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 .
Response to Arguments
The present office action is responsive to communications received on 11/20/2025. Claims 1, 10, 11, and 20 have been amended. Claims 1-20 are currently pending.
Applicant’s amendments filed on 11/20/2025 with regards to 35 USC 112(a), as seen in page 7, have been fully considered and fully persuasive. Applicant’s amendments with regards to 35 USC 112(b), as seen in page 8, have been fully considered but not fully persuasive. Applicant amends from “vulnerability compliance calculation” to “calculating vulnerability compliance score”. The Examiner asserts the amended limitation does not overcome the 112(b) in the previous office action because one in the ordinary in the art would not know what inputs the vulnerability compliance calculation is derived from. Furthermore, examiner still asserts the amended limitation does not remedy the indefinite term of “vulnerability compliance resource”. The independent and dependent claims do not further elaborate on what a vulnerability compliance resource is nor how the vulnerability compliance is modified. One of the ordinary skill in the art would not know how vulnerability compliance is modified or applied, nor it is unclear whether modifying resource refers to a changing rules, policies, configurations of a system, or something else.
Applicant’s arguments and amendments with regards to 35 USC 103 with respect to Smith et al. (US PGPub No. 20240241944-A1) in view of Manjunath et al. (US PGPub No.20250139250-A1) , as seen in pages 8-10, with respect to claims 1, 11, and their dependents have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new grounds of rejection is made in view of Twigg et al. (US PGPub No. 20230075355-A1), Berg et al. (US PGPub No. 20240430179-A1) and Alberti et al. (US PGPub No. 20060265630-A1)
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Regarding claims 1 and 11:
“a trigger indicating when new vulnerability information about a system becomes available and when changes to the containerized workload environment occur…” is recited in claims 1 and 11, but the specification does not explicitly disclose a trigger being indicated when both new vulnerability information about a system becomes available and changes to the containerized workload environment occur. In ¶0019 of the specification states, “…Some examples may include (a) when new vulnerability information becomes available, (b) when any hardware component configuration changes, (c) when preparing a system for solution, or (d) when preparing to onboard a system into the cluster…” . Nowhere in the specification discloses the combination of new vulnerability information becoming available and changes in containerized environment occur resulting in the indication of a trigger. Examiner suggests to amend the limitation to a plurality of triggers, wherein the plurality of triggers indicate one of the following: (a) when new vulnerability information is available or (b) when changes to the containerized environment occur.
The claims further recites:
“implementing the update in the system to address the trigger…” is recited in claims 1 and 11, but the specification does not disclose the limitation. In ¶0038 of the specification states, “…updating a vulnerability compliance resource catalogue, associated with the system, to list an update that is need to address the vulnerability; implementing the update of the system; as a result of the trigger…” which indicates that the update in the system addresses the vulnerability, not the trigger. The specifications and the claims clearly show that a trigger and a vulnerability are completely separate terms with separate meanings (as seen in the above paragraphs and claims) and are not used interchangeably.
Claims 2-10 and 12-20 do not overcome the rejections of their respective base claims that have been rejected above, and therefore rejected under the same grounds provided to claim 1 and 11.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claims 1 and 11:
“…parsing the trigger and modifying vulnerability compliance resources for the system based on the parsing…”
Indefinite because the claims does not specify how the vulnerability compliance resource are modified. It is unclear whether modifying resource refers to the modification of vulnerability compliance refers to the changing of configurations of a system, a rule change, a policy change, or something else.
“…calculating a vulnerability compliance score for the system.”
Indefinite because the claims does not specify what inputs are derived are used to calculate vulnerability compliance score for the system. Further one in the ordinary skill in the art would not know how to calculate the vulnerability compliance score nor what inputs are used in calculating the vulnerability the compliance score the of the system.
Regarding claims 8 and 18:
“… vulnerability compliance resource…”
Indefinite because the claim does not specify what constitutes as a “vulnerability compliance resource”. It is unclear whether the resource refers to a rule, policy, configuration, or something else.
Claims 2-10 and 12-20 do not overcome the rejections of their respective base claims that have been rejected above, and therefore rejected under the same grounds provided to claim 1 and 11.
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.
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.
Claims 1, 2, 3-6, 8, 9, 11, 12, 13-16, 18, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Twigg et al. (US PGPub No. 20230075355-A1) in view of Berg et al. (US PGPub No. 20240430179-A1) and Alberti et al. (US PGPub No. 20060265630-A1).
With respect to claim 1, Twigg teaches a method, comprising: monitoring a containerized workload environment; (¶0059-0063: Figure 1A shows an illustrative configuration 10 in which a data platform 12 is configure to perform various operations with respect to a cloud environment 14 that includes a plurality of compute assets 16-1 through 16-N (collectively “computer assets 16”). Compute assets 16 may include but not limited to, containers (e.g., container images, deployed and executing container instances, etc.), virtual machines, workloads, and/or any other virtual and/or physical compute resources that may reside in and/or be executed by one or more compute resources in cloud environment 14. Data platform 12 may be configured to perform one or more data security monitoring and/or remediation services, compliance monitoring services, anomaly detection services, compute asset management services, and/or any other type of data analytics service.);
receiving, as a result of the monitoring, a trigger indicating when new vulnerability information about a system becomes available and when changes to the containerized workload environment occur; (¶0157-0158: Using technique described herein, data platform 12 can automatically discover entities (which may implement compute assets 16) deployed in given datacenter. Examples entities include workloads. The entities may be grouped together logically based on behavior can be established. Deviations from the expected normal behavior then be detected and automatically reported (e.g., as anomalies and threats detected) (indication when new vulnerability information about system and when changes to containerized workload environment occur) . Such deviations may be due to a desired change, a misconfiguration, or malicious activity.);
Twigg does not disclose:
parsing the trigger and modifying vulnerability compliance resources for the system based on the parsing;
updating a catalogue that lists the modified vulnerability compliance resources for the system
implementing the update in the system to address the trigger; performing a reconciliation for the system; and calculating a vulnerability compliance score for the system.
However, Berg teaches parsing the trigger and modifying vulnerability compliance resources for the system based on the parsing; (¶0152-0153: Figure 6, shows an example method 600 of product management in a managed network. The method 600 may be implemented for vulnerability detection and mitigation or other management operations in managed network. Responsive to the trigger event being detected (“YES” at block 608), the method 600 may prevent to block 609.) At block 609, a scan may be initiated. For instance, a local scan, a network scan, a global scan, or some combination thereof may be initiated. The scan may be performed to identify trigger events or other inconsistencies with the defined state throughout the managed network or the cloud network. At block 610, a product modification process may be automatically implemented. The product modification process may include distribution of at least one product update to a first product installed at the endpoint. The product update may include a patch, version update, vulnerability fix, and the like.);
performing a reconciliation for the system; (¶0154-0155: At block 612, SLA compliance may be assessed or evaluated. For instance, in some embodiments, the defined state may at least partially include a service level agreement (SLA). In these and other embodiments, the at least one condition of the defined state includes a metric used to measure compliance with the SLA. The scan of block 609 may result in SLA compliance data at a time of the scan. In some embodiments, the method 600 may proceed from 609 to 612 without implementing the operations of block 610. For instance, an evaluation of compliance may be wanted without necessarily correcting outstanding deficiencies.);
and calculating a vulnerability compliance score for the system. (¶0157-0159: At block 612, Furthermore, Figure 7 illustrates and example method 700 of assessing real-time SLA compliance. At block 708, display SLA compliance may be caused. The method 700 may be implemented as part of another method or process such as block 612 of the method 600. For example, in embodiments of the method 600 in which the defined state at least partially includes an SLA, the method 700 may be included in block 612. The SLA compliance data includes data representatives of whether endpoints of the SLA group are SLA compliant or SLA non-compliant at a time of the scan (calculating compliance score for the system).);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Berg with regards to a parsing and modifying vulnerability compliance resources based on parsing, performing reconciliation for the system, and calculating a vulnerability compliance score, to the view of the method of Twigg in order to ensure the products are property functioning and to ensure cybersecurity vulnerabilities are addressed (Berg: ¶0004).
Twigg in view of Berg does not disclose:
updating a catalogue that lists the modified vulnerability compliance resources for the system implementing the update in the system to address the trigger;
However, Alberti teaches updating a catalogue that lists the modified vulnerability compliance resources for the system implementing the update in the system to address the trigger; (¶0009 &¶0034: The method includes the step of providing a set of software patches; each patch is intended to correct at least one problem (by modifying at least one software product) (addressing the trigger). The method continues selecting a subset of patch together with one or more target entities for each selected patch; the operation is performed according to a (vulnerability) catalogue, which provides an indication of the exposure to the problems by each entity. A distribution plan is then built; for each selected patch the distribution plan includes an activity, which is intended to apply a software package on the corresponding target entities. Further the prior art illustrates explicitly updating a catalog in Figure 2, wherein the automation engine 225 retrieves the available information (patch definitions and patch catalogue) for the patches that have been approved from the corresponding repositories 210 and 215 (through the patch manager 205). As it will be apparent in the following, the automation engine 225 generates a corresponding distribution plan for installing the approved patches (simply referred to as patches from now on). For this purpose, the automation engine 225 accesses a vulnerability catalogue 230; for each endpoint, the catalogue 230 lists its exposures to the problems of the (approved) patches (for example, in the form of the patches that should be required). );
It is noted that Berg does teach the modification of vulnerability compliance resources for the system implementing the update in the system to address the trigger as seen in ¶0153 (wherein in an update is implemented according the modifications) , but the prior art does not teach updating a catalogue. Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Alberti with regards to updating a catalogue, to the view of the method of Twigg in view of Berg in order to prevent exposure the of the system to malicious attacks, such as hackers (also because those vulnerabilities are now public) and better reliability of security. (Alberti: ¶0002-0007).
With respect to claim 2, the combination of Twigg in view of Berg and Alberti teaches method of claim 1 (see rejection of claim 1 above), wherein the update comprises any one or more of: a software update; a hardware update; or a firmware update. (Berg ¶0152-0153: Figure 6, shows an example method 600 of product management in a managed network. The method 600 may be implemented for vulnerability detection and mitigation or other management operations in managed network. At block 610, a product modification process may be automatically implemented. The product update may include a patch, version update, vulnerability fix, and the like. Additionally or alternatively, the product modification process may be configured to remove an installed product, replace an installed product, change to a setting or feature on an installed product, etc.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Berg with regards to the update to the method of Twigg in view of Alberti in order to mitigate the vulnerabilities that were detected in the system (Berg: ¶0004 & ¶0146).
With respect to claim 3, the combination of Twigg in view of Berg and Alberti teaches method of claim 1 (see rejection of claim 1 above) , wherein the update is implemented automatically after receipt of the trigger. ( Berg ¶0069 & ¶0153: As seen in Figure 6, at block 610, a product modification process may be automatically implemented. The product modification process may include distribution of at least one product update to a first product installed at the endpoint. The product update may include a patch, version update, vulnerability fix, and the like. It is further illustrated in Figure 1, wherein the update modules 116/120 may automatically implement of a product modification process, responsive to detection of the trigger events. The product modification process is configured to at least partially restore the endpoint 106 or a set of the endpoints 106 to the defined state. ).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Berg with regards to the update to the view of the method of Twigg in view of Alberti in order to mitigate the vulnerabilities that were detected in the system (Berg: ¶0004 & ¶0146).
With respect to claim 4, the combination of Twigg in view of Berg and Alberti teaches method of claim 1 (see rejection of claim 1 above), wherein the trigger is generated in response to one of: passage of a defined time interval; an addition or change to the system; or a change in the containerized workload environment. ( Twigg ¶0075: One or more operation performed by data processing resources 20 may be performed periodically according to a predetermined schedule. For example, one or more operations may be performed by data processing resources 20 every hour or any other suitable time interval. In this manner, the results of such operations (e.g., one or more detected anomalies in the data) may be provided to one or more external entities in substantially real-time and/or in near real-time. ).
With respect to claim 5, the combination of Twigg in view of Berg and Alberti teaches method of claim 1 (see rejection of claim 1 above) wherein the vulnerability compliance score indicates an extent to which the system is in compliance with an established standard. (Berg ¶0157-0158: As seen in Figure 7 shows a flow chart of an example method 700 of accessing real-time SLA compliance. In these and other embodiments, at least one condition of the defined state may include a metric used to measure compliance with the SLA. It is also further illustrated in Figure 10 where it shows method of 1000 of real-time, endpoint-level SLA compliance evaluation in managed network (which also could be applied since both methods assessing compliance in real time). The method 1000 may begin at block 1002 in which SLA definition input may be received. For instance, the SLA definition input may be received from a management device such as the first management device 102 or the cloud server 122. The SLA definition input may be configured to indicate an SLA definition for an SLA standard of a managed network or portion thereof. The SLA definition input may include a specification of an endpoint-level criterion or metric such as installation of a product update at a percentage or portion of the endpoints. ).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Berg with regards to the vulnerability compliance score to the method of Twigg in view of Alberti in order to mitigate the vulnerabilities that were detected in the system (Berg: ¶0004 & ¶0146).
With respect to claim 6, the combination of Twigg in view of Berg and Alberti teaches method of claim 1 (see rejection of claim 1 above) wherein the vulnerability comprises vulnerability to an attack or malware. (Twigg ¶0660-0665: The system may include one or more components that identify changes made by malware and provide recommended remediation steps to rollback capability. Additionally, the systems may include one or more components detect various application vulnerabilities and memory exploit techniques.).
With respect to claim 8, the combination of Twigg in view of Berg and Alberti teaches method of claim 1 (see rejection of claim 1 above) wherein the update comprises a vulnerability compliance resource. (Berg ¶0153: The product modification process may include distribution of at least one product update to a first product installed at the endpoint. The product update may include a patch, version update, vulnerability fix, and the like.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Berg with regards to the update to the view of the method of Twigg in view of Alberti in order to mitigate the vulnerabilities that were detected in the system (Berg: ¶0004 & ¶0146).
With respect to claim 9 , the combination of Twigg in view of Berg and Alberti teaches method of claim 1 (see rejection of claim 1 above) wherein the containerized workload environment comprises a Kubernetes environment. (Twigg ¶0102 & ¶0181: Deployment can also be performed using managed/hosted container management/orchestration frameworks such as Kubernetes, Mesos, and/or Docker Swarm. Further illustrated in Figure 1D embodiments of data platform 12 may be built using any suitable infrastructure as a service (IaaS) (e.g., AWS). Other infrastructure tools can also be used. Examples include: orchestration tools (e.g., Kubernetes or Mesos/Marathon)).
With respect to claim 11, Twigg teaches a non-transitory storage medium having stored therein instructions that are executable by one or more hardware processors to perform operations comprising: (¶0082: In some examples, a non-transitory computer-readable medium storing computer-readable instructions may be provided in accordance with the principles described herein. The instructions, when executed by a processor of a computing device, may direct the processor and/or computing device to perform one or more operations, including one or more of the operations described herein.) monitoring a containerized workload environment; (¶0059-0063: Figure 1A shows an illustrative configuration 10 in which a data platform 12 is configure to perform various operations with respect to a cloud environment 14 that includes a plurality of compute assets 16-1 through 16-N (collectively “computer assets 16”). Compute assets 16 may include but not limited to, containers (e.g., container images, deployed and executing container instances, etc.), virtual machines, workloads, and/or any other virtual and/or physical compute resources that may reside in and/or be executed by one or more compute resources in cloud environment 14. Data platform 12 may be configured to perform one or more data security monitoring and/or remediation services, compliance monitoring services, anomaly detection services, compute asset management services, and/or any other type of data analytics service.);
receiving, as a result of the monitoring, a trigger indicating when new vulnerability information about a system becomes available and when changes to the containerized workload environment occur; (¶0157-0158: Using technique described herein, data platform 12 can automatically discover entities (which may implement compute assets 16) deployed in given datacenter. Examples entities include workloads. The entities may be grouped together logically based on behavior can be established. Deviations from the expected normal behavior then be detected and automatically reported (e.g., as anomalies and threats detected) (indication when new vulnerability information about system and when changes to containerized workload environment occur) . Such deviations may be due to a desired change, a misconfiguration, or malicious activity.);
Twigg does not disclose:
parsing the trigger and modifying vulnerability compliance resources for the system based on the parsing;
performing a reconciliation; and calculating a vulnerability compliance score for the system.
However, Berg teaches parsing the trigger and modifying vulnerability compliance resources for the system based on the parsing; (¶0152-0153: Figure 6, shows an example method 600 of product management in a managed network. The method 600 may be implemented for vulnerability detection and mitigation or other management operations in managed network. Responsive to the trigger event being detected (“YES” at block 608), the method 600 may prevent to block 609.) At block 609, a scan may be initiated. For instance, a local scan, a network scan, a global scan, or some combination thereof may be initiated. The scan may be performed to identify trigger events or other inconsistencies with the defined state throughout the managed network or the cloud network. At block 610, a product modification process may be automatically implemented. The product modification process may include distribution of at least one product update to a first product installed at the endpoint. The product update may include a patch, version update, vulnerability fix, and the like.);
performing a reconciliation; (¶0154-0155: At block 612, SLA compliance may be assessed or evaluated. For instance, in some embodiments, the defined state may at least partially include a service level agreement (SLA). In these and other embodiments, the at least one condition of the defined state includes a metric used to measure compliance with the SLA. The scan of block 609 may result in SLA compliance data at a time of the scan. In some embodiments, the method 600 may proceed from 609 to 612 without implementing the operations of block 610. For instance, an evaluation of compliance may be wanted without necessarily correcting outstanding deficiencies.);
and calculating a vulnerability compliance score for the system. (¶0157-0159: At block 612, Furthermore, Figure 7 illustrates and example method 700 of assessing real-time SLA compliance. At block 708, display SLA compliance may be caused. The method 700 may be implemented as part of another method or process such as block 612 of the method 600. For example, in embodiments of the method 600 in which the defined state at least partially includes an SLA, the method 700 may be included in block 612. The SLA compliance data includes data representatives of whether endpoints of the SLA group are SLA compliant or SLA non-compliant at a time of the scan (calculating compliance score for the system).);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Berg with regards to a parsing and modifying vulnerability compliance resources based on parsing, performing reconciliation for the system, and calculating a vulnerability compliance score, to the view of the method of Twigg in order to ensure the products are property functioning and to ensure cybersecurity vulnerabilities are addressed (Berg: ¶0004).
Twigg in view of Berg does not disclose:
updating a catalogue that lists the modified vulnerability compliance resources for the system implementing the update in the system to address the trigger;
However, Alberti teaches updating a catalogue that lists the modified vulnerability compliance resources for the system implementing the update in the system to address the trigger; (¶0009 &¶0034: The method includes the step of providing a set of software patches; each patch is intended to correct at least one problem (by modifying at least one software product) (addressing the trigger). The method continues selecting a subset of patch together with one or more target entities for each selected patch; the operation is performed according to a (vulnerability) catalogue, which provides an indication of the exposure to the problems by each entity. A distribution plan is then built; for each selected patch the distribution plan includes an activity, which is intended to apply a software package on the corresponding target entities. Further the prior art illustrates explicitly updating a catalog in Figure 2, wherein the automation engine 225 retrieves the available information (patch definitions and patch catalogue) for the patches that have been approved from the corresponding repositories 210 and 215 (through the patch manager 205). As it will be apparent in the following, the automation engine 225 generates a corresponding distribution plan for installing the approved patches (simply referred to as patches from now on). For this purpose, the automation engine 225 accesses a vulnerability catalogue 230; for each endpoint, the catalogue 230 lists its exposures to the problems of the (approved) patches (for example, in the form of the patches that should be required). );
It is noted that Berg does teach the modification of vulnerability compliance resources for the system implementing the update in the system to address the trigger as seen in ¶0153 (wherein in an update is implemented according the modifications) , but the prior art does not teach updating a catalogue. Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Alberti with regards to updating a catalogue, to the view of the method of Twigg in view of Berg in order to prevent exposure the of the system to malicious attacks, such as hackers (also because those vulnerabilities are now public) and better reliability of security. (Alberti: ¶0002-0007).
With respect to claim 12, the combination of Twigg in view of Berg and Alberti teaches the non-transitory storage medium of claim 11 (see rejection of claim 11 above) wherein the update comprises any one or more of: a software update; a hardware update; or a firmware update. (Berg ¶0152-0153: Figure 6, shows an example method 600 of product management in a managed network. The method 600 may be implemented for vulnerability detection and mitigation or other management operations in managed network. At block 610, a product modification process may be automatically implemented. The product update may include a patch, version update, vulnerability fix, and the like. Additionally or alternatively, the product modification process may be configured to remove an installed product, replace an installed product, change to a setting or feature on an installed product, etc.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Berg with regards to the update to the method of Twigg in view of Alberti in order to mitigate the vulnerabilities that were detected in the system (Berg: ¶0004 & ¶0146).
With respect to claim 13, the combination of Twigg in view of Berg and Alberti teaches the non-transitory storage medium of claim 11 (see rejection of claim 11 above) wherein the update is implemented automatically after receipt of the trigger. ( Berg ¶0069 & ¶0153: As seen in Figure 6, at block 610, a product modification process may be automatically implemented. The product modification process may include distribution of at least one product update to a first product installed at the endpoint. The product update may include a patch, version update, vulnerability fix, and the like. It is further illustrated in Figure 1, wherein the update modules 116/120 may automatically implement of a product modification process, responsive to detection of the trigger events. The product modification process is configured to at least partially restore the endpoint 106 or a set of the endpoints 106 to the defined state. ).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Berg with regards to the update to the method of Twigg in view of Alberti in order to mitigate the vulnerabilities that were detected in the system (Berg: ¶0004 & ¶0146).
With respect to claim 14, the combination of Twigg in view of Berg and Alberti teaches the non-transitory storage medium of claim 11 (see rejection of claim 11 above) wherein the trigger is generated in response to one of: passage of a defined time interval; an addition or change to the system; or a change in the containerized workload environment. ( Twigg ¶0075: One or more operation performed by data processing resources 20 may be performed periodically according to a predetermined schedule. For example, one or more operations may be performed by data processing resources 20 every hour or any other suitable time interval. In this manner, the results of such operations (e.g., one or more detected anomalies in the data) may be provided to one or more external entities in substantially real-time and/or in near real-time. ).
With respect to claim 15, the combination of Twigg in view of Berg and Alberti teaches the non-transitory storage medium of claim 11 (see rejection of claim 11 above) wherein the vulnerability compliance score indicates an extent to which the system is in compliance with an established standard. (Berg ¶0157-0158: As seen in Figure 7 shows a flow chart of an example method 700 of accessing real-time SLA compliance. In these and other embodiments, at least one condition of the defined state may include a metric used to measure compliance with the SLA. It is also further illustrated in Figure 10 where it shows method of 1000 of real-time, endpoint-level SLA compliance evaluation in managed network (which also could be applied since both methods assessing compliance in real time). The method 1000 may begin at block 1002 in which SLA definition input may be received. For instance, the SLA definition input may be received from a management device such as the first management device 102 or the cloud server 122. The SLA definition input may be configured to indicate an SLA definition for an SLA standard of a managed network or portion thereof. The SLA definition input may include a specification of an endpoint-level criterion or metric such as installation of a product update at a percentage or portion of the endpoints. ).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Berg with regards to the vulnerability compliance score to the method of Twigg in view of Alberti in order to mitigate the vulnerabilities that were detected in the system (Berg: ¶0004 & ¶0146).
With respect to claim 16, the combination of Twigg in view of Berg and Alberti teaches the non-transitory storage medium of claim 11 (see rejection of claim 11 above) wherein the vulnerability comprises vulnerability to an attack or malware. (Twigg ¶0660-0665: The system may include one or more components that identify changes made by malware and provide recommended remediation steps to rollback capability. Additionally, the systems may include one or more components detect various application vulnerabilities and memory exploit techniques.).
With respect to claim 18, the combination of Twigg in view of Berg and Alberti teaches the non-transitory storage medium of claim 11 (see rejection of claim 11 above) wherein the update comprises a vulnerability compliance resource. (Berg ¶0153: The product modification process may include distribution of at least one product update to a first product installed at the endpoint. The product update may include a patch, version update, vulnerability fix, and the like.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Berg with regards to the update to the view of the method of Twigg in view of Alberti in order to mitigate the vulnerabilities that were detected in the system (Berg: ¶0004 & ¶0146).
With respect to claim 19, the combination of Twigg in view of Berg and Alberti teaches the non-transitory storage medium of claim 11 (see rejection of claim 11 above) wherein the containerized workload environment comprises a Kubernetes environment. (Twigg ¶0102 & ¶0181: Deployment can also be performed using managed/hosted container management/orchestration frameworks such as Kubernetes, Mesos, and/or Docker Swarm. Further illustrated in Figure 1D embodiments of data platform 12 may be built using any suitable infrastructure as a service (IaaS) (e.g., AWS). Other infrastructure tools can also be used. Examples include: orchestration tools (e.g., Kubernetes or Mesos/Marathon)).
Claims 7 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Twigg et al. (US PGPub No. 20230075355-A1) in view of Berg et al. (US PGPub No. 20240430179-A1), Alberti et al. (US PGPub No. 20060265630-A1), and Bach et al. (US PGPub No. 20160078231-A1 ) .
With respect to claim 7, the combination of Twigg in view of Berg and Alberti teaches method of claim 1 (see rejection of claim 1 above) wherein an administrator is notified automatically when the trigger is received.
However, Bach teaches wherein an administrator is notified automatically when the trigger is received. ( ¶0079: As seen in Figure 2, upon identifying a vulnerability, vulnerability processing system 250 transmits a notification message 260 to the corresponding operator 270. The message may be transmitted in any computer-based communication format, including email or a dedicated messaging system associated with vulnerability scanning and notification system 200.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Bach with regards to automatic notification to the method of Twigg in view of Berg and Alberti in order to efficiently address vulnerabilities in a system (Bach: ¶0001).
With respect to claim 17, the combination of Twigg in view of Berg and Alberti teaches the non-transitory storage medium of claim 11 (see rejection of claim 11 above) but does not disclose, wherein an administrator is notified automatically when the trigger is received.
However, Bach teaches wherein an administrator is notified automatically when the trigger is received. ( ¶0079: As seen in Figure 2, upon identifying a vulnerability, vulnerability processing system 250 transmits a notification message 260 to the corresponding operator 270. The message may be transmitted in any computer-based communication format, including email or a dedicated messaging system associated with vulnerability scanning and notification system 200.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Bach with regards to automatic notification , to the view of the method of Twigg in view of Berg and Alberti in order to efficiently address vulnerabilities in a system (Bach: ¶0001).
Claims 10 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Twigg et al. (US PGPub No. 20230075355-A1) in view of Berg et al. (US PGPub No. 20240430179-A1), Alberti et al. (US PGPub No. 20060265630-A1), and Rogers et al. (US PGPub No. 20210352099-A1) .
With respect to claim 10 , the combination of Twigg in view of Berg and Alberti teaches method of claim 1 (see rejection of claim 1 above) wherein results of the vulnerability compliance calculation are stored in a vulnerability compliance registry for the containerized workload environment.
However, Rogers teaches wherein results of the vulnerability compliance score are stored (¶0023-0028: Calculation of the risk scores can recur c based on an evaluation frequency associated with each risk object. The resulting scores are stored for future reference and/or time series or trending analyses. In one example, each of the resulting scores for each calculation is stored for each risk object as a node in the risk hierarchy with an edge connecting the risk score node to the risk object node. In one embodiment, the risk hierarchy is stored as a graph database with nodes representing the risk objects, the risk scenarios, and the mitigating controls, and edges representing the associations between the risk objects and the risk scenarios and the associations between the risk scenarios and the mitigating.) in a vulnerability compliance registry for the containerized workload environment. (¶0094 & ¶0311-0312: The entity relationship graph subsystem 126 further comprises a graph access service 246 and a graph server 248, the latter of which in turn comprises a graph query interface 132. The server system 118 also comprises one or more data stores 164 for persistently storing and managing collections of data, including databases such as a graph database 140, in one or more memory components 54, 56, 58 (for example)).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Rogers with regards to storing a vulnerability calculation to the of the method of Twigg in view of Berg and Alberti in order to be referenced for the future analyses (Rogers : ¶0027).
With respect to claim 20, the combination of Twigg in view of Berg and Alberti teaches the non-transitory storage medium of claim 11 (see rejection of claim 11 above) but does not disclose, wherein results of the vulnerability compliance calculation are stored in a vulnerability compliance registry for the containerized workload environment.
However, Rogers teaches wherein results of the vulnerability compliance score are stored (¶0023-0028: Calculation of the risk scores can recur c based on an evaluation frequency associated with each risk object. The resulting scores are stored for future reference and/or time series or trending analyses. In one example, each of the resulting scores for each calculation is stored for each risk object as a node in the risk hierarchy with an edge connecting the risk score node to the risk object node. In one embodiment, the risk hierarchy is stored as a graph database with nodes representing the risk objects, the risk scenarios, and the mitigating controls, and edges representing the associations between the risk objects and the risk scenarios and the associations between the risk scenarios and the mitigating.) in a vulnerability compliance registry for the containerized workload environment. (¶0094 & ¶0311-0312: The entity relationship graph subsystem 126 further comprises a graph access service 246 and a graph server 248, the latter of which in turn comprises a graph query interface 132. The server system 118 also comprises one or more data stores 164 for persistently storing and managing collections of data, including databases such as a graph database 140, in one or more memory components 54, 56, 58 (for example)).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Rogers with regards to storing a vulnerability calculation , to the view of the method of Twigg in view of Berg and Alberti in order to be referenced for the future analyses (Rogers : ¶0027).
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 TAYLOR P VU whose telephone number is (703)756-1218. The examiner can normally be reached MON - FRI (7:30 - 5: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, Alexander Lagor can be reached at (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.
/T.P.V./ Examiner, Art Unit 2437
/ALEXANDER LAGOR/Supervisory Patent Examiner, Art Unit 2437
Prosecution Insights