+

WO2006014439A2 - Base de donnees d'enregistrements d'emplacements de zones actives - Google Patents

Base de donnees d'enregistrements d'emplacements de zones actives Download PDF

Info

Publication number
WO2006014439A2
WO2006014439A2 PCT/US2005/023861 US2005023861W WO2006014439A2 WO 2006014439 A2 WO2006014439 A2 WO 2006014439A2 US 2005023861 W US2005023861 W US 2005023861W WO 2006014439 A2 WO2006014439 A2 WO 2006014439A2
Authority
WO
WIPO (PCT)
Prior art keywords
hotspot
location
database
information
record
Prior art date
Application number
PCT/US2005/023861
Other languages
English (en)
Other versions
WO2006014439A9 (fr
WO2006014439A3 (fr
Inventor
Anne Benzancon
Craig Lurey
Original Assignee
Jiwire
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Jiwire filed Critical Jiwire
Publication of WO2006014439A2 publication Critical patent/WO2006014439A2/fr
Publication of WO2006014439A9 publication Critical patent/WO2006014439A9/fr
Publication of WO2006014439A3 publication Critical patent/WO2006014439A3/fr

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/29Geographical information databases

Definitions

  • 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.
  • 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.
  • 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.
  • hotspot 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.
  • 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.
  • 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.
  • a hotspot location record database 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Hotspot locations 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • each item of information 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.
  • they enable scaling with increasing volumes of directory data, both in numbers of locations/hotspots and what information is collected.
  • Fourth, revenue opportunities may be multiplied by increasing granularity of the data that can be manipulated and published or licensed.
  • revenue opportunities may be further increased by having more accurate data of better quality to sell/resell to the emerging marketplace.
  • 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).
  • 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.
  • self-learning tools may be built, e.g., each new case may be incorporated into a "knowledge base" of reference tables and script rules.
  • the tools may be made available on the web.
  • 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.
  • Reference tables editing tools Provider, Location, Location type, Connection type, Venue group/Franchise, etc.
  • 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;
  • picklists may be preferably sorted alphabetically.
  • 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.
  • 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.
  • 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 (AP) Equipment (AP) Equipment (AP) Equipment (AP) Equipment (AP
  • 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 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.
  • ref# serving as ID unique to that provider record
  • 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).
  • a franchise/venue-group ID is manually assigned to each record having a franchise, brand, venue associated with it.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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:
  • 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.):
  • the de-duping of raw files is a preferred tool / process.
  • 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.
  • each record 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.
  • provider record ID used by the provider
  • venue_id used the franchise
  • reference # a reference # that is assigned.
  • 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.
  • Hotspot specific pricing is entered at the hotspot level (hotspot tool).
  • 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.
  • default provider pricing is entered in the provider tool or the pricing tool.
  • This tool 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.
  • 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.
  • ACTIVE/INT ACTIVE flag may be added with DSL/Tl/T3/Cable options. Hour/day/monthly subscription pricing may be added.
  • FIG. 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.
  • 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.
  • 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
  • the pricing tool of block 9 is a web-based data management tool for information about pricing of services.
  • 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.
  • 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;
  • 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;
  • Step 1 find the record to edit
  • Step 2 choose the record from a results list, which displays below;
  • Step 3 Edit the field(s);
  • 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;
  • 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);
  • 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;
  • 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);
  • Step 1 choose whether to create a new record, or edit an existing one via viewing the entire table;
  • 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;
  • Step 2 alternate: if "edit/view table” selected, refreshes and displays all records with an "edit” button next to each, sorted in alphabetical order;
  • 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”.
  • 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);
  • 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;
  • 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;
  • 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.
  • 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.
  • 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.
  • FIG. 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.
  • new information is obtained relating to hotspots.
  • the information will include at least some location information.
  • the information may include many other kinds of info ⁇ nation, as understood from the above.
  • 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.
  • 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.
  • hotspot records, venue records, provider records, etc. are also created, updated, deleted or left unchanged depending on the new information upon verification.
  • S7A 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.
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Remote Sensing (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Telephonic Communication Services (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Selon l'invention, un procédé de maintien dynamique d'une base de données consultable (T1-T8) d'informations se rapportant à des zones actives consiste à acquérir de temps en temps des informations se rapportant à des zones actives auprès de prestataires de zones actives et/ou d'autres sources d'information sur des zones actives. Ces nouvelles informations se rapportant à des zones actives sont traduites selon des règles de base de données uniformes qui s'appliquent à des informations reçues de plusieurs prestataires différents et/ou d'autres sources. Pour chaque nouvel emplacement de zones actives, un nouvel indentificateur d'emplacement unique est attribué à un nouvel enregistrement d'emplacement (T6R). Les indentificateurs d'emplacement sont uniques, même si la base de données (T1-T8) contient des informations se rapportant au même emplacement obtenues de plusieurs prestataires différents et/ou d'autres sources. La base de données (T1-T8) est mise à jour sur la base de nouvelles informations: par la création d'un nouvel enregistrement d'emplacement de zones actives (T6R) pour chaque nouvel emplacement (T7R) et, pour chaque enregistrement d'emplacement existant (T6R), par la mise à jour ou l'effacement de l'enregistrement existant ou la conservation dudit enregistrement existant intact. La base de données (T1-T8) contient plusieurs enregistrements d'emplacements de zones actives (T6R) correspondants à des emplacements de zones actives (T7R); elle contient en outre des informations se rapportant à des attributs d'un ou de plusieurs prestataires de zones actives et/ou à d'autres articles se rapportant à des zones actives pour chaque emplacement (T7R).
PCT/US2005/023861 2004-07-06 2005-07-05 Base de donnees d'enregistrements d'emplacements de zones actives WO2006014439A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US88650204A 2004-07-06 2004-07-06
US10/886,502 2004-07-06

Publications (3)

Publication Number Publication Date
WO2006014439A2 true WO2006014439A2 (fr) 2006-02-09
WO2006014439A9 WO2006014439A9 (fr) 2006-06-01
WO2006014439A3 WO2006014439A3 (fr) 2007-02-08

Family

ID=35787605

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2005/023861 WO2006014439A2 (fr) 2004-07-06 2005-07-05 Base de donnees d'enregistrements d'emplacements de zones actives

Country Status (1)

Country Link
WO (1) WO2006014439A2 (fr)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
NL1035516C1 (nl) * 2008-06-03 2008-07-23 Dave John Dronrijp Sorteringwijze van zoekresultaten bestaande uit locaties.
US7561890B2 (en) 2006-06-22 2009-07-14 Sony Ericsson Mobile Communications Ab Hotspot location database system, mobile terminal for use in such a system and method for creating maintaining and updating such a system
US8095534B1 (en) 2011-03-14 2012-01-10 Vizibility Inc. Selection and sharing of verified search results
US8385964B2 (en) 2005-04-04 2013-02-26 Xone, Inc. Methods and apparatuses for geospatial-based sharing of information by multiple devices
JP2013182298A (ja) * 2012-02-29 2013-09-12 Zenrin Datacom Co Ltd 情報処理装置、情報処理方法、及びプログラム
WO2013158726A3 (fr) * 2012-04-18 2014-01-23 Telcom Ventures, L.L.C. Systèmes et procédés de détermination de localisation assistée par réseau local
US8639266B2 (en) 2012-04-18 2014-01-28 Google Inc. Using peer devices to locate a mobile device
US8914043B2 (en) 2012-04-18 2014-12-16 Google Inc. Creating and sharing private location databases
EP2283693A4 (fr) * 2008-05-09 2016-02-17 Marvell World Trade Ltd Systèmes et procédés pour fournir un accès wi-fi conscient de l emplacement pour un dispositif portable
WO2017093039A1 (fr) * 2015-12-03 2017-06-08 Accuris Technologies Limited Commande d'accès à un point d'accès public wi-fi, par un dispositif mobile

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7266512B2 (en) * 2000-07-18 2007-09-04 Cnet Networks, Inc. System and method for establishing business to business connections via the internet
WO2002073429A1 (fr) * 2001-03-12 2002-09-19 Accenture Sas Systeme mobile d'aide a la decision

Cited By (52)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9736618B1 (en) 2005-04-04 2017-08-15 X One, Inc. Techniques for sharing relative position between mobile devices
US10165059B2 (en) 2005-04-04 2018-12-25 X One, Inc. Methods, systems and apparatuses for the formation and tracking of location sharing groups
US11778415B2 (en) 2005-04-04 2023-10-03 Xone, Inc. Location sharing application in association with services provision
US8385964B2 (en) 2005-04-04 2013-02-26 Xone, Inc. Methods and apparatuses for geospatial-based sharing of information by multiple devices
US11356799B2 (en) 2005-04-04 2022-06-07 X One, Inc. Fleet location sharing application in association with services provision
US8538458B2 (en) 2005-04-04 2013-09-17 X One, Inc. Location sharing and tracking using mobile phones or other wireless devices
US10856099B2 (en) 2005-04-04 2020-12-01 X One, Inc. Application-based two-way tracking and mapping function with selected individuals
US10791414B2 (en) 2005-04-04 2020-09-29 X One, Inc. Location sharing for commercial and proprietary content applications
US8712441B2 (en) 2005-04-04 2014-04-29 Xone, Inc. Methods and systems for temporarily sharing position data between mobile-device users
US8750898B2 (en) 2005-04-04 2014-06-10 X One, Inc. Methods and systems for annotating target locations
US8798645B2 (en) 2005-04-04 2014-08-05 X One, Inc. Methods and systems for sharing position data and tracing paths between mobile-device users
US8798593B2 (en) 2005-04-04 2014-08-05 X One, Inc. Location sharing and tracking using mobile phones or other wireless devices
US10750311B2 (en) 2005-04-04 2020-08-18 X One, Inc. Application-based tracking and mapping function in connection with vehicle-based services provision
US8831635B2 (en) 2005-04-04 2014-09-09 X One, Inc. Methods and apparatuses for transmission of an alert to multiple devices
US10750310B2 (en) 2005-04-04 2020-08-18 X One, Inc. Temporary location sharing group with event based termination
US9031581B1 (en) 2005-04-04 2015-05-12 X One, Inc. Apparatus and method for obtaining content on a cellular wireless device based on proximity to other wireless devices
US10750309B2 (en) 2005-04-04 2020-08-18 X One, Inc. Ad hoc location sharing group establishment for wireless devices with designated meeting point
US9167558B2 (en) 2005-04-04 2015-10-20 X One, Inc. Methods and systems for sharing position data between subscribers involving multiple wireless providers
US9185522B1 (en) 2005-04-04 2015-11-10 X One, Inc. Apparatus and method to transmit content to a cellular wireless device based on proximity to other wireless devices
US9253616B1 (en) 2005-04-04 2016-02-02 X One, Inc. Apparatus and method for obtaining content on a cellular wireless device based on proximity
US10341808B2 (en) 2005-04-04 2019-07-02 X One, Inc. Location sharing for commercial and proprietary content applications
US9654921B1 (en) 2005-04-04 2017-05-16 X One, Inc. Techniques for sharing position data between first and second devices
US9467832B2 (en) 2005-04-04 2016-10-11 X One, Inc. Methods and systems for temporarily sharing position data between mobile-device users
US9584960B1 (en) 2005-04-04 2017-02-28 X One, Inc. Rendez vous management using mobile phones or other mobile devices
US10313826B2 (en) 2005-04-04 2019-06-04 X One, Inc. Location sharing and map support in connection with services request
US10341809B2 (en) 2005-04-04 2019-07-02 X One, Inc. Location sharing with facilitated meeting point definition
US8798647B1 (en) 2005-04-04 2014-08-05 X One, Inc. Tracking proximity of services provider to services consumer
US10299071B2 (en) 2005-04-04 2019-05-21 X One, Inc. Server-implemented methods and systems for sharing location amongst web-enabled cell phones
US9749790B1 (en) 2005-04-04 2017-08-29 X One, Inc. Rendez vous management using mobile phones or other mobile devices
US10200811B1 (en) 2005-04-04 2019-02-05 X One, Inc. Map presentation on cellular device showing positions of multiple other wireless device users
US9854402B1 (en) 2005-04-04 2017-12-26 X One, Inc. Formation of wireless device location sharing group
US9854394B1 (en) 2005-04-04 2017-12-26 X One, Inc. Ad hoc location sharing group between first and second cellular wireless devices
US9883360B1 (en) 2005-04-04 2018-01-30 X One, Inc. Rendez vous management using mobile phones or other mobile devices
US9942705B1 (en) 2005-04-04 2018-04-10 X One, Inc. Location sharing group for services provision
US9955298B1 (en) 2005-04-04 2018-04-24 X One, Inc. Methods, systems and apparatuses for the formation and tracking of location sharing groups
US9967704B1 (en) 2005-04-04 2018-05-08 X One, Inc. Location sharing group map management
US9615204B1 (en) 2005-04-04 2017-04-04 X One, Inc. Techniques for communication within closed groups of mobile devices
US10149092B1 (en) 2005-04-04 2018-12-04 X One, Inc. Location sharing service between GPS-enabled wireless devices, with shared target location exchange
US7561890B2 (en) 2006-06-22 2009-07-14 Sony Ericsson Mobile Communications Ab Hotspot location database system, mobile terminal for use in such a system and method for creating maintaining and updating such a system
EP2283693A4 (fr) * 2008-05-09 2016-02-17 Marvell World Trade Ltd Systèmes et procédés pour fournir un accès wi-fi conscient de l emplacement pour un dispositif portable
US9374775B2 (en) 2008-05-09 2016-06-21 Marvell World Trade Ltd. Method and apparatus for providing location-aware Wi-Fi access
NL1035516C1 (nl) * 2008-06-03 2008-07-23 Dave John Dronrijp Sorteringwijze van zoekresultaten bestaande uit locaties.
US8095534B1 (en) 2011-03-14 2012-01-10 Vizibility Inc. Selection and sharing of verified search results
JP2013182298A (ja) * 2012-02-29 2013-09-12 Zenrin Datacom Co Ltd 情報処理装置、情報処理方法、及びプログラム
JP2015520361A (ja) * 2012-04-18 2015-07-16 テルコム・ベンチャーズ・エルエルシー ローカルエリアネットワークを利用したロケーション決定のためのシステム及び方法
JP2018097002A (ja) * 2012-04-18 2018-06-21 テルコム・ベンチャーズ・エルエルシー ローカルエリアネットワークを利用したロケーション決定のためのシステム及び方法
US9769601B2 (en) 2012-04-18 2017-09-19 Google Inc. Using peer devices to locate a mobile device
US8914043B2 (en) 2012-04-18 2014-12-16 Google Inc. Creating and sharing private location databases
US10172073B2 (en) 2012-04-18 2019-01-01 Telcom Ventures, Llc Systems and methods for local-area-network-assisted location determination
US8639266B2 (en) 2012-04-18 2014-01-28 Google Inc. Using peer devices to locate a mobile device
WO2013158726A3 (fr) * 2012-04-18 2014-01-23 Telcom Ventures, L.L.C. Systèmes et procédés de détermination de localisation assistée par réseau local
WO2017093039A1 (fr) * 2015-12-03 2017-06-08 Accuris Technologies Limited Commande d'accès à un point d'accès public wi-fi, par un dispositif mobile

Also Published As

Publication number Publication date
WO2006014439A9 (fr) 2006-06-01
WO2006014439A3 (fr) 2007-02-08

Similar Documents

Publication Publication Date Title
US20030061211A1 (en) GIS based search engine
CA2600849C (fr) Procede, systeme et dispositif de mise en oeuvre d'un service de repertoire electronique multi-mode base sur l'emplacement
US20080163073A1 (en) System and method for providing multiple participants with a central access portal to geographic point of interest data
US20080198995A1 (en) System and method for providing a search portal with enhanced results
US20040023666A1 (en) Location based service provider
US20050004903A1 (en) Regional information retrieving method and regional information retrieval apparatus
US20050192999A1 (en) System and method of virtualizing physical locations
CN101677472B (zh) 一种移动通信导航的方法、系统及终端
US20020143462A1 (en) Method and apparatus for providing location based data services
US20020087408A1 (en) System for providing information to intending consumers
US20090063474A1 (en) System and Method for Information Retrieval
CN101313300A (zh) 本地搜索
CN103457837A (zh) 通过搜索引擎进行即时通信搜索的方法及系统
WO2013134102A1 (fr) Données de requête de recherche filtrées pour le contexte et l'intention de l'utilisateur dans un moteur de recherche basé sur la localisation
US20100042611A1 (en) Location-based search mash-up engine, web site, and application programming interface
EP1879118A1 (fr) Serveur de recherche
WO2006014439A2 (fr) Base de donnees d'enregistrements d'emplacements de zones actives
US20090186631A1 (en) Location Based Information Related to Preferences
JP2002132827A (ja) インターネット情報からの広告宣伝情報自動検索装置及び広告宣伝情報自動検索方法
JP4987687B2 (ja) 配信サーバ及び配信方法
JP4619440B2 (ja) 地球時計と連結されたニュース配信システム
KR101688391B1 (ko) 위치정보db 기반 사용자 맞춤형 여가활동 코스 추천 컨텐츠 제공 시스템 및 방법
KR100921246B1 (ko) 지역 정보 검색 시스템 및 방법
KR101734533B1 (ko) 다국가 뉴스 서비스 제공 방법
JP2003223453A (ja) 住所情報と位置座標のマッチング方法

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU LV MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

COP Corrected version of pamphlet

Free format text: PAGES 1/11-11/11, DRAWINGS, REPLACED BY CORRECT PAGES 1/20-20/20

121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

122 Ep: pct application non-entry in european phase
点击 这是indexloc提供的php浏览器服务,不要输入任何密码和下载