DOMAINE

Le domaine de l’invention se rapporte à celui des dispositifs permettant à une personne d’obtenir une assistance auprès d’une communauté d’utilisateurs ou d’un service d’assistance dédié. Plus particulièrement, le domaine de l’invention se rapporte aux domaines des procédés de gestion de l’assistance à une personne ayant sollicité une aide par l’émission d’un message SOS à partir d’un équipement mobile.

ETAT DE L’ART

Il existe des méthodes permettant à un groupe d’individus de porter une assistance à une personne ayant sollicité de l’aide par l’intermédiaire d’un équipement électronique mobile. De tels systèmes existent par exemple pour permettre à une personne âgée de contacter son réseau proche afin de les avertir d’un danger.

C’est le cas par exemple de méthodes permettant de générer une alerte auprès de services d’assistance public ou privé permettant d’avertir de l’imminence d’un danger ou d’un accident. Une telle méthode est décrite dans le document de brevet US2008214142. Un tel système peut être utilisé à partir d’un téléphone portable par exemple.

Avec l’émergence des réseaux sociaux et des outils permettant de définir des services auprès de communautés, certains services d’assistance permettent de générer des messages d’urgence auprès de communautés. C’est le cas des systèmes décrits dans les documents US7574194 ou même auprès d’un ensemble d’utilisateurs dans le voisinage de l’appel d’urgence comme cela est décrit dans le document CN107071 160.

Un des enjeux majeurs est de pouvoir améliorer la rapidité de l’action auprès d’une personne en danger et de permettre de coordonner l’assistance apportée.

Or les méthodes actuelles ne permettent pas toujours de bien coordonner l’assistance successivement à l’émission de l’appel. Il peut arriver, lorsqu’un individu de la communauté sollicitée répond à un appel d’urgence, que la personne contactée soit dans l’incapacité de résoudre le problème. Il est alors nécessaire de relayer la demande d’assistance en apportant des précisions ou en s’adressant à des individus en particulier.

La solution décrite dans le document US7574194 propose d’augmenter la description de la situation rencontrée. Mais cette situation ne peut pas toujours être bien renseignée notamment parce que cette description demande une lucidité et un temps que la personne ne peut être en mesure de fournir compte tenu de la situation de danger ou d’accident.

Il existe donc un besoin de définir une solution permettant de contacter un réseau de personnes susceptibles d’aider une personne ayant émis un appel d’urgence tout en apportant une information enrichie sur le suivi de l’assistance d’une personne.

RESUME DE L’INVENTION

Le procédé de l’invention permet de résoudre les problèmes précités.

Selon un premier aspect l’invention concerne une méthode de gestion de l’assistance à une personne en réponse à l’émission d’une alerte comportant :

^■ Émission d’une alerte SOS à partir d’un premier équipement mobile d’un premier utilisateur au moyen d’une interface sans fil auprès d’un premier ensemble de terminaux d’une pluralité d’utilisateurs ayant chacun un identifiant d’appel, les identifiants d’appel étant enregistrés dans une mémoire du premier équipement électronique mobile ou d’un équipement distant ;

^■ Établissement d’une première communication bidirectionnelle entre le premier équipement et un terminal donné du premier ensemble d’un utilisateur donné, appelé « utilisateur-assistant » ;

^■ Génération automatique d’une pluralité de premières notifications auprès d’un sous-ensemble de terminaux du premier ensemble, chacune des premières notifications comportant au moins une donnée identifiant l’utilisateur-assistant ;

^■ Génération automatique d’une pluralité de secondes notifications auprès des terminaux du second sous-ensemble, chaque seconde notification comportant un statut relatif au traitement de l’alerte par l’utilisateur-assistant.

Un avantage est de permettre de coordonner l’assistance apportée à un individu ayant émis un SOS, notamment en tenant informé automatiquement les autres utilisateurs de la communauté ayant reçu le SOS du statut de la réponse apportée par l’utilisateur ayant répondu à l’appel SOS.

Selon un mode de réalisation, l’émission de l’alerte SOS est générée consécutivement à au moins l’un des évènements de la liste suivante :

^■ Une pression au moins pendant une durée prédéfinie sur une interface de commande du premier équipement ;

^■ Une détection d’une accélération dépassant un seuil prédéfini, ladite accélération étant acquise d’un accéléromètre agencé au sein du premier équipement ;

^■ Une détection d’une séquence d’accélération ayant un minimum de similitude avec un profil d’accélération sur une période prédéfini, ladite séquence d’accélération étant acquise d’un accéléromètre agencé au sein du premier équipement.

Un avantage est de générer des messages SOS automatiquement lorsqu’un cas de figure correspondant à un danger ou un accident est détecté par l’équipement utilisateur grâce à au moins un capteur.

Selon un mode de réalisation, l’émission de l’alerte SOS est générée à partir d’un protocole de communication de faible débit de type GSM, GPRS, LTE-M ou NB-IOT. Un avantage est de proposer un procédé adapté à un équipement peu cher, simple et comportant un minimum de composants.

Selon un mode de réalisation, la première communication bidirectionnelle est établie consécutivement à la validation d’une commande d’acceptation sur un terminal donné de l’utilisateur-assistant de la pluralité d’utilisateurs. Un avantage est de permettre d’établir une communication en un simple geste d’acceptation telle qu’une commande sur une interface utilisateur.

Selon un mode de réalisation, la première communication bidirectionnelle est automatiquement établie consécutivement à une demande d’appel provenant du terminal donné de l’utilisateur assistant. Un avantage est de générer automatiquement du point de vue de l’individu en détresse une proposition de réponse d’un utilisateur de la communauté.

Selon un mode de réalisation, la première communication bidirectionnelle est automatiquement établie consécutivement à une demande d’appel provenant du premier équipement consécutivement à la réception d’une notification comportant une information identifiant l’utilisateur-assistant ayant émis une commande d’acceptation. Un avantage est de permettre à l’individu de sélectionner une aide adaptée à la situation par exemple en acceptant ou refusant à son tour la réponse d’un utilisateur.

Selon un mode de réalisation, la première notification est automatiquement émise consécutivement à l’établissement de la première communication bidirectionnelle depuis :

^■ le premier équipement, ou ;

^■ le terminal donné ayant validé la commande d’acceptation ou ;

^■ un serveur de données comportant une information d’identification des utilisateurs du second ensemble.

Selon un mode de réalisation, l’alerte SOS comporte une information identifiant le premier utilisateur et une position géographique du premier équipement.

Selon un mode de réalisation, la première notification comporte une position géographique de l’utilisateur assistant. Un avantage est de tenir informé les autres utilisateurs du suivi d’appel de la réponse apportée. Notamment, l’identité de l’utilisateur assistant est communiqué, ce qui permet à chacun de ne pas générer des appels parasites à ce moment auprès de l’individu ayant émis le SOS.

Selon un mode de réalisation, la seconde notification comporte une durée d’appel et un indicateur de résolution. Un avantage est de délivrer un maximum d’information à la communauté afin de se faire une idée de la situation et de l’aide apportée. Chaque élément communiqué permet à chacun de se faire un avis de la situation sans générer des appels inutiles de prise d’information.

Selon un mode de réalisation, lorsque la première communication bidirectionnelle est interrompue, une demande d’établissement d’une nouvelle communication est automatiquement engagée par le premier équipement ou par le terminal donné de l’utilisateur-assistant. Selon un mode de réalisation, lorsqu’aucune commande d’acceptation n’a été établie dans une période de temps prédéfinie :

^■ un nouveau message SOS est émis au sein du premier ensemble ;

^■ un message est émis vers un centre d’appels prédéfini.

Un avantage est d’apporter une solution de replis au premier individu de manière automatique lorsqu’aucune commande d’acceptation n’est spontanément validée suite à l’émission du premier SOS.

Selon un mode de réalisation, l’utilisateur-assistant peut, à partir d’une commande prédéfinie, transmettre une consigne entraînant l’établissement d’une seconde communication bidirectionnelle entre le premier utilisateur et un second utilisateur donné. Selon un mode de réalisation, l’utilisateur-assistant peut, à partir d’une commande prédéfinie, engager l’établissement d’une seconde communication bidirectionnelle entre le premier utilisateur et un second utilisateur donné. Un avantage est de déterminer le plus rapidement possible la meilleure solution pour répondre au SOS.

Selon un autre aspect, l’invention concerne un produit programme d’ordinateur comportant un calculateur et une mémoire pour la mise en œuvre des étapes du procédé se rapportant au premier équipement. Le programme comprend des instructions de code de programme exécutées sur un ordinateur pour la mise en œuvre des étapes du procédé de l’invention se rapportant au premier équipement utilisateur.

Selon un autre aspect, l’invention concerne un produit programme d’ordinateur comportant un calculateur et une mémoire pour la mise en œuvre des étapes du procédé de l’invention se rapportant à un terminal établissant la première communication. Le programme comprend des instructions de code de programme exécutées sur un ordinateur pour la mise en œuvre des étapes du procédé de l’invention se rapportant à un terminal Ï3 établissant la première communication et/ou celui émettant le message d’alerte. Un avantage est de permettre de télécharger un logiciel à distance sur un équipement mobile afin de réaliser le procédé de l’invention.

Selon un autre aspect, l’invention concerne un équipement électronique mobile comportant une interface de commande comportant un actionneur par lequel la génération d’une commande entraîne l’émission d’un message SOS à destination d’un premier ensemble d’utilisateurs au moyen d’une interface de communication sans fil, ledit équipement comportant des moyens pour :

^■ établir une première communication bidirectionnelle avec un terminal donné du premier ensemble d’un utilisateur donné, appelé « utilisateur assistant » ;

^■ générer automatiquement une pluralité de premières notifications auprès d’un sous-ensemble de terminaux du premier ensemble, chacune des premières notifications comportant au moins une donnée identifiant l’utilisateur-assistant ;

^■ générer automatiquement une pluralité de secondes notifications auprès des terminaux du second sous-ensemble, chaque seconde notification comportant un statut relatif au traitement de l’alerte par l’utilisateur-assistant.

Selon un mode de réalisation, le premier équipement comporte des moyens pour décoder l’identifiant d’appel ou l’identité de l’utilisateur assistant afin de générer automatiquement une notification aux autres utilisateurs, ladite notification comportant une information relative à l’identité de l’utilisateur assistant ou de son identifiant d’appel.

Selon un mode de réalisation, l’équipement comporte des moyens pour mettre en œuvre les étapes du procédé de l’invention.

BREVE DESCRIPTION DES FIGURES

D’autres caractéristiques et avantages de l’invention ressortiront à la lecture de la description détaillée qui suit, en référence aux figures annexées, qui illustrent :

^■ figure 1 : un exemple d’une séquence d’échange de messages selon le procédé de l’invention ;

^■ figure 2 : un cas de figure représentant un individu comportant un équipement selon l’invention ayant émis un message SOS auprès d’une communauté d’utilisateurs.

DESCRIPTION

Dispositif

L’invention se rapporte à un dispositif et à un procédé. Le dispositif est désigné comme un équipement électronique mobile. Il comprend à minima un calculateur, une mémoire, une interface de commande, une interface de communication et une batterie ou une source d’énergie. Selon un mode de réalisation, l’interface de communication est une interface 2G, GSM, GPRS, 3G, LTE-M, NB-IOT, Sigfox, LoRa, 5G. Un intérêt est de définir un dispositif de faible coût destiné à émettre un signal d’urgence. Une liaison sans fil faible débit suffit à réaliser les fonctions minimales de communication. Toutefois, l’équipement de l’invention peut comprendre une interface de communication large bande de type 4G ou Wifi ou tout autre protocole de communication sans fil.

Selon un mode de réalisation, l’équipement de l’invention est simplifié, il comporte un minimum de composants et de fonctionnalités. En effet, l’équipement de l’invention permet, par exemple, à une personne âgée d’émettre, en cas d’urgence, un signal SOS à une communauté de personnes dont des amis, des voisins ou de la famille ou encore toute autre connaissance.

Selon un exemple de réalisation, l’interface de commande de l’équipement de l’invention est un bouton dont une pression pendant une durée prédéfinie permet d’émettre un message SOS. L’équipement EQo comporte une interface audio comportant un micro et une sortie casque permettant de délivrer et de transmettre un message audio au moyen d’une communication supportant de la voix. L’équipement comporte tous les éléments radio permettant de moduler, démoduler, décoder et coder des trames en bande de base du signal radio.

Selon un mode de réalisation, l’équipement EQo de l’invention comporte au moins un accéléromètre. Il peut s’agir, par exemple, d’un accéléromètre dit « trois axes » permettant de délivrer trois mesures d’accélération. L’émission du message SOS peut alors être automatiquement déclenchée lorsqu'au moins une composante d’accélération mesurée dépasse un certain seuil. Selon un autre exemple, le message SOS peut être émis automatiquement lorsque l’accélération mesurée est sensiblement proche d’un profil d’accélération prédéfini. A titre d’exemple, un profil d’accélération comportant une première phase d’accélération correspondant à une chute d’une personne suivie d’une seconde phase d’absence d’accélération peut correspondre à une chute d’une personne qui s’est évanouie. Le calculateur et la mémoire de l’équipement EQo permettent d’exploiter les données du capteur d’accélération. Un avantage est de permettre de détecter un immobilisme suspect d’une personne ou une chute d’une personne.

Un système de localisation peut aussi être exploité pour délivrer une position, telle qu’une position GPS. Cette donnée peut permettre de détecter un trajet anormal d’un individu.

Selon un autre exemple, l’équipement comporte un gyroscope permettant d’améliorer la détection de courbes liées une activité anormale pouvant correspondre à un danger imminent ou à un accident.

Lorsqu’une donnée de position ou d’orientation ou d’accélération est considérée sortir d’un champ d’application normal, un message SOS peut automatiquement être émis au sein de la communauté. Le calculateur est alors en mesure d’effectuer des opérations de comparaison, de corrélation ou tout autre calcul permettant de déterminer une singularité des paramètres relative à l’environnement de l’équipement EQo.

Selon un mode de réalisation, l’équipement EQo comporte un capteur de température. Une détection d’une température supérieure à un seuil permet d’engager automatiquement l’émission d’un message SOS à la communauté d’abonnés. Cette option permet d’obtenir une assistance rapidement en cas d’incendie par exemple.

Selon un mode de réalisation, l'équipement si EQo sort d'une zone géographique prédéfinie, l’émission d’un message SOS peut être automatique émis vers la communauté d’utilisateur du service. Cet évènement peut être déclenché par une fonction de géorepérage, plus connue sous le terme de « geofencing » dans la terminologie anglosaxonne. La mise en œuvre de cette fonction permet de surveiller à distance la position et le déplacement d'un objet et/ou d’une personne et de prendre des mesures, telles que l’émission automatique d’un message, si la position ou le déplacement s'écarte de certaines valeurs fixées d'avance.

Selon un mode de réalisation, l’équipement EQo est un équipement simplifié comportant un unique bouton. L’interface de commande définie par le bouton est alors préférentiellement mécanique. Une pression pendant un laps de temps donné, permet de générer un message SOS à la communauté. La durée de pression sur le bouton peut être, par exemple, configurée entre 2s et 4s, par exemple pendant 3s. Selon un mode de réalisation, l’équipement EQo comporte une batterie, par exemple de type Lithium-Ion. La recharge de la batterie peut être effectuée en déposant l’équipement EQo sur un socle alimenté par le secteur. Selon un exemple de réalisation, il comprend une prise de type USB ou toute autre connectique électrique permettant de recharger une batterie.

Selon un mode de réalisation, l’équipement EQo est étanche, c’est- à-dire « waterproof ». Il autorise une immersion dans l’eau dans une profondeur allant jusqu’à quelques mètres. Selon un mode de réalisation, l’équipement EQo est muni d’un capteur d’humidité ou tout type de capteur permettant de déduire que l’équipement EQo est dans un milieu liquide tel que l’eau. Lorsque le capteur détecte une valeur supérieure à un seuil prédéfini indiquant que l’équipement EQo est dans un milieu aqueux, ce qui peut par exemple correspondre à une chute dans une piscine, une génération automatique d’un message SOS est émis vers la communauté d’utilisateurs. Le message émis peut comprendre une information issue de la valeur mesurée par le capteur comme « équipement noyé » afin de renseigner les utilisateurs sur le contexte de l’émission d’urgence.

Selon un mode de réalisation, le message SOS peut être émis que lorsqu’une double condition est remplie. Par exemple la double condition peut correspondre à une détection d’eau suivi d’un immobilisme de l’équipement EQo. Tout autre combinaison d’évènement peut être configuré dans l’équipement afin de paramétrer les conditions d’émission d’un message SOS.

Configuration de l’équipement

Le procédé de l’invention permet à un individu Uo d’avertir une pluralité d’utilisateurs {Ui}ie [i ;N] d’un danger imminent ou d’un accident au moyen du premier équipement. La liste des utilisateurs est alors préalablement définie. Ils sont vus comme des abonnés au service du premier individu Uo. Selon un mode de réalisation, le procédé de l’invention comporte une étape de configuration. L’étape de configuration a préalablement permis de définir qui est susceptible de recevoir des messages SOS, soit de messages d’urgence, provenant du premier individu Uo.

A cette fin, selon un premier mode de réalisation, la configuration peut être réalisée directement sur l’équipement du premier individu Uo. Il s’agit alors de définir un carnet d’adresses particulier en mentionnant les numéros d’appel des abonnés au service d’urgence.

Selon un autre mode de réalisation, la configuration peut se faire en accédant à un serveur de données distant SERVo. Un intérêt est de permettre une configuration à distance. Dans ce cas, la configuration peut être réalisée depuis n’importe quel poste informatique connecté ou équipement mobile avec des droits suffisants. Le carnet d’adresses est alors accessible en ligne et peut être modifié lorsqu’un utilisateur possède les droits de lecture, et éventuellement de modifications pour modifier la liste des utilisateurs. La gestion des droits peut être réalisée par exemple au moyen d’un serveur d’authentification dédié (non représenté) ou du même serveur SERVo. Un avantage est qu’une personne de la communauté d’un individu Uo peut paramétrer son carnet d’adresses. Ce cas de figure peut se produire lorsqu’un enfant ou un petit enfant d’un individu paramètre le compte pour ce dernier.

Selon un mode de réalisation, le procédé de l’invention prend en compte une gestion de droits des différents utilisateurs. À titre d’exemple, un utilisateur Ui peut avoir les droits pour éditer les nouveaux utilisateurs et configurer les priorités d’appel, notamment des critères à prendre en compte dont par exemple :

- l’émission prioritaire d’un message d’urgence auprès d’une sous- communauté constituée des personnes les plus proches du premier individu ;

- l’émission d’un message d’urgence à toute la communauté dans un second temps, par exemple après un laps de temps écoulé, consécutivement à l’émission d’un premier message d’urgence prioritaire ;

- prise en compte d’au moins une position géographique des utilisateurs dans la génération des messages SOS ;

- hiérarchisation de l’émission des messages d’urgences dans le temps en fonction du critère géographique,

- etc.

Génération d’un SOS

La figure 1 représente un exemple de réalisation d’une séquence d’échanges de données selon le procédé de l’invention. Un premier individu Uo comportant un équipement électronique EQo de l’invention émet une alarme SOS. Cette étape est notée GEN_ALARM sur la figure 1 . Elle permet l’émission d’un message SOS à destination d’une pluralité d’utilisateurs d’un service accessible par l’intermédiaire d’un terminal.

Les équipements, notés ici Ti , T2, T3, sont chacun associé à un utilisateur noté respectivement U1, U2, U3. Les terminaux peuvent être, par exemple, un téléphone intelligent, une tablette, un téléphone portable ou un équipement de communication dédié. Le service peut être par exemple accessible par l’intermédiaire d’une application ou d’un logiciel.

L’exemple de résiliation est décrit ci-après avec 3 « utilisateurs- abonnés » au service d’un individu Uo. Ils sont appelés indifféremment un abonné ou un utilisateur. L’invention s’applique également avec une pluralité d’utilisateurs abonnés au service d’un individu sans limite de nombre. Il est possible de paramétrer le nombre d’utilisateurs-abonnés au moyen d’une interface, par exemple, du premier équipement EQo ou d’un terminal Ti ou encore depuis un ordinateur connecté à un réseau avec les droits d’accès nécessaires le cas échéant.

Lorsque le premier individu émet un message SOS, il est automatiquement émis vers une pluralité de terminaux dont les identifiants d’appels sont connus soit du premier équipement EQo soit d’un serveur SERVo. À titre d’exemple, les identifiants d’appel peuvent être préenregistrés dans une mémoire du premier équipement EQo. Lors d’une phase de configuration, les numéros peuvent être par exemple enregistrés dans un répertoire du premier équipement EQo.

Selon un autre mode de réalisation, l’équipement EQo émet un message SOS vers un serveur SERVo qui peut accéder à un répertoire préconfiguré de sorte à réémettre automatiquement autant de messages SOS que d’utilisateurs Ui ont été préalablement configurés. Un avantage de ce mode de réalisation, est de rendre accessible le répertoire du serveur SERVo à au moins un utilisateur U1, U2 ou U3 de sorte qu’il puisse le modifier, ajouter ou retirer une personne. Un intérêt est de permettre de configurer le service pour un proche, par exemple, âgé.

Chaque terminal T1, T2, T3 adressé par le message SOS, s’il est accessible depuis un réseau de communication, reçoit le message SOS. Cette étape est notée RECEPT_SOS dans chaque terminal T1, T2 et T3. Chaque terminal T1 , T2, T3 génère alors un indicateur afin de prévenir son utilisateur Ui, U2, U3 de l’arrivée d’un message d’urgence. Il peut s’agir d’un indicateur sonore, visuel ou mécanique tel qu’une vibration ou une combinaison d’indicateurs. Dans l’exemple de réalisation de la figure 1 , parmi les utilisateurs U1, U2, U3, un utilisateur U3 accepte de répondre au message SOS en validant une commande d’acceptation notée CACC.

Dans l’exemple de la figure 1 , l’utilisateur II3 valide le premier la réception du message d’urgence SOS indiquant qu’il prend l’appel. Une première communication bidirectionnelle COM_1 entre le terminal T3 et le premier équipement EQo démarre alors.

Prise en compte de la position géographique

Selon un mode de réalisation, la position géographique du premier individu Uo est émise dans le message SOS.

Selon un mode de réalisation, les positions GPS de la communauté sont partagées et les notifications sont émises préférentiellement selon une séquence temporelle dépendante des positions GPS de chaque utilisateur. Un premier message SOS d’urgence est émis à l’utilisateur le plus proche géographiquement du premier individu Uo et ainsi de suite jusqu’au dernier message SOS émis à l’utilisateur situé le plus loin de l’individu.

Le calcul des distances peut être effectué entre la position récupérée du premier individu Uo et la position de chaque utilisateur Ui.

Selon un mode de réalisation, les positions GPS ne sont pas nécessairement partagées et dans ce cas une adresse par défaut est choisie, par exemple l’adresse du lieu de travail ou du domicile d’un utilisateur. Cette dernière peut être préalablement enregistrée et/ou partagée. Selon un autre mode de réalisation, uniquement l’adresse définie par un utilisateur Ui est choisie. Cette option peut être potentiellement recommandée lorsqu’un utilisateur ne souhaite pas partager sa position courante.

Selon un mode de réalisation, les messages d’urgence sont envoyés en cascade suivant un intervalle de temps prédéfini entre chaque émission. Selon un autre mode de réalisation, le second message d’urgence Mo’ est émis lorsque le premier message d’urgence Mo n’a pas abouti à établir une communication COM 1. Selon un mode de réalisation, si la position géographique d’un utilisateur Ui est dans une zone définie comme hors de portée, le message d’urgence Mo n’est pas émis à l’utilisateur en question. Dans un autre cas de figure, il est reçu, mais il n’est pas traité, c’est-à-dire que le terminal n’émet pas d’indicateur à l’utilisateur pour le prévenir de l’émission d’un message SOS. Cela permet de ne pas émettre un message d’urgence ou de ne pas notifier de sa réception à un utilisateur situé dans un fuseau horaire trop éloigné du premier individu Uo, par exemple lorsqu’il est en vacances.

Établissement d’une communication

Selon un premier mode de réalisation, lorsque la validation d’une commande d’acceptation CACC pour répondre au message SOS est activée, par exemple ici par le terminal Ï3, une communication est automatiquement établie entre le premier équipement EQo et le terminal Ï3.

Selon un premier exemple, la communication COM_1 est alors initialisée par le terminal T3. Selon un mode de réalisation, le numéro d’appel du premier équipement EQo est inséré dans le message SOS de sorte que l’analyse du message permette d’extraire le numéro d’appel au moyen d’un calculateur du terminal T3. Selon un autre exemple, le numéro d’appel est récupéré dans une mémoire du terminal T3 ou dans le serveur distant SERVo à partir d’une information identifiant le premier individu Uo. Dans ce dernier cas de figure, un échange de données peut avoir lieu entre le serveur SERVO et le terminal T3 préalablement à l’établissement de la communication COM_1 .

Selon un second exemple, une réponse au message SOS est émise par le terminal T3 sous forme d’un message d’acceptation CACC de réponse au message SOS. Dans ce cas de figure, la communication COM_1 est automatiquement initiée par l’équipement EQo vers le terminal T3 ayant accepté le message SOS. Si c’est l’équipement EQo qui initie l’appel, l’établissement de la communication COM_1 peut par exemple être préalablement soumis à une acceptation de l’individu Uo qui valide la pertinence d’établir une communication avec tel ou tel utilisateur. Lorsqu’une confirmation est attendue par l’individu Uo, selon un mode de réalisation, aux termes d’un laps de temps prédéterminé, une communication est de toute manière engagée automatiquement. Ce cas permet de traiter les cas de figues dans lesquels l’individu Uo n’est pas en mesure de valider l’identité de l’utilisateur souhaitant établir une communication COM_1.

Selon un mode de réalisation, la communication COM_1 établie est une communication audio, telle qu’une communication téléphonique entre le premier équipement EQo et le terminal Ï3. Cette communication permet de faire dialoguer le premier individu Uo avec le troisième utilisateur U3.

La figure 1 représente le début D_COM_1 de l’établissement de la communication COM_1. La double flèche représente les deux cas de figure dans lesquels c’est soit le terminal T3 qui instancie la communication, soit l’équipement EQo.

La fin de la communication est annotée F_COM_1 . Elle peut être engagée par l’un ou l’autre des utilisateurs Uo ou U3. Selon un mode de réalisation, la fin de la communication peut être engagée automatiquement. Cela peut être par exemple le cas suite à une action du premier individu Uo ou du troisième utilisateur U3 telle qu’un acquittement de l’incident comme résolu ou un transfert de l’appel vers un autre utilisateur ou encore tout autre action découlant de l’appelé ou de l’appelant.

Pendant la communication, le procédé de l’invention permet de générer automatiquement des notifications auprès des autres utilisateurs. Ces notifications pendant la communication COM_1 sont notées GEN_NOTIF_1. Selon le mode de réalisation, ou bien même la nature des notifications, elles peuvent provenir du premier équipement EQo ou du terminal T3. Dans la figure 1 , une notification M1 est émise depuis le premier équipement EQo vers les terminaux T1 et T2, c’est-à-dire les autres terminaux n’ayant pas établi de communication, mais dont les utilisateurs sont susceptibles d’être intéressés par l’évolution de la prise d’appel par l’utilisateur U3. Le bloc GEN_NOTIF_1 est également indiqué en pointillé du côté du terminal T3 dans la figure 1 afin d’illustrer la possibilité que les notifications puissent provenir de ce terminal T3.

Les notifications {Mi} peuvent être émises par l’équipement EQo ou le terminal T3, mais également directement depuis un serveur distant, par exemple le serveur SERVo qui a permis d’établir d’émettre le message SOS d’urgence et/ou la communication COM_1.

Selon un mode de réalisation, certaines notifications sont directement émises de manière automatique vers les terminaux T1 et T2, d’autres sont émises consécutivement à une action de l’utilisateur Ih ou de du premier individu U1.

Dans l’exemple de la figure 1 , la première notification M1 comprend une information indiquant l’identité de l’utilisateur II3 aux autres utilisateurs U1 , U2 n’ayant pas répondu au message d’urgence Mo ou ayant répondu après l’utilisateur II3. Dans un exemple de réalisation, le numéro d’appel de l’utilisateur II3 est également renseigné dans la notification M1.

Dans un mode de réalisation, non représenté, d’autres notifications sont émises vers les utilisateurs U1 , U2, notamment une notification informant du statut de la communication COM_1 parmi une liste de statuts : {prise d’appel ; en cours ; fin de communication, etc.}. Selon un autre mode de réalisation, la position géographique du premier individu Uo peut être indiquée dans une notification ou encore la position géographique du troisième utilisateur U3.

Un intérêt est de tenir au courant la communauté d’abonnés afin que ces derniers puissent obtenir un minimum d’informations quant au suivi de la prise d’appel par le troisième utilisateur U3.

Selon un autre mode de réalisation, les utilisateurs U1, U2 de la communauté peuvent recevoir des notifications émises par une action du premier individu Uo ou du troisième utilisateur U3. Les notifications peuvent être des messages textes ou des images, elles peuvent également être des notifications préenregistrées et proposées à l’un ou à l’autre du premier individu Uo ou du troisième utilisateur U3. À titre d’exemple, une notification préenregistrée peut être « APPEL D’UN MEDECIN REQUISE » ou « DEPLACEMENT D’UN UTILISATEUR REQUIS » ou « ACCIDENT CARDIAQUE », etc.

Ainsi, une liste de notifications peut être présentée pendant la communication COM_1 au moyen d’une interface interactive proposée dans le service. Par exemple, l’utilisateur U3 peut, pendant qu’il parle au premier individu Uo, générer des notifications selon le cas de figure rencontré.

Notification de fin d’appel M2

Le procédé de l’invention comprend une étape à la fin de la communication COM_1 d’émission d’une notification de fin d’appel M2 permettant de transmettre un statut de résolution de l’alarme aux autres utilisateurs Ui , U2. Il peut s’agir d’un statut de type « INCIDENT CLOS » avec un champ de description permettant d’indiquer comment l’incident a été clos.

La notification de fin d’appel M2 peut également comprendre la durée de la communication COM_1 .

Selon un mode de réalisation, le troisième utilisateur U3 peut indiquer aux autres utilisateurs que l’incident n’est pas clos. Dans ce cas de figure, une personne de la communauté peut décider d’engager établissement d’une communication avec le premier individu U0. Si ce n’est pas le cas, le procédé de l’invention permet de générer un nouvel envoi de message SOS à la communauté en cas d’échec d’une première tentative de résolution par l’établissent d’une communication COM_1 .

Dans un mode de réalisation complémentaire, l’utilisateur U3 a, en outre, la possibilité de sélectionner un statut proposé par son interface ou de le définir lui-même selon le mode de réalisation.

Selon un mode de réalisation, le premier individu U0 peut lui aussi générer une notification M3 auprès de la communauté indiquant que le problème est résolu ou qu’il a évolué ou qu’il reste non résolu. Cette étape est notée GEN_NOTIF_3 sur la figure 1 .

Lorsque le statut n’est pas clos et que la communication COM_1 est terminée, un second message SOS peut être automatiquement réémis à destination des autres destinataires Ui et U2 afin qu’un autre utilisateur puisse répondre à l’appel d’urgence émis par le premier individu.

Selon un autre mode de réalisation, le troisième utilisateur U3 peut indiquer l’identité d’un utilisateur U2 devant être joint en priorité pendant l’appel COM_1 ou au moment de terminer l’appel COM_1 dont soit dans une notification de type M1 (émise pendant l’appel COM_1 ) ou de type M2 (émise après l’appel COM_1 )

Selon un autre mode de réalisation, le troisième utilisateur U3 peut générer une notification visant à établir une nouvelle communication entre lui et le premier individu. Ce cas peut se produire lorsque la première communication COM_1 a été interrompue, par exemple, consécutivement à un problème lié à un déficit de couverture réseau ou à un problème de batterie ou encore à tout autre type de problème ayant eu pour conséquence de suspendre la communication COM_1 . Le troisième utilisateur U3 peut donc solliciter en priorité un appel vers le premier équipement EQo avant qu’une nouvelle alarme SOS ne soit réémise par ce dernier.

Selon un mode de réalisation, l’utilisateur Ih peut directement activer un appel vers un centre d’urgence tel que le SAMU, un service de police ou de pompiers ou tout autre service public ou privé permettant d’assurer un service d’assistance d’urgence. Un tel service peut être assuré au moyen d’un serveur centralisé d’appel SERV1. Il peut également activer une commande permettant de mettre en relation un tel service avec le premier individu Uo.

La figure 2 représente un individu Uo comportant un équipement de l’invention EQo et ayant émis un message d’urgence SOS auprès d’une communauté d’utilisateurs U1, U2, U3.

Un serveur SERVo est représenté sur la figure 2. Le serveur SERVo comprend des données relatives à chaque utilisateur U1 , U2, U3 telles que les numéros d’appel et les identifiants de chaque utilisateur. Le serveur SERVo est utilisé, dans ce cas de figure, pour recevoir le message SOS du premier individu Uo et pour réémettre vers la communauté d’abonnés du premier individu Uo. Dans ce dernier, le serveur SERVo peut être le serveur centralisant les échanges au sein de la communauté d’utilisateurs avec le premier individu Uo et l’utilisateur assistant U3. Selon une alternative, les données sont hébergées dans un nuage, également appelé « cloud » dans la terminologie anglo-saxonne, c’est-à-dire sur une pluralité de serveurs de données distants.

Un serveur SERV1 est représenté, il correspond dans ce cas à un serveur d’un centre d’appel, par exemple un centre d’appel d’urgence. Lorsqu’un utilisateur ne peut pas résoudre le problème, un transfert de l’appel vers un centre d’appel de téléassistance est engagé.

L’invention permet donc d’améliorer la coordination de l’assistance apportée à une personne ayant sollicité une communauté d’utilisateurs ayant souscrit à un service d’assistance auprès de ce dernier. Un avantage est de tenir informé l’ensemble de la communauté de l’évolution de l’assistance lorsqu’un utilisateur a pris contact avec la personne en détresse. Un avantage est de favoriser la rapidité de diffusion d’information au sein de la communauté afin de coordonner par exemple des actions en parallèle. Un autre avantage est de diminuer le nombre d’échange entre les utilisateurs par un système de diffusion instantanée qui permet de mutualiser une synthèse de l’assistance apportée.

Un avantage de la présente invention est donc de permettre de traiter différents types de notifications. Ceci permet un traitement plus adapté à chaque cas d’émission d’alerte.

Un premier type de notification peut être automatiquement généré à partir d’un des terminaux, EQo ou Ï3, en utilisant les informations liées à la communication établie entre les deux terminaux. Ainsi, les notifications peuvent être déclenchées automatiquement à partir d’évènements liés à la session de communication. Par exemple, l’établissement de la communication, la rupture de la communication, l’établissement d’un mode conférence peuvent être des évènements contribuant à générer automatiquement des notifications émises par l’un des deux terminaux à l’ensemble ou le sous-ensemble des terminaux des autres utilisateurs n’ayant pas établis de communication avec l’utilisateur Uo. Ces notifications correspondent à des notifications générées à partir d’évènements liés à la communication, elles peuvent être, par exemple, appelées des « notifications de communication ».

Un second type de notification peut être automatiquement généré à partir d’un des terminaux en utilisant les informations liées à une donnée numérique générée depuis un des terminaux, préférentiellement le terminal T3 de l’utilisateur-assistant U3. En effet, ce dernier est plus à même de générer des notifications aux autres utilisateurs pour activer un scénario d’aide ou rassurer les autres utilisateurs du traitement de l’alerte.

On considère le cas de figure où l’utilisateur assistant U3 émet les notifications, un cas analogue pourrait être décrit en considérant que les notifications sont émises depuis le terminal de l’émetteur Uo. Ainsi, les notifications peuvent être déclenchées suite à l’action de l’utilisateur-assistant U3 pendant la communication. Alternativement ou conjointement, elles peuvent être générées automatiquement en fonction de la survenance de certains évènements à partir du terminal T3.

Dans ce cas de figure, c’est le statut du traitement de l’alerte en tant que telle qui est la source des notifications émises et non le statut de la communication. Ces notifications correspondent à des notifications générées à partir d’évènements liés aux données échangées, elles peuvent être par exemple appelées : « notifications de traitement de l’alerte ». Ces notifications sont émises aux autres utilisateurs de la communauté. Elles peuvent être, par exemple, générées à partir d’une icône numérique accessible depuis l’interface d’un terminal. Certaines notifications peuvent, en effet, être préenregistrées et être déclenchées successivement à l’action de l’utilisateur Us.

Par exemple, le procédé de l’invention permet la génération d’un indicateur de traitement qualifiant l’importance de l’alerte, un indicateur suggérant l’appel d’un médecin, un indicateur suggérant une intervention rapide sur le lieu de présence de l’utilisateur Uo, un indicateur de résolution ou un encore un indicateur suggérant l’établissement d’une communication entre l’utilisateur Uo et un autre utilisateur-assistant de la communauté, Ui, U2, dans le cas d’exemple précédemment décrit. D’autres notifications peuvent être réalisées.

Ainsi, on comprend que le procédé de l’invention permet de proposer une solution privilégiant dans un premier temps, l’établissement d’une communication entre le premier répondant à un SOS et son émetteur. Elle permet dans un second temps de définir la qualification du statut de l’alerte et de son suivi au sein d’une communauté d’utilisateurs. L’invention s’affranchit donc d’une solution dans laquelle des niveaux de priorité doivent être préalablement définis au sein d’une communauté et elle s’affranchit d’une solution dans laquelle un équipement tiers organise les communications entre l’émetteur du SOS et un utilisateur-assistant. En effet, ces niveaux de priorité prédéfinis ne peuvent être adaptés à un traitement particulier de l’alerte faute de pouvoir disposer d’une information liée à un statut de traitement de l’alerte, de son niveau d’importance, de sa qualification ou encore d’une action devant être réalisée rapidement au sein de la communauté.