DETAILED ACTION
Claim(s) 1-18 are presented for examination.
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 .
Priority
As required by M.P.E.P.201.14(c), acknowledgement is made to applicant’s claim for priority based on application(s) PCT/CN2022/075888 submitted on February 10th, 2022.
Information Disclosure Statement
The information disclosure statement(s) (IDS) submitted on August 1st, 2024; April 2nd, 2025; and July 29th, 2025 follow the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Objections
Claims 5, 7, 13 and 17 are objected to because of the following informalities:
Claim 5 recites “and/or” in line 10. For clarity and consistency, it is suggested to use words (i.e., and, or, etc.) without the slash “/”.
Claims 7, 13 and 17 are also being objected for reciting a similar limitation as set forth above. Appropriate correction is required.
Claim Rejections - 35 U.S.C. § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claim(s) 1-7 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Claim 1 recites “the topology” in line 6. There is insufficient antecedent basis for this limitation in the claim.
Claim(s) 2-7 are also rejected for being dependent on a rejected base claim as set forth above.
For the purpose of examination, examiner will interpret as best understood.
Claim Rejections - 35 U.S.C. § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. § 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151 , or in an application for patent published or deemed published under section 122(b) , in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim 18 is rejected under 35 U.S.C. § 102(a)(2) as being anticipated by Teyeb et al. (US 2023/0269644 A1) hereinafter “Teyeb”.
Regarding Claim 18,
Teyeb discloses an integrated access and backhaul (IAB) system [see fig. 9, pgs. 6-7, ¶130 lines 1-2; ¶131 lines 1-13, a network-initiated migration to migrate an IAB-MT “10”], comprising a first donor-CU and a second donor-CU [see fig. 9, pgs. 6-7, ¶131 lines 1-13, the IAB-node migration is initiated by the network (i.e., source Donor-CU “20” or Donor-CU “1”) to a target Donor-CU “30” or Donor-CU “2”];
the first donor-CU transmits an IAB transport migration management request for a traffic [see fig. 9: Step(s) “105”/ “110”, pgs. 6-7, ¶131 lines 1-13, once the source Donor-CU “20” (i.e. CU “1”) decides to migrate the IAB-MT “10” to the target Donor-CU “30” (i.e. CU “2”) due to any reason (such as load balancing, etc.), the source Donor-CU “20” triggers the handover procedure by sending a handover request, with additional information, to the target Donor-CU “30” (i.e. CU “2”)], wherein the IAB transport migration management request is used to request for releasing a resource serving for the traffic in a topology of the second donor-CU [see fig. 9: Step “115”, pg. 7, ¶136 lines 1-14, in response to the handover request, the target donor-CU “30” (i.e. donor-CU2) sends a handover response message to the source CU “20” containing information that facilitates the source donor-CU “20” to trigger the migration of the IAB-MT “10” only];
the second donor-CU receives the IAB transport migration management request [see fig. 9: Step “115”, pg. 7, ¶136 lines 1-14; ¶137 lines 1-10, if the target node “30” (i.e. Donor-CU “2”) accepts the handover request, it performs a set of actions (either in parallel, in sequence, or concurrently), which require enhancements or additional information elements in the F1 signalling between the target donor-CU “30” and the DU functionality of each intermediate node (i.e. donor DU, DU of intermediate IAB node, DU of the target parent node) that forwards the traffic between the migrated IAB node “10” and the target donor CU “30”].
Claim Rejections - 35 U.S.C. § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. § 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-17 are rejected under 35 U.S.C. § 103 as being unpatentable over Teyeb in view of HUANG et al. (US 2024/0187880 A1) hereinafter “Huang”.
Regarding Claim 1,
Teyeb discloses an integrated access and backhaul (IAB) donor device in a first donor-CU [see fig. 9, pgs. 6-7, ¶131 lines 1-13, IAB-node migration is initiated by the network (i.e., source Donor-CU “20” or Donor-CU “1”)], the device [see fig. 9, pgs. 6-7, ¶131 lines 1-13, the network (i.e., source Donor-CU “20” or Donor-CU “1”)] comprising:
a transmitter configured to transmit an IAB transport migration management request for a migrated traffic to a second donor-CU [see fig. 9: Step(s) “105”/ “110”, pgs. 6-7, ¶131 lines 1-13, once the source Donor-CU “20” (i.e. CU “1”) decides to migrate the IAB-MT “10” to the target Donor-CU “30” (i.e. CU “2”) due to any reason (such as load balancing, etc.), the source Donor-CU “20” triggers the handover procedure by sending a handover request, with additional information, to the target Donor-CU “30” (i.e. CU “2”)], and wherein the IAB transport migration management request is used to request for releasing a resource serving for the traffic in the topology of the second donor-CU [see fig. 9: Step “115”, pg. 7, ¶136 lines 1-14, in response to the handover request, the target donor-CU “30” (i.e. donor-CU2) sends a handover response message to the source CU “20” containing information that facilitates the source donor-CU “20” to trigger the migration of the IAB-MT “10” only], wherein an IAB-DU of an IAB node maintains F1 connection with the first donor-CU [see fig. 9: Step “115”, pg. 7, ¶136 lines 1-14, while keeping/maintaining the F1 interface with the migrating IAB node DU along with the UE contexts of all the UEs served by the migrating IAB-node “10”];
Although Teyeb discloses transmitting an IAB transport migration management request for a migrated traffic to a second donor-CU, Teyeb does not explicitly teach “the resource serving for the traffic of the IAB node has been established in a topology of the second donor-CU”.
However Huang discloses a transmitter configured to transmit an IAB transport migration management request for a migrated traffic to a second donor-CU [see fig. 4: Step “402”, pg. 6, ¶63 lines 1-9; ¶64 lines 1-7; ¶66 lines 1-20, the first (e.g., source/initial) IAB donor sends a request or a message (e.g., a non-UE-associated XnAP message) to transfer an updated information of an IAB node to the second (e.g., target/new) IAB donor], and wherein the IAB transport migration management request is used to request for releasing a resource serving for the traffic in the topology of the second donor-CU [see fig. 4: Step “402”, pg. 6, ¶63 lines 1-9; ¶64 lines 1-7; ¶66 lines 1-20, the request indicating that at least one of: a user equipment (UE) context, a mobile termination (MT) context or an UE-associated Xn connection between the first IAB donor and the second IAB donor, is to be maintained or kept (e.g., at/by the second IAB donor); or the message (e.g., non-UE-associated XnAP message) includes an identifier of the IAB node. The updated information includes at least one of: an IAB node (or IAB-DU) configuration information, or quality of service (QoS) information], wherein an IAB-DU of an IAB node maintains F1 connection with the first donor-CU [see fig. 4: Step “402”, pg. 6, ¶63 lines 1-9; ¶64 lines 1-7; ¶66 lines 1-20, the IAB node (or IAB-DU) configuration information includes at least one of: … a F1 user plane interface (F1-U) GPRS tunneling protocol (GTP) tunnel ID, or a QoS of a F1-U tunnel], and the resource serving for the traffic of the IAB node has been established in a topology of the second donor-CU [see fig. 4: Step “402”, pgs. 5-6, ¶57 lines 1-14; ¶63 lines 1-9; ¶64 lines 1-7; ¶66 lines 1-20, a target/source IAB donor (or non F1-terminating donor CU) sends the identifier of a IAB node (or IAB-DU) to a source/initial IAB donor (e.g., the F1-terminating donor) via a first message (e.g., a XnAP message). The identifier of the IAB node or IAB-DU includes at least one of the following: a DU ID, a BAP address of IAB node, which is allocated by the target/new IAB donor (or non F1-terminating donor) …].
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide “the resource serving for the traffic of the IAB node has been established in a topology of the second donor-CU” as taught by Huang in the system of Teyeb for facilitating enablement of different data services and requirements, and simplifying elements of 5G network functions with the elements being software, so that the elements can be adapted according to need in an efficient manner [see Huang, pg. 1, ¶3 lines 1-12].
Regarding Claim 2,
The combined system of Teyeb and Huang discloses the device according to claim 1.
Teyeb further discloses wherein the IAB-MT of the IAB-node maintains radio resource control connection with the first donor-CU [see pg. 5, ¶80 lines 1-8, according to the indication of the proxied inter donor IAB node migration, a radio resource control, RRC, connection of the IAB node is to be migrated to the target IAB node but F1 connections and RRC connections of any children nodes served by the IAB node are to be kept at a source IAB node such that the target IAB node is to serve as a proxy for the F1 connections and RRC connections kept at the source IAB node].
Regarding Claim 3,
The combined system of Teyeb and Huang discloses the device according to claim 1.
Teyeb further discloses wherein the traffic includes an F1 user plane traffic [see pg. 6, ¶124 lines 1-10, F1-U is tunneled over the Xn and then transparently forwarded to the IAB donor-DU-2 after the IAB node is migrated to the target donor CU (i.e. CU “2”)].
Regarding Claim 4,
The combined system of Teyeb and Huang discloses the device according to claim 1.
Teyeb further discloses wherein in a case where the traffic is migrated from the topology of the second donor-CU back to a topology of the first donor-CU [see fig. 9: Step(s) “105”/ “110”, pgs. 6-7, ¶131 lines 1-13, once the source Donor-CU “20” (i.e. CU “1”) decides to migrate the IAB-MT “10” to the target Donor-CU “30” (i.e. CU “2”) due to any reason (such as load balancing, etc.)], the transmitter transmits the IAB transport migration management request to the second donor-CU [see fig. 9: Step(s) “105”/ “110”, pgs. 6-7, ¶131 lines 1-13, the source Donor-CU “20” triggers the handover procedure by sending a handover request, with additional information, to the target Donor-CU “30” (i.e. CU “2”)].
Regarding Claim 5,
The combined system of Teyeb and Huang discloses the device according to claim 1.
Teyeb further discloses wherein the device further comprising: processor circuitry configured to perform the following operations:
configuring the IAB-node with updated uplink BH information for the traffic [see pg. 7, ¶138 lines 1-5, for every 1:1 mapped BH RLC channel indicated, set up a dedicated BH RLC channel on each BH link/hop until the migrated IAB node (with the same QoS profile or priority as indicated in the handover (HO) request)].
Regarding Claim 6,
The combined system of Teyeb and Huang discloses the device according to claim 1.
Teyeb further discloses wherein the IAB transport migration management request includes a traffic identifier needing to be released [see pg. 9, ¶155 lines 1-5, upon receiving this information from the target Donor-CU “30”, the source Donor-CU “20” (i.e. CU1) releases the UE context of all the UEs served by IAB-DU-3, F1 interface with IAB-DU-3 and the UE context of IAB-MT-3].
Regarding Claim 7,
The combined system of Teyeb and Huang discloses the device according to claim 1.
Teyeb further discloses wherein in a case where the IAB-MT of the IAB-node is handed over from the first donor-CU to the second donor-CU [see fig. 9: Step(s) “105”/ “110”, pgs. 6-7, ¶131 lines 1-13, once the source Donor-CU “20” (i.e. CU “1”) decides to migrate the IAB-MT “10” to the target Donor-CU “30” (i.e. CU “2”)], and one or more resources serving for one or more traffics of the IAB-node has/have been established in the topology of the second donor-CU [see fig. 9: Step(s) “105”/ “110”, pgs. 6-7, ¶131 lines 1-13, due to any reason (such as load balancing, etc.)], the transmitter transmits the IAB transport migration management request for the one or more traffics [see fig. 9: Step(s) “105”/ “110”, pgs. 6-7, ¶131 lines 1-13, the source Donor-CU “20” triggers the handover procedure by sending a handover request, with additional information, to the target Donor-CU “30” (i.e. CU “2”)].
Regarding Claim 8,
Teyeb discloses an integrated access and backhaul (IAB) donor device in a second donor-CU [see fig. 9, pgs. 6-7, ¶131 lines 1-13, IAB-node migration is initiated by the network (i.e., source Donor-CU “20” or Donor-CU “1”) to migrate the IAB-MT “10” to a target Donor-CU “30”], the device [see fig. 9, pgs. 6-7, ¶131 lines 1-13, the target Donor-CU “30”] comprising:
a transmitter configured to transmit an IAB transport migration modification request for a migrated traffic to a first donor-CU [see fig. 9: Step(s) “105”/ “110”, pgs. 6-7, ¶131 lines 1-13, once the source Donor-CU “20” (i.e. CU “1”) decides to migrate the IAB-MT “10” to the target Donor-CU “30” (i.e. CU “2”) due to any reason (such as load balancing, etc.), the source Donor-CU “20” triggers the handover procedure by sending a handover request, with additional information, to the target Donor-CU “30” (i.e. CU “2”)]; and
processor circuitry configured to release a resource serving for the traffic in a topology of the second donor-CU [see fig. 9: Step “115”, pg. 7, ¶136 lines 1-14, in response to the handover request, the target donor-CU “30” (i.e. donor-CU2) sends a handover response message to the source CU “20” containing information that facilitates the source donor-CU “20” to trigger the migration of the IAB-MT “10” only], and wherein an IAB-DU of an IAB node maintains F1 connection with the first donor-CU [see fig. 9: Step “115”, pg. 7, ¶136 lines 1-14, while keeping/maintaining the F1 interface with the migrating IAB node DU along with the UE contexts of all the UEs served by the migrating IAB-node “10”].
Although Teyeb discloses transmitting an IAB transport migration management request for a migrated traffic to a second donor-CU, Teyeb does not explicitly teach “the resource serving for the traffic of the IAB node has been established in the topology of the second donor-CU”.
However Huang discloses a transmitter configured to transmit an IAB transport migration modification request for a migrated traffic to a first donor-CU [see fig. 4: Step “402”, pg. 6, ¶63 lines 1-9; ¶64 lines 1-7; ¶66 lines 1-20, the first (e.g., source/initial) IAB donor sends a request or a message (e.g., a non-UE-associated XnAP message) to transfer an updated information of an IAB node to the second (e.g., target/new) IAB donor]; and
processor circuitry configured to release a resource serving for the traffic in a topology of the second donor-CU [see fig. 4: Step “402”, pg. 6, ¶63 lines 1-9; ¶64 lines 1-7; ¶66 lines 1-20, the request indicating that at least one of: a user equipment (UE) context, a mobile termination (MT) context or an UE-associated Xn connection between the first IAB donor and the second IAB donor, is to be maintained or kept (e.g., at/by the second IAB donor); or the message (e.g., non-UE-associated XnAP message) includes an identifier of the IAB node. The updated information includes at least one of: an IAB node (or IAB-DU) configuration information, or quality of service (QoS) information], and wherein an IAB-DU of an IAB node maintains F1 connection with the first donor-CU [see fig. 4: Step “402”, pg. 6, ¶63 lines 1-9; ¶64 lines 1-7; ¶66 lines 1-20, the IAB node (or IAB-DU) configuration information includes at least one of: … a F1 user plane interface (F1-U) GPRS tunneling protocol (GTP) tunnel ID, or a QoS of a F1-U tunnel], and the resource serving for the traffic of the IAB node has been established in the topology of the second donor-CU [see fig. 4: Step “402”, pgs. 5-6, ¶57 lines 1-14; ¶63 lines 1-9; ¶64 lines 1-7; ¶66 lines 1-20, a target/source IAB donor (or non F1-terminating donor CU) sends the identifier of a IAB node (or IAB-DU) to a source/initial IAB donor (e.g., the F1-terminating donor) via a first message (e.g., a XnAP message). The identifier of the IAB node or IAB-DU includes at least one of the following: a DU ID, a BAP address of IAB node, which is allocated by the target/new IAB donor (or non F1-terminating donor) …].
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide “the resource serving for the traffic of the IAB node has been established in a topology of the second donor-CU” as taught by Huang in the system of Teyeb for facilitating enablement of different data services and requirements, and simplifying elements of 5G network functions with the elements being software, so that the elements can be adapted according to need in an efficient manner [see Huang, pg. 1, ¶3 lines 1-12].
Regarding Claim 9,
The combined system of Teyeb and Huang discloses the device according to claim 8.
Teyeb further discloses wherein in a case of revoking the migrated traffic from the topology of the second donor-CU back to the topology of the first donor-CU [see fig. 9: Step(s) “105”/ “110”, pgs. 6-7, ¶131 lines 1-13, once the source Donor-CU “20” (i.e. CU “1”) decides to migrate the IAB-MT “10” to the target Donor-CU “30” (i.e. CU “2”) due to any reason (such as load balancing, etc.)], the transmitter transmits the IAB transport migration modification request for the traffic to the first donor-CU [see fig. 9: Step(s) “105”/ “110”, pgs. 6-7, ¶131 lines 1-13, the source Donor-CU “20” triggers the handover procedure by sending a handover request, with additional information, to the target Donor-CU “30” (i.e. CU “2”)].
Regarding Claim 10,
The combined system of Teyeb and Huang discloses the device according to claim 8.
Teyeb further discloses wherein the IAB transport migration modification request includes a traffic identifier needing to be released [see pg. 9, ¶155 lines 1-5, upon receiving this information from the target Donor-CU “30”, the source Donor-CU “20” (i.e. CU1) releases the UE context of all the UEs served by IAB-DU-3, F1 interface with IAB-DU-3 and the UE context of IAB-MT-3].
Regarding Claim 11,
The combined system of Teyeb and Huang discloses the device according to claim 8.
Teyeb further discloses wherein the device further comprising:
a receiver configured to receive an IAB transport migration modification response transmitted by the first donor-CU [see fig. 9: Step “115”, pg. 7, ¶136 lines 1-14, in response to the handover request, the target donor-CU “30” (i.e. donor-CU2) sends a handover response message to the source CU “20” containing information that facilitates the source donor-CU “20” to trigger the migration of the IAB-MT “10” only].
Regarding Claim 12,
The combined system of Teyeb and Huang discloses the device according to claim 11.
Teyeb further discloses wherein the IAB transport migration modification response includes an identifier of a traffic that is successfully released [see fig. 9: Step “115”, pg. 7, ¶136 lines 1-14, in response to the handover request, the target donor-CU “30” (i.e. donor-CU2) sends a handover response message to the source CU “20” containing information that facilitates the source donor-CU “20” to trigger the migration of the IAB-MT “10” only].
Regarding Claim 13,
The combined system of Teyeb and Huang discloses the device according to claim 11.
Teyeb further discloses wherein after receiving the IAB transport migration modification response, the processor circuitry releases backhaul adaptation protocol sublayer routing [see pg. 7, ¶138 lines 1-5, for every 1:1 mapped BH RLC channel indicated, set up a dedicated BH RLC channel on each BH link/hop until the migrated IAB node (with the same QoS profile or priority as indicated in the handover (HO) request)].
Regarding Claim 14,
The combined system of Teyeb and Huang discloses the device according to claim 11.
Teyeb further discloses wherein the receiver further receives an IAB transport migration modification response transmitted by the first donor-CU for rejecting the IAB transport migration modification request for the traffic [see pg. 7, ¶136 lines 1-14, the response message contains information that facilitates the source donor-CU “20” to trigger the migration of the IAB-MT “10” only, while keeping/maintaining the F1 interface with the migrating IAB node DU along with the UE contexts of all the UEs served by the migrating IAB-node “10”]
Regarding Claim 15,
The combined system of Teyeb and Huang discloses the device according to claim 14.
Teyeb further discloses wherein the IAB transport migration modification response is received via a transport migration management response message [see pg. 7, ¶136 lines 1-14, a HANDOVER REQUEST ACKNOWLEDGE message].
Regarding Claim 16,
The combined system of Teyeb and Huang discloses the device according to claim 14.
Teyeb further discloses wherein the IAB transport migration modification response includes an identifier of the traffic [see pg. 9, ¶155 lines 1-5, upon receiving this information from the target Donor-CU “30”, the source Donor-CU “20” (i.e. CU “1”) releases the UE context of all the UEs served by IAB-DU-3, F1 interface with IAB-DU-3 and the UE context of IAB-MT-3].
Regarding Claim 17,
The combined system of Teyeb and Huang discloses the device according to claim 8.
Teyeb further discloses wherein in a case where the IAB-MT of the IAB-node is handed over from the first donor-CU to the second donor-CU [see fig. 9: Step(s) “105”/ “110”, pgs. 6-7, ¶131 lines 1-13, once the source Donor-CU “20” (i.e. CU “1”) decides to migrate the IAB-MT “10” to the target Donor-CU “30” (i.e. CU “2”)], and one or more resources serving for one or more traffics of the IAB-node has/have been established in the topology of the second donor-CU [see fig. 9: Step(s) “105”/ “110”, pgs. 6-7, ¶131 lines 1-13, due to any reason (such as load balancing, etc.)], the transmitter transmits the IAB transport migration modification request for the one or more traffics [see fig. 9: Step(s) “105”/ “110”, pgs. 6-7, ¶131 lines 1-13, the source Donor-CU “20” triggers the handover procedure by sending a handover request, with additional information, to the target Donor-CU “30” (i.e. CU “2”)].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
United States Patent Application Publication: Muhammad et al. (US 2022/0183105 A1); see fig. 13, pg. 7, ¶111.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RUSHIL P SAMPAT whose telephone number is (469) 295-9141. The examiner can normally be reached on Mon-Fri (8 AM - 5 PM).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ian Moore can be reached on (571) 272-3085. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/RUSHIL P. SAMPAT/Primary Examiner- TC 2400, Art Unit 2469
Prosecution Insights