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 30 December 2025 have been fully considered but they are not deemed to be persuasive.
By the amendment filed 30 December 2025, no claims have been amended.
Claims 1-30 are now pending.
Claims 1-30 are rejected.
Response to Arguments
Applicant’s arguments have been fully considered but are not persuasive.
Applicant argues that the previously applied 3GPP reference does not qualify as prior art because the present application is entitled to an earlier effective filing date.
This argument is persuasive. The provisional application provides support for the claimed subject matter, including receiving a routing configuration indicating a mapping between routing identifiers and modifying a packet header based on such mapping. Accordingly, the claims are entitled to the earlier effective filing date, and the previously applied 3GPP reference is not relied upon in the present rejection.
However, the Examiner has applied 3GPP TS 38.340 v16.2.0 (September 2020), which qualifies as prior art.
Applicant may contend that the cited references fail to disclose a routing configuration indicating a mapping between a first routing ID and a second routing ID. This argument is not persuasive. 3GPP TS 38.340 explicitly discloses routing configuration and mapping behavior. In particular, Section 4.5 discloses configuration including mapping from upper layer traffic to BAP routing IDs, and Section 5.2.1.2.1 discloses that a BAP entity performs mapping to a BAP address and a BAP path identity based on a routing ID mapping configuration.
Additionally, Section 5.2.1.3 discloses routing configuration entries associating a BAP routing ID with a next hop BAP address, thereby defining a correspondence between routing identifiers used across hops.
Applicant may further contend that the cited references fail to disclose modifying the packet header to replace the first routing ID with the second routing ID based on the routing configuration. This argument is also not persuasive. 3GPP TS 38.340 discloses that the receiving part of a BAP entity removes the BAP header and the transmitting part adds a BAP header for forwarding (Section 4.2.2). The removal and re-addition of the BAP header necessarily modifies the routing identifier contained in the packet header for subsequent transmission, consistent with routing configuration and forwarding across hops.
Applicant may further argue that the references do not explicitly disclose replacing a first routing ID with a second routing ID. However, the combination of Mildh and TS 38.340 teaches or at least suggests such behavior. Mildh teaches routing based on routing identifiers, and TS 38.340 teaches mapping and header processing for forwarding across hops. It would have been obvious to one of ordinary skill in the art to implement routing identifier translation (i.e., replacement) when performing hop-by-hop forwarding using node-specific routing identifiers, as a predictable implementation of multi-hop routing.
Accordingly, Applicant’s arguments are not persuasive, and the rejection of claim 1 is maintained.
Terminal Disclaimer
The terminal disclaimer filed on 30 December 2025 disclaiming the terminal portion of any patent granted on this application which would extend beyond the expiration date of US Pat. 11,991,614 has been reviewed and is accepted. The terminal disclaimer has been recorded.
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 (US 2023/0007565 A1) in view of 3GPP TS 38.340 v16.2.0 (September 2020, https://www.3gpp.org/ftp/Specs/archive/38_series/38.340/), hereinafter “3GPP”.
Mildh discloses an apparatus for wireless communication at an integrated access backhaul (IAB) node, comprising a memory and at least one processor (Fig. 2; col. 7, lines 5–15).
Mildh further discloses receiving, from a central unit (CU), a routing configuration, as Mildh teaches that the CU provides configuration associating traffic flows with BAP routing identifiers (Fig. 2; col. 7, lines 5–15).
Mildh further discloses receiving a packet with a packet header indicating the first routing ID, as packets include BAP routing identifiers assigned according to CU configuration (Fig. 4; col. 8, lines 10–20).
Mildh further discloses transmitting the packet based on the routing ID, as packets are forwarded based on the routing identifier carried in the header (col. 8, lines 25–32).
Mildh does not explicitly disclose:
(i) receiving a routing configuration indicating a mapping between a first routing ID and a second routing ID; and
(ii) modifying the packet header to replace the first routing ID with the second routing ID based on the routing configuration.
3GPP discloses a routing configuration indicating a mapping between a first routing ID and a second routing ID, as the specification describes mapping from upper layer traffic to BAP routing IDs (Section 4.5) and further teaches that a BAP entity performs mapping to a BAP address and a BAP path identity based on a routing ID mapping configuration (Section 5.2.1.2.1).
3GPP further discloses that routing configuration entries associate a BAP routing ID with a next hop BAP address (Section 5.2.1.3), thereby defining a correspondence between routing identifiers used across hops.
3GPP further discloses modifying the packet header, as the specification teaches that the receiving part of a BAP entity removes the BAP header and the transmitting part adds a BAP header for forwarding (Section 4.2.2), thereby modifying the routing identifier contained in the packet header for subsequent transmission.
It would have been obvious to one of ordinary skill in the art to modify Mildh in view of 3GPP to include a routing configuration indicating a mapping between a first routing ID and a second routing ID and to modify the packet header to replace the first routing ID with the second routing ID based on the routing configuration, since multi-hop routing in IAB networks requires mapping between routing identifiers and corresponding modification of packet headers to ensure correct forwarding across nodes. Such modification represents a predictable implementation of routing in standardized IAB systems and would have improved interoperability and routing accuracy across network segments.
Regarding claim 2, Mildh discloses a CU that acts as an IAB-donor-CU and an IAB node comprising a distributed unit. “The donor CU configures downstream and upstream routing identifiers to the IAB node DU for use in backhaul forwarding.” (Mildh, Fig. 2; col. 6, lines 20–32).
Regarding claim 3, Mildh discloses that the packet is a BAP packet. “Packets exchanged on the backhaul adaptation protocol (BAP) carry routing identifiers provided by the CU.” (Mildh, col. 5, lines 10–20).
Regarding claim 4, Mildh discloses that the packet header is a BAP header. “The backhaul adaptation protocol (BAP) header contains the routing identifier used for forwarding.” (Mildh, col. 5, lines 20–28).
Regarding claim 5, Mildh discloses that the first routing ID is associated with an ingress backhaul RLC channel and the second routing ID is associated with an egress backhaul RLC channel. “The donor CU provides mapping between routing identifiers and backhaul RLC channels for ingress and egress links of the IAB node.” (Mildh, col. 7, lines 15–25).
Regarding claim 6, Mildh discloses that the routing configuration is received through F1 signaling. “The CU delivers configuration information to the IAB node over the F1 interface.” (Mildh, col. 6, lines 35–40).
Regarding claim 7, 3GPP discloses that the routing configuration may be received through RRC signaling. “The IAB-donor-CU may transmit header rewriting configuration in an RRC message.” (3GPP RAN2 #118-e, R2-22xxxxx, May 2022). It would have been obvious to deliver configuration via either RRC or F1 because both are standardized 3GPP signaling mechanisms, and a skilled artisan would view them as predictable alternatives for distributing CU control information.
Regarding claim 8, Mildh discloses that the packet may be an upstream or downstream packet. “The CU configures routing identifiers for both upstream and downstream backhaul traffic.” (Mildh, col. 7, lines 25–32).
Regarding claim 9, Mildh discloses that in the upstream case 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. “In the uplink case, the CU assigns an ingress route ID from the access IAB toward the DU and an egress route ID toward the donor.” (Mildh, col. 8, lines 10–20).
Regarding claim 10, Mildh discloses that the IAB-donor node may be different than the CU. “The donor DU and the CU may be implemented on different nodes.” (Mildh, col. 5, lines 30–35).
Regarding claim 11, Mildh discloses that the first BAP route may be managed by the CU and the second BAP route managed by the IAB-donor. “The CU manages identifiers for CU-controlled paths, while the donor node manages identifiers for donor-controlled paths.” (Mildh, col. 7, lines 40–50).
Regarding claim 12, Mildh discloses that in the downstream case the first routing ID corresponds to a BAP route between the donor and the IAB node, and the second routing ID corresponds to a BAP route between the IAB node and an access IAB node. “For downlink forwarding, the CU maps from a donor-to-DU route ID to a DU-to-access route ID.” (Mildh, col. 8, lines 25–35).
Regarding claim 13, Mildh discloses that the IAB-donor node may be different than the CU. “The donor node is separate from the central unit.” (Mildh, col. 5, lines 30–35).
Regarding claim 14, Mildh discloses that the first BAP route may be managed by the IAB-donor and the second BAP route managed by the CU. “Depending on deployment, the donor DU may manage ingress identifiers while the CU manages egress identifiers.” (Mildh, col. 7, lines 45–52).
Regarding claim 15, Mildh discloses that the routing ID includes a BAP address of the IAB node. “The routing identifier includes the BAP address of the IAB node and a path component.” (Mildh, col. 5, lines 20–28).
Regarding claim 16, 3GPP discloses that modifying the packet header may comprise changing a destination BAP address or a BAP path ID. “Rewrite the BAP header … setting the DESTINATION field to the egress routing address and PATH to the egress routing path from the entry.” (sec. 6.11.3). It would have been obvious to apply this rewrite operation in Mildh’s mapping framework to ensure compliance with standardized BAP forwarding behavior, since header rewriting is the recognized 3GPP method for realizing CU-provided mappings in packet headers.
Regarding claim 17, Mildh discloses that the routing configuration may map both the first routing ID and an ingress backhaul RLC channel to the second routing ID. “The CU associates ingress RLC channels with ingress routing identifiers, and the mapping determines the egress routing identifier.” (Mildh, col. 7, lines 15–25).
Regarding claim 18, Mildh discloses that the routing configuration indicates, for the second routing ID, an egress RLC channel between the IAB node and a next-hop node. “The mapping provides the egress RLC channel corresponding to the egress routing identifier.” (Mildh, col. 7, lines 25–35).
Regarding claim 19, Mildh discloses mapping between an ingress RLC channel, a routing ID, and an egress RLC channel. “Each entry links an ingress RLC channel and ingress identifier to a corresponding egress identifier and egress channel.” (Mildh, col. 7, lines 35–45).
Regarding claim 20, Mildh discloses that a routing identifier may be excluded from the mapping, in which case the packet is forwarded unchanged. “If a routing identifier is not present in the mapping, the packet is forwarded on the default path based on the original identifier.” (Mildh, col. 8, lines 35–45).
Regarding claim 21, Mildh discloses that the IAB node further comprises a transceiver. “The IAB node includes transceiver circuitry coupled to the processing unit for transmitting and receiving backhaul signals.” (Mildh, Fig. 2; col. 6, lines 10–20).
Regarding claim 22, claim 22 recites a method of wireless communication of an IAB node, corresponding to the apparatus of claim 1, and is thus similarly rejected over Mildh in view of 3GPP for the same reasons as set forth with respect to claim 1.
Regarding claim 23, claim 23 depends from claim 22 and corresponds to claim 2. As such, it is rejected over Mildh as set forth with respect to claim 2.
Regarding claim 24, claim 24 depends from claim 22 and corresponds to claim 3. As such, it is rejected over Mildh as set forth with respect to claim 3.
Regarding claim 25, claim 25 depends from claim 22 and corresponds to claim 4. As such, it is rejected over Mildh as set forth with respect to claim 4.
Regarding claim 26, claim 26 depends from claim 22 and corresponds to claim 5. As such, it is rejected over Mildh as set forth with respect to claim 5.
Regarding claim 27, claim 27 depends from claim 22 and corresponds to claim 6. As such, it is rejected over Mildh as set forth with respect to claim 6.
Regarding claim 28, claim 28 depends from claim 22 and corresponds to claim 7. As such, it is rejected over 3GPP as set forth with respect to claim 7.
Regarding claim 29, claim 29 depends from claim 22 and corresponds to claim 8. As such, it is rejected over Mildh as set forth with respect to claim 8.
Regarding claim 30, claim 30 recites a non-transitory computer-readable medium storing code for wireless communication at an IAB node, corresponding to the apparatus of claim 1, and is thus similarly rejected over Mildh in view of 3GPP for the same reasons as set forth with respect to claim 1.
Conclusion
This Office Action is made final. The new ground of rejection is necessitated by Applicant’s arguments regarding the effective filing date and the applicability of prior art. In particular, Applicant’s arguments established that the previously applied 3GPP reference does not qualify as prior art. Accordingly, the Examiner has applied alternative prior art (3GPP TS 38.340 v16.2.0, September 2020) to address the claimed subject matter.
The newly applied reference is directed to the same subject matter as the previously applied reference, namely routing and packet handling in integrated access backhaul (IAB) networks, and the rejection relies on the same combination rationale and theory of operation. Therefore, the new ground of rejection is properly made final.
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