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 .
Summary
This action is in reply to Applicant’s Amendments and Remarks filed on 01/20/2026.
Claims 1-8 and 10-17 are pending.
Claims 9 and 18 have been cancelled.
Response to Arguments
Applicant’s arguments filed on 01/10/2026 with respect to claims 1-8 and 10-17 have been considered but they are not persuasive.
The Applicant presented argument that Vivo at Section 2 explains that "UE experiences MCG link failure." Then Vivo at Section 2.1 describes a successful fast recovery of the MCG link failure and Vivo at Section 2.2 describes a procedure when fast recovery fails. Vivo does not mention anything about another MCG failure, much less where the another MCG failure is an integrity check failure or reconfiguration failure and the UE transmits a radio connection re-establishment request message to the MN in response to the integrity check failure or reconfiguration failure.
While the Office appears to allege that Vivo at Section 2.2.1 describes an integrity check failure, the integrity check failure in Vivo occurs during fast recovery of the MCG link. The Vivo integrity check failure is not another MCG failure as recited in claim 1. By contrast, in claim 1, the UE transmits an MCG failure recovery complete message to the MN. Thus, the integrity check failure in claim 1 is not a fast recovery failure of the MCG radio link, but is another MCG failure separate from the MCG radio link failure and recovery. (REMARKS, Page 7)
The Examiner respectfully disagrees, and presents that Claim 1 requires an MCG RLF detection and corresponding successful MCG fast recovery in a first instance, and in a second instance an MCG failure due to integrity check failure or reconfiguration failure causing a the UE transmits a radio connection re-establishment request message to the MN.
VIVO Section 2.1 teaches the first instance as acknowledged by the Applicant.
The Examiner also presents that VIVO Section 2.2.1, noticed by the Applicant, teaches the second instance, since both successful MCG failure recovery, and unsuccessful MCG failure cannot occur during same instance. Therefore Applicant’s argument that the integrity check failure in Vivo occurs during fast recovery of the MCG link, and so the Vivo integrity check failure is not another MCG failure as recited in claim 1, is not persuasive.
Please see also Instant Application Specification –
[0002] This disclosure relates generally to wireless communications and, more particularly, to fast recovery with a master node due to integrity check failure or reconfiguration failure..
In above [0002] indicates integrity check failure or reconfiguration failure associated with MCG fast recovery.
Therefore, VIVO teaches recovery procedures for both successful MCG fast recovery and unsuccessful MCG fast recovery integrity check failure or reconfiguration failure with subsequent recovery processes from MCG failures.
However, it is not clear if VIVO disclosing there are two distinct MCG failure instances at different times since VIVO discloses (Page 2 Section 2.2.1. Fast recovery failure) -
“After triggering fast recovery procedure, if the procedure succeeds, UE will recover the MCG link. But if the fast recovery timer expires and UE did not receive fast recovery RRC reconfiguration message the fast recovery can be considered as failed.”, although it would be obvious to a person skill in the art about how VIVO’s technique would work in case of two distinct and separate instances of MCG failures – the first instance to end with successful MCG fast recovery as in VIVO Section 2.1 , and the second instance to end with UE would trigger re-establishment procedure as in VIVO Section 2.2.1.
The Applicant further presented arguments that The UE in Futaki does not perform different procedures (an MCG fast recovery procedure via the SN v. an RRC re-establishment procedure via the MN) for different types of MCG failures (an MCG radio link failure v. an integrity check failure or reconfiguration failure). While Futaki mentions multiple types of MCG failures, Futaki does show or suggest determining which type of procedure to perform via which network element based on the type of MCG failure. (REMARKS, Page 8)
The Examiner respectfully disagrees and presents that Futaki discloses –
[0065] In addition, the message in step 201 explicitly or implicitly indicates that the modification or release of the configuration (or resource) in the SN 2 is related to an MCG failure (e.g., MCG RLF) ……. This indication may indicate, for example, that an MCG failure has occurred, that an MCG failure has been detected, or the type of an MCG failure (e.g., MCG failure type). …….. The RLF is an example of MCG failures. The MCG failure may be, for example, a handover failure, a reconfiguration failure of the MN (or MCG) (Reconfiguration with sync failure, or Reconfiguration failure), or an integrity protection check failure (Integrity protection check failure). The MCG failure type may indicate any of these other MCG failures.
[0072] As described above, the MN 1 may detect the MCG failure based on the reception of MCG failure information from the UE 3.
In above [0065, 0072], Futaki disclosing MCG failure can be due to MCG RLF, reconfiguration failure of the MN (or MCG) (Reconfiguration with sync failure, or Reconfiguration failure), or an integrity protection check failure (Integrity protection check failure), and MCG failure indication may indicate the type of an MCG failure.
Further Futaki discloses –
[0145] Furthermore, the MN 1 explicitly or implicitly transmits a permission to the UE 3 in advance to switch the uplink primary path of the split SRB from the MCG to the SCG. In response to the detection of an MCG failure (e.g., MCG RLF) when the split SRB has been set and the UE has received the permission, the UE sends MCG failure information to the MN 1 via the SCG leg of the split SRB. The transmission of this MCG failure information from the UE 3 to the MN 1 corresponds to step 902 in FIG. 9, for example. After the transmission of the MCG failure information, the procedure for recovering from the MCG failure described in FIG. 5-8, etc. may be performed. On the other hand, if the UE 3 has not received the permission, it may perform an RRC (connection) re-establishment procedure. This allows the MN 1 to control the behavior of the UE 3 (i.e., transmission of MCG failure information or RRC re-establishment) when an MCG failure occurs.
In [0145] Futaki, citing FIG. 5-8 for successful MCG failure recovery instances using SN, discloses a second instance with MCG failure recovery by perform an RRC (connection) re-establishment procedure with MN referring Fig. 9 since UE dis not have permission from MN to initiate recovery via SN, and the failure can be reconfiguration failure of the MN (or MCG) (Reconfiguration with sync failure, or Reconfiguration failure), or an integrity protection check failure (Integrity protection check failure).
Accordingly Claim 1 and claim 10 with similar features are rejected.
Dependent claims 2-8 and 11-17, being dependent on claims 1 and 10, are also rejected or objected for the same reason as above.
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 of this title, 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.
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 1, 8, 10 and 17 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Vivo (R2-1905827 “Remaining issues on MCG fast recovery”, of record, hereinafter ‘VIVO’) in view of Futaki et al. (US 20220256368 A1 with priority of JP 2019-139250, of record, hereinafter ‘FUTAKI’).
Regarding claim 1, VIVO teaches a method for failure recovery in a user equipment (UE) communicating in dual connectivity (DC) with a master node (MN) and a secondary node (SN) (Page 1: Section 1 Introduction
Agreements for MCG fast recovery:
0 MCG fast recovery targets all MRDC architecture options
1: When MCG failure occurs, UE follows SCG failure-like procedure:
i. UE does not trigger RRC connection re-establishment.
ii. UE triggers an MCG failure procedure in which a failure information message is transmitted to the network via SCG.
See also Page 1 Section 2 Discussion Paragraph 1.
Page 2: Figure 1: Fast recovery of MCG link
(Figure 1 showing UE with MN and SN operating under MR-DC), the method comprising:
detecting, by a UE communicating in DC with an MN and an SN, a master cell group (MCG) radio link failure associated with the MN (Page 1: Section 1 Introduction
Agreements for MCG fast recovery:
Page 1: Section 2 Discussion
As described in [1], fast recovery of MCG link in case of MR-DC is to utilize the SCG link and split SRBs for recovery during MCG failure while operating under MR-DC. For example as depicted in figure 1, there are basically 3 states for fast recovery:
UE experiences MCG link failure
Page 2: Figure 1 a. MCG Link Failure experience at UE);
transmitting, by the UE, an MCG failure information message to the SN in response to the MCG radio link failure (Page 1: Section 1 Introduction
Agreements for MCG fast recovery:
0 MCG fast recovery targets all MRDC architecture options
1: When MCG failure occurs, UE follows SCG failure-like procedure:
i. UE does not trigger RRC connection re-establishment.
ii. UE triggers an MCG failure procedure in which a failure information message is transmitted to the network via SCG.
Page 1: Section 2 Discussion
UE experiences MCG link failure
UE has split SRB1 connection on SCG link, UE uses the SCG link to trigger MCG link recovery.
Page 2: Figure 1 b. MCG link fast Recovery Procedure with arrow to MN via SN from UE, UE reports failure to SN, SN forward the failure report to MN
Page 2: Section 2.1 Successful fast recovery
RAN2 agreed on basic MCG fast recovery as: when UE triggers fast recovery UE does not trigger RRC connection re-establishment. Instead UE triggers MCG failure indication procedure in which the MCGFailureInformation message is transmitted to the network. The MCG failure information may include information, such as available measurement results of MCG/SCG and also MCG failure cause, necessary for successful fast recovery.);
receiving, by the UE, an MCG failure recovery message from the SN (
Page 1: Section 2 Discussion
As described in [1], fast recovery of MCG link in case of MR-DC is to utilize the SCG link and split SRBs for recovery during MCG failure while operating under MR-DC. For example as depicted in figure 1, there are basically 3 states for fast recovery:
Page 2: Figure 1 (b): Fast recovery of MCG link
In Figure 1 (b), the return arrow from MN via SN to UE
Page 2: Section 2.1 Successful fast recovery
Observation 1: After triggering MCG fast recovery procedure, UE will await a RRC reconfiguration message from network.
Proposal 2: After fast recovery triggering, if UE receives for fast recovery RRC reconfiguration message before fast recovery timer expire, the fast recovery is considered successful. Otherwise, the fast recovery is considered as failure.);
transmitting, by the UE, an MCG failure recovery complete message to the MN (Page 2: Section 2.1. Successful fast recovery
Proposal 1: After fast recovery triggering, UE starts a timer (T) for reception of fast recovery RRC reconfiguration message from network.
If UE receives the fast recovery RRC reconfiguration message before the timer T expires, UE can send the fast recovery RRC reconfiguration complete and the fast recovery would succeed.
(See also Fig. 3 marked as Prior Art in the Specification of the Instant Application));
detecting, by the UE, an integrity check failure or reconfiguration failure (Page 2 Section 2.2.1. Fast recovery failure
After triggering fast recovery procedure, if the procedure succeeds, UE will recover the MCG link. But if the fast recovery timer expires and UE did not receive fast recovery RRC reconfiguration message the fast recovery can be considered as failed.
The fast recovery failure may be due to the following potential reasons:
- UE could not find a good MCG cell: the MCG failure indication does not contain available MCG measurement result
- During fast recovery procedure SCG failure happens
- Integrity check failure on SCG link
- UE could not apply the received fast recovery RRC reconfiguration); and
transmitting, by the UE, a radio connection re-establishment request message to the MN in response to the expiry of the timer, the integrity check failure, or the reconfiguration failure (
Pages 2-3: Section 2.2.1. Fast recovery failure
If the fast recovery fails, for example due to SCG failure, UE may perform re/establishment like legacy UE behaviour.
Therefore,
Proposal 4: If fast recovery failure occurs, UE would trigger re-establishment procedure.
Page 3: Section 2.2.2. Fast recovery failure indication
If fast recovery fails, for example due to SCG failure during fast recovery, UE would trigger re/establishment. The re/establishment may be done at one of the following nodes:
Source MN: MN where MCG failure occurs
New MN: different from source MN).
VIVO does not explicitly disclose transmitting, by the UE, an MCG failure information message to the SN via signaling radio bearer 3 (SRB3) in an uplink information transfer multi-radio DC (MR-DC) message in response to the MCG radio link failure;
detecting, by the UE, another MCG failure which is an integrity check failure or reconfiguration failure; and
transmitting, by the UE, a radio connection re-establishment request message to the MN in response the integrity check failure or the reconfiguration failure.
In an analogous art, FUTAKI teaches transmitting, by the UE, an MCG failure information message to the SN via signaling radio bearer 3 (SRB3) in an uplink information transfer multi-radio DC (MR-DC) message in response to the MCG radio link failure (
[0003] SRB3, on the other hand, is a direct SRB between the SN and the UE, which can be used by the SN to send SN RRC messages via an SCG cell to the UE in DC.
Fig. 2, [0067] In some implementations, the MN 1 may decide to initiate an MCG recovery procedure in response to receiving MCG failure information (or MCG failure indication) from the UE 3 via the SN 2 (i.e., via a split SRB, or SRB3 and Xn/X2).);
detecting, by the UE, another MCG failure which is an integrity check failure or reconfiguration failure (
[0065] In addition, the message in step 201 explicitly or implicitly indicates that the modification or release of the configuration (or resource) in the SN 2 is related to an MCG failure (e.g., MCG RLF) ……. This indication may indicate, for example, that an MCG failure has occurred, that an MCG failure has been detected, or the type of an MCG failure (e.g., MCG failure type). …….. The RLF is an example of MCG failures. The MCG failure may be, for example, a handover failure, a reconfiguration failure of the MN (or MCG) (Reconfiguration with sync failure, or Reconfiguration failure), or an integrity protection check failure (Integrity protection check failure). The MCG failure type may indicate any of these other MCG failures.
Fig. 3, [0072] FIG. 3 is a flowchart showing an example of the operation of the MN 1. In step 301, the MN 1 initiates an MCG failure recovery procedure in response to the detection of an MCG failure. As described above, the MN 1 may detect the MCG failure based on the reception of MCG failure information from the UE 3.
(It is obvious from [0065 and 0072] that UE 3 detecting MCG failure due to integrity check failure or reconfiguration failure and informs MN)); and
transmitting, by the UE, a radio connection re-establishment request message to the MN in response the integrity check failure or the reconfiguration failure (
[0061] The MCG is a group of serving cells associated with (or provided by) the MN 1, and includes the SpCell (i.e., Primary Cell (PCell))…
[0072] As described above, the MN 1 may detect the MCG failure based on the reception of MCG failure information from the UE 3.
[0073] In step 302, the MN 1 sends to the SN 2 an SN MODIFICATION REQUEST or SN RELEASE REQUEST message explicitly or implicitly indicating that the modification or release of configuration (or resources) in the SN 2 is relevant to the MCG failure or its recovery, in the MCG recovery procedure.
Fig. 5, [0076] FIG. 5 shows an example of signalling of the MN 1 and the SN 2 performed in an intra-MN handover procedure without SN change.
[0077] The SN MODIFICATION REQUEST message of step 501 further includes an indication to the SN 2 that the message is associated with an MCG failure.
[0078] In step 502, the SN 2 sends an SN MODIFICATION REQUEST ACKNOWLEDGE message to the MN 1 to confirm the request from the MN 1 for the SN (or SCG) resource modification for the UE 3.
[0079] In step 503, the MN 1 transmits an MN RRC message (e.g., RRC Reconfiguration including reconfigurationWithSync) to the UE 3 via the SCG leg of split SRB1.
[0080] Upon receiving the MN RRC message in step 503, the UE 3 performs intra-MN handover without SN change according to the RRC configuration information ….. contained in the MN RRC message.
Fig. 9, [0096] In step 901 of FIG. 9, the UE 3 detects an MCG failure (e.g., MCG RLF). In step 902, the UE 3 transmits MCG failure information to the MN 1 via the SCG leg of Split SRB1. An RRC TRANSFER message may be used to transfer the MCG failure information from the SN 2 to the MN 1. In step 903, the MN 1 determines an MCG failure recovery procedure in response to receiving the MCG failure information. This MCG failure recovery procedure includes an intra-MN handover procedure without SN change (i.e., steps 904-911).
[0145] Furthermore, the MN 1 explicitly or implicitly transmits a permission to the UE 3 in advance to switch the uplink primary path of the split SRB from the MCG to the SCG. In response to the detection of an MCG failure (e.g., MCG RLF) when the split SRB has been set and the UE has received the permission, the UE sends MCG failure information to the MN 1 via the SCG leg of the split SRB. The transmission of this MCG failure information from the UE 3 to the MN 1 corresponds to step 902 in FIG. 9, for example. After the transmission of the MCG failure information, the procedure for recovering from the MCG failure described in FIG. 5-8, etc. may be performed. On the other hand, if the UE 3 has not received the permission, it may perform an RRC (connection) re-establishment procedure. This allows the MN 1 to control the behavior of the UE 3 (i.e., transmission of MCG failure information or RRC re-establishment) when an MCG failure occurs.
(It is obvious from [0065, 0072, 0073, 0076-0080, 0096 and 0147] that (that UE 3 detecting MCG failure due to integrity check failure or reconfiguration failure, informs MN of the MCG of the failure type which is received by the MN as request for radio connection re-establishment with the MCG and MN starts intra-MN handover for connection re-establishment with another MN or PCell in MCG))).
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was made to take the technique of MCG failure recovery of FUTAKI to the system of MCG failure recovery of VIVO in order to take the advantage of method for distinguishing the processing for detecting radio link failure in the Source MCG and allowing the MN to control the behavior of the UE (i.e., transmission of MCG failure information or RRC re-establishment) when an MCG failure occurs (FUTAKI: [0145]).
Regarding claim 8, VIVO, in view of FUTAKI, teaches the method of claim 1, wherein detecting the integrity check failure or reconfiguration failure includes detecting the integrity check failure or the reconfiguration failure in response to a Radio Resource Control (RRC) message from the MN (
Page 1: Section 2
As described in [1], fast recovery of MCG link in case of MR-DC is to utilize the SCG link and split SRBs for recovery during MCG failure while operating under MR-DC. For example as depicted in figure 1, there are basically 3 states for fast recovery:
Page 2: Figure 1 (b): Fast recovery of MCG link
In Figure 1 (b), the return arrow from MN via SN to UE
Pages 2-3: Section 2.2.1. Fast recovery failure
After triggering fast recovery procedure, if the procedure succeeds, UE will recover the MCG link. But if the fast recovery timer expires and UE did not receive fast recovery RRC reconfiguration message the fast recovery can be considered as failed.
The fast recovery failure may be due to the following potential reasons:
- UE could not find a good MCG cell: the MCG failure indication does not contain available MCG measurement result
- During fast recovery procedure SCG failure happens
- Integrity check failure on SCG link
- UE could not apply the received fast recovery RRC reconfiguration
If the fast recovery fails, for example due to SCG failure, UE may perform re/establishment like legacy UE behaviour.
Therefore,
Proposal 4: If fast recovery failure occurs, UE would trigger re-establishment procedure.).
Regarding claim 10, the claim is interpreted mutatis mutandis of claim 1 and rejected for the same reason as set forth for claim 1.
Regarding claim 17, the claim is interpreted and rejected for the same reason as set forth for claim 8.
Claims 2, 3, 11 and 12 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Vivo (R2-1905827 “Remaining issues on MCG fast recovery”, hereinafter ‘VIVO’) in view of Futaki et al. (US 20220256368 A1 with priority of JP 2019-139250, of record, hereinafter ‘FUTAKI’) and with further in view of Tsuboi et al. (US 20220279586 A1 with priority of JP 2019-146723, of IDS, hereinafter ‘TSUBOI’).
Regarding claim 2, VIVO, in view of FUTAKI, teaches the method of claim 1.
VIVO does not explicitly disclose starting, by the UE, a timer for configuring a maximum amount of time in which to perform a random access procedure with the MN;
performing, by the UE, the random access procedure with the MN; and
detecting, by the UE, a handover failure in response to the timer expiring before the random access procedure has been completed.
FUTAKI teaches performing, by the UE, the random access procedure with the MN (
[0061] The MCG is a group of serving cells associated with (or provided by) the MN 1, and includes the SpCell (i.e., Primary Cell (PCell))…
[0072] As described above, the MN 1 may detect the MCG failure based on the reception of MCG failure information from the UE 3.
Fig. 5, [0076] FIG. 5 shows an example of signalling of the MN 1 and the SN 2 performed in an intra-MN handover procedure without SN change.
Fig. 9 UE performing a Random Access 908 with MN).
VIVO and FUTAKI do not explicitly disclose receiving, by the UE from the MN, a handover command;
starting, by the UE, a timer for configuring a maximum amount of time in which to perform a random access procedure with the MN;
performing, by the UE, the random access procedure with the MN; and
detecting, by the UE, a handover failure in response to the timer expiring before the random access procedure has been completed.
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was made to take the technique of MCG failure recovery using intra-MN handover procedure of FUTAKI to the system of MCG failure recovery of VIVO in order to take the advantage of method for distinguishing the processing for detecting radio link failure in the Source MCG and allowing the MN to control the behavior of the UE (i.e., transmission of MCG failure information or RRC re-establishment) when an MCG failure occurs (FUTAKI: [0145]).
VIVO and FUTAKI do not explicitly disclose starting, by the UE, a timer for configuring a maximum amount of time in which to perform a random access procedure with the MN;
performing, by the UE, the random access procedure with the MN; and
detecting, by the UE, a handover failure in response to the timer expiring before the random access procedure has been completed.
In an analogous art TSUBOI teaches receiving, by the UE from the MN, a handover command (
[0129] In the MR-DC, the master node may be a base station including primary RRC functions related to MR-DC, for example, ….., and to perform handover and the like, and the secondary base station may be a base station including some RRC functions …..
[0164] FIG. 9 illustrates an example of the conditions for start, stop, and expiry of each of the timers of the EUTRA. Note that similar conditions may also be applied in the NR, though the timer name and/or the message name may differ in the NR…..
See Fig. 9, T304 Start reason, T304 Stop reason and at T304 expiry in case of sell change order from E-UTRA or intra E-UTRA handover, initiate the RRC connection re-establishment procedure…..
PNG
media_image1.png
336
866
media_image1.png
Greyscale
[0198] Source MN 1006 may then initiate an inter-MN handover procedure to a target-MN 1008. As part of the inter-MN handover procedure, at 1012, target SN 1008 may transmit a handover message to source MN 1006. At 1014, source MN 1006 may then transmit an RRC reconfiguration message (e.g., including a handover command, a reconfigureWithSync indication, etc.) to SN 1004, and SN 1004 may forward the RRC reconfiguration message to UE 1002. In some cases, if the handover procedure fails (e.g., if the handover timer expires), UE 1002 may initiate an RRC reestablishment procedure to reestablish a dual-connectivity configuration.
[0245] An example of processing related to handover between the same RATs (i.e., between the NRs) in NR will be described using FIG. 8….
[0247] The Source gNB determines handoff of the terminal apparatus, based on information such as the measurement results reported (step S802).
[0251] The Source gNB sends the terminal apparatus the container received from the Target gNB (the first RRC reconfiguration message (RRCReconfiguration message)) (step S806). The RRC reconfiguration message may include some or all of the identifier of the target cell, a new C-RNTI, the security algorithm identity of the Target gNB for a selected security algorithm, a set of resources for the dedicated random access channel, the configuration of a UE-specific CSI-RS, common random access channel resources, and the system information of the target cell.);
starting, by the UE, a timer for configuring a maximum amount of time in which to perform a random access procedure for connecting to a PCell with the MN (
[0156] A set of serving cells including two subsets may be configured for the terminal apparatus. The two subsets may include a cell group (master cell group) including one or multiple serving cells including the primary cell (PCell).
[0198] At 1014, source MN 1006 may then transmit an RRC reconfiguration message (e.g., including a handover command ….), ….to UE 1002. In some cases, if the handover procedure fails (e.g., if the handover timer expires)…
[0263] In a case that the timer T304 expires, the terminal apparatus performs some or all of steps of processing (A) to (D) below.
(Obviously indicating a handover timer T304 has been started));
performing, by the UE, the random access procedure with the MN for connecting to the PCell (See Fig. 9, T304 Start reason, T304 Stop reason and at T304 expiry in case of sell change order from E-UTRA or intra E-UTRA handover, initiate the RRC connection re-establishment procedure…..
[0254] In a case that no RACH-less handover is configured by the first RRC reconfiguration message, the terminal apparatus performs synchronization with the Target eNB and uses the random access channel to access the cell used as a target.); and
detecting, by the UE, a handover failure in response to the timer expiring before the random access procedure has been completed (
[0198] if the handover procedure fails (e.g., if the handover timer expires), UE 1002 may initiate an RRC reestablishment procedure to reestablish a dual-connectivity configuration.
[0254] In a case that no RACH-less handover is configured by the first RRC reconfiguration message, the terminal apparatus performs synchronization with the Target eNB and uses the random access channel to access the cell used as a target.
[0257] With RACH-less handover not configured, in a case that the terminal apparatus successfully accesses the target cell, the terminal apparatus may send the RRC reconfiguration complete message (RRCReconfigurationComplete message) to the Target gNB to confirm handover.
[0263] In a case that the timer T304 expires, the terminal apparatus performs some or all of steps of processing (A) to (D) below.
[0265] (B) In response to expiry of the timer T304 of the MCG, the configurations for the terminal apparatus are changed back to the configurations used in the PCell of the handover source.
[0266] (D) In response to expiry of the timer T304 of the MCG, the RRC connection re-establishment procedure is initiated.); and
transmitting, by the UE, the radio connection re-establishment request message to the MN (
[0198] if the handover procedure fails (e.g., if the handover timer expires), UE 1002 may initiate an RRC reestablishment procedure to reestablish a dual-connectivity configuration.).
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was made to take the technique of timer associated with RA procedure for handover in MCG of TSUBOI to the system of MSCG failure recovery using intra-MN handover procedure of VIVO and FUTAKI in order to take the advantage of method for distinguishing the processing for detecting radio link failure in the Source MCG to prevent unnecessary re-establishment processing for handover if completed within a finite time and do a re-establishment if handover is not completed within a finite time for enabling efficient control of mobility (TSUBOI: [0023, 0257, 0263-0266]).
Regarding claim 3, VIVO, in view of FUTAKI and TSUBOI, teaches the method of claim 1.
VIVO and FUTAKI do not explicitly disclose wherein transmitting the radio connection re-establishment request message to the MN includes transmitting the radio connection re-establishment request message in response to determining that the timer expired before the random access procedure has been completed.
TSUBOI teaches wherein transmitting the radio connection re-establishment request message to the MN includes transmitting the radio connection re-establishment request message in response to determining that the timer expired before the random access procedure has been completed ([0198] if the handover procedure fails (e.g., if the handover timer expires), UE 1002 may initiate an RRC reestablishment procedure to reestablish a dual-connectivity configuration.
[0254] In a case that no RACH-less handover is configured by the first RRC reconfiguration message, the terminal apparatus performs synchronization with the Target eNB and uses the random access channel to access the cell used as a target.
[0257] With RACH-less handover not configured, in a case that the terminal apparatus successfully accesses the target cell, the terminal apparatus may send the RRC reconfiguration complete message (RRCReconfigurationComplete message) to the Target gNB to confirm handover.
[0263] In a case that the timer T304 expires, the terminal apparatus performs some or all of steps of processing (A) to (D) below.
[0265] (B) In response to expiry of the timer T304 of the MCG, the configurations for the terminal apparatus are changed back to the configurations used in the PCell of the handover source.
[0266] (D) In response to expiry of the timer T304 of the MCG, the RRC connection re-establishment procedure is initiated.).
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was made to take the technique of timer associated with RA procedure for handover in MCG of TSUBOI to the system of VIVO in order to take the advantage of method for distinguishing the processing for detecting radio link failure in the Source MCG to prevent unnecessary re-establishment processing for handover if completed within a finite time and do a re-establishment if handover is not completed within a finite time for enabling efficient control of mobility. (TSUBOI: [0023, 0257, 0263-0266]).
Regarding claim 11, the claim is interpreted and rejected for the same reason as set forth for claim 2.
Regarding claim 12, the claim is interpreted and rejected for the same reason as set forth for claim 3.
Allowable Subject Matter
Claims 4-7 and 13-16 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and in intervening claims, and if the reason for rejection under 35 USC 112 (a) and 112 (b) are overcome.
The following is a statement of reasons for the indication of allowable subject matter:
Regarding claim 4, VIVO, FUTAKI, TSUBOI or any other prior arts of record either alone or in combination fails to teach the method of claim 2, further comprising:
receiving, by the UE from the MN, a handover command including a first time value for a first timer for performing a first random access procedure with the MN and a second time value for a second timer for performing a second random access procedure with the SN;
starting, by the UE, the first timer and the second timer;
performing, by the UE, the first random access procedure with the MN;
detecting, by the UE, the handover failure in response to the first timer expiring before the random access procedure has been completed;
performing, by the UE, the second random access procedure with the SN;
stopping, by the UE, the second timer in response to completing the second random access procedure; and
transmitting the radio connection re-establishment request message to the MN in response to determining that the first timer expired before the first random access procedure has been completed.
Claim 13 with similar elements as in claim 4 is also interpreted same as claim 4.
Dependent claims 5-7 and 14-16 being dependent on claim 4 and claim 13, are also interpreted same as claim 4 and claim 13.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Fujishiro et al. (US 12477428 B2), describing Communication Control Method
Zhang et al. (US 12262436 B2), describing Dual Connectivity And Carrier Aggregation Enhancement Schemes In Wireless Communication
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 SHAH M RAHMAN whose telephone number is (571)272-8951. The examiner can normally be reached 9:30AM-5:30PM PST.
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, UN C CHO can be reached at 571-272-7919. 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.
/SHAH M RAHMAN/Primary Examiner, Art Unit 2413