Buddy system for navigation devices

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

PRIORITY STATEMENT

The present application hereby claims priority under 35 U.S.C. §119 on each of Great Britain Patent Application numbers 0604709.6 filed Mar. 8, 2006; 0604708.8 filed Mar. 8, 2006; 0604710.4 filed Mar. 8, 2006; 0604704.7 filed Mar. 8, 2006; and 0604706.2 filed Mar. 8, 2006, the entire contents of each of which is hereby incorporated herein by reference.

FIELD

The present application generally relates to the field of navigation systems and more particularly to a buddy system for navigation systems, an arrangement for operating the buddy system with navigations systems, and a navigation system configured to affect operation of the buddy system.

BACKGROUND

Navigation systems as used herein refer to devices enabling a user to navigate from a current location to a destination location. The navigation systems may be arranged to provide user output in the form of a displayed map upon which arrows or other indicia indicate an appropriate route between the current and destination locations. The maps may be refreshed based upon, for example, current location as determined by appropriate satellite, GPS, and/or Internet connection. With refreshed maps come refreshed visual indicia as to an appropriate next step along the route between current and destination location. Alternatively, map refreshing may occur with time. Other user output may include voice direction made along with or independent of the map display. A common voice command may be to make a particular turn at an upcoming intersection.

The navigation systems may comprise an internal processor in communication with an internal memory, communication means, power means and a display. The processor may comprise software or other programming to effect the generation of the above noted maps and user output. The internal memory may include map data upon which the process may draw upon. Additionally, 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 with the communication means being standard direct and/or wireless communication.

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

Current navigation systems come in a variety of forms. A form, personal navigation device, may be handheld or otherwise portable and/or embedded into a motor vehicle such as a car, boat or plane. Among the navigation systems many features is the ability to route the user to a particular destination location or point of interest (such as a next gas station, favorite restaurant and the like). Such destinations are geographically static and typically known in advance. For example, a user may preprogram his or her device to identify a favorite bar in advance of beginning a trip to the bar. Upon embarking towards the bar, the user need simply enter the bar's name or location.

A common functionality missing from navigation systems is the capability of routing a user towards a moving destination location. Additionally, another missing functionality is the ability to locate other navigation system users. Such functionality is especially helpful in answering such important questions as “where is my wife?”, “where are my colleagues?” or “where are my friends?”. Such questions become even more important not only in a personal context of meeting friends or family but also in a professional context of a central office attempting to locate colleagues currently underway—such as delivery vehicles, taxis and the like.

SUMMARY

The present invention is therefore directed to the aforementioned unaddressed need in the art, namely the provision of locating, navigating towards and/or communicating with other navigation systems users. The present system for such provision is herein referred to as a buddy system. The present invention is accordingly directed to the buddy system, a system for providing the buddy system and navigation systems programmed or otherwise arranged to affect the buddy system.

The buddy system, per se, is a system by which one navigation system can locate a select other navigation system or systems. The instant buddy system provides users with functionality to select users of navigation systems according to a predetermined commonality of the select users. 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 location of the buddies with respect to point x may be varied. Additionally, the buddy system provides for the locating of select buddies belonging to a particular professional organization, i.e. select (or all) taxis in a greater city area or select (or all) delivery trucks currently in operation regardless of location, etc. The location of buddies may also be limited to friends, family and the like, i.e. location of one's children. Buddy groupings may of course overlap and include more than one of the aforementioned. These and other groupings of buddies are detailed below.

To affect the aforementioned groupings, a predetermined list of buddies, or buddy list, is created. Once affected, the identification and location of buddies on the buddy list may be made. As the buddies are also users of navigation systems, the buddy list may further include the geographical location of the navigation system and therefore buddy using the located navigation system. As navigation systems tend to be used by users in motion, the buddy list may be refreshed or updated periodically to remain current.

Once located, the requesting user may wish to navigate towards one or more buddies on the buddy list as well as communicate with one or more of them. The communication may take the form of voice or text communication. The buddy system is therefore further directed to effecting such and related functionality.

The inventive system for affecting the buddy system comprises a dedicated server in communication with one or more navigation systems. The system may follow the known client-server architecture with the additional features and functionality to affect the instant buddy system. In addition or alternative to a dedicated server, other appropriately configured client-server systems, i.e. dedicated and/or non-dedicated servers, may be employed. Navigation system to navigation system communication may be affected via a peer to peer configuration or via the dedicated and/or non-dedicated server.

The present invention is further directed to a navigation system for affecting the buddy system. The instant navigation system may comprise a processor programmed to affect the above noted functionality. Additionally, the instant navigation system includes input/output means for exchanging information with a user. Such input/output means may include a touch screen, speaker/microphone, buttons, lights and the like with the appropriate supporting functionality 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 and the like. By way of an appropriately programmed processor, the user may be prompted with a series of graphical interfaces to manually input desired functionality. The inputting may be manual, voice activated and the like. The desired functionality may include the aforementioned buddy location, buddy list creation, navigation towards a buddy, communication with a buddy and the like.

The present system is still further directed to a method for implementing the aforementioned buddy system.

While described above in the form of navigation systems, application of the present buddy system is not so limited to navigation systems and may include implementation on portable or desktop computers, personal digital assistants, mobile telephones and any other device including at least the above mentioned elements and functionality.

BRIEF DESCRIPTION OF THE DRAWINGS

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

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

FIG. 2 is a flowchart depicting a method for affecting the present buddy system on a navigation system;

FIGS. 3-12 depict a series of screen shots which may be presented to a user affecting the present buddy system on a navigation system.

DETAILED DESCRIPTION OF THE EXAMPLE EMBODIMENTS

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the present 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 “includes” and/or “including”, 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 example 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.

Referencing the drawings, wherein like reference numerals designate identical or corresponding parts throughout the several views, example embodiments of the present patent application are hereafter described. 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 present invention will be discussed with respect to a portable navigation device (PND) with the understanding that the present invention may be applied to any navigation system or other device including the functionality discussed herein.

FIG. 1 depicts a typical client server arrangement 15 comprising a server 10 in communication with a generic user 14 and a tablet computer 12 and a personal navigation device (PND) 16. Each of the aforementioned includes communication means, known in the art and not depicted in figure, arranged to facilitate communication 18 with the server 10. In addition, each may comprise input/output means for exchanging information with a user. Such input/output means may include a touch screen 17 upon which a map 19 is displayed and user commands tactically inputted as is depicted on the personal navigation device 16. The touch screen may further be used to display graphical user interfaces (detailed below) prompting the user commands. Other input/output means include speaker/microphone arrangements for receiving and broadcasting voice commands; buttons for receiving tactile prompts and/or displaying a prompt through flashing or the like; and other input/output means as may be envisioned by one skilled in the art. The present invention is not limited to the number or type of client interacting with the server and the aforementioned generic user, tablet computer and personal navigation device are depicted by way of non-limiting example.

The server comprises a buddy list 11 made up of a plurality of buddies 13. As will be detailed below, the buddies may be selectively organized and identified by either or both identification and geographical location. The server may be a dedicated or non-dedicated server. The server may be a stand alone server or part of a larger network. Communication with the server may be affected by means known to one skilled in the art. The present invention is not limited by client server architecture nor client or server type.

Because the buddy list may be populated by buddies within a certain radius of the requestor, the server may maintain a master list of available buddies and their current locations. Accordingly, as will be detailed below, a user when signing on to the buddy system may be requested to allow the release of his or her current position. Additionally, the server further includes processing means available to calculate a current requester position, apply a certain geographical radius to the current position and select from among the possible buddies for, among other criteria, buddies within the radius.

FIGS. 2a-c depict flowcharts depicting a method for affecting the present buddy system on a navigation system. The depicted method highlights the interaction between device and user, including the affects of user selection of a particular functionality. The present invention is not limited to the specific depicted order. The method will be discussed with respect to application on a personal navigation device (PND) with the understanding that the present method may apply to any client. The method steps will be discussed below with screen shots depicting icons for affecting the discussed method steps.

A top menu may comprise the map 19 depicted in FIG. 1. Tapping on the map or otherwise engaging the PND will cause a main menu to appear. The present buddy system may be part of a typical functionality provided by navigation software, the functionality appearing as one of many main menu icons. Alternatively, the buddy system may be an add-on system provided in addition to a main functionality. Such is offered by the assignee TOMTOM entitled PLUS.

When part of the PND, the Buddy System first becomes noticeable via a main menu icon such as is depicted in FIG. 3. FIG. 3 depicts a highest level icon 300 introducing the buddy functionality to the user. The functionality may be part of a navigation software package for a navigation system or an add-on to existing packages by way of an enhancement. Activation of icon 300 causes buddy system menus to appear. The activation also corresponds to the start 20 of the flowchart of FIGS. 2a-2c.

In a first step 22, prior to the display of buddy system menu or concurrently therewith, a buddy list request is sent by the PND to the server.

The buddy list comprises a grouping of navigation device users, the grouping being based upon a preexisting relationship set up by the user. The buddy list comprises user names and/or current geographical locations of the users. A depiction of a buddy list is set out below. Buddy lists are maintained by a central server and periodically refreshed. As will be detailed below, the user may selectively refresh the downloaded buddy list saved on his or her PND. The different categories or groupings of the buddies, as suggested above, may be based upon a relationship to the user (e.g. family, profession, etc.) or random (e.g. any other buddy systems users). The buddy list may further be limited by geographical location, such as a select radius to a current or select location.

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

In step 26, the PND creates a local shadow/working list of the buddy list.

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

The following queries are depicted as icons in a first of two buddy system menus. The specific pictorial depiction and corresponding text may vary by application and are depicted in the Figures as example icons only. The first buddy system menu 400 is depicted in FIG. 4, the menu comprising a number of icons corresponding to queries discussed in conjunction with the flowchart below.

Returning to FIG. 2a, in step 30, the user is queried whether to include his or her name and geographical location in other buddy lists stored on the server or whether the user wishes to remain anonymous. Icon 440 of FIG. 4 corresponds to this query. Should the user wish to remain anonymous (32), he or she will appear to other users as having turned his or her device off. The icon 440 may further be caused to change thereby indicating that the user is hiding his or her identity and location. Such an icon may include a cross through the icon as depicted in FIG. 4. The user unavailability is affected by sending a Set-Status/unavailable message to the server from the user PND. The result returned by server is processed appropriately.

If the user decides to have his or her name included in the list (34), the appropriate buddy list or lists stored on the server will be updated with the user's information in step 36. This will be affected by sending a Set-Status/available message to the server from the user PND. The result returned by server is processed as will be detailed below. Thereafter, the first Buddy System menu 400, FIG. 4 will be displayed to the user.

In addition to the aforementioned, the user may be asked if he or she wishes to adopt a special name which will be used in place of generic device identification. If so selected, the server will store the user's personally selected name. Further, if the buddy list requested from the server is empty, the hide your positions icon (below) will be dimmed.

Pursuant to the first Buddy System menu, the user is presented with additional options, including: guided tour 38 (icon 432), showing a buddy's location on a map 40 (icon 434), update (the buddy list) now 42 (icon 436), inviting a new buddy to the buddy list 44 (icon 438), proceeding to the second menu 46 (icon 438) and done 48 (icon 440). First Buddy System Menu 400 may include further displayed information, including current time 442, indication of when a last update was performed 444 and an indication of which of the two Buddy System menus is being displayed 446.

Returning to FIG. 2a, if the guided tour option 38 is selected 50, the PND user is provided with a guided tour of the buddy system 52. The guided tour may comprise a multimedia tour including visual and verbal feedback to the user. The tour may further be instructional and interactive. Software used for implementing and affecting the guided tour may be stored locally on the navigation system or remotely on the server or the like and downloaded when engaged by the user. The details of the tour are a matter of design.

Queries and/or options may be engaged or selected via example pressing the icon on the PND display, the display being touch sensitive. Other user input means include voice activation, buttons and the like.

Returning to FIG. 2a, if the show buddy option 40 is selected 54, a map view (500, FIG. 5) is displayed on the PND's display 55, the map depicting a location of a particular buddy in question indicated thereon with the exact current location (as known by the server) highlighted with indicia. An additional step may be the notification of the displayed buddy that his or her location was requested by the user. By way of example, a map is depicted on the PND of FIG. 1.

FIG. 5 depicts an example map view 500 of Amsterdam, with a particular buddy in question 502 depicted thereon 504. The map view includes other functionality including: Find 504, Options 506 and Done 508; which will be discussed in more detail below.

Returning to FIG. 2a, the update now option 42 (icon 436, FIG. 4) actually comprises two options: an Update Now option and an Update or Update Buddy option. Alternatively, the Update Buddy option may be presented by way of individual query or icon (as is the case with step 74). When the update now option 42 or update buddy option 74 is selected 56 and 58 respectively, the server is requested by way of a refresh message to update the identities and locations of persons on the received buddy list 60 and 62 respectively. Process 62 will be discussed in more detail below. The result returned by server is processed and the user is presented with the first menu screen or buddy list on the user's PND display. Pursuant to the Update Now option 42, the current state and last known geographical positions (when available) of all the buddies on the buddy list are retrieved by the server.

FIG. 6 depicts a typical buddy list 600. As depicted, the buddy list comprises a plurality of buddies 602 identified by e-mail address 604 and buddy icon 606. Further to the present invention, each buddy may be identified by a particular icon having particular significance. Different buddy icons are depicted in FIG. 7. The buddy list 600 further includes an indication of time 608, a title 610 and three options: find 612, update 614 and cancel 616. Pursuant to the find option 612, the user is presented with an interface to locate a particular buddy from the buddy list via a search function, the search function being known in the art. The update function 614, once activated, updates the buddy list with the most current information available on the buddies, the information originating either from the user's PND or the server. The cancel function 616 closes the buddy list and returns the user to either the first buddy system menu or to the PND's main menu.

FIGS. 7a-7e depict one buddy icon each. The icons may be color coded for easier identification. First buddy icon 702 is used to indicate that the respective buddy is available and his/her position is current. By current, it is meant that the position is no more than 15 minutes old. Alternatively, other time definitions of current may be applied. As this buddy is current and available, his/her position can be seen on the map (e.g. 502, FIG. 5).

Second buddy icon 704 is used to indicate that the respective buddy is available although his/her position is out of date. In other words, this buddy's position was known but has since gone stale. A stale position may be one that is between 15 and 60 minutes old. Alternatively, other time definitions may be applied. This buddy could still be depicted on the map.

Third buddy icon 706 is used to indicate that the buddy is available although his/her position is old, namely more than 60 minutes. Here too, the time may vary by application. This buddy could 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 an invitation to the buddy to join the buddy list. This buddy has not yet responded to an invitation to become buddies. Accordingly, 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 the buddy's position cannot be determined because the buddy has declined the invitation to become buddies. Additionally, the buddy may have deleted the user from his/her buddy list.

Information may be retrieved by the server from a database, the maintenance of which may be made by the server further to procedures known in the art. Further to the Update Buddy option 74, the server is caused to actively request one particular buddy to return his or her current geographical location via a push channel or the like. The following interactions occur based upon the state of the buddy at issue. The updating can also occur from the buddy list screen option 614.

If a buddy state is unavailable/unknown, then a message may be displayed to the user along the lines of: TOMTOM BUDDIES, <Name> is not a PLUS user—PLUS being an enhanced service available for navigation systems from the assignee of the present application TOMTOM, the service including the present buddy system. Other language may be used to the effect that the requested buddy is not a member of the buddy system.

If the buddy state is unavailable/deleted (i.e. the buddy has been deleted user from the list of buddies), then a message may be displayed to the user along the lines of: “TOMTOM BUDDIES, <Name> has deleted you from his/her list of buddies.”

If the buddy state was unavailable/invited and is now available (i.e. the buddy has accepted the user's invitation to become buddies), then a message is displayed to the user along the lines of: TOMTOM BUDDIES, <Name> has agreed to be your buddy.

If the buddy state was unavailable/invited and is now unavailable/declined (i.e. the buddy has declined user's invitation to become buddies), then message is displayed to the user along the lines of: TOMTOM BUDDIES, <Name> has declined to be your buddy.

If the buddy state is invited/reply-to-invitation (i.e. the buddy has invited user to become buddies), then the user is presented with the following text message: TOMTOM BUDDIES, <Name> has invited you to become buddies. The user is further presented with a pair of buttons for accepting or declining the invitation. If the user selects Accept, a Reply-to-Invitation/accepted message is sent to server. If the user declines, a Reply-to-Invitation/declined message is sent to server.

At the server, in response to the Reply-to-Invitation/accepted message: the state of accepting a buddy in list of buddies of inviting buddy is changed to available from unavailable/invited; the state of inviting buddy into list of buddies of accepting buddy is changed to available (was invited/reply/-to-invitation); responsive Reply-to-Invitation/declined message—the state of declining buddy in list of buddies of inviting buddy is changed to unavailable/declined; the inviting user is deleted from the list of buddies of declining buddy; and the local list of buddies is updated.

Updating the buddy list can be done automatically on a time delay set by the user. This can be set manually by the user when engaging the change buddy preferences 64. If engaged 66, the user is presented with an update screen 800 depicted in FIG. 8. Pursuant to FIG. 8, the user is presented with text 802 indicating an automatic buddy list update mode and a check box 801 checked when the automatic update mode is engaged. In addition, the update screen 800 includes a time indication 804 and 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 check box 801 is unchecked, a second update screen is displayed to the user, the second screen including a numeric editor 900, FIG. 9, which facilitates user entry of a select time delay between updates in minutes 907. The editor 900 further includes a back function 902, a cancel function 904 returning the user to the first buddy system menu and a done function 906 bringing the user back to the first update screen. As with the first update screen, the second update screen includes a time indication 908 and title 910.

Returning to FIG. 2a, if the invite new buddy option 44 is selected 58, the user identifies a particular buddy and requests the server to add the identified buddy to a user specified buddy list 62. To affect the identification of a new buddy for the buddy list, the user is presented with a standard alphabet editor screen 1000, FIG. 10 including alphanumeric characters as well as options to cancel 1010 and done 1012. New buddies may be identified by e-mail address 1014 or other identifier. To effect the addition, an invite message is sent to the server by the user PND and the result returned by server is processed. Hereafter, the buddies or first menu is again displayed. As with the above screens, the alphabet editor screen includes a clock 1016 and tide 1018.

At the server side, a determination is made whether the user exists and is otherwise available or known. If the status of the user is available, the user is added to the buddy list by way of an invited/reply-to-invitation step. The intended buddy is informed of the invitation by means of a message notification which can be personalized by the user or comprise prewritten text available from a memory and sent automatically as part of this step. If the buddy is unknown, then the buddy state becomes unavailable/unknown and the user is so informed. If the user is not available, the buddy state becomes unavailable/invited and the user so informed. If the buddy is available, the buddy state becomes available.

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

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

If the proceed to the next menu 40 is elected 62, the first menu will be replaced by a second menu presenting the option with additional options discussed below. As with the first menu, each of the second menu queries may be presented simultaneously on one screen. An alternative number of queries may be presented depending upon programming, screen size and the like. 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 elects to proceed to the next buddy system menu 70, the user is then presented with the second buddy system menu 1100 as depicted in FIG. 11. FIG. 11 comprises a series of icons related to method steps set out in FIG. 2a.

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

If the send buddy a message option 78 is elected 82, a send buddy message sub/menu screen 1200 is displayed for the user, the screen being depicted in FIG. 12 and the process continuing 84 in FIG. 2b. The user is presented with several options or queries, including: send buddy a message 88 (icon 1204); send buddy a location 90 ( icon 1202); send buddy your position 92 (icon 1206); and done 86 (icon 1208).

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

If the send buddy a location option 90 is elected 96, a user selected geographical location is transmitted to the buddy in question 106 along the same lines as the above message. An example message 1300 is depicted in FIG. 13. The message comprises text identifying the selected geographical location 1302 and the GPS position 1304 for the location. The message further comprises two options, namely proceeding to a navigation to menu 1306 and returning to the main map or main menu of the PND 1308. The message may further include a time 1310 and title with indication of sender and telephone number thereof 1312.

The buddy must have an available state and accordingly a list of buddies to whom such a message could be sent may be limited in advance, by the PND, to only those with that state. 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 facilitating determination of a position. Selection of the GPS icon brings up a location menu screen through which a location may be selected or otherwise inputted. One possible location is the user's current position. Once a location is selected and entered by the user, a Send-Position message is sent to the server. The message may include predetermined explanatory text or personalized text. The result returned by server is processed and the first menu is displayed for the user.

Upon receipt at the buddy's navigation device, the transmitted geographical location may be displayed as a text and/or as a location on a map. The user selected geographical location or address may be created by typing in alphanumeric characters off of a displayed alphabet; tactically indicating on a displayed map the location, or other input means. Such may be provided via a location selector in a text message. The now entered location is transformed into a message and transmitted, via the server or directly to the buddy's navigation system.

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

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

Returning to FIG. 2a, if the change buddy preferences option 64 (icon 1110, FIG. 11) is elected 110, a change buddy preferences screen (discussed above) is brought up and displayed on the user's PND display 84. Pursuant to this screen, the user is provided with the option to select an automatic update of the buddy list from the server, the updating comprising the names of current buddies (i.e. buddies who have currently activated their navigation devices and have agreed to be part of the buddy list) as well as the current buddies current locations as again obtained from the buddy navigation systems as discussed above. Pursuant to an additional automatic updated buddy list screen, the user is presented with the option to selectively update the buddy list every number of minutes, the number ranging from 1 to 99. To facilitate input of the updating time interval, the user is presented with a series of numbers 1-9 along with the options to cancel, finish and go back to a previous menu (as will be detailed below). Pursuant to the updating of the buddy list, the user's PND will be made to forward the user's current identification and geographical location to the server for inclusion in appropriate buddy list(s).

If the delete buddies option 72 (icon 1104) is selected 114, the user is presented with text requesting a confirmation of the deletion. The text may read, “Are you sure you want to delete <Name>?” Other text may be used by way of design choice. The user is further presented with a yes and no selection option. Such option may be a button, icon, voice activation means and the like. If the user selects “yes”, the buddy is deleted from the local list of buddies (on the user PND or stored remotely), a Delete-Buddy message is sent to the server and the result returned by server is processed. At the server, the buddy to be deleted is removed from the user's buddy list, the state of the deleted buddy is set to unavailable/deleted and the buddy list is displayed for the user on his or her PND display. Likewise, the user is deleted from buddy lists belonging to the now deleted buddy.

If the update buddy position option 74 (icon 1108) is selected 58, a determination is made of all buddies having an available state and a Get-Position message is sent by the user's PND to the server—the position being that of the available buddies 62. The result returned by the server is processed and the first or buddy menu is displayed to the user. At the server, if the statue of the intended buddy whose position is being updated is available, a Give-Position message is sent to the intended buddy (e.g. via Push) and the buddy returns his/her current position. The position of the buddy on the server is further updated.

If the user elects to read messages 118 pursuant to the read messages option 76 (icon 1106), the user is presented with a text message 120. The text message 120 may comprise the user's position and identification as will be detailed below with respect to FIG. 13. Pursuant to the displayed message in step 120, the user is presented with additional options step 122 set out in by way of the flowchart of FIG. 2c.

As depicted in FIG. 13, message 1300 comprises a location 1302 and buddy identification 1304 presented here as text. Other message formats may be used as envisioned by one skilled in the art, including pictures, sounds and other media. The message 1300 further includes an indication of the sender 1310 displayed therein. The sender may be identified by name and telephone number. As depicted, message 1300 was sent by Johnny having telephone number +31653354300 (1310). The current time (1312) may also be displayed. The precise presentation of the sender information and time is matter of design choice. Alternatively, other related information may be displayed within the message, including: current date, personalized sender identification and the like.

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

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

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

If the navigate there option 126 (icon 1402, FIG. 14) is selected 136, the user's PND will affect a navigation to the particular geographical location 132. Initially, the user will be queried about a specific arrival time step 148 (1500, FIG. 15). If a specific arrival time (1502, FIG. 15) is selected by the user 166, a route is calculated to the buddy location by the PND software which will affect arrival at the user desired time. Likewise, a best route will be calculated if no specific arrival time 168 (1504) is selected by the user 156. The affect may be made by determination of a best route from the user current location to the particular geographical location as may be effected by appropriate navigation software such as the NAVCORE software from this patent's assignee TOMTOM. The best route may be displayed on the user's PND as well as be accompanied by voice commands and the like.

If the user elects to have a buddy location displayed on a map 134 pursuant to query 128, the PND is made to decipher the buddy location as may have been received pursuant to an earlier query and display the same (step 144) on a map as depicted in FIG. 5. Prior to display, the state of the buddy for display is confirmed as being available. If available the buddy information is taken from the local list and displayed on the PND. The display may include a particular icon for emphasis 502, FIG. 5. The user is presented with the option of returning to the main map display or main menu by selecting icon 508. A route may be calculated from the user's current location to the buddy by activation of the find icon 504. Likewise, the aforementioned navigation menu options step 122, FIG. 2c may be accessed through activation of icon 506.

If the user elects to add a buddy location to his favorites 132 pursuant to option 130, the PND is made to store into memory the particular location 146 via entry of the buddy identification pursuant to an alphanumeric editor screen as is depicted in FIG. 10 and discussed above. If the entry already exists within the favorites list, the user will be given the option of replacing the existing entry as depicted by screen shot 1600 in FIG. 16 (query 150, FIG. 2c). Such messages may be flash messages. Screen shot 1600 includes a yes 1602 and no 1604 option. In the event the user elects to make the replacement (154, FIG. 2c), the prior entry of the same location is replaced with the new location (156, FIG. 2c) within the favorites list. If the user elects not to make the replacement (158, FIG. 2c), the step ends and screen 1700 is presented to the user (152, FIG. 2c) giving him/her the option to set the current location as a home location. Screen 1700 includes a yes 1702 and no 1704 option. If the yes option 1702 is selected (160, FIG. 2c), the PND is made to change the current home location to the one depicted on screen 1700 (162, FIG. 2c). If the user elects not to replace the current home location (164, FIG. 2c), the user is brought back to the navigation screen 1200 (140, FIG. 2c) as depicted in FIG. 12.

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

Returning to FIG. 2a, should the user elect to proceed to a previous menu 83 (1112, FIG. 11) pursuant to option 80, the method reverts back (step 102) to the first buddy system menu as depicted in FIG. 4. Should the user elect to finish 85 (1114, FIG. 11) pursuant to option 81, the method ends (step 160).

Message exchanges with the server, in general, will now be discussed and data managed by the server will also be outlined.

All Messages Sent by Client to Server Contain the Following Elements:

• own status: available or unavailable
• own current position if status is available; otherwise empty
  All Server Responses to Messages Sent by Client Contain these Elements:
• list of buddy items

There are 2 paths of communication between buddies. One is the buddy client-server message protocol, the other is text messaging. The buddy client-server message protocol covers requests such as AddBuddy, RemoveBuddy, Update. A response received from the server is the result of a manual user action: selecting a menu icon. A server response may cause a notification dialog to be shown on the client. Text messaging covers ordinary text, which may contain a position recognized by the application. These text messages could be read as normal text if received on a device that does not interpret them correctly. The messages could be typed in manually. It does not matter if they originate as an SMS, a server message, or a buddy message. The referred to visual notification is the indication that a text message has arrived (AFAIK this is general messaging functionality).The server sends a canned text message when a user is invited to become a buddy (i.e. when it receives an AddBuddy request).

Claims

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

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

3. The server according to claim 2, wherein said buddy list comprises at least one navigation device having at least one select characteristic.

4. The server according to claim 3, further comprises means for at least one of grouping, updating and storing records related to said characteristic.

5. The server according to claim 4, wherein said characteristic comprises at least one of: a location, an interest, an activity, an employment and an interpersonal relationship.

6. The server according to claim 1, further comprising means for receiving a request from at least one navigation device and communicating said buddy list in response to said request.

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

8. The server according to claim 7, wherein said means for updating further comprises means for updating said buddy list in accordance with said current location information.

9. The server according to claim 1, further comprising communication means arranged to affect communication between at least two navigation devices.

10. A navigation system buddy system, comprising:

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

means for communicating said at least one buddy to said navigation devices.

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

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

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

14. The navigation device according to claim 11, wherein said messages are communicated between at least one of navigation devices and a server.

15. The navigation device according to claim 11, wherein said messages comprise a request to a server for transmitting a buddy list to said navigation device.

16. The navigation device according to claim 13, wherein said buddy list comprises a number of navigation devices identified by name and geographical location.

17. The navigation device according to claim 14, further comprising means for outputting navigation instructions from a current location to said geographical location.

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

19. The navigation device according to claim 13, further comprising means for determining which of said navigation devices listed on a select buddy list is located within a radius of a select geographical location.

20. The navigation device according to claim 19, further comprising means for displaying said navigation devices listed on a select buddy list is located within a radius of a select geographical location; and means for editing said buddy list.