DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
The amendment submitted on 02/06/2026 has been received and considered by the Examiner. Claims 1, 7-8, 13, and 19 were amended, claims 2 and 14 were cancelled, and claims 21-22 were newly added. Claims 1, 3-13 and 15-22 remain pending.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1, 3-13, and 15-22 have been considered but are largely moot because the new ground of rejection does not rely on the combination of references applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
However, the Applicant’s argument that prior art of record – Hoang et al. – does not qualify as prior art should still be addressed because Hoang was again cited in this action. On page 13 of their remarks, the Applicant reiterates a previous argument that “Hoang cannot be used as prior art in rejecting claim 1” because “the provisional application 63/061,470 merely discloses that the WTRU acting as a relay can act as either an L3 relay or an L2 relay, and the WTRU can communicate with the base station” and that “the content in paragraph 0286 of the non-provisional application that ‘the WTRU may determine whether to act as an L2 or L3 relay based on an indication from a network node, such as a gNB’ is not obvious in view of the above content [emphasis in original]” (Remarks, p. 13).
In response to these concerns, the Examiner would like to point the Applicant’s attention to another passage from provisional application 63/061,470, paragraph 0077, which states that “[t]he ProSe WTRU-to-Network Relay may indicate to an eNB that it is a ProSe WTRU-to-Network Relay and intends to perform ProSe WTRU-to-Network Relay sidelink communication” and that, in response, “[t]he eNB may provide resources for ProSe WTRU-to-Network Relay communication”. Taken in conjunction with the previously cited paragraph 0080 of 63/061,470 which states that “ProSe WTRU to NW relays may use an L3 (e.g., IP layer) relay” and that “WTRU to NW relays for wearables may use, for example, an L2 relay”, paragraph 0077’s description of an “eNB ... provid[ing] resources for ProSe WTRU-to-Network Relay communication” clearly teaches the contested claim limitation requiring “receiving, by the terminal, relay communication information” that “comprises ... the relay communication mode” because the resources allocated in provisional paragraph 0077 must necessarily correspond to either L2 or L3 operation. Thus, the Examiner would like to respectfully reiterate his position that although provisional application 63/061,470 does not contain the wording of the non-provisional publication verbatim, it does teach the same substance as the non-provisional disclosure cited in this and previous office actions.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A 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.
Claim(s) 1, 4-7, 10-13, 16-18, and 21-22 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Li et al. (US 2022/0225448 A1, hereinafter “Li”).
As to Claims 1 and 13:
Li describes a method for multi-hop PC5 relay discovery and establishment.
Specifically, Li teaches:
Reporting, by a terminal, a relay communication mode to a network-side device
Li teaches that a potential relay UE must provide “[r]egistration/connection management capability, indicating if ... the UE supports layer 3 relay, layer 2 relay, or both” (Li, 0206-0214).
Receiving, by the terminal, relay communication information from the network side device, wherein the relay communication information comprises a relay communication policy and/or authorization parameter corresponding to the relay communication mode
Li teaches that “a UE can include a UE policy container in the registration request message ... so that network [sic] knows the UE is requesting the multi-hop relay policy”. Li adds that “[t]his can trigger the network to create/update UE policy association in later steps, and then ... determine and send a multi-hop relay policy to the UE” (Li, 0215).
The reporting, by a terminal, a relay communication mode to a network-side device comprises: transmitting, by the terminal, a registration message to the network-side device, wherein the registration message carries the relay communication mode
Li teaches that a potential relay UE must provide “[r]egistration/connection management capability, indicating if ... the UE supports layer 3 relay, layer 2 relay, or both” (Li, 0206-0214). Li then clarifies that this information is placed in “a UE policy container in the registration request message” (Li, 0215).
Claim 13 encompasses the same method as Claim 1 in addition to requiring:
A terminal, comprising a processor, a memory, and instructions stored in the memory and capable of running on the processor
Li teaches that “any of the methods and processes described herein can be embodied in the form of computer-executable instructions (i.e., program code) stored on a computer-readable storage medium” and “executed by a machine” (Li, 0361).
As to Claims 4, 10, and 16:
Li teaches:
The relay communication mode comprises at least one of the following: layer 2 relay communication mode; or layer 3 relay communication mode
Li teaches that during registration, a UE indicates if it “supports layer 3 relay, layer 2 relay or both” (Li, 0214).
Claim 10 introduces the same new limitations as Claim 4 from the perspective of the base station.
Claim 16 introduces the same new limitations as Claim 4
As to Claims 5, 11, and 17:
Li teaches:
The relay communication mode reported by the terminal comprises a relay communication mode supported by the terminal and/or a relay communication mode that the terminal tends to use
Li teaches that during registration, a UE indicates if it “supports layer 3 relay, layer 2 relay or both” (Li, 0214).
Claim 11 introduces the same new limitations as Claim 5 from the perspective of the base station.
Claim 17 introduces the same new limitations as Claim 5.
As to Claims 6 and 12:
Li teaches:
A relay discovery policy
Li states that “Discovery assistance information” should be included in a “registration request message” along with “a UE policy container” (Li, 0212, 0215).
A relay discovery authorization parameter
In describing Fig. 11, Li teaches that “[s]ervice authorization is accomplished” for “discovery model B” (Li, 0164).
A relay connection establishment policy
Li teaches that “depending on the network configuration and multi-hop relay policy, a network can participate in the process of forming a new multi-hop relay chain” (Li, 0184).
A parameter for relay connection establishment authorization
Li teaches that “[w]hen the UEs complete registration with the network, they are authorized to form or join a multi-hop relay chain”, evincing the existence of a “parameter for relay connection establishment authorization” (Li, 0232).
Claim 12 adds the same new limitations as claim 6.
As to Claims 7 and 18:
Li teaches:
Receiving, by a network-side device, a relay communication mode reported by a terminal
Li teaches that a potential relay UE must provide “[r]egistration/connection management capability, indicating if ... the UE supports layer 3 relay, layer 2 relay, or both” (Li, 0206-0214).
Transmitting, by the network-side device, relay communication information to the terminal, wherein the relay communication information comprises a relay communication policy and/or authorization parameter corresponding to the relay communication mode
Li teaches that “a UE can include a UE policy container in the registration request message ... so that network [sic] knows the UE is requesting the multi-hop relay policy”. Li adds that “[t]his can trigger the network to create/update UE policy association in later steps, and then ... determine and send a multi-hop relay policy to the UE” (Li, 0215).
Receiving, by the network-side device, a registration message from the terminal device, wherein the registration message carries the relay communication mode
Li teaches that a potential relay UE must provide “[r]egistration/connection management capability, indicating if ... the UE supports layer 3 relay, layer 2 relay, or both” (Li, 0206-0214). Li then clarifies that this information is place in “a UE policy container in the registration request message” (Li, 0215).
Receiving, by the network-side device, a policy configuration request message from the terminal device, wherein the policy configuration request message carries the relay communication mode
Li teaches that a potential relay UE must provide “[r]egistration/connection management capability, indicating if ... the UE supports layer 3 relay, layer 2 relay, or both” (Li, 0206-0214). Li then clarifies that this information is place in “a UE policy container in the registration request message” (Li, 0215).
Claim 19 encompasses the same limitations as Claim 7 in addition to:
A network-side device, comprising a processor, a memory, and instructions stored in the memory and capable of running on the processor, wherein when the instructions are executed by the processor, the steps of the method according to claim 7 are implemented
Li teaches that “any of the methods and processes described herein can be embodied in the form of computer-executable instructions (i.e., program code) stored on a computer-readable storage medium” and “executed by a machine” (Li, 0361).
As to Claims 21 and 22:
Li teaches:
Reporting, by a terminal, a relay communication mode to a network-side device
Li teaches that a potential relay UE must provide “[r]egistration/connection management capability, indicating if ... the UE supports layer 3 relay, layer 2 relay, or both” (Li, 0206-0214).
Receiving, by the terminal, relay communication information from the network side device, wherein the relay communication information comprises a relay communication policy and/or authorization parameter corresponding to the relay communication mode
Li teaches that “a UE can include a UE policy container in the registration request message ... so that network [sic] knows the UE is requesting the multi-hop relay policy”. Li adds that “[t]his can trigger the network to create/update UE policy association in later steps, and then ... determine and send a multi-hop relay policy to the UE” (Li, 0215).
The reporting, by a terminal, a relay communication mode to a network-side device comprises: transmitting, by the terminal, a policy configuration request message to the network-side device, wherein the policy configuration request message carries the relay communication mode
Li teaches that a potential relay UE must provide “[r]egistration/connection management capability, indicating if ... the UE supports layer 3 relay, layer 2 relay, or both” (Li, 0206-0214). Li then clarifies that this information is placed in “a UE policy container in the registration request message” (Li, 0215).
Claim 22 encompasses the same method as Claim 21 in addition to requiring:
A terminal, comprising a processor, a memory, and instructions stored in the memory and capable of running on the processor
Li teaches that “any of the methods and processes described herein can be embodied in the form of computer-executable instructions (i.e., program code) stored on a computer-readable storage medium” and “executed by a machine” (Li, 0361).
Claim Rejections - 35 USC § 103
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claim(s) 3 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Li (US 2022/0225448 A1) in view of Hoang et al. (US 2023/0284206 A1, hereinafter “Hoang”).
As to Claim 3 and 15:
Li teaches:
Receiving, by the terminal, a configuration update command from the network-side device
Li teaches that after a UE “request[s] the multi-hop relay policy”, the network will “create/update UE policy association in later steps” (Li, 0215).
Li does not explicitly disclose:
The configuration update command comprises the relay communication information
However, Hoang does describe a method for configuring sidelink relay devices.
Specifically, Hoang teaches:
The configuration update command comprises the relay communication information
Hoang teaches that “[t]he WTRU may determine whether to act as an L2 or L3 relay based on an indication from a network node, such as a gNB” (Hoang, 0286).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the network node indicating a relay mode, as described in Hoang, into Li’s method for configuring a relay mode. The network device’s indication of a relay mode can clarify the relay node’s responsibilities and avoid redundant signaling.
Claim 15 encompasses the same additional limitations as Claim 3
Claim(s) 8-9 and 19-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Li (US 2022/0225448 A1) in view of Ding et al. (US 2022/0330361 A1, hereinafter “Ding”).
As to Claims 8 and 19:
Li teaches:
The network-side device comprises an access and mobility management function (AMF) and a policy control function (PCF)
Fig. 1D in Li shows an example network architecture which includes an “AMF 172” and “PCF 184” in the “Core network 109”.
The registration message carries the relay communication mode
Li teaches that a potential relay UE must provide “[r]egistration/connection management capability, indicating if ... the UE supports layer 3 relay, layer 2 relay, or both” (Li, 0206-0214).
The policy configuration request message carries the relay communication mode
Li teaches that a potential relay UE must provide “[r]egistration/connection management capability, indicating if ... the UE supports layer 3 relay, layer 2 relay, or both” in a “UE policy container in the registration request message” (Li, 0206-0215).
Furthermore, although paragraphs 0217-0218 of Li do describe the process for an AMF to initiate a policy update with the PCF, Li does not explicitly disclose:
Any one of the following:
Receiving, by the AMF, the registration message from the terminal ... and transmitting, by the AMF ... to the PCF through a terminal policy control creation request or a terminal policy control update request; and
Receiving, by the AMF, the policy configuration request message from the terminal ... and transmitting, by the AMF ... to the PCF through a terminal policy control update request
However, Ding does describe methods to establish a relayed PC5 connection.
Specifically, Ding teaches:
Receiving, by the AMF, the registration message from the terminal ... and transmitting, by the AMF ... to the PCF through a terminal policy control creation request or a terminal policy control update request
Ding describes a “request message #6” that “may be a user policy association update request message”. Ding also clarifies that “after receiving the registration request message from the UE #B, the AMF #2 sends a request message #6 to the PCF #2” and that “the request message #6 may be a user policy association update request message” (Ding, 0391-0392).
Here, “the registration request message from the UE” corresponds to “the registration message from the terminal”, and
“a user policy association update request message” corresponds to “a terminal policy control update request” from the list of “a terminal policy control creation request or a terminal policy control update request”.
Receiving, by the AMF, the policy configuration request message from the terminal ... and transmitting, by the AMF ... to the PCF through a terminal policy control update request
Ding describes a “request message #6” that “may be a user policy association update request message”. Ding also clarifies that “after receiving the registration request message from the UE #B, the AMF #2 sends a request message #6 to the PCF #2” and that “the request message #6 may be a user policy association update request message” (Ding, 0391-0392).
Here, “user policy association update request message” corresponds to “the policy configuration request message from the terminal”, and
“a user policy association update request message” corresponds to “a terminal policy control update request”.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the signaling between the AMF and the PCF described in Ding into Li’s method for updating a relay policy using a registration message. The intra-core network signaling described in Ding is required by the 3GPP standard, so it would be obvious and necessary to use it to implement the policy change requests described in Li.
Claim 19 encompasses the same subject matter as Claim 8 in the form of an apparatus claim.
As to Claims 9 and 20:
Li teaches:
Determining, by the PCF relay communication information corresponding to the relay communication mode based on the relay communication mode reported by the terminal
Li teaches that after a UE indicates if it “supports layer 3 relay, layer 2 relay, or both”, the PCF “can determine and send a multi-hop relay policy to the UE” (Li, 0214-0215).
Transmitting, by the PCF, a configuration update command to the terminal, wherein the configuration update command comprises the relay communication information
Li teaches that after a UE indicates if it “supports layer 3 relay, layer 2 relay, or both”, the PCF “can determine and send a multi-hop relay policy to the UE” (Li, 0214-0215).
Claim 20 encompasses the same subject matter as Claim 9 in the form of an apparatus claim.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Benjamin Peter Welte whose telephone number is (703)756-5965. The examiner can normally be reached Monday - Friday, 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, Chirag Shah, can be reached at (571)272-3144. 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.
/B.P.W./Examiner, Art Unit 2477
/CHIRAG G SHAH/Supervisory Patent Examiner, Art Unit 2477
Prosecution Insights