DETAILED ACTION
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 .
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.
Priority/Benefit
Acknowledgment is made of applicant’s claim for priority under 35 U.S.C. 119 (a)-(d). The certified copy of European Application EP21204907.6 filed on 10/27/2021 has been received on 04/10/2024. The certified copy of FEDERAL REPUBLIC OF GERMANY Application DE10 2021 211 676.0 filed on 10/15/2021 has been received on 04/10/2024.
Acknowledgment is made of domestic priority data as claimed by applicant application is a 371 of PCT/EP2022/076648 has been filed 09/26/2022.
Response to Amendment
The Amendment filed on 12/16/2025 has been entered.
The objection of claim 1 is withdrawn in view of the amendment.
The objections of draws are maintained (see below).
The rejection of claims 1-16 under 35 U.S.C 112(b) is withdrawn in view of Applicant's remarks.
In response to the Applicant amendments/remarks regarding claims that invokes 35 U.S.C. 112(f) and corresponding claim rejections under 35 U.S.C. 112(b), the amendments have resolved the issues. The amendments clearly indicate that the claims as amended do not invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. Accordingly, the corresponding 35 U.S.C. 112(b) rejections are withdrawn.
Claims 1 and 15 are amended.
Claims 1-16 are pending of which claims 1 and 15 are independent claims.
Response to Arguments
Applicant's arguments filed on 12/16/2025 have been fully considered but they are not persuasive.
Regarding to applicant argument of limitation “executing the software image and the exploit associated with the software image on a configuration of a runtime environment specific to the target computer” that “in Sabetta, the exploits to be tested are pre-specified by a user or security tester in the exploit test request, rather than being determined from an exploit database based on previously identified vulnerabilities. Because Sabetta starts with user-specified exploits in an exploit test request rather than deriving exploits from an exploit database based on identified vulnerabilities, Sabetta cannot cure STOPEL's deficiency. Sabetta's "exploit repository 114 contains descriptions of exploits in some type of executable form," but Sabetta does not teach determining exploits from this repository based on vulnerabilities previously identified in software components.8 Instead, Sabetta's input handler 120 is configured to receive the exploit test request 106 from the security tester 104 where the exploits are already specified by the tester.” Examiner respectively disagree because:
Sabetta paragraph [0035] discloses a parser of testing request may determine exploit data to be executed from the repository manager to obtain exploit data from repositories (i.e. database). In combination with STOPEL's database, the exploit can be executed as argued claim limitation.
Argued limitation doesn’t explicitly define the exploit database and how exploits associated with the software image is determined and different from the combination of STOPEL and Sabetta.
Regarding to applicant argument of limitation “wherein a modified, non-exploitable software image is created depending on a policy stored in a manufacturer's assembly device for assembling the software image and depending on the at least one confirmed exploitable vulnerability” that “Sobel does not teach determining exploits using an exploit database or executing exploits to confirm exploitability. Sobel creates modified images based on detected vulnerabilities, not based on confirmed exploitable vulnerabilities as required by claim 1”. Examiner respectively disagree because:
the combination of STOPEL and Sabetta teaches “determining exploits using an exploit database or executing exploits to confirm exploitability” as argued (see Sabetta paragraph [0064]).
Sobel additionally teaches create a modified software image using security definition (policy) once a vulnerability is detected or confirmed. The argued limitation only depends on at least one confirmed vulnerability. Once vulnerability is found, a modified image is created as disclosed by Sobel [Col. 6, Line 4-36].
Furthermore, regarding to applicant argument of limitation "a policy stored in a manufacturer's assembly device for assembling the software image" that “Sobel's rules module is part of a vulnerability assessment engine, not a manufacturer's assembly device for assembling software images”, examiner respectively disagree because:
As illustrated in Sobel Fig. 1A and 1B, VA system 104 and rules module 158 are part of host device 102. Sobel [Col. 3, Line 32-48] further discloses VA system 104 can be deployed on a single host or, in a multi-host or internetwork environment, on multiple hosts. And Host 102 is shown in data communication with a potentially vulnerable system 107 and provides tools to user for generating hardware image. Therefore, in combination with STOPEL and Sabetta, Sobel teaches “a manufacturer's assembly device for assembling the software image”.
Therefore, the combination of STOPEL, Sabetta,and Sobel teaches the argued limitations.
Drawings
The drawings are objected to under 37 CFR 1.83(a) because they fail to show structural details as described in the specification. Any structural detail that is essential for a proper understanding of the disclosed invention should be shown in the drawing. MPEP § 608.02(d). Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
The boxes in figs. 1-3 should not be blank. The details of steps or components of graphs should be listed for a proper understanding of the disclosed invention.
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 of this title, 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-10 are rejected under 35 U.S.C. 103 as being unpatentable over STOPEL et al. (Pub. No.: US 2017/0109536, hereinafter STOPEL) in view of Sabetta et al. (Pub. No.: US 2016/0314302, hereinafter Sabetta) and Sobel et al. (Patent No.: US 7,437,764, hereinafter Sobel).
Regarding claim 1: STOPEL teaches: A method for automatic analysis of an exploitability of vulnerabilities of a software image executed on a target computer, comprising:
identifying all the software components contained in the software image (STOPEL - Fig. 6, [0062]: At S630, the contents of the exported base image are extracted. Specifically, the contents of each layer in the base image may be extracted);
determining vulnerabilities of an identified software component for each software component of the software image using a vulnerability database (STOPEL - [0064]: At S650, the extracted contents are scanned for vulnerabilities. Such vulnerabilities may include previously known or newly discovered malware, or any modified version of previously known or newly discovered malware);
determining all exploits associated with at least one determined vulnerability of the software component, for each identified software component, using an exploit database, associating the determined exploits with the software image (STOPEL - [0068]: At S670, a detection event is generated. The detection event may be sent to the source of the base image, i.e., an image registry, a continuous integration system, or both. The detection event may designate, for example, a base image identifier, an infected layer or layers, a source register, a type of the detected vulnerability, and so on);
However, STOPEL doesn’t explicitly teach, but Sabetta discloses:
executing the software image and the exploit associated with the software image on a configuration of a runtime environment specific to the target computer (Sabetta - [0053]: execution of the at least one execution environment may be scheduled within at least one execution engine, including scheduling an injection of at least one exploit as specified in the exploit test request 306)); and
confirming the exploitability of the at least one identified vulnerability on the configuration of the runtime environment if an execution of the at least one exploit leads to exploitation of the vulnerability (Sabetta - [0064]: when a vulnerability is detected for an application, being able to reproduce an attack is important to investigating the root cause of the vulnerability, and to providing a timely solution),
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of STOPEL with Sabetta so that test exploit in a certain execution environment to confirm vulnerability. The modification would have allowed the system to confirm exploit in an execution environment.
However, the combination of STOPEL and Sabetta doesn’t explicitly teach but Sobel discloses: wherein a modified, non-exploitable software image is created depending on a policy stored in a manufacturer's assembly device for assembling the software image and depending on the at least one confirmed exploitable vulnerability (Sobel - [Col. 6, Line 4-36]: Once a security definition/update has been retrieved from definition updates module 160, VA engine 152 tests the security definition/update to determine whether an applicable repair (e.g., a software patch) is available to be installed to repair the vulnerability (306) … If it is determined in step 306 that an applicable repair is available, then the repair is installed in the image (310). See also [Col. 3, Line 32-48]), and the modified software image is provided to one or all of the target computers that have the specific configuration of the runtime environment (Sobel - [Col. 8, Line 16-23]: Once called, the security definition/update (e.g., security patch, fix, application, etc.) is written to the file(s) including the vulnerability (422). If the vulnerability in the image exists in the configuration settings, the security definition/update may direct the modification of the configuration settings to place the image in a safe state (424). Once repairs, blocking, hardening, or other fix is written to the indicated files in the image).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of STOPEL and Sabetta with Sobel software image can be updated for vulnerable code. The modification would have allowed the system to be more secure.
Regarding claim 2: STOPEL as modified teaches wherein the at least one exploitable vulnerability is reported to a user of the target computer and/or to a manufacturer of the software image (STOPEL - [0068]: The detection event may be sent to the source of the base image, i.e., an image registry, a continuous integration system, or both. The detection event may designate, for example, a base image identifier, an infected layer or layers, a source register, a type of the detected vulnerability, and so on. The identifier of a malicious base image is saved in the database, reported to an external system, or both).
Regarding claim 3: STOPEL as modified teaches wherein the method steps are carried out after assembly of the software image at the manufacturer and/or at predetermined time intervals and/or after predetermined events (Sabetta - [0052]: The at least one execution environment may be deployed, including instantiating a container providing a virtual machine image).
The reason to combine is similar as claim 1.
Regarding claim 4: STOPEL as modified teaches wherein the modified software image is provided on a software repository (Sobel - [Col. 3, Line 24-26]: Memory 106 provides a storage capability for host 102, which includes storing images, configuration settings, security definitions and update).
The reason to combine is similar as claim 1.
Regarding claim 5: STOPEL as modified teaches wherein the modified software image is retrieved by the target computer or automatically imported into the target computer (Sobel - [Col. 4, Line 52-55]: Directed by VA engine logic module 166, VA engine 152 calls definition updates module 160 to determine whether a security definition/update or fix is available and/or required (304)).
The reason to combine is similar as claim 1.
Regarding claim 6: STOPEL as modified teaches wherein the modified software image is automatically imported into further target computers with the same configuration of the runtime environment (Sobel - [Col. 6, Line 34-37]: If it is determined in step 306 that an applicable repair is available, then the repair is installed in the image (310)).
The reason to combine is similar as claim 1.
Regarding claim 7: STOPEL as modified teaches wherein the software components and vulnerabilities are identified on a reference computer or on a manufacturer's assembly device (STOPEL - [0066]: S650 further includes scanning for vulnerabilities in software packages, libraries, or both, that are installed in the base image).
Regarding claim 8: STOPEL as modified teaches wherein the software components are identified depending on a signature of the software component or by a package manager within the software image (STOPEL - [0066]: an identifier of each such package or library is detected in the extracted contents).
Regarding claim 9: STOPEL as modified teaches wherein additional manufacturing information, including a version identifier, is determined for the at least one identified software components (STOPEL - [0043]: a version identifier of each software package is determined).
Regarding claim 10: STOPEL as modified teaches wherein a vulnerability profile specific to the software image and comprising the identified software components, the determined vulnerabilities and the determined exploits, is stored on an image vulnerability database (STOPEL - [0046]: Upon detection of a vulnerability, a detection event is generated and reported. Such a detection event may include, but is not limited to, a base image identifier, an infected layer or layers, a source register, a type of the detected vulnerability, and so on. The identifier of a malicious base image is saved in the database 350).
Regarding claim 15: this claim defines a system claim that corresponds to method claim 1 and does not define beyond limitations of claim 1. Therefore, claim 15 is rejected with the same rational as in the rejection of claim 1.
Regarding claim 16: this claim defines a computer readable hardware storage device claim that corresponds to system claim 1 and does not define beyond limitations of claim 1. Therefore, claim 17 is rejected with the same rational as in the rejection of claim 1.
Claims 11, 13-14 are rejected under 35 U.S.C. 103 as being unpatentable over STOPEL et al. (Pub. No.: US 2017/0109536, hereinafter STOPEL) in view of Sabetta et al. (Pub. No.: US 2016/0314302, hereinafter Sabetta) and Sobel et al. (Patent No.: US 7,437,764, hereinafter Sobel) and ANDREWS et al. (Pub. No.: US 2015/0142849, hereinafter ANDREWS).
Regarding claim 11: STOPEL as modified doesn’t explicitly teach but ANDREWS disclose wherein different configurations of runtime environments, with the correspondingly configured target computers on which the software image is executed, are determined by an inventory database (ANDREWS - [0039]: at step 312, web query application 118 determines and retrieves an RTE associated with the selected profile. See also Fig. 2).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of STOPEL and Sabetta with Sobel and ANDREWS so that RTE is queried from the RTE configuration table. The modification would have allowed the system to find a matching RTE.
Regarding claim 13: STOPEL as modified wherein the configuration of the runtime environment of the target computer, on which the software image is executed, is determined by a configuration scanner and transmitted to the inventory database (ANDREWS - [0033]: Web query application 118 searches for profiles in user RTE table 208. Web query application 118 matches an RTE username 206 (i.e., the username of client computer 102) with an RTE username from user RTE table 208. [0024]: server computer 112 stores RTE definitions 114, RTE configuration component 116, and web query application 118. Server computer 112 also stores profiles 120 and libraries 122. RTE definitions 114 stores data about each RTE that may be exposed to a client interaction with a web query application).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of STOPEL and Sabetta with Sobel and ANDREWS so that RTE configuration table can be searched and stored. The modification would have allowed the system to find a matching RTE.
Regarding claim 14: STOPEL as modified wherein the configuration scanner determines the configuration of the runtime environment of the target computer depending on open services on the target computer, response messages of the target computer to queries directed to the target computer, or an identifier of the target computer (ANDREWS - [0030]: each time web query application 118 services a query made by a user (such as query 108), web query application 118 determines which libraries to execute query 108 against. More specifically, web query application 118 reads the active RTE user table 202 to identify a user profile associated with the query. That is, web query application 118 reads RTE username 206 to identify the user. Furthermore, web query application 118 determines whether query 108 references the currently configured RTE (i.e., whether query 108 references RTE ID 204)).
The reason to combine is similar as claim 13.
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over STOPEL et al. (Pub. No.: US 2017/0109536, hereinafter STOPEL) in view of Sabetta et al. (Pub. No.: US 2016/0314302, hereinafter Sabetta) and Sobel et al. (Patent No.: US 7,437,764, hereinafter Sobel) and ANDREWS et al. (Pub. No.: US 2015/0142849), Yerramreddy et al. (US 10678522, hereinafter Yerramreddy).
Regarding claim 12: STOPEL as modified doesn’t explicitly teach but Yerramreddy disclose wherein the configuration of the runtime environment of the target computer, on which the software image is executed, is determined by the target computer and transmitted to an inventory database (Yerramreddy - [Col. 9, Line 17-18]: the configuration is specified by a user as a text or other data file, is stored in the repository 114).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of STOPEL and Sabetta with Sobel and ANDREWS, Yerramreddy so that configuration specified by the user can be stored in the repository.
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MENG LI whose telephone number is (571)272-8729. The examiner can normally be reached M-F 8:30-5:30.
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, Alexander Lagor can be reached on (571) 270-5143. 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.
/MENG LI/
Primary Examiner, Art Unit 2437