DETAILED ACTION
This office action is in response to an amendment filed on 03/30/2026. New dependent claim 72 is added. Claims 46-72 are pending. Claims 46, 51, 55, 59, 64 and 68 are independent. Each independent claim is amended.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 04/30/2026; 06/08/2026 and 06/09/2026 have been considered. The submission is in-compliance with the provisions of 37 CFR 1.97. Form PTO-1449 is signed and attached hereto.
Response to Arguments
Applicant’s arguments filed on March 30, 2026, with regarding to the 35 U.S.C. 102 rejection directed to the independent claims 46, 51, 55, 59, 64 and 68 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Applicant’s representative in particular argued that the following amended (underlined and bolded) “wherein the access token includes a claim asserting that the resource owner consents, or does not consent, to the communication equipment accessing the protected resource of the API” recited in independent claims 46, 51, 55, 59, 64 and 68 isn’t disclosed by the references/prior arts of the record namely by 3GPP
Examiner would like to point out that, the newly founded prior art NPL document, titled, WS02 Open Banking Accelerator 3.0.0 documentation –“JWT Access Token”(Herein after referred as WS02) discloses each and every amended/underlined claim limitation.
In particular WS02 discloses: “wherein the access token includes a claim [See WSO2 through out the documentation teaches that, “JWT access tokens and custom claims in the JWT access token”] asserting that the resource owner consents [WSO2 teaches that the JWT token contains a consent ID as a custom claim, and that the consent ID is a unique identifier for a granted consent], or
7. Thus, in response to the 35 U.S.C. 102 rejection set forth in the previous office action, applicant amended at least each independent claim 46, 51, 55, 59, 64 and 68, presumably to overcome the 35 U.S.C. 102 rejection set forth in the previous office action. Since, the newly amended claims changed the scope and necessitated new grounds of rejection, applicant’s arguments are moot. The analysis of the claims under consideration, as amended, follows in the corresponding section below.
Claim Rejections - 35 USC § 103
8. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or non-obviousness.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
9. Claims 46-47, 49, 51-52, 55, 58-60, 62, 64-65, 68 and 71 are rejected under 35 U.S.C. 102 (a)(1) as being anticipated by NPL Document, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Study on application enablement aspects for subscriber-aware northbound API access; (Release 18) (here in after referred as 3GPP) (TR 23.700-95) (Pub. Date: April 2022) (Pages 1-25). (This prior art is provided with the IDS) in view of NPL document, titled, WS02 Open Banking Accelerator 3.0.0 documentation –“JWT Access Token”(Herein after referred as WS02)
The following is referring to independent claims 46, 51, 55, 59, 64 and 68 and dependent claim 72:
As per independent claim 46, 3GPP discloses, a method performed by communication equipment configured to invoke an application programming interface (API) [Page 16, figure 6.4.1.1-1, “API Invoker”, corresponds to the limitation “communication equipment”, API Invoker is an entity that performs the API invocation] to access a service [Page 16, figure, 6.4.1.1-1, step 1, The API invoker requests authorization grant and access token to invoke the service API], the method comprising:
transmitting, from the communication equipment [Page 16, figure 6.4.1.1-1, “API Invoker”] to API exposing equipment configured to expose the API [Page 16, figure 6.4.1.1-1, “API exposing function” corresponds to the claim limitation, “API exposing equipment”], a request to invoke the API [Page 16, 6.4.1.1-1, step 2. The API invoker sends service API invocation request to the API exposing function]; and transmitting, from the communication equipment to the API exposing equipment, an access token [Page 16, 6.4.1.1-1, step 1, The API invoker requests authorization grant and access token to invoke the service API and step 2, The API invoker sends service API invocation request to the API exposing function with the access token
received in step 1], that indicates whether a resource owner consents to the communication equipment accessing a protected resource of the API [6.4.2, this solution requires that the API invoker get authorized to invoke the service API by the resource owner before sending the service API invocation request Page 16, 6.4.1.1, “API invoker obtaining resource owner consent prior to the service API invocation”, Page 16, 6.4.1.1-1, step 1, The API invoker requests authorization grant and access token to invoke the service API. Page 16, 6.4.1.1-1, Step 2. The API invoker sends service API invocation request to the API exposing function with the access token received in step 1. Examiner Note: This implies that the access token necessarily indicates whether the consent exists. If the consent were not granted, the access token would not be issued. Possession and use of the token thus indicates that the resource owner consents to access.]
3GPP doesn’t discloses : wherein the access token includes a claim asserting that the resource owner consents, or does not consent, to the communication equipment accessing the protected resource of the API”
However, WS02 discloses: “wherein the access token includes a claim [See WSO2 throughout the documentation teaches that, “JWT access tokens and custom claims in the JWT access token”] asserting that the resource owner consents [WSO2 throughout the documentation teaches that the JWT token contains a consent ID as a custom claim, and that the consent ID is a unique identifier for a granted consent], or
3GPP and WS02 are analogous arts and are in the same field of endeavor as they both pertain and directed to resource owner consents to the device accessing a protected resource.
It would have been obvious to one having ordinary skill in the art, before the effective filing of the claimed invention, to implement in the system of 3GPP, token “wherein the access token includes a claim asserting that the resource owner consents, “ as taught by WSO2 because this would enhance the security of the system where the access token incorporates a claim validating resource owner consents.
As per independent claim 59, Independent claim 59 is a device version of the above method claim 46 and having the same scope and is rejected for the same reason as that of the above independent claim 46.
As per independent claim 51, 3GPP discloses a method performed by application programming interface (API) exposing equipment configured to expose an API to communication equipment [Page 16, figure 6.4.1.1-1, “API exposing function” corresponds to the limitation “application programming interface (API) exposing equipment”], the method comprising:
receiving, from the communication equipment [Page 16, figure 6.4.1.1-1, “API Invoker”], a request to invoke the API [Page 16, figure 6.4.1.1-1, Step 2. The API invoker sends service API invocation request to the API exposing function]; and receiving, from the communication equipment, an access token [Page 16, figure 6.4.1.1-1, Step 2. The API invoker sends service API invocation request to the API exposing function with the access token received in step 1] that indicates whether a resource owner consents to the communication equipment accessing a protected resource of the API [6.4.2, this solution requires that the API invoker get authorized to invoke the service API by the resource owner before sending the service API invocation request Page 16, 6.4.1.1, “API invoker obtaining resource owner consent prior to the service API invocation”, Page 16, 6.4.1.1-1, step 1, The API invoker requests authorization grant and access token to invoke the service API. Page 16, 6.4.1.1-1, Step 2. The API invoker sends service API invocation request to the API exposing function with the access token received in step 1. Examiner Note: This implies that the access token necessarily indicates whether the consent exists. If the consent were not granted, the access token would not be issued. Possession and use of the token thus indicates that the resource owner consents to access.]
3GPP doesn’t discloses : wherein the access token includes a claim asserting that the resource owner consents, or does not consent, to the communication equipment accessing the protected resource of the API”
However, WS02 discloses: “wherein the access token includes a claim [See WSO2 through out the documentation teaches that, “JWT access tokens and custom claims in the JWT access token”] asserting that the resource owner consents [WSO2 teaches that the JWT token contains a consent ID as a custom claim, and that the consent ID is a unique identifier for a granted consent], or
3GPP and WS02 are analogous arts and are in the same field of endeavor as they both pertain and directed to resource owner consents to the device accessing a protected resource.
It would have been obvious to one having ordinary skill in the art, before the effective filing of the claimed invention, to implement in the system of 3GPP, token “wherein the access token includes a claim asserting that the resource owner consents, “ as taught by WSO2 because this would enhance the security of the system where the access token incorporates a claim validating resource owner consents.
As per independent claim 64, Independent claim 64 is a device version of the above method claim 51 and having the same scope and is rejected for the same reason as that of the above independent claim 51.
As per independent claim 55, 3GPP a method performed by common application programming interface (API) core equipment [Page 16, Figure, 6.4.1.1-1,, “CAPIF core function” /3.3 for Abbreviations, CAPIF/ Common API Framework. “CAPIF core function” corresponds to the claim limitation, “common application programming interface (API) core equipment”], the method comprising:
receiving, from communication equipment [Page 16, figure 6.4.1.1-1, “API Invoker”], a request for an access token [Page 16, 6.4.1.1-1, step 1, The API invoker requests authorization grant and access token to invoke the service API]; and transmitting, in response to the request, an access token [Page 16, 6.4.1.1-1, Step 2. The API invoker sends service API invocation request to the API exposing function with the access token received in step 1]. that indicates whether a resource owner consents to the communication equipment accessing a protected resource of an API [Page 15, 6.4.1, CAPIF may authorize the API invoker to invoke the service API based on the user consent
slightly before the API invocation. The procedures to obtain the user consent may reuse well-known authorization procedures such as OAuth 2.0 [9]. 6.4.2, this solution requires that the API invoker get authorized to invoke the service API by the resource owner before sending the service API invocation request Page 16, 6.4.1.1, “API invoker obtaining resource owner consent prior to the service API invocation”, Page 16, 6.4.1.1-1 step 1, The API invoker requests authorization grant and access token to invoke the service API. Page 16, 6.4.1.1-1 Step 2. The API invoker sends service API invocation request to the API exposing function with the access token received in step 1. Examiner Note: This implies that the access token necessarily indicates whether the consent exists. If the consent were not granted, the access token would not be issued. Possession and use of the token thus indicates that the resource owner consents to access.]
3GPP doesn’t discloses : wherein the access token includes a claim asserting that the resource owner consents, or does not consent, to the communication equipment accessing the protected resource of the API”
However, WS02 discloses: “wherein the access token includes a claim [See WSO2 through out the documentation teaches that, “JWT access tokens and custom claims in the JWT access token”] asserting that the resource owner consents [WSO2 teaches that the JWT token contains a consent ID as a custom claim, and that the consent ID is a unique identifier for a granted consent], or
3GPP and WS02 are analogous arts and are in the same field of endeavor as they both pertain and directed to resource owner consents to the device accessing a protected resource.
It would have been obvious to one having ordinary skill in the art, before the effective filing of the claimed invention, to implement in the system of 3GPP, token “wherein the access token includes a claim asserting that the resource owner consents, “ as taught by WSO2 because this would enhance the security of the system where the access token incorporates a claim validating resource owner consents.
As per independent claim 68, Independent claim 68 is a device version of the above method claim 55 and having the same scope and is rejected for the same reason as that of the above independent claim 55.
As per dependent claim 72, is rejected for the same reason as that of the above independent claim 46.
The following is referring to dependent claims 47, 49, 52, 58, 60, 62, 65 and 71:
As per dependent claim 47, the combination of 3GPP and WS02 discloses the method/device/apparatus as applied to claim 46 above. Furthermore, 3GPP discloses the method/device/apparatus, wherein the access token is included in the request [Page 16, figure 6.4.1.1-1 Step 2. The API invoker sends service API invocation request to the API exposing function with the access token received in step 1.]
, or wherein transmitting the request and the access token comprises transmitting, to the API exposing equipment [Page 16, figure 6.4.1.1-1, “API exposing function” corresponds to the claim limitation, “API exposing equipment”], a message that includes both the request and the access token [Page 16, figure 6.4.1.1-1 step 1, The API invoker requests authorization grant and access token to invoke the service API. Page 16, figure 6.4.1.1-1 Step 2. The API invoker sends service API invocation request to the API exposing function with the access token received in step 1.]
As per dependent claim 60, dependent claim 60 is a device version of the above method claim 47 and having the same scope and is rejected for the same reason as that of the above dependent claim 60.
As per dependent claim 49, the combination of 3GPP and WS02 discloses the method/device/apparatus as applied to claim 46 above. Furthermore, 3GPP discloses the method/device/apparatus, further comprising: transmitting, from the communication equipment [Page 16, figure 6.4.1.1-1, “API Invoker”], to common API core equipment [Page 16, Figure, 6.4.1.1-1, “CAPIF core function” /3.3 for Abbreviations, CAPIF/ Common API Framework. “CAPIF core function” corresponds to the claim limitation, “common application programming interface (API) core equipment”], a request for an access token [[Page 16, 6.4.1.1-1, step 1, The API invoker requests authorization grant and access token to invoke the service API]; and receiving the access token in response to the request [Page 16, 6.4.1.1-1, Step 2. The API invoker sends service API invocation request to the API exposing function with the access token received in step 1].
As per dependent claim 62, dependent claim 62 is a device version of the above method claim 49 and having the same scope and is rejected for the same reason as that of the above dependent claim 49.
As per dependent claim 52, the combination of 3GPP and WS02 discloses the method/device/apparatus as applied to claim 51 above. Furthermore, 3GPP discloses the method/device/apparatus, wherein the access token is included in the request [[Page 16, figure 6.4.1.1-1 Step 2. The API invoker sends service API invocation request to the API exposing function with the access token received in step 1.], or wherein receiving the request and the access token comprises receiving, from the communication equipment [Page 16, figure 6.4.1.1-1, “API Invoker”], a message that includes both the request and the access token [Page 16, figure 6.4.1.1-1 step 1, The API invoker requests authorization grant and access token to invoke the service API. Page 16, figure 6.4.1.1-1 Step 2. The API invoker sends service API invocation request to the API exposing function with the access token received in step 1.]
As per dependent claim 65, dependent claim 65 is a device version of the above method claim 52 and having the same scope and is rejected for the same reason as that of the above dependent claim 52.
As per dependent claim 58, the combination of 3GPP and WS02 discloses the method/device/apparatus as applied to claim 55 above. Furthermore, 3GPP discloses the method/device/apparatus, further comprising: responsive to receiving the request for the access token [[Page 16, 6.4.1.1-1, Step 1, step 1, The API invoker requests authorization grant and access token to invoke the service API];, retrieving user consent parameters from unified data management (UDM) equipment [Page 14, Figure 6.3.1.3-1, Step 3, obtain user consent from resource owner. Page 15, The API exposing function identifies the individual resource owner clients(corresponds to the API invoker) by interacting with HSS/UDM as specified in TS 23.682[7]. Examiner Note: Consent information is managed and retrieved via HSS/UDM in 3GPP architectures], wherein the user consent parameters indicate whether the resource owner has granted consent to the communication equipment accessing the protected resource of the API [6.4.2, this solution requires that the API invoker get authorized to invoke the service API by the resource owner before sending the service API invocation request Page 16, 6.4.1.1, “API invoker obtaining resource owner consent prior to the service API invocation”, step 1, The API invoker requests authorization grant and access token to invoke the service API. Step 2. The API invoker sends service API invocation request to the API exposing function with the access token received in step 1. Examiner Note: This implies that the access token necessarily indicates whether the consent exists. If the consent were not granted, the access token would not be issued. Possession and use of the token thus indicates that the resource owner consents to access.]; and generating the access token [step 1, The API invoker requests authorization grant and access token to invoke the service API. Step 2. The API invoker sends service API invocation request to the API exposing function with the access token received in step 1] based on the user consent parameters. [6.4.2, this solution requires that the API invoker get authorized to invoke the service API by the resource owner before sending the service API invocation request Page 16, 6.4.1.1, “API invoker obtaining resource owner consent prior to the service API invocation”, Page 16, 6.4.1.1-1, step 1, The API invoker requests authorization grant and access token to invoke the service API. [Page 16, 6.4.1.1-1, Step 2. The API invoker sends service API invocation request to the API exposing function with the access token received in step 1. Examiner Note: This implies that the access token necessarily indicates whether the consent exists. If the consent were not granted, the access token would not be issued. Possession and use of the token thus indicates that the resource owner consents to access.]
As per dependent claim 71, dependent claim 71 is a device version of the above method claim 58 and having the same scope and is rejected for the same reason as that of the above dependent claim 58.
10. Claims 48, 53-54, 56, 61, 66-67 and 69 are rejected under 35 U.S.C. 103 as being unpatentable over NPL Document, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Study on application enablement aspects for subscriber-aware northbound API access; (Release 18) (here in after referred as 3GPP) (TR 23.700-95) (Pub. Date: 04/2022) (Pages 1-25). (This prior art is provided with the IDS) ) in view of NPL document, titled, WS02 Open Banking Accelerator 3.0.0 documentation –“JWT Access Token”(Herein after referred as WS02) and in view of Venkataraman Uppili Srinivasan (herein after referred as Srinivasan) (US Publication No. US20130086645A1, Pub. Date: 03/13/2013)
As per dependent claim 48, 3GPP and WS02 discloses the method/device/apparatus as applied to claim 46 above. Furthermore, 3GPP discloses the method/device/apparatus, wherein the access token that indicates whether a resource owner consents/doesn’t consent to the communication equipment accessing a protected resource of an API [Page 15, 6.4.1, CAPIF may authorize the API invoker to invoke the service API based on the user consent slightly before the API invocation. The procedures to obtain the user consent may reuse well-known authorization procedures such as OAuth 2.0 [9]. 6.4.2, this solution requires that the API invoker get authorized to invoke the service API by the resource owner before sending the service API invocation request Page 16, 6.4.1.1, “API invoker obtaining resource owner consent prior to the service API invocation”, Page 16, 6.4.1.1-1 step 1, The API invoker requests authorization grant and access token to invoke the service API. Page 16, 6.4.1.1-1 Step 2. The API invoker sends service API invocation request to the API exposing function with the access token received in step 1. Examiner Note: This implies that the access token necessarily indicates whether the consent exists. If the consent were not granted, the access token would not be issued. Possession and use of the token thus indicates that the resource owner consents to access.]
3GPP and WSO2 doesn’t explicitly disclose the following underlined claim limitation: wherein the access token: or also asserts that the communication equipment is authorized to access the API.
However Srinivasan explicitly discloses the above underlined claim limitation:” wherein the access token: also asserts that the communication equipment is authorized to access the API “ [Para. 0032, 0036-0037, In an embodiment of the invention, resources & scope registry 224 stores resource information, scopes, and miscellaneous metadata related to resources and services exposed via OAuth authorization server 220. In an embodiment of the invention, client registry 236 stores trust keys and secrets for authorized remote clients (e.g., client application 204). In an embodiment, token-scope registry 222 stores access tokens and refresh tokens that are issued to clients (e.g., client application 204) based on user (e.g., resource owner 202) consent. In an embodiment, token-scope registry 222 stores AuthZ scope information that is associated with issued access tokens and Para. 0035-0036, Para. 0036, Para. 0036, intercept the token and validate the token with OAuth authorization server 220 (e.g., via access token validation API 214) before allowing client application 204 to access the particular resource. If the particular resource that client application 204 attempts to access does not fall within the scope that is mapped the access token in token-scope registry 222 (e.g., if client application 204 attempts to access a folder that is outside of the scope of access to which resource owner 202 previously consented), then OAuth authorization server 220 will not validate the token, and resource server 210 will refuse to grant client application 204 access to the particular resource. Thus, scope of access is based on specific consent to that scope by resource owner 202. Resource owner 202 has the opportunity to refuse to give consent to a specific scope requested by client application 204, in which case OAuth authorization server 220 will not create an access token for client application 204.].
3GPP, WS02 and Srinivasan are analogous arts and are in the same field of endeavor as they both pertain and directed to resource owner consents to the device accessing a protected resource.
It would have been obvious to one having ordinary skill in the art, before the effective filing of the claimed invention, to implement in the system of 3GPP, token including/encoding a claim assertion such as, “wherein the access token: includes a claim asserting that the resource owner consents, or does not consent, to the communication equipment accessing the protected resource of the API; and/or also asserts that the communication equipment is authorized to access the API“ as taught by Srinivasan because this would enhance the security of the system by enforcing the access restriction at the time where access tokens are validated per the scope that is encoded by the issued tokens [Srinivasan , Para 0036-0037,.Enforcement requires an understanding of the scope that is encoded by the access token. Access tokens are issued by OAuth authorization server 220 per the scope definitions. Access tokens are validated per the scope that is encoded by the issued tokens.]
As per dependent claim 61, dependent claim 61 is a device version of the above method claim 48 and having the same scope and is rejected for the same reason as that of the above dependent claim 48.
As per dependent claim 53, 3GPP and WS02 discloses the method/device/apparatus as applied to claim 51 above. Furthermore, 3GPP discloses the method/device/apparatus, wherein the access token that indicates whether a resource owner consents/doesn’t consent to the communication equipment accessing a protected resource of an API [Page 15, 6.4.1, CAPIF may authorize the API invoker to invoke the service API based on the user consent slightly before the API invocation. The procedures to obtain the user consent may reuse well-known authorization procedures such as OAuth 2.0 [9]. 6.4.2, this solution requires that the API invoker get authorized to invoke the service API by the resource owner before sending the service API invocation request Page 16, 6.4.1.1, “API invoker obtaining resource owner consent prior to the service API invocation”, Page 16, 6.4.1.1-1 step 1, The API invoker requests authorization grant and access token to invoke the service API. Page 16, 6.4.1.1-1 Step 2. The API invoker sends service API invocation request to the API exposing function with the access token received in step 1. Examiner Note: This implies that the access token necessarily indicates whether the consent exists. If the consent were not granted, the access token would not be issued. Possession and use of the token thus indicates that the resource owner consents to access.]
3GPP and WS02 doesn’t explicitly disclose the following underlined claim limitation: wherein the access token: includes a claim asserting that the resource owner consents, or does not consent, to the communication equipment accessing the protected resource of the API; and/or also asserts that the communication equipment is authorized to access the API.
However, Srinivasan explicitly discloses the above underlined claim limitation:” wherein the access token: includes a claim asserting that the resource owner consents, or does not consent, to the communication equipment accessing the protected resource of the API; and/or also asserts that the communication equipment is authorized to access the API “ [Para. 0032, 0036-0037, In an embodiment of the invention, resources & scope registry 224 stores resource information, scopes, and miscellaneous metadata related to resources and services exposed via OAuth authorization server 220. In an embodiment of the invention, client registry 236 stores trust keys and secrets for authorized remote clients (e.g., client application 204). In an embodiment, token-scope registry 222 stores access tokens and refresh tokens that are issued to clients (e.g., client application 204) based on user (e.g., resource owner 202) consent. In an embodiment, token-scope registry 222 stores AuthZ scope information that is associated with issued access tokens and Para. 0035-0036, Para. 0036, Para. 0036, intercept the token and validate the token with OAuth authorization server 220 (e.g., via access token validation API 214) before allowing client application 204 to access the particular resource. If the particular resource that client application 204 attempts to access does not fall within the scope that is mapped the access token in token-scope registry 222 (e.g., if client application 204 attempts to access a folder that is outside of the scope of access to which resource owner 202 previously consented), then OAuth authorization server 220 will not validate the token, and resource server 210 will refuse to grant client application 204 access to the particular resource. Thus, scope of access is based on specific consent to that scope by resource owner 202. Resource owner 202 has the opportunity to refuse to give consent to a specific scope requested by client application 204, in which case OAuth authorization server 220 will not create an access token for client application 204.].
3GPP, WS02 and Srinivasan are analogous arts and are in the same field of endeavor as they both pertain and directed to resource owner consents to the device accessing a protected resource.
It would have been obvious to one having ordinary skill in the art, before the effective filing of the claimed invention, to implement in the system of 3GPP, token including/encoding a claim assertion such as, “wherein the access token: includes a claim asserting that the resource owner consents, or does not consent, to the communication equipment accessing the protected resource of the API; and/or also asserts that the communication equipment is authorized to access the API“ as taught by Srinivasan because this would enhance the security of the system by enforcing the access restriction at the time where access tokens are validated per the scope that is encoded by the issued tokens [Srinivasan , Para 0036-0037,….Enforcement requires an understanding of the scope that is encoded by the access token. Access tokens are issued by OAuth authorization server 220 per the scope definitions. Access tokens are validated per the scope that is encoded by the issued tokens.]
As per dependent claim 66, dependent claim 66 is a device version of the above method claim 53 and having the same scope and is rejected for the same reason as that of the above dependent claim 53.
As per dependent claim 54, 3GPP and WS02 discloses the method/device/apparatus as applied to claim 51 above. Furthermore, 3GPP discloses the method/device/apparatus, wherein the access token that indicates whether a resource owner consents/doesn’t consent to the communication equipment accessing a protected resource of an API [Page 15, 6.4.1, CAPIF may authorize the API invoker to invoke the service API based on the user consent slightly before the API invocation. The procedures to obtain the user consent may reuse well-known authorization procedures such as OAuth 2.0 [9]. 6.4.2, this solution requires that the API invoker get authorized to invoke the service API by the resource owner before sending the service API invocation request Page 16, 6.4.1.1, “API invoker obtaining resource owner consent prior to the service API invocation”, Page 16, 6.4.1.1-1 step 1, The API invoker requests authorization grant and access token to invoke the service API. Page 16, 6.4.1.1-1 Step 2. The API invoker sends service API invocation request to the API exposing function with the access token received in step 1. Examiner Note: This implies that the access token necessarily indicates whether the consent exists. If the consent were not granted, the access token would not be issued. Possession and use of the token thus indicates that the resource owner consents to access.]
3GPP and WS02 doesn’t explicitly disclose the following underlined claim limitation: wherein the access token: includes a claim asserting that the resource owner consents, to the communication equipment accessing the protected resource of the API; wherein the method further comprises: verifying the request against the one or more claims in the access token; and allowing or rejecting the request depending on said verifying.
However, Srinivasan explicitly discloses the above underlined claim limitation:” wherein the access token: includes a claim asserting that the resource owner consents to the communication equipment accessing the protected resource of the API; wherein the method further comprises: verifying the request against the one or more claims in the access token; and allowing or rejecting the request depending on said verifying. [Para. 0032, 0036-0037, In an embodiment of the invention, resources & scope registry 224 stores resource information, scopes, and miscellaneous metadata related to resources and services exposed via OAuth authorization server 220. In an embodiment of the invention, client registry 236 stores trust keys and secrets for authorized remote clients (e.g., client application 204). In an embodiment, token-scope registry 222 stores access tokens and refresh tokens that are issued to clients (e.g., client application 204) based on user (e.g., resource owner 202) consent. In an embodiment, token-scope registry 222 stores AuthZ scope information that is associated with issued access tokens and Para. 0035-0036, Para. 0036, Para. 0036, intercept the token and validate the token with OAuth authorization server 220 (e.g., via access token validation API 214) before allowing client application 204 to access the particular resource. If the particular resource that client application 204 attempts to access does not fall within the scope that is mapped the access token in token-scope registry 222 (e.g., if client application 204 attempts to access a folder that is outside of the scope of access to which resource owner 202 previously consented), then OAuth authorization server 220 will not validate the token, and resource server 210 will refuse to grant client application 204 access to the particular resource. Thus, scope of access is based on specific consent to that scope by resource owner 202. Resource owner 202 has the opportunity to refuse to give consent to a specific scope requested by client application 204, in which case OAuth authorization server 220 will not create an access token for client application 204. and Para. 0036-0037¸In one embodiment of the invention, each client application's request to access a resource maintained by resource server 210 also specifies a scope that is mapped to resource server 210 in resources & scope registry 224, and it is this specified scope for which the consent of resource owner 202 is requested as discussed above.
According to an embodiment of the invention, consistent with the discussion above, enforcement of access restrictions occurs at the time that client application 204 presents an access token to resource server 210. Enforcement requires an understanding of the scope that is encoded by the access token. Access tokens are issued by OAuth authorization server 220 per the scope definitions. Access tokens are validated per the scope that is encoded by the issued tokens].
3GPP, WS02 and Srinivasan are analogous arts and are in the same field of endeavor as they both pertain and directed to resource owner consents to the device accessing a protected resource.
It would have been obvious to one having ordinary skill in the art, before the effective filing of the claimed invention, to implement in the system of 3GPP and WS02, token verification such as “wherein the access token: includes a claim asserting that the resource owner consents to the communication equipment accessing the protected resource of the API; wherein the method further comprises: verifying the request against the one or more claims in the access token; and allowing or rejecting the request depending on said verifying “as taught by Srinivasan because this would enhance the security of the system by enforcing the access restriction at the time where access tokens are validated per the scope that is encoded by the issued tokens. [Srinivasan , Para 0036-0037 ….Enforcement requires an understanding of the scope that is encoded by the access token. Access tokens are issued by OAuth authorization server 220 per the scope definitions. Access tokens are validated per the scope that is encoded by the issued tokens.]
As per dependent claim 67, dependent claim 67 is a device version of the above method claim 54 and having the same scope and is rejected for the same reason as that of the above dependent claim 54.
As per dependent claim 56, 3GPP and WS02 discloses the method/device/apparatus as applied to claim 55 above. Furthermore, 3GPP discloses the method/device/apparatus, wherein the access token that indicates whether a resource owner consents/doesn’t consent to the communication equipment accessing a protected resource of an API [Page 15, 6.4.1, CAPIF may authorize the API invoker to invoke the service API based on the user consent slightly before the API invocation. The procedures to obtain the user consent may reuse well-known authorization procedures such as OAuth 2.0 [9]. 6.4.2, this solution requires that the API invoker get authorized to invoke the service API by the resource owner before sending the service API invocation request Page 16, 6.4.1.1, “API invoker obtaining resource owner consent prior to the service API invocation”, Page 16, 6.4.1.1-1 step 1, The API invoker requests authorization grant and access token to invoke the service API. Page 16, 6.4.1.1-1 Step 2. The API invoker sends service API invocation request to the API exposing function with the access token received in step 1. Examiner Note: This implies that the access token necessarily indicates whether the consent exists. If the consent were not granted, the access token would not be issued. Possession and use of the token thus indicates that the resource owner consents to access.]
3GPP and WS02 doesn’t explicitly disclose the following underlined claim limitation: wherein the access token: includes a claim asserting that the resource owner consents, or does not consent, to the communication equipment accessing the protected resource of the API; and/or also asserts that the communication equipment is authorized to access the API.
However, Srinivasan explicitly discloses the above underlined claim limitation:” wherein the access token: includes a claim asserting that the resource owner consents, or does not consent, to the communication equipment accessing the protected resource of the API; and/or also asserts that the communication equipment is authorized to access the API “ [Para. 0032, 0036-0037, In an embodiment of the invention, resources & scope registry 224 stores resource information, scopes, and miscellaneous metadata related to resources and services exposed via OAuth authorization server 220. In an embodiment of the invention, client registry 236 stores trust keys and secrets for authorized remote clients (e.g., client application 204). In an embodiment, token-scope registry 222 stores access tokens and refresh tokens that are issued to clients (e.g., client application 204) based on user (e.g., resource owner 202) consent. In an embodiment, token-scope registry 222 stores AuthZ scope information that is associated with issued access tokens and Para. 0035-0036, Para. 0036, Para. 0036, intercept the token and validate the token with OAuth authorization server 220 (e.g., via access token validation API 214) before allowing client application 204 to access the particular resource. If the particular resource that client application 204 attempts to access does not fall within the scope that is mapped the access token in token-scope registry 222 (e.g., if client application 204 attempts to access a folder that is outside of the scope of access to which resource owner 202 previously consented), then OAuth authorization server 220 will not validate the token, and resource server 210 will refuse to grant client application 204 access to the particular resource. Thus, scope of access is based on specific consent to that scope by resource owner 202. Resource owner 202 has the opportunity to refuse to give consent to a specific scope requested by client application 204, in which case OAuth authorization server 220 will not create an access token for client application 204.].
3GPP, WS02 and Srinivasan are analogous arts and are in the same field of endeavor as they both pertain and directed to resource owner consents to the device accessing a protected resource.
It would have been obvious to one having ordinary skill in the art, before the effective filing of the claimed invention, to implement in the system of 3GPP and WS02, token including/encoding a claim assertion such as, “wherein the access token: includes a claim asserting that the resource owner consents, or does not consent, to the communication equipment accessing the protected resource of the API; and/or also asserts that the communication equipment is authorized to access the API“ as taught by Srinivasan because this would enhance the security of the system by enforcing the access restriction at the time where access tokens are validated per the scope that is encoded by the issued tokens [Srinivasan , Para 0036-0037, ….Enforcement requires an understanding of the scope that is encoded by the access token. Access tokens are issued by OAuth authorization server 220 per the scope definitions. Access tokens are validated per the scope that is encoded by the issued tokens.]
As per dependent claim 69, dependent claim 69 is a device version of the above method claim 56 and having the same scope and is rejected for the same reason as that of the above dependent claim 56.
11. Claims 50, 57, 63 and 70 are rejected under 35 U.S.C. 103 as being unpatentable over NPL Document, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Study on application enablement aspects for subscriber-aware northbound API access; (Release 18) (here in after referred as 3GPP) (TR 23.700-95) (Pub. Date: 04/2022) (Pages 1-25). (This prior art is provided with the IDS) in view of NPL document, titled, WS02 Open Banking Accelerator 3.0.0 documentation –“JWT Access Token”(Herein after referred as WS02)
And in view of (RFC 6749, The OAuth 2.0 Authorization Framework by D. Hardt, Ed, Microsoft October 2012) (herein after referred as RFC6749)
As per dependent claim 50, 3GPP and WS02 discloses the method/device/apparatus as applied to claim 51 above. Furthermore, 3GPP discloses the method/device/apparatus, before transmitting the request for the access token: transmitting an authorization request to the common API core equipment [Page 16, 6.4.1.1-1 step 1, The API invoker requests authorization grant and access token to invoke the service API]; and receiving, in response to the authorization request, a token Page 16, 6.4.1.1-1 Step 2. The API invoker sends service API invocation request to the API exposing function with the access token received in step 1; step 1, The API invoker requests authorization grant and access token to invoke the service API. [6.4.2, this solution requires that the API invoker get authorized to invoke the service API by the resource owner before sending the service API invocation request Page 16, 6.4.1.1, “API invoker obtaining resource owner consent prior to the service API invocation”, Examiner Note: This implies that the access token necessarily indicates whether the consent exists. If the consent were not granted, the access token would not be issued. Possession and use of the token thus indicates that the resource owner consents to access.]; wherein the request
3GPP and WS02 doesn’t explicitly disclose the following underlined claim limitation: ”an authorization code that is a credential representing authorization of the resource owner and wherein the request for the access token includes the authorization code”.
However, RFC 6749 explicitly discloses the above underlined claim limitation:” an authorization code that is a credential representing authorization of the resource owner [4.1.2, Authorization Response, “If the resource owner grants the access request, the authorization server issues an authorization code and delivers it to the client by adding the following parameters to the query component…1.3. Authorization Grant; An authorization grant is a credential representing the resource owner's authorization (to access its protected resources) used by the client to obtain an access token. This specification defines four grant types -- authorization code, implicit, resource owner password credentials, and client credentials -1.3.1, Authorization code: The authorization code is obtained by using an authorization server as an intermediary between the client and resource owner. Instead of requesting authorization directly from the resource owner, the client directs the resource owner to an authorization server (via its user-agent as defined in [RFC2616]), which in turn directs the resource owner back to the client with the authorization code. Before directing the resource owner back to the client with the authorization code, the authorization server authenticates the resource owner and obtains authorization. Because the resource owner only authenticates with the authorization server, the resource owner's credentials are never shared with the client. ]and wherein the request for the access token includes the authorization code” [4.1.3, Access Token Request, The client makes a request to the token endpoint by sending the following parameters using the "application/x-www-form-urlencoded" format per Appendix B with a character encoding of UTF-8 in the HTTP request entity-body: grant-type REQUIRED. Value MUST be set to "authorization-code"]
3GPP, WS02 and RFC 6749 are analogous arts and are in the same field of endeavor as they both pertain and directed to resource owner consents to the device accessing a protected resource.
It would have been obvious to one having ordinary skill in the art, before the effective filing of the claimed invention, to implement in the system of 3GPP and WS02, encoding token with credential such as “an authorization code that is a credential representing authorization of the resource owner and wherein the request for the access token includes the authorization code” as taught by RFC 6749 because this would enhance the security of the system by authenticating the client, as well as the transmission of the access token directly to the client without passing it through the resource owner's user-agent and potentially exposing it to others, including the resource owner.
[RFC 6749, 1.3.1, The authorization code provides a few important security benefits, such as the ability to authenticate the client, as well as the transmission of the access token directly to the client without passing it through the resource owner's user-agent and potentially exposing it to others, including the resource owner.]
As per dependent claim 63, dependent claim 63 is a device version of the above method claim 50 and having the same scope and is rejected for the same reason as that of the above dependent claim 50.
As per dependent claim 57, 3GPP and WS02 discloses the method/device/apparatus as applied to claim 55 above. Furthermore, 3GPP discloses the method/device/apparatus, before receiving the request for the access token: receiving an authorization request from the communication equipment [Page 16, 6.4.1.1-1, Step 1, step 1, The API invoker requests authorization grant and access token to invoke the service API]; responsive to receiving the authorization request, retrieving user consent parameters from unified data management (UDM) equipment[Page 14, Figure 6.3.1.3-1, Step 3, obtain user consent from resource owner, Page 15, The API exposing function identifies the individual resource owner clients(corresponds to the API invoker) by interacting with HSS/UDM as specified in TS 23.682[7]. Examiner Note: Consent information is managed and retrieved via HSS/UDM in 3GPP architectures], wherein the user consent parameters indicate whether the resource owner has granted consent to the communication equipment accessing the protected resource of the API [6.4.2, this solution requires that the API invoker get authorized to invoke the service API by the resource owner before sending the service API invocation request Page 16, 6.4.1.1, “API invoker obtaining resource owner consent prior to the service API invocation”, Page 16, 6.4.1.1-1, step 1, The API invoker requests authorization grant and access token to invoke the service API. [Page 16, 6.4.1.1-1, Step 2. The API invoker sends service API invocation request to the API exposing function with the access token received in step 1. Examiner Note: This implies that the access token necessarily indicates whether the consent exists. If the consent were not granted, the access token would not be issued. Possession and use of the token thus indicates that the resource owner consents to access.]; and generating a token [Page 16, 6.4.1.1-1, step 1, The API invoker requests authorization grant and access token to invoke the service API., Step 2. The API invoker sends service API invocation request to the API exposing function with the access token received in step 1. ; transmitting, in response to the authorization request, the token to the communication equipment [Page 16, 6.4.1.1-1, step 2, The API invoker sends service API invocation request to the API exposing function with the access token received in step 1]; wherein the request for the access token [Page 16, 6.4.1.1-1, step 1, The API invoker requests authorization grant and access token to invoke the service API]
3GPP and WS02 doesn’t explicitly disclose the following underlined claim limitation: “generating an authorization code based on the user consent parameters, transmitting, in response to the authorization request, the authorization code to the communication equipment and the access token includes the authorization code; wherein the authorization code is a credential representing authorization of the resource owner”
However, RFC 6749, explicitly discloses the above underlined claim limitation: “generating an authorization code based on the user consent parameters [4.1.2, If the resource owner grants the access request, the authorization server issues an authorization code and delivers it to the client], transmitting, in response to the authorization request, the authorization code to the communication equipment [4.1.2, If the resource owner grants the access request, the authorization server issues an authorization code and delivers it to the client by adding the following parameters to the query component of the redirection]and the access token includes the authorization code; wherein the authorization code is a credential representing authorization of the resource owner”[1.3. Authorization Grant; An authorization grant is a credential representing the resource owner's authorization (to access its protected resources) used by the client to obtain an access token. This specification defines four grant types -- authorization code, implicit, resource owner password credentials, and client credentials -1.3.1, Authorization code: The authorization code is obtained by using an authorization server as an intermediary between the client and resource owner. Instead of requesting authorization directly from the resource owner, the client directs the resource owner to an authorization server (via its user-agent as defined in [RFC2616]), which in turn directs the resource owner back to the client with the authorization code. Before directing the resource owner back to the client with the authorization code, the authorization server authenticates the resource owner and obtains authorization. Because the resource owner only authenticates with the authorization server, the resource owner's credentials are never shared with the client.]
3GPP, WS02 and RFC 6749 are analogous arts and are in the same field of endeavor as they both pertain and directed to resource owner consents to the device accessing a protected resource.
It would have been obvious to one having ordinary skill in the art, before the effective filing of the claimed invention, to implement in the system of 3GPP and WS02, token and authorization code such as “an authorization code based on the user consent parameters and the access token includes the authorization code; wherein the authorization code is a credential representing authorization of the resource owner” as taught by RFC 6749 because this would enhance the security of the system by authenticating the client, as well as the transmission of the access token directly to the client without passing it through the resource owner's user-agent and potentially exposing it to others, including the resource owner.[RFC 6749, 1.3.1, The authorization code provides a few important security benefits, such as the ability to authenticate the client, as well as the transmission of the access token directly to the client without passing it through the resource owner's user-agent and potentially exposing it to others, including the resource owner.]
As per dependent claim 70, dependent claim 70 is a device version of the above method claim 57 and having the same scope and is rejected for the same reason as that of the above dependent claim 57.
Conclusion
12. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
a. US Publication No. 2021/0136114 A1 to Barhudarian discloses implementing policy at a resource provider computer system. The method includes a resource provider computer system receiving policy from an identity provider system, the policy being related to an entity that authenticates using the identity provider computer system. The resource provider computer system receives a request for resources from the entity and an access token from the entity. The access token was obtained by the entity from the identity provider computer system as a result of the entity authenticating with the identity provider computer system. The resource provider computer system evaluates the request with respect to the policy. The resource provider computer system responds to the request based on evaluating the request with respect to the policy.
b. US Publication No. 2021/0152542 A1 to Palop discloses Access tokens with scope expressions of personal data policies, an example device includes a communications interface to communicate data with a network and a processor connected to the communications interface. The processor is to generate an access request and communicate the access request to an authorization service via the communications interface. The access request includes a requested scope of access to a resource available on the network. The processor is further to receive an access token from the authorization service. The access token contains a scope expression indicative of a personal data policy of an authorized scope of access to the resource. The processor is further to request access to the resource with the access token containing the scope expression indicative of the personal data policy.
c. US Publication No. 2014/0075513 A1 Trammel discloses techniques for providing a device token protocol for authorization and persistent authentication shared across applications are disclosed. In some embodiments, a device token protocol for authorization and persistent authentication shared across applications includes sending user credentials to a remote server to authenticate a user on a device for a plurality of applications; and receiving a device token from the remote server for the user to authenticate the user for the plurality of applications on the device, in which the device token facilitates authentication and authorization.
d. See the other cited prior arts.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAMSON B LEMMA whose telephone number is 571-272-3806. The examiner can normally be reached on M-F 8am-10pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor Yin-Chen Shaw can be reached on 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 an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/SAMSON B LEMMA/Primary Examiner, Art Unit 2498
Prosecution Insights