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 06/02/2026. Claims 1, 8, 10, 11, 18, and 20 have been amended. Claims 1-20 are currently pending.
Applicant’s amendments filed on 06/02/2026 with regards to 35 USC 112(a) and 35 USC 112(b), as seen in page 6-7, have been fully considered and fully persuasive. Therefore, the rejection has been withdrawn.
Applicant’s arguments and amendments with regards to 35 USC 103 with respect to 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), as seen in pages 7-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 ground of rejection in view of Morello et al. (US PGPub No. 20180260574-A1), Helander et al. (US Pat No. 10728284-B2), Larkin et al. (US PG Pub No. 20240289745-A1), Goldsteen et al. (US PGPub No. 20240362337-A1), Roche et al. (US PGPub No. 20200126085-A1), Rappaport et al. (US Pat No. 12141291-B1), Mizushima et al. (US PGPub No. 20230017839-A1), and Dunn et al. (US PGPub No. 20230336581-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 are 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.
Claim 1 and 11 recites the limitation of ”detecting that one or more vulnerability compliance resources associated with the system differ between a desired state and an existing state as needing a vulnerability compliance calculation”. The limitation is claimed at a high level abstraction and in purely functional terms. The specifications fails to demonstrate the applicant possessed the term of a “desired state”. As explained in MPEP § 2161.01, the written description requirement is separate and distinct from enablement, and requires that the specification describe the claimed invention in sufficient detail that one of ordinary skill in the art can reasonably conclude that the inventor had possession of the claimed invention at the time of filing. This requirement applies computer-implemented invention recited functional ,and simply restating the claimed function, or a desired result is not sufficient. Rather, the specification must disclose the computer and the algorithm, steps, or procedure for performing the claimed function in sufficient detail to show possession of that functionality. See Ariad Pharm., Inc. v. Eli Lilly & Co., 598 F.3d 1336, 1351 (Fed. Cir. 2010); LizardTech, Inc. v. Earth Res. Mapping, Inc., 424 F.3d 1336, 1345-46 (Fed. Cir. 2005); Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 681-83 (Fed. Cir. 2015); Finisar Corp. v. does not disclose what type of algorithm, structure, architecture, workflow, or generation criteria is used to obtain the desired state or define the desired state. The specification does not reasonably convey possession of the full scope of a “desired state”. Further, the specification does not sufficiently does not disclose any criteria, structure, threshold of differences, or type of algorithm is used to produce the result of needing of a vulnerability compliance calculation. Thus, it describes only the result to be achieved by comparing the desired state rather than demonstrating passion of the broadly claimed desired state itself. Therefore, the specification does not reasonably convey to one or ordinary skill in the art that Applicant had possession of the full scope of the desired state at the time of filing.
Claim 1 and 11 recites the limitation of ” calculating a vulnerability compliance score for the system by weighting hardware, firmware, and software component scores”. The limitation is claimed at a high level abstraction and in purely functional terms. The specifications fails to demonstrate the applicant possessed the steps of weighting hardware, firmware, and software component scores. As explained in MPEP § 2161.01, the written description requirement is separate and distinct from enablement, and requires that the specification describe the claimed invention in sufficient detail that one of ordinary skill in the art can reasonably conclude that the inventor had possession of the claimed invention at the time of filing. This requirement applies computer-implemented invention recited functional ,and simply restating the claimed function, or a desired result is not sufficient. Rather, the specification must disclose the computer and the algorithm, steps, or procedure for performing the claimed function in sufficient detail to show possession of that functionality. See Ariad Pharm., Inc. v. Eli Lilly & Co., 598 F.3d 1336, 1351 (Fed. Cir. 2010); LizardTech, Inc. v. Earth Res. Mapping, Inc., 424 F.3d 1336, 1345-46 (Fed. Cir. 2005); Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 681-83 (Fed. Cir. 2015); Finisar Corp. v. does not disclose what type of algorithm, structure, architecture, workflow, or generation criteria is used to weight the hardware, firmware, and software component scores. Thus, it describes only the result to be achieved by weighting hardware, firmware, and software component scores rather than demonstrating passion of the broadly claimed weight the scores itself. However, under MPEP § 2161.01 and the cited case law, identifying relevant inputs or factors does not by itself provide adequate written description support for a functionally claimed determination unless the specification also explains how those factors are actually used to perform the process of generating the prompt. Thus, the application describes only the result to be achieved by the claimed weighting, rather than demonstrating possession of the broadly claimed generation of a prompt itself. Therefore, the specification does not reasonably convey to one of ordinary skill in the art that Applicant had possession of the full scope of the claimed weighting scores at the time of filing.
Claims 2-10 and 12-20 do not overcome the rejection of their respective base claims that have been rejected above, and therefore rejected under the same grounds provided to claims 1 and 11 .
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 are 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:
The claims recite the step of obtaining a vulnerability. The omitted steps are what inputs are being used to obtain/detect vulnerability by the computing system within the independent claims. The independent claims only disclose how the vulnerability compliance is obtained. The independent claim does not disclose any inputs being used to detect or derive a vulnerability. Further, the independent claims do not disclose how the vulnerability is obtained by the computing system.
Regarding claims 1 and 11:
“…desired state…”
Indefinite because the claim does not specify constitutes as what is the desired state nor how it is derived from. The claim does not provide no definition of what “desired state” entails (e.g., user define or administrator defined) . Additionally, the limitation is indefinite because it provides no objective boundaries or metrics in which person having ordinary in the art can determine or apply “desired state”.
Claims 2-10 and 12-20 do not overcome the rejection of their respective base claims that
have been rejected above, and therefore rejected under the same grounds provided to claims 1 and 11.
Regarding claims 5 and 15:
“…established standard…”
Indefinite because the claim does not specify constitutes as what is the established standard nor how it is derived from. The claim does not provide no definition of what “established standard” entails (e.g., user define, administrator defined, SLA, or something else) . Additionally, the limitation is indefinite because it provides no objective boundaries or metrics in which person having ordinary in the art can determine or apply “established standard”.
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, 4, 8, 9, 11, 12, 14, 18, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Morello et al. (US PGPub No. 20180260574-A1) in view of Helander et al. (US Pat No. 10728284-B2), Larkin et al. (US PG Pub No. 20240289745-A1), Goldsteen et al. (US PGPub No. 20240362337-A1), and Roche et al. (US PGPub No. 20200126085-A1).
With respect to claim 1, Morello teaches a method, comprising: monitoring a containerized workload environment; (¶0042: Detection of unknown vulnerabilities is performed on each APP container 311 when APP container is executed. To this end, the detector container 315 is configured to monitor system calls indicative of instantiation, running, or new APP container (e.g., the container 311-2). Based on the monitoring, anomalous behavior may be identified.);
receiving, as a result of the monitoring, a trigger indicating one of: (i) when new vulnerability information about a system becomes available or (i) when a change to the system or the containerized workload environment occurs; (¶0062: Figure 6 is an example flowchart 600 illustrating a method for detecting known vulnerabilities in software containers at runtime. At S610, events triggered as a result of changes to the top (application) layer of an APP container (e.g., one of the APP containers 311, Figure 3 are monitored.). (changes to the system or containerized workload environment occurs). It should be noted that the evaluation of newly modified or new files can be performed in the same manner described as long as the changes are made to the top layer of an APP container.);
Morello does not disclose:
parsing the trigger and modifying vulnerability compliance resources for the system based on the parsing,
However, Helander teaches parsing the trigger and modifying vulnerability compliance resources for the system based on the parsing, (¶0062: In the illustrated example of Figure 5, the compliance assessor includes the example resource identifier 512 to identify one or more computing resources associated with a detected event. For example, the resource identifier 512 of the illustrated example parses the notification message retrieved from the example event monitor 510 to identify one or more computing resources. In some examples, the resource identifier 510 may identify additional information regarding the computing resources such as the new state of the computing resources (modifying vulnerability compliance resources for system based on parsing) , other computing resources related to the event-associated computing resources (e.g., via the inventory list generated by the inventory builder 502), etc. (catalogue specific to the system and as seen in ¶0054: In some examples, the inventory builder 502 registers the computing resources as an inventory list. As used herein, an inventory list is a dynamic list of computing resources that relate to other computing resources. In some examples, the inventory list may be organized by inventory type. For example, selecting a cluster list (e.g., via a web access client) may return identities or indications of all clusters in the virtual computing environment 100 (specific the system) as well as lists of all resource types that relate to the cluster (or clusters) selected.) );
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 Helander with regards to parsing a trigger and modifying a resource based off of the parsing in the system to the method of Morello in order to increase the security of computing environment and to effectively respond to changes in the environment (e.g., events) (Helander: ¶0017-0021).
Morello in view of Helander does not disclose:
wherein the vulnerability compliance resources comprise one or more hardware, firmware, or software compliance resources associated with the system and listed in a catalogue specific to the system; updating a catalogue that lists the modified vulnerability compliance resources for the system; implementing the update in the system to address a vulnerability of the system;
However, Larkin teaches wherein the vulnerability compliance resources comprise one or more hardware, firmware, or software compliance resources associated with the system and listed in a catalogue specific to the system; (¶0115: A host software catalogue is a list of software packages and constituent files on the machine running the component (software compliance resources associated with system) , indexed by hostname and IP address. This information is periodically gathered and uploaded to the TIAP portal to assist with analytics (specifically a common vulnerabilities and exposures (CVE) service). Further in ¶0147 discloses wherein, the API service 736 can also provide REST APIs to manage entities stored in a CVE database. A CVE API can produce a list of CVEs components that are vulnerable. )
updating a catalogue that lists the modified vulnerability compliance resources for the system; (¶0152: CVE Service 740 identifies which CVEs, which identify components having known vulnerabilities 741. CVE service 740 can include CVEs that are created and maintained by TIAP 700. CVE service 740 can use a CVE database, which can be populated from a CVE pack. For example, the CVE database may include a snapshot or copy of various CVE databases that is updated on demand or at regular intervals. CVE service 740 can retrieve a list of CVEs from the CVE database. CVE service 740 periodically scans the event database and determines if any components are vulnerable to CVE.);
implementing the update in the system to address a vulnerability of the system; (¶0155: Remediation service 770 can locate updated versions of the components found to be vulnerable or categorized as having a priority alert and package the updated versions into a script that can be downloaded and run so that the user can update all the vulnerable components, priority alert components, or combination thereof. );
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 Larkin with regards to the vulnerability compliance resource, updating the system and catalogue to the method of Morello in view of Helander in order to ensure that any defects are properly vetted and prevent unknown/ potentially components are used in the system (Larkin ¶0004-0005).
Morello in view of Larkin and Helander does not disclose:
performing a reconciliation for the system comprising detecting that one or more vulnerability compliance resources associated with the system differ between a desired state and an existing state associated with the system to identify the system as needing a vulnerability compliance calculation; and
However, Goldsteen teaches performing a reconciliation for the system comprising detecting that one or more vulnerability compliance resources associated with the system differ between a desired state and an existing state associated with the system to identify the system as needing a vulnerability compliance calculation; and (¶0044-0046: The system 400 comprises a score tracking component 428. The score tracking component can track changes to a customized risk assessment score over time. Over time, the most appropriate risk assessment requirements for a model may change. For example, new regulations or policies may be imposed. For example, new data from the model may indicate new vulnerabilities that need to be addressed (e.g., via new relevant dimensions or metric). In an embodiment, the score tracking component 428 can alert user or other entity to changes that may necessitate a new risk assessment (needing a vulnerability compliance calculation). For example, change can be a score falling below a predetermined threshold (differing from the desired state because the score falls below a threshold). );
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 Goldsteen with regards to a performing a reconciliation based on detecting resources being different from an existing state and a desired state to identify the need for a calculation to the method of Morello in view of Helander and Larkin in order to better manage risk and better adapt to new risks being introduced (Goldsteen: ¶0022 & ¶0044).
Morello in view of Helander, Larkin, and Goldsteen does not disclose:
calculating a vulnerability compliance score for the system by weighting hardware, firmware, and software component scores and aggregating the weighted scores.
However, Roche teaches calculating a vulnerability compliance score for the system by weighting hardware, firmware, and software component scores and aggregating the weighted scores. (¶0066: Thus, the pre-transaction 125 may assign weights to one or more of the hardware, software, an/or firmware components of the computing device, and then aggregate the various weights to score the device score (vulnerability compliance score for the system). The aggregation of the individual weights may be based upon computer modeling, applying a mathematical function (e.g., average), 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 Roche with regards to calculating a score for a system by weighting hardware, firmware, and software scores and aggregating the weight scores to the method of Morello in view of Helander, Larkin, and Goldsteen in order to better detect fraudulence and indicate if the device/system have been compromised (Roche: ¶0002 & ¶0067).
With respect to claim 2, the combination of Morello in view of Helander, Larkin, Goldsteen, and Roche 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. (Larkin ¶0173: Fixed versions of vulnerable components 826 can define updates to components that are identified as being vulnerable. Fixed components can be included in a script that is made available to a user for download. When the user downloads the script and it run, the components contained therein can be used to update legacy components being used by the application or container. After the components have been updated (software update), the user can re-run a SBOM/CVE analysis to verify that no further vulnerabilities exist for the application or software image. );
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 Larkin with regards to the vulnerability compliance resource, updating the system and catalogue to the method of Morello in view of Helander, Goldsteen, and Roche in order to ensure that any defects are properly vetted and prevent unknown/ potentially components are used in the system (Larkin ¶0004-0005).
With respect to claim 4, the combination of Morello in view of Helander, Larkin, Goldsteen, and Roche 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. (Helander ¶0062: Figure 6 is an example flowchart 600 illustrating a method for detecting known vulnerabilities in software containers at runtime. At S610, events triggered as a result of changes to the top (application) layer of an APP container (e.g., one of the APP containers 311, Figure 3 are monitored.). (changes to the system or containerized workload environment occurs). It should be noted that the evaluation of newly modified or new files can be performed in the same manner described as long as the changes are made to the top layer of an APP container.);
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 Helander with regards to parsing a trigger and modifying a resource based off of the parsing in the system to the method of Morello in view of Larkin, Goldsten, and Roche in order to increase the security of computing environment and to effectively respond to changes in the environment (e.g., events) (Helander: ¶0017-0021).
With respect to claim 8, the combination of Morello in view of Helander, Larkin, Goldsteen, and Roche, teaches method of claim 1 (see rejection of claim 1 above), wherein the comprises a vulnerability compliance resource comprise one or more hardware, or software compliance associated with the system. (Larkin ¶0115: A host software catalogue is a list of software packages and constituent files on the machine running the component (software compliance resources associated with system) , indexed by hostname and IP address. This information is periodically gathered and uploaded to the TIAP portal to assist with analytics (specifically a common vulnerabilities and exposures (CVE) service). Further in ¶0147 discloses wherein, the API service 736 can also provide REST APIs to manage entities stored in a CVE database. A CVE API can produce a list of CVEs components that are vulnerable. )
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 Larkin with regards to the vulnerability compliance resource to the method of Morello in view of Helander, Goldsteen, and Roche in order to ensure that any defects are properly vetted and prevent unknown/ potentially components are used in the system (Larkin ¶0004-0005).
With respect to claim 9 , the combination of Morello in view of Helander, Goldsteen, Larkin, Goldsteen, and Roche teaches method of claim 1 (see rejection of claim 1 above) wherein the containerized workload environment comprises a Kubernetes environment. (Morello ¶0039: In an optional deployment, the console device 320 also interfaces with one or more external systems 330 through the network 340. Examples for such external systems 330 may include, but are not limited to, an active directory of an origination to retrieve user permissions, access control systems (e.g., Docker Swarm, and Kubernetes management plane), SIEM systems to report on detected vulnerabilities, audit and compliance systems, and the like.).
With respect to claim 11, Morello teaches a non-transitory storage medium having stored therein instructions that are executable by one or more hardware processors to perform operations comprising: (¶0093: The various embodiments disclosed herein can be implemented as hardware, firmware, software, or any combination thereof. Moreover, the software is preferably implemented as an application program tangibly embodied on a program storage unit or computer readable medium consisting of parts, or of certain devices and/or a combination of devices. The various processes and functions described herein may be either part of the microinstruction code or part of the application program, or any combination thereof, which may be executed by a CPU, whether or not such a computer or processor is explicitly shown. Furthermore, a non-transitory computer readable medium is any computer readable medium except for a transitory propagating signal.);
monitoring a containerized workload environment; receiving, as a result of the monitoring, a trigger indicating one of: (i) when new vulnerability information about a system becomes available or (ii) when a change to the system or the containerized workload environment occurs; (¶0062: Figure 6 is an example flowchart 600 illustrating a method for detecting known vulnerabilities in software containers at runtime. At S610, events triggered as a result of changes to the top (application) layer of an APP container (e.g., one of the APP containers 311, Figure 3 are monitored.). (changes to the system or containerized workload environment occurs). It should be noted that the evaluation of newly modified or new files can be performed in the same manner described as long as the changes are made to the top layer of an APP container.);
Morello does not disclose:
parsing the trigger and modifying vulnerability compliance resources for the system based on the parsing,
However, Helander teaches parsing the trigger and modifying vulnerability compliance resources for the system based on the parsing, (¶0062: In the illustrated example of Figure 5, the compliance assessor includes the example resource identifier 512 to identify one or more computing resources associated with a detected event. For example, the resource identifier 512 of the illustrated example parses the notification message retrieved from the example event monitor 510 to identify one or more computing resources. In some examples, the resource identifier 510 may identify additional information regarding the computing resources such as the new state of the computing resources (modifying vulnerability compliance resources for system based on parsing) , other computing resources related to the event-associated computing resources (e.g., via the inventory list generated by the inventory builder 502), etc. (catalogue specific to the system and as seen in ¶0054: In some examples, the inventory builder 502 registers the computing resources as an inventory list. As used herein, an inventory list is a dynamic list of computing resources that relate to other computing resources. In some examples, the inventory list may be organized by inventory type. For example, selecting a cluster list (e.g., via a web access client) may return identities or indications of all clusters in the virtual computing environment 100 (specific the system) as well as lists of all resource types that relate to the cluster (or clusters) selected.) );
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 Helander with regards to parsing a trigger and modifying a resource based off of the parsing in the system to the method of Morello in order to increase the security of computing environment and to effectively respond to changes in the environment (e.g., events) (Helander: ¶0017-0021).
Morello in view of Helander does not disclose:
wherein the vulnerability compliance resources comprise one or more hardware, firmware, or software compliance resources associated with the system and listed in a catalogue specific to the system;
updating a catalogue that lists the modified vulnerability compliance resources for the system;
implementing the update in the system to address a vulnerability of the system;
However, Larkin teaches wherein the vulnerability compliance resources comprise one or more hardware, firmware, or software compliance resources associated with the system and listed in a catalogue specific to the system; (¶0115: A host software catalogue is a list of software packages and constituent files on the machine running the component (software compliance resources associated with system) , indexed by hostname and IP address. This information is periodically gathered and uploaded to the TIAP portal to assist with analytics (specifically a common vulnerabilities and exposures (CVE) service). Further in ¶0147 discloses wherein, the API service 736 can also provide REST APIs to manage entities stored in a CVE database. A CVE API can produce a list of CVEs components that are vulnerable. );
updating a catalogue that lists the modified vulnerability compliance resources for the system; (¶0152: CVE Service 740 identifies which CVEs, which identify components having known vulnerabilities 741. CVE service 740 can include CVEs that are created and maintained by TIAP 700. CVE service 740 can use a CVE database, which can be populated from a CVE pack. For example, the CVE database may include a snapshot or copy of various CVE databases that is updated on demand or at regular intervals. CVE service 740 can retrieve a list of CVEs from the CVE database. CVE service 740 periodically scans the event database and determines if any components are vulnerable to CVE.);
implementing the update in the system to address a vulnerability of the system; (¶0155: Remediation service 770 can locate updated versions of the components found to be vulnerable or categorized as having a priority alert and package the updated versions into a script that can be downloaded and run so that the user can update all the vulnerable components, priority alert components, or combination thereof. );
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 Larkin with regards to the vulnerability compliance resource, updating the system and catalogue to the method of Morello in view of Helander in order to ensure that any defects are properly vetted and prevent unknown/ potentially components are used in the system (Larkin ¶0004-0005).
Morello in view of Larkin and Helander does not disclose:
performing a reconciliation for the system comprising detecting that one or more vulnerability compliance resources associated with the system differ between a desired state and an existing state associated with the system to identify the system as needing a vulnerability compliance calculation; and
However, Goldsteen teaches performing a reconciliation for the system comprising detecting that one or more vulnerability compliance resources associated with the system differ between a desired state and an existing state associated with the system to identify the system as needing a vulnerability compliance calculation; and (¶0044-0046: The system 400 comprises a score tracking component 428. The score tracking component can track changes to a customized risk assessment score over time. Over time, the most appropriate risk assessment requirements for a model may change. For example, new regulations or policies may be imposed. For example, new data from the model may indicate new vulnerabilities that need to be addressed (e.g., via new relevant dimensions or metric). In an embodiment, the score tracking component 428 can alert user or other entity to changes that may necessitate a new risk assessment (needing a vulnerability compliance calculation). For example, change can be a score falling below a predetermined threshold (differing from the desired state because the score falls below a threshold). );
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 Goldsteen with regards to a performing a reconciliation based on detecting resources being different from an existing state and a desired state to identify the need for a calculation to the method of Morello in view of Helander and Larkin in order to better manage risk and better adapt to new risks being introduced (Goldsteen: ¶0022 & ¶0044).
Morello in view of Helander, Larkin, and Goldsteen does not disclose:
calculating a vulnerability compliance score for the system by weighting hardware, firmware, and software component scores and aggregating the weighted scores.
However, Roche teaches calculating a vulnerability compliance score for the system by weighting hardware, firmware, and software component scores and aggregating the weighted scores. (¶0066: Thus, the pre-transaction 125 may assign weights to one or more of the hardware, software, an/or firmware components of the computing device, and then aggregate the various weights to score the device score (vulnerability compliance score for the system). The aggregation of the individual weights may be based upon computer modeling, applying a mathematical function (e.g., average), 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 Roche with regards to calculating a score for a system by weighting hardware, firmware, and software scores and aggregating the weight scores to the method of Morello in view of Helander, Larkin, and Goldsteen in order to better detect fraudulence and indicate if the device/system have been compromised (Roche: ¶0002 & ¶0067).
With respect to claim 12, the combination of Morello in view of Helander, Larkin, Goldsteen, and Roche 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. (Larkin ¶0173: Fixed versions of vulnerable components 826 can define updates to components that are identified as being vulnerable. Fixed components can be included in a script that is made available to a user for download. When the user downloads the script and it run, the components contained therein can be used to update legacy components being used by the application or container. After the components have been updated (software update), the user can re-run a SBOM/CVE analysis to verify that no further vulnerabilities exist for the application or software image. );
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 Larkin with regards to the vulnerability compliance resource, updating the system and catalogue to the method of Morello in view of Helander, Goldsteen, and Roche in order to ensure that any defects are properly vetted and prevent unknown/ potentially components are used in the system (Larkin ¶0004-0005).
With respect to claim 14, the combination of Morello in view of Helander, Larkin, Goldsteen, and Roche 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. (Helander ¶0062: Figure 6 is an example flowchart 600 illustrating a method for detecting known vulnerabilities in software containers at runtime. At S610, events triggered as a result of changes to the top (application) layer of an APP container (e.g., one of the APP containers 311, Figure 3 are monitored.). (changes to the system or containerized workload environment occurs). It should be noted that the evaluation of newly modified or new files can be performed in the same manner described as long as the changes are made to the top layer of an APP container.);
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 Helander with regards to parsing a trigger and modifying a resource based off of the parsing in the system to the method of Morello in view of Larkin, Goldsteen, and Roche in order to increase the security of computing environment and to effectively respond to changes in the environment (e.g., events) (Helander: ¶0017-0021).
With respect to claim 18, the combination of Morello in view of Helander, Larkin, Goldsteen, and Roche teaches the non-transitory storage medium of claim 11 (see rejection of claim 11 above) wherein the comprises a vulnerability compliance resource comprise one or more hardware, or software compliance associated with the system. (Larkin ¶0115: A host software catalogue is a list of software packages and constituent files on the machine running the component (software compliance resources associated with system) , indexed by hostname and IP address. This information is periodically gathered and uploaded to the TIAP portal to assist with analytics (specifically a common vulnerabilities and exposures (CVE) service). Further in ¶0147 discloses wherein, the API service 736 can also provide REST APIs to manage entities stored in a CVE database. A CVE API can produce a list of CVEs components that are vulnerable. )
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 Larkin with regards to the vulnerability compliance resource to the method of Morello in view of Helander, Goldsteen, and Roche in order to ensure that any defects are properly vetted and prevent unknown/ potentially components are used in the system (Larkin ¶0004-0005).
With respect to claim 19, the combination of Morello in view of Helander, Larkin, Goldsteen, and Roche teaches the non-transitory storage medium of claim 11 (see rejection of claim 11 above) wherein the containerized workload environment comprises a Kubernetes environment. (Morello ¶0039: In an optional deployment, the console device 320 also interfaces with one or more external systems 330 through the network 340. Examples for such external systems 330 may include, but are not limited to, an active directory of an origination to retrieve user permissions, access control systems (e.g., Docker Swarm, and Kubernetes management plane), SIEM systems to report on detected vulnerabilities, audit and compliance systems, and the like.).
Claims 3 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Morello et al. (US PGPub No. 20180260574-A1) in view of Helander et al. (US Pat No. 10728284-B2), Larkin et al. (US PG Pub No. 20240289745-A1), Goldsteen et al. (US PGPub No. 20240362337-A1), Roche et al. (US PGPub No. 20200126085-A1), and Berg et al. (US PGPub No. 20240430179-A1).
With respect to claim 3, the combination of Morello in view of Helander, Goldsteen, and Roche teaches method of claim 1 (see rejection of claim 1 above), but does not disclose wherein the update is implemented automatically after receipt of the trigger.
However, Berg teaches wherein the update is implemented automatically after receipt of the trigger. (¶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 is implemented automatically after receipt of the trigger to the method of Morello in view of Helander, Larkin, Goldsteen, and Roche in order to mitigate the vulnerabilities that were detected in the system (Berg: ¶0004 & ¶0146).
With respect to claim 13, the combination of Morello in view of Helander, Larkin, Goldsteen, and Roche teaches the non-transitory storage medium of claim 11 (see rejection of claim 11 above), but does not disclose wherein the update is implemented automatically after receipt of the trigger.
However, Berg teaches wherein the update is implemented automatically after receipt of the trigger. ( ¶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 is implemented automatically after receipt of the trigger to the method of Morello in view of Helander, Larkin, Goldsteen, and Roche in order to mitigate the vulnerabilities that were detected in the system (Berg: ¶0004 & ¶0146).
Claims 5 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Morello et al. (US PGPub No. 20180260574-A1) in view of Helander et al. (US Pat No. 10728284-B2), Larkin et al. (US PG Pub No. 20240289745-A1), Goldsteen et al. (US PGPub No. 20240362337-A1), Roche et al. (US PGPub No. 20200126085-A1), and Rappaport et al. (US Pat No. 12141291-B1).
With respect to claim 5, the combination of Morello in view of Helander, Larkin, Goldsteen, and Roche teaches method of claim 1 (see rejection of claim 1 above), but does not disclose wherein the vulnerability compliance score indicates an extent to which the system is in compliance with an established standard.
However, Rappaport teaches wherein the vulnerability compliance score indicates an extent to which the system is in compliance with an established standard. ( ¶0039: In an embodiment, a compliance score 405 is determined by a compliance engine 420. To this end, the compliance engine 420 determines the compliance of each developed application 201 with the security policies and standards predefined for the project, by the organization. The compliance engine 420 determines the compliance score 405 based on configuration compliance and security protection. In one embodiment, the configuration compliance is a measure of the product's conformance to baseline configuration standards to identify non-compliance, and for observing configuration drift over time. ).
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 Rappaport with regards to the vulnerability compliance score to the method of Morello in view of Helander, Larkin, Goldsteen, and Roche in order to identify non-compliance in the system/device and malicious cyber activity (Rappaport: ¶0009 & ¶0039).
With respect to claim 15, the combination of Morello in view of Helander, Larkin, Goldsteen, and Roche teaches the non-transitory storage medium of claim 11 (see rejection of claim 11 above), but does not disclose wherein the vulnerability compliance score indicates an extent to which the system is in compliance with an established standard.
However, Rappaport teaches wherein the vulnerability compliance score indicates an extent to which the system is in compliance with an established standard. ( ¶0039: In an embodiment, a compliance score 405 is determined by a compliance engine 420. To this end, the compliance engine 420 determines the compliance of each developed application 201 with the security policies and standards predefined for the project, by the organization. The compliance engine 420 determines the compliance score 405 based on configuration compliance and security protection. In one embodiment, the configuration compliance is a measure of the product's conformance to baseline configuration standards to identify non-compliance, and for observing configuration drift over time. ).
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 Rappaport with regards to the vulnerability compliance score to the method of Morello in view of Helander, Larkin, Goldsteen, and Roche in order to identify non-compliance in the system/device and malicious cyber activity (Rappaport: ¶0009 & ¶0039).
Claims 6 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Morello et al. (US PGPub No. 20180260574-A1) in view of Helander et al. (US Pat No. 10728284-B2), Larkin et al. (US PG Pub No. 20240289745-A1), Goldsteen et al. (US PGPub No. 20240362337-A1), Roche et al. (US PGPub No. 20200126085-A1), and Mizushima et al. (US PGPub No. 20230017839-A1).
With respect to claim 6, the combination of Morello in view of Helander, Larkin, Goldsteen, and Roche teaches method of claim 1 (see rejection of claim 1 above), but does not disclose wherein the vulnerability comprises vulnerability to an attack or malware.
However, Mizushima wherein the vulnerability comprises vulnerability to an attack or malware. (¶0052: Specifically, the analysis result collecting unit 101 collects information in regards to the vulnerability present in the asset on which the attack could be made (vulnerability to an attack), such as identification information of the vulnerability, information about the presence/absence of a proof-of-attack code, and information about an attack method that can be used.);
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 Mizushima with regards to the vulnerability comprises vulnerability to an attack or malware to the method of Morello in view of Helander, Larkin, Goldsteen, and Roche in order to protect the system by better identifying the details of the vulnerability (Mizushima: ¶0008-0009).
With respect to claim 16, the combination of Morello in view of Helander, Larkin, Goldsteen, and Roche teaches the non-transitory storage medium of claim 11 (see rejection of claim 11 above), but does not disclose wherein the vulnerability comprises vulnerability to an attack or malware.
However, Mizushima wherein the vulnerability comprises vulnerability to an attack or malware. (¶0052: Specifically, the analysis result collecting unit 101 collects information in regards to the vulnerability present in the asset on which the attack could be made (vulnerability to an attack), such as identification information of the vulnerability, information about the presence/absence of a proof-of-attack code, and information about an attack method that can be used.);
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 Mizushima with regards to the vulnerability comprises vulnerability to an attack or malware to the method of Morello in view of Helander, Larkin, Goldsteen, and Roche in order to protect the system by better identifying the details of the vulnerability (Mizushima: ¶0008-0009).
Claims 7 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Morello et al. (US PGPub No. 20180260574-A1) in view of Helander et al. (US Pat No. 10728284-B2), Larkin et al. (US PG Pub No. 20240289745-A1), Goldsteen et al. (US PGPub No. 20240362337-A1), Roche et al. (US PGPub No. 20200126085-A1), and Bach et al. (US PGPub No. 20160078231-A1 ) .
With respect to claim 7, the combination of Morello in view of Helander, Larkin, Goldsteen, and Roche 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 Morello in view of Helander, Larkin, Goldsteen, and Roche in order to efficiently address vulnerabilities in a system (Bach: ¶0001).
With respect to claim 17, the combination of Morello in view of Helander, Larkin, Goldsteen, and Roche 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 method of Morello in view of Helander, Larkin, Goldsteen, and Roche 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 Morello et al. (US PGPub No. 20180260574-A1) in view of Helander et al. (US Pat No. 10728284-B2), Larkin et al. (US PG Pub No. 20240289745-A1), Goldsteen et al. (US PGPub No. 20240362337-A1), Roche et al. (US PGPub No. 20200126085-A1), and Dunn et al. (US PGPub No. 20230336581-A1) .
With respect to claim 10 , the combination of Morello in view of Helander, Larkin, Goldsteen, and Roche teaches method of claim 1 (see rejection of claim 1 above) wherein the vulnerability compliance score is stored in a vulnerability compliance registry for the containerized workload environment as historical vulnerability compliance information associated with the system.
However, Dunn teaches wherein the vulnerability compliance score is stored in a vulnerability compliance registry for the containerized workload environment as historical vulnerability compliance information associated with the system. ( ¶0042: The CVE frequency estimator module can compare what is the best practice for updates/patches compared to what is the history of this specific network device currently has, and that delta in that comparison is information which feeds its way into the calculations of the device weakness score in the device weakness module (storing in vulnerability compliance registry). ¶0057: The device weakness score is generated based on what CVEs, the kind of CVE actually detected and how critical each CVE is that is associated with each separate network device, what software updates are required for each device, and other factors discussed herein. The device weakness score generator can also factor in those vulnerabilities that are associated with that network device, the update frequency to remedy those vulnerabilities, and historical weakness scores over time; and then, it stores the device weakness scores over time.).
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 Dunn with regards to a score being stored as historical information of Morello in view of Helander, Larkin, Goldsteen, and Roche in order to prevent exposures and mitigate vulnerabilities (Dunn ¶0004-0006).
With respect to claim 20, the combination of Morello in view of Helander, Larkin, Goldsteen, and Roche teaches the non-transitory storage medium of claim 11 (see rejection of claim 11 above) but does not disclose, wherein the vulnerability compliance score is stored in a vulnerability compliance registry for the containerized workload environment as historical vulnerability compliance information associated with the system.
However, Dunn teaches wherein the vulnerability compliance score is stored in a vulnerability compliance registry for the containerized workload environment as historical vulnerability compliance information associated with the system. ( ¶0042: The CVE frequency estimator module can compare what is the best practice for updates/patches compared to what is the history of this specific network device currently has, and that delta in that comparison is information which feeds its way into the calculations of the device weakness score in the device weakness module (storing in vulnerability compliance registry). ¶0057: The device weakness score is generated based on what CVEs, the kind of CVE actually detected and how critical each CVE is that is associated with each separate network device, what software updates are required for each device, and other factors discussed herein. The device weakness score generator can also factor in those vulnerabilities that are associated with that network device, the update frequency to remedy those vulnerabilities, and historical weakness scores over time; and then, it stores the device weakness scores over time.).
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 Dunn with regards to a score being stored as historical information of Morello in view of Helander, Larkin, Goldsteen, and Roche in order to prevent exposures and mitigate vulnerabilities (Dunn ¶0004-0006).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Pagnozzi et al. (US Pat No. 11507672-B1 ) discloses for selectively remediating vulnerabilities for assets of a computing system, and wherein the vulnerability management system identifies “active” vulnerabilities associated with “active” computing assets that have been determined to be currently running, or to have been recently run, on the system using system call data.
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
/MENG LI/ Primary Examiner, Art Unit 2437
Prosecution Insights