Prosecution Insights
Last updated: April 19, 2026
Application No. 18/355,290

ASYNCHRONOUS AUTHORIZATION OF APPLICATION ACCESS TO RESOURCES

Non-Final OA §103
Filed
Jul 19, 2023
Examiner
HERZOG, MADHURI R
Art Unit
2438
Tech Center
2400 — Computer Networks
Assignee
Microsoft Technology Licensing, LLC
OA Round
3 (Non-Final)
78%
Grant Probability
Favorable
3-4
OA Rounds
3y 1m
To Grant
90%
With Interview

Examiner Intelligence

Grants 78% — above average
78%
Career Allow Rate
516 granted / 662 resolved
+19.9% vs TC avg
Moderate +12% lift
Without
With
+11.9%
Interview Lift
resolved cases with interview
Typical timeline
3y 1m
Avg Prosecution
35 currently pending
Career history
697
Total Applications
across all art units

Statute-Specific Performance

§101
12.4%
-27.6% vs TC avg
§103
45.7%
+5.7% vs TC avg
§102
13.0%
-27.0% vs TC avg
§112
17.0%
-23.0% vs TC avg
Black line = Tech Center average estimate • Based on career data from 662 resolved cases

Office Action

§103
DETAILED ACTION Notice of Pre-AIA or AIA Status The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . Claims 21-23, 25-31, and 33-40 have been examined. Continued Examination Under 37 CFR 1.114 A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 11/10/2025 has been entered. Response to Amendment Claims 21, 25, 28, 29, 33, 36, 37, 39, and 40 have been amended. Claims 24 and 32 have been cancelled. The rejection of claims 28, 36, and 40 under 35 U.S.C 112 is withdrawn in light of the applicant’s amendments to the claims. Applicant’s arguments with respect to claims 21, 29, and 37 regarding the new limitations: “send a message to a user of an application regarding whether the user would like to seek approval for a request for access by an application to a resource; responsive to receipt of an instruction from the user to seek approval for the request, output a notification for an authorized entity to evaluate the request”, have been considered but are moot in view of the new ground of rejection presented in the current office action. Claim Rejections - 35 USC § 103 The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action. Claims 21, 25, 27-29, 33, 35-37, and 39-40 are rejected under 35 U.S.C. 103 as being unpatentable over prior art of record US 20180375791 to Kaladgi et al (hereinafter Kaladgi), US 20040003071 to Mathew et al (hereinafter Mathew), and prior art of record US 20210352069 to Momchilov et al (hereinafter Momchilov). As per claims 21 and 29, Kaladgi teaches: An apparatus comprising: a processor; and a memory on which is stored machine-readable instructions that cause the processor to: output a notification for an authorized entity to evaluate the request, wherein the authorized entity is to evaluate the request (Kaladgi: [0022]: in response to a single access request, provisioning of a suite of access tokens. In various embodiments, resources 107 may be protected resources that, as noted above, require user 102's authorization to be accessed. Information specifying the grant of access privileges may be sent to user 102, for example by application 105. In such embodiments, the information specifying the grant of access privileges may include the types of access requested by the application and the corresponding durations for each of the types of access that are requested by application 105); receive, from the authorized entity, an indication that the request is granted; and based on a determination that the request is granted: submit, to an authorization server, an authorization grant for the application to access the resource, wherein, responsive to the authorization grant, the authorization server provides an access token that the application is to submit to access the resource (Kaladgi: [0022]: As shown in FIG. 1, user 102 may authorize application 105 to make such access by sending information indicative of a grant of access privileges to authorization server 108 that authorizes application 105 to access resources 107. Further, in some embodiments, the grant of access privileges may specify the types of access application 105 is permitted to make and the authorized duration for each type of access. Note that, in some embodiments, the information indicative of the grant of access privileges may instead be sent from user 102 to application 105, rather than to authorization server 108 (In this case the application 105 will submit the information indicative of the grant of access privileges to the authorization server 108). [0023]: authorization server 108 may provision a plurality of access tokens to application 105 corresponding user 102's grant of access privileges. In some embodiments, each of the plurality of access tokens may authorize a particular scope of access to resources 107 for a particular duration); forward, to the application, the access token for accessing the resource, wherein the application is to present the access token to a resource server to gain access to the resource (Kaladgi: [0023]: As shown in FIG. 1, subsequent to receiving the plurality of access tokens, application 105 may send one or more access requests, including one or more of the plurality of access tokens, to resource server 106, requesting to access one or more resources 107 of user 102 managed by resource server 106); Kaladgi does not teach: send a message to a user of an application regarding whether the user would like to seek approval for a request for access by an application to a resource; responsive to receipt of an instruction from the user to seek approval for the request, output a notification for an authorized entity to evaluate the request, wherein the authorized entity is to evaluate the request asynchronously with submission of the request by the application; and clear, responsive to forwarding the access token to the application, a record of the request from a data store. However, Mathew teaches: send a message to a user of an application regarding whether the user would like to seek approval for a request for access by an application to a resource (Mathew: [0055]: the user requested actions can include a Web site request from user 754, …, a file download request from user 760,… a run application request from user 764, etc. [0057]-[0058] At decision block 908, a test is made to determine if the user would like to submit a request for consent from the administrator to perform the blocked online action); responsive to receipt of an instruction from the user to seek approval for the request (Mathew: [0058]: If at decision block 908, it is determined that a user request for consent was received, routine 900 proceeds to block 910 where information related to the request is collected), output a notification for an authorized entity to evaluate the request, wherein the authorized entity is to evaluate the request asynchronously with submission of the request by the application (Mathew: [0059] After collecting the data related to the request at block 910, routine 900 proceeds to block 912 and creates an entry in consent database 208 for the request. In one embodiment, routine 900 creates the entry using the data structure 700 described above with reference to FIG. 7A. After creating the entry in the consent database 208 for the request, routine 900 proceeds to block 914. In one embodiment of the present invention, routine 900 sends the administrator notification of the pending request. The administrator is provided notification of the pending request at the time the administrator logs on, as described below with reference to FIG. 10. Routine 1000 starts at block 1002 and proceeds to decision block 1004 where a test is made to determine if the administrator has been detected logging on. If at decision block 1004, it is determined that the administrator was not detected logging on, routine 1000 cycles back until decision block 1004 tests positive. If at decision block 1004, it is determined that the administrator was detected logging on, routine 1000 proceeds to block 1006. If at decision block 1008, a pending request is found in the consent database 208, routine 1000 proceeds to block 1010 where the administrator is sent notification of the pending request, i.e., the administrator is notified of the pending request when the administrator logs in at a later time after the user submits the request. [0062] After displaying the pending request to the administrator at block 1108, routine 1100 proceeds to decision block 1110 where a test is made to determine if the administrator accepts the pending request. If at decision block 1110, it is determined that the administrator accepted the pending request, routine 1100 proceeds to block 1112, i.e., the administrator evaluates the request asynchronously with the submission of the request). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to employ the teachings of Mathew in the invention of Kaladgi to include the above limitations. The motivation to do so would be to enable a user and an administrator in a network environment to interactively customize the administrator controls used to filter the user's online actions (Mathew: [0006]). Kaladgi in view of Mathew does not teach: clear, responsive to forwarding the access token to the application, a record of the request from a data store. However, Momchilov teaches: clear, responsive to forwarding the access token to the application, a record of the request from a data store (Momchilov: [0041]: the application hosted within the virtual computing session is a hosted browser, initiates a hosted browser, or is capable of processing uniform resource identifiers (URIs). This hosted application initiates an OAuth workflow by transmitting, to an authorization server, a request for authorization to access resources protected by a resource server. In these examples, the virtualization agent executing within the virtual computing session intercepts these authorization requests. Further, the host virtualization agent passes intercepted authorization requests (e.g., over a virtual communication channel) to the virtualization agent executing locally on the endpoint device. [0043]: The local virtualization agent passes the authorization response to the host virtualization agent. The host virtualization agent invokes the hosted application and passes the authorization response to the hosted application. Regardless of how the hosted application acquires the token, the hosted application next uses the token to access resources protected by the resource server. [0143] Continuing this example, the local virtualization agent creates (e.g., the operation 1802 of FIG. 16) a request record that stores an identifier of the virtual computing session that originated the authorization request and a copy of the authorization request. [0144]: The local virtualization agent receives (e.g., the operation 2304 of FIG. 16) the authorization response. The local virtualization agent looks up (e.g., the operation 1810 of FIG. 16) the request record corresponding to the authorization response and passes (e.g., the operation 508 of FIG. 16) the authorization response to the host virtualization agent. [0145] Continuing this example, the local virtualization agent unregisters (e.g., the operation 2306 of FIG. 16) as the URI scheme handler for authorization responses and deletes the looked-up request record, i.e., after the authorization response comprising the token is passed to the hosted application, the request record is deleted). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to employ the teachings of Momchilov in the invention of Kaladgi in view of Mathew to include the above limitations. The claim would have been obvious because a particular known technique was recognized as part of the ordinary capabilities of one skilled in the art (see KSR Int’l Co. v. Teleflex Inc. 550 U.S. ___, 82 USPQ2d 1385 (Supreme Court 2007) (KSR)). As per claim 37, Kaladgi teaches: A non-transitory computer-readable medium on which is stored computer-readable instructions that when executed by a processor, cause the processor to: output a notification to an authorized entity, wherein the authorized entity is to evaluate the request (Kaladgi: [0022]: in response to a single access request, provisioning of a suite of access tokens. In various embodiments, resources 107 may be protected resources that, as noted above, require user 102's authorization to be accessed. Information specifying the grant of access privileges may be sent to user 102, for example by application 105. As shown in FIG. 1, user 102 may authorize application 105 to make such access by sending information indicative of a grant of access privileges to authorization server 108 that authorizes application 105 to access resources 107. Note that, in some embodiments, the information indicative of the grant of access privileges may instead be sent from user 102 to application 105, rather than to authorization server 108. In such embodiments, the information specifying the grant of access privileges may include the types of access requested by the application and the corresponding durations for each of the types of access that are requested by application 105); receive, from the authorized entity, an indication that the request is granted; and based on a determination that the request is granted: submit, to an authorization server, an authorization grant for the application to access the resource, wherein responsive to the authorization grant, the authorization server provides an access token that the application is to submit to access the resource (Kaladgi: [0022]: As shown in FIG. 1, user 102 may authorize application 105 to make such access by sending information indicative of a grant of access privileges to authorization server 108 that authorizes application 105 to access resources 107. Further, in some embodiments, the grant of access privileges may specify the types of access application 105 is permitted to make and the authorized duration for each type of access. Note that, in some embodiments, the information indicative of the grant of access privileges may instead be sent from user 102 to application 105, rather than to authorization server 108 (In this case the application 105 will submit the information indicative of the grant of access privileges to the authorization server 108). [0023]: authorization server 108 may provision a plurality of access tokens to application 105 corresponding user 102's grant of access privileges. In some embodiments, each of the plurality of access tokens may authorize a particular scope of access to resources 107 for a particular duration); forward, to the application, the access token for accessing the resource, wherein the application is to present the access token to a resource server to gain access to the resource (Kaladgi: [0023]: As shown in FIG. 1, subsequent to receiving the plurality of access tokens, application 105 may send one or more access requests, including one or more of the plurality of access tokens, to resource server 106, requesting to access one or more resources 107 of user 102 managed by resource server 106); Kalagdi does not teach: send a message to a user of an application regarding whether the user would like to seek approval for a request for access by an application to a resource; responsive to receipt of an instruction from the user to seek approval for the request, output a notification to an authorized entity, wherein the authorized entity is to evaluate the request asynchronously with submission by an application of the request; and clear, responsive to forwarding the access token to the application, a record of the request from a data store. However, Mathew teaches: send a message to a user of an application regarding whether the user would like to seek approval for a request for access by an application to a resource (Mathew: [0055]: the user requested actions can include a Web site request from user 754, …, a file download request from user 760,… a run application request from user 764, etc. [0057]-[0058] At decision block 908, a test is made to determine if the user would like to submit a request for consent from the administrator to perform the blocked online action); responsive to receipt of an instruction from the user to seek approval for the request, output a notification to an authorized entity, wherein the authorized entity is to evaluate the request asynchronously with submission by an application of the request (Mathew: [0059] After collecting the data related to the request at block 910, routine 900 proceeds to block 912 and creates an entry in consent database 208 for the request. In one embodiment, routine 900 creates the entry using the data structure 700 described above with reference to FIG. 7A. After creating the entry in the consent database 208 for the request, routine 900 proceeds to block 914. In one embodiment of the present invention, routine 900 sends the administrator notification of the pending request. The administrator is provided notification of the pending request at the time the administrator logs on, as described below with reference to FIG. 10. Routine 1000 starts at block 1002 and proceeds to decision block 1004 where a test is made to determine if the administrator has been detected logging on. If at decision block 1004, it is determined that the administrator was not detected logging on, routine 1000 cycles back until decision block 1004 tests positive. If at decision block 1004, it is determined that the administrator was detected logging on, routine 1000 proceeds to block 1006. If at decision block 1008, a pending request is found in the consent database 208, routine 1000 proceeds to block 1010 where the administrator is sent notification of the pending request, i.e., the administrator is notified of the pending request when the administrator logs in at a later time after the user submits the request. [0062] After displaying the pending request to the administrator at block 1108, routine 1100 proceeds to decision block 1110 where a test is made to determine if the administrator accepts the pending request. If at decision block 1110, it is determined that the administrator accepted the pending request, routine 1100 proceeds to block 1112, i.e., the administrator evaluates the request asynchronously with the submission of the request). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to employ the teachings of Mathew in the invention of Kaladgi to include the above limitations. The motivation to do so would be to enable a user and an administrator in a network environment to interactively customize the administrator controls used to filter the user's online actions (Mathew: [0006]). Kaladgi in view of Mathew does not teach: clear, responsive to forwarding the access token to the application, a record of the request from a data store. However, Momchilov teaches: clear, responsive to forwarding the access token to the application, a record of the request from a data store (Momchilov: [0041]: the application hosted within the virtual computing session is a hosted browser, initiates a hosted browser, or is capable of processing uniform resource identifiers (URIs). This hosted application initiates an OAuth workflow by transmitting, to an authorization server, a request for authorization to access resources protected by a resource server. In these examples, the virtualization agent executing within the virtual computing session intercepts these authorization requests. Further, the host virtualization agent passes intercepted authorization requests (e.g., over a virtual communication channel) to the virtualization agent executing locally on the endpoint device. [0043]: The local virtualization agent passes the authorization response to the host virtualization agent. The host virtualization agent invokes the hosted application and passes the authorization response to the hosted application. Regardless of how the hosted application acquires the token, the hosted application next uses the token to access resources protected by the resource server. [0143] Continuing this example, the local virtualization agent creates (e.g., the operation 1802 of FIG. 16) a request record that stores an identifier of the virtual computing session that originated the authorization request and a copy of the authorization request. [0144]: The local virtualization agent receives (e.g., the operation 2304 of FIG. 16) the authorization response. The local virtualization agent looks up (e.g., the operation 1810 of FIG. 16) the request record corresponding to the authorization response and passes (e.g., the operation 508 of FIG. 16) the authorization response to the host virtualization agent. [0145] Continuing this example, the local virtualization agent unregisters (e.g., the operation 2306 of FIG. 16) as the URI scheme handler for authorization responses and deletes the looked-up request record, i.e., the authorization response comprising the token is passed to the hosted application, the request record is deleted). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to employ the teachings of Momchilov in the invention of Kaladgi in view of Mathew to include the above limitations. The claim would have been obvious because a particular known technique was recognized as part of the ordinary capabilities of one skilled in the art (see KSR Int’l Co. v. Teleflex Inc. 550 U.S. ___, 82 USPQ2d 1385 (Supreme Court 2007) (KSR)). As per claims 25 and 33, Kaladgi in view of Mathew, and Momchilov teaches: The apparatus of claim 21, wherein the instructions cause the processor to: based on the receipt of the instruction from the user to not seek approval for the request, reject the request for access by the application to the resource (Mathew: [0058] At decision block 908, a test is made to determine if the user would like to submit a request for consent from the administrator to perform the blocked online action. If at decision block 908, it is determined that the user does not want to submit the consent request, routine 900 cycles back to decision block 904 and the above steps are repeated. [0057]: If at decision block 904, it is determined that the user was blocked from performing an online action. It is inherent that if the user does not want to submit the request for approval by an administrator, the request will be blocked); and clear a record of the request from a data store (Mathew: [0009]: The computer tracks and stores the user's allowed and blocked online actions. The computer generates a history summary report from the stored information and provides the history summary report to the administrator. After sending the history summary report to the administrator in block 1418, routine 1400 proceeds to block 1420 and clears the stored history summary information). The examiner provides the same rationale to combine prior arts Kaladgi and Mathew as in claims 21 and 29 above. As per claims 27 and 35, Kaladgi in view of Mathew and Momchilov teaches: The apparatus of claim 21, wherein the notification comprises: a push notification to a device of the authorized entity; an email message to the authorized entity; and/or an entry in a queue of pending requests displayed in a dedicated web portal or a mobile application (Mathew: [0059]: In one embodiment of the present invention, routine 900 sends the administrator notification of the pending request. The notification can be sent utilizing any of the various ways known by those of ordinary skill in the art. For example, the notification can be sent via e-mail and instant messaging). The examiner provides the same rationale to combine prior arts Kaladgi and Mathew as in claims 21 and 29 above. As per claims 28, 36, and 40, Kaladgi in view of Mathew and Momchilov teaches: The apparatus of claim 21, wherein the instructions to clear, responsive to forwarding the access token to the application, the record of the request from a data store cause the processor to: access the request for access by the application to the resource; and clear the record of the request from the data store after the access token to the resources has been forwarded to the application (Momchilov: [0143] Continuing this example, the local virtualization agent creates (e.g., the operation 1802 of FIG. 16) a request record that stores an identifier of the virtual computing session that originated the authorization request and a copy of the authorization request. [0144]: The local virtualization agent receives (e.g., the operation 2304 of FIG. 16) the authorization response. The local virtualization agent looks up (e.g., the operation 1810 of FIG. 16) the request record corresponding to the authorization response and passes (e.g., the operation 508 of FIG. 16) the authorization response to the host virtualization agent. [0145] Continuing this example, the local virtualization agent unregisters (e.g., the operation 2306 of FIG. 16) as the URI scheme handler for authorization responses and deletes the looked-up request record). The examiner provides the same rationale to combine prior arts Kaladgi in view of Mathew and Momchilov as in claims 21, 29, and 37 above. As per claim 39, Kaladgi in view of Mathew and Momchilov teaches: The non-transitory computer-readable medium of claim 37, wherein the instructions further cause the processor to: send a second message to a second user of the application regarding whether the second user would like to seek approval for a second request, wherein the second request is for access by the application to the resource (Mathew: [0055]: the user requested actions can include a Web site request from user 754, …, a file download request from user 760,… a run application request from user 764, etc. [0057]-[0058] At decision block 908, a test is made to determine if the user would like to submit a request for consent from the administrator to perform the blocked online action); based on receipt of a second instruction from the second user to seek approval for the second request, output a second notification to the authorized entity (Mathew: [0058]: If at decision block 908, it is determined that a user request for consent was received, routine 900 proceeds to block 910 where information related to the request is collected. [0059] After collecting the data related to the request at block 910, routine 900 proceeds to block 912 and creates an entry in consent database 208 for the request. In one embodiment, routine 900 creates the entry using the data structure 700 described above with reference to FIG. 7A. After creating the entry in the consent database 208 for the request, routine 900 proceeds to block 914. In one embodiment of the present invention, routine 900 sends the administrator notification of the pending request.); and based on receipt of the second instruction from the second user to not seek approval for the request: reject the second request for access by the application to the resource (Mathew: [0058] At decision block 908, a test is made to determine if the user would like to submit a request for consent from the administrator to perform the blocked online action. If at decision block 908, it is determined that the user does not want to submit the consent request, routine 900 cycles back to decision block 904 and the above steps are repeated. [0057]: If at decision block 904, it is determined that the user was blocked from performing an online action. It is inherent that if the user does not want to submit the request for approval by an administrator, the request will be blocked); and clear the record of the second request from the data store (Mathew: [0009]: The computer tracks and stores the user's allowed and blocked online actions. The computer generates a history summary report from the stored information and provides the history summary report to the administrator. After sending the history summary report to the administrator in block 1418, routine 1400 proceeds to block 1420 and clears the stored history summary information). The examiner provides the same rationale to combine prior arts Kaladgi in view of Mathew and Momchilov as in claim 37 above. Claims 22, 23, 30, 31, and 38 are rejected under 35 U.S.C. 103 as being unpatentable over Kaladgi in view of Mathew and Momchilov as applied to claims 21 and 29 above, and further in view of prior art of record EP 1134644 A2 to Parry et al (hereinafter Parry). As per claims 22 and 30, Kaladgi in view of Mathew and Momchilov does not teach the limitations of claims 22 and 30. However, Parry teaches: wherein the instructions cause the processor to: initiate a timer set to a predefined duration responsive to the output of the notification; determine whether the response is received prior to expiration of the predefined duration; and based on a determination that the response is not received prior to expiration of the predefined duration, output a reminder notification to the authorized entity (Parry: [0011] Preferably, the method further comprises: sending notices to notice receivers by a notice sender, said notices including: confirmatory requests for verification of continued access rights; user ID data for each said user ID currently having access rights; a user-defined time limit for responding to said notice. [0063]: Requests to a system are approved by one or more approvers as described herein. Shown in FIG. 3 is a first time limit 82 which designates how many days a request can sit without action before a reminder is sent to the delinquent approver or approvers. If stage one approvers are delinquent, only they will receive the note. If some stage one approvers have already approved, they will not receive the notice. If a stage two approver is the delinquent party, only that approver will receive the notice and not stage one approvers). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to employ the teachings of Parry in the invention of Kaladgi in view of Mathew and Momchilov to include the above limitations. The claim would have been obvious because a particular known technique was recognized as part of the ordinary capabilities of one skilled in the art (see KSR Int’l Co. v. Teleflex Inc. 550 U.S. ___, 82 USPQ2d 1385 (Supreme Court 2007) (KSR)). As per claims 23 and 31, Kaladgi in view of Mathew, Momchilov and Parry teaches: The apparatus of claim 22, wherein the instructions cause the processor to: initiate a second timer set to a second predefined duration responsive to the output of the reminder notification; determine whether the response is received prior to expiration of the second predefined duration; and based on a determination that the response is not received prior to expiration of the second predefined duration: reject the request for access by the application to the resource ([0012] Said notices may include a first notice and a second notice, wherein said second notice is sent to said notice receivers who have not responded to said first notice by said time limit and, wherein further, said second notice contains a second user-defined time limit for responding. [0015] Preferably, access rights are denied to said entity for said user IDs for which no response to said requests for verification was received by said notice sender within said time limit prescribed in said notice); and clear the record of the request from the data store (Parry: [0071]: This facility will allow the setup of a reminder notice, or the removal of a pending request, if the request for authorisation is not acted upon in the specified amount of time). The examiner provides the same rationale to combine prior arts Kaladgi in view of Mathew, Momchilov and Parry as in claims 22 and 30 above. As per claim 38, Kaladgi in view of Mathew and Momchilov does not teach the limitations of claim 38. However, Parry teaches: wherein the instructions further cause the processor to: initiate a timer set to a predefined duration responsive to the output of the notification; determine whether the response is received prior to expiration of the predefined duration; and based on a determination that the response is not received prior to expiration of the predefined duration: output a reminder notification to the authorized entity; or reject the request (Parry: [0011] Preferably, the method further comprises: sending notices to notice receivers by a notice sender, said notices including: confirmatory requests for verification of continued access rights; user ID data for each said user ID currently having access rights; a user-defined time limit for responding to said notice. [0063]: Requests to a system are approved by one or more approvers as described herein. Shown in FIG. 3 is a first time limit 82 which designates how many days a request can sit without action before a reminder is sent to the delinquent approver or approvers. If stage one approvers are delinquent, only they will receive the note. If some stage one approvers have already approved, they will not receive the notice. If a stage two approver is the delinquent party, only that approver will receive the notice and not stage one approvers). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to employ the teachings of Parry in the invention of Kaladgi in view of Mathew and Momchilov to include the above limitations. The claim would have been obvious because a particular known technique was recognized as part of the ordinary capabilities of one skilled in the art (see KSR Int’l Co. v. Teleflex Inc. 550 U.S. ___, 82 USPQ2d 1385 (Supreme Court 2007) (KSR)). Claims 26 and 34 are rejected under 35 U.S.C. 103 as being unpatentable over Kaladgi in view of Mathew and Momchilov as applied to claims 21 and 29 above, and further in view of prior art of record US 11341504 to Stanev (hereinafter Stanev). As per claims 26 and 34, Kaladgi in view of Mathew and Momchilov does not teach the limitations of claims 26 and 34. However, Stanev teaches: wherein, to identify the authorized entity, the instructions cause the processor to: select the authorized entity from a list of authorized entities (Stanev: column 8, lines 10-26: the policy may stipulate particular administrators to transmit a request to (e.g., an approval request as described herein). In some examples, the list of administrators may be updated to include new and/or different administrators. In some examples, the transmission module 225 may transmit an approval request to approve the financial transaction to a first administrator associated with the regulated account). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to employ the teachings of Stanev in the invention of Kaladgi in view of Mathew and Momchilov to include the above limitations. The motivation to do so would be to facilitating the approval or denial of a financial transaction using two-factor authentication (Stanev: column 3, lines 45-49). Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure: US 10567387 to Trinh et al: The disclosed computer-implemented method for managing computing device access to local area computer networks may include (i) receiving, at a router computing device, a request to connect a client computing device to a local area computer network, (ii) determining whether the client computing device has prior authorization to connect to the local area computer network, (iii) sending, when the client computing device is determined to not have prior authorization, a request to an administrator computing device for authorization to connect the client computing device to the local area computer network, (iv) receiving, from the administrator computing device, an instruction to allow the client computing device to connect or to block the client computing device from connecting, and (v) performing a security action to block or allow the client computing device's request based on the instruction. Various other methods, systems, and computer-readable media are also disclosed. Any inquiry concerning this communication or earlier communications from the examiner should be directed to MADHURI R HERZOG whose telephone number is (571)270-3359. The examiner can normally be reached 8:30AM-4:30PM. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Taghi Arani can be reached at (571)272-3787. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. MADHURI R. HERZOG Primary Examiner Art Unit 2438 /MADHURI R HERZOG/Primary Examiner, Art Unit 2438
Read full office action

Prosecution Timeline

Jul 19, 2023
Application Filed
Apr 10, 2025
Non-Final Rejection — §103
Jun 25, 2025
Interview Requested
Jul 02, 2025
Applicant Interview (Telephonic)
Jul 02, 2025
Examiner Interview Summary
Jul 15, 2025
Response Filed
Sep 04, 2025
Final Rejection — §103
Oct 31, 2025
Examiner Interview Summary
Oct 31, 2025
Applicant Interview (Telephonic)
Nov 10, 2025
Request for Continued Examination
Nov 17, 2025
Response after Non-Final Action
Feb 26, 2026
Non-Final Rejection — §103
Apr 03, 2026
Interview Requested

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12603766
QKD SWITCHING SYSTEM AND PROTOCOLS
2y 5m to grant Granted Apr 14, 2026
Patent 12592925
METHOD AND SYSTEM FOR AUTHENTICATING A USER ON AN IDENTITY-AS-A-SERVICE SERVER WITH A TRUSTED THIRD PARTY
2y 5m to grant Granted Mar 31, 2026
Patent 12592820
SYSTEMS AND METHODS FOR DIGITAL RETIREMENT OF INFORMATION HANDLING SYSTEMS
2y 5m to grant Granted Mar 31, 2026
Patent 12587383
METHOD AND SYSTEM FOR OUT-OF-BAND USER IDENTIFICATION IN THE METAVERSE VIA BIOGRAPHICAL (BIO) ID
2y 5m to grant Granted Mar 24, 2026
Patent 12556550
THREAT DETECTION PLATFORMS FOR DETECTING, CHARACTERIZING, AND REMEDIATING EMAIL-BASED THREATS IN REAL TIME
2y 5m to grant Granted Feb 17, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

3-4
Expected OA Rounds
78%
Grant Probability
90%
With Interview (+11.9%)
3y 1m
Median Time to Grant
High
PTA Risk
Based on 662 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month