Alert-information system having dynamic event-specific interactive alert-information

Abstract

Dynamic alert-information system (DAIS) for en-masse warning systems, such as public warning systems, that alert people to the occurrent of an alert event. In some embodiments, a DAIS includes one or more instances of an event-specific dynamic user interface (UI) that an alerted user can access using a dynamic event-alert link sent to a device, such as a mobile device, of the alerted user. The event-specific dynamic UI is unique and customized to the alert event. The dynamic event-alert link may be sent to people in an alert message in a broadcast manner and / or a direct-message manner. In some embodiments, the dynamic event-alert link includes a message identification (ID) used to create the customized event-specific dynamic UI. Related methods, software, and systems are also disclosed.

Description

C DS p pp p y . . pp No. 63 / 469,087, filed on May 26, 2023, and titled “ALERT-INFORMATION SYSTEMS HAVING DYNAMIC EVENT-SPECIFIC INTERACTIVE ALERT-INFORMATION USER INTERFACES, AND RELATED METHODS AND SOFTWARE”, which is incorporated by reference herein in its entirety. FIELD

[0002] The present disclosure generally relates to the field of en-masse alert systems. More particularly, this disclosure is directed to en-masse alert-information systems having dynamic event- specific interactive alert-information user interfaces, and related methods and software. BACKGROUND

[0003] Cellular-telecommunications-based public warning systems that warn the public of potentially dangerous events, such as severe weather, natural disasters, and terrorist activities, among many others, are becoming more widely used by various governmental organizations in many countries across the world. While these public warning systems are becoming increasingly ubiquitous and increasingly valuable for saving human lives and property, because of the limitation of one-way, point-to-many communication and other limitations on en-masse messaging on cellular telecommunications networks they typically provide only a limited amount of information to the alerted members of the public. SUMMARY

[0004] In one implementation, the present disclosure is directed to a method of automatedly making alert-event information available to alerted users when alerting the alerted users to an alert event. The method includes receiving an alert-event message that contains a dynamic alert-event link for an event-specific dynamic user interface (UI) and further contains event information regarding the alert event; and in response to receiving the alert-event message, causing a dynamic UI builder to build the event-specific dynamic UI by extracting at least a portion of the event 1 Attorney Docket No.17214-032WOU1information and the dynamic alert-event link from the alert-event message and using the at least a portion of the event information and the event-specific dynamic link to build the event-specific UI.

[0005] In another implementation, the present disclosure is directed to a method of deploying a dynamic alert-information system (DAIS) to a warning system in operative communication with a telecommunications network that includes a plurality of cell sites. The method includes deploying a plurality of edge-deployed dynamic user-interface (UI) systems at a plurality of differing edge- computing sites, each in physical proximity to a corresponding group of the cell sites; and deploying a centrally deployed dynamic UI system remotely from the edge-deployed dynamic UI systems; wherein each of the edge-deployed dynamic UI systems and the centrally deployed dynamic UI system: is configured to receive an alert-event message for an alert event, wherein the alert-event message includes information concerning the alert event and a dynamic alert-event link unique to the alert event; and includes a dynamic UI builder to build an event-specific dynamic UI by extracting at least a portion of the event information and the dynamic alert-event link from the alert-event message and using the at least a portion of the event information and the dynamic alert-event link to build the event-specific dynamic UI.

[0006] In yet another implementation, the present disclosure is directed to method of automatedly making alert-event information available to subscribers when subscribers are alerted to an alert event. The method includes receiving, at an edge-deployed dynamic user-interface (UI) system, an alert-event message that contains event information regarding the alert event, wherein the event information includes an alert-event region for the alert event; in response to receiving the alert- event message: determining, by the edge-deployed dynamic UI system, whether or not the edge- deployed dynamic UI system serves the alert-event region; when the edge-deployed dynamic UI system does not serve the alert-event region, not activating, by the edge-deployed dynamic UI system, an event-specific dynamic UI at the edge-deployed dynamic UI system; and when the edge- deployed dynamic UI system serves the affected area, activating, by the edge-deployed dynamic UI system, the event-specific dynamic UI at the edge-deployed dynamic UI system.

[0007] In still another implementation, the present disclosure is directed to a method of automatedly answering a question from an alerted user about an alert event. The method includes receiving, at an event-specific dynamic user interface (UI), an event-alert message that contains event information regarding the alert event; receiving, at the event-specific dynamic UI and from the alerted user, the question about the alert event; generating an artificial-intelligence (AI) prompt by 2 Attorney Docket No.17214-032WOU1combining at least a portion of the information from the system event-alert message with at least a portion of the question from the user; querying an AI tool using the AI prompt; receiving a response from the AI tool based on the AI prompt; and displaying, by the event-specific dynamic UI, the response to the alerted user.

[0008] In another implementation, the present disclosure is directed to a machine-readable medium containing machine-executable instructions for performing a method as described immediately above. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] For the purpose of illustration, the accompanying drawings show aspects of one or more embodiments of the disclosure. However, it should be understood that the scope of this disclosure is / are not limited to the precise arrangements and instrumentalities shown in the drawings, wherein:

[0010] FIG.1 is a high-level schematic diagram of a dynamic alert-information system (DAIS) made in accordance with the present disclosure;

[0011] FIG.2 is high-level block diagram of a dynamic user-interface (UI) application (app) that can be deployed as an edge-deployed dynamic UI system and / or a centralized dynamic UI system of a DAIS of the present disclosure, such the DAIS of FIG.1;

[0012] FIG.3 is a map of an area in which an alert event is occurring in an alert-event region, showing components of a telecommunications network and components of the DAIS of FIG.1 and their relationship to the alert-event region;

[0013] FIG.4 is a diagram illustrating an example method of automatedly making event- specific information available to alerted users when the alerted users are alerted to an alert event;

[0014] FIG.5 is a diagram illustrating an example method of deploying a DAIS to a warning system deployed on a cellular communications network that includes a plurality of cell sites;

[0015] FIG.6 is a diagram illustrating another example method of automatedly making alert- event information available to alerted users when alerted users are alerted to an alert event;

[0016] FIG.7 is a diagram illustrating a further example method of automatedly making alert- event information available to alerted users when alerted users are alerted to an alert event;

[0017] FIG.8 is a diagram illustrating an example method of answering a question from an alerted user about an alert event; 3 Attorney Docket No.17214-032WOU1

[0018] FIGS.9A through 9C collectively contain a high-level schematic diagram of a DAIS of the present disclosure, such as the DAIS of FIG.1, implemented in a public warning system (PWS) using a centralized chatbot instance and a plurality of chatbot instances deployed at multiple Multi- access Edge Computing (MEC) sites;

[0019] FIG.10A is a screenshot taken on a mobile device, showing an example of an alert message of the present disclosure for an alert event as it is visually displayed on the mobile device;

[0020] FIG.10B is a screenshot taken on the mobile device of FIG.10A, showing an example of a landing page of an event-specific dynamic UI of the present disclosure;

[0021] FIG.10C is a screenshot taken on the mobile device of FIGS.10A and 10B, showing an example of a question & answer page of the present disclosure that allows an alerted user to ask questions about the alert event;

[0022] FIG.11 is a high-level diagram illustrating an example missing-person alert system made in accordance with aspects of the present disclosure; and

[0023] FIGS.12A – 12F are example screenshots of a mobile browser showing various pages of the dynamic UI of the missing-person alert system of FIG.11 as displayed on a mobile device. DETAILED DESCRIPTION

[0024] In some aspects, the present disclosure is directed to dynamic alert-information systems (DAISs) that allow alerted users that receive an alert concerning the occurrence of an alert event via the mobile devices that they carry or wear to selectively access information about the alert event using those mobile devices that in conventional alert messaging would not be directly available to the alerted users. An alert event can be any type of event that occurs at or around a particular physical location for which people in one or more alert regions need to be alerted about the event for awareness that the event occurred, for example, so that the people can take appropriate actions. By way of a small, nonlimiting, set of examples, alert events include, but are not limited to: natural-disaster events, such as tornados, hurricanes, monsoons, tsunamis, volcanic eruptions, severe lighting, blizzards, avalanches, flooding, etc.; manmade-disaster events, such as train derailments, building collapses, active shooters, terror attacks, military attacks, riots, dam breaches, etc.; general safety events, such as riptides, excessively high outdoor temperatures, excessively low outdoor temperatures, etc.; and person-related events, such as missing-person events and dangerous-fugitive events, etc.; among many others. In each case, it is desirable for people within the corresponding 4 Attorney Docket No.17214-032WOU1alert region(s) to be provided with information concerning the alert event, such as, but not limited to, the type of the alert event, a precise location of the alert event, instructions for reacting to the event (e.g., evacuate, take shelter, avoid an area, move inland, stay out of the water, etc.), artificial- intelligence (AI) created information, maps, diagrams, photographs, sketches, shelter locations, hospital locations, best practices relating to the alert event and / or a component thereof, and multimedia instructions and / or other multimedia content, e.g., in the form of infographics, video, audio, etc. and any combination thereof, among many other types of information concerning the alert event. Regarding multimedia content, such content with video and / or auditory elements can be helpful in providing clear and concise information so that the alerted users quickly and clearly understand essential details of the situation. In some embodiments, it is also desirable to allow alerted users to contribute information to the DAIS. For example, for person-related events, alerted user can provide information such as a time and location of a sighting of the subject person, an updated image (e.g., photograph) of the subject person, or further identification detail of the subject person, among others, and any combination thereof.

[0025] As discussed and exemplified below in detail, a DAIS of the present disclosure includes one or more dynamically created event-specific user interfaces (UIs) from which the alerted people, hereinafter “alerted users”, can retrieve information about the relevant alert event, such as any one or more pieces of the example information above, among many other types of information. As also discussed below, each dynamically created event-specific UIs can be created by a dynamic UI builder that is responsive to a warning-system alert-event message generated by the relevant warning system. A detailed example of a DAIS of the present disclosure is presented below in which the warning system is a public warning system (PWS), such as a PWS available from Everbridge Inc., Burlington, Massachusetts, that uses the well-known Common Alert Protocol (CAP) such that the warning-system alert-event message is a CAP alert-event message. However, those skilled in the art are aware that another alert-messaging protocol may be used as desired to suit a particular deployment. In addition, those skilled in the art will readily appreciate that a DAIS of the present disclosure can be implemented in types of warning systems other than PWSs, such as a private warning system or any other type of warning system of any scale in which it is desirable to allow alerted users to easily learn event-specific information regarding a particular alert event via an initial event-alert message that they receive on their mobile devices. 5 Attorney Docket No.17214-032WOU1

[0026] In some aspects, the present disclosure is directed to methods and software for providing the functionalities of a DAIS of the present disclosure. Each of these and other aspects are described below, first in the context of a general example and then in the context of a particular PWS.

[0027] GENERAL EXAMPLE

[0028] Referring now to the drawings, FIG.1 shows an example DAIS 100 deployed in the context of a cellular-telecommunications-based warning system 104 that is in operative communications with a cellular-telecommunications network 108 so as to be able to warn end users (not shown) of alert events. The cellular-telecommunications network 108 can be any conventional cellular-telecommunications network or any later-developed cellular-telecommunications network having the requisite functionality. In the example shown, the cellular-telecommunications network 108 has a plurality of cell sites, here, cell sites 112(1), cell sites 112(2), cell sites 112(3), and cell sites 112(4) that are or can be in radio communication with end-user mobile devices, here, corresponding mobile devices 116(1), 116(2), 116(3), and 116(4).

[0029] Each of the cell sites in the cell sites 112(1) through 112(4) can be any type of known cell site or hereinafter-developed cell site having the functionalities needed to implement a DAIS of the present disclosure, such as the DAIS 100 of FIG.1. For the sake of the present disclosure and the appended claims, each of the cell sites in the cell sites 112(1) through 112(4) can use any suitable standard, such as conventional cellular standards (e.g., 4G, 5G, etc.) or computer-network standards (e.g., an IEEE 802 standard, etc.), or any combination thereof. Those skilled in the art will readily understand the types of cell sites suitable for each of the cell sites 112(1) through 112(4) such that further description is not needed herein for those skilled in the art to make and use a DAIS of this disclosure or any portion(s) thereof to the fullest scope of the appended claims.

[0030] Similarly, each of the mobile devices in the mobile devices 116(1) through 116(4) can be any type of known mobile device or hereinafter-described mobile devices that can communicate with the cellular-telecommunications network 108 and can interact with a DAIS of the present disclosure, such as the DAIS 100 of FIG.1. Examples of mobile devices that each of the mobile devices 116(1) through 116(4) can be include, but are not limited to, smartphones, smartwatches, tablet computers, and laptop computers, among others. Fundamentally, there is no limitation on the type of mobile device that mobile devices 116(1) through 116(4) are as long as it can provide the necessary functionalities to utilize a DAIS of the present disclosure, such as the DAIS 100 of FIG.1. 6 Attorney Docket No.17214-032WOU1

[0031] It is noted that each set of the cell sites 112(1) through 112(4) in this example include any number of individual cell sites and can, for example, number into the tens or hundreds. Similarly, each of the corresponding sets of mobile devices 116(1) through 116(4), while depicted in numbers ranging from two to six, can similarly exist in any number, ranging from zero (i.e., none currently in the corresponding cell region (not shown), to, for example, tens, hundreds, or thousands, depending on how many mobile devices are within that cell region.

[0032] In this example, the DAIS 100 is deployed using a deployment network 120, which, as those skilled in the art will readily understand, can be one or more of any suitable type of data- communications networks and / or portion(s) thereof. Examples of data-communications networks that the deployment network 120 can fully or partly contain include, but are not limited to, the cellular-telecommunications network 108 (here, other than the cell sites 112(1) through 112(4)), the Internet, local area networks, wide-area networks, and municipal area networks, among others. Fundamentally, there is no limitation on the nature of the deployment network 120 other than it support the functionalities of the DAIS 100.

[0033] It is noted that four sets of cell sites 112(1) through 112(4) are shown to illustrate a feature of the example DAIS 100, namely the absence and / or presence of one or more associated edge-computing sites, here three edge-computing (EC) sites 124(1) through 124(3) corresponding to and operatively associated, respectively, with cell sites 112(1) through 112(3), with cell sites 112(4) not being associated with any edge-computing site. In a real-world deployment of a DAIS of the present disclosure, such as DAIS 100 of FIG.1, the actual number of edge-computing sites may be any number, including zero.

[0034] FIG.1 shows the three edge-computing sites 124(1) through 124(3) as being proximate to edges of the cloud that the deployment network 120 to visually depict that they are at the edge of the deployment network. Similarly, the visual proximity of each of the edge-computing sites 124(1) through 124(3) to the corresponding set of the cell sites 112(1) through 112(3) in FIG.1 indicates that there is an operational relationship between the cell sites in that group with the corresponding edge-computing site. This operational relationship is described below in detail.

[0035] The example DAIS 100 of FIG.1 is designed and configured to provide an event- specific message (not shown) to each of the mobile devices 116(1) through 116(4) that includes an event-specific link (not shown) (e.g., an event-specific uniform resource locator (URL)) that the 7 Attorney Docket No.17214-032WOU1corresponding alerted users (not shown) can choose to use to access additional information (not shown) about the corresponding event. In this example, the DAIS 100 provides this functionality by providing one or more dynamic UI applications (apps), here three edge-deployed dynamic (EDD) UI systems 128(1) through 128(3) at corresponding respective ones of the edge-computing sites 124(1) through 124(3) and a centralized dynamic UI system 132 located, for example, either “in the cloud” on the deployment network 120 or in a server / server system (not shown) that may also provide the warning system 104, among other locations.

[0036] In the example DAIS 100 and at a high level, each dynamic UI system 128(1) through 128(3) and 132 is configured to receive a warning-system alert-event message 136, unique to an underlying alert event, from the warning system 104 and then uses information contained in that warning-system alert-event message to build an event-specific dynamic UI (not shown, but see event-specific dynamic UI 220 of FIG.2) customized to the underlying alert event. In association (e.g., simultaneously or nearly simultaneously) with the warning system 104 sending the warning- system alert-event message 136, in the embodiment shown the warning system also issues an alert message 140 that will ultimately be received by each of the mobile devices 116(1) through 116(4). The alert message 140 can be sent using any one or more messaging protocols suitable for the deployment network 120, such as the well-known Short Messaging Service (SMS) and / or Cellular Broadcast (CB) messaging protocols commonly used on conventional cellular-telecommunications networks. For more detailed information regarding warning systems that utilized SMS and / or CB messaging, see U.S. Patent No.10,924,891, issued on February 16, 2021, to Mouline et al. and titled “INTELLIGENT MESSAGING-CHANNEL SELECTION AND RELATED FEATURES FOR ALERT SYSTEMS, SYSTEMS INCORPORATING SAME AND METHODS AND SOFTWARE THEREFOR”, which is incorporated herein for all of its teachings relevant to the present disclosure. It is noted that the warning-system-alert message 136 and the alert message 140 needed not be separate and distinct from one another. Rather, these two messages may be the same message, such as a CAP message, that is received by the appropriate systems, such as a cell-broadcast system and a dynamic-UI system, such as the EDD UI systems 128(1) through 128(3) and the centralized dynamic-UI system 132. In some embodiments, the alert message 140 includes an dynamic alert- event link 140L that is unique to the underlying alert event and allows each end user to access the associated alert-event UI. In an example, the dynamic alert-event link 140L may be a Uniform Resource Locator (URL) and, in this example, is dynamically created and managed by a dynamic- link manager 144. 8 Attorney Docket No.17214-032WOU1

[0037] Referring now to FIG.2, and also to FIG.1, FIG.2 illustrates an example relationship among the warning system 104, the dynamic-link manager 144, each of the edge-deployed dynamic UI systems 128(1) through 128(3) and the centralized dynamic UI systems 132 (represented by dynamic UI system 200 in FIG.2), and each of the mobile devices 116(1) through 116(4) (represented in FIG.2 by mobile device 116). In an example, when a warning-system user (not shown) uses the warning system 104 to create an alert for a new alert event, as seen in FIG.2 the warning system 104 sends a message-identifier (ID) request 204 to the dynamic-link manager 144. In response to the message-ID request 204, the dynamic-link manager 144 generates a unique message ID 208 that is unique to the underlying new alert event. The warning system 104 then generates the dynamic alert-event link 140L and includes it in both the warning-system alert-event message 136 and the alert message 140. It is noted that while the dynamic-link manager 144 is shown as being located in the warning system 104, it may be located elsewhere in the DAIS 100, such as, for example, within the dynamic-UI system, which here is composed of the EDD UI systems 128(1) through 128(3) and the centralized dynamic-UI system 132.

[0038] In some embodiments, particularly embodiments where the alert message 140 needs to be relatively short, such as in SMS and CB messaging, the dynamic alert-event link 140L needs to be short, and, when the dynamic alert-event link is composed of a URL, this shortness can be provided in part by making the message ID 208 as short as practicable. For example, in some embodiments the message ID 208 can be a single alpha character, a single numeric character, or a single alphanumeric character, among others, depending on the maximum plausible number of message IDs that could be active simultaneously. For example, if 10 or fewer message IDs would ever be active and / or inactive but not purged at the same time, then a single numeric character can be used because that would yield 10 non-purged message IDs, namely, 0 through 9. Once the dynamic- link manager 144 has purged an already used message ID, the dynamic-link manager can reuse it for a new alert. A detailed example of message IDs and a dynamic-link manager is presented below in connection with FIGS.9A through 9C.

[0039] The warning system 104 sends the warning-system alert-event message 136 to the dynamic-UI system 200, which includes a dynamic-UI builder 212. In this embodiment, the warning-system alert-event message 136 includes the dynamic alert-event link 140L that is also sent to each mobile device 116 in the alert message 140, as well as information about the underlying alert event, such as type, severity, basic instructions, and / or location, among others. In response to the 9 Attorney Docket No.17214-032WOU1mobile device 116 receiving the alert message 140, it displays the alert message to the alerted user (not shown), including the dynamic alert-event link 140L. At this point, the alerted user may choose to select the dynamic alert-event link 140L, which may cause the mobile device to display a mobile- device UI 216, such as a browser or an application.

[0040] In response to receiving the warning-system alert-event message 136, the dynamic-UI builder 212 builds a corresponding dynamic UI 220 unique to the underlying alert event, including assigning the dynamic UI the dynamic alert-event link 140L so that the dynamic-UI system 200 uniquely serves that dynamic UI to, via the mobile-device UI 216, an alerted user choosing to select the dynamic alert-event link on her / his mobile device 116. In some embodiments, the dynamic-UI builder 212 may use other information in the warning-system alert-event message 136 to build the dynamic UI 220. In some embodiments, the dynamic UI 220 may include other features, such as AI features 224 that allow alerted users to ask questions and receive corresponding answers about the underlying alert event. As those skilled in the art will readily appreciate, the dynamic UI system 200 can serve two or more dynamic UIs in any given time period. For example, if three alert events A, B, and C, are currently active, then the dynamic-UI system 200 may be currently serving corresponding event-specific dynamic UIs 220A through 220C. Examples of content and other details about dynamic UIs that can be implemented in the dynamic UIs 220A through 220C are described below in connection with FIGS.9A through 9C.

[0041] Still referring to FIG.2, and also FIG.1, when the alerted user selects the dynamic-alert- event link 140L displayed on the mobile device 116, the mobile device sends a request 228 that causes the dynamic-UI system 200 to serve 232 the dynamic UI 220 to the mobile device, such as via a webpage 236. The mobile device 116 may then display the received webpage 236 of the dynamic UI 220 on the mobile device UI 216. Depending on the nature of the dynamic UI 220, the alerted user may then interact with the dynamic UI, for example, to the AI features 224 (if present) via the mobile-device UI 216 as desired.

[0042] Referring again to FIG.1 and as noted above, in this example the DAIS 100 may include one or more edge-deployed dynamic-UI systems, here shown as the edge-deployed dynamic-UI systems 128(1) through 128(3). Reasons for implementing the edge-deployed dynamic-UI systems 128(1) through 128(3) include 1) reducing response time for serving dynamic UIs (see, e.g., the dynamic UIs 220A through 220C of FIG.2) to the mobile devices 116(1) through 116(4) and 2) reducing the demand on bandwidth available within the deployment network 120 by not requiring 10 Attorney Docket No.17214-032WOU1all of the mobile devices to only be served the dynamic UIs via a centralized dynamic-UI system, such as the centralized dynamic-UI system 132.

[0043] In some embodiments, the DAIS 100 is designed and configured to determine which one(s) of multiple edge-deployed dynamic-UI systems, here, the three edge-deployed dynamic-UI systems 128(1) through 128(3). In an example, the DAIS 100 may include an edge-site activation- assessment system 148 that determines which, if any, of the edge-deployed dynamic-UI systems 128(1) through 128(3) should be activated so as to serve an event-specific dynamic UI (such as any of the event-specific dynamic UIs 220A through 220C of FIG.2) to the relevant ones of the cell sites 112(1) through 112(4). FIG.3 shows a map 300 of geographical region 304 that includes a plurality of cell sites 308 (similar to cell sites 112(1) through 112(4) of FIG.1) (here, the small circles; only a few labeled to avoid cluttering the figure), most, but not all, of which are operatively connected to edge-computing sites 312(1) through 312(11) as depicted by lines 316 (only a few labeled to avoid clutter) connecting a cell site to a corresponding edge-computing site. In this example, each of the edge-computing sites 312(1) through 312(11) includes a corresponding dynamic-UI system 320(1) through 320(11), which may be the same as or similar to the dynamic-UI system 200 of FIG.2. Each of the edge-computing sites 312(1) through 312(11) corresponds generally to any one of the edge-computing sites 124(1) through 124(3) of FIG.1. In this example, it is noted that edge-computing sites 312(4), 312(5), 312(6), 312(7), and 312(10) are co-located with a corresponding cell site 308, indicating that it is possible to co-locate edge-computing equipment (not shown) with cellular transmission equipment (not shown), if desired. This example also shows two groups 324(1) and 324(2) of cell sites 308 that are not operatively associated with any edge- computing site. Relative to the DAIS 100 of FIG.1, the cell sites 308 in these groups 324(1) and 324(2) generally correspond to the cell sites 112(4).

[0044] As discussed above, an alert event typically involves one or more alert regions that may contain people that need to be alerted to the alert event, and thus, the DAIS (e.g., the DAIS 100 of FIG.1) needs to send alert messages that the mobile devices carried by any such people present in the alert region(s) will receive. In FIG.3, a particular alert event has a single alert region 328 that may contain people that the DAIS attempts to warn via an alert message (see, e.g., alert message 140 of FIG.1) specific to the alert event. As can be seen in FIG.3, in this example edge-computing sites 312(3), 312(6), and 312(7) and their corresponding cell sites 308 are located within the alert region 328, as are the cell sites in the group 124(2) of cell sites. The edge-site activation-assessment system 11 Attorney Docket No.17214-032WOU1148 (FIG.1) is configured to determine which one(s) of the edge-computing sites 312(1) through 312(11), here edge-computing sites 312(3), 312(6), and 312(7), should be activated based on the alert region 328. This can be done in a variety of ways.

[0045] In one example, the warning system 104 may use conventional means for determining which cell sites 308 are within the alert region 328, and the edge-site activation-assessment system 148 (FIG.1) may use a connectivity topology to determine which, if any, of the identified cell sites 308 are associated with one or more of the edge-computing sites. If so, the DAIS activates the affected one(s) of the edge-computing sites, here, edge-computing sites 312(3), 312(6), and 312(7). In another example, the warning-system alert-event message 136 (FIG.1) defines the alert region 328 (e.g., using a circle or a polygon), and each dynamic-UI system 320(1) through 320(11) is configured to use that definition to determine whether or not it and / or corresponding ones of the cell sites 308 associated with it, are located within the alert region and, if so, effectively activating itself. This way, each dynamic-UI system 320(1) through 320(11) can make its own determination of whether or not it should be serving an event-specific UI to cell sites 308, and therefore alerted users located within the alert region 328. It is noted that the term “activating” in this context is used loosely and covers any manner of including or not including an edge-computing system 320(1) through 320(11) in event-specific-UI building operations for a particular alert event.

[0046] With the foregoing in mind, FIGS.4-8 illustrate a set of example methods 400, 500, 600, 700, and 800 that a DAIS of the present disclosure, such as the DAIS 100 of FIG.1, can perform or that can be performed in conjunction with a DAIS of the present disclosure. For assisting the reader’s understanding, each of the methods 400, 500, 600, 700, and 800 is described in the context of FIGS.1-3. However, their scopes are not limited to the particular instrumentalities and features depicted in those figures. Those skilled in the art will readily understand that these methods 400, 500, 600, 700, and 800 are only a few of many methods that a DAIS of the present disclosure can perform and that other methods will be readily apparent after reading and understanding this entire disclosure.

[0047] The method 400 of FIG.4 is a method of automatedly making event-specific information available to mobile devices of alerted users when the alerted users are alerted to an alert event. In this example, the method 400 includes, at block 405, receiving a warning-system alert- event message 136 that contains a dynamic alert-event link 140L for an event-specific dynamic UI 220 and further contains event information regarding the alert event. At block 410, in response to 12 Attorney Docket No.17214-032WOU1receiving the warning-system alert-event message 136, a dynamic-UI builder 212 is caused to build the event-specific dynamic UI 220 by extracting at least a portion of the event information and the alert-event link 140L, using the at least a portion of the event information to build the event-specific dynamic UI, and using the alert-event link to identify the event-specific dynamic UI so that the event-specific dynamic UI is accessible. At optional block 415, the event-specific dynamic link 140L is sent to the mobile devices so that the alerted users can access the event-specific dynamic UI 220 using the event-specific dynamic link.

[0048] The method 500 of FIG.5 is a method of deploying a DAIS 100 to a warning system 104 deployed on a cellular communications network 108 that includes a plurality of cell sites 112(1) through 112(4) and 308. In this example, the method 500 includes, at block 505, deploying a plurality of edge-deployed dynamic UI systems 128(1) through 128(3), 200, and 320(1) through 320(11) at a plurality of differing edge-computing sites 124(1) through 124(3) and 312(1) through 312(11), each in physical proximity to a corresponding group 124(1) through 124(3) of the cell sites. At block 510, a centrally deployed dynamic UI system 132 is deployed physically remotely from the edge-deployed dynamic UI systems 128(1) through 128(3), 200, and 320(1) through 320(11). In the method 500, each of the edge-deployed dynamic UI systems 128(1) through 128(3), 200, and 320(1) through 320(11) and the centrally deployed dynamic UI system 132 is configured to receive a warning-system alert-event message 136 for an alert event, wherein the warning-system alert-event message includes information concerning the alert event and a dynamic alert-event link 140L unique to the alert event. Each of the edge-deployed dynamic UI systems 128(1) through 128(3), 200, and 320(1) through 320(11) and the centrally deployed dynamic UI system 132 also includes a dynamic UI builder 212 to build an event-specific dynamic UI 220 by extracting at least a portion of the event information and the dynamic alert-event link from the warning-system alert-event message 136 and using the at least a portion of the event information and the dynamic alert-event link to build the event-specific dynamic UI.

[0049] The method 600 of FIG.6 is a method of automatedly making alert-event information available to alerted users when alerted users are alerted to an alert event. In this example, the method 600 includes, at block 605, receiving, at an edge-deployed dynamic UI system 128(1) through 128(3), 200, and 320(1) through 320(11), a warning-system alert-event message 136 that contains event information regarding the alert event, wherein the event information includes an alert- event region 304. In response to receiving the warning-system alert-event message 136, at 13 Attorney Docket No.17214-032WOU1block 610 the edge-deployed dynamic UI system 128(1) through 128(3), 200, and 320(1) through 320(11) determines whether or not the edge-deployed dynamic UI system serves the alert- event region 304. At block 615, when the edge-deployed dynamic UI system 128(1) through 128(3), 200, and 320(1) through 320(11) does not serve the alert-event region 304, the edge-deployed dynamic UI system does not activate an event-specific dynamic UI 220 at the edge-deployed dynamic UI system. At block 620, when the edge-deployed dynamic UI system 128(1) through 128(3), 200, and 320(1) through 320(11) does serve the alert-event region 304, the edge-deployed dynamic UI system activates the event-specific dynamic UI 304 at the edge-deployed dynamic UI system.

[0050] The method 700 of FIG.7 is a method of creating and using a dynamically created alert- event link in a DAIS. In this example, the method 700 includes, at block 705, sending, for a new alert event, a message-ID request 204 for a new-event message ID 208. At block 710, the message ID 208 is generated. At block 715, the new-event message ID 208 is included in an alert-event link 140L (FIG.1). At block 720, the alert-event link 130L is included in both an alert message 140 and a warning-system alert-event message 136, and at block 725 the alert message is sent to at least one mobile device 116 and to at least one dynamic UI system 200.

[0051] The method 800 of FIG.8 is a method of automatedly answering a question from an alerted user about an alert event. In this example, the method 800 includes, at block 805, receiving, at an event-specific dynamic UI 220, a warning-system event-alert message 136 that contains event information regarding the alert event. At block 810 and at the event-specific dynamic UI 220, the question about the alert event by the alerted user is received. At block 815, an artificial- intelligence (AI) prompt (see, e.g., section II.6.ii, below) is generated by combining at least a portion of the information from the warning-system event-alert message with at least a portion of the question from the user and including instructions for an AI tool to answer in a pertinent manner. At block 820, the AI tool of AI features 224, is queried using the AI prompt. At block 825, a response based on the AI prompt is received from the AI tool, and at block 830, the event-specific dynamic UI displays the response to the alerted user.

[0052] DETAILED EXAMPLE – PUBLIC WARNING SYSTEM IMPLEMENTATION

[0053] I. Overview

[0054] This example describes an implementation of features of the present disclosure in which a DAIS of the present disclosure is implemented in a public warning system (PWS) for a cellular 14 Attorney Docket No.17214-032WOU1communications network, and the event-specific dynamic UI system is implemented as a chatbot. In this example, the DAIS is configured to overcome some challenges with CB- and SMS-based messages, such as: 1. CB and SMS alert messages are relatively short; the message creator must focus on the main and most important part of an event-alert message. 2. CB cannot be used as an interactive protocol, as it is a one-way communication mode. SMS could in theory be used. An event-specific UI is much more convenient. 3. CB and SMS alert messages typically support only 1 or 2 languages in a single message whilst sending multiple message is generally not practical. 4. CB and SMS alert messages are text only, though some smartphones support performing Text To Speech (TTS) to make messages audible.

[0055] More information can be available from a PWS but not through CB or SMS channels due to them being text based and having message-size limitations. One or more event-specific dynamic-UI systems of the present disclosure fills this gap, allowing more information to be made available to the alerted user receiving the event-alert message and providing at least the following benefits: 1. ability to allow alerted users to ask questions on the ongoing alert event / event-alert message using text, audio, and / or soft buttons; 2. ability to convert the event-alert message into multiple languages text and audio; 3. ability to provide to alerted users a geographical location of the event on a map and / or a relation to the location of the alerted user (e.g., instructions for nearest shelter or evacuation route, among others); 4. ability to provide to alerted users multimedia messages when available; this can be, for example, recorded audio / video, map of the area of effect for the event-alert message, photo or picture, picture with signs / icons, etc.; and 5. ability to provide to alerted users one or more links to sources having additional information and / or emergency telephone number(s), and, if any such telephone number is provided, ability to access or dial each directly from the event-specific chatbot.

[0056] In some embodiments, a DAIS of the present disclosure, such as the DAIS 100 of FIG.1, may be used to obtain and log various feedback from alerted users receiving alert-event messages. For example, when an alerted user selects an event-specific URL, the DAIS can log this 15 Attorney Docket No.17214-032WOU1selection. This provides feedback to warning-system operators on the number of people receiving an event-alert and requesting chatbot access and thus usage numbers. In an example, selecting an event-specific URL embedded in an event-alert message generates and HTTP request to open, for example, a browser or an installed application (e.g., on a smartphone or other smart device) to open an event-specific dynamic UI. The event-specific dynamic UI will then display the event-specific dynamic UI and is ready to receive questions, commands, and / or other input from the alerted user. In addition, the selection of the embedded event-specific URL can trigger a logging of the event- specific dynamic UI access request to a suitable database, such as a database onboard a web server that serves the event-specific dynamic UI. This logged information can be used, for example, to track

[0057] Another, albeit optional, feature is that the vast majority of conventional chatbots, such as chatbots used on a company website or for civil safety information like COVID19 information or earthquake information, typically provide only static content. In the case of an event-specific dynamic UI of the present disclosure, the messages they provide can themselves be dynamic (perhaps enhanced with static content such as hazard instructions).

[0058] In some embodiments of a DAIS of the present disclosure, such as the DAIS 100 of FIG.1, one or more event-specific dynamic UIs include AI that allow alerted users to ask questions that the AI features answer. If so, the DAIS can log the questions that the alerted users ask as well as the corresponding answers that the AI provide. This logging can, for example, provide warning- system operators feedback on what information the alerted users are seeking. For example, if alerted users routinely seek certain information, that can be an indication that the event-alert message itself should contain that information so as to not require the alerted users to keep asking for the same type of information to save the user time and effort. In addition, logging questions and answers can provide data on how often the AI gets the answers right, which can help warning-system operators to determine whether additional efforts are needed for improving specific answers and / or for training AI models. Another option is that answers need not be given by an AI. Rather, for each repeated question for a particular alert event, a previously AI answer could be searched from a database instead, which can bring both cost and performance benefits. In an example, the event-specific dynamic UI may log each question and answer pair together with the corresponding unique message ID and a timestamp. Personal identifiable information need not be logged to protect identities of alerted users. The logging can be, for example, to a suitable log file or database. 16 Attorney Docket No.17214-032WOU1

[0059] In some embodiments, a DAIS of the present disclosure, such as the DAIS 100 of FIG.1, is configured to obtain explicit feedback on the state and / or condition of each alerted user. For example, an event-specific dynamic UI could be configured to include one or more soft buttons, for example, “I am safe” or “I need help”, among others. A selection of a feedback soft button by an alerted user may trigger the event-specific dynamic UI to log information regarding the same. It is noted that an alerted user should not as for help in an emergency, in which case the alerted user should contact the appropriate emergency services in the customary way. For example, the event- specific dynamic UI could expose a phone-dialing function of the alerted user’s mobile device to the alerted user.

[0060] II. Detailed Workings of Example Implementation

[0061] The descriptions in this section II are augmented by FIGS.9A through 10C, which in some cases use implementation-specific terminology that is different from the more generalized terminology used in other parts of this disclosure. For clarity, the following Table 1 contains a concordance between the two sets of terminology where the terminologies differ, as well as a list of corresponding element numerals to identify the various elements in FIGS.9A through 9C. For features of FIGS.9A through 10C not particularly addressed below, those skilled in the art will readily understand them in the context of the subject matter of these figures, such that explanation is not needed for those skilled in the art to make and use this implementation to its fullest scope. Table 1 Element in Implementation-specific FIGS.9A Terminology General Terminology through 9C Public Warning System (PWS) warning system 904 chatbot, chatbot instance(s) dynamic UI system 924, 928 decentralized chatbot edge-deployed dynamic UI system 928 centralized chatbot centrally deployed dynamic UI system 924 chatbot page, event-specific event-specific dynamic UI 952 chatbot page Multi-access Edge Computing edge-computing n / a (MEC) warning message, CAP alert, CAP warning-system alert-event message 900 message, CAP warning message, event-specific CAP warning message alert, alert message event-alert message 908 URL dynamic alert-event link n / a message ID, event ID, short ID message ID 912ID user alerted user 932 17 Attorney Docket No.17214-032WOU1Table 1 Element in Implementation-specific FIGS.9A Terminology General Terminology through 9C cell cell site n / a

[0062] II.1 Creating Warning Message / CAP alert in the PWS

[0063] To create a warning message / CAP alert 900 in the PWS 904, a PWS user (not shown) wanting to create an alert 908 for distribution using CB and / or SMS and that includes the chatbot function takes action in the PWS. A URL is needed in the alert 908, and this URL needs to be very short to overcome the CB / SMS message-size limitation mentioned above. The PWS user causes the PWS 904 to send a message identifier (ID) request 912R to a chatbot proxy 916 for the chatbot proxy to generate a unique alert ID.

[0064] In response to receiving the message-ID request 912R, the chatbot proxy 916 generates the unique alert ID 912ID and makes a reservation for the alert ID, and then sends the alert ID to the PWS 904. An algorithm (not shown) in the chatbot proxy 916 ensures the message ID is as short as possible or practicable, for example, using a single character that can be any alphabetic or numeric character so that the DAIS 920 can service 36 simultaneous alerts (26 alpha characters + 10 single- digit numerals). In some embodiments, the alert IDs 912ID gracefully expire after a day. Due to the urgent, short-term nature of certain events (e.g., tornado, hail storm, hurricane, active shooter, etc.), a one-day automatic expiration period is sufficient. However, the automatic expiration period can be different as required. In some embodiments, the alert IDs 912ID may not automatically expire. Rather, they may be periodically purged, either automatically or manually.

[0065] Once created, the message ID 912ID is used to make a short and unique URL. For example, if the underlying website is “crisis.chat” and the message ID is “A”, then the short URL can be: https: / / www.crisis.chat / ?id=A. It is noted that the short URL contains the message ID 912ID that allows the chatbot software instance(s) (i.e., one or more of the EC DAISUI system instances and / or a central DAIS UI system instance) to dynamically create the desired event-specific UIs as discussed below. The PWS 904 puts this short URL into the event-alert message 900, here, a CAP warning message, for example, in the CAP field alert.info.description. For example, this CAP field may contain: 18 Attorney Docket No.17214-032WOU1“Fire in Alkmaar. Please close all doors and windows and turn aircon off. For more information: https: / / crisis.chat / ?id=A” The PWS 904 may put this warning into the CAP warning message 900 together with allother relevant information in other alert fields present in the CAP standard, such as, for example, the alert fields for location text, location polygon, additional instructions, additional languages, severity, etc. Alternatively or additionally, the short URL for the chatbot software instance(s) may be put into the CAP field alert.info.web.

[0066] II.2 Sending the CAP Warning Message in the PWS that Includes the Chatbot Proxy

[0067] The PWS 904 sends the CAP warning message 900 to the chatbot proxy 916. Upon receipt, the chatbot proxy 916 updates the internal event ID 912ID reservation (e.g., from CAP field alert.info.web or alert.info.description) with the unique cap.identifier. The chatbot proxy 916 then forwards the CAP warning message 900 to all available chatbot instances (here, the decentralized chatbot 924 (FIG.9B) and the centralized chatbot 928 (FIG.9A)) using a suitable messaging protocol. For the centralized chatbot 928, for example, in the cloud or at an alert-issuing authority’s premises, the messaging protocol may include an acknowledgement 900A, such as, for example, an HTTP 200 success acknowledgement under the HTTP protocol or another acknowledgement under a different protocol.

[0068] For the chatbot proxy 916 to send the CAP message 900 to multiple decentralized chatbots 924 in the Multi-access Edge Computing (MEC) (European Telecommunications Standards Institute (ETSI)) of European telecom operators, a suitable publish / subscribe protocol, such as Kafka or other message queue (e.g., Google Firebase Cloud Message, Amazon SNS, even Amazon S3), can be advantageous to use. Even if a decentralized chatbot 924 would not receive the message 900 correctly, the centralized chatbot 928 is there as backup, as discussed below.

[0069] In this example, the PWS 904 may also send the warning message 900 (e.g., as a CAP message or a Common Mobile Alert System (CMAS) message) to one or more other alert systems (not shown) implementing CB and / or SMS as the delivery channel(s) and may also include channels that cannot yet utilize chatbots, such as radio and siren, among others. 19 Attorney Docket No.17214-032WOU1

[0070] II.3 CAP Administration for MEC and Centralized Chatbot

[0071] Upon receipt, each chatbot instance 924, 928 will update the internal ID administration with the unique alert.identifier. The chatbot proxy 916 can do this by analyzing the field alert.info.description (or field alert.info.web) of the CAP alert 900 for the chatbot URL that includes the short event ID 912ID. This is needed as alerted users 932 will use the short URL containing the short event ID 912ID, which needs to be mapped back to the original CAP warning message 900 with the help of the unique alert.identifier. The CAP warning message 900 will also be stored for later reference, for example, in a file system (not shown) or a database (not shown).

[0072] II.4 MEC-Deployed Chatbot Determining if it Needs to Serve CAP Warning Message to Particular Alerted Users

[0073] The CAP warning message 900 contains a location for the physical area in which the alert is in effect, and this is the area in which the DAIS 920 sends the CB and / or SMS messages. The relevant field of the CAP warning message 900 is alert.info.area.polygon or alert.info.area.circle. Consequently, only alerted users 932 in the affected area having received the CB / SMS message would contact a chatbot 924, 928.

[0074] To achieve this, a chatbot UI Frontend (UIF) 924UIF of each decentralized chatbot 924 will query, at 936, the MEC (not shown) using the ETSI MEC Location application programming interface (API) 940 using the “Radio Node Location Lookup” function. In response, the MEC will provide, at 936L, all served cells in the relevant telecommunications network(s), together with, for each cell, a location point, for example, in the form of latitude / longitude of, for example, the physical cell tower, center point of cell, or the like. For simple positioning with medium accuracy, this may suffice in some instances. This is based on the reasoning that each MEC site will typically service numerous cells, such that there will be a sizable collection of location points (e.g., tens or hundreds). The chatbot UIF 924UIF then checks to see if any location points fall within the event area identified in the CAP warning message 900.

[0075] If no cell location point falls into the CAP-warning-message-provided event area, processing ends in the chatbot UIF 924UIF and no further action needs to be taken. If alerted users 932 in this serving location perform a query using the short chatbot URL in the alert 908, they will reach the centralized chatbot 928. For any point falling within the CAP-warning-message- provided event area that a corresponding MEC-deployed chatbot 924 is serving, the chatbot UIF 924UIF requests, at 944, the MEC, through the ETSI MEC (Edge Platform Application 20 Attorney Docket No.17214-032WOU1Enablement, Domain Name System (DNS) rule activation from the MEC app) DNS 948 to set the local DNS to point to its local decentralized chatbot 924 (instead of the centralized chatbot 928).

[0076] II.5 Alerted User Chooses to Start Interacting with a Chatbot UI

[0077] Each alerted user receives an alert 908 corresponding to the CAP warning message 900 via CB and / or SMS functionality(ies) of that alerted user’s mobile device (not shown). The alerted user 932 views or clicks on, or otherwise selects, the alert 908, reads and / or listens to it, and may decide to get more information about the alert event by clicking on, or otherwise, activating the short URL in the displayed alert 908. A mobile packet data session may already be available or will be started by the mobile device in response to the activating of the short URL. A mobile-device browser aboard the alerted user’s mobile device will then perform, at 946, a DNS lookup for the chatbot URL. If the alerted user 932 is being served in a location where a decentralized chatbot instance 924 is deployed in the MEC and is active for the alert 908, then the MEC environment will return, to the mobile device, the URL 946URL of the corresponding decentralized chatbot 924 in the MEC. As noted above, if the alerted user 932 is not in or not near the area of the event underlying the alert 908, the chatbot URL would resolve to the centralized chatbot 928 that is, for example, on the cloud or on-premises of the alert-issuing authority.

[0078] Assuming that a relevant decentralized chatbot instance 924 exists and is active, the mobile-device browser will now directly contact, via an HTTP request 950, that decentralized chatbot instance running in the local MEC site and will open the corresponding chatbot page 952. The URL includes the event ID 912ID for the alert 908 and CAP warning message 900, allowing the decentralized chatbot instance 924 to dynamically create the event-specific chatbot page 952 to display information about the particular ongoing alert from the CAP warning message by mapping the event ID 912ID to the unique cap.alert.identifier and finding the corresponding event-specific CAP warning message 900. As discussed below, the chatbot instance 924, 928 at issue pulls information from the CAP warning message 900 to answer alerted-user questions either directly or using AI. Effectively, the relevant chatbot instance 924, 928 becomes an event-specific chatbot specifically configured to the corresponding alerting event.

[0079] II.6 User Interacting with an Event-specific Chatbot Page, and Answering Questions through Artificial Intelligence

[0080] With an event-specific chatbot page 952 of the relevant chatbot instance 924, 928 displayed in the browser of the alerted-user’s mobile device, in some embodiments the alerted 21 Attorney Docket No.17214-032WOU1user 932 can now ask questions 954Q, as illustrated in loop 958, by writing text and / or sending audio messages to the event-specific chatbot page 952. If the alerted user 932 uses audio, the chatbot UIF, 924UIF, 928UIF of the relevant chatbot instance 924, 928, for example, translates the audio to text using a Speech-to-Text function, for any AI function to further process. In response to each question, the chatbot UIF 924UIF will provide a corresponding answer 954A to the mobile device’s browser for the alerted user 932 to see and / or hear.

[0081] With an alert-user’s question available in text, the chatbot UIF 924UIF needs to resolve the question. In some embodiments this is done by performing AI question-answers sessions 956 in a chatbot AI Backend (AIB) 924AIB. The chatbot AIB 924AIB can be implemented using any one or more of various AI solutions, such as, but not limited to, a chatbot-builder tool, such as Google Dialogflow, or Amazon Lex, or a Large Language Model (LLM), such as openAI ChatGPT, among others. Those skilled in the art will readily understand that for at least some of these solutions to provide sensible answers, training needs to be done, and the information in the CAP warning message 900 for the current alert-event needs to be contextualized.

[0082] In an example, the relevant chatbot instance 924, 928 passes the question first to a chatbot-building tool, such as Google Dialogflow. If the chatbot-building tool can answer the question, then the process is done and the chatbot-building tool answers by return an intent ID. The intent ID classifies the answer, such as it is a location question, or the user wants to know about severity, or wants instructions on preparation. The relevant chatbot instance 924, 928 then uses this knowledge to generate the answer (response) in combination with information from the CAP warning message 900.

[0083] If an answer is not found in the first pass, the relevant chatbot instance 924, 928 generates the prompt for a LLM and sends the question again. If the question was relevant to the alert event and the LLM can answer, then the LLM will generate the precise answer that the chatbot instance provides as a response to the alerted user. It is possible that the LLM also cannot answer the question, as, for example, the question may not be relevant to the alert event. For example, perhaps the alerted use asked for a recipe for a particular dish.

[0084] In some embodiments, the chatbot-building tool need not be used. In such embodiments an LLM may be used, for example, by changing the prompt to include all available intents and their 22 Attorney Docket No.17214-032WOU1descriptions, including a summary of the CAP warning message 900 and asking the LLM to return one of: ^ Intent IDs if intents are the best match as an answer; these are answers that require further processing; ^ If no intents match but the LLM can give a reasonable answer in the context of the alert event, an LLM generated answer; and ^ If no intents match and the LLM cannot generate a relevant answer, a statement that no suitable answer is possible for the question asked. It is noted that this may make the prompt considerably larger and that a similar result can be achieved by customizing the LLM.

[0085] In some embodiments, the prompt for the LLM, such as ChatGPT, includes information from the event-alert warning message 900 and the alert-user’s question, as above, but it also includes specific instructions for the LLM on the type of information it should return in its response to the prompt. For example, to ensure that the type of information that the LLM returns is related to the alert event at issue in a particular alert-event warning message 900, the prompt may begin with: “You are an AI assistant that is there to help a user in a natural disaster. You only use the following info to answer the user's questions:”, and the prompt may end with: “Only use the information above to answer the user's questions. Do not use any other information.” This improves the answer from the LLM and prevents it from giving answers not related to the ongoing emergency.

[0086] II.6.i Training:

[0087] In some embodiments, each chatbot AIB 924AIB, 928AIB is trained to handle questions concerning the current alert event by providing it with multiple sets of historical alert messages (e.g., multiple differing CAP warning messages), alert instructions, and questions related to a diversity of emergencies users have previously asked, along with suitable answers. Training can be ongoing, with new questions and answers providing additional training material. Those skilled in the art will readily understand how to train the chatbot AIB 924AIB, 928AIB using this disclosure as a guide.

[0088] II.6.ii Contextualizing the current alert message:

[0089] Initially, each chatbot AIB 924AIB, 928AIB does not yet know the current alert-event, which likely has specific information not available and / or not provided in the training (e.g., current location, instruction, date and time, etc.). In an example, the chatbot UIF 924UIF, 928UIF will 23 Attorney Docket No.17214-032WOU1provide this information by contextualizing (e.g., “prompt engineering”) the CAP warning message 900 into more of a human-comprehendible format before asking the question to a trained AI model (not shown). For example, if an alerted user 932 asked: “What should I do” for the current alert event, then the contextualized message may look like: “On Monday 30-01-202312:39:32, at location Alkmaar, there is a fire alert ongoing with severity medium. Accordingly, the alert message says: Fire in Alkmaar. Please close all doors and windows and turn air-conditioning off. What should I do” The above can be done by templating a prompt (not shown) with the following information fields from the CAP warning message 900 and the user question: “On <alert.onset>, at location <alert.info.area.areaDesc>, there is a <alert.info.event> alert with severity <alert.info.severity>. Accordingly, the alert message says: <alert.info.description>. <user.question> Depending on the AI implementation being used, this prompt can be used directly as the prompt for the AI model (e.g., ChatGPT) or as the input to an agent (not shown), such as an intents agent (e.g., Google DialogFlow), or other AI-implementation interface.

[0090] II.7 Multimedia Support

[0091] In some embodiments, each provided chatbot instance 924, 928 may be designed and configured to provide multimedia content to each alerted user, for example, in any response to any question that the alerted user may ask. Examples of categories of information that each such chatbot instance 924, 928 can provide multimedia content for include, but are not limited to: 1) Preparation – information on anything the alerted user should do to prepare for the relevant alert event (e.g., imminent hazard). 2) Instructions – information on what the alerted user should do during the particular emergency. 3) Cause – information on what caused the alert event, such as, for example, information on what causes a quick clay landslide. 4) Emergency Kit – information on items that the alerted user should have in an emergency kit, either or both of generally and specifically for the event underlying the alert event. 5) Emergency System – information on how the emergency system works. 24 Attorney Docket No.17214-032WOU1

[0092] Following is an example of serving multimedia content in an example chatbot instance, e.g., any one of the chatbot instances 924, 928, that includes both a chatbot-building tool and an LLM. In this example, an alerted user asks a question, such as “how to I prepare for a brushfire”. In response, the chatbot-building tool (e.g., Google Dialogflow) categorizes an intermediate answer as “preparation” for the event type “bushfire”. Here, “preparation” is identified using a unique intent ID. This type of answer requires further post processing.

[0093] Using “preparation” for the intent and “bushfire” for the event type, the chatbot instance searches a database for textual and multimedia instructions. If such instructions are available, they are appended with pertinent multimedia content, such as, for example, one or more videos, audio clips, and / or images from a multimedia datastore (e.g., filesystem). The combination of the answer and the multimedia content is then served to the alerted user, which the chatbot UIF, such as chatbot UIF 924UIF, 928UIF, can play and / or otherwise present to the alerted user. If instructions are not available, fallback to the LLM can be done to retry getting an textual answer, as discussed above. In this embodiment and as alluded to above, the multimedia content itself is not stored in the database; rather it resides in the multimedia datastore and the database contains links to the multimedia objects.

[0094] II.8 Alert Expiry

[0095] In some embodiments, if the current alert does not get updated or cancelled, it can automatically expire through the field alert.info.expires in the CAP warning message 900. The alert in an expired case is not active anymore, and the DAIS 920 would not expect chatbot questions for expired alerts or, alternatively, would allow questions within a grace period after expiration. The chatbot proxy 916 may use the expiry information and optional grace period to release the short ID 912ID reserved for the expired alert, optionally with a grace period. After expiry with or without a grace period, the chatbot proxy 916 can reuse the short ID 912ID for new alerts.

[0096] For the chatbot UIF 924UIF, 928UIF, a grace period can be used to allow “late” questions. For example, after expiry + grace period, the chatbot UIF 924UIF, 928UIF can: ^ remove the expired CAP warning message 900 & update ID administration; ^ if no other CAP warning message is active in the region that each relevant decentralized chatbot instance 924 serves, remove the DNS entry using the MEC API 940 (as result of this action, any request for the chatbot will go to the centralized chatbot instance); 25 Attorney Docket No.17214-032WOU1^ upon an alerted user attempting to access information via an alert message 908 for an expired CAP warning message that is still in the grace period, cause the relevant chatbot instance 924, 928 to note to the users that the alert event is not active anymore; and ^ upon an alerted user 932 attempting to access information via an alert message for an expired CAP warning message that is outside of the grace period, cause the relevant chatbot instance to note to the users that the alert event is not valid.

[0097] In some embodiments in which a grace period is used, the active chatbot instance 924, 928 may present to the alerted user 932 a statement to the effect that the alert event has expired, along with any other relevant information.

[0098] II.9 Alert Cancellation

[0099] A user on the PWS 904 can decide to cancel an active CAP warning message 900 if the corresponding alert event is not active or not appropriate anymore. This results in a “CAP Cancel” message (not shown) that references the alert to be cancelled being sent to the chatbot proxy 916 and all of the chatbot instances 924, 928. The resulting actions that need to be taken are identical to the actions noted above for alert expiry.

[0100] II.10 Alert Updates

[0101] A user on the PWS 904 can decide to update an active CAP warning message 900 if the corresponding alert event has changed, for example, in terms of location, description, expiry, and / or severity, among other things. This results in a “CAP Update” message (not shown) that references the alert to be updated being sent to the chatbot proxy 916 and all the chatbot instances 924, 928.

[0102] II.11 Chatbot Proxy

[0103] A CAP update is handled in the CAP standard with a new unique alert.identifier and a reference to the previous (old) identifier in the field alert.references. The chatbot proxy 916 needs to update its internal short ID mapping with the new alert.identifier. The chatbot proxy 916 needs to examine if the expiry is earlier or later, which also impacts its short-ID reservation. The chatbot proxy 916 also sends the alert update as a CAP message 900 to all chatbots.

[0104] II.12 Chatbot

[0105] For the chatbot UIF 924UIF, 928UIF, depending on the change, the following actions may happen: 26 Attorney Docket No.17214-032WOU1^ Update the internal short-ID administration with new alert.identifier and store the new CAP warning message 900. ^ alert.info.expires change: Update internal ID administration if the expiry is earlier or later. ^ Event location change: If the location of alert event has changed, the new location must be matched with the served area. If there is no overlap of a serving location with the alert location, whilst there previously was, the situation is generally similar to expiry in that the DNS entry in the MEC must be removed. If alerted users 932 in this serving location make queries with the chatbot URL, then they will reach the centralized chatbot 928. For a decentralized chatbot 924 previously not serving an alert, the location change may result in it now serving the updated alert, for example, as discussed above in Section II.4.

[0106] Other (textual) changes, like severity and description change, have no impact on chatbot processing method, but can impact the chatbot AIB 956, which should use the updated alert information for the contextualization. This can be done as the internal ID administration now links the short ID 912ID to the updated alert.identifier, mentioned above.

[0107] II.13 Addition and Removal of Chatbot Functionality in CAP Update

[0108] Not yet mentioned is the removal of chatbot functionality using a CAP Update and a last-minute inclusion of chatbot functionality for ongoing CAP alert that initially did not include a chatbot functionality. These possibilities are discussed in this subsection.

[0109] II.13.i Inclusion of Chatbot Functionality using CAP Update

[0110] The inclusion of chatbot functionality in a CAP Update should follow the identical procedures in Sections II.1 through II.6, above. A difference here is that the message type of the CAP message field alert.msgType is “Update”. The chatbot proxy 916 looks to update its mapping, but since no earlier mapping existed, except for the ID reservation, it needs to update the mapping as is done for a new CAP alert as discussed above. The chatbot proxy 916 forwards this message to all chatbot instances 924, 928.

[0111] The process for each chatbot instance 924, 928 is also similar to the process for a new- alert-event CAP message 900, but the relevant CAP message is now designated as an Update as noted immediately above. An attempt to update the internal ID administration will not find any existing CAP alert to update. Consequently, this Update is treated as a new mapping. 27 Attorney Docket No.17214-032WOU1

[0112] II.13.ii Removal of Chatbot Functionality

[0113] The removal of chatbot functionality can be done in a CAP Update by removing the chatbot URL from the alert.info.description (and / or alert.info.web). In the chatbot proxy 916, this can be treated like a cancelled alert or an expiry, with the ID mapping being removed. The chatbot proxy 916 forwards this message to all chatbot instances 924, 928.

[0114] For the chatbot instances 924, 928, the removal of a chatbot page 952 is also similar to a cancelled alert and, so, can follow the process for a cancelled alert.

[0115] For the chatbot UIFs 924UIF, 928UIF and as discussed above, a grace period can be used to allow “late” questions. After expiry + grace period, the chatbot UIF may: ^ remove the expired CAP alert & update ID administration; ^ if no other CAP alert is active in the region that the chatbot instance serves, remove the DNS entry using the MEC API 940; ^ in response to an alerted user accessing a cancelled CAP alert still in a grace period, cause the chatbot instance to note to the alerted user that the alert is not active anymore; and ^ in response to an alerted user accessing a cancelled CAP alert outside of the grace period, cause the chatbot instance to note to the alerted user that the alert is not valid.

[0116] II.14 Other Information

[0117] II.14.i Chatbot Proxy

[0118] The example information in Table 2, below, can suffice for a chatbot proxy, such as the chatbot proxy 916 to perform its functions. The actual CAP message 900 is not required and could be stored for reference. The expiry is a combination of alert.info.expires + grace period, which could be any suitable grace period such as, for example, 24 hours. Table 2 Event No. Short ID alert.identifier alert.info.expires 1 10 pwp.32018.32018 04 / 04 / 202518:40 2 11 pwp.32021.32021 05 / 04 / 202513:34 28 Attorney Docket No.17214-032WOU1

[0119] II.14.ii Chatbot UIF

[0120] The example information in Table 3, below, can suffice for a chatbot UIF, such as any of the chatbot UIFs 924UIF and 928UIF to perform its functions. The actual CAP message 900 is and could be stored in the same database or file system where the example information in Table 3 is stored. The expiry is a combination of alert.info.expires + grace period, which could be any suitable grace period such as, for example 1 hour. Table 3 Event No. Short ID alert.identifier alert.info.expires CAP 1 10 pwp.32018.32018 03 / 04 / 202519:40 <xml … > 2 11 pwp.32021.32021 04 / 04 / 202514:34 <xml … >

[0121] For example, the file system may use either the short ID or the alert.identifier as file name, such as, for example, 10.xml or 11.xml, or pwp.32018.32018.xml or pwp.32020.32020.xml, among many others.

[0122] II.14.iii CAP Field Usage Relevant / Used for this Example ^ alert.identifier contains the unique identifier for this CAP message 900. Used by the chatbot proxy 916 and the chatbot UIF 924UIF, 928UIF and uniquely identifies CAP alerts. ^ alert.references contains the identifier for an alert being updated. Used by the chatbot proxy 916 and the chatbot UIF 924UIF, 928UIF to uniquely identify CAP alerts. ^ alert.msgType contains the message types, such as, “Alert”, “Update”, and “Cancel”, and is relevant for both the chatbot proxy 916 and the chatbot UIF 924UIF, 928UIF to determine what operation to perform. ^ alert.status indicates whether the alert of the CAP message 900 should be shown to public (value is “Actual”), or is of an “Exercise” or “Test” type in which case full processing can be done to test DAIS 920, but there will not be any access for the public (so no need to perform ETSI MEC DNS operation and answer user questions). ^ alert.info.expires contains information on when the Alert expires. This is optional, and, if not used, the PWS 904 must cancel the alert. ^ alert.info.description contains a human-readable description regarding the alert of the CAP message 900. This includes relevant information about the alert event and the chatbot URL 29 Attorney Docket No.17214-032WOU1for the user to access a chatbot page 952 of a chatbot instance 924, 928 to obtain more information about the alert event. The alerted-user devices displaying alerts 908 received using SMS / CB will render the short chatbot URL as clickable for the alerted user 932, to allow the alerted user to conveniently navigate to the chatbot page 952. ^ alert.info.web is an optional field, which, when used, contains the URL for more information. This could be utilized by a chatbot instance 924, 928 to find—more easily as opposed to alert.info.description that PWS 904 is using—the chatbot functionality for the current alert event and the short ID 912ID allocated, which can then be mapped to the alert.identifier.

[0123] II.15 Example Benefits

[0124] In the context of the DAIS 920 of FIGS.9A through 9C, overall benefits of providing the PWS 904 with chatbot functionality to complement the CB / SMS messaging for the public can include, but are not limited to: ^ User friendliness: allows alerted users to ask questions about the ongoing alert message using text, soft buttons, and / or other UI feature(s). ^ User friendliness: unlike traditional information websites having static information, there need not be a fixed format for an alerted user to read and / or follow, and the alerted users can query the chatbot instance(s) for information they want. ^ Ability to convert the alert message into multiple languages. ^ Ability to provide multimedia messages. This can be, for example, generated audio or recorded audio / video, map of the area of effect for the alert message, photo or picture, picture with signs / icons, etc., as desired to suit a particular situation. ^ Chatbot pages can provide links to sources with additional information and / or emergency numbers to call. ^ The URL shortening allows the chatbot URL to be present in the CB / SMS message without overly impacting the limited usable message length. ^ Benefits of deploying chatbot functionality into ETSI MEC (versus a cloud-based or on- premises deployment) include, but are not limited to: o decentralized chatbot instance(s) deployed closer to the alerted users in ETSI MEC, resulting in better performance and greater responsiveness; 30 Attorney Docket No.17214-032WOU1o decentralized chatbot instance(s) deployed closer to the user in ETSI MEC, resulting in increased resilience and / or reliability as the chatbot functionality is not dependent on large portion of public and telecom infrastructure that could fail; and o running in ETSI MEC on operator infrastructure provides the benefits of running in a safe, controlled, and monitored environment.

[0125] A benefit of combining both a decentralized ETSI MEC deployment of one or more chatbot instances and a centralized Internet (cloud / on-premises) deployment of a chatbot instance together with one another is the providing of redundant paths and environments to provide more resilience.

[0126] Benefits within the chatbot instances include taking input of CAP message and contextualizing the CAP message back into human language (e.g., via prompt engineering), together with handling alerted-user questions, to allow AI engines to provide suitable responses on a current alert without having been trained on the live and current alert at issue. This also allows the chatbot instances to operate in a dynamic manner, which is opposed to operating in the static manner of many conventional chatbots.

[0127] II.16 Example Mobile-Device Screenshots

[0128] FIGS.10A through 10C show corresponding screenshots 1000, 1004, and 1008 taken on a mobile device 1012 (here, a smartphone) carried by an alerted user (not shown, but see the alerted user 932 of FIG.9B), illustrating various aspects and features of a DAIS of the present disclosure, here the DAIS 920 of FIGS.9A through 9C.

[0129] FIG.10A shows the mobile device 1012 having received a CB message 1016 from the DAIS. The CB message 1016 includes a short URL 1020. In this example, the short URL 1020 is for a dynamic chatbot page. However, in other embodiments the short URL 1020 will contain a URL parameter (not shown) for a dynamic chatbot page to make the URL a dynamic short URL.

[0130] For example, in some embodiments the URL parameter may be the “?id=A” provided as an example in Section II.1, above, that, in this example, comprises the key “id” and the value “A”. Together, “id=A” identify that the message ID that the DAIS assigned to the particular alert event underlying the CB message is “A” (as single alphanumeric character, here “A”). The chatbot 31 Attorney Docket No.17214-032WOU1instance responding to the alerted user’s selection of the dynamic short URL will then use this message ID to display an appropriate event-specific chatbot page to the alerted user.

[0131] FIG.10B shows chatbot landing page 1024L of an event-specific dynamic UI 1024 that is accessed when the alerted user selects the dynamic short URL discussed above relative to FIG.10A. In this example, the alerted user can ask the event-specific dynamic UI a question using the “ASK A QUESTION” soft button 1028 at the bottom of the chatbot landing page 1024L. As discussed above, AI, such as the AI discussed above relative to subsection II.6, may underpin the event-specific dynamic UI 1024 and provide prompt-engineering functionality, such as the prompt- engineering functionality discussed above, among others.

[0132] In this example, the chatbot landing page 1024L also includes an information region 1032 that provides various information 1036 about the specific underlying event, here, a brief description 1036(1) and a corresponding icon 1036(2), a severity level 1036(3), a longer description 1036(4), instructions 1036(5), and a pair of updates 1036(6) and 1036(7). The chatbot landing page 1024L further includes a speech soft button 1040 that allows the alerted user to choose to listen to the information 1036, as well as a language-selection soft button 1044 that allows the alerted user to choose a language to display the information in.

[0133] FIG.10C shows a question & answer (Q&A) dialog UI 1048 of the event-specific dynamic UI 1024 that the event-specific dynamic UI displays after the alerted user selects the “ASK A QUESTION” soft button 1028 at the bottom of the chatbot landing page 1024L of FIG.10B. In this example, the Q&A dialog UI 1048 includes a user-input field 1052 where the alerted user enters one or more queries for the AI component of the event-specific dynamic UI 1024 to address. An alerted user may either type a query into the user-input field 1052 using a soft keyboard (not shown) or input the query using a speech-to-text feature of the mobile device 1012.

[0134] The Q&A dialog UI 1048 of this example also includes a dialog history region 1056 that displays a warning 1060, chatbot posts, here chatbot posts 1064(1) through 1064(3), any alerted-user queries (here, alerted-user query 1068), and one or more quick-ask soft buttons (here, quick-ask buttons 1072(1) and 1072(2)). As can be seen in this example, in response to the Q&A dialog UI 1048 posting the chatbot post 1064(1) the alerted user has asked “How close is the fire?” as the alerted-user query 1068. In an example, the alerted user may have made this alerted-user query 1068 using a quick-ask soft button (not shown) that the Q&A dialog UI 1048 removed from view since 32 Attorney Docket No.17214-032WOU1the alerted user already used it. In an example, the alerted user may have made this alerted-user query 1068 using the user-input field 1052.

[0135] In this example, the Q&A dialog UI 1048 responded to the alerted-user query 1068 by making the chatbot post 1064(2) stating that permission is needed to access the location services of the mobile device 1012. Not shown in the Q&A dialog UI 1048 is that in response to chatbot post 1064(2), the alerted user granted permission to access the location services. In response to that granting of permission, the Q&A dialog UI 1048 posted the chatbot post 1064(3) containing a brief statement on the location of the alerted user relative to the current alert event (a fire), as well as a map showing the two locations. Those skilled in the art will readily appreciate that the examples of FIGS.10A through 10C are merely illustrative and that other implementations may have other forms and features that comply with the present disclosure.

[0136] The embodiment shown in FIG.10C also includes feedback soft buttons, here feedback soft buttons 1076(1) and 1076(2) that allow an alerted user to provide feedback to the DAIS 900, for example, in accordance with the feedback-logging functionalities discussed above in Section I. Here, the “I am safe” feedback soft button 1076(1) allows the alerted user to inform the DAIS 900 that they are safe, and the “I need help” feedback soft button 1076(2) allows the alerted user to inform the DAIS that they need help. As alluded to above in Section I, the selection by the alerted user of the “I need help” feedback soft button 1076(2) may cause the event-specific dynamic UI 1024 to display emergency contact information (not shown) to the alerted user and / or cause the mobile device 1012 to present a phone-dialing interface (not shown) to the alerted user. Those skilled in the art will readily understand that these feedback soft button 1076(1) and 1076(2) are illustrative and can be replace and / or augmented by other feedback mechanisms, such as speech- based mechanisms and / or may be replaced and / or augmented with other types of feedback.

[0137] DETAILED EXAMPLE – MISSING-PERSON ALERT SYSTEM IMPLEMENTATION

[0138] This example describes an implementation of features of the present disclosure in which a DAIS of the present disclosure is implemented in a missing-person alert system, such as the example missing-person alert system 1100 of FIG.11A. As those skilled in the art will readily appreciate, a missing-person alert system, or any person-related alert system (e.g., dangerous- fugitive alert system), made in accordance with the present disclosure has benefits over conventional person-related alert systems, such as the well-known “Amber Alert” system and related systems for missing children. When a person-related alert system of the present disclosure utilizes CB 33 Attorney Docket No.17214-032WOU1messaging, the reach of the event alerts is greater than the reach of a conventional Amber Alert system. In addition, when a person-related alert system of the present disclosure allows alerted users to provide information to the DAIS, its use can lead to better resolutions of the alert events, such as finding the missing persons quicker and, perhaps, before more harm is done to or by the missing person, as the case may be.

[0139] In this example, the missing-person alert system 1100 is implemented in the context of a PWS 1104 using CAP messages and CAP messaging (represented at CAP message 1108 in FIG.11A) in the manner of the PWS described in detail above, and the missing-person dynamic UI system 1112 is based on the AWS LAMBDA® function as a service (FaaS) in conjunction with Amazon simple storage service (S3), both available from Amazon Web Services, Inc., and can be equated, for example, to any one or more of the EDD UI systems 128(1) through 128(3) and centralized dynamic UI system 132 of FIG.1. For convenience, the following description uses the respective terms “AL FaaS” and “AS3 storage service”. However, those skilled in the art should appreciate that a missing-person alert system of the present disclosure can use any suitable service(s) and architecture(s) for implementing the corresponding missing-person dynamic UI system 1112 for the missing-person alert system 1100. Similarly, those skilled in the art will appreciate that the CAP-messaging standard is only one example of messaging that can be used to implement a missing-person alert system of the present disclosure.

[0140] The example missing-person alert system 1100 works as follows. An authority 1116 sends a missing-person alert 1120 to the PWS 1104 alerting the PWS of a missing person. In response to receiving the missing-person alert 1120, the PWS 1104 generates a CAP message 1108 containing, among other things and for example, information about the missing person, such as an image, a physical description, and a location last seen. The CAP message also includes a short URL (not shown) that is sent to mobile devices (singly and collectively represented by mobile device 1124) as an alert message 1128 via CB and / or SMS messaging, for example, in the same or similar manner relative to the alert message 140 described above relative to FIGS.1 and 2. The short URL can be generated in any suitable manner, such as the manner discussed above relative to the dynamic alert-event link 140L of FIGS.1 and 2. As an example, the alert message 1128 may be as follow: “For more information please click the following link: mpa.nl / ?id=1”. Here, the “mpa” indicates that this is a missing-person alert, and the “1” is a unique numeral that allows more than one missing-person-alert message to be pending simultaneously for different missing persons. The 34 Attorney Docket No.17214-032WOU1missing-person dynamic UI system 1112 may be sensitive to the “MP” designation by formatting the dynamic UI 1132 specifically for missing-person alerts. CB messaging is particularly desirable for a missing-person alert because of the broad coverage. A drawback of CB messaging, however, is that it does not currently support multimedia (e.g., images) that is critical for missing-person alerts. Consequently, the combination of using a short URL to access dynamically created UIs that can display multimedia provides both the broad coverage and the visual information that are important for effective missing-person situations.

[0141] The CAP message 1108, which contains the short URL and multimedia and other information about the missing person and the underlying alert, is sent to the missing-person dynamic UI system 1112. The missing-person dynamic UI system 1112 then uses the short URL and at least some of the information in the CAP message, such as any image, physical description, time and / or location that the missing person was last seen, etc., to build an event-specific dynamic UI 1132 that is dedicated to the missing-person alert 1120. Once a mobile device 1124 receives the alert message, which the mobile device displays on its screen 1124S, the corresponding user (not shown) may select the short URL displayed. In response to the user selection, the mobile device 1124 navigates the user to the dynamic UI 1132 to interact 1136 with the dynamic UI 1132, for example, to learn more about the missing person and perhaps provide one or more tips that could potentially help the authority 1116 locate the missing person. The dynamic UI 1132 may forward 1140 each tip that a user provides. Screenshots 1200(1) through 1200(6) of example webpages that the event-specific dynamic UI 1132 may display are shown in FIGS.12A through 12F, respectively.

[0142] As noted above, the missing-person dynamic UI system 1112 of the example is implemented using an AL FaaS and an AS3 storage service. When the AL FaaS receives the CAP message 1108, it parses the message to, in this example, look for the identifier “ / ?id=MP1” and stores the CAP message in an AS3 storage service “bucket” (not shown, but part of the missing- person dynamic UI system 1112), where the event-specific dynamic UI 1132 (here, a web application) may also be located. The name of the CAP message 1108 in this case could be, for example, “MP1.xml”.

[0143] Extracting multimedia from a CAP message, such as the CAP message 1108, is slow and expensive when done in a frontend web application, so the AL FaaS is implemented to extract the multimedia information from CAP message and to also store the information into the AS3 storage service bucket along with the CAP message. When a user receives the cell-broadcast alert 35 Attorney Docket No.17214-032WOU1message 1128 on the mobile device 1124, the user selects the short URL in the displayed message, and, in response to the selection, the event-specific dynamic UI 1132 loads, dynamically including information from the CAP message 1108, such as the multimedia artifacts, which the dynamic UI then renders in a browser (not shown) running on the user mobile device 1124.

[0144] In the embodiment shown, the missing-person alert system 1100 is configured to allow users to submit a tip / sighting report via a dedicated tip / sighting report page of the event-specific dynamic UI 1132. In an example, the tip / sighting page includes user identification, free text information, and an option to upload multimedia. The tips / sighting reports may be stored in a “tip / sighting report” AS3 storage service bucket. In the present example, an AL FaaS is used to secure the tip / sighting report AS3 storage service bucket by providing a unique pre-signed URL to the dynamic UI 1132 for the upload of the tip to the tip / sighting report AS3 storage service bucket. The pre-signed URL has short duration; it is there to protect the tip / sighting report AS3 storage service bucket from malicious uploads, spam and Denial of Service attacks. The event-specific dynamic UI 1132 can directly upload the sighting report to the tip / sighting report AS3 storage service bucket with the pre-signed ULR. From the tip / sighting report AS3 storage service bucket, tips / sighting reports could be transferred (in real-time) to an separate evidence / case / file management system (not shown) of the authority 1116. In an optional embodiment of this example, the tip / sighting report AS3 storage service bucket could also be generated by an AL FaaS with a unique name based on the CAP information. This would link a particular missing-person CAP message, such as the CAP message 1108, with a corresponding tip / sighting report AS3 storage service bucket. Another AL FaaS could “close” the tip / sighting report AS3 storage service bucket as the time to submit tips / sighting reports expires by removing upload rights.

[0145] Referring now to FIG.11, and also FIGS.12A – 12F as noted, FIGS.12A – 12C are screenshots 1200(1) through 1200(3), respectively, of a mobile browser 1204 running on the mobile device 1124 of FIG.11 and displaying a landing page 1208 of the event-specific dynamic UI 1132 that the dynamic UI displays in response to the corresponding user selecting the short URL in the alert message 1128. In the example of FIG.12A, the landing page 1208 includes a photograph 1208P and a description 1208D of the missing person as taken from the CAP message 1108 (FIG.11), as well as a location 1208L of the alert region. The landing page 1208 also includes an event type 1212 (“Child Abduction”) and a “Call” button 1216 that allows the user to instantly make a call to a tip center that is set up to take such calls. FIG.12B shows more of the landing 36 Attorney Docket No.17214-032WOU1page 1208 after the user scrolls down on the landing page. As seen in FIG.12B, the landing page 1208 further includes a map 1208M showing where the missing person was abducted, along with an information link 1208I to another website where even further information about the event can be found. The map 1208M and the information link 1208I are also obtained from information within the CAP message 1108. As seen in FIG.12C, the landing page 1208 includes a reporting region 1220 that presents an “Emergency” call button 1220E and a “Fill in form” button 1220F that allows the user to select to either make an emergency phone call (e.g., to an emergency service such as the well-known 911 emergency call service) or to fill in a form 1224 (FIGS.12D and 12E) to input any tip, such as a sighting report, photograph etc., into the event-specific dynamic UI 1132.

[0146] When the user selects the “Fill in form” button 1220F on the landing page 1208 as seen in FIG.12C, the event-specific dynamic UI 1132 displays the tip form 1224 as shown in the screenshot 1200(4) and 1200(5) of FIGS.12D and 12E, respectively. In this example and as seen in FIG.12D, the tip form 1224 includes a text message field 1224T, an image-upload region 1224I, and a personal-details region 1224P that may include one or more fields that allows the user to input personal identifying information, such as the full-name field 1224F (FIG.12D), the email address field 1224E (FIG.12E), and the phone number field 1224N shown. The text message field 1224T allows the user to input any information the user wants to report, such as a location of a sighting. The image-upload region 1224I allows the user to upload one or more images, such as one or more photographs of the missing person taken during a sighting. The personal-details region 1224P provides a measure of legitimacy to the reporting, as well as information for any follow-up that may be warranted. As seen in FIG.12E, the tip form 1224 includes a “Submit tip” button 1224S that the user selects when finished with entering information into the tip form. FIG.12F is a screenshot 1200(6) of a submission-successful page 1228 that the event-specific dynamic UI 1132 (FIG.11) displays on the mobile device 1124 (FIG.11) to indicate that it has successfully received the information the user provided in the tip form 1224. In this example, the submission-successful page 1228 includes a “Back to homepage” button 1232 that, when user selected, causes the event- specific dynamic UI 1132 (FIG.11) to redisplay the landing page 1208 of FIG.12A.

[0147] Those skilled in the art will readily appreciate that the foregoing example is merely illustrative of general principles as well as a particular instantiation and is not limiting in any manner. Indeed, those skilled in the art will understand how to implement equivalents to this example using only the present disclosure as a guide and general knowledge in the art. 37 Attorney Docket No.17214-032WOU1

[0148] EXAMPLE HARDWARE AND SOFTWARE

[0149] Those skilled in the art will readily understand that a DAIS of the present disclosure, such as the DAIS 100 of FIG.1 and the DAIS 920 of FIGS.9A through 9C, and its various related components can be implemented in any suitable hardware or any combination of suitable hardware, such as any suitable conventional hardware or any combination of suitable hardware that is well known in the art. Such hardware is so well known and ubiquitous that it is not necessary to describe the hardware in any detail in this disclosure for those skilled in the art to make and use the inventions disclosed herein, including the inventions denoted by the claims appended hereto, to their fullest scope without needing to perform undue experimentation. An incomplete list of possible suitable hardware that can be used includes, but is not limited to, servers, Internet-enabling hardware (e.g., switches, bridges, routers, repeaters, gateways, cables, hubs, etc.), telecommunications networks (e.g., cellular networks), personal computers (desktops, laptops, etc.), mobile devices (e.g., smartphones, smartwatches, tablet computers, smart jewelry, smart glasses, etc.), and any hardware needed to support such components.

[0150] As those skilled in the art will readily appreciate, many of the methods, functionalities, aspects, and features of a DAIS of the present disclosure, such as the DAIS 100 of FIG.1 and the DAIS 920 of FIGS.9A through 9C, and its various related components will be implemented using software that resides on and interacts with the above-mentioned hardware. Those skilled in the art will understand 1) that the software is composed of machine-executable instructions that perform any one or more of the methods, functionalities, aspects, and features of a DAIS of the present disclosure and 2) that the machine-executable instructions will be stored in machine memory that is located in any one or more suitable locations throughout the hardware of the deployment of the DAIS at issue. The machine memory may be any type(s) of hardware memory including, but not limited to long-term storage memory and short-term storage memory of any suitable current or future-developed storage technology, collectively and singly. One or more instances of such machine memory can be located on some or all of the various components of the hardware used to implement the DAIS under consideration.

[0151] For convention, it is noted that the term “machine-readable storage medium” as used herein and in the appended claims mean the machine memory that stores the machine-executable instructions at issue, regardless how many differing types of machine memory are implicated and regardless of where the machine memory is located within the deployment hardware. Consequently, 38 Attorney Docket No.17214-032WOU1the term “medium” in “machine-readable storage medium” covers both the singular (medium) and the plural (media, mediums). It is specifically noted that the term “machine-readable storage medium” specifically excludes transient signals, including carrier-wave-based signals and pulsed signals that each carry information, such as digital encodings of machine-executed instructions.

[0152] Various modifications and additions can be made without departing from the spirit and scope of this invention. 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 invention. 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 invention.

[0153] 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 and additions may be made to that which is specifically disclosed herein without departing from the spirit and scope of the present invention. 39 Attorney Docket No.17214-032WOU1

Claims

What is claimed is:

1. A method of automatedly making alert-event information available to alerted users when alerting the alerted users to an alert event, the method comprising: receiving an alert-event message that contains a dynamic alert-event link for an event-specific dynamic user interface (UI) and further contains event information regarding the alert event; and in response to receiving the alert-event message, causing a dynamic UI builder to build the event-specific dynamic UI by extracting at least a portion of the event information and the dynamic alert-event link from the alert-event message and using the at least a portion of the event information and the event-specific dynamic link to build the event-specific UI.

2. The method of claim 1, further comprising sending the event-specific dynamic link to mobile devices carried by the users so that the alerted users can access the event-specific dynamic UI via the mobile devices using the event-specific dynamic link.

3. The method of claim 2, wherein sending the event-specific dynamic link to the alerted users comprises including the event-specific dynamic link in an alert message.

4. The method of claim 3, wherein the alert message is a cell-broadcast message.

5. The method of claim 3, wherein sending the event-specific dynamic link to the alerted users comprises including the event-specific dynamic link in a plurality of direct messages sent to individual mobile devices of the alerted users.

6. The method of claim 1, wherein the alert event has an active-warning period and the alert-event message includes expiration information indicating when the active-warning period expires, the method further comprising deactivating the event-specific UI based on the expiration information.

7. The method of claim 1, further comprising: receiving a request for a message identification (ID) corresponding to the alert event; generating the message ID; and including the message ID in the event-specific dynamic link. 40 Attorney Docket No.17214-032WOU18. The method of claim 7, wherein the message ID is selected from among a reusable set of message IDs.

9. The method of claim 8, further comprising managing the reusable set of message IDs by tracking activeness of a currently used message ID.

10. The method of claim 7, wherein the dynamic UI builder uniquely identifies the event-specific dynamic UI by the message ID.

11. The method of any one of claims 1 through 10, further comprising: receiving a selection of the dynamic alert-event link made by a selecting user of the alerted users on a mobile device; and in response to the selection being received, serving a webpage of the event-specific dynamic UI to the mobile device.

12. The method of claim 11, wherein the webpage displays the event information that the dynamic UI builder extracted from the alert-event message.

13. The method of claim 11, wherein the event-specific dynamic UI is configured to allow the selecting user to ask a question about the alert event.

14. The method of claim 13, wherein the webpage includes a query control that allows the selecting user to ask the question.

15. The method of claim 14, wherein the query control comprises a soft button for a predetermined question.

16. The method of claim 14, wherein the query control comprises a text field for receiving a free- form question.

17. The method of any one of claims 13, 14, and 16, wherein the event-specific dynamic UI uses an artificial-intelligence (AI) feature to provide an answer to the question.

18. The method of claim 17, wherein the AI feature engineers a prompt for a generative AI model using at least some of the event information from the alert-event message.

19. The method of claim 1, wherein the event-specific dynamic UI is an edge-deployed dynamic UI. 41 Attorney Docket No.17214-032WOU120. The method of claim 1, wherein the alert-event message is sent to a telecommunications network comprising a plurality of edge-computing sites, and an instance of the event-specific dynamic UI is deployed on each of the plurality of edge-computing sites.

21. The method of claim 20, wherein a central dynamic-UI system is present and includes an instantiation of the event-specific dynamic UI, and the method comprises, in response to receiving a selection of the dynamic alert-event link made by a selecting user of the alerted users on a mobile device, serving a webpage of the event-specific dynamic UI to the mobile device from the central dynamic-UI system when none of the instances of the event-specific dynamic UI on the edge-computing sites is available.

22. The method of claim 1, wherein the alert-event message is sent to a telecommunications network comprising a plurality of edge-computing sites and the alert event covers an alert-event region that includes only a subset of the edge-computing sites, the method further comprising determining which of the plurality of edge-computing sites should include an instance of the event-specific dynamic UI.

23. The method of claim 1, wherein the alert event is a person-related event involving a person, the event information includes an event type, an image of the person and a location, and the extracting and using of the at least a portion of the event information includes extracting and using the event type, the image, and the location.

24. The method of claim 23, wherein the alert event is a missing-person event.

25. The method of claim 23, wherein the event-specific dynamic UI includes a tip form that allows the alerted users to input tip information relating to the person-related event.

26. The method of claim 25, wherein the tip form includes at least one of a text-input field, and image-input region, and personal-identification-input region.

27. The method of either of claims 25 and 26, wherein the event-specific dynamic UI is configured to send the tip information to an authority handling the missing-person event.

28. The method of any one of claims 1-27, wherein the alert-event message is a common-alert protocol message. 42 Attorney Docket No.17214-032WOU129. The method of claim 28, wherein the dynamic-alert-event link is a uniform resource locator.

30. The method of claim 28, wherein the event-specific UI is implemented at a chatbot.

31. The method of claim 30, wherein the chatbot is implemented in one or more functions as a service.

32. A machine-readable medium containing machine-executable instructions for performing a method according to any one of claims 1-31.

33. A method of deploying a dynamic alert-information system (DAIS) to a warning system in operative communication with a telecommunications network that includes a plurality of cell sites, the method comprising: deploying a plurality of edge-deployed dynamic user-interface (UI) systems at a plurality of differing edge-computing sites, each in physical proximity to a corresponding group of the cell sites; and deploying a centrally deployed dynamic UI system remotely from the edge-deployed dynamic UI systems; wherein each of the edge-deployed dynamic UI systems and the centrally deployed dynamic UI system: is configured to receive an alert-event message for an alert event, wherein the alert-event message includes information concerning the alert event and a dynamic alert-event link unique to the alert event; and includes a dynamic UI builder to build an event-specific dynamic UI by extracting at least a portion of the event information and the dynamic alert-event link from the alert-event message and using the at least a portion of the event information and the dynamic alert-event link to build the event-specific dynamic UI.

34. The method of claim 33, wherein the alert-event message includes an affected-area specification defining an alert-event region, and each one of the edge-deployed dynamic UI systems is further configured to, in response to receiving the alert-event message, determine whether each one of the edge-deployed dynamic UI systems serves the alert-event region.

35. The method of claim 33, wherein the event-specific dynamic UI includes an artificial- intelligence (AI) feature that allows alerted users to ask a question regarding the alert event. 43 Attorney Docket No.17214-032WOU136. The method of claim 35, wherein the event-specific dynamic UI, upon selection by a selecting user of the alerted users of the dynamic alert-event link contained in an alert message, serves a webpage containing a query control that allows the selecting user to ask the question.

37. The method of claim 36, wherein the query control comprises a soft button for a predetermined question.

38. The method of claim 36, wherein the query control comprises a text field for receiving a free- form question.

39. The method of claim 35, wherein the AI feature includes generative AI.

40. The method of claim 39, wherein the AI feature engineers a prompt for the generative AI using at least some of the event information from the alert-event message.

41. The method of claim 33, wherein the alert event is a person-related event involving a person, the event information includes and event type, an image of the person and a location, and the extracting and using of the at least a portion of the event information includes extracting and using the event type, the image, and the location.

42. The method of claim 41, wherein the alert event is a missing-person event.

43. The method of claim 41, wherein the event-specific dynamic UI includes a tip form that allows the alerted users to input tip information relating to the person-related event.

44. The method of claim 43, wherein the tip form includes at least one of a text-input field, and image-input region, and personal-identification-input region.

45. The method of either of claims 43 and 44, wherein the event-specific dynamic UI is configured to send the tip information to an authority handling the missing-person event.

46. The method of any one of claims 33-45, wherein the alert-event message is a common-alert protocol message.

47. The method of claim 46, wherein the dynamic-alert-event link is a uniform resource locator.

48. The method of claim 46, wherein the event-specific UI is implemented at a chatbot. 44 Attorney Docket No.17214-032WOU149. The method of claim 48, wherein the chatbot is implemented in one or more functions as a service.

50. A method of automatedly making alert-event information available to subscribers when subscribers are alerted to an alert event, the method comprising: receiving, at an edge-deployed dynamic user-interface (UI) system, an alert-event message that contains event information regarding the alert event, wherein the event information includes an alert-event region for the alert event; in response to receiving the alert-event message: determining, by the edge-deployed dynamic UI system, whether or not the edge-deployed dynamic UI system serves the alert-event region; when the edge-deployed dynamic UI system does not serve the alert-event region, not activating, by the edge-deployed dynamic UI system, an event-specific dynamic UI at the edge-deployed dynamic UI system; and when the edge-deployed dynamic UI system serves the affected area, activating, by the edge-deployed dynamic UI system, the event-specific dynamic UI at the edge- deployed dynamic UI system.

51. The method of claim 50, wherein the event-specific dynamic UI includes an artificial- intelligence (AI) feature that allows alerted users to ask a question regarding the alert event.

52. The method of claim 51, wherein the event-specific dynamic UI, upon selection by a selecting user of the alerted users of the dynamic alert-event link contained in an alert message, serves a webpage containing a query control that allows the selecting user to ask the question.

53. The method of claim 52, wherein the query control comprises a soft button for a predetermined question.

54. The method of claim 52, wherein the query control comprises a text field for receiving a free- form question.

55. The method of claim 51, wherein the AI feature includes generative AI.

56. The method of claim 55, wherein the AI feature engineers a prompt for the generative AI using at least some of the event information from the alert-event message. 45 Attorney Docket No.17214-032WOU157. A machine-readable medium containing machine-executable instructions for performing a method according to any one of claims 50-56.

58. A method of automatedly answering a question from an alerted user about an alert event, the method comprising: receiving, at an event-specific dynamic user interface (UI), an event-alert message that contains event information regarding the alert event; receiving, at the event-specific dynamic UI and from the alerted user, the question about the alert event; generating an artificial-intelligence (AI) prompt by combining at least a portion of the information from the system event-alert message with at least a portion of the question from the user; querying an AI tool using the AI prompt; receiving a response from the AI tool based on the AI prompt; and displaying, by the event-specific dynamic UI, the response to the alerted user.

59. The method of claim 58, wherein the AI tool comprises a generative AI tool.

60. The method of claim 58 or 59, wherein the question is a predetermined question.

61. The method of claim 58 or 59, wherein the question is a freeform question.

62. A machine-readable medium containing machine-executable instructions for performing a method according to any one of claims 58-62. 46 Attorney Docket No.17214-032WOU1

Images