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 filed August 21 2026 have been fully considered but they are not persuasive. In regards to the applicants arguments regarding amended claims 10 and 20, the examiner respectfully disagrees as at least the combined teachings of Hampel in view of Xu, further in view of Sivavakeesar, further in view of Deng, and further in view of Zhang discloses the claim features of amended claims 10 and 20.
For example the applicant argues on (Pg. 5 of the remarks) that the claim features in claim 10 of an IP address for the IAB-DU is allocated by OAM, information on the IP address is provided from the IAB node to the donor CU via a UL RRC message, and the donor CU establishes an F1 connection based on the received IP address. The applicant then states that “Thus, a distinguishing feature of claim 10 includes the particular signaling relationship in which an OAM-allocated IP address for the DU is notified to the donor CU and is then used to establish the F1 connection”. The applicant then argues that Hampel may disclose than an F1-C fronthaul connection can be established between a DU of a relay node and a CU of an access or anchor node (Hampel i.e., Fig. 3B), which the examiner agrees. The applicant argues that however, Hampel does not disclose a sequence in which information in an IP address for the DU of the second node, which IP address is allocated by OAM, is provided by the second node to the CU of the first node via a UL RRC message, and the CU of the first node establishes an F1 connection based on the IP address so received (see Pg. 6 paragraph 1 of the remarks). However the applicant is arguing the teachings of Hampel individually for not disclosing the missing features such as how the F1 connection is established in Hampel when the rejection of claim 10 is an obviousness rejection under 35 U.S.C. 103.
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 applicant agrees that an F1 connection is established between the DU of the relay node and the CU of the access node in the Hampel reference, (Hampel, see Fig 3B i.e., 390 & Para’s [0069], [0072], & [0077]). Hampel does not disclose the claim features of establishing the F1 connection between the DU of the relay node and the CU of the access node such as for example i.e., OAM-based IP address allocation, notification of the IP address via UL RRC signaling from the DU to the CU, and the establishment of the F1 connection based on that IP address. However the teachings of Xu discloses the establishment of an F1 connection is performed between a DU and CU by OAM-based IP address allocation, notification of the IP address via UL RRC signaling from the DU to the CU, and the establishment of the F1 connection based on that IP address.
For example Xu discloses wherein the IP address for the DU is allocated by an operation administration and maintenance (OAM) (see Para [0057] i.e., the OAM also provides (i.e., allocated by OAM) the connected Donor-Dus IPv6 prefix to the IAB node…before the IAB-DU initiates SCTP/F1AP setup procedure). Therefore Xu discloses wherein the IP address for the DU may be allocated by an operation administration and maintenance (OAM) based on Para [0057] of Xu.
Xu discloses the F1 connection is established between a DU and a CU (see Para [0095] i.e., F1 setup request message), based on the DU sending an UL RRC message including information on an IP address for the DU to the CU (see Para’s [0076] i.e., F1AP may be an RRC message, [0079], [0095-0096] 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, & [0099-0101] i.e., F1AP setup message may be an RRC message).
Therefore it would be obvious to one of ordinary skill in the art for the F1 connection established between the DU of the relay node (i.e., claimed “second node”) and the CU of the access node (i.e., claimed “first node”) as disclosed in Hampel to be established between the DU of the second node and the CU of the first node based on F1 connection establishment procedure performed between the DU and the CU and disclosed in the teachings of Xu who discloses an OAM-based IP address allocation and a DU sending to a CU, the UL RRC message including the IP address of the DU in order to setup 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 the DU and the CU.
Therefore the combination of Hampel in view of Xu results in the IP address for the IAB-DU allocated by OAM, information on the IP address is provided from the IAB node to the donor CU via a UL RRC message, and the donor CU establishes an F1 connection based on the received IP address.
In regards to the applicants arguments regarding Bales, the current rejection of amended claims 10 and 20 do not rely on the reference of Bales, therefore arguments presented with respect to Bales are considered moot.
In regards to the applicants arguments regarding the teachings of Xu on (Pg. 6 of the remarks), the applicant argues that the disclosure of Xu fails to teach OAM-based IP address allocation and UL RRC-based notification recited in claim 10, however the examiner respectfully disagrees for the same reasons explained above with respect to Xu. For example Xu discloses OAM-based IP address allocation (see Para [0057]) and UL RRC-based notification (see Fig. 4 i.e., step 410 & Para’s [0076], [0079], [0095-0096], & [0099-0101]).
In regards to the applicants arguments regarding Sivavakeesar on (Pg. 6 of the remarks), the examiner respectfully disagrees. For example the applicant argues that Sivavakeesar does not disclose in claim 10 which recites the IAB node indication, which is received from the second node via the first UL RRC message. However the rejection of claim 10 is an obviousness rejection under 35 USC 103 and does not rely on Sivavakeesar individually for disclosing the IAB node indication received via the first UL RRC message included in the handover request message. For example, and for similar reasons explained in the response to arguments presented in the final office action of January 30 2026 (i.e., Pg.’s 3-6), Hampel discloses the second node is an IAB node which is a type of relay node (Hampel, see Para’s [0038-0040] & [0067-0069]). The teachings of Sivavakeesar discloses receiving, from the second node, a first UL RRC message including an indication indicating its relay type in a UL RRC message (see Para’s [0053], [0062], & [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 (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]).
Therefore it would have been 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 relay type in a UL RRC message to a first node (i.e., source DeNB) for transmitting to a third node, 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 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 that 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 (Sivavakeesar, see Para’s [0064], [0070-0072], & [0081])
Therefore the combination of Hampel in view of Xu, and further in view of Sivavakeesar discloses the claim feature in claim 10 of receiving, from the second node, a first UL RRC message including an IAB node indication indicating that the second node is the IAB node.
In regards to the applicants arguments on the (last paragraph on Pg. 6) regarding the teachings of Deng and Zhang failing to disclose the IAB-specific IP address/F1 establishment procedure and the handover indication, the combination of Hampel in view of Xu, and further in view of Sivavakeesar discloses the IAB-specific IP address/F1 establishment procedure and the handover indication for the reasons explained above.
In regards to the applicants arguments that the examiners proposed combination is unreasonable because it can only be arrived at using the present application and claims as an improper hindsight, the examiner respectfully disagrees.
In response to applicant's argument that the examiner's conclusion of obviousness is based upon improper hindsight reasoning, it must be recognized that any judgment on obviousness is in a sense necessarily a reconstruction based upon hindsight reasoning. But so long as it takes into account only knowledge which was within the level of ordinary skill at the time the claimed invention was made, and does not include knowledge gleaned only from the applicant's disclosure, such a reconstruction is proper. See In re McLaughlin, 443 F.2d 1392, 170 USPQ 209 (CCPA 1971).
In regards to the applicants arguments that none of the 6 references provides a specific teaching or motivation to combine the claimed IP address notification and F1 connection establishment with the claimed handover procedure using the IAB node indication. However the examiner respectfully disagrees as proper motivation to combine the references has been provided in the rejection of claims 10 and 20 to arrive to claimed invention of claims 10 and 20.
Applicant's arguments filed July 20 2026 have been fully considered but they are not persuasive. In regards to the applicants arguments regarding the rejection of claim 10, the examiner respectfully disagrees. For example with respect to the applicants introduction on (Pg.’s 5-6 of the remarks), the applicant describes an IAB relay node using IAB technology for relaying both access and backhaul traffic wirelessly in which the IAB node has two functional parts: a Mobile termination (MT) part, which connects to the donor/anchor node over the air interface like a UE, and a distributed unit (DU) part, which provides base station functionality to serve downstream UEs and other IAB nodes. The examiner notes that Hampel discloses such an IAB relay node with MT part and DU part for communicating with an access node and a UE, (Hampel, see Fig. 3B i.e., IAB relay node 375 & Para’s [0013], [0038-0040], & [0065-0069]).
In regards to the applicants arguments regarding claim 10 on (Pg.’s 7-8 of the remarks), the applicant argues the teachings of Hampel not disclosing the procedure in which the CU of the first node receives from the second node via a UL RRC message, information on an IP address for the DU of the second node. However for the same reasons explained above with respect to the response to arguments section for August 21, 2026, the combined teachings Hampel in view of Xu discloses the CU of the first node receives from the second node via a UL RRC message, information on an IP address for the DU of the second node. For example, the Applicant states that Hampel fails to disclose the features in claim 10 concerning notification of the DU IP address of the IAB node and establishment of the F1 connection based on the notified IP address. However the applicant is arguing the teachings of Hampel individually for not disclosing the F1 connection establishment procedure. For the same reasons explained above the combined teachings Hampel in view of Xu results in notification of the DU IP address of the IAB node (i.e., “second node”) and establishment of the F1 connection based on the notified IP address.
In regards to the applicants arguments regarding Bales, for the same reasons explained above, the current rejection of amended claims 10 and 20 do not rely on the reference of Bales, therefore arguments presented with respect to Bales are considered moot.
In regards to the applicants arguments regarding Xu on Pg. 8 of the remarks of July 20, 2026, the examiner respectfully disagrees. For example the applicant argues that Xu does not disclose the procedure as recited in claim 10, in which the CU of the first node provides IP-address configuration information for the second node via a DL RRC message. However such feature has been removed from amended claims 10 and 20, and therefore arguments provided with respect to such claim feature are considered moot.
In regards to the applicants further argument regarding Xu not disclosing the receiving from the second node via a UL RRC message, information on an IP address for the DU of the second node and establishes an F1 connection between the DU of the second node and the CU of the first node based on that IP address, the examiner respectfully disagrees as the combined teachings of Hampel in view of Xu arrive to F1 connection establishment procedure between the DU of second node and CU of the first node for the same reasons explained above. In regards to the applicants argument that Xu does not disclose “DU IP address configured based on DL RRC configuration information” such limitation has been removed from amended claim 10 and therefore arguments with respect to the limitation are considered moot.
In regards to the applicants arguments regarding the teachings of Sivavakeesar, the same response to arguments presented above with respect to the teachings of Sivavakeesar apply. For example the combined teachings of Hampel in view of Xu, and further in view of Sivavakeesar result in the target base station recognizing a relay type during handover such as IAB relay node type based on the IAB node indication received in the handover request message for the same reasons explained above with respect to the teachings of Sivavakeesar. The applicant further states that Sivavakeesar does not disclose establishment of dual connectivity of the IAB node with the first node and the third node. However the claim feature has been removed from amended claim 10 and therefore arguments with respect to the limitation are considered moot.
In regards to the applicants arguments regarding the references of Deng and Zhang on (Pg. 9 of the remarks), the examiner respectfully disagrees. For example the applicant argues that neither Deng nor Zhang disclose the DU IP address configuration, however the claim feature has been removed from amended claim 10 and therefore arguments with respect to the limitation are considered moot. In regards to the applicants argument that neither Deng nor Zhang disclose establishment of an F1 connection, or an IAB handover procedure as recited in claim 10, for the same reasons explained above, the combined teachings of Hampel in view of Xu, and further in view of Sivavakeesar discloses the establishment of an F1 connection and the IAB handover procedure as recited in claim 10.
In regards to the applicants arguments that none of the 6 references provides a specific teaching or motivation to combine the references or the proposed combination amounts to an impermissible hindsight, the examiner respectfully disagrees for the same reasons explained above. For example, the examiner respectfully disagrees as proper motivation to combine the references has been provided in the rejection of claims 10 and 20 to arrive to claimed invention of claims 10 and 20.
In regards to the applicants arguments on (Pg. 10 of the remarks), the applicant argues that the examiners assertion that claim 10 would have been obvious based on the combination of Hampel and Xi is not persuasive. For example the applicant states that Hampel discloses that an F1-C or fronthaul connection may be established between the DU of a relay node and the CU of an anchor node or access node. However Hampel still teaches that an F1 connection is established between the DU of the relay node and CU of the access node (Hampel, see Fig 3B i.e., 390 & Para’s [0069], [0072], & [0077]). For the same reasons explained above with respect to the combination of Hampel in view of Xu explained above, it would be obvious to one of ordinary skill in the art for the F1 connection established between the DU of the relay node and the access node of the CU as disclosed in Hampel to be performed according to the F1 connection setup performed between the DU and the CU as disclosed in Xu for establishing the F1 connection. In regards to the applicants arguments regarding the combination of Hampel in view of Xu not disclosing the CU of the first node providing IP address configuration information for the second node through a DL RRC message, the IP address is based on the configuration, the claim limitations are not claimed in claim 10 and therefore arguments with respect to the claim features are considered moot.
In regards to the applicants arguments that neither of the references provide a teaching, suggestion, or motivation that would have led a person of ordinary skill in the art to the claimed feature in which an IAB node notifies a donor CU of a IP address and an F1 connection is established based on that notified IP address, the examiner respectfully disagrees as one of ordinary skill in the art would rely on the F1 setup procedure disclosed between the DU and the CU based on sending the DUs IP address to the CU as disclosed in Xu to be used for setting up the F1 connection between the relay IAB node and the donor CU as disclosed in Hampel for successfully establishing the F1 connection. Therefore the combined teachings of Hampel in view of Xu results in the IAB node notifies a donor CU of a IP address and an F1 connection is established based on that notified IP address.
For the reasons explained, the amended claims 10 and 20 are rejected over the combination of Hampel in view of Xu, further in view of Sivavakeesar, further in view of Deng, and further in view of Zhang. The dependent claims remain rejected over the prior art (Of Record) based on their dependence to the independent claims 10 and 20.
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 Xu et al. US (2021/0409328), further in view of Sivavakeesar US (2014/0301370), further in view of Deng et al. US (2013/0094435), and further in view of Zhang et al. US (2020/0264636).
Regarding Claim 10, Hampel discloses a method performed by a central unit (CU) of a first node (see Fig. 3B i.e., access node that includes DU-1 370, CU-U 365, and CU-C 360 & Para’s [0067-0068] 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”)), an 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)
While Hampel discloses the first node (i.e., CU) 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]), Hampel does not disclose the claim features of the first node (i.e., CU) receiving from the second node such as the relay node, a second uplink RRC message including information on an internet protocol (IP) address for a distributed unit (DU) of the second node, wherein the IP address for the DU of the second node is allocated by an operation administration and maintenance (OAM), 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) from a second node (see Fig. 4 i.e., Donor-DU 110-12), a second uplink RRC message (see Fig. 4, 410) including information on an IP address for a distributed unit (DU) (see Fig. 4 i.e., Donor-DU 110-12) of the second node (see Para’s [0076] i.e., F1AP may be an RRC message, [0079], [0095-0096] 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, & [0099-0101] i.e., F1AP setup message may be an RRC message).
wherein the IP address for the DU of the second node is allocated by an operation administration and maintenance (OAM) (see Para [0057] i.e., the OAM also provides (i.e., allocated by OAM) the connected Donor-Dus IPv6 prefix to the IAB node…before the IAB-DU initiates SCTP/F1AP setup procedure)
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 to be established based on receiving, from the relay node a second uplink RRC 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 second uplink RRC 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 Xu does not disclose receiving, from the second node, a first 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 (i.e., “first 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 first 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.
The combination of Hampel in view of Bales, further in view of Xu, and further in view of Sivavakeesar does not disclose the claim feature of transmitting, to the second node, a RRC message including information associated with an access of a cell of the first node, wherein the information associated with the access of the cell of the first node indicates that the cell supports an IAB node. However the claim features would be rendered obvious in view of Deng et al. US (2013/0094435).
Deng discloses a first node transmitting, to a second node (see Fig. 4 i.e., RN), a message including information associated with an access of a cell of a first node (see Para [0045] i.e., Preferably, the RN, before sending the message to the DenB, selects a cell to be attached according to a pre-configured base station list or cell list or information in a cell system information broadcast message on whether attach of the RN is allowed, [0055], & [0083]), wherein the information associated with the access of the cell of the node indicates that the cell supports a relay node type (see Para’s [0042-0044] i.e., RN type & [0045] i.e., Preferably, the RN, before sending the message to the DenB, selects a cell to be attached according to a pre-configured base station list or cell list or information in a cell system information broadcast message on whether attach of the RN is allowed, [0055], & [0083]).
(Deng suggests the relay node receives the cell system broadcast message from the DeNB for indicating to the relay node which cells allow attach of the RN in order for the relay node to initiate an attach procedure on the selected cell for appropriately attaching to the base station (see Para’s [0045], [0055], & [0083])).
Therefore it would be obvious to one of ordinary skill in the art before the effective filing date for the first node to transmit and apply to the second IAB node (i.e., “relay node”) as disclosed in Hampel in view of Xu, and further in view of Sivavakeesar the cell system information broadcast message transmitted from a base station (i.e., “first node”) to a relay node (i.e., “second node”) including information associated with access of a cell of a node which allows attach of the relay node type as disclosed in Deng, which results in the information associated with access of the cell indicates that the cell supports an IAB relay node, because the motivation lies in Deng that the relay node receives the cell system broadcast message from the DeNB for indicating to the relay node which cells allow attach of the RN in order for the relay node to initiate an attach procedure on the selected cell for appropriately attaching to the base station.
The combination of Hampel in view of Xu, further in view of Sivavakeesar, and further in view of Deng does not disclose that the cell system information broadcast message is an RRC message. However the claim feature would be rendered obvious in view of Zhang et al. US (2020/0264636).
Zhang discloses that a base station transmits system information broadcast message in an RRC message (see Para’s [0128] i.e., the base station may include the generated configuration information in RRC signaling & [0131-0132] i.e., The RRC signaling may include a system broadcast message).
(Zhang suggests a base station may include required configuration information in the system broadcast message included in the RRC signaling in order for a receiving device to appropriately receive the configuration information, (see Para’s [0128] & [0131-0132])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the cell system information broadcast message as disclosed in Hampel in view of Xu, further in view of Sivavakeesar, and further in view of Deng to be included in an RRC message based on the teachings of Zhang who discloses that a base station transmits a system broadcast message in an RRC signaling message, because the motivation lies in Zhang that a base station may include required configuration information in the system broadcast message included in the RRC signaling in order for a receiving device to appropriately receive the configuration information.
Regarding Claim 20, Hampel discloses a central unit (CU) of a first node (see Fig. 3B i.e., CU of access node, Fig. 15 & Para’s [0067-0068], [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”)), an 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)
While Hampel discloses the first node (i.e., CU) 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]), Hampel does not disclose the claim features of the first node (i.e., CU) receiving from the second node such as the relay node, a second uplink RRC message including information on an internet protocol (IP) address for a distributed unit (DU) of the second node, wherein the IP address for the DU of the second node is allocated by an operation administration and maintenance (OAM), 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) from a second node (see Fig. 4 i.e., Donor-DU 110-12), a second uplink RRC message (see Fig. 4, 410) including information on an IP address for a distributed unit (DU) (see Fig. 4 i.e., Donor-DU 110-12) of the second node (see Para’s [0076] i.e., F1AP may be an RRC message, [0079], [0095-0096] 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, & [0099-0101] i.e., F1AP setup message may be an RRC message).
wherein the IP address for the DU of the second node is allocated by an operation administration and maintenance (OAM) (see Para [0057] i.e., the OAM also provides (i.e., allocated by OAM) the connected Donor-Dus IPv6 prefix to the IAB node…before the IAB-DU initiates SCTP/F1AP setup procedure)
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 to be established based on receiving, from the relay node a second uplink RRC 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 second uplink RRC 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 Xu does not disclose receiving, from the second node, a first 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 (i.e., “first 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 first 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.
The combination of Hampel in view of Bales, further in view of Xu, and further in view of Sivavakeesar does not disclose the claim feature of transmitting, to the second node, a RRC message including information associated with an access of a cell of the first node, wherein the information associated with the access of the cell of the first node indicates that the cell supports an IAB node. However the claim features would be rendered obvious in view of Deng et al. US (2013/0094435).
Deng discloses a first node transmitting, to a second node (see Fig. 4 i.e., RN), a message including information associated with an access of a cell of a first node (see Para [0045] i.e., Preferably, the RN, before sending the message to the DenB, selects a cell to be attached according to a pre-configured base station list or cell list or information in a cell system information broadcast message on whether attach of the RN is allowed, [0055], & [0083]), wherein the information associated with the access of the cell of the node indicates that the cell supports a relay node type (see Para’s [0042-0044] i.e., RN type & [0045] i.e., Preferably, the RN, before sending the message to the DenB, selects a cell to be attached according to a pre-configured base station list or cell list or information in a cell system information broadcast message on whether attach of the RN is allowed, [0055], & [0083]).
(Deng suggests the relay node receives the cell system broadcast message from the DeNB for indicating to the relay node which cells allow attach of the RN in order for the relay node to initiate an attach procedure on the selected cell for appropriately attaching to the base station (see Para’s [0045], [0055], & [0083])).
Therefore it would be obvious to one of ordinary skill in the art before the effective filing date for the first node to transmit and apply to the second IAB node (i.e., “relay node”) as disclosed in Hampel in view of Xu, and further in view of Sivavakeesar the cell system information broadcast message transmitted from a base station (i.e., “first node”) to a relay node (i.e., “second node”) including information associated with access of a cell of a node which allows attach of the relay node type as disclosed in Deng, which results in the information associated with access of the cell indicates that the cell supports an IAB relay node, because the motivation lies in Deng that the relay node receives the cell system broadcast message from the DeNB for indicating to the relay node which cells allow attach of the RN in order for the relay node to initiate an attach procedure on the selected cell for appropriately attaching to the base station.
The combination of Hampel in view of Xu, further in view of Sivavakeesar, and further in view of Deng does not disclose that the cell system information broadcast message is an RRC message. However the claim feature would be rendered obvious in view of Zhang et al. US (2020/0264636).
Zhang discloses that a base station transmits system information broadcast message in an RRC message (see Para’s [0128] i.e., the base station may include the generated configuration information in RRC signaling & [0131-0132] i.e., The RRC signaling may include a system broadcast message).
(Zhang suggests a base station may include required configuration information in the system broadcast message included in the RRC signaling in order for a receiving device to appropriately receive the configuration information, (see Para’s [0128] & [0131-0132])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the cell system information broadcast message as disclosed in Hampel in view of Xu, further in view of Sivavakeesar, and further in view of Deng to be included in an RRC message based on the teachings of Zhang who discloses that a base station transmits a system broadcast message in an RRC signaling message, because the motivation lies in Zhang that a base station may include required configuration information in the system broadcast message included in the RRC signaling in order for a receiving device to appropriately receive the configuration information.
Claims 14 and 24 are rejected under 35 U.S.C. 103 as being unpatentable over Hampel US (2019/0053317) in view of Xu et al. US (2021/0409328), and further in view of Sivavakeesar US (2014/0301370), further in view of Deng et al. US (2013/0094435), and further in view of Zhang et al. US (2020/0264636) as applied to claims 10 and 20 above, and further in view of Bales et al. USP (10,148,340).
Regarding Claim 14, the combination of Hampel in view of Xu, further in view of Sivavakeesar, further in view of Deng, and further in view of Zhang discloses the method of claim 10 including the IP address for DU of the second node, (Xu, see Para [0095]), but does not disclose the claim feature of further comprising: transmitting, to the second node, a downlink (DL) RRC message including configuration information on at least one 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 in view of Xu, further in view of Sivavakeesar, further in view of Deng, and further in view of Zhang 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.
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 Xu, further in view of Sivavakeesar, further in view of Deng, and further in view of Zhang, and further in view of Bales as in claim 14.
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 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
Prosecution Insights