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 .
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 03 March 2026 has been entered.
Response to Amendment
Applicant’s amendment filed 03 March 2026 amends claims 1-6 and 9-16. Claims 7, 8, 17, and 18 have been cancelled. Applicant’s amendment has been fully considered and entered.
Response to Arguments
Applicant argues on page 6 of the response, “The Applicant has amended claim 9 to provide a proper antecedent basis for ‘the requester,’ thereby clarifying the scope of claim 9 and rendering it definite.” This argument has been fully considered and is persuasive. Therefore, the previous §112 rejection of claim 9 has been fully considered and entered.
Applicant argues on pages 6-7 of the response, “Xu does not disclose – ‘retrieving, in response to the authentication token being determined to be valid for the at least one service provider from the gateway proxy, access credentials to access the cloud-based service of the at least one service provider, wherein one or more access credentials corresponding to one or more service providers are centrally stored and available at the gateway proxy.’” This argument has been fully considered and is persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground of rejection is made in view of Syomichev, U.S. Publication No. 2017/0339148.
Applicant argues on page 10 of the response, “To this end Application submits that Syomichev does not disclose a gateway proxy that sits between a separate local processing agent and a cloud-based service and that intercepts a service request received from that local processing agent and forms the service call on behalf of that agent.” In response, Applicant has failed to fully appreciate the proposed combination of Xu and Syomichev presented in the Final rejection mailed 05 December 2025 (“Final”). Specifically, the Final makes it clear (Page 16) that Xu discloses that the proxy authenticator can include the credential cache ([0109]). Xu does not specify that the proxy authenticator receives the user credentials separately and adds the user credentials to the service request message prior to forwarding the message to the callee service. Syomichev discloses a device that receives requests for services, injects credentials that are retrieved from central storage ([0030]: credential engine stores user credentials and can be considered “centrally” stored) into the requests, and forwards the modified requests to external services ([0058]: as it pertains to Xu, the service request message is not transmitted until after the token signature in the service request message is verified, which reads on the in response to authentication token being determined to be valid limitation). The Final goes on to state that it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for service request messages to have been transmitted to the proxy authenticator of Xu without credentials such that the proxy authenticator would have utilized the credential cache to retrieve credentials and inject the retrieved credentials into the service request prior to forwarding the service request message in order to reduce the credential vulnerability to leakage as suggested by Syomichev ([0006]).
Therefore, Xu, as modified by Syomichev, discloses that the proxy authenticator receives service request message, injects credentials received from the credential cache into the service request message, and forwards the request message to the callee service. Applicant has not addressed to combination of references and the proposed modification presented in the Final. One cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
Applicant argues on page 10 of the response, “In Syomichev, the application itself runs inside the host 821 and directly invokes the named credentials engine 831 as part of its normal execution; there is no disclosure of a distinct ‘local processing agent’ external to the host whole outgoing request is intercepted and modified by a gateway proxy.” In response, Applicant has failed to fully consider the proposed modification of Xu as presented above. Specifically, the host 821 corresponds with the proxy authenticator of Xu in that they each receive a request. However, host 821 of Syomichev injects the request with the received credentials. The proposed modification to Xu is simply for the service request messages of Xu to not include credentials and for the proxy authenticator of Xu to receive the necessary credentials and inject those credentials into the service request message upon receipt.
Applicant argues on page 11 of the response, “This reasoning is based on impermissible hindsight and does not reflect the actual teachings of the cited reference.” This argument is not persuasive because Syomichev specifically discloses that credentials for external services are vulnerable to leakage ([0006]) and that the procedures of Syomichev secures the credentials used to connect to external services by limited the exposure to the credentials ([0022]). Therefore, it is clear that the motivation to combine the references as presented in the Final comes directly from Syomichev.
Applicant argues on page 11 of the response, “Modifying Xu to remove credentials from the client request fundamentally changes Xu’s disclosed authentication model.” This argument is not persuasive because the authentication model remains the same. The only difference is the source of the authentication credentials, and Applicant has failed to provide any evidence that such a modification would present inoperability issues to the system of Xu.
Applicant argues on page 11 of the response, “Second, the Examiner’s rationale assumes that Xu’s ‘credential cache’ would be used to retrieve service-provider-specific access credentials and inject them into the request prior to forwarding. However, Xu does not disclose that the credential cache centrally stores the access credentials corresponding to multiple cloud-based service providers…” In response, the Examiner pointed to the credential cache of the proxy authenticator to show that the proxy authenticator included the means for implementing the proposed modification.
Applicant argues on pages 11-12 of the response, “Third, Syomichev’s general statement regarding reducing credential vulnerability to leakage does not supply…” In response, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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 factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-4, 9, 11, 12, 14 are rejected under 35 U.S.C. 103 as being unpatentable over Xu, U.S. Publication No. 2017/0141926, in view of Syomichev, U.S. Publication No. 2017/0339148. Referring to claim 1, Xu discloses a client sending a service request, that includes an authorization token ([0039]) and a resource indicator (Figure 4, 406 & [0126]: resource indicator reads on the claimed service information), to a proxy authenticator ([0039]: client reads on the claimed processing system) for a service provided by a service provider ([0034]: service/service provider reads on the claimed cloud based service/service provider), which meets the limitation of receiving a service request from a local processing agent of a processing system, the service request seeking access to a cloud-based service of the at least one service provider, the service request including at least service information and an authentication token. The client having previously received the authorization token from the proxy authenticator ([0178]-[0179]: proxy authenticator 710 forwards the authorization response 726 to the client; authorization response 726 includes authorization token), which meets the limitation of wherein the authentication token being previously provided to the local processing agent by a gateway proxy. The proxy authenticator extracts the authentication token from the received message and retrieves the public key that corresponds with the private key used to sign the token ([0067]-[0068]), which meets the limitation of extracting the authentication token from the service request. The proxy authenticator utilizes the public key to authenticate the authorization token ([0068]), which meets the limitation of determining whether the authentication token is valid. The service request message received by the proxy authenticator can include user credentials ([0161]-[0162]) and the proxy authenticator forwards the service request message to a routing controller responsive to the token being successfully verified ([0181]-[0182] & [0194]-[0195]: routing controller effectively retrieves the user credentials from the proxy authenticator to the extent that the routing controller receives the service request message from the proxy authenticator wherein the service request message includes the user credentials), which meets the limitation of retrieving, in response to the authentication token being determined to be valid for the at least one service provider, from the gateway proxy, [access credentials to access the cloud- based service of the at least one service provider], forming a service call for the cloud-based service on behalf of the local processing agent, by modifying, at the gateway proxy, the service request [by injecting access credentials]. The client receives a service response that reflects a response received from the service ([0184]: service response is not user credentials), which meets the limitation of wherein the access credentials are not transmitted to the local processing agent. The routing controller forwards the service request message, that includes resource indicator (Figure4, 406 & [0126]) and user credentials ([0161]- [0162]), to the callee service 224 that implements the service requested ([0183] & [0195]), which meets the limitation of making the service call to the at least one service provider.
Xu discloses that the service request message received by the proxy authenticator can include user credentials ([0161]-[0162]) such that the proxy authenticator forwards the service request message, that includes resource indicator (Figure 4, 406 & [0126]) and user credentials ([0161]-[0162]), to the callee service 224 that implements the service requested ([0069]).
Xu discloses that the proxy authenticator can include the credential cache ([0109]). Xu does not specify that the proxy authenticator receives the user credentials separately and adds the user credentials to the service request message prior to forwarding the message to the callee service. Syomichev discloses a device that receives requests for services, injects credentials that are retrieved from central storage ([0030]: credential engine stores user credentials and can be considered “centrally” stored) into the requests, and forwards the modified requests to external services ([0058]: as it pertains to Xu, the service request message is not transmitted until after the token signature in the service request message is verified, which reads on the in response to authentication token being determined to be valid limitation), which meets the limitation of retrieving, in response to authentication token being determined to be valid for the at least one service provider, from the gateway proxy, access credentials to access the cloud-based service of the at least one service provider, wherein one or more access credentials corresponding to one or more service providers are centrally stored and available at the gateway proxy, modifying, the service request by injecting the access credentials.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for service request messages to have been transmitted to the proxy authenticator of Xu without credentials such that the proxy authenticator would have utilized the credential cache to retrieve credentials and inject the retrieved credentials into the service request prior to forwarding the service request message in order to reduce the credential vulnerability to leakage as suggested by Syomichev ([0006] & [0022]).
Referring to claim 2, Xu discloses that the proxy authenticator receives a service response that includes a response from the callee service ([0184]), which meets the limitation of receiving a response to the service call. The proxy authenticator can forward the service response back to the client ([0184]), which meets the limitation of subsequently returning to the local processing agent at least a portion of the response to the service request.
Referring to claim 3, Xu discloses that resource indicator includes a URI that identifies the service provider and input parameters (Figure 4, 406 & [0126]), which meets the limitation of wherein the service information denotes the cloud-based service being requested and includes service input parameters for the cloud-based service.
Referring to claim 4, Xu discloses that resource indicator includes a URI that identifies the service provider, includes input parameters, and identifies the API name (Figure 4, 406 & [0126]), which meets the limitation of wherein the service information includes at least a service provider indication, a service indication, and a digital asset.
Referring to claim 9, Xu discloses a client sending a service request, that includes an previously provided authorization token ([0039]) with an expiration time ([0163] & [0171]), to a proxy authenticator ([0039]) for a service provided by a service provider ([0034]), which meets the limitation of wherein the service request is initiated by a requester, and wherein the authentication token is a time-limited token previously made available to the requester.
Referring to claims 11, 14, Xu discloses a client sending a service request, that includes an authorization token ([0039]) and a resource indicator (Figure 4, 406 & [0126]: resource indicator reads on the claimed service information), to a proxy authenticator ([0039]: client reads on the claimed processing system) for a service provided by a service provider ([0034]: service/service provider reads on the claimed cloud based service/service provider), which meets the limitation of computer program code for receiving a service request from a local processing agent, the service request seeking access to a cloud-based service of the at least one service provider, the service request including at least an authentication token, wherein the computer program code is executed by the gateway proxy. The client having previously received the authorization token from the proxy authenticator ([0178]-[0179]: proxy authenticator 710 forwards the authorization response 726 to the client; authorization response 726 includes authorization token), which meets the limitation of the authentication token being previously provided to the local processing agent by a gateway proxy. The proxy authenticator extracts the authentication token from the received message and retrieves the public key that corresponds with the private key used to sign the token ([0067]-[0068]), which meets the limitation of computer program code for extracting the authentication token from the service request. The proxy authenticator utilizes the public key to authenticate the authorization token ([0068]), which meets the limitation of computer program code for determining whether the authentication token is valid. The service request message received by the proxy authenticator can include user credentials ([0161]-[0162]) and the proxy authenticator forwards the service request message to a routing controller responsive to the token being successfully verified ([0181]-[0182] & [0194]-[0195]: routing controller effectively retrieves the user credentials from the proxy authenticator to the extent that the routing controller receives the service request message from the proxy authenticator wherein the service request message includes the user credentials), which meets the limitation of computer code for retrieving, in response to the authentication token being determined to be valid for the at least one service provider, from the gateway proxy, [access credentials to access the cloud- based service of the at least one service provider], computer program code for forming a service call for the cloud-based service on behalf of the local processing agent, by modifying, at the gateway proxy, the service request [by injecting access credentials]. The client receives a service response that reflects a response received from the service ([0184]: service response is not user credentials), which meets the limitation of wherein the access credentials are not transmitted to the local processing agent. The routing controller forwards the service request message, that includes resource indicator (Figure4, 406 & [0126]) and user credentials ([0161]- [0162]), to the callee service 224 that implements the service requested ([0183] & [0195]), which meets the limitation of computer program code for making the service call to the at least one service provider.
Xu discloses that the service request message received by the proxy authenticator can include user credentials ([0161]-[0162]) such that the proxy authenticator forwards the service request message, that includes resource indicator (Figure 4, 406 & [0126]) and user credentials ([0161]-[0162]), to the callee service 224 that implements the service requested ([0069]).
Xu discloses that the proxy authenticator can include the credential cache ([0109]). Xu does not specify that the proxy authenticator receives the user credentials separately and adds the user credentials to the service request message prior to forwarding the message to the callee service. Syomichev discloses a device that receives requests for services, injects credentials that are retrieved from central storage ([0030]: credential engine stores user credentials and can be considered “centrally” stored) into the requests, and forwards the modified requests to external services ([0058]: as it pertains to Xu, the service request message is not transmitted until after the token signature in the service request message is verified, which reads on the in response to authentication token being determined to be valid limitation), which meets the limitation of computer code for retrieving, in response to authentication token being determined to be valid for the at least one service provider, from the gateway proxy, access credentials to access the cloud-based service of the at least one service provider, wherein one or more access credentials corresponding to one or more service providers are centrally stored and available at the gateway proxy, modifying, the service request by injecting the access credentials.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for service request messages to have been transmitted to the proxy authenticator of Xu without credentials such that the proxy authenticator would have utilized the credential cache to retrieve credentials and inject the retrieved credentials into the service request prior to forwarding the service request message in order to reduce the credential vulnerability to leakage as suggested by Syomichev ([0006] & [0022]).
Referring to claim 12, Xu discloses a client sending a service request, that includes an authorization token ([0039]) and a resource indicator (Figure 4, 406 & [0126]: resource indicator reads on the claimed service input parameters), to a proxy authenticator ([0039]) for a service provided by a service provider ([0034]), which meets the limitation of wherein the service request includes the service input parameters.
Claims 5, 6, 10, 13, 15, 16 are rejected under 35 U.S.C. 103 as being unpatentable over Xu, U.S. Publication No. 2017/0141926, in view of Syomichev, U.S. Publication No. 2017/0339148, and further in view of Blohm, U.S. Publication No. 2021/0271985. Referring to claims 5, 10, Xu discloses a client sending a service request, that includes an authorization token ([0039]) and a resource indicator (Figure 4, 406 & [0126]), to a proxy authenticator ([0039]) for a service provided by a service provider ([0034]).
Xu does not specify that the client device is a robotic automation system. Blohm discloses computing devices being implemented as robotic autonomous devices ([0080]), which meets the limitation of wherein the processing system is a robotic processing automation system, wherein the local processing agent is a bot or bot-agent of a robotic processing automation system. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the client device of Xu to have been implemented as a robotic autonomous device because Blohm discloses that robotic autonomous devices are one of a finite number of possible devices that could be implemented by one of ordinary skill in the art with a reasonable expectation of success ([0080]).
Referring to claim 6, Xu discloses that the proxy authenticator receives a service response that includes a response from the callee service ([0184]), which meets the limitation of receiving a response to the service call. The proxy authenticator can forward the service response back to the client ([0184]), which meets the limitation of subsequently returning to the local processing agent at least a portion of the response to the service request.
Referring to claim 13, Xu discloses a client sending a service request, that includes an authorization token ([0039]) and a resource indicator (Figure 4, 406 & [0126]), to a proxy authenticator ([0039]) for a service provided by a service provider ([0034]).
Xu does not specify that the client device is a robotic automation system. Blohm discloses computing devices being implemented as robotic autonomous devices ([0080]), which meets the limitation of wherein the service request is sent by a bot or bot-agent of the robotic processing automation system. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the client device of Xu to have been implemented as a robotic autonomous device because Blohm discloses that robotic autonomous devices are one of a finite number of possible devices that could be implemented by one of ordinary skill in the art with a reasonable expectation of success ([0080]).
Referring to claims 15, 16, Xu discloses a client sending a service request, that includes an authorization token ([0039]) and a resource indicator (Figure 4, 406 & [0126]), to a proxy authenticator ([0039]) for a service provided by a service provider ([0034]), which meets the limitation of wherein the local processing agent is a [bot supported by a robotic processing automation system], wherein the [robotic processing automation system supporting a plurality of bots], and wherein the [bot] at least issues the service request to the cloud-based service of the at least one service provider in an [automated] manner without user input.
Xu does not specify that the client device is a robotic automation system. Blohm discloses computing devices being implemented as robotic autonomous devices ([0080]), which meets the limitation of wherein the local processing agent is a bot supported by a robotic processing automation system, the robotic processing automation system supporting a plurality of bots. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the client device of Xu to have been implemented as a robotic autonomous device because Blohm discloses that robotic autonomous devices are one of a finite number of possible devices that could be implemented by one of ordinary skill in the art with a reasonable expectation of success ([0080]).
Xu does not suggest that the client issues the service request automatically without user input. However, it is well settled that it is not "invention" to broadly provide a mechanical or automatic means to replace manual activity which has accomplished the same result. In re Venner, 120 USPQ 192. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the service requests of Xu to have been issue automatically without user input because it has been well settled that such a modification is not “invention”.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BENJAMIN E LANIER whose telephone number is (571)272-3805. The examiner can normally be reached M-Th: 6:20-4:50.
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, Alexander Lagor can be reached at 5712705143. 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.
/BENJAMIN E LANIER/ Primary Examiner, Art Unit 2437