EP3058543A1 - System for exchanging information between different users and different authorities - Google Patents

Abstract

The invention relates to a system for exchanging information between different users, signed up for the system, and different authorities, associated with geographical areas such as territory groups. Said system includes: - a common data storage platform (P); - terminals of the different users (Ui), each terminal including a means for determining the current geographic location of the terminal, a "signaling" interface enabling the user to signal an Event geolocated by an authority, and a means for sending, to the platform storing them, the current geolocation of the terminal and the signaled Event; and - terminals of the different authorities (Ci), each terminal including a means for sending, to the platform storing same, Alerts sent out by the authority in question. The system also includes: - a means for sending an Event, stored in the platform, to the authority associated with the geographical area where the Event was geolocated and time--stamped; and - a means for sending an Alert, stored in the platform, to a user, registered with the system and the terminal of which is geolocated in an area for broadcasting the Alert defined by the authority in question. The invention also relates to the corresponding information exchange method.

Description

 SYSTEM FOR EXCHANGING INFORMATION BETWEEN DIFFERENT

 USERS AND DIFFERENT AUTHORITIES

DESCRIPTION

TECHNICAL AREA

The invention relates to a system for exchanging information between different users and different authorities.

 The scope of the invention relates to the exchange of information between users and different authorities, for example between citizens and local authorities allowing citizens to report events occurring in their communities ("a Event "), and communities to issue alerts to citizens in a relevant geographic area, related to

Events reported or totally unrelated to them ("an Alert").

 This exchange between citizens and communities is beneficial to fluidize, secure and facilitate the well-being of users within these communities by involving them further in the operation of the community.

 The exchange of information between users and authorities is via an application previously downloaded to a smartphone, or smartphone, or via an interface of a dedicated website, this information is thus made available to users of the system , sedentary or on the move.

STATE OF THE ART [0005] It is known from document US Pat. No. 7,301,450, an Alerts communication system emitted by a communication center for citizens, attached for example to a municipality, intended for Citizens adhering to the system and having chosen to receive this type of Alert. In this system, the communication center collects on the internet, through government sites or other databases, Alerts to the public, such as Weather Alerts, and transmits them by SMS, email or via a dedicated website, users who have previously declared themselves willing to receive this type of information. This information exchange system is suitable for large-scale Alerts but is ineffective for Alerts relating to more localized events. no report will be made on a government site. In addition, although the sources providing the communications centers with information are relatively reliable, they do not, however, prove to be sufficiently reactive when a sudden, isolated, localized event occurs, such as the occurrence of water damage or the falling of hailstones in a city.

 [0006] Furthermore, in a completely different field of application, the driver assistance systems allow users to declare events, such as the occurrence of a traffic accident or a slowdown, via a network. navigation device or an application downloaded to their Smartphone, so that this Event is reported to users in the area where the Event occurred. Such is the case of the system described in the document FR 2 982 986. However, if this system actually allows the declaration of the annoying event or a problem, it does not allow the resolution, the events declared by users. remaining to the sole knowledge of those users who are not yet able to provide a solution to the inconvenience caused by the Event. STATEMENT OF THE INVENTION

The invention aims to solve the problems mentioned above by allowing a bilateral exchange of information between on the one hand different users of the system and on the other hand different authorities, which will cooperate to provide virtually real-time information on a particular fact, and allow a treatment of this fact by the competent authorities, either by solving the problem caused by this fact or by disseminating to the largest number of users information on this fact.

 More particularly, the invention relates to a technical solution and software for reporting an event by means of mobile or fixed terminals, processing these events by means of business portals by authorities and dissemination of alerts from these business portals. with these mobile or fixed terminals at the scale of a territory from a clean site (industrial site, building) to the national territory of a country or state.

 More specifically, the present invention relates to a system for exchanging information between different users registered in the system and different authorities associated with geographical areas such as local authorities, including:

 - a common data storage platform

- terminals of different users, each including A means of current geolocation of the terminal,

 • a "signaling" interface allowing the user to signal a geolocated event and preferably time stamped within one or more authorities (according to the event's qualification),

 Means of transmission to the platform which stores them, of the current location of geolocation of the terminal and of the reported event,

 - terminals of the different authorities, each comprising

• means of transmission to the platform that stores them, Alerts issued by the authority concerned,

The system further comprising:

 means for transmitting the events stored in the platform to the authorities respectively associated with the geographical areas where each event has been geolocated, and

 means for transmitting Alerts stored in the platform to the users registered in the system and whose terminals are geolocated in an area of dissemination of the Alert defined by the authority concerned.

According to advantageous embodiments:

 the geolocation means of the users' terminals are formed of GPS points provided by a device internal to the terminal or by GPS points provided by triangulation of cellular antennas (BTS), or are determined by attachment to a code previously deployed and parameterized in a particular spatial zone and recorded by the user on his terminal during a need for geolocation ("tags" in an uncovered area, inside buildings or buried environments), or are defined by selection by the user of a point on a map displayed in the signaling interface of his terminal,

 the system comprises means for automatically triggering transmission to the platform of the current geolocation location of a user's terminal,

 the automatic triggering of the transmission to the platform of the current geolocation location of a user's terminal is periodically carried out with a period corresponding to a predefined information feedback time

 - The information feedback time is adapted according to a load level of the user's terminal, the rise time being all the more important that the load is low,

- a user's terminal interface includes a list of event types that may be reported based on the current location of the user geolocation of the terminal (according to the processing capacity of the authority covering the territory and its proposals),

 the platform comprises means for identifying a secondary event signaled by a user, that is to say an event identified as similar to an event already reported and stored in the platform,

 - The identification of a Secondary Event is made by comparing parameters specific to an Event already reported and stored and including geolocation and time of the Event, to parameters defined by an authority and including a perimeter around an Event, a period of time around the occurrence of an Event and an indication of a relative spatial orientation between the user's terminal and the Event, a new Event being identified as secondary to the Event; an Event already reported and stored, if it occurs within the perimeter, the period of time and the direction defined by the authority

 - the platform is able to link, according to the various rules raised, one Event to another and thus perform a de-duplication of all events received.

 when the interface of the terminal includes an image or video capture to be associated with the signaling of an Event, the indication on the relative spatial orientation between the user's terminal and the Event takes the form of a compass appearing on the image or video explicitly (marking) or implicitly (internal data),

 - the platform includes means to ignore a Secondary Event by not storing it

 - alternatively, the system comprises means for requesting a user who has signaled an Event, or any user found in a predefined geographical area around the reported Event, additional information about the Event, such as images or confirmation that the Event continues,

 - the means to request additional information on a reported Event are managed by the authorities' terminals

 according to an alternative embodiment, the system comprises means for transmitting the signaling of an event generated by a user to other users located in a predefined geographical area around the reported event.

 the means for transmitting the signaling of an event generated by a user to other users are managed by the terminals of the authorities

- the signaling of an Event by a user, can be realized following a voluntary action of the user or automatically ie without any action on his part. This last case concerns facts, such as a shock suffered by a user in his vehicle, likely to generate information interpretable by the platform, in this case in the example considered, a discontinuity in the data provided by an accelerometer content in the user terminal disposed in the vehicle. The automatic transmission of such an event can be set beforehand by the user who will choose the type of fact that can be automatically reported as an Event to the platform, without any specific action on his part,

 according to one embodiment, the terminals of the users are mobile or fixed terminals.

 The invention also relates to a method of exchanging information between different users registered in an information exchange system and different authorities associated with geographical areas such as territorial communities, comprising:

 - Data storage steps within a common storage platform for different users and authorities,

a step of identifying the geolocation location of the terminals of the various users registered in the system, each terminal comprising a current geolocation means of the terminal, a "signaling" interface enabling the user to signal a geolocated event within a authority, and means of transmission to the platform that stores them, the current location of geolocation of the terminal and the reported event,

 - a step of transmission to the platform that stores them, alerts issued by terminals of the various authorities

The method further comprising:

 a step of transmitting the events stored in the platform to each authority associated with the geographical area where the event has been geolocated, and

 a step of transmission of Alerts stored in the platform, to each user registered in the system and whose terminal is geolocated in an area of dissemination of the Alert defined by the authority concerned.

Preferably, the method further comprises a step of transmitting the events stored in the platform to each service of an authority or each user having chosen, by explicit membership to automatically receive information on certain events according to their nature. PRESENTATION OF FIGURES

Other data, characteristics and advantages of the present invention will become apparent on reading the following nonlimited description, with reference to the appended figures which represent, respectively:

 FIG. 1 schematically represents the operation of the system according to the invention for the processing of events reported by a user;

 FIG. 2 schematically represents the operation of the system according to the invention for the communication of Alerts issued by an authority, for the attention of users subscribing to this authority.

 FIG. 3 schematically illustrates the entire information exchange process,

 FIGS. 4 to 6 schematically represent the process of identifying a primary event and a secondary event,

 FIGS. 7 to 9 schematically illustrate the identification of citizens present in a broadcast zone of an Alert,

 Figures 10 and 1 1 show a diagram illustrating the display of event mapping on the consumer area of the website of the system according to the invention.

DETAILED DESCRIPTION

The system of the invention will be described in the following with reference to an embodiment according to which the "authorities" are local authorities identified by "Ci" in Figure 3, such as cities, and users designated by "Ui" in that figure,

Citizens likely to be located in a city attached to the system or move between cities.

 This system provides mainly two types of information exchange, which can interact with each other:

 - the reporting of events by the Citizen on voluntary action on his part, or automatically, to cities and more widely to communities and

 - The issuance of Alerts by a community (and more generally an authority) to the Citizen

 It is a unique service accessible throughout the territory of a

State with a single site (portal direct access type WEB or indirect via mobile application) known to the general public (the declared users) and communities (the various cities subscribed to the system acting via Operators), and a single storage platform P events reported by different users, and Alerts issued by different cities. An Administrator Operator per city manages its own users, event types, and de-duplicate criteria. A global administrator manages the system.

 Users access the information exchange method according to the invention either via a free application previously downloaded to their smart mobile phone, or via a portal-type web application, local authorities via a website and the Global administrator also via a website.

 The interfaces of applications or websites dedicated to Citizens, communities and Administrators will be explained at the end of the description.

 [0018] Identification of the various speakers:

 There are four types of stakeholders: We will therefore distinguish four categories of people:

 • Registered users, named "Citizens" and able to report Events and receive Alerts.

 • Non-registered users, that is to say Internet users who will access the "General public" pages of the website or mobile phone holders who have not downloaded the application, named the General Public.

 • Operators of a community, in charge of public service management for a community.

 · The Administrators of the service: "the Administrator" represented by persons in charge of the management of the system of exchange of information between the different users and the different authorities object of the invention.

 Users must be registered in the system and therefore authenticated to access the features. This registration can be made with the user's login, email or phone number authenticated by procedure.

 Authentication of equipment: mobile or fixed terminals of citizens.

 An equipment corresponds to a mobile terminal on which is installed the application or a fixed terminal having access to the website dedicated to this application. The equipment will be identified as such and linked to a Citizen. The Citizen will be able to associate as many equipments as he wishes.

[0022] Location of an event The geolocation is an essential piece of the system according to the invention.

 This is an intrinsic property of an Event and a

Alert.

 The Event must be geolocated:

1. When creating an Event from a mobile device by a Citizen through the application downloaded to his phone, the Event is automatically geolocated by one or both of the following methods:

 • GPS point (coordinates (X, Y) provided by the equipment itself

 • GPS point provided by the triangulation of BTS cells.

 • Attachment to a "QRCode" tag, previously deployed and parameterized, (geolocation principle on "indoor" type sites: buildings, industrial sites, etc.). The "QRCode" is a tag supporting a known TAG of the system according to the invention: Each "QRCode" corresponds to a geographical position (real map point or a position on a plane for example). The "QRCode" is previously deployed and configured. (Principle of geolocation on "indoor" type sites: buildings, industrial sites, etc.). The "QRCode" is a label supporting a known TAG Alert-Phone service: Each "QRCode" corresponds to a geographical position (real map point or a position on a plane for example).

 2. When creating an Event from the website in the private portion of the Citizen, the Citizen must define on a map (by a simple "click" on this map) the geolocation of the Event.

The location is defined by the pair of values:

 Location type:

 o GPS EQUIPMENT

 o GPS_BTS

 o GPS_CARTO

 o QRCODE

 Location value

 o Coordinates (X, Y)

o Value of the "QRCode" An Event created by the Citizen follows a specific process, the purpose of which is the treatment of the Event by the community.

 The diagram illustrated in Figure 1 generally shows the state changes associated with an event.

 THE OBJECT EVENT AND ITS PROPERTIES

 This is the object created by the citizen through the Smartphone application, or a form on the website.

 The Event object has many properties:

1. It is attached to a level of the event nomenclature.

 2. A description (comment or additional information)

 3. A severity rate (from 1 to 5)

 4. A location

 5. Photos (3 for now)

6. Videos (x for now)

 7. One type (Primary / Secondary)

 8. A status

 9. A number of points

 DIRECT PROPERTIES OF THE EVENT

 Category and type of the event

The event object is attached to a level in the tree.

He therefore possesses:

 A category (level 1 of the nomenclature).

 A type of event and sub type (function of the number of level).

Description

 This text information, entered by the citizen is optional.

We will limit ourselves to 255 characters.

Severity rate

Subjective information filled in by the citizen of type integer Pictures

 The citizen can associate for example from 0 to 3 photos.

 These are stored in a specific directory.

Size of the images: in order not to penalize the loading time of the files (from mobile equipment to the server), the size of the files must be modified before sending.

 The chosen resolution is: 800 * 450 with a weight between 50 and 100 KB.

 Each of the associated photos has a property:

· Orientation. The possible values are:

o NULL: no associated information. (For example, if the user selects existing photos, or uses the website form).

o From 0 to 359: value of orientation relative to North.

 This information is available and will be displayed to the authority operator in the tab that shows the photos of the event.

Example:

 2 photos are associated with the event

 Photo 1, Orientation = 310

 Photo 2, Orientation = 325

Videos

The citizen will be able to associate from 0 to 3 videos.

These are stored in a specific directory.

A Specify: Re-naming + storage mode.

Rules on the weight of the video?

Video management will not implement for the Q1 typed version. The associated functional specification will be produced later. The status of the Event appearing on the Authority's terminal, and modified by the authority's operator:

 From the creation of the event to its closing, it will follow different statuses. The different statuses are as follows:

 OPEN This is the default status: the event is created in the system, but the de-doubling algorithm did not specify the type of the event.

 TO BE PROCESSED The type of the event is specified (Primary or Secondary). The element is therefore presented to the user of the authority that is to process it.

TAKEN INTO ACCOUNT The user of the authority indicates that the event is taken into account, and therefore being processed.

 NOT TAKEN INTO ACCOUNT The authority user indicates that the event will not be taken into account, it is not a relevant event to process.

 PROCESS The event is processed, the authority user indicates the change of state.

 CLOSURE This status is used to exit the event from the list of current events. This corresponds to an archiving of the event.

 REJECTED Following the status "NOT TAKEN INTO ACCOUNT", an event may be "REJECTED" if it is a "false" statement.

For each of these states, is associated a date (date of change of state), and a link to the user at the origin of the change.

We keep the history of status changes. This history will be presented insi:

 OPEN 12Î52 / 2814 - 1: 1 H22 5 -: Ready! Gm | ■

 A T AIT SYSTEM ■

 TAKEN m CO MPTE 12¾2ί28 · Μ - TLiSTAEUR • U - Ρεέαοπξ ■

 TREAT USTEZOU - iiTLISTaEliR l HOU - Préi nî II

CLOSURE 1 & ¾2 / 2: S1: 4 - 1: 8H ^' 3S OILER: - Fertilizer ■ [0026] Principle of "de-doubling an event" or "grouping secondary events with a primary event"

The purpose of this function is to not overload the Operator when processing events, by the multiple storage of similar or identical information relating to a single event.

 Take the example of a street lamp that no longer works.

If more than one Citizen declares this Event: "Floodlight Malfunction", then the Operator will have to deal with a large number of Events that are all identical. If we add to that a period of time long enough for the repair (for example a few days), then the Operator will be overwhelmed by an Event at the expense of other Events.

 To avoid this, a specific treatment (Algorithm of de-doubling) will be applied to each Event and which will allow to classify the Events into two categories:

 • Primary event

 • Secondary event

 The Primary Event is the first declaration by a Citizen of an Event for a given type. This must be processed by the Operator and will follow a status change process as shown in the diagram in Figure 1.

 The Secondary Event is the same Event (same type) as the primary event, but it was subsequently declared. In this case, this Event is attached to the Primary Event and will not be processed by the Operator. This Secondary Event will follow the status of the Primary Event. The Operator may access the information of the Secondary Events at his request in order to obtain, for example, additional information about the Event.

 The Primary Event will be all the more important as there will be Secondary Events that will relate to it.

 The classification is automatically performed by the system according to the invention as a function of the following parameters for each of which will be defined associated value ranges:

 (A) Geographical scope (radius of action),

 · (B) Time period

(C) Orientation (when taking the picture or video). The Administrator Operator can implicitly and simply change the values (A) and (B) by type of Event. Data (C) is used by the system to separate residual ambiguities. Other data may be used to separate the latter such as a degree of urgency provided by the Citizen.

Using the example above, the Operator will be able to define the value ranges for the de-duplication rules of the Event type "Floodlight malfunction":

 • (A) Geographical scope: 0-25 m

 (B) Period: 0-72 hours

Specifically, according to Figure 4, if a "Floodlight MALFUNCTION" type event is created, and the service does not find any Event of the same type created within 72 hours in a radius of 25 meters, then this is class "Primary".

 In the opposite case (the service already finds an existing Event within 72 hours ET within a radius of 25 meters), the Event is of "Secondary" class and will be attached to the Primary Event.

 According to FIGS. 5 and 6, the orientation, when taking a photo or video, will in certain cases make it possible to detect whether secondary events are duplicates of the primary event, or if a doubt remains. In this case, the Event may be presented as primary. These criteria will be used to automatically process residual ambiguities.

In the case of Figure 5, the ^2nd Event (point near the edge of the circle) will be defined as "secondary" because the orientation recorded when shooting is compatible with that of the primary event.

In the case of Figure 6, the 2 ^nd Event defined as "Secondary" (Geographical scope and period are respected) will be classified "Primary" because the shooting direction does not match that of the previous event.

The system according to the invention thus provides the Operator with the means for setting the de-doubling function. Grouping algorithm

 The system further includes an algorithm for grouping Events occurring after a Primary Event and outside the ranges of parameter values expected to qualify a Secondary Event, and assigning them to the Primary Event.

More precisely, this algorithm uses in addition to the initial parameters defined to qualify a secondary event (geographical perimeter A and period B according to the preceding example), a weighting for each of these parameters, for example between 1 and 10 and allowing assign a score to assess for the parameter considered the probability that it is really secondary (the score "1" representing a very low probability, for example, an event occurring more than 100 m from an Event of the same type, and the score of "10", a very important probability, this score of 10 being reserved for Events occurring within the tolerance provided for qualifying a Secondary Event).

 For example, if an Event is reported:

 in the same category as a previous event in date, "Floodlight malfunction" to resume the previous example,

 at a location 26 m from the previous Event (ie outside the 25 m perimeter around the above Event defined in the previous example to identify an Event as secondary, but within one meter), and

 within 73 hours of the occurrence of this previous Event (ie one hour too late compared to the duration of 72 hours defined to identify an Event as secondary in the previous example),

the score assigned to the geographical parameter A will be relatively high (for example 9/10) and that attributed to the parameter time B, also high (for example 9/10 also) as the probabilities are large that this event located certainly outside the perimeter and of the period defined to be identified as secondary, which is actually a Secondary Event of the previously reported Event.

A mathematical algorithm can be provided for assigning a weighting to each parameter making it possible to qualify a secondary event as a function of the difference observed for an event of the same category as a previous event, between the parameter recorded for the event considered, and the beach of values set for this parameter to qualify a Secondary Event. It may be possible to calculate an average of the scores awarded for all the qualification parameters of a Secondary Event. An example of the algorithm for calculating such a grouping note is given below:

The method will rely on the calculation of two notes:

^• The explicit reliability rate.

· The implicit reliability rate.

 Each of these scores will then be weighted to calculate a final score between 0 and 100.

 Step 1: Find out if there are any potential "Primary" events:

^• If no primary event matches, then there is no calculation of the final score.

 • Otherwise, a final score must be calculated to choose whether to attach to this event.

The closer the final score is to 100, the more confident the system is about assigning the new event to "Secondary": a previous "Primary" event is clearly identified.

 Conversely, if the final score is close to 0, it indicates that the relationship to a "Primary" event is not identified.

 Between these two values (0 and 100), it will be possible to define thresholds for which the system will automatically choose a type of event or not.

 The Administrator of Authority will be able to define his own thresholds, and thus choose his mode of management for his authority:

^• Automatic assignment of events in Primary or Secondary

 The assignment of a secondary type is automatic if the final score is greater than or equal to a threshold value (for example 70/100)

^• Value interval for which the assignment is not automatic and the system requests validation from the charging operator.

 If the score is less than a first threshold value (for example 65/100), the event is automatically identified as primary, greater than a second threshold value (for example 70/100), it is automatically identified as secondary, and when it falls within the range defined by these two threshold values (in this case between 65/100 and 70/100), a validation is requested from the Authority's operator who identifies by his / her assessment event as primary or secondary by clicking on a corresponding active area of the screen of its terminal,

a) Calculation of the explicit reliability rate The calculation of this rate applies to the 2 values: Period and Distance.

The principle: the closer the calculated value is to 100, the more the explicit reliability rate increases.

We must calculate 2 notes:

· A note for the Period

• A note for the Rayon

The explicit reliability rate thus corresponds to the average of the 2 notes previously described:

N & ietPsrioûe + Not »R3 on

 Explicit reliability rate =

b) Calculation of the implicit reliability rate

The calculation of this rate applies to 2 values.

 The principle: the closer the calculated value is to 100, the higher the implicit reliability rate.

 We must calculate 2 notes:

 • A note on the orientation of the shots (photos).

· A note on the reliability of geolocation.

The implicit reliability rate thus corresponds to the average of the 2 notes previously described:

 ftfote Qàeat. Photo + Hot * type <fe Geofoc.

Implicit reliability rate ^■

c) Calculation of the final grade

From the 2 notes: Explicit rate and Implicit rate, we calculate the final score.

The Administrator of Authority sets coefficients for each of his 2 rates. Then we calculate the final score according to these 2 values:

Coeff: E ^* TFE ^■ ÷ Caefi * TF!

 Final score =

 Coeff.E + CoefcJ

Link to Secondary Events

A primary event can be linked to 0 or more events secondary.

 For a "Primary" event, we access the list of "Secondary" events through a table.

 We will have in this table, the direct properties and we will access the indirect properties by the method of the actions "Form which integrates in the rows of the table.

A particular action (following a voluntary action of an operator) will make it possible to modify a "Secondary" event in "Primary":

o From this moment, the event becoming "Primary", it loses its relationship with the previous "Primary" event.

o It leaves the table and becomes a "Primary" element with a final score = 0. o Whatever its previous status, it has the status: "TO BE TREATED".

o Information is kept about whether an operator changes the type of this event.

 Request for additional information

 This feature allows for a particular event, to send on identified equipment (user terminals for example) a request for additional information.

The Administrator defines a department for which he wishes to reach the equipment.

Depending on the value of the radius, the system tells him the number of devices that are potentially in the zone.

When the request is sent, it contains the following information:

Date and time of the request for additional information

Type of the primary event

Contact information for the "Primary" event

Explanatory text entered by the operator.

 This information will make it possible to pre-fill the form in the appropriate equipment; each citizen receiving this request, will be able to add information:

o More description

o Photos

 Automatically, these events declared by the citizen are of type "Secondary" and associated with the initial primary event.

In the following, we detail the grouping algorithm and the method of calculating the notes:

STEP 1: SEARCH FOR "POTENTIAL PRIMARY EVENTS" For an event declaration, one searches in the database if there exists a list of events of the type "Primary" having as characteristics:

 • The same type (category, type, subtype, etc.)

· Possessing a date such as:

 [NOW] - [Status Date "TO BE TREATED"] <[period value]

 • Possessing a Geolocation such as:

[The calculation of the distance] <[Radius value]

The result of this research will be interpreted this way

 Result of the query is empty: Result of the query not empty:

No Primary Event Does No Primary Event Corresponds. criteria.

The new event is therefore We can not define the type automatically typed "PRIMARY" immediately, the calculation of the note is essential.

Warning: if a result exists, it must be unique. In the opposite case, there is an inconsistency in the data: the Administrator must be informed immediately (email).

No final grade calculation. Calculation of the final grade required.

This is automatically equal to 0

Explicit notes are determined by the formula:

Explicit note = 100 - 100 ^* period or radius of occurrence of the event / period or defined radius

 Explicit Note Period or Radius

 Period or Ray of Occurrence of V Event

= 100 - 100 x _n ,. j ^ 7 -.

 Period or Defined Radius

ex: at. Consider an example of a 48-hour period. If the event is declared 30 hours after the "Primary" event, then the score is calculated as follows:

 30

 Explicit note Period = 100 - 100 x- = 37%

 48

b. Consider an example of a 48-hour period. If the event is declared 5 hours after the "Primary" event, then the score is calculated as follows:

 5

 Explicit note Period = 100 - 100 x- = 90%

 48

vs. Let's take an example of a radius defined at 25 meters. If the event is declared 20 meters from the geolocation of the "Primary" event, then the score is calculated as follows:

 20

 Explicit note Radius = 100 - 100 x- = 20% d. Let's take an example of a radius defined at 25 meters. If the event is declared 7 meters from the geolocation of the "Primary" event, then the score is calculated as follows:

 7

 Explicit note Radius = 100 - 100 x- = 72%

The explicit reliability rate corresponds to the average of the 2 notes "Radius" and "Period" previously described:

 NoteFeight + Hoteftsycm

 Rate, explicit reliability =

Example, taking the above examples, combining the different results, we would have the following values:

CALCULATION OF THE RATE OF IMPLIED RELIABILITY

The calculation of this rate applies to 2 values.

 The principle: the closer the calculated value is to 100, the higher the implicit reliability rate.

One must calculate at least one note: • A note on the reliability of geolocation.

There are 4 types of geolocation:

o GPS EQUIPMENT

o GPS_BTS

o GPS_CARTO

o QRCODE

 For each of these types, the Authority Administrator will provide values to define the reliability of Geolocation based on the type.

For example, we will have values defined in this way:

 If the geolocation is done by a type GPS_EQUIPEMENT, then the note will be fixed at 90,

 If the geolocation is done by a type GPS_BTS, then the note will be fixed at 40,

If the geolocation is carried out by a type GPS_CARTO, then the note will be fixed at 60,

 If the geolocation is done by a type GPS_QRCODE, then the note will be fixed at 100. · and possibly, a note on the orientation of the shots (photos).

This note will be calculated only if values exist:

The Primary event must have photos and values regarding the orientation of these photos.

 The event to be classified must also have photos and associated values on the orientation.

 If none of these conditions are met, the calculation of the score can not take place, and in fact, this does not enter into account in the calculation of the implicit note (and therefore global) The implicit reliability rate therefore corresponds to the average of the 2 notes previously described: Orient tilote. Photo + '' Liver Geoksc type

 Tau * implied reliability =

Example, taking the above examples, combining the different results, we would have the following values:

CALCULATION OF THE FINAL NOTE

 From the 2 notes: Explicit rate and Implicit rate, we calculate the final score.

The administrator of the authority defines coefficients for each of its 2 rates: Then we calculate the final score according to these 2 values:

 TFE ÷ Caef.i * TFÎ

 Final score =

 Coeff.E ÷ Ceeff.î

Example, taking the above examples, combining the different results, we would have the following values:

Period of resolution

It corresponds to the time given to the authority to process the event. This delay is defined for each type of event. It corresponds to the "Period" value used by the grouping algorithm.

 The delay starts from the moment when the event is in the status: "TO BE TREATED" or "TAKEN INTO ACCOUNT"

For an event, depending on its status, it can be listed:

o In time,

o Out of time

 A representation of this delay will be displayed on the Authority's terminal with the time remaining, or conversely, the time passed after the delay.

Severity - Priority of a Reported Event

Depending on the type of Event reported (dangerous for the population or not), the number of Secondary Event reports for a Primary Event, or the identity of the user or entity reporting this Event, it will be possible to determine a degree of severity for the event considered (for example between 1 and 10) and an alert display for the event in question on the terminal of the Authority in which it has been reported .

 For example, this Event may appear with a color depending on the severity assigned to it, with a visual signal (flashing event display) or sound (alarm).

 Events with a high degree of severity may appear in priority on the list of Events displayed on the Authority's terminal. The application of this degree of severity can be carried out by the operator dedicated to the management of the Authority's terminal, or automatically by means of an algorithm provided for this purpose. Emergency function

 A computer object will declare an event to a national security service such as National Police, Samu, Fire Department, or City-type Municipal Police Station. Citizen at the origin of the declaration

 A link between the "Event" object and the "Citizen" object is retained.

One can therefore at any moment know the citizen at the origin of the event.

From an event, we can display the information of the citizen:

 • Last name

· First name

• E-mail • Photo

Equipment at the origin of the declaration

There is a link between the equipment (mobile equipment: IPhone, Android, Wphone) and the citizen.

 A citizen can use several equipment.

An event is created by a citizen, from:

 • mobile equipment or

 • from the website form.

From an event, we can display the information of the equipment:

 • ID

 • Type of equipment (IPhone, Android, Wphone)

Degree of trust, credibility - Reward

A history of events reported by each user allows to know for each its seniority, the number of reports of events that have been confirmed by other users, the nature of the events reported (dangerousness) ...

 Based on these data, a user is assigned a degree of confidence, or points of credibility for example calculated by an algorithm, and noted from 1 to 10.

 Dots

 The points associated with the declaration of a primary type event will be assigned to the event.

A global setting by authority will define the number of points for a declared event of type Primary and Secondary type.

So we will have 2 parameters

 • NBPOINTS_PRIMARY (from 0 to 10).

 • SECONDARY NBPOINTS (from 0 to 10).

Another parameter will define whether or not the authority uses the point allocation system:

 • SERVICE_POINTS: YES / NO.

Rules for awarding points:

1. At each declaration of an event, the number of points defined by the parameters is added to this event.

 2. There is no need for validation from a user of the authority. The points are automatically associated with the equipment.

 3. On the other hand, the user of the entity can, on a case-by-case basis, add or remove points to the event.

4. If a Primary typed event becomes Secondary (or conversely) per action of the user, then the points are reassigned. For example :

 For a community, the values for the parameters are:

· PRIMARY NBPOINTS = 10

 • SECONDARY NBPOINTS = 2

 A citizen declares an event of type: "Road Sign Fault / Traffic lights".

 If after treatment, the event is:

· Primary type, this one is given 10 points.

 • Secondary type, this one is given 2 points.

 But the user in charge of the treatment of the event has the right to modify this attribution of points. He will have to enter a new value in the card associated with the event then "Validate".

This degree of confidence may be taken into account in the calculation of the severity of a reported Event (see above) and thus to assess the priority of the reported Event.

 This degree of confidence, or these points of credibility may allow the issuance of rewards, such as gift vouchers, in connection with the Authority to which the User is subscribed (for example, a reduction on the amount of the annual subscription at the municipal swimming pool).

 Ideally, in order to avoid misuse of the application according to the invention, by a user desiring to artificially increase his degree of confidence, the reward may take the form of a benefit attributed to a third party (for example a check to the attention of an association of the municipality) and not to the user himself.

Also, always in order to avoid to venal users to declare events in number to increase their chances of obtaining a reward, by creating a multitude of user accounts in order to confirm in number a declared event from a main account, it is planned to be able to check whether several created user accounts correspond to different terminals, for example by means of a user terminal identifier which will be registered in connection with the first user account created at from this terminal. Depending on the identity of the User, the degree of trust or the credibility points granted may be greater. This is particularly the case when the User is recognized as a Trusted Agent (a technical agent of the city for example) or as a User with a high degree of confidence. If, on the contrary, a User proves detrimental to the proper functioning of the service, according to for example the far-fetched nature of the Events or the content of the messages it associates with these events (racist, pornographic, contrary to public order.) a message may be issued by an Authority to invite it to improve the quality of its reports. Otherwise, this User may be banned from the community.

Registering an identifier for the user's banned terminal will prevent him from creating another account on the same terminal after being banned. In addition, a computer recognition tool may be provided to analyze the image captures or videos accompanying the report of an Event and delete those representing an individual in a manner allowing its identification. A message may be sent to the user reminding him that no data of this type is accepted by the service. An alternative will be the use of a computer tool to scramble any identified face on an image capture or video.

Synchronization - network problems:

 Each Event is recorded locally on the User's terminal, and when the User is able to communicate with the server, also on that server.

 Thus, in the absence of a network, the creation of an event remains possible and it is stored on the terminal to be communicated to the server later.

 The synchronization of events to report and stored on the user's terminal, and Alerts stored on the server and to be transmitted to the user's terminal is done as soon as the terminal is connected to a network.

The application downloaded to the terminal may allow the sending of a notification when a network absence is detected with the geolocation of the loss of the network, to warn an Authority of the presence in its perimeter of a zone d the absence of a network, or the occurrence of a network problem, which problem may be transmitted to the competent department of the Authority, or to a service external to it, such as the service of a national network provider.

Management by the authorities

At the level of the terminal of an Authority, the events reported are grouped by sub-group according to the services of the Authority and communicated automatically to the service in question.

 The terminal of a User communicates at a given frequency its geolocation to the server (for example every 15 minutes) and receives the Alerts from the Authority concerned, as long as the last position of geolocation is within the perimeter of the Authority considered.

When the geolocation of the User's terminal positions it outside the geographical scope of an Authority he has just left, he is notified by a Notification ("You have just left Le Perreux sur Marne, Welcome to Neuilly sur Marne") and can be offered:

 - continue to receive the Alerts of the Authority he has just left,

- to start receiving the Alerts of the Authority that he has just joined, if he joins the service, and if not, to send a message to this

Authority to encourage him to join the service

 A history of Events reported in the perimeter of an Authority will make it possible to propose to a User wishing to report a new Event in the Authority concerned, to be offered, in the interface for entering a new Event, a list of the different Event already reported.

RULES FOR DELETING AN EVENT BY THE CITIZEN

 The citizen behind the creation of an event remains the "owner" of this event.

He may therefore at any time decide to delete it entirely or in part.

DELETION OR PARTIAL MODIFICATION

The citizen can modify or delete certain information associated with the event.

It can therefore modify the following information:

 • The gravity rate

 • The description

 The other properties of the event (its type, geolocation, etc.) are not modifiable by the Citizen.

Regarding photos, the Citizen can:

 • Delete them: this is really a physical deletion: the file is deleted from the server

 • Add, if the 3 available photo locations are not used.

TOTAL DELETION

Total suppression implies for the citizen that this event no longer exists. He will not be able to appear in his list "My events" anymore.

But this event remains available for the Authority in charge, with the following modifications:

 • The link to the Citizen who is at the origin of it does not exist.

 • And so the link to the equipment no longer exists.

 • The photos are physically deleted (because for the citizen, he really deleted the event and therefore the associated photos).

For a user of the Authority, this event will always appear in the table events, but it will be represented with a peculiarity (specific color of the line for example) so that the user immediately identifies that the Citizen to delete this event.

 The authority user will have the choice to process this event or close it if it is no longer relevant.

Management of Authorities by the Global Administrator

The Global Administrator is dedicated to the management of different Authorities and different users. It has a terminal with a management interface of these Authorities.

This interface allows access to the interface of each Authority and to intervene as the Authority itself, and create a new account for a new Authority.

This interface also allows the visualization of different maps of different Authorities on which the events reported are marked by sign, clickable to know the details of the event considered.

This interface is linked to a source of information on the cadastres of the various cities or townships of a territory, updated regularly, and allows, when a new Authority wants to subscribe to the service, to delimit automatically from the code postal of the city or township, of a perimeter on a map.

If a city wants to subscribe, it informs the different Events that it authorizes a User to declare, informs the identifiers for the different services that can handle these Events, and email addresses or links to them to push them Events reported, as well as the various system parameters (grouping parameters, degree of confidence).

This interface allows not only the introduction of a new Authority in the system but also that of an external information system, such as a government information system (for example: National Police for Abduction Alerts).

Indeed, at each Authority, the Global Administrator may propose the Alerts of an external information system. [0027] Locating an Alert

 The Alert is necessarily associated with a geographical perimeter and disseminated to citizens present in this area.

 The concept of geolocation for an Alert is therefore twofold:

 1. We must first define the geographical scope associated with the dissemination of this Alert: By default, it will be the perimeter on which extends the power of an authority (For example for a municipality, it will be the perimeter of the municipal territory).

 The Operator will also have the ability to modify this perimeter:

 at. Specifically digitize a perimeter (for an Alert that would only be broadcast in the city center for example)

 b. Select adjacent territories (for an Alert broadcast on a municipality, and the surrounding municipalities).

 The geographical scope of broadcast of the alert is independent of the current location of the terminal of the Authority through which are issued Alerts.

 2. The Alert is distributed only to Citizens present in the perimeter defined for the Alert.

 This implies, therefore, that the system and method according to the invention know at all times where the citizens declared in the system actually are.

 In other words, the list of Citizens (and therefore their equipment) impacted by the dissemination of an Alert will be calculated by the system through a Geo-Spatial type query that overlay the two geographic information (perimeter of the alert and positions of the different equipment) will deduce the group of Citizens to reach.

 For example, let's take an Alert whose dissemination perimeter corresponds to a circle on a given territory:

 According to Figure 7, we know at every moment the position of all citizens (equipment) declared in the Service Alert-Phone (white stars with black outline).

An alert is created. The dissemination perimeter of this Alert corresponds to a circle as represented in FIG. 8 (Operator's Choice). According to Figure 9, the system, through a Geospatial query defines the target of the Citizens (equipment) for which the Alert will be broadcast (black stars).

 Other Citizens not within the scope of the Alert will not be notified of it.

 In addition to receiving Alerts on a geolocated area, the Citizen may choose to subscribe to alerts from one or more Communities. It will receive the corresponding Alerts even if it is not located in the broadcast area of the Alert.

 [0030] Citizen's Reward

 A system of obtaining points will be set up to make the service attractive and reward the Active Citizen.

 The basic principle is that for any new event declared, the user receives points.

 The validation of the acquisition of the points will be performed by the Operator in charge of the processing of the Event.

 [0034] For a "Primary" type event, the Citizen receives points

 For a "Secondary" type event, no points will be awarded, unless the Operator finds the associated information relevant (best description of the Event, or relevant photos and videos).

 If the information collected within the various Events are considered insufficient by the Operator to process the Event, the latter will have the opportunity to issue a request for additional information to all users who have reported the Event. The request for additional information will be based on the function of issuing Alert by selection of citizens who transmitted the event (primary or secondary).

 The provision of additional information may be subject to the gain of points.

The points earned by the Citizens will be exploitable by the Collectivité by various means (presentation of the most active citizens, official rewards, exchange of points against services of the Community ...). According to the use of its points, a treatment of the value of the acquired points will be possible by user by the Community. EVENT MANAGEMENT BY SERVICE

 The concept of service corresponds to a compartmentalization necessary for the management of created events.

 The Administrator of the Authority has the ability to report services.

Then to define the relations between the nomenclature of the events and the services.

Link rules

 1. An Authority has at least one Service. It will therefore be necessary to create a Default Service when the INEO Administrator creates an Authority: it will be the "Authority Authority" Service which will contain at least one user: the Administrator of the Authority.

 2. A user of the authority belongs to one or more services.

 3. An event type is associated with one or more services. As a result, a user will see in the different functionalities (management board, on the map, etc.) all the events whose types are associated with the services to which he belongs.

[0038] History management

 As part of the invention, there is provided a global management of the history of actions performed by the stakeholders in the system.

 This means that all actions performed by the different actors (Citizens, Operators, Administrators) are identified and saved.

 Depending on the rights management associated with each, the display of this action history will be filtered and presented to the different types of actors.

 [0039] Proposed technical architecture

 The Alert-Phone information exchange system and method is a software as a service (SaaS) software solution that includes the following applications:

 ALERT-PHONE-SMART: Free client application dedicated to Smartphones (for the Citizen).

ALERT-PHONE: Portal-type WEB application for users of all types. ALERT-PHONE-COMMUNITY: Web application for communities (configuration, management, information processing and associated services).

 ALERT-PHONE-ADMIN: Global Administration WEB application for Service Administrators (depositor's personal).

 ALERT-PHONE-WEBSERVICE: Web Methods Interoperability service that will be consumed by external applications.

 According to FIG. 11, the Alert-Phone service is composed at the FrontOffice level of the following interfaces:

 Smartphone app: ALERT-PHONE-SMART

• Public Website: ALERT-PHONE which will be broken down into private space:

 o The private space for the Citizen

 o Private areas for communities: ALERT-PHONE- COMMUNITY

 • A private website (which may not be accessible from the internet) for the Global Administrator.

 The backoffice is composed of Web Application servers that will support the following components:

 • An interoperability layer (WebServices) that will be used by the FrontOffice of the Alert-Phone Service. This same layer of WebServices can be used by external applications.

 One or more web application servers that will be parallelized according to the overall load (solicitation of the system).

 A database management and file storage system (Photos, Videos).

INTERFACE DETAILS

[0040JCOTE USER: APPLICATION FOR MOBILE TELEPHONE

 The mobile terminal application will allow the Citizen to identify himself by creating a profile, to subscribe to the service, to select cities from which he wishes to receive Alerts, to select the type of Alerts that the Interested (weather alert, traffic accident, school closure ...), to report Events and receive Alerts.

Through the mobile phone application, the Citizen can declare an Event and its associated data: Choice of the type of Event

 Geolocation of the Event

 Comments or additional information

 Pictures

 Videos

 Degree of urgency (Citizen's subjective rating)

 All this information associated with the Event created by the Citizen is the property of the declaring Citizen. He therefore has a right to modify and delete at any time on this Event.

 It can associate with the reporting of an event, different media such as a photo or video. In this case, an option allowing the dynamic masking of faces may be provided.

 The functions associated with this masking will be established according to the following cases:

 - The Operator, that is to say the community collecting the report, can activate or not the masking when viewing the associated media (or according to rights associated with the Operator)

 - The Citizen will have the ability to make the masking dynamic or permanent

 [0046] The citizen can also delete:

 - The documents attached to his Event: Photos and videos. These documents will actually be deleted from the platform where they are stored. Nobody (Administrator, Operator) can view them after this delete operation.

 - An Event: in this case, this Event disappears from the Citizen's lists, but it remains in the system (in the platform) for processing (if necessary). All links between the Event and the Citizen are then removed, it will be impossible to make a link between the Event and the Citizen who initially declared it.

 It will be typed "Deleted", so that the Operator is aware of this state. He will therefore no longer be able to communicate expressly about this Event (with the declaring Citizen or other Citizens). It is therefore impossible to ask for more information about this Event.

 This application for Smartphone will have to be developed especially for the following OS:

 • IOS: iPhone®

 Android®

• Windows® Phone (W8) Each application (the FRONT part and use of the phone's API) will be developed using the technologies specific to each environment, but will use identical WS which will be developed on them side Server: Java J2EE. Whenever possible, JavaScript code common to all 3 environments will be used.

 In practice, the citizen wishing to implement the system according to the invention must install the application on his Smartphone. The use of this application necessarily requires authentication:

• The Citizen must be declared as a user of the service · The Citizen must authenticate and declare his equipment to access the features of the application.

 • Only the Alerts Notification feature is active without authentication.

 [0050] User registration form

 Since authentication is required, a new user can register with the service from this application.

 This form can potentially be relatively short (at least shorter than the web portal ALERT-PHONE detailed later). The user can later add other information about his account.

 The registration process requires the user to enter a code received by SMS, in order to validate the creation and activation of the account.

 [0051] Form of declaration of a mobile terminal

 [0052] A citizen can have several phones or tablets. In this case, a form allows him to declare several pieces of equipment. It will therefore be recognized as a single citizen regardless of the mobile terminal used.

 [0053] Login / logout form

 The connection is required to access the features of the service after filling the login form. The disconnection of the user is done through the form disconnection which, once validated, will no longer allow it to access the features.

 [0055] "Home" page, customizing the application

At the launch of the application, a check is made between the communities to which the Citizen adheres, and the geographical position where it is actually (Geolocation). [0057] The following cases will be managed:

 • If the Citizen is actually in a community supporting the Service, the application is personalized (Logo, name of the community, graphic charter, etc.).

 • If the Citizen is in a community or geographic area that does not adhere to the Alert-Phone service, then the application notifies that situation, and the home page will be a default page. In this case, it may be provided an action button that will ask the Citizen to send a message to the municipality: "Do you want to notify the municipality of the existence of the Alert-Phone service? "

 [0058] Management of the geolocation

 It is proposed to the Citizen to manage itself the period with which the application ALERT-PHONE-SMART will go back to the service position (geolocation) of its equipment.

 For example, the feedback of this information will be between 1 minute and 1 hour. Local processing (a function of the ALERT-PHONE-SMART application) consumes energy. This should not be done at the expense of using the equipment itself by the Citizen.

 From a certain threshold of the battery level, the application ALERT-PHONE-SMART automatically adapt the sending period of the position of the equipment to not solicit the battery in this context.

 When the terminal is connected to the mains and no longer operates on battery, the feedback of the position information (geolocation) is automatically activated on a short cycle (every 5 minutes for example).

 [0063] Declaring an Event

 The main function is that the user goes back Events. A whole list of Events (depending on the services available and set by the community) will be presented.

 An Event will have the following properties:

 • Geographic information (geolocation)

 Alpha information (text, type, date, etc.).

 • Associated photos (and orientations when shooting)

Related videos • Qualitative cursor: the user can give a note (from 1 to 5 for example), to signify the gravity of the fact.

 At the end of the declaration of the Event, the user will be notified:

• "Primary" event with potentially point allocation.

 • "Secondary" events (Event already declared).

 • If applicable, points earned through this Event.

[0065] Request for additional information

In the case of a Secondary Event, that is to say an Event previously declared, the community may ask the users for additional information.

 A user at the initiative of a "Secondary" Event may also be awarded points if the information provided (photo, video) is relevant.

 Subscribe to subscriptions (Subscribe to communities)

The Citizen may "subscribe" to receive the Alerts and address Events of one or more community (s) adherent (s) to the service of the invention.

 · A form in which the user selects the communities.

 • A dynamic subscription request when the user travels to a community that has this type of service.

 By subscribing to a community, the Citizen will:

• Declare Events for this community.

 • Receive Alerts issued by this community for which the Citizen subscribed. [0067] Receive Alerts

 This feature is transparent to the Citizen, in the sense that he will receive Alerts from the Alert-Phone Service generated by the community in which he is currently located.

 The Citizen will receive only Alerts that meet the following criteria:

• The Citizen is in the dissemination perimeter of the Alert • Not mandatory, the Citizen has validated in his preferences, the desire to receive Alerts of this type.

 Note that the receipt of Alerts is not subject to authentication. The Citizen can be notified of an Alert without having filled in the authentication form. On the other hand, to consult the contents of this Alert, it will have to authenticate in the application.

 [0069] See Alerts

 The Citizen consults the active Alerts in the area where it is located.

 [0071] Video media

 Advanced features will be associated with this media:

 - Record a video, then attach it to an Event and declare it.

 - Make a video and at the same time send this feed on the servers of the ALERT-PHONE service. This will allow Community Operators to have live access to the video stream.

 "EMERGENCY" or "SOS" function

 [0073] Function that allows the Citizen to create an "SOS" type event by simple click. The purpose is to provide the Citizen in emergency or stress, a way to issue as soon as possible an event to alert the competent services (Firefighter, Samu, Police, Gendarmerie, Municipal Police, etc.). When sending an "SOS", a countdown appears on the terminal before the actual sending (10 seconds for example) to allow the Citizen to cancel his "SOS" if it is 'a mistake.

 This event sends the geolocation of the person for a more accurate identification of the situation.

 [0075] The choice of the competent department capable of handling these "SOS" type events will of course be configurable by the community by the administrator operator.

 [0076] Function "PIETON / VEHICLE"

 [0077] Function that allows the Citizen to explicitly activate in the application its mode of movement:

 - PIETON: default mode.

- VEHICLE: mode allowing the Citizen to activate the automatic return of SOS if a shock is identified by the terminal. In this mode, the Citizen participates in the generation of traffic data. In mode "VEHICLE", the emission of "SOS" can be triggered automatically without action of the Citizen for example in case of shock of a user in the vehicle. The purpose is to send as soon as possible an Event to alert the competent services (Firefighter,

Samu, Police, Gendarmerie, Municipal Police, etc.) when a shock occurs. For this purpose this function exploits the accelerometer data provided by a device internal to the terminal in order to transmit the event. Thanks to the countdown available when issuing an "SOS", the Citizen can cancel a false alarm before it is actually issued.

 When the terminal moves at a speed greater than a threshold (30 km / h for example), the terminal is automatically identified in "VEHICLE" mode to consolidate traffic data. When the platform identifies terminals on predefined motorway areas (highways for example), the terminals are implicitly switched to "VEHICLE" mode.

 The speed of movement of a Citizen is determined by internal equipment terminal or calculation from the platform according to geolocation points, the timestamp of these points and the urban topology of the place.

 The traffic data and the damage thus collected on the roadways can be used by the Collectivité and / or the competent services to remedy situations and to inform the Citizens.

[0082] USER SIDE: APPLICATION ON WEB SITE

 The application available on the website will include the features described above for the application for mobile phone, and will present the overall process. The homepage is therefore global (there is no differentiation at this stage of local authorities who join the service, and the general public).

 This website (several pages depending on the content) will inform the public about the service, the communities that adhere to it, etc. The first page may contain, for example:

 • A link to descriptive pages: "I am a Citizen"

• A link to descriptive pages: "I am a community"

Then links will display specific pages (in terms of presentation and informative content) to each community and associated services. [0086] The pages associated with the communities may be presented according to:

 • Default mode: Enter their presentation content in an already "formatted" ALERT-PHONE portal with personalization in terms of graphic charter and data presented.

 • Optional Mode: Create a specific site of presentation if will of the community.

 [0087] Declare an Event

 This is the same functionality as that detailed in the application ALERT-PHONE-SMART. With the difference, the declaration is made from a fixed position; media (photos, videos) will be "uploader" from a selection of files. Ditto for geolocation, the user (if he wishes) will be able to geotag the Event by selecting on a map the appropriate location.

 My Alerts

 This function gathers all the Alerts issued by the communities to which the user adheres. The user can access all the Alerts issued. At this stage, a "community" could be of national type and thus spread the Alerts that impact the national territory. Or a community that broadcasts an alert on its territory, could also broadcast on adjacent territories if the risk comes out of its own original territory. In this case, even if the user has not explicitly joined the community, he still receives the Alert.

 [0091] My memberships in the communities

 This function allows the user to select the communities members of the Service, for which he wishes to receive Alerts or issue Events. The choice will be made only among the communities that subscribe to the Alert-Phone Service. In the case of a dynamic membership from his smartphone, the community will find the list of memberships.

 [0093] Mapping Events

 The user visualizes on the map his own Events. It can therefore access it by direct selection on the map.

[0095] In the pages "Grands Public", will appear an overall summary of the events reported. It will not be possible from this information to "go back" to a single Event containing the declarant's personal information. This is an anonymous presentation of the Events database in order to show the dynamism of the service.

 [0097JISITE WEB SPACE PUBLIC

 It is the general public site that presents the service (to future users, but also to future communities). From this site, you access:

 • The global pages of the Alert-Phone Service ("I am a Citizen", "I am a community").

 • The global presentation pages of the Events.

 • On the pages of presentation of the communities adhering to the service.

 [0099] Summaries of the events database (global synthesis, by community, by type of events, etc.).

 [00100] The site must highlight the dynamic side and real-time acquisition of the service (number of events reported per day, per week, number of events treated by the communities, satisfaction index, etc.) and the importance of the adherent community (users and collectivists). It proposes indicators for the general public and operators.

 [00101] Citizen User Membership Form

 [00102] This form allows the Citizen to register for the Alert-Phone Service. We will treat in this function: "Forgotten password, redefine a new password"

 [00103] Membership form of a community

 [00104] This form allows a community to join the Alert-Phone Service. As a first step, this form may not exist, but would allow the community to contact the Administrator to finalize the contractual part. The addition of a new community and its setting will be done in the application ALERT-PHONE-ADMIN.

 [00105] Citizen User Login Form

 [00106] Allows the Citizen to access the functions of the service, and the management of its Events: private part of the Citizen.

 [00107] Mapping Events

In accordance with FIGS. 10 and 11, the location of the events is displayed on a map, with a precision depending on the number of events as a function of the zoom level. [00109] This representation of filters is associated with the display of events in:

 • Function of the period (day-month-year)

 • Event type function

 · State function (processed, untreated, in progress, etc.)

 [00110] COTE COLLECTIVITES: WEBSITE

 The communities in turn access the system according to the invention via a web application for configuration, management, processing of information and associated services.

 The website of the system according to the invention thus has "private" pages accessible only to the declared citizens, as well as to the users of the communities and of two different types:

 [00113] · Private area for the Citizen

 [00114] · Private area for the Operators of a community: It is in these private spaces that the management functionalities of the Alert-Phone service will be positioned.

 The "community" application has two main goals:

• Allow the community to set up its service

• Allow the community to manage Events reported by Citizens.

 It is important to note that in reality, each community will have its own private space, to manage the specificities of Service that it wishes to implement in its perimeter (type of events that can be reported for example: "accident traffic "," water damage "but not" road "when the municipality concerned is not provided.

 The system according to the invention proposes by default a library of type of Events to the community, and the Operator (by simple configuration) will select among these types of Events, those he wishes to collect a report, and who will appear in the list available on the Citizen's mobile phone or the Citizen interface of the website. The community in charge of this Event accesses all the information of this Event declared by the user. The Operator will also be able to enrich this library with its own Alert types. All these types of Alerts will be proposed to the community, and the Operator can create an Alert (dissemination of the Alert to the Citizen) from this library.

 Through the application on mobile phone and the dedicated website, the Citizen will be notified of the presence of an alert issued in accordance with the diagram illustrated in Figure 2.

This alert will therefore have the following properties: 1. Type of Alert (library nomenclature)

 2. Label and description of the alert (taking into account the multilingual).

 3. Activation period (start date, end date). The end date is optional, which means the Alert is Active with no time limit. In this case, the Operator will have to "manually" deactivate the Alert when it is finished.

 4. Territories and / or communities concerned (case management where the Alert may be outside the perimeter of the community).

 [00120] In a first step, the area concerned by the Alert will correspond to the surface of the community concerned. Then the Operator, if he wishes, can define (digitize) himself a more precise geographical area that corresponds to the actual area of the Alert (the impact zone).

 Another "climbing management" feature will allow it to broadcast this Alert on territories adjacent to its own territory. In this case a workflow will allow each Operator of the concerned territories to validate the diffusion of this Alert. We can also provide a link to one or more files, such as a PDF file, which will be displayed by the capabilities of the Smartphone.

 When the Alert is no longer active: End date exceeded or the Operator deactivates the Alert; it disappears automatically from the list of "Alerts issued" presented in the Citizen Smartphone or in its interface on the dedicated website.

 [00123] MANAGEMENT

 These are features that allow the community to manage the Alert-Phone system.

 There are 3 main categories of functions:

 • Administration functions for Community Events.

 • The functions associated with Alerts (definition and distribution).

• The functions of restitution of information, reports, indicators.

 •

 Geographical Perimeter Management

 This function allows a community to define geographically the perimeter in which:

Events created by the Citizen will be geolocated. Alerts generated by the community will be broadcast. By default, for a communal type of community, this geographical perimeter will correspond to the territory of the municipality.

 This division into municipalities, departments, regions will already be present in the Alert-Phone Service. The community will be able to directly select the appropriate surface.

 As an option, digitalization tools will allow other types of authorities or authorities to graphically define their own geographical area in which their Alert-Phone Service will be operational.

Manage services (concept of portal by service)

 Allows to declare the internal services (Equipment, Roads, Works, etc.) of the community which, among other things, will be responsible for taking into account the declared Events.

 • Declare a service (presentation, radius of actions, etc.)

• Manage the users of this service: users, profiles, rights.

Manage options

 Different options can be activated or not

 Presentation options: Graphic chart, logo, name, etc. Points Management Options

 • Options on the level of detail or presentation of results to citizens, to the general public.

 Etc.

EVENT MANAGEMENT Manage the Events database

 From the Global Events Library (Library defined by the overall Service Administrator), the Operator selects the types of Events that he wishes to propose to the Citizens of his community.

 For each type of Event selected, the Operator defines the following parameters:

 • Setting the de-doubling function:

 o Definition of the geographical perimeter (in meter)

 o Definition of the period (in hour)

• Modification of the wording and description of the Event • Assignment of the service that will be in charge of processing the Event (service and / or Operator).

 Manage Workflow

 Definition of Workflow in the management of the taking into account of a fact: definition of the states and the associated actors for each of the states.

Manage Events Created

 The Operator will pay the Events that are intended for him and process them. This acquittal is important because it will be reported to the Citizen who declared the Event.

 Taking into account quickly, and a quick closing (event treated or no action) will create a feeling of satisfaction for the user (if a user realizes that there is no consideration, it does not). will have more the will to declare Events).

ALERT MANAGEMENT Manage Alert Types

 In addition to the global Alerts library defined by the Service Administrator (ALERT-PHONE-ADMIN tool), the Operator has the ability to define his own types of Preformatted Alert. For example, for a specific type of Alert, the list of setpoints would already be defined.

 Define an Alert (create an Alert)

 From the Global Alerts Library (Library defined by the Service's Global Administrator and Community Specific Library), the Operator selects the Alert that they wish to send to Citizens in their community.

 Interoperability with external systems

 The application Alerts system allows interoperability with external systems such as a centralized state service, or a private service (eg a territory-wide weather information service, which may provide an Authority with meteorological information concerning its perimeter.

An alert issued from an external source, will be declared in the system via WebServices made available by the solution. This Alert can then be disseminated by notification to all citizens with the application.

 For this, the operator visualizes in the Backoffice application the External Alerts, then, it validates if necessary Alerts that will be reflected in the solution according to the invention through the platform.

 The alert will be automatically associated with an authority, it is issued for the authority's perimeter (in our example, this corresponds to the outline of the municipality).

 So any terminal that is or enters this perimeter will be automatically notified of the current Alert.

 Declaration form of an Alert

 The notification form of an Alert allows you to enter or modify all the information relating to an Alert.

 1. Choice of the type of Alert

 2. Change the description and description of the Alert.

 3. Choice of an activation period (start date, end date, manual management)

 4. Territories and / or communities concerned (management of the case where the Alert can leave the perimeter of the community)

 5. Definition of instructions

 6. Etc.

TYPE OF LOCATION OF AN ALERT

 The operator can himself define a specific area for the alert, whether issued by the Authority on which it depends, or by an external service.

 These areas are therefore of different types:

There is always the perimeter of authority

 This corresponds to the functionality already available in V1, no functional change.

 A digitized area on the map: rectangle, circle, polygon.

The operator can therefore define temporary zones or that will be saved in the system. These zones will have at least one name, which will allow you to select it when the operator creates the Alert. These zone names can be "sorted" or categorized into a functional tree.

 The selection of a graphic entity belonging to a layer of the map: district, district, etc.

Setting alert zones

 A function will create an alert zone:

 Name, Description

 Associated geographical entity:

 o Existing graphic entity: district, neighborhood

 o Graphic entity drawn by the operator

 The choice of geographical entity will automatically associate the area in m2 with this warning zone.

Manage Alerts

 Presentation of forms allowing to:

 • View the history of Alerts issued.

 • View and manage current Alerts.

 • Renew an Alert.

 • Stop an alert.

 Display warning zones in a table; actions to edit, delete.

 In function of the geographical entity, the actions will be different:

 Existing graphic entity: district, neighborhood

 o Can not delete.

 o Modification of alphanumeric properties (name).

 Graphic entity drawn by the operator:

 o Delete: OK (if no alert is in progress)

 o Modification of alphanumeric and / or graphical properties

: OKAY

RETURN OF INFORMATION The adherent citizens

 Access to the list of Citizens who join the Community Alert-Phone Service. For each Citizen, we can count the number of Events (with a distribution according to the state)

 Events mapping

 The location of Events attached to the community is displayed on a map.

 We can filter according to:

 • Period.

 • Event Status (To be processed, processed, etc.).

 • Assignment to the service in charge of the treatment of the Event (Road, Equipment, etc.).

 • Others according to reflection.

The basis of Events

 This database will allow the creation and display of reports, indicators on the use of the Alert-Phone Service.

 These reports may remain confidential, that is, the community does not distribute them to its Citizens.

 These reports will allow a manager to verify the proper functioning of the Service within a community:

 • Event reporting rate

 Rate of consideration, resolution, etc.

 Other reports or indicators may be disseminated through the public area of the site ALERT-PHONE-COLLECTIVITY with the Citizen.

 Dashboard and Statistics

 Reports highlighting the rate of consideration and resolution can be put in place for each service in the community.

 Generation of a weekly, monthly, annual report on the performance of the Community Alert-Phone Service.

Claims

1. System for exchanging information between different users registered in the system and different authorities associated with geographical areas such as local authorities, including:

 - a common data storage platform

 - terminals of different users, each including

 A means of current geolocation of the terminal,

 · A "signaling" interface enabling the user to signal a location event within an authority,

 Means of transmission to the platform which stores them, of the current location of geolocation of the terminal and of the reported event,

- terminals of the different authorities, each comprising

 · Means of transmission to the platform that stores them, Alerts issued by the authority concerned,

 Means for defining a zone of diffusion of the Alert independent of the current location of geolocation of the terminal of the authority the system further comprising:

 means for transmitting an event stored in the platform to the authority associated with the geographic area where the event has been geolocated, and

 means for transmitting an Alert stored in the platform to a user registered in the system and whose terminal is geolocated in a broadcast area of the Alert defined by the authority concerned.

2. System according to claim 1, wherein the geolocation means of the user terminals are formed of GPS points provided by a device internal to the terminal or by GPS points provided by triangulation of cellular terminals, or are determined by attachment to a code previously deployed and set to a particular spatial area and recorded by the user on its terminal, or are defined by selection by the user of a point on a map displayed in the signaling interface of its terminal.

3. System according to claim 1 or 2, comprising means for automatically triggering the transmission to the platform of the current geolocation location of the terminal of a user.

4. System according to claim 3, wherein the automatic triggering of the transmission to the platform of the current geolocation location of a user's terminal is periodically with a period corresponding to a predefined information feedback time.

5. System according to claim 4, wherein the information feedback time is adapted according to a load level of the user's terminal, being all the more important that the load is low.

6. System according to one of the preceding claims, wherein the interface of a user's terminal comprises a list of types of events that can be reported, according to the current geolocation location of the terminal.

7. System according to one of the preceding claims, wherein the platform comprises means for identifying a secondary event reported by a user, the secondary event being an event identified as similar to an event already reported and stored in the platform.

8. The system of claim 7, wherein the identification of a secondary event is performed by comparing parameters specific to an event already reported and stored and including the geolocation and the time of the event, to defined parameters. by an authority and including a perimeter around an Event, a period of time around the occurrence of an Event and an indication of a relative spatial orientation between the user's terminal and the Event, a new Event being identified as secondary to an event already reported and stored, if it occurs within the perimeter, the period of time and the direction defined by the authority.

9. The system of claim 8, wherein when the interface of the terminal comprises an image or video capture to be associated with the signaling of an event, the indication on the relative spatial orientation between the terminal of the user and the Event takes the form of a compass appearing on the image or video.

10. System according to one of claims 7 to 9, wherein the platform comprises means for ignoring a secondary event and do not store it.

1 1. System according to one of the preceding claims, comprising means for requesting from a user who has signaled an Event, or to any user found in a predefined geographical area around the reported Event, additional information about the Event, such as pictures or confirmation that the Event continues.

12. The system of claim 1 1, wherein the means for requesting additional information on a reported event are managed by the authorities terminals.

13. System according to one of the preceding claims, comprising means for transmitting the signaling of a user-generated event to other users in a predefined geographical area around the reported event.

14. The system of claim 13, wherein the means for transmitting the reporting of a user-generated event to other users are managed by the authorities terminals.

15. System according to one of the preceding claims, wherein the user terminals are mobile or fixed terminals.

16. A method of exchanging information between different users registered in an information exchange system and different authorities associated with geographical areas such as territorial communities, comprising:

 steps of storage of data within a common storage platform to different users and authorities,

a step of identifying the geolocation location of the terminals of the various users registered in the system, each terminal comprising a current geolocation means of the terminal, a "signaling" interface allowing the user to signal a geolocated event within a authority, and means of transmission to the platform that stores them, the current location of geolocation of the terminal and the event reported,

a step of transmission to the platform which stores them, of Alerts issued by terminals of the various authorities, the method further comprising: a step of transmitting events stored in the platform to each authority associated with the geographic area where the event has been geolocated, and

 a step of transmission of Alerts stored in the platform, to each user registered in the system and whose terminal is geolocated in an area of dissemination of the Alert defined by the authority concerned.