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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 10/01/2024, 06/04/2025, 10/07/2025 were 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
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-15 are rejected under 35 U.S.C. 103 as being unpatentable over Diao (US 2022/0369190 A1) in view of Luo-464 (US 2022/0322464 A1).
Regarding claim 1, Diao discloses: An integrated access and backhaul IAB donor-CU device, which is an F1-terminating donor-CU device of a migrating IAB node, the device comprising: a transmitter configured to transmit IP address configuration information of an F1-terminating topology domain allocated for the migrating IAB node to a non-F1-terminating donor-CU, because Diao teaches a source (original) donor CU that holds the F1 interface toward the migrating IAB node and sends a handover request to a target donor CU carrying the collected context of the migrating IAB node and its downstream nodes, including addressing and backhaul channel information: (Diao, para [0024] “In some embodiments, and after the original donor CU collects all the IAB nodes and UEs to be switched, it sends a handover request to the target donor CU.”)
Although Diao teaches an inter-donor migration in which the source donor-CU that terminates F1 for the migrating IAB node exchanges handover request and acknowledgment signaling with the target donor-CU, the acknowledgment carrying reconfiguration content including IP addresses for the migrating node: (Diao, [0024], [0025], [0026], [0029]), Diao does not explicitly disclose explicit identification of the exchanged addresses as transport network layer addresses anchored at a donor-DU of each donor-CU topology, one already held in the source topology and a new one obtained from the target topology.
However, Diao in view of Luo-464 discloses wherein IP address configuration information of the F1-terminating topology domain includes a TNL (transport network layer) address anchored at a donor-DU in the F1-terminating donor-CU topology for the migrating IAB node, and a receiver configured to receive IP address configuration information of the non-F1-terminating topology domain allocated for the migrating IAB node transmitted by the non-F1-terminating donor-CU because Luo-464 teaches the IP address that the migrating node uses toward its current (source) donor is the transport-layer address on which its TNL connection to that donor is built and which is routed through that donor's DU, and Luo-464 expressly ties the IP address held for a donor CU to the TNL connection a gNB-DU must establish before F1 setup, so the address information the source donor passes along in handover preparation is such a donor-DU-anchored transport network layer address (Luo-464, para [0110], “in order to establish a new F1 connection, the IAB -n ode 3 needs to obtain the IP address of the target donor CU, which is because a gNB - DU needs to establish a transport network layer ( TNL) connection of the gNB - DU before an F1 setup”; Luo-464, para [0122], “the source donor CU acquired the IP address of the target donor CU during the handover preparation process”).
Furthermore, Luo-464 discloses wherein IP address configuration information of the non-F1-terminating topology domain includes a new TNL address anchored at a donor-DU in the non-F1-terminating donor-CU topology for the migrating IAB node because Luo-464 teaches a fresh address valid in the other donor's topology is supplied to the migrating node so that its DU part can build a TNL connection and then an F1 connection in that topology, which is exactly a new transport network layer address routed through the other donor's distributed unit rather than the address it previously used (Luo-464, para [0144], “the target donor CU sends its own IP address information to the MT part of the IAB -n ode through an RRC reconfiguration message, then the MT part of the IAB - node notifies the DU part, and the DU part of the IAB - node may use the IP”; Luo-464, para [0130], “after the MT part of the IAB - node establishes an RRC connection with the target donor CU, the target donor CU sends the IP address to the MT part of the IAB - node through an RRC reconfiguration message, and then the MT part of the IAB -n ode”).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the invention to implement the inter-donor address exchange of Diao using the transport-layer addressing teaching of Luo-464, because Diao already has the source and target donor-CUs exchange IP addresses for the migrating node during handover preparation but leaves the nature of those addresses unstated, while Luo-464 explains that an IAB node's DU must obtain an IP address in order to bring up a transport network layer connection before F1 setup, and further teaches carrying that address (and address requests) in RRC reconfiguration and other RRC container signaling and in handover request/acknowledge exchanges between source and target donor-CUs; a skilled artisan combining these teachings would predictably arrive at a source donor-CU that both supplies its own topology's transport-layer address and receives a new topology-specific transport-layer address, delivered in RRC reconfiguration content, so that F1 continuity is preserved across the donor change with no loss of connectivity
Regarding claim 2, in spite of the fact that Diao teaches the combination already establishes an F1-terminating donor-CU exchanging the migrating node's address configuration with a non-F1-terminating donor-CU during inter-donor migration: (Diao, para. [0024], [0025]), Diao does not explicitly disclose delivery of the F1-terminating topology address configuration inside an RRC container.
Yet, Diao in view of Luo-464 discloses The device according to claim 1, wherein the IP address configuration information of the F1-terminating topology domain is carried by a first RRC (Radio Resource Control) container because the source donor CU is described as delivering address information to the migrating node's mobile termination inside a radio resource control reconfiguration message, so the address configuration originating at the source donor side is conveyed within an encapsulated RRC message, which under the broadest reasonable reading is a first RRC container (Luo-464, para [0123], “the source donor CU sends an RRC reconfiguration message to the MT of an IAB - node ( for example, IAB - node 1 in this embodiment), and the RRC reconfiguration message may include the IP address of the target donor CU”).
Thus, it would have been obvious to one of ordinary skill in the art to carry the address configuration of Diao in an RRC container as taught by Luo-464, because Luo-464 states that directly carrying the IP address in an RRC reconfiguration message is the simpler manner of delivering it, and reusing an existing control-plane container avoids defining new signaling for the same purpose.
Regarding claim 3, although Diao teaches the combination already provides address configuration for the F1-terminating topology carried in an RRC container during inter-donor migration: (Diao, para. [0025], [0026]), Diao does not explicitly disclose use of an RRC reconfiguration message as the specific message within that container.
Yet, Diao in view of Luo-464 discloses The device according to claim 2, wherein the IP address configuration information of the F1-terminating topology domain is carried by RRC reconfiguration message (RRCReconfiguration) contained in the first RRC container because the address information sent from the source donor CU is placed specifically in an RRC reconfiguration message directed to the mobile termination of the IAB node, which is the RRCReconfiguration message encapsulated in the container recited by claim 2 (Luo-464, para [0126], “For the migrating IAB - node, directly carrying the IP address of the target donor CU in the RRC reconfiguration message is a simpler manner.”).
Consequently, it would have been obvious to one of ordinary skill in the art to specify the RRC reconfiguration message of Luo-464 as the carrier of the address configuration in Diao's inter-donor procedure, since Luo-464 identifies that message as the simpler and already available means for delivering address information to a migrating IAB node, and its use requires no new protocol element.
Regarding claim 4, in spite of the fact that Diao teaches the combination already has the F1-terminating donor-CU receive address configuration allocated in the other donor's topology for the migrating node: (Diao, para. [0025]), Diao does not explicitly disclose delivery of the non-F1-terminating topology address configuration inside a second RRC container.
Yet, Diao in view of Luo-464 discloses The device according to claim 1, wherein the IP address configuration information of the non-F1-terminating topology domain is carried by a second RRC container because the source donor CU is described as delivering address information to the migrating node's mobile termination inside a radio resource control reconfiguration message, so the address configuration originating at the source donor side is conveyed within an encapsulated RRC message, which under the broadest reasonable reading is a first RRC container (Luo-464, para [0123], “the source donor CU sends an RRC reconfiguration message to the MT of an IAB - node ( for example, IAB - node 1 in this embodiment), and the RRC reconfiguration message may include the IP address of the target donor CU”).
For these reasons, it would have been obvious to one of ordinary skill in the art to carry the target-topology address of Diao's handover acknowledgment in a second RRC container as taught by Luo-464, because Luo-464 shows the target donor CU delivering its address to the migrating node by RRC reconfiguration, and reusing that container keeps the address delivery consistent for both topologies.
Regarding claim 5, even though Diao teaches the combination already carries the non-F1-terminating topology address configuration for the migrating node in an RRC container: (Diao, para. [0025], [0026]), Diao does not explicitly disclose use of an RRC reconfiguration message as the specific message within the second container.
Yet, Diao in view of Luo-464 discloses The device according to claim 4, wherein the IP address configuration information of the non-F1-terminating topology domain is carried by an RRC reconfiguration message (RRCReconfiguration) contained in the second RRC container because the address allocated on the target side is expressly placed in an RRC reconfiguration message sent by the target donor CU, so the encapsulated message inside the second container is an RRCReconfiguration message (Luo-464, para [0131], “the target donor CU may send an RRC reconfiguration message to a child IAB node ( for example, IAB - node 3 in this embodiment) of the migrating IAB node, and the RRC reconfiguration message carries the IP address of the target donor CU.”).
Therefore, it would have been obvious to one of ordinary skill in the art to specify Luo-464's RRC reconfiguration message as the carrier of the target-topology address in Diao's procedure, because Luo-464 shows that message being used to hand the address to the node's DU part for transport-layer setup, a predictable and already standardized delivery mechanism.
Regarding claim 6, in spite of the fact that Diao teaches the combination already carries the F1-terminating topology address configuration in an RRC container exchanged during inter-donor handover preparation: (Diao, para. [0024]), Diao does not explicitly disclose carriage of that first RRC container in a handover request message.
Yet, Diao in view of Luo-464 discloses The device according to claim 2, wherein the first RRC container is carried by: a handover request message because the address information sent from the source donor CU is placed specifically in an RRC reconfiguration message directed to the mobile termination of the IAB node, which is the RRCReconfiguration message encapsulated in the container recited by claim 2 (Luo-464, para [0126], “For the migrating IAB - node, directly carrying the IP address of the target donor CU in the RRC reconfiguration message is a simpler manner.”).
Accordingly, it would have been obvious to one of ordinary skill in the art to place the migrating node's information container in the handover request message as taught by Luo-464, since Diao already sends a handover request to the target donor and Luo-464 shows that message carrying the migrating node's information, so consolidating the information in the existing request reduces signaling exchanges.
Regarding claim 7, even though Diao teaches the combination already carries the non-F1-terminating topology address configuration in an RRC container returned to the source donor-CU: (Diao, para. [0025]), Diao does not explicitly disclose carriage of that second RRC container in a handover request acknowledge message.
Yet, Diao in view of Luo-464 discloses The device according to claim 4, wherein the second RRC container is carried by a handover request acknowledge message because the address allocated on the target side is expressly placed in an RRC reconfiguration message sent by the target donor CU, so the encapsulated message inside the second container is an RRCReconfiguration message (Luo-464, para [0131], “the target donor CU may send an RRC reconfiguration message to a child IAB node ( for example, IAB - node 3 in this embodiment) of the migrating IAB node, and the RRC reconfiguration message carries the IP address of the target donor CU.”).
Thus, it would have been obvious to one of ordinary skill in the art to return the target-topology address container in the handover acknowledgment as taught by Luo-464, because Diao's target donor already answers with a handover request acknowledgment carrying reconfiguration content, and Luo-464 confirms that the responsive handover message is a natural vehicle for the target donor's address information.
Regarding claim 8, which depends on claim 1, Diao discloses The device according to claim 1, wherein the F1-terminating donor-CU is a source donor-CU from which the migrating IAB node is handed over, and the non-F1-terminating donor-CU is a target donor-CU to which the migrating IAB node is handed over; the migrating IAB node is migrated from the F1-terminating donor-CU to the non-F1-terminating donor-CU. as Diao further discloses an inter-donor switching operation in which the original (source) donor CU sends a handover request for the migrating IAB node to a target donor CU, which then admits the node and returns an acknowledgment, so the node moves from the source donor to the target donor (Diao, para [0025] “In some embodiments, and after receiving the handover request, the target donor CU performs admission control. If the target donor CU can support all IAB nodes and UEs that intend to switch, it responds with a handover request acknowledgment to the original donor CU.”).
Regarding claim 9, which depends on claim 1, Diao discloses The device according to claim 1, wherein the transmitter further transmits the IP address configuration information of the non-F1-terminating topology domain to the migrating IAB node. as Diao further discloses the original donor CU forwarding to the migrating IAB node the RRC Reconfiguration message received from the target donor, that message containing the migrating node's IP address and the target donor addresses (Diao, para [0044] “In some embodiments, and after receiving the handover request acknowledgment message, the original donor CU sends an RRC Reconfiguration message to the migrating IAB node.”).
Regarding claim 10, although Diao teaches the combination already delivers the other topology's address configuration to the migrating node in an RRC reconfiguration message: (Diao, para. [0026], [0029]), Diao does not explicitly disclose carriage of the address configuration in a list-type address configuration element within the reconfiguration message.
Yet, Diao in view of Luo-464 discloses The device according to claim 5, wherein the IP address configuration information of the non-F1-terminating topology domain is carried by IAB-IP-AddressConfigurationList in the RRCReconfiguration because the reconfiguration message sent by the target donor CU carries the address information for the IAB node together with further identity and configuration items, so the message conveys the address configuration as an enumerated set of address entries within the reconfiguration message; formatting those entries as a named address-configuration list information element is a routine labelling of the same content (Luo-464, para [0115], “the target donor CU notifies the IAB - node 3 through RRC signaling ( for example, RRC reconfiguration message)”).
Therefore, it would have been obvious to one of ordinary skill in the art to structure the address configuration delivered in Diao's reconfiguration signaling as a list element of the kind taught by Luo-464's RRC-borne address delivery, because an IAB node may need more than one address in the new topology and collecting the allocated addresses in a single list within the reconfiguration message is a straightforward organizational choice yielding predictable results.
Regarding claim 11, Diao discloses: An integrated access and backhaul IAB donor-CU device, which is a non-F1-terminating donor-CU device of a migrating IAB node, the device comprising: a receiver configured to receive IP address configuration information of an F1-terminating topology domain allocated for the migrating IAB node transmitted by an F1-terminating donor-CU, because Diao teaches a target donor CU that receives from the original donor CU a handover request carrying the context information of the migrating IAB node and its downstream nodes, including backhaul channel and identity content, and then performs admission control: (Diao, para [0024] “In an example, the handover request includes an Xn application protocol ( Xn - AP) ID assigned by the original donor CU to all MTs and UEs, the context info of each UE and MT, the established backhaul ( BH) RLC channel ID, and BH RLC channel quality -o f”)
Furthermore, Diao discloses: and, a transmitter configured to transmit IP address configuration information of the non-F1-terminating topology domain allocated for the migrating IAB node to the F1-terminating donor-CU, because Diao teaches the target donor CU responding to the original donor CU with a handover request acknowledgment that carries the RRC Reconfiguration message for the migrating IAB node, which includes the migrating node's IP address generated by the target donor: (Diao, para [0029] “migrating IAB node IP address ( if the IP address is generated by target donor)”; Diao, para [0025] “the handover request acknowledgment message includes the Source NG-RAN node UE XnAP IDs.of the accepted IAB MTs and UEs, the RRC Reconfiguration message sent to the migrating IAB node, and the RRC Reconfiguration message for the accepted downstream IAB nodes.”)
Although Diao teaches a target donor-CU that receives the migrating node's context in a handover request from the source donor-CU and answers with an acknowledgment carrying reconfiguration content including an IP address generated by the target donor for the migrating node: (Diao, [0024], [0025], [0029]), Diao does not explicitly disclose explicit identification of the exchanged addresses as transport network layer addresses anchored at a donor-DU in each donor-CU's topology.
However, Diao in view of Luo-464 discloses wherein IP address configuration information of the F1-terminating topology domain includes a TNL (transport network layer) address anchored at a donor-DU in the F1-terminating donor-CU topology for the migrating IAB-node because Luo-464 teaches the address a node holds toward its current donor is precisely the address on which its DU builds a transport network layer connection to that donor, routed through that donor's distributed unit, so the address information the source donor obtains and passes during handover preparation is such a donor-DU-anchored transport network layer address (Luo-464, para [0110], “in order to establish a new F1 connection, the IAB -n ode 3 needs to obtain the IP address of the target donor CU, which is because a gNB - DU needs to establish a transport network layer ( TNL) connection of the gNB - DU before an F1 setup”; Luo-464, para [0122], “the source donor CU acquired the IP address of the target donor CU during the handover preparation process”).
Furthermore, Luo-464 discloses wherein IP address configuration information of the non-F1-terminating topology domain includes a new TNL address anchored at a donor-DU in the non-F1-terminating donor-CU topology for the migrating IAB-node because Luo-464 teaches the target donor supplies a fresh address that the node's DU part uses to establish a transport network layer connection in the target topology before F1 setup, which is a new transport network layer address routed through the target donor's distributed unit (Luo-464, para [0144], “the target donor CU sends its own IP address information to the MT part of the IAB -n ode through an RRC reconfiguration message, then the MT part of the IAB - node notifies the DU part, and the DU part of the IAB - node may use the IP”).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the invention to implement the target donor-CU of Diao with the transport-layer addressing of Luo-464, because Diao has the target donor generate and return an IP address for the migrating node without stating how that address functions, while Luo-464 explains that such an address is needed so the node's DU can bring up a transport network layer connection before F1 setup and shows the address (and requests for it) being conveyed in RRC reconfiguration content and in handover request and response signaling between donor-CUs; using Luo-464's transport-layer address for Diao's returned address, and likewise for the address held in the source topology, is a predictable application of a known addressing mechanism that keeps F1 service continuous through the donor change
Regarding claim 12, Diao discloses: An integrated access and backhaul IAB donor-CU device, which is an F1-terminating donor-CU device of an IAB node, the device comprising: a transmitter configured to transmit IP address request information of a non-F1-terminating topology domain for the migrating IAB node to a non-F1-terminating donor-CU, because Diao teaches an original donor CU that terminates F1 for the IAB node and sends a handover request to another donor CU asking it to admit the node and its downstream nodes, the request identifying the nodes and their backhaul resources: (Diao, para [0024] “In some embodiments, and after the original donor CU collects all the IAB nodes and UEs to be switched, it sends a handover request to the target donor CU.”)
Furthermore, Diao discloses: a receiver configured to receive IP address configuration information of the non-F1-terminating topology domain allocated for the IAB node transmitted by the non-F1-terminating donor-CU, because Diao teaches receipt at the original donor CU of the acknowledgment from the other donor CU carrying the reconfiguration content prepared for the IAB node, which content includes the node's IP address where that address is generated by the other donor: (Diao, para [0025] “the handover request acknowledgment message includes the Source NG-RAN node UE XnAP IDs.of the accepted IAB MTs and UEs, the RRC Reconfiguration message sent to the migrating IAB node, and the RRC Reconfiguration message for the accepted downstream IAB nodes.”)
Although Diao teaches an F1-terminating donor-CU that asks another donor-CU to take on the IAB node by handover request and then receives back an acknowledgment carrying reconfiguration content, including an IP address generated by that other donor for the node: (Diao, [0024], [0025], [0029]), Diao does not explicitly disclose an explicit request for, and return of, a new or updated transport network layer address anchored at a donor-DU in the other donor-CU's topology.
Nevertheless, Diao in view of Luo-464 discloses wherein the IP address request information includes request for a new TNL address for the IAB node anchored at a donor-DU in the non-F1-terminating donor-CU topology because Luo-464 teaches the source donor is described as needing to obtain the address applicable in the other donor's topology and acquiring it during handover preparation, and the reason an IAB node needs such an address is that its DU must build a transport network layer connection in that topology, so the source donor's preparation signaling amounts to a request for a new transport-layer address anchored in that topology (Luo-464, para [0122], “[0122] In the case of Manner 2, the source donor CU needs to obtain the IP address of the target donor CU and may obtain the IP address of the target donor CU in one of the following manners:”).
Furthermore, Luo-464 discloses wherein the IP address configuration information of the non-F1-terminating topology domain includes a new or updated TNL (transport network layer) address anchored at a donor-DU in the non-F1-terminating donor-CU topology for the IAB node because Luo-464 teaches the address returned for the node in the other topology is the one its DU part uses to set up a transport network layer connection there and then an F1 connection, so it is a new or updated transport network layer address routed through that topology's distributed unit (Luo-464, para [0144], “the target donor CU sends its own IP address information to the MT part of the IAB -n ode through an RRC reconfiguration message, then the MT part of the IAB - node notifies the DU part, and the DU part of the IAB - node may use the IP”; Luo-464, para [0110], “a gNB - DU needs to establish a transport network layer ( TNL) connection of the gNB - DU before an F1 setup request message is sent to the gNB - DU and the IP address needs to be obtained to establish the TNL connection.”).
Accordingly, it would have been obvious to one of ordinary skill in the art at the time of the invention to have the F1-terminating donor-CU of Diao request and receive transport-layer addressing from the other donor-CU as taught by Luo-464, because Diao already exchanges handover request and acknowledgment signaling in which the other donor may generate the node's IP address, and Luo-464 teaches both that the source donor-CU obtains the address applicable in the other donor's topology during handover preparation and that such an address exists so the node's DU can bring up a transport network layer connection ahead of F1 setup; applying that teaching gives the source donor a definite way to solicit and receive a new or updated transport-layer address for the node with entirely predictable results for F1 continuity
Regarding claim 13, in spite of the fact that Diao teaches the combination already has the F1-terminating donor-CU solicit an address for the IAB node in the other donor's topology: (Diao, para. [0024]), Diao does not explicitly disclose carriage of the address request information in a first RRC container.
Yet, Diao in view of Luo-464 discloses The device according to claim 12, wherein the IP address request information is carried by a first RRC container because address-related information exchanged in connection with the migration is expressly stated to be carried in a radio resource control reconfiguration message, that is, encapsulated as RRC content within the inter-node signaling, which under the broadest reasonable reading is a first RRC container (Luo-464, para [0073], “The address information of the first CU may be carried in an F1 message or an RRC reconfiguration message.”).
Consequently, it would have been obvious to one of ordinary skill in the art to carry the address request of the combination in an RRC container as taught by Luo-464, because Luo-464 identifies RRC signaling as an available carrier for address information between the network and an IAB node, and reusing that container avoids introducing an additional message type.
Regarding claim 14, even though Diao teaches the combination already carries the IAB node's address request information in an RRC container: (Diao, para. [0024]), Diao does not explicitly disclose use of a dedicated IAB information message within that container to convey the request.
Yet, Diao in view of Luo-464 discloses The device according to claim 13, wherein the IP address request information is carried by IAB other information message (IABOtherInformation) contained in the first RRC (Radio Resource Control) container because the radio resource control message used to convey addressing to and from an IAB node is described as able to carry additional information beyond the identities themselves, so an IAB-directed information message conveying the node's address needs is carried inside the radio resource control container; naming that encapsulated message as an IAB other information message is a labelling of the same encapsulated content (Luo-464, para [0115], “The RRC reconfiguration message may contain additional information in addition to the above-mentioned identities.”).
For these reasons, it would have been obvious to one of ordinary skill in the art to convey the address request in a dedicated IAB information message inside the RRC container, as suggested by Luo-464's use of RRC messaging for IAB address information, because separating IAB-specific address content from ordinary reconfiguration content is a routine signaling design choice with predictable results.
Regarding claim 15, in spite of the fact that Diao teaches the combination already has one donor-CU terminating F1 for the IAB node while a second donor-CU supplies addressing in its own topology: (Diao, para. [0024], [0025]), Diao does not explicitly disclose an arrangement in which the F1-terminating donor-CU acts as master node and the other donor-CU as secondary node for the IAB node.
Yet, Diao in view of Luo-464 discloses The device according to claim 13, wherein the F1-terminating donor-CU is a master node MN of the IAB node, and the non-F1-terminating donor-CU is a secondary node SN of the IAB node because the radio resource control message used to convey addressing to and from an IAB node is described as able to carry additional information beyond the identities themselves, so an IAB-directed information message conveying the node's address needs is carried inside the radio resource control container; naming that encapsulated message as an IAB other information message is a labelling of the same encapsulated content (Luo-464, para [0115], “The RRC reconfiguration message may contain additional information in addition to the above-mentioned identities.”).
Therefore, it would have been obvious to one of ordinary skill in the art to designate the F1-terminating donor-CU as the controlling node and the address-providing donor-CU as the added node for the IAB node, since Luo-464 already contemplates an IAB node whose serving parent stays fixed while a different donor-CU supplies its addressing and transport resources, and formalizing that relationship as a master and secondary pairing simply labels the roles the two donor-CUs already perform.
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Diao (US 2022/0369190 A1) in view of Luo-464 (US 2022/0322464 A1) and further in view of Luo-976 (US 2022/0014976 A1).
Regarding claim 16, even though Diao in view of Luo-464 teaches the combination already has the F1-terminating donor-CU request addressing in the other donor's topology and receive the allocated address configuration back: (Diao, para. [0024], [0025]; Luo-464, para. [0122], [0144]), Diao in view of Luo-464 does not explicitly disclose use of dedicated transport migration management request, response and modification request messages to carry the address request and the allocated address configuration.
Yet, Diao in view of Luo-464 and further in view of Luo-976 discloses The device according to claim 12, wherein the IP address request information is carried by an IAB transport migration management request message, and the IP address configuration information is carried by an IAB transport migration management response message or an IAB transport migration modification request message because a donor CU is shown issuing a dedicated backhaul modification request that carries the transport configuration items for a node involved in the migration and receiving a matching modification response carrying the admitted configuration, so a purpose-built request/response pair is used to manage the node's transport resources during migration in place of generic mobility signaling (Luo-976, para [0061], “At 415, the IAB donor CU 408 sends an IAB BH modification request to the target path IAB node DU 406. The IAB BH modification request includes at least an IAB indication, a DRB list, a BH RLC channel list, adapt configurations, routine configurations, and so on.”).
Accordingly, it would have been obvious to one of ordinary skill in the art to carry the address request and the returned address configuration in dedicated transport management request, response and modification messages as taught by Luo-976, because Luo-976 shows a donor-CU managing a migrating IAB node's backhaul transport resources through a paired modification request and response that enumerate the admitted resources and their configurations, and using such purpose-built transaction messages for the address exchange keeps transport resource management separate from mobility signaling and makes the allocation explicitly acknowledged.
Accordingly, Diao and Luo-464 are combined for the reasons set forth in the rejection of claim 1 above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHONGSUH (John) PARK whose telephone number is 408-918-7574. The examiner can normally be reached Monday - Friday 8:00-5:30 PST
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, Avellino, Joseph can be reached at 571-272-3905 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.
/CHONGSUH PARK/Examiner, Art Unit 2478
/JOSEPH E AVELLINO/Supervisory Patent Examiner, Art Unit 2478
Prosecution Insights