Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Specification
The disclosure is objected to because of the following informalities:
Paragraph 25 recites “identifying an identify” which should be changed to --identifying an identifier--.
Paragraph 26 recites “identifying an identify” and “extracting an identify” which should be changed to --identifying an identifier-- and --extracting an identifier--.
Appropriate correction is required.
Claim Objections
Claims 10, 11, 12, and 14 are objected to because of the following informalities:
Claim 10, lines 2-3 recites “comprises scrambling the firmware image comprises scrambling the firmware image using a low-density parity check (LDPC) scrambler” which should be changed to --further comprises scrambling the firmware image using a low-density parity check (LDPC) scrambler--.
Claim 11, line 2 recites “identify” which should be changed to --identifier--.
Claim 12, lines 1 and 2 each recite “identify” which should be changed to --identifier--.
Claim 14, lines 2-4 recites the limitation “comprising transmit the scrambled firmware image to the at least one memory device by transmitting the scrambled firmware image to an update server” which should be changed to --further comprising transmitting the scrambled firmware image to an update server--.
Appropriate correction is required.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1, 2, 9, and 16 is/are rejected under 35 U.S.C. 102(a)(1) & (a)(2) as being anticipated by “Moon” (US 2019/0163910).
Regarding Claim 1:
A system (Fig. 1) comprising:
a firmware generator (¶0055, “The service provider provides … firmware (or an operating system… to be loaded and operated in the service device 1 as binary code or an executable file…”);
a memory device (Fig. 1, element 1; Fig. 14); and
an emulation platform (Fig. 4, element 3), the emulation platform configured to:
receive a firmware image from the firmware generator (¶0055, “The service provider provides … firmware…”),
scramble the firmware image using a scrambler module to obtain a scrambled firmware image (¶0104, “The firmware encryption processing unit 322 encrypts the original firmware image using the symmetric key FEK generated by the symmetric key generation processing unit 321. Thus, an encrypted firmware image is produced as a result”), and
transmit the scrambled firmware image to the memory device (¶0065, “… and inserts the encrypted firmware image into a flash memory specific area of a service device”).
Regarding Claim 2:
The system of claim 1, wherein the memory device is configured to:
receive the scrambled firmware image (¶0065, “… and inserts the encrypted firmware image into a flash memory specific area of a service device”);
descramble the scrambled firmware image using a descrambler circuit to obtain a descrambled firmware image (¶0069, “The secure memory loader of the service device 1 extracts key data, verifies the validity of the extracted key data, and decrypts the encrypted firmware stored in the specific area of the flash memory…”); and
install the descrambled firmware image (¶0070, “When firmware security verification is normally completed, the firmware loading procedure is performed”).
Regarding Claim 9:
Method claim corresponds to system claim 1 and contains no further limitations. Therefore claim 9 is rejected by applying the same rationale used to reject claim 1 above.
Regarding Claim 16:
A memory device (Fig. 1, element 1; Fig. 14) comprising:
a storage area configured for storing firmware images (¶0065, “… a flash memory specific area of a service device”); and
a controller (Fig. 14, elements 111, 112, and 113) configured to:
receive a scrambled firmware image (¶0065, “… and inserts the encrypted firmware image into a flash memory specific area of a service device”),
descramble the scrambled firmware image to obtain a descrambled firmware image (¶0069, “The secure memory loader of the service device 1 extracts key data, verifies the validity of the extracted key data, and decrypts the encrypted firmware stored in the specific area of the flash memory…”), and
install the descrambled firmware image in the storage area (¶0070, “When firmware security verification is normally completed, the firmware loading procedure is performed”).
Claim(s) 1, 2, 5-7, 9, 13, 14, 16, 17, 19, and 20 is/are rejected under 35 U.S.C. 102(a)(1) & (a)(2) as being anticipated by “Moran” (US 2022/0113960).
Regarding Claim 1:
A system (Fig. 2) comprising:
a firmware generator (Fig. 2, element 118);
a memory device (Fig. 2, element 204); and
an emulation platform (Fig. 2, element 112), the emulation platform configured to:
receive a firmware image from the firmware generator (Fig. 2, element 124 represents a firmware portion that is generated via authorizing entity 118 as disclosed in ¶0041),
scramble the firmware image using a scrambler module to obtain a scrambled firmware image (¶0045, “A differential firmware update component 128 of the trusted execution environment 112 generates an output differential firmware update 130 using the plurality of decrypted versions of the firmware portion 126”), and
transmit the scrambled firmware image to the memory device (¶0046, “After generating the output differential firmware update 130, the output differential firmware update 130 may be encrypted for deployment to the device 204”).
Regarding Claim 2:
The system of claim 1, wherein the memory device is configured to:
receive the scrambled firmware image (¶0047, “The firmware update service 206 sends the encrypted differential firmware update 134 to the device 204”);
descramble the scrambled firmware image using a descrambler circuit to obtain a descrambled firmware image (¶0047, “The encrypted differential firmware update 134 is decrypted …The encrypted differential firmware update 134 may be decrypted by the device 204…”); and
install the descrambled firmware image (¶0047, “… and an update client on the device replaces the part(s) of the firmware portion to be modified with the modified part(s) indicated by the differential firmware update”).
Regarding Claim 5:
The system of claim 1, wherein the emulation platform is further configured to validate the scrambled firmware image using an emulated descrambler module (¶0038, “… the authorizing entity 118 sends at least one key 120 to a decryption component 122 within the trusted execution environment 112. In this way, the authorizing entity 118 authorizes the trusted execution environment 112 to generate the output differential firmware update”).
Regarding Claim 6:
The system of claim 1, wherein the emulation platform is configured to transmit the scrambled firmware image to the memory device by transmitting the scrambled firmware image to an update server (¶0047, “In the method 110 of FIG. 2, the encrypted differential firmware update 134 is sent to the firmware update service 206 for deployment to the device 204 … The firmware update service 206 sends the encrypted differential firmware update 134 to the device 204”).
Regarding Claim 7:
The system of claim 1, wherein the emulation platform is configured to transmit the scrambled firmware image to the memory device by transmitting the scrambled firmware image to the firmware generator (¶0048, “In another example, the encrypted differential firmware update may be output from the trusted execution environment to a different entity before deployment to the device. For example, FIG. 3 is a schematic diagram showing a method 136 of generating an output differential firmware update for updating firmware associated with a device 304 according to further examples”; i.e., Fig. 3 details the encrypted firmware portion being sent to the authorizing entity, which generated the firmware portion, prior to sending the encrypted firmware portion (element 135) to the device 304).
Regarding Claims 9, 13, and 14:
Method claims 9, 13, and 14 correspond to respective system claims 1, 5, and 6, and contain no additional limitations. Therefore claims 9, 13, and 14 are rejected by applying the same respective rationale used to reject claims 1, 5, and 6 above, respectively.
Regarding Claim 16:
A memory device (Fig. 2, element 204) comprising:
a storage area configured for storing firmware images (¶0023, “Each of the set of devices 104 may for example include … memory which may for example be non-volatile flash memory. In one example, the memory stores code including a bootloader, a metadata header and an active firmware image. The active firmware image currently running on the device may be stored in an active image slot in the memory. The memory may also further include a spare image slot for storing a replacement firmware image during a firmware update procedure”); and
a controller (¶0023, “Each of the set of devices 104 may for example include processing circuitry in the form of a microcontroller…”) configured to:
receive a scrambled firmware image (¶0047, “The firmware update service 206 sends the encrypted differential firmware update 134 to the device 204”),
descramble the scrambled firmware image to obtain a descrambled firmware image (¶0047, “The encrypted differential firmware update 134 is decrypted …The encrypted differential firmware update 134 may be decrypted by the device 204…”), and
install the descrambled firmware image in the storage area (¶0047, “… and an update client on the device replaces the part(s) of the firmware portion to be modified with the modified part(s) indicated by the differential firmware update”).
Regarding Claim 17:
The memory device of claim 16, wherein the controller is configured to descramble the scrambled firmware image by inputting the scrambled firmware image to a descrambler circuit (¶0047, “The encrypted differential firmware update 134 is decrypted …The encrypted differential firmware update 134 may be decrypted by the device 204…”; ¶0088, “Each of these components may be implemented using machine readable instructions and suitably programmed or configured hardware, such as circuitry. Each of these components can include a microprocessor, microcontroller, processor module or subsystem, programmable integrated circuit, programmable gate array or other computing device”).
Regarding Claim 19:
The memory device of claim 16, wherein the controller is further configured to validate the descrambled firmware image prior to installing the descrambled firmware image (¶0092, “If the device receives a signed message (e.g. signed by the signing component 174 using the signing key), the device can for example compute a digest of the message and then use a corresponding public key to decrypt the signature and compare the resulting digest to the digest it has already computed. in this way, the device can determine whether the differential firmware update has been modified or replaced since being generated within the trusted execution environment. If digests match, the device may install the differential firmware update.”).
Regarding Claim 20:
The memory device of claim 16, wherein the controller is configured to receive the scrambled firmware image via a firmware update command (¶0034, “The trusted execution environment 112 may periodically check for the availability of new version of the firmware portion, e.g. by querying the authorizing entity 118 and/or the firmware update service 206, and may instigate the generation of the output differential firmware update if a new version of the firmware portion is available”; i.e., the examiner interprets such queries as a command corresponding to a firmware update).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, 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.
Claim(s) 3 and 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Moran” (US 2022/0113960) in view of “Caceres” (US 2020/0366653).
Regarding Claim 3:
Moran teaches:
The system of claim 1, …
Moran does not disclose:
… wherein the emulation platform is further configured to load an emulated memory device corresponding to the memory device.
Caceres teaches:
… wherein the emulation platform is further configured to load an emulated memory device corresponding to the memory device (Fig. 2; ¶0021, “… the client device may establish a session with a particular compute node in the set of compute nodes. For example, the session may be established to execute a virtualized desktop environment or to offload another suitable application workload from the client device to the compute node”; ¶0049, “Virtualized storage 245-3 includes one or more storage systems and/or one or more devices that use virtualization techniques within the storage systems or devices of computing resource 245”).
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to modify Moran’s firmware update system by enhancing Moran’s emulation platform to include virtualization of a storage area corresponding to a storage area on a client device, as taught by Caceres, in order to provide a trusted environment isolated from the client device.
The motivation is to provide a virtualized storage environment for offloading data processing onto in a manner which supports data security and conservation of computing resources of a client device (Caceres, ¶0008).
Regarding Claim 4:
The system of claim 3, wherein Moran in view of Caceres further teaches the scrambler module comprises an emulated scrambler circuit (Caceres, ¶0066, “the computing device … may secure communication between a local operating system executing on the client device and the virtualized environment instantiated in the trusted execution environment using the one or more cryptographic keys…”) corresponding to a physical descrambler circuit of the memory device (Caceres, ¶0016, “… the client device may include a secure element to securely store one or more cryptographic keys…”; ¶0017, “As shown in FIG. 1B, the cryptographic keys stored in the corresponding HSM can be used to encrypt data to be transmitted to the client device and to decrypt data to be processed by the TEE, which may provide various isolation mechanisms to ensure that plaintext or cleartext data is not accessible in the compute node”; ¶0058, “Additionally, or alternatively, hardware circuitry may be used in place of or in combination with software instructions to perform one or more processes described herein”).
The motivation to combine Caceres to Moran for the rejection of claim 4 is the same motivation cited for the rejection of claim 3 above.
Claim(s) 8, 10, and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Moran” (US 2022/0113960) in view of “Guo” (US 2022/0083419).
Regarding Claim 8:
Moran teaches:
The system of claim 1, …
Moran does not disclose:
… wherein the scrambler module comprises a low-density parity check (LDPC) scrambler.
Guo teaches:
… wherein the scrambler module comprises a low-density parity check (LDPC) scrambler (Fig. 2 depicts a scrambler circuit comprising a LDPC encoder).
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to modify Moran’s firmware update system by enhancing Moran’s scrambler to include a low-density parity check element, as taught by Guo, in order to shorten seed data associated with the scrambler.
The motivation is to provide an LDPC encoder which can shorten seed data used to scramble data, resulting in fewer data bytes being stored (Guo, ¶0015) and thus conserving storage resources.
Regarding Claim 10:
Moran teaches:
The method of claim 9, …
Moran does not disclose:
… wherein scrambling the firmware image using an emulated scrambler comprises scrambling the firmware image comprises scrambling the firmware image using a low-density parity check (LDPC) scrambler.
Guo teaches:
… wherein scrambling the firmware image using an emulated scrambler comprises scrambling the firmware image comprises scrambling the firmware image using a low-density parity check (LDPC) scrambler (Fig. 2 depicts a scrambler circuit comprising a LDPC encoder).
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to modify Moran’s firmware update system by enhancing Moran’s scrambler to include a low-density parity check element, as taught by Guo, in order to shorten seed data associated with the scrambler.
The motivation is to provide an LDPC encoder which can shorten seed data used to scramble data, resulting in fewer data bytes being stored (Guo, ¶0015) and thus conserving storage resources.
Regarding Claim 18:
Moran teaches:
The memory device of claim 17, …
Moran does not disclose:
… wherein the descrambler circuit comprises a low-density parity check (LDPC) descrambler.
Guo teaches:
… wherein the descrambler circuit comprises a low-density parity check (LDPC) descrambler (Fig. 3 depicts a descrambler circuit comprising a LDPC decoder).
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to modify Moran’s firmware update system by enhancing Moran’s descrambler to include a low-density parity check element, as taught by Guo, in order to shorten seed data associated with a scrambler.
The motivation is to provide an LDPC element which can shorten seed data used to descramble data, resulting in fewer data bytes being stored (Guo, ¶0015) and thus conserving storage resources.
Claim(s) 11 and 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Moran” (US 2022/0113960) in view of “Suryanarayana” (US 2023/0401316).
Regarding Claim 11:
Moran teaches:
The method of claim 9, …
Moran does not disclose:
… wherein receiving the firmware image comprises identifying an identify of the at least one memory device and loading a corresponding emulated memory device that includes the emulated scrambler.
Suryanarayana teaches:
… wherein receiving the firmware image comprises identifying an identify of the at least one memory device (¶0026, “For example, virtual BIOS engine 110 may dynamically measure, during operating system runtime, a firmware payload prior to update and tag measurement identifiers to cryptoprocessor 108 for the actual update”; i.e., tag identifiers that correspond to respective components of a device) and loading a corresponding emulated memory device that includes the emulated scrambler (Abstract, “A virtual BIOS engine may be configured to, during runtime of an operating system, in response to an operating system event for updating firmware, load onto an isolated compute domain of the processor to emulate firmware update processes of a non-transitory computer-readable media with a virtual non-transitory computer-readable media and emulate the firmware update processes of the cryptoprocessor with a virtual cryptoprocessor…”).
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to modify Moran’s firmware update system by enhancing Moran’s system to tag component identifiers from firmware for an emulated cryptoprocessor, as taught by Suryanarayana, in order to perform attestation of the firmware prior to installation in a client device.
The motivation is to provide an emulated environment, including a virtual cryptoprocessor, that is configured to extract measurement identifiers corresponding to device components from firmware in order to perform an attestation of the firmware using the identifiers. Such attestation ensures that the firmware was not modified prior to being installed and executed on a client device, which enhances the overall security of the client device (Suryanarayana, ¶0005, “Attestation of the firmware measurements collected by an RTM may provide the foundation for assurance that firmware is secure”).
Regarding Claim 12:
The method of claim 11, wherein Moran in view of Suryanarayana further teaches identifying an identify of the at least one memory device comprises extracting an identify of the at least one memory device from the firmware image (Suryanarayana, ¶0033, “Firmware measurement protocol 214 may extract a firmware payload representing a firmware update into virtual SPI flash and perform a firmware measurement as a virtual RTM…”).
The motivation to combine Suryanarayana to Moran for the rejection of claim 12 is the same motivation used for the rejection of claim 11 above.
Claim(s) 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Moran” (US 2022/0113960) in view of “Marx” (US 2023/0273788).
Regarding Claim 15:
Moran teaches:
The method of claim 9, …
Moran does not disclose:
… wherein the firmware image comprises a binary image, the binary image included one of a password, key, special string, or overlay data.
Marx teaches:
… wherein the firmware image comprises a binary image (Fig. 4 comprising Fig. 3; ¶0016, “… an independent binary, the so-called manifest, of the firmware update package”), the binary image included one of a password, key (¶0017, “Advantageously, the manifest also contains the hash value about the binary of the firmware in addition to the public key…”), special string, or overlay data.
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to modify Moran’s firmware update system by enhancing Moran’s firmware to include a binary manifest including a public key, as taught by Marx, in order to provide means to validate the trusted origin of the public key and of corresponding firmware at the same time.
The motivation is to enhance verification of a received firmware package by packaging a manifest file having a public key so that verification of both the public key and firmware can be done simultaneously (Marx, ¶0017).
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DANIEL B POTRATZ whose telephone number is (571)270-5329. The examiner can normally be reached on M-F 10 A.M. - 6 P.M. CST.
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, William Korzuch can be reached on 571-272-7589. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/DANIEL B POTRATZ/Primary Examiner, Art Unit 2491