WO2006014439A2

WO2006014439A2 - Hotspot location record database

Info

Publication number: WO2006014439A2
Application number: PCT/US2005/023861
Authority: WO
Inventors: Anne Benzancon; Craig Lurey
Original assignee: Jiwire
Priority date: 2004-07-06
Filing date: 2005-07-05
Publication date: 2006-02-09
Also published as: WO2006014439A3; WO2006014439A9

Abstract

A method of dynamically maintaining a searchable database of information relating to hotspots includes obtaining information relating to hotspots from time to time from hotspot providers or other hotspot information sources, or both. The new hotspot information is translated according to uniform database rules that apply to information received from multiple different providers or other sources or both. A new unique location identifier is assigned for each new hotspot location to a new location record. The location identifiers are unique even though the database contains information relating to a same location obtained from multiple different providers or other sources or both. The database is updated based on the new information by creating a new hotspot location record for each new location, and for each existing location record, updating or deleting the existing record, or leaving the existing record unchanged, wherein the database contains multiple hotspot location records corresponding to hotspot locations and further includes therein information relating to attributes of one or more hotspot providers or other hotspot-related items, or both, for each location.

Description

Hotspot Location Record Database

BACKGROUND

1. Field of the Invention

The invention relates to hotspot databases, and particularly to a hotspot database and corresponding search engine including searchable hotspot location records. Search results include single records for hotspot locations corresponding to multiple hotspots, and preferably include a map and other location and attribute information. The database may be a main database or a subset database created by applying a filter to the main database.

2. Description of the Related Art

Conventional Wi-Fi search sites provide a database of hotspot records that can be searched according to certain criteria such as primarily geographical location, and specifically using one or more items that can be found in a post office address. Some of these search ' engines include those found at JiWire.com, which belongs to the assignee of the present invention, and to WiFinder.com and Wi-FiPlanet.com. The search engines usually then provide an alphabetical list of hotspots associated with the location and/or other criteria. Because there are multiple service providers for many hotspot locations, multiple hotspot records appear in the results. This is inconvenient for the user of the search engine, who is really most interested in finding hotspot locations, and only secondarily interested in the providers at the location. It is therefore recognized in the present invention that a searchable database of hotspot location records would be desirable. It is further recognized that creating and maintaining such a database involves merging multiple provider or other source records such that only unique hotspot location records configured according to uniform database rules and contained in the database will appear in the results of a search.

When a hotspot search is performed either using a conventional hotspot database or the hotspot location database of the present invention, it is often by persons unfamiliar with the geographic vicinity that they are searching. Such persons may be business or vacation travelers who have long since identified Wi-Fi access hotspots in their home town, but not where they are staying temporarily. Thus, a search results record that only includes street address information may leave the traveler still not knowing how to get to the hotspot locations identified in the search results. It is desired to provide hotspot and/or hotspot location database search results that provide not only street or postal address information, but also allow a person unfamiliar with the local area to find the hotspot locations appearing in the results.

Certain entities may wish to have a searchable database of hotspot location records that is customized depending on marketing goals, business strategies and/or requirements of their own customers, investors, advertisers, etc. These entities may be interested in prioritizing or emphasizing hotspot records having certain characteristics. It is desired to have an efficient way of providing search results based on predetermined priorities and/or promotional criteria, and further to provide a database that is commensurate with yielding prioritized or promotionalized results.

SUMMARY OF THE INVENTION

In view of the above, an advantageous method of dynamically maintaining a searchable database of information relating to hotspots is provided. New information is obtained relating to hotspots from time to time from hotspot providers or other hotspot information sources, or both. The new hotspot information is translated according to uniform database rules that apply to information received from multiple different providers or other sources or both. A new unique location identifier is assigned for each new hotspot location to a new location record. The location identifiers are unique even though the database contains information relating to a same location obtained from multiple different providers or other sources or both. The database is updated based on the new information by creating a new hotspot location record for each new location, and for each existing location record, updating or deleting the existing record, or leaving the existing record unchanged, wherein the database contains multiple hotspot location records corresponding to hotspot locations and further includes therein information relating to attributes of one or more hotspot providers or other hotspot-related items, or both, for each location.

A filter may be applied to obtain a subset of the hotspot records having or not having a particular attribute. Logos or other objects may be appended with predetermined records within search results.

A geographical map may be provided with search result records including hotspot location icons appearing approximately at their geographical locations on the map with search results.

The method preferably further includes parsing hotspot provider information from the new information, and creating or updating a hotspot location record with the remaining provider-generic location information. A hotspot record that is linked to the hotspot location record may be created or updated including the information that has been parsed from the hotspot information.

In another advantageous method, customized search tables are provided from a dynamically maintained database of information relating to hotspots. New information relating to hotspots is obtained from time to time from one or more hotspot providers or other hotspot information sources, or a combination thereof. The new hotspot information is translated according to uniform database rules that apply to information received from providers and/or other sources. A new unique identifier is assigned to each new item of information that is unique. The database is updated based on the new information by creating a new record, updating or deleting an existing record, or leaving an existing record unchanged, wherein the database contains multiple records corresponding to information relating to attributes of hotspots. A filter is applied to obtain a searchable subset of the hotspot records having or not having a particular attribute.

Unique identifiers may be assigned even though the database contains information from multiple different providers or other sources or both. A logo may be appended with predetermined records within search results.

The provision of the dynamically maintained database may include the steps of operations set forth in any of the above or below methods, including obtaining and translating new information data, assigning unique identifiers, and updating the database based on the new information. A filter may be applied to create a subset database that may be more efficiently searched when only certain records of the main database are desired to be searched.

In addition, a hotspot location record database is provided including at least a provider table, a location table and a hotspot table. The provider table includes a provider record with a provider identifier for each of one or more hotspot providers and contains information relating to attributes of one or more providers. The location table includes a location record with a location identifier for each hotspot location that contains information relating to geographical, postal address or other location-specific attributes of the location. The hotspot table includes hotspot records with hotspot identifiers for combinations of hotspot providers and hotspot locations. Information relating to hotspot locations are uniquely identified within the database according to uniform database rules.

A venue table including identifiers for particular brands and/or a location type table including identifiers for particular location types may also be included. The hotspot table may include provider record identifiers (PRID) supplied by providers and/or other sources linked to corresponding hotspot identifiers. The location tables may include latitude and longitude coordinates corresponding to geographical hotspot locations. The locations tables may be searchable by search queries including location-related terms and yielding location records as results. The results may include a geographical map with hotspot location icons appearing approximately at their geographical locations on the map. The database may include a subset of records adhering to one or more applied filter criteria to a main database. The database may include records having promotional priorities appearing in search results. The appearance of priorities may include a logo included with one or more search result records. The appearance of priorities may include promoted records appearing nearer the top of search results than otherwise similar records. The location records of location tables may include links to hotspot records of the hotspot tables. The hotspot records of the hotspot tables may include links to corresponding hotspot provider tables.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 illustrates tables within a database including a hotspot location table, a hotspot table, a provider table, a location-type table, a venue table, and city, state and country tables, in accordance with a preferred embodiment.

Figure 2 illustrates some of the tables of Figure 1, further including a pricing table, having links to other tables within a database in accordance with a preferred embodiment.

Figure 3 illustrates data flow in accordance with a preferred embodiment.

Figures 4a-41 illustrates administration in accordance with a preferred embodiment.

Figure 5 a illustrates a feature of providing location and access information and a quick start guide with a location record linked to an index list result in accordance with a preferred embodiment.

Figure 5b illustrates a map with icons designating hotspot locations in accordance with a preferred embodiment.

Figure 6 is a flow diagram illustrating a method of maintaining a hotspot location record database in accordance with a preferred embodiment.

Figure 7 is a flow diagram illustrating a method of providing a hotspot database subset based on applied filter criteria in accordance with a preferred embodiment.

Figure 8 illustrates filters that may be applied to hotspot and location tables to create subset databases in accordance with preferred embodiments. SOME DEFINITIONS

Hotspot providers can be any company, individual or entity that operates or provides service or equipment or otherwise performs any act for a fee or other compensation, or for free under whatever circumstances, that enables, promotes or furthers the access, use or provision of wireless connectivity or communication, such as connecting to the internet or other communications network, communicating with other wireless enabled devices, communicating with RF transponders or other such chips or cards, etc. Each provider is assigned a unique provider ID in a database table in accordance with a preferred embodiment of the invention. Examples may include router or bridge and antenna device providers, Wi-Fi connection service providers, hotspot device providers, etc. A Wi-Fi connection service provider typically is either an operator or an aggregator and has billing and support relationships with end users. A provider record includes information relating to a hotspot provider and may include information pertaining to one or more hotspot provider attributes such as name, pricing, contacts, sales support, etc.

A hotspot location is a particular place that is fixed in space, wherein network access or communication is possible using a wireless-enabled communication device, such as a Wi- Fi-enabled laptop computer, phone, PDA or other device or product using radio-frequency or other wireless ID or other such technology. Typically, hotspot locations are at commercial or residential buildings, a transportation gateway such as an airport or train station, a campus, a city center, a library, a government building, etc. Although a hotspot has a geometrical extent from the physical equipment within which a wireless-enabled device may connect or communicate, the hotspot location may be represented by a specific latitude and longitude at sea level or at the level of the ground at that specific latitude or longitude or the actual level of the access point (AP) or other communication device. The location may be represented by a postal address or a portion thereof such as street address, city, state, zip code, and/or a business or household name. A hotspot location can be identified by further attributes such as contact person, location type and/or venue group (see below). Each hotspot location is assigned a unique location ID within a database in accordance with a preferred embodiment of the invention.

A location record includes information relating to a hotspot location, and may include location name, address, contact information at that physical venue, location type, geocode (latitude and longitude), etc. An address may include country, region, city, zipcode, and/or street address (including airport code if relevant). Location data may be preferably objective and fixed, and is preferably not dependent upon provider or other source of the location information. Location data is what preferred program tools logic is based on.

A location-type is a generic term for a service, product, action, event or significance primarily understood for a location. Location types may be hotels, restaurants, airports, residences, coffee shops, malls or stores, city squares, college or secondary school campuses, campus locations or classrooms, or other business, personal or recreational areas. Each location type is assigned a unique location type ID in the preferred database.

A venue group is a particular brand, franchise or type other than the generic types that are represented as location types and location type IDs. Venue groups can include particular companies, brands, or groups of people, places or businesses. For example, companies or brands such as Starbucks®, McDonalds®, Campgrounds of America or KO A®, AARP®, or other groups, clubs, organizations, etc. may be represented as a venue group and may be assigned a venue group ID within the preferred database.

A hotspot may be a combination of a particular location and a particular wireless communication-enabled device. Other attributes of a hotspot may include whether an access service is pay or free, whether the hotspot is 802.1 Ib or 802.1 Ig (and/or 802.1 Ia, 803.16, 802.20, etc.), the particular routing and/or bridging hardware and antenna-type, software, drivers, MAC address, bandwidth mechanism, whether it is DSL, cable, Tl, modem, etc., airport code, phone number, photographs, logos, whether there are restrooms, the operating hours, another communication-related attribute, or any other characteristic or attribute that may be useful for a hotspot user to know. Many of these may be associated with either the location or the communication characteristics of the hotspot, while there may be attributes of a hotspot that are not categorized either as location or communication attributes. A hotspot record includes information relating to a hotspot, and may contain a combination of location data and communication-related data such as access provider data, and may further include optional provider specific information such as SSID and pricing.

Quality of data is generally a measure of how much information is given in a user friendly format and how standard is the information. Accuracy of data is generally a measure of how relevant the data is to its users. High quality data is not necessarily accurate, and vice versa.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

It is desired to have a comprehensive database of hotspot locations. The database preferably contains information about that location for any or all of multiple providers that may service that location. The database preferably includes information regarding several advantageous attributes regarding that location, with some attributes being provider-generic and some being provider-specific. The database is preferably searchable by one or more of its multiple attributes, and/or is browsable according to certain predetermined rules, so that a person or entity interested in knowing current information about hotspots having certain attributes such as location, etc., may do so by searching or browsing the database.

OBTAINING CURRENT HOTSPOT INFORMATION

Current records are maintained for hotspot locations in a preferred database, and preferably also for hotspots for each provider, as well as location-types, venue groups, etc. These records are generally accumulated from information received from providers from time to time. Alternatively, infoπnation may be received from venues, the locations themselves, or by a specialized entity assigned to the task of obtaining and sending current hotspot information. Some of the preferred information is indicated in the above definitions, The desired information that generally does not change about a hotspot or hotspot location include the latitude, longitude, postal address, etc. The owner, contact person or organization, franchise-type, brand-type, and location-type are other attributes that generally remain constant, but sometimes change. The providers at particular locations will often change from time to time. The hardware or software of the access point machine itself may be updated or changed. Other attributes include whether a particular service is free or requires a fee, and if so what type of fee, whether the site is 802.1 Ib or 802.11 g/a, what the bandwidth is and what is the bandwidth type, airport codes, phone numbers, whether there are bathrooms, whether they serve coffee, food, alcohol or otherwise, whether there are waiters or only counter service, whether there is parking, whether there is indoor and outdoor access, etc., etc.

The information may be provided in electronic format as entered into script fields of forms. The information may be extracted by the database to update or create records within tables of the database. The provider or other source may send raw data or data within these forms. Providers or other sources may also be provided with there own subset or duplicative databases that they may update themselves based on rules using electronic forms.

Providers usually provide the information, and notwithstanding the origin of the information, at least some of the information is generally provider-specific. Thus, provider- specific records and IDs are maintained for communicating in a relationship with each provider. Providers may request and be transmitted information from the database based on information that they have provided and/or other information provided by other providers or by other sources, but these provider-database relationships are preferably maintained separate from relationships with other providers or other sources in order to maintain the uniqueness of IDs in relational communications, in the main database and in any subset databases.

UPDATING DATABASE RECORDS BASED ON THE CURIlENT INFORMATION

The information received from providers or that is otherwise associated with particular providers is maintained uniquely for each provider. Even hotspot information and IDs that are generic with respect to providers are uniquely maintained and distributed for each provider. Unique IDs are also assigned and understood by the database as being associated with locations, providers and other hotspot attributes. In this way, relationships between the database and each provider are maintained separately from other relationships, so that within each relationship, it is irrelevant what IDs may be associated with location, provider or other attributes for other relationships.

Information relating to hotspots is either received from each provider or is otherwise gathered regarding the provider periodically or otherwise at multiple points in time. Separate records are maintained for each hotspot location that a provider services. From time to time, locations may be added or deleted, or may be updated or unchanged, for each provider. Multiple providers may provide information relating to a same hotspot location. That information which is provider-generic, or the same for each provider, as it relates to a hotspot location is preferably parsed from provider-specific information so that unique and singular hotspot location records can be maintained in a hotspot location table, as well as hotspot and provider record tables, venue and location-type tables, city, region, country, and pricing tables, etc.

Thus, the information received from the providers is parsed of provider-specific attributes in order to create location records preferably indexed in the form of a location table including records that may be searched for in a generic sense with respect to any provider, such that the records themselves preferably only include provider generic information within them and the different provider-location combinations, or hotspots, do not uniquely qualify them within the location records table. That is, once the hotspot information is parsed of provider-specific information, a location record may be created and searched for as being unique from other location records because it is physically at a different location. A location ID will correspond to all of this location-specific and provider-generic information for a particular location.

Hotspot records and tables are also maintained in the database, wherein the location records, tables and IDs are combined with provider attribute data, and optionally other data. The hotspot records will include provider record IDs both as provided by the provider and as assigned to that provider according to database rules. The database will maintain a unique serial ID and provider ID for hotspots and providers, respectively, and provider record IDs (PRID) for each provider per hotspot. The unique serial IDs for hotspots are assigned by the database, while the provider-specified record IDs (PRIDs) may be assigned by the providers or other sources themselves.

Referring to Figure 1 which shows exemplary tables T1-T8 of a database in accordance with a preferred embodiment, and referring specifically to hotspot table Tl, provider ' 1 ' will be understood by the database as being associated with a particular hotspot location with location ID 'xyz' and hotspot ID 'abc\ Provider 1, which may be, e.g., Tmobile, will refer to the record that it has provided as PRID 'def for that location. Provider 2, which may be, e.g., Boingo, provides information regarding the same location xyz and refers to the information that it has provided according to provider record ID PRID 'ghi', and the database assigned a hotspot ID 'jkl'. A third provider '3' also provided information about a hotspot designated by the database hotspot ID 'mno' at a different location 'uvw' than the location of the first two hotspot record indexed in the hotspot table Tl, and so on.

Tables T2-T8 illustrate provider, city, region (state, e.g.), country, location, location- type and venue tables. Of course, other tables may be created based on other information such as pricing, equipment, amenities, etc. The location table T6 is highly advantageous because it is the locations of hotspots that end users particularly wish to search for. They may wish to study the provider information of locations within location records, but they are inconvenienced by multiple records appearing for a same location just because there are multiple different service providers for that location. The location table T6 illustrated in Figure 1 includes location IDs for the locations xyz and uvw. The xyz location turns out to be a Starbucks, located at 123 Main Street in Portland (City ID 123), Oregon (region ID 45), USA (country ID 1), having zip code ID 678. Actual zip codes are not preferably used because different countries generally use their own zip code systems and overlapping zip codes can provide ambiguities, although they may be alternatively used and the system may follow up an input search query with a question as to which of the multiple regions of the world having the inputted zip code is actually being requested. The specific geographic location of this Starbucks hotspot location having location ID xyz is shown in Figure 1 and table T6 as 45.45 latitude and 30.3 longitude. The location type ID is 5 for cafe, and the venue group ID is 34 for Starbucks.

The location table T6 does not show any provider IDs. This is because the location table preferably does not include provider IDs, nor PRIDs nor hotspot IDs, even though links are provided to hotspot records from location records that result from search queries. This way, search queries yield single results for each location that matches the criteria, and links from those results to whatever providers or hotspot records are available are provided within the location record. The city ID, Region ID, Country ID, Location-type ID and Venue ID within the location record T6 correspond to records in the corresponding tables T3-T5 and T7-T8 shown in Figure 1.

The main searchable or browsable database contains the unique IDs associated with locations, providers or other attributes for each hotspot. A location search that is not expressly, separately limited by provider search constraints will yield results that show the different providers (if there are different providers) associated with each location that comes up within the search criteria. When there are different providers at a same location, then a search record for that location will show that multiple hotspots are associated with it.

Figure 2 illustrates six records that are linked within the database. A location table record T6R is shown with several IDs corresponding to different location other attribute information, as well as names and numbers corresponding to actual information. The actual information portions are simply contained that way in the record without a link to another table, whereas the IDs that are provided link the location table record T6R to other records. For example, the venue_group_ID and location_type_ID of the location table record T6R, provide links to the actual venue group and location type information contained in location_type and venue_group records T7R and T8R, respectively.

A hotspot record TlR includes a location ID that provides a link to the location record T6R, as well as a provider ID that provides a link to the provider record T2R. A pricing record T9R may be linked to the hotspot record TlR, either by itself or with an additional link to a provider record T2R. Venue group records such as the exemplary record T8R of Figure 2 may also include links to pricing records such as record T9R, e.g., when a franchise has a promotion.

Information received from particular providers or other sources is mapped to a unique or universal information set that is the main database. When information comes in from a particular provider or other source, that information is designated with IDs corresponding to the main database, and a map is created or updated if previously created, for that provider or source. The map translates IDs both way, i.e., from provider or source to database, and from database to provider or source. Other users of the database do not see this mapping that takes places between the providers and other sources of the information and the main database records. The providers or other sources themselves will not receive main database records or IDs in database communications, which will utilize the language and IDs of the provider or source. Even when information from the database that was not obtained from provider 1 is communicated to provider 1, that information is translated to the language and ID set that is separately maintained for provider 1.

When information is received from multiple providers or other sources, each item of information has to be uniquely identified and correlated with other database information before being included into the database. Thus, each item of information from a provider or other source will not only be mapped according to certain mapping criteria that correspond to that provider or source, but each item will also be assigned one or more unique IDs, i.e., that are unique even with respect to information obtained from other providers and sources, however many there may be.

Separate subset databases may be maintained depending on customer preferences. For example, a customer that wishes to have a searchable database of only 802.1 Ig hotspots, or only of Boingo hotspots, or only of environmentally-responsible hotspots, or McDonalds' hotspots, or only a particular provider's hotspots, etc., may be provided a subset database that already has records removed that do not meet the universal criteria that customer desires for all of its searches. Promotional subsets may also be provided to certain customers, wherein priority is provided to venues, locations, etc., that have made promotional contributions. This will be described in more detail below with reference to Figures 7 and 8.

DIRECTORY DATA TOOLS

There are several advantages to using directory data tools in accordance with a preferred embodiment. First, they enable scaling with increasing volumes of directory data, both in numbers of locations/hotspots and what information is collected. Second, they help reduce manual labor involved in processing data files, standardizing, normalizing, de-duping and coding data. Third, they serve to increase quality and accuracy of data that may be published on a web site or otherwise provided to customers. Fourth, revenue opportunities may be multiplied by increasing granularity of the data that can be manipulated and published or licensed. Fifth, revenue opportunities may be further increased by having more accurate data of better quality to sell/resell to the emerging marketplace.

There are a few general principles or rules that directory data tools in accordance with a preferred embodiment adhere to. They allow a move from a provider centric approach to a location centric approach (location is fixed and objective, players, technologies and prices change). Second, data may be managed in a simple and efficient way, i.e., to process the same data only once, and then refer or link to it. Third, self-learning tools may be built, e.g., each new case may be incorporated into a "knowledge base" of reference tables and script rules. Fourth, the tools may be made available on the web.

There are generally four different kinds of data that may be obtained from various sources and for various purposes. There is data that seldom changes (e.g., Location, Provider name). There is data that changes frequently (e.g., Provider coverage, prices, promos). There is data which is preferably not published such as provider contact name and email, while there is data that is processed before publishing, such as address data. There is data that is created in the maintenance of the dynamic database of the preferred embodiment such as the various IDs or identifiers, and there is data that is obtained from external sources. There is also data that is fed to third party systems, e.g., Mapquest® may receive address and geocode, while the third party processes the data and returns third party data for output / publishing, e.g., driving directions and maps.

The main components of the data processed by the tools include where, who and what. That is, first, location data that is preferably objective, unique and permanent. Second, data on providers, aggregators, networks, operators, venue groups/franchises, and/or advertisers that is multiple and changing periodically. Third, data relating to the services provided and the price of services that is also multiple and changing frequently. In a preferred embodiment, the flow of data begins with obtaining the data and inputting it, and then processing the data, and outputting it for publication, or collecting, processing and publishing.

The following tools are preferably used to achieve an efficient data flow:

1. Raw provider data file upload and processing tool;

2. Reference tables editing tools (Provider, Location, Location type, Connection type, Venue group/Franchise, etc.);

3. Pricing tool (Batch edit records by provider/franchise/etc, Pricing configurations); 4. Single hotspot add/edit/delete tool, in parallel with the public submission tool;

5. Self Service Enhanced Listings tool;

6. Promos and campaigns management tool;

7. Extranet provider data maintenance tool;

8. Self Service "Thin Frame" co-brands/private label tool.

The following clean-up processes may be performed by tools in accordance with a preferred embodiment:

1. de-dupe the raw hotspot data based on provider/location name/geocode;

2. update/add relevant fields in hotspot and Location/address tables;

4. Review/QA/edit location table for location name, location type and venue_group

5. Capitalize properly all names in region and city tables;

6. Add variations (including language variations) where relevant to region/city/country data;

7. establish provider, equipment or promo verified status per provider in provider table so that the flag is set automatically at each data import;

8. populate the pricing table from the data in both hotspot table (ID) and provider table (default price);

9. provide fee comment in pricing table.

The following describes in more detail four main tools. These and any other tools are preferably easily adaptable for XML feeds/processes, i.e., in anticipation for the WISP Extranet. Also, picklists may be preferably sorted alphabetically.

RAW PROVIDER DATA FILE PROCESSING TOOL

The raw provider data file processing tool preferably does the following. It imports a data file and runs through each record. It matches the imported data to reference tables in a given order of routines with specific outcomes. It outputs 'rejects' from the above process for manual processing. It also outputs clean records into publishing tables in a staging database.

Moreover, it facilitates the creation of new tables and modifies current tables and populates them. Routines may be developed for using the tool with step by step conditional logic for processing of import file into publishing tables, and a web based user interface may be developed. The tools allows special data management needs to be accommodated for customers who desire or request such service.

A standardized provider hotspot data file import process applies to hotspot data files that are sent by providers or other sources according to preferred specs. These involve entering data into certain fields, and/or formatting by a data team to fit the import format. A non-exhaustive list of these hotspot and other record fields is as follows: Reference number (may be provided with format tool); status of the record: NEW, DELete, UNChanged, MODify; Provider Record ID (PRID); provider name; address as a postal address: number, street name, street type (other info preferably in parentheses - if at airport, also three letter airport code first); city; state or region; country; zip code; URL; phone; email; fax; location name; location_type_ID (table of location_type_IDs would be preferably visible from excel spreadsheet or drop down list); node type : 1 for pay, 2 for free); SSID; Fee_comments (input pricing info if rates are different for each hotspot, otherwise general provider rate is preferably displayed); Access Point (AP) Equipment (e.g., Cisco 1200); promo signage (^llO"=no, ^I1l"=yes).

Note that the data entered into these fields may be all included in hotspot record, while the data may be preferably parsed to create a location record, provider record, venue_group record, location-type record, etc. A different process may be applied to files sent by providers or other sources in other foπnats and that need de-duping against existing data. This process describes what preferably happens for each individual provider file containing hotspot location data (i.e., preferably there is no batch processing unless desired on a cases by case based to have a batch file).

A exemplary process will now be described, while those skilled in the art will recognize that many variations of this process exist as alternatives within the scope of the present invention. First, a raw data file comes in with records identified as NEW, DELete, MODify or UNChanged. Records may have a ref# (serves as ID unique to that provider record) which is either the provider's record ID or an assigned serial number. Next, the file is manually checked for integrity. New records addresses are reviewed and split if necessary between address 1 and address2 (address 1 used for geocoding, address2 is additional useful information for locating place). Now, a franchise/venue-group ID is manually assigned to each record having a franchise, brand, venue associated with it. If a file contains data in a particular language, the language records are separated for further processing (manual unique referencing of records to be able to map and tag IDs to language version later). The file is then uploaded via web interface. A user may choose a provider from a picklist (if new provider, create new provider record first). The user may enter an "origin" for the file (usually abbreviation of the provider name and date in YYMMDD format). The user is then asked name of file to upload, or to browse for it on their computer. An import tool accommodates variable column orders. It compares field name headers (to avoid parsing the wrong field content). If the field name headers do not match, a manual field-mapping tool is presented to the user before the process starts, with two windows, showing each the list of field of the raw file on the left and the destination file on the right, to select fields in each and a "MAP" button to associate them. When done, click "start import process". The file runs through several scripts that preferably accomplish the following tasks: a. Assign provider ID to each record; b. Assign origin to each record; c. Distinguish NEW, DELete and MODify records — Unchanged are ignored; d. Match Deletes by Provider ID (based on picklist selection on web) and ref# (or Provider record ID,) to get the hotspot ID and remove the record from the database; e. geocode the MOD and NEW records (based on address fields content); f. If geocoding error, the address fields of the problem record are shown in an editable format with a error message and options for action, preferably including live editing and then clicking "Save Changes", resumes the process (to deal with typos); clicking "Reject record" adds the record to the rejects file, goes to next record; and clicking "Edit relevant reference table" (to deal with different spellings or a genuine new city or region) opens the Reference Table editing menu in a new window. The reference table is chosen, edited and saved, then the window is closed and the process resumes by clicking "RETRY"; g. MOD records get matched by Provider ID, Provider record, and Geocode, to get the hotspot ID. Then, the records are treated as NEW records for the rest of the process, since updating is overwriting fields with newer data (will exclude Location ID which is already correct); h. NEW records are preferably processed as follows. First, compare location name (by similarity search and not exact string match) + geocode to existing records in Location table. The Location table is preferably an upgrade of the current address table, where Location name, Location type, Venue/Franchise ID, and latitude and longitude are added, and duplicates eliminated. Second, if there is a match, assign location ID and finalize import. Third, if there is no match, create a new location record. Creating a new location record may involve the following. Assign country ID based on Country table. If a zipcode is provided, the zipcode is compared either to a database zipcode table, and if there is a match check the country (as there are identical zipcodes in different countries) and obtain the city ID and region ID in the location table, then finalize, or use a commercially available zip code table for certain countries. If no zipcode is provided, then Assign Region ID (if applicable) based on Countries Reference table, Assign City ID, check address and replace strings according to country based rules contained in a format address table, and format the address, and finally compare resulting address data combined with Location Name, with existing data in Location table. Now, if there is a full match on all fields, assign existing location ID, and if there is a match on address but not location name, publish back to the web, for manual comparison of address match (both addresses), location name already in database, and location name provided in import file. Two choices are preferably provided. First, "accept as same location", and second "create new location" (to accommodate for different stores in the same shopping mall, or a McDonald's in a Hotel, e.g.,). If there is no match on address, then create new Location record (including location name, full address, contact info, franchise ID if applicable) with new ID and assign Location ID to hotspot record. The creation of the hotspot record may be completed by importing data from remaining fields (SSID, equipment, etc.), while import should check on formal correctness of email addresses and URLs.

When the process is completed for one record, the next record is processed, until all records in the file have been gone through. Records that are rejected at any step of the process are preferably returned in a text file for manual review and processing of the problem field(s), in order to be uploaded again. Deleted hotspot records are removed from the hotspot table and the pricing table. New records are imported in the proper tables in the relevant databases.

Update records are next imported. Then, new locations are previewed in a list format with only the Location name and Street Address fields in editable format, to allow for final QA before committing to location table. As the location record will generally not change, and gets published, it is particularly desired that it is clean and formatted properly. A message is displayed "file processing done, data imported". A link is provided to "Go QA" the imported data. This preferably opens a search results page containing all newly imported records with public site functionality and "edit" ability from an edit tool. If there are rejects, a link to the text file containing the rejected records appears. The rejects file preferably contains the original file's data, the provider ID and origin in each record, and the address IDs that could be assigned during the process.

A PROVIDER EXPORT contains all records including the newly imported, with the "provider data format" fields only, and is run automatically to generate the data file returned to the provider for update. The file is zipped and automatically emailed to a specified email address, with the name of the provider and the date as the file name. A full EXPORT of the database can be run upon request from the Search/Sort/Filter/Export page, then zipped and sent by email to a specified email address.

REFERENCE TABLES

Each reference table is preferably editable and searchable on the web. These tables form the backbone of a database in accordance with a preferred embodiment. The location table includes street and/or postal address information, to which are added location name, latitude, longitude, location type ID and franchise ID, among other location related fields. The location table contains fixed elements that generally do not change about a given location/venue.

A countries reference table includes current city and region tables. These may be licensed from Mapquest data files and may be grouped in a table that lists country, region and city for each city record, as well as the spelling and language variations for that region and city name, and the correct publishing nomenclature for each language. The table maps all versions of a city/region's name to an ID and to the proper publishing nomenclature for this city /region for each relevant locale. For example, for Austria (where it so happens that Vienna is both a city and a province), the following applies: jntry lD Region Variation CityVaπation City ID name_en name_de name_fr

214 Vienna Vienna 123123 Vienna Wien Vienne

214 VIENNA Vienna 123123 Vienna Wien Vienne

214 VIENNA VIENNA 123123 Vienna Wien Vienne

214 Wien Wien 123123 Vienna Wien Vienne

214 WIEN Wien 123123 Vienna Wien Vienne

214 WIEN WIEN 123123 Vienna Wien Vienne A zipcode table (for countries where zipcodes are used, and for which data is obtained) contains zipcode data which is the next most precise address element after a street address. A given country's zipcode table enables to compare the zipcode in the import record to a reference, and then extract the related city and region. Each country that uses standardized zipcodes (North America, Mexico, Europe) has a reference zipcode table containing a unique ID, zipcode and corresponding city and region names as per the publishing nomenclature. A zip code table may include a record as in the following example:

zipcode ID city ID city region ID region Country ID Country

94610 12345 245678 Oakland 34533 California 1 US

Commercial databases may be purchased or licensed, and reference zipcode tables can be built from existing address and/or location tables, and then added to as new data is processed.

A format address rules table may be maintained on a country per country basis, and provide versions of address expressions/strings and how they should be replaced for processing and publishing purposes. This table may be used to reformat street addresses. For example, for addresses in Germany (ID is 78, e.g.):

Country ID Rule Vaπation Replace with

78 String between spaces Str. Strasse

78 String ending with space str strasse

78 String ending with space str. strasse

78 String ending with space straβe strasse

78 String between spaces Pl. Platz

78 String ending with space Pl. platz

The de-duping of raw files is a preferred tool / process. In the event that a provider or other source sends a data file that is not conforming to expected specs, particularly on the status field (New, MOD, UNC or DEL) or the active/inactive flag, or when data files are obtained from both provider and franchise (e.g., Wayport and McDonald's), a file is run through a de- duping script to accomplish at least two things. First, that provider's records are compared in the latest file sent with the ones that already are in the DB for that provider. This is done to isolate new records (the ones with no match in our DB), records to delete (records in our DB but not in their file), records that match, which we can either update of leave unchanged, active records in our DB to switch to inactive, and inactive records in our DB to switch to active. Second, that provider's records are compared with records received from another source for the same location and provider.

In one embodiment, there are either for each record a unique identifier (provider record ID) used by the provider, and/or a unique venue_id used the franchise (ex. McDonald's store ID), or by default a reference # that is assigned. Preferably, a location ID system is used, wherein files are processed that are subject to de-duping semi-manually before they get imported in the automated tool. An access tool may be used, followed by running a couple of queries on the data, and SQL may be used.

WEB BASED REFERENCE TABLES EDITING TOOL(S)

These apply at least to provider, location, location-type, connection-type, and franchise data, among others. Each table has its own add/edit page with basic functionality.

PRICING RELATIONSHIP MANAGEMENT TOOL

These batch edit records by provider/franchise/etc. , and by pricing configurations, promos, etc. Pricing is determined hotspot by hotspot, and the pricing table populated accordingly based on a one-to-one relationship, per the following preferred hierarchy/order of priority. First, hotspot specific pricing is entered at the hotspot level (hotspot tool). Second, rule based pricing that applies to a group of hotspots for a given provider along a specific combination of criteria are defined in the pricing tool. Third, default provider pricing is entered in the provider tool or the pricing tool.

SINGLE HOTSPOT TOOL (add/edit/delete)

With this tool, the user enters data and not IDs. This tool also accommodates for the creation of hotzones based on a defined radius around the center represented by the address entered.

SEARCH/SORT/FILER/EXPORT TOOL

Website administration preferably offers extensive "advanced search" functionality where users can search the entire DB on any field or combination thereof, and sort results based on provider, country, region, city, zipcode, location name, location type, venue_group, node type, technology type, active/inactive, certification or any other relevant criteria TBD. Searching is done first, and the number of results found is displayed, followed by the message "How do you want the results sorted?". Sorting is done through a succession of picklists listing fields searched on, with the operator "and then" between them, followed by the button "Sort". The sorted results are displayed in rows with the field name at the top of each column. At the top and the bottom of the results listing, there is a button "EXPORT". If clicked, the results are exported to a .txt or .csv file and made available for download through a link displayed on the page, titled with user name, serial number and date.

Other features may include adding an ACTIVE/INT ACTIVE flag to accommodate for providers turning hotspots on and off and on again (repair, roaming negotiations). Certain data may use this flag to operate a private label or subset site. A Network_Drop field may be added with DSL/Tl/T3/Cable options. Hour/day/monthly subscription pricing may be added.

DATA INTAKE PROCESS

Figure 3 illustrates the processing of data in accordance with a preferred embodiment. Hotspot and location data are processed as indicated at blocks 1-6, and provider and pricing data are processed as indicated at blocks 8-9, followed by importing at block 7 and further processing to publication at blocks 10-12.

At block 1, raw data is received from a provider or other source relating to a hotspot and/or a hotspot location and is deemed accurate and timely. This data is verified using a verification process of matching portions of the raw data received with existing records or other verification information. This may be a manual and/or automated verification process. The logic used is at least arranged according to what is possible and not possible, and may be further otherwise arranged. For example, if a US zip code is designated as Topeka, Kansas in an existing record, and the same US zip code is designated as Fort Lauderdale, Florida in the raw data, then block 2 of Figure 3, which corresponds to a verification software module or manual process, will at least flag this data as not being verified. Both records may be checked against a zip code database or table automatically, or may be manually checked, and the incorrect record or raw data information will be updated.

The raw data information is preferably translated, e.g., if the database is an English database and the raw data is in Spanish. Block 3 is a translator module. The translation block 3 may be more or less sophisticated, e.g., translating St., street, and STREET each to Street whenever they appear, in addition to translating between languages. The information is normalized at block 4 as to grammar, syntax, usage, spelling, semantics, or whatever other rules it is desired that the database uniformly enforce when in-processing new or updated records, i.e., the data is formatted and standardized to tables' specifications.

The preferred embodiment includes a self service interface for manually importing new or updated data, i.e., the block 5 is preferably a web-based manual data entry / management tool. Even the manual input of new or updated data is subject to verification script at block 6, or is automatically compared against previous versions for that source and against location reference tables in multiple languages. Errors found are returned for correction. Data records that are manually and/or automatically input are normalized at block 4, and imported to the database at the block 7 import tool. The import tool assigns IDs, feeds back error for correction and populates tables of the database.

So far, the blocks 1-6 have worked with raw hotspot or hotspot location data in creating and updating records. Other information may be imported into the database including pricing information using a pricing tool indicated at block 9 and/or provider record management using a provider tool indicated at block 8 in Figure 3. The provider tool of block 8 is a web-based data management tool for inputting information about providers, and the pricing tool of block 9 is a web-based data management tool for information about pricing of services. These data may be imported into the database at particular tables or subsets of tables or into specific records corresponding to specific hotspots, venue groups, cities, etc.

The database itself includes a verified data module indicated at block 10. This is when the verified data is stored in the database. This represents the data residing or indexed within database tables in condition to be searched. The block 11 of Figure 3 represents a QA process which reviews discreet data sets and includes checks for integrity and content quality. At block 12, data is published or distributed through specific application on various platforms (e.g., web, offline app., XML feed, etc.) and in relevant languages.

Figures 4a-41 illustrate data administration in accordance with a preferred embodiment. Many of the fields in the forms shown are self-explanatory as to what is entered there, and so further explanation will not be provided here. The lettered references in the data administration screens illustrated at Figures 4a-41 are placed wherein some explanation is provided according to the correspondingly lettered paragraphs provided herebelow:

A: choose the task to perform in navigation menu on the left or use shortcuts for most frequent tasks; B: All entry field searches must allow wildcards or search on partial field content;

C: Goes to Create Provider page;

D: "Save" refreshes the page with Provider name, provider ID and origin displayed and a "Cancel" button that resets the page;

E: Once file uploaded, Field name headers are checks and if not matched, a mapping tool is displayed, otherwise the "start import process" button is displayed;

F: As fields are selected on both sides and mapped, they disappear from the list. When done mapping, message displays as below, with button to "start";

H: At the very end of the process, this message is displayed. "GO QA" links to the data staging site, presenting the imported data in a public site search results page format with all new records, and administrative edit functionality. Also provided is a link to download the rejects from the processed file. If not downloaded, the next file's rejects will be appended.

I: Displays the error(s) that occurred while geocoding the file by making the error fields show in RED. User can (i) reject the entire record, (ii) edit the field and "Save Changes" then click "Retry "to rerun the geocoding script, and (iii) click "Edit Ref Table". It opens the Reference Table editing menu in a new window. The reference table is chosen, edited and saved(which closes the window) and the process resumes by clicking "Retry" to re-run the geocoding script;

J: If the address of the import record matches the address of a record in the location table but not its location name, displays both and gives user the choice ( accommodate for different stores in the same shopping mall, or a McDonald's in a Hotel);

K: At the end of the import of all records, the list of all new locations created from this import is displayed with editable Location name and address fields to be QA' d before final message (see above) is displayed;

L: The Pricing table is populated from the data input here, unless Overwritten by specific hotspot pricing info input from the pricing table tool or directly through the hotspot tool. The generic fee comment shows in all hotspots for all the provider records unless like above. If no price info is entered, will display "no info", unless like above;

M: All data to be stored in the provider table itself;

N: Step 1: find the record to edit;

O: Step 2: choose the record from a results list, which displays below;

P: Step 3: Edit the field(s);

Q: Step 1 : choose provider, refreshes with default currency/country based on provider address; R: Step 2: Displays pricing data from provider table, which is default data in pricing table, as editable data. If data is edited and saved, redisplays new data. Preview shows data in live site context with a SAVE button added;

S: Also displays existing rules for that provider if any. Rule name is a link to edit that rule. Also displays button to Create a new rule. Max number of rules per provider is 10. The "delete" rule overwrites specific pricing data in pricing table with default pricing;

T: - Also displays unique hotspot exceptions (set in the hotspot tool);

U: Step 3: If edit existing rule has been clicked, displays that rule's data in editable foπnat. If "create a rule" has been clicked, displays the same form with empty fields. "Save" adds/updates the rule in the existing rules list and populates the pricing table accordingly;

V: The region and city lists are too long to put in a picklist, so we need to validate that the entry exists in the relevant table. Clicking returns a message "yes, entry is correct" or "not in the DB! Try again";

W: Rules priority order: specific hotspot price supersedes all rules, rule supersedes default for all fields, and most recent specific rule supersedes previous (to accommodate for rules that overlap);

X: Saves the rules and displays the previous page with the rale added to the list;

Y: Step 1 : choose whether to create a new record, or edit an existing one via viewing the entire table;

Z: Step 2: if "add record" selected, refreshes and displays the name of the table that is modified, and an entry field for the record content. Once saved, a message displays the Id that has been assigned to the new record;

AA: Step 2 alternate: if "edit/view table" selected, refreshes and displays all records with an "edit" button next to each, sorted in alphabetical order;

BB: Step 3: if "edit/view table" selected and "edit" clicked next to record, refreshes and shows record ID, and content in editable field. Clicking "save" redisplays the updated table as in "view table". NOTE: Display Rule for Picklists: sorted alphabetically;

CC: Airport code search. Results are displayed in a pop-up window, listing all airport codes matching that city with their 3 letter code and full name from the Airport table;

DD: Manual Geocode: latitude and longitude can be entered by hand if data available (useful for certain types of location without standard postal address);

EE: If Hotspot is Hotzone, assign a radius from the geocode of the address (center of the hotzone) with options from 200ft to 1 mile. Radius stored in hotspot table in field "Hotzonejrange" and display on map; FF: Records are set to Active by default and can be set to inactive (for hotspots not yet open to the public, or in testing, but data available already);

GG: Price info populates the pricing table for that hotspot. If nothing is entered, will display default provider pricing, if any. Otherwise shows: no info;

HH: Click on Preview shows geocode error message, or shows existing location match (see Edit location table) or if is new location opens widow with data in context of hotspot detail page with venue tab on top, with a SAVE and a BACK button;

II: Clicking on DELETE displays a confirmation message with "OK" or "CANCEL". If record is ACTIVE, button is "make inactive", and if record INACTIVE, button is "make active", clicking the button changes the status and saves the record;

JJ: If latitude and longitude are edited, user must check the new map by clicking the "preview map" button. The map displays in a pop-up with "save geocode" and "cancel" which both return to this page;

KK: "Preview" shows the hotspot detail page with the venue tab on top with a SAVE and a BACK BUTTON, "Save" directly overwrites the record data (when small change, this is faster). If geocode has been changed and the map not previewed, "save" is disabled;

Note that Figures 4a-41 and the above descriptions are only illustrative of a preferred embodiment. Those skilled in the art will recognize many other ways to implement the concepts of the present invention, and to provide alternative embodiment within the scope and spirit of the present invention.

PRESENTING INFORMATION FROM THE DATABASE

Once a search has been performed, the results will appear preferably on the screen of a users mobile or desktop computer, although audible results, directly printed or faxed results or results that are directly saved in a memory are possible. If a specific location was identified with a radius amount in the search query, then the results may preferably be sorted by distance from the specified location. Other sort criteria may be used, such as by bandwidth, amenities, whether the location and/or hotspot are 'certified', e.g., by an otherwise unbiased testing organization, consumer advocate group or database provider, whether the location or hotspot is free to access, whether coffee is available, whether and how much of a promotional fee has been paid by a venue, location or otherwise, alphabetical, etc., depending on the preferences of the searcher or the full or subset database provider. Features such as location and access infoπnation and a quick start guide are preferably provided with a location record linked to an index list result in accordance with a preferred embodiment as illustrated at Figure 5 a. Also in accordance with a preferred embodiment, hotspot locations resulting from a search will appear on a geographically displayed map with zoom-in and zoom-out feature as illustrated in a hotspot location record at Figure 5b. The hotspot location that is being studied in the exemplary location record of Figure 5 is at 701 Third Street in San Francisco, California. It is at a McDonalds® venue, and Boingo provides 802.1 Ib service there. The map shows an enlarged icon (i.e., near Pacific Bell Park in Figure 5b) corresponding to the particular location record being studied. The map also shows multiple other icons corresponding to locations on the map that are also hotspot locations. The user may click on any of the icons on the map. The icons are links to location records or pages of infoπnation about that hotspot location. Driving directions to the hotspot may also be shown either generically or from a designated location.

The location record illustrated at Figures 5a and 5b was viewable as a link from a list of records that met the search criteria. Those records may be initially provided in a list that may be prioritized according to promotional criteria, nearness to a specific address requested, alphabetically, whether certified by a biased or unbiased organization, etc. For example, a provider, or venue group or specific location may pay a promotional fee for having their icon presented at location records in the search results where they provide service, and/or to be prioritized in the search results listing before other record listings. As mentioned, in accordance with a preferred embodiment, the search results are a listing of hotspot location records including a single record for each hotspot location with links to multiple providers, pricing arrangements, hotspot records, etc., as opposed to conventional listings of hotspots which include multiple hotspot records for same locations.

DATABASE UPDATING AND FILTERING METHODS

Figure 6 is a flow diagram illustrating an advantageous set of steps or operations in a process for dynamically maintaining a searchable database of information relating to hotspots. At S 6 A, new information is obtained relating to hotspots. In order to provide a location record, the information will include at least some location information. The information may include many other kinds of infoπnation, as understood from the above. At this point, or somewhere further along in the process, the information may be parsed, so that provider information is removed and location record-specific information is retained for importing as a new or updated location record and indexing in a location record table. A hotspot record is preferably also created or updated. Provider information is preferably separately maintained in a provider table linked to the hotspot table; the hotspot record table being linked to the location record table.

At S6B, new hotspot information is translated according to uniform database rules. A new unique identifier is assigned to each new item of information and an updated identifier to each updated item of information at S6C. The database is updated based on the new information by creating a new hotspot location record and/or updating existing hotspot location records at S6D. In a preferred embodiment, hotspot records, venue records, provider records, etc., are also created, updated, deleted or left unchanged depending on the new information upon verification.

Referring now to Figure 7, new hotspot information is obtained at S7A, just as in S6A of Figure 6. All of the discussion at Figure S6A is incorporated and not repeated here. S6B is also the same preferably as S7B, and S6C is preferably the same as S7C. At S7D, the database is updated based on the new information. The database may include a location record table, a hotspot record table, a provider table, a venue group table, a location-type table, a city table, a region table, a zip code table, a pricing table, and/or other tables indexing records that end users would like to study.

Now, any of a variety of filters may be applied to the database at S7E to obtain a subset database including only records meeting certain criteria, e.g., having or not having a particularly-input filter attribute. The subset database is created prior to running search queries, and may be for particular groups or for a source web site. For example, the city of San Francisco may wish to publish a searchable hotspot location or hotspot database at its web site. The subset database would be filtered from the main database to include only records having the city ID corresponding to San Francisco. As another example, Starbucks® may wish to provide a searchable subset database at its web site or at computers located at their cafes, wherein the subset database includes only Wi-Fi-enabled Starbucks cafes. As a further example, Cisco® may wish to publish a subset database of hotspots that utilize their routers or other communications equipment.

Figure 8 illustrates how subset databases may be created from the main database. A hotspot table Tl is shown corresponding to the hotspot table Tl discussed with reference to Figure 1. The filter Fl is shown as pointing to provider ID 2. Either all hotspot records not including provider ID 2 or those including provider ID 2 are excluded from the subset. A location table T6 is also shown in Figure 8 corresponding to the location table T6 discussed with reference to Figure 1. The filter F2 is shown as pointing to city ID 123, which may correspond to Portland, Oregon. A subset including only Portland, Oregon records may be provided that may be searched to attain more specific hotspot or hotspot location information within the city of Portland, Oregon, with searches being performed in a fraction of the time it would take to search the entire main database. Filter F3 corresponds to a state or region such as Oregon, filter F4 corresponds to a country such as the United States, and filer F5 corresponds to a location-type ID filter. Such web sites as hotels.com may wish to utilize a subset database that includes only hotels as location-types for hotspots or hotspot locations. The filter F6 corresponds to a venue group filter.

LOCALIZATION

Information regarding hotspots and hotspot locations may be represented differently depending on locale. This is the case as information is gathered to be input into the database, as well as when the data is output as a result of browsing or searching the database. Among the most prominent localized characteristic is language, wherein same locations or other attributes are represented by differently spelled or pronounced words, and for audible input or results, inflections, tones, etc.

For example, the city Cologne, Germany is only recognized as such in English- speaking countries, while in German-speaking countries, the city is spelled Koehln or the equivalent umlaut-containing term, and in Japan, France, Korea, China, etc., the city has a different spelling and pronunciation. Thus, a language translator is included both for translating information as it is obtained from providers or other sources for inclusion into the database, and also for translating database information for presentation. In addition, either multiple language subset databases may be created that may be separately searched according to input criteria of different languages, or a translator may be used that translates search queries into language neutral database queries for searching the sole main database.

Moreover, information may be received that is punctuated, capitalized, or otherwise presented differently that corresponds to a same hotspot location or other attribute. These items are also translated into the database format the utilizes a uniform punctuation and capitalization scheme. For example, the uniform scheme may utilize "street" instead of "St." or "st." or "Street", and may utilize "PO" instead of "po" or "P.O." or "p.o." or "post office", and may utilize a coma between city and state, and may use "802.1 lg/a" instead of "802.1 Ig", etc., etc., even though information may be obtained from providers or other sources that is not unifoπn.

While an exemplary drawings and specific embodiments of the present invention have been described and illustrated, it is to be understood that that the scope of the present invention is not to be limited to the particular embodiments discussed. Thus, the embodiments shall be regarded as illustrative rather than restrictive, and it should be understood that variations may be made in those embodiments by workers skilled in the arts without departing from the scope of the present invention as set forth in the appended claims and structural and functional equivalents thereof.

In addition, in methods that may be performed according to preferred embodiments herein and that may have been described above or set forth in claim elements below, the operations have been described and/or set forth in selected typographical sequences. However, the sequences have been selected and so ordered for typographical convenience and are not intended to imply any particular order for performing the operations, except for those where a particular order may be expressly set forth as being necessary, or where those of ordinary skill in the art may deem a particular order to be necessary.

Claims

What is claimed is:

1. A method of dynamically maintaining a searchable database of information relating to hotspots, comprising:

(a) obtaining new information relating to hotspots from time to time from hotspot providers or other hotspot information sources, or both;

(b) translating the new hotspot information according to uniform database rules that apply to information received from multiple different providers or other sources or both;

(c) assigning a new unique identifier for each new location to a new location record that is unique even though the database contains information for same locations obtained from multiple different providers or other sources or both; and

(d) updating the database based on the new information by creating a new hotspot location record for each new location, and for each existing record, updating or deleting the existing record, or leaving the existing record unchanged, wherein the database contains multiple hotspot location records coiτesponding to hotspot locations and further includes therein information relating to attributes of one or more hotspot providers or other hotspot- related items, or both, for each location.

2. The method of claim 1, further comprising applying a filter to obtain a subset of the hotspot records having or not having a particular attribute.

3. The method of claim 2, further comprising appending a logo with predetermined records within search results.

4. The method of claim 1, further comprising appending a geographical map with hotspot location icons appearing approximately at their geographical locations on the map with search results.

5. The method of claim 1, further comprising parsing hotspot provider information from hotspot information of the new information and creating or updating a hotspot location record with the remaining provider-generic location information.

6. The method of claim 5, further comprising creating or updating a hotspot record that is linked to the hotspot location record with the information that has been parsed from the hotspot information.

7. A method of providing customized search tables from a dynamically maintained database of information relating to hotspots, comprising:

(a) obtaining new information relating to hotspots from time to time from one or more hotspot providers or other hotspot information sources, or a combination thereof;

(b) translating the new hotspot information according to uniform database rules that apply to information received from providers and/or other sources;

(c) assigning a new unique identifier to each new record;

(d) updating the database based on the new information by creating a new record, updating or deleting an existing record, or leaving an existing record unchanged, wherein the database contains multiple records corresponding to information relating to attributes of hotspots; and

(e) applying a filter to obtain a searchable subset of the hotspot records having or not having a particular attribute.

8. The method of claim 7, wherein said unique identifiers are assigned even though the database contains information from multiple different providers or other sources or both.

9. The method of claim 7, further comprising appending a logo with predetermined records within search results.

10. A hotspot location record database, comprising:

(a) a provider table including a provider record with a provider identifier for each of one or more providers and containing information relating to one or more attributes of the hotspot provider;

(b) a location table including a location record with a location identifier for each of one or more hotspot locations and containing information relating to geographical, postal address or other location-specific attributes for each location;

(c) a hotspot table including hotspot records with hotspot identifiers for combinations of hotspot providers and hotspot locations; and (d) wherein information relating to hotspot locations are uniquely identified within the database according to uniform database rules.

11. The database of claim 10, further comprising a venue table including identifiers for particular brands.

12. The database of claim 10, further comprising a location type table including identifiers for particular location types.

13. The database of claim 10, wherein the hotspot table comprises provider record identifiers (PRID) supplied by providers and/or other sources linked to corresponding hotspot identifiers.

14. The database of claim 10, wherein the location tables comprise latitude and longitude coordinates corresponding to geographical hotspot locations.

15. The database of claim 10, wherein the locations tables are searchable by search queries including location-related terms and yielding location records as results.

16. The database of claim 15, wherein the results include a geographical map with hotspot location icons appearing approximately at their geographical locations on the map.

17. The database of claim 10, wherein the database includes a subset of records adhering to one or more applied filter criteria.

18. The database of claim 10, wherein the database comprises records having promotional priorities appearing in search results.

19. The database of claim 18, wherein the appearance of priorities includes a logo included with one or more search result records.

20. The database of claim 18, wherein the appearance of priorities includes promoted records appearing nearer the top of search results than otherwise similar records.

21. The database of claim 10, wherein the location records of location tables include links to hotspot records of the hotspot tables.

22. The database of claim 21, wherein the hotspot records of the hotspot tables include links to corresponding hotspot provider tables.

23. One or more processor readable storage devices having processor readable code embodied thereon, said processor readable code for programming one or more processors to perform a method of dynamically maintaining a searchable database of information relating to hotspots, the method comprising:

(a) obtaining new information relating to hotspots from time to time from hotspot providers or other hotspot infoπnation sources, or both;

(c) assigning a new unique identifier for each new location to a new location record that is unique even though the database contains infoπnation for same locations obtained from multiple different providers or other sources or both;

(d) updating the database based on the new information by creating a new hotspot location record for each new location, and for each existing record, updating or deleting the existing record, or leaving the existing record unchanged, wherein the database contains multiple hotspot location records corresponding to hotspot locations and further includes therein information relating to attributes of one or more hotspot providers or other hotspot- related items, or both, for each location.

24. The one or more storage devices of claim 23, the method further comprising applying a filter to obtain a subset of the hotspot records having or not having a particular attribute.

25. The one or more storage devices of claim 24, the method further comprising appending a logo with predetermined records within search results.

26. The one or more storage devices of claim 23, the method further comprising appending a geographical map with hotspot location icons appearing approximately at their geographical locations on the map with search results.

27. The one or more storage devices of claim 1, the method further comprising parsing hotspot provider information from hotspot information of the new information and creating or updating a hotspot location record with the remaining provider-generic location infoπnation.

28. The one or more storage devices of claim 27, the method further comprising creating or updating a hotspot record that is linked to the hotspot location record with the information that has been parsed from the hotspot information.

29. One or more processor readable storage devices having processor readable code embodied thereon, said processor readable code for programming one or more processors to perform a method of providing customized search tables from a dynamically maintained database of information relating to hotspots, comprising:

^"(b) translating the new hotspot information according to uniform database rules that apply to information received from providers and/or other sources;

(c) assigning a new unique identifier to each new record;

30. The one or more storage devices of claim 29, wherein said unique identifiers are assigned even though the database contains information from multiple different providers or other sources or both.

31. The one or more storage devices of claim 29, further comprising appending a logo with predetermined records within search results.