DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to Response filed on 01/16/2026.
In the instant Amendment, claims 70-71 have been added; and claims 48, 58, 64, and 69 are independent claims. Claims 48-71 have been examined and are pending
Response to Arguments
Applicant’s arguments filed on 01/16/2026, with respect to the rejections of claims 48-64 under 35 U.S.C. 102(a)(2) and 35 U.S.C. 103, have been fully considered and are persuasive. Therefore, the rejections have been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of TS 33.501 (Security architecture and procedures for 5G System (3GPP TS 33.501 version 16.5.0 Release 16)).
The objection to the specification is withdrawn as the specification has been amended. The 112 (b) rejection is withdrawn as applicant’s argument is persuasive.
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.
Claim 48-56, 58-62, and 64-71 are rejected under 35 U.S.C. 103 as being unpatentable over Phan et al (U.S. PGPub. No. 2022/0116777 A1; Hereinafter "Phan") in view of TS 33.501 (Security architecture and procedures for 5G System (3GPP TS 33.501 version 16.5.0 Release 16) ; Hereinafter "TS 33.501").
As per claim 48, Phan teaches a method performed by security anchor equipment, the method comprising (Phan: para[03-07], [63-69], “FIG. 1, 4 represents a flowchart explaining how authentication typically occurs in a 5G environment. In this figure, several elements are shown: A User Equipment 20 (UE or terminal), that is a Mobile Equipment (ME) cooperating with a secure element (USIM); A SEAF 21 (Security Anchor Function) normally at the level of the serving network that may be a VPLMN (Visited Public Land Mobile Network) or the HPLMN”):
relaying authentication messages between a communication device (UE 20) and an authentication server (AUSF) that is operating as an EAP server for an EAP Authentication and Key Agreement (AKA) procedure between the communication device and the authentication server (Phan: para[07-10], [63-69], “The SEAF 21 receives intermediate key from the AUSF. The AUSF (HSS, EAP Server) interacts with the ARPF and terminates requests from the SEAF. It resides in an operator's network or a 3rd party system. The UDM/ARPF corresponds to an AuC (Authentication Centre). It stores the long-term security credentials and resides in an operator's Home Network domain system; TS 33.501, for example the version V15.3.1 dated 2018-12 describes how an authentication occurs, like represented in this figure (AKA—authentication and key agreement)…. At step 5, the AUSF removes the K.sub.SEAF and returns the 5G SE AV (RAND, AUTN, HXRES*) to the SEAF in a Nausf_UEAuthentication_Authenticate Response. At step 6, the SEAF sends RAND, AUTN to the UE via an AMF (not represented here) in a NAS message Authentication-Request. This message can also include the ngKSI that will be used by the UE (ME collaborating with a USIM) and the AMF to identify the K.sub.AMF and the partial native security context that is created if the authentication is successful. The ME shall forward the RAND and AUTN received in NAS message Authentication Request to the USIM.”);
receiving, from the communication device, a response to a challenge (Phan: para [10-12], [64-81], “At step 8, the UE returns RES* to the SEAF in a NAS message Authentication Response”); and
checking, by the security anchor equipment, whether the response corresponds to an expected response as part of an attempt by the security anchor equipment to authenticate the communication device (Phan: para[10-12], [64-81], “At step 9, the SEAF computes HRES* from RES* and the SEAF compares HRES* and HXRES*. If they coincide, the SEAF considers the authentication successful from the serving network point of view. At step 10, the SEAF sends RES*, as received from the UE, in a Nausf_UEAuthentication_Authenticate Request message to the AUSF”),
wherein at least one of the response, the challenge, and the expected response is, or is derived using, information used in procedure between the communication device and the authentication server (Phan: para[10-13], [69-70], “At step 4, the AUSF generates the 5G SE AV from the 5G HE AV received from the UDM/ARPF by computing the HXRES* from XRES* and K.sub.SEAF from K.sub.AUSF, and replaces the XRES* with the HXRES* and K.sub.AUSF with K.sub.SEAF in the 5G HE AV. At step 5, the AUSF removes the K.sub.SEAF and returns the 5G SE AV (RAND, AUTN, HXRES*) to the SEAF in a Nausf_UEAuthentication_Authenticate Response……At step 7, at receipt of the RAND and AUTN, the USIM verifies the freshness of the 5G AV by checking whether AUTN can be accepted as described in TS 33.102. If so, the USIM computes a response RES. The USIM returns RES, CK, IK to the ME. If the USIM computes a Kc (i.e. GPRS Kc) from CK and IK using conversion function c3 as described in TS 33.102, and sends it to the ME, then the ME shall ignore such GPRS Kc and not store the GPRS Kc on USIM or in ME. The ME then computes RES* from RES..”).
Phan does not explicitly teach that the authentication messages are Extensible Authentication Protocol (EAP) messages.
However, in the related art, TS 33.501 teaches relaying Extensible Authentication Protocol (EAP) messages (TS 33.501: 6.1.3.1, “The AUSF shall send the EAP-Request/AKA'-Challenge message to the SEAF in a Nausf_UEAuthentication_Authenticate Response message. The SEAF shall transparently forward the EAP-Request/AKA'-Challenge message to the UE in a NAS message Authentication Request message. The ME shall forward the RAND and AUTN received in EAP-Request/AKA' Challenge message to the USIM. This message shall include the ngKSI and ABBA parameter. In fact, SEAF shall include the ngKSI and ABBA parameter in all EAP-Authentication request message. ngKSI will be used by the UE and AMF to identify the partial native security context that is created if the authentication is successful. The SEAF shall set the ABBA parameter as defined in Annex A.7.1. During an EAP authentication, the value of the ngKSI and the ABBA parameter sent by the SEAF to the UE shall not be changed. The SEAF needs to understand that the authentication method used is an EAP method by evaluating the type of authentication method based on the Nausf_UEAuthentication_Authenticate Response message. ”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to implement the authentication architecture of Phan using the EAP-AKA′ authentication signaling defined in TS 33.501, because EAP-AKA′ is a standardized authentication method in 5G networks allowing the SEAF to relay authentication messages between a UE and an authentication server while using the same AKA authentication vectors and challenge-response mechanisms, thereby enabling interoperable and secure authentication procedures (TS 33.501, pag. 42).
As per claims 49 and 65, Phan in view of TS 33.501 teaches the independent claim 48. Phan teaches wherein information used in the EAP AKA procedure between the communication device and the authentication server includes a random token RAND, wherein at least one of the response, the challenge, and the expected response is, or is derived using, the random token RAND ((Phan: para[10-13], [69-70],“At step 7, at receipt of the RAND and AUTN, the USIM verifies the freshness of the 5G AV by checking whether AUTN can be accepted as described in TS 33.102. If so, the USIM computes a response RES. The USIM returns RES, CK, IK to the ME. If the USIM computes a Kc (i.e. GPRS Kc) from CK and IK using conversion function c3 as described in TS 33.102, and sends it to the ME, then the ME shall ignore such GPRS Kc and not store the GPRS Kc on USIM or in ME. The ME then computes RES* from RES..”, “the terminal 30 computes the challenge response RES*.sub.SRT based on the terminal key K.sub.SRT computed previously and the received challenge RAND”).
As per claim 50, Phan in view of TS 33.501 teaches the dependent claim 49. Phan teaches wherein the response and/or the expected response is derived using the random token RAND, and wherein the method further comprises receiving the random token RAND from the authentication server (Phan: para[10-13], “At step 4, the AUSF generates the 5G SE AV from the 5G HE AV received from the UDM/ARPF by computing the HXRES* from XRES* and K.sub.SEAF from K.sub.AUSF, and replaces the XRES* with the HXRES* and K.sub.AUSF with K.sub.SEAF in the 5G HE AV. At step 5, the AUSF removes the K.sub.SEAF and returns the 5G SE AV (RAND, AUTN, HXRES*) to the SEAF in a Nausf_UEAuthentication_Authenticate Response……At step 7, at receipt of the RAND and AUTN, the USIM verifies the freshness of the 5G AV by checking whether AUTN can be accepted as described in TS 33.102. If so, the USIM computes a response RES. The USIM returns RES, CK, IK to the ME. If the USIM computes a Kc (i.e. GPRS Kc) from CK and IK using conversion function c3 as described in TS 33.102, and sends it to the ME, then the ME shall ignore such GPRS Kc and not store the GPRS Kc on USIM or in ME. The ME then computes RES* from RES..”).
As per claim 51 and 61, Phan in view of TS 33.501 teaches the dependent claim 50. Phan teaches wherein: checking whether the response corresponds to the expected response comprises generating a response token from the response and the random token RAND and checking whether the response token is equal to the expected response; and/or (Phan: para[10-12], [64-81], “the terminal 30 computes the challenge response RES*.sub.SRT based on the terminal key K.sub.SRT computed previously and the received challenge RAND”, “At step 9, the SEAF computes HRES* from RES* and the SEAF compares HRES* and HXRES*. If they coincide, the SEAF considers the authentication successful from the serving network point of view. At step 10, the SEAF sends RES*, as received from the UE, in a Nausf_UEAuthentication_Authenticate Request message to the AUSF”, ).
As per claims 52 and 59, Phan in view of TS 33.501teaches the independent claim 48. Phan teaches wherein information used in the EAP AKA procedure between the communication device and the authentication server includes a cryptographic key that is shared between, or is generatable by each of, the communication device and the authentication server, wherein the response and/or the expected response is derived using the cryptographic key (para [9-13], [61-81], “he AUSF/UDM/ARFP 32 then generates a random challenge RAND and from K.sub.SRT and RAND, generates an AUTN.sub.SRT, a first expected challenge response XRES*.sub.SRT and keys CK.sub.SRT (for confidentiality protection) and IK.sub.SRT (for integrity protection).”).
As per claims 53 and 66, Phan in view of TS 33.501 teaches the independent claim 48. Phan teaches wherein the expected response is derived using information used in the EAP AKA procedure between the communication device and the authentication server, wherein either: the response is a response RES* and the expected response is an expected response HXRES*; (Phan: para[10-13], “At step 4, the AUSF generates the 5G SE AV from the 5G HE AV received from the UDM/ARPF by computing the HXRES* from XRES* and K.sub.SEAF from K.sub.AUSF, and replaces the XRES* with the HXRES* and K.sub.AUSF with K.sub.SEAF in the 5G HE AV. At step 5, the AUSF removes the K.sub.SEAF and returns the 5G SE AV (RAND, AUTN, HXRES*) to the SEAF in a Nausf_UEAuthentication_Authenticate Response……At step 7, at receipt of the RAND and AUTN, the USIM verifies the freshness of the 5G AV by checking whether AUTN can be accepted as described in TS 33.102. If so, the USIM computes a response RES. The USIM returns RES, CK, IK to the ME. If the USIM computes a Kc (i.e. GPRS Kc) from CK and IK using conversion function c3 as described in TS 33.102, and sends it to the ME, then the ME shall ignore such GPRS Kc and not store the GPRS Kc on USIM or in ME. The ME then computes RES* from RES..”).
As per claim 54, Phan in view of TS 33.501 teaches the independent claim 48. Phan teaches receiving the expected response from the authentication server (Phan: para[7-13], [61-70], “The AUSF/UDM/ARPF 32 then sends at step 42 an authentication vector AV.sub.SRT to the SEAF 31 containing RAND, AUTN.sub.SRT and HXRES*.sub.SRT. At step 43, the SEAF 31 stores locally the authentication vector and sends to UE 30 the RAND and authentication token AUTN.sub.SRT.”), wherein information used in the EAP AKA procedure between the communication device and the authentication server includes a random token RAND, and wherein the method further comprises deriving the expected response from the random token RAND (Phan: para[10-12], [64-81], “the terminal 30 computes the challenge response RES*.sub.SRT based on the terminal key K.sub.SRT computed previously and the received challenge RAND”, “At step 9, the SEAF computes HRES* from RES* and the SEAF compares HRES* and HXRES*. If they coincide, the SEAF considers the authentication successful from the serving network point of view. At step 10, the SEAF sends RES*, as received from the UE, in a Nausf_UEAuthentication_Authenticate Request message to the AUSF”, ).
As per claim 55, Phan in view of TS 33.501 teaches the dependent claim 54. Phan teaches wherein said deriving comprises deriving the expected response also using (Phan: para [7-13], [61-81], “At the next step 45, the UE 30 sends to the SEAF 31 the challenge response RES*.sub.SRT computed by the UE 30. At step 46, the SEAF 31 derives another HRES*.sub.SRT from the received RES*.sub.SRT and verifies that the HRES*.sub.SRT is equal to the HXRES*.sub.SRT contained in the locally stored authentication vector in step 42”).
As per claims 56 and 62, Phan in view of TS 33.501 teaches the independent claim 48. Phan teaches transmitting, to the authentication server and/or to the communication device, signaling indicating a result of said checking by the security anchor equipment; and/or authenticating or rejecting the communication device depending on a result of said checking (Phan: para[11-13], “At step 9, the SEAF computes HRES* from RES* and the SEAF compares HRES* and HXRES*. If they coincide, the SEAF considers the authentication successful from the serving network point of view. At step 10, the SEAF sends RES*, as received from the UE, in a Nausf_UEAuthentication_Authenticate Request message to the AUSF. At step 11, the AUSF receives as authentication confirmation the Nausf_UEAuthentication_Authenticate Request message including a RES*. If the RES* and XRES* are equal, the AUSF considers the authentication as successful from the home network point of view. AUSF informs UDM about the authentication result. At step 12, the AUSF indicates to the SEAF in the Nausf_UEAuthentication_Authenticate Response whether the authentication was successful or not from the home network point of view”).
As per claim 58, Phan teaches a method performed by an authentication server, the method comprising (Phan: para[03-07], [63-69], “FIG. 1 represents a flowchart explaining how authentication typically occurs in a 5G environment. In this figure, several elements are shown: A User Equipment 20 (UE or terminal), that is a Mobile Equipment (ME) cooperating with a secure element (USIM); A SEAF 21 (Security Anchor Function) normally at the level of the serving network that may be a VPLMN (Visited Public Land Mobile Network) or the HPLMN; An AUSF (Authentication Server Function, a UDM/ARPF 22 (Unified Data Management/Authentication Credential Repository and Processing Function). The AUSF/UDM/ARPF are at the level of an HPLMN 22 (Home Public Land Mobile Network):
exchanging authentication messages with a communication device as part of an EAP Authentication and Key Agreement (AKA) procedure between the communication device and the authentication server, with the authentication server operating as an EAP server (Phan: para[07-10], [63-69], “The SEAF 21 receives intermediate key from the AUSF. The AUSF (HSS, EAP Server) interacts with the ARPF and terminates requests from the SEAF. It resides in an operator's network or a 3rd party system. The UDM/ARPF corresponds to an AuC (Authentication Centre). It stores the long-term security credentials and resides in an operator's Home Network domain system; TS 33.501, for example the version V15.3.1 dated 2018-12 describes how an authentication occurs, like represented in this figure (AKA—authentication and key agreement)…. At step 5, the AUSF removes the K.sub.SEAF and returns the 5G SE AV (RAND, AUTN, HXRES*) to the SEAF in a Nausf_UEAuthentication_Authenticate Response. At step 6, the SEAF sends RAND, AUTN to the UE via an AMF (not represented here) in a NAS message Authentication-Request. This message can also include the ngKSI that will be used by the UE (ME collaborating with a USIM) and the AMF to identify the K.sub.AMF and the partial native security context that is created if the authentication is successful. The ME shall forward the RAND and AUTN received in NAS message Authentication Request to the USIM.”);
deriving, from information used in procedure between the communication device and the authentication server, an expected response that security anchor equipment is to expect in response to a challenge as part of an attempt by the security anchor equipment to authenticate the communication device (Phan: para[07-13], [66-69], “At step 3, the AUSF stores the XRES* temporarily together with the received SUPI. The AUSF may store the K.sub.AUSF. At step 4, the AUSF generates the 5G SE AV from the 5G HE AV received from the UDM/ARPF by computing the HXRES* from XRES* and K.sub.SEAF from K.sub.AUSF, and replaces the XRES* with the HXRES* and K.sub.AUSF with K.sub.SEAF in the 5G HE AV. At step 5, the AUSF removes the K.sub.SEAF and returns the 5G SE AV (RAND, AUTN, HXRES*) to the SEAF in a Nausf_UEAuthentication_Authenticate Response.”); and
transmitting the expected response to the security anchor equipment (Phan: para[07-13], [66-69], “At step 5, the AUSF removes the K.sub.SEAF and returns the 5G SE AV (RAND, AUTN, HXRES*) to the SEAF in a Nausf_UEAuthentication_Authenticate Response.”).
Phan does not explicitly teach that the authentication messages are Extensible Authentication Protocol (EAP) messages.
However, in the related art, TS 33.501 teaches relaying Extensible Authentication Protocol (EAP) messages (TS 33.501: 6.1.3.1, “The AUSF shall send the EAP-Request/AKA'-Challenge message to the SEAF in a Nausf_UEAuthentication_Authenticate Response message. The SEAF shall transparently forward the EAP-Request/AKA'-Challenge message to the UE in a NAS message Authentication Request message. The ME shall forward the RAND and AUTN received in EAP-Request/AKA' Challenge message to the USIM. This message shall include the ngKSI and ABBA parameter. In fact, SEAF shall include the ngKSI and ABBA parameter in all EAP-Authentication request message. ngKSI will be used by the UE and AMF to identify the partial native security context that is created if the authentication is successful. The SEAF shall set the ABBA parameter as defined in Annex A.7.1. During an EAP authentication, the value of the ngKSI and the ABBA parameter sent by the SEAF to the UE shall not be changed. The SEAF needs to understand that the authentication method used is an EAP method by evaluating the type of authentication method based on the Nausf_UEAuthentication_Authenticate Response message. ”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to implement the authentication architecture of Phan using the EAP-AKA′ authentication signaling defined in TS 33.501, because EAP-AKA′ is a standardized authentication method in 5G networks allowing the SEAF to relay authentication messages between a UE and an authentication server while using the same AKA authentication vectors and challenge-response mechanisms, thereby enabling interoperable and secure authentication procedures (TS 33.501, pag. 42).
As per claim 60, claim 60 is rejected under the same rational as claims 53 and 54.
As per claims 64 and 69, Phan teaches a method performed by a communication device, the method comprising(Phan: para[03-07], [63-69], “FIG. 1, 4 represents a flowchart explaining how authentication typically occurs in a 5G environment. In this figure, several elements are shown: A User Equipment 20 (UE or terminal), that is a Mobile Equipment (ME) cooperating with a secure element (USIM); A SEAF 21 (Security Anchor Function) normally at the level of the serving network that may be a VPLMN (Visited Public Land Mobile Network) or the HPLMN”):
exchanging Authentication messages with an authentication server as part of an EAP Authentication and Key Agreement (AKA) procedure between the communication device and the authentication server, with the authentication server operating as an EAP server (Phan: para[07-10], [63-69], “The SEAF 21 receives intermediate key from the AUSF. The AUSF (HSS, EAP Server) interacts with the ARPF and terminates requests from the SEAF. It resides in an operator's network or a 3rd party system. The UDM/ARPF corresponds to an AuC (Authentication Centre). It stores the long-term security credentials and resides in an operator's Home Network domain system; TS 33.501, for example the version V15.3.1 dated 2018-12 describes how an authentication occurs, like represented in this figure (AKA—authentication and key agreement)…. At step 5, the AUSF removes the K.sub.SEAF and returns the 5G SE AV (RAND, AUTN, HXRES*) to the SEAF in a Nausf_UEAuthentication_Authenticate Response. At step 6, the SEAF sends RAND, AUTN to the UE via an AMF (not represented here) in a NAS message Authentication-Request. This message can also include the ngKSI that will be used by the UE (ME collaborating with a USIM) and the AMF to identify the K.sub.AMF and the partial native security context that is created if the authentication is successful. The ME shall forward the RAND and AUTN received in NAS message Authentication Request to the USIM.”);
receiving a challenge from security anchor equipment (Phan: para[7-13], [69-81] “At step 6, the SEAF sends RAND, AUTN to the UE via an AMF (not represented here) in a NAS message Authentication-Request. This message can also include the ngKSI that will be used by the UE (ME collaborating with a USIM) and the AMF to identify the K.sub.AMF and the partial native security context that is created if the authentication is successful. The ME shall forward the RAND and AUTN received in NAS message Authentication Request to the USIM.”);
generating, from information used in the procedure between the communication device and the authentication server, a response to the challenge (Phan: para[7-13], [69-81], “At step 7, at receipt of the RAND and AUTN, the USIM verifies the freshness of the 5G AV by checking whether AUTN can be accepted as described in TS 33.102. If so, the USIM computes a response RES. The USIM returns RES, CK, IK to the ME. If the USIM computes a Kc (i.e. GPRS Kc) from CK and IK using conversion function c3 as described in TS 33.102, and sends it to the ME, then the ME shall ignore such GPRS Kc and not store the GPRS Kc on USIM or in ME. The ME then computes RES* from RES. The ME calculates K.sub.AUSF from CK∥IK. The ME shall calculate K.sub.SEAF from K.sub.AUSF. At step 8, the UE returns RES* to the SEAF in a NAS message Authentication Response”); and
transmitting the response to the security anchor equipment as part of an attempt to authenticate the communication device to the security anchor equipment (Phan: para[7-13], [69-81], “At step 8, the UE returns RES* to the SEAF in a NAS message Authentication Response”).
Phan does not explicitly teach that the authentication messages are Extensible Authentication Protocol (EAP) messages.
However, in the related art, TS 33.501 teaches relaying Extensible Authentication Protocol (EAP) messages (TS 33.501: 6.1.3.1, “The AUSF shall send the EAP-Request/AKA'-Challenge message to the SEAF in a Nausf_UEAuthentication_Authenticate Response message. The SEAF shall transparently forward the EAP-Request/AKA'-Challenge message to the UE in a NAS message Authentication Request message. The ME shall forward the RAND and AUTN received in EAP-Request/AKA' Challenge message to the USIM. This message shall include the ngKSI and ABBA parameter. In fact, SEAF shall include the ngKSI and ABBA parameter in all EAP-Authentication request message. ngKSI will be used by the UE and AMF to identify the partial native security context that is created if the authentication is successful. The SEAF shall set the ABBA parameter as defined in Annex A.7.1. During an EAP authentication, the value of the ngKSI and the ABBA parameter sent by the SEAF to the UE shall not be changed. The SEAF needs to understand that the authentication method used is an EAP method by evaluating the type of authentication method based on the Nausf_UEAuthentication_Authenticate Response message. ”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to implement the authentication architecture of Phan using the EAP-AKA′ authentication signaling defined in TS 33.501, because EAP-AKA′ is a standardized authentication method in 5G networks allowing the SEAF to relay authentication messages between a UE and an authentication server while using the same AKA authentication vectors and challenge-response mechanisms, thereby enabling interoperable and secure authentication procedures (TS 33.501, pag. 42).
Furthermore, Phan also teaches the hardware components of claim 69 such as processing circuitry (Qian: para[03-07).
As per claim 67, Phan in view of TS 33.501 teaches the independent claim 64. Phan in view of TS 33.501 teaches wherein transmitting the response comprises transmitting the response to the security anchor equipment within a Non-Access Stratum (NAS) message (Phan: para[11], “At step 8, the UE returns RES* to the SEAF in a NAS message Authentication Response.”).
As per claim 68, Phan in view of TS 33.501 teaches the independent claim 64. Phan teaches receiving a random token from the security anchor equipment and wherein said deriving comprises deriving the response from the random token received from the security anchor equipment (Phan: para[7-13], [68-69], “At step 43, the SEAF 31 stores locally the authentication vector and sends to UE 30 the RAND and authentication token AUTN.sub.SRT. The UE 30 then generates on its side, like the AUSF/UDM/ARFP 32, K.sub.SRT, the authentication token AUTN.sub.SRT, RES*.sub.SRT, CK.sub.SRT and IK.sub.SRT. It verifies also if AUTN.sub.SRT equals XAUTN.sub.SRT and generates K.sub.AUSF_SRT from the keys CK.sub.SRT and IK.sub.SRT and therefrom K.sub.SEAF_SRT.”); and/or receiving, from the security anchor equipment, signaling indicating a result of the attempt to authenticate the communication device to the security anchor equipment (Phan: para[82], “At step 48, the AUSF/UDM/ARPF 32 verifies that said received RES*.sub.SRT from AUSF 31 is equal to the expected challenge response XRES*.sub.SRT computed before. If they correspond, the AUSF/UDM/ARPF 32 considers that the UE 30 is authenticated and sends at step 49 the authentication result and the K.sub.SEAF_SRT to the SEAF 31, this authentication result indicating the status of the authentication of the terminal 30 accordingly to 3GPP TS 33.501. After that, the SEAF 31 and the UE 30 can use the anchor key K.sub.SEAF_SRT for communication as specified in 3GPP TS 33.501”).
As per claims 70, 71, Phan in view of TS 33.501 teaches the independent claim 64. Phan in view of TS 33.501 teaches wherein the EAP messages include one or more EAP- Request/AKA'-Challenge messages and/or one or more EAP-Response/AKA'-Challenge messages (TS 33.501: 6.1.3.1, “The AUSF shall send the EAP-Request/AKA'-Challenge message to the SEAF in a Nausf_UEAuthentication_Authenticate Response message. The SEAF shall transparently forward the EAP-Request/AKA'-Challenge message to the UE in a NAS message Authentication Request message. The ME shall forward the RAND and AUTN received in EAP-Request/AKA' Challenge message to the USIM. This message shall include the ngKSI and ABBA parameter. In fact, SEAF shall include the ngKSI and ABBA parameter in all EAP-Authentication request message. ngKSI will be used by the UE and AMF to identify the partial native security context that is created if the authentication is successful”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to implement the authentication architecture of Phan using the EAP-AKA′ authentication signaling defined in TS 33.501, because EAP-AKA′ is a standardized authentication method in 5G networks allowing the SEAF to relay authentication messages between a UE and an authentication server while using the same AKA authentication vectors and challenge-response mechanisms, thereby enabling interoperable and secure authentication procedures (TS 33.501, pag. 42).
Claim 57 and 63 are rejected under 35 U.S.C. 103 as being unpatentable over Phan et al (U.S. PGPub. No. 2022/0116777 A1; Hereinafter "Phan")in view of TS 33.501 (Security architecture and procedures for 5G System (3GPP TS 33.501 version 16.5.0 Release 16) ; Hereinafter "TS 33.501") and He et al (U.S. PGPub. No. 2020/0344604 A1; Hereinafter "He").
As per claims 57 and 63, Phan in view of TS 33.801 teaches the independent claims 48 and 58.
Phan in view of TS 33.801 does not teach wherein the challenge is a random token RAND* generated by the security anchor equipment and/or wherein the expected response is derived using a random token RAND* generated by the security anchor equipment.
However, in the related art, teaches wherein the challenge is a random token RAND* generated by the security anchor equipment and/or wherein the expected response is derived using a random token RAND* generated by the security anchor equipment (He: para[376-388], “S1110a. The SEAF generates the shared key Kamf-udm=KDF (Kseaf, RAND) between the AMF and the UDM based on Kseaf and the random number RAND in the authentication vector according to a KDF algorithm, where RAND may be alternatively a random number generated by the SEAF. Step S1110a may be completed in any step between step S116 and step S1111.”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to have update the modified Phan and generate RAND within the SEAF as discussed in He, it will improved integrity, confidentiality, and performance for mobile communication (He: para[72]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LYDIA L NOEL whose telephone number is (571)272-1628. The examiner can normally be reached Monday - Friday 9:00 - 5:00.
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, Alexander Lagor can be reached on (571)-270-5143. 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.
/L.L.N./Examiner, Art Unit 2437
/BENJAMIN E LANIER/Primary Examiner, Art Unit 2437