WO2020128252A1 - Procédé et structure de signalement d'incident - Google Patents

Procédé et structure de signalement d'incident Download PDF

Info

Publication number
WO2020128252A1
WO2020128252A1 PCT/FR2019/053057 FR2019053057W WO2020128252A1 WO 2020128252 A1 WO2020128252 A1 WO 2020128252A1 FR 2019053057 W FR2019053057 W FR 2019053057W WO 2020128252 A1 WO2020128252 A1 WO 2020128252A1
Authority
WO
WIPO (PCT)
Prior art keywords
incident
data
reporting
database
user
Prior art date
Application number
PCT/FR2019/053057
Other languages
English (en)
Inventor
Erwan Froc
Apostolos Kountouris
Original Assignee
Orange
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange filed Critical Orange
Priority to EP19842812.0A priority Critical patent/EP3899747A1/fr
Priority to US17/416,157 priority patent/US20220078597A1/en
Publication of WO2020128252A1 publication Critical patent/WO2020128252A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/90—Services for handling of emergency or hazardous situations, e.g. earthquake and tsunami warning systems [ETWS]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/01—Social networking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G06Q50/26—Government or public services
    • G06Q50/265—Personal security, identity or safety
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/025—Services making use of location information using location based information parameters

Definitions

  • 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.
  • 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:
  • 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,
  • At least part of the incident reporting data is generated via an application executed on the user terminal.
  • the incident reporting data also comprises data entered by a user of the user terminal via the application.
  • the incident reporting data includes data relating to multimedia content generated using the user terminal.
  • 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.
  • the geolocation data of the incident is determined automatically and corresponds to a current position of the user terminal.
  • 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:
  • 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;
  • a new incident associated with the received incident reporting data is stored in the incident database.
  • the incident reporting data 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the recipient (s) are determined automatically via a computer device, such as a learning machine.
  • a computer device such as a learning machine.
  • 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.
  • 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).
  • FIG. 1 illustrates an incident reporting data processing system according to the invention
  • FIG. 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.
  • system 1 an incident reporting data processing system
  • information system 3 an information system 3.
  • 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.
  • 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.
  • 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.
  • GPS type English acronym for “Global Positioning System”
  • Galileo type Galileo
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the Human / Machine interface 11 is then adapted to allow the user to specify a level of urgency for the incident.
  • a level of urgency for the incident.
  • 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.
  • the Human / Machine interface 11 is adapted to allow the user to specify a type of incident.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the SIGN incident reporting data includes at least incident location data.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • a network is for example a MAN type network (English acronym for "Metropolitan Area Network").
  • 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.
  • technologies such as TDMA, FDMA, OFDMA, CDMA
  • GSM Global System for Mobile communications
  • EDGE Code Division Multiple Access
  • CDMA Code Division Multiple Access
  • UMTS High Speed Packet Access
  • HSPA High Speed Packet Access
  • LTE Long Term Evolution
  • LTE-A Long Term Evolution-A
  • WiFi IEEE 802.11
  • WiMAX IEEE 802.16
  • 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.
  • 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).
  • 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.
  • a network is for example a MAN type network.
  • 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.
  • 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.
  • 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.
  • an incident and the incident report data SIGN associated with it can be deleted from the incident database 25 when the incident is resolved.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the recipient database 29 is adapted to store, in association with each stored recipient, one or more types of incident.
  • 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.
  • 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.
  • the INF incident reporting information includes a geolocation of the incident.
  • the INF incident reporting information may further include the type of reported incident selected from the pre-established list of incident types.
  • 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.
  • 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.
  • 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.
  • INF incident reporting information information
  • 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.
  • 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.
  • 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.
  • 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.
  • each information system such as the information system 3 can access the incident reporting information by accessing the web portal 5.
  • 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).
  • an entity such as an administration, an association, a public service, etc.
  • 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.
  • the user terminal 7 During a step SI, the user terminal 7 generates incident report data relating to the incident observed.
  • 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.
  • the user specifies for example the urgency level of the incident as well as the type of incident observed.
  • 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. .
  • 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.
  • 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.
  • 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.
  • the user terminal 7 automatically generates geolocation data for the incident.
  • This geolocation data corresponds to a position current of the user terminal 7.
  • 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.
  • 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.
  • 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.
  • the processing unit 31 of the processing structure 9 analyzes the multimedia content using recognition software of objects.
  • 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.
  • object bank stored for example in memory 33
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • a new incident associated with the received incident reporting data is stored in the incident database 25.
  • 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.
  • 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.
  • each incident listed in the incident database 25 is associated with a reliability coefficient.
  • 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.
  • 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.
  • the confidence index makes it possible to initialize the reliability coefficient associated with this new incident.
  • 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.
  • 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.
  • the processing structure can determine a completeness coefficient characterizing the sufficiency or insufficiency of the information reported concerning the reported incident.
  • 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.
  • 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.
  • 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.
  • 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.
  • the generation of the incident reporting information is implemented if and only if the incident completeness coefficient is equal to 1.
  • the INF incident reporting information includes the elements necessary to resolve the reported incident.
  • 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.
  • other elements such as the level of urgency of the incident can be included in the incident reporting information.
  • 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.
  • each recipient is associated, within the recipient database 29, with one or more types of incident.
  • the recipients selected are the recipients associated with at least the type of incident reported.
  • 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.
  • 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.
  • 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.
  • INF incident reporting information can be transmitted directly to the recipient.
  • 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.
  • 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.
  • 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.
  • storing a new incident in the incident database 25 triggers a 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).
  • 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.
  • 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.
  • the processing structure 9 remains awaiting the reception of new incident report data SIGN capable of modifying the reliability coefficient of the incident.
  • 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.
  • 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.
  • 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.
  • 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.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Human Resources & Organizations (AREA)
  • Tourism & Hospitality (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Economics (AREA)
  • Health & Medical Sciences (AREA)
  • Marketing (AREA)
  • General Business, Economics & Management (AREA)
  • Primary Health Care (AREA)
  • General Health & Medical Sciences (AREA)
  • Educational Administration (AREA)
  • Development Economics (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Computing Systems (AREA)
  • Public Health (AREA)
  • Environmental & Geological Engineering (AREA)
  • Emergency Management (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • General Engineering & Computer Science (AREA)
  • Game Theory and Decision Science (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Information Transfer Between Computers (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

L'invention concerne un procédé de signalement d'incident mis en œuvre par des moyens informatiques. Le procédé comprend : - générer, au niveau d'une structure de traitement (9), une information de signalement d'un incident (INF) en fonction de données de signalement d'incident (SIGN) relatives à l'incident et générées au niveau d'un ou plusieurs terminaux utilisateur (7) et comprenant au moins des données de géolocalisation de l'incident, - sélectionner un ou plusieurs destinataires (3) des données de signalement d'incident reçues en fonction desdites données de signalement d'incident, ledit ou lesdits destinataires étant sélectionnés au sein d'une base de données de destinataires (29) de la structure de traitement, et - transmettre l'information de signalement d'incident audit ou auxdits destinataires sélectionnés.

Description

Description
Procédé et structure de signalement d’incident
Le domaine de l’invention se rapporte aux procédés et structures de traitement de données de signalement d’incident dans le but d’assurer l’acheminement les informations relatives à l’incident signalé aux personnes compétentes et en mesure d’assurer la résolution de l’incident signalé.
Aujourd’hui, la multiplication des moyens de communication et la démocratisation des smartphones permettent dans chaque ville la constitution d’un vaste réseau auquel participent les citoyens. La prise de conscience du dynamisme et de l’étendue de ce réseau a conduit au développement de « villes intelligentes » (connu aussi sous le terme anglophone Smart City). Ce concept récent désigne les villes utilisant les technologies de l’information et de la communication pour améliorer la qualité des services urbains ou réduire ses coûts.
La ville intelligente contribue plus généralement à la mise en œuvre du « Citizen Sourcing » qui s’appuie sur la contribution active des citoyens pour développer de nouveaux services dans lesquels le rôle des citoyens est prépondérant. Parmi les nombreuses applications, le « Citizen Sourcing » permet par exemple de collecter les idées et les suggestions des citoyens ou encore la surveillance accrue des réseaux sociaux pour trouver des solutions collectives à des problèmes occasionnés par des catastrophes naturelles.
Le signalement et l’enregistrement des incidents de façon collaborative présentent donc un enjeu majeur pour les villes intelligentes. Par ailleurs, la résolution d’un incident nécessite que les données relatives à l’incident en question collectées par des citoyens soient acheminées à un destinataire apte à résoudre ce type d’incident. En effet, à l’échelle d’une ville par exemple, les différentes administrations et les différents services ont souvent des domaines d’intervention clairement délimités et sont donc assignés à la résolution de certaines tâches bien spécifiques. La collecte des données ne peut donc pas être efficace sans un traitement des données destiné à établir la nature exacte d’un incident et, donc, le destinataire approprié des données relatives à l’incident signalé.
La présente invention vient améliorer la situation. A cet effet, il est proposé un procédé de traitement de données de signalement d’incident mis en œuvre par des moyens informatiques. Le procédé visé comprend :
- générer, au niveau d’une structure de traitement, une information de signalement d’un incident en fonction de données de signalement d’incident relatives à incident, les données de signalement d’incident étant générées au niveau d’un ou plusieurs terminaux utilisateur et comprenant au moins des données de géolocalisation de l’incident en question,
- sélectionner, en fonction de l’information de signalement d’incident, un ou plusieurs destinataires de l’information de signalement d’incident au sein d’une base de données de destinataires de la structure de traitement, et
- transmettre l’information de signalement d’incident au ou aux destinataires sélectionnés.
Selon un aspect de l’invention, une partie au moins des données de signalement d’incident sont générées via une application exécutée sur le terminal utilisateur.
Selon un autre aspect de l’invention, les données de signalement d’incident comprennent en outre des données saisies par un utilisateur du terminal utilisateur via l’application.
Selon un autre aspect de l’invention, les données de signalement d’incident comprennent des données relatives à un contenu multimédia généré à l’aide du terminal utilisateur.
Avantageusement, selon un autre aspect de l’invention, le contenu multimédia est analysé au niveau de la structure de traitement à l’aide d’un logiciel de reconnaissance d’objets, des données générées par ledit logiciel de reconnaissance d’objets étant adjointes aux données de signalement d’incident.
Selon un autre aspect de l’invention, les données de géolocalisation de l’incident sont déterminées automatiquement et correspondent à une position courante du terminal utilisateur.
Selon un autre aspect de l’invention, la structure de traitement comprend une base de données d’incidents au sein de laquelle sont stockés le ou les incidents signalés ainsi que les données de signalement d’incident respectivement associées, les données de signalement d’incident reçues étant analysées pour déterminer, par comparaison avec les données de signalement d’incident précédemment stockées dans la base de données d’incidents, si les données de signalement d’incident sont relatives à un incident déjà stocké dans la base de données d’incidents de sorte que :
- si les données de signalement d’incident reçues sont relatives à un incident stocké dans la base de données d’incidents, les données de signalement d’incident en question sont associées au sein de la base de données d’incidents à l’incident correspondant ;
- sinon, un nouvel incident associé aux données de signalement d’incident reçues est stocké dans la base de données d’incidents.
Selon un autre aspect de l’invention, dans le cas où une partie au moins des données de signalement d’incident sont générées via une application exécutée sur le terminal utilisateur, un utilisateur accède à l’application en se connectant à un compte utilisateur qui lui est propre, et les données de signalement d’incident comprennent un identifiant de compte utilisateur émetteur des données de signalement d’incident, cet identifiant étant associé au sein d’une base de données d’utilisateurs de la structure de traitement avec un indice de confiance, et dans lequel un coefficient de fiabilité est calculé par la structure de traitement pour chaque incident signalé en fonction de l’indice de confiance du ou des comptes utilisateur émetteurs des données de signalement d’incident relative à l’incident, le coefficient de fiabilité d’un incident étant mis à jour à chaque réception de données de signalement d’incident relative à l’incident signalé.
Selon un autre aspect de l’invention, la génération de l’information de signalement d’incident et la sélection du ou des destinataires de l’information de signalement d’incident relative à un incident sont mises en œuvre si et seulement si le coefficient de fiabilité de l’incident est supérieur ou égal à un seuil prédéterminé.
Selon un autre aspect de l’invention, un incident et les données de signalement d’incident associées à cet incident sont supprimés de la base de données d’incidents si le coefficient de fiabilité dudit incident est inférieur au seuil prédéterminé à l’issue d’une période de temps prédéterminée.
Selon un autre aspect de l’invention, un coefficient de complétude est calculé par la structure de traitement pour chaque incident signalé en fonction d’un critère de précision concernant les données de signalement relatives audit incident, le coefficient de complétude étant une variable binaire prenant la valeur 0 lorsque le critère de précision n’est pas satisfait et prenant la valeur 1 lorsque le critère de précision est satisfait, la génération de l’information de signalement d’incident et la sélection du ou des destinataires de ladite information de signalement d’incident relative à un incident sont mises en œuvre si et seulement si le coefficient de complétude dudit incident est égal à 1. Selon un autre aspect de l’invention, l’information de signalement d’incident est mise à disposition du ou des destinataires sélectionnés via un portail web au contenu personnalisé et adapté à chaque destinataire.
Les destinataires peuvent fournir un avis sur la pertinence des signalements mis à disposition, afin d’affiner le processus de mise en adéquation entre signalements et destinataires potentiels. Un tel avis peut être fourni, par exemple, via un formulaire dans lequel à chaque signalement mis à disposition, une note de 0 à 3 est attribuée par un destinataire ayant reçu le signalement considéré.
Selon une caractéristique de mise en œuvre de l’invention, le ou les destinataires sont déterminés automatiquement via un dispositif informatique, telle qu’une machine d’apprentissage ( learning machine en anglais). Une telle caractéristique permet de combiner l’historique de sélection d’incidents avec une analyse sémantique des profils des destinataires potentiels.
Selon un autre aspect de l’invention, l’information de signalement comprend des données relatives à un type de l’incident sélectionné dans une liste préétablie de types d’incident, chaque destinataire identifié dans la base de données de destinataires étant associé à un ou plusieurs types d’incident de la liste préétablie de types d’incident.
L’invention concerne en outre un programme informatique comportant des instructions pour la mise en œuvre du procédé décrit précédemment, lorsque les instructions sont mises en œuvre par au moins un processeur.
Enfin, l’invention vise une structure de traitement de données de signalement d’incident agencée pour générer une information de signalement d’un incident en fonction de données de signalement d’incident relatives à cet incident, les données de signalement d’incident étant générées par un ou plusieurs terminaux utilisateur et comprenant au moins des données de géolocalisation de l’incident. Par ailleurs, la structure de traitement est agencée en outre pour sélectionner, en fonction de l’information de signalement d’incident, un ou plusieurs destinataires de l’information de signalement d’incident, la structure de traitement comprenant une base de données de destinataires au sein de laquelle le ou les destinataires sont sélectionnés. Enfin, la structure de traitement est agencée en outre pour transmettre l’information de signalement d’incident au ou aux destinataires sélectionnés. D’autres caractéristiques, détails et avantages de l’invention apparaîtront à la lecture de la description détaillée ci-après, et à l’analyse des dessins annexés, sur lesquels :
- la figure 1 illustre un système de traitement de données de signalement d’incident selon l’invention; et
- la figure 2 illustre un procédé de traitement de données de signalement d’incident selon l’invention.
La figure 1 illustre un système de traitement de données de signalement d’incident, ci- après système 1 et un système d’information 3. Dans l’exemple illustré, un portail web 5 permet d’accéder à des informations relatives à un ou plusieurs incidents signalés.
Le système 1 est agencé pour générer et traiter des données de signalement d’incident. Le système 1 est agencé en outre pour assurer l’acheminement d’informations relatives aux incidents signalés à un ou plusieurs destinataires, par exemple le système d’information 3, de manière à faciliter la résolution des incidents signalés en s’assurant que les informations relatives à un incident donné sont transmises aux destinataires appropriés.
Le système 1 comprend un ou plusieurs terminaux utilisateur, ici un terminal utilisateur 7, et une structure de traitement de données de signalement d’incident, ci-après structure de traitement 9.
Le terminal utilisateur 7 est adapté pour signaler un incident à la structure de traitement 9. Plus exactement, le terminal utilisateur 7 permet à un utilisateur en sa possession de signaler un incident en générant et en transmettant des données de signalement de l’incident à la structure de traitement 9. Les données de signalement d’incident comprennent au moins des données de géolocalisation de l’incident.
Dans un ou plusieurs modes de réalisation, le terminal utilisateur 7 est adapté pour déterminer automatiquement les données de géolocalisation de l’incident. La géolocalisation de l’incident correspond alors à une position courante du terminal utilisateur 7. La position courante du terminal utilisateur 7 est par exemple déterminée automatiquement par un serveur connecté à un réseau auquel le terminal utilisateur 7 est connecté. Alternativement, le terminal utilisateur 7 comprend un module de géolocalisation, par exemple de type GPS (acronyme anglophone pour « Global Positioning System ») ou de type Galileo. De manière générale, un incident est un accident de voiture, un incendie, une dégradation de la chaussée ou tout autre évènement localisé et pouvant faire l’objet d’un signalement. Un incident peut également concerner un dysfonctionnement, par exemple des retards, d’un prestataire de service de transport public ou privé.
Comme illustré en figure 1, le terminal utilisateur 7 comprend une interface Homme/Machine 11, une unité de capture d’images 13, une unité de traitement 15 et un module de communication 17.
L’interface Homme/Machine 11 est adaptée pour permettre à l’utilisateur en possession du terminal utilisateur 7 de générer des données relatives à l’incident qu’il souhaite signaler à la structure de traitement 9.
Par exemple, une partie au moins des données de signalement d’incident sont générées via une application exécutée sur le terminal utilisateur 7. L’utilisateur peut accéder à cette application en se connectant à un compte utilisateur. On comprend ici que dans un ou plusieurs modes de réalisation, un utilisateur souhaitant participer au signalement d’incidents peut le faire en exécutant une application client sur le terminal utilisateur 7 (par exemple application native ou web exécutée sur un smartphone ou une tablette, ou web- application exécutée par le biais d’un navigateur Web sur un ordinateur personnel (de type PC, pour « Personal Computer »)), et en utilisant un compte utilisateur qui lui est propre pour se connecter à une application serveur. Ce compte utilisateur peut se présenter par exemple sous la forme d’un ensemble de données comprenant des données d’identification ainsi que, selon les cas, des données d’authentification de l’utilisateur.
En fonction du mode de réalisation, une application client exécutée sur un terminal tel que le terminal utilisateur 7 peut nécessiter une inscription de l’utilisateur et le renseignement de données telles qu’un numéro de mobile, un mot de passe ou des données personnelles telles que son adresse de domicile.
Chaque compte utilisateur est associé à un identifiant qui lui est propre. Un tel identifiant permet, comme expliqué dans la suite, de déterminer à partir de quel compte utilisateur ont été générées les données de signalement. Une autre manière de voir les choses est de considérer que, avantageusement, l’identifiant du compte utilisateur à partir duquel l’utilisateur a signalé un incident et renseigné des informations sur cet incident fait partie des données de signalement d’incident et générées. A l’aide de cette application, l’utilisateur peut, par exemple, saisir ou renseignement une partie au moins des données de signalement d’incident. Autrement dit, l’interface Homme/Machine 11 et l’application exécutée sur le terminal utilisateur 7 permettent à l’utilisateur en possession du terminal utilisateur 7 de générer lui-même une partie au moins des données de signalement d’incident.
Par exemple, l’interface Homme/Machine 11 est alors adaptée pour permettre à l’utilisateur de spécifier un niveau d’urgence de l’incident. Par exemple, l’interface Homme/Machine 11 permet de sélectionner le niveau d’urgence de l’incident sur une échelle préétablie. Le niveau d’urgence est par exemple caractérisé par un chiffre ou une lettre.
Avantageusement, l’interface Homme/Machine 11 est adaptée pour permettre à l’utilisateur de spécifier un type de l’incident. Par exemple, l’interface Homme/Machine 11 permet de sélectionner le type de l’incident parmi une liste préétablie d’incidents potentiels. Cette fonctionnalité peut se présenter sous la forme d’un menu déroulant accessible à l’utilisateur via l’interface Homme/Machine 11. Alternativement, l’interface Homme/Machine 11 permet de spécifier un type d’incident ne faisant pas partie de la liste préétablie via une option de texte libre accessible à l’utilisateur.
Ainsi, le niveau d’urgence de l’incident ou encore le type de l’incident sont des exemples possibles de données inclues dans les données de signalement d’incident et générées par le terminal utilisateur 7. Ces données peuvent être en particulier saisies et renseignées par l’utilisateur en possession du terminal utilisateur 7 en exécutant une application.
Par ailleurs, comme expliqué précédemment, les données de signalement comprennent des données de géolocalisation de l’incident déterminées automatiquement par le terminal utilisateur 7 et correspondant à une position courante du terminal utilisateur 7. Néanmoins, alternativement, le terminal utilisateur 7 est adapté pour permettre à l’utilisateur de renseigner, par exemple via l’application exécutée sur le terminal utilisateur 7, la géolocalisation de l’incident.
L’unité de capture d’images 13 est adaptée pour générer un contenu multimédia tel qu’un contenu vidéo ou une photographie. Dans un ou plusieurs modes de réalisation, les données de signalement d’incident comprennent des données relatives à un contenu multimédia généré à l’aide du terminal utilisateur 7, et plus exactement donc à l’aide de l’unité de capture d’images 13. Par exemple, une fonctionnalité de l’application exécutée sur le terminal utilisateur 7 permet à l’utilisateur d’adjoindre aux données saisies un contenu multimédia, donc un contenu vidéo et/ou une ou plusieurs photographies.
L’unité de traitement 15 est adaptée pour générer des données de signalement d’incident SIGN.
Comme expliqué précédemment, les données de signalement d’incident SIGN comprennent au moins des données de géolocalisation de l’incident.
Par ailleurs, en référence aux modes de réalisation évoqués précédemment, les données de signalement d’incident SIGN peuvent comprendre en outre des données relatives au niveau d’urgence de l’incident et/ou des données relatives au type de l’incident et/ou un contenu multimédia. De manière générale, les données de signalement d’incident SIGN peuvent comprendre tout type de données concernant la nature de l’incident et pouvant être utile à la résolution de ce dernier.
Avantageusement, les données de signalement d’incident SIGN comprennent en outre un identifiant du compte utilisateur à partir duquel l’utilisateur du terminal utilisateur 7 a signalé, via l’application exécutée sur le terminal utilisateur 7, l’incident.
Comme illustré en figure 1, l’unité de traitement 13 comprend une mémoire 19 et un processeur 21.
La mémoire 19 est configurée pour stocker des instructions d’un programme informatique dont l’exécution par le processeur 21 se traduit par le fonctionnement de l’unité de traitement 15 pour la mise en œuvre du procédé de traitement de données de signalement d’incident proposé, et plus spécifiquement la génération des données de signalement d’incident SIGN.
Avantageusement, la mémoire 19 est en outre configurée pour stocker une adresse de la structure de traitement 9 pour l’acheminement des données de signalement d’incident SIGN à destination de la structure de traitement 9 correspondante. Par ailleurs, la mémoire 19 peut en outre être configurée pour stocker un identifiant du compte utilisateur auquel se connecte habituellement l’utilisateur du terminal utilisateur 7. Bien entendu, l’identifiant du compte utilisateur peut aussi être extrait de celui-ci, ponctuellement, lorsqu’un utilisateur se connecte à son compte utilisateur via le terminal utilisateur 7. Ainsi, dans le cas où un nouvel utilisateur utilise le terminal utilisateur 7 pour se connecter à un compte utilisateur différent du compte utilisateur auquel se connecte l’utilisateur régulier du terminal utilisateur 7, l’identifiant de ce nouveau compte utilisateur peut être extrait, éventuellement stocké dans la mémoire 19, et intégré aux données de signalement d’incident SIGN.
Le module de communication 17 est adapté pour émettre les données de signalement d’incident SIGN à destination de la structure de traitement 9. Les données de signalement d’incident SIGN sont par exemple émises à destination de la structure de traitement 9 via un réseau (non représenté sur la figure 1). Un tel réseau est par exemple un réseau de type MAN (acronyme anglophone pour « Metropolitan Area Network »).
L'homme du métier peut se rendre compte qu'il existe de nombreux types différents de réseaux de communication de données, par exemple des réseaux de radiocommunication, cellulaires ou non cellulaires, et qu’en fonction du mode de réalisation, le module de communication 17 pourra intégrer un ou plusieurs modules de communication, par exemple de communication radiofréquence et être configuré pour l’émission et la réception de signaux radiofréquences, selon une ou plusieurs technologies, telles que TDMA, FDMA, OFDMA, CDMA, ou un ou plusieurs standards de radiocommunication, tels que GSM, EDGE, CDMA, UMTS, HSPA, LTE, LTE-A, WiFi (IEEE 802.11) et WiMAX (IEEE 802.16), ou leurs variantes ou évolutions, actuellement connus ou développés ultérieurement.
La structure de traitement 9 est agencée pour générer une information de signalement d’un incident en fonction des données de signalement d’incident SIGN relatives à l’incident en question. Par ailleurs, la structure de traitement 9 est agencée en outre pour sélectionner, en fonction de l’information de signalement d’incident, un ou plusieurs destinataires de l’information de signalement d’incident. En d’autres termes, la structure de traitement 9 est agencée pour analyser les données de signalement d’incident SIGN reçues en provenance du ou des terminaux utilisateur, tels que le terminal utilisateur 7, et pour appliquer un traitement aux données de signalement d’incident SIGN en vue d’acheminer le signalement de l’incident aux destinataires appropriés, sous la forme de l’information de signalement, afin de faciliter la résolution de l’incident. Comme illustré en figure 1, la structure de traitement 9 comprend un module de communication 23, une base de données d’incidents 25, une base de données d’utilisateurs 27, une base de données de destinataires 29 et une unité de traitement 31.
Le module de communication 23 est adapté pour recevoir des données de signalement d’incident SIGN émises par le terminal utilisateur 7, et plus précisément par le module de communication 17 du terminal utilisateur 7. Avantageusement, le module de communication 23 est adapté pour recevoir des données de signalement d’incident SIGN émises par plusieurs terminaux utilisateur tels que le terminal utilisateur 7.
Le module de communication 23 est en outre adapté pour communiquer avec plusieurs destinataires. Le module de communication 23 communique par exemple avec le système d’information 3 via un réseau (non représenté sur la figure). En particulier, le module de communication 23 est adapté pour émettre l’information de signalement d’incident INF générée par la structure de traitement de données 9 à destination d’un ou plusieurs destinataires. Un tel réseau est par exemple un réseau de type MAN.
Par ailleurs, comme expliqué dans la suite de la description, le module de communication 23 peut être agencé en outre pour transmettre l’information de signalement d’incident INF à un ou plusieurs destinataires par l’intermédiaire du portail web 5.
F'homme du métier peut se rendre compte qu'il existe de nombreux types différents de réseaux de communication de données, par exemple des réseaux de radiocommunication, cellulaires ou non cellulaires, et qu’en fonction du mode de réalisation, le module de communication 23 pourra intégrer un ou plusieurs modules de communication, par exemple de communication radiofréquence et être configuré pour l’émission et la réception de signaux radiofréquences, selon une ou plusieurs technologies, telles que TDMA, FDMA, OFDMA, CDMA, ou un ou plusieurs standards de radiocommunication, tels que GSM, EDGE, CDMA, UMTS, HSPA, LTE, LTE-A, WiFi (IEEE 802.11) et WiMAX (IEEE 802.16), ou leurs variantes ou évolutions, actuellement connus ou développés ultérieurement.
La base de données d’incidents 25 est adaptée pour stocker le ou les incidents signalés ainsi que les données de signalement d’incident SIGN associées aux incidents signalés et stockés. On comprend ici que la base de données d’incidents 25 est configurée de sorte que les données de signalement d’incidents SIGN reçues en provenance de terminaux utilisateurs tels que le terminal utilisateur 7 sont regroupées par incident de sorte que chaque incident signalé est répertorié dans la base de données d’incidents 25 en association avec les données de signalement d’incidents SIGN qui lui sont relatives.
On comprend que la base de données d’incidents 25 est configurée pour être mise à jour en fonction des données de signalement d’incident SIGN reçues. Par ailleurs, et comme développé dans la suite de la description, un incident et les données de signalement d’incident SIGN qui lui sont associées peuvent être supprimés de la base de données d’incidents 25 sous certaines conditions, notamment lorsque les données de signalement d’incident SIGN reçues et relatives à un incident ne sont pas suffisamment fiables, la fiabilité étant estimé par la structure de traitement 9 sur la base d’un indice de confiance de chaque compte utilisateur signalant l’incident. On comprend que, dans ce mode de réalisation, chaque incident répertorié dans la base de données d’incidents 25 est associé à un coefficient de fiabilité susceptible d’être mis à jour.
Par ailleurs, avantageusement, un incident et les données de signalement d’incident SIGN qui lui sont associées peuvent être supprimés de la base de données d’incidents 25 lorsque l’incident est résolu.
Par ailleurs, dans un mode de réalisation, un incident signalé peut être associée à un coefficient de complétude caractérisant la suffisance ou l’insuffisance des informations remontées concernant l’incident signalé en question. En d’autres termes, un tel coefficient de complétude permet de caractériser le fait que les informations obtenues concernant un incident signalé sont suffisantes ou non pour résoudre cet incident.
Le coefficient de complétude est calculé par la structure de traitement pour chaque incident signalé en fonction d’un critère de précision concernant les données de signalement relatives à cet incident. Par exemple, le coefficient de complétude est une variable binaire prenant la valeur 0 lorsque le critère de précision n’est pas satisfait et prenant la valeur 1 lorsque le critère de précision est satisfait.
La base de données d’utilisateurs 27 est adaptée pour stocker l’identifiant d’un ou plusieurs comptes utilisateur tel que le compte utilisateur à partir duquel l’utilisateur du terminal utilisateur 7 a signalé un incident. Avantageusement, la base de données d’utilisateurs 27 est adaptée en outre pour stocker, en association avec chacun des identifiants stockés, un indice de confiance. On comprend donc que, au sein de la base de données d’utilisateurs 27, chaque identifiant d’un compte utilisateur est associé à un indice de confiance.
La base de données de destinataires 29 est adaptée pour stocker un ou plusieurs destinataires. On comprend ici que la base de données de destinataires 29 comprend un ou plusieurs identifiants, chaque identifiant étant associé à un destinataire potentiel d’une information de signalement d’incident INF générée par la structure de traitement 9.
Par ailleurs, la base de données de destinataires 29 est adaptée en outre pour stocker, en association avec chaque destinataire stocké dans la base de données de destinataires 29, une adresse du destinataire considéré. Cette adresse permet par la suite au module de communication 23 d’acheminer l’information de signalement d’incident INF générée aux destinataires sélectionnés.
Dans un ou plusieurs modes de réalisation, la base de données de destinataires 29 est adaptée pour stocker, en association avec chaque destinataire stocké, un ou plusieurs types d’incident. Typiquement, les différents types d’incident associés avec les destinataires au sein de la base de données de destinataires 29 font partie de la liste préétablie de types d’incident proposée à un utilisateur souhaitant signaler un incident à l’aide de son terminal utilisateur.
Avantageusement, chaque destinataire est associé en outre, au sein de la base de données de destinataires 29, avec une zone géographique. On comprend qu’une telle zone géographique correspond à une zone d’intervention possible du destinataire.
L’unité de traitement 31 est agencée pour générer une information de signalement d’incident INF en fonction des données de signalement d’incident SIGN relatives à l’incident en question.
L’information de signalement d’incident INF comprend des données permettant aux destinataires d’avoir à leur disposition les éléments nécessaires à la résolution de l’incident signalé. Par exemple, l’information de signalement d’incident INF comprend une géolocalisation de l’incident. Toujours à titre d’exemple, l’information de signalement d’incident INF peut comprendre en outre le type de l’incident signalé sélectionné dans la liste préétablie de types d’incident. Par ailleurs, comme expliqué précédemment, les données de signalement d’incident SIGN peuvent comprendre en outre un contenu multimédia généré par le terminal utilisateur 7 à l’aide de l’unité de capture d’images 13. L’unité de traitement 31 est alors agencée en outre pour analyser, à l’aide d’un logiciel de reconnaissance d’objets, le contenu multimédia émis. L’unité de traitement 31 adjoint alors les données générées par le logiciel de reconnaissance d’objets aux données de signalement d’incident SIGN.
L’unité de traitement 31 est agencée en outre pour sélectionner, en fonction de l’information de signalement d’incident INF générée, un ou plusieurs destinataires de l’information de signalement d’incident INF au sein de la base de données de destinataires 29 de la structure de traitement 9.
La sélection des destinataires de l’information de signalement d’incident INF dépend du type de l’incident signalé. Comme expliqué précédemment, chaque destinataire stocké dans la base de données de destinataires 29 est associé à un ou plusieurs types d’incidents. Les types d’incident auquel est associé un destinataire correspond aux types d’incident qu’il est apte à résoudre et qui relèvent de son domaine d’intervention. Par ailleurs, la sélection des destinataires peut dépendre en outre de la géolocalisation de l’incident signalé.
L’unité de traitement 31 comprend une mémoire 33 et un processeur 35.
La mémoire 33 est configurée pour stocker des instructions d’un programme informatique dont l’exécution par le processeur 35 se traduit par le fonctionnement de l’unité de traitement 31 pour la mise en œuvre du procédé de traitement de données de signalement d’incident proposé, et plus spécifiquement la génération de l’information de signalement d’incident INF.
Dans un ou plusieurs modes de réalisation, la mémoire 33 est configurée en outre pour stocker la liste préétablie de types d’incident.
Le système d’information 3 est agencé pour recevoir l’information de signalement d’incident INF générée et émise par la structure de traitement 9. Typiquement, dans le contexte de la présente invention, le système d’information 3 désigne des ressources informatiques de collecte d’informations, ici l’information de signalement d’incident INF, d’une administration ou d’un prestataire de services, que ce prestataire soit un organisme public ou privé. On comprend ici que l’architecture illustrée en figure 1 permet à cette administration ou à ce prestataire de services de prendre connaissance d’un incident signalé par un ou plusieurs utilisateurs à l’aide de leurs terminaux utilisateur et traité puis acheminé par la structure de traitement 9.
Par exemple, le système d’information 3 est celui d’un prestataire de service de transport et l’information de signalement d’incident INF permet de signaler un retard et de fournir les éléments nécessaires à la prise en charge et à la résolution de ce retard. Toujours à titre d’exemple, le système d’information 3 est celui d’une caserne de pompiers et l’information de signalement INF permet de signaler un incendie et de fournir les éléments nécessaires à la prise en charge de cet incendie.
Par ailleurs, dans un ou plusieurs modes de réalisation, l’information de signalement d’incident INF peut également être mise à disposition du ou des destinataires sélectionnés par la structure de traitement 9 via le portail web 5. Le portail web 5 présente un contenu personnalisé et adapté à chaque destinataire.
On comprend ici que chaque système d’information tel que le système d’information 3 peut accéder à l’information de signalement d’incident en accédant au portail web 5. Par exemple, l’administration ou le prestataire de services auquel est rattaché le système d’information 3 peut accéder au portail web 5 en se connectant via un compte utilisateur. L’accession à ce compte utilisateur peut impliquer l’utilisation d’un identifiant, propre au système d’information 3, et d’un mot de passe. Le portail web 5 est alors personnalisé en ce que les incidents signalés peuvent être différents d’un système d’information à un autre.
Un tel système peut également identifier d’une manière proactive une entité, telle qu’une administration, une association, un service public etc., et lui proposer d’accéder aux signalements qui peuvent être sous son périmètre de responsabilité. A titre d’exemple, des signalements relevant des abris de bus (détérioration, dysfonctionnements etc.) dans une région considérée peuvent être proposés, par l’envoi d’un courrier électronique (email) contenant un lien vers les données associées aux signalements à des sociétés spécialisées de cette région, par exemple un organisme qui gère les transports publics, une société qui exploite l’espace publicitaire, ainsi qu’à la police municipale (dans les cas de vandalisme notamment). Par la suite, ces destinataires de tels courriers électroniques peuvent consulter par exemple une page Web dont le lien est contenu dans l’email, et à la fois annoter la pertinence des signalements et récupérer les signalements pertinents. Ces nouveaux destinataires pourront de manière avantageuse affiner la sélection des incidents qui sont de leurs domaines de compétences (catégories des signalements pertinents).
Un procédé de traitement de données de signalement d’incident SIG va maintenant être décrit en référence à la figure 2.
Dans le contexte de l’invention, un incident se produit par exemple dans une ville. Cet incident peut être un incendie, un accident de voiture, une dégradation de la chaussée ou tout autre type d’incident. Les utilisateurs témoins de cet incident souhaitent que cet incident soit résolu au plus tôt et disposent chacun d’un terminal utilisateur tel que le terminal utilisateur 7.
Lors d’une étape SI, le terminal utilisateur 7 génère des données de signalement d’incident relatives à l’incident constaté. Par exemple, l’utilisateur en possession du terminal utilisateur 7 exécute une application, par exemple une application native ou une application web, lui permettant de saisir et de renseigner des données relatives à l’incident.
A l’aide de cette application, l’utilisateur spécifie par exemple le niveau d’urgence de l’incident ainsi que le type de l’incident constaté. Comme expliqué précédemment, l’utilisateur peut sélectionner le type de l’incident à l’aide d’un menu déroulant lui présentant une liste préétablie d’incidents potentiels ou utiliser une option de texte libre pour décrire l’incident qu’il souhaite signaler.
Toujours au cours de cette étape, l’utilisateur peut utiliser l’unité de capture d’image 13 du terminal utilisateur 7 pour générer un contenu multimédia relatif à l’incident constaté. Ce contenu multimédia correspond par exemple à un contenu vidéo ou à des photographies ou à une combinaison des deux. Le contenu multimédia ainsi obtenu fait alors partie des données de signalement d’incident SIGN.
Par ailleurs, comme expliqué précédemment, l’utilisateur du terminal utilisateur 7 signale l’incident par exemple en exécutant une application dédiée au signalement d’incident et en se connectant à un compte utilisateur qui lui est propre. Dans un tel cas, donc, les données de signalement d’incident SIGN peuvent comprendre en outre un identifiant du compte utilisateur à partir duquel l’utilisateur du terminal utilisateur 7 a signalé l’incident.
Lors d’une étape S2, le terminal utilisateur 7 génère automatiquement des données de géolocalisation de l’incident. Ces données de géolocalisation correspondent à une position courante du terminal utilisateur 7. Comme expliqué précédemment, la position courante du terminal utilisateur 7 est par exemple déterminée par un serveur connecté à un réseau auquel le terminal utilisateur 7 est connecté ou par un module de géolocalisation compris dans le terminal utilisateur 7.
Alternativement, la géolocalisation de l’incident peut être renseignée par l’utilisateur lui- même à l’aide de l’application exécutée sur le terminal utilisateur 7.
Ces données de géolocalisation de l’incident sont intégrées aux données de signalement d’incident SIGN.
Lors d’une étape S3, le module de communication 17 du terminal utilisateur 7 émet les données de signalement d’incident SIGN à destination de la structure de traitement 9. Les données de signalement d’incident SIGN sont émises à destination de la structure de traitement 9 à l’aide de l’adresse de la structure de traitement 9 stockée dans la mémoire 19 de l’unité de traitement 15 du terminal utilisateur 7. Les données de signalement d’incident SIGN sont par exemple émises à destination de la structure de traitement 9 via un réseau de type MAN.
Lors d’une étape S4, dans le cas où les données de signalement d’incident SIGN comprennent un contenu multimédia, l’unité de traitement 31 de la structure de traitement 9 analyse le contenu multimédia à l’aide d’un logiciel de reconnaissance d’objets. L’utilisation d’un logiciel de reconnaissance d’objets permet un marquage (plus connu sous le terme anglophone « tagging ») des différents objets ou éléments présents sur les images du contenu multimédia, qu’il s’agisse d’un contenu vidéo ou de photographies. Le marquage permet ainsi de déterminer automatiquement des zones d’intérêt dans une image et, par comparaison avec une banque d’objet, stockée par exemple dans la mémoire 33, de générer des données supplémentaires relatives à l’incident signalé. De telles données permettent par exemple, d’augmenter la précision de la géolocalisation de l’incident, d’estimer l’ampleur de l’incident, son niveau d’urgence ou toute autre information utile pour déterminer le type de l’incident et pour sa résolution.
Lors de cette étape, les données générées par le logiciel de reconnaissance d’objets sont adjointes aux données de signalement d’incident SIGN, ces dernières se trouvant ainsi enrichies. Lors d’une étape S5, la structure de traitement 9 analyse les données de signalement d’incident SIGN reçues, et potentiellement enrichies lors de l’étape S4 à l’aide du logiciel de reconnaissance d’objets,, pour déterminer, par comparaison avec les données de signalement d’incident précédemment stockées dans la base de données d’incidents 25 si les données de signalement d’incident SIGN reçues sont relatives à un incident déjà stocké dans la base de données d’incidents 25.
Cette comparaison peut être mise en œuvre de plusieurs manières. Tout d’abord, la structure de traitement 9, et plus particulièrement l’unité de traitement 31, peut comparer les données de géolocalisation comprises dans les données de signalement d’incident SIGN reçues avec les données de géolocalisation comprises dans les données de signalement d’incident déjà stocké. Ainsi, il est possible d’écarter les incidents dont les données de géolocalisation ne coïncident pas avec celles des données de signalement d’incident SIGN analysées.
Par ailleurs, une fois déterminés les incidents déjà stockés compatibles géographiquement avec les nouvelles données de signalement d’incident SIGN reçues, l’unité de traitement 31 peut comparer le type de l’incident avec le type de chaque d’incident déjà stockés. La comparaison peut en outre s’appuyer sur les données générées par le logiciel de reconnaissance d’objets en cherchant une corrélation entre des objets détectés dans le contenu multimédia des nouvelles données de signalement d’incident SIGN et des objets déjà détectés pour les contenus multimédias des données de signalement d’incident déjà stockées dans la base de données d’incidents 25.
Lors d’une étape S6A, si les données de signalement d’incident SIGN reçues sont relatives à un incident déjà stocké dans la base de données d’incidents 25, ces données de signalement d’incident SIGN sont associées au sein de la base de données d’incidents 25 à l’incident correspondant.
Alternativement, lors d’une étape S6B, un nouvel incident associé aux données de signalement d’incident reçues est stocké dans la base de données d’incidents 25.
Comme expliqué précédemment, dans un ou plusieurs modes de réalisation, les données de signalement d’incident SIGN émises par le terminal utilisateur 7 comprennent un identifiant du compte utilisateur à partir duquel l’utilisateur du terminal utilisateur 7 a signalé l’incident. Par ailleurs, au sein de la base de données d’utilisateurs 27, chaque identifiant de compte utilisateur est associé à un indice de confiance.
Ainsi, lors d’une étape S7, l’unité de traitement 31 détermine l’indice de confiance associé à l’identifiant du compte utilisateur émetteur des données de signalement d’incident SIGN, c’est-à-dire, dans le cas décrit ici, l’identifiant associé au compte utilisateur auquel s’est connecté l’utilisateur du terminal utilisateur 7 et a, depuis l’application exécutée, signalé l’incident.
Par ailleurs, comme expliqué précédemment, chaque incident répertorié dans la base de données d’incidents 25 est associé à un coefficient de fiabilité. Un tel coefficient de fiabilité permet de caractériser la fiabilité de l’incident signalé et, ainsi, d’éviter de signaler potentiellement un incident n’existant pas.
Ainsi, lors de l’étape S8, l’unité de traitement 31 de la structure de traitement 9 met à jour le coefficient de fiabilité de l’incident auxquelles se rapporte les données de signalement d’incident SIGN reçues en fonction de l’indice de confiance associé au compte utilisateur émetteur de ces données de signalement d’incident SIGN. Bien entendu, dans le cas où les données de signalement d’incident SIGN correspondent à un nouvel incident, l’indice de confiance permet d’initialiser le coefficient de fiabilité associé à ce nouvel incident. En d’autres termes, la structure de traitement 9 calcule, pour chaque incident signalé, un coefficient de fiabilité en fonction de l’indice de confiance du ou des comptes utilisateur émetteurs des données de signalement d’incident relative à l’incident considéré.
Lors d’une étape S9, le coefficient de fiabilité de l’incident signalé est comparé à un seuil prédéterminé. Ce seuil prédéterminé est par exemple stocké dans la mémoire 33 de l’unité de traitement 31.
Par ailleurs, alternativement ou parallèlement il est également possible de définir d’autres conditions que l’incident signalé doit vérifier lors de cette étape S9. Par exemple, en plus ou à la place de la condition portant sur le coefficient de fiabilité de l’incident, la structure de traitement peut déterminer un coefficient de complétude caractérisant la suffisance ou l’insuffisance des informations remontées concernant l’incident signalé. Par exemple, ce coefficient de complétude est une variable binaire prenant la valeur 0 lorsque les informations remontées par les différents utilisateurs, et plus exactement les différents comptes utilisateur, ne sont pas suffisante pour résoudre l’incident signalé ou la valeur 1 lorsque les informations remontées sont suffisantes pour la résolution de l’incident signalé.
Par exemple, le coefficient de complétude dépend de la précision de la géolocalisation de l’incident évaluée par comparaison des différentes données de géolocalisation comprises dans les données de signalement d’incident SIGN relatives à l’incident en question.
Toujours à titre d’exemple, le coefficient de complétude peut dépendre de la précision concernant le type de l’incident signalé. En effet, comme expliqué précédemment, l’application exécutée par un utilisateur peut laisser la possibilité à ce dernier de renseigner, via une option de texte libre, le type de l’incident auquel cas une incertitude peut exister sur le type de l’incident, la qualification du type de l’incident pouvant varier d’un utilisateur à l’autre.
Lors d’une étape S 10, mise en œuvre dans le cas où le coefficient de fiabilité de l’incident est supérieur ou égal au seuil prédéterminé, l’unité de traitement 31 génère une information de signalement d’incident INF relative à l’incident considéré. Par ailleurs, comme expliqué précédemment, un coefficient de complétude peut également être déterminé par la structure de traitement 9 de sorte que, dans ce mode de réalisation, l’étape S 10 n’est mise en œuvre que si, en plus à la place de la condition sur la valeur du coefficient de fiabilité, la valeur du coefficient de complétude est satisfaisante.
Ainsi, dans le cas où le coefficient de complétude est une variable binaire, la génération de l’information de signalement d’incident est mise en œuvre si et seulement si le coefficient de complétude de l’incident est égal à 1.
Comme expliqué précédemment, l’information de signalement d’incident INF comprend les éléments nécessaires à la résolution de l’incident signalé. Ainsi, l’information de signalement d’incident INF comprend la géolocalisation de l’incident ainsi que le type de l’incident sélectionné dans la liste préétablie d’incidents potentiels. Bien entendu, d’autres éléments comme le niveau d’urgence de l’incident peuvent être compris dans l’information de signalement d’incident.
Lors d’une étape Sl l, consécutive à l’étape S 10, la structure de traitement 9 et plus précisément l’unité de traitement 31, sélectionne un ou plusieurs destinataires de l’information de signalement d’incidents INF au sein de la base de données de destinataires 29 en fonction de l’information de signalement d’incident INF générée.
Comme expliqué précédemment, chaque destinataire est associé, au sein de la base de données de destinataires 29, à un ou plusieurs types d’incident. Ainsi, par exemple, les destinataires sélectionnés sont les destinataires associés au moins au type de l’incident signalé. Par ailleurs, chaque destinataire peut être associé en outre à une zone géographique au sein de la base de données de destinataires 29 de sorte qu’un critère supplémentaire peut consister à ne sélectionner que les destinataires dont la zone géographique comprend la géolocalisation de l’incident signalé.
Bien entendu, d’autres modes de réalisation sont possibles. Ainsi, un destinataire peut être sélectionné par la structure de traitement 9 même si la géolocalisation de l’incident n’est pas dans sa zone géographique si le niveau d’urgence de l’incident est faible.
Lors d’une étape S 12, le module de communication 23 de la structure de traitement 9 émet l’information de signalement d’incident SIGN à destination du ou des destinataires sélectionnés. Par ailleurs, il convient de noter que l’adresse de chaque destinataire est également stockée dans la base de données de destinataires 29, ce qui permet par la suite l’acheminement de l’information de signalement d’incident SIGN. Les informations de signalement d’incident INF sont par exemple émises à destination de la structure de traitement 9 via un réseau de type MAN.
On peut également envisager des mécanismes de détermination automatique des destinataires intéressés, par l’emploi d’une technique d’intelligence artificielle qui, suite à une analyse sémantique des signalements et de leurs attributs, effectuerait la recherche de destinataires potentiels sans que ceux-ci soient déclarés au préalable, et ainsi les solliciter de manière proactive afin qu’ils puissent s’abonner en tant qu’ organisme ou entité récipiendaire. Il est également possible selon le mode de réalisation choisi que le système d’informations puisse sonder des groupes d’usagers afin d’exploiter l’intelligence collective pour déterminer les destinataires. Le système d’informations peut également fournir des modes de soumission d’avis (feedbacks ) grâce auxquels les destinataires peuvent annoter la pertinence des signalements qui leur ont été fournis par le système ; cela permettant de régler le processus de sélection de manière continue. Ainsi, le système peut proposer de nouveaux types de signalement de façon aléatoire afin de permettre la découverte de nouvelles associations entre types de signalement et destinataires correspondants.
Comme expliqué précédemment, l’information de signalement d’incident INF peut être transmise directement au destinataire. Dans l’exemple illustré en figure 1, le destinataire de l’information de signalement d’incident INF est le système d’information 3. Le système d’information 3 est typiquement le système d’information d’une administration ou d’un prestataire de services en charge de la résolution d’incidents tels que l’incident signalé via l’information de signalement d’incident SIGN.
Par ailleurs, l’information de signalement d’incident peut être également utilisée pour mettre à jour le portail web 5, et plus exactement le contenu personnalisé du portail web 5 réservé à l’administration ou au prestataire de service auquel se rattache le système d’information 3. Ainsi, en accédant à son compte utilisateur, un salarié habilité de l’administration ou du prestataire de services a accès aux informations relatives à un incident signalé et relevant de son domaine d’intervention. Les étapes S 10, SU et S 12 décrites précédemment sont mises en œuvre lorsque le coefficient de fiabilité de l’incident signalé est supérieur ou égal au seuil prédéterminé. Néanmoins, dans le cas où le coefficient de fiabilité est inférieur au coefficient de fiabilité, les étapes décrites ci-après sont mises en œuvre par la structure de traitement 9.
Dans un ou plusieurs modes de réalisation, le stockage d’un nouvel incident dans la base de données d’incidents 25 déclenche une période de temps prédéterminée. Ainsi, si à l’issue de cette période de temps prédéterminée, le coefficient de fiabilité de l’incident signalé n’est pas supérieur au seuil prédéterminé, l’incident et les données de signalement d’incident qui lui sont associées sont supprimés de la base de données d’incident 25.
L’unité de traitement 31 est par exemple munie d’une horloge (non représentée sur la figure 1).
Ainsi, lors d’une étape S 13, dans le cas où le coefficient de fiabilité est inférieur au seuil prédéterminé, il est déterminé si la période de temps prédéterminée associée à l’incident est écoulée ou non. Lors d’une étape S 14, si la période de temps prédéterminée est écoulée, l’incident et les données de signalement d’incident qui lui sont associées sont supprimés de la base de données d’incident 25.
En revanche, si la période de temps prédéterminée n’est toujours pas écoulée, la structure de traitement 9 reste dans l’attente de la réception de nouvelles données de signalement d’incident SIGN susceptibles de modifier le coefficient de fiabilité de l’incident.
L’homme du métier comprend bien entendu ici que cette contrainte liée à la période de temps prédéterminée déclenchée au moment du stockage de l’incident dans la base de données d’incidents 25 est appliquée en permanence. Ainsi, la structure de traitement 9 n’attend pas la réception de nouvelles données de signalement d’incident SIGN et le calcul d’un nouveau coefficient de fiabilité pour supprimer l’incident si la période de temps prédéterminée qui lui est associée est révolue.
La présente invention présente plusieurs avantages.
Tout d’abord, la structure de données permet un traitement et un acheminement efficaces permettant ainsi un signalement intelligent de l’incident auprès des destinataires concernés par l’incident signalé, en évitant ainsi de solliciter un destinataire dont le domaine d’intervention est distinct de l’incident.
Ensuite, la possibilité d’intégrer un contenu multimédia aux données de signalement d’incident et le marquage de ce contenu multimédia à l’aide d’un logiciel de reconnaissance de caractères permet une collecte de données plus objective que les données saisies ou renseignées par un utilisateur à l’aide du terminal utilisateur. L’analyse du contenu multimédia permet en outre de recueillir des informations précises et utiles pour la résolution de l’incident.
Enfin, l’utilisation d’un portail web au contenu personnalisé et mis à jour permet aux destinataires, typiquement des administrations ou des prestataires de services, de pouvoir fonctionner selon un mode dans lequel ils peuvent décider quand accéder aux signalements d’incident et lesquels ils souhaitent résoudre en priorité.

Claims

Revendications
1. Procédé de traitement de données de signalement d’incident mis en œuvre par des moyens informatiques, le procédé comprenant :
- générer (S 10), au niveau d’une structure de traitement (9), une information de signalement d’un incident (INF) en fonction de données de signalement d’incident (SIGN) relatives audit incident et générées au niveau d’un ou plusieurs terminaux utilisateur (7) et comprenant au moins des données de géolocalisation dudit incident,
- sélectionner (Sl l), en fonction de ladite information de signalement d’incident, un ou plusieurs destinataires (3) de l’information de signalement d’incident au sein d’une base de données de destinataires (29) de la structure de traitement, et
- transmettre (S 12) l’information de signalement d’incident audit ou auxdits destinataires sélectionnés.
2. Procédé selon la revendication 1, dans lequel une partie au moins des données de signalement d’incident sont générées via une application exécutée sur le terminal utilisateur.
3. Procédé selon la revendication 2, dans lequel les données de signalement d’incident comprennent en outre des données saisies par un utilisateur du terminal utilisateur via l’application.
4. Procédé selon l’une des revendications précédentes, dans lequel les données de signalement d’incident comprennent des données relatives à un contenu multimédia généré à l’aide du terminal utilisateur.
5. Procédé selon la revendication 4, dans lequel le contenu multimédia est analysé (S4) au niveau de la structure de traitement à l’aide d’un logiciel de reconnaissance d’objets, des données générées par ledit logiciel de reconnaissance d’objets étant adjointes aux données de signalement d’incident.
6. Procédé selon l’une des revendications précédentes, dans lequel les données de géolocalisation de l’incident sont déterminées automatiquement et correspondent à une position courante du terminal utilisateur.
7. Procédé selon l’une des revendications précédentes, dans lequel la structure de traitement comprend une base de données d’incidents (25) au sein de laquelle sont stockés le ou les incidents signalés ainsi que les données de signalement d’incident respectivement associées, les données de signalement d’incident reçues étant analysées pour déterminer (S5), par comparaison avec les données de signalement d’incident précédemment stockées dans la base de données d’incidents, si lesdites données de signalement d’incident sont relatives à un incident déjà stocké dans la base de données d’incidents de sorte que :
- si les données de signalement d’incident reçues sont relatives à un incident stocké dans la base de données d’incidents, lesdites données de signalement d’incident sont associées (S6A) au sein de la base de données d’incidents à l’incident correspondant ;
- sinon, un nouvel incident associé aux données de signalement d’incident reçues est stocké (S6B) dans la base de données d’incidents.
8. Procédé selon la revendication 7 prise en combinaison avec la revendication 2, dans lequel un utilisateur accède à l’application en se connectant à un compte utilisateur qui lui est propre, dans lequel les données de signalement d’incident comprennent un identifiant de compte utilisateur émetteur des données de signalement d’incident, ledit identifiant étant associé au sein d’une base de données d’utilisateurs (27) de la structure de traitement avec un indice de confiance, et dans lequel un coefficient de fiabilité est calculé par la structure de traitement pour chaque incident signalé en fonction de l’indice de confiance du ou des comptes utilisateur émetteurs des données de signalement d’incident relative audit incident, le coefficient de fiabilité d’un incident étant mis à jour (S8) à chaque réception de données de signalement d’incident relative audit incident.
9. Procédé selon la revendication 8, dans lequel la génération de l’information de signalement d’incident et la sélection du ou des destinataires de ladite information de signalement d’incident relative à un incident sont mises en œuvre si et seulement si le coefficient de fiabilité dudit incident est supérieur ou égal à un seuil prédéterminé.
10. Procédé selon la revendication 9, dans lequel un incident et les données de signalement d’incident associées audit incident sont supprimés (S 14) de la base de données d’incidents si le coefficient de fiabilité dudit incident est inférieur au seuil prédéterminé à l’issue d’une période de temps prédéterminée.
11. Procédé selon l’une des revendications précédentes, dans lequel un coefficient de complétude est calculé par la structure de traitement pour chaque incident signalé en fonction d’un critère de précision concernant les données de signalement relatives audit incident, ledit coefficient de complétude étant une variable binaire prenant la valeur 0 lorsque le critère de précision n’est pas satisfait et prenant la valeur 1 lorsque le critère de précision est satisfait, la génération de l’information de signalement d’incident et la sélection du ou des destinataires de ladite information de signalement d’incident relative à un incident sont mises en œuvre si et seulement si le coefficient de complétude dudit incident est égal à 1.
12. Procédé selon l’une des revendications précédentes, dans lequel l’information de signalement d’incident est mise à disposition du ou des destinataires sélectionnés via un portail web (5) au contenu personnalisé et adapté à chaque destinataire.
13. Procédé selon l’une des revendications précédentes, dans lequel l’information de signalement comprend des données relatives à un type de l’incident sélectionné dans une liste préétablie de types d’incident, chaque destinataire stocké dans la base de données de destinataires étant associé à un ou plusieurs types d’incident de ladite liste préétablie de types d’incident.
14. Programme informatique comportant des instructions pour la mise en œuvre du procédé selon l’une des revendications précédentes, lorsque lesdites instructions sont mises en œuvre par au moins un processeur.
15. Structure de traitement (9) de données de signalement d’incident agencée pour générer une information de signalement d’un incident (INF) en fonction de données de signalement d’incident (SIGN) relatives audit incident et générées par un ou plusieurs terminaux utilisateur (7) et comprenant au moins des données de géolocalisation dudit incident, ladite structure de traitement étant agencée en outre pour sélectionner, en fonction de ladite information de signalement d’incident, un ou plusieurs destinataires (3) de l’information de signalement d’incident, ladite structure de traitement comprenant une base de données de destinataires (29) au sein de laquelle ledit ou lesdits destinataires sont sélectionnés, ladite structure de traitement étant agencée en outre pour transmettre l’information de signalement d’incident audit ou auxdits destinataires sélectionnés.
PCT/FR2019/053057 2018-12-21 2019-12-13 Procédé et structure de signalement d'incident WO2020128252A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP19842812.0A EP3899747A1 (fr) 2018-12-21 2019-12-13 Procédé et structure de signalement d'incident
US17/416,157 US20220078597A1 (en) 2018-12-21 2019-12-13 Incident Reporting Method and Structure

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1874032A FR3090930A1 (fr) 2018-12-21 2018-12-21 Procédé et structure de signalement d’incident
FR1874032 2018-12-21

Publications (1)

Publication Number Publication Date
WO2020128252A1 true WO2020128252A1 (fr) 2020-06-25

Family

ID=66641104

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2019/053057 WO2020128252A1 (fr) 2018-12-21 2019-12-13 Procédé et structure de signalement d'incident

Country Status (4)

Country Link
US (1) US20220078597A1 (fr)
EP (1) EP3899747A1 (fr)
FR (1) FR3090930A1 (fr)
WO (1) WO2020128252A1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140365574A1 (en) * 2013-06-07 2014-12-11 Lennie Earl Franks System and method for incident reporting and notification

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10157369B2 (en) * 2009-02-05 2018-12-18 International Business Machines Corporation Role tailored dashboards and scorecards in a portal solution that integrates retrieved metrics across an enterprise
US9258419B2 (en) * 2009-03-25 2016-02-09 General Motors Llc System and method for managing emergency calls
CA2947936C (fr) * 2013-05-04 2023-02-21 Christopher Decharms Technologie de securite mobile
US10045187B1 (en) * 2016-03-25 2018-08-07 Kastle System International Llc Emergency action systems and methods
US11259166B1 (en) * 2020-09-24 2022-02-22 Motorola Solutions, Inc. Tip submit method, apparatus, and system for public-safety tip submissions

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140365574A1 (en) * 2013-06-07 2014-12-11 Lennie Earl Franks System and method for incident reporting and notification

Also Published As

Publication number Publication date
US20220078597A1 (en) 2022-03-10
EP3899747A1 (fr) 2021-10-27
FR3090930A1 (fr) 2020-06-26

Similar Documents

Publication Publication Date Title
US10809069B2 (en) Location based content aggregation and distribution systems and methods
US11295623B2 (en) Community drone monitoring and information exchange
US9715233B1 (en) System and method for inputting a second taxi-start location parameter for an autonomous vehicle to navigate to whilst reducing distraction
US10425422B1 (en) Message content modification devices and methods
US10171964B2 (en) Location-oriented services
US11011159B2 (en) Detection of potential exfiltration of audio data from digital assistant applications
EP2686781A1 (fr) Controle de publication de message relatif a un utilisateur
WO2018063516A1 (fr) Indexation à contexte amélioré
FR2864279A1 (fr) Procede pour ajouter des donnees de caracterisation pendant une saisie d'image
WO2020128252A1 (fr) Procédé et structure de signalement d'incident
EP2806386A1 (fr) Procédé et systeme pour signaler automatiquement un évènement à partir de fichiers reçus sur un serveur informatique
FR3072487A1 (fr) Procede et systeme de traitement de donnees relatives a un incident
WO2006063621A1 (fr) Procede de mise a jour automatique de contenus numeriques, entre des elements mobiles informatiques, element mobile informatique adapte a un tel procede et reseau de diffusion de contenus numeriques
FR3106231A1 (fr) Procédé et système pour afficher sur une carte numérique, la position géographique de véhicules disponibles à la réservation
FR3110751A1 (fr) Procédé d’estimation du trafic automobile
EP2464068B1 (fr) Système de gestion globale de filtrage personnalisé basé sur un circuit d'échange d'informations sécurisé et procédé associé
FR2857477A1 (fr) Procede de mise a jour automatique de contenus numeriques, entre des elements mobiles informatiques, element mobile informatique adapte a un tel procede et reseau de diffusion de contenus numeriques
Post et al. Location is Everything
EP1921548A1 (fr) Procédé et système de communication pour fournir au moins une réponse à une requête d'un utilisateur
EP3058543A1 (fr) Système d'échange d'informations entre différents utilisateurs et différentes autorités
Popoola et al. GWG: A PARTICIPATORY LOCATION-BASED INFORMATION SYSTEM TOWARDS A MORE SECURED COUNTRY
FR2897493A1 (fr) Procede de diffusion de messages, support de donnees, plate-forme de diffusion et systeme de diffusion associes
FR2860328A1 (fr) Systeme d'information d'usagers d'un reseau de transport
FR2948791A1 (fr) Systeme de geolocalisation par analyse linguistique
FR2860676A1 (fr) Procede et systeme d'echange d'informations point a point par l'intermediaire d'un reseau de diffusion

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19842812

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2019842812

Country of ref document: EP

Effective date: 20210721