+

WO2002076121A1 - Systeme de controle d'acces a des donnees de localisation de dispositifs geolocalisables - Google Patents

Systeme de controle d'acces a des donnees de localisation de dispositifs geolocalisables Download PDF

Info

Publication number
WO2002076121A1
WO2002076121A1 PCT/FR2002/000910 FR0200910W WO02076121A1 WO 2002076121 A1 WO2002076121 A1 WO 2002076121A1 FR 0200910 W FR0200910 W FR 0200910W WO 02076121 A1 WO02076121 A1 WO 02076121A1
Authority
WO
WIPO (PCT)
Prior art keywords
location data
request
access
database
authorization parameters
Prior art date
Application number
PCT/FR2002/000910
Other languages
English (en)
Inventor
Wojciech Makowski
Original Assignee
Alternis
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alternis filed Critical Alternis
Publication of WO2002076121A1 publication Critical patent/WO2002076121A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/029—Location-based management or tracking services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/42229—Personal communication services, i.e. services related to one subscriber independent of his terminal and/or location
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2201/00—Electronic components, circuits, software, systems or apparatus used in telephone systems
    • H04M2201/14—Delay circuits; Timers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2203/00—Aspects of automatic or semi-automatic exchanges
    • H04M2203/20—Aspects of automatic or semi-automatic exchanges related to features of supplementary services
    • H04M2203/2072—Schedules, e.g. personal calendars
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2207/00—Type of exchange or network, i.e. telephonic medium, in which the telephonic communication takes place
    • H04M2207/18—Type of exchange or network, i.e. telephonic medium, in which the telephonic communication takes place wireless networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2242/00—Special services or facilities
    • H04M2242/30—Determination of the location of a subscriber
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/42025—Calling or Called party identification service
    • H04M3/42034—Calling party identification service
    • H04M3/42059—Making use of the calling party identifier
    • H04M3/42068—Making use of the calling party identifier where the identifier is used to access a profile
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/487—Arrangements for providing information services, e.g. recorded voice services or time announcements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/08—Mobility data transfer

Definitions

  • the present invention relates to a system for protecting access to location data of a set of geolocatable devices.
  • geolocatable device is understood here to mean a device allowing the determination of its geographic position and / or the description of its movements.
  • the means for determining these positions and / or movements may belong to the device itself (for example a GPS receiver). They can also be remote to the device, by operating on the basis of signals emitted by the latter.
  • a typical example of a geolocation device is a cellular radiotelephone.
  • the cellular network infrastructure makes it possible to locate the radiotelephone on the basis of the cell where it is located. The location of such a device results from the position of the base station with which it is communicating, or from that which picks up a response to a terminal search command ("paging") when the device is not not communicating.
  • the cellular network infrastructure can also employ known localization methods having a finer spatial resolution than that of cells.
  • a tracking device consists for example of a degraded cellular radio communication terminal to allow its location as indicated above, but not the establishment of communications.
  • An object of the present invention is to propose a technique allowing flexible and efficient control of access to location data from one or more user applications, in order to promote the development of various services using such data.
  • the invention thus proposes a system for controlling access to location data of geolocatable devices, comprising:
  • a database for containing authorization parameters defining access conditions, by at least one user application, to the location data of a set of geolocatable devices
  • This system acts as an intermediary between the applications using location data, one or more location servers capable of providing this data and the access authorities.
  • the system may belong, in whole or in part, to the same system as a location server.
  • Location servers can also be external. In the latter case, this system can be linked to several location servers corresponding for example to different cellular operators, so that the system presents itself, for user applications, as a one-stop shop where location data can be obtained. access is allowed.
  • the access authority can be the same for all user applications.
  • This single access authority can in particular be the device itself, which allows its holder to control the conditions under which it can be located.
  • the single authority can also be an information system of an organization operating a number of geolocatable devices (for example the system of supervision of a fleet of trucks).
  • the access authority for a given geolocation device can also be different from one user application to another.
  • the messages received by the second communication interface and analyzed by the filtering means typically carry requests for location data from user applications. They can also be response messages to such requests, passing through the access control system before being delivered to the applications concerned.
  • the access control system offers great flexibility in access conditions which may be taken into account in the authorization database.
  • These conditions may in particular relate to the application / device pair, the date and time of the request, the location of the device, data obtained from an external server to which the system is connected, etc.
  • Each access authority of a device can modify the authorization profile defined by the parameters contained in the database.
  • the updated parameters are then taken into account for the processing of requests for location data concerning the device.
  • FIG. 1 is a block diagram of a system for controlling access to location data according to the invention
  • FIG. 2 is a block diagram of a system for controlling access to location data according to the invention
  • FIG. 2 is a block diagram of a system for controlling access to location data according to the invention
  • FIG. 2 is a block diagram of a system for controlling access to location data according to the invention
  • FIG. 2 is a block diagram of a system for controlling access to location data according to the invention
  • FIG. 5 is a block diagram of an alternative embodiment of the system according to the invention.
  • a location server 3 is for example managed by a cellular radio operator. Several location servers 3 are accessible when the system cooperates with several cellular operators or when an operator has several location servers;
  • - access authorities 4 each having the capacity to define, for one or more geolocatable devices and one or more applications -conditions in which these applications can access the location data of these devices (module 14).
  • the access authority is also empowered to modify or delete previously granted authorizations.
  • the geolocatable device is a cellular radiocommunication terminal
  • its access authority 4 may consist of the terminal itself.
  • the access authority can also be a third party, for example the employer of the holder of a geolocatable device for professional use. Free access can still be specified for certain devices and / or certain user applications, in which case there is no access authority;
  • One or more external servers 5 from which the system 1 can obtain possibly relevant information to validate or reject requests for location data (module 15).
  • An example of such an external server 5 is a billing server of a cellular operator (for example, the validation of a request depends on the payment of the invoices by the holder of the geolocatable device).
  • the interface modules 12 and 13 support, for example, the application programming interface (API) called "Mobile Location Query", specified in a LIF standard.
  • API application programming interface
  • the interface 12 thus receives standard requests for location data from user applications 2, each identifying one or more devices whose location data is requested.
  • the interface 13 likewise transmits standard requests for location data to the location server or servers relevant for the device or devices concerned if the request received on the interface 12 is validated by a request filter 16 cooperating with a database. authorization data 18.
  • the responses received from the location servers 3, for example on the “Mobile Location Query” API, are retransmitted, after possible processing by the filter 16, to the user application 2 via the interface 12.
  • the interface modules 12 and 13 are advantageously connected to two separate local networks, for example of TCP / IP (“Transmission Control Protocol / Internet Protocol”) type.
  • TCP / IP Transmission Control Protocol / Internet Protocol
  • One of these local networks for example that located towards the location servers 3, can also be used for the connections to the external servers 5 by the interface module 15.
  • the authorization interface module 14 comprises on the one hand a mail server and on the other hand a portal server.
  • the messaging server for example voice and / or SMS (“Short Message Service”) type, allows a confirmation module 19 of the LDP system to communicate with the access authorities 4 to activate authorization parameters in the database 18 relating to one or more application / device pairs.
  • the portal server for example of the Web type, WAP (“Wireless Application Protocol”) or voice, allows the access authorities 4 to dialogue with an authorization profile management module 20 to define and update certain parameters. authorization of the database 18.
  • the LDP system 1 can be produced from two platforms of the RS 6000 type sold by the company IBM, one including interfaces 12, 13 and 15 and the request filter 16, and the other including the interface 14 as well as the authorization database 18, the modules 19, 20 for confirmation and management of profiles and a system administration module (not shown in Figure 1). These two platforms can communicate with each other via the same local network as that providing the links with the location servers 3 and the external servers 5.
  • the two platforms are provided with programs, for example developed in C language / C ++, for the execution of access control procedures such as those described below.
  • the purpose of the LDP system is to protect location data that one or more location servers 3 can provide against unauthorized access by user applications 2.
  • the basic task is to examine each standard request from a user application 2 to determine whether it can be answered, in whole or in part.
  • the LDP system can generate and return a refusal message directly to the application from which it originated.
  • the request is transmitted to the location server (s) 3 concerned, after having undergone any processing in the LDP system.
  • processing may for example consist in removing from the list of devices to be located according to the original request those for which authorization has not been granted.
  • the processing can also include a referral of requests re-sent to several location servers (for example in the case where the location of the various devices listed is carried out by several distinct cellular operators). If the APIs supported by interfaces 12 and 13 are distinct (unlike the example considered above), processing can also include a translation of the request between the two API formats.
  • the response returned by the location server (s) 3 can be transmitted directly to the requesting application 2, or it can be previously processed by the LDP system. In the latter case, the filter 16 can make some additional checks, in particular if authorization conditions defined in the database 18 relate to the actual location and / or movements of the device. If necessary, the response returned to the user application can be modified in order to remove the location data to which access is not authorized and / or to add information indicating the reasons why access was been refused.
  • the protection mechanisms for location data are at two levels: the level of services implemented by user applications and the level of geolocatable devices.
  • the protection mechanisms at the service level are based on known access control methods, using for example authentication methods using passwords or public keys. This ensures that only authorized and authenticated user applications can address their requests to the LDP system. These mechanisms are for example applied via the applications interface 12. It should be noted that they are optional: if they are not used, access to any user application is assumed to be authorized at the service level.
  • the administration module of the LDP system (not shown in FIG. 1) configures the applications interface 12 for each new user application capable of being authorized to access the LDP system. This configuration concerns the following parameters:
  • free requests - types of requests authorized unconditionally, called “free requests” (if such free requests are provided, they are transmitted directly from the interface 12 to the interface 13 without being processed by the request filter 16); - type of access authority and possibly description of its parameters
  • the LDP system administrator can also modify the configuration of the interface 12 for any user application 2 and in particular delete the access rights of an application.
  • the protection mechanisms at device level ensure that a user application 2 (where applicable already authorized at service level) can only access location data for geolocatable devices for which an authorization has been explicitly given.
  • the service-level protection mechanism can be applied at the entry of the LDP system (on request from a user application), or at the exit of the LDP system (before responding to the user application), or at the same time at the entrance and at the exit.
  • the protection mechanisms at device level are applied by the filter 16 in relation to the authorization database 18 and possibly the information coming from the external servers 5.
  • the database 18 contains an authorization profile comprising a separate set of authorization restriction parameters for each user application 2 or each system provided with one or more user applications. These parameters describe conditions under which the application is authorized to access the location data of the device.
  • these authorization restriction parameters are set to default values, which may depend on the application concerned.
  • the access authority assigned to the geolocatable device can modify the values of these parameters by dialoguing with the profile management module 20 through the portal server of the interface 14.
  • the module 20 saves the updated parameters in the authorization database 18.
  • the authorization conditions defined by the profile parameters can relate to one or more of the following elements or their combinations:
  • - authorization period during the day (for example from 8 am to 6 pm). These periods can be understood daily or be associated with a particular type of day (for example working day, weekend, ...);
  • time interval during which access is suspended for the user application (for example from January 3, 2001, 6 p.m. to January 10, 2001, 8 a.m.).
  • Such information relates for example to the level of service consumption of geolocalizable devices of the cell phone type or user applications, local weather, etc.
  • the access authority can view and modify the authorization profiles using various types of technology (Web, Wap, SMS, voice server, etc.). In the absence of certain identification, this access to the profiles can be protected by passwords. Each authority 4 has its own password. If the same authority manages authorizations for several geolocatable devices, the same password can be used at the interface level 14.
  • the authorization profile is very specific (based on specific logic of the service using location data), it can be managed directly by the system running the application in question.
  • FIGS. 2 and 3 show examples of procedures applicable by the request filter 16 in connection with the interfaces 12, 13, 15 and with the authorization database 18 when receiving a message from request from a user application 2 and upon receipt of a response message from a location server 3, respectively.
  • Step 21 represented in FIG. 2 corresponds to the reception of a standard request message on the applications interface 12, in accordance with the communication protocols supported by this interface.
  • the interface 12 extracts from this message a certain number of parameters including a type of request specified in the message, a request number, the time of issue or reception of the request, an identifier and a signature of the application.
  • user 2 where the message comes from (step 22).
  • the application interface 12 examines whether the request carried by the message is a free request, that is to say one that does not require any specific authorization (test 23). If the request is free, it is directly transmitted to the location interface 13 to be sent to a location server 3 (step 24).
  • the LDP system performs the authorization procedure at the service level while seeking to authenticate the application 2 from which the message originates (test 25).
  • This authentication can relate to the identifier and the signature extracted from the message in step 22.
  • the authentication process can include exchanges of additional messages with the user application.
  • the application interface 12 returns a refusal message to the application 2 from which the request originates (steps 26 and 27).
  • the request is decoded and, if necessary, decrypted by the filter 16 which extracts the list of identifiers of geolocatable devices for which the location data are requested (step 28).
  • the filter 16 For each device k identified in the request, the filter 16 consults in the database 18 the authorization profile relating to the application which was identified in step 22, and examines whether each of the authorization conditions defined by this profile is met (test 29). The test is performed on the basis of comparisons relating to the current time (or that extracted from the request in step 22) as well as to various other attributes specified in the profile. Yes some of these authorization conditions relate to data available from an external server 5, the test 29 includes an interrogation of this server 5 through the interface 15 for retrieving the relevant data.
  • the request is rejected with respect to this device (step 26).
  • This rejection can consist simply in removing the identifier of the device k from the list of the request.
  • this identifier can be marked by assigning it an authorization refusal indicator.
  • the states of this indicator can possibly identify the cause of the refusal (for example, inadequate request time).
  • the choice between the two rejection methods above can be configured by the LDP administrator.
  • the devices k for which the request has been rejected can be indicated in a refusal message returned to the application 2 through the interface 12, possibly with the indicators identifying the causes of refusal.
  • the request is validated (step 30) with respect to each device k for which access has been authorized by the filter 16 during the test 29.
  • a secondary request transmitted by the location interface 13 This transmission is encrypted if encryption is provided on the link with the location server (s) 3. If applicable (if the same server 3 does not provide all the required data), the interface 13 ensures the formatting of several standard requests addressed to several location servers 3.
  • the location interface 13 stores an association between the primary request from which it derives, extracted from the initial message in step 22, and this secondary request.
  • the interface 13 finds the association of the secondary request with the corresponding primary request in order to allow the subsequent referral of the response to the application concerned (step 32).
  • the response is then decoded and, if necessary, decrypted by the filter 16 which extracts the list of identifiers geolocatable devices concerned as well as the corresponding location data which have been supplied by the location server 3 (step 33). If the server 3 was unable to provide the location data of a device k from the list submitted to it (test 34), this failure to respond will be reported to the user application in the response returned by the intermediary. of the interface 12 in step 35. Otherwise, the filter 16 performs a comparison between the location data of the device k and the parameters of the corresponding authorization profile to verify whether the supply of this data to the application is authorized (test 36). If this supply is not authorized, the request is rejected with regard to device k (step 37 similar to step 26 above: deletion of the identifier of device k in the list or marking with an indicator identifying the cause refusal), and the refusal will be reported to the application in step 38.
  • the location data to which access was authorized to test 36 are included in the response returned by the interface 12 in step 35, in association with the identifier of the corresponding device k.
  • the response or refusal message returned to the application in step 35 or 38 can be encrypted if this is required on the interface 12.
  • initial values are allocated to the authorization parameters of the new application / device pair, but the profile thus defined is not yet activated in the database 18.
  • the allocation of these initial values can be carried out following the subscription of a subscription to a service rendered by this application relative to one or more geolocatable devices.
  • the initial values are for example default values defined by the application concerned. They can also be agreed between the application manager and the subscriber to the service prior to subscription. These initial values can be recorded in the database 18 with a non-activation indicator, or in an annex database, under the control of the administration module of the LDP system or in response to a special request received on the applications interface 12 ; - Then, a confirmation is requested from the access authority 4 assigned to the new application / device pair by means of the confirmation module 19 and the messaging server of the interface 14. If a confirmation is received in response to this request , the module 19 activates the initial profile in the base 18. The profile activated in response to this confirmation may also have been modified beforehand by the access authority 4 via the portal server of the interface 14 and of the module profile management 20. To facilitate this interaction, the parameters of this profile are presented to the access authority 4 in the confirmation request message.
  • This two-step procedure ensures flexible management of the implementation of services and facilitates careful control, by holders of geolocatable devices, of the conditions of access to their location data.
  • Two non-exclusive methods can be used to trigger a request for confirmation of authorization from a user application 2 for access to the location data of a given geolocation device:
  • the LDP system can ensure that permissions denied to a given application are not too frequent. It can thus build indicators of behavior of user applications, usable in the event of abuse (do not launch the confirmation procedure for devices that have already been the subject of a refusal, no longer respond to any request, publish the wrong ones behavioral indicators, etc.).
  • a special confirmation request designating a list of devices an application 2 of which will require the location data is detected on the basis of the type of message indicated in the message received on the interface 12.
  • This request is passed to the confirmation module 19 which generates the confirmation request and transmits it to the or the competent access authority (ies) via the messaging server of the interface 14.
  • the responses are then examined to activate or maintain inactive the authorization profiles concerned in the database 18.
  • FIG. 4 illustrates an example of a test procedure which can be executed in place of the test 29 of FIG. 2 and which incorporates a detection of the "new" devices for which confirmation must be requested.
  • the request filter 16 first examines (step 41) whether an active authorization profile is active in the database 18 for the application / device pair identified in steps 22 and 28. If so, the different conditions d access described by the active profile are examined in relation to the parameters of the request during test 42, and according to the result of this examination, the request is either validated (step 43) or rejected by indicating the authorization condition (s) which have not been met (step 44).
  • the filter 16 determines whether a profile which has not yet been activated has been defined for the application / device pair, that is to say whether an authorization confirmation is awaited for this pair (test 45). .
  • the request is rejected, indicating to the application that it relates to a device not registered with it (step 46). If there is a profile not yet activated, the module 19 is warned to send a confirmation request to the access authority of the device (step 47), and the request for location data for the device in question can be either rejected, indicating the reason as represented by step 48, or put on standby for confirmation by the access authority.
  • steps 28 to 30 of Figure 2 are not executed in response to the reception of a request message on the applications interface 12.
  • the location data is requested from the server (s) 3 for all the devices identified in the primary request authorized at the service level, and the analysis of the authorization conditions for each device k is entirely carried out during test 36 of FIG. 3 (which therefore also relates to the conditions of test 29 of FIG. 2).
  • This latter possibility is not very advantageous when the location data is obtained from one or more external servers 3, because it leads to a load on the location servers relative to data which will not be delivered.
  • This possibility may however be suitable when the location data are obtained from a local source, such as the location database 6 of the LDP system 10 represented in FIG. 5.
  • This variant 10 of the LDP system comprises a certain number of 'elements 12, 14, 18-20 similar to those bearing the same references in Figure 1 (the external interface 15, optional, is absent here).
  • the requests for location data extracted from the messages received on the applications interface 12 are processed by a module 7 with regard in particular to the following functions: decoding / decryption of the requests; recovery of the location data of each device concerned in the local database 6; interrogation of the request filter 8 relative to each device concerned, by specifying its location data for the assessment of any conditions of a geographic type; collection of responses (validation / rejection) developed by the filter 8 using the relevant authorization profiles contained in the database 18; consolidation of these responses and reporting to the interface 12.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Storage Device Security (AREA)

Abstract

Le système comporte: une première interface (14) de communication avec des autorités 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 des applications utilisatrices, 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 une ou plusieurs sources de messages se rapportant à des requêtes de données de localisation issues des applications utilisatrices (2); et des moyens de filtrage (16) 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 pour valider ces requêtes de façon dépendante du résultat de l'analyse.

Description

'I
SYSTEME DE CONTROLE D'ACCES A DES DONNEES DE LOCALISATION DE DISPOSITIFS GEOLQCALISABLES
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 œuvre 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 », 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/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, 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 elle peut être préalablement traitée 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 œuvre 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éolocalisabjes, 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 (« nouveau » 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.

Claims

R E V E N D I C A T I O N S
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.
PCT/FR2002/000910 2001-03-16 2002-03-14 Systeme de controle d'acces a des donnees de localisation de dispositifs geolocalisables WO2002076121A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR01/03617 2001-03-16
FR0103617A FR2822336A1 (fr) 2001-03-16 2001-03-16 Systeme de controle d'acces a des donnees de localisation de dispositifs geolocalisables

Publications (1)

Publication Number Publication Date
WO2002076121A1 true WO2002076121A1 (fr) 2002-09-26

Family

ID=8861225

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2002/000910 WO2002076121A1 (fr) 2001-03-16 2002-03-14 Systeme de controle d'acces a des donnees de localisation de dispositifs geolocalisables

Country Status (2)

Country Link
FR (1) FR2822336A1 (fr)
WO (1) WO2002076121A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5748148A (en) * 1995-09-19 1998-05-05 H.M.W. Consulting, Inc. Positional information storage and retrieval system and method
WO1998052379A1 (fr) * 1997-05-16 1998-11-19 Telefonaktiebolaget Lm Ericsson Protection de l'integrite dans un systeme de telecommunications
WO2000038467A1 (fr) * 1998-12-21 2000-06-29 Telefonaktiebolaget Lm Ericsson (Publ) Procedes et appareil de transfert de donnees de positions entre des terminaux dans des systemes de communication sans fil
US6138003A (en) * 1997-11-26 2000-10-24 Ericsson Inc. System and method for authorization of location services

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5748148A (en) * 1995-09-19 1998-05-05 H.M.W. Consulting, Inc. Positional information storage and retrieval system and method
WO1998052379A1 (fr) * 1997-05-16 1998-11-19 Telefonaktiebolaget Lm Ericsson Protection de l'integrite dans un systeme de telecommunications
US6138003A (en) * 1997-11-26 2000-10-24 Ericsson Inc. System and method for authorization of location services
WO2000038467A1 (fr) * 1998-12-21 2000-06-29 Telefonaktiebolaget Lm Ericsson (Publ) Procedes et appareil de transfert de donnees de positions entre des terminaux dans des systemes de communication sans fil

Also Published As

Publication number Publication date
FR2822336A1 (fr) 2002-09-20

Similar Documents

Publication Publication Date Title
US8862129B2 (en) Systems and methods for encrypted mobile voice communications
EP2248295B1 (fr) Système et procédé pour dispositif sans fil basé sur l'authentification d'un utilisateur
US10045327B2 (en) Mobile communication device monitoring systems and methods
EP2491735B1 (fr) Dispositif et procédé de gestion des droits d'accès à un réseau sans fil
US10027648B2 (en) Geolocation dependent variable authentication
US9572033B2 (en) Systems and methods for encrypted mobile voice communications
EP1683388A2 (fr) Methode de gestion de la s curit d' applications avec un module de securite
FR2864289A1 (fr) Controle d'acces biometrique utilisant un terminal de telephonie mobile
EP1964361A1 (fr) Architecture et procede pour controler le transfert d'informations entre utilisateurs
US8675828B2 (en) Authentication of a user to a telephonic communication device
US20060020816A1 (en) Method and system for managing authentication attempts
EP2369780B1 (fr) Procédé et système de validation d'une transaction, terminal transactionnel et programme correspondants.
EP2348763B1 (fr) Procédé d'authentification d'un terminal mobile pour accéder à un serveur d'applications
CN107995616B (zh) 用户行为数据的处理方法以及装置
CN106778334A (zh) 账号信息的保护方法及移动终端
CA2864030C (fr) Systemes et procedes pour des communications vocales mobiles chiffrees
WO2002076121A1 (fr) Systeme de controle d'acces a des donnees de localisation de dispositifs geolocalisables
EP2299667B1 (fr) Controle parental de l'utilisation d'un terminal mobile
CN119155129B (zh) 一种煤矿多服务间快速认证的方法及系统
JP7536047B2 (ja) 乗物環境における多要素認証およびアクセス制御
Rosati A comprehensive study of cyber threats and countermeasures in micromobility
EP1510904B1 (fr) Procédé et système d'évaluation du niveau de sécurité de fonctionnement d'un équipement électronique et d'accès conditionnel à des ressources
CN116318971A (zh) 基于身份认证的一种零信任im终端配置方法
CN119520152A (zh) 一种支持多类型和多模式的新能源汽车数据接入方法
FR2873260A1 (fr) Nouveau procede de localisation interpersonnelle par des terminaux numeriques mobiles et ses utilisations

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SD SE SG SI SK SL TJ TM TN TR TT TZ UA UG US UZ VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: CONSTATATION DE LA PERTE D UN DROIT CONFORMEMENT A LA REGLE 60(1) CBE

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载