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 07/27/2026 has been received and considered by the Examiner. Claims 1, 4, 7, 10, and 21 were amended, claims 5, 11, and 16-17 were cancelled, and claims 2 and 14 were previously cancelled. Claims 1, 3-4, 6-10, 12-13, 15, and 18-22 remain pending.
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.
Claim Objections
Claim 4 is objected to because of the following informalities: it contains an apparent typo (“does not comprises”). Appropriate correction is required.
Response to Arguments
The Applicant writes on page 10 of their remarks that Li’s disclosure of a “UE provid[ing] information (Layer 3 relay, layer 2 relay or both) about the relay mode that the UE supports” does not anticipate the limitation in Claim 1 requiring that “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; and the relay communication mode comprises at least one of the following: layer 2 relay communication mode or layer 3 relay communication mode” (Applicant Remarks, p. 10)
However, the Examiner respectfully disagrees with this argument because it misconstrues the broadest reasonable interpretation of the claims. The claims, as amended, require “a relay communication mode supported by the terminal and/or a relay communication mode that the terminal tends to use [emphasis added]”. In other words, the claims do not strictly require the “relay communication mode that the terminal tends to use”, meaning the rejection based on Li is properly maintained because it does describe a UE communicating “a relay communication mode supported by the terminal”.
The Applicant then offers another argument against the pending rejection of Claim 1 on page 11 of their remarks, writing, “Li mainly teaches that the PCF can determine and send a multi-hop relay policy to the UE depending on the role of UE (remote/relay/intermediate), but fails to explicitly teach that the multi-hop relay policy is determined in accordance with whether the UE supports Layer 2 or Layer 3 relay and/or tends to use Layer 2 or Layer 3 relay [emphasis in original]” (Remarks, p. 11).
However, another reference (Hoang) was used to address this limitation in this office action, meaning these arguments against Li are moot.
Finally, the Applicant next argues on page 12 of their remarks against the pending rejection of Claim 21, writing, “the UE [in Li] only provides information about the relay mode that the UE supports to the network” whereas “in amended claim 21, the terminal ... may report the one ‘relay communication mode that the terminal tends to use’ [emphasis in original]” (Remarks, p. 12).
However, new art (Shan et al.), previously listed on the IDS document submitted on 05/24/2024, was cited to address this limitation in place of Li, meaning this argument is moot in light of the newly cited art.
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) 1, 3-4, 6-7, 10, 12-13, 15, and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Li et al. (US 2022/0225448 A1, hereinafter “Li”) in view of Hoang et al. (US 2023/0284206 A1, hereinafter “Hoang”).
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).
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 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).
Here, “the UE supports layer 3 relay, layer 2 relay, or both” maps to “the relay communication mode reported by the terminal comprises a relay communication mode supported by the terminal” from the list of “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”.
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 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 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; or 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).
Here, “registration/connection management capability” maps to “a registration message” from the list of “a registration message ... or ... a policy configuration request message”.
Li does not explicitly disclose:
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
However, Hoang does describe a method for configuring sidelink relay devices.
Specifically, Hoang teaches:
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
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 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 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 teach:
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
As to Claims 4 and 10:
Li teaches:
The relay communication mode- is the layer 2 relay communication mode
In describing itself, Li states that its disclosure “is targeting layer 2 relay” (Li, 0152).
Li does not explicitly disclose:
The relay communication policy and/or authorization parameter corresponding to the layer 2 relay communication mode does not comprises [sic] one or more of: quality of service (QoS) mapping rule or data network name (DNN)
However, Hoang does teach:
The relay communication policy and/or authorization parameter corresponding to the layer 2 relay communication mode does not comprises [sic] one or more of: quality of service (QoS) mapping rule or data network name (DNN)
The indication of the relay layer in Hoang is a “gNB response or indication” that is an “indication of the discovery resource from a network” (Hoang, 0286-0287), not one of the prohibited categories above.
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 10 introduces the same new limitations as Claim 4 from the perspective of the base station.
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).
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 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).
Here, “the UE supports layer 3 relay, layer 2 relay, or both” maps to “the relay communication mode reported by the terminal comprises a relay communication mode supported by the terminal” from the list of “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”.
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 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).
Li does not explicitly disclose:
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
However, Hoang does teach:
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
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 18 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).
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 Hoang (US 2023/0284206 A1) and further in view of Ding et al. (US 2022/0330361 A1).
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, the combination of Li and Hoang 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.
Claim(s) 21-22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Li (US 2022/0225448 A1) in view of Hoang (US 2023/0284206 A1) and further in view of Shan et al. (US 2019/0350047 A1, hereinafter “Shan”), cited in the IDS filed on 05/24/2024.
As to Claims 21 and 22:
Li teaches:
Reporting, by a terminal supporting both layer 2 relay communication mode and layer 3 relay communication mode ... to a network-side device, wherein the relay communication mode indicates one of the layer 2 relay communication mode and the layer 3 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).
Transmitting, by the terminal, a registration message to the network side device, wherein the registration message carries the relay communication mode; or 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).
Here, the “[r]egistration/connection management capability, indicating if ... the UE supports layer 3 relay, layer 2 relay, or both” maps to “a registration message to the network side device” from the list of “a registration message ... or a policy configuration request message”.
Li does not explicitly disclose:
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
However, Hoang does teach:
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
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.
The combination of Li and Hoang also does not explicitly disclose:
Reporting, by a terminal ... a relay communication mode that the terminal tends to use
However, Shan does describe a method for establishing a sidelink relay connection via a relay UE.
Specifically, Shan teaches:
Reporting, by a terminal ... a relay communication mode that the terminal tends to use
Shan describes a UE sending a “ProSe relay layer indicator” that “may indicate one or more of ... a type of relay (layer 2 or layer 3) desired and/or requested by the eRelay UE 902” (Shan, 0117).
Here, the “desired” relay mode corresponds to “a relay communication mode that the terminal tends to use”.
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 Shan’s practice of reporting the relay mode a UE desires in the ProSe discovery indicator. This indicator is part of the 3GPP standard (see Shan, 0117), so it would be obvious to a skilled artisan to use it to report a desired relay mode.
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).
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 G 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.
BENJAMIN PETER WELTE
Examiner
Art Unit 2477
/GREGORY B SEFCHECK/Primary Examiner, Art Unit 2477
Prosecution Insights