DETAILED ACTION
Response to Arguments
Applicant's arguments ("REMARKS") filed 21 May 2026 have been fully considered, and they are partially persuasive as to the previous grounds of rejection.
Claims 5-6 and 8 were amended. Claims 1, 8, 15, and 18 are independent. Claims 1-20 are currently pending.
Re: Claim Rejections Under 35 U.S.C. §112(b)
The rejection of claims 5-6 under 35 U.S.C. §112(b) has been withdrawn in view of Applicant’s amendments to the claims indicated on p.6 of the REMARKS.
Re: Claim Rejections Under 35 U.S.C. §103
Applicant’s arguments, indicated on pp.6-8 of the REMARKS, in response to the rejection of the claims under 35 U.S.C. §103 with respect to Dahiya et al., US 2021/0319107 A1 (hereinafter, “Dahiya ‘107”), Chung et al., US 2025/0053407 A1 (hereinafter, “Chung ‘407”), Stahlberg et al., US 2018/0367311 A1 (hereinafter, “Stahlberg ‘311”), and Zaidi et al., US 2015/0067313 A1 (hereinafter, “Zaidi ‘313”) have been fully considered, and they are partially persuasive as to the previous grounds of rejection. In particular, Applicant argues that:
With respect to independent claims 1, 15 and 18, the ‘received request’ in Stahlberg ‘311 does not include a ‘cryptographic key’.
With respect to independent claims 1, 15 and 18, Stahlberg ‘311 does not disclose comparing a received cryptographic key to a respective cryptographic key by the HSM.
With respect to independent claims 1, 15 and 18, Stahlberg ‘311 does not disclose comparing a received authorization token to a stored authorization token by the HSM.
With respect to independent claim 8, the references do not explicitly disclose “… storing, by the second entity, the cryptographic key …”, as amended.
As an initial matter, with respect to Arguments A-C, Applicant's arguments appear to be directed exclusively to Stahlberg ‘311. Independent claims 1, 15, and 18 stand rejected under 35 U.S.C. 103 over Dahiya ‘107 in view of Chung ‘407, further in view of Stahlberg ‘311, and further in view of Zaidi ‘313. One cannot show nonobviousness by attacking references individually where the rejection is predicated upon a combination of references. See In re Keller, 642 F.2d 413 (CCPA 1981); In re Merck & Co., 800 F.2d 1091 (Fed. Cir. 1986); MPEP 2145(IV).
In Response to Argument A
With respect to independent claims 1, 15 and 18, Applicant argues that Stahlberg ‘311 discloses receiving a request for a cryptographic operation that includes an authorization token, but that the ‘received request does not include a cryptographic key’, and that Stahlberg ‘311 ‘only teaches cryptographic keys stored and managed by the HSM’.
The Examiner respectfully disagrees. The Applicant’s argument is not persuasive.
Applicant cites to ¶¶45 and 52 of Stahlberg ‘311 in support of Argument A. ¶¶45 and 52, however, only describe the operations performed by the HSM upon receipt of a request, they do not describe the contents of the request. The contents of the request are disclosed elsewhere in Stahlberg ‘311 and expressly include a cryptographic key. For example, Stahlberg ‘311 discloses that the method includes receiving, at a hardware security module, the cryptographic operation request including a cryptographic key and at least one authorization token (Stahlberg ‘311, ¶¶Abstract, 4). Furthermore, Stahlberg ‘311 discloses that, at time 2 of FIG.4, the user device 110 sends the cryptographic operation request 250 including the wrapped cryptographic key 120 and the authorization token 220 to the HSM 200 (Stahlberg ‘311, ¶44); a request that includes the cryptographic key 120 together with a first authorization token 220a and a second authorization token 220b (Stahlberg ‘311, ¶¶37, 50).
Examiner further disagrees with Applicant’s argument that Stahlberg ‘311 ‘only teaches cryptographic keys stored and managed by the HSM’. The cryptographic key 120 of Stahlberg ‘311 is a wrapped key, encrypted and signed by the HSM, which the HSM transmits out to the HSM manager and then to the user device (Stahlberg ‘311, ¶¶36, 42). The wrapped key is then presented back to the HSM with each cryptographic operation request. Stahlberg ‘311 discloses that only the HSM is capable of performing operations on the wrapped cryptographic key when authorized users present the wrapped cryptographic key and the at least one authorization token specified by the associated access control list (Stahlberg ‘311, ¶42). Thus, the cryptographic key presented to the HSM is an external wrapped key associated with each request, and not simply ‘cryptographic keys stored and managed by the HSM’.
In Response to Argument B
With respect to independent claims 1, 15 and 18, Applicant argues that, because Stahlberg ‘311 does not disclose a request containing a cryptographic key, Stahlberg ‘311 also fails to disclose the HSM comparing a received cryptographic key to a respective cryptographic key stored in the HSM.
The Examiner respectfully disagrees. The Applicant’s argument is not persuasive.
Stahlberg ‘311 expressly discloses a matching of the received cryptographic key against a corresponding cryptographic key, stating that when the cryptographic key of the cryptographic operation request matches the corresponding cryptographic key of the access control list, the HSM determines whether the requested cryptographic operation is allowed by that access control list (Stahlberg ‘311, ¶5). Stahlberg ‘311 further discloses that the access control list against which the received key is matched may be maintained within the HSM, referring to a master access control list stored in the HSM (Stahlberg ‘311, ¶52). In addition, upon creation of the key the HSM records the public authorizer key 118, and the wrapped cryptographic key 120 subsequently presented to the HSM includes the public parts of that authorizer key (Stahlberg ‘311, ¶¶36, 42). The HSM authenticates the received cryptographic key on this basis before processing the request (Stahlberg ‘311, ¶¶45, 53).
In Response to Argument C
With respect to independent claims 1, 15 and 18, Applicant argues that Stahlberg ‘311 does not disclose the HSM comparing the received authorization token to a stored authorization token, and that instead the HSM of Stahlberg ‘311 uses the received authorization token together with stored access control policies to determine whether the requested cryptographic operation is permitted.
The Examiner respectfully disagrees. The Applicant’s argument is not persuasive.
First, the authorization token of Stahlberg ‘311 is issued by the HSM itself in response to a challenge request from the owner of the cryptographic key (Stahlberg ‘311, ¶¶6, 38, 40). The token contains an HSM identifier 222 associated with data identifying the issuing HSM and a cryptographic signature 224 of that HSM (Stahlberg ‘311, ¶40). When the token is subsequently presented to the HSM with a cryptographic operation request, the HSM validates the token against data that the HSM itself contains, including the authorizer key 118 recorded by the HSM at the time of key creation, the authorization time period 226 evaluated against the internal clock 211 of the HSM, and the limit number 228 evaluated against the counter 213 that the HSM maintains for the particular token (Stahlberg ‘311, ¶¶42, 45, 55). Thus, Stahlberg ‘311 discloses validation by the HSM of the token against credentials retained within the HSM (i.e., comparing of the identity token to a respective identity token stored in the HSM).
Second, Applicant's argument appears to use a claim construction narrower than the construction supported by Applicant’s disclosure. Applicant essentially argues that the limitation “comparing, by the HSM, the identity token and the cryptographic key to a respective identity token and a respective cryptographic key stored in the HSM” requires that the HSM to hold duplicate copies of the received token and the received key and to perform a direct comparison against those duplicates. The present Specification does not disclose this type of comparison. Rather, the Specification states that an HSM can validate the input token and public key against an unrevoked Key Authentication Key (KAK) that is currently provisioned in the HSM (Specification, ¶58). Thus, in view of the Specification, the recited comparing step is interpreted as validating the incoming token and the incoming key against key material provisioned in the HSM.
In Response to Argument D
With respect to independent claim 8, as amended, Applicant argues that the Office Action of 25 February 2026 maps the claimed “system architecture” to computing platform 104 of Chung ‘407 and the claimed “second entity” to third-party computing platform 203 of Chung ‘407. Under this mapping, Chung ‘407 must disclose computing platform 203 both generating and storing a cryptographic key in HSM 106 of computing platform 104. Applicant argues that Chung ‘407 does not disclose this because the vendor pre-stores public keys in memory 138 of computing platform 104 at the time of manufacture and computing platform 104 thereafter moves those keys from memory 138 into HSM 106.
The Applicant’s argument is partially persuasive.
While the factory configuration (FCFG) region of memory 138 is pre-programmed by a vendor root of trust, Chung ‘407 further discloses that the public key of the other public/private key pair (e.g., the customer or third-party key pair) is stored in a system configuration (SCFG) region of memory 138 that is pre-programmed by the customers (Chung ‘407, ¶29). Thus, the entity mapped to the “second entity” programs the key into the “system architecture”. Furthermore, Chung ‘407 discloses that the third party holds the private key of the second public/private key pair and signs the firmware package with that private key outside the secure computing platform (Chung ‘407, ¶¶26-27, 46), and that the second public key is stored in the HSM asset store associated with the HSM (Chung ‘407, ¶¶29, 47).
Amended claim 8 now requires that the storing of the cryptographic key in the hardware security module be performed “by the second entity”. In Chung ‘407, the second entity pre-programs the key into the SCFG region of memory 138, and the subsequent transfer of that key into the HSM asset store 144 is performed by the firmware verifier 140 of the computing platform rather than by “the second entity” (Chung ‘407, ¶29).
With respect to independent claim 8, Applicant’s arguments and amendments have necessitated new ground(s) of rejection presented in this Office Action. A new ground of rejection has been asserted over Ballesteros, US 2014/0331064 A1 (hereinafter, “Ballesteros ‘064”).
Ballesteros ‘064 discloses generating a public key by an OEM, where the public key is used to verify the authenticity of code images. The public key is to be programmed at OEM manufacturing time and not at SoC manufacturing time, so as to allow the OEM to decide what keys to use for its devices (Ballesteros ‘064, ¶12). Ballesteros ‘064 further discloses that each OEM burns its respective values into the field programmable fuses of the SoC (Ballesteros ‘064, ¶19), in contrast to the public key of the SoC manufacturer, which is provisioned at SoC manufacturing time (Ballesteros ‘064, ¶¶13, 21). Thus, Ballesteros ‘064 discloses that the entity distinct from the manufacturer of the system architecture is the entity that generates the cryptographic key and provisions it into the system architecture, as recited in claim 8.
Thus, for the reasons stated above, the rejection of claims 1-5, 7, 15-20 under 35 U.S.C. 103 is maintained. The new grounds of rejection entered with respect to claim 6 and claims 8-14 are necessitated by Applicant's amendments to claims 6 and 8, respectively.
See Claim Rejections – 35 USC §103 below for further details.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
This application includes one or more claim limitations that use the word “means,” and are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. Such claim limitation(s) is/are:
“… and means for managing patching of the write-limited memory …” in claim 18.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 3-4, 7, and 15-20 are rejected under 35 U.S.C. 103 as being unpatentable over Dahiya et al., US 2021/0319107 A1 (hereinafter, “Dahiya ‘107”), in view of Chung et al., US 2025/0053407 A1 (hereinafter, “Chung ‘407”), and further in view of Stahlberg et al., US 2018/0367311 A1 (hereinafter, “Stahlberg ‘311”), and further in view of Zaidi et al., US 2015/0067313 A1 (hereinafter, “Zaidi ‘313”).
As per claim 1: Dahiya ‘107 discloses:
A method for managing patching of write-limited memory with a (a method for securely patching a read-only-memory (ROM) code, where the ROM patch is stored in a one-time programmable (OTP) memory of a system-on-chip (SoC), and where the OTP memory is a write-limited memory [Dahiya ‘107, ¶¶2-3, 9, 16, 44])
configuring a patch code (generating first partial cryptographic data based on the ROM patch and a set of secret bits for authenticating the ROM patch, where the ROM patch includes a set of address bits, a set of reference bits, and a set of data bits that are indicative of a ROM patch address, reference partial cryptographic data, and a set of patch instructions, respectively [Dahiya ‘107, ¶¶8-9, 16-19, 37]); and
installing the patch code in the write-limited memory (upon authentication of the ROM patch, the set of patch instructions of the ROM patch is executed instead of the erroneous ROM instructions, thereby securely patching the ROM code; the ROM patch may be stored in the OTP memory after the device is deployed in the field, and the OTP memory may include a plurality of ROM patches [Dahiya ‘107, ¶¶9, 16, 40-41, 44-45]).
As stated above, while Dahiya ‘107 discloses a method for securely patching ROM code stored in OTP memory with cryptographic authentication, Dahiya ‘107 does not explicitly disclose that the patching is managed “… with a hardware security module (HSM) comprising a plurality of one-time programmable (OTP) memory blocks where each OTP memory block is associated with a respective identification value; … receiving, from a patching entity, a patch management request, the patch management request comprising a first identification value associated with an OTP memory block of the plurality of OTP memory blocks of the HSM, an identity token, a cryptographic key, and a signature object; comparing, by the HSM, the identity token and the cryptographic key to a respective identity token and a respective cryptographic key stored in the HSM; verifying, by the HSM, the signature object of the patch management request …”.
Chung ‘407, however, discloses:
... with a hardware security module (HSM) (a computing platform 104 including a hardware security module (HSM) 106, where the HSM 106 includes an HSM ROM 148 and an HSM firmware region 150, and where an HSM asset store 144 is stored in a secure memory of the HSM 106 [Chung ‘407, ¶¶24, 28-29]) comprising ...
receiving, from a patching entity, a patch management request (receiving, at the computing platform 104, a firmware package 108 from a secure computing platform 102, where the firmware package is utilized to update the firmware associated with the HSM 106 [Chung ‘407, ¶¶24, 28, 47]), the patch management request comprising (the firmware package includes a first signature and a second signature, and in some examples a third signature signed by a customer’s private key [Chung ‘407, ¶¶25-26, 45-46]);
verifying, by the HSM, the signature object of the patch management request (the firmware updater 146 of the HSM 106 is configured to verify the second signature of the firmware package 108 by using the public key 118 stored in the HSM asset store 144; the firmware updater 146 is further configured to verify the third signature using the customer public key stored in the HSM asset store 144 [Chung ‘407, ¶¶32-33, 39, 48-50]) …
Dahiya ‘107 and Chung ‘407 are analogous art because they are from the same field of endeavor, namely that of securely updating or patching code in embedded systems. Prior to 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 Dahiya ‘107 and Chung ‘407 before them, to modify the method in Dahiya ‘107 to include the teachings of Chung ‘407, namely to implement the OTP-based ROM patching system of Dahiya ‘107 with a dedicated hardware security module (HSM), as disclosed in Chung ‘407, where the HSM receives a patch package from an external patching entity, verifies signatures of the package using cryptographic keys stored in the HSM asset store, and writes the verified patch code to the HSM firmware region. A motivation for doing so would be to ensure confidentiality and integrity of the patch update by delegating security operations to a dedicated HSM with tamper-resistant key storage and signature verification capabilities (see Chung ‘407, ¶¶20-23, 43).
As stated above, Dahiya ‘107 in view of Chung ‘407 does not explicitly disclose: “... a plurality of one-time programmable (OTP) memory blocks where each OTP memory block is associated with a respective identification value ... a first identification value associated with an OTP memory block of the plurality of OTP memory blocks … an identity token, a cryptographic key ... ; comparing, by the HSM, the identity token and the cryptographic key to a respective identity token and a respective cryptographic key stored in the HSM …
Stahlberg ‘311, however, discloses:
…
... the patch management request comprising … an identity token (a cryptographic operation request including at least one authorization token 220, where the authorization token includes data identifying the HSM, a cryptographic signature 224 of the HSM, and a digital signature 230 signed by the authorizer key 118 of the owner [Stahlberg ‘311, ¶¶4, 40, 44]), a cryptographic key (the cryptographic operation request further includes a cryptographic key 120, where the cryptographic key 120 is wrapped and includes public parts of the authorizer key 118 [Stahlberg ‘311, ¶¶4, 36, 42, 44]) ... ;
comparing, by the HSM, the identity token and the cryptographic key to a respective identity token and a respective cryptographic key stored in the HSM (at the HSM 200, authenticating and authorizing the cryptographic operation request, where the HSM 200 validates the authorization token 220 by determining whether the authorization token is signed by the authorizer key 118 and is within the authorization time period 226; where the cryptographic key of the cryptographic operation request matches the corresponding cryptographic key of the access control list (ACL) 214; and the HSM 200 thereafter determines whether the requested cryptographic operation is allowed by the ACL 124; where the ACL (against which the received cryptographic key is matched) is maintained as a master ACL stored in the HSM 200; and where the HSM 200 records the public authorizer key 118 upon creation of the cryptographic key 120, such that both the token validation and the key authorization conditions must be satisfied before the request is processed [Stahlberg ‘311, ¶¶4-5, 36, 42, 45, 52]) …
Dahiya ‘107 (modified by Chung ‘407) and Stahlberg ‘311 are analogous art because they are from the same field of endeavor, namely that of authenticating requests at hardware security modules using cryptographic credentials. Prior to 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 Dahiya ‘107 (modified by Chung ‘407) and Stahlberg ‘311 before them, to modify the method in Dahiya ‘107 (modified by Chung ‘407) to include the teachings of Stahlberg ‘311, namely to implement the patch management request to the HSM to include an authorization token and a cryptographic key bundled with the signature object, as disclosed in Stahlberg ‘311, and to configure the HSM to validate the authorization token and verify the association of the cryptographic key with the access control list before processing the patch request. A motivation for doing so would be to provide defense-in-depth security by requiring multiple forms of authentication, such as token validation, key authorization, and signature verification, before granting access to security-critical HSM operations (see Stahlberg ‘311, ¶¶4-5, 42, 45).
As stated above, Dahiya ‘107 in view of Chung ‘407, and further in view of Stahlberg ‘311 does not explicitly disclose: “... a plurality of one-time programmable (OTP) memory blocks where each OTP memory block is associated with a respective identification value ... a first identification value associated with an OTP memory block of the plurality of OTP memory blocks ...”.
Zaidi ‘313, however, discloses:
... a plurality of one-time programmable (OTP) memory blocks where each OTP memory block is associated with a respective identification value (OTP storage elements 116 configured to store boot ROM patch data 118, where the OTP storage elements can be implemented using electronic fuses or other one-time programmable non-volatile memory; the boot ROM patch data 118 can include multiple sets of patch data, and each set of patch data can include a unique identifier for the particular patch [Zaidi ‘313, ¶¶12, 18, 26]) ...
... a first identification value associated with an OTP memory block of the plurality of OTP memory blocks (the processor 102 can access OTP storage elements 116 to see whether one or more specified identifiers for secure patch data has been programmed in the OTP storage elements 116, where each set of patch data can include a unique identifier for the particular patch, an address of the boot ROM where the patch is used, the type of patch, the size of the patch, and the patch data [Zaidi ‘313, ¶26]) …
Dahiya ‘107 (modified by Chung ‘407 and Stahlberg ‘311) and Zaidi ‘313 are analogous art because they are from the same field of endeavor, namely that of secure ROM patching using one-time programmable memory on system-on-chip devices. Prior to 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 Dahiya ‘107 (modified by Chung ‘407 and Stahlberg ‘311) and Zaidi ‘313 before them, to modify the method in Dahiya ‘107 (modified by Chung ‘407 and Stahlberg ‘311) to include the teachings of Zaidi ‘313, namely to organize the OTP memory of Dahiya ‘107 into a plurality of OTP memory blocks, where each OTP memory block is associated with a unique identifier for identifying the particular patch data, as disclosed in Zaidi ‘313, and to include the identification value of a target OTP memory block in the patch management request. A motivation for doing so would be to efficiently manage and identify multiple sets of patch data stored in OTP memory, where the unique identifiers enable the system to determine whether secure patch data for the boot ROM is available and to accurately select the corresponding patch data for patching (see Zaidi ‘313, ¶¶11, 26, 28).
As per claim 3: Dahiya ‘107 in view of Chung ‘407, and further in view of Stahlberg ‘311, and further in view of Zaidi ‘313 discloses all limitations of claim 1, as stated above, from which claim 3 is dependent upon. Furthermore, Dahiya ‘107 discloses:
wherein the configuring the patch code further comprises checking the patch code for errors (authenticating the ROM patch by generating first partial cryptographic data based on the ROM patch and a set of secret bits, and comparing the first partial cryptographic data with the reference partial cryptographic data of the ROM patch to determine if they match; if the first and reference partial cryptographic data do not match, the processor determines that the authentication of the ROM patch is unsuccessful, i.e., the ROM patch is an invalid ROM patch [Dahiya ‘107, ¶¶9, 37-38]) and
As stated above, Dahiya ‘107 does not explicitly disclose “… loading the patch code into random access memory (RAM) of the HSM.”
Zaidi ‘313, however, discloses:
... loading the patch code into random access memory (RAM) (using corresponding patch data copy instructions 107 to copy boot ROM patch data 118 from the OTP storage elements 116 to patch data 112 in internal memory 110, where internal memory 110 can be any suitable random access memory (RAM) [Zaidi ‘313, ¶¶15, 17, 26])
Dahiya ‘107 (modified by Stahlberg ‘311) and Zaidi ‘313 are analogous art because they are from the same field of endeavor, namely that of secure ROM patching using one-time programmable memory on system-on-chip devices. Prior to 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 Dahiya ‘107 (modified by Stahlberg ‘311) and Zaidi ‘313 before them, to modify the method in Dahiya ‘107 (modified by Stahlberg ‘311) to include the teachings of Zaidi ‘313, namely to copy patch code from the OTP storage elements into random access memory (RAM) prior to execution. A motivation for doing so would be to enable the processor to execute the patch instructions from RAM during the boot process, where the patch data in RAM can be used in place of erroneous boot instructions without modifying the original ROM code (see Zaidi ‘313, ¶¶11, 26, 29).
As stated above, Dahiya ‘107 in view of Zaidi ‘313 does not explicitly disclose loading the patch code into random access memory (RAM) “… of the HSM.”
Chung ‘407, however, discloses:
... loading the ... into ... of the HSM (the HSM 106 includes an HSM ROM 148 and an HSM firmware region 150, where the decrypted augmented firmware image is transferred and written to the HSM firmware region 150 of the HSM 106; the HSM asset store 144 is stored in a secure memory of the HSM 106 and is only accessible by the system ROM and the HSM ROM 148 [Chung ‘407, ¶¶28-29, 36-37, 54]).
Dahiya ‘107 (modified by Stahlberg ‘311 and Zaidi ‘313) and Chung ‘407 are analogous art because they are from the same field of endeavor, namely that of securely updating or patching code in embedded systems. Prior to 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 Dahiya ‘107 (modified by Stahlberg ‘311 and Zaidi ‘313) and Chung ‘407 before them, to modify the method in Dahiya ‘107 (modified by Stahlberg ‘311 and Zaidi ‘313) to include the teachings of Chung ‘407, namely to perform the loading of the patch code into RAM within the hardware security module. A motivation for doing so would be to ensure that the patch code is loaded into memory that is protected by the HSM, where the HSM firmware region and asset store are only accessible by the system ROM and the HSM ROM, thereby preventing unauthorized access to or tampering with the patch code during the loading process (see Chung ‘407, ¶¶28-29, 43).
As per claim 4: Dahiya ‘107 in view of Chung ‘407, and further in view of Stahlberg ‘311, and further in view of Zaidi ‘313 discloses all limitations of claims 1 and 3, as stated above, from which claim 4 is dependent upon. Dahiya ‘107 in view of Stahlberg ‘311 does not explicitly disclose the limitations of claim 4. Zaidi ‘313, however, discloses:
wherein the patch code is loaded from an OTP memory block (using corresponding patch data copy instructions 107 to copy boot ROM patch data 118 from the OTP storage elements 116 [Zaidi ‘313, ¶¶15, 26]) (the boot ROM patch data 118 can include multiple sets of patch data, and each set of patch data can include a unique identifier for the particular patch [Zaidi ‘313, ¶26]) into RAM (copying boot ROM patch data 118 from the OTP storage elements 116 to patch data 112 in internal memory 110, where internal memory 110 can be any suitable random access memory (RAM) [Zaidi ‘313, ¶¶17, 26])
Dahiya ‘107 (modified by Stahlberg ‘311) and Zaidi ‘313 are analogous art because they are from the same field of endeavor, namely that of secure ROM patching using one-time programmable memory on system-on-chip devices. Prior to 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 Dahiya ‘107 (modified by Stahlberg ‘311) and Zaidi ‘313 before them, to modify the method in Dahiya ‘107 (modified by Stahlberg ‘311) to include the teachings of Zaidi ‘313, namely to load the patch code from a specific OTP memory block identified by a unique identifier into RAM. A motivation for doing so would be to enable the system to accurately select and load the correct patch data from among multiple sets of patch data stored in the OTP storage elements, where each set is associated with a unique identifier that distinguishes it from other patch sets (see Zaidi ‘313, ¶26).
As stated above, Dahiya ‘107 in view of Zaidi ‘313 does not explicitly disclose that the OTP memory block is “… of the HSM …” and that the RAM is “… of the HSM.”
Chung ‘407, however, discloses:
... from an OTP memory block of the HSM ... into RAM of the HSM (the HSM 106 includes an HSM ROM 148 and an HSM firmware region 150, where the HSM asset store 144 is stored in a secure memory of the HSM 106; the decrypted augmented firmware image is transferred and written to the HSM firmware region 150 of the HSM 106 [Chung ‘407, ¶¶28-29, 36-37, 54]).
Dahiya ‘107 (modified by Stahlberg ‘311 and Zaidi ‘313) and Chung ‘407 are analogous art because they are from the same field of endeavor, namely that of securely updating or patching code in embedded systems. Prior to 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 Dahiya ‘107 (modified by Stahlberg ‘311 and Zaidi ‘313) and Chung ‘407 before them, to modify the method in Dahiya ‘107 (modified by Stahlberg ‘311 and Zaidi ‘313) to include the teachings of Chung ‘407, namely to locate the OTP memory block and the RAM within the hardware security module. A motivation for doing so would be to ensure that both the source OTP memory and the destination RAM reside within the secure boundary of the HSM, where the HSM firmware region and asset store are only accessible by the system ROM and the HSM ROM, thereby maintaining the integrity and confidentiality of the patch code throughout the loading process (see Chung ‘407, ¶¶28-29, 43).
As per claim 7: Dahiya ‘107 in view of Chung ‘407, and further in view of Stahlberg ‘311, and further in view of Zaidi ‘313 discloses all limitations of claim 1, as stated above, from which claim 7 is dependent upon. Dahiya ‘107 in view of Stahlberg ‘311 and further in view of Zaidi ‘313 does not explicitly disclose the limitations of claim 7. Chung ‘407, however, discloses:
wherein the patch management request further comprises the patch code (the firmware package 108 includes the firmware image 116, where the firmware image is signed with a private key to provide a first signature, augmented with a header to provide an augmented firmware image, encrypted with a symmetric key to provide an encrypted augmented firmware image, and packaged into the firmware package 108; the firmware package 108 is provided to the computing platform 104 to be utilized to update the firmware associated with the HSM 106 [Chung ‘407, ¶¶25-26, 28]).
Dahiya ‘107 (modified by Stahlberg ‘311 and Zaidi ‘313) and Chung ‘407 are analogous art because they are from the same field of endeavor, namely that of securely updating or patching code in embedded systems. Prior to 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 Dahiya ‘107 (modified by Stahlberg ‘311 and Zaidi ‘313) and Chung ‘407 before them, to modify the method in Dahiya ‘107 (modified by Stahlberg ‘311 and Zaidi ‘313) to include the teachings of Chung ‘407, namely to include the patch code within the patch management request. A motivation for doing so would be to enable the system to receive, authenticate, and install the patch code in a single transaction, where the firmware package containing the firmware image is signed and encrypted to ensure both the confidentiality and integrity of the patch code during delivery to the computing platform (see Chung ‘407, ¶¶21, 25-26, 28).
As per claim 15: Claim 15 defines an apparatus that recites substantially similar subject matter as the method of claim 1. Specifically, claim 15 is directed to an apparatus comprising write-limited memory, a hardware security module comprising a plurality of one-time programmable memory blocks, and processor circuitry configured for managing patching of the write-limited memory as recited in the method of claim 1. Thus, the rejection of claim 1 is equally applicable to claim 15.
As per claim 16: Dahiya ‘107 in view of Chung ‘407, Stahlberg ‘311, and further in view of Zaidi ‘313 discloses all limitations of claim 15, as stated above, from which claim 16 is dependent upon. Furthermore, Dahiya ‘107 discloses:
wherein the write-limited memory comprises one or more OTP fuses (the ROM patch is stored in a one-time programmable (OTP) memory 108, where the OTP memory 108 comprises fuse bits, such as a ROM patch enable bit that is a fuse bit and a lock bit that is a fuse bit [Dahiya ‘107, ¶¶16-17]).
As per claim 17: Dahiya ‘107 in view of Chung ‘407, Stahlberg ‘311, and further in view of Zaidi ‘313 discloses all limitations of claim 15, as stated above, from which claim 17 is dependent upon. Furthermore, Dahiya ‘107 discloses:
wherein (the SoC 100 includes a one-time programmable (OTP) memory 108 that is configured to store the ROM patch, where the OTP memory 108 is part of the SoC 100 and comprises write-limited memory utilized for patching the ROM code [Dahiya ‘107, ¶¶12, 14, 16-17]).
As stated above, Dahiya ‘107 does not explicitly disclose the limitation “… the hardware security module comprises at least a portion of the … memory.”
Chung ‘407, however, discloses:
… the hardware security module comprises at least a portion of the … memory (the HSM includes an HSM firmware region 450 and an HSM asset store 444 that store firmware and cryptographic keys, respectively, where the HSM firmware region and the HSM asset store are internal memory regions of the HSM [Chung ‘407, ¶¶20, 28-29, 54]).
Dahiya ‘107 (modified by Stahlberg ‘311 and Zaidi ‘313) and Chung ‘407 are analogous art because they are from the same field of endeavor, namely that of securely updating or patching code in embedded systems. Prior to 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 Dahiya ‘107 (modified by Stahlberg ‘311 and Zaidi ‘313) and Chung ‘407 before them, to modify the method in Dahiya ‘107 (modified by Stahlberg ‘311 and Zaidi ‘313) to include the teachings of Chung ‘407, namely to incorporate OTP memory, as disclosed in Dahiya ‘107, as an internal memory region with the HSM region of Chung ‘407, such that the HSM comprises at least a portion of the write-limited memory. A motivation for doing so would be to ensure that the write-limited memory used for storing patch data has the same security protections afforded by the HSM, thereby preventing unauthorized access to or modifications of the patch data (see Chung ‘407, ¶¶20, 29, 43).
As per claim 18: Claim 18 defines an apparatus that recites substantially similar subject matter as the method of claim 1. Specifically, claim 18 is directed to an apparatus comprising write-limited memory, a hardware security module comprising a plurality of one-time programmable memory blocks, and means for managing patching of the write-limited memory as recited in the method of claim 1. Thus, the rejection of claim 1 is equally applicable to claim 18.
As per claim 19: Dahiya ‘107 in view of Chung ‘407, Stahlberg ‘311, and further in view of Zaidi ‘313 discloses all limitations of claim 18, as stated above, from which claim 19 is dependent upon. Furthermore, Dahiya ‘107 discloses:
wherein the write-limited memory comprises one or more OTP fuses (the ROM patch is stored in a one-time programmable (OTP) memory 108, where the OTP memory 108 comprises fuse bits, such as a ROM patch enable bit that is a fuse bit and a lock bit that is a fuse bit [Dahiya ‘107, ¶¶16-17]).
As per claim 20: Dahiya ‘107 in view of Chung ‘407, Stahlberg ‘311, and further in view of Zaidi ‘313 discloses all limitations of claim 18, as stated above, from which claim 20 is dependent upon. Furthermore, Dahiya ‘107 discloses:
wherein (the SoC 100 includes a one-time programmable (OTP) memory 108 that is configured to store the ROM patch, where the OTP memory 108 is part of the SoC 100 and comprises write-limited memory utilized for patching the ROM code [Dahiya ‘107, ¶¶12, 14, 16-17]).
As stated above, Dahiya ‘107 does not explicitly disclose the limitation “… the hardware security module comprises at least a portion of the … memory.”
Chung ‘407, however, discloses:
… the hardware security module comprises at least a portion of the … memory (the HSM includes an HSM firmware region 450 and an HSM asset store 444 that store firmware and cryptographic keys, respectively, where the HSM firmware region and the HSM asset store are internal memory regions of the HSM [Chung ‘407, ¶¶20, 28-29, 54]).
Dahiya ‘107 (modified by Stahlberg ‘311 and Zaidi ‘313) and Chung ‘407 are analogous art because they are from the same field of endeavor, namely that of securely updating or patching code in embedded systems. Prior to 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 Dahiya ‘107 (modified by Stahlberg ‘311 and Zaidi ‘313) and Chung ‘407 before them, to modify the method in Dahiya ‘107 (modified by Stahlberg ‘311 and Zaidi ‘313) to include the teachings of Chung ‘407, namely to incorporate OTP memory, as disclosed in Dahiya ‘107, as an internal memory region with the HSM region of Chung ‘407, such that the HSM comprises at least a portion of the write-limited memory. A motivation for doing so would be to ensure that the write-limited memory used for storing patch data has the same security protections afforded by the HSM, thereby preventing unauthorized access to or modifications of the patch data (see Chung ‘407, ¶¶20, 29, 43).
Claims 2 and 5 are rejected under 35 U.S.C. 103 as being unpatentable over Dahiya ‘107, in view of Chung ‘407, and further in view of Stahlberg ‘311, and further in view of Zaidi ‘313, and further in view of Yan et al., US 2023/0318819 A1 (hereinafter, “Yan ‘819”).
As per claim 2: Dahiya ‘107 in view of Chung ‘407, Stahlberg ‘311, and Zaidi ‘313 discloses all limitations of claim 1, as stated above, from which claim 2 is dependent upon. Dahiya ‘107 in view of Chung ‘407, Stahlberg ‘311, and Zaidi ‘313 does not explicitly disclose the limitations of claim 2. Yan ‘819, however, discloses:
further comprising deactivating the OTP memory block associated with the first identification value (an OTP module comprising memory that can only be programmed once, where the memory comprises a plurality of regions, each region is dedicated to an individual key of a plurality of OTP keys, and where a key register stored in the OTP module comprises a plurality of status bits, each status bit mapped to an individual key of the plurality of OTP keys, such that when a status bit is burned, the corresponding key group is invalidated; invalidating a first key region by burning a status bit of the key region status register, where the invalidated key region is subsequently ignored during normal operation [Yan ‘819, ¶¶34-35, 38, 54, 59, 61]).
Dahiya ‘107 (modified by Chung ‘407, Stahlberg ‘311, and Zaidi ‘313) and Yan ‘819 are analogous art because they are from the same field of endeavor, namely that of managing one-time programmable memory on a system-on-chip for secure operations. Prior to 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 Dahiya ‘107 (modified by Chung ‘407, Stahlberg ‘311, and Zaidi ‘313) and Yan ‘819 before them, to modify the method in Dahiya ‘107 (modified by Chung ‘407, Stahlberg ‘311, and Zaidi ‘313) to include the teachings of Yan ‘819, namely to implement the OTP memory of Dahiya ‘107 to include a status bit register associated with each OTP memory block, as disclosed in Yan ‘819, such that a specific OTP memory block may be deactivated by burning the corresponding status bit after a patch management operation. A motivation for doing so would be to ensure that obsolete or revoked data stored in a specific OTP region is invalidated and subsequently ignored during normal operation, thereby preventing the reuse of outdated data and improving the security of the system (see Yan ‘819, ¶¶35, 38-39).
As per claim 5: Dahiya ‘107 in view of Chung ‘407, Stahlberg ‘311, and Zaidi ‘313 discloses all limitations of claim 1, as stated above, from which claim 5 is dependent upon. Dahiya ‘107 in view of Chung ‘407, Stahlberg ‘311, and Zaidi ‘313 does not explicitly disclose the limitations of claim 5. Yan ‘819, however, discloses:
further comprising activating the OTP memory block associated with a second identification value (an OTP module comprising memory that can only be programmed once, where the memory comprises a plurality of regions, each region is dedicated to an individual key group image hash of a plurality of key group image hashes; loading a second key group image hash into a second key storage region as part of a key revocation process, where the first key region is invalidated and forward operations continue with new keys stored in the second key storage region [Yan ‘819, ¶¶34, 59-60, 62]).
Dahiya ‘107 (modified by Chung ‘407, Stahlberg ‘311, and Zaidi ‘313) and Yan ‘819 are analogous art because they are from the same field of endeavor, namely that of managing one-time programmable memory on a system-on-chip for secure operations. Prior to 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 Dahiya ‘107 (modified by Chung ‘407, Stahlberg ‘311, and Zaidi ‘313) and Yan ‘819 before them, to modify the method in Dahiya ‘107 (modified by Chung ‘407, Stahlberg ‘311, and Zaidi ‘313) to include the teachings of Yan ‘819, namely to implement the OTP memory of Dahiya ‘107 such that when a patch management operation is performed, a second OTP memory block associated with a second identification value is activated by loading new data into the second OTP storage region, as disclosed in Yan ‘819. A motivation for doing so would be to ensure that after a management operation, forward operations continue with valid data stored in a newly activated OTP region, thereby maintaining the integrity and continuity of secure operations on the system-on-chip (see Yan ‘819, ¶¶60, 62).
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Dahiya ‘107, in view of Chung ‘407, and further in view of Stahlberg ‘311, and further in view of Zaidi ‘313, and further in view of Yan ‘819, and further in view of Shuf et al., US 2011/0022815 A1 (hereinafter, “Shuf ‘815”).
As per claim 6: Dahiya ‘107 in view of Chung ‘407, and further in view of Stahlberg ‘311, and further in view of Zaidi ‘313, and further in view of Yan ‘819 discloses all limitations of claims 1 and 5, as stated above, from which claim 6 is dependent upon. Dahiya ‘107 in view of Chung ‘407, and further in view of Stahlberg ‘311 does not explicitly disclose the limitations of claim 6. Zaidi ‘313, however, discloses:
wherein the second identification value is determined based at least in part on a comparison of a size of the patch code (each set of patch data stored in the OTP storage elements includes metadata comprising a unique identifier for the particular patch, an address of the boot ROM where the patch is used, the type of patch, the size of the patch, and the patch data [Zaidi ‘313, ¶26])
Dahiya ‘107 (modified by Chung ‘407 & Stahlberg ‘311 & Yan ‘819) and Zaidi ‘313 are analogous art because they are from the same field of endeavor, namely that of securely patching boot ROM code using OTP memory in system-on-chip devices. Prior to 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 Dahiya ‘107 (modified by Chung ‘407 & Stahlberg ‘311 & Yan ‘819) and Zaidi ‘313 before them, to modify the method in Dahiya ‘107 (modified by Chung ‘407 & Stahlberg ‘311 & Yan ‘819) to include the teachings of Zaidi ‘313, namely to maintain metadata for each set of patch data stored in the OTP storage elements, including the size of the patch, as disclosed in Zaidi ‘313. A motivation for doing so would be to enable the system to determine whether secure patch data for the boot ROM is available and to facilitate the copying of the appropriate patch data from the OTP storage elements to internal memory (see Zaidi ‘313, ¶¶18, 25-26).
As stated above, while Zaidi ‘313 discloses that each set of patch data includes the size of the patch as metadata, Dahiya ‘107 in view of Chung ‘407, and further in view of Stahlberg ‘311, and further in view of Zaidi ‘313, and further in view of Yan ‘819 does not explicitly disclose the limitation “… and a size of the OTP memory block associated with the second identification value”, as recited in claim 6.
Shuf ‘815, however, discloses:
… and a size of the OTP memory block associated with the second identification value (a storage allocation technique in which a storage block for a data record is selected based on one or more data record attributes, including a record size, where an ideal location for storing the data record is defined as a function of both the key value and the size of the record, i.e., L0=L(key, size), and where the technique searches among a plurality of available storage blocks of varying block sizes to identify a block capable of accommodating the data record, including exploring the possibility of placing a new record into a bigger memory block [Shuf ‘815, ¶¶19-21, 43, 49, 54-55])
Dahiya ‘107 (modified by Chung ‘407, Stahlberg ‘311, Zaidi ‘313, and Yan ‘819) and Shuf ‘815 are analogous art because they are reasonably pertinent to the problem faced by the inventor, namely that of allocating data to an appropriate storage block from among a plurality of available storage blocks. Prior to 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 Dahiya ‘107 (modified by Chung ‘407, Stahlberg ‘311, Zaidi ‘313, and Yan ‘819) and Shuf ‘815 before them, to modify the method in Dahiya ‘107 (modified by Chung ‘407, Stahlberg ‘311, Zaidi ‘313, and Yan ‘819) to include the teachings of Shuf ‘815, namely to apply the known technique of selecting a storage block based on comparing the size of the data to be stored against the sizes of available storage blocks, as disclosed in Shuf ‘815, to the process of selecting an OTP memory block for storing patch code in the modified system. Applying this well-known technique to the OTP patch context would yield predictable results, as comparing the patch code size to the OTP memory block size before selecting a block ensures that the selected block has sufficient capacity to store the patch code. A motivation for doing so would be to achieve lower space fragmentation and more efficient storage allocation by selecting an appropriately-sized storage block for the data to be stored (see Shuf ‘815, ¶¶16-17, 21, 75).
Claims 8-11 and 13-14 are rejected under 35 U.S.C. 103 as being unpatentable over Chung ‘407 in view of Dahiya ‘107, and further in view of Ballesteros, US 2014/0331064 A1 (hereinafter, “Ballesteros ‘064”).
As per claim 8: Chung ‘407 discloses:
A method for managing patching of (a method for updating firmware of a computing platform 104, where the computing platform 104 is manufactured and provided by a vendor associated with a secure computing platform 202, and where the firmware of the HSM needs to be updated after the HSM is delivered to the field or the customer end [Chung ‘407, ¶¶20-21, 24, 44]), wherein the system architecture comprises a hardware security module (the computing platform 104 includes a hardware security module (HSM) 106, where the HSM 106 includes an HSM ROM 148, an HSM firmware region 150, and an HSM asset store 144 [Chung ‘407, ¶¶24, 28-29]), the method comprising:
generating, by a second entity that is different from the first entity, a cryptographic key associated with the system architecture (the third-party computing platform 203, which is different from the secure computing platform 202 of the vendor, is associated with a second private key of a second public private key pair, where the second private key is associated with a second public key, or a public key of the third party, thereby forming the second public private key pair) [Chung ‘407, ¶¶44, 46]);
storing, (the associated public key of the other public private key pair is stored in a system configuration (SCFG) region of the memory 138, which is pre-programmed by the customers, and the firmware verifier 140 is configured to copy the key from the SCFG region to the HSM asset store 144, which is stored in a secure memory of the HSM 106; the second public key is stored in an HSM asset store associated with the HSM 206 [Chung ‘407, ¶¶29, 47]);
configuring, by the first entity, a (the firmware generator 214 of the secure computing platform 202 is configured to sign a firmware image with a first private key to provide a first signature, augment the firmware image with a header to provide an augmented firmware image, and encrypt the augmented firmware image using an AES key to provide an encrypted augmented firmware image [Chung ‘407, ¶¶21, 25, 45]);
generating, by the second entity, a patch management request associated with a signature object, wherein the signature object is produced at least in part on the cryptographic key associated with the system architecture (the third-party computing platform 203 is configured to sign the firmware package 208 with the private key of the third party to provide a third signature, and to augment the firmware package 208 with the third signature to provide a signed firmware package, where the third signature is produced using the second private key of the second public private key pair associated with the system architecture [Chung ‘407, ¶46]); and
providing the patch management request to the system architecture (the firmware verifier 240 of the computing platform 204 is configured to receive the signed firmware package from the firmware generator 214/the third-party computing platform 203 [Chung ‘407, ¶47]).
As stated above, while Chung ‘407 discloses a method for updating firmware of a system architecture comprising a hardware security module, where a second entity generates a cryptographic key associated with the system architecture and signs a firmware package using that key, Chung ‘407 does not explicitly disclose that the memory being patched is “… storing, by the second entity, the cryptographic key … write-limited memory …”, and that the first entity configures “… a patch code associated with the write-limited memory …”.
Dahiya ‘107, however, discloses:
…
... managing patching of write-limited memory (a method for securely patching a read-only-memory (ROM) code, where a ROM patch is stored in a one-time programmable (OTP) memory of a system-on-chip (SoC), and where the OTP memory is a write-limited memory [Dahiya ‘107, ¶¶2-3, 9, 16]) ...
... configuring, by the first entity, a patch code associated with the write-limited memory (the ROM patch is stored in the OTP memory by a system controller that is external to the SoC, where the ROM patch includes a set of address bits, a set of reference bits, and a set of data bits that are indicative of a ROM patch address, reference partial cryptographic data, and a set of patch instructions, respectively [Dahiya ‘107, ¶¶15-16, 18-19]) ...
Chung ‘407 and Dahiya ‘107 are analogous art because they are from the same field of endeavor, namely that of securely updating or patching code in embedded systems. Prior to 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 Chung ‘407 and Dahiya ‘107 before them, to modify the method in Chung ‘407 to include the teachings of Dahiya ‘107, namely to implement the HSM firmware update process of Chung ‘407 in the context of patching write-limited memory such as OTP memory, as disclosed in Dahiya ‘107, where the firmware image of Chung ‘407 corresponds to patch code that is configured for patching the write-limited memory of the system architecture. A motivation for doing so would be to enable secure patching of ROM code stored in OTP memory after the device is deployed in the field, thereby eliminating the need to replace the device to fix bugs and leading to a low cost of manufacturing (see Dahiya ‘107, ¶¶3, 11, 44, 55).
As stated above, while Chung ‘407 discloses that the cryptographic key associated with the system architecture is stored in the hardware security module of the system architecture, Chung ‘407 in view of Dahiya ‘107 does not explicitly disclose that the storing of the cryptographic key in the hardware security module is performed “… by the second entity …”, as recited in claim 8.
Ballesteros ‘064, however, discloses:
… storing, by the second entity, the cryptographic key associated with the system architecture in the … of the system architecture (a system-on-chip (SOC) manufactured by an SOC manufacturer, where fuses of the SOC, such as field programmable fuses (FPF), store the public key or keys that the original equipment manufacturer (OEM) chooses or generates to verify code images executed on the SOC, and where the OEM public key is to be programmed at OEM manufacturing time and not at SOC manufacturing time so as to allow the OEM to decide what keys to use for their devices until they are ready; each OEM burns its respective values into the FPF of the SOC, in contrast to the public key of the SOC manufacturer, which is provisioned at SOC manufacturing time [Ballesteros ‘064, ¶¶11-13, 19, 21]) …
Chung ‘407 (modified by Dahiya ‘107) and Ballesteros ‘064 are analogous art because they are from the same field of endeavor, namely that of provisioning and managing cryptographic keys used to authenticate code images in system-on-chip devices. Prior to 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 Chung ‘407 (modified by Dahiya ‘107) and Ballesteros ‘064 before them, to modify the method in Chung ‘407 (modified by Dahiya ‘107) to include the teachings of Ballesteros ‘064, namely to have the second entity, rather than the manufacturer of the system architecture, program the cryptographic key associated with the system architecture into the system architecture at the time of the second entity’s own manufacturing operations, as disclosed in Ballesteros ‘064, such that the storing of the cryptographic key in the hardware security module of Chung ‘407 is performed by the second entity. A motivation for doing so would be to allow the second entity to decide what keys to use for its devices until it is ready, and to enable the second entity to retain control of the platform, such that in the event the private key associated with the provisioned cryptographic key is compromised, the second entity can revoke the compromised key and introduce a new key rather than losing control of the platform (see Ballesteros ‘064, ¶¶2, 12-14).
As per claim 9: Chung ‘407 in view of Dahiya ‘107, and further in view of Ballesteros ‘064 discloses all limitations of claim 8, as stated above, from which claim 9 is dependent upon. Chung ‘407 does not explicitly disclose the limitations of claim 9. Dahiya ‘107, however, discloses:
wherein the write-limited memory of the system architecture comprises one or more one-time programmable fuses (the ROM patch is stored in a one-time programmable (OTP) memory 108, where the OTP memory 108 comprises fuse bits, such as a ROM patch enable bit that is a fuse bit and a lock bit that is a fuse bit [Dahiya ‘107, ¶¶16-17]).
Chung ‘407 (modified by Ballesteros ‘064) and Dahiya ‘107 are analogous art because they are from the same field of endeavor, namely that of secure patching and firmware management for hardware systems. Prior to 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 Chung ‘407 (modified by Ballesteros ‘064) and Dahiya ‘107 before them, to modify the method in Chung ‘407 (modified by Ballesteros ‘064) to include the teachings of Dahiya ‘107, namely to implement the write-limited memory of the system architecture of Chung ‘407 using one-time programmable fuse bits, as disclosed in Dahiya ‘107. A motivation for doing so would be to utilize a well-known and reliable write-once storage mechanism that ensures the integrity and permanence of stored patch data, such that the patch data remains unalterable once programmed, thereby preventing unauthorized modification of the patch data after deployment (see Dahiya ‘107, ¶¶16-17).
As per claim 10: Chung ‘407 in view of Dahiya ‘107, and further in view of Ballesteros ‘064 discloses all limitations of claim 8, as stated above, from which claim 10 is dependent upon. Furthermore, Chung ‘407 discloses:
further comprising verifying the signature object of the patch management request based at least in part on a comparison of the signature object and the cryptographic key associated with the system architecture (the firmware updater 146 of the HSM 106 is configured to verify the second signature of the firmware package 108 by using the public key 118 stored in the HSM asset store 144, where verifying the second signature verifies the integrity and authenticity of the firmware package 108 [Chung ‘407, ¶¶32, 39, 47]).
As per claim 11: Chung ‘407 in view of Dahiya ‘107, and further in view of Ballesteros ‘064 discloses all limitations of claims 8 and 10, as stated above, from which claim 11 is dependent upon. Furthermore, Chung ‘407 discloses:
wherein the verifying the signature object of the patch management request is performed by the hardware security module (the firmware verifier 140 requests verification of the second signature of the firmware package 108 by the HSM 106, where the HSM 106 includes a firmware updater 146 that is configured to verify the second signature of the firmware package 108 by using the public key 118 stored in the HSM asset store 144 [Chung ‘407, ¶32]).
As per claim 13: Chung ‘407 in view of Dahiya ‘107, and further in view of Ballesteros ‘064 discloses all limitations of claim 8, as stated above, from which claim 13 is dependent upon. Furthermore, Chung ‘407 discloses
wherein the hardware security module comprises at least a portion of the (the HSM includes an HSM firmware region 450 and an HSM asset store 444 that store firmware and cryptographic keys, respectively, where the HSM firmware region and the HSM asset store are internal memory regions of the HSM [Chung ‘407, ¶¶20, 28-29, 54]).
As stated above, Chung ‘407 does not explicitly disclose the limitation “… write-limited memory.”
Dahiya ‘107, however, discloses:
wherein the … comprises at least a portion of the write-limited memory (the SoC 100 includes a one-time programmable (OTP) memory 108 that is configured to store the ROM patch, where the OTP memory 108 is part of the SoC 100 and comprises write-limited memory utilized for patching the ROM code [Dahiya ‘107, ¶¶12, 14, 16-17]).
Chung ‘407 (modified by Ballesteros ‘064) and Dahiya ‘107 are analogous art because they are from the same field of endeavor, namely that of secure patching and firmware management for hardware systems. Prior to 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 Chung ‘407 (modified by Ballesteros ‘064) and Dahiya ‘107 before them, to modify the method in Chung ‘407 (modified by Ballesteros ‘064) to include the teachings of Dahiya ‘107, namely to integrate the one-time programmable memory of Dahiya ‘107 within the hardware security module of Chung ‘407, such that the hardware security module comprises at least a portion of the write-limited memory. A motivation for doing so would be that locating the write-limited memory within the trusted security boundary of the hardware security module would provide enhanced physical protection against tampering and unauthorized access to the stored patch data, thereby improving the overall security of the patching process (see Dahiya ‘107, ¶¶16-17).
As per claim 14: Chung ‘407 in view of Dahiya ‘107, and further in view of Ballesteros ‘064 discloses all limitations of claim 8, as stated above, from which claim 14 is dependent upon. Furthermore, Chung ‘407 discloses:
wherein the patch management request comprises the patch code (the firmware package 108 comprises the firmware image 116, where the firmware image 116 is augmented with a header 132 that includes a first signature to provide an augmented firmware image 126, which is then encrypted and further augmented with a second signature to provide the firmware package 108 [Chung ‘407, ¶¶25-26]).
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Chung ‘407, in view of Dahiya ‘107, and further in view of Ballesteros ‘064, and further in view of Yan ‘819.
As per claim 12: Chung ‘407 in view of Dahiya ‘107, and further in view of Ballesteros ‘064 discloses all limitations of claim 8, as stated above, from which claim 12 is dependent upon. Chung ‘407 in view of Dahiya ‘107, and further in view of Ballesteros ‘064 does not explicitly disclose the limitations of claim 12. Yan ‘819, however, discloses:
further comprising deactivating one or more blocks of the write limited memory based at least in part on the patch management request (an OTP module comprising memory that can only be programmed once, where the memory comprises a plurality of regions, each region is dedicated to an individual key of a plurality of OTP keys, and where a key register stored in the OTP module comprises a plurality of status bits, each status bit mapped to an individual key of the plurality of OTP keys, such that when a status bit is burned, the corresponding key group is invalidated; burning a key status bit and a key group status bit to invalidate one or more key regions as part of a management operation, where the invalidated key regions are subsequently ignored during normal operation [Yan ‘819, ¶¶34-35, 38-39, 54, 61]).
Chung ‘407 (modified by Dahiya ‘107 and Ballesteros ‘064) and Yan ‘819 are analogous art because they are from the same field of endeavor, namely that of managing one-time programmable memory on a system-on-chip for secure operations. Prior to 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 Chung ‘407 (modified by Dahiya ‘107 and Ballesteros ‘064) and Yan ‘819 before them, to modify the method in Chung ‘407 (modified by Dahiya ‘107 and Ballesteros ‘064) to include the teachings of Yan ‘819, namely to implement the write-limited memory of Chung ‘407 to include a status bit register associated with each memory block, as disclosed in Yan ‘819, such that one or more blocks of the write-limited memory may be deactivated by burning the corresponding status bits as part of a patch management operation. A motivation for doing so would be to ensure that obsolete or revoked data stored in one or more regions of the write-limited memory is invalidated and subsequently ignored during normal operation, thereby preventing the reuse of outdated data and improving the security of the system (see Yan ‘819, ¶¶35, 38-39).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Liu et al., US 20240202341 A1: loading a patch on a flash memory of a system-on-chip (SoC); generating a patch key corresponding to the loaded patch using a cryptographic algorithm; reading a pre-determined authentication key from a one-time programmable (OTP) memory of the SoC; comparing the patch key with the authentication key.
Soenkens et al., US 11748275 B2: The control unit includes a host configured to execute an update program and at least one application program, a memory, which contains the programs and data, and a hardware security module (HSM) which is configured to block and to unblock a write access to the memory.
Ju, US 9904806 B2: storing user authentication information of the terminal transferred from the terminal to preregister a user of the terminal, transferring an authentication information request message, requesting the user authentication information, to the terminal in response to an update request message.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALAN L KONG whose telephone number is (571)272-2646. The examiner can normally be reached Monday-Friday 8:00am-4:30pm 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, JUNG (JAY) KIM can be reached on (571)272-3804. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of 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.
/ALAN L KONG/Examiner, Art Unit 2494
/KAVEH ABRISHAMKAR/Primary Examiner, Art Unit 2494
Prosecution Insights