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 .
Response to Amendment
The Amendment filed March 17, 2026 has been entered. Claims 1-20 are pending in the application. Applicant has submitted amendments to the claims along with other remarks. Applicant’s amendments regarding the drawings have overcome the objection. Applicant’s amendments regarding 112(b) have overcome the rejection. Claims 1-20 are still rejected by prior art references, refer to the following rejection for details.
Response to Arguments
Applicant’s arguments and amendments, see pp. 8-10 of the response, filed March 17, 2026, with respect to the rejection(s) of claim(s) 1-20 under § 102 have been fully considered but are not persuasive, please see the rejection for details.
Regarding Applicant’s contention that “the Blog does not describe or suggest an authentication request message routed from a non-3GPP device that is unable to authenticate directly with the core network,” Applicant focuses on the non-3GPP portion of the Blog. Importantly, the term “N3IWF” is a term that indicates an ability to authenticate indirectly with the core network. The newly cited reference entitled, “Untrusted Non-3GPP Access with 5G Core” explains the meaning of this term used in the primary reference as one that would meet every new element of the pending claim.
As shown in the “Architecture” of Figure 2, the UE is unable to authenticate directly with the core network and relies on the N3IWF to register over the “IPsec Tunneling for CP” connection.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Claims 1 and 14 recite “unable to authenticate directly with the core network.” .
MPEP § 2173.05(i) provides, “[t]he mere absence of a positive recitation is not basis for an exclusion.” And, ‘[a]ny claim containing a negative limitation which does not have basis in the original disclosure should be rejected under 35 U.S.C. 112(a).” Applicant cites to [0020-23] in the specification, but those paragraphs do not provide for the term “unable to authenticate directly with the core network.”
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Non-patent Literature entitled, “A Comparative Introduction to 4G and 5G Authentication” (hereinafter “CableLabs”.
Regarding claim 1, CableLabs teaches: A system for authenticating a core network comprising: a computing device (e.g., Figure 4, serving network device or home network devices) comprising at least one processor in communication with at least one memory device, wherein the computing device is a part of the core network, and wherein the at least one memory device stores a plurality of instructions, which when executed by the at least one processor cause the at least one processor to: receive, from a gateway, an authentication request message (p. 8/20 For simplicity, generic messages such as Authentication Request and Authentication Response are used in Figure 4 without referring to the actual authentication service names.) routed from a non-3GPP device that is unable to authenticate directly with the core network, wherein the non-3GPP device is located on a network behind the gateway (Figure 3 – Non-3GPP Access Network); transfer the authentication request message to a unified data management function of the core network (p. 8/20 Upon success, the AUSF sends an authentication request to UDM/ARPF.); select, by the unified data management function, an authentication method based upon the authentication request (p. 8/20 If a SUCI is provided by the AUSF, then the SIDF will be invoked to decrypt the SUCI to obtain the SUPI, which is further used to select the authentication method configured for the subscriber.); transmit an authentication challenge message to the non-3GPP device (p. 9/20 The SEAF stores the HXRES and sends the AUTH token in an authentication request to the UE. The UE validates the AUTH token by using the secret key it shares with the home network.); receive, from the gateway, the authentication response from the non-3GPP device (p. 9/20 The UE continues the authentication by computing and sending the SEAF a RES token, which is validated by the SEAF. Upon success, the RES token is further sent by the SEAF to the AUSF for validation.); verify the authentication response (p. 9/20 The UE continues the authentication by computing and sending the SEAF a RES token, which is validated by the SEAF. Upon success, the RES token is further sent by the SEAF to the AUSF for validation.); and transmit the authentication result to the non-3GPP device (p. 7/20 A unified authentication framework has been defined to make 5G authentication both open (e.g., with the support of EAP) and access-network agnostic (e.g., supporting both 3GGP access networks and non-3GPP access networks such as Wi-Fi and cable networks) (see Figure 3). pp. 10-11/20 The AMF will then derive from the KAMF (a) the confidentiality and integrity keys needed to protect signaling messages between the UE and the AMF and (b) another key, KgNB, which is sent to the Next Generation NodeB (gNB) base station for deriving the keys used to protect subsequent communication between the UE and the gNB. Since the protocol is access-network agnostic the AMF/gNB are interchangeable with Non-3GPP access).
Regarding claim 2, CableLabs teaches: wherein the core network is a 5G core network (p. 1/20 Because additional authentication methods are defined in 5G, wireless practitioners often ask what motivates the adoption of these new authentication methods in 5G and how they differ from 4G authentication.).
Regarding claim 3, CableLabs teaches: wherein the selected authentication method is the Extensible Authentication Protocol Authentication and Key Agreement (EAP-AKA’) (p. 3/20 This paper provides an overview of the 4G and 5G authentication methods defined by the3GPP—4G EPS-AKA and 5G AKA, EAP-AKA’, and EAP-TLS. It also highlights the differences between 4G AKA and 5G AKA protocols and among the three 5G authentication methods.), and wherein the instructions further cause the at least one processor to generate, by the unified data management function, an EAP-AKA’ authentication vector based upon the authentication request (p. 6/20 Unified data management (UDM) is an entity that hosts functions related to data management, such as the Authentication Credential Repository and Processing Function (ARPF), which selects an authentication method based on subscriber identity and configured policy and computes the authentication data and keying materials for the AUSF if needed. p. 8/20 UDM/ARPF starts 5G-AKA by sending the authentication response to the AUSF with an authentication vector consisting of an AUTH token, an XRES token, the key K, and the SUPI if applicable (e.g., when a SUCI is included in the corresponding authentication request), among other data.).
Regarding claim 4, CableLabs teaches: wherein the instructions further cause the at least one processor to: store at least a portion of the authentication vector prior to transmitting the authentication challenge message (Figure 4, step 6); and verify the authentication response based upon the stored portion of the authentication vector (Figure 4, step 13).
Regarding claim 5, CableLabs teaches: wherein the at least a portion of the authentication vector includes an expected response (XRES) (Figure 4, step 6 “XRES”).
Regarding claim 6, CableLabs teaches: wherein the instructions further cause the at least one processor to generate the authentication vector using an Access Network Identity as an KDF (key derivative function) input parameter (Figure 4, Step 4, SUPI -> Generate AV).
Regarding claim 7, CableLabs teaches: wherein the instructions further cause the at least one processor to transmit, by the unified data management function, an master session key (MSK) to indicate that the non-3GPP device does not support a 5G key hierarchy (p. 11/20 Key derivation differs slightly. In 5G-AKA, the KAUSF is computed by UDM/ARPF and sent to the AUSF. In EAP-AKA’, the AUSF derives the KAUSF itself in part based on the keying materials received from UDM/ARPF. More specifically, the AUSF derives an Extended Master Session Key (EMSK) based on the keying materials received from UDM according to EAP and then uses the first 256 bits of the EMSK as the KAUSF.).
Regarding claim 8, CableLabs teaches: wherein the access request message includes at least one of a Subscription Permanent Identifier (SUPI) or a Subscription Concealed Identifier (SUCI) for the non-3GPP device (Figure 4, Steps 1-3, SUCI, SUPI).
Regarding claim 9, CableLabs teaches: wherein the instructions further cause the at least one processor to invokes, by the unified data management function, a SIDF (Subscription Identifier De-Concealing Function) to map the SUCI to the SUPI to select an authentication method (such as EAP-AKA’) based on the SUPI (p. 6/20 The Subscription Identifier De-concealing Function (SIDF) decrypts a Subscription Concealed Identifier (SUCI) to obtain its long-term identity, namely the Subscription Permanent Identifier (SUPI), e.g., the IMSI. In 5G, a subscriber long-term identity is always transmitted over the radio interfaces in an encrypted form. More specifically, a public key-based encryption is used to protect the SUPI. Therefore, only the SIDF has access to the private key associated with a public key distributed to UEs for encrypting their SUPIs.).
Regarding claim 10, CableLabs teaches: wherein when the "username" part of the SUPI is "anonymous" or omitted, the instructions further cause the at least one processor to select the authentication method based upon a “realm” part of the SUPI, an AUN3 device indicator, a combination of the "realm" part and the AUN3 device indicator, or a UDM local policy (p. 6/20 Unified data management (UDM) is an entity that hosts functions related to data management, such as the Authentication Credential Repository and Processing Function (ARPF), which selects an authentication method based on subscriber identity and configured policy and computes the authentication data and keying materials for the AUSF if needed.).
Regarding claim 11, CableLabs teaches: wherein the selected authentication method is one of EAP-TLS (Extensible Authentication Protocol-Transport Layer Security) or EAP-TTLS (EAP-Tunneled TLS) (p. 6/20 The next section introduces the 5G authentication framework and three authentication methods: 5G-AKA, EAP-AKA’, and EAP-TLS.).
Regarding claim 12, CableLabs teaches: wherein the instructions further cause the at least one processor to use an Authentication Server Function (AUSF) to perform the selected authentication method with the non-3GPP device (p. 11/20 EAP-TLS[8] is defined in 5G for subscriber authentication in limited use cases such as private networks and IoT environments. When selected as the authentication method by UDM/ARPF, EAP-TLS is performed between the UE and the AUSF through the SEAF, which functions as a transparent EAP authenticator by forwarding EAP-TLS messages back and forth between the UE and the AUSF. To accomplish mutual authentication, both the UE and the AUSF can verify each other’s certificate or a pre-shared key (PSK) if it has been established in a prior Transport Layer Security (TLS) handshaking or out of band. At the end of EAP-TLS, an EMSK is derived, and the first 256 bits of the EMSK is used as the KAUSF. As in 5G-AKA and EAP-AKA’, the KAUSF is used to derive the KSEAF, which is further used to derive other keying materials (see Figure 5) needed to protect communication between the UE and the network.).
Regarding claim 13, CableLabs teaches: wherein the gateway is a residential gateway (p. 14/20 For example, in the scenario of wireless and wireline convergence, a piece of user equipment such as a laptop behind a residential gateway may not have a USIM; it would not be able to execute AKA protocols even though it needs to be able to register and connect to the 5G core. In such a case, non-AKA-based methods such as EAP-TLS or EAP-TTLS can be used to authenticate the user to the 5G core.).
Regarding claim 14, CableLabs teaches: A server for authenticating a core network, comprising: a transceiver configured for operable communication with at least one gateway external to the core network (e.g., Figure3, Figure 4, serving network device or home network devices); a processor including a memory configured to store computer-executable instructions, which, when executed by the processor, cause the server to: receive, from a gateway, an authentication request message (p. 8/20 For simplicity, generic messages such as Authentication Request and Authentication Response are used in Figure 4 without referring to the actual authentication service names.) routed from a non-3GPP device that is unable to authenticate directly with the core network, wherein the non-3GPP device is located on a network behind the gateway (Figure 3 – Non-3GPP Access Network); transfer the authentication request message to a unified data management function of the core network (p. 8/20 Upon success, the AUSF sends an authentication request to UDM/ARPF.); select, by the unified data management function, an authentication method based upon the authentication request (p. 8/20 If a SUCI is provided by the AUSF, then the SIDF will be invoked to decrypt the SUCI to obtain the SUPI, which is further used to select the authentication method configured for the subscriber.); transmit an authentication challenge message to the non-3GPP device (p. 9/20 The SEAF stores the HXRES and sends the AUTH token in an authentication request to the UE. The UE validates the AUTH token by using the secret key it shares with the home network.); receive, from the gateway, the authentication response from the non-3GPP device (p. 9/20 The UE continues the authentication by computing and sending the SEAF a RES token, which is validated by the SEAF. Upon success, the RES token is further sent by the SEAF to the AUSF for validation.); verify the authentication response (p. 9/20 The UE continues the authentication by computing and sending the SEAF a RES token, which is validated by the SEAF. Upon success, the RES token is further sent by the SEAF to the AUSF for validation.); and transmit the authentication result to the non-3GPP device (p. 7/20 A unified authentication framework has been defined to make 5G authentication both open (e.g., with the support of EAP) and access-network agnostic (e.g., supporting both 3GGP access networks and non-3GPP access networks such as Wi-Fi and cable networks) (see Figure 3). pp. 10-11/20 The AMF will then derive from the KAMF (a) the confidentiality and integrity keys needed to protect signaling messages between the UE and the AMF and (b) another key, KgNB, which is sent to the Next Generation NodeB (gNB) base station for deriving the keys used to protect subsequent communication between the UE and the gNB. Since the protocol is access-network agnostic the AMF/gNB are interchangeable with Non-3GPP access).
Regarding claim 15, CableLabs teaches: wherein the core network is a 5G core network (p. 1/20 Because additional authentication methods are defined in 5G, wireless practitioners often ask what motivates the adoption of these new authentication methods in 5G and how they differ from 4G authentication.).
Regarding claim 16, CableLabs teaches: wherein the selected authentication method is the Extensible Authentication Protocol Authentication and Key Agreement (EAP-AKA’) (p. 3/20 This paper provides an overview of the 4G and 5G authentication methods defined by the3GPP—4G EPS-AKA and 5G AKA, EAP-AKA’, and EAP-TLS. It also highlights the differences between 4G AKA and 5G AKA protocols and among the three 5G authentication methods.), and wherein the instructions further cause the at least one processor to generate, by the unified data management function, an EAP-AKA’ authentication vector based upon the authentication request (p. 6/20 Unified data management (UDM) is an entity that hosts functions related to data management, such as the Authentication Credential Repository and Processing Function (ARPF), which selects an authentication method based on subscriber identity and configured policy and computes the authentication data and keying materials for the AUSF if needed. p. 8/20 UDM/ARPF starts 5G-AKA by sending the authentication response to the AUSF with an authentication vector consisting of an AUTH token, an XRES token, the key K, and the SUPI if applicable (e.g., when a SUCI is included in the corresponding authentication request), among other data.).
Regarding claim 17, CableLabs teaches: wherein the instructions further cause the at least one processor to: store at least a portion of the authentication vector prior to transmitting the authentication challenge message (Figure 4, step 6); and verify the authentication response based upon the stored portion of the authentication vector (Figure 4, step 13).
Regarding claim 18, CableLabs teaches: wherein the at least a portion of the authentication vector includes an expected response (XRES) (Figure 4, step 6 “XRES”).
Regarding claim 19, CableLabs teaches: wherein the instructions further cause the at least one processor to generate the authentication vector using an Access Network Identity as an KDF (key derivative function) input parameter (Figure 4, Step 4, SUPI -> Generate AV).
Regarding claim 20, CableLabs teaches: wherein the instructions further cause the at least one processor to transmit, by the unified data management function, a master session key (MSK) to indicate that the non-3GPP device does not support a 5G key hierarchy (p. 11/20 Key derivation differs slightly. In 5G-AKA, the KAUSF is computed by UDM/ARPF and sent to the AUSF. In EAP-AKA’, the AUSF derives the KAUSF itself in part based on the keying materials received from UDM/ARPF. More specifically, the AUSF derives an Extended Master Session Key (EMSK) based on the keying materials received from UDM according to EAP and then uses the first 256 bits of the EMSK as the KAUSF.).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
U.S. Publication No. 2024/0298174 (Rajadurai) related to a method and system for authenticating a US for accessing a Non-3GPP service.
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JUSTIN BARRY whose telephone number is (571)272-0201. The examiner can normally be reached 8:00am EST to 5:00pm EST.
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, Jinsong HU can be reached at (571) 272-3965. 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.
/JAB/ Examiner, Art Unit 2643
/YUWEN PAN/ Supervisory Patent Examiner, Art Unit 2649
Prosecution Insights