Methods and systems for generating alerts and situation reports

Abstract

A report generator produces reports during an identified event and these reports are transformed into editable reports that can be auto-updated with newly acquired data in any format selected by a user. The reports can be downloaded or shared in an collaboration application in a selected format, such as PDF, or included as or within forms provided in a system for tracking and providing information about an incident. Alert messages and updated reports may be generated and sent to certain recipients based on monitoring selected data sources for data defined alert trigger thresholds, as well as when event category or severity change. Alert checks are run based on a selected refresh cadence in which datasets from assocaited data sources are assessed based on the trigger content and defined area of interest. Duplicate alerts are avoided by comparing data from all previous alert checks for the same event types.

Description

METHODS AND SYSTEMS FOR GENERATING ALERTS AND SITUATION REPORTSRELATED APPLICATION DATA

[0001] This application claims the benefit of priority of U.S. Provisional Patent Application Serial No. 63 / 635,155, filed April 17, 2024, and titled “Methods and Systems For Automatic Generation of Situation Reports,” which is incorporated by reference herein in its entirety.FIELD OF THE DISCLOSURE

[0002] The present disclosure generally relates to the field of the preparation of situation reports. In particular, the present disclosure is directed to systems and methods for providing automatically generated alert messages and situation reports.BACKGROUND

[0003] It can be critical in many circumstances that situation reports are not only produced in a timely manner and kept up to date. In current systems, situation reports are often not editable or difficult to edit, which results in sometimes significant delays before up-to-date information is included. There is a need for an efficient and accurate technique for generating situation reports.SUMMARY OF THE DISCLOSURE

[0004] A method for setting up, assessing the need for, generating, and sending event alerts includes receiving input from a user to prepare an event alert configuration, the input including an event type, an area, a list of recipients, a time window, and a refresh cadence; associating one or more triggers with the event alert configuration, wherein each of the one or more triggers includes a string of text defining a trigger threshold; assigning one or more data sources to each of the one or more triggers; specifying a severity level for each of the one or more triggers; associating one or more critical information requirements (CIR) with the event alert configuration, wherein each of the one or more CIR include information fields for information to retrieve and include in the CIR when an event alert is triggered for the event alert configuration; specifying one or more data sources for each of the one or more CIR; retrieving data from the data sources associated with each of the one or more triggers during the time window at the refresh cadence; determining for each of the one or more triggers, based on the trigger threshold and alert check data of the retrieved data from one or more data sources assigned to the trigger, whether the trigger threshold is met; comparing the event run data to prior event run data associated with any instances having a same event type to determine whether the alert check data is indicative of a new instance; creating an instance identification for anew instance if the alert check data is indicative of a new instance and tagging the alert check data with an instance identification of a prior instance if the alert check data is not indicative of a new instance; generating an alert message if the trigger threshold is met and the alert check data is indicative of a new instance, the alert message including information for each of the one or more triggers for which the trigger threshold is met; and retrieving, if the trigger threshold is not met or if the alert check data is not indicative of a new instance, data from the data sources associated with each of the one or more triggers at a time determined by the refresh cadence.

[0005] Additionally or alternatively, the retrieved data is filtered based on the defined area for the event alert configuration.

[0006] Additionally or alternatively, the alert message is sent to one or more recipients on the list of recipients if the trigger threshold is met and the alert check data is indicative of a new instance.

[0007] Additionally or alternatively, the list of recipients includes an alert severity notification level associated with one or more recipient on the list of recipients.

[0008] Additionally or alternatively, the sending the alert message includes sending the alert message to each recipient for which the associated alert severity notification level matches the severity level for any of the triggered triggers.

[0009] Additionally or alternatively,, when the alert check data is not indicative of a new instance, it is determined whether the severity level of the instance has changed since the alert message was sent by comparing the severity level based on the current run event data and the prior run event data, and sending an updated alert message if the severity level has increased to one or more recipient of the list of recipients.

[0010] Additionally or alternatively, the updated alert message is sent to the one or more recipient of the list of recipients for which the associated alert severity notification level matches the increased severity level.

[0011] Additionally or alternatively, an event report is generated when the trigger threshold is met and the alert check data is indicative of a new instance, wherein the event report includes a section for each of the one or more CIR.

[0012] Additionally or alternatively, each section of the event report includes information from the one or more data sources associated with the respective one or more CIR each section is for.

[0013] Additionally or alternatively, the event report is updated when the trigger threshold is met and the alert check data is not indicative of a new instance, wherein the updated event report includes any information that is different from information in an immediately preceding version of the event report.

[0014] Additionally or alternatively, the updated information in the updated event report is visually distinguishable from information that was also in the immediately preceding version of the event report.

[0015] Additionally or alternatively, an alert message is not sent to any recipients on the list of recipients when the trigger threshold is met and the alert check data is not indicative of a new instance during a refresh cadence period.BRIEF DESCRIPTION OF THE DRAWINGS

[0016] For the purpose of illustrating the disclosure, the drawings show aspects of one or more embodiments of the disclosure. However, it should be understood that the present disclosure is not limited to the precise arrangements and instrumentalities shown in the drawings, wherein:FIG. 1 is a process diagram for generating situation reports in accordance with an embodiment of the present disclosure;FIG. 2 is a process diagram for setting up an event alert configuration in accordance with an embodiment of the present disclosure; andFIG. 3 is a process diagram for monitoring for event triggers and preparing alert messages and reports in accordance with an embodiment of the present disclosure.DETAILED DESCRIPTION

[0017] A report generator is provided that produces informational reports during an identified event or incident and these reports are transformed into editable reports that can be auto-updated with newly acquired data in any format selected by a user. The reports can be downloaded or shared in an collaboration application in a selected format, such as PDF, or included as or within forms provided in a system for tracking and providing information about an incident.

[0018] For a given a declared event, such as may occur when there is a flood warning, relevant data is gathered, such as the event declaration, current and forecast weather information, power outages and predictions, news, and social media. This data is sent to the report generator for analysis, which is a large language model. Users are able to view the generated reports on a platform or have the reports sent via alerts as soon as they are created.

[0019] Once created, these reports may be updated as new relevant information becomes available. In an embodiment, a system for updating situation reports includes schemas, which are provided for each dataset and function essentially as dictionary entries that can be accessed and used by a large language model to understand the meaning, purpose, and wording of each data item that the model works with. For example, data labeled “list.main.feelsjike” may be defined in the schema to mean “This temperature parameter accounts for the human perception of weather.”

[0020] Prompt engineering is used to provide high level instructions for a program, such as a large language model (LLM) to summarize datasets according to the context (described below), the search text (described below), if applicable, and the data itself. The prompt engineering ensures the results are succinct, informative, and relevant to the context of the auto-generated situation report. Additionally, prompt engineering is used to instruct the LLM towards the desired behavior for subsequent queries to use the user-formatted text and only update the report with new information while not changing the format of the text in the auto-generated situation report. Prompt engineering includes prepending requests for subsequent information with instructional text informing the LLM of the constraints of the request. For example, the instructional text may be “only respond to the query with regards to the relevant data source”. In addition, further direction may be provided by including text such as “Structure the response to be succinct and directly relevant to the query, and provide references to the data used for analysis.”

[0021] A context for the auto-generated situation report is defined and used to assist in the determination of relevant information. A context type could be an Area of Responsibility (AOR). The AOR may be user-defined, with examples being a facility, a military installation, a city, a state, or a laboratory. This way, the LLM understands the summarization should focus on what would be relevant for that AOR, and not as a generic summary of the data.

[0022] An initial summarization requires a context to best fit the results of the auto-generated situation report. A declared event may include as a named hurricane, a flood warning alerted by theNational Weather Service, or an earthquake reported by the US Geological Survey. A declared event may be used as the context for the auto-generated situation report so that the LLM understands that the summarizations should have relevance to the declared event. For example, if the event is a hurricane, the LLM is more likely to report relevant conditions such as wind speed. Events are tracked in the system as being declarations from authoritative sources, such as government agencies like the National Weather Service, via their APIs. Instead of making an AOR the context of the automatic situation report, that event itself (i.e., the data from the API) can be the basis for an automatic situation report. For example, a hurricane could impact multiple AORs in a given area, so it would be helpful to have automatic situation reports providing situation awareness about that hurricane and anything related to it, rather than just the relevance to a given AOR.

[0023] A data source may require a search text to fetch relevant information. For example, searching for news, social media, or web (i.e., search engine) sources for information relating to a given situation (such as an active hurricane or the collapse of a bridge), starts with a string of text used to initiate the search for that data source. Including that search text, when appropriate, helps guide the LLM in extracting the resultant data, and assists with summarization. Search text can be any words or phrases that provide additional guidance, such as “Hazards, threats, or risks associated with {Name of AOR or Hurricane}”.

[0024] An initial user interface (UI) may be used for viewing the initial auto-generated situation report, which is created in context of an AOR or event. The user interface allows the user to input clarifying questions of the system, which it either answers from its provided real-time dataset, or does a web lookup and analyzes results.

[0025] The UI element may be downloaded as PDF in markdown format. The UI element may be used to create an initial incident report from the auto-generated situation report. The autogenerated situation report in the initial incident brief may be its own module, instead of only a text area on the initial incident report.

[0026] The auto-generated situation report may include an editor UI, which allows users to format data as desired for subsequent auto-updates. For example, if a part of the LLM summary of news includes a statement such as “There were four fatalities,” a user may wish that to read “Four fatalities have been reported.” That way, when an update is performed, the LLM can use the formatted data as a structure for the summary, by replacing older data with newer data, whileretaining the format of the text as defined by the user. The editor UI is organized into sections so that it is easier for the system to reformat with new data, and also allows for things like tear-lines to manage role-based access. Sections may include an auto-update, which may be for power outages, news, and social media, for example, a user-update for manual entry that can fill gaps with data not entered, and situation awareness that includes data in platform, such as objectives, actions, or resources. A document of the UI may be downloaded in a format such as PDF and exported to a collaboration application.

[0027] As outlined in FIG. 1, a situation report generator 100 is provided for preparing, updating, and sending reports based on events. The report generator may include a large language model (LLM) or other programming as well as data storage components and processors for receiving and sending data from data sources and users. The generator fetches real-time data (including for events at step 106) from various sources 104, which may include direct data sources for instances in which a curated data source is used (at step 108), such as for power outages or weather information, and receives data providing real-time context, such as for identified events. For non-curated data sources, the real-time data received from various data sources (via step 110) may be first passed through a search text module (at step 112) configured to extract and modify relevant data from the non-curated data sources based on instance context and / or user input.

[0028] The user-defined context, which is stored in a system database 116, for each situation report, such as an area of interest (AOR), or event as may be defined by an authority like the National Weather Service, is received at step 120 and combined with the user’s query (which may be, for example, “How many fatalities?”) received at step 124 from a user interface 122 such as an incident management web application, and sent to the report generator’s LLM with the task to create a text string for use in searching for an answer to the user inquiry. In this way, the context-defined inquiry can result in improved responses. For example, a search for “How many fatalities” in a typical search engine would not likely result in results relevant to the use, unless something related to such an inquiry was dominating a news cycle at the time. In the present system, the LLM is guided by the provided context — for example, a hurricane named Gerald — and then automatically modifies the search text based on that context (which may become, for example, “How many fatalities from Hurricane Gerald?”), then sends the modified search text to search engines (which may include news, web, social media, etc.) that are appropriate based on the context and / or the user query. This results in the return of search results that will likely include more relevant informationfor the LLM to process and extract an answer to the user’s query. In addition, user inputted data may be fetched from an incident response application that is relevant to the situation.

[0029] The generator may receive schemas (from a schema file 128) that serve to assist with data extraction and deriving meaning of the structured data received, directly or through the search text feature, from various sources in real time. The schemas are used to create dictionaries at step 132 that can provide the report generator with meanings of structured data received from the realtime data sources. Guidance on the structure of summarizations based on the context, schemas, and data from a prompt engineering feature 140 is provided at step 136 to the report generator. All information obtained from data sources selected by the user are made available to the LLM for consideration. Small data sources are appended to the query, while larger data sources are saved as files and uploaded to a vector database. Files, when selected, constitute the full scope of files made available to the LLM, both through direct upload to the system, or synchronized from another directory.

[0030] Since files are all uploaded to a single vector store, the LLM can make inferences as to which data within the various files is relevant to the response without the user having to specify any given files in particular. Furthermore, the use of sections in the reports allows the LLM to focus on a particular topic. Because the accuracy and usefulness of an LLM’s summarization of information degrades with the size and scope of a task, the creation and use of sections allows for improved, focused summaries. For example, one section may be dedicated to a weather summary, another section to a news summary, and another section to a power outage summary. This use of sections also facilitates tracking differences from update to update, as described further below.

[0031] Based on all of the above information, a situation report is formatted and presented in step 144 to the user 148, which may be reformatted at step 152 based on input from the user and / or updated information received from real-time data sources. Each such report includes sections, as noted, and each section is version controlled. In particular, any change to a section, whether the change comes from an LLM update or a user’s manual input, is logged as a change. When a user updates a report, an option is presented regarding the manner in which the update should be treated. For example, the user may be presented with options to “refresh” or “update”. The “refresh” option results in prior section versions not being taking into account, and the summarization task is performed according to the prompt conditions and the datasets provided.

[0032] The “update” option specifically prompts the LLM to provide an update to the provided prior section content and only make changes that are reflected in changes in the data. For example, a section focused on power outages may have a table of various counties with their absolute and relative outage counts, along with an accompanying paragraph to summarize. Choosing the “update” option for that section would result in any changes, such as different numbers in the paragraph and in the table where appropriate, to be made, but otherwise no changes to the output or formatting are made. In this situation, he LLM is instructed to denote such changes, such as by placing them in double curly braces, which are used as a delimiter in the formatter in order to present those changes to the user in a manner that allows the changes to be identified as such. For example, in the front end application, content that is stored in double curly braces may be presented in highlighted formatting, such as bold text and yellow highlighting, which provides at a glance understanding of what has changed since the prior update.

[0033] In addition to or in conjunction with the generation and updating of reports described above, an alert system is provided that sends alerts to users based on user selections and periodic monitoring of data from sources. To set up alerts, users define event types of interest and triggers (such as thresholds or textual criteria), which are mapped to a list of recipients for these alerts. The real-time source data is compared against these triggers, factoring in any geospatial and temporal constraints that may be provided by the user or system defaults.

[0034] If an event meets or exceeds user-defined triggers, it is determined whether an alert should be sent to the recipients. If an alert is to be sent, an alert is generated and linked to a corresponding structured report for the event, where each alert or associated report contains critical information requirements (CIR / CCIR / EEI) and additional data (e.g., news, weather) for context. The system sends alerts to the relevant recipient lists, requiring acknowledgment for high-severity alerts. Duplicate alerts (i.e., alerts that are triggered after the time interval that are based on the same event as a previously sent alert to the same recipient within a selected period of time) are suppressed unless conditions change significantly, i.e., unless a severity index or category is upgraded or downgraded.

[0035] When the conditions for triggering an alert are met, the system automatically compiles a report using dedicated sections for each CIR / EEI item and relevant contextual sections.

[0036] To set up alert criteria, a user selects or provides an event type, which may be chosen from a list of predefined event types (e.g., hurricane, earthquake) or entered as character strings (e.g., “train derailment”). In addition, the alert and defined event type are linked to an area of interest (AOR) chosen by the user, which may be selected from a list of preexisting AORs or drawn or defined by the user during the set up process. Optionally, a time range may be entered for forecastable events, which defines a time window during which alerts will be generated and sent if the other criteria are met.

[0037] Triggers for initiating an alert may be based on topics entered by the user, which will be searched for in selected data sources selected for each trigger, which functions as thresholds as datasets retrieved from the associated data sources are assessed. Each selected data source includes a schema that displays all available fields. In this way, the user is provided guidance on the source data, such as the data fields it has available, but does not need to directly map the named data field in the schema. For example, an earthquake dataset could include a latitude / longitude and magnitude in the schema. This may be displayed to the user, who could then select that dataset to be either “on” or “off’ for the trigger check. The name of the trigger serves as the prompt (e.g., “Earthquake 6.0 magnitude or greater”) that the system uses and compares with the full dataset of the earthquakes overlapping the AOR to determine the outcome of the trigger check. With more datasets, more information can be used to refine the trigger check. For example, if the prompt is “Earthquake less than 6.0 magnitude but with 10+ fatalities reported”, the system could use an “Earthquakes” dataset as well as a “News” dataset and then query each based on the prompt and then make a comparison. If there was a less than 6.0 magnitude earthquake result alongside a news story about 10+ deaths, the system would determine that the trigger threshold to be met.

[0038] In addition, a user can associate recipients in the list of recipients that could receive alerts with a severity level such that recipients will receive alerts when their associated severity level matches the severity level of the alert (for a given alert check). For each trigger in an alert configuration, the user may define an alert category or severity level, such as Low, Medium, High, with corresponding numbers of severity starting from 1 and going upwards in severity. The triggers are tagged to an alert category corresponding to the severity levels, which are linked to appropriate indicia of the severity that would be included in the trigger name field. For example, in the context of tropical storms, a tropical storm under Category 1 hurricane would be Low, Category 1-2 would be Medium, and Category 3-5 would be High.

[0039] Turning to FIG. 2, an overview of a process for setting up alerts is shown. Input is received from a user at step 202 to set up an alert, which may include an area of interest (AOR), event type, list of recipients, data sources to be monitored, refresh cadence, and list of recipients based on the severity of the event. The AOR is specified at step 204, which may be an AOR selected from a list or a newly defined AOR created by the user. It is then determined at decision 206, based on further user input, whether the event type is to be selected from an existing list of event types or a custom event type. If the event type is to be custom, a new event type is created at step 208 and given a name based on the user input. The newly created event type is added to the list of event types to be selected. If the event type is already listed, the user selects the event type from the list of existing event types at step 210.

[0040] At step 212 refresh cadence is specified for the frequency at which data sources are monitored for potential indications of events or activities requiring alerts. Any refresh cadence may be used that is suitable based on the nature of the event type and user preferences. For many circumstances, refresh cadences between five minutes and 24 hours will be typical. A refresh cadence period is the time between data runs in which information is retrieved from the designated data sources and assessed.

[0041] Next, triggers are set up starting with step 214. This may include adding, editing, or removing triggers for the given alert at step 216. A trigger creation drawer component may be used for creating new triggers or editing existing triggers. Each trigger includes a name field, a category (e.g., a level of importance), which is specified at step 220, a recipient list, and one or more data source selection(s), which are specified at step 218. The string of characters in the name field form the basis for determining whether the trigger threshold is met when evaluating the selected data sources.

[0042] Data source selection may be implemented by presenting an accordion with the data sources listed in a table, with columns for data source name, description, and whether it is a “System” data source (if from a list of data sources in the system) or a “Custom” data source (if from user-entered data sources). System data sources may include a schema JSON as a list of key names (data fields) and values (descriptions). These data sources will be checked for the associated trigger during each data run.

[0043] Once a trigger set up is complete for a given trigger, meaning the selected trigger has a name that defines the trigger condition, associated data sources, and a specified category, it is determined (e.g., by user input) whether additional triggers are to be set up at decision point 222. If so, the set up process is continued by returning to step 216 (i.e., add, remove, or edit triggers and add or modify the name, condition, data source(s), and category for each). Once all triggers are set up, the next step is to add CIRs at step 224 for each configured alert.

[0044] At step 226, CIRs may be added, edited, or removed during the set up process. CIRs are used as part of reports generated if an alert is triggered (and an alert message / report is to be sent, which will also depend on whether the triggering relates to a new instance, as described further below). CIRs include a name (based on user input, required), a prompt (which is optional and may provide further guidance for what information is to be summarized), and selected data source(s), which are specified at step 228 and are where the information included in the CIR is extracted. Data source selection may be completed in a similar manner to the data source selection for triggers. Each CIR has an associated structured list of required information based on the event type previously selected.

[0045] All selected items automatically appear in the report that is generated in response to a triggered alert.

[0046] The CIR set up continues for each selected, added, or modified CIR until completed, which is determined at decision point 230. Once completed, it is determined at decision point 234 whether to run a test of the completed event alert configuration. If no test is to be run, the event alert configuration is saved at step 238 and are denoted as active at step 240, which remains during the alerting cycle (e.g., immediately or during a selected future window), such that the selected data sources are monitored / evaluated at the selected refresh cadence.

[0047] If a test is run, a simulation mode is used at step 238 that is based on historic or canned data to determine whether alerts would be sent given the event alert configuration and a data run based on the historic or canned data.

[0048] Once an event alert configuration is complete, event triggers are checked as outlined for example in the diagram of FIG. 3. For each event alert that has been configured, a task, i.e., a data run performed for a trigger check, is scheduled at step 302 based on the alert window (time period during which the event alert should be checked) and refresh cadence to check the triggers that wereset up for the given event alert configuration. This starts by fetching the triggers at step 304 for the configured alert to be checked, and then fetching the datasets at step 306 from data sources assigned for each such trigger. When an alert configuration includes more than one trigger, each trigger is preferably checked in parallel. The extracted data is filtered by correlating the AOR for the configured alert with geo information in the data, e.g., place names or latitude / longitude tags, so that only data relevant to the AOR associated with the event alert configuration is retained. This filtered data is sent at step 308 to a reasoning model to determine at decision 310 whether the trigger threshold is met based on the content of the trigger name and the filtered data. If the trigger threshold is determined to not have been met for any of the triggers associated with the event alert configuration, step 312 requires that no action is taken at that time and monitoring continues again at the next appropriate interval based on the refresh cadence.

[0049] If any trigger thresholds are met for any of the triggers of the event alert configuration, all triggers for which the threshold were met are assembled at step 314 for the event type associated with the event alert configuration. It is then determined at step 316 for use at decision point 318 if the event causing the trigger threshold(s) to be met is a new or existing instance by comparing the alert check data to run data for every for instances (i.e., events for which a trigger threshold was met resulting in an alert being sent, in which case an instance identification would have been created for that instance and associated with all corresponding event run data for that instance) of the same event type with a reasoning model. If it is determined to be a new instance, that is, the trigger threshold are met based on data not sufficiently associated with a previous instance, an alert message is created at step 324 based on the triggers for which the thresholds were met and a new instance identification is generated. If more than one trigger is met, the categories for those triggers are compared and the highest triggered trigger category is used for determining which recipients will be sent an alert message. The alert message is sent to members of the specified recipient list based on the category level.

[0050] If the triggering is determined not to be based on a new instance, the current run is tagged at step 320 to the existing instance identification it matches and the data is checked at step 322 to determine whether the trigger category has changed from the prior run for decision point 328. If the category has changed, an alert message is created at step 324 that indicates the change in category for the trigger and references the instance for which the alert message pertains. If there has not been a category change, no action is taken (i.e., no new alert message is created), and the system continues at step 330 to monitor the data sources at the refresh frequency. In this way, repeatedduplicate alerts are not sent during the course of an instance / event when no significant changes have occurred.

[0051] After an alert message is created as above, either due to a newly detected event or a category change for a previously detected and alerted instance, it is determined at decision point 326 whether an event instance report exists. If no report exists, as when it is a newly detected instance, a report is created at step 332 in which the first section includes the contents of the alert message, and the subsequent sections will have content for each of the associated CIRs. The report is then sent to the appropriate recipients based on the trigger category.

[0052] If a report already exists for the event instance, the contents in sections of the report for the event instance are updated at step 334 with new details or changes since the last run (which may optionally be delimited), and the updated instance report is sent at step 336 to appropriate recipients based on the trigger category.

[0053] Any one or more of the aspects and embodiments described herein may be implemented using one or more machines (e.g, one or more computing devices that are utilized as a user computing device for an electronic document, one or more server devices, such as a document server, etc.) programmed according to the teachings of the present specification.

[0054] Such software may be a computer program product that employs a machine-readable storage medium. A machine-readable storage medium may be any medium that is capable of storing and / or encoding a sequence of instructions for execution by a machine and that causes the machine to perform any one of the methodologies and / or embodiments described herein. Examples of a machine-readable storage medium include, but are not limited to, a magnetic disk, an optical disc (e.g, CD, CD-R, DVD, DVD-R, etc.), a magneto-optical disk, a read-only memory “ROM” device, a random access memory “RAM” device, a magnetic card, an optical card, a solid-state memory device, an EPROM, an EEPROM, and any combinations thereof. As used herein, a machine- readable storage medium does not include transitory forms of signal transmission.

[0055] Such software may also include information (e.g., data) carried as a data signal on a data carrier, such as a carrier wave. For example, machine-executable information may be included as a data-carrying signal embodied in a data carrier in which the signal encodes a sequence of instruction, or portion thereof, for execution by a machine (e.g., a computing device) and any related information(e.g., data structures and data) that causes the machine to perform any one of the methodologies and / or embodiments described herein.

[0056] Examples of a computing device include, but are not limited to, an electronic book reading device, a computer workstation, a terminal computer, a server computer, a handheld device (e.g., a tablet computer, a smartphone, etc.), a web appliance, a network router, a network switch, a network bridge, any machine capable of executing a sequence of instructions that specify an action to be taken by that machine, and any combinations thereof. In one example, a computing device may include and / or be included in a kiosk.

[0057] Memory may include various components (e.g., machine-readable media) including, but not limited to, a random access memory component, a read only component, and any combinations thereof. In one example, a basic input / output system (BIOS), including basic routines that help to transfer information between elements within computer system, such as during start-up, may be stored in memory. Memory may also include (e.g., stored on one or more machine-readable media) instructions (e.g., software) embodying any one or more of the aspects and / or methodologies of the present disclosure. In another example, memory may further include any number of program modules including, but not limited to, an operating system, one or more application programs, other program modules, program data, and any combinations thereof.

[0058] Various modifications and additions can be made without departing from the spirit and scope of this disclosure. Features of each of the various embodiments described above may be combined with features of other described embodiments as appropriate in order to provide a multiplicity of feature combinations in associated new embodiments. Furthermore, while the foregoing describes a number of separate embodiments, what has been described herein is merely illustrative of the application of the principles of the present disclosure. Additionally, although particular methods herein may be illustrated and / or described as being performed in a specific order, the ordering is highly variable within ordinary skill to achieve aspects of the present disclosure. Accordingly, this description is meant to be taken only by way of example, and not to otherwise limit the scope of this disclosure.

[0059] Exemplary embodiments have been disclosed above and illustrated in the accompanying drawings. It will be understood by those skilled in the art that various changes, omissions andadditions may be made to that which is specifically disclosed herein without departing from the spirit and scope of the present disclosure.

Claims

What is claimed is:1 . A computer-implemented method for event alerts, the method comprising: receiving input from a user for an event alert configuration, the input including an event type, an area, a list of recipients, a time window, and a refresh cadence; associating one or more triggers with the event alert configuration, wherein each of the one or more triggers includes a string of text defining a trigger threshold; assigning one or more data sources to each of the one or more triggers; specifying a severity level for each of the one or more triggers; associating one or more critical information requirements (CIR) with each trigger, wherein each of the one or more CIR include information fields for information to retrieve and include in a report when an event alert is triggered for the event alert configuration; specifying one or more data sources for each of the one or more CIR; retrieving data from the data sources associated with each of the one or more triggers during the time window at a time determined by the refresh cadence; filtering the data based on the area by correlating geospatial information of the area with geospatial information derived from the data to extract alert check data; determining for each of the one or more triggers, based on the trigger threshold and alert check data from the one or more data sources assigned to the trigger, whether the trigger threshold is met; comparing the alert check data to prior alert check data associated with any instances having a same event type as the trigger for which the trigger threshold is met to determine whether the alert check data is indicative of a new instance; creating an instance identification for a new instance if the alert check data is indicative of a new instance and tagging the alert check data with an instance identification of a prior instance if the alert check data is not indicative of a new instance; generating an alert message if any trigger threshold associated with the event alert configuration is met and the alert check data is indicative of a new instance, the alert message including information pertaining to each of the one or more triggers for which the trigger threshold is met; and retrieving, if the trigger threshold is not met for any trigger threshold associated with the event alert configuration or if the alert check data is not indicative of a new instance, data from the data sources associated with each of the one or more triggers at a time determined by the refresh cadence.

2. The method of claim 1, further including sending the alert message to one or more recipients on the list of recipients if the trigger threshold is met and the alert check data is indicative of a new instance.

3. The method of claim 2, wherein the list of recipients includes an alert severity notification level associated with one or more recipient on the list of recipients.

4. The method of claim 3, wherein the sending the alert message includes sending the alert message to each recipient for which the associated alert severity notification level matches the severity level of any trigger for which the trigger threshold is met.

5. The method of claim 4, further including, when the alert check data is not indicative of a new instance, determining whether the severity level any trigger for which the trigger threshold is met has changed since the alert message was sent, and sending an updated alert message if the severity level has changed to one or more recipient of the list of recipients.

6. The method of claim 5, wherein the updated alert message is sent to the one or more recipient of the list of recipients for which the associated alert severity notification level matches the changed severity level.

7. The method of claim 1, further including generating an event report when the trigger threshold is met and the alert check data is indicative of a new instance, wherein the event report includes a section for each of the one or more CIR.

8. The method of claim 7, wherein each section of the event report includes information from the one or more data sources associated with the respective one or more CIR each section is for.

9. The method of claim 8, further including updating the event report when the trigger threshold is met and the alert check data is not indicative of a new instance, wherein the updated event report includes any information that is different from information in an immediately preceding version of the event report.

10. The method of claim 9, wherein the updated information in the updated event report is visually distinguishable from information that was also in the immediately preceding version of the event report.

11. The method of claim 1, further including not sending an alert message to any recipients on the list of recipients when the trigger threshold is met and the alert check data is not indicative of a new instance during a refresh cadence period.

12. The method of claim 1, wherein the determining whether the trigger threshold is met is performed in parallel when there is more than one trigger.

13. An event alert system comprising: a user interface; and a processor, including a report generator module and an automated extract, transform, load module in communication with the report generator module, the processor configured to: receive input from the user interface for setting up an event alert configuration, the input including an event type, an area, a list of recipients, a time window, and a refresh cadence; associate one or more triggers with the event alert configuration, wherein each of the one or more triggers includes a string of text defining a trigger threshold; associate one or more data sources to each of the one or more triggers; associate a severity level for each of the one or more triggers; associate one or more critical information requirements (CIR) with the event alert configuration, wherein each of the one or more CIR include information fields for information to retrieve and include in the CIR when an event alert is triggered for the event alert configuration; assign one or more data sources for each of the one or more CIR; retrieve data from the data sources associated with each of the one or more triggers during the time window at the refresh cadence; determine for each of the one or more triggers, based on the trigger threshold and alert check data of the retrieved data from one or more data sources assigned to the trigger, whether the trigger threshold is met; compare the event run data to prior event run data associated with any instances having a same event type to determine whether the alert check data is indicative of a new instance; create an instance identification for a new instance if the alert check data is indicative of a new instance and tagging the alert check data with an instance identification of a prior instance if the alert check data is not indicative of a new instance;generate an alert message if the trigger threshold is met and the alert check data is indicative of a new instance, the alert message including information for each of the one or more triggers for which the trigger threshold is met; and retrieve, if the trigger threshold is not met or if the alert check data is not indicative of a new instance, data from the data sources associated with each of the one or more triggers at a time determined by the refresh cadence.

14. The system of claim 13, wherein the processor is further configured to filter the data based on the area by correlating geospatial information of the area with geospatial information derived from the data to extract alert check data prior to determining whether the trigger threshold is met for each of the one or more triggers.

15. The system of claim 14, wherein the processor is further configured to send the alert message to one or more recipients on the list of recipients if the trigger threshold is met and the alert check data is indicative of a new instance.

16. The system of claim 15, wherein the list of recipients includes an alert severity notification level associated with one or more recipient on the list of recipients.

17. The system of claim 16, wherein the processor is further configured to send the alert message to each recipient for which the associated alert severity notification level matches the severity level for of any trigger for which the trigger threshold is met.

18. The system of claim 17, the processor is further configured to, when the alert check data is not indicative of a new instance, determine whether the severity level of the instance has changed since the alert message was sent and send an updated alert message if the severity level has changed to one or more recipient of the list of recipients.

19. The system of claim 18, wherein the updated alert message is sent to the one or more recipient of the list of recipients for which the associated alert severity notification level matches the changed severity level.

20. The system of claim 13, the processor is further configured to generate an event report when the trigger threshold is met and the alert check data is indicative of a new instance, wherein the event report includes a section for each of the one or more CIR.

21. The system of claim 20, wherein each section of the event report includes information from the one or more data sources associated with the respective one or more CIR each section is for.

22. The system of claim 21, the processor is further configured to update the event report when the trigger threshold is met and the alert check data is not indicative of a new instance, wherein the updated event report includes any information that is different from information in an immediately preceding version of the event report.

23. The system of claim 22, wherein the updated information in the updated event report is visually distinguishable from information that was also in the immediately preceding version of the event report.

24. The system of claim 13, the processor is further configured to not sending an alert message to any recipients on the list of recipients when the trigger threshold is met and the alert check data is not indicative of a new instance during a refresh cadence period.

Images