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 .
This is a Non-Final Office Action in response to the communication filed on September 28, 2023.
Claims 1-24 have been examined.
Drawings
The drawings filed on September 28, 2023 are acceptable for examination proceedings.
Priority
Acknowledgment is made of applicant's claim for foreign priority under 35 U.S.C. 119(a)-(d). The certified copy has been filed in parent Application No. 18/3553015, filed on September 28, 2023.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on September 28, 2023, and January 03, 2024 were filed after the mailing date of the application 18/553015 on September 28, 2023. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 101 (CRM Analysis)
Claims 11, and 19 are directed to "computer readable medium" and applicant's specification support for said “computer readable medium” is being limited to a statutory embodiment and not of “computer readable signal medium” (See, Specification Para 0215-0216).
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.
Claims 1-12, and 21-24 are rejected under 35 U.S.C. 103 as being unpatentable over Joshua Jay Norem (U.S. Patent Application Publication No.: US 2020/0159965 A1 / or “Norem” hereinafter [provided by the applicant]) in view of McCauley et al. (U.S. Patent Application Publication No.: US 2018/0145991 A1 / or “McCauley” hereinafter).
Regarding claim 1, Norem discloses “A method for providing firmware to an electronic device” (Para 0006-0009; a system and method of downloading firmware into an embedded device is disclosed),
“the electronic device comprising a security module having a physical unclonable function (PUF)” (Para 0022-0023: PUF can be used to encrypt the secret key),
“the security module configured to establish a firmware key pair (FPK, FSK) based on a first challenge and response to the PUF, the firmware key pair comprising a firmware public key (FPK) and a firmware secret key (FSK), wherein the method comprises” (Para 0022-0023: key pair is created comprising of a private key and a corresponding public key and PUF can be used to create keys that is used in encrypting other keys; and para 0035: the secure enclave generates a pair of public and private key. Also 0031: disclose ''At the time of device manufacture, the embedded device 650 creates a kev in the memory 50 of the embedded device. This is a private kev, referred to as the SE CHIP ID KEYPRIV key 61. This SE_CHIP_ID_KEYPRIV key 61 is disposed in the first portion 51 of the memory 50. The public key may be obtained by querying the device. and specifically, by querying the Secure Enclave 600 . ... the Secure Enclave 600 has the ability to communicate with external components such as via a hardware interface. such as by using the Challenge Interface 640. "in other words physical properties of the chip are used during manufacturing to generate the firmware key. This is a PUF based challenge/response; whether the term "PUF" is explicitly used or not):
“causing a hash of the firmware to be signed using a secret key of an authority key pair to obtain a signature, wherein the authority key pair comprises a public key and the secret key, wherein the public key is embedded securely in the electronic device” (Para 0007-0008, 0038-0039: a certificate is used in checking the checksum i.e., the “hash” for integrity, where the certificate provides the public key need to verify signature generated with the private key);
“encrypting the firmware and the [signature] using a server encryption key” (Para 0006-0007: the firmware is encrypted when it is transferred from the host to the embedded device using a shared/session key );
“encrypting a server decryption key using the FPK, the server decryption key for decrypting the encrypted firmware and the [encrypted signature]” (Para 0008, and 0054: the shared/session key is encrypted public key of the device);
“communicating the encrypted firmware, the [encrypted signature], and the encrypted server decryption key to a third party for installation on the electronic device” (Para 0003, and 0008: loading the firmware to embedded device for installation, whereby a contract manufacturer is entrusted with the programming of the device).
But Norem fails to specially disclose encrypting a signature during transmission by an entity.
However, McCauley discloses encrypting a signature during transmission (McCauley, Para 0051, the encrypted signature is decrypted in order to authentication firmware installation of a vehicle).
It would have been obvious to an ordinary person skilled in the art before the effective filing date of the claimed invention to employ the teachings of encrypting a signature during transmission of McCauley to the system of Norem to validate the firmware update for the vehicle is provided by a trusted entity and the ordinary person skilled in the art would have been motivated to combine to ensure safety and security of the vehicle (McCauley, Para 0052).
Regarding claim 2, in view of claim 1, Norem in view of McCauley disclose “the method further comprising receiving the firmware and performing a hash function on the firmware to generate the hash of the firmware” (McCauley, Fig. 4b: Step 456; and Para 0041: checksum is performed on firmware).
Regarding claim 3, in view of claim 1, Norem in view of McCauley disclose “wherein the method further comprises receiving the hash of the firmware” (McCauley, Fig. 4b: Step 462; and Para 0041: the firmware is transferred).
Regarding claim 4, in view of any preceding claim, Norem in view of McCauley disclose “wherein causing a hash of the firmware to be signed comprises signing the hash of the firmware” (McCauley, Para 0004: the checksum is signed).
Regarding claim 5, in view of any of claims 1-3, Norem in view of McCauley disclose “wherein causing a hash of the firmware to be signed comprises transmitting the hash of the firmware to a trusted authority, and receiving the signature from the trusted authority” (McCauley, Para 0038-0039, receives firmware update from a server).
Regarding claim 6, in view of any preceding claim, Norem in view of McCauley disclose “the method further comprising receiving the FPK from a trusted authority” (McCauley, Para 0038-0039, receives firmware update from a server and the firmware is encrypted).
Regarding claim 7, in view of any preceding claim, Norem discloses “wherein the server encryption key is the same as the server decryption key” (Para 0007: discloses a shared key for encryption and decryption operation).
Regarding claim 8, in view of any preceding claim, Norem discloses “wherein the security module is further configured to establish an enrolment key pair (EPK, ESK) based on a second challenge and response to the PUF, the enrolment key pair comprising an enrolment public key (EPK) and an enrolment secret key (ESK); and wherein the method further comprises communicating a device identifier to the third party, the device identifier comprising a function of the EPK” (Para 0031; and Para 0046: secure Identity is used; and Para 0023).
Regarding claim 9, in view of claim 8, Norem discloses “wherein the device identifier is received from a trusted authority” (Para 0023).
Regarding claim 10, in view of any preceding claim, Norem discloses “the method further comprising: after the firmware has been installed on the electronic device, receiving the device identifier and registering the device identifier with the trusted authority” (Para 0046).
Regarding claim 11, in view of any preceding claim, Norem in view of McCauley disclose “A computer readable medium having instructions stored thereon which, when executed by one or more processors, cause the one or more processors to perform the method of any preceding claim” (see rejection of claim 1).
Regarding claim 12, in view of any of claims 1-10, Norem in view of McCauley disclose “Computing apparatus comprising: one or more processors; and one or more memories having instructions stored thereon which, when executed by the one or more processors, cause the one or more processors to execute a method according to any of claims 1-10” (see rejection of claim 1).
Regarding claim 21, Norem discloses “A method for performance by an electronic device” (Para 0006-0009; a system and method of downloading firmware into an embedded device is disclosed),
“the electronic device comprising a security module having a physical unclonable function (PUF) ” (Para 0022-0023: PUF can be used to encrypt the secret key),
“the security module configured to establish a firmware key pair (FPK, FSK) based on a first challenge and response to the PUF, the firmware key pair comprising a firmware public key (FPK) and a firmware secret key (FSK), wherein the method comprises” (Para 0022-0023: key pair is created comprising of a private key and a corresponding public key and PUF can be used to create keys that is used in encrypting other keys; and para 0035: the secure enclave generates a pair of public and private key. Also 0031: disclose ''At the time of device manufacture, the embedded device 650 creates a kev in the memory 50 of the embedded device. This is a private kev, referred to as the SE CHIP ID KEYPRIV key 61. This SE_CHIP_ID_KEYPRIV key 61 is disposed in the first portion 51 of the memory 50. The public key may be obtained by querying the device. and specifically, by querying the Secure Enclave 600 . ... the Secure Enclave 600 has the ability to communicate with external components such as via a hardware interface. such as by using the Challenge Interface 640. "in other words physical properties of the chip are used during manufacturing to generate the firmware key. This is a PUF based challenge/response; whether the term "PUF" is explicitly used or not):
“using the FSK, decrypting an encrypted server decryption key, wherein the server decryption key is encrypted using the FPK” (Para 0022-0023: key pair is created comprising of a private key and a corresponding public key and PUF can be used to create keys that is used in encrypting other keys; and para 0035: the secure enclave generates a pair of public and private key);
“using the decrypted server decryption key, decrypting firmware and a [signature over a hash of the firmware] ” (Para 0006-0007: the firmware is encrypted when it is transferred from the host to the embedded device using a shared/session key );
“verifying, using a public authority key embedded securely in the electronic device, that the hash of the firmware has been signed by a trusted authority” (Para 0008, and 0054: the shared/session key is encrypted public key of the device);
“and based on the verifying, installing the decrypted firmware on the electronic device” (Para 0003, and 0008: loading the firmware to embedded device for installation, whereby a contract manufacturer is entrusted with the programming of the device).
But Norem fails to specially disclose encrypting a signature during transmission by an entity.
However, McCauley discloses encrypting a signature during transmission (McCauley, Para 0051, the encrypted signature is decrypted in order to authentication firmware installation of a vehicle).
It would have been obvious to an ordinary person skilled in the art before the effective filing date of the claimed invention to employ the teachings of encrypting a signature during transmission of McCauley to the system of Norem to validate the firmware update for the vehicle is provided by a trusted entity and the ordinary person skilled in the art would have been motivated to combine to ensure safety and security of the vehicle (McCauley, Para 0052).
Regarding claim 22, in view of claim 21, Norem in view of McCauley disclose “further comprising, on booting, verifying that the firmware has been signed by a trusted party” (McCauley, Para 0004: the checksum is signed).
Regarding claim 23, claim 23 is directed to a device corresponding to the method recited in claim 21. Claim 23 is similar in scope to claim 21, and is therefore, rejected under similar rationale.
Regarding claim 24, claim 24 is directed to a system corresponding to the method recited in claim 1. Claim 24 is similar in scope to claim 1, and is therefore, rejected under similar rationale.
Claim Rejections - 35 USC § 102
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)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 13-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Norem.
Regarding claim 13, Norem discloses “A method for authenticating firmware for an electronic device” (Para 0006-0009; a system and method of downloading firmware into an embedded device is disclosed),
“the electronic device comprising a security module having a physical unclonable function (PUF) ” (Para 0022-0023: PUF can be used to encrypt the secret key),
“the security module configured to establish a firmware key pair (FPK, FSK) based on a first challenge and response to the PUF and an enrolment key pair (EPK, ESK) based on a second challenge and response to the PUF, wherein the firmware key pair comprises a firmware public key (FPK) and a firmware secret key (FSK), and wherein the enrolment key pair (EPK, ESK) comprises an enrolment public key (EPK) and an enrolment secret key (ESK), the method comprising” (Para 0022-0023: key pair is created comprising of a private key and a corresponding public key and PUF can be used to create keys that is used in encrypting other keys; and para 0035: the secure enclave generates a pair of public and private key. Also 0031: disclose ''At the time of device manufacture, the embedded device 650 creates a kev in the memory 50 of the embedded device. This is a private kev, referred to as the SE CHIP ID KEYPRIV key 61. This SE_CHIP_ID_KEYPRIV key 61 is disposed in the first portion 51 of the memory 50. The public key may be obtained by querying the device. and specifically, by querying the Secure Enclave 600 . ... the Secure Enclave 600 has the ability to communicate with external components such as via a hardware interface. such as by using the Challenge Interface 640. "in other words physical properties of the chip are used during manufacturing to generate the firmware key. This is a PUF based challenge/response; whether the term "PUF" is explicitly used or not):
“receiving, from a server, a hash of firmware over a secure communication channel, the firmware for installation on the electronic device” (Para 0008, and 0054: the shared/session key is encrypted public key of the device);
“signing the hash of the firmware using a secret authority key of an authority key pair comprising a public authority key (PAK) and the secret authority key (SAK), wherein the public authority key is embedded securely in the electronic device” (Para 0007-0008, 0038-0039: a certificate is used in checking the checksum i.e., the “hash” for integrity, where the certificate provides the public key need to verify signature generated with the private key);
“initiating communication of the signature over the hash to a third party for installation on the electronic device” (Para 0003, and 0008: loading the firmware to embedded device for installation, whereby a contract manufacturer is entrusted with the programming of the device).;
“and sending, over a secure communication channel to the server, the FPK and an associated device identifier for identifying the electronic device, the device identifier comprising a function of the EPK” (Para 0031; and Para 0046: secure Identity is used; and Para 0023).
Regarding claim 14, in view of claim 13, Norem discloses “the method further comprising extracting the device identifier from the security module” (Para 0031; and Para 0046: secure Identity is used; and Para 0023)
Regarding claim 15, in view of claim 13 or 14, Norem discloses “the method further comprising extracting the FPK from the security module” (Para 0022-0023: key pair is created comprising of a private key and a corresponding public key and PUF can be used to create keys that is used in encrypting other keys; and para 0035: the secure enclave generates a pair of public and private key. Also 0031: disclose ''At the time of device manufacture, the embedded device 650 creates a kev in the memory 50 of the embedded device. This is a private kev, referred to as the SE CHIP ID KEYPRIV key 61. This SE_CHIP_ID_KEYPRIV key 61 is disposed in the first portion 51 of the memory 50. The public key may be obtained by querying the device. and specifically, by querying the Secure Enclave 600 . ... the Secure Enclave 600 has the ability to communicate with external components such as via a hardware interface. such as by using the Challenge Interface 640).
Regarding claim 16, in view of claim 13 or 14, Norem discloses “the method further comprising receiving the device identifier and the FPK” (Para 0031; and Para 0046: secure Identity is used; and Para 0023).
Regarding claim 17, in view of claim 13 to 16, Norem discloses “the method further comprising receiving a request to register the device identifier with the server” (Para 0031; and Para 0046: secure Identity is used; and Para 0023).
Regarding claim 18, in view of claim 13 to 16, Norem discloses “the method further comprising entering the device identifier and the FPK in a lookup table” (Para 0031; and Para 0046: secure Identity is used to verify which is related to key ID; and Para 0023).
Regarding claim 19, in view of claim 13 to 18, Norem discloses “A computer readable medium having instructions stored thereon which, when executed by one or more processors, cause the one or more processors to perform the method of any of claims 13 to 18” (see rejection of claim 13).
Regarding claim 20, in view of claim 13 to 18, Norem discloses “Computing apparatus comprising: one or more processors; and one or more memories having instructions stored thereon which, when executed by the one or more processors, cause the one or more processors to execute a method according to any of claims 13-18” (see rejection of claim 13).
Relevant Prior Arts
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
David Walter Young (US 20060140399 A1) discloses:
[0021] According to one embodiment, programming data may be transmitted from the source device to the receiving device in order to update software or firmware within device 120. In a further embodiment, the programming data is transmitted with encrypted signature data to ensure that the patch is from a trusted source. As a result, source device 110 includes a signing unit (SU) 107 to generate authenticating signatures, and receiving device includes an authenticated code module (ACM) 109 to authenticate the received signatures.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABDULLAH ALMAMUN whose telephone number is (571) 270-3392. The examiner can normally be reached on 8 AM - 5 PM.
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, Lynn Feild can be reached on (571) 272-2092. 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.
/ABDULLAH ALMAMUN/Examiner, Art Unit 2431
/LYNN D FEILD/Supervisory Patent Examiner, Art Unit 2431