CTNF 18/247,948 CTNF 82638 DETAILED ACTION Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. Continued Examination Under 37 CFR 1.114 07-42-04 AIA A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 05/13/2026 has been entered. Claim Rejections - 35 USC § 102 07-06 AIA 15-10-15 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. 07-07-aia AIA 07-07 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 – 07-08-aia AIA (a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention. 07-15-aia AIA Claim(s) 5 – 6, 11 – 16 and 18 – 20 is/are rejected under 35 U.S.C. 102 (a)(1) as being anticipated by 3rd Generation Partnership Project (3GPP), R3-196992, "Routing in IAB network", TSG-RAN WG3 meeting #106, Huawei, 2019-11-08, (listed in applicant submitted IDS and listed as D1 in PCT search report), hereinafter Huawei . Regarding claim 5 , Huawei teaches a method performed by a donor central unit (CU) in an integrated access backhaul (IAB) network, wherein the IAB network comprises the donor CU, a plurality of donor distributed units (DUs), and a plurality of IAB nodes, and wherein the method comprises: (Huawei: pages 1-2 – 2.1 Issue 1: Which BAP routing ID to be added in BAP header for UL – IAB network includes CU, DUs and a plurality of IAB nodes) assigning a same Backhaul Adaptation Protocol (BAP) address to each of the plurality of donor DUs; (Huawei: section 2.1 - Issue 1: Which BAP routing ID to be added in BAP header for UL – page 1 last bullet to page 2 1 st paragraph - BAP address configuration for upstream - A) assigning BAP address. Multiple IAB donor DUs will share same BAP address if these DUs connects to a same IAB donor CU-UP, i.e. same BAP address to each of the plurality of donor DUs. section 2.5 Issue 5 – Fig. 3 shows a BH link redundancy for IAB networks, as IAB-donor-DU1 and IAB-donor-DU2 connects to a same IAB-donor-CU-UP1, IAB-donor-DU1 and IAB-donor-DU2 share the same BAP address) and PNG media_image1.png 200 400 media_image1.png Greyscale assigning for each path originating from an IAB node and terminating at one of the plurality of donor DUs, a different BAP path identity, ID (Huawei: page 2 1 st bullet – Configuration of upstream BAP path ID for access IAB node - IAB donor CU may optionally configure one or multiple BAP path IDs towards each BAP address. and assigns preferred path ID with highest priority to the IAB-donor-DU and IAB nodes, i.e. assigning for each path originating from an IAB node (corresponds to claim limitation “originating from an IAB donor”) and terminating at one (corresponds to claim limitation “terminating at one IAB donor”) of the plurality of donor DUs, a different BAP ID (corresponds to claim limitation “a different path identity”) . Pages 2-4 sec. 2.2 and Fig. 1 shows three different paths from IAB 5 to IAB donor node, where each of the three different paths assigned with different PAP path ID. Fig. 2 and Fig. 3 and Sec. 2.4) Huawei, e.g. below for Figure 1 PNG media_image2.png 200 400 media_image2.png Greyscale Figure 1. An example of BH link RLF wherein different paths terminating at different donor DUs and associated with the same BAP address are assigned different BAP path IDs. (Huawei: section 2.1 - Issue 1: Which BAP routing ID to be added in BAP header for UL – page 1 last bullet to page 2 1st paragraph teaches BAP address configuration for upstream - A) assigning BAP address. Multiple IAB donor DUs will share same BAP address if these DUs connects to a same IAB donor CU-UP, i.e. same BAP address to each of the plurality of donor DUs. Fig. 3 shows IAB-donor-DU1 and IAB-donor-DU2 share the same BAP address (corresponds to claim limitation “different donor DUs associated with the same BAP address”) . page 2 1st bullet – Configuration of upstream BAP path ID for access IAB node - IAB donor CU may optionally configure one or multiple BAP path IDs towards each BAP address. Finally, Fig. 1 and Fig. 2 show multiple different paths from IAB node to IAB donor node, where each of the three different paths assigned with their respective different BAP path IDs within the same BAP address. Pages 2-4 sec. 2.2 and Fig. 1. In addition, page 4 - Option 2a. The intermediate IAB node changes the BAP path ID to identify the actual path, which is selected when perform re-routing – teaches each path is assigned with a unique BAP (corresponds to claim limitation “different paths terminating at different donor DUs are assigned different BAP path IDs”) and toward same destination BAP address, which includes IAB donor DU1 and IAB-donor-DU2. This option will avoid the confliction) Regarding claim 6, Huawei teaches the method according to claim 5, wherein each different BAP path ID is a unique BAP path ID. (Huawei: B) configures one or multiple BAP path IDs towards each BAP address and assigns preferred path ID with highest priority to the IAB-donor-DU and IAB nodes, i.e. assigning for each path originating from an IAB node and terminating at one of the plurality of donor DUs, a different BAP ID. See sec. 2-2.1. TFig. 1 and Fig. 2 show multiple different paths from IAB node to IAB donor node, where each of the three different paths assigned with their respective different BAP path IDs within the same BAP address. Pages 2-4 sec. 2.2 and Fig. 1. In addition, page 4 - Option 2a. The intermediate IAB node changes the BAP path ID to identify the actual path, which is selected when perform re-routing – teaches each path is assigned with a unique BAP and toward same destination BAP address, which includes IAB donor DU1 and IAB-donor-DU2. This option will avoid the confliction) Regarding claim 11, Huawei teaches a method performed by an Integrated Access Backhaul (IAB) node in an IAB network, wherein the IAB network comprises a donor central unit (CU), a plurality of donor distributed units (DUs), and a plurality of IAB nodes including the IAB node, and wherein the method comprises: (Huawei: pages 1-2 – 2.1 Issue 1: Which BAP routing ID to be added in BAP header for UL – IAB network includes CU, DUs and a plurality of IAB nodes) receiving a first packet, wherein the first packet has a Backhaul Adaptation Protocol (BAP) routing ID in its header, wherein the BAP routing ID comprises a BAP path ID and a BAP address, (Huawei: pages 1-2 sec. 1-2.1 retrieves a packet, i.e. the first packet, for selection/addition of a BAP routing ID from an IP header. Each BAP routing ID includes a BAP address, and also include a path ID) and wherein the IAB node has its Backhaul (BH) routing configuration (Huawei: page 3 2 nd paragraph - When the intermediate IAB node needs to choose another next hop link different from the one indicated by the entry of the BAP path ID and BAP address, the IAB node may look up the routing table and find another entry with same BAP address. Page 6 Observation 4 and Fig. 4 routing table of IAB node 3 is being updated) determining, based on the BH routing configuration of the IAB node, (Huawei: page 3 2 nd paragraph - When the intermediate IAB node needs to choose another next hop link different from the one indicated by the entry of the BAP path ID and BAP address, the IAB node may look up the routing table (corresponds to claim limitation “BH routing configuration”) and find another entry with same BAP address. Page 5 2.5 - Issue 5: RLF handling of routing for the IAB node connecting to multiple donor DUs – 1 st paragraph - Each BAP address can have one or multiple entries in the routing table to enable local route selection. Multiple entries is for load balancing, re-routing at RLF) whether at least one of the following conditions apply to the received first packet: the BAP path ID of the first packet is not present in the BH routing configuration of the IAB node; (Huawei: 2.4 proposal 6 - If the path indicated by the path ID in the BAP header is not available (e.g. BH RLF), BAP resets the path ID in BAP header as one of the actual path to be re-routed, or resets the path ID to the default value, e.g. all zero values) the destination indicated by the BAP address of the received packet is not present in the BH routing configuration of the IAB node; a link towards a next hop for the BAP routing ID of the first packet is unavailable, or the link is congested, or radio measurements for the link are below a predetermined threshold; (Huawei: pages 2-3 sec. 2.2 - Issue 2: How to handle the RLF case - has a link that is failed, as for instance in fig. 1. Some BH links along a path suffer from radio link failure, RLF, i.e. a link towards a next hop for the BAP routing ID of the first packet is unavailable. An example where the IAB node is aware that the path suffers from congestion is also mentioned, i.e. the link is congested. When an intermediate IAB node needs to choose another next hop link different from the one indicated by the entry of the BAP path ID and BAP address, the IAB node look up a routing table and find another entry with same BAP address by implementation or take a priority level into consideration if the priority level of each path is configured, i.e. the IAB node has its BH routing configuration determining whether at least one of the following conditions apply. pages 3 sec. 2.2 - Issue 2: How to handle the RLF case – 3 rd paragraph - it is also possible for the access IAB node or the IAB donor to select other paths if it knows that some link along the path with the highest priority level is suffering from RLF. For example, the access IAB node or the IAB donor DU may detect that the first hop of the path is failure (corresponds to claimed limitation “determining that at least one of the conditions apply”) , or receive RLF notification from intermediate IAB nodes. See sec. 2.1-2.3 & 2.5, fig. 1. These features correspond to bullets b) and iii)-iv)) and rerouting the first packet upon determining that at least one of the conditions apply, (Huawei: pages 2-3 sec. 2.2 - Issue 2: How to handle the RLF case - C) forwards packets through other candidate paths, i.e. rerouting the first packet, to ensure lossless transmission, upon RLF, i.e. upon determining that at least one of the conditions - it is also possible for the access IAB node or the IAB donor to select other paths if it knows that some link along the path with the highest priority level is suffering from RLF. For example, the access IAB node or the IAB donor DU may detect that the first hop of the path is failure (corresponds to claimed limitation “determining that at least one of the conditions apply”) , or receive RLF notification from intermediate IAB nodes) wherein the rerouting comprises selecting another path from the BH routing configuration for forwarding the first packet . (Huawei: Page 5 2.5 - Issue 5: RLF handling of routing for the IAB node connecting to multiple donor DUs – 1 st paragraph - Each BAP address can have one or multiple entries in the routing table (corresponds to claim limitation “BH routing configuration”) to enable local route selection. Multiple entries is for load balancing, re-routing at RLF) Regarding claim 12, Huawei teaches the method according to claim 11, further comprising: selecting a new BAP path ID among one or more BAP path IDs present in the BH routing configuration of the IAB node, wherein the selected new BAP path ID is associated to the destination indicated by the BAP address of the first packet; and assigning the selected new BAP path ID to the first packet, wherein rerouting the first packet is performed based on the new BAP path ID. (D1: sec. 2.1-2.2, 2.4 - describing that the IAB node selects any next hop to transmit the packet. If multiple BAP path IDs are configured towards same BAP address in the routing configuration information, and no preference is configured by the IAB-donor-CU, then the access IAB node determines a preferred one by itself. Furthermore, it is also possible for the access IAB node or the IAB donor to select other paths if it knows that some link along the path with the highest priority level is suffering from RLF) Regarding claim 13, Huawei teaches the method according to claim 12, wherein selecting a new BAP path ID comprises selecting a BAP path ID that corresponds to an egress link between the IAB node at which the first packet is received and an IAB node at a next hop. (D1: sec. 2.1-2.2, 2.4 - describing that the IAB node selects any next hop to transmit the packet. If multiple BAP path IDs are configured towards same BAP address in the routing configuration information, and no preference is configured by the IAB-donor-CU, then the access IAB node determines a preferred one by itself. Furthermore, it is also possible for the access IAB node or the IAB donor to select other paths if it knows that some link along the path with the highest priority level is suffering from RLF) Regarding claim 14, Huawei teaches the method according to claim 11, further comprising selecting a new BAP path ID among one or more BAP path IDs present in the BH routing configuration of the IAB node, wherein the selection is based on evaluation of at least one of: radio conditions of egress links associated with the one or more paths present in the BH routing configuration, (Huawei: 2.2 it is also possible for the access IAB node or the IAB donor to select other paths if it knows that some link along the path with the highest priority level is suffering from RLF. For example, the access IAB node or the IAB donor DU may detect that the first hop of the path is failure, or receive RLF notification from intermediate IAB nodes. In such case, the selection of BAP path ID from other inferior candidate paths to same BAP address can also be based on implementation or according to the configured priority level of each path) load conditions of egress links associated with the one or more paths present in the BH routing configuration; and (Huawei: 2.3 – for intermediate IAB nodes, if the path indicated by the BAP path ID is congested or will overload, an intermediate IAB node can choose an alternative path towards a same BAP address also, either according to the configured priority level of each path or local decision by implementation. 2.4 - Based on the analysis in issue 2 and issue 3, it is obvious that re-routing may occurs in intermediate IAB node for some special reasons, e.g. BH link suffers RLF, load balancing) assigning the selected new BAP path ID to the first packet, wherein rerouting the first packet is performed based on the new BAP path ID. (D1: sec. 2.1-2.2, 2.4 - describing that the IAB node selects any next hop to transmit the packet. If multiple BAP path IDs are configured towards same BAP address in the routing configuration information, and no preference is configured by the IAB-donor-CU, then the access IAB node determines a preferred one by itself. Furthermore, it is also possible for the access IAB node or the IAB donor to select other paths if it knows that some link along the path with the highest priority level is suffering from RLF) Regarding claim 15, Huawei teaches the method according to claim 12, further comprising retaining the BAP address of the first packet after assigning the new selected BAP path ID. (Huawei: 2.2 it is also possible for the access IAB node or the IAB donor to select other paths if it knows that some link along the path with the highest priority level is suffering from RLF. For example, the access IAB node or the IAB donor DU may detect that the first hop of the path is failure, or receive RLF notification from intermediate IAB nodes. In such case, the selection of BAP path ID from other inferior candidate paths to same BAP address can also be based on implementation or according to the configured priority level of each path) Regarding claim 16, Huawei teaches the method according to claim 11, further comprising, prior to rerouting the first packet, setting one of the reserve bits in the BAP header of the first packet at a specific value to indicate that the first packet is rerouted. (Huawei: 2.4 proposal 6 - BAP resets the path ID in BAP header as one of the actual path to be re-routed) Regarding claim 18, Huawei teaches the method according to claim 11, further comprising assigning a special BAP routing ID to the received first packet upon determining at least one of the conditions apply to the received first packet, wherein the first packet is to be forwarded by a donor DU to an upper layer. (Huawei: sec. 2 and 2.2) describing that the access IAB node will add the BAP routing ID for UL packets and IAB-donor-DU will add BAP routing IDs for DL packets, and thus, it is possible that the access IAB node/lAB-donor-DU adds a preferred BAP path ID to a packet, but some BH links along this path may suffer from RLF. To ensure lossless transmission, upon RLF, the intermediate IAB node can forward the packets through other candidate paths. The access IAB node should decide which BAP routing ID will be added to a given BAP SOU according to configurations received from the IAB-donor-CU) Regarding claim 19, Huawei teaches the method according to claim 18, wherein the special BAP routing ID is pre-configured by the donor CU. (Huawei: sec. 2 and 2.2 - the access IAB node will add the BAP routing ID for UL packets and IAB-donor- DU will add BAP routing IDs for DL packets, and thus, it is possible that the access IAB node/lAB-donor-DU adds a preferred BAP path ID to a packet, but some BH links along this path may suffer from RLF. To ensure lossless transmission, upon RLF, the intermediate IAB node can forward the packets through other candidate paths. The access IAB node should decide which BAP routing ID will be added to a given BAP SOU according to configurations received from the IAB-donor-CU) Regarding claim 20, Huawei teaches the method according to claim 11, further comprising replacing the BAP address of the first packet with a new BAP routing ID upon determining that the destination indicated by the BAP routing ID of the received first packet is not present in the BH routing configuration of the IAB node, wherein the new BAP routing ID indicates a destination that is included in the BH routing configuration of the IAB node. (Huawei: 2.4 proposal 6 - If the path indicated by the path ID in the BAP header is not available (e.g. BH RLF), BAP resets the path ID in BAP header as one of the actual path to be re-routed, or resets the path ID to the default value, e.g. all zero values) Claim Rejections - 35 USC § 103 07-20-aia AIA 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. 07-23-aia AIA 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. 07-21-aia AIA Claim (s) 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Huawei in view of Chen et al. WO2021062627A1 (with priorities CN2019109449W filed 2019-09-30), hereinafter Chen . Regarding claim 7 , Huawei teaches the method according to claim 5, Huawei does not explicitly teach: further comprising: sharing, for each of the plurality of IAB nodes under the domain of a donor DU, a respective assigned IP address of the respective IAB node to one or more other donor DUs. However, Chen from the same or similar fields of endeavor teaches the use of: sharing, for each of the plurality of IAB nodes under the domain of a donor DU (Chen: page 4 last paragraph - evolving new generation wireless communication network such as 5G network develops a split network architecture in which the Radio Access Network (RAN) functionality is split between a central unit (CU) and multiple distributed units (DUs)) , a respective assigned IP address of the respective IAB node to one or more other donor DUs (Chen: Fig. 7 and pages 15-16 4 th – 5 th paragraphs – In order to support the multi-hop routing of CP/UP/OAM traffic, it is necessary to configure the routing information for each IAB node and donor DU. Generally, the routing information contains a list of routing entry. Each routing entry include the BAP routing ID, egress link. The BAP routing ID may comprise BAP address and BAP path ID. Each BAP address defines a unique destination (unique for the IAB network, either an IAB access node or the IAB donor DU). Each BAP address can have one or multiple entries in the routing table to enable local route selection. Multiple entries can be used for re-routing at radio link failure (RLF). donor CU 204 configures the routing selection information for the donor DU 205 and access IAB node 206d, and then sends the configured routing selection information to donor DU 205 and access IAB node 206d. The donor DU 205 and access IAB node 206d receive the routing selection information (step 710), and then may use the routing selecting information to select the routing path for packet transmission (step 720). The routing selection information may include a list of routing selection entry and each entry may include the destination IP address and the BAP routing ID). Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to use the teaching of Chen in the method of Huawei. One of ordinary skill in the art would be motivated to do so for IAB technologies will allow for easier deployment of a dense network of self-backhauled NR cells in a more integrated and robust manner. For example, the IAB technology in the 5G NR network will support a multi-hop relay system, where the network topology also supports redundant connections. (Chen: page 5 1 st paragraph) . 07-21-aia AIA Claim (s) 8 and 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Huawei in view of Huang et al. US 20230362745 A1 (Huang: para. [0001] patent document is a continuation of and claims benefit of priority to International Patent Application No. PCT/CN2020/105701, filed on Jul. 30, 2020), hereinafter Huang . Regarding claim 8, Huawei teaches the method according to claim 5, further comprising performing at least one of: configuring at least one of the plurality of IAB nodes to evaluate a level of congestion of an egress link of the respective IAB node; and (Huawei: sec. 2.3 describing that if the path indicated by the BAP path ID is congested or will overload, an intermediate IAB node choose an alternative path towards a same BAP address also, either according to the configured priority level of each path or local decision by implementation) It is noted that Huawei does not explicitly disclose: configuring, for at least one of the plurality of IAB nodes, a threshold of radio measurements below which the IAB node is allowed to perform rerouting. However, Huang from the same or similar fields of endeavor teaches the use of: configuring, for at least one of the plurality of IAB nodes, a threshold of radio measurements below which the IAB node is allowed to perform rerouting (Huang: para. [0051] a donor CU sends measurement threshold to IAB node via RRC. For example, the measurement threshold could be a RSRP threshold based on SS/PBCH block or based on CSI-RS. The IAB node performs measurement of the serving cell and, when the measured RSRP is lower than the measurement threshold, the IAB node sends mobility configuration information to child IAB node/UE. Optionally, when IAB node receives mobility configuration information from parent node, it can send mobility configuration information to its child node. The mobility configuration information includes at least one of the following: (a) indication information relating to whether a parent node is performing or will perform inter-CU migration, or (b) indication information relating to whether an ancestor node is performing or will perform inter-CU migration, or (c) indication information relating to starting measuring, or (d) measurement configuration). Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to use the teaching of Huang in the method of Huawei. One of ordinary skill in the art would be motivated to do so for provides connectivity with other wireless communication systems and wired communication systems (Huang: para. [0112]) . Regarding claim 10, Huawei teaches the method according to claim 5, further comprising: configuring, at one or more links, one or more dedicated Backhaul (BH) Radio Link Control (RLC) channels (Huawei: sec. 1 and 2.6) describing separate BH RLC channel) However, Huang from the same or similar fields of endeavor teaches the use of: wherein each of the one or more links is between an IAB node and a donor DU or between two IAB nodes, and wherein each of the one or more dedicated BH RLC channels is only used for forwarding rerouted traffic (Huang: para. [0080] (d) BH RLC channel configuration for IAB-MT configured by source donor CU, or (e) BH RLC channel configuration for collocated IAB-DU configured by source donor CU, including one of following). Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to use the teaching of Huang in the method of Huawei. One of ordinary skill in the art would be motivated to do so for provides connectivity with other wireless communication systems and wired communication systems (Huang: para. [0112]) . 07-22-aia AIA Claim (s) 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Huawei and Huang as applied to claim 8 above, and further in view of Akl et al. US 20210127296 A1 (Akl: para. [0001] claims the benefit of U.S. Provisional Patent Application No. 62/926,381 filed Oct. 25, 2019, hereinafter Akl’381), hereinafter Akl . Regarding claim 9 , Huawei and Huang teach the method according to claim 8, Huawei and Huang do not explicitly teach: wherein configuring an IAB node to evaluate a level of congestion of an egress link of the IAB node comprises performing at least one of: configuring the IAB node to receive flow control feedback from at least one of a parent node and a child node of the IAB node, wherein the flow control feedback includes a buffer size at the respective at least one of a parent node and a child node, and configuring the IAB node to determining whether the buffer size at the at least one of a parent node and a child node is over a predetermined threshold; and configuring the IAB node to determine whether an elapsed time between reception of a data unit at the IAB node and transmission of the data unit to a parent node is over a predetermined threshold. However, Akl from the same or similar fields of endeavor teaches the use of: wherein configuring an IAB node to evaluate a level of congestion of an egress link of the IAB node comprises performing at least one of: configuring the IAB node to receive flow control feedback from at least one of a parent node and a child node of the IAB node, wherein the flow control feedback includes a buffer size at the respective at least one of a parent node and a child node, and configuring the IAB node to determining whether the buffer size at the at least one of a parent node and a child node is over a predetermined threshold; (Akl: para. [0219] activation event component 1145 may identify the event based on receiving a buffer status reporting indicating congestion at one or more access nodes of the wireless backhaul communications network. In some examples, the activation event component 1145 may identify the event based on establishment, or release, or modification, of a radio link control channel at one or more access nodes of the wireless backhaul communications network. In some examples, the activation event component 1145 may identify the event based on a time period elapsing; Akl’381: para. [0212]. Para. [0164] an intermediate node may buffer data prior to enabling network coding. The amount of data to buffer may be configured by the CU of the donor IAB node. The amount of available data may be a trigger to activate or deactivate network coding. For example, if an intermediate IAB node determines that an amount of data for one or more received packets of a packet flow satisfies a network coding threshold, the intermediate IAB node may perform a network encoding operation on the received packets of the packet flow; Akl’381: para. [0161]) and configuring the IAB node to determine whether an elapsed time between reception of a data unit at the IAB node and transmission of the data unit to a parent node is over a predetermined threshold. (Akl: para. [0219] the activation event component 1145 may identify the event based on a time period elapsing. Para. [0203] in the event the uplink transmissions are experiencing a long delay, as indicative by the time elapsed between reception of Medium Access Control (MAC) SDU from higher layers until transmission to the parent node of such MAC SDU, the IAB node may perform rerouting when the delay exceeds a delay threshold. This delay threshold may be configured by the donor CU.); Akl’381: para. [0212 & 0146]). Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to use the teaching of Akl in the method of Huawei and Huang. One of ordinary skill in the art would be motivated to do so for a destination IAB node or IAB donor DU address or path identifier may be unique within an IAB donor CU (Akl: para. [0154]) . 07-21-aia AIA Claim (s) 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Huawei . Regarding claim 17 , Huawei teaches the method according to claim 16, wherein the reserve bit is a reroute bit, and setting the reroute bit comprises setting the bit value. (Huawei: 2.4 proposal 6 - If the path indicated by the path ID in the BAP header is not available (e.g. BH RLF), BAP resets the path ID in BAP header as one of the actual path to be re-routed, or resets the path ID to the default value, e.g. all zero values). Although Huawei does not explicitly teach: setting the bit value to 1 (Huawei: 2.4 proposal 6 - If the path indicated by the path ID in the BAP header is not available (e.g. BH RLF), BAP resets the path ID in BAP header as one of the actual path to be re-routed, or resets the path ID to the default value, e.g. all zero values – it would have been obvious to one ordinary skill in the art to modify the resetting bit value from all zero values to 1 ). Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to use the modified teaching of Huawei in the method of Huawei. One of ordinary skill in the art would be motivated to do so for avoid conflict and more restrictions for allocating BAP path ID (Huawei: 2.4) . Allowable Subject Matter 12-151-07 AIA 07-97 12-51-07 Claim s 1 – 4 allowed. Response to Arguments 07-37 AIA Applicant's arguments filed 05/13/2026 have been fully considered but they are not persuasive. With regard to applicant’s remark on claim 5 pages 7-8, applicant submits: “Applicant submits that Huawei does not disclose or suggest the newly presented feature of "wherein different paths terminating at different donor DUs and associated with the same BAP address are assigned different BAP path IDs" of amended independent Claim 5. Accordingly, the allowance of independent Claim 5 is respectfully requested.” (page 8) However, Huawei in section 2.1 - Issue 1: Which BAP routing ID to be added in BAP header for UL – page 1 last bullet to page 2 1st paragraph teaches BAP address configuration for upstream - A) assigning BAP address. Multiple IAB donor DUs will share same BAP address if these DUs connects to a same IAB donor CU-UP, i.e. same BAP address to each of the plurality of donor DUs. Fig. 3 shows IAB-donor-DU1 and IAB-donor-DU2 share the same BAP address (corresponds to claim limitation “different donor DUs associated with the same BAP address”). page 2 1st bullet – Configuration of upstream BAP path ID for access IAB node - IAB donor CU may optionally configure one or multiple BAP path IDs towards each BAP address. Finally, Fig. 1 and Fig. 2 show multiple different paths from IAB node to IAB donor node, where each of the three different paths assigned with their respective different BAP path IDs within the same BAP address, Pages 2-4 sec. 2.2 and Fig. 1. In addition, page 4 - Option 2a. The intermediate IAB node changes the BAP path ID to identify the actual path, which is selected when perform re-routing – teaches each path is assigned with a unique BAP (corresponds to claim limitation “different paths terminating at different donor DUs are assigned different BAP path IDs”) and toward same destination BAP address, which includes IAB donor DU1 and IAB-donor-DU2. This option will avoid the confliction. Therefore, the Huawei teaches claim limitation “wherein different paths terminating at different donor DUs and associated with the same BAP address are assigned different BAP path IDs”, and thus rejection is maintained . 07-37 AIA Applicant's arguments filed 05/13/2026 have been fully considered but they are not persuasive. With regard to applicant’s remark on claim 5 pages 7-8, applicant submits: “ Applicant submits that Huawei does not disclose or suggest the newly presented features of "wherein the rerouting comprises selecting another path from the BH routing configuration for forwarding the first packet" of amended independent Claim 11. Accordingly, the allowance of independent Claim 11 is respectfully requested.” (page 9) Huawei on page 3 2 nd paragraph teaches the intermediate IAB node needs to choose another next hop link different from the one indicated by the entry of the BAP path ID and BAP address, the IAB node may look up the routing table (corresponds to claim limitation “BH routing configuration”) and find another entry with same BAP address. In addition, Huawei on Page 5 2.5 - Issue 5: RLF handling of routing for the IAB node connecting to multiple donor DUs – 1 st paragraph - Each BAP address can have one or multiple entries in the routing table (corresponds to claim limitation “BH routing configuration”) to enable local route selection. Multiple entries is for load balancing, re-routing at RLF. Therefore, Huawei teaches the claim limitation “wherein the rerouting comprises selecting another path from the BH routing configuration for forwarding the first packet”, and thus rejection is maintained . Conclusion 07-96 AIA The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Please also see PTO-892 . Zhuo et al. EP 4120727 A1 teaches first IAB node may select another BAP address or another path ID in a routing table to perform routing. The another BAP address (for example, a BAP address of a first donor DU) and the BAP addresses (for example, a BAP address of a second donor DU) in the RLF notification belong to a same donor CU. Any inquiry concerning this communication or earlier communications from the examiner should be directed to WUTCHUNG CHU whose telephone number is (571)272-4064. The examiner can normally be reached 10:00 AM - 4:00 PM. 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, Moo R Jeong can be reached at (571) 272-9617. 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. /WUTCHUNG CHU/ Primary Examiner, Art Unit 2418 Application/Control Number: 18/247,948 Page 2 Art Unit: 2418 Application/Control Number: 18/247,948 Page 3 Art Unit: 2418 Application/Control Number: 18/247,948 Page 4 Art Unit: 2418 Application/Control Number: 18/247,948 Page 5 Art Unit: 2418 Application/Control Number: 18/247,948 Page 6 Art Unit: 2418 Application/Control Number: 18/247,948 Page 7 Art Unit: 2418 Application/Control Number: 18/247,948 Page 8 Art Unit: 2418 Application/Control Number: 18/247,948 Page 9 Art Unit: 2418 Application/Control Number: 18/247,948 Page 10 Art Unit: 2418 Application/Control Number: 18/247,948 Page 11 Art Unit: 2418 Application/Control Number: 18/247,948 Page 12 Art Unit: 2418 Application/Control Number: 18/247,948 Page 13 Art Unit: 2418 Application/Control Number: 18/247,948 Page 14 Art Unit: 2418 Application/Control Number: 18/247,948 Page 15 Art Unit: 2418 Application/Control Number: 18/247,948 Page 16 Art Unit: 2418 Application/Control Number: 18/247,948 Page 17 Art Unit: 2418 Application/Control Number: 18/247,948 Page 18 Art Unit: 2418 Application/Control Number: 18/247,948 Page 19 Art Unit: 2418 Application/Control Number: 18/247,948 Page 20 Art Unit: 2418 Application/Control Number: 18/247,948 Page 21 Art Unit: 2418
Prosecution Insights