DETAILED ACTION
Notice of 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 and are rejected.
Response to Amendment
This Office Action is responsive to the amendment filed on 06/04/2026.
Claims 1, 9 and 17 are amended and are being fully considered by the examiner.
In response to applicant’s amendments to claims 1, 9 and 17 and arguments filled 06/04/2026, all the 35 USC § 101 rejections of claims 1-20 as set forth in the previous office action has been withdrawn.
THIS ACTION IS MADE FINAL.
Claim Objections
Duplicate Claim Warning
Claim 2 is duplicate of claim 1:
Claims 1 and 2 both include the exact same limitation, “wherein the alert policy change data object is configured to cause rendering of an alert policy change recommendation interface to a user device display of the alert manager device.”
Applicant is advised that should claim 1 be found allowable, claim 2 will be objected to under 37 CFR 1.75 as being a substantial duplicate thereof. When two claims in an application are duplicates or else are so close in content that they both cover the same thing, despite a slight difference in wording, it is proper after allowing one claim to object to the other as being a substantial duplicate of the allowed claim. See MPEP § 608.01(m).
Claim 8 is duplicate of claim 1:
Claims 1 and 8 both include the exact same limitations, “wherein the one or more processors and one or more memories storing instructions are further operable, when executed by the one or more processors, to cause the alert cluster analysis apparatus to:
access one or more alert policy change instructions generated based on user engagement with the alert policy change recommendation interface; and
store one or more alert policy configuration changes to an alert policy database based on the one or more alert policy change instructions.”
Applicant is advised that should claim 1 be found allowable, claim 8 will be objected to under 37 CFR 1.75 as being a substantial duplicate thereof. When two claims in an application are duplicates or else are so close in content that they both cover the same thing, despite a slight difference in wording, it is proper after allowing one claim to object to the other as being a substantial duplicate of the allowed claim. See MPEP § 608.01(m).
Claim 10 is duplicate of claim 9:
Claims 9 and 10 both include the exact same limitation, “wherein the alert policy change data object is configured to cause rendering of an alert policy change recommendation interface to a user device display of the alert manager device.”
Applicant is advised that should claim 9 be found allowable, claim 10 will be objected to under 37 CFR 1.75 as being a substantial duplicate thereof. When two claims in an application are duplicates or else are so close in content that they both cover the same thing, despite a slight difference in wording, it is proper after allowing one claim to object to the other as being a substantial duplicate of the allowed claim. See MPEP § 608.01(m).
Claim 16 is duplicate of claim 9:
Claims 9 and 16 both include the exact same limitations, “accessing one or more alert policy change instructions generated based on user engagement with the alert policy change recommendation interface; and
storing one or more alert policy configuration changes to an alert policy database based on the one or more alert policy change instructions.”
Applicant is advised that should claim 9 be found allowable, claim 16 will be objected to under 37 CFR 1.75 as being a substantial duplicate thereof. When two claims in an application are duplicates or else are so close in content that they both cover the same thing, despite a slight difference in wording, it is proper after allowing one claim to object to the other as being a substantial duplicate of the allowed claim. See MPEP § 608.01(m).
Claim 18 is duplicate of claim 17:
Claims 17 and 18 both include the exact same limitation, “wherein the alert policy change data object is configured to cause rendering of an alert policy change recommendation interface to a user device display of the alert manager device.”
Applicant is advised that should claim 17 be found allowable, claim 18 will be objected to under 37 CFR 1.75 as being a substantial duplicate thereof. When two claims in an application are duplicates or else are so close in content that they both cover the same thing, despite a slight difference in wording, it is proper after allowing one claim to object to the other as being a substantial duplicate of the allowed claim. See MPEP § 608.01(m).
Claim Rejections - 35 USC § 112
35 USC § 112(d)
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Independent claims failed to further limit the subject matter of the claim upon which they depend:
Claims 2, 8, 10, 16 and 18 are rejected under 35 U.S.C. 112(d), as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends.
Claims 2, 20, and 18 each repeats the exact same limitation, “wherein the alert policy change data object is configured to cause rendering of an alert policy change recommendation interface to a user device display of the alert manager device” that was recited by the corresponding independent claims 1, 9 and 17. Claims 2, 12, and 18 failed to further limit the subject matter of the claim upon which they depend (corresponding independent claims 1, 9 and 17).
Claims 8 and 16 each repeats the exact same limitations, “access(ing) one or more alert policy change instructions generated based on user engagement with the alert policy change recommendation interface; and store(ing) one or more alert policy configuration changes to an alert policy database based on the one or more alert policy change instruction” that were recited by the corresponding independent claims 1, 9 and 17. Claims 8 and 16 failed to further limit the subject matter of the claim upon which they depend (corresponding independent claims 1 and 9).
Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements.
Response to Arguments
Applicant’s arguments, see pages 9-10 of the remarks, filed 06/04/2026, with respect to 35 USC 101 rejections of claims 1-20 have been fully considered and are persuasive. The 35 USC 101 rejections of claims 1-20 has been withdrawn.
Applicant responds
(a) Rejections under 35 U.S.C. § 101
The same amendments…integrate any alleged abstract idea into a practical application by requiring specific technical components-an alert policy change recommendation interface, user engagement processing, and an alert policy database-that provide a concrete technical improvement to alert management systems. Accordingly, Applicant submits that the amended claims are patent eligible under 35 U.S.C. § 101.
(Pages: 9-10)
With respect to (a) above, Examiner appreciates the interpretative description given by Applicant in response.
Applicant’s amendments as described above in (a) are persuasive. In response to applicant’s amendments to claims 1, 9 and 17 and applicant’s remarks, the 35 USC 101 rejections of claims 1-20 has been withdrawn.
Applicant's arguments filed 06/04/2026 have been fully considered but they are not persuasive.
Applicant responds
(b) Rejections under 35 U.S.C. §102
Patrich does not disclose the newly added limitations of the amended claims.
However, Patrich's user interface 334 merely "provides a notification to a system administrator of the validated incident."
In contrast, the amended claims recite a system that outputs an alert policy change data object configured to cause rendering of an alert policy change recommendation interface, accesses alert policy change instructions based on user engagement with that interface, and stores alert policy configuration changes to an alert policy database. These features are entirely absent from Patrich. Accordingly, Applicant submits that the amended claims are not anticipated by Patrich.
(Pages: 8-9)
With respect to (b) above, Examiner appreciates the interpretative description given by Applicant in response.
Regarding the limitation, alert policy change data object is configured to cause rendering of an alert policy change recommendation interface to a user device display of the alert manager device, this limitation is broad, and it describes an user interface is presented with policy change recommendation in a display, where the policy change recommendation interface can be any interface displaying policy change recommendation and the policy change recommendation can be any policy change recommendation, and policy can be any policy. Accordingly, as described in the previous office action (for example rejections of claim 2), Patrich discloses, displaying validated incident to the user/operator that is recommendation to the user that there is a change in score such that is meets the predetermined criteria.
Regarding the limitation, access one or more alert policy change instructions generated based on user engagement with the alert policy change recommendation interface; and store one or more alert policy configuration changes to an alert policy database based on the one or more alert policy change instructions, this limitation is broad describes user accesses policy change instructions by interacting with the user interface, where the policy change instructions can be any instructions, and then storing alert policy configuration changes to an alert policy database based on the instructions accessed by user (for example, rejections of claim 8), where policy configuration changes to alert policy database can be any alert policy change. Accordingly, Patrich discloses, as described in the previous office action, operator access the interface to access policy change instruction and accessed instruction is a policy change such as a score change is then stored. Further, Patrich discloses, the operator may access the change interface to change rules/policies that are then stored.
For the purpose of compact prosecution, examiner notes that, these limitations are broad and describes user provided with a user interface, then user accessing the user interface, and storage of policy change instructions based on user accessing the user interface, and doesn’t provide any additional detailed descriptions of these policy change instructions and alert policy configuration changes.
Applicant’s arguments are fully considered, but for the above described reasons, they are not persuasive; therefore, the claims 1, 9, and 17 are rejected under 35 USC § 102 as described in the current office action and the rejections are updated based on applicants amendments.
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.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claim(s) 1-4, 7-12, 15-20 is/are rejected under 35 U.S.C. 102(a)(1)/102(a)(2) as being anticipated by Patrich et al. (US20180351783A1) [hereinafter Patrich].
Regarding claim 1 (amended):
Patrich discloses, An alert cluster analysis apparatus comprising one or more processors and one or more memories storing instructions that are operable, when executed by the one or more processors, to cause the alert cluster analysis apparatus to: [¶4: Methods, systems, and computer program products are provided for evaluating a chain of alerts.
¶95: implemented as computer program code/instructions configured to be executed in one or more processors and stored in a computer readable storage medium];
access an alert set associated with one or more service events; [¶58: Flowchart 400 commences at step 402. At step 404, alerts are received. In an embodiment, alerts are obtained from any of servers 112A-112N and/or computing device(s) 140.
¶45: alerts 120A-120N include any security alerts that are perceived as unauthorized or illegitimate attempts to access servers 112A-112N, network 100, or any other device connected to network 110. Alerts 120A-120N may also include comprise one or more alert(s) resulting from Internet noise that any of servers 112A-112N or computing device(s) 140 view as a potential threat.];
apply a feature extraction model that is configured to extract alert features from the alert set;
apply an alert clustering model to group alerts of the alert set into one or more alert clusters based at least in part on the alert features; [¶59: step 406, alerts are grouped into sets based on a predetermined relationship…generator 312 groups alerts contained within alert log 301 into a plurality of alert sets comprising one or more alerts based on a predetermined relationship between the alerts…groups alerts contained within alert log 301 based on a timing relationship between the alerts…group together alerts in alert log 301 that commonly occur together at the same time, or nearly the same time…group alerts into a set that occur within a predetermined time interval…create a set of alerts containing alerts in a sequence of alerts that begins with a first alert and continues until a predetermined length of time passes during which no further alerts are received…group together alerts in alert log 301 using contextual information (e.g., username, process name, IP address, etc.) included in alert log 301…group together alerts in alert log 301 using any number of predetermined criteria, including but not limited to temporal and/or contextual information contained within alert log 301.];
determine an alert significance score for each of the one or more alert clusters; [¶60: In step 408, for each set of alerts, a score is determined that represents a statistical likelihood of correlation between the alerts….Score determiner 322 determines a plurality of scores for the alert sets generated by alert set generator 312. Score determiner 322 may use any suitable technique for generating the score representing statistical likelihood, such as a lift score, a correlation function, etc.];
compare the alert significance score for each of the one or more alert clusters to an alert insignificance threshold; and [¶68: In step 414,…if chain of alerts 305 contained alerts [A, B, C], alert chain searcher 314 may analyze model 332 to determine if the set of alerts [A, B, C] is present (and having an associated score). If chain of alerts 305 has a match in model 332, operation proceeds from step 414 to step 416....
¶69: In step 416,…once chain of alerts 305 (or a sub-chain of alerts thereof) is located in model 332, score analyzer 324 determines whether the corresponding score in model 332 meets a predetermined criteria (e.g., has a relationship with a threshold value, a value range, etc.)…score analyzer 324 determines whether the corresponding score is above a threshold value.];
in a circumstance where an alert significance score for a selected alert cluster of the one or more alert clusters satisfies the alert insignificance threshold, output an alert policy change data object to an alert manager device. [¶69: In step 416,…score analyzer 324 determines whether the corresponding score in model 332 meets a predetermined criteria (e.g., has a relationship with a threshold value, a value range, etc.)…if a score for a chain of alerts is above a threshold value, score analyzer 324 may decide that the chain of alerts indicates an actual threat to network 110 or one of the devices connected to network 110. If the score is below the threshold value, operation proceeds to the iterative loop at step 420, described below, whereby one alert is removed and the extracted sub-chains of alerts are analyzed.
¶71: if score analyzer 324 determines the score meets the predetermined criteria, operation proceeds from step 416 to step 418. If score analyzer 324 determines the score does not meet the predetermined criteria, operation proceeds from step 416 to step 420.
¶72: In step 418 of FIG. 4, if the score meets a predetermined criteria, an indication is provided to an administrator…if score analyzer 324 determines that a score corresponding to chain of alerts 305 (or a sub-chain of alerts) meets the predetermined criteria, user interface 334 provides a notification to a system administrator of the validated incident. The notification may be provided at a computing device of computing device(s) 140, or transmitted to a different computing device,].
wherein the alert policy change data object is configured to cause rendering of an alert policy change recommendation interface to a user device display of the alert manager device. [¶72: In step 418 of FIG. 4, if the score meets a predetermined criteria, an indication is provided to an administrator…if score analyzer 324 determines that a score corresponding to chain of alerts 305 (or a sub-chain of alerts) meets the predetermined criteria, user interface 334 provides a notification to a system administrator of the validated incident. The notification may be provided at a computing device of computing device(s) 140, or transmitted to a different computing device…may provide a notification for play or display to a system administrator (or other user) via user interface 334…User interface 334 may be any one of a graphical user interface, audio interface, haptic interface, or any other interface a user may access and/or monitor.];
wherein the one or more processors and one or more memories storing instructions are further operable, when executed by the one or more processors, to cause the alert cluster analysis apparatus to:
access one or more alert policy change instructions generated based on user engagement with the alert policy change recommendation interface; and
store one or more alert policy configuration changes to an alert policy database based on the one or more alert policy change instructions. [¶32: take into consideration additional information accompanying the alerts, and adjust a score accordingly based on such additional information. In one embodiment, a system administrator may manually set rules identifying alerts or types of alerts that are related. In such an instance, a score calculation may take these additional rules into account prior to storing the score in the model…
¶65: a system administrator may manually set rules identifying alerts or types of alerts that are correlated or indicative of an attack on device or network. In such an instance, score determiner 322 may take the manual rules or contextual information into account prior to storing the score (e.g., by scaling the score accordingly) in the model…
[¶72: user interface 334 provides a notification to a system administrator of the validated incident…User interface 334 may be any one of a graphical user interface, audio interface, haptic interface, or any other interface a user may access and/or monitor.].
Regarding claim 2:
Patrich discloses, The alert cluster analysis apparatus of claim 1, and
Patrich further discloses, wherein the alert policy change data object is configured to cause rendering of an alert policy change recommendation interface to a user device display of the alert manager device. [¶72: In step 418 of FIG. 4, if the score meets a predetermined criteria, an indication is provided to an administrator…if score analyzer 324 determines that a score corresponding to chain of alerts 305 (or a sub-chain of alerts) meets the predetermined criteria, user interface 334 provides a notification to a system administrator of the validated incident. The notification may be provided at a computing device of computing device(s) 140, or transmitted to a different computing device…may provide a notification for play or display to a system administrator (or other user) via user interface 334…User interface 334 may be any one of a graphical user interface, audio interface, haptic interface, or any other interface a user may access and/or monitor.
Examiner notes the duplicate claim warning and the 35 USC 112(d) rejections as set forth in the current office action].
Regarding claim 3:
Patrich discloses, The alert cluster analysis apparatus of claim 1, and
Patrich further discloses, wherein determining the alert significance score for each of the one or more alert clusters comprises
determining an incident linkage status for each alert of the one or more alert clusters. [¶60: In step 408, for each set of alerts, a score is determined that represents a statistical likelihood of correlation between the alerts…score determiner 322 determines, for each set of alerts, the likelihood that one alert in the set of alerts is correlated to another alert in the same set…calculates a score representing a statistical likelihood that at least one alert in the set of alerts is correlated to at least one other alert in the set…the determined score may represent how unlikely the alerts in the group of alerts occurred by chance or coincidence…determines a plurality of scores for the alert sets generated by alert set generator 312. Score determiner 322 may use any suitable technique for generating the score representing statistical likelihood, such as a lift score, a correlation function, etc.].
Regarding claim 4:
Patrich discloses, The alert cluster analysis apparatus of claim 1, and
Patrich further discloses, wherein determining the alert significance score for each of the one or more alert clusters comprises
determining a significant action status for each alert of the one or more alert clusters. [¶61: score determiner 322 may extract each combination of unique associations between alerts contained with each alert set…score determiner 322 may extract combinations [A→B, C], [B→A, C], [C→A, B], [A, B→C], [A, C→B], [B, C→A]. For example, the combination [A→B, C] may represent the likelihood that alert [A] is correlated to the occurrence of alert [B] and alert [C]…score determiner 322 determines a score for each association rule extracted. The maximum score determined by score determiner 322 across the combination of unique associations for a particular set of alerts may be assigned by score determiner 322 as the score for the particular set of alerts.].
Regarding claim 7:
Patrich discloses, The alert cluster analysis apparatus of claim 1, and
Patrich further discloses, wherein determining an alert significance score for each of the one or more alert clusters comprises
applying at least one of a linear discriminant analysis model, a support vector machine model, or a neural network model to alert features of the one or more alert clusters. [Examiner notes that claim requires only one of the elements separated by “or” and therefore only one of them is given the patentable weight.
Patrich discloses the limitation, applying a linear discriminant analysis model as described below,
¶66: the model may be used to evaluate further received alerts to determine related alerts for grouping into incidents.
¶60: In step 408, for each set of alerts, a score is determined that represents a statistical likelihood of correlation between the alerts….Score determiner 322 determines a plurality of scores for the alert sets generated by alert set generator 312. Score determiner 322 may use any suitable technique for generating the score representing statistical likelihood, such as a lift score, a correlation function, etc.
¶69: In step 416, if the chain of alerts (or any sub-chain of alerts extracted in step 422) corresponds to a score in the model, it is determined whether the score meets a predetermined criteria. In an embodiment, with respect to FIG. 3, once chain of alerts 305 (or a sub-chain of alerts thereof) is located in model 332, score analyzer 324 determines whether the corresponding score in model 332 meets a predetermined criteria (e.g., has a relationship with a threshold value, a value range, etc.).].
Regarding claim 8:
Patrich discloses, The alert cluster analysis apparatus of claim 2, and
Patrich further discloses, wherein the one or more processors and one or more memories storing instructions are further operable, when executed by the one or more processors, to cause the alert cluster analysis apparatus to:
access one or more alert policy change instructions generated based on user engagement with the alert policy change recommendation interface; and
store one or more alert policy configuration changes to an alert policy database based on the one or more alert policy change instructions. [¶32: take into consideration additional information accompanying the alerts, and adjust a score accordingly based on such additional information. In one embodiment, a system administrator may manually set rules identifying alerts or types of alerts that are related. In such an instance, a score calculation may take these additional rules into account prior to storing the score in the model…
¶65: a system administrator may manually set rules identifying alerts or types of alerts that are correlated or indicative of an attack on device or network. In such an instance, score determiner 322 may take the manual rules or contextual information into account prior to storing the score (e.g., by scaling the score accordingly) in the model…
[¶72: user interface 334 provides a notification to a system administrator of the validated incident…User interface 334 may be any one of a graphical user interface, audio interface, haptic interface, or any other interface a user may access and/or monitor.
Examiner notes the duplicate claim warning and the 35 USC 112(d) rejections as set forth in the current office action].
Regarding claim 9 (amended):
Patrich discloses, A computer-implemented method comprising: [¶4: Methods, systems, and computer program products are provided for evaluating a chain of alerts.];
accessing an alert set associated with one or more service events; [¶58: Flowchart 400 commences at step 402. At step 404, alerts are received. In an embodiment, alerts are obtained from any of servers 112A-112N and/or computing device(s) 140.
¶45: alerts 120A-120N include any security alerts that are perceived as unauthorized or illegitimate attempts to access servers 112A-112N, network 100, or any other device connected to network 110. Alerts 120A-120N may also include comprise one or more alert(s) resulting from Internet noise that any of servers 112A-112N or computing device(s) 140 view as a potential threat.];
applying a feature extraction model that is configured to extract alert features from the alert set;
applying an alert clustering model to group alerts of the alert set into one or more alert clusters based at least in part on the alert features; [¶59: step 406, alerts are grouped into sets based on a predetermined relationship…generator 312 groups alerts contained within alert log 301 into a plurality of alert sets comprising one or more alerts based on a predetermined relationship between the alerts…groups alerts contained within alert log 301 based on a timing relationship between the alerts…group together alerts in alert log 301 that commonly occur together at the same time, or nearly the same time…group alerts into a set that occur within a predetermined time interval…create a set of alerts containing alerts in a sequence of alerts that begins with a first alert and continues until a predetermined length of time passes during which no further alerts are received…group together alerts in alert log 301 using contextual information (e.g., username, process name, IP address, etc.) included in alert log 301…group together alerts in alert log 301 using any number of predetermined criteria, including but not limited to temporal and/or contextual information contained within alert log 301.];
determining an alert significance score for each of the one or more alert clusters; [¶60: In step 408, for each set of alerts, a score is determined that represents a statistical likelihood of correlation between the alerts….Score determiner 322 determines a plurality of scores for the alert sets generated by alert set generator 312. Score determiner 322 may use any suitable technique for generating the score representing statistical likelihood, such as a lift score, a correlation function, etc.];
comparing the alert significance score for each of the one or more alert clusters to an alert insignificance threshold; and [¶68: In step 414,…if chain of alerts 305 contained alerts [A, B, C], alert chain searcher 314 may analyze model 332 to determine if the set of alerts [A, B, C] is present (and having an associated score). If chain of alerts 305 has a match in model 332, operation proceeds from step 414 to step 416....
¶69: In step 416,…once chain of alerts 305 (or a sub-chain of alerts thereof) is located in model 332, score analyzer 324 determines whether the corresponding score in model 332 meets a predetermined criteria (e.g., has a relationship with a threshold value, a value range, etc.)…score analyzer 324 determines whether the corresponding score is above a threshold value.];
in a circumstance where an alert significance score for a selected alert cluster of the one or more alert clusters satisfies the alert insignificance threshold, outputting an alert policy change data object to an alert manager device. [¶69: In step 416,…score analyzer 324 determines whether the corresponding score in model 332 meets a predetermined criteria (e.g., has a relationship with a threshold value, a value range, etc.)…if a score for a chain of alerts is above a threshold value, score analyzer 324 may decide that the chain of alerts indicates an actual threat to network 110 or one of the devices connected to network 110. If the score is below the threshold value, operation proceeds to the iterative loop at step 420, described below, whereby one alert is removed and the extracted sub-chains of alerts are analyzed.
¶71: if score analyzer 324 determines the score meets the predetermined criteria, operation proceeds from step 416 to step 418. If score analyzer 324 determines the score does not meet the predetermined criteria, operation proceeds from step 416 to step 420.
¶72: In step 418 of FIG. 4, if the score meets a predetermined criteria, an indication is provided to an administrator…if score analyzer 324 determines that a score corresponding to chain of alerts 305 (or a sub-chain of alerts) meets the predetermined criteria, user interface 334 provides a notification to a system administrator of the validated incident. The notification may be provided at a computing device of computing device(s) 140, or transmitted to a different computing device,];
wherein the alert policy change data object is configured to cause rendering of an alert policy change recommendation interface to a user device display of the alert manager device, [¶72: In step 418 of FIG. 4, if the score meets a predetermined criteria, an indication is provided to an administrator…if score analyzer 324 determines that a score corresponding to chain of alerts 305 (or a sub-chain of alerts) meets the predetermined criteria, user interface 334 provides a notification to a system administrator of the validated incident. The notification may be provided at a computing device of computing device(s) 140, or transmitted to a different computing device…may provide a notification for play or display to a system administrator (or other user) via user interface 334…User interface 334 may be any one of a graphical user interface, audio interface, haptic interface, or any other interface a user may access and/or monitor.];
wherein the computer-implemented method further comprises:
accessing one or more alert policy change instructions generated based on user engagement with the alert policy change recommendation interface; and
storing one or more alert policy configuration changes to an alert policy database based on the one or more alert policy change instructions. [¶32: take into consideration additional information accompanying the alerts, and adjust a score accordingly based on such additional information. In one embodiment, a system administrator may manually set rules identifying alerts or types of alerts that are related. In such an instance, a score calculation may take these additional rules into account prior to storing the score in the model…
¶65: a system administrator may manually set rules identifying alerts or types of alerts that are correlated or indicative of an attack on device or network. In such an instance, score determiner 322 may take the manual rules or contextual information into account prior to storing the score (e.g., by scaling the score accordingly) in the model…
[¶72: user interface 334 provides a notification to a system administrator of the validated incident…User interface 334 may be any one of a graphical user interface, audio interface, haptic interface, or any other interface a user may access and/or monitor.].
Regarding claim 10:
Patrich discloses, The computer-implemented method of claim 9, and
Patrich further discloses, wherein the alert policy change data object is configured to cause rendering of an alert policy change recommendation interface to a user device display of the alert manager device. [¶72: In step 418 of FIG. 4, if the score meets a predetermined criteria, an indication is provided to an administrator…if score analyzer 324 determines that a score corresponding to chain of alerts 305 (or a sub-chain of alerts) meets the predetermined criteria, user interface 334 provides a notification to a system administrator of the validated incident. The notification may be provided at a computing device of computing device(s) 140, or transmitted to a different computing device…may provide a notification for play or display to a system administrator (or other user) via user interface 334…User interface 334 may be any one of a graphical user interface, audio interface, haptic interface, or any other interface a user may access and/or monitor.
Examiner notes the duplicate claim warning and the 35 USC 112(d) rejections as set forth in the current office action].
Regarding claim 11:
Patrich discloses, The computer-implemented method of claim 9, and
Patrich further discloses, wherein determining the alert significance score for each of the one or more alert clusters comprises
determining an incident linkage status for each alert of the one or more alert clusters. [¶60: In step 408, for each set of alerts, a score is determined that represents a statistical likelihood of correlation between the alerts…score determiner 322 determines, for each set of alerts, the likelihood that one alert in the set of alerts is correlated to another alert in the same set…calculates a score representing a statistical likelihood that at least one alert in the set of alerts is correlated to at least one other alert in the set…the determined score may represent how unlikely the alerts in the group of alerts occurred by chance or coincidence…determines a plurality of scores for the alert sets generated by alert set generator 312. Score determiner 322 may use any suitable technique for generating the score representing statistical likelihood, such as a lift score, a correlation function, etc.].
Regarding claim 12:
Patrich discloses, The computer-implemented method of claim 9, and
Patrich further discloses, wherein determining the alert significance score for each of the one or more alert clusters comprises
determining a significant action status for each alert of the one or more alert clusters. [¶61: score determiner 322 may extract each combination of unique associations between alerts contained with each alert set…score determiner 322 may extract combinations [A→B, C], [B→A, C], [C→A, B], [A, B→C], [A, C→B], [B, C→A]. For example, the combination [A→B, C] may represent the likelihood that alert [A] is correlated to the occurrence of alert [B] and alert [C]…score determiner 322 determines a score for each association rule extracted. The maximum score determined by score determiner 322 across the combination of unique associations for a particular set of alerts may be assigned by score determiner 322 as the score for the particular set of alerts.].
Regarding claim 15:
Patrich discloses, The computer-implemented method of claim 9, and
Patrich further discloses, wherein determining an alert significance score for each of the one or more alert clusters comprises
applying at least one of a linear discriminant analysis model, a support vector machine model, or a neural network model to alert features of the one or more alert clusters. [Examiner notes that claim requires only one of the elements separated by “or” and therefore only one of them is given the patentable weight.
Patrich discloses the limitation, applying a linear discriminant analysis model as described below,
¶66: the model may be used to evaluate further received alerts to determine related alerts for grouping into incidents.
¶60: In step 408, for each set of alerts, a score is determined that represents a statistical likelihood of correlation between the alerts….Score determiner 322 determines a plurality of scores for the alert sets generated by alert set generator 312. Score determiner 322 may use any suitable technique for generating the score representing statistical likelihood, such as a lift score, a correlation function, etc.
¶69: In step 416, if the chain of alerts (or any sub-chain of alerts extracted in step 422) corresponds to a score in the model, it is determined whether the score meets a predetermined criteria. In an embodiment, with respect to FIG. 3, once chain of alerts 305 (or a sub-chain of alerts thereof) is located in model 332, score analyzer 324 determines whether the corresponding score in model 332 meets a predetermined criteria (e.g., has a relationship with a threshold value, a value range, etc.).].
Regarding claim 16:
Patrich discloses, The computer-implemented method of claim 10, and
Patrich further discloses, accessing one or more alert policy change instructions generated based on user engagement with the alert policy change recommendation interface; and
storing one or more alert policy configuration changes to an alert policy database based on the one or more alert policy change instructions. [¶32: take into consideration additional information accompanying the alerts, and adjust a score accordingly based on such additional information. In one embodiment, a system administrator may manually set rules identifying alerts or types of alerts that are related. In such an instance, a score calculation may take these additional rules into account prior to storing the score in the model…
¶65: a system administrator may manually set rules identifying alerts or types of alerts that are correlated or indicative of an attack on device or network. In such an instance, score determiner 322 may take the manual rules or contextual information into account prior to storing the score (e.g., by scaling the score accordingly) in the model…
[¶72: user interface 334 provides a notification to a system administrator of the validated incident…User interface 334 may be any one of a graphical user interface, audio interface, haptic interface, or any other interface a user may access and/or monitor.
Examiner notes the duplicate claim warning and the 35 USC 112(d) rejections as set forth in the current office action].
Regarding claim 17 (amended):
Patrich discloses, A computer program product, stored on a computer readable medium, comprising instructions that when executed by one or more computers cause the one or more computers to: [¶4: Methods, systems, and computer program products are provided for evaluating a chain of alerts.
¶95: implemented as computer program code/instructions configured to be executed in one or more processors and stored in a computer readable storage medium];
access an alert set associated with one or more service events; [¶58: Flowchart 400 commences at step 402. At step 404, alerts are received. In an embodiment, alerts are obtained from any of servers 112A-112N and/or computing device(s) 140.
¶45: alerts 120A-120N include any security alerts that are perceived as unauthorized or illegitimate attempts to access servers 112A-112N, network 100, or any other device connected to network 110. Alerts 120A-120N may also include comprise one or more alert(s) resulting from Internet noise that any of servers 112A-112N or computing device(s) 140 view as a potential threat.];
apply a feature extraction model that is configured to extract alert features from the alert set;
apply an alert clustering model to group alerts of the alert set into one or more alert clusters based at least in part on the alert features; [¶59: step 406, alerts are grouped into sets based on a predetermined relationship…generator 312 groups alerts contained within alert log 301 into a plurality of alert sets comprising one or more alerts based on a predetermined relationship between the alerts…groups alerts contained within alert log 301 based on a timing relationship between the alerts…group together alerts in alert log 301 that commonly occur together at the same time, or nearly the same time…group alerts into a set that occur within a predetermined time interval…create a set of alerts containing alerts in a sequence of alerts that begins with a first alert and continues until a predetermined length of time passes during which no further alerts are received…group together alerts in alert log 301 using contextual information (e.g., username, process name, IP address, etc.) included in alert log 301…group together alerts in alert log 301 using any number of predetermined criteria, including but not limited to temporal and/or contextual information contained within alert log 301.];
determine an alert significance score for each of the one or more alert clusters; [¶60: In step 408, for each set of alerts, a score is determined that represents a statistical likelihood of correlation between the alerts….Score determiner 322 determines a plurality of scores for the alert sets generated by alert set generator 312. Score determiner 322 may use any suitable technique for generating the score representing statistical likelihood, such as a lift score, a correlation function, etc.];
compare the alert significance score for each of the one or more alert clusters to an alert insignificance threshold; and [¶68: In step 414,…if chain of alerts 305 contained alerts [A, B, C], alert chain searcher 314 may analyze model 332 to determine if the set of alerts [A, B, C] is present (and having an associated score). If chain of alerts 305 has a match in model 332, operation proceeds from step 414 to step 416....
¶69: In step 416,…once chain of alerts 305 (or a sub-chain of alerts thereof) is located in model 332, score analyzer 324 determines whether the corresponding score in model 332 meets a predetermined criteria (e.g., has a relationship with a threshold value, a value range, etc.)…score analyzer 324 determines whether the corresponding score is above a threshold value.];
in a circumstance where an alert significance score for a selected alert cluster of the one or more alert clusters satisfies the alert insignificance threshold, output an alert policy change data object to an alert manager device. [¶69: In step 416,…score analyzer 324 determines whether the corresponding score in model 332 meets a predetermined criteria (e.g., has a relationship with a threshold value, a value range, etc.)…if a score for a chain of alerts is above a threshold value, score analyzer 324 may decide that the chain of alerts indicates an actual threat to network 110 or one of the devices connected to network 110. If the score is below the threshold value, operation proceeds to the iterative loop at step 420, described below, whereby one alert is removed and the extracted sub-chains of alerts are analyzed.
¶71: if score analyzer 324 determines the score meets the predetermined criteria, operation proceeds from step 416 to step 418. If score analyzer 324 determines the score does not meet the predetermined criteria, operation proceeds from step 416 to step 420.
¶72: In step 418 of FIG. 4, if the score meets a predetermined criteria, an indication is provided to an administrator…if score analyzer 324 determines that a score corresponding to chain of alerts 305 (or a sub-chain of alerts) meets the predetermined criteria, user interface 334 provides a notification to a system administrator of the validated incident. The notification may be provided at a computing device of computing device(s) 140, or transmitted to a different computing device,];
wherein the alert policy change data object is configured to cause rendering of an alert policy change recommendation interface to a user device display of the alert manager device [¶72: In step 418 of FIG. 4, if the score meets a predetermined criteria, an indication is provided to an administrator…if score analyzer 324 determines that a score corresponding to chain of alerts 305 (or a sub-chain of alerts) meets the predetermined criteria, user interface 334 provides a notification to a system administrator of the validated incident. The notification may be provided at a computing device of computing device(s) 140, or transmitted to a different computing device…may provide a notification for play or display to a system administrator (or other user) via user interface 334…User interface 334 may be any one of a graphical user interface, audio interface, haptic interface, or any other interface a user may access and/or monitor.].
access one or more alert policy change instructions generated based on user engagement with the alert policy change recommendation interface; and
store one or more alert policy configuration changes to an alert policy database based on the one or more alert policy change instructions. [¶32: take into consideration additional information accompanying the alerts, and adjust a score accordingly based on such additional information. In one embodiment, a system administrator may manually set rules identifying alerts or types of alerts that are related. In such an instance, a score calculation may take these additional rules into account prior to storing the score in the model…
¶65: a system administrator may manually set rules identifying alerts or types of alerts that are correlated or indicative of an attack on device or network. In such an instance, score determiner 322 may take the manual rules or contextual information into account prior to storing the score (e.g., by scaling the score accordingly) in the model…
[¶72: user interface 334 provides a notification to a system administrator of the validated incident…User interface 334 may be any one of a graphical user interface, audio interface, haptic interface, or any other interface a user may access and/or monitor.].
Regarding claim 18:
Patrich discloses, The computer program product of claim 17, and
Patrich further discloses, wherein the alert policy change data object is configured to cause rendering of an alert policy change recommendation interface to a user device display of the alert manager device. [¶72: In step 418 of FIG. 4, if the score meets a predetermined criteria, an indication is provided to an administrator…if score analyzer 324 determines that a score corresponding to chain of alerts 305 (or a sub-chain of alerts) meets the predetermined criteria, user interface 334 provides a notification to a system administrator of the validated incident. The notification may be provided at a computing device of computing device(s) 140, or transmitted to a different computing device…may provide a notification for play or display to a system administrator (or other user) via user interface 334…User interface 334 may be any one of a graphical user interface, audio interface, haptic interface, or any other interface a user may access and/or monitor.
Examiner notes the duplicate claim warning and the 35 USC 112(d) rejections as set forth in the current office action].
Regarding claim 19:
Patrich discloses, The computer program product of claim 17, and
Patrich further discloses, wherein determining the alert significance score for each of the one or more alert clusters comprises
determining an incident linkage status for each alert of the one or more alert clusters. [¶60: In step 408, for each set of alerts, a score is determined that represents a statistical likelihood of correlation between the alerts…score determiner 322 determines, for each set of alerts, the likelihood that one alert in the set of alerts is correlated to another alert in the same set…calculates a score representing a statistical likelihood that at least one alert in the set of alerts is correlated to at least one other alert in the set…the determined score may represent how unlikely the alerts in the group of alerts occurred by chance or coincidence…determines a plurality of scores for the alert sets generated by alert set generator 312. Score determiner 322 may use any suitable technique for generating the score representing statistical likelihood, such as a lift score, a correlation function, etc.].
Regarding claim 20:
Patrich discloses, The computer program product of claim 17, and
Patrich further discloses, wherein determining the alert significance score for each of the one or more alert clusters comprises
determining a significant action status for each alert of the one or more alert clusters. [¶61: score determiner 322 may extract each combination of unique associations between alerts contained with each alert set…score determiner 322 may extract combinations [A→B, C], [B→A, C], [C→A, B], [A, B→C], [A, C→B], [B, C→A]. For example, the combination [A→B, C] may represent the likelihood that alert [A] is correlated to the occurrence of alert [B] and alert [C]…score determiner 322 determines a score for each association rule extracted. The maximum score determined by score determiner 322 across the combination of unique associations for a particular set of alerts may be assigned by score determiner 322 as the score for the particular set of alerts.].
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filling date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
Determining the scope and contents of the prior art.
Ascertaining the differences between the prior art and the claims at issue.
Resolving the level of ordinary skill in the pertinent art.
Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 5 and 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Patrich and further in view of Gupta’309 et al. (US10469309B1) [hereinafter GUPTA’309].
Regarding claim 5:
Patrich discloses, The alert cluster analysis apparatus of claim 1, and
Patrich further discloses, wherein the one or more processors and one or more memories storing instructions are further operable, when executed by the one or more processors, to cause the alert cluster analysis apparatus to:
determine if the selected alert cluster of the one or more alert clusters is associated with an increasing alert volume status or a decreasing alert volume status; [Examiner notes that claim requires only one of the elements separated by “or” and therefore only one of them is given the patentable weight.
Patrich discloses the limitation, determine if the selected alert cluster of the one or more alert clusters is associated with an increasing alert volume status as described below,
¶31: a score is calculated for sets of alerts occurring in the past on more than a predetermined number of occasions, and is rendered unknown for sets of alerts not occurring more than a predetermined number of occasions.];
output the alert policy change data object to the alert manager device only in circumstances…where the selected alert cluster satisfies the alert insignificance threshold. [¶31: a score is calculated for sets of alerts occurring in the past on more than a predetermined number of occasions, and is rendered unknown for sets of alerts not occurring more than a predetermined number of occasions. The output of the process is a model that contains a score for each set of alerts…
¶72: In step 418 of FIG. 4, if the score meets a predetermined criteria, an indication is provided to an administrator…if score analyzer 324 determines that a score corresponding to chain of alerts 305 (or a sub-chain of alerts) meets the predetermined criteria, user interface 334 provides a notification to a system administrator of the validated incident. The notification may be provided at a computing device of computing device(s) 140, or transmitted to a different computing device,], but doesn’t explicitly disclose, and
GUPTA’309 discloses, output the alert policy change data object to the alert manager device only in circumstances where the selected alert cluster is associated with the increasing alert volume status [col 14, lines 24-33: At 906, avalanche windows may be determined based on an alert count for a time window meeting or exceeding the avalanche threshold….Avalanche patterns may be based on intersections that have an intersection score that meets or exceeds an avalanche pattern threshold. Intersection scores may be determined based on number of intersections and number of avalanche window alerts.…
col 7, lines 23-26: The avalanche window module 308 may determine the avalanche windows 512/514/518 based on a total alert count 502 within each time window TW that…exceeds the avalanche threshold 506…
col 12, lines 43-45: A presentation module 324 may generate a display region for displaying the alert groups for monitoring by a user or system administrator].
Therefore, it would have been obvious to one of ordinary skill in the art before the filling date of the claimed invention to have combined the capability of outputting the alert policy change data object to the alert manager device only in circumstances where the selected alert cluster is associated with the increasing alert volume status in order to enable a user or system administrator to more efficiently manage alert dispositions by reducing the number of alerts by eliminating redundant and insignificant alerts taught by GUPTA’309 with the apparatus taught by Patrich as discussed above in order to have reasonable expectation of success such as to enable a user or system administrator to more efficiently manage alert dispositions by reducing the number of alerts by eliminating redundant and insignificant alerts [GUPTA’309, col 13, lines 5-14: Accordingly, the alert pattern detection and alert grouping is a useful tool to enable a user or system administrator to more efficiently manage alert dispositions by reducing the number of alerts, which may have been inflated due to redundancy of alerts. The compression rate may be compared to a compression parameter to determine if the number of alert groups are satisfactory.].
Regarding claim 13:
Patrich discloses, The computer-implemented method of claim 9, and
Patrich further discloses, determining if the selected alert cluster of the one or more alert clusters is associated with an increasing alert volume status or a decreasing alert volume status; [Examiner notes that claim requires only one of the elements separated by “or” and therefore only one of them is given the patentable weight.
Patrich discloses the limitation, determine if the selected alert cluster of the one or more alert clusters is associated with an increasing alert volume status as described below,
¶31: a score is calculated for sets of alerts occurring in the past on more than a predetermined number of occasions, and is rendered unknown for sets of alerts not occurring more than a predetermined number of occasions.];
outputting the alert policy change data object to the alert manager device only in circumstances…where the selected alert cluster satisfies the alert insignificance threshold. [¶31: a score is calculated for sets of alerts occurring in the past on more than a predetermined number of occasions, and is rendered unknown for sets of alerts not occurring more than a predetermined number of occasions. The output of the process is a model that contains a score for each set of alerts…
¶72: In step 418 of FIG. 4, if the score meets a predetermined criteria, an indication is provided to an administrator…if score analyzer 324 determines that a score corresponding to chain of alerts 305 (or a sub-chain of alerts) meets the predetermined criteria, user interface 334 provides a notification to a system administrator of the validated incident. The notification may be provided at a computing device of computing device(s) 140, or transmitted to a different computing device,], but doesn’t explicitly disclose, and
GUPTA’309 discloses, outputting the alert policy change data object to the alert manager device only in circumstances where the selected alert cluster is associated with the increasing alert volume status [col 14, lines 24-33: At 906, avalanche windows may be determined based on an alert count for a time window meeting or exceeding the avalanche threshold….Avalanche patterns may be based on intersections that have an intersection score that meets or exceeds an avalanche pattern threshold. Intersection scores may be determined based on number of intersections and number of avalanche window alerts.…
col 7, lines 23-26: The avalanche window module 308 may determine the avalanche windows 512/514/518 based on a total alert count 502 within each time window TW that…exceeds the avalanche threshold 506…
col 12, lines 43-45: A presentation module 324 may generate a display region for displaying the alert groups for monitoring by a user or system administrator].
Therefore, it would have been obvious to one of ordinary skill in the art before the filling date of the claimed invention to have combined the capability of outputting the alert policy change data object to the alert manager device only in circumstances where the selected alert cluster is associated with the increasing alert volume status in order to enable a user or system administrator to more efficiently manage alert dispositions by reducing the number of alerts by eliminating redundant and insignificant alerts taught by GUPTA’309 with the method taught by Patrich as discussed above in order to have reasonable expectation of success such as to enable a user or system administrator to more efficiently manage alert dispositions by reducing the number of alerts by eliminating redundant and insignificant alerts [GUPTA’309, col 13, lines 5-14: Accordingly, the alert pattern detection and alert grouping is a useful tool to enable a user or system administrator to more efficiently manage alert dispositions by reducing the number of alerts, which may have been inflated due to redundancy of alerts. The compression rate may be compared to a compression parameter to determine if the number of alert groups are satisfactory.].
Claim(s) 6 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Patrich and further in view of Banerjee et al. (US20130346594A1) [hereinafter Banerjee].
Regarding claim 6:
Patrich discloses, The alert cluster analysis apparatus of claim 1, and
Patrich further discloses, wherein determining an alert significance score for each of the one or more alert clusters comprises [¶60: In step 408, for each set of alerts, a score is determined that represents a statistical likelihood of correlation between the alerts….Score determiner 322 determines a plurality of scores for the alert sets generated by alert set generator 312. Score determiner 322 may use any suitable technique for generating the score representing statistical likelihood, such as a lift score, a correlation function, etc.], but doesn’t explicitly disclose, and
Banerjee discloses, determining a ratio between significant alerts and insignificant alerts of the one or more alert clusters. [¶119: Relationships between clusters may be manually, semi-automatically, or automatically determined based on the clustering analysis. These relationships may be generated via a classification algorithm, for example, that classifies the various clusters according to relative importance and frequency of the clusters,…Such determination of relative importance may be automatically determined based on a mathematical and/or statistical comparison of the clusters…
¶121: The importance of these clusters, relative to other clusters, may be determined in many different ways but one simple importance measure may be simply the number of members of the cluster. That is, if a cluster has a membership that meets or exceeds a predetermined threshold, then the cluster may be determined to be relatively important with regard to the other clusters that may have a membership less than the predetermined threshold, for example. Other more complex mechanisms for determining relative importance may also be utilized without departing from the spirit and scope of the illustrative embodiments.
Examiner notes that, in broadest reasonable interpretation, determining a ratio between significant alerts and insignificant alerts of the one or more alert clusters means determination of any ratio such as relative comparisons between significant/important alerts and insignificant/unimportant alerts of any of the alert clusters.
Banerjee discloses, a ratio showing relative relationships of important alerts and unimportant alerts].
Therefore, it would have been obvious to one of ordinary skill in the art before the filling date of the claimed invention to have combined the capability of outputting the alert policy change data object to the alert manager device only in circumstances where the selected alert cluster is associated with the increasing alert volume status in order to enable a user or system administrator to more efficiently manage alert dispositions by reducing the number of alerts by eliminating redundant and insignificant alerts taught by GUPTA’309 with the apparatus taught by Patrich as discussed above in order to have reasonable expectation of success such as to enable a user or system administrator to more efficiently manage alert dispositions by reducing the number of alerts by eliminating redundant and insignificant alerts [GUPTA’309, col 13, lines 5-14: Accordingly, the alert pattern detection and alert grouping is a useful tool to enable a user or system administrator to more efficiently manage alert dispositions by reducing the number of alerts, which may have been inflated due to redundancy of alerts. The compression rate may be compared to a compression parameter to determine if the number of alert groups are satisfactory.].
Regarding claim 14:
Patrich discloses, The computer-implemented method of claim 9, and
Patrich further discloses, wherein determining an alert significance score for each of the one or more alert clusters comprises [¶60: In step 408, for each set of alerts, a score is determined that represents a statistical likelihood of correlation between the alerts….Score determiner 322 determines a plurality of scores for the alert sets generated by alert set generator 312. Score determiner 322 may use any suitable technique for generating the score representing statistical likelihood, such as a lift score, a correlation function, etc.], but doesn’t explicitly disclose, and
Banerjee discloses, determining a ratio between significant alerts and insignificant alerts of the one or more alert clusters. [¶119: Relationships between clusters may be manually, semi-automatically, or automatically determined based on the clustering analysis. These relationships may be generated via a classification algorithm, for example, that classifies the various clusters according to relative importance and frequency of the clusters,…Such determination of relative importance may be automatically determined based on a mathematical and/or statistical comparison of the clusters…
¶121: The importance of these clusters, relative to other clusters, may be determined in many different ways but one simple importance measure may be simply the number of members of the cluster. That is, if a cluster has a membership that meets or exceeds a predetermined threshold, then the cluster may be determined to be relatively important with regard to the other clusters that may have a membership less than the predetermined threshold, for example. Other more complex mechanisms for determining relative importance may also be utilized without departing from the spirit and scope of the illustrative embodiments.
Examiner notes that, in broadest reasonable interpretation, determining a ratio between significant alerts and insignificant alerts of the one or more alert clusters means determination of any ratio such as relative comparisons between significant/important alerts and insignificant/unimportant alerts of any of the alert clusters.
Banerjee discloses, a ratio showing relative relationships of important alerts and unimportant alerts].
Therefore, it would have been obvious to one of ordinary skill in the art before the filling date of the claimed invention to have combined the capability of outputting the alert policy change data object to the alert manager device only in circumstances where the selected alert cluster is associated with the increasing alert volume status in order to enable a user or system administrator to more efficiently manage alert dispositions by reducing the number of alerts by eliminating redundant and insignificant alerts taught by GUPTA’309 with the method taught by Patrich as discussed above in order to have reasonable expectation of success such as to enable a user or system administrator to more efficiently manage alert dispositions by reducing the number of alerts by eliminating redundant and insignificant alerts [GUPTA’309, col 13, lines 5-14: Accordingly, the alert pattern detection and alert grouping is a useful tool to enable a user or system administrator to more efficiently manage alert dispositions by reducing the number of alerts, which may have been inflated due to redundancy of alerts. The compression rate may be compared to a compression parameter to determine if the number of alert groups are satisfactory.].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure is listed in the PTO-892 Notice of Reference Cited document mailed on 03/02/2026.
Gupta’467 et al. (US20160364467A1) - Event notification system with cluster classification:
¶17: To reduce the number of alerts generated, cluster processor 108 groups datapoints by similarity as indicated by proximity in a multi-dimensional status-parameter space.
Ranjan et al. (US20150222477A1) - Network alert pattern mining:
¶13: a plurality of network alerts is received at a device over a time frame. A sliding transaction window is used across the time frame to associate each network alert occurring within the transaction window with one or more transactions. A pruning test is applied to subsets of the plurality of network alerts, with the network alerts in a given subset being associated with the same transaction. The pruning test is based in part on the number of co-occurrences of network alerts in a given subset for different transaction windows. The subsets of network alerts are assigned to network alert clusters based on the applied pruning test. The network alerts are then joined within a network alert cluster to identify the largest grouping of network alerts that pass the pruning test. A notification that the identified grouping of network alerts is associated with the same transaction is also provided.
THIS ACTION IS MADE FINAL. 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 MOHAMMED SHAFAYET whose telephone number is (571)272-8239. The examiner can normally be reached M-F 8:30 AM-5:00 PM.
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, Kenneth Lo can be reached at (571) 272-9774. 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.
/M.S./
Patent Examiner,
Art Unit 2116
/KENNETH M LO/Supervisory Patent Examiner, Art Unit 2116
Prosecution Insights