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 .
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(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.
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; and
(Huawei: section 2.1 - Issue 1: Which BAP routing ID to be added in BAP header for UL – pages 1 last bullet 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. See sec. 2. These features correspond to bullet a)
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: 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 (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”). See sec. 2-2.1. These features correspond to bullet b and Fig. 1 and Fig. 2 and Sec. 2.4)
Huawei, e.g. below for Figure 1
PNG
media_image1.png
200
400
media_image1.png
Greyscale
Figure 1. An example of BH link RLF
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. These features correspond to bullet b and Fig. 1 and Fig. 2 and Sec. 2.4)
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, and wherein the IAB node has its Backhaul (BH) routing configuration
(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)
determining 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 – 3rd 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)
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
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.
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 4th – 5th 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 1st paragraph).
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]).
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]).
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
Claims 1 – 4 allowed.
Response to Arguments
Applicant's arguments filed 01/16/2026 have been fully considered but they are not persuasive. With regards to applicant’s remarks on claim 5 (pages 8-9), applicant submits:
“Huawei does not clearly and unequivocally disclose the claimed assignment rule that for each path terminating at a respective donor DU (among plural DUs sharing the same BAP address), a different BAP path ID is assigned as a matter of configuration by the donor CU.
At minimum, Huawei's "multiple BAP path IIDs toward
PNG
media_image2.png
17
6
media_image2.png
Greyscale
s each BAP address" is compatible with multiple alternative paths toward a single destination address (load balancing / redundancy), not necessarily the claim's "terminating at one of the plurality of donor DUs" differentiation requirement under a shared BAP address.
Thus, Applicant submits that Huawei does not disclose or suggest the features of "assigning a same Backhaul Adaptation Protocol (BAP) address to each of the plurality of donor DUs; and 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" of independent Claim 5. Accordingly, the allowance of independent Claim 5 is respectfully requested.” (page 9)
However, the cited paragraphs and Figure 1 and Fig. 2 and Sec. 2.4 of Huawei teaches different paths leads to IAB donor (corresponds to claim limitation “terminating at one IAB donor”) – please see Huawei, e.g. below for Figure 1
PNG
media_image1.png
200
400
media_image1.png
Greyscale
Figure 2. An example of BH link RLF
Each of the different path have its own BAP Path ID (corresponds to claim limitation “a different path identity”) and these different paths originating from IAB node (corresponds to claim limitation “originating from an IAB donor”). Therefore, Huawei teaches the claimed limitation and thus rejection is maintained.
Applicant's arguments filed 01/16/2026 have been fully considered but they are not persuasive. With regards to applicant’s remarks on claim 11 (pages 9-11), applicant submits:
“Huawei, as cited, describes possible RLF/congestion scenarios and proposes approaches such as resetting the path ID, selecting other entries with the same BAP address, or forwarding through other paths.
But, Huawei does not disclose the claimed explicit evaluation by BH routing configuration of the enumerated conditions (including the "destination indicated by the BAP address ... not present" condition) and the claimed action "rerouting ... upon determining" those conditions as a structured method performed by the IAB node.” (page 11)
However, the cited portion(s) of Huawei teaches 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 - Huawei teaches page 3 sec. 2.2 - Issue 2: How to handle the RLF case – 3rd 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. Therefore, Huawei teaches the claimed limitation and thus rejection is maintained.
Applicant’s arguments, see Remarks, filed 01/16/2026, with respect to 112 2nd rejection have been fully considered and are persuasive. The 112 2nd rejection of claim 7 has been withdrawn.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Please also see PTO-892.
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 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 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
Prosecution Insights