WO2009083719A1 - Points d'intérêt adjacents à l'emplacement d'un dispositif mobile - Google Patents

Points d'intérêt adjacents à l'emplacement d'un dispositif mobile Download PDF

Info

Publication number
WO2009083719A1
WO2009083719A1 PCT/GB2008/004278 GB2008004278W WO2009083719A1 WO 2009083719 A1 WO2009083719 A1 WO 2009083719A1 GB 2008004278 W GB2008004278 W GB 2008004278W WO 2009083719 A1 WO2009083719 A1 WO 2009083719A1
Authority
WO
WIPO (PCT)
Prior art keywords
members
location
mobile device
candidate
list
Prior art date
Application number
PCT/GB2008/004278
Other languages
English (en)
Inventor
William Browne-Swinburne
Alexander Fairfax
Original Assignee
William Browne-Swinburne
Alexander Fairfax
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
Priority claimed from US12/166,350 external-priority patent/US20100004004A1/en
Application filed by William Browne-Swinburne, Alexander Fairfax filed Critical William Browne-Swinburne
Publication of WO2009083719A1 publication Critical patent/WO2009083719A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/18—Information format or content conversion, e.g. adaptation by the network of the transmitted or received information for the purpose of wireless delivery to users or terminals
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/953—Querying, e.g. by the use of web search engines
    • G06F16/9537—Spatial or temporal dependent retrieval, e.g. spatiotemporal queries
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/52—Network services specially adapted for the location of the user terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/20—Services signaling; Auxiliary data signalling, i.e. transmitting data via a non-traffic channel

Definitions

  • Mobile communication devices are expensive to run, easy to lose, easily broken and commication may be spotty. Despite this, mobile communication has rapidly become a key means of communication for voice and data of all types for nearly 80% of the world's population. This is because mobile communication provides convenience, whether actual or perceived.
  • a cell phone is a mobile communication device that operates within a physical area that is divided into cells. In order for cell service to work, the approximate location of a cell phone relative to a group of adjacent cells must be known. This attribute makes the cell phone suitable for receiving information relating a user's location to points-of-interest within a certain distance of the user.
  • Other communication devices may be locatable by various means, including GPS and Bluetooth location schemes.
  • What would be useful is a system and method that advantageously uses the location capabilities of a mobile device to provide location-related content to the mobile device based on criteria entered by a user.
  • Figure 1 illustrates a flow of a graphical user interface from a user perspective according to an embodiment.
  • Figure 2 illustrates an overall request process according to an embodiment.
  • Figure 3 illustrates a search flow of a search engine performing an automated search according to an embodiment.
  • Figure 4 illustrates the logical elements of an import service according to an embodiment hereof.
  • Figure 5 illustrates a flow of a user subscribe flow according to an embodiment.
  • Figure 6 illustrates a flow of a user subscribe flow according to an embodiment.
  • Figure 7 illustrates possible subscription states and their relationships according to an embodiment.
  • Figure 7 illustrates the logical elements of an import service according to an embodiment hereof.
  • Figure 8 illustrates a block diagram of an architecture for hosting a content delivery service according to an embodiment.
  • a point-of-interest may be a place, such as a restaurant, a park, a theater, a business address and a residential address, an event, such as an art exhibit or concert, or the location of another person. The event will also be associated with a location.
  • a postcode is a code used to identify a geographic region serviced by a postal authority. Thus, a postcode includes, but is not limited to, a zip code.
  • a “geocode” is a representational format of a geospatial coordinate measurement comprising at least a latitude and a longitude of a location.
  • LBS location based service
  • a LBS is a service that returns location data, which may be in the form of a postcode or geocode, that is indicative of a current location of a wireless mobile device.
  • a content delivery system provides context-relevant information to users of wireless mobile devices.
  • a CDS operator provides a mobile application that is installed and operated on a cell phone.
  • the mobile application is installed on the cell phone via a download.
  • the mobile application may be downloaded to the cell phone through the following methods:
  • Figure 1 illustrates a flow from a user perspective according to an embodiment.
  • the mobile application displays a graphical user interface (GUI) comprising a menu 100 of "categories" of points-of-interest (POIs).
  • GUI graphical user interface
  • Figure 1 illustrates category A 102, category B 104, and category N 106.
  • a categories list may include bars, clubs, culture, film, social affinity groups of all kinds, hotels, health and fitness, pubs, and restaurants.
  • CDS may be used to locate people who are users of the CDS.
  • the functional elments of the CDS may also be applied to allow users of the CDS to meet other users that have common interests or needs.
  • the GUI is responsive to selection components of the cell phone.
  • input components such as navigation keys, touch screens, and speech recognition systems normally assigned to navigate the cell phone features may be used to navigate the various lists and menus of the mobile application.
  • a user selected category N 108 As illustrated in Figure 1, a user selected category N 108.
  • a category may be further divided into subcategories. If so, the selection by the user of a category will prompt the mobile application to display a list of subcategories 120.
  • Figure 1 illustrates subcategory A 122, subcategory B 124, and subcategory N 126.
  • the subcategories are also selectable by the user via the selection components.
  • the category "Food” may be further organized into subcategories Chinese, Italian, and Fast Food. As illustrated in Figure 1, the user selects subcategory N and requests a search 128.
  • a "final” result is displayed.
  • the user selects result N 138 and the selected result is displayed 140.
  • the mobile application provides the user the option to share the final result with another party via Bluetooth, SMS or an IR connection.
  • the shared result comprises a link prompting the recipient to download the mobile application. The user is also given the option of submitting a new request or of exiting the mobile application.
  • the mobile application provides the user the option to share the results of the manual search with another party via Bluetooth, SMS or an IR connection.
  • Figure 2 illustrates an overall request process according to an embodiment.
  • the functions of a CDS are logically arranged according to whether the functions are to be performed by a mobile application running on a wireless mobile device, by a server application running on a server operated by (or for) a provider of an CDS, or by a database. While the functions of the server application and database are illustrated as to be logically distinct, it will be appreciated that some or all of these functions may be performed by a single physical device that comprises both the server application and the database logic.
  • a mobile application is loaded on a mobile device 200.
  • a category is selected from a menu of POIs displayed by the mobile application 202.
  • a subcategory is selected from a menu of subcategories of the selected category 204.
  • a request to search the category or subcategory is sent to a server application 210.
  • the server application runs on a server that is accessible to the wireless mobile device and that is operated by, or for, the operator of a CDS.
  • the server application communicates with a database to access a location based service (LBS) 212.
  • the LBS returns location data to the server application 214.
  • the location data may be a latitude and longitude or in the form of a postcode.
  • the server application accesses a postcode server 216, which converts the postcode to a geocode and returnes the geocode to the server application 218.
  • the geocode can be use directly without any need for a determination of postcode.
  • the server application communicates the geocode to the database.
  • a search engine operated by the server application accesses a content database 220 or a content provider 222 using the request criteria and the geocode and/or the location information.
  • the request criteria comprise the selected category and, if selected, the subcategory, and a radius value indicative of a distance from the location of the wireless mobile device to search for POIs that are assigned to the selected category and, if appropriate, subcategory.
  • the server application receives data associated with "N" nearest POIs within the selected category and, if appropriate, subcategory 224.
  • the number of listed POIs "N” is arbitrary. However, in an embodiment, "N” is set to three.
  • the "N" POIs are displayed by the mobile application for selection by the user 226. Following the user selection, information relating to the selected POI is displayed 228.
  • the information relating to the selected comprises the name, address, telephone contact of the selected POI.
  • a map or illustrating a route to the selected POI may be displayed. The route map may be accompanied by text instructions detailing driving or walking directions to the POI.
  • ancillary information such as the availability of local transport, the location of an ATM, a rating of the selected POI, a general range of prices for goods and services offered by the POI, and a review of the POI may be provided.
  • the user may call a POI directly from the mobile application or invite others to the meet at the POI via an "Invitation SMS.”
  • a user may also be presented with the opportunity to make a reservation at a hotel, a restaurant, or a performance near the POI.
  • the user may be offered a "discount” off the regular price charged by the POI or by businesses near the POI.
  • a specific time may be set by the system operator for the duration of a search.
  • the server may receive a request and perform the requested search for a fixed period of time (e.g. 15 seconds) after which the results are returned to the user. In this way results are returned without an overly long search period. This timeout aspect is further discussed (below).
  • the user elects to search manually.
  • the request further comprises location information provided by the user. If the user-provided location information does include a postcode, the request is sent to the server application 210 and the location information is forwarded to the database which then accesses a postcode server 216 (bypassing illustrated elments 212 and 214). If the user-provided location information includes a geocode, the request is sent to the server application 210 and the geocode and the request is forwarded to the database which then accesses either the content database 220 or the content provider 222 (bypassing illustrated elments 212, 214, 216, and 218).
  • the server application obtains the location information of the wireless mobile device from which a request is sent.
  • the location information is obtained via a location based service that associates a telephone number with longitude and latitude data and a radius about the coordinates in which the cell phone assigned the telephone number is located.
  • the location of a cell phone does not require or utilize GPS technology. However, this is not meant as a limitation. Other means, including the use of GPS technology, may be used to determine the location of the cell phone.
  • the search engine component of the server application makes a determination whether the search request has produced results data. If not, the geographic area encompassed by the search as determined by the radius data is enlarged and the search engine again processes the request. If results data is returned, the user is billed and presented with the results data.
  • the search engine is also implemented with a "thread pool" limit.
  • the thread pool limit determines the number of instances of the search engine to be instantiated in response to the receipt of requests from users and determines the number of content providers that can be searched simultaneously.
  • search engine performs the following tasks:
  • a list of content providers is retrieved from the content provider cache based on a match between the requested postcode and category. In this way, only service providers that provide the desired content within the desired geographic location are searched.
  • each member of the set of content providers is called via an agreed protocol in order to retrieve a list of locations.
  • an order in which these content providers are used is determined by a rank (described below) associated with the content provider.
  • the points-of-interest are ordered by the nearest to the location of the cell phone. For example, the top three distinct locations are displayed to the user of the wireless mobile device.
  • the mobile application interacts with a server application running on a server operated by or for the operator of a CDS.
  • the server application the search engine comprises a set of configuration values.
  • the configuration values determine the behavior of the CDS and provide the search engine information necessary to communicate with the content providers.
  • FIG. 3 illustrates a search flow of a search engine performing an automated search according to an embodiment.
  • the search flow is illustrated from the point when the user has selected a category and an LBS lookup has been performed.
  • the World Geodetic System 1984 (WGS84) standard is used for GeoCode data which is in WGS84 Latitude and WGS84 Longitude.
  • the latitude and longitude of the client's position can be determined from the location based service (using the WGS84 standard).
  • WGS84 World Geodetic System 1984
  • this is not meant as a limitation.
  • Other standards for determining location data may be used.
  • the search engine receives location data 300.
  • a database is searched using the category (or subcategory) selected 302. As described below, the database may be a central database or a database operated by a content provider.
  • the search engine retrieves POIs located within a specified area. A determination is made whether the results were returned or whether the number of results returned meets a preset number of results 304. If the number of results returned meets a preset number of results, a distance from the wireless device location to each POI is computed 308. The results are displayed to a user in order of increasing distance from the wireless device location 310.
  • the search returns an insufficient number of locations, then a determination is made whether the search time has exceeded a present limit 312. If the search returns an insufficient number of locations and the search time has not been exceeded, the search radius is widened until preset number of results is returned 314. If the present timeout period has been exceeded, the search is terminated 320 and the POIs retrieved are sent to the client.
  • the distance from a POI and a wireless mobile device is computed using an algorithm.
  • search location latitude is greater than or equal to the sthece location latitude then the search location must not exceed the sthece location latitude + 0.008999;
  • search location latitude is less than or equal to the sthece location latitude then the search location latitude must be greater than or equal to the sthece location latitude - 0.008999.
  • search location longitude is greater than or equal to the sthece location longitude then the search location must not exceed the sthece location longitude + 0.015299.
  • search location longitude is less than or equal to the sthece location longitude then the search location longitude must be greater than or equal to the sthece location longitude -0.015299.
  • longitudinal values can be positive or negative.
  • adjustment factors may be applied.
  • values within the UK may be adjusted by -1.3 degrees and multiplied by -1 in order to provide a positive longitude value.
  • the distance calculation may be performed using known techniques. By way of illustration and not as a limitation, the determination may be made by applying Pythagoras Theorem. If distances involved are small and accuracy is not critical, this approach will produce good results. However, in large regions where the distances may be larger, determination of the distances between points may be more accurately determined using a formula that accounts for the curvature of the earth. One such formula is the Haversine formula.
  • a manual search mechanism works differently from the automated search flow (see, Figure 3) in that the location to search against is entered as either a post code, town or city which is converted into geocodes before the search is performed.
  • the search engine may be configured to manage the behavior of the search engine.
  • Table 1 illustrates the elements of a GUI configuration file of a search engine according to an embodiment.
  • Table 1 The values set forth in Table 1 are considered exemplary and not limiting.
  • the values established for the longitude offset, minimum and maximum latitude and minimum and maximum longitude are illustrative of a search engine configured for operation in the United Kingdom.
  • the search engine configuration information also identifies all the content providers that can be used by the search engine.
  • Table 2 illustrates the content of a configuration file for a content provider known to the search engine according to an embodiment.
  • the content provider is identified by a unique "ContentProviderld.”
  • a content provider is also identified as “national” or “local” using a Boolean operator.
  • a national content provider provides information that is not grouped by postcodes or other location identifiers. If a content provider is identified as national, the search engine will disregard the postal area and category configuration information (each of which is described below).
  • the proximity to the target always takes precedence over every other factor.
  • the content providers are ranked in order of precedence and the data from the highest ranking content provider is used.
  • the precedence thus determines when the content of one content provider is displayed over the content of another based on the results returned.
  • the precedence may be determined based on financial considerations. For example, if content provider A signs a more lucrative license with the CDS operator than content provider B, the content of content provider A will be displayed more frequently than content provider B, thus offering A a greater opportunity to earn revenue.
  • Table 3 illustrates the content of a content provider ranking configuration file according to an embodiment.
  • Table 3 The string size set forth in Table 3 is considered exemplary and not limiting.
  • Table 4 illustrates the possible rank identifiers and the values assigned to them according to an embodiment.
  • a statistical model is used to select a content provider to return data in response to a request.
  • the performance of a service provider relative to an expected performance is monitored.
  • the relative performances of all of the service providers able to provide a response to a request are then evaluated using an algorithm to select the actual provider.
  • the information used by the algorithm is set forth in Tables 5-9 below.
  • Table 5 captures the details of licenses held by all content providers. It is assumed that a content provider will only have one license in any one period of time. >
  • Table 6 stores the number of locations returned for a period of time and for a content provider.
  • PeriodStart/PeriodEnd combination does not overlap any existing record in this table and is contiguous.
  • the actual period duration (PeriodEnd -PeriodStart) is arbitrary. In an embodiment, the period duration is in multiples of whole days.
  • Table 7 stores the number of locations returned for a period of time and for a content provider.
  • Tables 5-9 can be calculated in real time (which would provide a very accurate way of determining the correct content provider).
  • the table information is pre-processed on a daily basis in order to limit impact on the system.
  • the search engine may search a central database or a database operated by a content provider.
  • the search engine is configured to perform these searches as described below.
  • the central database is populated with POI information provided by content providers.
  • the data from a content provider is imported and transformed via a web service.
  • one web service serves all of the participating content providers.
  • a web service is provided per content provider.
  • the location import schema allows content providers to supply locations to the operator of a CDS with a category of selected by the content provider. It is envisaged that this category would be translated with the corresponding CDS category before the location is transferred into the database.
  • verification of the address data is provided to ensure data integrity.
  • Figure 4 illustrates the logical elements of an import service according to an embodiment hereof.
  • Data from a content provider is received at a website 400.
  • the content provider data is mapped to the structure of the central database 410 and imported into the central database 430.
  • the address data for POIs provided by the content provider are verified before importation into the central database 420.
  • a "patching application” receives content submissions from content providers.
  • the content submissions are obtained via FTP or a webservice.
  • the patching application then transforms the data from the content provider and inserts it into the central database so that all the relevant relationships and tracking information are captured. This transformation utilizes a category mapping table and import logging table(s) for capturing import processing data.
  • Table 10 illustrates the content of a category mapping configuration file according to an embodiment. This configuration file defines how the content provider maps categories to the system categories.
  • the ContentProviderld and Categoryld field combination will be unique.
  • the string size set forth in Table 10 is considered exemplary and not limiting.
  • the patching application ensures the following when transferring data into the database:
  • the mobile application also organizes the different categories from the content providers into normalized categories. For example, if a content provider has categories for Indian / Chinese / Korean and the mobile application had one category (Asian cuisine) for all the categories, then the data is reclassified before being stored into the database.
  • Table 11 illustrates the fields of a central database:
  • a location table defines all the establishments that can be used by the search engine and ultimately returned to the client.
  • the table is configured such that every row in this table is unique for an entry with the same Company Name, AddressLinel and Postcode. However, this is not meant as a limitation. Other table structures may be used to provide location information for points of interest.
  • Table 12 illustrates a location table according to an embodiment:
  • the location search table defines all the information used by the search engine in order to provide content to the client. In an embodiment, only active locations that are associated with at least one active content provider are reflected in this table. In addition, the table may be optimized for quickly identifying suitable locations by the search engine. Table 13 illustrates a location search table according to an embodiment.
  • a category is used to define a set of system categories that can be searched by the rules engine.
  • Table 14 illustrates the content of a category configuration file according to an embodiment.
  • the string size set forth in Table 14 is considered exemplary and not limiting.
  • Table 15 illustrates the content of an exemplary category configuration file according to an embodiment:
  • a region table is used to categorize post areas. For example, LS, BD, WF all belong to West Yorkshire. So, if Buffalo Post was only licensed to serve content in Buffalo, if the user was in Lancashire, then they would not be served data from Dodge Post's content database. Table 16 illustrates the contents of a region table according to an embodiment.
  • a post area table defines all the post areas used within the system. This table is used by the search engine in order to retrieve locations for a specified post town. Table 17 illustrates the contents of a post area table according to an embodiment.
  • Table 18 illustrates the content of an exemplary category post area table according to an embodiment.
  • a content provider table defines all the content providers that have contributed locations to the central database.
  • Table 19 illustrates the contents of a content provider table according to an embodiment.
  • the content provider is identified by a unique "ContentProviderld.”
  • a content provider is also identified as “national” or “local” using a Boolean operator.
  • a national content provider provides information that is not grouped by postcodes or other location identifiers. If a content provider is identified as national, the search engine will disregard the postal area and category configuration information.
  • a content provider category defines the set of categories that a content provider supports.
  • Table 20 illustrates a categories configuration file according to an embodiment for a content provider identified as national.
  • the search engine will be able to distinguish regions based on the geocodes and will be able to define the boundaries of the various regions using a lookup table. This is dependent on how the regions are sectioned by the operator of the CDS.
  • the ContentProviderld and Categoryld field combination will be unique.
  • a content provider postal area category defines the set of categories that are associated with a postal area for a specified content provider.
  • a content provider "YORKSHIRE PUBS AND RESTAURANTS” may have the categories PUBS for postal codes LS, BD, FIX, and RESTAURANTS for postal codes LS, HX, S75.
  • Table 21 illustrates a postal area category configuration file according to an embodiment.
  • the ContentProviderld, PostalAreald and Categoryld field combination will be unique. As previously indicated, a content provider that is identified as "national" does not provide content grouped by postcode. Thus, this configuration file is ignored by the search engine in the event that the content provider is defined as national.
  • the rules engine is configured to search databases of content providers and a central data base.
  • the search engine in order for the search engine to acquire data with from the content provider, the search engine is configured to use protocols recognized by the content provider.
  • service providers may utilize a web service, a HTTP GET implementation, or a HTTP POST implementation.
  • the search engine is configured to pass the parameters required by the content provider's interface in order to pass data requests to the content provider.
  • a content provider will be provided with at least a postcode, possibly a category (the content provider may only support one category), and maybe security details (in order that the content provider can validate the user requesting the information).
  • a protocol is used to define how the search engine communicates with the content provider in order to retrieve a list of locations.
  • Table 12 illustrates a protocol configuration file according to an embodiment.
  • Table 23 illustrates the content of an exemplary protocol configuration file according to an embodiment.
  • a parameter is used to define the parameters used when communicating with a content provider.
  • Table 24 illustrates a parameter configuration file according to an embodiment.
  • the string size set forth in Table 24 is considered exemplary and not limiting.
  • Table 25 illustrates the content of an exemplary parameter configuration file according to an embodiment.
  • a content type defines how the protocol encodes the data that is sent to a content provider.
  • Table 26 illustrates a protocol encoding configuration file according to an embodiment.
  • the string size set forth in Table 26 is considered exemplary and not limiting.
  • Table 27 illustrates the content of an exemplary protocol encoding configuration file according to an embodiment.
  • a content provider protocol defines the protocols that are implemented by a content provider.
  • Table 28 illustrates a provider protocol configuration file according to an embodiment.
  • the ContentProviderld and Protocolld field combination will be unique.
  • the string size set forth in Table 28 is considered exemplary and not limiting.
  • a content provider protocol configuration defines the set of parameter names and values that need to be specified for a content provider and protocol.
  • Table 29 illustrates a parameter configuration file according to an embodiment.
  • the string size set forth in Table 29 is considered exemplary and not limiting.
  • This configuration information is particularly useful when the content provider needs to be made aware of security details when using the specified protocol.
  • a content provider protocol parameter defines the content provider's representation of the parameters used by the search engine for a specified protocol.
  • Table 20 illustrates a content provider parameter naming configuration file according to an embodiment.
  • the ContentProviderProtocolId and Parameterld field combination will be unique.
  • the string size set forth in Table 30 is considered exemplary and not limiting.
  • the data that is returned from a content provider comprises a defined structure.
  • Table 31 illustrates a data structure according to an embodiment.
  • data that is returned from a content provider is in XML format.
  • content providers store (cache) the data in a central database.
  • a search engine component of a client searches the central database and does not communicate directly with a content provider.
  • a version table is used for distinguishing between the different versions of the mobile application.
  • Table 32 illustrates the contents of a version table according to an embodiment.
  • a content provider version table is a list of content providers that can be searched against for each mobile application version. This configuration table thus defines which content providers' data will be used for a particular version of the mobile application.
  • Table 33 illustrates the contents of a content provider version table according to an embodiment. TABLE 33
  • a content provider location table defines all the content providers that are associated with locations. Since the location table is assumed to have unique establishments, this table allows the same location to be assigned to multiple content providers.
  • Table 34 illustrates the contents of a content provider location table according to an embodiment.
  • the CDS provides context-relevant information to users of mobile devices.
  • the CDS thus utilizes existing infrastructure of a mobile gateway service provider to provide the communication between a mobile device and the content delivery system using short code messaging.
  • FIG. 5 illustrates a flow of a user subscribe flow according to an embodiment.
  • a user desiring to subscribe to content delivery service sends a text message comprising a short code from a mobile device to the gateway service provider 500.
  • the gateway service provider determines if the mobile number is valid 504. If the mobile is not valid, the gateway service provider returns an error message to the mobile device 508. If the mobile number is valid, the gateway service provider looks up the network of the user 512.
  • the user is then subscribed to a location based service 516.
  • the telephone number is associated with a unique reference number and added to a JAD file 520.
  • the telephone number and the unique reference number are sent to the provider of the content delivery service 524.
  • the unique reference number and telephone number are used for billing, audit and compliance or regulatory purposes.
  • the mobile application is then sent by the provider of the content delivery service to the mobile device 528.
  • FIG. 6 illustrates a flow of a user subscribe flow according to an embodiment.
  • a user desiring to subscribe to content delivery service sends a text message comprising a stop short code from a mobile device to the gateway service provider 600.
  • the use of a text message is exemplary and not limiting.
  • a voicecode could be used in place of a text message.
  • the gateway service provider determines if the mobile number is valid 602. If the mobile is not valid, the gateway service provider returns an error message to the mobile device 604. The gateway service provider determines if the mobile number is subscribed to the content delivery service 606. If the -mobile is not valid, the gateway service provider returns an error message to the mobile device 608. If the mobile number is valid and the number is subscribed to the content delivery service, the mobile service unsubscribes the user from the location based server 616 and from recurring billing 620. An unsubscribe message is sent to the provider of the content delivery service 624.
  • a text or audio shortcode is used to authenticate the user.
  • the shortcode By using the shortcode, the user is voluntarily opting into the content delivery service and accepting legal and commercial terms associated with the service.
  • the network lookup service is a transparent service provided by the gateway service provider for detecting the networks each mobile phone request is from. This is so that the appropriate network providers can be contacted for LBS data and recurring billing.
  • the change in network is detected.
  • a message is returned to the user asking the user to text to a mobile application shortcode to subscribe and download the latest copy of the mobile application.
  • the content delivery system obtains location based information from the gateway service provider via two interfaces, HTTP and XML/SOAP.
  • HTTP/HTPPS has an advantage in that the packets are significantly smaller sized.
  • a gateway service provider allows location requests to be made over HTTP to an LBS.
  • the most common method of connecting to the gateway service provider's LBS is through the use of HTTP GET requests.
  • the gateway service provider's LBS exposes an HTTP interface allowing applications with internet connectivity to locate a mobile handset.
  • a request for a page using the structure shown below is used to locate a mobile handset using the Gateway service provider's LBS.
  • the response given by the Gateway service provider's LBS can either be in plain text or XML format.
  • the endpoints for these HTTP requests are Plain text http://lbs.serviceprovider.com/PlainLocate and https://lbs.serviceprovider.com/PlainLocate.
  • Requests may be sent as a HTTP GET or POST using the parameters listed below.
  • HTTP/ 1.1 is enabled, if sending multiple packets, the TCP/IP connection is kept open between requests. Table 35 sets forth the parameters for requests according to an embodiment.
  • timeout will be set to a default value. In an embodiment, the default value is 20 seconds. If a request is made synchronously, timeout will have a maximum value. In an embodiment, the maximum value is 20 seconds.
  • a response to a request comprises a status code indicating how the request has proceeded. If this status indicates an error, there will also be a plain text explanation. However, status codes are used for ease of parsing by applications. Table 36 illustrates an error code map according to an embodiment. TABLE 36
  • Status codes 0 and 2xx (where x is a digit) indicate that a user will be billed for the request.
  • Status codes lxx indicate that the user will not be billed.
  • the request has been successful. If the status is of the form lxx (where x is a digit) the request has been rejected. If the status is of the form (2xx) the request has failed. Again, if the request is accepted, the reply will have HTTP status 200, if the request is rejected, the reply will have HTTP status 403, with text indicating the error.
  • the Gateway service provider's LBS allows location requests to be made using SOAP over HTTP.
  • a Web Services Definition Language (.wsdl) file describing the Location Gateway SOAP interface according to an embodiment is illustrated below:
  • targetNamespace http://I bs.wapmx.com/ext/soap
  • a content delivery system is provided in exchange for payment of fees.
  • a user pays for the service on a per use basis.
  • a user "subscribes" to the service.
  • a subscription describes a recurring charge applied to a single user, and is identified by the gateway with a single subscription Id generated by the gateway provider and a number of transaction Ids that relate to the individual charges that have been applied over the cthese of the subscription.
  • a number of management operations can be applied to subscriptions; they can be unsubscribed, this means that the subscription is immediately and permanently ended.
  • a request can also be made to conclude a subscription, which means that the subscription remains valid until the end of the current billing period, but after that time the subscription is automatically unsubscribed.
  • Subscriptions can be suspended, which means the subscription is deemed inactive, and should be unsubscribed after a defined period of time.
  • the gateway may continue to attempt to bill the user in order to restore their subscription. This process will terminate once the user becomes unsubscribed. A user will be prevented from using a suspended service until the user has been successfully billed.
  • the mobile application may also manually restore the subscription, enabling the user to continue to use the service without being billed until the start of the next billingperiod. This may be used either automatically (to allow a number of billing failures before permanently unsubscribing the user) or manually (to respond to a customer services call).
  • a concluding subscription is a request to be terminated submitted by the user (perhaps via their online bill) or the client (via a customer services call). If the next billing period is reached, then the user will not be billed, and will be unsubscribed instead. If during the time a subscription is concluding, a restore request is created (perhaps via a customer services call) the user will re- enter the subscribed state, and will be billed again at the start of the next billing period. If the billing frequency of a subscription is set to an arbitrary value (for example, "Every Goal"), then no automatic charges will be applied to the customer. The calling application will be responsible for instigating all charges.
  • a charge may be applied to an active subscription at any time, with the sole exception that a charge request will be rejected if a charge is already in progress.
  • Possible subscription states and their relationships are illustrated in Figure 7.
  • a client application issues a subscribe request 700. An attempt is made to subscribe the user 704. If the subscribe attempt fails the user is "not subscribed” 708. If the subscribe attempts succeeds, the use is "subscribed” 716. A “subscribed” user may be "suspended” 720. In an embodiment, suspension of a subscribed user occurs automatically if billing fails or is delayed. A suspended user will be subscribed if the issues with billing are resolved. A "suspended" user may be "unsubscribed” 722 if the issues giving rise to the suspension are not resolved before the end of the suspension period.
  • a subscribed user may be "concluding" at the request of a user 718.
  • a concluding account may be restored to “subscribed” on request of the user.
  • a concluding account may be "unsubscribed” 722 if the account is not restored before the end of the subscription period.
  • a “subscribed" user 716 may be “unsubscribed” 722 at the request of the user.
  • the calling application can choose to specify the recurring charge frequency and allow the gateway to process all the required charges automatically, or can manage the frequency of the charges itself by making explicit separate charge requests to the gateway as required, passing the subscriptionld as a request parameter.
  • the 'subscriptionPeriodUnits' parameter indicates the required charge frequency required; if set to an arbitrary unknown value the gateway will not automatically charge the user. If the gateway manages the recurring charges, the instigating application is notified of all charges via the Notification API.
  • Table 38 illustrates parameters used to instigate a subscription for a user according to an embodiment:
  • Values in the required column of Table 38 marked with "*" indicate that the details can be specified by the subscription product referred to by the given product Id. Alternatively they are specified on a per "subscribe request" basis where the account policy permits. In this instance all parameters are required.
  • the gateway will indicate in its response that user input is required and provide a billing URL for the required page.
  • Table 38B illustrates additional that parameters are returned in addition to the common response information:
  • Table 39 illustrates the parameters of unsubscribe request according to an embodiment:
  • Table 40 illustrates the parameters of a conclude request according to an embodiment:
  • Table 41 illustrates the parameters of a restore request according to an embodiment:
  • the gateway service provider's SMS server exposes an HTTP interface allowing applications with internet connectivity to send SMS text messages.
  • a request for a page using the structure shown below is all that is needed for a user to send an SMS through the gateway service provider's SMS Server.
  • the endpoints for these HTTP requests are http://sms.serviceprovider.com/SMSSend for HTTP and https://sms.serviceprovider.com/SMSSend for HTTPS (SSL).
  • messages are sent as either a HTTP GET or POST using the parameters listed below.
  • One request is sent per message.
  • HTTP/1.1 is enabled and when sending multiple packets, the TCP/IP connection is kept open between requests. If sending message with a high transmission rate is required, then several persistent HTTP/ 1.1 connections may be used concurrently (perhaps 3 or 4).
  • pipelining requests (ala Mozilla) is supported. Pipeling is best suited for circumstances in which high message rates and large latency between customer and the gateway service provider are needed.
  • the responses to GET requests utilize standard internet three digit reply codes: broadly speaking, 2Ox implies success, 4Ox implies bad request, and 5Ox implies server errors.
  • 2Ox implies success
  • 4Ox implies bad request
  • 5Ox implies server errors.
  • a GET transacition may be appear as follows:
  • a multi-part GET transacition may be appear as follows:
  • gateway service provider's server If there is a problem with the gateway service provider's server then a 500 Internal server error will be returned. The customer should wait a few seconds and reattempt to send their message.
  • the HTTP request comprises the common parameters described above and the plain-text-specific parameters set forth in Table 42A:
  • the CDS uses GPS to obtain location information.
  • the wireless mobile device comprises a GPS location system.
  • the mobile application interfaces with GPS location system to get location information.
  • the mobile application comprises detection logic to switch between LBS and GPS depending on availability. For example, in a building GPS may not work effectively, and LBS would be used. In an open space, GPS is would be used to provide more accurate location data.
  • content providers are remunerated for providing content.
  • the results for each content provider need to be tracked and logged.
  • the CDS allows for differences between different content providers. For example, content provider A may have a revenue split of 50/50 whereas content provider B may have 70/30.
  • Table 5 captures details all the licenses held by all content providers.
  • Table 5 captures the details of licenses held by all content providers.
  • Table 43 captures the details of a license audit table that is captured from the license table:
  • Table 44 illustrates an accounting period table that defines monetary and summary values for a specified period of time according to an embodiment:
  • Table 45 illustrates a Transaction Table and Table 46 illustrates a Transaction Log table.
  • the Transaction Table and the TransactionLog Table are maintained separately because, there could be three separate transaction logs in one transaction. For example, when a user is returned 3 results at the end of the search, it is one transaction with 3 transaction logs. This way, the transaction logs can be associated with a particular session.
  • Table 47 illustrates a transaction table comprising detailed information regarding each stage of the location searching process.
  • a transaction record is created using the ClientRequest, StartedOn, and Status data and, then updated on completion of the transaction with the additional data.
  • a transaction is only deemed successful if it has completed all the necessary steps in the allocated time and has returned at least one location to the client.
  • Table 48 illustrates a transaction item table comprising the locations that were supplied for each transaction. It is assumed that the Locationld is unique for the same Transactionld. For example, a suitable candidate key would be Transactionld, Locationld.
  • the CDS provides error reporting at points of failure. Error reports are logged into a database. This allows an error to be easily isolated and where required provide customers (content providers) with reporting during outages.
  • Table 49 illustrates an errors sthece table comprising all the entities that can log an error according to an embodiment:
  • Table 50 illustrates an errors table comprising all the errors that have occurred according to an embodiment: TABLE 50
  • FIG. 8 illustrates a block diagram of an architecture for hosting a content delivery service according to an embodiment.
  • redundant load balancers 804 and 808 route traffic depending on their load and availability.
  • the two load balancers are illustrated as being located in primary and secondary data centers. Should one load balancer fail then traffic to the hosted environment will be routed through a secondary load balancer which is also hosted in a secondary data centre.
  • Firewalls 812 located in the primary datacenter and firewall 816 located in the secondary datacenter utilize "heartbeat" monitoring. Should one firewall find a fault then the other will take over responsibilities seamlessly.
  • production webservers 820 and 824 communicate with database servers 828 and 832 clustered using a Storage Area Network (SAN) 836 to serve and store data.
  • SAN Storage Area Network
  • Web server 820 and 824 are assigned virtual IP addresses.
  • the virtual IP addresses are hosted on load balancers 804 and 808, which route traffic to virtual IP's of webservers through firewall.
  • Database servers 828 and 832 utilize a a two node cluster and use the fastIO (Input / Output) of SAN 836 to maintain disk high performance while storing and serving the data back to the DB cluster.
  • a two database server cluster means that one server will be live (master) while the other will be passive (slave) unless there is a fault whereby the slave will become the master until the original master returns to operational status.
  • the primary data center and the secondary data center are located in separate physical locations.
  • the secondary data center is secured behind a load balancer and a firewall.
  • the secondary test data center may be used for testing and for receiving the log data.
  • the log data is sent to the secondary data center on a 15-30 second periodical basis and stored on testing/data recovery servers 840 and 844.
  • any reference to claim elements in the singular for example, using the articles “a,” “an,” or “the” is not to be construed as limiting the element to the singular.
  • a reference to a specific time, time interval, and instantiation of scripts or code segments is in all respects illustrative and not limiting.

Abstract

L'invention porte sur un système et un procédé pour présenter des données de contenu de points d'intérêt (POI) sur un dispositif mobile. Des instructions logicielles sont stockées dans la mémoire du dispositif mobile et sont exécutées par le processeur. Les instructions permettent au dispositif mobile d'afficher une liste de catégories POI pour une acceptation par un utilisateur. La catégorie peut être en outre divisée en sous-catégories qui sont également affichées pour une sélection par l'utilisateur. La position courante du dispositif mobile est demandée à un fournisseur de service de localisation ou fournie par l'utilisateur. La position courante et une catégorie et une sous-catégorie sélectionnées sont formulées dans une requête de données de contenu POI. La requête est envoyée à des fournisseurs de service de contenu POI sélectionnés dont les offres de service comprennent la fourniture de données de contenu POI pour la catégorie/sous-catégorie et la position courante. Les données de contenu POI reçues en provenance des fournisseurs de service de contenu POI sélectionnés sont affichées sur le dispositif mobile.
PCT/GB2008/004278 2007-12-27 2008-12-29 Points d'intérêt adjacents à l'emplacement d'un dispositif mobile WO2009083719A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US1683007P 2007-12-27 2007-12-27
US61/016,830 2007-12-27
US12/166,350 US20100004004A1 (en) 2008-07-02 2008-07-02 System and Method for Matching User Preferences to Places of Interest
US12/166,350 2008-07-02

Publications (1)

Publication Number Publication Date
WO2009083719A1 true WO2009083719A1 (fr) 2009-07-09

Family

ID=40458538

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2008/004278 WO2009083719A1 (fr) 2007-12-27 2008-12-29 Points d'intérêt adjacents à l'emplacement d'un dispositif mobile

Country Status (1)

Country Link
WO (1) WO2009083719A1 (fr)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2306333A1 (fr) * 2009-09-04 2011-04-06 Jentro Technologies GmbH Bibliothèque de logiciels hors ligne
EP2320686A1 (fr) * 2009-11-04 2011-05-11 Cellco Partnership D/B/A Verizon Wireless Suggestions d'application pour dispositif de communication mobile basé sur les informations de répertoire à base d'emplacement
US8428622B1 (en) 2011-09-23 2013-04-23 Cellco Partnership Location based recommendation method for mobile station content
EP2413103A3 (fr) * 2010-07-26 2014-02-12 Elektrobit Automotive GmbH Technique de détermination de points d'intérêt pour un dispositif de navigation
CN103954277A (zh) * 2014-04-30 2014-07-30 百度在线网络技术（北京）有限公司 检测兴趣点位置的方法及装置
WO2014159423A1 (fr) * 2013-03-14 2014-10-02 Qualcomm Incorporated Procédés et systèmes pour une entrée d'informations automatique dans un dispositif sans fil
US8923888B2 (en) 2012-06-15 2014-12-30 Cellco Partnership Local content recommendations
CN104717292A (zh) * 2015-03-20 2015-06-17 南京邮电大学 一种k-匿名与云端相结合的位置隐私保护方法

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030069693A1 (en) * 2001-01-16 2003-04-10 Snapp Douglas N. Geographic pointing device
US20050130676A1 (en) * 2003-12-11 2005-06-16 International Business Machines Corporation Methods, systems, and media for acquiring ratings for points of interest
US20050255861A1 (en) * 2004-04-15 2005-11-17 Brian Wilson System for providing location-based services in a wireless network, such as locating sets of desired locations
WO2007013796A1 (fr) * 2005-07-29 2007-02-01 Telefonaktiebolaget Lm Ericsson (Publ) Procede de recherche du terminal utilisateur le plus proche pour reseau de telecommunication et noeud de service mettant en oeuvre ce procede
US20070270159A1 (en) * 2005-09-30 2007-11-22 Sunit Lohtia Location sensitive messaging
US20070281716A1 (en) * 2006-06-01 2007-12-06 Flipt, Inc Message transmission system for users of location-aware mobile communication devices in a local area network

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030069693A1 (en) * 2001-01-16 2003-04-10 Snapp Douglas N. Geographic pointing device
US20050130676A1 (en) * 2003-12-11 2005-06-16 International Business Machines Corporation Methods, systems, and media for acquiring ratings for points of interest
US20050255861A1 (en) * 2004-04-15 2005-11-17 Brian Wilson System for providing location-based services in a wireless network, such as locating sets of desired locations
WO2007013796A1 (fr) * 2005-07-29 2007-02-01 Telefonaktiebolaget Lm Ericsson (Publ) Procede de recherche du terminal utilisateur le plus proche pour reseau de telecommunication et noeud de service mettant en oeuvre ce procede
US20070270159A1 (en) * 2005-09-30 2007-11-22 Sunit Lohtia Location sensitive messaging
US20070281716A1 (en) * 2006-06-01 2007-12-06 Flipt, Inc Message transmission system for users of location-aware mobile communication devices in a local area network

Cited By (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2306333A1 (fr) * 2009-09-04 2011-04-06 Jentro Technologies GmbH Bibliothèque de logiciels hors ligne
US8559931B2 (en) 2009-11-04 2013-10-15 Cellco Partnership Application suggestions for mobile communication device based on location-based directory information
EP2320686A1 (fr) * 2009-11-04 2011-05-11 Cellco Partnership D/B/A Verizon Wireless Suggestions d'application pour dispositif de communication mobile basé sur les informations de répertoire à base d'emplacement
US8990008B2 (en) 2010-07-26 2015-03-24 Elektrobit Automotive Gmbh Technique for determining points of interest for a navigation device
EP2413103A3 (fr) * 2010-07-26 2014-02-12 Elektrobit Automotive GmbH Technique de détermination de points d'intérêt pour un dispositif de navigation
US8428622B1 (en) 2011-09-23 2013-04-23 Cellco Partnership Location based recommendation method for mobile station content
US9088867B2 (en) 2011-09-23 2015-07-21 Cellco Partnership Location based recommendation method for mobile station content
US8923888B2 (en) 2012-06-15 2014-12-30 Cellco Partnership Local content recommendations
WO2014159423A1 (fr) * 2013-03-14 2014-10-02 Qualcomm Incorporated Procédés et systèmes pour une entrée d'informations automatique dans un dispositif sans fil
US9131345B2 (en) 2013-03-14 2015-09-08 Qualcomm Incorporated Methods and systems for automated information entry in a wireless device
CN105027585A (zh) * 2013-03-14 2015-11-04 高通股份有限公司 用于无线装置中的自动信息输入的方法及系统
CN105027585B (zh) * 2013-03-14 2019-01-18 高通股份有限公司 用于无线装置中的自动信息输入的方法及系统
CN103954277A (zh) * 2014-04-30 2014-07-30 百度在线网络技术（北京）有限公司 检测兴趣点位置的方法及装置
CN103954277B (zh) * 2014-04-30 2017-05-03 百度在线网络技术（北京）有限公司 检测兴趣点位置的方法及装置
CN104717292A (zh) * 2015-03-20 2015-06-17 南京邮电大学 一种k-匿名与云端相结合的位置隐私保护方法
CN104717292B (zh) * 2015-03-20 2018-03-06 南京邮电大学 一种k‑匿名与云端相结合的位置隐私保护方法

Similar Documents

Publication Publication Date Title
US20100004004A1 (en) System and Method for Matching User Preferences to Places of Interest
WO2009083719A1 (fr) Points d'intérêt adjacents à l'emplacement d'un dispositif mobile
US8688148B2 (en) Dynamic resource matching system
US8516550B2 (en) Systems and methods for enabling a service provider to obtain and use user information
RU2612583C2 (ru) Торговая площадка для своевременного распределения данных о событиях
US20030087648A1 (en) End user to mobile service provider message exchange system based on proximity
US20110099037A1 (en) Location-Based, Time Sensitive Wireless Exchange
EP1119211A2 (fr) Procédé et système pour fournir des services dépendants de la position aux abonnés GSM/PCS
TWI441535B (zh) 使用地理信號特徵群集實現端到端訊息推播之方法
CN102137155A (zh) 一种基于客户感知的通信网络质量投诉处理方法
CN103297551A (zh) 自动获取地址的方法、服务器和系统
WO2010080668A2 (fr) Réseautage social basé sur un serveur à état à l'aide de dispositifs mobiles
JP2003533834A (ja) 通信ネットワークにおけるサービスノードへ接続されたエンドユーザ端末へのねらいの定められたメッセージの送信
JP2002269316A (ja) 店舗情報サービスシステム
US8554613B2 (en) Providing coupons based on user selected preference options
CN101836405B (zh) 用于通过SIP终端在VoIP网络系统中发布、查询和订阅信息的方法、SIP终端、SIP应用服务器、SIP信息中心和VoIP网络系统
CN100471288C (zh) 一种目标方获取发起方位置信息的方法及系统
US20140365476A1 (en) Virtual tag, client hosted and client sourced content/services rating and ranking support
KR20000006760A (ko) 이동 단말기를 통한 위치정보 서비스 제공방법
US20100180323A1 (en) Stateful server based social networking using mobile devices
EP2190169A1 (fr) Transmetteur de service de diffusion personnelle et terminal mobile
US20070005483A1 (en) Technique for providing a personalized auction service through an information assistance provider
US20140241330A1 (en) Method and system to provide relevant local service over wi-fi
KR20180100499A (ko) 위치 기반의 제2급 소셜 네트워킹에 관한 적응 가능한 브로커
US20220245604A1 (en) Service processing method and apparatus

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08868948

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08868948

Country of ref document: EP

Kind code of ref document: A1