DETAILED ACTION
1.
This is in reply to an application filed on 11/21/2024. Claims 1-20 are pending examination.
2.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
3.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 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-6, 8-9, 11-17 and 19-20 are rejected under 35 U.S.C. 103 as unpatentable over Engelkemier et al, US 11,665,001 (hereinafter Engelkemier), and further in view of Wang et al,. US 2025/0365272 (hereinafter Wang).
Regarding claim 1 Engelkemier teaches a method comprising:
obtaining, from a provisioning system, a software image and a digital signature associated with the software image; applying a hash function to the software image (Engelkemier teaches a manufacturer or other trusted entity generates the private/public key pair and uses the private key to digitally sign a software image used during the secure boot of a node (col. 5, lin. 27-37);
verifying, using a first public key of the provisioning system, the digital signature; and responsive to the verification of the digital signature, causing the software image to execute (Engelkemier teaches executing the signed software after verifying the digital signature using the public key (col. 5, lin. 38-50)). Engelkemier does not teach a hash message authentication code (HMAC) is derived from first data provided by a root of trust (RoT). Wang substantially teaches a first expected check value HMAC is generated by processing the first expected attestation information evidence and the first random number nonce by using HMAC algorithm and a key [0275], wherein a trust value data includes may include a random number, a key used for trusted attestation, or expected attestation information of the attested entity [0201], [0272] and [0274].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention was made to modify Engelkemier such that the invention further includes a hash message authentication code (HMAC) is derived from first data provided by a root of trust (RoT). One would have been motivated to do so to enable devices to prove their trustworthiness to other parties.
Regarding claim 2 Engelkemier as modified teaches the method of claim 1, wherein the first data comprises: a first nonce generated by the RoT; and RoT system information (Engelkemier teaches authenticated software image may also include a software component that allows the source node to authenticate itself to an adjacent node with unique identification information such as port, or address (col. 8, lin. 62-col. 9, lin. 1-9), and (col. 5, lin. 3-17), and further Wang teaches a first random number nonce may be a random number that is generated by a third network element and that corresponds to the identification information of the UE, wherein the third network element generates one first random number for each time of trusted attestation of the UE [0274]).
Regarding claim 3 Engelkemier as modified teaches the method of claim 1, further comprising sending the first data to the provisioning system (Engelkemier teaches a plurality of nodes may send information to each other (col. 5, lin. 15-17)).
Regarding claim 4 Engelkemier as modified teaches the method of claim 1, further comprising:
obtaining second data provided by the provisioning system (Engelkemier teaches authenticated software image may also include a software component that allows the source node to authenticate itself to an adjacent node with unique identification information such as port, or address (col. 8, lin. 62-col. 9, lin. 1-9);
generating HMAC key derived from at least a portion of the second data; and
generating, based on the HMAC key and the first data, the HMAC (Wang teaches a first expected check value HMAC′ is generated by processing the first expected attestation information evidence and the first random number nonce by using HMAC algorithm and a key [0275], wherein a trust value data includes may include a random number, a key used for trusted attestation, or expected attestation information of the attested entity [0201], [0272] and [0274].
Regarding claim 5 Engelkemier as modified teaches the method of claim 4, wherein the second data comprises: a second nonce generated by the provisioning system; and
provisioning system information (Wang teaches a first random number nonce may be a random number that is generated by the third network element and that corresponds to the identification information of the UE, wherein the third network element generates one first random number for each time of trusted attestation of the UE [0274]).
Regarding claim 6 Engelkemier as modified teaches the method of claim 4, wherein: the second data comprises a cryptographic key identifier; and generating the HMAC key further comprises: obtaining a cryptographic key indicated by the cryptographic key identifier, and inputting the cryptographic key and the at least a portion of the second data into a key derivation function (Engelkemier teaches a signed software image comprising a public key may be provided to multiple nodes (col. 6, lin. 55-62), and further Wang teaches an expected check value HMAC is generated by processing the first expected attestation information evidence and the first random number nonce by using HMAC algorithm and the symmetric key KRAF [0275]).
In response to Claim 8: Rejected for the same reason as claim 1
Regarding claim 9 Engelkemier as modified teaches the system of claim 8, wherein the software image comprises a software application configured to write an original equipment manufacturer (OEM) identifier to an electronic device (Engelkemier teaches the software components may include identifying information of the node (col. 12, lin. 20-21)).
Regarding claim 11 Engelkemier as modified teaches the system of claim 8, wherein: the software image is encrypted; and the operations further comprise decrypting the encrypted software image (Engelkemier teaches decrypting the digital signature appended to the software image (col. 8, lin. 45-46) and fig. 11).
Regarding claim 12 Engelkemier as modified teaches the system of claim 8, wherein: the first data comprises data identifying a class of computing devices; and a computing device that executes the RoT belongs to the class of computing devices (Engelkemier teaches the software components may include identifying information of the node (col. 12, lin. 20-21), wherein the identifying information of the source node may include any type of uniquely identifying information, such as node, port, or address information (col. 8, lin. 67-col. 9, lin. 1-3) wherein the nodes such as a computing devices for example desktop, laptops, PDAs, smart phones, tablets, ultra books, netbooks and others (col. 2, lin. 41-55) and (col. 21, lin. 36-45).
In response to Claim 13: Rejected for the same reason as claim 2
Regarding claim 14 Engelkemier as modified teaches the system of claim 8, wherein causing the software image to execute comprises executing the software image in the RoT (Engelkemier teaches a node for providing network security using RoT, wherein the node includes a processor, wherein the processor is configured to execute a secure boot process to ensure that only trusted and authenticated software code is loaded and executed by the node during power-up or reset of the node, wherein a private/public key pair is used to verify that the software being loaded by the node is trusted and authenticated software (col. 5, lin. 4-26)).
Regarding claim 15 Engelkemier as modified teaches a method, comprising:
receiving, at a provisioning system first data and RoT system information (Engelkemier teaches a plurality of nodes may send information to each other via internet (i.e. internet protocol allows entities to exchange system information) (col. 5, lin. 15-17), (col. 21, lin. 18-23), wherein one of the nodes is a RoT node (col. 5, lin. 4-26)).
applying a hash function to a software image to generate an image hash (Engelkemier teaches a hashing module generates a hash value based on the encrypted software image, or it generates the hash value based on an unencrypted version of the software image (col. 12, lin. 39-43));
generating a digital signature for the image hash (Engelkemier teaches a manufacturer or other trusted entity generates the private/public key pair and uses the private key to digitally sign a software image used during a secure boot of a node (col. 5, lin. 27-37)); and
sending the software image and the digital signature to the RoT for execution of the software image by the RoT (Engelkemier teaches a manufacturer or other trusted entity generates the private/public key pair and uses the private key to digitally sign a software image used during a secure boot of a node (col. 5, lin. 27-37) and wherein a node for providing network security using RoT, wherein the node utilizes a processor to execute a secure boot process to ensure that only trusted and authenticated software code is loaded and executed by the node during power-up or reset of the node, wherein a private/public key pair is used to verify that the software being loaded by the node is trusted and authenticated software (col. 5, lin. 4-26)). Engelkemier does not teach generating a nonce; and inputting, into a hash message authentication code (HMAC) function, HMAC key and data provided by a RoT to generate HMAC. Wang substantially teaches a network element may process a first expected attestation information evidence and a first random number nonce by using a symmetric key KRAF, to generate a first expected check value HMAC, wherein the key KRAF is derived by the network element based on a root key KTPM [0272] and [0275].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention was made to modify Engelkemier such that the invention further includes generating a nonce; and inputting, into a hash message authentication code (HMAC) function, HMAC key and data provided by a RoT to generate HMAC. One would have been motivated to do so to enable devices to prove their trustworthiness to other parties.
Regarding claim 16 Engelkemier as modified teaches the method of claim 15, further comprising transmitting, to the RoT, second data provided by the provisioning system, wherein the second data comprises a cryptographic key identifier and provisioning system information (Engelkemier teaches a node for providing network security using RoT, wherein the node may send and receive information from other nodes via internet (col. 5, lin. 4-17), (col. 21, lin. 18-23), and wherein a signed software image comprising a public key may be provided to multiple nodes (col. 6, lin. 55-62)).
Regarding claim 17 Engelkemier as modified teaches the method of claim 15, wherein generating the digital signature for the image hash comprises signing the image hash with a private key of the provisioning system (Engelkemier teaches a manufacturer or other trusted entity generates the private/public key pair and uses the private key to digitally sign a software image used during the secure boot of the node (col. 5, lin. 27-37).
Regarding claim 19 Engelkemier as modified teaches the method of claim 15, wherein:
sending the software image and the digital signature to the RoT further comprises sending a footer to the RoT, wherein the footer comprises metadata associated with the software image; and the digital signature comprises a digital signature for the image hash and the footer (Engelkemier teaches A manufacturer or other trusted entity uses the private key to digitally sign a software image used during a secure boot of the computing node. The digitally signed software image may include multiple software components to be executed by the computing node (col. 2, lin. 49-53), wherein the software image components may also include any number of additional keys, which may include additional public keys, private keys, derivative private keys, and the like. The additional keys may be stored in the software image for use authorizing authentication messages (col. 13, lin. 45-50)).
Regarding claim 20 Engelkemier as modified teaches the method of claim 15, wherein the software image comprises a cryptographic key-generating software application (Engelkemier: col. 3, lin. 12-25).
4.
Claim 7 is rejected under 35 U.S.C. 103 as unpatentable over Engelkemier and Wang as mentioned above, and further in view of Kravitz et al,. KR 20210139344 (hereinafter Kravitz).
Regarding claim 7 Engelkemier as modified teaches the method of claim 4, wherein:
the second data comprises a digital certificate that includes a second public key of the provisioning system (Wang teaches an endorser provides an attester endorsement, namely, a root of trust certificate, wherein the root of trust certificate is used to determine that a security chip in a attester is trustworthy, and the certificate includes a public key [0151]); and
generating the HMAC key further comprises (Wang teaches an expected check value HMAC is generated by processing the first expected attestation information evidence and the first random number nonce by using HMAC algorithm and the symmetric key KRAF [0275]). The combination of Engelkemier and Wang does not teach using a public key to compute a shared secret with a system, and inputting the shared secret and a portion of data into a key derivation function. Kravitz substantially teaches Alice and Bob want to establish a shared secret between them. Bob works first, generates a public key, and publishes it. Anytime after this point, Alice uses the results of this process to create a shared secret between the two of them (pg. 20), wherein HMAC key is derived from a shared secret and other data (pg. 22 and 26)).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention was made to modify the combination of Engelkemier and Wang such that the invention further includes using a public key to compute a shared secret with a system, and inputting the shared secret and a portion of data into a key derivation function. One would have been motivated to do so to enhance the key strength and ensure that the derivation key is resistant to attacks.
5.
Claim 10 is rejected under 35 U.S.C. 103 as unpatentable over Engelkemier and Wang as mentioned above, and further in view of Hardy et al,. US 2007/0271461 (hereinafter Hardy).
Regarding claim 10 Engelkemier as modified teaches the system of claim 8. The combination of Engelkemier and Wang does not teach a software application includes debug enablement. Hardy substantially teaches a determination is made as to whether a debug enablement indicator 96 is received at product [0042] and fig. 3.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention was made to modify the combination of Engelkemier and Wang such that the invention further includes a software application includes debug enablement. One would have been motivated to do so to identify a root causing issues and improve the software quality.
6.
Claim 18 is rejected under 35 U.S.C. 103 as unpatentable over Engelkemier and Wang as mentioned above, and further in view of Le Saint et al,. US 2005/0138386 (hereinafter Le).
Regarding claim 18 Engelkemier as modified teaches the method of claim 15, wherein:
the first data further comprises a public key of the RoT; and a private key of a system (Engelkemier teaches manufacturer or other trusted entity generates the private/public key pair and uses the private key to digitally sign a software image used during the secure boot of the node (col. 5, lin. 27-37) and further see Wang: [0151]. The combination of Engelkemier and Wang does not teach generating HMAC key based on a public key. Le substantially teaches a keyed hash message authentication code (HMAC) operation is generated from the generated public key using the proof of token key and sent along with the public key to the registration authority [0016].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention was made to modify the combination of Engelkemier and Wang such that the invention further includes generating a HMAC key based on a public key. One would have been motivated to do so to provides assurances to the registration authority that the PKI key pair was actually generated within the secure domain of the security token rather than elsewhere [0017].
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AYOUB ALATA whose telephone number is (313)446-6541. The examiner can normally be reached on Monday - Friday 7:30 - 5:00 Est.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jung (Jay) Kim can be reached on (571)272-3804. The fax phone number for the organization where this application or proceeding is assigned is (571)273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/AYOUB ALATA/ Primary Examiner, Art Unit 2494