DETAILED ACTION
Remarks
Applicant presents a communication dated 27 October 2025 in response to the 30 July 2025 non-final office action (the “Previous Action).
Claims 1, 2, 6, 12 and 15 are amended.
Claims 1-20 remain pending. Claims 1, 6 and 12 are the independent claims.
Any unpersuasive arguments are addressed in the “Response to Arguments” section below.
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 .
Examiner Notes
Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
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.
Allowable Subject Matter
Claim 2 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims and rewritten or amended to overcome the rejection(s) under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), 2nd paragraph, set forth in this Office action
Claim 6 would be allowable if rewritten or amended to overcome the rejection(s) under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), 2nd paragraph, set forth in this Office action.
Claims 7-11 would be allowable via dependence from claim 6.
Response to Arguments
Applicant argues with respect to claim 1 that Semerdhiev does not teach an empty sector indicator to indicate a number of empty sectors among the plurality of programmable sectors of the device firmware volume. Applicant reasons that merely having an empty field in a record when a particular file or folder is empty “does not indicate the number of empty sectors” and that Semerdhiev simply stores the file size instead. (Emphasis original) (Remarks, p. 10 par. 2 – p. 11 par. 3.
Examiner respectfully disagrees and submits that Semerdhiev does not merely store file sizes. As acknowledged by Applicant, uses empty fields to indicate that a folder has no files or subfolders. Such fields “indicate a number of empty sectors” at least in the sense that they indicate an empty folder. Such a folder is “a number of empty sectors” because it occupies space on the hard drive, i.e., one or more sectors, despite being empty. Merely “indicat[ing] a number of empty sectors does not require specifying an actual numeric value as implied by Applicant’s argument.
Applicant then argues with respect to claim 12 that Semerdhiev does not obtain sub-hash values in response to a determination that the hash value of the firmware update volume does not match the hash value of the device firmware volume. Applicant reasons that the sub-hash values of that Semerdhiev are obtained when building the index object 330. (Remarks, p. 16 par. 4 – p. 17 par. 3).
Examiner respectfully disagrees and points out that, as set forth in the Office action, Semerdhiev describes comparing file hashes (sub-hashes) of a current folder in block 1020 in response to determining that the hash value of the reference directory (device software volume) and the target directory (software update volume) do not match at 1015. (See Semerdhiev Fig. 10 and par. [0055]). The file hashes (sub-hashes) are implicitly obtained at that time in the sense that they are accessed as part of the comparison. They may be obtained when inserted into the index objects as well but his does not mean they are not also obtained when they are accessed from those objects. “[T]he indexes are intended to be read by a computer for comparing” them. (See Semerdhiev, par. [0047]).
Semerdhiev may not disclose that its software is firmware but it would have been obvious to modify that software to include firmware for the reasons set forth in the Office action.
Applicant’s arguments with respect to the remaining claims by virtue of their dependence from claims 1 and 12, similarity with claims 1 or 12 or dependence from a similar claim are unpersuasive for the same reasons.
Applicant’s arguments with respect to claims not rejected herein are moot.
Claim Rejections - 35 USC § 112
In view of Applicant’s amendments to the claims, the Previous Action’s § 112 rejections of are withdrawn unless reproduced herein.
13. 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.
Claim 2, 6-11 and 15 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 to claim 2, the claim refers to “the comparison of the sub-hash-value of the device firmware files to the sub-hash value of the updated firmware files for the empty sector.” There is insufficient antecedent basis for this limitation in the claim and it is unclear to which previously recited element, if any, the claim is referring. For the purposes of examination “the comparison of the sub-hash-value of the device firmware files to the sub-hash value of the updated firmware files for the empty sector” will be interpreted as “a comparison of a sub-hash-value of the device firmware files to a sub-hash value of the updated firmware files for the empty sector.”
As to claim 6, “the comparison of the sub-hash value of the device firmware files to the sub-hash value of the updated firmware files for the empty segment” language of this claim is indefinite for the same reasons as claim 2 and will be interpreted in the same manner.
As to claims 7-11, the claims are dependent on claim 7, do not cure the deficiencies of that claim and are rejected for the same reasons.
As to claim 15, the claim recites that the instructions are executable to verify the update responsive to the determining that “the hash value of the device firmware descriptor” matches “the hash value of the firmware update descriptor.” However, claim 12, from which claim 15 depends do not refer to any “hash value of the device firmware descriptor” or “hash value of the firmware update descriptor.” Claim 12 does refer to such descriptors respectively comprising “a hash value of a device firmware volume” and “a hash value of the firmware update volume” but p. 6 ll. 1-12 that claim also explicitly recites that those hash values “do[] not match.”
The hash values of claim 15 thus do not appear to be those previously recited in claim 12. “[T]he hash value of the device firmware descriptor” and “the hash value of the firmware update descriptor” of claim 15 thus lack antecedent basis and it is unclear which previously recited element, if any, the claim is referring.
For the purposes of examination, “the hash value of the device firmware descriptor” and “the hash value of the firmware update descriptor” will be construed as referring to different hash values than those recited in claim 12.
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.
Claims 1, 12, 14 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Semerdzhiev et al. (US 2005/0256864) (art of record – hereinafter Semerdzhiev) in view of Mangaiahgari (US 2015/0220318) (art of record – hereinafter Mangaiahgari) and Morgan et al. (US 2012/0131566) (art of record – hereinafter Morgan).
As to claim 1, Semerdzhiev discloses an electronic device, comprising:
a memory to store device software for the electronic device, the device software (e.g., Semerdzhiev, Fig. 13 and associated text [note too that software is necessarily stored in memory]) comprising:
a device software volume comprising a plurality of programmable sectors, the plurality of programmable sectors storing device software files (e.g., Semerdzhiev, Fig 2 and associated text [see the “reference directory” in the figure])
a device software descriptor corresponding to the device software, the device software descriptor comprising a hash value of the device software volume; (e.g., Semerdzhiev, par. [0040]: an index object [data structure] for reference directory 200B [device software volume, or comprising them]; Fig. 4 and associated text, par. [0032]: index object [data structure] includes a single top-level folder hash object 405 [and various others, see figure]; par. [0035]: the folder hash object may be generated based on some or all of the following inputs: (1) the files within the folder, (2) the subfolders within the folder) and a processing resource including a processor (e.g., Semerdzhiev, Fig. 13 and associated text ) to:
obtain a software update descriptor corresponding to the software update, the software update descriptor comprising a hash value of the software update; (e.g., Semerdzhiev, par. [0028]: an index is generated from target directory 200A; Fig. 4 and associated text, par. [0032]: index object [data structure] includes a single top-level folder hash object 405 [and various others, see figure]; par. [0035]: the folder hash object may be generated based on some or all of the following inputs: (1) the files within the folder, (2) the subfolders within the folder)
compare the hash value of the device software volume to the hash value of the software update volume; (e.g., Semerdzhiev, par. [0037]: index 340 may be inserted into a target version file for conveying information about target directory 200A. A similar index based on reference directory 200B may be inserted into a reference version file for comparison with the target version file; Fig. 10 and associated text, par. [0055]: In a process block 1010, the folder hashes of the current folder levels of both version files are compared. For the first loop through process 100, the current folder level is top-level folders 205. If folder hashes do not match (decision block 1015) then process 1000 continues to block 1020)
in response to a determination that the hash value of the device software volume does not match the hash value of the software update volume, obtain a plurality of sub-hash values corresponding to the device software files and a plurality of sub-hash values corresponding to the updated software files (e.g., Semerdzhiev, Fig. 10 and associated text, par. [0055]: if folder hashes do not match (decision block 1015) then process 1000 continues to block 1020. At block 1020, all file hashes [sub-hashes] of the current folder level are compared [which means they are obtained])
compare the plurality of sub-hash values of the device software files to the plurality of sub-hash values of the updated software files; (e.g., Semerdzhiev, Fig. 10 and associated text, par. [0055]: at block 1020, all file hashes [sub-hashes] of the current folder level are compared [which means they are obtained]) and
in response to a determination that the sub-hash value of a respective device software file does not match the sub-hash value of a corresponding updated software file, cause an update of the respective device software file based on the corresponding updated software file (e.g., Semerdzhiev, par. [0055]: in block 1020 all file hashes at the current folder level are compared. If one or more of the file hash values of targe directory 200A do not match the corresponding file hash values of reference directory 200B, then the non-matching files are noted for subsequent updating; par. [0056]: the non-matching files are updated in process block 1040; par. [0054]: updating contents of target directory 200A not matching contents of reference directory 200B; claim 2 updating the contents of the target directory to match the contents of the reference directory) and
an empty sector indicator to indicate a number of empty sectors among the plurality of programmable sectors of the device software volume; (e.g., Semerdzhiev, Fig. 4 and associated text, par. [0032]: as illustrated by the “X”, some file hash arrays and folder hash arrays may be empty; par. [0036]: if the current folder has no files, then field 515 would be empty. If the current folder has no subfolders, then field 520 would be empty [so an empty 515 and 520 field would indicate that the current folder (a number of sectors because this folder still occupies space) is empty]).
Semerdzhiev does not explicitly disclose firmware, to: receive a firmware update to update the device firmware for the electronic device, the firmware update comprising a firmware update volume comprising a plurality of updated firmware files respectively corresponding to the plurality of programmable sectors and on a sector-by-sector basis, and compare the plurality of sub-hash values of the device software files to the plurality of sub-hash values of the updated software files;
However, in an analogous art, Mangaiahgari discloses:
firmware; (e.g., Mangaiahgari, abstract: firmware files) and
to receive a firmware update to update the device firmware for the electronic device, the firmware update comprising a firmware update volume comprising a plurality of updated firmware files respectively corresponding to the plurality of programmable sectors; (e.g., Mangaiahgari, par. [0025]: the method of FIG. 2 may be used to communicate an update, such as a firmware update from a server to a panel; par. [0028]: an update to the panel’s firmware [device firmware]; par. [0014]: a firmware update may contain one or more files [so it is a firmware update volume]; par. [0034]: a full update may replace [correspond to] all or a large number of files [necessarily stored in sectors] at the panel).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the software and system of Semerdzhiev to include firmware and receiving a firmware update to update the device firmware for the electronic device, the firmware update comprising a firmware update volume comprising a plurality of updated firmware files respectively corresponding to the plurality of programmable sectors, as taught by Mangaiahgari, as Mangaiahgari would provide the advantage of a means of updating firmware files on the device. (See Mangaiahgari, parts. [0014], par. [0002]).
Further, in an analogous art, Morgan discloses to:
on a sector-by-sector basis, compare the plurality of sub-hash values of the device software files to the plurality of sub-hash values of the updated software files; (e.g., Morgan, par. [0034], the update component 114 can go through the list of old and new files and the component 114 will determine whether the file has changed with respect to the V1 package 122. This determination can be made by comparing the hashes of blocks [sectors] between the old and new file)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to file sub-hash comparison of Semerdzhiev/Mangaiahgari such that the files are compared on a sector-by-sector basis using sub-hash values of each block, as taught by Morgan, as Morgan would provide the advantage of a means of identifying changed blocks of the file, (see Morgan, par. [0032]), as well as a means of avoiding performing write operations for unchanged blocks. (See US 7,437,523 at col. 6 ll. 21-32).
As to claim 12, Semerdzhiev discloses a non-transitory computer-readable medium comprising instructions executable by a processing resource (e.g., Semerdzhiev, Fig. 13 and associated text, par. [0039]) to:
obtain a software update descriptor from the software update volume, the software update descriptor comprising a hash value of the software update volume (e.g., Semerdzhiev, claim 2 updating the contents of the target directory to match the contents of the reference directory; par. [0028]: an index is generated from target directory 200A; Fig. 4 and associated text, par. [0032]: index object [data structure] includes a single top-level folder hash object 405 [and various others, see figure]; par. [0035]: the folder hash object may be generated based on some or all of the following inputs: (1) the files within the folder, (2) the subfolders within the folder)
obtain a device software descriptor associated with the device software, the device software descriptor comprising a hash value of a device software volume of the memory of the computing device; (e.g., Semerdzhiev, claim 2 updating the contents of the target directory to match the contents of the reference directory; par. [0028]: an index is generated from target directory 200A; Fig. 4 and associated text, par. [0032]: index object [data structure] includes a single top-level folder hash object 405 [and various others, see figure]; par. [0035]: the folder hash object may be generated based on some or all of the following inputs: (1) the files within the folder, (2) the subfolders within the folder)
compare the hash value of the software update volume with the hash value of the device software volume; (e.g., Semerdzhiev, par. [0037]: index 340 may be inserted into a target version file for conveying information about target directory 200A. A similar index based on reference directory 200B may be inserted into a reference version file for comparison with the target version file; Fig. 10 and associated text, par. [0055]: In a process block 1010, the folder hashes of the current folder levels of both version files are compared. For the first loop through process 100, the current folder level is top-level folders 205. If folder hashes do not match (decision block 1015) then process 1000 continues to block 1020) and
in response to a determination that the hash value of the software update volume does not match the hash value of the device software volume, obtain a plurality of sub-hash values corresponding to a plurality of components of the software update and a plurality of sub-has values corresponding to a plurality of components of the device software (e.g., Semerdzhiev, Fig. 10 and associated text, par. [0055]: if folder hashes do not match (decision block 1015) then process 1000 continues to block 1020. At block 1020, all file hashes [sub-hashes] of the current folder level are compared [which means they are accessed for the comparison, i.e., obtained]; par. [0047]: the indexes are intended to be read by a computer for comparing)
compare the plurality of sub-hash values of the components of the software update to the plurality of sub-hash values of the components of the device software; (e.g., Semerdzhiev, Fig. 10 and associated text, par. [0055]: at block 1020, all file hashes [sub-hashes] of the current folder level are compared [which means they are obtained in the sense that they are accessed in to compare them]) and
in response to a determination that the sub-hash value of a respective component of the software update does not match the sub-has value of a corresponding component of the device software, cause an update of a programmable segment of the plurality of programmable sectors corresponding to the component of the device software (e.g., Semerdzhiev, par. [0055]: in block 1020 all file hashes at the current folder level are compared. If one or more of the file hash values of targe directory 200A do not match the corresponding file hash values of reference directory 200B, then the non-matching files are noted for subsequent updating; par. [0056]: the non-matching files [necessarily stored in programmable segments] are updated in process block 1040; par. [0054]: updating contents of target directory 200A not matching contents of reference directory 200B; claim 2 updating the contents of the target directory to match the contents of the reference directory).
Semerdzhiev does not explicitly disclose obtain a firmware update to update a device firmware within a memory of a computing device, the firmware update comprising a firmware update volume having a plurality of firmware files, the device firmware being stored in a plurality of programmable sectors; firmware; or to on a sector-by-sector basis, compare the plurality of sub-hash values of the components of the firmware update to the plurality of sub-hash values of the components of the device firmware;
However, in an analogous art, Mangaiahgari discloses:
obtain a firmware update to update a device firmware within a memory of a computing device, the firmware update comprising a firmware update volume having a plurality of firmware files, the device firmware being stored in a plurality of programmable sectors; (e.g., Mangaiahgari, par. [0025]: the method of FIG. 2 may be used to communicate an update, such as a firmware update from a server to a panel; par. [0028]: an update to the panel’s firmware [device firmware]; par. [0014]: a firmware update may contain one or more files [so it is a firmware update volume]; par. [0034]: a full update may replace [correspond to] all or a large number of files [necessarily stored in sectors] at the panel) and
firmware (see immediately above).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the software and system of Semerdzhiev to include firmware and obtaining a firmware update to update a device firmware within a memory of a computing device, the firmware update comprising a firmware update volume having a plurality of firmware files, the device firmware being stored in a plurality of programmable sectors, as taught by Mangaiahgari, as Mangaiahgari would provide the advantage of a means of updating firmware files on the device. (See Mangaiahgari, parts. [0014], par. [0002]).
Further, in an analogous art, Morgan discloses to:
on a sector-by-sector basis, compare the plurality of sub-hash values of the components of the software update to the plurality of sub-hash values of the components of the device software; (e.g., Morgan, par. [0034], the update component 114 can go through the list of old and new files and the component 114 will determine whether the file has changed with respect to the V1 package 122. This determination can be made by comparing the hashes of blocks [sectors] between the old and new file)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to file sub-hash comparison of Semerdzhiev/Mangaiahgari such that the files are compared on a sector-by-sector basis using sub-hash values of each block, as taught by Morgan, as Morgan would provide the advantage of a means of identifying changed non-matching blocks of the file, (See Morgan, par. [0032]), as well as a means of avoiding performing write operations for unchanged blocks. (See US 7,437,523 at col. 6 ll. 21-32).
As to claim 14, Semerdzhiev/Mangaiahgari/Morgan discloses the non-transitory computer-readable medium as claimed in claim 12 (see rejection of claim 12 above), Semerdzhiev further discloses: wherein the software update descriptor comprises a table signature (e.g., Semerdzhiev, Fig. 7 and associated text, par. [0046]: FIG. 7 is a table illustrating a version file 700 for storing one or more indexes; par. [0014]: an index object containing folder hash objects and file hash objects; par. [0028]: indexes may be used when updating a software product) but does not explicitly disclose firmware.
However, in an analogous art, Mangaiahgari discloses:
firmware; (e.g., Mangaiahgari, abstract: firmware files) and
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the software of Semerdzhiev to include firmware, as taught by Mangaiahgari, as Mangaiahgari would provide the advantage of a means of updating firmware files on the device. (See Mangaiahgari, parts. [0014], par. [0002]).
As to claim 18, Semerdzhiev/Mangaiahgari/Morgan discloses the electronic device as claimed in claim 1 (see rejection of claim 1 above) Semerdzhiev further discloses:
wherein to cause the update, (see below) the electronic circuitry (e.g., Semerdzhiev, par. [0013]) is to:
determine that a first sub-hash value associated with a first programmable sector of the plurality of programmable sectors of the device software volume is different from a second sub-hash value associated with a first updated software file of the plurality of updated software files of the software update volume; (e.g., Semerdzhiev, par. [0055]: in block 1020 all file [necessarily stored in one or more programmable sectors] hashes at the current folder level are compared. If one or more of the file hash values of targe directory 200A do not match the corresponding file hash values of reference directory 200B, then the non-matching files are noted for subsequent updating; par. [0056]: the non-matching files are updated in process block 1040; par. [0054]: updating contents of target directory 200A not matching contents of reference directory 200B; claim 2 updating the contents of the target directory to match the contents of the reference directory).and
cause the first programmable sector to be updated in accordance with the first updated software file (see immediately above).
Semerdzhiev does not explicitly disclose firmware.
However, in an analogous art, Mangaiahgari discloses:
firmware; (e.g., Mangaiahgari, abstract: firmware files) and
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the software of Semerdzhiev to include firmware, as taught by Mangaiahgari, as Mangaiahgari would provide the advantage of a means of updating firmware files on the device. (See Mangaiahgari, parts. [0014], par. [0002]).
Claims 3, 4, 13 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Semerdzhiev (US 2005/0256864) in view of Mangaiahgari (US 2015/0220318) in view of Morgan (US 2012/0131566) in further view of Smith et al. (US 2008/0126779) (art of record – hereinafter Smith).
As to claim 3, Semerdzhiev/Mangaiahgari/Morgan discloses the electronic device as claimed in claim 1 (see rejection of claim 1 above), and further discloses the device firmware volume (see rejection of claim 1 above) but does not explicitly disclose wherein the processing resource is to verify an integrity of the device firmware volume using the device firmware descriptor.
However, in an analogous art, Smith discloses:
wherein the processing resource is to verify an integrity of the device firmware using the device firmware descriptor (e.g., Fig. 1 and associated text, par. [0041]: end-user may re-measure the CRTM 132 and store the new CRTM has value in the policies of the TPM-NV 134; par. [0036]: the hash value of the measured CRTM 132 [firmware, see figure] is stored to allow the TPM to compare the measured hash value with the secure hash previously stored as a policy. Verification occurs if the two hashes match, such that the requesting CRTM 132 is deemed valid).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the device firmware volume and device firmware descriptor of that volume of Semerdzhiev/Mangaiahgari/Morgan by verifying the device firmware using the descriptor, as taught by Smith, as Smith would provide the advantage of a means of reducing concern that malicious code has entered the platform. (See Smith, par. [0012]).
As to claim 4, Semerdzhiev/Mangaiahgari/Morgan/Smith discloses: the electronic device as claimed in claim 3 (see rejection of claim 3 above), and further discloses the device firmware volume but Semerdzhiev/Mangaiahgari/Morgan does not explicitly disclose wherein the processing resource is to verify the integrity of the device firmware volume by comparing a current hash value of the device firmware volume to a previous hash value of the device firmware volume.
However, in an analogous art, Smith discloses:
wherein the processing resource is to verify the integrity of the device firmware by comparing a current hash value of the device firmware to a previous hash value of the device firmware (e.g., Fig. 1 and associated text, par. [0041]: end-user may re-measure the CRTM 132 and store the new CRTM has value in the policies of the TPM-NV 134; par. [0036]: the hash value of the measured CRTM 132 [firmware, see figure] is stored to allow the TPM to compare the measured hash value with the secure hash previously stored as a policy. Verification occurs if the two hashes match, such that the requesting CRTM 132 is deemed valid).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the device firmware volume and processing resource of of Semerdzhiev/Mangaiahgari/Morgan by verify the integrity of that firmware by comparing a current hash value of the firmware to a previous hash value of the firmware, as taught by Smith, as Smith would provide the advantage of a means of reducing concern that malicious code has entered the platform. (See Smith, par. [0012]).
As to claim 13, Semerdzhiev/Semerdzhiev/Morgan discloses the non-transitory computer-readable medium as claimed in claim 12 (see rejection of claim 12 above) and the hash value of the device firmware volume (see rejection of claim 12 above) but does not explicitly disclose wherein the instructions are executable by the processing resource to obtain the hash value of the device firmware volume from a hardware based-security module.
However, in an analogous art, Smith discloses
wherein the instructions are executable by the processing resource to obtain the hash value from a hardware based-security module; (e.g., Smith,: par. [0013]: TPM 104 [hardware-based security module] includes process control registers (PCRs) 136; par. [0033]: the ME 102 invokes the TPM 104 to measure a hash value of the CRTM 132; par. [0036]: the resulting hash of the measured CRTM 132 is stored in a PCR 136 to allow the TPM 104 to compare the measured hash with the secured hash previously stored as a policy in TPM-NV-132).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the hash value of the device firmware volume of Semerdzhiev/Semerdzhiev/Morgan to include obtaining the hash value from a hardware-based security module, as taught by Smith, as Smith would provide the advantages of a means of calculating and storing the hash value securely. (See Smith, pars, [0033], [0010]).
As to claim 20, Semerdzhiev/Semerdzhiev/Morgan/Smith discloses the non-transitory computer-readable medium as claimed in claim 13 (see rejection of claim 13 above) but Semerdzhiev/Semerdzhiev/Morgan does not explicitly disclose wherein the hardware-based security module comprises a trusted platform module (TPM).
However, in an analogous art, Smith discloses:
wherein the hardware-based security module comprises a trusted platform module (TPM) (e.g., Smith, par. [0009]: trusted platform module (TPM)).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the hash value of the device firmware volume of Ludwig/Chang to include obtaining the hash value of the device firmware from a TPM, as taught by Smith, as Smith would provide the advantages of a means of calculating and storing the hash value securely. (See Smith, pars, [0033], [0010]).
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Semerdzhiev (US 2005/0256864) in view of Mangaiahgari (US 2015/0220318) and Morgan (US 2012/0131566) in further view of Steshenko et al. (US 2017/0286093) (art of record – hereinafter Steshenko).
As to claim 5, Semerdzhiev/Mangaiahgari/Morgan discloses the electronic device as claimed in claim 1 (see rejection of claim 1), but does not explicitly disclose wherein processing resource is to generate the device firmware descriptor responsive to receiving a request for updating the device firmware.
However, in an analogous art, Steshenko discloses:
wherein the processing resource is to generate the device firmware descriptor responsive to receiving a request for updating the device firmware (e.g., Steshenko, par. [0061]: firmware update instructions 134 may request information about firmware stored in memory of the component. The information may include information to identify the firmware version, such as a hash value; par. [0129]: reader 22 may request information from components of reader 22 about firmware stored in memory of the component, such as hash value. Reader 22 may then generate a firmware manifest at step 513. The manifest generated at step 513 may include information about firmware stored in memory of any of the components).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the device firmware descriptor of Semerdzhiev/Mangaiahgari/Morgan such that it is generated on receiving a request for updating the device firmware, as taught by Steshenko, as Steshenko would provide the advantages of a means of generating that information only when it is needed and a means of providing most current firmware information. (See Steshenko, pars. [0102], [0109]).
Claims 15 is rejected under 35 U.S.C. 103 as being unpatentable over Semerdzhiev (US 2005/0256864) in view of Mangaiahgari (US 2015/0220318) and Morgan (US 2012/0131566) in further view of Ludwig (US 2014/0122862) (art of record – hereinafter Ludwig).
As to claim 15, Semerdzhiev/Mangaiahgari/Morgan discloses the non-transitory computer-readable medium as claimed in claim 12 (see rejection of claim 12), but does not explicitly disclose wherein the instructions are executable by the processing resource to verify the firmware update responsive to determining that the hash value of the device firmware descriptor matches the hash value of the firmware update descriptor.
However, in an analogous art, Ludwig discloses:
wherein the instructions are executable by the processing resource to verify the firmware update responsive to determining that the hash value of the device firmware descriptor matches the hash value of the firmware update descriptor (e.g., Ludwig, par. [0044]: update verifier 114b may verify that the hash of the current data “(e.g., the current version of the configuration component being updated)” matches the one required by the update “(i.e., the update data has metadata that includes a hash, and the update data hash has to match the hash of the current version of the configuration component, otherwise the update may not be installed)”; par. [0059]: the downloaded update may be verified by comparing the hash value in the configuration update metadata with a hash value in the metadata associated with a current version; par. [0019]: memory 104 may store configuration data, which may comprise firmware).
It would have been obvious to one of ordinary skill before the effective filing date of the claimed invention to modify the firmware update volume and device firmware volume of Semerdzhiev/Mangaiahgari/Morgan to include verifying the firmware update responsive to determining that the hash value of the device firmware matches the hash value of the firmware update, as taught by Ludwig, as Ludwig would provide the advantage of a means of ensuring the update is applicable to device firmware. (See Ludwig, par. [0044]).
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Semerdzhiev (US 2005/0256864) in view of Mangaiahgari (US 2015/0220318) and Morgan (US 2012/0131566) in view of Steshenko (US 2017/0286093) in further view of Smith (US 2008/0126779).
As to claim 16, Semerdzhiev/Semerdzhiev/Morgan/Steshenko discloses the electronic device as claimed in claim 5 (see rejection of claim 5 above) but Semerdzhiev/Semerdzhiev/Morgan does not explicitly disclose wherein, to generate the device firmware descriptor, the processing resource is to obtain the has value of the device firmware volume from a trusted platform module (TPM).
However, in an analogous art, Steshenko discloses:
wherein, to generate the device firmware descriptor the electronic circuitry is to obtain the hash value (e.g., Steshenko, par. [0129]: reader 22 may request information from components of reader 22 about firmware stored in memory of the component, such as hash value. Reader 22 may then generate a firmware manifest at step 513. The manifest generated at step 513 may include information about firmware stored in memory of any of the components).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the device firmware descriptor of Semerdzhiev/Semerdzhiev/Morgan/such that it is generated by obtaining a hash value, as taught by Steshenko, in order to generate a descriptor comprising such a value as suggested by Ludwig. (See Steshenko, par. [0129], Ludwig at par. [0044]).
Further, in an analogous art, Smith dislcloses:
to obtain the hash value of the device firmware volume from a trusted platform module (TPM) (e.g., Smith,: par. [0033]: the ME 102 invokes the TPM 104 to measure a hash value of the CRTM 132; par. [0036]: the resulting hash of the measured CRTM 132 is stored in a PCR 136 to allow the TPM 104 to compare the measured hash with the secured hash previously stored as a policy in TPM-NV-132).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the hash value of the device firmware volume of Semerdzhiev/Semerdzhiev/Morgan/Steshenko to include obtaining the hash value of the device firmware from a hardware-based security module, as taught by Smith, as Smith would provide the advantages of a means of calculating and storing the hash value securely. (See Smith, pars, [0033], [0010]).
Claim 17 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Semerdzhiev (US 2005/0256864) in view of Mangaiahgari (US 2015/0220318) and Morgan (US 2012/0131566) in further view of Brannock (US 2002/0194313).
As to claim 17, Semerdzhiev/Mangaiahgari/Morgan discloses the electronic device as claimed in claim 1 (see rejection of claim 1 above) but does not explicitly disclose wherein the memory comprises flash read-only memory (ROM).
However, in an analogous art, Brannock discloses:
wherein the memory comprises flash read-only memory (ROM) (e.g., Brannock, par. [0036]: it may be desirable to have all of the base portion of the platform firmware stored in flash ROM).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the firmware of Semerdzhiev/Mangaiahgari such that it is stored in flash ROM, as taught by Brannock, as a flash ROM would provide the advantage of a means of retaining data when power is off.
As to claim 19, it is a medium claim having limitations substantially the same as those of claim 1. Accordingly, it is rejected for substantially the same reasons.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any 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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TODD AGUILERA whose telephone number is (571)270-5186. The examiner can normally be reached M-F 11AM - 7:30PM EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Hyung S Sough can be reached at (571)272-6799. 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.
/TODD AGUILERA/Primary Examiner, Art Unit 2192