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 . In communications filed on 01/17/2025. Claims 1-20 are pending in this examination.
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 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. This examination is in response to US Patent Application No. 19/031,120.
Drawings
New corrected drawings in compliance with 37 CFR 1.121(d) are required in this application because [the drawing filed on 01/17/2025 does not describe what the item numbers are in the FIG. 2]. Applicant is advised to employ the services of a competent patent draftsperson outside the Office, as the U.S. Patent and Trademark Office no longer prepares new drawings. The corrected drawings are required in reply to the Office action to avoid abandonment of the application. The requirement for corrected drawings will not be held in abeyance.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL. —The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 8-13 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement.
The independent claim 8 recites “receiving, from a second device, a first digital certificate including a second public key generated using a second value from a second PUF circuit as a second seed;”
However, the specification is devoid of any description of this limitation and only in paragraph 38 mentions of [ the computing device 100 can include a physically unclonable function 114] which this PUF could be a component in the first device.
For written description, the specification as filed must describe the claimed invention in sufficient detail so that one of ordinary skill in the art can reasonably conclude that the inventor had possession of the claimed invention. An original claim may lack written description when the claim defines the invention in functional language specifying a desired result, but the specification does not sufficiently identify how the inventor has devised the function to be performed, or result achieved.”
Applicant is kindly requested to show the examiner support in the original disclosure for the new or amended claims. See MPEP 714.02 and 2163.06 (“Applicant should specifically point out the support for any amendments made to the disclosure").
Claims 9-13 do not cure the deficiency of claim 8 and are rejected under 35 USC 112, 1st
paragraph, for their dependency upon claim 8.
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 of this title, 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
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 of this title, 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-2, 4, 7, 14-15, and 17-19 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. 2019/03055973 issued to Dewan in view of US Patent Application No. (10374809) issued to Arjun Dasarakothapalli et al (“Dasarakothapalli”), and further in view of US Patent Application No. (2022/0029790) issued to Peddada et al (“Peddada”) ( filed in IDS 02/10/2025).
Regarding claim 1, Dewan discloses generating, by a client device, a private key using a value from a physically unclonable function (PUF) circuit as a seed [¶23, The present techniques extend the PUF circuit in the device with a PRNG and an asymmetric key generation module. Thus, when a challenger sends the challenge c, the PUF to provides a response r. The response r is provided as a seed value to the PRNG. The PRNG generates a set of random numbers, and the first two prime numbers are used to generate Rivest, Shamir, and Adelman (RSA) keys (K.sub.pub and K.sub.priv). The key derivation block subsequently releases the K.sub.pub to the SoC and the software. The manufacturer of the device takes as input the challenge and public key {c, K.sub.pub} and provides a certificate corresponding to the challenge and public key {c, K.sub.pub}. The certificate attests the authentic identity of the device to any entity, such as an application processor. This can be further extended to attesting the firmware of the device to a remote entity].
Dewan does not explicitly disclose, however, Dasarakothapalli discloses receiving, from a server, a digital certificate including a server public key [ Col. 1 lines 53-67-Col.2 lines 1-9, In a response generated to fulfill the request, the server may identify the location of a digital certificate that is digitally signed by a certificate authority and includes a public cryptographic key of the server… the response may include a digital signature of the server, which may be generated using a private cryptographic key of a cryptographic key pair that includes the public cryptographic key included in the digital certificate], and [ Col. 1 lines 53-67-Col.2 lines 1-9, In a response generated to fulfill the request, the server may identify the location of a digital certificate that is digitally signed by a certificate authority and includes a public cryptographic key of the server… the response may include a digital signature of the server, which may be generated using a private cryptographic key of a cryptographic key pair that includes the public cryptographic key included in the digital certificate]
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Dewan by incorporating “ verification of digital signatures in asynchronous responses”, as taught by Dasarakothapalli . One could have been motivated to ensure that the response originated from a trusted server , and in a response generated to fulfill the request, the server may identify the location of a digital certificate that is digitally signed by a certificate authority and includes a public cryptographic key of the server. [ Dasarakothapalli , Col. 1 lines 53-67-Col.2 lines 1-9].
Dewan, and Dasarakothapalli do not explicitly disclose, however, Peddada discloses :
computing a shared secret using the server public key and the generated private key [¶14, Key agreement protocols may support generation of shared secrets between two parties without interference from a third party. In some cases, each party may generate the shared secret using respective private keys and the public key of the other party. For example, Elliptic Curve Diffie-Hellman (ECDH) protocol is a key agreement protocol that allows two parties to establish a shared secret, and thus derive a symmetric key, over an insecure channel using elliptic curve public/private key pairs], and [¶32, The client 205 may have a data payload (e.g., a secret) that is to be encrypted according to implementations described herein. For initiation of the secrets management, the client 205 may generate a key pair including a client private key and a server public key. Using the client private key and the public key of the secrets management server 210, the client 205 may generate a shared secret. Because the shared secret is generated using the client private key and the server public key, the same shared secret may be subsequently generated by the secrets management server 210 using the client public key and the server private key], and [¶¶38, 58]; and
And encrypting communications with the server using the shared secret.
[ Abstract, a client system may generate a new key pair for a secrets management process. The client may generate a shared secret using the private key of the new key pair and a public key of a secrets management server. Using the shared secret, the client may derive an encryption key and encrypt a data payload for subsequent decryption by the secrets management server].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Dewan, and Dasarakothapalli with the teaching of Peddada in order for provide Elliptic Curve Diffie-Hellman (ECDH) protocol which is a key agreement protocol that allows two parties to establish a shared secret, and thus derive a symmetric key, over an insecure channel using elliptic curve public/private key pairs, by using the shared secret, the client may derive an encryption key and encrypt a data payload for subsequent decryption by the secrets management server[ Peddada, Abstract, ¶14].
Regarding claim 2, Dewan discloses wherein the PUF circuit comprises a static random-access memory (SRAM) PUF [¶25... The attestation engine may include a PUF circuit 202, a PRNG 204, a key generation engine 206, and a signing and verification engine 208. In embodiments, each of the PUF circuit, PRNG 204, key generation engine 206, and signing and verification 208 may be embedded in hardware of component including the attestation engine 104. The PUF circuit generates a unique response r 212 based on a challenge c 210. The present techniques are agnostic to the type of PUF used. In embodiments, the PUF may be an optical PUF, silicon PUF, arbiter PUF, a ring oscillator PUF, and SRAM PUF, the present techniques are also agnostic to the exact circuit parameters that are extracted from the circuit to generate the response r.].
Regarding claim 4, Dewan discloses wherein generating the private key comprises: applying a key derivation function to the value read from the PUF circuit to generate the private key [¶23, The present techniques extend the PUF circuit in the device with a PRNG and an asymmetric key generation module. Thus, when a challenger sends the challenge c, the PUF to provides a response r. The response r is provided as a seed value to the PRNG. The PRNG generates a set of random numbers, and the first two prime numbers are used to generate Rivest, Shamir, and Adelman (RSA) keys (K.sub.pub and K.sub.priv). The key derivation block subsequently releases the K.sub.pub to the SoC and the software. The manufacturer of the device takes as input the challenge and public key {c, K.sub.pub} and provides a certificate corresponding to the challenge and public key {c, K.sub.pub}. The certificate attests the authentic identity of the device to any entity, such as an application processor. This can be further extended to attesting the firmware of the device to a remote entity].
Regarding claim 7, Dewan discloses further comprising: erasing the generated private key after computing the shared secret [ ¶209, The key generation engine then generates a private and public key pair (K.sub.pub and K.sub.priv) from the prime numbers 214. The key pair K.sub.pub and K.sub.priv are subsequently provided to the signing and verification engine 208. The private key K.sub.priv of the key pair 216 never leaves the key generation/signing and verification engine. Since the public key is made available to the world while the private key never leaves the key generation/signature engine, the key generation engine is asymmetric. Additionally, the private key is never stored anywhere and is generated at runtime].
Regarding claim 14, this claim is interpreted and rejected for the same rational set forth in claim 1.
Regarding claim 15, Dewan discloses wherein the physically unclonable function comprises at least one of: a static random-access memory (SRAM) PUF or a delay PUF [¶25... The attestation engine may include a PUF circuit 202, a PRNG 204, a key generation engine 206, and a signing and verification engine 208. In embodiments, each of the PUF circuit, PRNG 204, key generation engine 206, and signing and verification 208 may be embedded in hardware of component including the attestation engine 104. The PUF circuit generates a unique response r 212 based on a challenge c 210. The present techniques are agnostic to the type of PUF used. In embodiments, the PUF may be an optical PUF, silicon PUF, arbiter PUF, a ring oscillator PUF, and SRAM PUF, the present techniques are also agnostic to the exact circuit parameters that are extracted from the circuit to generate the response r.].
Regarding claim 17, Dewan discloses , further comprising: storing the generated key pair in a secure storage device of the computing device [¶16, the device 100 may be an MPU, controller, MCU, DSP, on-chip memory or memory controller, hardware accelerator, EC, on-board GPU, camera controller, TPM( trusted platform module), and the like], and ¶20, The security enabled by a PUF is based on the particular internal gate delays and parameters of the device, which cannot be externally measured], and [¶25, FIG. 2 is an illustration of a system 200 comprising an attestation engine 104. In examples, the attestation engine 104 is as illustrated in FIG. 1. The system 200 may be, for example, embedded in the hardware of a component of a client platform as discussed above. The attestation engine may include a PUF circuit 202, a PRNG 204, a key generation engine 206, and a signing and verification engine 208. In embodiments, each of the PUF circuit, PRNG 204, key generation engine 206, and signing and verification 208 may be embedded in hardware of component including the attestation engine 104. The PUF circuit generates a unique response r 212 based on a challenge c 210. The present techniques are agnostic to the type of PUF used. In embodiments, the PUF may be an optical PUF, silicon PUF, arbiter PUF, a ring oscillator PUF, and SRAM PUF, The present techniques are also agnostic to the exact circuit parameters that are extracted from the circuit to generate the response r.], and [¶26] The PUF is used to generate a security primitive establish an asymmetric authentication scheme].
Regarding claim 18, Dewan discloses wherein the secure storage device comprises a hardware security module (HSM) [¶16, the device 100 may be an MPU, controller, MCU, DSP, on-chip memory or memory controller, hardware accelerator, EC, on-board GPU, camera controller, TPM( trusted platform module), and the like], and ¶20, The security enabled by a PUF is based on the particular internal gate delays and parameters of the device, which cannot be externally measured], and [¶25, FIG. 2 is an illustration of a system 200 comprising an attestation engine 104. In examples, the attestation engine 104 is as illustrated in FIG. 1. The system 200 may be, for example, embedded in the hardware of a component of a client platform as discussed above. The attestation engine may include a PUF circuit 202, a PRNG 204, a key generation engine 206, and a signing and verification engine 208. In embodiments, each of the PUF circuit, PRNG 204, key generation engine 206, and signing and verification 208 may be embedded in hardware of component including the attestation engine 104. The PUF circuit generates a unique response r 212 based on a challenge c 210. The present techniques are agnostic to the type of PUF used. In embodiments, the PUF may be an optical PUF, silicon PUF, arbiter PUF, a ring oscillator PUF, and SRAM PUF, the present techniques are also agnostic to the exact circuit parameters that are extracted from the circuit to generate the response r.], and [¶26, The PUF is used to generate a security primitive establish an asymmetric authentication scheme].
Regarding claim 19, Dewan discloses wherein the secure storage device comprises a general-purpose storage device with a write-protected region [¶13, The challenge-response system may be rooted into an asymmetric or symmetric secret that is provisioned into the device. Alternatively, the secret may be stored in an on-board persistent storage], and [0053] The computing device 600 also includes a storage device 618. The storage device 618 is a physical memory such as a hard drive, an optical drive, a thumb-drive, an array of drives, a solid-state drive, or any combinations thereof. The storage device 618 may also include remote storage drives. The storage device 618 may include an attestation authority 624D to enable asymmetric device attestation using physically unclonable functions for the storage device 618. The attestation authority 624D may be located within a storage controller or a storage engine of the storage device 618. The attestation block 624D may be an attestation engine 104 as described in FIGS. 1-4B].
Claims 3, 5, 8-9, 11-12, 16, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. 2019/03055973 issued to Dewan in view of US Patent Application No. (10374809) issued to Arjun Dasarakothapalli et al (“Dasarakothapalli”), and further in view of US Patent Application No. (2022/0029790) issued to Peddada et al (“Peddada”) ( filed in IDS 02/10/2025), and further in view of (US2020/0015087) issued to PAK ( filed in IDS 02/10/2025).
Regarding claim 3, Dewan discloses generating a public key corresponding to the generated private key; generating a clientkey; and transmitting the client [¶23, The present techniques extend the PUF circuit in the device with a PRNG and an asymmetric key generation module. Thus, when a challenger sends the challenge c, the PUF to provides a response r. The response r is provided as a seed value to the PRNG. The PRNG generates a set of random numbers, and the first two prime numbers are used to generate Rivest, Shamir, and Adelman (RSA) keys (K.sub.pub and K.sub.priv). The key derivation block subsequently releases the K.sub.pub to the SoC and the software. The manufacturer of the device takes as input the challenge and public key {c, K.sub.pub} and provides a certificate corresponding to the challenge and public key {c, K.sub.pub}. The certificate attests the authentic identity of the device to any entity, such as an application processor. This can be further extended to attesting the firmware of the device to a remote entity].
Dewan , Dasarakothapalli , and Peddada do not disclose explicitly disclose client digital certificate , however PAK discloses:
[¶4, The TLS/DTLS protocol requires machines that seek to communicate with each other (e.g. end-point devices and servers) to authenticate each other by exchanging and validating digital certificates in a handshake process.], and [see FIG. 1 and corresponding text for more details, ¶ 10, According to a fifth aspect of the present techniques, there is provided a method of establishing a secure communication session between a client device and a server, the method comprising: transmitting, from the server to the client device, a request from the server for a first digital certificate for authenticating the client device to the server, the first digital certificate comprising a client device identifier, a server identifier and a further identifier identifying a relationship between the client device and the server; transmitting, from the client device to the server, a uniform resource identifier (URI) for the first digital certificate; transmitting, from the client device to the server, a request for a second digital certificate for authenticating the server to the client device, the second digital certificate comprising the server identifier; and transmitting, from the server to the client device, fingerprint data corresponding to the second digital certificate.], and [¶45].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Dewan , Dasarakothapalli , and Peddada with the teaching of PAK in order of establishing a secure communication session between a client device and a server by providing TLS/DTLS protocol which requires machines that seek to communicate with each other (e.g. end-point devices and servers) to authenticate each other by exchanging and validating digital certificates in a handshake process.[ PAK, ¶¶4,6].
Regarding claim 5, Dewan , Dasarakothapalli , and Peddada do not disclose explicitly disclose, however PAK discloses wherein the client device comprises an Internet of Things (IoT) device having limited computational resources [ ¶33, Client device 102 may, in embodiments, be an Internet of Things (IoT) device or a constrained resource device]., and[¶66, As explained earlier, the TLS/DTLS protocols may be used to secure the communication between an IoT device and a remote (e.g. cloud-based) server and/or service. During a TLS/DTLS handshake, the IoT device and the remote server exchange their digital certificates].
Regarding claim 8, Dewan discloses a method for mutual authentication, comprising: reading, by a first device, a first value from a first PUF circuit; generating a first key pair using the first value as a first seed [¶23, The present techniques extend the PUF circuit in the device with a PRNG and an asymmetric key generation module. Thus, when a challenger sends the challenge c, the PUF to provides a response r. The response r is provided as a seed value to the PRNG. The PRNG generates a set of random numbers, and the first two prime numbers are used to generate Rivest, Shamir, and Adelman (RSA) keys (K.sub.pub and K.sub.priv). The key derivation block subsequently releases the K.sub.pub to the SoC and the software. The manufacturer of the device takes as input the challenge and public key {c, K.sub.pub} and provides a certificate corresponding to the challenge and public key {c, K.sub.pub}. The certificate attests the authentic identity of the device to any entity, such as an application processor. This can be further extended to attesting the firmware of the device to a remote entity]; and
generated using a second value from a second PUF circuit as a second seed [¶23, The present techniques extend the PUF circuit in the device with a PRNG and an asymmetric key generation module. Thus, when a challenger sends the challenge c, the PUF to provides a response r. The response r is provided as a seed value to the PRNG. The PRNG generates a set of random numbers, and the first two prime numbers are used to generate Rivest, Shamir, and Adelman (RSA) keys (K.sub.pub and K.sub.priv). The key derivation block subsequently releases the K.sub.pub to the SoC and the software. The manufacturer of the device takes as input the challenge and public key {c, K.sub.pub} and provides a certificate corresponding to the challenge and public key {c, K.sub.pub}. The certificate attests the authentic identity of the device to any entity, such as an application processor. This can be further extended to attesting the firmware of the device to a remote entity].
Dewan does not explicitly disclose, however, Dasarakothapalli discloses receiving, from a second device, a first digital certificate including a second public key [ Col. 1 lines 53-67-Col.2 lines 1-9, In a response generated to fulfill the request, the server may identify the location of a digital certificate that is digitally signed by a certificate authority and includes a public cryptographic key of the server… the response may include a digital signature of the server, which may be generated using a private cryptographic key of a cryptographic key pair that includes the public cryptographic key included in the digital certificate]; and
validating the first digital certificate [Col. 2 lines 47-60, If the digital certificate was issued by the certificate authority to a trusted server, the client may further evaluate the digital certificate to determine whether it is valid. This may include determining whether the digital certificate has expired or is active. Additionally, the client may verify that the digital certificate is authentic by verifying the digital signature of the certificate authority in the digital certificate]; and
and establishing a mutual TLS connection with the second device using the shared secret [Col. 3 lines 19-30, FIG. 1 shows an illustrative example of an environment 100 in which various embodiments can be implemented. In the environment 100, a customer 102 of a computing service may transmit a request to one or more servers 104 to establish a communications channel between a customer's client device and the one or more servers 104. A customer 102, via a client, may submit an application layer (e.g., HyperText Transfer Protocol Secure (HTTPS), file transfer protocol, etc.) request to a destination server 104 (e.g., network server) to establish a secure network communications channel, such as a Transport Layer Security/Secure Sockets Layer (TLS/SSL) secure channel.].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Dewan by incorporating “Transport Layer Security/Secure Sockets Layer (TLS/SSL) secure channel.”, as taught by Dasarakothapalli . One could have been motivated to do so in order to establish a secure network communications channel between customer's client device and the one or more servers [ Dasarakothapalli , Col. 3 lines 19-30].
Dewan, and Dasarakothapalli do not explicitly disclose, however, PAK discloses transmitting, to the second device, a second digital certificate including a first public key from the generated first key pair [¶4, The TLS/DTLS protocol requires machines that seek to communicate with each other (e.g. end-point devices and servers) to authenticate each other by exchanging and validating digital certificates in a handshake process.], and [see FIG. 1 and corresponding text for more details, ¶ 10] According to a fifth aspect of the present techniques, there is provided a method of establishing a secure communication session between a client device and a server, the method comprising: transmitting, from the server to the client device, a request from the server for a first digital certificate for authenticating the client device to the server, the first digital certificate comprising a client device identifier, a server identifier and a further identifier identifying a relationship between the client device and the server; transmitting, from the client device to the server, a uniform resource identifier (URI) for the first digital certificate; transmitting, from the client device to the server, a request for a second digital certificate for authenticating the server to the client device, the second digital certificate comprising the server identifier; and transmitting, from the server to the client device, fingerprint data corresponding to the second digital certificate.]. and [¶45].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Dewan , and Dasarakothapalli with the teaching of PAK in order of establishing a secure communication session between a client device and a server by providing TLS/DTLS protocol which requires machines that seek to communicate with each other (e.g. end-point devices and servers) to authenticate each other by exchanging and validating digital certificates in a handshake process.[ PAK, ¶¶4,6].
Dewan, and Dasarakothapalli, and PAK do not explicitly disclose, however, Peddada
computing a shared secret using the second public key and a first private key from the generated first key pair [ Abstract, a client system may generate a new key pair for a secrets management process. The client may generate a shared secret using the private key of the new key pair and a public key of a secrets management server. Using the shared secret, the client may derive an encryption key and encrypt a data payload for subsequent decryption by the secrets management server], and [¶14, Key agreement protocols may support generation of shared secrets between two parties without interference from a third party. In some cases, each party may generate the shared secret using respective private keys and the public key of the other party. For example, Elliptic Curve Diffie-Hellman (ECDH) protocol is a key agreement protocol that allows two parties to establish a shared secret, and thus derive a symmetric key, over an insecure channel using elliptic curve public/private key pairs], and [¶32, The client 205 may have a data payload (e.g., a secret) that is to be encrypted according to implementations described herein. For initiation of the secrets management, the client 205 may generate a key pair including a client private key and a server public key. Using the client private key and the public key of the secrets management server 210, the client 205 may generate a shared secret. Because the shared secret is generated using the client private key and the server public key, the same shared secret may be subsequently generated by the secrets management server 210 using the client public key and the server private key], and [¶¶38, 58]; and
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Dewan, Dasarakothapalli, and PAK with the teaching of Peddada in order for provide Elliptic Curve Diffie-Hellman (ECDH) protocol which is a key agreement protocol that allows two parties to establish a shared secret, and thus derive a symmetric key, over an insecure channel using elliptic curve public/private key pairs, by using the shared secret, the client may derive an encryption key and encrypt a data payload for subsequent decryption by the secrets management server[ Peddada, Abstract, ¶14].
Regarding claim 9, Dewan discloses wherein the first PUF circuit and the second PUF circuit comprise different types of PUF circuits [¶25... The attestation engine may include a PUF circuit 202, a PRNG 204, a key generation engine 206, and a signing and verification engine 208. In embodiments, each of the PUF circuit, PRNG 204, key generation engine 206, and signing and verification 208 may be embedded in hardware of component including the attestation engine 104. The PUF circuit generates a unique response r 212 based on a challenge c 210. The present techniques are agnostic to the type of PUF used. In embodiments, the PUF may be an optical PUF, silicon PUF, arbiter PUF, a ring oscillator PUF, and SRAM PUF, the present techniques are also agnostic to the exact circuit parameters that are extracted from the circuit to generate the response r.], and [ ¶¶ 29-31, The PRNG 204 generates random numbers that are sent to the key generation engine 206 until at least two prime numbers are obtained. These primes, P0 and P1, may be referred to as co-primes 214. The random numbers generated by the PRNG 204 are based on the input seed value response r 212. The co-primes 214 are identified from the sequence of random numbers sent from the PRNG to the key generation engine 206. The key generation engine 206 discovers co-primes in the sequence of random numbers transmitted from the PRNG 204 and notifies the PRNG 206 to terminate transmission of random numbers. the key pair 216 may be according to the public key encryption algorithm developed by Rivest, Shamir, and Adelman (RSA). The RSA key pair includes two keys, one a public key and the other a private key.... The signing and verification engine 208, signs the blob with the private key and transmits the signed blob to the device. The device transmits the blob signed back to the host application processor. Using the public key, host application processor can verify the signed blob], and [see FIG.2 and corresponding text for more detail].
Regarding claim 11, Dewan discloses further comprising: storing the first public key in a secure storage area of the first device [¶53, The storage device 618 may include an attestation authority 624D to enable asymmetric device attestation using physically unclonable functions for the storage device 618. The attestation authority 624D may be located within a storage controller or a storage engine of the storage device 618], and [ ¶29, Since the public key is made available to the world while the private key never leaves the key generation/signature engine, the key generation engine is asymmetric. Additionally, the private key is never stored anywhere and is generated at runtime], and [¶23, This can be further extended to attesting the firmware of the device to a remote entity. In particular, once the hardware is attested, the ROM in the hardware can measure the firmware that is loaded and send the measurements to the application processor/attestation entity. The manufacturer can now issue a certificate for {c, K.sub.pub} and revoke the certificate if the corresponding K.sub.priv stored at the SoC is compromised].
Regarding claim 12, Dewan, Peddada, and PAK do not explicitly disclose, however Dasarakothapalli discloses wherein establishing the mutual TLS connection comprises: verifying the second device possesses a private key corresponding to the second public key [ Col. 1 lines 53-67-Col.2 lines 1-9, In a response generated to fulfill the request, the server may identify the location of a digital certificate that is digitally signed by a certificate authority and includes a public cryptographic key of the server… the response may include a digital signature of the server, which may be generated using a private cryptographic key of a cryptographic key pair that includes the public cryptographic key included in the digital certificate], and [Col. 3 lines 19-30, (15) FIG. 1 shows an illustrative example of an environment 100 in which various embodiments can be implemented. In the environment 100, a customer 102 of a computing service may transmit a request to one or more servers 104 to establish a communications channel between a customer's client device and the one or more servers 104. A customer 102, via a client, may submit an application layer (e.g., HyperText Transfer Protocol Secure (HTTPS), file transfer protocol, etc.) request to a destination server 104 (e.g., network server) to establish a secure network communications channel, such as a Transport Layer Security/Secure Sockets Layer (TLS/SSL) secure channel.].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Dewan, Peddada, and PAK by incorporating “ verification of digital signatures in asynchronous responses”, as taught by Dasarakothapalli . One could have been motivated to ensure that the response originated from a trusted server , and in a response generated to fulfill the request, the server may identify the location of a digital certificate that is digitally signed by a certificate authority and includes a public cryptographic key of the server. [ Dasarakothapalli , Col. 1 lines 53-67-Col.2 lines 1-9].
Regarding claim 16 Dewan, Dasarakothapalli , and Peddada do not explicitly disclose, however, PAK discloses wherein the computing device comprises a lightweight computing device having minimal storage capacity[¶33, Client device 102 may, in embodiments, be an Internet of Things (IoT) device or a constrained resource device]., and[¶66, As explained earlier, the TLS/DTLS protocols may be used to secure the communication between an IoT device and a remote (e.g. cloud-based) server and/or service. During a TLS/DTLS handshake, the IoT device and the remote server exchange their digital certificates].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Dewan, Dasarakothapalli, and Peddada with the teaching of PAK in order to implement TLS/DTLS protocol secure for the communication between an IoT device and a remote (e.g. cloud-based) server and/or service, and During a TLS/DTLS handshake in order to the IoT device and the remote server exchange their digital certificates [ PAK, ¶66].
Regarding claim 20, Dewan, Dasarakothapalli, and Peddada do not explicitly disclose, however PAK discloses generating a digital certificate for a public key of the generated key pair; and transmitting the generated digital certificate to the server [¶4, The TLS/DTLS protocol requires machines that seek to communicate with each other (e.g. end-point devices and servers) to authenticate each other by exchanging and validating digital certificates in a handshake process.], and [see FIG. 1 and corresponding text for more details, ¶ 10, According to a fifth aspect of the present techniques, there is provided a method of establishing a secure communication session between a client device and a server, the method comprising: transmitting, from the server to the client device, a request from the server for a first digital certificate for authenticating the client device to the server, the first digital certificate comprising a client device identifier, a server identifier and a further identifier identifying a relationship between the client device and the server; transmitting, from the client device to the server, a uniform resource identifier (URI) for the first digital certificate; transmitting, from the client device to the server, a request for a second digital certificate for authenticating the server to the client device, the second digital certificate comprising the server identifier; and transmitting, from the server to the client device, fingerprint data corresponding to the second digital certificate.]. and [¶45].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Dewan , Dasarakothapalli , and Peddada with the teaching of PAK in order of establishing a secure communication session between a client device and a server by providing TLS/DTLS protocol which requires machines that seek to communicate with each other (e.g. end-point devices and servers) to authenticate each other by exchanging and validating digital certificates in a handshake process.[ PAK, ¶¶4,6].
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. 2019/03055973 issued to Dewan in view of US Patent Application No. (10374809) issued to Arjun Dasarakothapalli et al (“Dasarakothapalli”), and further in view of US Patent Application No. (2022/0029790) issued to Peddada et al (“Peddada”) ( filed in IDS 02/10/2025), and further in view of (US2020/0015087) issued to PAK ( filed in IDS 02/10/2025), and further in view of (US2013/0166907) issued to Brown ( filed in IDS 02/10/2025).
Regarding claim 6, Dewan, Dasarakothapalli, Peddada , and PAK do not explicitly disclose, however, Brown discloses wherein validating the digital certificate comprises: verifying a key usage field of the digital certificate indicates the server public key is for key agreement. [¶34, The self-signed root certificate 206 includes an indication that it may be used for verifying digital signatures of process certificates and optionally that it may be used for verifying digital signatures on certificate revocation lists. An X.509 certificate may comprise extension fields indicative of how the certificate is to be used. For example, a certificate may comprise one or more key usage extension fields which define the purpose(s) of the certificate's public key, where each key usage is indicated by a bit. In this case, for the root certificate 206, the first device 200 may assert the "keyCertSign" bit in a key usage extension field 214 to indicate that the public key 204 is permitted to be used for verifying a signature on a public key certificate. Assertion of the "keyCertSign" bit in the key usage extension field 214 will allow the root certificate 206 to be used by the second device 250 to verify a signature on a process certificate received from the first device 200, as will be described below. The first device 200 may also optionally assert the "cRLsign" bit in the key usage extension field 214 to indicate that the public key 204 is permitted to be used for verifying a signature on a certificate revocation list].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Dewan, Dasarakothapalli, Peddada , and PAK with the teaching of Brown in order for creating and using certificates based on capabilities of processes, where a certificate may comprise one or more key usage extension fields which define the purpose(s) of the certificate's public key [ Brown, ¶¶1, 34]
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. 2019/03055973 issued to Dewan in view of US Patent Application No. (10374809) issued to Arjun Dasarakothapalli et al (“Dasarakothapalli”), and further in view of US Patent Application No. (2022/0029790) issued to Peddada et al (“Peddada”) ( filed in IDS 02/10/2025), and further in view of (US2020/0015087) issued to PAK ( filed in IDS 02/10/2025), and further in view of Guccione (US2009/0313472) issued to Guccione.
Regarding claim 10, Dewan discloses further comprising :generating a first random value; transmitting the first random value to the second device; receiving a second random value from the second device [¶23, The present techniques extend the PUF circuit in the device with a PRNG and an asymmetric key generation module. Thus, when a challenger sends the challenge c, the PUF to provides a response r. The response r is provided as a seed value to the PRNG. The PRNG generates a set of random numbers, and the first two prime numbers are used to generate Rivest, Shamir, and Adelman (RSA) keys (K.sub.pub and K.sub.priv). The key derivation block subsequently releases the K.sub.pub to the SoC and the software. The manufacturer of the device takes as input the challenge and public key {c, K.sub.pub} and provides a certificate corresponding to the challenge and public key {c, K.sub.pub}. The certificate attests the authentic identity of the device to any entity, such as an application processor. This can be further extended to attesting the firmware of the device to a remote entity].
Dewan, Dasarakothapalli, Peddada ,and PAK do not explicitly disclose, however, Guccione discloses and deriving a session key from the shared secret using the first random value and the second random value. [ see FIG 5 and corresponding text for more details, [¶25, FIG. 5 is an example of session key generation for securing the interface 130 between the UICC 110 and the Terminal 120. The Terminal 120 identifies a secret that can be used to encrypt communications with the UICC 110, at 510. Similarly, the UICC identifies a secret that can be used to encrypt communications with the Terminal 120, at 515. Optionally, the identified secrets are a pre-provisioned shared secret. A tunnel is established on the interface 130 using the secrets, at 520, such that a channel between the UICC 110 and the Terminal 120 is secured with the respective secrets. The tunnel is used to share data for use in deriving a secure shared session key, at 525.], and [¶¶29-31, FIG. 6 shows an example of an explicit mutual authentication and session key generation method 600. First, the Terminal 120 generates a RAND and a SQN.sub.T, at 610. The Terminal 120 also computes a MAC, an XRES, an AK.sub.T, and a XSQN, at 620. The MAC is computed based on the shared secret K, the RAND, and the SQN.sub.T. The XRES represents an authentication code and is computed using the shared secret K and the RAND. The AK.sub.T is generated using the shared secret K and the RAND. Optionally, the AK.sub.T is the same size as the SQN.sub.T. The XSQN is computed by performing a bitwise exclusive-or (XOR or .sym.) of the SQN and the AK.sub.T. Next, the Terminal 120 sends the MAC, the RAND, and the XSQN to the UICC 110 over the interface 130, at 630. The UICC 110 computes an AK.sub.U, a SQN.sub.U, and an expected MAC (XMAC), at 640. The AK.sub.U is calculated using the shared secret K and the received RAND. The SQN.sub.U is calculated by performing a bitwise exclusive-or of the AK.sub.U and the XSQN. The XMAC is calculated using the shared secret K, the RAND, and the SQN.sub.U. Optionally, the function used to calculate the AK.sub.U at the UICC 110 is identical to the function used to calculate the AK.sub.T at the Terminal 120. Next the UICC 110 compares the XMAC with MAC, at 650. If the XMAC and the MAC are not equal, the authentication process fails and terminates with a fail condition, at 655. Optionally, the authentication process may be restarted after a predetermined interval. Otherwise, the Terminal 120 is authenticated, and the UICC 110 computes a RES using the shared secret K and RAND, at 660. The UICC 110 sends the RES to the Terminal 120, at 670, and derives a shared session key S.sub.U, at 680. For example, the shared session keys are derived using the RAND and the shared secret K.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Dewan, Dasarakothapalli, Peddada , and PAK with the teaching of Brown in order to generate a session key for securing the interface 130 between the UICC 110 and the Terminal 120. The Terminal 120 identifies a secret that can be used to encrypt communications with the UICC 110 [ Guccione, ¶25].
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. 2019/03055973 issued to Dewan in view of US Patent Application No. (10374809) issued to Arjun Dasarakothapalli et al (“Dasarakothapalli”), and further in view of US Patent Application No. (2022/0029790) issued to Peddada et al (“Peddada”) ( filed in IDS 02/10/2025), and further in view of (US2020/0015087) issued to PAK ( filed in IDS 02/10/2025), and further in view of Guccione (US2015/0095648) issued to NIX ( filed in IDS 02/10/2025).
Regarding claim 13, Dewan, Dasarakothapalli, Peddada, and PAK do not explicitly disclose, however, NIX discloses further comprising: receiving periodic heartbeat messages from the second device encrypted using the shared secret[¶8, Since the packets transmitted and received by a wireless module will likely traverse the public Internet for many applications, a need exists in the art to (i) prevent eavesdropping at intermediate points along the path of packets transmitted and received, (ii) allow endpoints to verify the identity of the source of packets received. A need exists in the art for a wireless module and a monitoring server to leverage established public key infrastructure (PKI) techniques and algorithms. A need exists in the art for communication to be secured without requiring the established, but relatively processing, bandwidth, and energy intensive security protocols such as IPSec, TLS, and SSL, since the establishment of theses links requires packet handshakes and/or key exchanges at levels including the network and transport layer of the traditional Open Systems Interconnection (OSI) model. M2M applications frequently require small, periodic messages sent between a wireless module and a monitoring server, where the wireless module sleeps between the messages. M2M applications may leverage wired modules as well which also sleep between messages. During relatively long periods of sleep such as 30 minutes or more, the a wireless or wired network with intermediate firewalls will often tear down the network and/or transport layer connections, which means the wireless module would need to re-negotiate or reestablish the secure tunnels each time the wireless module wakes and seeks to send a relatively small message to a server], and[ ¶88, The CPU wake controller 101u can also include a timer to periodically wake the CPU 101b in order to perform sensor measurements or communicate with a wireless network 102 or server 105.].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Dewan, Dasarakothapalli, Peddada , and PAK with the teaching of NIX in order to CPU wake controller 101u which includea a timer to periodically wake the CPU 101b in order to perform sensor measurements or communicate with a wireless network 102 or server 105 and to re-negotiate or reestablish the secure tunnels each time the wireless module wakes and seeks to send a relatively small message to a server, and the [ NIX, ¶¶8, 88]
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
See 892 for more relevant references
Alder ( US2015/0288667) 0011] The information defining the session key may include a shared secret.
[0012] The shared secret may be randomly generated by the first device.
[0013] The method of sharing a session key according to an exemplary embodiment may
further include deriving, by the first device, the session key from the shared secret, using
a Password Authenticated Key Exchange (PAKE) algorithm.
NIX (US2015/0143125) [0471] A subset of the steps for using conventional technology with a key K in both authentication of a module 101 and deriving session keys for encryption are depicted and described in connection with FIG. 9b, including (i) a step 910 of processing a RES 913 in response to a RAND 912 received by module 101, (ii) a step 911 of deriving a cipher key CK 914 using the RAND 912 and the derived secret shared network key K 129d, and also (iii) deriving additional keys using the RAND 912 and a key K, such as, but not limited to, values for an integrity key (IK), Kasme, Knasenc, Knasint, Kenb, and/or Kupenc. In other words, conventional technology contemplated using a pre-shared secret key K for the various steps listed in the prior sentence, but the present invention contemplates using a mutually derived secret shared network key K 129d in order to perform the same steps (and thus the present invention supports widely deployed wireless networks 102 and also future planned networks that continue to use a key K). In the present invention, a derived secret shared network key K 129d could be used to process or derive additional keys using a RAND 912, such as using a step 911 in FIG. 9b. The derived additional keys could comprise symmetric keys 127 for use with symmetric ciphering algorithms 141b such as, but not limited to, an AES 155 ciphering. A module 101 could also use derived secret shared network key K 129d illustrated in a module key K derivation algorithm 909 with future wireless networks 102 that utilize different symmetric keys 127 than those listed above within this paragraph, where the different symmetric keys 127 are also derived from a shared secret key K
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHAHRIAR ZARRINEH whose telephone number is (571)272-1207. The examiner can normally be reached Monday-Friday, 8:30am-5: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, Jorge Ortiz-Criado can be reached at 571-272-7624. 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.
/SHAHRIAR ZARRINEH/Primary Examiner, Art Unit 2496
Prosecution Insights