DETAILED ACTION
This is a non-final Office action in response to communications received on 5/06/2025. Claims 1-62 were cancelled via preliminary amendment. New claims 63-80 were added. Claims 63-80 are pending and are examined. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Drawings
The drawings filed 5/06/2025 are acknowledged.
Foreign Priority or Provisional
Priority to 11/07/2022 is recognized.
Claim Rejections - 35 USC § 112, second paragraph
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.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 64-65 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 pre-AIA the applicant regards as the invention.
Claims 64-65 are rejected as indefinite because it is unclear which “request” is being referred to from the independent claim – which has multiple requests.
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 of this title, 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
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.
Claims 63-69 and 71-80 are rejected under 35 U.S.C. 103 as being unpatentable over Hu (US 20250184731).
Regarding claim 63, Hu discloses the limitations substantially as follows:
A method performed by communication equipment configured to invoke an application programming interface (API) to access a service, the method comprising:
transmitting, to network equipment, a request for an access token (paras. [0068], [0547], Figs. 4-5: transmitting to network elements such as an authorization function, common API framework core function (CCF) or API exposing function (AEF), an authorization request/access token request to obtain a token);
receiving, in response to the request, an access token that indicates whether a resource owner authorizes the communication equipment to access a protected resource of the resource owner (paras. [0028], [0114], [0336]-[0337], [0503], [0544], [0550]-[0551], Figs. 4-5: receiving, in response to a request sent from the network element API invoker, an authorization response including a first token with integrity protection and a target user identifier indicating that the API invoker has permission to access data of a target user and an including an identifier of the target user (i.e. resource owner));
transmitting, to API exposing equipment configured to expose the API, a request to invoke the API (paras. [0114], [0558], Figs. 4-5: transmit to API exposing function network element (AEF) a API invocation request message to invoke a target API); and
transmitting, to the API exposing equipment, the access token (paras. [0114], [0560], Figs. 4-5: transmitting to the AEF the first token as part of the invocation request)).
Hu does not explicitly disclose an access token indicating that the resource owner authorizes the communication equipment to access a protected resource of the resource owner, however it would have been obvious to one of ordinary skill before the effective filing data of the invention that Hu discloses such functionality because Hu discloses receiving a first token with integrity protection and a target user identifier indicating that the API invoker has permission to access data of a target user, where including the target user identifier in the token increases the security of the system by enabling the generation of “a token of a finer granularity (including a user identifier 1), so that user consent information is considered in an authorization process, and a granularity can be that an NF 1 authorizes an NF2 to access an API and invoke data of a user” (Hu, para. [0587]) and enabling a message received with the token to be verified by comparing the user identifier in the message with the user identifier in the token.
Regarding claim 64, Hu discloses the limitations of claim 63.
Hu discloses the limitations of claim 64 as follows:
The method of claim 63, wherein the access token is included in the request (paras. [0114]: transmitting to the AEF the first token as part of the invocation request)).
Regarding claim 65, Hu discloses the limitations of claim 63.
Hu discloses the limitations of claim 65 as follows:
The method of claim 63, wherein transmitting the request and the access token comprises transmitting, to the API exposing equipment, a message that includes both the request and the access token (paras. [0114]: transmit to API exposing function network element AEF a API invocation request message to invoke a target API including the first token).
Regarding claim 66, Hu discloses the limitations of claim 63.
Hu discloses the limitations of claim 66 as follows:
The method of claim 63, wherein transmitting the access token comprises transmitting the access token to the API exposing equipment before, or at the same time as, transmitting the request to the API exposing equipment (paras. [0114]: transmit to API exposing function network element AEF a API invocation request message to invoke a target API (i.e. the request with the first token (i.e. access token transmitted at same time)).
Regarding claim 67, Hu discloses the limitations of claim 63.
Hu discloses the limitations of claim 67 as follows:
The method of claim 63, wherein the access token includes authorization information asserting that the resource owner authorizes, or does not authorize, the communication equipment to access the protected resource of the resource owner (paras. [0114], [0337] [0503], [0544], [0550]-[0551]: the first token includes an identifier of the target user/resource owner indicating that the target user authorizes the invocation of the target API (i.e. accessing protected resource of the resource owner) by the API Invoker).
Regarding claim 68, Hu discloses the limitations of claims 63 and 67.
Hu discloses the limitations of claim 68 as follows:
The method of claim 67, wherein the authorization information is a claim asserting that the resource owner authorizes, or does not authorize, the communication equipment to access the protected resource of the resource owner (paras. [0114], [0503], [0544], [0550]-[0551]: the first token includes an identifier of the target user/resource owner indicating that the target user authorizes the invocation of the target API (i.e. accessing protected resource of the resource owner) by the API Invoker).
Regarding claim 69, Hu discloses the limitations of claim 63.
Hu discloses the limitations of claim 69 as follows:
The method of claim 63, wherein the access token is an OAuth 2.0 access token (paras. [0185], [0342]: token is an 2.0 OAuth access token)).
Regarding claim 71, Hu discloses the limitations of claim 63.
Hu discloses the limitations of claim 71 as follows:
The method of claim 63, wherein the communication equipment is a user equipment (paras. [0145], [0169]: API invoker may be user equipment).
Regarding claim 72, Hu discloses the limitations of claim 63.
Hu discloses the limitations of claim 72 as follows:
The method of claim 63, wherein the resource owner is a user of the communication equipment (paras. [0168]: resource owner client).
Regarding claim 73, Hu discloses the limitations of claim 63.
Hu discloses the limitations of claim 73 as follows:
The method of claim 63, wherein the communication equipment is network equipment that implements an application function (AF) (paras. [0168]-[0169], Fig. 1: API invoker is a UE or AF).
Regarding claim 74, Hu discloses the limitations of claim 63.
Hu discloses the limitations of claim 74 as follows:
The method of claim 63, wherein the access token also asserts that the communication equipment is authorized to access the API (para. [0114]: receiving, in response to a request sent from the network element API invoker, an authorization response including a first token indicating that the API invoker has permission to access data of a target user and an including an identifier of the target user (i.e. resource owner)).
Regarding claim 75, Hu discloses the limitations of claim 63.
Hu discloses the limitations of claim 75 as follows:
The method of claim 63, further comprising, before transmitting the request for the access token:
transmitting an authorization request to the network equipment (paras. [0531], [0533], Figs. 2c: transmitting an authorization request to the AuF/CCF prior to transmitting an access token request); and
receiving, in response to the authorization request, an authorization code that is a credential representing authorization of the resource owner (paras. [0272], [0503], [0544], [0553], Fig. 2c: receiving, in response to the response to the authorization request, a response to the authorization request including authorization code representing authorization of the user and a token with integrity protection including a user identifier of the target owner representing consent from the resource owner to access the user/owner data);
wherein the request for the access token includes the authorization code (paras. [0272], [0275], Fig, 2c: wherein the access token request message includes the authorization code authorization request includes an identifier of the target user).
Regarding claim 76, Hu discloses the limitations of claim 63.
Hu discloses the limitations of claim 76 as follows:
The method of claim 63, wherein the network equipment implements a CAPIF Core Function (paras. [0168]-[0169]: API invoker implements CAPIF architecture).
Regarding claim 77, Hu discloses the limitations of claim 63.
Hu discloses the limitations of claim 77 as follows:
The method of claim 63, wherein the network equipment is common API core equipment (paras. [0012], [0076]-[0077]: API invoker works with common API framework core function network elements)).
Regarding claim 78, Hu discloses the limitations of claim 63.
Hu discloses the limitations of claim 78 as follows:
The method of claim 63, wherein the network equipment is an authorization server (paras. [0168]-[0169]: API invoker may be implemented as third-party application provider/server).
Regarding claim 79, Hu discloses the limitation substantially as follows:
Communication equipment comprising:
processing circuitry and memory, the memory containing instructions executable by the processing circuitry whereby the communication equipment is configured to:
transmit, to network equipment, a request for an access token (paras. [0068], [0547], Figs. 4-5: transmitting to network elements such as an authorization function, common API framework core function (CCF) or API exposing function (AEF), an authorization request/access token request to obtain a token);
receive, in response to the request, an access token that indicates whether a resource owner authorizes the communication equipment to access a protected resource of the resource owner (paras. [0028], [0114], [0336]-[0337], [0503], [0544], [0550]-[0551], Figs. 4-5: receiving, in response to a request sent from the network element API invoker, an authorization response including a first token with integrity protection and a target user identifier indicating that the API invoker has permission to access data of a target user and an including an identifier of the target user (i.e. resource owner));
transmit, to API exposing equipment configured to expose the API, a request to invoke the API (paras. [0114], [0558], Figs. 4-5: transmit to API exposing function network element (AEF) a API invocation request message to invoke a target API); and
transmit, to the API exposing equipment, the access token (paras. [0114], [0560], Figs. 4-5: transmitting to the AEF the first token as part of the invocation request)).
Hu does not explicitly disclose an access token indicating that the resource owner authorizes the communication equipment to access a protected resource of the resource owner, however it would have been obvious to one of ordinary skill before the effective filing data of the invention that Hu discloses such functionality because Hu discloses receiving a first token with integrity protection and a target user identifier indicating that the API invoker has permission to access data of a target user, where including the target user identifier in the token increases the security of the system by enabling the generation of “a token of a finer granularity (including a user identifier 1), so that user consent information is considered in an authorization process, and a granularity can be that an NF 1 authorizes an NF2 to access an API and invoke data of a user” (Hu, para. [0587]) and enabling a message received with the token to be verified by comparing the user identifier in the message with the user identifier in the token.
Regarding claim 80, Hu discloses the limitation substantially as follows:
A non-transitory computer-readable storage medium on which is stored a computer program comprising instructions which, when executed by at least one processor of communication equipment, causes the communication equipment to:
transmit, to network equipment, a request for an access token (paras. [0068], [0547], Figs. 4-5: transmitting to network elements such as an authorization function, common API framework core function (CCF) or API exposing function (AEF), an authorization request/access token request to obtain a token);
receive, in response to the request, an access token that indicates whether a resource owner authorizes the communication equipment to access a protected resource of the resource owner (paras. [0028], [0114], [0336]-[0337], [0503], [0544], [0550]-[0551], Figs. 4-5: receiving, in response to a request sent from the network element API invoker, an authorization response including a first token with integrity protection and a target user identifier indicating that the API invoker has permission to access data of a target user and an including an identifier of the target user (i.e. resource owner));
transmit, to API exposing equipment configured to expose the API, a request to invoke the API (paras. [0114], [0558], Figs. 4-5: transmit to API exposing function network element (AEF) a API invocation request message to invoke a target API); and
transmit, to the API exposing equipment, the access token (paras. [0114], [0560], Figs. 4-5: transmitting to the AEF the first token as part of the invocation request)).
Hu does not explicitly disclose an access token indicating that the resource owner authorizes the communication equipment to access a protected resource of the resource owner, however it would have been obvious to one of ordinary skill before the effective filing data of the invention that Hu discloses such functionality because Hu discloses receiving a first token with integrity protection and a target user identifier indicating that the API invoker has permission to access data of a target user, where including the target user identifier in the token increases the security of the system by enabling the generation of “a token of a finer granularity (including a user identifier 1), so that user consent information is considered in an authorization process, and a granularity can be that an NF 1 authorizes an NF2 to access an API and invoke data of a user” (Hu, para. [0587]) and enabling a message received with the token to be verified by comparing the user identifier in the message with the user identifier in the token.
Claim 70 is rejected under 35 U.S.C. 103 as being unpatentable over Hu (US 20250184731), as applied to claim 63, further in view of Rajadurai (US 2019/0149576).
Regarding claim 70, Hu discloses the limitations of claim 63.
Hu does not disclose the limitations of claim 70 but, in the same field of endeavor, Rajadurai discloses the limitations of claim 70 as follows:
The method of claim 63, wherein the API is a Northbound API (paras. [0031]-[0032]: northbound API).
Rajadurai is combinable with Hu because both are from the same field of endeavor of OAuth authorization in order to transmit an access token to API exposing equipment. It would have been obvious to one of ordinary skill before the effective filing data of the invention to integrate Rajadurai’s method of incorporating a Northbound API with the APIs of Hu in order to establish a clear, bidirectional architectural layer which encompasses interfaces facing outwards towards higher-level management and provide a single point of entry to enforce authentication.
Prior Art Considered But Not Relied Upon
Prior art considered but not relied upon includes:
1) Liang (US 2026/0039644) disclosing a method for authenticating an application program interface (API) invoker enhances secure communication between API invokers and a Common Application Program Interface Framework (CAPIF). An API invoker authentication apparatus is provided, which is performed by a CAPIF function, including: [0127] a receiving module, configured to receive first request information sent by an application program interface (API) invoker, where the first request information includes authentication information of the API invoker including at least one of: a token of the API invoker, a key pair of the API invoker, and a public key of the API invoker. Here, the token of the API invoker may be, but is not limited to, an OAuth 2.0 token. The API invoker sends the first request information to the CAPIF function, where the first request information includes the authentication information of the API invoker, and the authentication information is used for the CAPIF function to authenticate the identity of the API invoker. (paras. [0202]-[0203]).
Conclusion
For the above-stated reasons, claims 63-80 are rejected.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHARON S LYNCH whose telephone number is (571)272-4583. The examiner can normally be reached on 10AM-6PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Taghi T Arani can be reached on 571-272-3787. 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). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SHARON S LYNCH/Primary Examiner, Art Unit 2438
Prosecution Insights