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 .
Information Disclosure Statement
The information disclosure statements (IDSs) submitted on Jan. 8, Jan. 31, and Mar. 5, 2025 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the IDSs are being considered by the Examiner.
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)(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 21-23, 26-32, 35-38, and 40 are rejected under 35 U.S.C. § 102(a)(2) as being unpatentable over US 2024/0314883 (hereinafter, “LUNARDI”).
Regarding claim 21, LUNARDI discloses:
A method applied for a first access network device (network node 500, 1860, 1860B, 2030, 2040), wherein the method comprises:
receiving a first message from a second access network device (network node 500, 1860, 1860B, 2030, 2040), wherein the first message indicates that at least two inactive radio network temporary identifier (I-RNTI) rules of the second access network device remain valid; (¶¶ 0336-0338: [I]n block 1301, the processing circuitry 503 receives, from the second network node neighboring the first network node, second information including: [0337] an I-RNTI profile valid for the second network node and associated with a full I-RNTI; and/or [0338] an I-RNTI profile valid for the second network node and associated with a short I-RNTI)
determining, according to at least one valid I-RNTI rule of the second access network device, an access network device corresponding to an I-RNTI of a terminal device; and (¶ 0011: The I-RNTI is defined for allocation in an NR or E-UTRA serving cell as a reference to a UE Context within an NG-RAN node. The I-RNTI is partitioned into two parts, the first part identifies the NG-RAN node that allocated the I-RNTI and the second part identifies the UE context stored in this NG-RAN node; ¶ 0016: The I-RNTI provides the new NG-RAN node a reference to the UE context in the old NG-RAN node; ¶ 0079: [I]t is possible for a RAN node receiving the I-RNTI at RRC Resume to disambiguate the RAN node hosting the UE Context of a UE in RRC Inactive state; ¶ 0095: [T]he identification of the RAN node hosting the UE Context of UEs in RRC Inactive state)
obtaining context information of the terminal device from at least one of the access network device. (¶ 0027: [T]he process of RRC resume and the disambiguation of the RAN node from which a UE context needs to be retrieved from the I-RNTI signalled by the UE at RRC resume; ¶ 0042: [M]ost significant bits of the I-RNTI should be taken into account to derive the Local gNB ID identifying the RAN node from which the UE context needs to be retrieved)
Regarding claim 22, LUNARDI, as applied above, anticipates the method of claim 21. LUNARDI further discloses:
wherein the first message indicates that an updated I-RNTI rule of the second access network device is a first I-RNTI rule, and (¶ 0255: [T]he first RAN node can derive a new “Local RAN node Identifier” and sends the new “Local RAN node Identifier” to the second RAN node via a RAN Configuration Update procedure; Change of “I-RNTI Profile” ¶¶ 0176-0180, e.g., ¶ 0179: [A] RAN node, receiving from a neighbouring RAN node the information that a new “I-RNTI profile” and a new “Local RAN node Identifier” are used by the neighbouring RAN node, can be configured to use, during a transient period, both the “I-RNTI profile” and the “Local RAN node Identifier” assigned by the neighbouring RAN node prior to the change and the “I-RNTI profile” and “Local RAN node Identifier” assigned by neighbouring RAN node after the change)
the first message further indicates that a second I-RNTI rule remains valid, wherein the second I-RNTI rule is an I-RNTI rule before being updated by the second access network device. (Change of “I-RNTI Profile” ¶¶ 0176-0180, e.g., ¶ 0180: During the transient period, the disambiguation of the gNB ID from received I-RNTIs can be done according to both the old and the new values of “I-RNTI profile” and “Local RAN node Identifier” of the neighbouring RAN node)
Regarding claim 23, LUNARDI, as applied above, anticipates the method of claim 22. LUNARDI further discloses:
wherein the first message indicates the first I-RNTI rule and first indication information, and the first indication information indicates that the second I-RNTI rule remains valid;
or
wherein the first message indicates the first I-RNTI rule and the second I-RNTI rule; (¶¶ 0336-0338: [I]n block 1301, the processing circuitry 503 receives, from the second network node neighboring the first network node, second information including: [0337] an I-RNTI profile valid for the second network node and associated with a full I-RNTI; and/or [0338] an I-RNTI profile valid for the second network node and associated with a short I-RNTI)
or
wherein the first message indicates to add the first I-RNTI rule.
Regarding claim 26, LUNARDI, as applied above, anticipates the method of claim 21. LUNARDI further discloses:
wherein the at least one valid I-RNTI rule is used by the first access network device to determine access network device identification information carried in the I-RNTI of the terminal device. (¶ 0011: The I-RNTI is defined for allocation in an NR or E-UTRA serving cell as a reference to a UE Context within an NG-RAN node. The I-RNTI is partitioned into two parts, the first part identifies the NG-RAN node that allocated the I-RNTI and the second part identifies the UE context stored in this NG-RAN node; ¶ 0016: The I-RNTI provides the new NG-RAN node a reference to the UE context in the old NG-RAN node; ¶ 0079: [I]t is possible for a RAN node receiving the I-RNTI at RRC Resume to disambiguate the RAN node hosting the UE Context of a UE in RRC Inactive state; ¶ 0095: [T]he identification of the RAN node hosting the UE Context of UEs in RRC Inactive state)
Regarding claim 27, LUNARDI, as applied above, anticipates the method of claim 26. LUNARDI further discloses:
wherein the at least one valid I-RNTI rule comprises related information of the access network device identification information, and (¶ 0011: The I-RNTI is partitioned into two parts, the first part identifies the NG-RAN node that allocated the I-RNTI)
wherein the related information of the access network device identification information indicates a quantity of bits of the access network device identification information, (¶ 0353: In block 1703, the processing circuitry 503 parses the I-RNTI profile and determines a length in bits of the Local Node Identifier and a length in bits of the UE context identifier corresponding to a received type of I-RNTI)
or
the related information of the access network device identification information is access network device identification information of the second access network device. (¶ 0011: The I-RNTI is partitioned into two parts, the first part identifies the NG-RAN node that allocated the I-RNTI)
Regarding claim 28, LUNARDI, as applied above, anticipates the method of claim 21. LUNARDI further discloses:
wherein the method further comprises:
receiving a radio resource control (RRC) resume request from the terminal device, (¶ 0352: [P]rocessing circuitry 503 receives, from a user equipment, UE, (400, 1810, 1810B, 1810C, 1900, 2030, 2040) a Resume attempt comprising at least one of an RRC Resume Request or an RRC Resume Request 1 comprising an I-RNTI)
wherein the RRC resume request carries the I-RNTI of the terminal device, and the I-RNTI indicates an I-RNTI rule before being updated by the second access network device or an updated I-RNTI rule of the second access network device, and (¶ 0352: [A]n RRC Resume Request 1 comprising an I-RNTI comprising an I-RNTI profile, a Local Node Identifier, and a UE context Identifier; ¶ 0180: During the transient period, the disambiguation of the gNB ID from received I-RNTIs can be done according to both the old and the new values of “I-RNTI profile” and “Local RAN node Identifier” of the neighbouring RAN node)
wherein the determining according to the at least one valid I-RNTI rule of the second access network device, the access network device corresponding to the I-RNTI of the terminal device comprises:
determining according to the I-RNTI rule indicated by the I-RNTI, the access network device corresponding to the I-RNTI of the terminal device. (¶ 0079: [I]t is possible for a RAN node receiving the I-RNTI at RRC Resume to disambiguate the RAN node hosting the UE Context of a UE in RRC Inactive state; ¶ 0095: [T]he identification of the RAN node hosting the UE Context of UEs in RRC Inactive state)
Regarding claim 29, LUNARDI, as applied above, anticipates the method of claim 28. LUNARDI further discloses:
wherein based on that a first one or more bits of the I-RNTI is a first value, the I-RNTI indicates the I-RNTI rule before being updated by the second access network device, (¶ 0097: One length in bits can be used to encode a “full I-RNTI” and a different length in bits can be used to encode a “short I-RNTI”; ¶ 0180: [T]he disambiguation of the gNB ID from received I-RNTIs can be done according to both the old and the new values of “I-RNTI profile” and “Local RAN node Identifier” of the neighbouring RAN node)
or
wherein based on that the first one or more bits of the I-RNTI is a second value, the I-RNTI indicates the updated I-RNTI rule of the second access network device.
Regarding claim 30, LUNARDI discloses:
A method applied for a second access network device (network node 500, 1860, 1860B, 2030, 2040), wherein the method comprises:
updating an inactive radio network temporary identifier (I-RNTI) rule; and (Change of “I-RNTI Profile” ¶¶ 0174-0180; ¶ 0326: [I]n block 1201, the processing circuitry 503 determines a Local node Identifier)
sending a first message to a first access network device (network node 500, 1860, 1860B, 2030, 2040), (¶ 0327: In block 1203, the processing circuitry 503 transmits the one or more Local node Identifiers to a second network node 500, 1860, 1860B, 2030, 2040 neighboring the first network node)
wherein the first message indicates that at least two I-RNTI rules of the second access network device remain valid. (¶¶ 0327-0329: each of the one or more Local node Identifiers information including: [0328] an Inactive-Radio Network Temporary Identifier, I-RNTI, profile valid for the first network node and associated with a full I-RNTI; and/or [0329] an I-RNTI profile valid for the first network node and associated with a short I-RNTI)
Regarding claim 31, LUNARDI, as applied above, anticipates the method of claim 30. LUNARDI further discloses:
wherein the first message indicates that an updated I-RNTI rule of the second access network device is a first I-RNTI rule, and the first message further indicates that a second I-RNTI rule remains valid, (¶ 0255: [T]he first RAN node can derive a new “Local RAN node Identifier” and sends the new “Local RAN node Identifier” to the second RAN node via a RAN Configuration Update procedure; Change of “I-RNTI Profile” ¶¶ 0176-0180, e.g., ¶ 0179: [A] RAN node, receiving from a neighbouring RAN node the information that a new “I-RNTI profile” and a new “Local RAN node Identifier” are used by the neighbouring RAN node, can be configured to use, during a transient period, both the “I-RNTI profile” and the “Local RAN node Identifier” assigned by the neighbouring RAN node prior to the change and the “I-RNTI profile” and “Local RAN node Identifier” assigned by neighbouring RAN node after the change)
wherein the second I-RNTI rule is an I-RNTI rule before being updated by the second access network device. (Change of “I-RNTI Profile” ¶¶ 0176-0180, e.g., ¶ 0180: During the transient period, the disambiguation of the gNB ID from received I-RNTIs can be done according to both the old and the new values of “I-RNTI profile” and “Local RAN node Identifier” of the neighbouring RAN node)
Regarding claim 32, LUNARDI, as applied above, anticipates the method of claim 31. LUNARDI further discloses:
wherein the first message indicates the first I-RNTI rule and first indication information, and the first indication information indicates that the second I-RNTI rule remains valid;
or
wherein the first message indicates the first I-RNTI rule and the second I-RNTI rule; (¶¶ 0336-0338: [I]n block 1301, the processing circuitry 503 receives, from the second network node neighboring the first network node, second information including: [0337] an I-RNTI profile valid for the second network node and associated with a full I-RNTI; and/or [0338] an I-RNTI profile valid for the second network node and associated with a short I-RNTI)
or
wherein the first message indicates to add the first I-RNTI rule.
Regarding claim 35, LUNARDI, as applied above, anticipates the method of claim 30. LUNARDI further discloses:
wherein the at least one valid I-RNTI rule is used by the first access network device to determine access network device identification information carried in an I-RNTI of a terminal device. (¶ 0011: The I-RNTI is defined for allocation in an NR or E-UTRA serving cell as a reference to a UE Context within an NG-RAN node. The I-RNTI is partitioned into two parts, the first part identifies the NG-RAN node that allocated the I-RNTI and the second part identifies the UE context stored in this NG-RAN node; ¶ 0016: The I-RNTI provides the new NG-RAN node a reference to the UE context in the old NG-RAN node; ¶ 0079: [I]t is possible for a RAN node receiving the I-RNTI at RRC Resume to disambiguate the RAN node hosting the UE Context of a UE in RRC Inactive state; ¶ 0095: [T]he identification of the RAN node hosting the UE Context of UEs in RRC Inactive state)
Regarding claim 36, LUNARDI, as applied above, anticipates the method of claim 35. LUNARDI further discloses:
wherein the at least one valid I-RNTI rule comprises related information of the access network device identification information, and (¶ 0011: The I-RNTI is partitioned into two parts, the first part identifies the NG-RAN node that allocated the I-RNTI)
wherein the related information of the access network device identification information indicates a quantity of bits of the access network device identification information, (¶ 0353: In block 1703, the processing circuitry 503 parses the I-RNTI profile and determines a length in bits of the Local Node Identifier and a length in bits of the UE context identifier corresponding to a received type of I-RNTI)
or
the related information of the access network device identification information is access network device identification information of the second access network device. (¶ 0011: The I-RNTI is partitioned into two parts, the first part identifies the NG-RAN node that allocated the I-RNTI)
Regarding claim 37, LUNARDI discloses:
A system, comprising a first access network device (network node 500, 1860, 1860B, 2030, 2040) and a second access network device (network node 500, 1860, 1860B, 2030, 2040), wherein:
the first access network device is configured to:
receive, from the second access network device, a first message indicating that at least two inactive radio network temporary identifier (I-RNTI) rules of the second access network device remain valid; (¶¶ 0336-0338: [I]n block 1301, the processing circuitry 503 receives, from the second network node neighboring the first network node, second information including: [0337] an I-RNTI profile valid for the second network node and associated with a full I-RNTI; and/or [0338] an I-RNTI profile valid for the second network node and associated with a short I-RNTI)
determine according to at least one valid I-RNTI rule of the second access network device, an access network device corresponding to an I-RNTI of a terminal device; and (¶ 0011: The I-RNTI is defined for allocation in an NR or E-UTRA serving cell as a reference to a UE Context within an NG-RAN node. The I-RNTI is partitioned into two parts, the first part identifies the NG-RAN node that allocated the I-RNTI and the second part identifies the UE context stored in this NG-RAN node; ¶ 0016: The I-RNTI provides the new NG-RAN node a reference to the UE context in the old NG-RAN node; ¶ 0079: [I]t is possible for a RAN node receiving the I-RNTI at RRC Resume to disambiguate the RAN node hosting the UE Context of a UE in RRC Inactive state; ¶ 0095: [T]he identification of the RAN node hosting the UE Context of UEs in RRC Inactive state)
obtain context information of the terminal device from at least one of the access network device. (¶ 0027: [T]he process of RRC resume and the disambiguation of the RAN node from which a UE context needs to be retrieved from the I-RNTI signalled by the UE at RRC resume; ¶ 0042: [M]ost significant bits of the I-RNTI should be taken into account to derive the Local gNB ID identifying the RAN node from which the UE context needs to be retrieved)
Regarding claim 38, LUNARDI, as applied above, anticipates the system of claim 37. LUNARDI further discloses:
wherein the first message indicates that an updated I-RNTI rule of the second access network device is a first I-RNTI rule, and (¶ 0255: [T]he first RAN node can derive a new “Local RAN node Identifier” and sends the new “Local RAN node Identifier” to the second RAN node via a RAN Configuration Update procedure; Change of “I-RNTI Profile” ¶¶ 0176-0180, e.g., ¶ 0179: [A] RAN node, receiving from a neighbouring RAN node the information that a new “I-RNTI profile” and a new “Local RAN node Identifier” are used by the neighbouring RAN node, can be configured to use, during a transient period, both the “I-RNTI profile” and the “Local RAN node Identifier” assigned by the neighbouring RAN node prior to the change and the “I-RNTI profile” and “Local RAN node Identifier” assigned by neighbouring RAN node after the change)
the first message further indicates that a second I-RNTI rule remains valid, wherein the second I-RNTI rule is an I-RNTI rule before being updated by the second access network device. (Change of “I-RNTI Profile” ¶¶ 0176-0180, e.g., ¶ 0180: During the transient period, the disambiguation of the gNB ID from received I-RNTIs can be done according to both the old and the new values of “I-RNTI profile” and “Local RAN node Identifier” of the neighbouring RAN node)
Regarding claim 40, LUNARDI, as applied above, anticipates the system of claim 37. LUNARDI further discloses:
wherein the at least one valid I-RNTI rule comprises related information of access network device identification information, and (¶ 0011: The I-RNTI is partitioned into two parts, the first part identifies the NG-RAN node that allocated the I-RNTI)
wherein the related information of the access network device identification information indicates a quantity of bits of the access network device identification information, (¶ 0353: In block 1703, the processing circuitry 503 parses the I-RNTI profile and determines a length in bits of the Local Node Identifier and a length in bits of the UE context identifier corresponding to a received type of I-RNTI)
or
the related information of the access network device identification information is access network device identification information of the second access network device. (¶ 0011: The I-RNTI is partitioned into two parts, the first part identifies the NG-RAN node that allocated the I-RNTI)
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.
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.
Claims 24, 25, 33, 34, and 39 are rejected under 35 U.S.C. § 103 as being unpatentable over LUNARDI in view of US 2017/0127272 (hereinafter, “KELA”).
Regarding claim 24, LUNARDI, as applied above, anticipates the method of claim 22. LUNARDI further discloses:
wherein the method further comprises:
receiving a second message from the second access network device, wherein the second message indicates that the second I-RNTI rule is [removed]. (¶ 0300: It is also possible to use separate messages for addition and removal; ¶ 0323: [I]n block 901, the processing circuitry 503 transmits to the second network node information including: a Node Address Index; an indication if the Node Address Index is added or removed; and an I-RNTI type; ¶ 0325: [I]n block 1101, the processing circuitry 503 receives, from the second network node, an indication of a removal of at least one Local node Identifier (e.g., Node Address Index) used by the second network node)
LUNARDI does not explicitly disclose:
that the second I-RNTI rule is invalid.
In the same field of endeavor, however, KELA teaches:
that the second I-RNTI rule is invalid. (¶ 0097: The RNTI selection rule[] based on RNTI communication failures for selecting the RNTI is to reactively change the RNTI when it has been detected that the first RNTI is not working (not valid). This may occur when the first RNTI is being used outside the first set of network nodes, and the rule may be that the user device shall select the second RNTI instead when such a failure occurs; ¶ 0109: [M]onitor the usage of the RNTIs and the mobility of the user device and initiate an RNTI change when there is a risk that the same RNTI is used by another user device in close proximity, i.e. where there is a risk that the RNTI is no longer valid)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify LUNARDI’s RRC resume procedure to provide initiation of RNTI rule change as taught by KELA responsive to detection of a risk that a current RNTI rule may not be valid so that the user device selects a valid RNTI, such that the network node may signal the RNTIs to the user device in an efficient manner of RNTI handling. See KELA, at ¶ 0017.
Regarding claim 25, LUNARDI, as applied above, anticipates the method of claim 24. LUNARDI further discloses:
wherein the second message carries second indication information, and the second indication information indicates that the second I-RNTI rule is [removed]; (¶ 0323: [I]n block 901, the processing circuitry 503 transmits to the second network node information including: a Node Address Index; an indication if the Node Address Index is added or removed; and an I-RNTI type; ¶ 0325: [I]n block 1101, the processing circuitry 503 receives, from the second network node, an indication of a removal of at least one Local node Identifier (e.g., Node Address Index) used by the second network node)
or
wherein the second message indicates that the first I-RNTI rule remains valid;
or
wherein the second message indicates to release or remove the second I-RNTI rule.
LUNARDI does not explicitly disclose:
that the second I-RNTI rule is invalid.
In the same field of endeavor, however, KELA teaches:
that the second I-RNTI rule is invalid. (¶ 0097: The RNTI selection rule[] based on RNTI communication failures for selecting the RNTI is to reactively change the RNTI when it has been detected that the first RNTI is not working (not valid). This may occur when the first RNTI is being used outside the first set of network nodes, and the rule may be that the user device shall select the second RNTI instead when such a failure occurs; ¶ 0109: [M]onitor the usage of the RNTIs and the mobility of the user device and initiate an RNTI change when there is a risk that the same RNTI is used by another user device in close proximity, i.e. where there is a risk that the RNTI is no longer valid)
Regarding claim 33, LUNARDI, as applied above, anticipates the method of claim 31. LUNARDI further discloses:
wherein the method further comprises:
sending a second message to the first access network device, wherein the second message indicates that the second I-RNTI rule is [removed]. (¶ 0300: It is also possible to use separate messages for addition and removal; ¶ 0323: [I]n block 901, the processing circuitry 503 transmits to the second network node information including: a Node Address Index; an indication if the Node Address Index is added or removed; and an I-RNTI type; ¶ 0325: [I]n block 1101, the processing circuitry 503 receives, from the second network node, an indication of a removal of at least one Local node Identifier (e.g., Node Address Index) used by the second network node)
LUNARDI does not explicitly disclose:
that the second I-RNTI rule is invalid.
In the same field of endeavor, however, KELA teaches:
that the second I-RNTI rule is invalid. (¶ 0097: The RNTI selection rule[] based on RNTI communication failures for selecting the RNTI is to reactively change the RNTI when it has been detected that the first RNTI is not working (not valid). This may occur when the first RNTI is being used outside the first set of network nodes, and the rule may be that the user device shall select the second RNTI instead when such a failure occurs; ¶ 0109: [M]onitor the usage of the RNTIs and the mobility of the user device and initiate an RNTI change when there is a risk that the same RNTI is used by another user device in close proximity, i.e. where there is a risk that the RNTI is no longer valid)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify LUNARDI’s RRC resume procedure to provide initiation of RNTI rule change as taught by KELA responsive to detection of a risk that a current RNTI rule may not be valid so that the user device selects a valid RNTI, such that the network node may signal the RNTIs to the user device in an efficient manner of RNTI handling. See KELA, at ¶ 0017.
Regarding claim 34, LUNARDI, as applied above, anticipates the method of claim 33. LUNARDI further discloses:
wherein the second message carries second indication information, and the second indication information indicates that the second I-RNTI rule is [removed]; (¶ 0323: [I]n block 901, the processing circuitry 503 transmits to the second network node information including: a Node Address Index; an indication if the Node Address Index is added or removed; and an I-RNTI type; ¶ 0325: [I]n block 1101, the processing circuitry 503 receives, from the second network node, an indication of a removal of at least one Local node Identifier (e.g., Node Address Index) used by the second network node)
or
wherein the second message indicates that the first I-RNTI rule remains valid;
or
wherein the second message indicates to release or remove the second I-RNTI rule.
LUNARDI does not explicitly disclose:
that the second I-RNTI rule is invalid.
In the same field of endeavor, however, KELA teaches:
that the second I-RNTI rule is invalid. (¶ 0097: The RNTI selection rule[] based on RNTI communication failures for selecting the RNTI is to reactively change the RNTI when it has been detected that the first RNTI is not working (not valid). This may occur when the first RNTI is being used outside the first set of network nodes, and the rule may be that the user device shall select the second RNTI instead when such a failure occurs; ¶ 0109: [M]onitor the usage of the RNTIs and the mobility of the user device and initiate an RNTI change when there is a risk that the same RNTI is used by another user device in close proximity, i.e. where there is a risk that the RNTI is no longer valid)
Regarding claim 39, LUNARDI, as applied above, anticipates the system of claim 38. LUNARDI further discloses:
wherein the first access network device is further configured to:
receive a second message from the second access network device, wherein the second message indicates that the second I-RNTI rule is [removed]. (¶ 0300: It is also possible to use separate messages for addition and removal; ¶ 0323: [I]n block 901, the processing circuitry 503 transmits to the second network node information including: a Node Address Index; an indication if the Node Address Index is added or removed; and an I-RNTI type; ¶ 0325: [I]n block 1101, the processing circuitry 503 receives, from the second network node, an indication of a removal of at least one Local node Identifier (e.g., Node Address Index) used by the second network node)
LUNARDI does not explicitly disclose:
that the second I-RNTI rule is invalid.
In the same field of endeavor, however, KELA teaches:
that the second I-RNTI rule is invalid. (¶ 0097: The RNTI selection rule[] based on RNTI communication failures for selecting the RNTI is to reactively change the RNTI when it has been detected that the first RNTI is not working (not valid). This may occur when the first RNTI is being used outside the first set of network nodes, and the rule may be that the user device shall select the second RNTI instead when such a failure occurs; ¶ 0109: [M]onitor the usage of the RNTIs and the mobility of the user device and initiate an RNTI change when there is a risk that the same RNTI is used by another user device in close proximity, i.e. where there is a risk that the RNTI is no longer valid)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify LUNARDI’s RRC resume procedure to provide initiation of RNTI rule change as taught by KELA responsive to detection of a risk that a current RNTI rule may not be valid so that the user device selects a valid RNTI, such that the network node may signal the RNTIs to the user device in an efficient manner of RNTI handling. See KELA, at ¶ 0017.
Conclusion
Any inquiry concerning this communication or earlier communications from the Examiner should be directed to Garth D Richmond whose telephone number is (703)756-4559. The Examiner can normally be reached M-F 8 a.m. - 5 p.m. ET.
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, Kathy Wang-Hurst can be reached at 571-270-5371. 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.
/GARTH D RICHMOND/Examiner, Art Unit 2644
/KATHY W WANG-HURST/Supervisory Patent Examiner, Art Unit 2644