DETAILED ACTION
This office action is in response to the application filed on 08/06/2025. Claim(s) 1-20 is/are pending and are examined.
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
Applicant’s amendments to claims 16-20 direct the claimed invention to statutory subject matter as such the 101 rejection is withdrawn.
Applicant's arguments filed on 08/06/2025 have been fully considered but they are not persuasive for the following reasons:
Applicant’s Argument:
At most, Hwang calculates risk scores using a common vulnerability scoring system (CVSS) and classifies security patterns (8:40-60), but Hwang does not disclose assigning "a security state label to each microservice based on scores obtained from a set of security rules," as claimed. (Applicant’s response filed on 08/06/2025, page 8-9).
Examiner’s Response:
The Examiner respectfully disagrees. The limitation the applicant is discussing is not mapped by Hwang but instead by Millar. (Millar Fig. 2 Col. 8 Ln. 1-10 teaches, in alternative embodiments, an initial graphical user interface presented to an analyst may include a set of findings that are automatically sorted and/or filtered based on confidence score and/or severity. (i.e., label based of a score)). While Millar alone nor Hwang alone teaches each and every limitation of the claim Hwang in combination with Millar does clearly teach the limitation of assigning a security label to each microservice where Hwang Col. 2 Ln. 60-67 teaches, “information technology cyber-attacks are growing and, as a result, security measures are constantly requiring new and improved methods to counterbalance the cyber-attacks. Cloud computing environments, such as microservices, and users of microservices 65 and computing applications can benefit from greater security measures.” The system for a security assessment of cloud platform using microservices. As such the combination of Hwang and Millar teach the limitation. It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Hwang with Millar, to modify the shift-left security risk analysis system of Hwang with the security platform displaying potential vulnerability information and labeling of Millar. The motivation to do so, Millar Col. 7 Ln. 35-44, improve efficiency and effectiveness while reducing alert fatigue.
Applicant’s Argument:
The Office Action's reliance on Hwang (4:1-20; 8:1-40) for this limitation (Office Action, 10) is therefore misplaced, as these passages discuss general machine learning classification and graph-based analysis, not rule-based scoring or microservice-specific labeling. Furthermore, Hwang does not disclose using a "hidden Markov model (HMM)" for predicting security states, and any modification would impermissibly change Hwang's principle of operation. The cited passages (1:50-60; 2:5-17; 3:11-20) describe neural networks, regression, and graph-based models, none of which involve temporal, probabilistic state transitions of HMMs. Thus, Hwang fails to teach the predictive modeling aspect of the claimed labeling component. (Applicant’s response filed on 08/06/2025, page 8-9).
Examiner’s Response:
The Examiner respectfully disagrees. The mapping for the limitations of claim 1 are done as a combination of Hwang-Millar-Noeth teaching each and every limitation where one lacks a specific feature the others make up for it combined. The cited paragraph of Noeth ¶ 66 teaches, “anomalies may be detected by training a hidden Markov model or recurrent neural network”, while Hwang cited in the passages mentioned in the applicant’s response discuss neural networks, regression, and graph-based models. Individually the two sources may not teach each and every limitation in combination they do teach the limitation. It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Hwang in view of Millar with Noeth, to modify the shift-left security risk analysis system of Hwang with the security platform displaying potential vulnerability information of Millar with the anomaly detection using a hidden Markov model of Noeth. The motivation to do so, Noeth ¶ 68, the detection of anomalies in a system.
Applicant’s Argument:
Moreover, the CVSS scores in Hwang are general risk metrics, not derived from a defined set of security rules, nor are they used to assign categorical labels (e.g., RED, YELLOW, GREEN, for microservice status). The claimed invention uses a specific ruleset to generate scores that determine discrete labels for each microservice. See, for example, the specification at paragraphs [0100] to [0104), a feature absent in Hwang's broader risk classification approach. (Applicant’s response filed on 08/06/2025, page 8-9).
Examiner’s Response:
The Examiner respectfully disagrees. The labeling done in claim 1 is not mapped to Hwang but to art of Millar. Millar teaches in Col 6. Ln. 1-13, Col. 8 Ln. 1-10 and Fig. 2, “include a set of findings that are automatically sorted and/or filtered based on confidence score and/or severity” showing that Millar is assigning a label to the data based on a score. This is further expanded on with the inclusion of Packwood in Col.7 Ln. 29-47, “corresponding to each entered risk factor. The outputs are color-coded depending on the results of the comparison the programmed ranges of risk level values. Preferably three colors are used green, yellow, or red.” As such the combination of Hwang-Millar-Noeth-Packwood teaches each and every limitation of the claim. It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Hwang-Millar-Noeth with Packwood, to modify the shift-left security risk analysis system of Hwang with the security platform displaying potential vulnerability information of Millar with the anomaly detection using a hidden Markov model of Noeth with the labeling method of Packwood. The motivation to do so, Packwood Col. 12 Ln. 34-37, to further improve the report and make reference to a particular risk factor easier.
Applicant’s Argument:
The user interface displays scanner outputs, not a rule-based classification of a microservice's overall security posture. Millar is therefore fundamentally retrospective, tied to a vulnerability scan output, and does not provide proactive assessment or classification logic.
That is, Millar's system is retrospective, as it involves "utilizing, during an application security test, a scan module... to obtain scan traffic data associated with a particular potential security vulnerability" (Millar, operation 1110, 15:28-37), and then "determining, using the ML.
model... a confidence score for the particular potential security vulnerability," (Millar, operation 1120, 15:38-49) focusing on analyzing vulnerabilities detected in scans, not predicting future states. Additionally, Millar describes "utilizing, during a subsequent application security test, the scan module to obtain subsequent scan traffic data associated with the particular potential security vulnerability,” (operation 1130, 15:50-59) teaching re-analysis of detected vulnerabilities without forecasting. Millar does not teach or suggest using any predictive model, such as an HMM, to forecast future security states based on historical data, as required by the claims. Therefore, Millar fails to address both the rule-based labeling and predictive modeling limitations of claim 1. (Applicant’s response filed on 08/06/2025, page 9-10).
Examiner’s Response:
The Examiner respectfully disagrees. Fig. 2 of Millar is a clear representation of the vulnerabilities having both a severity (i.e., a label) and a confidence score. Millar is taught in combination with Hwang and Noeth which as previously discussed cover the deficiencies of Millar in teaching each and every limitation. It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Hwang in view of Millar with Noeth, to modify the shift-left security risk analysis system of Hwang with the security platform displaying potential vulnerability information of Millar with the anomaly detection using a hidden Markov model of Noeth. The motivation to do so, Millar Col. 7 Ln. 35-44, improve efficiency and effectiveness while reducing alert fatigue.
Applicant’s Argument:
However, Noeth's disclosure only describes anomaly detection at the network level, not to analysis of microservices or source code. Noeth does not assign scores to microservices, does not define security rules or apply a ruleset, and does not use HMMs to predict the future state of a software service. The reference is focused on traffic behavior and user activity, not microservice architecture or code-based analysis. A use of HMMs to detect anomalous packets in a network flow does not render obvious the use of HMMs to predict a labeled state sequence of microservice security classifications. The Office Action's generic rationale for combining Noeth with Hwang and Millar is to enhance "anomaly detection" (Office Action, p. 7, citing Noeth at paragraph [0068]). However, Noeth at paragraph [0068] discusses associating network packet reports with application attributes (e.g., memory utilization, file access) for intrusion detection, stating:"the intrusion detection agent may associate with the reports of network packets...
additional forensic information about the corresponding application" (Noeth, paragraph [0068]).
Noeth describes anomaly detection in network traffic using an HMM to identify potentially malicious packets (Noeth, paragraph [0066]).
This application is fundamentally different from predicting the security state of microservices, which involves analyzing software components (e.g., source code, dependencies, runtime environment) rather than network packets. Noeth's HMM models sequences of network events, not the state transitions of microservices, and does not involve scoring based on security rules or assigning labels to software components. The Office Action provides no rationale for why a person of ordinary skill in the art (POSITA) would adapt Noeth's network-focused HMM to predict microservice security states, especially given Hwang's existing use of other machine learning models for risk prediction (Hwang, 4:1-20). Therefore, Noeth only pertains to the context of network security, not microservice state prediction.
(Applicant’s response filed on 08/06/2025, page 10-12).
Examiner’s Response:
The Examiner respectfully disagrees. As discussed above the combination of Hwang-Millar-Noeth teaches each aspect of the claimed limitation those being Hwang teaching in Hwang Col. 1 Ln. 50-60 Fig. 1 Col. 10 Ln. 14-35, “Embodiments of the present invention disclose a method, a computer system, and a computer program product for security risk analysis. Col. 2 Ln. 60-67 teaches, information technology cyber-attacks are growing and, as a result, security measures are constantly requiring new and improved methods to counterbalance the cyber-attacks. Cloud computing environments, such as microservices, and users of microservices 65 and computing applications can benefit from greater security measures.” and Noeth covering the deficiencies of Hwang in ¶ 66, “anomalies may be detected by training a hidden Markov model or recurrent neural network”. It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Hwang in view of Millar with Noeth, to modify the shift-left security risk analysis system of Hwang with the security platform displaying potential vulnerability information of Millar with the anomaly detection using a hidden Markov model of Noeth. The motivation to do so, Noeth ¶ 68, the detection of anomalies in a system. Even though Noeths art does not pertain to microservices it does pertain to the security of networks which cloud computing environments including cloud computing environments rely on thus the arts while not the same do pertain to similar subject matters. As such the combination of including Noeth’s HMM into the system of Hwang is a reasonable combination and Hwang-Millar-Noeth teach each and every limitation of the claim.
Applicant’s Argument:
The Office Action asserts that certain claim terms are being interpreted under 35 U.S.C.
§112(f) because they are alleged to invoke means-plus-function treatment. Specifically, the Office identifies the term "component" as a generic placeholder and finds that the claimed "data gathering component,""security assessment component," and "labeling component" lack corresponding structure, material, or acts in the specification. Applicant respectfully traverses this interpretation.
Applicant disagrees. In the present application, the claims recite the "data gathering component,""security assessment component," and "labeling component" in structural terms tied to specific operations and data flows between modules. For example, claim 1 recites a "data gathering component configured to collect microservice release information including microservice source code, source code dependencies, and runtime environment." This is not a purely functional black box: the component is specifically configured to interact with source code repositories and runtime telemetry systems, as supported in the specification.
Moreover, the specification provides detailed structural and algorithmic descriptions of each of the components alleged to be governed by §112(f). The data gathering component is supported, for example, in paragraph [0104], which explains that it accesses microservice manifests, source code repositories, runtime environment variables, and external vulnerability databases. The security assessment component is described in paragraphs [0106] to [0107], which disclose the use of static analysis tools, software composition analyzers, and runtime vulnerability scanners to evaluate the collected artifacts. The labeling component is described in detail at paragraphs [0108] to [0111], where it is shown to compute risk scores based on rule- defined criteria and optionally apply a trained IHMVIM to generate predictive labels such as RED, YELLOW, or GREEN. Taken together, these disclosures convey definite structure to a person of
ordinary skill in the art and provide ample guidance for implementing the claimed components.
The claim terms are therefore not subject to §112(f) and should be interpreted under the broadest reasonable interpretation standard without invoking means-plus-function treatment.
Accordingly, Applicant respectfully requests that the Examiner withdraw the §112(f) treatment of the recited components and interpret the claims under the ordinary framework applicable to computer-implemented inventions with explicit structural context.
(Applicant’s response filed on 08/06/2025, page 13-14).
Examiner’s Response:
The Examiner respectfully disagrees. The usage of 112(f) for the claim interpretation of claim 1 is done due to the following wording of the limitation “a data gathering component configured to collect microservice release information including microservice source code, source code dependencies, and runtime environment” where a data gathering component is a generic structure, the linking language of comprising, and insufficient structure or acts “collect microservice release information including microservice source code, source code dependencies, and runtime environment”. A similar break down can be done the other components in the claim. As such the claim language does invoke interpretation under 112(f). Meaning the limitations are to be interpreted as their actions and structure are represented in the specification. The Examiner recommends modifying the claim language to “gathering data of microservice release information…” or “a data gathering component comprising a processor configured to collect...” to overcome the claim interpretation.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “a data gathering module configured to”, “a labeling component configured to” in claim 1. Examiner interprets the structure of the modules as referenced in the specification ¶ 73, “The computing device 310 hosts the software components and resources necessary for the operation of system 300, such as the microservice composition module 320, data gathering module 330, security assessment module 340, and labeling module 350.”
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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, 3, 7, 9, 11, 13, 16-17, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hwang (US 11,968,224 B2), hereinafter Hwang in view of Millar (US 12,118,095 B1), hereinafter Millar in further view of Noeth (US 2018/0307833 A1), hereinafter Noeth.
Regarding Claim(s) 11 and 16 Hwang teaches:
A method for automated security assessment of microservices in a Cloud Platform, comprising: (Hwang Col. 1 Ln. 50-60 Fig. 1 Col. 10 Ln. 14-35 teaches, Embodiments of the present invention disclose a method, a computer system, and a computer program product for security risk analysis. Col. 2 Ln. 60-67 teaches, information technology cyber-attacks are growing and, as a result, security measures are constantly requiring new and improved methods to counterbalance the cyber-attacks. Cloud computing environments, such as microservices, and users of microservices 65 and computing applications can benefit from greater security measures.)
collecting microservice release information including microservice source code, source code dependencies, and runtime environment; (Hwang Col. 2 Ln. 5-17 teaches, in another aspect of the exemplary embodiments, the method, the computer system and the computer program product include constructing a semantic graph using shift left data such as source code, deployment configurations and deployment specifications. (i.e., source code, dependencies, and environment) Col. 3 Ln. 11-20 teaches, Input data or datasets used for training, testing and updating models may include, for example, operational data obtained from shift-left activities.)
performing security assessments at each layer by analyzing the microservice source code, tracking vulnerabilities in third-party dependencies, and identifying vulnerabilities in the runtime environment; (Hwang Col. 5 Ln. 5-27 teaches, for example, security violations can include external libraries (i.e., third-party dependencies) that have security or vulnerability issues that have been reported, operating system calls that have security issues, or configuration level or environment level security issues.)
Hwang does not appear to explicitly teach but in related art Millar:
assigning a security state label to each microservice based on scores obtained from a set of security rules; and (Millar Fig. 2 Col. 8 Ln. 1-10 teaches, in alternative embodiments, an initial graphical user interface presented to an analyst may include a set of findings that are automatically sorted and/or filtered based on confidence score and/or severity. (i.e., label))
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Hwang with Millar, to modify the shift-left security risk analysis system of Hwang with the security platform displaying potential vulnerability information of Millar. The motivation to do so, Millar Col. 7 Ln. 35-44, improve efficiency and effectiveness while reducing alert fatigue.
Hwang in view of Millar does not appear to explicitly teach but in related art:
predicting the security state of microservices based on historical data using a hidden Markov model. (Noeth ¶ 66 teaches the concept, anomalies may be detected by training a hidden Markov model or recurrent neural network on historical network traffic.)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Hwang in view of Millar with Noeth, to modify the shift-left security risk analysis system of Hwang with the security platform displaying potential vulnerability information of Millar with the anomaly detection using a hidden Markov model of Noeth. The motivation to do so, Noeth ¶ 68, the detection of anomalies in a system.
Regarding Claim(s) 13 Hwang-Millar-Noeth teaches:
The method of claim 11, (Andr in view of Noeth teaches the parent claim above.) wherein the security assessments at each layer are performed using a combination of static code analysis, dynamic analysis, software composition analysis, and container vulnerability scanning techniques. (Hwang Col.6 Ln. 17-33 teaches, an operational flowchart illustrating the exemplary shift-left security risk analysis (shift left analysis is dynamic that can perform composition and container analysis) process used by the security risk program according to at least one embodiment is depicted. The operational datasets may be used to build pipelines, such as testing results and static analyses.)
The motive given in Claim 11 is equally applicable to the above claim.
Regarding Claim(s) 17 Hwang-Millar-Noeth teaches:
The non-transitory computer-readable medium of claim 16, (Hwang-Millar-Noeth teaches the parent claim above.) wherein the instructions further cause the processor to generate a visual representation of the predicted security states of the microservices (Millar Fig. 2 Col. 8 Ln. 1-10 teaches, in alternative embodiments, an initial graphical user interface presented to an analyst may include a set of findings that are automatically sorted and/or filtered based on confidence score and/or severity. (i.e., label)) based on the hidden Markov model analysis. (Noeth ¶ 66 teaches the concept, anomalies may be detected by training a hidden Markov model or recurrent neural network on historical network traffic.)
The motive given in Claim 11 is equally applicable to the above claim.
Regarding Claim(s) 20 Hwang-Millar-Noeth teaches:
The non-transitory computer-readable medium of claim 16, (Hwang-Millar-Noeth teaches the parent claim above.) wherein the instructions further cause the processor to track and store historical security data to continuously update and refine the hidden Markov model for more accurate security state predictions. (Noeth ¶ 53 teaches, utilizing adversarial neural networks, advanced models may conduct a series of automated requests and analysis of cloud data stores and tasked endpoint agent collection to create deterministic predictions of maliciousness based on classifiers of historical events, open-source data, and recorded user/human engagement with the platform.)
The motive given in Claim 16 is equally applicable to the above claim.
Regarding Claim(s) 1 Hwang in view of Noeth teaches:
A system for performing automated security assessment of microservices in a cloud platform, comprising: (Hwang Col. 1 Ln. 50-60 teaches, Embodiments of the present invention disclose a method,
a computer system, and a computer program product for security risk analysis. Col. 2 Ln. 60-67 teaches, information technology cyber-attacks are growing and, as a result, security measures are constantly requiring new and improved methods to counterbalance the cyber-attacks. Cloud computing environments, such as microservices, and users of microservices 65 and computing applications can benefit from greater security measures.)
a microservice module comprising a set of microservices, each microservice comprising one or more rules as a separate project following its own development lifecycle for enhanced observability and precise risk score estimations; (Hwang Col. 13 Ln. 45-55 teaches, workloads layer provides examples of functionality for which the cloud computing environment may be utilized. Examples of workloads and functions that may be provided from this layer include: mapping and navigation; software development and lifecycle management. A security risk program provides a way to provide security risk analyses using machine learning.)
microservice release information including microservice source code, source code dependencies, and runtime environment; (Hwang Col. 2 Ln. 5-17 teaches, In another aspect of the exemplary embodiments, the method, the computer system and the computer program product include constructing a semantic graph using shift left data such as source code, deployment configurations and deployment specifications. Col. 3 Ln. 11-20 teaches. Input data or datasets used for training, testing and
updating models may include, for example, operational data obtained from shift-left activities.)
a security assessment component comprising one or more automatic and semi- automatic tools to analyze the microservice source code, track vulnerabilities in third-party dependencies, and/or identify vulnerabilities in the runtime environment; and (Hwang Col. 5 Ln. 5-27 teaches, for example, security violations can include external libraries that have security or vulnerability issues that have been reported, operating system calls that have security issues, or configuration level or environment level security issues.)
Hwang does not appear to explicitly teach but in related art Millar teaches:
a data gathering component configured to collect (Millar Col. 5 Ln. 40-58 teaches, the information associated with each individual potential security vulnerability may be provided to the confidence score prediction component(s) 122 of the ML model 112. For each of the individual potential security vulnerabilities, the confidence score prediction component(s) 122 may be configured to generate respective confidence scores associated with the individual potential security vulnerabilities.)
a labeling component configured to assign a security state label to each microservice based on scores obtained from a set of security rules, (Millar Fig. 2 Col. 6 Ln. 1-13 and Col. 8 Ln. 1-10 teaches, the information associated with each individual potential security vulnerability may be provided to the confidence score prediction component(s) 122 of the ML model 112. For each of the individual potential security vulnerabilities, the confidence score prediction component(s) 122 may be configured to generate respective confidence scores associated with the individual potential security vulnerabilities. in alternative embodiments, an initial graphical user interface presented to an analyst may include a set of findings that are automatically sorted and/or filtered based on confidence score and/or severity. (i.e., label))
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Hwang with Millar, to modify the shift-left security risk analysis system of Hwang with the security platform displaying potential vulnerability information of Millar. The motivation to do so, Millar Col. 7 Ln. 35-44, improve efficiency and effectiveness while reducing alert fatigue.
Hwang in view of Millar does not appear to explicitly teach but in related art:
wherein the labeling component employs one or more models to predict the security state of microservices based on historical data, the one or more models selected from: a hidden Markov model (HMM), a Regression Analysis, a Random Forest, an Artificial Neural Network (ANN), a Support Vector Machines (SVM), an Artificial Intelligence (AI) Model, and a Bayesian Network. (Noeth ¶ 66 teaches the concept, anomalies may be detected by training a hidden Markov model or recurrent neural network on historical network traffic.)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Hwang in view of Millar with Noeth, to modify the shift-left security risk analysis system of Hwang with the security platform displaying potential vulnerability information of Millar with the anomaly detection using a hidden Markov model of Noeth. The motivation to do so, Noeth ¶ 68, the detection of anomalies in a system.
Regarding Claim(s) 7 Hwang-Millar-Noeth teaches:
The system of claim 1, (Hwang-Millar-Noeth teaches the parent claim above.) wherein the microservice release information further includes metadata about the base image and runtime environment used by the microservices. (Hwang Col. 3 Ln. 1-11 and Col.5 Ln. 5-18 teaches, many security detection methods consist of searching for vulnerabilities in libraries and base image. Input data may also include computer programming code 5 and sections of the programming code, such as code snippets. (i.e., metadata) Code snippets may be broken down into segments and different aggregation techniques may be used to improve classification. For example, a code snippet that creates a file during runtime can be manipulated over time with certain 10 permissions and this is a security violation in a cloud environment.)
Regarding Claim(s) 9 Andr in view of Noeth teaches:
The system of claim 1, (Andr in view of Noeth) wherein the labeling component assigns the security state label based on cumulative scores obtained from the security rules. (Millar Col. 15 Ln. 4-22 teaches, FIG. 12, the confidence scores may be used for further ranking of findings, whereby the severity of the finding and the confidence score are used in combination to produce an overall ranking metric)
The motive given in Claim 11 is equally applicable to the above claim.
Regarding Claim(s) 2 Hwang-Millar-Noeth teaches:
The system of claim 1, (Hwang-Millar-Noeth teaches the parent claim above.) wherein the one or more models is the hidden Markov model (HMM). (Noeth ¶ 66 teaches the concept, anomalies may be detected by training a hidden Markov model or recurrent neural network on historical network traffic.)
The motive given in Claim 1 is equally applicable to the above claim.
Claim(s) 3 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hwang-Millar-Noeth as applied to claim 1 above, and further in view of Zech (US 2024/0289465 A1), hereinafter Zech.
Regarding Claim(s) 3 Hwang-Millar-Noeth teaches:
The system of claim 1, (Hwang-Millar-Noeth teaches the parent claim above.)
Hwang-Millar-Noeth does not appear to explicitly teach but in related art:
wherein the microservice composition model enables isolation of engineering risks from business risks. (Zech ¶ 28 teaches the concept, the vulnerability content may be separated into different sets of data.)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Hwang-Millar-Noeth with Zech, to modify the shift-left security risk analysis system of Hwang with the security platform displaying potential vulnerability information of Millar with the anomaly detection using a hidden Markov model of Noeth with the isolation of different kinds of risk of Zech. The motivation to do so constitutes applying a known technique of separating different types of data to known devices and/or methods of security risk analysis ready for improvement to yield predictable results of having more in-depth analysis.
Claim(s) 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hwang-Millar-Noeth as applied to claim 1 above, and further in view of Markley (US 2005/0132350 A1), hereinafter Markley.
Regarding Claim(s) 5 Hwang-Millar-Noeth teaches:
The system of claim 1, (Hwang-Millar-Noeth teaches the parent claim above.)
Hwang-Millar-Noeth does not appear to explicitly teach but in related art:
wherein the data gathering component utilizes APIs and/or scraping techniques to gather information about source code dependencies from package managers, build files, or manifest files associated with the microservices. (Markley ¶ 5 teaches, The API exists as a build system API as well as an embedded device API, and serves to effectively parse the device manifest files of a collection of package files.)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Hwang-Millar-Noeth with Markley, to modify the shift-left security risk analysis system of Hwang with the security platform displaying potential vulnerability information of Millar with the anomaly detection using a hidden Markov model of Noeth with the API for gathering manifest and package files of Markley. The motivation to do so constitutes applying a known technique of gathering data via APIs to known devices and/or methods of security risk analysis ready for improvement to yield predictable results of enhanced data collection.
Claim(s) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hwang-Millar-Noeth as applied to claim 1 above, and further in view of Wu (US 2023/0244593 A1), hereinafter Wu.
Regarding Claim(s) 6 Hwang-Millar-Noeth teaches:
The system of claim 1, (Hwang-Millar-Noeth teaches the parent claim above.) wherein the security assessment component software composition analysis, and container vulnerability scanning. (Hwang Col.6 Ln. 17-33 teaches, an operational flowchart illustrating the exemplary shift-left security risk analysis (shift left analysis is dynamic that can perform composition and container analysis) process used by the security risk program according to at least one embodiment is depicted. The operational datasets may be used to build pipelines, such as testing results and static analyses.)
Hwang-Millar-Noeth does not appear to explicitly teach but in related art:
integrates with security tools via APIs or command-line interfaces to perform static code analysis, dynamic analysis, (WU ¶ 25 teaches, flow diagram illustrates a method performed by the REST API dynamic analysis engine)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Hwang-Millar-Noeth with Wu, to modify the shift-left security risk analysis system of Hwang with the security platform displaying potential vulnerability information of Millar with the anomaly detection using a hidden Markov model of Noeth with the API for dynamic analysis of Wu. The motivation to do so constitutes applying a known technique of dynamic analysis via APIs to known devices and/or methods of security risk analysis ready for improvement to yield predictable results of enhanced data analysis.
Claim(s) 12 and 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hwang-Millar-Noeth as applied to claim 11 above, and further in view of Bubshait (US 2024/0143781 A1), hereinafter Bub.
Regarding Claim(s) 12 Hwang-Millar-Noeth teaches:
The method of claim 11, (Hwang-Millar-Noeth teaches the parent claim above.)
Hwang-Millar-Noeth does not appear to explicitly teach but in related art:
further comprising generating a security report for each microservice, including details of identified vulnerabilities, their severity levels, and recommended remediation actions. (Bub ¶ 40 teaches, the method includes evaluating a computer application by using the system described above. The method includes steps of starting (e.g., block 301), receiving an assessment report, identifying vulnerabilities, determining exploitability levels, calculating risk levels, determining remediation prioritization (, and generating a remediation prioritization report.)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Hwang-Millar-Noeth with Bub, to modify the shift-left security risk analysis system of Hwang with the security platform displaying potential vulnerability information of Millar with the anomaly detection using a hidden Markov model of Noeth with the remediation report of Bub. The motivation to do so, Bub ¶ 13, mitigate or reduce an amount of damage that such threats cause to one or more systems or a network to which the one or more systems are coupled.
Regarding Claim(s) 8 Hwang-Millar-Noeth -Bub teaches:
The system of claim 1, (Hwang-Millar-Noeth teaches the parent claim above.) wherein the security assessment component generates detailed reports and findings, including lists of security vulnerabilities, associated scores or severity levels, and evidence or descriptions of the vulnerabilities. (Bub ¶ 40 teaches, the method 300 includes evaluating a computer application by using the system 100 described above. The method 300 includes steps of starting (e.g., block 301), receiving an assessment report (e.g., block 302), identifying vulnerabilities (e.g., block 303), determining exploitability levels (e.g., block 304), calculating risk levels (e.g., block 305), determining remediation prioritization (e.g., block 306), and generating a remediation prioritization report (e.g., block 307).)
The motive given in Claim 12 is equally applicable to the above claim.
Claim(s) 10 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hwang-Millar-Noeth as applied to claim 11 and 1 above, and further in view of Packwood (US 7,006,992 B1), hereinafter Packwood.
Regarding Claim(s) 14 Hwang-Millar-Noeth teaches:
The method of claim 11, (Hwang-Millar-Noeth teaches the parent claim above.)
Hwang-Millar-Noeth does not appear to explicitly teach but in related art:
wherein the security state label comprises a color-coded indicator representing the overall security status of each microservice, with "RED" indicating immediate attention required, "YELLOW" indicating at-risk status, and "GREEN" indicating compliance with security standards. (Packwood Col. 7 Ln. 29-47 teaches, corresponding to each entered risk factor. The outputs are color-coded 260 depending on the results of the comparison with the programmed ranges of risk level values to indicate 40 acceptable or unacceptable results. Preferably three colors and ranges are used, so that each risk factor is described and a color-coded bar is used to show compliance (green), caution (yellow) or non-compliance (red). The numeric value, used to determine risk level range in which the 45 measured risk factor falls, is also presented for assessment of the severity of the identified problems.)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Hwang-Millar-Noeth with Packwood, to modify the shift-left security risk analysis system of Hwang with the security platform displaying potential vulnerability information of Millar with the anomaly detection using a hidden Markov model of Noeth with the labeling method of Packwood. The motivation to do so, Packwood Col. 12 Ln. 34-37, to further improve the report and make reference to a particular risk factor easier.
Regarding Claim(s) 10 Hwang-Millar-Noeth -Packwood teaches:
The system of claim 1, (Hwang-Millar-Noeth teaches the parent claim above.) wherein the security state label comprises "RED" for microservices requiring immediate attention, "YELLOW" for microservices at risk, and "GREEN" for microservices meeting security standards. (Packwood Col. 7 Ln. 29-47 teaches, corresponding to each entered risk factor. The outputs are color-coded 260 depending on the results of the comparison with the programmed ranges of risk level values to indicate 40 acceptable or unacceptable results. Preferably three colors and ranges are used, so that each risk factor is described and a color-coded bar is used to show compliance (green), caution (yellow) or non-compliance (red). The numeric value, used to determine risk level range in which the 45 measured risk factor falls, is also presented for assessment of the severity of the identified problems.)
The motive given in Claim 14 is equally applicable to the above claim.
Claim(s) 4 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hwang-Millar-Noeth as applied to claim 11 and 1 above, and further in view Achleitner (US 2024/0427902 A1), hereinafter Ach.
Regarding Claim(s) 15 Hwang-Millar-Noeth teaches:
The method of claim 11, (Hwang-Millar-Noeth teaches the parent claim above.) further comprising integrating the security state labels with a security dashboard or monitoring system to provide real-time visibility into the security posture of the microservices. (Ach ¶ 38 teaches, after having updated server-side vulnerability database, the real-time monitoring of loading/executing vulnerable software component on a client-side application)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Hwang-Millar-Noeth with Ach, to modify the shift-left security risk analysis system of Hwang with the security platform displaying potential vulnerability information of Millar with the anomaly detection using a hidden Markov model of Noeth with the automated real time identification of vulnerabilities of Ach. The motivation to do so, Ach ¶ 4, to improve the quality of the data output.
Regarding Claim(s) 4 Hwang-Millar-Noeth-Ach teaches:
The system of claim 1, (Hwang-Millar-Noeth teaches the parent claim above.) wherein the data gathering component interfaces with version control systems or repositories to extract the microservice source code. (Ach ¶ 144 teaches the concept, the link from the vulnerability database to a patch on a source-code repository is extracted and the link is followed)
Claim(s) 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hwang-Millar-Noeth as applied to claim 16 above, and further in view Lou (US 2024/0386243 A1), hereinafter Lou.
Regarding Claim(s) 18 Hwang-Millar-Noeth teaches:
The non-transitory computer-readable medium of claim 16, (Hwang-Millar-Noeth teaches the parent claim above.)
Hwang-Millar-Noeth does not appear to explicitly teach but in related art:
wherein the instructions further cause the processor to incorporate machine learning techniques to improve the accuracy of the hidden Markov model predictions over time. (Lou ¶ 28 teaches, by generating the customized hidden Markov models utilizing deep neural networks.)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Hwang-Millar-Noeth with Lou, to modify the shift-left security risk analysis system of Hwang with the security platform displaying potential vulnerability information of Millar with the anomaly detection using a hidden Markov model of Noeth with the improved Markov model of Lou. The motivation to do so, Lou ¶ 29, improves efficiency with respect to conventional systems.
Claim(s) 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hwang-Millar-Noeth as applied to claim 16 above, and further in view Murthy (US 2024/0419794 A1), hereinafter Murthy.
Regarding Claim(s) 19 Hwang-Millar-Noeth teaches:
The non-transitory computer-readable medium of claim 16, (Hwang-Millar-Noeth teaches the parent claim above.) wherein the instructions further cause the processor to provide recommendations for security enhancements based on the predicted security states and identified vulnerabilities. (Murthy ¶ 40-42 teaches, the vulnerability validator 116 can analyze the changes that were performed to fix the vulnerability and recommend steps to fix the vulnerability. This allows, for example, the vulnerability validator 116 to determine if there are any known vulnerabilities and recommend fixes even before proceeding with new build and/or vulnerability scan processes.)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Hwang-Millar-Noeth with Murthy, to modify the shift-left security risk analysis system of Hwang with the security platform displaying potential vulnerability information of Millar with the anomaly detection using a hidden Markov model of Noeth with the security recommendations of Murthy. The motivation to do so, Murthy ¶ 42, to determine if there are any known vulnerabilities and recommend fixes even before proceeding with new build and/or vulnerability scan processes.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 2025/0055876 - Automated Risk Assessment Module with Real-Time Compliance Monitoring
US 2023/0412620 A1 - SYSTEM AND METHODS FOR CYBERSECURITY ANALYSIS USING UEBA AND NETWORK TOPOLOGY DATA AND TRIGGER - BASED NETWORK REMEDIATION
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JACOB BENEDICT KNACKSTEDT whose telephone number is (703)756-5608. The examiner can normally be reached Monday-Friday 8:00 am - 5:00 pm.
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, Linglan Edwards can be reached on (571) 270-5440. 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.
/J.B.K./Examiner, Art Unit 2408
/LINGLAN EDWARDS/Supervisory Patent Examiner, Art Unit 2408
Prosecution Insights