PROCÉDÉ DE CONTRÔLE D'UN SYSTÈME D'ALARME

Abstract

 L'invention propose un procédé de contrôle d'un système d'alarme (1) comprenant au moins un capteur de présence (10) équipant un site (S), le système d'alarme (1) présentant un état désactivé et un état activé dans lequel une alerte est déclenchée si ledit capteur de présence (10) détecte une présence, ledit procédé étant caractérisé en ce qu'il comprend la mise en œuvre, par un module de traitement de données (22) du système d'alarme (1), d'étapes de :
(a) Détection d'une absence d'un utilisateur (U) dans le site (S),
(b) Estimation en fonction de données de géolocalisation de l'utilisateur (U) d'un temps de trajet retour (Δtr) de l'utilisateur (U) jusqu'au site (S),
(c) Si le système d'alarme (1) est dans ledit état désactivé, contrôle de l'état du système d'alarme (1) en fonction dudit temps de trajet retour (Δtr) estimé de l'utilisateur (U).

Description

DOMAINE TECHNIQUE GENERAL

[0001] L'invention relève du domaine de la surveillance de site.

[0002] Plus particulièrement, l'invention concerne un procédé de contrôle d'un système d'alarme.

ETAT DE L'ART

[0003] De nombreux sites (typiquement des locaux tels que des habitations, des commerces, des bureaux, etc.) sont équipés de systèmes d'alarme.
Plus précisément, l'inoccupation du site est surveillée au moyen de capteurs de présence installés sur le site tels que des détecteurs de mouvement, des capteurs thermiques, des détecteurs d'ouverture de porte/fenêtre, des caméras, etc., qui renvoient au fil de l'eau des informations à un équipement central de traitement des données issues des capteurs (qui lui peut être distant et connecté aux capteurs par un réseau).
L'alarme est soit dans un état désactivé (lorsque des utilisateurs sont présents de manière normale sur le site), soit dans un état activé (lorsque les utilisateurs sont partis et que le site est censé être inoccupé).
Si lorsque l'alarme est dans l'état activé au moins un capteur fait remonter une information indiquant une présence sur les lieux (i.e. une occupation non prévue est détectée), alors une action d'alerte est déclenchée, pouvant aller d'une forte sonnerie à l'appel d'une société de gardiennage ou de la police.

[0004] Aujourd'hui, les capteurs sont extrêmement fiables, et s'ils sont bien installés les éventuels « ratés » d'une alarme tiennent essentiellement en des erreurs humaines dans l'activation/désactivation.
En effet, les utilisateurs sont présents sur le site et le quittent avec une régularité variable, et il est courant soit que l'alarme soit activée alors qu'il y a encore des utilisateurs sur le site (résultant en une fausse alerte), soit non activée au départ du dernier occupant. La cause peut être l'oubli pur et simple ou bien le fait que l'absence étant supposée courte, l'opération ne semble pas requise aux yeux de l'utilisateur. En effet, la procédure d'activation/désactivation est souvent encore perçue comme un « effort ».
Cependant, les chiffres démontrent qu'une part importante des effractions a lieu dans l'heure suivant le début de l'absence.
Une innovation supplémentaire a consisté en la prise en compte des absences et des présences prévues des utilisateurs du site, i.e. l'activation/désactivation de l'alarme sur la base d'un système d'horloge, au lieu de laisser manuellement les utilisateurs le faire. Cela impose cependant des contraintes supplémentaires aux utilisateurs (heure d'arrivée minimale et heure de départ maximale), et laisse dans certains cas des trous qui peuvent être exploités par des voleurs bien renseignés.
Pour résoudre cette difficulté, le document EP3367184 propose de changer automatiquement l'état d'un système domotique tel qu'une alarme notamment sur la base de la détection de présence de personnes ou d'animaux. En d'autres termes, si l'alarme est dans l'état désactivé et qu'il est détecté le départ de tous les utilisateurs, elle est automatiquement passée dans l'état activée.
Si cette technique garantit d'éviter tout oubli et limite donc les risques d'effraction, elle s'avère lourde pour les utilisateurs, car l'alarme peut s'activer de manière intempestive, par exemple si le seul utilisateur présent est sorti fumer une cigarette. Il y a alors un risque permanent de fausse alerte (qui peut in fine nuire à la crédibilité de l'alarme) et la nécessité de désactiver l'alarme très régulièrement. Une possibilité est alors, au lieu d'activer automatiquement l'alarme, d'envoyer une notification à l'utilisateur lui signalant que le site est vide et lui demandant une confirmation avant d'activer l'alarme, mais cela ne fait que déplacer le problème : l'utilisateur est inondé de notifications et risque de les ignorer.
Plus récemment, le document EP3410413 propose un fonctionnement automatique utilisant la reconnaissance faciale : il n'y a plus d'activation/désactivation, l'alarme analyse le visage des utilisateurs présents de sorte à distinguer les utilisateurs connus et autorisés des autres, et déclenche l'alerte si un utilisateur non autorisé est détecté. Une telle solution s'avère cependant bien plus complexe et bien plus couteuse, et n'est pas accessible à des particuliers par exemple.
Il serait ainsi souhaitable de disposer d'une nouvelle solution de contrôle d'un système d'alarme qui soit simple, universelle, fiable, et sollicitant le moins possible les utilisateurs.

PRESENTATION DE L'INVENTION

[0005] Selon un premier aspect, l'invention concerne un procédé de contrôle d'un système d'alarme comprenant au moins un capteur de présence équipant un site, le système d'alarme présentant un état désactivé et un état activé dans lequel une alerte est déclenchée si ledit capteur de présence détecte une présence, ledit procédé étant caractérisé en ce qu'il comprend la mise en œuvre, par au moins un module de traitement de données du système d'alarme, d'étapes de :

(a) Détection d'une absence d'un utilisateur dans le site,

(b) Estimation en fonction de données de géolocalisation de l'utilisateur d'un temps de trajet retour de l'utilisateur (U) jusqu'au site,

(c) Si le système d'alarme est dans ledit état désactivé, contrôle de l'état du système d'alarme en fonction dudit temps de trajet retour estimé de l'utilisateur.

[0006] Selon des caractéristiques avantageuses et non limitatives :

• l'étape (b) comprend le calcul d'un temps de trajet retour théorique minimal de l'utilisateur, puis l'estimation dudit temps de trajet retour de l'utilisateur à partir dudit temps de trajet retour théorique minimal calculé de l'utilisateur ;
• l'étape (b) comprend en outre l'estimation d'un temps de station restant e l'utilisateur, l'estimation du temps de trajet retour de l'utilisateur comprenant le calcul d'une somme du temps de station restant estimé de l'utilisateur et du temps de trajet retour théorique minimal calculé de l'utilisateur ;
• l'étape (b) en outre la détermination en fonction desdites données de géolocalisation de l'utilisateur d'un lieu de l'utilisateur, ledit temps de station restant de l'utilisateur étant estimé en fonction dudit lieu déterminé ;
• l'étape (b) comprend, si l'utilisateur est en mouvement, la prédiction d'une destination de l'utilisateur, ledit lieu de l'utilisateur étant déterminé comme ladite destination prédite ; l'étape (b) comprenant en outre l'estimation d'un temps de trajet aller de l'utilisateur vers la destination prédite, l'estimation du temps de trajet retour de l'utilisateur comprenant le calcul d'une somme du temps de station restant estimé de l'utilisateur, du temps de trajet retour théorique minimal calculé de l'utilisateur et du temps de trajet aller estimé de l'utilisateur ;
• l'étape (c) comprend la sélection d'une action parmi un ensemble d'actions possibles de changement d'état du système d'alarme et/ou de notification de l'utilisateur ;
• ledit ensemble comprend au moins une action de changement d'état du système d'alarme vers l'état activé, et une action de notification de l'utilisateur lui proposant de changer l'état du système d'alarme vers l'état activé ;
• ledit ensemble comprend deux actions de changement d'état du système d'alarme vers l'état activé, dont l'une avec notification de l'utilisateur et l'autre sans notification de l'utilisateur, et une absence d'action ;
• lesdites données de géolocalisation sont obtenues par un terminal mobile de l'utilisateur comprenant des moyens de localisation ;
• la détection de l'absence de l'utilisateur à l'étape (a) est effectuée soit par comparaison de données de géolocalisation du terminal mobile de l'utilisateur et de données référence de géolocalisation du site, soit par détection de déconnexion d'un réseau local, soit par détection d'absence via ledit capteurs de présence ;
• l'étape (a) est mise en œuvre par le module de traitement de données du terminal, et l'étape (c) est mise en œuvre par le module de traitement de données d'un équipement de contrôle du système d'alarme ;
• l'étape (a) est mise en œuvre pour chaque utilisateur du site ;
• l'étape (c) est mise en œuvre seulement si l'étape (a) est vérifiée pour chaque utilisateur du site ;
• l'étape (c) est mise en œuvre en utilisant l'estimation du temps de trajet retour la plus faible obtenue ;
• l'étape (b) est mise en œuvre par apprentissage à partir d'une base de temps de trajet retour réels mesurés pour l'utilisateur (U).

[0007] Selon un deuxième aspect, l'invention concerne un système d'alarme pour la mise en œuvre du procédé selon le premier aspect. Ce système comprend au moins un capteur de présence équipant un site, le système d'alarme présentant un état désactivé et un état activé dans lequel une alerte est déclenchée si ledit capteur de présence détecte une présence, ledit système d'alarme étant caractérisé en ce qu'il comprend au moins un module de traitement de données configuré pour :

• Détecter une absence d'un utilisateur dans le site,
• Estimer en fonction de données de géolocalisation de l'utilisateur d'un temps de trajet retour de l'utilisateur jusqu'au site,
• Si le système d'alarme est dans ledit état désactivé, contrôler l'état du système d'alarme en fonction dudit temps de trajet retour estimé de l'utilisateur.

PRESENTATION DES FIGURES

[0008] D'autres caractéristiques, buts et avantages de l'invention ressortiront de la description qui suit, qui est purement illustrative et non limitative, et qui doit être lue en regard des dessins annexés, sur lesquels :

• La figure 1 représente une architecture pour la mise en œuvre du procédé selon l'invention,
• La figure 2 illustre schématiquement un mode de réalisation d'un procédé conforme à l'invention.

DESCRIPTION DETAILLEE

[0009] Le présent procédé de contrôle d'un système d'alarme 1 est mis en œuvre dans un environnement du type de celui représenté par la figure 1.
Le système d'alarme 1 comprend au moins deux grandes parties :

• au moins un capteur de présence 10 équipant un site S ;
• un équipement de contrôle 20, dit équipement central, généralement de type serveur ;
• éventuellement au moins un terminal mobile 30.

L'équipement 20 comprend classiquement un module de traitement de données 22 (tel qu'un processeur) et un module de stockage de données 23 (par exemple un disque dur). L'équipement 20 peut être un équipement dédié (disposé dans le site S ou distant), ou peut être intégré à un ordinateur personnel, à un boitier d'accès à Internet, etc. En outre, l'équipement 20 peut être intégré audit terminal mobile 30, i.e. le système ne comprend plus que les capteurs 10 et les terminaux mobiles 30 connectés. L'équipement 20 peut comprendre ou être connecté à des moyens d'alerte 24 tels qu'un avertisseur sonore ou une unité de communication. L'alerte pourra, en cas d'intrusion, être lancée de n'importe quelle façon connue.
On note qu'un même système d'alarme 1 peut permettre de surveiller plusieurs sites S (équipés chacun d'au moins un capteur de présence 10) partageant le même l'équipement de contrôle 20, et au sein d'un même site S il peut y avoir plusieurs capteurs 10 le cas échéant de types variés. Par exemple, on pourra avoir des détecteurs de mouvement, des radars, des capteurs thermiques, des détecteurs d'ouverture de porte/fenêtre, des caméras, des capteurs vibratoires et/ou sonores, des capteurs de proximité, des barrières périmétriques, etc. Dans la suite de la présente description on prendra l'exemple d'un seul site S et l'homme du métier saura transposer à plusieurs sites S le cas échéant.
Le site S est occupé par au moins un utilisateur U et signifie toute construction dans laquelle peut se trouver un utilisateur U. Typiquement, le site S est un logement ou un local commercial. En outre, le présent procédé est décrit pour un seul utilisateur U, on évoquera plus loin le cas d'une pluralité d'utilisateurs (famille, ensemble du personnel d'une entreprise, etc.).

[0010] Les capteurs 10 sont connectés audit équipement 20, typiquement par un réseau de communication 21 tel qu'un réseau de téléphonie mobile, internet, LoRa, etc., ou bien directement si celui-ci est local. Les capteurs 10 acquièrent des données dans le site S, et envoient un signal au serveur 20. La nature de ce signal dépend du capteur 10, par exemple pour une caméra ce sera une image, pour un capteur thermique une mesure de température, pour un détecteur de mouvement un booléen représentatif de la détection ou non d'un mouvement, etc. Les moyens de traitement 22 sont, de manière classique, aptes à traiter les informations remontées des capteurs 10 de sorte à conclure à la présence ou non d'un individu, et de fait, à une potentielle intrusion.
Le système d'alarme 1 présente ainsi un état désactivé et un état activé :

• dans l'état activé, une alerte est déclenchée (via les moyens d'alerte 24) si ledit capteur de présence 10 détecte une présence (et plus généralement si le module de traitement de données 22 détermine que les données fournies par le ou les capteurs 10 sont représentatives d'une présence dans le site S) ;
• dans l'état désactivé, une alerte n'est jamais déclenchée (que ledit capteur de présence 10 détecte ou non une présence).

On note que l'état désactivé ne signifie pas que le système 1 est complètement éteint. Généralement dans l'état désactivé les capteurs 10 continuent de remonter des informations et le module de traitement 22 continue de les traiter, mais aucune alerte n'est déclenchée. Le mode désactivé est celui généralement utilisé lorsque utilisateurs U sont normalement présents dans le site S, i.e. lorsqu'il est attendu de détecter une présence. Selon une autre disposition, dans l'état désactivé, le module de traitement 22 peut aussi être en veille et ne plus traiter les informations remontées par les capteurs.
Dans tous les cas, qu'elles soient traitées ou non, en état désactivé, les informations remontées par les capteurs ne débouchent sur aucune alerte.
Un terminal mobile 30 de l'utilisateur U peut être connecté au à l'équipement central 20 du système d'alarme 1 par le réseau de communication. Le terminal mobile 30 peut être n'importe quel équipement apte à se connecter au réseau de communication 21. Il peut s'agir par exemple d'un Smartphone, d'une tablette tactile, etc.
Le terminal mobile 30 comprend typiquement un module de traitement de données 31, des moyens de localisation (par exemple un GPS - « global positioning system », un « système » de triangulation des stations de base, une connexion WIFI, etc.), et des moyens d'interface tel qu'un écran. Le terminal mobile 30 peut être intégré à un véhicule de l'utilisateur U. De façon générale, par «terminal mobile» on entendra tout dispositif disposant de moyens de communications et dont les déplacements coïncident avec ceux de l'utilisateur U.
En fonctionnement par défaut, le passage de l'état désactivé à l'état activé ou inversement est soit commandé manuellement par un utilisateur (par exemple via une interface de l'équipement 20 disposée dans le site S, via le terminal 30, etc.), soit commandé automatiquement par le module de traitement 22 en fonction de règles telles que des horaires. Les deux principes peuvent coexister.

[0011] L'objectif de l'invention est de qualifier une situation d'absence de l'utilisateur U, et en fonction du résultat de cette qualification, déterminer une éventuelle action à effectuer pouvant être une activation de l'alarme mais pas nécessairement. Plus précisément, ladite action est préférentiellement une action de changement d'état du système d'alarme 1 et/ou de notification de l'utilisateur U.
Avantageusement, comme l'on verra, suivant le résultat de cette qualification, le système 1 peut (1) basculer l'alarme dans le mode activé sans avertir l'utilisateur, (2) basculer l'alarme dans l'état activé tout en avertissant l'utilisateur connecté, ou (3) juste alerter l'utilisateur connecté de l'oubli. Une action « vide », i.e. une absence d'action, reste (4) une action possible.
Cela permet d'activer au plus tôt l'alarme, à bon escient, en sollicitant le moins possible l'utilisateur.

[0012] Le présent procédé est mis en œuvre par le ou les modules de traitement de données 22, 31 du système 1, i.e. ceux respectivement de l'équipement 20 et/ou du terminal 30. A noter que ces derniers peuvent être confondus, comme expliqué.
En référence à la figure 2, dans une première étape (a), l'absence de l'utilisateur U du site S est détectée lorsque l'utilisateur U quitte le site S, au temps t₀.
L'absence t₀ de l'utilisateur U peut être détectée par comparaison des données de localisation fournies par le terminal mobile 30 et des données de localisation du site S. La comparaison peut être effectuée par le terminal mobile 30 ou par l'équipement 20. Alternativement, l'absence de l'utilisateur U peut se faire par signalisation de l'utilisateur U, à l'aide par exemple d'un interrupteur, par perte de signal WIFI, par déconnexion d'un réseau local (ou tout autre moyen tiers).
A noter que l'utilisation des données des capteurs de présence 10 permet de détecteur d'un coup l'absence de tous les utilisateurs U, et ce de manière très fiable.

[0013] Dans une seconde étape (b), une géolocalisation de l'utilisateur U est effectuée dans une première partie b1. Dans une deuxième partie b2, le temps de trajet retour Δtr de l'utilisateur U est estimé en fonction des données de géolocalisation de l'utilisateur U. Par temps de trajet retour, on entend le temps que l'utilisateur U devrait mettre pour rentrer au site S, i.e. être à nouveau présent.
Les données de géolocalisation sont typiquement issues des moyens de localisation du terminal mobile 30 de l'utilisateur U. L'estimation du temps de trajet retour Δtr est effectuée par analyse de la position de l'utilisateur U et des plans routiers connus, des vitesses des moyens de transports (voiture, métro, pied, vélo, etc.), de l'état du trafic, etc.

[0014] Ladite analyse peut être effectuée par l'équipement 20 après envoi des données de géolocalisation par le terminal mobile 30.
Alternativement, ladite analyse peut être effectuée par le terminal mobile 30 qui ensuite envoie ladite estimation à l'équipement 20 via le réseau de communication 21. A noter qu'un tel mode de réalisation est préféré, car à partir du seul temps de retour Δtr il est impossible de retrouver la position de l'utilisateur, et donc on garantit ainsi la vie privée de l'utilisateur. En effet une valeur donnée de Δtr peut aussi bien correspondre à « je suis en voiture à 8h de route du site S » qu'à « il est 11h du matin et je serais rentré à 19h de mon travail qui se trouve à 10 minutes du site S », et l'équipement 20 ne peut pas les distinguer.
Si l'étape (a) est mise en œuvre sur la base des données de géolocalisation fournies par le terminal mobile 30, les étapes (a) et (b) peuvent être confondues : plus précisément, une absence est détectée si ledit temps de trajet retour Δtr est non-nul (alors qu'à la précédente itération celui-ci était nul).
Par simplicité, on peut prévoir que le système 1 réalise un traitement des données d'un site S à chaque réception d'une nouvelle donnée (issue d'un terminal 30 ou d'un capteur 10). Si le système d'alarme 1 est dans l'état activé ou s'il reste au moins un utilisateur U détecté sur le site S, le procédé s'arrête à l'issue de l'étape (b) (pas d'utilité de la suite).
A chaque réception d'une nouvelle information d'un terminal mobile 30, quand c'est une information de temps de trajet retour Δtr > 0 et que le précédent temps de trajet retour Δtr était nul, un départ du site S est qualifié. Si aucun autre utilisateur U n'est présent sur le site (tous les autres temps de trajet retour Δtr sont déjà supérieurs à 0), l'absence de tous les utilisateurs U est qualifiée.
Alternativement, si l'étape (a) n'est pas mise en œuvre sur la base des données de géolocalisation fournies par le terminal mobile 30, et en particulier est mise en œuvre sur la base des données de capteur de présence 10, on peut conditionner la mise en œuvre de l'étape (b) à la détection d'absence de tous les utilisateurs U, de sorte à limiter la consommation énergétique des terminaux mobiles 30.

[0015] Dans tous les cas, le terminal mobile 30 est préférentiellement préalablement doté d'une application dédiée. Cette dernière peut fonctionner en tache de fond et se réveiller plus ou moins régulièrement, par exemple à une périodicité moyenne de 10 minutes à 1 heure, ce qui garantit un excellent compromis entre consommation énergétique et qualité. A noter que le fait ne pas avoir une périodicité fixe est préféré, et le déclenchement de la tache de fond résulte avantageusement de la survenue de nouveaux événements (géolocalisation faites automatiquement par l'OS, changement de wifi, etc.) ou de sollicitations externes quand le terminal mobile 30 devient silencieux trop longtemps.

[0016] A chaque réveil, l'application commence par récupérer la position géographique (première partie b1). Cette information est avantageusement prétraitée par un algorithme pour identifier un éventuel lieu d'habitude de l'utilisateur. Ce lieu peut être caractérisé par un identifiant (anonymisé, i.e. un code sans signification). Cette nouvelle donnée peut être complétée de l'heure et du jour de la semaine de l'instant ainsi que de son temps de retour Δtr quand il a été estimé (deuxième partie b2).
De manière particulièrement préférée, ladite estimation en fonction de données de géolocalisation de l'utilisateur U d'un temps de trajet retour Δtr de l'utilisateur U comprend tout d'abord le calcul d'un temps de trajet retour théorique minimal Δtr_min, correspondant au temps de retour dans l'hypothèse d'un départ immédiat, puis l'estimation dudit temps de trajet retour « pratique » Δtr à partir dudit temps de trajet retour théorique minimal Δtr_min, le temps de trajet Δtr étant supérieur ou égal audit temps de trajet retour théorique minimal Δtr_min.
En effet, dans la majeure partie des cas, l'utilisateur U va encore passer du temps là où il est, voire même n'est pas encore arrivé à sa destination et est donc loin d'amorcer un trajet retour (exemple de l'utilisateur parti au travail et donc qui sera absent toute la journée de la maison même s'il est à 10 minutes de trajet). Ledit temps de trajet retour théorique minimal Δtr_min correspond au temps avant l'issue duquel on est sûr que l'utilisateur U ne pourra pas être rentré.
L'estimation dudit temps de trajet retour Δtr à partir dudit temps de trajet retour théorique minimal Δtr_min peut être mise en œuvre grâce à un algorithme qui repose sur un apprentissage statistique (potentiellement un réseau de neurones, mais également tout autre technique d'apprentissage automatisé telle que le machine learning basé sur les Quantile Régression Forests). A noter que dans chaque cas, le temps de retour réel peut être mesuré et comparé avec le temps de retour prédit Δtr de sorte à améliorer l'apprentissage du modèle.
Cet apprentissage statistique permet aussi de définir des lieux d'habitude.
Le temps de trajet retour Δtr estimé est typiquement composé d'un temps expérimenté de station sur le lieu visité, quand l'utilisateur y est à cet instant de la semaine, augmenté du temps de parcours du lieu au site (i.e. le temps de retour minimal théorique Δtr_min). En d'autres termes, l'estimation du temps de trajet retour Δtr comprend préférentiellement l'estimation d'un temps de station restant Δts de l'utilisateur U, et le temps de trajet retour Δtr estimé est obtenu comme la somme du temps de retour minimal théorique Δtr_min et du temps de station restant Δts, i.e. Δtr = Δtr_min + Δts
Concrètement, le temps de trajet retour Δtr est avantageusement estimé comme :

1. Si l'utilisateur U est en mouvement, le temps que mettrait ce dernier pour revenir au site S s'il amorçait son retour à l'instant (i.e. Δts = 0 et Δtr= Δtr_min). En effet on ne sait pas encore quelle est sa destination.

2. Si l'utilisateur est à un endroit qui ne correspond pas à un lieu d'habitude, le temps que mettrait l'utilisateur pour revenir au site s'il amorçait son retour à l'instant (à nouveau Δts = 0 et Δtr= Δtr_min).

3. Si l'utilisateur est à un lieu d'habitude (i.e. un lieu dont l'identifiant est connu), on peut déterminer à quelle heure l'utilisateur quitte habituellement ce lieu ou combien de temps il y reste, et ainsi estimer Δts

4. Si l'utilisateur est sur le site S, Δtr= Δts = Δtr_min = 0.

[0017] Pour cela, le procédé peut intégrer le calcul de la dérivée de la position de l'utilisateur U ou la dérivée de l'estimation du temps de trajet retour Δtr, afin d'établir une tendance de caractère statique ou en mouvement de l'utilisateur U.
Dès qu'un utilisateur arrive sur un lieu, le système est en mesure d'identifier une absence « significative », i.e. longue et interprétable. Ainsi, on comprend qu'obtenir l'information de situation de l'utilisateur sur un lieu demande à ce que ce dernier y arrive physiquement, et y reste sensiblement statique (i.e. il peut bouger à l'intérieur du lieu, sans en sortir). Donc cette information n'est connue qu'une fois que l'utilisateur est arrivé sur le lieu. Cela demande soit d'attendre l'écoulement de la durée du trajet du site S vers le lieu, ce qui nuit à la réactivité du système, soit de prendre des décisions à l'aveugle (cas 1 supposant que Δtr= Δtr_min).
Ainsi, de manière particulièrement préférée, l'étape (b) comprend lorsque l'utilisateur U est en mouvement la prédiction d'une destination de l'utilisateur U en fonction des données de géolocalisation, considérée comme lieu de l'utilisateur U. Les données de géolocalisation sont ainsi utilisées pour construire et exploiter un arbre de chemin pour prédire le lieu de destination (notamment chaines de Markov).
Ainsi, quand un utilisateur quitte le site S, il est possible d'obtenir, dans un délai court, un prédictif du lieu de destination. Et de valider rapidement une absence significative par le même biais. Si un lieu de destination est prédit, l'estimation du temps de trajet retour Δtr peut comprendre le calcul d'un temps d'aller Δta (qui est en pratique un temps d'aller minimal théorique), qui pourra être ajouté à ladite somme du temps de retour minimal théorique Δtr_min et du temps de station restant Δts, i.e. Δtr = Δtr_min + Δts + Δta.
En résumé, dans un tel mode de réalisation soit l'utilisateur est sensiblement statique (un lieu de l'utilisateur est directement déterminable en fonction de la position actuelle) et alors Δtr = Δtr_min + Δts, soit l'utilisateur est en mouvement (aucun lieu de l'utilisateur n'est directement déterminable en fonction de la position actuelle, mais on peut prédire en tant que lieu à considérer une destination de l'utilisateur) et Δtr = Δtr_min + Δts + Δta.
On peut dans tous les cas prévoir, si l'utilisateur est déterminé dans le cas 1 (en mouvement), d'attendre de voir s'il s'éloigne, se rapproche ou s'il s'arrête pour conclure. Ainsi, l'étape (b) peut par exemple présenter une certaine durée (par exemple 10 minutes), avant de renvoyer une valeur estimée du temps de trajet retour Δtr, de sorte à améliorer la fiabilité du résultat. Plus précisément, plusieurs valeurs du temps de trajet retour Δtr peuvent être successivement calculées pendant cette durée, de sorte à voir s'il y a convergence, et une valeur estimée finale étant émise à la fin de la durée, par exemple la moyenne desdites valeurs du temps de trajet retour Δtr.
Afin de limiter les consignes dites trépidantes, liées à des géolocalisations proches (piétinement ou trajet aller-retour de quelques dizaines de mètres par exemple) dites géostatiques, un filtrage peut être appliqué à l'étape (b) (durant ladite durée). Ce filtrage est typiquement effectué par le module de traitement 31 du terminal 30.
Par exemple, le filtrage peut consister à créer un cercle d'un certain diamètre autour d'une position de géolocalisation et, tant qu'aucune géolocalisation n'identifie l'utilisateur U en dehors de ce cercle, aucun nouveau temps de trajet retour Δtr n'est estimé. Dès qu'une géolocalisation identifie l'utilisateur U en dehors de ce cercle, un nouveau cercle est créé autour de ladite géolocalisation ; un tel filtrage est mis en œuvre durant la première partie b1 de l'étape (b). Alternativement, le filtrage peut consister à créer un intervalle de temps de trajet de retour autour d'une estimation de temps de trajet retour Δtr et à vérifier si lesdites estimations Δtr successives se trouvent à l'intérieur dudit intervalle. Un tel filtrage est mis en œuvre durant la deuxième partie b2 de l'étape (b).
De tels filtrages contribuent à éviter des temps de trajet retour aberrants (artefacts).

[0018] Dans une troisième étape (c), si le système d'alarme 1 est dans ledit état désactivé, l'état du système d'alarme 1 est contrôlé en fonction notamment dudit temps de trajet retour Δtr estimé de l'utilisateur U. On note que tout le procédé (i.e. aussi les étapes (a) et (b)) peut être conditionné au fait que le système d'alarme soit dans l'état désactivé. En effet, le présent procédé vise l'activation (ou non) de système d'alarme 1, et donc n'a pas lieu d'être mis en œuvre lorsqu'il est déjà activé, pour limiter encore la consommation énergétique du terminal 30.
Cette étape est préférentiellement mise en œuvre par le module de traitement de données 22 de l'équipement 20, après réception depuis le terminal 30 du temps de trajet retour Δtr estimé.

[0019] L'étape (c) comprend préférentiellement la sélection d'une action parmi un ensemble d'actions possibles de changement d'état du système d'alarme 1 et/ou de notification de l'utilisateur U.
En particulier, comme expliqué, ledit ensemble comprend au moins une action de changement d'état du système d'alarme 1 vers l'état activé, et une action de notification de l'utilisateur U lui proposant de changer l'état du système d'alarme 1 vers l'état activé. Avantageusement, ledit ensemble comprend même deux actions de changement d'état du système d'alarme 1 vers l'état activé, dont l'une avec notification de l'utilisateur U et l'autre sans notification de l'utilisateur U, et une absence d'action (système 1 laissé dans l'état désactivé, à charge pour l'utilisateur de l'activer manuellement s'il le souhaite), pour un total de quatre actions.
On peut hiérarchiser les actions selon un niveau « d'autonomie » du système 1 associé. Par exemple, du plus autonome au moins autonome, on trouve :

(1) changement d'état du système d'alarme 1 vers l'état activé sans notification de l'utilisateur U ;

(2) changement d'état du système d'alarme 1 vers l'état activé avec notification de l'utilisateur U ;

(3) notification de l'utilisateur U lui proposant de changer l'état du système d'alarme 1 vers l'état activé ;

(4) absence d'action.

[0020] De manière générale, plus l'action est associée à un niveau d'autonomie élevée, plus il faut que le temps de trajet retour Δtr estimé soit élevé et/ou qu'un niveau de fiabilité du temps de trajet retour Δtr soit élevé.
En effet, plus le temps de trajet retour Δtr estimé est élevé moins il y a de risques d'erreur à activer l'alarme, et donc moins on a besoin de solliciter l'utilisateur. Le présent procédé apporte ainsi un excellent équilibre entre sécurité et sollicitations de l'utilisateur. L'idée de considérer un niveau de fiabilité en plus du temps de trajet retour Δtr permet d'incorporer un risque que le temps de trajet retour réel s'avère bien moindre que la valeur Δtr estimée, et donc de limiter le niveau d'autonomie dans ces cas.
Par « niveau de fiabilité », on entend une caractérisation de la qualité de l'estimation, principalement liée au caractère habituel ou non de l'absence. Un niveau de fiabilité élevé signifie que l'on peut avoir confiance dans l'estimation, et ainsi aller également dans le sens d'un niveau d'autonomie élevé. En particulier, le temps de trajet retour Δtr estimé pour un lieu récurrent (pour lequel les habitudes de l'utilisateur U sont particulièrement bien connues) est considéré d'un niveau de fiabilité élevé, par opposition au temps de trajet retour Δtr estimé pour un lieu inconnu. A noter qu'il y a souvent déjà une corrélation entre temps de trajet retour Δtr estimé élevé et niveau de fiabilité élevé.
A titre d'exemple, on comprend que si le dernier utilisateur part de chez lui le matin et que le temps de trajet retour estimé est de 8h car il va au travail, alors l'alarme peut être activée sans la moindre hésitation, nul besoin de notifier l'utilisateur. En effet, ce temps de trajet retour Δtr est élevé et d'une fiabilité élevée, car il n'y a que très peu de risque que l'utilisateur revienne chez lui en pleine journée. L'action (1) changement d'état du système d'alarme 1 vers l'état activé sans notification de l'utilisateur U est donc préférée. Inversement, si l'utilisateur part durant un week-end de manière inopinée à proximité immédiate (temps de trajet retour Δtr estimé de 15 minutes), il y a des chances qu'il soit allé faire quelque chose de très bref comme aller poster une lettre et qu'il revienne très vite, un cambriolage est peu probable durant ce laps de temps et on peut par exemple se contenter dans le doute de l'action (3) notification de l'utilisateur U lui proposant de changer l'état du système d'alarme 1 vers l'état activé, voire de ne rien faire (4).

Comme expliqué, le niveau de fiabilité du temps de trajet retour Δtr estimé peut être calculé en particulier selon le caractère habituel ou non de l'absence, et par exemple être exprimé comme un taux. A nouveau de l'apprentissage peut être utilisé pour ce calcul.
Pour sélectionner l'action, on peut par exemple définir des seuils (par exemple : Δtr<10 min → action (4), Δtr<1h → action (3), Δtr<2h → action (2), Δtr≥2h → action (4), éventuellement pondérés par le niveau de fiabilité), ou bien à nouveau faire de l'apprentissage, i.e. voir comment l'utilisateur U réagit.
Dans un tel mode de réalisation par apprentissage, au commencement, le système 1 ne dispose pas de données d'expérience. Il ne lui est donc pas possible de s'appuyer sur autre chose que les faits. L'action qui sera alors privilégiée sera généralement une action d'un niveau d'autonomie moyen, en particulier l'action (3) de notification de l'utilisateur U lui proposant de changer l'état du système d'alarme 1 vers l'état activé. Ainsi, selon si l'utilisateur accepte ou non d'activer l'alarme
Le système 1 est ainsi avantageusement doté d'un module d'apprentissage statistique automatisé qui est mis à jour continuellement, permettant d'améliorer jour après jour la précision des prévisions d'occupation du site S et des lieux d'expérience utilisateur sur base des horaires observés de présence des utilisateurs U sur le site ainsi que leurs évolutions au fil du temps. Selon ce mode de réalisation, le serveur 20 comprend un procédé d'apprentissage local, par accumulation des données issues de l'utilisateur U dans une base d'apprentissage stockée sur le module de traitement 23.
L'utilisateur connecté peut aussi paramétrer le système de sélection à sa guise.

[0021] A noter que dans le cas où il ne serait plus possible d'obtenir de données de géolocalisation d'un utilisateur U (par exemple si l'utilisateur U se trouve dans un tunnel, ou si son terminal mobile 30 est coupé), il est possible de définir par sécurité un temps de trajet retour Δtr par défaut, ou une action de contrôle d'état par défaut (par exemple l'action (3) de notification de l'utilisateur U lui proposant de changer l'état du système d'alarme 1 vers l'état activé). Alternativement, en cas de perte de données de géolocalisation, le procédé pourra appuyer son choix sur l'expérience d'usage du site S et notamment basculer automatiquement sur un mode de contrôle programmable basé sur les heures de présence et d'absence et/ou la présence effective de l'utilisateur U, ou un contrôle manuel de l'utilisateur.

[0022] En outre le procédé s'applique préférentiellement à plusieurs utilisateurs U. Dans ce cas, l'étape (a) est mise en œuvre pour chaque utilisateur U du site S, et l'étape (c) est mise en œuvre seulement si l'étape (a) est vérifiée pour chaque utilisateur U du site S : l'état du système d'alarme n'est contrôlé en fonction dudit temps de trajet retour Δtr estimé de l'utilisateur U que si et seulement si aucun utilisateur U n'est présent dans le site S. L'étape (b) est mise en œuvre pour chaque utilisateur U, c'est-à-dire que la géolocalisation et l'estimation du temps de trajet retour est effectuée pour chaque utilisateur. L'étape (c) est effectuée pour l'estimation de temps de trajet retour Δtr la plus faible obtenue parmi toutes les estimations Δtr.
Le procédé s'applique aussi à une pluralité de site S. Dans ce cas, chaque site S est traité indépendamment.

Revendications

1. Procédé de contrôle d'un système d'alarme (1) comprenant au moins un capteur de présence (10) équipant un site (S), le système d'alarme (1) présentant un état désactivé et un état activé dans lequel une alerte est déclenchée si ledit capteur de présence (10) détecte une présence, ledit procédé étant caractérisé en ce qu'il comprend la mise en œuvre, par au moins un module de traitement de données (22, 31) du système d'alarme (1), d'étapes de :

(a) Détection d'une absence d'un utilisateur (U) dans le site (S),

(b) Estimation en fonction de données de géolocalisation de l'utilisateur (U) d'un temps de trajet retour (Δtr) de l'utilisateur (U) jusqu'au site (S),

(c) Si le système d'alarme (1) est dans ledit état désactivé, contrôle de l'état du système d'alarme (1) en fonction dudit temps de trajet retour (Δtr) estimé de l'utilisateur (U), et sélection d'une action parmi un ensemble d'actions possibles de changement d'état du système d'alarme (1) et/ou de notification de l'utilisateur (U), les actions étant hiérarchisées selon un niveau d'autonomie du système 1 associé.

2. Procédé selon la revendication 1, dans lequel l'étape (b) comprend le calcul d'un temps de trajet retour théorique minimal (Δtr_min) de l'utilisateur (U), puis l'estimation dudit temps de trajet retour (Δtr) de l'utilisateur (U) à partir dudit temps de trajet retour théorique minimal (Δtr_min) calculé de l'utilisateur (U).

3. Procédé selon la revendication 2, dans lequel l'étape (b) comprend en outre l'estimation d'un temps de station restant (Δts) de l'utilisateur (U), l'estimation du temps de trajet retour (Δtr) de l'utilisateur (U) comprenant le calcul d'une somme du temps de station restant (Δts) estimé de l'utilisateur (U) et du temps de trajet retour théorique minimal (Δtr_min) calculé de l'utilisateur (U).

4. Procédé selon la revendication 3, dans lequel l'étape (b) en outre la détermination en fonction desdites données de géolocalisation de l'utilisateur (U) d'un lieu de l'utilisateur (U), ledit temps de station restant (Δts) de l'utilisateur (U) étant estimé en fonction dudit lieu déterminé.

5. Procédé selon la revendication 4, dans lequel l'étape (b) comprend, si l'utilisateur est en mouvement, la prédiction d'une destination de l'utilisateur (U), ledit lieu de l'utilisateur étant déterminé comme ladite destination prédite ; l'étape (b) comprenant en outre l'estimation d'un temps de trajet aller (Δta) de l'utilisateur (U) vers la destination prédite, l'estimation du temps de trajet retour (Δtr) de l'utilisateur (U) comprenant le calcul d'une somme du temps de station restant (Δts) estimé de l'utilisateur (U), du temps de trajet retour théorique minimal (Δtr_min) calculé de l'utilisateur (U) et du temps de trajet aller (Δta) estimé de l'utilisateur (U).

6. Procédé selon l'une quelconque des revendications précédentes, dans lequel ledit ensemble comprend au moins une action de changement d'état du système d'alarme (1) vers l'état activé, et une action de notification de l'utilisateur (U) lui proposant de changer l'état du système d'alarme (1) vers l'état activé.

7. Procédé selon la revendication 6, ledit ensemble comprend deux actions de changement d'état du système d'alarme (1) vers l'état activé, dont l'une avec notification de l'utilisateur (U) et l'autre sans notification de l'utilisateur (U), et une absence d'action.

8. Procédé selon l'une quelconque des revendications précédentes, dans lequel lesdites données de géolocalisation sont obtenues par un terminal mobile (30) de l'utilisateur (U) comprenant des moyens de localisation.

9. Procédé selon la revendication 8, dans lequel la détection de l'absence de l'utilisateur (U) à l'étape (a) est effectuée soit par comparaison de données de géolocalisation du terminal mobile (30) de l'utilisateur (U) et de données référence de géolocalisation du site (S), soit par détection de déconnexion d'un réseau local, soit par détection d'absence via ledit capteurs de présence (10).

10. Procédé selon l'une des revendications 8 et 9, dans lequel l'étape (a) est mise en œuvre par le module de traitement de données (31) du terminal (30), et l'étape (c) est mise en œuvre par le module de traitement de données (22) d'un équipement de contrôle (20) du système d'alarme (1).

11. Procédé selon l'une quelconque des revendications précédentes, dans lequel :

- l'étape (a) est mise en œuvre pour chaque utilisateur (U) du site (S),

- l'étape (c) est mise en œuvre seulement si l'étape (a) est vérifiée pour chaque utilisateur (U) du site (S).

12. Procédé selon la revendication 11, dans lequel l'étape (c) est mise en œuvre en utilisant l'estimation du temps de trajet retour (Δtr) la plus faible obtenue.

13. Procédé selon l'une quelconque des revendications précédentes, dans lequel l'étape (b) est mise en œuvre par apprentissage à partir d'une base de temps de trajet retour réels mesurés pour l'utilisateur (U).

14. Système d'alarme (1) comprenant au moins un capteur de présence (10) équipant un site (S), le système d'alarme (1) présentant un état désactivé et un état activé dans lequel une alerte est déclenchée si ledit capteur de présence (10) détecte une présence, ledit système d'alarme (1) étant caractérisé en ce qu'il comprend au moins un module de traitement de données (22, 31) configuré pour :

- Détecter une absence d'un utilisateur (U) dans le site (S),

- Estimer en fonction de données de géolocalisation de l'utilisateur (U) d'un temps de trajet retour (Δtr) de l'utilisateur (U) jusqu'au site (S),

- Si le système d'alarme (1) est dans ledit état désactivé, contrôler l'état du système d'alarme (1) en fonction dudit temps de trajet retour (Δtr) estimé de l'utilisateur (U).

Dessins