DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after 16 March 2013, is being examined under the first inventor to file provisions of the AIA .
This action is in reply to papers filed on 06 November 2024. Claims 1, 8, 15, and 18 are independent. Claims 1-20 are pending.
Priority
Acknowledgment is made of Applicant’s claim for domestic benefit priority of U.S. Provisional Application Serial No. 63/547,836, filed 08 November 2023.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 06 November 2024 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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 § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 5-6 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
As per claims 5-6:
Claims 5-6 recite: “… the second identification value ...”. The term “the second identification value” make the claims indefinite as it lacks proper antecedent basis.
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.
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; and where the HSM 200 determines whether the access control list (ACL) 214 associated with the cryptographic key 120 of the request is authorized to govern access to the cryptographic key; both conditions must be satisfied before processing the request [Stahlberg ‘311, ¶¶4-5, 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 the 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 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 discloses all limitations of claim 1, 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 and Stahlberg ‘311) 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 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 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 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, and Zaidi ‘313) 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, and Zaidi ‘313) and Shuf ‘815 before them, to modify the method in Dahiya ‘107 (modified by Chung ‘407, Stahlberg ‘311, and Zaidi ‘313) 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.
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 [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) [Chung ‘407, ¶¶44, 46]);
storing the cryptographic key associated with the system architecture in the hardware security module of the system architecture (the second public key of the second public private key pair is stored in the HSM asset store 144, which is stored in a secure memory of the HSM 106; the associated public key of the other public private key pair is stored in a system configuration (SCFG) region and is copied to the HSM asset store 144 [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, 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 with an HSM, where a third-party entity generates cryptographic keys and signs the firmware package, Chung ‘407 does not explicitly disclose that the memory is “… 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 per claim 9: Chung ‘407 in view of Dahiya ‘107 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 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 and Dahiya ‘107 before them, to modify the method in Chung ‘407 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 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 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 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 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 and Dahiya ‘107 before them, to modify the method in Chung ‘407 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 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 Yan ‘819.
As per claim 12: Chung ‘407 in view of Dahiya ‘107 discloses all limitations of claim 8, as stated above, from which claim 12 is dependent upon. Chung ‘407 in view of Dahiya ‘107 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 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 Yan ‘819 before them, to modify the method in Chung ‘407 (modified by Dahiya ‘107) 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.
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-Thursday 9:00am-7:00pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, 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
/JUNG W KIM/Supervisory Patent Examiner, Art Unit 2494