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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 10/01/2024 was filed. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 4-22 of U.S. Patent No.12137091. Although the claims at issue are not identical, they are not patentably distinct from each other.
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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Pub.No.: US 2018/0012012 A1 to Stone in view of Pub.No.: US 2017/0331829 A1 to LANDER et al(hereafter referenced as Lander).
Regarding claim 1, Stone discloses “a computer-implemented method comprising: creating, by a first server(web server [Fig.1/item 130]), a Single Sign-On (SSO) session for a user; storing, by the first server, session information associated with the SSO session(policy server 170 or other suitable authentication server may return a single sign - on ( SSO ) authentication token to the client device 110 [par.0025]), “the session information including a session identifier(key Store [Fig.1/190]) ; based on the session identifier (the single - sign - on authentication state token comprises an embedded validity parameter that links the single - sign on authentication state token to a session identifier that identifies a network communication session [par.0005]).
Stone does not explicitly disclose “and sending, by the first server, the session identifier to an application, wherein the application sends an access token request including the session identifier to a second server, the second server retrieves the session information based on the session identifier, the second server uses the session information to determine that the SSO session is valid, the second server generates an access token in response to determining that the SSO session is valid, where the access token provides access to a protected resource, and wherein the second server sends the access token to the application to enable the application to use the access token for accessing the protected resource.”
However, Lander in an analogous art discloses “and sending, by the first server, the session identifier to an application, wherein the application sends an access token request including the session identifier(applications can retrieve discovery documents by being configured with a single IDCS URL Lander [par.0071]) to a second server (Chief server Lander [Fig.9]), “the second server retrieves the session information based on the session identifier”(client identifier Lander [par.0158]) , “the second server uses the session information to determine that the SSO session is valid, the second server generates an access token in response to determining that the SSO session is valid, where the access token provides access to a protected resource” (client 708 ( e . g . , mobile , web apps , JavaScript , etc. . ) presents an access token ( issued by IDCS ) to use with a protected REST API 714 , Cloud Gate 702 validates the access token before allowing access to the API Lander[par.0120]), “and wherein the second server sends the access token to the application to enable the application to use the access token for accessing the protected resource” (Cloud Gate 702 validates the access token before allowing access to the API Lander[par.0120]).
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was filed to modify Stone’s system for controlling tokens with Lander’s security tokens within a multi-tenant environment in order to provide additional security. One of ordinary skill would have been motivated to combine because Stone discloses a process to control tokens, Stone also disclose a process to access tokens within a multi-tenant environment, and both are from the same field of endeavor.
Regarding claim 2 in view of claim 1, the references combined disclose “wherein the second server determines that the SSO session is valid at least by determining a session expiration time based on the session information, and determining that the session expiration time has not yet been reached.” (other string sequences that define control parameters associated with the state token , wherein the parameters may include an expiration date , a restriction on domain names or resources that can receive the state token , or other suitable control parameters Stone[par.0022]).
Regarding claim 3 in view of claim 1, the references combined disclose “wherein the second server determines that the SSO session is valid at least by determining a timeout duration based on the session information, and determining that the SSO session has not timed out based upon the timeout duration.” (other string sequences that define control parameters associated with the state token , wherein the parameters may include an expiration date , a restriction on domain names or resources that can receive the state token , or other suitable control parameters Stone[par.0022]).
Regarding claim 4 in view of claim 1, the references combined disclose “wherein the session information includes an association between the SSO session and the user, and further comprising: generating, by the first server, a user identity token, the user identity token including information identifying the user and the session identifier associated with the SSO session, wherein sending the session identifier to the application includes sending the user identity token to the application”(client 708 ( e . g . , mobile , web apps , JavaScript , etc. . ) presents an access token ( issued by IDCS ) to use with a protected REST API 714 , Cloud Gate 702 validates the access token before allowing access to the API Lander[par.0120]);,
Regarding claim 5 in view of claim 4, the references combined disclose “wherein the access token is different than the user identity token” (IDCS 118 provides a unified view 124 of a user ' s applications including federation services 130 ( e . g SAML ) ,token services 132 ( e . g . , OAuth ) Lander[par.0035]).
Regarding claim 6 in view of claim 4, the references combined disclose “wherein the access token request includes the user identity token, and wherein the second server determines that the SSO session is valid at least by identifying the user associated with the SSO session based on the session information in the user
identity token” (the single - sign - on authentication state token comprises an embedded validity parameter that links the single - sign on authentication state token to a session identifier that identifies a network communication session Stone[par.0005]),, and determining that the user identifying information in the user identity token matches the user associated with the SSO session” (user token that provides the context within the operating system that executes the application 120 , wherein the web server 130 may then use the user token associated with the operating system to control access to the requested information relating to the document Stone[par.0026]).
Regarding claim 7 in view of claim 4, the references combined disclose “wherein the second server generates the access token based on the user identity token, thereby causing the access token to be linked to the SSO session, wherein the application uses the access token to access the protected resource by providing the access token in an access request(the SSO microservice 1112 generates an access token and sends it to Cloud Gate 1104 Lander[par.0173], and wherein the application uses the protected resource to provide application functionality or processes the protected resource to generate graphical output for display on a Web browser (webserver 130 comprising token module configuration module interconnecting with client device web browser 115 Stone[Fig.1]).
Regarding claim 8 in view of claim 4, the references combined disclose “wherein the user identity token is a JavaScript Object Notation (JSON) Web Token, and the access token is an Open Authorization (OAuth) access token” (IDCS 118 provides a unified view 124 of a user ' s applications including federation services 130 ( e . g . , SAML ) , token services 132 ( e . g . , OAuth ) Lander[par.0035]).
Regarding claim 9 in view of claim 8, the references combined disclose “wherein the first server is an access manager that is included in an access management system, and the second server is an Open Authorization (OAuth) server that is included in the access management system. (IDCS 118 provides a unified view 124 of a user ' s applications including federation services 130 ( e . g SAML ) , token services 132 ( e . g . , OAuth ) Lander[par.0035]).
Regarding claim 10 in view of claim 1, the references combined disclose “further comprising: sending, to the application, a request for user credentials; receiving, from the application, the user credentials; and authenticating the user based on the user credentials, wherein creating the SSO session for the user is in response to a successful authentication” (policy server 170 or other suitable authentication server may return a single sign - on ( SSO ) authentication token to the client device 110 [par.0025]),
Regarding claim 11, Stone discloses “a computer system comprising: one or more processors; and a memory coupled to the one or more processors, the memory storing instructions that, when executed by the one or more processors, cause the one or more processors to: create a Single Sign-On (SSO) session for a user; store session information associated with the SSO session(policy server 170 or other suitable authentication server may return a single sign - on ( SSO ) authentication token to the client device 110 [par.0025]), the session information including a session identifier(key Store [Fig.1/190]) ; based on the session identifier (the single - sign - on authentication state token comprises an embedded validity parameter that links the single - sign on authentication state token to a session identifier that identifies a network communication session [par.0005]).
Stone does not explicitly disclose “and send the session identifier to an application, wherein the application sends an access token request including the session identifier to a second server, the second server retrieves the session information based on the session identifier, the second server uses the session information to determine that the SSO session is valid, the second server generates an access token in response to determining that the SSO session is valid, where the access token provides access to a protected resource, and wherein the second server sends the access token to the application to enable the application to use the access token for accessing the protected resource”
However, Lander in an analogous art discloses “and send the session identifier to an application, wherein the application sends an access token request including the session identifier(applications can retrieve discovery documents by being configured with a single IDCS URL Lander [par.0071]) to a second server(Chief server Lander [Fig.9]),, the second server retrieves the session information based on the session identifier(client identifier Lander [par.0158]), the second server uses the session information to determine that the SSO session is valid, the second server generates an access token in response to determining that the SSO session is valid, where the access token provides access to a protected resource(client 708 ( e . g . , mobile , web apps , JavaScript , etc. . ) presents an access token ( issued by IDCS) to use with a protected REST API 714 , Cloud Gate 702 validates the access token before allowing access to the API Lander[par.0120]), “and wherein the second server sends the access token to the application to enable the application to use the access token for accessing the protected resource” (Cloud Gate 702 validates the access token before allowing access to the API Lander[par.0120]).
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was filed to modify Stone’s system for controlling tokens with Lander’s security tokens within a multi-tenant environment in order to provide additional security. One of ordinary skill would have been motivated to combine because Stone discloses a process to control tokens, Stone also disclose a process to access tokens within a multi-tenant environment, and both are from the same field of endeavor.
Regarding claim 12 in view of claim 11, the references combined disclose “wherein the session information includes an association between the SSO session and the user, and wherein the instructions, when executed by the one or more processors, further cause the one or more processors to: generate a user identity token including information identifying the user and the session identifier associated with the SSO session, wherein sending the session identifier to the application includes sending the user identity token to the application. (Cloud Gate 502 is a component that secures access to multi - tenant IDCS microservices by ensuring that client applications provide valid access tokens , and / or users successfully authenticate in order to establish SSO sessions Lander[par.0049]).
Regarding claim 13 in view of claim 12, the references combined disclose “wherein sending the user identity token to the application includes sending a session cookie including the user identity token or sending a token response with a header including the user identity token” (client device 125 returns a cookie or other state token , the HTTP Cookie specification lacks any built - in mechanisms to secure the information contained in the cookie or other state token to maintain the state information Stone[par.0021]).
Regarding claim 14 in view of claim 12, the references combined disclose “wherein the access token request includes the user identity token( operation 320 may uniquely identify a user or other identity associated with the request or the communication session ( e . g . , a single - sign on identity token , a digital signature , or any other suitable token Stone[par.0033]), and the second server determines that the SSO session is valid at least by identifying the user associated with the SSO session based on the session information in the user identity token, and determining that the information identifying the user in the user identity token
matches the user associated with the SSO session” (user token that provides the context within the operating system that executes the application 120 , wherein the web server 130 may then use the user token associated with the operating system to control access to the requested information relating to the document [par.0120]);
Regarding claim 15 in view of claim 12, the references combined disclose “wherein the access token is different than the user identity token. (i.e. identity platform [Fig.1] distinguishes tokens via API token service Lander [Fig.1/item 132]).
Regarding claim 16 in view of claim 11, the references combined disclose
“or more processors to: receive a request from the second server for the session information associated with the session identifier; and provide the session information to the second server. (Chief server Lander [Fig.9]),
Regarding claim 17 in view of claim 16, the references combined disclose
“wherein the computer system is part of a cluster in a data center, and the cluster is associated with a cluster identifier.” (i.e. policy server and web server work in combination Stone[Fig.1]).
Regarding claim 18 in view of claim 17, the references combined disclose
“wherein the second server determines the cluster identifier from the access token request” (i.e. policy server and web server work in combination Stone[Fig.1]).
Regarding claim 19, Stone discloses “A non-transitory computer-readable storage medium storing instructions that, when executed by one or more processors of a computer system, cause the one or more processors to perform processing comprising: creating a Single Sign-On (SSO) session for a user(policy server 170 or other suitable authentication server may return a single sign - on ( SSO ) authentication token to the client device 110 [par.0025]); “storing session information associated with the SSO session(key Store [Fig.1/190]), the session information including a session identifier(the single - sign - on authentication state token comprises an embedded validity parameter that links the single - sign on authentication state token to a session identifier that identifies a network communication session [par.0005]).
Stone does not explicitly disclose “and sending the session identifier to an application, wherein the application sends an access token request including the session identifier to a second server, the second server retrieves the session information based on the session identifier, the second server uses the session information to determine that the SSO session is valid, the second server generates an access token in response to determining that the SSO session is valid, where the access token provides access to a protected resource, and wherein the second server sends the access token to the application to enable the application to use the access token for accessing the protected resource.”
However, Lander in an analogous art discloses “and sending the session identifier to an application, wherein the application sends an access token request including the session identifier to a second server, the second server retrieves the session information based on the session identifier(applications can retrieve discovery documents by being configured with a single IDCS URL Lander [par.0071]), the second server uses the session information to determine that the SSO session is valid(OAuth2 platform service provides token authorization services . It provides a rich API infrastructure for creating and validating access tokens conveying user rights to make API calls Lander [par.0078]), the second server generates an access token in response to determining that the SSO session is valid, where the access token provides access to a protected resource(client 708 ( e . g . , mobile , web apps , JavaScript , etc. . ) presents an access token ( issued by IDCS ) to use with a protected REST API 714 , Cloud Gate 702 validates the access token before allowing access to the API Lander[par.0120]);, and wherein the second server sends the access token to the application to enable the application to use the access token for accessing the protected resource.” (Cloud Gate 702 validates the access token before allowing access to the API Lander[par.0120]).
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was filed to modify Stone’s system for controlling tokens with Lander’s security tokens within a multi-tenant environment in order to provide additional security. One of ordinary skill would have been motivated to combine because Stone discloses a process to control tokens, Stone also disclose a process to access tokens within a multi-tenant environment, and both are from the same field of endeavor.
Regarding claim 20 in view of claim 19, the references combined disclose “wherein the processing further comprises: generating a user identity token including information identifying the user and the session identifier associated with the SSO session(the single - sign - on authentication state token comprises an embedded validity parameter that links the single - sign on authentication state token to a session identifier that identifies a network communication session [par.0005])., wherein sending the session identifier to the application includes sending the user identity token to the application(client 708 ( e . g . , mobile , web apps , JavaScript , etc. . ) presents an access token ( issued by IDCS ) to use with a protected REST API 714 , Cloud Gate 702 validates the access token before allowing access to the API Lander[par.0120]), wherein the access token request includes the user identity token, and wherein the second server generates the access token based on the user identity token, thereby causing the access token to be linked to the SSO
Session” (the SSO microservice 1112 generates an access token and sends it to Cloud Gate 1104 Lander[par.0173]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL D ANDERSON whose telephone number is (571)270-5159. The examiner can normally be reached Mon-Fri 9am-6pm.
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, Jeffrey Pwu can be reached at (571) 272-6798. 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.
/MICHAEL D ANDERSON/Examiner, Art Unit 2433
/JEFFREY C PWU/Supervisory Patent Examiner, Art Unit 2433