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 .
DETAILED ACTION
2. This action is in response to the Request for Continued Examination and Amendment filed July 27, 2026.
3. Claims 1-5,7-19, 21, and 22 have been canceled and new claims 23-42 have been added.
4. Claims 23-42 have been examined and are pending with this action.
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 (i.e., changing from AIA to pre-AIA ) 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.
5. Claims 23-40 are rejected under 35 U.S.C. 102(a)(1) and 102(a)(2) as being anticipated by Suzuki et al. (US 2024/0346126 A1).
INDEPENDENT:
As per claim 23, Suzuki teaches a method performed by a common application programming interface framework (CAPIF) core function (see Suzuki, FIG. 3), the method comprising:
receiving, from an user equipment (UE)-deployed application programming interface (API) invoker, a request for access, via a service API, to a resource associated with one or more other UEs, wherein the request comprises resource owner identity information (see Suzuki, Abstract: “a reception unit that receives, from a first user, an authorization request for an Application Programming Interface (API) call, for which the authorization of a second user is required”; [0006]: “In the CAPIF, an API invoker is authorized to invoke an API with authentication of the CCF and is enabled to access an API exposing function.”; and [0018]: “A communication method according to one aspect of the present disclosure includes: indicating to a network node, by a first user, an authorization request for invocation of an Application Programming Interface (API) which requires authorization from a second user”);
determining, based on the request and resource owner authorization information, whether the API invoker is authorized to access the resource via the service API (see Suzuki, Abstract: “a control unit that identifies the second user on the basis of the authorization request”; [0005]: “In the 3GPP core network, APIs are open for external applications, and third-party applications in the CAPIF can invoke an API and access an API exposing function. At that time, a CAPIF Core Function (CCF) in the network manages an application capable of invoking the API and then authenticates and authorizes the application that has invoked the API (API invoker)”; [0018]: “verifying, by the second user, the authorization request and authorizing, by the second user, the first user”; [0080]: “Meanwhile, a security method is agreed between API invoker 101 and CCF 102. Note that a Client Credential scheme specified in OAuth 2.0 is used for this security method. In this scheme, the API invocation is authorized by authentication from the client (API invoker) alone.”; [0082]: “CCF 102 is a network node and manages an application capable of invoking an API. Upon receiving an authorization request for the API invocation from API invoker 101, CCF 102 performs verification of the authorization request and authenticates/authorizes API invoker 101.”; and [0086]: “In S102, CCF 102 verifies the authorization request from API invoker 101 and performs authentication processing for API invoker 101.”); and
sending, to the API invoker, authorization information for accessing the resource via the service API (see Suzuki, [0018]: “transmitting to the network node, by the second user, information indicating that the authorization has been made for the invocation of the API of the first user; issuing an access token, by the network node, based on the authorization of the second user; transmitting the access token to the first user, by the network node”; and [0087]: “Upon completion of the authentication processing, in S103, CCF 102 transmits authorization information on the API invocation, specifically an access token”).
As per claim 32, Suzuki teaches an apparatus comprising a processor and a memory coupled to the processor and having instructions stored thereon, which when executed by the processor cause the apparatus to:
receive, from a user equipment (UE)-deployed application programming interface (API) invoker, a request for access, via a service API, to a resource associated with one or more other UEs, wherein the request comprises resource owner identity information (see Claim 23 rejection above);
determine, based on the request and resource owner authorization information, whether the API invoker is authorized to access the resource via the service API (see Claim 23 rejection above); and
send, to the API invoker, authorization information for accessing the resource via the service API (see Claim 23 rejection above).
DEPENDENT:
As per claims 24 and 33, which respectively depend on claims 23, and 32, Suzuki further teaches wherein the request further comprises one or more of authentication information, API invoker identity information, information identifying the service API, API invocation context information, service API resource information, and service API operation information (see Suzuki, [0079]: “API invoker 101 is an application from which an API is invoked. API invoker 101 is connectable to CCF 102 and API provider domain 103 and is registered (onboarding) in CCF 102 in advance. Note that API invoker 101 may be a third-party application or may be an application operated by the same carrier that provides CCF 102 or API provider domain 103.”; and [0093]: “client 201 requests issuance of an access token by transmitting authentication information and the authorization code to authorization server 203, thus receiving the access token from authorization server 203. Client 201 accesses protection resource 204, using the access token.”).
As per claims 25 and 34, which respectively depend on claims 23, and 32, Suzuki teaches further comprising:
receiving resource owner registration information comprising resource identity information, and one or more of service conditions, consent triggering conditions and API identity information (see Suzuki, Abstract: “a control unit that identifies the second user on the basis of the authorization request”; [0093]: “client 201 requests issuance of an access token by transmitting authentication information and the authorization code to authorization server 203, thus receiving the access token from authorization server 203. Client 201 accesses protection resource 204, using the access token.”; and [0107]: “a request from user 305 may be trigger a request for authorization of API invocation”); and
determining, based on the resource owner registration information, an association between the resource owner and resources owned (see Suzuki, [0120]: “Upon completion of the authentication processing, in S303, CCF 303 identifies, based on the authorization request from user 301, user 302 from which the authorization is to be acquired and, in S304, indicates, to user 302, that the authorization request for the API invocation has been received from user 301.”; and [0125]: “In this manner described above, according to the present embodiment, a CCF identifies user 302 (resource holder) based on an authorization request from user 301 for invocation of an API that requires authorization from user 302, thereby making it possible to acquire authorization from the other user while eliminating the need for redirection.”).
As per claims 26 and 35, which respectively depend on claims 23, and 32, Suzuki further teaches wherein determining whether the API invoker is authorized to access the resource via the service API comprises requesting service API authorization from a policy control function (see Suzuki, [0038]: “AMF 30A-1 is a network node having functions such as RAN interface termination, non-access stratum (NAS) termination, registration management, connection management, reachability management, and mobility management. AMF 30A-1 is connected to UE 10A,… policy control function (PCF) 30A-8”).
As per claims 27 and 36, which respectively depend on claims 23, and 32, Suzuki further teaches wherein determining whether the API invoker is authorized to access the resource via the service API comprises requesting subscription and policy parameters from a database (see Suzuki, [0043]: “UDM 30A-6 is a network node that manages subscriber data and authentication data. UDM 30A-6 is connected to a user data repository (UDR) that holds the data.”; and [0044]: “AUSF 30A-7 is a network node that authenticates a subscriber/UE 10A for the subscriber data held in the UDR.”).
As per claims 28 and 37, which respectively depend on claims 23, and 32, Suzuki further teaches wherein determining whether the API invoker is authorized to access the resource via the service API comprises checking the resource owner authorization information via a resource owner function to determine authorization to access the resource via the service API (see Suzuki, [0120]: “Upon completion of the authentication processing, in S303, CCF 303 identifies, based on the authorization request from user 301, user 302 from which the authorization is to be acquired and, in S304, indicates, to user 302, that the authorization request for the API invocation has been received from user 301.”; and [0125]: “In this manner described above, according to the present embodiment, a CCF identifies user 302 (resource holder) based on an authorization request from user 301 for invocation of an API that requires authorization from user 302, thereby making it possible to acquire authorization from the other user while eliminating the need for redirection.”).
As per claims 29 and 38, which respectively depend on claims 23, and 32, Suzuki teaches further comprising sending the authorization information to an API exposing function (AEF) (see Suzuki, [0005]: “In the 3GPP core network, APIs are open for external applications, and third-party applications in the CAPIF can invoke an API and access an API exposing function.”; and [0006]: “In the CAPIF, an API invoker is authorized to invoke an API with authentication of the CCF and is enabled to access an API exposing function”).
As per claims 30 and 39, which respectively depend on claims 23, and 32, Suzuki further teaches wherein the resource owner authorization information comprises an indication of consent by a user of the resource owner (see Suzuki, [0018]: “verifying, by the second user, the authorization request and authorizing, by the second user, the first user”; and [0100]: “Meanwhile, in S203, resource holder 202 authorizes client 201 to access protection resource 204”).
As per claims 31 and 40, which respectively depend on claims 23, and 32, Suzuki teaches further comprising sending, to the API invoker, information enabling the API invoker to invoke the requested API (see Suzuki, [0006]: “In the CAPIF, an API invoker is authorized to invoke an API with authentication of the CCF and is enabled to access an API exposing function”).
Claim Rejections - 35 USC § 103
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 (i.e., changing from AIA to pre-AIA ) 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 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.
6. Claims 41-42 are rejected under 35 U.S.C. 103 as being unpatentable over Suzuki et al. (US 2024/0346126 A1) in view of Official Notice.
As per claim 41, Suzuki teaches an apparatus comprising a processor and a memory coupled to the processor and having instructions stored thereon, which when executed by the processor cause the apparatus to:
receive, from a resource owner function for an user equipment (UE)-deployed application programming interface (API) invoker, a request, via a service API, to a resource associated with one or more other UEs, wherein the request comprises resource owner identity information (see Claim 1 rejection above);
determine, based on the request and resource owner authorization information, to authorization for the API invoker to access the resource via the service API (see Claim 1 rejection above); and
send, to the API invoker, a request or a notification (see Claim 1 rejection above).
Suzuki does not explicitly teach that the request is a revoke access request; that the determination is to revoke authorization to access; and that the request or notification sent to the API invoker is a revocation request or revocation notification, respectively.
The examiner takes Official Notice.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to modify the system of Suzuki in view of Official Notice so that the request of Suzuki is a revoke access request; that the determination of Suzuki is to revoke authorization to access; and the request or notification sent to the API invoker is a revocation request or revocation notification, respectively. One would be motivated to do so because it well-known, routine, or conventional for any changes to a protected resource will require authorization as taught by Suzuki and such functionality associated with authorization will still remain the same whether the objective is to access or revoke access, to a resource.
As per claim 42, which depends on claim 41, Suzuki and Official Notice further teaches wherein the revocation request or revocation notification comprises one or more of API invoker identity information, service API identification information, security information, or a cause indicating resource owner authorization revocation (see Claim 1 rejection above).
Conclusion
7. For the reasons above, claims 23-42 have been rejected and remain pending.
8. Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL Y WON whose telephone number is (571)272-3993. The examiner can normally be reached on Wk.1: M-F: 8-5 PST & Wk.2: M-Th: 8-7 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, Nicholas R Taylor can be reached on 571-272-3889. 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.
/Michael Won/Primary Examiner, Art Unit 2443
Prosecution Insights