Patent Application
20170206211
The present invention relates to computer-network-based mapping systems.
Many online databases are concerned with data items that are inherently location based. For example, an online database of hotels or a database of real estate listings or a database of weekend garage sales can all have locations in the form of street addresses associated with them. In all these cases, the location information is an important aspect of each item, however, in many systems there is no easy way for the user to interact with the location aspect of the data.
For example, it is known to provide a web-based system that shows maps with numbered icons in response to a user's query. For example, if the user requests information on hotels in Miami, the system will show the user what hotels are available by displaying numbers at the locations on the map corresponding to the hotels. The user has to look up the number of the hotel on a legend, to find out what hotel corresponds to the number, and the user must then follow a link to another web page to obtain information about that hotel.
An improved system for presenting location information in response to a user's query is desired.
In some embodiments, a method comprises the steps of: transmitting a map request from a client computer to a server; receiving in the client computer data representing a map from a map server; receiving, in the client computer, dynamic, location-based data from a content provider separately from the data representing the map; generating within the client computer a rendering of the dynamic, location-based data overlaid on the map; and displaying the rendering on the client computer.
In some embodiments, a method comprises the steps of: transmitting a map request from a first user at a first client computer to a web server, including a request for data representing a map provided by the web server, and for user-defined location-based data stored on a second client computer operated by a second user but not permanently stored on the web server, wherein the user-defined location-based data are transmitted from the second client computer to the server in a transmission initiated by the server in response to the map request; receiving, in the first client computer, data representing the map; receiving, in the first client computer, a representation of the location-based data, wherein the server transmits the user-defined location-based data to the first client computer separately from the data representing the map; generating within the first client computer a rendering of icons representing the user-defined location-based data overlaid on the map; and displaying the icons on the map at the first client computer at corresponding locations to which the location-based data pertain.
In some embodiments, a method comprises the steps of: transmitting a map request from a client computer to a first web server, the map request including a request for data representing a map that is stored in a second web server and for location-based data that are stored in the first web server, wherein the first web server requests that the second web server transmit the data representing the map and the location-based data to the client computer in response to the map request from the client computer, and the second web server obtains the location-based data from the first web server; receiving, in the client computer, data from the second web server representing the map separately from a representation of the location-based data; generating within the client computer a rendering of the user-defined location-based data overlaid on the map; and displaying the user-defined location-based data on the map on the client computer at corresponding locations to which the data pertain.
U.S. Provisional Patent Application No. 60/471,822, filed May 20, 2003, and U.S. Patent Application Publications US 2004/0073538 and US 2005/0027705, and U.S. Pat. Nos. 6,240,360 and 6,317,686 are incorporated by reference as though set forth herein in their entireties.
This description of the exemplary embodiments is intended to be read in connection with the accompanying drawings, which are to be considered part of the entire written description.
An exemplary method of presenting location based items, integrated with a geographical map, allows the user to obtain detailed information about the items and their spatial relationships, and to control their display.
The term “items” as used herein are not limited to public, historic or well known landmarks and attractions, but broadly cover a wide variety of objects or locations, such as buildings, monuments, artworks, tracts of land or other items that may be of interest to any person, for either tourist, commercial, residential, academic, historic or religious reasons, for example. Thus, a hotel, a restaurant, a store, a ski resort, an airport, an apartment, a house, a housing development, or a city, a church, a bank, a school and a hospital may all qualify as items, and may be considered landmarks or attractions. Additionally, items could include dynamic location based information such as atmospheric conditions at a particular location, the position of a vehicle, environmental measurements taken at specific locations, for example.
An exemplary system allows the user to specifically input special queries on the data, and superimposes the results on a map graphically. For example, the user may input a query for hotels within a particular price range, and the user is also able to visually locate the hotels that are close to restaurants, the beach or other landmarks the user wants displayed. The user is also able to view information, integrated with the icons, without having to go to another web page to see those details. Various types of landmarks and attractions are all embedded in the map, and the user can selectively display the desired types of landmarks as icons on the map.
For example, in the case of the hotel database, the user may want to do any of the following:
The above examples easily translate to other areas, such as real estate, where users might want to filter data based on proximity to highways, schools, their work and other factors such as rent or the number of bedrooms. For example, in a real estate application where the user wants to view homes for sale on a map, one of the input criteria could be houses within 10 miles of a given school, or within five miles of the school and 10 miles of a given highway on-ramp. Although this example finds items within a given radius of a landmark, other embodiments may find items within a specified restricted boundary. In still other embodiments the search looks for items, ‘between’-bounding box or corridor around a route. If the route is a straight line between two selected points, the search looks for items within a rectangle containing the two points. If the route between two points is defined by a plurality of connected line segments that extend in different directions, the search can identify items within a given corridor or perpendicular distance around any one of the line segments. In the real estate example, the database of landmarks may contain more items of interest to home buyers, such as the locations of schools, bus stops, train stations, shopping, hospitals, churches, synagogues and mosques, and the like.
Although the example shown displays the results of the search query without ranking them against each other, in other embodiments, a local search relevance algorithm is used to provide a list of what elements are involved in determining relevance for local searches (e.g., distance, title, category, word index from official web site or the like). Optionally, a weighted score can be computed for each item, based on the values of these attributes.
In other embodiments, the mapping facility may be used for a business-to-business directory. The item types may correspond to vendors of various goods and/or services. Thus, a business person, in seeking to locate a branch office or factory, may wish to see what resources are available to serve that business, as well as businesses that may be potential customers.
In some embodiments, the mapping facility permits the user to specify location queries using a non-postal addresses (e.g., using a landmark name, business name, or personal address book) for use as a local search input parameter. Such embodiments could include generating a map using one of the landmarks as a center point, or generating a map of a corridor of a user specified width connecting two landmarks. For example, a query might include parks within 25 miles of a route connecting Big Sur Park and Muir Woods Park in California.
An exemplary implementation of the above concept is described for a hotel database. In this implementation, a variety of travel-related items are displayed on the map, including hotels, airports, restaurants, attractions, and the like.
Each map is defined by its center point (e.g., latitude/longitude or any other geocoding standard), the zoom level and the items that are displayed on it. Although the example refers to longitude and latitude, one skilled in the art would understand that this can be any type of geocoding technology.
Each class of items on the map is represented by a respective icon. For example, hotels are displayed by icons depicting a bed. It is possible to have unique icon designs for individual items as well.
For any given map defined by its center point and zoom level, only items that fall within the geographical area of the map are displayed by the system. Furthermore, only items that meet the user's filtering criteria (e.g. hotel price <$100/night) are displayed. It is possible for the user to change the filtering criteria and request that the map be updated to reflect the changes. In this implementation, it is possible to filter hotels based on their price, but also by size, amenities, association or other user defined criteria.
Some embodiments allow the user to navigate around the map by zooming and panning around. These functions are achieved by clicking around the map and the zoom level controls, respectively.
Some embodiments allow the user to restrict the display of the items to a certain radius around the map center. For example, the user may want to only display hotels within a 2 mile radius of the map center.
Some embodiments allow the user to toggle the display of entire classes of items. For example, the user may choose to view only hotels and restaurants. In some embodiments, this is achieved using checkbox controls associated with each class of items.
Different classes of icons may be displayed at different zoom levels. The detail level is adjusted for the user's zoom level so that when the user is at a very high zoom level, e.g., the street level, more street level details are visible. For example, hotels are only of interest to the user at relatively high zoom levels (city, neighborhood or street level), but not at low zoom levels (state, country or world). Therefore, hotels are only displayed at high zoom levels.
On the other hand, when zoomed out, only very big items like cities and ski resorts or airports that might be of interest to people on a large (e.g., continental U.S.) map would be displayed. For example, major airports are relevant at all zoom levels and are therefore displayed at all zoom levels.
If the user requests a San Francisco map, at that level, the system will try to fit San Francisco city inside the map, and determine the appropriate zoom level. If, on the other hand, the user has selected a hotel, for example, and wants to see it on the map, then the resulting map is more zoomed in so that only the vicinity of that hotel is displayed.
In some embodiments, the user selects the zoom level that fits within the map (for example, by selecting one of the zoom controls 106). In other embodiments, if the user inputs a query that requests sites (e.g., hotels, restaurants) within a user defined radius of a city or center point, the map automatically zooms in or zooms out to accommodate that radius.
Each item's icon 104, 112, 114, 116 allows the user to interact with that item. For example, hovering the cursor of the mouse (or other pointing device) over an icon allows the user to view a summarization of pertinent information about that item.
It is also possible for the icon to allow the user navigational choices (by clicking on the icon). For example, in the case of a ‘city’ icon, the system can allow the user to jump to a higher zoom level and re-center the map around the center of the icon with one click. Alternatively, the icon may have hyperlinks to other parts of the information system. For example, in the case of a hotel, one link may allow the user to visit another screen with more detailed information and another link that allows the user to book a room in that hotel. In some embodiments, venue or restaurant seating charts are overlaid with information on specific seating availability and price. This feature allows the user to select which seats he or she would like to purchase.
The system can display special (distinctive) icons for items that are not positioned on the map but nonetheless may be of interest to the user. For example, in the case where hotels are displayed, the user may want to know where the closest airport is situated. The system can display a link that adjusts the map state such that the closest airport is brought into view.
In some embodiments, the links are shown visually on the map. For example, if the user is looking at the center of San Francisco, and San Francisco International Airport is to the south of the city, an icon may be displayed on the south border of the image that points in the general direction of San Francisco Airport. For example, as shown in
In other embodiments, a link (not shown) is displayed next to the airport category that says, for example, “Take me to the closest airport.” For example, when the search is performed, a larger radius may be used than the radius that currently fits on the map. The system would recognize that this airport is close by (e.g., within 100 miles), but it doesn't fit on the map, so the link or specific icon is displayed that allows the search and jump so the user is able to see that item.
It is also possible for the user to ‘select’ an item/items and obtain navigational information about them. For example, selecting a hotel would allow the user to obtain the distance of other items in relation to the selected hotel, or obtain driving directions from the selected hotel to the other item.
In some embodiments, this capability is provided graphically. For example, the user can select any of the items as a first point. Then the user can select any other item on the map as a second point and obtain extra information. For example, the system may identify the distance between the two points and, optionally, provide the driving directions from the first point to the second point. Additional information such as the approximate driving time between the points and/or the direction of a straight path connecting the two locations may optionally be provided. In some embodiments, the locations of the two points are fed to an existing driving map and distance program, such as the Yahoo! maps driving direction feature. Alternatively, the system can calculate the distance between the two points from the latitudes and longitudes of the two points using trigonometric functions (or other view coding format). The result will be a web page generated by Yahoo! maps. (I.e., the results are presented in a Yahoo! web page, as opposed to just extracting the driving direction in raw form and displaying them in a front end interface.) In other embodiments, when the user selects two points, the user is presented a link to such a driving map and distance program.
Synchronized List
Some embodiments, in addition to enabling the user to display items on a map representing any point with a geographic location (businesses, landmarks, events w/venues . . . etc), also allow the user to display a list that corresponds to all the points being displayed on a map. In some embodiments, this option allows two modes of identifying or finding a the point on the map: the user can select the icon on the map corresponding to the point in order to highlight the item in the list, or the user can select the item in the list in order to highlight the corresponding icon on the map. This mode may support the display of multiple sets of results as well through segmenting the lists.
In some embodiments, the paid advertisers' items are listed separately from the icons corresponding to non-advertisers. For example, the items for the paying advertisers may be included at the beginning of the list, or in a first list above a second list (which contains non-advertisers). The paying advertisers' items may also be in a font that is larger, brighter, differently colored, or otherwise expected to increase the likelihood of capturing a user's attention.
The results can be further filtered and sorted to refine the results sets a user receives in the application. These actions cause both the results on the map 1602 and the corresponding list 1604 to be modified to fit this new criterion.
Displaying Advertiser Business Locations on a Map
As noted above, in some embodiments, in addition to the normal types of icons that can be plotted on a map, a map can also be used to include icons paid for by an advertiser. These icons may be paid for and provided in a variety of ways.
For example, in some embodiments, the advertiser may pay a cost per 1000 impressions (abbreviated as “CPM”) rendered. A CPM advertiser would pay a predetermined fee to the business that provides the maps, for every 1000 times that the advertiser's icon is displayed on a map generated by the method and system described herein.
In other embodiments, the advertiser may pay on a pay-for-performance (PFP or pay per click) basis. In these embodiments, the PFP advertiser would pay a predetermined fee each time that a user selects (e.g., clicks on) one of the interactive icons. In the case of the map with a synchronized list described above, payment would be based on the user either selecting one of the interactive icons or selecting the corresponding item in the text list. In another variation of PFP, the advertiser may pay based on conversions. For example, if clicking on the icon for a restaurant generates an online reservation form, the advertiser may pay the service each time that an online reservation is made using that online registration form.
The CPM and PFP options are useful if, for example, the advertiser wants to promote a physical business location. These locations are highlighted on a map and possibly on the corresponding list view of results as well. In some embodiments, the results can be distinguished visually or given higher prominence on the list, but it is not required they be displayed this way. For example, a generic restaurant icon can be displayed on the map for non-advertisers (restaurants in the database that do not subscribe to the map generating service), whereas paid advertisers may be indicated by an icon that is larger, brighter, and/or distinctive to the advertiser's business (e.g., the company's logo). For example, a restaurant corporate logo 1620 could be displayed. In some embodiments, the advertiser has the option of specifying a map icon or small logo specific to its locations to further visually distinguish the item. For a PFP listing, payment may be received either for a click on the icon/list or tracked based on a link embedded within the additional information that shows up on the informational window for the item.
The advertiser icons to be displayed on a map are determined by the various algorithms of a standard ad server or PFP engine (inventory available, % delivered on campaign, time . . . etc). Ads may be scheduled based on a measure of “urgency.” For example, the measure of urgency can be based on the fraction of ads yet to be scheduled for an ad campaign, divided by the remaining fraction of the total duration of the campaign. In addition to these, the points representing locations of the items must fall within the map area being displayed (geographic targeting). In some embodiments, the paid advertisers' icons are only displayed if they correspond to the query term.
In other embodiments, the paid advertisers' icons are displayed so long as they correspond to the category for the search, regardless of whether they satisfy the user's query criterion. (For example, a paying restaurant's icon may be displayed even if the restaurant's price range is outside of the price range selected or input by the user.) Preferably, an indication is automatically provided to the user via appearance of the icon or some other display feature to notify the user if a given icon is being displayed due to a paid advertisement that lies outside of the range of the query criteria, so that the user is not misled by the displaying of the icon that does not satisfy the search criterion.
In some embodiments, the advertiser has the ability to specify the content and the link contained within the pop-up informational window 1608 for the item, if one is used.
User Interaction with Selection of Points
In some embodiments, once a user has plotted locations on a map and has a list of results that satisfy a query, the user has the ability to further customize or control the items displayed on their map by selecting only a subset of the items displayed that the user wants to continue to appear on the map. When the user executes one or more subsequent queries, the items selected for continued display remain on the map following a subsequent query, even if the items do not satisfy the search criterion of the subsequent query. These items can be selected across or on several different layered-on query results.
For example,
As an example of layered-on results, the user may select a subset of the items displayed in response to a first query as a first set of items for continued display. The items in the first set are subsequently displayed along with the results of a second query. The user can select a second subset of the points that are displayed in response to the second query, to be included in a second set of items for continued display. Subsequently, when a third (or fourth) query is executed, the first and second sets of points are displayed along with the items that satisfy the search criterion of the third (or fourth) query.
In some embodiments, the user is then provided the option to print a view of the map and the list that contains only the points that the user selected for continued display across the single or multiple queries.
In some embodiments, the software supports the ability to automatically readjust the zoom level to most appropriately display only those points selected for continued display. If this automatic capability is included, then preferably, the user is provided an option to override the default zoom level in the application.
The software used to customize the points plotted (by selecting points for continued display) can be executed either on the server side or on the client.
Preferably, a function is provided (not shown) to enable the user to switch back to the “default” non-customized view of the results with a single click. Following execution of this function, each map only includes the items that satisfy the query in response to which the map is displayed.
The duration these custom points are “saved” by the system can vary depending on the needs of the application, but can range any where from a single session with the application to being permanently saved to an address book associated with the user.
Implementation Details:
Some embodiments take advantage of the fact that correspondence between a given address and a latitude/longitude pair does not change, by storing this information in a cache (e.g., a cache 414 located at the mapping application or at the user's host). In cache embodiments, the geocoder 408 does not need to do the translation every time the user retrieves the same address. In other embodiments, each time the user types in an address, the geo coder is used to find the latitude and longitude of that address.
In a preferred embodiment, the geocoder 408 has the ability to perform interpolation for a street address that is in between the two closest locations in the latitude/longitude database. Linear interpolation may be used, although higher order interpolation is also acceptable.
An exemplary list of the data fields or attributes in the database for each item may include:
name
oid—unique identifier for the item. This is used to link an icon to more detailed information on a separate page.
description
latitude
longitude
min/max price—used for display and filtering purposes (optional)
type—the category for the item (hotel, restaurant etc. . . . )
zoom—values are 1-9 and indicate the appropriate zoom level to display the item if the user decided to zoom in on the item (The value “9” means street level, such as a hotel. The value “5” means city level, used for ski resorts, airports)
zoomhigh, zoomlow—the range of zoom levels to display the item on the map when the user is browsing around. For example, for hotels, the value of zoomlow may be “6” and the value of zoomhigh may be “9,” so that hotel icons are only displayed from the city level down to the street level.
url/title1,2,3—each item can display hyperlinks in its pop up display (e.g., for a hotel links may be provided to: make a reservation and/or to read more information. For a ski resort, links may be provided to: read more information and/or determine current conditions and/or buy lift tickets.
It will be understood by one skilled in the art that other data fields could be included, including metadata fields such as key words associated with the business or with the item, hours of operation, special promotions, and the like.
In some embodiments, the content database(s) are all owned and operated by the owner of the mapping application. Other embodiments use structured local data to find appropriately matching web content and attach this content to the structured data to enhance it.
The data items in the database 402 are processed through the geocoder component 408 and their address information is translated to a latitude and longitude. This information is used to display each item at the correct location on the map.
The search engines can be hosted locally or on remote servers, or the entire system can be on one device. The remote servers can even include third party servers. The communication between the mapping application 400 and the search engine 404 occurs over standard internet protocols (e.g., hypertext transport protocol, or HTTP) and the results from the mapping application are formatted in a parsable format (e.g., Extensible Markup Language, or XML). This design allows the system to easily incorporate items from disparate sources. Any other appropriate communication protocol may be used.
At step 500, the mapping application 400 receives a query from the user. The query may request a particular type of landmark or attraction near an address. Optionally, the query may specify a radius within which the map is to be displayed.
At step 502, when the user requests display of a particular hotel, then the system finds the center point. For example, the center point may be the address of the hotel, so the system will have a center point, which the system can use to generate the image.
At step 504, the type of query (e.g., a query based on the type of landmark specified, or a query based on a radius around a given location) is determined.
At step 506, if no radius is specified, the map server selects the zoom level as a function of the type of landmark(s) identified in the query (e.g., hotel, restaurant, airport or the like). For example, if cities and airports are specified, lower zoom levels are used than if hotels and restaurants are specified.
At step 508, if a radius value is specified in the user's input query, the zoom level is determined as a function of the radius. The zoom level will ensure that the map displayed is slightly larger than a circle having the radius, so that items at the edge can be displayed.
At step 510, the appropriate zoom level is selected.
At step 512, once the map server 406 knows the center point of the map to be displayed, it uses the Yahoo! map server to generate a correct map image of that area with the correct zoom level. To do so, the map server would need to provide an address for the center point of the map.
At step 513, an array may be input containing identification of the types of items to be displayed on the map. In some embodiments the array is input graphically by a set of checkboxes that are checked or unchecked by the user. In other embodiments, the user can input the item types using text entry. In other embodiments, they are saved locations.
At step 514, the mapping application 400 queries the one or more search engines 404 for data items matching the user's filtering criteria and geographic constraints. These data items are initially loaded from the content database into the search engine.
At step 516, items returned from the queries to each search engine 404 are combined into one result set. For each item in the result set, the mapping application 400 translates the latitude and longitude information to a Cartesian (x,y) pixel coordinate. This information allows the correct placement of the item's icon on the map image. This is essentially a geometric transformation.
At step 517, the mapping application 400 generates a response to the web browser 412 containing the map image, the data items with their pixel coordinates and the rest of the user interface components. The user is then able to interact with the system by initiating another request to the mapping application.
For example, at step 518, if at least one icon is selected, step 520 is performed.
At step 520, if only one icon is selected, then at step 522, the interface application jumps to another web page linked to the icon. (In some embodiments, the user must click on a button in addition to selecting the icon to cause the jump, or a double-click may be used to cause the jump).
At step 520, if two icons are selected, then at step 524, the distance between the two locations and/or travel information is displayed.
If no icon is selected at step 518, but the user hovers the cursor over one of the icons at step 526, then at step 528 a summary of information about the selected landmark or attraction is displayed.
In the user interface of
In this embodiment, a note 650 with an asterisk (*) appears in the display indicating that “Categories are not available at the current zoom level.” The asterisk automatically appears next to each attraction category (e.g., hotels, restaurants, shopping, tourist sights, nightlife venues, ski resorts and recreational facilities in
In the example of
In
One of ordinary skill in programming can readily select the appropriate type of information to be made available for other types of items.
At step 1400, the process begins by connecting to a source of restaurant information, such as an automated contact management system. Other sources of restaurant listings, such as an electronically formatted yellow pages directory, or commercial search engine databases may be used.
At step 1401, a loop of steps 1402-1418 is performed over all restaurants in the contact management system (or other restaurant list), to prepare them for submission to the search database.
At step 1402, the address of the current item is converted to a latitude and longitude, for example, using a geocoder as described above. The geo coder is responsible for converting an address to latitude and longitude. In a preferred embodiment, the geocoder also supplies a measure of the precision with which the address is converted.
At step 1404, a determination is made whether the precision determined at step 1402 is at least street-level precision so that the item can be displayed at the correct street level detail. If the precision is at least street-level, then step 1408 is executed. If the precision is less than street level detail, step 1406 is executed.
At step 1406, the program skips to the next restaurant if the correct precision is lacking. This is based on the assumption that for restaurants, only items that are converted with street level precision should be entered in the database. Many restaurant patrons would be unable to find a restaurant if lesser precision is provided.
At step 1408, the system extracts all the information need for populating the search engine. This may include:
NAME—for display purposes
TYPE—to display the correct icon and allow filtering
DESCRIPTION—for display purposes
LAT/LONG—latitude and longitude of the item so that
1) the search engine can perform geographical queries
2) the icon can be placed at the correct location on the map
ZOOM HI/LOW—the zoom levels where this item should be visible on the map
MIN/MAX PRICE—the price for this item to allow filtering on price
RANK—a number that is used for prioritizing the display of items when there are more items to display on a map than there is room.
OID—unique contact management system identifier for this object for linking to other information about this item.
At step 1410, the system constructs a summary description of the item by considering:
(a) the editorial review of the item;
(b) whether it has received a top-pick rating;
(c) the cuisine of the food served at the restaurant; and
(d) the price range of the restaurant.
In some embodiments, the system blends ratings from multiple sources (e.g., ratings from Yahoo! users and ratings from other editorial sources). An exemplary system blends varying editorial and users' ratings from multiple sources into one unified rating score, using standardized scoring. In a preferred embodiment, the editorial reviews are given a higher weight than the user reviews.
At step 1412, a determination is made whether the restaurant is recommended (for example, by a restaurant critic, or a service such as “ZAGAT™”. If the restaurant has a high rating, then step 1416 is executed. Otherwise, step 1414 is executed.
At step 1414, a determination is made whether the restaurant has a high usage on the website (i.e., the restaurant is the subject of a high number of queries.) If there is a high web site usage, then step 1416 is executed. Otherwise, step 1418 is executed.
At step 1416, the rank of the restaurant is increased.
At step 1418, the item is stored in the search database.
One of ordinary skill can readily construct customized applications for other specific item types, to increase the functions available for displaying those item types.
At step 1500, a loop of steps 1502-1512 is executed for each type of item to be displayed on the map. For example, this loop may be repeated for every item type having a checked checkbox, as shown in
At step 1502, a determination is made whether the current zoom level is within the range of allowable zoom levels for the current type of item. As noted above, each item has a minimum zoom and a maximum zoom level. For example, in some embodiments, display of restaurants may be limited to zoom levels showing street level detail. If a map is being displayed at a zoom level where the finest detail is a city, then the current zoom level would be outside of the range for display of restaurants, and restaurants inside the current radius would not be displayed. In preferred embodiments, a message is displayed if the current zoom level lies outside of the range of allowable zoom levels associated with a type of item selected for display. This alerts the user that the absence of this type of item on the map is not an indication that there are no items of this type within the current map radius. If the current zoom level is outside the range for this item type, then the loop returns to step 1500 for the next type of item.
At step 1504, the loop of steps 1506-1512 is executed for each item within the current item type. The system can check each item in the database, and only further consider the items for which the type attribute matches the current type.
At step 1506, a determination is made whether the item is located within the current radius of the center of the map. In some embodiments, the current radius is a function of the current zoom level. In other embodiments, the current radius may be either an optional filter criterion or a mandatory input parameter entered by the user. If the item is located outside of the current radius, then the item is not added to the map, and the loop returns to step 1504 for the next item of this type. If the item is within the current radius, then step 1508 is executed.
At step 1508, a determination is made whether the current item satisfies any additional filtering criteria that the user may have selected to be displayed in the map. In some embodiments, such as travel information mapping programs, or shopping information programs, the additional filtering criteria may include distance from the center of the map, distance from another selected item, or price range. However, filtering criteria based on attributes associated with any of the item types may be used.
For example, in a restaurant information application, the user may be provided the ability to filter and only display restaurants that have received a predetermined minimum level of approval from a reviewer in one or more categories from the group including food quality, service, or ambiance. Within the restaurant type, subcategories may also be established, such as the cuisine, and the user may be able to filter restaurants to only display those restaurants serving a particular cuisine, such as, for example, Indian food.
Other filtering criteria may be tailored to each application and item type. For example, in a real estate application, the user may be provided the ability to display only school districts in which the average scholastic aptitude test score exceeds a threshold level.
If all of the filtering criteria selected by the user are met, then step 1510 is executed. Otherwise, the next item is considered beginning at step 1504.
At step 1510, the item is added to the list for display on the map.
At step 1512 a determination is made whether there are more items for this type to be evaluated. If there are more items, then the loop of steps 1504-1512 is repeated. If there are no more items of this type, then step 1500 is executed, to begin the loop for the next item type.
At step 1800, a set of search results are received from a search engine.
At step 1802, a loop is executed for each of the items in the search result set.
At step 1804, a determination is made whether the item corresponds to an advertiser or not. If the item corresponds to an advertiser, step 1806 is executed. If not, then step 1808 is executed.
At step 1806, the item corresponding to an advertiser is added to a first list.
At step 1808, the item corresponding to an advertiser is added to a second list.
At step 1810, the items in the first list are displayed above the items in the second list. This may include listing items separately by category, and within each category, displaying the items from the first list above the items from the second list, so that the list is divided into twice as many sections as the number of categories.
At step 1902, a user selects an item on the map or an item on the list by, for example, clicking on the item or holding the cursor over the item.
At step 1904, a determination is made whether the selected item is an icon on the map or an item on the list. If an icon on the map is selected, step 1806 is executed. If an item on the list is selected, then step 1910 is executed.
At step 1906, the items on the list are searched, until the item is found which corresponds to the selected icon on the map.
At step 1908, the matching item on the list is highlighted (e.g., by reverse video and/or larger font and/or different font and/or different color from other items on the list).
At step 1910, the icons on the map are searched, until the icon is found which corresponds to the selected item on the list.
At step 1912, the matching icon on the map is highlighted (e.g., by different icon and/or different color from other items on the list, and/or larger icon size).
Although selection devices are discussed above, all of the above described functions may be done using voice activation.
Although browser based user interfaces are described above, the above described functions may be implemented for use with an alternative user device, such as, for example, a personal digital assistant, which may provide wireless internet access.
At step 2000, an initial result set is displayed containing the results of a query.
The result set is displayed so as to provide a means for enabling a user to select at least one item for continued display. For example, checkboxes as shown in
At step 2002, a user's selection of a subset of the displayed items is received, for example by way of checkboxes checked by the user. Identification of the items in the subset is saved.
At step 2004, the user makes a new query.
At step 2006, a next result set from the additional query by the user is received.
At step 2008, the subset of items selected by the user at step 2002 is combined with the result set of step 2006.
At step 2010, the combined result set (including the selected subset of items and the results of the most recent query) is displayed. Thus a means is provided for displaying the selected item(s) on the map simultaneously while displaying items found by a subsequent query, regardless of whether the at least one selected item satisfies a search criterion used in the subsequent query.
After step 2010, steps 2002-2010 may be repeated any number of times. During each iteration of this loop, the user can any of the currently displayed items to the selected subset for incorporation into the combined list, and can also delete any previously selected item in the subset (for example, but un-checking the corresponding checkbox).
In the above example of
At step 2102, the client computer transmits a map request to an application server. The map request may be initiated when, for example, the user clicks on a link or button on a web page rendered by an application server, in order to request a map, or enters a text based request.
At step 2103, the application server requests map data from a map server and location-based information from a content server. If the location-based information is provided in a format other than latitude-longitude coordinates (e.g., if street addresses or intersections are provided), a geocoder 408 (
At step 2104, the application server transmits the map data from the map server to the client, and the client receives the map data.
At step 2106, the application server transmits the dynamic, location-based data from the content provider to the client, and the client computer receives the dynamic, location-based data from the content provider separately from the data representing the map. The application server can transmit the map data and the location-based data sequentially, or in parallel streams. Either way, the map data cover a complete map, including the areas that will subsequently be obscured when the location-based data are overlaid on the map.
At step 2108, the client computer assembles the various data streams (map, dynamic, location based data) and generates a rendering of the dynamic, location-based data overlaid on the map. The application server sends a plurality of different images and instructs the client to overlay them on top of each other in a particular order, so that the location-based information appears on top of the map. In addition, if two or more types of location-based data are to be overlaid on the map, a predetermined front-to-back order is used, so that if two types of location-based data values are provided at a given point, a predetermined one of the types of location-based data is always shown on top. For example, in a display of traffic data including vehicle speed and construction/traffic-incident indicators, the construction/traffic-incident indicators may be selected to always appear on tope of the speed indicators, so that construction and accident locations are readily visible on the map.
At step 2110, the client computer displays the rendering. The rendering is displayed with icons representing the traffic data on the map at map locations corresponding to the locations represented by the icons.
By allowing the assembly of information to occur in the browser of the client computer, it is possible to overlay interactive icons on the map, for example using HTML.
The exemplary system also allows rapid updating of maps that contain overlaid dynamic data. For example, upon client browser refresh, updates to the dynamic, location-based data can be downloaded from the content server to the application server, and then to the client, and overlaid onto the previously downloaded map data, without requiring a retransmission of the map data. Only the dynamic overlaid data needs to be updated. This is particularly efficient, because the map data comprises a substantially larger number of bytes than the location-based data. The map data would only need to be replaced to change zoom levels, pan, or start a new map.
At step 2202, the client computer transmits a map request to the application server. The application server requests map data from a map server and traffic information from a content server. The traffic content server may be of a type shown and described in U.S. Pat. No. 6,317,686, which is incorporated by reference herein in its entirety. The content server provides updated traffic data to the application server, either on a periodic schedule, or upon the occurrence of a predetermined event (e.g., car accident, road closure, etc.), or as a combination of the two. In a preferred embodiment, the content server provides at least the following information: the average speed of vehicles at a plurality of points, locations of road construction work, and locations of traffic incidents. The location can be uniquely specified by latitude and longitude, so each speed value can be designated by a latitude-longitude-speed triplet. Other optional information may include, for example, road surface conditions.
If the traffic feed identifies the location of each latitude-longitude-speed triplet with sufficient precision, then it is not necessary to identify the direction of travel. Because the locations of roads are static and known, the location of any given point will determine the correct side of the road for which the vehicle speed is being provided. Based on whether autos drive on the right side of the road (e.g., in the U.S.) or the left side (e.g., U.K.), the direction of the traffic can be determined from the latitude and longitude. In other embodiments, the traffic feed may use an alternate format for specifying the location of each point, such as specifying an intersection. In such embodiments, a geocoder as described above can provide the application server with the latitude and longitude of each point.
In some embodiments, the application server, content server and map server are located in a single host computer. In other embodiments, the map server and content server are located in one or two separate computers, other than the computer hosting the application server.
At step 2204, the application server receives the map data feed from the map server.
At step 2205, the application server transmits the map data to the client. The client receives the map data.
At step 2206, the application server receives the traffic data from the content provider (traffic data feed).
At step 2207, the application server transmits the traffic data to the client, and the client computer receives the traffic data, separately from the data representing the map. The application server can transmit the map data and the traffic data sequentially, or in distinct parallel streams.
At step 2208, the client computer assembles the map and traffic data streams and generates a rendering of the traffic data overlaid on the map. The application server sends a plurality of different images and instructs the client to overlay them on top of each other in a particular order, so that the location-based information appears as interactive icons on top of the map. The map is at the back, with the traffic data on top thereof. Preferably, construction, incidents, or other events that disrupt traffic are overlaid on top of more routine indicators, such as speed indicators.
At step 2210, the client computer displays the rendering.
In the exemplary embodiment, the user of the client computer can interact with the icons representing the traffic information.
At step 2212, the user can hold the cursor of the pointing device over one of the icons, such as an icon representing a traffic incident or road construction. If so, then at step 2214, details of the traffic incident or road construction are displayed. If not, then step 2216 is performed.
Referring again to
In
Although exemplary text boxes 2314 (
In the example of
In some embodiments, the speed indicators are not interactive, so that no function is performed when a speed indicator is selected. In some embodiments, the speed indicators 2510a, 2510b are interactive icons, and selecting (i.e., clicking on) one of the speed indicators 2510a, 2510b causes a display of the average speed value at that specific location, or the range of speeds over a short, immediately preceding period (e.g., the last 5 or 10 minutes). In other embodiments, selecting one of the speed indicators 2510a, 2510b causes the system to zoom in to the next higher level of magnification.
In other embodiments, instead of representing the speed indicators as dots on a map, they are represented as highlighting the parts of the road that they represent. So, visually they would appear like lines that are overlaid on top of the lines on the map. These overlaid lines may have a thickness that is the same as (or different from) the thickness of the lines on the map, with a distinctive color or pattern that is recognizable according to a legend that is displayed near the map. These embodiments may calculate, based on the traffic information, how long is it will take for a vehicle to reach its destination, or allow comparison and selection between one of two routes based on current traffic conditions.
Host 2710 contains a map server 2712 that provides maps of the requested cities at the requested (or calculated) zoom levels, and a storage device 2714 for the maps. Preferably, the map server 2712 is hosted in a separate computer from application server 2702, but this is not a requirement. The host 2710 may also contain the geocoder, for generating a latitude and longitude corresponding to any street address information that is provided.
One or more content servers 2722 provide the data content that is to be overlaid on the maps. Preferably, the content servers 2722 are hosted in one or more computers 2720 separate from the computer 2700 hosting the application server 2702, but this is not a requirement. This content may be any of the types described above, and may be stored in a local storage device 2724. The content may be provided by a plurality of servers. For example, tourist attraction data may be fed from a first server, traffic data from a second server, weather data from a third server, etc. The content server host 2720 may also contain a web application 2726 that provides users access to the mapping application by way of a different interface, as discussed further below.
The system in
Client host 2750 may host personal web pages and/or store location-based data suitable for displaying on maps. In one variation of the method, the user of client host 2750 may wish to present his/her location-based data on a map for display by another user (e.g., a friend), such as the user of client host 2740. For example, the user of client 2750 may wish to share vacation descriptions of places visited or photographs taken at various locations, allowing friends to view a map with interactive icons overlaid on each location visited or at which a corresponding photograph was taken. Clicking on one of the icons causes display of the photograph taken at the location indicated by the icon and/or additional text and/or playback of audio information provided by the user of client 2750. This is just one example, and any type of location-based data may be used.
The exemplary application server 2702 allows the client 2740 to display maps with the location-based data from the second client host 2750 overlaid thereon, while the second client host 2750 stores the location-based data locally in storage device 2754, without permanently storing the data in the storage device 2704 of server host 2700. According to this variation, individual users can act as private content providers for the system. Rather than turning their location-based data over to the server 2700, the user of client 2750 maintains control of the data and responsibility for storing the data permanently (or for as long as it is to be made available for other users), and controls access to the data. The client 2750 can make the location-based data and maps available to the user of client 2740 through a hypertext link provided in an HTML message from email application 2758, or on a web page 2756 hosted on client 2750. The server 2702 does not need to maintain any type of index of the privately maintained location-based data stored in storage device 2754.
At step 2604, the recipient uses the link in the message or web page to visit the web page of the application server 2702 associated with the mapping function.
At step 2606, the client computer 2740 requests that application server 2702 generate a map with the location based information from the content owner's computer 2750. Preferably, all the information concerning the location of the content needed by the application server 2702 is also provided to the application server automatically when the client computer 2740 clicks on the link to access the application server. In other embodiments, the step 2606 of requesting the map and location-based data of the content owner is a separate step that is performed manually using instructions in the message or web page that invites the recipient to view the map.
At step 2607, the application server 2702 requests the map data from the map server 2712. In some embodiments, the map server 2712 is in a separate host 2710 different from the application server host 2700. In other embodiments, the map server 2712 is in the same host 2700 as the application server.
At step 2608, the map server 2712 provides the map data to the application server 2702.
At step 2610, the application server transmits the map data to the first client computer 2740.
At step 2611, if the location based data is in the second client, then step 2612 is performed.
At step 2612, the application server 2702 requests the location-based data from the second client computer 2750, using the path information provided by the first client to the application server. (This is part of the information originally provided by the second client 2750 to the first client 2740 via the link in the email or web page).
At step 2614, the application server 2702 receives the location-based data from the second client computer 2750. The application server 2702 is not required to save the location-based data locally in any persistent or non-volatile storage device.
At step 2616, the application server 2702 can transmit the location-based data to the first client computer 2740 without permanently storing the location-based data in the server computer 2700.
At step 2618, the client application 2746 in the first client computer 2740 generates a rendering of the location-based data overlaid on the map.
At step 2620, the client computer 2740 displays the rendering in the first client's web browser 2744. The client can interact with the map by holding the cursor over or selecting one of the icons overlaid on the map, in the manner described above.
The method of
In addition, the above method allows a portal or Internet service provider (ISP) to offer the mapping service to its users without having to assume the responsibility or expense of providing any long term storage for the content. At the same time, it allows the portal or ISP to control the quality and/or limit the type of content that it is perceived to endorse by making such content available to the general public.
The above method also improves system efficiency over a mapping system in which all the rendering of content overlaid on maps is done on the server side. The recipient client 2740 can generate the maps with overlaid location-based data locally in the browser 2744 of host 2740, which allows the recipient computer to interact with the data locally, in ways that would not be practical if the rendering is generated in the server host 2700 and transmitted to the client 2740 as a single image. The client host 2740 can cache any maps and location-based data it receives in a local cache 2743, for generating revised renderings of the map with different subsets of the location-based data on the map. In many cases, this allows the client to generate the revised renderings without downloading the same information from the server 2702 all over again. If the user subsequently issues a request for different location-based information overlaid on the same map, the cache 2743 can provide the map, and the client 2740 would, at most, only have to obtain the location-based data for the second query.
The ability for the client to generate the local renderings from the cache is enhanced if related location-based data are proactively transmitted each time a request for a map is sent to the application server. For example, at the time the map and the location-based data are transmitted to the client 2740, the server 2702 can obtain (“pre-fetch”) from the content owner computer 2750 all of the location-based data in the designated portion of the storage device 2754 in host 2750, or all of the location-based data pertinent to the geographic area covered by the requested map. Upon a cursor roll-over or upon selection of one of the interactive icons on the display of host 2740, the additional data describing the item associated with that icon on the map can be obtained locally from the cache 2743, instead of issuing a request for the information from the server 2702.
In another example for using the system shown in
For example, the web application 2726 may provide an online classified ad service, of a type provided by such web services as www.craigslist.com. The application 2726 may allow its users to query the web application 2726 for all the advertised items meeting a given query criteria (e.g., three-bedroom apartments in the San Francisco area that allow cats and dogs). But the web application owner may not want to incur the expense of developing a mapping capability. Instead, the web application 2726 could include a button or hyperlink on its page for displaying the query results on a map. Upon selection of the button or hyperlink, the web application 2726 can automatically transmit a map request to application server 2702, including the locations of all of the points to be overlaid on a map (either in latitude longitude format, or street address format). In some embodiments, the content owner does not want to transmit any of the query-result data (except for the locations of points) to the application server 2702, and the rendering consists of non-interactive symbols overlaid on the map, with no text or additional information. For purpose of maintaining confidentiality and avoiding transmission of its query result information to server 2702, the application 2726 may request the same generic-type icons for all of the queries that it sends to application server 2702. Upon a cursor rollover or selection, the only information that may be displayed would be limited to (at most) street addresses at each point.
In other embodiments, where the content owner is willing to transmit additional information to the application server 2702 for inclusion with the map, the web application 2726 can also send the text that is to be displayed when the user holds the mouse over or clicks on one of the icons. Then the client 2740 can generate a rendering of the map with interactive icons.
The program flow in this example is the same flow as shown in
The present invention may be embodied in the form of computer-implemented processes and apparatus for practicing those processes. The present invention may also be embodied in the form of computer program code embodied in tangible media, such as floppy diskettes, read only memories (ROMs), flash memories, CD-ROMs, hard drives, ZIP™ disks, or any other computer-readable storage medium, wherein, when the computer program code is loaded into and executed by a computer, the computer becomes an apparatus for practicing the invention. The present invention may also be embodied in the form of computer program code, for example, whether stored in a storage medium, loaded into and/or executed by a computer, or transmitted over some transmission medium, such as over the electrical wiring or cabling, through fiber optics, or via electromagnetic radiation, wherein, when the computer program code is loaded into and executed by a computer, the computer becomes an apparatus for practicing the invention. When implemented on a general-purpose processor, the computer program code segments configure the processor to create specific logic circuits.
Although the invention has been described in terms of exemplary embodiments, it is not limited thereto. Rather, the appended claims should be construed broadly, to include other variants and embodiments, which may be made by those skilled in the art without departing from the scope and range of equivalents of the invention.
This application is a continuation in part of U.S. patent application Ser. No. 10/849,083, filed May 19, 2004, which claims the benefit of U.S. Provisional Patent Application No. 60/471,822, filed May 20, 2003.
| Number | Date | Country | |
|---|---|---|---|
| 60471822 | May 2003 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 11137603 | May 2005 | US |
| Child | 15468889 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 10849083 | May 2004 | US |
| Child | 11137603 | US |
