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 .
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, 3-4, 7, 14, and 18 are rejected under 35 U.S.C. 102 (a) (2) as being anticipated by Palanigounder et al. (hereinafter Palanigouder) US 2024/0171978 A1.
Regarding claim 1, Palanigouder teaches a method comprising:
generating, for transmission to an access and mobility management function (AMF) of a network, a first message that includes an indication as to whether a user equipment (UE) supports UE parameter update (UPU) header protection (¶0031; this limitation is mandatory step to support a Release-15 feature for 5G. For example, according to the 3rd Generation Partnership Project (3GPP), UPU is mandatory to support a Release-15 feature for a fifth-generation (5G)/New Radio (5G/NR) UE. For instance, a home network (e.g., a Unified Data Management (UDM) entity, also referred to as a “UDM”) can transmit UPU data (and in some cases other data, such as an acknowledgement indication) for the UE. The UPU data can be transmitted to the UE via one or more other network entities (e.g., an Access and Mobility Management Function (AMF)). ¶0099 & Fig. 6; the Nausf_UPUProtection request message includes an ACK Indication. For example, if the UDM 608 determines that the UE 602 is to acknowledge the successful security check of the received UPU Data, then the UDM 608 can set a corresponding indication in the UPU Data (e.g., according to 3GPP TS 24.501) and include the ACK Indication in the Nausf_UPUProtection service operation message to signal that it also needs an expected UPU-XMAC-I.sub.UE. The inclusion of UPU Data in the calculation of UPU-MAC-I.sub.AUSF provides integrity of the data, thus allowing the UE 602 to verify that it has not been tampered with by any intermediary. The expected UPU-XMAC-I.sub.UE allows the UDM 608 to verify that the UE 602 received the UPU Data correctly); and
receiving a second message from the network, the second message including a UPU transparent container (¶0032; home network can transmit [second message] the UPU data in a UPU container, which can be a transparent container (meaning the container is transparent to network entities between the UDM and the UE, such as the AMF). For example, as defined in 3GPP Technical Specification (TS) 24.501, the UPU container transmitted from the UDM to the UE can be a UPU transparent container data type with value “0”. The UPU container can include various information elements (IEs), including an IE with a UE parameters update transparent container IE Identifier (IEI), an IE with a length of UE parameters update transparent container contents, an IE with a UE parameters update header, an IE with UPU-MAC-I.sub.AUSF, an IE with UPU counter information (e.g., denoted as Counter.sub.UPU), and an IE with a UE parameters update list); and
processing the second message, wherein:
the processing includes using header information included in the UPU data set based at least in part on the UE supporting UPU header protection and a UPU data set included in the UPU transparent container including a UPU header protect indication indicating that a UPU header is protected (¶0032-¶0036; as defined in 3GPP Technical Specification (TS) 24.501, the UPU container transmitted from the UDM to the UE can be a UPU transparent container data type with value “0”. The UPU container can include various information elements (IEs), including an IE with a UE parameters update transparent container IE Identifier (IEI), an IE with a length of UE parameters update transparent container contents, an IE with a UE parameters update header, an IE with UPU-MAC-I.sub.AUSF, an IE with UPU counter information (e.g., denoted as Counter.sub.UPU), and an IE with a UE parameters update list.),
or the processing includes using header information from a UPU header in the UPU transparent container based at least in part on the UE not supporting UPU header protection or the UPU transparent container not including a UPU header protect indication indicating that the UPU header is protected.
Regarding Claim 3, Palanigouder teaches the method of claim 1, further comprising comprises:
generating a REGISTRATION REQUEST message for the AMF, wherein the REGISTRATION REQUEST message includes the first message (¶0097 & Fig. 6; the security functions associated with the security procedure 600 are described in the context of the functions supporting the delivery of UE Parameters Update Data (UPU data) from the UDM 608 to the UE 602 after the UE has successfully registered to a wireless communications network (e.g., a 5G network)).
Regarding Claim 4, Palanigouder teaches the method of claim 1, wherein generating the first message comprises: configuring an information element (IE) to include a bit indicating that the UE supports the UPU header protection (¶0106; TABLE-US-00002 TABLE 2 UE parameters update transparent container information element (IE) for UE parameters update data type with value “1” UE parameters update transparent container IEI octet 1 Length of UE parameters update transparent octet 2 container contents octet 3 UE parameters update header octet 4 UPU-MAC-I.sub.UE octet 5-20).
Regarding Claim 7, Palanigouder teaches an apparatus comprising: interface circuitry; and processor circuitry, coupled with the interface circuitry, the processor circuitry configured to:
decode a first message received from a network using the interface circuitry (¶0006; one processor is configured to: receive a user equipment (UE) parameters update (UPU) container, the UPU container comprising a UE parameters update header information element (IE) and a UE parameters update list IE, wherein the UE parameters update header IE comprises UE parameters update header information, and wherein the UE parameters update list IE comprises the UE parameters update header information of the UE parameters update header IE);
identify, from the decoded first message, a request for an indication as to whether a user equipment (UE) supports protection of a UE parameter update (UPU) header (¶0006; one processor is configured to: receive a user equipment (UE) parameters update (UPU) container, the UPU container comprising a UE parameters update header information element (IE) and a UE parameters update list IE, wherein the UE parameters update header IE comprises UE parameters update header information, and wherein the UE parameters update list IE comprises the UE parameters update header information of the UE parameters update header IE); and
generate, for transmission to the network using the interface circuitry, a second message that includes the indication as to whether the UE supports protection of the UPU header based at least in part on the first message (¶0006; and generate, based on the UE parameters update list IE, a UPU message authentication code (MAC) for verifying integrity of the UPU container).
Claims 14, and 18 are substantially similar to the above claims, thus the same rationale applies.
Claims 1, 3-4, 6-11, 13-18 and 20 are rejected under 35 U.S.C. 102 (a) (2) as being anticipated by Baskaran et al. (Baskaran) US 2024/0388894 A1.
Regarding claim 1, Baskaran teaches a method comprising:
generating, for transmission to an access and mobility management function (AMF) of a network, a first message that includes an indication as to whether a user equipment (UE) supports UE parameter update (UPU) header protection (see Fig. 5 & ¶0070; UE 502 transmits a message 522 to AMF 504 that includes UE capability indication. Also see 0075, ¶0086-¶0095 & Fig. 6; the UE 602 sends a registration request message that may include a UPU capability container); and
receiving a second message from the network, the second message including a UPU transparent container (¶0089; If the UPU capability check at the UE is successful, then the UE determines to store and use the UPU data provisioned (e.g., in the UPU data container) by the UDM (via the AMF); and
processing the second message, wherein:
the processing includes using header information included in the UPU data set based at least in part on the UE supporting UPU header protection and a UPU data set included in the UPU transparent container including a UPU header protect indication indicating that a UPU header is protected (¶0090-¶0092; on a successful UPU-MAC-I.sub.AUSF verification and successful UPU capability check, the UE generates the UPU-MAC-I.sub.UE using inputs related to UPU acknowledgements (e.g., that it verified the parameters update data and UPU capability) and UE parameters update header, respectively. Further the UE also provides ‘the UPU capability check success indication’ to the UDM via the AMF in the acknowledgement response message. The UE may also generate a negative acknowledgement if the UPU capability check fails, and may include its UPU data set type capabilities so that the UDM can retry only with the supported UPU data set types; and [0092] 5) the UDM, on receiving the ‘UPU capability check success indication’, checks if the received UPU-MAC-I.sub.UE matches the stored UPU-XMAC-I.sub.UE, or else the UDM sends the received ‘UPU capability check success indication’ along with other received data to the AUSF to perform UPU-MAC-I.sub.UE verification),
or the processing includes using header information from a UPU header in the UPU transparent container based at least in part on the UE not supporting UPU header protection or the UPU transparent container not including a UPU header protect indication indicating that the UPU header is protected (¶0091-0092).
Regarding claim 3, Baskaran teaches the method of claim 1, further comprising comprises:
generating a REGISTRATION REQUEST message for the AMF, wherein the REGISTRATION REQUEST message includes the first message (¶0075 & Fig. 6; the UE 602 sends a registration request message that may include a UPU capability container).
Regarding claim 4, Baskaran teaches the method of claim 1, wherein generating the first message comprises: configuring an information element (IE) to include a bit indicating that the UE supports the UPU header protection (¶0126 & ¶0128; FIG. 11 shows how the network can provide the expected and/or required UE parameters update data set type(s) information element to the UE during a UPU procedure, where each data set type can reserve a bit to indicate if it is required to be supported (e.g., bit 1) or not (e.g., bit 0). The ‘expected/required UE parameters update data set type(s) information element’ can be provided by the network to the UE as part of the UE parameters update transparent container information element for UE parameters update data type with value ‘0’).
Regarding claim 6, Baskaran teaches the method of claim 1, wherein the indication as to whether the UE supports the UPU header protection is an explicit indication as to whether the UE supports the UPU header protection (¶0126 & ¶0128; FIG. 11 shows how the network can provide the expected and/or required UE parameters update data set type(s) information element to the UE during a UPU procedure, where each data set type can reserve a bit to indicate if it is required to be supported (e.g., bit 1) or not (e.g., bit 0). The ‘expected/required UE parameters update data set type(s) information element’ can be provided by the network to the UE as part of the UE parameters update transparent container information element for UE parameters update data type with value ‘0’).
Regarding Claim 7, Baskaran teaches an apparatus comprising: interface circuitry; and processor circuitry, coupled with the interface circuitry, the processor circuitry configured to:
decode a first message received from a network using the interface circuitry (¶0067-¶0074 & Figs. 5-6; UDM 508 decides 510 to perform a UE parameter update for additional UPU parameters);
identify, from the decoded first message, a request for an indication as to whether a user equipment (UE) supports protection of a UE parameter update (UPU) header (¶0068-¶0074 & Fig.5; In a first communication 512, the UDM 508 transmits an Nausf_UPUProtection_Protect request message which may include: a SUPI, UPU data (e.g., an ACK indication, a UE capability request indication, and so forth), and/or an ACK indication. In a second communication 514, the AUSF 506 transmits an Nausf_UPUProtection_Protect response message which may include: UPU-MAC-I.sub.AUSF, UPU-XMAC-I.sub.UE, and/or Counter.sub.UPU); and
generate, for transmission to the network using the interface circuitry, a second message that includes the indication as to whether the UE supports protection of the UPU header based at least in part on the first message (¶0070; In a fifth communication 522, the UE 502 transmits an UL NAS transport message that may include an ACK response (e.g., including a UE capability indication) and UPU-MAC-I.sub.UE. Moreover, in a sixth communication 524, the AMF 504 may transmit an Nudm_SDM_Info message that may include an ACK response and the UPU-MAC-I.sub.UE. The UDM 508 may, if there is no UE capabilities indication, compare 526 the received UPU-MAC-I.sub.UE with a stored UPU-XMAC-I.sub.UE; otherwise, the UDM 508 may omit the stored UPU-XMAC-I.sub.UE and request a UPU-XMAC-I.sub.UE from the AUSF 506 corresponding to the UE capabilities indication provided by the UE 502.).
Regarding claim 8, Baskaran teaches the apparatus of claim 7, the first message includes an indication as to whether the network supports protection of the UPU header (¶0126 & ¶0128; FIG. 11 shows how the network can provide the expected and/or required UE parameters update data set type(s) information element to the UE during a UPU procedure, where each data set type can reserve a bit to indicate if it is required to be supported (e.g., bit 1) or not (e.g., bit 0). The ‘expected/required UE parameters update data set type(s) information element’ can be provided by the network to the UE as part of the UE parameters update transparent container information element for UE parameters update data type with value ‘0’).
Regarding claim 9, Baskaran teaches the apparatus of claim 8, wherein the processing circuitry is further to: determine whether to include the indication as to whether the UE supports protection of the UPU header based at least in part on the indication as to whether the network supports protection of the UPU header (¶0126 & ¶0128; FIG. 11 shows how the network can provide the expected and/or required UE parameters update data set type(s) information element to the UE during a UPU procedure, where each data set type can reserve a bit to indicate if it is required to be supported (e.g., bit 1) or not (e.g., bit 0). The ‘expected/required UE parameters update data set type(s) information element’ can be provided by the network to the UE as part of the UE parameters update transparent container information element for UE parameters update data type with value ‘0’).
Regarding claim 10, Baskaran teaches the apparatus of claim 7, wherein the first message includes first UE configuration parameters in a UPU transparent container, wherein the request for the indication includes a request for an acknowledgment (¶0126 & ¶0128; FIG. 11 shows how the network can provide the expected and/or required UE parameters update data set type(s) information element to the UE during a UPU procedure, where each data set type can reserve a bit to indicate if it is required to be supported (e.g., bit 1) or not (e.g., bit 0). The ‘expected/required UE parameters update data set type(s) information element’ can be provided by the network to the UE as part of the UE parameters update transparent container information element for UE parameters update data type with value ‘0’), and wherein the processing circuitry is further to: configure an information element (IE) to include the indication as to whether the UE supports protection of the UPU header, wherein the second message includes the IE (¶0126 & ¶0128; FIG. 11 shows how the network can provide the expected and/or required UE parameters update data set type(s) information element to the UE during a UPU procedure, where each data set type can reserve a bit to indicate if it is required to be supported (e.g., bit 1) or not (e.g., bit 0). The ‘expected/required UE parameters update data set type(s) information element’ can be provided by the network to the UE as part of the UE parameters update transparent container information element for UE parameters update data type with value ‘0’).
Regarding claim 11, Baskaran teaches the apparatus of claim 10, wherein the first message comprises an unprotected UPU header (¶0070; if there is no UE capabilities indication, compare 526 the received UPU-MAC-I.sub.UE with a stored UPU-XMAC-I.sub.UE; otherwise, the UDM 508 may omit the stored UPU-XMAC-I.sub.UE and request a UPU-XMAC-I.sub.UE from the AUSF 506 corresponding to the UE capabilities indication provided by the UE 502), and wherein the processing circuitry is further to: process second UE configuration parameters in a second UPU transparent container, wherein the second UPU transparent container includes a protected UPU header based at least in a part on the indication included in the IE (¶0126 & ¶0128; FIG. 11 shows how the network can provide the expected and/or required UE parameters update data set type(s) information element to the UE during a UPU procedure, where each data set type can reserve a bit to indicate if it is required to be supported (e.g., bit 1) or not (e.g., bit 0). The ‘expected/required UE parameters update data set type(s) information element’ can be provided by the network to the UE as part of the UE parameters update transparent container information element for UE parameters update data type with value ‘0’).
Regarding claim 13, Baskaran teaches the apparatus of claim 7, wherein the indication as to whether the UE supports protection of the UPU header is an explicit indication as to whether the UE supports protection of the UPU header (¶0126 & ¶0128; FIG. 11 shows how the network can provide the expected and/or required UE parameters update data set type(s) information element to the UE during a UPU procedure, where each data set type can reserve a bit to indicate if it is required to be supported (e.g., bit 1) or not (e.g., bit 0). The ‘expected/required UE parameters update data set type(s) information element’ can be provided by the network to the UE as part of the UE parameters update transparent container information element for UE parameters update data type with value ‘0’).
Regarding claim 14, Baskaran teaches the One or more non-transitory computer-readable media including stored thereon a sequence of instructions that, when executed by one or more processors, causes the one or more processors to: process a first message including user equipment (UE) configuration parameters in a UE parameter update (UPU) transparent container from a network, the first message including a protected UPU header; decode the UPU header and a payload of the first message (¶0031; The UPU data can be transmitted to the UE via one or more other network entities (e.g., an Access and Mobility Management Function (AMF)). ¶0099 & Fig. 6; the Nausf_UPUProtection request message includes an ACK Indication. For example, if the UDM 608 determines that the UE 602 is to acknowledge the successful security check of the received UPU Data, then the UDM 608 can set a corresponding indication in the UPU Data (e.g., according to 3GPP TS 24.501) and include the ACK Indication in the Nausf_UPUProtection service operation message to signal that it also needs an expected UPU-XMAC-I.sub.UE. The inclusion of UPU Data in the calculation of UPU-MAC-I.sub.AUSF provides integrity of the data, thus allowing the UE 602 to verify that it has not been tampered with by any intermediary. The expected UPU-XMAC-I.sub.UE allows the UDM 608 to verify that the UE 602 received the UPU Data correctly); validate the first message from the network (¶0044, ¶0069-¶0081 & ¶0166); and update UE configuration parameters based at least in part on the UE configuration parameters included in the first message (same as previously cited paragraphs. Also see ¶0090-¶0092; UPU data is payload. Here, on a successful UPU-MAC-I.sub.AUSF verification and successful UPU capability check, the UE generates the UPU-MAC-I.sub.UE using inputs related to UPU acknowledgements (e.g., that it verified the parameters update data and UPU capability) and UE parameters update header, respectively. Further the UE also provides ‘the UPU capability check success indication’ to the UDM via the AMF in the acknowledgement response message. The UE may also generate a negative acknowledgement if the UPU capability check fails, and may include its UPU data set type capabilities so that the UDM can retry only with the supported UPU data set types; and [0092] 5) the UDM, on receiving the ‘UPU capability check success indication’, checks if the received UPU-MAC-I.sub.UE matches the stored UPU-XMAC-I.sub.UE, or else the UDM sends the received ‘UPU capability check success indication’ along with other received data to the AUSF to perform UPU-MAC-I.sub.UE verification).
Regarding claim 15, Baskaran teaches the one or more non-transitory computer-readable media of claim 14, wherein, to validate, the first message from the network the sequence of instructions, when executed by the one or more processors, further causes the one or more processors to:
calculate a first enhanced UPU- Message Authentication Code (MAC)-I authentication server function (AUSF) security token value based at least in a part on the decoded UPU header (¶0044, ¶0069-¶0081; see successful verification. For example, in a seventh communication 528, the UDM 508 transmits an Nausf_UPUProtection_ProtectACK that may include a SUPI, and an ACK response (e.g., including the UE capabilities indication). The AUSF 506 generates 530 a new UPU-XMAC-I.sub.UE. In an eighth communication 532, the AUSF 506 transmits an Nausf_UPUProtection_ProtectACK response message that includes the new UPU-XMAC-I.sub.UE. The UDM 508 compares 534 the received UPU-MAC-I.sub.UE from the UE 502 with the new UPU-XMAC-I.sub.UE received from the AUSF 506. The UDM 508 stores the supported UE parameters update data set types if the verification is successful. In a ninth communication 536, another round of steps 510 through 526 is performed for the new parameter updated according to the received UE capabilities indication);
and compare the first enhanced UPU-MAC-IAUSF security token value to a second enhanced UPU-MAC-IAUSF security token received in the first message, wherein the first message is validated based at least in part on the comparison (see above the comparison. Also see ¶0166; a receiver to receive a first message from a first network function, wherein the first message comprises: UPU priority information, UPU capability check required information, required UPU data type support information, or a combination thereof; and a transmitter to transmit a second message to the first network function, wherein the second message comprises an UPU-MAC-IAUSF and a UPU-XMAC-IUE).
Regarding claim 16, Baskaran teaches the one or more non-transitory computer-readable media of claim 14, wherein the first message is a non-access stratum (NAS) transport message (¶0079; In a second communication 714, the UE 702 transmits an UL NAS transport message that may include Ho PU data, the HoPU-MAC-I.sub.UE, and the Counter.sub.HoPU. In a third communication 716, the AMF 704 transmits a Nudm_ParameterProvision message that includes a SUPI, HoPU data, the HoPU-MAC-I.sub.UE, and the Counter.sub.HoPU).
Regarding claim 17, Baskaran teaches the one or more non-transitory computer-readable media of claim 14, wherein the first message includes an indication that the UPU header is protected, and wherein the sequence of instructions that, when executed by one or more processors, further causes the one or more processors to: determine whether the UPU is protected based at least in part on the indication, wherein the UE decodes the UPU header and a payload of the first message based at least in part on the determination (see claim 1, also (¶0090-¶0092; UPU data is payload. Here, on a successful UPU-MAC-I.sub.AUSF verification and successful UPU capability check, the UE generates the UPU-MAC-I.sub.UE using inputs related to UPU acknowledgements (e.g., that it verified the parameters update data and UPU capability) and UE parameters update header, respectively. Further the UE also provides ‘the UPU capability check success indication’ to the UDM via the AMF in the acknowledgement response message. The UE may also generate a negative acknowledgement if the UPU capability check fails, and may include its UPU data set type capabilities so that the UDM can retry only with the supported UPU data set types; and [0092] 5) the UDM, on receiving the ‘UPU capability check success indication’, checks if the received UPU-MAC-I.sub.UE matches the stored UPU-XMAC-I.sub.UE, or else the UDM sends the received ‘UPU capability check success indication’ along with other received data to the AUSF to perform UPU-MAC-I.sub.UE verification)).
Regarding claim 18, Baskaran teaches the one or more non-transitory computer-readable media of claim 17, wherein the indication is a bit included in a UE parameters update transparent container or in an information element distinct from the UE parameters update transparent container (¶0126 & ¶0128; FIG. 11 shows how the network can provide the expected and/or required UE parameters update data set type(s) information element to the UE during a UPU procedure, where each data set type can reserve a bit to indicate if it is required to be supported (e.g., bit 1) or not (e.g., bit 0). The ‘expected/required UE parameters update data set type(s) information element’ can be provided by the network to the UE as part of the UE parameters update transparent container information element for UE parameters update data type with value ‘0’).
Regarding claim 20, Baskaran teaches the one or more non-transitory computer-readable media of claim 14, wherein the indication as to whether the UE supports protection of the UPU header is an explicit indication as to whether the UE supports protection of the UPU header (¶0126 & ¶0128; FIG. 11 shows how the network can provide the expected and/or required UE parameters update data set type(s) information element to the UE during a UPU procedure, where each data set type can reserve a bit to indicate if it is required to be supported (e.g., bit 1) or not (e.g., bit 0). The ‘expected/required UE parameters update data set type(s) information element’ can be provided by the network to the UE as part of the UE parameters update transparent container information element for UE parameters update data type with value ‘0’).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
The factual inquiries 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, 5, 12 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Baskaran in view of Protection of UPU Header, 3GPP TSG-SA3 Meeting #111; Goteburg, Sweden, S3-233870 (IDS entry 3 under NPL filed 5/5/2025) by Adrian Escott et al. (hereinafter Adrian).
Regarding claim 2, Baskaran teaches the method of claim 1, but does not expressly teach wherein the first message is a UE STATE INDICATION message.
Adrian teaches wherein the first message is a UE STATE INDICATION message (D.5.4-P. 980-981; UE sends first UE state indication message).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to incorporate Adrian into the system of Baskaran in order to deliver UPSIs of the UE policy sections stored in the UE and to indicate whether the UE supports ANDSP (D.5.4.1 on p. 980-981).
Regarding claim 5, Baskaran teaches the method of claim 4, but does not expressly teach wherein the IE is a UE policy classmark IE or a mobility management (MM) capability IE.
Adrian teaches wherein the IE is a UE policy classmark IE or a mobility management (MM) capability IE (D.6.5 on P. 990-991 or D.6.7. on Page 992; UE policy classmark information).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to incorporate Adrian into the system of Baskaran in order to provide the network with information about the policy aspects of the UE (D.6.5 on p. 990).
Claims 12 and 19 are substantially similar to the above claims, thus the same rationale applies.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MAHRAN ABU ROUMI whose telephone number is (469)295-9170. The examiner can normally be reached Monday-Thursday 6AM-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, Emmanuel Moise can be reached at 571-272-3865. 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.
MAHRAN ABU ROUMI
Primary Examiner
Art Unit 2455
/MAHRAN Y ABU ROUMI/ Primary Examiner, Art Unit 2455
Prosecution Insights