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 .
The claims 1-20, submitted on 1/27/2025, is acknowledged and considered.
Claims 1, 9, and 17 are independent. Claims 1-20 are pending.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 1/16/2025 was filed after the mailing date of the claims on 1/16/2025. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Allowable Subject Matter
4. Claims 4-5 and 12-13 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
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 (i.e., changing from AIA to pre-AIA ) 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, 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 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.
4. Claim(s) 1-3, 6-11, and 14-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Liu, et al. [US 20180082065] in view of Ballesteros [US 20140331064].
As per claim 1: Liu, et al. teaches a memory sub-system comprising:
a memory device storing a public key of a public/private key pair; [Liu: para 0031, 0041; public key is stored on the secure element of the electronic device (i.e. memory device)]
a persistent storage component storing a first verification key; and [Liu: para 0031; The non-volatile memory (i.e. persistent storage) store a primary entity root public key and/or a secondary entity symmetric key]
a processing device, operatively coupled with the memory device and the persistent storage component, to perform operations comprising: [Liu: para 0029]
receiving, from a host system, a key manifest and a digital signature, the key manifest comprising a second verification key, the digital signature being generated based on the key manifest using a private key corresponding to the public/private key pair; [Liu: para 0038; the manifest data item is generated by the primary entity server. The manifest data item includes a manifest body, a digital signature of the manifest body, and a leaf certificate. Para 0040-0041; The primary entity server sign the manifest body of the manifest data item, e.g., by signing a hash of the manifest body using a private key, to generate the digital signature of the manifest body. The digital signature of the manifest body is added to the manifest data item. The primary entity server sign the manifest body of the manifest data item using the private key for which the corresponding public key is stored on the secure element of the electronic device. The second verification key can broadly be given as a key included with the key manifest, such as a private key or symmetric key]
verifying the digital signature using the public key of the public/private key pair; [Liu: para 0043; a secure element receiving the manifest data item first verifies the digital signature of the primary entity leaf public key using the primary entity root public key, then verifies the digital signature of the manifest body using the primary entity leaf public key, and then individually verify the authentication code using the corresponding symmetric keys, such as the secondary entity symmetric key]
based on verifying the digital signature, [Liu: para 0051] **replacing the first verification key stored in the persistent storage component with the second verification key [**rejected under the secondary reference, discussion below] and discarding the first verification key; and [Liu: para 0051]
utilizing the second verification key in one or more verification operations based on the key manifest being stored in the persistent memory device. [Liu: para 0060; The primary entity server signs the manifest data item using a private key corresponding to the primary entity, such as the primary entity root private key. The primary entity server then transmits the signed manifest data item and the software update to the electronic device. Para 0087; The root public key identifier field is used by the secure element to identify the primary entity root public key stored in the non-volatile memory, such as in implementations where the primary entity has multiple root private keys]
Liu discloses the digital signature of the primary entity leaf public key is included in the leaf certificate where the root primary entity server can reserve the root private key for signing primary entity leaf public keys corresponding to any number of primary entity servers that provide updates to the electronic device without compromising the root private key [Liu: para 0042]. The secure element discards the one or more software updates being provided with the manifest data item. The secure element further discard and/or invalidate the manifest data item [Liu: para 0051]. Thus, Liu suggest signature verification with key updates and “discarding the first verification key”. However, Liu does not clearly discuss “replacing the first verification key stored in the persistent storage component with the second verification key”.
Ballesteros teaches key revocation in system on chip devices are described. In an embodiment, a storage device stores an identifier of an Original Equipment Manufacturer (OEM) and key versioning information corresponding to the OEM. At least a portion of the storage device is updated by a security engine in response to a determination that a first OEM key has been replaced with a second OEM key [Ballesteros: Abstract]. The OEM Key revocation/recovery mechanism includes the SOC security engine tracks the OEM key certificate version in FPF (dynamic fuse set), the SOC security engine updates the FPF dynamic fuse set for OEM key certificate version when it finds a higher/newer OEM key certificate version in the Non-Volatile Storage flash device (which in turn enforces key revocation and prevents OEM key certificate version rollback), and if an OEM needs to revoke any or all previous keys, a new OEM key certificate is requested to be signed by the SOC manufacturer where only the desired keys are included, and the OEM key certificate version is incremented/updated to revoke the previous OEM key certificate(s) (and keys) [Ballesteros: para 0020]. The SPI flash stores an OEM manifest (including signature) that links and selects, and points to OEM key certificate. Also, the certificate version fuse set tracks the OEM key certificate version, which provides a mechanism for key revocation. The OEM ID fuse set binds the OEM manifest and key certificate to the OEM platform. The OEM key certificate includes a header (where the key set version allows for key revocation, as a new version lists the authorized keys only and the Security Engine maintains the version in FPF to prevent rollback, and OEM ID (e.g., in FPF fuses) binds the certificate to a specific OEM platform), one or more OEM public keys, and a signature, which may be invariant and signed by the SOC manufacturer or OEM versioning key and the signing key hash matches the SOC manufacturer's signing key has in standard fuses or OEM key hash in FPF. [Ballesteros: para 0023-0024]. Ballesteros includes key revocation in system on chip devices comprising key versioning information corresponding to the OEM in a storage device and updating a portion of the storage device by a security engine in response to a determination that a first OEM key certificate has been replaced with a second OEM key [Ballesteros: para 0048]. As such, Ballesteros; obviously suggest “replacing the first verification key stored in the persistent storage component with the second verification key”, where one would be motivated to track the key certificate version in order to enforce key revocation and prevents OEM key certificate version rollback such that if an OEM needs to revoke any or all previous keys, a new OEM key certificate is requested to be signed by the SOC manufacturer where only the desired keys are included, and the OEM key certificate version is incremented/updated to revoke the previous OEM key certificate(s) (and keys).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Ballesteros with Liu to teach “replacing the first verification key stored in the persistent storage component with the second verification key” for the reason to track the key certificate version in order to enforce key revocation and prevents key certificate version rollback such that only the desired keys are included and the key certificate version is incremented/updated to revoke the previous key certificates and keys [Ballesteros: para 0020].
Claim 2: Liu: para 0040-0043 discussing the memory sub-system of claim 1, wherein utilizing the second verification key comprises verifying a digital signature of firmware of the memory sub-system using the second verification key.
Claim 3: Liu: para 0049; discussing the memory sub-system of claim 1, wherein the key manifest comprises at least one of: a manifest version, a security version, a product identifier, a product variant, or a key type of the second verification key.
Claim 4: Objected
Claim 5: Objected
Claim 6: Liu: para 0045, 0090; discussing the memory sub-system of claim 1, wherein the memory device comprises an immutable storage device.
Claim 7: Liu: para 0045; discussing the memory sub-system of claim 6, wherein the immutable storage device comprises one of a read only memory (ROM) component, a one-time programmable (OTP) circuit, an e-fuse, or a dedicated hardware component.
Claim 8: Liu: para 0045; discussing the memory sub-system of claim 1, wherein the persistent memory device comprises one of: a negative-and (NAND) type memory device, a negative-or (NOR) memory device, a one-time programmable (OTP) circuit, or an e-fuse.
As per claim 9: Liu, et al. teaches a method comprising:
receiving, at processing device of a memory sub-system [Liu: para 0029], from a host system, a key manifest and a digital signature, the digital signature being generated based on the key manifest using a private key corresponding to a key pair, the key pair comprising the private key and a public key stored in an immutable storage component of the processing device, the key manifest comprising a first verification key; [Liu: para 0038; the manifest data item is generated by the primary entity server. The manifest data item includes a manifest body, a digital signature of the manifest body, and a leaf certificate. Para 0040-0041; The primary entity server sign the manifest body of the manifest data item, e.g., by signing a hash of the manifest body using a private key, to generate the digital signature of the manifest body. The digital signature of the manifest body is added to the manifest data item. The primary entity server sign the manifest body of the manifest data item using the private key for which the corresponding public key is stored on the secure element of the electronic device. The second verification key can broadly be given as a key included with the key manifest, such as a private key or symmetric key]
verifying the digital signature using a public key of the key pair; [Liu: para 0043; a secure element receiving the manifest data item first verifies the digital signature of the primary entity leaf public key using the primary entity root public key, then verifies the digital signature of the manifest body using the primary entity leaf public key, and then individually verify the authentication code using the corresponding symmetric keys, such as the secondary entity symmetric key]
based on verifying the digital signature [Liu: para 0051], **replacing a second verification key stored in a persistent storage component with the first verification key [**rejected under the secondary reference, discussion below] and discarding the second verification key; and [Liu: para 0051]
utilizing the second verification key in one or more verification operations based on the key manifest being stored in the persistent memory device. [Liu: para 0060; The primary entity server signs the manifest data item using a private key corresponding to the primary entity, such as the primary entity root private key. The primary entity server then transmits the signed manifest data item and the software update to the electronic device. Para 0087; The root public key identifier field is used by the secure element to identify the primary entity root public key stored in the non-volatile memory, such as in implementations where the primary entity has multiple root private keys]
Liu discloses the digital signature of the primary entity leaf public key is included in the leaf certificate where the root primary entity server can reserve the root private key for signing primary entity leaf public keys corresponding to any number of primary entity servers that provide updates to the electronic device without compromising the root private key [Liu: para 0042]. The secure element discards the one or more software updates being provided with the manifest data item. The secure element further discard and/or invalidate the manifest data item [Liu: para 0051]. Thus, Liu suggest signature verification with key updates and “discarding the first verification key”. However, Liu does not clearly discuss “replacing a second verification key stored in a persistent storage component with the first verification key and discarding the second verification key”.
Ballesteros teaches key revocation in system on chip devices are described. In an embodiment, a storage device stores an identifier of an Original Equipment Manufacturer (OEM) and key versioning information corresponding to the OEM. At least a portion of the storage device is updated by a security engine in response to a determination that a first OEM key has been replaced with a second OEM key [Ballesteros: Abstract]. The OEM Key revocation/recovery mechanism includes the SOC security engine tracks the OEM key certificate version in FPF (dynamic fuse set), the SOC security engine updates the FPF dynamic fuse set for OEM key certificate version when it finds a higher/newer OEM key certificate version in the Non-Volatile Storage flash device (which in turn enforces key revocation and prevents OEM key certificate version rollback), and if an OEM needs to revoke any or all previous keys, a new OEM key certificate is requested to be signed by the SOC manufacturer where only the desired keys are included, and the OEM key certificate version is incremented/updated to revoke the previous OEM key certificate(s) (and keys) [Ballesteros: para 0020]. The SPI flash stores an OEM manifest (including signature) that links and selects, and points to OEM key certificate. Also, the certificate version fuse set tracks the OEM key certificate version, which provides a mechanism for key revocation. The OEM ID fuse set binds the OEM manifest and key certificate to the OEM platform. The OEM key certificate includes a header (where the key set version allows for key revocation, as a new version lists the authorized keys only and the Security Engine maintains the version in FPF to prevent rollback, and OEM ID binds the certificate to a specific OEM platform), one or more OEM public keys, and a signature, which may be invariant and signed by the SOC manufacturer or OEM versioning key and the signing key hash matches the SOC manufacturer's signing key has in standard fuses or OEM key hash in FPF [Ballesteros: para 0023-0024]. Ballesteros; includes key revocation in system on chip devices comprising key versioning information corresponding to the OEM in a storage device and updating a portion of the storage device by a security engine in response to a determination that a first OEM key certificate has been replaced with a second OEM key [Ballesteros;: para 0048]. As such, Ballesteros obviously suggest “replacing a second verification key stored in a persistent storage component with the first verification key and discarding the second verification key”, where one would be motivated to track the key certificate version in order to enforce key revocation and prevents OEM key certificate version rollback such that if an OEM needs to revoke any or all previous keys, a new OEM key certificate is requested to be signed by the SOC manufacturer where only the desired keys are included, and the OEM key certificate version is incremented/updated to revoke the previous OEM key certificate(s) (and keys).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Ballesteros; with Liu to teach “replacing a second verification key stored in a persistent storage component with the first verification key and discarding the second verification key” for the reason to track the key certificate version in order to enforce key revocation and prevents key certificate version rollback where only the desired keys are included and the key certificate version is incremented/updated to revoke the previous key certificates and keys [Ballesteros: para 0020].
Claim 10: Liu: para 0040-0043; discussing the method of claim 9, wherein utilizing the second verification key comprises verifying a digital signature of firmware of the memory sub-system using the second verification key.
Claim 11: Liu: para 0049; discussing the method of claim 9, wherein the key manifest comprises at least one of: a manifest version, a security version, a product identifier, a product variant, or a key type of the second verification key.
Claim 12: Objected
Claim 13: Objected
Claim 14: Liu: para 0045, 0090; discussing the method of claim 9, wherein the memory device comprises an immutable storage device.
Claim 15: Liu: para 0045; discussing the method of claim 14, wherein the immutable storage device comprises one of a read only memory (ROM) component, a one-time programmable (OTP) circuit, an e-fuse, or a dedicated hardware component.
Claim 16: Liu: para 0045; discussing the method of claim 9, wherein the persistent memory device comprises one of: a negative-and (NAND) type memory device, a negative-or (NOR) memory device, a one-time programmable (OTP) circuit, or an e-fuse.
As per claim 17: Liu, et al. teaches a memory sub-system comprising:
a memory component storing a set of key manifest verification keys; and [Liu: para 0031, 0041; public key is stored on the secure element of the electronic device (i.e. memory component)]
a processing device, operatively coupled with the memory component [Liu: para 0029], to perform operations comprising:
receiving, from a host system, a key manifest and a digital signature, the digital signature being generated based on the key manifest using a private key corresponding to a public/private key pair, the key manifest specifying a first key manifest verification key from the set of key manifest verification keys to be revoked; [Liu: para 0038; the manifest data item is generated by the primary entity server. The manifest data item includes a manifest body, a digital signature of the manifest body, and a leaf certificate. Para 0040-0041; The primary entity server sign the manifest body of the manifest data item, e.g., by signing a hash of the manifest body using a private key, to generate the digital signature of the manifest body. The digital signature of the manifest body is added to the manifest data item. The primary entity server sign the manifest body of the manifest data item using the private key for which the corresponding public key is stored on the secure element of the electronic device. The second verification key can broadly be given as a key included with the key manifest, such as a private key or symmetric key]
verifying the digital signature using a public key of the public/private key pair; and [Liu: para 0043; a secure element receiving the manifest data item first verifies the digital signature of the primary entity leaf public key using the primary entity root public key, then verifies the digital signature of the manifest body using the primary entity leaf public key, and then individually verify the authentication code using the corresponding symmetric keys, such as the secondary entity symmetric key]
based on successful verification of the digital signature, revoking the first key manifest verification key, the revoking of the first key manifest verification key comprises updating a revocation map to indicate that the first key manifest verification key has been revoked [Liu: para 0051; if the digital signature of the manifest body can be verified using the primary entity root public key, the secure element determines whether the manifest properties of the manifest data item can be verified. Para 0060; The primary entity server signs the manifest data item using a private key corresponding to the primary entity, such as the primary entity root private key. The primary entity server then transmits the signed manifest data item and the software update to the electronic device. The secure element discard and/or invalidate the manifest data item], the revocation map comprising a set of flags, the updating of the revocation map comprising setting a flag in the set of flags corresponding to the first key manifest verification key. [**rejected under the secondary reference, discussion below]
Liu discloses the digital signature of the primary entity leaf public key is included in the leaf certificate where the root primary entity server can reserve the root private key for signing primary entity leaf public keys corresponding to any number of primary entity servers that provide updates to the electronic device without compromising the root private key [Liu: para 0042]. The secure element discards the one or more software updates being provided with the manifest data item. The secure element further discard and/or invalidate the manifest data item [Liu: para 0051]. Thus, Liu suggest signature verification with key updates and “discarding the first verification key”. However, Liu does not clearly discuss “the revocation map comprising a set of flags, the updating of the revocation map comprising setting a flag in the set of flags corresponding to the first key manifest verification key”.
Ballesteros teaches key revocation in system on chip devices are described. In an embodiment, a storage device stores an identifier of an Original Equipment Manufacturer (OEM) and key versioning information corresponding to the OEM. At least a portion of the storage device is updated by a security engine in response to a determination that a first OEM key has been replaced with a second OEM key [Ballesteros: Abstract]. The OEM Key revocation/recovery mechanism includes the SOC security engine tracks the OEM key certificate version in FPF (dynamic fuse set), the SOC security engine updates the FPF dynamic fuse set for OEM key certificate version when it finds a higher/newer OEM key certificate version in the Non-Volatile Storage flash device (which in turn enforces key revocation and prevents OEM key certificate version rollback), and if an OEM needs to revoke any or all previous keys, a new OEM key certificate is requested to be signed by the SOC manufacturer where only the desired keys are included, and the OEM key certificate version is incremented/updated to revoke the previous OEM key certificate(s) (and keys) [Ballesteros: para 0020]. The SPI flash stores an OEM manifest (including signature) that links and selects, and points to OEM key certificate. Also, the certificate version fuse set tracks the OEM key certificate version, which provides a mechanism for key revocation. The OEM ID fuse set binds the OEM manifest and key certificate to the OEM platform. The OEM key certificate includes a header (where the key set version allows for key revocation, as a new version lists the authorized keys only and the Security Engine maintains the version in FPF to prevent rollback, and OEM ID (e.g., in FPF fuses) binds the certificate to a specific OEM platform), one or more OEM public keys, and a signature, which may be invariant and signed by the SOC manufacturer or OEM versioning key and the signing key hash matches the SOC manufacturer's signing key has in standard fuses or OEM key hash in FPF [Ballesteros: para 0023-0024]. Ballesteros; includes key revocation in system on chip devices comprising key versioning information corresponding to the OEM in a storage device and updating a portion of the storage device by a security engine in response to a determination that a first OEM key certificate has been replaced with a second OEM key [Ballesteros;: para 0048]. As such, Ballesteros obviously suggest “the revocation map comprising a set of flags, the updating of the revocation map comprising setting a flag in the set of flags corresponding to the first key manifest verification key”, where one would be motivated to track the key certificate version in order to enforce key revocation and prevents OEM key certificate version rollback such that if an OEM needs to revoke any or all previous keys, a new OEM key certificate is requested to be signed by the SOC manufacturer where only the desired keys are included, and the OEM key certificate version is incremented/updated to revoke the previous OEM key certificate(s) (and keys).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Ballesteros; with Liu to teach “the revocation map comprising a set of flags, the updating of the revocation map comprising setting a flag in the set of flags corresponding to the first key manifest verification key”, for the reason to track the key certificate version in order to enforce key revocation and prevents key certificate version rollback where only the desired keys are included and the key certificate version is incremented/updated to revoke the previous key certificates and keys [Ballesteros: para 0020].
Claim 18: Liu: para 0064; discussing the memory sub-system of claim 17, wherein the revocation map indicates a second key manifest verification key is valid.
Claim 19: Liu: para 0034, 0052; discussing the memory sub-system of claim 17, wherein: the memory component comprises at least one of a read only memory (ROM) component, a one-time programmable (OTP) circuit, an e-fuse, or a dedicated hardware component; and the public key comprises a second key manifest verification key from the set of key manifest verification keys.
Claim 20: Liu: para 0051; discussing the memory sub-system of claim 17, wherein the operations comprise accessing the revocation map to determine whether the first key manifest verification key is valid prior to using the first key manifest verification key.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Leynna Truvan whose telephone number is (571)272-3851. The examiner can normally be reached Monday-Friday 9:00AM-5:00PM, EST.
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, Amir Mehrmanesh can be reached at 571-270-3351. 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.
Leynna Truvan
Examiner
Art Unit 2435
/L.TT/Examiner, Art Unit 2435
/EDWARD ZEE/Primary Examiner, Art Unit 2435
Prosecution Insights