EP3025481A2 - Procédé de traitement de données de géolocalisation - Google Patents

Procédé de traitement de données de géolocalisation

Info

Publication number
EP3025481A2
EP3025481A2 EP14744556.3A EP14744556A EP3025481A2 EP 3025481 A2 EP3025481 A2 EP 3025481A2 EP 14744556 A EP14744556 A EP 14744556A EP 3025481 A2 EP3025481 A2 EP 3025481A2
Authority
EP
European Patent Office
Prior art keywords
geolocation
data
mobile terminal
server
application server
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP14744556.3A
Other languages
German (de)
English (en)
Inventor
Antonino Famulari
Thomas Bonald
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Institut Mines Telecom IMT
Original Assignee
Institut Mines Telecom IMT
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 Institut Mines Telecom IMT filed Critical Institut Mines Telecom IMT
Publication of EP3025481A2 publication Critical patent/EP3025481A2/fr
Withdrawn legal-status Critical Current

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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/2228—Indexing structures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/29—Geographical information databases
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
    • G06F21/6254—Protecting personal data, e.g. for financial or medical purposes by anonymising data, e.g. decorrelating personal data from the owner's identification
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/566—Grouping or aggregating service requests, e.g. for unified processing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • H04L67/5682—Policies or rules for updating, deleting or replacing the stored data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • H04L67/5683—Storage of data provided by user terminals, i.e. reverse caching
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/59—Providing operational support to end devices by off-loading in the network or by emulation, e.g. when they are unavailable
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/02—Protecting privacy or anonymity, e.g. protecting personally identifiable information [PII]
    • 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
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/18—Information format or content conversion, e.g. adaptation by the network of the transmitted or received information for the purpose of wireless delivery to users or terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/20—Services signaling; Auxiliary data signalling, i.e. transmitting data via a non-traffic channel
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02—Power saving arrangements
    • H04W52/0209—Power saving arrangements in terminal devices
    • H04W52/0251—Power saving arrangements in terminal devices using monitoring of local events, e.g. events related to user activity
    • H04W52/0254—Power saving arrangements in terminal devices using monitoring of local events, e.g. events related to user activity detecting a user operation or a tactile contact or a motion of the device
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02—Power saving arrangements
    • H04W52/0209—Power saving arrangements in terminal devices
    • H04W52/0251—Power saving arrangements in terminal devices using monitoring of local events, e.g. events related to user activity
    • H04W52/0258—Power saving arrangements in terminal devices using monitoring of local events, e.g. events related to user activity controlling an operation mode according to history or models of usage information, e.g. activity schedule or time of day
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/69—Identity-dependent
    • H04W12/75—Temporary identity
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Definitions

  • the present invention relates to a method for processing geolocation data.
  • Modern mobile terminals of the smartphone type have geolocation capabilities, allowing for example the navigation on a map, "check-in”, that is to say the publication of the position of a user on social networks, as well as many other features.
  • the geolocation data is transmitted to a trusted server, which returns to the terminal processed data corresponding to different levels of associated accuracy possible (for example, if the user geolocates in an airport, the different levels can from the precise number of the airport door in which the user is, to the general indication of the region in which the airport is located), for selection by the user and transmission to a or multiple application servers for one or more check-ins.
  • This process can slightly reduce the consumption to the extent that some treatments are deported.
  • check-ins are a small part of energy consumption for geolocation purposes. Indeed, it is the mechanisms of "tracking" (French tracking) that consume the most battery mobile. Tracking consists of the repeated sending (for example every thirty seconds) of the user's position so as to allow dynamic functionalities, for example the sending of a notification if the user passes close to a predetermined position (a center of interest, a known person, a sign, etc.).
  • Tracking consists of the repeated sending (for example every thirty seconds) of the user's position so as to allow dynamic functionalities, for example the sending of a notification if the user passes close to a predetermined position (a center of interest, a known person, a sign, etc.).
  • a proposal that has been made to reduce the energy consumption related to tracking is the forced reduction in the frequency of updating geolocation data, which can affect the operation of certain applications.
  • Document US 201 1/0159884 also discloses a solution in which a server storing the position of the terminal serves as an interface for the various application servers, the terminal not transmitting its position to the server intermediate only if it moves significantly. This solution therefore makes it possible to reduce the energy consumption of the terminal only in the case of reduced mobility.
  • the present invention thus relates to a geolocation data processing method comprising the implementation by data processing means of a server of steps of:
  • a trusted server to respond to requests sent by the application servers makes it easy to anonymize the geolocation data and to rationalize the solicitation of the geolocation means of the mobile terminals: if several applications require these data, it just transmit them once to the server, and it is the latter that processes multiple requests.
  • this method requires only the implementation of a lightweight module on the terminal and facilitates the development of new applications using geolocation, as long as it is sufficient to contact a single server, which can handle complex queries offering advanced features (for example, notification request if a certain event occurs).
  • advanced features for example, notification request if a certain event occurs.
  • Said unique identifier is an anonymous identifier generated by the mobile terminal and received by the data processing means of the server during step (a);
  • Said unique identifier is an anonymous identifier generated in step (b) by the data processing means of the server and sent to the mobile terminal;
  • Said unique identifier received by the mobile terminal is sent to the application server if the user authorizes the application server to access his geolocation data;
  • the geolocation data are also associated in said database with temporal data relating to the moment of their reception in step (b);
  • the method comprises a step (e1) of transmitting a new first request, receiving updated geolocation data from the mobile terminal and then updating the database stored on the data storage means;
  • the method comprises the repetition of steps (d) and (e), wherein step (e1) being implemented following each step (d) if the data processing means of the server determine according to associated rules the application server that issued the second request that the geolocation data be updated;
  • step (e1) being repeated at a frequency depending on the frequencies at which the sequence of steps (d) and (e) is repeated for an application server and / or at least one rule associated with the application server;
  • the response generated in step (e) comprises a degraded version of the geolocation data associated with the unique identifier in said database
  • the second request received in step (d) comprises reference geolocation data, according to a rule associated with the application server the step (e) comprises comparing the geolocation data associated with the unique identifier in said database with the reference geolocation data, the generated response being a function of the result of said comparison.
  • the invention relates to a geolocation data processing server connected to at least one mobile terminal comprising geolocation means and to at least one application server, the server comprising data storage means and means data processing configured to implement:
  • a second module for receiving a second geolocation request sent by the application server, the second request comprising said unique identifier associated with the mobile terminal;
  • the invention relates to a system comprising: at least one mobile terminal comprising geolocation means; at least one application server;
  • At least one server according to the second aspect.
  • the mobile terminal implements a module for managing the rules associated with each application server.
  • the invention relates to a computer program product comprising code instructions for executing a method according to the first aspect of the geolocation data processing invention; and computer readable storage means on which a computer program product comprises code instructions for executing a method according to the first aspect of the geolocation data processing invention.
  • FIG. 1 represents an architecture for implementing the method according to the invention.
  • One or more mobile terminals 1a, 1b are connected to a communication network 20 (in particular a mobile telephone network).
  • a communication network 20 in particular a mobile telephone network.
  • Each mobile terminal 1a, 1b may be any device capable of connecting to the communication network 20. It may for example act as a smartphone, a touch pad, etc.
  • Each mobile terminal 1a, 1b comprises geolocation means 10, which can implement one of the many geolocation techniques implemented on mobile terminals (GPS, GSM positioning, RFID, etc.). It will be understood that the preceding method is not limited in any way to obtain on the mobile terminal 1a, 1b location data, and that the means 10 can take any form (physical and / or software).
  • a server 2 is connected to the communication network 20. It is a “trusted” server, in particular a server of the network operator 20. It conventionally comprises a data processing module 21 (a processor) and a data storage module 22 (for example a hard disk).
  • a data processing module 21 a processor
  • a data storage module 22 for example a hard disk
  • This server 2 is itself connected for example via the Internet network 30 to one or more application servers 3a, 3b. They are servers involved in the operation of an application (for example one or more servers of a social network), at the origin of geolocation data requests sent to the terminals 1 a, 1 b.
  • application servers 3a, 3b are servers involved in the operation of an application (for example one or more servers of a social network), at the origin of geolocation data requests sent to the terminals 1 a, 1 b.
  • the Applicant has noticed that it is now common that several applications simultaneously use the geolocation data of a mobile terminal, especially in tracking mode. For example, it is possible that the user is using a first application of type "map" displaying a map on which the position of the user is displayed, while in the background some applications, designed by example to send a notification if the user is near a friend, a restaurant, etc., works.
  • the application server of each of these applications "tracks" the position of the user, that is to say that he requires (possibly at regular intervals) the location data of his mobile terminal 1 a, 1 b.
  • the present method thus proposes a way of avoiding any redundancy in the management of the geolocation data, thanks to the trusted server 2.
  • the present server 2 instead of operating in a "push” mode in which it is the terminal 1a, 1b that decides when to send geolocation data to the server (it “pushes” the data), the present server 2 implements a so-called “pull” mode of operation in which it explicitly asks for the terminal position when appropriate (the server "pulls” the data), the latter simply replying.
  • the intelligence (with regard to the management of the geolocation) of the terminal 1a, 1b is at least partially moved to the trusted server 2.
  • the server 2 operates only in push mode.
  • a first step (a) the data processing means 21 of the server 2 transmit to the mobile terminal a first geolocation request (this is the pull request).
  • these data processing means 21 receive from the mobile terminal 1a, 1b geolocation data (obtained by the geolocation means 10).
  • This sending has the particularity of not being implemented in response to a request from an application. It just aims to provide this data to the server 2 for storage.
  • this first request can follow, or on the contrary precede, a second request coming from an application server 3a, 3b.
  • these data are associated in a database stored on the data storage means 22 of the server 2, with a unique identifier itself associated with the mobile terminal 1a, 1b.
  • the geolocation data are also associated in this database with time data (typically time) relative to the moment of their reception in step (b).
  • the database of the server 2 consists of triplets of type (identifier, geolocation data, time). Many terminals 1a, 1b can be managed within a single database.
  • This unique identifier is an anonymous identifier that can be either generated by the data processing means 21 of the server 2 and sent to the mobile terminal 1 a, 1 b (during the step (b)), or generated by the mobile terminal. 1 a, 1 b, which directly sends the pair (identifier, data) to the server 2 in step (b).
  • the unique identifier makes it possible to anonymize the geolocation data by preventing the latter from being referenced via data enabling the terminal 1a, 1b or its user to be directly identified.
  • the trusted server 2 Only the trusted server 2 is possibly able to link a unique identifier to the real identity of the user, which guarantees the confidentiality of the geolocation data.
  • the terminal 1a, 1b which generates (and changes) the identifier it is possible to make the server 2 is not able to bind the old and the new identifier, since it receives directly a new pair (identifier, data), which it can interpret as representing a new terminal. This increases the confidentiality, but it may be desirable to avoid it if, for example, an application uses past positions of the terminal 1a, 1b.
  • the unique identifier can be changed (that is to say regenerated by the server 2 / the terminal 1a, 1b) at regular intervals, for example every hour.
  • the "current" unique identifier of the mobile terminal 1 a, 1 b is sent to the application server 3a, 3b (so that the latter can designate the terminal 1a, 1b) if the user authorizes the application server 3a , 3b to access its geolocation data.
  • This authorization can be given via a software module implemented on the terminal 1a, 1b (which will be described in more detail below).
  • the sending can be done either by the terminal 1a, 1b, or by the server 2.
  • the server 2 can receive in a step (d) a second geolocation request sent by the application server 3a, 3b, the second request comprising said unique identifier associated with the mobile terminal 1a, 1b ( as well as additional data that will be described later). It is note that step (d) may optionally precede one or more of steps (a) to (c). Indeed step (d) and steps (a) to (c) are independent and server 2 does not control the arrival time of the second requests.
  • the data processing means 21 of the server 2 will then generate and send to the application server 3a, 3b (in a step (e)) a response to the second request according to the geolocation data associated with the unique identifier in said base data, and rules associated with the application server 3a, 3b.
  • Steps (d) and (e) occur as many times as second requests are sent to server 2. As will be seen later, each second request may or may not give rise to the updating of geolocation data (in other words the sending of a first request).
  • the trusted server 2 that receives the second requests and responds to them. None of the second requests is transmitted to the terminal 1 a, 1 b. The latter only sees the first requests (which are in practice much less numerous than the second queries thanks to the intelligence of the server 2) and is thus not solicited excessively.
  • All exchanges between terminals and trusted server, application servers and trusted server
  • a single sending of geolocation data by the terminal 1a, 1b can be exploited by a plurality of application servers 3a, 3b, the energy cost of generating a response per request being reported on the server 2
  • the present precedes provides a one-stop service to the applications, allowing the mobile terminal 1a, 1b to send only once its geographical position, this information being available for all applications.
  • Energy consumption linked to geolocation becomes independent of the number of active applications; o on the other hand the terminal 1 a, 1 b is solicited to the strict minimum thanks to the filtering done intelligently by the server which transforms a large number of second requests into a small number of first requests, or takes the initiative of the first queries when this is timely.
  • the geolocation data associated with a particular mobile terminal 1 a, 1 b in the database are quickly obsolete, since the user continues to move. It is therefore necessary to update them regularly, especially if an application operates in tracking mode (and therefore the associated application server 3a, 3b must receive updates at regular intervals).
  • the method thus advantageously comprises a step (e1) of transmitting a new first request, receiving updated geolocation data from the mobile terminal 1a, 1b and updating the database stored on the means. 22.
  • the step (e1) is equivalent to a repetition of the steps (a) to (c), that is to say, the issuance of a new first request.
  • this update is not necessarily a replacement of previously stored data. If the geolocation data is associated with a time parameter, it is possible to create a new entry in the database. In general, this will be the most recent entry for a given unique identifier that will be used (although as explained one can imagine that the knowledge of old geolocation data could be interesting for some applications).
  • Step (e1) can take place before or after step (e).
  • step (d) each time a second request is received (step (d)), the server 2 determines whether an implementation of step (e1) is necessary, according to rules associated with each application server 3a, 3b and parameters such as "age" data. These rules can, for example, define a time threshold beyond which data are considered outdated and must be updated, or a consecutive number of second requests. In other words, at each second request, the server 2 responds directly (no implementation of step (e1)) if it can (the information is there), or goes back to the source if necessary (the information is absent or obsolete). In this embodiment, each possible implementation of step (e1) is interposed between steps (d) and (e).
  • the server 2 has the initiative and can independently of the reception of the second requests update the geolocation data (implementation of the step (e1) after step (e) and before a possible step (d)).
  • a sign wants to be notified when potential customers are near its stores; it is then the server 2 which notifies the application server 3a, 3b when it is the case.
  • he can query the mobile on his own initiative (pull request), when for example the historical data makes him think that such potential customer must be close to such store.
  • the second requests are sent at a given frequency (tracking frequency), in other words the frequency at which the sequence of steps (d) and (e) is repeated for at least one application server. 3a, 3b.
  • the updating frequency can be set by the server 2 and defined as that fixed by the most restrictive application: instead of using rules and / or reacting to each reception of a second request , step (e1) is repeated at a frequency equivalent to the highest frequency among the frequencies at which the sequence of steps (d) and (e) is repeated for an application server 3a, 3b.
  • the actual frequency may alternatively depend on other criteria such as the time or the position of the mobile , according to user-defined access rules (see below).
  • an application A requires a precision of 50 m on the location of the terminal 1 a, 1 b and an application B an accuracy of 500 m
  • the position will be sent with an accuracy of 50 m to ensure the good operation of application A, and the update will be requested as soon as the current position differs by more than 50 m from the last position sent.
  • the different data update modes mentioned above can be implemented in turn or in combination depending on the different application servers 3a, 3b requiring geolocation.
  • the geolocation means 10 never transmit useless updates (ie that can not be exploited by an application) in order to preserve as much as possible the battery of the mobile terminal 1 a, 1 b.
  • the frequency can therefore be continuously optimized by the data processing means 21 of the server 2.
  • the generation of the responses may be a function of other rules associated with the application servers 3a, 3b, these rules being moreover able to be managed at the mobile terminal 1a, 1b by a specific module.
  • this module allows for each application to first define an authorization or not to access the geolocation data. If the authorization is given, the server 2 can transmit to the application server associated with the unique identifier of the terminal 1a, 1b (which makes possible the receipt and processing of requests by the server 2).
  • this module defines the rules, which can be seen generally as management rules, that is to say modulations on the level of access to geolocation data, and on possible additional treatments, to be compared. the rules related to updating the data (step (e1)).
  • a management rule may allow an application to access these data only with a certain temporal and spatial precision, this level of precision being able to be a function of the time and the position of the mobile terminal 1 a, 1 b.
  • the server 2 can then take care of "degrading" the data by adding a hazard to the exact position and the moment at which this position has been recorded.
  • a maximum frequency of the requests of the application can also be defined.
  • step (e) may include the comparison by the data processing means 21 of the server 2 of the associated geolocation data. to the unique identifier in said database with the reference geolocation data, the generated response being a function of the result of said comparison (for example it is a response to "the terminal is less than 100 meters from such a position?").
  • the use of the trusted server 2 thus makes it possible to consider responding directly to complex requests, which facilitates the work of the developers (possibility of "pre-processing" in the server 2, with elaborate answers obtained at the end of step (e), which can be directly used in the applications), while increasing the level of confidentiality (possibility of directly responding to the complex requests of the application servers 3a, 3b without ultimately disclosing the real position of the user ).
  • the software module can be implemented in the operating system of the mobile terminal 1 a, 1 b or as an independent application, which can be activated by the applications using the geolocation data.
  • the management module can play an additional role.
  • a user can indeed call on servers 2 that are active at the same time (with updates for each server) or alternatively: the software module can, by notifying the applications, change server 2 or request a change of identifier unique to enhance the anonymity of the user's data.
  • There may be a default trusted server 2 for example, managed by the OS manufacturer), configurable by the user.
  • the invention also relates to the trusted server 2 for the implementation of the previously described method.
  • This server 2 is therefore connected to at least one mobile terminal 1a, 1b including geolocation means 10 and at least one application server 3a, 3b. It comprises data storage means 22 and data processing means 21.
  • a module for associating said geolocation data in a database stored on the data storage means 22 with a unique identifier itself associated with the mobile terminal 1 a, 1 b (this module also enabling the generation of the unique identifier, and where applicable the update of the geolocation data in the database);
  • a second module for receiving a second geolocation request sent by the application server 3a, 3b, the second request comprising said unique identifier associated with the mobile terminal 1a, 1b; a module for generating and sending to the application server 3a, 3b a response to the second request according to the geolocation data associated with the unique identifier in said database, and rules associated with the application server 3a, 3b .
  • the invention furthermore relates to the system which comprises this server 2, at least one mobile terminal 1a, 1b comprising the geolocation means 10 and at least one application server 3a, 3b.
  • the mobile terminal (s) 1 a, 1 b advantageously implement (via own means of data processing) a management module of the rules associated with each application server 3 a, 3 b (which also optionally allows the activation / disabling access rights to geolocation data for application servers 3a, 3b, and commands related to server 2 such as the possibility of regenerating a unique identifier).
  • a management module of the rules associated with each application server 3 a, 3 b which also optionally allows the activation / disabling access rights to geolocation data for application servers 3a, 3b, and commands related to server 2 such as the possibility of regenerating a unique identifier.
  • the invention relates to a computer program product comprising code instructions for the execution (in particular on the data processing module 21 of the server 2) of a method according to the first aspect. of the invention of data processing of geolocation, as well as storage means readable by a computer equipment (for example a data storage module 22 of the server 2) on which this computer program product is found.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Computer Hardware Design (AREA)
  • Medical Informatics (AREA)
  • Remote Sensing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Abstract

La présente invention concerne un procédé de traitement de données de géolocalisation comprenant la mise en œuvre par des moyens de traitement de données (21) d'un serveur (2) d'étapes de: (a) émission d'une requête de géolocalisation à destination d'un terminal mobile comprenant des moyens de géolocalisation; (b) réception de données de géolocalisation depuis le terminal mobile (1a, 1b); (c) association desdites données de géolocalisation dans une base de données stockée sur des moyens de stockage de données (22) avec un identifiant unique lui-même associé au terminal mobile (1a, 1b); (d) réception d'une requête de géolocalisation émise par un serveur applicatif (3a, 3b), la requête comprenant ledit identifiant unique associé au terminal mobile (1a, 1b); (e) génération et envoi au serveur applicatif (3a, 3b) d'une réponse à la requête en fonction des données de géolocalisation associées à l'identifiant unique dans ladite base de données, et de règles associées au serveur applicatif (3a, 3b).

Description

Procédé de traitement de données de géolocalisation
DOMAINE TECHNIQUE GENERAL La présente invention concerne un procédé de traitement de données de géolocalisation.
ETAT DE L'ART Les terminaux mobiles modernes de type smartphones disposent de capacités de géolocalisation, permettant par exemple la navigation sur une carte, des « check-in », c'est-à-dire la publication de la position d'un utilisateur sur des réseaux sociaux, ainsi que de nombreuses autres fonctionnalités.
Toutefois, l'augmentation importante du nombre d'applications tirant parti de la géolocalisation fait aujourd'hui apparaître deux problèmes.
Tout d'abord, les mécanismes actuels ne permettent pas une gestion fine de la confidentialité des données de géolocalisation. Dans la plupart des cas, l'utilisateur n'a que la possibilité d'accepter ou refuser l'accès complet par l'application aux données de géolocalisation, alors qu'il apparaît qu'il n'est pas nécessaire de toujours divulguer ces données avec la même finesse (précision de la localisation géographique, fréquence de mise à jour, etc.). Par exemple, il existe des applications utilisant la géolocalisation qui ont seulement besoin de savoir si un utilisateur A est à proximité d'un utilisateur B, la connaissance de leur position n'étant pas indispensable. L'envoi d'informations trop détaillées (en particulier si elles contiennent des données permettant de retrouver l'identité de l'utilisateur) crée un risque d'utilisation illicite des données par l'application, voire par un attaquant exploitant une faille de sécurité de l'application.
Ensuite, on constate une consommation énergétique importante des terminaux mobiles liée au traitement et à l'envoi de données de géolocalisation. En effet, chaque application exploite indépendamment les données de géolocalisation dont elle a besoin. Lorsque plusieurs applications utilisant les données de géolocalisation fonctionnent en même temps sur le même mobile, ces données sont susceptibles d'être envoyées plusieurs fois par ce mobile, vers chaque serveur d'application lié à une des applications. Les opérations de traitement et de transmission de données associées consomment de l'énergie inutilement. De nombreuses solutions ont été proposées en particulier pour résoudre le premier problème (celui de confidentialité), par exemple l'utilisation sur le terminal d'un module logiciel supplémentaire de contrôle des données de géolocalisation avant émission, ou l'utilisation d'un serveur « proxy » gérant les autorisations d'accès aux données de géolocalisation, anonymisant les requêtes, et notifiant l'utilisateur si besoin (voir demande de brevet EP 1878283).
Ces solutions ne résolvent toutefois pas le problème de consommation énergétique, et au contraire l'aggravent : le terminal mobile est encore plus sollicité.
Plus récemment, il a été proposé dans la demande internationale WO 2013/002927 une gestion mutualisée des check-in. Dans le procédé décrit, les données de géolocalisation sont transmises à un serveur de confiance, qui renvoie au terminal des données traitées correspondant à différents niveaux de précision associés possible (par exemple, si l'utilisateur se géolocalise dans un aéroport, les différents niveaux peuvent s'étaler du numéro précis de la porte de l'aéroport dans lequel l'utilisateur se trouve, jusqu'à l'indication générale de la région dans laquelle l'aéroport est situé), pour sélection par l'utilisateur et transmission à un ou plusieurs serveurs d'application en vue d'un ou plusieurs check-in.
Ce procédé peut réduire légèrement la consommation dans la mesure où quelques traitements sont déportés.
Toutefois, on constate qu'aujourd'hui, les check-in représentent une faible part de la consommation énergétique à des fins de géolocalisation. En effet, ce sont les mécanismes de « tracking » (pistage en français) qui consomment le plus la batterie du mobile. Le tracking consiste en l'envoi répété (par exemple toutes les trente secondes) de la position de l'utilisateur de sorte à permettre des fonctionnalités dynamiques, par exemple l'envoi d'une notification si l'utilisateur passe à proximité d'une position prédéterminée (un centre d'intérêt, une personne connue, une enseigne, etc.).
Une proposition qui ait été faite pour réduire la consommation d'énergie liée au tracking est la diminution forcée de la fréquence des mises à jour des données de géolocalisation, ce qui peut nuire au fonctionnement de certaines applications.
On connaît également du document US 201 1/0159884 une solution dans laquelle un serveur stockant la position du terminal sert d'interface pour les différents serveurs d'application, le terminal ne transmettant sa position au serveur intermédiaire que s'il bouge de façon significative. Cette solution ne permet donc de réduire la consommation énergétique du terminal qu'en cas de mobilité réduite.
Il serait souhaitable de disposer d'une solution de gestion des données de géolocalisation qui garantisse la confidentialité des données de géolocalisation et permette de réduire sensiblement la consommation énergétique des terminaux, ce sans altérer la qualité du service.
PRESENTATION DE L'INVENTION
La présente invention se rapporte ainsi à un procédé de traitement de données de géolocalisation comprenant la mise en œuvre par des moyens de traitement de données d'un serveur d'étapes de :
(a) émission d'une première requête de géolocalisation à destination d'un terminal mobile comprenant des moyens de géolocalisation ;
(b) réception en réponse de données de géolocalisation depuis le terminal mobile ;
(c) association desdites données de géolocalisation dans une base de données stockée sur des moyens de stockage de données avec un identifiant unique lui-même associé au terminal mobile ;
(d) réception d'une requête de géolocalisation émise par un serveur applicatif, la requête comprenant ledit identifiant unique associé au terminal mobile ;
(e) génération et envoi au serveur applicatif d'une réponse à la requête en fonction des données de géolocalisation associées à l'identifiant unique dans ladite base de données, et de règles associées au serveur applicatif.
L'utilisation d'un serveur de confiance pour répondre aux requêtes envoyées par les serveurs applicatifs permet à la fois de facilement anonymiser les données de géolocalisation et de rationaliser la sollicitation des moyens de géolocalisation des terminaux mobiles : si plusieurs applications requièrent ces données, il suffit de les transmettre une fois au serveur, et c'est ce dernier qui traite les multiples requêtes.
Par ailleurs, ce procédé ne nécessite que la mise en œuvre d'un module léger sur le terminal et facilite le développement de nouvelles applications utilisant la géolocalisation, dans la mesure où il suffit de contacter un unique serveur, celui- ci pouvant gérer des requêtes complexes offrant des fonctionnalités avancées (par exemple, demande de notification si un certain événement se produit). Selon d'autres caractéristiques avantageuses et non limitatives :
• ledit identifiant unique est un identifiant anonyme généré par le terminal mobile et reçu par les moyens de traitement de données du serveur lors de l'étape (a) ;
• ledit identifiant unique est un identifiant anonyme généré à l'étape (b) par les moyens de traitement de données du serveur et envoyé au terminal mobile ;
· ledit identifiant unique est changé à intervalles réguliers ;
• ledit identifiant unique reçu par le terminal mobile est envoyé au serveur applicatif si l'utilisateur autorise le serveur applicatif à accéder à ses données de géolocalisation ;
• les données de géolocalisation sont également associées dans ladite base de données à des données temporelles relatives au moment de leur réception à l'étape (b) ;
• le procédé comprend une étape (e1 ) d'émission d'une nouvelle première requête, de réception de données de géolocalisation actualisées depuis le terminal mobile puis de mise à jour la base de données stockée sur les moyens de stockage de données ;
• le procédé comprend la répétition des étapes (d) et (e), dans lequel l'étape (e1 ) étant mise en œuvre suite à chaque étape (d) si les moyens de traitement de données du serveur déterminent en fonction de règles associées au serveur applicatif ayant émis la deuxième requête que les données de géolocalisation doivent être actualisées ;
• l'enchaînement des étapes (d) et (e) est répété à une fréquence donnée pour au moins un serveur applicatif, l'étape (e1 ) étant répétée à une fréquence fonction des fréquences auxquelles l'enchaînement des étapes (d) et (e) est répété pour un serveur applicatif et/ou d'au moins une règle associée au serveur applicatif ;
· selon une règle associée au serveur applicatif la réponse générée à l'étape (e) comprend une version dégradée des données de géolocalisation associées à l'identifiant unique dans ladite base de données ;
• la deuxième requête reçue à l'étape (d) comprend des données de géolocalisation de référence, selon une règle associée au serveur applicatif l'étape (e) comprend la comparaison des données de géolocalisation associées à l'identifiant unique dans ladite base de données avec les données de géolocalisation de référence, la réponse générée étant fonction du résultat de ladite comparaison.
Selon un deuxième aspect, l'invention concerne un serveur de traitement de données de géolocalisation, connecté à au moins un terminal mobile comprenant des moyens de géolocalisation et à au moins un serveur applicatif, le serveur comprenant des moyens de stockage de données et des moyens de traitement de données configurés pour mettre en œuvre :
un module d'émission d'une première requête de géolocalisation à destination du terminal mobile ;
un premier module de réception de données de géolocalisation depuis le terminal mobile en réponse à la première requête ;
- un module d'association desdites données de géolocalisation dans une base de données stockée sur les moyens de stockage de données avec un identifiant unique lui-même associé au terminal mobile ;
un deuxième module de réception d'une deuxième requête de géolocalisation émise par le serveur applicatif, la deuxième requête comprenant ledit identifiant unique associé au terminal mobile ;
un module de génération et d'envoi au serveur applicatif d'une réponse à la deuxième requête en fonction des données de géolocalisation associées à l'identifiant unique dans ladite base de données, et de règles associées au serveur applicatif.
Selon un troisième aspect, l'invention concerne un système comprenant : au moins un terminal mobile comprenant des moyens de géolocalisation ; au moins un serveur applicatif ;
au moins un serveur selon le deuxième aspect.
Selon d'autres caractéristiques avantageuses et non limitatives :
• le terminal mobile met en œuvre un module de gestion des règles associées à chaque serveur applicatif. Selon un quatrième et un cinquième aspects, l'invention concerne un produit programme d'ordinateur comprenant des instructions de code pour l'exécution d'un procédé selon le premier aspect de l'invention de traitement de données de géolocalisation ; et un moyen de stockage lisible par un équipement informatique sur lequel un produit programme d'ordinateur comprend des instructions de code pour l'exécution d'un procédé selon le premier aspect de l'invention de traitement de données de géolocalisation.
PRESENTATION DES FIGURES
D'autres caractéristiques et avantages de la présente invention apparaîtront à la lecture de la description qui va suivre d'un mode de réalisation préférentiel. Cette description sera donnée en référence à la figure 1 annexée qui représente une architecture pour la mise en œuvre du procédé selon l'invention.
DESCRIPTION DETAILLEE Architecture interne Le présent procédé de traitement de données de géolocalisation est mis en œuvre dans un environnement du type de celui représenté par la figure 1.
Un ou plusieurs terminaux mobiles 1 a, 1 b sont connectés à un réseau de communication 20 (en particulier un réseau de téléphonie mobile). Chaque terminal mobile 1 a, 1 b peut être n'importe quel équipement apte à se connecter au réseau de communication 20. Il peut par exemple d'agir d'un smartphone, d'une tablette tactile, etc.
Chaque terminal mobile 1 a, 1 b comprend des moyens de géolocalisation 10, lesquelles peuvent mettent en œuvre l'une des nombreuses techniques de géolocalisation implémentées sur des terminaux mobiles (GPS, positionnement GSM, RFID, etc.). On comprendra que le précédent procédé n'est limité à aucune façon d'obtenir sur le terminal mobile 1 a, 1 b des données de localisation, et que les moyens 10 peuvent prendre n'importe quelle forme (physique et/ou logicielle).
Un serveur 2 est connecté au réseau de communication 20. Il s'agit d'un serveur « de confiance », notamment un serveur de l'opérateur du réseau 20. Il comprend classiquement un module de traitement de données 21 (un processeur) et un module de stockage de données 22 (par exemple un disque dur).
Ce serveur 2 est lui-même connecté par exemple via le réseau Internet 30 à un ou plusieurs serveurs applicatifs 3a, 3b. Il s'agit de serveurs impliqués dans le fonctionnement d'une application (par exemple un ou plusieurs serveurs d'un réseau social), à l'origine des requêtes de données de géolocalisation émises à destination des terminaux 1 a, 1 b.
Il est à noter qu'il peut y avoir plusieurs serveurs 2, chacun connecté à un ou plusieurs serveurs applicatifs 3a, 3b.
Principe
La Demanderesse a remarqué qu'il est aujourd'hui courant que plusieurs applications utilisent simultanément les données de géolocalisation d'un terminal mobile, a fortiori en mode tracking. Par exemple, il est possible que l'utilisateur soit en train d'utiliser une première application de type « map » affichant une carte sur laquelle la position de l'utilisateur est affichée, pendant qu'en tâche de fond certaines applications, conçues par exemple pour envoyer une notification si l'utilisateur est à proximité d'un ami, d'un restaurant, etc., fonctionne.
Le serveur applicatif de chacune de ces applications « piste » la position de l'utilisateur, c'est-à-dire qu'il requiert (éventuellement à intervalles réguliers) les données de localisation de son terminal mobile 1 a, 1 b.
Si chacune de ces applications a une fréquence donnée de mise à jour des données de géolocalisation, on constate que la fréquence réelle de sollicitation des moyens 10 de géolocalisation est égale à la somme de ces fréquences, d'où l'augmentation conséquente de la consommation énergétique dès que plusieurs tracking sont simultanément actifs.
Or, solliciter autant de fois les moyens 10 de géolocalisation qu'il y a d'applications s'avère inutile. Le présent procédé propose ainsi une façon d'éviter toute redondance dans la gestion des données de géolocalisation, grâce au serveur de confiance 2.
De plus, au lieu de fonctionner dans un mode « push » dans lequel c'est le terminal 1 a, 1 b qui décide quand envoyer des données de géolocalisation au serveur (il « pousse » les données), le présent serveur 2 met en œuvre un mode de fonctionnement dit « pull » dans lequel c'est lui qui demande explicitement la position du terminal quand c'est opportun (le serveur « tire » les données), ce dernier se contentant de répondre. En d'autres termes, on déplace au moins partiellement l'intelligence (en ce qui concerne la gestion de la géolocalisation) du terminal 1 a, 1 b vers le serveur de confiance 2. Dans des méthodes connues du type de celle décrite dans le document US 201 1/0159884, le serveur 2 fonctionne uniquement en mode push.
Cela permet d'améliorer encore l'économie de batterie. Tout d'abord, cela permet de garantir qu'aucune demande de géolocalisation n'est faite pour rien, quand bien même le terminal serait en mouvement. Ensuite, cela permet de nombreuses économies supplémentaires astucieuses. Par exemple, si le serveur 2 sait qu'un terminal devrait se trouver dans une certaine zone (par exemple à l'aide des historiques de position du mobile) mais n'a pas sa position actuelle précise, il peut ne faire une requête pull pour avoir la position exacte du mobile que si un événement intéressant l'utilisateur a lieu dans cette zone (présence d'une personne connue, demande d'information d'un tiers, covoiturage possible, offre commerciale, etc.). La géolocalisation n'est donc demandée qu'à bon escient, à partir d'informations non disponibles pour le terminal 1 a, 1 b, ce qui différencie nettement de la solution push. On optimise ainsi davantage la consommation de la batterie. Et si la position effective du terminal 1 a, 1 b n'est pas celle prévue, ce n'est pas grave, l'information stockée pourra être réutilisée par d'autres applications.
Dans une première étape (a), les moyens de traitement de données 21 du serveur 2 émettent à destination du terminal mobile une première requête de géolocalisation (c'est la requête pull). En réponse, dans une étape (b) ces moyens de traitement de données 21 reçoivent de la part du terminal mobile 1 a, 1 b des données de géolocalisation (obtenues par les moyens de géolocalisation 10). Cet envoi présente la particularité de ne pas être mis en œuvre en réponse à une requête de la part d'une application. Il vise juste à fournir ces données au serveur 2 en vue d'un stockage. Comme l'on verra plus tard, cette première requête peut suivre, ou au contraire précéder, une deuxième requête émanant justement d'un serveur applicatif 3a, 3b.
Dans une étape (c), ces données sont associées dans une base de données stockée sur les moyens de stockage de données 22 du serveur 2, avec un identifiant unique lui-même associé au terminal mobile 1 a, 1 b. De façon préférée, les données de géolocalisation sont également associées dans cette base de données à des données temporelles (typiquement l'heure) relatives au moment de leur réception à l'étape (b).
Ainsi, la base de données du serveur 2 se compose de triplets de type (identifiant, données de géolocalisation, heure). De nombreux terminaux 1 a, 1 b peuvent être gérés au sein d'une seule base de données.
Cet identifiant unique est un identifiant anonyme qui peut être soit généré par les moyens de traitement de données 21 du serveur 2 et envoyé au terminal mobile 1 a, 1 b (lors de l'étape (b)), soit généré par le terminal mobile 1 a, 1 b, lequel envoie directement le couple (identifiant, données) au serveur 2 à l'étape (b). L'identifiant unique permet d'anonymiser les données de géolocalisation en évitant que ces dernières soient référencées via des données permettant d'identifier directement le terminal 1 a, 1 b ou son utilisateur.
Seul le serveur 2 de confiance est éventuellement capable de faire le lien entre un identifiant unique et l'identité réelle de l'utilisateur, ce qui garantit la confidentialité des données de géolocalisation. Dans le cas où c'est le terminal 1 a, 1 b qui génère (et change) l'identifiant, il est possible de faire que le serveur 2 ne soit pas en mesure de lier l'ancien et le nouvel identifiant, puisqu'il reçoit directement un nouveau couple (identifiant, données), qu'il peut interpréter comme représentant un nouveau terminal. Cela augmente la confidentialité, mais il peut être souhaitable de l'éviter si par exemple une application utilise des positions passées du terminal 1 a, 1 b.
Dans tous les cas, pour une sécurité optimale l'identifiant unique peut être changé (c'est-à-dire regénéré par le serveur 2/le terminal 1 a, 1 b) à intervalles réguliers, par exemple toutes les heures.
L'identifiant unique « actuel » du terminal mobile 1 a, 1 b est envoyé au serveur applicatif 3a, 3b (de sorte à ce que ce dernier puisse désigner le terminal 1 a, 1 b) si l'utilisateur autorise le serveur applicatif 3a, 3b à accéder à ses données de géolocalisation. Cette autorisation peut être donnée via un module logiciel mis en œuvre sur le terminal 1 a, 1 b (lequel sera décrit plus en détails plus loin). L'envoi peut être réalisé soit par le terminal 1 a, 1 b, soit par le serveur 2.
Si l'identifiant a été transmis, le serveur 2 peut recevoir dans une étape (d) une deuxième requête de géolocalisation émise par le serveur applicatif 3a, 3b, la deuxième requête comprenant ledit identifiant unique associé au terminal mobile 1 a, 1 b (ainsi que des données supplémentaires qui seront décrites plus loin). Il est à noter que l'étape (d) peut le cas échéant précéder une ou plusieurs des étapes (a) à (c). En effet l'étape (d) et les étapes (a) à (c) sont indépendantes et le serveur 2 ne contrôle pas le moment d'arrivée des deuxièmes requêtes.
Les moyens de traitement de données 21 du serveur 2 vont alors générer et envoyer au serveur applicatif 3a, 3b (dans une étape (e)) une réponse à la deuxième requête en fonction des données de géolocalisation associées à l'identifiant unique dans ladite base de données, et de règles associées au serveur applicatif 3a, 3b.
Les étapes (d) et (e) ont lieu autant de fois que des deuxièmes requêtes sont envoyées au serveur 2. Comme l'on verra plus tard, chaque deuxième requête peut donner lieu ou non à l'actualisation des données de géolocalisation (en d'autres termes l'envoi d'une première requête).
Ainsi dans le présent procédé, c'est le serveur 2 de confiance qui reçoit les deuxièmes requêtes et y répond. Aucune des deuxièmes requêtes n'est transmise au terminal 1 a, 1 b. Ce dernier ne voit que les premières requêtes (qui sont en pratique beaucoup moins nombreuses que les deuxièmes requêtes grâce à l'intelligence du serveur 2) et n'est ainsi pas sollicité outre mesure.
Cela permet :
de garantir la confidentialité puisque d'une part les données sont anonymisées, et d'autre part la réponse générée peut être « dégradée » ou se limiter à certaines informations moins confidentielles si les règles associées le prévoient. Tous les échanges (entre terminaux et serveur de confiance, serveurs applicatifs et serveur de confiance) peuvent par ailleurs être chiffrés pour prévenir toute interception par un équipement tiers, de diminuer sensiblement la consommation énergétique, puisque :
o d'une part un seul envoi de données de géolocalisation par le terminal 1 a, 1 b peut être exploité par une pluralité de serveurs applicatifs 3a, 3b, le coût énergétique de génération d'une réponse par requête étant reporté sur le serveur 2. En d'autres termes, le présent précédé offre un guichet unique aux applications, permettant au terminal mobile 1 a, 1 b de n'envoyer qu'une seule fois sa position géographique, cette information étant disponible pour toutes les applications. La consommation énergétique liée à la géolocalisation devient indépendante du nombre d'applications actives ; o d'autre part le terminal 1 a, 1 b est sollicité au strict minimum grâce au filtrage opéré intelligemment par le serveur qui transforme un grand nombre de secondes requêtes en un petit nombre de premières requêtes, ou prend l'initiative des premières requêtes lorsque cela est opportun.
Mise à jour des données
Les données de géolocalisation associées à un terminal mobile 1 a, 1 b particulier dans la base données sont rapidement obsolètes, puisque l'utilisateur continue à se déplacer. Il est donc nécessaire de les mettre à jour régulièrement, a fortiori si une application fonctionne en mode tracking (et donc que le serveur applicatif 3a, 3b associé doit recevoir des mises à jour à intervalles réguliers).
Le procédé comprend ainsi avantageusement une étape (e1 ) d'émission d'une nouvelle première requête, de réception de données de géolocalisation actualisées depuis le terminal mobile 1 a, 1 b puis de mise à jour de la base de données stockée sur les moyens de stockage de données 22. L'étape (e1 ) équivaut à une répétition des étapes (a) à (c), c'est-à-dire à l'émission d'une nouvelle première requête.
II est à noter que cette mise à jour n'est pas forcément un remplacement des données précédemment stockées. Si les données de géolocalisation sont associées à un paramètre temporel, il est possible de créer une nouvelle entrée dans la base de données. De façon générale, ce sera l'entrée la plus récente pour un identifiant unique donné qui sera utilisée (même si comme expliqué on peut imaginer que la connaissance d'anciennes données de géolocalisations pourrait être intéressante pour certaines applications).
L'étape (e1 ) peut avoir lieu avant ou après l'étape (e).
Dans un premier mode de réalisation, à chaque fois qu'une deuxième requête est reçue (étape (d)), le serveur 2 détermine si une mise en œuvre de l'étape (e1 ) est nécessaire, en fonction de règles associée à chaque serveur applicatif 3a, 3b et de paramètres tels que de « l'âge » des données. Ces règles peuvent par exemple définir un seuil de temps au-delà duquel les données sont considérées comme dépassées et doivent être actualisées, où un nombre consécutif de secondes requêtes. En d'autres termes, à chaque deuxième requête, le serveur 2 répond directement (pas de mise en œuvre de l'étape (e1 )) s'il le peut (l'information est là), ou remonte à la source s'il le faut (l'information est absente ou obsolète). Dans ce mode de réalisation, chaque éventuelle mise en œuvre de l'étape (e1 ) est intercalée entre les étapes (d) et (e).
Dans un deuxième mode de réalisation, le serveur 2 a l'initiative et peut indépendamment des réceptions des deuxièmes requêtes actualiser les données de géolocalisation (mise en œuvre de l'étape (e1 ) après l'étape (e) et avant une éventuelle étape (d)). Par exemple, une enseigne veut être avertie lorsque des clients potentiels sont à proximité de ses magasins ; c'est alors le serveur 2 qui notifie le serveur applicatif 3a, 3b lorsque c'est le cas. Pour cela, il peut interroger les mobiles de sa propre initiative (requête pull), lorsque par exemple l'historique des données lui fait penser que tel client potentiel doit être à proximité de tel magasin.
Dans un cas de tracking, les deuxièmes requêtes sont envoyées à une fréquence donnée (fréquence du tracking), en d'autres termes la fréquence à laquelle l'enchaînement des étapes (d) et (e) est répété pour au moins un serveur applicatif 3a, 3b.
La fréquence de mise à jour peut dans un tel cas être fixée par le serveur 2 et définie comme celle fixée par l'application la plus contraignante : au lieu d'utiliser des règles et/ou de réagir à chaque réception d'une deuxième requête, l'étape (e1 ) est répétée à une fréquence équivalente à la fréquence la plus élevée parmi les fréquences auxquelles l'enchaînement des étapes (d) et (e) est répété pour un serveur applicatif 3a, 3b.
En l'absence d'applications en mode tracking (en d'autres termes d'applications imposant une fréquence donnée de mise à jour), la fréquence effective peut alternativement dépendre d'autres critères tels que l'heure ou de la position du mobile, selon les règles d'accès définies par l'utilisateur (voir ci-après).
A titre d'exemple, si une application A demande une précision de 50 m sur la localisation du terminal 1 a, 1 b et une application B une précision de 500 m, la position sera envoyée avec une précision de 50 m pour assurer le bon fonctionnement de l'application A, et la mise à jour sera demandée dès que la position actuelle diffère de plus de 50 m de la dernière position envoyée.
Il est à noter que les différents modes de mise à jour des données mentionnés ci-dessus peuvent être mis en œuvre à tour de rôle ou en combinaison en fonction des différents serveurs applicatifs 3a, 3b requérant la géolocalisation. De façon générale, on comprendra que les moyens de géolocalisation 10 ne transmettent jamais de mise à jour inutile (c'est-à-dire ne pouvant être exploitée par une application) afin de préserver au maximum la batterie du terminal mobile 1 a, 1 b. La fréquence peut donc être optimisée en permanence par les moyens de traitement de données 21 du serveur 2.
Règles et module de gestion
La génération des réponses peut être fonction d'autres règles associées aux serveurs applicatifs 3a, 3b, ces règles pouvant être par ailleurs gérées au niveau du terminal mobile 1 a, 1 b par un module spécifique.
Comme expliqué précédemment, ce module permet pour chaque application de tout d'abord définir une autorisation ou non d'accéder aux données de géolocalisation. Si l'autorisation est donnée, le serveur 2 peut transmettre au serveur applicatif associé l'identifiant unique du terminal 1 a, 1 b (ce qui rend possible la réception et le traitement de requêtes par le serveur 2).
Ensuite, ce module définit les règles, qui peuvent être vues de façon générale comme des règles de gestion, c'est-à-dire des modulations sur le niveau d'accès aux données de géolocalisation, et sur des éventuels traitements supplémentaires, à comparer aux règles liées à la mise à jour des données (étape (e1 )).
Par exemple, une règle de gestion peut autoriser une application à n'accéder à ces données qu'avec une certaine précision temporelle et spatiale, ce niveau de précision pouvant être fonction de l'heure et de la position du terminal mobile 1 a, 1 b. Le serveur 2 peut alors se charger de « dégrader » les données en ajoutant un aléa sur la position exacte et l'instant auquel cette position a été enregistrée. Une fréquence maximale des requêtes de l'application peut également être définie.
Par ailleurs, des règles peuvent prévoir la possibilité de répondre à une seconde requête autrement qu'en transmettant des données de géolocalisation. Par exemple, en prévoyant que la requête reçue à l'étape (d) comprenne des données de géolocalisation de référence, l'étape (e) peut comprendre la comparaison par les moyens de traitement de données 21 du serveur 2 des données de géolocalisation associées à l'identifiant unique dans ladite base de données avec les données de géolocalisation de référence, la réponse générée étant fonction du résultat de ladite comparaison (il s'agit par exemple d'une réponse à « le terminal est-il à moins de 100 mètres de telle positon ? »).
L'utilisation du serveur de confiance 2 permet ainsi d'envisager de répondre directement à des requêtes complexes, ce qui facilite le travail des développeurs (possibilité de « pré-traitements » dans le serveur 2, avec des réponses élaborées obtenues à l'issue de l'étape (e), lesquelles peuvent être directement utilisées dans les applications), tout en augmentant le niveau de confidentialité (possibilité de directement répondre aux requêtes complexes des serveurs applicatifs 3a, 3b sans au final divulguer la position réelle de l'utilisateur).
Le module logiciel peut être implanté dans le système d'exploitation du terminal mobile 1 a, 1 b ou comme une application indépendante, activable par les applications utilisant les données de géolocalisation.
S'il y a plusieurs serveurs 2 de confiance, le module de gestion peut jouer un rôle supplémentaire. Un utilisateur peut en effet faire appel à des serveurs 2 soit actifs en même temps (avec des mises à jour pour chaque serveur) soit alternativement : le module logiciel peut, en notifiant les applications, changer de serveur 2 ou demander un changement d'identifiant unique pour renforcer l'anonymat des données de l'utilisateur. Il peut y avoir un serveur 2 de confiance par défaut (par exemple, géré par le fabricant du système d'exploitation), configurable par l'utilisateur.
Il est à noter que des protocoles standards existent pour transmettre des données de géolocalisation et les règles d'accès à ces données (voir par exemple le groupe GEOPRIV de l'IETF), le présent procédé ne sera limité à aucun d'entre eux.
Serveur
L'invention concerne également le serveur 2 de confiance pour la mise en œuvre du procédé précédemment décrit.
Ce serveur 2 est donc connecté à au moins un terminal mobile 1 a, 1 b comprenant des moyens de géolocalisation 10 et à au moins un serveur applicatif 3a, 3b. Il comprend des moyens de stockage de données 22 et des moyens de traitement de données 21 .
Ces derniers sont configurés pour mettre en œuvre : un module d'émission d'une première requête de géolocalisation à destination du terminal mobile 1 a, 1 b ;
un premier module de réception de données de géolocalisation depuis le terminal mobile 1 a, 1 b en réponse à la première requête ;
- un module d'association desdites données de géolocalisation dans une base de données stockée sur les moyens de stockage de données 22 avec un identifiant unique lui-même associé au terminal mobile 1 a, 1 b (ce module permettant également la génération de l'identifiant unique, et le cas échéant la mise à jour des données de géolocalisation dans la base de données) ;
un deuxième module de réception d'une deuxième requête de géolocalisation émise par le serveur applicatif 3a, 3b, la deuxième requête comprenant ledit identifiant unique associé au terminal mobile 1 a, 1 b ; un module de génération et d'envoi au serveur applicatif 3a, 3b d'une réponse à la deuxième requête en fonction des données de géolocalisation associées à l'identifiant unique dans ladite base de données, et de règles associées au serveur applicatif 3a, 3b.
L'invention concerne par ailleurs le système qui comprend ce serveur 2, au moins un terminal mobile 1 a, 1 b comprenant les moyens de géolocalisation 10 et au moins un serveur applicatif 3a, 3b.
Comme expliqué, le ou les terminaux mobiles 1 a, 1 b mettent avantageusement en œuvre (via des moyens propres de traitement de données) un module de gestion des règles associées à chaque serveur applicatif 3a, 3b (lequel permet également éventuellement l'activation/désactivation des droits d'accès aux données de géolocalisation pour les serveurs applicatifs 3a, 3b, et des commandes liées au serveur 2 telles que la possibilité de regénérer un identifiant unique). Produit programme d'ordinateur
Selon un quatrième et un cinquième aspects, l'invention concerne un produit programme d'ordinateur comprenant des instructions de code pour l'exécution (en particulier sur le module de traitement de données 21 du serveur 2) d'un procédé selon le premier aspect de l'invention de traitement de données de géolocalisation, ainsi que des moyens de stockage lisibles par un équipement informatique (par exemple un module de stockage de données 22 du serveur 2) sur lequel on trouve ce produit programme d'ordinateur.

Claims

REVENDICATIONS
1. Procédé de traitement de données de géolocalisation comprenant la mise en œuvre par des moyens de traitement de données (21 ) d'un serveur (2) d'étapes de :
(a) émission d'une première requête de géolocalisation à destination d'un terminal mobile (1 a, 1 b) comprenant des moyens de géolocalisation (10) ;
(b) réception en réponse de données de géolocalisation depuis le terminal mobile (1 a, 1 b) ;
(c) association desdites données de géolocalisation dans une base de données stockée sur des moyens de stockage de données (22) avec un identifiant unique lui-même associé au terminal mobile (1 a, 1 b) ;
(d) réception d'une deuxième requête de géolocalisation émise par un serveur applicatif (3a, 3b), la deuxième requête comprenant ledit identifiant unique associé au terminal mobile (1 a, 1 b) ;
(e) génération et envoi au serveur applicatif (3a, 3b) d'une réponse à la deuxième requête en fonction des données de géolocalisation associées à l'identifiant unique dans ladite base de données, et de règles associées au serveur applicatif (3a, 3b).
2. Procédé selon la revendication 1 , dans lequel ledit identifiant unique est un identifiant anonyme généré par le terminal mobile (1 a, 1 b) et reçu par les moyens de traitement de données (21 ) du serveur (2) lors de l'étape (a).
3. Procédé selon la revendication 1 , dans lequel ledit identifiant unique est un identifiant anonyme généré à l'étape (b) par les moyens de traitement de données (21 ) du serveur (2) et envoyé au terminal mobile (1 a, 1 b).
4. Procédé selon l'une des revendications 2 et 3, dans lequel ledit identifiant unique est changé à intervalles réguliers.
5. Procédé selon l'une des revendications 2 à 4, dans lequel ledit identifiant unique reçu par le terminal mobile (1 a, 1 b) est envoyé au serveur applicatif (3a, 3b) si l'utilisateur autorise le serveur applicatif (3a, 3b) à accéder à ses données de géolocalisation.
6. Procédé selon l'une des revendications 1 à 5, dans lequel les données de géolocalisation sont également associées dans ladite base de données à des données temporelles relatives au moment de leur réception à l'étape (b).
7. Procédé selon l'une des revendications 1 à 6, comprenant une étape (e1 ) d'émission d'une nouvelle première requête, de réception de données de géolocalisation actualisées depuis le terminal mobile (1 a, 1 b) puis de mise à jour la base de données stockée sur les moyens de stockage de données (22).
8. Procédé selon la revendication 7, comprenant la répétition des étapes (d) et (e), dans lequel l'étape (e1 ) étant mise en œuvre suite à chaque étape (d) si les moyens de traitement de données (21 ) du serveur (2) déterminent en fonction de règles associées au serveur applicatif (3a, 3b) ayant émis la deuxième requête que les données de géolocalisation doivent être actualisées.
9. Procédé selon la revendication 7, dans lequel l'enchaînement des étapes (d) et (e) est répété à une fréquence donnée pour au moins un serveur applicatif (3a, 3b), l'étape (e1 ) étant répété à une fréquence fonction des fréquences auxquelles l'enchaînement des étapes (c) et (d) est répété pour un serveur applicatif (3a, 3b) et/ou d'au moins une règle associée au serveur applicatif (3a, 3b).
10. Procédé selon l'une des revendications 1 à 9, dans lequel selon une règle associée au serveur applicatif (3a, 3b) la réponse générée à l'étape (e) comprend une version dégradée des données de géolocalisation associées à l'identifiant unique dans ladite base de données.
11. Procédé selon l'une des revendications 1 à 10, dans lequel la deuxième requête reçue à l'étape (d) comprend des données de géolocalisation de référence, selon une règle associée au serveur applicatif (3a, 3b) l'étape (e) comprenant la comparaison des données de géolocalisation associées à l'identifiant unique dans ladite base de données avec les données de géolocalisation de référence, la réponse générée étant fonction du résultat de ladite comparaison.
12. Serveur (2) de traitement de données de géolocalisation, connecté à au moins un terminal mobile (1 a, 1 b) comprenant des moyens de géolocalisation (10) et à au moins un serveur applicatif (3a, 3b), le serveur comprenant des moyens de stockage de données (22) et des moyens de traitement de données (21 ) configuré pour mettre en œuvre :
un module d'émission d'une première requête de géolocalisation à destination du terminal mobile (1 a, 1 b) ;
un premier module de réception de données de géolocalisation depuis le terminal mobile (1 a, 1 b) en réponse à la première requête ;
- un module d'association desdites données de géolocalisation dans une base de données stockée sur les moyens de stockage de données (22) avec un identifiant unique lui-même associé au terminal mobile (1 a, 1 b) ; un deuxième module de réception d'une deuxième requête de géolocalisation émise par le serveur applicatif (3a, 3b), la deuxième requête comprenant ledit identifiant unique associé au terminal mobile (1 a, 1 b) ; un module de génération et d'envoi au serveur applicatif (3a, 3b) d'une réponse à la deuxième requête en fonction des données de géolocalisation associées à l'identifiant unique dans ladite base de données, et de règles associées au serveur applicatif (3a, 3b).
13. Système comprenant :
au moins un terminal mobile (1 a, 1 b) comprenant des moyens de géolocalisation (10) ;
- au moins un serveur applicatif (3a, 3b) ;
au moins un serveur selon la revendication 1 1 .
14. Système selon la revendication 13, dans lequel le terminal mobile (1 a, 1 b) met en œuvre un module de gestion des règles associées à chaque serveur applicatif (3a, 3b).
15. Produit programme d'ordinateur comprenant des instructions de code pour l'exécution d'un procédé selon l'une des revendications 1 à 1 1 de traitement de données de géolocalisation, lorsque le programme est exécuté par un ordinateur.
16. Moyen de stockage lisible par un équipement informatique sur lequel un produit programme d'ordinateur comprend des instructions de code pour l'exécution d'un procédé selon l'une des revendications 1 à 1 1 de traitement de données de géolocalisation.
EP14744556.3A 2013-07-26 2014-07-28 Procédé de traitement de données de géolocalisation Withdrawn EP3025481A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1357423A FR3009159B1 (fr) 2013-07-26 2013-07-26 Procede de traitement de donnees de geolocalisation
PCT/EP2014/066206 WO2015011296A2 (fr) 2013-07-26 2014-07-28 Procédé de traitement de données de géolocalisation

Publications (1)

Publication Number Publication Date
EP3025481A2 true EP3025481A2 (fr) 2016-06-01

Family

ID=50137724

Family Applications (1)

Application Number Title Priority Date Filing Date
EP14744556.3A Withdrawn EP3025481A2 (fr) 2013-07-26 2014-07-28 Procédé de traitement de données de géolocalisation

Country Status (4)

Country Link
US (1) US20160162706A1 (fr)
EP (1) EP3025481A2 (fr)
FR (1) FR3009159B1 (fr)
WO (1) WO2015011296A2 (fr)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8560604B2 (en) 2009-10-08 2013-10-15 Hola Networks Ltd. System and method for providing faster and more efficient data communication
US9241044B2 (en) 2013-08-28 2016-01-19 Hola Networks, Ltd. System and method for improving internet communication by using intermediate nodes
US9824515B2 (en) 2015-03-24 2017-11-21 At&T Intellectual Property I, L.P. Automatic calendric physical access
US9972144B2 (en) 2015-03-24 2018-05-15 At&T Intellectual Property I, L.P. Automatic physical access
US9582841B2 (en) * 2015-03-24 2017-02-28 At&T Intellectual Property I, L.P. Location based emergency management plans
US10296851B2 (en) 2015-04-11 2019-05-21 At&T Intellectual Property I, L.P. Automatic allocation of physical facilities for maximum collaboration
US11057446B2 (en) 2015-05-14 2021-07-06 Bright Data Ltd. System and method for streaming content from multiple servers
LT3805958T (lt) 2017-08-28 2024-03-12 Bright Data Ltd. Būdas pagerinti turinio parsisiuntimą, pasirenkant tunelinius įrenginius
CN109696867A (zh) * 2018-12-26 2019-04-30 上海司南卫星导航技术股份有限公司 用户终端处理gnss设备数据的方法、用户终端和gnss设备管理系统
LT3780557T (lt) 2019-02-25 2023-03-10 Bright Data Ltd. Turinio parsisiuntimo, naudojant url bandymų mechanizmą, sistema ir būdas
WO2020202135A2 (fr) 2019-04-02 2020-10-08 Luminati Networks Ltd. Système et procédé de gestion d'un service d'extraction non directe d'url
US11270019B2 (en) * 2019-10-04 2022-03-08 X Development Llc Processing data and programs with mutual security to the data and programs
CN112669480B (zh) * 2020-12-08 2023-04-18 安徽鸿程光电有限公司 数据处理方法、装置、终端设备及存储介质

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020169539A1 (en) * 2001-03-28 2002-11-14 Menard Raymond J. Method and system for wireless tracking
US7023995B2 (en) * 2000-12-08 2006-04-04 Telefonaktiebolaget L M Ericsson (Publ) Secure location-based services system and method
US7472423B2 (en) * 2002-03-27 2008-12-30 Tvworks, Llc Method and apparatus for anonymously tracking TV and internet usage
US8023958B2 (en) * 2003-03-05 2011-09-20 Qualcomm Incorporated User plane-based location services (LCS) system, method and apparatus
US7559081B2 (en) * 2003-09-18 2009-07-07 Alcatel-Lucent Usa Inc. Method and apparatus for authenticating a user at an access terminal
DE102004038588A1 (de) * 2004-08-06 2006-03-16 Deutsche Telekom Ag Verfahren zum Bereitstellen von Diensten verschiedener Diensteanbieter und zentrale, rechnerbasierte Plattform zur Durchführung eines solchen Verfahrens
CA2620617A1 (fr) * 2006-10-20 2008-04-20 T-Mobile Usa, Inc. Systeme et methode permettant d'utiliser des donnees d'emplacement de client de telecommunications sans fil a base d'ip
US8489111B2 (en) * 2007-08-14 2013-07-16 Mpanion, Inc. Real-time location and presence using a push-location client and server
US8595327B2 (en) * 2009-04-10 2013-11-26 Microsoft Corporation Obtaining instrumentation data
US8930438B2 (en) * 2009-06-17 2015-01-06 Apple Inc. Push-based location update
US8229461B1 (en) * 2009-11-18 2012-07-24 Nextel Communications, Inc. System and method for operating a location server
US20110153525A1 (en) * 2009-12-18 2011-06-23 Alcatel-Lucent Usa Inc. Method and system for managing power consumption using geolocation information
US8689277B2 (en) * 2010-01-13 2014-04-01 Andrew Llc Method and system for providing location of target device using stateless user information
US20130124628A1 (en) * 2011-11-15 2013-05-16 Srilal Weerasinghe Method and apparatus for providing social network based advertising with user control and privacy
US9131462B1 (en) * 2012-02-14 2015-09-08 Google Inc. Determining a geographic location of a mobile device

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Functional stage 2 description of Location Services (LCS) (Release 9)", 3GPP STANDARD ; TECHNICAL SPECIFICATION ; 3GPP TS 23.271, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. SA WG2, no. V9.8.0, 5 March 2013 (2013-03-05), pages 1 - 168, XP051297347 *

Also Published As

Publication number Publication date
WO2015011296A3 (fr) 2015-06-18
FR3009159A1 (fr) 2015-01-30
WO2015011296A2 (fr) 2015-01-29
FR3009159B1 (fr) 2017-06-23
US20160162706A1 (en) 2016-06-09

Similar Documents

Publication Publication Date Title
WO2015011296A2 (fr) Procédé de traitement de données de géolocalisation
EP2415294B1 (fr) Procédé et dispositif de gestion d'une authentification d'un utilisateur
WO2013001230A1 (fr) D'obtention par un terminal d'une information relative a un acces a un service
FR2932048A1 (fr) Procede et systeme d'acces par un utilisateur a au moins un service offert par au moins un autre utilisateur.
EP2360889B1 (fr) Création et utilisation d'un lien de télécommunication entre deux utilisateurs d'un réseau de télécommunication
EP2979435B1 (fr) Procédé de traitement de donnés d'utilisateur d'un réseau social
FR2889388A1 (fr) Procede et systeme de gestion securise de donnees entre un serveur et un client
WO2018193201A1 (fr) Procédés pour le partage de données de localisation entre un dispositif source d'un utilisateur et un dispositif destinataire d'un tiers, serveur, dispositif source d'un utilisateur, dispositif destinataire d'un tiers et programme d'ordinateur correspondants
FR2863810A1 (fr) Procede et systeme de coordination de services de telecommunication
EP2797284B1 (fr) Procédés et systèmes pour l'accès contrôlé à des données stockées dans un réseau
EP2489155A1 (fr) Gestion de dispositif de communication a travers un reseau de telecommunications
WO2015181462A1 (fr) Procédé de synchronisation de données entre différents équipements par l'intermédiaire d'un serveur
WO2024188822A1 (fr) Procédé et dispositif de paiement confidentiel sur chaîne de blocs
EP3888333B1 (fr) Activation ou désactivation d'un sous-ensemble virtuel d'un réseau dédié à un service pour un terminal
EP4335145A1 (fr) Procédé d'enregistrement d'un terminal utilisateur auprès d'un réseau de communications organise en tranches de réseau
WO2021156664A1 (fr) Plateforme de gestion des preferences en matiere de donnees personnelles
EP2979234A1 (fr) Acces a un sous-ensemble d'informations relatives a un utilisateur
FR3019437A1 (fr) Technique de gestion d'un etat d'activation d'un reseau d'acces radio dans un reseau local
WO2014080131A1 (fr) Service de communication voix a partir d'un reseau social
EP2856780A1 (fr) Procede et systeme de reglage spatio-temporel des permissions de geolocalisation
EP2464068B1 (fr) Système de gestion globale de filtrage personnalisé basé sur un circuit d'échange d'informations sécurisé et procédé associé
FR3124341A1 (fr) Procédé et ensemble permettant à des terminaux utilisateurs d’échanger en toute confidentialité des données personnelles avec une plateforme de serveurs
FR3077458A1 (fr) Procede d'agregation d'une pluralite de connexions radio dans un reseau sans fil
FR3025391A1 (fr) Procede et systeme de gestion de l’appairage d’elements communicants
WO2006092505A1 (fr) Procede et dispositif de mise en relation automatique de terminaux proches

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20160127

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: INSTITUT MINES-TELECOM

17Q First examination report despatched

Effective date: 20170925

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20181122