Prosecution Insights
Last updated: August 18, 2026
Application No. 18/862,416

METHOD AND DEVICE FOR SUPPORTING AUTHENTICATION OF TERMINAL IN WIRELESS COMMUNICATION SYSTEM

Final Rejection §103
Filed
Nov 01, 2024
Priority
May 02, 2022 — RE 10-2022-0054347 +1 more
Examiner
GERGISO, TECHANE
Art Unit
2408
Tech Center
2400 — Computer Networks
Assignee
Samsung Electronics Co., Ltd.
OA Round
2 (Final)
84%
Grant Probability
Favorable
3-4
OA Rounds
1y 3m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 84% — above average
84%
Career Allowance Rate
720 granted / 852 resolved
+26.5% vs TC avg
Strong +24% interview lift
Without
With
+24.2%
Interview Lift
resolved cases with interview
Typical timeline
3y 1m
Avg Prosecution
14 currently pending
Career history
876
Total Applications
across all art units

Statute-Specific Performance

§101
14.0%
-26.0% vs TC avg
§103
56.4%
+16.4% vs TC avg
§102
11.4%
-28.6% vs TC avg
§112
10.7%
-29.3% vs TC avg
Black line = Tech Center average estimate • Based on career data from 852 resolved cases

Office Action

§103
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 . Response to Arguments Applicant’s arguments, see pages 7-19, filed 04/27/2026, with respect to the rejection(s) of claims 1-15 under YOUN et al (US 20220279348 A1—hereinafter—" YOUN”) in view of KAWASAKI US 20220279378 A1 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of in view of LY US 20220210698 A1. Claim Rejections - 35 USC § 103 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 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. Claims 1-15 are rejected under 35 U.S.C. 103 as being unpatentable over YOUN et al (US 20220279348 A1—hereinafter—" YOUN”) in view of LY US 20220210698 A1 As per claim 1: YOUN discloses a method for supporting an authentication for a second user equipment (UE) by a first UE in a wireless communication system, the method comprising: transmitting, to a session management function (SMF), a packet data unit (PDU) session establishment message for a PDU session for the first UE ([0062] The illustrated SMF 420 may perform a function of allocating an Internet protocol (IP) address of the UE. In addition, the SMF may control a protocol data unit (PDU) session. ([0252-0254] While the PDU session establishment procedure is being performed, the Data Network-Authentication, Authorization, and Accounting (DN-AAA) server may perform secondary authentication/authentication. Here, the secondary authentication/authorization may mean authentication/authorization through a data network (DN) outside the domain of the mobile operator. A DN-AAA server may belong to 5GC or DN. When the procedure for establishing a PDU session to the Data Network (DN) is performed, the following operations may be performed: The DN-specific identity of the UE can be authenticated/authorized by the DN); [0345] 4) The Relay UE may transmit a PDU Session Modification Request message to the SMF through the AMF. The PDU session modification request message may include ID information of the Remote UE and PC5 session information. At this time, in order to inform that the Relay UE starts the relay for the Remote UE, Relay UE may include ID information and PC5 session information (eg, session information transmitted by the UE (eg, session information that the Remote UE wants to receive service e.g. DNN, S-NSSAI)+PC5 session information for identifying the session requested by the Remote UE (eg, information for identifying the link created in the PC5 link e.g. PC5 link id)) in the PDU session modification request message. If the Remote UE provided information for secondary authentication to the relay UE, the Relay UE may include information for secondary authentication in the PDU session modification request message and transmit the PDU session modification request message); receiving, from the SMF, a PDU session establishment response message corresponding to the PDU session establishment message ([0156] More specifically, when the AMF is changed, the new AMF notifies the new AMF that provides services to the UE to each SMF. The AMF authenticates the PDU session status from the UE by using available SMF information. In case the AMF is changed, the available SMF information may be received from the previous (or old) AMF. The new AMF may send a request to the SMF to release (or cancel) network resources related to a PDU session that is not activated in the UE. ([0294-0295] FIGS. 10a and 10b show Remote UE, Relay UE, AMF, Remote UE Authentication Server Function (RAUSF), SMF, DN-AAA (DN-AAA Server), and UDM. 1) Relay UE may perform registration procedure and PDU session establishment procedure. For example, for relaying to the Remote UE, the Relay UE may perform a registration procedure and may establish (or generate) a PDU session for relaying data of the Remote UE. (eg, SUPI, SUCI, or temporary ID); Note that Remote UE is considered as the second user equipment UE. [0299]5) The AMF may transmit an Authentication Request message to the Remote UE Authentication Server Function (RAUSF) to start the authentication procedure for the Remote UE. The authentication request message transmitted by the AMF may include information on the Relay UE ID and information on the Remote UE ID (eg, SUPI, SUCI, or temporary ID)); [0350] 7 and 8) The SMF may inform the Remote UE that the service is allowed. For example, the SMF may transmit a PDU session modification command message (including ID information of the Remote UE and PC5 session information) to the Relay UE via the AMF. Then, the Relay UE may transmit a direct communication accept message including the Remote UE IP address to the Remote UE. Here, the Remote UE IP address may refer to IP address information of the Remote UE used in the PC5 link); transmitting, to the SMF, a security trigger request message to request he authentication ([0140-0142]) The UE transmits an Identity Response message including the SUPI to the new AMF. The AMF may determine to perform triggering of an AUSF. In this case, the AMF may select an AUSF based on the SUPI. The AUSF may initiate authentication of the UE and the NAS security function. ([0188-0191] The SMF may verify whether or not the UE request follows the user subscription and local policy. Alternatively, the SMF may reject the UE request via NAS SM signaling (including the related SM rejection cause), which is forwarded (or transferred) by the AMF, and then the SMF may notify to the AMF that this shall be considered as a release of the PDU session ID. The SMF transmits a message to the DN through a UPF. More specifically, in case the SMF is required to authorize/authenticate a PDU session establishment, the SMT selects a UPF and triggers the PDU. If the PDU Session Establishment authentication/authority assignment fails, the SMF ends the PDU Session Establishment procedure and notifies the rejection to the UE. [0323] 4) Relay UE includes information on Remote UE ID (eg, SUPI, SUCI or temporary ID), type information of Remote UE ID, and information on session (eg, ID for distinguishing PC5 sessions, DNN, S-NSSAI, etc.) in the PDU Session Modification Request message and transmit the PDU Session Modification Request message to the SMF. At this time, in order to inform that the Relay UE starts relaying for the Remote UE, the Relay UE may include information on the Remote UE ID (eg, SUPI, SUCI, or temporary ID) and information on the session (eg, information on the session transmitted by the Remote UE) and PC5 session information (eg, including PC5 link identity) for identifying the session requested by the Remote UE) in the PDU Session Modification Request message. If the Remote UE provides information for secondary authentication in step 3), the Relay UE may also include information for secondary authentication in the PDU Session Modification Request message and may transmit the PDU Session Modification Request message. For reference, the Relay UE may transmit a PDU session modification request message to the SMF through the AMF. [0357] 25) When the SMF receives a message from the DN-AAA server indicating that the secondary authentication has been successfully performed, the SMF may transmit a PDU Session Modification Command message to the Relay UE. Here, the PDU session modification command message may include information on the Remote UE ID and information on which whether PC5 session authentication has been successful. When the SMF receives a message from the DN-AAA server notifying that the secondary authentication has failed, the PDU session modification command message may include information about the Remote UE ID and at which stage (eg network authentication or secondary authentication) authentication failed. In addition, the SMF may include the ID (e.g. 5G-GUTI) allocated by the AMF for the Remote UE in the PDU Session Modification Command message and transmit the PDU Session Modification Command message to the Relay UE); receiving, from the SMF, a security trigger response message including authentication information for the second UE ([0300] 6 and 7) RAUSF may obtain AV (Authentication Vector) and SUPI information for remote UE authentication from UDM based on information on Remote UE ID. For example, the RAUSF may transmit a request message (eg, Nudm_UEAuthentication_Get request message) including information (eg, SUCI) on the Remote UE ID to the UDM. Then, the UDM may transmit a response message (eg, Nudm_UEAuthentication_Get response message) including information about the Remote UE ID (eg, SUPI) and AV (Authentication Vector) to RAUSF. The UDM may provide the RAUSF with a SUPI matching the SUCI received from the RAUSF. [0330] 5) When the information on the Remote UE ID received by the SMF in step 4) is SUCI, the SMF may transmit a request message (eg, Nudm_UEAuthentication_Get request message) to the UDM. The SMF may transmit a Nudm_UEAuthentication_Get request message including information on the Remote UE ID (SUCI) to the UDM. Additionally, the SMF may include an indication (or information) indicating that it is related to the Remote UE in the Nudm_UEAuthentication_Get request message. [0331] 6) The UDM may generate a SUPI based on the SUCI transmitted by the SMF. The UDM may transmit a response message (eg, Nudm_UEAuthentication_Get response message) to the SMF. The response message (eg, Nudm_UEAuthentication_Get response message) may include information about the Remote UE ID (SUPI). [0332] When the SMF transmits an indication (or information) indicating that the UDM is related to the Remote UE, the UDM may include only the SUPI in the response message (eg, Nudm_UEAuthentication_Get response message) without including the AV. Alternatively, when the SMF transmits a request message (eg, Nudm_UEAuthentication_Get request message), regardless of whether the SMF transmitted an indication (or information) indicating it is related to the Remote UE or not, the UDM may not include the AV, but only include the SUPI in the response message (eg Nudm_UEAuthentication_Get response message). The reason why the UDM does not transmit the AV is that the AV is used when authenticating the terminal during the registration procedure and does not need to be used after step 7). [0340-0343] AUSF, SMF, AMF, Relay UE and Remote UE may perform the EAP authentication procedure. After the EAP authentication procedure is performed, the AUSF may transmit an authentication response message (eg, Nausf_UEAuthentication_Authentication Response message) including information about the Remote UE ID (eg, SUPI) to the AMF. The AMF may transmit an authentication response message including information about the Remote UE ID (eg, SUPI) to the SMF….When the Relay UE receives the Authentication Request message for the Remote UE, the Relay UE may transmit parameters related to the EAP message to the Remote UE using PC5 signaling (PC5 signaling may be performed as the same manner of step 10) of FIGS. 10a and 10b). The Remote UE may transmit a response (eg, a response to parameters related to the EAP message) to the Relay UE by including the response it in PC5 signaling (this transmission may be performed in the same manner of step 11 of FIGS. 10a and 10b). The Relay UE may include the Remote UE's response in the Authentication Response message and transmit the Authentication Response message to the AMF (this may be performed as the same way of step 12 of FIGS. 10a and 10b). In this case, the Relay UE may include information about Remote UE ID (e.g. SUCI or temp ID) in the Authentication Response message, in order to inform that the Authentication Response message is related to authentication for the Remote UE. When the authentication for the Remote UE (eg EAP authentication) is successfully completed, if the SMF transmitted an authentication request message including information about the Remote UE ID (SUCI) in Step 7, AUSF may transmit the authentication response message (eg, Nausf_UEAuthentication_Authentication Response message) of step 12) to the AMF by including information (SUPI) about the Remote UE ID in the authentication response message). YOUN does not explicitly discloses wherein the authentication information for the second UE includes group key information of a group to which the first UE and the second UE belong. LY, in analogous art however, discloses wherein the authentication information for the second UE includes group key information of a group to which the first UE and the second UE belong ([0209] After receiving the new parameters, the NAS Layer of a UE 102 can establish a “Shared PDU Session” with the core network 106. This Shared PDU Session is a special PDU session with a primary PDU session ID and one or more secondary PDU session IDs. The shared PDU session contains data from multiple PDU Session IDs, which represent the one or more secondary PDU session IDs, that have been aggregated as described herein. A UE 102 can include a primary PDU Session ID for this shared PDU session, a Shared PDU Session indication, the Traffic Group ID, and a list of secondary PDU Session IDs of other UEs in a PDU Session Establishment request where the provided secondary PDU Session IDs are associated with aggregated data over this shared PDU session. These secondary PDU Session IDs and the Traffic Group ID can be included along with the aggregated data to inform a Relay Aggregation (RA) UPF on how to route the data from the individual UEs. These secondary PDU Session IDs may have been received by the relay UE via PC5 signaling from other UEs. [0210] The SMF 174 will use the secondary PDU Session IDs to determine the UPF anchors 176b, 176c, etc. identified by each PDU session ID. The SMF 174 will then perform a UPF selection procedure to select an RA UPF that will be used to de-aggregate and aggregate the data of PDU session IDs of UL and DL traffic, respectively. The SMF 174 will provide the secondary PDU Session IDs, the Traffic Group ID, and the Delay Tolerant Data Period to the selected RA UPF. The SMF 174 will also configure the RA UPF and the PSA UPFs with tunnel information so that data can be tunneled between the RA UPF and PSA UPFs. The RA UPF in turn will use the secondary PDU Session IDs, the Traffic Group ID, and the Delay Tolerant Data Period in making UL and DL traffic routing decisions. For UL traffic routing, the UPF 176 can interface to the multiple PSA UPFs using the secondary PDU Session IDs and the Traffic Group ID and the tunnel parameters that can be received from the SMF. For DL traffic routing, the RA UPF can use the Delay Tolerant Data Period and the Traffic Group ID to aggregate data from potentially multiple PSA UPFs for different UEs before sending the aggregated data to the relay UE via the RAN node 105. [0233] An RA UPF that supports this shared PDU session concept can perform the de-aggregation of UL data to one or more PSA UPFs similar to an UL CL or BP UPF. However, unlike the UL CL or the BP UPF cases, the establishment of a shared PDU session automatically selects a UPF that supports relay aggregation to manage routing both UL and DL data associated with the shared PDU session to and from multiple PSA UPFs. The relay UE sends a combined message including data from multiple PDU Session IDs of other UEs. Within the combined message, a Traffic Group ID is inserted along with the aggregated data that are organized according to the PDU Session ID they belong to. The Traffic Group ID allows the RA UPF to make a determination to parse the combined message into individual PDU sessions and route them to the associate PSA UPFs. [0234] To support the shared PDU session concept, the session management procedures of TS 23.502 (3GPP TS 23.502, Procedures for the 5G System; V15.4.1 (2019 January)), incorporated herein by reference, are modified for specifying a request for shared PDU session functionality. Using FIGS. 3A and 3B as the basis for the modifications to the PDU Session Establishment procedure, the following are differences to the procedure to support shared PDU sessions. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations of supporting authentication of a user equipment (UE) in a wireless communication system disclosed by YOUN to include wherein the authentication information for the second UE includes group key information of a group to which the first UE and the second UE belong. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to provide an electronic device that includes a circuitry configured to send a request to a core network, wherein the request informs the core network that the electronic device is capable of aggregating data and relaying data from other electronic devices; receive one or more aggregation policies from the core network, wherein the one or more aggregation policies provide parameters that instruct how the electronic device is to aggregate and relay data; receive data from the other electronic devices; aggregate the data from the other electronic devices based on the parameters; and send the aggregated data to the core network as suggested by LY ([0004-0008]). As per claim 2: YOUN in view LY discloses the method of claim 1, wherein the authentication information for the second UE further includes one of an extensible authentication protocol (EAP) authentication message for performing authentication, an EAP authentication request message, an EAP success message, or an EAP failure message (YOUN; [0301] 8) RAUSF may generate an Extensible Authentication Protocol (EAP)-Request message for authentication to the Remote UE. RAUSF may transmit an Authentication Response message including the EAP-Request message and information about the Remote UE ID (information transmitted by the UE in step 3) (eg, SUPI, SUCI, or temporary ID) to the AMF. Here, when the Relay UE has a plurality of Remote UEs (when communicating with a plurality of Remote UEs), in order to inform which Remote UE the message is for authentication, RAUSF may transmit information about the Remote UE ID). As per claim 3: YOUN in view LY discloses the method of claim 1, further comprising storing the authentication information for the second UE included in the security trigger response message (YOUN ([0323] 4) Relay UE includes information on Remote UE ID (eg, SUPI, SUCI or temporary ID), type information of Remote UE ID, and information on session (eg, ID for distinguishing PC5 sessions, DNN, S-NSSAI, etc.) in the PDU Session Modification Request message and transmit the PDU Session Modification Request message to the SMF. At this time, in order to inform that the Relay UE starts relaying for the Remote UE, the Relay UE may include information on the Remote UE ID (eg, SUPI, SUCI, or temporary ID) and information on the session (eg, information on the session transmitted by the Remote UE) and PC5 session information (eg, including PC5 link identity) for identifying the session requested by the Remote UE) in the PDU Session Modification Request message). As per claim 4: YOUN in view LY discloses the method of claim 3, further comprising: transmitting a first message indicating the authentication for the second UE is completed to the second UE (YOUN: [0310] When authentication for the Remote UE is successfully completed and the Remote UE can receive service through the current Relay UE, the AMF may transmit a Remote UE Registration Accept message to the Relay UE. When the Remote UE transmits the SUCI in step 3), the AMF may allocate a temporary ID (eg, 5G-GUTI) to the Remote UE, and transmit the assigned temporary ID to the Relay UE. For example, the AMF may transmit a Remote UE Registration Accept message including information about the Remote UE ID (including temporary ID) to the Relay UE. The AMF may manage the Remote UE based on the remote UE's temporary ID (eg, 5G-GUTI); and receiving a second message which is a response to the first message from the second UE. transmitting a first message indicating the authentication for the second UE is completed to the second UE; and receiving a second message which is a response to the first message from the second UE (YOUN: [0343] The Remote UE may transmit a response (eg, a response to parameters related to the EAP message) to the Relay UE by including the response it in PC5 signaling (this transmission may be performed in the same manner of step 11 of FIGS. 10a and 10b). The Relay UE may include the Remote UE's response in the Authentication Response message and transmit the Authentication Response message to the AMF (this may be performed as the same way of step 12 of FIGS. 10a and 10b). In this case, the Relay UE may include information about Remote UE ID (e.g. SUCI or temp ID) in the Authentication Response message, in order to inform that the Authentication Response message is related to authentication for the Remote UE. When the authentication for the Remote UE (eg EAP authentication) is successfully completed, if the SMF transmitted an authentication request message including information about the Remote UE ID (SUCI) in Step 7, AUSF may transmit the authentication response message (eg, Nausf_ UEAuthentication _Authentication Response message) of step 12) to the AMF by including information (SUPI) about the Remote UE ID in the authentication response message). As per claim 5: YOUN in view LY discloses the method of claim 1, further comprising: receiving, from the second UE, a security request message for the second UE to be authenticated through the first UE in a communication network (YOUN: [0335] The SMF may transmit an authentication request message to the AMF. For example, when the information on the Remote UE ID received by the SMF in step 4) is a SUCI or a temporary ID, the SMF may transmit an authentication request message to the AMF. For another example, when the Remote UE transmits the SUPI (that is, when the information on the Remote UE ID received in step 4 by the SMF is SUPI) or when the SMF receives the SUPI through the operation described in (Option 1), in order to perform authentication for the Remote UE, the SMF may transmit an authentication request message to the AMF); and transmitting a response message to the security request message to the second UE (YOUN [0351] In step 19), the Relay UE receiving the PDU Session Authentication Command message may transmit parameters related to the EAP message included in the PDU Session Authentication Command message to the Remote UE by using PC5 signaling. For example, the Relay UE may transmit an authentication message including parameters related to the EAP message to the Remote UE by using PC5 signaling. The authentication message transmitted by the Relay UE may also include information on which PC5 session authentication is associated with (eg, PC5 session information). As per claim 6: YOUN discloses a method for supporting an authentication for a second user equipment (UE) by a session management function (SMF) in a wireless communication system, the method comprising: receiving, from a first UE, a packet data unit (PDU) session establishment message for a PDU session for the first UE ([0062] The illustrated SMF 420 may perform a function of allocating an Internet protocol (IP) address of the UE. In addition, the SMF may control a protocol data unit (PDU) session. ([0252-0254] While the PDU session establishment procedure is being performed, the Data Network-Authentication, Authorization, and Accounting (DN-AAA) server may perform secondary authentication/authentication. Here, the secondary authentication/authorization may mean authentication/authorization through a data network (DN) outside the domain of the mobile operator. A DN-AAA server may belong to 5GC or DN. When the procedure for establishing a PDU session to the Data Network (DN) is performed, the following operations may be performed: The DN-specific identity of the UE can be authenticated/authorized by the DN); [0345] 4) The Relay UE may transmit a PDU Session Modification Request message to the SMF through the AMF. The PDU session modification request message may include ID information of the Remote UE and PC5 session information. At this time, in order to inform that the Relay UE starts the relay for the Remote UE, Relay UE may include ID information and PC5 session information (eg, session information transmitted by the UE (eg, session information that the Remote UE wants to receive service e.g. DNN, S-NSSAI)+PC5 session information for identifying the session requested by the Remote UE (eg, information for identifying the link created in the PC5 link e.g. PC5 link id)) in the PDU session modification request message. If the Remote UE provided information for secondary authentication to the relay UE, the Relay UE may include information for secondary authentication in the PDU session modification request message and transmit the PDU session modification request message); transmitting, to the first UE, a PDU session establishment response message corresponding to the PDU session establishment message ([0156] More specifically, when the AMF is changed, the new AMF notifies the new AMF that provides services to the UE to each SMF. The AMF authenticates the PDU session status from the UE by using available SMF information. In case the AMF is changed, the available SMF information may be received from the previous (or old) AMF. The new AMF may send a request to the SMF to release (or cancel) network resources related to a PDU session that is not activated in the UE. ([0294-0295] FIGS. 10a and 10b show Remote UE, Relay UE, AMF, Remote UE Authentication Server Function (RAUSF), SMF, DN-AAA (DN-AAA Server), and UDM. 1) Relay UE may perform registration procedure and PDU session establishment procedure. For example, for relaying to the Remote UE, the Relay UE may perform a registration procedure and may establish (or generate) a PDU session for relaying data of the Remote UE. (eg, SUPI, SUCI, or temporary ID); Note that Remote UE is considered as the second user equipment UE. [0299]5) The AMF may transmit an Authentication Request message to the Remote UE Authentication Server Function (RAUSF) to start the authentication procedure for the Remote UE. The authentication request message transmitted by the AMF may include information on the Relay UE ID and information on the Remote UE ID (eg, SUPI, SUCI, or temporary ID)); [0350] 7 and 8) The SMF may inform the Remote UE that the service is allowed. For example, the SMF may transmit a PDU session modification command message (including ID information of the Remote UE and PC5 session information) to the Relay UE via the AMF. Then, the Relay UE may transmit a direct communication accept message including the Remote UE IP address to the Remote UE. Here, the Remote UE IP address may refer to IP address information of the Remote UE used in the PC5 link); receiving, from the first UE, a security trigger request message to request he authentication transmitting, to the first UE, a security trigger response message including authentication information for the second UE ([0300] 6 and 7) RAUSF may obtain AV (Authentication Vector) and SUPI information for remote UE authentication from UDM based on information on Remote UE ID. For example, the RAUSF may transmit a request message (eg, Nudm_UEAuthentication_Get request message) including information (eg, SUCI) on the Remote UE ID to the UDM. Then, the UDM may transmit a response message (eg, Nudm_UEAuthentication_Get response message) including information about the Remote UE ID (eg, SUPI) and AV (Authentication Vector) to RAUSF. The UDM may provide the RAUSF with a SUPI matching the SUCI received from the RAUSF. [0330] 5) When the information on the Remote UE ID received by the SMF in step 4) is SUCI, the SMF may transmit a request message (eg, Nudm_UEAuthentication_Get request message) to the UDM. The SMF may transmit a Nudm_UEAuthentication_Get request message including information on the Remote UE ID (SUCI) to the UDM. Additionally, the SMF may include an indication (or information) indicating that it is related to the Remote UE in the Nudm_UEAuthentication_Get request message. [0331] 6) The UDM may generate a SUPI based on the SUCI transmitted by the SMF. The UDM may transmit a response message (eg, Nudm_UEAuthentication_Get response message) to the SMF. The response message (eg, Nudm_UEAuthentication_Get response message) may include information about the Remote UE ID (SUPI). [0332] When the SMF transmits an indication (or information) indicating that the UDM is related to the Remote UE, the UDM may include only the SUPI in the response message (eg, Nudm_UEAuthentication_Get response message) without including the AV. Alternatively, when the SMF transmits a request message (eg, Nudm_UEAuthentication_Get request message), regardless of whether the SMF transmitted an indication (or information) indicating it is related to the Remote UE or not, the UDM may not include the AV, but only include the SUPI in the response message (eg Nudm_UEAuthentication_Get response message). The reason why the UDM does not transmit the AV is that the AV is used when authenticating the terminal during the registration procedure and does not need to be used after step 7). [0340-0343] AUSF, SMF, AMF, Relay UE and Remote UE may perform the EAP authentication procedure. After the EAP authentication procedure is performed, the AUSF may transmit an authentication response message (eg, Nausf_UEAuthentication_Authentication Response message) including information about the Remote UE ID (eg, SUPI) to the AMF. The AMF may transmit an authentication response message including information about the Remote UE ID (eg, SUPI) to the SMF….When the Relay UE receives the Authentication Request message for the Remote UE, the Relay UE may transmit parameters related to the EAP message to the Remote UE using PC5 signaling (PC5 signaling may be performed as the same manner of step 10) of FIGS. 10a and 10b). The Remote UE may transmit a response (eg, a response to parameters related to the EAP message) to the Relay UE by including the response it in PC5 signaling (this transmission may be performed in the same manner of step 11 of FIGS. 10a and 10b). The Relay UE may include the Remote UE's response in the Authentication Response message and transmit the Authentication Response message to the AMF (this may be performed as the same way of step 12 of FIGS. 10a and 10b). In this case, the Relay UE may include information about Remote UE ID (e.g. SUCI or temp ID) in the Authentication Response message, in order to inform that the Authentication Response message is related to authentication for the Remote UE. When the authentication for the Remote UE (eg EAP authentication) is successfully completed, if the SMF transmitted an authentication request message including information about the Remote UE ID (SUCI) in Step 7, AUSF may transmit the authentication response message (eg, Nausf_UEAuthentication_Authentication Response message) of step 12) to the AMF by including information (SUPI) about the Remote UE ID in the authentication response message). YOUN does not explicitly discloses wherein the authentication information for the second UE includes group key information of a group to which the first UE and the second UE belong. LY, in analogous art however, discloses wherein the authentication information for the second UE includes group key information of a group to which the first UE and the second UE belong ([0209] After receiving the new parameters, the NAS Layer of a UE 102 can establish a “Shared PDU Session” with the core network 106. This Shared PDU Session is a special PDU session with a primary PDU session ID and one or more secondary PDU session IDs. The shared PDU session contains data from multiple PDU Session IDs, which represent the one or more secondary PDU session IDs, that have been aggregated as described herein. A UE 102 can include a primary PDU Session ID for this shared PDU session, a Shared PDU Session indication, the Traffic Group ID, and a list of secondary PDU Session IDs of other UEs in a PDU Session Establishment request where the provided secondary PDU Session IDs are associated with aggregated data over this shared PDU session. These secondary PDU Session IDs and the Traffic Group ID can be included along with the aggregated data to inform a Relay Aggregation (RA) UPF on how to route the data from the individual UEs. These secondary PDU Session IDs may have been received by the relay UE via PC5 signaling from other UEs. [0210] The SMF 174 will use the secondary PDU Session IDs to determine the UPF anchors 176b, 176c, etc. identified by each PDU session ID. The SMF 174 will then perform a UPF selection procedure to select an RA UPF that will be used to de-aggregate and aggregate the data of PDU session IDs of UL and DL traffic, respectively. The SMF 174 will provide the secondary PDU Session IDs, the Traffic Group ID, and the Delay Tolerant Data Period to the selected RA UPF. The SMF 174 will also configure the RA UPF and the PSA UPFs with tunnel information so that data can be tunneled between the RA UPF and PSA UPFs. The RA UPF in turn will use the secondary PDU Session IDs, the Traffic Group ID, and the Delay Tolerant Data Period in making UL and DL traffic routing decisions. For UL traffic routing, the UPF 176 can interface to the multiple PSA UPFs using the secondary PDU Session IDs and the Traffic Group ID and the tunnel parameters that can be received from the SMF. For DL traffic routing, the RA UPF can use the Delay Tolerant Data Period and the Traffic Group ID to aggregate data from potentially multiple PSA UPFs for different UEs before sending the aggregated data to the relay UE via the RAN node 105. [0233] An RA UPF that supports this shared PDU session concept can perform the de-aggregation of UL data to one or more PSA UPFs similar to an UL CL or BP UPF. However, unlike the UL CL or the BP UPF cases, the establishment of a shared PDU session automatically selects a UPF that supports relay aggregation to manage routing both UL and DL data associated with the shared PDU session to and from multiple PSA UPFs. The relay UE sends a combined message including data from multiple PDU Session IDs of other UEs. Within the combined message, a Traffic Group ID is inserted along with the aggregated data that are organized according to the PDU Session ID they belong to. The Traffic Group ID allows the RA UPF to make a determination to parse the combined message into individual PDU sessions and route them to the associate PSA UPFs. [0234] To support the shared PDU session concept, the session management procedures of TS 23.502 (3GPP TS 23.502, Procedures for the 5G System; V15.4.1 (2019 January)), incorporated herein by reference, are modified for specifying a request for shared PDU session functionality. Using FIGS. 3A and 3B as the basis for the modifications to the PDU Session Establishment procedure, the following are differences to the procedure to support shared PDU sessions. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations of supporting authentication of a user equipment (UE) in a wireless communication system disclosed by YOUN to include wherein the authentication information for the second UE includes group key information of a group to which the first UE and the second UE belong. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to provide an electronic device that includes a circuitry configured to send a request to a core network, wherein the request informs the core network that the electronic device is capable of aggregating data and relaying data from other electronic devices; receive one or more aggregation policies from the core network, wherein the one or more aggregation policies provide parameters that instruct how the electronic device is to aggregate and relay data; receive data from the other electronic devices; aggregate the data from the other electronic devices based on the parameters; and send the aggregated data to the core network as suggested by LY ([0004-0008]). As per claim 7: YOUN in view LY discloses the method of claim 6, wherein the authentication information for the second UE further includes one of an extensible authentication protocol (EAP) authentication message for performing authentication, an EAP authentication request message, an EAP success message, or an EAP failure message (YOUN; [0301] 8) RAUSF may generate an Extensible Authentication Protocol (EAP)-Request message for authentication to the Remote UE. RAUSF may transmit an Authentication Response message including the EAP-Request message and information about the Remote UE ID (information transmitted by the UE in step 3) (eg, SUPI, SUCI, or temporary ID) to the AMF. Here, when the Relay UE has a plurality of Remote UEs (when communicating with a plurality of Remote UEs), in order to inform which Remote UE the message is for authentication, RAUSF may transmit information about the Remote UE ID). As per claim 8: YOUN in view LY discloses the method of claim 6, further comprising: transmitting an authentication request message for requesting authentication of the second UE to an authentication, authorization, and accounting (AAA) based on the security trigger request message (YOUN [0252-0254] While the PDU session establishment procedure is being performed, the Data Network-Authentication, Authorization, and Accounting (DN-AAA) server may perform secondary authentication/authentication. Here, the secondary authentication/authorization may mean authentication/authorization through a data network (DN) outside the domain of the mobile operator); and receiving an authentication response message corresponding to the authentication request message from the AAA (YOUN [0252-0254]: A DN-AAA server may belong to 5GC or DN. When the procedure for establishing a PDU session to the Data Network (DN) is performed, the following operations may be performed: The DN-specific identity of the UE can be authenticated/authorized by the DN). As per claim 9: YOUN in view LY discloses the method of claim 6, further comprising: transmitting a security request message for requesting authentication of the first UE to an authentication, authorization, and accounting (AAA) based on the PDU session establishment message; and receiving a security response message corresponding to the security request message from the AAA (YOUN [0357] 25) When the SMF receives a message from the DN-AAA server indicating that the secondary authentication has been successfully performed, the SMF may transmit a PDU Session Modification Command message to the Relay UE. Here, the PDU session modification command message may include information on the Remote UE ID and information on which whether PC5 session authentication has been successful. When the SMF receives a message from the DN-AAA server notifying that the secondary authentication has failed, the PDU session modification command message may include information about the Remote UE ID and at which stage (eg network authentication or secondary authentication) authentication failed. In addition, the SMF may include the ID (e.g. 5G-GUTI) allocated by the AMF for the Remote UE in the PDU Session Modification Command message and transmit the PDU Session Modification Command message to the Relay UE). As per claims 10-13: Claims 10-13 are directed to a first user equipment (UE) supporting authentication of a second UE in a wireless communication system, the first UE comprising: a transceiver; and a processor controlling to perform features having substantially similar corresponding limitations of claims 1-4 respectively and therefore claims 10-13 are rejected with the same rationale given above to reject corresponding limitations of claims 1-4 respectively. As per claim 14-15: Claims 14-15 are directed to a session management function (SMF) supporting authentication of a second user equipment (UE) in a wireless communication system, the SMF_comprising: a transceiver; and a processor controlling to features having substantially similar corresponding limitations of claims 6-7 respectively and therefore claims 14-15 are rejected with the same rationale given above to reject corresponding limitations of claims 6-7 respectively. Concussion The prior arts made of record and not relied upon are considered pertinent to applicant's disclosure. See the notice of reference cited in form PTO-892 for additional prior arts. KIM et al. (US 20250016560 A1) discloses authenticating a UE in which a first UE receives authentication mode information, wherein a second UE relaying the first UE also receives the authentication mode information, and the first UE, on the basis of the authentication mode information, requests information necessary for direct search between UEs; a step in which the first UE receives the information necessary for direct searches between UEs; and a step for connecting to a network and performing authentication via the second UE on the basis of the received information necessary for direct searches between the UEs. LIAO et al. (US 20210360742 A1) discuses relay service enabled between a residential gateway and a remote user. A 5G residential gateway (5G-RG) includes a relay user equipment (UE) to enable relay service for a 5G core (5GC)-capable UE behind the 5G-RG to connect to the 5GC. The relay UE of the 5G-RG may provide a trusted/untrusted non-3GPP access network for L2 or L3 transport connection to the 5GC-capable UE. Baskaran et al (US 20230284030) describes UAS authentication and security establishment that includes a transceiver that sends, from a first network function of a mobile wireless communication network, an authentication request message from a user equipment (“UE”) to a UAS Service Supplier (“USS”)/UAS Traffic Management (“UTM”). The UE includes an unmanned aerial vehicle (“UAV”) and a UAV controller (“UAV-C”). The transceiver receives, at the first network function from the USS/UTM, an authentication response message comprising a UAS identifier and a UAS security context. 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. Contact Information Any inquiry concerning this communication or earlier communications from the examiner should be directed to TECHANE GERGISO whose telephone number is (571)272-3784. The examiner can normally be reached 9:30am to 6:30pm. 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, LINGLAN EDWARDS can be reached at (571) 270-5440. 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. /TECHANE GERGISO/Primary Examiner, Art Unit 2408
Read full office action

Prosecution Timeline

Nov 01, 2024
Application Filed
Jan 28, 2026
Non-Final Rejection mailed — §103
Apr 27, 2026
Response Filed
Jul 24, 2026
Final Rejection mailed — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12706759
KEY MANAGEMENT AND SERVICE PROCESSING
2y 0m to grant Granted Aug 11, 2026
Patent 12701017
Authentication with Cloud-Based Secure Enclave
2y 6m to grant Granted Aug 04, 2026
Patent 12700052
CROSS-CERTIFICATE METHOD AND DEVICE FOR ELECTRIC VEHICLE CHARGING
2y 0m to grant Granted Aug 04, 2026
Patent 12695599
METHOD FOR USING CRYPTOGRAPHIC KEYS IN A VEHICLE ON-BOARD COMMUNICATION NETWORK
3y 0m to grant Granted Jul 28, 2026
Patent 12647399
BYPASSING IKE FIREWALL FOR CLOUD-MANAGED IPSEC KEYS IN SDWAN FABRIC
2y 2m to grant Granted Jun 02, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

3-4
Expected OA Rounds
84%
Grant Probability
99%
With Interview (+24.2%)
3y 1m (~1y 3m remaining)
Median Time to Grant
Moderate
PTA Risk
Based on 852 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month