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 .
Detail Action
This office action is response to the application 19/210,025 filed on 05/16/2025. Claims 1-20 are pending in this communication.
Priority
This application claims priority from CHINA 202211436707.8 11/16/2022. Priority date has been accepted.
Examiner’s Note
The examiner is requesting the applicant’s representative to provide direct phone number and/or mobile phone number in next communication, which will be very helpful to advance the prosecution.
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)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention. OR
(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-7 and 9-19 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by KIM; Anbin et al. (US 2026/0025656 A1).
Regarding Claim 1, KIM anticipated a communication method, comprising:
receiving, by a visited authentication and key management for applications anchor function network element {ABSTRACT}, an application key get request message including a key identifier which is associated with a subscriber permanent identifier of a terminal device from a visited application function network element {Fig. 7 & [0012], “the authentication response message may include an AKMA anchor key and an A-KID (AKMA key Identifier)indicating the AKMA anchor key, and the AMF may perform a procedure of registering the AKMA anchor key in an AKMA anchor function (AAnF) based on the SUPI (subscriber permanent identifier), the AKMA anchor key and the A-KID”}, wherein the application key get request message is used to request to obtain a root key, and the root key is used to protect communication data between the visited application function network element and the terminal device {[0013], “generating an AKMA anchor key and an A-KID indicating the AKMA anchor key based on a network root key, and completing authentication for a network” … [0133], “FIG. 10 is a view showing a method for establishing an application session”};
obtaining, by the visited authentication and key management for applications anchor function network element, a verification result of the subscriber permanent identifier {[0128], “the terminal 710 may generate a RES* value based on a key held by it and transmit an authentication response including RES* to the SEAF 720. The SEAF 720 may calculate HRES* based on RES* and compare HRES* with the above-described HXRES*. If the two values are identical, the SEAF 720 may determine success of authentication and transmit an authentication response including RES* to the AUSF 730”. Examiner’s note: Fig. 7 step 12 demonstrates authentication result based on SUPI}; and
when verification on the subscriber permanent identifier succeeds, sending, by the visited authentication and key management for applications anchor function network element, the root key to the visited application function network element {[0130], “after primary authentication of the terminal is successful based on an AKMA system, KAUSF may be generated. Referring to FIG. 9, in each of a network (AUSF) and a terminal, KAKMA may be generated as a root key that may be used to generate an application key later, and an A-KID capable of indicating KAKMA may also be generated together”. Examiner’s note: a root key is generated and used to generate an application key}.
Regarding Claim 2, KIM anticipates all the features of claim 1 and KIM further anticipates
when the visited authentication and key management for applications anchor function network element receives the subscriber permanent identifier from a visited access and mobility management function network element, determining, by the visited authentication and key management for applications anchor function network element, that the verification on the subscriber permanent identifier succeeds {[0130], “after primary authentication of the terminal is successful based on an AKMA system, KAUSF may be generated. Referring to FIG. 9, in each of a network (AUSF) and a terminal, KAKMA may be generated as a root key that may be used to generate an application key later, and an A-KID capable of indicating KAKMA may also be generated together”. Examiner’s note: a root key is generated and used to generate an application key}.
Regarding Claim 3, KIM anticipates all the features of claim 1 and KIM further anticipates
obtaining, by the visited authentication and key management for applications anchor function network element, the subscriber permanent identifier corresponding to the key identifier {[0121], “in case there is a valid 5G-GUTI and a terminal is reauthenticated, the SEAF 520 may transmit an authentication request message including a SUPI. After receiving the authentication request message, the AUSF 530 may check whether the SEAF 520 in a serving network is qualified to use a serving network name”};
sending, by the visited authentication and key management for applications anchor function network element, a verification request message to a visited access and mobility management function network element, wherein the verification request message comprises the subscriber permanent identifier, and the verification request message is used to request to verify the subscriber permanent identifier {Fig. 6 element 620, step 7 & [0123], “based on an authentication request of a terminal, the AUSF 630 may perform an authentication request to the UDM/ARPF 640“}; and
receiving, by the visited authentication and key management for applications anchor function network element, a verification response message from the visited access and mobility management function network element, wherein the verification response message comprises the verification result of the subscriber permanent identifier {Fig. 6 element 620, steps 8, 9 & [0124], “based on a value generated based on the key held in it, the terminal 610 may transmit an authentication response including an EAP response and the AKA′-Challenge to the SEAF 620. The SEAF 620 may also transmit the authentication response including the EAP response and the AKA′-Challenge to the AUSF 630, and the AUSF 630 may perform authentication through verification of the value generated by the terminal”}.
Regarding Claim 4, KIM anticipates all the features of claim 3 and KIM further anticipates
receiving, by the visited authentication and key management for applications anchor function network element, an association relationship between the key identifier and the subscriber permanent identifier from an authentication server function network element; and storing, by the visited authentication and key management for applications anchor function network element, the association relationship between the key identifier and the subscriber permanent identifier {[0134], “in case the primary authentication is successfully completed and the AUSF 1030 receives the “AKMA Ind” value from the UDM 1040, the AUSF 1030 may store KAUSF and generate an AKMA anchor key (KAKMA) and an A-KID from the KAUSF. After the AKMA anchor key is generated, the AUSF 1030 may select an AAnF 1050 through a function of “AAnF search and selection”. In addition, the AUSF 1030 may forward the generated A-KID and KAKMA to the AAnF 1050 together with a SUPI of the terminal”}.
Regarding Claim 5, KIM anticipates all the features of claim 3 and KIM further anticipates
sending, by the visited authentication and key management for applications anchor function network element, an application key get request message to an authentication server function network element, wherein the application key get request message comprises the key identifier; and receiving, by the visited authentication and key management for applications anchor function network element, an application key get response message from the authentication server function network element, wherein the application key get response message comprises the subscriber permanent identifier {[0016], “transmit an authentication request message including the SUCI or a subscriber permanent identifier (SUPI) and a serving network name (SN-name) to an authentication server function (AUSF) based on the message, and to receive an authentication response message from the AUSF. In case the terminal is a roaming terminal and authentication and key management for applications (AKMA) is supported, the authentication response message may include an AKMA anchor key and an A-KID indicating the AKMA anchor key, and the AMF may perform a procedure of registering the AKMA anchor key in an AKMA anchor function (AAnF) based on the SUPI, the AKMA anchor key and the A-KID”}.
Regarding Claim 6, KIM anticipates all the features of claim 1 and KIM further anticipates
receiving, by the visited authentication and key management for applications anchor function network element, an authentication and key management for applications anchor key from the visited access and mobility management function network element; and generating, by the visited authentication and key management for applications anchor function network element, the root key based on the authentication and key management for applications anchor key {[0014], “the message includes any one of a subscription concealed identifier (SUCI) or a 5G-globally unique temporary identifier (GUTI), based on the terminal supporting authentication and key management for applications (AKMA), generate an AKMA anchor key and an A-KID indicating the AKMA anchor key based on a network root key, and complete authentication for a network”}.
Regarding Claim 7, KIM anticipates all the features of claim 1 and KIM further anticipates
when the verification on the subscriber permanent identifier fails, rejecting, by the visited authentication and key management for applications anchor function network element, the application key get request message {[0136], “in case the AAnF 1050 has no corresponding KAKMA, the AAnF 1050 may transmit an error response to the AF 1060. Herein, the AF 1060 may also notify a cause of failure to the terminal, and the terminal may request a new application session to the AF 1060 with a latest A-KID for an AKMA”}.
Regarding claim 9, claim 9 is claim to a method using the method of claim 1. Therefore, claim 9 is rejected for the reasons set forth for claim 1.
Regarding claim 10, claim 10 is a dependent claim of claim 9, claim 10 is claim to method using the method of claim 3. Therefore, claim 10 is rejected for the reasons set forth for claim 3.
Regarding claim 11, claim 11 is a dependent claim of claim 10, claim 11 is claim to method using the method of claim 4. Therefore, claim 11 is rejected for the reasons set forth for claim 4.
Regarding claim 12, claim 12 is a dependent claim of claim 10, claim 12 is claim to method using the method of claim 5. Therefore, claim 12 is rejected for the reasons set forth for claim 5.
Regarding claim 13, claim 9 is claim to a network element using the method of claim 1. Therefore, claim 13 is rejected for the reasons set forth for claim 1.
Regarding claim 14, claim 14 is a dependent claim of claim 13, claim 14 is claim to network element using the method of claim 2. Therefore, claim 14 is rejected for the reasons set forth for claim 2.
Regarding claim 15, claim 15 is a dependent claim of claim 13, claim 15 is claim to network element using the method of claim 3. Therefore, claim 15 is rejected for the reasons set forth for claim 3.
Regarding claim 16, claim 16 is a dependent claim of claim 15, claim 16 is claim to network element using the method of claim 4. Therefore, claim 16 is rejected for the reasons set forth for claim 4.
Regarding claim 17, claim 17 is a dependent claim of claim 16, claim 17 is claim to network element using the method of claim 5. Therefore, claim 17 is rejected for the reasons set forth for claim 5.
Regarding claim 18, claim 18 is a dependent claim of claim 13, claim 18 is claim to network element using the method of claim 6. Therefore, claim 18 is rejected for the reasons set forth for claim 6.
Regarding claim 19, claim 19 is a dependent claim of claim 13, claim 19 is claim to network element using the method of claim 7. Therefore, claim 19 is rejected for the reasons set forth for claim 7.
Allowable subject matter
Claim 8 will be allowable if written in independent form with base method claim 1 and Claim 20 will be allowable if written in independent form with base independent claim 13. For allowability, the independent method Claim 9 is required to be in same scope with equivalent limitations of claim 8 as proposed for amended claim 1.
Reasons of allowance: what is missing from the prior arts is: a security mechanism where an "application key get request" includes a Message Authentication Code (MAC) and specific computing parameters to verify the integrity of the request. To ensure the request is authentic, the receiving AKMA anchor function uses the same parameters and an established key (such as the root or anchor key) to generate its own second MAC. Only if this second MAC matches the first one—confirming the request was not tampered with—does the anchor function proceed to send the requested root key to the application function.
NOTE: the applicant has option to write similar text written in the Reason of allowance above.
Therefore, claims 8 & 20 are objected.
Conclusion
Following prior art has been consulted but is not applied:
KARAKOC; Ferhat et al. (US 2024/0357355 A1) – AKMA key diversity for multiple applications in UE: “Systems and methods for enabling Authentication and Key Management for Applications (AKMA) key diversity for multiple applications are disclosed herein. In one embodiment, an AKMA client of a wireless device determines a root key (KAKMA) and an AKMA key identifier (A-KID) based on primary authentication with a telecommunications network. The AKMA client receives an application identifier (APP-ID) and an application function (AF) identifier (AF-ID) from an application of the wireless device. The AKMA client verifies APP-ID, and verifies that the application is entitled to use AF-ID. If successful, an application key (KAPP) is derived based on KAKMA. AF-ID, and APP-ID. Optionally, the AKMA client encrypts APP-ID and outputs A-KID. KAPP, and the encrypted APP-ID to the application, and the application sends a session establishment request to an AF, the session establishment request comprising A-KID and the encrypted APP-ID.”
Any inquiry concerning this communication or earlier communications from the examiner should be directed to QUAZI FAROOQUI whose telephone number is (571) 270-1034 or Quazi.farooqui@USPTO.GOV. The examiner can normally be reached on Monday-Friday 9:00 am to 5:30 pm, EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bill Korzuch can be reached on (571) 272-7589 or William.Korzuch@USPTO.GOV. The fax phone number for Examiner Farooqui assigned is 571-270-2034.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-flee). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/QUAZI FAROOQUI/
Primary Examiner, Art Unit 2491
Prosecution Insights