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/20/2026 has been entered. This office action is made Non-Final.
Status of claims
This office action is in response to claims filed on 01/20/2026
Claims 1, 3-24 and 26-27 are pending and rejected; claims 1, 6, 14, 15 and 23 are independent claims
The claim objections to 16-22 is withdrawn in response to applicant’s amendment.
Response to Arguments
Applicant's arguments filed on 01/20/2026 have been fully considered but they are not persuasive.
The claims interpretation under 35 USC 112(f) and subsequent rejections under 35 USC 112(b)
Applicants assertion that the amended claims overcome 112(f) claim interpretations of (1, 3-5, 23, 24, 26 and 27) are not persuasive, the claims remain interpreted with the same grounds. The claims are remain rejected under 35 USC 112(b).
The claim rejections of (1, 3-24 and 26-27) under 35 USC 112(a) regarding the phrase “adaption layer”
Applicant’s explanation is accepted and the rejection is withdrawn.
The claim rejections under 35 USC 103
With respect to applicant’s argument: Leander fail to disclose the limitations, “OAuth services”, much less any disclosure of performing authorization for OAuth services.
Examiner respectfully disagree with applicant’s argument for the following reasons: First, the claimed OAuth (Open Authorization) is an open-source security protocol that allows applications to access user data from other online services without requiring users to share their passwords. Accordingly, Lander discloses JSON Web Tokens (JWT) is implemented under OAuth framework (see Lander Fig. 4 and ¶¶9 73 75, use case for requesting and using the JSON Web Tokens (JWT) access token and ¶81, Using JWT for authorization is part of the OAuth2 framework).
In Addition, Madden discloses (see Madden ¶47, FIG. 2A illustrates message flow 200 for the OAuth 2.0 protocol for authorizing access to resources… Client 104 transmits authorization grant 236 to authorization service 105 which issues access tokens 245 for authenticating client 104) .
With respect to applicant’s argument Leander fails to disclose the limitation “wherein authorization protocol processing is not distributed to implement access to a remote resource server but is instead managed centrally at the authorization module of the centralized management unit”
Examiner respectfully disagree with applicant’s argument for the following reasons: Leander discloses (see Leander Fig. 4 and ¶73 79, centralized authorization service (AS) will evaluate the access-token request and, if granted, issue a token containing a claim which can be used to exercise the permission; ¶81, Using JWT for authorization is part of the OAuth2 framework; ¶¶16 22-23 42 49 54, there is a single centralized authorization server[i.e. centralized authorization management unit], which is thus common to all resource servers in the computer system; ¶106, an access token is received from the authorization server [i.e. centralized authorization management unit]240 in response to the access request, the access token indicates at least one role associated with the user and at least one explicit permission/restriction to access at least one of the resources)) disclosing the recited claim limitation.
With respect to applicant’s argument: the cited references either alone or in combination do not teach or suggest at least "an adaptation layer to unify user experience for third-party applications wherein the adaptation layer unifies the user experience for OAuth authorization for the plurality of OAuth services, wherein the adaptation layer operates by pairing a matching authorization algorithm with a selected external authorization service through the adaptation layer"
Examiner respectfully disagree with applicant’s argument for the following reasons: Madden discloses the recited claim limitation(see Madden Fig. 2 and ¶¶50 59, OAuth 2 access tokens are bearer tokens, which utilize a simple token format, like HS256 JSON web tokens (JWTs). If a service knows the value of the token they can use it, without needing other credentials. Macaroons are a type of bearer token that can be used when issuing OAuth 2.0 access and refresh tokens. They can be used in place of regular access or refresh tokens, as they allow the sharing of a single token with multiple clients and resource servers without compromising security; ¶69, OAuth authorization servers are provided a mechanism for binding/unify access tokens to a client’s mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. When mutual TLS authentication is used by the client on the connection to the token endpoint, the authorization server is able to bind the issued access token to the client certificate. Such a binding is accomplished by associating the certificate with the token in a way that can be accessed by the protected resource) in addition, Applicant's arguments fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are:
In Claim 1:
“an authorization module to perform an authorization process that performs authorization for a plurality of OAuth services”
“a token management module that provides one or more tokens to the third-party applications”
In Claim 3:
“centralized management unit of claim 1, wherein the authorization module performs the authorization process that is initiated by a user who is previously authenticated to the authorization framework”
In Claim 4:
“centralized management unit of claim 1, wherein the token management module defines a token scope for a token, validates the token, refreshes the token if the token is expired and revokes or invalidates the token”
In Claim 5:
“centralized management unit of claim 4, wherein the token management module verifies two conditions: whether a user has privilege to request an access token and whether a service has access to any tokens to validate the scope of the token”
In Claim 23:
“centralized management unit facilitates protocol implementation, internal authorization, handling of the access tokens, revoking of access tokens, validating third-party services tokens, and refreshing a token, wherein the internal authorization is performed in conjunction with an adaptation layer to unify user experience for third-party applications where the adaptation layer unifies the user experience for OAuth authorization for a plurality of OAuth services”
In Claim 24:
“an authorization module to perform an authorization process”
In Claim 26:
“an authorization module performs an authorization process that is initiated by a user which is previously authenticated to the authorization framework”
In Claim 27:
“a token management module defines token scope, validates the token, refreshes the token if the token is expired, and revokes or invalidates the token”
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 1, 3-5, 23, 24, 26 and 27 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
In Claim 1:
Claim limitation “an authorization module to perform an authorization process that performs authorization for a plurality of OAuth services” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. the disclosure is devoid of any structure that performs the function in the claim Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Claim limitation “a token management module that provides one or more tokens to the third-party applications” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. the disclosure is devoid of any structure that performs the function in the claim Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
In Claim 3:
Claim limitation “the authorization module performs the authorization process that is initiated by a user who is previously authenticated to the authorization framework” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. the disclosure is devoid of any structure that performs the function in the claim Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
In Claim 4:
Claim limitation “the token management module defines a token scope for a token, validates the token, refreshes the token if the token is expired and revokes or invalidates the token” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. the disclosure is devoid of any structure that performs the function in the claim Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
In Claim 5:
Claim limitation “token management module verifies two conditions: whether a user has privilege to request an access token and whether a service has access to any tokens to validate the scope of the token” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. the disclosure is devoid of any structure that performs the function in the claim Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
In Claim 23:
Claim limitation “ centralized management unit for an authorization framework to provide access tokens to third-party services for accessing user data outside of an internal security domain, wherein the centralized management unit facilitates protocol implementation, internal authorization, handling of the access tokens, revoking of access tokens, validating third-party services tokens, and refreshing a token, wherein the internal authorization is performed in conjunction with an adaptation layer to unify user experience for third-party applications where the adaptation layer unifies the user experience for OAuth authorization for a plurality of OAuth services.” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. the disclosure is devoid of any structure that performs the function in the claim Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
In Claim 24:
Claim limitation “ an authorization module to perform an authorization process; and a token management module.” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. the disclosure is devoid of any structure that performs the function in the claim Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
In Claim 26:
Claim limitation “wherein an authorization module performs an authorization process that is initiated by a user which is previously authenticated to the authorization framework.” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. the disclosure is devoid of any structure that performs the function in the claim Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
In Claim 27:
Claim limitation “wherein a token management module defines token scope, validates the token, refreshes the token if the token is expired, and revokes or invalidates the token.” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. the disclosure is devoid of any structure that performs the function in the claim Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
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, 3-24 and 26-27 are rejected under 35 U.S.C. 103 as being unpatentable over Leander US Pub. No.: 2023/0254320 A1 (hereinafter Leander) in view of Madden et al. US Pub. No.: 2023/0239151 A1 (hereinafter Madden).
Leander teaches:
As to claim 1, a centralized management unit of an authorization framework (see Leander Fig. 4 and ¶14 a centralized authorization server) comprising:
an authorization module to perform an authorization process that performs authorization for a plurality of OAuth service, wherein authorization protocol processing is not distributed to implement access to a remote resource server but is instead managed centrally at the authorization module of the centralized management unit, (see Leander Fig. 4 and ¶73 79, centralized authorization service (AS) will evaluate the access-token request and, if granted, issue a token containing a claim which can be used to exercise the permission; ¶81, Using JWT for authorization is part of the OAuth2 framework; ¶¶16 22-23 42 49 54, there is a single centralized authorization server[i.e. centralized authorization management unit], which is thus common to all resource servers in the computer system; ¶106, an access token is received from the authorization server [i.e. centralized authorization management unit]240 in response to the access request, the access token indicates at least one role associated with the user and at least one explicit permission/restriction to access at least one of the resources), and wherein an external authorization service is selected to be authorized (see Leander ¶66, the outer resource server is not able to execute the explicit permissions/restrictions in the access token, then the inner resource server can be configured to apply these explicit permissions/restrictions to selectively forward any resource requests that would be granted according to the explicit permissions/restrictions and to stop any resource requests that would be declined according to the explicit permissions/restrictions)
a token management module that provides one or more tokens to the third-party application (see Lander ¶¶57, method is using delegation through an authorization service (AS) [i.e. token management module], which issues a security token containing information and assurance of validity for a specific resource request; ¶¶75 95, the AS queries an NGAC graph database requesting all the privileges that the orchestrator holds on the specific module. Privileges marked as roles will be added to the list of roles claims),
Leander does not explicitly teach but the analogous art Madden discloses:
an adaptation layer to unify user experience for third- party applications wherein the adaption layer unifies the user experience for OAuth authorization for the plurality of OAuth services (see Madden Fig. 2 and ¶¶50 59, OAuth 2 access tokens are bearer tokens, which utilize a simple token format, like HS256 JSON web tokens (JWTs). If a service knows the value of the token they can use it, without needing other credentials. Macaroons are a type of bearer token that can be used when issuing OAuth 2.0 access and refresh tokens. They can be used in place of regular access or refresh tokens, as they allow the sharing of a single token with multiple clients and resource servers without compromising security; ¶69, OAuth authorization servers are provided a mechanism for binding/unify access tokens to a client’s mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. When mutual TLS authentication is used by the client on the connection to the token endpoint, the authorization server is able to bind the issued access token to the client certificate. Such a binding is accomplished by associating the certificate with the token in a way that can be accessed by the protected resource),
wherein the adaption layer operates by pairing a matching authorization algorithm with a selected external authorization service through the adaption layer (see Madden ¶69, OAuth authorization servers are provided a mechanism for binding/pairing access tokens to a client’s mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. When mutual TLS authentication is used by the client on the connection to the token endpoint, the authorization server is able to bind the issued access token to the client certificate. Such a binding is accomplished by associating the certificate with the token in a way that can be accessed by the protected resource)
wherein the token management module performs an action to define a token scope for the one or more tokens (see Madden ¶¶38, Introspection endpoint 115 provides the overall scope for authorization server 105, which is the intersection of the macaroon access token and associated caveats, after determining how to reduce the access; ¶44, Rather than issuing multiple access tokens with different scopes for a set of microservices, authorization service 105 issues an access token in the form of a macaroon (MAT) with a broad scope to API gateway 125, which can then create as many macaroons as needed from the single macaroon access token, restricting their scopes as required by using caveats)
Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify access control enforcement architectures for dynamic manufacturing system disclosed by Leander to include safely using access tokens for confirming delegation of authorization from an authorization server by a client to a service using OAuth authorization farmwork as thought by Madden. A person with ordinary skill in the art would have been motivated to for safely confirming delegation of authorization within an OAuth2 framework to overcome issue of encoding specific details of a transaction (see Madden ¶¶13-15)
As to claim 2, (Canceled)
As to claim 3, the combination of Leander and Madden teaches the centralized management unit of claim 1, wherein the authorization module performs the authorization process that is initiated by a user who is previously authenticated to the authorization framework (see Leander ¶25, the processing in the authorization server excludes any decision-making on policy privileges based on the user's role or roles (e.g., permissions/restrictions related to the user's roles))
As to claim 4, the combination of Leander and Madden teaches the centralized management unit of claim 1, wherein the token management module, validates the token, refreshes token if token is expired and revokes or invalidates the token (see Madden ¶¶47-49, Authorization service 105 tracks the validity of the tokens which validate that user/resource owner 102 authorizes client 104 to act on their behalf over specific resources during a limited amount of time… Macaroons are a type of bearer token that can be used when issuing OAuth 2.0 access and refresh tokens; ¶59, client 204 first requests a long-lived access token, and refresh token if desired, from authorization service 105; ¶32, tokens can be refreshed once exfiltrated/revoked )
Same rational as above to claim 1 applies to combine the cited prior art references.
As to claim 5, the combination of Leander and Madden teaches the centralized management unit of claim 4, wherein the token management module verifies two conditions: whether a user has privilege to request access token and whether a service has access to any tokens to validate the scope of the token (see Leander Fig. 2 and ¶¶57 59, method is using delegation through an AS, which issues a security token containing information and assurance of validity for a specific resource request; ¶114, an access token is provided. The access token indicates said at least one determined role of the user and said at least one explicit permission/restriction to access at least one of the resources)
Leander teaches:
As to claim 6, a method for authorization for a centralized authorization framework, comprising:
performing an authorization process that is initiated by a user through third-party applications for authorization for a plurality of OAuth services wherein authorization protocol processing is not distributed to implement access to a remote resource service but is instead managed centrally at the authorization module of the centralized management unit (see Leander Fig. 4 and ¶73 79, centralized authorization service (AS) will evaluate the access-token request and, if granted, issue a token containing a claim which can be used to exercise the permission; ¶81, Using JWT for authorization is part of the OAuth2 framework; ¶¶16 22-23 42 49 54, there is a single centralized authorization server[i.e. centralized authorization management unit], which is thus common to all resource servers in the computer system; ¶106, an access token is received from the authorization server [i.e. centralized authorization management unit]240 in response to the access request, the access token indicates at least one role associated with the user and at least one explicit permission/restriction to access at least one of the resources), and wherein an external authorization service is selected to be authorized for a user(see Leander ¶66, the outer resource server is not able to execute the explicit permissions/restrictions in the access token, then the inner resource server can be configured to apply these explicit permissions/restrictions to selectively forward any resource requests that would be granted according to the explicit permissions/restrictions and to stop any resource requests that would be declined according to the explicit permissions/restrictions)l
defining and generating an access token through a token management module (see Leander ¶¶57 88, using the access token needs to be adapted, so that the client can issue different types of access-token requests to the AS, differentiating single-operation access-token requests from ordinary access-token requests).
Leander does not explicitly teach but the analogous art Madden teaches:
pairing a matching authorization algorithm with a selected one of the third-party applications and the centralized authorization framework through an adaptation layer wherein the adaptation layer unifies a user experience for OAuth authorization for the plurality of OAuth services (see Madden Fig. 2 and ¶¶50 59, OAuth 2 access tokens are bearer tokens, which utilize a simple token format, like HS256 JSON web tokens (JWTs). If a service knows the value of the token they can use it, without needing other credentials. Macaroons are a type of bearer token that can be used when issuing OAuth 2.0 access and refresh tokens. They can be used in place of regular access or refresh tokens, as they allow the sharing of a single token with multiple clients and resource servers without compromising security [i.e. adaption layer is inherent to OAuth and implicitly disclosed by the cited prior art reference]; ¶69, OAuth authorization servers are provided a mechanism for binding/pairing access tokens to a client’s mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token),
wherein the adaption layer operates by pairing a matching authorization algorithm with a selected external authorization service through the adaption layer (see Madden ¶69, OAuth authorization servers are provided a mechanism for binding/pairing access tokens to a client’s mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. When mutual TLS authentication is used by the client on the connection to the token endpoint, the authorization server is able to bind the issued access token to the client certificate. Such a binding is accomplished by associating the certificate with the token in a way that can be accessed by the protected resource)
wherein the token management module performs an action to define a token scope for the one or more tokens (see Madden ¶¶38, Introspection endpoint 115 provides the overall scope for authorization server 105, which is the intersection of the macaroon access token and associated caveats, after determining how to reduce the access; ¶44, Rather than issuing multiple access tokens with different scopes for a set of microservices, authorization service 105 issues an access token in the form of a macaroon (MAT) with a broad scope to API gateway 125, which can then create as many macaroons as needed from the single macaroon access token, restricting their scopes as required by using caveats)
Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify access control enforcement architectures for dynamic manufacturing system disclosed by Leander to include safely using access tokens for confirming delegation of authorization from an authorization server by a client to a service using OAuth authorization farmwork as thought by Madden. A person with ordinary skill in the art would have been motivated to for safely confirming delegation of authorization within an OAuth2 framework to overcome issue of encoding specific details of a transaction (see Madden ¶¶13-15)
As to claim 7, the combination of Leander and Madden teaches the method of claim 6, wherein the authorization process comprises selecting an external authorization service to be authorized by the user (see Leander ¶66, the policy decision provided in the second step 712 is enforced, so that the user client is selectively granted access to all, some, or none of the resources it requested… providing the (aggregate) resource server between the user client and the outer resource server);
redirecting the user to a web page of the external authorization service and the user is allowed to accept terms and conditions for authorization (see Leander ¶¶45-47 75, the resource request must be evaluated against available policy data, which is done by the PDP, which reads policy data from PIPs);
if the user agrees and accepts the terms, redirecting back to present authorization framework and centralized management unit continues with an authorization handshake protocol (see Leander ¶47, Before allowing a subject to access the resource, the resource request must be evaluated against available policy data, which is done by the PDP, which reads policy data from PIPs) ;
receiving the access token along with a scope definition comprising its expiration date and optionally provide a refresh token as well (see Leander ¶106, an access token is received from the authorization server 240 in response to the access request, the access token indicates at least one role associated with the user and at least one explicit permission/restriction to access at least one of the resources); and
storing the access token, its expiration date and the refresh token into a secure vault and informing the user about a result (see Leander ¶109, access token may be temporarily stored in a memory in the resource server 220, after the resource server 220 has received the access token the first time, or a memory in the user client 210).
As to claim 8, the combination of Leander and Madden teaches the method of claim 6, further comprising defining token scope, validating a token, refreshing the token if the token is expired and revoking or invalidation of the token (see Madden ¶¶4-50 59, original access token, with scope a b c d and a specific expiry time and audience, is stored in the token database and is listed next… Macaroons are a type of bearer token that can be used when issuing OAuth 2.0 access and refresh tokens; ¶32, tokens can be refreshed once exfiltrated/revoked).
Same rational as above to claim 1 applies to combine the cited prior art references.
As to claim 9, the combination of Leander and Madden teaches the method of claim 8, wherein validating the token comprises requesting access token by the third-party application (see Leander Fig. 2 and ¶¶57 59, method is using delegation through an AS, which issues a security token containing information and assurance of validity for a specific resource request; ¶114, an access token is provided. The access token indicates said at least one determined role of the user and said at least one explicit permission/restriction to access at least one of the resources);
verifying two conditions: whether a user has such privilege to request the access token and whether a service has access to any tokens (see Leander ¶¶99 114, an access token is provided. The access token indicates said at least one determined role of the user and said at least one explicit permission/restriction to access at least one of the resources);
validating the scope of the token if these conditions are satisfied (see Leander ¶¶99-103, validation is done based on token explicit permissions as part of entitlements);
rejecting the request for access token if these conditions are not satisfied (see Leander ¶¶99-103, request is denied for access token based on role-permission).
As to claim 10, the combination of Leander and Madden teaches the method of claim 8, wherein validating the token further comprises validating scope of the token (see Leander ¶114, access token indicates said at least one determined role of the user and said at least one explicit permission/restriction to access at least one of the resources);
if the scope is active then access token is granted and if the scope is expired or invalidated by the user then initiating request for refreshing the access token or denying the request of the access token (see Leander ¶¶102-103, If the requested resource matches the role-permission, access is granted otherwise, access is denied)
As to claim 11, the combination of Leander and Madden teaches the method of claim 8, wherein validating the token comprises requesting access token by the third-party application (see Leander Fig. 2 and ¶¶57 59, method is using delegation through an AS, which issues a security token containing information and assurance of validity for a specific resource request; ¶114, an access token is provided. The access token indicates said at least one determined role of the user and said at least one explicit permission/restriction to access at least one of the resources);
validating the access token by requesting the API of a service (see Madden ¶31, Applications use access tokens to make Application Programming Interface (API) requests on behalf of a user. The access token represents the authorization of a specific application to access specific parts of a user’s data [i.e. validating/authorization of access token request]);
verifying the scope of the token (see Madden ¶¶44, authorization service 105 issues an access token in the form of a macaroon (MAT) with a broad scope to API gateway 125);
if the scope of token is valid then access is granted else initiating a request for a refresh token (see Madden ¶44, Authorization service 105 responds to a request for access, providing an access token which represents the authorization for a user of a specific application to access specific user data).
As to claim 12, the combination of Leander and Madden teaches the method of claim 8, wherein refreshing the token comprises requesting an additional authorization protocol handshake with an external service (see Leander ¶73, token is used to open a new session, or to refresh the current session);
allowing the user to grant a required permission on the API of the external service (see Madden ¶¶44, authorization service 105 issues an access token in the form of a macaroon (MAT) with a broad scope to API gateway 125);
refreshing the token and discarding an old token from a token vault (see Leander ¶73, token is used to open a new session, or to refresh the current session).
As to claim 13, the combination of Leander and Madden teaches the method of claim 8, wherein invalidating of the token comprises initiating invalidation (see Leander ¶¶93 98, validation of the token is done at session activation, e.g., that the signature is valid, that the issuer is the expected one)
invoking external service API (see Madden ¶46, Authorization service 105 generates and sends a broadly-scoped access token to API gateway which accepts application programming interface (API) calls from client 104)
invalidating the token by disallowing granted licenses and permissions for using user data by the user (see Leander ¶99 when validation fails access is denied);
removing or erasing the invalidated token from the token vault or repository (see Leander ¶99 when validation fails access is denied).
Leander teaches:
As to claim 14, a computer processing system comprises a processing unit (see Leander ¶54, processing circuitry);
a communications interface (see Leander ¶56, communication interface); and
a non-transitory computer-readable storage medium to store instructions, wherein the processing unit execute the stored instructions to perform protocol implementation (see Leander ¶¶14 29 computer programs stored in communication media, perform authorization protocol), internal authorization (see Leander Fig. 3 and ¶78, authorization service), handling of access tokens (see Leander ¶11, how access control policies expressed using a standardized ABAC policy model can be formulated using access tokens),
Leander does not explicitly teach but the analogous art Madden teaches:
revoking of the access tokens, validating third-party services tokens, and refreshing a token (see Madden ¶32, tokens can be refreshed once exfiltrated/revoked)
wherein the internal authorization is performed in conjunction with an adaptation layer to unify user experience for third-party applications where the adaptation layer unifies the user experience for OAuth authorization for a plurality of OAuth services (see Madden Fig. 2 and ¶¶50 59, OAuth 2 access tokens are bearer tokens, which utilize a simple token format, like HS256 JSON web tokens (JWTs). If a service knows the value of the token they can use it, without needing other credentials. Macaroons are a type of bearer token that can be used when issuing OAuth 2.0 access and refresh tokens. They can be used in place of regular access or refresh tokens, as they allow the sharing of a single token with multiple clients and resource servers without compromising security),
wherein the adaption layer operates by pairing a matching authorization algorithm with a selected external authorization service through the adaption layer (see Madden ¶69, OAuth authorization servers are provided a mechanism for binding/pairing access tokens to a client’s mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. When mutual TLS authentication is used by the client on the connection to the token endpoint, the authorization server is able to bind the issued access token to the client certificate. Such a binding is accomplished by associating the certificate with the token in a way that can be accessed by the protected resource)
Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify access control enforcement architectures for dynamic manufacturing system disclosed by Leander to include safely using access tokens for confirming delegation of authorization from an authorization server by a client to a service using OAuth authorization farmwork as thought by Madden. A person with ordinary skill in the art would have been motivated to for safely confirming delegation of authorization within an OAuth2 framework to overcome issue of encoding specific details of a transaction (see Madden ¶¶13-15)
Leander teaches:
As to claim 15. a computer non-transitory readable medium storing a set of instructions that when executed (see Leander ¶29), cause a processing module of a computer to perform:
an authorization process that is initiated by a user through third- party applications for OAuth authorization for a plurality, wherein authorization protocol processing is not distributed to implement access to a remote resource server but is instead managed centrally at the authorization module of the centralized management unit, (see Leander Fig. 4 and ¶73 79, centralized authorization service (AS) will evaluate the access-token request and, if granted, issue a token containing a claim which can be used to exercise the permission; ¶81, Using JWT for authorization is part of the OAuth2 framework; ¶¶16 22-23 42 49 54, there is a single centralized authorization server[i.e. centralized authorization management unit], which is thus common to all resource servers in the computer system; ¶106, an access token is received from the authorization server [i.e. centralized authorization management unit]240 in response to the access request, the access token indicates at least one role associated with the user and at least one explicit permission/restriction to access at least one of the resources), and wherein an external authorization service is selected to be authorized for a user (see Leander ¶66, the outer resource server is not able to execute the explicit permissions/restrictions in the access token, then the inner resource server can be configured to apply these explicit permissions/restrictions to selectively forward any resource requests that would be granted according to the explicit permissions/restrictions and to stop any resource requests that would be declined according to the explicit permissions/restrictions);
defining and generating an access token through a token management module (see Leander ¶11, for using claim-based tokens as part of the enforcement mechanism, including how access control policies expressed using a standardized ABAC policy model can be formulated using access tokens)
Leander does not explicitly teach but the analogous art Madden teaches:
OAuth authorization for a plurality of OAuth services (see Madden ¶¶31 35, authorization for OAuth services);
pairing a matching authorization algorithm with at least one of the third-party applications and a centralized authorization framework through an adaptation layer wherein the adaptation layer unifies a user experience for OAuth authorization for the plurality of OAuth services (see Madden Fig. 2 and ¶¶50 59, OAuth 2 access tokens are bearer tokens, which utilize a simple token format, like HS256 JSON web tokens (JWTs). If a service knows the value of the token they can use it, without needing other credentials. Macaroons are a type of bearer token that can be used when issuing OAuth 2.0 access and refresh tokens. They can be used in place of regular access or refresh tokens, as they allow the sharing of a single token with multiple clients and resource servers without compromising security)
wherein the adaption layer operates by pairing a matching authorization algorithm with a selected external authorization service through the adaption layer (see Madden ¶69, OAuth authorization servers are provided a mechanism for binding/pairing access tokens to a client’s mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. When mutual TLS authentication is used by the client on the connection to the token endpoint, the authorization server is able to bind the issued access token to the client certificate. Such a binding is accomplished by associating the certificate with the token in a way that can be accessed by the protected resource)
wherein the token management module performs an action to define a token scope for the one or more tokens (see Madden ¶¶38, Introspection endpoint 115 provides the overall scope for authorization server 105, which is the intersection of the macaroon access token and associated caveats, after determining how to reduce the access; ¶44, Rather than issuing multiple access tokens with different scopes for a set of microservices, authorization service 105 issues an access token in the form of a macaroon (MAT) with a broad scope to API gateway 125, which can then create as many macaroons as needed from the single macaroon access token, restricting their scopes as required by using caveats).
Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify access control enforcement architectures for dynamic manufacturing system disclosed by Leander to include safely using access tokens for confirming delegation of authorization from an authorization server by a client to a service using OAuth authorization farmwork as thought by Madden. A person with ordinary skill in the art would have been motivated to for safely confirming delegation of authorization within an OAuth2 framework to overcome issue of encoding specific details of a transaction (see Madden ¶¶13-15)
As to claim 16, the non-transitory combination of Leander and Madden teaches the computer readable medium of claim 15, wherein a set of instructions that when executed, cause the processing module to perform an authorization process (see Leander Fig. 4 and ¶79, authorization service)comprising:
selecting an external authorization service to be authorized by the user (see Leander ¶66, resource server can be configured to apply these explicit permissions/restrictions to selectively forward any resource requests);
redirecting the user to a web page of the external authorization service and the user is allowed to accept terms and conditions for authorization (see Leander ¶34, “resource” may be, for example, a portion of a personal storage quota, a business unit storage quota, an information retrieval system, a (portion of a) database, an online service, a protected webpage, or a physical device);
if the user agrees and accepts the terms, redirecting back to present authorization framework and a centralized management unit continues with an authorization handshake protocol (see Leander ¶34, “resource” may be, for example, a portion of a personal storage quota, a business unit storage quota, an information retrieval system, a (portion of a) database, an online service, a protected webpage, or a physical device);
receiving the access token along with a scope definition comprising its expiration date and optionally provide refresh token as well (see Leander ¶¶83 99-101, validation is done in the following steps: expiry time of token is checked, resource request is compared with the list of explicit permissions, as part of entitlements claim); and
storing the access token, its expiration date and the refresh token into a secure vault and informing the user about a result (see Leander ¶109, access token may be temporarily stored in a memory in the resource server 220, after the resource server 220 has received the access token the first time, or a memory in the user client 210).
As to claim 17, the non-transitory combination of Leander and Madden teaches the computer readable medium of claim 15, wherein a set of instructions that when executed, cause the processing module to perform: validating the token, refreshing the token if the token is expired and revoking or invalidation of the token (Madden ¶32, tokens can be refreshed once exfiltrated/revoked).
As to claim 18, the non-transitory combination of Leander and Madden teaches the computer readable medium of claim 17, wherein a set of instructions that when executed, cause the processing module to perform validation of the token that further comprising:
requesting access token by the third-party application (see Leander ¶114, an access token is provided. The access token indicates said at least one determined role of the user and said at least one explicit permission/restriction to access at least one of the resources);
verifying two conditions whether a user has such privilege to request access token and whether a service has access to any tokens (see Leander ¶¶99 114, an access token is provided. The access token indicates said at least one determined role of the user and said at least one explicit permission/restriction to access at least one of the resources);
validating the scope of the token if these conditions are satisfied(see Leander ¶¶99-103, validation is done based on token explicit permissions as part of entitlements);
rejecting the request for the access token if these conditions are not satisfied (see Leander ¶¶99-103, validation is done based on token explicit permissions as part of entitlements).
As to claim 19, the non-transitory combination of Leander and Madden teaches the computer readable medium of claim 17, wherein a set of instructions that when executed, cause the processing module to perform validation of the token that further comprising:
validating the scope of the token; if the scope is active then access token is granted and if the scope is expired or invalidated by the user then initiating request for refreshing the access token or denying the request of access token (see Leander ¶¶102-103, If the requested resource matches the role-permission, access is granted otherwise, access is denied).
As to claim 20, the non-transitory combination of Leander and Madden teaches the computer readable medium of claim 17, wherein a set of instructions that when executed, cause the processing module to perform validation of the token (see Leander ¶¶99-103, validation is done based on token explicit permissions as part of entitlements); that further comprising:
requesting the access token by the third-party application (see Leander Fig. 2 and ¶¶57 59, method is using delegation through an AS, which issues a security token containing information and assurance of validity for a specific resource request);
validating the access token by requesting the API of a service (see Madden ¶31, Applications use access tokens to make Application Programming Interface (API) requests on behalf of a user. The access token represents the authorization of a specific application to access specific parts of a user’s data [i.e. validating/authorization of access token request]);
verifying the scope of the token if the scope of token is valid then access is granted else initiating a request for a refresh token (see Madden ¶¶4 40-41, introspection endpoint 115 provides the overall scope for authorization server 105).
As to claim 21, the non-transitory combination of Leander and Madden teaches the computer readable medium of claim 17, wherein a set of instructions that when executed, cause the processing module to perform refreshing the token that further comprises:
requesting an additional authorization protocol handshake with an external service (see Leander ¶73, token is used to open a new session, or to refresh the current session);
allowing the user to grant a required permission on the API of the external service; refreshing the token and discarding an old token from a token vault (see Leander ¶73, token is used to open a new session, or to refresh the current session.
As to claim 22, the non-transitory combination of Leander and Madden teaches the computer readable medium of claim 17, wherein a set of instructions that when executed, cause the processing module to perform invalidation of the token that further comprises: initiating invalidation see Leander ¶¶93 98, validation of the token is done at session activation, e.g., that the signature is valid, that the issuer is the expected one);
invoking external service API (see Leander ¶¶83 99-101, validation is done in the following steps: expiry time of token is checked, resource request is compared with the list of explicit permissions, as part of entitlements claim);
invalidating the token by disallowing granted licenses and permissions for using user data by the user (see Leander ¶99 when validation fails access is denied);
removing or erasing the invalidated token from the token vault or a repository (see Leander ¶99 when validation fails access is denied).
Leander teaches:
As to claim 23, a centralized management unit for an authorization framework to provide access tokens to third- party services for accessing user data outside of an internal security domain (see Leander Fig. 4, a computer system/server 12),
wherein the centralized management unit facilitates protocol implementation (see Leander ¶47, Before allowing a subject to access the resource, the resource request must be evaluated against available policy data, which is done by the PDP, which reads policy data from PIPs),
internal authorization, handling of the access tokens (see Leander ¶106, an access token is received from the authorization server 240 in response to the access request, the access token indicates at least one role associated with the user and at least one explicit permission/restriction to access at least one of the resources),
Leander does not explicitly teach but the analogous art Madden teaches:
revoking of access tokens, validating third-party services tokens, and refreshing a token (see Madden ¶32, tokens can be refreshed once exfiltrated/revoked)
wherein the internal authorization is performed in conjunction with an adaptation layer to unify user experience for third-party applications where the adaptation layer unifies the user experience for OAuth authorization for a plurality of OAuth services (see Madden Fig. 2 and ¶¶50 59, OAuth 2 access tokens are bearer tokens, which utilize a simple token format, like HS256 JSON web tokens (JWTs). If a service knows the value of the token they can use it, without needing other credentials. Macaroons are a type of bearer token that can be used when issuing OAuth 2.0 access and refresh tokens. They can be used in place of regular access or refresh tokens, as they allow the sharing of a single token with multiple clients and resource servers without compromising security)
wherein the adaption layer operates by pairing a matching authorization algorithm with a selected external authorization service through the adaption layer (see Madden ¶69, OAuth authorization servers are provided a mechanism for binding/pairing access tokens to a client’s mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. When mutual TLS authentication is used by the client on the connection to the token endpoint, the authorization server is able to bind the issued access token to the client certificate. Such a binding is accomplished by associating the certificate with the token in a way that can be accessed by the protected resource).
Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify access control enforcement architectures for dynamic manufacturing system disclosed by Leander to include safely using access tokens for confirming delegation of authorization from an authorization server by a client to a service using OAuth authorization farmwork as thought by Madden. A person with ordinary skill in the art would have been motivated to for safely confirming delegation of authorization within an OAuth2 framework to overcome issue of encoding specific details of a transaction (see Madden ¶¶13-15)
As to claim 24, the combination of Leander and Madden teaches the centralized management unit of claim 23 that further comprises: an authorization module to perform an authorization process (see Leander Fig. 3 and ¶78, authorization service); and
a token management module (see Leander ¶11, for using claim-based tokens as part of the enforcement mechanism, including how access control policies expressed using a standardized ABAC policy model can be formulated using access tokens)
As to claim 25, (canceled).
As to claim 26, the combination of Leander and Madden teaches the centralized management unit of claim 23, wherein an authorization module performs an authorization process that is initiated by a user which is previously authenticated to the authorization framework (see Leander ¶25, the processing in the authorization server excludes any decision-making on policy privileges based on the user's role or roles (e.g., permissions/restrictions related to the user's roles).
As to claim 27, the combination of Leander and Madden teaches the centralized management unit of claim 23, wherein a token management module defines token scope, validates the token, refreshes token if token is expired and revokes or invalidates the token (see Leander ¶¶83 99-101, validation is done in the following steps: expiry time of token is checked, resource request is compared with the list of explicit permissions, as part of entitlements claim).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NEGA WOLDEMARIAM whose telephone number is (571)270-7478. The examiner can normally be reached Monday to Friday, 8am-5pm.
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, Cathy Thiaw can be reached at 5712701138. 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.
NEGA . WOLDEMARIAM
Examiner
Art Unit 2407
/N.W/Examiner, Art Unit 2407
/Catherine Thiaw/Supervisory Patent Examiner, Art Unit 2407 2/20/2026