A method for handling position data in a mobile equipment, and a mobile equipment having improved position data handling capabilities

0001The present invention generally relates to a method and system for handling position determination devices and related position data in a mobile equipment such as a mobile phone, a personal digital assistant, a laptop computer, etc.

Background of the invention

0002Modem communication services increasingly tend to use context information, i.e. any information that can be used to characterize the location or position of an entity, where an entity can be a person, place, physical or computational object, and to perform so-called context-aware computing, i.e. to use the context information to provide task-relevant information and/or services to the user of a mobile equipment, wherever they may be.

0003For instance, network service providing equipments are known where a number of techniques are used for providing services to a user mobile station or equipment based on his current location as determined or obtained at the network level through a predetermined positioning technology.

0004A major drawback of this known approach is that the network software and/or a software in the mobile equipment needs a specific design for taking into account location information, which design also depends from the type of position data that will be determined or obtained.

0005Another major drawback is that the predetermined type of position data may not be suitable for all contexts and requested services.

0006For instance, position data obtained through so-called cell-ID, i.e. the identifiers of the cells of a cellular telephone network within reach of a mobile phone, will not be accurate enough for e.g. indoor navigation service in a shopping mall or other place.

0007In another example, a GPS device, which has a high power consumption and good accuracy, will not be suitable in contexts where low power consumption is required.

0008<patcit id="pcit0001" dnum="US200210019698A1"><text>US 200210019698 A1</text></patcit> describes a positioning method selection device (PMSD). The PMSD receives a positioning request from an application, forms a parameter or parameters indicating the quality of positioning requested by the application, compares the quality of positioning data provided by the positioning methods with the positioning quality required by the application, and sends positioning data to the application in response to the positioning request.

0009<patcit id="pcit0002" dnum="US6002936A"><text>US 6 002 936</text></patcit> describes a telecommunications system in which a Mobile Station (MS) sends a list of terminal-based positioning methods that the MS is capable of performing, to a Mobile Switching Center / Visitor Location Register (MSC/VLR). This list can be forwarded to a Mobile Positioning Center (MPC) for determination of the optimum positioning method.

0010The article entitled "Application and performance of personnel tracking systems" by R. Christ, ISBN: 0-7803-3537-6, presents and compares potential approaches to personnel tracking. The article introduces an alternative RF location technique utilized by a system called "Personal Alarm Location System" (PALS).

Summary of the invention

0011One object of the present invention is to provide a method and system for handling position information in a mobile equipment that is transparent to any application software designed for a mobile equipment, i.e. that provide a common interface to any position determination technology (hereinafter "PDT") implemented in a mobile equipment, and that allows a user application to self-select and best exploit the capabilities of whatever PDT is available in the mobile equipment.

0012Another object of the present invention is to allow location-based application developers to interact through a single interface and avoid worrying about complex positioning issues and techniques.

0013Still another object of the present invention is to provide an adaptable and customizable device and method that can be used by general-purpose wireless applications, and can also be easily tailored for various environments, such as for the automotive environment or for high accuracy in-building navigation applications using local network aided positioning technology.

0014In particular, the device and method according to the present invention seeks to decrease the efforts and investments needed for integrating location technology into applications developed in standard developing environments such as the so-called J2ME environment (for Java 2 Micro Edition).

0015More particularly, the present invention provides according to a first aspect a method as claimed in claim 1.

0016Preferred but non-limiting aspects of the above method are defined in claims 2-9.

0017According to a second aspect, the present invention provides a mobile equipment as claimed in claim 10.

0018Preferred but non-limiting aspects of the mobile equipment are defined in claims 11-20.

Brief description of the drawings

0019Other aims, features and advantages of the present invention will better appear from the following detailed description of a preferred embodiment thereof, made with reference to the appended drawings, in which: <ul id="ul0001" list-style="none"><li><figref idref="f0001">Figure 1</figref> is a block diagram of the general architecture of a mobile equipment incorporating a location handling system according to the present invention, and</li><li><figref idref="f0002">Figures 2</figref>, <figref idref="f0003">3</figref> and <figref idref="f0004">4</figref> are flow diagrams illustrating three process implemented in the present invention.</li></ul>

Detailed description of a preferred embodiment

0020It will be first noted that all trademarks cited in the present specification belong to their respective owners.

1) Location handling system

a) Purposes

0021The basic purpose of the location handling system is both to provide a simple localization interface to application software (at the network and/or mobile side) so that the development of such software does not require that the developers are aware of the positioning technologies the device is equipped with, and to easily enable to best support up-to-date (whether current or future) positioning technologies and/or specific hardware.

0022On one side the fact of providing a simple interface leads the developers not to have any knowledge about positioning issues and techniques and to interact with all the positioning equipments in the same way. Therefore, the developers of application software which should cooperate with the system do not have to learn at each time how a new or different technology works and will not be required to have specific knowledge on signal propagation, modulation, etc. In other words, the application software using location information does not need to be specifically designed according to existing or future positioning technologies.

0023Another purpose of the location handling system is to fully exploit the capabilities of a given equipment and to provide an interface common to all the positioning technology, so as to add extra value to those products the Location Handler will support and/or to conform to the Location Handler specifications.

b) Functional description

0024A first feature of the location handling system is the support of different positioning technologies, i.e. multiple (at least two) kinds of location devices that can be added or removed dynamically. In this regard, the system includes one driver or "cartridge" per positioning device, with which a main component is capable of communicating individually.

0025A correlated feature of the location handling system is to make abstraction of the effectively used positioning technology, i.e. to handle different and heterogeneous positioning technologies in a simple and effective way. To that end, the system provides a common, simple but still flexible interface to the application software using location information so as to easily and optimally support new positioning technologies and/or new hardware and/or logic regarding an existing technology.

0026Another feature of the inventive system is a capability of switching from one positioning technology to another under various circumstances as will be explained in the following. For instance, switching can occur when a currently used positioning technology becomes unavailable or when the currently used positioning technology becomes less adapted to the current circumstances than another positioning technology which is available in the equipment.

0027In order to implement such dynamic switching, the location handling system cooperates with cartridges associated with the different available positioning technologies, and parameters are stored in a memory in association with each cartridge.

0028In the present example, four parameters values can be associated with a given cartridge, and the system is capable of reading these parameters values for each cartridge, either at predetermined times or upon specific events, so as to determine through a suitable process which cartridge should be the active one, i.e. which positioning technology should be used.

0029The four exemplary parameters are ACCURACY, POWER CONSUMPTION, RESPONSE TIME and CUSTOM.

0030ACCURACY is the default mode, i.e. by default, the system will select the cartridge (i.e. the positioning technology) which provides the best position accuracy.

0031It should be noted that the values of the ACCURACY, POWER CONSUMPTION and RESPONSE TIME parameters for a given technology are typically obtained from the technical specifications or datasheets provided by positioning technology manufacturers or providers.

0032The CUSTOM parameter is available for developers, so as to offer the capability to select a positioning technology according to another, existing or future, criterion.

0033Each cartridge, depending on the associated positioning technology, is capable of handling physical or logic location information.

0034For instance, technologies such as proximity technologies are not capable of generating physical coordinates such as Cartesian or WGS84, but just consider one or several IDs. More specifically, a mobile equipment having a Bluetooth communication capability can only obtain the addresses BD_ADDR of the beacons which are within reach. Similarly, a communication under the radiofrequency standard 802.11b will give the MAC addresses of the beacons in reach as the position information, and a RF tag system will provide identifiers ("RFid") of the tags with which contact is established.

0035Other technologies, as will be described in the following, provide as the location information physical information such as Cartesian coordinates (X, Y, Z) or standard latitude/longitude and possibly altitude coordinates, preferably according to the WGS84 standard. An application software using the system according to the present invention can specify to the system, through a suitable message, the kind of location data it expects.

0036As an example, these messages are the following: <ul id="ul0002" list-style="dash" compact="compact"><li>a "TO_CARTESLAN" message will return Cartesian coordinates;</li><li>a "TO_WGS84" message will return standard WGS84 latitude/longitude and possibaltitude coordinates;</li><li>a "TO_LOGIC" message will return logic information such as beacon or tag identifiers;</li><li>finally, a "TO_ALL" message will return all types of positioning data, whether physical or logic.</li></ul>

0037In the present embodiment, two positioning technologies are considered, i.e. a GPS system providing WGS84 coordinates and Bluetooth communication system providing addresses of Bluetooth beacons within reach. The one skilled in the art will however easily understahd how to adapt the teachings of the present description to other positioning technologies.

0038When a given positioning device is not capable per se to supply the position information in the format required by the application software, then the present system includes, preferably in the form of a plug-in software module, a conversion module programmed - in a manner known per se- to convert a given position format to another position format.

0039For instance, such conversion module is capable of converting Cartesian coordinates into WGS84 coordinates and vice versa. The conversion module can also be in charge of determining physical position data such as Cartesian or WGS84 from logic position data.

0040The system of the present invention may also include other types of plug-in modules such as: <ul id="ul0003" list-style="dash"><li>a history module capable of providing a history service, i.e. position data stored in a memory in association with time/date information; such module may for instance allow the user to set a time window for the position history, and a sampling frequency, i.e. the number of times per minute (or hour, or day, etc.) the position information will be stored together with the associated time/date information;</li><li>various computing modules for processing position information; for instance, if the mobile equipment is capable of generating different position data from different positioning technology, a position refinement plug-in module can take as an input these data and compute therefrom a refined position data, taking into account inter alia the accuracy of each positioning technology.</li></ul>

0041Advantageously, and in a manner known per se by the one skilled in computer art, each plug-in module can be used dynamically: the system automatically detects the presence of a plug-in module and, when needed, calls a given execution in the module by a suitable instruction and parameters.

0042For instance, in the case the conversion module has been installed and the application software (or the user) asks for physical location data in a given format while the active positioning technology (i.e. the active cartridge) returns a logic position, then the conversion module automatically converts the logic position data into physical location data in said given format.

0043Similarly, a position refinement plug-in module can be called automatically, when present, so as to allow two or more positioning technologies to be used at the same time and to generate from the data provided by these technologies a refined position data in terms of accuracy.

0044The system of the present invention can communicate with an application software both asynchronously and synchronously, i.e. can communicate position data to the application either upon request from the application, or at predetermined times.

0045For that purpose, standard messages can be provided by the application software to the system, basically a position request message to which the system will answer with a message containing the requested position data, and a message requesting the system to automatically output to the application software at a given rate ("polling frequency") provided as a parameter in the message (synchronous mode). Another possibility is that the message contains as a parameter, instead of a polling frequency, a "RealMode" indicator, so that the position handling system will provide refreshed position data as soon as they become available (asynchronous mode).

0046Practically, the asynchronous mode is advantageously implemented by means of "location listener" which is selectively activated in the system so as to send a position data message to the application software as soon as the position data have been refreshed. The lack of such location listener is automatically detected by the system, which then operates in synchronous mode and/or in "on demand" mode.

0047In addition, while the system operates in asynchronous mode, an application software preferably can ask for "on demand" localization.

0048According to another preferred feature, each cartridge receives from the system information about the current mode of operation, so as not to perform useless location determination and to therefore limit power consumption and possibly increase response time.

0049According to another preferred feature, when the system returns to a requesting application position data, such data are accompanied with a time/date stamp and with an accuracy information indicating the accuracy of the position data.

0050In a basic mode of operation, the accuracy information is directly read from the ACCURACY parameter field in the cartridge which has determined the position, or derived therefrom.

0051When a position refining module is present, such module can combine the ACCURACY parameters read from two or more cartridges which have determined the positions used as inputs by the module so as to compute a combined accuracy information.

0052Other information can also be provided to the application software in addition to the above position, time/date and accuracy data.

0053Typically, such additional information could include direction, speed, acceleration, etc., as determined by computation based on history data, descriptors related to a specific hardware, etc.

c) Architecture description

0054A preferred software architecture for the system and method according to the present invention will now be described with additional details with reference to <figref idref="f0001">Figure 1</figref>.

0055First of all, the core of the architecture is a main location handling component <i>Location Handler</i> which is in charge of handling location and related information. This component queries a plurality of positioning cartridges such as <i>GPS NMEA, GPS SiRF</i> and <i>BlueTooth</i> via a cartridge application programming interface <i>cartridge API</i>, which provides a common interface to all supported positioning technologies. The main component <i>Location Handler</i> can communicate with any application software using position information (not shown in <figref idref="f0001">Figure 1</figref>) through a suitable application programming interface <i>Location API</i>.

0056As above-mentioned, plug-in modules are provided to supply coherent services to the location API. In <figref idref="f0001">Figure 1</figref> have been shown a history module <i>SmartHistory</i>, a conversion module <i>SmartConvert</i> and a computation module <i>SmartCompute</i>.

0057In view of the types of functionalities offered by the <i>SmartHistory, SmartConvert</i> and <i>SmartCompute</i> plug-in modules, they are each built over Location Handler.

2) Description of selected algorithms

0058A literal description of the essential algorithms implemented in the inventive system and method will now be given.

a) Cartridge selection

0059First of all, <i>CartridgeHandler</i> process or algorithm checks whether a currently active cartridge is still available, in the case it is the current cartridge is selected. In case said current cartridge is no longer available, it is closed to release the corresponding resources and the <i>CartrtdgeHandler</i> process parses a list of current cartridges stored in the system in order to find another cartridge which would be available. As a cartridge is found available it is selected as the current cartridge, per a selection process which will be exemplified in the following. If none of the cartridges referenced by the current cartridges list is available a <i>NoAvailableCartridgeException</i> is raised.

0060The cartridge selection is a quite simple process as most of the heavy work (list update, etc.) will be done when a new cartridge is added/removed and/or a new criterion or position data format is set (as will be described in the following), and as these types of operations will be rare compared to cartridge selection.

0061The <i>CartridgeHandler</i> process for cartridge selection purposes is preferably called each time a new location is requested.

b) Cartridge insertion

0062When a new cartridge is installed in the system, the <i>CartridgeHandler</i> process checks if the cartridge had been previously installed. In the affirmative, the <i>CartridgeHandler</i> process does nothing. In the negative, the <i>CartridgeHandler</i> process adds the installed cartridge in a table called <i>Vector</i> which collects all the cartridge data, and determines a unique identifier or index thereof (preferably the next available integer N+1 when pre-existing cartridges have indexes comprises between 1 and N). Beside the <i>Vector</i> table are stored four arrays <i>Array</i> of integer values <i>Int</i>. One of the integers array comprises the indexes of the cartridges capable of returning locations in the WGS84 format, another stores the indexes of those returning Cartesian locations, another stores the indexes of those returning logic locations and finally the last stores the indexes of those matching the currently requested position format and preferred criterion. All the arrays <i>array</i> of integer values <i>Int</i> constitute lists of most preferred to least preferred position determination devices according to the priority criterion as will be further described in the following. The <i>CartridgeHandler</i> process checks the type(s) of position data format that the installed cartridge is capable of supplying and writes its index in the corresponding list(s). This insertion process can benefit of the ranking process based on preferred criterion/criteria as will be described in full detail in the following.

c) Cartridge removal

0063When a cartridge is to be uninstalled or removed, the <i>CartridgeHandler</i> process checks whether the cartridge was listed in the <i>Vector</i> table. In the negative, it is not, the <i>cartridgeHandler</i> process does nothing. In the affirmative, the <i>CartridgeHandler</i> process verifies the cartridge capabilities and removes it both from the <i>Vector</i> table and the corresponding arrays <i>Array.</i> In the practical embodiment where all installed cartridges have successive indexes which are integers comprised between 1 and N, the removal or a cartridge with an index lower than N also involve a change of the higher indexes, which are decremented by one.

d) Context dependent setting

0064In the case the <i>Location Handler</i> determines that the context has changed (typically this is passed as a context message to the <i>Location Handler</i> component), then it asks the <i>CartridgeHandler</i> process to set a new related strategy regarding parameter-based cartridge selection, so that said process reorders in the arrays <i>Array</i> the cartridges to be activated in priority.

d) Position data format setting

0065In the case the <i>Location Handler</i> component determines, based on a request or message from application software, that a new position data format should be used which is different from the current format, then it requests the <i>CartridgeHandler</i> process to update the current cartridges indexes list in the arrays <i>Array</i> in order to reflect such change.

e) Cartridge mode switching

0066No assumption can be made about the working mode a cartridge supports. This means that the localization modes (synchronous or asynchronous) have to be handled at higher levels. On the other hand, some positioning devices inherently have the capability to work different ways so as to best behave in a peculiar case.

0067As the system of the present invention is aimed both to provide a common interface and to best exploit each device, the <i>Location Handler</i> component advantageously includes a capability of switch the mode of operation of the cartridges associated with PDTs which support multiple modes, in compliance with the current status of the <i>Location Handler</i> component.

0068For instance, an activated cartridge can be set by default to work in synchronous mode. However, when the cartridge receives from the <i>Location Handler</i> component through the <i>CartridgeHandler</i> process a message indicating that the mode has been turned from synchronous to asynchronous mode, then the cartridge conforms its behavior to this mode change and controls the PDT accordingly.

0069Conversely, as the <i>Location Handler</i> component mode is set back to synchronous, then the <i>CartridgeHandler</i> process restores the synchronous mode of the active cartridge, typically by deactivating same and then reactivating it in the synchronous mode.

f) Cartridge types

0070In the present embodiment, the <i>Location Handler</i> component can access to two kinds of cartridges: <ul id="ul0004" list-style="dash" compact="compact"><li>pure Java cartridges: these are cartridges based on standard KVM (for "K Virtual Machine", i.e. the standard implementation of the Java 2 Micro Edition environment for a given computing platform); of example would be a cartridge for GPS NMEA positioning technology communicating through serial port;</li><li>native cartridges: these are cartridges based on an an extended KVM virtual machine (this for instance is the case of a BlueTooth cartridge using a standard or specific BlueTooth application programming interface, such as the standard one included in the standard KVM environment). Hence, such cartridges have the capability of making specific calls to native methods (This could be the case for instance in some cellular phones having an access to an integrated GPS module, such as a cellular phone currently marketed by Benefon).</li></ul>

g) Examples of PDT constraints associated to a context

0071It has been explained in the foregoing that each cartridge stores a plurality of associated parameters, i.e. ACCURACY, POWER CONSUMPTION, RESPONSE TIME and CUSTOM in the present example.

0072Besides, the Location Handler component is capable of receiving in a message from an application software, or to determine by itself, a "context" information revealing in what type of context or physical environment the mobile equipment implementing the system is operating.

0073For instance, when a mobile phone rests on its cradle in a car, then a very simple logic can determine this fact, so that a context parameter value <i>In Car</i> can be set.

0074Similarly, by analyzing the location history handled by the plug-in module <i>SmartHistory</i>, and in particular the current average speed of the mobile equipment, the Location Handler component can determine whether the used is <i>On Foot</i> or again <i>In Car.</i>

0075In addition, by polling a cartridge such as a BlueTooth cartridge so as to determine whether BlueTooth beacons are within reach, the Location Handler can determine by itself whether a mobile equipment is <i>Indoor</i>. In the contrary, it is considered as being <i>Outdoor.</i>

0076In addition, the application software can give to the <i>Location Handler</i> component any other context information as determined or obtained by said software.

0077The following Table I gives examples of parameter priorities used by the Location Handler component for selecting and activating the most appropriate cartridge in a given context. In this table, the context is defined by the combination of three parameter values, i.e. a user situation information, a location information and a service information. The latter information is typically useful when a given application software can provide different types of services and therefore has different needs concerning the position determination technology to be used. <tables id="tabl0001" num="0001"><table frame="all"><title><u style="single">Table I</u></title><tgroup cols="4"><colspec colnum="1" colname="col1" colwidth="26mm" /><colspec colnum="2" colname="col2" colwidth="28mm" /><colspec colnum="3" colname="col3" colwidth="30mm" /><colspec colnum="4" colname="col4" colwidth="28mm" /><thead><row><entry valign="top"><b>User situation</b></entry><entry valign="top"><b>Location</b></entry><entry valign="top"><b>Service</b></entry><entry valign="top"><b>Constraints</b></entry></row></thead><tbody><row rowsep="0"><entry>In Car</entry><entry>Outdoor</entry><entry>Navigation</entry><entry>Accuracy</entry></row><row><entry /><entry /><entry /><entry>Response Time</entry></row><row rowsep="0"><entry>In Car</entry><entry>Outdoor</entry><entry>Traffic Information</entry><entry>Response Time</entry></row><row><entry /><entry /><entry /><entry>Accuracy</entry></row><row rowsep="0"><entry>On Foot</entry><entry>Indoor/Outdoor</entry><entry>Navigation</entry><entry>Power</entry></row><row rowsep="0"><entry /><entry /><entry /><entry>Consumption</entry></row><row><entry /><entry /><entry /><entry>Accuracy</entry></row><row rowsep="0"><entry>On Foot</entry><entry>Indoor</entry><entry>Yellow Pages</entry><entry>Accuracy</entry></row><row rowsep="0"><entry /><entry /><entry /><entry>Power</entry></row><row><entry /><entry /><entry /><entry>Consumption</entry></row></tbody></tgroup></table></tables>

h) Examples of position determination technologies

0078The present invention can be advantageously used with the all currently available position determination technologies. Typical examples of these technologies and their properties are given in the following Table II. <tables id="tabl0002" num="0002"><table frame="all"><title><u style="single">Table II</u></title><tgroup cols="4"><colspec colnum="1" colname="col1" colwidth="36mm" /><colspec colnum="2" colname="col2" colwidth="35mm" /><colspec colnum="3" colname="col3" colwidth="27mm" /><colspec colnum="4" colname="col4" colwidth="33mm" /><thead><row><entry align="center" valign="top" /><entry namest="col2" nameend="col4" align="center" valign="top">Properties</entry></row><row><entry align="center" valign="top">Available PDTs</entry><entry align="center" valign="top">Positioning Accuracy</entry><entry align="center" valign="top">Response Time</entry><entry align="center" valign="top">Power Consumption</entry></row></thead><tbody><row><entry>GPS</entry><entry>50 meters</entry><entry>1 sec</entry><entry>&lt;170mW</entry></row><row><entry>Cell phone antenna ID</entry><entry>250 meters</entry><entry>3 sec</entry><entry>&lt;200mW</entry></row><row><entry>Bluetooth</entry><entry>10 meters</entry><entry>3 sec</entry><entry>&lt;100mW</entry></row></tbody></tgroup></table></tables>

0079It should be noted that the "Positioning Accuracy" and "Response time" properties are directly used as parameters in the corresponding driving cartridges. The "Power Consumption" parameter can generally be obtained directly or indirectly from the technical data of the manufacturer.

i) Practical example of dynamic positioning technology switching

0080A mobile equipment is in an "in car outdoor navigation" context and needs positioning data to provide the user with real time navigation instructions between his current location and a shopping mall.

0081The system first determines, among all installed PDTs as listed in table II, those who are available. In the present example, the BlueTooth positioning technology is not available (no BlueTooth beacon in the vicinity). Then, as the priority parameter is determined as being positioning accuracy, the GPS PDT is determined as preferred, and the Cell-ID PDT comes second.

0082It should be noted here that, should the process determine that two PDTs have the same parameter value as to the criterion of higher priority, then the process selects the PDT to be used as the one having the best parameter as to the criterion coming in second rank (here the "Response Time" criterion/parameter).

0083Once the user arrived in the shopping mall, either the application software automatically, and/or the user himself manually through a suitable input action, sets the context to "on foot indoor navigation". The available navigation application software has the functionality of providing navigation information to the user e.g. between shopping mall entrance and a selected shop.

0084The system takes into consideration this new context and tries to find between available PDTs those which (i) currently are available and (ii) better match with this new context.

0085According to criterion of higher priority attached to the user context, i.e. "Power Consumption", and supposing that the BlueTooth PDT is available and has the best "Power Consumption" parameter, the BlueTooth PDT is therefore selected and activated.

0086<figref idref="f0002">Figures 2</figref>, <figref idref="f0003">3</figref> and <figref idref="f0004">4</figref> diagrammatically illustrate the essential processes performed according to the present invention. In each of these Figures, the three columns designate from left to right the application software level ("Application"), the location handling level ("Dynamic Switching") and the position determination technology level ("PDTs").

0087Referring now to <figref idref="f0002">Figure 2</figref>, which illustrates the main process when a context changes, a new context is determined at the application software level. A corresponding message, including as a parameter a designation of the new context, is passed to the location handling system. A first test is performed at this level so as to determine whether any PDT is implemented (which requires that the corresponding cartridge is installed). If no PDT is implemented, then the location handling system provides to the application a message indicating this, so the process aborts.

0088If the location handling system has determined that at least one PDT is present, then a message addressed to the corresponding cartridge(s) allows to obtain the properties (i.e. parameters + data format) thereof.

0089Then the location handling system, identifies the applicable criteria by order or priority, depending on the context, and applies these criteria to the set of properties, so as to generate a ranking of installed PDTs which could be used in the new context, by order of preference. The arrays <i>Array</i> of integers <i>Int</i> described in the foregoing are used for that purpose.

0090If the above ranking process finds that no PDT suits the needs defined by the new context, then a corresponding message is provided to the application software, and the process is aborted.

0091If at least one PDT suiting the needs defined by the new context is found, then an ordered list of PDTs corresponding to the ranking is created and stored (cf. <i>Array</i>), from most preferred to least preferred. Then the context change process then ends.

0092<figref idref="f0003">Figure 3</figref> illustrates the major steps performed when the application software provides to the location handling system a location request message.

0093The location handling system then parses the ordered list stored in memory as described with reference to <figref idref="f0002">Figure 2</figref>, from most preferred to least preferred, and each PDT is checked for availability.

0094If no PDT appears to be available, a corresponding message is sent to the application software, and the process then ends.

0095If on the contrary a PDT is determined as being available (the best available), a request for position is provided to the corresponding cartridge, and the position data are then transferred by the location handling system from the cartridge to the application software.

0096If any data format conversion is to be done, it is performed at this stage under control of the location handling system.

0097<figref idref="f0004">Figure 4</figref> shows a variant embodiment of the process illustrated in <figref idref="f0003">Figure 3</figref>.

0098While in <figref idref="f0003">Figure 3</figref> the best available PDT was looked for each time location data were requested, the process of <figref idref="f0004">Figure 4</figref> does not perform this check at each time.

0099More precisely, when a location request message is received by the location handling system (provided of course that the context does not change), the system first determines whether a PDT was already selected or active.

0100In the negative, a process identical to the one shown in <figref idref="f0003">Figure 3</figref> is performed. In the affirmative, the availability of the currently selected PDT is determined. If this PDT is still available, then the location data are obtained from the PDT cartridge and transferred to the application software. If on the contrary the currently selected PDT is no longer available, then the process of <figref idref="f0003">Figure 3</figref> is performed to find the most preferred available PDT.

0101Of course, many variants and changed may be brought to the invention as described.

0102In particular, the present invention can be used with a wide variety of current and future PDTs such as OTD (Observed Time Difference) with a variety of wireless technologies, classical GPS, differential GPS, assisted GPS, Cell-ID (cellular phone network), Enhanced Cell-ID, BlueTooth beacon IDs and similar RF communication systems for intelligent mobile equipment, Bluetooth with distance measurements, etc.