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 .
Applicant’s arguments, see page(s) 1, filed 4/13/2026, with respect to the objection(s) to the drawings have been fully considered and are persuasive. The associated objection(s) to the drawings has/have been withdrawn.
Applicant’s arguments, see page(s) 2, filed 4/13/2026, with respect to the objection(s) to claim(s) 7, 8, 14, 15, 19, and 20 have been fully considered and are persuasive. The associated objection(s) to the listed claim(s) has/have been withdrawn.
Applicant's arguments, see page(s) 2-4, filed 4/13/2026, with respect to the rejection of claims 1-20 under 35 USC 112(a) have been fully considered but they are not persuasive.
Regarding the argument:
“The specification provides sufficient disclosure of the classification analysis. Specifically, Applicant’s ¶ [0098] describes that “the vulnerability evaluation service runs a classification analysis in which vulnerabilities are classified using neural networking techniques according to the likelihood that a vulnerability will fall into the following classifications: (1) a known vulnerability stored to the database, (2) a potential vulnerability, or (3) not a vulnerability.””
Examiner respectfully disagrees. As explained in the previous office action, a listing the possible classifications produced by the claimed analysis represents a mere recitation of function rather than a disclosure of how to perform the function. A sufficient written description requires disclosing by what measure or criteria each vulnerability is classified into each of the listed alternatives. This portion of the rejection is maintained.
“Applicant’s ¶ [00100] further describes that “the categorical analysis can be conducted by a support vector machine using logistic regression to categorize vulnerabilities according to the probability a vulnerability is related to one of the following categories.”
“Applicant’s ¶ [0062]–[0086] provides extensive disclosure of neural network architectures including feedforward networks, convolutional neural networks, support vector machines, and training methodologies. …”
Examiner respectfully disagrees. The paragraphs referenced by Applicant are mostly directed to high-level descriptions of well-known capabilities of generic machine learning (ML) models and neural networks (NN). This portion of the disclosure does not provide adequate description of how any of these broadly defined models perform the claimed function of the claims in question. This portion of the rejection is maintained.
“… Additionally, Figure 6 and the accompanying discussion beginning at Applicant’s ¶ [0085] describe a detailed machine learning workflow for model development and deployment …. Specifically, Applicant’s ¶ [0085] describes that “training test data such as a target variable value is inserted into an iterative training and testing loop” and that “features in the training test data are used to train the model based on weights and iterative calculations in which the target variable may be incorrectly predicted in an early iteration” with “[s]ubsequent iterations of the model training” conducted “with updated weights in the calculations.” …”
Examiner respectfully disagrees. The workflow disclosed in the drawings and specification serve as a high-level description of well-known steps in configuring a generic NN, but lack any detail which would inform one of skill in the art as to how a NN is specifically configured in order to perform the claimed function. For example, Applicant cites ¶ [0085] of the specification to argue that “training test data such as a target variable” is used to train the NN, but there is no disclosure of how the variable is chosen or even the variable’s data type. The same paragraph teaches that “features in the training test data are used to train the model”, but fails to disclose even what “features” of the training data are used. This portion of the rejection is maintained.
Regarding the argument:
“Applicant’s ¶ [0091] describes mapping vulnerabilities to firewall attack signatures …
“Applicant’s ¶ [00106] explains that “the vulnerability evaluation service will self-execute a rule that enables the attack signatures that protect against the set of vulnerabilities by either removing or patching.”
Examiner respectfully notes that the provides portions of the specification are recitations of function, and do not provide adequate description of how the claimed function is performed. A sufficient written description of the claimed function of “removing or patching” vulnerabilities would disclose from where the claimed patches are being obtained, an algorithm used to remove a vulnerability, or, at a minimum, a description of what “removing” even entails in the context of vulnerability mitigation. For example, that the vulnerable service/program disabled, or uninstalled. Alternatively, whether and how the firewall is enabled to modify the source code of the vulnerable element. This portion of the rejection is maintained.
Applicant's arguments, see page(s) 4-5, filed 4/13/2026, with respect to the rejection of claims 1-20 under 35 USC 112(b) have been fully considered.
Regarding the argument:
“The term “attack signatures” should be interpreted consistent with its usage at Applicant’s ¶ [0091], which defines attack signatures as “regular expressions, formatting, identifiers, structures, rules, policies, or other means with which a firewall can detect the identified set of vulnerabilities.””
Examiner respectfully disagrees. As stated in the previous office action, the claim is indefinite due to the inconsistency with which the term is used in the specification. While ¶ 0091 provides an example of a use of the term as understood in the art, this definition is incompatible with the term’s use in the claims (“… execute a rule that enables the firewall attack signatures to remove the vulnerability or patch the vulnerability …”). The claims are explicit in reciting the “attack signatures” performing removal or patching of a vulnerability. This is mutually exclusive with the use of the term in ¶ 0091 of the specification, but consistent with its use in ¶ 0106. It is this ambiguity that must be addressed to overcome the rejection. This rejection is maintained.
Regarding claims 5, 8, 9, 17, and 20:
These rejections are withdrawn.
Applicant’s arguments, see page(s) 5-7, filed 4/13/2026, with respect to the rejection of claim(s) 8, 12, 15, and 20 under 35 USC 112(d) have been fully considered and are persuasive. The associated rejection(s) to the listed claim(s) has/have been withdrawn.
Applicant’s arguments, see page(s) 7-16, filed 4/13/2026, with respect to the rejection of claim(s) 1-20 under 35 USC 101 have been fully considered and are persuasive. The associated rejection(s) to the listed claim(s) has/have been withdrawn.
Applicant’s arguments, see page(s) 16-17, filed 4/13/2026, with respect to the rejection of claim(s) 1, 2, 9, and 10 under 35 USC 102(a)(2) have been fully considered and are persuasive. The associated rejection(s) to the listed claim(s) has/have been withdrawn; however, the details of Applicant’s arguments may be relevant to prior art which is mapped to the claims in the future and will be addressed.
Regarding the argument:
“Cruz does not teach “execut[ing] a rule that enables attack signatures to remove the vulnerability or patch the vulnerability” as claimed. Cruz’s VMS addresses vulnerabilities by obtaining software patches through a network interface, but does not disclose executing a rule that enables attack signatures to perform remediation. See Cruz ¶¶ [0003], [0076]. …”
Examiner respectfully disagrees. In conjunction with the pending rejection of this claim, linked to this limitation, under 35 USC 112(b), this limitation is being given its broadest reasonable interpretation based on the context of the specification and the state of the art. The prior art performs the function of obtaining a patch for use in the removing the vulnerability. This is consistent with the interpretation of claim, in which a detected vulnerability is addressed via a patch. While the rejection writ large has been withdrawn, this mapping is maintained.
Applicant’s arguments, see page(s) 16-17, filed 4/13/2026, with respect to the rejection of claim(s) 3-8 and 11-20 under 35 USC 103 have been fully considered.
Regarding the arguments directed to the prior art of CRUZ:
These arguments repeat those provided for rejections under 35 USC 102, and have previously been addressed.
Regarding the arguments directed to the prior art of SRIVASTAVA:
Examiner respectfully disagrees. The prior art performs an equivocal function that claimed. Examiner notes that of the three recited classifications, only two are given any further function by the invention. As described in ¶¶ 0099 and 0100, “known” and “potential” vulnerabilities are further analyzed to categorize the vulnerabilities. As the specification is silent regarding any action taken for the classification of “not a vulnerability,” it is presumed this category is ignored. The prior art of SRIVASTAVA similarly groups detected vulnerabilities into two groups on which is given further function, and third implicit group which is ignored (all other elements which are not false positives or true positives; i.e. true negatives). While the claim has been cancelled, its subject matter has been incorporated into a parent claim. This mapping is maintained.
Regarding the arguments directed to the prior art of CAMERON:
“… However, Cameron does not teach the specific training approach recited in claim 5: … training at least one neural network by adjusting neural network parameters to reduce the error rate. The claimed training approach is specifically tied to the vulnerability classification scheme and historical verification data structure disclosed in the specification, which Cameron does not teach or suggest.”
Examiner respectfully disagrees and notes that Applicant’s arguments amount to an assertion that CAMERON does not teach the limitations of the claims, but does not provide any examples or evidence explaining why the mapping is inappropriate beyond repeating the subject matter of the claims. Each of the claimed limitations is individually mapped to an aspect of the prior art in the previous office action. Examiner further notes that contrary to the “specific training approach” argued by the Applicant, the actual wording of the claim is limited to a single limitation which recites, “… train the at least one neural network by adjusting one or more neural network parameters to reduce the error rate.” This is mapped appropriately to CAMERON, which explicitly teaches, “... the machine learning models can be adjusted or modified ... by, for example, adjusting or modifying model parameters ... so as to minimize some error measure …”. This mapping is maintained.
Regarding the arguments directed to the prior art of ALKELAIBI:
Examiner respectfully disagrees. Applicant’s arguments seem to indicate that the instant application disclosed a distinct or unique use of a Convolutional Neural Network (CNN) which is unknown in the art. Examiner notes that the specification indicates that other types of machine learning (ML) models may perform the same function, and other that generalized examples of how the data of the invention is input into the recited, provides no disclosure which would indicate that the CNN used is distinct over CNNs known in the art. The prior art of ALKELAIBI is provided to illustrate that it is known in the art to use a CNN in the classification and detection of vulnerabilities. While the claim has been cancelled, its subject matter has been incorporated into a parent claim. This mapping is maintained.
Examiner notes that due to the significant change in the scope of the claims, mappings declared as maintained in these responses may be applied to new grounds of rejection as necessary.
Examiner further notes that additional arguments are directed to amended subject matter and do not require response here.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL. — The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
Claims 1, 5, 8-10, 14-17, 19, and 20 are rejected under 35 U.S.C. 112(a) 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, at the time the application was filed, had possession of the claimed invention.
Regarding claims 1 and 9:
Claim 1 recites, “… perform a classification analysis using at least one neural network to determine the vulnerability’s classification …”. Claim 9 recites similar language. This limitation recites a function that is not supported by sufficient written description in the specification. The specification names broad categories such as rules based processes, “statistical analyses,” and generic ML families, but it does not disclose any concrete algorithm, feature encoding, labeled training data, or representative model architecture that shows possession of the full breadth of that limitation. For example, the “Identifying Vulnerabilities and Notifying Remediation Personnel” section states that the vulnerability evaluation service runs a classification analysis using neural networking techniques and that a categorical analysis can be conducted by a support vector machine using logistic regression, yet it provides no steps of the analysis, no description of how systems/software/configuration data are converted into input vectors, and no decision criteria for the claimed classes “known,” “potential,” and “not a vulnerability.” This is merely a recitation of function rather than a disclosure of how to perform it.
Regarding claims 1, 9, and 16:
Claim 1 recites, “… execute a rule that enables the firewall attack signatures to remove the vulnerability or patch the vulnerability.” Claims 9 and 16 recite similar language. This limitation is not given sufficient written description in the specification. The specification discusses mapping vulnerabilities to firewall attack signatures and gives high level examples such as blocking SQL injection or blacklisting an attacker, but it does not disclose any concrete rule format, execution mechanism, protocol, or algorithm that would enable a POSITA to perform the claimed rule execution across the full scope claimed. Nor does the specification describe how an “attack signature” could itself remove or patch a vulnerability in the first place.
Regarding claim 5:
Claim 5 recites, “…generate an error rate by comparing the output data of the vulnerability classification process to the classification analysis to the historical data …”. This limitation lacks sufficient written description in the original disclosure, and thus constitutes new matter. The specification discloses a comparison between “vulnerability classification data” and “historical data” in ¶ 0007; however, there is no description in the specification regarding a three-way comparison between the “output data of the vulnerability classification process”, “classification analysis”. And “historical data.” This rejection can be overcome by amending the claim such that it recites only subject which is supported by the original disclosure.
Regarding claims 9 and 16:
Claim 9 recites, “… iteratively train, using the training data, a neural network to generate simulated vulnerability data …”. Claim 16 recites similar language. This limitation lacks sufficient written description in the original disclosure, and thus constitutes new matter. The specification discusses iterative training at ¶ 0085; however, the specification is silent regarding generating “simulated vulnerability data.” Indeed, there is no teaching in the original disclosure which can be interpreted as referring to simulated vulnerability data at all
Claim 9 additionally recites, “… insert the training data into an iterative training and testing loop to predict a target vulnerability …”. Claim 16 recites similar language. This limitation lacks sufficient written description in the original disclosure, and thus constitutes new matter. The specification predicting a target variable at ¶ 0085; however, there is no indication that this “target variable” is equivocal to the newly claimed “target vulnerability.”
Claim 9 additionally recites, “… repeatedly determine, during each iteration of the training and testing loop, the target vulnerability …”. Claim 16 recites similar language. This limitation lacks sufficient written description in the original disclosure, and thus constitutes new matter. The specification discussed a target variable at ¶ 0085; however, in addition to the new matter of the “target vulnerability” discussed above, there is also no teaching in the specification regarding “repeatedly determining” a target value, vulnerability or otherwise. The specification describes only adjusting weights based on incorrect predictions of a target variable.
This rejection can be overcome by amending the claims such that they recite only subject which is supported by the original disclosure.
Regarding claims 10, 14, 17, and 19:
They are dependent on one or more rejected claims, and thus inherit those rejections. This rejection could be overcome by overcoming the rejection(s) to any claims upon which these claims depend, or by amending the claims such that they are no longer dependent on any rejected claim.
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.
Claims 1, 5, 8-10, 14-17, 19, and 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.
Regarding claims 1 and 9:
Claim 1 recites, “execute a rule that enables the firewall attack signatures to remove the vulnerability or patch the vulnerability.” Claim 9 recites similar language. Where applicant acts as his or her own lexicographer to specifically define a term of a claim contrary to its ordinary meaning, the written description must clearly redefine the claim term and set forth the uncommon definition so as to put one reasonably skilled in the art on notice that the applicant intended to so redefine that claim term. Process Control Corp. v. HydReclaim Corp., 190 F.3d 1350, 1357, 52 USPQ2d 1029, 1033 (Fed. Cir. 1999). The term “attack signatures” is used by the claim to refer to a remediation action of some kind which removes a software vulnerability, while the accepted meaning is: a recognizable pattern or trace used to identify a specific, known cyber attack. The term is indefinite because the specification is inconsistent in the use of the term (used as recognized in the art in paragraph 0091, inter alia, and sharing the claim language at paragraph 0106), and does not explicitly redefine the term.
Regarding claim 5:
Claim 5 recites, “(c) generate historical data using the vulnerability database record;” and “(d) generate an error rate by comparing the output data of the vulnerability classification process to the classification analysis to the historical data;”. The claim is incomplete for omitting essential steps, such omission amounting to a gap between the steps. See MPEP § 2172.01. Specifically, the claim lacks a step describing how the “historical data” differs from the “vulnerability classification data.” Presumably, both this claim and claim 1, on which this claim depends, capture the same systems data, software data, and software configuration data (hereafter “system data”). Where both the vulnerability classification data and the historical data are created from the same system data, it is unclear how any useful “error rate” can be calculated. Based on context in the specification, the missing step seems to be obtaining user input which labels the historical data vis a vie whether vulnerabilities exist in the data.
Additionally, claim 5 recites, “… comparing the output data of the vulnerability classification process to the classification analysis to the historical data …”. The claim is further indefinite because the metes and bounds of the claim are made unclear by this limitation. It is first unclear how the “output data of the vulnerability classification process” can be compared to the “classification analysis.” It is unclear what comparison can be made based on the plain wording of the claim, and even if one were to assume it is the output of the “classification analysis” which is to be compared, it seems clear from the parent claim that “vulnerability classification process” and “classification analysis” refer to the same function, and would therefore refer to the same output. It is further unclear how each of these can be compared to the “historical data.”
Regarding claims 8, 15, and 20:
Claim 8 recites, “…expertise corresponding to the vulnerability’s category.” Claims 15 and 20 recite similar language. This limitation is indefinite because “the vulnerability’s category” lacks antecedent basis in the claims. It is unclear from where this category is obtained. This rejection can be overcome by amending the claims such that they provide antecedence to the term.
The claim(s) is/are rejected as being incomplete for omitting essential steps, such omission amounting to a gap between the steps. See MPEP § 2172.01. Specifically, the claims omit the steps of obtaining agent information and algorithmically determining the most appropriate agent to contact based on the agent and vulnerability information. This rejection can be overcome by amending the claims such that they either include all essential intervening steps or removing recitations in the claim directed to particular agent expertise.
Regarding claims 9 and 16:
Claim 9 recites, “… iv. deploy the trained neural network …”. Claim 16 recites similar language. This limitation lacks antecedence for “the trained neural network.” Examiner notes that this is likely a clerical error and the previous limitation should recite “a trained neural network” (i.e. “… thereby creating a trained neural network …”).
Regarding claims 10, 14, and 19:
They are dependent on one or more rejected claims, and thus inherit those rejections. This rejection could be overcome by overcoming the rejection(s) to any claims upon which these claims depend, or by amending the claims such that they are no longer dependent on any rejected claim.
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS. — Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claim(s) 10 and 17 is/are rejected under 35 U.S.C. 112(d) as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends.
Regarding claim 10:
The claim(s) fails to further limit the depended-on claim Specifically, claim 10 recites, “… (b) the at least one neural network determines a probability that the vulnerability is one of (i) the known vulnerability stored to the database, (ii) the potential vulnerability, or (iii) not the vulnerability.” This limitation does not further limit parent claim 9, which recite(s), “… (c) classify the vulnerability as one of: (i) a known vulnerability stored to the database, (ii) a potential vulnerability, and (iii) not a vulnerability …” Paragraph 0096 of the specification recites, “… The vulnerability evaluation service output can additionally include information that classifies the vulnerability, such as the probability that the vulnerability is (1) a known vulnerability stored to the database, (2) a potential vulnerability, or (3) not a vulnerability.” The specification is explicit that the “classification” and “probability” are equivocal. Claim 10 therefore recites identical subject matter to its parent claim.
Regarding claim(s) 17:
The claim(s) fails to further limit the depended-on claim Specifically, claim 17 recites, “… (a) the remediation solution comprises remediation software code; and (b) the step of implementing the remediation solution comprises transmitting the remediation software code to the computing device or software application associated with the vulnerability.” This limitation does not further limit parent claim 16, which recite(s), “… (h) implement the remediation solution … associated with the vulnerability by deploying remediation software code to the computing device or software application.” Each claim identifies the “remediation solution” as “remediation software code.” Further, “transmitting” the code in claim 17 is not functionally distinct over “deploying” the code in claim 16, as one of ordinary skill in the art would understand that to deploy code from one machine to another would require transmitting the code.
Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements.
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 1 is rejected under 35 U.S.C. 103 as being unpatentable over ZAW (Doc ID US 20170034199 A1), and further in view of WEIZMAN et al (Doc ID US 20190306178 A1) and ALKELAIBI et al (Doc ID US 20240396921 A1).
Regarding claim 1:
ZAW teaches:
A system for vulnerability remediation comprising a plurality of devices, each device having an address and at least one port ([0016] "The process 100 commences by cataloging (at 110) the systems, software, and software configurations of the particular network. … The crawling may involve scanning the address range of the particular network to identify the accessible systems."),
a first computing device that includes at least one processor and a memory device that stores executable code that, when executed, causes the at least one processor to ([0049] "… Computer system 500 includes a bus 505, a processor 510, a system memory 515, a read-only memory 520, a permanent storage device 525 ..."):
(a) scan a range of ports for each of the plurality of devices using the respective address and port by passing a script to the port of each device and capturing a response, wherein the response comprises a software configuration data associated with each device ([0016] "The scanning may further involve scanning each port at each address .... The crawling may also involve ... submitting requests using different communication protocols to each address. Once a machine is found, the crawling then involves identifying the software running on the machine as well as the configuration for any identified software.");
(b) detect a vulnerability by comparing the software configuration data for each device against a database of known vulnerabilities, wherein the vulnerability comprises a weakness in software, hardware, or firmware that can be exploited to gain unauthorized access ([0017] "The process then compares (at 120) the identified set of software and software configurations (i.e., version numbers) to a database of known vulnerabilities.");
(e) map the vulnerability to firewall attack signatures to update a firewall for a particular network, wherein the firewall attack signatures define regular expressions, formatting, identifiers, structures, rules, policies, or other means with which the firewall can detect the vulnerability ([0019] "The process maps (at 140) the set of vulnerabilities to firewall attack signatures. The attack signatures define regular expressions, formatting, identifiers, structures, rules, policies, or other means with which a firewall can detect the identified set of vulnerabilities."); and
(f) execute a rule that enables the firewall attack signatures to remove the vulnerability or patch the vulnerability by enabling the firewall to detect and remediate the vulnerability ([0038] "… The self-configuring firewall automatically adjusts its configuration to enable the attack signature and thereby block any traffic that harbors an attack attempting to exploit the vulnerability.").
WEIZMAN teaches the following limitation(s) not taught by ZAW:
(c) perform a classification analysis using at least one neural network to determine the vulnerability’s classification as one of: (i) a known vulnerability stored to the database, (ii) a potential vulnerability, and (iii) not a vulnerability, by using the software configuration data as well as a vulnerability data and a attack signature data loaded from an end user database (Paragraphs [0088]-[0094] and Fig. 7C teach classifying a vulnerability as known (steps 756 and 760), potential (steps 772 and 776), or not a vulnerability (step 772, where the process moves to the next vulnerability when a vulnerability does not meet any of the criteria as a known or potential vulnerability).),
(d) notify a remediation agent of the vulnerability, wherein the remediation agent monitors the vulnerability ([0092] "Control continues at 792, where the addition of the new vulnerability scanner cluster is reported to the operator. … this allows the operator to vet the new vulnerability scanner cluster and identify false positives.");
Conducting a port scan of multiple devices to obtain software configuration data, identifying vulnerabilities based on the software data, mapping the vulnerabilities to firewall attack signatures, and enabling the firewall to mitigate the vulnerabilities is/are known technique(s) in the art, as demonstrated by ZAW. Further, using machine learning (ML) to classify vulnerabilities into multiple groups, and notifying an agent of a discovered vulnerability is/are known technique(s) in the art, as demonstrated by WEIZMAN. It would have been obvious to a person having ordinary skill in the art (PHOSITA) before the effective filing date of the claimed invention to modify the vulnerability detection and mitigation of ZAW with the classification and notification of WEIZMAN with the motivation to separate the vulnerabilities into groups so that different actions may be taken depending on the group a vulnerability belongs to, including assigning an agent to the vulnerability.
ALKELAIBI teaches the following limitations not taught by the combination of ZAW and WEIZMAN:
wherein the at least one neural network comprises an architecture selected from a support vector machine network or a convolutional neural network ([0075] "… classifier 410, which classifies the vulnerability records ... included in raw vulnerability data 401 based on their respective characteristics." and [0080] "... classifiers 410 and 415 ... can incorporate … any machine learning model, including but not limited to ..., convolutional neural networks, transformers, etc.");
Using a Convolutional Neural Network (CNN) for vulnerability classification is/are known technique(s) in the art, as demonstrated by ALKELAIBI. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the vulnerability detection and mitigation of ZAW and WEIZMAN with the CNN of ALKELAIBI with the motivation to utilize a machine learning model which is especially suited to classification of data sets such as vulnerabilities.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over ZAW (Doc ID US 20170034199 A1), WEIZMAN et al (Doc ID US 20190306178 A1), and ALKELAIBI et al (Doc ID US 20240396921 A1) as applied to claim 1 above, and further in view of CAMERON et al (Doc IDUS 20250165617 A1).
Regarding claim 5:
The combination of ZAW, WEIZMAN, and ALKELAIBI teaches:
The system of claim 1, wherein running the executable code stored to a second memory device causes a second processor to: (a) capture the systems data, the software data, and the software configuration data of the particular network (ZAW [0016] "The scanning may further involve scanning each port at each address .... The crawling may also involve ... submitting requests using different communication protocols to each address. Once a machine is found, the crawling then involves identifying the software running on the machine as well as the configuration for any identified software.");
CAMERON teaches the following limitation(s) not taught by the combination of ZAW, WEIZMAN, and ALKELAIBI:
(b) create a vulnerability database record comprising the systems data, the software data, the software configuration data, the vulnerability data, the firewall attack signature data, and remediation agent data ([0062] "The test data or validation data can also come from data that is stored in databases 308 and 312 …");
(c) generate historical data using the vulnerability database record ([0062] "... The machine learning models can be retrained on existing and/or new training data, training data, or validation data so as to fine-tune the model parameters ...");
(d) generate an error rate by comparing the output data of the vulnerability classification process to the classification analysis to the historical data ([0062] "… error measure (e.g., a difference between a predicted value and an actual/ground-truth value) over the training data."); and
(e) train the at least one neural network by adjusting one or more neural network parameters to reduce the error rate ([0062] "... the machine learning models can be adjusted or modified ... by, for example, adjusting or modifying model parameters ... so as to minimize some error measure (e.g., a difference between a predicted value and an actual/ground-truth value) …").
Training an ML model by comparing actual output to expected output and adjusting parameters based on the error rate is a known technique in the art, as demonstrated by CAMERON. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the vulnerability detection and mitigation of ZAW, WEIZMAN, and ALKELAIBI with the ML model tuning of CAMERON with the motivation to continually improve the accuracy of the model by comparing outputs to known historical data.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over ZAW (Doc ID US 20170034199 A1), WEIZMAN et al (Doc ID US 20190306178 A1), and ALKELAIBI et al (Doc ID US 20240396921 A1) as applied to claim 1 above, and further in view of SHAH (Doc ID US 20220150271 A1).
Regarding claim 8:
The combination of ZAW, WEIZMAN, and ALKELAIBI teaches:
The system of claim 1,
SHAH teaches the following limitation(s) not taught by the combination of ZAW, WEIZMAN, and ALKELAIBI:
The system of claim 1, wherein the remediation agent comprises a human agent with specialized software expertise corresponding to the vulnerability’s category ([0030] "... The defender also determines the appropriate security personnel to assign for mitigation of the vulnerability instances based on historical mitigation data.").
Humans who are knowledgeable in software vulnerability mitigation are known in the art, as demonstrated by SHAH. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the vulnerability detection and mitigation of ZAW, WEIZMAN, and ALKELAIBI with the human agent of SHAH with the motivation to ensure that the agent which is assigned to a vulnerability is knowledgeable in that particular type of software and/or vulnerability.
Claims 9, 10, 14, 16, 17, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over ZAW (Doc ID US 20170034199 A1), and further in view of WEIZMAN et al (Doc ID US 20190306178 A1), ALKELAIBI et al (Doc ID US 20240396921 A1), and CAMERON et al (Doc IDUS 20250165617 A1).
Regarding claim 9:
This claim is rejected with the same justification, mutatis mutandis, as its counterpart claims 1 and 5 above.
Regarding claims 10 and 14:
These claims are rejected with the same justification, mutatis mutandis, as their counterpart claim 1 above.
Regarding claim 16:
ZAW teaches:
A system for vulnerability remediation comprising a first computing device that includes at least one processor and a memory device that stores executable code that, when executed, causes the at least one processor to ([0016] "The process 100 commences by cataloging (at 110) the systems, software, and software configurations of the particular network. … The crawling may involve scanning the address range of the particular network to identify the accessible systems."):
(a) scan a network to detect accessible computing devices and software applications by scanning a range of network addresses and ports ([0016] "The scanning may further involve scanning each port at each address .... The crawling may also involve ... submitting requests using different communication protocols to each address. Once a machine is found, the crawling then involves identifying the software running on the machine as well as the configuration for any identified software.");
(b) catalog system configuration data and vulnerabilities of each computing device and software application detected during the scan ([0017] "The process then compares (at 120) the identified set of software and software configurations (i.e., version numbers) to a database of known vulnerabilities.");
WEIZMAN teaches the following limitation(s) not taught by ZAW:
(c) compare the system configuration data against known vulnerability data to generate a vulnerability set, wherein the vulnerability set comprises a plurality of vulnerabilities that are each associated with a network computing device or software application (Paragraphs [0088]-[0094] and Fig. 7C teach classifying a vulnerability as known (steps 756 and 760), potential (steps 772 and 776), or not a vulnerability (step 772, where the process moves to the next vulnerability when a vulnerability does not meet any of the criteria as a known or potential vulnerability).);
(e) perform a classification analysis using at least one neural network to classify each vulnerability in the vulnerability set as one of: (i) a known vulnerability stored to the database, (ii) a potential vulnerability, or (iii) not a vulnerability (Paragraphs [0088]-[0094] and Fig. 7C teach classifying a vulnerability as known (steps 756 and 760), potential (steps 772 and 776), or not a vulnerability (step 772, where the process moves to the next vulnerability when a vulnerability does not meet any of the criteria as a known or potential vulnerability).);
Conducting a port scan of multiple devices to obtain software configuration data, and identifying vulnerabilities based on the software data is/are known technique(s) in the art, as demonstrated by ZAW. Further, using machine learning (ML) to classify vulnerabilities into multiple groups is/are known technique(s) in the art, as demonstrated by WEIZMAN. It would have been obvious to a person having ordinary skill in the art (PHOSITA) before the effective filing date of the claimed invention to modify the vulnerability detection of ZAW with the classification of WEIZMAN with the motivation to separate the vulnerabilities into groups so that different actions may be taken depending on the group a vulnerability belongs to.
ALKELAIBI teaches the following limitations not taught by the combination of ZAW and WEIZMAN:
(d) provide a machine-learning software module and training data, wherein the machine-learning software module causes the at least one processor to ([0075] "… classifier 410, which classifies the vulnerability records ... included in raw vulnerability data 401 based on their respective characteristics." and [0080] "... classifiers 410 and 415 ... can incorporate … any machine learning model, including but not limited to ..., convolutional neural networks, transformers, etc."):
iv. deploy the trained neural network, wherein the trained neural network comprises an architecture selected from a support vector machine network or a convolutional neural network ([0075] "… classifier 410, which classifies the vulnerability records ... included in raw vulnerability data 401 based on their respective characteristics." and [0080] "... classifiers 410 and 415 ... can incorporate … any machine learning model, including but not limited to ..., convolutional neural networks, transformers, etc.");
Using a Convolutional Neural Network (CNN) for vulnerability classification is/are known technique(s) in the art, as demonstrated by ALKELAIBI. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the vulnerability detection of ZAW and WEIZMAN with the CNN of ALKELAIBI with the motivation to utilize a machine learning model which is especially suited to classification of data sets such as vulnerabilities.
CAMERON teaches the following limitation(s) not taught by the combination of ZAW, WEIZMAN, and ALKELAIBI:
i. iteratively train, using the training data, a neural network to generate simulated vulnerability data ([0062] "The test data or validation data can also come from data that is stored in databases 308 and 312 …"),
ii. insert the training data into an iterative training and testing loop to predict a target vulnerability ([0062] "... The machine learning models can be retrained on existing and/or new training data, training data, or validation data so as to fine-tune the model parameters ..."),
iii. repeatedly determine, during each iteration of the training and testing loop, the target vulnerability ([0062] "… error measure (e.g., a difference between a predicted value and an actual/ground-truth value) over the training data."),
wherein each iteration of the training and testing loop has differing weights assigned to one or more nodes of the neural network, each of the differing weights being updated with each iteration of the training and testing loop to reduce error in predicting the target vulnerability and improve predictability of the neural network, thereby creating a training neural network, ([0062] "... the machine learning models can be adjusted or modified ... by, for example, adjusting or modifying model parameters ... so as to minimize some error measure (e.g., a difference between a predicted value and an actual/ground-truth value) …")and
(f) select a remediation solution module for each vulnerability in the vulnerability set ([0085] "… the system may later use generated set of mitigation actions to configure a network component to automatically apply one or more mitigation actions to correct security vulnerabilities impacting the computing system/platform …");
(g) transmit the remediation solution module to a computing device associated with the vulnerability ([0085] "… the system may later use generated set of mitigation actions to configure a network component to automatically apply one or more mitigation actions to correct security vulnerabilities impacting the computing system/platform …"); and
Examiner notes that the BRI of this limitation encompasses patching software, which involves "integrating" code "within" an application.
(h) implement the remediation solution within the computing device or software application associated with the vulnerability by deploying remediation software code to the computing device or software application ([0085] "… the system may later use generated set of mitigation actions to configure a network component to automatically apply one or more mitigation actions to correct security vulnerabilities impacting the computing system/platform …").
Training an ML model by comparing actual output to expected output and adjusting parameters based on the error rate, and selecting and sending remediation code to a device are known techniques in the art, as demonstrated by CAMERON. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the vulnerability detection of ZAW, WEIZMAN, and ALKELAIBI with the ML model tuning and vulnerability remediation of CAMERON with the motivation to continually improve the accuracy of the model by comparing outputs to known historical data and to provide steps to correct or protect against the vulnerability once it has been discovered.
Regarding claim 17:
This claim is rejected with the same justification, mutatis mutandis, as its counterpart claim 16 above.
Regarding claim 19:
The combination of ZAW, WEIZMAN, ALKELAIBI, and CAMERON teaches:
The system of claim 16, wherein when the remediation solution is transmitted a remediation agent is notified of the vulnerability and the remediation agent monitors the vulnerability (WEIZMAN [0092] "Control continues at 792, where the addition of the new vulnerability scanner cluster is reported to the operator. … this allows the operator to vet the new vulnerability scanner cluster and identify false positives.").
Notifying an agent when a vulnerability has been discovered is/are known technique(s) in the art, as demonstrated by WEIZMAN. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the vulnerability detection and mitigation of ZAW, WEIZMAN, ALKELAIBI, and CAMERON with the agent notification of WEIZMAN with the motivation to ensure that an agent has the information necessary to take further actions to make the system safe against the detected vulnerability.
Claims 15 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over ZAW (Doc ID US 20170034199 A1), WEIZMAN et al (Doc ID US 20190306178 A1), ALKELAIBI et al (Doc ID US 20240396921 A1), and CAMERON et al (Doc IDUS 20250165617 A1) as applied to claims 14 and 19 above, and further in view of SHAH (Doc ID US 20220150271 A1).
Regarding claims 15 and 20:
These claims are rejected with the same justification, mutatis mutandis, as their counterpart claim 8 above.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRANDON BINCZAK whose telephone number is (703)756-4528. The examiner can normally be reached M-F 0800-1700.
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.
/BB/Examiner, Art Unit 2437
/ALI S ABYANEH/Primary Examiner, Art Unit 2437
Prosecution Insights