DETAILED ACTION
Claims 1-4, 7-30, and 32 are pending. Claims 5, 6, and 31 have been cancelled. Claims 20-28 and 30 are withdrawn from consideration.
Election/Restrictions
Claims 20-28 and 30 are withdrawn from further consideration pursuant to 37 CFR 1.142(b) as being drawn to a nonelected invention (Group II, see Restriction Requirement mailed 2/20/2026), there being no allowable generic or linking claim. Election was made without traverse in the reply filed on 4/20/2026.
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 10/12/2023 was filed. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
The listing of references in the specification is not a proper information disclosure statement (see at least pg. 9, lines 3-8, pg. 13, line 34, pg. 14, line 11, ). 37 CFR 1.98(b) requires a list of all patents, publications, or other information submitted for consideration by the Office, and MPEP § 609.04(a) states, "the list may not be incorporated into the specification but must be submitted in a separate paper." Therefore, unless the references have been cited by the examiner on form PTO-892, they have not been considered.
Drawings
The drawings were received on 10/12/2023. These drawings are accepted.
Specification
The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant’s cooperation is requested in correcting any errors of which applicant may become aware in the specification.
Claim Objections
Claim 29 is objected to because of the following informalities: The claim should begin with “An”. Appropriate correction is required.
Claim Interpretation
MPEP § 2111.04(II) states in relevant part:
The broadest reasonable interpretation of a method (or process) claim having contingent limitations requires only those steps that must be performed and does not include steps that are not required to be performed because the condition(s) precedent are not met. For example, assume a method claim requires step A if a first condition happens and step B if a second condition happens. If the claimed invention may be practiced without either the first or second condition happening, then neither step A or B is required by the broadest reasonable interpretation of the claim. If the claimed invention requires the first condition to occur, then the broadest reasonable interpretation of the claim requires step A. If the claimed invention requires both the first and second conditions to occur, then the broadest reasonable interpretation of the claim requires both steps A and B.
…
See Ex parte Schulhauser, Appeal 2013-007847 (PTAB April 28, 2016) for an analysis of contingent claim limitations in the context of both method claims and system claims. In Schulhauser, both method claims and system claims recited the same contingent step. When analyzing the claimed method as a whole, the PTAB determined that giving the claim its broadest reasonable interpretation, "[i]f the condition for performing a contingent step is not satisfied, the performance recited by the step need not be carried out in order for the claimed method to be performed" (quotation omitted). Schulhauser at 10.
…
Therefore "[t]he Examiner did not need to present evidence of the obviousness of the [ ] method steps of claim 1 that are not required to be performed under a broadest reasonable interpretation of the claim (e.g., instances in which the electrocardiac signal data is not within the threshold electrocardiac criteria such that the condition precedent for the determining step and the remaining steps of claim 1 has not been met);" however to render the claimed system obvious, the prior art must teach the structure that performs the function of the contingent step along with the other recited claim limitations. Schulhauser at 9, 14.
Independent claim 1 recites a method. In accordance with MPEP § 2111.04(II), conditional limitations within method claims will be treated as not being required to be performed under the BRI.
As per independent claim 1, the claim recites, “in response to determining that the routing path of the received data packet includes at least one IAB node of a different IAB network, using the path identifier of the received data packet to determine whether there is a next IAB node in the routing path for routing the data packet,
when a next IAB node is determined, routing the data packet to the next IAB node,
wherein determining whether there is a next IAB node for routing the data packet using the path identifier of the received data packet comprises comparing the path identifier of the received data packet with a path identifier field of a routing configuration table,
when the path identifier of the received data packet matches a path identifier in a path identifier field of an entry in the routing configuration table and when an address assigned to the IAB node does not match the address of the IAB node in a destination address field of the entry, determining there is a next IAB node,
when the path identifier of the received data packet matches a path identifier in the path identifier field of an entry in the routing configuration table and when the destination address of the received data packet matches the address of the IAB node and the address in the destination address field of the entry, determining there is not a next IAB node and the IAB node is the destination IAB node.” The examiner notes that the cited limitations rely on the terms “whether” and “when”, where the definition (and BRI) of these terms includes “if”, which is considered conditional. In other words, the determination step may conclude that a collision does not exist, which would conclude the operation of the claim. Therefore, the examiner considers the BRI of independent claim 1 to include a scenario where the determining and routing limitations are not performed, as the conditions before the limitation are optional.
Dependent claims 2-4 and 7-19 inherit the same issue. Any limitations further defining the determining and routing steps are considered to be optional under the BRI as well.
As per dependent claims 2-4 and 7-16, the claims recite additional features coupled with “when” and/or “whether” followed by a condition. The BRI of the terms “when” and “whether” includes “if”, which is considered conditional. Therefore, the examiner considers the BRI of dependent claims 2-4 and 7-16 to include the limitations not being performed.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim 32 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because the claimed invention is directed to non-statutory subject matter. The claims are directed toward a computer-readable storage medium, which according to the broadest reasonable interpretation, is defined as being a carrier or the like. The broadest reasonable interpretation of a claim drawn to a computer readable medium (also called machine readable medium and other such variations) typically covers forms of non-transitory tangible media (or non-transitory media) and transitory propagating signals per se in view of the ordinary and customary meaning of computer readable media, particularly when the specification is silent (or absent of a controlling definition in the specification). See MPEP §2111.01. When the broadest reasonable interpretation of a claim covers a signal per se, the claim must be rejected under 35 U.S.C. § 101 as covering non-statutory subject matter. See MPEP 2106.03(I) and Nuijten, 500 F.3d at 1356-1357, 84 USPQ2d at 1501-03.
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.
Claims 1-4 and 7-19 are rejected under 35 U.S.C. 103 as being unpatentable over Zhuo et al. (US PB Pub 2022/0174579) in view of Samsung (R3-210218, NPL cited on IDS dated 10/12/2023).
As per claim 1, Zhuo et al. teach a method for processing data packets at an integrated access and backhaul, IAB, node of an IAB network comprising a plurality of IAB nodes [Zhuo, figs. 3 and 6, ¶s 0147, 1049, The routing (or packet processing) method is performed by an IAB node.], the method comprising:
receiving a data packet [Zhuo, fig. 6, step s601, ¶ 0148, “S601: A first node receives a data packet”, The IAB node receives a packet including a BAP header (see also ¶s 0149 and 0150).] including a destination address of a destination IAB node for the data packet and a path identifier identifying a routing path for the data packet to the destination IAB node [Zhuo, ¶ 0132, “For example, as shown in FIG. 5A, a BAP header includes a BAP address of a destination node (a BAP ID of the destination node in FIG. 5A) and a routing path identifier of a data packet”, The data packet includes a BAP header, which further includes a BAP ID of a destination node and a path identifier (see fig. 5A, and ¶ 0151).].
Zhou et al. do not explicitly teach determining, based on the received data packet, whether the routing path of the received data packet includes at least one IAB node of a different IAB network; in response to determining that the routing path of the received data packet includes at least one IAB node of a different IAB network, using the path identifier of the received data packet to determine whether there is a next IAB node in the routing path for routing the data packet, when a next IAB node is determined, routing the data packet to the next IAB node,wherein determining whether there is a next IAB node for routing the data packet using the path identifier of the received data packet comprises comparing the path identifier of the received data packet with a path identifier field of a routing configuration table, when the path identifier of the received data packet matches a path identifier in a path identifier field of an entry in the routing configuration table and when an address assigned to the IAB node does not match the address of the IAB node in a destination address field of the entry, determining there is a next IAB node, when the path identifier of the received data packet matches a path identifier in the path identifier field of an entry in the routing configuration table and when the destination address of the received data packet matches the address of the IAB node and the address in the destination address field of the entry, determining there is not a next IAB node and the IAB node is the destination IAB node.
However, in an analogous art, Samsung teaches determining, based on the received data packet, whether the routing path of the received data packet includes at least one IAB node of a different IAB network [Samsung, section 2.2, pg. 3, “Traffic transmission across topology”, “In inter-donor topology, the F1-C/F1-U traffic may be transmitted across two topologies controlled by two different donor CUs, i.e., for UL, the traffic from the boundary node and the descendant nodes may be split to two different parent nodes, while for DL, the traffic from the master donor CU will be split to two different donor DUs (one of them belonging to secondary donor CU) , and then be converged to the boundary IAB node and further towards the descendant nodes. Thus, the boundary IAB node should be able to 1) identify the traffic from two parent nodes and route them to the right descendant nodes, and 2) differentiate the traffic from the descendant node(s) and route them to different parent nodes”, Boundary IAB nodes receive packets that are forwarded to descendent nodes across different topologies according to their paths (see fig. 1(a) and 1(b), pg. 4.).];
in response to determining that the routing path of the received data packet includes at least one IAB node of a different IAB network [Samsung, section 2.2, pg. 3, Category 1, Option 1, “Option 1 (BAP address coordination between two donor CUs): this method needs split the whole BAP address space to two parts, each of which is used by one donor CU. Moreover, the boundary IAB node/each descendant IAB node have to be assigned two different BAP addressed belonging to two topologies, respectively. Apparently, this option will limit the number of IAB nodes connecting to each topology. Moreover, how to split the BAP address space between two donors is a headache issue. The inappropriate split would result in unnecessary limitation for the capacity of one topology”, The boundary IAB nodes perform coordination to forward the packets across different topologies corresponding to different donor CUs.], using the path identifier of the received data packet to determine whether there is a next IAB node in the routing path for routing the data packet [Samsung, section 2.2, pg. 3, Category 1, “In this category, the packets received by the boundary IAB node should contain the unique information so that it can help the packet routing in both DL and UL. In Rel-16, the packet routing is based on the BAP routing ID contains each BAP packets, which is comprised of destination BAP address and the path ID. The BAP address and path ID can be unique only in the topology controlled by same donor CU. For inter-donor topology redundancy, such uniqueness becomes difficult since the traffic routed by the boundary IAB node belonging two different topologies. For example, the same BAP routing ID (e.g., 10) may be targeting at IAB node 1 in topology 1, while targeting at IAB node 10 in topology 2. Thus, the methods in this category aim at assigning unique information in the BAP packets”, The header contains a routing path ID, which is used by the boundary node to determine the routing path for the packet (see fig. 1(a) and 1(b).],
when a next IAB node is determined, routing the data packet to the next IAB node [Samsung, section 2.2, pg. 3, “Traffic transmission across topology”, “In inter-donor topology, the F1-C/F1-U traffic may be transmitted across two topologies controlled by two different donor CUs, i.e., for UL, the traffic from the boundary node and the descendant nodes may be split to two different parent nodes, while for DL, the traffic from the master donor CU will be split to two different donor DUs (one of them belonging to secondary donor CU) , and then be converged to the boundary IAB node and further towards the descendant nodes. Thus, the boundary IAB node should be able to 1) identify the traffic from two parent nodes and route them to the right descendant nodes, and 2) differentiate the traffic from the descendant node(s) and route them to different parent nodes”, The boundary node forwards (or routes) packets to the next (or descendent) node.].
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the IAB routing across different topologies as taught by Samsung into Zhuo et al. One would have been motivated to do this because implementing introducing redundancy across IAB networks allows for load balancing and robustness (see Samsung, section 2.2, F1 termination point boundary IAB and its descendent node(s)) with a reasonable expectation of success.
Examiner Note: The following limitations are considered optional under the BRI, see “Claim Interpretation” section, above.
wherein determining whether there is a next IAB node for routing the data packet using the path identifier of the received data packet comprises comparing the path identifier of the received data packet with a path identifier field of a routing configuration table,
when the path identifier of the received data packet matches a path identifier in a path identifier field of an entry in the routing configuration table and when an address assigned to the IAB node does not match the address of the IAB node in a destination address field of the entry, determining there is a next IAB node,
when the path identifier of the received data packet matches a path identifier in the path identifier field of an entry in the routing configuration table and when the destination address of the received data packet matches the address of the IAB node and the address in the destination address field of the entry, determining there is not a next IAB node and the IAB node is the destination IAB node.
As per claim 2, Zhuo et al. in view of Samsung teach the method of claim 1. Zhuo et al. do not explicitly teach wherein the destination address of the received data packet is not used to determine whether there is a next IAB node for routing the data packet.
However, in an analogous art, Samsung teaches wherein the destination address of the received data packet is not used to determine whether there is a next IAB node for routing the data packet [Samsung, section 2.2, pg. 3, Category 1, “For inter-donor topology redundancy, such uniqueness becomes difficult since the traffic routed by the boundary IAB node belonging two different topologies. For example, the same BAP routing ID (e.g., 10) may be targeting at IAB node 1 in topology 1, while targeting at IAB node 10 in topology 2”, The BAP routing ID is used to target (or determine) a destination node.].
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the IAB routing across different topologies as taught by Samsung into Zhuo et al. One would have been motivated to do this because implementing introducing redundancy across IAB networks allows for load balancing and robustness (see Samsung, section 2.2, F1 termination point boundary IAB and its descendent node(s)) with a reasonable expectation of success.
As per claim 3, Zhuo et al. in view of Samsung teach the method of claim 1. Zhuo et al. also teach further comprising receiving configuration information for providing the routing configuration table, each entry of the routing configuration table having 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 [Zhuo, ¶ 0105, “Manner 2: The first path is a routing path with a highest priority in at least one routing path between the first node and the destination node in a routing table of the first node. Routing table information of the first node is configured by the donor CU for the first node”, Within the IAB network (see fig. 3), the donor node configures the routing tables of the intermediary IAB nodes. The routing table is configured to accommodate information within the BAP headers received.].
As per claim 4, Zhuo et al. in view of Samsung teach the method of claim 3. As noted in the “Claim Interpretation” section, above, the following features of this claim are considered optional under the BRI.
wherein when the path identifier of the received data packet does not match a path identifier in the path identifier field, determining there is not a next IAB node, wherein the method further comprises comparing the destination address of the received data packet with an address assigned to the IAB node, and when the destination address of the received data packet matches the address assigned to the IAB node, determining the IAB node is the destination IAB node.
As per claim 7, Zhou et al. in view of Samsung teach the method of claim 1. As noted in the “Claim Interpretation” section, above, the following features of this claim are considered optional under the BRI.
wherein determining whether the routing path of the received data packet includes at least one IAB node of a different IAB network comprises determining, based on the path identifier of the received data packet, whether the routing path of the received data packet includes at least one IAB node of a different IAB network.
As per claim 8, Zhou et al. in view of Samsung teach the method of claim 7. Zhuo et al. also teach wherein one or more path identifier values of a plurality of path identifier values are assigned to represent one or more transit path identifiers [Zhuo, ¶ 0105, “Manner 2: The first path is a routing path with a highest priority in at least one routing path between the first node and the destination node in a routing table of the first node. Routing table information of the first node is configured by the donor CU for the first node”, Within the IAB network (see fig. 3), the donor node configures the routing tables of the intermediary IAB nodes. The routing table is configured to accommodate information within the BAP headers received.], each one of the one or more path identifier values representing a respective transit path identifier identifying a transit path [Zhuo, ¶ 0132, “For example, as shown in FIG. 5A, a BAP header includes a BAP address of a destination node (a BAP ID of the destination node in FIG. 5A) and a routing path identifier of a data packet”, The data packet includes a BAP header, which further includes a BAP ID of a destination node and a path identifier (see fig. 5A, and ¶ 0151).], wherein a transit path is a routing path including at least one IAB node of a different IAB network [Zhuo, ¶ 0113, “Optionally, a routing path identifier of the first path may include ID information of all IAB nodes on the first path; or a routing path identifier of the first path may be in a form of an index, and the donor CU needs to configure an association relationship between the index and the routing path. N path identifiers correspond to N routing paths between a same access IAB node and a same destination node. Routing paths between different access IAB nodes and different destination nodes may reuse a same routing path identifier. Alternatively, each routing path has a routing path identifier that is unique in an entire network or in a CU”, The routing path identifier is assigned by the donor CU. The routing path identifier denotes the path that a packet takes across the IAB topology (see fig. 3). See also ¶s 0134-0136.].
As per claim 9, Zhou et al. in view of Samsung teach the method of claim 8. Zhuo et al. also teach further comprising: receiving, from a donor Central Unit of the IAB network [Zhuo, ¶ 0113, “Optionally, a routing path identifier of the first path may include ID information of all IAB nodes on the first path; or a routing path identifier of the first path may be in a form of an index, and the donor CU needs to configure an association relationship between the index and the routing path. N path identifiers correspond to N routing paths between a same access IAB node and a same destination node. Routing paths between different access IAB nodes and different destination nodes may reuse a same routing path identifier. Alternatively, each routing path has a routing path identifier that is unique in an entire network or in a CU”, The routing path identifier is assigned by the donor CU. The routing path identifier denotes the path that a packet takes across the IAB topology (see fig. 3). See also ¶s 0134-0136.], routing configuration information indicating the one or more path identifier values assigned to the one or more transit path identifiers [Zhuo, ¶ 0105, “Manner 2: The first path is a routing path with a highest priority in at least one routing path between the first node and the destination node in a routing table of the first node. Routing table information of the first node is configured by the donor CU for the first node”, Within the IAB network (see fig. 3), the donor node configures the routing tables of the intermediary IAB nodes. The routing table is configured to accommodate information within the BAP headers received.].
As per claim 11, Zhou et al. in view of Samsung teach the method of claim 10. Zhuo et al. do not explicitly teach wherein each entry of the transit table further includes a target IAB information field for indicating whether the destination IAB node for a data packet routed using the transit path identified by the transit path identifier in the transit path identifier field of the entry is in the IAB network of the IAB node or if the destination IAB node is part of a different IAB network.
However, in an analogous art, Samsung teaches wherein each entry of the transit table further includes a target IAB information field for indicating whether the destination IAB node for a data packet routed using the transit path identified by the transit path identifier in the transit path identifier field of the entry is in the IAB network of the IAB node or if the destination IAB node is part of a different IAB network [Samsung, section 2.2, pg. 3, Traffic transmission across topology, Option 2, “Option 2 (a new unique identity, e.g., BAP routing ID + topology ID): this option extends the legacy BAP address by including the topology ID. Such topology ID should ensure the uniqueness of BAP address across multiple topologies, which can be gNB ID. However, the resultant issue is the variable length of gNB ID (22 ~ 32bits) and the additional overhead of each BAP packet”, The header of the packet may alternatively include a BAP routing ID (or path identifier) and a topology ID, which indicates a different IAB network. This creates a unique address for the separate topology and creates a unique header for routing. The routing/transit table may be updated to accommodate and operate according to Option 2 header information.].
As per claim 13, Zhou et al. in view of Samsung teach the method of claim 3. Zhuo et al. do not explicitly teach wherein each entry of the routing configuration table further includes a transit path field for indicating whether the path identifier in the path identifier field is a transit path identifier identifying a transit path, wherein a transit path is a routing path including at least one IAB node of a different IAB network.
However, in an analogous art, Samsung teaches wherein each entry of the routing configuration table further includes a transit path field for indicating whether the path identifier in the path identifier field is a transit path identifier identifying a transit path, wherein a transit path is a routing path including at least one IAB node of a different IAB network [Samsung, section 2.2, pg. 3, Traffic transmission across topology, Option 2, “Option 2 (a new unique identity, e.g., BAP routing ID + topology ID): this option extends the legacy BAP address by including the topology ID. Such topology ID should ensure the uniqueness of BAP address across multiple topologies, which can be gNB ID. However, the resultant issue is the variable length of gNB ID (22 ~ 32bits) and the additional overhead of each BAP packet”, The header of the packet may alternatively include a BAP routing ID (or path identifier) and a topology ID, which indicates a different IAB network. This creates a unique address for the separate topology and creates a unique header for routing. The routing/transit table may be updated to accommodate and operate according to Option 2 header information.].
As per claim 15, Zhou et al. in view of Samsung teach the method of claim 1. Zhuo et al. do not explicitly teach wherein the data packet comprises a header including the path identifier and at least one bit configured to indicate whether the path identifier of the data packet is a transit path identifier identifying a transit path, wherein a transit path is a routing path including at least one IAB node of a different IAB network.
However, in an analogous art, Samsung teaches wherein the data packet comprises a header including the path identifier and at least one bit configured to indicate whether the path identifier of the data packet is a transit path identifier identifying a transit path, wherein a transit path is a routing path including at least one IAB node of a different IAB network [Samsung, section 2.2, pg. 3, Traffic transmission across topology, Option 2, “Option 2 (a new unique identity, e.g., BAP routing ID + topology ID): this option extends the legacy BAP address by including the topology ID. Such topology ID should ensure the uniqueness of BAP address across multiple topologies, which can be gNB ID. However, the resultant issue is the variable length of gNB ID (22 ~ 32bits) and the additional overhead of each BAP packet”, The header of the packet may alternatively include a BAP routing ID (or path identifier) and a topology ID, which indicates a different IAB network. This creates a unique address for the separate topology and creates a unique header for routing.].
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the IAB routing across different topologies as taught by Samsung into Zhuo et al. One would have been motivated to do this because implementing introducing redundancy across IAB networks allows for load balancing and robustness (see Samsung, section 2.2, F1 termination point boundary IAB and its descendent node(s)) with a reasonable expectation of success.
As per claim 17, Zhou et al. in view of Samsung teach the method of claim 1. Zhuo et al. do not explicitly teach wherein the IAB node is capable of routing data packets to one or more IAB nodes in the IAB network of the IAB node and to one or more IAB nodes in at least one different IAB network.
However, in an analogous art, Samsung teaches wherein the IAB node is capable of routing data packets to one or more IAB nodes in the IAB network of the IAB node and to one or more IAB nodes in at least one different IAB network [Samsung, section 2.2, pg. 3, “Traffic transmission across topology”, “In inter-donor topology, the F1-C/F1-U traffic may be transmitted across two topologies controlled by two different donor CUs, i.e., for UL, the traffic from the boundary node and the descendant nodes may be split to two different parent nodes, while for DL, the traffic from the master donor CU will be split to two different donor DUs (one of them belonging to secondary donor CU) , and then be converged to the boundary IAB node and further towards the descendant nodes. Thus, the boundary IAB node should be able to 1) identify the traffic from two parent nodes and route them to the right descendant nodes, and 2) differentiate the traffic from the descendant node(s) and route them to different parent nodes”, Boundary IAB nodes receive packets that are forwarded to descendent nodes across different topologies according to their paths (see fig. 1(a) and 1(b), pg. 4.).].
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the IAB routing across different topologies as taught by Samsung into Zhuo et al. One would have been motivated to do this because implementing introducing redundancy across IAB networks allows for load balancing and robustness (see Samsung, section 2.2, F1 termination point boundary IAB and its descendent node(s)) with a reasonable expectation of success.
As per claim 18, Zhou et al. in view of Samsung teach the method of claim 17. Zhuo et al. do not explicitly teach wherein the IAB node is capable of routing data packets to one or more IAB nodes in the IAB network of the IAB node and to one or more IAB nodes in at least one different IAB network.
However, in an analogous art, Samsung teaches wherein the IAB node is capable of routing data packets to one or more IAB nodes in the IAB network of the IAB node and to one or more IAB nodes in at least one different IAB network [Samsung, section 2.2, pg. 3, Traffic transmission across topology, Option 2, “Option 2 (a new unique identity, e.g., BAP routing ID + topology ID): this option extends the legacy BAP address by including the topology ID. Such topology ID should ensure the uniqueness of BAP address across multiple topologies, which can be gNB ID. However, the resultant issue is the variable length of gNB ID (22 ~ 32bits) and the additional overhead of each BAP packet”, The header of the packet may alternatively include a BAP routing ID (or path identifier) and a topology ID, which indicates a different IAB network. This creates a unique address for the separate topology and creates a unique header for routing.].
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the IAB routing across different topologies as taught by Samsung into Zhuo et al. One would have been motivated to do this because implementing introducing redundancy across IAB networks allows for load balancing and robustness (see Samsung, section 2.2, F1 termination point boundary IAB and its descendent node(s)) with a reasonable expectation of success.
As per claim 19, Zhou et al. in view of Samsung teach the method of claim 17, further comprising sending a notification to a donor Central Unit, CU, of the IAB network, indicating the IAB node is capable of routing data packets to one or more IAB nodes in the at least one different IAB network.
However, in an analogous art, Samsung teaches sending a notification to a donor Central Unit, CU, of the IAB network, indicating the IAB node is capable of routing data packets to one or more IAB nodes in the at least one different IAB network [Samsung, section 2.2, F1 termination point boundary IAB and its descendent node(s), “Terminating the F1 interface to different nodes cannot bring any additional benefit for our intention, except increasing the complexity on the resource and configuration coordination between two donor nodes. Moreover, the topology redundancy establishment is triggered whenever the network load needs some offloading, i.e., the donor node wants to add SN for the boundary IAB node in order to offload traffic. In other words, before starting inter-donor topology redundancy, the boundary IAB node already establishes the F1 interface with MN. If the termination point is changed from MN to SN, the inter-donor migration procedure should be performed first, which can be considered as a redundant operation”, The F1 interface is used to facilitate communications between the boundary IAB and MN. Load balancing may be setup, presumably if a boundary IAB is capable.]
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the IAB routing across different topologies as taught by Samsung into Zhuo et al. One would have been motivated to do this because implementing introducing redundancy across IAB networks allows for load balancing and robustness (see Samsung, section 2.2, F1 termination point boundary IAB and its descendent node(s)) with a reasonable expectation of success.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the IAB routing across different topologies as taught by Samsung into Zhuo et al. One would have been motivated to do this because implementing introducing redundancy across IAB networks allows for load balancing and robustness (see Samsung, section 2.2, F1 termination point boundary IAB and its descendent node(s)) with a reasonable expectation of success.
Allowable Subject Matter
Claims 29 is allowed.
The following is a statement of reasons for the indication of allowable subject matter:
Independent claim 29 recites an apparatus. As noted in the “Claim Interpretation” section of the Office Action, contingent limitations are only optional under the BRI of method claims. Since claim 29 is an apparatus claim, all features are required under the BRI. The cited prior art fails to teach or render obvious the claim in its entirety.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
The reference, Madapatha et al. (NPL), teaches Integrated Access Backhaul in 3GPP (see section II).
The reference, Nokia (R3-210489), teaches routing ID and address collision in IAB (see section 2.3).
The reference, LG (R3-210536), teaches load balancing in IAB (see section 2).
The reference, Lenovo (R3-210615), teaches inter-donor topology redundancy in IAB (see fig. 1).
The reference, ZTE (R3-210717), teaches inter-donor redundancy in IAB (see section 2.2).
The reference, Yi et al. (US PG Pub 20240015633), teaches an IAB boundary node serving different topologies (see at least figs. 3 and 4).
The reference, Zhu et al. (US PG Pub 20230362779), teaches an IAB boundary node supporting different “legs” (see fig. 7(a)).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Paul H. Masur whose telephone number is (571)270-7297. The examiner can normally be reached Monday to Friday, 4:30 AM to 5PM.
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, Rebecca Song can be reached at (571) 270-3667. 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.
/Paul H. Masur/
Primary Examiner
Art Unit 2417