Location-code system for location-based services6912545Abstract A location-code system provides user-specific location codes corresponding to locations. A user can provision the codes. When the user accesses a location-based service, the user can then provide the service with a location code. The service, perhaps with the assistance of a location-code provider, can then translate the user-specific location code into location coordinates that can be used to facilitate a location-based service. Further, the location-code system can provide global, or generic, location-codes for particular locations, which any user can use as a basis to indicate a location. Claims 1. A method of determining a location for use in a location-based service, the method comprising: Description BACKGROUND
In the exemplary embodiment, speed codes and global codes can be distinguished from each other in some way such as by length, so that a system provided with a code can determine whether the code is a speed code or a global code. For instance, all speed codes could be restricted to be 3-4 characters, while all global codes could be 10 or more characters. (As a particular example, every global code could be a combination of the latitude and longitude numbers corresponding to a respective location, padded if necessary so that the total length of the global code is at least 10 digits. In that case, the separate latitude and longitude coordinates listed in the Global Table could be omitted. Other examples are possible as well.) The User Table and Global Table could be stored in various locations. For instance, the User Table and Global Table could be stored on a common platform, such as on a client station or on a network server. Alternatively, the User Table could be stored on one platform, and the Global Table could be stored on another platform. As an example, the User Table could be stored in a data file on a client station (and could therefore be accessible to a client application) and the Global Table could be stored in a data file on a network server (and could therefore be more generally accessible). As still another example, the User Table could be stored on a corporate LAN server and the Global Table could be stored on a network server located elsewhere on the Internet. For purposes of this description, but without limitation, the User Table can be assumed to be stored on the speed code server 16, and the Global Table can be assumed to be stored on the global code server 18. As shown in FIG. 1, both of these database servers may be accessible via provisioning system 20 and access system 22. Alternatively, the servers could be accessed via any other desired channels. The database system, however, can vary from that described above and shown in FIG. 1. For example, the database system can be arranged as one table, in which each record has the following fields:
Still further, other fields, field definitions, tables, and database relationships are possible as well. For example, a User Table could correlate each user to a Group Table, and the Group Table could then define Global Codes that correspond to the speed codes for the users in a given group. As another example, the specific fields listed above could be varied, such as by omitting one or more fields, combining fields together, adding other fields, or otherwise altering the fields. For instance, although latitude and longitude are listed as separate fields, the two could be combined together as one field. Further, the "location" indicated by the database system could take a form other than geographic location coordinates. Still further, in addition to (or instead of) a plaintext location name, the database could include a field that designates an image corresponding to the location, such as a corporate logo or photo image for instance, and the database could store each associated image. 3. Overview of Operation In operation, a user will access a location-based service, such as that provided on application server 32. In order for the location service to function (i.e., to provide a service based on location), the location service must be provided with a location. In the exemplary embodiment, the user will specify a location by specifying a location code, such as a speed code or a global location code. If the user specifies a speed code, the application server will refer to the User Table to convert the speed code to a global location code, and the application server will then refer to the Global Table to convert the global location code to location coordinates. Alternatively, if the user specifies a global location code, the application server will refer to the Global Table to convert the global location code to location coordinates. The application server will then use the location coordinates as a basis to provide a location service. 4. Provisioning Location Codes A variety of procedures can be employed in order to populate the database system 14 with location codes. In the exemplary embodiment, for instance, a user or other entity may populate the User Table with entries by selecting one or more locations, providing a name for each location, and selecting a speed code for each location. The user may do this by interfacing with provisioning system 20 or with another suitable provisioning system. The provisioning system may take various forms. For example, the provisioning system may comprise a web site that can be accessed directly (e.g., by browsing to the site) or from another web site (e.g., through a suitable CGI or Java script). For instance, provisioning system 20 can host a provisioning web site having a designated address on IP network 26, and web server 34 could host another web site that includes a link to the address of the provisioning web site. The provisioning server can be coupled with speed code server 16 and with global code server 18 and can be programmed to access the User Table and the Global Table, so as to facilitate setting up or modifying location codes. Alternatively, the provisioning system may provide an operator-center or interactive voice response unit (IVRU) that users could call (via a toll-free number, for instance). For instance, operator station 30 shown in FIG. 1 could be part of provisioning system 20; alternatively, provisioning system 20 could include a separate operator center or IVRU that is accessible at a designated telephone number. The operator site or IVRU could then be coupled with the database servers described above, to facilitate setting up speed codes in a similar manner. Other examples are possible as well. The process of provisioning location codes can take various forms. To help illustrate, FIG. 2 provides a flow chart depicting the functions that could be performed by an exemplary provisioning web site, hosted by provisioning system 20. As noted above, this and other figures are set forth for purposes of example only, and variations are possible. For instance, various functions can be modified, combined or omitted, additional functions can be added, and the order of the functions could be changed. Referring to FIG. 2, at block 52, for instance, when a user visits the provisioning site, the site prompts the user for a User ID (and password), and the user provides the User ID (and password). At block 54, with the User ID, the site then queries the User Table to find all records for the User. At block 56, the site determines if any such records exist. If any records exist, then, at block 58, the site responsively presents the user with a list of the speed codes and corresponding location names (and/or images) that have been established for the user. Alternatively, if no such records exist for the user yet, then, at block 60, the site advises the user accordingly. The site then prompts the user to modify or add speed code entries. To facilitate adding a new speed code entry, for instance, the exemplary provisioning site could include a hyperlink or other mechanism that leads the user to a list or outline of locations, possibly classified by subject matter (e.g., restaurants, pizza restaurants, hot dog stands, etc.) or in some other way. The list could describe each location by formal name and address, such as "McDonald's restaurant, 125 S. George Street, Pineville, Ky." and could further include a representative logo or picture associated with the location (such as the "golden arches" McDonald's logo, for instance). Thus, at block 62, the site could present this list of available locations to the user. The site could be programmed with the location coordinates corresponding to each listed location, although those coordinates will preferably be hidden from the user's view. In the exemplary embodiment, at block 64, the user then selects a desired location from those presented. At block 66, in response to the user's selection of the location, the site then prompts the user for a name by which the user would like to refer to the location, and the user selects or provides a desired name. Alternatively, the site could accept the formal name by default if the user does not specify another name. At block 68, the site then stores the user's User ID and selected location name in a new record in the User Table. Further, if the speed code database allows for storage of an image associated with a location, the provisioning site also stores in the database the representative logo or picture associated with the location (if provided). Alternatively, the site could prompt the user to provide another desired image to be associated with the location. At block 70, the exemplary provisioning site will then prompt the user to specify a speed code to be associated with the designated location, and the user will specify a speed code. If the site has a list of the speed codes already established for the user, the site could suggest a next available speed code in numerical order and could allow the user to signal approval of the suggested speed code. Alternatively, the site could accept another speed code entered by the user. In the exemplary embodiment, the site could restrict the length of the speed code to three or four characters, as described above. At block 72, the site could then store the selected speed code in the new User Table record as well. Given the location coordinates of the selected location, the exemplary provisioning site will then determine if the location selected is already listed in the Global Table, such that a global location code already exists for the location. In particular, at block 74, the provisioning site may query the Global Table to find if any Global Table entry lists the location coordinates. If the provisioning site finds such an entry, at block 76, the provisioning site will then retrieve the global code from the entry and store the global code in the User Table record. Alternatively, if the provisioning site finds that such an entry does not exist, then, at blocks 78, the site will create a new record for the location in the Global Table and, at block 80, the site will store the associated global code in the User Table record. As noted above, the provisioning system can be accessed directly or in some other manner. As examples, a user could access the provisioning system as a service provided by a directory assistance center, a web service provider, or a carrier that knows or can determine the user's current location. These entry points are illustrated in FIG. 1 by blocks A, B and C respectively. For instance, when a user calls directory assistance to obtain a telephone number or address of a given party, the directory assistance operator (or automated system) could prompt the user to create a speed code for the party. For example, assume that the user has called directory assistance to get information about the McDonald's restaurant noted above. The directory assistance center could switch the user to an IVRU, possibly hosted by the location-code provider company (e.g., as part of provisioning system 20, coupled to the operator via a voice over IP channel over network 26), which could ask whether the user would like to create a speed code for that restaurant. If the user wants to, the IVRU could then carry out a provisioning process like that noted above, prompting the user for information via voice commands or other entry mechanisms. If the IVRU allows a user to speak a description of a location, the IVRU may be arranged to convert that description into text and then store the text description in the database. Alternatively, the database system might provide a field for storing a digitized voice signal associated with the speed code, so the platform might store that digitized voice signal in the database, rather than converting the voice to text and storing the text. Similarly, assume that a user is visiting a McDonald's web site, hosted by server 34, for instance. The web site could provide a "Create Location Code" hyperlink button, which, when selected by the user, could cause the McDonald's web site to execute a script so as call up the location code provisioning site described above. The script could pass to the provisioning site an indication of the McDonald's restaurant name and location coordinates. And the provisioning site can then work as described above, allowing the user to select a speed code and a reference name for the location. In accordance with the exemplary embodiment, the location-code provider company can distribute a "Create Location Code" button graphic and associated script code for use on third party web sites. With this arrangement, the "Create Location Code" link could be displayed on many web pages, thereby enabling increased use of the location code system. Further, if a user is operating a client station that is currently located at a given position, and if the user is communicating with a service that can determine the current position, the service could allow the user to set up a speed code for the user's current location. For instance, a telecommunication service provider can readily determine the location of a landline or wireless terminal that a user is operating. (Recent advances in location technology have enabled cellular wireless carriers to identify the location of mobile stations, such as cellular telephones, personal digital assistants, etc., with great precision. Further progress in this area is expected as well.) The service provider, or an authorized third party service provider, can set up a service by which a user can establish a speed code for the user's current location. For example, if a user is operating a cellular telephone equipped with a microbrowser application, the user could browse to a web site operated by the user's cellular carrier. The web site can present the user with a choice (e.g., via a choice card or other mechanism) to establish a speed code for the user's current location. When the user makes that choice, the web site can determine the user's current location (by reference to a mobile positioning center, location server, or other entity) and then prompt the user for a speed code and name to use for the location. The web site can then set up the speed code, as described above. A similar process can be accomplished through other communication channels, such as by telephone for instance. It should be understood that the speed code provisioning system could take still other forms as well. For example, in an alternative embodiment, the provisioning system (e.g., provisioning web site) could include logic that causes a user's speed codes and corresponding plaintext descriptions to be stored on the user's client terminal. Each time the user visits the provisioning web site or changes the list of speed codes, the web site can then autonomously (or at the user's request) store a cookie or other file on the user's computer, providing a list of the user's speed codes and corresponding descriptions. 5. Using Location Codes As noted above, a user can use a speed code to facilitate a location-based service, by providing the speed code to a location-based-service provider. The service provider can take various forms, and the user can access the location-based service through various mechanisms. For instance, as described above, the location-service may be Internet-based, so that the user could browse to the service from a landline or wireless terminal equipped with a web browser. Alternatively, the location-service may be telephone based (e.g., at an operator center, which may include operator station 30), so that the user could access the service by calling a designated telephone number. Other examples are possible as well. The process of providing a speed code to the location-based service could take various forms. For example, once the user accesses the location-service, the service could prompt the user to indicate a location and could allow the user to do so by providing a speed code. The user could then responsively provide the speed code. By way of example, FIG. 3 provides a flow chart depicting the functions that may be involved in using a speed code, where the location-service 32 is Internet-based and the user is operating a browser-equipped client station by which the user has accessed the service. Again, these functions are shown and described for purposes of example only, and many variations are possible. Further, analogous functions can be performed in other scenarios (e.g., through telephone access) as well. Referring to FIG. 2, at block 100, for instance, the location-service first sends to the user's browser a web page (e.g., an HTML page or an HDML choice card) that displays an "Enter Location Code" option or the like. (By analogy, in a telephone based system, the location-based-service provider could employ an IVRU to prompt the user for that selection.) At block 102, the user selects that option, indicating a desire to specify a location by providing a location code. The service then prompts the user to specify a location code, and the user specifies a location code. In obtaining a location code from a user, the an exemplary service can allow the user to enter a desired location code or to request a list of speed codes that are available for the user, as shown at block 104. For instance, the service may provide a text entry box or card for the user to specify a location code, and the service may provide a button for the user to select so as to indicate a request to see a list of available speed codes for the user. If the user requests a list of available speed codes, then, at block 106, the service will ask the user to provide a User ID, to facilitate correlation with speed code entries. Alternatively, rather than having the user expressly indicate a User ID, the service could identify the user, perhaps with the assistance of a telecommunications carrier, based on the identity of the user's terminal or based on a session ID for instance. Provided with the User ID, at block 108, the service will then query the User Table, by reference to the User ID, so as to obtain a list of all speed codes and associated names (and/or images) that are currently set up for the user. For instance, the service could send a message to the access system 22, asking the access system to provide a list of speed codes associated with the designated User ID. In response, access system 22 could query the User Table and return a list of available speed codes and associated names and global codes, and perhaps the associated location coordinates. At block 110, the location-service may present the list of the associated names to the user and allow the user to select a location from the list. To do so, the location-service could send to the user's terminal a "Select Location" web page (e.g., HTML page or HDML card), which lists some or all of the user's available speed codes by name. At block 112, the user may then select a desired item from the page. In response, the browser would send a signal to the location-service, indicating the selected item. The page could be programmed with the speed code corresponding to each location listed on the page, in which case the signal that the browser sends to the service could indicate the speed code. Alternatively, the service could otherwise correlate the selected item with the user's corresponding speed code. Still alternatively, the description (name) of the location selected by the user could be considered the user's specific code for that location. So that description could be returned as the speed code. At block 114, the service could then correlate the speed code with the corresponding global code, if the service received the corresponding global code from access system 22. Alternatively, the service could send the speed code to the access system and ask access system 22 to provide the global code. Provided with the global code, at block 116, the location-service may identify the location coordinates corresponding to the global code. For instance, the service could send a message to the access system 22, asking the access system to provide location coordinates corresponding to the global code. In response, the access system could query the Global Table and return location coordinates. Alternatively, the user may opt to enter a location code, as indicated at block 118, rather than selecting one from a list. In response, the location-service may send a message to access system 22, seeking the corresponding location coordinates. In turn, at block 120, the access system will determine whether the entered code is a speed code or is a global location code. If codes are distinguished by length as described above, for instance, this can be done by determining the length of the entered code and then concluding that the code is either a speed code or a global code. If the code is a speed code, then the access system could determine the global code by reference to the User Table, as shown at block 122. The access system could then determine the location coordinates by reference to the Global Table, as shown at block 124. Or if the code is a global code, then, at block 126, the access system could determine the location coordinates by reference to the Global Table. The access system could then report the corresponding location coordinates to the location-service. Further, if the user's terminal has a local copy of the user's speed codes and corresponding plaintext descriptions, the user could invoke an application (i.e., a client application or a server application) that reads the local copy and presents the user with list of the codes and/or descriptions. The user may then readily select an entry from the list and provide the corresponding speed code to the location-service. For instance, the application may automatically transmit the speed code to the location-service. Alternatively, the application may present the speed code to the user, and the user may manually communicate the speed code to the service. The service can then translate the speed code into location coordinates, by reference to the User Table and Global Table for instance. Once the location-service has identified the location coordinates that correspond to the code selected by the user, the location-service may then continue, providing a service based on those location coordinates, as indicated at block 128. For example, the location-based service may invoke a mapping engine to provide the user with a map of the location. As another example, provided with the user's current location and a location of another entity, the service could invoke a routing engine to provide a user with a plan for travel between the user and the other entity. As still another example, the service could provide the user with weather or traffic reports for the designated location. As another example, a user may call or otherwise access a voice-command platform (such as a VXML-based web site, or an IVRU accessible by telephone for instance), and the platform can prompt a user to select a location service, such as a business-locator or other service. Once the client selects the service, the platform could prompt the user to speak a voice description that has been associated in the database with a speed code for a particular business, and the platform could responsively get the corresponding location from the location-code system as described above. In this scenario, if the database has only text versions of location descriptions, the platform might convert the spoken description to text, and that text can be used as a user-specific code (i.e., a speed code) to search for the location. Alternatively, if the database has a voice description (such as a digitized voice signal) corresponding to various locations, the spoken voice description can be used as a user-specific code (i.e., a speed code (e.g., a "voice speed code")) to search the database for a corresponding location. Other examples are possible as well. 6. Database Maintenance As noted above, the database system (e.g., the Global Table) can associate with each location code a field that indicates the last time the code was accessed. This field can be updated with the current date each time the location code is used. In the exemplary embodiment, provisioning system 20 can be programmed to periodically review the database system and to delete location code records that are older than a predetermined time period (such as a year). When a global code is deleted, all speed codes that refer to the global code would preferably be deleted as well. This way, a location code provider can manage the size of the database system. 7. Conclusion An exemplary embodiment of the present invention has been described above. Those skilled in the art will understand, however, that changes and modifications may be made to this embodiment without departing from the true scope and spirit of the present invention, which is defined by the claims.
|
Same subclass Same class Consider this |
||||||||||