DETAILED ACTION
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 .
Priority
The instant application is a 371 of PCT/CN2022/142733 which has foreign priority claims to CN202210701819.5 and CN202111681982.1 filed 12/31/2021. The priority claims comply with all applicable rules and regulations. Therefore, the effective filing date of the claims is 31 December 2021.
Information Disclosure Statement
The Information Disclosure Statement filed on 26 January 2026 complies with all applicable rules and regulations. Therefore, the information referred to therein has been considered.
Response to Arguments
Applicant's arguments filed 05 June 2026 have been fully considered but they are not persuasive.
In response to applicant’s arguments that “[n]either Lehtovirta nor Bone involves a first device and a second device that are in the same trust domain” stated on page 14, the examiner respectfully disagrees.
Lehtovirta discloses a method for obtaining AS-specific keys for an Authentication Proxy (AP) scenario, wherein this embodiment is intended for a general AP-AS scenario in which several ASs 16a and 16b may reside behind an AP 15 (Fig. 8; Para. 104). At a new step 6b, the AP 15 determines which AS should receive the request, and the AP derives an AP-specific key Ks_AS from the Ks_NAF and a nonce using a key derivation function such as Ks_AS =KDF (Ks_NAF, nonce) (Fig. 8, el. 6b; Para. 106). At step 7, the AP 15 sends the Ks_AS and the identity of the AS (e.g., FQDN) in an HTTP request to the identified AS 16a (Fig. 8, el. 7; Para. 107). At step 9b, the UE derives the AS-specific key Ks_AS from the Ks_NAF and the nonce, and at step 10, the AS 16a sends a message protected with Ks_AS to the UE, and the UE 11 is then able to decrypt and verify the message using Ks_AS, and the UE uses the AS identity to identify the correct Ks_AS (Fig. 8, el. 9b, 10; Para. 108).
Lehtovirta further discloses 3GPP TS 33.222 clause 6 specifies the use of an Authentication Proxy (AP) in the NAF 13. The AP is compatible with the GBA architecture specified in TS 33.220. When an AP is used in this architecture, the AP relieves the Application Server (AS) of security tasks by taking the role of a NAF (Para. 9).
The NAF/AP and each AS that is behind the NAF/AP would be considered to be in the same trust domain since the NAF/AP “relieves the Application Server (AS) of security tasks”.
Bone discloses the NAF 122 may act as a proxy in front of the DM server 120. As a proxy, the NAF 122 would terminate the connection from the UE 110 (thus acting as a server to the UE 110) and start a new connection with the DM server 120 (thus acting as a client to the DM server 120) (Para. 408), and the NAF 122 may act as a router, located between the UE 110 and the DM server 120, wherein the NAF 122 may then pass Ua 150 traffic from the UE 110 on to the DM server 120 and pass Ua 150 traffic from the DM server 120 back to the UE 110 (Fig. 1, el. 110, 150; Para. 409). The NAF 122 can terminate the security established over the Ua 150 interface using the Ks_NAF (or a key(s) derived from the Ks_NAF) and then pass the Ua 150 traffic on to the DM server 120, encrypted in a way that does not necessarily require the DM server 120 to be GBA aware (Para. 410).
The NAF and the DM server may be considered to be in the same trust domain since the NAF may act as a proxy and/or a router for the DM server.
Therefore, the cited prior art teaches the aforementioned limitation.
The examiner suggests amending the independent claims to clarify how the first device and the AF/AS are considered to be in the same trust domain.
Applicant states “Independent claims 13, 22, and 24 include similar features, and are allowable for at least similar reasons, as claim 1” on page 14. It should be noted that independent claim 22 was only amended to correct an informality and does not include the same language as claim 1.
Claim Objections
Claims 1, 2, 10, 17, and 24 are objected to because of the following informalities:
Regarding Claim 1, line 6—“” includes both strike-through and underlining formatting. For examination purposes, the phrase will be interpreted to not be a part of the claim.
Regarding claim 2, line 2—“a second device” appears to be referring to “a second device” of claim 1. This objection may be overcome by amending line 2 to state --the second device--.
Regarding claim 10, line 2—“data” and “a third key” appears to be referring to “a data” in line 7 of claim 1 and “a third key” of line 8 of claim 1, respectively. This objection may be overcome by amending line 2 to state --the data-- and --the third key--, respectively.
Regarding claim 17, line 3—“a third key” appears to be referring to “a third key” of claim 13. This objection may be overcome by amending line 2 to state --the third key--.
Regarding claim 24, line 1—“A communication device” appears to be referring to “a user equipment (UE)” of claim 13. This objection may be overcome by amending line 1 to state the --method of according to claim 13, wherein the user equipment (UE) comprises…key management method--, for example. Alternatively, claim 24 could be rewritten to be an independent claim.
Appropriate correction is required.
Claim Rejections - 35 USC § 102
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim 22 is rejected under 35 U.S.C. 102(a)(2) as being anticipated by Peng et al. (US 2023/0413055 A1).
Regarding claim 22, Peng teaches a communication device, e.g., Application Function (AF) 525/635 (Fig. 5, el. 525; Fig. 6, el. 635); 5GDDNMF 715 (Fig. 7, el. 715), comprising a memory, e.g., apparatus 1005 can include one or more memories configured to store information such as data and/or instructions (Fig. 10, el. 1005; Para. 92),
a processor, e.g., processor electronics 1010 such as a microprocessor that implements one or more of the techniques presented in this document (Fig. 10, el. 1010; Para. 92), and
a program stored in the memory and executable on the processor; the processor is configured to execute the program to perform, e.g., apparatus 1005 can include one or more memories configured to store information such as data and/or instructions, and processor electronics 1010 such as a microprocessor that implements one or more of the techniques presented in this document (Para. 92):
receiving a session establishment request message initiated by a user equipment (UE), e.g., User equipment (UE) 510/610/710 (Fig. 5, el. 510; Fig. 6, el. 610; Fig. 7, el. 710) initiating the application session establishment requests 501, wherein the request message carries a key identifier, e.g., When the UE initiates communication with the AKMA AF, it may include the derived A-KID—key identifier-- in the Application Session Establishment request message (e.g., operation 501 in FIG. 5) (Fig. 5, el. 501; Para. 55);
at operation 602a, the UE initiates TLS with Pre-Shared Key (PSK) authentication with the AF server, wherein the UE sends Client Hello—session establishment request-- where the ClientHello contains a pre_shared_key extension including a PSK identity formatted from A-KID—key identifier-- and 3GPP-akma hint together with a psk_key_exchange_modes extension indicating, e.g., psk_dhe_ke (Fig. 6, el. 602a; Para. 63);
at operation 703, the UE sends a discovery request message—session establishment request-- to the 5GDDNMF, wherein the discovery request message can include the A-KID as clear text (Fig. 7, el. 703; Para. 79); and
acquiring a first key between the communication device and the UE according to the key identifier, e.g., At operation 602b, the AF server contacts the AAnF with the A-KID (Fig. 6, el. 602b; Para. 64);
at operation 602c, the AAnF looks up the KAKMA key using the A-KID and generates a KAF key from the KAKMA key (Fig. 6, el. 602c; Para. 65);
at operation 602d, the AAnF server responds with the KAF key to the AF (Fig. 6, el. 602d; Para. 66);
the AAnF sends Naanf_AKMA_ApplicationKey_Get response to the AF with KAF (e.g., operation 504 in FIG. 5) (Fig. 5, el. 504; Para. 58);
the AAnF can verify whether the subscriber is authorized to use AKMA based on the presence of the UE specific KAKMA key identified by the A-KID (Para. 81);
at operation 706, the AAnF sends Naanf_AKMA_ApplicationKey_Get response to the AF with KAF (Fig. 7, el. 706; Para. 83).
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-3, 5, 7-10, 12-14, 16-18, and 24 are rejected under 35 U.S.C. 103 as being unpatentable over Peng in view of Lehtovirta et al. (US 2012/0027211 A1) and further in view of Bone (US 2016/0234255 A1).
Regarding claim 1, Peng teaches an authentication and/or key management method, comprising:
receiving, by a first device, e.g., Application Function (AF) 525/635 (Fig. 5, el. 525; Fig. 6, el. 635); 5GDDNMF 715 (Fig. 7, el. 715), a session establishment request message initiated by a user equipment (UE), e.g., User equipment (UE) 510/610/710 (Fig. 5, el. 510; Fig. 6, el. 610; Fig. 7, el. 710) initiating the application session establishment requests 501, wherein the request message carries a key identifier, e.g., When the UE initiates communication with the AKMA AF, it may include the derived A-KID—key identifier-- in the Application Session Establishment request message (e.g., operation 501 in FIG. 5) (Fig. 5, el. 501; Para. 55);
at operation 602a, the UE initiates TLS with Pre-Shared Key (PSK) authentication with the AF server, wherein the UE sends Client Hello—session establishment request-- where the ClientHello contains a pre_shared_key extension including a PSK identity formatted from A-KID—key identifier-- and 3GPP-akma hint together with a psk_key_exchange_modes extension indicating, e.g., psk_dhe_ke (Fig. 6, el. 602a; Para. 63);
at operation 703, the UE sends a discovery request message—session establishment request-- to the 5GDDNMF, wherein the discovery request message can include the A-KID as clear text (Fig. 7, el. 703; Para. 79);
acquiring, by the first device, a first key between the first device and the UE according to the key identifier, e.g., At operation 602b, the AF server contacts the AAnF with the A-KID (Fig. 6, el. 602b; Para. 64);
at operation 602c, the AAnF looks up the KAKMA key using the A-KID and generates a KAF key from the KAKMA key (Fig. 6, el. 602c; Para. 65);
at operation 602d, the AAnF server responds with the KAF key to the AF (Fig. 6, el. 602d; Para. 66);
the AAnF sends Naanf_AKMA_ApplicationKey_Get response to the AF with KAF (e.g., operation 504 in FIG. 5) (Fig. 5, el. 504; Para. 58);
the AAnF can verify whether the subscriber is authorized to use AKMA based on the presence of the UE specific KAKMA key identified by the A-KID (Para. 81);
at operation 706, the AAnF sends Naanf_AKMA_ApplicationKey_Get response to the AF with KAF (Fig. 7, el. 706; Para. 83);
receiving, by the first device, a data which is protected by the UE based on a third key…wherein the third key is generated by the UE and is the same as the first key, e.g., the UE protects the messages to be sent with the key derived, wherein the UE encrypts the messages to be sent with the Kenc and calculates Message Authentication code (MAC) for the messages with the Kint if the Kenc and the Kint are available, and in another example, the UE encrypts the messages to be sent encrypt and calculates the MAC for the messages with the KAF (Peng-Para. 78);
….
Peng does not clearly teach receiving, by the first device, a data which is protected by the UE based on a third key, and sending the data to a second device, wherein the third key is generated by the UE and is the same as the first key;
receiving, by the first device, data sent by the second device, protecting the data based on the first key, and sending the data to the UE;
wherein the first device is configured to be a proxy of a group of application functions (AF)/application servers (AS) or to be a proxy of AF/AS in a same trust domain, and the second device is an AF/AS that trusts the first device.
Lehtovirta teaches wherein the first device is configured to be a proxy of a group of application functions (AF)/application servers (AS) or to be a proxy of AF/AS in a same trust domain, e.g., Authentication Proxy (AP)/ Network Application Function (NAF) 15 (Fig. 8, el. 15), and the second device is an AF/AS, e.g., Application Servers (AS)s 16a and 16b (Fig. 8, el. 16a, 16b), that trusts the first device, e.g., method for obtaining AS-specific keys for an Authentication Proxy (AP) scenario, wherein this embodiment is intended for a general AP-AS scenario in which several ASs 16a and 16b may reside behind an AP 15 (Fig. 8; Para. 104);
at a new step 6b, the AP 15 determines which AS should receive the request, and the AP derives an AP-specific key Ks_AS from the Ks_NAF and a nonce using a key derivation function such as Ks_AS =KDF (Ks_NAF, nonce) (Fig. 8, el. 6b; Para. 106);
at step 7, the AP 15 sends the Ks_AS and the identity of the AS (e.g., FQDN) in an HTTP request to the identified AS 16a (Fig. 8, el. 7; Para. 107);
At step 9b, the UE derives the AS-specific key Ks_AS from the Ks_NAF and the nonce, and at step 10, the AS 16a sends a message protected with Ks_AS to the UE, and the UE 11 is then able to decrypt and verify the message using Ks_AS, and the UE uses the AS identity to identify the correct Ks_AS (Fig. 8, el. 9b, 10; Para. 108).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Peng to include wherein the first device is configured to be a proxy of a group of application functions (AF)/application servers (AS) or to be a proxy of AF/AS in a same trust domain, and the second device is an AF/AS that trusts the first device, using the known system of an AP being an intermediary between the UE and a plurality of ASs, as taught by Lehtovirta, in combination with the secure communication system of Peng, for the purpose of implementing a shared secret which enables new kinds of applications developed for scenarios with an AP and further to provide a more secure system in which the UE shares different keys with each AS (Lehtovirta-Para. 43).
Peng in view of Lehtovirta does not clearly teach receiving, by the first device, a data which is protected by the UE based on a third key, and sending the data to a second device, wherein the third key is generated by the UE and is the same as the first key;
receiving, by the first device, data sent by the second device, protecting the data based on the first key, and sending the data to the UE.
Bone teaches receiving, by the first device, e.g., Network Application Function (NAF) 122 (Fig. 1, el. 122), a data which is protected by the UE based on a third key, and sending the data to the second device, e.g., Device Management (DM) server 120 (Fig. 2, el. 120), wherein the third key is generated by the UE and is the same as the first key; receiving, by the first device, data sent by the second device, protecting the data based on the first key, and sending the data to the UE, e.g., the NAF 122 may act as a proxy in front of the DM server 120. As a proxy, the NAF 122 would terminate the connection from the UE 110 (thus acting as a server to the UE 110) and start a new connection with the DM server 120 (thus acting as a client to the DM server 120) (Para. 408);
the NAF 122 may act as a router, located between the UE 110 and the DM server 120, wherein the NAF 122 may then pass Ua 150 traffic from the UE 110 on to the DM server 120 and pass Ua 150 traffic from the DM server 120 back to the UE 110 (Fig. 1, el. 110, 150; Para. 409);
the NAF 122 can terminate the security established over the Ua 150 interface using the Ks_NAF (or a key(s) derived from the Ks_NAF) and then pass the Ua 150 traffic on to the DM server 120, encrypted in a way that does not necessarily require the DM server 120 to be GBA aware (Para. 410);
the UE 110 derives a secret Ks_NAF (Para. 185);
the BSF 130 authenticates the NAF, derives the corresponding Ks_NAF, and at 270 returns it to the NAF (Fig. 1, el. 130; Para. 187);
securing of communications over the interface between the UE 110 and the NAF 122 (for example Ua 150) is achieved with use of a shared secret (for example, Ks_NAF) and an identifier of the shared secret (for example, P-TID or B-TID), or one or more keys that are derived from the shared secret (such as Ks_NAF) may be used to carry out a symmetric or asymmetric security process in order to secure the interface between the UE 110 and the NAF 122. (Para. 412).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Peng in view of Lehtovirta to include receiving, by the first device, a data which is protected by the UE based on a third key, and sending the data to a second device, wherein the third key is generated by the UE and is the same as the first key; and receiving, by the first device, data sent by the second device, protecting the data based on the first key, and sending the data to the UE, using the known method of using the Ks_NAF to secure the interface between the UE and the NAF and communicating, by the NAF, data from the UE to the server and to the UE from the server, as taught by Bone, in combination with the secure communication system of Peng in view of Lehtovirta, for the purpose of preventing direct communication between the application function/server and the user equipment, thereby increasing the security for both devices while also reducing the processing required by the application function/server.
Regarding claim 2, Peng in view of Lehtovirta in view of Bone teaches the method of claim 1.
Peng does not clearly teach further comprising: generating, by the first device, a second key between the UE and a second device for the second device according to the first key.
Lehtovirta teaches generating, by the first device, e.g., Authentication Proxy (AP)/Network Application Function (NAF) 15 (Fig. 8, el. 15), a second key between the UE and a second device, e.g., Application Server (AS) 16a (Fig. 8, el. 16a), for the second device according to the first key, e.g., the AP derives an AP-specific key Ks_AS from the Ks_NAF and a nonce using a key derivation function such as Ks_AS =KDF (Ks_NAF, nonce) (Para. 106);
at step 9b, the UE derives the AS-specific key Ks_AS from the Ks_NAF and the nonce using a key derivation function such as Ks_AS =KDF (Ks_NAF, nonce), and at step 10, the AS 16a sends a message protected with Ks_AS to the UE (Fig. 8, el. 9b, 10; Para. 108).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Peng to include generating, by the first device, a second key between the UE and a second device for the second device according to the first key, using the known method of deriving, by the AP, an AS key to be used for communications between the AS and the UE, as taught by Lehtovirta, in combination with the secure communication system of Peng, using the same motivation as in claim 1.
Regarding claim 3, Peng in view of Lehtovirta in view of Bone teaches the method according to claim 2, wherein the generating, by the first device, the second key between the UE and the second device for the second device according to the first key comprises: generating, by the first device, the second key based on the first key and identification information of the second device, e.g., the AP derives an AP-specific key Ks_AS from the Ks_NAF and a nonce using a key derivation function such as Ks_AS =KDF (Ks_NAF, nonce), wherein the nonce may be the identity of the AS such as an FQDN (Lehtovirta-Para. 106).
Regarding claim 5, Peng in view of Lehtovirta in view of Bone teaches the method according to claim 1, wherein the acquiring the first key between the first device and the UE according to the key identifier comprises: acquiring, by the first device, a local first key corresponding to the key identifier according to the key identifier; or, acquiring, by the first device, the first key corresponding to the key identifier from an AKMA Anchor Function (AAnF) according to the key identifier, e.g., At operation 602b, the AF server contacts the AAnF with the A-KID (Peng-Fig. 6, el. 602b; Para. 64);
at operation 602c, the AAnF looks up the KAKMA key using the A-KID and generates a KAF key from the KAKMA key (Peng-Fig. 6, el. 602c; Para. 65);
at operation 602d, the AAnF server responds with the KAF key to the AF (Peng-Fig. 6, el. 602d; Para. 66);
the AAnF sends Naanf_AKMA_ApplicationKey_Get response to the AF with KAF (e.g., operation 504 in FIG. 5) (Peng-Fig. 5, el. 504; Para. 58);
the AAnF can verify whether the subscriber is authorized to use AKMA based on the presence of the UE specific KAKMA key identified by the A-KID (Peng-Para. 81);
at operation 706, the AAnF sends Naanf_AKMA_ApplicationKey_Get response to the AF with KAF (Peng-Fig. 7, el. 706; Para. 83).
Regarding claim 7, Peng in view of Lehtovirta in view of Bone teaches the method according to claim 1, further comprising: establishing, by the first device, a transport layer security (TLS) secure channel with the UE, e.g., At operation 602a, the UE initiates TLS with Pre-Shared Key (PSK) authentication with the AF server (Peng-Fig. 6, el. 602a; Para. 63).
Regarding claim 8, Peng in view of Lehtovirta in view of Bone teaches the method according to claim 7.
Peng does not explicitly teach wherein the establishing by the first device the TLS secure channel with the UE comprises: generating, by the first device, a premaster key or an external pre-shared key of the TLS secure channel based on the first key or a key derived from the first key.
Lehtovirta teaches wherein the establishing by the first device the TLS secure channel with the UE comprises: generating, by the first device, a premaster key or an external pre-shared key of the TLS secure channel based on the first key or a key derived from the first key, e.g., the AP derives an AP-specific key Ks_AS from the Ks_NAF and a nonce using a key derivation function such as Ks_AS =KDF (Ks_NAF, nonce), wherein the nonce may be the identity of the AS such as an FQDN (Para. 106);
a TLS tunnel may be set up between the UE 11 and the AP 15 (Fig. 8, el. 11, 15; Para. 104).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Peng to include wherein the establishing by the first device the TLS secure channel with the UE comprises: generating, by the first device, a premaster key or an external pre-shared key of the TLS secure channel based on the first key or a key derived from the first key, using the known method of deriving, by the AP, an AS key to be used for communications between the AS and the UE, as taught by Lehtovirta, in combination with the secure communication system of Peng, using the same motivation as in claim 1.
Regarding claim 9, Peng in view of Lehtovirta in view of Bone teaches the method according to claim 1, further comprising: sending, by the first device, first protected data to the UE, wherein the first protected data comprises data protected by the first device based on the first key or a key derived from the first key, e.g., the 5GDDNMF encrypts the message to be sent and calculates the MAC for the message with the KAF, wherein the 5GDDNMF sends the discovery response to the UE (Peng-Para. 84);
the AF may be the 5GDDNMF (Peng-Para. 60).
Regarding claim 10, Peng in view of Lehtovirta in view of Bone teaches the method according to claim 1, further comprising: receiving, by the first device, data sent by the UE and protected based on a third key or a key derived from the third key, wherein the third key is a key generated by the UE and is the same as the first key, e.g., The UE protects the messages to be sent with the key derived, wherein the UE encrypts the messages to be sent with the Kenc and calculates Message Authentication code (MAC) for the messages with the Kint if the Kenc and the Kint are available, and in another example, the UE encrypts the messages to be sent and calculates the MAC for the messages with the KAF (Peng-Para. 78).
Regarding claim 12, Peng in view of Lehtovirta in view of Bone teaches the method according to claim 1.
Peng does not clearly teach wherein the first device comprises an Authentication and Key Management for Applications (AKMA) application proxy, or an authentication proxy, or an AKMA authentication proxy.
Lehtovirta teaches wherein the first device comprises an Authentication and Key Management for Applications (AKMA) application proxy, or an authentication proxy, or an AKMA authentication proxy, e.g., method for obtaining AS-specific keys for an Authentication Proxy (AP) scenario, wherein this embodiment is intended for a general AP-AS scenario in which several ASs 16a and 16b may reside behind an AP 15 (Fig. 8; Para. 104).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Peng to include wherein the first device comprises an Authentication and Key Management for Applications (AKMA) application proxy, or an authentication proxy, or an AKMA authentication proxy, using the known system of an AP being an intermediary between the UE and a plurality of ASs, as taught by Lehtovirta, in combination with the secure communication system of Peng, using the same motivation as in claim 1.
Regarding claim 13, Peng teaches an authentication and/or key management method, comprising:
sending, by a user equipment (UE), e.g., User equipment (UE) 510/610/710 (Fig. 5, el. 510; Fig. 6, el. 610; Fig. 7, el. 710), a session establishment request message to a first device, e.g., Application Function (AF) 525/635 (Fig. 5, el. 525; Fig. 6, el. 635); 5GDDNMF 715 (Fig. 7, el. 715), wherein the request message carries a key identifier, .g., When the UE initiates communication with the AKMA AF, it may include the derived A-KID—key identifier-- in the Application Session Establishment request message (e.g., operation 501 in FIG. 5) (Fig. 5, el. 501; Para. 55);
at operation 602a, the UE initiates TLS with Pre-Shared Key (PSK) authentication with the AF server, wherein the UE sends Client Hello—session establishment request-- where the ClientHello contains a pre_shared_key extension including a PSK identity formatted from A-KID—key identifier-- and 3GPP-akma hint together with a psk_key_exchange_modes extension indicating, e.g., psk_dhe_ke (Fig. 6, el. 602a; Para. 63);
at operation 703, the UE sends a discovery request message—session establishment request-- to the 5GDDNMF, wherein the discovery request message can include the A-KID as clear text (Fig. 7, el. 703; Para. 79);
receiving, by the UE, a first protected data sent by the first device, wherein the first protected data comprises a data protected by the first device based on a first key or a key derived from the first key, e.g., the 5GDDNMF encrypts the message to be sent and calculates the MAC for the message with the KAF, wherein the 5GDDNMF sends the discovery response to the UE (Para. 84);
at 910, receiving, by a first network function, an encrypted and integrity-protected message from a wireless device, and at 920, decrypting the encrypted and integrity-protected message using a first key that is derived from a second key, wherein the encrypted and integrity-protected message is obtained by encrypting and integrity-protecting a message using the first key, and wherein the second key is established using a communication between the wireless device and a second network function (Fig. 9, el. 910, 920; Para. 90);
the first network function may include 5GDDNMF, the second network function may include AAnF, the first key may include KAF key, and the second key may include KAKMA (Para. 91);
the AF may be the 5GDDNMF (Para. 60);
at operation 603, the UE and the AF server can exchange application data over a secured link (Fig. 6, el. 603; Para. 70),
wherein the first key is acquired by the first device according to the key identifier, e.g., At operation 602b, the AF server contacts the AAnF with the A-KID (Fig. 6, el. 602b; Para. 64);
at operation 602c, the AAnF looks up the KAKMA key using the A-KID and generates a KAF key from the KAKMA key (Fig. 6, el. 602c; Para. 65);
at operation 602d, the AAnF server responds with the KAF key to the AF (Fig. 6, el. 602d; Para. 66);
the AAnF sends Naanf_AKMA_ApplicationKey_Get response to the AF with KAF (e.g., operation 504 in FIG. 5) (Fig. 5, el. 504; Para. 58);
the AAnF can verify whether the subscriber is authorized to use AKMA based on the presence of the UE specific KAKMA key identified by the A-KID (Para. 81);
at operation 706, the AAnF sends Naanf_AKMA_ApplicationKey_Get response to the AF with KAF (Fig. 7, el. 706; Para. 83);
the second key is established using a communication between the wireless device and a second network function (Para. 90).
wherein the method further comprises:
generating, by the UE, a third key that is the same as the first key, and sending, to the first device, a data protected by the third key or a key derived from the third key,…, e.g., the UE protects the messages to be sent with the key derived, wherein the UE encrypts the messages to be sent with the Kenc and calculates Message Authentication code (MAC) for the messages with the Kint if the Kenc and the Kint are available, and in another example, the UE encrypts the messages to be sent encrypt and calculates the MAC for the messages with the KAF (Peng-Para. 78);
….
Peng does not clearly teach generating, by the UE, a third key that is the same as the first key, and sending, to the first device, a data protected by the third key or a key derived from the third key, to enable the first device to send the data to a second device;
receiving, by the UE, a data protected and forwarded by the first device based on the first key, wherein the data is sent by the second device to the first device;
wherein the first device is configured to be a proxy of a group of application functions (AF)/application servers (AS) or to be a proxy of AF/AS in a same trust domain, and the second device is an AF/AS that trusts the first device.
Lehtovirta teaches wherein the first device is configured to be a proxy of a group of application functions (AF)/application servers (AS) or to be a proxy of AF/AS in a same trust domain, e.g., Authentication Proxy (AP)/ Network Application Function (NAF) 15 (Fig. 8, el. 15), and the second device is an AF/AS, e.g., Application Servers (AS)s 16a and 16b (Fig. 8, el. 16a, 16b), that trusts the first device, e.g., method for obtaining AS-specific keys for an Authentication Proxy (AP) scenario, wherein this embodiment is intended for a general AP-AS scenario in which several ASs 16a and 16b may reside behind an AP 15 (Fig. 8; Para. 104);
at a new step 6b, the AP 15 determines which AS should receive the request, and the AP derives an AP-specific key Ks_AS from the Ks_NAF and a nonce using a key derivation function such as Ks_AS =KDF (Ks_NAF, nonce) (Fig. 8, el. 6b; Para. 106);
at step 7, the AP 15 sends the Ks_AS and the identity of the AS (e.g., FQDN) in an HTTP request to the identified AS 16a (Fig. 8, el. 7; Para. 107);
At step 9b, the UE derives the AS-specific key Ks_AS from the Ks_NAF and the nonce, and at step 10, the AS 16a sends a message protected with Ks_AS to the UE, and the UE 11 is then able to decrypt and verify the message using Ks_AS, and the UE uses the AS identity to identify the correct Ks_AS (Fig. 8, el. 9b, 10; Para. 108).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Peng to include wherein the first device is configured to be a proxy of a group of application functions (AF)/application servers (AS) or to be a proxy of AF/AS in a same trust domain, and the second device is an AF/AS that trusts the first device, using the known system of an AP being an intermediary between the UE and a plurality of ASs, as taught by Lehtovirta, in combination with the secure communication system of Peng, for the purpose of implementing a shared secret which enables new kinds of applications developed for scenarios with an AP and further to provide a more secure system in which the UE shares different keys with each AS (Lehtovirta-Para. 43).
Peng in view of Lehtovirta does not clearly teach generating, by the UE, a third key that is the same as the first key, and sending, to the first device, a data protected by the third key or a key derived from the third key, to enable the first device to send the data to a second device; and
receiving, by the UE, a data protected and forwarded by the first device based on the first key, wherein the data is sent by the second device to the first device.
Bone teaches generating, by the UE, e.g., User Equipment (UE) (Fig. 1, el. 110), a third key that is the same as the first key, and sending, to the first device, e.g., Network Application Function (NAF) 122 (Fig. 1, el. 122), a data protected by the third key or a key derived from the third key, to enable the first device to send the data to a second device, e.g., Device Management (DM) server 120 (Fig. 2, el. 120); and receiving, by the UE, a data protected and forwarded by the first device based on the first key, wherein the data is sent by the second device to the first device, e.g., the NAF 122 may act as a proxy in front of the DM server 120. As a proxy, the NAF 122 would terminate the connection from the UE 110 (thus acting as a server to the UE 110) and start a new connection with the DM server 120 (thus acting as a client to the DM server 120) (Para. 408);
the NAF 122 may act as a router, located between the UE 110 and the DM server 120, wherein the NAF 122 may then pass Ua 150 traffic from the UE 110 on to the DM server 120 and pass Ua 150 traffic from the DM server 120 back to the UE 110 (Fig. 1, el. 110, 150; Para. 409);
the NAF 122 can terminate the security established over the Ua 150 interface using the Ks_NAF (or a key(s) derived from the Ks_NAF) and then pass the Ua 150 traffic on to the DM server 120, encrypted in a way that does not necessarily require the DM server 120 to be GBA aware (Para. 410);
the UE 110 derives a secret Ks_NAF (Para. 185);
the BSF 130 authenticates the NAF, derives the corresponding Ks_NAF, and at 270 returns it to the NAF (Fig. 1, el. 130; Para. 187);
securing of communications over the interface between the UE 110 and the NAF 122 (for example Ua 150) is achieved with use of a shared secret (for example, Ks_NAF) and an identifier of the shared secret (for example, P-TID or B-TID), or one or more keys that are derived from the shared secret (such as Ks_NAF) may be used to carry out a symmetric or asymmetric security process in order to secure the interface between the UE 110 and the NAF 122. (Para. 412).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Peng in view of Lehtovirta to include generating, by the UE, a third key that is the same as the first key, and sending, to the first device, a data protected by the third key or a key derived from the third key, to enable the first device to send the data to a second device; and receiving, by the UE, a data protected and forwarded by the first device based on the first key, wherein the data is sent by the second device to the first device, using the known method of using the Ks_NAF to secure the interface between the UE and the NAF and communicating, by the NAF, data from the UE to the server and to the UE from the server, as taught by Bone, in combination with the secure communication system of Peng in view of Lehtovirta, for the purpose of preventing direct communication between the application function/server and the user equipment, thereby increasing the security for both devices while also reducing the processing required by the application function/server.
Regarding claim 14, Peng in view of Lehtovirta in view of Bone teaches the method according to claim 13.
Peng does not clearly teach further comprising: generating, by the UE, a fourth key that is the same as a second key, and receiving a second protected data sent by the second device, wherein the second protected data comprises a data protected by the second device based on the second key, wherein the second key is generated by the first device for the second device based on the first key.
Lehtovirta further teaches generating, by the UE, a fourth key that is the same as a second key, and receiving a second protected data sent by the second device, wherein the second protected data comprises a data protected by the second device based on the second key, wherein the second key is generated by the first device for the second device based on the first key, e.g., at step 9b, the UE derives the AS-specific key Ks_AS from the Ks_NAF and the nonce using a key derivation function such as Ks_AS =KDF (Ks_NAF, nonce), and at step 10, the AS 16a sends a message protected with Ks_AS to the UE, and the UE 11 is then able to decrypt and verify the message using Ks_AS. The UE uses the AS identity to identify the correct Ks_AS (Fig. 8, el. 9b, 10; Para. 108);
the AP derives an AP-specific key Ks_AS from the Ks_NAF and a nonce using a key derivation function such as Ks_AS =KDF (Para. 106).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Peng to include generating, by the UE, a fourth key that is the same as a second key, and receiving a second protected data sent by the second device, wherein the second protected data comprises a data protected by the second device based on the second key, wherein the second key is generated by the first device for the second device based on the first key, using the known method of deriving, by the AP and the UE, an AS key to be used for communications between the AS and the UE, as taught by Lehtovirta, in combination with the secure communication system of Peng, using the same motivation as in claim 13.
Regarding claim 16, Peng in view of Lehtovirta in view of Bone teaches the method according to claim 13, further comprising: establishing, by the UE, a transport layer security (TLS) secure channel with the first device, e.g., At operation 602a, the UE initiates TLS with Pre-Shared Key (PSK) authentication with the AF server (Peng-Fig. 6, el. 602a; Para. 63).
Regarding claim 17, Peng in view of Lehtovirta in view of Bone teaches the method according to claim 16.
Peng further teaches wherein the establishing by the UE the TLS secure channel with the first device comprises: generating, by the UE, a third key that is the same as the first key, e.g., At operation 602f, the UE generates KAF from KAKMA (Fig. 6, el. 602f; Para. 68);
….
Peng does not explicitly teach wherein the establishing by the UE the TLS secure channel with the first device comprises: generating, by the UE, a premaster key or an external pre-shared key of the TLS secure channel based on the third key or a key derived from the third key.
Lehtovirta teaches wherein the establishing by the UE the TLS secure channel with the first device comprises: generating, by the UE, a third key that is the same as the first key, e.g., At step 2, the UE derives NAF-specific key material (Ks_NAF) (Fig. 8, el. 2; Para. 105);
at step 6, the BSF sends the Ks_NAF to the AP (Fig. 8, el. 6; Para. 105);
generating, by the UE, a premaster key or an external pre-shared key of the TLS secure channel based on the third key or a key derived from the third key, e.g., the AP derives an AP-specific key Ks_AS from the Ks_NAF and a nonce using a key derivation function such as Ks_AS =KDF (Ks_NAF, nonce), wherein the nonce may be the identity of the AS such as an FQDN (Para. 106);
a TLS tunnel may be set up between the UE 11 and the AP 15 (Fig. 8, el. 11, 15; Para. 104).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Peng to include wherein the establishing by the UE the TLS secure channel with the first device comprises: generating, by the UE, a premaster key or an external pre-shared key of the TLS secure channel based on the third key or a key derived from the third key, using the known method of deriving, by the AP, an AS key to be used for communications between the AS and the UE, as taught by Lehtovirta, in combination with the secure communication system of Peng, using the same motivation as in claim 13.
Regarding claim 18, Peng in view of Lehtovirta in view of Bone teaches the method according to claim 13.
Peng does not clearly teach wherein the first device comprises an Authentication and Key Management for Applications (AKMA) application proxy, or an authentication proxy, or an AKMA authentication proxy.
Lehtovirta teaches wherein the first device comprises an Authentication and Key Management for Applications (AKMA) application proxy, or an authentication proxy, or an AKMA authentication proxy, e.g., method for obtaining AS-specific keys for an Authentication Proxy (AP) scenario, wherein this embodiment is intended for a general AP-AS scenario in which several ASs 16a and 16b may reside behind an AP 15 (Fig. 8; Para. 104).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Peng to include wherein the first device comprises an Authentication and Key Management for Applications (AKMA) application proxy, or an authentication proxy, or an AKMA authentication proxy, using the known system of an AP being an intermediary between the UE and a plurality of ASs, as taught by Lehtovirta, in combination with the secure communication system of Peng, using the same motivation as in claim 13.
Regarding claim 24, the claim is analyzed with respect to claim 1. Peng in view of Lehtovirta in view of Bone further teaches a communication device, e.g., User equipment (UE) 510/610/710 (Peng-Fig. 5, el. 510; Fig. 6, el. 610; Fig. 7, el. 710),
comprising a memory, e.g., Apparatus 1005 can include one or more memories configured to store information such as data and/or instructions (Peng-Fig. 10, el. 1005; Para. 92),
a processor, e.g., processor electronics 1010 such as a microprocessor that implements one or more of the techniques presented in this document (Peng-Fig. 10, el. 1010; Para. 92), and
a program stored in the memory and executable on the processor; the processor is configured to execute the program to perform the authentication and/or key management method according to claim 13, e.g., Apparatus 1005 can include one or more memories configured to store information such as data and/or instructions, and processor electronics 1010 such as a microprocessor that implements one or more of the techniques presented in this document (Peng-Para. 92).
Claims 6 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Peng in view of Lehtovirta in view of Bone and in view of Romano et al. (US 6,839,757 B1).
Regarding claim 6, Peng in view of Lehtovirta in view of Bone teaches the method according to claim 1.
Peng in view of Lehtovirta in view of Bone does not clearly teach further comprising: providing for the UE, by the first device, a list of second devices that the UE is able to access.
Romano teaches providing for the UE, e.g., client computer 124 (Fig. 1, el. 124), by the first device, e.g., gateway server 110 (Figs. 1, 2, el. 110), a list of second devices that the UE is able to access, e.g., the scanning engine 310 periodically scans the network devices 118 on the inside network 116 to automatically detect accessible network services located on the inside network 116 (Fig. 1, el. 116, 118; Fig. 2, el. 216; Fig. 3, el. 216, 310; Col. 4, lines 4-7);
the inside network devices 118 may include network servers (Col. 3, lines 35-38);
Upon detecting, or discovering, certain available network services on the inside network 116, the scanning engine 310 creates a list of the detected or discovered services, wherein the list of detected or discovered available services is published to the outside network 120 on a gateway server web page (Col. 4, lines 18-25);
a user at an outside network client computer 124 may access detected building network services by browsing to the web page of the gateway server 110 and selecting a dynamic link displayed thereon (Col. 4, lines 55-58).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Peng in view of Lehtovirta in view of Bone to include providing for the UE, by the first device, a list of second devices that the UE is able to access, using the known method of scanning, by the gateway server, for available network servers, creating a list of available network servers, and providing the list to the client computer, as taught by Romano, in combination with the secure communication system of Peng in view of Lehtovirta in view of Bone, for the purpose of providing additional information to the user so that the user may make a more informed decision.
Regarding claim 15, Peng in view of Lehtovirta in view of Bone teaches the method according to claim 13.
Peng in view of Lehtovirta in view of Bone does not clearly teach further comprising: acquiring, by the UE, from the first device, a list of second devices that the UE is able to access.
Romano teaches acquiring, by the UE, e.g., client computer 124 (Fig. 1, el. 124), from the first device, e.g., gateway server 110 (Figs. 1, 2, el. 110), a list of second devices that the UE is able to access, e.g., the scanning engine 310 periodically scans the network devices 118 on the inside network 116 to automatically detect accessible network services located on the inside network 116 (Fig. 1, el. 116, 118; Fig. 2, el. 216; Fig. 3, el. 216, 310; Col. 4, lines 4-7);
the inside network devices 118 may include network servers (Col. 3, lines 35-38);
upon detecting, or discovering, certain available network services on the inside network 116, the scanning engine 310 creates a list of the detected or discovered services, wherein the list of detected or discovered available services is published to the outside network 120 on a gateway server web page (Col. 4, lines 18-25);
a user at an outside network client computer 124 may access detected building network services by browsing to the web page of the gateway server 110 and selecting a dynamic link displayed thereon (Col. 4, lines 55-58).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Peng in view of Lehtovirta in view of Bone to include acquiring, by the UE, from the first device, a list of second devices that the UE is able to access, using the known method of scanning, by the gateway server, for available network servers, creating a list of available network servers, and providing the list to the client computer, as taught by Romano, in combination with the secure communication system of Peng in view of Lehtovirta in view of Bone, for the purpose of providing additional information to the user so that the user may make a more informed decision.
Relevant Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Huang (US 2007/0050623 A1)—Huang discloses When NAF works as an application server proxy to forward a message to other servers, it inserts the subscriber identity into the message that it forwards, so that the receiving application servers are able to identify the subscriber (Para. 46).
Wang et al. (US 11,051,161 B1)—Wang discloses determining whether a first message received from a network node includes an Authentication and Key Management for Applications (AKMA) key indicator and, based on whether the first message includes the AKMA indicator, determining whether to generate AKMA key material for the authentication procedure with the network (Abstract).
Barriga et al. (US 2010/0115598 A1)—Barriga discloses an integrated proxy server (IAP) is inserted in the path between a user and a service provider (SP). The proxy server differentiates type of access and determines corresponding operative state to act as a liberty enabled server or as a GAA/GBA network application function (Abstract).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JEREMY DUFFIELD whose telephone number is (571)270-1643. The examiner can normally be reached Monday - Friday, 7:00 AM - 3:00 PM (ET).
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, Yin-Chen Shaw can be reached at (571) 272-8878. 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.
06 July 2026
/Jeremy S Duffield/Primary Examiner, Art Unit 2498
Prosecution Insights