Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
This is in response to the amendments filed on 4/13/2026. Claims 10, 11, 12, and 14 have been amended. Claims 1-20 are currently pending and have been considered below.
Response to Arguments
Applicant's arguments filed 4/13/2026 have been fully considered but they are not persuasive. On page 3 of Remarks, Applicant asserts that “In view of this explicit technical distinction in the Specification, the claimed “scrambler module” cannot reasonably be equated with Moon’s symmetric-key FEK encryption processing unit” and “Because Moon describes cryptographic encryption rather than scrambling using a scrambler module, Moon fails to describe at least the element of “scramble the firmware image using a scrambler module to obtain a scrambled firmware image”…”. The examiner respectfully disagrees.
First, in response to Applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which Applicant relies (i.e., “… a scrambler as “a circuit or algorithm that is used to randomly rearrange or permute the bits of a digital signal in a NAND flash storage device” that operates using “a seed value to randomize cleartext data”, “… a scrambler … comprises “a linear function that produces a balanced number of ones and zeroes” based on “a non-cryptographic hash function, such as a Fowler-Noll-Vo (FNV) hash function””) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). In this instance, the examiner applied Broadest Reasonable Interpretation to the term “scrambler module” to mean “encryption module”, as the term “scrambler” in the cryptographic arts is generally synonymous with the term “encryption” (see Microsoft Computer Dictionary Fifth Edition, page 466 - “scrambler n. A device or program that reorders a signal sequence in order to render it indecipherable. See also encryption.”). The examiner recommends Applicant formally clarify their usage of the term “scrambler” and/or “scramble” in the claims in order to formally overcome the existing interpretation.
Second, Moon clearly teaches “scrambling” of a firmware image by “a scrambler module” via teachings in paragraph 104, where it’s taught that an original firmware image is encrypted via a firmware encryption processing unit. Again, if Applicant determines that aspects of Applicant’s Specification disclose features which would readily overcome Moon’s encryption of firmware via an encryption processing unit, then the examiner respectfully request Applicant to formally amend the claims to recite those features.
Therefore, in view of the above, the examiner maintains that Moon fully teaches and suggests “scramble the firmware image using a scrambler module to obtain a scrambled firmware image”, and thus the rejection is sustained.
On pages 3-4 of Remarks, Applicant asserts that “Moran’s “differential firmware update” is, by its own terms, a delta or difference between two firmware versions that describes what must change to move from an existing firmware version to a new firmware version. Generating such a difference is not scrambling. Scrambling, as the term is used in the present application and understood in the art of NAND flash memory devices, refers to permuting or randomizing the bits of a firmware image using a scrambler module such as a linear-function scrambler or an LDPC scrambler … Moran does not describe applying any scrambler module to a firmware image”, “… cryptographic encryption is distinct from the claimed scrambling operations”, and “Neither the differential generation nor the subsequent encryption operation in Moran constitutes scrambling a firmware image using a scrambler module”. The examiner respectfully disagrees.
Initially, in response to Applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which Applicant relies (i.e., “Scrambling, as the term is used in the present application and understood in the art of NAND flash memory devices, refers to permuting or randomizing the bits of a firmware image using a scrambler module such as a linear-function scrambler or an LDPC scrambler”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). In this instance, the examiner referred to Fig. 2 of Moran as providing teaching for the claimed system that is configured to “scramble the firmware image using a scrambler module”. Specifically, the examiner referred to paragraph 45 as detailing how at least one firmware image is retrieved and updated prior to being input into an encryption component 132. Paragraph 46 then describes that “After generating the output differential firmware update 130, the output differential firmware update 130 may be encrypted for deployment to the device 204”.
In other words, the examiner utilized teachings from paragraphs 45 and 46 to detail the entire process of generating a differential firmware update (i.e., a firmware image) and providing the generated differential firmware update to an encryption component for encryption. The examiner did not attempt to equate the generation of differential firmware as “scrambling”, as contended by Applicant. As the examiner noted above, encryption and scrambling of data are synonymous within the cryptographic arts, and thus the examiner referred to paragraph 46’s encryption component as being the claimed “scrambler module”, where the encryption of the differential firmware is the “scrambling” of firmware being performed.
Therefore, in view of the above, the examiner maintains that Moran fully teaches and suggests the claimed “scramble the firmware image using a scrambler module”, and thus the rejection is sustained.
On page 4 of Remarks, Applicant asserts that “Moran does not describe an “emulation platform” … Accordingly, Moran fails to describe at least the “emulation platform” configured to “scramble the firmware image using a scrambler module” recited in independent claim 1 and as similarly recited in independent claims 9 and 16”. The examiner respectfully disagrees.
In response to Applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which Applicant relies (i.e., “The present application describes an emulation platform as “a hardware emulation platform designed for the verification of digital circuits including memory device 106” that uses “programmable logic devices (PLDs) to implement the digital circuits being simulated” such that the PLDs can be “programmed to mimic the behavior of various types of digital logic gates, flip-flops, and other components, allowing users to create a faithful emulation of the target circuit” and “The emulation platform thus executes an emulated memory device that mirrors a target memory device and that includes an emulated scrambler corresponding to a counterpart descrambler on the actual memory device”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). In this instance, the examiner interpreted the “emulation platform” as how it functions within the claim (e.g., a platform that is configured to receive a firmware image, scramble the firmware image, and transmit the scrambled firmware image). If Applicant intends for the “emulation platform” to refer to something beyond what is merely claimed, then the examiner respectfully requests Applicant formally clarify the “emulation platform” via limitations derived from the Specification in order to potentially overcome the examiner’s current interpretation.
Therefore, because the independent claims fail to further limit the “emulation platform” in a manner that includes the limitations as argued by Applicant, the examiner maintains that Moran fully teaches and suggests an “emulation platform” that is equivalent to what is claimed, and thus the rejection is sustained.
On pages 5 and 6 of Remarks, Applicant asserts that “However, Guo’s teaching of an LDPC scrambler in isolation does not supply Moran’s missing “scrambler module” operating on a firmware image within an emulation platform. Modifying Moran’s differential firmware update component or its cryptographic encryption step by substituting in a NAND-style LDPC scrambler would not result in the claimed invention, and the Examiner has articulated no rationale explaining how such a modification would be consistent with Moran’s differential-update architecture”. The examiner respectfully disagrees.
First, and as noted above, Moran’s “Encryption Component” (Fig. 2, element 132) is being interpreted as the claimed “scrambler module”, and thus the LDPC scrambler as taught by Guo is not being considered in isolation, as purported by Applicant. Instead, the combination is built around the broad interpretation of the claimed “scrambler module” and the existing mapping of Moran’s encryption component to said module.
Second, the examiner provided sufficient teaching, suggestion, and motivation to combine Guo’s LDPC scrambler with the encryption (scrambler) component of Moran by stating that “The motivation is to provide an LDPC encoder which can shorten seed data used to scramble data, resulting in fewer bytes being stored and thus conserving storage resources”. As Applicant did not refute this motivation statement, and instead relied upon the original unpersuasive argument concerning Moran’s encryption component being the claimed “scrambler module”, the examiner maintains that the combination of Guo to Moran would have been obvious to one with ordinary skill in the art prior to the effective filing date of the claimed invention.
Therefore, the examiner maintains that the combination of Moran and Guo fully teaches and suggests the limitations of claims 8, 10, and 18, and thus these rejections are sustained as below.
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 further comprises scrambling the firmware image using a low-density parity check (LDPC) scrambler.
Guo teaches:
… wherein scrambling the firmware image using an emulated scrambler further 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 identifier 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 identifier 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 identifier of the at least one memory device comprises extracting an identifier 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).
Conclusion
THIS ACTION IS MADE FINAL. 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 nonprovisional extension fee (37 CFR 1.17(a)) 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 mailing date of this final action.
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
Prosecution Insights