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 .
This Office Action is in response to Remarks filed on 02/20/2026.
In the instant Amendment, claims 1-7, 9-15, and 17-19 have been amended; and claims 1, 9, and 17 are independent claims. Claims 1-20 have been examined and are pending.
Response to Arguments
Applicants’ arguments filed on 02/20/2026 with respect to claims 1-20 have been considered but are moot in view of the new ground(s) of rejection, which were necessitated by amendment.
In light of Applicant Amendment, in regards to the predicted and specific issue, the prior 112 (b) rejection of claims 1, 9 and 17 have been withdrawn, however this new amended language creates a different clarity issue (see 112 (b) rejection below).
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim1-20 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1, 9, and 17 are rejected under 35 U.S.C. §112(b) as indefinite because the claims fail to particularly point out and distinctly claim the subject matter regarded as the invention. The claims recite applying a trained machine-learning model to predict a specific potential vulnerability “based on correlation between the identified features and patterns in the received data,” but subsequently recite “identifying … patterns in the received data similar to the specific potential vulnerability.” Thus, the claims appear to require the “patterns in the received data” to be used as an input to the prediction before the patterns are identified. It is unclear whether the patterns are identified before applying the machine-learning model, after applying the machine-learning model, or both. It is also unclear whether the later-recited patterns are the same patterns used in the prediction step or different patterns identified after the prediction. Therefore, one of ordinary skill in the art would not be able to determine the scope of the claimed prediction and pattern-identification steps with reasonable certainty.
Claims 2-8, 10-16 and 18-20 are rejected under 35 U.S.C. § 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention, as they depend from claims 1, 9 and 17 and incorporate the same limitations for which claims 1, 9 and 17 have been rejected. The same reasoning and factual bases set forth for the rejection of claims 1, 8 and 15 are equally applicable to claims 2-8, 10-16 and 18-20
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Issue #1: ML training using historical vulnerability data / lack of training data, labels, and feature to vulnerability correlation logic
Claims 1–20 are rejected under 35 U.S.C. §112(a) because the Specification does not provide adequate written-description support for “training … a machine learning model using historical vulnerability data that correlates identified code features with known vulnerabilities.” Applicant’s Specification, e.g., paragraphs [0084]–[0085], states that machine learning may be used to train an artificial-intelligence system, that a machine-learning model may learn from training data, and that the model may use supervised learning, unsupervised learning, feature learning, association rules, neural networks, decision trees, support-vector machines, Bayesian networks, genetic algorithms, and other machine-learning techniques. Paragraphs [0081]–[0083] separately disclose identifying application-code features and scanning vulnerability information for mentions of the identified features. However, the Specification does not identify historical vulnerability data as the training data, does not identify the input features or labels contained in the training data, does not describe how an identified code feature is associated with a known vulnerability, and does not disclose the encoding, classification, correlation, or training logic used to cause the model to learn the claimed feature to vulnerability relationship. Merely listing known machine-learning algorithms and separately describing code features and vulnerability information does not reasonably convey possession of the claimed ML training process. It is not sufficient that one skilled in the art could theoretically develop a program to perform the claimed function; the Specification itself must explain how the claimed function is achieved to demonstrate that Applicant possessed the claimed invention. See MPEP §2161.01; Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 681–683 (Fed. Cir. 2015). Accordingly, the Specification describes the desired training result but does not reasonably convey possession of the full scope of the claimed ML training process.
Issue #2: ML prediction of a specific vulnerability / lack of pattern extraction, two input correlation, and decision logic
Claims 1–20 are rejected under 35 U.S.C. §112(a) because the Specification does not provide adequate written-description support for “applying … the trained machine learning model to predict a specific potential vulnerability based on correlation between the identified features and patterns in the received data” and “identifying … patterns in the received data similar to the specific potential vulnerability.” Applicant’s Specification, e.g., paragraphs [0076]–[0080], identifies potential vulnerability information received from vulnerability databases, social sourced information, product information, data center information, and deny-list repositories. Paragraphs [0081]–[0083] disclose identifying application-code features and scanning vulnerability information for mentions of those features. Paragraphs [0085]–[0087] state generally that machine-learning models may predict a vulnerability based on ingested data, perform regression analysis of data center information, and perform similarity analysis of data-center information and product histories. However, the Specification does not disclose how patterns are extracted or represented from the received data, how the identified application code features and received data patterns are provided to or processed by the ML model, how the two different inputs are correlated, what similarity metric or correlation rule is applied, what confidence threshold or decision criterion is used, or how the correlation produces the claimed specific potential vulnerability. Paragraph [0086] describes predicting a high probability of a zero-day vulnerability from unusual network traffic and deny-listed IP addresses, while paragraph [0087] describes identifying similar product histories and generating a shortlist of potential issues. Neither disclosure explains how a trained model correlates application code features with patterns in the received data to identify a specific vulnerability. Accordingly, the Specification describes the desired prediction result and separately identifies possible sources of information, but does not reasonably convey possession of the claimed ML correlation and prediction process across its full scope.
Issue #3: Static-code verification of the predicted vulnerability / lack of code-path and data-flow analysis architecture
Claims 1–20 are rejected under 35 U.S.C. §112(a) because the Specification does not provide adequate written-description support for “performing … a static code analysis of the set of components to verify presence of the specific potential vulnerability by analyzing code paths and data flow patterns.” Applicant’s Specification, e.g., paragraph [0082], states generally that code analysis may include static analysis that analyzes and evaluates application code without actually executing the application package. Paragraph [0087] states that, based on features identified during code analysis, the vulnerability manager may identify a possibility that a vulnerability impacts the application package. Paragraph [0105] similarly states that code analysis may identify a possibility that a predicted vulnerability impacts the application package. However, the Specification does not disclose using static analysis as a verification stage following the ML prediction, receiving the predicted specific vulnerability as an input to the static analysis, identifying or traversing code paths associated with the vulnerability, analyzing control-flow or data-flow relationships, tracing data between a source and a vulnerable operation, determining reachability, evaluating sanitization or validation operations, or applying a verification rule to determine that the predicted vulnerability is actually present. A general statement that static analysis evaluates code without execution does not describe the claimed code path and data flow verification architecture. Likewise, identifying a possibility that a vulnerability may affect an application package does not describe verifying the presence of that specific vulnerability. Accordingly, the Specification describes the desired verification result but does not reasonably convey possession of the claimed static verification process.
Issue #3: Issue: Pattern-identification / unclear ML input-output relationship
Claims 1–20 are rejected under 35 U.S.C. §112(a) because the Specification does not provide adequate written-description support for applying a trained machine-learning model to predict a specific potential vulnerability based on “patterns in the received data,” and then identifying “patterns in the received data similar to the specific potential vulnerability.” Applicant’s Specification generally discloses ingesting vulnerability data, using an ML model to predict a vulnerability, and performing similarity analysis of data-center information and product histories. However, the Specification does not disclose whether the patterns in the received data are identified before prediction, after prediction, or both; whether the same patterns are used in both steps; how such patterns are extracted from the received data; how the patterns are correlated with identified code features; or how the patterns are determined to be similar to the predicted vulnerability. Accordingly, the Specification describes the desired result of using received-data patterns in an ML prediction, but does not disclose the technical relationship, sequence, or logic by which those patterns are identified and used to produce the claimed specific vulnerability.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-4, 7, 9-12, 15, and 17-19, are rejected under 35 U.S.C. 103 as being unpatentable over Pradzynski et al. (U.S. Patent Application Publication No. 2022/0156380 A1, hereinafter “Pradzynski”), in view of Mehta (U.S. Patent Application Publication No. 2018/0157845 A1, hereinafter “Mehta”), Carback et al. (U.S. Patent Application Publication No. 2015/0363294 A1, hereinafter “Carback”), and Pontecorvi et al. (EP 3,575,953 A1, hereinafter “Pontecorvi”).
As per claims 1, 9 and 17, Pradzynski teaches a computer implemented method for managing zero-day vulnerabilities in an application package having a set of components, the method comprising (Pradzynski: , para [0013-014], [0025-0028], and Figures 1–5. “systems and methods of the present disclosure may improve security when launching and running container-based environments by enabling detection, prediction, and/or mitigation of vulnerabilities in container images before the images are used to launch the container.”):
receiving, by a computer system, data about potential vulnerabilities from a plurality of data sources, wherein the data sources include vulnerability databases, social media platforms, and data center deny-list repositories (Pradzynski: para [0017], [0024-0028], and [0030-0037]; Figures 1–3, teaches receiving vulnerability and threat information from the National Vulnerability Database, China’s National Vulnerability Database, ExploitDB, malware repositories, TOR, social media, Freenet, deep-web sites, paste sites, hacker discussions, public announcements, and media reports. Pradzynski further teaches storing and retrieving vulnerability information identifying known or predicted IP addresses used to exploit vulnerabilities and implementing mitigation actions that include blocking those IP addresses and blocking malicious-software signatures.);
identifying, by the computer system, patterns in the received data similar to a specific potential vulnerability (Pradzynski: para [0020-0022] [0028], and [0030-0033]); Figures 1–3, “The indicator extractor may obtain indicators from threat intelligence that can be used as decision criteria. Various techniques may be used to extract indicators from threat intelligence such as, for example, regular expression matching, pattern matching, entity extraction, natural language processing (NLP). Extracted indicators may include items such as for example, availability of an exploit for a particular vulnerability, the vulnerability being of interest to part of the hacking community, proof-of-concept code for a vulnerability being available, or other various pieces of metadata relating to either the vulnerability itself or aspects of intelligence relating to threats associated with vulnerability,…NLP techniques may include, for example, using Word2vec or other neural network techniques to find words from hacker discussions that are similar to software names”, “decision logic layer 110 may align the scan results 214 with the aggregated information from intelligence aggregator 112 to identify threats relevant to the vulnerabilities in a given container 224. Intelligence aggregator 112 may tag and sort intelligence data by vulnerability to facilitate alignment.”.);
applying, by the computer system, machine learning to predict a potential vulnerability based on patterns in the received data (Pradzynski: para [0020-0022], [0025-0028]; [0030-0038], “The machine learning predictive engine may either use threat intelligence and ground-truth data directly or leverage indicators as described above to create predictions as to which vulnerabilities will be exploited….”, “decision logic layer 110 may align the scan results 214 with the aggregated information from intelligence aggregator 112 to identify threats relevant to the vulnerabilities in a given container 224.”, Pradzynski teaches scanning and generating vulnerability-analysis results, aligning those results with external vulnerability intelligence, and selecting mitigation actions based on the combined information, such mitigation actions include blocking ports or IP addresses, disabling vulnerable software, substituting another container image, patching the container, reimaging the container, or preventing deployment. );
Pradzynski does not explicitly teach identifying, by the computer system, features of application code in the set of components, wherein the features comprise at least one of programming language constructs, library dependencies, and API calls; training, by the computer system, a machine learning model using historical vulnerability data that correlates identified code features with known vulnerabilities; predicting a specific potential vulnerability based on the identified features; performing, by the computer system, a static code analysis of the set of components to verify presence of the specific potential vulnerability by analyzing code paths and data flow patterns; querying, by the computer system, a private blockchain ledger to identify previously applied mitigations for similar vulnerabilities in other application packages; generating, by the computer system, a remediation recommendation based on the static code analysis results and the identified previously applied mitigations; submitting, by the computer system, the remediation recommendation to the private blockchain for evaluation by authorized participants; and automatically deploying, by the computer system, a consensus-approved mitigation solution using autonomous deployment agents that translate blockchain-stored solutions into executable patch formats.
However, in the related art, Mehta teaches identifying, by the computer system, features of application code in the set of components, wherein the features comprise at least one of programming language constructs, library dependencies, and API calls (Mehta: para [0013-0017], [0025-0029], and Figure 2, “For instance, the analysis system can be configured to perform static code analysis to identify traits including, for example, memory usage (e.g., dynamic or static sized buffers), signed operations, indexed memory reads and writes, application programming interface (API) usage, and code complexity.”, Because the claim requires “at least one of” the listed code-feature alternatives, Mehta’s express identification of API usage satisfies the claimed feature limitation.”);
training, by the computer system, a machine learning model using historical vulnerability data that correlates identified code features with known vulnerabilities (Mehta: para [0016-0019] and [0028-0033], and Figures 1-3, “the machine learning module 130 can be configured to generate and train a random forest that includes a plurality of decision trees. Each decision tree can be generated and trained to detect, in a computer program, the presence of one or more traits indicative of a specific type of vulnerability. For instance, the machine learning module 130 can apply a random forest to a computer program to determine whether the computer program includes vulnerabilities to exploits that include, for example, SQL injection, OS command injection, cross-site scripting, cross-site request forgery, open redirection, buffer overflow, and path traversal.”);
applying, by the computer system, the trained machine learning model to predict a specific vulnerability based the identified features (Mehta: para [0026-0033], and Figures 1-3, “For instance, the trait detection module 110 can identify an n number of traits t.sub.1, t.sub.2, . . . , t.sub.n that are associated with a known vulnerability A…the trait detection module 110 can determine that the other computer program includes the same vulnerability A and/or a similar vulnerability A′ if the same traits t.sub.1, t.sub.2, . . . , t.sub.n are present and/or absent from that computer program. Alternately and/or additionally, the trait detection module 110 can determine that the other computer program includes the same vulnerability A and/or a similar vulnerability A′ if greater than a threshold number of the traits t.sub.1, t.sub.2, . . . , t.sub.n are present and/or absent from that computer program.”, Mehta also uses weighted traits, thresholds, and vulnerability-specific decision trees to determine whether a program contains a specific type of vulnerability);
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to modify Pradzynski’s vulnerability prediction system to include Mehta’s static identification of application code traits and its trained vulnerability specific machine learning models. It will improve the accuracy of Pradzynski’s predictions, determine whether an externally reported vulnerability is actually applicable to the particular application package, and reduce false positive mitigation or deployment decisions (Mehta: para [0004]).
Pradzynski in view of Mehta does not explicitly teach performing, by the computer system, a static code analysis of the set of components to verify presence of the specific potential vulnerability by analyzing code paths and data flow patterns; querying, by the computer system, a private blockchain ledger to identify previously applied mitigations for similar vulnerabilities in other application packages; generating, by the computer system, a remediation recommendation based on the static code analysis results and the identified previously applied mitigations; submitting, by the computer system, the remediation recommendation to the private blockchain for evaluation by authorized participants; and automatically deploying, by the computer system, a consensus-approved mitigation solution using autonomous deployment agents that translate blockchain-stored solutions into executable patch formats.
However, in the related art, Carback teaches performing, by the computer system, a static code analysis of the set of components to verify presence of the predicted vulnerability by analyzing code paths and data flow patterns (Carback: para [0008-0009] and [0045-0049]; [0080-0089], Figure 3, teaches performing static code analysis using code paths and data flow patterns to identify and verify a flaw in a current software file and generates static software artifacts including “call graphs, control flow graphs, use-def chains, def-use chains, dominator trees, basic blocks, variables, constants, branch semantics, and protocols”, “Control Flow Graph (CFG) is a directed graph of the control flow between basic blocks inside of a function. Each node in a CFG represents a basic block and the edges between nodes are directional and shows potential paths in the flow”, “the developmental artifacts may specify where in the source code the flaw exists and where in a patch the repair exists. Also, the source code or LLVM IR can be analyzed and compared with the file having the flaw and the newer repaired version of the file for isolating the differences and discerning where the flaw and repair are located.”).
identify previously applied mitigations for similar vulnerabilities in other application packages (Carback: [0034-0039] and [0078-0085]; [0099], Figures 1, 4, and 5, “FIG. 1 is a flow chart illustrating example processing of input software files for the corpus….The software files obtained include not only the source code or binary files, but also can include….the associated build files, make files, libraries, documentation files, commit logs, revision histories, bugzilla entries, Common Vulnerabilities and Exposures (CVE) entries, and other unstructured text.”, [0082]–[0085] and [0105]–[0108], Carback analyzes a file having a flaw and a newer repaired version of that file to isolate the differences and determine where both the flaw and its repair are located. Commit logs and revision histories identify why patches were applied, and the identified flaw and repair patterns are stored in the corpus so that they may be searched and applied to other software files);
generating, by the computer system, a remediation recommendation based on the static code analysis results and the identified previously applied mitigations (Carback: [0006-0013],[0106-0108], and [0114-0117], Figures 1, 4, and 5, “when a software flaw is identified…the corresponding software repair pattern can be used to generate a repair specification. This repair specification, for example, can be used to synthesize an appropriate software repair in the form of a source or binary, also referred to as machine language, patch….performing automatic software maintenance, such as flaw identification and repair, on both binary code and source code allowing for broad automated software maintenance for legacy systems.”, Carback teaches once the static artifacts of the current program identify a flaw matching a flaw or repair pattern in the corpus, Carback provides candidate repair strategies corresponding to that flaw. The repair strategies may be ranked based on prior selections and presented as proposed repair solutions. Accordingly, Carback’s recommendation is based on the current program’s static control flow, data-flow, and other artifact analysis results and repair patterns, patches, repaired versions, and repair portions previously identified in other software files and projects).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to modify the combined Pradzynski Mehta system to use Carback’s deeper static control flow and data flow analysis after the ML prediction and to use Carback’s corpus of historical flaw and repair patterns to generate a remediation recommendation for the verified vulnerability, it would reduce remediation development time, provide a technically relevant starting point for the current repair, and improve consistency and reliability (Carback: para [0065]).
Pradzynski in view of Mehta and Carback does not explicitly teach querying, by the computer system, a private blockchain ledger; submitting, by the computer system, the remediation recommendation to the private blockchain for evaluation by authorized participants; and automatically deploying, by the computer system, a consensus-approved mitigation solution using autonomous deployment agents that translate blockchain-stored solutions into executable patch formats.
However, in the related art, Pontecorvi teaches querying, by the computer system, a private blockchain ledger; submitting, by the computer system, the remediation recommendation to the private blockchain for evaluation by authorized participants; and automatically deploying, by the computer system, a consensus-approved mitigation solution using autonomous deployment agents that translate blockchain-stored solutions into executable patch formats (Pontecorvi: para [0027], [0034-0048], and [0057-0068]; Figures 1–3, Pontecorvi teaches a blockchain-controlled patch-validation and deployment system, a blockchain ledger is a trusted source for changes, including patches, updates, recovery actions, and audits. A patch initiator sends a patch request to blockchain-network peers and to agents associated with network elements. The peers validate, agree upon, order, and write accepted patch requests to the blockchain. An agent communicates with the peers to determine which patch requests have been accepted and applies a patch only after the request has been globally verified by being written to the blockchain. Pontecorvi further teaches maintaining patch order and software dependencies, verifying patch integrity, applying the accepted patch to the network element, and reporting fingerprints or resulting hashes to the blockchain peers after the patch is applied).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to store Carback’s prior flaw and repair records, repair patterns, and generated remediation recommendations in Pontecorvi’s blockchain ledger, it will provide an immutable and auditable record of previous mitigations and their provenance, protect the historical repair information from unauthorized alteration, and ensure that a generated patch is approved by authorized participants before deployment. Pontecorvi expressly identifies the risks of malicious or unsynchronized patch initiators and teaches blockchain verification as a solution to those risks (Pontecorvi: para [47]).
As per claims 2, 10, and 18, Pradzynski in view of Mehta and Carback and Pontecorvi teaches the independent claim 1. Pradzynski teaches wherein the data about the specific potential vulnerabilities comprises crowd-sourced information, vulnerability information, product information, and data center information (Pradzynski: para [0017], [0024-0028], and [0030-0037]; Figures 1–3, teaches receiving vulnerability and threat information from the National Vulnerability Database, China’s National Vulnerability Database, ExploitDB, malware repositories, TOR, social media, Freenet, deep-web sites, paste sites, hacker discussions, public announcements, and media reports. Pradzynski further teaches storing and retrieving vulnerability information identifying known or predicted IP addresses used to exploit vulnerabilities and implementing mitigation actions that include blocking those IP addresses and blocking malicious-software signatures.).
As per claims 3 and 11, Pradzynski in view of Mehta and Carback and Pontecorvi teaches the independent claim 2. Mehta teaches receiving, by the computer system, application code for the set of components; identifying, by the computer system, features of the application code based on the code analysis of the set of components (Mehta: para [0013-0017], [0025-0029], and Figure 2, “For instance, the analysis system can be configured to perform static code analysis to identify traits including, for example, memory usage (e.g., dynamic or static sized buffers), signed operations, indexed memory reads and writes, application programming interface (API) usage, and code complexity.”, Because the claim requires “at least one of” the listed code-feature alternatives, Mehta’s express identification of API usage satisfies the claimed feature limitation.”); and
scanning, by the computer system, the vulnerability information for mentions of the features that were identified (Mehta: para [0016-0019] and [0028-0033], and Figures 1-3, “the machine learning module 130 can be configured to generate and train a random forest that includes a plurality of decision trees. Each decision tree can be generated and trained to detect, in a computer program, the presence of one or more traits indicative of a specific type of vulnerability. For instance, the machine learning module 130 can apply a random forest to a computer program to determine whether the computer program includes vulnerabilities to exploits that include, for example, SQL injection, OS command injection, cross-site scripting, cross-site request forgery, open redirection, buffer overflow, and path traversal.”)
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to modify Pradzynski’s vulnerability prediction system to include Mehta’s static identification of application code traits and its trained vulnerability specific machine learning models. It will improve the accuracy of Pradzynski’s predictions, determine whether an externally reported vulnerability is actually applicable to the particular application package, and reduce false positive mitigation or deployment decisions (Mehta: para [0004]).
As per claims 4 and 12, Pradzynski in view of Mehta and Carback and Pontecorvi teaches the independent claim 2. Pradzynski teaches wherein receiving data, by the computer system, about potential vulnerabilities further comprises: scanning, by the computer system, data center information including running products, product history, and a deny-list repository information and product information (Pradzynski: para [0013-014], [0025-0028], and Figures 1–5. “systems and methods of the present disclosure may improve security when launching and running container-based environments by enabling detection, prediction, and/or mitigation of vulnerabilities in container images before the images are used to launch the container.”); and mapping, by the computer system, product version information to internet protocol (IP) addresses in the deny-list repository information (Pradzynski: para [0017], [0024-0028], and [0030-0037]; Figures 1–3, teaches receiving vulnerability and threat information from the National Vulnerability Database, China’s National Vulnerability Database, ExploitDB, malware repositories, TOR, social media, Freenet, deep-web sites, paste sites, hacker discussions, public announcements, and media reports. Pradzynski further teaches storing and retrieving vulnerability information identifying known or predicted IP addresses used to exploit vulnerabilities and implementing mitigation actions that include blocking those IP addresses and blocking malicious-software signatures.).
As per claims 7, 15, and 19, Pradzynski in view of Mehta and Carback and Pontecorvi teaches the independent claim 1. Pontecorvi teaches submitting, by the computer system, the remediation recommendation to the private blockchain for consumption by participants in the private blockchain; identifying, by the computer system, a set of mitigations submitted to the private blockchain by the participants (Pontecorvi: para[34-38], [63-68], “As patches rely on software dependencies, it is important that the order agreed by the blockchain network peers 303 is maintained. Once it is verified that the patch request is the next patch to be applied, the agent 304 determines if the dependencies or prerequisites of that patch are satisfied by the latest status of the network element, as computed above. If so, the patch request is then aborted if it is not the next one in order within the blockchain sequence, or it may be aborted if it was not requested and an alarm is raised and further action is required by SOAR. When the protocol does not abort and the patch is applied, the agent 304 then computes the patch report, containing the fingerprints of the resulting hashes after applying validated changes that must be sent to the blockchain network peers 303 for the patch process to be finally validated and completed. If this is not completed, an alarm is raised.”, para [39-41], “The agent may further gather and provide analytics and/or forensics data by the blockchain network to the SOAR enabled management system to enable countermeasures (e.g., block or reroute traffic) and remediation (e.g., re-boot or re-image).”);
in response to a consensus among the participants, dispatching, by the computer system, a mitigation that is consensus-approved for deployment to the application package (Pontecorvi: para[42-43], [63-68], “The agent may then be able to verify each patch request and apply it to the network device, if the request has been globally verified (i.e., written within the blockchain network) without requiring any external trusted third party and in case of a mismatch, the agent may provide a status report on the network element under supervision, in order to support the analytics task of an overlooking SOAR system. The agent may also support rollback actions, for example, re-imaging or re-configuring the network element, making it aligned to the blockchain network and be configured to receive new patches.”, “it is important that the order agreed by the blockchain network peers 303 is maintained. Once it is verified that the patch request is the next patch to be applied, the agent 304 determines if the dependencies or prerequisites of that patch are satisfied by the latest status of the network element, as computed above.”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to store Carback’s prior flaw and repair records, repair patterns, and generated remediation recommendations in Pontecorvi’s blockchain ledger, it will provide an immutable and auditable record of previous mitigations and their provenance, protect the historical repair information from unauthorized alteration, and ensure that a generated patch is approved by authorized participants before deployment. Pontecorvi expressly identifies the risks of malicious or unsynchronized patch initiators and teaches blockchain verification as a solution to those risks (Pontecorvi: para [47]).
Claims 5-6 and 13-14 are rejected under 35 U.S.C. 103 as being unpatentable over Pradzynski et al. (U.S. Patent Application Publication No. 2022/0156380 A1, hereinafter “Pradzynski”), in view of Mehta (U.S. Patent Application Publication No. 2018/0157845 A1, hereinafter “Mehta”), Carback et al. (U.S. Patent Application Publication No. 2015/0363294 A1, hereinafter “Carback”), Pontecorvi et al. (EP 3,575,953 A1, hereinafter “Pontecorvi”), and Jiang (U.S. 20220239687 A1; Hereinafter “Jiang”).
As per claims 5 and 13, Pradzynski in view of Mehta and Carback and Pontecorvi teaches the independent claim 1.
Pradzynski in view of Mehta and Carback and Pontecorvi does not explicitly teach wherein determining, by the computer system, a resolution to the vulnerability further comprises: matching, by the computer system, release notes of the product information with the vulnerability information in a vulnerability database; and generating, by the computer system, a shortlist of potential issues based on similar product history, and similar past issues between the application package and other packages
However, in an analogous art, Jiang teaches matching, by the computer system, release notes of the product information with the vulnerability information in a vulnerability database (Jiang: fig. 2, para [0055-0077], “As shown in S215, the analysis and defense unit 210 may analyze and establish a correspondence between an asset identifier and a vulnerability identifier based on <asset model, asset version> and the correspondence between an asset and a vulnerability <asset model, asset version, vulnerability identifier> in the asset information, for example, <asset identifier, asset model, asset version, vulnerability identifier>, or may only perform matching and establish a correspondence: <asset identifier, vulnerability identifier>.”); and
generating, by the computer system, a shortlist of potential issues based on similar product history, and similar past issues between the application package and other packages (Jiang: para [0066], “the ACL access control policy may be used to issue an instruction list to a router interface, or the like to instruct a router to perform an acceptance or rejection operation on a packet. In an emergency protection state, for example, an ACL instruction list may be used to restrict the router from accepting only a trusted packet, so that the router is not threatened by a malicious packet. …For example, a feature character string used to represent an unauthorized domain name system (DNS) may be preset, so as to filter out accesses, attacks, and the like of potential unauthorized users to the system. The IPS signature-based protection policy is mainly used to establish and maintain a feature behavior classification filter based on collected historical vulnerability information and attack features, and the like.”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, for the modified Pradzynski to have been update in the manner describe in Jiang, it will improve timeliness of performing zero-day vulnerability and reduce possibility of attacks (Jiang: para [05]).
As per claims 6 and 14, Pradzynski in view of Mehta and Carback, Pontecorvi and Jiang teaches the dependent claim 5. Carback teaches identifying, by the computer system, a probable issue based on the code analysis and the identified previously applied mitigations to the other packages; and generating, by the computer system, the recommendation that addresses the probable issue (Carback: [0006-0013],[0106-0108], and [0114-0117], Figures 1, 4, and 5, “when a software flaw is identified…the corresponding software repair pattern can be used to generate a repair specification. This repair specification, for example, can be used to synthesize an appropriate software repair in the form of a source or binary, also referred to as machine language, patch….performing automatic software maintenance, such as flaw identification and repair, on both binary code and source code allowing for broad automated software maintenance for legacy systems.”, Carback teaches once the static artifacts of the current program identify a flaw matching a flaw or repair pattern in the corpus, Carback provides candidate repair strategies corresponding to that flaw. The repair strategies may be ranked based on prior selections and presented as proposed repair solutions. Accordingly, Carback’s recommendation is based on the current program’s static control flow, data-flow, and other artifact analysis results and repair patterns, patches, repaired versions, and repair portions previously identified in other software files and projects).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to modify the combined Pradzynski Mehta system to use Carback’s deeper static control flow and data flow analysis after the ML prediction and to use Carback’s corpus of historical flaw and repair patterns to generate a remediation recommendation for the verified vulnerability, it would reduce remediation development time, provide a technically relevant starting point for the current repair, and improve consistency and reliability (Carback: para [0065]).
Claims 8, 16, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Pradzynski et al. (U.S. Patent Application Publication No. 2022/0156380 A1, hereinafter “Pradzynski”), in view of Mehta (U.S. Patent Application Publication No. 2018/0157845 A1, hereinafter “Mehta”), Carback et al. (U.S. Patent Application Publication No. 2015/0363294 A1, hereinafter “Carback”), Pontecorvi et al. (EP 3,575,953 A1, hereinafter “Pontecorvi”), and Wright et al. (U.S. Pub. 20220164435 A1; Hereinafter “Wright”).
As per claims 8, 16, and 20, Pradzynski in view of Mehta and Carback and Pontecorvi teaches the dependent claim 7. Wright teaches wherein dispatching the mitigation further comprises: consuming blockchain data by autonomous operational bots, looking for the mitigation that has been consensus-approved (Wright: para [63-76], “the computing resource is arranged to generate a cryptographic hash of code relating to the loop. Preferably, the cryptographic hash is stored within a transaction on the blockchain. Additionally, or alternatively, the computing resource is arranged to monitor the state of the blockchain for a transaction comprising a cryptographic hash of code relating to the loop.”); and
translating the dispatched mitigation by the autonomous operational bots according to an automated protocol for automatic dispatch and deployment (Wright: para [63-76], “Preferably, for each iteration of the loop: a condition is evaluated and at least one action is performed based on the outcome of the evaluation; the at least one action comprising: causing at least one transaction to be written to the blockchain; and/or causing an off-blockchain action to be performed. The condition may relate to data received, detected, or generated by the computing resource; or the state of the blockchain.” See also para [109-137]).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to combine the blockchain based remediation approval with the autonomous oof-chain agent execution taught by wright, it will automate dispatch and deployment of approved mitigation (wright: para [10]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LYDIA L NOEL whose telephone number is (571)272-1628. The examiner can normally be reached Monday - Friday 9:00 - 5:00.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Alexander Lagor can be reached on (571)-270-5143. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/L.L.N./Examiner, Art Unit 2437
/MENG LI/Primary Examiner, Art Unit 2437
Prosecution Insights