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 01/06/2026 has been entered.
Response to Amendment
Applicant arguments filed 12/19/2025, with respect to objections to the claims have been fully considered, and the objections have been withdrawn. However, additional claim objections arise in view of the amendments.
Response to Arguments
Applicant’s arguments filed 12/19/2025, with respect to the rejections of independent claims 1 and 11 and their respective corresponding dependent claims under 35 USC 103 have been fully considered and are persuasive. Therefore, the rejections have been withdrawn. However, upon further consideration, new grounds of rejection are made in view of the previously applied references from Maria, Dungen, and Martynov, in addition to a newly applied reference Tran (US 20210021995 A1), hereinafter Tran. The Tran will be relied upon herein to teach the newly added limitations in addition to limitations previously taught by Frederick. Specifically, Tran teaches “combining … the user token and the service token into a single access token comprising both a user profile associated with the user token and a service profile associated with the service token”; and “wherein the access token is usable by the first service to gain access to the second service upon successful authentication, by the second service, of both (1) the user that invoked the containerized application for the execution of the function, and (2) the first service that was used to call the second service, and wherein authenticating both the user and the first service is performed via the single access token, where the user is authenticated via the user profile included in the single access token and the first service is authenticated via the service profile included in the single access toke, resulting in an enforcement of dual authorization”.
Claim Objections
Claims 1 and 11 are objected to because of the following informalities:
In lines 15, 16, 20-21, and 22 of Claim 1, the limitation(s) “the access token” should read: “the single access token” for consistency with the antecedent basis of the single access token established earlier in the claim
In line 28 of Claim 1, the limitation “the single access toke” should read: “the single access token”
Claim 11 includes similar limitations and is objected to for the same reasons as Claim 1
Appropriate correction is required.
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.
Claim(s) 1, 2, 4-8, 11, 12, and 14-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Maria et al. (US 20190372962 Al), hereafter Maria, in view of Dungen et al. (US 20180115542 A1), hereinafter Dungen, Tran (US 20210021995 A1), hereinafter Tran, and Martynov et al. (US 20200059360 A1), hereinafter Martynov.
Regarding Claim 1:
Maria teaches a method comprising: when an identity and access management module authorizes a user, sending, by the identity and access management module, a user token to a containerized application (Maria – Paragraph [0072]: FIG. 3 is a flowchart of a method 300 for generating a user identity token, in accordance with an embodiment. The method 300 can be performed by an access manager, such as the access manager 130 of FIG. 1. At step 310, the access manager receives an authentication request from an application [0073] At step 312, the access manager receives one or more user credentials from the user [0074] At step 314, the access manager authenticates the user using the one or more user credentials received in step 312 [0076] At step 318, the access manager generates, as part of the session creation, a user identity token including a session ID that identifies the session [0078] At step 322, the access manager sets or sends the session cookie(s) along with the user identity token for the application to use in the future (e.g., as part of an access token request). The user identity token can be sent as a cookie or in a header of a token response. For example, if the application accepts SSO cookies, the access manager may send the user identity token along with the SSO cookie in a cookie package); sending, by the containerized application, the user token to a first service (Maria – Paragraph [0078]: The application can subsequently present the user identity token when it needs access to a protected resource for which an access token is required. The user identity token may be shared with other applications that support SSO so that the other applications can also present the user identity token in connection with an access token request [0086] In certain embodiments, server 512 may also provide other services or software applications that can include non-virtual and virtual environments. In some embodiments, these services may be offered as Web-based or cloud services or under a Software as a Service (SaaS) model to the users of client computing devices 502, 504, 506, and/or 508); receiving, by the identity and access management module, a request from the first service to validate the user token, [wherein the request includes a service token for a second service needed by the containerized application for execution of a function] (Maria – Paragraph [0079]: At step 410, the access management system receives an access token request from an application. For example, the access token request may be sent to the OAuth server 140 in response to an access request for a resource protected by the OAuth server 140 and for which an access token is required. The access token request includes information identifying a session created prior to generation of the access token request. For example, the information identifying the session may include a session ID contained within a user identity token (e.g., a JWT) that was previously generated in connection with SSO authentication of the user; and Paragraph [0080]: For example, in certain embodiments, the OAuth server 140 may parse a user identity token to determine the session ID of an SSO session created by an access manager; and Paragraph [0086]: In certain embodiments, server 512 may also provide other services or software applications that can include non-virtual and virtual environments. In some embodiments, these services may be offered as Web-based or cloud services or under a Software as a Service (SaaS) model to the users of client computing devices 502, 504, 506, and/or 508); performing, by the identity and access management module, a validation process on the user token (Maria – Paragraph [0081]: At step 414, the access management system determines, using the session information retrieved in step 412, whether the session is valid. In particular, the session may be validated by performing one or more of the checks described earlier. For example, if the information
identifying the session is provided in a user identity token, the OAuth server 140 may determine whether the user identified in the user identity token matches the user associated with the session, e.g., based on a comparison between a subject field in the user identity token and a subject of the session); when the validation process is successful, [combining], by the identity and access management
module, [the user token and the service token into] a single access token (Maria – Paragraph [0081]: At step 414, the access management system determines, using the session information retrieved in step 412, whether the session is valid ... The validation of the session may involve communicating with the
access manager that created the session (e.g., to request that the checks be performed by the access manager on behalf of the OAuth server). If the session is determined to be invalid for any reason, the access token request is denied and no access token is generated. However, if the session is determined to be valid, the method proceeds to step 416; and Paragraph [0082]: At step 416, the access management system generates an access token for the user (e.g., using the access token generator 144 in OAuth server 140). The access token is generated in response to a determination in step 414 that the session is valid); and transmitting, by the identity and access management module to the first service, the access token (Maria – Paragraph [0083]: At step 418, the access management system sends the access token to the application for storage and Paragraph [0086]: In certain embodiments, server 512 may also provide other services or software applications that can include non-virtual and virtual environments. In some embodiments, these services may be offered as Web-based or cloud services or under a Software as a Service (SaaS) model to the users of client computing devices 502, 504, 506, and/or 508).
Maria does not expressly teach [receiving, by the identity and access management module, a request from the first service to validate the user token,] wherein the request includes a service token for a second service needed by the containerized application for execution of a function.
However, Dungen teaches receiving, by the identity and access management module, a request from the first service to validate the user token, wherein the request includes a service token for a second service needed by the containerized application for execution of a function (Dungen – Paragraph [0025]: Returning to FIG. 5, in act 504, the facility calls the back-end service for a request 451 that corresponds to the client request 431, including both the user token and the service token; and Paragraph [0016]: When the front-end service is called by the client with a first token denoting the user's entitlement to use the application (“user token”), the front-end service uses its own credentials to request a second token for accessing the back-end service (“service token”)).
Dungen further teaches performing, by the identity and access management module, a validation process on the user token (Dungen – Figs. 5, 6, and 8; and Paragraph [0023]: FIG. 5 is a flow diagram showing a process performed by the facility in some embodiments in the first approach in the front-end service. In act 501, the facility receives the client request 431 containing the user token. In act 502, the facility evaluates the application token; if it is unmodified and unexpired, and identifies the front-end service in its audience field, the facility continues in act 503, else the facility returns an error. In act 503, the facility uses credentials of the front-end service to obtain a second, “service token” token whose audience is the back-end service; and Paragraph [0028]: In act 602, the facility evaluates the user token; if the user token identifies the front-end service as its audience and is unmodified and unexpired, then the facility continues in act 603, else the facility returns an error; and Paragraph [0033]: FIG. 8 is a flow diagram showing a process performed by the facility in some embodiments in the second approach in the front-end service. In act 801, the facility receives the client request 721 in the front-end service. In act 802, the facility evaluates the user token received in the client request; if it identifies the front-end service in its audience field, and is unmodified and unexpired, then the facility continues in act 803, else the facility returns an error).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Maria, further incorporating Dungen to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Dungen’s teaching of user-specific and service-specific token for verification into Maria’s method for user access management. The incorporation of a service token in a request to validate a user token for authorized access of the service enhances the security of Maria’s method.
The combination of Maria and Dungen does not expressly teach combining, by the identity and access management module, the user token and the service token into a single access token comprising both a user profile associated with the user token and a service profile associated with the service token); and wherein the access token is usable by the first service to gain access to the second service upon successful authentication, by the second service, of both (1) the user that invoked the containerized application for the execution of the function, and (2) the first service that was used to call the second service, and wherein authenticating both the user and the first service is performed via the single access token, where the user is authenticated via the user profile included in the single access token and the first service is authenticated via the service profile included in the single access toke, resulting in an enforcement of dual authorization.
However, Tran teaches combining … the user token and the service token into a single access token comprising both a user profile associated with the user token and a service profile associated with the service token (Tran – Paragraph [0040]: At runtime, the first application 108 receives an invocation request, which can be an HTTP POST request f_1. The first application 108, acting as a gateway, requests an initial token 124. The initial token 124 can have a JWT format, and is provided by a user authentication service. The initial token 124 can include information of an authenticated user; and Paragraph [0045]: The first application 108 invokes the second application 110 by sending an invocation request downstream to the second application 110. During the invocation, the first application 108 propagates an invocation context in the invocation request. Propagating the invocation context includes wrapping a token receive by the first application in another token that describes the invocation to be performed. In this example, the first application 108 wraps the received initial token 124 in a first authentication token 126 generated by the first application 108. The wrapping includes designating the initial token 124 as a part of the first authentication token 126); and wherein the access token is usable by the first service to gain access to the second service upon successful authentication, by the second service, of both (1) the user that invoked the containerized application for the execution of the function, and (2) the first service that was used to call the second service, and wherein authenticating both the user and the first service is performed via the single access token, where the user is authenticated via the user profile included in the single access token and the first service is authenticated via the service profile included in the single access toke, resulting in an enforcement of dual authorization (Tran – Paragraph [0046]: The second application 110 receives the first authentication token 126 associated with an invocation request generated by the first application 108. The second application 110 authenticates the invocation request using the first authentication token 126; and Paragraph [0057]: The second application program 110, in response to receiving the invocation request from the first application program 108 for POST/f_2, inspects the first authentication token 126 to verify that the intent of the first authentication token 126 corresponds to the operation to be performed. The second application program 110 inspects the audience claim and request claim. The second application 110 identifies its virtual hostname in the audience claim. The second application 110 determines that the request claim unambiguously describes the invocation request received by the second application 110. The second application 110 may also ensure that a user initiating the chain of calls is authorized to perform this action, by examining the scope claim of the initial token 124; and Figure 6: an example process of invocation path authentication; and Paragraph [0088]: The midstream application receives (602) a first invocation request from an upstream application. The first invocation request is associated with a first token signed by a first private key of the upstream application … The first token includes an initial token including credentials of a user initiating the chain of invocation requests; and Paragraph [0089]: The midstream application authenticates (604) the first invocation request. The midstream application performs the authentication on the first token using the corresponding public key stored in a service registry. The midstream application performs the authentication on the initial token).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Maria and Dungen, further incorporating Tran to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Tran’s teaching of layered composite tokens for authentication as application invocation requests progress down an invocation path into Maria and Dungen’s method for user access management. This addition enhances the security of the method by ensuring that unauthorized users/services will not be granted access to services they may not be entitled to in their own right, while preserving operational efficiency by minimizing token exchanges.
The combination of Maria, Dungen, and Tran does not expressly teach further performing by the identity and access management module: digitally signing the access token; and encrypting the access token, after it has been digitally signed, using a public-private key combination wherein a first key of the public-private key combination is held by the first service, and a second key of the public-private key combination is held by a token adapter of the identity and access management module.
However, Martynov teaches further performing by the identity and access management module: digitally signing the access token (Paragraph [0027]: The authentication token is a JSON Web Token (JWT) signed by the SSA service 230 using its own private key according to one embodiment. The private key for the SSA service may be abbreviated herein as “PrSS.” JWT is a compact URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is digitally signed using JSON Web Signature (JWS)); and encrypting the access token, after it has been digitally signed (Paragraph [0061]: The SSA service 230 can be highly secure by design, for the following reasons. First, the SSA system 230 can use RSA signed JWT tokens, which means only the SSA service 230 can issue authentication tokens as long as its RSA private key is not compromised. Second, the authentication tokens have limited lifespan, so in case an authentication token is compromised, the time window during which the authentication token might be useful is limited in duration. Third, the authentication tokens can be RSA-encrypted during delivery from the SSA service 230 to the micro service 250, 260 being authenticated), using a public-private key combination wherein a first key of the public-private key combination is held by the first service, and a second key of the public-private key combination is held by a token adapter of the identity and access management module (Martynov – Paragraph [0061]: The SSA service 230 can be highly secure by design … the authentication tokens can be RSA-encrypted during delivery from the SSA service 230 to the micro service 250, 260 being authenticated. The RSA private key used to decrypt the authentication token is unique per client service instance. This feature mitigates the risk of an authentication token being intercepted in transit; and Paragraph [0023]: The SSA system may also include a backend database 132 for storing data used to operate the SSA system, such as encryption keys, secret codes, configuration information, deployment information, service information, and other data, as will be described further below).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Maria, Dungen, and Tran, further incorporating Martynov to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Martynov’s teaching to digitally sign and encrypt service authentication tokens into Maria, Dungen, and Tran’s method for user access management. This combination would provide additional security for the tokens being used to authenticate services to other required services by protecting their integrity and confidentiality from unauthorized parties.
Regarding Claim 2:
The combination of Maria, Dungen, Tran, and Martynov teaches the method of claim 1.
Maria further teaches wherein the request is associated with the user token and an application programming interface (API) call received by the first service from the containerized application (Maria – Paragraph [0079]: At step 410, the access management system receives an access token request from an application. For example, the access token request may be sent to the OAuth server 140 in response to an access request for a resource protected by the OAuth server 140 and for which an access token is required. The access token request includes information identifying a session created prior to generation of the access token request. For example, the information identifying the session may include a session ID contained within a user identity token (e.g., a JWT) that was previously generated in connection with SSO authentication of the user; and Paragraph [0080]: For example, in certain embodiments, the OAuth server 140 may parse a user identity token to determine the session ID of an SSO session created by an access manager; and Paragraph [0086]: In certain embodiments, server 512 may also provide other services or software applications that can include non-virtual and virtual environments. In some embodiments, these services may be offered as Webbased or cloud services or under a Software as a Service (SaaS) model to the users of client computing devices 502, 504, 506, and/or 508; and Paragraph [0046]: The application 125 may send the user identity token to the OAuth server 140 using, for example, REST API calls).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 4:
The combination of Maria, Dungen, Tran, and Martynov teaches the method of claim 1.
Maria further teaches wherein, prior to receipt of the request, the identity and access management module performs a user authentication process at a request of an application that has received an access request from a user (Maria – Paragraph [0072]: FIG. 3 is a flowchart of a method 300 for generating a user identity token, in accordance with an embodiment. The method 300 can be performed by an access manager, such as the access manager 130 of FIG. 1. At step 310, the access manager receives an authentication request from an application. The authentication request may have been triggered by a user's request to access a resource protected by the access manager, and may have been sent to the access manager by an access management agent (e.g., the access management agent 122) that intercepted the access request; and Paragraph [0073] At step 312, the access manager receives one or more user credentials from the user; and Paragraph [0074]: At step 314, the access manager authenticates the user using the one or more user credentials received in step 312; and Paragraph [0076]: At step 318, the access manager generates, as part of the session creation, a user identity token including a session ID that identifies the session; and Paragraph [0078]: At step 322, the access manager sets or sends the session cookie(s) along with the user identity token for the application to use in the future (e.g., as part of an access token request). The user identity token can be sent as a cookie or in a header of a token response. For example, if the application accepts SSO cookies, the access manager may send the user identity token along with the SSO cookie in a cookie package).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 5:
The combination of Maria, Dungen, Tran, and Martynov teaches the method of claim 4.
Maria further teaches wherein the request by the application includes the user token (Maria – Paragraph [0072]: FIG. 3 is a flowchart of a method 300 for generating a user identity token, in accordance with an embodiment. The method 300 can be performed by an access manager, such as the access manager 130 of FIG. 1. At step 310, the access manager receives an authentication request from an application. The authentication request may have been triggered by a user's request to access a resource protected by the access manager, and may have been sent to the access manager by an access management agent (e.g., the access management agent 122) that intercepted the access request; and Paragraph [0073]: At step 312, the access manager receives one or more user credentials from the user; and Paragraph [0074]: At step 314, the access manager authenticates the user using the one or more user credentials received in step 312; and Paragraph [0076]: At step 318, the access manager generates, as part of the session creation, a user identity token including a session ID that identifies the session; and Paragraph [0078]: At step 322, the access manager sets or sends the session cookie(s) along with the user identity token for the application to use in the future (e.g., as part of an access token request). The user identity token can be sent as a cookie or in a header of a token response. For example, if the application accepts SSO cookies, the access manager may send the user identity token along with the SSO cookie in a cookie package).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 6:
The combination of Maria, Dungen, Tran, and Martynov teaches the method of claim 1.
Maria further teaches wherein the user token previously included the user profile (Maria – Paragraph [0054]: At step 222, the session engine creates a user identity token (e.g., user identity token 162). The user identity token can be created along with the session and, in some embodiments, is a JWT. Tokens can include one or more claims, which are assertions that an entity makes about itself or another entity. In particular, the user identity token can include one or more claims that identify the user for whom the session was created, hence the label “user identity” token. For example, the user information may be contained in a subject field of the user identity token. In certain embodiments, the user identity token is a JWT that includes a session ID as part of its claims. The session ID included in the user identity token corresponds to the session ID for the session created in step 220).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 7:
The combination of Maria, Dungen, Tran, and Martynov teaches the method of claim 1.
Dungen further teaches wherein the service token previously included the service profile (Dungen – Paragraph [0016]: the front-end service uses its own credentials to request a second token for accessing the back-end service (“service token”); and Paragraph [0017]: In the back-end service, the facility determines whether the service token is unexpired, unmodified, and identifies the back-end device as its audience).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 8:
The combination of Maria, Dungen, Tran, and Martynov teaches the method of claim 1.
Maria further teaches wherein the identity and access management module validation process comprises checking the user token to determine if the user token is expired (Maria – Paragraph [0081]: At step 414, the access management system determines, using the session information retrieved in step 412, whether the session is valid. In particular, the session may be validated by performing one or more of the checks described earlier. For example, if the information identifying the session is provided in a user identity token, the OAuth server 140 may determine whether the user identified in the user identity token matches the user associated with the session, e.g., based on a comparison between a subject field in the user identity token and a subject of the session. The validation of the session may involve communicating with the access manager that created the session (e.g., to request that the checks be performed by the access manager on behalf of the OAuth server). If the session is determined to be invalid for any reason, the access token request is denied and no access token is generated; and Paragraph [0062]: Session management-related checks can also be performed as part of session validation. Such checks may include, for example, determining whether a session expiration time has been reached and whether the session has timed out. For example, if the session has been idle for more than some configured value (e.g., an idle timeout of 15 minutes), when the user identity token is checked for validity the check will fail because the rules of the session are also applied to the access token being requested. If the user identity token is invalid, no access token will be generated).
Regarding Claim 11:
Claim 11 is a non-transitory storage medium claim with limitations corresponding to those of method Claim 1. Therefore, Claim 11 is rejected with the same combination and rationale as that of the rejection of Claim 1.
Maria further teaches a non-transitory storage medium having stored therein instructions that are executable by one or more hardware processors to perform operations (Maria – Paragraph [0047]: The processing depicted in FIGS. 2 to 4 may be implemented in software (e.g., code, instructions, program) executed by one or more processing units (e.g., processors, cores) of the respective systems, hardware, or combinations thereof. The software may be stored on a nontransitory storage medium (e.g., on a memory device)).
Regarding Claim 12:
Claim 12 is a non-transitory storage medium claim with limitations corresponding to those of method Claim 2. Therefore, Claim 12 is rejected with the same combination and rationale as that of the rejection of Claim 2.
Regarding Claim 14:
Claim 14 is a non-transitory storage medium claim with limitations corresponding to those of method Claim 4. Therefore, Claim 14 is rejected with the same combination and rationale as that of the rejection of Claim 4.
Regarding Claim 15:
Claim 15 is a non-transitory storage medium claim with limitations corresponding to those of method Claim 5. Therefore, Claim 15 is rejected with the same combination and rationale as that of the rejection of Claim 5.
Regarding Claim 16:
Claim 16 is a non-transitory storage medium claim with limitations corresponding to those of method Claim 6. Therefore, Claim 16 is rejected with the same combination and rationale as that of the rejection of Claim 6.
Regarding Claim 17:
Claim 17 is a non-transitory storage medium claim with limitations corresponding to those of method Claim 7. Therefore, Claim 17 is rejected with the same combination and rationale as that of the rejection of Claim 7.
Regarding Claim 18:
Claim 18 is a non-transitory storage medium claim with limitations corresponding to those of method Claim 8. Therefore, Claim 18 is rejected with the same combination and rationale as that of the rejection of Claim 8.
Claim(s) 3 and 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Maria in view of Dungen, Tran, Martynov, and Junior (US 20200133738 A1).
Regarding Claim 3:
The combination of Maria, Dungen, Tran, and Martynov teaches the method of claim 1.
Maria further teaches wherein one or both of the first service [and second service comprise a respective microservice operable to carry out respective functions of a containerized application] (Maria – Paragraph [0079]: At step 410, the access management system receives an access token request from an application; and Paragraph [0086]: In certain embodiments, server 512 may also provide other services or software applications that can include non-virtual and virtual environments. In some embodiments, these services may be offered as Webbased or cloud services or under a Software as a Service (SaaS) model to the users of client computing devices 502, 504, 506, and/or 508).
The combination of Maria, Dungen, Tran, and Martynov does not expressly teach wherein one or both of the first service and second service comprise a respective microservice operable to carry out respective functions of a containerized application.
However, Junior teaches wherein one or both of the first service and second service comprise a respective microservice operable to carry out respective functions of a containerized application (Junior – Paragraph [0019]: In one or more embodiments, a multi-cloud framework is provided for stateless microservice-based applications that can be implemented across multiple cloud environments. A user creates an application as a series of code fragments corresponding to individual microservices, and each microservice can be implemented using different technologies, such as Container as a Service (CaaS) and Function as a Service (FaaS). The application microservices can thus reside in different cloud environments (e.g., public clouds and/or private clouds). The disclosed framework is responsible for deploying the application and keeping track of the structural state of the application. Generally, the structural state of an application identifies the clouds that run particular versions of the microservices at any given point in time).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Maria, Dungen, Tran, and Martynov, further incorporating Junior to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Junior’s teaching of microservices to perform functions of containerized applications into Maria, Dungen, Tran, and Martynov’s combined method for user access management. This combination provides more context and precision regarding the capabilities of the method to control user access to applications.
Regarding Claim 13:
Claim 13 is a non-transitory storage medium claim with limitations corresponding to those of method Claim 3. Therefore, Claim 13 is rejected with the same combination and rationale as that of the rejection of Claim 3.
Claim(s) 9, 10, 19, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Maria in view of Dungen, Tran, Martynov, and Jiang et al. (US 20230092902 A1), hereinafter Jiang.
Regarding Claim 9:
The combination of Maria, Dungen, Tran, and Martynov teaches the method of claim 1.
Maria further teaches wherein the identity and access management module validation process comprises checking the user token to determine if the user token is expired (Maria – Paragraph [0081]: At step 414, the access management system determines, using the session information retrieved in step 412, whether the session is valid. In particular, the session may be validated by performing one or more of the checks described earlier. For example, if the information identifying the session is provided in a user identity token, the OAuth server 140 may determine whether the user identified in the user identity token matches the user associated with the session, e.g., based on a comparison between a subject field in the user identity token and a subject of the session. The validation of the session may involve communicating with the access manager that created the session (e.g., to request that the checks be performed by the access manager on behalf of the OAuth server). If the session is determined to be invalid for any reason, the access token request is denied and no access token is generated; and Paragraph [0062]: Session management-related checks can also be performed as part of session validation. Such checks may include, for example, determining whether a session expiration time has been reached and whether the session has timed out. For example, if the session has been idle for more than some configured value (e.g., an idle timeout of 15 minutes), when the user identity token is checked for validity the check will fail because the rules of the session are also applied to the access token being requested. If the user identity token is invalid, no access token will be generated).
The combination of Maria, Dungen, Tran, and Martynov does not expressly teach and, when the user token is expired, creating a refresh token for a user, on whose behalf the request was sent by the first service, when one or more criteria are met.
However, Jiang teaches and, when the user token is expired, creating a refresh token for a user, on whose behalf the request was sent by the first service, when one or more criteria are met (Jiang – Paragraph [0056]: For example, sidecar computer system 250 is configured to check
whether the time to live in local TTL database 252 for the access token has expired [0070] Token
initializer 204 can represent one or more software applications and/or modules executing on token computer system 202. Token initializer 204 is configured to accept the login request from a client
computer system 240 (e.g., an actor) and get an access token and refresh token from an authorization
identify provider such as one of the authorization servers 270. Token initializer 204 is configured to
get a new access token using a refresh token once the access token expires, i.e., once the time to live
expires).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Maria, Dungen, Tran, and Martynov, further incorporating Jiang to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Jiang’s teaching of microservices to perform functions of containerized applications into Maria, Dungen, Tran, and Martynov’s combined method for user access management. This addition further enhances the efficiency of the method by ensuring that a verified user will be quickly re-authenticated in the event that a valid session expires.
Regarding Claim 10:
The combination of Maria, Dungen, Tran, Martynov, and Jiang teaches the method of claim 9.
Maria further teaches [wherein the refresh token enables] the user to have continued access to the [second] service without having to login to a web application which initially received the user token from the user (Maria – Paragraph [0031]: An SSO flow may involve authenticating the user using one or more user credentials in order to create an SSO session along with a corresponding SSO cookie that enables the user to access additional resources without having to re-authenticate during the session; and Paragraph [0072]: FIG. 3 is a flowchart of a method 300 for generating a user identity token, in accordance with an embodiment. The method 300 can be performed by an access manager, such as the access manager 130 of FIG. 1. At step 310, the access manager receives an authentication request from an application; and Paragraph [0073]: At step 312, the access manager receives one or more user credentials from the user; and Paragraph [0074]: At step 314, the access manager authenticates the user using the one or more user credentials received in step 312; and Paragraph [0076]: At step 318, the access manager generates, as part of the session creation, a user identity token including a session ID that identifies the session; and Paragraph [0078]: At step 322, the access manager sets or sends the session cookie(s) along with the user identity token for the application to use in the future (e.g., as part of an access token request). The user identity token can be sent as a cookie or in a header of a token response. For example, if the application accepts SSO cookies, the access manager may send the user identity token along with the SSO cookie in a cookie package).
Dungen further teaches the second service (Dungen – Paragraph [0017]: In some embodiments, the facility is adapted to operate more effectively in connection with a multi-tiered server-implemented application in which an asynchronous queueing mechanism is used to process requests sent by a front-end service to a back-end service).
Jiang further teaches wherein the refresh token enables the user to have continued access to the [second] service without having to login [to a web application which initially received the user token from the user] (Jiang – Paragraph [0002]: To solve this problem, OAuth 2.0 (an industry-standard for authorization) introduced an artifact called a refresh token. A refresh token allows an application to obtain a new access token without prompting the user; and Paragraph [0004]: As noted above, a refresh token is a special kind of token used to obtain a renewed access token, and the application can request new access tokens until the refresh token is on the Denylist which indicates that it can no longer be used. Applications store refresh tokens securely because they allow a user to remain authenticated).
The motivation to combine the arts is the same as that of Claim 9.
Regarding Claim 19:
Claim 19 is a non-transitory storage medium claim with limitations corresponding to those of method Claim 9. Therefore, Claim 19 is rejected with the same combination and rationale as that of the rejection of Claim 9.
Regarding Claim 20:
Claim 20 is a non-transitory storage medium claim with limitations corresponding to those of method Claim 10. Therefore, Claim 20 is rejected with the same combination and rationale as that of the rejection of Claim 10.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Frei et al. (US 20160142409 A1) teaches methods and systems for authenticating users wherein a user identity is maintained throughout service communications via a proxy token
De Boer et al. (US 20190190912 A1) teaches a method for providing user access to services through an authorization entity
Rowe et al. (US 20190097802 A1) teaches systems and methods for creating composite tokens such that users do not have to re-authenticate for each service accessed
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NICHOLAS JOSEPH DILUZIO whose telephone number is (703)756-1229. The examiner can normally be reached Mon - Fri -- 7:30 AM - 5 PM.
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, Yin-Chen Shaw can be reached at 571-272-8878. 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.
/NICHOLAS JOSEPH DILUZIO/Examiner, Art Unit 2498
/YIN CHEN SHAW/Supervisory Patent Examiner, Art Unit 2498
Prosecution Insights