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 .
DETAILED ACTION
This office action is in response to the amendment and remarks filed on 01/21/2026.
Claims 1-20 are currently pending.
Claims 1, 3-4, 9-10, 18-20 are currently amended.
Claims 1-20 are rejected.
Response to Amendments
Applicant's amendments filed on 01/21/2026 have necessitated the new grounds of the rejection contained in this Office action.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-4, 6-12, 18-20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by 3GPP TR 23.752 v0.3.0 (2020-01).
For Claim 1, 3GPP discloses a method for determining a Sidelink (SL) relay node, performed by a first SL relay node (3GPP teaches, in Figure 6.8.2-1, that UE-1 broadcasts directly communication request with relay indication =1), comprising:
obtaining SL connection request information of a first terminal (3GPP teaches, in par. 6.8.1, the third paragraph, wherein the UE-to-UE relay receives a direct communication request); and
sending SL connection forwarding information when the first SL relay node meets a first preset condition (3GPP teaches, in par. 6.8.1, that the UE-to-UE relay shall decide whether to forward the request (i.e. broadcast this request in its proximity), according to e.g. the QoS requirements in the request, the current traffic load of the relay, the radio conditions between the source UE and the relay UE , or some other policies), wherein the SL connection forwarding information comprises the SL connection request information (3GPP teaches, in par. 6.8.2, item 2, where a relay forwards the request, thus the connection forwarding information contains the original SL request information), wherein the SL connection request information comprises at least one of the following information: related service information of the first terminal (3GPP teaches, in par. 6.8.1, that the UE-to-UE relay shall decide whether to forward the request (i.e. broadcast this request in its proximity), according to e.g. the QoS requirements in the request, the current traffic load of the relay, the radio conditions between the source UE and the relay UE , or some other policies); or identification information of a second terminal to which the first terminal requests the SL connection.
Examiner notes that Applicant’s specification as filed states “[0050] In some embodiments, the related service information includes, but is not limited to, at least one of a service type or a QoS requirement.” Therefore, Examiner concludes that 3GPP’s recitation of the QoS requirements in the request [sent by UE-1] is sufficient and proper to reject the corresponding claim limitation.
For Claim 2, 3GPP discloses a method, wherein obtaining the SL connection request information of the first terminal comprises: obtaining the SL connection request information sent by the first terminal (3GPP teaches, in par. 6.8.1, the third paragraph, wherein the UE-to-UE relay receives a direct communication request [from source UE]); or obtaining the SL connection request information sent by the first terminal that is forwarded by the second SL relay node (3GPP teaches, in par. 6.8.2(2), that Relay-1 and relay-2 decide to forward the request [from source UE]).
For Claim 3, 3GPP discloses a method, wherein the SL connection request information further comprises at least one of the following information:
location information of the first terminal;
identification information of the first terminal (3GPP teaches, in par. 6.8.1, the sixth paragraph, that The UE-to-UE Relay maintains a mapping table containing the mapping of peer UEs L2 IDs and the corresponding Relay-L2 IDs that have been self-assigned).
For Claim 4, 3GPP discloses a method, wherein the first preset condition further comprises: a forwarding function of a service request of the first terminal being met; a Received Signal Strength (RSS) of the first terminal being greater than or equal to a first preset value (3GPP teaches, in par. 6.8.1, that the source UE chooses the communication path according to e.g. signal strength, local policy (e.g. traffic load of the UE-to-UE relays) or operator policies (e.g. always prefer direct communication or only use some specific UE-to-UE relays)); or an RSS of a second SL relay node that previously forwards the SL connection request information sent by the first terminal being greater than or equal to a second preset value (3GPP teaches, in par. 6.8.1, that the source UE chooses the communication path according to e.g. signal strength, local policy (e.g. traffic load of the UE-to-UE relays) or operator policies (e.g. always prefer direct communication or only use some specific UE-to-UE relays)).
For Claim 6, 3GPP discloses a method, wherein when obtaining the SL connection request information sent by the first terminal that is forwarded by a second SL relay node, the SL connection forwarding information further comprises at least one of the following information: identification information of the first SL relay node; or identification information of the second SL relay node (3GPP teaches, in par. 6.8.1, the sixth paragraph, that The UE-to-UE Relay maintains a mapping table containing the mapping of peer UEs L2 IDs and the corresponding Relay-L2 IDs that have been self-assigned).
For Claim 7, 3GPP discloses a method, wherein after sending the SL connection forwarding information, the method further comprises: obtaining first response information fed back by the second terminal to which the first terminal requests the SL connection after receiving the SL connection forwarding information; and sending the first response information (3GPP teaches, in Figure 6.8.2-1, that If UE-2 … setup a direct communication link by sending the request accept directly to UE-1. The response message includes indication on the type of communication link being established (e.g. via relay or direct).
For Claim 8, 3GPP discloses a method, wherein the obtaining first response information fed back by the second terminal after receiving the SL connection forwarding information comprises: obtaining the first response information sent by the second terminal; or obtaining the first response information sent by the second terminal that is forwarded by a third SL relay node (3GPP teaches, in Figure 6.8.2-1, step 4, that UE-1 receives the request accept from UE-2 via relay-1).
For Claim 9, 3GPP discloses a method for determining a Sidelink (SL) relay node, performed by a second terminal (3GPP teaches, in Figure 6.8.2-1, UE-2), comprising:
receiving SL connection forwarding information sent by a first SL relay node, wherein the SL connection forwarding information comprises SL connection request information of a first terminal (3GPP teaches, in Figure 6.8.2-1, Step 3, that UE-2 receiving, from Relay-1, the connection request received from UE-1), wherein the SL connection forwarding information is sent when the first SL relay node meets a first preset condition (3GPP teaches, in par. 6.8.1, that the UE-to-UE relay shall decide whether to forward the request (i.e. broadcast this request in its proximity), according to e.g. the QoS requirements in the request, the current traffic load of the relay, the radio conditions between the source UE and the relay UE , or some other policies), wherein the SL connection request information comprises at least one of the following information: related service information of the first terminal (3GPP teaches, in par. 6.8.1, that the UE-to-UE relay shall decide whether to forward the request (i.e. broadcast this request in its proximity), according to e.g. the QoS requirements in the request, the current traffic load of the relay, the radio conditions between the source UE and the relay UE , or some other policies); or identification information of a second terminal to which the first terminal requests the SL connection.
Examiner notes that Applicant’s specification as filed states “[0050] In some embodiments, the related service information includes, but is not limited to, at least one of a service type or a QoS requirement.” Therefore, Examiner concludes that 3GPP’s recitation of the QoS requirements in the request [sent by UE-1] is sufficient and proper to reject the corresponding claim limitation.
For Claim 10, please refer to the rejection of Claim 3, above.
For Claim 11, 3GPP discloses a method, wherein after receiving the SL connection forwarding information sent by the first SL relay node, the method further comprises: determining a target SL path according to the SL connection forwarding information; and sending first response information through the target SL path (3GPP depicts, in Figure 6.8.2-1, step 4, that UE-2 decides which path to choose and use that path to send the REQUEST ACCEPT message to UE-1 via Relay-1).
For Claim 12, 3GPP discloses a method, wherein the SL connection forwarding information further comprises at least one of the following information: location information of the first SL relay node; a Received Signal Strength (RSS) of the first terminal detected by the first SL relay node; identification information of the first SL relay node; or identification information of a second SL relay node in a case of forwarding the SL connection request information to the first SL relay node (3GPP teaches, in par. 6.8.1, the sixth paragraph, that The UE-to-UE Relay maintains a mapping table containing the mapping of peer UEs L2 IDs and the corresponding Relay-L2 IDs that have been self-assigned).
For Claims 18-20, please refer to the rejection of Claims 1-3, above.
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.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over 3GPP TR 23.752 v0.3.0 (2020-01) in view of YUAN Naihua et al (CN 110839270 A).
For Claim 5, 3GPP discloses all of the claimed subject matter with the exception that the SL connection forwarding information further comprises at least one of the following information: location information of the first SL relay node; or an RSS of the first terminal detected by the first SL relay node.
However, Naihua, in analogous art, discloses that the SL connection forwarding information further comprises at least one of the following information: location information of the first SL relay node; or an RSS of the first terminal detected by the first SL relay node (Naihua teaches, on page 8, that the following method may be used to determine the relay selection related parameter of each node having relay capability in the coverage area of the current reference node: step x1, each reference node broadcasts its own location information in the system message.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the communication system taught in 3GPP with the relay node selection taught in Naihua. The motivation is in order to order to improve coverage, improve cell edge throughput [Naihua: on page 1].
Claims 13-16 are rejected under 35 U.S.C. 103 as being unpatentable over 3GPP TR 23.752 v0.3.0 (2020-01) in view of Pontus Arvidson et al (US 20220303745 A1).
For Claim 13, 3GPP discloses all of the claimed subject matter with the exception that the target SL path is an SL path on which the fourth SL relay node is located.
However, Arvidson, in the analogous art, discloses that the target SL path is an SL path on which the fourth SL relay node is located (Arvidson teaches, in ¶ 0209, lines 3-8, that The operation of the path relay device will be disclosed with reference to FIG. 3 and FIG. 5. FIG. 5 is a flowchart for a general method for a path relay device according to the teachings herein. The path relay device 100PR is an intermediate node, located in a path between a path originator and a path destination). Arvidson teaches, in ¶ 0031, that terms device and node in the present context denotes devices such as Machine to Machine (M2M) devices, Internet of things (IoT) devices, Device to Device (D2D) devices.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the communication system taught in 3GPP & Zhao with the path originator device taught in Arvidson. The motivation is to improve the scalability and performance of D2D Networks [Arvidson: ¶ 0044, lines 1-3].
For Claim 14, 3GPP discloses all of the claimed subject matter with the exception that the target SL path is an SL path on which a target SL relay node in the plurality of fourth SL relay nodes is located.
However, Arvidson, in the analogous art, discloses that the target SL path is an SL path on which a target SL relay node in the plurality of fourth SL relay nodes is located (Arvidson teaches, in ¶ 0209, lines 3-8, that The operation of the path relay device will be disclosed with reference to FIG. 3 and FIG. 5. FIG. 5 is a flowchart for a general method for a path relay device according to the teachings herein. The path relay device 100PR is an intermediate node, located in a path between a path originator and a path destination).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the communication system taught in 3GPP with the path originator device taught in Arvidson. The motivation is to improve the scalability and performance of D2D Networks [Arvidson: ¶ 0044, lines 1-3].
For Claim 15, 3GPP discloses all of the claimed subject matter with the exception that the target SL path is an SL path with a smallest quantity of SL relay nodes in a plurality of SL paths in different combinations of the fourth SL relay node and the fifth SL relay node.
However, Arvidson, in the analogous art, discloses that the target SL path is an SL path with a smallest quantity of SL relay nodes in a plurality of SL paths in different combinations of the fourth SL relay node and the fifth SL relay node (Arvidson teaches, in ¶ 0220, lines 3-8, that When the path destination device receives a PREQ message, it may wait and gather PREQ messages from multiple paths, and then chooses 660 the best path among the candidates, i.e. the PREQ representing the best path is selected … The determination of which path is the best path may be based on a hop count as in the state of the art. Alternatively or additionally, the determination of which path is the best path may be based on a received signal strength or other metrics as in the state of the art).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the communication system taught in 3GPP with the path determination taught in Arvidson. The motivation is to improve the scalability and performance of D2D Networks [Arvidson: ¶ 0044, lines 1-3].
For Claim 16, 3GPP discloses all of the claimed subject matter with the exception that the target SL path is an SL path comprising a target SL relay node in the SL paths with the smallest quantity of SL relay nodes.
However, Arvidson, in the analogous art, discloses that the target SL path is an SL path comprising a target SL relay node in the SL paths with the smallest quantity of SL relay nodes (Arvidson teaches, in ¶ 0197, lines 2-5, that The PD device 100PD can select the path (or relay node) to be used based on algorithms and metrics similar to what is available in the state of the art, e.g., using a hop count based metric. Arvidson states, in ¶ 0002, lines 12-15, that In both cases a communication path is established between the originator node/device and the destination node/device, which path may include zero or more relay nodes/devices, one hop between each node).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the communication system taught in 3GPP with the path determination taught in Arvidson. The motivation is to improve the scalability and performance of D2D Networks [Arvidson: ¶ 0044, lines 1-3].
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over 3GPP TR 23.752 v0.3.0 (2020-01) in view of Pontus Arvidson et al (US 20220303745 A1) as applied to claim 14 above, and further in view of YUAN Naihua et al (CN 110839270 A).
For Claim 17, 3GPP & Arvidson disclose all of the claimed subject matter with the exception that an RSS of the target SL relay node is higher than RSSs of other SL relay nodes in the plurality of first SL relay nodes; or a distance between the target SL relay node and the second terminal is less than distances between the other SL relay nodes and the second terminal.
However, Naihua, in analogous art, discloses that that an RSS of the target SL relay node is higher than RSSs of other SL relay nodes in the plurality of first SL relay nodes; or a distance between the target SL relay node and the second terminal is less than distances between the other SL relay nodes and the second terminal (Naihua teaches, on page 9, that receiving that the signal strength of the reference node n is greater than a preset minimum signal strength threshold value and less than a preset maximum signal strength threshold value. The minimum signal strength threshold is used for ensuring the reliability of communication between the ith relay node and the previous relay node, and the maximum signal strength threshold is used for controlling the distance between the ith relay node and the previous relay node/root node).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the communication system taught in 3GPP & Arvidson with the relay node selection taught in Naihua. The motivation is in order to order to improve coverage, improve cell edge throughput [Naihua: on page 1].
Response to Arguments
Applicant's arguments filed on 01/21/2026 have been fully considered but they are not persuasive. Examiner will respond in the rebuttal that follows:
Rejection under 35 USC 103
Claims 1-4, 6-12, 18-20
Examiner respectfully disagrees with Applicant’s argument that the applied art fails to disclose, teach or suggest “wherein the SL connection request information comprises at least one of the following information: related service information of the first terminal; or identification information of a second terminal to which the first terminal requests the SL connection, as recited by amended claim 1” (see remarks, pages 8-10).
As an initial matter, the Examiner consulted applicant’s specification as an aid to claim construction. And in Applicant’s specification as filed, Examiner determined that paragraph [0050] states: “In some embodiments, the related service information includes, but is not limited to, at least one of a service type or a QoS requirement.”
Second, 3GPP teaches, in par. 6.8.1, that the UE-to-UE relay shall decide whether to forward the request (i.e. broadcast this request in its proximity), according to e.g. the QoS requirements in the request, the current traffic load of the relay, the radio conditions between the source UE and the relay UE , or some other policies
Therefore, based on the claim construction informed by Applicant’s own specification, Examiner concludes that 3GPP’s recitation of the QoS requirements in the request [sent by UE-1] reads on, and properly rejects the claim limitation related service information of the first terminal.
Thus, 3GPP does disclose that "the SL connection request information comprises at least one of the following information: related service information of the first terminal; or identification information of a second terminal to which the first terminal requests the SL connection," as recited in previously presented claim 3 and now required by amended claim 1 (and similarly by amended claims 9 and 18).
For at least the above reason, 3GPP does disclose each and every element of amended claims 1, 9, and 18. Claims 1, 9, and 18 are thus not yet allowable over 3GPP. In addition, claims 2-4, 6-8, 10-12, 19, and 20 are also not yet allowable by virtue of their dependency from rejected claims 1, 9, and 18, respectively, as well as for being rejected on their own merits.
Accordingly, Examiner respectfully requests that the rejection of claims 1-4, 6-12, and 18- 20 be maintained as proper.
Further, dependent claims 5 and 13-17 are also not yet allowable by virtue of their dependence from independent claims 1 or 9, as well as for being rejected on their own merits.
In light of the above rebuttal and rejection, Examiner believes that this instant rejection should be made final.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MOHAMED A KAMARA whose telephone number is (571)270-5629. The examiner can normally be reached M-F 9AM-4PM.
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, CHARLES JIANG can be reached at 5712707191. 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.
/MOHAMED A KAMARA/Primary Examiner, Art Unit 2412