DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
In view of the appeal brief filed on 8/1/2025, PROSECUTION IS HEREBY REOPENED. New grounds of rejection are set forth below.
To avoid abandonment of the application, appellant must exercise one of the following two options:
(1) file a reply under 37 CFR 1.111 (if this Office action is non-final) or a reply under 37 CFR 1.113 (if this Office action is final); or,
(2) initiate a new appeal by filing a notice of appeal under 37 CFR 41.31 followed by an appeal brief under 37 CFR 41.37. The previously paid notice of appeal fee and appeal brief fee can be applied to the new appeal. If, however, the appeal fees set forth in 37 CFR 41.20 have been increased since they were previously paid, then appellant must pay the difference between the increased fees and the amount previously paid.
A Supervisory Patent Examiner (SPE) has approved of reopening prosecution by signing below:
{ 4 }
Response to Arguments
Regarding Double Patenting:
Applicant’s arguments have been fully considered and are persuasive. The rejection has been withdrawn.
Regarding 35 USC 101:
Applicant's arguments have been fully considered but they are not persuasive.
Applicant argues that “’adjusting the security rating based on periodic recalibration using historical vulnerability data across multiple release cycles, wherein recalibration includes adjusting detection thresholds to selectively enhance sensitivity for high-risk vulnerabilities identified in previous cycles…’ is not a mental process. The claimed operations are contingent upon the collection, aggregation, and model-based analysis of structured telemetry data generated by automated scanners and sensors over multiple release cycles. The recalibration process is not simply a mathematical exercise, it is an automated technical operation that accounts for temporal trends in vulnerability telemetry, detects recurring risk patterns, and dynamically adjusts sensitivity thresholds in response. These operations are computational in nature and cannot be performed by the human mind, as they require layered scanner data, cross-cycle comparisons, and predictive modeling based on release telemetry.” Applicant additionally argues that “[t]he specification directly supports this technical characterization. As described in paragraph [0033], telemetry is sourced from automated scanners such as Anchore, DTRACK, and Sonar. Paragraph [0041] makes clear that this telemetry includes scanner outputs over time that are aggregated and processed across software release cycles. Paragraphs [0043] to [0045] further detail how recalibration occurs via forecasting models, including examples such as Holt-Winters, where coefficients are tuned over time to reflect changes in security posture. This model-driven, telemetry-informed recalibration transforms how scanner outputs are interpreted and how system- level vulnerability predictions are refined.”
In response to Applicant's argument, it is first noted that the features upon which applicant relies (i.e., “how recalibration occurs via forecasting models, including examples such as Holt-Winters, where coefficients are tuned over time to reflect changes in security posture”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). In this case, the Holt-Winters model is claimed in dependent claim 13. Further, while Holt-Winters itself concerns forecasting, there is no mention of forecasting models in the claims until dependent claim 13 being drawn to Holt-Winters itself. As such, these argued features are explicitly absent from the independent claim which is being argued.
Additionally, independent claim 1 does not detail “iteratively predicting, via a model, a security rating” beyond it being “based on two or more of the first, second, and third scores.” Independent claim 1 further does not specify “iteratively.” In the trivial case, “iteratively predicting, via a model, a security rating for the stack of microservices based on two or more of the first, second, and third scores” may be interpreted as taking a first average of the first and second scores, then a second average of the first average and the third score. This may be performed by an analyst at the level of generality at which it is claimed.
Applicant further argues that “[t]he telemetry-informed recalibration is the solution itself, not merely ancillary to the solution. In other words, rather than merely reporting data or applying static rules, the claimed system introduces a dynamic feedback mechanism that iteratively improves predictive performance based on empirical telemetry. The recalibration modifies how scanner outputs are weighted and interpreted in context, enabling more precise identification of high-risk patterns across deployment histories.” In response, it is noted that the features upon which applicant relies (i.e., that “recalibration modifies how scanner outputs are weighted and interpreted in context, enabling more precise identification of high-risk patterns across deployment histories”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). In this case, the claim merely recites “wherein recalibration includes adjusting detection thresholds,” but it does not tie the “detection thresholds” to anything else in the claim. The claim does not state that the detection thresholds are those of the first, second, and third sets of security tools. Further, there is no detection step in the claim for an implicit tie-in to the “detection thresholds.”
As such, Applicant’s arguments that “[t]he recalibration algorithm is not incidental… recalibration reshapes the behavior of the system over time based on learned risk patterns, thereby improving how security vulnerabilities are forecasted and addressed in complex microservice stacks” and that “the feedback loop of telemetry- derived scores, model recalibration, and resource estimation defines a new class of technical operations for dynamic risk forecasting, not a conventional business or administrative process” have not been found persuasive because they concern adjusting thresholds which are otherwise not tied to any other element in the claim. If the improvement flows from the periodic recalibration including adjusting detection thresholds, then this improvement is potentially unrelated to the rest of the claim elements. Additionally, it is noted that the features upon which applicant relies (i.e., “model recalibration”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). In this case, the recalibration concerns “adjusting the security rating” rather than the claimed model.
Applicant further argues that “claim language explicitly requires periodic recalibration and further defines that recalibration includes ‘adjusting detection thresholds to selectively enhance sensitivity.’ This is not peripheral or extra-solution activity, it is the core adaptive logic that enables the system to respond to evolving threat patterns. The Examiner’s refusal to treat recalibration and threshold refinement as positive limitations reflects a clear error of law and fact. The claims require operations that do not merely recite result-oriented steps, but rather a specific sequence of processing steps that improve the functionality of the underlying system.” However, and as discussed previously, the “recalibration includ[ing] adjusting detection thresholds” is extra-solution to the rest of the claim language of claim 1 because it is not tied to the rest of the claim language of claim 1 beyond adjusting the security rating. The detection thresholds are not specified as being those of the security tools, and the security tools are not specified as having a detection step.
Applicant further argues that “[u]nder Alice Step 2B, the rejection is likewise improper. The Examiner cites paragraph [0033] of the specification to assert that the scanners and telemetry data are conventional. However, Appellant does not claim scanners per se; rather, the claimed invention is directed to the integration of scanner telemetry with a predictive recalibration architecture that adapts detection thresholds over time. The novelty lies in the system-level orchestration of telemetry ingestion, forecasting, and threshold adjustment across layered microservice stacks. This is supported by the detailed technical description of predictive recalibration in paragraphs [0043] to [0045], and by the claim’s requirement that vulnerability data be used ‘to selectively enhance sensitivity for high-risk vulnerabilities identified in previous cycles…’ The rejection fails to provide the evidentiary showing required under Berkheimer v. HP Inc., 881 F.3d 1360 (Fed. Cir. 2018). "Whether something is well-understood, routine, and conventional to a skilled artisan at the time of the patent is a factual determination." Berkheimer, 881 F.3d at 1369. The Office has not cited any publication or official notice demonstrating that the combination of layered scanner telemetry, predictive modeling, historical recalibration, and dynamic threshold refinement was routine or conventional. The cited paragraph [0033] merely acknowledges certain exemplary scanner tools utilizable for implantation using the novel, claimed processes. It does describe Applicant Admitted Prior Art nor admit that the claimed architecture or its forecast-driven recalibration logic was in common use.”
In response, it is noted that [0033] of the specification explicitly recites obtaining and storing historical data “via a plurality of predetermined tools, such as (but not limited to) Anchore®/Trivy® (e.g., for base image (BI) vulnerability check(s)), DTRACK (e.g., for environment vulnerability check(s)), Sonar® (e.g., for source code vulnerability check(s)), and/or another image, environment, and/or code scanner” while [0067] of the specification explicitly states that “Anchore may be used as a BI review tool, e.g., which may provide all required data as shown in FIG. 3.” Likewise, [0069] of the specification explicitly states that “DTrack may be an example of an environment review tool, e.g., to provide all required data as shown in FIG. 5.” Finally, [0078] of the specification explicitly states that “Sonar may be used as a static code review tool, e.g., for providing all required data as shown in FIGs. 7-8.” The instant specification recites known prior art scanner tools each respectively providing their data. In the case of the security tools, the claimed invention is merely performing data gathering by using the tools as they are designed. With respect to “a plurality of microservices in a stack… wherein the microservices operate with respect to a same set of operations parameters,” it is drawn to the known in the art elements of multi-container applications implementing a microservices architecture, where the different services may communicate with one another via APIs (e.g., the description in [0040]-[0045] of Hufsmith).
Regarding claims rejected under 35 USC 103:
Applicant’s arguments have been fully considered and are persuasive concerning “vulnerability data across multiple release cycles” and “identified in previous cycles” since Hufsmith and Smyth do not explicitly address these limitations. Additionally, the references do not explicitly address time series information, which Applicant argues based on the instant specification. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Aguiar (US 2024/0056484 A1).
Where Applicant argues that the applied prior art does not describe “recalibrating release-specific forecasting models using internal scan data across multiple software releases” and “adjusting detection thresholds based on recurrence of high-risk vulnerabilities over time, nor does it mention Holt-Winters or any time-series forecasting model for software release stacks,” it is noted that the features upon which applicant relies (i.e., “across multiple software releases,” “recurrence of high-risk vulnerabilities over time,” and “Holt-Winters or any time-series forecasting model for software release stacks”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). These elements are not in the argued independent claims. Instead, example claim 1 merely recites “release cycles” rather than “software release cycles;” it does not discuss recurrence of vulnerabilities at all; and neither does it discuss time series modeling or Holt-Winters specifically. For instance, claim 13 is drawn to “the model being a Holt-Winters model,” which narrows independent claim 1 having no mention of the Holt-Winters model nor time series modeling.
Applicant likewise argues that the applied prior art does not disclose “(i) recalibrating a forecasting model using internal, layered scan results accumulated across multiple software release cycles; (ii) detecting trends in recurring vulnerabilities in a microservice stack; or (iii) selectively increasing sensitivity for those high-risk vulnerabilities based on such internal trend analysis.” However, it is noted that the features upon which applicant relies (i.e., “a forecasting model,” “internal, layered scan results accumulated over multiple software release cycles,” “detecting trends,” “based on such internal trend analysis”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). These elements are not in the argued independent claims. Example claim 1 does not recite that its model is “a forecasting model;” it does not specify between external and “internal” scan results; it does not specify “layered” scan results; it does not specify “software release cycles” as discussed above; and it does not specify “detecting trends” and “internal trend analysis.”
Applicant further argues that Hufsmith and Smyth are not combinable. Specifically, Applicant argues that “[r]egardless of whether the references generically concern ‘malware detection,’ they do so in entirely distinct technical contexts. Hufsmith addresses static scoring of container images using environment-specific scanner outputs and metadata. It produces a contextual threat score based on current properties of a container image. Smyth, by contrast, predicts the likelihood that a CVE will be exploited, based on external data sources like the NVD and social media;” that “[t]he rejection provides no articulated reasoning or technical bridge between the types of input data, model structure, or operational purpose of the systems in Smyth and Hufsmith, and thus fails to support a conclusion of obviousness;” that “such hypothetical modification of Hufsmith would render the prior art invention being modified unsatisfactory for its intended purpose and change the principle of operation of the prior art invention being modified… Even assuming arguendo that Smyth’s retraining approach were considered combinable with Hufsmith, such a modification would fundamentally alter the principle of operation of Hufsmith and render it inoperative or unsatisfactory for its intended purpose. Hufsmith generates a composite threat score for container images based on scan outputs and environmental context relevant to the image itself. Its function is to evaluate container security based on known vulnerabilities and runtime conditions within the deployment environment. It does not rely on external threat intelligence or exploit prediction, nor is it structured around CVE identifiers or external correlation data… Importing Smyth’s model retraining framework into Hufsmith would eliminate Hufsmith’s ability to operate on image-specific scan and context data and would instead substitute a probabilistic exploitability prediction that ignores localized environmental parameters. In other words, the proposed modification would not merely supplement Hufsmith but displace its foundational design logic.”
In response, it is first noted the Hufsmith explicitly recites using CVE data and external vulnerability databases: e.g., “obtaining, with one or more processors, a plurality of scanner properties pertaining to a container, the scanner properties at least comprising one or more Common Vulnerabilities and Exposures (CVE) scanner properties determined for the container by a first scanner and one or more Common Weakness Enumeration (CWE) scanner properties determined for the container be a second scanner” in [0008]; “binary and package information may be assessed and sent to engines to acquire the CVE and CWE information for the binary” in [0033]; “scanner applications may scan the identified resources from the scan request to identify any of a variety of different types of vulnerabilities, examples include those identified in public repositories, such as repositories of CVE or CWE vulnerabilities. In some cases, each vulnerability may have a unique identifier in a namespace of such repositories, and embodiments may reference that identifier in results” in [0084]; “the results engine 54 may include one or more components for evaluating properties associated with a container image, such as a configuration evaluator 105, CVE evaluator 110, malware evaluator 115, CWE evaluator 120, and a context evaluator 125” in [0109]; and “the CVE evaluator 110 may query a repository, database, or other entity with the CVE identifier to retrieve current information about the CVE. In turn, the CVE evaluator 110 may update the CVE properties 106 to associate the retrieved information with the CVE identifier” in [0113]. Additionally, Hufsmith concerns classification models in a general manner: e.g., [0076] and [0095].
As such, Hufsmith both incorporates vulnerability data from vulnerability databases into its analysis, and allows for generic classification models. Additionally, there is no recitation inf Smyth concerning “a probabilistic exploitability prediction that ignores localized environmental parameters.” For instance, [0021] of Smyth states that “data sources 260 may also be considered, along with proprietary data sources 250. Each of the data sources 210, 220, 230, 240, 250, 260 shown in FIG. 2 are merely examples and do not limit the number of type of data sources which may be considered by the method 100 described. A common characteristic of the data sources 210, 220, 230, 240, 250, 260 is that they rely on a common identifier associating information with a particular vulnerability;” [0024] of Smyth states that “entities providing cybersecurity services may have proprietary data describing how often their customers encounter certain vulnerabilities. Other entities that largely conduct their operations online may also have internal information regarding the frequency and type of vulnerabilities encountered. Such proprietary data also includes CVE identifiers so that the proprietary data may be associated with updated or revised information associated with the specific vulnerability.” Therefore, both Hufsmith and Smyth concern analyzing similar data from similar sources, and neither discusses excluding any particular type of source.
With respect to the obviousness rationale, the Smyth reference is currently relied upon for teaching adjusting detection sensitivities for particular vulnerabilities as per the rejection below. Applicant has not of yet addressed this rationale.
Requirement for Information Under 37 CFR 1.105
Applicant and the assignee of this application are required under 37 CFR 1.105 to provide the following information that the examiner has determined is reasonably necessary to the examination of this application.
In response to this requirement, please state the specific improvements of the subject matter in claims 1 and 15, over the disclosed prior art and indicate the specific elements in the claimed subject matter that provide those improvements. In this case, Applicant argues that “cited paragraph [0033] merely acknowledges certain exemplary scanner tools utilizable for implantation using the novel, claimed processes. It does describe Applicant Admitted Prior Art nor admit that the claimed architecture or its forecast-driven recalibration logic was in common use.” The examiner requests clarification concerning the improvement to the art in obtaining data from the exemplary scanner tools. It is specifically requested to clarify Applicant’s invention as in [0033], [0067], [0069], and [0078] of the instant specification concerning prior art tools and data provision.
For those claims expressed as means or steps plus function, please provide the specific page and line numbers within the disclosure which describe the claimed structure and acts.
In responding to those requirements that require copies of documents, where the document is a bound text or a single article over 50 pages, the requirement may be met by providing copies of those pages that provide the particular subject matter indicated in the requirement, or where such subject matter is not indicated, the subject matter found in applicant’s disclosure.
The applicant is reminded that the reply to this requirement must be made with candor and good faith under 37 CFR 1.56. Where the applicant does not have or cannot readily obtain an item of required information, a statement that the item is unknown or cannot be readily obtained may be accepted as a complete reply to the requirement for that item.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Note that the courts do not distinguish between mental processes that are performed entirely in the human mind and mental processes that require a human to use a physical aid (e.g., pen and paper or a slide rule) to perform the claim limitation (refer to MPEP 2106.04(a)(2)).
Example independent claim 15 recites the following abstract idea limitations: A system, comprising: provide first, second, and third sets of security tools configured to generate first, second, and third vulnerability scores, respectively (calculating scores according to an algorithm as part of a mental process—e.g., first, second, and third teams of analysts outputting scores according to prerecorded instructions); monitor, the via first, second, and third sets of security tools, (i) source code, (ii) a base image (BI), and (iii) a runtime environment of each of a plurality of microservices in a stack (observation as part of a mental process—e.g., the first, second, and third teams having specific assignments; receiving written information concerning (i)-(iii) for a given plurality of microservices), wherein each of the security tools is selectable (allocation of tasks as part of certain methods of organizing human activity—e.g., choosing a team with the correct expertise for a given task) and comprises at least one of a scanner or sensor configured to output historical data (adding insignificant extra-solution activity to the judicial exception; the “scanner or sensor” is recited at a high level of generality while the historical data is otherwise unconnected to the claim); iteratively predict, via a model, a security rating for the stack of microservices based on two or more of the first, second, and third scores (correlating and calculating scores as part of a mental process—e.g., an analyst averaging the scores according to a prerecorded model having instructions for doing so, via pen and paper); adjusting the security rating based on periodic recalibration using historical vulnerability data (recalculating or otherwise modifying a score as part of a mental process—e.g., the analyst recalculates or annotates the score) across multiple release cycles (adding insignificant extra-solution activity to the judicial exception—i.e., mere data gathering), wherein recalibration includes adjusting detection thresholds to selectively enhance sensitivity for high-risk vulnerabilities identified in previous cycles (observation, evaluation, judgment, and opinion as part of a mental process—e.g., the analyst reviews gathered data to evaluate and judge which vulnerabilities to prioritize, and thereafter modifies model values accordingly); and determine, based on the predicted rating, an amount of resources needed to enable a security team to increase security via implementation of the resources (evaluation, judgement, and opinion as part of a mental process—e.g., an administrator deciding that an average score over a certain threshold merits swift remediation).
Example independent claim 15 recites the following limitations which may comprise additional elements that are sufficient to amount to significantly more than the judicial exception: a memory having computer-readable instructions stored therein; a processor configured to perform the claimed steps; wherein the microservices operate with respect to a same set of operations parameters.
With respect to step 2A, this judicial exception is not integrated into a practical application because adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea is not considered to be sufficient—see MPEP 2106.05(f). In this case, the claim generally concerns calculating and aggregating security scores to determine a remedial response. This is performed by a processor and memory, implementing security tools, and in reference to microservices as the object of concern. This is considered to be a form of invoking computers or other machinery (the processor, memory, security tools, and scanners / sensors) merely as a tool to perform an existing process (the analyst example above). The processor and memory are base level components of any possible computer for performing the judicial exception. The “scanner or sensor” and the “security tools” are likewise recited at a high level of generality, where they merely function as a computerization for data gathering. The claim does not specify any particular machine beyond substituting computers (any kind of computer having a processor and memory) and scanners/sensors (any kind of data gathering tool). Further, “wherein the microservices operate with respect to a same set of operations parameters” merely defines the genre of microservices monitored (e.g., being part of the same application or suite) rather than being part of the “provide,” “monitor,” “predict,” and “determine” steps. Even if, arguendo, the “monitoring” step is viewed as non-abstract it is insufficient under MPEP 2106.05(g) because it is insignificant extra solution activity.
The claimed invention is drawn to a problem which is not rooted in computers because it concerns improvements to calculating, aggregating, and judging scores as discussed above. It is addressing a problem that transcends computing (calculating and interpreting scores). Since the claimed invention is not rooted in computers, it therefore does not improve the functioning of a computer or any other technology or technical field so as to integrate the judicial exception into a practical application.
With respect to step 2B, the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception because simply appending well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception is not considered to be sufficient—see MPEP 2106.05(d) and Berkheimer Memo. Monitoring microservices with a plurality of selectable security tools and outputting historical data is well known and understood in the industry. For instance, [0033] of the instant specification makes reference to prior art tools such as Anchore/Trivy, DTRACK, Sonar, and so forth for this purpose. Microservices are also known and understood to operate as claimed within the industry. For instance, refer to at least [0040]-[0045] of US 2020/0097662 A1 concerning multi-container applications implementing a microservices architecture. Likewise, refer to at least the abstract, [0069], [0071], [0073], and [0083] of US 2020/0097662 A1 with respect to a plurality of selectable scanners for obtaining and scoring security information of the microservices architecture. Therefore it would have been obvious to one or ordinary skill in the art to obtain security data for microservices from a plurality of selectable security tools because all of the claimed elements were known in the prior art (microservices architecture and available products for security monitoring) and one skilled in the art could have combined the elements as claimed by known methods with no change in their respective functions (using the security products to monitor microservices as intended), and the combination would have yielded predictable results to one of ordinary skill in the art at the time (obtaining security data from the security tools).
Further concerning the processor and memory, these are base components of any potential computer for implementing the judicial exception. Base computerization at this level of generality is considered to be a form or adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea. This is not sufficient under MPEP 2106.05(f).
Independent claim 1 is substantially similar, and is therefore rejected under the same analysis.
Dependent claim 2 merely further specifies the abstract idea, and is therefore rejected under the same analysis. Specifically, it recites the following abstract idea limitation: determining a time at which to implement a reservation of the amount of resources, the reservation comprising an assignment or scheduling of the security team's resources (evaluation, judgement, and opinion as part of a mental process—e.g., the administrator further contemplating scheduling and resource allocation based on a received score).
Dependent claim 3 merely further specifies the abstract idea, and is therefore rejected under the same analysis. Specifically, it recites the following abstract idea limitation: determining a security state for a next release of the stack of microservices (evaluation, judgement, and opinion as part of a mental process—e.g., an analyst contemplating a security state of a given grouping of microservices).
Dependent claim 4 recites “wherein the microservices comprise one or more sets of cloud services.” With respect to step 2A, this judicial exception is not integrated into a practical application because generally linking the use of the judicial exception to a particular technological environment or field of use is not considered to be sufficient—see MPEP 2106.05(h). In this case, the claim limitation merely further specifies the genre of information being analyzed. The providing, monitoring, predicting, and determining steps remain the same. With respect to step 2B, the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception because simply appending well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception is not considered to be sufficient—see MPEP 2106.05(d) and Berkheimer Memo. In this case, [0040]-[0045] of US 2020/0097662 A1 concern cloud-based microservices and the analysis remains the same as for the parent claim above (the same citations and obviousness rationale).
Dependent claim 5 merely further specifies the abstract idea, and is therefore rejected under the same analysis. Specifically, it recites the following abstract idea limitation: providing a user interface (UI) configured to obtain a selection of an information technology (IT) risk level over a configurable period of time (passing information as part of a mental process—e.g., pen and paper notes for specifying risk levels and policy between analysts and/or administrators).
Dependent claim 6 merely further specifies the abstract idea, and is therefore rejected under the same analysis. Specifically, it recites the following abstract idea limitation: wherein each of the scores is an average (merely further specifies the calculations performed as part of the mental process).
Dependent claims 7-8 are rejected for substantially the same reasons as claim 6 above, since they merely specify the calculations performed as part of the abstract idea.
Dependent claim 9 is rejected for substantially the same reasons as claim 5 above (i.e., a pen and paper implementation for specifying policy).
Dependent claim 10 merely further specifies the abstract idea, and is therefore rejected under the same analysis. Specifically, it recites the following abstract idea limitation: transmitting a notification based on the determination (passing information as part of the mental process—e.g., via pen and paper, or verbally), wherein the amount of resources is determined based on the security rating satisfying a first criterion (merely further specifying the calculations performed as part of the mental process), and wherein the notification enables a team of developers to be activated (assigning tasks as part of certain methods of organizing human activity) when, at a subsequent iteration, the security rating is predicted to satisfy a second criterion having a greater risk level than the first criterion (merely further specifying the calculations performed as part of the mental process—e.g., multiple criteria and successive calculations).
Dependent claim 11 merely further specifies the abstract idea, and is therefore rejected under the same analysis. Specifically, it recites the following abstract idea limitation: wherein each of the predictions is performed to enable a first amount of false positives to increase and a second amount of false negatives to decrease (judgement as part of a mental process—e.g., a judgment choosing improved detection over reducing erroneous hits).
Dependent claim 12 merely further specifies the abstract idea, and is therefore rejected under the same analysis. Specifically, it recites the following abstract idea limitation: tracking a change of a project state according to a release lifecycle from each layer individually, to automatically apply additional checks that exclude false positive errors in one or more security tool reports (observation and analysis as part of a mental process—e.g., an analyst observing a project and choosing to filter security data according to a given policy).
Dependent claim 13 is rejected for substantially the same reasons as claims 7-8 above, since it merely further specifies the calculations performed as part of the mental process.
Dependent claim 14 is rejected for substantially the same reasons as claim 5 above (i.e., a pen and paper implementation for specifying policy).
Dependent claims 16-20 are substantially similar to claims 2-5 and 7 above. As such, they are likewise rejected under the same analysis.
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.
Claim(s) 1-6, 8-10, 12, and 14-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hufsmith (US 2020/0097662 A1) in view of Pfleger de Aguiar (US 2024/0056484 A1), hereinafter “Aguiar,” and in view of Smyth (US 2018/0034842 A1).
.
Regarding claim 1, Hufsmith discloses: A computer-implemented method, comprising:
providing first, second, and third sets of security tools (e.g., scanner apps in FIG. 1A of Hufsmith) configured to generate first, second, and third vulnerability scores, respectively;
Refer to at least [0032], [0071], and [0090] of Hufsmith with respect to utilizing a plurality of scanners, each producing a respective score.
monitoring, via the first, second, and third sets of security tools, (i) source code (e.g., [0073] of Hufsmith concerning scanners for source code), (ii) a base image (BI) (e.g., [0069] and [0157] of Hufsmith concerning scanning container images), and (iii) a runtime environment (e.g., [0083] of Hufsmith concerning scanners implementing dynamic analysis; [0032] of Hufsmith concerning execution environment and context properties) of each of a plurality of microservices in a stack (e.g., [0040]-[0041] and [0045] of Hufsmith concerning scanning microservices and multi-container applications), wherein each of the security tools is selectable and comprises at least one of a scanner or sensor (e.g., [0071] of Hufsmith concerning scanner selection) configured to output historical data (e.g., [0034] and [0106] of Hufsmith concerning historical information and context properties such as score history), and wherein the microservices operate with respect to a same set of operations parameters (e.g., [0040]-[0045] of Hufsmith concerning microservice architecture);
iteratively predicting, via a model (e.g., the classification model in [0095] of Hufsmith), a security rating for the stack of microservices based on two or more of the first, second, and third scores;
Refer to at least the abstract, [0090]-[0091], and [0095] of Hufsmith with respect to aggregating and correlating the scanner scores to produce a combined threat score.
Refer to at least [0113], [0121], [0129], and [0206] of Hufsmith with respect to refreshing scores periodically; [0160] of Hufsmith with respect to continuously updating.
adjusting the security rating based on periodic recalibration using historical vulnerability data across multiple release [versions];
Refer to at least FIG. 5, [0160], and [0206]-[0209] of Hufsmith with respect to continuously updating and reporting the latest information on vulnerabilities; weighting and reweighting the combined threat score.
Refer to at least [0106], [0005], and [0158]-[0160] of Hufsmith with respect to version history as part of context properties; [0135] and [0138] of Hufsmith concerning version history used in determining weights.
determining, based on the predicted rating, an amount of resources needed to enable a security team to increase security via implementation of the resources (interpreted in view of [0046] and [0051] of the instant specification—i.e., a determination that a particular resource (analyst or software tool) is needed at a particular time as part of a mitigation strategy).
Refer to at least [0096], [0158]-[0160], and [0181] of Hufsmith with respect to providing results to an analyst responsive to the combined threat score determination, where the results include a mitigation strategy. The mitigation strategy includes utilizing alternate resources and/or code.
Hufsmith does not specify: the release versions further comprising release cycles; wherein recalibration includes adjusting detection thresholds to selectively enhance sensitivity for high-risk vulnerabilities. However, Hufsmith in view of Aguiar discloses: the release versions further comprising release cycles;
Refer to at least [0024], [0027]-[0028], and [0047] of Aguiar with respect to vulnerability time series information, including vulnerability lifecycle, patches, and advisory release dates.
wherein recalibration includes adjusting [risk information] for high-risk vulnerabilities.
Refer to at least the abstract, [0024], [0031], FIG. 6, and [0054]-[0055] of Aguiar with respect to recalibrating rules and risk prediction based on new time series information.
The teachings of Hufsmith and Aguiar both concern cybersecurity and vulnerability analysis, and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant's invention to modify the teachings of Hufsmith to further implement time series information as part of its vulnerability analysis and evaluation for at least the reasons discussed in [0002], [0010], [0019], [0048], and [0055] of Aguiar (i.e., improving the accuracy of analysis as new information is released over time and accounted for; allowing for improved threat-prioritization).
Hufsmith-Aguiar does not specify: adjusting the risk information further comprising adjusting detection thresholds to selectively enhance sensitivity. However, Hufsmith-Aguiar in view of Smyth discloses: adjusting the risk information further comprising adjusting detection thresholds to selectively enhance sensitivity.
Refer to at least [0007] and [0044] of Smyth with respect to retraining a prediction ensemble comprising modifying the sensitivity for a particular vulnerability.
The teachings of Hufsmith-Aguiar and Smyth both concern malware detection and models for malware detection, and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant's invention to modify the teachings of Hufsmith-Aguiar to further implement adjusting sensitivity for particular vulnerabilities for at least the purpose of improving the chance of detecting whether vulnerabilities of particular concern are present (e.g., those making it to national news), and because the particular known technique was recognized as part of the ordinary capabilities of one skilled in the art.
Regarding claim 2, Hufsmith-Aguiar-Smyth discloses: The method of claim 1, further comprising: determining a time at which to implement a reservation of the amount of resources, the reservation comprising an assignment or scheduling of the security team's resources.
Refer to at least [0059]-[0060] of Hufsmith with respect to scheduling deployment, rolling out updates, and/or revisions for containers based on policy.
Refer to at least [0146]-[0147] of Hufsmith with respect to score evaluation based on policy; granting or rejecting deployment of applications as a result.
Regarding claim 3, Hufsmith-Aguiar-Smyth discloses: The method of claim 1, further comprising: determining a security state for a next release of the stack of microservices.
Refer to at least [0102], [0106], [0138], [0181], and [0189] of Hufsmith with respect to obtaining security information for different versions (e.g., later version) of containers / applications under analysis.
Regarding claim 4, Hufsmith-Aguiar-Smyth discloses: The method of claim 1, wherein the microservices comprise one or more sets of cloud services.
Refer to at least [0044] of Hufsmith with respect to distributed applications (e.g., microservices in [0040] and [0045] of Hufsmith) being cloud-based.
Regarding claim 5, Hufsmith-Aguiar-Smyth discloses: The method of claim 1, further comprising: providing a user interface (UI) configured to obtain a selection of an information technology (IT) risk level over a configurable period of time.
Refer to at least [0146]-[0147] and [0206] of Hufsmith with respect to policy having thresholds configurable by an administrator.
Regarding claim 6, Hufsmith-Aguiar-Smyth discloses: The method of claim 1, wherein each of the scores is an average.
Refer to at least [0095], [0119]-[0120], [0127]-[0128], and [0133]-[0134] of Hufsmith with respect to threat scores as weighted sums or averages.
Regarding claim 8, Hufsmith-Aguiar-Smyth discloses: The method of claim 1, wherein each iterative prediction corresponding to the iteratively predicting is performed within a first duration, the first duration being greater than a length of time of each of the iterations, the iterations being periodic.
Refer to at least [0113], [0121], [0129], and [0206] of Hufsmith with respect to refreshing scores periodically; [0160] of Hufsmith with respect to continuously updating.
Regarding claim 9, it is rejected for substantially the same reasons as claim 5 above (i.e., administrators setting time thresholds in policy; the “second duration” has not been examined with respect to prior art since it has no antecedent basis nor any definition).
Regarding claim 10, Hufsmith-Aguiar-Smyth discloses: The method of claim 1, further comprising: transmitting a notification based on the determination (e.g., [0096], [0158]-[0160], and [0181] of Hufsmith with respect to providing results to an analyst), wherein the amount of resources is determined based on the security rating satisfying a first criterion,
Refer to at least [0152], [0072], and [0146] of Hufsmith with respect to scanner criteria and/or thresholds which may be satisfied during security processing.
and wherein the notification enables a team of developers to be activated when, at a subsequent iteration, the security rating is predicted to satisfy a second criterion having a greater risk level than the first criterion.
Refer to at least [0191] of Hufsmith with respect to waiting until subsequent events before reporting to an analyst. Further see at least [0060] and [0106] with respect to different versions having different scores, which thereby influences whether a threshold is met.
Regarding claim 12, Hufsmith-Aguiar-Smyth discloses: The method of claim 1, further comprising: tracking a change of a project state according to a release lifecycle (e.g., [0158] of Hufsmith concerning development lifecycle) from each layer individually (e.g., [0031] of Hufsmith with respect to examining each layer of a container), to automatically apply additional checks that exclude false positive errors in one or more security tool reports.
Refer to at least [0087] and [0089] of Hufsmith with respect to filtering out false positives and potential vulnerabilities that are fixed in a different layer.
Regarding claim 14, it is rejected for substantially the same reasons as claim 5 above (i.e., administrators setting time thresholds in policy).
Regarding independent claim 15, it is substantially similar to independent claim 1 above, and is therefore likewise rejected.
Regarding claims 16-19, they are substantially similar to claims 2-5 above, and are therefore likewise rejected.
Claim(s) 7 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hufsmith-Smyth as applied to claims 1-6, 8-10, 12, and 14-19 above, and further in view of Futamura (US 2007/0150949 A1).
Regarding claim 7, Hufsmith-Aguiar-Smyth does not disclose: aggregating or summing the averages with an estimated slope value and with a seasonality value associated with the slope value. However, Hufsmith-Aguiar-Smyth in view of Futamura discloses: aggregating or summing the averages with an estimated slope value and with a seasonality value associated with the slope value.
Refer to at least [0064] of Futamura with respect to exponential smoothing to calculate the mean, slope, seasonality, and variance, among other values, and then use the smoothed values to trigger an anomaly alarm.
The teachings of Hufsmith-Aguiar-Smyth and Futamura both concern computer security scanning, and are considered to be within the same field of endeavor and combinable as such. Further, Hufsmith concerns averaging threat scores while exponential smoothing is a moving average.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Hufsmith to further implement exponential smoothing for obtaining a combined threat score because the substitution of one known element for another would have yielded predictable results to one of ordinary skill in the art at the time (i.e., techniques for calculating an average).
Regarding claim 20, it is substantially similar to claim 7 above, and is therefore likewise rejected.
Claim(s) 11 and 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hufsmith-Aguiar-Smyth as applied to claims 1-6, 8-10, 12, and 14-19 above, and further in view of Batoukov (US 2019/0370610 A1).
Regarding claim 13, Hufsmith-Aguiar-Smyth does not disclose: adjusting the model such that a prediction for a long-term duration is performed in a subsequent iteration, the model being a Holt-Winters model. However, Hufsmith-Aguiar-Smyth in view of Batoukov discloses: adjusting the model such that a prediction for a long-term duration is performed in a subsequent iteration, the model being a Holt-Winters model.
Refer to at least [0084], [0091], and [0117]-[0118] of Batoukov with respect to Holt-Winters for anomaly detection; with respect to iterative learning.
The teachings of Hufsmith-Aguiar-Smyth and Batoukov both concern computer security scanning, and are considered to be within the same field of endeavor and combinable as such. Further, Aguiar already concerns time series techniques.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Hufsmith-Aguiar-Smyth to further implement a Holt-Winters model for anomaly detection at scanners and evaluators for at least the purposes discussed in [0024]-[0026] of Batoukov (i.e., detection accuracy is improved over iterations of learning), and because the substitution of one known element for another (i.e., the time series technique used) would have yielded predictable results to one of ordinary skill in the art at the time.
Regarding claim 11, Hufsmith-Aguiar-Smyth-Batoukov discloses: The method of claim 1, wherein each of the predictions is performed to enable a first amount of false positives to increase and a second amount of false negatives to decrease.
Refer to at least [0118] of Batoukov with respect to reducing false positives when changes in the time series become more erratic and the expected deviations grow. Conversely, when the metric stabilizes into a more regular pattern, the expected deviations decrease resulting in increased sensitivity.
This claim would have been obvious for substantially the same reasons as claim 13 above.
Conclusion
This Office action has an attached requirement for information under 37 CFR 1.105. A complete reply to this Office action must include a complete reply to the attached requirement for information. The time period for reply to the attached requirement coincides with the time period for reply to this Office action.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VADIM SAVENKOV whose telephone number is (571)270-5751. The examiner can normally be reached 12PM-8PM.
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, Jeffrey L Nickerson can be reached at (469) 295-9235. 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.
/V.S/Examiner, Art Unit 2432
/ALI SHAYANFAR/Supervisory Patent Examiner, Art Unit 2432