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
Applicants’ arguments filed on 29 July 2026 have been fully considered but they are moot in view of the new ground of rejection.
By the amendment filed 29 July 2026, claims 1, 22, and 30 have been amended.
Claims 1-30 are now pending.
Claims 1-30 are rejected.
Claim Rejections - 35 USC § 103
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 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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1–30 are rejected under 35 U.S.C. § 103 as being unpatentable over Mildh et al. (US 2023/0007565 A1) in view of Zhuo et al. (US 2022/0174579 A1).
Regarding claim 1, Mildh teaches “An apparatus for wireless communication at an integrated access backhaul (IAB) node, comprising: a memory; and at least one processor coupled to the memory and configured to:” perform IAB routing operations. Mildh describes IAB nodes having DU and MT functionality controlled by an IAB donor CU and performing multi-hop packet forwarding through a BAP layer (Mildh ¶¶4–13). Mildh further discloses processing circuitry and device-readable memory configured to execute the disclosed routing functions (Mildh ¶¶108–116).
Mildh further teaches “receive, from a central unit (CU), a routing configuration” by teaching that the BAP layer is configured with routing and bearer mappings and that such configuration is provided under control of the IAB donor CU (Mildh ¶¶12–13, 20). Mildh further teaches that the IAB donor CU sends mapping information to an IAB node, including mappings associated with BAP routing IDs, and that the IAB node receives the mapping from the IAB donor CU (Mildh ¶¶91–94). Mildh also teaches transmitting such mapping information from the donor CU to the IAB node by RRC signaling (Mildh ¶¶161–163).
Mildh further teaches “receive a packet with a packet header indicating the first routing ID” by teaching that a BAP routing ID is carried in the BAP header and that routing of a packet is performed using the BAP routing ID contained in the BAP header (Mildh ¶¶12–14). Mildh further teaches that packets arriving at an IAB node are processed by the BAP layer and forwarded toward a next hop according to the configured routing and bearer mappings (Mildh ¶¶19–22).
Mildh further teaches “transmit the packet based on the second routing ID” insofar as Mildh teaches transmitting packets according to BAP routing IDs. Mildh teaches that the BAP layer determines the route and backhaul RLC channel for forwarding according to the configured routing and bearer mappings (Mildh ¶¶20, 22). Mildh further teaches that separate communication paths may be associated with separate BAP routing IDs (Mildh ¶¶28, 32, 36) and that an IAB node transmits a communication using a communication path represented by the applicable BAP routing ID (Mildh ¶¶161–167).
Mildh does not expressly teach “a routing configuration indicating a mapping between a first routing identifier (ID) and a second routing ID that is different than the first routing ID” and “modify the packet header to replace the first routing ID with the second routing ID based on the routing configuration.”
Zhuo teaches “a routing configuration indicating a mapping between a first routing identifier (ID) and a second routing ID that is different than the first routing ID.” Zhuo teaches that an IAB donor CU configures an IAB node with identifiers of one or more alternative destination nodes. When the routing path to the original destination fails or is congested, the IAB node uses the identifier of an alternative destination node as the new BAP address of the destination node for routing (Zhuo ¶¶94–96). Zhuo further teaches that the IAB donor may directly configure BAP addresses of one or more alternative destination nodes for the BAP address of each destination node. For example, Zhuo teaches configuring the identifier of gNB-DU2 as the alternative BAP address corresponding to the identifier of gNB-DU1 (Zhuo ¶99). Thus, Zhuo teaches a CU-provided mapping between an original routing identifier and a different alternative routing identifier.
Zhuo further teaches “modify the packet header to replace the first routing ID with the second routing ID based on the routing configuration.” Zhuo expressly teaches that the IAB node may “replace the BAP address of the destination node carried in a BAP header in the received data packet with the identifier of the second node” and thereafter perform routing based on the replacement identifier (Zhuo ¶¶95–100). Zhuo additionally teaches modifying the BAP header of a received packet when a new destination node or routing path is determined (Zhuo ¶¶158–160). In the specific example of Zhuo ¶¶207–211, IAB node 3 determines that the radio link to the original destination, IAB node 1, has failed, modifies the BAP header by using the BAP ID of IAB node 2 as the BAP address of the destination node, determines the next-hop node based on the modified BAP header, and sends the packet toward IAB node 2.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the IAB routing arrangement of Mildh to employ Zhuo's donor-CU-configured mapping between an original routing identifier and an alternative routing identifier and to replace the original routing identifier in the received packet header with the alternative routing identifier when rerouting is required. One would have been motivated to make such a modification to permit an IAB node to redirect a packet to an available alternative destination when the route to the original destination is unavailable or congested, thereby allowing continued packet transmission without waiting for recovery of the original radio link and reducing service latency, as taught by Zhuo (Zhuo ¶100).
Regarding claim 2, Mildh further teaches “wherein the CU is an IAB-donor-CU and the IAB node comprises a distributed unit (DU).” Mildh teaches that the IAB architecture includes an IAB-donor comprising gNB-DU and gNB-CU functions and IAB nodes having DU functionality controlled by a central unit (Mildh ¶¶4, 7–9).
Regarding claim 3, Mildh further teaches “wherein the packet is a backhaul adaptation protocol (BAP) packet.” Mildh teaches a Backhaul Adaptation Protocol (BAP) layer at IAB nodes and the IAB-donor for routing packets to appropriate downstream or upstream nodes and describes processing and forwarding packets by the BAP layer (Mildh ¶¶10–13, 18–22).
Regarding claim 4, Mildh further teaches “wherein the packet header is a BAP header.” Mildh expressly teaches that the BAP Routing ID is carried in the BAP header and describes the BAP data PDU header (Mildh ¶¶13, 15–16).
Regarding claim 5, Mildh further teaches “wherein the first routing ID is associated with an ingress backhaul radio link control (RLC) channel and the second routing ID is associated with an egress backhaul RLC channel.” Mildh teaches that the BAP layer performs routing and bearer mapping, including mapping between ingress and egress backhaul RLC channels at intermediate IAB nodes (Mildh ¶¶10–11). Mildh further teaches that, for a packet retrieved from the RLC layer, the IAB node is configured with a mapping of a BAP routing ID in the BAP header to an egress link and a mapping of an ingress RLC channel to an egress RLC channel (Mildh ¶13). Thus, the routing ID used for routing the received packet is associated with the ingress-side processing of the packet and the routing ID identifying the selected route is associated with the egress link and corresponding egress RLC channel.
Regarding claim 6, Mildh further teaches “wherein the routing configuration is received through F1 signaling.” Mildh teaches that BAP includes a DU part configured by F1-AP and an MT part configured by RRC (Mildh ¶13). Mildh further teaches that the IAB architecture reuses the F1 interface and that F1-C and F1-U terminate at the IAB node (Mildh ¶¶5, 9).
Regarding claim 7, Mildh further teaches “wherein the routing configuration is received through radio resource control (RRC) signaling.” Mildh expressly teaches that the BAP MT part is configured by RRC (Mildh ¶13) and further teaches receiving mapping information from the IAB donor CU through RRC signaling (Mildh claims 36–37).
Regarding claim 8, Mildh further teaches “wherein the packet is an upstream packet or a downstream packet.” Mildh separately describes BAP packet processing and forwarding in both the downlink and uplink directions (Mildh ¶¶18–22).
Regarding claim 9, Mildh further teaches “wherein, for the upstream packet, the first routing ID corresponds to a first BAP route between an access IAB node and the IAB node, and the second routing ID corresponds to a second BAP route between the IAB node and an IAB-donor.” Mildh teaches that, in the uplink direction, a packet received at an IAB node from a child IAB node over a backhaul RLC channel is processed by the DU BAP layer and passed to the MT BAP layer because every uplink packet is destined for the donor CU. The MT BAP then determines the route, including the parent node, and the backhaul RLC channel used to forward the packet upstream (Mildh ¶¶21–22). Mildh further teaches multiple communication paths and redundant routes toward the IAB donor CU (Mildh ¶23). Zhuo further teaches modifying routing information of a received BAP packet to use a different destination or routing identifier for subsequent forwarding when an alternative route is selected (Zhuo ¶¶94–100). It would have been obvious to employ Zhuo's routing-ID replacement in Mildh's multi-hop upstream routing to permit the packet to be forwarded using the routing identifier applicable to the selected upstream route toward the IAB donor.
Regarding claim 10, Mildh further teaches “wherein the IAB-donor is different than the CU.” Mildh teaches that an IAB-donor is a logical node comprising gNB-DU, gNB-CU-CP, and gNB-CU-UP functions and that these functions may be collocated or non-collocated (Mildh ¶7).
Regarding claim 11, Zhuo further teaches “wherein the first BAP route is managed by the CU and the second BAP route is managed by the IAB-donor.” Zhuo teaches that a donor CU configures routing paths and routing-table information used by an IAB node to route packets, including configuring a default routing path and routing information for selecting among available paths (Zhuo ¶¶103–105). Zhuo further teaches that the IAB donor may directly configure BAP addresses of one or more alternative destination nodes for the BAP address of an existing destination node, such that the alternative destination information is used to route a packet over an alternative route (Zhuo ¶¶94–100). It would have been obvious to employ Zhuo's CU- and IAB-donor-controlled routing configuration in the multi-hop BAP routing arrangement of Mildh so that the respective network control entities manage the routes for which they provide routing information, thereby facilitating rerouting and continued packet delivery when an existing route becomes unavailable or congested.
Regarding claim 12, Mildh further teaches “wherein, for the downstream packet, the first routing ID corresponds to a first BAP route between the IAB-donor and the IAB node, and the second routing ID corresponds to a second BAP route between the IAB node and an access IAB node.” Mildh teaches that, in the downlink direction, a packet received at the IAB-donor DU from the donor CU and requiring further downstream forwarding is passed to the DU BAP layer (Mildh ¶18). At an intermediate IAB node, a packet received from a parent IAB node or IAB-donor DU is processed by the MT BAP layer and, when further downstream forwarding is required, is passed to the DU BAP layer (Mildh ¶19). The DU BAP then determines the route to the child node and the backhaul RLC channel used for downstream forwarding based on the routing and bearer-mapping table configured by the IAB-donor CU (Mildh ¶20). Zhuo further teaches changing routing information carried by a BAP packet to identify a different destination or path and thereafter routing the packet according to the modified BAP header (Zhuo ¶¶94–100). It would have been obvious to employ Zhuo's BAP-header modification in Mildh's downstream multi-hop forwarding to permit the packet to be forwarded according to the routing identifier applicable to the selected downstream route toward the access IAB node.
Regarding claim 13, Mildh further teaches “wherein the IAB-donor is different than the CU.” Mildh teaches that the IAB-donor is a logical node comprising gNB-DU, gNB-CU-CP, and gNB-CU-UP functions, which may be collocated or non-collocated (Mildh ¶7).
Regarding claim 14, Zhuo further teaches “wherein the first BAP route is managed by the IAB-donor and the second BAP route is managed by the CU.” Zhuo teaches that the IAB donor may directly configure BAP addresses of one or more alternative destination nodes for the BAP address of an existing destination node, thereby controlling the alternative routing information used for rerouting (Zhuo ¶¶94–100). Zhuo further teaches that a donor CU configures routing paths and routing-table information used by an IAB node, including configuring a default routing path and routing information for selecting among available paths (Zhuo ¶¶103–105). It would have been obvious to employ Zhuo's IAB-donor- and CU-controlled routing configuration in the multi-hop BAP routing arrangement of Mildh so that the respective network control entities manage the routes for which they provide routing information, thereby facilitating route selection and rerouting in the IAB network.
Regarding claim 15, Mildh further teaches “wherein the routing ID includes a BAP address of the IAB node.” Mildh expressly teaches that a BAP Routing ID consists of a BAP address and a BAP path ID and that each BAP address defines a unique destination, including an IAB access node or the IAB donor (Mildh ¶13).
Regarding claim 16, Zhuo further teaches “wherein modifying the packet header comprises modifying a BAP address of a destination node in the BAP header.” Zhuo teaches that an IAB node may replace the BAP address of the destination node carried in the BAP header of a received data packet with the identifier of an alternative destination node and thereafter route the packet based on the replacement identifier (Zhuo ¶¶94–100). Zhuo further teaches modifying the BAP header when a new destination node or routing path is determined (Zhuo ¶¶158–160), including an example in which an IAB node modifies the BAP header using the BAP ID of a different IAB node as the BAP address of the destination node and forwards the packet according to the modified header (Zhuo ¶¶207–211). It would have been obvious to employ Zhuo's BAP-address modification in Mildh's BAP routing system to permit packets to be redirected to an alternative destination when the original route is unavailable or congested.
Regarding claim 17, Mildh further teaches “wherein the routing configuration maps both the first routing ID and an ingress backhaul RLC channel to the second routing ID.” Mildh teaches that routing and bearer mapping are adaptation-layer functions and that packets relayed by an IAB node are forwarded from the receive part to the transmit part for the next hop (Mildh ¶¶10–11). Mildh further teaches that, for packets retrieved from the RLC layer, the IAB node is configured with a mapping of the BAP routing ID in the BAP header to an egress link and a mapping of the ingress RLC channel to an egress RLC channel (Mildh ¶13). Zhuo further teaches replacing routing information in a received BAP header with different routing information associated with the selected destination or path (Zhuo ¶¶94–100). It would have been obvious to use the incoming routing ID together with Mildh's ingress-channel bearer information in selecting and applying Zhuo's replacement routing identifier because Mildh expressly uses both routing information and ingress-channel information in routing and bearer mapping for relayed packets.
Regarding claim 18, Mildh further teaches “wherein the routing configuration indicates, for the second routing ID, an egress RLC channel between the IAB node and a next-hop node.” Mildh teaches that the BAP layer maps routing information to an egress link and that the DU-BAP and MT-BAP determine both the route or next-hop node and the backhaul RLC channel within that route used to forward the packet (Mildh ¶¶13–14, 20, 22).
Regarding claim 19, Mildh further teaches “wherein the routing configuration comprises an entry including the first routing ID, the ingress backhaul RLC channel, the second routing ID, and the egress backhaul RLC channel.” Mildh teaches that routing and bearer mapping are performed together for relayed packets and that an IAB node is configured with routing and bearer mapping information used to determine both the route and the backhaul RLC channel for forwarding a packet (Mildh ¶¶10–13, 20, 22). Zhuo further teaches mapping a routing ID to an RLC entity ID and explains that data on different routes are transmitted through different RLC entities (Zhuo ¶187). Zhuo also teaches replacing routing information in a received BAP packet with different routing information associated with an alternative destination or path (Zhuo ¶¶94–100). It would have been obvious to include the ingress routing ID and associated ingress RLC channel together with the replacement routing ID and associated egress RLC channel in an entry of the routing configuration, thereby providing the routing and bearer information needed to map a received packet to the appropriate outgoing route and RLC entity.
Regarding claim 20, Mildh further teaches “wherein the routing configuration indicates a default routing ID for the packet.” Mildh is directed to default path assignment in IAB networks and teaches obtaining a mapping between a traffic type and a communication path and transmitting the mapping to an IAB node for use in transmitting communications over the mapped communication path. Mildh further expressly teaches a default traffic type and a communication path identified by a BAP route identifier (Mildh ¶¶44–51; claims 20–21, 45–46).
Regarding claim 21, Mildh further teaches “wherein the apparatus is an IAB network node.” Mildh teaches implementation of the disclosed IAB functionality in network nodes including processing circuitry, memory or device-readable medium, and communication interfaces configured to perform the disclosed communication and routing operations (Mildh ¶¶108–116).
Claim 22 recites substantially identical subject matter as recited in claim 1, except in method form, and is thus similarly rejected.
Claims 23–29 recite substantially identical subject matter as recited in claims 2–8, respectively, and are thus similarly rejected.
Claim 30 recites substantially identical subject matter as recited in claim 1, except in non-transitory computer-readable medium form, and is thus similarly rejected.
Conclusion
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 LUAT T PHUNG whose telephone number is (571)270-3126. The examiner can normally be reached on M-F 9 AM - 6 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, 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.
/Luat Phung/
Primary Examiner, Art Unit 2468
Prosecution Insights