DETAILED ACTION
Claims 1-2, 4-7, 10-12, 15, 19- 22, 24 and 27-31 are presented for consideration.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-2, 4-7, 10-12, 15, 19-22, 24 and 27-31 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Hu et al. [ US Patent Application No 2025/0184731 ].
As per claim 1, Hu discloses the invention as claimed including a method for invoking a resource [ i.e. permission to access data of a target user ] [ Abstract ], performed by a resource owner [ i.e. the AEF can authorize the API invoker to access an API and process data of a user ] [ Figure 2(b); and paragraph 0007 ], comprising:
receiving at least one of an authorization request for the resource and/or or an application programming interface (API) authorization request from an API invoker [ i.e. the API invocation request message to the AEF ] [ S226, Figure 2(b); and paragraphs 0080, and 0235 ], wherein the authorization request for the resource is used to request configured to access, set, or modify the resource of the resource owner [ i.e. user consents to authorize to operate the data of the target user ] [ paragraphs 0071, and 0103 ];
sending an authorization code request to a first entity [ i.e. the CCF receives a third request message from an AEF ] , the authorization code request being configured to request an authorization code [ i.e. where the third request message is used to request to obtain an access policy for the API invoker to invoke the target API, and access control policy information includes an allowed access policy for the API invoker ID to request service API ID ] [ S227, Figure 2(b); and paragraphs 0091, 0092, an d0244 ]; and
sending the authorization code received from the first entity to the API invoker [ i.e. AEF sends an API invocation response message to the API invoker ] [ S220, Figure 2(b); and paragraphs 0247, and 0248 ].
As per claim 2, Hu discloses performing mutual authentication with the API invoker; and in the case that the mutual authentication is passed, establishing a first connection between the resource owner and the API invoker, wherein the first connection is a secure connection for transmitting the at least one of the authorization request for the resource and/or or the API authorization request [ i.e. establish a TLS connection ] [ S225, Figure 2(b); and paragraph 0233 ].
As per claim 4, Hu discloses in the case that the API invoker obtains authorization of a service, receiving the authorization request for the resource from the API invoker; and in the case that the API invoker does not obtain the authorization of the service, receiving the authorization request for the resource and the API authorization request from the API invoker [ i.e. AEF can authorize the API invoker to access an API and process data of a user ] [ paragraphs 0069, and 0483 ], wherein the authorization request for the resource comprises at least one of: an API invoker identity (ID), a resource owner ID, or a target resource ID, and the API authorization request comprises a service identifier [ i.e. API invoker ID, service API ID ] [ paragraphs 0207, and 0213 ].
As per claim 5, Hu discloses wherein the service identifier comprises at least one of: a service name; a service operation name; an operation semantic identifier; or an API name [ i.e. service API name ] [ paragraphs 0193, and 0208 ].
As per claim 6, Hu discloses performing mutual authentication with the first entity; and in the case that the mutual authentication is passed, establishing a second connection between the resource owner and the first entity, wherein the second connection is a secure connection for transmitting the authorization code request and a response [ i.e. establish TLS connection ] [ Figure 2(b); and paragraphs 0233, and 0234 ].
As per claim 7, Hu discloses performing the mutual authentication based on at least one of a certificate-based authentication mechanism; a generic bootstrapping architecture (GBA)-based authentication mechanism; an authentication and key management for applications (AKMA)-based authentication mechanism; a transport layer security with pre-shared key (TLS-PSK); or an open authorization (OAuth) token-based authentication mechanism [ paragraphs 0204, and 0234 ], wherein the method further comprises: in the case that the authorization request for the resource is authorized and the API invoker obtains the authorization of the service, receiving the authorization code from the first entity [ paragraphs 0203, and 0204 ].
9. As per claim 10, Hu discloses wherein the resource owner is a UE, and the resource is at least one of quality of service and/or or location information of the UE [ i.e. information of the user ] [ paragraphs 0003, and 0183 ].
10. As per claim 11, Hu discloses the invention as claimed including a method for invoking a resource [ i.e. permission to access data of a target user ] [ Abstract ], performed by a first entity [ i.e. CCF ] [ Figure 2(b) ], comprising:
receiving an authorization code request from a resource owner [ i.e. the CCF receives a third request message from an AEF ], the authorization code request being configured to request an authorization code [ i.e. where the third request message is used to request to obtain an access policy for the API invoker to invoke the target API, and access control policy information includes an allowed access policy for the API invoker ID to request service API ID ] [ S227, Figure 2(b); and paragraphs 0091, 0092, an d0244 ];
sending the authorization code to the resource owner [ i.e. the CCF sends an access control policy obtaining response message to the AEF ] [ S228, Figure 2(b); and paragraph 0241 ];
receiving the authorization code from an application programming interface (API) invoker [ i.e. the API invoker sends a first request message to the CCF ] [ S306, Figure 3; and paragraph 0441 ]; and
generating a token based on the authorization code and sending the token to the API invoker [ i.e. the CCF sends a second token to the API invoker ] [ S307, Figure 3; and paragraphs 0089, and 0445 ].
11. As per claim 12, Hu discloses performing mutual authentication with the resource owner; and in the case that the mutual authentication is passed, establishing a second connection between the resource owner and the first entity, wherein the second connection is a secure connection for transmitting the authorization code request and a response [ Figure 2(b); and paragraphs 0233-0237 ].
12. As per claim 15, Hu discloses in the case that the authorization request for the resource is granted and the API invoker obtains an authorization of a service, generating the authorization code [ i.e. the CCF sends an access control policy obtaining response message to the AEF ] [ S228, Figure 2(b); and paragraph 0241 ].
13. As per claim 19, Hu discloses at least one of: sending at least one of an access token and/or or a refresh token to the API invoker; or receiving the refresh token from the API invoker, and sending the access token to the API invoker based on the refresh token [ i.e. the authorization response message includes a first token, the first token indicates that the API invoker has permission to access the data of the target user ] [ paragraph 0085 ].
14. As per claim 20, Hu discloses wherein the first entity is a common application programming interface framework (CAPIF) core function/authorization function [ i.e. CCF ] [ Figure 2(b) ].
15. As per claim 21, Hu discloses the invention as claimed including a method for invoking a resource [ i.e. permission to access data of a target user ] [ Abstract ], performed by an application programming interface (API) invoker [ i.e. API invoker ] [ Figure 3 ], comprising:
sending at least one of an authorization request for the resource and/or or an API authorization request to a resource owner [ i.e. the API invocation request message to the AEF ] [ S226, Figure 2(b); and paragraphs 0080, and 0235 ], wherein the authorization request for the resource is used to request configured to access, set, or modify the resource of the resource owner[ i.e. user consents to authorize to operate the data of the target user ] [ paragraphs 0071, and 0103 ];
receiving an authorization code from the resource owner [ i.e. AEF sends an API invocation response message to the API invoker ] [ S220, Figure 2(b); and paragraphs 0247, and 0248 ] and sending the authorization code to a first entity [ i.e. the API invoker sends a first request message to the CCF ] [ S306, Figure 3; and paragraph 0441 ]; and
receiving a token generated by the first entity based on the authorization code [ i.e. the CCF sends a second token to the API invoker ] [ S307, Figure 3; and paragraphs 0089, and 0445 ].
16. As per claim 22, Hu discloses performing mutual authentication with the resource owner; and in the case that the mutual authentication is passed, establishing a first connection between the resource owner and the API invoker, wherein the first connection is a secure connection for transmitting the at least one of the authorization request for the resource and/or or the API authorization request [ i.e. establish a TLS connection ] [ S225, Figure 2(b); and paragraph 0233 ].
17. As per claim 24, Hu discloses in the case that the API invoker obtains authorization of a service, sending the authorization request for the resource to the resource owner; and in the case that the API invoker does not obtain the authorization of the service, sending the authorization request for the resource and the API authorization request to the resource owner [ i.e. AEF can authorize the API invoker to access an API and process data of a user ] [ paragraphs 0069, and 0483 ], wherein the authorization request for the resource comprises at least one of: an API invoker identity (ID), a resource owner ID, or a target resource ID, and the API authorization request comprises a service identifier [ i.e. API invoker ID, service API ID ] [ paragraphs 0207, and 0213 ].
18. As per claim 27, Hu discloses wherein receiving the token generated by the first entity based on the authorization code comprises at least one of: receiving at least one of an access token and/or or a refresh token from the first entity; or sending the refresh token to the first entity and receiving the access token from the first entity based on the refresh token [ i.e. the authorization response message includes a first token, the first token indicates that the API invoker has permission to access the data of the target user ] [ paragraph 0085 ].
19. As per claim 28, Hu discloses wherein the API invoker is a UE or an AF, and the resource is at least one of quality of service and/or or location information of the resource owner [ i.e. information of the user ] [ paragraphs 0003, and 0183 ].
20. As per claim 29, it is rejected for similar reasons as stated above in claim 1.
21. As per claim 30, it is rejected for similar reasons as stated above in claim 11.
22. As per claim 31, it is rejected for similar reasons as stated above in claim 21.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Karakoc et al. [ US Patent Application No 2025/0254157 ] discloses the access token for indicating whether a resource owner consents to communication equipment accessing a protected resource of an API
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DUSTIN NGUYEN whose telephone number is (571)272-3971. The examiner can normally be reached Monday-Friday 9-6 PST.
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, Brian Gillis can be reached at 571-2727952. 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.
/DUSTIN NGUYEN/Primary Examiner, Art Unit 2445
