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 .
Response to Arguments
Applicant’s arguments with respect to claim(s) 10, 12-14, 20, and 22-24 have been considered but are moot in view of the new ground(s) of rejection set forth.
The rejection of claims 15-19 and 25-29 under 35 U.S.C. § 112(b) have been withdrawn.
Applicant's arguments filed October 24 2025 have been fully considered but they are not persuasive. In regards to the applicants arguments, the examiner respectfully disagrees with certain arguments presented by the applicant. In regards to the applicants arguments regarding the amended claim features in independent claims 10 and 20 of “transmitting, to a second node, a downlink radio resource control (RRC) message including configuration information on at least one internet protocol (IP) address for the second node” and “receiving, from the second node, a second UL RRC message including an integrated access and backhaul (IAB) node indication indicating that the second node is an IAB node”, a new ground(s) of rejection has been set forth for the claim features. Therefore applicants arguments with respect to the claim features are considered moot.
However, in regards to the applicants arguments regarding the claim features of “receiving, from the second node, a second UL RRC message including an IAB node indication indicating that the second node is an IAB node”, and “transmitting, to a third node, a handover request message including the IAB node indication for indicating a handover request is for the IAB node”, the examiner respectfully disagrees as at least the combined teachings of Hampel in view of Sivakeesar discloses such claim features.
For example, in regards to the applicants arguments on (Pg.’s 6-7 of the remarks) with respect to the teachings of Sivavakeesar, the applicant argues that Sivavakeesar teachings of relay type/capability and handover signaling between source and target D-eNBs does not teach an integrated access and backhaul (IAB) node and that Sivavakeesar’s UL RRC message using a “modified UE capability container” indicating relay type and not indicating that the second node is an IAB node (i.e., Pg. 7 of the remarks). However the rejection is an obviousness rejection under 35 USC 103(a), and the applicant is arguing the teachings of Sivavakeesar individually for not disclosing the claim feature of “receiving, from the second node, a second UL RRC message including an IAB node indication indicating that the second node is an IAB node” when the combined teachings of Hampel in view of Sivavakeesar would arrive to the claim feature.
In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
For example, the teachings of Hampel discloses the second node is an IAB node which is a type of relay node (see Para’s [0038-0040] & [0067-0069]), but does not disclose the second node signaling an indication indicating its type in a second UL RRC message and the first node transmitting, to a third node, a handover request message including the indication for indicating a handover request is for the second node. However the claim features would be rendered obvious in view of Sivavakeesar (Of Record).
For example Sivavakeesar discloses the second node (see Fig. 3 i.e., relay) signaling an indication indicating its type in a UL RRC message (see Para’s [0053] i.e., it is important when a relay node (RN) attaches to D-eNB (i.e., “first node”) or is handed over from one D-eNB to another that the relevant D-eNB (i.e., “first node”) can readily ascertain the RN’s type), [0062] i.e., it is important for a D-eNB to decide on the relay node type at the time of relay attachment (i.e., relay type is indicated to a first D-eNB during attachment to the first D-eNB) or relay handover, [0066] i.e., For attachment of RNs to a D-eNB, there are two methods to inform the type of a mobile relay to any possible eNB (i.e., “first node”) that has the D-eNB capabilities. The first is to let the RN 14 inform its relay type to the D-eNB 12 using a modified UE capability container (a modified UE capability container (i.e., UE capability container is part of an RRC message and therefore an UL RRC message indicating the relay type) is part of the UE capability transfer procedure), & [0068] i.e., when the RN has cause to attach to the wireless telecommunications network, either 1) it communicates its type to the D-eNB (base station))
and the first node (see Fig. 3 i.e., source DeNB) transmitting, to a third node, a handover request message including the indication for indicating a handover request is for the second node (see Fig. 3 i.e., 4. Handover Request & Para’s [0041] i.e., when handover is required, said first base station sends a handover request to the second base station of information pertaining to the handover, including information regarding the relay nodes type, [0053-0056], [0062] i.e., it is important for a D-eNB to decide on the relay node type at the time of relay attachment or relay handover, [0064] i.e., target D-eNB 12 to ascertain the relay type before it can decide whether or not it can support the relay to be handed over, [0065] i.e., This requires the target D-eNB needs to be notified of the mobile relay type and/or its capabilities, [0069] i.e., For mobile relay handover, it is appropriate for the source D-eNB 10 to pass the relay type onto the target D-eNB 12 (i.e., “third node”)…The appropriate timing for such an operation to take place is when the handover request command is issued. Hence, the type of the mobile relay and/or its capability details can be included as part of Handover request parameters and notified to the target D-eNB 12 (i.e., “third node”), [0070-0072] i.e., The relay node is connected to the first base station such that, when handover is required, said first base station sends a handover request to the second base station (i.e., “third node”) of information pertaining to the handover, including information regarding the relay nodes type and/or a given relay’s capability details, & [0079] i.e., The source D-eNB issues a HANDOVER REQUEST message to the target D-eNB (i.e., “third node”) passing necessary information to prepare the handover at the target side (relay type and/or a capability container), & [0087]).
(Sivavakeesar suggests it is important that when the relay node is handed over, the target D-eNB can readily ascertain the RN’s type and capability so the target D-eNB can decide whether or not it can support the relay to be handed over and for configuring the required resources for the handover in order to achieve successful handover for the relay node to the target D-eNB, (see Para’s [0064], [0070-0072], & [0081])).
Therefore it would be obvious to one of ordinary skill in the art for the IAB relay node which is a type of relay node as disclosed in Hampel to signal its type according to the teachings of Sivavakeesar who discloses the second node (i.e., relay) signaling an indication indicating its type in a UL RRC message to a first node (i.e., source DeNB) for transmitting, to a third node (i.e., target DeNB), a handover request message including the indication for indicating a handover request is for the second node, which results in the indication being an IAB node indication indicating the IAB relay node, because the motivation lies in Sivavakeesar that it is important that when the relay node is handed over, the target D-eNB can readily ascertain the RN’s type and capability so the target D-eNB can decide whether or not it can support the relay to be handed over and for configuring the required resources for the handover in order to achieve successful handover for the relay node to the target D-eNB.
Based on the combined teachings of Hampel in view of Sivavakeesar, the signaling of the relay type from the relay to the source base station (Sivavakeesar, Fig. 3 & Para’s [0053], [0062], [0066], & [0068]) will result in being an IAB node indication indicating the relay node is an IAB node and the handover request from the source base station to the target base station (Sivavakeesar, see Para’s [0041], [0053-0056], [0062], [0065], [0069-0072], & [0079]) will include the IAB node indication.
For the reasons explained, the combination of Hampel in view of Sivavakeesar discloses the claim features in claims 10 and 20 of “receiving, from the second node, a second UL RRC message including an IAB node indication indicating that the second node is an IAB node”, and “transmitting, to a third node, a handover request message including the IAB node indication for indicating a handover request is for the IAB node”.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 10 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Hampel US (2019/0053317) in view of Bales et al. USP (10,148,340), and further in view of Xu et al. US (2021/0409328), and further in view of Sivavakeesar US (2014/0301370).
Regarding Claim 10, Hampel discloses a method performed by a first node (see Fig. 3B i.e., access node that includes DU-1 370, CU-U 365, and CU-C 360 & Para [0067] i.e., The L2-relay 375 connects to an access node (e.g., a base station of a gNB) (i.e., access node may be a “first node”)) in a wireless communication system (see Fig. 3B), the method comprising: receiving, from a second node (see Fig. 3B i.e., relay 375 (i.e., “second node”)), a first uplink (UL) message for establishing an F1 connection (see Para’s [0041], [0067] i.e., L2 relay 375 may be used to establish wireless backhauling or wireless fronthauling. The L2-relay 375 connects to an access node (e.g., a base station or a gNB) in a similar manner as a UE established a wireless connection (i.e., establishing connection between the relay 375 and the base station involves signaling exchange which includes an uplink message from the relay for establishing the connection), [0068] i.e., the relay 375 may support RRC functionality to connect to the access node that includes DU-1 370, CU-U 365 and CU-C 360, [0069] i.e., the relay 375 supports a fronthaul control connection 390 between the DU-2 385 and CU-C 360, which may be referred to as F1-C in the CU/DU split architecture (i.e., F1-C connection between the DU-2 385 of the relay 375 and the CU-C 360 of the base station may be established based on signaling exchange which includes an uplink message from the relay for establishing the F1-C connection). A user plane connection 395 may also be supported between DU-2 385 and CU-U 365, [0077] i.e., F1-C messages 620 over RRC may be exchanged between DU-2 at the relay 605 and the CU-C, & [0091] i.e., the relay may then launch DU-2…and at block 1075 may establish F1-C with CU-C via SRB-B 1070)
a distributed unit (DU) of the second node (see Fig. 3B i.e., Du-2 385 of relay node 375 & Para [0069] i.e., the relay 375 uses its DU, referred to as DU-2 385 in Fig. 3B… i.e., the relay 375 supports a fronthaul control connection 390 between the DU-2 385 and CU-C 360, which may be referred to as F1-C in the CU/DU split architecture)
the second node is an integrated access and backhaul (IAB node), (see Fig. 3B i.e., relay node 375 & Para’s [0038] systems that use integrated access/backhaul (IAB) through a relay & [0039-0040] i.e., When using a CU/DU architecture for IAB, one or more relays may relay access data, backhaul data, or combinations & [0067-0069])
establishing an F1 connection between the DU of the second node and a central unit (CU) of the first node, (see Fig. 3B i.e., F1 connection 390 & Para [0069] i.e., the relay 375 supports a fronthaul control connection 390 between the DU-2 385 and CU-C 360, which may be referred to as F1-C in the CU/DU split architecture, [0072], [0077], & [0091] i.e., the relay may then launch DU-2…and at block 1075 may establish F1-C with CU-C via SRB-B 1070)
Hampel does not disclose the claim feature of transmitting, to a second node, a downlink (DL) radio resource control (RRC) message including configuration information on at least on internet protocol (IP) address for the second node. However the claim feature would be rendered obvious in view of Bales et al. USP (10,148,340).
Bales discloses transmitting by a base station (see Fig. 6 i.e., base station), to a second node (see Fig. 6 i.e., wireless relay), a downlink (DL) radio resource control (RRC) message (see Fig. 6 i.e., Relay RRC message transmitted from base station to wireless relay) including configuration information on at least on internet protocol (IP) address for the second node (see Fig. 6 & Col. 6 lines 11-36 i.e., Fig. 6 illustrates wireless relay attachment in multi-core LTE network 400…The R-PGW also issues an IP address (IPR) to the wireless relay. The R-PGW returns an S5 session response having the relays QCIs and IP address to the R-SGW…The wireless base station transfers an RRC service response (i.e., “downlink RRC message”) having the relay QCIs and IP address to the wireless relay. The wireless relay may now exchange R/R S1-MME signaling with the R-MME and may also exchange (R/UE) S1-MME signaling with the UE-MME).
(Bales suggests the base station transmits the downlink RRC service response message including wireless relays IP address in order for the wireless relay to successfully perform the attachment to the network and in order for the wireless relay to begin communication with the network, (see Fig. 6 & Col. 6 lines 11-36)).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the second node such as the relay node which establishes a connection with the first node such as the base station as disclosed in Hampel to include transmitting, by the base station to the relay node, a downlink (DL) radio resource control (RRC) message including configuration information on at least on internet protocol (IP) address for the relay node as disclosed in the teachings of Bales, because the motivation lies in Bales that the base station transmits the downlink RRC service response message including wireless relays IP address in order for the wireless relay to successfully perform the attachment to the network and in order for the wireless relay to begin communication with the network.
While Hampel discloses receiving, from the second node, a first uplink message for establishing the F1 connection between the DU of the second node and the CU of the first node (see Fig. 3B, Fig. 6 & Para’s [0041], [0067-0069], [0072], [0077], & [0091]), the combination of Hampel in view of Bales does not disclose the claim features of receiving from the second node such as the relay node, a first uplink message including information on an IP address for a distributed unit (DU) of the second node and establishing the F1 connection between the DU of the second node and the central unit (CU) of the first node, based on the IP address for the DU of the second node. However the claim features would be rendered obvious in view of Xu et al. US (2021/0409328).
Xu discloses receiving, by a first node (see Fig. 4 i.e., Donor-CU 110-11), a first uplink message including information on an IP address for a distributed unit (DU) (see Fig. 4 i.e., Donor-DU 110-12) of a second node (see Fig. 4 & Para [0095] i.e., As shown in Fig. 4, the Donor-DU 110-12 transmits 410 a F1AP message to the Donor-CU 110-11. In one example, the F1AP message may be a F1 setup request message. In addition, the message comprises an IPV6 prefix of the Donor-DU).
and establishing the F1 connection between the DU of the second node and the central unit (CU) of the first node (see Para [0095] i.e., the Donor-DU transmits 410 a F1AP message which may be a F1 setup request message (i.e., F1 setup request message is used for establishing the F1 connection between the DU and the CU)), based on the IP address for the DU of the second node (see Fig. 4 & Para’s [0095-0098] i.e., As shown in Fig. 4, the Donor-DU 110-12 transmits 410 a F1AP message to the Donor-CU 110-11. In one example, the F1AP message may be a F1 setup request message. In addition, the message comprises an IPV6 prefix of the Donor-DU).
(Xu suggests the donor-DU transmits the F1 setup request message to the Donor-CU for successfully establishing the F1 connection between the DU and the CU in order to perform data communications between an IAB node, the DU and the CU (see Para’s [0086] & [0095-0098])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the F1 connection established between the DU part of the relay node and the CU of the base station which is based on an uplink signaling message from the relay node to the base station as disclosed in Hampel in view of Bales to be established based on receiving, from the relay node a first uplink message including information on an IP address for the DU of the relay node based on the teachings of Xu who discloses receiving, by a first node, a first uplink message such as a F1 setup request including information on an IP address for a distributed unit (DU) of a second node for establishing the F1 connection between the DU and the CU, because the motivation lies in Xu that the donor-DU transmits the F1 setup request message to the Donor-CU for successfully establishing the F1 connection between the DU and the CU in order to perform data communications between an IAB node, the DU and the CU.
While Hampel discloses the second node is an IAB node which is a type of relay node (see Para’s [0038-0040] & [0067-0069]), the combination of Hampel in view of Bales, and further in view of Xu does not disclose receiving, from the second node, a second UL RRC message including an indication indicating the type of the second node and transmitting, to a third node, a handover request message including the indication for indicating a handover request is for the second node, and receiving, from the third node, a handover response message in response to the handover request message. However the claim features would be rendered obvious in view of Sivavakeesar US (2014/0301370).
Sivavakeesar discloses receiving by a first node (see Fig. 3 i.e., Source DeNB & Para’s [0070] i.e., the first base station & [0079]), from a second node (see Fig. 3 i.e., relay), an UL RRC message including an indication indicating the type of the second node (see Para’s [0053] i.e., it is important when a relay node (RN) attaches to D-eNB (i.e., “first node”) or is handed over from one D-eNB to another that the relevant D-eNB (i.e., “first node”) can readily ascertain the RN’s type), [0062] i.e., it is important for a D-eNB to decide on the relay node type at the time of relay attachment (i.e., relay type is indicated to a first D-eNB during attachment to the first D-eNB) or relay handover, [0066] i.e., For attachment of RNs to a D-eNB, there are two methods to inform the type of a mobile relay to any possible eNB (i.e., “first node”) that has the D-eNB capabilities. The first is to let the RN 14 inform its relay type to the D-eNB 12 using a modified UE capability container (a modified UE capability container (i.e., UE capability container is part of an RRC message and therefore an UL RRC message indicating the relay type) is part of the UE capability transfer procedure), & [0068] i.e., when the RN has cause to attach to the wireless telecommunications network, either 1) it communicates its type to the D-eNB (base station))
and transmitting, to a third node, a handover request message including the indication for indicating a handover request is for the second node (see Fig. 3 i.e., 4. Handover Request & Para’s [0041] i.e., when handover is required, said first base station sends a handover request to the second base station of information pertaining to the handover, including information regarding the relay nodes type, [0053-0056] i.e., RN capability, [0062] i.e., it is important for a D-eNB to decide on the relay node type at the time of relay attachment or relay handover, [0064] i.e., target D-eNB 12 to ascertain the relay type before it can decide whether or not it can support the relay to be handed over, [0065] i.e., This requires the target D-eNB needs to be notified of the mobile relay type and/or its capabilities, [0069] i.e., For mobile relay handover, it is appropriate for the source D-eNB 10 to pass the relay type onto the target D-eNB 12 (i.e., “third node”)…The appropriate timing for such an operation to take place is when the handover request command is issued. Hence, the type of the mobile relay and/or its capability details can be included as part of Handover request parameters and notified to the target D-eNB 12 (i.e., “third node”), [0070-0072] i.e., The relay node is connected to the first base station such that, when handover is required, said first base station sends a handover request to the second base station (i.e., “third node”) of information pertaining to the handover, including information regarding the relay nodes type and/or a given relay’s capability details, & [0079] i.e., The source D-eNB issues a HANDOVER REQUEST message to the target D-eNB (i.e., “third node”) passing necessary information to prepare the handover at the target side (relay type and/or a capability container), & [0087]).
and receiving, from the third node (see Fig. 4 i.e., Target DeNB), a handover response message in response to the handover request message (see Fig. 3 i.e., 6. Handover Request Ack & Para [0082] i.e., The target D-eNB prepares HO and sends the HANDOVER REQUEST ACKNOWLEDGE to the source D-eNB)
(Sivavakeesar suggests it is important that when the relay node is handed over, the target D-eNB can readily ascertain the RN’s type and capability so the target D-eNB can decide whether or not it can support the relay to be handed over and for configuring the required resources for the handover in order to achieve successful handover for the relay node to the target D-eNB, (see Para’s [0064], [0070-0072], & [0081])),
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the IAB relay node which is a type of relay node as disclosed in Hampel in view of Bales, and further in view of Xu to be indicated to the first base station for performing handover of the relay node to a third node based on the teachings of Sivavakeesar who discloses receiving, from a second node (i.e., relay node) a second UL RRC message including an indication indicating the type of relay node to a source base station and transmitting, from the source base station to a target base station, a handover request message including the indication for indicating a handover request is for the relay node, which results in the indication being an IAB node indication indicating the IAB relay node, because the motivation lies in Sivavakeesar that it is important that when the relay node is handed over, the target D-eNB can readily ascertain the RN’s type and capability so the target D-eNB can decide whether or not it can support the relay to be handed over and for configuring the required resources for the handover in order to achieve successful handover for the relay node to the target D-eNB.
Regarding Claim 20, Hampel discloses a first node (see Fig. 15 & Para’s [0117-0124]) in a wireless communication system (see Fig. 3B), the first node (see Fig. 15) comprising: a transceiver (see Fig. 15 i.e., transmitter 1520 & receiver 1510 & Para’s [0117-0118] & [0124]); and a controller coupled with the transceiver (see Fig. 15 i.e., communications manager 1515 & Para’s [0117] & [0120]) and configured to: receive, from a second node (see Fig. 3B i.e., relay 375 (i.e., “second node”)), a first uplink (UL) message for establishing an F1 connection (see Para’s [0041], [0067] i.e., L2 relay 375 may be used to establish wireless backhauling or wireless fronthauling. The L2-relay 375 connects to an access node (e.g., a base station or a gNB) in a similar manner as a UE established a wireless connection (i.e., establishing connection between the relay 375 and the base station involves signaling exchange which includes an uplink message from the relay for establishing the connection), [0068] i.e., the relay 375 may support RRC functionality to connect to the access node that includes DU-1 370, CU-U 365 and CU-C 360, [0069] i.e., the relay 375 supports a fronthaul control connection 390 between the DU-2 385 and CU-C 360, which may be referred to as F1-C in the CU/DU split architecture (i.e., F1-C connection between the DU-2 385 of the relay 375 and the CU-C 360 of the base station may be established based on signaling exchange which includes an uplink message from the relay for establishing the F1-C connection). A user plane connection 395 may also be supported between DU-2 385 and CU-U 365, [0077] i.e., F1-C messages 620 over RRC may be exchanged between DU-2 at the relay 605 and the CU-C, & [0091] i.e., the relay may then launch DU-2…and at block 1075 may establish F1-C with CU-C via SRB-B 1070)
a distributed unit (DU) of the second node (see Fig. 3B i.e., Du-2 385 of relay node 375 & Para [0069] i.e., the relay 375 uses its DU, referred to as DU-2 385 in Fig. 3B… i.e., the relay 375 supports a fronthaul control connection 390 between the DU-2 385 and CU-C 360, which may be referred to as F1-C in the CU/DU split architecture)
the second node is an integrated access and backhaul (IAB node), (see Fig. 3B i.e., relay node 375 & Para’s [0038] systems that use integrated access/backhaul (IAB) through a relay & [0039-0040] i.e., When using a CU/DU architecture for IAB, one or more relays may relay access data, backhaul data, or combinations & [0067-0069])
establishing an F1 connection between the DU of the second node and a central unit (CU) of the first node, (see Fig. 3B i.e., F1 connection 390 & Para [0069] i.e., the relay 375 supports a fronthaul control connection 390 between the DU-2 385 and CU-C 360, which may be referred to as F1-C in the CU/DU split architecture, [0072], [0077], & [0091] i.e., the relay may then launch DU-2…and at block 1075 may establish F1-C with CU-C via SRB-B 1070)
Hampel does not disclose the claim feature of transmitting, to a second node, a downlink (DL) radio resource control (RRC) message including configuration information on at least on internet protocol (IP) address for the second node. However the claim feature would be rendered obvious in view of Bales et al. USP (10,148,340).
Bales discloses transmitting by a base station (see Fig. 6 i.e., base station), to a second node (see Fig. 6 i.e., wireless relay), a downlink (DL) radio resource control (RRC) message (see Fig. 6 i.e., Relay RRC message transmitted from base station to wireless relay) including configuration information on at least on internet protocol (IP) address for the second node (see Fig. 6 & Col. 6 lines 11-36 i.e., Fig. 6 illustrates wireless relay attachment in multi-core LTE network 400…The R-PGW also issues an IP address (IPR) to the wireless relay. The R-PGW returns an S5 session response having the relays QCIs and IP address to the R-SGW…The wireless base station transfers an RRC service response (i.e., “downlink RRC message”) having the relay QCIs and IP address to the wireless relay. The wireless relay may now exchange R/R S1-MME signaling with the R-MME and may also exchange (R/UE) S1-MME signaling with the UE-MME).
(Bales suggests the base station transmits the downlink RRC service response message including wireless relays IP address in order for the wireless relay to successfully perform the attachment to the network and in order for the wireless relay to begin communication with the network, (see Fig. 6 & Col. 6 lines 11-36)).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the second node such as the relay node which establishes a connection with the first node such as the base station as disclosed in Hampel to include transmitting, by the base station to the relay node, a downlink (DL) radio resource control (RRC) message including configuration information on at least on internet protocol (IP) address for the relay node as disclosed in the teachings of Bales, because the motivation lies in Bales that the base station transmits the downlink RRC service response message including wireless relays IP address in order for the wireless relay to successfully perform the attachment to the network and in order for the wireless relay to begin communication with the network.
While Hampel discloses receiving, from the second node, a first uplink message for establishing the F1 connection between the DU of the second node and the CU of the first node (see Fig. 3B, Fig. 6 & Para’s [0041], [0067-0069], [0072], [0077], & [0091]), the combination of Hampel in view of Bales does not disclose the claim features of receiving from the second node such as the relay node, a first uplink message including information on an IP address for a distributed unit (DU) of the second node and establishing the F1 connection between the DU of the second node and the central unit (CU) of the first node, based on the IP address for the DU of the second node. However the claim features would be rendered obvious in view of Xu et al. US (2021/0409328).
Xu discloses receiving, by a first node (see Fig. 4 i.e., Donor-CU 110-11), a first uplink message including information on an IP address for a distributed unit (DU) (see Fig. 4 i.e., Donor-DU 110-12) of a second node (see Fig. 4 & Para [0095] i.e., As shown in Fig. 4, the Donor-DU 110-12 transmits 410 a F1AP message to the Donor-CU 110-11. In one example, the F1AP message may be a F1 setup request message. In addition, the message comprises an IPV6 prefix of the Donor-DU).
and establishing the F1 connection between the DU of the second node and the central unit (CU) of the first node (see Para [0095] i.e., the Donor-DU transmits 410 a F1AP message which may be a F1 setup request message (i.e., F1 setup request message is used for establishing the F1 connection between the DU and the CU)), based on the IP address for the DU of the second node (see Fig. 4 & Para’s [0095-0098] i.e., As shown in Fig. 4, the Donor-DU 110-12 transmits 410 a F1AP message to the Donor-CU 110-11. In one example, the F1AP message may be a F1 setup request message. In addition, the message comprises an IPV6 prefix of the Donor-DU).
(Xu suggests the donor-DU transmits the F1 setup request message to the Donor-CU for successfully establishing the F1 connection between the DU and the CU in order to perform data communications between an IAB node, the DU and the CU (see Para’s [0086] & [0095-0098])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the F1 connection established between the DU part of the relay node and the CU of the base station which is based on an uplink signaling message from the relay node to the base station as disclosed in Hampel in view of Bales to be established based on receiving, from the relay node a first uplink message including information on an IP address for the DU of the relay node based on the teachings of Xu who discloses receiving, by a first node, a first uplink message such as a F1 setup request including information on an IP address for a distributed unit (DU) of a second node for establishing the F1 connection between the DU and the CU, because the motivation lies in Xu that the donor-DU transmits the F1 setup request message to the Donor-CU for successfully establishing the F1 connection between the DU and the CU in order to perform data communications between an IAB node, the DU and the CU.
While Hampel discloses the second node is an IAB node which is a type of relay node (see Para’s [0038-0040] & [0067-0069]), the combination of Hampel in view of Bales, and further in view of Xu does not disclose receiving, from the second node, a second UL RRC message including an indication indicating the type of the second node and transmitting, to a third node, a handover request message including the indication for indicating a handover request is for the second node, and receiving, from the third node, a handover response message in response to the handover request message. However the claim features would be rendered obvious in view of Sivavakeesar US (2014/0301370).
Sivavakeesar discloses receiving by a first node (see Fig. 3 i.e., Source DeNB & Para’s [0070] i.e., the first base station & [0079]), from a second node (see Fig. 3 i.e., relay), an UL RRC message including an indication indicating the type of the second node (see Para’s [0053] i.e., it is important when a relay node (RN) attaches to D-eNB (i.e., “first node”) or is handed over from one D-eNB to another that the relevant D-eNB (i.e., “first node”) can readily ascertain the RN’s type), [0062] i.e., it is important for a D-eNB to decide on the relay node type at the time of relay attachment (i.e., relay type is indicated to a first D-eNB during attachment to the first D-eNB) or relay handover, [0066] i.e., For attachment of RNs to a D-eNB, there are two methods to inform the type of a mobile relay to any possible eNB (i.e., “first node”) that has the D-eNB capabilities. The first is to let the RN 14 inform its relay type to the D-eNB 12 using a modified UE capability container (a modified UE capability container (i.e., UE capability container is part of an RRC message and therefore an UL RRC message indicating the relay type) is part of the UE capability transfer procedure), & [0068] i.e., when the RN has cause to attach to the wireless telecommunications network, either 1) it communicates its type to the D-eNB (base station))
and transmitting, to a third node, a handover request message including the indication for indicating a handover request is for the second node (see Fig. 3 i.e., 4. Handover Request & Para’s [0041] i.e., when handover is required, said first base station sends a handover request to the second base station of information pertaining to the handover, including information regarding the relay nodes type, [0053-0056] i.e., RN capability, [0062] i.e., it is important for a D-eNB to decide on the relay node type at the time of relay attachment or relay handover, [0064] i.e., target D-eNB 12 to ascertain the relay type before it can decide whether or not it can support the relay to be handed over, [0065] i.e., This requires the target D-eNB needs to be notified of the mobile relay type and/or its capabilities, [0069] i.e., For mobile relay handover, it is appropriate for the source D-eNB 10 to pass the relay type onto the target D-eNB 12 (i.e., “third node”)…The appropriate timing for such an operation to take place is when the handover request command is issued. Hence, the type of the mobile relay and/or its capability details can be included as part of Handover request parameters and notified to the target D-eNB 12 (i.e., “third node”), [0070-0072] i.e., The relay node is connected to the first base station such that, when handover is required, said first base station sends a handover request to the second base station (i.e., “third node”) of information pertaining to the handover, including information regarding the relay nodes type and/or a given relay’s capability details, & [0079] i.e., The source D-eNB issues a HANDOVER REQUEST message to the target D-eNB (i.e., “third node”) passing necessary information to prepare the handover at the target side (relay type and/or a capability container), & [0087]).
and receiving, from the third node (see Fig. 4 i.e., Target DeNB), a handover response message in response to the handover request message (see Fig. 3 i.e., 6. Handover Request Ack & Para [0082] i.e., The target D-eNB prepares HO and sends the HANDOVER REQUEST ACKNOWLEDGE to the source D-eNB)
(Sivavakeesar suggests it is important that when the relay node is handed over, the target D-eNB can readily ascertain the RN’s type and capability so the target D-eNB can decide whether or not it can support the relay to be handed over and for configuring the required resources for the handover in order to achieve successful handover for the relay node to the target D-eNB, (see Para’s [0064], [0070-0072], & [0081])),
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the IAB relay node which is a type of relay node as disclosed in Hampel in view of Bales, and further in view of Xu to be indicated to the first base station for performing handover of the relay node to a third node based on the teachings of Sivavakeesar who discloses receiving, from a second node (i.e., relay node) a second UL RRC message including an indication indicating the type of relay node to a source base station and transmitting, from the source base station to a target base station, a handover request message including the indication for indicating a handover request is for the relay node, which results in the indication being an IAB node indication indicating the IAB relay node, because the motivation lies in Sivavakeesar that it is important that when the relay node is handed over, the target D-eNB can readily ascertain the RN’s type and capability so the target D-eNB can decide whether or not it can support the relay to be handed over and for configuring the required resources for the handover in order to achieve successful handover for the relay node to the target D-eNB.
Claims 12 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Hampel US (2019/0053317) in view of Bales et al. USP (10,148,340), and further in view of Xu et al. US (2021/0409328), and further in view of Sivavakeesar US (2014/0301370), and further in view of Huang et al. US (2015/0071210) as applied to claims 11 and 20 above, and further in view of Huang et al. US (2018/0160338).
Regarding Claims 12 and 22, the combination of Hampel in view of Bales, further in view of Xu, and further in view of Sivavakeesar, discloses the method and first node of claims 11 and 20, including the IP address for DU of the second node, (Xu, see Para [0095]), but does not disclose wherein the DL RRC message includes sending the IP address for the DU of the second node. However the claim feature would be rendered obvious in view of Huang et al. US (2015/0071210).
Huang discloses the DL RRC message from a source DeNB to relay node (i.e., “second node”) includes configuration information regarding the internet protocol (IP) address for the second node (see Fig. 3 i.e., step 4 i.e., RRC reconfiguration message & Para’s [0004] i.e., co-located gateway (LGW) is located in the MRN & [0154] i.e., In step 4, the source DeNB sends the air interface message RRC connection reconfiguration message to the MRN and the RRC connection reconfiguration message carries the transparent handover command message sent to the MRN…The source DeNB can send the IP address of the LGW (i.e., “IP address for the second node”) to the MRN through the message).
(Huang suggests the source DeNB sends the RRC connection reconfiguration message including the IP address of the relay node to the MRN in order to successfully handover the MRN from the source DeNB to the target DeNB, (see Para’s [0154-0156])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the IP address for DU of the second node such as the IAB nodes IP address as disclosed in Hampel in view of Bales, further in view of Xu, and further in view of Sivavakeesar, to be sent in the DL RRC message based on the teachings of Huang who discloses the DL RRC message from a source DeNB to relay node (i.e., “second node”) includes configuration information regarding the internet protocol (IP) address for the second node, because the motivation lies in Huang that the source DeNB sends the RRC connection reconfiguration message including the IP address of the relay node to the MRN in order to successfully handover the MRN from the source DeNB to the target DeNB.
While The combination of Hampel in view of Bales, further in view of Xu, and further in view of Sivavakeesar, and further in view of Huang discloses including the IP address for the DU of the second node in the DL RRC message, the references combined does not disclose wherein the DL RRC message further includes configuration information on a list including the IP address for the DU of the second node. However the claim feature would be rendered obvious in view of Huang et al. US (2018/0160338).
Huang discloses wherein a DL RRC message further includes configuration information regarding a list of configuration information of a relay node (i.e., “second node”) (see Para’s [0159-0165] i.e., Specifically the D2D relay configuration information includes one or a combination (i.e., list) of the following: type of served D2D relay node, D2D resource information, power-saving configuration information of the D2D relay node…In step 604, the target base station sends a handover request acknowledgement to the source base station which includes the D2D relay configuration information determined for the relay UE by the target base station..In step S605, the source base station sends a handover command received from the target base station to the UE by means of a RRC reconfiguration message which includes the D2D relay configuration information configured for the relay UE).
(Huang suggests the handover command including the D2D relay configuration information is sent to the relay UE for successfully performing handover of the Relay UE from the source eNB to the Target eNB (see Para’s [0035], [0044], & [0159-0165])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the DL RRC message including the IP address for the DU of the second node as disclosed in Hampel in view of Bales, further in view of Xu, and further in view of Sivavakeesar, to further include the list of configuration information of the relay node included in the RRC handover request acknowledgement message sent from the source eNB to the relay node for performing handover of the relay node as disclosed in the teachings of Huang which results in the DL RRC message further including configuration information regarding a list of configuration information including the IP address for the DU of the second node, because the motivation lies in Huang that the handover command including the D2D relay configuration information is sent to the relay UE for successfully performing handover of the Relay UE from the source eNB to the Target eNB.
Claims 13 and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Hampel US (2019/0053317) in view of Bales et al. USP (10,148,340), and further in view of Xu et al. US (2021/0409328), and further in view of Sivavakeesar US (2014/0301370), and further in view of Huang et al. US (2015/0071210), as applied to claims 10 and 20 above, and further in view of Takahashi et al. US (2012/0300693).
Regarding Claim 13, the combination of Hampel in view of Bales, further in view of Xu, and further in view of Sivavakeesar discloses the method of claim 10, but does not disclose further comprising: transmitting, via a cell of the first node, an RRC message including information associated with the cell, wherein the information associated with the cell indicates that the cell supporting an access of the IAB node allows the access of the second node. However the claim features would be rendered obvious in view of Takahashi et al. US (2012/0300693).
Takahashi discloses transmitting, via a cell of the first node to a relay node, an RRC message including information associated with the cell, (see Para’s [0032] i.e., cell identity…and is configured by Macro eNB ID (20 bits) that is used by the relay node RN and ID (8 bits) that enables unique identification of a cell in the relay node or the radio base station DeNB in which the “Macro eNB ID” is used, & [0068-0069] i.e., the relay node RN receives “RRC connection Reconfiguration” that assigns the above-described “ID” that should be set to the lower 8 bits of the “Cell Identity”, from the radio base station DeNB)
wherein the information associated with the cell indicates that the cell supporting an access of the relay node allows the access of the second node (see Para’s [0032] i.e., cell identity…and is configured by Macro eNB ID (20 bits) that is used by the relay node RN and ID (8 bits) that enables unique identification of a cell in the relay node or the radio base station DeNB in which the “Macro eNB ID” is used, [0043], [0057], & [0068] i.e., the relay node RN receives “RRC connection Reconfiguration” that assigns the above-described “ID” that should be set to the lower 8 bits of the “Cell Identity”, from the radio base station DeNB (i.e., cell supports an access of the relay node))
(Takahashi suggests the cell identity information is communicated to the relay node in the RRC connection reconfiguration message in order for the UE to setup an RRC connection with the base station for performing communication with the base station according to the configured cell identity information, (see Para’s [0032], [0041], [0057], & [0068-0071])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the IAB relay node which established a connection to the base station as disclosed in Hampel in view of Bales, further in view of Xu, and further in view of Sivavakeesar to perform by the base station (i.e., “first node”), transmitting to a relay node, via a cell of the first node, an RRC message including information associated with the cell, wherein the information associated with the cell indicates that the cell supporting an access of the relay node allows the access of the second node as disclosed in the teachings of Takahashi, because the motivation lies in Takahashi that the cell identity information is communicated to the relay node in the RRC connection reconfiguration message in order for the UE to setup an RRC connection with the base station for performing communication with the base station according to the configured cell identity information.
Regarding Claim 23, the claim is directed towards a first node which performs the same claim features as claim 13. Therefore claim 23 is rejected as obvious over the combination of Hampel in view of Bales, further in view of Xu, and further in view of Sivavakeesar, and further in view of Takahashi as in claim 13.
Claims 14 and 24 are rejected under 35 U.S.C. 103 as being unpatentable over Hampel US (2019/0053317) in view of Bales et al. USP (10,148,340), and further in view of Xu et al. US (2021/0409328), and further in view of Sivavakeesar US (2014/0301370), and further in view of Huang et al. US (2015/0071210) as applied to claims 10 and 20 above, further in view of Huang et al. US (2015/0071210), and further in view of Keskitalo et al. US (2021/0321298).
Regarding Claim 14, the combination of Hampel in view of Bales, further in view of Xu, and further in view of Sivavakeesar discloses the method of claim 10 including the IP address for DU of the second node, (Xu, see Para [0095]), but does not disclose further comprising: transmitting, to the third node, the information regarding the IP address for the DU of the second node, and wherein the first node is a master base station, and the third node is a secondary gNB (SGNB). However the claim features would be rendered obvious in view of further in view of Huang et al. US (2015/0071210).
Huang discloses transmitting, to the third node, information regarding the IP address for a relay node (i.e., “second node) (see Para’s [0004] i.e., co-located gateway (LGW) in the MRN, [0019] i.e., the destination donor NodeB receiving an X2 interface handover request message carrying the local gateway address assignment information sent by a source donor NodeB of the mobile relay node, [0103], & [0148])
and wherein the first node is a master base station (see Fig. 7 i.e., source DeNB may be a “master base station” & Para’s [0147-0148]), and the third node is a secondary base station (see Fig. 7 i.e., target DeNB may be a “secondary base station” & Para’s [0147-0148])
(Huang suggests the source DeNB sends the handover request to the target DeNB for successfully performing handover of the Relay UE from the source eNB to the Target eNB (see Para’s [0148] & [0156])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the first base station as disclosed in Hampel in view of Bales, further in view of Xu, and further in view of Sivavakeesar to transmit, to a third node, information regarding the IP address for the DU of the second node based on the teachings of Huang who discloses a source base station transmitting, to a third node such as a target base station, information regarding the IP address for a relay node in a handover request message, because the motivation lies in Huang that the source DeNB sends the handover request to the target DeNB for successfully performing handover of the Relay UE from the source eNB to the Target eNB.
The references combined does not disclose wherein the third node is to be operated as an evolved-universal radio access network-new radio (en) - gNodeB (gN B) and the third node is a secondary gNB. However the claim features would be rendered obvious in view of the Keskitalo et al. US (2021/0321298).
Keskitalo discloses wherein the third node (see Fig. 6A i.e., target network node 620) is to be operated as an evolved-universal radio access network-new radio (en) - gNodeB (gN B) (see Fig. 6A & Para’s [0013] & [0070] i.e., the source node may be a gNB and the target node may be a gNB)
and the third node is a secondary gNB (see Fig. 6A i.e., target network node 620 is a secondary node with respect to the source network node 610 & Para’s [0017-0019] & [0070] i.e., the target node may be a gNB)
(Keskitalo suggests the source and target base stations which are 5G base stations support a wide range of applications for a UE (see Para [0024]) and may communicate with the device 600 which may be an IAB relay node for supporting IAB, (see Para’s [0017-0019], [0024], [0032], & [0110])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the third base station such as the target base station as disclosed in Hampel in view of Bales, further in view of Xu, and further in view of Sivavakeesar to be operated as an evolved-universal radio access network-new radio (en) - gNodeB (gN B) and a secondary gNB as disclosed in Keskitalo, because the motivation lies in Keskitalo that the source and target base stations which are 5G base stations support a wide range of applications for a UE and may communicate with the device 600 which may be an IAB relay node for supporting IAB.
Regarding Claim 24, the claim is directed towards a first node which performs the same claim features as claim 14. Therefore claim 24 is rejected as obvious over the combination of Hampel in view of Bales, further in view of Xu, and further in view of Sivavakeesar, and further in view of Huang, and further in view of Keskitalo as in claim 14.
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 ADNAN A BAIG whose telephone number is (571)270-7511. The examiner can normally be reached M-F 9:00am-5:00pm.
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.
/ADNAN BAIG/Primary Examiner, Art Unit 2461