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 written action is responding to the Requested Continued Evaluation dated on 06/15/2026.
Claims 20 and 26 has been amended.
Claims 20-23 and 26-29 are submitted for examination.
Claims 20-23 and 26-29 are pending.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 05/06/2026 was filed after the mailing date. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on June 15, 2026 has been entered.
Response to Arguments
Applicant’s amendment, filed on June 15, 2026, has claims 20 and 26 amended. Claims 20 and 26 are independent claims.
Applicant’s remark, filed on June 15, 2026 at pages 7-10, indicates, “… In ex parte examination of patent applications, the Office bears the burden of establishing a prima facie case of obviousness. MPEP § 2142. Absent such a prima facie case, the Applicant is under no obligation to produce evidence of nonobviousness. Id. … Claim 20 recites "determining whether to provide the AKMA service to the UE, based on the GPSI" and "based on the AF entity being allowed to obtain the AKMA service from the AAnF entity and a determination to provide the AKMA service to the UE, deriving the requested AKMA application key for the UE from an AKMA Anchor Key (KAKMA).” Specifically, according Claim 20, an AAnF is the entity authorizing the UE. For example, the paragraphs [0171] and [0174] explicitly discloses that the AAnF authorizes the UE using the GPSI …”. The Office Action asserts that, since AF needs GPSI in order to correctly identify UE and the AF selects AAnF for acquiring Kaf for the UE according to Tsiatsis, the reference discloses the above-emphasized claim features. … These portions of Tsiatsis merely disclose that the "AF" selects AAnF using the GPSI, and fail to disclose that the "AAnF" determines to provide AKMA service to the UE using the GPSI. In contrast with Claim 20, the AF in Tsiatsis is the subject of authorizing the UE, not the AAnF as recited. For at least these reasons, Claim 20 and its dependent claims are patentable over the cited references, taken alone or in combination. Claim 26 recites analogous limitations to those discussed above and is, together with its dependent claims, also patentable over the cited references for at least the same reasons. Withdrawal of the § 103 rejection is respectfully requested.”
Applicant’s arguments have been fully considered, but are not found persuasive. Arguments are not found persuasive, as follows:
According to the teaching from Tsiatsis, Tsiatsis clearly teaches a method for providing Authentication and Key Management for Applications (AKMA) service in 3GPP to a user equipment (UE) based on subscriber-related information maintained by the network. In particular, Tsiatsis discloses that the AKMA service enablement is controlled using identifiers associated with the UE/subscriber and corresponding subscription data stored in network entities. A Global Public Subscription Identifier (GPSI) is one of the well-known 3GPP-defined identifiers used to identify a subscriber and access subscription-related information. Specifically, example embodiments of Tsiatsis describe methods performed by a key management server (e.g., AAnF) in a communication network (e.g., 5GC). These embodiments can include receiving, from an application function (AF) a request for a security key (Kaf) specific to an application session for a particular UE. In particular, parag. [0035], the representation of the first and second identifiers can include the first identifier (e.g., KakmalD) and the second identifier. The second identifier can be any one of the following: HPLMN ID and user equipment routing identifier (RID), subscription concealed identifier (SUCI); subscription permanent identifier (SUPI), or generic public subscription identifier (GPSI). In addition, parags. [0045] and [0153] of Tsiatsis clearly describe the AAnF is in communication with the UDM and sending to the UDM a first request for a fourth identifier associated with the AUSF. In sub-block 1424, the key management server can receive, from the UDM, a first response including the fourth identifier that could be a SUPI/GPSI. Furthermore, Tsiatsis discloses, in Parag. [0133], "In operation 4d, the UDM returns the SUPI (corresponding to GPSI) and AUSF ID to the requesting AAnF. The provided SUPI can be used by the AAnF for subsequent key requests for the same UE". This particular teaching implies that the UE having the same GPSI (i.e., the same UE) needs to be determined in order for the AAnF to provide the AKMA service to the UE based on the identifier (i.e., GPSI). Furthermore, Tsiatsis discloses, in parag. [0132], the UE includes KakmaID and GPSI. The GPSI can be included within the KakmalD or can be included as a separate identifier in the message. The AF selects AAnF based on HPLM ID associated with the GPSI and sends the selected AAnF a request for Kaf to use in the application session with UE. The request includes AF ID, KakmalD, and GPSI”. Teaching in parag. [0137] discloses “In operation 0b, the UE runs a primary authentication with the network. Kakma and KakmalD are generated and stored in UE and AUSF. The AUSF also generates a binding identifier B-TID, which can include KakmaID, AKMA binding information (e.g., from operation 0a), and UE identifier(s) (e.g., GPSI). The AUSF calls the existing service operation Nudm_UE Authentication_ResultConfirmation to inform UDM about the authentication result including SUPI, AUSF ID, Serving Network Name, authentication Type, and timestamp information. Additionally, AUSF provides B-TID. UDM then stores all information together”. In addition, in parag. [0158], the key management server can receive, from an application function, a request for a security key (Kaf) specific to an application session for the particular user, wherein the request comprises a further identifier (KakmaID) of a non-application-specific anchor security key associated with the particular user. The request can include a further identifier (KakmalD) of a non-application-specific anchor security key associated with the particular user.” Thus, Examiner submits that the AF needs the GPSI to correctly identify the corresponding subscriber (i.e., UE) for the application session, and therefore, the AF selects the AAnF in order to receive the security key Kaf specific for the identified subscriber having the corresponding identifier (SUPI/GPSI). In summary, the AAnF’s decision to provide the AKMA service based on GPSI will involve retrieving the GPSI from the UDM, checking policies and AF authorization, deriving the application-specific key (KAF) and sending it including the corresponding identifier to establish the communication with the UE. Therefore, based on the aforementioned paragraphs, Tsiatsis clearly discloses the features, "determining whether to provide the AKMA service to the UE, based on the GPSI" and "based on the AF entity being allowed to obtain the AKMA service from the AAnF entity and a determination to provide the AKMA service to the UE, deriving the requested AKMA application key for the UE from an AKMA Anchor Key (KAKMA).”. Please also refer to the detailed prior-art rejection below.
Examiner further submits it is well established that a determination of obviousness mat be based on a combination of multiple references, provided there is an articulated reasoning with a rational underpinning for why a person of ordinary skill in the art would have combined the teachings. Under the KSR Int’l Co v Teleflex Inc. rationale for 35 U.S.C. 103, the references need not come from the same field of endeavor or explicitly suggest combination with each other, so long as they are reasonably pertinent to the problem addressed by the Applicant. Therefore, the rejection based on the combination of prior-art references by 3GPP-2019, 3GPP-2020 and Tsiatsis is maintained as the combination would still render the newly amended claim 20 obvious.
Applicant’s remark, filed on June 15, 2026 at pages 7-10, indicates similar arguments for independent claim 26.
Applicant’s argument has been considered. Please refer to the aforementioned response on item 10, which addresses how the prior-art reference by Tsiatsis, when in combination with other previously applied references, would renders the independent claim 26 obvious.
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.
Claims 20-23 and 26-29 are rejected under 35 U.S.C. 103 as being unpatentable over 3GPP TS 33.535 V0.2.0 (2019-11) - 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Authentication and key management for applications; based on 3GPP credential in 5G (AKMA) Release 16, hereinafter 3GPP-2019, and in view of 3GPP TS 33.535 V0.3.0 (2020-03) - 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Authentication and key management for applications; based on 3GPP credential in 5G (AKMA) Release 16, hereinafter 3GPP-2020 and further in view of Tsiatsis et al. (US 2021/0392495) hereinafter Tsiatsis.
Regarding claim 20, 3GPP-2019 teaches:
A method performed by an authentication and key management for applications AKMA anchor function (AAnF) entity in a wireless communication system, the method comprising (3GPP-2019, [Page 7]; “Figure 4.1 a fundamental network model of AKMA … shows the case where AAnF is deployed as a standalone function. Deployments can choose to collocate AAnF with AUSF or with NEF according to operators’ deployment scenarios.” … Figure 6.2-1 shows an AF Key generation method from KAKMA”):
receiving, from an application function (AF) entity, a message for requesting an (AKMA) application key for a user equipment (UE) wherein the message for requesting the AKMA application key includes an AF identifier (ID) of the AF entity (3GPP-2019, Section 6.2-1, [Page 10]; “… then the AF sends a request to AAnF with the key identifier to request application function specific AKMA keys for the UE. The AF also includes its identity (AF Id) in the request.”);
[checking that the AF entity is allowed to obtain an AKMA service from the AAnF entity, based on a configured local policy or authorization information];
[transmitting, to a unified data management (UDM) entity, a request for fetching a generic public subscription identifier (GPSI) of the UE];
[receiving, from the UDM entity, a response including the GPSI];
[determine whether to provide the AKMA service to the UE based on the GPSI];
based on the AF entity being allowed to obtain the AKMA service from the AAnF entity and [a determination to provide the AKMA service to the UE], deriving the requested AKMA application key for the UE from an AKMA Anchor Key (KAKMA) (3GPP-2019, Section 6.2-1, [Page 10]; “If KAKMA is available in AAnF (i.e., allowed to obtain the AKMA), it shall derive the AF specific AKMA key (KAF) from KAKMA and respond to the AF with KAF and lifetime”); and
transmitting, to the AF entity, a response message including the derived AKMA application key (3GPP-2019, Section 6.2-1, [Page 10]; “If KAKMA is available in AAnF (i.e., allowed to obtain the AKMA), it shall derive the AF specific AKMA key (KAF) from KAKMA and respond to the AF with KAF and lifetime”).
3GPP-2019 does not expressly teach:
checking that the AF entity is allowed to obtain an AKMA service from the AAnF entity, based on a configured local policy or authorization information;
transmitting, to a unified data management (UDM) entity, a request for fetching a generic public subscription identifier (GPSI) of the UE;
receiving, from the UDM entity, a response including the GPSI;
determine whether to provide the AKMA service to the UE based on the GPSI;
a determination to provide the AKMA service to the UE
However, 3GPP-2020 teaches:
checking that the AF entity is allowed to obtain an AKMA service from the AAnF entity, based on a configured local policy or authorization information (3GPP-2020, Section 5.2, [Page 9]; “The KAKMA is valid until the next primary authentication is performed (implicit lifetime), in which case the KAKMA might be replaced after a successful new authentication or removed after an unsuccessful one. Application keys KAF shall use explicit lifetimes based on operator’s policy. The lifetime of KAF shall be sent by the AAnF as described in clause 6.2. In case that a new anchor key KAKMA is established, the application key KAF can continue to be used until its lifetime expires. When the KAF lifetime expires, a new application key is established based on the current anchor key KAKMA.” … Section 6.2, [Page 11]; “The AF also includes its identity (AF Id) in the request. If the AF does not have an active context associated with the key identifier, then the AF sends a request to AAnF with the key identifier to request application function specific AKMA keys for the UE. The AF also includes its identity (AF Id) in the request. The AAnF shall check whether the AAnF can provide the service to the AF by checking the AF Id. If succeeds, the following procedures is executed. Otherwise, the AAnF shall reject the procedure.”); Examiner submits that the claimed local policy has been also interpreted as the protocol required to provide the AKMA service by checking whether the AF ID is valid or not. In addition, the authorization information is an alternative to the claimed feature due to the limitation “OR”;
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of 3GPP-2019, and 3GPP-2020 before them, to modify 3GPP-2019 that teaches a method performed by an AKMA anchor function (AAnF) entity in a wireless communication system; to include checking if the AF received the AKMA based on a valid AF ID. One would have been motivated to have a more secure system as taught by 3GPP-2020 (see Section 6.2).
The combination of 3GGP-2019 and 3GPP-2020 does not expressly teach:
transmitting, to a unified data management (UDM) entity, a request for fetching a generic public subscription identifier (GPSI) of the UE;
receiving, from the UDM entity, a response including the GPSI;
determine whether to provide the AKMA service to the UE based on the GPSI;
a determination to provide the AKMA service to the UE
However, Tsiatsis teaches:
transmitting, to a unified data management (UDM) entity, a request for fetching a generic public subscription identifier (GPSI) of the UE (Tsiatsis, Parag. [0036]; “In such embodiments, the determining operations can include selecting a unified data management (UDM) function, in the communication network, based on the second identifier; sending, to the UDM, a first request for a fourth identifier associated with the AUSF; and receiving, from the UDM, a first response including the fourth identifier. In some embodiments, the first response can also include a further second identifier related to the network subscription associated with the particular user. For example, the further second identifier can be a SUPI and the second identifier can be an identifier other than SUPI (e.g., GPSI, SUCI, HPLMN+RID).” … Parag. [0045]; “These Example methods can include receiving, from an anchor function for authentication and key management for applications (AAnF) in the communication network, a request for a non-application-specific anchor security key (Kakma) for a particular user. The request can include a first representation of the following: the first identifier (KakmalD) associated with the non-application-specific anchor security key (Kakma), and a second identifier related to a network subscription of the particular user.” … Parag. [0153]; “In such embodiments, the determining operations of block 1420 can include the operations of sub-blocks 1422-1424. In sub-block 1422, the key management server can select a unified data management (UDM) function, in the communication network, based on the second identifier. In sub-block 1423, the key management server (i.e., AAnF) can send, to the UDM, a first request for a fourth identifier associated with the AUSF. In sub-block 1424, the key management server can receive, from the UDM, a first response including the fourth identifier. In some embodiments, the first response can also include a further second identifier related to the network subscription associated with the particular user. For example, the further second identifier can be a SUPI and the second identifier can be an identifier other than SUPI (e.g., GPSI , SUCI , HPLMN + RID ).”);
receiving, from the UDM entity, a response including the GPSI (Tsiatsis, Parag. [0036]; “In such embodiments, the determining operations can include selecting a unified data management (UDM) function, in the communication network, based on the second identifier; sending, to the UDM, a first request for a fourth identifier associated with the AUSF; and receiving, from the UDM, a first response including the fourth identifier. In some embodiments, the first response can also include a further second identifier related to the network subscription associated with the particular user. For example, the further second identifier can be a SUPI and the second identifier can be an identifier other than SUPI (e.g., GPSI, SUCI, HPLMN+RID).” … Parag. [0045]; “These Example methods can include receiving, from an anchor function for authentication and key management for applications (AAnF) in the communication network, a request for a non-application-specific anchor security key (Kakma) for a particular user. The request can include a first representation of the following: the first identifier (KakmalD) associated with the non-application-specific anchor security key (Kakma), and a second identifier related to a network subscription of the particular user.” … Parag. [0153]; “In such embodiments, the determining operations of block 1420 can include the operations of sub-blocks 1422-1424. In sub-block 1422, the key management server can select a unified data management (UDM) function, in the communication network, based on the second identifier. In sub-block 1423, the key management server (i.e., AAnF) can send, to the UDM, a first request for a fourth identifier associated with the AUSF. In sub-block 1424, the key management server can receive, from the UDM, a first response including the fourth identifier. In some embodiments, the first response can also include a further second identifier related to the network subscription associated with the particular user. For example, the further second identifier can be a SUPI and the second identifier can be an identifier other than SUPI (e.g., GPSI , SUCI , HPLMN + RID ).”);
determine whether to provide the AKMA service to the UE based on the GPSI (Tsiatsis, Parag. [0035]; “ In other embodiments, the representation of the first and second identifiers can include the first identifier (e.g., KakmalD) and the second identifier. For example, the second identifier can be any one of the following: HPLMN ID and user equipment routing identifier (RID); subscription concealed identifier (SUCI); subscription permanent identifier (SUPI); or generic public subscription identifier (GPSI). In a variant, the representation can include only the first identifier (e.g., KakmaID), which can include a representation of the second identifier.” … Parag. [0132]; “Operation 0 is identical to operation 0 shown in FIGS. 9-10. In operation 1, the UE initiates an application session setup procedure with the AF. The UE includes KakmaID and GPSI. The GPSI can be included within the KakmalD or can be included as a separate identifier in the message. In operations 2-3, the AF selects AAnF based on HPLM ID associated with the GPSI and sends the selected AAnF a request for Kaf to use in the application session with UE. The request includes AF ID, KakmalD, and GPSI.” … Parag. [0133]; “Operation 4 involves AUSF discovery and selection by the AAF. In operation 4a, the AAnF discovers and selects UDM based on GPSI received from the AF. In operation 4b, the AAnF calls a new service operation Nudm_UEAuthentication_ResultStatus to send a request to the selected UDM with KakmalD and GPSI included with the request . In operation 4c , UDM translates the received GPSI to the corresponding SUPI and uses SUPI to select the AUSF instance based on the information stored during operation 0. UDM verifies that KakmalD received from the AAnF is included in the stored authentication context for the UE. In operation 4d , the UDM returns the SUPI (corresponding to GPSI ) and AUSF ID to the requesting AAnF. The provided SUPI can be used by the AAnF for subsequent key requests for the same UE, as needed or desired.” … Parag. [0158]; “The example method can also include the operations of block 1530, in which the key management server can receive, from an application function, a request for a security key (Kaf) specific to an application session for the particular user, wherein the request comprises a further identifier (KakmaID) of a non-application-specific anchor security key associated with the particular user. The request can include a further identifier (KakmalD) of a non-application-specific anchor security key associated with the particular user.” Examiner submits that the AF needs GPSI to correctly identify the subscriber (i.e., UE) for the application session, and therefore, the AF selects the AAnF in order to receive the security key Kaf specific for the identified subscriber having the corresponding identifier (SUPI/GPSI).);
a determination to provide the AKMA service to the UE (Tsiatsis, Parag. [0035]; “ In other embodiments, the representation of the first and second identifiers can include the first identifier (e.g., KakmalD) and the second identifier. For example, the second identifier can be any one of the following: HPLMN ID and user equipment routing identifier (RID); subscription concealed identifier (SUCI); subscription permanent identifier (SUPI); or generic public subscription identifier (GPSI). In a variant, the representation can include only the first identifier (e.g., KakmaID), which can include a representation of the second identifier.” … Parag. [0132]; “Operation 0 is identical to operation 0 shown in FIGS. 9-10. In operation 1, the UE initiates an application session setup procedure with the AF. The UE includes KakmaID and GPSI. The GPSI can be included within the KakmalD or can be included as a separate identifier in the message. In operations 2-3, the AF selects AAnF based on HPLM ID associated with the GPSI and sends the selected AAnF a request for Kaf to use in the application session with UE.” … Parag. [0133]; “Operation 4 involves AUSF discovery and selection by the AAF. In operation 4a, the AAnF discovers and selects UDM based on GPSI received from the AF. In operation 4b, the AAnF calls a new service operation Nudm_UEAuthentication_ResultStatus to send a request to the selected UDM with KakmalD and GPSI included with the request . In operation 4c , UDM translates the received GPSI to the corresponding SUPI and uses SUPI to select the AUSF instance based on the information stored during operation 0. UDM verifies that KakmalD received from the AAnF is included in the stored authentication context for the UE. In operation 4d , the UDM returns the SUPI (corresponding to GPSI ) and AUSF ID to the requesting AAnF. The provided SUPI can be used by the AAnF for subsequent key requests for the same UE, as needed or desired.” … Parag. [0137]; discloses “In operation 0b, the UE runs a primary authentication with the network. Kakma and KakmalD are generated and stored in UE and AUSF. The AUSF also generates a binding identifier B-TID, which can include KakmaID, AKMA binding information (e.g., from operation 0a), and UE identifier(s) (e.g., GPSI). The AUSF calls the existing service operation Nudm_UEAuthentication_ResultConfirmation to inform UDM about the authentication result including SUPI, AUSF ID, Serving Network Name, authentication Type, and timestamp information. Additionally, AUSF provides B-TID. UDM then stores all information together.” … Parag. [0158]; “The example method can also include the operations of block 1530, in which the key management server can receive, from an application function, a request for a security key (Kaf) specific to an application session for the particular user, wherein the request comprises a further identifier (KakmaID) of a non-application-specific anchor security key associated with the particular user. The request can include a further identifier (KakmalD) of a non-application-specific anchor security key associated with the particular user.” Examiner submits that the AF needs the GPSI to correctly identify the subscriber (i.e., UE) for the application session, and therefore, the AF selects the AAnF in order to receive the security key Kaf specific for the identified subscriber having the corresponding identifier (SUPI/GPSI).).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Tsiatsis to modify 3GPP2020-3GPP-2019 that teaches a method performed by an AKMA anchor function (AAnF) entity in a wireless communication system; to request UE identifier to establish secure communications in 5G networks (see Parag. [0153-0158]).
Regarding claim 21, the combination of 3GPP-2019, 3GPP-2020 and Tsiatsis teaches the method of claim 20. 3GPP-2019 further teaches wherein the response further includes an expiration time of the AKMA application key (3GPP-2019, Section 6.2-1, [Page 10]; “If KAKMA is available in AAnF (i.e., allowed to obtain the AKMA), it shall derive the AF specific AKMA key (KAF) from KAKMA and respond to the AF with KAF and lifetime”).
Regarding claim 22, the combination of 3GPP-2019, 3GPP-2020 and Tsiatsis teach the method of claim 20. 3GPP-2019 further teaches wherein the message for requesting the AKMA application key further includes an AKMA key ID related to the UE (3GPP-2019, Section 6.1, [Page 10], “The KAKMA key identifier identifies the KAKMA key of the UE from which other AKMA keys are derived. Editor’s Note: Derivation of KAKMA is FFS. Editor’s Note: Format and derivation of KAKMA key identifier and its association with UE identifier is FFS. Whether the key identifier is generated during the primary authentication or as needed, is FFS.).
Regarding claim 23, the combination of 3GPP-2019, 3GPP-2020 and Tsiatsis teach the method of claim 20. 3GPP-2020 teaches in case that the AF entity is not allowed to obtain the AKMA service from the AAnF entity, rejecting the message for requesting the AKMA application key (3GPP-2020, Section 6.2-1, [Page 11]; “If the AF does not have an active context associated with the key identifier, then the AF sends a request to AAnF with the key identifier to request application function specific AKMA keys for the UE. The AF also includes its identity (AF Id) in the request. The AAnF shall check whether the AAnF can provide the service to the AF by checking the AF Id. If succeeds, the following procedures is executed. Otherwise, the AAnF shall reject the procedure.”).
Regarding claim 26, 3GPP-2019 teaches an authentication and key management for applications AKMA anchor function (AAnF) entity in a wireless communication system, the AAnF entity comprising (3GPP-2019, [Page 7]; “Figure 4.1 a fundamental network model of AKMA … shows the case where AAnF is deployed as a standalone function. Deployments can choose to collocate AAnF with AUSF or with NEF according to operators’ deployment scenarios.” … Figure 6.2-1 shows an AF Key generation method from KAKMA”):
[a transceiver]; and
[at least one processor coupled with the transceiver and configured to]:
receive, from an application function (AF) entity, a message for requesting an (AKMA) application key for a user equipment (UE), wherein the message for requesting the AKMA application key includes an AF identifier (ID) of the AF entity (3GPP-2019, Section 6.2-1, [Page 10]; “… then the AF sends a request to AAnF with the key identifier to request application function specific AKMA keys for the UE. The AF also includes its identity (AF Id) in the request.”);
[check that the AF entity is allowed to obtain an AKMA service from the AAnF entity, based on a configured local policy or authorization information];
[transmit, to a unified data management (UDM) entity, a request for fetching a generic public subscription identifier (GPSI) of the UE];
[receive, from the UDM entity, a response including the GPSI];
[determine whether to provide the AKMA service to the UE, based on the GPSI];
based on the AF entity being allowed to obtain the AKMA service from the AAnF entity and [a determination to provide the AKMA service to the UE], derive the requested AKMA application key for the UE from an AKMA Anchor Key (KAKMA) (3GPP-2019, Section 6.2-1, [Page 10]; “If KAKMA is available in AAnF (i.e., allowed to obtain the AKMA), it shall derive the AF specific AKMA key (KAF) from KAKMA and respond to the AF with KAF and lifetime”); and
transmit, to the AF entity, a response message including the derived AKMA application key (3GPP-2019, Section 6.2-1, [Page 10]; “If KAKMA is available in AAnF (i.e., allowed to obtain the AKMA), it shall derive the AF specific AKMA key (KAF) from KAKMA and respond to the AF with KAF and lifetime”).
3GPP-2019 does not expressly teach:
the AAnF entity comprising:
a transceiver; and
at least one processor coupled with the transceiver …
check that the AF entity is allowed to obtain an AKMA service from the AAnF entity, based on a configured local policy or authorization information;
transmit, to a unified data management (UDM) entity, a request for fetching a generic public subscription identifier (GPSI) of the UE;
receive, from the UDM entity, a response including the GPSI;
determine whether to provide the AKMA service to the UE, based on the GPSI;
a determination to provide the AKMA service to the UE
However, 3GPP-2020 teaches:
check that the AF entity is allowed to obtain an AKMA service from the AAnF entity, based on a configured local policy or authorization information (3GPP-2020, Section 5.2, [Page 9]; “The KAKMA is valid until the next primary authentication is performed (implicit lifetime), in which case the KAKMA might be replaced after a successful new authentication or removed after an unsuccessful one. Application keys KAF shall use explicit lifetimes based on operator’s policy. The lifetime of KAF shall be sent by the AAnF as described in clause 6.2. In case that a new anchor key KAKMA is established, the application key KAF can continue to be used until its lifetime expires. When the KAF lifetime expires, a new application key is established based on the current anchor key KAKMA.” … Section 6.2, [Page 11]; “The AF also includes its identity (AF Id) in the request. If the AF does not have an active context associated with the key identifier, then the AF sends a request to AAnF with the key identifier to request application function specific AKMA keys for the UE. The AF also includes its identity (AF Id) in the request. The AAnF shall check whether the AAnF can provide the service to the AF by checking the AF Id. If succeeds, the following procedures is executed. Otherwise, the AAnF shall reject the procedure.”) Examiner submits that is not clear what the claimed local policy refers to, however has been interpreted as the steps or protocol to provide the AKMA service by checking if the AF ID is valid and reject it if not valid. In addition, the authorization information is an alternative to the claimed feature due to the limitation “OR”;
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of 3GPP-2019, and 3GPP-2020 before them, to modify 3GPP-2019 that teaches a method performed by an AKMA anchor function (AAnF) entity in a wireless communication system; to include checking if the AF received the AKMA based on a valid AF ID. One would have been motivated to have a more secure system as taught by 3GPP-2020 (see Section 6.2).
The combination of 3GPP-2019 and 3GPP-2020 does not expressly teach:
the AAnF entity comprising:
a transceiver; and
at least one processor coupled with the transceiver …
transmit, to a unified data management (UDM) entity, a request for fetching a generic public subscription identifier (GPSI) of the UE;
receive, from the UDM entity, a response including the GPSI;
determine whether to provide the AKMA service to the UE, based on the GPSI;
a determination to provide the AKMA service to the UE
However, Tsiatsis teaches:
a transceiver (Tsiatsis, Parag. [0187]; “In some embodiments, processing circuitry 2070 can include one or more of radio frequency (RF) transceiver circuitry 2072 and baseband processing circuitry 2074. In some embodiments, radio frequency (RF) transceiver circuitry 2072 and baseband processing circuitry 2074 can be on separate chips (or sets of chips), boards, or units, such as radio units and digital units.”); and
at least one processor coupled with the transceiver (Tsiatsis, Parag. [0185]; “Processing circuitry 2070 can comprise a combi nation of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application- specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and/or encoded logic.”)
transmit, to a unified data management (UDM) entity, a request for fetching a generic public subscription identifier (GPSI) of the UE (Tsiatsis, Parag. [0036]; “In such embodiments, the determining operations can include selecting a unified data management (UDM) function, in the communication network, based on the second identifier; sending, to the UDM, a first request for a fourth identifier associated with the AUSF; and receiving, from the UDM, a first response including the fourth identifier. In some embodiments, the first response can also include a further second identifier related to the network subscription associated with the particular user. For example, the further second identifier can be a SUPI and the second identifier can be an identifier other than SUPI (e.g., GPSI, SUCI, HPLMN+RID).” … Parag. [0045]; “These Example methods can include receiving, from an anchor function for authentication and key management for applications (AAnF) in the communication network, a request for a non-application-specific anchor security key (Kakma) for a particular user. The request can include a first representation of the following: the first identifier (KakmalD) associated with the non-application-specific anchor security key (Kakma), and a second identifier related to a network subscription of the particular user.” … Parag. [0153]; “In such embodiments, the determining operations of block 1420 can include the operations of sub-blocks 1422-1424. In sub-block 1422, the key management server can select a unified data management (UDM) function, in the communication network, based on the second identifier. In sub-block 1423, the key management server (i.e., AAnF) can send, to the UDM, a first request for a fourth identifier associated with the AUSF. In sub-block 1424, the key management server can receive, from the UDM, a first response including the fourth identifier. In some embodiments, the first response can also include a further second identifier related to the network subscription associated with the particular user. For example, the further second identifier can be a SUPI and the second identifier can be an identifier other than SUPI (e.g., GPSI , SUCI , HPLMN + RID ).”),
receiving, from the UDM entity, a response including the GPSI (Tsiatsis, Parag. [0036]; “In such embodiments, the determining operations can include selecting a unified data management (UDM) function, in the communication network, based on the second identifier; sending, to the UDM, a first request for a fourth identifier associated with the AUSF; and receiving, from the UDM, a first response including the fourth identifier. In some embodiments, the first response can also include a further second identifier related to the network subscription associated with the particular user. For example, the further second identifier can be a SUPI and the second identifier can be an identifier other than SUPI (e.g., GPSI, SUCI, HPLMN+RID).” … Parag. [0045]; “These Example methods can include receiving, from an anchor function for authentication and key management for applications (AAnF) in the communication network, a request for a non-application-specific anchor security key (Kakma) for a particular user. The request can include a first representation of the following: the first identifier (KakmalD) associated with the non-application-specific anchor security key (Kakma), and a second identifier related to a network subscription of the particular user.” … Parag. [0153]; “In such embodiments, the determining operations of block 1420 can include the operations of sub-blocks 1422-1424. In sub-block 1422, the key management server can select a unified data management (UDM) function, in the communication network, based on the second identifier. In sub-block 1423, the key management server (i.e., AAnF) can send, to the UDM, a first request for a fourth identifier associated with the AUSF. In sub-block 1424, the key management server can receive, from the UDM, a first response including the fourth identifier. In some embodiments, the first response can also include a further second identifier related to the network subscription associated with the particular user. For example, the further second identifier can be a SUPI and the second identifier can be an identifier other than SUPI (e.g., GPSI , SUCI , HPLMN + RID).”);
determine whether to provide the AKMA service to the UE, based on the GPSI (Tsiatsis, Parag. [0035]; “ In other embodiments, the representation of the first and second identifiers can include the first identifier (e.g., KakmalD) and the second identifier. For example, the second identifier can be any one of the following: HPLMN ID and user equipment routing identifier (RID); subscription concealed identifier (SUCI); subscription permanent identifier (SUPI); or generic public subscription identifier (GPSI). In a variant, the representation can include only the first identifier (e.g., KakmaID), which can include a representation of the second identifier.” … Parag. [0132]; “Operation 0 is identical to operation 0 shown in FIGS. 9-10. In operation 1, the UE initiates an application session setup procedure with the AF. The UE includes KakmaID and GPSI. The GPSI can be included within the KakmalD or can be included as a separate identifier in the message. In operations 2-3, the AF selects AAnF based on HPLM ID associated with the GPSI and sends the selected AAnF a request for Kaf to use in the application session with UE.” … Parag. [0133]; “Operation 4 involves AUSF discovery and selection by the AAF. In operation 4a, the AAnF discovers and selects UDM based on GPSI received from the AF. In operation 4b, the AAnF calls a new service operation Nudm_UEAuthentication_ResultStatus to send a request to the selected UDM with KakmalD and GPSI included with the request . In operation 4c , UDM translates the received GPSI to the corresponding SUPI and uses SUPI to select the AUSF instance based on the information stored during operation 0. UDM verifies that KakmalD received from the AAnF is included in the stored authentication context for the UE. In operation 4d , the UDM returns the SUPI (corresponding to GPSI ) and AUSF ID to the requesting AAnF. The provided SUPI can be used by the AAnF for subsequent key requests for the same UE, as needed or desired.” … Parag. [0158]; “The example method can also include the operations of block 1530, in which the key management server can receive, from an application function, a request for a security key (Kaf) specific to an application session for the particular user, wherein the request comprises a further identifier (KakmaID) of a non-application-specific anchor security key associated with the particular user. The request can include a further identifier (KakmalD) of a non-application-specific anchor security key associated with the particular user.” Examiner submits that the AF needs GPSI to correctly identify the subscriber (i.e., UE) for the application session, and therefore, the AF selects the AAnF in order to receive the security key Kaf specific for the identified subscriber having the corresponding identifier (SUPI/GPSI).);
a determination to provide the AKMA service to the UE (Tsiatsis, Parag. [0035]; “ In other embodiments, the representation of the first and second identifiers can include the first identifier (e.g., KakmalD) and the second identifier. For example, the second identifier can be any one of the following: HPLMN ID and user equipment routing identifier (RID); subscription concealed identifier (SUCI); subscription permanent identifier (SUPI); or generic public subscription identifier (GPSI). In a variant, the representation can include only the first identifier (e.g., KakmaID), which can include a representation of the second identifier.” … Parag. [0132]; “Operation 0 is identical to operation 0 shown in FIGS. 9-10. In operation 1, the UE initiates an application session setup procedure with the AF. The UE includes KakmaID and GPSI. The GPSI can be included within the KakmalD or can be included as a separate identifier in the message. In operations 2-3, the AF selects AAnF based on HPLM ID associated with the GPSI and sends the selected AAnF a request for Kaf to use in the application session with UE.” … Parag. [0133]; “Operation 4 involves AUSF discovery and selection by the AAF. In operation 4a, the AAnF discovers and selects UDM based on GPSI received from the AF. In operation 4b, the AAnF calls a new service operation Nudm_UEAuthentication_ResultStatus to send a request to the selected UDM with KakmalD and GPSI included with the request . In operation 4c , UDM translates the received GPSI to the corresponding SUPI and uses SUPI to select the AUSF instance based on the information stored during operation 0. UDM verifies that KakmalD received from the AAnF is included in the stored authentication context for the UE. In operation 4d , the UDM returns the SUPI (corresponding to GPSI ) and AUSF ID to the requesting AAnF. The provided SUPI can be used by the AAnF for subsequent key requests for the same UE, as needed or desired.” … Parag. [0158]; “The example method can also include the operations of block 1530, in which the key management server can receive, from an application function, a request for a security key (Kaf) specific to an application session for the particular user, wherein the request comprises a further identifier (KakmaID) of a non-application-specific anchor security key associated with the particular user. The request can include a further identifier (KakmalD) of a non-application-specific anchor security key associated with the particular user.” Examiner submits that the AF needs GPSI to correctly identify the subscriber (i.e., UE) for the application session, and therefore, the AF selects the AAnF in order to receive the security key Kaf specific for the identified subscriber having the corresponding identifier (SUPI/GPSI).).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Tsiatsis to modify 3GPP2020-3GPP-2019 that teaches a method performed by an AKMA anchor function (AAnF) entity in a wireless communication system; to request UE identifier to establish secure communications in 5G networks (see Parag. [0153-0158]).
Regarding claim 27, the combination of 3GPP-2019, 3GPP-2020 and Tsiatsis teaches the AAnF entity of claim 26. 3GPP-2019 teaches:
wherein the response message further includes an expiration time of the AKMA application key (3GPP-2019, Section 6.2-1, [Page 10]; “If KAKMA is available in AAnF (i.e., allowed to obtain the AKMA), it shall derive the AF specific AKMA key (KAF) from KAKMA and respond to the AF with KAF and lifetime”).
Regarding claim 28, the combination of 3GPP-2019, 3GPP-2020 and Tsiatsis teaches the AAnF entity of claim 26. Furthermore, 3GPP-2019 teaches:
wherein the message for requesting the AKMA application key further includes an AKMA key ID related to the UE (3GPP-2019, Section 6.1, [Page 10], “The KAKMA key identifier identifies the KAKMA key of the UE from which other AKMA keys are derived. Editor’s Note: Derivation of KAKMA is FFS. Editor’s Note: Format and derivation of KAKMA key identifier and its association with UE identifier is FFS. Whether the key identifier is generated during the primary authentication or as needed, is FFS.).
Regarding claim 29, the combination of 3GPP-2019, 3GPP-2020 and Tsiatsis teaches the AAnF entity of claim 26. 3GPP-2020 teaches in case that the AF entity is not allowed to obtain the AKMA service from the AAnF entity, rejecting the message for requesting the AKMA application key (3GPP-2020, Section 6.2-1, [Page 11]; “If the AF does not have an active context associated with the key identifier, then the AF sends a request to AAnF with the key identifier to request application function specific AKMA keys for the UE. The AF also includes its identity (AF Id) in the request. The AAnF shall check whether the AAnF can provide the service to the AF by checking the AF Id. If succeeds, the following procedures is executed. Otherwise, the AAnF shall reject the procedure.”).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Salmela et al. (WO 2020007461) relates to mechanisms for establishing authentication and key agreement between a network and a UE. The UE has an Identifier. A method is performed by the UE. The method comprises providing, towards a bootstrapping server function of the network of the UE, a request message with the Identifier of the UE as username, as part of bootstrapping of the UE. The method comprises obtaining, from the bootstrapping server function, a response message to the request message. The response message comprises a challenge, RAND, and an authentication token, AUTN, of an authentication vector, AV. The AV has been generated based on the Identifier. The method comprises verifying the AUTN, thereby authenticating the network, and deriving its own instance of a bootstrapping server function key from a key, K_AUSF, of an AUSF of the network of the UE.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALEX D CARRASQUILLO whose telephone number is (571)270-5045. The examiner can normally be reached Monday - Friday 9:00 am - 6:00 pm.
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, Yin-Chen Shaw can be reached at 571-272-8878. 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.
/A.D.C./Examiner, Art Unit 2498
/YIN CHEN SHAW/Supervisory Patent Examiner, Art Unit 2498
Prosecution Insights