Prosecution Insights
Last updated: April 19, 2026
Application No. 17/320,737

KEY MATERIAL GENERATION OPTIMIZATION FOR AUTHENTICATION AND KEY MANAGEMENT FOR APPLICATIONS

Non-Final OA §102§103§DP
Filed
May 14, 2021
Examiner
NGUY, CHI D
Art Unit
2435
Tech Center
2400 — Computer Networks
Assignee
Telefonaktiebolaget Lm Ericsson (Publ)
OA Round
3 (Non-Final)
75%
Grant Probability
Favorable
3-4
OA Rounds
3y 7m
To Grant
91%
With Interview

Examiner Intelligence

Grants 75% — above average
75%
Career Allow Rate
376 granted / 501 resolved
+17.0% vs TC avg
Strong +16% interview lift
Without
With
+16.0%
Interview Lift
resolved cases with interview
Typical timeline
3y 7m
Avg Prosecution
22 currently pending
Career history
523
Total Applications
across all art units

Statute-Specific Performance

§101
8.2%
-31.8% vs TC avg
§103
51.9%
+11.9% vs TC avg
§102
18.9%
-21.1% vs TC avg
§112
11.1%
-28.9% vs TC avg
Black line = Tech Center average estimate • Based on career data from 501 resolved cases

Office Action

§102 §103 §DP
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 . 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 11/18/2025 has been entered. Claims 1-3, 5-15, 17-24, 26-36 and 38-42 are pending. Response to Arguments Applicant's arguments filed 11/18/2025 have been fully considered but they are not persuasive. On pages 13-14 of the Remarks, the Applicants argue that You does not disclose, teach or suggest "based on subscription information associated with the wireless device, generating a second message comprising an authentication response message, the second message including an Authentication and Key Management for Applications, AKMA, key indicator, wherein the AKMA key indicator comprises a AKMA key material generation flag to trigger the wireless device to generate AKMA key material," as recited in amended Claim 1. In response, the Examiner respectfully disagrees and submits that You discloses a system and/or a method for key generation for encrypted communication between a terminal device and a service application in a communication network. You discloses that a Universal Data Management (UDM) forms a permanent storage or database for user contract and subscription data and includes an authentication credential repository and processing function (ARPF) for storage of long-term security credentials for user authentication, and for using such long-term security credentials as input to perform computation of encryption keys (page 7, paragraph “Continuing with FIG. 3, the UDM…”). You further discloses that a (AUSF) receives a user authentication request, and communicates to the UDM to authenticate and obtain a return message comprising (1) user contract/subscription information which indicates whether the terminal device subscribes to the AKMA service or not and/or (2) authentication vector which indicates the user is authenticated or not. The user contract/subscription information and the successful authentication vector indicates to the terminal device and the AUSF that the terminal device is subscribed to the AKMA service and allows or triggers the terminal device and the AUSF to a key KAUSF which is a based bey to trigger generating an anchor key KAKMA and an identifier for the anchor key KAKMA (page 12, line 8-page 13, lines 4, page 17, line 25-page 18, line 14, page 19, lines 3-17), thus, You at least discloses the claimed “based on subscription information associated with the wireless device, generating a second message comprising an authentication response message, the second message including an Authentication and Key Management for Applications, AKMA, key indicator” wherein the user contract/subscription information and/or the successful authentication vector corresponds to the claimed “an Authentication and Key Management for Applications, AKMA, key indicator”. You further discloses that the authentication vector from the UDM includes an authentication token (AUTN), a random number (RAND), and/or various authentication keys, and the AKMA service subscription information include identifiers for one or more AAnFs and/or validity time period of the AKMA anchor key, wherein the terminal device and the AUSF generate the anchor key KAKMA and or the identifier of the anchor key not only using the KAUSF but also the RAND and identifier of the AAnF included in user contract/subscription information and authentication vector returned from the UDM (page 19, line 18-page 20, line 21). Thus at least the RAND, identifier of the AAnF and/or the validity time period of the AKMA are interpreted as the AKMA key material generation flag to trigger the terminal and the AUSF to generate the anchor key KAKMA for a particular AAnF and/or for a particular time. As such, You clearly discloses the claimed “based on subscription information associated with the wireless device, generating a second message comprising an authentication response message, the second message including an Authentication and Key Management for Applications, AKMA, key indicator, wherein the AKMA key indicator comprises a AKMA key material generation flag.” Therefore, the Applicant’s argument is not persuasive. Double Patenting The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969). A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b). The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp. Claims 1, 9-11, 22, and 30-32 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-9 of U.S. Patent No. 11,051,161. Although the claims at issue are not identical, they are not patentably distinct from each other because the limitations recited in the claims 1, 9-11, 22, and 30-32 are anticipated by the limitations recited in the claims 1-9 of the U.S. Patent No. 11,051,161. Claim Rejections - 35 USC § 102 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. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action: A person shall be entitled to a patent unless – (a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention. Claims 1-3, 5, 7-10, 12-14, 17-19, 21-24, 26, 28-31, 33-35, 38-40 and 42 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by You et al. (WO 2021/093164 A1 hereinafter You). Regarding claim 1, You discloses a method performed by a network node operating as a Unified Data Management, UDM, node, the method comprising: receiving a first message associated with an authentication request message of a wireless device (FIG. 3-5, p. 9, lines 1-5 “…the UE 310 may first communicate with AMF/SEAF 330 for network registration and may then be authenticated by the AUSF 360 according to user contract and subscription data in the UDM/ARPF 370”, p. 12, lines 12-28 “…The user authentication procedure 402…Upon successful authentication, an authentication vector may be generated by the UDM/ARPF 370 and such authentication vector may be transmitted to the AUSF 360”, p. 18, last lines “…the AUSF 360 initiates a user authentication request message…to the UDM/ARFP 370”; i.e. the UDM/ARPF receives a UE authentication request from the AUSF); based on subscription information associated with the wireless device, generating a second message comprising an authentication response message, the second message including an Authentication and Key Management for Applications, AKMA, key indicator, wherein the AKMA key indicator comprises a AKMA key material generation flag to trigger the wireless device to generate AKMA key material (FIG. 3-5 & 8, p. 9, lines 1-5 “…the UE 310 may first communicate with AMF/SEAF 330 for network registration and may then be authenticated by the AUSF 360 according to user contract and subscription data in the UDM/ARPF 370”, p. 12, lines 12-28 “…The user authentication procedure 402…Upon successful authentication, an authentication vector may be generated by the UDM/ARPF 370 and such authentication vector may be transmitted to the AUSF 360. Following successful user authentication procedure 402, a base key may be generated at both the UE 310 side and the AUSF 360…an anchor key may be derived based on the base key KAUSF…Such an anchor key, may be referred to as KAKMA”, p. 19, line 3-p. 20, line 9 “The authentication vector generated by the UDM/ARPF 370 and included in the return message may include, for example, an authentication token (AUTN), a random number (RAND)…The AKM service subscription information for the UE may include, for example, identifiers for one or more AAnFs…Specifically, in Step 806, after the UE main authentication logic flow 850 is successful, the UE 310 and the AUSF 360 may generate the AKMA anchor key KAKMA = KDF (KAUSF, AKMA Type, RAND, SUPI, AAnF identifier)…”; i.e. the UDM/ARPF authenticates the UE based on the subscription data and generates a return message to send to the AUSF, wherein the return message includes the subscription information and the successful authentication vector that indicates to the UE and the AUSF to generate the keys KAUSF, KAKMA, identifier of the KAKMA, at least using the AKMA key material information or flag such as the AAnF identifier in the subscription information and the RAND in the authentication vector); and transmitting the second message comprising the authentication response message to trigger the wireless device to generate the AKMA key material (FIG. 3-5 & 8, p. 12, lines 12-28, p. 18, lines 11-14 “…Upon successful UE registration and authentication…the UE 310 may also derive the AKMA anchor key based on the AKMA service subscription information…”; i.e. the UDM/ARPF sends the authentication success to the AUSF to enable the UE and the AUSF generating the base key and/or the anchor key). Regarding claim 2, You discloses the method of Claim 1, wherein the first message initiates an authentication procedure of a wireless device with a network (FIG. 3-5, p. 9, lines 1-5). Regarding claim 3, You discloses the method of Claim 2, wherein the authentication procedure comprises a primary authentication procedure of the wireless device (FIG. 3-5, p. 9, lines 1-5, p. 19, lines 15-20). Regarding claim 5, You discloses the method of Claim 1, wherein the AKMA key material comprises an Authentication and Key Management for Applications anchor key, KAKMA (FIG. 4-5, p. 12, lines 12-28, p. 18, lines 11-14). Regarding claim 7, You discloses the method of Claim 1, wherein: the first message is received from a second network node operating as an Authentication Server Function, AUSF, and the second message is sent to the second network node operating as the AUSF (FIG. 3-5, p. 9, lines 1-5, p. 12, lines 12-28). Regarding claim 8, You discloses the method of Claim 1, further comprising: prior to receiving the first message from the wireless device, receiving a third message from a Network Function (NF), the third message comprising the subscription information associated with the wireless device (FIG. 7, p. 9-12; i.e. the UDM receives subscription information from AF, AMF/SEAF, etc.). Regarding claim 9, You discloses a method performed by a first network node operating as an Authentication Server Function, AUSF, the method comprising: determining whether a first message received from a second network node includes an Authentication and Key Management for Applications, AKMA, key indicator, wherein the AKMA key indicator comprises a AKMA key material generation flag (FIG. 3-5 & 8, p. 19, line 3-p. 20, line 9 “The authentication vector generated by the UDM/ARPF 370 and included in the return message may include, for example, an authentication token (AUTN), a random number (RAND)…The AKM service subscription information for the UE may include, for example, identifiers for one or more AAnFs…the AUSF 360 verifies the authentication vector sent from the UDM/ARPF…Specifically, in Step 806, after the UE main authentication logic flow 850 is successful, the UE 310 and the AUSF 360 may generate the AKMA anchor key KAKMA = KDF (KAUSF, AKMA Type, RAND, SUPI, AAnF identifier)…”; i.e. the AUSF verifies the return message, wherein the return message includes the subscription information and the successful authentication vector that indicates to the UE and the AUSF to generate the keys KAUSF, KAKMA, identifier of the KAKMA, at least using the AKMA key material information or flag such as the AAnF identifier in the subscription information and the RAND in the authentication vector); and based on whether the first message includes the AKMA indicator, determining whether to generate AKMA key material (FIG. 3-5 & 8, p. 19, lines 18-28, p. 20, lines 1-16; i.e. based on verifying the authentication vector including the AKMA information, generating the AKMA anchor key). Regarding claim 10, You discloses the method of Claim 9, wherein: determining whether the first message comprises the AKMA key indicator comprises determining that the first message comprises the AKMA key indicator (FIG. 3-5 & 8, p. 19, lines 18-28; and the method further comprises generating the AKMA key material based on the AKMA key indicator in the first message (FIG. 3-5 & 8, p. 19, lines 18-28, p. 20, lines 1-16). Regarding claim 12, You discloses the method of Claim 9, wherein the second network node comprises a Unified Data Management, UDM, node (FIG. 3-5 & 8, p. 19, lines 9-28). Regarding claim 13, You discloses the method of Claim 9, further comprising transmitting a second message comprising the AKMA key indicator to a wireless device to trigger the wireless device to generate the AKMA key material (FIG. 3-5 & 8, p. 19, lines 18-28, p. 20, lines 1-16). Regarding claim 14, You discloses the method of Claim 9, wherein the AKMA key material comprises an Authentication and Key Management for Applications Anchor Key, KAKMA (FIG. 3-5 & 8, p. 19, lines 18-28, p. 20, lines 1-16). Regarding claim 17, You discloses a method performed by a wireless device, the method comprising: in response to determining a need to initiate a communication session with an Application Function, AF, generating an Authentication and Key Management for Applications Anchor Key, KAKMA (FIG. 3-6, p. 13, lines 23-28, p. 14, lines 1-6; i.e. the UE determines to initiate a communication session with the AF and generating a communication request that includes the KID associated with the anchor key KAKMA); transmitting, to the AF, a request to initiate the communication session (FIG. 3-6, p. 14, lines 1-4; i.e. the UE initiates a communication session with the AF by sending a communication request message); and receiving an authentication response message comprising an Authentication and Key Management for Applications, AKMA, key indicator, wherein the AKMA key indicator comprises a AKMA key material generation flag to trigger the wireless device to generate AKMA key material (FIG. 3-5 & 8, p. 9, lines 1-5 “…the UE 310 may first communicate with AMF/SEAF 330 for network registration and may then be authenticated by the AUSF 360 according to user contract and subscription data in the UDM/ARPF 370”, p. 12, lines 12-28 “…The user authentication procedure 402…Upon successful authentication, an authentication vector may be generated by the UDM/ARPF 370 and such authentication vector may be transmitted to the AUSF 360. Following successful user authentication procedure 402, a base key may be generated at both the UE 310 side and the AUSF 360…an anchor key may be derived based on the base key KAUSF…Such an anchor key, may be referred to as KAKMA”, p. 19, line 3-p. 20, line 9 “The authentication vector generated by the UDM/ARPF 370 and included in the return message may include, for example, an authentication token (AUTN), a random number (RAND)…The AKM service subscription information for the UE may include, for example, identifiers for one or more AAnFs…Specifically, in Step 806, after the UE main authentication logic flow 850 is successful, the UE 310 and the AUSF 360 may generate the AKMA anchor key KAKMA = KDF (KAUSF, AKMA Type, RAND, SUPI, AAnF identifier)…”; i.e. the UE is authenticated based on the subscription data successfully and receives a return message, wherein the return message includes the subscription information and the successful authentication vector that indicates to the UE and the AUSF to generate the keys KAUSF, KAKMA, identifier of the KAKMA, at least using the AKMA key material information or flag such as the AAnF identifier in the subscription information and the RAND in the authentication vector. Regarding claim 18, You discloses the method of Claim 17, wherein the need to initiate the communication session with the AF is determined after a performance of a primary authentication procedure with a network (FIG. 6 & 9-12, p. 13, lines 23-28, p. 14, lines 1-6). Regarding claim 19, You discloses the method of Claim 18, further comprising, during the performance of the primary authentication procedure, generating a root key, KAUSF (FIG. 3-6, p. 13, lines 2-8; i.e. generating the base key KAUSF). Regarding claim 21, You discloses the method of Claim 17, further comprising determining to generate a KAKMA based on subscription information stored in or at the wireless device (FIG. 3-5, 8, p. 18, lines 12-14). Regarding claim 22, You discloses a network node operating as a Unified Data Management, UDM, node, the network node comprising: processing circuitry configured to (FIG. 3-4, p. 2, lines 17-25): receive a first message associated with an authentication request message of a wireless device (FIG. 3-5, p. 9, lines 1-5 “…the UE 310 may first communicate with AMF/SEAF 330 for network registration and may then be authenticated by the AUSF 360 according to user contract and subscription data in the UDM/ARPF 370”, p. 12, lines 12-28 “…The user authentication procedure 402…Upon successful authentication, an authentication vector may be generated by the UDM/ARPF 370 and such authentication vector may be transmitted to the AUSF 360”, p. 18, last lines “…the AUSF 360 initiates a user authentication request message…to the UDM/ARFP 370”; i.e. the UDM/ARPF receives a UE authentication request from the AUSF); based on subscription information associated with the wireless device, generate a second message comprising an authentication response message, the second message including an Authentication and Key Management for Applications, AKMA, key indicator, wherein the AKMA key indicator comprises a AKMA key material generation flag to trigger the wireless device to generate AKMA key material (FIG. 3-5 & 8, p. 9, lines 1-5 “…the UE 310 may first communicate with AMF/SEAF 330 for network registration and may then be authenticated by the AUSF 360 according to user contract and subscription data in the UDM/ARPF 370”, p. 12, lines 12-28 “…The user authentication procedure 402…Upon successful authentication, an authentication vector may be generated by the UDM/ARPF 370 and such authentication vector may be transmitted to the AUSF 360. Following successful user authentication procedure 402, a base key may be generated at both the UE 310 side and the AUSF 360…an anchor key may be derived based on the base key KAUSF…Such an anchor key, may be referred to as KAKMA”, p. 19, line 3-p. 20, line 9 “The authentication vector generated by the UDM/ARPF 370 and included in the return message may include, for example, an authentication token (AUTN), a random number (RAND)…The AKM service subscription information for the UE may include, for example, identifiers for one or more AAnFs…Specifically, in Step 806, after the UE main authentication logic flow 850 is successful, the UE 310 and the AUSF 360 may generate the AKMA anchor key KAKMA = KDF (KAUSF, AKMA Type, RAND, SUPI, AAnF identifier)…”; i.e. the UDM/ARPF authenticates the UE based on the subscription data and generates a return message to send to the AUSF, wherein the return message includes the subscription information and the successful authentication vector that indicates to the UE and the AUSF to generate the keys KAUSF, KAKMA, identifier of the KAKMA, at least using the AKMA key material information or flag such as the AAnF identifier in the subscription information and the RAND in the authentication vector); and transmit the second message comprising the authentication response message to trigger the wireless device to generate the AKMA key material (FIG. 3-5 & 8, p. 12, lines 12-28, p. 18, lines 11-14 “…Upon successful UE registration and authentication…the UE 310 may also derive the AKMA anchor key based on the AKMA service subscription information…”; i.e. the UDM/ARPF sends the authentication success to the AUSF to enable the UE and the AUSF generating the base key and/or the anchor key). Regarding claim 23, You discloses the network node of Claim 22, wherein the first message initiates an authentication procedure of a wireless device with a network (FIG. 3-5, p. 9, lines 1-5). Regarding claim 24, You discloses the network node of Claim 23, wherein the authentication procedure comprises a primary authentication procedure of the wireless device (FIG. 3-5, p. 9, lines 1-5, p. 19, lines 15-20). Regarding claim 26, You discloses the network node of Claim 22, wherein the AKMA key material comprises an Authentication and Key Management for Applications anchor key, KAKMA (FIG. 4-5, p. 12, lines 12-28, p. 18, lines 11-14). Regarding claim 28, You discloses the network node of Claim 22, wherein: the first message is received from a second network node operating as an Authentication Server Function, AUSF, and the second message is sent to the second network node operating as the AUSF (FIG. 3-5, p. 9, lines 1-5, p. 12, lines 12-28). Regarding claim 29, You discloses the network node of Claim 22, wherein the processing circuitry is configured to: prior to receiving the first message from the wireless device, receiving a third message from a NF, the third message comprising the subscription information associated with the wireless device (FIG. 7, p. 9-12; i.e. the UDM receives subscription information from AF, AMF/SEAF, etc.). Regarding claim 30, You discloses a first network node operating as an Authentication Server Function, AUSF, the first network node comprising: processing circuitry configured to (FIG. 3-4, p. 2, lines 17-25): determine whether a first message received from a second network node includes an Authentication and Key Management for Applications, AKMA, key indicator, wherein the AKMA key indicator comprises a AKMA key material generation flag (FIG. 3-5 & 8, p. 19, line 3-p. 20, line 9 “The authentication vector generated by the UDM/ARPF 370 and included in the return message may include, for example, an authentication token (AUTN), a random number (RAND)…The AKM service subscription information for the UE may include, for example, identifiers for one or more AAnFs…the AUSF 360 verifies the authentication vector sent from the UDM/ARPF…Specifically, in Step 806, after the UE main authentication logic flow 850 is successful, the UE 310 and the AUSF 360 may generate the AKMA anchor key KAKMA = KDF (KAUSF, AKMA Type, RAND, SUPI, AAnF identifier)…”; i.e. the AUSF verifies the return message, wherein the return message includes the subscription information and the successful authentication vector that indicates to the UE and the AUSF to generate the keys KAUSF, KAKMA, identifier of the KAKMA, at least using the AKMA key material information or flag such as the AAnF identifier in the subscription information and the RAND in the authentication vector); and based on whether the first message includes the AKMA indicator, determine whether to generate AKMA key material (FIG. 3-5 & 8, p. 19, lines 18-28, p. 20, lines 1-16; i.e. based on verifying the authentication vector including the AKMA information, generating the AKMA anchor key). Regarding claim 31, You discloses the first network node of Claim 30, wherein when the processing circuitry determines that the first message includes the AKMA key indicator, the processing circuitry is further configured to generate the AKMA key material (FIG. 3-5 & 8, p. 19, lines 18-28, p. 20, lines 1-16). Regarding claim 33, You discloses the first network node of Claim 30, wherein the second network node comprises a Unified Data Management, UDM, node (FIG. 3-5 & 8, p. 19, lines 9-28). Regarding claim 34, You discloses the first network node of Claim 30, wherein the processing circuitry is configured to transmit a second message comprising the AKMA key indicator to a wireless device to trigger the wireless device to generate the AKMA key material (FIG. 3-5 & 8, p. 19, lines 18-28, p. 20, lines 1-16). Regarding claim 35, You discloses the first network node of Claim 30, wherein the AKMA key material comprises an Authentication and Key Management for Applications Anchor Key, KAKMA (FIG. 3-5 & 8, p. 19, lines 18-28, p. 20, lines 1-16). Regarding claim 38, You discloses a wireless device comprising: processing circuitry configured to(FIG. 3-4, p. 2, lines 17-25): in response to determining a need to initiate a communication session with an Application Function, AF, generate an Authentication and Key Management for Applications Anchor Key, KAKMA (FIG. 3-6, p. 13, lines 23-28, p. 14, lines 1-6; i.e. the UE determines to initiate a communication session with the AF and generating a communication request that includes the KID associated with the anchor key KAKMA); transmit, to the AF, a request to initiate the communication session (FIG. 3-6, p. 14, lines 1-4; i.e. the UE initiates a communication session with the AF by sending a communication request message); and receiving an authentication response message comprising an Authentication and Key Management for Applications, AKMA, key indicator, wherein the AKMA key indicator comprises a AKMA key material generation flag to trigger the wireless device to generate AKMA key material (FIG. 3-5 & 8, p. 9, lines 1-5 “…the UE 310 may first communicate with AMF/SEAF 330 for network registration and may then be authenticated by the AUSF 360 according to user contract and subscription data in the UDM/ARPF 370”, p. 12, lines 12-28 “…The user authentication procedure 402…Upon successful authentication, an authentication vector may be generated by the UDM/ARPF 370 and such authentication vector may be transmitted to the AUSF 360. Following successful user authentication procedure 402, a base key may be generated at both the UE 310 side and the AUSF 360…an anchor key may be derived based on the base key KAUSF…Such an anchor key, may be referred to as KAKMA”, p. 19, line 3-p. 20, line 9 “The authentication vector generated by the UDM/ARPF 370 and included in the return message may include, for example, an authentication token (AUTN), a random number (RAND)…The AKM service subscription information for the UE may include, for example, identifiers for one or more AAnFs…Specifically, in Step 806, after the UE main authentication logic flow 850 is successful, the UE 310 and the AUSF 360 may generate the AKMA anchor key KAKMA = KDF (KAUSF, AKMA Type, RAND, SUPI, AAnF identifier)…”; i.e. the UE is authenticated based on the subscription data successfully and receives a return message, wherein the return message includes the subscription information and the successful authentication vector that indicates to the UE and the AUSF to generate the keys KAUSF, KAKMA, identifier of the KAKMA, at least using the AKMA key material information or flag such as the AAnF identifier in the subscription information and the RAND in the authentication vector. Regarding claim 39, You discloses the wireless device of Claim 38, wherein the need to initiate the communication session with the AF is determined after a performance of a primary authentication procedure with a network (FIG. 6 & 9-12, p. 13, lines 23-28, p. 14, lines 1-6). Regarding claim 40, You discloses the wireless device of Claim 39, wherein, during the performance of the primary authentication procedure, the processing circuitry is configured to generate a root key, KAUSF (FIG. 3-6, p. 13, lines 2-8; i.e. generating the base key KAUSF). Regarding claim 42, You discloses the wireless device of Claim 38, wherein the processing circuitry is configured to determine to generate a KAKMA based on subscription information stored in or at the wireless device (FIG. 3-5, 8, p. 18, lines 12-14). Claim Rejections - 35 USC § 103 The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. Claims 6, 11, 15, 20, 27, 32, 36 and 41 are rejected under 35 U.S.C. 103 as being unpatentable over You et al. (WO 2021/093164 A1 hereinafter You) in view of Deng et al. (US 2022/0377540 hereinafter Deng). Regarding claim 6, You discloses the method of Claim 5, wherein the AKMA key material comprises a KAKMA Identifier, KAKMAID, and wherein the KAKMA [[and the KAKMAID]] are derived based on a KAUSF (FIG. 8, p. 20, lines 6-19, Examiner note: KAKMAID is interpreted as the abbreviation of KAKMA Identifier according to the specification). You does not explicitly disclose the KAKMAID is derived based on the KAUSF. However, Deng discloses the KAKMAID is derived based on the KAUSF (¶ [0007], [0126]-[0129]). Therefore, it would have been obvious to one of ordinary skill in the art before effective filing date of the claimed invention to incorporate Deng‘s teaching into You in order to allow key negotiation between the user equipment and the Application Function (Deng, ¶ [0003]-[0005]). Regarding claim 11, You discloses the method of Claim 9. You does not explicitly disclose wherein: determining whether the first message comprises the AKMA key indicator comprises determining that the first message does not include the AKMA key indicator; and the method further comprises determining not to generate the AKMA key material for the authentication procedure with the network based on the first message not including the AKMA key indicator. However, Deng discloses wherein: determining whether the first message comprises the AKMA key indicator comprises determining that the first message does not include the AKMA key indicator; and the method further comprises determining not to generate the AKMA key material for the authentication procedure with the network based on the first message not including the AKMA key indicator (¶ [0017], [0152]). Therefore, it would have been obvious to one of ordinary skill in the art before effective filing date of the claimed invention to incorporate Deng‘s teaching into You in order to allow key negotiation between the user equipment and the Application Function (Deng, ¶ [0003]-[0005]). Regarding claim 15, You discloses the method of Claim 14, wherein: the AKMA key material comprises a KAKMA Identifier, KAKMAID, associated with a wireless device, and the KAKMA [[and the KAKMAID]] are derived based on a KAUSF (FIG. 8, p. 20, lines 6-19, Examiner note: KAKMAID is interpreted as the abbreviation of KAKMA Identifier according to the specification). You does not explicitly disclose the KAKMAID is derived based on the KAUSF. However, Deng discloses the KAKMAID is derived based on the KAUSF (¶ [0007], [0126]-[0129]). Therefore, it would have been obvious to one of ordinary skill in the art before effective filing date of the claimed invention to incorporate Deng‘s teaching into You in order to allow key negotiation between the user equipment and the Application Function (Deng, ¶ [0003]-[0005]). Regarding claim 20, You discloses the method of Claim 19, further comprising generating the KAKMA [[and a KAKMA Identifier, KAKMAID,]] based on the KAUSF (FIG. 8, p. 20, lines 6-19, Examiner note: KAKMAID is interpreted as the abbreviation of KAKMA Identifier according to the specification). You does not explicitly disclose the KAKMAID is derived based on the KAUSF. However, Deng discloses the KAKMAID is derived based on the KAUSF (¶ [0007], [0126]-[0129]). Therefore, it would have been obvious to one of ordinary skill in the art before effective filing date of the claimed invention to incorporate Deng‘s teaching into You in order to allow key negotiation between the user equipment and the Application Function (Deng, ¶ [0003]-[0005]). Regarding claim 27, You discloses the network node of Claim 26, wherein the AKMA key material comprises a KAKMA Identifier, KAKMAID, and wherein the KAKMA [[and the KAKMAID]] are derived based on a KAUSF (FIG. 8, p. 20, lines 6-19, Examiner note: KAKMAID is interpreted as the abbreviation of KAKMA Identifier according to the specification). You does not explicitly disclose the KAKMAID is derived based on the KAUSF. However, Deng discloses the KAKMAID is derived based on the KAUSF (¶ [0007], [0126]-[0129]). Therefore, it would have been obvious to one of ordinary skill in the art before effective filing date of the claimed invention to incorporate Deng‘s teaching into You in order to allow key negotiation between the user equipment and the Application Function (Deng, ¶ [0003]-[0005]). Regarding claim 32, You discloses the first network node of Claim 31. You does not explicitly disclose wherein when the processing circuitry determines that the first message does not include the AKMA key indicator, the processing circuitry is further configured to determine not to generate the AKMA key material for the authentication procedure with the network. However, Deng discloses determining wherein when the processing circuitry determines that the first message does not include the AKMA key indicator, the processing circuitry is further configured to determine not to generate the AKMA key material for the authentication procedure with the network (¶ [0017], [0152]). Therefore, it would have been obvious to one of ordinary skill in the art before effective filing date of the claimed invention to incorporate Deng‘s teaching into You in order to allow key negotiation between the user equipment and the Application Function (Deng, ¶ [0003]-[0005]). Regarding claim 36, You discloses the first network node of Claim 35, wherein: the AKMA key material comprises a KAKMA Identifier, KAKMAID, associated with a wireless device, and the KAKMA [[and the KAKMAID]] are derived based on the KAUSF (FIG. 8, p. 20, lines 6-19, Examiner note: KAKMAID is interpreted as the abbreviation of KAKMA Identifier according to the specification). You does not explicitly disclose the KAKMAID is derived based on the KAUSF. However, Deng discloses the KAKMAID is derived based on the KAUSF (¶ [0007], [0126]-[0129]). Therefore, it would have been obvious to one of ordinary skill in the art before effective filing date of the claimed invention to incorporate Deng‘s teaching into You in order to allow key negotiation between the user equipment and the Application Function (Deng, ¶ [0003]-[0005]). Regarding claim 41, You discloses the wireless device of Claim 40, wherein the processing circuitry is configured to generate the KAKMA [[and a KAKMA Identifier, KAKMAID,]] based on the KAUSF (FIG. 8, p. 20, lines 6-19, Examiner note: KAKMAID is interpreted as the abbreviation of KAKMA Identifier according to the specification). You does not explicitly disclose the KAKMAID is derived based on the KAUSF. However, Deng discloses the KAKMAID is derived based on the KAUSF (¶ [0007], [0126]-[0129]). Therefore, it would have been obvious to one of ordinary skill in the art before effective filing date of the claimed invention to incorporate Deng‘s teaching into You in order to allow key negotiation between the user equipment and the Application Function (Deng, ¶ [0003]-[0005]). Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHI D NGUY whose telephone number is (571)270-7311. The examiner can normally be reached Monday-Friday 9-5 ET. 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, Joseph P Hirl can be reached on (571)272-3685. 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. /C.D.N/Examiner, Art Unit 2435 /AMIR MEHRMANESH/Supervisory Patent Examiner, Art Unit 2491
Read full office action

Prosecution Timeline

May 14, 2021
Application Filed
Feb 02, 2023
Non-Final Rejection — §102, §103, §DP
May 09, 2023
Response Filed
Aug 30, 2023
Final Rejection — §102, §103, §DP
Dec 11, 2023
Notice of Allowance
Feb 12, 2024
Response after Non-Final Action
Feb 16, 2024
Response after Non-Final Action
May 09, 2024
Response after Non-Final Action
Aug 21, 2024
Response after Non-Final Action
Aug 22, 2024
Response after Non-Final Action
Aug 22, 2024
Response after Non-Final Action
Sep 17, 2025
Response after Non-Final Action
Nov 18, 2025
Request for Continued Examination
Nov 22, 2025
Response after Non-Final Action
Feb 04, 2026
Non-Final Rejection — §102, §103, §DP (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12598206
DETERMINING EXPLOIT PREVENTION USING MACHINE LEARNING
2y 5m to grant Granted Apr 07, 2026
Patent 12596775
SYSTEM AND METHODS FOR PAIRING EXTERNAL DEVICES TO VIRTUAL REALITY DEVICES
2y 5m to grant Granted Apr 07, 2026
Patent 12574730
METHOD AND SYSTEM FOR ACCESS AND COMMUNICATION CONTROL OF SIM-LESS END DEVICES
2y 5m to grant Granted Mar 10, 2026
Patent 12563395
ACCESSING A DENIED NETWORK RESOURCE
2y 5m to grant Granted Feb 24, 2026
Patent 12561481
DATA SHARING SYSTEM, METHOD AND APPARATUS, AND DEVICE AND MEDIUM
2y 5m to grant Granted Feb 24, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

3-4
Expected OA Rounds
75%
Grant Probability
91%
With Interview (+16.0%)
3y 7m
Median Time to Grant
High
PTA Risk
Based on 501 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month