Method and Apparatus for Providing Location-Dependent Services to Mobile
Users
This application claims the benefit of Provisional U.S. Patent application no. 60/148,849, filed on August 12, 1999.
FIELD OF THE INVENTION
The present invention pertains to the field of mobile information services. More particularly, the present invention relates to providing navigation information and other services to the user of a mobile processing device.
BACKGROUND OF THE INVENTION
Automobile on-board navigation systems are becoming increasingly more popular. Such systems are commonly available as an option in many models and are now standard components in some higher-end models. The navigation system generally allows the driver to enter a desired destination. The system then computes a route from the current location of the vehicle to the destination, and then tracks the vehicle's progress along the route while guiding the driver with audible or visual navigation instructions, a graphical map display, or a combination thereof. Computer software has also been developed to enable a conventional personal computer (PC) to perform similar navigation functions, including route calculation. A laptop (notebook) PC equipped with such software and a mobile positioning device, such as a Global Positioning System (GPS) receiver, may be used to track a user's progress along the computed route. Recently, there been interest in incorporating navigation capabilities such as these into other types of mobile devices, such as cellular telephones ("cell phones"), personal digital assistants (PDAs), personal information managers (PIMs), and other devices.
Existing navigation systems such as those mentioned above have certain
disadvantages. For example, the automobile-based navigation systems are typically based on dedicated hardware and/or software and are therefore not usable for other applications. In addition, existing navigation systems are very limited in. the type and amount of data they can utilize to provide navigation information to the user. Also, such systems generally require the user to select a desired destination before computing a route or providing navigation instructions. However, the selection of the destination can be inconvenient and tedious. In particular, the user is often required to either enter a specific street address or select the destination from a predetermined list provided by the navigation system. This may be inconvenient if the user does not know the address of the destination and the destination does not appear on the predetermined list. Furthermore, even if the user does know the address of destination, certain users dislike the process of manually entering that information. In addition, existing navigation systems generally provide only limited types of information to the user.
SUMMARY OF THE INVENTION
The present invention includes a method and apparatus for providing location- or time-dependent data to a remote processing device, which may be a mobile device. The mobile device may be, for example, a cellular telephone, an automobile on-board navigation system, or a hand-held computing device, such as a PDA, PIM, or the like. Among other advantages, the invention allows the user of the remote processing device to quickly and easily request and receive maps, route solutions, and point in interest (POI) search solutions, without requiring the user to know or to input detailed origin or destination information. Further, solutions provided to the user may be generated based on data compiled from numerous different sources.
In one embodiment, the apparatus comprises a data indexer and a geocoder. The data indexer receives geographic data and indexes the geographic data to spatial coordinates to generate indexed data. The geocoder responds to a
user query from the remote processing device to determine a set of coordinates from the indexed data based on a received index item, and outputs the set of coordinates for transmission to the remote processing device. The apparatus may also be used to search for a point of interest from the indexed data based on a user query including a distance value and an origin, and to output the point of interest for transmission to the remote processing device. The apparatus may further include a route generator which generates a route between two locations in response to a user query from the remote processing device, using the indexed data.
Another aspect of the present invention is a method and apparatus for allowing a mobile device to access location-dependent information maintained by a remote server system. At the server system, a signal transmitted from the mobile device is received. The signal represents a user input applied at the mobile device to select an item in a database. The server system is used to compute location-dependent information based on the signal and geocoded data in the server system. The location-dependent information may comprise information specifying a geographic location, which may include or represent a solution of a geographic proximity search, or information for assisting a driver in navigating an automobile. The geocoded data may be generated dynamically by the server system in response to receiving the signal from the processing device. A signal representing the location-dependent information is then transmitted to a remote recipient, which may be the originating mobile device or some other processing device, which need not be a mobile device. The recipient of the signal transmitted from the server system may be automatically and dynamically determined at the server system, and this transmission may be performed asynchronously.
The server system may maintain a unique code for each of multiple mobile devices. User-specific information in the server system may also be maintained in the server system. This information may be accessed by the server system in response to receiving the signal representing from the mobile device, which may include the unique code of the mobile device, such that the computed location- dependent information is tailored to a particular user or device. Accordingly, the
computation of location-dependent data in the server system may include the cross-referencing of time and /or location dependent information with user information.
Data stored in the mobile device may be updated from the server system. Such updating may be accomplished by receiving a signal at the server system representing an input from a user of the remote mobile device. Based on the signal, an update signal may be asynchronously transmitted from the server system to the mobile device to automatically update data stored in the mobile device.
Yet another aspect of the present invention is a method and apparatus for maintaining map data at the server system. The method represents a geocoding process, which in one embodiment includes inputting to the server system a user- provided database maintained by the remote processing device. The database includes multiple data entries. Each of the data entries is then linked to the map data to form a set of geocoded data. The linking may be performed automatically by the server system, or manually by an operator. The geocoded data is maintained at the server system for use by a remote processing device, such as noted above. The geocoding process may be performed dynamically in response to a query from a remote mobile computing device.
Other features of the present invention will be apparent from the accompanying drawings and from the detailed description which follows.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which:
Figure 1 illustrates a network configuration in which a mobile device can be used to access location- or time-dependent information in a server system.
Figure 2 is a block diagram of a computer system.
Figure 3 illustrates the software and data components of a mobile client
device and the server system.
Figure 4 illustrates the components of the location server and the geocoding and routing indexer of the server system.
Figure 5 is a flow diagram illustrating a geocoding process that may be implemented by the server system.
Figure 6 is a flow diagram illustrating a point of interest (POI) lookup process that may be implemented in a client device.
Figure 7 is a flow diagram illustrating a route calculation process that may be implemented in a client device.
Figure 8 is a flow diagram illustrating a process that may be implemented in the server system for responding to a query from a remote client device.
Figure 9 is a flow diagram illustrating a process for performing a POI search or a route calculation based on a user profile.
Figure 10 is a flow diagram illustrating a process that may be implemented in the server system to determine an appropriate recipient device for transmission.
Figure 11 is a flow diagram illustrating an operator-assisted POI lookup process.
DETAILED DESCRIPTION
A method and apparatus for providing navigation assistance and other services to a user of a mobile processing device are described. The method and apparatus include a technique for providing location- or time-dependent services to users of mobile devices. Applications and business models may include, for example, location- and time-dependent notifications ("geo broadcast"), directed advertising ("geo mail"), or preference and profile management ("geo behavior").
The user of a mobile processing device, such as a cellular telephone, PDA, PIM, notebook computer, or the like, has communication capability with a server. The communication can be verbal (e.g., via a telephone connection) or digital (via a computer network, such as the Internet). The server has access to records that are created by the user, then replicated and enhanced (extended) by a server
process and /or user entry. Specifically, the user creates a profile of entities. Examples of such a profile are a 'phone book' (contact list) stored on a cell phone and a 'preferred destination list' stored on a mobile navigation device. The profile contains labeled entities, for example, a person's name and corresponding data such as the person's phone number at home, phone number at the office, and/or mobile phone number (for a cellular telephone). For a mobile navigation device, an entry may be a location entered by address or a location entered by point-and- click at a map displayed by the device. The list is replicated on the server through a conventional download and synchronization process. The list is then enhanced, or extended, through automated processes, user entry, or both. The processes are referred to herein as indexing and 'geocoding'. When the user accesses the server through a digital interface, the list is synchronized to reflect the most-recently edited records.
As an example, assume that a cell phone user has created a list, stored in the cell phone, in the format {Name {location labels:phone numbers} }, such as:
Joe {home 555-1234, mobile 555-5678, office 555-3456} Mike {home 555-4321, mobile 555-8765, office 555-6543} etc.
The list is then digitally or manually replicated onto the server. Mechanisms such as Bluetooth or Starfish or SIM100 may be utilized, or a World Wide Web ("Web") access page may be used for manual replication. The server process then "geocodes" the entries (associates each entry with a set of latitude /longitude coordinates) using, for example, any of the following methods:
1) An index to a complete address set, such as a GDT database, or a complete phone number set, such as InfoUSA or LSIP, is used to create address entries using phone numbers;
2) the user key enters the address data for each record through a Web access engine;
3) the user takes advantage of his complete database as maintained by a
conventional database application, such as Filemaker Pro or another similar application, for the server to create the index; or
4) the user provides the data to an operator of the server service via voice phone call, and the service enters the data.
The user can then access geocoded data through a Web site. The position of the entries can be overlaid on a detailed map as icons definable by the user. The user can edit the data, creating qualities and preferences. The user can also enter data into a private area that is only accessible to the user through password protection. In some embodiments, the data may be set up to be inaccessible to the service operator.
The user can then make sophisticated queries to the service from the mobile device. For example, the user can scroll through the phone number list on his cell phone, select a person at a location (such as "Mike:Office") and a type of query, such as "Restaurant:Nearest" (nearest restaurant). The cell phone (or whatever type of mobile device is being used) then transmits a corresponding query signal to the server. In response, the mobile device receives a proximity search solution from the server. This solution may contain, in the above example, a list of restaurants near the selected entry, which may be sorted by direct distance or driving distance. The list may also contain value-added data, such as phone number, cuisine type, and rating. The value added data may be selected by the server based upon a stored user profile for that particular user.
The user can also request, from the mobile device, maps, driving directions or other route information from one location to another. If the mobile device is location-sensitive (such as a GPS-enhanced device), the mobile device can be used to calculate the origin for the search. Otherwise, the user can select the entry in his contact list to which he is nearest. The server service then provides verbal, graphical or textual directions (depending on the capabilities of the mobile device).
Thus, a user of a mobile device can quickly and easily obtain a variety of types of time- or location-dependent information from the mobile device. The information is generated at the server based on a comprehensive set of databases
derived from a variety of sources and is delivered to the mobile device in a form appropriate for that device. The user can access and edit portions of the databases via a conventional World Wide Web site to personalize the data.
Refer now to Figure 1, which illustrates a network configuration in which a mobile device 1 (shown as a cell phone) can be used to obtain location- or time- dependent information from a central server system 3, as described above. The mobile device 1 has a radio frequency (RF) to communication link with a cellular base station 6. The base station 6 is coupled to a public switched telephone network (PSTN) 5, and is further coupled to the Internet 4 via the PSTN 5. Also coupled to the Internet 4 is the server system 3, which provides the location- and time-dependent services described above. The server system 3 includes a geo- server 7 coupled to the Internet 4, and a Web server 8 coupled to the Internet 4 and to the geo-server 7. The server system 3 also includes a database 9 coupled to the geo-server 7 and database 10 coupled to the Web server 8. Also coupled to the Internet 4 may be a PC 2 operated by the user of the mobile device 1 (the customer). Of course, there may actually be multiple mobile device 1 and multiple PCs 2 in the network, associated with multiple users, although only one of each is shown to simplify description.
The Web server 8 provides the user with access to personal profile information (i.e. preferences, etc.), which is stored in database 10, and contact information which is stored in database 9. The user may access such information using the PC 2. The geo- server 7 provides the location- and time-dependent services described above, including indexing, geocoding, and route calculation, as described further below. Among other functions, three important functions of the geo- server 7 are: 1) returning spatial coordinates (latitude /longitude) to mobile devices 1 in response to contact-string queries; 2) providing solutions to POI proximity queries (i.e., a list of nearby POIs) from mobile devices; and 3) providing route information and /or maps to mobile devices.
Note that the geo-server 7 and the Web server 8 each may be implemented as one or more individual computer systems in communication with each other. Alternatively, geo-server 7 and Web server 8 may be implemented together as a
single computer system. Similarly, although databases 9 and 10 are illustrated as separate databases, the data contained therein may actually be stored in a single database, or in any number of separate databases.
Figure 2 is a block diagram of a computer system, which is representative of any or all of the processing systems shown in Figure 1, such the PC 2, the geo- server 7, and the Web server 8. Note that Figure 2 is a high-level conceptual representation and is not intended to specify any one particular architectural arrangement. As shown, the computer system includes a central processing unit (CPU) 20, read-only memory (ROM) 21, random access memory (RAM) 22, each connected to a bus system 29. The bus system 29 may include one or more physical buses connected to each other through various bridges, controllers and /or adapters, such as are well-known in the art. For example, the bus system 29 may include a "system bus" that is connected through an adapter to one or more expansion buses, such as a Peripheral Component Interconnect (PCI) bus or the like.
Also coupled to the bus system 29 are a mass storage device 23 and various input devices 24, 25, various output devices 26, 27, and a communication device 28. The input devices 24, 25 may include, for example, one or more of: a keyboard, a pointing device, a touch-sensitive screen, a speech recognition subsystem, etc. the output devices may include, for example, display device and audio speakers. Mass storage device 23 may include any suitable device or devices for storing large volumes of data in a non-volatile manner, such as a magnetic disk or tape, magneto-optical (MO) storage device, or any of various types of Digital Versatile Disk (DVD) or compact disk (CD-x) storage.
The communication device 28 may be any device suitable for or enabling the computer system 1 to communicate data with a remote processing system over a data link, such as a conventional telephone modem, a cable modem, an Integrated Services Digital Network (ISDN) adapter, a Digital Subscriber Line (xDSL) adapter, a network interface card (NIC), a Ethernet adapter, or the like.
Figure 3 illustrates the software and data components of a mobile device 1 and the server system 3, according to at least one embodiment. As shown, the
mobile device includes a database 31 of personal contacts, which may be stored in the format described above, i.e., {Name {location labels:phone numbers} }. The mobile device 1 further includes a data manager 32 for enabling the user to access the stored, data via a Graphical User Interface (GUI) of the mobile device 1, and a geo- client 33 operatively coupled to the data manager 32, for providing the client- side functionality described above (i.e., formulation and transmission of queries, etc.). The mobile device 1 further includes appropriate communication software 34 operatively coupled to the geo- client 33, for enabling the mobile device 1 to communicate with remote devices, such as other cell phones and the server system 3.
The server system 3 also includes appropriate communications software 46 for enabling it to communicate with other, remote devices, such as the mobile device 1 and/or the PC 2. Coupled to the communication software 46 is a location server module 45, which provides much of the core functionality of the server system 3 described above, including geocoding, POI lookup functions, and route calculation. The location server 45 may be implemented as an application program interface (API). The server system 3 further includes a Cell Storage Format (CSF) compiler 37, a number N of CSF databases 38-1 through 38-N, a data parser 39, a geocoding and routing indexer 40, a POI indexer 41, and databases 42, 43 and 44.
Map data supplied by N vendors are stored in databases 35-1 through 35- N, respectively. The map data of each vendor includes spatial data describing roads, streets, highways, freeways, etc., and political boundaries. The map data of each vendor further includes text data labeling the elements of spatial data. In addition to the map data, POI data supplied by a number M of different vendors are stored in databases 36-1 through 36-M. The POI data may include, for example, data on the locations of restaurants, parks, airports, hospitals, gas stations, or any other locations of interest.
The map data stored in databases 35-1 through 35-N is vendor-specific; for example, such data may be stored in any of a number of well-known formats, such as Geographic Data Format (GDF) or formats proprietary to the vendor.
Accordingly, the CSF compiler 37 receives the map data from the N vendors, which is likely to have various different formats, and reformats the data into a common format, referred to herein as CSF. CSF represents the map data using a multi-level matrix of rectangular cells. The details of the CSF are not germane for purposes of understanding of the present invention. The re-formatted data is stored in CSF databases 38-1 through 38-N.
Data parser 39 receives the reformatted map data from databases 38-1 through 38-N as well as the POI data from databases 36-1 from 36-M and parses the data into recognizable fields (e.g., name, address, phone number, etc.). The parser 39 also parses information received in queries from the mobile device 1. Parsed map data may be stored in database 42 as display data, which may be used by the server system 3 to provide a World Wide Web graphical map interface, as noted above. Parsed data from databases 38-1 through 38-N or databases 36-1 through 36-M are also provided to the geocoding and routing indexer 40.
The geocoding and routing indexer 40 indexes the parsed map data to allow it to be searched by name (e.g., "Oakland Hilton Hotel") or by phone number. The indexed map data is then stored in the geocoding and routing indexed database 43. Similarly, POI indexer 41 indexes the parsed POI data to allow it to be searched by POI category (e.g., ATM, airport, etc.) and stores the indexed data in POI indexed database 44. The data in the databases 42, 43, and 44 are all accessed by the location server 45 to provide geocoding, POI lookup, route calculation, and other functions.
Figure 4 illustrates the components of the location server 45 and the geocoding and routing indexer 40, according to one embodiment. As shown, the indexer 40 includes a spatial data indexer 51 and a text data indexer 52, each of which receives parsed data from the data parser 39. The spatial data indexer 51 indexes any spatial map data, while the text data indexer 52 indexes textual map data, such as labels. The location server 45 includes a route generator 53 and a geocoder 54. The route generator 53 uses the indexed spatial data generated by the spatial data indexer 51 to compute routes between selected points of origin and destination in response to a query from a mobile device 1. Such route
n
generation devices are well-known in the art and therefore need not be described further herein. The geocoder 54 uses indexed text data generated by the text data indexer 52 to determine spatial coordinates (latitude and longitude) associated with a given text field, in response to a query from the mobile device 1.
As noted above, geocoding is the process of returning spatial coordinates (latitude and longitude) given an input string. Geocoding is one service provided by the server system 3 to mobile devices 1. The server system 3 may perform geocoding in either batch mode or dynamic mode. Batch geocoding may be performed in response to the mobile device 1 being synchronized with the server system 3, or when the user enters personal contact information from his PC 2 via his personal Web page (as maintained by the Web server 8; see Figure 1). Alternatively, the server system 3 may perform geocoding dynamically, i.e., in response to a query received from the mobile device 1. Dynamic geocoding is performed if the information in the query (i.e., name, phone number, etc.) has not been geocoded (associated with spatial coordinates) prior to the query.
Refer now to Figure 5, which shows a geocoding process that may be implemented by the geocoder 54. T e process of Figure 5 is applicable to both batch geocoding and dynamic geocoding. At 501, the server system 3 receives a contact string. Of course, more than one string may be received, however, only one is assumed here to facilitate description. The contact string may be received from the mobile device 1 during synchronization or during a user query; alternatively, the string may be received from the PC 2 and Web server 8 in response to manual input from the user or from an operator. At 502, the input string is parsed into recognizable fields (i.e., address, street name, city, state, zip code, phone number, etc.) by the data parser 39 (Figure 3). At 503, it is determined whether spatial coordinates (latitude /longitude) for the name field of the contact string are stored in the central address book. The central address book is a subset of the geocoding and routing indexed database 43 (Figure 3). If coordinates are found in the central address book for the name field, the process continues from 506, as described below. If coordinates are not found for the name field, then at 504 an attempt is made to determine the spatial coordinates based on other fields
in the contact string, such as the address or phone number. This may be accomplished by, for example, performing a reverse look-up, by phone number, address, etc., in a database that includes spatial coordinates; such databases are commercially available. If the operation at 504 was unsuccessful, then at 509 a fail message is transmitted to the appropriate recipient device (which is not necessarily the device which submitted the query). If 504 was successful, and if the server system 3 was responding to a query from the mobile device (506), then at 507, the coordinates are transmitted to be appropriate recipient device (which, again, need not be the device which submitted the query)— this is the case of dynamic geocoding. If the server system 3 is not responding to a query (in the case of batch mode geocoding), then at 510, the server system 3 transmits a confirmation that the string has been successfully geocoded to the appropriate recipient device. Note that for purposes of batch geocoding, real-time location and /or traffic information may be used. Optionally, the server system 3 also transmits to the recipient device an index value corresponding to the input string, which a mobile device 1 can later use to represent the string during a query transmitted to the server system 3. Following 507, 509 or 510, if all input contacts strings have been geocoded, then the process ends; otherwise, the next contact string is input at 501, and the above process repeats.
As noted above, another service provided by the server system 3 is to provide the user of a mobile device 1 with a list of POIs that are in proximity to a selected point of origin, in response to an associated query. The point of origin may be the mobile device itself or an entry selected from the user's list of contacts stored in the mobile device 1. This process is referred to as POI lookup. Figure 6 is a flow diagram illustrating a point of interest (POI) lookup process that may be implemented in a client device, such as the mobile device 1. The routine of Figure 6 may be implemented by the geo-client module 33, in cooperation with the data manager 32 and communication software 34.
At 601, the user of the mobile device 1 enters an input selecting POI proximity query as the desired action. In response, at 602 the mobile device 1 establishes a point of origin for the POI proximity query. If the mobile device 1
has an internal positioning device, such as a GPS receiver, then such positioning device may be used to establish the spatial coordinates of the origin. Otherwise, the origin may be established by submitting a contact string lookup query to the server system 3 or by making a voice query to an operator of the server system 3. In the case of a contact string lookup, the mobile device 1 sends a query to the server system 3 using a selected item from the user's contact list in the mobile device 1. The query is then processed by the server system 3 in the manner described in Figure 5, resulting in spatial coordinates of the origin being returned to the mobile device 1.
After the origin is established, the coordinates of the origin are stored locally at 603, and at 604,the user enters an input selecting the desired type of POI, e.g., restaurant, airport, gas station, etc. At 605, the user selects a radius about the point of origin, defining an area within which he wishes POIs of the selected type to be identified. At 606, the mobile device 1 transmits a query to the server system 3, including the selected origin, POI type, radius, and a unique device code identifying the mobile device 1. The server system 3 then identifies any POIs within the specified radius of the selected origin, based on the coordinates of the origin. If at least one POI meets the criteria (607), then a list of POIs meeting the search criteria is returned to the mobile device 1 by the server system 3. If no POI meets the criteria, then (at the user's option) the procedure repeats from 605, in which the user selects a new, larger radius for the POI search. If the query was successful, then at 608 the user may select an item from the return list and initiate any of several available functions. The user may, for example, initiate a phone call from the selected POI, get directions to the selected POI, or update his personal database with the selected POI. Thus, at 609 the user is given the option of updating his personal database maintained in the server system 3 based on the item selected in the returned list. For example, the user may wish to identify the selected item as a "favorite" POI in his personal map database. If the user elects this option, then at 610 the selected item is stored locally in the mobile device 1 and propagated to the server system 3 at the next synchronization with the server system 3. The results of the action (e.g., "successful" or "unsuccessful") are then
displayed by the mobile device 1 to the user at 611.
Figure 11 illustrates a process that may be performed by an operator of the server system 3 in connection with performing an operator-assisted POI lookup (see Figure 6, 602). At 1101, it is determined whether the user is calling for registered phone number. If not, at 1109 the operator asks the user to provide the phone number of any nearby registered telephone. Next, at 1102 the operator obtains the user's Personal Identification Number (PIN). The operator's then obtains the desired POI type from the user at 1103, and that 1104 is determined whether the users location is known from the signal received from the mobile device which the user is using (such as when the mobile device has an internal positioning device). If the location is known, then the operator initiates the geocode process for the specified POI type and origin at 1105. If the origin is not known, then the operator determines at 1110 whether the user wishes to select the origin from his personal Web page maintained by the Web server 8. If so, the geocode process is initiated 1105. Otherwise, the operator verbally obtains the origin from the user at 1111. Following the geocode process at 1105, the operator determines at 1106 whether the user wishes his personal Web page to be updated with any POIs found in the geocode process. If so, the operator updates the users Web page 1107. If not, or following 1107, the operator transmits results to the user at 1108 using an appropriate mode, i.e., verbally via telephone, or electronically to the mobile device 1.
Another service provided by the server system 3 is to provide a best route solution in response to queries from mobile devices 1. Figure 7 illustrates a process that may be performed in a mobile device 1 to obtain a route calculation from the server system 3. At 701, the user enters an input at mobile device 1 selecting route calculation as the desired action. If (702) the user wishes to select the origin and destination from local data within the mobile device 1 (i.e., using an internal positioning device or a contact string query), then at 703, the origin is established using such technique. Otherwise the user contacts an operator of the server system 3 by voice and, at 708, the operator receives the origin and destination from the user. The operator enters the origin and destination data into
the server system 3, which computes the best route. At 707, the user receives the best route in an appropriate communication mode, depending on the capability of the mobile device 1. For example, the best route may be received verbally from the operator (by telephone), or in text and /or graphics generated by the mobile device 1 from a signal transmitted from the server system 3.
If operator assistance is not required or desired (702), the origin is established from an internal positioning device or contact string query, as appropriate. In that case, at 704 the coordinates of the origin are stored, and at 705 the destination is established by submitting a contact list query to the server system 3. At 706, the coordinates of the destination are stored, and at 707, the best route information is received by the user in an appropriate communication mode, as described above.
Figure 8 illustrates a process that may be implemented in the server system 3 to respond to a query from a mobile device 1. When the server system 3 receives a contact string query from a mobile device 1, the query may include the complete contact string (e.g., "Ginny:Office"), or the query may instead include a representative index value in place of the complete contact string. The index value may have been previously received from the server system 3 when the corresponding contact string was geocoded (see Figure 5, block 511). Accordingly, at 801, a query is received which includes a contact string or an index value representing a contact string. If the query contains an index value, then corresponding spatial coordinates are already stored in the central address book; accordingly, at 808 the coordinates are found in the central address book and transmitted to the appropriate recipient device at 807. If the query includes a complete contact string (802), then at 803, the contact string is parsed into recognizable fields. At 804, it is determined whether spatial coordinates are stored in the central address book for any field of the query. If so, the coordinates are transmitted to the recipient device at 807. If not, then at 805 an attempt is made to determine the spatial coordinates based on, for example, the address or phone number fields of the query. If a user profile is available for this user, it is also accessed at 805. If the attempt to determine spatial coordinates is successful (806),
then the coordinates are transmitted to the recipient device at 807. Otherwise, a fail message is transmitted to the recipient device at 809.
As noted above, the server system 3 may maintain personal profiles for the users of mobile devices 1 (user profiles). A user profile may be accessed in response to a POI lookup or route calculation query from a mobile device 1 to provide the user with information that is more meaningful to that user, i.e., information that is customized for the requesting user. For example, a user profile may include a list of preferences to be used for route calculation, such as "avoid freeways" or "always use shortest time route", or a list of favorite POIs, such as favorite restaurants. Accordingly, the server system 3 may maintain a list of unique device codes, each corresponding to a particular mobile device 1 and /or a particular user. Each mobile device 1 may transmit its unique device code with any query it transmits to the server system 3. Accordingly, the server system 3 can use the received device code to identify and use the appropriate user profile when responding to the query.
Figure 9 illustrates a process that may be implemented by the server system 3 to perform a POI search or a route calculation using a user profile. At 901, it is determined whether the selected action is a POI lookup or a route calculation. If the selected action is a POI lookup, then at 902 a POI query is received containing an origin, POI type, radius, and the unique device code of the requesting device. At 903 it is determined the server system 3 has a user profile corresponding to the received device code. It may be assumed, for this purpose, that the user of the device is the registered user. If a user profile is available for this device code, then at 904 the server system 3 performs a POI search based on the user profile, and the received origin, POI type, and radius. Otherwise, at 905, the search is performed based on that same data, excluding the user profile. Similarly, if the selected action is a route calculation (901), then at 906 a query is received containing an origin, a destination, and a unique device code for the requesting device. At 907 it is determined whether a user profile is available based on the device code. If so, the route is computed based upon the user profile, the origin, and the destination at 908. Otherwise, at 909 the route is computed based upon the same data, except
the user profile.
A query transmitted from a mobile device 1 to the server system 3 may specify a recipient device for the response that is not the querying device. For example, the user may wish to transmit a route calculation query from his cell phone, but desires that the route solution be transmitted to his automobile navigation system. The user may, for example, program the recipient device into the mobile device 1 prior to making the query. Accordingly, the server system 3 is configured to identify such a recipient code and to appropriately select the recipient device for the response, based on such code. The server system 3 may use its above-mentioned database of device codes for this purpose, or it may maintain a separate database of recipient device codes.
Figure 10 illustrates a process that may be implemented by the server system 3 to select the recipient device. At 1001, it is determined whether the currently received query contains a recipient code indicating a destination other than the transmitting device. If so, the server system 3 performs a simple lookup at 1002 to identify the recipient device based on the code. Otherwise, at 1003, the recipient device is determined to be the device which transmitted the query.
Note that a response by the server system 3 to a query may be transmitted to the recipient device asynchronously with respect to the query. That is, there is no time limit between a query and the associated response. Hence, the response may occur much later than the query, if necessary, and as already noted, the response may go to a recipient device other than the querying device. Hence, if the server system 3 is unsuccessful in contacting the intended recipient device to send the response (such as when the intended recipient device is turned off), the server system 3 may continue to attempt to respond until successful. Alternatively, the server system 3 may select an alternate recipient device, which may be specified in a user profile.
Thus, a method and apparatus for providing navigation assistance and other services to a user of a mobile processing device have been described. Although the present invention has been described with reference to specific exemplary embodiments, it will be evident that various modifications and changes
may be made to these embodiments without departing from the broader spirit and scope of the invention as set forth in the claims. Accordingly, the specification and drawings are to be regarded in an illustrative sense rather than a restrictive sense.