Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s arguments with respect to claims 1, 33, and 75 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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.
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 1-3, 5-6, 9, 12, 26, 33-34, 44, and 75 are rejected under 35 U.S.C. 103 as being unpatentable over by Ishii et al. US 20230098848 A1 (Domestic Priority February 12, 2020) in view of Xu et al. US 20220182905 A1 (Domestic Priority January 29, 2019).
Regarding claim 1 (Currently Amended), Ischii discloses a method comprising: sending, by a source donor central unit (CU) to a target donor CU (see, transferring UE context from a source donor node via a parent IAB node to a target donor node, section 0282), an XnAP mobility related request message requesting migration of a wireless node from the source donor CU to the target donor CU (see, two donor nodes (CUs) are inter-connected by inter-node protocols such as Xn Application Protocol (XnAP) to select a cell and move it to its suitable location, section 0269, 0284-handover request message); sending, by the source donor CU to the wireless node, a threshold information for the wireless node to determine triggering migration from the source donor CU to the target donor CU and to establish a connection with the target donor CU; and receiving, by the source donor CU from the target donor CU, an XnAP mobility related response message in response to sending the XnAP mobility related request message (see, XnAP HANDOVER REQUEST messages being met with respective HANDOVER REQUEST ACKNOWLEDGEMENT messages, section 0264; noted, donor IAB nodes can receive a response after a request, sections 0268-0271).
Ischii discloses all the claim limitations as set forth above but fails to explicitly disclose: sending, by the source donor CU to the wireless node, a threshold information for the wireless node to determine triggering migration from the source donor CU to the target donor CU and to establish a connection with the target donor CU; and receiving, by the source donor CU from the target donor CU, an XnAP mobility related response message in response to sending the XnAP mobility related request message (see, XnAP HANDOVER REQUEST messages being met with respective HANDOVER REQUEST ACKNOWLEDGEMENT messages, section 0264; noted, donor IAB nodes can receive a response after a request, sections 0268-0271).
However Xu ‘905 from a similar field of endeavor discloses: sending, by the source donor CU to the wireless node, a threshold information for the wireless node to determine triggering migration from the source donor CU to the target donor CU (see, the DU may determine that it needs to switch from the source CU to the target CU if the distance between the DU and the source CU exceeds a threshold value, section 0053 Xu ‘905; noted, if the radio condition or quality of the interface is below a threshold value, the DU may determine that the CU switch is needed, section 0053 Xu ‘905; noted, where the DU is located may have means for measurements and may measure the radio link quality to both source CU and target CU and trigger the switch when the target CU radio link becomes better than the source CU radio link, section 0053 Xu ‘905) and to establish a connection with the target donor CU (see, a first message comprises identity information of the target CU and identity information of the DU to be used by the DU after it connects to target CU, section 0056 Xu ‘905); and receiving, by the source donor CU from the target donor CU, an XnAP mobility related response message in response to sending the XnAP mobility related request message.
In view of the above, it would have been obvious before the effective filling date of the claim invention to a person having ordinary skill in the art of which the claimed invention pertains to modify the network of Ischii with the triggering of a switch after a threshold value as taught by Xu ‘905. The motivation would have been to transmit identity information of a target CU/DU to the source CU for the CU switch.
Regarding claim 2 (Original), Ischii discloses the method according to claim 1, wherein the XnAP mobility related request message (see, XnAP HANDOVER REQUEST messages being met with respective HANDOVER REQUEST ACKNOWLEDGEMENT messages, section 0264; noted, donor IAB nodes can receive a response after a request, sections 0268-0271) comprises at least one of the following: at least one identity of one or more wireless nodes or user equipment (UE) that are to migrate from the source donor CU to the target donor CU (see, identity of the child node may comprise the Physical Cell ID (PCI) of the old serving cell, e.g., the cell served by IAB-node, section 0285; noted, the message flow from source donor node to target donor node, section 0282); gNB-DU System Information (see, cell may broadcast a node identification such as gNB-DU ID, section 0249); gNB-DU Cell Resource Configuration configured by the source donor CU (see, protocol stack configuration for the plane between an IAB-node directly connected to the IAB-donor where CU component is part of the IAB-donor and CU/IAB-donor to control the DU component resident in the IAB-node, sections 0112-0119; noted, cell may broadcast a node identification such as gNB-DU ID, section 0249); Integrated access and backhaul (IAB) Synchronization Signal Block (SSB) Transmission Configuration (STC) Information configured by the source donor CU (IAB-nodes may need to periodically perform inter-IAB-node discovery to detect new IAB-nodes in their vicinity based on cell-specific reference signals, e.g., Synchronization Signal and PBCH block SSB) where packets may be carried or broadcasted on the Master Information Block (MIB) section, section 0007; noted, child node may store the identification of the cell that transmits the Backhaul RLF Indication where the child node uses Synchronization Signal Block (SSB) and Master Information Block (MIB), section 0233); Multiplexing Information of wireless node (see, the system of relay nodes may utilize the same 5G radio access technologies and connections to the core network (backhaul link) simultaneously. These radio links may be multiplexed in time, frequency, and/or space. This system may be referred to as Integrated Access and Backhaul (IAB), section 0006); or indication information that indicates migration of the wireless node from the source donor CU to the target donor CU is complete (see, XnAP HANDOVER REQUEST messages being met with respective HANDOVER REQUEST ACKNOWLEDGEMENT messages, section 0264; noted, two donor nodes (CUs) are inter-connected by inter-node protocols such as Xn Application Protocol (XnAP), section 0269, see, XnAP HANDOVER REQUEST messages being met with respective HANDOVER REQUEST ACKNOWLEDGEMENT messages, section 0264; noted, donor IAB nodes can receive a response after a request, sections 0268-0271; noted, IAB-node may send a RRCSetupRequest, followed by reception of an RRCSetup and transmission of RRCSetupComplete, 0121).
Regarding claim 3 (Original), Ischii discloses the method according to claim 1, wherein the XnAP mobility related request message (see, two donor nodes (CUs) are inter-connected by inter-node protocols such as Xn Application Protocol (XnAP) to select a cell and move it to its suitable location, section 0269, 0284-handover request message) comprises at least one identity of one or more mobile terminal (MT) parts or distributed unit (DU) parts of one or more wireless nodes (see, a Mobile Termination (MT) functionality-typically provided by the User Equipment (UE) terminals-that may be implemented by Base Transceiver Stations (BTSs or BSs) nodes such as IAB nodes, section 0105) that are to migrate from the source donor CU to the target donor CU (see, identity of the child node may comprise the Physical Cell ID (PCI) of the old serving cell, e.g., the cell served by IAB-node, section 0285; noted, the message flow from source donor node to target donor node, section 0282), wherein the at least one identity further comprises at least one of a Backhaul Adaptation Protocol (BAP) address of the one or more wireless nodes allocated by the source donor CU (see, CU part of the donor node manages routings and topologies of the relay network belonging to the donor node, the source donor node, e.g., donor IAB node, section 282; noted, physical layer signaling includes BAP layer signaling, section 0287), or an XnAP ID allocated by the source donor CU (see, XnAP HANDOVER REQUEST messages that may be used to transfer each child/grandchild's context, 0284).
Regarding claim 5 (Original), Ischii discloses the method according to claim 1, further comprising: sending, by the source donor CU to the target donor CU, a mobility related message indicating that migration of the wireless node from the source donor CU to the target donor CU is complete (see, a child node sending back an acknowledgement message showing successful transmission, sections 0156, 0177; noted, child node sending a message to the donor of the target cell, section 0156; noted, donor node comprises central unit, section 0241).
Regarding claim 6 (Original), Ischii discloses the method according to claim 1, further comprising: receiving, by the source donor CU from the target donor CU (see, XnAP HANDOVER REQUEST messages being met with respective HANDOVER REQUEST ACKNOWLEDGEMENT messages, section 0284; noted, donor IAB nodes can receive a response after a request, sections 0268-0271), a mobility related message including at least one of the following: an indication information indicating the migration of a mobile terminal (MT) part or a distributed unit (DU) part of the wireless node is complete (see, DU part of IAB-node may initiate an Fl Setup procedure by sending a F1 SETUP REQUEST to donor IAB node and receiving a F1 SETUP RESPONSE that is part of the re-establishment procedure that sends back an indication of changes, sections 0271-278); an indication information indicating the wireless node has established an F1 connection with the target donor CU (see, DU part of IAB-node may initiate an Fl Setup procedure by sending a F1 SETUP REQUEST to donor IAB node, section 0271); an indication information indicating F1-C between the wireless node and the target donor CU has migrated successfully (see, a second wireless access node may use F1-AP* to update the routing configurations at the Node B for the Child Node 1 and may interact with the first wireless access node to report the completion of the conditional handover, section 0156); one or more new radio (NR) Cell Global Identifier (CGI) configured by the target donor CU; or one or more old NR CGI (see, IAB-donor wireless access node can include cell/node identities that can include NR Cell Global Identifiers (NCGIs), section 0202; noted, target cell can be a cell served by wireless access node, section 0144).
Regarding claim 9 (Original), Ischii discloses the method according to claim 1, wherein the XnAP mobility related response message further comprises at least one child distributed unit (DU) cell configuration, comprising at least one of: an gNB-CU UE F1AP ID (see, IAB-donor may comprise at least one Central Unit (CU) that may also be an interface to the core network behaving as a RAN base station (e.g., eNB or gNB), section 0112); a gNB-DU UE F1AP ID (see, IAB-donor may comprise at least one Central Unit (CU) that is a logical entity managing the DU collocated in the IAB-donor as well as the remote DUs resident in the IAB-nodes, section 0112; noted, cell may broadcast a node identification, such as gNB-DU ID per 3GPP, section 01249); an old Cell Global Identifier (CGI) (see, IAB-donor wireless access node can include cell/node identities that can include NR Cell Global Identifiers (NCGIs), section 0202; noted, target cell can be a cell served by wireless access node, section 0144); a gNB-DU Cell Resource Configuration (see, cell may broadcast a node identification, such as gNB-DU ID, 0249); IAB STC Information; a Random Access Channel (RACH) configuration (see, IAB-node, e.g., child IAB-node, may follow the same initial access procedure as a UE, including cell search, system information acquisition, and random access; noted, the system provide for capabilities needed to use the broadcast channel for carrying information bit(s) (on the physical channels) and provide access to the core network, section 0110); a Channel State Information Reference Signal/Scheduling Request (CSI-RS/SR) Configuration; a Physical Downlink Control Channel (PDCCH) Configuration System Information Block 1 (SIB1) (see, indication transmitted from IAB-node may be carried by physical layer signaling, e.g., such as PDCCH, section 0287); Subcarrier Spacing (SCS) Common (see, the spacing of subcarriers of symbols, section 0103); or Multiplexing Information (see, IAB may be multiplexed in time, frequency, and/or space, section 0006).
Regarding claim 12 (Original), Ischii discloses the method according to claim 1, further comprising: sending, by the source donor CU to the wireless node, trigger information to trigger the wireless node to migrate to the target donor CU (see, identity of the child node may comprise the Physical Cell ID (PCI) of the old serving cell, e.g., the cell served by IAB-node, section 0285; noted, the message flow from source donor node to target donor node, section 0282).
Regarding claim 26 (Original), Ischii discloses the method according to claim 1, further comprising: sending, by the source donor CU to the target donor CU (see, two donor nodes (CUs) are inter-connected by inter-node protocols such as Xn Application Protocol (XnAP) to select a cell and move it to its suitable location, section 0269), a communication setup request message (see, XnAP HANDOVER REQUEST messages being met with respective HANDOVER REQUEST ACKNOWLEDGEMENT messages, section 0264; noted, donor IAB nodes can receive a response after a request, sections 0268-0271); and receiving, by the source donor CU from the target donor CU, a communication setup response message (see, XnAP HANDOVER REQUEST messages being met with respective HANDOVER REQUEST ACKNOWLEDGEMENT messages, section 0264; noted, donor IAB nodes can receive a response after a request, sections 0268-0271; noted, IAB-node may send a RRCSetupRequest, followed by reception of an RRCSetup and transmission of RRCSetupComplete, 0121).
Regarding claim 33 (Currently Amended), Ischii discloses a method comprising: receiving, by a target donor central unit (CU) from a source donor CU (see, the source or source donor node may transfer its contexts to the target or target donor node upon the parent IAB-node's inter-CU re-establishment, section 0282), an XnAP mobility related request message (see, XnAP HANDOVER REQUEST messages being met with respective HANDOVER REQUEST ACKNOWLEDGEMENT messages, section 0264; noted, donor IAB nodes can receive a response after a request, sections 0268-0271) requesting migration of a wireless node (section 0284-XnAP handover request messages, section 0284) from the source donor CU to the target donor CU (see, two donor nodes (CUs) are inter-connected by inter-node protocols such as Xn Application Protocol (XnAP) to select a cell and move it to its suitable location, section 0269); wherein migration of the wireless node is triggered by the wireless node based on a threshold information received from the source donor CU; and sending, by the target donor CU to the source donor CU, an XnAP mobility related response message in response to receiving the XnAP mobility related request message (see, XnAP HANDOVER REQUEST messages being met with respective HANDOVER REQUEST ACKNOWLEDGEMENT messages, section 0264; noted, donor IAB nodes can receive a response after a request, sections 0268-0271).
Ischii discloses all the claim limitations as set forth above but fails to explicitly disclose: wherein migration of the wireless node is triggered by the wireless node based on a threshold information received from the source donor CU; and sending, by the target donor CU to the source donor CU, an XnAP mobility related response message in response to receiving the XnAP mobility related request message (see, XnAP HANDOVER REQUEST messages being met with respective HANDOVER REQUEST ACKNOWLEDGEMENT messages, section 0264; noted, donor IAB nodes can receive a response after a request, sections 0268-0271).
However Xu ‘905 from a similar field of endeavor discloses: wherein migration of the wireless node is triggered by the wireless node based on a threshold information received from the source donor CU (see, the DU may determine that it needs to switch from the source CU to the target CU if the distance between the DU and the source CU exceeds a threshold value, section 0053 Xu ‘905; noted, if the radio condition or quality of the interface is below a threshold value, the DU may determine that the CU switch is needed, section 0053 Xu ‘905; noted, where the DU is located may have means for measurements and may measure the radio link quality to both source CU and target CU and trigger the switch when the target CU radio link becomes better than the source CU radio link, section 0053 Xu ‘905); and sending, by the target donor CU to the source donor CU, an XnAP mobility related response message in response to receiving the XnAP mobility related request message.
In view of the above, it would have been obvious before the effective filling date of the claim invention to a person having ordinary skill in the art of which the claimed invention pertains to modify the network of Ischii with the triggering of a switch after a threshold value as taught by Xu ‘905. The motivation would have been to transmit identity information of a target CU/DU to the source CU for the CU switch.
Regarding claim 34 (Original), Ischii discloses the method according to claim 33, wherein the XnAP mobility related request message (see, XnAP HANDOVER REQUEST messages being met with respective HANDOVER REQUEST ACKNOWLEDGEMENT messages, section 0264; noted, donor IAB nodes can receive a response after a request, sections 0268-0271) comprises at least one of the following: at least one identity of one or more wireless nodes or user equipment (UE) that are to migrate from the source donor CU to the target donor CU (see, identity of the child node may comprise the Physical Cell ID (PCI) of the old serving cell, e.g., the cell served by IAB-node, section 0285; noted, the message flow from source donor node to target donor node, section 0282); gNB-DU System Information (see, cell may broadcast a node identification such as gNB-DU ID, section 0249); gNB-DU Cell Resource Configuration configured by the source donor CU (see, protocol stack configuration for the plane between an IAB-node directly connected to the IAB-donor where CU component is part of the IAB-donor and CU/IAB-donor to control the DU component resident in the IAB-node, sections 0112-0119; noted, cell may broadcast a node identification such as gNB-DU ID, section 0249); Integrated access and backhaul (IAB) Synchronization Signal Block (SSB) Transmission Configuration (STC) Information configured by the source donor CU (IAB-nodes may need to periodically perform inter-IAB-node discovery to detect new IAB-nodes in their vicinity based on cell-specific reference signals, e.g., Synchronization Signal and PBCH block SSB) where packets may be carried or broadcasted on the Master Information Block (MIB) section, section 0007; noted, child node may store the identification of the cell that transmits the Backhaul RLF Indication where the child node uses Synchronization Signal Block (SSB) and Master Information Block (MIB), section 0233); Multiplexing Information of wireless node (see, the system of relay nodes may utilize the same 5G radio access technologies and connections to the core network (backhaul link) simultaneously. These radio links may be multiplexed in time, frequency, and/or space. This system may be referred to as Integrated Access and Backhaul (IAB), section 0006); or indication information that indicates migration of the wireless node from the source donor CU to the target donor CU is complete (see, XnAP HANDOVER REQUEST messages being met with respective HANDOVER REQUEST ACKNOWLEDGEMENT messages, section 0264; noted, two donor nodes (CUs) are inter-connected by inter-node protocols such as Xn Application Protocol (XnAP), section 0269).
Regarding claim 44 (Original), Ischii discloses the method according to claim 33, further comprising: receiving, by the target donor CU from the source donor CU, a communication setup request message (see, two donor nodes (CUs) are inter-connected by inter-node protocols such as Xn Application Protocol (XnAP) to select a cell and move it to its suitable location, section 0269); and sending, by the target donor CU to the source donor CU, a communication setup response message (see, XnAP HANDOVER REQUEST messages being met with respective HANDOVER REQUEST ACKNOWLEDGEMENT messages, section 0264; noted, donor IAB nodes can receive a response after a request, sections 0268-0271; noted, IAB-node may send a RRCSetupRequest, followed by reception of an RRCSetup and transmission of RRCSetupComplete, 0121).
Regarding claim 75 (Currently Amended), Ischii discloses a source donor central unit comprising: a processor; and a non-transient memory in communication with the processor, the memory storing a plurality of instructions (see, donor IAB node may comprise context memory, which may store context information for the IAB-nodes and grand-children nodes, section 0282) that, when executed by the processor, configure the processor to: send to a target donor CU, an XnAP mobility related request message (see, XnAP HANDOVER REQUEST messages being met with respective HANDOVER REQUEST ACKNOWLEDGEMENT messages, section 0264; noted, donor IAB nodes can receive a response after a request, sections 0268-0271) requesting migration (section 0284-XnAP handover request messages, section 0284) of a wireless node from the source donor CU to the target donor CU (see, two donor nodes (CUs) are inter-connected by inter-node protocols such as Xn Application Protocol (XnAP) to select a cell and move it to its suitable location, section 0269); send, by the source donor CU to the wireless node, a threshold information for the wireless node to determine triggering migration from the source donor CU to the target donor CU and to establish a connection with the target donor CU; and receive from the target donor CU, an XnAP mobility related response message in response to sending the XnAP mobility related request message (see, XnAP HANDOVER REQUEST messages being met with respective HANDOVER REQUEST ACKNOWLEDGEMENT messages, section 0264; noted, donor IAB nodes can receive a response after a request, sections 0268-0271).
Ischii discloses all the claim limitations as set forth above but fails to explicitly disclose: send, by the source donor CU to the wireless node, a threshold information for the wireless node to determine triggering migration from the source donor CU to the target donor CU and to establish a connection with the target donor CU; and receive from the target donor CU, an XnAP mobility related response message in response to sending the XnAP mobility related request message (see, XnAP HANDOVER REQUEST messages being met with respective HANDOVER REQUEST ACKNOWLEDGEMENT messages, section 0264; noted, donor IAB nodes can receive a response after a request, sections 0268-0271).
However Xu ‘905 from a similar field of endeavor discloses: send, by the source donor CU to the wireless node, a threshold information for the wireless node to determine triggering migration from the source donor CU to the target donor CU (see, the DU may determine that it needs to switch from the source CU to the target CU if the distance between the DU and the source CU exceeds a threshold value, section 0053 Xu ‘905; noted, if the radio condition or quality of the interface is below a threshold value, the DU may determine that the CU switch is needed, section 0053 Xu ‘905; noted, where the DU is located may have means for measurements and may measure the radio link quality to both source CU and target CU and trigger the switch when the target CU radio link becomes better than the source CU radio link, section 0053 Xu ‘905) and to establish a connection with the target donor CU (see, a first message comprises identity information of the target CU and identity information of the DU to be used by the DU after it connects to target CU, section 0056 Xu ‘905); and receive from the target donor CU, an XnAP mobility related response message inresponse to sending the XnAP mobility related request message.
In view of the above, it would have been obvious before the effective filling date of the claim invention to a person having ordinary skill in the art of which the claimed invention pertains to modify the network of Ischii with the triggering of a switch after a threshold value as taught by Xu ‘905. The motivation would have been to transmit identity information of a target CU/DU to the source CU for the CU switch.
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Ishii et al. US 20230098848 A1 (Domestic Priority February 12, 2020) in view of Xu et al. US 20220182905 A1 (Domestic Priority January 29, 2019), and in view of Malkamaki et al. US 20200015147 A1 (Domestic Priority July 18, 2019).
The combination of Ischii and Xu ‘905 discloses all the claim limitations as set forth above but fails to explicitly disclose: Regarding claim 4 (Original), the method according to claim 1, wherein the XnAP mobility related request message comprises at least one of the following: at least one identity of one or more parent wireless nodes of the wireless node; at least one identity of one or more child wireless nodes or UE of the wireless node; at least one identity of one or more mobile terminal (MT) parts collocated with a distributed unit (DU) parts of the wireless node; or at least one identity of one or more serving wireless nodes.
However Malkamaki from a similar field of endeavor discloses: the method according to claim 1, wherein the XnAP mobility related request message (see, the receiving of the UE/IAB node context modification request from a Donor gNB-CU for handover, section 0042 Malkamaki) comprises at least one of the following: at least one identity of one or more parent wireless nodes of the wireless node (see, the use of parent node of the source IAB node, section 0033 Malkamaki; noted, IAB nodes transferred data over wireless self-backhauling links, section 0005 Malkamaki); at least one identity of one or more child wireless nodes or UE of the wireless node (see, the use of child node of IAB node from where UL data was received, section 0033 Malkamaki; noted, IAB nodes transferred data over wireless self-backhauling links, section 0005 Malkamaki); at least one identity of one or more mobile terminal (MT) parts collocated with a distributed unit (DU) parts of the wireless node (see, UE-serving integrated access and backhaul (IAB) node may contain both DU part and MT parts, section 0048 Malkamaki); or at least one identity of one or more serving wireless nodes (see, the use of Donor gNB-DU (or Donor gNB) and UE serving IAB node as end points, section 0023 Malkamaki).
In view of the above, it would have been obvious before the effective filling date of the claim invention to a person having ordinary skill in the art of which the claimed invention pertains to modify the combination of Ischii and Xu ‘905 with the identity of nodes as taught by Malkamaki. The motivation would have been to improve current techniques for connecting autonomously to other network entities.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Ishii et al. US 20230098848 A1 (Domestic Priority February 12, 2020) in view of Xu et al. US 20220182905 A1 (Domestic Priority January 29, 2019), and in view of Barac et al (US 2023/0232285 A1).
The combination of Ischii and Xu ‘905 discloses all the claim limitations as set forth above but fails to explicitly disclose: Regarding claim 7 (Original), the method according to claim 1, wherein the XnAP mobility related response message comprises at least one of the following: a BAP address allocated by the target donor CU; an IP address allocated by the target donor CU or the target donor DU; traffic mapping information, including at least one of a Prior-Hop Backhaul Adaptation Protocol (BAP) Address, an Ingress backhaul (BH) Radio Link Control (RLC) Channel (CH) ID, a Next-Hop BAP Address, or an Egress BH RLC CH ID; a gNB distributed unit (DU) Cell Resource Configuration configured by the target donor CU; Integrated access and backhaul (IAB) Synchronization Signal Block (SSB) Transmission Configuration (STC) Information configured by the target donor CU; one or more old BAP address of a child IAB node; one or more old BAP address of a parent IAB node; one or more new BAP address of the child IAB node configured by the target donor CU; or one or more new BAP address of the parent IAB node configured by the target donor CU.
However Barac from a similar field of endeavor discloses: the method according to claim 1, wherein the XnAP mobility related response message comprises at least one of the following: a BAP address allocated by the target donor CU (see, IAB nodes includes context such as BAP configuration such as BAP address, 0139 Barac; noted, the handover the IAB node to a target donor-CU based on the load conditions of the source donor-CU, section 0133 Barac); an IP address allocated by the target donor CU or the target donor DU (see, allocation of IP address for IAB-node based on the donor-CU and intra-donor DU, sections 0042-0044 Barac); traffic mapping information, including at least one of a Prior-Hop Backhaul Adaptation Protocol (BAP) Address (see, IAB nodes includes context such as BAP configuration such as BAP address, 0139 Barac; noted, the resources available at the parent target node for the migrating IAB node and any intermediate nodes between the target donor CU and the parent target node include the case of multiple hops between the parent node and the target gNB-CU, section 0082 Barac; noted, multi-hop backhauling, section 0011 Barac), an Ingress backhaul (BH) Radio Link Control (RLC) Channel (CH) ID (see, e 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, section 0060 Barac), a Next-Hop BAP Address (see, BAP sublayer routing of packets to next hop, section 0033 Barac), or an Egress BH RLC CH ID (see, determination of egress backhaul (BH) RLC channels for packets routed to next hop, sections 0033-0039 Barac); a gNB distributed unit (DU) Cell Resource Configuration configured by the target donor CU (see, IAB-MT sends a Measurement Report message to the source parent node gNB-DU based on a Measurement Configuration the migrating IAB-MT received from the IAB-donor-CU, section 0050 Barac); Integrated access and backhaul (IAB) Synchronization Signal Block (SSB) Transmission Configuration (STC) Information configured by the target donor CU (see, IAB-MT sends a Measurement Report message to the source parent node gNB-DU based on a Measurement Configuration the migrating IAB-MT received from the IAB-donor-CU, section 0050 Barac); one or more old BAP address of a child IAB node (see, identity of the parent node the IAB node, i.e. the parent node's BAP address(es), section 0139 Barac; noted, secondary node BAP address, sections 0213-0214 Barac); one or more old BAP address of a parent IAB node (see, identity of the parent node the IAB node, i.e. the parent node's BAP address(es), section 0139 Barac); one or more new BAP address of the child IAB node configured by the target donor CU (see, handover an IAB node to a target cell that belongs to the target Donor-CU based on source donor, section 0133 Barac; noted, secondary node BAP address, sections 0213-0214 Barac); or one or more new BAP address of the parent IAB node configured by the target donor CU (see, identity of the parent node the IAB node, i.e. the parent node's BAP address(es), section 0139 Barac; noted, handover an IAB node to a target cell that belongs to the target Donor-CU based on source donor, section 0133 Barac).
In view of the above, it would have been obvious before the effective filling date of the claim invention to a person having ordinary skill in the art of which the claimed invention pertains to modify the combination of Ischii and Xu ‘905 with the use of BAP as taught by Barac. The motivation would have been to improve current techniques for handling communication in a wireless communications network.
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Ishii et al. US 20230098848 A1 (Domestic Priority February 12, 2020) in view of Xu et al. US 20220182905 A1 (Domestic Priority January 29, 2019), and in view of Adjakple et al. US 20210282050 A1 (Domestic Priority June 20, 2018).
The combination of Ischii and Xu ‘905 discloses all the claim limitations as set forth above but fails to explicitly disclose: Regarding claim 11 (Original), the method according to 10, further comprising: sending, by the source donor CU to the wireless node, the threshold information via a Radio Resource Control (RRC) message.
However Adjakple from a similar field of endeavor discloses: the method according to 10, further comprising: sending, by the source donor CU to the wireless node, the threshold information via a Radio Resource Control (RRC) message (see, threshold may be configured into the UE by RRC configuration between the UE and the IAB-donor CU, section 0071-0076 Adjakple).
In view of the above, it would have been obvious before the effective filling date of the claim invention to a person having ordinary skill in the art of which the claimed invention pertains to modify the combination of Ischii and Xu ‘905 with the use of RRC configurations as taught by Adjakple. The motivation would have been to improve current techniques for handling flow control options.
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Ishii et al. US 20230098848 A1 (Domestic Priority February 12, 2020) in view of Xu et al. US 20220182905 A1 (Domestic Priority January 29, 2019), and in view of Hampel et al. US 20210321467 A1 (Domestic Priority April 8, 2020).
The combination of Ischii and Xu ‘905 discloses all the claim limitations as set forth above but fails to explicitly disclose: Regarding claim 14 (Original), the method according to claim 1, further comprising: receiving, by the source donor CU from the wireless node, a request for an Internet Protocol (IP) address of at least one of the wireless node or the target donor CU; and sending, by the source donor CU to the wireless node, the IP address of the at least one of the wireless node or the target donor CU in response to receiving the request for the IP address.
However Hampel from a similar field of endeavor discloses: the method according to claim 1, further comprising: receiving, by the source donor CU from the wireless node, a request for an Internet Protocol (IP) address of at least one of the wireless node or the target donor CU (see, request message for IP address information from RAN node, sections 0224-0227 Hampel); and sending, by the source donor CU to the wireless node, the IP address of the at least one of the wireless node or the target donor CU in response to receiving the request for the IP address (see, IAB donor CU sends an indication of its support of the LTE and X2 path in an X2AP message such as an acknowledgement message where this message may include IP address information, section 0118 Hampel).
In view of the above, it would have been obvious before the effective filling date of the claim invention to a person having ordinary skill in the art of which the claimed invention pertains to modify the combination of Ischii and Xu ‘905 with the use of IP addresses as taught by Hampel. The motivation would have been to improve current techniques for handling signaling connections in wireless communications.
Claims 20, 32, and 50 are rejected under 35 U.S.C. 103 as being unpatentable over Ishii et al. US 20230098848 A1 (Domestic Priority February 12, 2020) in view of Xu et al. US 20220182905 A1 (Domestic Priority January 29, 2019), and in view of Xu et al. US 20230284246 A1 (Domestic Priority August 5, 2020).
The combination of Ischii and Xu ‘905 discloses all the claim limitations as set forth above but fails to explicitly disclose: Regarding claim 20 (Original), the method according to claim 1, further comprising: receiving, by the source donor CU from the wireless node, a communication setup request message; and sending, by the source donor CU to the wireless node, a communication setup response message.
However Xu ‘246 from a similar field of endeavor discloses: the method according to claim 1, further comprising: receiving, by the source donor CU from the wireless node, a communication setup request message (see, IAB-donor-CU may migrate the F1-U tunnels it has with the IAB node from the first path to the second path via the UE CONTEXT MODIFICATION REQUEST message, section 0071 Xu ‘246); and sending, by the source donor CU to the wireless node, a communication setup response message (see, IAB node replies with a UE CONTEXT MODIFICATION RESPONSE message to the IAB-donor-CU, section 0072 Xu ‘246).
In view of the above, it would have been obvious before the effective filling date of the claim invention to a person having ordinary skill in the art of which the claimed invention pertains to modify the combination of Ischii and Xu ‘905 with the use of F1 application protocol as taught by Xu ‘246. The motivation would have been to improve current techniques for reducing topology redundancy.
The combination of Ischii and Xu ‘905 discloses all the claim limitations as set forth above but fails to explicitly disclose: Regarding claim 32 (Original), the method according to claim 1, further comprising: sending, by the source donor CU to the target donor CU, a second XnAP message comprising a first F1AP message encapsulated in the second XnAP message, wherein an RRCreconfiguration message is encapsulated in the first F1AP message.
However Xu ‘246 from a similar field of endeavor discloses: the method according to claim 1, further comprising: sending, by the source donor CU to the target donor CU, a second XnAP message comprising a first F1AP message encapsulated in the second XnAP message (see, first device may transmit to the second device an XnAP message that includes a request for setup of the context of the third device, section 0089 Xu; noted, first device transmits the context in a radio resource control (RRC) message or an F1 application protocol (F1AP) message to the third device, section 0093 Xu ‘246), wherein an RRCreconfiguration message is encapsulated in the first F1AP message (see, first device transmits the context in an RRC message (for example, an RRCReconfiguration message) or an F1AP message, section 0093 Xu ‘246).
In view of the above, it would have been obvious before the effective filling date of the claim invention to a person having ordinary skill in the art of which the claimed invention pertains to modify the combination of Ischii and Xu ‘905 with the use of F1 application protocol as taught by Xu ‘246. The motivation would have been to improve current techniques for reducing topology redundancy.
The combination of Ischii and Xu ‘905 discloses all the claim limitations as set forth above but fails to explicitly disclose: Regarding claim 50 (Original), the method according to claim 33, further comprising: receiving, by the target donor CU from the source donor CU, a second XnAP message comprising a first F1AP message encapsulated in the second XnAP message, wherein an RRCreconfiguration message is encapsulated in the first FlAP message; encapsulating, by the target donor CU, the first F1AP message in a first message; and sending, by the target donor CU to the first wireless node, the first message.
However Xu ‘246 from a similar field of endeavor discloses: the method according to claim 33, further comprising: receiving, by the target donor CU from the source donor CU, a second XnAP message comprising a first F1AP message encapsulated in the second XnAP message (see, first device may transmit to the second device an XnAP message that includes a request for setup of the context of the third device, section 0089 Xu; noted, first device transmits the context in a radio resource control (RRC) message or an F1 application protocol (F1AP) message to the third device, section 0093 Xu ‘246), wherein an RRCreconfiguration message is encapsulated in the first F1AP message (see, first device transmits the context in an RRC message (for example, an RRCReconfiguration message) or an F1AP message, section 0093 Xu ‘246); encapsulating, by the target donor CU, the first FlAP message in a first message; and sending, by the target donor CU to the first wireless node, the first message (see, IAB-donor-CU sends the UE CONTEXT SETUP REQUEST message to the second-path IAB-donor-DU to create the UE context for the IAB node, section 0062 Xu ‘246).
In view of the above, it would have been obvious before the effective filling date of the claim invention to a person having ordinary skill in the art of which the claimed invention pertains to modify the combination of Ischii and Xu ‘905 with the use of F1 application protocol as taught by Xu ‘246. The motivation would have been to improve current techniques for reducing topology redundancy.
Conclusion
THIS ACTION IS MADE FINAL. 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 PATRICK YIPAO PEI whose telephone number is (703)756-1890. The examiner can normally be reached Monday - Friday 9:30 AM to 5:30 PM ET.
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, Kwang Yao can be reached at (571) 272-3182. 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.
/PATRICK YIPAO PEI/Examiner, Art Unit 2473
/KWANG B YAO/Supervisory Patent Examiner, Art Unit 2473
Prosecution Insights