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 06/10/2026.
Claims 48-71 have been examined and are pending. This Action is made Final
Response to Arguments
Applicant’s arguments filed on 06/10/2026, with respect to the rejections of claims 48-71 under 35 U.S.C. 103, have been fully considered but are not persuasive.
Applicant’s arguments have been fully considered but are not persuasive for the following reasons.
A. Argument that Phan fundamentally operates according to 5G AKA
Applicant argues that Phan expressly follows the 5G AKA procedure of TS 33.501 6.1.3.2, whereas TS 33.501 separately describes EAP-AKA′ in 6.1.3.1. Applicant therefore contends that Phan’s 5G AKA operation cannot be treated as interchangeable with EAP-AKA′.
This argument is not persuasive because the rejection does not rely on Phan alone as teaching the claimed EAP messages and does not require replacement of Phan’s entire authentication procedure. Rather, Phan is relied upon for the security anchor equipment receiving a response from the communication device, obtaining or storing an expected response, and checking whether the received response corresponds to the expected response. TS 33.501 is relied upon for teaching that authentication messages exchanged between the communication device and the authentication server may be EAP-AKA′ messages relayed through the SEAF. Claim 48 does not require that the security anchor checking operation itself be defined by TS 33.501 6.1.3.1. Nor does claim 48 require that the expected response be generated or received as part of the EAP-AKA′ procedure. The claim merely requires both the relay of EAP messages and a security anchor checking operation, together with the broader requirement that at least one of the response, challenge, or expected response be, or be derived using, information used in the EAP-AKA procedure. Accordingly, the rejection relies on the combined teachings of Phan and TS 33.501, rather than treating Phan as independently disclosing EAP-AKA′. Furthermore, the test for obviousness is not whether the features of a secondary reference may be bodily incorporated into the structure of the primary reference; nor is it that the claimed invention must be expressly suggested in any one or all of the references. Rather, the test is what the combined teachings of the references would have suggested to those of ordinary skill in the art. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981).
B. Argument that the stated reason for modifying Phan is insufficient
1- Applicant argues that Phan already uses the standardized 5G AKA procedure and, therefore, the fact that EAP-AKA′ is also standardized does not provide a sufficient reason to modify Phan.
This argument is not persuasive. A prior art system need not be defective or nonstandard before it would have been obvious to implement a known alternative. TS 33.501 teaches EAP-AKA′ as another standardized authentication technique within the same 5G authentication architecture. A person of ordinary skill would have recognized that using EAP-AKA′ signaling would permit Phan’s architecture to operate in an EAP based authentication environment while retaining Phan’s serving network response checking. The proposed modification therefore represents the use of a known authentication message technique in a closely related authentication architecture to obtain the predictable benefit of EAP compatibility and interoperability. The MPEP recognizes combining known elements, substituting known alternatives, and applying a known technique to a similar method as appropriate obviousness rationales when the result would have been predictable.
2- Applicant argues that because Phan expressly selected the 5G AKA procedure of 6.1.3.2, Phan does not suggest using the separate EAP-AKA′ procedure of 6.1.3.1.
This argument improperly limits the obviousness inquiry to whether Phan expressly proposes the modification. The rejection is based on Phan in view of TS 33.501. TS 33.501 itself teaches EAP-AKA′ signaling involving the same general participating entities UE, SEAF, and AUSF, and teaches that the SEAF relays the EAP authentication messages between the UE and AUSF. Phan’s disclosure of one standardized authentication alternative does not teach away from the other standardized alternative merely because Phan does not expressly select it. Applicant has not identified any disclosure in Phan that criticizes, discredits, or discourages the use of EAP-AKA′ signaling.
3. Applicant argues that the rejection has not shown that the exact RES*, HRES*, and HXRES* values used by Phan are used in the EAP-AKA′ procedure.
In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies are not recited in the rejected claims, i.e., claim 48 does not require: an HRES*/HXRES* comparison; that the expected response be an EAP-AKA′ expected response; that the checked response be an EAP-Response/AKA′-Challenge payload; or that all of the response, challenge, and expected response be values used in the EAP-AKA′ procedure. Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). The claim requires only that at least one of the response, challenge, and expected response be, or be derived using, information used in the EAP-AKA procedure. Phan teaches use of the random challenge RAND. TS 33.501 likewise teaches that RAND is included in the EAP-Request/AKA′ Challenge and is forwarded to the UE. Therefore, the claimed alternative is satisfied at least by the challenge RAND, which is information used in the EAP-AKA′ procedure. The claim does not additionally require that Phan’s HXRES* itself be an EAP-AKA′ value.
4- Applicant argues that replacing Phan’s NAS based 5G AKA signaling with EAP-AKA′ signaling would fundamentally change how Phan operates and would eliminate Phan’s SEAF side HRES*/HXRES* checking.
This argument misconstrues the proposed modification. The rejection does not require eliminating Phan’s response checking operation. The proposed combination retains Phan’s teaching that the security anchor performs a preliminary check of a response received from the UE and uses TS 33.501 to provide EAP-AKA′ authentication messages between the UE and AUSF through the SEAF. Thus, in the proposed combination: Phan’s security anchor checking continues to perform its disclosed function; and TS 33.501’s EAP messages continue to perform their authentication message function. The modification does not require that the combined system operate exclusively and without any additional checking beyond the minimum standardized EAP AKA′ procedure. Claim 48 also does not impose such an exclusivity requirement. Applicant has not shown that relaying EAP AKA′ messages would render Phan incapable of performing a local response check or would make Phan inoperable for authentication. Although a combination cannot change the principle of operation or render a reference inoperable, a showing of physical identity between the two disclosed protocol flows is not required.
5- Applicant argues that interoperability, standardization, and secure authentication do not motivate the modification because Phan’s 5G AKA procedure already provides those benefits.
This argument is not persuasive because the proposed benefit is not merely making Phan standardized. The modification permits Phan’s architecture to support the standardized EAP AKA′ message framework, including the exchange and relay of EAP-Request/AKA′-Challenge and EAP-Response/AKA′-Challenge messages. The fact that Phan already supports another standardized authentication method does not eliminate the predictable benefit of compatibility with EAP based authentication systems. A known technique may be obvious even though the prior art system already performs its basic intended purpose. The references need not identify the exact same advantage recognized by Applicant, provided the prior art supplies an articulated reason to make the predictable modification.
C. Argument concerning the final “wherein” limitation
Applicant argues that Phan’s RAND, AUTN, RES*, and HXRES* values are disclosed only in Phan’s 5G AKA procedure and that the rejection has not shown that those values are information used in the claimed EAP-AKA procedure.
This argument is not persuasive because the final limitation is expressly written in the alternative: “at least one of the response, the challenge, and the expected response is, or is derived using, information used in the EAP AKA procedure.” The rejection need not establish that every one of the response, challenge, and expected response is an EAP-AKA′ value. Phan teaches that RAND is the challenge transmitted to the UE, and TS 33.501 teaches that RAND is contained in the EAP-Request/AKA′-Challenge sent through the SEAF to the UE. Thus, the challenge is information used in the EAP-AKA′ procedure, satisfying the claimed “at least one” alternative. Applicant’s argument appears to require that: the expected response be supplied through the EAP-AKA′ procedure; the response checked by the SEAF be the EAP-Response/AKA′-Challenge; and the SEAF perform standardized EAP-AKA′ response verification. None of those additional requirements is recited in claim 48. Accordingly, Phan supplies the security anchor checking operation, TS 33.501 supplies the EAP-AKA′ message relay, and the common use of RAND establishes the required relationship between the securityanchor challenge and information used in the EAP-AKA′ procedure.
Independent claims 58, 64, and 69
Applicant states generally that the other independent claims should be withdrawn for similar reasons. That general assertion is not persuasive.
For claim 58, Phan teaches the authentication server deriving and transmitting the expected response to the security anchor, while TS 33.501 supplies the EAP-AKA′ exchange. Applicant again improperly assumes that the expected response must be generated exclusively according to the standardized EAP-AKA′ procedure.
For claims 64 and 69, Applicant’s argument is even less applicable because those claims do not require the security anchor to compare a response with an expected response. TS 33.501 expressly teaches the UE receiving an EAP-Request/AKA′ Challenge through the SEAF, generating a response using the authentication information, and transmitting the EAP Response/AKA′ Challenge to the SEAF. The arguments regarding the location of HRES*/HXRES* verification therefore do not address a limitation of claims 64 or 69.
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 one of ordinary skill in the art before the effective filing date of the invention to modify the authentication architecture of Phan, as taught by TS 33.501, to relay EAP AKA′ authentication messages between the communication device and the authentication server while retaining Phan’s security anchor response checking operation. TS 33.501 teaches EAP-AKA′ as a standardized authentication alternative involving the UE, SEAF, and AUSF and using AKA challenge-response information, including RAND. The modification would have predictably enabled Phan’s authentication architecture to support interoperable EAP based authentication signaling while continuing to provide Phan’s preliminary serving network authentication check. (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 one of ordinary skill in the art before the effective filing date of the invention to modify the authentication architecture of Phan, as taught by TS 33.501, to relay EAP AKA′ authentication messages between the communication device and the authentication server while retaining Phan’s security anchor response checking operation. TS 33.501 teaches EAP-AKA′ as a standardized authentication alternative involving the UE, SEAF, and AUSF and using AKA challenge-response information, including RAND. The modification would have predictably enabled Phan’s authentication architecture to support interoperable EAP based authentication signaling while continuing to provide Phan’s preliminary serving network authentication check. (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 one of ordinary skill in the art before the effective filing date of the invention to modify the authentication architecture of Phan, as taught by TS 33.501, to relay EAP AKA′ authentication messages between the communication device and the authentication server while retaining Phan’s security anchor response checking operation. TS 33.501 teaches EAP-AKA′ as a standardized authentication alternative involving the UE, SEAF, and AUSF and using AKA challenge-response information, including RAND. The modification would have predictably enabled Phan’s authentication architecture to support interoperable EAP based authentication signaling while continuing to provide Phan’s preliminary serving network authentication check. (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
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 2006/0253703 A1 - a method for delivering certificates in a communication system using Extensible Authentication Protocol (EAP).
US 2003/0233546 A1- A challenge response authentication procedure includes masking of the expected response (XRES) generated by an authentication center by means of a masking function (.function.), and transmission of the masked expected response (XRES'), instead of the expected response itself, to an intermediate party at which the actual user authentication takes place.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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
/ALEXANDER LAGOR/Supervisory Patent Examiner, Art Unit 2437
Prosecution Insights