Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
This is in response to the amendments filed on 7/22/2026. Claims 1-10 have been amended. Claims 1-10 are currently pending and have been considered below.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1 and 6 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Objections
Claim 6 is objected to because of the following informalities: Claim 6, page 2, line 2 recites “configuring” which should be changed to --configure--. Appropriate correction is required.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 2, and 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Wu” (US 2023/0232228) in further view of “Palanigounder” (US 2019/0313238).
Regarding Claim 1:
Wu teaches:
A method performed by a user equipment (UE) in a wireless network (Fig. 10), the method comprising:
receiving, from an upper layer of the UE (¶0074, “An edge enable client (EEC) is a peer entity on the terminal side device. The EEC is configured to register EEC information and AC information with the EES, perform security authentication and authorization …”; ¶0076, “An enable client (for example, the EEC) may be … implemented inside the AC”; i.e., the EEC, when implemented within an application client (AC) is considered to be operating within an application (upper) layer), a request for providing an authentication and key management for applications (AKMA) anchor key (KAKMA) and an AKMA key identifier (A-KID) (¶0154, “The edge enabler client registration request message includes capability information of the UE, and the capability information of the UE includes at least one second authentication mechanism supported by the UE. Optionally, the capability information of the UE may further include a network type used by the UE to access the EAS and priority information of the at least one authentication mechanism supported by the UE”; ¶0199), wherein the KAKMA and the A-KID are generated based on an authentication server function (AUSF) key (KAUSF) (¶0199, “If the UE can use the AKMA authentication mechanism (for example, the AUSF may determine, based on an AKMA indication received from a UDM, that the UE can use the AKMA authentication mechanism), after the primary identity authentication process succeeds, the AUSF generates, according to a definition in TS33.535, an AKMA key (KAKMA) and an identifier A-KID that corresponds to the AKMA key”; i.e., an AKMA key is derived from an AUSF key);
determining … whether the KAUSF based on a primary authentication with an AUSF (Fig. 10, step 1000a) is available (¶0199, “The UE registers with an operator network and performs a primary authentication procedure. In the primary authentication procedure, the UE and an AUSF separately generate an authentication key KAUSF”; i.e., a successful authentication leads to the UE knowing that the AUSF also has generated a KAUSF via step 1003);
based on determining that the KAUSF is not available, transmitting, from the NAS layer of the UE to the upper layer of the UE, a reject message in response to the request and configuring a back-off flag in the UE to prevent retransmitting the request (The examiner notes that this limitation is contingent on the condition of determining a KAUSF not being available. However, when these conditions are not satisfied, the limitation which is contingent on such is not required to be performed and thus holds no patentable weight in a method/process claim - see MPEP 2111.04 (II)); and
based on determining that the KAUSF is available (Fig. 10, step 1003 indicates that primary authentication procedure was successful in step 1000a and deriving AKMA indicates that the KAUSF is available), notifying the upper layer of the UE and providing the A-KID and the KAKMA to the upper layer of the UE (¶0125, “A bottom layer of the terminal device generates the first key and the first key identifier based on the information that corresponds to the target authentication mechanism, and the bottom layer of the terminal device sends the first key identifier and the like to the EEC”; ¶203, “When the UE determines to communicate with the second network element, if the UE supports the AKMA, and the second network element also supports the AKMA (optionally, whether the second network element supports the AKMA may be determined based on the indication in step 1002), the UE derives the AKMA key and the A-KID according to the definition in TS33.535 … For the UE that supports the AKMA, the derivation of the AKMA key and the A-KID may be performed at any time after the primary authentication procedure and before the UE determines to communicate with the second network element by using the AKMA”).
Wu does not disclose:
determining, using a non-access stratum (NAS) layer of the UE, whether the KAUSF based on a primary authentication with an AUSF is available;
Palanigounder teaches:
determining, using a non-access stratum (NAS) layer of the UE (Fig. 2, message 5 - “Non access stratum (NAS) Security Mode Command (SMC)”), whether the KAUSF based on a primary authentication with an AUSF is available (¶0042, “ … sends a UE authentication request (e.g., utilizing a Subscription Concealed Identifier (SUCI)) to the authentication server function (AUSF) 222 of the HPLMN 220… As illustrated, the UE 200 is then authenticated by the HPLMN 220 … followed by the derivation of keys (e.g., KAUSF & KSEAF) at the UE 200 and HPLMN 220. After the derivation of keys, the AUSF 222 sends an authentication response to the PLMN 210 … Upon receiving the authentication response from the AUSF 222, the PLMN 210 sends a non-access stratum (NAS) security mode command (SMC) to the UE 200”; i.e., upon primary authentication being successful between a UE and an AUSF, both UE and AUSF derive KAUSF, where the UE receives via NAS layer messaging confirmation that a KAUSF is available at the AUSF by virtue of successful authentication);
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to modify Wu’s system for establishing a secure communication by enhancing Wu’s system to utilize NAS messaging to indicate to a UE whether authentication was successful with an AUSF, as taught by Palanigounder, in order to ensure compliance with industry-standard protocols.
The motivation is to implement authentication procedures in mobile wireless networks within NAS messages thus ensuring devices in the networks can operate in a secure, compliant manner.
Regarding Claim 2:
The method of claim 1, Wu in view of Palanigounder further comprising:
performing the primary authentication with the AUSF entity and storing the KAUSF, based on the primary authentication (Wu, Fig. 10, step 1000a & 1003);
generating the KAKMA and the A-KID from the KAUSF (Wu, ¶0199, “If the UE can use the AKMA authentication mechanism (for example, the AUSF may determine, based on an AKMA indication received from a UDM, that the UE can use the AKMA authentication mechanism), after the primary identity authentication process succeeds, the AUSF generates, according to a definition in TS33.535, an AKMA key (KAKMA) and an identifier A-KID that corresponds to the AKMA key”); and
establishing communication with an application function (AF) server using the A-KID (Wu, Fig. 10, step 1004).
Regarding Claim 5:
The method of claim 2, wherein Wu in view of Palanigounder further teaches the establishing the communication with the AF server comprises:
generating an AKMA application key (KAF) using the A-KID to access an application hosted by the AF server (Wu, Fig. 10, step 1003; ¶0203, “… the UE obtains the locally stored A-KID based on that the second network element supports the AKMA authentication mechanism, and includes the A-KID in step 1004. Further, the UE generates, based on the locally stored AKMA key, the K.sub.AF that corresponds to the second network element”);
establishing the communication with the AF server to access the application hosted by the AF server (Wu, Fig. 10, step 1004); and
transmitting, to the AF server, the A-KID over the established communication (Wu, Fig. 10, step 1004; ¶0204, “… and sends, to the second network element, a communication connection establishment request including the A-KID…”).
Claim(s) 6, 7, and 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Wu” (US 2023/0232228) in view “Chin” (US 2020/0092720) in further view of “Palanigounder” (US 2019/0313238).
Regarding Claim 6:
Wu teaches:
A user equipment (UE) in a wireless network (Fig. 10), the UE comprising:
a transceiver (¶0085, “The terminal device may be referred to as a terminal for short, and is a device having a wireless transceiver function … The terminal device sometimes may also be referred to as user equipment (UE)”); and
at least one processor coupled to the transceiver and configured to:
receive, from an upper layer of the UE (¶0074, “An edge enable client (EEC) is a peer entity on the terminal side device. The EEC is configured to register EEC information and AC information with the EES, perform security authentication and authorization …”; ¶0076, “An enable client (for example, the EEC) may be … implemented inside the AC”; i.e., the EEC, when implemented within an application client (AC) is considered to be operating within an application (upper) layer), a request for providing an authentication and key management for applications (AKMA) anchor key (KAKMA) and an AKMA key identifier (A-KID) (¶0154, “The edge enabler client registration request message includes capability information of the UE, and the capability information of the UE includes at least one second authentication mechanism supported by the UE. Optionally, the capability information of the UE may further include a network type used by the UE to access the EAS and priority information of the at least one authentication mechanism supported by the UE”; ¶0199),, wherein the KAKMA and the A-KID are generated based on an authentication server function (AUSF) key (KAUSF) (¶0199, “If the UE can use the AKMA authentication mechanism (for example, the AUSF may determine, based on an AKMA indication received from a UDM, that the UE can use the AKMA authentication mechanism), after the primary identity authentication process succeeds, the AUSF generates, according to a definition in TS33.535, an AKMA key (KAKMA) and an identifier A-KID that corresponds to the AKMA key”);
determine … whether the KAUSF based on a primary authentication with an AUSF (Fig. 10, step 1000a) is available (¶0199, “The UE registers with an operator network and performs a primary authentication procedure. In the primary authentication procedure, the UE and an AUSF separately generate an authentication key KAUSF”; i.e., a successful authentication leads to the UE knowing that the AUSF also has generated a KAUSF via step 1003);
…
based on determining that and the KAUSF is available (Fig. 10, step 1003 indicates that primary authentication procedure was successful in step 1000a and deriving AKMA indicates that the KAUSF is available), notify the upper layer of the UE and provide the A-KID and the KAKMA to the upper layer of the UE (¶0125, “A bottom layer of the terminal device generates the first key and the first key identifier based on the information that corresponds to the target authentication mechanism, and the bottom layer of the terminal device sends the first key identifier and the like to the EEC”; ¶203, “When the UE determines to communicate with the second network element, if the UE supports the AKMA, and the second network element also supports the AKMA (optionally, whether the second network element supports the AKMA may be determined based on the indication in step 1002), the UE derives the AKMA key and the A-KID according to the definition in TS33.535 … For the UE that supports the AKMA, the derivation of the AKMA key and the A-KID may be performed at any time after the primary authentication procedure and before the UE determines to communicate with the second network element by using the AKMA”).
Wu does not disclose:
determine, using a non-access stratum (NAS) layer of the UE, whether the KAUSF based on a primary authentication with an AUSF is available;
based on determining that the KAUSF is not available, transmit, from the NAS layer of the UE to the upper layer of the UE, a reject message in response to the request and configuring a back-off flag in the UE to prevent retransmitting the request; and
Chin teaches:
based on determining that the KAUSF is not available (Fig. 6, step 602 indicating an authentication failure with a corresponding AUSF and therefore making a key shared with the AUSF not available), transmit, from the NAS layer of the UE to the upper layer of the UE, a reject message in response to the request (Fig. 6, step 608; ¶0059, “At 608 the AUSF component 148 sends an EAP failure message EAP_FAILURE to the AMF component 146, which passes the message to the NAS component 142, which passes the message to the EAP component 144”; i.e., transmit a failure message from a NAS layer to an EAP (upper) layer of the UE responsive to the authentication failure) and configuring a back-off flag in the UE to prevent retransmitting the request (¶0060, “In the message sequence flow 600, when the EAP component 144 on the UE 104 has failed to authenticate the 5G network, there is no point in the NAS component 142 retrying registration to the same NR cell as the same result will keep repeating. Accordingly, at 610 the EAP component 144 provides a notification to the NAS component 142 to abort the registration procedures and bar the current NR cell or registration area from further registration attempts”); and
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to modify Wu’s system for establishing a secure communication by enhancing Wu’s user equipment (UE) to forward, to an upper layer of the UE, a rejection message upon unsuccessful authentication with an AUSF, in addition to preventing retry messages, as taught by Chin, in order to determine whether to retry or abort the authentication process while minimizing the impact of a retry process.
The motivation is to provide a rejection notice to active layers of user equipment when authentication fails with a designated entity in order for these layers to determine whether to retry or abort authentication. This may result in lessening the chances of registration failures as well as minimizing the delay for completing NAS layer procedures (Chin, ¶0050). Additionally, in the instance of a registration failure, the system can be configured to prevent retransmission of registration requests so that a NAS component of a UE does not waste time and resources trying to reconnect to a network that provided the failure (Chin, ¶0060).
Wu in view of Chin does not disclose:
determine, using a non-access stratum (NAS) layer of the UE, whether the KAUSF based on a primary authentication with an AUSF is available;
Palanigounder teaches:
determine, using a non-access stratum (NAS) layer of the UE (Fig. 2, message 5 - “Non access stratum (NAS) Security Mode Command (SMC)”), whether the KAUSF based on a primary authentication with an AUSF is available (¶0042, “ … sends a UE authentication request (e.g., utilizing a Subscription Concealed Identifier (SUCI)) to the authentication server function (AUSF) 222 of the HPLMN 220… As illustrated, the UE 200 is then authenticated by the HPLMN 220 … followed by the derivation of keys (e.g., KAUSF & KSEAF) at the UE 200 and HPLMN 220. After the derivation of keys, the AUSF 222 sends an authentication response to the PLMN 210 … Upon receiving the authentication response from the AUSF 222, the PLMN 210 sends a non-access stratum (NAS) security mode command (SMC) to the UE 200”; i.e., upon primary authentication being successful between a UE and an AUSF, both UE and AUSF derive KAUSF, where the UE receives via NAS layer messaging confirmation that a KAUSF is available at the AUSF by virtue of successful authentication);
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to modify Wu in view of Chin’s system for establishing a secure communication by enhancing Wu in view of Chin’s system to utilize NAS messaging to indicate to a UE whether authentication was successful with an AUSF, as taught by Palanigounder, in order to ensure compliance with industry-standard protocols.
The motivation is to implement authentication procedures in mobile wireless networks within NAS messages thus ensuring devices in the networks can operate in a secure, compliant manner.
Regarding Claim 7:
The UE of claim 6, wherein Wu in view of Chin in further view of Palanigounder further teaches the at least one processor is further configured to:
perform the primary authentication with an AUSF and store the KAUSF, based on the primary authentication (Wu, Fig. 10, step 1000a & 1003);
generate the KAKMA and the A-KID from the KAUSF (Wu, ¶0199, “If the UE can use the AKMA authentication mechanism (for example, the AUSF may determine, based on an AKMA indication received from a UDM, that the UE can use the AKMA authentication mechanism), after the primary identity authentication process succeeds, the AUSF generates, according to a definition in TS33.535, an AKMA key (KAKMA) and an identifier A-KID that corresponds to the AKMA key”); and
establish communication with an application function (AF) server using the A-KID (Wu, Fig. 10, step 1004).
Regarding Claim 10:
The UE of claim 7, wherein Wu in view of Chin in further view of Palanigounder further teaches the at least one processor is further configured to:
generate an AKMA application key (KAF) using the A-KID to access an application hosted by the AF server (Wu, Fig. 10, step 1003; ¶0203, “… the UE obtains the locally stored A-KID based on that the second network element supports the AKMA authentication mechanism, and includes the A-KID in step 1004. Further, the UE generates, based on the locally stored AKMA key, the K.sub.AF that corresponds to the second network element”);
establish the communication with the AF server to access the application hosted by the AF server (Wu, Fig. 10, step 1004); and
transmit, to the AF server, the A-KID over the established communication (Wu, Fig. 10, step 1004; ¶0204, “… and sends, to the second network element, a communication connection establishment request including the A-KID…”).
Allowable Subject Matter
Claims 3, 4, 8, and 9 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
The following is a statement of reasons for the indication of allowable subject matter: The prior art of record does not teach or suggest, either alone or in combination, the subject matter recited within claims 3, 4, 8, and 9 including any intervening claims.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DANIEL B POTRATZ whose telephone number is (571)270-5329. The examiner can normally be reached on M-F 10 A.M. - 6 P.M. CST.
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, William Korzuch can be reached on 571-272-7589. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
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-free). 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.
/DANIEL B POTRATZ/Primary Examiner, Art Unit 2491
