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 Arguments
Applicant's arguments filed on 07/13/2026 have been fully considered but they are not persuasive.
Applicant argued in the remark that Wang does not mention a CAPIF function at all, let alone to disclose that the API invoker sends first request information to a CAPIF function, including authentication information of the API invoker, and the authentication information includes the AKMA key identifier corresponding to the AKMA anchor key.
Moreover, Wang is totally silent on the fact that the API invoker determines, based on the AKMA anchor key, a first KAF for authenticating the API invoker.
Examiner respectfully disagrees.
Rajavelsamy discloses 0008 authenticating API invokers using a common application program interface framework (CAPIF).
Wang discloses [0187] FIG. 16 is flowchart illustrating an example method in an application function (AF), i.e. API invoker, network node, according to certain embodiments. The method begins at step 1612, where the AF receives an application session setup request from a wireless device. The application session setup request includes an anchor key identifier (K.sub.AKMA ID) associated with the wireless device. To obtain application function key (K.sub.AF) associated with the K.sub.AKMA ID, the AF needs to contact an AAnF. Wherein the application function invokes the session request or AKMA Key request using the KsubAkma ID,i.e. AKMA key identifier, to obtain the application function key, i.e. AKMA anchor key. [0192] At step 1716, the AAnF obtains the K.sub.AKMA associated with the K.sub.AKMA ID. The K.sub.AKMA may be stored locally, or the AAnF may obtain the K.sub.AKMA from the AUSF that performed the primary authentication for the wireless device (e.g., when the key material includes the K.sub.AKMA ID and the AUSF identifier).
Wang discloses, determining, based on an authentication server function key (KAUSF), an authentication and key management for applications (AKMA) anchor key and an AKMA key identifier corresponding to the AKMA anchor key as follows:
Par 0020 discloses an authentication server function (AUSF) and an authentication and key management for applications (AKMA) anchor function (AAnF) for the handling of key material related to AKMA. Wherein the AUSF can be seen as the KAUSF because it is determining anchor key by generating the K.sub.AKMA, i.e. the anchor key, and K.subAKMA ID, i.e. the anchor key identifier.
The authentication information comprises the AKMA key identifier corresponding to the AKMA anchor key, and the AKMA key identifier is used to determine the AKMA anchor key( Wang’s Par 0031 discloses [0031] In particular embodiments, the key material associated with the wireless device further comprises an AUSF identifier of the network node that performed the primary authentication for the wireless device. Obtaining the K.sub.AKMA associated with the K.sub.AKMA ID may comprise obtaining the K.sub.AKMA from the AUSF that performed the primary authentication for the wireless device. wherein the network node is performing the primary authentication by obtaining the K.sub. AKAM key, i.e. the AKMA anchor key. wherein the K.sub. AKMA ID is associated with the AkMA anchor key).
determining, based on the AKMA anchor key, a first application function key (KAF), wherein the first KAF is used for authenticating the API invoker ( Wang discloses par 0026, an application function (AF) comprises receiving an application session setup request from a wireless device. The application session setup request includes an anchor key identifier (K.sub.AKMA ID) associated with the wireless device. The method further comprises transmitting a request to at least one AAnF instance for an application function key (K.sub.AF) associated with the K.sub.AKMA ID and receiving the K.sub.AF from the AAnF. Par 0191 discloses [0191] At step 1714, the AAnF receives, from an AF, a request for an application function key (K.sub.AF) associated with a K.sub.AKMA ID. Par 0192 [0192] At step 1716, the AAnF obtains the K.sub.AKMA associated with the K.sub.AKMA ID. The K.sub.AKMA may be stored locally, or the AAnF may obtain the K.sub.AKMA of the application function key from the AUSF that performed the primary authentication for the wireless device (e.g., when the key material includes the K.sub.AKMA ID and the AUSF identifier). Wherein the AUSF authenticates the AF, i.e. KAF, key form the wireless device).
Claim Rejections - 35 USC § 103
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.
Claim(s) 1-2,6,8-9,12,14-16, 19-20, 24-25,27,30,32,34-35, 43, and 45 are rejected under 35 U.S.C. 103 as being unpatentable over Rajavelsamy et al EP 3972310 in view of Wang et al US 2023/0199486.
As per claim 1, Rajavelsamy discloses a method for authenticating an application program interface (API) invoker authentication method, performed by an API invoker, and the method comprising:
authenticating the API invoker(Rajavelsamy’ s Par 0042 discloses the API Invoker 102 discovers/identifies to contact the AEF 108 directly for the service API, then the API Invoker 102 initiates an authentication with the AEF 108 directly, The AEF 108 requests the API Invoker's 102 authorization rights from the CCF 106 over the CAPIF-3 reference point. 0044 enabling the C2eISby the AEF 108, for the at least one API invoker 102 based on the determined at least one security method comprises establishing a secure TLS connection between the AEF 108 and the at least one API invoker 102 over the CAPIF-2e interface using at least one of a certificate-based mutual authentication and a server side certificate-based authentication.
0039 The CAPIF-1/1-e between the API Invoker 102 and the CCF 106. Further, the system 100 authenticates the API Invoker 102 based on the identity and credentials of the API Invoker 102 or presenting a valid security token. There is a mutual authentication between the API Invoker and the CCF. Further, the system 100 provides authorization for the API Invoker prior to accessing one or more service API's. For the CAPIF-2/2e between the API Invoker 102 and the AEF 108, the system 100 authenticates the API Invoker 102 based on the identity and credentials of the API invoker 102 or presenting the valid security token (OAuth). Further, the system 100 provides authorization for the API invoker 102 prior to accessing the service API. Further, there is an authorization and verification for the API invoker upon accessing the service API. Further, the system 100 controls the service API access based on a PLMN operator configured policies. The CAPIF-1e and the CAPIF-2e are reference points, where the API invoker 102 is outside the PLMN trust domain.
According to FIG. 9, the CCF 106 shares an authentication response to the API Invoker 102 based on an authentication request from the API Invoker 102. Further, the API Invoker 102 gives a service API invocation request with the authentication information to the AEF-2 108. Further, the AEF-2 108 can be configured to receive the API Invoker 102 information for the authentication. Further, AEF-2 108 performs identity verification and authentication based on a token presented by the API invoker 102 and establishes the secure TLS connection between the API invoker 102 and the AEF 108. Further, based on the identity verification and authentication, the AEF-2 108 provides a service API invocation response. Par 0098 discloses shares an authentication response to the API Invoker 102 based on an authentication request from the API Invoker 102. Further, the API Invoker 102 gives a service API invocation request with the authentication information to the AEF-2 108. Further, the AEF-2 108 can be configured to receive the API Invoker 102 information for the authentication. Further, AEF-2 108 performs identity verification and authentication based on a token presented by the API invoker 102 and establishes the secure TLS connection between the API invoker 102 and the AEF 108. Further, based on the identity verification and authentication, the AEF-2 108 provides a service API invocation response);
sending first request information to a common application program interface framework (CAPIF) function( fig.7, application program interface framework (CAPIF) functional security mechanisms for authenticating and authorizing an API invoker, API Invoker 102 sends the security method request to the CAPIF core function), wherein the first request information comprises authentication information of the API invoker( Fig.7 the request includes ID, capability, AEF details, security method preference, as an authentication information of the API invoker 102 and fig.7, the security method selection for user the AI and AEF, based on the service APIs, the API interface details, time based scenarios and the security method response and Fig.8, request with authentication information TLS-PSK and obtain API invoker information for authentication and identity verification and authentication based on the based on pre-shared key(TLS-PSK), Establishment for TLS session and Fig.9, The CAPIF core function provides authentication response (token: AEF ID-2, Root certificate of the CA to verity AEF ID-2 certificate and Type of service the API invoker 102 subscribed, Interface details (such as IP address/port), Protocol between the AEF 108 and the API Invoker 102, when requested for access to a particular service (when multiple services are subscribed), based on time based scenarios (subscribed APIs), based on the need on how long the TLS sessions to be alive, capability of the API Invoker, capability of the AEF 108, based on the request from the API Invoker 102 (based on User input, time of usage, number of request known in prior), a particular method is selected by the CCF 106 (per AEF or per API Invoker) and indicated to the API Invoker 102. ).
Rajavelsamy does not disclose determining, based on an authentication server function key (KAUSF), an authentication and key management for applications (AKMA) anchor key and an AKMA key identifier corresponding to the AKMA anchor key; the authentication information comprises the AKMA key identifier corresponding to the AKMA anchor key, and the AKMA key identifier is used to determine the AKMA anchor key; and determining, based on the AKMA anchor key, a first application function key (KAF), wherein the first KAF is used for authenticating the API invoker.
However, Wang discloses, determining, based on an authentication server function key (KAUSF), an authentication and key management for applications (AKMA) anchor key and an AKMA key identifier corresponding to the AKMA anchor key as follows:
Par 0020 discloses an authentication server function (AUSF) and an authentication and key management for applications (AKMA) anchor function (AAnF) for the handling of key material related to AKMA. Wherein the AUSF can be seen as the KAUSF because it is determining anchor key by generating the K.sub.AKMA, i.e. the anchor key, and K.subAKMA ID, i.e. the anchor key identifier.
The authentication information comprises the AKMA key identifier corresponding to the AKMA anchor key, and the AKMA key identifier is used to determine the AKMA anchor key( Wang’s Par 0031 discloses [0031] In particular embodiments, the key material associated with the wireless device further comprises an AUSF identifier of the network node that performed the primary authentication for the wireless device. Obtaining the K.sub.AKMA associated with the K.sub.AKMA ID may comprise obtaining the K.sub.AKMA from the AUSF that performed the primary authentication for the wireless device. wherein the network node is performing the primary authentication by obtaining the K.sub. AKAM key, i.e. the AKMA anchor key. wherein the K.sub. AKMA ID is associated with the AkMA anchor key).
determining, based on the AKMA anchor key, a first application function key (KAF), wherein the first KAF is used for authenticating the API invoker ( Wang discloses par 0026, an application function (AF) comprises receiving an application session setup request from a wireless device. The application session setup request includes an anchor key identifier (K.sub.AKMA ID) associated with the wireless device. The method further comprises transmitting a request to at least one AAnF instance for an application function key (K.sub.AF) associated with the K.sub.AKMA ID and receiving the K.sub.AF from the AAnF. Par 0191 discloses [0191] At step 1714, the AAnF receives, from an AF, a request for an application function key (K.sub.AF) associated with a K.sub.AKMA ID. Par 0192 [0192] At step 1716, the AAnF obtains the K.sub.AKMA associated with the K.sub.AKMA ID. The K.sub.AKMA may be stored locally, or the AAnF may obtain the K.sub.AKMA of the application function key from the AUSF that performed the primary authentication for the wireless device (e.g., when the key material includes the K.sub.AKMA ID and the AUSF identifier). Wherein the AUSF authenticates the AF, i.e. KAF, key form the wireless device).
Rajavelsamy and Wang are both considered to be analogous to the claimed invention because they are in the same field of authentication systme.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Rajavelsamy to incorporate the teachings of Wang and provide the AF may determine all available AAnF instances and transmit the request to each instance until the K.sub.AF is received( par 0188). Doing so would provide an instance key, thereby increasing key function for the instance application.
As per claim 2. Rajavelsamy and Wang discloses the method according to claim 1, further comprising: obtaining enrolment information from an API provider domain or preconfigured information of the API invoker, wherein the enrolment information comprises at least one of: an address of the CAPIF function; a fully qualified domain name (FQDN) of the CAPIF function; or a root certificate authority (CA) certificate of the CAPIF function; establishing, based on the enrolment information, a transport layer security (TLS) connection with the CAPIF function; wherein the TLS connection sends the first request information to the CAPIF function (Rajavelsamy, 0007 the security aspects and respective security information flows of a common application program interface (API) framework (CAPIF) interfaces (CAPIF-1, CAPIF-le, CAPIF-2 and CAPIF-2e) are open. Therefore, there is a need for various security methods to support more than one authentication method and a secure interface establishment method/procedure, as the CAPIF will support vast services with different architectural and performance requirements for authentication of API Invokers).
As per claim 8. Rajavelsamy and Wang discloses The method according to any one of claims 1 , wherein, the authentication information comprises: a first certificate, wherein the first certificate is used for the CAPIF function to authenticate the identity of the API invoker; and the first certificate is a certificate generated by an authority for the API invoker or a certificate generated by a CAPIF core function for the API invoker(Rajavelsamy, fig.2-3, the embodiments herein establishes the dedicated secure connection/session for authenticating the API invoker 102. The dedicated secure connection between the API Invoker 102 and the AEF 108 can be established using two different methods such as the PSK based and the certificate based method. The established dedicated secure session can be used for all API invocations and responses. To establish the dedicated secure session, a PSK can be derived after the successful mutual authentication between the CCF 106 and the API invoker 102 over the CAPIF-1e interface. Further, the PSK can be used to establish the secure connection (for example, TLS or IPSec) between the API invoker 102 and AEF 108 over the CAPIF-2e interface. The CAPIF-1e security mechanism can be used to "bootstrap" a key for authenticating the secure TLS connection for the CAPIF-2e. In the absence of the PSK, certificate based mutual authentication between the API invoker 102 and AEF 108 can be used to establish the secure TLS session over the CAPIF-2e interface).
As per claim 9. Rajavelsamy and Wang discloses the method according to claim 1 , further comprising : receiving first response information sent by the CAPIF function after successful verification based on a token (Rajavelsamy, 0014-0015 enabling the C2eIS by the AEF, for the at least one API invoker based on the determined at least one security method includes establishing a secure Transport layer security (TLS) connection with the at least one API invoker over the CAPIF-2e interface using a pre-shared key (PSK) received from the CCF, if the determined at least one security method is the TLS-PSK, wherein the PSK is derived by at least one of the at least one API invoker and the CCF after establishing the secure TLS connection between the CCF and the at least one API invoker over the CAPIF-1e interface. Further, receiving authorization rights of the at least one API invoker from the CCF over the CAPIF-3 interface. Further, authorizing the at least one API invoker to access the at least one service API based on the received authorization rights of the at least one API invoker from the CCF.), wherein the first request information further comprises: the token of the API invoker, wherein the first response information comprises: API invoker configuration information, wherein the API invoker configuration information comprises: API exposing function (AEF) authentication and authorization information; an API invoker's certificate ( 0016 enabling the C2eIS by the AEF, the at least one API invoker based on the determined at least one security method comprises establishing a secure TLS connection with the at least one API invoker over the CAPIF-2e interface using a certificate-based mutual authentication, if the determined at least one security method is the OAuth (Open Authorization: token-based authentication and authorization). Further, receiving a service API access request from the at least one API invoker along with an access token, wherein the access token is generated by the CCF on receiving a OAuth based access token request from the at least one API invoker after establishing the secure TLS connection between the CCF and the at least one API invoker over the CAPIF-1e interface. Further, authorizing the at least one API invoker to access the at least one service API based on the received access token from the at least one API invoker. ), wherein the API invoker's certificate comprises at least one of: identification information of the API invoker and a public key of the API
PNG
media_image1.png
87
33
media_image1.png
Greyscale
invoker (0017enabling the C2eIS by the AEF, the at least one API invoker based on the determined at least one security method includes establishing a secure TLS connection with the at least one API invoker over the CAPIF-2e interface using a server certificate-based authentication, if the determined at least one security method is the OAuth 2.0. Further, receiving a service API access request from the at least one API invoker along with an access token, wherein the access token is generated by the CCF on receiving a OAuth 2.0 based access token request from the at least one API invoker after establishing the secure TLS connection between the CCF and the at least one API invoker over the CAPIF-1e interface. Further, authorizing the at least one API invoker to access the at least one service API based on the received access token from the at least one API invoker. ); and an onboard signing key of the API invoker, wherein the identification information of the API invoker comprises one of: identification information of the API invoker assigned by CAPIF function; a subscription permanent identifier (SUPI);a generic public subscription identifier (GPSI); an internet protocol multimedia subsystem (IMS) private identity (IMPI);a subscription concealed identifier (SUCI); and an application layer identification (ID) of UE (0018 authenticating application program interface (API) invokers using a common application program interface framework (CAPIF). The system includes a CAPIF core function (CCF) configured to establish a secure connection with at least one API invoker, on receiving a connection request from the at least one API invoker to access at least one service API on a CAPIF-2e interface, wherein establishing the secure connection between the CCF and the at least one API invoker is based on a mutual authentication between the CCF and the at least one API invoker over a CAPIF- 1e interface. Further, the CCF configured to determine at least one security method to be used by the at least one API invoker for a C2eIS of the at least one API invoker for accessing the at least one service API on a CAPIF-2e interface, wherein the at least one security method includes at least one of a Transport Layers Security -Pre-Shared Key (TLS-PSK), a TLS-Public Key Infrastructure (TLS-PKI), an Internet Key Exchange version 2 (IKEv2), an Internet Protocol Security (IPsec), an application layer protection, a native authorization mechanism and an OAuth 2.0. Further, the system includes an API exposing function (AEF) configured to enable the C2eIS for the at least one API invoker based on the determined at least one security method. In an embodiment, the at least one security method is determined based on at least one of a type of service the API invoker is subscribed, Interface details between the AEF and the API Invoker, access scenarios, length of a secure Transport layer security (TLS) sessions required, capability of the API Invoker, capability of the AEF, preferences of the API Invoker and a negotiation between the at least one API invoker and the CCF. ).
As per claim 12. Rajavelsamy and Wang discloses The method according to claim 1, wherein the API invoker comprises: a user equipment (UE)( Rajavelsamy, FIG. 1 illustrates a system 100 diagram illustrating CAPIF functional security mechanisms for authenticating, securing the interface and authorizing the API invoker 102, according to an embodiment as disclosed herein.
The system 100 includes one or more API invokers 102, 104, a CAPIF core function (CCF) 106, an application program interface exposing function (AEF) 108, API publishing function 110 and API management function 112. In an embodiment, the one or more API invokers 102, 104 can be at least one of, but not limited to a computer, laptop, mobile phone, personal digital assistants (PAD) and servers or any other device which tries to access the AEF 108 for one or more service API's. In embodiment, the one or more API invokers can be configured to invoke one or more service API's present on a network. The CCF 106 is a functional entity which can be configured to accumulate all common aspects of service API's. The CCF 106 can be configured for authenticating, monitoring, logging authorization, discovery which is common to all the service API's. The AEF 108 is the entity which can be configured for exposing the one or more service API's to the API invokers (i.e., for 102 and 104). The API invoker 102 can have a direct connection with the AEF 108 to invoke the service API's. However, the API invoker 102 may not have the direct connection with the API publishing function 110 and the API management function 112. The API publishing function 110 can be configured to publish library of service API's on the CCF 106. Further, the API management function 112 can be configured to manage functions related managing of loggings and auditing of logs stored in the CCF 106. ).
As per claim 25. Rajavelsamy and Wang discloses method for authenticating an application program interface (API) invoker, performed by a common application program interface framework (CAPIF) function, the method comprising: receiving first request information sent by an application program interface (API) invoker, wherein the first request information comprises authentication information of the API invoker, and the authentication information is used for authenticating an identity of the API invoker ( Rajavelsamy, fig.7, application program interface framework (CAPIF) functional security mechanisms for authenticating and authorizing an API invoker, API Invoker 102 sends the security method request to the CAPIF core function and Fig.7 the request includes ID, capability, AEF details, security method preference, as an authentication information of the API invoker 102 and fig.7, the security method selection for user the AI and AEF, based on the service APIs, the API interface details, time based scenarios and the security method response and Fig.8, request with authentication information TLS-PSK and obtain API invoker information for authentication and identity verification and authentication based on the based on pre-shared key(TLS-PSK), Establishment for TLS session and Fig.9, The CAPIF core function provides authentication response (token: AEF ID-2, Root certificate of the CA to verity AEF ID-2 certificate and Type of service the API invoker 102 subscribed, Interface details (such as IP address/port), Protocol between the AEF 108 and the API Invoker 102, when requested for access to a particular service (when multiple services are subscribed), based on time based scenarios (subscribed APIs), based on the need on how long the TLS sessions to be alive, capability of the API Invoker, capability of the AEF 108, based on the request from the API Invoker 102 (based on User input, time of usage, number of request known in prior), a particular method is selected by the CCF 106 (per AEF or per API Invoker) and indicated to the API Invoker 102)
Rajavelsamy does not explicitly disclose the authentication information comprises an authentication and key management for applications (AKMA) key identifier corresponding to an AKMA anchor key, and the AKMA key identifier is used to determine the AKMA anchor key sending second request information to an AKMA anchor function (AAnF) corresponding to the CAPIF function, wherein the second request information comprises the AKMA key identifier, and the AKMA key identifier is used for the AAnF to determine the AKMA anchor key, and the AKMA anchor key is used for the AAnF to determine a second application function key (KAF) of the CAPIF function; receiving second response information sent by the AAnF, wherein the second response information comprises the second KAF: and authenticating, based on the second KAF, the API invoker.
However, Wang discloses the authentication information comprises an authentication and key management for applications (AKMA) key identifier corresponding to an AKMA anchor key, and the AKMA key identifier is used to determine the AKMA anchor key sending second request information to an AKMA anchor function (AAnF) corresponding to the CAPIF function, wherein the second request information comprises the AKMA key identifier, and the AKMA key identifier is used for the AAnF to determine the AKMA anchor key, and the AKMA anchor key is used for the AAnF to determine a second application function key (KAF) of the CAPIF function (Par 0020 discloses an authentication server function (AUSF) and an authentication and key management for applications (AKMA) anchor function (AAnF) for the handling of key material related to AKMA. Wherein the AUSF can be seen as the KAUSF because it is determining anchor key by generating the K.sub.AKMA, i.e. the anchor key, and K.subAKMA ID, i.e. the anchor key identifier Wang’s Par 0031 discloses [0031] In particular embodiments, the key material associated with the wireless device further comprises an AUSF identifier of the network node that performed the primary authentication for the wireless device. Obtaining the K.sub.AKMA associated with the K.sub.AKMA ID may comprise obtaining the K.sub.AKMA from the AUSF that performed the primary authentication for the wireless device. wherein the network node is performing the primary authentication by obtaining the K.sub. AKAM key, i.e. the AKMA anchor key. wherein the K.sub. AKMA ID is associated with the AkMA anchor key ) ;
receiving second response information sent by the AAnF, wherein the second response information comprises the second KAF ( Wang discloses par 0026, an application function (AF) comprises receiving an application session setup request from a wireless device. The application session setup request includes an anchor key identifier (K.sub.AKMA ID) associated with the wireless device. The method further comprises transmitting a request to at least one AAnF instance for an application function key (K.sub.AF) associated with the K.sub.AKMA ID and receiving the K.sub.AF from the AAnF. Par 0191 discloses [0191] At step 1714, the AAnF receives, from an AF, a request for an application function key (K.sub.AF) associated with a K.sub.AKMA ID. Par 0192 [0192] At step 1716, the AAnF obtains the K.sub.AKMA associated with the K.sub.AKMA ID. The K.sub.AKMA may be stored locally, or the AAnF may obtain the K.sub.AKMA of the application function key from the AUSF that performed the primary authentication for the wireless device (e.g., when the key material includes the K.sub.AKMA ID and the AUSF identifier). Wherein the AUSF authenticates the AF, i.e. KAF, key form the wireless device ): and authenticating, based on the second KAF, the API invoker (Par 0192 [0192] At step 1716, the AAnF obtains the K.sub.AKMA associated with the K.sub.AKMA ID. The K.sub.AKMA may be stored locally, or the AAnF may obtain the K.sub.AKMA of the application function key from the AUSF that performed the primary authentication for the wireless device (e.g., when the key material includes the K.sub.AKMA ID and the AUSF identifier). Wherein the AUSF authenticates the AF, i.e. KAF, key form the wireless device ).
Rajavelsamy and Wang are both considered to be analogous to the claimed invention because they are in the same field of authentication systme.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Rajavelsamy to incorporate the teachings of Wang and provide the AF may determine all available AAnF instances and transmit the request to each instance until the K.sub.AF is received( par 0188). Doing so would provide an instance key, thereby increasing key function for the instance application.
As per claim 43. Rajavelsamy and Wang discloses A communication device, comprising : a memory, configured to store instructions executable by the processor; one or more processors communicatively coupled to the memory, ( Rajavelsamy , apr 0022 the phrase "processor adapted (or configured) to perform A, B, and C" may mean a dedicated processor (e.g., embedded processor) only for performing the corresponding operations or a generic-purpose processor (e.g., Central Processing Unit (CPU) or Application Processor (AP)) that can perform the corresponding operations by executing one or more software programs stored in a memory device. ) wherein the instructions when collectively executed by the one or more processors cause the communication device to act as the API invoker and perform the method according to claim 1 (see the rejection under clam 1 ).
As per claim 45, Rajavelsamy and Wang discloses the method according to the claim 1, further comprising: obtaining the Kausf from an API provider domain (par 0035-0037 the AEF 108 access points for the API Invoker 102 present outside of the PLMN trust domain. A security for the CAPIF-1, the CAPIF-2, the CAPIF-3, the CAPIF-4 and the CAPIF-5 interfaces supports Transport Layer security (TLS) as defined in the 3GPP TS 23.222 standard. ).
As per claim 6. Rajavelsamy and Wang discloses The method according to claim 5,Wang discloses wherein the determining, based on the AKMA anchor key, a first KAF comprises one of: determining the first KAF based on the AKMA anchor key and identification information of the CAPIF function, wherein the identification information of the CAPIF function comprises: at least one of a fully qualified domain name (FQDN) or a security protocol identifier, and the security protocol identifier is determined by negotiation between the API invoker and the CAPIF function (Wang [0180] FIG. 15 is flowchart illustrating an example method in a authentication server function (AUSF) network node, according to certain embodiments. The method begins at step 1512 where the AUSF generates an anchor key (K.sub.AKMA) and a K.sub.AKMA key identifier (K.sub.AKMA ID) associated with a wireless device. For example, after performing a primary authentication for the wireless device, the AUSF may then generate the K.sub.AKMA and K.sub.AKMA ID, as described with respect to step 0 of FIGS. 4 and 5.
[0181] At step 1514, the AUSF may determine all available AAnF instances. For example, the AUSF may discover all the AAnF instances available in the HPLMN by querying the NRF for an NF type of “AAnF.” In some embodiments, the AUSF may only determine a single available AAnF instance.
[0182] At step 1516, the AUSF transmits, to at least one AAnF instance, key material associated with the wireless device. For example, in some embodiments, the AUSF may transmit the key material to all available AAnF instances. In some embodiments, the AUSF may transmit the key material to one available AAnF instance. Further details are described with respect to FIG. 4. [0183] The key material may comprise the K.sub.AKMA and the K.sub.AKMA ID. In some embodiments, they key material further comprises any one or more of a subscription identifier (e.g., SUPI), a serving network name, authentication type, and a timestamp. In some embodiments the key material comprises the K.sub.AKMA ID and an AUSF identifier of the network node.
[0184] In the embodiments where the AUSF transmits the K.sub.AKMA ID and an AUSF identifier to the one or more AAnFs, the AAnF may use the AUSF identifier to contact the AUSF to retrieve the associated K.sub.AKMA. These embodiments may continue to step 1518. [0185] At step 1518, the AUSF receives a request for a K.sub.AKMA from an AAnF. The request comprises a K.sub.AKMA ID. The AUSF retrieves the K.sub.AKMA based on the K.sub.AKMA ID and transmits the K.sub.AKMA to the AAnF in step 1520.
[0186] Modifications, additions, or omissions may be made to method 1500 of FIG. 15. Additionally, one or more steps in the method of FIG. 15 may be performed in parallel or in any suitable order. [0187] FIG. 16 is flowchart illustrating an example method in an application function (AF) network node, according to certain embodiments. The method begins at step 1612, where the AF receives an application session setup request from a wireless device. The application session setup request includes an anchor key identifier (K.sub.AKMA ID) associated with the wireless device. To obtain application function key (K.sub.AF) associated with the K.sub.AKMA ID, the AF needs to contact an AAnF.).
As per claim 14. Rajavelsamy discloses a method for authentication of an application program interface (API) invoker authentication method, performed by an authentication and key management for applications (AKMA) anchor function (AAnF), the method and comprising:
receiving second request information sent by a common application program interface framework (CAPIF) function, wherein the second request information is determined by the CAPIF function based on first request information, and the second request information comprises an API invoker comprised in the first request information; and determining based on the AKMA key identifier, an AKMA anchor key corresponding to the AKMA key identifier ( fig.7, application program interface framework (CAPIF) functional security mechanisms for authenticating and authorizing an API invoker, API Invoker 102 sends the security method request to the CAPIF core function and Fig.7 the request includes ID, capability, AEF details, security method preference, as an authentication information of the API invoker 102 and fig.7, the security method selection for user the AI and AEF, based on the service APIs, the API interface details, time based scenarios and the security method response and Fig.8, request with authentication information TLS-PSK and obtain API invoker information for authentication and identity verification and authentication based on the based on pre-shared key(TLS-PSK), Establishment for TLS session and Fig.9, The CAPIF core function provides authentication response (token: AEF ID-2, Root certificate of the CA to verity AEF ID-2 certificate and Type of service the API invoker 102 subscribed, Interface details (such as IP address/port), Protocol between the AEF 108 and the API Invoker 102, when requested for access to a particular service (when multiple services are subscribed), based on time based scenarios (subscribed APIs), based on the need on how long the TLS sessions to be alive, capability of the API Invoker, capability of the AEF 108, based on the request from the API Invoker 102 (based on User input, time of usage, number of request known in prior), a particular method is selected by the CCF 106 (per AEF or per API Invoker) and indicated to the API Invoker 102. ).
Rajavelsamy fails to disclose determining a second application function key (KAF) based on the AKMA anchor key; and sending second response information to the CAPIF function, wherein the second response information comprises the second KAF, wherein the second KAF is used for the CAPIF function to authenticate the API invoker..
However, Wang discloses determining a second application function key (KAF) based on the AKMA anchor key; and sending second response information to the CAPIF function, wherein the second response information comprises the second KAF, wherein the second KAF is used for the CAPIF function to authenticate the API invoker.( [0065] FIG. 4 is a flow diagram depicting the AUSF push of AKMA key material to all AAnFs, according to certain embodiments. In the illustrated example, at step 0 the UE runs a primary authentication with the network. K.sub.AKMA and K.sub.AKMA key identifier (i.e., K.sub.AKMA ID) is generated and stored in the AUSF. The K.sub.AKMA ID generated may contain RID.
[0066] At step 0a the AUSF uses a new service operation Naanf_AKMA_Info to inform all the available AAnF instances within the HPLMN about the K.sub.AKMA and K.sub.AKMA ID generated by the AUSF as a result of the execution of a successful primary authentication procedure with the UE. In addition, the AUSF may push additional information about the authentication result, such as the UE subscription permanent identifier (SUPI), the AUSF ID, the serving network name, the authentication type, timestamp information, etc.
[0067] In general, the AUSF discovers all the AAnF instances available in the HPLMN (e.g., by querying the NRF for an NF type of “AAnF”) and pushes/broadcasts the aforementioned information to all the AAnF instances.
[0068] The AAnFs store the AKMA related information received from the AUSF. The AAnF potentially stores several records with any of the following information received from AUSF(s) after execution of subsequent successful primary authentication procedures for each UE: K.sub.AKMA, K.sub.AKMA ID, SUPI, AUSF ID, authentication result, serving network name, authentication type, timestamp, etc. The minimum information included in the records sent from the AUSF(s) to the AAnF(s) or the minimum information stored on the AAnF(s) (even if the AUSFs sends a very detailed report) is K.sub.AKMA and K.sub.AKMA ID. The rest of the information mentioned above is optional and may be used for optimization purposes).
Rajavelsamy and Wang are both considered to be analogous to the claimed invention because they are in the same field of authentication system.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Rajavelsamy to incorporate the teachings of Wang and provide the AF may determine all available AAnF instances and transmit the request to each instance until the K.sub.AF is received(par 0188). Doing so would provide an instance key, thereby increasing key function for the instance application.
As per claim 15. Rajavelsamy and Wang discloses The method according to claim 14, wherein determining the second KAF based on the AKMA anchor key comprise: determining a second application function key (KAF) based on the AKMA anchor key and identification information of the CAPIF function comprised in the second request information; ( Wang [0010] FIG. 3 illustrates a secured session setup between a UE and an application. As depicted, a pre-requisite to the establishment of a communication session, is primary authentication and establishment of a K.sub.AKMA ID.
[0011] Then, to initiate communication with the AKMA AF, the UE sends a session establishment request, which includes the derived K.sub.AKMA ID in the message. The AF then requests the application specific key from AAnF by providing at least the K.sub.AKMA ID and the AF Identifier in the session establishment request.
[0012] Further, the AAnF sends a request to the AUSF to obtain the K.sub.AKMA specific to the UE. The AAnF then derives the K.sub.AF from K.sub.AKMA and responds to the AKMA AF via a Key Response, which includes the K.sub.AF, an expiration time also known as KAF_exptime and a freshness parameter used by the AAnF to derive a fresh K.sub.AF.
[0013] The AF forwards the KAF_exptime and the freshness parameter to the UE in a response message (Application Session Establishment response in FIG. 3). Optionally, the AF integrity protects the response with a message authentication code (MAC) calculated using the K.sub.AF.).
As per claim 16. Rajavelsamy and Wang discloses The method according to claim 15, Wang discloses wherein the second response information further comprises: at least one of a valid time corresponding to the second KAF or identification information of the API invoker; wherein the identification information of the API invoker comprises one of: a subscription permanent identifier (SUPI);a generic public subscription identifier (GPSI);an internet protocol multimedia subsystem (IMS) private identity (IMPI);a subscription concealed identifier (SUCI); and an application layer identification (ID) of UE (Wang [0024] In particular embodiments, the key material associated with the wireless device comprises the K.sub.AKMA and the K.sub.AKMA ID. The key material associated with the wireless device may further comprise any one or more of a subscription identifier, a serving network name, authentication type, and a timestamp. The key material associated with the wireless device may comprise the K.sub.AKMA ID and an AUSF identifier of the network node.
[0025] In particular embodiments, the method further comprises receiving a request for a K.sub.AKMA from an AAnF, the request comprising a K.sub.AKMA ID, and transmitting the K.sub.AKMA associated with the K.sub.AKMA ID to the AAnF.
[0026] According to some embodiments, a method performed by a network node capable of operating as an application function (AF) comprises receiving an application session setup request from a wireless device. The application session setup request includes an anchor key identifier (K.sub.AKMA ID) associated with the wireless device. The method further comprises transmitting a request to at least one AAnF instance for an application function key (K.sub.AF) associated with the K.sub.AKMA ID and receiving the K.sub.AF from the AAnF and 0070] At step 1, the UE is triggered to perform an AKMA session request. It obtains the K.sub.AKMA, K.sub.AKMA ID and initiates application session setup procedure with the AF. In the message, the K.sub.AKMA ID is included as well as identifying information about the HPLMN. In this case, there is no need for the UE to include a UE identifier (e.g., subscription concealed identifier (SUCI)/SUPI or generic public subscription identifier (GPSI)) in the AKMA request to the AF. ).
As per claim 19. Rajavelsamy and Wang discloses The method according to claim 15, Wang discloses wherein the identification information of the CAPIF function comprises: at least one of a fully qualified domain name (FQDN) or a security protocol identifier, and the security protocol identifier is determined by negotiation between the API invoker and the CAPIF function; wherein the determining the second KAF based on the AKMA anchor key and the identification information of the CAPIF function comprises one of: determining the second KAF based on the AKMA anchor key and the FQDN; and determining the second KAF based on the AKMA anchor key, the FQDN and the security protocol identifier (Wang 0075 FIG. 4, the AUSF pushes the following information to all AAnF instances: K.sub.AKMA ID, AUSF ID, and a UE Identifier such as SUPI and/or a GPSI. When the AF receives the AKMA Session request, it sends the request to an arbitrary AAnF instance as in steps 1-3 of FIG. 4. Then, according to certain embodiments, the arbitrary AAnF instance uses the K.sub.AKMA ID to query the AUSF instance (i.e., the AUSF ID matching the K.sub.AKMA ID received from the UE) for the K.sub.AKMA using a new service operation e.g. Nausf_AKMA_KeyGet Request.
[0076] According to certain embodiments, the Nausf_AKMA_KeyGet Request may use as input a UE identifier such as a SUPI while the AAnF may receive a different type of UE identifier from the AF e.g. it may receive a GPSI. As a result, in some embodiments the AAnF may translate a GPSI to a SUPI e.g. by request to the UDM. This is a combination of the push and pull strategies. [0077] In a second group of embodiments, the AUSF pushes AKMA key material to an arbitrary AAnF and an AF may query all AAnFs. According to certain embodiments, the AUSF may select a single arbitrary AAnF instance and pushes at least the K.sub.AKMA/K.sub.AKMA ID to the AAnF in step 0a of FIG. 4.).
As per claim 20. Rajavelsamy and Wang discloses The method according to claim 14,Wang discloses further comprising: determining, based on the identification information of the CAPIF function, whether the AAnF is capable of providing a service to the CAPIF function; in response to determining that the AAnF is capable of providing the service to the CAPIF function, determining, based on the AKMA key identifier, the AKMA anchor key corresponding to the AKMA key identifier; in response to determining that the AAnF is not capable of providing the service to the CAPIF function, refusing to provide the second KAF to the CAPIF: or sending, based on the AKMA anchor key corresponding to the AKMA key identifier is not present in the AAnF, the second response information with error indication information to the CAPIF function( Wang, step 3 of FIG. 4 may be performed with all AAnF instances available in the HPLMN. The AAnF instance that holds the K.sub.AKMA ID which is matching the one sent by the UE may perform all the steps for the derivation of the K.sub.AF and respond to the AF. The other AAnF instances should discard/ignore the request. In some embodiments, the AF may send the request to each AAnF instance one at a time and stop when a match is found.
[0079] In a variant of the previous embodiment, the AUSF may select a single arbitrary AAnF instance and push the K.sub.AKMA ID and AUSF ID to it. For example, when the AF receives the AKMA Session request, the AF may send the request to all AAnF instances. The AAnF instance that holds the K.sub.AKMA ID which is matching the one sent by the UE may query the right AUSF instance (with AUSF ID corresponding to the K.sub.AKMA ID) for the K.sub.AKMA. Then the AAnF may perform all the steps for the derivation of the K.sub.AF and respond to the AF. The other AAnF instances should discard the request. In some embodiments, the AF may send the request to each AAnF instance one at a time and stop when a match is found.
[0080] A third group of embodiments include an AKMA binding network function.
[0081] FIG. 5 is a flow diagram depicting the AUSF push to AKMA binding NF, according to certain embodiments. In the illustrated example, step 0 is the same as described with respect to FIG. 4.
[0082] At step 0a, an AKMA Binding NF deployed in the network supports storing the binding relation between K.sub.AKMA ID and the AUSF instance that generated the K.sub.AKMA ID and the corresponding K.sub.AKMA. The binding NF may be a new NF type, or based on an existing NF, e.g., NRF, BSF or UDM.
[0083] The AUSF calls a new service operation Nbnf_AKMA_Info to inform the Binding NF about the K.sub.AKMA ID and AUSF ID. The AUSF may also send additional information, e.g., the UE SUPI, the authentication result, etc.
[0084] The binding NF then stores records with the following information: K.sub.AKMA ID, AUSF ID, SUPI, etc.
[0085] Steps 1-3 are the same as described with regard to FIG. 4.
[0086] At step 4, the AAnF uses the K.sub.AKMA ID to discover the corresponding AUSF instance via the service operation provided by the AKMA Binding NF, e.g. Nbnf_AKMA_discover. The AKMA Binding NF may respond with a AUSF instance and optionally a SUPI or other identifier.
[0087] At step 5, the AAnF fetches the K.sub.AKMA from the AUSF instance provided by the AKMA Binding NF.
[0088] The method ends at step 6 where the rest of AKMA procedures continue ).
As per claim 24. Rajavelsamy and Wang discloses The method according to claim 14, Rajavelsamy discloses wherein the CAPIF function comprises one of: a CAPIF core function (CCF); an API exposing function (AEF); and an authorization function (AF)( 0012 authenticating application program interface (API) invokers using a common application program interface framework (CAPIF). The method includes establishing by a CAPIF core function (CCF) a secure connection with at least one API invoker, on receiving a connection request from the at least one API invoker to access the at least one service API on a CAPIF-2e interface, wherein establishing the secure connection between the CCF and the at least one API invoker is based on a mutual authentication between the CCF and the at least one API invoker over a CAPIF-1e interface. Further, the method includes determining and indicating by the CCF at least one security method to be used by the at least one API invoker for the C2eIS (i.e., authentication, interface protection and authorization) of the at least one API invoker for accessing the at least one service API on a CAPIF-2e interface, wherein the at least one security method includes at least one of a Transport Layers Security -Pre-Shared Key (TLS-PSK), a TLS-Public Key Infrastructure (TLS-PKI), IKEv2, IPsec and an OAuth. The method further includes enabling the C2eIS by an API exposing function (AEF) the at least one API invoker based on the determined at least one security method. Referring now to the drawings, and more particularly to FIGS. 1 through 9).
As per claim 27. Rajavelsamy and Wang discloses the method according to claim 25, Wang discloses further comprising: determining, the AKMA key identifier corresponding to an AKMA anchor key comprised in the authentication information, the AAnF (0178] FIG. 14 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to FIGS. 9 and 10. For simplicity of the present disclosure, only drawing references to FIG. 14 will be included in this section.
[0179] In step 910 (which may be optional), in accordance with the teachings of the embodiments described throughout this disclosure, the base station receives user data from the UE. In step 920 (which may be optional), the base station initiates transmission of the received user data to the host computer. In step 930 (which may be optional), the host computer receives the user data carried in the transmission initiated by the base station.
[0180] FIG. 15 is flowchart illustrating an example method in a authentication server function (AUSF) network node, according to certain embodiments. The method begins at step 1512 where the AUSF generates an anchor key (K.sub.AKMA) and a K.sub.AKMA key identifier (K.sub.AKMA ID) associated with a wireless device. For example, after performing a primary authentication for the wireless device, the AUSF may then generate the K.sub.AKMA and K.sub.AKMA ID, as described with respect to step 0 of FIGS. 4 and 5.
[0181] At step 1514, the AUSF may determine all available AAnF instances. For example, the AUSF may discover all the AAnF instances available in the HPLMN by querying the NRF for an NF type of “AAnF.” In some embodiments, the AUSF may only determine a single available AAnF instance.
[0182] At step 1516, the AUSF transmits, to at least one AAnF instance, key material associated with the wireless device. For example, in some embodiments, the AUSF may transmit the key material to all available AAnF instances. In some embodiments, the AUSF may transmit the key material to one available AAnF instance. Further details are described with respect to FIG. 4.
[0183] The key material may comprise the K.sub.AKMA and the K.sub.AKMA ID. In some embodiments, they key material further comprises any one or more of a subscription identifier (e.g., SUPI), a serving network name, authentication type, and a timestamp. In some embodiments the key material comprises the K.sub.AKMA ID and an AUSF identifier of the network node.
[0184] In the embodiments where the AUSF transmits the K.sub.AKMA ID and an AUSF identifier to the one or more AAnFs, the AAnF may use the AUSF identifier to contact the AUSF to retrieve the associated K.sub.AKMA. These embodiments may continue to step 1518.
[0185] At step 1518, the AUSF receives a request for a K.sub.AKMA from an AAnF. The request comprises a K.sub.AKMA ID. The AUSF retrieves the K.sub.AKMA based on the K.sub.AKMA ID and transmits the K.sub.AKMA to the AAnF in step 1520.
[0186] Modifications, additions, or omissions may be made to method 1500 of FIG. 15. Additionally, one or more steps in the method of FIG. 15 may be performed in parallel or in any suitable order.
[0187] FIG. 16 is flowchart illustrating an example method in an application function (AF) network node, according to certain embodiments. The method begins at step 1612, where the AF receives an application session setup request from a wireless device. The application session setup request includes an anchor key identifier (K.sub.AKMA ID) associated with the wireless device. To obtain application function key (K.sub.AF) associated with the K.sub.AKMA ID, the AF needs to contact an AAnF.
[0188] At step 1614, the AF transmits a request to at least one AAnF instance for an K.sub.AF associated with the K.sub.AKMA ID. In the embodiments where the AUSF pushes the key material to all AAnF instances, then the AF may transmit the request to any AAnF. In the embodiments where the AUSF pushed the key material to one AAnF instance, the AF may determine all available AAnF instances and transmit the request to each instance (simultaneously or sequentially) until the K.sub.AF is received. The AF receives the K.sub.AF from the AAnF at step 1616. Additional details are described with respect to FIG. 4. [0189] Modifications, additions, or omissions may be made to method 1600 of FIG. 16. Additionally, one or more steps in the method of FIG. 16 may be performed in parallel or in any suitable order).
As per claim 30, Rajavelsamy and Wang discloses the method according to claim 27, Wang discloses wherein the second response information further comprises at least one of:
PNG
media_image2.png
87
6
media_image2.png
Greyscale
identification information of the API invoker; a valid time corresponding to the second KAF; wherein the identification information of the API invoker comprises one of: a subscription permanent identifier (SUPI); a generic public subscription identifier (GPSI); an internet protocol multimedia subsystem (IMS) private identity (IMPI); a subscription concealed identifier (SUCI); and an application layer identification (ID) of UE (Wang [0070] At step 1, the UE is triggered to perform an AKMA session request. It obtains the K.sub.AKMA, K.sub.AKMA ID and initiates application session setup procedure with the AF. In the message, the K.sub.AKMA ID is included as well as identifying information about the HPLMN. In this case, there is no need for the UE to include a UE identifier (e.g., subscription concealed identifier (SUCI)/SUPI or generic public subscription identifier (GPSI)) in the AKMA request to the AF.
[0071] At steps 2-3, the AF selects the HPLMN and selects any AAnF instance in the HPLMN. The AF sends the request towards the arbitrary selected AAnF with AF ID and K.sub.AKMA ID included in the message. The AF may need to forward the session request to the NEF in the core network. In this case it is the NEF that selects the AAnF.
[0072] At step 4, the selected AAnF uses the K.sub.AKMA ID to locate the corresponding K.sub.AKMA from the information received from the AUSF and stored in step 0a.
[0073] The method ends at step 5 where the AAnF generates AF specific key material based on the K.sub.AKMA found in step 4. The rest of AKMA procedures continue.
[0074] In some embodiments, the AUSF pushes an AUSF ID to all AAnFs. The UE may query an arbitrary AAnF and the AAnF may pull AKMA key material from the identified AUSF.
[0075] According to certain embodiments, in step 0a of FIG. 4, the AUSF pushes the following information to all AAnF instances: K.sub.AKMA ID, AUSF ID, and a UE Identifier such as SUPI and/or a GPSI. When the AF receives the AKMA Session request, it sends the request to an arbitrary AAnF instance as in steps 1-3 of FIG. 4. Then, according to certain embodiments, the arbitrary AAnF instance uses the K.sub.AKMA ID to query the AUSF instance (i.e., the AUSF ID matching the K.sub.AKMA ID received from the UE) for the K.sub.AKMA using a new service operation e.g. Nausf_AKMA_KeyGet Request.
[0076] According to certain embodiments, the Nausf_AKMA_KeyGet Request may use as input a UE identifier such as a SUPI while the AAnF may receive a different type of UE identifier from the AF e.g. it may receive a GPSI. As a result, in some embodiments the AAnF may translate a GPSI to a SUPI e.g. by request to the UDM. This is a combination of the push and pull strategies).
As per claim 32. Rajavelsamy and Wang discloses The method according to claim 27, the combination discloses wherein the second request information comprises: identification information of the CAPIF function, wherein the identification information of the CAPIF function comprises (Rajavelsamy 0040 authenticating the API invokers using the CAPIF, the method includes establishing by the CCF 106 a secure connection with at least one API invoker 102, on receiving a connection request from the at least one API invoker 102 to access the at least one service API on the CAPIF-2e interface. The secure connection is established between the CCF 106 and the at least one API invoker 102 is based on a mutual authentication between the CCF 104 and the at least one API invoker 102 over the CAPIF-1e interface. Further, the method includes determining by the CCF 106, at least one security method to be used by the at least one API invoker 102 for the C2eIS (i.e., authentication, interface protection and authorization) of the at least one API invoker 102 for accessing the at least one service API on the CAPIF-2e interface. The at least one security method includes at least one of a Transport Layers Security -Pre-Shared Key (TLS-PSK), a TLS-Public Key Infrastructure (TLS-PKI),an Internet Key Exchange version 2 (IKEv2), an Internet Protocol Security (IPsec), an application layer protection, a native authorization mechanism and an OAuth. Further, the method includes enabling the C2eIS by the AEF 108, for the at least one API invoker 102 based on the determined at least one security method. In an embodiment, the at least one security method is determined based on at least one of a type of service the API invoker 102 is subscribed, a type Interface between the AEF 108 and the API Invoker 102, access scenarios, length of a secure Transport layer security (TLS) sessions required, a capability of the API Invoker 102, capability of the AEF 108, preferences of the API Invoker 102 and a negotiation between the at least one API invoker 102 and the CCF 106. In an embodiment, the at least one determined security method is also indicated, either solicited or unsolicited, by the CCF 106 to the AEF 108 to perform the determined security method on the CAPIF-2e interface.
In an embodiment, enabling the C2eIS by the AEF 108, for the at least one API invoker 102 based on the determined at least one security method includes, establishing a secure TLS connection between the AEF 108 and the at least one API invoker 102 over the CAPIF-2e interface using the PSK received from the CCF 106, if the determined at least one security method is the TLS-PSK, wherein the PSK is derived by at least one of the at least one API invoker 102 and the CCF 106 after establishing the secure TLS connection between the CCF 106 and the at least one API invoker 102 over the CAPIF-1e interface. Further, receiving authorization rights of the at least one API invoker from the CCF over the CAPIF-3 interface. Further, authorizing the at least one API invoker 102 to access the at least one service API based on the received authorization rights of the at least one API invoker 102 from the CCF 106.
: at least one of a fully qualified domain name (FQDN) or a security protocol identifier, and the security protocol identifier is determined by negotiation between the API invoker and the CAPIF function; and the AKMA anchor key and the identification information of the CAPIF function are used for the AAnF to determine the second KAF (Wang discloses [0077] In a second group of embodiments, the AUSF pushes AKMA key material to an arbitrary AAnF and an AF may query all AAnFs. According to certain embodiments, the AUSF may select a single arbitrary AAnF instance and pushes at least the K.sub.AKMA/K.sub.AKMA ID to the AAnF in step 0a of FIG. 4.
[0078] For example, when the AF receives the AKMA Session request, the AF may send the request to all AAnF instances. For example, step 3 of FIG. 4 may be performed with all AAnF instances available in the HPLMN. The AAnF instance that holds the K.sub.AKMA ID which is matching the one sent by the UE may perform all the steps for the derivation of the K.sub.AF and respond to the AF. The other AAnF instances should discard/ignore the request. In some embodiments, the AF may send the request to each AAnF instance one at a time and stop when a match is found.
[0079] In a variant of the previous embodiment, the AUSF may select a single arbitrary AAnF instance and push the K.sub.AKMA ID and AUSF ID to it. For example, when the AF receives the AKMA Session request, the AF may send the request to all AAnF instances. The AAnF instance that holds the K.sub.AKMA ID which is matching the one sent by the UE may query the right AUSF instance (with AUSF ID corresponding to the K.sub.AKMA ID) for the K.sub.AKMA. Then the AAnF may perform all the steps for the derivation of the K.sub.AF and respond to the AF. The other AAnF instances should discard the request. In some embodiments, the AF may send the request to each AAnF instance one at a time and stop when a match is found).
As per claim 34. Rajavelsamy and Wang discloses The method according to claim 25, Rajavelsamy discloses further comprising: determining, based on a first certificate comprised in the authentication information and a root certificate corresponding to the first certificate stored by the CAPIF function, whether authentication of the API invoker is successful (FIG. 2, the embodiments herein establishes the dedicated secure connection/session for authenticating the API invoker 102. The dedicated secure connection between the API Invoker 102 and the AEF 108 can be established using two different methods such as the PSK based and the certificate based method. The established dedicated secure session can be used for all API invocations and responses. To establish the dedicated secure session, a PSK can be derived after the successful mutual authentication between the CCF 106 and the API invoker 102 over the CAPIF-1e interface. Further, the PSK can be used to establish the secure connection (for example, TLS or IPSec) between the API invoker 102 and AEF 108 over the CAPIF-2e interface. The CAPIF-1e security mechanism can be used to "bootstrap" a key for authenticating the secure TLS connection for the CAPIF-2e. In the absence of the PSK, certificate based mutual authentication between the API invoker 102 and AEF 108 can be used to establish the secure TLS session over the CAPIF-2e interface).
As per claim 35. Rajavelsamy and Wang discloses The method according to claim 27 , Rajavelsamy discloses wherein the method comprises at least one of:
determining, based on successful authentication of the API invoker, an onboard secret key of the API invoker ( par 0012 authenticating application program interface (API) invokers using a common application program interface framework (CAPIF). The method includes establishing by a CAPIF core function (CCF) a secure connection with at least one API invoker, on receiving a connection request from the at least one API invoker to access the at least one service API on a CAPIF-2e interface, wherein establishing the secure connection between the CCF and the at least one API invoker is based on a mutual authentication between the CCF and the at least one API invoker over a CAPIF-1e interface. Further, the method includes determining and indicating by the CCF at least one security method to be used by the at least one API invoker for the C2eIS (i.e., authentication, interface protection and authorization) of the at least one API invoker for accessing the at least one service API on a CAPIF-2e interface, wherein the at least one security method includes at least one of a Transport Layers Security -Pre-Shared Key (TLS-PSK), a TLS-Public Key Infrastructure (TLS-PKI), IKEv2, IPsec and an OAuth. The method further includes enabling the C2eIS by an API exposing function (AEF) the at least one API invoker based on the determined at least one security method. Referring now to the drawings, and more particularly to FIGS. 1 through 9 );
determining, based on successful authentication of the API invoker, API invoker configuration information of the API invoker according to a token of the API invoker comprised in the first request information, wherein the API invoker configuration information comprises: API exposing function (AEF) authentication and authorization information ( 0012 authenticating application program interface (API) invokers using a common application program interface framework (CAPIF). The method includes establishing by a CAPIF core function (CCF) a secure connection with at least one API invoker, on receiving a connection request from the at least one API invoker to access the at least one service API on a CAPIF-2e interface, wherein establishing the secure connection between the CCF and the at least one API invoker is based on a mutual authentication between the CCF and the at least one API invoker over a CAPIF-1e interface. Further, the method includes determining and indicating by the CCF at least one security method to be used by the at least one API invoker for the C2eIS (i.e., authentication, interface protection and authorization) of the at least one API invoker for accessing the at least one service API on a CAPIF-2e interface, wherein the at least one security method includes at least one of a Transport Layers Security -Pre-Shared Key (TLS-PSK), a TLS-Public Key Infrastructure (TLS-PKI), IKEv2, IPsec and an OAuth. The method further includes enabling the C2eIS by an API exposing function (AEF) the at least one API invoker based on the determined at least one security method. Referring now to the drawings, and more particularly to FIGS. 1 through 9 );
generating, based on successful identity authentication of the API invoker, an API invoker's certificate, wherein the API invoker's certificate comprises a public key of the API invoker and identification information of the API invoker ( FIG. 2, the embodiments herein establishes the dedicated secure connection/session for authenticating the API invoker 102. The dedicated secure connection between the API Invoker 102 and the AEF 108 can be established using two different methods such as the PSK based and the certificate based method. The established dedicated secure session can be used for all API invocations and responses. To establish the dedicated secure session, a PSK can be derived after the successful mutual authentication between the CCF 106 and the API invoker 102 over the CAPIF-1e interface. Further, the PSK can be used to establish the secure connection (for example, TLS or IPSec) between the API invoker 102 and AEF 108 over the CAPIF-2e interface. The CAPIF-1e security mechanism can be used to "bootstrap" a key for authenticating the secure TLS connection for the CAPIF-2e. In the absence of the PSK, certificate based mutual authentication between the API invoker 102 and AEF 108 can be used to establish the secure TLS session over the CAPIF-2e interface.); or
sending first response information to the API invoker, wherein the first response information comprises at least one of: onboarding information of the API invoker, the API invoker configuration information and the API invoker's certificate (The FIG.2 shows a high-level security information flows between the API invoker 102, the CCF 106 and the AEF 108 for establishing the secure channel using the PSK (for the access scenario: the API invoker 102 access the AEF 108 prior to the service API invocation). The security information is exchanged over the CAPIF-le, the CAPIF-2e and the CAPIF-3 reference points are detailed below in the steps.
At step 1, the method includes establishing the secure TLS session/connection between the API invoker 102 and the CCF 106 over the CAPIF-1e interface. The method allows the API invoker 102 and the CCF 106 to establish the secure TLS session/connection between the API invoker 102 and the CCF 106 over the CAPIF-1e interface. The secure TLS session can be established between the API invoker 102 and the CCF 106 based on the mutual authentication between the API invoker 102 and the CCF 106. The mutual authentication can be certificate based mutual authentication (i.e., mutual authentication based on a client (i.e., API invoker 102) and a server (i.e., CCF 106) certificates).
At step 2, the method includes deriving the PSK over the CAPIF-1e interface. The method allows the API invoker 102 and the CCF 106 to derive the PSK. After the successful establishment of the secure TLS session, the PSK can be derived based on the TLS Session's master secret, AEF's 108 specific parameters, session parameters and other possible parameters. In an embodiment, derivation of the PSK at the CCF 106 can be delayed till a request for the PSK is received from the AEF 108. In an embodiment, the PSK is specific to a particular AEF 108 (PSK is bound to an AEF ID). The AEF ID is unique identifier at least within the CAPIF. AEF.sub.PSK = KDF (TLS Session Master_Secret, TLS Session parameters, AEF ID, <other potential parameters>). The KDF is a Key Derivation Function. AEF.sub.PSK and the PSK terms are used interchangeably throughout this document ).
Conclusion
THIS ACTION IS MADE FINAL. 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 ABU S SHOLEMAN whose telephone number is (571)270-7314. The examiner can normally be reached EST: 9am-5pm.
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, JORGE ORTIZ CRIADO can be reached at 571-272-7624. 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.
/ABU S SHOLEMAN/Primary Examiner, Art Unit 2496
Prosecution Insights