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 .
Claims 1-20 are pending. Claims 1 and 12 are independent. Claims 1, 7, 12, and 18 are amended. Claims 1-20 are rejected.
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-9, filed 8/5/2026, with respect to the rejection of claims 1-20 under 35 U.S.C. 101 have been fully considered but they are not persuasive.
Regarding the amended claims and the interview conducted on 8/3/2026:
Examiner notes that a key distinction noted during the discussion was that the new amendment recite performing a remedial action that was chosen. As currently drafted, the amended claims recite the additional limitation of determining a remediating action, which still falls within the mental process category of abstract ideas. See the below rejection for suggested amendment to overcome this rejection. As to other arguments, examiner notes that they are substantially the same as those answered in the previous office action and are a matter of record, and those answers are incorporated here. This rejection is maintained.
Applicant's arguments, see pages 7-9, filed 8/5/2026, with respect to the rejection of claims 1-20 under 35 U.S.C. 112(a) have been fully considered and are persuasive. The associated rejection(s) to the listed claim(s) has/have been withdrawn.
Applicant's arguments, see pages 10-16, filed 8/5/2026, with respect to the rejection of claims 1-20 under 35 U.S.C. 103 have been fully considered.
Regarding claims 1 and 12:
Regarding “KUPPA Does Not Teach Predicting a Data or Schema Category Representing a Type of Data Set or Schema for the Software Vulnerability”:
Examiner respectfully disagrees. The terms “security category,” “data category,” and “schema category” have no commonly agreed upon definition in the art, and the original disclosure provides no definition which precludes the mapping provided in the previous office action. The most detail regarding these terms is found in ¶ 0033 of the specification (emphasis added), “… determine a threat vector based on a security category and a data or schema category of the software vulnerability, wherein the threat vector comprises first indicia that represents a exploitation mechanism of the software vulnerability, and the threat vector comprises second indicia that represents a scope of the exploitation mechanism of the software vulnerability.” The broadest reasonable interpretation of “security category” in this context encompasses the “use” of a CVE, where the “use” is taken to mean which CVEs (categories) are predicted to be used in an attack. Likewise, the broadest reasonable interpretation of a “data or schema category” in this context encompasses the mapped “attack techniques” where the various attack techniques represent the “scope of the exploitation mechanism.” This portion of the rejection is maintained.
Remaining arguments directed to this issue merely address the prior art which is not mapped to this limitation.
Regarding “KUPPA and KIM Do Not Teach Determining the Threat Vector Based on Both Predicted Categories”:
Examiner respectfully disagrees. The claims are given their broadest reasonable interpretation within the context of the specification. Regarding this limitation, the specification teaches at ¶¶ 0021 and 0033 (emphasis added), “In one aspect, a method is provided for predicting an exploitation mechanism of a software vulnerability and/or for predicting an impact of the exploitation mechanism of the software vulnerability. … The threat vector comprises first indicia that represents a exploitation mechanism of the software vulnerability, and the threat vector comprises second indicia of a scope of the exploitation mechanism of the software vulnerability.”
Examiner notes that this is in contrast to the claimed limitation, which recites a “second indicia of an impact of the exploitation mechanism”.
The original disclosure does not draw any concrete definitions or distinctions among the “scope” and “impact” of the exploitations. Indeed, the terms appear to be interchangeable. Further, where the claim recites, “… determining a threat vector based on the predicted security category and the predicted data or schema category …”, and then, “… the threat vector comprises first indicia that represents an exploitation mechanism …, and … second indicia of an impact of the exploitation mechanism …”, it is indicated that the security and data or schema categories are at least closely linked (or interchangeable outside of their context within either the “threat vector” or “indicia), with the “exploitation mechanism” and “impact of the exploitation mechanism,” respectively. Thus, supplied with the “additional information” represented by the “CVE uses and attack techniques” of the prior art of Kuppa, already mapped to the security and data or schema categories, the method of Kim would function predictably to output a sharing object (vector) including these indicia. This portion of the rejection is maintained.
Regarding, “The Cited Combination Does Not Teach the Newly Added Final Use Limitation”:
Examiner first notes that based on the change in scope created by the amendment, the previous prior art rejection is withdrawn.
Regarding the argument, “Neither reference teaches using a threat vector to relate a software vulnerability to indicia of an attack detected”, examiner notes that no attack, detected or otherwise, is recited in the claim.
Regarding claims 2, 4, 13, and 15:
These arguments are persuasive. Therefore, the rejection(s) has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of NGWETA et al (Doc ID US 11924239 B2).
Regarding claims 3 and 14:
Applicant argues that the prior art of Kuppa does not disclose a transformer neural network (TNN). Examiner respectfully disagrees. Besides the cited paragraph of Kuppa, the reference additionally teaches at, inter alia ¶ [0070], “… In addition to attention sub-layers, in some designs, each of the layers in the encoder and decoder of the transform network 505 contains a fully connected feed-forward network 709 …”. The specification also makes numerous references to “transformer blocks” and “feed-forward networks,” all of which would be recognized by one of ordinary skill in the art as well-known, fundamental features of a TNN. These rejections are maintained.
Regarding claims 5 and 16:
Examiner notes that these arguments are addressed in answers to arguments directed to the prior art of Kuppa and depended-on claims 1 and 12.
Regarding claims 6 and 17:
Applicant argues that the prior art of Mullaney does not teach “training threat- intelligence information labeled according to all of the claimed categories, including data or schema categories.” Examiner notes that the claims in question recite an obvious and well-known method of training a machine learning (ML) model, in which training data is labelled using the intended inputs and outputs of the model. The prior art provides an example of this method, and using this method with the claimed categories is obvious to try. This rejection is maintained, and updated to include clearer language.
Regarding claims 7 and 18:
Applicant argues that the explanation given regarding claim elements being obvious to try is insufficient. Examiner concedes that “obvious to try” is not an appropriate rationale for obviousness. However, Examiner notes that the prior art referenced in the previous office action maps sufficiently to the claim, as it teaches multiple elements from the claimed list of alternatives.
Regarding claims 8, 9, 19, and 20:
In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the feature(s) upon which applicant relies “using the claimed threat vector to relate the software vulnerability to indicia of an attack detected and to determine a remediating action based on the first indicia and the second indicia”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). This rejection is maintained
Regarding claim 10:
Applicant argues that the prior art performs the mapped function in a different context. The prior art is agnostic the context of a given user feedback, and would identically perform the claimed function given user feedback and machine learning model.
Examiner notes that additional arguments are directed to the alleged allowability of claims based on their dependency to already-argued claims, and will not be addressed.
Claim Objections
Claim(s) 12-20 is/are objected to because of the following informalities:
Regarding claim(s) 12:
The portion of the claim reciting. “… predict a data or schema category representing for the software vulnerability …” should be corrected to: “… category representing or “… schema category
Regarding claims 13-20:
They are objected to for being dependent on one or more objected-to claims. These objections could be overcome by overcoming the objections to any claims upon which these claims depend, or by amending the claim such that they are no longer dependent on any objected-to claims.
Appropriate correction is required.
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.
Choosing a remedial action to address the threats.
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 § 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, 5, 12, 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 for the software vulnerability ([0059] "At 430, the vulnerability management system 250 predicts CVE uses and attack techniques using the model …");
using the threat vector to determine a remediating action based on the first indicia and the second indicia ([0059] "At 430, the vulnerability management system 250 … suggests mitigation techniques for the vulnerability management system to use to address the CVE exploit.").
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."); and
Determining categorical aspects of a vulnerability using a machine learning (ML) model and choosing an appropriate remedial action is/are 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. This is a combination of prior art elements according to known methods which yields predictable results.
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 claim(s) 16:
The listed claim(s) is/are rejected with the same justification, mutatis mutandis, as its/their counterpart claim(s) 5 above.
Claims 2-4 and 13-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 1 and 12 above, and further in view of NGWETA et al (Doc ID US 11924239 B2).
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
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.
NGWETA teaches the following limitation(s) not taught by the above combination:
including a second portion constrained to predict a second intermediary result corresponding to the data or schema category of the software vulnerability, (Col 7 lines 51-58 "... in FIG. 1, map component 108 can employ a BERT model to define mappings (e.g., associations, relationships, etc.) between vulnerability data representing a vulnerability of a computing resource ... and attack data representing at least one attack technique ...") and
Using an ML model to assess vulnerability and attack data is/are known technique(s) in the art, as demonstrated by NGWETA. 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 NGWETA with the motivation to focus a model on particular aspects of a vulnerability assessment. This is a known technique applied to a known device which produces predictable results.
Regarding claim 3:
The combination of KUPPA, KIM, and NGWETA 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 4:
The combination of KUPPA, KIM, and NGWETA teaches:
The method of claim 3,
NGWETA teaches the following limitations not taught by the above combination:
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 (NGWETA Col 7 lines 51-58 "... in FIG. 1, map component 108 can employ a BERT model to define mappings (e.g., associations, relationships, etc.) between vulnerability data representing a vulnerability of a computing resource ... and attack data representing at least one attack technique ...").
Using a BERT (bidirectional encoder representations from transformers), which is a type of Transformer Neural Network (TNN), to generate vulnerability data based on data ontology is a known technique in the art, as demonstrated by NGWETA. 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 NGWETA with the ML model of NGWETA with the motivation to generate vulnerability analyses from various forms of data related to the vulnerability. This is a combination of prior art elements according to known methods which yields predictable results.
Regarding claims 13, 14, and 15:
These claims are rejected with the same justification, mutatis mutandis, as their counterpart claims 2, 3, and 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. This is the well-known and inherent way that ML models are trained, and is obvious to try.
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:
wherein 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 ...").
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. This is a known technique which has been used to improve similar devices.
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 above combination:
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. This is a known technique which has been used to improve similar devices.
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. This is a known technique which has been used to improve similar devices.
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 above combination:
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. This is a known technique which has been used to improve similar devices.
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 above combination:
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. This is a known technique which has been used to improve similar devices.
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.
/BRANDON BINCZAK/Examiner, Art Unit 2437
