Prosecution Insights
Last updated: April 19, 2026
Application No. 18/671,545

APPLICATION PROGRAMMING INTERFACE (API) ACCESS TO RESOURCE BASED ON RESOURCE OWNER IDENTIFIER

Non-Final OA §102§112
Filed
May 22, 2024
Examiner
REVAK, CHRISTOPHER A
Art Unit
2407
Tech Center
2400 — Computer Networks
Assignee
Telefonaktiebolaget Lm Ericsson (Publ)
OA Round
1 (Non-Final)
89%
Grant Probability
Favorable
1-2
OA Rounds
2y 9m
To Grant
98%
With Interview

Examiner Intelligence

Grants 89% — above average
89%
Career Allow Rate
987 granted / 1105 resolved
+31.3% vs TC avg
Moderate +9% lift
Without
With
+8.6%
Interview Lift
resolved cases with interview
Typical timeline
2y 9m
Avg Prosecution
17 currently pending
Career history
1122
Total Applications
across all art units

Statute-Specific Performance

§101
12.0%
-28.0% vs TC avg
§103
20.9%
-19.1% vs TC avg
§102
38.0%
-2.0% vs TC avg
§112
7.2%
-32.8% vs TC avg
Black line = Tech Center average estimate • Based on career data from 1105 resolved cases

Office Action

§102 §112
DETAILED ACTION Notice of Pre-AIA or AIA Status The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . Information Disclosure Statement The information disclosure statement (IDS) submitted on August 23, 2024 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner. Priority Acknowledgment is made of applicant's claim for foreign priority. It is noted, however, that applicant has not filed a certified copy of the PCT/CN2023/095482 application as required by 37 CFR 1.55. Claim Rejections - 35 USC § 112 The following is a quotation of 35 U.S.C. 112(b): (b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. 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 1-12, 14 and 15 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Claim 1 recites the limitation "an access token" in lines 4 and 8 (reproduced below highlighting both instances in question). It is unclear if the recitation of the “an access token” recited in line 8 is the same “access token” previously recited in line 4 of the claim, of it is a different one. For examination purposes, recitation of “access token” on line 8 of the claim will be interpreted as “the access token”. Claims 2-8 are rejected by virtue of the dependency on claim 1. There is insufficient antecedent basis for this limitation in the claim. 1. A method for an application programming interface, API, invoking entity of a communication network, the method comprising: sending, to a common API framework, CAPIF, core function, CCF, of the communication network, a request for an access token granting the API invoking entity permission to access a resource, in the communication network, that is owned by a resource owner, wherein the request includes an indication related to the resource owner; receiving, from the CCF, an access token in accordance with the request, wherein the access token includes the following: a first identifier associated with the resource owner; and a second identifier associated with the API invoking entity; and invoking, via an API exposing function, AEF, an API for the resource using the access token. Claim 8 recites the limitation "an access token" in lines 3 and 9 (reproduced below highlighting both instances in question). It is unclear if the recitation of the “an access token” recited in line 9 is the same “access token” previously recited in line 3 of the claim, of it is a different one. For examination purposes, recitation of “access token” on line 9 of the claim will be interpreted as “the access token”. Claims 9-12, 14, and 15 are rejected by virtue of the dependency on claim 8. There is insufficient antecedent basis for this limitation in the claim. 8. A method for a common application programming interface, API, framework core function, CCF, of a communication network, the method comprising: receiving, from an API invoking entity, a request for an access token granting the API invoking entity permission to access a resource, in the communication network, that is owned by a resource owner, wherein the request includes an indication related to the resource owner; obtaining a first identifier associated with the resource owner and a second identifier associated with the API invoking entity; generating an access token that includes the following: the first identifier; and the second identifier; and sending the access token to the API invoking entity, in accordance with the request. 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. Claims 1-5, 7-12, and 14-20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Liang et al, EP 4572230 A1. As per claim 1, it is disclosed of a method for an application programming interface, API, invoking entity of a communication network (invoking of an API by an API invoker takes place across a communications network paragraph 0022-0024, column 6 and paragraph 0277 & 0280, column 28), the method comprising: sending, to a common API framework, CAPIF, core function, CCF (CAPIF authentication function includes a CAPIF core function (CCF), paragraph 0024, column 6), of the communication network (invoking of an API by an API invoker takes place across a communications network paragraph 0022-0024, column 6 and paragraph 0277 & 0280, column 28), a request for an access token granting the API invoking entity permission to access a resource, in the communication network, that is owned by a resource owner, wherein the request includes an indication related to the resource owner (an API invoker sends a token request to the CAPIF authentication/authorization function, paragraph 0023, column 6 and paragraph 0290, column 28; the API invoker is the target resource owner, paragraph 0025, column 6 and paragraph 0291, column 28); receiving, from the CCF (CAPIF authentication function includes a CAPIF core function (CCF), paragraph 0024, column 6), an access token in accordance with the request (CAPIF authentication/ authorization function maps the identity of the API invoker for the first token request and a token response message is received by the API invoking entity, paragraph 0034, column 7 & paragraph 0040, column 7 and; paragraphs 0303-0304, column 30), wherein the access token includes the following: a first identifier associated with the resource owner (token includes identity of the target resource owner, paragraph 0042, column 8 and paragraph 0305, column 30); and a second identifier associated with the API invoking entity (token includes identity of the API invoking entity, paragraph 0042, column 8 and paragraph 0305, column 30); and invoking, via an API exposing function, AEF, an API for the resource using the access token (upon verification of the token, invocation of the API is authorized by an API exposing function or AEF, to grant authorization for the requested target resource, paragraphs 0094 & 0097, column 12 and paragraphs 0334, 0336, & 0338, column 32). As per claim 2, it is disclosed of further comprising receiving an API invocation response from the AEF (invocation of the API is authorized by an API exposing function or AEF, to grant authorization for the requested target resource by the API invoking entity, paragraphs 0094 & 0097, column 12 and paragraphs 0334, 0336, & 0338, column 32). As per claim 3, it taught wherein the API invoking entity is the resource owner and the indication related to the resource owner (token includes identity of the target resource owner and identity of the API invoking entity, paragraph 0042, column 8 and paragraph 0305, column 30) is one of the following: the second identifier associated with the API invoking entity (token includes identity of the API invoking entity, paragraph 0042, column 8 and paragraph 0305, column 30), or As per claim 4, it is disclosed wherein the API invoking entity is different from the resource owner and the indication related to the resource owner is the first identifier associated with the resource owner (token includes identity of the API invoking entity and the target resource owner, paragraph 0042, column 8 and paragraph 0305, column 30, the teachings further disclose that the API invoker can modify or set a target resource of a target resource owner, paragraph 0025, column 6, wherein the Examiner is interpreted this to imply that the API invoking entity is different from the resource owner). As per claim 5, it is taught wherein the request also includes the second identifier associated with the API invoking entity (token request includes identity of the API invoking entity, paragraph 0042, column 8 and paragraph 0305, column 30). As per claim 7, it is disclosed wherein the API invoking entity is an application hosted by a user equipment, UE, and the second identifier is a generic public subscription identifier, GPSI, or subscription public identifier, SUPI, associated with a user subscription to the communication network (identity information includes but is not limited to an A-KID of the API invoker, a B-TID of the API invoker, a SUPI of the API invoker, and a GPSI of the API invoke, paragraph 0035, column 7 and paragraph 0312, column 31 and the API invoking entity is an application function or AF hosted the UE, paragraph 0034, column 7 and paragraph 0300, column 30). As per claim 8, it taught of a method for a common application programming interface, API, framework core function, CCF (CAPIF authentication function includes a CAPIF core function (CCF), paragraph 0024, column 6), of a communication network (invoking of an API by an API invoker takes place across a communications network paragraph 0022-0024, column 6 and paragraph 0277 & 0280, column 28), the method comprising: receiving, from an API invoking entity, a request for an access token granting the API invoking entity permission to access a resource, in the communication network, that is owned by a resource owner, wherein the request includes an indication related to the resource owner (an API invoker sends a token request to the CAPIF authentication/authorization function, paragraph 0023, column 6 and paragraph 0290, column 28; the API invoker is the target resource owner, paragraph 0025, column 6 and paragraph 0291, column 28); obtaining a first identifier associated with the resource owner (token includes identity of the target resource owner, paragraph 0042, column 8 and paragraph 0305, column 30) and a second identifier associated with the API invoking entity (token includes identity of the API invoking entity, paragraph 0042, column 8 and paragraph 0305, column 30); generating an access token (CAPIF authentication/authorization function maps the identity of the API invoker for the first token request and a token response message, paragraph 0034, column 7 and paragraph 0040, column 7; and paragraphs 0303-0304, column 30) that includes the following: the first identifier; and the second identifier (token includes identity of the target resource owner and the identity of the API invoking entity, paragraph 0042, column 8 and paragraph 0305, column 30); and sending the access token to the API invoking entity, in accordance with the request (CAPIF authentication/authorization function maps the identity of the API invoker for the first token request and a token response message is received by the API invoking entity, paragraph 0034, column 7 & paragraph 0040, column 7 and; paragraphs 0303-0304, column 30). As per claim 9, it is disclosed wherein the second identifier is obtained from one of the following: the request (an API invoker sends a token request to the CAPIF authentication/authorization function, paragraph 0023, column 6 and paragraph 0290, column 28 wherein the token includes identity of the API invoking entity, paragraph 0042, column 8 and paragraph 0305, column 30); or As per claim 10, it is taught of further comprising performing an authentication procedure with the API invoking entity based on the request, wherein one of the following applies: the second identifier is obtained from the communication network during or after the authentication procedure; or the second identifier in the request is authenticated during the authentication procedure (CAPIF authentication/authorization function maps the identity of the API invoker for the token request and a token response message is received by the API invoking entity, paragraph 0034, column 7 & paragraph 0040, column 7 and; paragraphs 0303-0304, column 30). As per claim 11, it disclosed wherein the API invoking entity is the resource owner and the indication related to the resource owner (token includes identity of the target resource owner and identity of the API invoking entity, paragraph 0042, column 8 and paragraph 0305, column 30) is one of the following: the second identifier associated with the API invoking entity (token includes identity of the API invoking entity, paragraph 0042, column 8 and paragraph 0305, column 30), or As per claim 12, it is taught wherein obtaining the first identifier comprises, based on the indication related to the resource owner (token includes identity of the target resource owner and identity of the API invoking entity, paragraph 0042, column 8 and paragraph 0305, column 30), setting the first identifier equal to the second identifier (since the token includes identity of both the target resource owner and identity of the API invoking entity, it is interpreted by the Examiner whereby both identifiers are equals since they are part of the same token identifying the same API invoker and target resource owner, paragraph 0042, column 8 and paragraph 0305, column 30). As per claim 14, it disclosed wherein the API invoking entity is an application function, AF, in or associated with the communication network, and the second identifier is an AF identifier (API invoking entity within the communication network can include a category involving an AF along with an AF identifier, paragraph 0293, columns 29-30 and paragraphs 0295 & 0300, column 30). As per claim 15, it is taught wherein the API invoking entity is an application hosted by a user equipment, UE, and the second identifier is a generic public subscription identifier, GPSI, or subscription public identifier, SUPI, associated with a user subscription to the communication network (identity information includes but is not limited to an A-KID of the API invoker, a B-TID of the API invoker, a SUPI of the API invoker, and a GPSI of the API invoke, paragraph 0035, column 7 and paragraph 0312, column 31 and the API invoking entity is an application function or AF hosted the UE, paragraph 0034, column 7 and paragraph 0300, column 30). As per claim 16, it is disclosed of a method for an application programming interface, API, exposing function, AEF (an API invocation request is sent from an API invoker to an AEF, paragraphs 0062 & 0064, column 9 and paragraph 0305), of a communication network (invoking of an API by an API invoker takes place across a communications network paragraph 0022-0024, column 6 and paragraph 0277 & 0280, column 28), the method comprising: receiving, from an API invoking entity, an invocation of an API for a resource, in the communication network, that is owned by a resource owner, wherein the API invocation includes an access token (an API invoker sends a token request to the CAPIF authentication/authorization function, paragraph 0023, column 6 and paragraph 0290, column 28; the API invoker is the target resource owner, paragraph 0025, column 6 and paragraph 0291, column 28) that includes the following: a first identifier associated with the resource owner (token includes identity of the target resource owner, paragraph 0042, column 8 and paragraph 0305, column 30); and a second identifier associated with the API invoking entity (token includes identity of the API invoking entity, paragraph 0042, column 8 and paragraph 0305, column 30); and authorizing API access by the API invoking entity, but limited to the resource; and sending an API invocation response to the API invoking entity (upon verification of the token, invocation of the API is authorized by an API exposing function or AEF, to grant authorization for the requested target resource, paragraphs 0094 & 0097, column 12 and paragraphs 0334, 0336, & 0338, column 32). As per claim 17, it is taught wherein the API invoking entity is the resource owner (the API invoker is the target resource owner, paragraph 0025, column 6 and paragraph 0291, column 28). As per claim 18, it is disclosed wherein the API invoking entity is different from the resource owner (token includes identity of the API invoking entity and the target resource owner, paragraph 0042, column 8 and paragraph 0305, column 30, the teachings further disclose that the API invoker can modify or set a target resource of a target resource owner, paragraph 0025, column 6, wherein the Examiner is interpreted this to imply that the API invoking entity is different from the resource owner). As per claim 19, it is taught wherein the API invoking entity is an application function, AF, in or associated with the communication network, and the second identifier is an AF identifier (API invoking entity within the communication network can include a category involving an AF along with an AF identifier, paragraph 0293, columns 29-30 and paragraphs 0295 & 0300, column 30). As per claim 20, it is disclosed wherein the API invoking entity is an application hosted by a user equipment, UE, and the second identifier is a generic public subscription identifier, GPSI, or subscription public identifier, SUPI, associated with a user subscription to the communication network (identity information includes but is not limited to an A-KID of the API invoker, a B-TID of the API invoker, a SUPI of the API invoker, and a GPSI of the API invoke, paragraph 0035, column 7 and paragraph 0312, column 31 and the API invoking entity is an application function or AF hosted the UE, paragraph 0034, column 7 and paragraph 0300, column 30). Conclusion The relevant art made of record and not relied upon is considered pertinent to applicant's disclosure. Baskaran et al, US 2025/0133399 is relied upon for disclosing of an API invoker and CAPIF core function for onboarding, see paragraph 0101. The API invoker sends an onboard service request to a CCF that includes identification information, see paragraph 0102. The CCF requests the request and determines and uses information to determine context for the USE for the associated API invocation, see paragraph 0103. An access token is checked for verifying authorization, see paragraph 0109. Mladin et al, WO 2023/150782 A2 is relied upon for disclosing of including UE/API Invoker parameters, such as: UE network provider, UE service provider, UE ID (e.g., external ID), group ID, API provider domain, API Invoker OS, API Invoker device (e.g., International Mobile Equipment Identity - IMEI), API Invoker subscription (e.g., IMSI), API invoker AppID, API Invoker, API Invoker userID, API Invoker supported features, resource owner IDs for API Invocations, permission for AIP to act as API Invoker on its behalf, or credentials for API invocations, see paragraph 0063. Rajadurai et al, US 2019/0149576 is relied upon for disclosing of authentication and authorization are required for both the API invokers which present within the PLMN trust domain and outside of the PLMN trust domain. To authenticate and authorize the API invoker present outside of the PLMN trust domain, the CCF must in coordination with the AEF and utilizes the CAPIF-1e, the CAPIF-2e and the CAPIF-3 interfaces to onboard to authenticate and authorize the API invoker prior to granting an access to CAPIF services/service API's. When the API invoker is within the PLMN trust domain, the CCF in coordination with the AEF can perform authentication and authorization of the API invoker via the CAPIF-1, the CAPIF-2 and the CAPIF-3 interfaces prior to granting access to the CAPIF services, see paragraph, see paragraph 0047. Xu et al, WO 2024/100055 A1 is a related teaching by the Applicant relied upon for disclosing of communication equipment is configured to invoke an application programming interface (API) to access a service. The communication equipment transmits, from the communication equipment to API exposing equipment configured to expose the API, a request to invoke the API. The communication equipment also transmits, from the communication equipment to the API exposing equipment, an access token that indicates whether a resource owner authorizes the communication equipment to access a protected resource of the resource owner. The API exposing equipment may verify the request based on the access token, e.g., by verifying the request against one or more claims in the access token. The API exposing equipment may then accept or reject the request depending on that verification, see abstract. Xiong et al, US 2025/0274759 is relied upon for disclosing of TLS and authorization (OAuth) token. FIG. 6 is a schematic diagram of an authorization mode of Method three of CAPIF-2e, including the following contents. Step 1. CAPIF-1e authentication and secure session establishment. Step 2. After successfully establishing a TLS session on CAPIF-1e (i.e., a TLS session is established between the API invoker and the CAPIF core function), the API invoker transmits an access token request message to the CAPIF core function. Step 3. The CAPIF core function verifies the access token request message. Step 4. If the CAPIF core function successfully verifies the access token request message, the CAPIF core function generates an access token specific to the API invoker, and returns an access token response message to the API invoker, where the access token response message carries the access token, see paragraphs 0214-0218. Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHRISTOPHER REVAK whose telephone number is (571)272-3794. The examiner can normally be reached 5:30am - 3:00pm. 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, Catherine Thiaw can be reached at 571-270-1138. 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. /CHRISTOPHER A REVAK/Primary Examiner, Art Unit 2407
Read full office action

Prosecution Timeline

May 22, 2024
Application Filed
Feb 28, 2026
Non-Final Rejection — §102, §112 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12602477
DETECTING TARGETED INTRUSION ON MOBILE DEVICES
2y 5m to grant Granted Apr 14, 2026
Patent 12596798
PROBABILISTIC TRACKER MANAGEMENT FOR MEMORY ATTACK MITIGATION
2y 5m to grant Granted Apr 07, 2026
Patent 12591698
SECURE DATA PARSER METHOD AND SYSTEM
2y 5m to grant Granted Mar 31, 2026
Patent 12579251
SYSTEM AND METHOD FOR DETECTING EXCESSIVE PERMISSIONS IN IDENTITY AND ACCESS MANAGEMENT
2y 5m to grant Granted Mar 17, 2026
Patent 12561439
LOCATION-BASED IHS FUNCTIONALITY LIMITING SYSTEM AND METHOD
2y 5m to grant Granted Feb 24, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

1-2
Expected OA Rounds
89%
Grant Probability
98%
With Interview (+8.6%)
2y 9m
Median Time to Grant
Low
PTA Risk
Based on 1105 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month