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
Claims 1, 33, and 42 have been amended.
Claims 1, 3, 5-9, 33, 35, and 37-42 are pending.
1. Applicant’s arguments with respect to the claim(s) have been considered but are moot in view of the new ground(s) of rejection.
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 1, 7-9, 33, 39-42 are rejected under 35 U.S.C. 103 as being unpatentable over HSIEH (WO 2019246446 A1, hereinafter, “HSIEH”, provided in the IDS by the applicant) in view of “(TP for NR IAB), BL CR for TS 38.401): Intra IAB donor-CU topology adaptation procedure” published on October 2019, hereinafter, “Huawei”, provided in the IDS on 03/23/2023 by the applicant, and further in view of ADJAKPLE et al. (US 20210282050, hereinafter, “ADJAKPLE”).
Claim 1. HSIEH teaches: A method for wireless communication, comprising: - See Fig. 10
receiving, by a receiving device, a radio resource control (RRC) message sent from a transmitting device, the RRC message comprising first information which indicates inter IAB- donor migration related information, - See Fig. 10, ¶ [0115] & ¶ [0132], (“Responsive to receiving the Handover Request Acknowledgement message 1006 from the Target IAB-Donor 125, the Source IAB-Donor 123 forwards the Node RRC Reconfiguration message to the IAB-Node 830 and the UE RRC Reconfiguration messages to the connected UE 110.”, this shows that IAB-Node 830 and UE 110 receive RRC messages from Source IAB-Donor 123 (transmitting device); The Handover Request Acknowledgment message confirms the migration process and the RRC reconfiguration messages carry the migration-related details)
the transmitting device comprising one of a subset, the subset comprising at least one of a target nodeB (gNB), a target gNB central unit (gNB-CU), a source gNB, and a source gNB-CU, - See Fig. 10, ¶ [0115], ¶ [0132], (“the Source IAB-Donor 123 forwards the Node RRC Reconfiguration message to the IAB-Node 830 and the UE RRC Reconfiguration messages to the connected UE 110.”, this shows that IAB-Node 830 and UE 110 receive RRC messages from Source IAB-Donor 123 (transmitting device))
wherein the first information indicates one of a second subset, - See Fig. 10, ¶ [0115] & ¶ [0132], (“Responsive to receiving the Handover Request Acknowledgement message 1006 from the Target IAB-Donor 125, the Source IAB-Donor 123 forwards the Node RRC Reconfiguration message to the IAB-Node 830 and the UE RRC Reconfiguration messages to the connected UE 110.”, this shows that IAB-Node 830 and UE 110 receive RRC messages from Source IAB-Donor 123 (transmitting device); The Handover Request Acknowledgment message confirms the migration process and the RRC reconfiguration messages carry the migration-related details)
HSIEH does not explicitly teach:
wherein the first information indicates one of a second subset, the second subset comprising at least one of a successful status of the inter-donor migration, an ongoing status of the inter-donor migration, a failed status of the inter-donor migration, or a starting status of the inter-donor migration; and in response to receiving the first information indicating the successful status of the inter- donor migration, triggering, by the receiving device, to send one or more packet data convergence protocol (PDCP) status reports to a target IAB-donor, and resuming, by the receiving device, data transmission of radio bearers.
However, Huawei teaches:
wherein the first information indicates one of a second subset, the second subset comprising at least one of a successful status of the inter-donor migration, an ongoing status of the inter-donor migration, a failed status of the inter-donor migration, or a starting status of the inter-donor migration; - See Section 2.2, Candidate solution 1, (“When IAB node has finished its migration, PDCP status report can be requested to each downstream UE of migrating IAB node. IAB donor CU can perform retransmission based on the receiving PDCP status report.”, This indicates a successful status of the inter-donor migration.) and
in response to receiving the first information indicating the successful status of the inter- donor migration, triggering, by the receiving device, to send one or more packet data convergence protocol (PDCP) status reports to a target IAB-donor, and resuming, by the receiving device, data transmission of radio bearers. - See Section 2.2, Candidate solution 1, (“When IAB node has finished its migration, PDCP status report can be requested to each downstream UE of migrating IAB node. IAB donor CU can perform retransmission based on the receiving PDCP status report.”)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified HSIEH with Huawei to include a second subset comprising at least one of a successful status of the inter-donor migration, an ongoing status of the inter-donor migration, a failed status of the inter-donor migration, or a starting status of the inter-donor migration, as taught by Huawei. One of ordinary skill in the art would have been motivated to make this modification to reduce unnecessary retransmissions and improve performance by including the inter-donor migration status in the RRC message, as suggested by Huawei, Therefore, how the IAB donor CU knows the unsuccessfully transmitted downlink data should be studied…In this solution, new trigger condition for PDCP status report need to be introduced. - See Section 2.2
Combination of HSIEH and Huawei does not explicitly teach:
in response to receiving the first information indicating the successful status of the inter- donor migration, triggering, by the receiving device, to send one or more packet data convergence protocol (PDCP) status reports to a target IAB-donor, and resuming, by the receiving device, data transmission of radio bearers.
However, ADJAKPLE teaches:
in response to receiving the first information indicating the successful status of the inter- donor migration, triggering, by the receiving device, to send one or more packet data convergence protocol (PDCP) status reports to a target IAB-donor, - See Fig. 4, 6, ¶ [0033], (“The receiving PDCP entity may also trigger PDCP acknowledgment when, for example, the receiving side of the PDCP entity receives a request from a transmitting side of the PDCP peer entity, to send PDCP Acknowledgment.”); ¶ [0037], (“Based on a trigger or a status request, the apparatus can generate a PDCP status report, and send the PDCP status report to the Integrated Access and Backhaul (IAB) node.”) and resuming, by the receiving device, data transmission of radio bearers. - See Fig. 1, 4, ¶ [0084], (“start/resume data transmission for a specific bearer…”); ¶ [0048], (“examples described herein…may apply to both transmissions over Data Radio Bearers (DRBs) or transmissions over Signaling Radio Bearers (SRBs).”)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified HSIEH and Huawei with ADJAKPLE to include triggering by the receiving device and resuming, by the receiving device, data transmission of radio bearers, as taught by ADJAKPLE. Huawei teaches sending PDCP status reports after successful IAB donor migration, while ADJAKPLE teaches that a receiving device can trigger PDCP status reports based on a trigger event and resume data transmission of radio bearers. One of ordinary skill in the art would have been motivated to make this modification to avoid unnecessary retransmissions, as suggested by ADJAKPLE, without proper buffer management, the likelihood of buffer overflow at IAB node may be high, which may lead to unnecessary retransmissions over the backhaul and inefficient usage of radio resources. - ¶ [0029]
Claim 7. Combination of HSIEH, Huawei, and ADJAKPLE teaches The method according to claim 1, - refer to the indicated claim for reference(s).
HSIEH teaches:
wherein: the receiving device comprises at least one user equipment (UE) connecting to a migrating IAB-node. - See Fig. 10, ¶ [0115], (“FIG. 10 illustrates an example of data and control transmissions for an IAB-Node (node base station) and connected User Equipment (UE) to handover from a Source IAB-Donor (source donor base station) to a Target IAB-Donor (target donor base station)”)
Claim 8. Combination of HSIEH, Huawei, and ADJAKPLE teaches The method according to claim 1, - refer to the indicated claim for reference(s).
HSIEH teaches:
wherein: the receiving device comprises at least one user equipment (UE) connecting to a downstream IAB-node of a migrating IAB-node. - See Fig. 8, ¶ [0070], (“to support the Mobile-Termination (MT) function of subtending (downstream) IAB-Nodes. Via the MT function, an IAB-Node connects to an intermediate (upstream) IAB-Node or the IAB-Donor…Source DU 822 supports the MT function 834 of IAB-Node 832 via a wireless backhaul link 807 (Uu interface 807 (Uu 807)), and the DU 836 of IAB-Node 832 connects via a wireless backhaul link 809 (Uu interface 809 (Uu 809)) with the Mobile-Termination 844 (MT 844) of IAB-Node 842.”, this shows that the UE connected to downstream IAB-nodes can be supported by IAB-Node 832 via the MT function of the upstream node); See Fig. 10, ¶ [0115 – 0116], (“In aspects, the handover of an IAB-Node 830 from a Source IAB-Donor 123 to a Target IAB-Donor 125 may be applied to subtending IAB-Nodes and User Equipment devices connected to such subtending IAB-Nodes.”, this directly supports that the handover involves subtending IAB-Nodes (which are downstream of the migrating IAB-node 830) and UE connected to those downstream nodes)))
Claim 9. Combination of HSIEH, Huawei, and ADJAKPLE teaches The method according to claim 1, - refer to the indicated claim for reference(s).
HSIEH teaches:
wherein: the receiving device comprises at least one downstream IAB-node of a migrating IAB- node. - See Fig. 8, ¶ [0070], (“to support the Mobile-Termination (MT) function of subtending (downstream) IAB-Nodes. Via the MT function, an IAB-Node connects to an intermediate (upstream) IAB-Node or the IAB-Donor…Source DU 822 supports the MT function 834 of IAB-Node 832 via a wireless backhaul link 807 (Uu interface 807 (Uu 807)), and the DU 836 of IAB-Node 832 connects via a wireless backhaul link 809 (Uu interface 809 (Uu 809)) with the Mobile-Termination 844 (MT 844) of IAB-Node 842.”, IAB-Node 842 (receiving device) is a downstream IAB-node to IAB-Node 832 (migrating IAB- node)); See Fig. 10, ¶ [0115 – 0116], (“the handover of an IAB-Node 830 from a Source IAB-Donor 123 to a Target IAB-Donor 125 may be applied to subtending IAB-Nodes and User Equipment devices connected to such subtending IAB-Nodes.”, this supports that subtending IAB-Nodes (which are downstream of the migrating IAB-node 830) are part of the handover process)
Claim 33 is the apparatus claim corresponding to the method claim of claim 1 and is rejected under the same rationale as Claim 1 since they recite nearly identical limitations.
Claims 39-41 are rejected under the same rationale as Claims 7-9 since they recite nearly identical limitations.
Claim 42 is rejected under the same rationale as Claim 1 since they recite nearly identical limitations.
Claims 3, 5-6, 35, 37-38 are rejected under 35 U.S.C. 103 as being unpatentable over HSIEH (WO 2019246446 A1, hereinafter, “HSIEH”, provided in the IDS by the applicant) in view of “(TP for NR IAB), BL CR for TS 38.401): Intra IAB donor-CU topology adaptation procedure” published on October 2019, hereinafter, “Huawei”, provided in the IDS on 03/23/2023 by the applicant, and further in view of ADJAKPLE et al. (US 20210282050, hereinafter, “ADJAKPLE”) and JANG et al. (US 20200053600, hereinafter, “JANG”, provided in the IDS by the applicant).
Claim 3. Combination of HSIEH, Huawei, and ADJAKPLE teaches The method according to claim 1, - refer to the indicated claim for reference(s).
Combination of HSIEH, Huawei, and ADJAKPLE does not explicitly teach:
wherein: the one or more PDCP status reports correspond to a radio link control acknowledged mode (RLC-AM) bearer which has been configured to be required to send the one or more PDCP status reports in an uplink.
However, JANG teaches:
wherein: the one or more PDCP status reports correspond to a radio link control acknowledged mode (RLC-AM) bearer which has been configured to be required to send the one or more PDCP status reports in an uplink. - in ¶ [0365], (“If the handover is successfully completed in the target cell (for example, when transmission of the HO complete message starts or the random access succeeds if the target uses the dedicated random access resource, the terminal may trigger the PDCP status report-AM for the RLC-AM bearer in which the statusReportRequiredforHO is configured and transmit it to the base station and may trigger the PDCP status report-AM for the RLC-UM bearer in which the statusReportRequiredforUEHO is configured and transmit it to the base station (4c-41).”, this shows that successful handover (eq. successful inter-donor migration) triggers the sending of a PDCP status report for an RC-AM bearer to the target base station (target IAB donor). The configuration to require the PDCP status report in the uplink is mentioned.)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified HSIEH, Huawei, and ADJAKPLE with JANG to include the PDCP status reports correspond to a RLC-AM bearer which has been configured to be required to send the PDCP status report in an uplink, as taught by JANG. One of ordinary skill in the art would have been motivated to make this modification to ensure successful and failed inter-donor migration(s) are managed effectively which improves system reliability and minimizes data loss, as suggested by JANG, The present disclosure is directed to provision of a method of processing data without a loss when a terminal based handover is performed in a wireless communication system. - ¶ [0010]
Claim 5. Combination of HSIEH, Huawei, and ADJAKPLE teaches The method according to claim 1, - refer to the indicated claim for reference(s).
Combination of HSIEH, Huawei, and ADJAKPLE does not explicitly teach:
wherein: in response to the first information indicating the ongoing status of the inter-donor migration or the starting status of the inter-donor migration, the receiving device stops data transmission of all radio bearers.
However, JANG teaches:
wherein: in response to the first information indicating the ongoing status of the inter-donor migration or the starting status of the inter-donor migration, the receiving device stops data transmission of all radio bearers. - in ¶ [0363], (“When the handover condition is satisfied as described above, the data transmission/reception to/from the source cell 4c-03 stops and the movement to the selected target cell is made.”, this describes when the migration (handover) is in progress (either ongoing or starting), the receiving device stops data transmission from the source, which includes all radio bearers)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified HSIEH, Huawei, and ADJAKPLE with JANG to include stopping data transmission during ongoing or starting migration, as taught by JANG. One of ordinary skill in the art would have been motivated to make this modification to avoid incomplete or unsuccessful transmissions which minimizes data loss, as suggested by JANG, The present disclosure is directed to provision of a method of processing data without a loss when a terminal based handover is performed in a wireless communication system. - ¶ [0010]
Claim 6. Combination of HSIEH, Huawei, and ADJAKPLE teaches The method according to claim 1, - refer to the indicated claim for reference(s).
Combination of HSIEH, Huawei, and ADJAKPLE does not explicitly teach:
wherein: in response to the first information indicating the failed status of the inter-donor migration, the receiving device stops or cancels behaviors related to the inter-donor migration.
However, JANG teaches:
wherein: in response to the first information indicating the failed status of the inter-donor migration, - in ¶ [0365], (“The PDCP status report-AM consists of a first missing PDCP sequence number (FMS) and BITMAT (packets which are successfully received or are not successfully received after the FMS value are transmitted in a bitmap form, for example, 1 indicates the reception success and 0 indicates reception failure)”)
the receiving device stops or cancels behaviors related to the inter-donor migration. - in ¶ [0365], (“Accordingly, the terminal deletes the PDCP SDU notified that the base station has successfully received from the buffer, thereby preventing unnecessary transmission.”, this shows that in case of a failure, the terminal cancels migration-related behaviors (such as unnecessary transmission) by deleting buffered PDCP SDUs)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified HSIEH, Huawei, and ADJAKPLE with JANG to include stopping or canceling actions if migration fails, as taught by JANG. One of ordinary skill in the art would have been motivated to make this modification to avoid incomplete or unsuccessful transmissions which minimizes data loss, as suggested by JANG, The present disclosure is directed to provision of a method of processing data without a loss when a terminal based handover is performed in a wireless communication system. - ¶ [0010]
Claim 35 is rejected under the same rationale as Claim 3 since they recite nearly identical limitations.
Claims 37-38 are rejected under the same rationale as Claims 5-6 since they recite nearly identical limitations.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Shima Wasel whose telephone number is (703)756-4725. The examiner can normally be reached Monday - Friday 8:00 am - 5:00 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, Khaled Kassim can be reached at (571) 270-3770. 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.
/SHIMA WASEL/Patent Examiner, Art Unit 2475
/KHALED M KASSIM/supervisory patent examiner, Art Unit 2475
Prosecution Insights