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 .
DETAILED ACTION
Response to Preliminary Amendment
A preliminary amendment is filed on 10/14/2024. Claims 1-15 are amended, claims 16-20 are new, and claims 1-20 are currently pending.
Priority
This application is a 371 National Stage of International Patent Application No. PCT/EP2022/063810, filed 5/20/2022, also claims foreign priority to Greece Patent Application No. GR20220100323, filed 4/14/2022.
Specification
The abstract of the disclosure is objected to because the Abstract recites “NSWO” and “WLAN AN”. Examiner suggest amending these phrases to “Non-Seamless WLAN Offload (NSWO)” and “Wireless Local Area Network (WLAN) Access Network (AN)”. A corrected abstract of the disclosure is required and must be presented on a separate sheet, apart from any other text. See MPEP § 608.01(b).
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)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-5, 7-13, 15-18 and 20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Rajadurai et al. (US 20240298174 A1 and Rajadurai hereinafter).
Regarding claim 1, Rajadurai teaches a User Equipment (“UE”) for wireless communication (Figure 5), comprising:
at least one memory (Paragraph 0196; the device may also include at least one memory with software modules located therein. The method embodiments described herein could be implemented partly in hardware and partly in software. Alternatively, the invention may be implemented on different hardware devices, e.g. using a plurality of CPUs); and
at least one processor coupled with the at least one memory and configured to cause the UE to (Paragraph 0196; the device may also include means which could be e.g. hardware means like e.g. an ASIC, or a combination of hardware and software means, e.g. an ASIC and an FPGA, or at least one microprocessor and at least one memory with software modules located therein. The method embodiments described herein could be implemented partly in hardware and partly in software. Alternatively, the invention may be implemented on different hardware devices, e.g. using a plurality of CPUs):
connect to a wireless local area network (“WLAN”) access network (“AN”) (Figure 5 and Paragraphs 0066 and 0096; the UE 206 establishes the connection with the WLAN AP 220) using credentials associated with a mobile communication network (Figure 5 and Paragraphs 0070 and 0099; on receiving the identity response of the UE 206, the IWF 218 sends the authentication request to the authentication server 212 [of the mobile communication networks]. The authentication request include the identity response of the UE 206 and an indicator to determine whether the authentication request is for a normal network access authentication or a special case of authentication that indicates the non-3GPP network access authentication), wherein connecting to the WLAN AN comprises performing a first authentication procedure between the UE and the mobile communication network (Figure 5 and Paragraph 0108; the WLAN access authentication (i.e.., the non-3GPP network access authentication) is performed between the UE 206 and the 5GC 210 including the AUSF/AAA-S 212), wherein the first authentication procedure does not register the UE with the mobile communication network (Figure 2 and Paragraphs 0070 and 0071; the authentication request include the identity response of the UE 206 and an indicator to determine whether the authentication request is for a normal network access authentication or a special case of authentication that indicates the non-3GPP network access authentication);
determine to register with the mobile communication network after connecting to the WLAN AN (Figure 5 and Paragraph 0098; WLAN AP 220 discovers the N3IWF 218 for a 5GC registration procedure. Paragraph 0110; the UE 206 may initiate the procedure for the tunnel establishment with the N3IWF 218 along with the 5GC registration procedure);
transmit a first message including a first container (Figure 8 and Paragraph 0129; the UE 206 sends the IKE_AUTH request to the N3IWF 218), wherein the first container is derived based at least in part on information generated by the UE during the first authentication procedure (Figure 8 and Paragraph 0128; a pre-authentication may be performed between the UE 206 and the AAA-S 212 for accessing the WLAN AP 220. Paragraph 0129; the UE 206 derives the key KWLAN directly and calculates an authentication parameter AUTH as specified in IETF RFC 7296 using the derived key KWLAN), and wherein the first message initiates registration with the mobile communication network (Figure 8 and Paragraph 0127; the generation of optimized IKEv2 mutual authentication keys for the tunnel establishment procedure over the 5G-WLAN interworking system using the EMSK derived during the WLAN access authentication procedure for a tunnel establishment request);
receive a second message including a second container (Figure 8 and Paragraph 0130; the AAA-S 212 sends an accesss accept (i.e.., the key KWLAN) to the N3IWF 218, which in turn sends an IKE_AUTH response to the UE 206, wherein the IKE_AUTH response as specified in IETF RFC 7296 includes the mutual authentication keys such as, an IDr, a CERT, an AUTH, a SAr, a TSi, and a TSr), wherein the second container is derived based at least in part on the information generated by the mobile communication network during the first authentication procedure (Figure 8 and Paragraph 0130; the AAA-S 212 derives the key KWLAN, if the UE 206 has been already authenticated for accessing the WLAN AP 220);
validate the second container (Figure 8 and Paragraph 0127; the generation of optimized IKEv2 mutual authentication keys for the tunnel establishment procedure over the 5G-WLAN interworking system using the EMSK derived during the WLAN access authentication procedure for a tunnel establishment request. Figure 9 and Paragraphs 0135 and 0136; the EAP-AKA′/5G-AKA procedure may be trigged to perform a mutual authentication between the UE 206 and the 5GC 210. After authentication the UE 206 (for example, 802.1x using EAP-AKA/EAP-TLS), the AMF 216 derives the key KWLAN from the key KSEAF or the key KAMF and stores the key KWLAN. At steps 11-12, after successful authentication of the UE 206, the UE 206 initiates the tunnel establishment procedure (i.e.., the UE 206 proceeds with the establishment of an IPsec Security Association (SA) with the selected N3IWF 218 by initiating an IKE initial exchange)); and
register with the mobile communication network based at least in part on a successful validation of the second container (Figure 9 and paragraphs 0136 and 0137; after successful authentication of the UE 206, the UE 206 initiates the tunnel establishment procedure).
Regarding claim 2, the combination of Rajadurai and TEST teaches all of the limitations of claim 1, as described above. Further, Rajadurai teaches wherein, to register with the mobile communication network, the at least one processor is configured to cause the UE to bypass a primary authentication between the UE and the mobile communication network during a registration procedure (Paragraphs 0044 and 0084; initiating the authentication server or an Access and Mobility Management Function (AMF) to derive a tunnel session key (TSK) for a tunnel establishment. Embodiments herein also disclose methods and systems for deriving the tunnel session key using a Master Session Key (MSK)/Extended Master Session key (EMSK) derived during a previous authentication).
Regarding claim 3, the combination of Rajadurai and TEST teaches all of the limitations of claim 1, as described above. Further, Rajadurai teaches wherein the first container comprises a first authentication (Figure 8 and Paragraph 0129; the UE 206 derives the key KWLAN directly and calculates an authentication parameter AUTH as specified in IETF RFC 7296 using the derived key KWLAN. At step 5, the UE 206 sends the IKE_AUTH request to the N3IWF 218. The IKE_AUTH request as specified in IETF RFC 7296 includes at least one of, an Idi, a Certificate Request (CERT REQ), a SAi, the authentication parameter (AUTH), a Traffic Selector-initiator (TSi), and Traffic Selector-responder (TSr)).
Regarding claim 4, the combination of Rajadurai and TEST teaches all of the limitations of claim 3, as described above. Further, Rajadurai teaches wherein the at least one processor is configured to: generate a master session key or an extended master session key, or both, during the first authentication procedure (Figure 5, Paragraphs 0019 and 0109; generating, by the authentication server, a Master Session Key (MSK) specific to the non-3GPP network access authentication using the AV for the non-3GPP network access authentication, on verifying that the authentication initiated with the UE is successful); and derive the first authentication code based at least in part on the master session key or the extended master session key, or both (Figure 8, Paragraphs 0035, 0048 and 0112; generation of optimized Internet key exchange version two (IKEv2) mutual authentication keys for a tunnel establishment over the 5G-WLAN interworking system using Extended Master Session key (EMSK) derived during a WLAN access authentication procedure for a tunnel establishment request).
Regarding claim 5, the combination of Rajadurai and TEST teaches all of the limitations of claim 3, as described above. Further, Rajadurai teaches wherein the second container comprises a second authentication code (Figure 8 and Paragraph 0131; the N3IWF 218 sends an IKE_AUTH response to the UE 206, wherein the IKE_AUTH response as specified in IETF RFC 7296 includes the mutual authentication keys such as, an IDr, a CERT, an AUTH, a SAr, a TSi, and a TSr).
Regarding claim 7, the combination of Rajadurai and TEST teaches all of the limitations of claim 1, as described above. Further, Rajadurai teaches wherein the WLAN AN supports 5G connectivity to the mobile communication network (Paragraph 0009; in a trusted TG-WLAN interworking system, a trusted WLAN Access Point (AP) is integrated with the 5GC via a Trusted Non-3GPP Gateway Function (TNGF)), and wherein the at least one processor is configured to cause the UE to: determine to register with the mobile communication network (Figure 5 and Paragraph 0098; at Step 4, the WLAN AP 220 starts a 5GC registration procedure) after connecting to the WLAN Access network (Figure 5 and Paragraph 0096; at Step 1, the UE 206 establishes the connection with the WLAN AP 220. Step 4 occurs after Step 1); and discover a trusted non-3GPP gateway function (“TNGF”) in response to a determination to register with the mobile communication network (Paragraphs 0009 and 0010; in a trusted TG-WLAN interworking system, a trusted WLAN Access Point (AP) is integrated with the 5GC via a Trusted Non-3GPP Gateway Function (TNGF)).
Regarding claim 8, the combination of Rajadurai and TEST teaches all of the limitations of claim 1, as described above. Further, Rajadurai teaches wherein the WLAN AN does not support 5G connectivity to the mobile communication network (Paragraph 0008; in an untrusted 5G-WLAN interworking system, an untrusted WLAN access is integrated with the 5GC via the N3IWF), and wherein the at least one processor is configured to cause the UE to: determine to register with the mobile communication network (Figure 5 and Paragraph 0098; at Step 4, the WLAN AP 220 discovers the N3IWF 218 for a 5GC registration procedure) after connecting to the WLAN Access network (Figure 5 and Paragraph 0096; at Step 1, the UE 206 establishes the connection with the WLAN AP 220. Step 4 occurs after Step 1. Paragraph 0110; at Step 15, after successful authentication of the UE 206, the AUSF/AAA-S 212 sends the success message, the MSK/EMSK, and/or the WLAN access keys to the WLAN AP 220, which in turn forwards these information to the UE 206. The UE 206 may initiate the procedure for the tunnel establishment with the N3IWF 218 along with the 5GC registration procedure); and discover a non-3GPP interworking function (“N3IWF”) in response to a determination to register with the mobile communication network (Paragraph 0110; at Step 15, after successful authentication of the UE 206, the AUSF/AAA-S 212 sends the success message, the MSK/EMSK, and/or the WLAN access keys to the WLAN AP 220, which in turn forwards these information to the UE 206. The UE 206 may initiate the procedure for the tunnel establishment with the N3IWF 218 along with the 5GC registration procedure).
Regarding claim 9, the combination of Rajadurai and TEST teaches all of the limitations of claim 1, as described above. Further, Rajadurai teaches wherein the WLAN AN is a trusted non-3GPP access network for the mobile communication network (Paragraph 0062; the non-3GPP network AP 220 is a trusted AP).
Regarding claim 10, claim 10 recites similar features as claim 1, therefore is rejected for at least the same reason as discussed above regarding claim 1. Further, Rajadurai teaches a processor for wireless communication (Figure 2), comprising:
at least one controller coupled with at least one memory and configured to cause the processor to perform functions (Paragraph 0196; the device may also include means which could be e.g. hardware means like e.g. an ASIC, or a combination of hardware and software means, e.g. an ASIC and an FPGA, or at least one microprocessor and at least one memory with software modules located therein. The method embodiments described herein could be implemented partly in hardware and partly in software. Alternatively, the invention may be implemented on different hardware devices, e.g. using a plurality of CPUs).
Regarding claim 11, claim 11 recites similar features as claim 1 for corresponding steps performed by a network apparatus, therefore is rejected for at least the same reason as discussed above regarding claim 1. Further, Rajadurai teaches a network apparatus in a mobile communication network (Figure 2), the network apparatus (Figure 4) comprising:
a transceiver (Figure 4 and Paragraph 0086; communication interface 404); and
a processor coupled to the transceiver (Figure 4 and Paragraph 0086; a controller 406), the processor configured to cause the network apparatus to perform functions (Figure 4 and Paragraphs 0087 and 0090; controller 406 may perform various functions).
Regarding claim 12, claim 12 recites similar features as claim 2, therefore is rejected for at least the same reason as discussed above regarding claim 2.
Regarding claim 13, claim 13 recites similar features as claim 3, therefore is rejected for at least the same reason as discussed above regarding claim 3.
Regarding claim 15, claim 15 recites similar features as claim 4, therefore is rejected for at least the same reason as discussed above regarding claim 4.
Regarding claim 16, claim 16 recites similar features as claim 11, therefore is rejected for at least the same reason as discussed above regarding claim 11.
Regarding claim 17, claim 17 recites similar features as claim 2, therefore is rejected for at least the same reason as discussed above regarding claim 2.
Regarding claim 18, claim 18 recites similar features as claim 3, therefore is rejected for at least the same reason as discussed above regarding claim 3.
Regarding claim 20, claim 20 recites similar features as claim 4, therefore is rejected for at least the same reason as discussed above regarding claim 4.
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 of this title, 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 6, 14 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Rajadurai, as applied to claims above, further in view of Zhang et al. (US 20240073685 A1 and Zhang hereinafter).
Regarding claim 6, the combination of Rajadurai and TEST teaches all of the limitations of claim 5, as described above. Further, Rajadurai teaches wherein, to validate the second container (Figure 8 and Paragraph 0127; the generation of optimized IKEv2 mutual authentication keys for the tunnel establishment procedure over the 5G-WLAN interworking system using the EMSK derived during the WLAN access authentication procedure for a tunnel establishment request. Figure 9 and Paragraphs 0135 and 0136; the EAP-AKA′/5G-AKA procedure may be trigged to perform a mutual authentication between the UE 206 and the 5GC 210. After authentication the UE 206 (for example, 802.1x using EAP-AKA/EAP-TLS), the AMF 216 derives the key KWLAN from the key KSEAF or the key KAMF and stores the key KWLAN. At steps 11-12, after successful authentication of the UE 206, the UE 206 initiates the tunnel establishment procedure (i.e.., the UE 206 proceeds with the establishment of an IPsec Security Association (SA) with the selected N3IWF 218 by initiating an IKE initial exchange)), the at least one processor is configured to cause the UE to: calculate a first function using a master session key and an extended master session key, or both (Figure 8 and Paragraph 0129; the UE 206 derives the key KWLAN directly and calculates an authentication parameter AUTH as specified in IETF RFC 7296 using the derived key KWLAN. At step 5, the UE 206 sends the IKE_AUTH request to the N3IWF 218. The IKE_AUTH request as specified in IETF RFC 7296 includes at least one of, an Idi, a Certificate Request (CERT REQ), a SAi, the authentication parameter (AUTH), a Traffic Selector-initiator (TSi), and Traffic Selector-responder (TSr)); and compare the first hash to the second authentication code (Figure 9 and Paragraphs 0135 and 0136; the EAP-AKA′/5G-AKA procedure may be trigged to perform a mutual authentication between the UE 206 and the 5GC 210. After authentication the UE 206 (for example, 802.1x using EAP-AKA/EAP-TLS), the AMF 216 derives the key KWLAN from the key KSEAF or the key KAMF and stores the key KWLAN. At steps 11-12, after successful authentication of the UE 206, the UE 206 initiates the tunnel establishment procedure (i.e.., the UE 206 proceeds with the establishment of an IPsec Security Association (SA) with the selected N3IWF 218 by initiating an IKE initial exchange)), wherein the second container is successfully validated when the first authentication code matches the second authentication code (Figure 9 and paragraph 0136; when KN3A from KSEAF and/or KAMF is the same, EAP success).
Rajadurai does not explicitly teach calculate a first hash using a key. In an analogous art, Zhang teaches calculate a first hash using a key (Paragraphs 0459 and 0460; the UE calculates, based on the key K.sub.AUSF, a message authentication code (message authentication code, MAC), which is HMAC-SHA256 (the key K.sub.AUSF, a fresh parameter, an NSWO indicator). The HMAC represents a hash-based message authentication code (hashed-based message authentication)). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of Rajadurai and Zhang because there is a urgent need to implmenet authentication on the terminal device for the non-seamless wireless local area network offload (NSWO)) service in the 5G network (Zhang, Paragraph 0005).
Regarding claim 14, claim 14 recites similar features as claim 6, therefore is rejected for at least the same reason as discussed above regarding claim 6.
Regarding claim 19, claim 19 recites similar features as claim 6, therefore is rejected for at least the same reason as discussed above regarding claim 6.
Pertinent but not Cited References
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Wang et al. (US 20250274751 A1) discloses authentication for non-seamless wlan offload (NSWO).
Gupta et al. (US 20240251239 A1) discloses support NSWO for users with credentials defined in a 5GC, the NSWO authentication procedure may make use of the credentials provided by components of the 5GC.
PALANIGOUNDER et al. (US 20230044847 A1) discloses deployment and use of NSWO with 5G NR communication networks. Various embodiments leverage the enhanced security capability of 5G protocols by implementing NSWO authentication procedures supported by elements of a 5G core network using credentials provided by a function of the 5G core network
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Jing Gao whose telephone number is (571)270-7226. The examiner can normally be reached on 9am - 6pm M-F.
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 Alison Slater can be reached on (571) 270-0375. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Jing Gao/
Primary Examiner, Art Unit 2647
Prosecution Insights