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 statement (IDS) submitted 1 July 2026 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the IDS is being considered by the Examiner.
Response to Arguments
Applicant’s arguments—set forth at pp. 6-8 in the Remarks with respect to independent claims 21, 30, and 37—have been fully considered but the Examiner finds that the arguments are not persuasive for at least the reasons set forth below.
Applicant's amendment necessitated the new grounds of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
Applicant particularly argues that the cited portions of LUNARDI relied upon for disclosing the limitations of claim 21 “relate to the receiving node’s autonomous local behavior” and not to a “message-based indication.” Remarks at pp. 7-8. In response, the Examiner finds that it would have been obvious to one of ordinary skill in the art, before Applicant’s application was filed, by drawing a reasonable inference and/or employing routine steps to conclude that the described signaling related to the disclosed node operations—implicitly discloses messages containing information related to instructions for performing those operations. See MPEP § 2143.
The Examiner further finds that the “wherein” clauses being argued (e.g., “the content of the first message,” “what the message itself indicates,” “the content of the message itself,” “a message that indicates,” “message content,” “the amended claims require the first message itself to indicate that both the update I-RNTI rule (first I-RNTI rule) and the pre-update I-RNTI rule (second I-RNTI rule) remain valid”) are nonfunctional descriptive material because the clauses are not relied upon nor used by any step of the method claim. Non-functional descriptive material cannot lend patentability to an invention that would have otherwise been unpatentable. That is, the content of non-functional descriptive material is not entitled to weight in the patentability analysis.
Although the “wherein clauses” further refine the details of the message data, the details of the data do not functionally limit the three steps of the claimed method steps of “receiving,” “determining,” and “obtaining,” and the Applicant’s arguments do not identify any difference between the prior art teachings relative to the claimed invention. That is, the claimed message information is not related to the claimed process by changing the efficiency or accuracy or any other characteristic of the required steps. Claim 21 is directed to a “method applied for a first access network device”—not to a “message-based indication” as argued. See Remarks at p. 8. These reasons similarly apply to independent claims 30 and 37.
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 21, 23, 26-30, 32, 35-37, and 40 are rejected under 35 U.S.C. § 103 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 [signalling] 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; ¶ 0294: Signalling for these embodiments of inventive concepts will support both full I-RNTI and short I-RNTI. Considering the current standard, both the 24-bit and the 40-bit I-RNTIs would need to be exchanged. Considering the existing messages suitable candidates would be the Xn Setup and Xn NG-RAN Node Configuration Update procedures. However, new messages can also be used. The new messages could be designed to include the complete list of I-RNTIs in use by the node)
wherein the first [signalling] 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)
wherein the first [signalling] further indicates that a second I-RNTI rule remains valid, and (¶¶ 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)
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)
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)
Although LUNARDI describes “Signalling of ‘I-RNTI Profile’ and ‘Local Node RAN Identifier,’” LUNARDI does not explicitly disclose specific messages. See ¶¶ 0174-0175. The Examiner finds that it would have been obvious to one of ordinary skill in the art, before Applicant’s application was filed, by drawing a reasonable inference and/or employing routine steps to conclude that the described signaling related to the disclosed node operations—implicitly discloses messages containing information related to instructions for performing those operations. See MPEP § 2143.
Regarding claim 23, LUNARDI, as applied above, anticipates the method of claim 21. 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 the 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 [signalling] to a first access network device (network node 500, 1860, 1860B, 2030, 2040), (¶ 0294: Signalling for these embodiments of inventive concepts will support both full I-RNTI and short I-RNTI. Considering the current standard, both the 24-bit and the 40-bit I-RNTIs would need to be exchanged. Considering the existing messages suitable candidates would be the Xn Setup and Xn NG-RAN Node Configuration Update procedures. However, new messages can also be used. The new messages could be designed to include the complete list of I-RNTIs in use by the node; ¶ 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 [signalling] 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)
wherein the first [signalling] 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)
wherein the first [signalling] further indicates that a second I-RNTI rule remains valid, and (¶¶ 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)
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)
Although LUNARDI describes “Signalling of ‘I-RNTI Profile’ and ‘Local Node RAN Identifier,’” LUNARDI does not explicitly disclose specific messages. See ¶¶ 0174-0175. The Examiner finds that it would have been obvious to one of ordinary skill in the art, before Applicant’s application was filed, by drawing a reasonable inference and/or employing routine steps to conclude that the described signaling related to the disclosed node operations—implicitly discloses messages containing information related to instructions for performing those operations. See MPEP § 2143.
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 30. 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 at least one valid I-RNTI rule of the at least two I-RNTI rules 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 [signalling] 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; ¶ 0294: Signalling for these embodiments of inventive concepts will support both full I-RNTI and short I-RNTI. Considering the current standard, both the 24-bit and the 40-bit I-RNTIs would need to be exchanged. Considering the existing messages suitable candidates would be the Xn Setup and Xn NG-RAN Node Configuration Update procedures. However, new messages can also be used. The new messages could be designed to include the complete list of I-RNTIs in use by the node)
wherein the first [signalling] 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)
wherein the first [signalling] further indicates that a second I-RNTI rule remains valid, and (¶¶ 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)
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)
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)
Although LUNARDI describes “Signalling of ‘I-RNTI Profile’ and ‘Local Node RAN Identifier,’” LUNARDI does not explicitly disclose specific messages. See ¶¶ 0174-0175. The Examiner finds that it would have been obvious to one of ordinary skill in the art, before Applicant’s application was filed, by drawing a reasonable inference and/or employing routine steps to conclude that the described signaling related to the disclosed node operations—implicitly discloses messages containing information related to instructions for performing those operations. See MPEP § 2143.
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)
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 21. 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 30. 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 37. 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
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
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
