DETAILED ACTION
This action is responsive to amendment filed on November 26th, 2025.
Claims 1, 3, 5~11, 13, and 15~24 are examined.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s arguments with respect to claims 1, 3, 5~11, 13, and 15~24 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 103
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claims 1, 3, 6~9, 11, 13, 15~17, and 19~21 are rejected under 35 U.S.C. 103 as being unpatentable over Dorrans et al. hereinafter Dorrans (U.S 2020/0074084), Sweet et al. hereinafter Sweet (U.S 2018/0309747), Giakouminakis et al. hereinafter Giakouminakis (U.S 2013/0074188) in view of Brucker et al. hereinafter Brucker (U.S 2017/0169229).
Regarding Claim 1,
Dorrans taught a system comprising: a microprocessor; and a computer readable medium, coupled with the microprocessor and comprising microprocessor readable and executable instructions that, when executed by the microprocessor, cause the microprocessor to:
initiate a self-contained validation process, wherein the self-contained validation process comprises at least one of: a self-contained application validation process [¶309, notifications are given during application startup 1256 when the application 124 depends on vulnerable components; the runtime proactively performs a periodic vulnerability check on each application; ¶289, perform or use logging at app startup 1256 and generate 1008 vulnerability notifications 226 only when a runtime 604 or package 902 is out of date];
in response to initiating the self-contained validation process, request, by the self- contained validation process, a list of vulnerabilities associated with the self-contained validation process [¶273, runtime obtains vulnerable components list; ¶278];
receive the list of vulnerabilities associated with the self-contained validation process [¶181, obtain the vulnerable components list; ¶278]; and
take an action based on the received list of vulnerabilities associated with the self-contained validation process [¶5, ¶249, generates a vulnerability notification 226 that is formatted to notify a user 104 of the computing system 202 that at least one utilizable component 210, 204 is also a vulnerable component 218, 204].
Dorrans did not specifically teach wherein the action is to modify a configuration file.
Sweet taught wherein the action is to modify a configuration file [¶229, examples of action commands include making changes to configuration parameters within the container 74 and application configuration files].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention was made, to combine, Sweet’s teachings with the teachings of Dorrans, because the combination allows the states of security, compliance and integrity of container 74 and the programs running on the container to be continuously assessed, analyzed and improved [Sweet: ¶233].
The combination of Dorrans and Sweet did not specifically teach wherein the list of vulnerabilities associated with the self-contained validation process comprises combination vulnerabilities of two or more of: library vulnerabilities, configuration vulnerabilities, and hypervisor vulnerabilities.
Giakouminakis taught wherein the list of vulnerabilities associated with the self-contained validation process comprises configuration vulnerabilities [¶21, security tool 102 can be configured to scan the computing systems 104 in order to identify the details of the software resources of the computing systems (configuration of the software installed). The security tool 102 can be configured to communicate with a vulnerability scanner, which can operate on the computer systems 104, to identity the vulnerabilities; ¶55, security tool 102 provide report that includes identity of the asset, the identified vulnerabilities, the risk level, and the overall risk].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention was made, to combine, Giakouminakis’s teachings with the teachings of Dorrans and Sweet, because the combination identify and analyze security threats to a computing system and provide details of vulnerabilities that accurately represent the threats to a user [Giakouminakis: ¶12].
The combination Dorrans, Sweet, and Giakouminakis did not specifically teach wherein the list of vulnerabilities associated with the self-contained validation process comprises library vulnerabilities.
Brucker taught the self-contained validation process comprises library vulnerabilities [¶6, identifying a first set of the plurality of software components by performing a first analysis of the application, where the first analysis is an analysis of byte-code of the application to identify the software components based on links to dynamic libraries; ¶16~¶19, determining, for each software component in the list, whether the software component has an exploitable vulnerability].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention was made, to combine, Brucker’s teachings with the teachings of Dorrans, Sweet, and Giakouminakis, because the combination would prevent the need for complex and dynamic software tracking and security monitoring policies [Brucker: ¶2].
Regarding Claim 3,
Dorrans taught wherein requesting the list of vulnerabilities associated with the self-contained validation process further comprises requesting the list of vulnerabilities associated with the self-contained validation process after the self-contained validation process is loaded [¶25, perform a runtime check which compares the currently loaded program framework and dependency tree, as a utilizable components list, against a vulnerabilities list of superseded software].
Regarding Claim 6,
Dorrans taught wherein the action taken is based on a combination vulnerability that comprises at least two of: an individual vulnerability associated with the self-contained validation process, a hardware vulnerability, a firmware vulnerability, a driver vulnerability, and an operating system vulnerability [¶249; ¶251].
Regarding Claim 7,
Dorrans-Sweet-Giakouminakis-Brucker taught wherein the self-contained validation process uses a self-contained bill-of-materials, wherein the self-contained bill-of-materials comprises a plurality of components and wherein the request for the list of vulnerabilities associated with the self-contained validation process requests an individual list of vulnerabilities for each of the plurality of components in the self- contained bill-of-materials [¶38, the BOM can be used to monitor the security of application components and track updates to application components. BOM can be revised to track updates to a component (e.g., version updates, patches, etc.) and information for which update(s) or version(s) of the component correct different vulnerabilities; ¶39, the component monitoring system 106 can access the BOM and monitor for vulnerabilities in the components exposed by an application to track component updates and provide corresponding updates for the application]. The rationale to combine as discussed in claim 1, applies here as well.
Regarding Claim 8,
Dorrans taught wherein the self-contained validation process comprises a hierarchy of self-contained validation processes [¶300, runtime monitoring to include applications running within PAAS VMs and similarly extended to containers].
Regarding Claim 10,
Dorrans taught wherein requesting the list of vulnerabilities associated with the self-contained validation process comprises sending a configuration file or at least some content of the configuration file to a vulnerabilities server [¶244, detailed configuration information may be sent to the base 216 but not be retained in the base after the responsive vulnerabilities list is sent to the system 202] and wherein the vulnerabilities server determines if there are any configuration vulnerabilities based the configuration file or the at least some content of the configuration file [¶244; ¶270; ¶323].
Regarding Claim 23,
Dorrans taught wherein the list of vulnerabilities is in a format including number representations of vulnerabilities or tokens including a vulnerability [¶119, 212 list of one or more utilizable components, e.g., a linked list, array, tree, manifest, XML recitation, file, or other data structure which includes, names, addresses, identifies].
Regarding Claims 11, 13, 15~17, and 19~21, the claims are similar in scope to claims 1~4, 6, and 8 and therefore, rejected under the same rationale.
Claims 5 and 24 rejected under 35 U.S.C. 103 as being unpatentable over Dorrans, Sweet, Giakouminakis, and Brucker in view of Dominessy et al. hereinafter Dominessy (U.S 11,683,333).
Regarding Claim 5,
Dorrans-Sweet taught wherein the action is taken based on one or more rules, and wherein the one or more rules are defined in the self-contained validation process, in the list of vulnerabilities associated with the self-contained validation process, and/or in a configuration file [Sweet: ¶189, policy domain consists of a set of commands 58 applied to both the container 74 and the applications running on it and a corresponding set of rules 59 to ensure that the commands are appropriately executed]. The rationale to combine as discussed in claim 1, applies here as well.
Dorrans-Sweet-Giakouminakis-Brucker-Dominessy taught wherein the one or more rules are dynamically changed based on machine learning (C8:50~66, rule-based/machine learning engine 6 may identify a respective likelihood of occurrence of each of one or more potential vulnerabilities).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention was made, to combine, Dominessy’s teachings with the teachings of Dorrans, Sweet, Giakouminakis, and Brucker, because the provides an opportunity to monitor cybersecurity risk in an automated, maintainable, and more efficient and effective manner [Dominessy: C5:49~54].
Regarding Claim 24,
Dorrans-Sweet taught wherein the action is taken based on one or more rules, wherein the one or more rules are defined in the self-contained validation process, in the list of vulnerabilities associated with the self-contained validation process, and/or in a configuration file [Sweet: ¶189, policy domain consists of a set of commands 58 applied to both the container 74 and the applications running on it and a corresponding set of rules 59 to ensure that the commands are appropriately executed].
Dorrans-Sweet-Giakouminakis-Brucker-Dominessy taught wherein the one or more rules is determined based on a threshold level defined by the list of vulnerabilities (C29:66~ C30:6, Policies 104 used by rules engine 100 may provide various rules and corresponding weights and/or thresholds. Rules engine 100 may process monitoring information provided by agents/test modules 12, using policies 104, where corresponding weights or thresholds of rules may be associated with likelihoods of possible vulnerabilities, or triggers (e.g., triggers of malicious activity), based execution of applications 66). The rationale to combine as discussed in claim 5, applies here as well.
Claims 9, 18, and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Dorrans, Sweet, Giakouminakis, and Brucker in view of White et al. hereinafter White (U.S 2022/0300330).
Regarding Claim 9,
Dorrans-Sweet-Giakouminakis-Brucker-White taught wherein the hierarchy of self-contained validation processes comprises one of: the self-contained hypervisor validation process at a top level, the self-contained virtual machine validation process at a second level, and the self-contained container validation process at a third level [White: ¶22, VMM logic 120 comprises RCP logic 125. RCP logic 125 comprises one or more computer programs, application programming interfaces, or other software elements that are configured to implement runtime container protection. RCP logic 125 comprises an agent (e.g., hypervisor agent). VMM logic 120 may comprise a hypervisor (e.g., Kernel-based Virtual Machine (KVM), Xen, Microsoft Hyper-V, VMware vSphere, etc.) or other virtual machine monitor [¶21].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention was made, to combine, White’s teachings with the teachings of Dorrans, Sweet, Giakouminakis, and Brucker, because the combination would provide protection against vulnerabilities associated with using containers to create virtual environments for applications [White: ¶10].
Regarding Claims 18 and 22, the claims are similar in scope to claim 9 and therefore, rejected under the same rationale.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HEE SOO KIM whose telephone number is (571)270-3229. The examiner can normally be reached M-F 9AM-5PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Nicholas Taylor can be reached on (571) 272-3889. 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.
/HEE SOO KIM/Primary Examiner, Art Unit 2443
Prosecution Insights