Google patent app shows extensive Google plans for mobile search
A Google Patent application newly published on the United States Patent & Trademark Office website this morning appears to furnish extensive details on Google's plans for enhanced local searches via mobile devices.
Fittingly enough, the Patent app is entitled, Local Search and Mapping for Mobile Devices.
The Abstract gives us a sneak peek, referring to:
A computer-implemented method is disclosed that includes receiving on a mobile device a search query associated with a geographic location, providing one or more search results in response to the search query, the search results each being associated with a geographic location, and presenting on a graphical display of the computing device icons corresponding to each search result and also corresponding to a key on the computing device.
But that's just for starters. To grasp the enormity of what is being described here, I think you should see some art from this application, as well as read the explanation of the Patent art I think you might want to examine.
FIGS. 3a-3b show displays for a local searching operation on a mobile device. Searching on the device may employ a standard search system on a server, such as the Google Local service.
The information retrieved may be specially formatted for mobile display, such as by a webserver connected to the search backend, but configured to provide information particularly well-suited for display on a mobile device (e.g., search results responsive to a query, but relating to a particular town or zip code). View (a) in FIG. 3a shows a local search input box, along with examples of formats that a search may take. When the search input box is displayed, the softkeys may change to reflect activities that are helpful in the entry of data to the search input box.
The user may enter a search request by selecting the "type a new search" hyperlink from the initial view (view (a)), which causes the device to show an empty search input box (not shown). The user may enter a search request that includes location information, such as a zip or area code or other information such as "hotels near jfk" or "pizza in sf." In such a situation, the server that receives the request will parse out and identify the location information, and the search will be conducted around that location. The user may also enter a search request without location information, such as "dim sum," "flowers," or "U Haul."
In such a situation, the local search may be performed on the area shown on the map when the search is performed, or may be based on a centerpoint that is the centerpoint of the map (but perhaps covering an area smaller or larger than that shown in the map). In addition, a location may be assigned for a user to be applied across all searches, or a location may be determined by the device, such as through GPS measurement. The search box may be incorporated directly into the search dialog box also.
A user may then submit the search request, such as by pressing the equivalent of an "enter" key (e.g., pressing the center of a control pad). The request, with appropriate identifying and other information, may then be transmitted to a remote system, such as a local search server system.
That system may recognize the request as coming from a mobile device, and may format the information accordingly, but may otherwise perform the search as any other local search. For example, the system may return information for nine hits so as to correspond to selections that may be made using the nine positive integers on a typical telephone keypad. (A tenth result may be provided for the 0 key also).
Such search results are shown in view (b) of FIG. 3a, where the search term was "pizza." Here, the results are shown in a manner common to Google Local search, with pin icons representing search results.
Each pin icon is shown located approximately over the location of the result (e.g., the address of a restaurant or other business), like a push-pin in a map.
Each pin is also given a number that is associated with a key on the keypad. Pressing the associated key once will cause summary information for the search result to be displayed, such as the business name, as shown in view (b).
The zoom level may be selected so as to avoid getting more than 9 or 10 results, which could not be easily identified with a mobile device keypad. Where additional results exist outside the bounds of the display (e.g., because there are many results or because the user was zoomed in very tightly and display of the search results did not change the zoom level), other selections may be provided to the user for viewing other search results, such as is shown in view (b). Various actions may be taken on the information. For example, a user may press the "send" or similar button on their device to make a telephone connection with the search result--a click to dial transaction.
Also, with mobile devices having small sizes and a limited number of input keys, it may be preferable only to display a smaller number of results on a map at a time to provide for easier viewing and interaction by a user.
Where there are additional "hits" in the area searched, the display may provide some indicator of the presence of those hits located off the initial display. For example, an icon (not shown) could be displayed at each edge of the display where there are additional hits off that side of the display.
Likewise, icons may be shown in the corners when the hits are located diagonally from the displayed initial map (e.g., providing eight directions of possible indicators).
The icons may be similar to the pins that represent hits on a full desktop display, such as for a desktop computer. For example, the icons may simply be circles like the pins, but without extensions below them toward the map, so as to indicate that they represent hits just as the pins represent hits, but that they are not located over their respective hits.
The icons may also take on a different color than the pins so as to distinguish them, may be provided with additional indicators such as arrows attached to or wrapped around the pin heads, and may also be provided with a number that may or may not correspond to a key on the device's keypad.
For example, the number may correspond to the number of hits located in the direction of the icon. As such, the user may be apprised that panning in a particular direction is more likely to be successful than panning in another direction. Such additional direction may be particularly valuable to a user of a mobile device because such a user may not be able to see very much at one time, and may also have much less bandwidth, so that the user has a need to pan more often but more efficiently also.
Movements with the device may also occur in a manner that appears to a user as animated. For example, tiles may be moved smoothly across a display from one panning position to another or from a small zoomed-out or zoomed in display to smoothly enlarge to the post-zoom display size.
In addition, when search results are provided, panning toward a result may cause the display to snap to the next result, either immediately upon entry of a pan command, or when the result is sufficiently close to entering the edge of the display. Moreover, as a user selects different numbered search results, the display may automatically pan smoothly from one result to the next, e.g., placing the new result in the center or near the center of the display.
The user may also press the key relating to a search result a second time (or another key, as prompted) to bring up additional information about the result, as shown in view (c). Such information may include an address of a business along with its telephone number and other contact information.
Again, the telephone number may allow for click-to-dial operations-either by highlighting the number or a "call" hyperlink on the display and selecting it, or by pressing a "send" or similar button when the result is displayed.
Additional choices may also be presented to the user. For example, the user may be provided with options whose selection permits the user to receive directions to the location of the search result or from the location of the search result. The other endpoint for the directions may be selected in any appropriate manner.
For example, where the mobile device is GPS-enabled or otherwise location-enabled, the directions may be computed automatically from a measured location of the device. Alternatively, the user may be asked to enter their current location, and the directions will be provided between the entered location and the location of the search result. Also, particular locations may be stored in a history list, and may thus be selected easily by a user. Additional information about a search result may also be shown, and additional options may be provided for selection by a user.
View (d) shows a subsequent search on the device, where a search history is stored. The display is similar to that in view (a), but now a recent search is available for display in a search history. Thus, a hyperlink for the search "pizza" appears on the display. This history may be helpful, for example, because it allows a user to do the same search but for different areas.
For example, a traveling salesperson may love a particular restaurant chain, and may place the name of that chain into favorites. The salesperson may then repeat that search easily for any town in which the salesperson is located, and may quickly receive results to the search (particularly when an automatic location identifier generates the appropriate map).
When a user selects an item from the search history, the user may be provided an opportunity to edit the item. If such editing occurs, the edited search request may be added to the history list.
FIG. 3b shows similar searching processes with more detail.
In a first view, a map is displayed. A user then selects a right softkey associated by position with the "menu" overlay. Upon selected the softkey, a menu of choices is generated visually over the map, with a portion of the map show through around the menu, so that the display more accurately approximates a desktop windowed system with which users are typically aware.
The user selects "1" and is provided a search box in the third view (and the menu box is removed). The box shows recent searches that the user may enter simply by using a directional key to move down to one of the searches, and then press an activation button. The user may also choose to type a new search using a URL selection or such an option.
In the example, the user enters "pizza 02138," a query that may be transmitted to a central server. The server will parse the query apart and look for local information in it. For example, the system may assume that a 5-digit number in the appropriate location of a query represents a zip code.
The system may also assume that food names, when accompanied by location information such as a zip code, represent an interest in restaurants. Once the user confirms their query, such as by pushing the center of a directional button, the query may be submitted to the central server, and the results sent back.
The next view shows an exemplary display for such a result. As shown, a single result has been generated in response to the search query, and it is a particular pizza parlor.
The user may be given the option to see additional detail about the search result (e.g., by pressing a key such as 1), and such detail is shown in the last display in FIG. 3b. The detail shows the address and telephone number of the particular search result. In addition, certain options with respect to the search result are provided.
One of the options, for example, causes the mobile device to dial and attempt to contact the search result, such as a restaurant that takes reservations. In addition, directions relating to the location of the search result may also be provided, as described next.
FIGS. 4a-4b show displays for a directions operation on a mobile device. Directions may be, for example, a choice under a "menu" item, along with other options like those just discussed. As just noted, a directions operation may also be readily selected from the outcome of a local search request.
Directions may be shown by a line of contrasting color or weight overlaid on a map, and may also include a number of waypoints, where the illustrated path changes directions or changes from one road to another road. Other waypoints may also be provided, such as lookouts or other points of interest along a path.
A user may be provided with a menu to select preferences for particular waypoints that the user would like to have displayed near a route, such as particular stores, government buildings, landmarks, scenic points, etc.
View (a) in FIG. 4(a) shows a first display for entering data for receiving directions. The view provides a user the ability to enter a starting point for the directions. In the pictured view, a user can select a point in two ways--by entering an address or similar locational information, and by selecting a point on a map.
If the user chooses the first option, such as by selecting a corresponding hyperlink, the user may be provided with an empty data entry box into which an address may be entered. T
That address will be sent to a remote system which may then parse it and determine the address to which it refers, in preparing directions to return to the device. The user may also choose a location from a "recent places" list which stores location data and names for locations that have recently been entered into the user's device, or "favorite places" list which displays locations specifically identified by the user as favorites (much like favorite web sites in a standard web browser).
If the user chooses the second option (selecting a location on a map), the dialog will be removed so that the underlying map is displayed, and the user may use map navigation (e.g., panning and zooming) as explained above to place the starting point in or near the middle of the displayed map. The user may then press the center of a navigation key to indicate a selection of the particular starting location.
Once the user has entered the starting point, he or she may enter the ending point in a similar manner to the entry of the starting point. View (b) shows a dialog for entering end point information. Note again that the device may track recently identified locations and present them as "recent places" selections, either for starting points or ending points, to permit quicker identification of a point by a user.
Also, context sensitive softkeys may also be provided, such as an option (in view (a)) to cancel an attempt to receive directions, and an option (in view (b)) to go back to re-select a start point.
Once the start and end points are provided, the remote system (such as a Google backend server) may compute a route and transmit it back to the device for display. The route may be placed over the map in a particular color, with identifiers for the start and end points.
For example, the start point may be a simple green icon, while the end may be a red icon. Also, the path may be in the form of a highlighted or thickened line over the suggested paths.
A dialog can initially be displayed along with the proposed directions. The dialog (see view (c) in FIG. 4a) shows a route overview, e.g., in the form of the start and end points, and a computed distance for the trip.
An additional dialog may be provided showing the user which key to press to start the directions, or a user may simply scroll down through the main dialog to get to the directions. The directions may be simply short-hand statements typical of driving directions well known in the art.
A user can use the keypad (or voice commands, or even GPS readings) to traverse through the route turns, with navigational information appearing in a pop up window in much the same way as the route overview information. A user may move forward and back through a route, for instance, by pressing the 3 and 1 keys, respectively (as shown in the bottom display of FIG. 4b). The device may also display text or icons for cues to the user about this functionality.
The map may additionally animate with the actual progress along a path as a user moves from turn to turn. For example, the text indication for a waypoint may jump from one waypoint to the next, but the tiles may be panned smoothly so that a first waypoint is initially positioned near the middle of the screen and then a second waypoint is moved onto the screen (if it is initially off the screen) and then into the middle of the screen. Appropriate tiles may be retrieved, in a tile-based system, to show the map between the two waypoints. Also, the map may rotate so that the user's course on the map is always view-northward (i.e., to the top of the device.