Brevet FR2822336A1 — publié le 20020920

SYSTEME DE CONTROLE D'ACCES A DES DONNEES DE LOCALISATION DE DISPOSITIFS GEOLOCALISABLES La présente invention se rapporte à un système servant à protéger l'accès à des données de localisation d'un ensemble de dispositifs géolocalisables. 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. 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. Ce développement pose le problème de la confidentialité des données de localisation, qui doit être préservée notamment pour protéger la vie privée des détenteurs de dispositifs géolocalisables et leur permettre d'exercer un certain contrôle sur la diffusion de ces données. Un exemple classique d'un tel service se rapporte à la tarification dans les réseaux cellulaires : le tarif appliqué pour une communication depuis ou vers un radiotéléphone cellulaire dépend généralement de la localisation de celui-ci dans le réseau ou dans des réseaux partenaires. Dans le cadre d'un tel service de facturation dépendant de la localisation, il est relativement aisé de préserver la confidentialité des données de localisation puisque celles-ci sont uniquement à la disposition de l'opérateur cellulaire. Des privilèges peuvent éventuellement être accordés à des tiers tels que les forces de police, mais ceci se fait naturellement sans contrôle de la part du détenteur. En revanche, dès que des prestataires de service multiples sont susceptibles d'avoir accès à des données de localisation, le problème de confidentialité devient central et peut constituer un frein au développement de nouveaux services à valeur ajoutée de ce type, en raison de contraintes légales et des réticences des clients que cela permet de localiser. Une but de la présente invention est de proposer une technique permettant de contrôler de manière souple et efficace l'accès aux données de localisation depuis une ou plusieurs applications utilisatrices, afin de favoriser le développement de services variés utilisant de telles données. L'invention propose ainsi un système de contrôle d'accès à des données de localisation de dispositifs géolocalisables, comprenant : - une première interface de communication avec au moins une autorité d'accès aux données de localisation ; - une base de données pour contenir des paramètres d'autorisation définissant des conditions d'accès, par au moins une application utilisatrice, aux données de localisation d'un ensemble de dispositifs géolocalisables ; -des moyens de mise à jour des paramètres d'autorisation enregistrés dans la base de données, par l'intermédiaire de la première interface de communication ; - une seconde interface de communication avec au moins une source de messages se rapportant à des requêtes de données de localisation issues d'au moins une application utilisatrice ; et - des moyens de filtrage pour analyser des messages se rapportant à des requêtes de données de localisation reçus par la seconde interface de communication, en relation avec les paramètres d'autorisation contenus dans la base de données, et valider lesdites requêtes de données de localisation de façon dépendante du résultat de l'analyse. Ce système joue un rôle d'intermédiaire entre les applications utilisatrices de données de localisation, un ou plusieurs serveurs de localisation capables de fournir ces données et les autorités d'accès. Le système peut appartenir, en totalité ou en partie, au même système qu'un serveur de localisation. Les serveurs de localisation peuvent également être externes. Dans ce dernier cas, ce système peut être relié à plusieurs serveurs de localisation correspondant par exemple à des opérateurs cellulaires différents, de sorte que le système se présente, pour les applications utilisatrices, comme un guichet unique où peuvent être obtenues les données de localisation auquel l'accès est autorisé. Pour un dispositif géolocalisable donné, l'autorité d'accès peut être la même pour toutes les applications utilisatrices. Cette autorité d'accès unique peut notamment être le dispositif lui-même, ce qui permet à son détenteur de maîtriser les conditions dans lesquelles il pourra être localisé. L'autorité unique peut également être un système d'information d'une organisation exploitant un certain nombre de dispositifs géolocalisables (par exemple le système de supervision d'une flotte de camions). L'autorité d'accès pour un dispositif géolocalisable donné peut également être différente d'une application utilisatrice à une autre. Les messages reçus par la seconde interface de communication et analysés par les moyens de filtrage portent typiquement des requêtes de données de localisation issues des applications utilisatrices. Ils peuvent également être des messages de réponse à de telles requêtes, transitant par le système de contrôle d'accès avant d'être remis aux applications concernées. En plus de la richesse de ses interfaces qui lui permettent d'être raccordé à une ou plusieurs applications utilisatrices, une ou plusieurs autorités d'accès et un ou plusieurs serveurs de localisation, le système de contrôle d'accès offre une grande souplesse dans les conditions d'accès pouvant être prises en compte dans la base de données d'autorisation. Ces conditions peuvent notamment porter sur le couple application/dispositif, sur la date et l'heure de la requête, sur la localisation du dispositif, sur des données obtenues depuis un serveur externe auquel le système est relié, etc. Chaque autorité d'accès d'un dispositif peut modifier le profil d'autorisation défini par les paramètres contenus dans la base de données. Les paramètres mis à jour sont ensuite pris en compte pour le traitement des requêtes de données de localisation concernant le dispositif. 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 contrôle d'accès à des données de localisation selon l'invention ; -les figures 2 à 4 sont des organigrammes de procédures utilisables dans le système de la figure 1 ; et -la figure 5 est schéma synoptique d'une variante de réalisation du système selon l'invention. Le système de contrôle d'accès 1 représenté sur la figure 1, ci-après appelé système de protection de données de localisation ou système LDP ( Location Data Protection ), comporte des modules d'interface 12-15 qui lui permettent de communiquer avec quatre types d'entité, à savoir : - des applications 2 mettant en oeuvre des services utilisant 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 ; - des autorités d'accès 4 ayant chacune la capacité de définir, pour un ou plusieurs dispositifs géolocalisables et une ou plusieurs applications utilisatrices, des conditions dans lesquelles ces applications peuvent avoir accès aux données de localisation de ces dispositifs (module 14). L'autorité d'accès est également habilitée à modifier ou supprimer des autorisations précédemment accordées. Dans le cas particulier où le dispositif géolocalisable est un terminal de radiocommunication cellulaire, son autorité d'accès 4 peut consister en le terminal lui-même. L'autorité d'accès peut aussi être un tiers, par exemple l'employeur du détenteur d'un dispositif géolocalisable d'usage professionnel. Il peut encore être spécifié un accès libre pour certains dispositifs et/ou certaines applications utilisatrices, auquel cas il n'y a pas d'autorité d'accès ; - un ou plusieurs serveurs externes 5 auprès desquels le système 1 peut obtenir des informations éventuellement pertinentes pour valider ou rejeter des requêtes de données de localisation (module 15). Un exemple d'un tel serveur externe 5 est un serveur de facturation d'un opérateur cellulaire (par exemple, cas où la validation d'une requête dépend du paiement des factures par le détenteur du dispositif géolocalisable). 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. L'interface 13 transmet de même des requêtes standard de données de localisation vers le ou les serveurs de localisation pertinents pour le ou les dispositifs concernés si la requête reçue sur l'interface 12 est validée par un filtre de requêtes 16 coopérant avec une base de données d'autorisation 18. Les réponses reçues des serveurs de localisation 3, par exemple sur l'API Mobile Location Query dz sont retransmises, après un traitement éventuel par le filtre 16, vers l'application utilisatrice 2 par l'intermédiaire de l'interface 12. 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/ ! P ( Transmission Control Protocol/Internet Protocol ). Ceci permet au système 1 de séparer physiquement les applications utilisatrices 2 des serveurs de localisation 3, en jouant ainsi un rôle de pare-feu pour améliorer la sécurité d'accès aux données de localisation. L'un de ces réseaux locaux, par exemple celui situé vers les serveurs de localisation 3, peut également servir pour les liaisons aux serveurs externes 5 par le module d'interface 15. Dans une réalisation particulière du système LDP, le module d'interface d'autorisation 14 comporte d'une part un serveur de messagerie et d'autre part un serveur de portail. Le serveur de messagerie, par exemple vocal et/ou de type SMS ( Short Message Service ), permet à un module de confirmation 19 du système LDP de dialoguer avec les autorités d'accès 4 pour activer des paramètres d'autorisation dans la base de données 18 relativement à un ou plusieurs couples application/dispositif. Le serveur de portail, par exemple de type Web, WAP ( Wireless Application Protocol ) ou vocal, permet aux autorités d'accès 4 de dialoguer avec un module de gestion de profils d'autorisation 20 pour définir et mettre à jour certains paramètres d'autorisation de la base de données 18. A titre d'illustration, le système LDP 1 peut être réalisé à partir de deux plates-formes de type RS 6000 commercialisées par la société IBM, l'une incluant des interfaces 12,13 et 15 et le filtre de requêtes 16, et l'autre incluant l'interface 14 ainsi que la base de données d'autorisation 18, les modules 19, 20 de confirmation et de gestion de profils et 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 avec les serveurs de localisation 3 et les serveurs externes 5. Les deux plates-formes sont pourvues de programmes, par exemple développés en langage C/C++, pour l'exécution de procédures de contrôle d'accès telles que celles décrites plus loin. L'objet du système LDP est de protéger des données de localisation que peuvent fournir un ou plusieurs serveurs de localisation 3 contre des accès non autorisés par des applications utilisatrices 2. La tâche de base consiste à examiner chaque requête standard provenant d'une application utilisatrice 2 afin de déterminer s'il peut y être répondu, en totalité ou en partie. Si aucune réponse ne peut être faite à la requête, le système LDP peut générer et retourner un message de refus directement à l'application d'où elle provient. Sinon, la requête est transmise au (x) serveur (s) de localisation 3 concerné (s), après avoir subi un traitement éventuel dans le système LDP. Un tel traitement peut par exemple consister à retirer de la liste des dispositifs à localiser d'après la requête d'origine ceux pour lesquels l'autorisation n'a pas été accordée. Le traitement peut également comprendre un aiguillage des requêtes ré-émises vers plusieurs serveurs de localisation (par exemple dans le cas où la localisation des différents dispositifs listés est effectuée par plusieurs opérateurs cellulaires distincts). Si les API supportées par les interfaces 12 et 13 sont distinctes (contrairement à l'exemple considéré plus haut), le traitement peut également comporter une traduction de la requête entre les deux formats d'API. La réponse retournée par le ou les serveurs de localisation 3 peut être transmise directement à l'application requérante 2, ou elles peuvent être préalablement traitées par le système LDP. Dans ce dernier cas, le filtre 16 peut faire quelques vérifications supplémentaires, notamment si des conditions d'autorisation définies dans la base de données 18 portent sur la localisation effective et/ou les mouvements du dispositif. Le cas échéant, la réponse retournée à l'application utilisatrice peut être modifiée afin d'enlever les données de localisation auxquelles l'accès n'est pas autorisé et/ou pour ajouter de l'information indiquant les raisons pour lesquelles l'accès a été refusé. Les mécanismes de protection des données de localisation se situent à deux niveaux : le niveau des services mis en oeuvre par les applications utilisatrices et le niveau des dispositifs géolocalisables. Les mécanismes de protection au niveau service sont fondés sur des méthodes de contrôle d'accès connues, utilisant par exemple des méthodes d'authentification par mots de passe ou à clés publiques. Ceci assure que seules les applications utilisatrices autorisées et authentifiées peuvent adresser leurs requêtes au système LDP. Ces mécanismes sont par exemple appliqués par l'interface applications 12. Il est à noter qu'ils sont optionnels : s'ils ne sont pas utilisés, l'accès de n'importe quelle application utilisatrice est supposé autorisé au niveau service. Le module d'administration du système LDP (non représenté sur la figure 1) configure l'interface applications 12 pour chaque nouvelle application utilisatrice susceptible d'être autorisée à accéder au système LDP. Cette configuration concerne les paramètres suivants : - paramètres des protocoles d'accès ; - paramètres de protection au niveau service ; - types de requêtes autorisées ; - types de requêtes autorisées inconditionnellement, dites requêtes libres (si de telles requêtes libres sont prévues, elles sont transmises directement de l'interface 12 vers l'interface 13 sans être traitées par le filtre de requêtes 16) ; - type d'autorité d'accès et éventuellement description de ses paramètres (protocoles, adresses,...). L'administrateur du système LDP peut également modifier la configuration de l'interface 12 pour toute application utilisatrice 2 et en particulier supprimer les droits d'accès d'une application. Les mécanismes de protection au niveau dispositif assurent qu'une application utilisatrice 2 (le cas échéant déjà autorisée au niveau service) ne peut accéder aux données de localisation que pour les dispositifs géolocalisables pour lesquels une autorisation a été explicitement donnée. Le mécanisme de protection au niveau service peut être appliqué à l'entrée du système LDP (sur requête provenant d'une application utilisatrice), ou à la sortie du système LDP (avant de répondre à l'application utilisatrice), ou à la fois à l'entrée et à la sortie. Les mécanismes de protection au niveau dispositif sont appliqués par le filtre 16 en relation avec la base de données d'autorisation 18 et éventuellement les informations provenant des serveurs externes 5. Pour chaque dispositif géolocalisable pris en compte par le système LDP, la base de données 18 contient un profil d'autorisation comportant un jeu distinct de paramètres de restriction d'autorisation pour chaque application utilisatrice 2 ou chaque système pourvu d'une ou plusieurs application utilisatrice. Ces paramètres décrivent des conditions dans lesquelles l'application est autorisée à accéder aux données de localisation du dispositif. Initialement, ces paramètres de restriction d'autorisation sont fixés à des valeurs par défaut, qui peuvent dépendre de l'application concernée. Ensuite, l'autorité d'accès affectée au dispositif géolocalisable peut modifier les valeurs de ces paramètres en dialoguant avec le module de gestion de profils 20 à travers le serveur de portail de l'interface 14. Le module 20 enregistre les paramètres mis à jour dans la base de données d'autorisation 18. Les conditions d'autorisation définies par les paramètres du profil peuvent porter sur un ou plusieurs des éléments suivants ou leurs combinaisons : - zone géographique inclusive. L'accès aux données de localisation du dispositif n'est autorisé que si celui-ci est localisé à l'intérieur d'une zone géographique spécifiée par les paramètres du profil ; - zone géographique exclusive. L'accès aux données de localisation du dispositif n'est autorisé que si celui-ci est localisé à l'extérieur d'une zone géographique spécifiée par les paramètres du profil ; - toute autre restriction, inclusive et/ou exclusive, déterminable à partir de paramètres déduits des données de localisation récupérées, tels que par exemple la vitesse du dispositif, son altitude, l'orientation de son mouvement, etc. ; - période d'autorisation dans la journée (par exemple de 8 heures à 18 heures). Ces périodes peuvent s'entendre quotidiennement ou être associées avec un type de jour particulier (par exemple jour ouvré, week- end,...) ; - intervalle de temps pendant lequel l'accès est suspendu pour l'application utilisatrice (par exemple du 3 janvier 2001,18 heures au 10 janvier 2001, 8 heures). - une liste de dispositifs autorisés. Si une telle liste est utilisée, elle spécifie des dispositifs affiliés qui sont autorisés à bénéficier du service rendu par l'application utilisatrice des données de localisation. Par exemple, cette liste peut spécifier pour un mobile M et un service de rendez-vous S quels sont les mobiles dont le service S est autorisé à détecter qu'ils se trouvent dans un voisinage déterminé du mobile M ; - toute autre restriction, inclusive et/ou exclusive, fondée sur une ou plusieurs informations externes récupérables depuis une source externe 5 par l'intermédiaire de l'interface 15 du système LDP. De telles informations relèvent par exemple du niveau de consommation de services des dispositifs géolocalisables de type téléphone cellulaire ou des applications utilisatrices, de la météo locale, etc. On peut ainsi définir des jeux de paramètres différenciés par dispositif géolocalisable et par application utilisatrice habilitée. On peut aussi prévoir deux autres classes de paramètres analogues : - des paramètres d'autorisation définissant des conditions différenciées par dispositif géolocalisable, mais indépendantes des applications utilisatrices ; - des paramètres d'autorisation définissant des conditions différenciées par application utilisatrice, mais indépendantes des dispositifs géolocalisables. Toutes ces classes de paramètres d'autorisation peuvent être combinées ensemble, chaque classe étant optionnelle. L'autorité d'accès peut consulter et modifier les profils d'autorisation en utilisant divers types de technologie (Web, Wap, SMS, serveur vocal,...). En l'absence d'identification certaine, cet accès aux profils peut être protégé par des mots de passe. Chaque autorité 4 a son propre mot de passe. Si la même autorité gère les autorisations pour plusieurs dispositifs géolocalisables, le même mot de passe peut être utilisé au niveau de l'interface 14. Dans certains cas, si le profil d'autorisation est très spécifique (basé sur une logique spécifique du service utilisant les données de localisation), il peut être géré directement par le système exécutant l'application en question. On peut alors être amené à adapter le serveur de portail de l'interface 14 aux interfaces de supervision de ces systèmes. Les figures 2 et 3 montrent des exemples de procédures applicables par le filtre de requêtes 16 en liaison avec les interfaces 12,13, 15 et avec la base de données d'autorisation 18 lors de la réception d'un message de requête depuis une application utilisatrice 2 et lors de la réception d'un message de réponse depuis un serveur de localisation 3, respectivement. L'étape 21 représentée sur la figure 2 correspond à la réception d'un message de requête standard sur l'interface applications 12, conformément aux protocoles de communication supportés par cette interface. L'interface 12 extrait de ce message un certain nombre de paramètres incluant un type de requête spécifié dans le message, un numéro de requête, l'heure d'émission ou de réception de la requête, un identifiant et une signature de l'application utilisatrice 2 d'où provient le message (étape 22). Sur la base du type de requête extrait du message à l'étape 22, l'interface application 12 examine si la requête portée par le message est une requête libre, c'est-à-dire ne nécessitant pas d'autorisation particulière (test 23). Si la requête est libre, elle est directement transmise à l'interface de localisation 13 pour être envoyée à un serveur de localisation 3 (étape 24). Sinon, le système LDP exécute la procédure d'autorisation au niveau service en cherchant à authentifier l'application 2 d'où provient le message (test 25). Cette authentification peut porter sur l'identifiant et la signature extraits du message à l'étape 22. En variante, le processus d'authentification peut comporter des échanges de messages supplémentaires avec l'application utilisatrice. Si l'autorisation n'est pas accordée au niveau service, la requête de données de localisation est rejetée et l'interface application 12 retourne un message de refus à l'application 2 d'où provient la requête (étapes 26 et 27). Lorsque l'application 2 a été correctement authentifiée, la requête est décodée et, le cas échéant, déchiffrée par le filtre 16 qui extrait la liste des identifiants de dispositifs géolocalisables dont les données de localisation sont demandées (étape 28). Pour chaque dispositif k identifié dans la requête, le filtre 16 consulte dans la base de données 18 le profil d'autorisation relatif à l'application qui a été identifiée à l'étape 22, et examine si chacune des conditions d'autorisation définies par ce profil est remplie (test 29). Le test est effectué sur la base de comparaisons portant sur l'heure courante (ou celle extraite de la requête à l'étape 22) ainsi que sur divers autres attributs spécifiés dans le profil. Si certaines de ces conditions d'autorisation portent sur des données disponibles auprès d'un serveur externe 5, le test 29 comporte une interrogation de ce serveur 5 à travers l'interface 15 pour la récupération des données pertinentes. Si l'accès aux données de localisation du dispositif k n'est pas autorisé, la requête est rejetée à l'égard de ce dispositif (étape 26). Ce rejet peut consister simplement à retirer l'identifiant du dispositif k de la liste de la requête. En variante, cet identifiant peut être marqué en lui affectant un indicateur de refus d'autorisation. Les états de cet indicateur peuvent éventuellement identifier la cause du refus (par exemple heure de requête inadéquate). Le choix entre les deux méthodes de rejet ci-dessus peut-être configuré par l'administrateur du système LDP. Le cas échéant, les dispositifs k pour lesquels la requête a été rejetée peuvent être indiqués dans un message de refus retourné à l'application 2 à travers l'interface 12, éventuellement avec les indicateurs identifiant les causes de refus. La requête est validée (étape 30) vis-à-vis de chaque dispositif k pour lequel l'accès a été autorisé par le filtre 16 lors du test 29. Une fois que tous les identifiants de la liste ont été examinés, ceux pour lesquels la requête a été validée font l'objet d'une requête secondaire transmise par l'interface de localisation 13. Cette transmission est chiffrée si un chiffrement est prévu sur la liaison avec le ou les serveurs de localisation 3. Le cas échéant (si le même serveur 3 ne permet pas de disposer de toutes les données requises), l'interface 13 assure la mise en forme de plusieurs requêtes standard adressées à plusieurs serveurs de localisation 3. Lors de l'envoi de chaque requête secondaire, l'interface de localisation 13 mémorise une association entre la requête primaire d'où elle découle, extraite du message initial à l'étape 22, et cette requête secondaire. A réception du message de réponse sur l'interface de localisation 13 (étape 31 sur la figure 3), l'interface 13 retrouve l'association de la requête secondaire avec la requête primaire correspondante afin de permettre l'aiguillage ultérieur de la réponse vers l'application concernée (étape 32). Si un traitement supplémentaire doit être effectué (protection au niveau service appliquée à la sortie du système LDP), la réponse est ensuite décodée et, le cas échéant, déchiffrée par le filtre 16 qui extrait la liste des identifiants des dispositifs géolocalisables concernés ainsi que les données de localisation correspondantes qui ont été fournies par le serveur de localisation 3 (étape 33). Si le serveur 3 a été incapable de fournir les données de localisation d'un dispositif k de la liste qui lui a été soumise (test 34), ce défaut de réponse sera signalé à l'application utilisatrice dans la réponse retournée par l'intermédiaire de l'interface 12 à l'étape 35. Sinon, le filtre 16 effectue une comparaison entre les données de localisation du dispositif k et les paramètres du profil d'autorisation correspondant pour vérifier si la fourniture de ces données à l'application est autorisée (test 36). Si cette fourniture n'est pas autorisée, la requête est rejetée à l'égard du dispositif k (étape 37 semblable à l'étape 26 précitée : suppression de l'identifiant du dispositif k dans la liste ou marquage avec un indicateur identifiant la cause de refus), et le refus sera signalé à l'application à l'étape 38. Les données de localisation auxquelles l'accès a été autorisé au test 36 sont incluses dans la réponse retournée par l'interface 12 à l'étape 35, en association avec l'identifiant du dispositif k correspondant. Le message de réponse ou de refus retourné à l'application à l'étape 35 ou 38 peut être chiffré si cela est requis sur l'interface 12. Pour la prise en compte d'un nouveau profil d'autorisation dans la base de données d'autorisation 18, on procède avantageusement en deux étapes : - dans un premier temps, des valeurs initiales sont allouées aux paramètres d'autorisation du nouveau couple application/dispositif, mais le profil ainsi défini n'est pas encore activé dans la base de données 18. Typiquement, l'allocation de ces valeurs initiales peut être effectuée à la suite de la souscription d'un abonnement à un service rendu par cette application relativement à un ou plusieurs dispositifs géolocalisables. Les valeurs initiales sont par exemple des valeurs par défaut définies par l'application concernée. Elles peuvent aussi être convenues entre le gestionnaire de l'application et l'abonné au service préalablement à la souscription. Ces valeurs initiales peuvent être enregistrées dans la base de données 18 avec un indicateur de non activation, ou dans une base annexe, sous le contrôle du module d'administration du système LDP ou en réponse à une requête spéciale reçue sur l'interface applications 12 ; - ensuite, une confirmation est demandée à l'autorité d'accès 4 affectée au nouveau couple application/dispositif au moyen du module de confirmation 19 et du serveur de messagerie de l'interface 14. Si une confirmation est reçue en réponse à cette demande, le module 19 active le profil initial dans la base 18. Le profil activé en réponse à cette confirmation peut aussi avoir été modifié préalablement par l'autorité d'accès 4 par l'intermédiaire du serveur portail de l'interface 14 et du module de gestion de profils 20. Pour faciliter cette interaction, les paramètres de ce profil sont présentés à l'autorité d'accès 4 dans le message de demande de confirmation. Cette procédure en deux étapes assure une gestion souple de la mise en place des services et facilite un contrôle attentif, par les détenteurs de dispositifs géolocalisables, des conditions d'accès à leurs données de localisation. Deux méthodes non-exclusives peuvent être utilisées pour déclencher une demande de confirmation d'autorisation d'une application utilisatrice 2 pour l'accès aux données de localisation d'un dispositif géolocalisable donné : - une méthode de détection automatique des nouveaux dispositifs ( nouveaux signifie ici que l'autorité d'accès pertinente n'a pas encore confirmé l'autorisation d'accès par l'application 2) dans les listes d'identifiants figurant dans les requêtes standard ; et - une méthode de traitement de requêtes de confirmation spéciales issues de l'application 2 et désignant une liste de dispositifs dont l'application 2 requerra les données de localisation. Dans les deux cas, une demande de confirmation est adressée à une ou plusieurs autorités d'accès. Le système LDP peut s'assurer que les autorisations refusées à une application donnée ne sont pas trop fréquentes. Il peut ainsi construire des indicateurs de comportement des applications utilisatrices, utilisables en cas d'abus (ne pas lancer la procédure de confirmation pour des dispositifs ayant déjà fait l'objet d'un refus, ne plus répondre à aucune requête, publier les mauvais indicateurs de comportement, etc. ). Une requête de confirmation spéciale désignant une liste de dispositifs dont une application 2 requerra les données de localisation est détectée sur la base du type de message indiqué dans le message reçu sur l'interface 12. Cette requête est passée au module de confirmation 19 qui génère la demande de confirmation et la transmet à la ou les autorité (s) d'accès compétente (s) par l'intermédiaire du serveur de messagerie de l'interface 14. Les réponses sont ensuite examinées pour activer ou maintenir inactifs les profils d'autorisation concernés dans la base de données 18. La figure 4 illustre un exemple de procédure de test qui peut être exécutée à la place du test 29 de la figure 2 et qui incorpore une détection des nouveaux dispositifs pour lesquels une confirmation doit être demandée. Le filtre de requêtes 16 examine d'abord (étape 41) si un profil d'autorisation actif est actif dans la base de données 18 pour le couple application/dispositif identifié aux étapes 22 et 28. Dans l'affirmative, les différentes conditions d'accès décrites par le profil actif sont examinées par rapport aux paramètres de la requête lors du test 42, et selon le résultat de cet examen, la requête est soit validée (étape 43) soit rejetée en indiquant la ou les conditions d'autorisation qui n'ont pas été remplies (étape 44). En l'absence de profil actif, le filtre 16 détermine si un profil non encore activé a été défini pour le couple application/dispositif, c'est-à-dire si une confirmation d'autorisation est attendue pour ce couple (test 45). En l'absence de tout profil, la requête est rejetée en indiquant à l'application qu'elle porte sur un dispositif non inscrit à son égard (étape 46). S'il existe un profil non encore activé, le module 19 est averti pour adresser une demande de confirmation à l'autorité d'accès du dispositif (étape 47), et la requête de données de localisation pour le dispositif en question peut être soit rejetée, en indiquant la raison comme représenté par l'étape 48, soit mise en attente de confirmation de la part de l'autorité d'accès. Lorsque la protection au niveau service est appliquée à la sortie du système LDP mais non à l'entrée, les étapes 28 à 30 de la figure 2 ne sont pas exécutées en réponse à la réception d'un message de requête sur l'interface applications 12. Les données de localisation sont demandées au (x) serveur (s) 3 pour tous les dispositifs identifiés dans la requête primaire autorisée au niveau service, et l'analyse des conditions d'autorisation pour chaque dispositif k est entièrement effectuée lors du test 36 de la figure 3 (qui porte donc aussi sur les conditions du test 29 de la figure 2). Cette dernière possibilité n'est pas très intéressante lorsque les données de localisation sont obtenues depuis un ou plusieurs serveurs externes 3, car elle conduit à une charge sur les serveurs de localisation relativement à des données qui ne seront pas délivrées. Cette possibilité peut toutefois convenir lorsque les données de localisation sont obtenues à partir d'une source locale, telle que la base de données de localisation 6 du sytème LDP 10 représenté sur la figure 5. Cette variante 10 du système LDP comporte un certain nombre d'éléments 12,14, 18-20 semblables à ceux portant les mêmes références sur la figure 1 (l'interface externe 15, optionnelle, est ici absente). Les requêtes de données de localisation extraites des messages reçus sur l'interface applications 12 sont traitées par un module 7 pour ce qui concerne notamment les fonctions suivantes : décodage/déchiffrement des requêtes ; récupération des données de localisation de chaque dispositif concerné dans la base de données locale 6 ; interrogation du filtre de requête 8 relativement à chaque dispositif concerné, en précisant ses données de localisation pour l'appréciation des éventuelles conditions de type géographique ; collecte des réponses (validation/rejet) élaborées par le filtre 8 à l'aide des profils d'autorisation pertinents contenus dans la base de données 18 ; consolidation de ces réponses et compte rendu vers l'interface 12. On appréciera que diverses autres architectures peuvent encore être retenues pour le système LDP selon l'invention. REVENDICATIONS 1. Système de contrôle d'accès à des données de localisation de dispositifs géolocalisables, comprenant : - une première interface (14) de communication avec au moins une autorité d'accès aux données de localisation (4) ; - une base de données (18) pour contenir des paramètres d'autorisation définissant des conditions d'accès, par au moins une application utilisatrice, aux données de localisation d'un ensemble de dispositifs géolocalisables ; -des moyens (19,20) de mise à jour des paramètres d'autorisation enregistrés dans la base de données, par l'intermédiaire de la première interface de communication ; - une seconde interface (12) de communication avec au moins une source de messages se rapportant à des requêtes de données de localisation issues d'au moins une application utilisatrice (2) ; et -des moyens de filtrage (16 ; 8) pour analyser des messages se rapportant à des requêtes de données de localisation reçus par la seconde interface de communication, en relation avec les paramètres d'autorisation contenus dans la base de données, et valider lesdites requêtes de données de localisation de façon dépendante du résultat de l'analyse. 2. Système selon la revendication 1, dans lequel les messages reçus par la seconde interface de communication (12) et analysés par les moyens de filtrage (16 ; 8) portent des requêtes de données de localisation issues d'au moins une application utilisatrice (2). 3. Système selon la revendication 2, dans lequel la seconde interface de communication (12) comprend des moyens d'identification et d'authentification de l'application utilisatrice (2) d'où est issue une requête de données de localisation. 4. Système selon la revendication 3, comprenant des moyens pour extraire un type de requête de chaque message reçu par la seconde interface de communication et portant une requête issue d'une application utilisatrice authentifiée, et pour valider automatiquement les requêtes d'au moins un type particulier. 5. Système selon l'une quelconque des revendications précédentes, comprenant des moyens (16 ; 7) de traitement des requêtes de données de localisation validées par les moyens de filtrage (16 ; 8). 6. Système selon la revendication 5, dans lequel les moyens de traitement des requêtes validées (16 ; 7) sont agencés pour interroger au moins une source (3 ; 6) de données de localisation d'un dispositif pour lequel une requête de données de localisation a été validée par les moyens de filtrage (16 ; 8). 7. Système selon la revendication 6, comprenant une troisième interface (13) de communication avec au moins une source de données de localisation (3) externe au système (1) et interrogeable par les moyens de traitement des requêtes validées (16). 8. Système selon la revendication 7, dans lequel les seconde et troisième interfaces de communication (14,13) sont reliées à des réseaux distincts. 9. Système selon l'une quelconque des revendications 6 à 8, dans lequel les moyens de filtrage (16 ; 8) sont agencés pour analyser des données de localisation incluses dans un message retourné par une source (3 ; 6) de données de localisation d'un dispositif pour lequel une requête de données de localisation a été validée et, de façon dépendante du résultat de l'analyse, autoriser la transmission de certaines au moins desdites données de localisation vers l'application utilisatrice (2) d'où est issue ladite requête. 10. Système selon l'une quelconque des revendications précédentes, dans lequel les moyens de mise à jour des paramètres d'autorisation comprennent des moyens (19) d'activation de paramètres d'autorisation dans la base de données (18) pour générer une demande de confirmation d'autorisation pour au moins une application utilisatrice (2) émise par l'intermédiaire de la première interface de communication (14) vers une autorité d'accès (4) affectée à au moins un dispositif géolocalisable, et pour activer des paramètres d'autorisation dans la base de données relativement audit dispositif et à ladite application utilisatrice lorsqu'une confirmation est reçue en réponse à ladite demande. 11. Système selon la revendication 10, dans lequel les moyens d'activation de paramètres d'autorisation (19) sont agencés pour traiter une requête de prise en compte d'une liste de nouveaux dispositifs géolocalisables, reçue depuis une application utilisatrice (2) par l'intermédiaire de la seconde interface de communication (12), en générant une demande de confirmation relativement à chaque dispositif de ladite liste. 12. Système selon la revendication 10 ou 11, dans lequel les moyens de filtrage (16 ; 8) sont agencés pour détecter chaque requête de données de localisation concernant au moins un nouveau dispositif géolocalisable pour lequel la base de données (18) ne contient pas de paramètres d'autorisation actifs relativement à l'application utilisatrice (2) d'où provient ladite requête, et dans lequel les moyens d'activation de paramètres d'autorisation (19) sont agencés pour générer une demande de confirmation relativement à chaque nouveau dispositif pour lequel une requête de données de localisation a été détectée. 13. Système selon l'une quelconque des revendications 10 à 12, dans lequel certaines au moins des autorités d'accès (4) comprennent des terminaux de radiocommunication cellulaire, et dans lequel la première interface de communication (14) est agencée pour communiquer avec lesdites autorités d'accès sous forme de messages courts ou de messages vocaux pour l'émission des demandes de confirmation et la réception des réponses à ces demandes. 14. Système selon l'une quelconque des revendications précédentes, dans lequel les moyens de mise à jour des paramètres d'autorisation comprennent des moyens de gestion de profils (20) pour présenter à l'autorité d'accès (4) affectée à un dispositif géolocalisable les paramètres d'autorisation contenus dans la base de données relativement audit dispositif, et pour modifier lesdits paramètres d'autorisation en réponse à des instructions reçues de l'autorité d'accès par l'intermédiaire de la première interface de communication (14). 15. Système selon la revendication 14, dans lequel la première interface de communication (14) comprend un serveur de portail pour faire communiquer les autorités d'accès (4) avec le module de gestion de profils (20). 16. Système selon l'une quelconque des revendications précédentes, dans lequel les conditions d'accès définies par les paramètres d'autorisation contenus dans la base de données (18) comprennent des conditions différenciées par dispositif géolocalisable et par application utilisatrice. 17. Système selon l'une quelconque des revendications précédentes, dans lequel les conditions d'accès définies par les paramètres d'autorisation contenus dans la base de données (18) comprennent des conditions différenciées par dispositif géolocalisable indépendamment des applications utilisatrices. 18. Système selon l'une quelconque des revendications précédentes, dans lequel les conditions d'accès définies par les paramètres d'autorisation contenus dans la base de données (18) comprennent des conditions différenciées par application utilisatrice indépendamment des dispositifs géolocalisables. 19. Système selon l'une quelconque des revendications précédentes, dans lequel les conditions d'accès définies par les paramètres d'autorisation contenus dans la base de données (18) comprennent des conditions portant sur l'heure de la requête de données de localisation analysée par les moyens de filtrage (16 ; 8). 20. Système selon l'une quelconque des revendications précédentes, dans lequel les conditions d'accès définies par les paramètres d'autorisation contenus dans la base de données (18) relativement à un dispositif géolocalisable comprennent des conditions portant sur les données de localisation dudit dispositif. 21. Système selon l'une quelconque des revendications précédentes, dans lequel les conditions d'accès définies par les paramètres d'autorisation contenus dans la base de données (18) relativement à un dispositif géolocalisable comprennent des conditions portant sur les données de localisation d'au moins un autre dispositif géolocalisable. 22. Système selon l'une quelconque des revendications précédentes, comprenant en outre une interface (15) de communication avec au moins une source d'information externe (5), dans lequel les conditions d'accès définies par les paramètres d'autorisation contenus dans la base de données (18) comprennent des conditions portant sur des données obtenues depuis ladite source d'information externe.