FR3072487A1 - METHOD AND SYSTEM FOR PROCESSING DATA RELATING TO AN INCIDENT - Google Patents

Abstract

An incident data processing method implemented by a processing unit is proposed. The method includes: upon receipt of incident reporting data, storing incident data in a first database that includes data representative of a management system. olocalisation of incident and incident report, select one or more users based on user profile data corresponding respectively to users and incident data, to report a crash return request to at least one selected user, and update in the first database the status of the incident based on tracking data from incident received from at least selected users.

Description

Method and system for processing incident data

The field of the invention relates to methods and systems for processing data relating to an incident in order to ensure verification, follow-up and resolution of the reported incident.

Today, the multiplication of means of communication and the democratization of smartphones allow in each city the constitution of a vast network in which the citizens participate. Awareness of the dynamism and scope of this network has led to the development of "smart cities" (also known by the English term Smart City). This recent concept refers to cities using information and communication technologies to improve the quality of urban services or reduce their costs.

The smart city contributes more generally to the implementation of "Citizen Sourcing" which relies on the active contribution of citizens to develop new services in which the role of citizens is paramount. Among the many applications, "Citizen Sourcing" allows for example to collect ideas and suggestions from citizens or even increased monitoring of social networks to find collective solutions to problems caused by natural disasters.

Collaborative reporting and recording of incidents therefore presents a major challenge for smart cities. The various platforms created to allow citizens to forward information in the event of an incident today encounter problems related to verifying or monitoring the status of a report. In addition, the resolution of these incidents comes up against the inability of these platforms to selectively solicit citizens able to provide a solution to the reported incidents.

The present invention improves the situation.

To this end, there is provided a method for processing incident data implemented by a processing unit, the method comprising:

a) on receipt of incident reporting data comprising incident presence data and incident geolocation data, store incident data relating to the incident in a first database, the data incident comprising data representative of a geolocation of the incident and of an incident state selected from a predefined set of states, the incident data being a function of the data received. A reported incident is archived in the first database in order to ensure its verification, follow-up and resolution. Such archiving also makes it possible to keep a history of past and current incidents. The data representative of a geolocation of an incident stored in the first database are determined as a function of the incident reporting data, and more precisely of the geolocation data of the incident. This data can for example be transcoded and / or formatted to produce the data representative of a geolocation of an incident which is stored in the first database,

b) select one or more users according to user profile data corresponding respectively to users, and according to incident data, the user profile data being stored in a second database,

c) issue an incident return request to at least one selected user, the incident return request comprising at least part of the incident data, and

d) update the incident status in the first database according to incident tracking data received from at least selected users.

In one or more embodiments, the predefined set of states includes at least one "unresolved incident" state, a "resolved incident" state and a "faulty incident" state. This set of reports allows monitoring, potentially in real time or close to real time, of the reported incident. Specifically, the "unresolved incident" status indicates that the reported incident has not been resolved or is in the process of being resolved. The "incident resolved" status indicates that the reported incident has been resolved and therefore no longer requires the intervention of new users. Finally, the “erroneous incident” state indicates, for example, that the incident was reported in error, or that the incident has already been resolved, or any other state that cannot be assimilated to the “incident not resolved” state or the 'incident resolved' state.

In this embodiment, the transmission of incident return request and the update of the incident state are advantageously repeated according to an iterative process as long as the incident state after update does not correspond not to a predefined state for stopping the iterative process, for example the “incident resolved” state. The incident tracking data sent by users, selected or not, connected to their respective user accounts via their respective user terminals makes it possible to update the status of the incident in the first database. In one or more embodiments, as long as the incident state is not the "incident resolved" state, incident feedback requests are sent in a loop, thus optimizing the chances of resolution of the incident .

In the embodiments using the iterative process described above, the iterative process can advantageously be interrupted if the number of repetition cycles of the transmission of incident feedback request and of updating the state of the incident reaches a predetermined number. As previously explained, return incident request cycles increase the chances of resolving the reported incident. However, in the event that the incident was reported in error, such a cycle interrupt feature avoids unnecessarily asking users.

In one or more embodiments, the user profile data corresponding to a user is representative of a geographic location of a user terminal of the user. A user is characterized in the second database by user profile data. This user profile data may include terminal data comprising data representative of one or more respective geographic locations of one or more user terminals of the user. Such data allows a finer and optimized selection of users for monitoring, verification and resolution of reported incidents. It is in particular advantageous to select users whose current or usual position is close to the reported incident.

In one or more embodiments, the user profile data corresponding to a user comprises data representative of a user confidence index. As explained above, the selection of users may depend on user profile data. The user profile data may in particular include trust index data. It is particularly advantageous to assign a confidence index to a user to estimate the relevance of the incident tracking data that he would be able to send from his user account via a user terminal. In particular, such a functionality makes it possible to attribute more credibility and importance to incident tracking data sent by a user considered to be very reliable than to data sent by a user judged to be unreliable.

In this embodiment, a reliability coefficient can be calculated for each state of the set of states following the receipt of incident tracking data, the reliability coefficient of a state being a function of the number of users. having transmitted incident tracking data representative of said state and of the users' respective confidence index. The confidence indexes assigned to users are used to estimate the relevance of the incident tracking data that they are likely to send. The incident tracking data are advantageously representative respectively of a state of the incident. It is understood here that a user can, via a user terminal, send incident tracking data to report that an incident is resolved, unresolved or erroneous. Depending on each person's confidence indexes, we can estimate the reliability of each state, that is to say the probability that the incident is in such and such a state.

In this embodiment, the reliability coefficient of a state E, is for example defined by:

N, Ci = ^ ic (j) 1 = 1 where:

• Ci is the reliability coefficient for the state Ej, • Ni is the number of users who sent incident monitoring data which include monitoring data representative of the state Ej, and • IC (j) is the confidence index of the j-th user who sent incident tracking data representative of the state Ej.

In this embodiment, the predefined set of states comprises at least one “unresolved incident” state, a “resolved incident” state and a “faulty incident” state and, in the absence of reception of tracking data d incident associated with a user selected after a predetermined period of time, the reliability coefficient of the "erroneous incident" state is advantageously increased by the confidence index of said user. It is entirely possible that a user receives a request for incident feedback on their user account but does not respond to this request. In such a case, it can be considered that the absence of reaction on the part of the user is significant of an erroneous state of the reported incident.

In this embodiment, the update of the incident state is for example carried out as a function of the respective reliability coefficients of each state of the set of states. After a cycle of transmission of incident return requests, of processing of the incident monitoring data received, the status of the incident in the first database can possibly be updated as a function of the tracking data d 'incident received.

In one or more embodiments, the user profile data corresponding to a user are representative of a geographic location of a user terminal of the user and the selection of one or more users comprises:

bl) determine a set of users, each user being associated with a user terminal whose geographic location is at a distance from the geolocation of the incident less than or equal to a predetermined threshold, b2) determine whether the set of users verifies a confidence index criterion, the determination of a set of users being repeated for a new threshold greater than the previous one if the confidence index criterion is not verified, b3) select the users from the set of users if the confidence index criterion is verified.

As explained previously, the users can be selected both according to user profile data (comprising data representative of a geographic location of a user terminal of the user and data representative of a confidence index of l 'user) and incident data. Thus, the selection of the users can be carried out by first determining a set of users close to the incident (or those whose usual position is close), then by choosing within this set of users according to the indices of respective trust.

In this embodiment, the confidence index criterion is for example defined by:

N _p > N _P; mi _n for any natural integer p between 1 and n where:

• n is a predetermined non-zero natural integer • N _p is the number of users of the set of users whose confidence index is greater than or equal to the predetermined confidence index IC _P and strictly less than the predetermined confidence index ICp + i, with IC _p <IC _{p +} i for any natural integer p between 1 and n, • N _Pjm in is a predetermined natural integer, for all natural integer p between 1 and n, the selected users satisfying the following condition:

N _p , _min <N'p where N ' _p is the number of selected users whose confidence index is greater than or equal to the predetermined confidence index IC _P and strictly lower than the predetermined confidence index IC _{p +} i.

Such a confidence index criterion makes it possible to control the heterogeneity of the users selected for sending a return incident request. It is indeed advantageous to have reliable or very reliable users to ensure optimal monitoring of the status of the reported incident. But it is also advantageous to be able to select unreliable or unreliable users to reassess their respective confidence indices. Such functionality ensures dynamism in updating user profile data in the second database via intelligent learning.

In one or more embodiments, the confidence index of at least one user at the origin of incident tracking data is updated according to the state of the incident including the tracking data d 'incident are representative and the status of the incident updated. As previously explained, the incident status may be updated after processing the incident tracking data received. It is thus possible to compare the status of the incident after updating and the status of the incident as reported by users. Thus, if the incident state is the “incident resolved” state after updating but a user has reported the incident as being unresolved, the confidence index of this user can be reduced and the for example, the user can switch from reliable to unreliable. Conversely, if the incident status is, for example, the status “erroneous incident” after update and a user has actually reported the incident as being erroneous, the confidence index of this user can be increased and the user can change, for example, from unreliable to reliable.

In one or more embodiments, the user profile data corresponding to a user are representative of an active mode, in which the user is systematically selected, or of a passive mode, in which the user is not systematically selected. It is possible for a user to be selected even when his geographic location or his confidence index do not justify being selected. Thus a user whose user profile data is representative of the active mode is systematically selected.

A computer program is also proposed, characterized in that it includes instructions for the implementation of the incident data processing method according to one of the embodiments proposed herein, when this program is executed by at least one processor.

Finally, an incident data processing system is proposed for implementing the method, the system comprising: a communication module adapted to receive incident reporting data, a first database adapted to store data. of incident relating to the incident, a second database adapted to store user profile data corresponding respectively to users, and a processing unit comprising a processor, operatively coupled to the communication module and to the first and second databases, in which the communication module, the first and second databases and the processing unit are further adapted to implement a method for processing incident data according to one of the proposed embodiments herein.

Other characteristics, details and advantages of the invention will appear on reading the detailed description below, and on analysis of the appended drawings, in which:

Figure 1 illustrates an assembly comprising at least one user terminal at the origin of data relating to an incident, a system and a plurality of user terminals selected for the verification, monitoring and resolution of the incident;

Figure 2 illustrates a process for processing incident data in one or more embodiments; and Figure 3 illustrates a selection of one or more user terminals of the method illustrated in Figure 2.

Figure 1 illustrates a set 1. The set 1 comprises at least one user terminal 3, a system 5 and user terminals 7, 9.

The user terminal 3 is adapted to report an incident to the system 5. More precisely, the user terminal 3 allows a user in his possession to report an incident and information relating to the incident to the system 5. For example, an incident is a car accident, fire, deterioration of the roadway or any other localized event which may be the subject of a report.

The user terminal 3 comprises a man / machine interface 11, a processing module 13 and a communication module 15.

The Human / Machine interface 11 is adapted to allow the user to specify the geolocation of the incident that he wishes to report to the system 5. Alternatively, the geolocation of the incident is associated with a current position of the user terminal 3 The current position of the user terminal 3 is for example automatically determined by a server connected to a network to which the user terminal 3 is connected. Alternatively, the user terminal 3 comprises a geolocation module, for example of the GPS type (English acronym for “Global Positioning System”) or of the Galileo type.

Advantageously, the Human / Machine interface 11 is adapted to allow the user to specify a level of urgency for the incident. For example, the Human / Machine interface 11 allows you to select the emergency level of the incident on a pre-established scale. The level of urgency is for example characterized by a number or a letter.

Advantageously, the Human / Machine interface 11 is adapted to allow the user to specify a type of incident. For example, the Human / Machine interface 11 allows you to select the type of incident from a pre-established list of potential incidents. This functionality can be in the form of a drop-down menu accessible to the user via the Human / Machine interface 11. Alternatively, the Human / Machine interface 11 makes it possible to specify a type of incident that is not part of the preset list via a free text option accessible to the user.

The functions described above and accessible to the user wishing to report an incident via the Human / Machine interface 11 of their user terminal are accessible to the user in question, for example by logging into a user account. It is understood here that in one or more embodiments, a user wishing to participate in the reporting, monitoring, verification and resolution of incidents can do so by running a client application on a user terminal (for example native application or web running on a smartphone or tablet, or web-application running through a web browser on a personal computer (such as PC, for "Personal Computer"), and using a user account to connect to a server application running on an incident data processing system as proposed herein. This user account can for example be in the form of a data set comprising identification data as well as, depending on the case, user authentication data. Depending on the embodiment, a client application executed on a user terminal may require user registration and the provision of data such as a mobile number, a password or personal data such as his workplace. , his home address or any other place regularly visited by the user.

The processing module 13 is adapted to generate signaling data SIGN relating to the incident. In the following description, the SIGN data relating to the incident is called the SIGN incident reporting data. SIGN incident data may in particular include presence data and geolocation data of the incident or incidents.

Advantageously, the SIGN incident data includes emergency data of the incident or of each incident to which it relates. In one or more embodiments, the emergency data of an incident is representative of an emergency level selected by the user for the incident.

Advantageously, the incident report SIGN data includes data of the type of the incident or of each incident to which it relates. In one or more embodiments, the incident type data is representative of an incident type as selected or specified by the user.

Advantageously, the incident report SIGN data also includes identification data of the user terminal 3.

In one or more embodiments, the processing module 13 comprises a memory 17 and a processor 19.

The memory 17 can be configured to store lines of code of a computer program whose execution by the processor 19 results in the operation of the processing module 13 for the implementation of the proposed incident processing method. Advantageously, the memory 17 is further configured to store an address of the system 5 for the routing of the incident report data SIGN to the corresponding system 5.

The communication module 15 is adapted to transmit the incident signal data SIGN to the system 5. The incident signal data SIGN are for example transmitted to the system 5 via a network (not shown in Figure 1 ). Such a network is for example a MAN type network (English acronym for "Metropolitan Area Network").

Those skilled in the art can appreciate that there are many different types of data communication networks, for example radiocommunication networks, cellular or non-cellular, and that depending on the embodiment, the communication module 15 could integrate one or more communication modules, for example radio frequency communication and be configured for the transmission and reception of radio frequency signals, according to one or more technologies, such as TDMA, FDMA, OFDMA, CDMA, or one or more standards radio communications, such as GSM, EDGE, CDMA, UMTS, HSPA, LTE, LTE-A, WiFi (IEEE 802.11) and WiMAX (IEEE 802.16), or their variants or developments, currently known or developed later.

System 5 is adapted to follow up on the reported incident.

In the nonlimiting embodiment illustrated in FIG. 1, the system 5 comprises a communication module 21, a first database 23, a second database 25 and a processing unit 27.

The communication module 21 is adapted to receive SIGN incident signaling data transmitted by a user terminal 3. Advantageously, the communication module 21 is adapted to receive SIGN incident signaling data transmitted by user terminals such as the user terminal 3. The communication module 21 is further adapted to communicate with user terminals. In the example illustrated in Figure 1, the communication module 21 is adapted to communicate with the plurality of user terminals 7, 9. The communication module 21 communicates for example with the plurality of terminals 7, 9 via a network (not shown on the face). Such a network is for example a MAN type network.

Again, there are many different types of data communication networks, for example radio networks, cellular or non-cellular, and that depending on the embodiment, the communication module 21 may integrate one or more communication modules. communication, for example radiofrequency communication and be configured for the transmission and reception of radiofrequency signals, according to one or more technologies, such as TDMA, FDMA, OFDMA, CDMA, or one or more radiocommunication standards, such as GSM, EDGE , CDMA, UMTS, HSPA, LTE, LTE-A, WiFi (IEEE 802.11) and WiMAX (IEEE 802.16), or their variants or evolutions, currently known or developed later.

In one or more embodiments, the first database 23 is adapted to store data, called incident data, relating to a reported incident. The incident data stored in the first database 23 may comprise, for an incident, data representative of a geolocation of the incident, for example received with incident reporting data SIGN relating to the incident and Advantageously, the data representative of a geolocation of the incident stored in the first database 23 are a function of the incident signaling data SIGN received.

In one or more embodiments, the incident data stored in the first database 23 can also comprise, for an incident, data representative of an incident state, or incident state data , selected from a set of states. In one embodiment, the set of states may include at least one "unresolved incident" state, a "resolved incident" state and a "faulty incident" or "error on the incident" state. The incident status data in the first database 23 can be defined and structured to allow monitoring of the evolution of the incident over time, based on the status information of the incident. 'incident. For example, when the incident is reported, the state of the latter in the first database 23 may be the "unresolved incident" state since the incident is not a priori resolved. In one or more embodiments, this “unresolved incident” state can be assigned by default to any incident newly reported and newly recorded in the first database 23.

In one or more embodiments, the “resolved incident” state can be used to characterize a resolved incident. For example, the state “incident resolved” can be assigned to an incident recorded in the first database 23, and the state of which has evolved into a state in which the incident is considered to be resolved.

In one or more embodiments, the "erroneous incident" state can be used to characterize a reported incident but the veracity of which has not been established or could not be established.

In one or more embodiments, the incident data stored in the first database 23 can also comprise, for an incident, emergency data for the incident.

In one or more embodiments, the incident data stored in the first database 23 can also comprise, for an incident, data representative of the type of information of the incident.

Advantageously, the first database 23 stores all the incidents reported by user terminals such as the user terminal 3. The conservation in the first database 23 of the reported incidents makes it possible to establish a history. The history may include other reported incident data such as video or incident images.

In one or more embodiments, the second database 25 is adapted to store data, called user profile data, respectively relating to users. As previously mentioned, user profile data can be associated with a user account of the user. The second database 25 can for example include a list of users, and each user in the list can correspond to user profile data stored in the second database 25.

In one or more embodiments, the user profile data stored in the second database 25 can comprise, for a user, data representative of a geographic location of a user's user terminal, or terminal data . The geographic location of a user terminal is for example a current position of the user terminal. Alternatively, the geographic location may be a regular or usual position of the user terminal, or else a combination of a current position and a regular or usual position of the terminal. The geographic location data of a user terminal stored in the second database 25 can correspond, depending on the embodiment chosen, to different levels of geographic scale, and can for example designate a domicile, a workplace of the user in possession of the user terminal or any other place occasionally visited by the user. In one or more embodiments, the user profile data stored in the second database 25 can comprise, for a user, data representative of a plurality of geographic locations, each geographic location data item of the plurality of geographic locations being associated with a probability data item that the user terminal is present at this geographic location. It is understood here that one or more geographic locations can be associated with a user terminal corresponding to the user in the second database 25.

In one or more embodiments, the user profile data stored in the second database 25 can comprise, for a user, data representative of a confidence index IC, or confidence index data. A user’s IC trust rating is representative of the user's past contribution to the verification, tracking, and resolution of past incidents. Depending on the embodiment chosen, the confidence index IC can take continuous values, or discrete values. By way of example, the system 5 can be configured to use discrete values of confidence indices, for example the set of values {0; 0.25; 0.5; 1; 2}, and a user deemed unreliable can be associated in the second database 25 with a confidence index value equal to 0, a user considered neutral can be associated in the second database 25 with a value of confidence index equal to 0.25, a user considered to be fairly reliable can be associated in the second database 25 with a confidence index value equal to 0.5, a user considered to be reliable can be associated in the second database 25 to a confidence index value equal to 1, and a user judged to be very reliable can be associated in the second database 25 with a confidence index value equal to 2.

In one or more embodiments, the processing unit 27 is adapted to select one or more users from the second database 25 as a function of user profile data and incident data. The selection of users will be detailed below. In the nonlimiting example illustrated in FIG. 1, the user terminals 7, 9 are associated respectively with users selected by the processing unit 27. As specified previously, the processing unit 27 can select only one user .

In one or more embodiments, the processing unit 27 can also be adapted to generate a request for incident feedback REQ intended to be sent to one or more selected users. As explained above, any user wishing to participate in the reporting, monitoring, verification and resolution of incidents must have a user account. It is understood here that the request for return on incident REQ is transmitted to the user account of each selected user. A selected user can therefore access the REQ incident feedback request by logging into their user account via a user terminal. The REQ incident recovery request may include at least part of the incident data. The REQ incident return request may, for example, include data relating to the geolocation of the incident. Depending on the embodiment, the REQ incident return request may also include an emergency level of the incident, a type of incident and / or an incident state. The REQ incident feedback request allows selected users to learn about the incident and necessary elements such as the level of urgency of the incident or its geolocation.

The REQ incident return request can be sent by the communication module 21 to the selected terminals.

In one or more embodiments, the processing unit 27 can also be adapted to update the incident status data in the second database 25 as a function of incident tracking data received from at least selected users. It is understood here that a user selected to receive a REQ incident return request may not respond to the REQ incident return request. It is also understood that a user wishing to transmit incident tracking data to the processing unit 27 can transmit this data via a user terminal in his possession after logging into his user account.

In one or more embodiments, the user profile data of a user comprises data representative of an active mode, in which the user is systematically selected to receive a request for return on incident REQ, or of a mode passive, in which the user is not systematically selected to receive a request for return on incident REQ. It is understood here that the users whose user profile data comprise data representative of an active mode are part of the selected users, that is to say the users to whom a request for incident feedback REQ is sent via their respective user accounts.

In one or more embodiments, the processing unit 27 comprises a memory 29 and a processor 31.

The memory 29 can be configured to store lines of code of a computer program whose execution by the processor 31 results in the operation of the processing unit 27 for the implementation of the proposed incident processing method . Advantageously, the memory 29 is also configured to store respective addresses of user accounts for the routing of a request for return on incident REQ to each selected user to whom it is planned to send a request for return on incident REQ .

In one or more embodiments, each user account associated with a selected user can be adapted to, on receipt of a request for return on incident REQ, or independently of the reception or not of a request for return on incident, collect information regarding a reported incident. The respective user accounts of the selected users can thus be configured to cooperate with the system 5 to allow the latter to follow up on the reported incident.

In the example illustrated in Figure 1 and as explained above, the selected users have access to the REQ incident return request sent by the system 5 respectively via the user terminals 7, 9. In other words, two users have been selected in the example illustrated in Figure 1. Each selected user accesses the REQ incident feedback request by opening their user account on a user terminal, here a first user terminal 7 and a second user terminal 9. Ideally, several tens of the user are selected by the system 5 for sending a request for return on incident REQ.

Each user terminal 7, 9 is adapted to allow a user to access his user account. For example, the user terminal 7, 9 is suitable for connecting to an Internet type network and thus allowing the user to access his user account.

In one or more embodiments, each user terminal 7, 9 comprises a communication module 33, a man / machine interface 35 and a processing module 37.

The communication module 33 is adapted to communicate with the system 5. More particularly, the communication module 33 is adapted to receive a request for return on incident REQ sent by the system 5.

The communication module 15 may integrate one or more communication modules, for example radio frequency communication and be configured for the transmission and reception of radio frequency signals, according to one or more technologies, such as TDMA, FDMA, OFDMA, CDMA, or one or more radiocommunication standards, such as GSM, EDGE, CDMA, UMTS, HSPA, LTE, LTE-A, WiFi (IEEE 802.11) and WiMAX (IEEE 802.16), or their variants or evolutions, currently known or developed later.

In one or more embodiments, the Human / Machine interface 35 is adapted to display information characteristic of the incident, and make it accessible to the user. This information is intended to facilitate user verification and resolution of the incident. The Human / Machine interface 35 is for example adapted to display the geolocation of the incident.

For example, the Human / Machine interface 35 is advantageously adapted to display the emergency level of the incident, the type of incident and / or the status of the incident.

In one or more embodiments, the Human / Machine interface 35 is further adapted to allow the user to select an incident state from a set of incident states to indicate to the system 5 a current state. of the incident as he sees it. This set of incident states preferably comprises the set of incident states used in the first database 23. In the event of resolution of the incident, the user can for example select the “incident resolved” state. Or an equivalent state from the set of states to indicate that the incident is resolved. If the incident is not resolved, the user can for example select the "incident not resolved" state or an equivalent state from the set of states to indicate that the incident is still not resolved. absence of incident, the user can for example select the “erroneous incident” state or an equivalent state from the set of states to indicate that he does not observe any incident, possibly corresponding to the type of incident which indicated to him, in the place corresponding to the geolocation of the incident.

More specifically, the information and data relating to the incident as well as the functionalities allowing the user to participate in the verification, monitoring and resolution of the incident are accessible via the Human / Machine interface 35 when the user is connected to their user account via their user terminal 7, 9.

In one or more embodiments, the processing unit 37 can be adapted to generate incident tracking data intended to be sent to the system 5. In the example described here, the user terminal 7 sends a message ANS7 containing incident tracking data to system 5, and the user terminal 9 sends an ANS9 message containing incident tracking data to system 5. The incident tracking data included in the messages respectively ANS 7, ANS 9 include data relating to an incident state as selected by the user. In one or more embodiments, the ANS 7, ANS 9 messages can also advantageously include identification data of the user terminal sending the data, such as, for example, a terminal identifier of the MSISDN number type (from English Mobile Station - Integrated Services Digital Network), of the IMSI type (from the English “International Mobile Subscriber Identity”), or from the IMEI type (from the English “International Mobile Equipment Identity”).

In one or more embodiments, the processing unit 37 comprises a memory 39 and a processor 41.

The memory 39 can be configured to store lines of code of a computer program whose execution by the processor 41 results in the operation of the processing unit 37 for the implementation of the proposed incident processing method . Advantageously, the memory 39 is also configured to store an address of the system 5 for the routing of the message comprising incident tracking data intended for the system 5.

In the example described here, the selected users transmit, via a user terminal, incident tracking data intended for the system 5 in response to the reception of the incident feedback request REQ. As explained above, the second database 25 can be adapted so that the user profile data can correspond to several user terminals of the same user. For example, the user terminals of the same user are characterized by the same identification data. The different user terminals belonging to the same user, within the second database 25, make it possible to determine several possible geographic locations of this user. However, as explained above, a user accesses a request for a REQ incident by logging into his user account. Thus, a user can completely connect to his user account via an unreferenced user terminal, within the second database 25, as belonging to the user in question, and send incident tracking data to the system 5 via this user terminal.

An incident processing method as proposed is now described in one or more embodiments with particular reference to Figures 2 and 3.

With reference to FIG. 2, the system 5 receives (SI) incident signaling data SIGN from a user terminal. In the example described here, the incident report SIGN data comes from the user terminal 3 and is sent by the communication module 15. In addition, the incident report SIGN data includes geolocation data of the incident . In one or more embodiments, the incident report SIGN data also includes data representative of an emergency level of the incident and / or data representative of the type of incident.

Upon receipt of the SIGN incident data, incident data relating to the incident is stored (S2) in the first database 23. The incident data includes at least data representative of a geolocation of the incident and an incident state among a set of states. As previously explained, incident data is a function of received SIGN incident reporting data. Advantageously, the data representative of a geolocation of the incident stored in the first database 23 are determined as a function of the geolocation data of the incident included in the incident reporting data SIGN. For example, the incident state which has just been reported by the user terminal 3 is the "unresolved incident" state or an equivalent state.

One or more users are selected (S3) by the processing unit 27 of the system 5. In one or more embodiments, the selection of the users is carried out as a function of the user profile data stored in the second database 25, and based on incident data. In one embodiment, the selection of users is carried out on the user profile database included in the second database 25, without taking account of the incident data, and this selection can then be carried out independently of reception. SIGN incident reporting data. In another variant, the selection of users is preconfigured in the system 5, independently of user profile data or incident data. Those skilled in the art can realize that the different modes of selecting user terminals can be used individually, or in combination, depending on the embodiment chosen, and that the proposed method is not limited to a selection scheme. particular.

As indicated above, the user profile data corresponding to a user can comprise, in one or more embodiments, data representative of a geographic location of a user terminal of the user. The user profile data may also comprise data representative of a confidence index IC of the user to which they correspond. The user profile data can further comprise, in one or more embodiments, data representative of a plurality of geographic locations such as a current position and a usual position of the user terminal. The selection of users (reference S3 in Figure 2) will now be described in one or more embodiments with reference to Figure 3.

FIG. 3 illustrates various operations, the implementation of which corresponds to the realization, by the processing unit 27, of the selection of users. More particularly, these operations relate to the mode of selection of the users.

Referring to Figure 3, the processing unit 27 determines (Tl) a predetermined distance Di, hereinafter predetermined threshold Di. This predetermined threshold Di makes it possible to delimit a geographic area around the geolocation of the incident. Users whose respective user terminal (s) are located in this geographical area can then be selected to be called upon to ensure verification of the status of the incident, for example by sending a return request REQ incident of the type described above. As explained above, a geographic location of a user's user terminal can also correspond to a current position of the user terminal. Alternatively, the geographic location may be a regular or usual position of the user terminal, or else a combination of a current position and a regular or usual position of the terminal.

To do this, the processing unit 27 can, in one or more embodiments, determine (T2) a set of user terminals whose geographic location is at a distance from the geolocation of the incident less than or equal to the predetermined threshold. Di.

In one or more embodiments, for example when the reported incident is considered urgent on the basis of emergency information representative of the level of emergency included in the SIGN incident reporting data, the geographic location considered to determine the set of selected user terminals is the respective current position of the user terminals. In the case of a lower emergency level, the geographic location considered can be a usual or regular position of each user terminal.

In one or more embodiments, the processing unit 27 determines (T3) whether the set of user terminals determined during the previous operation T2 verifies a criterion of confidence index. The confidence index criterion will be detailed in the following description.

The processing unit 27 determines confidence index values {IC _P }, p being a natural integer between 1 and n + 1, n being a non-zero natural integer. The IC _P confidence indices are, for example, ordered in ascending order:

ICi <... <ICp <... <IC _{n +} i

As explained above, several confidence index thresholds can be predefined in order to respectively associate corresponding confidence index intervals with user reliability levels. For example, the system 5 can be configured to determine that a user will be considered unreliable when associated with a confidence index equal to 0, that a user will be considered neutral when associated with a confidence index equal to 0.25, that a user will be considered fairly reliable when associated with a confidence index equal to 0.5, that a user will be considered reliable when associated with a confidence index equal to 1 , and that a user will be considered very reliable when associated with a confidence index equal to 2.

It can be assumed for example that the processing unit 27 has determined the following values of confidence indices IC _P :

HERE = 0

CI ₂ = 0.25

CI ₃ = 0.5

IC ₄ = 1

IC5 = 2

IC ₆ = 3

From the confidence index values {ICp}, all the user terminals can be partitioned as follows:

N = Ni + - + Ν _ρ + ··· + Ν _η where:

• N is the number of users in the set of users, and • N _p is the number of users in the set of users whose confidence index CI is greater than or equal to the confidence index predetermined at IC _P and strictly lower than the confidence index predetermined at IC _{p +} i · In other words:

IC _P <IC <IC _p + i

Here, the confidence index IC can take continuous values or discrete values.

In the example described above where 6 values of confidence index IC _P are predetermined, the set of user terminals can be partitioned as follows:

N = Ni + N ₂ + N ₃ + N ₄ + N ₅ where:

• Ni is the number of users in the set of users whose confidence index is greater than or equal to ICi = 0 and strictly less than IC2 = 0.25, • N2 is the number of users of the set of users whose confidence index is greater than or equal to ICi = 0.25 and strictly less than IC2 = 0.5, • N ₃ is the number of users of the set of users whose index is greater than or equal to IC2 = 0.5 and strictly less than IC3 = 1, • N ₄ is the number of users in the set of users whose confidence index is greater than or equal to IC3 = 1 and strictly less than IC ₄ = 2, • N ₅ is the number of users in the set of users whose confidence index is greater than or equal to IC4 = 2 and strictly less than IC2 = 3,

In one or more embodiments, it is determined that the confidence index criterion is verified if:

N _p > Np _{; m} in, for any natural integer p between 1 and n where Νρ, πύη is a natural integer predetermined by the processing unit 27.

Still with reference to the example described above where 6 values of confidence index IC _P are predetermined, the criterion of confidence index is for example verified if the set of users comprises at least Z very reliable users, 2Z users reliable, 4Z user fairly reliable, 8Z neutral users and 16Z unreliable users, Z being a natural number. In other words:

Ni _{> min} = 16 * Z

N2, min ⁼ 8 * Z

N _{3; min} = 4 * Z

N4, min = 2 * Z

N5 _{; m} in = Z

Typically, untrusted users are selected in order to reassess their confidence indices as explained below.

If the confidence index criterion is not verified, the processing unit 27 selects (T4) a new threshold D2 strictly greater than Di. The operations T2 and T3 are then repeated until a set of users verifying the criterion of confidence index is found. It is understood here that the zone around the incident from which the users will be selected is widened as long as the set of users inside this zone does not check the criterion of confidence index.

When a set of users verifying the criterion of confidence index has been determined, the processing unit 27 selects (T5) one or more users from the set of users. The users selected are those who check for example the following condition:

N · <N 'where N'p is the number of selected users whose confidence index IC is greater than or equal to the predetermined confidence index IC _P and strictly less than the predetermined confidence index IC _{p +} i. The number of users selected is then N 'with:

n '= n; + ··· + n ^ + - + n;

In one or more embodiments, the users selected from the set of users verify:

N ’= N

P ^ ρ, ΠΊΐη

Still referring to the example described above, the selected users check for example:

N = 16 * Z

N ' ₂ = 8 * Z

N ' ₃ = 4 * Z

N ' ₄ = 2 * Z

N ' ₅ = Z

At the end of this selection (T5) of one or more users from among the set of users, the processing unit 27 has selected (S3) one or more users, whose respective confidence indices exhibit heterogeneity in the embodiment described with reference to FIG. 3.

The previous operations described with reference to FIG. 3 make it possible to select users as a function of the geographic location or locations of the user terminal or terminals associated with the users in the second database 25 and of a confidence index criterion. Alternatively or in parallel, other users can be selected in place of or in addition to the users selected after the T5 operation. In fact, as explained above, the user profile data of a user comprises, in one or more embodiments, data representative of an active mode, in which the user is systematically selected to receive the return request on REQ incident, or a passive mode, in which the user is not systematically selected to receive a request for return on REQ incident. In one or more embodiments, the users selected by the processing unit 27 can therefore be the users selected via the operations T1, T2, T3, T4 and T5 as well as the users whose user profile data are representative of an active mode.

In the example illustrated in FIG. 1, a first user in possession of a first user terminal 7 and a second user in possession of a second user terminal 9 are selected for sending a request for incident feedback REQ .

Preferably, the system 5 will be configured and configured so that several dozen users are selected. To do this, the system 5 could be provided to reach a minimum threshold of number of users by learning and dynamic configuration.

A processing loop, one iteration of which sends requests and processes incident tracking data received, can be implemented in one or more embodiments of the proposed method. The proposed method illustrated in FIG. 2 thus performs an iterative loop, each iteration of the loop operating the sending of REQ incident feedback requests to the selected user terminals. In the example illustrated in FIG. 2, the loop traverses a set of request emission cycles by means of a loop index k which is incremented (S9) at each loop iteration, k being initialized to the value 0 (S4) and the ending loop (S8) when k reaches the value M, value determined by the processing unit 27 and corresponding to a maximum number of cycles for sending a request for return to incident incident REQ.

At each iteration of the loop, a request for return on incident REQ is sent (S5) by the communication module 21 to the selected user terminals. As indicated above, the request for a return to incident REQ may, in one or more embodiments, comprise at least part of the incident data, such as, for example, representative data of geolocation of the incident . The REQ incident return request may also include an emergency level of the incident, a type of incident and / or an incident status.

Following the sending of incident feedback requests, the system 5 receives incident tracking data (S6) from at least the users selected to receive a REQ incident recovery request. As explained above, in one or more embodiments, incident tracking data can also be received by the system 5 from unselected users. It is also possible that selected users, despite having received the incident feedback request, do not respond to the REQ incident feedback request received on their user account. In other words, it is possible that the system does not receive incident tracking data from a user terminal connected to the user account of a selected user. On receipt of incident tracking data, the unit 27 calculates a reliability coefficient for each state of the predetermined set of possible states for the incident (for example comprising an “unresolved incident” state or an equivalent state, a “resolved incident” state or an equivalent state , and an "erroneous incident" state or an equivalent state as described above).

In one or more embodiments, the incident tracking data sent by a user terminal typically includes data indicating a current state of the incident as entered by the user of the terminal via a human interface. / Terminal machine.

In one or more embodiments, a reliability coefficient for a state for the incident is calculated as a function of the number of users who have sent incident follow-up data comprising data indicating this state, and possibly as a function of the respective IC trust rating of the users who sent incident tracking data. The reliability coefficient of a state advantageously allows the processing unit 27 to determine for example a probability that this state is effectively the state of the incident, for example the state “incident resolved”, “incident not resolved Or "wrong incident".

In one or more embodiments, the reliability coefficient C, of a state E, in a set of states [Εί], can be determined as follows:

1 = 1

or :

• Ci is the reliability coefficient for state E _i5 • Ni is the number of users who sent incident follow-up data which include follow-up data representative of state E _i5 and • IC (j) is the confidence index of the jth user who sent incident tracking data representative of the state Ej.

In the nonlimiting case where the set of states {Ei} _{i = 1 3} comprises three states, for example a "incident resolved" or equivalent state, a "incident not resolved" or equivalent state, and a state " erroneous incident "or equivalent, the processing unit 27 measures three reliability coefficients corresponding respectively to the states: a first reliability coefficient for the" resolved incident "state, a second reliability coefficient for the" unresolved incident "state , and a third reliability coefficient for the "erroneous incident" state.

With reference to the particular case described above in which a user will be considered unreliable when associated with a confidence index equal to 0, a user will be judged neutral when associated with a confidence index equal to 0.25, a user will be considered fairly reliable when associated with a confidence index equal to 0.5, a user will be considered reliable when associated with a confidence index equal to 1, and a user will be considered very reliable when it is associated with a confidence index equal to 2, to illustrate the operations of Figure 3, each coefficient Ci can for example be determined as follows:

Cj 0 * Νί _ηοη finite + 0.25 * Nj, neutral d * Njpiôtôtiables d ”1 * Nj fi _a bi _es + 2 * N ^ very reliable where:

• Ni, _n on reliable is the number of users associated with a confidence index corresponding to the level of “unreliable” confidence confirming the state E _i5 • N ;, neutral is the number of users associated with a confidence index corresponding to the “neutral” level of confidence confirming the state Ej, • N ;, rather reliable is the number of users associated with a confidence index corresponding to the level of “fairly reliable” confidence confirming the state E _i5 • Ni, gables is the number of users associated with a confidence index corresponding to the “reliable” confidence level confirming the state Ej, • Ni, very reliable is the number of users associated with a confidence index corresponding to the confidence level “ very reliable ”confirming the state Ej.

Thus, in the example described here, the contribution of unreliable users is not taken into account in the calculation of the reliability coefficients since the corresponding confidence index IC is zero. Those skilled in the art will understand, however, that values other than those presented here are possible for untrusted users, and that the proposed method is not limited to particular values of confidence index associated with confidence levels. It may therefore be envisaged to implement the proposed method, in another embodiment, taking into account the contribution of unreliable users in the calculation of the reliability coefficients.

In an embodiment in which all of the possible states of an incident include an “erroneous incident” state or equivalent, in the absence of reception of incident tracking data from a user selected during the 'After a predetermined period of time, the reliability coefficient of the "erroneous incident" state may be increased by the confidence index IC of the user in question. Thus, if a selected user has not sent, via a user terminal, incident tracking data after a predetermined period of time, or if the incident tracking data has not been received by system 5, the reliability coefficients will be calculated as if the user had sent, via a user terminal, incident tracking data including data indicating the "erroneous incident" state. In other embodiments, a selected user whose incident tracking data has not been received by the system 5 may not be taken into account, in particular in the calculation of the reliability coefficient of the state "Erroneous incident".

In one or more embodiments, the reliability coefficient of the “erroneous incident” state may be increased by the confidence index of a user who has not sent, via a user terminal, tracking data for incident (or not received by the system 5) when the user has been selected by the processing unit 27 as a function of the incident data, for example as a function of the geolocation of the incident. In such an embodiment, the reliability coefficient of the “erroneous incident” state is not increased by the confidence index of a user whose incident tracking data has not been received by the system 5 in the case where the user has been selected only because the terminal data of this user are representative of an active mode.

In one or more embodiments, the predetermined period of time depends on the level of urgency of the incident. Alternatively or in parallel, the predetermined period of time is a function of an average distance between the respective geographic locations of the respective user terminals of the selected users and the geolocation of the reported incident.

For example, the predetermined period of time for an incident considered urgent is of the order of a few hours. For example, the predetermined period of time for an incident considered to be non-emergency is a few days.

Again with reference to FIG. 1, the processing unit 27 updates (S7) the state of the incident in the first database 23. The updating (S7) of the state of the incident advantageously allows, depending on the embodiment, for example according to the frequency of sending requests for return requests on incident REQ, monitoring of the incident, possibly in real time. In one or more embodiments, the update of the incident state takes account of one or more of the respective reliability coefficients determined for each state of the set of states.

In one or more embodiments, the processing unit 27 can use for this update a maximum score determined as follows:

Maximum score = ^ answers

Σ ^ic ®

1 = 1 where:

• Answers is the number of user transmitters, via a user terminal, of incident tracking data, and • IC (j) is the confidence index of the j-th user transmitter, via a user terminal, of incident tracking.

The state of the incident in the first database 23 is updated with state E, if the reliability coefficient of state Ej is greater than a predetermined value based on the maximum score. For example, the state of the incident recorded in the first database 23 is updated with the state Ej if the reliability coefficient Ci of the state Ej checks:

> Maximum score /

For example, with reference to the particular case developed previously to illustrate the operations of FIG. 3 and in a case in which all the selected user terminals, and only the selected user terminals, send a response to the system 5, the score maximum can be calculated as follows:

Maximum score = 16Z * 0 + 8Z * 0.25 + 4Z * 0.5 + 2Z * 1 + Z * 2 = 8Z

In the event that no determined reliability coefficient exceeds the predetermined value, the status of the incident may not be updated.

At the end of iteration of the request sending loop, the processing unit 27 determines (S8) whether the state of the incident, possibly updated, corresponds to one or more predetermined states (for example a state "Incident resolved" or equivalent), called "loop output states", and determines whether the number of cycles for sending requests for return requests on incident REQ is greater than or equal to the maximum number M of cycles.

If the incident state is not a loop exit state (for example if the incident state is not, after update, the "incident resolved" state), and if the number of cycles of emission of return requests on incident REQ is strictly less than the maximum number M of cycles, a new iteration of the loop of emission of requests for return on incident REQ is undertaken, with an index k of iteration of an incremented loop (S9), an iteration which includes sending (S5) incident feedback requests, receiving (S6) incident tracking data, and possibly updating (S7) the status of the incident in the first database 23. When the incident state, after updating, is a loop exit state, or when the index k of the loop iteration is equal to the maximum number M of REQ incident return request transmission cycles, the loop ends.

In one or more embodiments, if the incident state is not a loop exit state and if the number of cycles of transmission of incident feedback requests REQ is strictly less than the maximum number M of cycles, the process can loop back not on a new iteration of the loop, but on a new selection (S3) of users and an initialization (S4) of a new loop for sending requests for incident feedback REQ.

In one or more embodiments, when the loop is finished the incident is archived (S 10) in the first database 23. The loop being finished, the transmission of requests for return on incident REQ concerning this incident is therefore stopped.

In one or more embodiments, when the loop is terminated for an incident, the confidence index IC of at least one user who sends, via a user terminal, incident tracking data is updated (Sll) . This update may take into account data indicating an incident status which has been reported by the user in the incident tracking data, and the status of the incident archived. As a result, a user's IC Confidence Index can be updated based on their contribution to the verification, tracking and resolution of the incident. For example, if a user has issued incident tracking data that includes data indicating a "faulty incident" status or that has been treated as corresponding to a "faulty incident" status or equivalent, while the incident is archived with another state (such as for example the “incident resolved” state), the user's confidence index IC may be reduced. Conversely, if a user has sent, via a user terminal, incident tracking data comprising data indicating a “resolved incident” state or equivalent, and the incident is archived with the same state, the the user's CI confidence index may be increased.

In one or more embodiments, the confidence index IC of the user 3 which is the source of the incident report data is also updated.

In other embodiments, the confidence index IC of a user is updated each time the incident state is updated as a function of the data designating an incident state included in the data of user terminal incident and reliability coefficient calculated for this state.

The proposed method has several advantages.

First, the selection of user terminals based on the geographic location of the terminals and the geolocation of the incident optimizes the chances of verification and resolution of an incident. This optimization in the selection of user terminals also allows savings in bandwidth by using only the user terminals likely to be relevant, thus avoiding the influx of responses from irrelevant user terminals.

In addition, the reassessment of the confidence indexes of the user terminals which contributed to the follow-up of the incident allows the system 5 to be learned intelligently by constant improvement of the second database 25.

Finally, archiving incidents in another database, the first database 23, makes it possible to avoid clogging up the databases and to have a reliable history concerning the various incidents dealt with.

The proposed method can be implemented using software and / or hardware components. In this perspective, the terms “module” and “unit” can correspond in this document as well to a software component, as to a hardware component or to a set of hardware and / or software components, able to implement a function or a set of functions, as described for the module or unit concerned.

A software component corresponds to one or more computer programs executable by a processor, one or more subroutines of a program, or more generally to any element of a program or software. Such a software component is stored in memory then loaded and executed by a data processor of a physical entity (multimedia gateway, user equipment, terminal, etc.) and is capable of accessing the hardware resources of this physical entity (memories, recording media, communication bus, electronic input / output cards, user interfaces, etc.).

Likewise, a hardware component corresponds to any element of a hardware (or hardware) set. It can be a programmable hardware component or with an integrated processor for running software, for example an integrated circuit such as an integrated circuit for specific application ASIC (acronym for "ApplicationSpecific Integrated Circuit"), a system on a chip SOC (English acronym for "System On Chip"), a smart card, an electronic card for executing firmware, etc.

SOCs are embedded systems that integrate all the components of an electronic system into a single chip. An ASIC is a specialized electronic circuit that brings together functionalities tailored to a given application. ASICs are generally configured during their manufacture and can only be simulated by the user.

A data processing method as proposed can also use hybrid architectures, such as for example architectures based on a CPU + FPGA, a GPU (acronym for "Graphies Processing Unit") or MPPA (acronym for "Multi- Purpose Processor Array ”).

The proposed method can also be implemented in the form of a combination of software and hardware elements, such as for example a software program intended to be loaded and executed on a component of type FPGA programmable logic circuits (acronym for "Field Programmable Gâte Array ”). FPGAs are user-reconfigurable electronic circuits.

Depending on the embodiment chosen, certain acts, actions, events or functions of each of the methods described in this document may be performed or occur in a different order from that in which they have been described, or may be added, merged or not be performed or not occur, as the case may be. Furthermore, in some embodiments, certain acts, actions or events are performed or occur concurrently and not successively.

Although described through a number of detailed exemplary embodiments, the proposed encoding method and the equipment for implementing the method include various variants, modifications and improvements which will become apparent to those skilled in the art. the art, it being understood that these different variants, modifications and improvements form part of the scope of the invention, as defined by the claims which follow. In addition, different aspects and features described above can be implemented together, or separately, or substituted for each other, and all of the different combinations and sub combinations of the aspects and features are within the scope of the invention. In addition, some systems and equipment described above may not incorporate all of the modules and functions described for the preferred embodiments.

Claims (11)

1. Method for processing incident data implemented by a processing unit, the method comprising: a) on receipt of incident reporting data comprising incident presence data and incident geolocation data, store incident data relating to the incident in a first database, the data incident comprising data representative of a geolocation of the incident and of an incident state selected from a predefined set of states, the incident data being a function of the incident report data received, b) select one or more users according to user profile data corresponding respectively to users, and according to incident data, the user profile data being stored in a second database, c) issue an incident return request to at least one selected user, the incident return request comprising at least part of the incident data, and d) update the incident status in the first database according to incident tracking data received from at least selected users. 2. Method according to claim 1, in which the predefined set of states comprises at least one "unresolved incident" state, a "resolved incident" state and a "faulty incident" state. 3. The method as claimed in claim 2, in which the transmission of incident return request and the updating of the incident state are repeated as long as the state of the incident after updating is not not the "incident resolved" state. 4. The method of claim 3, wherein the method is interrupted if the number of repetition cycles of the transmission of incident feedback request and the update of the incident state reaches a predetermined number. 5. Method according to one of the preceding claims, in which the user profile data corresponding to a user comprises data representative of a geographic location of a user terminal of the user. 6. Method according to one of the preceding claims, in which the user profile data corresponding to a user comprises data representative of a confidence index of said user. 7. The method as claimed in claim 6, in which a reliability coefficient is calculated for each state of the set of states following reception of the incident tracking data, the reliability coefficient of a state being a function of the number of users having transmitted incident tracking data representative of said state and of the respective confidence index of said users. 8. Method according to claim 7, in which the reliability coefficient of a state Ej is defined by: NOT; Ci = ^ ic (j) j = i where: • Ci is the reliability coefficient for the state Ej, • Ni is the number of users who sent incident monitoring data which include monitoring data representative of the state E _i5 and • IC (j) is the confidence index of the jth user who sent incident tracking data representative of the state Ej. 9. The method according to claim 7 or 8, in which the predefined set of states comprises at least one “incident not resolved” state, a “incident resolved” state and a “faulty incident” state and, in the absence of reception of incident tracking data associated with a selected user after a predetermined period of time, the reliability coefficient of the “erroneous incident” state is increased by the confidence index of said user. 10. Computer program characterized in that it includes instructions for the implementation of the method according to one of claims 1 to 9, when this program is executed by at least one processor. 11. Incident data processing system comprising: a communication module adapted to receive incident reporting data, a first database adapted to store incident data relating to the incident, a second database data suitable for storing user profile data corresponding respectively to users, and a processing unit comprising a processor, operatively coupled to the communication module and to the first and second databases, wherein the communication module, the first and second databases and the processing unit are further adapted to implement a method according to any one of claims 1 to 9.