EP2426655A1

EP2426655A1 - Internet alert broadcaster

Info

Publication number: EP2426655A1
Application number: EP10305959A
Authority: EP
Inventors: Carmine Lausi; Giuseppe Falivene; Angelo Lattuada
Original assignee: Alcatel Lucent SAS
Current assignee: Alcatel Lucent SAS
Priority date: 2010-09-06
Filing date: 2010-09-06
Publication date: 2012-03-07

Abstract

An alert terminal (AT1; AT2; AT3) comprises means for receiving a message from a central alert broadcasting unit (CABU) via multicast, characterized in that it further comprises:
- means (GCS) for storing the geographical coordinates of this terminal,
- means (MA) for extracting from a received message area data defining a target area,
- means (MA) for determining whether the location defined by the geographical coordinates of this terminal is included in the target area defined by the extracted area data,
- and means (MA) for performing actions requested in the received message only if the result is positive.

Description

BACKGROUND OF THE INVENTION

Field of the invention

The present invention generally relates to an alert system. It can be used for providing a warning of imminent danger to the public.
The system is able to complement national, state, provincial, regional, and community emergency broadcast systems that currently do not have the capability of reaching several persons (e.g. not listening to a radio, or not watching television), at the time of an emergency. The system comprises a central alert unit controlled by an administration, and a plurality of alert terminals within communities such as homes, businesses, schools, hospitals, etc, to provide various alert messages and alert actions with loudspeakers, displays, sirens, bells, flashing lights and actuators (if available).

Description of the prior art

The world community is highly demanding (mainly after tsunami in December 2004) a fast "globally comprehensive early warning system, rooted in existing early warning systems and capacities" (ref. first recommendation of 3^rd International Conference on Early Warning, Bonn 2006). This early warning system shall be able to alert in a very short time the affected people in any geographical area (even wide high-density areas). That is a not yet solved technical problem.
The most popular fast communication medium in the world is the phone call (fixed and mobile), so an early warning system able to disseminate Alert Messages via fixed and mobile phone calls would be the most powerful and appropriate one to comply with international demand.
Normally this system should use, per each end user/phone number to be alerted, a telephone channel that should be busy for all the time of the call. This would cause a big limitation, since an alert system with n telephone channels available would be able to inform n end users/phone numbers at most at the same time.
E.g. assuming that:

the average duration of the call (set up phase + subscriber's answer + conversation/playing of announcement + release) is equal to 1 minute;
the alert system has 100 telephone channels available;

On the other hand, the existing alert systems based on other communication media (e.g. radio/TV, SMS, Internet, e-mails, sirens) have other even bigger limitations and/or disadvantages, therefore these solutions are not good enough to comply with international requirements. E.g. during the night a warning dissemination via alert systems able to use only SMS and/or radio/TV is not effective since it cannot reach in time most of the people. Alert Systems based on sirens can wake up the people, but they cannot give enough information and their deployment in very large areas (e.g. like the areas impacted by the tsunami on 26/12/04) would be too expensive.
A possible partial solution of the above mentioned technical problem is the usage of "Alert Terminals", to be installed in big communities (e.g. hospitals, schools, offices, companies,...) and interconnected somehow to a "central server" able to trigger them in case of emergencies. When triggered, the alert terminals are able to inform people belonging to the communities about the received alert.
In this way the dissemination of the alert messages is highly speed up, but the performances of the existing types of "Alert terminals" (in terms of number of end users alerted in a given time) are in any case limited by the number of channels available between the "central server" and the terminals. So only a limited number of alert terminals can be triggered in a short time. Therefore, in some types of emergencies, only a part of the population (i.e. who belongs to "high priority" communities) can be alerted in time. This limitation hinders also the usage of alert terminals in private houses, since they should be handled with a lower priority, i. e. they might receive the alert messages too late.
Thus, there is a need to provide a technical solution for alerting a higher number of people in a shorter time.

SUMMARY OF THE INVENTION

A first object of the invention is an alert terminal comprising means for receiving a message from a central alert broadcasting unit via multicast, characterized in that it further comprises:

means for storing the geographical coordinates of this terminal,
means for extracting from a received message area data defining a target area,
means for determining whether the location defined by the geographical coordinates of this terminal is included in the target area defined by the extracted area data,
and means for performing actions requested in the received message only if the result is positive.

According to a peculiar embodiment of the terminal according to the present invention, said means for determining whether the location defined by the geographical coordinates of this terminal is included in the target area defined by the extracted area data, comprise means for comparing the geographical coordinates of this terminal with the coordinates of the vertices of a polygon delimiting the target area.
According to another peculiar embodiment of the terminal according to the present invention, means for determining whether the location defined by the geographical coordinates of this terminal is included in the target area defined by the extracted area data, comprise means for comparing the geographical coordinates of this terminal with the coordinates of points included in a circle defined by the coordinates of its centre, and by its radius.
A second object of the invention is a central alert broadcasting unit comprising means for multicasting an alert message to a plurality of alert terminal, characterized in that said means for multicasting an alert message comprise means for generating an alert message containing area data defining a target area.
According to a peculiar embodiment of the central alert broadcasting unit according to the invention, said area data defining a target area are the coordinates of the vertices of a polygon.
According to another peculiar embodiment of the central alert broadcasting unit according to the invention, said area data defining a target area are the coordinates of the centre of a circle, and its radius.
A third object of the invention is a terminal for controlling a central alert broadcasting unit according to the invention characterized in that it comprises means for supplying, to this unit, data defining a target area by the coordinates of the vertices of a polygon.
A fourth object of the invention is a terminal for controlling a central alert broadcasting unit according to the invention, characterized in that it comprises means for supplying, to this unit, data defining a target area by the coordinates of the centre of a circle, and its radius.
Other features and advantages of the present invention will become more apparent from the following detailed description of embodiments of the present invention, when taken in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to illustrate in detail features and advantages of embodiments of the present invention, the following description will be with reference to the accompanying drawings. If possible, like or similar reference numerals designate the same or similar components throughout the figures thereof and description, in which:

Figure 1 represents an alert system comprising one embodiment of the central alert broadcasting unit according to the invention, and several embodiments of the alert terminal according to the invention.
Figure 2 represents the functional diagram of an embodiment of the alert terminal according to the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Figure 1 represents an alert broadcasting system comprising one embodiment of the central alert broadcasting unit according to the invention, and several embodiments of the alert terminal according to the invention.
This alert broadcasting system comprises:

A warning organization terminal WOT.
A central alert broadcasting unit CABU that can be activated via the warning organization terminal WOT, and that can multicast a message via the Internet IPN.
A plurality of alert terminals, such as the alert terminals AT1, AT2, AT3, that are exemplary embodiments of the alert terminal according to the invention.

The alert terminals AT1, AT2, AT3 use various access technologies for being permanently linked to the Internet IPN. For instance, the alert terminal AT1 is permanently linked to the Internet by an asynchronous digital subscriber line ADSL supported by a classical public switched telephone network. The alert terminal AT2 is permanently linked to the Internet by a WiMAX wireless link WL1. The alert terminal AT3 is permanently linked to the Internet by a wireless UMTS link WL2. In all these cases, the message copying for multicast is made by routers inside the Internet. The UMTS network, the WiMAX network, and the classical public switched telephone network do not intervene in the message copying. They are only used as access networks to transport the copied messages.
Each of the alert terminals AT1, AT2, AT3 access to the Internet through a service provider that offers an Internet protocol (IP) multicast service, so that the central alert broadcasting unit CABU will be able to send commands to the alert terminals AT1, AT2, AT3 by IP multicast. In particular, this service provider owns routers R1, R2, R3, R4 that support IP multicast. Router R1 is linked to an ADSL access equipment that connects the alert terminal AT1 to the Internet. Router R2 is linked to a WiMAX base station BS1 that connects the alert terminal AT2 to the Internet. Router R3 is linked to an UMTS base station BS2 that connects the terminal AT3 to the Internet. Router R4 is linked to the central alert broadcasting unit CABU.
Each of the alert terminals AT1, AT2, AT3 is linked to some audio broadcasting equipment, such as a set of loudspeakers, respectively LS1, LS2, LS3, which can alert a community such as a school, a hotel, a business, etc. In such communities, the corridors are often equipped with loudspeakers, linked to appropriate amplifiers, for broadcasting audio messages (for calling a person, for instance). The alert terminals AT1, AT2, AT3 can also pilot sirens, bells, actuators e.g. to stop gas distribution, to take elevators to the floor, etc.
Networks using IP multicast deliver source content to multiple users (hosts or receivers) that are interested in a same data stream. A multicast channel refers to the combination of a content source IP address and an IP Multicast group address to which the content is being broadcasted. Unlike unicast/broadcast addresses, multicast groups do not have any physical or geographic boundaries, and receivers interested in joining can be located anywhere on a network or the Internet as long as a multicast-enabled path has been established.
To receive a particular multicast data stream, hosts must join a multicast "group" by sending an Internet Group Management Protocol (IGMP) message to their local multicast router. IGMP allows individual receivers to independently join or leave a group. Adjacent routers also use this protocol to communicate.
Content is identified by "(S, G)" where G is the multicast group and S is the sending source IP address. The multicast group addresses belong to the Class D IP address space. The sender sends a single datagram (from the sender's unicast address) to the multicast address, and the intermediary routers take care of making copies and sending them to all receivers that have registered in the group.
In unicast routing, each router examines the destination address of an incoming packet and looks up the destination in a table to determine which interface to use in order for that packet to get closer to its destination. Routers use the Protocol-Independent Multicast protocol (PIM) to build "distribution trees" for multicast routing in the network. Routers replicate source content at any point where the network paths diverge, and use Reverse Path Forwarding (RPF) techniques to ensure content is forwarded to the appropriate downstream paths without routing loops.
PIM protocol is a family of multicast routing protocols for Internet Protocol networks that provide one-to-many and many-to-many distribution of data over a LAN, WAN or the Internet. It is termed protocol-independent because PIM does not include its own topology discovery mechanism, but instead uses routing information supplied by other traditional routing protocols such as the Border Gateway Protocol (BGP).
Multicast-capable routers dynamically create distribution trees that control the path the content travels through the network. PIM uses two types of multicast distribution trees: "shared trees" and "source trees." Because members of multicast groups can join or leave at any time, distribution trees must be updated constantly. When all the active receivers on a particular branch stop requesting traffic for a particular multicast group, routers along the path will "prune" that branch from the distribution tree and stop forwarding traffic down that branch. If one receiver on that branch becomes active and requests the multicast traffic, the router will dynamically modify the distribution tree and resume forwarding traffic over that branch.
The implementation of known IP Multicasting protocols, such as PGM and SMART, is within the scope of a man skilled in the art.
When the warning organization has to disseminate an alert message to a given target area, it accesses to the central alert broadcasting unit CABU by a classical access control procedure preventing malicious alerts. The warning organization supplies to the alert broadcasting unit CABU, via the terminal WOT:

The identity of a "multicast group" of alert terminals.
An "Originator Identifier Code", in order to identify the specific warning organization that is sending the alert (e.g. Civil Protection).
A "Terminal Identifier Type", in order to identify the type of alert terminals which the command is directed to, e.g. with/without feedback capabilities.
An "End User Identifier Type", in order to identify the type of end users which the command is directed to, e.g. authority, public building, private house, etc.
A "Command Type".
A "Command Number".
An "Alert Type" including a code (and a "subcode" for advanced types of terminals if any).
"Area data" defining the target area.

If the "Command Type" is a "real time speech announcement", the warning organization records an appropriate speech announcement in the central alert broadcasting unit CABU.
Practically, an operator of the warning organization has to follow the simple and fast following procedure:

a) The operator writes, in a graphic user interface (on the terminal WOT), the name of a region, a mountain, or a town, near the target area. Software means then display, on the terminal WOT, a map including this region, mountain, or town.
b) Using a mouse and a "zoom" button, the operator can focus on the target area.
c) If the target area can be delimited by a polygon, the operator clicks on a button activating the function called "polygon". Then the operator clicks on the vertices of the polygon (for defining the target area). The geographical coordinates of the vertices are determined. The polygon is displayed on the screen.
d) Or if the target area can be delimited by a circle, the operator clicks on a button activating the function called "circle". Then the operator clicks on the centre of the circle, and on a point of the circumference (delimiting the target area). The geographical coordinates of the centre, and the radius, are determined. The circle is displayed on the screen.

Afterwards the warning organization operator inputs all the other data to be supplied to the central alert broadcasting unit CABU (see above).
Then the central alert broadcasting unit CABU multicasts a single alert message to all the alert terminals that have been previously registered in a customer multicast group in the central alert broadcasting unit CABU, whatever are their geographical locations. The alert message carries identification data designating the multicast group selected by the warning organization. The alert message also contains the area data that define the geographical target area, so that the alert message will activate only the terminals that are in the target area. Each alert terminal comprises means for determining whether it is located inside or outside the target area, by comparing its current location with the targeted area as defined by the area data contained in the received alert message. This method provides the possibility to dynamically and precisely define the target area.
For instance, on figure 1, when the warning organization activates, via the terminal WOT, the central alert broadcasting unit CABU, the latter sends a single IP multicast message that contains a set of information that is adapted to be multicast up to a multicast group of terminals corresponding to the terminals located in the target area. In the example represented on figure 1, the multicast group comprises the alert terminals AT1, AT2, AT3. The router R4 receives the message from the central alert broadcasting unit CABU and makes three copies that are respectively sent to the routers R1, R2, R3 for delivery to the alert terminals AT1, AT2, AT3, respectively.
The use of IP multicasting technology enables the dissemination of messages to a (theoretically) unlimited number of destinations (e.g. all the citizens of a wide high-density area) in a few seconds.
Every alert terminal can join and leave a multicast group dynamically. Newly joined host in a group sends an IGMP (Internet Group Management Protocol) message to a predetermined group multicast address for declaring membership. A local multicast router receives the message and establishes necessary routing path. The router sends host membership query to all multicast hosts on a subnet. Each host responds with a "host Membership report" for each group to which it belongs (sent to the group address).
Once registered, the host receives traffic sent to that multicast group. To keep multicast group memberships up-to-date and prevent forwarding traffic unnecessarily, multicast routers periodically query hosts for their interest in receiving multicast traffic using IGMP membership query messages. The frequency of the IGMP membership query messages is a tunable parameter in most multicast routers. By default, it is typically sent every sixty seconds. Hosts respond to these queries with IGMP membership report messages that list the multicast groups for which they wish to receive traffic. If there is no response to three consecutive IGMP membership query packets for a particular group, the multicast router stops forwarding traffic to that group.
The IP multicast message is an unconfirmed push service, meaning that the originator of the message will not know who has received the message, except if the terminal is adapted to elaborate and send a feedback message.
The alert multicast message text is a command that is coded according to the general format described below:

1) An authentication part, in order to check that the command arrives from an authorized user. It includes an "Originator Identifier Code", in order to identify the specific warning organization that is sending the alert (e.g. Civil Protection).
2) A "Terminal Identifier Type", in order to identify the type of alert terminals which the command is directed to, e.g. with/without feedback capabilities.
3) An "End User Identifier Type", in order to identify the type of end users which the command is directed to, e.g. authority, public building, private house, etc.
4) "Area data", i.e.:
1. a. coordinates (e.g. in WGS84 format) of vertices of a polygon that delimitates the geographical target area where the message has to be disseminated,
2. b. or coordinates of the center and value of the radius of a circle that delimitates the target area.
5) A "Command Type" indicating: dissemination of a message, configuration update, test, etc.
6) A "Command Number".
7) An "Alert Type" including a code (and a "subcode" for advanced types of terminals if any).
8) A "Message Audio File" i.e. an audio file to be played.
9) A "Message Text" containing the text of a message to be disseminated via "text to speech" and/or to be displayed on screens (when available in the alert terminal or in end user's environment).
10) A "Message Number" in order:
- to identify a pre-recorded announcement stored in the terminal and to be played, or
- to indicate a "real time announcement" i. e. a message audio file recorded in real time by the warning organization, via the terminal WOT, in order to provide specific information about the upcoming event.
11) "Additional information" (if any).

The parts of a same command are separated by a delimiter (e.g. the character '^*'). Some of the above parameters can be missing (e.g. "Message Audio File"): in this case the relevant part of the command is empty and there are 2 consecutive delimiters (e.g. '^**'). The complete command is delimited by another delimiter (e.g. the character '#') at the beginning and at the end of the command.
So a complete command can have the following format:

#<Originator Identifier Code>^*<TerminaL Identifier Type>^*<End User Identifier Type>^*< Area Data>^*<Command Type>*<Command Number>^*<Alert Type>^* <Message Audio File>^*< Message Text>^*<Message Number>^*<Additional information>#

The mandatory parameters are:

"Originator Identifier Code"
"Command Type"
"Command Number"

The other parameters can be missing. In this case, they assume the following default values:

1) "Terminal Identifier Type" = All (all the types of alert terminals)
2) "End User Identifier Type" = All (all the types of end users)
3) "Area Data" = All (all the terminals, independently from their geographical position)
4) "Alert Type" = None (When the alert type is not relevant for command execution).
5) "Message Audio File" = None
6) "Message Text" = None
7) "Message Number" = None
8) "Additional information" = None

The alert terminals AT1, AT2, AT3... need to be configured at installation phase with the "Geographical Coordinates" of the respective places where they are installed, and with the terminal identifier type and end user identifier type corresponding to the type of alert terminal and end user type. This configuration may be done by:

the authority providing the terminal (e.g. the town council),
or an employee of the shop that is selling the terminal,
or a technician that installs the terminal at end user premises,
or by the end user itself.

Each terminal shall be equipped with a key enabling a self-test of the equipment. This self-test that can be triggered by the end user, to check correct behavior.
A terminal shall be able to perform the actions described below (if the relevant parameter is present in the received command):

1) To perform the authentication of the received command and to apply the behavior relative to the specific warning organization (identified by the "Originator Identifier Code").
2) To check that its own "Terminal Identifier Type" and "End User Identifier Type" correspond to the ones contained in the command, and to check that its own "Geographical Coordinates" belong to the polygon or circle defined by the "Area Data" contained in the command.
3) If all the previous checks are positive, to apply the actions corresponding to the "Command Type":
1. A) If the "Command Type" is "message dissemination", applying the action(s) corresponding to the specific "Alert Type" e.g.:
  - to pilot actuators and/or bells according to preconfigured data associated to each "Alert Type",
  - to play the "Message Audio File" via the audio broadcasting equipment,
  - to derive, from the "Message Text", an audio announcement via text-to-speech and to broadcast it via the audio broadcasting equipment,
  - to display the "Message Text" on the screens / panels (if available),
  - to open the speech path towards the audio broadcasting equipment, if the "Message Number" indicates that a real time announcement or a pre-recorded announcement has to be played.
2. B) If the "Command Type" is "download": to download the data associated to the specific "Command Number" (e.g. to predispose itself to receive a new "Message Audio File" and to store it in its own data base.
3. C) If the "Command Type" is "test": to apply the test actions associated to the specific "Command Number" (e.g. to play a test announcement).

The alert terminals can be implemented with different "capability levels", i.e. a simplified and cheaper version might be unable to perform some of the above actions. In particular the announcement will be played according to the "capability level" of the terminal, on the ground of the following priorities:

a) if the alert terminal is able to play a message audio file and if one is present: only message audio file playing will be applied, otherwise
b) if the alert terminal has text-to-speech capability and if a text is present, only text-to-speech announcement will be applied, otherwise
c) if the alert terminal is able to open the speech path towards audio broadcasting equipment and the "Message Number" indicates that a "real time announcement" has to be played, only "real time announcement" will be applied, otherwise
d) if the alert terminal is able to play a pre-recorded announcement and the "Message Number" is present, only the pre-recorded announcement associated to the "Message Number" will be applied, otherwise
e) no announcement will be played.

So with a number "N" of distributed alert terminals inside communities, a centralized alert broadcasting system will be able to disseminate simultaneously messages to N communities. Inside the communities the message will be broadcasted via "Audio Broadcasting Equipments" (e.g. loudspeakers, sound/amplifier systems) available in the community building / area. In this way the system provides a huge increase of the number of alerted people in a given time.
The time required for message broadcasting is not significantly dependent from the number of terminals, so the latter can be installed in all the type of "communities" (big and small), even in all the private houses. So the technical solution of the present invention overcomes the limitations of the existing types of alert terminals, mentioned at the end of the section "Description of the prior art".
Some internet access suppliers propose an Internet access via satellites. Thus an alert terminal according to the invention could be based on a satellite communication network. This option is important since it could allow the dissemination of messages during and after big calamities, when all the other communications media are out of service or overloaded, e.g. in order to instruct the population how to face the emergency. This option is suitable also for dissemination of alerts to villages in areas not covered by other telecommunications equipments.
An alert terminal may be able to pilot:

bells and/or sirens, for the customers that have no loudspeakers / sound/amplifier systems available: in this case the number and duration of ringing will differentiate an emergency from the others (analogously to the method used by the ships).
"actuators" locally available, e.g. to stop gas distribution, to take elevators to the ground floor, etc.

The alert terminals might be commercialized in 2 basic configurations.

1) A small and cheap configuration for "Consumers" / small communities (e.g. private houses, private buildings, joint ownerships ...) with standard predefined announcements (besides the possibility to deliver real time announcements) and standard piloting of bells and sirens.
2) A bigger configuration for "Enterprises" / big communities (e.g. factories, companies, schools, hospitals, public offices ...) with the possibility to customize the predefined announcement (e.g. in order to provide more detailed instructions for evacuation, taking in account the physical layout of the customer site) and the number and duration of ringing of bells and sirens. Besides this configuration should allow the customer (via an authentication procedure) to activate autonomously the terminal, selecting a predefined announcement or recording a real time announcement: in this way the customer could use the terminal also for local emergencies (e.g. fire, emission of dangerous gases ...) and for the broadcasting of other types of announcements (e.g. information to employees and/or clients, advertisements...).

Figure 2 represents the functional diagram of an embodiment AT1 of the alert terminal according to the invention. It comprises:

An ADSL interface ADSLI for receiving messages,
a message analyzer MA,
a storage GCS for storing the geographical coordinates of the terminal,
a message data base MDB,
a video board VB that may be connected to a large display D1,
an audio board AB that may be connected to audio broadcasting equipment LS1,
a text to speech converter TTS,
an output interface 01 that may be connected to a flashing light FL (as well as sirens SI, actuators AC, etc.).

The message analyzer MA comprises software means for:

extracting from a received alert message area data defining a target area,
determining whether the location defined by the geographical coordinates of this terminal (supplied by the storage GCS) is included in the target area defined by the extracted area data,
then implementing the actions requested in the received alert message only if the result is positive.

The message analyzer MA comprises software means for comparing the geographical coordinates of this terminal with the coordinates of points included in a polygon defined by the coordinates of its vertices.
The message analyzer MA also comprises software means for comparing the geographical coordinates of this terminal with the coordinates of points included in a circle defined by the coordinates of its centre, and its radius.
The message analyzer MA parses the received text message and it decides whether or not to execute one or more actions according to a predetermined logic. For example:

Step 1: Determining whether or not the message is for the terminal AT1 by checking: "Originator Identifier Code", "Terminal Identifier Type", "End User Identifier Type", "Polygon Coordinates" or "Center-Radius".
Step 2: If the message is for the terminal AT1, determining the action(s) to be executed in the following way:
- Case 1 - If the "Command Type" is "message dissemination", applying the action(s) corresponding to the specific "Command Type", "Command Number", and "Alert Type" e.g.:
  - to pilot actuators/sirens/bells S1 according to preconfigured data associated to each "Alert Type",
  - to play a "Real Time Message Audio File" via the audio board AB and the audio broadcasting equipment LS1,
  - to derive, from a received "Message Text", an audio announcement via the text-to-speech converter TTS, and to broadcast it via the audio board AB and the audio broadcasting equipment LS1, and to display the "Message Text" via the video board VB and the display D1 (if available).
- Case 2 - If "Command Type" = "Preconfigured Message Dissemination", the "Message Number" carried in the received alert message is used to access the Message Data Base MDB, in order to get both the audio file to be played and the text to be displayed. In case the text file does not exist, no text will be displayed (only audio file will be played). In case the audio file does not exist, the text file will be sent to the text to speech converter TTS, in order to be converted into an audio file to be played via the sound board AB1 and the audio broadcasting equipment LS1.
- Case 3 - If "Command Type" = "Configuration Message", the "Message Text" and/or the "Message Audio File" carried in the received alert message is used to replace the "File Text" and/or the "Audio file" stored in the message data base MDB at the entry "Message Number". In case the "Message ID" does not exist in the data base MDB, a new entry is created.

A first variant of the alert terminal and of the central alert broadcasting unit according to the invention comprise additional software means in order to provide the "end users" (i. e. communities and individuals owning such an alert terminal) with the possibility to send a notification and some data to the central alert broadcasting unit CABU. In fact the alert message is a text/audio message that may contain a request for notification/confirmation of the reception of the alert message and request for some data (e.g. damages on the end user's building caused by a calamity, number of wounded people, etc.). The response sent by the alert terminal to the central alert broadcasting unit CABU is an "instant message".
The alert message sent by the central alert broadcasting unit CABU contains two additional fields:

a) "Address for notifications" (i.e. the IP address of the central alert broadcasting unit CABU).
b) "RAND number" (i.e. a random number calculated by the central alert broadcasting unit CABU with a RAND routine).

The central alert broadcasting unit CABU can be distributed and physically dimensioned according to the number of deployed alert terminals, and the time requested for data collection, therefore the "Address for notifications" can be different depending on the geographic locations of the alert terminals.
The central alert broadcasting unit CABU shall have the capability to receive "instant messages" and to analyse the contained data. It shall include the received data into its data base that also will contain the respective identities and geographical coordinates of the terminals (introduced at the time of provisioning terminals). After the reception of all the data, the central alert broadcasting unit CABU shall issue a report according to administrations requirements (e.g. calculating the totals, displaying the results with different colors on a map, etc.).
A second variant of the alert terminal and of the central alert broadcasting unit according to the invention comprise additional software means in order to collect data from the alert terminals following another method too. In this case when the user inputs the data requested in the alert message, e. g. by means of a keyboard. The alert terminal shall store them in its memory. After some time the central alert broadcasting unit CABU shall gradually interrogate all the alert terminals, asking to send the stored data (if any).
The alert terminal shall have also the possibility to send automatically (without user intervention) some data, such as the results of actions performed by the terminal itself.
The capability to collect data from the alert terminals gives to the Warning Organization the possibility to ask and collect data in a very short time from an even huge number of people. E.g. in case of calamities, the Civil Protection can quickly have a report on the damages caused by calamities and identify the areas to be addressed by rescue teams with higher priority, and even to properly dimension these teams.
This capability can be very useful for many other applications too, even commercial. E.g. this feature will enable and ease applications such as polls, televoting, order collections, etc.

Claims

An alert terminal (AT1; AT2; AT3) comprising means for receiving a message from a central alert broadcasting unit (CABU) via multicast, characterized in that it further comprises:
- means (GCS) for storing the geographical coordinates of this terminal,

- means (MA) for extracting from a received message area data defining a target area,

- means (MA) for determining whether the location defined by the geographical coordinates of this terminal is included in the target area defined by the extracted area data,

- and means (MA) for performing actions requested in the received message only if the result is positive.
An alert terminal (AT1; AT2; AT3) according to claim 1, characterized in that said means (MA) for determining whether the location defined by the geographical coordinates of this terminal is included in the target area defined by the extracted area data, comprise means for comparing the geographical coordinates of this terminal with the coordinates of the vertices of a polygon delimiting the target area.
An alert terminal (AT1; AT2; AT3) according to claim 1, characterized in that said means (MA) for determining whether the location defined by the geographical coordinates of this terminal is included in the target area defined by the extracted area data, comprise means for comparing the geographical coordinates of this terminal with the coordinates of points included in a circle defined by the coordinates of its centre, and by its radius.
An alert terminal (AT1; AT2; AT3) according to claim 1, characterized in that it further comprises:
- means for receiving a request for notification/confirmation of the reception of an alert message and for transmission of some data, to a central alert broadcasting unit (CABU);

- means for giving to the end user the possibility to provide the requested data and for storing these data in the alert terminal;

- and means for sending, to a central alert broadcasting unit (CABU), a message containing a notification/confirmation of the reception of an alert message, and containing the requested data.
An alert terminal (AT1; AT2; AT3) according to claim 4, characterized in that:
- said means for receiving a request for notification/confirmation of the reception of an alert message and for transmission of some data, comprise means for extracting from an alert message: a request for notification/confirmation of the reception of this alert message and for transmission of some data, a destination IP address, and a random number;

- and said means for sending, to a central alert broadcasting unit (CABU), a message containing a notification/confirmation of the reception of an alert message, and containing the requested data, comprise means for sending this message to the received IP address, and after a delay corresponding to the received random number.
An alert terminal (AT1; AT2; AT3) according to claim 4, characterized in that:
- said means for receiving a request for notification/confirmation of the reception of an alert message and for transmission of some data, comprise means for extracting, from an alert message, a request for notification/confirmation of the reception of this alert message and for transmission of some data;

- said means for receiving a request for notification/confirmation of the reception of an alert message and for transmission of some data, are adapted for receiving a second request and for extracting, from this second request, an IP destination address;

- and said means for sending, to the central alert broadcasting unit (CABU), a message containing a notification/confirmation of the reception of an alert message, and containing the requested data, comprise means for sending this message to the received IP address only after the reception of the said second request.
A central alert broadcasting unit (CABU) comprising means for multicasting an alert message to a plurality of alert terminal (AT1; AT2; AT3), characterized in that said means for multicasting an alert message comprise means for generating an alert message containing area data defining a target area.
A central alert broadcasting unit (CABU) according to claim 7, characterized in that said area data defining a target area are the coordinates of the vertices of a polygon.
A central alert broadcasting unit (CABU) according to claim 7, characterized in that said area data defining a target area are the coordinates of the centre of a circle, and its radius.
A central alert broadcasting unit (CABU) according to claim 7, characterized in that said alert message contains a request for a response message, an IP destination address for this response message, and a random number defining a delay to send the response message.
A central alert broadcasting unit (CABU) according to claim 7, characterized in that it further comprises means for gradually interrogating a plurality of alert terminals so that they respectively send, to this central alert broadcasting unit (CABU) response messages containing data provided by these alert terminals.
An alert system characterized in that it comprises a central alert broadcasting unit (CABU) according to one of the claims 7-11; and at least one alert terminal (AT1; AT2; AT3) according to one of the claims 1-6.
Terminal (WOT) for controlling a central alert broadcasting unit (CABU) according to claim 8, characterized in that it comprises means for supplying, to this unit, data defining a target area by the coordinates of the vertices of a polygon.
Terminal (WOT) for controlling a central alert broadcasting unit (CABU) according to claim 9, characterized in that it comprises means for supplying, to this unit, data defining a target area by the coordinates of the centre of a circle, and its radius.
Terminal (WOT) for controlling a central alert broadcasting unit (CABU) according to claim 10, characterized in that it comprises means for supplying, to this unit, a request for notification/confirmation of the reception of an alert message and for transmission of some data to be collected from alert terminals)