DETAILED ACTION
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 amendment dated on 01/07/2026.
Claims 20-21, and 26-27 has been amended.
Claims 20-23 and 26-29 are submitted for examination.
Claims 20-23 and 26-29 are pending.
Notice of Pre-AIA or AIA Status
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 11/20/2025 and 02/19/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.
Response to Arguments
Applicant’s amendment, filed on January 7, 2026, has claims 20-21 and 26-27 amended. Claims 20 and 26 are independent claims.
Applicant’s remark, filed on January 7, 2026 at page 7, indicates, “Claims 20-23 and 26-29 were rejected under 35 U.S.C. § 112(b) as allegedly being indefinite for failing to particularly point out and distinctly claim the subject matter regarded as the invention. This rejection is respectfully traversed. The claim amendments herein obviate the basis for this rejection. Withdrawal of the § 112(b) rejection is respectfully requested.
Applicant’s arguments have been fully considered and are found persuasive. Accordingly, the claim rejection under 35 U.S.C 112(b) has been withdrawn.
Applicant’s remark, filed on January 7, 2026 at pages 7-9, 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 "in case that the AF entity is allowed to obtain the AKMA service from the AAnF entity and that the AAnF entity determines to provide the AKMA service to the UE ..." Tsiatsis fails to disclose those features. According to Claim 20, the claimed AAnF performs an authorization procedure for AF based on local policy or authorization information, and also performs authorization procedure for UE based on GPSI received from UDM. By sending AKMA application key to UE in a case where AF and the UE are successfully authorized, security procedure for AKMA service can be strengthened. Accordingly, there is an effect of increasing security by deriving KAF to the authorized UE. Tsiatsis fails to disclose that the received GPSI is used to determine whether to provide AKMA service to the UE, or the resulting effect. 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 persuasive, as follows:
Accordingly, 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 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. [0045] and [0153], Tsiatsis clearly describes 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 sending to an application function (AF) a security key (Kaf) and identifier associated to the particular user in order to establish a communication session (See Parag. [0158]). Thus, Examiner submits, that Tsiatsis discloses the amended feature “transmitting, to a unified data management (UDM) entity, a message for requesting a generic public subscription identifier (GPSI) of the UE, in case that the GPSI is needed for the AF entity; and receiving, from the UDM entity, a response including the GPSI”. Finally, Tsiatsis discloses, in 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 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.” Furthermore, in parag. [0133], Tsiatsis teaches that the AAnF discovers and selects UDM based on GPSI received from the AF. 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. UDM verifies that KakmalD received from the AAnF is included in the stored authentication context for the UE. 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 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). Therefore, based on the aforementioned paragraphs, Tsiatsis clearly discloses the amended features, “determining whether to provide the AKMA service to the UE, based on the GPSI" and "in case that the AF entity is allowed to obtain the AKMA service from the AAnF entity and that the AAnF entity determines to provide the AKMA service to the UE …”. Please also refer to the detailed prior-art rejection below.
Under the KSR Int’l Co v Teleflex Inc. rationale for 35 U.S.C. 103, 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. 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.
The combination of prior-art references based on 3GPP-2019, 3GPP-2020 and Tsiatsis would still render the newly amended claim 20 obvious.
Applicant’s remark, filed on January 7, 2026 at pages 7-9, indicates similar arguments for independent claim 26.
Applicant’s argument has been considered. Please refer to the aforementioned response on item 11, 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 further 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 whether 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];
in case that the AF entity is allowed to obtain the AKMA service from the AAnF entity [and that the AAnF entity determines to provide the AKAMA 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 service), 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 whether 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; and
receiving, from the UDM entity, a response including the GPSI;
determine whether to provide the AKMA service to the UE based on the GPSI;
… the AAnF entity determines to provide the AKAMA service to the UE
However, 3GPP-2020 teaches:
checking whether 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; and
receiving, from the UDM entity, a response including the GPSI;
determine whether to provide the AKMA service to the UE based on the GPSI;
… the AAnF entity determines to provide the AKAMA 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. In operation 4e, the AAnF discovers and selects AUSF based on the AUSF ID received from the UDM.” … 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).);
… the AAnF entity determines to provide the AKAMA 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. [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 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 teaches 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 whether 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];
[receiving, from the UDM entity, a response including the GPSI];
[determine whether to provide the AKMA service to the UE based on the GPSI];
in case that the AF entity is allowed to obtain the AKMA service from the AAnF entity [and that the AAnF entity determines to provide the AKAMA 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 and configured to:
check whether 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;
receiving, from the UDM entity, a response including the GPSI;
determine whether to provide the AKMA service to the UE based on the GPSI;
… the AAnF entity determines to provide the AKAMA service to the UE.
However, 3GPP-2020 teaches:
check whether 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 and configured to:
transmit, 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;
… the AAnF entity determines to provide the AKAMA 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. [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).);
… the AAnF entity determines to provide the AKAMA 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. [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 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 teach 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. Furthermore, 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.
Ben Henda et al. (US 2020/0084676) relates to a method for handling change of serving Access and Mobility Managing Function for a user equipment. The method comprises sending of a context request to a source Access and Mobility Managing Function. This sending is performed from a target Access and Mobility Managing Function. In the target Access and Mobility Managing Function, a context is received in reply from the source Access and Mobility Managing Function. The context comprises a parameter which identifies a Security Anchor Function Access and Mobility Managing Function. The Security Anchor Function Access and Mobility Managing Function keeps a key, which is shared with the user equipment.
Qiao et al. (US 2019/0150081) relates to a radio access network (RAN) receives a first registration request from a wireless device. The RAN sends a first message to a network repository function in response to receiving the first registration request. The first message comprises at least one single network slice selection assistance information of at least one network slice. The first message comprises network slice isolation information for the at least one single network slice selection assistance information. The network repository function selects an access and mobility management function based on the network slice isolation information. The RAN receives a second message from the network repository function. The second message comprises an Internet protocol address of the access and mobility management function. The RAN sends a second message to the access and mobility management function. The second registration request may be for the first registration request.
Accordingly, 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 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