DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Applicant's amendments filed on 02/09/2026 has been received and entered. Currently Claims 1-19 and 21 are pending.
Response to Arguments
Applicant argues on pages 9-11 of applicant’s remarks that no combination of the cited art teaches or suggests an embodiment in which a provider-managed orchestration engine programmatically establishes trust between a customer-controlled identity service and an endpoint, while authorization decisions are independently determined at the endpoint without delegation to the orchestration engine or to a centralized authorization service.
The examiner respectfully disagrees. The examiner refers to the below 103 rejection of the claims. In particular Lukanov teaches establishing trust between identity providers and a deployed appliance ([0030], [0035], [0039]). Lukanov further teaches deployed appliance authenticate user based on user token of the identity provider, via trust with the identity provider ([0041]-[0043]). Therefore, Lukanov teaches limitations of the claims.
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.
Claims 1, 3, 5-12, 14-19 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Field et al. USPN 8,850,546 (hereinafter Field), in view of Lukanov et al. US 2023/0353557 (hereinafter Lukanov).
As per claim 1, Field teaches a method for facilitating authentication and authorization in a computing system configured to provide at least one service, the method comprising: accessing a customer identity service associated with a customer, wherein the customer identity service is a customer-controlled identity authority for the customer and is configured to authenticate an identity of a user (Field Fig. 1, Fig. 5, col 5 line 65 – col 6 line 40, accessing enterprise identity provider wherein the identity provider is configured to authenticate a user);
accessing an endpoint of a provider, the endpoint being configured to expose a service or resource to the customer (Field Fig. 1, Fig. 5, col 3 lines 55-65, col 11 lines 30-35, accessing application resources).
Field does not explicitly disclose accessing an orchestration engine of a provider, wherein the orchestration engine is configured to establish trust between endpoint and customer identity service, and wherein the trust enables the endpoint to rely on an authentication of the user's identity performed by the customer identity service;
causing the orchestration engine to establish the trust between the endpoint and the customer identity service;
configuring the endpoint with federated authentication such that the endpoint is configured to rely on the authentication of the user's identity performed by the customer identity service, said relying being permitted as a result of the trust that was previously established between the endpoint and the customer identity service by the orchestration engine, and
causing the endpoint to independently determine whether a request by the user is authorized, without delegation of authorization decisions to the orchestration engine or to a centralized authorization service.
Lukanov teaches accessing an orchestration engine of a provider, wherein the orchestration engine is configured to establish trust between endpoint and customer identity service, and wherein the trust enables the endpoint to rely on an authentication of the user's identity performed by the customer identity service (Lukanov paragraph [0030], [0035], [0039], establish trust between the identity provider and the deployed appliance);
causing the orchestration engine to establish the trust between the endpoint and the customer identity service (Lukanov paragraph [0030], [0035], [0039], establish trust between the identity provider and the deployed appliance);
configuring the endpoint with federated authentication such that the endpoint is configured to rely on the authentication of the user's identity performed by the customer identity service, said relying being permitted as a result of the trust that was previously established between the endpoint and the customer identity service by the orchestration engine (Lukanov paragraph [0030], [0035], [0037], [0039], establish trust between the identity provider and the deployed appliance. Rely on authentication of the user performed by the identity provider), and
causing the endpoint to independently determine whether a request by the user is authorized, without delegation of authorization decisions to the orchestration engine or to a centralized authorization service (Lukanov paragraph [0041]-[0043], deployed appliance authenticate user based on user token of the identity provider, via trust with the identity provider).
Thus it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Field of deployed cloud endpoints with application resources/services with the teachings of Lukanov to include establishing trust between the identity provider and the deployed appliance in order to establish individual trusts between the enterprise identity provider and the cloud endpoints and to allow the cloud endpoints to authenticate users.
As per claim 3, Field in view of Lukanov teaches the method of claim 1, further comprising providing endpoint credentials to the customer identity service to the endpoint (Field Fig. 1, Fig. 5, col 5 line 65 – col 6 line 5, trust relationship is established between enterprise identity provider and the cloud service provider component by exchanging certificates. Fig. 1, Fig. 5, col 3 lines 55-65, col 11 lines 30-35, application resources in the cloud; Lukanov paragraph [0030], [0035], establish trust between the identity provider and the deployed appliance).
As per claim 5, Field in view of Lukanov teaches the method of claim 1, further comprising authenticating the user associated with the customer, wherein the orchestration engine brokers authentication of the user when the user signs into the computing system using a single sign-on verified by the customer identity service (Field Fig. 1, Fig. 5, col 5 line 50 – col 8 line 50, col 11 line 15- col 12 line 5, authenticate a user based on external token generated by the enterprise identity provider and grant user access to the requested resource; Lukanov paragraph [0041]-[0043]).
As per claim 6, Field in view of Lukanov teaches the method of claim 1, further comprising receiving a command from the user via a browser, wherein the endpoint receives a token associated with the user and verifies the identity of the user with the customer identity service (Field Fig. 1, Fig. 5, col 5 line 50 – col 8 line 50, col 11 line 15- col 12 line 5, user request for resource includes external token generated by the enterprise identity provider. Authenticate the user based on external token and grant user access to the requested resource.; Lukanov paragraph [0030], [0035]).
As per claim 7, Field in view of Lukanov teaches the method of claim 6, wherein the endpoint generates an authorization token that is associated with the user (Field Fig. 1, Fig. 5, col 4 lines 22-30, col 6 lines 65-67, generate internal token; Lukanov paragraph [0041]-[0043], authentication token).
As per claim 8, Field in view of Lukanov teaches the method of claim 7, further comprising performing the command, wherein the endpoint determines whether the command is authorized in the authorization token such that access control autonomy is held by the endpoint and wherein the customer identity service is a sole source of ground truth with respect to the customer and the computing system (Field Fig. 1, Fig. 5, col 5 line 50 – col 8 line 50, col 11 line 15- col 12 line 5, Authenticate the user based on external token generated by the enterprise identity provider, generate internal token, verify and grant user access to the requested resource based on internal token; Lukanov paragraph [0030], [0035], [0041]-[0043], deployed appliance authenticate user based on user token of the identity provider, via trust with the identity provider).
As per claim 9, Field in view of Lukanov teaches the method of claim 1, wherein multiple endpoints associated with the customer are deployed in the computing system and wherein each of the multiple endpoints has its own access control autonomy (Field Fig. 1, Fig. 5, col 3 lines 55-65, col 5 line 50 – col 8 line 50, col 11 line 15- col 12 line 5, plurality of application resources in the cloud; Lukanov paragraph [0029], [0030], [0035], deploy and establish trust between the identity provider and a plurality of appliances).
As per claim 10, Field in view of Lukanov teaches the method of claim 1, further comprising authenticating an application with the customer identity service and receiving a script associated with the application (Field Fig. 1, Fig. 5, col 5 line 50 – col 8 line 50, col 11 line 15- col 12 line 5, non-browser user request for resource includes external token generated by the enterprise identity provider. Authenticate the user based on external token and grant user access to the requested resource.).
As per claim 11, Field in view of Lukanov teaches the method of claim 10, further comprising exchanging an authorization token of the application for an authorization token of the endpoint and performing the script at the endpoint when allowed by the authorization token issued by the endpoint (Field Fig. 1, Fig. 5, col 5 line 50 – col 8 line 50, col 11 line 15- col 12 line 5, Authenticate non-browser user based on external token generated by the enterprise identity provider, generate internal token, verify and grant user access to the requested resource based on internal token; Lukanov paragraph [0041]-[0043], authentication token).
As per claims 12, 14-19 and 21, the claims claim a non-transitory storage medium and a system essentially corresponding to the method claims 1, 3, 5-11 above, and they are rejected, at least for the same reasons.
Claims 2, 4 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Field in view of Lukanov, and further in view of Jain et al. US 2022/0159083 (hereinafter Jain).
As per claim 2, Field in view of Lukanov teaches the method of claim 1, wherein users associated with the customer are able to access the endpoint using credentials verified by the customer identity service (Field Fig. 1, Fig. 5, col 6 lines 25-40, col 6 line 50 – col 7 line 25, col 8 lines 48-55, col 11 line 15 – col 12 line 5, user request for resource includes external token generated by the enterprise identity provider).
Field in view of Lukanov does not explicitly disclose using on day 0 of a deployment.
Jain teaches using on day 0 of a deployment (Jain paragraph [0033], zero day, zero touch deployment of applications/services).
Thus it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Field in view of Lukanov of deploying endpoints of applications/services at the cloud provider with the teachings of Jain to include zero day, zero touch deployment of applications/services in order to allow for minimal to no manual configuration of the deployment and to allow the deployed endpoint to be usable at day 0.
As per claim 4, Field in view of Lukanov teaches the method of claim 1, wherein the trust between the endpoint and the customer identity service is established (Field Fig. 1, Fig. 5, col 5 line 65 – col 6 line 5, trust relationship is established between enterprise identity provider and the cloud service provider component by exchanging certificates. Fig. 1, Fig. 5, col 3 lines 55-65, col 11 lines 30-35, application resources in the cloud; Lukanov paragraph [0030], [0035], establish trust between the identity provider and the deployed appliance).
Field in view of Lukanov does not explicitly disclose established programmatically.
Jain teaches established programmatically (Jain paragraph [0033], zero day, zero touch deployment of applications/services).
Thus it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Field in view of Lukanov of deploying endpoints of applications/services at the cloud provider with the teachings of Jain to include zero day, zero touch deployment of applications/services in order to allow for minimal to no manual configuration of the deployment and to allow the deployed endpoint to be usable at day 0.
As per claim 13, the claim claims a non-transitory storage medium essentially corresponding to the method claims 2 and 4 above, and is rejected, at least for the same reasons.
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 HENRY TSANG whose telephone number is (571)270-7959. The examiner can normally be reached M-F 9am - 5pm EST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Farid Homayounmehr can be reached at (571) 272-3739. 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.
/HENRY TSANG/ Primary Examiner, Art Unit 2495
Prosecution Insights