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 .
Response to Amendment
Applicant’s amendment filed 26 March 2026 amends claims 1-3, 6, 9-11, 13-18, and 21. Applicant’s amendment has been fully considered and entered.
Examiner Notes
Examiner notes that while Applicant’s remarks do not address the previous §112 rejections, the amendments filed 26 March 2026 are sufficient to overcome the previous §112 rejections.
Response to Arguments
Applicant argues on page 12 of the response, “Neither LTE nor Tao teaches or suggests including both an API invoker identifier for the apparatus and a UE identifier for the apparatus in an authentication initiation request sent to an AEF…” In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). Applicant has failed to address the proposed modification of LTE utilizing the Tao reference as presented in the Non-Final rejection dated 30 December 2025 (“Non-Final”)(See page 6). Specifically, the Non-Final makes it clear that the proposed modification to LTE was to include a terminal device identifier in the authentication initiation request that already included an API invoker ID. Therefore, when modified in the manner proposed in the Non-Final, the authentication initiation request of LTE includes an API invoker ID and a terminal identifier.
Applicant argues on page 12 of the response, “…let alone that ‘the service invocation response indicates the result based on the application programming interface invoker identifier and the UE identifier,’ as recited in amended independent claim 9.” This argument is not persuasive because the API invoker receives a northbound API invocation response that specifies that the requested API will be invoked (Page 15, step 8). This response is based upon the authentication initiation request that includes the API invoker ID and a terminal identifier (as discussed above). Therefore, the response can be considered to indicate a result based on the identifiers as claimed.
Applicant argues on page 13 of the response, “The combination of the terminal device identifier from Tao with the API invoker ID from LTE improperly transposes an authorization request to HSS/UDM onto an authentication initiation request to an AEF, without any teaching, suggestion, or motivation to make such a combination, and without a reasonable expectation of success that such a combination would achieve the claimed result.” This argument is not persuasive because page 6 of the Non-Final clearly set forth that it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the authentication initiation request of LTE to have included a terminal device identifier in order to validate whether the terminal device is allowed to use the invoked API as suggest by Tao ([0085]). Applicant has not actually addressed to motivation to combine that was presented in the Non-Final.
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.
The factual inquiries 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 nonobviousness.
Claims 9, 11-17, 19 are rejected under 35 U.S.C. 103 as being unpatentable over “LTE: 5G; Security Aspects of Common API Framework for 3GPP Northbound APIs (3GPP TS 33.122 version 15.0.0 Release 15)” from IDS dated 18 October 2024 (“LTE”), in view of Tao, U.S. Publication No. 2023/0113108. Referring to claim 9, LTE discloses an API invoker that generates an API exposing function (“AEF”) function key (Page 12, Figures 6.5.2.1-1, step 2: key AEFPSK reads on the claimed application programming interface exposing function key), which meets the limitation of one or more derive or obtain an application programming interface exposing function key associated with an application programming interface exposing function of a wireless network. API invoker sends an authentication initiation request to the AEF that includes an API invoker ID (Page 12, Figure 6.5.2.1-1, step 3), which meets the limitation of send an authentication initiation request to the application programming interface exposing function, the authentication initiation request including an application programming interface invoker identifier for the apparatus [and a user equipment (UE) identifier for the apparatus]. The API invoker receives an authentication initiation response from the AEF (Figure 6.5.2.1-1, step 5 & Page 13, step 5), which meets the limitation of receiving an authentication initiation response from the application programming interface exposing function. The API invoker and the AEF establish a TSL connection session using key AEFPSK (Figure 6.5.2.1-1, step 6 & Page 13, step 6), which meets the limitation of establish a secure connection with the application programming interface exposing function using the application programming interface exposing function key. After the TSL connection session is established, the API invoker sends a northbound API invocation request to the AEF that includes an access token (Page 15, step 6), which meets the limitation of send, over the secure connection, a service invocation request to the application programming interface exposing function, the service invocation request including an access token. The API invoker receives a northbound API invocation response that specifies that the requested API will be invoked (Page 15, step 8: response is based upon a request that includes the identifier. Therefore, the response can be considered to be said to indicate a result based on the identifier as claimed), which meets the limitation of receive, over the secure connection and from the application programming interface exposing function, a service invocation response indicating a result of the application programming interface request, wherein the service invocation response indicates the result based on the application programming interface invoker identifier [and the UE identifier].
LTE does not explicitly disclose that the API invoker is implemented in a device including memory and a processor. Tao discloses a wireless network system wherein network devices in the system include memory and a processor ([0115]-[0116]), which meets the limitation of at least one memory, and at least one processor coupled with the at least one memory. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the API invoker of LTE to have been implemented in a device comprising memory and a processor in order to implement the functionality of the API invoker as suggested by Tao ([0116]).
LTE does not specify that the authentication initiation request includes a user equipment identifier. Tao discloses a wireless network system that utilizes requests that include terminal device identifiers ([0085]), which meets the limitation of the authentication initiation request including a user equipment (UE) identifier for the apparatus, wherein the service invocation response indicates the result based on the UE identifier. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the authentication initiation request of LTE to have included a terminal device identifier in order to validate whether the terminal device is allowed to use the invoked API as suggest by Tao ([0085]).
Referring to claim 11, LTE discloses the API invoker and the CAPIF generate an API exposing function (“AEF”) function key (Page 12, Figures 6.5.2.1-1, step 2: key AEFPSK) such that AEFPSK is generated using a key derivation function that takes as inputs a relevant key after authentication between the API invoker and the CAPIF core function (Pages 10-11 & 18: relevant key reads on the claimed application programming interface framework core function key; CAPIF reads on the claimed application programming interface framework core function; key derivation function utilizes both API invoker information and CAPIF information such that the acquisition of such information represents the claimed interaction; Examiner notes that the claims do not functionally utilized the claimed identifiers outside of merely being provided. Therefore, as it pertains to the claimed interaction, the claimed identifiers represent non-functional descriptive material that is not give patentable weight. See MPEP 2111.04-2111.05), which meets the limitation of one or more of derive or obtain an application programming interface framework core function key via interaction with an application programming interface framework core function of the wireless network, wherein the interaction includes providing the application programming interface invoker identifier and the UE identifier to the application programming interface framework core function. The AEFPSK is generated using a key derivation function that takes as inputs a relevant key and an input string S that formed using parameters that include Length of Service API interface information and Length of TLS Session ID (Page 18: Length of Service API interface information and Length of TLS Session ID can each be considered a freshness parameter), which meets the limitation of apply a key derivation function to the application programming interface framework core function key to generate the application programming interface exposing function key, the key derivation function utilizing input parameters including freshness parameter.
Referring to claim 12, LTE does not specify that the authentication initiation request includes an application identifier. Tao discloses a wireless network system that utilizes requests that include an application identifier of a terminal device ([0085]), which meets the limitation of the authentication initiation request further includes an application identifier. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the authentication initiation request of LTE to have included an application identifier of the terminal device in order to validate whether the terminal device is allowed to use the invoked API as suggest by Tao ([0085]).
Referring to claim 13, LTE discloses the API invoker sends an access token request to the CAPIF (Pages 14-15, 6.5.2.3, step 2: access token request reads on the claimed onboard application programming interface invoker request; CAPIF reads on the claimed application programming interface framework core function of the wireless network), which meets the limitation of send, to an application programming interface framework core function of the wireless network, an onboard application programming interface invoker request. The CAPIF verifies the access token request (Pages 14-15, 6.5.2.3, step 3) and provides a response to the API invoker that includes the access token (Pages 14-15, 6.5.2.3, step 4), which meets the limitation of receive, from the application programming interface framework core function, an onboard application programming interface invoker response that includes the access token. The access token request can include the API invoker ID (Page 15, Note 1), which meets the limitation of wherein the access token is based on authentication using the application programming interface invoker identifier [and the UE identifier].
LTE does not specify that the access token request includes a user equipment identifier. Tao discloses a wireless network system that utilizes requests that include terminal device identifiers ([0085]), which meets the limitation of the wherein the access token is based on authentication using the UE identifier. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the access token request of LTE to have included a terminal device identifier in order to validate whether the terminal device is allowed to use the invoked API as suggest by Tao ([0085]).
Referring to claim 14, LTE discloses that the API invoker sends a security method request to the CAPIF (Pages 11-12, 6.3.1, step 2), which meets the limitation of send, to an application programming interface framework core function of the wireless network, a security method request [including the UE identifier for the apparatus]. The API invoker receives a security method response from the CAPIF that includes a selected security method (Pages 11-12, 6.3.1, step 4), which meets the limitation of receive, from the application programming interface framework core function, a security method response that identifies a security method. The selected security method included in the response will be utilized by the API invoker in the establishment of subsequent communications (Page 12, step 4: The communication established with the AEF is a subsequent communication since it is described as occurring later in the process. See section 6.5 on pages 12-15.), which meets the limitation of establish the secure connection with the application programming interface exposing function using the security method.
LTE does not specify that the security method request includes a user equipment identifier. Tao discloses a wireless network system that utilizes requests that include terminal device identifiers ([0085]), which meets the limitation of the authentication initiation request including a user equipment identifier for the apparatus. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the security method request of LTE to have included a terminal device identifier in order to validate whether the terminal device is allowed to use the invoked API as suggest by Tao ([0085]).
Referring to claim 15, LTE discloses an API exposing function (“AEF”) that receives an authentication initiation request includes an API invoker ID from an API invoker (Page 12, Figure 6.5.2.1-1, step 3: AEF reads on the claimed apparatus), which meets the limitation of receive, from an application program interface invoker, an authentication initiation request, the authentication initiation request including an application programming interface invoker identifier [and a user equipment identifier associated with the application programming interface invoker]. The AEF sends an authentication initiation response to the API invoker (Figure 6.5.2.1-1, step 5 & Page 13, step 5), which meets the limitation of send, the application programming interface invoker, an authentication initiation response. The AEF and the API invoker establish a TSL connection session using key AEFPSK (Figure 6.5.2.1-1, step 6 & Page 13, step 6) generated by the API invoker (Page 12, Figures 6.5.2.1-1, step 2: key AEFPSK reads on the claimed application programming interface exposing function key), which meets the limitation of establish a secure connection with the application programming interface invoker using an application programming interface exposing function key. After the TSL connection session is established, the AEF receives a northbound API invocation request from the API invoker that includes an access token (Page 15, step 6), which meets the limitation of receive, over the secure connection and from the application programming interface invoker, a service invocation request, the service invocation request including an access token. The API invoker receives a northbound API invocation response that specifies that the requested API will be invoked (Page 15, step 8: response is based upon a request that includes the identifier. Therefore, the response can be considered to be said to indicate a result based on the identifier as claimed), which meets the limitation of cause an application programming interface invocation action based on the application programming interface request, send, over the secure connection and to the application programming interface invoker, a service invocation response indicating a result of the application programming interface invocation action, wherein the service invocation response indicates the result based on the application programming interface invoker identifier [and the UE identifier].
LTE does not explicitly disclose that the AEF is implemented in a device including memory and a processor. Tao discloses a wireless network system wherein network devices in the system include memory and a processor ([0115]-[0116]), which meets the limitation of at least one memory, and at least one processor coupled with the at least one memory. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the AEF of LTE to have been implemented in a device comprising memory and a processor in order to implement the functionality of the AEF as suggested by Tao ([0116]).
LTE does not specify that the authentication initiation request includes a user equipment identifier. Tao discloses a wireless network system that utilizes requests that include terminal device identifiers ([0085]), which meets the limitation of the authentication initiation request including a user equipment (UE) identifier associated with the application programming interface invoker, wherein the service invocation response indicates the result based on the UE identifier. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the authentication initiation request of LTE to have included a terminal device identifier in order to validate whether the terminal device is allowed to use the invoked API as suggest by Tao ([0085]).
Referring to claim 16, LTE does not specify that the authentication initiation request includes a user equipment identifier. Tao discloses a wireless network system that utilizes requests that include terminal device subscription identifiers ([0085]), which meets the limitation of wherein the UE identifier includes one or more of a subscription permanent identifier, a generic subscription identifier. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the authentication initiation request of LTE to have included a terminal device identifier in order to validate whether the terminal device is allowed to use the invoked API as suggest by Tao ([0085]).
Referring to claim 17, LTE discloses in response to receiving the authentication initiation request, the AEF sends a security information request to the CAPIF (Pages 12-13, step 4a), which meets the limitation of in response to the authentication initiation request, send, to an application programming interface framework core function of a wireless network, a security information request [that includes the UE identifier]. The CAPIF provides a security information response the AEF that includes AEFPSK (Pages 12-13, step 4b), which meets the limitation of receive, from the application programming interface framework core function, a security information response that includes the application programming interface exposing function key.
LTE does not specify that the service information request includes a user equipment identifier. Tao discloses a wireless network system that utilizes requests that include terminal device identifiers ([0085]), which meets the limitation of the, a security information request that includes the UE identifier. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the service information request of LTE to have included a terminal device identifier in order to validate whether the terminal device is allowed to use the invoked API as suggest by Tao ([0085]).
Referring to claim 19, LTE discloses that the security information response can include an API invoker root CA certificate (Page 12, step 2) where the root CA certificate is communicated together with the access token (Page 9, step 1), which meets the limitation of wherein the security information response further [includes] an instance of the access token.
LTE does not specify that the transmission of the enrollment information includes the transmission of the access token as part of the root CA certificate. However, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the access token to have been transmitted as part of the root CA certificate, instead of being transmitted along with the root CA certificate, because such a transmission represents one of a finite number of possible transmission embodiments that could have been implemented by one of ordinary skill in the art with a reasonable expectation of success.
Claims 10 are rejected under 35 U.S.C. 103 as being unpatentable over “LTE: 5G; Security Aspects of Common API Framework for 3GPP Northbound APIs (3GPP TS 33.122 version 15.0.0 Release 15)” from IDS dated 18 October 2024 (“LTE”), in view of Tao, U.S. Publication No. 2023/0113108, in view of Ge, U.S. Publication No. 2022/0174585. Referring to claim 10, LTE discloses that the API invoker sends an authentication initiation request and a northbound API invocation request to the AEF (Page 12, Figure 6.5.2.1-1, step 3 & Page 15, step 6: the functionality that performs the request generation reads on the claimed application), which meets the limitation of execute an application to generate the authentication initiation request and the service invocation request.
LTE does not specify that the API invoker is implemented in the user equipment. Ge discloses that the API invoker can be implemented by the user equipment ([0263]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the user equipment of LTE to have implemented the API invoker because the user equipment represents one of a finite number of possible devices that could have utilized by one of ordinary skill in the art to implement the API invoker with a reasonable expectation of success.
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over “LTE: 5G; Security Aspects of Common API Framework for 3GPP Northbound APIs (3GPP TS 33.122 version 15.0.0 Release 15)” from IDS dated 18 October 2024 (“LTE”), in view of Tao, U.S. Publication No. 2023/0113108, and further in view of Ito, WO 2019/194242.
Referring to claim 18, LTE discloses that the AEF receives a northbound API invocation request from the API invoker that includes an access token (Page 15, step 6), received from the CAPIF (Page 14, figure 6.5.2.3-1, step 4), such that the AEF verifies the access token and the northbound API invocation request using authorization claims in the access token (Pages 14-15, step 7), which meets the limitation of cause the apparatus to perform an authorization check by verifying the access token, and requested service application programming interfaces information received from the application programming interface invoker with the service invocation request, based on information including service application programming interface authorization information and an access token received from an application programming interface framework core function and available locally.
LTE does not specify that the authentication initiation request includes a user equipment identifier. Tao discloses a wireless network system that utilizes requests that include terminal device identifiers ([0085]), which meets the limitation of the user equipment identifier. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the authentication initiation request of LTE to have included a terminal device identifier in order to validate whether the terminal device is allowed to use the invoked API as suggest by Tao ([0085]).
LTE does not specify that the AEF verifies the information from the authentication initiation request. Ito discloses the AEF receiving an API invocation request that includes an API invoker ID such that the AEF compares the request information, such as the received API invoker ID, with information received from the CCR in order to perform verification (Page 15, paragraph 3 - paragraph 6: the authentication initiation request of LTE, as modified above, includes the terminal identifier. Therefore, verification would include the verification of the terminal identifier also), which meets the limitation of verifying that the application programming interface invoker identifier and the UE identifier match an authorized application programming interface invoker identifier and an authorized UE identifier. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the AEF of LTE to have verified the invoker ID and terminal identifier received in the authentication initiation request in order to provide identity verification for the requested service as suggested by Ito (Page 15, paragraph 6).
Allowable Subject Matter
Claims 1-8, 21 are allowed.
The following is an examiner’s statement of reasons for allowance:
The prior art does not disclose or make obvious the claimed apparatus that generates and sends an onboard service request that includes key data to an application programming interface framework core function such that the key data is utilized to generate an authorization key used by the apparatus and the application programming interface framework core function to establish a secure connection. The secure connection is subsequently utilized by the apparatus to send an onboard application programming interface invoker request to the application programming interface framework core function such that the apparatus receives on onboard application programming interface invoker response from the application programming interface framework core function.
The closest prior art, “LTE: 5G; Security Aspects of Common API Framework for 3GPP Northbound APIs (3GPP TS 33.122 version 15.0.0 Release 15)” from IDS dated 18 October 2024 (“LTE”), discloses the establishment of a secure TLS connection between an API invoker and a CAPIF responsive to the API invoker receiving enrollment information from an API provider domain (page 9, steps 1-2). The API invoker transmits an onboard API invoker request to the CAPIF over the established TLS connection such that the API invoker receives an onboard API invoker response from the CAPIF (Pages 9-10, steps 3-6).
LTE does not disclose that the onboarding enrollment information is received by the API invoker (Page 9, step 1) in response to the API invoker generating and sending an onboard server request to the CAPIF that includes key data utilized by the CAPIF and the key invoker to establish the TLS connection (Page 9, step 2).
Any comments considered necessary by applicant must be submitted no later than the payment of the issue fee and, to avoid processing delays, should preferably accompany the issue fee. Such submissions should be clearly labeled “Comments on Statement of Reasons for Allowance.”
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BENJAMIN E LANIER whose telephone number is (571)272-3805. The examiner can normally be reached M-Th: 5:30-4:00.
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, Alexander Lagor can be reached at 5712705143. 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.
/BENJAMIN E LANIER/ Primary Examiner, Art Unit 2437
Prosecution Insights