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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 3/16/2026 has been entered.
Information Disclosure Statement
The information disclosure statements (IDS) filed 10/25/2023 and 1/17/2024 fail to comply with 37 CFR 1.98(a)(2), which requires a legible copy of each cited foreign patent document; each non-patent literature publication or that portion which caused it to be listed; and all other information or that portion which caused it to be listed. It has been placed in the application file, but the information referred to therein has not been considered.
Specifically, copies were not received for the documents listed in the Non-Patent Literature sections.
Response to Arguments
Applicant's arguments, see pages 7-11, filed 3/16/2026, with respect to the rejection of claims 1-20 under 35 USC 101 have been fully considered but they are not persuasive.
Regarding the argument:
“The amended claims are directed to a specific machine-implemented process for generating a threat vector for a software vulnerability using two distinct classification domains:
1. predicting a security category …
2. predicting a data or schema category …
“The method then determines a threat vector derived from these predicted classifications.
“This is not merely analyzing data. Rather, the claims define a specific technical process for transforming threat-intelligence information into a structured threat vector representation used by cybersecurity systems.”
Examiner respectfully disagrees. Transforming data into a “structured” form is not a specific improvement to computer technology, and there are no disclosed details regarding the “predictions” which represent an improvement to technology.
“Courts have repeatedly held that claims directed to specific improvements in computer functionality or computer security systems are not abstract ideas. See, e.g.:
Enfish v. Microsoft, 822 F.3d 1327 (Fed. Cir. 2016)
SRI International v. Cisco, 930 F.3d 1295 (Fed. Cir. 2019)
“Like the network security improvements in SRI, the present claims improve the ability of cybersecurity systems to detect and analyze vulnerabilities using structured threat intelligence representations.”
Examiner respectfully disagrees. In Enfish, details were provided which demonstrated the specific improvement to storage and retrieval of data combined with a specific and novel data structure. In contrast, the instant application combines known methods of data classification and vectorization of data. In SRI, details were provided regarding specific network monitors which analyzed network packets to detect suspicious activity. In contrast, the instant application recites only obtaining and processing data using a generic machine learning (ML) model. There are no claimed functions which represent a specific improvement to any technology.
Regarding the argument:
“Even if the claimed operations were considered to involve data analysis, the claims clearly integrate such analysis into a practical application in cybersecurity systems.
“The claims do not merely process data. Instead they:
receive threat-intelligence information regarding a vulnerability,
apply a machine learning method to generate two different vulnerability classifications, and
determine a threat vector representing exploitation mechanism and impact.”
Examiner respectfully disagrees and notes that receiving information and “determining a threat vector” are given no distinction in the claims over a mental process accomplishing the same tasks. Further, the application of machine learning simply instructs a generic computer product be applied to the judicial exception.
“The resulting threat vector is used to guide cybersecurity operations such as vulnerability analysis and remediation. The specification explicitly describes how the threat vector improves the ability of systems such as XDR, EDR, and NDR systems to correlate vulnerabilities with attacks and determine appropriate remediation actions.”
Examiner respectfully disagrees. Even if, arguendo, such improvement takes place, that the resulting vector may eventually be used for applications which may be deemed eligible subject matter is irrelevant in the analysis of the claim in which the vector is computed, where no such eligible subject matter is recited.
“This is a concrete cybersecurity application, not a mental process.
“The claimed process cannot be practically performed in the human mind because it requires processing large volumes of threat intelligence data using machine learning systems to generate structured threat vectors.
Examiner respectfully disagrees. The claimed process recites no such large volume of data, only obtaining “threat-intelligence information” corresponding to a software vulnerability. Examiner notes that information regarding a single software vulnerability can hardly be considered a volume of data too large to be dealt with in the mind and with pen and paper. Additionally, examiner notes that the claims recite the application of a “machine learning method,” which is distinct from an ML “system.”
Regarding the argument:
“Even if the claims were considered to be directed to an abstract idea, the claims recite significantly more than generic computer implementation.
…
“The Office Action characterizes the claims as using a "generic ML model." However, the claims do not merely apply machine learning to vulnerability data. Instead they require:
prediction of a security category …
prediction of a data/schema category …
followed by determination of a threat vector …
“This dual-classification approach is a non-conventional architecture for vulnerability analysis systems and reflects the technical solution described in the specification.”
Examiner respectfully disagrees. The characterization of the claimed ML model as “generic” is directed towards the fact that the claimed invention is not directed to a novel ML architecture. Given an “off-the-shelf” model, trained with the appropriate data, the functions listed in applicant’s arguments merely represent output which is expected and predictable, which does not represent “significantly more” than the abstract idea of analyzing threat data and conceiving a “vector” representative of predictions regarding the data. The listed functions do not represent a “non-conventional architecture,” nor do they represent an “architecture” of an ML model at all.
“The Federal Circuit has held that specific rules or architectures for automated computer analysis can constitute an inventive concept, even where the implementation uses software or machine learning techniques. See McRO v. Bandai Namco, 837 F.3d 1299 (Fed. Cir. 2016).
“Similarly, the present claims recite a specific classification architecture that transforms raw threat intelligence into a structured threat vector representation. This provides significantly more than the alleged abstract idea.”
Examiner respectfully disagrees. In McRO, the claims were directed to improvement of an animation process through the use of an automated computer process. The instant application merely recites the use of an ML model to be applied to the judicial exception, with no positively claimed details explaining whether the alleged improvement even exists. The majority of the functions relied upon in applicant’s arguments directed to alleged improvements performed by the invention are performed in the “black box” of the ML model, meaning that even if there were “specific rules and architecture” involved in any alleged “improvement,” they are not claimed in the instant application. The “predictions” and “threat vectors” recited in applicant arguments do not represent “specific rules and architecture;” rather, they merely recite the intended results.
Regarding the argument:
“The Office Action asserts that the claimed operations could be performed mentally.
“This characterization is not accurate. The claims require:
applying machine learning methods to threat-intelligence data,
predicting two different vulnerability classifications, and
determining a structured threat vector based on those predictions.
“This process requires computational analysis of complex threat-intelligence data and generation of structured security representations.
“A human analyst cannot practically perform such operations mentally across the large volumes of vulnerability and threat intelligence data processed by cybersecurity systems.
“Thus the claimed invention is not a mental process.”
Examiner respectfully disagrees. This argument merely represents an assertion, and no convincing evidence is provided vis a vie the alleged complexity of the threat data or “structured security representations” (assumed to be a verbose description of the claimed “threat vector”). Again, no claim language describes any such “large volume” of data; indeed, the claims explicitly recite receiving threat data regarding only a single vulnerability.
For the reasons listed above, this rejection is maintained.
Applicant’s arguments, see pages 11-16, filed 3/16/2026, with respect to the rejection of claims X1-20 under 35 USC 103 have been fully considered and are partly persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of KUPPA et al (Doc ID US 20210367961 A1).
Regarding the argument:
“The Office Action further relies on KIM to supplement LABRECHE. KIM generally describes converting vulnerability information into structured information objects and generating documents for sharing vulnerability information.
“However, KIM merely describes organizing vulnerability information into structured formats (e.g., STIX objects). KIM does not disclose predicting categories using machine learning …
“KIM's system converts vulnerability information into predefined formats …. It does not perform the dual classification recited in amended claim 1.
“Therefore, even when considered in combination, KUPPA and KIM do not teach or suggest the amended limitations.”
Examiner respectfully disagrees. In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). The prior art of KIM is relied on for generation of output which encompasses an exploitation mechanism and impact, and not for performing any prediction function.
“Amended claim 1 further requires determining a threat vector based on the predicted security category and the predicted data or schema category.
“Neither LABRECHE nor KIM discloses a system that derives a threat vector based on two distinct predicted classification domains.
“LABRECHE generates attack likelihood predictions directly from vulnerability features. KIM organizes vulnerability information into structured objects. Neither reference describes deriving a threat vector based on both:
a predicted cybersecurity threat classification, and
a predicted data/schema classification.
“The cited references therefore fail to disclose or suggest the claimed method.”
Examiner respectfully disagrees. The prior art of KIM receives information related to vulnerabilities and generates a data object (threat vector) which comprises information about the exploitability and impact of the vulnerability. The method of KIM is not source-specific. The output does not depend on whether the source of the input data is a “prediction,” as being a prediction does not lend any distinguishable characteristic to a value over one which is predetermined.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claims 1 and 12 recite:
Obtaining “threat-intelligence information” regarding a software vulnerability.
Using a generic machine learning (ML) model to determine a “threat vector” based on a “security category” and a “data category” or “schema category” of the software vulnerability.
Claims 2 and 13 recite:
Using a generic machine learning (ML) model to output an “intermediary result corresponding to the security category of the software vulnerability”.
Using a generic machine learning (ML) model to output an “intermediary result corresponding to the data or schema category of the software vulnerability”.
Using a generic machine learning (ML) model for “predicting a threat vector for the software vulnerability based on the first intermediary result and the second intermediary result.”
Claims 3 and 14 recite:
Using a generic machine learning (ML) model that “predicts, based on a security taxonomy or ontology, a type of security threat of the software vulnerability.”
Claims 4 and 15 recite:
Using a generic machine learning (ML) model that “predicts, based on a data taxonomy or ontology, a type of data set or schema for the software vulnerability.”
Claims 5 and 16 recite:
Using a generic machine learning (ML) model that “classifies the software vulnerability according to the security category of the software vulnerability and according to the data or schema category of the software vulnerability.”
Claims 7 and 18 recite:
Selecting a first indicia from among “a STRIDE threat category, a common vulnerability scoring system (CVSS) vector, a vulnerability type, the exploitation mechanism, an exploitation entry point, and MITRE ATT&CK framework tactics and techniques.”
These are processes that, under their broadest reasonable interpretation, may be performed in the mind. Accordingly, the claims recite an abstract idea.
This judicial exception is not integrated into a practical application because other aspects of the claims’ limitations amount no more than mere instructions to apply the exception using a generic ML model and generic computer components.
Regarding limitations directed to the use of the ML model, patents may be directed to abstract ideas where they disclose the use of an already available technology, with its already available basic functions, to use as a tool in executing the claimed process.
Regarding limitations directed to obtaining threat-intelligence information and selecting the first indicia: if a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Analyzing cybersecurity information is a process which has long been performed manually by human programmers. That the claimed invention may perform this task with greater speed and/or efficiency than a human does not by itself render the claims patent eligible under 35 USC 101.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because there is nothing in the claims, whether considered individually or in their ordered combination, that would transform the application into something “significantly more” than the abstract idea of analyzing cybersecurity threat data. Further, the claims do not contain steps through which the ML model achieves an improvement, nor any improvement over generic ML models themselves. The claims are not patent eligible. See Recentive Analytics, Inc. v. Fox Corp., No. 23-2437 (Fed. Cir. 2025) (“patents that do no more than claim the application of generic machine learning to new data environments, without disclosing improvements to the machine learning models to be applied, are patent ineligible under § 101”).
Regarding claims 6, 8-11, 17, 19, and 20:
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.
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.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 112(a) as failing to comply with the written description requirement. The claim(s) contain(s) 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 claim(s) 1 and 12:
Claim 1 recites, “… predict a data or schema category representing a classification of data structures …”. Claim(s) 12 recite(s) similar language. This limitation lacks sufficient written description in the original disclosure, and thus constitutes new matter. The specification is silent regarding classification of “data structures”, nor any mention of the term at all. This rejection can be overcome by amending the claim(s) such that they recite only that subject matter which is explicitly supported by the original disclosure.
Regarding claims 2-11, and 13-20:
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.
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.
Claims 1-3, 5, 12-14, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over KUPPA et al (Doc ID US 20210367961 A1), and further in view of KIM (Doc ID US 20190156042 A1).
Regarding claim 1:
KUPPA teaches:
A method for predicting an exploitation mechanism of a software vulnerability and/or for predicting an impact thereof, the method comprising: obtaining threat-intelligence information regarding a software vulnerability [0057] "At 410, the vulnerability management system 250 receives a CVE description or intrusion report …"); and
applying the threat-intelligence information to a machine learning (ML) method to predict a security category representing a cybersecurity threat classification of the software vulnerability and to predict a data or schema category representing a classification of data structures or schemas associated with the software vulnerability ([0059] "At 430, the vulnerability management system 250 predicts CVE uses and attack techniques using the model …"); and
KIM teaches the following limitations not taught by KUPPA:
determining a threat vector based on the predicted security category and the predicted data or schema category of the software vulnerability ([0077] "Next, in operation S650, the vulnerability information sharing apparatus 100 may convert the vulnerability information into additional vulnerability information. ... Here, the vulnerability information sharing apparatus 100 may generate an information sharing object that includes the predetermined information sharing items and the additional items for the vulnerability information ..."),
wherein the threat vector comprises first indicia that represents an exploitation mechanism of the software vulnerability, and the threat vector comprises second indicia of an impact of the exploitation mechanism of the software vulnerability ([0085] "... the vulnerability information providing system 10 may ... add the ... exploitability and impact items of the information sharing object. Here, the ... exploitability and impact items may be included in the additional items defined additionally in operation S610.").
Determining categorical aspects of a vulnerability using a machine learning (ML) model is a known technique in the art, as demonstrated by KUPPA. Further, representing exploitability and impact of a vulnerability with data derived from categorical vulnerability data is a known technique in the art, as demonstrated by KIM. 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 classification of KUPPA with the data object of KIM with the motivation to create a consolidated data object describing a vulnerability in a standardized way.
Regarding claim 2:
The combination of KUPPA and KIM teaches:
The method of claim 1, wherein applying the threat-intelligence information to the ML method further comprises that the ML method including a first portion constrained to predict a first intermediary result corresponding to the security category of the software vulnerability (KUPPA [0059] "At 430, the vulnerability management system 250 predicts CVE uses … using the model …") and
including a second portion constrained to predict a second intermediary result corresponding to the data or schema category of the software vulnerability (KUPPA [0059] "At 430, the vulnerability management system 250 predicts … attack techniques using the model …"), and
the ML method predicting a threat vector for the software vulnerability based on the first intermediary result and the second intermediary result (KIM [0077] "Next, in operation S650, the vulnerability information sharing apparatus 100 may convert the vulnerability information into additional vulnerability information. ... Here, the vulnerability information sharing apparatus 100 may generate an information sharing object that includes the predetermined information sharing items and the additional items for the vulnerability information ...").
Representing exploitability and impact of a vulnerability with data derived from categorical vulnerability data is a known technique in the art, as demonstrated by KIM. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the vulnerability classification and data object of KUPPA and KIM with the data object of KIM with the motivation to create a consolidated data object describing a vulnerability in a standardized way.
Regarding claim 3:
The combination of KUPPA and KIM teaches:
The method of claim 2, wherein applying the threat-intelligence information to the ML method further comprises that the first portion of the ML method comprises a first transformer neural network that predicts, based on a security taxonomy or ontology, a type of security threat of the software vulnerability (KUPPA [0062] "The data manipulator 502 as illustrated in FIG. 5 may include ... a transform network 505. … These results may be used by the vulnerability management system 250.").
Regarding claim 5:
The combination of KUPPA and KIM teaches:
The method of claim 1, wherein applying the threat-intelligence information to the ML method further comprises applying the threat-intelligence information to a classifier that classifies the software vulnerability according to the security category of the software vulnerability and according to the data or schema category of the software vulnerability (KUPPA [0062] "The computing device 501 may include a Multi-Layer Perceptron (MLP) classifier 507 that operates on the joint latent space 506 and arranges the data objects of the joint latent space 506. ... These results may be used by the vulnerability management system 250.").
Regarding claim 12:
KIM teaches:
A computing apparatus comprising: a processor; and a memory storing instructions that, when executed by the processor, configure the apparatus to ([0022] "… a vulnerability information sharing apparatus comprising: a processor; a storage device which stores a program; and a memory which stores a plurality of operations to be executed by the processor …"):
The remainder of this claim’s limitations are mapped and rejected with the same justification, mutatis mutandis, as its counterpart claim 1.
Regarding claims 13, 14, and 16:
These claims are rejected with the same justification, mutatis mutandis, as their counterpart claims 2, 3, and 5 above.
Claims 4 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over KUPPA et al (Doc ID US 20210367961 A1) and KIM (Doc ID US 20190156042 A1) as applied to claims 3 and 14 above, and further in view of LIN (Doc ID US 20240411898 A1).
Regarding claim 4:
The combination of KUPPA and KIM teaches:
The method of claim 3,
LIN teaches the following limitations not taught by the combination of KUPPA and KIM:
wherein applying the threat-intelligence information to the ML method further comprises that the second portion of the ML method comprises a second transformer neural network that predicts, based on a data taxonomy or ontology, a type of data set or schema for the software vulnerability ([0058] "At the third stage, initial scores are assigned to each vulnerability in block 103 using the Common Vulnerability Scoring System (CVSS) … Each of the vulnerabilities is assigned scores of … access complexity, authentication, … remediation level …").
Using ML to generate vulnerability data based on data ontology is a known technique in the art, as demonstrated by LIN. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the vulnerability classification and data object of KUPPA and KIM with the ML model of LIN with the motivation to generate vulnerability from various forms of data related to the vulnerability.
Regarding claim 15:
This claim is rejected with the same justification, mutatis mutandis, as its counterpart claim 4 above.
Claims 6 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over KUPPA et al (Doc ID US 20210367961 A1) and KIM (Doc ID US 20190156042 A1) as applied to claims 1 and 12 above, and further in view of MULLANEY (Doc ID US 20220286475 A1).
Regarding claim 6:
The combination of KUPPA and KIM teaches:
The method of claim 1,
MULLANEY teaches the following limitations not taught by the combination of KUPPA and KIM:
wherein the ML method has been trained using labeled training data that includes training threat-intelligence information that is labeled according to threat vectors, security categories, and data or schema categories ([0095] "… a CVSS vector may be an example of the training vulnerability vector. Thus, each training vulnerability vector of at least one training vulnerability data may comprise ...: [0096] attack vector (AV) metric … [0098] a privileges required (PR) metric ...").
Training a machine learning model with labelled vulnerability data is a known technique in the art, as demonstrated by MULLANEY. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the vulnerability classification and data object of KUPPA and KIM with the labelled training data of MULLANEY with the motivation to provide supervised learning to the model. It is obvious to label training data so that the model is able to produce consistent results based on the desired outcome.
Regarding claim 17:
This claim is rejected with the same justification, mutatis mutandis, as its counterpart claim 6 above.
Claims 7 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over KUPPA et al (Doc ID US 20210367961 A1) and KIM (Doc ID US 20190156042 A1) as applied to claims 1 and 12 above, and further in view of MOHANTY (Doc ID US 9692778 B1).
Regarding claim 7:
The combination of KUPPA and KIM teaches:
The method of claim 1,
MOHANTY teaches the following limitations not taught by the combination of KUPPA and KIM:
The method of claim 1, wherein the threat vector comprises the first indicia comprises a predicted classification corresponding to one or more items from the group consisting of: a STRIDE threat category, a common vulnerability scoring system (CVSS) vector, a vulnerability type, the exploitation mechanism, an exploitation entry point, and MITRE ATT&CK framework tactics and techniques (Col 3 lines 43-58 "The system and method employ an algorithm that correlates vulnerabilities with contextual information such as threat data …. The algorithm works on a three dimensional ... model ...: Dimension#1 ... Related data could include base/temporal CVSS score, ... severity, etc. Dimension#2 ... Related data could include threat impact, impacted CVE ID, type of threat ...". Examiner notes that the remainder of the examples given in the claim are obvious to try, and represent a selection of alternatives among a finite number of identified, predictable solutions.).
Describing a threat using systems such as STRIDE and MITRE ATT&CK is a well-known technique in the art, as demonstrated by MOHANTY. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the vulnerability classification and data object of KUPPA and KIM with the threat categorization of MOHANTY with the motivation to utilize well-known standards in threat categorization such as STRIDE, CVSS, and MITRE ATT&CK. It is obvious to use industry standards so that the threat information is expressed in a format understandable to systems designed for working with software vulnerabilities.
Regarding claim 18:
This claim is rejected with the same justification, mutatis mutandis, as its counterpart claim 7 above.
Claims 8, 9, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over KUPPA et al (Doc ID US 20210367961 A1) and KIM (Doc ID US 20190156042 A1) as applied to claims 1 and 12 above, and further in view of ALEIDAN (Doc ID US 20210211450 A1).
Regarding claim 8:
The combination of KUPPA and KIM teaches:
The method of claim 1,
ALEIDAN teaches the following limitations not taught by the combination of KUPPA and KIM:
further comprising: providing the threat vector to a remediation processor ([0108] "... the vulnerability remediator 185 can access the database 140 ..., and prioritize the vulnerabilities …"); and
performing, by the remediation processor, a remediating action based on the threat vector ([0111] "… the remediation actions can be implemented to resolve the corresponding vulnerabilities …").
Providing remediation for an identified software vulnerability is a known technique in the art, as demonstrated by ALEIDAN. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the vulnerability classification and data object of KUPPA and KIM with the vulnerability remediation of ALEIDAN with the motivation to provide the user with a means to mitigate the threat posed by a vulnerability. It is obvious to remediate vulnerabilities, where possible, with minimal input from the user.
Regarding claim 9:
The combination of KUPPA, KIM, and ALEIDAN teaches:
The method of claim 8, wherein the remediating action is selected from the group consisting of quarantining a computer implementable instruction corresponding to the software vulnerability, installing a software patch, updating and/or upgrading software corresponding to the software vulnerability, defending privileges and/or accounts, enforcing signed software execution policies, exercising a recovery plan, managing systems and/or configurations, searching or scanning for network intrusions, engaging hardware security features, increasing segregation of networks and processors, and transitioning to multi-factor authentication (ALEIDAN [0094] "… The vulnerability remediator 185 ... can be arranged to mitigate the vulnerabilities by ... implementing patches or fixes ..., disconnecting the computer resource assets from the computer network 10 ..., breaking connectivity links to the computer resource assets, terminating access ..., modifying firewall policies or rules, or modifying router policies or rules." Examiner notes that the remainder of the examples given in the claim are obvious to try, and represent a selection of alternatives among a finite number of identified, predictable solutions.).
Utilizing vulnerability remediation methods such as patches, hardware security, and configuration management are well-known techniques in the art, as demonstrated by ALEIDAN. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the vulnerability classification and data object of KUPPA, KIM, and ALEIDAN with the remediation strategies of ALEIDAN with the motivation to provide the user with a means to mitigate the threat posed by a vulnerability. It is obvious to use proven and well-known remediation strategies for cases in which they are appropriate.
Regarding claims 19 and 20:
These claims are rejected with the same justification, mutatis mutandis, as their counterpart claims 8 and 9 above.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over KUPPA et al (Doc ID US 20210367961 A1) and KIM (Doc ID US 20190156042 A1) as applied to claim 1 above, and further in view of PAL et al (Doc ID US 20230062725 A1).
Regarding claim 10:
The combination of KUPPA and KIM teaches:
The method of claim 1,
PAL teaches the following limitations not taught by the combination of KUPPA and KIM:
further comprising: signaling the threat vector to a user ([0050] "... requesting user feedback on power-up to perform reinforced learning under critical situation to avoid nuisance tripping.");
receiving user feedback regarding values of the threat vector ([0051] "Step 511 includes checking whether user feedback is available or not;"); and
performing reinforcement learning based on the received user feedback to update the ML method ([0051] "… step 512, perform reinforced learning based on user feedback;").
Addressing the user, receiving feedback on output from a machine learning model, and using reinforcement learning to incorporate the feedback into the model are known techniques in the art, as demonstrated by PAL. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the vulnerability classification and data object of KUPPA and KIM with the reinforcement learning of PAL with the motivation to maintain an up-to-date model producing results with as much accuracy as possible. It is obvious to use feedback and reinforcement learning in an environment where the security landscape changes at a rapid pace.
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over KUPPA et al (Doc ID US 20210367961 A1), KIM (Doc ID US 20190156042 A1), and PAL et al (Doc ID US 20230062725 A1) as applied to claim 10 above, and further in view of MELNIKOV et al (Doc ID US 20210182370 A1).
Regarding claim 11:
The combination of KUPPA, KIM, and PAL teaches:
The method of claim 10,
MELNIKOV teaches the following limitations not taught by the combination of KUPPA, KIM, and PAL:
further comprising: prior to receiving the user feedback, verifying, based on login credentials of the user, that the user is authorized to provide the user feedback ([0038] "Based on the authorize user's feedback, continuous authentication module 106 may retrain machine learning module 115, adjust the weights assigned to the respective usage attributes, … (if the current user is the authorized user).").
Ensuring a user is authorized before accepting their feedback for use in training a machine learning model is a known technique in the art, as demonstrated by MELNIKOV. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the vulnerability classification and data object of KUPPA, KIM, and PAL with the user authorization of MELNIKOV with the motivation to ensure that only authorized users are able to provide feedback, and by extension changes, to the model. It is obvious to do this by checking a user’s authorization prior to accepting feedback from the user.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
KIM et al (Doc ID US 20230048076 A1) teaches a similar method of determining categories and outputting transformed data. However, it is performed on a file believed to be malicious and not on a vulnerability.
UEDA et al (Doc ID US 20230024824 A1) teaches a similar method of categorizing software vulnerabilities and vectorizing the results. However, it is performed on virtual vulnerabilities in order to determine whether they exist on a live system, and not on a novel vulnerability input into the system.
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
/ALEXANDER LAGOR/Supervisory Patent Examiner, Art Unit 2437
Prosecution Insights