HK1126551A - A buddy system for navigation devices - Google Patents

Abstract

A buddy system for navigation systems is disclosed. Further to the buddy system, a user of a navigation device can locate other navigation device users within a select vicinity. The buddy system further includes buddy lists compiled from a number of navigation devices grouped according to a common characteristic. The characteristic may be a relationship among the users of the navigation devices, the location of the navigations, and the like. The navigation systems are listed within buddy lists according to identification and geographical location. The navigation systems, with buddy lists stored therein, may be made to navigate towards a select buddy. In addition, further to the buddy system, one navigation system can communicate with another via text and voice messages.

Description

Buddy system for navigation device

Priority declaration

The present application claims priority herein to each of the following uk patent applications in accordance with 35 u.s.c. § 119: 0604709.6, filed on 8/3/2006; 0604708.8, filed on 8/3/2006; 0604710.4, filed on 8/3/2006; 0604704.7, filed on 8/3/2006; and 0604706.2, filed on 8.3.2006, the entire contents of each of which are hereby incorporated by reference.

Technical Field

The present application relates generally to the field of navigation systems, and more particularly to a buddy system for a navigation system, an arrangement for operating the buddy system with a navigation system, and a navigation system configured to carry out operations on the buddy system.

Background

A navigation system, as used herein, refers to a device that enables a user to navigate from a current location to a destination location. The navigation system may be arranged to provide user output in the form of a displayed map on which arrows or other markers indicate appropriate routes between the current location and the destination location. The map may be refreshed based on the current location, as determined by appropriate satellite, GPS, and/or internet connections, for example. Accompanying the refreshing of the map, the visual indicia regarding the appropriate next step along the route between the current location and the destination location is also refreshed. Alternatively, map refreshes may occur over time. Other user outputs may include voice guidance made in conjunction with or independent of the map display. One common voice command may be to make a particular turn at an upcoming intersection.

The navigation system may include an internal processor in communication with an internal memory, a communication component, a power component, and a display. The processor may include software or other programming to effect the generation of the maps and user output described above. The internal memory may include map data, which the process may utilize. Further, the processor may be arranged to communicate with a remote server via the communication means. The server may be a dedicated or non-dedicated server having standard communication means for direct and/or wireless communication.

The navigation system may further be arranged to receive user input via a touch screen, buttons, voice activation, etc. The processor may be further programmed to receive user input, determine the current location via GPS or the like, and display the current location on a map obtained from the memory. Furthermore, once the destination location is available, the processor may be programmed to determine a selected and/or optimal route between the current location and the destination location and further output, such as an optimal route, via a series of output voice commands in conjunction with a refreshed map display.

Current navigation systems come in a variety of forms. One form (personal navigation device) may be hand-held or otherwise portable and/or may be embedded in a motor vehicle such as an automobile, boat or airplane. Among the many features of navigation systems, one is the ability to route a user to a particular destination location or point of interest (e.g., the next gas station, favorite restaurant, etc.). Such destinations are geographically static and are typically known in advance. For example, a user may pre-program their device to identify a favorite bar in advance of beginning to rush to the bar. After leaving towards the bar, the user only needs to enter the name or location of the bar.

A common functionality lacking in navigation systems is the ability to route a user to a mobile destination location. Furthermore, another lacking functionality is the ability to locate other navigation system users. This functionality answers, for example, "where do i wife? "," where do my colleagues? "or" where do my friends? "and the like are particularly useful when there is an important problem. Such problems are becoming more and more important not only in personal situations where friends or family are met, but also in professional situations where head offices try to locate colleagues currently on the road, such as delivery vehicles, taxis, etc.

Disclosure of Invention

The present invention is therefore directed to the aforementioned unaddressed need in the art to provide for positioning, navigation, and/or communication to other navigation system users. The inventive system for this provision is referred to herein as a buddy system. The invention is accordingly directed to the buddy system, which is a system for providing a buddy system and a navigation system programmed or otherwise arranged to implement the buddy system.

The buddy system is essentially a system by which one navigation system can locate a selected other navigation system. The instant buddy system provides the user with the functionality to select a user of the navigation system according to a predetermined commonality of the selected user. For example, the buddy system enables one user to locate other navigation system users or buddies in a particular location, i.e., all buddies located in or around point x. The position of the partner relative to point x may change. Further, the buddy system provides for locating selected buddies belonging to a particular professional organization, i.e., selected (or all) taxis in a larger metropolitan area or selected (or all) delivery trucks currently in operation regardless of location, etc. The location of buddies may also be limited to friends, family, etc., i.e. the location of one's children. The groupings of partners may of course overlap and may include more than one of the categories mentioned above. These and other groupings of partners are described in detail below.

To implement the foregoing grouping, a predetermined buddy list is created. Once implemented, identification and location of buddies on the buddy list may occur. Since the buddy is also a user of the navigation system, the buddy list may further include the geographic location of the navigation system, and thus include buddies using the located navigation system. Since navigation systems are often used by users in motion, buddy lists may be periodically refreshed or updated to remain current.

Once located, the requesting user may wish to navigate toward and communicate with one or more buddies on the buddy list. The communication may take the form of voice or text communication. The buddy system is thus further directed to carrying out this and related functionality.

The present system for implementing a navigation system includes a dedicated server in communication with one or more navigation systems. The system may emulate a known client-server architecture with additional features and functionality to implement an instant buddy system. Other suitably configured client-server systems, i.e., dedicated and/or non-dedicated servers, may be employed in addition to or in place of the dedicated servers. Navigation system to navigation system communication may be accomplished via a peer-to-peer configuration or via dedicated and/or non-dedicated servers.

The invention is further directed to a navigation system for implementing a buddy system. The instant navigation system may include a processor programmed to achieve the functionality described above. Furthermore, the instant navigation system comprises input/output means for exchanging information with a user. Such input/output means may include a touch screen, speaker/microphone, buttons, lights, etc. with appropriate support functionality, located within the navigation system itself and/or remotely located on at least one of the aforementioned dedicated and non-dedicated servers, remote computers, remote navigation systems, etc. With the aid of a suitably programmed processor, the user may be prompted with a series of graphical interfaces in order to manually enter the desired functionality. The input may be manual, voice activated, etc. The desired functionality may include the aforementioned buddy location, buddy list creation, navigation towards the buddy, communication with the buddy, and the like.

The system of the present invention is still further directed to a method for implementing the aforementioned navigation system.

Although described above in the form of a navigation system, applications of the buddy system of the present invention are not limited to navigation systems and may include implementation on portable or desktop computers, personal digital assistants, mobile phones, and any other device that includes at least the above-described elements and functionality.

Drawings

The application will be described in more detail below by using example embodiments, which will be explained with the aid of the drawings, wherein:

FIG. 1 depicts an instant buddy system by means of a first navigation system querying the location of another navigation system;

FIG. 2 is a flow chart depicting a method for implementing the buddy system of the present invention on a navigation system;

fig. 3-12 depict a series of screen shots that may be presented to a user to implement the buddy system of the present invention on a navigation system.

Detailed Description

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

In describing the exemplary embodiments illustrated in the drawings, specific terminology is employed for the sake of clarity. However, the disclosure of this patent specification is not intended to be limited to the specific terminology so selected, and it is to be understood that each specific element includes all technical equivalents that operate in a similar manner.

Referring to the drawings, wherein like reference numbers refer to the same or corresponding parts throughout the several views, exemplary embodiments of the present patent application are described below. Like numbers refer to like elements throughout. As used herein, the term "and/or" includes any and all combinations of one or more of the associated listed items.

The invention will be discussed with respect to a Portable Navigation Device (PND), and it will be appreciated that the invention can be applied to any navigation system or other device that includes the functionality discussed herein.

Fig. 1 depicts a typical client server arrangement 15 comprising a server 10 in communication with a general user 14, a tablet computer 12 and a Personal Navigation Device (PND) 16. Each of the foregoing devices includes communication means arranged to facilitate communications 18 with the server 10, which are known in the art and not depicted in the figures. Further, each may include input/output means for exchanging information with a user. Such input/output means may include a touch screen 17 on which touch screen 17 is displayed a map 19 and touch-input user commands, as depicted on the personal navigation device 16. The touch screen may further be used to display a graphical user interface (described in detail below) that prompts user commands. Other input/output means include: speaker/microphone settings for receiving and broadcasting voice commands; buttons for receiving touch prompts and/or displaying prompts by flashing or the like; and other input/output means as would occur to those skilled in the art. The present invention is not limited to the number or type of clients interacting with the server, and the aforementioned general users, tablet computers and personal navigation devices are depicted by way of non-limiting examples.

The server includes a buddy list 11 consisting of a plurality of buddies 13. As will be described in detail below, the partners may be selectively organized and identified by either or both of identification and geographic location. The server may be a dedicated or non-dedicated server. The server may be a standalone server or part of a larger network. Communication with the server may be accomplished in a manner known to those skilled in the art. The present invention is not limited by the client server architecture and the type of client or server.

Because the buddy list may be populated by buddies within a particular radius belonging to the requestor, the server may maintain a master list of available buddies and their current locations. Thus, as will be described in detail below, a user may be required to allow publishing of their current location when registering with a buddy system. Moreover, the server further comprises processing means operable to calculate a current requester location, apply a particular geographic radius to the current location, and select buddies within that radius from among the possible buddies (other criteria may also be used).

Fig. 2a to 2c depict a flow chart depicting a method for implementing the buddy system of the present invention on a navigation system. The depicted method emphasizes the interaction between the device and the user, including enabling user selection of particular functionality. The invention is not limited to the particular depicted order. The method will be discussed with respect to application on a Personal Navigation Device (PND), and it should be understood that the method of the present invention may be applied to any client. Method steps will be discussed below with screen shots depicting icons for implementing the discussed method steps.

The top menu may include the map 19 depicted in fig. 1. Tapping the map or otherwise interacting with the PND will cause the main menu to appear. The buddy system of the present invention may be part of the typical functionality provided by navigation software, which appears as one of many main menu icons. Alternatively, the buddy system may be an additional system provided in addition to the main functionality. This is supplied by the assignee thomson under the name "PLUS".

When part of the PND-the buddy system first becomes visible via, for example, the main menu icon depicted in figure 3. Fig. 3 depicts a top level icon 300 introducing buddy functionality to a user. The functionality may be part of a navigation software package for a navigation system or additional software to an existing package in an enhanced form. Activating icon 300 causes the buddy system menu to appear. The activation may also correspond to the start 20 of the flow chart of fig. 2a to 2 c.

In a first step 22, a buddy list request is sent by the PND to the server before or at the same time as the buddy system menu is displayed.

The buddy list includes groupings of navigation device users based on pre-existing relationships set by the users. The buddy list includes the user's username and/or current geographic location. A depiction of a buddy list is set forth below. The buddy list is maintained by the central server and periodically refreshed. As will be described in detail below, the user may selectively refresh the downloaded buddy list saved on their PND. As set forth above, the different categories or groupings of buddies may be based on relationships with the user (e.g., family, profession, etc.) or random (e.g., any other buddy system user). The buddy list may be further limited by geographic location, such as a selected radius relative to the current or selected location.

In step 24, the server transmits the requested buddy list to the PND.

In step 26, the PND creates a local mask/worklist of buddy lists.

In step 28, the server registers the client's request. The above steps may occur automatically without the user directly knowing.

The following queries are depicted as icons in the first of two buddy system menus. The particular pictorial depictions and corresponding text may vary from application to application and are depicted in the figures only as example icons. A first buddy system menu 400 is depicted in fig. 4, which includes a plurality of icons corresponding to the queries discussed below in connection with the flow chart.

Returning to fig. 2a, in step 30, the user is asked whether he contains his name and geographical location in other buddy lists stored on the server, or whether he wishes to remain anonymous. Icon 440 of fig. 4 corresponds to this query. If the user wishes to remain anonymous (32), it will appear to other users that their device has been turned off. The icon 440 may further be caused to change, thereby indicating that the user is hiding their identity and location. Such an icon may include a fork depicted in fig. 4 through the icon. The unavailability of the user is achieved by sending a set status/unavailable message from the user PND to the server. The results returned by the server are processed appropriately.

If the user decides to include their name in the list (34), the appropriate buddy list stored on the server will be updated with the user's information in step 36. This will be done by sending a set status/available message from the user PND to the server. The results returned by the server are processed as will be described in detail below. Thereafter, the first buddy system menu 400 of fig. 4 will be displayed to the user.

In addition to the foregoing, the user may be asked if he or she wishes to employ a special name that will be used in place of the generic device identification. If this selection is made, the server will store the name of the user's personal selection. Furthermore, if the buddy list requested from the server is empty, the "hide your location" icon (see below) will be darkened.

Following the first buddy system menu, the user is presented with additional options including: guide trip 38 (icon 432), display buddy's location on map 40 (icon 434), update now (buddy list) 42 (icon 436), invite new buddies to join buddy list 44 (icon 438), proceed to second menu 46 (icon 438), and complete 48 (icon 440). First buddy system menu 400 may include other displayed information including current time 442, an indication 444 of when the last update was performed, and an indication 446 of which of the two buddy system menus is being displayed.

Returning to fig. 2a, if the "guide trip" option (38)50 is selected, the PND user is provided with a guide trip 52 of the buddy system. The guided tour may comprise a multimedia tour that includes visual and verbal feedback to the user. The trip may further be indicative and interactive. The software for implementing and implementing the guided tour may be stored locally on the navigation system, or remotely on a server or the like and downloaded as the user interacts therewith. The details of the journey are a design issue.

The query and/or option may be made or selected via an instance of pressing a button on the PND display. Other user input means include voice activation, buttons, etc.

Returning to fig. 2a, if the "show buddies" option (40)54 is selected, a map view (500, fig. 5)55 is displayed on the PND's display, the map depicting the location of the particular buddy in question indicated thereon, with the exact current location (known to the server) highlighted with a marker. An additional step may be to notify the displayed buddy that the user has requested to obtain his location. For example, a map is depicted on the PND of fig. 1.

Fig. 5 depicts an example map view 500 of amsterdam, on which is depicted a particular buddy of interest (502) 504. The map view includes other functionality, including: find 504, option 506, and complete 508; which will be discussed in more detail below.

Returning to FIG. 2a, the "update now" option 42 (icon 436, FIG. 4) actually includes two options: the "update now" option and the "update or update buddy" option. Alternatively, the "update buddy" option may be presented by a single query or icon (as is the case in step 74). When the "update now" option (42) or the "update buddy" option (74)58, respectively, is selected, the server is requested by means of a refresh message to update the identity and location 60 and 62, respectively, of the person on the received buddy list. Process 62 will be discussed in more detail below. The server returns the results are processed and a first menu screen or buddy list is presented to the user on the user's PND display. Following the update now option 42, the server retrieves the current status and the last known geographic location (when available) of all buddies on the buddy list.

Fig. 6 depicts a typical buddy list 600. As depicted, the buddy list includes a plurality of buddies 602 identified by email addresses 604 and buddy icons 606. Further to the present invention, each buddy may be identified by a particular icon having a particular importance. Different buddy icons are depicted in fig. 7. Buddy list 600 further includes a time indication 608, a title 610, and three options: seek 612, update 614, and cancel 616. Following the "find" option 612, the user is presented with an interface to locate a particular buddy from the buddy list via a search function, which is known in the art. The update function 614, once activated, updates the buddy list with the most current information available about the buddy, which originates from the user's PND or server. Cancel function 616 closes the buddy list and brings the user back to the first buddy system menu or the PND's main menu.

Fig. 7 a-7 e each depict one buddy icon. The icons may be color coded for easier identification. First buddy icon 702 is used to indicate that the corresponding buddy is available and that its location is current. By "current" is meant that the time elapsed for the location is less than 15 minutes. Alternatively, other time definitions for the current may be applied. Since this buddy is current and available, its location can be seen on the map (e.g., 502, fig. 5).

The second buddy icon 704 is used to indicate that the respective buddy is available although the buddy's location is outdated. In other words, the location of this buddy is previously known, but has become disabled thereafter. The time elapsed for the failed location may be 15 minutes to 60 minutes. Alternatively, other time definitions may be applied. This buddy may still be depicted on the map.

The third buddy icon 706 is used to indicate that the buddy is available despite its long elapsed time (i.e., over 60 minutes). Here again, the time may vary with the application. This buddy may still be depicted on the map.

Fourth buddy icon 708 is used to indicate that the buddy is unavailable and the server is waiting for a reply to invite the buddy to join the buddy list. This buddy has not yet responded to the invitation to become a buddy. Thus, this buddy or potential buddy is only visible on the buddy list.

The fifth buddy icon 710 is used to indicate that the buddy is unavailable and that the buddy's location cannot be determined because the buddy has declined the invitation to become a buddy. In addition, a buddy may have deleted the user from its buddy list.

The server may retrieve information from a database, the maintenance of which may be performed by the server or even by processes known in the art. Further to the "update buddies" option 74, the server is caused to actively request that a particular buddy return its current geographic location via a push channel or the like. The following interactions occur based on the status of the partner of interest. Updates may also occur from buddy list screen option 614.

If the buddy state is "unavailable/unknown," a message may be displayed to the user along the following lines: tomtomtom buddies, < name > not a PLUS user-PLUS is an enhanced service available to the navigation system of tomtomtom, the assignee of the present application, which includes the buddy system of the present invention. Other languages may be used to indicate that the requested partner is not a member of the partner system.

If the buddy state is "unavailable/deleted" (i.e., the buddy has deleted the user from the buddy list), a message may be displayed to the user along the following lines: "tomtom buddy, < name > you have deleted from their buddy list".

If the buddy state was originally "unavailable/invited" and is now "available" (i.e., the buddy has accepted the user's invitation to make it a buddy), then a message is displayed to the user along the following lines: tomtomtom partner, < name > has agreed to become your partner.

If the buddy state was originally "unavailable/invited" and is now "unavailable/declined" (i.e., the buddy has declined the user's invitation to have it as a buddy), then a message is displayed to the user along the following lines: tomtomtom buddy, < name > has been rejected as your buddy.

If the buddy state is "invited/reply-to-invite" (i.e., buddy has invited the user to become a buddy), then the user is presented with the following text message: tomtomtom buddy, < name > you have been invited to become a buddy. The user is further presented with a pair of buttons for accepting or rejecting the invitation. If the user chooses to accept, a reply invite/accepted message is sent to the server. If the user declines, a "reply invite/declined" message is sent to the server.

At the server, in response to the reply invite/accepted message: the status of accepting the buddy in the buddy list of the inviting buddy changes from "unavailable/invited" to "available"; change the status of the invitation buddy entering the buddy list of the recipient buddy to "available" (formerly "invited/reply invitation"); in response to the reply invite/denied message-change the status of the rejecting buddy in the buddy list of the inviting buddy to "unavailable/denied"; deleting the inviting user from the buddy list of the rejecting buddy; and updates the local buddy list.

Updating the buddy list may be done automatically at a time delay set by the user. This may be set manually by the user when making changes to the buddy preferences 64. If 66 is done, the user is presented with the update screen 800 depicted in FIG. 8. According to fig. 8, the user is presented with text 802 indicating an automatic buddy list update mode and a check box 801, the check box 801 being checked when the automatic update mode is performed. In addition, the update screen 800 includes a time indication 804 and a title 806. The user is further presented with an option to end the function (done, 808), which brings the user back to the first buddy system menu. If the checkbox 801 is unchecked, a second update screen is displayed to the user, which includes a numeric editor 900 (FIG. 9) that facilitates the user entering a select time delay 907 in minutes between updates. The editor 900 further comprises: a return function 902; cancel function 904, which brings the user back to the first buddy system menu; and a done function 906, which brings the user back to the first update screen. Like the first update screen, the second update screen contains a time indication 908 and a title 910.

Returning to FIG. 2a, if the "invite new buddy" option (44)58 is selected, the user identifies a particular buddy and requests the server to add the identified buddy to the user-specified buddy list 62. To enable identification of new buddies of the buddy list, the user is presented with a standard letter editor screen 1000, fig. 10 containing alphabetic characters along with a cancel option 1010 and a complete option 1012. The new partner may be identified by an email address 1014 or other identifier. To effect the addition, an invite message is sent by the user PND to the server and the results returned by the server are processed. Thereafter, the buddy or the first menu is displayed again. As with the above screens, the letter editor screen contains a clock 1016 and a title 1018.

On the server side, a determination is made whether the user is present and otherwise available or known. If the user's status is available, the user is added to the buddy list by means of the invited/reply-to-invitation step. The intended buddy is notified of the invitation with a message notification, which may be personalized by the user or may comprise pre-composed text available from memory and automatically sent as part of this step. If the buddy is unknown, the buddy state becomes "unavailable/unknown" and the user is notified of this. If the user is unavailable, the buddy state becomes "unavailable/invited" and the user is notified of this. If the buddy is available, the buddy state becomes "available".

The server may further contact the identified buddy and query him for permission to add it (with or without the current location) to the user-specified buddy list. Alternatively, the foregoing steps may be performed without confirmation or input of the identified partner.

Returning to FIG. 2a, if further to option 48, the user chooses to exit buddy system 66, the user exits buddy system 68 and returns to the map view or main menu of his PND.

If a move to the next menu (40)62 is selected, the first menu will be replaced with a second menu presenting options with additional options as described below. As with the first menu, each of the second menu queries may be presented on one screen at the same time. An alternate number of queries may be presented depending on programming, screen size, etc. The present invention is not limited by the number of graphical user interface queries presented on any one screen at any one time.

If further to option 46, the user chooses to proceed to the next buddy system menu 70, the user is presented with a second buddy system menu 1100 as depicted in FIG. 11. Fig. 11 includes a series of icons associated with the method steps set forth in fig. 2 a.

Returning to FIG. 2a, the user is presented with a series of queries or options (via icons of the second buddy system menu 1100), including: send message 78 to buddy (icon 1102); change buddy preferences 64 (icon 1110); delete buddy 72 (icon 1104); update buddy 74 (icon 1108); and read message 76 (icon 1106). The user is further provided with the option to proceed back to the previous menu 80 (icon 1112) and end 81 (icon 1114).

If the "send message to buddy" option (78)82 is selected, a send message to buddy sub-screen/menu screen 1200 is displayed to the user, which is depicted in FIG. 12 and the process continues 84 in FIG. 2 b. The user is presented with several options or queries, including: send message 88 to buddy (icon 1204); send location 90 to buddy (icon 1202); send your location 92 to buddy (icon 1206); and completion 86 (icon 1208).

If send to buddy message 88 (icon 1204, FIG. 12)98 is selected, the user's PND transmits a message to selected buddy 104. The message may comprise text, voice, images, combinations thereof, and the like, and may be transmitted via a server or peer. The message may further be a pre-stored message stored within the server and available for transmission upon request by the user on the PND. Details of the general exchange of messages are set forth below.

If the "send location to buddy" option 90 is selected, the user selected geographic location 106 is transmitted along the same line as the above message to the buddy in question. An example message 1300 is depicted in fig. 13. The message includes text identifying the selected geographic location 1302 and the GPS location 1304 for that location. The message further includes two options, namely advancing to navigate to menu 1306 and returning to the main map or main menu 1308 of the PND. The message may further include a time 1310 and a title with an indication 1312 of the sender and its phone number.

The buddy must have an "available" status and therefore the buddy list that can be the subject of sending a message can be defined in advance by the PND to only those buddies that have an available status. A send buddy location screen may further be displayed to the user in conjunction with this option, the send buddy location screen including a GPS icon that facilitates location determination. Selection of the GPS icon brings up a location menu screen through which the location may be selected or otherwise entered. One possible location is the current location of the user. Once a location is selected and entered by the user, a "send location" message is sent to the server. The message may comprise predetermined explanatory text or personalized text. And processing a result returned by the server, and displaying a first menu to the user.

Upon receipt at the buddy's navigation device, the transmitted geographic location may be displayed as text and/or as a location on a map. The user-selected geographic location or address may be created by: typing alphabetic characters from the displayed alphabet; indicating the location on the displayed map by touch, or by other input means. This may be provided via a location selector in the text message. The now entered location is converted to a message and transmitted either via a server or directly to the buddy's navigation system.

If the user chooses to send the buddy's current location 94 per step 92, a request 108 for the buddy's current location is sent from the PND to the server. The server then locates a record corresponding to the current location of the buddy (which may be available according to a refreshed buddy list, or may be obtained automatically or by permission of the buddy), and transmits the location to the PND, which in turn displays the location as text or indicia on a map. An example of a map depicting a buddy is set forth in fig. 5.

If the cancel option (86)100 is selected, the method proceeds 102 back to the previous menu. Alternatively, the method may proceed to an end.

Returning to fig. 2a, if the "change buddy preferences" option 64 (icon 1110, fig. 11)110 is selected, a change buddy preferences screen (discussed above) is brought up and displayed on the user's PND display 84. Following this screen, the user is provided with the option of selecting an automatic update to the buddy list from the server, including the name of the current buddy (i.e., the buddy for which the navigation device has been currently activated and has agreed to be part of the buddy list) and the current buddy's current location, again obtained from the buddy navigation system as described above. Following the additional automatic update buddy list screen, the user is presented with the option of selectively updating the buddy list every several minutes, which may be 1 minute to 99 minutes. To facilitate entry of the update interval, the user is presented with a series of numbers 1 through 9 along with options to cancel, complete, and go back to the previous menu (as will be described in detail below). In accordance with the update to the buddy list, the user's PND will be caused to forward the user's current identification and geographic location to the server for inclusion in the appropriate buddy list.

If the "delete buddy" option 72 is selected (icon 1104), the user is presented with text requesting confirmation of the deletion. The text content may be "do you determine to delete < name >? ". Other text may be used by design choice. The user is further presented with a selection option of "yes" and "no". This option may be a button, icon, voice activated means, etc. If the user selects "yes," the buddy is deleted from the local buddy list (stored on the user PND or remotely), a "delete buddy" message is sent to the server, and the results returned by the server are processed. At the server, the buddy to be deleted is removed from the user's buddy list, the status of the deleted buddy is set to "unavailable/deleted", and the buddy list is displayed to the user on their PND display. Likewise, the user is deleted from the buddy list belonging to the now deleted buddy.

If the "update buddy location" option 74 (icon 1108)58 is selected, all buddies with an "available" status are determined and a "get location" message is sent by the user's PND to the server — the location is the location 62 of the available buddy. The results returned by the server are processed and a first or buddy menu is displayed to the user. At the server, if the status of the intended buddy whose location is being updated is "available," a "provide location" message is sent to the intended buddy (e.g., via a "push"), and the buddy returns its current location. The buddy location on the server is further updated.

If the user selects read message 118 per "read message" option 76 (icon 1106), the user is presented with text message 120. The text message 120 may include the location and identification of the user, as will be described in detail below with respect to fig. 13. Following the message displayed in step 120, the user is presented with an additional options step 122 set forth by the flow chart of fig. 2 c.

As depicted in fig. 13, message 1300 includes location 1302 and buddy identification 1304, which is presented here as text. Other message formats may be used, including pictures, sounds, and other media, as will occur to those of skill in the art. The message 1300 further includes an indication 1310 of the sender displayed therein. The sender may be identified by name and telephone number. As depicted, the message 1300 is sent by john (1310), having telephone number + 31653354300. The current time may also be displayed 1312. The exact presentation of sender information and time is a matter of design choice. Alternatively, other related information may be displayed within the message, including: current date, personalized sender identification, etc.

Pursuant to message 1300, the user is presented with an exit message (done) option 1306, which if selected exits the buddy system functionality and returns to the main map display or other high-level display. Following message 1300, the user is presented with an option 1308 which, if activated, brings up a navigation screen menu 1400 depicted in fig. 14, which corresponds to the flowchart of fig. 2 c.

Returning to FIG. 2c, the user is presented with several options, namely: navigate to this 126 (icon 1402, FIG. 14), display on the map 128 (icon 1404, FIG. 14), add as favorites 130 (icon 1406, FIG. 14), and cancel 124 (icon 1410, FIG. 14). The aforementioned options operate in conjunction with the possession of the buddy address.

If the user further selects cancel 138 for cancel option 124, the method branches back 140 to the second buddy system menu, the screen shot of which is depicted in FIG. 12.

If the "navigate to here" option 126 (icon 1402, FIG. 14)136 is selected, the user's PND will effect navigation to a particular geographic location 132. First, the user will be queried 148 for a particular time of arrival step (1500, FIG. 15). If the user selects a particular arrival time (1502, FIG. 15)166, a route to the buddy location is calculated by the PND software that will achieve the arrival at the time desired by the user. Likewise, if the user does not select any particular arrival time 168(1504), the optimal route 156 will be calculated. The implementation can be carried out in the following way: the optimal route from the user's current location to a particular geographic location is determined, which may be carried out by suitable navigation software, such as NAVCORE software from thomson, the assignee of this patent. The optimal route may be displayed on the user's PND and assisted by voice commands and the like.

If the user has selected to display the buddy location 134 on the map in accordance with query 128, the PND is caused to decipher and display (step 144) the buddy location that may have been received in accordance with the earlier query on the map depicted in FIG. 5. Before the display, it is confirmed that the status of the buddy for display is "available". If "available," buddy information is retrieved from the local list and displayed on the PND. The display may include a specific icon 502 (fig. 5) for emphasis. The user is presented with the option of returning to the main map display or main menu by selecting icon 508. A route from the user's current location to the buddy may be calculated by activating find icon 504. Similarly, the aforementioned navigation menu options step 122 (FIG. 2c) may be entered by activating icon 506.

If the user selects to add a buddy location to his favorite 132 as per option 130, the PND is caused to store the particular location in memory 146 via entry of the buddy identification as per the letter editor screen depicted in figure 10 and discussed above. If the entry already exists in the favorites list, the user will be provided the option to replace the existing entry, as depicted by screenshot 1600 in FIG. 16 (query 150, FIG. 2 c). Such messages may be flash messages. Screenshot 1600 includes a "yes" option 1602 and a "no" option 1604. In the event that the user selects to replace (154, FIG. 2c), the previous entry (156, FIG. 2c) for the same location is replaced with the new location within the favorites list. If the user chooses not to replace (158, FIG. 2c), the step ends and the user is presented with a screen 1700(152, FIG. 2c) providing him with the option of setting the current location as the home location. Screen 1700 contains a yes option 1702 and a no option 1704. If yes option 1702(160, figure 2c) is selected, the PND is caused to change the current home location to the location depicted on screen 1700 (162, figure 2 c). If the user chooses not to replace the current home location (164, FIG. 2c), the user is taken back to the navigation screen 1200(140, FIG. 2c) depicted in FIG. 12.

In the event the cancel option 118 (icon 1214, fig. 12)138 is selected, the previous menu 116 is depicted or the method ends.

Returning to fig. 2a, if the user selects to proceed to previous menu 83(1112, fig. 11) as per option 80, the method transitions back (step 102) to the first buddy system menu depicted in fig. 4. If the user selects completion 85(1114, FIG. 11) per option 81, the method ends (step 160).

The general message exchange with the server will now be discussed, and the data managed by the server will also be summarized.

All messages sent by the client to the server contain the following elements:

self status: available or unavailable "

If the status is "available", then the current location of itself is included; otherwise it is empty

All responses of the server to messages sent by the client contain these elements:

buddy item List

There are 2 communication paths between partners. One is the partner client-server messaging protocol and the other is text messaging. Partner client-server message protocols encompass requests such as "add partner," "remove partner," "update," and the like. The response received from the server is the result of a user manual action, selecting a menu icon. The server response may result in a notification dialog being displayed on the client. Text messaging encompasses plain text, which may contain a location recognized by an application. These text messages may be read as general text if they are received on a device that does not interpret them correctly. The message may be entered manually. It does not matter whether the message originates as an SMS, server message or buddy message. The visual notification referred to is an indication that a text message has arrived (AFAIK, which is a general message transfer functionality). When a user is invited to become a buddy (i.e., when it receives an "add buddy" request), the server sends a prerecorded text message.

Claims (20)

1. A server comprising means for communicating a buddy list to at least one navigation device.

2. The server of claim 1, wherein the buddy list comprises a name and a location of at least one navigation device.

3. The server of claim 2, wherein the buddy list comprises at least one navigation device having at least one selected characteristic.

4. The server of claim 3, further comprising means for at least one of: grouping the characteristics, updating the characteristics, and storing records relating to the characteristics.

5. The server of claim 4, wherein the characteristics comprise at least one of: location, interests, activities, occupation, and interpersonal relationships.

6. The server of claims 1-5, further comprising means for receiving a request from at least one navigation device and communicating the buddy list in response to the request.

7. The server of claim 4, further comprising means for querying the at least one navigation device for current location information and identification.

8. The server of claim 7, wherein the means for updating further comprises means for updating the buddy list according to the current location information.

9. The server of claims 1-8, further comprising communication means arranged to enable communication between at least two navigation devices.

10. A navigation system buddy system, comprising:

at least one buddy list comprising a plurality of navigation devices grouped according to a common characteristic, an

Means for communicating the at least one buddy to the navigation device.

11. The navigation system buddy system according to claim 10, wherein said navigation devices are listed in said buddy list by name and geographic location.

12. The navigation system buddy system according to claim 11, wherein said geographic location is provided by said navigation device.

13. A navigation device comprising communication means arranged to send and receive buddy system messages.

14. The navigation device of claim 11, wherein the message is communicated between at least one of navigation devices and a server.

15. The navigation device of claim 11, wherein the message comprises a request for a server to transmit a buddy list to the navigation device.

16. The navigation device of claim 13, wherein the buddy list comprises a plurality of navigation devices identified by name and geographic location.

17. The navigation device of claim 14, further comprising means for outputting navigation instructions from a current location to the geographic location.

18. The navigation device of claim 17, wherein the instructions comprise at least one of audio instructions and visual instructions depicted on a map background.

19. The navigation device of claim 13, further comprising means for determining which of the navigation devices listed on a selected buddy list is located within a radius of a selected geographic location.

20. The navigation device of claim 19, further comprising means for displaying that the navigation device listed on a selected buddy list is located within a radius of a selected geographic location; and means for editing the buddy list.