EP3899747A1

EP3899747A1 - Incident reporting method and structure

Info

Publication number: EP3899747A1
Application number: EP19842812.0A
Authority: EP
Inventors: Erwan Froc; Apostolos Kountouris
Original assignee: Orange SA
Current assignee: Orange SA
Priority date: 2018-12-21
Filing date: 2019-12-13
Publication date: 2021-10-27
Also published as: WO2020128252A1; FR3090930A1; US20220078597A1

Abstract

The invention concerns an incident reporting method implemented by computer means. The method comprises: - generating, at a processing structure (9), a piece of incident reporting information (INF) depending on incident reporting data (SIGN) relative to the incident and generated at one or more user terminals (7) and comprising at least geolocation data of the incident, - selecting one or more recipients (3) of the received incident reporting data depending on the incident reporting data, the recipient or recipients being selected from a database (29) of recipients of the processing structure, and - transmitting the incident reporting information to the selected recipient or recipients.

Description

Incident reporting process and structure

The field of the invention relates to methods and structures for processing incident reporting data with the aim of ensuring the routing of information relating to the reported incident to the competent persons capable of ensuring the 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.

Reporting and recording incidents collaboratively therefore presents a major challenge for smart cities. In addition, the resolution of an incident requires that the data relating to the incident in question collected by citizens be forwarded to a recipient capable of resolving this type of incident. Indeed, on the scale of a city for example, the different administrations and different services often have clearly delimited areas of intervention and are therefore assigned to the resolution of certain very specific tasks. Data collection cannot therefore be effective without data processing intended to establish the exact nature of an incident and, therefore, the appropriate recipient of the data relating to the reported incident.

The present invention improves the situation. To this end, there is proposed a method for processing incident reporting data implemented by computer means. The targeted process includes:

- generate, at a processing structure, incident reporting information as a function of incident reporting data relating to an incident, the incident reporting data being generated at one or more terminals user and including at least geolocation data for the incident in question,

- select, according to the incident reporting information, one or more recipients of the incident reporting information from a recipient database of the processing structure, and

- transmit the incident reporting information to the selected recipient (s).

According to one aspect of the invention, at least part of the incident reporting data is generated via an application executed on the user terminal.

According to another aspect of the invention, the incident reporting data also comprises data entered by a user of the user terminal via the application.

According to another aspect of the invention, the incident reporting data includes data relating to multimedia content generated using the user terminal.

Advantageously, according to another aspect of the invention, the multimedia content is analyzed at the level of the processing structure using an object recognition software, data generated by said object recognition software being added. incident reporting data.

According to another aspect of the invention, the geolocation data of the incident is determined automatically and corresponds to a current position of the user terminal.

According to another aspect of the invention, the processing structure comprises an incident database in which the reported incident (s) are stored as well as the respectively associated incident reporting data, the reporting data received incidents being analyzed to determine, by comparison with the incident reporting data previously stored in the incident database, whether the incident reporting data relates to an incident already stored in the incident database incidents so that:

- if the incident reporting data received relates to an incident stored in the incident database, the incident reporting data in question is associated within the incident database with the corresponding incident;

- otherwise, a new incident associated with the received incident reporting data is stored in the incident database.

According to another aspect of the invention, in the case where at least part of the incident reporting data is generated via an application executed on the user terminal, a user accesses the application by logging into a user account which specific to it, and the incident reporting data includes a user account identifier sending the incident reporting data, this identifier being associated within a database of users of the processing structure with an index confidence, and in which a reliability coefficient is calculated by the processing structure for each reported incident based on the confidence index of the user account (s) issuing incident reporting data relating to the incident, the coefficient of an incident's reliability being updated each time incident reporting data relating to the reported incident is received.

According to another aspect of the invention, the generation of the incident reporting information and the selection of the recipient (s) of the incident reporting information relating to an incident are implemented if and only if the coefficient reliability of the incident is greater than or equal to a predetermined threshold.

According to another aspect of the invention, an incident and the incident reporting data associated with this incident are deleted from the incident database if the reliability coefficient of said incident is less than the predetermined threshold after 'a predetermined period of time.

According to another aspect of the invention, a completeness coefficient is calculated by the processing structure for each reported incident according to a precision criterion concerning the reporting data relating to said incident, the completeness coefficient being a binary variable taking the value 0 when the precision criterion is not satisfied and taking the value 1 when the precision criterion is satisfied, the generation of the incident reporting information and the selection of the recipient (s) of said reporting information d incident related to an incident are implemented if and only if the completeness coefficient of said incident is equal to 1. According to another aspect of the invention, the incident reporting information is made available to the recipient or recipients selected via a web portal with personalized content adapted to each recipient.

Recipients can provide an opinion on the relevance of the alerts made available, in order to refine the process of matching alerts and potential recipients. Such a notice can be provided, for example, via a form in which for each alert made available, a score of 0 to 3 is assigned by a recipient who has received the alert in question.

According to an implementation characteristic of the invention, the recipient (s) are determined automatically via a computer device, such as a learning machine. Such a characteristic makes it possible to combine the incident selection history with a semantic analysis of the profiles of potential recipients.

According to another aspect of the invention, the reporting information includes data relating to an incident type selected from a pre-established list of incident types, each recipient identified in the recipient database being associated with a or more incident types from the pre-established list of incident types.

The invention further relates to a computer program comprising instructions for implementing the method described above, when the instructions are implemented by at least one processor.

Finally, the invention relates to an incident reporting data processing structure arranged to generate incident reporting information as a function of incident reporting data relating to this incident, the incident reporting data being generated by one or more user terminals and comprising at least geolocation data of the incident. Furthermore, the processing structure is further arranged to select, according to the incident reporting information, one or more recipients of the incident reporting information, the processing structure comprising a database recipients from which the recipient (s) are selected. Finally, the processing structure is further arranged to transmit the incident reporting information to the selected recipient (s). 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 incident reporting data processing system according to the invention; and

- Figure 2 illustrates a method of processing incident reporting data according to the invention.

FIG. 1 illustrates an incident reporting data processing system, hereinafter system 1 and an information system 3. In the example illustrated, a web portal 5 makes it possible to access information relating to one or more several incidents reported.

System 1 is arranged to generate and process incident reporting data. The system 1 is further arranged to ensure the routing of information relating to the reported incidents to one or more recipients, for example the information system 3, so as to facilitate the resolution of the reported incidents by ensuring that the information relating to a given incident are forwarded to the appropriate recipients.

The system 1 comprises one or more user terminals, here a user terminal 7, and an incident reporting data processing structure, hereinafter processing structure 9.

The user terminal 7 is adapted to report an incident to the processing structure 9. More precisely, the user terminal 7 allows a user in his possession to report an incident by generating and transmitting data for reporting the incident to the processing structure 9. The incident reporting data includes at least incident geolocation data.

In one or more embodiments, the user terminal 7 is adapted to automatically determine the geolocation data of the incident. The geolocation of the incident then corresponds to a current position of the user terminal 7. The current position of the user terminal 7 is for example automatically determined by a server connected to a network to which the user terminal 7 is connected. Alternatively, the user terminal 7 comprises a geolocation module, for example of the GPS type (English acronym for “Global Positioning System”) or of the Galileo type. Generally, an incident is a car accident, fire, deterioration of the roadway or any other localized event that can be reported. An incident can also relate to a malfunction, for example delays, of a public or private transport service provider.

As illustrated in FIG. 1, the user terminal 7 comprises a man / machine interface 11, an image capture unit 13, a processing unit 15 and a communication module 17.

The Human / Machine interface 11 is adapted to allow the user in possession of the user terminal 7 to generate data relating to the incident that he wishes to report to the processing structure 9.

For example, at least part of the incident reporting data is generated via an application running on the user terminal 7. The user can access this application by logging into a user account. It is understood here that in one or more embodiments, a user wishing to participate in the reporting of incidents can do so by running a client application on the user terminal 7 (for example native or web application executed on a smartphone or a tablet, or web- application executed by means of a Web browser on a personal computer (of the PC type, for “Personal Computer”)), and using a user account of its own to connect to a server application. 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 terminal such as the user terminal 7 may require user registration and the provision of data such as a mobile number, a password or personal data such as than his home address.

Each user account is associated with a unique identifier. Such an identifier makes it possible, as explained below, to determine from which user account the reporting data were generated. Another way of seeing things is to consider that, advantageously, the identifier of the user account from which the user has reported an incident and provided information on this incident is part of the incident reporting data and generated. With the help of this application, the user can, for example, enter or inform at least part of the incident reporting data. In other words, the Human / Machine interface 11 and the application executed on the user terminal 7 allow the user in possession of the user terminal 7 to generate at least part of the incident reporting data himself.

For example, the Human / Machine interface 11 is then adapted to allow the user to specify a level of urgency for the incident. For example, the Human / Machine interface 11 makes it possible 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 Man / Machine interface 11. Alternatively, the Man / 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.

Thus, the level of urgency of the incident or the type of incident are possible examples of data included in the incident reporting data and generated by the user terminal 7. This data can in particular be entered and entered by the user in possession of the user terminal 7 by executing an application.

Furthermore, as explained above, the reporting data includes geolocation data of the incident determined automatically by the user terminal 7 and corresponding to a current position of the user terminal 7. However, alternatively, the user terminal 7 is adapted to allow the user to inform, for example via the application running on the user terminal 7, the geolocation of the incident.

The image capture unit 13 is adapted to generate multimedia content such as video content or a photograph. In one or more embodiments, the incident reporting data includes data relating to multimedia content generated using the user terminal 7, and more precisely therefore using the image capture unit 13. For example, a functionality of the application executed on the user terminal 7 allows the user to add multimedia content, therefore video content and / or one or more, to the data entered. photographs.

The processing unit 15 is adapted to generate incident reporting data SIGN.

As previously explained, the SIGN incident reporting data includes at least incident location data.

Furthermore, with reference to the embodiments mentioned above, the incident signaling data SIGN can further comprise data relating to the level of urgency of the incident and / or data relating to the type of the incident and / or multimedia content. In general, SIGN incident report data may include any type of data relating to the nature of the incident and which may be useful in resolving the incident.

Advantageously, the incident report SIGN data also includes an identifier of the user account from which the user of the user terminal 7 has reported the incident via the application executed on the user terminal 7.

As illustrated in FIG. 1, the processing unit 13 comprises a memory 19 and a processor 21.

The memory 19 is configured to store instructions from a computer program whose execution by the processor 21 results in the operation of the processing unit 15 for the implementation of the method for processing incident report data. proposed, and more specifically the generation of SIGN incident reporting data.

Advantageously, the memory 19 is further configured to store an address of the processing structure 9 for the routing of incident signaling data SIGN to the corresponding processing structure 9. Furthermore, the memory 19 can also be configured to store an identifier of the user account to which the user of the user terminal usually connects. Of course, the identifier of the user account can also be extracted from it, from time to time, when a user logs into his user account via the user terminal 7. Thus, in the case where a new user uses the user terminal 7 to connect to a user account different from the user account to which the regular user of the user terminal 7 connects, the identifier of this new user account can be extracted, possibly stored in the memory 19, and integrated with SIGN incident reporting data.

The communication module 17 is adapted to transmit the incident signaling data SIGN to the processing structure 9. The incident signaling data SIGN is for example transmitted to the processing structure 9 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 radio networks, cellular or non-cellular, and that depending on the embodiment, the communication module 17 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 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.

The processing structure 9 is arranged to generate an incident reporting information as a function of the incident reporting data SIGN relating to the incident in question. Furthermore, the processing structure 9 is further arranged to select, as a function of the incident reporting information, one or more recipients of the incident reporting information. In other words, the processing structure 9 is arranged to analyze the incident report signal data SIGN received from the user terminal (s), such as the user terminal 7, and to apply processing to the report data SIGN incident to send the incident report to the appropriate recipients, in the form of the reporting information, to facilitate resolution of the incident. As illustrated in FIG. 1, the processing structure 9 comprises a communication module 23, an incident database 25, a user database 27, a recipient database 29 and a processing unit 31.

The communication module 23 is adapted to receive incident signaling data SIGN transmitted by the user terminal 7, and more precisely by the communication module 17 of the user terminal 7. Advantageously, the communication module 23 is adapted to receive SIGN incident report data transmitted by several user terminals such as user terminal 7.

The communication module 23 is further adapted to communicate with several recipients. The communication module 23 communicates for example with the information system 3 via a network (not shown in the figure). In particular, the communication module 23 is suitable for transmitting the incident reporting information INF generated by the data processing structure 9 to one or more recipients. Such a network is for example a MAN type network.

Furthermore, as explained in the following description, the communication module 23 can be arranged in addition to transmit the incident reporting information INF to one or more recipients via the web portal 5.

Those skilled in the art can appreciate that 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 23 can 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.

The incident database 25 is adapted to store the reported incident or incidents as well as the incident reporting data SIGN associated with the reported and stored incidents. It is understood here that the incident database 25 is configured so that the incident reporting data SIGN received from terminals users such as the user terminal 7 are grouped by incident so that each reported incident is listed in the incident database 25 in association with the incident reporting data SIGN relating thereto.

It is understood that the incident database 25 is configured to be updated as a function of the incident signal reporting data SIGN received. Furthermore, and as developed in the following description, an incident and the incident report data SIGN associated with it can be deleted from the incident database 25 under certain conditions, in particular when the report data SIGN incidents received relating to an incident are not sufficiently reliable, reliability being estimated by the processing structure 9 on the basis of a confidence index of each user account reporting the incident. It is understood that, in this embodiment, each incident listed in the incident database 25 is associated with a reliability coefficient capable of being updated.

Furthermore, advantageously, an incident and the incident report data SIGN associated with it can be deleted from the incident database 25 when the incident is resolved.

Furthermore, in one embodiment, a reported incident may be associated with a completeness coefficient characterizing the sufficiency or insufficiency of the information reported concerning the reported incident in question. In other words, such a completeness coefficient characterizes the fact that the information obtained concerning a reported incident is sufficient or not to resolve this incident.

The completeness coefficient is calculated by the processing structure for each incident reported according to a precision criterion concerning the reporting data relating to this incident. For example, the completeness coefficient is a binary variable taking the value 0 when the precision criterion is not satisfied and taking the value 1 when the precision criterion is satisfied.

The user database 27 is adapted to store the identifier of one or more user accounts such as the user account from which the user of the user terminal 7 has reported an incident. Advantageously, the user database 27 is further adapted to store, in association with each of the stored identifiers, a confidence index. It is therefore understood that, within the user database 27, each identifier of a user account is associated with a confidence index.

The recipient database 29 is adapted to store one or more recipients. It is understood here that the recipient database 29 includes one or more identifiers, each identifier being associated with a potential recipient of incident reporting information INF generated by the processing structure 9.

Furthermore, the recipient database 29 is further adapted to store, in association with each recipient stored in the recipient database 29, an address of the recipient considered. This address then allows the communication module 23 to route the incident reporting information INF generated to the selected recipients.

In one or more embodiments, the recipient database 29 is adapted to store, in association with each stored recipient, one or more types of incident. Typically, the different incident types associated with the recipients within the recipient database 29 form part of the pre-established list of incident types offered to a user wishing to report an incident using his user terminal.

Advantageously, each recipient is also associated, within the recipient database 29, with a geographical area. It is understood that such a geographic area corresponds to a possible area of intervention of the recipient.

The processing unit 31 is arranged to generate incident reporting information INF as a function of the incident reporting data SIGN relating to the incident in question.

The INF incident reporting information includes data allowing recipients to have at their disposal the elements necessary to resolve the reported incident. For example, the INF incident reporting information includes a geolocation of the incident. Still as an example, the INF incident reporting information may further include the type of reported incident selected from the pre-established list of incident types. Furthermore, as explained above, the incident reporting data SIGN can also comprise multimedia content generated by the user terminal 7 using the image capture unit 13. The processing unit 31 is then further arranged to analyze, using object recognition software, the multimedia content transmitted. The processing unit 31 then appends the data generated by the object recognition software to the incident reporting data SIGN.

The processing unit 31 is further arranged to select, as a function of the incident reporting information INF generated, one or more recipients of the incident reporting information INF within the recipient database 29 of the processing structure 9.

The selection of recipients for INF incident reporting information depends on the type of incident reported. As explained above, each recipient stored in the recipient database 29 is associated with one or more types of incidents. The types of incident with which a recipient is associated corresponds to the types of incident which he is capable of resolving and which fall within his area of intervention. In addition, the selection of recipients may also depend on the geolocation of the reported incident.

The processing unit 31 includes a memory 33 and a processor 35.

The memory 33 is configured to store instructions of a computer program whose execution by the processor 35 results in the operation of the processing unit 31 for the implementation of the method for processing incident report data. proposed, and more specifically the generation of INF incident reporting information.

In one or more embodiments, the memory 33 is further configured to store the pre-established list of incident types.

The information system 3 is arranged to receive the incident reporting information INF generated and transmitted by the processing structure 9. Typically, in the context of the present invention, the information system 3 designates computer resources of collection of information, here INF incident reporting information, from an administration or a service provider, whether this provider is a public or private body. We understand here that the architecture illustrated in Figure 1 allows this administration or this service provider to become aware of an incident reported by one or more users using their user terminals and processed then forwarded by the processing structure 9.

For example, the information system 3 is that of a transport service provider and the incident reporting information INF makes it possible to report a delay and to provide the elements necessary for the management and resolution of this late. Still by way of example, information system 3 is that of a fire station and the INF reporting information makes it possible to report a fire and to supply the elements necessary to manage this fire.

Furthermore, in one or more embodiments, the incident reporting information INF can also be made available to the recipient or recipients selected by the processing structure 9 via the web portal 5. The web portal 5 has content personalized and adapted to each recipient.

It is understood here that each information system such as the information system 3 can access the incident reporting information by accessing the web portal 5. For example, the administration or the service provider to which the information system 3 can access web portal 5 by logging in via a user account. Access to this user account may involve the use of an identifier, specific to information system 3, and a password. The web portal 5 is then personalized in that the incidents reported may be different from one information system to another.

Such a system can also proactively identify an entity, such as an administration, an association, a public service, etc., and offer it access to reports that may be within its scope of responsibility. For example, reports relating to bus shelters (deterioration, malfunctions etc.) in a region considered may be offered, by sending an electronic mail (email) containing a link to the data associated with the reports to specialized companies in this region, for example an organization which manages public transport, a company which exploits advertising space, as well as the municipal police (in particular in cases of vandalism). Subsequently, these recipients of such e-mails can consult, for example, a web page whose link is contained in the email, and both annotate the relevance of the reports and retrieve the relevant reports. These new recipients can advantageously refine the selection of incidents that fall within their areas of competence (categories of relevant reports).

A method for processing GIS incident reporting data will now be described with reference to FIG. 2.

In the context of the invention, an incident occurs for example in a city. This incident could be a fire, a car accident, a deterioration of the road surface or any other type of incident. The users witnessing this incident want this incident to be resolved as soon as possible and each have a user terminal such as user terminal 7.

During a step SI, the user terminal 7 generates incident report data relating to the incident observed. For example, the user in possession of the user terminal 7 runs an application, for example a native application or a web application, enabling him to enter and fill in data relating to the incident.

Using this application, the user specifies for example the urgency level of the incident as well as the type of incident observed. As explained previously, the user can select the type of incident using a drop-down menu presenting him with a pre-established list of potential incidents or use a free text option to describe the incident he wishes to report. .

Still during this step, the user can use the image capture unit 13 of the user terminal 7 to generate multimedia content relating to the incident observed. This multimedia content corresponds, for example, to video content or to photographs or to a combination of the two. The multimedia content thus obtained then forms part of the incident reporting data SIGN.

Furthermore, as explained above, the user of the user terminal 7 reports the incident, for example by running an application dedicated to the reporting of an incident and by logging into a user account of their own. In such a case, therefore, the incident reporting data SIGN can also comprise an identifier of the user account from which the user of the user terminal 7 has reported the incident.

During a step S2, the user terminal 7 automatically generates geolocation data for the incident. This geolocation data corresponds to a position current of the user terminal 7. As explained above, the current position of the user terminal 7 is for example determined by a server connected to a network to which the user terminal 7 is connected or by a geolocation module included in the user terminal 7.

Alternatively, the geolocation of the incident can be entered by the user himself using the application running on the user terminal 7.

This incident geolocation data is integrated with the SIGN incident reporting data.

During a step S3, the communication module 17 of the user terminal 7 sends the incident signaling data SIGN to the processing structure 9. The incident signaling data SIGN is sent to the structure of processing 9 using the address of the processing structure 9 stored in the memory 19 of the processing unit 15 of the user terminal 7. The incident signaling data SIGN are for example sent to the structure 9 through a MAN type network.

During a step S4, in the case where the incident signaling data SIGN comprises multimedia content, the processing unit 31 of the processing structure 9 analyzes the multimedia content using recognition software of objects. The use of object recognition software allows marking (better known under the English term "tagging") of the various objects or elements present on the images of the multimedia content, whether it is video content or photographs. The marking thus makes it possible to automatically determine areas of interest in an image and, by comparison with an object bank, stored for example in memory 33, to generate additional data relating to the reported incident. Such data allow, for example, to increase the accuracy of the geolocation of the incident, to estimate the magnitude of the incident, its level of urgency or any other information useful for determining the type of the incident and for its resolution.

During this step, the data generated by the object recognition software is added to the SIGN incident report data, the latter thus being enriched. During a step S5, the processing structure 9 analyzes the incident signaling data SIGN received, and potentially enriched during the step S4 using the object recognition software, to determine, by comparison with the incident reporting data previously stored in the incident database 25 if the received incident reporting data SIGN relates to an incident already stored in the incident database 25.

This comparison can be implemented in several ways. First of all, the processing structure 9, and more particularly the processing unit 31, can compare the geolocation data included in the incident report data SIGN received with the geolocation data included in the report data d incident already stored. In this way, it is possible to rule out incidents where the geolocation data does not coincide with that of the SIGN incident data analyzed.

Furthermore, once the incidents already stored have been determined which are geographically compatible with the new incident report data SIGN received, the processing unit 31 can compare the type of incident with the type of each incident already stored. The comparison can also be based on the data generated by the object recognition software by seeking a correlation between objects detected in the multimedia content of the new incident incident signal data SIGN and objects already detected for the multimedia content. incident reporting data already stored in the incident database 25.

During a step S6A, if the incident report signal SIGN data received relates to an incident already stored in the incident database 25, this incident report signal data SIGN is associated within the database. incident data 25 to the corresponding incident.

Alternatively, during a step S6B, a new incident associated with the received incident reporting data is stored in the incident database 25.

As explained above, in one or more embodiments, the incident report data SIGN transmitted by the user terminal 7 comprises an identifier of the user account from which the user of the user terminal 7 has reported the incident. Furthermore, within the user database 27, each user account identifier is associated with a confidence index.

Thus, during a step S7, the processing unit 31 determines the confidence index associated with the identifier of the user account sending the incident report data SIGN, that is to say in the case described here, the identifier associated with the user account to which the user of the user terminal 7 has connected and has, from the application executed, reported the incident.

Furthermore, as explained above, each incident listed in the incident database 25 is associated with a reliability coefficient. Such a reliability coefficient makes it possible to characterize the reliability of the reported incident and, thus, to avoid potentially reporting an incident that does not exist.

Thus, during step S8, the processing unit 31 of the processing structure 9 updates the reliability coefficient of the incident to which the incident reporting data SIGN received relates as a function of the index of trust associated with the user account issuing this SIGN incident report data. Of course, in the case where the SIGN incident report data corresponds to a new incident, the confidence index makes it possible to initialize the reliability coefficient associated with this new incident. In other words, the processing structure 9 calculates, for each reported incident, a reliability coefficient as a function of the confidence index of the user account or accounts sending the incident reporting data relating to the incident under consideration.

During a step S9, the reliability coefficient of the reported incident is compared with a predetermined threshold. This predetermined threshold is for example stored in the memory 33 of the processing unit 31.

Furthermore, alternatively or in parallel, it is also possible to define other conditions which the reported incident must verify during this step S9. For example, in addition to or instead of the condition relating to the reliability coefficient of the incident, the processing structure can determine a completeness coefficient characterizing the sufficiency or insufficiency of the information reported concerning the reported incident. For example, this completeness coefficient is a binary variable taking the value 0 when the information reported by the different users, and more exactly the different user accounts, are not sufficient to resolve the reported incident or the value 1 when the information reported is sufficient to resolve the reported incident.

For example, the completeness coefficient depends on the accuracy of the geolocation of the incident assessed by comparing the different geolocation data included in the SIGN incident report data relating to the incident in question.

Still by way of example, the completeness coefficient may depend on the precision concerning the type of incident reported. Indeed, as explained previously, the application executed by a user can leave the possibility to the latter to inform, via a free text option, the type of the incident in which case an uncertainty may exist on the type of the incident. , the qualification of the type of incident may vary from one user to another.

During a step S 10, implemented in the event that the reliability coefficient of the incident is greater than or equal to the predetermined threshold, the processing unit 31 generates incident reporting information INF relating to the incident considered. Furthermore, as explained above, a completeness coefficient can also be determined by the processing structure 9 so that, in this embodiment, step S 10 is only implemented if, in addition instead from the condition on the value of the reliability coefficient, the value of the completeness coefficient is satisfactory.

Thus, in the case where the completeness coefficient is a binary variable, the generation of the incident reporting information is implemented if and only if the incident completeness coefficient is equal to 1.

As previously explained, the INF incident reporting information includes the elements necessary to resolve the reported incident. Thus, the INF incident reporting information includes the geolocation of the incident as well as the type of incident selected from the pre-established list of potential incidents. Of course, other elements such as the level of urgency of the incident can be included in the incident reporting information.

During a step S1, consecutive to step S 10, the processing structure 9 and more precisely the processing unit 31, selects one or more recipients of the INF incident reporting information within the recipient database 29 based on the generated INF incident reporting information.

As explained above, each recipient is associated, within the recipient database 29, with one or more types of incident. For example, the recipients selected are the recipients associated with at least the type of incident reported. Furthermore, each recipient can also be associated with a geographic area within the recipient database 29 so that an additional criterion may consist in selecting only the recipients whose geographic area includes the geolocation of the incident. reported.

Of course, other embodiments are possible. Thus, a recipient can be selected by the processing structure 9 even if the geolocation of the incident is not in its geographical area if the level of urgency of the incident is low.

During a step S 12, the communication module 23 of the processing structure 9 transmits the incident reporting information SIGN to the destination or recipients selected. Furthermore, it should be noted that the address of each recipient is also stored in the recipient database 29, which subsequently makes it possible to route the incident reporting information SIGN. The incident reporting information INF is for example sent to the processing structure 9 via a network of the MAN type.

One can also envisage mechanisms for automatic determination of interested recipients, by the use of an artificial intelligence technique which, following a semantic analysis of reports and their attributes, would search for potential recipients without them are declared in advance, and thus proactively solicit them so that they can subscribe as a recipient organization or entity. It is also possible, depending on the embodiment chosen, that the information system can probe groups of users in order to use collective intelligence to determine the recipients. The information system can also provide modes of submission of opinions (feedbacks) by which the recipients can annotate the relevance of the reports which have been provided to them by the system; this allows to regulate the selection process continuously. Thus, the system can propose new types of reports at random to allow the discovery of new associations between types of report and corresponding recipients.

As previously explained, INF incident reporting information can be transmitted directly to the recipient. In the example illustrated in FIG. 1, the recipient of the incident reporting information INF is the information system 3. The information system 3 is typically the information system of an administration or a service provider responsible for resolving incidents such as the incident reported via the SIGN incident reporting information.

Furthermore, the incident reporting information can also be used to update the web portal 5, and more precisely the personalized content of the web portal 5 reserved for the administration or the service provider to which the data system is attached. 'information 3. Thus, by accessing his user account, an authorized employee of the administration or of the service provider has access to information relating to an incident reported and relating to his area of intervention. The steps S 10, SU and S 12 described above are implemented when the reliability coefficient of the reported incident is greater than or equal to the predetermined threshold. However, in the case where the reliability coefficient is lower than the reliability coefficient, the steps described below are implemented by the processing structure 9.

In one or more embodiments, storing a new incident in the incident database 25 triggers a predetermined period of time. Thus, if at the end of this predetermined period of time, the reliability coefficient of the reported incident is not greater than the predetermined threshold, the incident and the incident reporting data associated with it are deleted from the incident database 25.

The processing unit 31 is for example provided with a clock (not shown in FIG. 1).

Thus, during a step S 13, in the case where the reliability coefficient is lower than the predetermined threshold, it is determined whether the predetermined period of time associated with the incident has elapsed or not. In a step S 14, if the predetermined period of time has elapsed, the incident and the incident reporting data associated with it are deleted from the incident database 25.

On the other hand, if the predetermined period of time has still not elapsed, the processing structure 9 remains awaiting the reception of new incident report data SIGN capable of modifying the reliability coefficient of the incident.

Those skilled in the art of course understand here that this constraint linked to the predetermined period of time triggered when the incident is stored in the incident database 25 is applied constantly. Thus, the processing structure 9 does not wait for the reception of new incident signaling data SIGN and the calculation of a new reliability coefficient to eliminate the incident if the predetermined period of time associated with it is over.

The present invention has several advantages.

First of all, the data structure allows efficient processing and routing, thus allowing intelligent reporting of the incident to the recipients affected by the reported incident, thus avoiding soliciting a recipient whose area of intervention is distinct. of the incident.

Then, the possibility of integrating multimedia content with incident reporting data and the marking of this multimedia content using character recognition software allows for more objective data collection than the data entered or entered by a user using the user terminal. The analysis of multimedia content also makes it possible to collect precise and useful information for the resolution of the incident.

Finally, the use of a web portal with personalized and updated content allows recipients, typically administrations or service providers, to be able to operate in a mode in which they can decide when to access incident reports and which ones. they wish to resolve as a priority.

Claims

1. Method for processing incident reporting data implemented by computer means, the method comprising:

- generate (S 10), at a processing structure (9), incident reporting information (INF) as a function of incident reporting data (SIGN) relating to said incident and generated at level d 'one or more user terminals (7) and comprising at least geolocation data of said incident,

- select (Sl l), as a function of said incident reporting information, one or more recipients (3) of the incident reporting information within a recipient database (29) of the structure processing, and

- transmit (S 12) the incident reporting information to said selected recipient (s).

2. The method of claim 1, wherein at least part of the incident reporting data is generated via an application running on the user terminal.

3. The method of claim 2, wherein the incident reporting data further comprises data entered by a user of the user terminal via the application.

4. Method according to one of the preceding claims, in which the incident reporting data comprises data relating to multimedia content generated using the user terminal.

5. Method according to claim 4, in which the multimedia content is analyzed (S4) at the level of the processing structure with the aid of object recognition software, data generated by said object recognition software. being added to the incident reporting data.

6. Method according to one of the preceding claims, in which the geolocation data of the incident are determined automatically and correspond to a current position of the user terminal.

7. Method according to one of the preceding claims, in which the processing structure comprises an incident database (25) in which the reported incident (s) are stored as well as the incident reporting data. respectively associated, the received incident reporting data being analyzed to determine (S5), by comparison with the incident reporting data previously stored in the incident database, whether said incident reporting data is relative an incident already stored in the incident database so that:

- if the incident reporting data received relates to an incident stored in the incident database, said incident reporting data is associated (S6A) within the incident database with the corresponding incident;

- otherwise, a new incident associated with the received incident reporting data is stored (S6B) in the incident database.

8. The method of claim 7 taken in combination with claim 2, wherein a user accesses the application by logging into a user account of his own, wherein the incident reporting data includes an account identifier user sending incident reporting data, said identifier being associated within a user database (27) of the processing structure with a confidence index, and in which a reliability coefficient is calculated by the processing structure for each reported incident based on the confidence index of the user account (s) issuing incident reporting data relating to said incident, the reliability coefficient of an incident being updated (S8) on each reception incident reporting data related to this incident.

9. Method according to claim 8, in which the generation of the incident reporting information and the selection of the recipient (s) of said incident reporting information relating to an incident are implemented if and only if the coefficient reliability of said incident is greater than or equal to a predetermined threshold.

10. The method as claimed in claim 9, in which an incident and the incident reporting data associated with said incident are deleted (S 14) from the incident database if the reliability coefficient of said incident is less than the predetermined threshold at after a predetermined period of time.

11. Method according to one of the preceding claims, in which a completeness coefficient is calculated by the processing structure for each reported incident according to a precision criterion concerning the reporting data. relating to said incident, said completeness coefficient being a binary variable taking the value 0 when the precision criterion is not satisfied and taking the value 1 when the precision criterion is satisfied, the generation of the incident reporting information and the selection of the recipient (s) of said incident reporting information relating to an incident are implemented if and only if the completeness coefficient of said incident is equal to 1.

12. Method according to one of the preceding claims, in which the incident reporting information is made available to the selected recipient or recipients via a web portal (5) with personalized content adapted to each recipient.

13. Method according to one of the preceding claims, in which the reporting information comprises data relating to an incident type selected from a pre-established list of incident types, each recipient stored in the recipient database. being associated with one or more incident types from said predetermined list of incident types.

14. Computer program comprising instructions for implementing the method according to one of the preceding claims, when said instructions are implemented by at least one processor.

15. Incident reporting data processing structure (9) arranged to generate incident reporting information (INF) based on incident reporting data (SIGN) relating to said incident and generated by one or more user terminals (7) and comprising at least geolocation data of said incident, said processing structure being further arranged for selecting, as a function of said incident reporting information, one or more recipients (3) of the information of incident reporting, said processing structure comprising a recipient database (29) from which said one or more recipients are selected, said processing structure being further arranged for transmitting incident reporting information to said or to said selected recipients.