DETAILED ACTION
A Request for Continued Examination under 37 CFR 1.114, 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 December 18, 2025 has been entered.
Claims 1, 3-11, and 13-20 are pending and are directed toward ACCELERATED VULNERABILITY DETECTION AND AUTOMATED MITIGATION.
Any claim objection/rejection not repeated below is withdrawn due to Applicant's amendment.
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.
Response to Arguments
Applicant’s arguments with regards to claims 1, 3-11, and 13-20 have been fully considered, but they are not persuasive and/or moot because of new grounds of rejection. Specifically:
“does not teach enumeration of in-box devices” argument – Applicant argues that while Srinivasan discusses provider-generated reports, tagging of assets, and prioritization scores and dashboards, all in the context of a multi-tenant cloud, it does not teach enumeration of in-box devices and device firmware or identification of dependencies associated with device firmware (REMARKS, page 7).
Response: Examiner puts on record that no “in-box devices” were claimed or even disclosed by Applicant, therefore it is irrelevant. Further, Applicant reproduced the citation from Srinivasan in regards to a new limitation of currently amended claims “enumerated devices” (REMARKS, page 7) including “allowing a customer to select a number of instances of a specific type and configuration”, which is the same as Applicant’s claimed enumeration.
“as inputs to a vulnerability status determination” argument – Applicant argues that Srinivasan does not simply fail to mention firmware, it fails to teach or suggest enumeration and dependency identification operations as inputs to a vulnerability status determination. (REMARKS, page 8).
Response: The exact limitation as currently amended is: “the dependencies, a vulnerability status of at least one of the information handling system or an application running on the information handling system”. Srinivasan explicitly teaches “at least one of the information handling system or an application running on the information handling system” as for example: “The computing resources provided by the computing resource provider may be made available in discrete units, which may be referred to as instances. An instance may represent a physical server hardware platform, a virtual machine instance executing on a server, or some combination of the two. Various types and configurations of instances may be made available, including different sizes of resources executing different operating systems (OS) and/or hypervisors and with various installed software applications, runtimes, and the like.” (Srinivasan, column 36, lines 47-56). Srinivasan further explicitly teaches “dependencies” as “Executing the instructions further causes the system to parse the device configuration information to identify a group of software packages installed within the VMI and determine that the first software package is in the group of software packages installed within the VMI. Executing the instructions further causes the system to retrieve network configuration information of the private computing environment that defines a maximum level of network access to the VMI. Executing the instructions further causes the system to determine a maximum privilege level allowed for applications executing within the VMI defined by the device configuration information, convert the maximum level of network access to a system access score according to a predefined vulnerability metric definition, convert the maximum privilege level to a system privilege score according to the predefined vulnerability metric definition, and generate a vulnerability priority score for the vulnerability.” (Srinivasan, column 38, lines 24-42), and a “vulnerability status” as “the configuration service may determine that the vulnerability description indicates that exploiting the vulnerability may result in a privilege escalation or other change of access scope (e.g., based on the base scope attribute 640 of FIG. 6A, i.e., Scope60se). For example, the configuration service may parse a vulnerability description ( e.g., one of the vulnerability descriptions 230) to extract an indication that the vulnerability allows a privilege escalation and assign a numerical value to that indication according a vulnerability metric definition such as the metric defined by the example VSS (e.g., by using the lookup table 700 of FIG. 7).” (Srinivasan, column 32, lines 21-32).
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, 3, 4, 6, 10, 11, 13, 14, 16 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Srinivasan et al. (US 11,516,222, Nov. 29, 2022), in view of Eacmen, III et al. (US 2019/0294801, Sep. 26, 2019), hereinafter referred to as Srinivasan and Eacmen.
As per claim 1, Srinivasan teaches a method, comprising:
consuming vulnerability information from one or more security services associated with an information handling system (the computing resource service provider may provide reports to the user identifying potential and/or observed security vulnerabilities. These reports may be generated by one or more security analysis tools operated by the computing resource service provider and may take into account particular configurations of resources (e.g., virtual machines and datastores) belonging to or allocated to the user. Srinivasan, Column 3, lines 64-67 – Column 4, lines 1-4);
determining, based on the vulnerability information, the enumerated devicesand the dependencies (A number of different types of computing devices may be used singly or in combination to implement the resources of the provider network in different embodiments, including general-purpose or special-purpose computer servers, storage devices, network devices, and the like. Srinivasan, Column 36, lines 11-15; see also The provider network may make instances available "on demand," allowing a customer to select a number of instances of a specific type and configuration ( e.g. size, platform, tenancy, availability zone, and the like) and quickly launch the instances for deployment. On-demand instances may further be added or removed as needed, either manually or automatically through auto scaling, as demand for or capacity requirements change over time. Srinivasan, Column 37, lines 14-21), a vulnerability status of at least one of the information handling system or an application running on the information handling system (a user 102 may manually assign attributes indicating that a particular asset (e.g., a machine instance 150 or a datastore 160) is sensitive, mission-critical, or otherwise of greater importance by assigning one or more tags indicating that status for that asset ( e.g., "sensitive," "high priority," "restricted," "redundant," "critical," "primary," "secondary," and so on) or other tags from which the user 102 or the configuration service 220 may use to classify assets. Srinivasan, Column 17, lines 48-56);
determining a vulnerability mitigation policy corresponding to the vulnerability status (The vulnerability report 295 may include a list of vulnerabilities and recommended priorities ("priority indications," or "priority scores") for mitigating those vulnerabilities relative to each other and/or to other vulnerabilities. Srinivasan, Column 12, lines 40-44); and
enforcing the vulnerability mitigation policy while the vulnerability status persists, wherein enforcing the vulnerability mitigation policy includes restricting functionality of at least one of the information handling system or the application (The policy statement next specifies that the policy statement applies only to a particular resource, although that resource may be specified as a function of the ClientID in the request (i.e., policy statements may contain variables). Next, the policy statement specifies that the statement pertains to a particular action denoted by "Connect." Srinivasan, Column 10, lines 33-38).
wherein the vulnerability information includes information indicative of a vulnerability of firmware for one or more hardware components of the information handling system.
Srinivasan does not teach firmware, Eacman however, teaches “wherein the vulnerability information includes information indicative of a vulnerability of firmware for one or more hardware components of the information handling system.” (The method may include acquiring, by at least one server, a firmware image of firmware associated with at least one computing device. The method may further include extracting, by the at least one server, at least one component of the firmware image. The method may further include analyzing, by the at least one server, the at least one component to detect at least one vulnerability of the firmware. The method may further include estimating, by the at least one server and based on the at least one vulnerability of the firmware, a security risk level of the firmware. The method may further include providing, by the at least one server, a report regarding the security risk level and the at least one vulnerability of the firmware. Eacmen, [0005]).
Srinivasan in view of Eacmen are analogous art to the claimed invention, because they are from a similar field of endeavor of systems, components and methodologies for providing secure communication between computer systems. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Srinivasan in view of Eacmen. This would have been desirable because Some embodiments of the present disclosure may allow for the prediction of vulnerabilities in the firmware of IoT devices, embedded devices, industrial controllers, and so forth (Eacmen, [0005]).
As per claim 3, Srinivasan in view of Eacmen teaches the method of claim 1, wherein determining the vulnerability status includes determining a vulnerability score wherein the vulnerability score comprises a metric quantifying information handling system vulnerabilities (Srinivasan, FIG. 6A).
As per claim 4, Srinivasan in view of Eacmen teaches the method of claim 1, wherein enforcing the vulnerability mitigation policy includes prohibiting potentially destructive operations (when the vulnerability is evaluated for the particular system, the system configuration prevents a network attack from succeeding and now requires adjacent network access instead. Srinivasan, Column 29, lines 24-27).
As per claim 6, Srinivasan in view of Eacmen teaches the method of claim 4, wherein the potentially destructive operations include device diagnostic operations (Vulnerability descriptions may also come from within a system. For example a computing system may include a computing process or access a service that monitors the system (or multiple systems) for performance issues or other undesired behavior and learns system configuration details that are predictive of problems occurring. Srinivasan, Column 9, lines 34-40).
As per claim 10, Srinivasan in view of Eacmen teaches the method of claim 1, wherein determining the vulnerability includes identifying vulnerabilities associated with the device firmware or the dependencies ((The method may include acquiring, by at least one server, a firmware image of firmware associated with at least one computing device. The method may further include extracting, by the at least one server, at least one component of the firmware image. The method may further include analyzing, by the at least one server, the at least one component to detect at least one vulnerability of the firmware. The method may further include estimating, by the at least one server and based on the at least one vulnerability of the firmware, a security risk level of the firmware. The method may further include providing, by the at least one server, a report regarding the security risk level and the at least one vulnerability of the firmware. Eacmen, [0005]).
Srinivasan in view of Eacmen are analogous art to the claimed invention, because they are from a similar field of endeavor of systems, components and methodologies for providing secure communication between computer systems. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Srinivasan in view of Eacmen. This would have been desirable because Some embodiments of the present disclosure may allow for the prediction of vulnerabilities in the firmware of IoT devices, embedded devices, industrial controllers, and so forth (Eacmen, [0005]).
Claims 11, 13, 14, 16 and 20 have limitations similar to those treated in the above rejection, and are met by the references as discussed above, and are rejected for the same reasons of obviousness as used above.
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 5 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Srinivasan et al. (US 11,516,222, Nov. 29, 2022), in view of Eacmen, III et al. (US 2019/0294801, Sep. 26, 2019), in view of AdorableFunnyKitty (Cancelling BIOS Data Wipe Process, r/Dell, 2021, 3 pages), hereinafter referred to as Srinivasan, Eacmen, and AFK.
As per claim 5, Srinivasan in view of Eacmen teaches the method of claim 4, but does not teach data wipe, AFK however teaches wherein the potentially destructive operations include data wipe functions (After that, I initiated BIOS Maintenance Data Wipe function since I didn't really care about the data and just wanted to set both disks to defaults (hoping it would fix the HDD). AFK, page 1).
Srinivasan in view of Eacmen in view of AFK are analogous art to the claimed invention, because they are from a similar field of endeavor of systems, components and methodologies for providing secure communication between computer systems. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Srinivasan in view of Eacmen in view of AFK. This would have been desirable because I'm afraid to make another hard shutdown since I think it may damage the whole hardware system, not only the HDD, turning my whole PC into paperweight. I don't even care about HDD anymore, I'll just go buy another one. I only care if the system would be safe so I can put a fresh Windows 10 installation on SSD after all (AFK, page 1).
Claim 15 has limitations similar to those treated in the above rejection, and are met by the references as discussed above, and are rejected for the same reasons of obviousness as used above.
Claims 7-9 and 17-19 are rejected under 35 U.S.C. 103 as being unpatentable over Srinivasan et al. (US 11,516,222, Nov. 29, 2022), in view of Eacmen, III et al. (US 2019/0294801, Sep. 26, 2019), in view of Kramer et al. (US 2006/0218635, Pub. Date: Sep. 28, 2006), hereinafter referred to as Srinivasan, Eacmen, and Kramer.
As per claim 7, Srinivasan in view of Eacmen teaches the method of claim 1, but does not teach restricting execution, Kramer however teaches wherein enforcing the vulnerability mitigation policy includes restricting execution of a vulnerable application program (the security component 306 may be in an isolated mode or a normal mode. Isolated mode refers to a security level that protects the computer system from an open vulnerability window during a state change. Normal mode refers to the security level that was in effect prior to entering the isolated mode. In isolated mode, the security component 306 may have implemented more stringent security restrictions than in normal mode. Kramer, [0043]).
Srinivasan in view of Eacmen in view of Kramer are analogous art to the claimed invention, because they are from a similar field of endeavor of systems, components and methodologies for providing secure communication between computer systems. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Srinivasan in view of Eacmen in view of Kramer. This would have been desirable because computer security has become increasingly more important, particularly, the prevention of attacks delivered over a network. As those skilled in the art will recognize, these attacks come in many different forms, including, but not limited to, computer viruses, computer worms, system component replacements, denial of service, even misuse and abuse of legitimate computer system features, all of which exploit one or more computer system vulnerabilities for illegitimate purposes (Kramer, [0002]).
As per claim 8, Srinivasan in view of Kramer teaches the method of claim 7, wherein restricting execution of a vulnerable application program includes prompting a user of the information handling system to update software or firmware associated with the vulnerable application program (the present invention provides a security measure to protect the computer system in the event that the state change does result in the opening of a vulnerability window. In accordance with the invention, before, simultaneously with, or after a state change has been indicated, detected, or discovered, for example, by the state-change-indicating component 304, the security component 306 raises the security level, placing the computer system in a temporary "isolated" mode, which may include blocking all incoming network traffic other than information requested by the computer system or coming from a secure or a known location. Then, on successful completion of a fixing routine by the fixing component 308, which may include determining that the required updates have been installed, the security level is returned to a normal mode by the security component 306. Thus, in accordance with the present invention, a computer system is protected during state changes. Kramer, [0038]).
Srinivasan in view of Eacmen in view of Kramer are analogous art to the claimed invention, because they are from a similar field of endeavor of systems, components and methodologies for providing secure communication between computer systems. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Srinivasan in view of Eacmen in view of Kramer. This would have been desirable because computer security has become increasingly more important, particularly, the prevention of attacks delivered over a network. As those skilled in the art will recognize, these attacks come in many different forms, including, but not limited to, computer viruses, computer worms, system component replacements, denial of service, even misuse and abuse of legitimate computer system features, all of which exploit one or more computer system vulnerabilities for illegitimate purposes (Kramer, [0002]).
As per claim 9, Srinivasan in view of Kramer teaches the method of claim 8, wherein restricting execution of a vulnerable application program includes preventing use of the vulnerable application program until the update is performed (Kramer, [0038]).
Srinivasan in view of Eacmen in view of Kramer are analogous art to the claimed invention, because they are from a similar field of endeavor of systems, components and methodologies for providing secure communication between computer systems. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Srinivasan in view of Eacmen in view of Kramer. This would have been desirable because computer security has become increasingly more important, particularly, the prevention of attacks delivered over a network. As those skilled in the art will recognize, these attacks come in many different forms, including, but not limited to, computer viruses, computer worms, system component replacements, denial of service, even misuse and abuse of legitimate computer system features, all of which exploit one or more computer system vulnerabilities for illegitimate purposes (Kramer, [0002]).
Claims 17-19 have limitations similar to those treated in the above rejection, and are met by the references as discussed above, and are rejected for the same reasons of obviousness as used above.
Conclusion -Therefore, in view of the above reasons, Examiner maintains rejections.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to OLEG KORSAK whose telephone number is (571)270-1938. The examiner can normally be reached on Monday-Friday 7:30am - 5:00pm EST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Rupal Dharia can be reached on (571) 272-3880. 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.
/OLEG KORSAK/
Primary Examiner, Art Unit 2492