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 .
Election/Restrictions
Applicant’s election without traverse of group I in the reply filed on 08/21/2026 is acknowledged.
Claims 21-24, 27-35 and 54-62 withdrawn from further consideration pursuant to 37 CFR 1.142(b) as being drawn to the nonelected group II, group III and group IV, respectively, there being no allowable generic or linking claim. Election was made without traverse in the reply filed on 08/21/2026.
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.
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-2, 5, 7-12, 14-15, 17-18, 20, 39-41, 43, 45-49 and 52-53 are rejected under 35 U.S.C. 103 as being unpatentable over US 2024/0179610 A1 to Sun et al. (hereafter refers as Sun) in view of US 2024/0022965 A1 to Diao et al. (hereafter refers as Diao) and further in view of US 2022/0132394 A1 to AKL et al. (hereafter refers as AKL).
Regarding claim 1, Sun teaches a method for processing data packets at an integrated access and backhaul, IAB, node (a method for processing data packets at IAB node, Fig. 3, 9-14) in an IAB communication system (in an IAB communication system Fig. 3) comprising at least two IAB topologies (the IAB communication system comprises at least two IAB topologies, paragraphs [10, 12, 62, 66, 68, 71, 166] and Fig. 7) and each IAB topology comprising a plurality of IAB nodes (each IAB topology includes a plurality of IAB nodes, Fig. 7 and paragraphs [46, 62, 164, 166, 173]), the method comprising:
receiving a data packet, the data packet (the IAB node receives a first data packet, paragraphs [202, 229] and Fig. 9-10) including a routing identifier (the first data packet includes a routing ID, paragraphs [209-210, 235-238]);
determining whether the routing identifier is to be rewritten updated before transmitting the data packet to another IAB node (determining whether the routing ID is to be rewritten prior to transmitting to the other IAB node, i.e. whether the first data packet is from a second topology, paragraphs [203-210, 212, 233-237] and Fig. 9-10),
in response to determining that the routing identifier is to be rewritten (when determining that the routing ID is to be rewritten/replace, paragraphs [203-210, 212, 233-237] and Fig. 9-10):
identifying, based on a header rewriting configuration information table and the routing identifier of the received data packet, a new routing identifier and an associated IAB topology (identifying a new routing ID/rewritten routing ID and a corresponding IAB topology, based on rewritten table and the routing ID in the first data packet, paragraphs [185-190, 208-212, 215, 217] and table 1);
rewriting the received data packet by rewriting the routing identifier of the received data packet with the identified new routing identifier to provide a rewritten updated data packet including the identified new routing identifier (rewriting the routing ID of the first data packet, with the new/rewritten routing ID, by including the new/rewritten routing ID in the first data packet, paragraphs [213-215, 217, 237-239]); and
transmitting the rewritten data packet over link to the next IAB-node (the IAB node forwards the rewritten first data packet over a correct path to a next IAB-node, paragraphs [223-226, 242-246]),
wherein the header rewriting configuration table including a field for indicating the new routing identifier (wherein the rewritten table includes a field for indicating the new routing ID associated with the topology, i.e. second IAB topology, paragraphs [214-217]).
However, Sun does not explicitly teach “determining, based on routing configuration information associated with the identified IAB topology and the identified new routing identifier, an egress backhaul link over which the data packet is to be routed to a next IAB node” and transmitting the written data packet over the “egress backhaul” link.
Diao teaches determining, based on routing configuration information associated with the identified IAB topology and the identified new routing identifier (based on rewritten configuration associated with a leg/path/flow and the identified new routing ID, paragraphs [24-25, 160, 167-174] and Fig. 2, 4A), an egress backhaul link over which the data packet is to be routed to a next IAB node (determines an egress backhaul link for transmitting the data packet to a next IAB node, paragraphs [160-163, 173-179]); and transmitting the rewritten data packet over the egress backhaul link to the next IAB-node (transmits the rewritten data packet over the egress backhaul link to a next IAB node, paragraphs [160-163, 172]).
Therefore, it would have been obvious to one of the ordinary skills in the art before the effective filing date of the claimed invention to incorporate the teachings of determining, based on routing configuration information associated with the identified IAB topology and the identified new routing identifier, an egress backhaul link over which the data packet is to be routed to a next IAB node and transmitting the rewritten data packet over the egress backhaul link to the next IAB-node as taught by Diao, with the teachings of transmitting the rewritten data packet over link to the next IAB-node and routing configuration information associated with the identified IAB topology and the identified routing identifier as taught by Sun, for a purpose of increase efficiency in transmitting the rewritten data packet by identifying the egress backhaul link for transmitting using the new routing identifier (See AKL, paragraphs [92, 94, 100, 103, 105, 111]).
However, the combination of Sun and Diao does not explicitly teach the field indicating “the IAB topology”.
AKL teaches determining, based on determining, based on routing configuration information associated with the identified IAB topology and the routing identifier, an egress backhaul link over which the data packet is to be routed to a next IAB node ((based on routing configuration information associated with topology and a routing ID, determines an egress backhaul link for transmitting the data packet to a next IAB node, paragraphs [129, 133-136]), and transmitting the data packet over the egress backhaul link to a next IAB-node (transmits the data packet over the egress backhaul link to a next IAB node, paragraphs [111, 112, 115, 133-136]), wherein a header configuration includes a field for indicating an IAB topology associated with a routing identifier (a header configuration table/information includes routing ID which includes a routing ID and a topology identifier, paragraphs [92, 94, 100, 103, 105, 111]).
Therefore, it would have been obvious to one of the ordinary skills in the art before the effective filing date of the claimed invention to incorporate the teachings of field for indicating an IAB topology associated with a routing identifier as taught by AKL, with the teachings of field for indicating the new routing identifier as taught by combination of Sun and Diao, for a purpose of clearly identifying the topology associated with the new routing identifier, by specifying the topology along with the new routing identifier in the field of the header rewriting configuration table (See AKL, paragraphs [92, 94, 100, 103, 105, 111]).
Regarding claims 39 and 40, Sun teaches a non-transitory computer-readable medium (memory, paragraphs [282-289, 294, 303]) carrying a computer program comprising instructions which, when the program is executed by a processing unit of an integrated access and backhaul, IAB, node (wherein the memory stores instructions which, when executed by a processor of an IAB node, paragraphs [282-286]) in an IAB communication system comprising at least two IAB topologies and each IAB topology comprises a plurality of IAB nodes, cause the processing unit to perform the steps (cause the IAB node to perform the functions/steps of the method, paragraphs [282-289]) and an apparatus (IAB node, Fig. 3, 9-14) for an integrated access and backhaul, IAB, node for an IAB communication system comprising at least two IAB topologies and each IAB topology comprising a plurality of IAB nodes, the apparatus comprising:
one or more processing units (the IAB node comprises one or more processors, Fig. 15 and paragraphs [282-286]); and
a memory (the IAB node comprises a memory, Fig. 15 and paragraphs [282-286]) operably connectable to the processing unit (connected to the processor, Fig. 15) and for storing instructions which, when executed by the processing unit, configured the processing unit to (which, when executed by the processor, configured the processor of the IAB node to perform the method, paragraphs [285-287]):
determine whether a routing identifier of a received data packet is to be updated rewritten before transmitting the data packet to another IAB node (determining whether the routing ID is to be rewritten prior to transmitting to the other IAB node, i.e. whether the first data packet is from a second topology, paragraphs [203-210, 212, 233-237] and Fig. 9-10),
in response to determining that the routing identifier is to be rewritten (when determining that the routing ID is to be rewritten/replace, paragraphs [203-210, 212, 233-237] and Fig. 9-10):
identify, based on a header rewriting configuration information table and the routing identifier of the received data packet, a new routing identifier and an associated IAB topology (identifying a new routing ID/rewritten routing ID and a corresponding IAB topology, based on rewritten table and the routing ID in the first data packet, paragraphs [185-190, 208-212, 215, 217] and table 1);
rewrite the received data packet by updating rewriting the routing identifier of the received data packet with the identified new routing identifier to provide a rewritten updated data packet including the identified new routing identifier (rewriting the routing ID of the first data packet, with the new/rewritten routing ID, by including the new/rewritten routing ID in the first data packet, paragraphs [213-215, 217, 237-239]); and
provide the updated rewritten data packet for transmission over a link to the next IAB-node (the IAB node provides the rewritten first data packet for transmission over a correct path to a next IAB-node, paragraphs [223-226, 242-246]),
wherein the header rewriting configuration information comprises a header rewriting configuration table including a field for indicating the new routing identifier (wherein the rewritten table includes a field for indicating the new routing ID associated with the topology, i.e. second IAB topology, paragraphs [214-217]).
However, Sun does not explicitly teach “determine, based on routing configuration information associated with the identified IAB topology and the identified new routing identifier, an egress backhaul link over which the data packet is to be routed to a next IAB node” and provide the rewritten data packet for transmission over the “egress backhaul” link.
Diao teaches determine, based on routing configuration information associated with the identified IAB topology and the identified new routing identifier (based on rewritten configuration associated with a leg/path/flow and the identified new routing ID, paragraphs [24-25, 160, 167-174] and Fig. 2, 4A), an egress backhaul link over which the data packet is to be routed to a next IAB node (determines an egress backhaul link for transmitting the data packet to a next IAB node, paragraphs [160-163, 173-179]) and provide the rewritten data packet for transmission over the egress backhaul ink to the next IAB-node (provides the rewritten data packet for transmission over the egress backhaul link to a next IAB node, paragraphs [160-163, 172]).
Therefore, it would have been obvious to one of the ordinary skills in the art before the effective filing date of the claimed invention to incorporate the teachings of determining, based on routing configuration information associated with the identified IAB topology and the identified new routing identifier, an egress backhaul link over which the data packet is to be routed to a next IAB node and providing the rewritten data packet for transmission over the egress backhaul ink to the next IAB-node as taught by Diao, with the teachings of providing the rewritten data packet over link to the next IAB-node and routing configuration information associated with the identified IAB topology and the identified routing identifier as taught by Sun, for a purpose of increase efficiency in transmitting the rewritten data packet by identifying the egress backhaul link for transmitting using the new routing identifier (See AKL, paragraphs [92, 94, 100, 103, 105, 111]).
However, the combination of Sun and Diao does not explicitly teach the field indicating “the IAB topology”.
AKL teaches determining, based on determining, based on routing configuration information associated with the identified IAB topology and the routing identifier, an egress backhaul link over which the data packet is to be routed to a next IAB node ((based on routing configuration information associated with topology and a routing ID, determines an egress backhaul link for transmitting the data packet to a next IAB node, paragraphs [129, 133-136]), and providing the data packet over the egress backhaul link to a next IAB-node (transmits the data packet over the egress backhaul link to a next IAB node, paragraphs [111, 112, 115, 133-136]), wherein a header configuration includes a field for indicating an IAB topology associated with a routing identifier (a header configuration table/information includes routing ID which includes a routing ID and a topology identifier, paragraphs [92, 94, 100, 103, 105, 111]).
Therefore, it would have been obvious to one of the ordinary skills in the art before the effective filing date of the claimed invention to incorporate the teachings of field for indicating an IAB topology associated with a routing identifier as taught by AKL, with the teachings of field for indicating the new routing identifier as taught by combination of Sun and Diao, for a purpose of clearly identifying the topology associated with the new routing identifier, by specifying the topology along with the new routing identifier in the field of the header rewriting configuration table (See AKL, paragraphs [92, 94, 100, 103, 105, 111]).
Regarding claims 2 and 41, the combination of Sun, Diao and AKL further teaches wherein the received data packet is a Backhaul Adaptation Protocol, BAP, data packet comprising a BAP header including the routing identifier (wherein the received data packet comprises a BAP header including the routing ID, see Sun, paragraphs [202-206, 208, 214-217], see Diao, paragraphs [160-163, 167-175]).
Regarding claims 5 and 43, the combination of Sun, Diao and AKL further teaches wherein routing configuration information comprises a routing configuration table having at least one entry (wherein the routing table comprising at least one entry, see Sun, paragraphs [35-39]), each entry of the routing configuration table including; a routing identifier field for a routing identifier (the routing table comprises a routing ID, see Sun, paragraphs [39-40, 43, 48-50, 233-234, 249, 276-278], see AKL, paragraphs [103, 110]), the routing identifier field comprising a destination address field for an address of an IAB node, and a path identifier field for a path identifier of a routing path to the IAB node (wherein the routing ID comprising a destination address and a path ID, see Sun, paragraphs [39-40, 43, 48-50, 233-234, 249, 276-278], see AKL, paragraphs [103, 110]);
a next hop address field for indicating an address of a next IAB node in the routing path identified by the path identifier (the routing table comprises a next hop BAP address indicating next IAB node in a routing path, see Sun, paragraphs [39-40, 43, 48-50, 233-234, 249, 276-278], see AKL, paragraphs [103, 110]).
Regarding claims 7 and 45, the combination of Sun, Diao and AKL further teaches selecting a backhaul RLC channel for the egress backhaul link based on the identified IAB topology associated with the egress backhaul link and backhaul RLC channel mapping information (selecting a backhaul RLC channel for egress based on the topology and mapping information, see Diao, paragraphs [75-78, 161-165, 173], see AKL, paragraphs [100, 103, 111, 113, 116, 119, 122]).
Regarding claims 8 and 46, the combination of Sun, Diao and AKL further teaches wherein the backhaul RLC channel mapping information comprises a backhaul RLC channel mapping configuration table having at least one entry, each entry including:
a next hop address field for a next hop address of a next IAB node that is next to the IAB node in a routing path (next hop BAP address, see Diao, paragraphs [41-53], see AKL, paragraph [103]),
an egress topology field for indicating the IAB topology associated with the next IAB node, and for indicating with the next hop address field an egress backhaul link between the IAB node and the next IAB node (topology for outputting, see AKL, paragraphs [100, 103, 111, 113]),
a prior hop address field for a prior hop address of a prior IAB node that is prior to the IAB node in the routing path (prior hop BAP address, see Diao, paragraphs [41-53]),
an ingress topology field for indicating the IAB topology associated with the prior IAB node, and for indicating with the prior hop address field an ingress backhaul link between the IAB node and the prior IAB node (topology associated with received packet, see AKL, paragraphs [111-113, 130-133, 167-169]),
an ingress backhaul RLC channel identifier field for a backhaul RLC channel identifier of a backhaul RLC channel of the ingress backhaul link (ingress BH RLC channel ID, see Diao, paragraphs [41-53]), and
an egress backhaul RLC channel identifier field for a backhaul RLC channel identifier of a backhaul RLC channel for the egress backhaul link (egress BH RLC channel ID, see Diao, paragraphs [41-53, 164-167], see AKL, paragraphs [88-89, 103]).
Regarding claims 9 and 47, the combination of Sun, Diao and AKL further teaches wherein receiving a data packet comprises receiving the data packet from a prior IAB node over an ingress BH link (receiving data packet from a prior AIB node over an ingress BH link, see Sun, paragraph [208], see AKL, paragraphs [88, 89, 111, 133-134]), wherein selecting a backhaul RLC channel for the egress backhaul link (selecting a backhaul RLC channel for the egress BH link, see AKL, paragraphs [88, 89, 111, 133-134]) comprises:
checking the backhaul RLC channel mapping configuration table to determine whether a backhaul RLC channel ID of the ingress backhaul link, an address of the prior IAB node, the IAB topology associated with the prior IAB node, an address of the next IAB node and the IAB topology associated with the next IAB node match the respective fields of an entry in the backhaul RLC channel mapping configuration table (determining whether a backhaul RLC channel, prior address, an address of next IAB node and topology match an entry in the table, see Diao, paragraphs [41-53, 164-167], see AKL, paragraphs [111-113, 130-133, 167-169]); and
when a match with an entry is determined, using the egress backhaul RLC channel ID of the matched entry to select the backhaul RLC channel for the egress backhaul link (identifying the egress BH RLC channel based on matched entry, see Diao, paragraphs [41-53, 164-167], see AKL, paragraphs [111-113, 130-133, 167-169]).
Regarding claims 10 and 48, the combination of Sun, Diao and AKL further teaches wherein the backhaul RLC channel mapping information comprises a backhaul RLC channel mapping configuration table having at least one entry, each entry including:
a traffic type identifier field for indicating a traffic type of a data packet to be routed (traffic type, see Diao, paragraphs [63, 79-84, 125-130], see AKL, paragraphs [89, 102-103, 106, 114, 123]),
a next hop address field for a next hop address of a next IAB node that is next to the IAB node in a routing path (next hop BAP address, see Diao, paragraphs [41-53], see AKL, paragraph [103]),
an egress topology field for indicating the IAB topology associated with the next IAB node, and for indicating with the next hop address field an egress backhaul link between the IAB node and the next IAB node (topology for outputting, see AKL, paragraphs [100, 103, 111, 113]), and
an egress backhaul RLC channel identifier field for a backhaul RLC channel identifier of a backhaul RLC channel for the egress backhaul link (egress BH RLC channel ID, see Diao, paragraphs [41-53, 164-167], see AKL, paragraphs [88-89, 103]).
Regarding claims 11 and 49, the combination of Sun, Diao and AKL further teaches wherein receiving a data packet comprises generating the data packet in one part of the IAB node (receiving a data packet from upper layer of the IAB, see AKL, paragraphs [114-117]) and receiving, at another part of the IAB node, the data packet for routing to another IAB node (receiving a data packet for routing to another IAB node, see Sun, abstract, see Diao, paragraphs [105-108], see AKL, paragraph [137]), wherein selecting a backhaul RLC channel for the egress backhaul link comprises:
checking the backhaul RLC channel mapping configuration table to determine whether a traffic type of data in the received data packet, an address of the next IAB node and the IAB topology associated with the next IAB node match the respective fields of an entry in the backhaul RLC channel mapping configuration table (determining whether a traffic type of the received data packet, an address of next IAB node and topology match an entry in the table, see Diao, paragraphs [63, 79-84, 125-130], see AKL, paragraphs [89, 102-103, 106, 114, 123]); and
when a match with an entry is determined, using the egress backhaul RLC channel ID of the matched entry to select the backhaul RLC channel for the egress backhaul link (identifying the egress BH RLC channel based on matched entry, see Diao, paragraphs [63, 79-84, 125-130], see AKL, paragraphs [89, 102-103, 106, 114, 123]).
Regarding claim 12, the combination of Sun, Diao and AKL further teaches wherein the header rewriting configuration table has at least one entry (wherein the rewritten configuration table has at least one entry, see Sun, table 1) each entry of the header rewriting configuration table including:
a previous routing identifier field for a routing identifier (comprising an original routing ID field, see Sun, table 1);
a new routing identifier field for a routing identifier (comprising a rewritten routing ID field, see Sun, table 1); and
the field for indicating the IAB topology associated with the routing identifier in the new routing identifier field (wherein the field including the routing ID also including the topology associated with the routing ID, see AKL, paragraphs [92, 94, 100, 103, 105, 111]).
Regarding claim 14, the combination of Sun, Diao and AKL further teaches wherein the routing identifier of the received data packet includes a destination address of a destination IAB node for the data packet, wherein identifying a new routing identifier and the IAB topology associated with the next IAB node the data packet is to be routed comprises:
checking the header rewriting configuration table to determine whether the routing identifier of the received data packet matches a routing identifier in the previous routing identifier field of an entry (using the written table to determine whether the routing ID in the received data packet matches a routing ID in the original routing ID field, see Sun, paragraphs [214-217]) or whether a destination address of the routing identifier of the received data packet matches a destination address in the destination address field of an entry (using the written table to determine whether a destination address of the routing ID of the received data packet matches a destination address in the destination address field, see Sun, paragraphs [175-177, 214-215, 232-235]); and
when a match with an entry is determined, using the routing identifier in the new routing identifier field of the matched entry as the identified new routing identifier and using the IAB topology indicated by the new topology field of the matched entry as the identified IAB topology associated with the next IAB node (when a match is determined, using the routing identifier in the rewritten routing ID as the rewritten routing ID, see Sun, paragraphs [175-177, 214-215, 232-235], comprising the topology ID, see AKL, paragraphs [92, 94, 100, 103, 105, 111]).
Regarding claim 15, the combination of Sun, Diao and AKL further teaches wherein each topology field in the backhaul RLC channel mapping configuration table includes a topology identifier that uniquely identifies one of the at least two IAB topologies (backhaul RLC channel mapping configuration table includes topology ID for uniquely identifies one of the at least two IAB topologies, see Sun, paragraph [208], see AKL, abstract and paragraphs [52, 71-73, 93-95, 100-103]).
Regarding claim 17, the combination of Sun, Diao and AKL further teaches wherein the IAB node is a boundary node such that the IAB node is part of a first IAB topology of the at least two IAB topologies and is also connected to an IAB node of a second IAB topology of the at least two IAB topologies (wherein the IAB node is a boundary node that connected to at least two IAB topologies, see Sun, paragraphs [166, 176], see Diao, paragraphs [24, 159, 162]), wherein the IAB node has a first address associated with the first IAB topology and a second address associated with the second IAB topology (wherein the IAB node has a first address/routing ID associated with a first topology and a second address/routing ID associated with a second topology, see Sun, paragraphs [166, 175-177, 181, 184-186]), the method comprising:
identifying the IAB topology associated with the received data packet (identifying the topology associated with the received data packet, paragraphs [166, 184-186]);
determining whether a received data packet is to be delivered to upper layers of the IAB node by checking whether the destination address of the routing identifier matches one of the first or second addresses of the IAB node by comparing the destination address of the routing identifier with the one of the first or second addresses of the IAB node, wherein the one address of the first or second addresses of the IAB node used in the comparison is the address associated with the same topology as the topology associated with the received data packet (determining whether a received data packet is to delivered to an upper layer based on whether the destination address matches one of the addresses, see Sun, paragraphs [186, 190-195, 197-199]).
Regarding claim 18, the combination of Sun, Diao and AKL further teaches wherein receiving a data packet comprises receiving the data packet from a prior IAB node over an ingress backhaul link (receiving data packet from a prior IAB node over an ingress BH link, see Sun, paragraphs [172-175, 208, 212], see AKL, paragraphs [111, 113, 133, 134, 167, 169]), the method further comprising determining the IAB topology associated with the received data packet by determining the IAB topology associated with the ingress backhaul link (determining the IAB topology associated with the received packet based on the IAB topology associated with the ingress BH link, see Sun, paragraphs [172-175, 208, 212], see AKL, paragraphs [111, 113, 133, 134, 167, 169]).
Regarding claim 20, the combination of Sun, Diao and AKL further teaches receiving routing configuration information and information for the header rewriting configuration table information from a donor control unit, CU, of at least one of the at least two IAB topologies (receiving routing configuration and rewritten table from an CU of at least one of the two topologies, see Sun, paragraphs [166, 176], see Diao, paragraphs [105, 115, 118, 153, 159, 175], see AKL, paragraphs [87-88, 94, 100]).
Regarding claim 52, the combination of Sun, Diao and AKL further teaches wherein the topology field in the backhaul RLC channel mapping configuration table includes a topology identifier that uniquely identifies one of the at least two IAB topologies (backhaul RLC channel mapping configuration table includes topology ID for uniquely identifies one of the at least two IAB topologies, see Sun, paragraph [208], see AKL, abstract and paragraphs [52, 71-73, 93-95, 100-103]).
Regarding claim 53, the combination of Sun, Diao and AKL further teaches wherein the topology field in the header rewriting configuration table includes a topology identifier that uniquely identifies one of the at least two IAB topologies (topology ID for uniquely identifies one of the at least two IAB topologies, see Sun, paragraph [208], see AKL, abstract and paragraphs [52, 71-73, 93-95, 100-103]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 2024/0015633 A1 discloses a boundary IAB node receives a BAP packet and rewriting routing ID of the BAP packet based on a routing mapping relation configuration information when a predetermined condition is satisfied (See paragraphs [168-175]).
US 2022/0141749 A1 discloses IAB updates a route according to the routing information (paragraphs [85, 94, 123]).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DUNG B. HUYNH whose telephone number is (571)270-7642. The examiner can normally be reached M-F 9:00 AM - 6: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, Ian N. Moore can be reached at 571-272-3085. 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.
/DUNG B HUYNH/ Primary Examiner, Art Unit 2469 September 19, 2026
Prosecution Insights