EP3058543A1 - Système d'échange d'informations entre différents utilisateurs et différentes autorités - Google Patents

Système d'échange d'informations entre différents utilisateurs et différentes autorités

Info

Publication number
EP3058543A1
EP3058543A1 EP14798919.8A EP14798919A EP3058543A1 EP 3058543 A1 EP3058543 A1 EP 3058543A1 EP 14798919 A EP14798919 A EP 14798919A EP 3058543 A1 EP3058543 A1 EP 3058543A1
Authority
EP
European Patent Office
Prior art keywords
event
user
terminal
authority
platform
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP14798919.8A
Other languages
German (de)
English (en)
Inventor
David Denis
Jean-Marc DU SAILLANT DU LUC
Jean-Michel PAYET
Jean-Philippe DEGONVILLE
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ineo Digital SNC
Original Assignee
Ineo Digital SNC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ineo Digital SNC filed Critical Ineo Digital SNC
Publication of EP3058543A1 publication Critical patent/EP3058543A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G06Q50/26—Government or public services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management

Definitions

  • 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
  • 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.
  • events such as the occurrence of a traffic accident or a slowdown
  • 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.
  • 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.
  • 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.
  • 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.
  • 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:
  • the system further comprising:
  • 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,
  • BTS triangulation of cellular antennas
  • 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.
  • 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
  • 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 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,
  • 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:
  • 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,
  • the method further comprising:
  • 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.
  • 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.
  • This system provides mainly two types of information exchange, which can interact with each other:
  • 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 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.
  • 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.
  • the Event must be geolocated:
  • the Event is automatically geolocated by one or both of the following methods:
  • 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).
  • the location is defined by the pair of values:
  • the diagram illustrated in Figure 1 generally shows the state changes associated with an event.
  • the Event object has many properties:
  • a severity rate (from 1 to 5)
  • the event object is attached to a level in the tree.
  • a category (level 1 of the nomenclature).
  • a type of event and sub type (function of the number of level).
  • This text information, entered by the citizen is optional.
  • the citizen can associate for example from 0 to 3 photos.
  • 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:
  • o NULL no associated information. (For example, if the user selects existing photos, or uses the website form).
  • This information is available and will be displayed to the authority operator in the tab that shows the photos of the event.
  • the citizen will be able to associate from 0 to 3 videos.
  • 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.
  • TAKEN INTO ACCOUNT The user of the authority indicates that the event is taken into account, and therefore being processed.
  • PROCESS The event is processed, the authority user indicates the change of state.
  • 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.
  • 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.
  • (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.
  • the Event is of "Secondary" class and will be attached to the Primary Event.
  • 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.
  • the Event may be presented as primary.
  • 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.
  • the system according to the invention thus provides the Operator with the means for setting the de-doubling function.
  • 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.
  • 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).
  • 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:
  • 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:
  • the Administrator of Authority will be able to define his own thresholds, and thus choose his mode of management for his authority:
  • 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)
  • 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 first threshold value for example 65/100
  • a second threshold value for example 70/100
  • a primary event can be linked to 0 or more events secondary.
  • o Information is kept about whether an operator changes the type of this event.
  • 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.
  • the system tells him the number of devices that are potentially in the zone.
  • 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:
  • Result of the query is empty: Result of the query not empty:
  • 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).
  • the Authority Administrator will provide values to define the reliability of Geolocation based on the type.
  • the note will be fixed at 100. ⁇ and possibly, a note on the orientation of the shots (photos).
  • 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.
  • the implicit reliability rate therefore corresponds to the average of the 2 notes previously described: Orient tilote. Photo + '' Liver Geoksc type
  • the administrator of the authority defines coefficients for each of its 2 rates: Then we calculate the final score according to these 2 values:
  • 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.
  • this Event may appear with a color depending on the severity assigned to it, with a visual signal (flashing event display) or sound (alarm).
  • 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 citizen can use several equipment.
  • An event is created by a citizen, from:
  • 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) ...
  • a user is assigned a degree of confidence, or points of credibility for example calculated by an algorithm, and noted from 1 to 10.
  • a global setting by authority will define the number of points for a declared event of type Primary and Secondary type.
  • the user of the entity can, on a case-by-case basis, add or remove points to the event.
  • 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).
  • 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.
  • a third party for example a check to the attention of an association of the municipality
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the citizen can modify or delete certain information associated with the event.
  • the Citizen can:
  • 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.
  • 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.
  • 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).
  • an external information system such as a government information system (for example: National police for Abduction Alerts).
  • the Alert is necessarily associated with a geographical perimeter and disseminated to citizens present in this area.
  • 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.
  • the Alert is distributed only to citizens present in the perimeter defined for the Alert.
  • 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.
  • 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.
  • 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 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 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.
  • 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.
  • a user of the authority belongs to one or more services.
  • 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.
  • 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.
  • the Alert-Phone service is composed at the FrontOffice level of the following interfaces:
  • the backoffice is composed of Web Application servers that will support the following components:
  • WebServices 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).
  • 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.
  • the Citizen can declare an Event and its associated data: Choice of the type of Event
  • 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 can also delete:
  • 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.
  • 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.
  • 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.
  • 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.
  • the application is personalized (Logo, name of the community, graphic charter, etc.).
  • 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? "
  • 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.
  • the application ALERT-PHONE-SMART automatically adapt the sending period of the position of the equipment to not solicit the battery in this context.
  • the feedback of the position information is automatically activated on a short cycle (every 5 minutes for example).
  • 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.
  • Alpha information text, type, date, etc.
  • 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.
  • 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.
  • 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 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.
  • the Citizen consults the active Alerts in the area where it is located.
  • This event sends the geolocation of the person for a more accurate identification of the situation.
  • 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,
  • 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.
  • 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.
  • a threshold (30 km / h for example)
  • the terminal is automatically identified in "VEHICLE” mode to consolidate traffic data.
  • 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 Collect Supreme and / or the competent services to remedy situations and to inform the citizens.
  • 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).
  • the first page may contain, for example:
  • links will display specific pages (in terms of presentation and informative content) to each community and associated services.
  • the pages associated with the communities may be presented according to:
  • This function gathers all the Alerts issued by the communities to which the user adheres. The user can access all the Alerts issued.
  • a "community" could be of national type and thus spread the Alerts that impact the national territory.
  • 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.
  • 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.
  • the user visualizes on the map his own Events. It can therefore access it by direct selection on the map.
  • 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.
  • 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.
  • 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:
  • the "community” application has two main goals:
  • 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.
  • 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.
  • 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.
  • a workflow will allow each Operator of the concerned territories to validate the diffusion of this Alert.
  • This function allows a community to define geographically the perimeter in which:
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • the notification form of an Alert allows you to enter or modify all the information relating to 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.
  • 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.
  • a function will create an alert zone:
  • the location of Events attached to the community is displayed on a map.
  • Event Status (To be processed, processed, etc.).
  • This database will allow the creation and display of reports, indicators on the use of the Alert-Phone Service.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Tourism & Hospitality (AREA)
  • Human Resources & Organizations (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • General Physics & Mathematics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Quality & Reliability (AREA)
  • Operations Research (AREA)
  • Development Economics (AREA)
  • Educational Administration (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Telephonic Communication Services (AREA)
  • Alarm Systems (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un système d'échange d'informations entre différents utilisateurs inscrits au système et différentes autorités associées à des zones géographiques telles que des collectivités territoriales, comprenant : - une plateforme commune de stockage de données (P) - des terminaux des différents utilisateurs (Ui), comprenant chacun • un moyen de géolocalisation courant du terminal, • une interface « signalisation » permettant à l'utilisateur de signaler un Evènement géolocalisé au sein d'une autorité, • des moyens de transmission à la plateforme qui les stocke, du lieu courant de géolocalisation du terminal et de l'Evènement signalé, - des terminaux des différentes autorités (Ci), comprenant chacun • des moyens de transmission à la plateforme qui les stocke, d'Alertes émises par l'autorité considérée, le système comprenant en outre : - des moyens de transmission d'un Evènement stocké dans la plateforme à l'autorité associée à la zone géographique où l'Evènement a été géolocalisé et horodaté, et - des moyens de transmission d'une Alerte stockée dans la plateforme, à un utilisateur inscrit au système et dont le terminal est géolocalisé dans une zone de diffusion de l'Alerte définie par l'autorité considérée. L'invention concerne également le procédé d'échange d'informations associé.

Description

SYSTEME D'ECHANGE D'INFORMATIONS ENTRE DIFFERENTS
UTILISATEURS ET DIFFERENTES AUTORITES
DESCRIPTION
DOMAINE TECHNIQUE
[0001] L'invention se rapporte à un système d'échange d'informations entre différents utilisateurs et différentes autorités.
[0002] Le domaine d'application de l'invention concerne l'échange d'informations entre des utilisateurs et différentes autorités, par exemple entre des Citoyens et des collectivités territoriales permettant aux Citoyens, de signaler des Evénements survenus dans leurs collectivités (« un Evénement »), et aux collectivités d'émettre des alertes à l'attention de Citoyens présents dans une zone géographique pertinente, liée aux
Evénements signalés ou totalement indépendantes de ceux-ci (« une Alerte »).
[0003] Cet échange entre Citoyens et collectivités est bénéfique pour fluidifier, sécuriser et faciliter le bien-être des utilisateurs au sein de ces collectivités en les impliquant en outre dans le fonctionnement de la collectivité considérée.
[0004] L'échange d'informations entre utilisateurs et autorités s'effectue via une application préalablement téléchargée sur un téléphone intelligent, ou Smartphone, ou via une interface d'un site internet dédié, ces informations étant ainsi rendues accessibles aux utilisateurs du système, sédentaires ou en déplacement.
ÉTAT DE LA TECHNIQUE [0005] Il est connu du document US 7 301 450, un système de communication d'Alertes émises par un centre de communication aux Citoyens, rattaché par exemple à une municipalité, à destination de Citoyens adhérents au système et ayant choisi de recevoir ce type d'Alerte. Dans ce système, le centre de communication recueille sur internet, par le biais de sites gouvernementaux ou d'autres bases de données, des Alertes à l'attention de la population, telles que des Alertes météorologiques, et les transmet, par SMS, courriel ou via un site internet dédié, aux utilisateurs s'étant préalablement déclarés désireux de recevoir ce type d'information. Ce système d'échange d'informations est adapté aux Alertes de grande ampleur mais s'avère inopérant pour des Alertes relatives à des faits plus localisés, dont aucun rapport ne sera établi sur un site gouvernemental. En outre, bien que les sources fournissant en informations les centres de communications soient relativement fiables, celles-ci ne s'avèrent cependant pas suffisamment réactives lors de la survenue d'un fait soudain, isolé, et localisé, tel que la survenue d'un dégât des eaux ou la chute de grêlons dans une ville.
[0006] Par ailleurs, dans un tout autre domaine d'application, les systèmes d'aide à la conduite permettent à des utilisateurs de déclarer des Evénements, tels que la survenue d'un accident de circulation ou d'un ralentissement, via un dispositif de navigation ou une application téléchargée sur leur Smartphone, afin que cet Evénement soit signalé à des utilisateurs présents dans la zone où l'Evénement est survenu. Tel est le cas du système décrit dans le document FR 2 982 986. Toutefois, si ce système permet effectivement la déclaration de l'Evénement gênant ou d'un problème, il n'en permet pas la résolution, les Evénements déclarés par des utilisateurs demeurant à la seule connaissance de ces utilisateurs qui ne sont pourtant pas en mesure d'apporter une solution à la gêne occasionnée par l'Evénement. EXPOSÉ DE L'INVENTION
[0007] L'invention vise à résoudre les problèmes évoqués ci-dessus en permettant un échange bilatéral d'informations entre d'une part différents utilisateurs du système et d'autre part différentes autorités, qui coopéreront pour fournir pratiquement en temps réel des informations sur un fait particulier, et permettre un traitement de ce fait par les autorités compétentes, soit en résolvant le problème occasionné par ce fait soit en diffusant au plus grand nombre d'utilisateurs des informations sur ce fait.
[0008] Plus particulièrement, l'invention concerne une solution technique et logicielle de signalement d'un événement au moyen de terminaux mobiles ou fixes, traitement de ces événements au moyens de portails métiers par des autorités et diffusion d'alertes depuis ces portails métiers auprès de ces terminaux mobiles ou fixes à l'échelle d'un territoire allant d'un site propre (site industriel, bâtiment) au territoire national d'un pays ou état.
[0009] Plus précisément, la présente invention a pour objet un système d'échange d'informations entre différents utilisateurs inscrits au système et différentes autorités associées à des zones géographiques telles que des collectivités territoriales, comprenant :
- une plateforme commune de stockage de données
- des terminaux des différents utilisateurs, comprenant chacun • un moyen de géolocalisation courant du terminal,
• une interface « signalisation » permettant à l'utilisateur de signaler un Evénement géolocalisé et de préférence horodaté au sein d'une ou plusieurs autorités (selon qualification de l'Evénement),
• des moyens de transmission à la plateforme qui les stocke, du lieu courant de géolocalisation du terminal et de l'Evénement signalé,
- des terminaux des différentes autorités, comprenant chacun
• des moyens de transmission à la plateforme qui les stocke, d'Alertes émises par l'autorité considérée,
Le système comprenant en outre :
- des moyens de transmission des événements stockés dans la plateforme aux autorités associées respectivement aux zones géographiques où chaque Evénement a été géolocalisé, et
- des moyens de transmission des Alertes stockées dans la plateforme, aux utilisateurs inscrits au système et dont les terminaux sont géolocalisés dans une zone de diffusion de l'Alerte définie par l'autorité considérée.
[0010]Selon des modes de mise en œuvre avantageux :
- les moyens de géolocalisation des terminaux des utilisateurs sont formés de points GPS fournis par un équipement interne au terminal ou par des points GPS fournis par triangulation d'antennes cellulaires (BTS), ou sont déterminés par rattachement à un code préalablement déployé et paramétré en une zone spatiale particulière et enregistré par l'utilisateur sur son terminal lors d'un besoin de géolocalisation (« tags » en zone non couverte, à l'intérieur de bâtiments ou d'environnements enterrés), ou sont définis par sélection par l'utilisateur d'un point sur une carte affichée dans l'interface de signalisation de son terminal,
- le système comprend des moyens de déclenchement automatique de la transmission à la plateforme du lieu courant de géolocalisation du terminal d'un utilisateur,
- le déclenchement automatique de la transmission à la plateforme du lieu courant de géolocalisation du terminal d'un utilisateur s'effectue périodiquement avec une période correspondant à un temps de remontée d'information prédéfini
- le temps de remontée d'information est adapté en fonction d'un niveau de charge du terminal de l'utilisateur, le temps de remontée étant d'autant plus important que la charge est basse,
- l'interface du terminal d'un utilisateur comprend une liste de types d'Evénements susceptibles d'être signalés en fonction du lieu courant de géolocalisation du terminal (selon la capacité de traitement de l'autorité couvrant le territoire et ses propositions),
- la plateforme comprend des moyens d'identification d'un Evénement secondaire signalé par un utilisateur c'est-à-dire un Evénement identifié comme similaire à un Evénement déjà signalé et stocké dans la plateforme,
- l'identification d'un Evénement secondaire s'effectue par comparaison de paramètres propres à un Evénement déjà signalé et stocké et incluant la géolocalisation et l'heure de l'Evénement, à des paramètres définis par une autorité et incluant un périmètre autour d'un Evénement, une période de temps autour de la survenue d'un Evénement et une indication sur une orientation spatiale relative entre le terminal de l'utilisateur et l'Evénement, un nouvel Evénement étant identifié comme secondaire vis-à- vis d'un Evénement déjà signalé et stocké, s'il intervient dans le périmètre, la période de temps et l'orientation définis par l'autorité
- la plateforme est capable de rattacher, selon les différentes règles suscitées, un Evénement à un autre et de réaliser ainsi un dé-doublonnage de l'ensemble des Evénements reçus.
- lorsque l'interface du terminal comprend une capture d'image ou de vidéo à associer à la signalisation d'un Evénement, l'indication sur l'orientation spatiale relative entre le terminal de l'utilisateur et l'Evénement prend la forme d'une boussole apparaissant sur l'image ou la vidéo de manière explicite (marquage) ou implicite (données internes),
- la plateforme comprend des moyens pour ignorer un Evénement secondaire en ne le stockant pas
- selon une alternative, le système comprend des moyens pour demander à un utilisateur ayant signalé un Evénement, ou à tout utilisateur se retrouvant dans une zone géographique prédéfinie autour de l'Evénement signalé, des renseignements complémentaires sur l'Evénement, tels que des images ou une confirmation que l'Evénement perdure,
- les moyens pour demander des renseignements complémentaires sur un Evénement signalé sont gérés par les terminaux des autorités
- selon une variante de réalisation, le système comprend des moyens pour transmettre le signalement d'un Evénement généré par un utilisateur, à d'autres utilisateurs se trouvant dans une zone géographique prédéfinie autour de l'Evénement signalé
- les moyens pour transmettre le signalement d'un Evénement généré par un utilisateur, à d'autres utilisateurs sont gérés par les terminaux des autorités
- le signalement d'un Evénement par un usager, peut être réalisé suite à une action volontaire de l'usager ou automatiquement c'est à dire sans action de sa part. Ce dernier cas concerne des faits, tels qu'un choc subi par un usager dans son véhicule, susceptibles de générer des informations interprétables par la plateforme, en l'occurrence dans l'exemple considéré, une discontinuité dans les données fournies par un accéléromètre contenu dans le terminal de l'usager disposé dans le véhicule. La transmission automatique d'un tel événement peut être paramétrée au préalable par l'usager qui choisira le type de fait pouvant être automatiquement signalé comme un Evénement à la plateforme, sans donc aucune action spécifique de sa part,
- selon un mode de réalisation, les terminaux des utilisateurs sont des terminaux mobiles ou fixes.
[0011] L'invention concerne également un procédé d'échange d'informations entre différents utilisateurs inscrits à un système d'échange d'informations et différentes autorités associées à des zones géographiques telles que des collectivités territoriales, comprenant :
- des étapes de stockage de données au sein d'une plateforme de stockage commune aux différents utilisateurs et aux différentes autorités,
- une étape d'identification du lieu de géolocalisation des terminaux des différents utilisateurs inscrits au système, chaque terminal comprenant un moyen de géolocalisation courant du terminal, une interface « signalisation » permettant à l'utilisateur de signaler un événement géolocalisé au sein d'une autorité, et des moyens de transmission à la plateforme qui les stocke, du lieu courant de géolocalisation du terminal et de l'événement signalé,
- une étape de transmission à la plateforme qui les stocke, d'alertes émises par des terminaux des différentes autorités
Le procédé comprenant en outre :
- une étape de transmission des Evénements stockés dans la plateforme à chaque autorité associée à la zone géographique où l'événement a été géolocalisé, et
- une étape de transmission des Alertes stockées dans la plateforme, à chaque utilisateur inscrit au système et dont le terminal est géolocalisé dans une zone de diffusion de l'Alerte définie par l'autorité considérée.
De préférence, le procédé comprend en outre une étape de transmission des Evénements stockés dans la plateforme à chaque service d'une autorité ou chaque usager ayant choisi, par adhésion explicite de recevoir automatiquement des informations sur certains Evénements selon leur nature. PRÉSENTATION DES FIGURES
[0012] D'autres données, caractéristiques et avantages de la présente invention apparaîtront à la lecture de la description non limitée qui suit, en référence aux figures annexées qui représentent, respectivement :
la figure 1 , représente de façon schématique le fonctionnement du système selon l'invention pour le traitement d'Evénements signalés par un utilisateur ;
la figure 2, représente de façon schématique le fonctionnement du système selon l'invention pour la communication d'Alertes émises par une autorité, à l'attention d'utilisateurs abonnés à cette autorité
la figure 3 illustre de façon schématique l'ensemble du procédé d'échange d'informations,
les figures 4 à 6 représentent schématiquement le processus d'identification d'un Evénement primaire et d'un Evénement secondaire,
les figures 7 à 9 illustrent schématiquement l'identification de citoyens présents dans une zone de diffusion d'une Alerte,
les figures 10 et 1 1 montrent un schéma illustrant l'affichage de la cartographie des Evénements sur l'espace Grand Public du site Web du système selon l'invention.
DESCRIPTION DÉTAILLÉE
[0013] Le système selon l'invention sera décrit dans ce qui suit en référence à un mode de réalisation selon lequel les « autorités » sont des collectivités territoriales repérées par « Ci » sur la figure 3, telles que des villes, et les utilisateurs désignés par « Ui » sur cette même figure, des
Citoyens susceptibles d'être situés dans une ville rattachée au système ou de se déplacer entre villes.
[0014]Ce système permet de fournir principalement deux types d'échange d'information, qui peuvent interagir l'un l'autre :
- le signalement d'Evénements par le Citoyen sur action volontaire de sa part, ou de façon automatique, à destination des villes et plus largement de collectivités et
- l'émission d'Alertes par une collectivité (et plus généralement une autorité) à destination du Citoyen
[0015] Il s'agit d'un service unique accessible sur tout le territoire d'un
Etat avec un unique site (portail en accès direct type WEB ou indirect via application mobile) connu du grand public (les utilisateurs déclarés) et des collectivités (les différentes villes abonnées au système agissant via des Opérateurs), et une unique plateforme de stockage P des événements signalés par les différents utilisateurs, et des Alertes émises par les différentes villes. Un Opérateur administrateur par ville gère ses propres usagers, ses types d'Evénements et ses critères de dé-doublonnage. Un Administrateur global gère le système.
[0016] Les utilisateurs accèdent au procédé d'échange d'informations selon l'invention soit via une application gratuite préalablement téléchargée sur leur téléphone mobile intelligent, soit via une application web de type portail, les collectivités territoriales via un site web et l'Administrateur global également via un site web.
[0017] Les interfaces des applications ou sites web dédiés aux Citoyens, aux collectivités et aux Administrateurs seront explicitées en fin de description.
[0018] Identification des différents intervenants :
On distingue quatre types d'intervenants : On va donc distinguer quatre catégories de personnes :
• Les utilisateurs inscrits, nommés « les Citoyens » et pouvant déclarer des Evénements et recevoir des Alertes.
• Les utilisateurs non inscrits, c'est-à-dire les internautes qui accéderont aux pages « Grand public » du site web ou les détenteurs de téléphones mobiles n'ayant pas téléchargé l'application, nommés le Grand Public.
• Les Opérateurs d'une collectivité, en charge de la gestion du service public pour une collectivité.
· Les Administrateurs du service : « l'Administrateur » représentés par des personnes en charge de la gestion du Système d'échange d'informations entre les différents utilisateurs et les différentes autorités objet de l'invention.
[0019] Les utilisateurs devront être inscrits dans le système et donc authentifiés pour accéder aux fonctionnalités. Cette inscription peut s'effectuer avec comme identifiant pour l'intervenant, son email, ou son numéro de téléphone authentifié par procédure.
[0020]Authentification des équipements : terminaux mobiles ou fixes des Citoyens.
[0021] Un équipement correspond à un terminal mobile sur lequel est installée l'application ou un terminal fixe ayant accès au site web dédié à cette application. L'équipement sera identifié en tant que tel et lié à un Citoyen. Le Citoyen pourra associer autant d'équipements qu'il le souhaite.
[0022] Localisation d'un événement [0023] La géolocalisation est une donnée essentielle du système selon l'invention.
Celle-ci est une propriété intrinsèque d'un Evénement et d'une
Alerte.
L'Evénement est obligatoirement géolocalisé :
1 . Lors de la création d'un Evénement à partir d'un équipement mobile par un Citoyen au travers de l'application téléchargée sur son téléphone, l'Evénement est automatiquement géolocalisé par l'un et/ou l'autre des procédés suivants :
• Point GPS (coordonnées (X, Y) fourni par l'équipement lui- même
• Point GPS fourni par la triangulation des cellules BTS.
• Rattachement à un « tag » type « QRCode » préalablement déployé et paramétré, (principe de géolocalisation sur des sites de types « Indoor » : bâtiments, sites industriels, etc.). Le « QRCode » est une étiquette supportant un TAG connu du système selon l'invention : A chaque « QRCode» correspond une position géographique (Point réel cartographique ou une position sur un plan par exemple). Le « QRCode » est préalablement déployé et paramétré. (Principe de géolocalisation sur des sites de types « Indoor » : bâtiments, sites industriels, etc.). Le « QRCode » est une étiquette supportant un TAG connu du service Alert-Phone : A chaque « QRCode» correspond une position géographique (Point réel cartographique ou une position sur un plan par exemple).
2. Lors de la création d'un Evénement à partir du site Web dans la partie privative du Citoyen, le Citoyen devra définir sur une carte (par un simple « click » sur cette carte) la géolocalisation de l'Evénement.
La localisation est donc définie par le couple de valeurs :
Type de localisation :
o GPS EQUIPEMENT
o GPS_BTS
o GPS_CARTO
o QRCODE
Valeur de localisation
o Coordonnées (X, Y)
o Valeur du « QRCode » [0024] Un Evénement créé par le Citoyen suit un processus précis, dont le but est le traitement de l'Evénement par la collectivité.
[0025] Le diagramme illustré sur la figure 1 présente globalement les changements d'états associés à un Evénement.
L'OBJET EVENEMENT ET SES PROPRIETES
Il s'agit de l'objet créé par le citoyen au travers de l'application Smartphone, ou d'un formulaire sur le site web.
L'objet Evénement possède de nombreuses propriétés :
1 . Il est rattaché à un niveau de la nomenclature des événements.
2. Une description (commentaire ou informations supplémentaires)
3. Un taux de gravité (de 1 à 5)
4. Une localisation
5. Des photos (3 pour l'instant)
6. Des vidéos (x pour l'instant)
7. Un type (Primaire / Secondaire)
8. Un statut
9. Un nombre de points
LES PROPRIETES DIRECTES DE L'EVENEMENT
Catégorie et type de l'événement
L'objet événement est rattaché à un niveau de l'arborescence.
Il possède donc :
Une catégorie (niveau 1 de la nomenclature).
Un type d'événement et sous type (fonction du nombre de niveau).
Description
Cette information de type texte, saisie par le citoyen est optionnelle.
On se limitera à 255 caractères.
Taux de gravité
Information subjective renseigné par le citoyen de type entier Des photos
Le citoyen peut associer par exemple de 0 à 3 photos.
Celles-ci sont stockées dans un répertoire spécifique.
Taille des images : pour ne pas pénaliser le temps de chargement des fichiers (d'équipement mobile vers le serveur), la taille des fichiers doit être modifiée avant envoi.
La résolution choisie est de : 800*450 avec un poids entre 50 et 100 Ko.
Chacune des photos associées possède une propriété :
· L'orientation. Les valeurs possibles sont :
o NULL : aucune information associée. (Par exemple, si l'utilisateur sélectionne des photos existantes, ou utilise le formulaire du site web).
o De 0 à 359 : valeur de l'orientation par rapport au Nord.
Cette information est disponible et sera affichée à l'opérateur de l'autorité dans l'onglet qui présente les photos de l'événement.
Exemple :
2 photos sont associées à l'événement
Photo 1 , Orientation = 310
Photo 2, Orientation = 325
Des vidéos
Le citoyen pourra associer de 0 à 3 vidéos.
Celles-ci sont stockées dans un répertoire spécifique.
A Spécifier : Re-nommage + mode de stockage.
Règles sur le poids de la vidéo ?
La gestion des vidéos ne sera pas implémenter pour la version typée Q1 . La spécification fonctionnelle associée, sera produite ultérieurement. Le statut de l'Evénement apparaissant sur le terminal de l'Autorité, et modifié par l'opérateur de l'autorité :
De la création de l'événement à sa clôture, celui-ci va suivre différents statuts. Les différents statuts sont les suivants :
OUVERT C'est le statut par défaut : l'événement est créé dans le système, mais l'algorithme de dé-doublonnage n'a pas spécifié le type de l'événement.
A TRAITER Le type de l'événement est spécifié (Primaire ou Secondaire). L'élément est donc présenté à l'utilisateur de l'autorité qui doit le traiter.
PRIS EN COMPTE L'utilisateur de l'autorité indique que l'événement est pris en compte, et donc en cours de traitement.
NON PRIS EN COMPTE L'utilisateur de l'autorité indique que l'événement ne sera pas pris en compte, il ne s'agit pas d'un événement pertinent à traiter.
TRAITE L'événement est traité, l'utilisateur de l'autorité indique le changement d'état.
CLOTURE Ce statut permet de sortir l'événement de la liste des événements en cours. Cela correspond à un archivage de l'événement.
REJETE Suite au statut « NON PRIS EN COMPTE », un événement pourra être « REJETE » si s'agit d'une « fausse » déclaration.
Pour chacun de ces états, est associée une date (date de changement d'état), ainsi qu'un lien vers l'utilisateur à l'origine de la modification.
On conserve l'historique des changements de statut. Cet historique se présentera insi :
OUVERT 12Î52/2814 - 1:1 H22 5 - :Préf!Gm| ■
A T AIT SYSTEM ■
PRIS m CO MPTE 12¾2ί28·Μ - TLiSTAEUR • U - Ρεέαοπξ ■
TRAITER UStEZOU - iiTLISTÀEliR l HOU - Préi nî II
CLOTURER 1&¾2/2:S1:4 - 1:8H'3S ÛTLiSTÂEUR : - FïériOîriî ■ [0026] Principe du « dé-doublonnage d'un événement » ou du « regroupement d'Evénements secondaires avec un Evénement primaire »
Le but de cette fonction est de ne pas surcharger l'Opérateur lors du traitement des Evénements, par le stockage multiple d'informations similaires ou identiques relatives à un seul et même événement.
Prenons l'exemple d'un lampadaire public qui ne fonctionne plus.
Si plusieurs Citoyens déclarent cet Evénement : « Dysfonctionnement LAMPADAIRE », alors l'Opérateur devra traiter un grand nombre d'Evénements qui sont tous identiques. Si on ajoute à cela une période de temps assez longue pour la réparation (par exemple quelques jours), alors l'Opérateur sera submergé par un Evénement au détriment d'autres Evénements.
Pour éviter cela, un traitement spécifique (Algorithme de dé- doublonnage) sera appliquer à chaque Evénement et qui permettra de classer les Evénements en deux catégories :
• Evénement primaire
• Evénement secondaire
L'Evénement primaire correspond à la première déclaration par un Citoyen d'un Evénement pour un type donné. Celui-ci devra donc être traité par l'Opérateur et suivra un processus de changement de statut tel qu'indiqué sur le diagramme de la figure 1 .
L'Evénement secondaire correspond au même Evénement (même type) que le primaire, mais il a été déclaré par la suite. Dans ce cas, cet Evénement est rattaché à l'Evénement primaire et ne sera pas traité par l'Opérateur. Cet Evénement secondaire suivra le statut de l'Evénement primaire. L'Opérateur pourra accéder aux informations des Evénements secondaires à sa demande afin d'obtenir, par exemple, des informations complémentaires sur l'Evénement.
L'Evénement primaire aura d'autant plus d'importance qu'il y aura d'Evénements secondaires qui s'y rapporteront.
La classification est automatiquement réalisée par le système selon l'invention en fonction des paramètres suivants pour chacun desquels seront définies des plages de valeurs associées :
(A) Périmètre géographique (rayon d'action),
· (B) Période de temps
(C) Orientation (lors de la prise de la photo ou vidéo). L'Opérateur administrateur peut modifier implicitement et simplement les valeurs (A) et (B) par type d'Evénement. Les données (C) sont exploitées par le système pour départager les ambiguïtés résiduelles. D'autres données pourront intervenir pour départager ces dernières tel qu'un degré d'urgence fourni par le Citoyen.
En reprenant l'exemple ci-dessus, l'Opérateur pourra donc définir les plages de valeurs pour les règles de dé-doublonnage du type d'Evénement « Dysfonctionnement LAMPADAIRE » :
• (A) Périmètre géographique : 0-25 m
(B) Période : 0-72 heures
Concrètement, conformément à la figure 4, si un événement de type « Dysfonctionnement LAMPADAIRE » est créé, et que le service ne trouve aucun Evénement de même type créé dans les 72 heures dans un rayon de 25 mètres, alors celui-ci est de classe « Primaire ».
Dans le cas contraire (le service trouve déjà un Evénement existant dans les 72 heures ET dans un rayon de 25 mètres), l'Evénement est de classe « Secondaire » et sera rattaché à l'Evénement primaire.
Conformément aux figures 5 et 6, l'orientation, lors d'une prise de photo ou de vidéo, permettra dans certains cas, de détecter si des Evénements secondaires sont bien des doublons de l'Evénement primaire, ou si un doute subsiste. Dans ce cas, l'Evénement pourra être présenté comme primaire. Ces critères serviront à traiter automatiquement les ambiguïtés résiduelles.
Dans le cas de la figure 5, le 2eme Evénement (point proche du contour du cercle) sera bien défini comme « Secondaire », car l'orientation enregistrée lors de la prise de vue est compatible avec celle de l'Evénement primaire.
Dans le cas de la figure 6, le 2eme Evénement à priori défini comme « Secondaire » (Périmètre géographique et période sont respectés) se verra classé « Primaire » car l'orientation de prise de vue ne correspond pas à celle du précédent Evénement.
Le système selon l'invention fournit donc à l'Opérateur les moyens pour paramétrer la fonction de dé-doublonnage. Algorithme de regroupement
Le système comprend en outre un algorithme permettant de regrouper des Evénements survenant après d'un Evénement primaire et en dehors des plages de valeurs de paramètres prévus pour qualifier un Evénement de secondaire, et de les attribuer à l'Evénement primaire.
Plus précisément, cet algorithme utilise en plus des paramètres initiaux définis pour qualifier un Evénement secondaire (périmètre géographique A et période B selon l'exemple précédent), une pondération pour chacun de ces paramètres, par exemple comprise entre 1 et 10 et permettant d'attribuer une note permettant d'apprécier pour le paramètre considéré la probabilité qu'il soit réellement secondaire (la note « 1 » représentant une probabilité très faible, par exemple, un Evénement intervenant à plus de 100 m d'un Evénement du même type, et la note « 10 », une probabilité très importante, cette note de 10 pouvant être réservée aux Evénements intervenant dans la tolérance prévue pour qualifier un Evénement de secondaire).
Par exemple, si un Evénement est signalé :
dans la même catégorie qu'un Evénement précédent en date, « Dysfonctionnement LAMPADAIRE » pour reprendre l'exemple précédent,
à un emplacement situé à 26 m de l'Evénement précédent (c'est à dire en dehors du périmètre de 25 m autour dudit Evénement précédent défini dans l'exemple précédent pour identifier un Evénement comme secondaire, mais à un mètre près), et
dans les 73 heures suivant la survenue de cet Evénement précédent (c'est à dire une heure trop tard par rapport à la durée de 72 heures définie pour identifier un Evénement comme secondaire dans l'exemple précédent),
la note attribuée au paramètre géographique A sera relativement élevée (par exemple 9/10) et celle attribuée au paramètre temps B, également élevée (par exemple 9/10 également) tant les probabilités sont grandes que cet Evénement situé certes en dehors du périmètre et de la période définis pour être identifié comme secondaire, soit en réalité un Evénement secondaire de l'Evénement précédemment signalé.
Un algorithme mathématique pourra être prévu pour attribuer une pondération à chaque paramètre permettant de qualifier un Evénement secondaire en fonction de l'écart observé pour un Evénement de la même catégorie qu'un Evénement précédent, entre le paramètre relevé pour l'Evénement considéré, et la plage de valeurs définie pour ce paramètre pour qualifier un Evénement de secondaire. L'on pourra éventuellement prévoir de calculer une moyenne des notes attribuées pour l'ensemble des paramètres de qualification d'un Evénement secondaire. Un exemple de l'algorithme de calcul d'une telle note de regroupement est donné ci-après :
La méthode va s'appuyer sur le calcul de deux notes :
• Le taux de fiabilité explicite.
· Le taux de fiabilité implicite.
Chacune de ces notes sera ensuite pondérée pour calculer une note finale entre 0 et 100.
Etape 1 : on recherche s'il existe des événements « Primaires » potentiels :
• Si aucun événement primaire ne correspond, alors il n'y a pas de calcul de la note finale.
• Sinon, on doit calculer une note finale pour choisir le rattachement ou non à cet événement.
Plus la note finale est proche des 100, et plus le système est confiant sur l'affectation du nouvel événement en « Secondaire » : un précédent événement « Primaire » est clairement identifié.
Inversement, si la note finale est proche de la valeur 0, cela indique que la relation vers un événement « Primaire » n'est pas identifiée.
Entre ces deux valeurs (0 et 100), on pourra définir des seuils pour lesquels le système choisira automatiquement ou non un type d'événement.
L'Administrateur de l'autorité pourra définir ses propres seuils, et ainsi choisir son mode de gestion pour son autorité :
• Affectation automatique des événements en Primaire ou Secondaire
L'affectation d'un type secondaire est automatique si la note finale est supérieure ou égale à une valeur de seuil (par exemple 70/100)
• Intervalle de valeur pour lequel l'affectation n'est pas automatique et le système demande une validation de la part de l'opérateur en charge.
Si la note est inférieure à une première valeur de seuil (par exemple 65/100), l'Evénement est automatiquement identifié comme primaire, supérieure à une deuxième valeur de seuil (par exemple 70/100), il est automatiquement identifié comme secondaire, et lorsqu'elle est comprise dans l'intervalle défini par ces deux valeurs de seuil (en l'occurrence entre 65/100 et 70/100), une validation est demandée à l'opérateur de l'Autorité qui identifie par son appréciation l'événement comme primaire ou secondaire en cliquant sur une zone active correspondante de l'écran de son terminal,
a) Calcul du taux de fiabilité explicite Le calcul de ce taux s'applique sur les 2 valeurs : Période et Distance.
Le principe : plus la valeur calculée est proche de 100, plus le taux de fiabilité explicite augmente.
On doit calculer 2 notes :
· Une note pour la Période
• Une note pour le Rayon
Le taux de fiabilité explicite correspond donc à la moyenne des 2 notes précédemment décrite :
N&ietPsrioûe + Not»R3 on
Taux de fiabilité explicite =
b) Calcul du taux de fiabilité implicite
Le calcul de ce taux s'applique sur 2 valeurs.
Le principe : plus la valeur calculée est proche de 100, plus le taux de fiabilité implicite augmente.
On doit calculer 2 notes :
• Une note sur l'orientation des prises de vues (photos).
· Une note sur la fiabilité de la géolocalisation.
Le taux de fiabilité implicite correspond donc à la moyenne des 2 notes précédemment décrites :
ftfote Qàeat. Photo + Hot* type <fe Géofoc.
Taux de fiabtiité implicite ■
c) Calcul de la note finale
A partir des 2 notes : taux Explicite et taux Implicite, on calcule la note finale.
L'Administrateur de l'autorité défini des coefficients pour chacun de ses 2 taux. Puis on calcule la note finale en fonction de ces 2 valeurs :
Coeff :E * TFE■÷ Caefi * TF!
Note finale =
Coeff.E + CoefcJ
Lien vers les événements Secondaires
Un événement primaire peut donc être lié à 0 ou plusieurs événements secondaires.
Pour un événement « Primaire », on accède donc à la liste des événements « Secondaires » au travers d'un tableau.
On aura donc dans ce tableau, les propriétés directes et on accédera aux propriétés indirectes par la méthode des actions « Formulaire qui s'intègre dans les lignes du tableau.
Une action particulière (suite à une action volontaire d'un opérateur) permettra de modifier un événement « Secondaire » en « Primaire » :
o À partir de ce moment, l'événement devenant « Primaire », il perd sa relation avec le précédent événement « Primaire ».
o II quitte le tableau et devient un élément « Primaire » avec une note finale = 0. o Quel que soit son précédent statut, il prend le statut : « A TRAITER ».
o On garde l'information sur le fait qu'un opérateur à modifier le type de cet événement.
Demande d'informations complémentaires
Cette fonctionnalité permet pour un événement particulier, d'envoyer sur des équipements identifiés (terminaux des utilisateurs par exemple) une demande d'informations complémentaire.
L'Administrateur définit un rayon pour lequel il désire atteindre les équipements.
En fonction de la valeur du rayon, le système lui indique le nombre d'équipements qui sont potentiellement dans la zone.
Lorsque la demande est envoyée, elle contient les informations suivantes :
Date et heure de la demande d'informations complémentaires
Type de l'événement primaire
Coordonnées de l'événement « Primaire »
Texte explicatif saisi par l'opérateur.
Ces informations permettront de pré-remplir le formulaire dans les équipements adéquats ; chacun des citoyens recevant cette demande, pourront donc ajouter de l'information :
o Plus de description
o Photos
Automatiquement, ces événements déclarés par le citoyen sont de type « Secondaire » et associés à l'événement primaire initial.
On détaille dans ce qui suit l'algorithme de regroupement et la méthode de calcul des notes :
ETAPE 1 : ON RECHERCHE S'IL EXISTE DES EVENEMENTS « PRIMAIRES POTENTIELS Pour une déclaration d'événement, on recherche dans la base de données s'il existe une liste d'événements de type « Primaire » possédant comme caractéristiques :
• Le même type (catégorie, type, sous- type, etc ..)
· Possédant une date telle que :
[NOW] - [Date du statut « A TRAITER »] < [valeur de la période]
• Possédant une Géolocalisation telle que :
[Le calcul de la distance] < [Valeur du rayon]
Le résultat de cette recherche sera interprété de cette manière
Résultat de la requête est vide : Résultat de la requête non vide :
Aucun événement primaire ne Un événement primaire correspond correspond. aux critères.
Le nouvel événement est donc On ne peut pas définir le type automatiquement typé « PRIMAIRE » immédiatement, le calcul de la note est indispensable.
Attention : si un résultat existe, celui- ci doit être unique. Dans le cas contraire, c'est qu'il existe une incohérence dans les données : l'Administrateur doit en être informé immédiatement (email).
Pas de calcul de note finale. Calcul de la note finale nécessaire.
Celle-ci est automatiquement égale à 0
Les notes explicites sont déterminées par la formule :
Note explicite = 100 - 100 * période ou rayon de survenue de l'Evénement / période ou rayon défini
Note explicite Période ou Rayon
Période ou Rayon de survenue de V Evénement
= 100 - 100 x n , . j ^ 7 -.
Période ou Rayon définie
ex : a. Prenons un exemple d'une Période définie sur 48 heures. Si l'événement est déclaré 30 heures après l'événement « Primaire », alors, la note est calculée comme suit :
30
Note explicite Période = 100 - 100 x— = 37%
48
b. Prenons un exemple d'une Période définie sur 48 heures. Si l'événement est déclaré 5 heures après l'événement « Primaire », alors, la note est calculée comme suit :
5
Note explicite Période = 100 - 100 x— = 90%
48
c. Prenons un exemple d'un Rayon défini à 25 mètres. Si l'événement est déclaré à 20 mètres de la géolocalisation de l'événement « Primaire », alors, la note est calculée comme suit :
20
Note explicite Rayon = 100 - 100 x— = 20% d. Prenons un exemple d'un Rayon défini à 25 mètres. Si l'événement est déclaré à 7 mètres de la géolocalisation de l'événement « Primaire », alors, la note est calculée comme suit :
7
Note explicite Rayon = 100 - 100 x— = 72%
Le taux de fiabilité explicite correspond à la moyenne des 2 notes « Rayon » et « Période » précédemment décrite :
NotePériû îe + Hoteftsycm
Taux, de fiabilité explicite =
Exemple, en prenant les exemples ci-dessus, en combinant les différents résultats, on aurait les valeurs suivantes :
CALCUL DU TAUX DE FIABILITE IMPLICITE
Le calcul de ce taux s'applique sur 2 valeurs.
Le principe : plus la valeur calculée est proche de 100, plus le taux de fiabilité implicite augmente.
On doit calculer au moins une note : • Une note sur la fiabilité de la géolocalisation.
Il existe 4 types de géolocalisation :
o GPS EQUIPEMENT
o GPS_BTS
o GPS_CARTO
o QRCODE
Pour chacun de ces types, l'Administrateur de l'autorité indiquera des valeurs permettant de définir la fiabilité de la Géolocalisation en fonction du type.
On aura donc par exemple des valeurs définies de cette manière :
Si la géolocalisation est effectuée par un type GPS_EQUIPEMENT, alors la note sera fixée à 90,
Si la géolocalisation est effectuée par un type GPS_BTS, alors la note sera fixée à 40,
Si la géolocalisation est effectuée par un type GPS_CARTO, alors la note sera fixée à 60,
Si la géolocalisation est effectuée par un type GPS_QRCODE, alors la note sera fixée à 100. · et éventuellement, une note sur l'orientation des prises de vues (photos).
Cette note sera calculée uniquement si des valeurs existent :
L'événement Primaire doit posséder des photos et des valeurs concernant l'orientation de ces photos.
L'événement à classifier doit lui aussi posséder des photos et les valeurs associés sur l'orientation.
Si aucune de ces conditions n'est respectées, le calcul de la note ne peut pas avoir lieu, et de fait, cela ne rentre pas en compte dans le calcul de la note implicite (et donc globale) Le taux de fiabilité implicite correspond donc à la moyenne des 2 notes précédemment décrites : tilote Orient. Photo + ''foie type de Geoksc
Tau* de fiabilité implicite =
Exemple, en prenant les exemples ci-dessus, en combinant les différents résultats, on aurait les valeurs suivantes :
CALCUL DE LA NOTE FINALE
A partir des 2 notes : taux Explicite et taux Implicite, on calcule la note finale.
L'Administrateur de l'autorité défini des coefficients pour chacun de ses 2 taux : Puis on calcule la note finale en fonction de ces 2 valeurs :
C∞ff.£ '' TFE ÷ Caef.i * TFÎ
Note finale =
Coeff.E ÷ Ceeff.î
Exemple, en prenant les exemples ci-dessus, en combinant les différents résultats, on aurait les valeurs suivantes :
Période de résolution
Elle correspond au temps imparti à l'autorité pour traiter l'événement. Ce délai est défini pour chaque type d'événement. Il correspond à la valeur « Période » utilisée par l'algorithme de regroupement.
Le délai démarre à partir du moment où l'événement est dans le statut : « A TRAITER » ou « PRIS EN COMPTE »
Pour un événement, en fonction de son statut, celui-ci pourra être répertorié:
o Dans le délai,
o Hors délai
On affichera sur le terminal de l'Autorité, une représentation de ce délai avec le temps qu'il reste, ou inversement, le temps passé après le délai.
Sévérité - Priorité d'un Evénement signalé
En fonction du type d'Evénement signalé (dangereux pour la population ou non), du nombre de signalements d'Evénements secondaires pour un Evénement primaire, ou encore de l'identité de l'utilisateur ou de l'entité ayant signalé cet Evénement, l'on pourra déterminer un degré de sévérité pour l'Evénement considéré (par exemple compris entre 1 et 10) et un affichage d'alerte pour l'Evénement en question sur le terminal de l'Autorité au sein de laquelle il a été signalé.
Par exemple, cet Evénement pourra apparaître avec une couleur dépendant de la sévérité qui lui aura été attribuée, avec un signal visuel (affichage clignotant de l'Evénement) ou sonore (alarme).
Les Evénements avec un degré de sévérité important pourront apparaître de façon prioritaire sur la liste des Evénement s'affichant sur le terminal de l'Autorité. L'application de ce degré de sévérité pourra s'effectuer par l'opérateur dédié à la gestion du terminal de l'Autorité, ou de façon automatique grâce à un algorithme prévu à cet effet. Fonction urgence
Un objet informatique permettra de déclarer un Evénement à un service de sécurité national type police national, Samu, pompier, ou de la ville type commissariat municipal. Citoyen à l'origine de la déclaration
Un lien entre l'objet « Evénement » et l'objet « Citoyen » est conservé.
On peut donc à tout instant connaître le citoyen à l'origine de l'événement.
A partir d'un événement, on pourra afficher les informations du citoyen :
• Nom
· Prénom
• Email • Photo
Equipement à l'origine de la déclaration
Il existe un lien entre l'équipement (l'équipement mobile : IPhone, Android, Wphone) et le citoyen.
Un citoyen peut utiliser plusieurs équipements.
Un événement est créé par un citoyen, à partir :
• d'un équipement mobile ou
• depuis le formulaire du site Web.
A partir d'un événement, on pourra afficher les informations de l'équipement :
• ID
• Type d'équipement (IPhone, Android, Wphone)
Degré de confiance, de crédibilité - Récompense
Un historique des Evénements signalés par chaque utilisateur permet de connaître pour chacun son ancienneté, le nombre de signalement d'Evénements qui ont été confirmés par d'autres utilisateurs, la nature des Evénements signalés (dangerosité)...
En fonction de ces données, un utilisateur se voit attribué un degré de confiance, ou des points de crédibilité par exemple calculé par un algorithme, et noté de 1 à 10.
Les points
Les points associés à la déclaration d'un événement de type primaire seront affectés à l'événement.
Un paramétrage global par autorité permettra de définir le nombre de points pour un événement déclaré de type Primaire et de type Secondaire.
On aura donc 2 paramètres
• NBPOINTS_PRIMAIRE (de 0 à 10).
• NBPOINTS SECONDAIRE (de 0 à 10).
Un autre paramètre permettra de définir si l'autorité utilise ou pas le système d'attribution des points :
• SERVICE_POINTS : OUI/NON.
Règles d'attribution des points :
1 .A chaque déclaration d'un événement, le nombre de points définis par les paramètres est ajouté à cet événement.
2. Il n'y a pas besoin de validation de la part d'un utilisateur de l'autorité. Les points sont automatiquement associés à l'équipement.
3. En revanche, l'utilisateur de l'entité peut au cas par cas, ajouter ou supprimer des points à l'événement.
4. Si un événement typé Primaire devient Secondaire (ou inversement) par action de l'utilisateur, alors les points sont réattribués. Par exemple :
Pour une collectivité, les valeurs pour les paramètres sont :
· NBPOINTS PRIMAIRE = 10
• NBPOINTS SECONDAIRE = 2
Un citoyen déclare un événement de type : « Défaut de signalisation routière / Feux tricolores ».
Si après traitement, l'événement est :
· De type Primaire, celui-ci se voit attribuer 10 points.
• De type Secondaire, celui-ci se voit attribuer 2 points.
Mais l'utilisateur en charge du traitement de l'événement possède le droit de modifier cette attribution de points. Il devra donc saisir une nouvelle valeur dans la fiche associée à l'événement puis « Valider ».
Ce degré de confiance pourra être pris en compte dans le calcul de la sévérité d'un Evénement signalé (voir ci-dessus) et ainsi pour évaluer la priorité de l'Evénement signalé.
Ce degré de confiance, ou ces points de crédibilité pourra permettre la délivrance de récompenses, telles que des chèques cadeaux, en lien avec l'Autorité à laquelle l'Utilisateur est abonné (par exemple, une réduction sur le montant de l'abonnement annuel à la piscine municipale).
Idéalement, dans le but d'éviter une utilisation abusive de l'application selon l'invention, par un utilisateur désirant artificiellement augmenter son degré de confiance, la récompense pourra prendre la forme d'un avantage attribué à un tiers (par exemple un chèque à l'attention d'une association de la municipalité) et non à l'utilisateur lui-même.
Egalement, toujours dans le but d'éviter à des utilisateurs vénaux de déclarer des Evénements en nombre pour augmenter leurs chances d'obtenir une récompense, en créant une multitude de comptes d'utilisateur afin de confirmer en nombre un Evénement déclaré à partir d'un compte principal, il est prévu de pouvoir vérifier si plusieurs comptes d'Utilisateur crées correspondent bien à des terminaux différents, par exemple grâce à un identifiant du terminal de l'utilisateur qui sera enregistré en lien avec le premier compte d'utilisateur crée à partir de ce terminal. En fonction de l'identité de l'Utilisateur, le degré de confiance ou les points de crédibilité accordés pourront être plus importants. C'est notamment le cas lorsque l'Utilisateur est reconnu comme un Agent de confiance (un agent technique de la ville par exemple) ou comme un Utilisateur au degré de confiance élevé. Si au contraire, un Utilisateur s'avérait nuisible pour le bon fonctionnement du service, d'après par exemple le caractère farfelu des Evénements ou la teneur des messages qu'il associe à ces Evénements (à caractère raciste, pornographique, contraires à l'ordre public .) un message pourra être émis par une Autorité pour l'inviter à améliorer la qualité de ses signalements. A défaut, cet Utilisateur pourra être banni de la communauté.
L'enregistrement d'un identifiant pour le terminal de l'Utilisateur banni permettra d'éviter qu'il crée un autre compte sur le même terminal après avoir été banni. Par ailleurs, un outil informatique de reconnaissance pourra être prévu pour analyser les captures d'image ou les vidéos accompagnant le signalement d'un Evénement et supprimer celles représentant un individu d'une façon permettant son identification. Un message pourra être adressé à l'utilisateur lui rappelant qu'aucune donnée de ce type n'est acceptée par le service. Une alternative sera l'utilisation d'un outil informatique permettant de brouiller tout visage identifié sur une capture d'image ou une vidéo.
Synchronisation - problèmes de réseau:
Chaque Evénement est enregistré localement sur le terminal de l'Utilisateur, et lorsque ce dernier est en mesure de communiquer avec le serveur, également sur ce serveur.
Ainsi, en cas d'absence de réseau, la création d'un Evénement reste possible et celui-ci est stocké sur le terminal pour être communiqué au serveur ultérieurement.
La synchronisation des Evénements à signaler et stockés sur le terminal de l'utilisateur, et des Alertes stockées sur le serveur et à transmettre au terminal de l'utilisateur s'effectue dès que le terminal est connecté à un réseau.
L'application téléchargée sur le terminal pourra permettre l'envoi d'une notification lorsqu'une absence de réseau est détectée avec la géolocalisation de la perte du réseau, afin d'avertir une Autorité de la présence dans son périmètre d'une zone d'absence de réseau, ou de la survenue d'un problème de réseau, problème pouvant être transmis au service compétent de l'Autorité, ou à un service externe à celle-ci tel que le service d'un fournisseur national de réseau.
Gestion par les Autorités
Au niveau du terminal d'une Autorité, les événements signalés sont regroupés par sous groupe en fonction des services de l'Autorité et communiqués de façon automatique au service considéré.
Le terminal d'un Utilisateur communique à une fréquence donnée sa géolocalisation au serveur (par exemple toutes les 15 mn) et reçoit les Alertes émanant de l'Autorité considérée, tant que la dernière position de géolocalisation est située dans le périmètre de l'Autorité considérée.
Lorsque la géolocalisation du terminal de l'Utilisateur le positionne en dehors du périmètre géographique d'une Autorité qu'il vient de quitter, il en est averti par une Notification (« Vous venez de quitter Le Perreux sur Marne, Bienvenue à Neuilly sur Marne ») et peut se voir proposer :
- de continuer à recevoir les Alertes de l'Autorité qu'il vient de quitter,
- de commencer à recevoir les Alertes de l'Autorité qu'il vient de rejoindre, si celle-ci adhère au service, et dans la négative, d'envoyer un message à cette
Autorité pour l'inciter à adhérer au service
Un historique des Evénements signalés dans le périmètre d'une Autorité permettra de proposer à un Utilisateur désirant signaler un nouvel Evénement dans l'Autorité concernée, de se voir proposé, dans l'interface de saisie d'un nouvel Evénement, une liste des différents Evénement déjà signalés.
REGLES DE SUPPRESSION D'UN EVENEMENT PAR LE CITOYEN
Le citoyen à l'origine de la création d'un événement reste le « propriétaire » de cet événement.
II peut donc à tout instant décider de le supprimer entièrement ou en partie.
SUPPRESSION OU MODIFICATION PARTIELLE
Le citoyen peut modifier ou supprimer certaines informations associées à l'événement.
II peut donc modifier les informations suivantes :
• Le taux de gravite
• La description
Les autres propriétés de l'événement (son type, sa géolocalisation, etc.) ne sont pas modifiables par le Citoyen.
En ce qui concerne les photos, le Citoyen peut :
• Les supprimer : il s'agit vraiment d'une suppression physique : le fichier est supprimé du serveur
• En ajouter, si les 3 emplacements photos disponibles ne sont pas utilisés.
SUPPRESSION TOTALE
La suppression totale implique pour le citoyen que cet événement n'existe plus. Il ne pourra donc plus apparaître dans sa liste « Mes événements ».
Mais cet événement reste disponible pour l'Autorité qui en a la charge, avec les modifications suivantes :
• Le lien vers le Citoyen qui en est à l'origine n'existe.
• Et donc le lien vers l'équipement n'existe plus.
• Les photos sont physiquement supprimés (car pour le citoyen, il a vraiment supprimé l'événement et donc les photos associées).
Pour un utilisateur de l'Autorité, cet événement apparaîtra toujours dans le tableau des événements, mais il sera représenté avec une particularité (couleur spécifique de la ligne par exemple) pour que l'utilisateur identifie immédiatement que le Citoyen à supprimer cet événement.
L'utilisateur de l'autorité aura le choix de traiter cet événement ou de le clôturer si celui-ci n'est plus pertinent.
Gestion des Autorités par l'Administrateur global
L'Administrateur global est dédié à la gestion des différentes Autorités et des différents utilisateurs. Il possède un terminal doté d'une interface de gestion de ces Autorités.
Cette interface permet d'accéder à l'interface de chaque Autorité et d'y intervenir comme l'Autorité elle-même, et de créer un nouveau compte pour une nouvelle Autorité.
Cette interface permet également la visualisation de différentes cartographies de différentes Autorités sur lesquelles les Evénements signalés sont repérés par signe, cliquable afin de connaître le détail de l'Evénement considéré.
Cette interface est reliée à une source d'information sur les cadastres des différentes villes ou cantons d'un territoire, mise à jour régulièrement, et permet, lorsqu'une nouvelle Autorité veut s'abonner au service, de délimiter automatiquement à partir du code postal de la ville ou canton, d'un périmètre sur une carte.
Si une ville veut s'abonner, elle renseigne les différents Evénements qu'elle autorise un Utilisateur à déclarer, renseigne des identifiants pour les différents services susceptibles de traiter ces Evénements, et des adresses emails ou des liens vers ceux ci permettant de leur pousser les Evénements signalés, ainsi que les différents paramètres du systèmes (paramètres de regroupements, degré de confiance).
Cette interface permet non seulement l'introduction d'une nouvelle Autorité dans le système mais aussi celle d'un système d'information extérieur, tel qu'un système d'information gouvernemental (par exemple : Police national pour les Alertes enlèvement).
En effet, à chaque Autorité, l'Administrateur global pourra proposer les Alertes d'un système d'information extérieur. [0027] Localisation d'une Alerte
[0028] L'Alerte est obligatoirement associée à un périmètre géographique et diffusée aux Citoyens présents dans ce périmètre.
La notion de géolocalisation pour une Alerte est donc double :
1 . Il faut tout d'abord définir le périmètre géographique associé à la diffusion de cette Alerte : Par défaut, il s'agira du périmètre sur lequel s'étend le pouvoir d'une autorité (Par exemple pour une commune, il s'agira du périmètre du territoire communal).
L'Opérateur aura aussi la capacité de modifier ce périmètre :
a. Digitaliser spécifiquement un périmètre (pour une Alerte qui serait uniquement diffusée dans le centre-ville par exemple)
b. Sélectionner des territoires adjacents (pour une Alerte diffusée sur une commune, et les communes environnantes).
Le périmètre géographique de diffusion de l'alerte est indépendant du lieu courant de localisation du terminal de l'Autorité par lequel sont émises des Alertes.
2. L'Alerte est diffusée uniquement aux Citoyens présents dans le périmètre défini pour l'Alerte.
Cela implique donc que le système et le procédé selon l'invention connaissent à tout instant où se trouve réellement les Citoyens déclarés dans le système.
Autrement dit, la liste des Citoyens (et donc de leurs équipements) impactés par la diffusion d'une Alerte sera calculée par le système au travers d'une requête de type Géo-Spatiale qui en superposant les deux informations géographiques (périmètre de l'alerte et positions des différents équipements) en déduira le groupe de Citoyens à atteindre.
Par exemple, prenons une Alerte dont le périmètre de diffusion correspond à un cercle sur un territoire donné :
Conformément à la figure 7, on connaît à chaque instant la position de tous les Citoyens (équipements) déclarés dans le Service Alert-Phone (étoiles blanches à contour noir).
Une Alerte est créée. Le périmètre de diffusion de cette Alerte correspond à un cercle tel que représenté sur la figure 8 (Choix de l'Opérateur). Conformément à la figure 9, le système, au travers d'une requête Géo-Spatiale définit la cible des Citoyens (équipements) pour lesquels l'Alerte sera diffusée (étoiles noires).
Les autres Citoyens n'étant pas dans le périmètre de l'Alerte ne seront pas notifiés de celle-ci.
[0029] En plus de la réception d'Alertes sur une zone géolocalisée, le Citoyen pourra choisir de s'abonner aux alertes d'une ou de plusieurs Collectivités. Il recevra ainsi les Alertes correspondantes même si ce dernier n'est pas localisé dans la zone de diffusion de l'Alerte.
[0030] Récompense du Citoyen
[0031] Un système d'obtentions de points sera mis en place pour rendre attractif le service et récompenser le Citoyen actif.
[0032] Le principe de base est que pour tout nouvel Evénement déclaré, l'utilisateur reçoit des points.
[0033] La validation de l'acquisition des points sera réalisée par l'Opérateur en charge du traitement de l'Evénement.
[0034] Pour un Evénement de type « Primaire », le Citoyen reçoit des points
[0035] Pour un Evénement de type « Secondaire », aucun point ne sera octroyé, sauf si l'Opérateur trouve pertinent les informations associées (meilleure description de l'Evénement, ou photos et vidéos pertinentes).
[0036] Si les informations recueillies au sein des différents Evénements sont jugées insuffisantes par l'Opérateur pour traiter l'Evénement, ce dernier aura la possibilité d'émettre une demande d'information complémentaire à tous les usagers ayant signalés l'Evénement. La demande d'information complémentaire s'appuiera sur la fonction d'émission d'Alerte par sélection des Citoyens ayant transmis l'Evénement (primaire ou secondaires).
La fourniture d'information complémentaire pourra être assujettie au gain de points.
[0037] Les points gagnés par les Citoyens seront exploitables par la Collectivité par différents moyens (présentation des citoyens les plus actifs, récompenses officielles, échange des points contre des services de la Collectivité...). Selon l'usage de ses points, un traitement de la valeur des points acquis sera possible par usager par la Collectivité. GESTION DES EVENEMENTS PAR SERVICE
La notion de service correspond à un cloisonnement nécessaire à la gestion des événements créés.
L'Administrateur de l'Autorité possède la capacité de déclarer des services.
Puis de définir les relations entre la nomenclature des événements et les services.
Règles de liaisons
1 . Une Autorité possède au moins un Service. Il faudra donc créer un Service par défaut lorsque l'Administrateur INEO créera une Autorité : il s'agira du Service « Administration Autorité » qui contiendra au moins un utilisateur : l'Administrateur de l'autorité.
2. Un utilisateur de l'autorité appartient à un ou plusieurs services.
3. Un type d'événement est associé à un ou plusieurs services. De ce fait, un utilisateur verra dans les différentes fonctionnalités (tableau de gestion, sur la carte, etc.) tous les événements dont les types sont associés aux services auxquels il appartient.
[0038] Gestion de l'historique
Au titre de l'invention, il est prévu une gestion globale de l'historique des actions réalisées par les intervenants dans le système.
Cela veut dire que toutes les actions réalisées par les différents acteurs (Citoyens, Opérateurs, Administrateurs) sont identifiées et sauvegardées.
En fonction de la gestion des droits associés à chacun, l'affichage de cet historique des actions sera filtré et présenté aux différents types d'acteurs.
[0039] Architecture technique envisagée
Le système et procédé d'échange d'informations Alert-Phone est une solution logicielle en mode SaaS (Software As A Service) qui regroupe les applications suivantes :
ALERT-PHONE-SMART : Application cliente gratuite dédiées aux Smartphones (pour le Citoyen).
ALERT-PHONE : Application WEB de type portail destinée aux utilisateurs de tout type. ALERT-PHONE-COLLECTIVITE : Application WEB à destination des collectivités (configuration, gestion, traitement de l'information et des services associés).
ALERT-PHONE-ADMIN : Application WEB d'Administration globale à destination des Administrateurs du service (personnels du déposant).
ALERT-PHONE-WEBSERVICE : Méthodes Web Service d'interopérabilités qui seront consommées par des applications externes.
Conformément à la figure 1 1 , le service Alert-Phone est composé au niveau FrontOffice des interfaces suivantes :
Application pour Smartphone : ALERT-PHONE-SMART
• Site Web grand Public : ALERT-PHONE qui sera lui-même décomposé en espace privatif :
o L'espace privatif pour le Citoyen
o Les espaces privatifs pour les collectivités : ALERT-PHONE- COLLECTIVITE
• Un site Web privé (qui ne sera pas forcément accessible depuis internet) pour l'Administrateur global.
Le backoffice est composé de serveurs Web Applicatifs qui prendront en charge les composants suivants :
• Une couche d'interopérabilité (WebServices) qui sera utilisée par le FrontOffice du Service Alert-Phone. Cette même couche de WebServices pourra être utilisée par des applications externes.
Un ou plusieurs serveurs d'applications Web qui seront parallélisés en fonction de la charge globale (sollicitation du système).
Un système de gestion de base de données et de stockage de fichiers (Photos, vidéos).
DETAILS DES INTERFACES
[0040JCOTE UTILISATEUR : APPLICATION POUR TELEPHONE MOBILE
[0041] L'application pour terminal mobile, permettra au Citoyen de s'identifier en créant un profil, de s'abonner au service, de sélectionner des villes dont il souhaite recevoir des Alertes, de sélectionner le type d'Alertes qui l'intéresse (Alerte météorologiques, accident de circulation, fermeture d'une école...), de déclarer les Evénements et de recevoir des Alertes.
[0042] A travers l'application pour téléphone mobile, le Citoyen pourra déclarer un Evénement et ses données associées : Choix du type d'Evénement
Géolocalisation de l'Evénement
Commentaires ou informations supplémentaires
Photos
Vidéos
Degré d'urgence (note subjective du Citoyen)
[0043]Toutes ces informations associées à l'Evénement créé par le Citoyen sont la propriété du Citoyen déclarant. Il possède donc un droit de modification et de suppression à tout instant sur cet Evénement.
[0044] Il peut associer au signalement d'un Evénement, différents médias tels qu'une photo ou une vidéo. Dans ce cas, une option permettant le masquage dynamique des visages pourra être prévue.
[0045] Les fonctions associées à ce masquage seront établies suivant les cas suivants :
- L'Opérateur, c'est-à-dire la collectivité recueillant le signalement, peut activer ou non le masquage lorsqu'il visualise les médias associés (ou en fonction de droits associés à l'Opérateur)
- Le Citoyen aura la capacité de rendre le masquage soit dynamique soit permanent
[0046] Le Citoyen peut en outre supprimer :
- Les documents attachés à son Evénement : Photos et vidéos. Ces documents seront réellement supprimés de la plateforme où ils sont stockés. Personne (Administrateur, Opérateur) ne peut les consulter après cette opération de suppression.
- Un Evénement : dans ce cas, cet Evénement disparait des listes du Citoyen, mais celui-ci reste présent dans le système (dans la plateforme) pour traitement (si besoin). Tous liens entre l'Evénement et le Citoyen sont alors supprimés, il sera impossible de faire un lien entre l'Evénement et le Citoyen l'ayant initialement déclaré.
Il sera typé « Supprimé », pour que l'Opérateur soit conscient de cet état. Il ne pourra donc plus communiquer expressément sur cet Evénement (avec le Citoyen déclarant ou d'autres Citoyens). Impossible donc de demander plus d'informations sur cet Evénement.
[0047]Cette application pour Smartphone devra être développée notamment pour les OS suivants :
• IOS : iPhone®
ANDROID®
• Windows® Phone (W8) [0048]Chaque application (la partie FRONT et utilisation des API du téléphone) sera développée en utilisant les technologies propres à chaque environnement, mais utilisera des WS identiques qui seront eux développés coté Serveur : Java J2EE. Dans la mesure du possible, du code JavaScript commun aux 3 environnements sera utilisé.
[0049] En pratique, le Citoyen désireux de mettre en œuvre le système selon l'invention doit installer l'application sur son Smartphone. L'utilisation de cette application nécessite forcément une authentification :
• Le Citoyen doit être déclaré comme utilisateur du service · Le Citoyen doit s'authentifier et déclarer son équipement pour accéder aux fonctionnalités de l'application.
• Seule la fonctionnalité de notification d'Alertes (Réception d'une Alerte) est active sans authentification.
[0050] Formulaire d'inscription de l'utilisateur
Puisque l'authentification est obligatoire, un nouvel utilisateur peut se déclarer auprès du service à partir de cette application.
Ce formulaire peut potentiellement être relativement court (en tous cas plus court que celui du portail web ALERT-PHONE détaillé par la suite). L'utilisateur pourra ultérieurement ajouter d'autres informations sur son compte.
Le processus d'inscription demande à l'utilisateur de saisir un code reçu par SMS, cela afin de valider la création et l'activation du compte.
[0051] Formulaire de déclaration d'un terminal mobile
[0052] Un Citoyen peut posséder plusieurs téléphones ou tablettes. Dans ce cas, un formulaire lui permet de déclarer plusieurs équipements. Il sera donc reconnu comme Citoyen unique quel que soit le terminal mobile utilisé.
[0053] Formulaire de connexion/déconnexion
[0054] La connexion est obligatoire pour accéder aux fonctionnalités du service après avoir rempli le formulaire de connexion. La déconnexion de l'utilisateur se fait au travers du formulaire déconnexion qui, une fois validé, ne permettra plus à celui-ci d'accéder aux fonctionnalités.
[0055] Page « Accueil », personnalisation de l'application
[0056]Au lancement de l'application, un contrôle est réalisé entre les collectivités auxquelles adhèrent le Citoyen, et la position géographique ou il se trouve réellement (Géolocalisation). [0057] Les cas suivants seront gérés :
• Si le Citoyen se trouve réellement dans une collectivité supportant le Service, l'application est personnalisée (Logo, nom de la collectivité, charte graphique, etc.).
• Si le Citoyen se trouve dans une collectivité ou zone géographique non adhérente au service Alert-Phone, alors l'application le notifie de cette situation, et la page d'accueil sera une page par défaut. Dans ce cas, il pourra être prévu un bouton d'action qui proposera au Citoyen d'envoyer un message à la commune : « Voulez-vous signifier à la commune l'existence du service Alert-Phone ? »
[0058] Gestion de la géolocalisation
[0059]On propose au Citoyen de gérer lui-même la période avec laquelle l'application ALERT-PHONE-SMART remontera au service la position (géolocalisation) de son équipement.
[0060]A titre d'exemple, la remontée de cette information sera comprise entre 1 minute et 1 heure. Le traitement local (fonction de l'application ALERT-PHONE-SMART) est consommatrice d'énergie. Cela ne doit pas être réalisé au dépend de l'utilisation de l'équipement lui-même par le Citoyen.
[0061]A partir d'un certain seuil du niveau de la batterie, l'application ALERT-PHONE-SMART adaptera automatiquement la période d'envoi de la position de l'équipement pour ne pas solliciter la batterie dans ce contexte.
[0062] Lorsque le terminal est connecté au secteur et ne fonctionne plus sur batterie, la remontée de l'information de position (géolocalisation) s'active automatiquement sur un cycle court (toutes les 5 minutes par exemple).
[0063] Déclarer un Evénement
[0064] La principale fonction est bien que l'utilisateur remonte des Evénements. Toute une nomenclature d'Evénements (en fonction des services disponibles et paramétrés par la collectivité) sera présentée.
Un Evénement aura les propriétés suivantes :
• Information géographique (géolocalisation)
Informations alpha (texte, type, date, etc.).
• Photos associées (et orientations lors de la prise de vue)
Vidéos associées • Curseur qualitatif : l'utilisateur peut donner une note (de 1 à 5 par exemple), pour signifier la gravité du fait.
A l'issue de la déclaration de l'Evénement, l'utilisateur sera notifié :
• Evénement « primaire » avec potentiellement l'attribution de points.
• Evénements « secondaire » (Evénement déjà déclaré).
• Le cas échéant, les points acquis grâce à cet Evénement.
[0065] Demande d'informations supplémentaires
Dans le cas d'un Evénement secondaire, c'est-à-dire d'un Evénement préalablement déclaré, la collectivité peut demander aux utilisateurs des informations complémentaires.
Un utilisateur à l'initiative d'un Evénement « secondaire » pourra par ailleurs se voir attribuer des points si les informations remontées (photo, vidéo) sont pertinentes.
[0066] Souscrire aux abonnements (Souscrire aux collectivités)
Le Citoyen peut « s'abonner » pour recevoir les Alertes et adresser des Evénement d'une ou plusieurs collectivité(s) adhérente(s) au service de l'invention.
· Un formulaire dans lequel l'utilisateur sélectionne les collectivités.
• Une demande d'abonnement dynamique lorsque l'utilisateur suite à ses déplacements, arrive dans une collectivité qui possède ce type de service.
Le fait de s'abonner à une collectivité, permettra au Citoyen de :
• Déclarer des Evénements pour cette collectivité.
• Recevoir les Alertes émises par cette collectivité pour lesquelles le Citoyen s'est abonné. [0067] Recevoir les Alertes
[0068]Cette fonctionnalité est transparente pour le Citoyen, dans le sens où il recevra les Alertes du Service Alert-Phone générées par la collectivité dans laquelle il se trouve actuellement.
Le Citoyen recevra donc uniquement les Alertes qui répondent aux critères suivants :
• Le Citoyen se trouve dans le périmètre de diffusion de l'Alerte • De façon non obligatoire, le Citoyen a validé dans ses préférences, la volonté de recevoir des Alertes de ce type.
A noter que la réception d'Alertes n'est pas soumise à authentification. Le Citoyen peut être notifié d'une Alerte sans avoir renseigné le formulaire d'authentification. En revanche, pour consulter le contenu de cette Alerte, il devra s'authentifier dans l'application.
[0069] Consulter les Alertes
[0070] Le Citoyen consulte les Alertes actives dans la zone où il se trouve.
[0071] Média vidéo
Des fonctionnalités avancées seront associées à ce média :
- Enregistrer une vidéo, puis l'attacher à un Evénement et le déclarer.
- Réaliser une vidéo et en même temps envoyer ce flux sur les serveurs du service ALERT-PHONE. Cela permettra à des Opérateurs de la collectivité d'accéder en direct au flux vidéo.
[0072] Fonction « URGENCE » ou « SOS »
[0073] Fonction qui permet au Citoyen de créer un Evénement de type « SOS » par simple clic. La finalité est de fournir au Citoyen en situation d'urgence ou de stress, un moyen d'émettre le plus rapidement possible un Evénement pour alerter les services compétents (Pompier, Samu, Police, Gendarmerie, Police municipale, etc.). Lors de l'envoi d'un « SOS », un compte à rebours apparaît sur le terminal avant l'envoi effectif (10 secondes par exemple) afin de permettre au Citoyen d'annuler son « SOS » s'il s'agit d'une erreur.
[0074]Cet Evénement envoie la géolocalisation de la personne pour une identification plus précise de la situation.
[0075] Le choix du service compétent apte à traiter ces Evénements de type « SOS » sera bien sûr paramétrable par la collectivité par l'Opérateur administrateur.
[0076] Fonction « PIETON / VEHICULE »
[0077] Fonction qui permet au Citoyen d'activer explicitement dans l'application son mode de déplacement :
- PIETON : mode par défaut.
- VEHICULE : mode permettant au Citoyen d'activer la remontée automatique de SOS si un choc est identifié par le terminal. Dans ce mode, le Citoyen participe à la génération de données de trafic. [0078] En mode « VEHICULE », l'émission de « SOS » peut être déclenchée automatiquement sans action du Citoyen par exemple en cas de choc d'un usager en véhicule. La finalité est d'émettre le plus rapidement possible un Evénement pour alerter les services compétents (Pompier,
Samu, Police, Gendarmerie, Police municipale, etc.) lorsqu'un choc se produit. Pour cela cette fonction exploite les données d'accéléromètre fournies par un équipement interne au terminal afin d'émettre l'Evénement. Grâce au compte à rebours disponible lors de l'émission d'un « SOS », le Citoyen peut annuler une fausse alerte avant son émission effective.
[0079] Lorsque le terminal se déplace à une vitesse supérieure à un seuil (30 km/h par exemple), le terminal s'identifie automatiquement en mode « VEHICULE » afin de consolider les données de trafic. Lorsque la plateforme identifie des terminaux sur des zones autoroutière prédéfinies (autoroutes par exemple), les terminaux sont implicitement basculé en mode « VEHICULE ».
[0080] La vitesse de déplacement d'un Citoyen est déterminée par un équipement interne au terminal ou par calcul depuis la plateforme selon les points de géolocalisation, l'horodatage de ces points et la topologie urbaine du lieu.
[0081] Les données de trafic et les avaries ainsi récoltées sur les voies routières peuvent être utilisées par la Collectivité et/ou les services compétents pour remédier à des situations et pour informer les Citoyens.
[0082] COTE UTILISATEUR : APPLICATION SUR SITE WEB
[0083] L'application disponible sur le site web comprendra les fonctionnalités ci-dessus décrites pour l'application pour téléphone portable, et présentera de manière globale le procédé. La page d'accueil est donc globale (il n'y a pas à ce stade de différenciation des collectivités locales qui adhèrent au service, et le grand public).
[0084] Ce site web (plusieurs pages selon le contenu) devra informer le public sur le service, les collectivités qui y adhèrent, etc .. La première page pourra contenir par exemple :
• Un lien vers des pages descriptives : « Je suis un Citoyen »
• Un lien vers des pages descriptives : « Je suis une collectivité »
[0085] Ensuite des liens permettront d'afficher des pages spécifiques (en termes de présentation et de contenu informatif) vers chaque collectivité et les services associés. [0086] Les pages associées aux collectivités pourront être présentées selon un:
• Mode par défaut : Inscrire leur contenu de présentation dans un cadre déjà « formaté » du portail ALERT-PHONE avec une personnalisation en termes de charte graphique et de données présentées.
• Mode Optionnel : Créer un site spécifique de présentation si volonté de la collectivité.
[0087] Déclarer un Evénement
[0088] Il s'agit de la même fonctionnalité que celle détaillée dans l'application ALERT-PHONE-SMART. A la différence, que la déclaration se fait depuis un poste fixe ; les médias (photos, vidéos) seront donc « uploader » à partir d'une sélection de fichiers. Idem pour la géolocalisation, l'utilisateur (s'il le désire) aura la possibilité de géolocaliser l'Evénement en sélectionnant sur une carte l'emplacement adéquat.
[0089] Mes Alertes
[0090]Cette fonction regroupe l'ensemble des Alertes émises par les collectivités auxquelles l'utilisateur adhère. L'utilisateur peut accéder à l'ensemble des Alertes émises. A ce stade, une « collectivité » pourrait être de type national et donc diffuser les Alertes qui impactent le territoire national. Ou une collectivité qui diffuse une Alerte sur son territoire, pourrait aussi diffuser sur des territoires adjacents si le risque sort de son propre territoire initial. Dans ce cas, même si l'utilisateur n'a pas adhéré explicitement à la collectivité, il reçoit tout de même l'Alerte.
[0091] Mes adhésions aux collectivités
[0092]Cette fonction permet à l'utilisateur de sélectionner les collectivités adhérentes au Service, pour lesquelles il souhaite recevoir les Alertes ou émettre des Evénements. Le choix ne pourra se faire que parmi les collectivités qui adhérent au Service Alert-Phone. Dans le cas d'une adhésion dynamique depuis son Smartphone, la collectivité retrouvera donc la liste des adhésions.
[0093] Cartographie des Evénements
[0094] L'utilisateur visualise sur la carte ses propres Evénements. Il pourra donc y accéder par sélection directe sur la carte.
[0095] Dans des pages « Grands Public », figurera une synthèse globale des Evénements reportés. Il ne sera pas possible à partir de ces informations de « remonter » vers un Evénement unique contenant les informations personnelles du déclarant. [0096] C'est une présentation anonyme de la base des Evénements dans le but de montrer le dynamisme du service.
[0097JSITE WEB ESPACE GRAND PUBLIC
[0098]C'est le site Grand Public qui présente le service (aux futurs utilisateurs, mais aussi aux futures collectivités). A partir de ce site, on accède :
• Aux pages globales de présentation du Service Alert-Phone (« Je suis un Citoyen », « Je suis une collectivité »).
• Aux pages globales de présentation des Evénements.
• Aux pages de présentation des collectivités adhérentes au service.
[0099]Aux synthèses de la base des Evénements (synthèse globales, par collectivité, par type d'Evénements, etc.).
[00100] Le site doit mettre en valeur le côté dynamique et acquisition en temps réel du service (nombre d'Evénements déclarés par jour, par semaines ; Nombre d'Evénements traités par les collectivités, indice de satisfaction, etc.) et l'importance de la communauté adhérente (utilisateurs et collectivistes). Il propose pour cela des indicateurs dédiés au Grand Public et aux Opérateurs.
[00101] Formulaire d'adhésion du Citoyen utilisateur
[00102] Ce formulaire permet au Citoyen de s'inscrire au Service Alert-Phone. On traitera dans cette fonction : « Mot de passe oublié, redéfinir un nouveau mot de passe »
[00103] Formulaire d'adhésion d'une collectivité
[00104] Ce formulaire permet à une collectivité d'adhérer au Service Alert-Phone. Dans un premier temps, ce formulaire pourrait ne pas exister, mais permettrait à la collectivité de prendre contact avec l'Administrateur pour mettre au point la partie contractuelle. L'ajout d'une nouvelle collectivité et son paramétrage sera réalisé dans l'application ALERT-PHONE-ADMIN.
[00105] Formulaire de connexion du Citoyen utilisateur
[00106] Permet au Citoyen d'accéder aux fonctions du service, et à la gestion de ses Evénements : partie privative du Citoyen.
[00107] Cartographie des Evénements
[00108] Conformément aux figures 10 et 1 1 , on affiche sur une carte, la localisation des Evénements, avec une précision dépendante du nombre d'Evénements en fonction du niveau de zoom. [00109] On associe à cette représentation des filtres, l'affichage des Evénements en :
• Fonction de la période (jour-mois-année)
• Fonction du type d'Evénement
· Fonction de l'état (traité, non traité, en cours, etc.)
[00110] COTE COLLECTIVITES : SITE WEB
[00111] Les collectivités quant à elles accèdent au système selon l'invention via une application web permettant la configuration, la gestion, le traitement de l'information et des services associés.
[00112] Le site web du système selon l'invention, possède donc des pages « privées » accessibles uniquement aux Citoyens déclarés, ainsi qu'aux utilisateurs des collectivités et de deux types différents :
[00113] · Espace privé pour le Citoyen
[00114] · Espace privé pour les Opérateurs d'une collectivité : C'est dans ces espaces privés, que les fonctionnalités de gestion du service Alert-Phone seront positionnées.
[00115] L'application « collectivité » a deux buts principaux :
• Permettre à la collectivité de paramétrer son service
• Permettre à la collectivité de gérer les Evénements remontés par les Citoyens.
[00116] Il est important de noter qu'en réalité, chaque collectivité aura son propre espace privé, pour gérer les spécificités de Service qu'elle désire mettre en œuvre dans son périmètre (type d'Evénements pouvant être signalés par exemple : « accident de circulation », « dégât des eaux » mais pas « voirie » lorsque la municipalité considérée n'en est pas pourvue.
[00117] Le système selon l'invention propose par défaut une bibliothèque de type d'Evénements à la collectivité, et l'Opérateur (par simple paramétrage) sélectionnera parmi ces types d'Evénements, ceux dont il souhaite recueillir un signalement, et qui apparaîtront dans la liste disponible sur le téléphone mobile du Citoyen ou l'interface Citoyen du site web. La collectivité en charge de cet Evénement accède à toutes les informations de cet Evénement déclaré par l'utilisateur. L'Opérateur aura en outre la capacité d'enrichir cette bibliothèque avec ses propres types d'Alerte. Tous ces types d'Alertes seront donc proposés à la collectivité, et l'Opérateur pourra créer une Alerte (diffusion de l'Alerte vers le Citoyen) à partir de cette bibliothèque.
[00118] A travers l'application sur téléphone mobile et le site web dédié, le Citoyen sera notifié de la présence d'une Alerte émise conformément au diagramme illustré sur la figure 2.
[00119] Cette Alerte aura donc les propriétés suivantes : 1. Type de l'Alerte (nomenclature de la bibliothèque)
2. Libellé et description de l'Alerte (prise en compte du multilingues).
3. Période d'activation (date de début, date de fin). La date de fin est optionnelle, ce qui veut dire que l'Alerte est Active sans limite de temps. Dans ce cas l'Opérateur devra donc « manuellement » désactiver l'Alerte lorsque celle- ci sera terminée.
4. Territoires et/ou collectivités concernées (gestion du cas ou l'Alerte peut sortir du périmètre de la collectivité).
[00120] Dans un premier temps, la zone concernée par l'Alerte correspondra à la surface de la collectivité concernée. Puis l'Opérateur, s'il le souhaite pourra définir (digitaliser) lui-même une zone géographique plus précise qui correspondrait à la zone réelle de l'Alerte (la zone d'impact).
[00121] Une autre fonctionnalité « Gestion de l'escalade » lui permettra de diffuser cette Alerte sur des territoires adjacents à son propre territoire. Dans ce cas un workflow permettra à chaque Opérateur des territoires concernés de valider la diffusion de cette Alerte. On pourra également prévoir un lien vers un ou plusieurs fichiers, comme par exemple un fichier PDF, qui seront affichés par les capacités propre du Smartphone.
[00122] Lorsque l'Alerte n'est plus active : Date de fin dépassée ou l'Opérateur désactive l'Alerte ; celle-ci disparait automatiquement de la liste des « Alertes émises » présentée dans le Smartphone du Citoyen ou dans son interface sur le site web dédié.
[00123] GESTION
Il s'agit des fonctionnalités permettant à la collectivité de gérer le système Alert-Phone.
Il existe 3 grandes catégories de fonctions :
• Les fonctions d'administration des Evénements liés à la collectivité.
• Les fonctions associées aux Alertes (définition et diffusion).
• Les fonctions de restitution des informations, rapports, indicateurs.
•
Gestion du Périmètre géographique
Cette fonction permet à une collectivité de définir géographiquement le périmètre dans lequel :
Les Evénements crées par le Citoyen seront géolocalisés. Les Alertes générées par la collectivité seront diffusées. Par défaut, pour une collectivité de type communal, ce périmètre géographique correspondra au territoire de la commune.
Ce découpage en communes, départements, régions sera déjà présent dans le Service Alert-Phone. La collectivité pourra ainsi directement sélectionner la surface adéquate.
En option, des outils de digitalisation permettront à d'autres types de collectivités ou d'autorités de définir graphiquement leur propre périmètre géographique dans lequel leur Service Alert-Phone sera opérationnel.
Gérer les services (notion de portail par service)
Permet de déclarer les services internes (Equipement, Voirie, Travaux, etc.) de la collectivité qui entre-autre, auront la charge de prendre en compte les Evénements déclarés.
• Déclarer un service (présentation, rayon d'actions, etc.)
• Gérer les utilisateurs de ce service : utilisateurs, profils, droits.
Gérer les options
Différentes options pourront être activées ou non
Options de présentation : Charte graphique, logo, nom, etc. Options sur la gestion des points
• Options sur le niveau de détail ou de présentation des résultats aux Citoyens, aux Grand Public.
Etc.
GESTION DES EVENEMENTS Gérer la base des Evénements
A partir de la bibliothèque globale des Evénements (Bibliothèque définie par l'Administrateur global du Service), l'Opérateur sélectionne les types d'Evénements qu'il désire proposer aux Citoyens de sa collectivité.
Pour chaque type d'Evénement sélectionné, l'Opérateur définie les paramètres suivants :
• Paramétrage de la fonction de dé-doublonnage :
o Définition du périmètre géographique (en mètre)
o Définition de la période (en heure)
• Modification du libellé et de la description de l'Evénement • Affectation du service qui sera en charge de traiter l'Evénement (service et/ou Opérateur).
Gérer des Workflow
Définition de Workflow dans la gestion de la prise en compte d'un fait : définition des états et des acteurs associés pour chacun des états.
Gérer les Evénements créés
L'Opérateur acquittera les Evénements qui lui sont destinés et les traitera. Cette opération d'acquittement est importante car elle sera remontée auprès du Citoyen qui a déclaré l'Evénement.
Une prise en compte rapide, et une clôture rapide (Evénement traité ou sans suite) permettra de créer un sentiment de satisfaction pour l'utilisateur (si un utilisateur s'aperçoit qu'il n'y pas de prise en compte, il n'aura plus la volonté de déclarer des Evénements).
GESTION DES ALERTES Gérer des types d'Alerte
Outre la bibliothèque globale des Alertes définies par l'Administrateur du Service (outil ALERT-PHONE-ADMIN), l'Opérateur a la capacité de définir ses propres types d'Alerte pré formatée. Par exemple, pour un type spécifique d'Alerte, la liste des consignes seraient déjà définie.
Définir une Alerte (créer une Alerte)
A partir de la bibliothèque globale des Alertes (Bibliothèque définie par l'Administrateur global du Service et bibliothèque spécifique de la collectivité), l'Opérateur sélectionne l'Alerte qu'il désire envoyer aux Citoyens de sa collectivité.
Interopérabilité avec des systèmes externes
Le système d'Alertes de l'application permet l'interopérabilité avec des systèmes externes tels qu'un service d'état centralisé, ou un service privé (par exemple un service d'informations météorologiques sur l'ensemble d'un territoire, qui pourra fournir à une Autorité des informations météorologiques concernant son périmètre.
Une Alerte émise depuis une source externe, sera déclaré dans le système par l'intermédiaire de WebServices mis à disposition par la solution. Cette Alerte pourra donc ensuite être diffusée par notification auprès de tous les citoyens possédant l'application.
Pour cela, l'opérateur visualise dans l'application Backoffice les Alertes Externes, puis, il valide le cas échéant les Alertes qui devront être répercutées dans la solution selon l'invention par l'intermédiaire de la plateforme.
L'alerte sera automatiquement associée à une autorité, elle est donc émise pour le périmètre de l'autorité (dans notre exemple, cela correspond au contour de la commune).
Donc tout terminal qui se trouve ou entre dans ce périmètre sera automatiquement notifié de l'Alerte en cours.
Formulaire de déclaration d'une Alerte
Le formulaire de déclaration d'une Alerte permet de saisir ou modifier toutes les informations relatives à une Alerte.
1 . Choix du type de l'Alerte
2. Modifier le libellé et description de l'Alerte.
3. Choix d'une période d'activation (date de début, date de fin, gestion manuelle)
4. Territoires et/ou collectivités concernées (gestion du cas où l'Alerte peut sortir du périmètre de la collectivité)
5. Définition de consignes
6. Etc ..
TYPE DE LOCALISATION D'UNE ALERTE
L'opérateur pourra lui-même définir une zone spécifique pour l'alerte, qu'elle soit émise par l'Autorité dont il dépend, ou par un service externe.
Ces zones sont donc de différents types :
Il existe toujours le périmètre de l'autorité
Cela correspond à la fonctionnalité déjà disponible en V1 , pas de changement fonctionnel.
Une zone digitalisée sur la carte : rectangle, cercle, polygone.
L'opérateur peut donc définir des zones temporaires ou qui seront sauvegardées dans le système. Ces zones auront au moins un nom, ce qui permettra de la sélectionner lorsque l'opérateur créera l'Alerte. On pourra « ranger » ou classer ces noms de zones dans une arborescence fonctionnelle.
La sélection d'une entité graphique appartenant à une couche de la cartographie : District, quartier, etc.
Définition de zones d'alertes
Une fonction permettra de créer une zone d'alerte :
Nom, Description
Entité géographique associée :
o Entité graphique existante : district, quartier
o Entité graphique dessinée par l'opérateur
Le choix de l'entité géographique permettra de d'associer automatiquement la surface en m2 à cette zone d'alerte.
Gérer les Alertes
Présentation de formulaires permettant de :
• Visualiser l'historique des Alertes émises.
• Visualiser et gérer les Alertes en cours.
• Reconduire une Alerte.
• Arrêter une Alerte.
Affichage des zones d'alertes dans un tableau ; actions pour modifier, supprimer.
En fonctions de l'entité géographique, les actions seront différentes :
Entité graphique existante : district, quartier
o Suppression impossible.
o Modification des propriétés alphanumériques (nom).
Entité graphique dessinée par l'opérateur :
o Suppression : OK (si aucune alerte en cours)
o Modification des propriétés alphanumériques et/ou graphiques
: OK
RESTITUTION DE L'INFORMATION Les Citoyens adhérents
Accès à la liste des Citoyens qui adhèrent au Service Alert-Phone de la collectivité. Pour chaque Citoyen, on peut comptabiliser le nombre de d'Evénements (avec une répartition en fonction de l'état)
La cartographie des Evénements
On affiche sur une carte, la localisation des Evénements attachés à la collectivité.
On pourra filtrer selon :
• Période.
• Etat de l'Evénement (A traiter, traiter, etc.).
• Affectation au service en charge du traitement de l'Evénement (Voirie, Equipement, etc.).
• Autres selon réflexion.
La base des Evénements
Cette base permettra la création et l'affichage de rapports, d'indicateurs sur l'utilisation du Service Alert-Phone.
Ces rapports pourront rester confidentiels, c'est-à-dire que la collectivité ne les diffuse pas auprès de ses Citoyens.
Ces rapports permettront à un gestionnaire de vérifier le bon fonctionnement du Service à l'intérieur d'une collectivité :
• Taux de déclaration des Evénements
Taux de prise en compte, de résolution, etc.
D'autres rapport ou indicateurs pourront être diffusé par l'intermédiaire de l'espace public du site ALERT-PHONE-COLLECTIVITE auprès du Citoyen.
Tableau de bord et Statistiques
Des rapports mettant en évidence le taux de prise en compte et de résolution pourront être mis en place pour chaque service de la collectivité.
Génération d'un rapport hebdomadaire, mensuel, annuel sur la performance du Service Alert-Phone de la collectivité.

Claims

REVENDICATIONS
1 . Système d'échange d'informations entre différents utilisateurs inscrits au système et différentes autorités associées à des zones géographiques telles que des collectivités territoriales, comprenant :
- une plateforme commune de stockage de données
- des terminaux des différents utilisateurs, comprenant chacun
• un moyen de géolocalisation courant du terminal,
· une interface « signalisation » permettant à l'utilisateur de signaler un Evénement géolocalisé au sein d'une autorité,
• des moyens de transmission à la plateforme qui les stocke, du lieu courant de géolocalisation du terminal et de l'Evénement signalé,
- des terminaux des différentes autorités, comprenant chacun
· des moyens de transmission à la plateforme qui les stocke, d'Alertes émises par l'autorité considérée,
• des moyens de définition d'une zone de diffusion de l'Alerte indépendante du lieu courant de géolocalisation du terminal de l'autorité le système comprenant en outre :
- des moyens de transmission d'un Evénement stocké dans la plateforme à l'autorité associée à la zone géographique où l'Evénement a été géolocalisé, et
- des moyens de transmission d'une Alerte stockée dans la plateforme, à un utilisateur inscrit au système et dont le terminal est géolocalisé dans une zone de diffusion de l'Alerte définie par l'autorité considérée.
2. Système selon la revendication 1 , dans lequel les moyens de géolocalisation des terminaux des utilisateurs sont formés de points GPS fournis par un équipement interne au terminal ou par des points GPS fournis par triangulation de bornes cellulaires, ou sont déterminés par rattachement à un code préalablement déployé et paramétré en une zone spatiale particulière et enregistré par l'utilisateur sur son terminal, ou sont définis par sélection par l'utilisateur d'un point sur une carte affichée dans l'interface de signalisation de son terminal.
3. Système selon la revendication 1 ou 2, comprenant des moyens de déclenchement automatique de la transmission à la plateforme du lieu courant de géolocalisation du terminal d'un utilisateur.
4. Système selon la revendication 3, dans lequel le déclenchement automatique de la transmission à la plateforme du lieu courant de géolocalisation du terminal d'un utilisateur s'effectue périodiquement avec une période correspondant à un temps de remontée d'information prédéfini.
5. Système selon la revendication 4, dans lequel le temps de remontée d'information est adapté en fonction d'un niveau de charge du terminal de l'utilisateur, en étant d'autant plus important que la charge est basse.
6. Système selon l'une des revendications précédentes, dans lequel l'interface du terminal d'un utilisateur comprend une liste de types d'Evénements susceptibles d'être signalés, en fonction du lieu courant de géolocalisation du terminal.
7. Système selon l'une des revendications précédentes, dans lequel la plateforme comprend des moyens d'identification d'un Evénement secondaire signalé par un utilisateur, l'Evénement secondaire étant un Evénement identifié comme similaire à un Evénement déjà signalé et stocké dans la plateforme.
8. Système selon la revendication 7, dans lequel l'identification d'un Evénement secondaire s'effectue par comparaison de paramètres propres à un Evénement déjà signalé et stocké et incluant la géolocalisation et l'heure de l'Evénement, à des paramètres définis par une autorité et incluant un périmètre autour d'un Evénement, une période de temps autour de la survenue d'un Evénement et une indication sur une orientation spatiale relative entre le terminal de l'utilisateur et l'Evénement, un nouvel Evénement étant identifié comme secondaire vis-à-vis d'un Evénement déjà signalé et stocké, s'il intervient dans le périmètre, la période de temps et l'orientation définis par l'autorité.
9. Système selon la revendication 8, dans lequel lorsque l'interface du terminal comprend une capture d'image ou de vidéo à associer à la signalisation d'un Evénement, l'indication sur l'orientation spatiale relative entre le terminal de l'utilisateur et l'Evénement prend la forme d'une boussole apparaissant sur l'image ou la vidéo.
10. Système selon l'une des revendications 7 à 9, dans lequel la plateforme comprend des moyens pour ignorer un Evénement secondaire et ne pas le stocker.
1 1 . Système selon l'une des revendications précédentes, comprenant des moyens pour demander à un utilisateur ayant signalé un Evénement, ou à tout utilisateur se retrouvant dans une zone géographique prédéfinie autour de l'Evénement signalé, des renseignements complémentaires sur l'Evénement, tels que des images ou une confirmation que l'Evénement perdure.
12. Système selon la revendication 1 1 , dans lequel les moyens pour demander des renseignements complémentaires sur un Evénement signalé sont gérés par les terminaux des autorités.
13. Système selon l'une des revendications précédentes, comprenant des moyens pour transmettre le signalement d'un Evénement généré par un utilisateur, à d'autres utilisateurs se trouvant dans une zone géographique prédéfinie autour de l'Evénement signalé.
14. Système selon la revendication 13, dans lequel les moyens pour transmettre le signalement d'un Evénement généré par un utilisateur, à d'autres utilisateurs sont gérés par les terminaux des autorités.
15. Système selon l'une des revendications précédentes, dans lequel les terminaux des utilisateurs sont des terminaux mobiles ou fixes.
16. Procédé d'échange d'informations entre différents utilisateurs inscrits à un système d'échange d'informations et différentes autorités associées à des zones géographiques telles que des collectivités territoriales, comprenant :
-des étapes de stockage de données au sein d'une plateforme de stockage commune aux différents utilisateurs et aux différentes autorités,
- une étape d'identification du lieu de géolocalisation des terminaux des différents utilisateurs inscrits au système, chaque terminal comprenant un moyen de géolocalisation courant du terminal, une interface « signalisation » permettant à l'utilisateur de signaler un Evénement géolocalisé au sein d'une autorité, et des moyens de transmission à la plateforme qui les stocke, du lieu courant de géolocalisation du terminal et de l'Evénement signalé,
- une étape de transmission à la plateforme qui les stocke, d'Alertes émises par des terminaux des différentes autorités le procédé comprenant en outre : - une étape de transmission des Evénements stockés dans la plateforme à chaque autorité associée à la zone géographique où l'Evénement a été géolocalisé, et
- une étape de transmission des Alertes stockées dans la plateforme, à chaque utilisateur inscrit au système et dont le terminal est géolocalisé dans une zone de diffusion de l'Alerte définie par l'autorité considérée.
EP14798919.8A 2013-10-18 2014-10-20 Système d'échange d'informations entre différents utilisateurs et différentes autorités Withdrawn EP3058543A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1360196A FR3012240B1 (fr) 2013-10-18 2013-10-18 Systeme d'echange d'informations entre differents utilisateurs et differentes autorites
PCT/FR2014/052661 WO2015055970A1 (fr) 2013-10-18 2014-10-20 Système d'échange d'informations entre différents utilisateurs et différentes autorités

Publications (1)

Publication Number Publication Date
EP3058543A1 true EP3058543A1 (fr) 2016-08-24

Family

ID=50424352

Family Applications (1)

Application Number Title Priority Date Filing Date
EP14798919.8A Withdrawn EP3058543A1 (fr) 2013-10-18 2014-10-20 Système d'échange d'informations entre différents utilisateurs et différentes autorités

Country Status (4)

Country Link
EP (1) EP3058543A1 (fr)
FR (1) FR3012240B1 (fr)
MA (1) MA38979A1 (fr)
WO (1) WO2015055970A1 (fr)

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7301450B2 (en) * 2006-03-14 2007-11-27 John Carrino Citizen communication center
FR2953054B1 (fr) * 2009-11-25 2012-01-06 Coyote Sys Systeme d'aide personnalisee a la conduite d'un vehicule
FR2982986B1 (fr) * 2011-11-23 2013-11-15 Wikango Systeme electronique d'aide a la conduite

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None *
See also references of WO2015055970A1 *

Also Published As

Publication number Publication date
MA38979A1 (fr) 2016-05-31
FR3012240B1 (fr) 2016-01-01
WO2015055970A1 (fr) 2015-04-23
FR3012240A1 (fr) 2015-04-24

Similar Documents

Publication Publication Date Title
US9706379B2 (en) Method and system for generation and transmission of alert notifications relating to a crowd gathering
Avvenuti et al. Ears (earthquake alert and report system) a real time decision support system for earthquake crisis management
US10922776B2 (en) Platform for real-time views on consolidated data
Mateescu et al. Social media surveillance and law enforcement
US10062129B1 (en) Systems and methods for a home market alert service
US8266712B2 (en) Privacy through artificial contextual data generation
AU2005242282A1 (en) Communication system and method for comprehensive collection, aggregation and dissemination of geospatial information
CN109274727A (zh) 基于区块链的气象数据共享方法、装置及系统
Dette Do no digital harm: mitigating technology risks in humanitarian contexts
US10904376B1 (en) Location specific container based management of mobile devices
EP3058543A1 (fr) Système d&#39;échange d&#39;informations entre différents utilisateurs et différentes autorités
CN113132909B (zh) 基于网络切片与边缘数据中心的失踪人员协查方法、装置
US10708749B1 (en) Validating and supplementing emergency call information removing private information
US20200175189A1 (en) Detecting events from features derived from ingested signals
Elazab et al. Location based services classifications
FR3047334A1 (fr) Systeme et procede de traitement et partage des donnees sur une region geographique preconfiguree et determinee
EP2769528A1 (fr) Systeme de communication pour l&#39;affichage d&#39;annonces publicitaires
Elazab et al. Location Based Approach for Messaging Services.
Weiss Spying on ourselves
WO2020128252A1 (fr) Procédé et structure de signalement d&#39;incident
Healow Neighborhood Watch 2.0: Private Surveillance and the Internet of Things
Kubásek Civic Issues Reporting and Involvement of Volunteers as a Phenomenon in the Czech Republic
Animas et al. PEERS: A Community-based Geo-social Information Collaboration Framework for Public Safety and Security
Zarate Data on Demand
John et al. A review of Information Communication Technology (ICT) methods for road infrastructure monitoring

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20160415

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20170928

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20180209