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 .
Status of the Claims
The office action is in response to the claim amendments and remarks filed on March 27, 2026 for the application filed January 12, 2023. Claims 5, 6, 21, and 22 have been amended; claims 13 and 28 have been canceled. Claims 5-8, 10, 21-25, and 29-32 are currently pending.
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.
Claims 5, 6, 7, 8, 10, 21, 22, 23, 24, 25 are rejected under 35 U.S.C. 103 as being unpatentable over Barac et al. (US2023/0239754A1), in view of Teyeb et al. (US2023/0239755A1), Hong (WO2021/187933A1), and Barac et al. (US2023/0232285A1) hereinafter Barac2.
Regarding claim 5, Barac teaches an information transmission method comprising: sending, by a first donor Centralized Unit (CU), a mobility related request message to a second donor CU, wherein the mobility related request comprises: (Paragraph [0172]: FIG. 9 is a combined signalling scheme and flowchart depicting some embodiments herein wherein the first radio network node 12 is exemplified as a first IAB-donor CU and the second radio network node 15 is exemplified as a second IAB-donor CU. Paragraph [0173]: Action 901. The first radio network node 12 may decide to handover a migrating node such as an IAB node, for example, the second intermediate radio network node 14, to the second radio network node 15 or a plurality of nodes such as radio network nodes and/or UEs. This may be decided based on measurements, load conditions of the different radio network nodes, mobility or configured. The cause may be e.g. RLF, load balancing, and/or IAB node mobility. Paragraph [0174]: Action 902. The first radio network node 12 may transmit, for example, a message such as a handover request to the second radio network node 15, wherein the handover request comprises data, being an indication, associated with the migrating node e.g. IAB node and data related to one or more other nodes, such as IAB nodes and/or UEs, directly and indirectly served by the migrating node. The data may indicate one or more resources required to serve the migrating node and/or one or more other nodes. Paragraph [0181]: Action 1003. The first radio network node 12 may transmit to the second radio network node 15, the message related to the handover or the cell reselection of the migrating node to the second radio network node 15, wherein the message comprises data associated with the migrating node, and data related to the one or more other nodes, directly and indirectly served by the migrating node. The message may be a handover request to the second radio network node 15, wherein the handover request comprises data, or an indication of resources needed for being served, signalling requirements etc., associated with the migrating node, e.g. IAB node, and data related to other nodes, such as IAB nodes and/or UEs, directly and indirectly served by the migrating node i.e. plurality of nodes. The data may indicate one or more resources required to serve the migrating node and/or the other nodes. The transmitted message may comprise a HANDOVER REQUEST message.)
a BH RLC Channel configuration for an integrated access and backhaul distributed unit (IAB-DU) configured by the first donor CU including a BH RLC Channel ID (Paragraph [0019]: As shown, the chosen protocol stacks reuse the current CU-DU split specification in rel-15, where the full user plane F1-U (GTP-U/UDP/IP) is terminated at the IAB node (like a normal DU) and the full control plane F1-C (F1-AP/SCTP/IP) is also terminated at the IAB node (like a normal DU). In the above cases, Network Domain Security (NDS) has been employed to protect both UP and CP traffic (IPsec in the case of UP, and datagram transport layer security (DTLS) in the case of CP). IPsec could also be used for the CP protection instead of DTLS (in this case no DTLS layer would be used). Paragraph [0020]: A new protocol layer called Backhaul Adaptation Protocol (BAP) has been introduced in the IAB nodes and the IAB donor, which is used for routing of packets to the appropriate downstream/upstream node and also mapping the UE bearer data to the proper backhaul radio link control (RLC) channel, and also between ingress and egress backhaul RLC channels in intermediate IAB nodes, to satisfy the end-to-end quality of service (QoS) requirements of bearers. Paragraph [0022]: FIG. 4 shows one example of the functional view of the BAP sublayer. This functional view should not restrict implementation. The FIG. 4 is based on the radio interface protocol architecture defined in TS 38.300 v16.1.0. In the example of FIG. 4 , the receiving part on the BAP entity delivers BAP Protocol data units (PDU) to the transmitting part on the collocated BAP entity. Alternatively, the receiving part may deliver BAP service data units (SDU) to the collocated transmitting part. When passing BAP SDUs, the receiving part removes the BAP header and the transmitting part adds the BAP header with the same BAP routing ID as carried on the BAP PDU header prior to removal. Passing BAP SDUs in this manner is therefore functionally equivalent to passing BAP PDUs, in implementation. Paragraph [0058]: Action 15. The IAB-donor-CU releases BH RLC channels and BAP routing entries on the source path. The migrating IAB-node may further release the TNL address(es) it used on the source path. Paragraph [0114]: Mechanisms shown on how the information and/or contexts of the migrating IAB node and of all the UEs and IAB nodes that are directly or indirectly served by the migrating IAB node are transferred to the target CU are provided, which target-CU uses the received information to perform proper admission control. The target CU-CP will respond to the HANDOVER REQUEST with a HANDOVER REQUEST ACK that will indicate the list of admitted and non-admitted PDU session and BH RLC channel resources, for each concerned UE/IAB node included in the handover request. The PDU session is essentially a set of the QoS flows that were associated with each UE/IAB-MT. Paragraph [0201]: For example, the second radio network node 15 may perform admission control for the UEs and IAB nodes included in the handover request. Performing admission control for the UEs and IAB nodes included in the handover request, may consider: Paragraph [0202]: The CP resources required to admit/handle the indicated UEs and IABs and their CP connections at the target network node. Paragraph [0203]: The UP resources required to serve the migrating IAB-nodes and UEs (DRBs, QoS flows, PDU sessions, backhaul (BH) RLC channels).)
configuration information of an IAB-DU, and routing configuration for the IAB-DU configured by the first donor CU (Paragraph [0021]: On the IAB-node, the BAP sublayer contains one BAP entity at the MT function and a separate collocated BAP entity at the DU function. On the IAB-donor-DU, the BAP sublayer contains only one BAP entity. Each BAP entity has a transmitting part and a receiving part. The transmitting part of the BAP entity has a corresponding receiving part of a BAP entity at the IAB-node or IAB-donor-DU across the backhaul link. Paragraph [0022]: FIG. 4 shows one example of the functional view of the BAP sublayer. This functional view should not restrict implementation. The FIG. 4 is based on the radio interface protocol architecture defined in TS 38.300 v16.1.0. In the example of FIG. 4 , the receiving part on the BAP entity delivers BAP Protocol data units (PDU) to the transmitting part on the collocated BAP entity. Alternatively, the receiving part may deliver BAP service data units (SDU) to the collocated transmitting part. When passing BAP SDUs, the receiving part removes the BAP header and the transmitting part adds the BAP header with the same BAP routing ID as carried on the BAP PDU header prior to removal. Passing BAP SDUs in this manner is therefore functionally equivalent to passing BAP PDUs, in implementation. Paragraph [0054]: Action 11. The IAB-donor-CU configures BH RLC channels and BAP-layer route entries on the target path between migrating IAB-node and target IAB-donor-DU. This step also includes allocation of transport network layer (TNL) address(es) that is (are) routable via the target IAB-donor-DU. These configurations may be performed at an earlier stage, e.g. right after action 3. The new TNL address(es) is (are) included in the RRCReconfiguration message at action 5. Paragraph [0058]: Action 15. The IAB-donor-CU releases BH RLC channels and BAP routing entries on the source path. The migrating IAB-node may further release the TNL address(es) it used on the source path. Paragraph [0064]: Based on implementation, these actions can be performed after or in parallel with the handover of the migrating IAB-node.)
and receiving at the first donor CU, a mobility related ACK message from the second donor CU (Paragraph [0182]: Action 1004. The first radio network node 12 receives from the second radio network node 15, the indication indicating whether handover or cell reselection to the second radio network node 15 is confirmed or not, wherein the indication indicates whether the migrating node 15 and/or the one or more other nodes, directly and indirectly served by the migrating node 15, are accepted or cancelled for handover or cell reselection to the second radio network node 15. The indication may indicate whether one or more nodes are accepted or cancelled for Handover (HO) to the second radio network node 15. The received indication may be comprised in a HANDOVER REQUEST ACKNOWLEDGE message. Thus, the first radio network node 12 may receive a HANDOVER REQUEST ACKNOWLEDGE message, such as an enhanced Xn HANDOVER REQUEST ACKNOWLEDGE message or a newly defined message, being an example of the received indication.);
Barac does not explicitly teach configuration information of an IAB-DU that includes an IP address request information; wherein the mobility related ACK message comprises IP address information allocated for an IAB-DU, a routing configuration information configured by the second donor CU, and a traffic mapping configuration information configured by the second donor CU, wherein the IP address information comprises: an IP address, or an IP address prefix, or an IP address usage, or an IAB donor DU BAP address.
However, Teyeb teaches wherein the mobility related ACK message comprises IP address information allocated for an IAB-DU, wherein the IP address information comprises: an IP address (Paragraph [0095]: In a particular embodiment, the source donor CU provides the target donor CU with information about the distributed unit (DU) of the migrating IAB node (e.g., served cells, transport layer addresses, etc.), and the target donor CU uses the information to respond with the F1-setup response message to the DU of the IAB node. Paragraph [0105]: According to some embodiments, a network node is capable of operating as an IAB donor. The IAB donor performs a method comprising receiving a handover request for an IAB node from a source IAB donor. The handover request comprises configuration information for establishing an interface between the IAB node DU and the IAB donor CU. The method further comprises, after a handover of the IAB node to the IAB donor, establishing the interface between the IAB node DU and the IAB donor CU based on the received configuration information. Paragraph [0106]: In particular embodiments, the interface comprises an F1 interface and the configuration information comprises a transport layer address of the IAB node. Paragraph [0147]: The terms “transport layer information”, “transport layer address” and “IP address” are used interchangeably. Paragraph [0152]: Alternatively, the source CU may have the required information, or the target CU may provide it to the source CU in one of the following ways: 1) inside the HANDOVER REQUEST ACK message; Paragraph [0153]: The information may be provided to the IAB node prior to the migration procedure, where the IAB node is provided with a list (e.g., list of identities) of all the possible parent nodes (donor DUs or other IAB nodes), or/and the cells belonging to the parent nodes, along with the information to use for setting up F1 when the IAB node establishes a connection via one of these parent cells (e.g., transport layer address). Paragraph [0162]: FIG. 15 is a signaling diagram illustrating an example of the second group of embodiments. In the illustrated example, Donor CU1 sends a handover request to Donor CU2. The handover request includes information about the IAB node, such as its transport layer address. After the handover of IAB-MT to Donor CU2, Donor CU2 uses the information about the IAB node to send an F1 setup request to IAB-DU.)
a routing configuration information configured by the second donor CU (Paragraph [0095]: In a particular embodiment, the source donor CU provides the target donor CU with information about the distributed unit (DU) of the migrating IAB node (e.g., served cells, transport layer addresses, etc.), and the target donor CU uses the information to respond with the F1-setup response message to the DU of the IAB node. Paragraph [0105]: According to some embodiments, a network node is capable of operating as an IAB donor. The IAB donor performs a method comprising receiving a handover request for an IAB node from a source IAB donor. The handover request comprises configuration information for establishing an interface between the IAB node DU and the IAB donor CU. The method further comprises, after a handover of the IAB node to the IAB donor, establishing the interface between the IAB node DU and the IAB donor CU based on the received configuration information. Paragraph [0106]: In particular embodiments, the interface comprises an F1 interface and the configuration information comprises a transport layer address of the IAB node. Paragraph [0152]: Alternatively, the source CU may have the required information, or the target CU may provide it to the source CU in one of the following ways: 1) inside the HANDOVER REQUEST ACK message; Paragraph [0153]: The information may be provided to the IAB node prior to the migration procedure, where the IAB node is provided with a list (e.g., list of identities) of all the possible parent nodes (donor DUs or other IAB nodes), or/and the cells belonging to the parent nodes, along with the information to use for setting up F1 when the IAB node establishes a connection via one of these parent cells (e.g., transport layer address). Paragraph [0159]: Alternatively, the target CU may invoke the DU of the migrating node to start the F1 setup procedure with the target CU by, e.g., sending an indication to the migrating IAB-MT that triggers the collocated IAB-DU to start F1 setup (reusing the legacy F1 setup procedure). The indication may be sent to the IAB-MT by using an enhancement of an existing RRC message or a new message. The IAB node is provided with, e.g. the transport address, of the target donor CU in advance. This alternative is similar to the first group of embodiments, a difference being that in this case the triggering to send the F1-AP setup request is sent from the target CU, while in the first group of embodiments, the trigger is coming from the source CU. Paragraph [0162]: FIG. 15 is a signaling diagram illustrating an example of the second group of embodiments. In the illustrated example, Donor CU1 sends a handover request to Donor CU2. The handover request includes information about the IAB node, such as its transport layer address. After the handover of IAB-MT to Donor CU2, Donor CU2 uses the information about the IAB node to send an F1 setup request to IAB-DU. Paragraph [0167]: In the handover response message, the target includes the information that it normally provides as a response to an F1 setup request message (the information equivalent to F1 setup request was provided in a previous step).)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide wherein the mobility related ACK message comprises IP address information allocated for an IAB-DU, wherein the IP address information comprises: an IP address, a routing configuration information configured by the second donor CU, as taught by Teyeb in the system of Barac, so that after a handover, the interface between the IAB node DU and the IAB donor CU can be established based on the received configuration information, and the routing configuration provided by the second donor CU to the first donor CU can establish the interface between the IAB node DU and the IAB donor CU in parallel while sending the handover command (Teyeb: Paragraphs [0105], [0106], [0152], [0153], [0162]).
The combination of Barac and Teyeb does not explicitly teach configuration information of IAB-DU that includes an IP address request information.
However, Hong teaches configuration information of IAB-DU that includes an IP address request information (Page 14, Paragraph 4: For example, the handover request message includes Backhaul Adaptation Protocol (BAP) address information for the migration target IAB node, Backhaul Adaptation Protocol (BAP) routing ID information….and IAB DU ( It may include at least one of transport layer address request information for F1 transmission between the distributed unit) and the target IAB donor CU. Page 14, Paragraph 5: As another example, BAP (Backhaul Adaptation Protocol) address information for the migration target IAB node, ….and IAB DU (Distributed Unit) of the migration target IAB node and At least one piece of transport layer address request information for F1 transmission between the target IAB donor CUs may be received by being included as an information field in an RRC container (eg HandoverPreparationInformation message) in a handover request message. Page 16, Paragraph 8: 3. For example, the source IAB donor CU transmits a handover request message to the target IAB donor CU. Page 18, Paragraph 1: Accordingly, the handover request message (or the RRC container included in the handover request message) may additionally include information necessary to generate a configuration for the IAB DU (or IAB node). Page 18, Paragraph 2: It may include at least one of transport layer address request information for F1 transmission between (Distributed Unit) and the target IAB donor CU. Examiner’s note: Transport layer address indicates IP address. See Page 19, Paragraph 9; Page 20, Paragraph 1.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide configuration information of IAB-DU that includes an IP address request information, as taught by Hong in the combined system of Barac and Teyeb, so that the IAB-DU is provided with the IP address information for the handover (Hong: Page 14, Paragraphs 4-5, Page 16, Paragraph 8).
The combination of Barac, Teyeb, and Hong does not explicitly teach a traffic mapping configuration information configured by the second donor CU.
However, Barac2 teaches a traffic mapping configuration information configured by the second donor CU (Paragraph [0156]: Action 1005. The first radio network node 12 may then handle a handover process of the migrating node and/or the one or more other nodes based on the received indication, for example, handle handover of the migrating node based on the received indication. The first radio network node 12 may, for example, on determining the response message is a HANDOVER REQUEST ACKNOWLEDGE message (a modified version of the Xn HANDOVER REQUEST ACKNOWLEDGE message or a newly defined message for that purpose): Determine the admission level of the response message. Paragraph [0172]: The first radio network node 12 may be a source IAB donor central unit and the second radio network node 15 may be a target IAB donor central unit. Paragraph [0189]: the second radio network node 15 may perform admission control for the UEs and IAB nodes included in the handover request, and may consider one or more of the following: Paragraph [0191]: The UP resources required to serve the migrating IAB-nodes and UEs (DRBs, QoS flows, PDU sessions, backhaul (BH) RLC channels). Paragraph [0194]: The lower layer resources, i.e. radio resources, required to admit/handle the indicated UEs and IABs contexts at any intermediate IAB node between the target donor DU and the parent IAB node that the migrating IAB node is being handed over to, i.e. the backhaul links on each hop along the way. Paragraph [0195]: For example, the second radio network node 15 may transmit an indication wherein the indication indicates acceptance or not. The indication may further indicate one or more nodes that has been accepted or not. The transmitted indication may be comprised in a HANDOVER REQUEST ACKNOWLEDGE message. Paragraph [0197]: If the handover can be performed, the handover response message being the HANDOVER REQUEST ACKNOWLEDGE message. Paragraph [0198]: Including in the message the IAB-MT/UE/DU contexts that has been admitted (e.g. QoS flows/PDU sessions admitted). Paragraph [0215]: The handover response from the second radio network node 15 may comprise information pertaining to the migrating IAB-MT, including the list of admitted and the list of not admitted BH RLC channels and PDU sessions established towards the migrating IAB-MT's parent node. Also see paragraphs [0157] – [0165], [0190], [0192], [0193], [0216] – [0220], [0223])
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide a traffic mapping configuration information configured by the second donor CU, as taught by Barac2 in the combined system of Barac, Teyeb, and Hong, so that the QoS flows, PDU sessions, BH RLC channels information, and other information related to the migrating node can be included in the handover request message for a successful handover process (Barac2: Paragraphs [0156] – [0165], [0189] – [0195], [0197] – [0198], [0215] – [0220], [0223]).
Regarding claim 6, the combination of Barac, Teyeb, Hong, and Barac2 teaches the method according to claim 5 further comprising (see rejection for claim 5);
The combination of Barac, Teyeb, and Barac2 does not explicitly teach before sending the mobility related request message to the second donor CU, receiving a measurement report from a source parent node wherein the measurement report is included in a mobility related required message sent from the source parent node, and wherein the measurement report is associated with a measurement performed by a migrating IAB node.
However, Hong teaches before sending the mobility related request message to the second donor CU, receiving a measurement report from a source parent node wherein the measurement report is included in a mobility related required message sent from the source parent node, and wherein the measurement report is associated with a measurement performed by a migrating IAB node (Page 16, Paragraph 3: 13 is a diagram exemplarily illustrating an Inter IAB-donor-CU movement/adaptation procedure according to an embodiment. Page 16, Paragraphs 6-8: 1. The migrating IAB node MT may forward the measurement report message to the source parent IAB node. 2. The source parent IAB node DU sends a UL RRC Transfer message to the source IAB donor CU to transfer the received measurement report. 3. For example, the source IAB donor CU transmits a handover request message to the target IAB donor CU.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide before sending the mobility related request message to the second donor CU, receiving a measurement report from a source parent node wherein the measurement report is included in a mobility related required message sent from the source parent node, and wherein the measurement report is associated with a measurement performed by a migrating IAB node, as taught by Hong in the combined system of Barac, Teyeb, and Barac2, so that an Inter IAB-donor-CU movement/adaptation procedure can be performed (Hong: Fig. 13, Page 16, Paragraphs 1-8).
Regarding claim 7, the combination of Barac, Teyeb, Hong, and Barac2 teaches the method according to claim 5 (see rejection for claim 5);
Barac further teaches wherein the mobility related request message is a handover request message (Paragraph [0181]: Action 1003. The first radio network node 12 may transmit to the second radio network node 15, the message related to the handover or the cell reselection of the migrating node to the second radio network node 15, wherein the message comprises data associated with the migrating node, and data related to the one or more other nodes, directly and indirectly served by the migrating node. The message may be a handover request to the second radio network node 15, wherein the handover request comprises data, or an indication of resources needed for being served, signalling requirements etc., associated with the migrating node, e.g. IAB node, and data related to other nodes, such as IAB nodes and/or UEs, directly and indirectly served by the migrating node i.e. plurality of nodes. The data may indicate one or more resources required to serve the migrating node and/or the other nodes. The transmitted message may comprise a HANDOVER REQUEST message.)
Regarding claim 8, the combination of Barac, Teyeb, Hong, and Barac2 teaches the method according to claim 5 (see rejection for claim 5);
Barac further teaches wherein the mobility related ACK message is a handover request acknowledge message (Paragraph [0182]: Action 1004. The first radio network node 12 receives from the second radio network node 15, the indication indicating whether handover or cell reselection to the second radio network node 15 is confirmed or not, wherein the indication indicates whether the migrating node 15 and/or the one or more other nodes, directly and indirectly served by the migrating node 15, are accepted or cancelled for handover or cell reselection to the second radio network node 15. The indication may indicate whether one or more nodes are accepted or cancelled for Handover (HO) to the second radio network node 15. The received indication may be comprised in a HANDOVER REQUEST ACKNOWLEDGE message. Thus, the first radio network node 12 may receive a HANDOVER REQUEST ACKNOWLEDGE message, such as an enhanced Xn HANDOVER REQUEST ACKNOWLEDGE message or a newly defined message, being an example of the received indication.)
Regarding claim 10, the combination of Barac, Teyeb, Hong, and Barac2 teaches the method according to claim 5 further comprising (see rejection for claim 5);
Barac further teaches configuring, at the first donor CU, (a) BH RLC channels, or (b) BAP-sublayer routing entries for a target path (Paragraph [0054]: Action 11. The IAB-donor-CU configures BH RLC channels and BAP-layer route entries on the target path between migrating IAB-node and target IAB-donor-DU. This step also includes allocation of transport network layer (TNL) address(es) that is (are) routable via the target IAB-donor-DU. These configurations may be performed at an earlier stage, e.g. right after action 3. The new TNL address(es) is (are) included in the RRCReconfiguration message at action 5. Paragraph [0058]: Action 15. The IAB-donor-CU releases BH RLC channels and BAP routing entries on the source path. The migrating IAB-node may further release the TNL address(es) it used on the source path. Paragraph [0064]: Based on implementation, these actions can be performed after or in parallel with the handover of the migrating IAB-node.)
or (c) UL traffic mapping for the target path (Paragraph [0053]: Action 10. The target parent node gNB-DU sends an UL RRC MESSAGE TRANSFER message to the IAB-donor-CU to convey the received RRCReconfigurationComplete message. Also, uplink packets can be sent from the migrating IAB-MT, which are forwarded to the IAB-donor-CU through the target parent node gNB-DU. These DL and UL packets belong to the MT's own signalling and data traffic. Paragraph [0054]: Action 11. The IAB-donor-CU configures BH RLC channels and BAP-layer route entries on the target path between migrating IAB-node and target IAB-donor-DU. This step also includes allocation of transport network layer (TNL) address(es) that is (are) routable via the target IAB-donor-DU. These configurations may be performed at an earlier stage, e.g. right after action 3. The new TNL address(es) is (are) included in the RRCReconfiguration message at action 5.)
Regarding claim 21, Barac teaches an apparatus for wireless communication comprising at least one processor configured to execute code from a memory and cause the apparatus to implement a method, comprising: (Paragraph [0122]: It is furthermore provided herein a computer program product comprising instructions, which, when executed on at least one processor, cause the at least one processor to carry out the method above, as performed by the first radio network node or the second radio network node, respectively. It is additionally provided herein a computer-readable storage medium, having stored thereon a computer program product comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method according to the method above, as performed by the first radio network node or the second radio network node, respectively. Paragraph [0227]: Thus, embodiments herein may disclose a first radio network node for handling communication in a wireless communications network, wherein the first radio network node comprises processing circuitry and a memory, said memory comprising instructions executable by said processing circuitry whereby said first radio network node is operative to perform any of the methods herein.)
sending, by a first donor Centralized Unit (CU), a mobility related request message to a second donor CU; wherein the mobility related request message comprises: a BH RLC Channel configuration for an integrated access and backhaul distributed unit (IAB-DU) configured by the first donor CU including a BH RLC Channel ID; configuration information of an IAB-DU, and routing configuration for the IAB-DU configured by the first donor CU; and receiving at the first donor CU, a mobility related ACK message from the second donor CU (see rejection for claim 5);
Barac does not explicitly teach configuration information of an IAB-DU that includes an IP address request information; wherein the mobility related ACK message comprises IP address information allocated for an IAB-DU, a routing configuration information configured by the second donor CU, and a traffic mapping configuration information configured by the second donor CU, wherein the IP address information comprises: an IP address, an IP address prefix, an IP address usage, or an IAB donor DU BAP address.
However, Teyeb teaches wherein the mobility related ACK message comprises IP address information allocated for an IAB-DU, wherein the IP address information comprises: an IP address; a routing configuration information configured by the second donor CU (see rejection for claim 5);
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide wherein the mobility related ACK message comprises IP address information allocated for an IAB-DU, wherein the IP address information comprises: an IP address, a routing configuration information configured by the second donor CU, as taught by Teyeb in the system of Barac, so that after a handover, the interface between the IAB node DU and the IAB donor CU can be established based on the received configuration information, and the routing configuration provided by the second donor CU to the first donor CU can establish the interface between the IAB node DU and the IAB donor CU in parallel while sending the handover command (Teyeb: Paragraphs [0105], [0106], [0152], [0153], [0162]).
The combination of Barac and Teyeb does not explicitly teach configuration information of IAB-DU that includes an IP address request information.
However, Hong teaches configuration information of IAB-DU that includes an IP address request information (see rejection for claim 5);
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide configuration information of IAB-DU that includes an IP address request information, as taught by Hong in the combined system of Barac and Teyeb, so that the IAB-DU is provided with the IP address information for the handover (Hong: Page 14, Paragraphs 4-5, Page 16, Paragraph 8).
The combination of Barac, Teyeb, and Hong does not explicitly teach a traffic mapping configuration information configured by the second donor CU.
However, Barac2 teaches a traffic mapping configuration information configured by the second donor CU (see rejection for claim 5);
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide a traffic mapping configuration information configured by the second donor CU, as taught by Bartac2 in the combined system of Barac, Teyeb, and Hong, so that the QoS flows, PDU sessions, BH RLC channels information, and other information related to the migrating node can be included in the handover request message for a successful handover process (Barac2: Paragraphs [0156] – [0165], [0189] – [0195], [0197] – [0198], [0215] – [0220], [0223]).
Regarding claim 22, the combination of Barac, Teyeb, Hong, and Barac2 teaches the apparatus according to claim 21, wherein the method further comprises (see rejection for claim 21);
The combination of Barac, Teyeb, and Barac2 does not explicitly teach before sending the mobility related request message to the second donor CU, receiving a measurement report from a source parent node wherein the measurement report is included in a mobility related required message sent from the source parent node, and wherein the measurement report is associated with a measurement performed by a migrating IAB node.
However, Hong teaches before sending the mobility related request message to the second donor CU, receiving a measurement report from a source parent node wherein the measurement report is included in a mobility related required message sent from the source parent node, and wherein the measurement report is associated with a measurement performed by a migrating IAB node (see rejection for claim 6);
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide before sending the mobility related request message to the second donor CU, receiving a measurement report from a source parent node wherein the measurement report is included in a mobility related required message sent from the source parent node, and wherein the measurement report is associated with a measurement performed by a migrating IAB node, as taught by Hong in the combined system of Barac, Teyeb, and Barac2, so that an Inter IAB-donor-CU movement/adaptation procedure can be performed (Hong: Fig. 13, Page 16, Paragraphs 1-8).
Regarding claim 23, the combination of Barac, Teyeb, Hong, and Barac2 teaches the apparatus according to claim 21 (see rejection for claim 21);
Barac further teaches wherein the mobility related request message is a handover request message (see rejection for claim 7).
Regarding claim 24, the combination of Barac, Teyeb, Hong, and Barac2 teaches the apparatus according to claim 21 (see rejection for claim 21);
Barac further teaches wherein the mobility related ACK message is a handover request acknowledge message (see rejection for claim 8).
Regarding claim 25, the combination of Barac, Teyeb, Hong, and Barac2 teaches the apparatus according to claim 21 (see rejection for claim 21);
Barac further teaches wherein the method further includes, configuring, at the first donor CU, (a) BH RLC channels, or (b) BAP-sublayer routing entries for a target path, or (c) UL traffic mapping for the target path (see rejection for claim 10).
Claims 29-32 are rejected under 35 U.S.C. 103 as being unpatentable over Barac et al. (US2023/0239754A1) in view of Teyeb et al. (US2023/0239755A1), Hong (WO2021/187933A1), Barac et al. (US2023/0232285A1) hereinafter Barac2, and further in view of Ishii (US2022/0217598A1).
Regarding claim 29, the combination of Barac, Teyeb, Hong, and Barac2 teaches the method according to claim 5, wherein the IAB-DU configured by the first donor is a IAB-DU (see rejection for claim 5);
The combination of Barac, Teyeb, Hong, and Barac2 does not explicitly teach a collocated IAB-DU.
However, Ishii teaches is a collocated IAB-DU (Paragraph [0077]: FIG. 2 depicts an example of functional block diagrams for the IAB-donor and the IAB-node (see FIG. 1). The IAB-donor may comprise at least one Central Unit (CU) and at least one Distributed Unit (DU). The CU is a logical entity managing the DU collocated in the IAB-donor.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide a collocated IAB-DU, as taught by Ishii in the combined system of Barac, Teyeb, Hong, and Barac2, so that the donor CU can coordinate the handover process of a collocated IAB-DU (Ishii: Paragraph [0077], Paragraph [0118]).
Regarding claim 30, the combination of Barac, Teyeb, Hong, and Barac2 teaches the method according to claim 5 wherein the configuration information of the IAB-DU corresponds to configuration information of a IAB-DU (see rejection for claim 5);
The combination of Barac, Teyeb, Hong, and Barac2 does not explicitly teach a collocated IAB-DU.
However, Ishii teaches a collocated IAB-DU (Paragraph [0077]: FIG. 2 depicts an example of functional block diagrams for the IAB-donor and the IAB-node (see FIG. 1). The IAB-donor may comprise at least one Central Unit (CU) and at least one Distributed Unit (DU). The CU is a logical entity managing the DU collocated in the IAB-donor.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide a collocated IAB-DU, as taught by Ishii in the combined system of Barac, Teyeb, Hong, and Barac2, so that the donor CU can coordinate the handover process of a collocated IAB-DU (Ishii: Paragraph [0077], Paragraph [0118]).
Regarding claim 31, the combination of Barac, Teyeb, Hong, and Barac2 teaches the apparatus according to claim 21, wherein the IAB-DU configured by the first donor is a IAB-DU (see rejection for claim 21);
The combination of Barac, Teyeb, Hong, and Barac2 does not explicitly teach a collocated IAB-DU.
However, Ishii teaches is a collocated IAB-DU (Paragraph [0077]: FIG. 2 depicts an example of functional block diagrams for the IAB-donor and the IAB-node (see FIG. 1). The IAB-donor may comprise at least one Central Unit (CU) and at least one Distributed Unit (DU). The CU is a logical entity managing the DU collocated in the IAB-donor.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide a collocated IAB-DU, as taught by Ishii in the combined system of Barac, Teyeb, Hong, and Barac2, so that the donor CU can coordinate the handover process of a collocated IAB-DU (Ishii: Paragraph [0077], [0118]).
Regarding claim 32, the combination of Barac, Teyeb, Hong, and Barac2 teaches the apparatus according to claim 21 wherein the configuration information of the IAB-DU corresponds to configuration information of a IAB-DU (see rejection for claim 21);
The combination of Barac, Teyeb, Hong, and Barac2 does not explicitly teach a collocated IAB-DU.
However, Ishii teaches a collocated IAB-DU (Paragraph [0077]: FIG. 2 depicts an example of functional block diagrams for the IAB-donor and the IAB-node (see FIG. 1). The IAB-donor may comprise at least one Central Unit (CU) and at least one Distributed Unit (DU). The CU is a logical entity managing the DU collocated in the IAB-donor.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide a collocated IAB-DU, as taught by Ishii in the combined system of Barac, Teyeb, Hong, and Barac2, so that the donor CU can coordinate the handover process of a collocated IAB-DU (Ishii: Paragraph [0077], Paragraph [0118]).
Response to Arguments
Applicant's arguments filed March 27, 2026 with respect to claims 5, 7, 8, 10, 13, 21, and 23-25, 28 being rejected under 35 U.S.C. § 103 as being unpatentable over Barac et al. (US2023/0239754A1), in view of Teyeb et al. (US2023/0239755A1) and Hong (WO2021/187933A1); claims 6 and 22 being rejected under 35 U.S.C. § 103 as being unpatentable over Barac et al. (US2023/0239754A1) in view of Teyeb et al. (US2023/0239755A1), and Hong (WO2021/187933A1), and further in view of Fujishiro (US2022/0264665A1); claims 29-32 being rejected under 35 U.S.C. § 103 as being unpatentable over Barac et al. (US2023/0239754A1) in view of Teyeb et al. (US2023/0239755A1), and Hong (WO2021/187933A1), and further in view of Ishii (US2022/0217598A1), have been fully considered.
Applicant submits that the cited references Barac, Hong and Teyeb do not teach the HANDOVER REQUEST ACK message including "a traffic mapping configuration information configured by the second donor CU" as required by amended claim 5. However, Barac et al. (US2023/0232285A1) hereinafter Barac2, teaches the HANDOVER REQUEST ACK message including "a traffic mapping configuration information configured by the second donor CU". Barac2 teaches that the second donor CU (target donor CU – node 15) includes in the handover request acknowledge message the DRBs, QoS flows/PDU sessions admitted, and the list of admitted and the list of not admitted BH RLC channels and PDU sessions established. The second donor CU configures the traffic mapping configuration based on the UP resources required to serve the migrating IAB-nodes and UEs (DRBs, QoS flows, PDU sessions, backhaul (BH) RLC channels), and includes them in the handover response (Barac2: [0191], [0195], [0198]. Thus, Barac2 teaches that the second donor CU sends a traffic mapping configuration in the handover acknowledgement message. Thus, the combination of Barac, Teyeb, Hong, and Barac2 teaches amended independent claim 5 and also amended independent claim 21 which recites similar limitations.
Dependent claims 6, 7, 8, 10, and 22-25 are also taught by the combination of Barac, Teyeb, Hong, and Barac2. Hong teaches “before sending the mobility related request message to the second donor CU, receiving a measurement report from a source parent node, wherein the measurement report is included in a mobility related required message sent from the source parent node, and wherein the measurement report is associated with a measurement performed by a migrating IAB node", as recited in dependent claims 6 and 22. Dependent claims 29-32 are taught by the combination of Barac, Teyeb, Hong, Barac2, and Ishii (US2022/0217598A1).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LATHA CHAKRAVARTHY whose telephone number is (703)756-1172. The examiner can normally be reached M-Th 8:30 AM - 5 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, Huy Vu can be reached at 571-272-3155. 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.
/L.C./Examiner, Art Unit 2461
/JASON E MATTIS/Primary Examiner, Art Unit 2461
Prosecution Insights