US 20070271328 A1
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.
1. A server comprising means for communicating a buddy list to at least one navigation device.
2. The server according to
3. The server according to
4. The server according to
5. The server according to
6. The server according to
7. The server according to
8. The server according to
9. The server according to
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
12. The navigation system buddy system according to
13. A navigation device comprising communication means arranged to send and receive buddy system messages.
14. The navigation device according to
15. The navigation device according to
16. The navigation device according to
17. The navigation device according to
18. The navigation device according to
19. The navigation device according to
20. The navigation device according to
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.
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.
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.
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.
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:
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.
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.
A top menu may comprise the map 19 depicted in
When part of the PND, the Buddy System first becomes noticeable via a main menu icon such as is depicted in
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
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,
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.
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.
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
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.
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
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
If the send buddy message 88 (icon 1204,
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
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
If the cancel option 86 is selected 100, the method proceeds 102 back to the pervious menu. Alternatively, the method may proceed to end.
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
As depicted in
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
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
If the navigate there option 126 (icon 1402,
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
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
In the event the cancel option 118 (icon 1214,
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:
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).