DETAILED ACTION
This office action is in response to the application filed on 06/22/2026. 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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after allowance or after an Office action under Ex Parte Quayle, 25 USPQ 74, 453 O.G. 213 (Comm'r Pat. 1935). Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, prosecution in this application has been reopened pursuant to 37 CFR 1.114. Applicant's submission filed on 06/22/2026 has been entered.
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-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lambotte (US 11,829,486 B1), hereinafter Lambotte in view of Alagappan (US 10,713,664 B1), hereinafter Alag.
Regarding Claim(s) 1 Lambotte teaches:
A system for performing automated security assessment of microservices in a cloud platform, comprising: (Lambotte Col. 23 Ln.47-54 teaches, cybersecurity enhancement program may include one or more core information security practices such as, without limitation, performing ongoing security assessments (i.e., cybersecurity assessment))
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 (Lambotte Col. 23 Ln. 53-57 teaches, ongoing security assessments (i.e., cybersecurity assessment) to look for and/or resolve distributed denial-of service attack (DDos) related vulnerabilities, email phishing testing, network monitoring, and the like thereof.)
a labeling component configured to assign a security state label to each microservice based on scores obtained from a set of security rules, 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, wherein the labeling component is configured to: (Lambotte Col. 21 Ln. 12-22 teaches, cybersecurity machine-learning process may include a cybersecurity threat classifier. Identifying at least one cybersecurity threat classification may include generating a cybersecurity threat classifier using processor. A “classifier,” as used in this disclosure is a machine-learning model, such as a mathematical model, neural net, or program generated by a machine learning algorithm known as a “classification algorithm,” as described in further detail below, that sorts inputs into categories or bins of data, outputting the categories or bins of data and/or labels associated therewith. Col. 28 Ln. 55-57 teaches, sequential tokens may be modeled as chains, serving as the observations in a Hidden Markov Model.)
(a) compute, for each individual microservice and for each release of that microservice, a single cumulative security score by aggregating scores produced by a predefined set of security rules respectively applied to (Lambotte Col. 39 Ln. 36-41 teaches, a cybersecurity threat classification model may be configured to input collected data and cluster data lo a centroid based on, but not limited to, frequency of appearance, linguistic indicators of quality, and the like. Centroids may include scores assigned to them such that quality of entity data may each be assigned a score.) (i) static analysis results of the microservice's own source code, (ii) software composition analysis results of the microservice's third-party dependencies, and (iii) container or runtime-environment scanning results of that microservice; (Lambotte Col.30-31 Ln. 63-67 and 1-7 teaches, Cyber-attack simulation module may include a simulation statistical model configured to perform statistical analysis such as, without limitation, data collection, descriptive statistical analysis, inferential statistical analysis, associational statistical analysis, predictive analysis, prescriptive analysis, exploratory data analysis, causal analysis, and the like to plurality of responses to malicious data. Statistical analysis may be performed through one or more statistical analysis process such as, without limitation, data collection, data organization, data presentation, data analysis, data interpretation, and the like.)
(d) train a hidden Markov model based on historical sequence of security state labels of the same microservice such that hidden states of the model represent latent security posture of that specific microservice emissions comprise features derived from the cumulative security scores of a current or candidate release, and apply the trained hidden Markov model to predict the most probable next (Lambotte Col. 28 Ln. 55-65 teaches, HMMs as used herein are statistical models with inference algorithms that that may be applied to the models. In such models, a hidden state to be estimated may include an association between an extracted words, phrases, and/or other semantic units.)
Lambotte does not appear to explicitly teach but in related art:
a microservice module comprising a set of microservices; (Alag Col. 21 Ln. 1-5 teaches, Applying the compliance rule to microservice monitoring can including performing a curated rules and policies scan, a network protocol scan, a security protocol scan, an IP address scan, an RBAC scan, an ACL scan, and an endpoint scan, based upon which the corresponding self-assessment questionnaire report is generated.)
a data gathering component configured to collect microservice release information including microservice source code, source code dependencies, and runtime environment; (Alag Col. 13-14 Ln. 64-67 and 1-4 teaches, a source code repository operations, a CI/CD pipeline continuous build/test/integration/deployment tool, a continuous performance testing tool, a repository dependency manager tool, a cloud platform services component, and a microservice monitoring tool, which in accordance with one or more aspects of the present invention, can each be wrapped with compliance processing such as disclosed herein.)
(b) assign exactly one security state label selected from RED, YELLOW, and
GREEN to that microservice for that release based on said single cumulative security score; (Alag Col. 16 Ln. 35-40 teaches, the scanner accepts properly formatted (curated) rules, along with input from the rules engine, and is able deliver vulnerability assessments, such as rated by risk, which can be color-coded (in one embodiment).)
(c) store, over a plurality of prior releases of the same microservice, a historical sequence comprising the security state labels previously assigned to that identical microservice under the predefined set of security rules; and (Alag Col. 7 Ln. 35-41 teaches, The rules engine generates, in one or more embodiments, a regulation-compliance report, such as a self-assessment questionnaire (SAQ) report, for the microservice based on the received responses to the compliance queries, and stores the report, for instance, in local metadata store, as well as provides the report to a compliance auditor and/or authority.)
security state label (RED, YELLOW, or GREEN) that the same microservice will receive in a future release. (Alag Col. 16 Ln. 35-40 teaches, the scanner accepts properly formatted (curated) rules, along with input from the rules engine, and is able deliver vulnerability assessments, such as rated by risk, which can be color-coded (in one embodiment).)
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 Lambotte with Alag, to modify the method for enhancing cybersecurity of an entity of Lambotte with the method for automated evaluation and reporting of microservice regulatory compliance of Alag. The motivation to do so, Alag Col. 1 Ln. 21-
23, a microservice architecture is commonly adopted for cloud native applications, and applications using lightweight container deployment.
Regarding Claim(s) 2 Lambotte in view of Alag teaches:
The system of claim 1, (Lambotte in view of Alag teaches the parent claim above.) wherein the one or more models is the hidden Markov model (HMM). (Lambotte Col. 28 Ln. 55-65 teaches, HMMs as used herein are statistical models with inference algorithms that that may be applied to the models. In such models, a hidden state to be estimated may include an association between an extracted words, phrases, and/or other semantic units.)
Regarding Claim(s) 3 Lambotte in view of Alag teaches:
The system of claim 1, (Lambotte in view of Alag teaches the parent claim above.) wherein the microservice composition model enables isolation of engineering risks from business risks. (Lambotte Col. 25 Ln. 24-27 teaches, computer programs may include one or more computer programs configured to reduce and/or mitigate cybersecurity risk exposed and/or hidden in entity such as, without limitation, cybersecurity risk management tools.)
Regarding Claim(s) 4 Lambotte in view of Alag teaches:
The system of claim 1, (Lambotte in view of Alag teaches the parent claim above.) wherein the data gathering component interfaces with version control systems or repositories to extract the microservice source code. (Alag Col. 13 Ln. 63-85 teaches, The DevOps cycle can use a variety of external tools or repositories, including, for instance, a source code repository operations)
The motive given in Claim 1 is equally applicable to the above claim.
Regarding Claim(s) 5 Lambotte in view of Alag teaches:
The system of claim 1, (Lambotte in view of Alag teaches the parent claim above.), 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. (Lambotte Col. 15 Ln. 15-27 teaches, Automated evaluation may include automatically collecting entity data from entity. In a non-limiting example, processor may be configured to run a security process, wherein the security process is an instance of a computer program that is being executed by one or more threads configured to extract entity datafrom one or more components, systems, or otherwise devices within entity; for instance, processor may utilize a security software and/or application programming interface (API) configured to determine whether system structure, endpoints, access point, system configurations, any other aspects of entity comply within one or more security standards described above.)
Regarding Claim(s) 6 Lambotte in view of Alag teaches:
The system of claim 1, (Lambotte in view of Alag teaches the parent claim above.), wherein the security assessment component integrates with security tools via APIs or command-line interfaces to perform static code analysis, dynamic analysis, software composition analysis, and container vulnerability scanning. (Lambotte Col.30-31 Ln. 63-67 and 1-7 teaches, Cyber-attack simulation module may include a simulation statistical model configured to perform statistical analysis such as, without limitation, data collection, descriptive statistical analysis, inferential statistical analysis, associational statistical analysis, predictive analysis, prescriptive analysis, exploratory data analysis, causal analysis, and the like to plurality of responses to malicious data. Statistical analysis may be performed through one or more statistical analysis process such as, without limitation, data collection, data organization, data presentation, data analysis, data interpretation, and the like.)
Regarding Claim(s) 7 Lambotte in view of Alag teaches:
The system of claim 1, (Lambotte in view of Alag teaches the parent claim above.), wherein the microservice release information further includes metadata about the base image and runtime environment used by the microservices. (Lambotte Col. 10 Ln. 54-59 teaches, device information may include software information such as, without limitation, dependencies, software version, package content, file type, program size, installation method, information of any program/software described in this disclosure, and the like thereof)
Regarding Claim(s) 8 Lambotte in view of Alag teaches:
The system of claim 1, (Lambotte in view of Alag 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. (Lambotte Col. 19 Ln. 16-24 teaches, cybersecurity metric may include one or more key performance indicators (KPI), wherein the key performance indicator is a type of performance measurement. KPI may evaluate the success of entity in cybersecurity. In a non-limiting example, KPI within cybersecurity metric may include, without limitation, meantime to detect (MTTD), mean time lei resolve (MTTR), mean time to contain (MTTC), patching cadence, security rating, number of known vulnerabilities, and the like thereof. Col. 30 Ln. 49-67, performing the cyber-attack simulation 160 may include generating a cybersecurity report 168 as a function of cyber-allack simulation. As used in this disclosure, a "cybersecurity report" is a set of critical information about cybersecurity of entity. In some embodiments, cybersecurity report may include, without limitation, representations of entity data, cybersecurity threat classification, cybersecurity enhancement program, and the like thereof.").)
Regarding Claim(s) 9 Lambotte in view of Alag teaches:
The system of claim 1, (Lambotte in view of Alag teaches the parent claim above.), wherein the labeling component assigns the security state label based on cumulative scores obtained from the security rules. (Lambotte Col. 39 Ln. 36-41 teaches, a cybersecurity threat classification model may be configured to input collected data and cluster data lo a centroid based on, but not limited to, frequency of appearance, linguistic indicators of quality, and the like. Centroids may include scores assigned to them such that quality of entity data may each be assigned a score.)
Regarding Claim(s) 10 Lambotte in view of Alag teaches:
The system of claim 1, (Lambotte in view of Alag 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. (Alag Col. 16 Ln. 35-40 teaches, the scanner accepts properly formatted (curated) rules, along with input from the rules engine, and is able deliver vulnerability assessments, such as rated by risk, which can be color-coded (in one embodiment).)
The motive given in Claim 1 is equally applicable to the above claim.
Regarding Claim(s) 11 and 16 Lambotte in view of Alag teaches:
A method for automated security assessment of microservices in a Cloud Platform, comprising: (Lambotte Col. 23, Ln. 51-54 teaches, cybersecurity enhancement program may include one or more core information security practices such as, without limitation, performing ongoing security assessments (i.e., cybersecurity assessment). Col. 43 Ln. 10-17 teaches, storage device 724 and an associated machine-readable medium 728 may provide nonvolatile and/or volatile storage of machine-readable instructions, data structures, program modules, and/or other data for computer system 700. In one example, software 720 may reside, completely or partially, within machine-readable medium 728.)
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; (Lambotte Col. 23, Ln. 51-54 teaches, ongoing security assessments (i.e., cybersecurity assessment) to look for and/or resolve distributed denial of service attack (DDos) related vulnerabilities, email phishing testing, network monitoring, and the like thereor)
assigning a security state label to each microservice based on scores obtained from a set of security rules, wherein assigning the label comprises: (Lambotte Col. 39 Ln. 36-41 teaches, A cybersecurity threat classification model may be configured to input collected data and cluster data to a centroid based on, but not limited to, frequency of appearance, linguistic indicators of quality, and the like. Centroids may include scores assigned to them such that quality of entity data may each be assigned a score.)
computing, for each individual microservice and for each release of that microservice, a single cumulative security score by aggregating scores produced by a predefined set of security rules (Lambotte Col. 39 Ln. 36-41 teaches, a cybersecurity threat classification model may be configured to input collected data and cluster data lo a centroid based on, but not limited to, frequency of appearance, linguistic indicators of quality, and the like. Centroids may include scores assigned to them such that quality of entity data may each be assigned a score.) respectively applied to (i) static analysis results of the microservice's own source code, (ii) software composition analysis results of the microservice's third-party dependencies, and (iii) container or runtime-environment scanning results of that microservice; (Lambotte Col.30-31 Ln. 63-67 and 1-7 teaches, Cyber-attack simulation module may include a simulation statistical model configured to perform statistical analysis such as, without limitation, data collection, descriptive statistical analysis, inferential statistical analysis, associational statistical analysis, predictive analysis, prescriptive analysis, exploratory data analysis, causal analysis, and the like to plurality of responses to malicious data. Statistical analysis may be performed through one or more statistical analysis process such as, without limitation, data collection, data organization, data presentation, data analysis, data interpretation, and the like.)
[[and]] predicting the security state of microservices based on historical data using a hidden Markov model (Lambotte Col. 28 Ln. 55-57 teaches, sequential tokens may be modeled as chains, serving as the observations in a Hidden Markov Model (HMM).").)
training a hidden Markov model based on historical sequence of security state labels of the same microservice, and applying the trained hidden Markov model to predict the most probable next (Lambotte Col. 28 Ln. 55-65 teaches, HMMs as used herein are statistical models with inference algorithms that that may be applied to the models. In such models, a hidden state to be estimated may include an association between an extracted words, phrases, and/or other semantic units.)
Lambotte does not appear to explicitly teach but in related art:
collecting microservice release information including microservice source code, source code dependencies, and runtime environment; (Alag Col. 13-14 Ln. 64-67 and 1-4 teaches, a source code repository operations, a CI/CD pipeline continuous build/test/integration/deployment tool, a continuous performance testing tool, a repository dependency manager tool, a cloud platform services component, and a microservice monitoring tool, which in accordance with one or more aspects of the present invention, can each be wrapped with compliance processing such as disclosed herein. Alag Col. 21 Ln. 1-5 teaches, Applying the compliance rule to microservice monitoring can including performing a curated rules and policies scan, a network protocol scan, a security protocol scan, an IP address scan, an RBAC scan, an ACL scan, and an endpoint scan, based upon which the corresponding self-assessment questionnaire report is generated.)
(b) assigning a security state label selected from RED, YELLOW, and GREEN to that microservice for that release based on said single cumulative security score; (Alag Col. 16 Ln. 35-40 teaches, the scanner accepts properly formatted (curated) rules, along with input from the rules engine, and is able deliver vulnerability assessments, such as rated by risk, which can be color-coded (in one embodiment).)
storing, over a plurality of prior releases of the same microservice, a historical sequence comprising the security state labels previously assigned to that identical microservice under the predefined set of security rules; and (Alag Col. 7 Ln. 35-41 teaches, The rules engine generates, in one or more embodiments, a regulation-compliance report, such as a self-assessment questionnaire (SAQ) report, for the microservice based on the received responses to the compliance queries, and stores the report, for instance, in local metadata store, as well as provides the report to a compliance auditor and/or authority.)
security state label (RED, YELLOW, or GREEN) that the same microservice will receive in a future release. (Alag Col. 16 Ln. 35-40 teaches, the scanner accepts properly formatted (curated) rules, along with input from the rules engine, and is able deliver vulnerability assessments, such as rated by risk, which can be color-coded (in one embodiment).)
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 Lambotte with Alag, to modify the method for enhancing cybersecurity of an entity of Lambotte with the method for automated evaluation and reporting of microservice regulatory compliance of Alag. The motivation to do so, Alag Col. 1 Ln. 21-
23, a microservice architecture is commonly adopted for cloud native applications, and applications using lightweight container deployment.
Regarding Claim(s) 12 Lambotte in view of Alag teaches:
The method of claim 11, (Lambotte in view of Alag teaches the parent claim above.) further comprising generating a security report for each microservice, including details of identified vulnerabilities, their severity levels, and recommended remediation actions. (Lambotte Col 19. Ln. 16-24 teaches, cybersecurity metric may include one or more key performance indicators (KPI), wherein the key performance indicator is a type of performance measurement. KPI may evaluate the success of entity in cybersecurity. In a nonlimiting example, KPI within cybersecurity metric may include, without limitation, mean time to detect (MTTD), mean lime to resolve (MTTR), mean lime to contain (MTTC), patching cadence, security rating, number of known vulnerabilities, and the like thereof. Col. 30-31, Ln. 49-67 and Ln. 1-7 teaches, performing the cyber-attack simulation may include generating a cybersecurity report as a function of cyberattack simulation. As used in this disclosure, a "cybersecurity report" is a set of critical information about cybersecurity of entity. In some embodiments, cybersecurity report may include, without limitation, representations of entity data, cybersecurity threat classification, cybersecurity enhancement program, and the like thereof)
Regarding Claim(s) 13 Lambotte in view of Alag teaches:
The method of claim 11, (Lambotte in view of Alag 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. (Lambotte Col.30-31 Ln. 63-67 and 1-7 teaches, Cyber-attack simulation module may include a simulation statistical model configured to perform statistical analysis such as, without limitation, data collection, descriptive statistical analysis, inferential statistical analysis, associational statistical analysis, predictive analysis, prescriptive analysis, exploratory data analysis, causal analysis, and the like to plurality of responses to malicious data. Statistical analysis may be performed through one or more statistical analysis process such as, without limitation, data collection, data organization, data presentation, data analysis, data interpretation, and the like.)
Regarding Claim(s) 13 Lambotte in view of Alag teaches:
The method of claim 11, (Lambotte in view of Alag teaches the parent claim above.) 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. (Alag Col. 16 Ln. 35-40 teaches, the scanner accepts properly formatted (curated) rules, along with input from the rules engine, and is able deliver vulnerability assessments, such as rated by risk, which can be color-coded (in one embodiment).)
Regarding Claim(s) 15 Lambotte in view of Alag teaches:
The method of claim 11, (Lambotte in view of Alag 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. (Lambotte Col. 31-32 Ln. 45-67 and 1-18 teaches, cybersecurity report may be displayed graphically through a visual interface ...
cybersecurity report may include one or more graphs illustrating data such as, without limitation, plurality of responses to malicious data, at least a change to entity data, and the like extracted, processed, and/or analyzed by cyber-attack simulation module, particularly simulation statistical model. In some cases, graphs may include bar graphs, box plots, histograms, pie charts, scatter plots, and the like thereof. In some embodiments, entity may interact with cybersecurity report; for instance, without limitation, entity may be able to change graph types through visual interface. For another example, without limitation, entity may be able to show and/or hide data such as, entity data, cybersecurity threat classification, cybersecurity metric, cybersecurity enhancement program, plurality of responses to malicious data, at least a change to entity data, and the like thereof)
Regarding Claim(s) 17 Lambotte in view of Alag teaches:
The non-transitory computer-readable medium of claim 16, (Lambotte in view of Alag 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 based on the hidden Markov model analysis. (Lambotte Col. 31-32 Ln. 45-67 and 1-18 teaches, cybersecurity report may be displayed ·graphically through a visual interface ... cybersecurity report may include one or more graphs illustrating data such as, without limitation, plurality of responses to malicious data, at least a change to entity data, and the like extracted, processed, and/or analyzed by cyber-attack simulation module, particularly simulation statistical model. In some cases, graphs may include bar graphs, box plots, histograms, pie charts, scatter plots, and the like thereof)
Regarding Claim(s) 18 Lambotte in view of Alag teaches:
The non-transitory computer-readable medium of claim 16, (Lambotte in view of Alag teaches the parent claim above.) wherein the instructions further cause the processor to incorporate machine learning techniques to improve the accuracy of the hidden Markov model predictions over time. (Alag Col. 11 Ln. 1-10 teaches, in a machine learning-based example, program code extracts various features/attributes from the generated ontology resident, for instance, in the metadata storage. In creating the rules engine, including identifying compliance rules and associated compliance queries, the program code can utilize various techniques .to select features (elements, patterns, attributes, etc.) including, but not limited to, diffusion mapping, principle component analysis, recursive feature elimination (a brute force approach to selecting features), and/or a Random Forest)
The motive given in Claim 16 is equally applicable to the above claim.
Regarding Claim(s) 19 Lambotte in view of Alag teaches:
The non-transitory computer-readable medium of claim 16, (Lambotte in view of Alag 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. (Lambotte Col. 19 Ln. 16-24 teaches, cybersecurity metric 132 may include one or more key performance indicators (KPI), wherein the key performance indicator is a type of performance measurement. KPI may evaluate the success of entity in cybersecurity. In a non-limiting example, KPI within cybersecurity metric may include, without limitation, mean time to detect (MTTD), mean time to resolve (MTTR), mean time to contain (MTTC), patching cadence, security rating, number of known vulnerabilities, and the like thereof. Col. 30-31 Ln. 49-67 and 1-7 teaches, performing the cyber-attack simulation may include generating a cybersecurity report as a function of cyber-attack simulation. As used in this disclosure, a "cybersecurity report" is a set of critical information about cybersecurity of entity. In some embodiments, cybersecurity report may include, without limitation, representations of entity data, cybersecurity threat classification, cybersecurity enhancement program, and the like thereof)
Regarding Claim(s) 20 Lambotte in view of Alag teaches:
The non-transitory computer-readable medium of claim 16, (Lambotte in view of Alag 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. (Alag Col. 11 Ln. 1-17 teaches, In a machine learning-based example, program code extracts various features/attributes from the generated ontology resident, for instance, in \he metadata storage. In creating the rules engine, including identifying compliance rules and associated compliance queries, the program code can utilize various techniques to select features (elements, patterns, attributes, etc.) including, but not limited to, diffusion mapping, principle component analysis, recursive feature elimination (a brute force approach to selecting features), and/or a Random Forest to select, for instance, the applicable compliance rules obtained from natural language parsing of the set of regulations from the compliance authority website. The program code can utilize a machine learning algorithm to train the rules engine, including providing classification, rankings or weights for extracted data or conclusions, so the program code can create the rules engine from the stored ontology)
The motive given in Claim 16 is equally applicable to the above claim.
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
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
/CHAU LE/Primary Examiner, Art Unit 2408
Prosecution Insights