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 .
DETAILED ACTION
The response filed 1/28/2026 was received and considered (request for continued examination, filed 2/11/2026).
Claims 1-20 are pending.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114 (2/11/2026), including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 1/28/2026 has been entered.
Response to Arguments
Applicant's arguments filed 1/28/2026 have been fully considered but they are not persuasive.
Applicant’s remarks (p. 10) argue that:
“one of ordinary skill in the art would understand Eacmen top simple discuss the placement of extracted files into a queue. According to Eacmen, a queue is a temporary data structure for task management, not a persistent repository of newly organized, independent files created specifically for targeted analysis. Put simply, one of ordinary skill in the art would understand that Eacmen's system processes the original files, not newly generated ones”.
The Examiner respectfully disagrees. Eacmen discloses:
“The extractor 104 utilizes rule sets or other signatures to open the firmware image and inspect the firmware image to determine its contents. Broadly, the extractor 104 is configured to determine and extract files within the firmware image in a recursive manner. In some embodiments, extractor 104 scans a file for signatures (i.e. markers) of either a file or a file container. When those markers are found, the file is carved out of the file being scanned and the extractor 104 then continues to examine for more signatures in the file or the file container being scanned. For each carved file, it is then either extracted (if it was a file container), or if it was an individual file, it would then be added to the task queue 106 for analysis. For files that are extracted, the extractor 104 is re-run on extracted files in the event that there are file containers within file containers (hence the recursive functionality mentioned infra)” (Eacmen, ¶23),
“Once the discrete components (e.g., files) of the firmware image are located, the extractor 104 may extract the components and place them into the task queue 106 for further processing. In some embodiments, the firmware image can comprise components such as executable files, cryptographic hashes, passwords, and so forth” (Eacmen, ¶24),
“the analyzer 108 can be configured to obtain the files from the task queue 106 and perform at least one type of vulnerability analysis on the files (or a portion thereof)” (Eacmen, ¶31) and
“Once the one or more analyzers have performed their file analysis of the components of the firmware image, the log files are then stored in the database 110” (Eacmen, ¶32).
The Examiner respectfully submits that Eacmen teaches recursive extraction (extract files within the firmware image in a recursive manner, ¶32) and that the content items (Eacmen’s components) are stored in a plurality of separate, independent files (“file is carved out of the file being scanned”, ¶32, “For each carved file, it is then either extracted (if it was a file container), or if it was an individual file, it would then be added to the task queue 106 for analysis”, ¶32) and “discrete components (e.g., files)”, ¶24). Applicant’s remarks suggest that the disclosure of components in the task queue does not constitute files. However, Eacmen discloses storing the files in the task queue and further uses the language “discrete components (e.g., files)”, ¶24. The Examiner respectfully submits that an ordinarily-skilled artisan would have interpreted Eacmen’s teaching as falling within the scope of the claims.
Applicant’s remarks (p. 10) argue that “Shi has not been shown to account for these deficiencies in Eacmen”. However, as discussed with respect to the previous argument, Eacmen discloses this limitation.
Applicant’s remarks (p. 10) argue:
“Likewise, Zhou has not been shown to account for these deficiencies in Eacmen or Shi. One of ordinary skill in the art would interpret Zhou to discuss the creation of a single "disk image" from extracted executable files for a QEMU simulation environment… In contrast, amended claim 1 recites the creation of multiple, separate, independent files organized by data type outside of an emulation environment specifically for targeted testing algorithms. In short, amended claim 1 does not aim to create a singular disk image for a simulated boot process”.
The Examiner respectfully disagrees. As discussed with respect to the previous argument, Eacmen discloses this limitation. Further, the Examiner notes that Applicant’s recitation of “outside of an emulation environment specifically for targeted testing algorithms” and “create a singular disk image for a simulated boot process” are not recited in the claims.1
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 3, 5-6, 9, 11, 13-14, 16, 18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over US 2019/0294802 A1 to Eacmen et al. (Eacmen), in view of US 2020/0372107 A1 to Shi et al. (Shi).
Regarding claim 1, Eacmen discloses a computer-implemented method for security assessment, the method comprising: obtaining a source firmware file (firmware image is received, ¶23); recursively extracting content items (extractor 104 is configured to determine and extract files within the firmware image in a recursive manner, ¶23) from the source firmware file and storing a plurality of separate, independent files (components in task queue; “[for] each carved file, it is then either extracted (if it was a file container), or if it was an individual file, it would then be added to the task queue 106 for analysis”, ¶23) based on the extracted content items (extractor opens firmware image, ¶23, carves out files, ¶23 and adds the components to a task queue, ¶¶23-24), wherein each of the plurality of separate, independent files is of a respective data type of a respective content item from which the file is extracted (task queues represent components are a particular type, ¶25), wherein the respective data type is of a plurality of data types (discrete components extracted are of specific types, including executable files, cryptographic hashes, passwords, etc., ¶24); identifying sets of security test algorithms to be used for the security assessment of respective sets of files of the plurality of separate, independent files (analyzer 108 is utilized to process executables, ¶¶26-27; another example analyzer detects signing keys or passwords, ¶¶28-29), wherein each set of files is associated with content items of a same data type of the plurality of data types (extractor opens firmware image, ¶23, carves out files, ¶23 and adds the components to a task queue, ¶¶23-24, where components extracted are of specific types, including executable files, cryptographic hashes, passwords, etc., ¶24); executing a first set of the sets of security test algorithms (analyzers are executed, ¶26) over a respective first set of files of the plurality of separate, independent files (analyzer 108 is utilized to process executables, ¶¶26-27; another example analyzer detects signing keys or passwords, ¶¶28-29; one or more analyzers are launched to perform one or more types of vulnerability analysis on the components in the task queue, ¶¶24-25; components of firmware image are place in their own batch or group for analysis based on type, ¶25; analyzer 108 can analyze binary code of the files, ¶27; one analyzer can be configured to detect private signing keys in an IoT device firmware image, ¶28; examples of analyzers can be used to search and examine object code, drivers, and other binaries, ¶30; see also ¶45), wherein the first set of security test algorithms is identified as specific to a first data type associated with the first set of files (analyzer 108 is utilized to process executables, ¶¶26-27; another example analyzer detects signing keys or passwords, ¶¶28-29); evaluating test execution results obtained based on the executed first set of security test algorithms (results of analyzers are output to a log file in a database, ¶¶31-32); and providing a report for display at a display device (alerting module transmits message to manufacturer/customer, ¶34; system comprises a visual dashboard describing vulnerabilities, ¶50), the report comprising a security risk status for the source firmware file determined based on the evaluation (dashboard includes a gauge indicative of a relative risk level for an analyzed firmware image, ¶50). Eacmen teaches separate queues for separate component types (¶25) and examples of analyzers used for different component types (analyzer 108 is utilized to process executables, ¶¶26-27; another example analyzer detects signing keys or passwords, ¶¶28-29) and further teaches that the analyzers are selected based on the extracted files and their associated file types (claim 12), but lacks wherein each set of security test algorithms is specific to each data type associated with a respective set of files. However, Shi, in an analogous art (scanning files for malicious content, ¶2), teaches that it was known to utilize a plurality of file scanners to scan a set of file parts retrieved from a parts bucket (¶17), where each file scanner is specialized to handle the file parts of a specific file type (¶17; see also ¶19 and ¶21). Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Eacmen such that each set of security test algorithms is specific to each data type associated with a respective set of files. One of ordinary skill in the art would have been motivated to perform such a modification to enable specialized analyzers to handle particular types of files using specialized mechanisms and to enable parallel operation by the analyzers (Shi, Fig. 2), as taught by Shi.2
Regarding claim 9, the claim is similar in scope to claim 1 and is therefore rejected using a similar rationale (Eacmen discloses a non-transitory computer-readable medium (¶53) coupled to one or more processors (¶¶51-52) and having instructions stored thereon which, when executed by the one or more processors, cause the one or more processors to perform operations (¶60)).
Regarding claim 16, the claim is similar in scope to claim 1 and is therefore rejected using a similar rationale (Eacmen discloses a system comprising a computing device (¶¶51-52); and a computer-readable storage device coupled to the computing device (¶53) and having instructions stored thereon which, when executed by the computing device (¶54), cause the computing device to perform operations (¶60)).
Regarding claims 3, 11 and 18, Eacmen discloses wherein providing the report comprising: automatically generating the report based on one or more rules to structure and aggregate data provided from the evaluation of the test execution results (analyzers output log files, which are stored in a database, ¶32; logs can be associated with the firmware image, device identifier, version, ¶32; see also ¶48) and to generate the security risk status for the source firmware file (alerting module transmits message when vulnerability analysis indicates possible problem, ¶34; dashboard displays calculated risk level, ¶50); and providing the report as a file for downloading via interaction with the display (alert message includes identification of device, potential problem, ¶34; system reports vulnerability results to a visual dashboard, ¶50).
Regarding claims 5, 13 and 20, Eacmen, as modified, teaches wherein identifying the respective sets of security test algorithms (analyzers) comprises: analyzing each of the plurality of separate, independent files based on unique characteristics determined as related to a respective data type associated with one or more files of the plurality of separate, independent files (Eacmen discloses one or more analyzers are launched to perform one or more types of vulnerability analysis on the components in the task queue, ¶¶24-25; components of firmware image are place in their own batch or group for analysis based on type, ¶25; analyzer 108 can analyze binary code of the files, ¶27; one analyzer can be configured to detect private signing keys in an IoT device firmware image, ¶28; examples of analyzers can be used to search and examine object code, drivers, and other binaries, ¶30; see also ¶45, and, as modified, teaches where each file scanner is specialized to handle the file parts of a specific file type (as modified by Shi, ¶17; see also ¶19 and ¶21).
Regarding claims 6 and 14, Eacmen discloses wherein evaluating the test execution results comprises: identifying security alerts associated with at least one of the plurality of separate, independent files (alerting module transmits message when vulnerability analysis indicates possible problem, ¶34; alert message includes identification of device, potential problem, ¶34; system reports vulnerability results to a visual dashboard, ¶50).
Claims 2, 10 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Eacmen and Shi, as applied to claims 1, 9 and 16, in view of US 10484419 B1 to Davis et al. (Davis).
Regarding claims 2, 10 and 17, Eacmen discloses wherein extracting the content items from the source firmware file comprises: determining a list for discrete components identifiable by data type (components are extracted, ¶24, based on type, ¶24, and based on rule sets, ¶23) and extracting, based on the determined list, the discrete components from the source firmware file to be stored as the plurality of separate, independent files (once the components are located, extractor extracts components, ¶24), but lacks wherein the list includes data for each discrete component comprising a starting point, an offset, and description; and extracting, based on the determined list, the discrete components from the source firmware file to be stored as the plurality of separate, independent files. However, Davis, in an analogous art (classification of software modules within a piece of software, col. 5, lines 51-58), teaches that it was known to extract code fragments from an executable by parsing section headers to identify data sections using section flags and offsets from a starting address (col. 5, line 59 – col. 6, line 5). Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Eacmen such that the list includes data for each discrete component comprising a starting point (starting address), an offset (offsets to starting address), and description (section flags); and extracting, based on the determined list, the discrete components from the source firmware file to be stored as the plurality of separate, independent files. One of ordinary skill in the art would have been motivated to perform such a modification to utilize a known method of identifying and analyzing sections of software code, as taught by Davis.
Claims 4, 12 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Eacmen and Shi, as applied to claims 1, 9 and 16, in view of CN 115062309 A to Zhou et al. (Zhou).
Regarding claims 4, 12 and 19, Eacmen discloses wherein recursively extracting the content items from the source firmware file comprises: recursively extracting of components of the source firmware file (¶23), wherein one or more of the components are nested into a parent component of the components (files are extracted from containers recursively, ¶23), but lacks wherein the recursive extracting comprises determining whether the source firmware file is in a compressed form to execute decompression of the source firmware file to enable the recursive extraction. However, Zhou, in an analogous art (firmware analysis, ¶12), teaches that it was known to analyze firmware by acquiring the firmware (¶12) and perform firmware analysis (¶¶13-15), including determining whether the firmware has been compressed and, if so, performing decompression (¶23). Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Eacmen such that the recursive extracting comprises determining whether the source firmware file is in a compressed form to execute decompression of the source firmware file to enable the recursive extraction. One of ordinary skill in the art would have been motivated to perform such a modification to analyze compressed firmware, as taught by Zhou.3
Claims 7 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Eacmen and Shi, as applied to claims 1 and 9, in view of “OWASP FSTM” (stages 3-5) by Moreno et al. (Moreno).
Regarding claims 7 and 15, Eacmen lacks wherein evaluating the test execution results comprises: based on identifying security alerts associated with one or more files of the plurality of separate, independent files, mounting the plurality of separate, independent files as a filesystem at a local mount point to perform local audit of the filesystem, permissions, versions, and configuration files to determine security issues in the mounted filesystem. However, Moreno, in an analogous art (OWASP FSTM (Open Web Application Security Project), firmware analysis, p. 2), teaches that it was known to mount the plurality of separate, independent files (firmware) as a filesystem at a local mount point (mount to an analysis environment, p. 18, ¶5) to perform local audit of the filesystem (p. 18, ¶5), permissions (files with execution permissions, p. 38), versions (version messages, p. 14, ¶2, comparison of known file versions, p. 22, p. 41, ¶2), and configuration files (boot configuration, p. 31, BSD, files of interest, including configuration files, p. 38) to determine security issues in the mounted filesystem (OWASP firmware security testing, p. 31, ¶2). Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Eacmen such that evaluating the test execution results comprises: based on identifying security alerts associated with one or more files of the plurality of separate, independent files, mounting the plurality of separate, independent files as a filesystem at a local mount point to perform local audit of the filesystem, permissions, versions, and configuration files to determine security issues in the mounted filesystem. One of ordinary skill in the art would have been motivated to perform such a modification to utilize known methods and datasets for firmware security analysis, as taught by Moreno.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Eacmen, Shi and Moreno, as applied to claim 7, in view of “A Taxonomy of IoT Firmware Security and Principal Analysis Techniques” by Nadir et al. (Nadir).
Regarding claim 8, Eacmen, as modified, lacks wherein the determined security issues comprise misconfigurations in the filesystem related to setting permissions and/or insecure network communication channels. However, Nadir, in an analogous art (IoT firmware vulnerability analysis, §1 and Abstract), teaches that it was known to analyze firmware for vulnerabilities, including misconfigurations related to setting permission (permission leaks, p. 14, §Static Analysis Solutions) and insecure network communication channels (vulnerability related to SSL-encrypted communication channel, p. 8, §3.2 and vulnerability related to insecure network interfaces, p. 9, §3.5). Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to further modify Eacmen such that the determined security issues comprise misconfigurations in the filesystem related to setting permissions and/or insecure network communication channels. One of ordinary skill in the art would have been motivated to perform such a modification to analyze the firmware for permission leaks and communication vulnerabilities, as taught by Nadir.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
“Firmware dump extraction with binwalk and bsdtar” (Plough, Matthew) teaches using binwalk to recursively extract (p. 1) individual files (p. 9, ¶1) and making them available to analysis tools (p. 9, ¶1 and p. 10).
“Introduction to Binwalk – Firmware Analysis Tool – Penetration Testing” (Della Flora, Julio) teaches recursive extraction of data from firmware and creation of individual files (p. 3).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL J SIMITOSKI whose telephone number is (571)272-3841. The examiner can normally be reached on Monday - Friday, 7:00-3:00.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Carl Colin can be reached on 571-272-38623862. 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.
/Michael Simitoski/ Primary Examiner, Art Unit 2493
March 9, 2026
1 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).
2 US 20250013753 A1 (Conway; Eric) teaches an analysis system initializing pipelines based on the type of input data (¶39, ¶¶42-43 and ¶¶63-68).
3 Decompression of compressed firmware is taught in additional prior art (US 20230229417 A1 (Qian; Jing et al.), ¶¶60-64, CN 117454366 A (WANG, Yi-sen et al.), Abstract, CN 117494142 A (XU, Si-yao et al.), claim 3)