DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-3, 5-8, 10-11, 13-14, 16, 18-25 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
At step 1, if no statutory category rejection was given above, then the claims have been determined to have a statutory category.
Referring to claim 1, at step 2a, prong one, it recites, via generic processor, receiving a plurality of alerts (including that these alerts are regarding what is experienced by a computer) stored in a first table, identifying configuration items, identifying properties of configuration items stored in a second table, receiving input to select a property, filtering the alerts based on the property selected, updating a GUI to display the filtered alerts, receiving additional input to select a remediation, and performing the remediation. As emphasized, claim 1 is recited as representative, “A method, comprising: receiving, via a processor, a plurality of alerts experienced by a computer information technology system, wherein the plurality of alerts is stored in a first table; identifying, via the processor, a plurality of respective configuration items of a computer information technology configuration management system associated with the plurality of alerts, wherein the configuration items are stored in a second table, different than the first table; identifying, via the processor, a plurality of properties of the plurality of respective configuration items stored in the second table; receiving, via the processor, an input selecting a particular property of the plurality of properties to filter the plurality of alerts; filtering, via the processor, the plurality of alerts stored in the first table based on the particular property of the plurality of properties of the plurality of respective configuration items stored in the second table; updating, via the processor, a graphical user interface (GUI) to display the filtered plurality of alerts; receiving, via the processor, an additional input selecting a remediation action to address the filtered plurality of alerts; and performing, via the processor, the selected remediation action.” Claims 19 and 20 are similar.
The limitations of receiving, identifying, identifying, receiving, filtering, and receiving, as crafted, are processes that, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of additional elements that do not integrate the judicial exception into a practical application. That is, nothing in those claim elements as emphasized preclude the steps from practically being performed in the mind, possibly with the aid pen and paper. For example, these steps perform steps of observation, evaluation, judgment, or opinion. On “separate storage” in particular, this merely further identifies a conceptual gap between data that may be retain in some manner, again possibly with the aid of pen and paper.
If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of additional elements that do not integrate the judicial exception into a practical application, then it falls within the "Mental Processes" grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
At step 2a, prong two, this judicial exception is not integrated into a practical application. In particular the claims additionally recite a generic computer, a GUI for the necessary output of data, and performing an action.
Even when viewed in combination, the additional elements in this claim do no more than automate the mental processes a person may perform, using the computer components as a tool.
Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
At step 2b, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of a generic computer, GUI, and an action amount to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using generic computer components cannot provide an inventive concept.
With respect to the generic computer, the courts have found limitations directed to generic computers, recited at a high level of generality, to be well-understood, routine, and conventional. See MPEP2106.05(d), for example TLI Communications, Flook, Alice Corp, and Versata.
With respect to the conventional GUI providing output. See for example US 20050010416 paragraph 125, US 20090150812 paragraph 3, and US 20130007655 paragraph 4.
With respect to performing an action, the courts have found limitations directed to insignificant application, recited at a high level of generality, to be well-understood, routine, and conventional. See MPEP 2106.05(g) In re Brown and Ameranth and MPEP 2106.05(d) Flook.
Considering the additional elements individually and in combination and the claim as a whole, the additional elements do not provide significantly more than the abstract idea. The claim is not patent eligible.
Further incorporating claims 2, 3, 5-8, these further describe data and observation, evaluation, judgment, or opinion.
Further referring to claim 10, this merely provides additional output to the GUI, as identified above.
Further incorporating claim 11, this merely provides additional output, albeit with an arbitrary time constraint of being in “real-time”. Without any meaningful constraints, this is simply taken to mean that available data is displayed, including when there is no data. Regarding any necessary generic computer processing that may need to take place to accomplish such a task, see above.
Further incorporating claim 13, this again provides the output of observation, evaluation, judgment, or opinion.
Further incorporating claim 14, this further describes data.
Further referring to claim 16, at step 2a prong one, Applicant further claims a GUI with an interactive filter enabling a view to be created “without leaving the GUI”. Firstly, it is not claimed what is within or without the GUI and any arbitrary grouping of elements may be considered “within” (or without) the GUI.
At step 2a prong two, this does not integrate the judicial exception into a practical application. Even when viewed in combination, the additional elements in this claim do no more than automate the output of mental processes a person may perform, using the computer components as a tool. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
At step 2b, the additional elements are not sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of an interactive filter amount to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using generic computer components cannot provide an inventive concept.
Additional elements found not to be significantly more include well understood, routine, and conventional an interactive filter. See for example US20210034633 paragraph 2, US20190138192 paragraph 35, US9489400 paragraph (1).
Considering the additional elements individually and in combination and the claim as a whole, the additional elements do not provide significantly more than the abstract idea. The claim is not patent eligible.
Further incorporating claim 18, this further describes observation, evaluation, judgment, or opinion.
Further incorporating claim 21, this further describes observation, evaluation, judgment, or opinion and the output of that observation, evaluation, judgment, or opinion to the GUI, as identified above.
Further referring to claim 22, see rejection of claim 1 above describing output to a GUI.
Further referring to claim 23, this is removing data within a time constraint, describing observation, evaluation, judgment, or opinion, perhaps involving disregard or erasure.
Further referring to claim 24, this is using the above GUI to output data.
Further referring to claim 25, this further describes data.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-3, 5-7, 10, 11, 13-14, 18-22, 25 is/are rejected under 35 U.S.C. 103 as being unpatentable over US20100131315 to Gilbert et al. and US 10469309 to Gupta et al. and US20190306009 to Makovsky et al.
Referring to claim 1, Gilbert discloses a method, comprising:
receiving, via a processor, a plurality of alerts experienced by a computer information technology system, wherein the plurality of alerts is stored in a first data structure (Paragraph 16, “Clients can use natural language text to describe incidents. Incidents that are reported can be caused, for example, by changes or events generated in the enterprise. As described herein, events are captured and stored in an event monitoring and/or management system. One or more embodiments of the present invention correlate the client incidents with the enterprise events to facilitate resolution of the incidents. Such a correlation can be performed, for example, using a configuration management database (CMDB), which stores various configuration items (CIs) along with their inter-relationships. Client incidents and events are correlated with the relevant CIs in the CMDB, and these CIs, along with their relationships, are used to compute the correlation between events and client incidents.”);
identifying, via the processor, a plurality of respective configuration items of a computer information technology configuration management system associated with the plurality of alerts, wherein the configuration items are stored in a second data structure, different than the first table (Paragraph 40, “As part of incident-CI association, one or more embodiments of the invention use incident description to extract keywords. These keywords are searched over a configuration management database (CMDB) to obtain associated CIs. A Lucene based search engine and other search techniques can be employed to make this search efficient and more accurate. All (unresolved) events can be obtained from the event server, and these CIs associated with the incident along with their relevancy scores can be denoted as ICI.sub.1, ICI.sub.2, . . . , ICI.sub.n and S.sub.1, S.sub.2, S.sub.n, respectively. One or more CIs are associated with every event using an event-search. A CI associated with the event is usually explicitly mentioned in the events or can be searched using the same technique as used for client reported incidents. For obtaining an event CI, event attributes and/or description can be searched over a CMDB and a resultant CI can be obtained.” Further see figure 5 and paragraphs 16 and 40 on the “difference” of these data structures.);
identifying, via the processor, a plurality of properties of the plurality of respective configuration items stored in the second data structure (Paragraph 44, “If ECI, for an event, is a dependent CI of any of ICI.sub.i for 1.ltoreq.i.ltoreq.n, that event is correlated with the incident. This dependence can be defined using CMDB relationships. An ECI is dependent on ICI if ECI and ICI are related using one or more relationships, directly or indirectly.”);
receiving, via the processor, an input selecting a particular property of the plurality of properties to filter the plurality of alerts; filtering, via the processor, the plurality of alerts stored in the first data structure based on the particular property of the plurality of properties of the plurality of respective configuration items stored in the second data structure (Paragraph 42, 43, “A list of events correlated with the client incident can be obtained by comparing an incident search result (ICIs) with the event search result (ECI or explicitly mentioned CI) using various intuitions including: If ECI, for an event, is the same as any of ICI.sub.i (for 1.ltoreq.i.ltoreq.n) for the incident then one can say that the event is correlated with the incident.”).
Although Gilbert does not explicitly disclose that the data structures may be tables, storing data in a table is very well known in the art. In a related field of computing, an example of this is shown by Gupta, line 36 of column 6, “FIG. 4 is a block diagram of an example alert table in accordance with the present disclosure. The alert information for the historical alert data 302 may be stored as an alert table 404 as shown in FIG. 4, in a data storage unit 402. For each alert, the alert table 404 may include an alert ID 412, a time stamp 414, a configuration item (CI) ID 416, and an alert metric 418. For example, when an event triggers an alert, each alert may be recorded and stored in the data storage unit 402 with alert information including the time stamp 414 of when the alert was triggered, a CI ID 416 for the identity of the CI affected by the event, and the alert metric 418 that triggered the alert, which may include for example, high memory utilization or high CPU utilization. In some applications, an alert metric 418 for high memory utilization may be an indication that an additional server is needed to handle the current traffic or demand for services by clients 112 in the cloud computing system 100.” It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to store data in a table because, as shown by Gupta, it provides a specific format for data to be stored and organized for retrieval.
Although Gilbert does not explicitly disclose updating, via the processor, a graphical user interface (GUI) to display the filtered plurality of alerts, outputting data to a GUI is known in the art. In a related field of computing, an example of this is shown by Gupta, abstract, “An apparatus for grouping alerts generated by automated monitoring of at least an operating condition of a machine, represented as a configuration item in a configuration management database, in a computer network. A first event pattern is identified based on configuration items associated with an alert avalanche identified from received historical alert data stored in memory. A second event pattern is identified based on co-occurrences of configuration item pairs in the historical alert data and on at least one conditional probability parameter. At least one alert group is determined by comparing at least one configuration item associated with a current alert to the plurality of configuration items of the first event pattern and of the second event pattern stored in memory. A graphical display region for displaying the alert group is generated.” Further, from line 28 of column 13, “FIG. 8 is a diagram of an example display region generated for enabling user feedback and supervision of alert grouping in accordance with the present disclosure. In some applications, if the compression rate Comp or alert coverage Acov values do not meet the parameter thresholds, the user or system administrator may delete a group using a graphical user interface, such as the delete alert button 809. The display region 802 may include various alert information for an alert group 803, as shown in FIG. 8. For example, impacted services may be visually accessed by clicking on the impacted services button 804. Feedback 806 from the user may be submitted to a system administrator regarding whether the alert group is representative or related to new alerts. For example, due to irregularities in the pattern detection, some alert groups may be determined to be invalid, in which case the user has the ability to delete the alert group using interface button 809. The display region 802 may also include the alert ID 810, severity of each alert 812, the CI_ID 814, the metric name 816, or a combination thereof, for the alerts in the displayed alert group. In some applications, if an erroneous group repeatedly appears, the user or system administrator may set a rule to prevent particular patterns from being developed by the avalanche pattern detection module 304 or the conditional probability pattern detection module 314. In some applications, the user or system administrator may define patterns and can set a high priority of those patterns if so desired. For instance, a particular alert or entity may be flagged as significant or critical and an associated pattern may be assigned a high priority.” It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to display via a GUI because, as shown by Gupta, this enables user feedback and supervision.
Although Gilbert and Gupta do not specifically disclose receiving, via the processor, an additional input selecting a remediation action to address the filtered plurality of alerts; and performing, via the processor, the selected remediation action, conditional remedial action is known in the art. In a related field of computing, an example of this is shown by Makovksy, from the abstract, “The client instance is also configured to: evaluate at least one condition of the alert rule using the context of the first and/or second alert; and in response to evaluating the at least one condition of the alert rule to be true, performing at least one action of the alert rule using the context of the first and/or second alert.” Further from paragraph 41, “In certain embodiments, the one or more alert rule actions of an alert rule include external alert rule actions. As used herein, “external” refers to actions of the client instance that are outside of the alert portion of the system. In certain embodiments, these external actions include launching one or more application(s), such as an interactive user interface or launcher. The external actions may include running one or more remediations, which may be interactive or may execute in the background. In certain embodiments, the external action can include opening a new incident (INT), change (CHG), or problem (PRB) in the CMDB, immediately or with a predetermined delay. The external action may include conditionally updating an existing INT/CHG/PRB, such as assigning it to a group. For example, the external actions may include escalating, merging, or conditionally auto-closing INTs/CHGs/PRBs based on alert context. External actions may also include sending an email, creating an alert task, executing a script or workflow, updating a service level agreement (SLA), creating outage records, or running a discovery operation (e.g., horizontal, top down). In certain embodiments, external actions include changing a service status, opening a chat dialog in a messaging tool, and updating CI attributes. External actions may also include making Hypertext Transfer Protocol (HTTP) or Hypertext Transfer Protocol Secure (HTTPS) calls that are not associated with the GUI, as well as updating data source (e.g., update system center operation manager (SCOM) with a parameter from the alert).” It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to select and perform a remedy because, as disclosed by Makovksy, paragraph 5, “Within the context of cloud computing solutions for CMDBs, users may be asked to deal with ever increasing amounts of data, e.g., with respect to the number of Configuration Items (CIs) stored in the CMDB (including such CIs' relevant metadata, such as manufacturer, vendor, location, etc.), as well as the alerts, service metrics, and maintenance status information related to such CIs. In fact, the amount of data collected and stored in today's cloud computing solutions, such as CMDBs, may be orders of magnitude greater than what was historically collected and stored. Users tasked with automating and/or troubleshooting enterprise, IT, and/or other organization-related functions (e.g., incident tracking and/or help desk-related functions) navigate ever increasing amounts of data to properly and efficiently perform their job functions. In particular, CMDBs may generate hundreds or thousands of alerts in a brief period of time, and users may want to define complex, automatic responses to these alerts. With this in mind, the following embodiments are directed to improving the manner in which alerts are managed within the CMDB, as well as the manner in which the user interfaces with the alert management system, in order to provide an enhanced user experience.” Further, Gilbert explicitly contemplated that such correlation may be used for steps of remedy, from paragraph 16, “…One or more embodiments of the present invention correlate the client incidents with the enterprise events to facilitate resolution of the incidents. …”
Referring to claim 2, Gilbert and Gupta and Makovsky discloses wherein identifying the plurality of respective configuration items of the computer information technology configuration management system associated with the plurality of alerts includes: determining a relationship between a particular alert of the plurality of alerts and a particular configuration item of the plurality of respective configuration items; and determining a relationship between the particular alert and an application service (Gilbert, paragraph 40, “As part of incident-CI association, one or more embodiments of the invention use incident description to extract keywords. These keywords are searched over a configuration management database (CMDB) to obtain associated CIs. A Lucene based search engine and other search techniques can be employed to make this search efficient and more accurate. All (unresolved) events can be obtained from the event server, and these CIs associated with the incident along with their relevancy scores can be denoted as ICI.sub.1, ICI.sub.2, . . . , ICI.sub.n and S.sub.1, S.sub.2, S.sub.n, respectively. One or more CIs are associated with every event using an event-search. A CI associated with the event is usually explicitly mentioned in the events or can be searched using the same technique as used for client reported incidents. For obtaining an event CI, event attributes and/or description can be searched over a CMDB and a resultant CI can be obtained.” Paragraph 42-45, “A list of events correlated with the client incident can be obtained by comparing an incident search result (ICIs) with the event search result (ECI or explicitly mentioned CI) using various intuitions including: If ECI, for an event, is the same as any of ICI.sub.i (for 1.ltoreq.i.ltoreq.n) for the incident then one can say that the event is correlated with the incident. If ECI, for an event, is a dependent CI of any of ICI.sub.i for 1.ltoreq.i.ltoreq.n, that event is correlated with the incident. This dependence can be defined using CMDB relationships. An ECI is dependent on ICI if ECI and ICI are related using one or more relationships, directly or indirectly. For efficient implementation, dependence between an ECI and ICIs can be defined using template (such as shown in FIG. 6). According to such a template, if ECI is a Database then its dependent ICIs include all CIs of type WebSphere Application Server related to the ECI using runsOn relationship and WWER and LiveCore applications deployedTo the related WebSphere Application Server ICIs.”).
Referring to claim 3, Gilbert and Gupta and Makovsky discloses wherein the particular property of the plurality of properties of the plurality of respective configuration items includes an application service and the filtering the plurality of alerts includes filtering by impacted application service (Gilbert paragraph 42-45, “A list of events correlated with the client incident can be obtained by comparing an incident search result (ICIs) with the event search result (ECI or explicitly mentioned CI) using various intuitions including: If ECI, for an event, is the same as any of ICI.sub.i (for 1.ltoreq.i.ltoreq.n) for the incident then one can say that the event is correlated with the incident. If ECI, for an event, is a dependent CI of any of ICI.sub.i for 1.ltoreq.i.ltoreq.n, that event is correlated with the incident. This dependence can be defined using CMDB relationships. An ECI is dependent on ICI if ECI and ICI are related using one or more relationships, directly or indirectly. For efficient implementation, dependence between an ECI and ICIs can be defined using template (such as shown in FIG. 6). According to such a template, if ECI is a Database then its dependent ICIs include all CIs of type WebSphere Application Server related to the ECI using runsOn relationship and WWER and LiveCore applications deployedTo the related WebSphere Application Server ICIs.”).
Referring to claim 5, Gilbert and Gupta and Makovsky discloses wherein an alert of the plurality of alerts includes a key-value pair (Gilbert paragraph 40-46, “As part of incident-CI association, one or more embodiments of the invention use incident description to extract keywords. These keywords are searched over a configuration management database (CMDB) to obtain associated CIs. A Lucene based search engine and other search techniques can be employed to make this search efficient and more accurate. All (unresolved) events can be obtained from the event server, and these CIs associated with the incident along with their relevancy scores can be denoted as ICI.sub.1, ICI.sub.2, . . . , ICI.sub.n and S.sub.1, S.sub.2, S.sub.n, respectively. One or more CIs are associated with every event using an event-search. A CI associated with the event is usually explicitly mentioned in the events or can be searched using the same technique as used for client reported incidents. For obtaining an event CI, event attributes and/or description can be searched over a CMDB and a resultant CI can be obtained. A CI comparator can take input such as, for example, results of an incident-search (for example, a list of CIs with their relevancy scores (denoted as ICI.sub.1, ICI.sub.2, . . . , ICI.sub.n and S.sub.1, S.sub.2, . . . , S.sub.n, respectively)) as well as results of an event-search (for example, a CI (such as, for example, ECI)). Also, a CI comparator can include output such as, for example, a list of events with their relevance score. A list of events correlated with the client incident can be obtained by comparing an incident search result (ICIs) with the event search result (ECI or explicitly mentioned CI) using various intuitions including: If ECI, for an event, is the same as any of ICI.sub.i (for 1.ltoreq.i.ltoreq.n) for the incident then one can say that the event is correlated with the incident. If ECI, for an event, is a dependent CI of any of ICI.sub.i for 1.ltoreq.i.ltoreq.n, that event is correlated with the incident. This dependence can be defined using CMDB relationships. An ECI is dependent on ICI if ECI and ICI are related using one or more relationships, directly or indirectly. For efficient implementation, dependence between an ECI and ICIs can be defined using template (such as shown in FIG. 6). According to such a template, if ECI is a Database then its dependent ICIs include all CIs of type WebSphere Application Server related to the ECI using runsOn relationship and WWER and LiveCore applications deployedTo the related WebSphere Application Server ICIs. For increasing precision of the resultant events, one can only present events that have occurred before the incident or in recent past. Also, by way of example, an event is a more likely cause if the event is still unresolved, if the time difference between incident and event is low and/or the score of ICIk, which is dependent on the ECI, is high.”).
Referring to claim 6, Gilbert and Gupta and Makovsky discloses wherein the key-value pair includes a single key associated with a plurality of values (Gilbert paragraph 40-46, “As part of incident-CI association, one or more embodiments of the invention use incident description to extract keywords. These keywords are searched over a configuration management database (CMDB) to obtain associated CIs. A Lucene based search engine and other search techniques can be employed to make this search efficient and more accurate. All (unresolved) events can be obtained from the event server, and these CIs associated with the incident along with their relevancy scores can be denoted as ICI.sub.1, ICI.sub.2, . . . , ICI.sub.n and S.sub.1, S.sub.2, S.sub.n, respectively. One or more CIs are associated with every event using an event-search. A CI associated with the event is usually explicitly mentioned in the events or can be searched using the same technique as used for client reported incidents. For obtaining an event CI, event attributes and/or description can be searched over a CMDB and a resultant CI can be obtained. A CI comparator can take input such as, for example, results of an incident-search (for example, a list of CIs with their relevancy scores (denoted as ICI.sub.1, ICI.sub.2, . . . , ICI.sub.n and S.sub.1, S.sub.2, . . . , S.sub.n, respectively)) as well as results of an event-search (for example, a CI (such as, for example, ECI)). Also, a CI comparator can include output such as, for example, a list of events with their relevance score. A list of events correlated with the client incident can be obtained by comparing an incident search result (ICIs) with the event search result (ECI or explicitly mentioned CI) using various intuitions including: If ECI, for an event, is the same as any of ICI.sub.i (for 1.ltoreq.i.ltoreq.n) for the incident then one can say that the event is correlated with the incident. If ECI, for an event, is a dependent CI of any of ICI.sub.i for 1.ltoreq.i.ltoreq.n, that event is correlated with the incident. This dependence can be defined using CMDB relationships. An ECI is dependent on ICI if ECI and ICI are related using one or more relationships, directly or indirectly. For efficient implementation, dependence between an ECI and ICIs can be defined using template (such as shown in FIG. 6). According to such a template, if ECI is a Database then its dependent ICIs include all CIs of type WebSphere Application Server related to the ECI using runsOn relationship and WWER and LiveCore applications deployedTo the related WebSphere Application Server ICIs. For increasing precision of the resultant events, one can only present events that have occurred before the incident or in recent past. Also, by way of example, an event is a more likely cause if the event is still unresolved, if the time difference between incident and event is low and/or the score of ICIk, which is dependent on the ECI, is high.”).
Referring to claim 7, Gilbert and Gupta and Makovsky discloses wherein filtering, via the processor, the plurality of alerts stored in the first table based on the particular property of the plurality of properties of the plurality of respective configuration items stored in the second table includes using data stored across a plurality of tables (See Gilbert’s data structures in view of Gupta’s tables, above).
Referring to claim 10, Gilbert discloses a result associated with the filtering of the alerts based on a property of the configuration items (see above). Gupta further discloses this can be provided via a graphical user interface with an alert panel including a summary of the plurality of alerts and at least one insight associated with the plurality of alerts (Gupta, abstract, “An apparatus for grouping alerts generated by automated monitoring of at least an operating condition of a machine, represented as a configuration item in a configuration management database, in a computer network. A first event pattern is identified based on configuration items associated with an alert avalanche identified from received historical alert data stored in memory. A second event pattern is identified based on co-occurrences of configuration item pairs in the historical alert data and on at least one conditional probability parameter. At least one alert group is determined by comparing at least one configuration item associated with a current alert to the plurality of configuration items of the first event pattern and of the second event pattern stored in memory. A graphical display region for displaying the alert group is generated.” Further, from line 28 of column 13, “FIG. 8 is a diagram of an example display region generated for enabling user feedback and supervision of alert grouping in accordance with the present disclosure. In some applications, if the compression rate Comp or alert coverage Acov values do not meet the parameter thresholds, the user or system administrator may delete a group using a graphical user interface, such as the delete alert button 809. The display region 802 may include various alert information for an alert group 803, as shown in FIG. 8. For example, impacted services may be visually accessed by clicking on the impacted services button 804. Feedback 806 from the user may be submitted to a system administrator regarding whether the alert group is representative or related to new alerts. For example, due to irregularities in the pattern detection, some alert groups may be determined to be invalid, in which case the user has the ability to delete the alert group using interface button 809. The display region 802 may also include the alert ID 810, severity of each alert 812, the CI_ID 814, the metric name 816, or a combination thereof, for the alerts in the displayed alert group. In some applications, if an erroneous group repeatedly appears, the user or system administrator may set a rule to prevent particular patterns from being developed by the avalanche pattern detection module 304 or the conditional probability pattern detection module 314. In some applications, the user or system administrator may define patterns and can set a high priority of those patterns if so desired. For instance, a particular alert or entity may be flagged as significant or critical and an associated pattern may be assigned a high priority.”
Referring to claim 11, Gilbert and Gupta and Makovsky discloses the graphical user interface displays a list of the plurality of alerts in real-time (Gupta, line 6 of column 3, “When a significant condition or event occurs that affects multiple devices in the cloud computing system, a cluster or “avalanche” of alerts may be triggered within a short time period. Over time, as avalanches of alerts are detected, patterns of affected nodes may emerge, which can be stored and used as a template during real time monitoring of alerts. As a current alert is detected, it may be matched to learned patterns for aggregating the alert into one or more alert groups to more efficiently manage and dispatch the alert. Conditional probability patterns may also be developed based on stored alert information, which may further refine the learned patterns for the alert grouping. By aggregating alerts, system operators may more efficiently triage alerts for disposition.”).
Referring to claim 13, Gilbert and Gupta and Makovsky discloses the graphical user interface displays a group of alerts, from the plurality of alerts, identified to be correlated with each other (Gupta, abstract, “An apparatus for grouping alerts generated by automated monitoring of at least an operating condition of a machine, represented as a configuration item in a configuration management database, in a computer network. A first event pattern is identified based on configuration items associated with an alert avalanche identified from received historical alert data stored in memory. A second event pattern is identified based on co-occurrences of configuration item pairs in the historical alert data and on at least one conditional probability parameter. At least one alert group is determined by comparing at least one configuration item associated with a current alert to the plurality of configuration items of the first event pattern and of the second event pattern stored in memory. A graphical display region for displaying the alert group is generated.”).
Referring to claim 14, Gilbert and Gupta and Makovsky discloses the particular property of the plurality of properties of the plurality of respective configuration items includes being a member of the group of alerts (Gupta, abstract, “An apparatus for grouping alerts generated by automated monitoring of at least an operating condition of a machine, represented as a configuration item in a configuration management database, in a computer network. A first event pattern is identified based on configuration items associated with an alert avalanche identified from received historical alert data stored in memory. A second event pattern is identified based on co-occurrences of configuration item pairs in the historical alert data and on at least one conditional probability parameter. At least one alert group is determined by comparing at least one configuration item associated with a current alert to the plurality of configuration items of the first event pattern and of the second event pattern stored in memory. A graphical display region for displaying the alert group is generated.”).
Referring to claim 18, Gilbert and Gupta and Makovsky discloses wherein identifying, via the processor, the plurality of respective configuration items of the computer information technology configuration management system associated with the plurality of alerts is performed in response to receiving the plurality of alerts or according to a pre-determined schedule (Gilbert paragraph 16, “Clients can use natural language text to describe incidents. Incidents that are reported can be caused, for example, by changes or events generated in the enterprise. As described herein, events are captured and stored in an event monitoring and/or management system. One or more embodiments of the present invention correlate the client incidents with the enterprise events to facilitate resolution of the incidents. Such a correlation can be performed, for example, using a configuration management database (CMDB), which stores various configuration items (CIs) along with their inter-relationships. Client incidents and events are correlated with the relevant CIs in the CMDB, and these CIs, along with their relationships, are used to compute the correlation between events and client incidents.”).
Referring to claims 19 and 20, see rejection of claim 1.
Referring to claim 21, Gilbert and Gupta and Makovsky discloses receiving, via the processor, an additional input selecting an additional particular property of the plurality of properties to filter the plurality of alerts; and filtering, via the processor, the plurality of alerts stored in the first table based on the particular property and the additional particular property of the plurality of properties of the plurality of respective configuration items stored in the second table (Gilbert paragraph 42-45, “A list of events correlated with the client incident can be obtained by comparing an incident search result (ICIs) with the event search result (ECI or explicitly mentioned CI) using various intuitions including: If ECI, for an event, is the same as any of ICI.sub.i (for 1.ltoreq.i.ltoreq.n) for the incident then one can say that the event is correlated with the incident. If ECI, for an event, is a dependent CI of any of ICI.sub.i for 1.ltoreq.i.ltoreq.n, that event is correlated with the incident. This dependence can be defined using CMDB relationships. An ECI is dependent on ICI if ECI and ICI are related using one or more relationships, directly or indirectly. For efficient implementation, dependence between an ECI and ICIs can be defined using template (such as shown in FIG. 6). According to such a template, if ECI is a Database then its dependent ICIs include all CIs of type WebSphere Application Server related to the ECI using runsOn relationship and WWER and LiveCore applications deployedTo the related WebSphere Application Server ICIs.”); and
updating, via the processor, the GUI to display the plurality of alerts filtered based on the particular property and the additional property of the plurality of properties of the plurality of respective configuration items stored in the second table (Gupta, abstract, “An apparatus for grouping alerts generated by automated monitoring of at least an operating condition of a machine, represented as a configuration item in a configuration management database, in a computer network. A first event pattern is identified based on configuration items associated with an alert avalanche identified from received historical alert data stored in memory. A second event pattern is identified based on co-occurrences of configuration item pairs in the historical alert data and on at least one conditional probability parameter. At least one alert group is determined by comparing at least one configuration item associated with a current alert to the plurality of configuration items of the first event pattern and of the second event pattern stored in memory. A graphical display region for displaying the alert group is generated.” Further, from line 28 of column 13, “FIG. 8 is a diagram of an example display region generated for enabling user feedback and supervision of alert grouping in accordance with the present disclosure. In some applications, if the compression rate Comp or alert coverage Acov values do not meet the parameter thresholds, the user or system administrator may delete a group using a graphical user interface, such as the delete alert button 809. The display region 802 may include various alert information for an alert group 803, as shown in FIG. 8. For example, impacted services may be visually accessed by clicking on the impacted services button 804. Feedback 806 from the user may be submitted to a system administrator regarding whether the alert group is representative or related to new alerts. For example, due to irregularities in the pattern detection, some alert groups may be determined to be invalid, in which case the user has the ability to delete the alert group using interface button 809. The display region 802 may also include the alert ID 810, severity of each alert 812, the CI_ID 814, the metric name 816, or a combination thereof, for the alerts in the displayed alert group. In some applications, if an erroneous group repeatedly appears, the user or system administrator may set a rule to prevent particular patterns from being developed by the avalanche pattern detection module 304 or the conditional probability pattern detection module 314. In some applications, the user or system administrator may define patterns and can set a high priority of those patterns if so desired. For instance, a particular alert or entity may be flagged as significant or critical and an associated pattern may be assigned a high priority.”).
Referring to claim 22, Gilbert and Gupta and Makovsky discloses generating, via the processor, the GUI configured to display the plurality of alerts (Gupta, abstract, “An apparatus for grouping alerts generated by automated monitoring of at least an operating condition of a machine, represented as a configuration item in a configuration management database, in a computer network. A first event pattern is identified based on configuration items associated with an alert avalanche identified from received historical alert data stored in memory. A second event pattern is identified based on co-occurrences of configuration item pairs in the historical alert data and on at least one conditional probability parameter. At least one alert group is determined by comparing at least one configuration item associated with a current alert to the plurality of configuration items of the first event pattern and of the second event pattern stored in memory. A graphical display region for displaying the alert group is generated.” Further, from line 28 of column 13, “FIG. 8 is a diagram of an example display region generated for enabling user feedback and supervision of alert grouping in accordance with the present disclosure. In some applications, if the compression rate Comp or alert coverage Acov values do not meet the parameter thresholds, the user or system administrator may delete a group using a graphical user interface, such as the delete alert button 809. The display region 802 may include various alert information for an alert group 803, as shown in FIG. 8. For example, impacted services may be visually accessed by clicking on the impacted services button 804. Feedback 806 from the user may be submitted to a system administrator regarding whether the alert group is representative or related to new alerts. For example, due to irregularities in the pattern detection, some alert groups may be determined to be invalid, in which case the user has the ability to delete the alert group using interface button 809. The display region 802 may also include the alert ID 810, severity of each alert 812, the CI_ID 814, the metric name 816, or a combination thereof, for the alerts in the displayed alert group. In some applications, if an erroneous group repeatedly appears, the user or system administrator may set a rule to prevent particular patterns from being developed by the avalanche pattern detection module 304 or the conditional probability pattern detection module 314. In some applications, the user or system administrator may define patterns and can set a high priority of those patterns if so desired. For instance, a particular alert or entity may be flagged as significant or critical and an associated pattern may be assigned a high priority.”).
Referring to claim 25, Gilbert and Gupta and Makovsky discloses wherein at least one alert of the plurality of alerts identifies an affected service (Gilbert, paragraph 21-23, “As detailed herein, a system event can be defined as any significant change in the state of an enterprise system resource, network resource, or network application. For example, one can generate an event for a problem, for the resolution of a problem, or for the successful completion of a task. Examples of events can include normal starting and stopping of a process, abnormal process termination, server malfunction, etc. Events are generated and managed by various event management systems. FIG. 3 is a diagram illustrating an exemplary event generation process, according to an embodiment of the present invention. By way of illustration, FIG. 3 depicts a monitored source 302, an adapter 304 (that can include, for example, a .conf file to configure the event generation and setting event attributes; and an .xml file to specify correlation engine to filter and correlate events at adaptors before forwarding them to an event server), an event server 306 (that can include, for example, a baroc file to classify events to a particular event class and an .rls file to process the events and to fire some actions, such as enriching an event or changing event criticality or deciding the operator this event has to be assigned to, etc.) that distributes events to event consoles 308, an event database 310 and other applications 312. As such, FIG. 3 depicts the parsing of log files of managed resources and the generating of events of configured classes. Also, an event server manages events via sending them to appropriate users, and correlating multiple events, etc.” Further, paragraph 40, “As part of incident-CI association, one or more embodiments of the invention use incident description to extract keywords. These keywords are searched over a configuration management database (CMDB) to obtain associated CIs. A Lucene based search engine and other search techniques can be employed to make this search efficient and more accurate. All (unresolved) events can be obtained from the event server, and these CIs associated with the incident along with their relevancy scores can be denoted as ICI.sub.1, ICI.sub.2, . . . , ICI.sub.n and S.sub.1, S.sub.2, S.sub.n, respectively. One or more CIs are associated with every event using an event-search. A CI associated with the event is usually explicitly mentioned in the events or can be searched using the same technique as used for client reported incidents. For obtaining an event CI, event attributes and/or description can be searched over a CMDB a