DETAILED ACTION
This Office Action, based on application 18/600,853 filed 11 March 2024, is responsive to applicant’s amendment and remarks filed 29 June 2026. Claims 1-8 and 10-21 are currently pending and have been fully considered below.
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 29 July 2026 has been entered.
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 .
Response to Arguments
Applicant’s remarks, submitted 29 June 2026 in response to the Office Action entered 29 April 2026, have been fully considered below.
Claim Interpretation
The Office agrees the term ‘at least one memory’ does not invoke an interpretation under 35 U.S.C 112(f).
Claim Rejections under 35 U.S.C. § 103
Applicant’s arguments with respect to the prior art rejection to the claims in view of the SHINER and SKELTON references have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration and after an updated search, new grounds of rejection are made in view of MARKEY. As such, applicant’s arguments with respect to the claims have been considered but now are moot because the new grounds of rejection do not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 103
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claim(s) 1-8 and 10-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over MARKEY et al (US PGPub 2021/0200874) in further view of SHINER et al (US PGPub 2022/0129390).
With respect to Claim 1, MARKEY discloses a storage device comprising:
a non-volatile memory (NVM) (Fig 1, Memory Device 130; ¶[0011] – “one or more non-volatile memory devices e.g. memory device 130”);
a unique device secret (UDS) data comprising a UDS (¶[0035] – secret key), and pre-installed device secret (PDS) data comprising a PDS (¶[0033] – public/private key), the UDS and the PDS being different and independent (¶[0035] – “Similar to the private key of the asymmetric signing procedure, the secret key of the symmetric cryptographic signature may not be shared with other devices (e.g., is private to the memory sub-system). In this case, the secret key can be used to verify the integrity of the firmware image in the memory device without the use of a public key. The generation of the symmetric cryptographic signature, including the secret key, can occur at a signing manager in the memory device, such as symmetric signing manager 160 as discussed with reference to the memory sub-system in FIG. 1”), and
a processor configured to
receive a first firmware image and a first endorsement generated based on first data including the PDS being a general key and the first firmware image (Fig 2, Step 205 – “Receive Firmware Image Signed with First Signature based on First Signing Procedure”; ¶[0033] – “For example, the new firmware image can be received by the memory sub-system containing an asymmetric cryptographic signature based upon an asymmetric signing procedure. The asymmetric cryptographic signature can be a signature written to a portion of the firmware image and used to verify the firmware image based upon the associated cryptographic algorithm. For example, an asymmetric cryptographic algorithm, such as a Rivest Shamir Adleman (RSA) algorithm, can be used in the generation of the symmetric cryptographic signature. Signing of the asymmetric cryptographic signature can be performed by a signing manager, such as asymmetric signing manager 150 as discussed with reference to the memory sub-system in FIG. 1. In some cases, an asymmetric cryptographic algorithm, such as the RSA cryptographic algorithm, may be associated with two keys, such as a private key and a public key. The private key may be used when generating the asymmetric cryptographic signature that is signed to the firmware image.”);
store the first firmware image in the NVM (¶[0008] – “A memory sub-system can receive a firmware image (e.g., for updating the firmware of the memory sub-system). The firmware image can be downloaded (e.g., from a server), or sent to the memory sub-system from another source such as the manufacturer of the memory sub-system or the firmware manufacturer. If, however, the firmware image is corrupt (e.g., data of the firmware is unreadable or invalid) or hacked by an attacker such that the firmware image contains code different from its source code, the memory sub-system that loads the corrupt or hacked firmware can be subject to inoperability, data loss, or other malicious attacks. In some examples, the firmware image can become corrupt after the firmware image is received and loaded (e.g., stored) at the memory sub-system”; ¶[0012] – “A memory sub-system 110 can be a storage device, a memory module, or a hybrid of a storage device and memory module. Examples of a storage device include a solid-state drive (SSD), a flash drive, a universal serial bus (USB) flash drive, an embedded Multi-Media Controller (eMMC) drive, a Universal Flash Storage (UFS) drive, a secure digital (SD) card, and a hard disk drive (HDD). Examples of memory modules include a dual in-line memory module (DIMM), a small outline DIMM (SO-DIMM), and various types of non-volatile dual in-line memory module (NVDIMM)”);
perform a first integrity check for the first firmware image based on the PDS of the PDS data, the first firmware image stored in the NVM, and the first endorsement (Fig 2, Step 210 – “Verify the Integrity of the Firmware Image based on First Signing Procedure”; ¶[0033] – “The public key can be shared with multiple devices outside the memory sub-system (e.g., public) and used to verify the asymmetric cryptographic signature. ….The public key can then be used to verify the integrity of the firmware image within the memory sub-system based upon the asymmetric cryptographic signature.”; ¶[0034] – “the memory device can verify the firmware image based upon the public key that is associated with the private key that was used by asymmetric signing manager 150 to sign the firmware image”); and
generate a second endorsement (Fig 2, Step 215 – “Generate Second Signature based on Second Signing Procedure”) based on second data including the UDS being a unique key (¶[0035] – “At operation 215, the memory sub-system can generate a second cryptographic signature. The generation of the second signature can occur after the initial verification of the firmware image (e.g., operation 210). Similar to the first cryptographic signature, the second cryptographic signature can be signed (e.g., written to) the firmware image, and used to verify the integrity of the firmware image based upon the second signing procedure. For example, the memory sub-system can generate a symmetric cryptographic signature based upon a symmetric cryptographic algorithm, such as a HMAC algorithm. This symmetric cryptographic signature can include a secret key associated with the symmetric cryptographic algorithm. Similar to the private key of the asymmetric signing procedure, the secret key of the symmetric cryptographic signature may not be shared with other devices (e.g., is private to the memory sub-system). In this case, the secret key can be used to verify the integrity of the firmware image in the memory device without the use of a public key. The generation of the symmetric cryptographic signature, including the secret key, can occur at a signing manager in the memory device, such as symmetric signing manager 160 as discussed with reference to the memory sub-system in FIG. 1”) and the first firmware image stored in the NVM in response to a pass result of the first integrity check (¶[0044] – “In this case, both failures can indicate a corruption of the firmware image, and indicate that the firmware image is unsafe to be used by the memory sub-system the memory sub-system can avoid booting up using the unverified firmware image. In this case, at optional operation 250, the memory sub-system can send an indication of a failure to verify the firmware image. The indication of the failure can be an error status indication, such as an error status code, that is sent from the memory sub-system. The memory sub-system can send the indication to the device that it received the firmware image from during operation 205, or could send the indication to a different device. At operation 255, the new firmware image can be received by the memory sub-system from the device that the memory sub-system sent the indication to in response to the indication. The new firmware image, rather than the initial firmware image, can be used by the memory device and can undergo similar verification procedures (e.g., operations 205-225) as discussed herein. In some cases, the new firmware image can be received after being signed with a new asymmetric cryptographic signature.”), the first data and the second data being different (Fig 2, Step 205 and 215’s signature are generated using different keys).
MARKEY may not explicitly disclose at least one memory configured to store the UDS data and the PDS data.
However, SHINER discloses at least one memory configured to store the UDS data and the PDS data (¶[0088] – “The secure memory device 130 can store a unique device secret 101 for its authentication”; ¶[0130] – “When the memory device 130 is manufactured, one or more relevant cryptographic keys 105 are stored in the memory device 130 to provide the owner privileges to the security server 140”);
MARKEY and SHINER are analogous art because they are from the same field of endeavor of data integrity and security. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of MARKEY and SHINER before him or her, to modify the memory sub-system of MARKEY to include dedicated storage for secret data as taught by SHINER. A motivation for doing so would have been to protect sensitive data with strong security measures to prevent hacking and unauthorized access (¶[0088]). Therefore, it would have been obvious to combine SHINER and SKELTON to obtain the invention as specified in the instant claims.
With respect to Claim 10, MARKEY discloses a method of operating a storage controller connected to a non-volatile memory (NVM) (Fig 1, Memory Device 130; ¶[0011] – “one or more non-volatile memory devices e.g. memory device 130”), the method comprising:
receiving a first firmware image and a first endorsement generated based on first data including a pre-installed device secret (PDS) being a universal key (¶[0033] – public/private key) and the first firmware image (Fig 2, Step 205 – “Receive Firmware Image Signed with First Signature based on First Signing Procedure”; ¶[0033] – “For example, the new firmware image can be received by the memory sub-system containing an asymmetric cryptographic signature based upon an asymmetric signing procedure. The asymmetric cryptographic signature can be a signature written to a portion of the firmware image and used to verify the firmware image based upon the associated cryptographic algorithm. For example, an asymmetric cryptographic algorithm, such as a Rivest Shamir Adleman (RSA) algorithm, can be used in the generation of the symmetric cryptographic signature. Signing of the asymmetric cryptographic signature can be performed by a signing manager, such as asymmetric signing manager 150 as discussed with reference to the memory sub-system in FIG. 1. In some cases, an asymmetric cryptographic algorithm, such as the RSA cryptographic algorithm, may be associated with two keys, such as a private key and a public key. The private key may be used when generating the asymmetric cryptographic signature that is signed to the firmware image.”);
store the first firmware image in the NVM (¶[0008] – “A memory sub-system can receive a firmware image (e.g., for updating the firmware of the memory sub-system). The firmware image can be downloaded (e.g., from a server), or sent to the memory sub-system from another source such as the manufacturer of the memory sub-system or the firmware manufacturer. If, however, the firmware image is corrupt (e.g., data of the firmware is unreadable or invalid) or hacked by an attacker such that the firmware image contains code different from its source code, the memory sub-system that loads the corrupt or hacked firmware can be subject to inoperability, data loss, or other malicious attacks. In some examples, the firmware image can become corrupt after the firmware image is received and loaded (e.g., stored) at the memory sub-system”; ¶[0012] – “A memory sub-system 110 can be a storage device, a memory module, or a hybrid of a storage device and memory module. Examples of a storage device include a solid-state drive (SSD), a flash drive, a universal serial bus (USB) flash drive, an embedded Multi-Media Controller (eMMC) drive, a Universal Flash Storage (UFS) drive, a secure digital (SD) card, and a hard disk drive (HDD). Examples of memory modules include a dual in-line memory module (DIMM), a small outline DIMM (SO-DIMM), and various types of non-volatile dual in-line memory module (NVDIMM)”);
performing a first integrity check for the first firmware image based on the PDS of PDS data (¶[0033] – public/private key), the first firmware image stored in the NVM, and the first endorsement and receiving a pass result (Fig 2, Step 210 – “Verify the Integrity of the Firmware Image based on First Signing Procedure”; ¶[0033] – “The public key can be shared with multiple devices outside the memory sub-system (e.g., public) and used to verify the asymmetric cryptographic signature. ….The public key can then be used to verify the integrity of the firmware image within the memory sub-system based upon the asymmetric cryptographic signature.”; ¶[0034] – “the memory device can verify the firmware image based upon the public key that is associated with the private key that was used by asymmetric signing manager 150 to sign the firmware image”).
in response to the pass result of the first integrity check, generating a second endorsement (Fig 2, Step 215 – “Generate Second Signature based on Second Signing Procedure”) based on second data including a unique device secret (UDS) being a unique key of UDS data (¶[0035] – secret key) and the first firmware image stored in the NVM (¶[0035] – “At operation 215, the memory sub-system can generate a second cryptographic signature. The generation of the second signature can occur after the initial verification of the firmware image (e.g., operation 210). Similar to the first cryptographic signature, the second cryptographic signature can be signed (e.g., written to) the firmware image, and used to verify the integrity of the firmware image based upon the second signing procedure. For example, the memory sub-system can generate a symmetric cryptographic signature based upon a symmetric cryptographic algorithm, such as a HMAC algorithm. This symmetric cryptographic signature can include a secret key associated with the symmetric cryptographic algorithm. Similar to the private key of the asymmetric signing procedure, the secret key of the symmetric cryptographic signature may not be shared with other devices (e.g., is private to the memory sub-system). In this case, the secret key can be used to verify the integrity of the firmware image in the memory device without the use of a public key. The generation of the symmetric cryptographic signature, including the secret key, can occur at a signing manager in the memory device, such as symmetric signing manager 160 as discussed with reference to the memory sub-system in FIG. 1”), the first data and the second data being different (Fig 2, Step 205 and 215’s signature are generated using different keys), the UDS and the PDS being different and independent (¶[0035] – “Similar to the private key of the asymmetric signing procedure, the secret key of the symmetric cryptographic signature may not be shared with other devices (e.g., is private to the memory sub-system). In this case, the secret key can be used to verify the integrity of the firmware image in the memory device without the use of a public key. The generation of the symmetric cryptographic signature, including the secret key, can occur at a signing manager in the memory device, such as symmetric signing manager 160 as discussed with reference to the memory sub-system in FIG. 1”).
MARKEY may not explicitly disclose at least one memory configured to store the UDS data and the PDS data (or ‘pre-stored’ data).
However, SHINER discloses at least one memory configured to store the UDS data and the PDS data (¶[0088] – “The secure memory device 130 can store a unique device secret 101 for its authentication”; ¶[0130] – “When the memory device 130 is manufactured, one or more relevant cryptographic keys 105 are stored in the memory device 130 to provide the owner privileges to the security server 140”);
MARKEY and SHINER are analogous art because they are from the same field of endeavor of data integrity and security. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of MARKEY and SHINER before him or her, to modify the memory sub-system of MARKEY to include dedicated storage for secret data as taught by SHINER. A motivation for doing so would have been to protect sensitive data with strong security measures to prevent hacking and unauthorized access (¶[0088]). Therefore, it would have been obvious to combine SHINER and SKELTON to obtain the invention as specified in the instant claims.
With respect to Claim 17, MARKEY discloses a universal flash storage (UFS) system comprising:
a UFS host configured to generate a first endorsement based on first data including a pre-installed device secret (PDS) being a universal key and a first firmware image and transmit the first endorsement and the first firmware image (¶[0047] – “System 300 includes an asymmetric signing manager 315. Asymmetric signing manager 315 can be an example of the asymmetric signing manager 150, as described with reference to FIG. 1. In some cases, asymmetric signing manager 315 can receive a firmware image from a source outside of system 300. The outside source can be a host system, such as host system 105 as described with reference to FIG. 1. The received firmware image can be signed by the asymmetric signing manager 315. In some cases, asymmetric signing manager 315 can be in a secure environment 310. For example, the asymmetric signing manager 315 can be part of a hardware signing machine (HSM) which is located in a secure facility. Secure environment 310 can be a location where system 300 undergoes initial fabrication, or can be a secure location where a secure firmware image is received. Secure environment 310 can be used to ensure that the firmware image signed by asymmetric signing manager 315 is a valid firmware image which has not been corrupted or tampered with by outside sources. Secure environment 310 can therefore ensure that the asymmetric signature signed to the firmware is a valid cryptographic signature”); and
a UFS device configured to update firmware based on the first endorsement and the first firmware image (Fig 2, Step 205 – “Receive Firmware Image Signed with First Signature based on First Signing Procedure”; ¶[0033] – “For example, the new firmware image can be received by the memory sub-system containing an asymmetric cryptographic signature based upon an asymmetric signing procedure. The asymmetric cryptographic signature can be a signature written to a portion of the firmware image and used to verify the firmware image based upon the associated cryptographic algorithm. For example, an asymmetric cryptographic algorithm, such as a Rivest Shamir Adleman (RSA) algorithm, can be used in the generation of the symmetric cryptographic signature. Signing of the asymmetric cryptographic signature can be performed by a signing manager, such as asymmetric signing manager 150 as discussed with reference to the memory sub-system in FIG. 1. In some cases, an asymmetric cryptographic algorithm, such as the RSA cryptographic algorithm, may be associated with two keys, such as a private key and a public key. The private key may be used when generating the asymmetric cryptographic signature that is signed to the firmware image.”), the UFS device comprising
a non-volatile memory (NVM) (Fig 1, Memory Device 130; ¶[0011] – “one or more non-volatile memory devices e.g. memory device 130”);
a unique device secret (UDS) data comprising a UDS being a unique key (¶[0035] – secret key) and PDS data including the PDS, the UDS and the PDS being different and independent (¶[0035] – “Similar to the private key of the asymmetric signing procedure, the secret key of the symmetric cryptographic signature may not be shared with other devices (e.g., is private to the memory sub-system). In this case, the secret key can be used to verify the integrity of the firmware image in the memory device without the use of a public key. The generation of the symmetric cryptographic signature, including the secret key, can occur at a signing manager in the memory device, such as symmetric signing manager 160 as discussed with reference to the memory sub-system in FIG. 1”);
a processor configured to store the first firmware image in the NVM (¶[0008] – “A memory sub-system can receive a firmware image (e.g., for updating the firmware of the memory sub-system). The firmware image can be downloaded (e.g., from a server), or sent to the memory sub-system from another source such as the manufacturer of the memory sub-system or the firmware manufacturer. If, however, the firmware image is corrupt (e.g., data of the firmware is unreadable or invalid) or hacked by an attacker such that the firmware image contains code different from its source code, the memory sub-system that loads the corrupt or hacked firmware can be subject to inoperability, data loss, or other malicious attacks. In some examples, the firmware image can become corrupt after the firmware image is received and loaded (e.g., stored) at the memory sub-system”; ¶[0012] – “A memory sub-system 110 can be a storage device, a memory module, or a hybrid of a storage device and memory module. Examples of a storage device include a solid-state drive (SSD), a flash drive, a universal serial bus (USB) flash drive, an embedded Multi-Media Controller (eMMC) drive, a Universal Flash Storage (UFS) drive, a secure digital (SD) card, and a hard disk drive (HDD). Examples of memory modules include a dual in-line memory module (DIMM), a small outline DIMM (SO-DIMM), and various types of non-volatile dual in-line memory module (NVDIMM)”), perform a first integrity check for the first firmware image stored in the NVM based on the PDS of the PDS data, the first firmware image stored in the NVM, and the first endorsement (Fig 2, Step 210 – “Verify the Integrity of the Firmware Image based on First Signing Procedure”; ¶[0033] – “The public key can be shared with multiple devices outside the memory sub-system (e.g., public) and used to verify the asymmetric cryptographic signature. ….The public key can then be used to verify the integrity of the firmware image within the memory sub-system based upon the asymmetric cryptographic signature.”; ¶[0034] – “the memory device can verify the firmware image based upon the public key that is associated with the private key that was used by asymmetric signing manager 150 to sign the firmware image”); and in response to a pass result of the first integrity check, generate a second endorsement (Fig 2, Step 215 – “Generate Second Signature based on Second Signing Procedure”) based on second data including the UDS (¶[0035] – “At operation 215, the memory sub-system can generate a second cryptographic signature. The generation of the second signature can occur after the initial verification of the firmware image (e.g., operation 210). Similar to the first cryptographic signature, the second cryptographic signature can be signed (e.g., written to) the firmware image, and used to verify the integrity of the firmware image based upon the second signing procedure. For example, the memory sub-system can generate a symmetric cryptographic signature based upon a symmetric cryptographic algorithm, such as a HMAC algorithm. This symmetric cryptographic signature can include a secret key associated with the symmetric cryptographic algorithm. Similar to the private key of the asymmetric signing procedure, the secret key of the symmetric cryptographic signature may not be shared with other devices (e.g., is private to the memory sub-system). In this case, the secret key can be used to verify the integrity of the firmware image in the memory device without the use of a public key. The generation of the symmetric cryptographic signature, including the secret key, can occur at a signing manager in the memory device, such as symmetric signing manager 160 as discussed with reference to the memory sub-system in FIG. 1”), the first data and the second data being different (Fig 2, Step 205 and 215’s signature are generated using different keys), and store the second endorsement in the NVM (Fig 2, Step 220 – Write Second Signature to Firmware Image).
MARKEY may not explicitly disclose at least one memory configured to store the UDS data and the PDS data.
However, SHINER discloses at least one memory configured to store the UDS data and the PDS data (¶[0088] – “The secure memory device 130 can store a unique device secret 101 for its authentication”; ¶[0130] – “When the memory device 130 is manufactured, one or more relevant cryptographic keys 105 are stored in the memory device 130 to provide the owner privileges to the security server 140”);
MARKEY and SHINER are analogous art because they are from the same field of endeavor of data integrity and security. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of MARKEY and SHINER before him or her, to modify the memory sub-system of MARKEY to include dedicated storage for secret data as taught by SHINER. A motivation for doing so would have been to protect sensitive data with strong security measures to prevent hacking and unauthorized access (¶[0088]). Therefore, it would have been obvious to combine SHINER and SKELTON to obtain the invention as specified in the instant claims.
With respect to Claim 2, the combination of MARKEY and SHINER disclose the storage device of claim 1.
MARKEY further discloses wherein the NVM is configured to store a second firmware image (Fig 2, Step 255 – “Receive Second Firmware Image Signed with Third Signature”), wherein the processor is configured to output a UDS-based endorsement, a write command instructing to store the first endorsement and the first firmware image, and an address to the NVM, before the first integrity check is performed (¶[0044] – “The new firmware image, rather than the initial firmware image, can be used by the memory device and can undergo similar verification procedures (e.g., operations 205-225) as discussed herein.”)
With respect to Claim 3, the combination of MARKEY and SHINER disclose the storage device of claim 2.
MARKEY further discloses wherein, based on the storage device being re-booted, the processor is configured to load the first endorsement and the first firmware image stored in the NVM, and perform a second integrity check for the first firmware image based on the UDS, the first firmware image, and the UDS-based endorsement (¶[0031] – “Upon boot-up of memory sub-system 110, verification manager 160 can again verify the firmware image. However, rather than verifying the firmware image based upon the asymmetric cryptographic signature upon boot-up, verification manager 160 can use a verification procedure involving the second (e.g., symmetric) cryptographic signature and/or the asymmetric cryptographic signature.”)
With respect to Claim 4, the combination of MARKEY and SHINER disclose the storage device of claim 3.
MARKEY further discloses wherein the processor is configured to generates a measurement from the UDS and the first firmware image based on a message authentication code (MAC)-based crypto algorithm, and perform the second integrity check based on determining whether the measurement and the UDS-based endorsement are identical to each other (¶[0031] – “For example, the symmetric cryptographic signature may be generated and verified based on a symmetric cryptographic algorithm (e.g., an HMAC algorithm)”; ¶[0028] – “The symmetric cryptographic signature can be based upon a second cryptographic algorithm, such as a hash-based message authentication code (HMAC) algorithm.”).
With respect to Claim 5, the combination of MARKEY and SHINER disclose the storage device of claim 3.
MARKEY further discloses wherein the UDS-based endorsement comprises an invalid value, and the processor is configured to perform the first integrity check in response to a failure result of the second integrity check (Fig 2 illustrates Step 240 – “Verify Firmware Image based on First Signing Procedure” happens in response to Step 230 – “Verify Firmware Image based on Second Signing Procedure” => NO).
With respect to Claim 6, the combination of MARKEY and SHINER disclose the storage device of claim 1.
MARKEY further discloses wherein the processor is configured to generate a measurement from the PDS and the first firmware image of the PDS data based on a message authentication code (MAC)-based crypto algorithm, and perform the first integrity check based on determining whether the measurement and the first endorsement are identical to each other (¶[0015] – “The firmware image can be received by asymmetric signing manager 150, and asymmetric signing manager 150 can sign (e.g., write) a cryptographic signature, such as an asymmetric cryptographic signature to the firmware image. The signing of the firmware image with the cryptographic signature can occur in a secure environment. The asymmetric cryptographic signature can be based upon a cryptographic algorithm, such as a Rivest Shamir Adleman (RSA) algorithm. The cryptographic signature can be associated with a public key that can be shared with one or more devices, and a private key that can be shared with a limited number of devices. The public key and private key can be associated with the cryptographic algorithm. The combination of the public and private keys can be used to verify the firmware images integrity based upon one or more cryptographic procedures. “).
With respect to Claim 7, the combination of MARKEY and SHINER disclose the storage device of claim 1.
MARKEY further discloses wherein the processor is configured to generate the second endorsement from the UDS and the first firmware image based on a message authentication code (MAC)-based crypto algorithm, and the second endorsement corresponds to a UDS-based endorsement comprising a valid value (¶[0031] – “For example, the symmetric cryptographic signature may be generated and verified based on a symmetric cryptographic algorithm (e.g., an HMAC algorithm)”; ¶[0028] – “The symmetric cryptographic signature can be based upon a second cryptographic algorithm, such as a hash-based message authentication code (HMAC) algorithm.”)
With respect to Claim 8, the combination of MARKEY and SHINER disclose the storage device of claim 1.
SHINER further discloses wherein the at least one memory comprises at least one non-volatile memory configured to store the UDS data and the PDS data (¶[0088] – “The secure memory device 130 can store a unique device secret 101 for its authentication”; ¶[0130] – “When the memory device 130 is manufactured, one or more relevant cryptographic keys 105 are stored in the memory device 130 to provide the owner privileges to the security server 140”).
With respect to Claim 11, the combination of MARKEY and SHINER disclose the method of claim 10.
MARKEY further discloses before the performing of the first integrity check, controlling the NVM to store a UDS-based endorsement, the first endorsement, and the first firmware image in the non-volatile memory (Fig 2, Step 205 – “Receive Firmware Image Signed with First Signature based on First Signing Procedure”; ¶[0033] – “For example, the new firmware image can be received by the memory sub-system containing an asymmetric cryptographic signature based upon an asymmetric signing procedure. The asymmetric cryptographic signature can be a signature written to a portion of the firmware image and used to verify the firmware image based upon the associated cryptographic algorithm. For example, an asymmetric cryptographic algorithm, such as a Rivest Shamir Adleman (RSA) algorithm, can be used in the generation of the symmetric cryptographic signature. Signing of the asymmetric cryptographic signature can be performed by a signing manager, such as asymmetric signing manager 150 as discussed with reference to the memory sub-system in FIG. 1. In some cases, an asymmetric cryptographic algorithm, such as the RSA cryptographic algorithm, may be associated with two keys, such as a private key and a public key. The private key may be used when generating the asymmetric cryptographic signature that is signed to the firmware image.”)
With respect to Claim 12, the combination of MARKEY and SHINER disclose the method of claim 11.
MARKEY further disclose (The function of “loading the UDS-based endorsement …” is not required to be performed under the Broadest Reasonable Interpretation of the claim because the function is performed contingent on “in response to a re-booting performed …” and the contingency is not met {or required} by the claim. See EXAMINER’S NOTE below); and performing a second integrity check for the first firmware image based on the UDS, the first firmware image, and the UDS-based endorsement (Fig 2, Step 225 – “Verify Firmware Image based on Second Signing Procedure”).
With respect to Claim 13, the combination of MARKEY and SHINER disclose the method of claim 12.
MARKEY further discloses wherein the performing of the second integrity check comprises: generating a measurement from the UDS and the first firmware image based on a message authentication code (MAC)-based crypto algorithm; and determining whether the measurement and the UDS-based endorsement are identical to each other (¶[0031] – “For example, the symmetric cryptographic signature may be generated and verified based on a symmetric cryptographic algorithm (e.g., an HMAC algorithm)”; ¶[0028] – “The symmetric cryptographic signature can be based upon a second cryptographic algorithm, such as a hash-based message authentication code (HMAC) algorithm.”).
With respect to Claim 14, the combination of MARKEY and SHINER disclose the method of claim 13.
SKELTON further discloses wherein, in the performing of the first integrity check, the first integrity check is performed in response to a failure result indicating that the measurement and the UDS-based endorsement are different from each other (Fig 2 illustrates Step 240 – “Verify Firmware Image based on First Signing Procedure” happens in response to Step 230 – “Verify Firmware Image based on Second Signing Procedure” => NO).
With respect to Claim 15, the combination of MARKEY and SHINER disclose the method of claim 10.
MARKEY further discloses wherein the performing of the first integrity check comprises: generating a measurement from the PDS and the first firmware image of the PDS data based on a message authentication code (MAC)-based crypto algorithm; and determining whether the measurement and the first endorsement are identical to each other (¶[0015] – “The firmware image can be received by asymmetric signing manager 150, and asymmetric signing manager 150 can sign (e.g., write) a cryptographic signature, such as an asymmetric cryptographic signature to the firmware image. The signing of the firmware image with the cryptographic signature can occur in a secure environment. The asymmetric cryptographic signature can be based upon a cryptographic algorithm, such as a Rivest Shamir Adleman (RSA) algorithm. The cryptographic signature can be associated with a public key that can be shared with one or more devices, and a private key that can be shared with a limited number of devices. The public key and private key can be associated with the cryptographic algorithm. The combination of the public and private keys can be used to verify the firmware images integrity based upon one or more cryptographic procedures.“).
With respect to Claim 16, the combination of MARKEY and SHINER disclose the method of claim 10.
MARKEY further discloses controlling the NVM to store the second endorsement and the first firmware image in the NVM (Fig 2, Step 220 – Write Second Signature to Firmware Image).
With respect to Claim 18, the combination of MARKEY and SHINER disclose the UFS system of claim 17.
MARKEY further discloses wherein the processor is configured to generate a measurement from the PDS of the PDS data and the first firmware image based on a message authentication code (MAC)-based crypto algorithm, and perform the first integrity check based on determining whether the measurement and the first endorsement are identical to each other (¶[0015] – “The firmware image can be received by asymmetric signing manager 150, and asymmetric signing manager 150 can sign (e.g., write) a cryptographic signature, such as an asymmetric cryptographic signature to the firmware image. The signing of the firmware image with the cryptographic signature can occur in a secure environment. The asymmetric cryptographic signature can be based upon a cryptographic algorithm, such as a Rivest Shamir Adleman (RSA) algorithm. The cryptographic signature can be associated with a public key that can be shared with one or more devices, and a private key that can be shared with a limited number of devices. The public key and private key can be associated with the cryptographic algorithm. The combination of the public and private keys can be used to verify the firmware images integrity based upon one or more cryptographic procedures. “).
With respect to Claim 19, the combination of MARKEY and SHINER disclose the UFS system of claim 17.
MARKEY further discloses wherein the processor is configured to generate the second endorsement from the UDS and the first firmware image based on a message authentication code (MAC)-based crypto algorithm (¶[0031] – “For example, the symmetric cryptographic signature may be generated and verified based on a symmetric cryptographic algorithm (e.g., an HMAC algorithm)”; ¶[0028] – “The symmetric cryptographic signature can be based upon a second cryptographic algorithm, such as a hash-based message authentication code (HMAC) algorithm.”).
Claim(s) 20 and 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over MARKEY in further view of SHINER and WELLS et al (US Patent 6,488,585).
With respect to Claim 20, the combination of MARKEY and SHINER disclose the UFS system of claim 17.
SHINER further discloses read-only memory (ROM) configured to store the PDS data (¶[0669] – “memory device can be based on … EEPROM”).
MARKEY and SHINER may not explicitly disclose wherein the at least one memory comprises: one-time programmable (OTP) memory configured to store the UDS data.
However, WELLS discloses wherein the at least one memory comprises: one-time programmable (OTP) memory configured to store the UDS data (Col 8, Lines 1-4 – “Preferably, the information stored in OTP/AO memory includes information that can be used for error or data integrity checks such as cyclic redundancy check (CRC) information, one or more parity bits or the like”).
MARKEY, SHINER, and WELLS are analogous art because they are from the same field of endeavor of data integrity and security. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of MARKEY, SHINER, and WELLS before him or her, to modify the integrity check of the combination of MARKEY and SHINER to include verification data to be stored on OTP memory as taught by WELLS. A motivation for doing so would have been to assist in preventing or reducing the likelihood of an improper download (Col 7, Line 61 through Col 8, Line 26). Therefore, it would have been obvious to combine MARKEY, SHINER, and WELLS to obtain the invention as specified in the instant claims.
With respect to Claim 21, the combination of MARKEY and SHINER disclose the UFS system of claim 17.
MARKEY and SHINER may not explicitly disclose wherein the at least one memory comprises one-time programmable (OTP) memory configured to store the UDS data and the PDS data.
However, WELLS discloses wherein the at least one memory comprises one-time programmable (OTP) memory configured to store the UDS data and the PDS data (Col 8, Lines 1-4 – “Preferably, the information stored in OTP/AO memory includes information that can be used for error or data integrity checks such as cyclic redundancy check (CRC) information, one or more parity bits or the like”).
MARKEY, SHINER, and WELLS are analogous art because they are from the same field of endeavor of data integrity and security. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of MARKEY, SHINER, and WELLS before him or her, to modify the integrity check of the combination of MARKEY and SHINER to include verification data to be stored on OTP memory as taught by WELLS. A motivation for doing so would have been to assist in preventing or reducing the likelihood of an improper download (Col 7, Line 61 through Col 8, Line 26). Therefore, it would have been obvious to combine MARKEY, SHINER, and WELLS to obtain the invention as specified in the instant claims.
EXAMINER’S NOTE
The Office reminds the applicant of MPEP 2111.04(II) with respect to process or method claims reciting contingent limitations:
The broadest reasonable interpretation of a method (or process) claim having contingent limitations requires only those steps that must be performed and does not include steps that are not required to be performed because the condition(s) precedent are not met. For example, assume a method claim requires step A if a first condition happens and step B if a second condition happens. If the claimed invention may be practiced without either the first or second condition happening, then neither step A or B is required by the broadest reasonable interpretation of the claim. If the claimed invention requires the first condition to occur, then the broadest reasonable interpretation of the claim requires step A. If the claimed invention requires both the first and second conditions to occur, then the broadest reasonable interpretation of the claim requires both steps A and B.
The broadest reasonable interpretation of a system (or apparatus or product) claim having structure that performs a function, which only needs to occur if a condition precedent is met, requires structure for performing the function should the condition occur. The system claim interpretation differs from a method claim interpretation because the claimed structure must be present in the system regardless of whether the condition is met and the function is actually performed.
See Ex parte Schulhauser, Appeal 2013-007847 (PTAB April 28, 2016) for an analysis of contingent claim limitations in the context of both method claims and system claims. In Schulhauser, both method claims and system claims recited the same contingent step. When analyzing the claimed method as a whole, the PTAB determined that giving the claim its broadest reasonable interpretation, "[i]f the condition for performing a contingent step is not satisfied, the performance recited by the step need not be carried out in order for the claimed method to be performed" (quotation omitted). Schulhauser at 10. When analyzing the claimed system as a whole, the PTAB determined that "[t]he broadest reasonable interpretation of a system claim having structure that performs a function, which only needs to occur if a condition precedent is met, still requires structure for performing the function should the condition occur." Schulhauser at 14. Therefore "[t]he Examiner did not need to present evidence of the obviousness of the [ ] method steps of claim 1 that are not required to be performed under a broadest reasonable interpretation of the claim (e.g., instances in which the electrocardiac signal data is not within the threshold electrocardiac criteria such that the condition precedent for the determining step and the remaining steps of claim 1 has not been met);" however to render the claimed system obvious, the prior art must teach the structure that performs the function of the contingent step along with the other recited claim limitations. Schulhauser at 9, 14.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ERIC T LOONAN whose telephone number is (571)272-6994. The examiner can normally be reached M-F 8am-5pm.
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, Arpan Savla can be reached at 571-272-1077. 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.
/ERIC T LOONAN/Primary Examiner, Art Unit 2137
Prosecution Insights