WO2002078378A1

WO2002078378A1 - Location data monitoring system for devices that can be geolocated

Info

Publication number: WO2002078378A1
Application number: PCT/FR2002/000972
Authority: WO
Inventors: Wojciech Makowski
Original assignee: Alternis
Priority date: 2001-03-22
Filing date: 2002-03-20
Publication date: 2002-10-03
Also published as: FR2822629B1; FR2822629A1

Abstract

The invention relates to a location memory unit (18) containing records, each of which comprises location data for a respective device that can be geolocated, said data being delivered by a location data source (3) accompanied by a quality indicator. The quality of positioning is estimated for a device concerned by a location data request, and for which the location memory unit contains a record, on the basis of parameters including the quality indicator included in the record. The estimated quality of positioning for the device is compared to a quality of positioning objective defined for the request, so that the request can be answered using the record relating to the device if the estimated quality is satisfactory in relation to the objective or, if not, by querying a location data source (3).

Description

SYSTEM FOR MONITORING LOCATION DATA OF GEOLOCABLE DEVICES

The present invention relates to techniques used to supervise the supply of location data of a set of geolocatable devices for the exploitation of such data by user applications.

The term “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 (in this case the device is in the so-called “passive” mode). On the other hand, for its own needs and without any external demand, the cellular network maintains information on the approximate current position of all the connected devices (even those which are in passive mode). However, this information is not very precise and the "localization zone" thus maintained by the cellular network usually covers several cells.

The cellular network infrastructure can also employ known localization methods having a finer spatial resolution than that of cells. In some cases, it can also estimate the speed of movement of cellular radiotelephones. Various other types of geolocatable devices can be concerned by the invention, for example personal digital assistants (PDAs) or tracking devices, etc. A tracking device consists, for example, of a cellular radio communication terminal degraded to allow its location as indicated above, but not the establishment of communications.

Due in particular to the success of digital radiocommunication systems, a number of services are developing using location data from geolocatable devices. If we extrapolate this development, the amount of data exchanged between user applications and remote sources of location data between is virtually enormous, which risks slowing down excessively or even blocking the supply of the required data. In addition, obtaining the data from a location server requires operations which generally represent a cost. For example, in the case of a cellular operator, the location of a terminal typically requires a signaling charge for paging, unwelcome if the network is already sufficiently charged. It is therefore advisable to dispense with interrogating the location server when this is not essential.

An object of the present invention is to propose a technique making it possible to optimize the processing of requests for location data as well as the communications between the user applications and the sources of location data, in order to promote the development of various services using such data.

The invention thus proposes a system for supervising the location data of geolocatable devices comprising means for processing requests for location data. According to the invention, these processing means include: - a location memory for containing records each comprising location data from a respective geolocation device delivered by a location data source, accompanied by an indication of quality; calculation means for estimating a positioning quality of a geolocalizable device concerned by a request for location data and for which the location memory contains a record, on the basis of parameters including the quality indication included in said record ; means of comparison between the positioning quality of a geolocalizable device concerned by a request, estimated by the calculation means, and a positioning quality objective defined for said request, in order to respond to the request from the recording relating to the device if the estimated quality is sufficient in relation to the objective and by interrogating a source of location data otherwise.

This system acts as an intermediary between one or more applications using location data and one or more sources or location servers capable of providing this data. The system may belong, in whole or in part, to the same system as a location data source. Sources can also be external. In the latter case, the system can be linked to several location servers corresponding for example to different cellular operators, so that it presents itself, for user applications, as a one-stop shop where the required location data can be obtained. .

The system can also belong, in whole or in part, to the same system as one or more user applications. It then serves simply to optimize the interrogations sent to the location server or servers.

The system itself delivers location data when it considers that it is able to do so by extrapolation from data previously supplied by a location data source. The sufficiently precise nature of this extrapolation is evaluated by comparison of the estimated positioning quality with a target defined for the request. This objective can be a parameter specified in the request, or a default parameter, depending or not on the application making the request. For some requests, it is possible to define a maximum quality objective (such requests will always give rise to a query from a location data source).

These provisions reduce the load on the location servers, as well as the communication traffic with these servers if they are remote from the system. The advantage is particularly important when several user applications are likely to contact the system to be informed of the location of the same device. Each application can then take advantage of queries from the location servers carried out to process requests from other applications. A recording of the location memory can also include, with the location data of a geolocatable device, time stamping information of this location data. The parameters on the basis of which the positioning quality of this device is estimated then advantageously include the current time and said time stamping information, in order to extrapolate the quality. These data can be enriched by an indication of a speed of movement of the device, in particular an estimate of the absolute value and / or of the direction of this speed of movement.

For a given record of the location memory, the estimation of the positioning quality can in certain cases be carried out by the calculation means on the sole basis of the quality indication included in said record. Such a recording typically includes a connection status indicator of the geolocalizable device, and the estimation is only carried out on the basis of the quality indication if said indicator is representative of a connected state.

These provisions are well suited to the case where the location of geolocatable devices is obtained via a cellular network. One or more sources of location data can then provide information on the "location area" and / or on the connection status (connected or not connected to a cellular network) of the devices. In particular, this supply to the system can be carried out at each change of location area (procedure for updating the location in the cellular network) and at each change in the connection state. It should be noted that unlike more precise localization (at least at the cell scale), obtaining this information does not require any additional radio or signaling load in the cellular network. It is therefore optimal in terms of radio load and signaling in the network. In a way, this approximate location can be considered as Free.

It should be noted that certain user applications may not need explicit location data from geolocatable devices, but only to be informed of certain events (for example the movement of a device outside a determined area, the approximation of two geolocation devices at a distance below a certain threshold, etc.).

For this, a supervision system according to the invention advantageously comprises an interface for communication with at least one application using location data, and means for detecting events by analyzing location data from at least one geolocalizable device, in particular data supplied by the request processing means, for signaling the events detected to at least one user application via said communication interface. The system thus implements software components which operate on the basis of the location data supplied by the request processing means. Depending on the requirements, the detection means can themselves generate some of the requests for location data addressed to the processing means. They can also take advantage of the responses provided by the processing means to other requests, formulated by other components or even directly by external applications.

Some of the software components can be predefined, that is to say comprise a predetermined portion of code and parameters advantageously modifiable, through the communication interface, by the user applications for which they are executed. This allows for example to specify a geographic area from which a device must exit (or into which it must enter) for an alarm to be triggered towards an application.

There may also be dynamic software components. Such a dynamic component has at least a portion of code downloaded by the user application for which it is executed, which offers great flexibility to applications for taking into account various situations based on location data. Other features and advantages of the present invention will appear in the following description of nonlimiting exemplary embodiments, with reference to the appended drawings, in which:

- Figure 1 is a block diagram of a location data supervision system according to the invention;

- Figures 2 to 5 are diagrams illustrating examples of spatial transformations taken into account in the system of Figure 1; and

FIG. 6 is a flow diagram of an example of request processing implemented in the system of FIG. 1.

The supervision system 1 represented in FIG. 1, hereinafter called location data distribution optimizer or LDDO

("Location Data Distribution Optimizer"), includes interface modules

12, 13, 15 which allow it to communicate with three types of entity, namely:

- applications 2 implementing services using directly or indirectly location data from geolocatable devices (module 12);

- location servers 3 capable of delivering location data to the devices concerned (module 13). 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. A server for monitoring and filtering signaling messages from the cellular network, capable of delivering information on the location areas and on the connection status of the geolocatable devices is a particular case of location server;

- one or more external servers 5 from which the system 1 can obtain possibly relevant information (module 15). An example of such an external server 5 is a traffic information server. To communicate with applications 2 and servers 3, the modules interface 12 and 13 support for example the application programming interface (API) called "Mobile Location Query", specified in a LIF standard.

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. These requests are processed by a location data management module 16 in relation to records present in a location memory 18. The interface 13 likewise transmits standard requests for location data, generated by the module 16, to the or the location servers relevant to the device (s) concerned. A location server 3 can also spontaneously deliver the information on the change of location area and / or connection state of the geolocatable devices to the interface 13, as these changes occur. The responses provided by the module 16 using the location servers 3 are transmitted to the user application 2 via the interface 12.

The system 1 also comprises a module 17 for managing software components that are programmable and / or configurable by the applications 2, the role of which is to detect particular events on the basis of the location data obtained by the module 16 and to report them to the applications in question. For exchanges between the applications 2 and the module 17, the interface module 12 supports, for example, the HTTP protocol (“HyperText Transfer Protocol”) conveying XML pages (“eXtended Markup Language”) in a manner known per se.

The “Mobile Location Query” API can also be used between modules 16 and 17, which allows the component management module 17 to formulate standard requests (such as an external application 2) when necessary to detect the required events. and retrieve the responses produced by the location data management module 16.

Even if they support the same API, the interface modules 12 and 13 are advantageously connected to two separate local networks, for example of the TCP / IP (“Transmission Control Protocol / Internet Protocol”) type. This allows the system 1 to physically separate the user applications 2 from the location servers 3, thus playing a firewall role. By way of example, another local network of the TCP / IP type can be used for the links of the component management module 17 with the external server (s) 5 via the interface module 15.

By way of illustration, the LDDO 1 can be produced from two RS 6000 type platforms sold by the company IBM, one including the location data management module 16 and the associated memory 18, the interface 13 and the API "Mobile Location Query" of interface 12, and the other including the component management module 17, interface 15, the XML / HTTP part of interface 12 as well as a module system administration (not shown in Figure 1). These two platforms can communicate with each other via the same local network as that providing the links of module 17 with the external server (s) 5. The two platforms are provided with programs, for example developed in C / C ++, for the execution of procedures such as those described below.

A recording of the location memory 18 relating to a given geolocation device comprises the following elements, coded in an appropriate form: - an identifier of the geolocation device, for example a call number or a subscriber or equipment identity in the case where the device is a cellular radiocommunication terminal;

the most recent location data which have been supplied by a location server 3 for the device, which may in particular be in the form of a pair of Cartesian coordinates x, y or of longitude / latitude;

an indication, hereinafter noted OQoP (“Original Quality of Positioning”) representing an original quality of positioning of the device, that is to say the accuracy of the location data contained in the recording. This indication is for example quantified by means of a distance representing a margin of error on the location; timestamping information of the location data contained in the recording, representing the instant T (date and time) when these data were obtained;

- possibly an indication of speed v, which can be scalar (absolute value) or vectorial (absolute value and direction). This speed indication can be provided with the location data by the location server 3 if the latter performs speed measurements. It can also be estimated by the module 16 by observing the evolution of the time-stamped location data sets successively supplied by the location server 3

- possibly an indication of the current location area of the device, coupled to the device connection status indicator (connected / not connected).

At each instant t = T + Δt, the module 16 is capable of estimating a positioning quality (QoP) of a device subject to a time-stamped recording T in the memory 18 (Δt> 0). To do this, it applies a function f of several variables:

QoP = f (OQoP, Δt, v, z) (1) where z represents one or more additional optional parameters, describing for example topological constraints in a geographic environment of the place defined by the location data of the recording.

In practice, the zones in which the servers 3 are capable of locating the devices (“QoP zones”) are relatively simple in shape, for example circle, ellipse, sector or arc of a circle, polygon, etc. The set of possible shapes can be defined for each positioning technology. The transformation function f can then be selected from a set of predefined functions adapted to specific forms of the QoP zone.

If the direction of the speed vector is taken into account, the location of the device is also updated and not only the shape of its QoP zone, by translating the previous location proportionally to the vector v.

By way of illustration, FIGS. 2 to 5 show examples of transformations which can be applied in the case of a circular QoP area produced by the server 3. This circle has the radius r ₀ (quantification of the OQoP) in Figures 2 to 5.

In the case of FIG. 2, only the absolute value I v I of the speed v is taken into account in formula (1) in addition to the parameters OQoP = g (r ₀ ) and

.Delta.t. With a decreasing function g, the expression of the function f is:

QoP = f (OQoP, Δt, I v I) = g (r) = g (r ₀ + Δt. (I v I + IV _j I)) (2) where IV _j I is a predefined inflation rate expressing the degradation of the

Zero speed QoP. In the case of figure 3, the direction of the speed v is taken into account in the formula (1), so that the zone of QoP is elliptical, the QoP being determined by two quantities r _x , r _y respectively equal to the half major axis and half minor axis of the ellipse. For OQoP, r _x = r _y = r ₀ . The expression for the function f is: QoP = f (OQoP, Δt, v) = g (r _x , r _y )

= g (r ₀ + α.Δt. (I v I + | _Vj I), r ₀ + β.Δt. (I v I + IV _j |)) (3) where α and β are coefficients depending on the direction of the speed v and expressing the probabilities of orientation of the speed along the two axes of the ellipse. The estimated location of the device also changes: the center of the OQoP circle is translated along the major axis of the ellipse by the quantity Δx = γ.lv I .Δt, the coefficient γ expressing the probability of displacement along the major axis of l 'ellipse.

The transformation can be enriched by taking into account topological constraints around the location area of the device, described by the parameters z in formula (1). FIG. 4 gives an illustration of this in the particular case where a river R obstructs the movement of the device in a part of the QoP zone of FIG. 3.

It should be noted that the calculation of the QoP is simplified in the case of a location expressed by a location area. Indeed, the location and its QoP expressed in this way remain unchanged until the arrival of information on their change. In other words, the QoP of an area of location is constant, ie QoP = OQoP.

The boundaries of the current location area can also be used as a limit for extending the QoP of a location recalculated by the function QoP = f (OQoP, Δt, v, z). FIG. 5 gives an illustration of this in a case where the region of radius r, defined by the QoP calculated as indicated with reference to FIG. 2, is reduced by the portion extending outside the localization zone ZL.

FIG. 6 shows an example of a procedure applicable by the location data management module 16 in relation to a recording from the memory 18 to process a request for location data concerning the device which is the subject of this recording.

Step 20 represented in FIG. 6 corresponds to the reception of a standard request message by the module 16, coming from an application 2 through the applications interface 12 or coming from the component management module 17. The request can relate to a plurality of geolocatable devices. The following steps in FIG. 6 relate to one of these devices, for which it is assumed that the request has been duly validated with regard to the access rights of the application or of the component to the location data. Following receipt of the request for a geolocatable device, the module 16 calculates a current positioning quality in step 21. If no record is present in the memory 18 for the device in question, a value of QoP minimum is produced in step 21. Otherwise, the current QoP is calculated as explained above using formula (1) and the relevant parameters of the record.

The query specifies a QoP goal, representing the desired precision of the location data (by default, a maximum value can be allocated to the QoP goal). In test 22, this objective is compared with the current QoP calculated in step 21. If the current QoP is at least as good as the objective set, the module 16 determines, in step 23, the location data to be return to respond to the request in step 24, either by simply reading them in the memory record 18, or by recalculating them from this record, in particular to take account of the displacement of the device in the direction of its estimated speed vector.

If test 22 shows that the current QoP calculated in step 21 is insufficient compared to the objective defined in the request, the location data to be returned in step 24 are obtained by a query from a location server 3.

If the initial request concerned several geolocalizable devices, the response made in step 24 may thus include location data recovered in the memory 18 for certain devices, and data freshly obtained from a server 3 for other devices. In each case, the associated QoP can be communicated to the application.

Before interrogating the location server 3 when the current QoP is insufficient, some preliminary operations can be carried out, depending on the configuration of the module 16 by the system administrator.

In particular, if a predictive positioning function is activated (test 26), the module 16 recalculates an optimized QoP objective at least equal to the objective defined for the request being processed, in step 27. This makes it possible to take into account, for each positioning method, a combination of the positioning quality and the cost of obtaining a location data set. If a given device can be located by different methods and if its location data is required often enough, predictive positioning makes it possible to optimize the use of these methods in terms of cost.

For example, even if the cost of a higher QoP is higher, it may be worthwhile to request this higher QoP if this allows later to dispense with interrogating a server 3 during the next request for location data for the same device. This is particularly true when the cost of a higher QoP is lower than the cost of two successive interrogations with the objective of QoP of the request. This optimization is based on the frequency of requests for device location data, specified by an application or evaluated by keeping a history of the distribution over time of requests concerning the device and from all the user applications, which allows a prediction of the time of the next request The history can also carry on the QoPs requested for the device. Optimization can also be done in an auto-adaptive way. If a sufficiently reliable prediction cannot be performed, the QoP provided by step 27 remains equal to the objective defined for the request. For some location servers 3, the OQoP depends on the local network topology (usually different in town and country) and the characteristics of the device. In the first case, the prediction takes into account a recent QoP for the device and, if it is not known, the worst possible QoP. In the second case, the QoP is limited by the characteristics of the device.

After step 27, or if the predictive positioning function is not activated according to test 26, the module 16 examines whether another function for managing concurrent interrogations is activated (test 28). If so, it examines whether an interrogation of a location server 3 more recent than that which gave rise to the recording taken into account in the calculation of the current QoP in step 21 is in progress with a location server 3 (test 29).

If this is the case, the module 16 compares the QoP objective defined for the request (or recalculated in step 27) with that which was specified for the interrogation in progress (test 30). If the QoP previously specified is greater, it is not necessary to repeat the interrogation, so that the module 16 simply places itself awaiting the response from the location server 3 previously interrogated (step 31).

On receipt of this response, the record present in the memory 18 for the device concerned is updated (or created if it is a first interrogation for the device) with the data returned by the server 3 in step 32, then the location data is retransmitted to the application or component at the origin of the request in the aforementioned step 24.

If the predictive positioning function is not activated according to test 28, or if no interrogation is in progress according to test 29, or if the QoP specified in the previous interrogation is not sufficient with regard to the objective according to test 30, a new request is sent to a server 3 for the device.

The interrogated server is first selected in step 33. If several external servers 3 are capable of locating the device with the desired QoP, the module 16 operates the selection on the basis of criteria including the number of queries already sent to these external servers and awaiting response and, if we know that they are different, the average response times of these servers. This selection aims to minimize the average time for retrieving location data. Selection can also be made using a self-adapting load balancing mechanism.

In order to reduce the number of interrogation messages sent to the location server 3 via the interface 13, it is possible to group in the same standard request message interrogations to be made for several different devices (step 34) .

In step 35, the module 16 addresses the interrogation to the selected server via the interface 13, then it places itself awaiting the response to the aforementioned step 31. Certain applications using information on the location of devices need to observe the movements of a set of devices to detect situations where they have to take specific actions, dictated by their service logic. The detection of these situations can be based on regular location requests, at a certain frequency, of the devices concerned. It can also be based on location data generated only when the devices are moving significantly. In both cases, the amount of location data required by the application can be very large in comparison with the number of events detected. In addition, if the movements of the device are observed by numerous applications, the management of the location data for this device is not globally optimized. Indeed, if the requests from the different applications are out of sync (which is the normal case), the frequency of positioning increases a lot. Even if it were possible to synchronize these requests, which would be technically complex and economically irrational, the amount of data exchanged between the location servers and the applications would remain very large, because of the need to transmit all the location data obtained of the servers to all requesting applications.

When the events to be detected mainly depend on the location of one or more devices, the component management module 17 remote in the LDDO 1 advantageously overcomes these difficulties. The events detected can also depend on a certain number of parameters delivered by the servers 3 or by external data sources 5 (for example road traffic, weather, etc.).

We can define a certain number of typical situations whose detection is likely to be taken into account by various applications, for example:

- case where two devices from a specified list are in close proximity to each other (below a determined distance with a determined precision);

- case where a device from a specified list enters a specific geographical area; etc.

The data analysis leading to the detection of such an event can be conducted by the module 17 by executing a predefined software component. Such a component consists of a portion of executable code, associated with a set of parameters defined for each application which calls upon it. The parameters include in particular the identities of the devices in the list to be considered as well as the quantitative criteria of the event to be detected (location, distance, accuracy, road traffic, etc.) and the lifetime of the component (limited or not). These parameters can be modified by the application through the XML / HTTP part of the interface 12. The LDDO also offers the possibility of executing remote components defined dynamically by the applications 2. In this case, the module 17 includes a machine virtual, for example a Java virtual machine (trademark of the company Sun Microsystems), which executes the code of each dynamic component, downloaded by the application. This virtual machine presents the APIs required to manipulate the location data, the external information possibly provided by the servers 5, as well as the parameters and contexts of the dynamic components (modifiable like those of the predefined components) and to prepare and send the messages. reporting events relevant to applications 2.

The inputs of a component (predefined or dynamic) include location data and possibly other information, in particular from external servers 5. Its outputs are software alerts advising the application of detected events as well as a possible description of these events. The component is initialized by a specific request sent by the application which specifies its initial attributes (parameters, algorithm for a dynamic component), which can subsequently be modified. A running component can be stopped and deleted by a destruction request, or automatically when its specified lifespan has expired. The component instance is executed at a frequency defined in the parameters or in response to a determined event such as a specific execution request from the application.

The execution of a component gives rise to requests for location data addressed to the module 16 as required. These requests can be synchronized with those directly from applications 2, which makes it possible to make less use of module 16 and servers 3.

In the case where the LDDO system receives information on the change of location area and / or connection state of geolocatable devices, software components can use this information first and only request a more precise location if this is really necessary.

It is also possible not to request the more precise location of the devices which are not connected to the cellular network or of the devices for which the approximate position (expressed by a location area) is already sufficient to be able to respond to the request. . For example, if the purpose of a software component is to detect the entry of a given device in a given geographic area, no precise location will be requested if the current location area of this device is too far from the geographic area in question. In addition, no new comparison calculation between this device and this geographic area is not necessary until the location area of the device is changed. The use of the location zones and / or of the connection state thus makes it possible to optimize the computation load and to significantly reduce the number of location requests sent to the location servers 3. Thus, the radio and / or signaling load in the cellular network is reduced because information on the location area and the connection status is obtained by monitoring the messages already exchanged in the signaling plan of the cellular network.

Claims

1. System for supervising the location data of geolocation devices, comprising means for processing requests for location data including: - a location memory (18) for containing records each comprising location data of a respective geolocation device delivered by a location data source (3), accompanied by an indication of quality;

- calculation means (16) for estimating a positioning quality of a geolocatable device concerned by a request for location data and for which the location memory contains a record, on the basis of parameters including the quality indication included in said record;

- means (16) for comparing the positioning quality of a geolocalizable device concerned by a request, estimated by the calculation means, and a positioning quality objective defined for said request, in order to respond to the request from recording relating to the device if the estimated quality is sufficient with respect to the objective and by interrogating a source of location data (3) otherwise.

2. The system as claimed in claim 1, in which at least some of the records of the location memory (18) comprise, with the location data of a respective geolocatable device, timestamping information of said location data.

3. The system as claimed in claim 2, in which the parameters on the basis of which the calculation means (16) estimate the positioning quality of a geolocatable device, for which the location memory contains a record comprising time stamping information, further include the current time and said time stamp information.

4. The system as claimed in claim 3, in which at least some of the records of the location memory (18) comprise, with the location data of a respective geolocatable device, an indication of a speed of movement of said device, and in which the parameters on the basis of which the calculation means (16) estimate the positioning quality of said device include said speed indication.

5. The system of claim 4, wherein said speed indication comprises an absolute value of an estimated movement speed of the device.

The system of claim 5, wherein said speed indication further comprises a direction of the estimated traveling speed of the device.

7. The system as claimed in claim 6, in which the response made to the request if the estimated quality is sufficient with respect to the objective comprises location data calculated from the location data of the recording and of the indication of corresponding speed.

8. System according to any one of the preceding claims, in which, for at least one recording of the location memory (18), the positioning quality estimation is carried out by the calculation means (16) on the sole basis of the quality indication.

9. The system as claimed in claim 8, in which said recording further comprises a connection status indicator of the geolocatable device, and the positioning quality estimation is carried out solely on the basis of the quality indication included in said recording. provided that said indicator is representative of a connected state.

10. System according to any one of the preceding claims, in which the parameters on the basis of which the calculation means (16) estimate the positioning quality of a geolocatable device include parameters describing topological constraints (R) in an environment geographic location defined by the location data of the record relating to the device.

11. System according to any one of the preceding claims, in which the request processing means further comprises predictive positioning means (16) for recalculating a positioning quality objective of a geolocatable device concerned by a request when the estimated quality is insufficient compared to the objective defined for said request, and to specify the recalculated quality objective for the interrogation of the location data source (3).

12. The system as claimed in claim 11, in which the recalculated objective is at least equal to the objective defined for said request and is determined by taking account of parameters including a frequency of requests for location data from said device.

13. System according to any one of the preceding claims, in which the request processing means further comprises means (16) for managing concurrent interrogations of location data sources (3), to determine whether a relative interrogation to a geolocatable device concerned by a request is in progress when the estimated quality is insufficient compared to the objective defined for said request, the response to the request being developed from the response to a query in progress for which has been specified a quality objective at least equal to the objective defined for said request, or by carrying out a new interrogation if a quality objective at least equal to the objective defined for said request has not been specified for any interrogation in progress relatively to the device.

14. System according to any one of the preceding claims, comprising an interface (13) for communication with at least one external source of location data (3).

15. The system as claimed in claim 14, comprising means (16) for grouping interrogations to address an external data source of location (3), via the communication interface (13), a message requesting the location data of several geolocatable devices for which the positioning qualities respectively estimated by the calculation means are insufficient with respect to respective objectives defined for requests concerning said devices.

16. The system as claimed in claim 14 or 15, comprising means (16) for sending a query relating to the location data of a device to a location data source selected from several external sources of location data (3) on the basis of criteria including the number of queries already sent to said external sources.

17. System according to any one of claims 14 to 16, in which the communication interface (13) is arranged to receive information from at least one server associated with a cellular telecommunication system, including information on a zone. locating at least one geolocatable device, said information received from the server associated with the cellular system being processed to update the recording of the location memory (18) relating to said geolocatable device.

18. The system as claimed in claim 17, in which said information on the location area of the geolocatable device is spontaneously transmitted by the server associated with the cellular system during a change of location area of the geolocation device.

19. The system of claim 17 or 18, wherein said information received from the server associated with the cellular system further includes information on a connection state of the geolocation device.

20. The system as claimed in claim 19, in which said information on the connection state of the geolocalizable device is spontaneously transmitted by the server associated with the cellular system during a change of connection state of the geolocalizable device.

21. System according to any one of the preceding claims, comprising an interface (12) for communication with at least one application using location data (2).

22. The system as claimed in claim 21, comprising means (17) for detecting events by analyzing location data from at least one geolocation device, for signaling the events detected to at least one user application (2) by the communication interface (12).

23. The system of claim 22, wherein the location data analyzed by the event detection means (17) is provided by the request processing means (16).

24. The system of claim 22 or 23, wherein the event detection means (17) are arranged to generate requests for location data addressed to the processing means (16).

25. System according to any one of claims 22 to 24, in which the event detection means (17) comprise at least one predefined software component executed for a user application (2), having a predetermined portion of code and parameters modifiable by said user application via the communication interface (12).

26. System according to any one of claims 22 to 25, in which the event detection means comprise at least one dynamic software component executed for a user application (2), having at least a portion of code downloaded by said application. user via the communication interface (12).

27. System according to any one of claims 22 to 26, further comprising an interface (15) for communication with at least one external information source (5), and in which the event detection means are arranged for analyze the location data of at least one geolocation device taking into account information obtained from at least one external information source via said communication interface (15).