DETAILED ACTION
Claims 1-3, 9-12, 14-15, 19, 27-28, 44-45, 47-48, 59, 64-65 are presented for examination. Claims 4 – 8, 13, 16 – 18, 20 – 26, 29 - 43, 46, 49 - 58, 60.-63, and 66 have been canceled.
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(s) submitted by applicant on 09/21/2025 and 02/12/2025 has/have been considered. The submission is in compliance with the provisions of 37 CFR § 1.97. Form PTO-1449 signed and attached hereto.
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 .
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.
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 .
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.
Claim Rejections - 35 USC § 102
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.
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)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
(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-3, 9-12, 14-15, 19, 27-28, 44-45, 47-48, 59, 64-65 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Study on application enablement aspects for subscriber-aware northbound API access; (Release 18)", 3GPP DRAFT; S3-221586.ZIP 23700-95-130, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE , 23 June 2022 (2022-06-23), XP052257841,” (Hereinafter 3GPP).
As per claim 1, 3GPP discloses a method for invoking a northbound application program interface (API), executed by a user equipment (UE), and comprising:
receiving an authorization request message sent by a common API framework (CAPIF) authentication and authorization function for requesting a specified authorization (page 18, section 6.4.1.1, "1. The API invoker requests authorization grant and access token to invoke the service API"; page 19, section 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";); wherein the specified authorization is an authorization corresponding to a target resource of the UE(page 18, section 6.4.1.1, "1. The API invoker requests authorization grant and access token to invoke the service API"; page 19, section 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";);
determining whether to allow an API invoker to obtain the target resource according to the authorization request message (page 18, section 6.4.1.1, "1. The API invoker requests authorization grant and access token to invoke the service API"; page 19, section 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") ; and
sending an authorization response message to the CAPIF authentication and authorization function; wherein the authorization response message is used to indicate whether the UE agrees to provide the specified authorization for the API invoker (page 15, last paragraph of section 6.2.1.3.4: "If API invokers wish to utilize the API provider users' resources via the service API exposed by the API provider, then API invoker is required to obtain the resource owner authorization from API provider's
authorization function";
page 12, figure 6.2.1.2.1-1: Functional model for the CAPIF authorization with SNA enhancements;
page 12, section 6.2.1.2.1, third sentence: "The resource owner client (s) interacts with the authorization function via CAPIF-8. The resource owner communicates with the authorization function to provide and revoke resource owner consent";
page 12, section 6.2.1.2.1, antepenultimate and penultimate paragraph: "The API exposing function (e.g NEF) acts as a resource owner consent enforcement point as specified in 3GPP TS 33.501 [8] and interacts with the authorization function via CAPIF-9. The API exposing function can retrieve the resource owner consent parameters from. the authorization function. The API invoker interacts with authorization function via CAPIF-10/CAPIF-10e"; page 11, section 6.1.1, second sentence: "the resource owner (which is a UE-side entity) is a new entity that has not been in the existing CAPIF business relationship, thus the business relationship should be updated to include the resource owner"; wherein the "authorization function" corresponds to the "CAPIF authentication and authorization function" claimed; wherein the request from the API invoker for authorization grant from the resource owner, i.e. the UE, has to be done through authorization function employing interfaces CAPIF-10 and CAPIF-8 in
figure 6.2.1.2.1-1); page 12, section 6.2.1.2.1, antepenultimate and penultimate
paragraph: "The API exposing function (e.g NEF) acts as a resource owner consent enforcement point as specified in 3GPP TS 33.501 [8] and interacts with the authorization function via CAPIF-9. The API exposing function can retrieve the resource owner consent parameters from the authorization function. The API invoker
interacts with authorization function via CAPIF-10/CAPIF-10e"; page 11, section 6.1.1, second sentence: "the resource owner (which is a UE-side entity) is a new entity that has not been in the existing CAPIF business relationship, thus the business relationship should be updated to include the resource owner"; wherein the "authorization function" corresponds to the "CAPIF authentication and authorization function" claimed; wherein the request from the API invoker for authorization grant from the resource owner, i.e. the UE, has to be done through authorization function employing interfaces CAPIF-10 and CAPIF-8 in figure 6.2.1.2.1-1).
As per claim 2, 3GPP discloses The method according to claim 1, wherein the authorization request message comprises at least one of: an identifier of the API invoker; an identifier of a target resource owner; an identifier of the target resource; an identifier of a service API requested by the API invoker; an identifier of a service requested by the API invoker; or an identifier of a service operation requested by the API invoker (Figure 6.3.1.3-1: Procedure for obtaining resource owner consent upon service API invocation; page 17, 6.3.1.3 Obtaining resource owner consent).
As per claim 3, 3GPP discloses wherein the authorization response message is used to indicate at least one of: a token type that the UE needs to obtain; whether the UE agrees to provide the specified authorization for the API invoker; the UE permanently agrees to provide the specified authorization for the API invoker; the UE permanently disagrees to provide the specified authorization to the API invoker; new authorization is required each time the API accesses the target resource; the UE agrees to provide the specified authorization to the API invoker according to an authorization condition; or the UE disagrees to provide the specified authorization to the API invoker according to the authorization condition (page 18, 6.3.1.4 Updating resource owner consent; Figure 6.4.1.1-1: Procedure for API invoker obtaining resource owner consent prior to the service API invocation).
As per claim 9, 3GPP discloses wherein the UE is a target resource owner; and/or the CAPIF authentication and authorization function comprises a CAPIF core function or an authorization function (page 18, 6.3.1.4 Updating resource owner consent; Figure 6.4.1.1-1: Procedure for API invoker obtaining resource owner consent prior to the service API invocation).
As per claim 10, 3GPP discloses a method for invoking a northbound application program interface (API), executed by an API invoker and comprising:
sending an authorization request message to a common API framework (CAPIF) authentication and authorization function for requesting a specified authorization (page 18, section 6.4.1.1, "1. The API invoker requests authorization grant and access token to invoke the service API"; page 19, section 6.4.2 ); wherein the specified authorization is an authorization corresponding to a target resource of a user equipment (UE) (page 18, section 6.4.1.1, "1. The API invoker requests authorization grant and access token to invoke the service API"; pages 17-19, section 6.4.2, 6.3.1.3);;
receiving an authorization response message returned by the CAPIF authentication and authorization function; wherein the authorization response message is used to indicate whether the UE agrees to provide the specified authorization for the API invoker (pages 18-23, 6.5 Solution #5: UE-originated API invocation within CAPIF);
sending, in response to the authorization response message indicating that the UE agrees to provide the specified authorization for the API invoker, a service API invoke request message carrying at least a token to an API exposing function (AEF) (page 18, 6.4.1.1 API invoker obtaining resource owner consent prior to the service API
invocation Figure 6.4.1.1-1 shows the procedure to obtain resource owner consent prior to the service API invocation, which is used in the near real-time consent scenario.); wherein the token is used to obtain, modify or set the target resource (pages 17-23, 6.3.1.3 Obtaining resource owner consent; Figure 6.3.1.3-1: Procedure for obtaining resource owner consent upon service API invocation); and
receiving a service API invoke response message returned by the AEF; wherein the target resource is carried by the service API invoke response message (pages 17-23, 6.3.1.3 Obtaining resource owner consent; Figure 6.3.1.3-1: Procedure for obtaining resource owner consent upon service API invocation).
As per claim 11, 3GPP discloses further comprising:
determining, in response to determining that the target resource needs to be obtained, whether the API invoker has an authorized token or an authorization code (page 18, section 6.4.1.1, "1. The API invoker requests authorization grant and access token to invoke the service API"; page 19, section 6.4.2,);
executing, in response to having the authorized token, a step of sending the service API invoke request message carrying at least the token to the API exposing function (AEF);
sending, in response to having the authorization code, a first token request message to the CAPIF authentication and authorization function to request the token, receiving a token response message carrying the token returned by the CAPIF authentication and authorization function, and sending the service API invoke request message carrying at least the token to the API exposing function (AEF) (pages 17-23, 6.3.1.3 Obtaining resource owner consent; Figure 6.3.1.3-1: Procedure for obtaining resource owner consent upon service API invocation);
wherein the authorization code is carried by the first token request message (page 18, section 6.4.1.1, "1. The API invoker requests authorization grant and access token to invoke the service API"; page 19, section 6.4.2,); and
executing, in response to absence of the authorized token and the authorization code, a step of sending the authorization request message to the common API framework (CAPIF) authentication and authorization function for requesting the specified authorization (page 19, 6.5 Solution #5: UE-originated API invocation within CAPIF; Figure 6.5.1-1: Overview of CAPIF operations).
As per claim 12, 3GPP discloses wherein the token or the authorization code is carried in the authorization response message, and wherein in response the authorization response message carrying the authorization code, the method further comprises: sending a first token request message to the CAPIF authentication and authorization function requesting to obtain the token (page 23, 6.7.1.1 Reducing resource owner consent inquiry in a nested API invocation; Figure 6.7.1.1-1: Procedure for obtaining resource owner consent in a nested API invocation); wherein the authorization code is carried in the first token request message (page 23, 6.7.1.1 Reducing resource owner consent inquiry in a nested API invocation; Figure 6.7.1.1-1: Procedure for obtaining resource owner consent in a nested API invocation); and receiving a token response message carrying the token returned by the CAPIF authentication and authorization function (page 23, 6.7.1.1 Reducing resource owner consent inquiry in a nested API invocation; Figure 6.7.1.1-1: Procedure for obtaining resource owner consent in a nested API invocation).
As per claim 14, 3GPP discloses wherein the authorization request message comprises at least one of:
an identifier of the API invoker (page 21, Figure 6.6.1-1: API provider name used in CAPIF procedures);
an identifier of a target resource owner; an identifier of the target resource; an identifier of a service API requested by the API invoker (page 21, The API provider name uniquely identifies an API provider (e.g. Internet Service Provider).);
an identifier of a service requested by the API invoker; or an identifier of a service operation requested by the API invoker(Figure 6.3.1.3-1: Procedure for obtaining resource owner consent upon service API invocation; page 17, 6.3.1.3 Obtaining resource owner consent).
As per claim 15, 3GPP discloses wherein the token comprises at least one of: a token type; an identifier of the CAPIF authentication and authorization function; an identifier of the API invoker; an identifier of an intended service API; an identifier of a service requested by the API invoker; an identifier of a service operation requested by the API invoker; an identifier of the target resource; an identifier of a target resource owner; a geographic area of the API invoker when accessing the target resource; an identifier of the AEF; or a validity period ending time of the token (pages 17-, 6.3.1.4 Updating resource owner consent; Figure 6.4.1.1-1: Procedure for API invoker obtaining resource owner consent prior to the service API invocation).
As per claim 19, 3GPP discloses wherein the sending the service API invoke request message carrying at least the token to the API exposing function (AEF) comprises: sending, in response to the authorization response message carrying a second token whose token type is an access token, the service API invoke request message carrying at least the second token to the AEF(para 23, The existing mechanisms such as OAuth 2.0 Token Exchange [10] can be used to obtain the access token for the nested API invocation. The detailed procedure for authorization for nested API invocations in this step will be studied in SA3; page 18, This solution addresses the key issues #1, #2 and #3 with regard to obtaining resource owner consent in the UE- and AF-originated API invocation scenarios. CAPIF may authorize the API invoker to invoke the service API based on the resource owner consent slightly before the API invocation. The procedures to obtain the resource owner consent may reuse well-known authorization procedures such as OAuth 2.0), and wherein the service API invoke request message comprises at least one of: an identifier of the API invoker; an identifier of a target resource owner; an identifier of the target resource; an identifier of a service API requested by the API invoker; an identifier of a service requested by the API invoker; an identifier of a service operation requested by the API invoker; or the token (pages 17-, 6.3.1.4 Updating resource owner consent; Figure 6.4.1.1-1: Procedure for API invoker obtaining resource owner consent prior to the service API invocation; page 21, Figure 6.4.1.1-1: Procedure for API invoker obtaining resource owner consent prior to the service API invocation).
As per claim 27, 3GPP discloses wherein the API invoker is another UE different from the UE, or the API invoker is an application function (AF); page 21, Table 6.6.1-1: Registration request; The API provider name uniquely identifies an API provider (e.g. Internet Service Provider).).
As per claim 28, 3GPP discloses wherein the UE is a target resource owner; and/or the CAPIF authentication and authorization function comprises a CAPIF core function or an authorization function (page 18, 6.3.1.4 Updating resource owner consent; Figure 6.4.1.1-1: Procedure for API invoker obtaining resource owner consent prior to the service API invocation).
As per claim 19, 3GPP discloses a method for invoking a northbound application program interface (API), executed by a common API framework (CAPIF) authentication and authorization function, and comprising:
receiving an authorization request message sent by an API invoker requesting to obtain a specified authorization (page 18, section 6.4.1.1, "1. The API invoker requests authorization grant and access token to invoke the service API"; page 19, section 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";);
wherein the specified authorization is an authorization corresponding to a target resource of a user equipment (UE) (pages 17-, 6.3.1.4 Updating resource owner consent; Figure 6.4.1.1-1: Procedure for API invoker obtaining resource owner consent prior to the service API invocation; page 21, Figure 6.4.1.1-1: Procedure for API invoker obtaining resource owner consent prior to the service API invocation);
sending the authorization request message to the UE; receiving an authorization response message returned by the UE (page 18, section 6.4.1.1, "1. The API invoker requests authorization grant and access token to invoke the service API"; page 19, section 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";);
wherein the authorization response message is used to indicate whether the UE agrees to provide the specified authorization for the API invoker (page 18, section 6.4.1.1, "1. The API invoker requests authorization grant and access token to invoke the service API"; page 19, section 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";); and
sending the authorization response message to the API invoker (page 18, section 6.4.1.1, "1. The API invoker requests authorization grant and access token to invoke the service API"; page 19, section 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";).
As per claim 45, 3GPP discloses wherein a token or an authorization code is carried in the authorization response message in response the authorization response message indicating that the UE agrees to provide the specified authorization to the API invoker ((pages 17-23, 6.3.1.3 Obtaining resource owner consent; Figure 6.3.1.3-1: Procedure for obtaining resource owner consent upon service API invocation);
wherein the token is used to obtain, modify or set the target resource-; and wherein in response the authorization response message carrying the authorization code, the method further comprises (page 18, 6.3.1.4 Updating resource owner consent):
receiving a first token request message sent by the API invoker to request a token; wherein the authorization code is carried in the first token request message, and the token is used to obtain, modify or set the target resource (pages 17-23, 6.3.1.3 Obtaining resource owner consent; Figure 6.3.1.3-1: Procedure for obtaining resource owner consent upon service API invocation); and
sending a token response message carrying the token to the API invoker (pages 16-18, Figure 6.4.1.1-1: Procedure for API invoker obtaining resource owner consent prior to the service API invocation).
As per claim 47, 3GPP discloses wherein the authorization request message comprises at least one of: an identifier of the API invoker; an identifier of a target resource owner; an identifier of the target resource; an identifier of a service API requested by the API invoker; an identifier of a service requested by the API invoker; or an identifier of a service operation requested by the API invoker (Figure 6.3.1.3-1: Procedure for obtaining resource owner consent upon service API invocation; page 17, 6.3.1.3 Obtaining resource owner consent)..
As per claim 48, 3GPP discloses The method according to claim wherein the token comprises at least one of:
a token type;
an identifier of the CAPIF authentication and authorization function;
an identifier of the API invoker;
an identifier of an intended service API; an identifier of a service requested by the API invoker; an identifier of a service operation requested by the API invoker;
an identifier of the target resource; an identifier of a target resource owner;
an identifier of the API exposing function (AEF); or a validity period ending time of the token (page 18, 6.3.1.4 Updating resource owner consent; Figure 6.4.1.1-1: Procedure for API invoker obtaining resource owner consent prior to the service API invocation).
As per claim 59, 3GPP discloses wherein the CAPIF authentication and authorization function comprises a CAPIF core function or an authorization function; and/or the UE is a target resource owner (page 18, 6.3.1.4 Updating resource owner consent; Figure 6.4.1.1-1: Procedure for API invoker obtaining resource owner consent prior to the service API invocation).
As per claim 64, 65, and 67, 3GPP discloses 64. A northbound application program interface API invoking apparatus, comprising: a processor; and
a memory for storing processor-executable instructions; wherein, the processor is configured to execute the northbound application program interface (API) invoking method according to claims 1, 10, and 44 (para, 6.5.1 Solution description KI#1 describes the scenario of UE application client (AC) invokes 3GPP northbound APIs (e.g. NEF location API). In figure 6.5.1-1, the AC plays the role of the API invoker, and triggers a number of service operations with CCF and AEF (e.g. onboarding, security, API discovery)..
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Bodes et al. discloses (US 20060100835 A1) discloses northbound Application Programming Interface (API) and a southbound API.
Pateromichelakis et al (US 20250055716 A1) discloses an API invocation charging request and includes API invoker information (e.g. invoker's ID and IP address, location, timestamp) and service API information (e.g. service API name and version, invoked operation, input parameters, invocation result) towards the CAPIF core function.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MOHAMMAD A SIDDIQI whose telephone number is (571)272-3976. The examiner can normally be reached Monday-Friday.
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, Carl G Colin can be reached at 571-272-3862. 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.
/MOHAMMAD A SIDDIQI/Primary Examiner, Art Unit 2493
Prosecution Insights