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 .
Response to Amendment
Applicant’s amendment filed 22 May 2026 amends claims 1 and 11. Claims 15 and 16 have been cancelled. Applicant’s amendment has been fully considered and entered.
Response to Arguments
Applicant argues on page 2 of the response, “The credential cache operates within a token-verification pipeline, not a credential-injection pipeline. Accordingly, the existence of the credential cache does not provide a means to implement the proposed modification. This argument is not persuasive because Applicant has failed to show any actual evidence that the system of Xu would not be capable of implementing the proposed modification. A reference may be understood by the artisan as suggesting a solution to a problem that the reference does not discuss. See KSR, 137, S. Ct. at 1742, 82 USPQ2d at 1397 (“Common sense teaches…that familiar items may have obvious uses beyond their primary purposes, and in many cases a personal of ordinary skill will be able to fit the teachings of multiple patents together like pieces of a puzzle... A person of ordinary skill is also a person of ordinary creativity, not an automaton.").
Applicant argues on page 2 of the response, “Rather, Applicant submits that the proposed combination itself is improper and does not provide a legally sufficient basis for the § 103 rejection.” This argument is not persuasive because Applicant has failed to provide any evidence that the proposed modifications to Xu as presented in the Non-Final dated 20 March 2026 (“Non-Final”) are “improper”. Arguments presented by applicant cannot take the place of factually supported objective evidence. See, e.g., In re Schulze, 346 F.2d 600, 602, 145 USPQ 716, 718 (CCPA 1965); In re De Blauwe, 736 F.2d 699, 705, 222 USPQ 191, 196 (Fed. Cir. 1984).
Applicant argues on pages 2-3 of the response, “Xu’s principle of operation is a zone-based PKI authentication architecture in which a proxy authenticator verifies signed requests or tokens…Xu’s proxy authenticator does not originate, retrieve, select, or inject service-provider-specific access credentials on behalf of a client or local processing agent.” In response, Xu actually specifies that the authorization controller generates the authorization token ([0190]) and that the aspects of figure 8 can be performed by the authorization controller or the proxy authenticator ([0187]). Therefore, Xu is clearly unconcerned regarding which element, the authorization controller or the proxy authenticator, performs the functional steps of figure 8, which includes the generation of the authorization token.
Applicant argues on page 3 of the response, “A generalized desire to reduce credential exposure does not provide a reasoned basis to make this specific cross-architectural modification.” In response, Applicant has failed to point out any “cross-architectural modification” being suggested. Instead, the proposed modification rather clear from the Non-Final in 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] & [0022]).”
Applicant argues on page 4 of the response, “…Xu’s proxy authenticator 710 is a separate network-facing component in the Perimeter Zone 704 that intercepts incoming requests from external clients and performs token verification before forwarding…The mere fact that both components ‘receive a request’ does not establish architecture equivalence.” In response, there is no legal requirement for “architectural equivalence” as required by Applicant. Instead, Applicant makes clear that “network-facing” nature of the proxy authenticator 710 puts the contents of the requests received by the proxy authenticator at risk during transmission. Therefore, the proposed modification to Xu presented in the Non-Final that suggests that the 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, appears all the more beneficial to reduce the credential vulnerability to leakage during those transmissions as suggested by Syomichev ([0006] & [0022]).
Applicant argues on page 5 of the response, “Syomichev’s solution to credential leakage is to have the application itself avoid hard-coding or locally storing credentials, and instead call a named credentials engine at runtime to inject them into outgoing requests. This is an application-level solution…” In response, a reference may be understood by the artisan as suggesting a solution to a problem that the reference does not discuss. See KSR, 137, S. Ct. at 1742, 82 USPQ2d at 1397 (“Common sense teaches…that familiar items may have obvious uses beyond their primary purposes, and in many cases a personal of ordinary skill will be able to fit the teachings of multiple patents together like pieces of a puzzle... A person of ordinary skill is also a person of ordinary creativity, not an automaton."). As stated above, the requests are transmitted and the contents of those requests would be at risk during transmission. The proposed modification elevates the risk of credential exposure during transmission as stated in the Non-Final.
Applicant argues on page 5 of the response, “The Applicant respectfully submits that the proposed modification does not merely change ‘the source’ of credentials…” In response, that is the proposed modification as presented in the Non-Final. 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 6 of the response, “…the cited portions of Xu do not disclose that the credential cache stores service-provider-specific access credential for multiple external cloud-based services…” In response, the credential cache is simply storage for credentials and would be capable of storing credentials from any cloud-based services. Again, a reference may be understood by the artisan as suggesting a solution to a problem that the reference does not discuss. See KSR, 137, S. Ct. at 1742, 82 USPQ2d at 1397 (“Common sense teaches…that familiar items may have obvious uses beyond their primary purposes, and in many cases a personal of ordinary skill will be able to fit the teachings of multiple patents together like pieces of a puzzle... A person of ordinary skill is also a person of ordinary creativity, not an automaton.").
Applicant argues on page 7 of the response, “The principle of operation in Xu is therefore a zone-based trust architecture…” This argument is not persuasive because Applicant has failed to identify the actual principle of operation in Xu. Instead, the principle of operation in Xu is simply the authentication of service requests and Xu makes it clear in paragraph [0187] that the system is flexible regarding which system element performs the various required functionality.
Applicant’s arguments on pages 7-9 are not persuasive because they are directed to Applicant’s incorrectly identified principle of operation in Xu. Since Applicant has not properly identified the principle of operation in Xu, Applicant has also failed to show that the proposed modification has changed the principle of operation in Xu.
Applicant argues on page 10 of the response, “As shown in FIG. 7 of Xu, the proxy authenticator 710 sits in a perimeter zone 704, and a separate authorization controller 714 sits in a distinct business zone 706. FIG. 8 of Xu further confirms that the authentication token is generated in the high-security zone at step 806 by the authorization controller 714, and not by the proxy authenticator 710.” This argument is not persuasive because Xu discloses that authorization token generation is step 806 in figure 8 ([0190]) and that the aspects of figure 8 can be performed by the authorization controller or the proxy authenticator 710 ([0187]).
Applicant argues on page 12 of the response, “Relocating token generation to Xu’s proxy authenticator is not a design choice available to a person of ordinary skill in the art.” This argument is not persuasive because Xu specifically states that the aspects of figure 8 can be performed by the authorization controller or the proxy authenticator 710 ([0187]) and the aspects of figure 8 include the generation of the authorization token ([0190] & Figure 8, step 806).
Applicant argues on page 14 of the response, “Xu nowhere teaches that the cache stores access credentials for multiple cloud-based service providers, nor that the retrieval from the cache is conditioned on token validation for a particular identified provider.” In response, this argument is repeated from an argument presented earlier and has been fully addressed above.
Applicant argues on page 14 of the response, “Syomichev does not disclose a gateway proxy…” In response, Applicant has failed to fully appreciate the proposed combination of Xu and Syomichev presented in the Non-Final Specifically, the Non-Final makes it clear 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 Non-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 16 of the response, “The proposed modification is not supported by a teaching or suggestion in Xu or Syomichev and instead appears to rely on the Applicant’s amended claim as a guide.” This argument is not persuasive because a reference may be understood by the artisan as suggesting a solution to a problem that the reference does not discuss. See KSR, 137, S. Ct. at 1742, 82 USPQ2d at 1397 (“Common sense teaches…that familiar items may have obvious uses beyond their primary purposes, and in many cases a personal of ordinary skill will be able to fit the teachings of multiple patents together like pieces of a puzzle... A person of ordinary skill is also a person of ordinary creativity, not an automaton."). As stated above, the requests are transmitted and the contents of those requests would be at risk during transmission. The proposed modification elevates the risk of credential exposure during transmission as stated in the Non-Final.
Applicant argues on page 17 of the response, “Blohm does not disclose a robotic processing automation system that supports a plurality of software automation processes…” This argument is not persuasive because Blohm discloses computing devices being implemented as autonomous devices such as robots ([0080]: plural devices specified by Blohm).
Applicant argues on page 17 of the response, “Blohm does not disclose…nor the mediation of that software automation process’s outbound service request at a gateway proxy of the type recited in amended claim 1.” This argument is not persuasive because Applicant has failed to fully consider the proposed modification of Xu as presented in the Non-Final. Specifically, the proposed modification to Xu is for the client devices of Xu to have been implemented as a robotic autonomous devices 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]).
Applicant argues on page 18 of the response, “The rationale reflects generic device-substitution reasoning, not the articulated rationale supported by factual underpinnings that KSR…require for a legally sound obviousness rejection.” This argument is not persuasive because MPEP 2143 makes it clear that the “obvious to try” rationale comes directly from the KSR decision.
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-6, 9-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, and further in view of Blohm, U.S. Publication No. 2021/0271985. 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. The authorization token can be generated by the proxy authenticator ([0190]: specifies that the authorization controller generates the authorization token but [0187] specifies that the aspects of figure 8 can be performed by the authorization controller or the proxy authenticator) in response to receiving an authorization request from the client ([0188]) and authenticating, by the proxy authenticator, credentials included in the authorization request ([0189]: describes the authorization controller performing the authentication, but ([0187] specifies that the aspects of figure 8 can be performed by the authorization controller or the proxy authenticator) such that the proxy authenticator provides the authorization token to the client ([0192]), which meets the limitation of wherein the authentication token is generated at the gateway proxy in response to validating an access identifier of the local processing agent and is provided from the gateway proxy to the local processing agent.
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]).
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 [software automation process supported by a robotic processing automation system, the robotic processing automation system supporting a plurality of software automation processes].
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 software automation process supported by a robotic processing automation system, the robotic processing automation system supporting a plurality of software automation processes. 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 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 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 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. The authorization token can be generated by the proxy authenticator ([0190]: specifies that the authorization controller generates the authorization token but [0187] specifies that the aspects of figure 8 can be performed by the authorization controller or the proxy authenticator) in response to receiving an authorization request from the client ([0188]) and authenticating, by the proxy authenticator, credentials included in the authorization request ([0189]: describes the authorization controller performing the authentication, but ([0187] specifies that the aspects of figure 8 can be performed by the authorization controller or the proxy authenticator) such that the proxy authenticator provides the authorization token to the client ([0192]), which meets the limitation of wherein the authentication token is generated at the gateway proxy in response to validating an access identifier of the local processing agent and is provided from the gateway proxy to the local processing agent.
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]).
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 [software automation process supported by a robotic processing automation system, the robotic processing automation system supporting a plurality of software automation processes].
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 software automation process supported by a robotic processing automation system, the robotic processing automation system supporting a plurality of software automation processes. 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 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.
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]).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
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: 5:30-4:00.
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
Prosecution Insights