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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 02/17/2026 was filed after the mailing date of the Non-Final Rejection on 11/17/2025. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Response to Amendment
The Amendment to the claim 1 filed on 02/02/2026 complies with the requirements of 37 CFR 1.121(c) and has been entered. Claim 29 is cancelled. Objection to Claim 1 is withdrawn.
Response to Arguments
Applicant's Arguments filed 02/02/2026 (hereinafter Resp.) are fully considered hereinafter.
Applicant first argues that rejection of Claims 1, 3, and 6-8 under 35 U.S.C. § l 12(a) in the previous Office Action was improper because [¶0117] and [¶0093] of the Specification support the claimed limitation “one of the plurality of candidate relay UEs indicated in the conditional handover configuration information for the relay path to the target base station” – See Resp., 9:¶3. Examiner respectfully disagrees and points to the detailed explanation in the §112(a) rejection in the previous Office action as evidence that the rejection was not issued because the Specification wouldn’t recite the claimed limitation, but because the Specification recites the claimed limitation using the same language, as correctly noted by the Applicant in [¶0117] and [¶0093] of the Specification, and nothing more, when the test for sufficient written description requirement under §112(a), specifically for computer-implemented functions claimed as a “desired result,” like the case here with the plurality of candidate relay UEs prepared by the target base, is that “the specification discloses the computer and the algorithm (e.g., the necessary steps and/or flowcharts) that perform the claimed function in sufficient detail such that one of ordinary skill in the art can reasonably conclude that the inventor possessed the claimed subject matter at the time of filing”. See MPEP § 2161.01 (I) (citing to Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 682 (stating that “the specification does not show that the inventor had possession of the ability to access ‘disparate databases’” because “the specification describes a result, but does not show how to achieve the result” and citing also to Ariad Pharm., Inc. V. Eli Lilly & Co, 598 F.3d 1336, 1351)); see also MPEP §2163 (I) (stating that although “it is now well accepted that a satisfactory description may be found in originally-filed claims or any other portion of the originally-filed specification . . . that does not mean that all originally-filed claims have adequate written support. The specification must still be examined to assess whether an originally-filed claim has adequate support in the written disclosure and/or the drawings”).
At issue in Vasudevan was whether the Specification contained sufficient description to support the functional limitation of “access disparate databases” when it was known in the art that such function requires correlation between database identifiers. There, the Federal Court stated that it is not enough that one skilled in the art could write a program to achieve the claimed function because the specification must explain how the inventor intends to achieve the claimed function to satisfy the written description requirement – See 782 F.3d at 681-683 (emphasis added), and found that specific portions of the specification explain “that serialized files can be used to correlate parameters from two databases,” and that “those correlation parameters can be used to identify data in one database that is correlated to data in another.” – See id. at 683 which, as part of an expert testimony given in the district court, at least raises “a genuine issue of material fact on whether the specification shows how to achieve the functionality of accessing disparate databases” – See id.
Here, the Specification is silent as to how to obtain the claimed “plurality of candidate relay UEs prepared by the target base,” as recited in Claim 1, even in light of the cited Specification paragraphs making the bare assertion of the same – See [¶0093] (stating that “the conditional handover configuration information may include information regarding a plurality of candidate relay UEs prepared by the target base”); see also [¶0117] (stating “a selected relay UE from the plurality of relay UEs that were prepared for the first UE and identified in the conditional handover configuration information”). Furthermore, the first Final Office Action dated 07/23/2025, explained in Response to Arguments, at page 4-6, that there is no special meaning given to the term “prepare” in connection with a base station and candidate relay UEs under its control in any of the Specification paragraphs disclosing such function in a base station, citing [¶¶0006, 0030, 0058, 0093, 0099, 00113] and Figs. 2-4 and 5B, therefore a person of ordinary skills in the art would turn to prior art, including 3GPP specifications, to understand how a network node “prepares” relay UEs. However, the limitation of “the plurality of candidate relay UEs indicated in the conditional handover configuration information,” as claimed and as recited in Spec.[¶0117], there is no guidance for how to implement “indicating” each and every one of “the plurality of candidate relay UEs in the conditional handover configuration information” so that the first UE performs the selection based on that indication. To be sure, handing the UE “information regarding a plurality of candidate relay UEs prepared by the target base” – See, e.g., [¶0093] (emphasis added) is not the same as handing the UE “the plurality of candidate relay UEs” itself, i.e., an enumeration of UE identities or a list of UEs to select from, as claimed. Furthermore, as explained in Response to Arguments in the previous Office Action, dated 11/17/2025, at page 6-7, reading Claim 1 limitation “the plurality of candidate relay UEs indicated in the conditional handover configuration information” in light of the present disclosure, a person of ordinary skills in the art would only find support for “criteria” to identify and/or to select the relay UE, e.g., a threshold for the SD-RSRP on the link between the first UE and a relay UE – See Spec.:[¶¶0057-59]; see also Appendix at page 43, stating “[t]he Remote UE discovers all relay UEs” (emphasis added); furthermore, “a plurality of candidate relay UEs [is] configured by one or more of source base station 102-a, first target base station 102-b, and/or second target base station 102-c” – See Spec.: [¶0063] (emphasis added); see also Fig. 5A at step 515, showing the step of “Preparation of candidate Relay UEs” at target base stations side but no step of forwarding “the plurality of candidate relay UEs prepared” to the source base station of the remote UE. Because there is a substantial cognitive step between configuring relay UEs by a base station, an action/function that may be called “Preparation”, and the action/function of indicating or identifying the plurality of configured relay UEs in a conditional handover configuration information for a remote UE, it is unlikely that an expert would find a shred of structural support in the present disclosure for how a target base station identifies a plurality of candidate relay UEs and transmits their identity in the conditional handover configuration of the first UE, for the first UE to select one of them, as claimed.
In sum, the rejection under 35 U.S.C. § 112(a) is maintained because Applicant’s argument based on bare assertions in the Specification do not explain how the inventor intends to achieve the claimed limitation as required by the Federal Court in Vasudevan and Ariad supra, therefore the disclosure suffers from insufficient written description.
Claim Rejections - 35 USC § 112(a)
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention..
Claim 1 and its dependent claims are rejected under 35 U.S.C. 112(a) as failing to comply with the written description requirement. The claims contain subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, at the time the application was filed, had possession of the claimed invention.
Claim 1 requires that “the plurality of candidate relay UEs [are] indicated in the conditional handover configuration information.” However, the present Specification and drawings do not sufficiently describe how the plurality of candidate relay UEs become “indicated” in the conditional handover configuration information by a target base station so that the claimed first UE can select one of them.
MPEP §2163 (I) provides that although “it is now well accepted that a satisfactory description may be found in originally-filed claims or any other portion of the originally-filed specification . . . that does not mean that all originally-filed claims have adequate written support. The specification must still be examined to assess whether an originally-filed claim has adequate support in the written disclosure and/or the drawings.” For computer-implemented functions claimed as a “desired result,” like here with the plurality of candidate relay UEs being indicated by the target base in a conditional handover configuration information, the disclosure adequacy assessment is made under Federal Circuit test that “the specification discloses the computer and the algorithm (e.g., the necessary steps and/or flowcharts) that perform the claimed function in sufficient detail such that one of ordinary skill in the art can reasonably conclude that the inventor possessed the claimed subject matter at the time of filing” – See MPEP § 2161.01 (I) (citing to Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 682 and Ariad Pharm., Inc. V. Eli Lilly & Co, 598 F.3d 1336, 1351)(citation omitted) (emphasis added).
Here, the Specification discloses that “[t]he conditional handover preparations may include . . .prepare conditional handover configuration for the UE 104” such as “criteria for the UE 104 to select one or more relay UEs 104” wherein “criteria” include “determining whether the UE 104 that satisfy a sidelink discovery reference signal power (SD-RSRP) for transitioning from Uu connection to PCS connection (e.g., from direct base station connection to a relay connection),” i.e., as in Claim 1 – See [¶0057], while the “preparation of the one or more relay UEs 104 as part of the conditional handover procedure” comprises the base stations “provide conditional handover configuration information that may include the criteria for the UE 104 to execute for conditional handover” – See [¶0058] and “the criteria for selecting one or more relay UEs 104” so that “the UE l 04 may identify one or more relay UEs 104 that have been configured by the source base station 102—a . . . and one of a plurality of candidate target base stations 102-b, 102-c” – See [¶0059] and Fig. 5A; at the same time , “the remote UE 104 may verify target base station configuration that includes identifying one or more candidate relay UEs 104 and verify the availability of target path configuration (e.g., PC5 or Uu path) to one or more target base stations 102-b, 102-c.” – See [¶0062] before “selecting a relay UE 106 from a plurality of candidate relay UEs configured by one or more of source base station” or “target base station” – See [¶0063]; see also Appendix to Specification (describing the relay selection procedure as “The remote UE discovers all relay UEs whose SD-RSRP is above qRxlevMin”) (emphasis added).
Interpreting Claim 1 in light of the Specification, a person of ordinary skill in the art would understand that “preparation” of candidate relay UEs by the target base station means “configuration” of those UEs for becoming relays UEs, and could learn how the configuration is performed, e.g., from the 3GPP technical specifications available before the effective filing date of the present application. However, the same person would not find any guidance as to how the “candidate relay UEs [are] indicated in the conditional handover configuration information,” as claimed. Even though Spec.: [¶00117] discloses that “the method may further include receiving [at the source base station] an indication from the first UE identifying a selected relay UE from the plurality of relay UEs that were prepared for the first UE and identified in the conditional handover configuration information,” the discussed method is executed at a source base station, as shown in Fig. 10, and there is no hint in there or in other parts of the Specification as to who (the target or the source base station) “identifies” or “indicates” the plurality of relay UEs in the conditional handover configuration information, and how functionally (e.g., by execution of an algorithm, filtering condition or characteristic), or structurally (e.g., a field in the conditional handover configuration information such as a list of UE IDs or a bitmap associated with a decoding method) to accomplish the claimed feature, that is, reasonably conveying to those skilled in the art skills that the inventors were in possession of the claimed feature at the filing time. The only disclosed “indication” received by the first UE in the conditional handover configuration information concerning the plurality of candidate relay UEs prepared by the target base station for the first UE is the indication that a candidate selected by the first UE must satisfy the sidelink discovery reference signal power (SD-RSRP) threshold, i.e., the indication is the same as the selection criteria1.
Therefore, Claim 1 and its dependents are rejected under 35 U.S.C. §112(a) as containing subject matter not sufficiently described in the Specification.
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 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 1, 9, 15-16, 19, 21, 34 and 37, as amended, are rejected under 35 U.S.C. 103 as being unpatentable over Latheef et al., U.S. Patent Application Publication No. 2020/0351744 (hereinafter Latheef), and further in view of 3GPP TR 23.752 V0.4.0 (2020-06), "Technical Specification Group Services and System Aspects; Study on system enhancement for Proximity based Services (ProSe) in the 5G System (5GS) (Release 17)" (hereinafter 3GPP TR 23.752), references included therein, and updates to 3GPP TR 23.752 from 3GPP workgroups published before the effective filing date
Regarding Amended Claim 1, Latheef teaches a method for wireless communications (“method for executing conditional handover by UE in a wireless communication network” – See [¶0007]), comprising:
receiving, at a first user equipment (UE), conditional handover configuration information from a source base station (“receiving an RRC reconfiguration message from a source cell” including “a handover configuration” and “a CHO configuration is provided in the handover configuration” with “plurality of conditions for performing the CHO and a plurality of target cell configurations” – See id. whereby “[a]n aspect of improved mobility robustness during the handover procedure is conditional Handover (CHO) which is agreed to be supported on both long-term evolution (LTE) and New Radio (NR)” – See [¶0062]),
wherein the conditional handover configuration information in part includes conditional handover execution criteria that should be met by the first UE in order to execute conditional handover (“the CHO configuration may include a condition for executing the CHO for the candidate target cell and a candidate target cell configuration” – See [¶0009], whereby “[t]he condition for performing the CHO may be determined and appended by the source cell to the CHO configuration” – See [¶0080] and “the UE may determine whether the conditional handover (CHO) configuration is provided in the handover configuration” – See [¶0089] and Fig. 2A)
wherein the first UE is in communication with the source base station via a direct communication path prior to triggering the conditional handover (as shown in Figs. 3A and 3B, “the UE (100) is in the RRC connected state with the source gNB” – See [¶0106]), and
wherein the conditional handover configuration information includes information regarding In order to achieve the CHO, the configuration parameters are typically configured by the source node (source cell) and the target node (target cell) at the CHO configuration (i.e., in signaling towards the UE (100)) and are assumed to be known” – See [¶0113] wherein a “target node sets the configuration to be used when the UE (100) moves to the CHO from an initial access” – See [¶0118] and “the network may only include the most essential parameters in the CHO configuration” – See [¶0123], e.g., an indication2 of a plurality of candidate relay UEs prepared by a target base station for the first UE to select from when the CHO is triggered because there could be “introduce[d] specific fields for the CHO candidate configuration” and/or “specify[] the fields that the target cell can set/change as part of the CHO configuration” – See [¶0153], e.g., an “octet string/container is added to the reconfiguration message to carry the CHO configuration generated by the target node” – See [¶0154])
determining, at the first UE, that the conditional handover execution criteria are satisfied based in part on one of channel conditions between the first UE and the source base station falling below a channel condition threshold (“the HO execution may be initiated by the UE ( 100) only when the CHO condition is met” and “[w]hen the CHO condition is met, then the serving cell signal conditions may start degrading” – See [¶0187], e.g., “[t]he UE (100) performs the RLM [radio link monitoring] by estimating the downlink radio link quality and compare the downlink radio link quality to preset thresholds Qout for monitoring the downlink radio link quality of the source cell (Pcell)” – See [¶0106] and “the UE (100) suspends the radio link monitoring on the source cell when the HO execution to the target cell is initiated in the event when the condition configured in the HO command is met” – See [¶0188] and Fig. 3B);
selecting, by the first UE, one of the plurality of candidateIn response to determining that the conditional handover criteria is satisfied,” e.g., the signal quality to the source cell is weak, as explained supra, “the NR UE may initiate the HO execution at step 414,” i.e., selecting a target cell – See [¶0197] and Fig. 4, whereby “priority is provided for the cell for which a measurement report is sent to the source cell prior to the RLF” and “the next higher priority may be given to the cells that were detected when on the source cell but for which the measurement report is not triggered” – See [¶0208], i.e., selecting a target from the received targets in order of priority is part of executing the HO, and “[f]urther, at step 416, the NR UE may execute the handover and switches from the source cell to the candidate target cell” – See [¶0197]); and
triggering the conditional handover at the first UE to transition communication from the source base station to the target base station (“The method may then include executing the CHO from the source cell to a candidate target cell of the plurality of target cells in the wireless communication network based on the CHO configuration” – See [¶0065]).
Latheef teaching 5G gNB stations, e.g., in Figs. 3A and 3B, RRC configuration messages to the UE based on Information Elements3 (e.g., measConfig, MAC config, spCellConfig) and further “system network improvement is under way based on . . . device-to-device (D2D) communication, wireless backhaul communication”– See [¶0058] and “early handover provisioning using CHO mechanism are also being discussed in RAN2” – See [¶0177], does not explicitly teach the plurality of candidate relay UEs indicated in the conditional handover configuration information for the relay path to the target base station.
3GPP TR 23.752, at page 11, defines a “5G ProSe UE-to-Network Relay” as “[a] UE that provides functionality to support connectivity to the network for Remote UE(s)” and further specifies, in § 6.2.2, at page 22, procedures for allocating identities and provisioning (i.e., configuring or preparing) UE-to-Network Relays, e.g., a “Relay Service Code as defined in TS 23.303” is provisioned to the UE-to-Network Relay by the network. Section 6.6, describes the Layer-3 UE-to-Network Relay architecture shown in Figure 6.6.1-1, at page 34, stating that “[t]he type of traffic supported over PC5 reference point is indicated by the ProSe UE-to-Network Relay e.g. using the corresponding Relay Service Code,” and “[t]he UE-to-Network Relay determines the PDU Session Type based on, e.g. ProSe policy/parameters, URSP rule, Relay Service Code,” e.g., different candidate relay UEs may provide different services at the PC5 interface with remote UEs identified by Relay Service Codes because, as taught by 3GPP TS 23.303, § 4.6.4.3, at page 33, “Relay Service Codes are configured in a ProSe UE-to-Network Relay for advertisement” and also “configured in the Remote UEs interested in related connectivity services,” therefore candidate relay UEs can be matched with a remote UE based on a Relay Service Code of interest for the remote UE, configured to the remote UE.
3GPP TR 23.752 further teaches a plurality of candidate relay UEs prepared by a target base station for the first UE to select from for a relay path to the target base station (the ProSe 5G UE-to-Network Relay procedures start with step 0, “the Registration procedure, Authorization and provisioning [] performed for the ProSe UE-to-NW relay,” followed by establishing “a PDU session for relaying with default PDU session parameters received in step 0 or pre-configured in the UE-to-NW relay, e.g. . . . PDU Session Type. In case of IP PDU Session Type and IPv6, the ProSe UE-to-Network Relay obtains the IPv6 prefix via prefix delegation function from the network as defined in TS 23.501” and if “there is no PDU session satisfying the requirements of the PC5 connection with the remote UE,” e.g., the PDU Session Type associated with the Relay Service Code for the first UE, “the ProSe 5G UE-to-Network Relay initiates a new PDU session establishment or modification procedure for relaying” – See id., at page 36, and Figure 6.6.2-1). To be sure, 3GPP TR 23.752 received many updates during 3GPP SA WG2 Meeting #139E, June 2020, published before the effective filing date of the present application.
3GPP SA WG2 Meeting #139E, S2-2004748, Title: “KI#3 and 8, New Solution: Generic Authorization for 5G ProSe UE-to-Network Relay service,” Source: Intel, published June 15, 2020 (hereinafter 3GPP S2-2004748) teaches how to authorize and provision a UE to be a 5G UE-to-Network Relay and how to authorize a UE to access 5GC via a 5G UE-to-Network Relay for each ProSe Relay Service Code, including a case where the remote UE is outside the coverage area of the target base station4.
3GPP SA WG2 Meeting #139E, S2-2004201 and S2-2004202, Title: “UE-to-Network Relay discovery and handling of PDU session parameters with Remote UE based relay selection,” Source: Philips International B.V., published May 22, 2020 (hereinafter 3GPP S2-2004201 and 3GPP S2-2004202, respectively) each discloses a solution that allows the target network to prepare candidate relay UEs specifically for the requirement of a remote UE, e.g., a ProSe Relay Service Code, by “keep[ing] much of the information and decision power on whether a UE-to-Network Relay is capable to serve as relay for the Remote UE inside the core network, e.g. the AMF” thus avoiding “[s]imply provisioning the UE-to-Network Relay with all kinds of information about supported slices, NPNs and other related attributes, and exposing this information during discovery of a UE-to-Network Relay,” a solution that is not “scalable, since the number of slices, NPNs is potentially quite large, and “it is not known in advance which Remote UEs the UE-to-Network Relay will encounter” – See, e.g., 3GPP S2-2004201, at page 1. Each proposed solution allows “only UE-to-Network relays that are currently capable to serve as relay for the Remote UE’s requested PDU session parameters will respond” – See 3GPP S2-2004202, at page 1.
Taking 3GPP S2-2004201 as example, the network of the UE-to-Network Relays keeps a “list of Relay Service Codes which the UE-to-Network Relay may be able to handle and get authorized for” and a “mapping between the Relay Service Code and a set of PDU session parameter values” and based on “the UE-to-Network Relay[s] send[ing] a Discovery Report (i.e. a newly defined message) to the UE-to-Network Relay’s serving AMF via NG-RAN” including includes the requested Relay Service Codes, “[t]he UE-to-Network Relay’s serving AMF will verify for each UE-to-Network Relay in the Aggregated Discovery Report, whether or not the UE-to-Network Relay is currently capable to meet the requirement associated with the Relay Service Code’s PDU session parameters” and “may trigger an update of some of the other network functions to enable the selected UE-to-Network Relay to serve as a relay for the requested PDU session parameters,” e.g., “may send an RRC Connection Reconfiguration message and/or send a UE Configuration Update message to the selected UE-to-Network Relay” so that only “selected UE-to-Network Relay performs the PC5 unicast link security procedure and sends a Direct Communication Accept message to the Remote UE that includes the given Relay Service Code” – See id., at page 5-6 and Figure 6.x.2.x.
3GPP S2-2004202 proposed solution is based on the same Discovery Report from which “the AMF decides that a UE-to-Network Relay can serve as relay for the requested PDU session parameters, then the AMF will send a Relay Accepted (i.e. newly defined message) to that UE-to-Network Relay” and “[i]f the UE-to-Network relay receives a Relay Accepted message from the AMF, the UE-to-Network Relay sends a Discovery Response (i.e. newly defined message) to the Remote UE that includes the given Relay Service Code” – See id., page 5-6 and Figure 6.x.2.x. However, here “[a]fter receiving one or more Discovery Responses from UE-to-Network Relays, the Remote UE selects the UE-to-Network Relay for setting up the indirect communication with the core network” – See id..
In sum, the difference between 3GPP S2-2004201 and 3GPP S2-2004202 is only that the candidate relay UEs and network functions are specifically configured for a given Relay Service Code requested for the remote UE, therefore, 3GPP S2-2004201 is better suited for a case where a target base station sends to the source base station a list of relay UEs specifically configured for a Relay Service Code to be included in a CHO, while 3GPP S2-2004202 is better suited for a case where the source base station sends to the target base station one or more Relay Service Code as the indication of the plurality of candidate UEs to be prepared by the target base station for a first UE and the UE would select one candidate.
Thus, Latheef and 3GPP TR 23.752 (including 3GPP S2-2004201 and 3GPP S2-2004202 updates) teach novel mobility aspects in 5G networks. A person of ordinary skill in the art before the effective filing date of the claimed invention would have understood that the CHO configuration information sent to the first UE wherein both the source cell and the target cell may generate some configuration parameters that are to be provided to the UE, as taught by Latheef, could have been combined with the indication of Relay Service Codes specifically provisioned to UE-to-Network Relay UEs by the target network to perform direct communication method over the PC5 interface with the first UE because the source base station and the targe base station can exchange over standard interfaces (e.g., X2/Xn) the Relay Service Codes and the UE-to-Network Relay UEs authorized to accept the request for the specific service request from the first UE once the CHO condition is triggered and both relay UEs and remote UEs can be authorized for relay services over PC5 interface at their registration with the network. Furthermore, a person of ordinary skill in the art would have been able to carry out the combination through techniques known in the art. Finally, the combination achieves the predictable result of assuring that only UE-to-Network Relays that are currently capable to serve as relay for the Remote UE’s requested PDU session parameters are selectable by the UE, as taught by 3GPP TR 23.752 updated by 3GPP S2-2004201 and 3GPP S2-2004202.
Therefore, Amended Claim 1 is obvious over Latheef in view of the updated 3GPP TR 23.752.
Regarding Amended Claim 9, Latheef discloses an apparatus for wireless communications, comprising: at least one processor; and a memory coupled to the at least one processor, the memory including instructions executable by the at least one processor (e.g., in Fig. 8) to cause the apparatus to execute the method in Amended Claim 1. Because Amended Claim 1 is obvious over Latheef in view of the updated 3GPP TR 23.752, Claim 9 is obvious over Latheef in view of the updated 3GPP TR 23.752.
Regarding Amended Claim 15, Latheef teaches a CHO method comprising receiving, at a source base station, a measurement report from a first user equipment (UE), wherein the measurement report indicates signal quality between the first UE and the source base station (e.g., in Fig. 3A, “source gNB(100a) sends a measurement configuration to the UE (100)” and “the UE (100) sends measurement report to the source gNB (1000a)” that “includes . . . estimating the downlink radio link quality and compare the downlink radio link quality to preset thresholds Qout for monitoring the downlink radio link quality of the source cell (Pscell)” – See [¶0106]);
identifying one or more candidate target base stations for the first UE to transition communication towards from the source base station (“The HO signaling for the CHO scenario may include some limitations such as: . . . support candidate target cells controlled by different target nodes . . . support candidate target cells on different carrier frequencies/MOs” – See [¶¶0109-0111])
generating a conditional handover configuration information for the first UE based in part on identifying the one or more candidate target base stations (“In order to achieve the CHO, the configuration parameters are typically configured by the source node (source cell) and the target node (target cell) at the CHO configuration (i.e., in signaling towards the UE (100)” wherein “the source node controls the CHO candidates which are to be configured” – See [¶¶0113-114], and “[a] container may be added to the reconfiguration message i.e., to carry the configuration generated by the target node” – See [¶0150], e.g., target “PCell (dedicated and common) configuration” – See [¶0121] and “the new primary frequency (for the case of inter-frequency CHO)” – See [¶0125], for when “multiple CHO candidates are configured” – See [¶0125]),
wherein the conditional handover configuration information in part includes conditional handover execution criteria that should be met by the first UE in order to execute conditional handover (“[a]t step 210a, the UE may determine that the condition for executing the CHO from the source cell to the candidate target cell is fulfilled” – See [¶0092] and Fig. 2A);
wherein the conditional handover execution criteria is considered to be met if channel conditions between the first UE and the source base station falling below a channel condition threshold (“the HO execution may be initiated by the UE (100) only when the CHO condition is met,” e.g., “the CHO condition is met [when] the serving cell signal conditions may start degrading and the neighbour cell may become better suited to serve the UE”– See [¶0187], whereby “[t]he UE (100) performs the RLM by estimating the downlink radio link quality and compare the downlink radio link quality to preset thresholds Qout for monitoring the downlink radio link quality of the source cell (Pscell)” – See [¶0106]); and
transmitting the conditional handover configuration information to the first UE (“the handover command may be provided to the UE (100)” – See [¶0178] by “early handover provisioning using CHO mechanisms” – See [¶0177]).
Latheef further teaches that a target node may include multiple CHO candidates in a CHO configuration list parameter sent to the UE (“[each] container is carrying the CHO configuration of a single CHO candidate as generated by the target node” – See ¶0163]; whereby the “source node includes a CHO candidate list field, for [the] source controlled parameters (e.g. condition)” – See [¶¶0166-68]). Because when “multiple CHO candidates are configured” and “controlled by the different target nodes (with different capabilities/typical settings)” – See [¶0125], it follows that a candidates to CHO is in a coverage area.
Latheef, teaching 5G gNB stations, e.g., in Figs. 3A and 3B, and intimating D2D communications – See [¶0058], does not teach also that the one or more candidate target base stations prepare a plurality of relay UEs for selection in a relay path by the first UE, that are in a coverage area of the one or more candidate target base stations, wherein at least one of the plurality of relay UEs and at least one of the one or more candidate target base stations form part of the relay path that the first UE is to transition communications towards.
The updated 3GPP TR 23.752 teaches a target base station prepares a plurality of relay UEs for selection in a relay path by the first UE, as explained in Regarding Claim 1 supra, whereby the candidate relay UEs are in a coverage area of the candidate target base station as explained in 3GPP S2- S2-2004201 solution, at page 6 (the target network “may send an RRC Connection Reconfiguration message and/or send a UE Configuration Update message to the selected UE-to-Network Relay”). The same solution teaches that the target base station forms part of the relay path that the first UE is to transition communications towards when connected directly over the PC5 interface to the selected relay UE because candidate relay UEs allowed to respond to the first UE request based on the Relay Service Code are already in RRC_CONNECTED status with the NG-RAN as shown in Figure 6.x.2.x; see also 3GPP Ts 36.300:341 (“A ProSe UE-to-Network Relay performing sidelink communication for ProSe UE-to-Network Relay operation has to be in RRC_CONNECTED”).
Therefore, Amended Claim 15 is obvious over Latheef in view of the updated 3GPP TR 23.752.
Regarding Claim 16, dependent from Amended Claim 15, Latheef further teaches configuring, at the source base station, an intra conditional handover preparation for the first UE (“the source node controls the CHO candidates which are to be configured and therefore the source node sets: . . . the CHO condition” – See [¶¶0114-15] and “the UE (100) may monitor for satisfying the condition provided in the HO command for performing the conditional handover” – See [¶0185] and Fig. 4; furthermore, “the conditional handover may support simultaneous reconfiguration of the source cell and the CHO configuration i.e., together within the same message” – See [¶0145], e.g., the HO of the UE from direct communication with the source base station to indirect communication, as further explained in 3GPP TR 23.752).
3GPP TR 23.752 further teaches in Figure 6.7.2.6-1, at page 41, intra-NR-RAN mobility (“[m]obility of a Remote UE within an NG-RAN node will be handled by the NG-RAN and the UE-to-Network Relay, allowing the Remote UE to maintain service when changing from a direct network connection to an indirect network connection (i.e. via L2 UE-to-Network Relay UE) and vice-versa without 5GC involvement”) and describes the procedure in § 6.29.2.1, at page 96 and Figure 6.29.1.1-1, wherein one or more intra candidate relay UEs for the first UE that are in coverage area of the source base station (“Remote UE receives the measurement configuration via RRC message from the NG-RAN,” i.e., intra candidate relay UEs for the first UE are in the source base station coverage, and “ [t]he access stratum procedure that the Remote UE, UE-to-Network Relay and served NG-RAN node for handover is defined by RAN WG2,” i.e., the source base station uses standard reconfiguration messages carrying the CHO information, and that information may include an indication of the candidate relay UEs registered and in RRC_CONNECT state with the source base station5). Furthermore, any of the 3GPP S2-2004201 and 3GPP S2-2004202 solutions updates to 3GPP TR 23.752 are applicable to the source base station to update the CHO information sent to the first UE with indication of candidate relay UEs for L3 UE-to Network Relay communication.
Therefore, Claim 16 is obvious over Latheef in view of the updated 3GPP TR 23.752.
Regarding Claim 19, dependent from Amended Claim 15, Latheef further teaches that in preparation for CHO, the “source cell has prepared the target cells with the UE context” – See [¶0206] and, “[s]imultaneously, the target cell may try to fetch the UE context from the source cell after the successful reception of the re-establishment request from the UE” – See [¶0207] whereby a person of ordinary skills in the art would understand that the successful reception of the re-establishment request from the UE could be that the first UE successfully established a PC5-Uu connection with the network through the selected relay UE from the plurality of relay UEs that were prepared for the first UE and identified in the conditional handover configuration information. However, Latheef does not teach releasing a first UE context from a non-selected plurality of relay UEs, whereby a UE context could be understood by a person of ordinary skills in the art as any piece of information specific to the UE such as a UE ID (e.g., a SL-RNTI configured to the UE for SL communications6), authorization and security context for Relay Service Codes, sidelink measurement identities, etc.
3GPP TR 23.752 teaches in § 6.6, at page 35-37, L3 ProSe 5G UE-to-Network Relay discovery and authorization followed by “[t]he Remote UE selects a ProSe 5G UE-to-Network Relay and establishes a connection for One-to-one ProSe Direct Communication as described in TS 23.287” and “point the uplink and downlink relaying can start” once “IPv6 prefix or IPv4 address is allocated for the remote UE as it is defined in TS 23.303 [9] clauses 5.4.4.2 and 5.4.4.3.” The referenced 3GPP TS 23.303 discloses in § 5.4, at page 104-106, direct communication via ProSe UE-to-Network Relay procedures shown in Figure 5.4.4.1-1, wherein each authorized relay UE has a ProSe Relay UE ID and each remote UE has a “Remote User ID [a]s an identity of the Remote UE user (provided via User Info) that was successfully connected” to the ProSe Relay UE ID and the ProSe UE-to-Network Relay UE sends “a Remote UE Report (Remote User ID, IP info) message to the MME for the PDN connection associated with the relay” – See id., at page 105; therefore the network would know of each successful direct communication over PC5 between a Remote UE User and its selected ProSe Relay UE ID. Furthermore, if “an additional PDN connection for relaying is needed, the ProSe UE-to-Network Relay initiates a new PDN connection establishment procedure for relaying. The details of this procedure are described in clause 5.4.5” – See id., at page 105, whereby “[t]he connection of a new Remote UE most probably require the creation and/or modification of additional dedicated bearers for the PDN connection used for relaying” that “are cleared/disconnected by the ProSe UE-to-Network Relay . . . [w]hen Remote UE(s) disconnect from the ProSe UE-to-Network Relay”– See id., at page 106. Therefore, it would be obvious to one of ordinary skills in the art before the effective filing date of the present application that a network knowing which Remote UEs are connected to which ProSe Relay UE ID based on the received Remote UE Reports would release a UE context, particularly its allocated radio resources for relaying communication, from non-selected relay UEs for reasons of resource scarcity at each ProSe UE-to-Network Relay.
Because the techniques and procedures taught by 3GPP TR 23.752 and its updates and references are combinable with Latheef, Claim 19 is obvious over Latheef in view of the updated 3GPP TR 23.752.
Regarding Amended Claim 21, Latheef discloses an apparatus for wireless communications, comprising: at least one processor; and a memory coupled to the at least one processor, the memory including instructions executable by the at least one processor (“[t]he memory 920 may be connected to the processor 920 and store at least one instruction or a protocol or a parameter for the proposed function, process, and/or method” – See [¶0280] and Fig. 9). Furthermore, the Latheef apparatus executes a method which, when 5G D2D communications improvements are applied, such as the preparation of ProSe UE-to-Network Relay UEs disclosed in 3GPP TR 23.752, as explained in Regarding Amended Claim 1 and Amended Claim 15, supra. Because Amended Claim 21 reads on the Latheef apparatus executing the steps of Amended Claim 15, Amended Claim 21 is obvious over Latheef in view of the updated 3GPP TR 23.752.
Regarding Claims 34 and 37, dependent from Amended Claim 21, they merely recite the same limitations disclosed by Claims 16 and 19, as amended. Because Amended Claim 21 and Claims 16 and 19 are obvious over Latheef in view of the updated 3GPP TR 23.752.
Therefore, Claims 1, 9, 15-16, 19, 21, 34 and 37, as amended, are rejected under 35 U.S.C. 103 as obvious over Latheef in view of the updated 3GPP TR 23.752.
Claims 3, 6-7, 17-18, 28, 30-32, as amended, are rejected under 35 U.S.C. 103 as being unpatentable over Latheef in view of the updated 3GPP TR 23.752 as applied to Claims 1, 9, and 15 above, and further in view of Xu et al., U. S. Patent Application Publication No. 20190313315 (hereinafter Xu).
Regarding Claim 3, dependent from Claim 1, Latheef in view of the updated 3GPP TR 23.752 teaches selecting the one of the plurality of candidate relay UEs prepared by the target base station for the first UE based on a required service, e.g., a Relay Service Code, including sidelink discovery procedures known in the art. However, Latheef in view of the updated 3GPP TR 23.752 does not teach that the selection is based in part on measurement of sidelink discovery reference signals received power (SD-RSRP) between the first UE and each of the plurality of candidate relay UEs.
Xu teaches a method at a UE to “acquire information related to a state of a link between the user equipment and the current relay equipment and a state of a link between the current relay equipment and the current cell” and “adjust, based on the information, a measurement configuration of the user equipment with regard to candidate links including a cellular link to the current cell or another cell and a relay link via another relay equipment” – See [¶0009], whereby “[t]he relay link includes a link that a remote UE communicates with an eNB via a relay UE by means of a PCS interface between the remote UE and the relay UE . . . also be referred to as a Sidelink or PC5 link” – See [¶0038]. Furthermore, Xu teaches a scenario shown in Fig. 7, wherein “the remote UE is in the coverage of cell A and has established a PC5 link with a relay UE, while the remote UE is moving from cell A to cell B” and wherein “[t]he measurement result of the remote UE may satisfy a relay reselection condition (the relay reselection refers to a case that the remote UE needs to reselect the relay UE due to the radio link quality or other reasons after establishing a connection with a relay UE) and a cell handover condition” – See [¶0043].
Xu also teaches “a case, for example, that the remote UE satisfies both the handover and relay reselection” – See [¶0108] whereby “[t]he UE-to-Network reselection condition defined in LTE include that a SD-RSRP measurement result of the current relay UE is lower than q-RxLevMin in reselectionInfoIC (within the coverage) or reselectioninfoOoC (outside of the coverage)” – See [¶0109]. Otherwise said, Xu teaches the (remote) UE needs the sidelink system information 7 of the target cell and a SD-RSRP measurement threshold to find a suitable relay UE when executing a conditional handover to a target cell. That information may be part of the CHO configuration information gathered and formatted at the source base station, as taught by Latheef.
Lastly, Xu further teaches selecting the one of the plurality of candidate relay UEs prepared by the target base station for the first UE is based in part on measurement of sidelink discovery reference signals received power (SD-RSRP) between the first UE and each of the plurality of candidate relay UEs (“the remote UE may first sort the discovered relay UEs” and “[i]f the relay UE with the best general condition is the UE of the cell B, the remote UE may establish a connection with the relay UE, and complete the auxiliary handover procedure by the relay UE of the cell B” – See [¶0050] whereby “the quality of the link between the user equipment and the candidate relay equipment in the above example is characterized by SD-RSRP” – See [¶0078]).
Thus, Latheef in view of the updated 3GPP TR 23.752 and Xu each teaches a cell handover condition whereby a UE receives handover configuration information from a source base station the UE is connected to through a Uu interface. A person of ordinary skill in the art before the effective filing date of the claimed invention would have understood that the method executed by the remote UE to select a relay UE based on the highest measured SD-RSRP of each relay UE in a target cell, as configured to the UE by the source eNB in Xu, could have been combined with the method of configuring CHO to the UE by the source base station comprising a plurality of candidate relay UE prepared by eth target base station for the first UE as taught in Latheef in view of the updated 3GPP TR 23.752, because both methods use configuration information sent to the UE by the serving/source base station in a standard RRC Reconfig message and Xu teaches that the method can be used in a case where the UE performs both handover and relay (re)selection. Furthermore, a person of ordinary skill in the art would have been able to carry out the combination through techniques known in the art. Finally, the combination achieves the predictable result of using standards defined procedures for handover to a target cell supporting UE-to-Network Relay whereby UE relay selection among multiple relay UEs is based on link quality, as taught by Xu.
Therefore, Claim 3 is obvious over Latheef in view of the updated 3GPP TR 23.752 and further in view of Xu.
Regarding Claim 6, dependent from Claim 1, Latheef in view of the updated 3GPP TR 23.752 further teaches wherein triggering the conditional handover at the first UE to transition the communication from the source base station to the target base station, comprises:
maintaining communication with the source base station while a target path to the target base station is setup (“in the proposed method, UE (100) may not initiate the handover procedure/CHO immediately” and “may not suspend the RLM procedure on the source cell . . . hence continue to be latched to the source cell even when the handover procedure is initiated” – See Latheef:[¶0069]).
Xu further teaches that the handover happens via the relay path (“The remote UE is likely to perform the handover when establishing a connection with the relay UE of a neighboring cell” – See [¶0052], and the connection via PC5 interface to the relay happens after “the remote UE in the link state, . . . , the candidate relay UEs may be sorted to determine the optimal relay UE” – See [¶0051], i.e., while the UE is still connected to the source base station via Uu interface)
Therefore, Claim 6 is obvious over Latheef in view of the updated 3GPP TR 23.752 and further in view of Xu.
Regarding Claim 7, dependent from Amended Claim 1, Xu further teaches the method of claim 1, wherein the first UE is a relay UE for one or more remote UEs to communicate with the source base station prior to triggering the conditional handover (“in a case where a user equipment obtains a communication service from a current cell via a current relay equipment, acquire information related to candidate links” whereby “candidate links may include a cellular link to another cell and a relay link via another relay equipment” – See [¶0037], i.e., the current relay equipment is the first UE; furthermore “[t]he Remote UE may be a UE having the same capability as the Relay UE” or “a wearable device having a weaker function than current smartphones” – See [¶0083]).
Therefore, Claim 7 is obvious over Latheef in view of the updated 3GPP TR 23.752 and further in view of Xu.
Regarding Claim 17, dependent from Amended Claim 15, the claim language merely recites the same limitations as recited in Claim 6. Because Claim 6 is obvious over Latheef in view of the updated 3GPP TR 23.752 and further in view of Xu and Claim 15 is Latheef in view of the updated 3GPP TR 23.752, Claim 17 is obvious Latheef in view of the updated 3GPP TR 23.752 and further in view of Xu.
Regarding Claim 18, dependent from Amended Claim 15, Latheef further teaches the method of claim 15, wherein the one or more candidate target base stations further prepare conditional handover cells (“configuration for multiple CHO candidates”– See [¶0155] and “[w]hen the single message is used to signal the CHO configuration to the multiple CHO candidates, the option to include multiple spCells/reconfiguration WithSync fields needs to be added” – See [¶0158] and Fig. 5A showing target cell preparation at 506a by a target base station for a target cell list at 508a, and sent to the UE through RRC Reconfiguration message at step 508a, whereby the “source (at least) may set the CHO condition and signal the CHO condition per candidate” to the UE – See [¶0166], [¶¶0171-74]).
Although Latheef in view of the updated 3GPP TR 23.752 does not explicitly teach that the conditional handover is for one or more remote UEs that are in communication with the first UE, Xu teaches this feature (the CHO can be that “the quality of the PC5 link between the remote UE and the current relay UE may be decreased, and the quality of the Uu link of the cell A may also decreased, and the quality of the Uu link of an adjacent cell B may be increased,” because then “the remote UE may satisfy . . . a cell handover condition” – See [¶0043], i.e., the condition is for a remote UE in communication with the first UE).
Therefore, Claim 18 is obvious Latheef in view of the updated 3GPP TR 23.752 and further in view of Xu.
Regarding Claim 28, dependent from Amended Claim 9, it merely recites the limitations of Claim 3, whereas Claim 3 is obvious over Latheef in view of the updated 3GPP TR 23.752 and Xu. Therefore, Claim 28, is obvious over Latheef in view of the updated 3GPP TR 23.752 and Xu.
Regarding Claim 30, dependent from Amended Claim 9, Latheef in view of the updated 3GPP TR 23.752 further teaches wherein the instructions to determine that that the conditional handover execution criteria are satisfied are further executable by the at least one processor to:
measure sidelink reference signals received power (SL-RSRP) between the first UE and a second UE (“After being connected to the ProSe 5G UE-to-Network Relay, the Remote UE keeps performing the measurement of the signal strength of PC5 unicast link with the ProSe 5G UE-to-Network Relay for relay reselection” – See § 6.6, 3GPP TR 23.752:37)
Xu further teaches that “the relay UE may configure the sidelink measurement configuration for the remote UE to avoid conflict between the measurement and operations on the sidelink” – See [¶0142] and that “both S-RSRP and SD-RSRP can characterize the quality of the PC5 link” – See [¶0141].
Xu further teaches determine that the SL-RSRP falls below a sidelink channel condition threshold (“SysteminformationBlock19, which are used to carry the system information of the D2D communication” and “threshHigh in the remoteUE-Config in the SIB 19 represents the threshold condition of the remote UE” – See [¶0145]; and the “UE-to-Network reselection condition defined in LTE include that a SD-RSRP measurement result of the current relay UE is lower than q-RxLevMin” – See [¶0109]; see also 3GPP TS 36.331: 481-482 describing SystemInformationBlockType19 Information Element containing measurement parameters for both relay discovery, e.g., ThreshHigh, and relay reselection, e.g., q-RxLevMin; 3GPP TS 36.300:341 stating “[a] ProSe UE-to-Network Relay is considered suitable in terms of radio criteria if the PC5 link quality exceeds configured threshold (pre-configured or provided by eNB),” otherwise a “Remote UE triggers ProSe UE-to-Network Relay reselection when PC5 signal strength of current ProSe UE-to-Network Relay is below configured signal strength threshold”).
Therefore, Claim 30 is obvious over Latheef in view of the updated 3GPP TR 23.752 and further in view of Xu.
Regarding Claims 31-32, dependent from Amended Claim 9, obvious over Latheef in view of the updated 3GPP TR 23.752, they merely recite the same limitations as Claims 6 and 7, recited with the same language, only applied to the apparatus of Amended Claim 9. Because Claims 6, 7 are obvious over Latheef in view of the updated 3GPP TR 23.752 and further in view of Xu, Claims 31-32 are also obvious over Latheef in view of the updated 3GPP TR 23.752 and further in view of Xu.
Regarding Claims 35-36, dependent from Amended Claim 21, obvious over Latheef in view of the updated 3GPP TR 23.752, they merely recite the same limitations as Claims 17 and 18, recited with the same language, only applied to the apparatus of Amended Claim 21. Because Claims 17 and are obvious over Latheef in view of the updated 3GPP TR 23.752 and further in view of Xu, Claims 35-36 are also obvious over Latheef in view of the updated 3GPP TR 23.752 and further in view of Xu.
In sum, Claims 3, 6-7, 17-18, 28, 30-32 and 35-36 are rejected under 35 U.S.C. §103 as obvious over Latheef in view of the updated 3GPP TR 23.752 and further in view of Xu.
Claims 8 and 33 are rejected under 35 U.S.C. 103 as being unpatentable over Latheef in view of the updated 3GPP TR 23.752 and Xu as applied to claim 7 and 32 above, and further in view of Tenny et al., U. S. Patent Application Publication No. 20220191745 (hereinafter Tenny).
Regarding Claim 8, dependent from Claim 7, Latheef in view of the updated 3GPP TR 23.752 and Xu teaches the method of claim 7 wherein triggering the conditional handover at the first UE to transition the communication from the source base station to the target base station, comprises “the remote UE may satisfy a relay reselection condition . . . and a cell handover condition,” e.g., “the remote UE is in the coverage of cell A and has established a PC5 link with a relay UE, while the remote UE is moving from cell A to cell B” – See Xu:[¶0043] and the first UE connected to the one or more remote UEs – See § 6.10, 3GPP TR 23.752:52-54 (describing ProSe 5G UE-to-UE Relay operations). Furthermore, § 6.33, 3GPP TR 23.752:101-103, teaches Network-Assisted UE-to-UE Relay Discovery and Selection procedures wherein the “5G network selects the most suitable UE-to-UE relay, based on the location and capability of the UE-to-UE relay” – See id., at page 101, and in Figure 6.33.2-1 and example where the network, after it “locates the UE-1, UE-2, and UEs that have relay capability and are authorized to use ProSe” (e.g., because “5GS may subscribe to (one of the) UEs for the PC5 link status”) determines to change the relay UE between UE-1 and UE-2, e.g., “informs the UE-R to [act] as the relay to transfer the packets between UE-1 and UE-2, this request includes the UE-1 identity, UE-1 Capability, UE-2 identity, UE-2 Capability” – See id., at page 103-104.
However, Latheef in view of the updated 3GPP TR 23.752 and Xu and does not teach receiving, at the first UE, a remote UE handover command from the source base station as part of the conditional handover configuration information; and transmitting the remote UE handover command from the first UE to the one or more remote UEs upon triggering the conditional handover, wherein the one or more remote UEs reconfigure connection to the target base station via the first UE.
Tenny teaches a method for group handover procedure whereby “[a] relay device and one or more remote devices are collectively relocated from a source network node to a target network node, where messages of the group handover procedure are selectively delayed or omitted to ensure synchronisation of the handover operations at the various devices” – See [¶0005] and Figs. 5-6, and a “method of performing a group handover procedure”– See [¶0023].
Tenny’s method comprises receiving, at the relay UE (i.e., the first UE), a remote UE handover command from the source base station conditioned on a prior measurement report (the “relay UE 501 sends one or more measurement reports to source gNB 502” and “[s]ource gNB 502 and target gNB 503 exchange HO request and HO accept” – See [¶0035] and Fig. 5, then “the source network node (for instance, a gNB) sends the relay UE's handover command in a group with the remote UEs' handover commands” – See [¶0037]).
Tenny’s method further comprises transmitting the remote UE handover command from the first UE to the one or more remote UEs upon triggering the conditional handover (“after receiving its handover command, the relay UE . . . stops all forwarding . . . then moves to the target network node immediately, sends its own handover complete message, and resumes forwarding” and “the remote UEs receive handover commands only after the relay UE has performed handover” whereby “relay UE 601 delivers the handover command message to remote UE 604 (step 9) and receives the corresponding handover complete message from remote UE 604” – See [¶¶0037-38] and Fig. 6).
Tenny further teaches wherein the one or more remote UEs reconfigure connection to the target base station via the first UE and via the relay path (“any message sent by the remote UE 604 after step 5 will reach relay UE 601” and if “relay UE 601 buffers them for later forwarding, the message will be received when forwarding resumes at step 8, by the target network node” – See [¶0037] and Fig. 6; that is, the remote UEs are now connected to the target node through the relay (i.e., first) UE).
Thus, Latheef in view of the updated 3GPP TR 23.752 and Xu and Tenny each discloses triggering a conditional handover at a first UE in communication with one or more remote UEs wherein a handover command is triggered from a source node/cell towards a target node/cell and executed by a first (relay) UE. A person of ordinary skill in the art before the effective filing date of the claimed invention would have understood that the method of group handover of one or more remote UEs enabled by the relay UE in Tenny could have been used to improve on the conditional handover triggered at the first UE acting as a relay UE for two remote UEs, as taught in Latheef modified in view of the updated 3GPP TR 23.752 and Xu, because both methods use the source base station knowledge of the remote UEs PC5 link status and best relay UE, hence can generate “group handover command” as part of a CHO configuration transmitted to the first/relay UE. Furthermore, a person of ordinary skill in the art would have been able to carry out the substitution through techniques known in the art. Finally, the substitution achieves the predictable result of carrying handover signaling to and from all the remote UEs in Latheef in view of the updated 3GPP TR 23.752 and Xu substantially simultaneously as taught by Tenny.
Therefore, Claim 8 is obvious over in Latheef in view of the updated 3GPP TR 23.752 and Xu, and further in view of Tenny.
Regarding Claim 33, dependent from Claim 32, the claim language merely recites the limitations of Claim 8, as applied to the apparatus of Claim 32. Because Claim 8 is obvious over Latheef in view of the updated 3GPP TR 23.752 and Xu and further in view of Tenny, and Claim 32 is obvious over Latheef in view of the updated 3GPP TR 23.752 and Xu, Claim 33 is obvious over Latheef in view of the updated 3GPP TR 23.752, and further in view of Tenny.
In sum, Claims 8 and 33 are rejected 35 U.S.C. §103 as obvious over Latheef in view of the updated 3GPP TR 23.752, and further in view of Tenny.
Claims 20 and 38 are rejected under 35 U.S.C. 103 as being unpatentable over Latheef in view of the updated 3GPP TR 23.752 as applied to Amended Claims 15 and 21 above, and further in view of Tenny.
Regarding Claim 20, dependent from Amended Claim 15, Latheef teaches that the conditional handover configuration information further includes command to be executed by the first UE (“the UE may determine that the condition for executing the CHO from the source cell to the candidate target cell is fulfilled” – See [¶0092]), whereby the first UE may be a relay to the source base station for the remote UE, as taught in 3GPP TR 23.752.
3GPP TR 23.752: 103-104 further teaches that the network “informs the UE-R to [act] as the relay to transfer the packets between UE-1 and UE-2, this request includes the UE-1 identity, UE-1 Capability, UE-2 identity, UE-2 Capability,” therefore sending a command to the first/relay UE to forward to the remote UEs. Even though a person of ordinary skills in the art could substitute “act as a relay command” in 3GPP TR 23.752 with the handover command part of the CHO configuration to the first UE acting as a relay UE through techniques known in the art, Latheef in view of the updated 3GPP TR 23.752 does not explicitly teach the first UE decoding the handover command to forward it to one or more remote UEs.
Tenny teaches a “method of performing a group handover procedure” wherein “a relay device and one or more remote devices are collectively relocated from a source network node to a target network node” -– See [¶0023].
Tenny teaches the conditional handover configuration information further includes a remote UE handover command for the first UE to forward to one or more remote UEs when triggering conditional handover (after “[r]elay UE 601 sends one or more measurement reports to source gNB 602 . . . handover commands for relay UE 601 and remote UE 604 are delivered as a group handover command from source gNB 602 (step 4), after which the relay UE 601 immediately stops all forwarding (step 5) and moves to the target cell (step 6)” and “[t]he relay UE 601 delivers the handover command message to remote UE 604 (step 9) and receives the corresponding handover complete message from remote UE 604 (step 10)” – See [¶0038] and Fig. 7).
Thus, Latheef in view of the updated 3GPP TR 23.752 and Tenny each discloses methods of configuring a (relay) UE by the network with conditional handover configuration information, whereby the relay UE may be a UE-to-UE relay or a UE-to-Network relay. A person of ordinary skill in the art before the effective filing date of the claimed invention would have understood that the step of sending a remote UE handover command for the first UE to forward to one or more remote UEs when triggering conditional handover, as taught in Tenny, could have been combined with the conditional handover method as taught in Latheef in view of the updated 3GPP TR 23.752 because these procedures rely on the configuration of the first/relay UE by the source base station while connected to it. Furthermore, a person of ordinary skill in the art would have been able to carry out the combination through techniques known in the art. Finally, the substitution achieves the predictable result of carrying handover signaling to and from all the remote UEs in Latheef in view of the updated 3GPP TR 23.752 and Xu substantially simultaneously, as taught by Tenny.
Therefore, the combination of Latheef in view of the updated 3GPP TR 23.752, and further in view of Tenny makes Claim 20 obvious.
Regarding Claim 38, dependent from Claim 21, it merely recites the same limitations as Claim 20 only applied to the apparatus of Claim 21, which is obvious over Latheef in view of Xu and further in view of 3GPP TS 36.300. Because Claim 20 is obvious over Latheef in view of Xu and 3GPP TS 36.300, and further in view of Tenny, Claim 38 is also obvious over Latheef in view of X and 3GPP TS 36.300, and further in view of Tenny.
In sum, Claims 8, 20, 33, and 38 are rejected under 35 U.S.C. 103 as obvious over Latheef in view of X and 3GPP TS 36.300, and further in view of Tenny.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Martin et al., U.S. Patent Application Publication No. 2022/0330131 teaches relay access in wireless networks;
Karampatsis et al., U.S. Patent Application Publication No. 2020/0037218 teaches switching between direct and indirect access through a relay UE;
Xu et al., U.S. Patent Application Publication No. 2023/0189100 teaches that a base station prepares candidate UE relays and a target base station may request from the relay UE information about the remote UE before preparing the handover response configuration to the source base station;
Uchiyama et al., EPO Patent Application Publication No. EP3522592A1, discloses relay communication between a base station and a remote terminal via a relay terminal, whereby quality of wireless link of end-to-end can be guaranteed;
Lee, U. S. Patent Application Publication No. 2022/0167221 teaches conditional HO based on service time of candidate cells;
Lee et al., U. S. Patent No. 10,470,097 B2, discloses a first user equipment (UE) connected with one or more UEs, and a handover procedure in a wireless communication system;
Jung et al., U. S. Patent Application Publication No. 2018/0123682 discloses a relay-terminal selection method, performed by a remote terminal in a wireless communication system;
Gu et al., U. S. Patent Application Publication No. 2020/0383031 teaches a relay device;
3GPP TSG-RAN2 Meeting # 110-e, R2-2005767, CR to 36.331, Title:”V2X IRAT signalling,” Source: Samsung, June 2020;
3GPP TSG-RAN2 Meeting # 110-e, R2-2005769, CR 1658 to 38.331, Title: “Correction to crossRAT signalling for NR V2X,” Source: Ericsson, June 2020;
3GPP SA WG2 Meeting #139E, S2-2003818, Title: “KI #4, Sol #10 Update: Support of ProSe Service discovery and QoS flow when using Layer-3 UE-to-UE Relay,” Source: Interdigital Inc., June 2020, teaches ProSe 5G UE-to-UE Relay authorization and discovery;
3GPP SA WG2 Meeting #S2-139-e, S2-2003634, Title: “KI #4, Sol #11: Update to Stateful UE-to-UE Relay to include a Layer-2 communication option,” Source: Intel, June 2020;
3GPP TSG-WG SA2 Meeting #139E e-meeting, S2-2004726, Title: “KI #3, Sol #6:Open issues of Solution #6,” Source: Huawei, HiSilicon, MediaTek Inc., June 2020, discloses architecture, protocol stack and procedures for Layer-3 UE-to-Network Relay;
3GPP SA WG2 Meeting #139E, S2-2004748, Title: “KI#3 and 8, New Solution: Generic Authorization for 5G ProSe UE-to-Network Relay service,” Source: Intel, published June 15, 2020;
3GPP SA WG2 Meeting #139E, S2-2004201 and S2-2004202, Title: “UE-to-Network Relay discovery and handling of PDU session parameters with Remote UE based relay selection,” Source: Philips International B.V., published May 22, 2020;
3GPP TSG-RAN WG2 Meeting #109 electronic, R2-2002323, Title:” Correction of TS 37.340 on the support of MR-DC for IAB,” Source: Huawei, HiSilicon, March 2020, discloses definition and dual connectivity support for IAB-MT nodes;
3GPP TS 23.303 V15.1.0 (2018-06), “Technical Specification Group Services and System Aspects; Proximity-based services (ProSe); Stage 2 (Release 15),” June 2018;
3GPP TR 23.752 V0.4.0 (2020-06), “Technical Specification Group Services and System Aspects; Study on system enhancement for Proximity based Services (ProSe) in the 5G System (5GS) (Release 17),” June 2020;
3GPP TS 23.287 V16.2.0 (2020-03), “Technical Specification Group Services and System Aspects; Architecture enhancements for 5G System (5GS) to support Vehicle-to-Everything (V2X) services (Release 16),” March 2020;
3GPP TS 36.331 V16.0.0 (2020-03), “Technical Specification Group Radio Access Network; E-UTRAN; Radio Resource Control (RRC) protocol specification (Release 16)”;
3GPP TS 38.331 V16.0.0 (2020-03), “Technical Specification Group Radio Access Network; NR; Radio Resource Control (RRC) protocol specification (Release 16),” indicating IAB support for a selected PLMN through iab-Support provided to the UE in SIB1;
3GPP TSG-RAN WG2 Meeting #109-e, R2-2002358, CR 4233 to TS 36.331, Title: “NR_IAB Core,” Source: Ericsson, March 2020, adding support of IAB in Rel-16;
3GPP TS 38.300 V16.1.0 (2020-03), “Technical Specification Group Radio Access Network; NR; NR and NG-RAN Overall Description; Stage 2 (Release 16),” showing IAB architecture with multiple IAB relay nodes on the path;
3GPP TR 23.703 V2.0.0 (2014-02), “Technical Specification Group Services and System Aspects; Study on architecture enhancements to support Proximity-based Services (ProSe) (Release 12)”;
Title: “Integrated access and backhaul a new type of wireless backhaul in 5G,” Source: Ericsson, June 23, 2020, available at https://www.ericsson.com/en/reports-and-papers/ericsson-technology-review/articles/introducing-integrated-access-and-backhaul.
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 LUCIA GHEORGHE GRADINARIU whose telephone number is (571)272-1377. The examiner can normally be reached Monday-Friday 9:00am - 5:00pm 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, Joseph AVELLINO can be reached at (571)272-3905. 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.
/L.G.G./Examiner, Art Unit 2478
/JOSEPH E AVELLINO/Supervisory Patent Examiner, Art Unit 2478
1 This is not to say that there were no other possibilities for identifying a plurality of candidate relay UEs prepared by a target base station known in the industry before the effective filing date of the present application – See, e.g., 3GPP TS 23.303 V15.1.0 (2018-06), “Technical Specification Group Services and System Aspects; Proximity-based services (ProSe); Stage 2 (Release 15),” (hereinafter 3GPP TS 23.303), teaching in § 4.6.4.3, at page 33, that “Relay Service Codes are configured in a ProSe UE-to-Network Relay for advertisement” and also “configured in the Remote UEs interested in related connectivity services,” therefore a plurality of candidate relay UEs may be indicated or identified by the Relay Service Codes, provisioned to them by a target base station, that they offer to remote UEs; similarly a “Service ID for the 3GPP-defined Service Category for ProSe” can be used as an identifier – See id., at page 128; see also 3GPP TR 23.752 V0.4.0 (2020-06), “Technical Specification Group Services and System Aspects; Study on system enhancement for Proximity based Services (ProSe) in the 5G System (5GS) (Release 17)” (hereinafter 3GPP TS 23.752) , teaching in § 6.13.6, at page 67, that “UE-to-Network Relay Service Code or Service ID [] identifies a connectivity service that the UE-to-Network Relay provides.”
2 A person of ordinary skills in the art would appreciate that an indication such as Relay Service Code of Service ID provided by the candidate relay UEs, as described in Footnote 1, is a more judicious use of radio resources for transmitting the CHO configuration to the first UE than a full list of candidates.
3 See 3GPP TS 38.331 V16.0.0 (2020-03), “Technical Specification Group Radio Access Network; NR; Radio Resource Control (RRC) protocol specification (Release 16),” (hereinafter 3GPP TS 38.331)
4While 3GPP TR 23.752 references 3GPP TS 38.300: "NR; NR and NG-RAN Overall Description; Stage 2" (hereinafter 3GPP TS 38.300), § 16.9, 3GPP TS 38.300, at page 113, discloses that “an overview of NR sidelink communication and how NG-RAN supports NR sidelink communication and V2X sidelink communication is given. V2X sidelink communication are specified in TS 36.300,” referencing 3GPP TS 36.300 V16.1.0 (2020-03), “Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2 (Release 16)” (hereinafter 3GPP TS 36.300).See also § 23.10.4 of 3GPP TS 36.300 teaching a plurality of candidate sidelink relay UEs prepared by a target base station for a remote UE to select from for the relay path to the target base station (the eNB controls the UE relay by: (1) providing “broadcast transmission resource pools for ProSe-UE-to-Network Relay discovery” and (2) “broadcast[ing] a minimum and/or a maximum Uu link quality (RSRP) threshold(s) that the ProSe UE-to-Network Relay needs to respect” and “the UE uses the threshold(s) to determine if it can indicate to eNB that it is a Relay UE and wants to start ProSe UE-to-Network Relay discovery” – See id.:341; in addition, 3GPP TS 36.300:346 defines “NR sidelink communication as specified in TS 23.287”; see also 3GPP TS 23.287 V16.2.0 (2020-03), “Technical Specification Group Services and System Aspects; Architecture enhancements for 5G System (5GS) to support Vehicle-to-Everything (V2X) services (Release 16),” (hereinafter 3GPP TS 23.287).
5 CHO was discussed in detail in 3GPP TSG-RAN WG2 Meetings 109e and #110-e and summary of all contributions are outlined under § 6.9, Report of 3GPP TSG RAN WG2 meeting #109-e, R2-2002501 (available at https://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_109_e/Report) and Report of 3GPP TSG RAN WG2 meeting #110-e, R2-2006501 (available at https://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_110-e/Report). Section 6.4 of the same Reports contain the summary and agreements on NR V2X updates.
6 See, e.g., 3GPP TS 36.331 V16.0.0 (2020-03), “Technical Specification Group Radio Access Network; E-UTRAN; Radio Resource Control (RRC) protocol specification (Release 16)” (hereinafter 3GPP TS 36.331) disclosing in § 5.10.2.1, at page 306, Sidelink UE information to inform the base station “that the UE is interested or no longer interested to receive sidelink communication or discovery, to receive V2X sidelink communication, as well as to request assignment or release of transmission resources for sidelink communication or discovery announcements or V2X sidelink communication or sidelink discovery gaps, to report parameters related to sidelink discovery from system information of inter-frequency/PLMN cells and to report the synchronization reference used by the UE for V2X sidelink communication,” at page 416, the SidelinkUEInformation message is used for the indication of sidelink information to the eNB, at page 795, the IE SL-CommConfig specifies the dedicated configuration information for sidelink communication, including the SL-RNTI of the UE.
7 See 3GPP TS 36.331 disclosing, at page 481-483, SystemInformationBlockType19 which in E-UTRAN “supports the sidelink UE information procedure and may contain sidelink discovery related resource configuration information,” and, at page 487-488, SystemInformationBlockType21 which contains V2X sidelink communication configuration; similarly, in NR sidelink, 3GPP TS 38.331 discloses, at page 308-310, SIB12 which contains NR sidelink communication configuration and SIB13 which contains configurations of V2X sidelink communication defined in 3GPP TS 36.331.