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 .
Claim Rejections – 35 USC§ 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)(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.
Claims 19, 20, 22, 23, 28, 30, 32, 35, 56, 59, 60, 62,65, 67, 69, 73-92 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Belleschi et al(US 2024/0205727 A1).
Regarding claims 19, 56 and 73, Belleschi ‘727 teaches, apparatus for a source donor Central Unit, CU([0101]-[0103], [0139] and Figs.11, 16, first radio network node(source donor CU)), for use in a process for migrating resources from a source Integrated Access and Backhaul, IAB, topology to a target IAB topology of a communication system([0071]-[0072], a method for inter-doner topology adaptation (inter CU migration) in an IAB network, where traffic or a top-level IAB node is migrated from a source donor CU to a target donor CU), each of the source IAB topology and the target IAB topology comprising a set of IAB nodes and a donor Central Unit, CU([0101]-[0103], [0139] and Figs.11, 13,16, first radio network node(source donor CU) managing migration of its traffic to second network node(target donor CU)), the apparatus comprising:
one or more processing units ([0246] and Fig. 16, the source/first donor CU comprising processing circuitry) configured to; send, to a target donor CU of the target IAB topology, a migration request ([0103], [0179], [0211]. [0212] and Fig. 12a, first radio network node (source CU) transmitting an indication (handover request message) to a second radio network node (target CU) to initiate the migration or load sharing procedure)
including at least one item of traffic migration information([0178]- [0179] and Fig. 12a, the transmitted indication includes delay information (the Packet Delay Budget or PDP), each item of the at least one item of traffic migration information item for indicating the resource requirements for traffic to be migrated from the source IAB topology to the target IAB topology([0103], [0109], [0178]-[0179] and Fig. 12a, the indication includes PDB which specifies the latency/resource requirements that the target CU must sustain/provide for the migrated traffic)
each item of the at least one item of traffic migration information including an identifier for use in uniquely identifying the respective item of traffic migration information and the traffic to be migrated associated with the respective item of traffic migration information ([0211], [0232] and Fig. 12, the PDP is calculated and indicated per BH RLC channel. The BH RLC channel ID is used to uniquely identify both the traffic routing path and the specific QoS/delay requirements associated with it); receive, from the target donor CU, a migration response ([0103], [0180] and Fig. 12a, the source donor CU receives a response (a PDP acknowledgment message) from the target donor CU indicating whether the requirements can be met), wherein the received migration response includes at least one identifier for use in uniquely identifying the traffic associated with the respective item of traffic migration information that has been accepted by the target donor CU ([0214], [0232], the target CU transmits a response confirming that the QoS requirements (the PDP) can be handled. When the target CU can meet the requirements, specific BH RLC channels, identified by their BH RLC channel IDs are accepted and routed via the new path).
Regarding claim 20, Belleschi ‘727 teaches, wherein each item of the at least one item of traffic migration information includes at least one of:
bandwidth required to support traffic to be migrated([0236], the negotiation can be applied to other QoS parameter such as bit rate requirements( bit rate is the standard measure of bandwidth)); number of IAB nodes of the source IAB topology to be migrated([0188], [0240], [0241], indicating whether migrating the whole IAB node or number hops) ; number of User Equipment, UE, to be migrated; maximum level of Quality of Service, QoS, required for the migration([0103], [0191], [0209], end to end latency requirements and SQI (5G QoS identifier) parameters the PDP represents an upper bound (maximum) for acceptable delay for the migrated traffic).
Regarding claims 22 and 59, Belleschi ‘727 teaches, wherein sending comprises sending, to the target donor CU, a migration request message including the migration request, wherein the migration request message includes, for each item of traffic migration information, ([0103], [0179], [0211]. [0212] and Fig. 12a, first radio network node (source CU) transmitting an indication (handover request message) to a second radio network node (target CU) to initiate the migration or load sharing procedure) at least one of the following Information Elements, IEs:
an IE indicating a maximum uplink bandwidth load required for uplink traffic to be migrated;
an IE indicating a maximum downlink bandwidth required for downlink traffic to be migrated;
an IE indicating one or more levels of Quality of Service, QoS, required for migration ([0103], [0209], [0211], [0214], end to end latency requirements and SQI (5G QoS identifier) parameters the PDP represents an upper bound (maximum) for acceptable delay for the migrated traffic, notice the claim limitation is written in alternative form thus examiner is required to show only one of the alternative claim limitations);
an IE indicating a number of IAB nodes of the source IAB topology to be migrated; an IE indicating a number of User Equipment, UE, to be migrated.
Regarding claims 23 and 60, Belleschi ‘727 teaches, wherein each item of traffic migration information further includes priority information for indicating a priority of the respective migration ([0098], [0239], [0240], the IAB control Plane Traffic Type IE indicates the priority of control plane BH RLC channel. The priority information is provided per hop for channels to be migrated).
Regarding claims 28 and 65, Belleschi ‘727 teaches, wherein receiving comprises receiving, from the target donor CU, a migration response message including the migration response ([0103], [0180] and Fig. 12a, the source donor CU receives a response (a PDP acknowledgment message) from the target donor CU indicating whether the requirements can be met), wherein the migration response message comprises at least one of the following Information Elements, IEs: an IE indicating traffic of a respective item of traffic migration information has been accepted for([0214], [0232], a response confirming that QoS requirements can be handled, where specific BH RLC channels identified by BH RLC channel IDs are accepted and routed via the new path); an IE identifying all of the traffic indicated in the migration request are accepted([0188], the scenario where the whole IAB node is migrated in which case all the BH RLC channels configured to this IAB node are migrated to the target CU upon confirmation); an IE indicating migration capability information of the target IAB topology ([0215], [0229], when requirements cannot be handled, the response message may contain cumulative PDB that can be sustained by the target donor CU for each channel and this sustained PDP indicates the target topology’s migration capability, notice the claim limitation is written in alternative claim limitation thus examiner is required show only one of the alternative claim limitations).
Regarding claims 30 and 67, Belleschi ‘727 teaches, wherein the migration capability information includes at least one of: maximum bandwidth available for supporting additional traffic ([0236], considering the bit rate requirements(bandwidth);
maximum number of additional IAB nodes that can be supported;
maximum number of additional User Equipment, UE, that can be supported; one or more levels of Quality of Service, QoS, that can be supported ([0035], [0215], [0229], when requirements cannot be handled, the response message may contain cumulative PDB that can be sustained by the target donor CU for each channel. PDP is explicitly defined as a 5G QoS identifier parameter, notice the claim limitation is written in alternative claim limitation thus examiner is required show only one of the alternative claim limitations).
Regarding claims 32 and 69, Belleschi ‘727 teaches, further comprising determining a need to migrate resources from the source IAB topology: wherein determining traffic which is to be migrated includes determining traffic which is to be migrated from the source IAB topology to the target IAB topology in the case where it is determined that there is a need to migrate resources from the source IAB topology([0139] source CU may determine initiation for topology adaptation such as determine a congestion or initiates a load balancing between CUs),
wherein in a case where the determined traffic to be migrated is classified into multiple types, the migration request including two or more items of traffic migration information is sent to the target donor CU ([0211], [0221], transmitting an indication value (PDB/QoS requirements for each BH RLC channel of an IAB node since the request contains separate requirement items for each individual channel /traffic type).
Regarding claim 35, Belleschi ‘727 teaches, a method for use in a process for migrating traffic from a source Integrated Access and Backhaul, IAB, topology to a target IAB topology of a communication system([0071]-[0072], a method for inter-doner topology adaptation (inter CU migration) in an IAB network, where traffic or a top-level IAB node is migrated from a source donor CU to a target donor CU), each of the source IAB topology and the target IAB topology comprising a set of IAB nodes and a donor Central Unit, CU([0101]-[0103], [0139] and Figs.11, 13,16, first radio network node(source donor CU) managing migration of its traffic to second network node(target donor CU)), the method comprising:
send, to a target donor CU of the target IAB topology, a migration request ([0103], [0179], [0211]. [0212] and Fig. 12a, first radio network node (source CU) transmitting an indication (handover request message) to a second radio network node (target CU) to initiate the migration or load sharing procedure)
including at least one item of traffic migration information([0178]- [0179] and Fig. 12a, the transmitted indication includes delay information (the Packet Delay Budget or PDP), each item of the at least one item of traffic migration information item for indicating the resource requirements for traffic to be migrated from the source IAB topology to the target IAB topology([0103], [0109], [0178]-[0179] and Fig. 12a, the indication includes PDB which specifies the latency/resource requirements that the target CU must sustain/provide for the migrated traffic)
each item of the at least one item of traffic migration information including an identifier for use in uniquely identifying the respective item of traffic migration information and the traffic to be migrated associated with the respective item of traffic migration information ([0211], [0232] and Fig. 12, the PDP is calculated and indicated per BH RLC channel. The BH RLC channel ID is used to uniquely identify both the traffic routing path and the specific QoS/delay requirements associated with it);
receiving, by the target donor CU, the migration request sent by the source donor CU ([0179], and Fig. 12a, the target CU receiving the indication remitted by the source CU) ;
determining, by the target donor CU, based on the received migration request, whether the target IAB topology can support the resource requirements of the traffic to be migrated([0213], [0214], [0228], the target node determining if the indicated delay information /PDP requirements can be sustained by the nodes in its topology) ;
in the case where it is determined the target IAB topology can support the resource requirements of the traffic to be migrated, sending, by the target donor CU to the source donor CU, a migration accept response including at least one identifier for use in uniquely identifying traffic associated with the respective item of traffic migration information that has been accepted by the target donor CU([0213, [0214], [0232], [0233] and Fig. 12, if the requirements are met the target CU transmits a response confirming acceptance. BH-RLC channels identified by BH RLC channel IDs are confirmed and routed via the new path);
in a case where it is determined that the target IAB topology cannot support the resource requirements of all traffic to be migrated, sending, by the target donor CU to the source donor CU, a migration reject response indicating all traffic indicated in the migration request has not been accepted by the target donor CU ([0213, [0215], [0229] and Fig. 12, sending a response indicating rejection to be able to meet a requirement of delay in case where the requirements cannot be handled by the target donor).
Regarding claim 62, Belleschi ‘727 teaches, wherein the one or more processing units are configured to receive, from the target donor CU, a migration response message including the migration response, wherein the migration response message includes an IE that indicates an identifier for uniquely identifying traffic that has been accepted by the target donor CU([0232], [0233], during confirmation, the specific BH RLC channels, identified by BH RLC channel IDs are accepted and routed via the new path. The BH RLC channel ID functions as the unique identifier for the accepted traffic).
Regarding claim 74, Belleschi ‘727 teaches, wherein the migration request includes two or more items of traffic migration information( [0211], [0221], transmitting an indication value (PDB/QoS requirements for each BH RLC channel of an IAB node since the request contains separate requirement items for each individual channel /traffic type).
Regarding claims 75 and 84, Belleschi ‘727 teaches, wherein the migration response indicates that traffic to be migrated has been accepted and includes the at least one identifier for uniquely identifying traffic that has been accepted by the target donor CU ([0232], [0233], during confirmation, the specific BH RLC channels, identified by BH RLC channel IDs are accepted and routed via the new path. The BH RLC channel ID functions as the unique identifier for the accepted traffic).
Regarding claims 76, 85 and 90 Belleschi ‘727 teaches, wherein each item of the at least one item of traffic migration information includes information for indicating one or more levels of Quality of Service, QoS, required for the migration ([0103], [0209], [0211], [0214], end to end latency requirements and SQI (5G QoS identifier) parameters the PDP represents an upper bound (maximum) for acceptable delay for the migrated traffic).
Regarding claims 77 and 86, Belleschi ‘727 teaches, wherein sending comprises sending, to the target donor CU, a migration request message including the migration request([0212 and Fig. 12a, the migration indication may be carried on the handover preparation phase as part of handover request), wherein the migration request message includes, for each item of traffic migration information, an Information Element, IE, indicating the resource requirement of the traffic to be migrated, and an IE for the identifier([0097], [0098], [0211] , legacy QoS IEs to communicate QoS requirements such as PDP and bit rate for the channels and these are provided for each BH RLC channel).
Regarding claim 78, Belleschi ‘727 teaches, wherein receiving comprises receiving, from the target donor CU, a migration response message including the migration response, wherein the migration response message includes an IE that indicates an identifier for uniquely identifying traffic that has been accepted by the target donor CU([0098], [0232]. [0233] the target donor responds with a list of BH RLC channels (e.g. identified by BH RLC channel IDs) that can be handled. BH RLC CH ID are identified as an IE used in the messaging to identify specific traffic flow).
Regarding claims 79 and 87, Belleschi ‘727 teaches, determining traffic which is to be migrated from the source IAB topology to the target IAB topology ([0178], [0188] and Fig. 12a, source CU determining/selecting one or more backhaul channels selected for migration to a second node); specifying resource requirements corresponding to the determined traffic to be migrated ([0178] and Fig. 12a, determining PDP related information).
Regarding claim 80, Belleschi ‘727 teaches, wherein in a case where the migration request includes two or more items of traffic migration information, the determining by the target donor CU whether the target IAB topology can support the resource requirement of the traffic is performed for each item of traffic migration information([0213], [0228] and [0232] the target donor CU checks in one or more of the backhaul channels and/or their requirement of delay are matching its radio conditions and resources, where the check is performed for each ingress and egress backhaul(BH) Radio Link Control channel).
Regarding claim 81, Belleschi ‘727 teaches, wherein the identifier included in the migration response identifies traffic to be migrated of the resource requirement that has been determined, by the target donor CU, the target IAB topology can support([0214], [0232], [0233], the response identifying which specific BH RLC channels are accepted and routed via the new path based on the determination that the specific latency/resource requirements for those channel can be handled by the target donor).
Regarding claims 82, 89 and 92 Belleschi ‘727 teaches, wherein the migration reject response includes information for indicating why the target donor CU does not accept the traffic to be migrated ([0215], [0229], the response message includes cumulative PDB that can be sustained by the target donor CU which allows the source to determine the reason (e.g. latency constraints) for the rejection/failure).
Regarding claim 83, Belleschi ‘727 teaches, wherein the migration request includes two or more items of traffic migration information([0211], [0221], transmitting an indication value (PDB/QoS requirements for each BH RLC channel of an IAB node since the request contains separate requirement items for each individual channel /traffic type).
Regarding claims 88 and 91, Belleschi ‘727 teaches, apparatus for a source donor Central Unit, CU([0101]-[0103], [0139] and Figs.11, 16, first radio network node(source donor CU)), for use in a process for migrating resources from a source Integrated Access and Backhaul, IAB, topology to a target IAB topology of a communication system([0071]-[0072], a method for inter-doner topology adaptation (inter CU migration) in an IAB network, where traffic or a top-level IAB node is migrated from a source donor CU to a target donor CU), each of the source IAB topology and the target IAB topology comprising a set of IAB nodes and a donor Central Unit, CU([0101]-[0103], [0139] and Figs.11, 13,16, first radio network node(source donor CU) managing migration of its traffic to second network node(target donor CU)), the apparatus comprising:
one or more processing units([0246] and Fig. 16, the source/first donor CU comprising processing circuitry) configured to; send, to a target donor CU of the target IAB topology, a migration request ([0103], [0179], [0211]. [0212] and Fig. 12a, first radio network node (source CU) transmitting an indication (handover request message) to a second radio network node (target CU) to initiate the migration or load sharing procedure) including at least one item of traffic migration information([0178]- [0179] and Fig. 12a, the transmitted indication includes delay information (the Packet Delay Budget or PDP), each item of the at least one item of traffic migration information item for indicating the resource requirements for traffic to be migrated from the source IAB topology to the target IAB topology([0103], [0109], [0178]-[0179] and Fig. 12a, the indication includes PDB which specifies the latency/resource requirements that the target CU must sustain/provide for the migrated traffic)
each item of the at least one item of traffic migration information including an identifier for use in uniquely identifying the respective item of traffic migration information and the traffic to be migrated associated with the respective item of traffic migration information([0211], [0232] and Fig. 12, the PDP is calculated and indicated per BH RLC channel. The BH RLC channel ID is used to uniquely identify both the traffic routing path and the specific QoS/delay requirements associated with it);
receive, from the target donor CU, a migration reject response for indicating all traffic indicated in the migration request has not been accepted by the target donor CU([0180], [0213], [0215] and Fig. 12a, the source CU receiving a response from the target CU indicating confirmation or rejection to be able to meet a requirement of delay, [0215] defines the case where QoS requirements cannot be handled by the target donor).
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.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 33 and 70 are rejected under 35 U.S.C. 103 as being unpatentable over Belleschi ‘727 in view of Liu et al (US 2023/0262827 A1).
Regarding claims 33 and 70, Belleschi ‘727 teaches all claim limitations except, receiving, from the target donor CU, a notification indicating that the IAB node of the source IAB topology has initiated a backhaul link re-establishment procedure and wherein determining a need to migrate resources comprises determining a need to migrate resources from the source IAB topology based on the received notification.
Liu ‘827 teaches, receiving, from the target donor CU, a notification indicating that the IAB node of the source IAB topology has initiated a backhaul link re-establishment procedure ([0261], [0263] and Fig. 12, after the recovery IAB-MT sends an RRC re-establishment request to the target IAB donor CU(Step 1) the target IAB donor-CU sends a retrieve UE context request message to the source IAB donor-CU. This message serves as the notification that the re-establishment procedure has been initiated at the target) and wherein determining a need to migrate resources comprises determining a need to migrate resources from the source IAB topology based on the received notification ([0265], [0268] and Fig. 12, when receiving the retrieve UE context request, the source IAB donor CU is triggered to migrate the resources by sending a retrieve UE context response back to the target IAB donor-CU. This response contains the context of the IAB node including the configuration of the backhaul resources).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the communication system of Belleschi ‘727 by incorporating the teaching of Liu’827, since such modification would enable, a target parent node of the first IAB node to flexibly configure a communication resource of the first IAB node based on configuration information of a BH RLC CH from an IAB donor, as suggested by Liu ‘827([006]).
Internet Communications
Applicant is encouraged to submit a written authorization for Internet communications (PTO/SB/439, which can be found: http://www.uspto.gov/sites/default/files/documents/sb0439.pdf) in the instant patent application to authorize the examiner to communicate with the applicant via email. The authorization will allow the examiner to better practice compact prosecution. The written authorization can be submitted via one of the following methods only: (1) Central Fax which can be found in the Conclusion section of this Office action; (2) regular postal mail; or (3) EFS WEB. Written authorization submitted via other methods, such as direct fax to the examiner or email, will not be accepted. See MPEP § 502.03.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AWET A HAILE whose telephone number is (571)270-3114. The examiner can normally be reached Monday through Friday 8:30 AM - 4:30 PM EST.
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, Michael Thier can be reached at (571)272-2832. 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.
/AWET HAILE/Primary Examiner, Art Unit 2474
Prosecution Insights