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 6/16/2026 was received and considered.
Claims 1-20 are pending.
Response to Arguments
Applicant's arguments filed 6/16/2026 have been fully considered but they are not persuasive.
Applicant’s remarks (p. 12, regarding rejections of independent claims under 35 U.S.C. §103) suggest that:
“Eacmen fails to teach claim 1 as amended, and in particular fails to teach "sorting a plurality of independent files into groups" let alone "wherein the sorting is based on the respective data type of each independent file of the plurality of independent files, wherein each group is associated with a respective data type; selecting at least one security test algorithm from sets of security test algorithms to be used for a security assessment of independent files in at least one group of the groups based on the respective data type of the at least one group; executing the at least one security test algorithm over the independent files in the at least one group;" Shi fails to cure the deficiencies of Eacmen”.
The Examiner respectfully disagrees. While Eacmen teaches utilizing different scanners to different portions of a firmware file, the reference lacks explicitly sorting the plurality of independent files into groups, wherein the sorting is based on the respective data type of each independent file of the plurality of independent files, wherein each group is associated with a respective data type and selecting an algorithm to be used for a security assessment of independent files in at least one group of the groups based on the respective data type of the at least one group. 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), including sorting the plurality of independent files into groups, wherein the sorting is based on the respective data type of each independent file of the plurality of independent files, wherein each group is associated with a respective data type (Fig. 2, groups represented by buckets 114; see also ¶19) and selecting an algorithm to be used for a security assessment of independent files in at least one group of the groups based on the respective data type of the at least one group (Fig. 2, represented by workers 108; see also ¶19). Therefore, the Examiner respectfully maintains that 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 to include sorting the plurality of independent files into groups, wherein the sorting is based on the respective data type of each independent file of the plurality of independent files, wherein each group is associated with a respective data type and selecting an algorithm to be used for a security assessment of independent files in at least one group of the groups based on the respective data type of the at least one group to enable specialized analyzers to handle particular types of files using specialized mechanisms and to enable parallel operation by the analyzers, as taught by Shi.
Applicant’s remarks (pp. 12-13, regarding rejections of dependent claims under 35 U.S.C. §103) refer to remarks related to the independent claims. Therefore, the Examiner references the response provided with respect to claim 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; storing a plurality of 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 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; 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), 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); selecting at least one security test algorithm from sets of security test algorithms to be used for a security assessment of independent files (analyzer 108 is utilized to process executables, ¶¶26-27; another example analyzer detects signing keys or passwords, ¶¶28-29); executing the at least one security test algorithm (analyzers are executed, ¶26) over the 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); evaluating test execution results obtained based on the executing (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 (1) sorting the plurality of independent files into groups, wherein the sorting is based on the respective data type of each independent file of the plurality of independent files, wherein each group is associated with a respective data type and (2) selecting an algorithm to be used for a security assessment of independent files in at least one group of the groups based on the respective data type of the at least one group. 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), including sorting the plurality of independent files into groups, wherein the sorting is based on the respective data type of each independent file of the plurality of independent files, wherein each group is associated with a respective data type (Fig. 2, groups represented by buckets 114; see also ¶19) and selecting an algorithm to be used for a security assessment of independent files in at least one group of the groups based on the respective data type of the at least one group (Fig. 2, represented by workers 108; see also ¶19). 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 to include (1) sorting the plurality of independent files into groups, wherein the sorting is based on the respective data type of each independent file of the plurality of independent files, wherein each group is associated with a respective data type and (2) selecting an algorithm to be used for a security assessment of independent files in at least one group of the groups based on the respective data type of the at least one group. 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.1
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 files based on unique characteristics determined as related to a respective data type associated with one or more files of the plurality of 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 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 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 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 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.2
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 independent files, mounting the plurality of 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 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 independent files, mounting the plurality of 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.
US 20200104490 A1 (BOULTON; Adam John et al.) teaches extracting various data types from binary files for analysis (¶¶21-30).
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 MICHAEL J SIMITOSKI whose telephone number is (571)272-3841. The examiner can normally be reached Monday - Friday, 7:00-3:00.
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, Carl Colin can be reached at 571-272-3862. 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.
/Michael Simitoski/ Primary Examiner, Art Unit 2493
August 7, 2026
1 US 20250013753 A1 (Conway; Eric) teaches an analysis system initializing pipelines based on the type of input data (¶39, ¶¶42-43 and ¶¶63-68).
2 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)
Prosecution Insights