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 .
Information Disclosure Statement
The Information Disclosure Statement submitted on 09/10/2025 and 02/03/2025 have been considered by the examiner (see attached PTO-1449 form).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tiwari (WO 2023/068118A1) in view of Tamura (US 20220264295).
Regarding claims 1, 7 and claim 13, Tiwari teaches a method for an access and mobility management function (AMF), the method comprising:
receiving, from a wireless transmit receive unit (WTRU) (UE), a registration request message indicating the WTRU intends to use a system feature ([Requested NSSAI], [Mapping Of Requested NSSAI])
(See Fig. 15, At Step 1, RAN receives a Registration Request from UE. At step 3, New AMF receives the Registration Request which includes a system feature the UE intends to use (“Requested NSSAI], [Mapping Of Requested NSSAI]”).
See also [0451]:"1. UE to (R)AN: AN message (AN parameters, Registration Request (Registration type, SUCI or 5G-GUTI or PEI, [last visited TAI (if available)], Security parameters, [Requested NSSAI], [Mapping Of Requested NSSAI] ...[Requested Active Time], [Requested DRX parameters for E-UTRA and NR]",
[0486]:"The (R)AN selects an AMF as described in clause 6.3.5 of TS 23.501 [2]. If UE is in CM-CONNECTED state, the (R)AN can forward the Registration Request message to the AMF based on the N2 connection of the UE";
[0488]:"3. (R)AN to new AMF: N2 message (N2 parameters, Registration Request (as described in step 1) and [LTE-M Indication]")
sending, to the WTRU, a registration accept message indicating that the system feature is supported ([Allowed NSSAI], [Mapping Of Allowed NSSAI]) by the network and
(see [0606]:"The Allowed NSSAI for the Access Type for the UE is included in the N2 message carrying the Registration Accept message. The Allowed NSSAI contains only S-NSSAIs that do not require, based on subscription information, Network Slice-Specific Authentication and Authorization and, based on the UE Context in the AMF, those S-NSSAIs for which Network Slice-Specific Authentication and Authorization previously succeeded, regardless of the Access Type. The Mapping Of Pending NSSAI is the mapping of each S-NSSAI of the Pending NSSAI for the Serving PLMN to the HPLMN S-NSSAIs";
the WTRU may use the system feature on a condition the network validates that the WTRU supports the system feature;
(See [0604]:"21. New AMF to UE: Registration Accept (5G-GUTI, Registration Area, [Mobility restrictions], [PDU Session status], [Allowed NSSAI], [Mapping Of Allowed NSSAI], [Configured NSSAI for the Serving PLMN], [Mapping Of Configured NSSAI], [NSSRG Information], [rejected S-NSSAIs], [Pending NSSAI], [Mapping Of Pending NSSAI]…";
[0607]:"If the UE has indicated its support of the Network Slice-Specific Authentication and Authorization procedure in the UE MM Core Network Capability in the Registration Request, AMF includes in the Pending NSSAI the S-NSSAIs that map to an S-NSSAI of the HPLMN which in the subscription information has indication that it is subject to Network Slice-Specific Authentication and Authorization, as described in clause 4.6.2.4 of TS 24.501 [25]. In such case, the AMF then shall trigger at step 25 the Network Slice-Specific Authentication and Authorization procedure, specified in clause 4.2.9.2, except, based on Network policies, for those S-NSSAIs for which Network Slice-Specific Authentication and Authorization have already been initiated on another Access Type for the same S-NSSAI(s). The UE shall not attempt re-registration with the S-NSSAIs included in the list of Pending NSSAIs until the Network Slice-Specific Authentication and Authorization procedure has been completed, regardless of the Access Type")
sending, to the WTRU, a system feature validation trigger;
(see [0607]:"If the UE has indicated its support of the Network Slice-Specific Authentication and Authorization procedure in the UE MM Core Network Capability in the Registration Request, AMF includes in the Pending NSSAI the S-NSSAIs that map to an S-NSSAI of the HPLMN which in the subscription information has indication that it is subject to Network Slice-Specific Authentication and Authorization, as described in clause 4.6.2.4 of TS 24.501 [25]. In such case, the AMF then shall trigger at step 25 the Network Slice-Specific Authentication and Authorization procedure, specified in clause 4.2.9.2, except, based on Network policies, for those S-NSSAIs for which Network Slice-Specific Authentication and Authorization have already been initiated on another Access Type for the same S-NSSAI(s). The UE shall not attempt re-registration with the S-NSSAIs included in the list of Pending NSSAIs until the Network Slice-Specific Authentication and Authorization procedure has been completed, regardless of the Access Type". Note: "the S-NSSAIs that map to an S-NSSAI of the HPLMN which in the subscription information has indication that it is subject to Network Slice-Specific Authentication and Authorization" in the "Pending NSSAI" is equated to "system feature validation trigger", since the "UE shall not attempt re-registration with the S-NSSAIs included in the list of Pending NSSAIs until the Network Slice-Specific Authentication and Authorization procedure has been completed", i.e. until the "system feature", i.e. any of the NSSAIs in the "pending NSSAIs" list, has been "validated";
Note: The above interpretation is in line with feature "310" in Figure 3 described in the present application. See present Application’s publication [0097]:"At step 310, the WTRU may consider that access to the system feature is pending validation. When a system feature is pending validation, the WTRU may not attempt to use, request, or activate the system procedure until the system feature is validated. The Registration Response may inform the WTRU to wait for the network to trigger a validation procedure or that the WTRU should trigger the validation procedure");
receiving, from a network entity, a validation result message (deliver an "Allowed NSSAI containing the S-NSSAIs for which the Network Slice-Specific Authentication and Authorization was successful, and include any rejected NSSAIs") associated with the system feature validation trigger the validation result message indicating whether the WTRU is validated (S-NSSAIs for which the Network Slice-Specific Authentication and Authorization was successful) or not validated (rejected NSSAIs) to use the system feature;
(see [0665]: "25. [Conditional] If the UE indicates its support for Network Slice-Specific Authentication and Authorization procedure in the UE MM Core Network Capability in Registration Request, and any S-NSSAI of the HPLMN is subject to Network Slice-Specific Authentication and Authorization, the related procedure is executed at this step (see clause 4.2.9.1). Once the Network Slice-Specific Authentication and Authorization procedure is completed for all S-NSSAIs, the AMF shall trigger a UE Configuration Update procedure to deliver an Allowed NSSAI containing also the S-NSSAIs for which the Network Slice-Specific Authentication and Authorization was successful, and include any rejected NSSAIs with an appropriate rejection cause value"; Note: “validation result message” is equated to "Allowed NSSAI containing the S-NSSAIs for which the Network Slice-Specific Authentication and Authorization was successful, and include any rejected NSSAIs”; wherein the "Allowed NSSAIs" are equated to "validated" to be used by the UE and the "rejected NSSAIs" are equated to "not validated" to be used by the UE, the allowed/rejected "NSSAIs" equated to "system features") and
sending a configuration update message based on the received validation result message, and
(see [0665]:"25. [Conditional] If the UE indicates its support for Network Slice-Specific Authentication and Authorization procedure in the UE MM Core Network Capability in Registration Request, and any S-NSSAI of the HPLMN is subject to Network Slice-Specific Authentication and Authorization, the related procedure is executed at this step (see clause 4.2.9.1). Once the Network Slice-Specific Authentication and Authorization procedure is completed for all S-NSSAIs, the AMF shall trigger a UE Configuration Update procedure to deliver an Allowed NSSAI containing also the S-NSSAIs for which the Network Slice-Specific Authentication and Authorization was successful, and include any rejected NSSAIs with an appropriate rejection cause value").
Tiwari teaches sending a configuration update message but does not explicitly teach sending the configuration update message to the WTRU.
In an analogous art, Tamura teaches sending, to the WTRU (UE), a configuration update message ([0079] “In step 303, the AMF 2 sends a UE Configuration Update Command message to the UE 1 indicating that the particular S-NSSAI is to be removed from the Allowed NSSAI and included in the Pending NSSAI”.) Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to modify Tiwari 's teaching of configuration update message to include Tamura's teaching of sending the configuration update message to the WTRU in order to allow the network to conveniently refresh the UE’s mobility and registration context without requiring a full re-registration.
With further regard to claim 7, Tiwari further teaches a network node including an access and mobility management function (AMF) (Fig. 12), the network node comprising: a transceiver (Fig. 12, 701) and a processor (Fig. 12, controller 703) operatively coupled to the transceiver, the transceiver and processor configured to perform the method of claim 1. Therefore, claim 7 is rejected for the same reasons as claim 1.
With further regard to claim 13, it has similar limitations as that of method claim 1 and thus is rejected for the same reasons as claim 1.
Regarding claim 2, 8 and claim 14, Tiwari and Tamura teach the method of claim 1, wherein Tiwari teaches the system feature validation trigger including information for performing a validation procedure for the WTRU to use the system
(see [0607]:"If the UE has indicated its support of the Network Slice-Specific Authentication and Authorization procedure in the UE MM Core Network Capability in the Registration Request, AMF includes in the Pending NSSAI the S-NSSAIs that map to an S-NSSAI of the HPLMN which in the subscription information has indication that it is subject to Network Slice-Specific Authentication and Authorization, as described in clause 4.6.2.4 of TS 24.501 [25]. In such case, the AMF then shall trigger at step 25 the Network Slice-Specific Authentication and Authorization procedure, specified in clause 4.2.9.2, except, based on Network policies, for those S-NSSAIs for which Network Slice-Specific Authentication and Authorization have already been initiated on another Access Type for the same S-NSSAI(s). The UE shall not attempt re-registration with the S-NSSAIs included in the list of Pending NSSAIs until the Network Slice-Specific Authentication and Authorization procedure has been completed, regardless of the Access Type". Note: "the S-NSSAIs that map to an S-NSSAI of the HPLMN which in the subscription information has indication that it is subject to Network Slice-Specific Authentication and Authorization" in the "Pending NSSAI" is equated to "system feature validation trigger".
Tiwari does not teach a downlink (DL) non-access stratum (NAS) message. Tamura teaches a downlink (DL) non-access stratum (NAS) message.
(Tamura, [0080], " The UE Configuration Update Command message shown in FIG. 3 is one typical example of a message that can be used to cause the UE 1 to update the UE NSSAI configuration. However, the AMF 2 may instruct or request the UE 1 to update the UE NSSAI configuration via any other NAS message. For example, the AMF 2 may use a NAS message (e.g., Network Slice-Specific Authentication Command) that is sent from the AMF 2 to the UE 1 during a re-authentication and re-authorization procedure for the particular S-NSSAI… ";
[0106]:" ... The NAS message may contain a Pending NSSAI IE containing the particular S-NSSAI. As another example, the NAS message may contain an updated Allowed NSSAI with the particular S-NSSAI removed from it and an updated Pending NSSAI with the particular S-NSSAI added to it. Additionally or alternatively, the NAS message(e.g., DL NAS Transport message) may contain a new cause IE (e.g., 5GMM Cause IE) indicating that a re-authentication and re-authorization procedure is ongoing ").
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to modify Tiwari's teaching of validation system to include Tamura's teaching of using a downlink (DL) non-access stratum (NAS) message because the DL NAS message enables efficient, reliable, and secure control-plane signaling between the User Equipment (UE) and the core network.
Regarding claim 3, 9 and claim 15, Tiwari and Tamura teach the method of claim 2, wherein Tiwari teaches the information for performing the validation procedure (see [0607]:"If the UE has indicated its support of the Network Slice-Specific Authentication and Authorization procedure in the UE MM Core Network Capability in the Registration Request, AMF includes in the Pending NSSAI the S-NSSAIs that map to an S-NSSAI of the HPLMN which in the subscription information has indication that it is subject to Network Slice-Specific Authentication and Authorization, as described in clause 4.6.2.4 of TS 24.501 [25]. In such case, the AMF then shall trigger at step 25 the Network Slice-Specific Authentication and Authorization procedure, specified in clause 4.2.9.2, except, based on Network policies, for those S-NSSAIs for which Network Slice-Specific Authentication and Authorization have already been initiated on another Access Type for the same S-NSSAI(s). The UE shall not attempt re-registration with the S-NSSAIs included in the list of Pending NSSAIs until the Network Slice-Specific Authentication and Authorization procedure has been completed, regardless of the Access Type". Note: "the S-NSSAIs that map to an S-NSSAI of the HPLMN which in the subscription information has indication that it is subject to Network Slice-Specific Authentication and Authorization" in the "Pending NSSAI" is equated to "system feature validation trigger".
However, Tiwari does not teach an extensible authentication protocol (EAP) identity request. Tamura teaches an extensible authentication protocol (EAP) identity request.
(See [0013], ".. A Pending NSSAI indicates one or more S-NSSAIs for which Network Slice-Specific Authentication and Authorization (NSSAA)) is pending. A Serving PLMN shall perform NSSAA for S-NSSAIs of the HPLMN which are subject to NSSAA based on subscription information. In order to perform NSSAA, an AMF invokes an Extensible Authentication Protocol (EAP)-based authorization procedure….";
[0089]:"The AMF 2 may send an authentication request message to the AUSF 4 in order to initiate (or trigger the initiation of) the re-authentication and re-authorization procedure.... The AMF 2 may send the UE User ID for EAP authentication (EAP ID) for the S-NSSAI that needs to be (re)authenticated to the AUSF 4 in the above message, or in a separate message to the AUSF 4. .. The AMF2 may send the address of the AAA-S to the AUSF4 by including it in the above message, or it may send it to the AUSF4 by another message. Prior to this, the AMF 2 may request the UE 1 for the EAP ID for the relevant S-NSSAI").
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to modify Tiwari's teaching of validation system to include Tamura's teaching of using an extensible authentication protocol (EAP) because the EAP provides a foundational framework for network access security with flexibility to support various authentication methods.
Regarding claim 4, 10 and claim 16, Tiwari and Tamura teach the method of claim 2, wherein the information for performing the validation procedure (Tiwari [0607]:"If the UE has indicated its support of the Network Slice-Specific Authentication and Authorization procedure in the UE MM Core Network Capability in the Registration Request, AMF includes in the Pending NSSAI the S-NSSAIs that map to an S-NSSAI of the HPLMN which in the subscription information has indication that it is subject to Network Slice-Specific Authentication and Authorization, as described in clause 4.6.2.4 of TS 24.501 [25]. In such case, the AMF then shall trigger at step 25 the Network Slice-Specific Authentication and Authorization procedure, specified in clause 4.2.9.2, except, based on Network policies, for those S-NSSAIs for which Network Slice-Specific Authentication and Authorization have already been initiated on another Access Type for the same S-NSSAI(s). The UE shall not attempt re-registration with the S-NSSAIs included in the list of Pending NSSAIs until the Network Slice-Specific Authentication and Authorization procedure has been completed, regardless of the Access Type". Note: "the S-NSSAIs that map to an S-NSSAI of the HPLMN which in the subscription information has indication that it is subject to Network Slice-Specific Authentication and Authorization" in the "Pending NSSAI" is equated to "system feature validation trigger". However, Tiwari does not teach an identity of a user equipment certification validation (UCV) server and a generic public subscription identifier (GPSI) of the WTRU.
Tamura teaches an identity of a user equipment certification validation (UCV) server ("AUSF") and a generic public subscription identifier (GPSI) of the WTRU.
(see [0089]:"The AMF 2 may send an authentication request message to the AUSF 4 in order to initiate (or trigger the initiation of) the re-authentication and re-authorization procedure.. The AMF 2 may send the UE User ID for EAP authentication (EAP ID) for the S-NSSAI that needs to be (re)authenticated to the AUSF 4 in the above message, or in a separate message to the AUSF 4. The AMF 2 may send the Generic Public Subscription Identifier (GPSI) of the UE 1 in the above message to the AUSF 4, or in a separate message to the AUSF 4... Prior to this, the AMF 2 may request the UE 1 for the EAP ID for the relevant S-NSSAI". Note: the "AUSF" is equated to "UCV server".
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to modify Tiwari's teaching of validation system to include Tamura's teaching of using a user equipment certification validation server to necessarily authenticate a User Equipment and using the GPSI to provide Flexibility in Identifier Formats and enabling consistent user addressing across different data networks.
Regarding claim 5 and claim 11, Tiwari and Tamura teach the method of claim 1, wherein the network entity comprises a unified data management (UDM)
(Tiwari [0313] “9a. If authentication is required, the AMF requests it from the AUSF; if Tracing Requirements about the UE are available at the AMF, the AMF provides Tracing Requirements in its request to AUSF. Upon request from the AMF, the AUSF shall execute authentication of the UE. The authentication is performed as described in TS 33.501 [15]. The AUSF selects a UDM as described in clause 6.3.8 of TS 23.501 [2] and gets the authentication data from UDM.)
or a unified data repository (UDR) database.
Regarding claim 6 and claim 12, Tiwari and Tamura teach the method of claim 1, wherein Tamura teach a network entity comprises a user equipment certification validation (UCV) server (AUSF).
(see [0089]:"The AMF 2 may send an authentication request message to the AUSF 4 in order to initiate (or trigger the initiation of) the re-authentication and re-authorization procedure.. The AMF 2 may send the UE User ID for EAP authentication (EAP ID) for the S-NSSAI that needs to be (re)authenticated to the AUSF 4 in the above message, or in a separate message to the AUSF 4. The AMF 2 may send the Generic Public Subscription Identifier (GPSI) of the UE 1 in the above message to the AUSF 4, or in a separate message to the AUSF 4... Prior to this, the AMF 2 may request the UE 1 for the EAP ID for the relevant S-NSSAI", Note: the "AUSF" is equated to "UCV server").
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to modify Tiwari's teaching of validation system to include Tamura's teaching of using a user equipment certification validation server to necessarily authenticate User Equipment to prevent fraudulent UE from accessing the network.
Citation of Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
Rajadurai (US 20230232221) teaches “UDM may perform authorization check on whether the UE and/or AF is authorized to use the AKMA feature, based on at least one of the stored information: the service profile, the subscription data of the UE, allowed list GPSI(s) of the UE allowed list of AF(s) that can serve the UE and list of AF that can use the AKMA service and/or whether the UE is registered in 5GS from the network” ([0179]).
Shekhar (US 20230370950) teaches UE seeks to register with each network slices by sending a registration request to AMF ([0052]). The AMF trigger the NSACF perform per-network slice NSAC registration validation operations (i.e., to check the slice Reg-Quota threshold for each slice) to determine whether there is registration quota left for the UE to register with each slice and will also trigger the NSACF to perform per-network slice NSAC session validation operations” ([0043]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DUNG L LAM whose telephone number is (571)272-6497. The examiner can normally be reached Monday -Thursday 9-5pm.
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, Jeanette Parker can be reached at 571-270-3647. 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.
/DUNG L LAM/Examiner, Art Unit 2646
Prosecution Insights