FR2822629A1

FR2822629A1 - Systeme de supervision de donnees de localisation de dispositifs geolocalisables

Info

Publication number: FR2822629A1
Application number: FR0103872A
Authority: FR
Inventors: Wojciech Makowski
Original assignee: ALTERNIS
Current assignee: ALTERNIS
Priority date: 2001-03-22
Filing date: 2001-03-22
Publication date: 2002-09-27
Anticipated expiration: 2021-03-22
Also published as: FR2822629B1; WO2002078378A1

Abstract

Une mémoire de localisation (18) contient des enregistrements comportant chacun des données de localisation d'un dispositif géolocalisable respectif délivrées par une source de données de localisation (3), accompagnées d'une information d'horodatage et d'une indication de qualité. Une qualité de positionnement d'un dispositif concerné par une requête de données de localisation et pour lequel la mémoire de localisation contient un enregistrement est estimée sur la base de paramètres incluant l'heure courante, l'information d'horodatage et l'indication de qualité comprises dans l'enregistrement. La qualité de positionnement estimée d'un dispositif est comparée à un objectif de qualité de positionnement défini pour la requête, afin de répondre à la requête à partir de l'enregistrement relatif au dispositif si la qualité estimée est suffisante par rapport à l'objectif et en interrogeant une source de données de localisation (3) sinon.

Description

SYSTEME DE SUPERVISION DE DONNEES DE LOCALISATION DE
DISPOSITIFS GEOLOCALISABLES
La présente invention se rapporte aux techniques servant à superviser la fourniture de données de localisation d'un ensemble de dispositifs géolocalisables en vue de l'exploitation de telles données par des applications utilisatrices.

On entend ici par dispositif géolocalisable , un dispositif permettant la détermination de sa position géographique et/ou la description de ses mouvements. Les moyens permettant de déterminer ces positions et/ou mouvements peuvent appartenir au dispositif lui-même (par exemple un récepteur GPS). Ils peuvent aussi être à distance au dispositif, en fonctionnant sur la base de signaux émis par celui-ci.

Un exemple typique de dispositif géolocalisable est un radiotéléphone cellulaire. L'infrastructure du réseau cellulaire permet de localiser le radiotéléphone sur la base de la cellule où il se trouve. La localisation d'un tel dispositif résulte de la position de la station de base avec laquelle il est en train de communiquer, ou de celle qui capte une réponse à une commande de recherche de terminal ( paging ) lorsque le dispositif n'est pas en train de communiquer. L'infrastructure du réseau cellulaire peut aussi employer des méthodes connues de localisation ayant une résolution spatiale plus fine que celle des cellules. Dans certains cas, elle peut en outre estimer les vitesses de déplacement des radiotéléphones cellulaires.

Divers autres types de dispositifs géolocalisables peuvent être concernés par l'invention, par exemple des assistants numériques personnels (PDA) ou des dispositifs de pistage ( tracking device ), etc. Un dispositif de pistage consiste par exemple en un terminal de radiocommunication cellulaire dégradé pour permettre sa localisation comme indiqué ci-dessus, mais non l'établissement de communications.

En raison notamment du succès des systèmes de radiocommunication numérique, il se développe un certain nombre de services utilisant des données de localisation de dispositifs géolocalisables. Si on extrapole ce développement, la quantité de données échangées entre les applications utilisatrices et les sources distantes de données de localisation est

virtuellement énorme, ce qui risque de ralentir excessivement ou même de bloquer la fourniture des données requises.

De plus, l'obtention des données par un serveur de localisation requiert des opérations qui représentent généralement un coût. Par exemple, dans le cas d'un opérateur cellulaire, la localisation d'un terminal nécessite typiquement une charge de signalisation, mal venue si le réseau est déjà assez chargé. Il est donc judicieux de se passer d'interroger le serveur de localisation lorsque cela n'est pas indispensable.

Une but de la présente invention est de proposer une technique permettant d'optimiser le traitement des requêtes de données de localisation ainsi que les communications entre les applications utilisatrices et les sources de données de localisation, afin de favoriser le développement de services variés utilisant de telles données.

L'invention propose ainsi un système de supervision de données de localisation de dispositifs géolocalisables comprenant des moyens de traitement de requêtes de données de localisation. Selon l'invention, ces moyens de traitement incluent : - une mémoire de localisation pour contenir des enregistrements comportant chacun des données de localisation d'un dispositif géolocalisable respectif délivrées par une source de données de localisation, accompagnées d'une information d'horodatage et d'une indication de qualité ; - des moyens de calcul pour estimer une qualité de positionnement d'un dispositif géolocalisable concerné par une requête de données de localisation et pour lequel la mémoire de localisation contient un enregistrement, sur la base de paramètres incluant l'heure courante, l'information d'horodatage et l'indication de qualité comprises dans ledit enregistrement ; - des moyens de comparaison entre la qualité de positionnement d'un dispositif géolocalisable concerné par une requête, estimée par les moyens de calcul, et un objectif de qualité de positionnement défini pour ladite requête, pour répondre à la requête à partir de l'enregistrement

relatif au dispositif si la qualité estimée est suffisante par rapport à l'objectif et en interrogeant une source de données de localisation sinon.

Ce système joue un rôle d'intermédiaire entre une ou plusieurs applications utilisatrices de données de localisation et une ou plusieurs sources ou serveurs de localisation capables de fournir ces données.

Le système peut appartenir, en totalité ou en partie, au même système qu'une source de données de localisation. Les sources peuvent également être externes. Dans ce dernier cas, le système peut être relié à plusieurs serveurs de localisation correspondant par exemple à des opérateurs cellulaires différents, de sorte qu'il se présente, pour les applications utilisatrices, comme un guichet unique où peuvent être obtenues les données de localisation requises.

Le système peut également appartenir, en totalité ou en partie, au même système qu'une ou plusieurs applications utilisatrices. Il sert alors simplement à optimiser les interrogations émises vers le ou les serveurs de localisation.

Le système délivre lui-même des données de localisation lorsqu'il estime être capable de le faire par extrapolation à partir de données précédemment fournies par une source de données de localisation. Le caractère suffisamment précis de cette extrapolation est évalué par comparaison de la qualité de positionnement estimée avec un objectif défini pour la requête. Cet objectif peut être un paramètre spécifié dans la requête, ou encore un paramètre par défaut, dépendant ou non de l'application à l'origine de la requête. Pour certaines requêtes, il est possible de définir un objectif maximal de qualité (de telles requêtes donneront toujours lieu à une interrogation d'une source de données de localisation).

Ces dispositions permettent d'alléger la charge des serveurs de localisation, ainsi que le trafic de communication avec ces serveurs s'ils sont distants du système. L'avantage est particulièrement important lorsque plusieurs applications utilisatrices sont susceptibles de s'adresser au système pour être informées de la localisation d'un même dispositif. Chaque application peut alors tirer parti d'interrogations des serveurs de localisation effectuées pour traiter les requêtes issues d'autres applications.

Un enregistrement de la mémoire de localisation peut en outre comporter, avec les données de localisation d'un dispositif géolocalisable, une indication d'une vitesse de déplacement de ce dispositif, notamment une estimation de la valeur absolue et/ou de la direction de cette vitesse de déplacement. Les paramètres pris en compte par les moyens de calcul pour estimer la qualité de positionnement d'un dispositif peuvent inclure une telle indication de vitesse, ou encore d'autres paramètres.

Il est à noter que certaines applications utilisatrices peuvent ne pas avoir besoin de données de localisation explicites de dispositifs géolocalisables, mais seulement d'être informées de certains événements (par exemple le mouvement d'un dispositif hors d'une zone déterminée, le rapprochement de deux dispositifs géolocalisables à une distance inférieure à un certain seuil, etc. ).

Pour cela, un système de supervision selon l'invention comprend avantageusement une interface de communication avec au moins une application utilisatrice de données de localisation, et des moyens de détection d'événements par analyse de données de localisation d'au moins un dispositif géolocalisable fournies par les moyens de traitement de requêtes, pour signaler les événements détectés à au moins une application utilisatrice par l'intermédiaire de ladite interface de communication.

Le système met ainsi en oeuvre des composants logiciels qui opèrent sur la base des données de localisation fournies par les moyens de traitement des requêtes. Selon les besoins, les moyens de détection peuvent générer eux-mêmes certaines des requêtes de données de localisation adressées aux moyens de traitement. Ils peuvent aussi tirer parti des réponses fournies par les moyens de traitement à d'autres requêtes, formulées par d'autres composants ou encore directement par des applications externes.

Certains des composants logiciels peuvent être prédéfinis, c'est-à-dire comporter une portion de code prédéterminée et des paramètres avantageusement modifiables, à travers l'interface de communication, par les applications utilisatrices pour lesquelles ils sont exécutés. Ceci permet par exemple de spécifier une zone géographique d'où un dispositif doit sortir (ou dans laquelle il doit entrer) pour qu'une alarme soit déclenchée vers une

application.

Il peut aussi y avoir des composants logiciels dynamiques. Un tel composant dynamique a au moins une portion de code téléchargée par l'application utilisatrice pour laquelle il est exécuté, ce qui offre une grande souplesse aux applications pour la prise en compte de situations variées fondées sur des données de localisation.

D'autres particularités et avantages de la présente invention apparaîtront dans la description ci-après d'exemples de réalisation non limitatifs, en référence aux dessins annexés, dans lesquels : - la figure 1 est un schéma synoptique d'un système de supervision de données de localisation selon l'invention ; - les figures 2 à 4 sont des schémas illustrant des exemples de transformations spatiales prises en compte dans le système de la figure
1 ; et - la figure 5 est un organigramme d'un exemple de traitement de requête mis en oeuvre dans le système de la figure 1.

Le système de supervision 1 représentée sur la figure 1, ci-après appelé optimiseur de distribution de données de localisation ou LDDO ( Location Data Distribution Optimize ), comporte des modules d'interface 12,13, 15 qui lui permettent de communiquer avec trois types d'entité, à savoir : - des applications 2 mettant en oeuvre des services utilisant directement ou indirectement des données de localisation de dispositifs géolocalisables (module 12) ; - des serveurs de localisation 3 capables de délivrer des données de localisation des dispositifs concernés (module 13). Un serveur de localisation 3 est par exemple géré par un opérateur de radiocommunication cellulaire. Plusieurs serveurs de localisation 3 sont accessibles lorsque le système coopère avec plusieurs opérateurs cellulaires ou lorsqu'un opérateur possède plusieurs serveurs de localisation ; - un ou plusieurs serveurs externes 5 auprès desquels le système 1 peut obtenir des informations éventuellement pertinentes (module 15). Un

exemple d'un tel serveur externe 5 est un serveur d'information sur le trafic routier.

Pour dialoguer avec les applications 2 et les serveurs 3, les modules d'interface 12 et 13 supportent par exemple l'interface de programmation

d'application (API) dite Mobile Location Query , spécifiée dans une norme LIF.

L'interface 12 reçoit ainsi des requêtes standard de données de localisation issues des applications utilisatrices 2, identifiant chacune un ou plusieurs dispositifs dont les données de localisation sont demandées. Ces requêtes sont traitées par un module 16 de gestion des données de localisation en relation avec des enregistrements présents dans une mémoire de localisation 18. L'interface 13 transmet de même des requêtes standard de données de localisation, générées par le module 16, vers le ou les serveurs de localisation pertinents pour le ou les dispositifs concernés. Les réponses fournies par le module 16 à l'aide des serveurs de localisation 3 sont transmises vers l'application utilisatrice 2 par l'intermédiaire de l'interface 12.

Le système 1 comporte en outre un module 17 de gestion de composants logiciels programmables et/ou configurables par les applications 2, dont le rôle est de détecter des événements particuliers sur la base des données de localisation obtenues par le module 16 et de les signaler aux applications en question. Pour les échanges entre les applications 2 et le module 17, le module d'interface 12 supporte par exemple le protocole HTTP ( HyperText Transfer Protocol ) véhiculant de façon connue en soi des pages XML ( eXtended Markup Language ).

L'API Mobile Location Query est également utilisable entre les modules 16 et 17, ce qui permet au module de gestion de composants 17 de formuler des requêtes standard (comme une application externe 2) lorsque cela est nécessaire à la détection des événements requis et de récupérer les réponses produites par le module de gestion des données de localisation 16.

Même s'ils supportent la même API, les modules d'interface 12 et 13 sont avantageusement reliés à deux réseaux locaux distincts, par exemple de type TCP/IP ( Transmission Control Protocol/Internet Protocol ). Ceci permet au système 1 de séparer physiquement les applications utilisatrices 2

des serveurs de localisation 3. A titre d'exemple, un autre réseau local de type TCP/IP peut servir pour les liaisons du module de gestion de composants 17 avec le ou les serveurs externes 5 par l'intermédiaire du module d'interface 15.

A titre d'illustration, le LDDO 1 peut être réalisé à partir de deux platesformes de type RS 6000 commercialisées par la société IBM, l'une incluant le module de gestion des données de localisation 16 et la mémoire associée 18, l'interface 13 et l'API Mobile Location Query de l'interface 12, et l'autre incluant le module de gestion de composants 17, l'interface 15, la partie XML/HTTP de l'interface 12 ainsi qu'un module d'administration du système (non représenté sur la figure 1). Ces deux plates-formes peuvent communiquer entre elles par l'intermédiaire du même réseau local que celui fournissant les liaisons du module 17 avec le ou les serveurs externes 5. Les deux platesformes sont pourvues de programmes, par exemple développés en langage C/C++, pour l'exécution de procédures telles que celles décrites plus loin.

Un enregistrement de la mémoire de localisation 18 relatif à un dispositif géolocalisable donné peut comporter les éléments suivants, codés sous une forme appropriée : - un identifiant du dispositif géolocalisable, par exemple un numéro d'appel ou une identité d'abonné ou d'équipement dans le cas où le dispositif est un terminal de radiocommunication cellulaire ; - les données de localisation les plus récentes qui ont été fournies par un serveur de localisation 3 pour le dispositif, qui peuvent notamment être sous forme d'un couple de coordonnées cartésiennes x, y ou de longitude/latitude ; - une indication, ci-après notée OQoP ( Original Quality of Positioning ) représentant une qualité originelle de positionnement du dispositif, c'est- à-dire la précision des données de localisation contenues dans l'enregistrement. Cette indication est par exemple quantifiée au moyen d'une distance représentant une marge d'erreur sur la localisation ; - une information d'horodatage des données de localisation contenues dans l'enregistrement, représentant l'instant T (date et heure) où ces données ont été obtenues ;

- éventuellement une indication de vitesse v, qui peut être scalaire (valeur absolue) ou vectorielle (valeur absolue et direction). Cette indication de vitesse peut être fournie avec les données de localisation par le serveur de localisation 3 si celui-ci effectue des mesures de vitesse. Elle peut aussi être estimée par le module 16 en observant l'évolution des jeux de données de localisation horodatés successivement fournis par le serveur de localisation 3.

A chaque instant t = T+At, le module 16 est capable d'estimer une qualité de positionnement (QoP) d'un dispositif faisant l'objet d'un enregistrement horodaté T dans la mémoire 18 (At > 0). Il applique pour cela une fonction f de plusieurs variables :

où z représente un ou plusieurs paramètres optionnels supplémentaires, décrivant par exemple des contraintes topologiques dans un environnement géographique du lieu défini par les données de localisation de l'enregistrement.

En pratique, les zones dans lesquelles les serveurs 3 sont capables de localiser les dispositifs ( zones de QoP ) sont de forme relativement simple, par exemple cercle, ellipse, secteur ou arc de cercle, polygone, etc.

L'ensemble des formes possibles peut être défini pour chaque technologie de positionnement. La fonction de transformation f peut alors être sélectionnée dans un ensemble de fonctions prédéfinies adaptées à des formes spécifiques de la zone de QoP.

Si la direction du vecteur vitesse est prise en considération, on met aussi à jour la localisation du dispositif et non seulement la forme de sa zone de QoP, en translatant la localisation précédente proportionnellement au vecteur v.

A titre d'illustration, les figures 2 à 4 montrent des exemples de transformations qui peuvent être appliquées dans le cas d'une zone de QoP circulaire produite par le serveur 3. Ce cercle a pour rayon ro (quantification de la OQoP) sur les figures 2 à 4.

Dans le cas de la figure 2, seule la valeur absolue 1 v 1 de la vitesse v est prise en compte dans la formule (1) en plus des paramètres OQoP =g (ro) et At. Avec une fonction décroissante g, l'expression de la fonction f est :

où 1 vil est une vitesse d'inflation prédéfinie exprimant la dégradation de la QoP à vitesse nulle.

Dans le cas de la figure 3, la direction de la vitesse v est prise en compte dans la formule (1), de sorte que la zone de QoP est elliptique, la QoP étant déterminée par deux quantités rx, ry respectivement égales au demi grand axe et au demi petit axe de l'ellipse. Pour la OQoP, rx = ry = ro.

L'expression de la fonction f est :

où a et p sont des coefficients dépendant de la direction de la vitesse v et exprimant les probabilités d'orientation de la vitesse suivant les deux axes de l'ellipse. La localisation estimée du dispositif change aussi : le centre du cercle OQoP est translaté suivant le grand axe de l'ellipse de la quantité Ax = y x 1 v x At, le coefficient y exprimant la probabilité de déplacement le long du grand axe de l'ellipse.

La transformation peut être enrichie en prenant en compte des contraintes topologiques aux alentours de la zone de localisation du dispositif, décrites par les paramètres z dans la formule (1). La figure 4 en donne une illustration dans le cas particulier où une rivière R fait obstacle au déplacement du dispositif dans une partie de la zone de QoP de la figure 3.

La figure 5 montre un exemple de procédure applicable par le module de gestion des données de localisation 16 en relation avec un enregistrement de la mémoire 18 pour traiter une requête de données de localisation concernant le dispositif faisant l'objet de cet enregistrement.

L'étape 20 représentée sur la figure 5 correspond à la réception d'un message de requête standard par le module 16, en provenance d'une application 2 à travers l'interface applications 12 ou en provenance du module de gestion de composants 17. La requête peut concerner une pluralité de dispositifs géolocalisables. Les étapes suivantes de la figure 5 se rapportent à l'un de ces dispositifs, pour lequel on suppose que la requête a été dûment validée au regard des droits d'accès de l'application ou du composant aux

données de localisation.

A la suite de la réception de la requête pour un dispositif géolocalisable, le module 16 calcule une qualité de positionnement courante à l'étape 21. Si aucun enregistrement n'est présent dans la mémoire 18 pour le dispositif en question, une valeur de QoP minimale est produite à l'étape 21. Sinon, la QoP courante est calculée comme expliqué ci-dessus à l'aide de la formule (1) et des paramètres pertinents de l'enregistrement.

La requête spécifie un objectif de QoP, représentant la précision souhaitée des données de localisation (par défaut, une valeur maximale peut être allouée à l'objectif de QoP). Au test 22, cet objectif est comparé à la QoP courante calculée à l'étape 21. Si la QoP courante est au moins aussi bonne que l'objectif fixé, le module 16 détermine, à l'étape 23, les données de localisation à retourner pour répondre à la requête à l'étape 24, soit en les lisant simplement dans l'enregistrement de la mémoire 18, soit en les recalculant à partir de cet enregistrement, notamment pour tenir compte du déplacement du dispositif dans le sens de son vecteur vitesse estimé.

Si le test 22 montre que la QoP courante calculée à l'étape 21 est insuffisante par rapport à l'objectif défini dans la requête, les données de localisation à retourner à l'étape 24 sont obtenues par une interrogation d'un serveur de localisation 3.

Si la requête initiale concernait plusieurs dispositifs géolocalisables, la réponse faite à l'étape 24 peut ainsi comporter des données de localisation récupérées dans la mémoire 18 pour certains dispositifs, et des données fraîchement obtenues d'un serveur 3 pour d'autres dispositifs. Dans chaque cas, la QoP associée peut être communiquée à l'application.

Avant d'interroger le serveur de localisation 3 quand la QoP courante est insuffisante, quelques opérations préliminaires peuvent être effectuées, en fonction de la configuration du module 16 par l'administrateur du système.

En particulier, si une fonction de positionnement prédictif est activée (test 26), le module 16 recalcule un objectif de QoP optimisé au moins égal à l'objectif défini pour la requête en cours de traitement, à l'étape 27. Ceci permet de prendre en compte, pour chaque méthode de positionnement, une combinaison de la qualité de positionnement et du coût d'obtention d'un jeu de

données de localisation. Si un dispositif donné peut être localisé par différentes méthodes et si ses données de localisation sont requises assez souvent, le positionnement prédictif permet d'optimiser l'usage de ces méthodes en termes de coût.

Par exemple, même si le coût d'une QoP supérieure est plus élevé, il peut être intéressant de requérir cette QoP supérieure si cela permet ultérieurement de se dispenser d'interroger un serveur 3 lors de la prochaine requête de données de localisation pour le même dispositif. Ceci est notamment vrai quand le coût d'une QoP supérieure est plus faible que le coût de deux interrogations successives avec l'objectif de QoP de la requête. Cette optimisation est fondée sur la fréquence des requêtes de données de localisation du dispositif, spécifiée par une application ou évaluée en tenant un historique de la distribution dans le temps des requêtes concernant le dispositif et issues de l'ensemble des applications utilisatrices, ce qui permet une prédiction de l'instant de la prochaine requête. L'historique peut porter en outre sur les QoP demandées pour le dispositif. L'optimisation peut aussi être réalisée de façon auto-adaptative. Si une prédiction suffisamment fiable ne peut pas être effectuée, la QoP fournie par l'étape 27 reste égale à l'objectif défini pour la requête.

Pour certains serveurs de localisation 3, la OQoP dépend de la topologie locale du réseau (habituellement différente en ville et à la campagne) et des caractéristiques du dispositif. Dans le premier cas, la prédiction prend en compte une QoP récente pour le dispositif et, si elle n'est pas connue, la pire QoP possible. Dans le second cas, la QoP est limitée par les caractéristiques du dispositif.

Après l'étape 27, ou si la fonction de positionnement prédictif n'est pas activée selon le test 26, le module 16 examine si une autre fonction de gestion d'interrogations concurrentes est activée (test 28). Dans l'affirmative, il examine si une interrogation d'un serveur de localisation 3 plus récente que celle ayant donné lieu à l'enregistrement pris en compte dans le calcul de la QoP courante à l'étape 21 est en cours auprès d'un serveur de localisation 3 (test 29).

Si tel est le cas, le module 16 compare l'objectif de QoP défini pour la requête (ou recalculé à l'étape 27) à celui qui a été spécifié pour l'interrogation

en cours (test 30). Si la QoP précédemment spécifiée est égale ou supérieure, il n'est pas nécessaire de réitérer l'interrogation, de sorte que le module 16 se place simplement en attente de la réponse du serveur de localisation 3 précédemment interrogé (étape 31).

A réception de cette réponse, l'enregistrement présent dans la mémoire 18 pour le dispositif concerné est mis à jour (ou créé si c'est une première interrogation pour le dispositif) avec les données retournées par le serveur 3 à l'étape 32, puis les données de localisation sont retransmises à l'application ou au composant à l'origine de la requête à l'étape 24 précitée.

Si la fonction de positionnement prédictif n'est pas activée selon le test 28, ou si aucune interrogation n'est en cours selon le test 29, ou encore si la QoP spécifiée dans la précédente interrogation ne suffit pas au regard de l'objectif selon le test 30, une nouvelle requête est adressée à un serveur 3 pour le dispositif.

Le serveur interrogé est d'abord sélectionné à l'étape 33. Si plusieurs serveurs externes 3 sont capables de localiser le dispositif avec la QoP souhaitée, le module 16 opère la sélection sur la base de critères incluant le nombre d'interrogations déjà envoyées à ces serveurs externes et en attente de réponse et/ou les temps de réponse moyens de ces serveurs. Cette sélection vise à minimiser la durée moyenne de récupération des données de localisation. La sélection peut aussi être réalisée suivant un mécanisme autoadaptatif d'équilibrage de charge.

Afin de réduire le nombre de messages d'interrogation envoyés au serveur de localisation 3 par l'intermédiaire de l'interface 13, il est possible de regrouper dans un même message de requête standard des interrogations à faire pour plusieurs dispositifs différents (étape 34).

A l'étape 35, le module 16 adresse l'interrogation au serveur sélectionné par l'intermédiaire de l'interface 13, puis il se place en attente de la réponse à l'étape 31 précitée.

Certaines applications utilisant de l'information sur la localisation de dispositifs ont besoin d'observer les mouvements d'un ensemble de dispositifs pour détecter des situations où elles ont à entreprendre des actions particulières, dictées par leur logique de service. La détection de ces situations

peut reposer sur des requêtes de localisation régulières, à une certaine fréquence, des dispositifs concernés. Elle peut aussi reposer sur des données de localisation générées seulement quand les dispositifs se déplace de façon significative. Dans les deux cas, la quantité de données de localisation requises par l'application peut être très importante en comparaison avec le nombre d'événements détectés.

De plus, si les mouvements du dispositif sont observés par de nombreuses applications, la gestion des données de localisation pour ce dispositif n'est pas optimisée globalement. En effet, si les requêtes issues des différentes applications sont désynchronisées (ce qui est le cas normal), la fréquence de positionnement augmente beaucoup. Même s'il était possible de synchroniser ces requêtes, ce qui serait techniquement complexe et économiquement irrationnel, la quantité de données échangées entre les serveurs de localisation et les applications resterait très importante, à cause de la nécessité de transmettre toutes les données de localisation obtenues des serveurs à toutes les applications requérantes.

Lorsque les événements à détecter dépendent principalement de la localisation d'un ou plusieurs dispositifs, le module de gestion de composants 17 déporté dans le LDDO 1 permet avantageusement de surmonter ces difficultés. Les événements détectés peuvent aussi dépendre d'un certain nombre de paramètres délivrés par les serveurs 3 ou par des sources de données externes 5 (par exemple trafic routier, météo, etc.).

On peut définir un certain nombre de situations typiques dont la détection est susceptible d'être prise en compte par diverses applications, par exemple : - cas où deux dispositifs d'une liste spécifiée sont à proximité l'un de l'autre (en-deçà d'une distance déterminée avec une précision déterminée) ; - cas où un dispositif d'une liste spécifiée entre dans une zone géographique déterminée ; etc.

L'analyse de données conduisant à la détection d'un tel événement peut être conduite par le module 17 en exécutant un composant logiciel prédéfini. Un tel composant consiste en une portion de code exécutable,

associé à un jeu de paramètres défini pour chaque application qui lui fait appel. Les paramètres comprennent notamment les identités des dispositifs de la liste à considérer ainsi que les critères quantitatifs de l'événement à détecter (localisation, distance, précision, trafic routier, etc. ) et la durée de vie du composant (limitée ou non). Ces paramètres sont modifiables par l'application à travers la partie XML/HTTP de l'interface 12.

Le LDDO offre en outre la possibilité d'exécuter des composants distants définis dynamiquement par les applications 2. Le module 17 comporte dans ce cas une machine virtuelle, par exemple une machine virtuelle Java (marque de la société Sun Microsystems), qui exécute le code de chaque composant dynamique, téléchargé par l'application. Cette machine virtuelle présente les API requises pour manipuler les données de localisation, les informations externes éventuellement fournies par les serveurs 5, ainsi que les paramètres et contextes des composants dynamiques (modifiables comme ceux des composants prédéfinis) et pour préparer et envoyer les messages signalant les événements pertinents aux applications 2.

Les entrées d'une instance de composant (prédéfini ou dynamique) comprennent les données de localisation et éventuellement d'autres informations, notamment issues des serveurs externes 5. Ses sorties sont les alertes logicielles avisant l'application des événements détectés ainsi qu'une description éventuelle de ces événements. L'instance de composant est initialisée par une requête spécifique envoyée par l'application qui précise ses attributs initiaux (paramètres, algorithme pour un composant dynamique), ultérieurement modifiables. Une instance de composant en cours d'exécution peut être stoppée et supprimée par une requête de destruction, ou automatiquement quand sa durée de vie spécifiée a expiré. L'instance de composant est exécutée à une fréquence définie dans les paramètres ou en réponse à un événement déterminé tel qu'une requête spécifique d'exécution issue de l'application.

L'exécution d'une instance de composant donne lieu à des requêtes de données de localisation adressées au module 16 selon les besoins. Ces requêtes peuvent être synchronisées avec celles directement issues des applications 2, ce qui permet de moins solliciter le module 16 et les serveurs 3.

Claims

REVENDICATIONS 1. Système de supervision de données de localisation de dispositifs géolocalisables, comprenant des moyens de traitement de requêtes de données de localisation incluant : - une mémoire de localisation (18) pour contenir des enregistrements comportant chacun des données de localisation d'un dispositif géolocalisable respectif délivrées par une source de données de localisation (3), accompagnées d'une information d'horodatage et d'une indication de qualité ; - des moyens de calcul (16) pour estimer une qualité de positionnement d'un dispositif géolocalisable concerné par une requête de données de localisation et pour lequel la mémoire de localisation contient un enregistrement, sur la base de paramètres incluant l'heure courante, l'information d'horodatage et l'indication de qualité comprises dans ledit enregistrement ; - des moyens (16) de comparaison entre la qualité de positionnement d'un dispositif géolocalisable concerné par une requête, estimée par les moyens de calcul, et un objectif de qualité de positionnement défini pour ladite requête, pour répondre à la requête à partir de l'enregistrement relatif au dispositif si la qualité estimée est suffisante par rapport à l'objectif et en interrogeant une source de données de localisation (3) sinon.
2. Système selon la revendication 1, dans lequel certains au moins des enregistrements de la mémoire de localisation (18) comportent, avec les données de localisation d'un dispositif géolocalisable respectif, une indication d'une vitesse de déplacement dudit dispositif, et dans lequel les paramètres sur la base desquels les moyens de calcul (16) estiment la qualité de positionnement dudit dispositif incluent ladite indication de vitesse.
3. Système selon la revendication 2, dans lequel ladite indication de vitesse comprend une valeur absolue d'une vitesse de déplacement estimée du dispositif.

<Desc/Clms Page number 16>
4. Système selon la revendication 3, dans lequel ladite indication de vitesse comprend en outre une direction de la vitesse de déplacement estimée du dispositif.
5. Système selon la revendication 4, dans lequel la réponse faite à la requête si la qualité estimée est suffisante par rapport à l'objectif comporte des données de localisation calculées à partir des données de localisation de l'enregistrement et de l'indication de vitesse correspondante.
6. Système selon l'une quelconque des revendications précédentes, dans lequel les paramètres sur la base desquels les moyens de calcul (16) estiment la qualité de positionnement d'un dispositif géolocalisable incluent des paramètres décrivant des contraintes topologiques (R) dans un environnement géographique d'un lieu défini par les données de localisation de l'enregistrement relatif au dispositif.
7. Système selon l'une quelconque des revendications précédentes, dans lequel les moyens de traitement de requêtes comprennent en outre des moyens de positionnement prédictif (16) pour recalculer un objectif de qualité de positionnement d'un dispositif géolocalisable concerné par une requête lorsque la qualité estimée est insuffisante par rapport à l'objectif défini pour ladite requête, et pour spécifier l'objectif de qualité recalculé pour l'interrogation de la source de données de localisation (3), et dans lequel l'objectif recalculé est au moins égal à l'objectif défini pour ladite requête et est déterminé en tenant compte de paramètres incluant une fréquence des requêtes de données de localisation dudit dispositif.
8. Système selon l'une quelconque des revendications précédentes, dans lequel les moyens de traitement de requêtes comprennent en outre des moyens (16) de gestion d'interrogations concurrentes de sources de données de localisation (3), pour déterminer si une interrogation relative à un dispositif géolocalisable concerné par une requête est en cours lorsque la qualité estimée est insuffisante par rapport à l'objectif défini pour ladite requête, la réponse à la requête étant élaborée à partir de la réponse à une interrogation en cours pour laquelle a été spécifié un objectif de qualité au moins égal à

<Desc/Clms Page number 17>

l'objectif défini pour ladite requête, ou en procédant à une nouvelle interrogation si un objectif de qualité au moins égal à l'objectif défini pour ladite requête n'a été spécifié pour aucune interrogation en cours relativement au dispositif.
9. Système selon l'une quelconque des revendications précédentes, comprenant une interface (13) de communication avec au moins une source externe de données de localisation (3).
10. Système selon la revendication 9, comprenant des moyens (16) de groupage d'interrogations pour adresser à une source externe de données de localisation (3), par l'intermédiaire de l'interface de communication (13), un message de demande de données de localisation de plusieurs dispositifs géolocalisables pour lesquels des qualités de positionnement respectivement estimées par les moyens de calcul sont insuffisantes par rapport à des objectifs respectifs définis pour des requêtes concernant lesdits dispositifs.
11. Système selon la revendication 9 ou 10, comprenant des moyens (16) pour adresser une interrogation relative aux données de localisation d'un dispositif vers une source de données de localisation sélectionnée parmi plusieurs sources externes de données de localisation (3) sur la base de critères incluant le nombre d'interrogations déjà envoyées auxdites sources externes et/ou les temps de réponse constatés de ces sources externes.
12. Système selon l'une quelconque des revendications précédentes, comprenant une interface (12) de communication avec au moins une application utilisatrice de données de localisation (2).
13. Système selon la revendication 12, comprenant des moyens (17) de détection d'événements par analyse de données de localisation d'au moins un dispositif géolocalisable fournies par les moyens de traitement de requêtes (16), pour signaler les événements détectés à au moins une application utilisatrice (2) par l'intermédiaire de l'interface de communication (12).

<Desc/Clms Page number 18>
14. Système selon la revendication 13, dans lequel les moyens de détection d'événements (17) sont agencés pour générer des requêtes de données de localisation adressées aux moyens de traitement (16).
15. Système selon la revendication 13 ou 14, dans lequel les moyens de détection d'événements (17) comprennent au moins un composant logiciel prédéfini exécuté pour une application utilisatrice (2), ayant une portion de code prédéterminée et des paramètres modifiables par ladite application utilisatrice par l'intermédiaire de l'interface de communication (12).
16. Système selon l'une quelconque des revendications 13 à 15, dans lequel les moyens de détection d'événements comprennent au moins un composant logiciel dynamique exécuté pour une application utilisatrice (2), ayant au moins une portion de code téléchargée par ladite application utilisatrice par l'intermédiaire de l'interface de communication (12).
17. Système selon l'une quelconque des revendications 13 à 16, comprenant en outre une interface (15) de communication avec au moins une source d'information externe (5), et dans lequel les moyens de détection d'événements sont agencés pour analyser les données de localisation d'au moins un dispositif géolocalisable en tenant compte d'informations obtenues depuis au moins une source d'information externe par l'intermédiaire de ladite interface de communication (15).