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 .
This Office Action is in response to Application No. 18/833,549 filed on 07/26/2024.
Claims 1-3, 6-10, 13-24 have been examined and are pending in this application. As per the Preliminary Amendment filed on 07/26/2024, claims 4-5, and 11-12 have been cancelled, claims 1, 7, 9, 13, 17-18 were amended and claims 21-24 were added.
Priority
Acknowledgment is made of Applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d) to parent Application No. 63304261 filed on 01/28/2022, and parent Application No. PCT/IB2023/050556, filed on 01/23/2023.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 11/11/2024, 11/20/2024, 06/20/2025, is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Specification
The abstract of the disclosure is objected to because The abstract should be in narrative form and generally limited to a single paragraph within the range of 50 to 150 words in length . A corrected abstract of the disclosure is required and must be presented on a separate sheet, apart from any other text. See MPEP § 608.01(b).
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 1-3, and 6 are rejected under 35 U.S.C. 103 as being unpatentable over (“5G; Authentication and Key Management for Applications (AKMA) based on 3GPP credentials in the 5G System (5GS) (3GPP TS 33.535”; Hereinafter “TS 33.535”) in view of (“LTE; 5G; Security aspects of Common API Framework (CAPIF) for 3GPP northbound APIs (3GPP TS 33.122 version 16.4.0 Release 16)”; Hereinafter “TS 33.122”) from IDS dated 6/20/2025; and further in view of (“LTE; 5G; Common API Framework for 3GPP Northbound APIs (3GPP TS 29.222)”; Hereinafter “TS 29.222”) and Rajadurai et al. (U.S Pub. No. 2023/0164553 A; Hereinafter “Rajadurai”).
As per claim 1, TS 33.535 teaches an apparatus for wireless communication, comprising: transmit, to a unified data management, an authentication request for a user equipment (TS 33.535: 6.1, fig. 6.1-1, “During the primary authentication procedure, the AUSF interacts with the UDM in order to fetch authentication information such as subscription credentials (e.g. AKA Authentication vectors) and the authentication method using the Nudm_UEAuthentication_Get Request service operation.”);
receive, from the unified data management, an authentication response including an indication (TS 33.535: 6.1, fig. 6.1-1, “In the response, the UDM may also indicate to the AUSF whether the AKMA Anchor key needs to be generated for the UE. If the AKMA indication is included, the UDM shall also include the RID of the UE”);
derive, in response to receiving the indication, security information (AKMA Anchor Key (KAKMA) and the A-KID) (TS 33.535: 6.1, fig. 6.1-1, “If the AUSF receives the AKMA indication from the UDM, the AUSF shall store the KAUSF and generate the AKMA Anchor Key (KAKMA) and the A-KID from KAUSF after the primary authentication procedure is successfully completed”); and
store the security information as a user equipment context along with an identifier of the user equipment (TS 33.535: 6.1, fig. 6.1-1, After AKMA key material is generated, the AUSF selects the AAnF as defined in clause 6.7, and shall send the generated A-KID and KAKMA to the AAnF together with the SUPI of the UE using the Naanf_AKMA_KeyRegistration Request service operation. The AAnF shall store the latest information sent by the AUSF…The AAnF sends the response to the AUSF using the Naanf_AKMA_AnchorKey_Register Response service operation. A-KID identifies the KAKMA key of the UE. A-KID shall be in NAI format as specified in clause 2.2 of IETF RFC 7542 [6], i.e. username@realm. The username part shall include the RID and the A-TID (AKMA Temporary UE Identifier), and the realm part shall include Home Network Identifier.).
TS 33.535 does not explicitly teaches the derived information as common application programming interface framework.
However, in the related art, TS 33.122 teaches common application programming interface framework (TS 33.122: 6.5.2.1, “The AEF shall request for security information from the CAPIF Core Function to perform authentication and secure interface establishment with the API invoker, if the AEF does not have a valid key. The CAPIF Core Function provides the security information related to the chosen security method (TLS-PSK: AEFPSK) to the AEF over CAPIF-3 reference point. The CAPIF core function shall provide the remaining validity timer value for the key AEFPSK.”) and TS 29.122 also discloses (5.6.2.2.2, “Upon receiving the above described HTTP PUT message, the CAPIF core function shall: 1. determine the security method for each service API interface as specified in 3GPP TS 33.122 [16]; 2. store the Notification Destination URI for security related notification; 3. create a new resource as defined in clause 8.5.2.1; and 4. return the security method information and the CAPIF Resource URI in the response message.”)
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to adapt the UE specific authentication derived security material of TS 33.535 for use as CAPIF security information, because TS 33.122 and TS 29.222 already teaches that CAPIF relies on CAPIF core provided security information to authenticate entities and establish secure CAPIF interfaces. Using the existing post authentication key and identifier material in CAPIF would leverage established 5G authentication results, improves security continuity and avoids unnecessary duplicate key generation procedures.
Furthermore, Rajadurai teaches an apparatus comprising at least one memory; and at least one processor coupled with the at least one memory and configured to cause the apparatus to (Rajadurai; para [45], “These blocks, which may be referred to herein as units or modules or the like, are physically implemented by analog or digital circuits such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuits, or the like, and may optionally be driven by firmware.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the apparatus of TS 33.535 to have been implemented in a device comprising memory and a processor in order to implement the functionality of the apparatus as suggested by Rajadurai (para [45]).
As per claim 2, TS 33.535 in view of TS 33.122 and TS 29.222 teaches the independent claim 1. TS 33.535 teaches the authentication response further including one or more of a common application programming interface framework function identifier, a common application programming interface framework function address, a generic public subscription identifier, and a user equipment identifier (TS 33.535: 6.1, fig. 6.1-1, “In the response, the UDM may also indicate to the AUSF whether the AKMA Anchor key needs to be generated for the UE. If the AKMA indication is included, the UDM shall also include the RID of the UE”).
As per claim 3, TS 33.535 in view of TS 33.122, TS 29.222 and Rajadurai teaches the independent claim 1. TS 33.535 teaches wherein the security information comprises one or more of a user equipment identifier and a key (TS 33.535: 6.1, fig. 6.1-1, “If the AUSF receives the AKMA indication from the UDM, the AUSF shall store the KAUSF and generate the AKMA Anchor Key (KAKMA) and the A-KID from KAUSF after the primary authentication procedure is successfully completed”).
TS 33.535 does not explicitly teaches the derived information as common application programming interface framework.
However, in the related art, TS 33.122 teaches common application programming interface framework (TS 33.122: 6.5.2.1, “The AEF shall request for security information from the CAPIF Core Function to perform authentication and secure interface establishment with the API invoker, if the AEF does not have a valid key. The CAPIF Core Function provides the security information related to the chosen security method (TLS-PSK: AEFPSK) to the AEF over CAPIF-3 reference point. The CAPIF core function shall provide the remaining validity timer value for the key AEFPSK.”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to adapt the UE specific authentication derived security material of TS 33.535 for use as CAPIF security information, because TS 33.122 and TS 29.222 already teaches that CAPIF relies on CAPIF core provided security information to authenticate entities and establish secure CAPIF interfaces. Using the existing post authentication key and identifier material in CAPIF would leverage established 5G authentication results, improves security continuity and avoids unnecessary duplicate key generation procedures.
As per claim 6, TS 33.535 in view of TS 33.122 , TS 29.222, and Rajadurai teaches the independent claim 1. TS 33.535 wherein the at least one processor is further configured to cause the apparatus to transmit, to a user equipment via an intermediate access and mobility management function, a common application programming interface framework registration related information that includes one or more of: a common application programming interface framework function identifier, a common application programming interface framework function address, a generic public subscription identifier, and a common application programming interface framework-user equipment identifier (TS 33.535: 6.1, see fig. 6.1-1 AMF, “The AAnF sends the response to the AUSF using the Naanf_AKMA_AnchorKey_Register Response service operation. A-KID identifies the KAKMA key of the UE. A-KID shall be in NAI format as specified in clause 2.2 of IETF RFC 7542 [6], i.e. username@realm. The username part shall include the RID and the A-TID (AKMA Temporary UE Identifier), and the realm part shall include Home Network Identifier. The A-TID shall be derived from KAUSF as specified in Annex A.3. The AUSF shall use the RID received from the UDM as described in step 2 to derive A-KID”).
Claims 7-10 are rejected under 35 U.S.C. 103 as being unpatentable over (“5G; Authentication and Key Management for Applications (AKMA) based on 3GPP credentials in the 5G System (5GS) (3GPP TS 33.535”; Hereinafter “TS 33.535”) in view of Ito et al. (U.S Pub. No. 20210144550 A1; Hereinafter “Ito”).
As per claim 7, TS 33.535 teaches an apparatus for wireless communication, comprising: receive, from a user equipment, a request to initiate resource owner registration for the user equipment, the request including an identifier of the user equipment (TS 33.535: 6.2.1, fig. 6.2-1, “When the UE initiates communication with the AKMA AF, it shall include the derived A-KID (see clause 6.1) in the Application Session Establishment Request message” 6.2.2, “The A-KID functions as a temporary user identifier.”);
identify or retrieve, in response to the request, a key associated with the user equipment identifier (TS 33.535: 6.2.1, fig. 6.2-1, “If the AF does not have an active context associated with the A-KID, then the AF selects the AAnF as defined in clause 6.7, and sends a Naanf_AKMA_ApplicationKey_Get request to AAnF with the A-KID to request the KAF for the UE. The AF also includes its identity (AF_ID) in the request.”, 6.3.1, “. In the case of architecture with CAPIF support, the AF obtains the service API information from the CAPIF core function via the Availability of service APIs event notification or Service Discover Response as specified in TS 23.222 [5]”);
establish, using a shared key based on the key, a secure session with the user equipment (TS 33.535: 6.2.1, fig. 6.2-1, “AF_ID consists of the FQDN of the AF and the Ua* security protocol identifier. The latter parameter identifies the security protocol that the AF will use with the UE.”, B.1.3.2, “the UE shall derive the TLS premaster secret from KAF and shall send a ClientKeyExchange message including a PSK identity consisting of "3GPP-AKMA" and the A-KID…At step 4, if the AF receives the "3GPP-AKMA" prefix and the A-KID in the ClientKeyExchange messages it fetches the AF specific shared secret (KAF) from the AAnF using the A-KID. The AF shall derive the TLS premaster secret from the AF specific key (KAF).”, “The UE and NAF shall derive the TLS external PSK from KAF”);
TS 33.535 does not explicitly teach at least one memory ; and at least one processor coupled to the transceiver, the processor and the transceiver configured with the at least one memory and configured to cause the apparatus to; receive, from the user equipment via the secure session, a resource owner registration request including a common application programming interface framework-user equipment identifier; verify, in response to the resource owner registration request, whether the common application programming interface framework-user equipment identifier is same as a locally stored common application programming interface framework-user equipment identifier for the user equipment; and return, to the user equipment via the secure session, a resource owner registration response including a resource owner identifier if the received common application programming interface framework-user equipment identifier is the same as the locally stored common application programming interface framework- user equipment identifier for the user equipment or a failure indication if the common application programming interface framework-user equipment identifier is not the same as the locally stored common application programming interface framework-user equipment identifier for the user equipment.
However, in the related art, Ito teaches at least one memory ; and at least one processor coupled to the transceiver, the processor and the transceiver configured with the at least one memory and configured to cause the apparatus to (Ito: para [292], “Each controller may comprise any suitable form of processing circuitry including (but not limited to), for example: one or more hardware implemented computer processors; microprocessors; central processing units (CPUs); arithmetic logic units (ALUs); input/output (IO) circuits; internal memories/aches (program and/or data); processing registers; communication buses (e.g. control, data and/or address buses); direct memory access (DMA) functions; hardware or software implemented counters, pointers and/or timers; and/or the like.”):
receive, from the user equipment via the secure session, a resource owner registration request including a common application programming interface framework-user equipment identifier (Ito: fig. 13, para [217-223], “The subscribing entity sends an event subscription request to the CAPIF core function 21 along with the subscribing entity identifier, authorization token, event type, service API ID, Service API name in order to receive notification of events. [0219] a. Variant: The subscribing entity can be API invoker 20, API exposing function 22, API publishing function 23 or API management function 24. [0220] b. Variant: If the subscribing entity is an API invoker 20, the subscribing entity ID is the CAPIF specific API invoker ID”);
verify, in response to the resource owner registration request, whether the common application programming interface framework-user equipment identifier is same as a locally stored common application programming interface framework-user equipment identifier for the user equipment (Ito: fig. 13, para [217-223], “Upon receiving the event subscription request from the subscribing entity, the CAPIF core function 21 checks for the relevant authorization for the event subscription. The CCF 21 validates the authorization token and if the validation/verification is successful, the CC assigns a subscription identifier (ID) and generates a subscription token”); and
return, to the user equipment via the secure session, a resource owner registration response including a resource owner identifier if the received common application programming interface framework-user equipment identifier is the same as the locally stored common application programming interface framework- user equipment identifier for the user equipment or a failure indication if the common application programming interface framework-user equipment identifier is not the same as the locally stored common application programming interface framework-user equipment identifier for the user equipment (Ito: fig. 13, para [217-223], “If the authorization is successful, the CAPIF core function 21 stores the subscription information such as the subscription ID and the subscription token. 4. The CAPIF core function 21 sends an event subscription response indicating successful operation along with the subscription ID and the subscription token”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to combine TS 33.535 with Ito to reuse known 5G authentication derived application key material in CAPIF security procedures, to provide a secure CAPIF authentication session establishment tied to an already authenticated UE, while reducing redundant credential generation and improving security continuity across 5G and CAPIF operations.
As per claim 8, TS 33.535 in view of Ito teaches the independent claim 7. TS 33.535 teaches wherein the shared key is the common application programming interface framework key (TS 33.535: 6.2.1, fig. 6.2-1, “AF_ID consists of the FQDN of the AF and the Ua* security protocol identifier. The latter parameter identifies the security protocol that the AF will use with the UE.”, B.1.3.2, “the UE shall derive the TLS premaster secret from KAF and shall send a ClientKeyExchange message including a PSK identity consisting of "3GPP-AKMA" and the A-KID…At step 4, if the AF receives the "3GPP-AKMA" prefix and the A-KID in the ClientKeyExchange messages it fetches the AF specific shared secret (KAF) from the AAnF using the A-KID. The AF shall derive the TLS premaster secret from the AF specific key (KAF).”, “The UE and NAF shall derive the TLS external PSK from KAF” 6.3.1, “. In the case of architecture with CAPIF support, the AF obtains the service API information from the CAPIF core function via the Availability of service APIs event notification or Service Discover Response as specified in TS 23.222 [5]”).
As per claim 9, TS 33.535 in view of Ito teaches the independent claim 7. TS 33.535 teaches wherein the at least one processor is further configured to cause the apparatus to derive the shared key from the common application programming interface framework key using as input parameters one or more of: the user equipment identifier, the common application programming interface framework-user equipment identifier, a common application programming interface framework registration key word, a common application programming interface framework function identifier, a random number, and a nonce included in the request to initiate resource owner registration (TS 33.535: 6.2.1, fig. 6.2-1, “The AAnF derives the AKMA Application Key (KAF) from KAKMA if it does not already have KAF. The key derivation of KAF shall be performed as specified in Annex A.4.” 6.3.1, “. When the AF is about to request AKMA Application Key for the UE from the AAnF, e.g. when UE initiates application session establishment request as in clause 6.2.1, the AF discovers the HPLMN of the UE based on the A-KID and sends the request towards the AAnF via NEF service API. The request shall include the A-KID and the AF_ID and optionally UE Id not needed indication… In the case of architecture with CAPIF support, the AF obtains the service API information from the CAPIF core function via the Availability of service APIs event notification or Service Discover Response as specified in TS 23.222 [5]”);
As per claim 10, TS 33.535 in view of Ito teaches the independent claim 7. Ito teaches wherein the resource owner registration response includes a failure indication if there is no common application programming interface framework-user equipment identifier available for the user equipment (Ito: fig. 13, para [217-223], “4. The CAPIF core function 21 sends an event unsubscription response indicating successful or failure operation accordingly.”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to combine TS 33.535 with Ito to reuse known 5G authentication derived application key material in CAPIF security procedures, to provide a secure CAPIF authentication session establishment tied to an already authenticated UE, while reducing redundant credential generation and improving security continuity across 5G and CAPIF operations.
Claims 13-24 are rejected under 35 U.S.C. 103 as being unpatentable over (“LTE; 5G; Security aspects of Common API Framework (CAPIF) for 3GPP northbound APIs (3GPP TS 33.122 version 16.4.0 Release 16)”; Hereinafter “TS 33.122”) from IDS dated 6/20/2025 in view of Ito et al. (U.S Pub. No. 20210144550 A1; Hereinafter “Ito”) and Suzuki et al. (W.O. No. 2023/084606 A1; Hereinafter “Suzuki”).
As per claims 13 and 24, TS 33.122 teaches an apparatus for wireless communication, comprising:
receive, from an application programming interface invoker, a first request message (TS 33.122: 6.5.2.3, “The API invoker shall send Authentication Initiation Request to the AEF, including API invoker ID.”);
fetch, in response to the first request message, resource owner data and a resource owner key from a common application programming interface framework function (TS 33.122: 6.5.2.3, “The AEF shall request for security information from the CAPIF Core Function to perform authentication and secure interface establishment with the API invoker. The CAPIF Core Function provides the security information related to the chosen security method (TLS-PKI) to the AEF over CAPIF-3 reference point. CAPIF core function may return API invoker's root CA certificate for the AEF to validate the API invoker's certificate.”);
establish, using the application programming interface exposing function key, a secure connection (TS 33.122: 6.5.2.3, “As per OAuth 2.0 [4], the CAPIF core function shall perform the functionalities of the Authorization and token protocol endpoints, the API invoker shall perform the functions of the resource owner, client and redirection endpoints functionalities, while the API exposing function shall perform the resource server functions….. After fetching the relevant security information for the authentication, the AEF shall send Authentication Initiation Response message to API invoker to initiate the TLS session establishment procedure”);
TS 33.122, does not explicitly teach at least one memory ; and at least one processor coupled to the transceiver, the processor and the transceiver configured with the at least one memory and configured to cause the apparatus to; derive an application programming interface exposing function key based on the resource owner key; transmit, to the resource owner, a second request message that includes one or more of: an application programming interface exposing function identifier, a target user equipment identifier, an application/function identifier, and service data set type identifiers; receive, from the resource owner via the secure connection, a second response message that includes one or more of: a user equipment identifier and a user consent data set; store the user consent data set along with user equipment identifier.
However, in the related art, Ito teaches at least one memory ; and at least one processor coupled to the transceiver, the processor and the transceiver configured with the at least one memory and configured to cause the apparatus to (Ito: para [292], “Each controller may comprise any suitable form of processing circuitry including (but not limited to), for example: one or more hardware implemented computer processors; microprocessors; central processing units (CPUs); arithmetic logic units (ALUs); input/output (IO) circuits; internal memories/aches (program and/or data); processing registers; communication buses (e.g. control, data and/or address buses); direct memory access (DMA) functions; hardware or software implemented counters, pointers and/or timers; and/or the like.”):
the AEF derive an application programming interface exposing function key based on the resource owner key (Ito: para[194], “The AEF 22 obtains invocation token or invocation token* from CCF 21 along with other parameters listed in step 2 to perform authentication. [0196] b. Variant: The invocation token* is derived at API invoker 20 side and either at the CCF 21 or AEF 22 side.”, para[200-203], “Variant: Invocation token* or invocation key* or invocation secret*can be derived using any Service API related information, Invocation token/access token received from CCF 21, CAPIF API ID, CAPIF ID, Invocation count specific to the service type/ID/name. Combination of any one or more of the listed parameters is used in the Invocation Token* or invocation key* or invocation secret* derivation.”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to combine TS 33.122 with Ito to reuse known 5G authentication derived application key material in CAPIF security procedures, to provide a secure CAPIF authentication session establishment tied to an already authenticated UE, while reducing redundant credential generation and improving security continuity across 5G and CAPIF operations.
TS 33.122 in view of Ito does not explicitly teach transmit, to the resource owner, a second request message that includes one or more of: an application programming interface exposing function identifier, a target user equipment identifier, an application/function identifier, and service data set type identifiers; receive, from the resource owner via the secure connection, a second response message that includes one or more of: a user equipment identifier and a user consent data set; store the user consent data set along with user equipment identifier.
However, in the related art, Suzuki teaches transmit, to the resource owner, a second request message that includes one or more of: an application programming interface exposing function identifier, a target user equipment identifier, an application/function identifier, and service data set type identifiers (Suzuki: fig. 4, s1-s2, “The API caller 30A, which has received the service API call request, accesses the resource owner 40 in S2, for example, based on the information (eg, API name, resource owner ID) included in the service API call request”);
receive, from the resource owner via the secure connection, a second response message that includes one or more of: a user equipment identifier and a user consent data set (Suzuki: fig 4, s1-s3, “and From the owner 40, API authorization information related to the service API call request (information indicating whether the API can be called) is acquired,”, fig. 6, “API authorization information. Each entry in this table includes a resource owner ID, target API, and callability. For example, it is indicated that the SessionWithQoS API, which is the target API of resource owner ID=123456789, can be used.”); and
store the user consent data set along with user equipment identifier (Suzuki: fig. 4, s3, “and the API authorization information is retained in S3.”, fig. 6, “API authorization information. Each entry in this table includes a resource owner ID, target API, and callability. For example, it is indicated that the SessionWithQoS API, which is the target API of resource owner ID=123456789, can be used. This information is obtained, for example, by the procedure shown in FIG. 4, or after being updated by the procedure shown in FIG.”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to combine TS 33.122 with Suzuki so that the resource owner consent and API invocation procedure is carried out sing the know CAPIF authentication and TLS protection procedure taught by TS 33.122, thereby improving security, integrity, and trustworthiness of consent based API exposure.
As per claim 14, TS 33.122 in view of Ito and Suzuki teaches the independent claim 13. Suzuki teaches wherein the second request message further includes a resource owner identifier (Suzuki: fig. 4, s1-s2, “The API caller 30A, which has received the service API call request, accesses the resource owner 40 in S2, for example, based on the information (eg, API name, resource owner ID) included in the service API call request”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to combine TS 33.122 with Suzuki so that the resource owner consent and API invocation procedure is carried out sing the know CAPIF authentication and TLS protection procedure taught by TS 33.122, thereby improving security, integrity, and trustworthiness of consent based API exposure.
As per claim 15, TS 33.122 in view of Ito and Suzuki teaches the independent claim 13. Suzuki teaches wherein the user consent data set includes one or more of: an application/function identifier, one or more service data types, and a consent status (Suzuki: fig 4, s1-s3, “and From the owner 40, API authorization information related to the service API call request (information indicating whether the API can be called) is acquired,”, fig. 6, “API authorization information. Each entry in this table includes a resource owner ID, target API, and callability. For example, it is indicated that the SessionWithQoS API, which is the target API of resource owner ID=123456789, can be used.”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to combine TS 33.122 with Suzuki so that the resource owner consent and API invocation procedure is carried out sing the know CAPIF authentication and TLS protection procedure taught by TS 33.122, thereby improving security, integrity, and trustworthiness of consent based API exposure.
As per claim 16, TS 33.122 in view of Ito and Suzuki teaches the dependent claim 15. Suzuki teaches wherein the consent status is indicated as one of: accept or allowed, denied or not allowed, revoked/updated (Suzuki: fig 4, s1-s3, “If the above API authorization information is information that permits API usage, API execution processing is performed. If the above API authorization information is information that denies the use of the API, for example, information indicating the denial of the use of the API is returned to the API caller 30A, and the API execution processing is not performed. <Update API authorization information> Here, for example, if the resource owner 40 wants to disable the use of an API that has been available (or wants to enable the use of an unavailable API), in S1 of FIG. , to the AEF 30C.”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to combine TS 33.122 with Suzuki so that the resource owner consent and API invocation procedure is carried out sing the know CAPIF authentication and TLS protection procedure taught by TS 33.122, thereby improving security, integrity, and trustworthiness of consent based API exposure.
As per claim 17, TS 33.122 in view of Ito and Suzuki teaches the dependent claim 15. Suzuki teaches wherein the at least one processor is further configured to cause the apparatus to transmit, to the application programming interface invoker, a third response message based on the consent status (Suzuki: fig 4, s1-s3, “If the above API authorization information is information that denies the use of the API, for example, information indicating the denial of the use of the API is returned to the API caller 30A, and the API execution processing is not performed.”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to combine TS 33.122 with Suzuki so that the resource owner consent and API invocation procedure is carried out sing the know CAPIF authentication and TLS protection procedure taught by TS 33.122, thereby improving security, integrity, and trustworthiness of consent based API exposure.
As per claim 18, TS 33.122 in view of Ito and Suzuki teaches the independent claim 13. Suzuki teaches wherein the at least one processor is further configured to cause the apparatus to derive the application programming interface exposing function key from the resource owner key and using as input parameters one or more of: a resource owner identifier, a user equipment identifier, a freshness parameter, application/function identifiers, a common application programming interface framework function identifier or application programming interface exposing function identifier, and a length of each input parameter (Suzuki: fig 4, s1-s3, “If the above API authorization information is information that denies the use of the API, for example, information indicating the denial of the use of the API is returned to the API caller 30A, and the API execution processing is not performed.”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to combine TS 33.122 with Suzuki so that the resource owner consent and API invocation procedure is carried out sing the know CAPIF authentication and TLS protection procedure taught by TS 33.122, thereby improving security, integrity, and trustworthiness of consent based API exposure.
As per claim 19, TS 33.122 in view of Ito and Suzuki teaches the dependent claim 18. Ito teaches wherein the freshness parameter comprises one or more of a counter, a random number, and a nonce (Ito: para[194], “The AEF 22 obtains invocation token or invocation token* from CCF 21 along with other parameters listed in step 2 to perform authentication. [0196] b. Variant: The invocation token* is derived at API invoker 20 side and either at the CCF 21 or AEF 22 side.”, para[200-203], “Variant: Invocation token* or invocation key* or invocation secret*can be derived using any Service API related information, Invocation token/access token received from CCF 21, CAPIF API ID, CAPIF ID, Invocation count specific to the service type/ID/name. Combination of any one or more of the listed parameters is used in the Invocation Token* or invocation key* or invocation secret* derivation.”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to combine TS 33.122 with Ito to reuse known 5G authentication derived application key material in CAPIF security procedures, to provide a secure CAPIF authentication session establishment tied to an already authenticated UE, while reducing redundant credential generation and improving security continuity across 5G and CAPIF operations.
As per claim 20, TS 33.122 in view of Ito and Suzuki teaches the independent claim 13. Ito teaches wherein the application programming interface exposing function key comprises a common application programming interface framework key (Ito: para[194], “The AEF 22 obtains invocation token or invocation token* from CCF 21 along with other parameters listed in step 2 to perform authentication. [0196] b. Variant: The invocation token* is derived at API invoker 20 side and either at the CCF 21 or AEF 22 side.”, para[200-203], “Variant: Invocation token* or invocation key* or invocation secret*can be derived using any Service API related information, Invocation token/access token received from CCF 21, CAPIF API ID, CAPIF ID, Invocation count specific to the service type/ID/name. Combination of any one or more of the listed parameters is used in the Invocation Token* or invocation key* or invocation secret* derivation.”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to combine TS 33.122 with Ito to reuse known 5G authentication derived application key material in CAPIF security procedures, to provide a secure CAPIF authentication session establishment tied to an already authenticated UE, while reducing redundant credential generation and improving security continuity across 5G and CAPIF operations.
As per claim 21, TS 33.122 in view of Ito and Suzuki teaches the independent claim 13. Suzuki teaches wherein the first request message comprises an application programming interface invocation request and the user consent data set indicates that the application programming interface invocation is denied, and the at least one processor is further configured to cause the apparatus to: transmit, to the application programming interface invoker, a response message indicating that the application programming interface invocation request is denied (Suzuki: fig 4, s1-s3, “In S1, the API caller 30A calls the API by sending a service API invocation request to the AEF 30C…If the above API authorization information is information that permits API usage, API execution processing is performed. If the above API authorization information is information that denies the use of the API, for example, information indicating the denial of the use of the API is returned to the API caller 30A, and the API execution processing is not performed. <Update API authorization information> Here, for example, if the resource owner 40 wants to disable the use of an API that has been available (or wants to enable the use of an unavailable API), in S1 of FIG. , to the AEF 30C.”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to combine TS 33.122 with Suzuki so that the resource owner consent and API invocation procedure is carried out sing the know CAPIF authentication and TLS protection procedure taught by TS 33.122, thereby improving security, integrity, and trustworthiness of consent based API exposure.
As per claim 22, TS 33.122 in view of Ito and Suzuki teaches the independent claim 13. Suzuki teaches wherein the at least one processor is further configured to cause the apparatus to store the user consent data at the apparatus (Suzuki, “the AEF 30C updates the authorization information table as shown in FIG. 8, for example”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to combine TS 33.122 with Suzuki so that the resource owner consent and API invocation procedure is carried out sing the know CAPIF authentication and TLS protection procedure taught by TS 33.122, thereby improving security, integrity, and trustworthiness of consent based API exposure.
As per claim 23, TS 33.122 in view of Ito and Suzuki teaches the independent claim 13. Suzuki teaches wherein the at least one processor is further configured to cause the apparatus to store the user consent data at the common application programming interface framework function (Suzuki, “the AEF 30C updates the authorization information table as shown in FIG. 8, for example”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to combine TS 33.122 with Suzuki so that the resource owner consent and API invocation procedure is carried out sing the know CAPIF authentication and TLS protection procedure taught by TS 33.122, thereby improving security, integrity, and trustworthiness of consent based API exposure.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LYDIA L NOEL whose telephone number is (571)272-1628. The examiner can normally be reached Monday - Friday 9:00 - 5: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 on (571)-270-5143. 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.
/L.L.N./Examiner, Art Unit 2437
/ALEXANDER LAGOR/Supervisory Patent Examiner, Art Unit 2437
Prosecution Insights