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 .
This office action is in repones to the amendment filed on 10/22/2025. Claims 1-15 are pending.
Response to Arguments
Applicant’s arguments, see Remarks, filed 04/23/2025, with respect to the rejection(s) of claim(s) 1-15 under 102/103 have been fully considered and are not persuasive. Examiner acknowledges applicant’s point of view regarding the 35 U.S.C. 103 rejection but respectfully disagrees for the following reasons:
With respect to applicant’s argument that Yi does not teach "receiving, from the PKMF associated with the first WTRU, a key response message that includes generic bootstrapping architecture (GBA) push information (GPI)." Examiner respectfully disagrees because Yi teaches generating/obtaining GPI at the PKMF-like network device and returning a key-response that includes the GPI. (see for example, para [0176] - network device obtains GPI via a GBA push para [0187). Yi further discloses para, [0187] (‘the response message … needs to further include the GPI information’). Yi further shows that the key response is delivered to the remote UE via the relay and the remote uses the received Kd/GPI in subsequent security negotiation (para . [0186]–[0196], S303-S310). Yi describes a network device (PKMF-like entity) that obtains GPI and returns a key-response message containing that GPI, and further discloses delivery of that key-response to the remote WTRU (via the relay). See para. [0176] (“The network device obtains GPI of the eRemote UE based on the IMSI, where the GPI information is obtained by the network device based on a universal bootstrapping process in a push mode.”) and para [0187] (“The response message includes the identity of the Remote UE, the Kd generated by the network device, and the freshness parameter for generating the root key. If the network device obtains the GPI, the response message needs to further include the GPI information.”). Yi further describes returning this key-response to the relay and forwarding it to the remote UE and using the received Kd/GPI in security negotiation (S306–S310; see para [0186]–[0196]). Thus, Yi teaches a PKMF-associated network device that obtains GPI, (2) a key response message that includes the GPI, and (3) reception of that key response by the remote WTRU (delivered via the relay). Accordingly, Yi discloses receiving a key response from the PKMF that includes GPI.
With respect to applicant’s argument that Yi does not teach " transmitting, to the PKMF associated with the first WTRU, a PRUK confirmation message, wherein the PRUK confirmation message includes the PRUK ID." Examiner respectfully disagrees because Yi expressly discloses that, after the remote UE (first WTRU) sends a first request to the relay, the relay transmits a “second request message” to the network device that performs the ProSe key management function (PKMF), and that the second request message includes the first identity information of the remote UE. (see para [0142]–[0144] (“the second request message includes the first identity information or the second identity information of the eRemote UE”), and para [0140] (defining “first identity information” as including the proximity service relay user key identity, PRUK ID). Moreover, Yi further explains that this message is used by the PKMF/network device to obtain and/or confirm the association between the PRUK/PRUK ID and the subscriber (IMSI) and to proceed with keying, and further to store/update that correspondence at the HSS/MME (see para [0151]–[0156]). In terms of the Yi’s disclosure labels the message a “second request message” (key request) rather than a “PRUK confirmation message” is a matter naming and both elements are still equivalent; functionally, it confirms to the PKMF the PRUK identity being used for the session by explicitly including the PRUK ID and triggering the PKMF’s association/storage operations. Thus, Yi teaches transmitting to the PKMF a message that includes the PRUK ID and that operates as a PRUK confirmation, and therefore meets the recited limitation.
With respect to applicant’s argument that Fu does not teach "transmitting, to the PKMF associated with the first WTRU, a PRUK confirmation message, wherein the PRUK confirmation message includes the PRUK ID." Examiner respectfully disagrees because Fu’s UP-based security procedure, the remote UE (first WTRU) sends a Direct Communication Request that “contains the PRUK ID or a SUCI” (see step 603; para. [0196]). The relay then “sends a Key Request message that contains PRUK ID or SUCI, RSC and KNRP freshness parameter 1 to its 5G PKMF” (see step 604a; para. [0197]). Fu further discloses that the “5G PKMF of the Relay UE sends the Key Request with the PRUK ID or the SUCI to the 5G PKMF of the Remote UE” (see step 604b; para [0198]). Thus, Fu expressly teaches a transmission to the PKMF associated with the first WTRU (the remote UE’s PKMF) of a message that includes the PRUK ID. Functionally, this message confirms the PRUK identity being used for the session and triggers the PKMF’s authorization and key derivation operations (see para [0198]–[0204]). Furthermore, Fu’s CP-based procedure identifies the 5GPRUK ID in subsequent control messages and storage (see for e.g., step 511 and step 518, para. [0171], [0178]), reinforcing that the system communicates and records the PRUK ID as part of establishing relay security. The fact that Fu labels the message a “Key Request” rather than “PRUK confirmation” is a matter of naming and both elements are still equivalent; functionally; the disclosure meets the limitation because it teaches transmitting to the PKMF a message that includes the PRUK ID and confirms/associates the PRUK for the session.
With respect to the applicant argument that Fu does not teach “the first WTRU send a direct connection request (DCR) including a PRUK ID, receive a connection reject containing a cause code.” Examiner respectfully disagrees and points out that Fu explicitly teaches that the remote UE’s Direct Communication Request (DCR) may “contain [] the PRUK ID” (UP-based flow step 603; par. [0195]), thereby meeting the recited limitation that the first WTRU sends a DCR including a PRUK ID. Applicant’s contention that Fu does not teach receipt of a connection-reject/failure with a cause code is not persuasive. Fu expressly describes Direct Security Mode Failure and synchronization-failure handling and the Relay’s response (e.g., “The Relay UE shall send the key request message … upon receiving the Direct Security Mode Failure message from the Remote UE” (see para. [0210]), and Fu repeatedly relies on and cites 3GPP procedures (e.g., TS 33.536, TS 23.752, TS 33.503, TS 33.303) that define standard reject/failure messages and cause Information elements. Fu therefore contemplates and discloses failure/reject signaling and the forwarding of failure/cause information to the PKMF. Fu discloses the presence of a reject/failure indication with cause is supported by Fu’s explicit failure-handling text and its incorporation of the applicable 3GPP standards.
Due to the reasons set forth above, the previous 35 U.S.C. 103 rejection has been maintained.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-12 is/are rejected under 35 U.S.C. 103 as being unpatentable Fu ( US 20240196206 A1 filed: 05/21/2022 ) in view of YI et al. (US 2020/0213858) herein after YI.
Regarding claim 1, Fu teaches the method for facilitating a secure direct connection between wireless transmit/receive units.
Fu teaches: A method performed by a first wireless transmit/receive unit (WTRU), the method comprising:
receiving, from a second WTRU, a request for connection, wherein the request for connection includes a proximity service (ProSe) remote user key (PRUK) ID; (Paragraph [0195] and Fig. 6 disclose the Remote user equipment(UE), equated to applicants second WTRU, will send a direct communication request that contains the PRUK ID, Relay Service Code(RSC), and a KNRP freshness parameter 1.)
transmitting, to a ProSe Key Management Function (PKMF) associated with the first WTRU, a key request message that includes the PRUK ID received from the second WTRU; (Paragraph [0196] and Fig. 6 disclose Relay UE, equated to applicants first WTRU, sends a Key Request message to the PKMF that contains PRUK ID, RSC and KNRP freshness parameter 1.)
transmitting, to the second WTRU, a direct security mode command message that includes the GPI; (Paragraph [0207] and Fig. 6 disclose the relay receiving a GPI and KNRP freshness parameter 2 and sending it to the remote UE in a direct security mode command message.)
receiving, from the second WTRU, a direct security mode complete message; and (Paragraph [0211] and Fig. 6 disclose the Remote UE responds with a Direct Security Mode Complete message to the Relay UE.)
transmitting, to the PKMF associated with the first WTRU, a PRUK confirmation message, wherein the PRUK confirmation message includes the PRUK ID. (Paragraph [0212] and Fig. 6 disclose the Relay UE 216 shall verify the Direct Security Mode Complete message it would be obvious for one to perform the verification via PRUK ID confirmation as used in earlier steps in the claim which would not require any extra experimentation and would yield predictable results.)
Fu does not explicitly disclose receiving, from the PKMF associated with the first WTRU, a key response message that includes generic bootstrapping architecture (GBA) push information (GPI);
YI in analogous art, however, discloses receiving, from the PKMF associated with the first WTRU, a key response message that includes generic bootstrapping architecture (GBA) push information (GPI); (Paragraph [0140]-[0152], [0176]-[0177] network device performs bootstrapping process in a push mode based on IMSI of eRemote UE, …generates the push process P-TID and obtains GPI or eRemote UE… transmits to the eRelay UE) and transmitting, to the PKMF associated with the first WTRU, a PRUK confirmation message, wherein the PRUK confirmation message includes the PRUK ID. (Paragraph [0140]-[0152, [0180]-[0182], network device sends an update proximity service policy … request message includes the PRUK and the PRUK ID of the eRemote UE and the identity of the eRelay UE].Therefore, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of YI into the teaching of Fu by receiving a key response message that includes GBA and push information from the PKMF associated with the first WTRU. One would be motivated to do so in order to prevent spoofing action such as fraud on the remote terminal and protecting privy. (see Paragraph [0005], [0006], YI)
Regarding claim 2, Fu in view YI teaches the method of claim 1 as detailed above. Fu further teaches: The method of claim 1, further comprising: validating the direct security mode complete message. (Paragraph [0212] and Fig. 6 disclose the Relay UE 216 shall verify the Direct Security Mode Complete message.)
Regarding claim 3, Fu in view YI teaches the method of claim 1 as detailed above. Fu further teaches: The method of claim 1, further comprising: receiving, from the PKMF associated with the first WTRU, an acknowledgement that the PRUK confirmation message was received; and (Paragraph [0212] and Fig. 6 disclose the Relay UE 216 shall verify the Direct Security Mode Complete message it would be obvious for one to perform the verification via PRUK ID confirmation as used in earlier steps in the claims which would not require any extra experimentation and would yield predictable results.)
transmitting, to the second WTRU, an acceptance of the request for connection. (Paragraph [0213] and Fig. 6 discloses the relay UE will send a communication accept message to the remote UE.)
Regarding claim 4, Fu in view YI teaches the method of claim 1 as detailed above. Fu further teaches: The method of claim 1, wherein the request for connection is a Direct Communication Request message. (Paragraph [0195] and Fig. 6 discloses the remote UE sends a direct communication request.)
Regarding claim 5, Fu in view YI teaches the method of claim 1 as detailed above. Fu further teaches: The method of claim 1, wherein the key request message includes a relay service code (RSC) and KNRP freshness parameter 1. (Paragraph [0196] and Fig. 6 disclose Relay UE, sends a Key Request message to the PKMF that contains PRUK ID, RSC and KNRP freshness parameter 1.)
Regarding claim 6, Fu in view YI teaches the method of claim 1 as detailed above. Fu further teaches: The method of claim 1, wherein the direct security mode command message includes a KNRP freshness parameter 2. (Paragraph [0207] and Fig. 6 disclose the relay receiving a GPI and KNRP freshness parameter 2 and sending it to the remote UE in a direct security mode command message.)
Regarding claim 7, Fu teaches the wireless transmit and receive unit for managing direct communication connections. Fu teaches: A first wireless transmit receive unit (WTRU), comprising:
a transceiver; and (Paragraph [0302] discloses a communication component comprising means for communication)
a processor; (Paragraph [0074] discloses a processor for executing the instructions to operate the communication device. )
wherein the transceiver and processor are configured to:
receive, from a second WTRU, a request for connection, wherein the request for connection includes a proximity service (ProSe) remote user key (PRUK) ID; (Paragraph [0195] and Fig. 6 disclose the Remote user equipment(UE), interpreted as the second WTRU, will send a direct communication request that contains the PRUK ID, Relay Service Code(RSC), and a KNRP freshness parameter 1.)
transmit, to a ProSe Key Management Function (PKMF) associated with the first WTRU, a key request message that includes the PRUK ID received from the second WTRU; (Paragraph [0196] and Fig. 6 disclose Relay UE, equated to applicants first WTRU, sends a Key Request message to the PKMF that contains PRUK ID, RSC and KNRP freshness parameter 1.)
transmit, to the second WTRU, a direct security mode command message that includes the GPI; (Paragraph [0207] and Fig. 6 disclose the relay receiving a GPI and KNRP freshness parameter 2 and sending it to the remote UE in a direct security mode command message.)
receive, from the second WTRU, a direct security mode complete message; and (Paragraph [0211] and Fig. 6 disclose the Remote UE responds with a Direct Security Mode Complete message to the Relay UE.)
transmit, to the PKMF associated with the first WTRU, a PRUK confirmation message, wherein the PRUK confirmation message includes the PRUK ID. (Paragraph [0212] and Fig. 6 disclose the Relay UE 216 shall verify the Direct Security Mode Complete message it would be obvious for one to perform the verification via PRUK ID confirmation as used in earlier steps in the claim which would not require any extra experimentation and would yield predictable results.)
Fu does not explicitly disclose receiving, from the PKMF associated with the first WTRU, a key response message that includes generic bootstrapping architecture (GBA) push information (GPI);
YI in analogous art, however, discloses receiving, from the PKMF associated with the first WTRU, a key response message that includes generic bootstrapping architecture (GBA) push information (GPI); (Paragraph [0140]-[0152], [0176]-[0177] network device performs bootstrapping process in a push mode based on IMSI of eRemote UE, …generates the push process P-TID and obtains GPI or eRemote UE… transmits to the eRelay UE) and transmitting, to the PKMF associated with the first WTRU, a PRUK confirmation message, wherein the PRUK confirmation message includes the PRUK ID. (Paragraph [0140]-[0152, [0180]-[0182], network device sends an update proximity service policy … request message includes the PRUK and the PRUK ID of the eRemote UE and the identity of the eRelay UE]. Therefore, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of YI into the teaching of Fu by receiving a key response message that includes GBA and push information from the PKMF associated with the first WTRU. One would be motivated to do so in order to prevent spoofing action such as fraud on the remote terminal and protecting privy. (see Paragraph [0005], [0006], YI)
Regarding claim 8, Fu in view of YI teaches the method of claim 7 as detailed above.
Fu further teaches: The first WTRU of claim 7, wherein the transceiver and processor are further configured to: validate the direct security mode complete message. (Paragraph [0212] and Fig. 6 disclose the Relay UE 216 shall verify the Direct Security Mode Complete message.)
Regarding claim 9, Fu in view of YI teaches the method of claim 7 as detailed above. Fu further teaches: The first WTRU of claim 7, wherein the transceiver and processor are further configured to: receive, from the PKMF associated with the first WTRU, an acknowledgement that the PRUK confirmation message was received; and (Paragraph [0212] and Fig. 6 disclose the Relay UE shall verify the Direct Security Mode Complete message it would be obvious for one to perform the verification via PRUK ID confirmation as used in earlier steps in the claims which would not require any extra experimentation and would yield predictable results.) transmit, to the second WTRU, an acceptance of the request for connection. (Paragraph [0213] and Fig. 6 discloses the relay UE will send a communication accept message to the remote UE.)
Regarding claim 10, Fu in view of YI teaches the method of claim 7 as detailed above. Fu further teaches: The first WTRU of claim 7, wherein the request for connection is a Direct Communication Request message. (Paragraph [0195] and Fig. 6 discloses the remote UE sends a direct communication request.)
Regarding claim 11, Fu in view of YI teaches the method of claim 7 as detailed above. Fu further teaches: The first WTRU of claim 7, wherein the key request message includes a relay service code (RSC) and KNRP freshness parameter 1. (Paragraph [0196] and Fig. 6 disclose Relay UE, sends a Key Request message to the PKMF that contains PRUK ID, RSC and KNRP freshness parameter 1.)
Regarding claim 12, Fu in view of YI teaches the method of claim 7 as detailed above. Fu further teaches: The first WTRU of claim 7, wherein the direct security mode command message includes a KNRP freshness parameter 2. (Paragraph [0207] and Fig. 6 disclose the relay receiving a GPI and KNRP freshness parameter 2 and sending it to the remote UE in a direct security mode command message.)
Claims 13-15 are rejected under 35 U.S.C. 103 as being unpatentable over Kim ( US 20200100088 A1 filed: 01/08/2018 ) in view of Fu ( US 20240196206 A1 filed: 05/21/2022) and in view of Lee et al. (US 2022/0109996) hereinafter Lee.
Regarding claim 13, Kim and Fu teach the wireless transmit/receive unit for connection rejections. Kim teaches: A first wireless transmit/receive unit (WTRU), comprising:
a transceiver; and (Paragraph [0898] and Fig. 25 disclose a receiver and transmitter as part of the system unit.)
a processor; (Paragraph [0895] and Fig. 25 disclose a processor as part of the system unit.)
wherein the transceiver and processor are configured to:
transmit, to a second WTRU, a request for connection that includes a first proximity service (ProSe) remote user key (PRUK) ID associated with a PRUK; (Paragraphs [202]-[206] when the initializing UE request a connection to the target UE the connection request will include a PRUK ID an associated PRUK.)
receive, from the second WTRU, a connection reject message that includes a cause code; (Paragraphs [240] and [271] disclose sending a connection rejection message accompanied by the cause value.)
determine, based on the cause code, that the PRUK is [[out of sync with a proximity service (ProSe)]] Key Management Function (PKMF) associated with the first WTRU; Paragraphs [240] and [357] discloses a plurality of cause values, equated to applicants cause codes, that will disclose the connection rejection issue including an authentication synchronization error.)
transmit, to the second WTRU, a connection request message that includes (Paragraphs [202]-[207] when the initializing UE request a connection to the target UE the connection request will include the International Mobile Subscriber Identity(IMSI).)
Kim does not explicitly teach: a subscription concealed identifier (SUCI).
Fu teaches: a subscription concealed identifier (SUCI). (Paragraph [0148] discloses using the SUCI as a method of identification to be passed along with the direct connection request.)
Both Kim and Fu are directed towards wireless transceiver units and connection security. It would have been obvious to a person of ordinary skill in the art before the effective filing date to modify the teaching of Kim to include the SUCI encrypted version of the IMSI as taught by Fu for the purpose of adding addition security when transmitting connection requests. (Fu Paragraph [0148])
Kim in view of Fu does not explicitly disclose, however, Lee discloses determine, based on the cause code, that the PRUK is out of sync with a proximity service (ProSe); (Paragraph [0080]-[0086], freshness parameter 1 and freshness parameter 2, request contains PRUK ID, …freshness parameter). It would have been obvious to a person of ordinary skill in the art before the effective filing date to modify the teaching of Kim and Fu for the purpose of providing connection setup that includes discovery parameters and relay security information thereby providing establishing a secure connection between two remote UEs (Lee Abstract, [0005]).
Regarding claim 14, Kim and Fu and Lee teach the method of claim 13 as detailed above.
Kim further teaches: The first WTRU of claim 13, wherein the cause code indicates that the PRUK ID is invalid. (Paragraphs [240]-[246] discloses a plurality of cause values, equated to applicants cause codes, that will disclose the connection rejection issue including an authentication error which would correspond to applicants invalid PRUK ID code.)
Regarding claim 15, Kim and Fu and Lee teach the method of claim 13 as detailed above. Kim further teaches: The first WTRU of claim 13, wherein the request for connection is a Direct Communication Request message. (Paragraph [187] discloses that the connection request is a direct communication request.)
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Ahmad et al. US 2016/0295347 directed to proximity services (ProSe) direct discovery,
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Shewaye Gelagay whose telephone number is (571)272-4219. The examiner can normally be reached Monday to Friday 8 A.M. - 4 P.M..
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, Amy Cohen Johnson can be reached at (571)272-2238. 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.
/SHEWAYE GELAGAY/Supervisory Patent Examiner, Art Unit 2436