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 .
Response to Amendment
This action is in response to the application filed on March 18, 2026
Claims 1, 3-5, 7-9, 11-13 and 15-16 is under examination.
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 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-5, 7-9, 11-13 and 15-16 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Teyeb et al, (USPUB: 2023/0232294)”
As per Claim 1 Teyeb teaches a method performed by a first integrated access and backhaul (IAB) node in a communication system, the method comprising:
receiving, from a second IAB node, a message including an indication indicating withholding transmission and a radio resource control (RRC) message for a third IAB node (Paragraph 0051, 0151, 0152 the IAB-donor-CU sends a UE CONTEXT SETUP REQUEST message to the target parent node gNB-DU to create the UE context for the migrating IAB-MT. RRC MESSAGE TRANSFER message to the IAB-donor-CU to convey the received, a communication method applied to an IAB system. The child node receives a first RRC reconfiguration message from an access network device via a parent node.); withholding the RRC message for the third IAB node until the first IAB node receives information related to a migration (Paragraph 0071, 0053-0155 received RRCReconfiguration message to the migrating IAB-MT. In operation 7, the source parent node gNB-DU responds to the IAB-donor-CU with the UE CONTEXT MODIFICATION RESPONSE message.); and in case that the first
IAB node receives the information related to the migration (Paragraph 0071, 0152, 0154, 0155 UL packets can be sent from the migrating IAB-MT, and are forwarded to the IAB-donor-CU through the target parent node gNB-DU. These DL and UL packets belong to the MT's own signalling and data traffic),
transmitting, to the third IAB node, the RRC message for the third IAB node (Paragraph 0202-0203, 0206 IAB2 forwards this information within an F1 message or an embedded RRC message to IAB3. IAB3 are type 2 parent nodes with respect to IAB3 a migrating IAB node knows that it is receiving a handover (HO) command (i.e., RRC Reconfiguration message containing reconfiguration With Sync for the MCG) but it doesn't necessarily know whether the HO command is for an inter-CU handove ), in case that a condition is met (Paragraph 0314, 0332 where the IAB node can determine/condition that the HO command is for an inter-CU migration of the child IAB node to the second CU. where the IAB node can, based on determining /condition that the hand over (HO) command is for an inter-CU migration, perform modified handling of UL data buffered at the one or more descendant nodes, according to the instructions and until execution of the HO command), wherein the first IAB node belongs to a descendant node of a migrating IAB node, wherein the second IAB node is a IAB donor node (Paragraph 0256, 0263, 0270, 0297 a migrating IAB node can be a type 2 parent node, whose descendant nodes are also migrating. Migrating IAB nodes can perform various operations upon determining that: 1) the handover (HO) of the migrating IAB node is an inter-CU handover, and/or 2) there is some explicit indication of modified handling of UL/DL data packets during the migration, the migrating IAB node is an inter-CU handover, and/or there is some explicit indication of modified handling of UL/DL data packets during the migration.), and wherein the third IAB node is a descendant node of the first IAB node (Paragraph 0271, 0292 a migrating IAB node can be a type 2 parent node, whose descendant nodes are also migrating. Within the HO command, that the one or more descendant nodes are also subject to the inter-CU migration).
2. (Cancelled)
As per Claim 3 Teyeb teaches the method of claim 2, wherein the information related to the migration includes at least one of new internet protocol (IP) address, routing identification (ID), or backhaul radio link control (RLC) channel ID (Paragraph 0010, 0135, 0216 This means that each BH RLC channel ID maps to one LCID. As such, when the following discussion refers to a list of BH (RLC) channels, it could mean either a list of RLC channel IDs or a list of LCIDs. Backhaul Adaptation Protocol (BAP) layer has been introduced in the IAB nodes and the IAB donor.. The BAP layer also maps UE radio bearer data to the proper backhaul RLC channel (also referred to herein as “backhaul RLC bearers”), as well as between ingress and egress backhaul RLC channels in intermediate IAB nodes.. In other variants, the RLC protocol can be split between CU and DU, with Automatic Retransmission Request (ARQ) functionality in CU. ).
As per Claim 4 Teyeb teaches the method of claim 1, wherein the message includes a UE CONTEXT MODIFICATION REQUEST message (Paragraph 0153 the IAB-donor-CU sends a UE CONTEXT MODIFICATION REQUEST message to the source parent node gNB-DU).
As per Claim 5 Teyeb teaches a first integrated access and backhaul (IAB) node in a communication system, the first IAB node comprising:
a transceiver configured to transmit and receive a signal; and at least one processor coupled with the transceiver and configured to ():
receive, from a second IAB node, a message including an indication indicating withhold transmission indication information and a radio resource control (RRC) message for a third IAB node(Paragraph 0051, 0151, 0152 the IAB-donor-CU sends a UE CONTEXT SETUP REQUEST message to the target parent node gNB-DU to create the UE context for the migrating IAB-MT. RRC MESSAGE TRANSFER message to the IAB-donor-CU to convey the received, a communication method applied to an IAB system. The child node receives a first RRC reconfiguration message from an access network device via a parent node.); and withholding the RRC message for the third IAB node until the first IAB node receives information related to a migration (Paragraph 0071, 0053-0155 received RRCReconfiguration message to the migrating IAB-MT. In operation 7, the source parent node gNB-DU responds to the IAB-donor-CU with the UE CONTEXT MODIFICATION RESPONSE message.); and in case that the first IAB node receives the information related to the migration(Paragraph 0071, 0152, 0154, 0155 UL packets can be sent from the migrating IAB-MT, and are forwarded to the IAB-donor-CU through the target parent node gNB-DU. These DL and UL packets belong to the MT's own signalling and data traffic),
transmit, to the third IAB node, the RRC message for the third IAB node (Paragraph 0202-0203, 0206 IAB2 forwards this information within an F1 message or an embedded RRC message to IAB3. IAB3 are type 2 parent nodes with respect to IAB3 a migrating IAB node knows that it is receiving a handover (HO) command (i.e., RRC Reconfiguration message containing reconfiguration With Sync for the MCG) but it doesn't necessarily know whether the HO command is for an inter-CU handove ), in case that a condition is met (Paragraph 0314, 0332 where the IAB node can determine/condition that the HO command is for an inter-CU migration of the child IAB node to the second CU. where the IAB node can, based on determining /condition that the hand over (HO) command is for an inter-CU migration, perform modified handling of UL data buffered at the one or more descendant nodes, according to the instructions and until execution of the HO command ), wherein the first IAB node belongs to a descendant node of a migrating IAB node, wherein the second IAB node is a IAB donor node(Paragraph 0256, 0263, 0270, 0297 a migrating IAB node can be a type 2 parent node, whose descendant nodes are also migrating. Migrating IAB nodes can perform various operations upon determining that: 1) the handover (HO) of the migrating IAB node is an inter-CU handover, and/or 2) there is some explicit indication of modified handling of UL/DL data packets during the migration, the migrating IAB node is an inter-CU handover, and/or there is some explicit indication of modified handling of UL/DL data packets during the migration.), and wherein the third IAB node is a descendant node of the first IAB node (Paragraph 0271, 0292 a migrating IAB node can be a type 2 parent node, whose descendant nodes are also migrating. Within the HO command, that the one or more descendant nodes are also subject to the inter-CU migration).
6. (Cancelled)
As per Claim 7 Teyeb teaches the first IAB node of claim 6, wherein the information related to the migration includes at least one of new internet protocol (IP) address, routing identification (ID), or backhaul radio link control (RLC) channel ID (Paragraph 0010, 0135, 0216 This means that each BH RLC channel ID maps to one LCID. As such, when the following discussion refers to a list of BH (RLC) channels, it could mean either a list of RLC channel IDs or a list of LCIDs. Backhaul Adaptation Protocol (BAP) layer has been introduced in the IAB nodes and the IAB donor.. The BAP layer also maps UE radio bearer data to the proper backhaul RLC channel (also referred to herein as “backhaul RLC bearers”), as well as between ingress and egress backhaul RLC channels in intermediate IAB nodes.. In other variants, the RLC protocol can be split between CU and DU, with Automatic Retransmission Request (ARQ) functionality in CU. ).
As per Claim 8 Teyeb teaches the first IAB node of claim 5, wherein the message includes a UE CONTEXT MODIFICATION REQUEST message (Paragraph 0153 the IAB-donor-CU sends a UE CONTEXT MODIFICATION REQUEST message to the source parent node gNB-DU).
As per Claim 9 Teyeb teaches a method performed by a second integrated access and backhaul (IAB) node in a communication system, the method comprising:
generating a message including an indication indicating withholding transmission of (Paragraph 0153, 0160, 0208 This message includes the handover (HO) command and indicates to stop the data transmission for the UE or IAB-MT (i.e., Transmission Action Indicator IE is set to the value of “stop”). The Transmission Action Indicator in the UE CONTEXT MODIFICATION REQUEST message indicates to stop the data transmission to the migrating IAB-node) and a radio resource control (RRC) message for a third IAB node (Paragraph 0051, 0151, 0152 the IAB-donor-CU sends a UE CONTEXT SETUP REQUEST message to the target parent node gNB-DU to create the UE context for the migrating IAB-MT. RRC MESSAGE TRANSFER message to the IAB-donor-CU to convey the received, a communication method applied to an IAB system. The child node receives a first RRC reconfiguration message from an access network device via a parent node.); and withholding the RRC message for the third IAB node until the first IAB node receives information related to a migration (Paragraph 0071, 0053-0155 received RRCReconfiguration message to the migrating IAB-MT. In operation 7, the source parent node gNB-DU responds to the IAB-donor-CU with the UE CONTEXT MODIFICATION RESPONSE message.); and in case that the first IAB node receives the information related to the migration (Paragraph 0071, 0152, 0154, 0155 UL packets can be sent from the migrating IAB-MT, and are forwarded to the IAB-donor-CU through the target parent node gNB-DU. These DL and UL packets belong to the MT's own signalling and data traffic),
transmitting, to a first IAB node, the message, the first IAB node belonging to a descendant node of a migrating IAB node, wherein the RRC message for the third IAB node is transmitted from the first IAB node to the third IAB node (Paragraph 0202-0203, 0206 IAB2 forwards this information within an F1 message or an embedded RRC message to IAB3. IAB3 are type 2 parent nodes with respect to IAB3 a migrating IAB node knows that it is receiving a handover (HO) command (i.e., RRC Reconfiguration message containing reconfiguration With Sync for the MCG) but it doesn't necessarily know whether the HO command is for an inter-CU handover ), in case that a condition is met (Paragraph 0314, 0332 where the IAB node can determine/condition that the HO command is for an inter-CU migration of the child IAB node to the second CU. where the IAB node can, based on determining /condition that the hand over (HO) command is for an inter-CU migration, perform modified handling of UL data buffered at the one or more descendant nodes, according to the instructions and until execution of the HO command ), wherein the second IAB node is an IAB donor node(Paragraph 0256, 0263, 0270, 0297 a migrating IAB node can be a type 2 parent node, whose descendant nodes are also migrating. Migrating IAB nodes can perform various operations upon determining that: 1) the handover (HO) of the migrating IAB node is an inter-CU handover, and/or 2) there is some explicit indication of modified handling of UL/DL data packets during the migration, the migrating IAB node is an inter-CU handover, and/or there is some explicit indication of modified handling of UL/DL data packets during the migration.), and wherein the third IAB node is a descendant node of the first IAB node (Paragraph 0271, 0292 a migrating IAB node can be a type 2 parent node, whose descendant nodes are also migrating. Within the HO command, that the one or more descendant nodes are also subject to the inter-CU migration).
10. (Cancelled)
As per Claim 11 Teyeb teaches the method of claim 10, wherein the information related to the migration includes at least one of new internet protocol (IP) address, routing identification (ID), or backhaul radio link control (RLC) channel ID (Paragraph 0010, 0135, 0216 This means that each BH RLC channel ID maps to one LCID. As such, when the following discussion refers to a list of BH (RLC) channels, it could mean either a list of RLC channel IDs or a list of LCIDs. Backhaul Adaptation Protocol (BAP) layer has been introduced in the IAB nodes and the IAB donor.. The BAP layer also maps UE radio bearer data to the proper backhaul RLC channel (also referred to herein as “backhaul RLC bearers”), as well as between ingress and egress backhaul RLC channels in intermediate IAB nodes.. In other variants, the RLC protocol can be split between CU and DU, with Automatic Retransmission Request (ARQ) functionality in CU. ).
As per Claim 12 Teyeb teaches the method of claim 9, wherein the message includes a UE CONTEXT MODIFICATION REQUEST message (Paragraph 0153 the IAB-donor-CU sends a UE CONTEXT MODIFICATION REQUEST message to the source parent node gNB-DU).
As per Claim 13 Teyeb teaches a second integrated access and backhaul (IAB) node in a communication system, the second IAB node comprising:
a transceiver configured to transmit and receive a signal (Paragraph 0371 radio frequency (RF) transceiver circuitry 1972 ); and at least one processor coupled with the transceiver and configured to (Paragraph 0371processing circuitry 1970 can include one or more of radio frequency (RF) transceiver circuitry 1972):
generate a message including an indication indicating withholding of transmission and a radio resource control (RRC) message for a third IAB node (Paragraph 0051, 0151, 0152 the IAB-donor-CU sends a UE CONTEXT SETUP REQUEST message to the target parent node gNB-DU to create the UE context for the migrating IAB-MT. RRC MESSAGE TRANSFER message to the IAB-donor-CU to convey the received, a communication method applied to an IAB system. The child node receives a first RRC reconfiguration message from an access network device via a parent node.); and withholding the RRC message for the third IAB node until the first IAB node receives information related to a migration (Paragraph 0071, 0053-0155 received RRCReconfiguration message to the migrating IAB-MT. In operation 7, the source parent node gNB-DU responds to the IAB-donor-CU with the UE CONTEXT MODIFICATION RESPONSE message.); and in case that the first IAB node receives the information related to the migration (Paragraph 0071, 0152, 0154, 0155 UL packets can be sent from the migrating IAB-MT, and are forwarded to the IAB-donor-CU through the target parent node gNB-DU. These DL and UL packets belong to the MT's own signalling and data traffic),
transmit, to a first IAB node, the message, the first IAB node belonging to a descendant node of a migrating IAB node, wherein the RRC message for the third IAB node is transmitted from the first IAB node to the third IAB node (Paragraph 0202-0203, 0206 IAB2 forwards this information within an F1 message or an embedded RRC message to IAB3. IAB3 are type 2 parent nodes with respect to IAB3 a migrating IAB node knows that it is receiving a handover (HO) command (i.e., RRC Reconfiguration message containing reconfiguration With Sync for the MCG) but it doesn't necessarily know whether the HO command is for an inter-CU handover), in case that a condition is met, wherein the second IAB node is a IAB donor node(Paragraph 0256, 0263, 0270, 0297 a migrating IAB node can be a type 2 parent node, whose descendant nodes are also migrating. Migrating IAB nodes can perform various operations upon determining that: 1) the handover (HO) of the migrating IAB node is an inter-CU handover, and/or 2) there is some explicit indication of modified handling of UL/DL data packets during the migration, the migrating IAB node is an inter-CU handover, and/or there is some explicit indication of modified handling of UL/DL data packets during the migration.), and wherein the third IAB node is a descendant node of the first IAB node(Paragraph 0271, 0292 a migrating IAB node can be a type 2 parent node, whose descendant nodes are also migrating. Within the HO command, that the one or more descendant nodes are also subject to the inter-CU migration).
14. (Cancelled)
As per Claim 15 Teyeb teaches the second IAB node of claim 14, wherein the information related to the migration includes at least one of new internet protocol (IP) address, routing identification (ID), or backhaul radio link control (RLC) channel ID (Paragraph 0010, 0135, 0216 This means that each BH RLC channel ID maps to one LCID. As such, when the following discussion refers to a list of BH (RLC) channels, it could mean either a list of RLC channel IDs or a list of LCIDs. Backhaul Adaptation Protocol (BAP) layer has been introduced in the IAB nodes and the IAB donor.. The BAP layer also maps UE radio bearer data to the proper backhaul RLC channel (also referred to herein as “backhaul RLC bearers”), as well as between ingress and egress backhaul RLC channels in intermediate IAB nodes.. In other variants, the RLC protocol can be split between CU and DU, with Automatic Retransmission Request (ARQ) functionality in CU. ).
As per Claim 16 Teyeb teaches the second IAB node of claim 13, wherein the message includes a UE CONTEXT MODIFICATION REQUEST message (Paragraph 0153 the IAB-donor-CU sends a UE CONTEXT MODIFICATION REQUEST message to the source parent node gNB-DU).
Response to Argument(s)
Applicant's argument(s) filed on March 18, 2026 have been fully considered but they are not persuasive. Therefore, the rejection is maintained.
In the remarks, at page 10-15 the Applicant argues in substance that:
(A) "Teyeb does not disclose an RRC message for the third IAB node, which also constitutes a difference between the claimed features and Teyeb.”.
Response
(A) In response, Examiner respectfully disagrees with applicant’s representative’s assertions. The Examiner has thoroughly reviewed Applicants' arguments but firmly believes that the cited references teaches claim limitation. Teyeb explicitly states that a migrating IAB3 node knows that it is receiving a handover command such as RRCReconfiguration message containing reconfigurationWithSync for the MCG but it doesn't necessarily know whether the handover command is for an inter-CU handover. The migrating IAB3 node can check to see if the target cell indicated in the handover command is the same as the current serving cell or if it is a current PCell or SCell. If any of those criteria are met. However, if none of these criteria are met, the migrating IAB3 node will still not be able to distinguish between the cases of: 1) the target cell belongs to the same DU that's currently providing serving cell(s) for the migrating IAB3 node; 2) the target cell belongs to another DU within the same CU as the current serving DU; and 3) the target cell belongs to a DU of another CU... An example from Teyeb (Paragraph 0200 nodes IAB2, IAB3, and IAB 4 are “migrating IAB nodes.” In other words, even if IAB3 and IAB4 do not relocate their radio links with their respective parent IAB nodes, the default assumption is that IAB3 and IAB4 will also change the CU together with the migration of IAB2. There can be exceptions to this, as discussed in more detail below..).
PNG
media_image1.png
395
491
media_image1.png
Greyscale
Therefore, Teyeb reference teaches the claim limitation as currently presented.
Examiner’s Note
Examiner is open for discussion if the applicant’s representative need further clarifications.
Conclusion
THIS ACTION IS MADE FINAL
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 extension fee 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 SYED ALI whose telephone number is (571)270-3681. The examiner can normally be reached on M-F.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Asad Nawaz can be reached on 571-272-3988. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov . Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SYED ALI/Primary Examiner, Art Unit 2468
Prosecution Insights