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 .
Preliminary Amendment
The present Office Action is based upon the original patent application filed on 03/08/2024 as modified by the preliminary amendment filed on 03/08/2024. Claims 1-20 are now pending in the present application.
Election/Restrictions
Claims 9-15 withdrawn from further consideration pursuant to 37 CFR 1.142(b) as being drawn to nonelected groups II and III, there being no allowable generic or linking claim. Election was made without traverse in the reply filed on 04/22/2026.
Applicant’s election without traverse of group I (claims 1-8 and 16-20) in the reply filed on 04/22/2026 is acknowledged.
Information Disclosure Statement
The information disclosure statement submitted on 03/08/2024 has been considered by the Examiner and made of record in the application file.
Claim Rejections - 35 USC § 102
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, 3, 6-7, 16 and 18 are rejected under 35 U.S.C. 102(a) (1) as being anticipated by Applicant provide NPL MediaTek et al. (3GPP TSG-SA WG2 Meeting #146E, The supported parameters set type indication for UPU procedure, August 16-27, 2021, hereinafter MediaTek).
Regarding claim 1, MediaTek discloses, an apparatus for performing a first network function (see e.g., Figure 4.2.2.2.2-1, New AMF (access and mobility management function)), the apparatus further comprising:
at least one memory (see e.g., Figure 4.2.2.2.2-1, New AMF with inherent memory and/or “The AMF stores whether the UE supports this feature in the UE context”, lines 23-24); and
at least one processor coupled with the at least one memory (see e.g., Figure 4.2.2.2.2-1, New AMF with inherent processor and memory connected)and configured to cause the apparatus to:
receive a registration request message from a user equipment (UE) (see e.g., “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], [Default Configured NSSAI Indication], [UE Radio Capability Update],…”, Fig. 4.2.2.2.2-1, page 6, lines 1- 10 and/or “3. Registration request”, Fig. 4.2.2.2.2-1; Examiner’s note: registration transmitted to New AMF), wherein the registration request message comprises:
an identity (see e.g., “When the UE is performing an Initial Registration the UE shall indicate its UE identity in the Registration Request message as follows…”, page 6, lines 28-29);
at least one information element (see e.g., “the cleartext IEs, as defined in TS 24.501 [25] that can be sent by the UE in the Registration Request message…”, page 1, lines 20-28 and/or “The UE shall include the entire Registration Request message (i.e. containing cleartext IEs and non-cleartext IEs) in the NAS message container…”, page 7, lines 6-7); and
at least one UE capability (see e.g., “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], [Default Configured NSSAI Indication], [UE Radio Capability Update],…”, Fig. 4.2.2.2.2-1, page 6, lines 1-3);
a processor to determine release information of the UE by analyzing the identity, the at least one information element, and the at least one UE capability (see e.g., “3. Registration request”, Fig. 4.2.2.2.2-1, step 3 and/or “When the UE is performing an Initial Registration the UE shall indicate its UE identity in the Registration Request message as follows…5G-GUTI or PEI…4G tracking Area update”, page 6, lines 28-34 and/or “the cleartext IEs, as defined in TS 24.501 [25] that can be sent by the UE in the Registration Request message…”, page 1, lines 20-28 and/or “UE to (R)AN: AN message (AN parameters, Registration Request (Registration type, SUCI or 5G-GUTI or PEI…[UE Radio Capability Update],…”, Fig. 4.2.2.2.2-1, page 6, lines 1-3; Examiner’s note: based on paragraph [0095] of specification “release information of the UE” relates to when the UE was release, (i.e., UE belongs to 2G, 3G, 4G or 5G)); and
a transmitter to transmit to a second network (see e.g., “14a. Nudm_UECM_Registration”, Fig. 4.2.2.2.2-1, step 14a and/or “the new AMF registers with the UDM using Nudm_UECM_Registration for the access to be registered”, page 12, lines 47-48) function:
the identity (see e.g., “If the PEI was retrieved by the AMF ( either from the UE or another AMF), AMF shall provide it to the UDM using Nudm_ UECM_Registration in order to ensure that the UDM always has the latest PEI available”, sec. 5.2.3.2.1, page 22, line 1-2); and
the release information of the UE (see e.g., “If the PEI was retrieved by the AMF ( either from the UE or another AMF), AMF shall provide it to the UDM using Nudm_ UECM_Registration in order to ensure that the UDM always has the latest PEI available”, sec. 5.2.3.2.1, page 22, line 1-2 and/or “UE to (R)AN: AN message (AN parameters, Registration Request (Registration type, SUCI or 5G-GUTI or PEI…[UE Radio Capability Update],…”, Fig. 4.2.2.2.2-1, page 6, lines 1-3).
Regarding claim 3, MediaTek discloses, wherein the identity comprises a subscription concealed identifier (SUCI), a fifth generation (5G) global unique temporary identifier (5G-GUTI) (see e.g., “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], [Default Configured NSSAI Indication], [UE Radio Capability Update],…”, Fig. 4.2.2.2.2-1, page 6, lines 1- 10).
Regarding claim 6, MediaTek discloses, wherein the first network function comprises an access and mobility management function (AMF) (see e.g., “The new AMF provides the Access Type it serves for the UE to the UDM and the Access Type is set to "3GPP access"”, page 13, lines 33-34, and/or Fig. 4.2.2.2.2-1, step 3, “3. Registration Request”).
Regarding claim 7, MediaTek discloses, wherein the second network function comprises a unified data management (UDM) (see e.g., “The new AMF provides the Access Type it serves for the UE to the UDM and the Access Type is set to "3GPP access"”, page 13, lines 33-34, and/or Fig. 4.2.2.2.2-1, step 9, “9. Authentication/Security”).
Regarding claim 16, MediaTek discloses, a method of a network function (see e.g., Figure 4.2.2.2.2-1, New AMF (access and mobility management function)), the method comprising:
receiving a registration request message from a user equipment (UE) (see e.g., “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], [Default Configured NSSAI Indication], [UE Radio Capability Update],…”, Fig. 4.2.2.2.2-1, page 6, lines 1- 10 and/or “3. Registration request”, Fig. 4.2.2.2.2-1; Examiner’s note: registration transmitted to New AMF), wherein the registration request message comprises:
an identity (see e.g., “When the UE is performing an Initial Registration the UE shall indicate its UE identity in the Registration Request message as follows…”, page 6, lines 28-29);
at least one information element (see e.g., “the cleartext IEs, as defined in TS 24.501 [25] that can be sent by the UE in the Registration Request message…”, page 1, lines 20-28 and/or “The UE shall include the entire Registration Request message (i.e. containing cleartext IEs and non-cleartext IEs) in the NAS message container…”, page 7, lines 6-7); and
at least one UE capability (see e.g., “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], [Default Configured NSSAI Indication], [UE Radio Capability Update],…”, Fig. 4.2.2.2.2-1, page 6, lines 1-3);
determining release information of the UE by analyzing the identity, the at least one information element, and the at least one UE capability (see e.g., “3. Registration request”, Fig. 4.2.2.2.2-1, step 3 and/or “When the UE is performing an Initial Registration the UE shall indicate its UE identity in the Registration Request message as follows…5G-GUTI or PEI…4G tracking Area update”, page 6, lines 28-34 and/or “the cleartext IEs, as defined in TS 24.501 [25] that can be sent by the UE in the Registration Request message…”, page 1, lines 20-28 and/or “UE to (R)AN: AN message (AN parameters, Registration Request (Registration type, SUCI or 5G-GUTI or PEI…[UE Radio Capability Update],…”, Fig. 4.2.2.2.2-1, page 6, lines 1-3; Examiner’s note: based on paragraph [0095] of specification “release information of the UE” relates to when the UE was release, (i.e., UE belongs to 2G, 3G, 4G or 5G)); and
transmitting to a second network (see e.g., “14a. Nudm_UECM_Registration”, Fig. 4.2.2.2.2-1, step 14a and/or “the new AMF registers with the UDM using Nudm_UECM_Registration for the access to be registered”, page 12, lines 47-48) function:
the identity (see e.g., “If the PEI was retrieved by the AMF ( either from the UE or another AMF), AMF shall provide it to the UDM using Nudm_ UECM_Registration in order to ensure that the UDM always has the latest PEI available”, sec. 5.2.3.2.1, page 22, line 1-2); and
the release information of the UE (see e.g., “If the PEI was retrieved by the AMF ( either from the UE or another AMF), AMF shall provide it to the UDM using Nudm_ UECM_Registration in order to ensure that the UDM always has the latest PEI available”, sec. 5.2.3.2.1, page 22, line 1-2 and/or “UE to (R)AN: AN message (AN parameters, Registration Request (Registration type, SUCI or 5G-GUTI or PEI…[UE Radio Capability Update],…”, Fig. 4.2.2.2.2-1, page 6, lines 1-3).
Regarding claim 18, MediaTek discloses, wherein the identity comprises a subscription concealed identifier (SUCI), a fifth generation (5G) global unique temporary identifier (5G-GUTI) (see e.g., “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], [Default Configured NSSAI Indication], [UE Radio Capability Update],…”, Fig. 4.2.2.2.2-1, page 6, lines 1- 10).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived 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 2, 4-5, 8, 17 and 19-20 are rejected under 35 U.S.C. 103(a) as being unpatentable over MediaTek, in view of Applicant provide NPL Ericsson (3GPP TSG-CT WG1 Meeting #126-e, Discussion on UE parameters update transparent container with an unsupported UE parameters update data set type, October 15-23, 2020, hereinafter Ericsson).
Regarding claim 2, MediaTek fails to explicitly disclose, wherein the second network function transmits at least one UE parameter update data set type to the UE based on the identity and the release information of the UE.
In the same field of endeavor, Ericsson discloses, wherein the second network function transmits at least one UE parameter update data set type to the UE based on the identity and the release information of the UE (see e.g., “Including a UE parameters update data set type *not supported* by the UE in a UE parameters update transparent container sent to the UE during the UE parameters update via UDM control plane procedure results into undesirable loss of information…To avoid the issue, the network needs to include *solely* UE parameters update data set types *supported* by the UE in a UE parameters update transparent container sent to the UE…Enable the network to detect the UE parameters update data set types supported by the UE (excluding those specified in Rel-IS)…The network detects the UE parameters update data set types supported by the UE by enhancements the UE parameters update transparent container IE in the NAS.”, page 4, lines 1-12).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine teachings of MediaTek with Ericsson, in order to meet 3GPP standards and prevent loss of information, by including parameter update set supported by the UE (please see Ericsson, page 2, lines 5-6).
Regarding claim 4, MediaTek fails to explicitly disclose, wherein the second network function determines at least one UE parameter update data set type that the UE supports based on the identity.
In the same field of endeavor, Ericsson discloses, wherein the second network function determines at least one UE parameter update data set type that the UE supports based on the identity (see e.g., “the UE indicates the UE parameters update data set types supported by the UE…in a new UE parameters update capabilities IE in the REGISTRATION REQUEST of the initial registration.”, page 2, lines 29-30 and/or “…a UE parameters update transparent container sent to the UE during the UE parameters update via UDM control plane procedure…”, page 4, lines 1-12).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine teachings of MediaTek with Ericsson, in order to meet 3GPP standards and prevent loss of information, by including parameter update set supported by the UE (please see Ericsson, page 2, lines 5-6).
Regarding claim 5, MediaTek fails to explicitly disclose, wherein the release information of the UE comprises at least one UE parameter update data set type that the UE supports.
In the same field of endeavor, Ericsson discloses, wherein the release information of the UE comprises at least one UE parameter update data set type that the UE supports (see e.g., “The network detects the UE parameters update data set types supported by the UE by enhancements the UE parameters update transparent container IE in the NAS”, page 3, lines 11-12 and/or “the UE indicates the UE parameters update data set types supported by the UE…in a new UE parameters update capabilities IE in the REGISTRATION REQUEST of the initial registration.”, page 2, lines 29-30 and/or “…a UE parameters update transparent container sent to the UE during the UE parameters update via UDM control plane procedure…”, page 4, lines 1-12).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine teachings of MediaTek with Ericsson, in order to meet 3GPP standards and prevent loss of information, by including parameter update set supported by the UE (please see Ericsson, page 2, lines 5-6).
Regarding claim 8, MediaTek fails to explicitly disclose, wherein the UE stores at least one UE parameter update data set type.
In the same field of endeavor, Ericsson discloses, wherein the UE stores at least one UE parameter update data set type (see e.g., “the UE will not send any acknowledgement to the network as the acknowledgement is sent as confirmation of successful storage of all the received parameters.”, page 1, lines 35-36 and/or “…the network needs to include *solely* UE parameters update data set types *supported* by the UE in a UE parameters update transparent container sent to the UE…Enable the network to detect the UE parameters update data set types supported by the UE (excluding those specified in Rel-IS)…The network detects the UE parameters update data set types supported by the UE by enhancements the UE parameters update transparent container IE in the NAS.”, page 4, lines 1-12).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine teachings of MediaTek with Ericsson, in order to meet 3GPP standards and prevent loss of information, by including parameter update set supported by the UE (please see Ericsson, page 2, lines 5-6).
Regarding claim 17, MediaTek fails to explicitly disclose, wherein the second network function transmits at least one UE parameter update data set type to the UE based on the identity and the release information of the UE.
In the same field of endeavor, Ericsson discloses, wherein the second network function transmits at least one UE parameter update data set type to the UE based on the identity and the release information of the UE (see e.g., “Including a UE parameters update data set type *not supported* by the UE in a UE parameters update transparent container sent to the UE during the UE parameters update via UDM control plane procedure results into undesirable loss of information…To avoid the issue, the network needs to include *solely* UE parameters update data set types *supported* by the UE in a UE parameters update transparent container sent to the UE…Enable the network to detect the UE parameters update data set types supported by the UE (excluding those specified in Rel-IS)…The network detects the UE parameters update data set types supported by the UE by enhancements the UE parameters update transparent container IE in the NAS.”, page 4, lines 1-12).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine teachings of MediaTek with Ericsson, in order to meet 3GPP standards and prevent loss of information, by including parameter update set supported by the UE (please see Ericsson, page 2, lines 5-6).
Regarding claim 19, MediaTek fails to explicitly disclose, wherein the second network function determines at least one UE parameter update data set type that the UE supports based on the identity.
In the same field of endeavor, Ericsson discloses, wherein the second network function determines at least one UE parameter update data set type that the UE supports based on the identity (see e.g., “the UE indicates the UE parameters update data set types supported by the UE…in a new UE parameters update capabilities IE in the REGISTRATION REQUEST of the initial registration.”, page 2, lines 29-30 and/or “…a UE parameters update transparent container sent to the UE during the UE parameters update via UDM control plane procedure…”, page 4, lines 1-12).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine teachings of MediaTek with Ericsson, in order to meet 3GPP standards and prevent loss of information, by including parameter update set supported by the UE (please see Ericsson, page 2, lines 5-6).
Regarding claim 20, MediaTek fails to explicitly disclose, wherein the release information of the UE comprises at least one UE parameter update data set type that the UE supports.
In the same field of endeavor, Ericsson discloses, wherein the release information of the UE comprises at least one UE parameter update data set type that the UE supports (see e.g., “The network detects the UE parameters update data set types supported by the UE by enhancements the UE parameters update transparent container IE in the NAS”, page 3, lines 11-12 and/or “the UE indicates the UE parameters update data set types supported by the UE…in a new UE parameters update capabilities IE in the REGISTRATION REQUEST of the initial registration.”, page 2, lines 29-30 and/or “…a UE parameters update transparent container sent to the UE during the UE parameters update via UDM control plane procedure…”, page 4, lines 1-12).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine teachings of MediaTek with Ericsson, in order to meet 3GPP standards and prevent loss of information, by including parameter update set supported by the UE (please see Ericsson, page 2, lines 5-6).
Conclusion
The prior art made of record and not relied upon is considered pertinent to Applicant’s disclosure.
Suresh Babu et al. (US 2022/0141902 A1) discloses APPARATUS, SYSTEM, AND METHOD FOR PERFORMING GUTI REALLOCATION.
Bakker (US 2020/0205110 A1) discloses MANAGING LOCAL EMERGENCY NUMBERS.
LEE (US 2019/0230556 A1) discloses APPARATUS AND METHOD FOR NETWORK FUNCTION PROFILE MANAGEMENT.
YOU et al. (US 2023/0300702 A1) discloses METHOD, DEVICE, AND SYSTEM FOR CORE NETWORK DEVICE RE-ALLOCATION IN WIRELESS NETWORK.
KIM et al. (US 2023/0397092 A1) discloses PROCESSING OF NSSAI REJECTED DUE TO NSSAA FAILURE.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FARID SEYEDVOSOGHI whose telephone number is (571)272-9679. The examiner can normally be reached Mon - Fri 8: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, Anthony S. Addy can be reached at 5712727795. 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.
/FARID SEYEDVOSOGHI/ Examiner, Art Unit 2645
Prosecution Insights