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 .
The following is final office action in response to communications received 02/25/2026. Claims 4-5 are amended. Claim 7 is canceled. Therefore, claims 1-6 and 8-21 are pending and addressed below.
Response to Arguments
Applicant’s arguments filed 02/25/2026 have been fully considered but they are not persuasive for the following reasons:
Applicant’s Argument (I):
“Regarding Independent Claims 1, 17 and 19, Hutelmyer does not teach or suggest “a threshold number of incidents per time period configured to generate a security event”” as recited on page 7.
Examiner’s Response (I):
The examiner respectfully disagrees. Hutelmyer teaches in paragraph [0052]: “The case count 228 (rule performance indicator) can also be configured to determine case outcomes over a predetermined time period. For example, a higher score can be assigned to a rule that caused identification of a quantity of cases that were all false positives, where the quantity of cases exceeds a minimum threshold value (e.g., 50 cases) over the predetermined time period (e.g., past 180 days) (a threshold number of incidents per time period). Therefore, if the rule triggered 50 cases over the past 180 days but the outcome for the rule was poor because all 50 cases were false positives (In this example, an incident is a false positive case; the threshold number of incidents is 50 cases, the predetermined time period is 180 days.), then the rule may require more immediate attention and/or modification (generate a security event for the respective rules. In this example, any immediate attention and/or modification is understood as a security event for the respective rule.) than a rule that triggered fewer cases but had more positive outcomes.". While the broadest reasonable interpretation (BRI) must be consistent with the specification, it is improper to import limitations from the specification into the claims (MPEP 2111.01(II)). Therefore, the BRI of the claim interprets the "50 cases over the past 180 days required a rule modification” as "50 incidents over the past 180 days required to generate a security event", it is reasonable and common to use “the number of false positive cases” for “the number of incidents”. It would be understood by one of ordinary skill in the art that the prior art above disclosed by Hutelmyer teaches the “a threshold number of incidents per time period configured to generate a security event”, as recited in the claims by the applicant.
Therefore, the 35 U.S.C. 102(a)(1) rejection to claims 1, 17 and 19 are maintained.
Applicant’s Argument (II):
“Regarding Dependent Claim 4, Hutelmyer does not teach or suggest “the true positive rate counts alerts escalated from a T1 analyst to a T2 analyst as true positives”” as recited on page 8.
Examiner’s Response (II):
The examiner respectfully disagrees. The examiner recognized that the “the true positive rate counts alerts escalated from a T1 analyst to a T2 analyst as true positives” is the amended new claim limitation, therefore, additional citations from the same prior art are added to support the examiner’s response. Hutelmyer teaches the true positive rate in paragraph [0066]: “If the number of times that the rule properly triggered (true positive rate) is less than the threshold value, then a higher score can be assigned (310) This can indicate that the rule is not performing as intended”; Hutelmyer further teaches the T1 and T2 supports in paragraph [0007]: “Rules having top scores can be flagged such that they can be reviewed and/or modified to perform better in subsequent triggering events. The rules can be compared to each other based on their assigned scores. A user, such as an analyst (T1 analyst), can be presented with a visual timeline indicating scored performance of rules relative to each other. The developer (T2 analyst) can then have a better understanding of how to modify a particular rule to trigger or perform better in relation to other rules.”; Hutelmyer further teaches the alert counts rate being escalated from T1 analyst to T2 analyst in paragraph [0051]: “The alert count 226 can be configured to determine how many times, in an executed log, that a particular rule was triggered and caused an alert to be generated. In some implementations, the more alerts that are generated, the higher a score can be for the associated rule. If the rule is alerting a lot (e.g., over a predetermined threshold amount), then there can be a problem with the rule and it may need to be addressed by a user, such as a developer (a rate that is being escalated from a T1 analyst to a T2 analyst). Thus, the alert count can be used, by the scoring engine 224, to assign a higher score to the rule”. It would be understood by one of ordinary skill in the art that the true positive rate indicates the number of times that the rule properly triggered which uses the mechanism of alert count for true positives, and when the true positive rate is less than a threshold value, a higher score can be assigned to indicate that the rule is not performing well. Also, with the BRI interpretation to the claim, it is reasonable and common to interpret the “the true positive rate counts alerts escalated from a T1 analyst to a T2 analyst as true positives” to the “the true positive rate counts alerts escalated from an analyst to a developer as true positives”.
Therefore, the 35 U.S.C. 102(a)(1) rejection to claim 4 is maintained.
Applicant’s Argument (III):
“Regarding Dependent claim 5, Hutelmyer does not teach or suggest “the false positive rate counts alerts that are not escalated from a T1 analyst to a T2 analyst as false positives””, as recited on page 9.
Examiner’s Response (III):
The examiner respectfully disagrees. The examiner recognized that the “the false positive rate counts alerts that are not escalated from a T1 analyst to a T2 analyst as false positives” is the amended new claim limitation and also logically obvious as it is inverse of claim 4, therefore, additional citations from the same prior art are added to support the examiner’s response. Hutelmyer teaches the false positive rate in paragraph [0066]: “The rule may be triggering more often for false positives (false positive rate) than it is triggering for true positives. Therefore, a high score can bring attention to the rule such that the users can review and modify it”; Hutelmyer further teaches the T1 and T2 supports in paragraph [0007]: “Rules having top scores can be flagged such that they can be reviewed and/or modified to perform better in subsequent triggering events. The rules can be compared to each other based on their assigned scores. A user, such as an analyst (T1 analyst), can be presented with a visual timeline indicating scored performance of rules relative to each other. The developer (T2 analyst) can then have a better understanding of how to modify a particular rule to trigger or perform better in relation to other rules.”; Hutelmyer further teaches the alert counts rate being escalated from T1 analyst to T2 analyst in paragraph [0051]: “The alert count 226 can be configured to determine how many times, in an executed log, that a particular rule was triggered and caused an alert to be generated. In some implementations, the more alerts that are generated, the higher a score can be for the associated rule. If the rule is alerting a lot (e.g., over a predetermined threshold amount), then there can be a problem with the rule and it may need to be addressed by a user, such as a developer (a rate that is being escalated from a T1 analyst to a T2 analyst). Thus, the alert count can be used, by the scoring engine 224, to assign a higher score to the rule”. It would be understood by one of ordinary skill in the art that a false positive rate counts alerts by the mechanism of alert count for false positives, when it reaches to a high score, then it will bring attention the users to review and modify the rule. Also, with the BRI interpretation to the claim, it is reasonable and common to interpret the “the false positive rate counts alerts that are not escalated from a T1 analyst to a T2 analyst as false positives” to the “the false positive rate counts alerts that are not escalated from an analyst to a developer as false positives”.
Therefore, the 35 U.S.C. 102(a)(1) rejection to claim 5 is maintained.
Applicant’s Argument (IV):
“Regarding Dependent Claim 6, Hutelmyer does not teach or suggest “a first rule that is configured to generate a security alert has a relatively higher rule status indicator, and wherein a second rule that is configured to perform an action other than generating a security alert has a relatively lower rule status indicator””, as recited on page 9. The applicant further argues “Hutelmyer discusses rule scores based on a type of security threat rather than based on actions associated with the rules”, as recited on page 10.
Examiner’s Response (IV):
The examiner respectfully disagrees. Hutelmyer teaches in paragraph [0053]: “In some implementations, rules that are associated with large security threats can be assigned higher scores (a first rule that is configured to generate a security alert has a relatively higher rule status indicator) than rules that are associated with small security threats or no security threats (a second rule that is configured to perform an action other than generating a security alert has a relatively lower rule status indicator). Rule types can be determined by the detection hub system 102. The rule types can alternatively or additionally be determined by the users.” Hutelmyer also teach examples of different rule types as rule status indicator based on a type of response implemented by the respective rules, these rule types are defined by the system or users in the paragraph [0053]: “For example if the rule was triggered in response to a new threat source, the rule may receive a lower score because the rule was able to respond to the new threat source and therefore may not require immediate modification (this rule is configured to perform an action which is to respond to the new threat source and therefore has a relatively lower rule status indicator – lower score). As another example, if the triggered rule is intended to respond to big threats but was triggered for a small or minor threat, the rule can be assigned a higher score because the rule may not be responding appropriately to its intended threats (As this rule is not responding appropriately to its intended threats, a security alert is generated and a relatively higher rule status indicator - a higher score is assigned). As another example, if the triggered rule is supposed to respond to an attack but, when triggered, it remained silent, the rule can be assigned a higher score since it may require more immediate attention such that it can perform properly (the rule is configured to generate a security alert and is assigned a higher rule status indicator - higher score).”.
It would be understood by one of ordinary skill in the art that above prior art teaches “a first rule that is configured to generate a security alert has a relatively higher rule status indicator, and wherein a second rule that is configured to perform an action other than generating a security alert has a relatively lower rule status indicator”.
Therefore, the 35 U.S.C. 102(a)(1) rejection to claim 6 is maintained.
Applicant’s Argument (V):
“Regarding Dependent Claim 10, Hutelmyer does not teach or suggest “the rule change indicator for a first rule is configured to be decremented for each time period after an initial time period for which there is no modification to the first rule” as recited on page 10. The applicant further argues “Hutelmyer teaches away from the limitation presented in dependent claim 10 by assigning lower scores to recently modified rules” as recited on page 11.
Examiner’s Response (V):
The examiner respectfully disagrees. Hutelmyer teaches in paragraph [0054]: “The modification frequency 232 (rule change indicator) can be configured to determine how many times and/or how often that a triggered rule, in the executed log, was modified over a predetermined period of time (indicating a rate at which the respective rules are modified). If the rule was recently modified (e.g., at a time immediately prior to being triggered during log execution), the rule can be assigned a lower score (as the opposite statement to the claim, if the rule was NOT recently modified for each time period after an initial time period, the rule change indicator can be assigned a lower score or a decremented score). It would be understood by one of ordinary skill in the art that the rule change indicator is logically obvious as it can be configured to assign either a decremented score or an incremented score to represent a recent rule modification.
Therefore, the 35 U.S.C. 102(a)(1) rejection to claim 10 is maintained.
Applicant’s Argument (VI):
“Regarding Dependent Claim 3, Hutelmyer and Kannan do not teach or suggest “a rule coverage metric based on a ratio of assets being monitored by the respective rules to a total number of assets in a same group of an asset database”, as recited on page 11.
Examiner’s Response (VI):
The examiner respectfully disagrees. Hutelmyer teaches all the features with respect to the claim 1, as outline above. Kannan teaches in [Col 8, Line 36]: “In some embodiments, threat frameworks, such as Mitre adversarial tactics, techniques, and common knowledge (ATT&CK), and Kill Chain, Mitre ATT&CK, may be employed to organize these adversaries and TTPs and associate detection rules to indicate coverage (rule coverage metric).”; Kannan further teaches in [Col 16, Line 15]: “the content platform130 presents these analytics according to use case to guide the analyst for future use, while also identifying potential coverage gaps that exist in the analyst's monitoring environment”. Kannan further teaches in [Col 13, Line 16]: “In some embodiments, the content platform 130 allows enterprises to define a monitoring scope for each rule when applicable. This scope can define smaller subsets of entities or assets within their environment to which a rule will apply (a ratio of assets being monitored by the respective rules to a total number of assets in a same group of an asset database).”. It would be understood by one of ordinary skill in the art that a rule coverage metric would be based on a ratio of assets being monitored by the respective rules to a total number of assets in a same group of an asset database.
Therefore, the 35 U.S.C. 103 rejection to claim 3 is maintained.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1, 4-6, 10-12, 16-17, 19 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Hutelmyer et al. (US PG-PUB No. 20220321606 A1).
Regarding claim 1, 17 and 19, Hutelmyer et al., hereinafter Hutelmyer, teaches a method, system and product for characterizing performance of a cybersecurity detection tool, the method comprising:
generating a cybersecurity result set in response to applying synthetic test data to the cybersecurity detection tool (paragraph [0009]: “The detection hub (cybersecurity detection tool) system can retrieve, from the log results data store, the results for the processed log of security events (synthetic test data). The results can identify determined outcomes (cybersecurity result set) for instances triggering the plurality of security detection rules (result set is generated when the rules are triggered)”);
extracting respective rules from the cybersecurity detection tool (paragraph [0009]: “The system can also include a detection hub (cybersecurity detection tool) system for assessing the plurality of security detection rules that were triggered (extracting respective rules) by processing of the log of security events.”); and
characterizing the performance of the cybersecurity detection tool based on the cybersecurity result set and the respective rules, wherein the performance includes a rule performance indicator based on a threshold number of incidents per time period configured to generate a security event for the respective rules (paragraph [0009]: “The detection hub (cybersecurity detection tool) system can also determine scores (characterizing the performance) for the plurality of security detection rules (based on the respective rules) based on the results of the processed log of security events and the determined outcomes (cybersecurity result set) and rank the plurality of security detection rules based on the scores”); Paragraph [0052]: “The case count 228 (rule performance indicator) can also be configured to determine case outcomes over a predetermined time period (performance). For example, a higher score (rule performance score) can be assigned to a rule that caused identification of a quantity of cases that were all false positives, where the quantity of cases exceeds a minimum threshold value (e.g., 50 cases) over the predetermined time period (e.g., past 180 days) (a threshold number of incidents per time period). Therefore, if the rule triggered 50 cases over the past 180 days but the outcome for the rule (performance) was poor because all 50 cases were false positives, then the rule may require more immediate attention and/or modification
(generate a security event for the respective rules) than a rule that triggered
fewer cases but had more positive outcomes."
Regarding claim 4, Hutelmyer teaches all of the features with respect to claim 1, as outlined above.
Hutelmyer further teaches wherein the performance includes: a true positive rate indicating accurately identified cybersecurity events by the respective rules, wherein the true positive rate counts alerts escalated from a T1 analyst to a T2 analyst as true positives (paragraph [0065]: “To score the rule, the system 102 can determine a number of times that the selected rule properly triggered more than a threshold value (306) (a true positive rate indicating accurately identified cybersecurity events by the respective rules).”; Paragraph [0066] further discloses “If the number of times that the rule properly triggered is less than the threshold value, then a higher score can be assigned (310) (the true positive rate counts escalated alerts as true positives, and if the counts less than a threshold value, a higher score can be assigned to indicate that the rule is not performing well). This can indicate that the rule is not performing as intended.”; Hutelmyer further teaches the T1 and T2 supports in paragraph [0007]: “Rules having top scores can be flagged such that they can be reviewed and/or modified to perform better in subsequent triggering events. The rules can be compared to each other based on their assigned scores. A user, such as an analyst (T1 analyst), can be presented with a visual timeline indicating scored performance of rules relative to each other. The developer (T2 analyst) can then have a better understanding of how to modify a particular rule to trigger or perform better in relation to other rules.”; Hutelmyer further teaches the alert counts rate being escalated from T1 analyst to T2 analyst in paragraph [0051]: “The alert count 226 can be configured to determine how many times, in an executed log, that a particular rule was triggered and caused an alert to be generated. In some implementations, the more alerts that are generated, the higher a score can be for the associated rule. If the rule is alerting a lot (e.g., over a predetermined threshold amount), then there can be a problem with the rule and it may need to be addressed by a user, such as a developer (a rate that is being escalated from a T1 analyst to a T2 analyst). Thus, the alert count can be used, by the scoring engine 224, to assign a higher score to the rule”.).
Regarding claim 5, Hutelmyer teaches all of the features with respect to claim 1, as outlined above.
Hutelmyer further teaches wherein the performance includes: a false positive rate indicating inaccurately identified cybersecurity events by the respective rules, wherein the false positive rate counts alerts that are not escalated as false positives (paragraph [0066]: “The rule may be triggering more often for false positives (false positive rate) than it is triggering for true positives. Therefore, a high score can bring attention to the rule such that the users can review and modify it (The false positive rate counts alerts that are not escalated as false positives, when it reaches to a high score, then it will bring attention the users to review and modify the rule).”; Hutelmyer further teaches the T1 and T2 supports in paragraph [0007]: “Rules having top scores can be flagged such that they can be reviewed and/or modified to perform better in subsequent triggering events. The rules can be compared to each other based on their assigned scores. A user, such as an analyst (T1 analyst), can be presented with a visual timeline indicating scored performance of rules relative to each other. The developer (T2 analyst) can then have a better understanding of how to modify a particular rule to trigger or perform better in relation to other rules.”; Hutelmyer further teaches the alert counts rate being escalated from T1 analyst to T2 analyst in paragraph [0051]: “The alert count 226 can be configured to determine how many times, in an executed log, that a particular rule was triggered and caused an alert to be generated. In some implementations, the more alerts that are generated, the higher a score can be for the associated rule. If the rule is alerting a lot (e.g., over a predetermined threshold amount), then there can be a problem with the rule and it may need to be addressed by a user, such as a developer (a rate that is being escalated from a T1 analyst to a T2 analyst). Thus, the alert count can be used, by the scoring engine 224, to assign a higher score to the rule”).
Regarding claim 6, Hutelmyer teaches all of the features with respect to claim 1, as outlined above.
Hutelmyer further teaches wherein the performance includes: a rule status indicator based on a type of response implemented by the respective rules, wherein a first rule that is configured to generate a security alert has a relatively higher rule status indicator, and wherein a second rule that is configured to perform an action other than generating a security alert has a relatively lower rule status indicator (paragraph [0053]: “The rule type 230 (rule status indicator) can be configured to determine a rule type for each of the triggered rules in the executed log. The rule type can include, but is not limited to, a source of a threat or event, whether a threat actor is intentionally targeted by the triggered rule, how big of a threat is the triggered rule trying to or supposed to identify, whether the triggered rule is intended to respond to a threat or remain silent and report out, and whether the triggered rule is intended to identify a threat or merely respond to non-threatening events (a rule status indicator based on a type of response implemented by the respective rules). In some implementations, rules that are associated with large security threats can be assigned higher scores (a first rule that is configured to generate a security alert has a relatively higher rule status indicator) than rules that are associated with small security threats or no security threats (a second rule that is configured to perform an action other than generating a security alert has a relatively lower rule status indicator). Rule types can be determined by the detection hub system 102. The rule types can alternatively or additionally be determined by the users.”).
Regarding claim 10, Hutelmyer teaches all of the features with respect to claim 1, as outlined above.
Hutelmyer further teaches wherein the performance includes: a rule change indicator indicating a rate at which the respective rules are modified , wherein the rule change indicator for a first rule is configured to be decremented for each time period after an initial time period for which there is no modification to the first rule (paragraph [0054]: “The modification frequency 232 (rule change indicator) can be configured to determine how many times and/or how often that a triggered rule, in the executed log, was modified over a predetermined period of time (indicating a rate at which the respective rules are modified). If the rule was recently modified (e.g., at a time immediately prior to being triggered during log execution), the rule can be assigned a lower score (as the opposite statement in the claim, if the rule was NOT recently modified for each time period after an initial time period, the rule change indicator can be assigned a lower score or a decremented score. It would be understood by one of ordinary skill in the art would understand that the rule change indicator can be configured to assign either a decremented score or an incremented score to represent a recent rule modification.)”).
Regarding claim 11, Hutelmyer teaches all of the features with respect to claim 1, as outlined above.
Hutelmyer further teaches wherein the performance includes: an alert frequency of the respective rules (paragraph [0051]: “The alert count 226 can be configured to determine how many times, in an executed log, that a particular rule was triggered and caused an alert to be generated (alert frequency). In some implementations, the more alerts that are generated, the higher a score can be for the associated rule”).
Regarding claim 12, Hutelmyer teaches all of the features with respect to claim 1, as outlined above.
Hutelmyer further teaches wherein the performance includes: an indicator of dependencies associated with the respective rules (paragraph [0007]: “the scores can be based on a combination of how frequently a rule fires/is triggered, what outcomes result from triggering the rule, and whether the rule has been verified independently (e.g., by an engineer) as working properly (indicator of dependencies)”).
Regarding claim 16, Hutelmyer teaches all of the features with respect to claim 1, as outlined above.
Hutelmyer further teaches wherein the method is performed by a cybersecurity tool evaluator code, and wherein the method further comprises: metering usage of the cybersecurity tool evaluator code (paragraph [0055]: “Once the rule scoring engine 224 scores each of the triggered rules in the executed log, the rule ranking engine 234 can determine a ranking of the rules based on their scores (metering usage of the cybersecurity tool evaluator code) (e.g., refer to FIG. 4)”); and generating an invoice based on metering the usage of the cybersecurity tool evaluator code (paragraph [0056]: “The score report generator 238 can be configured to generate reports and other visuals (generating an invoice) for each of the scored rules as well as the overall ranked rules (e.g., refer to FIGS. 5-9). The generator 238 can also be configured to generate reports or other visuals about each of the executed logs of events.”).
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 2-3, 13-14 are rejected under 35 U.S.C. 103 as being unpatentable over Hutelmyer et al. (US PG-PUB No. 20220321606 A1) in view of Kannan et al. (US Patent No. 11290483 B1).
Regarding claim 2, Hutelmyer teaches all of the features with respect to claim 1, as outlined above.
Hutelmyer fails to explicitly disclose indicators of IOCs and TTP.
However, Kannan et al., hereinafter Kannan, teaches wherein the performance includes: an indication whether the cybersecurity detection tool identifies threats based on known Indicators of Compromise (IOCs) or Tactics, Techniques, and Procedures (TTP) ([Col 13, Line 60]: “In some embodiments, the content platform130 allows enterprises to manage blacklists that can apply to a single rule or many rules within the platform. In some embodiments, blacklists include objects that track already confirmed malicious activity and behaviors or indicators of compromise (IOCs), associated with a rule(s) to ensure the proper follow up actions occur when the activity is observed.”; [Col 1, Line 41]: “Enterprise systems and services are constantly under attack by adversaries using a variety of threats that are characterized by their tactics, techniques, and procedures (TTPs).”).
Hutelmyer and Kannan are both considered to be analogous to the claimed invention because they both teach security rules. Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the performance indication disclosed by Hutelmyer with adding known indicators of Compromise (IOCs) or Tactics, Techniques, and Procedures (TTP), disclosed by Kannan.
One of ordinary skill in the art would have been motivated to make this modification in order to characterize the variety of threats and ensure the proper follow up actions occur when the activity is observed, as suggested by Kannan in [Col 1, Line 41] and [Col 13, Line 65].
Regarding claim 3, Hutelmyer teaches all of the features with respect to claim 1, as outlined above.
Hutelmyer fails to explicitly disclose a rule coverage metric.
However, Kannan teaches wherein the performance includes: a rule coverage metric based on a ratio of assets being monitored by the respective rules to a total number of assets in a same group of an asset database ([Col 8, Line 36]: “In some embodiments, threat frameworks, such as Mitre adversarial tactics, techniques, and common knowledge (ATT&CK), and Kill Chain, Mitre ATT&CK, may be employed to organize these adversaries and TTPs and associate detection rules to indicate coverage (rule coverage metric).”; Kannan further teaches in [Col 16, Line 15]: “the content platform130 presents these analytics according to use case to guide the analyst for future use, while also identifying potential coverage gaps that exist in the analyst's monitoring environment”. Kannan further teaches in [Col 13, Line 16]: “In some embodiments, the content platform 130 allows enterprises to define a monitoring scope for each rule when applicable. This scope can define smaller subsets of entities or assets within their environment to which a rule will apply (a ratio of assets being monitored by the respective rules to a total number of assets in a same group of an asset database).”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the performance indication disclosed by Hutelmyer with adding a rule coverage metric, disclosed by Kannan.
One of ordinary skill in the art would have been motivated to make this modification in order to identify potential coverage gaps that exist in the analyst’s monitoring environment, as suggested by Kannan in [Col 16, Line 17].
Regarding claim 13, Hutelmyer teaches all of the features with respect to claim 1, as outlined above.
Hutelmyer fails to explicitly disclose EDR tool.
However, Kannan teaches wherein the cybersecurity detection tool is an Endpoint Detection and Response (EDR) tool ([Col 12, Line 18]: “Such an interface allows for the threat detection rules to be deployed in an alternative SIEM or detection engine (e.g., Endpoint Detection and Response (EDR)”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the cybersecurity detection tool disclosed by Hutelmyer with adding EDR tool, disclosed by Kannan.
One of ordinary skill in the art would have been motivated to make this modification in order to allow the data collected from the enterprise sources comprises raw event feeds or data models that align to endpoint devices, as suggested by Kannan in [Col 3, Line 38].
Regarding claim 14, Hutelmyer teaches all of the features with respect to claim 1, as outlined above.
Hutelmyer fails to explicitly disclose SIEM tool.
However, Kannan teaches wherein the cybersecurity detection tool is a Security Information and Event Management (SIEM) tool ([Col 3, Line 33]: “In some embodiments, the threat scenario rule is deployed to a Security Incident and Event Management (SIEM).”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the cybersecurity detection tool disclosed by Hutelmyer with adding SIEM tool, disclosed by Kannan.
One of ordinary skill in the art would have been motivated to make this modification in order to detect scenarios of interest (SOI) based on data collected at the SIEM from enterprise sources, as suggested by Kannan in [Col 3, Line 35].
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Hutelmyer et al. (US PG-PUB No. 20220321606 A1) in view of Bhatia et al. (US PG- PUB No. 20200272741 A1).
Regarding claim 8, Hutelmyer teaches all of the features with respect to claim 1, as Outlined above.
Hutelmyer fails to explicitly disclose a duplicate rule indicator using NLP.
However, Bhatia teaches wherein the performance includes: a duplicate rule indicator that indicates whether the respective rules are duplicative using Natural Language Processing (NLP) (paragraph [0059]: “The ARA uses natural language processing (NLP) techniques, statistical analysis, similarity analysis, topic modeling, principal component analysis (PCA), and rule visualization on the SIEM rules information, threat intelligence information, log source information, framework information, and the like, obtained from these various sources to identify and eliminate duplicate rules, combine similar rules together into “super rules,” align SIEM rules with frameworks and/or standard rules from standard rules repositories, decompose the rules and their conditions into principal components for use in automatically generating new SIEM rules, and train a machine learning model, such as a Recurrent Neural Network (RNN), to generate automated rules based on specific threat intelligence and learning of rule components that correspond to threat characteristics.” Paragraph [0078]: “The rule deduplication and merging engine 108 may be configured to deduplicate pairings of SIEM rules that have a similarity score (duplicate rule indicator) above a specified threshold similarity score (referred to as the deduplication threshold similarity score) indicating that the SIEM rules are considered to be duplicate of one another.”).
Hutelmyer and Bhatia are both considered to be analogous to the claimed invention because they both teach security rules. Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the performance indication disclosed by Hutelmyer with adding a duplicate rule indicator using NLP, disclosed by Bhatia.
One of ordinary skill in the art would have been motivated to make this modification in order to perform deduplication and merging of similar rules based on a cognitive analysis, as suggested by Bhatia in paragraph [0001].
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Hutelmyer et al. (US PG-PUB No. 20220321606 A1) in view of Mwangi et al. (US PG-PUB No. 20110321122 A1).
Regarding claim 9, Hutelmyer teaches all of the features with respect to claim 1, as outlined above.
Hutelmyer fails to explicitly disclose a logic contradiction indicator.
However, Mwangi et al., hereinafter Mwangi, teaches wherein the performance includes: a logic contradiction indicator indicating whether the respective rules contain logic contradictions (abstract: “A conflict detection means for detecting at least two conflicting policy rules indicative of denial and allowance, respectively, of a possible access request (whether the respective rules contain logic contradictions). A conflict indication means (logic contradiction indicator) for indicating to a user information relating to the conflict.”).
Hutelmyer and Mwanqi are both considered to be analogous to the claimed invention because they both teach security rules and policies. Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the performance indication disclosed by Hutelmyer with adding a logic contradiction indicator, disclosed by Mwangi.
One of ordinary skill in the art would have been motivated to make this modification in order to help to create error-free policies, as suggested by Mwangi in paragraph [0011].
Claims 15, 18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Hutelmyer et al. (US PG-PUB No. 20220321606 A1) and Kannan et al. (US Patent No. 11290483 B1) in further view of Bhatia et al. (US PG-PUB No. 20200272741 A1).
Regarding claim 15, 18 and 20, Hutelmyer teaches all of the features with respect to claim 1, 17 and 19 accordingly, as outlined above.
Hutelmyer further teaches the method, system and product of claim 1, 17 and 19, wherein the characterizing the performance of the cybersecurity detection tool further comprises: presenting, on a user interface, an overall average score, a true positive rate score, a false positive rate score, a rule status score, a rule performance score, and a rule changes score (paragraph [0050]: “The rule scoring engine 224 can include one or more modules for determining sub-scores that can be used to generate an overall score (an overall average score) for each of the triggered rules (e.g., refer to FIGS. 3A-B). The sub-scores can be combined and weighted relative to each other for each rule. The rule scoring engine 224 can include an alert count 226, a case count 228 (rule performance indicator for rule performance score), a rule type 230 (rule status indicator for rule status score), and a modification frequency 232 (rule change indicator for rule changes score). The engine 224 can include one or more fewer or additional modules (true positive rate score and false positive rate score, as discloses in paragraph [0065] and [0066]) that can be used to determine sub-scores for the triggered rule.” Paragraph [0058]: “The rule analytics interface 246 can present, to the user, the score reports that were generated by the detection hub system 102. The interface 246 can be interactive, providing the user with an ability to select different reports, rules, case outcomes, and/or executed logs to be displayed (e.g., refer to FIGS. 5-9)”).
Hutelmyer fails to explicitly disclose a TTP coverage score and a rule coverage score.
However, Kannan discloses wherein the characterizing the performance of the cybersecurity detection tool further comprises: a TTP coverage score and a rule coverage score ([Col 8, Line 36]: “In some embodiments, threat frameworks, such as Mitre adversarial tactics, techniques (MITRE® TTP coverage score), and common knowledge (ATT&CK), and Kill Chain, Mitre ATT&CK, may be employed to organize these adversaries and TTPs and associate detection rules to indicate coverage (rule coverage score).”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the performance indication disclosed by Hutelmyer with adding a MITRE® TTP coverage score and a rule coverage score, disclosed by Kannan.
One of ordinary skill in the art would have been motivated to make this modification in order to identify potential coverage gaps that exist in the analyst’s monitoring environment, as suggested by Kannan in [Col 16, Line 17].
Hutelmyer and Kannan both fails to explicitly discloses a duplicate rules score.
However, Bhatia discloses wherein the characterizing the performance of the cybersecurity detection tool further comprises: a duplicate rules score.
Hutelmyer, Kannan and Bhatia are all considered to be analogous to the claimed invention because they all teach security rules. Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the performance indication disclosed by Hutelmyer and Kannan with adding a duplicate rule score, disclosed by Bhatia.
One of ordinary skill in the art would have been motivated to make this modification in order to perform deduplication and merging of similar rules based on a cognitive analysis, as suggested by Bhatia in paragraph [0001].
Claims 21 is rejected under 35 U.S.C. 103 as being unpatentable over Hutelmyer et al. (US PG-PUB No. 20220321606 A1) in view of Harang (US PG-PUB No. 20220156372 A1).
Regarding claim 21, Hutelmyer teaches all of the features with respect to claim 1, as outlined above.
Hutelmyer further teaches wherein extracting respective rules from the cybersecurity detection tool comprises performing dynamic analysis on code associated with the cybersecurity detection tool (Paragraph [0041] “As shown in FIG. 1, items A-K demonstrate a closed feedback loop. This closed feedback loop can be advantageous to provide for dynamic and continuous review and analysis of rules (performing dynamic analysis).”).
Hutelmyer fails to explicitly teach performing static analysis.
However, Harang teaches wherein extracting respective rules from the cybersecurity detection tool comprises performing static analysis and dynamic analysis on code associated with the cybersecurity detection tool (Paragraph [0042] “The analysis object may be, for example, files (e.g., Portable Executable (PE) files), documents, processes, network flows, or any other suitable computing object or the like suitable for analysis. Recognition tasks may be applied, for example, to features determined by static analysis, dynamic analysis, behavior analysis, activity analysis, or any other suitable features.”).
Hutelmyer and Harang are both considered to be analogous to the claimed invention because they both teach cybersecurity. Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the type of analysis disclosed by Hutelmyer with adding performing static analysis, disclosed by Harang.
One of ordinary skill in the art would have been motivated to make this modification in order to improve cybersecurity, as suggested by Harang in paragraph [0002].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure (see PTO-892 form for details).
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 mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JASMINE DAY whose telephone number is (571)272-0204. The examiner can normally be reached Monday - Friday 9:00 - 5:00.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Philip Chea can be reached at 571-272-3951. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/J.M.D./ Examiner, Art Unit 2499 /PHILIP J CHEA/Supervisory Patent Examiner, Art Unit 2499
Prosecution Insights