US008045995B2
`
`(12) United States Patent
`King et a].
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 8,045,995 B2
`Oct. 25, 2011
`
`(54) CENTRALIZED LOCATION BROKER
`
`(75) Inventors: Simon P. King, Berkeley, CA (US); Paul
`Hammond, San Francisco, CA (US);
`Tom Coates, London (GB); Simon
`Willison, Oxford (GB); Rahul Nair,
`Oakland, CA (US); Shane Ahern, Foster
`City, CA (US); Mor Naaman, San
`Francisco, CA (US)
`
`(73) Assignee: Yahoo! Inc., Sunnyvale, CA (US)
`
`( * ) Notice:
`
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 809 days.
`
`(21) Appl.No.: 11/755,99s
`
`(22) Filed:
`
`May 31, 2007
`
`(65)
`
`Prior Publication Data
`
`US 2008/0299989 A1
`
`Dec. 4, 2008
`
`(51) Int. Cl.
`(2009.01)
`H04 W24/00
`(52) US. Cl. ............. .. 455/456.1; 455/404.2; 455/414.2;
`455/456.2; 455/456.5
`(58) Field of Classi?cation Search ............. .. 455/414.2,
`455/456.1, 456.2, 456.5, 404.2
`See application ?le for complete search history.
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`6,321,092 Bl
`11/2001 Fitch et al.
`6,757,545 B2 *
`6/2004 NoWak et a1. ............ .. 455/456.2
`7,035,647 B2
`4/2006 De Verteuil
`7,085,578 B2 *
`8/2006 Barclay et al. .............. .. 455/457
`7,117,371 B1* 10/2006 Parthasarathy et al. ..... .. 713/187
`7,120,254 B2 * 10/2006 Glick et a1. ................. .. 380/258
`2002/0193121 A1 12/2002 NoWak et a1.
`2004/0104097 A1* 6/2004 Ngee ........................... .. 194/210
`2005/0181805 A1* 8/2005 Gallagher ................ .. 455/456.1
`2005/0186967 A1
`8/2005 OZluturk
`
`2005/0204014 A1* 9/2005 Yao m1. .................... .. 709/217
`2005/0251440 A1* 11/2005 Bednarek
`....... .. 705/10
`2006/0077095 A1* 4/2006 Tucker et al. ..
`.. 342/357.08
`
`. . . . . .. 701/213
`2006/0217885 A1* 9/2006 Crady et al. . . . . . . .
`.. 340/521
`2007/0132550 A1* 6/2007 Avraham et al.
`455/456.1
`2007/0149212 A1* 6/2007 Gupta et al.
`2008/0171559 A1* 7/2008 Frank et al. .............. .. 455/456.5
`
`W0
`W0
`W0
`
`FOREIGN PATENT DOCUMENTS
`WO 97/38548 A1 10/1997
`WO 00/27143 A1
`5/2000
`W0 02/076118 A1
`9/2002
`(Continued)
`
`OTHER PUBLICATIONS
`
`Brandt, Joel, et al. “Lash-Ups: A Toolkit for Location-Aware Mash
`Ups,” http://hci.stanford.edu/research/lash-ups/, 4 pages (retrieved
`May 29, 2007).
`
`(Continued)
`
`Primary Examiner * Marivelisse Santiago Cordero
`Assistant Examiner * Qun Shen
`(74) Attorney, Agent, or Firm * Nathan 0. Greene; Brinks
`Hofer Gilson & Lione
`
`ABSTRACT
`(57)
`A centralized location system includes a location update
`application programming interface (API) to receive varying
`types of location inputs for a user from at least one location
`providing application. A memory stores a location of the user
`and the location inputs, Wherein the location update API
`periodically updates in the memory the location inputs When
`location updates are received from the at least one location
`providing application. A location export API, upon request
`from a location-based service application, processes the loca
`tion inputs to estimate a location of the user, Which location
`estimate replaces the stored location in memory and is sent to
`the location-based service application. A user interface
`enables the user to specify a location granularity for at least
`one of the at least one location-providing application and the
`location-based service application.
`
`23 Claims, 6 Drawing Sheets
`
`Sponsored
`“9157:”!
`—
`_
`
`Extemai
`Applications
`2 1L
`
`l-vci?'vn Br?k?r 11H
`User Loealion
`Update API 1.45
`
`User Location
`Export API 31
`
`User Permission I;
`Privacy Manager
`E
`
`Userlnien‘ace 11.4,
`
`N ETWORK
`
`I Sponsored
`>
`Sega“
`
`108
`
`q
`
`External
`Services
`m
`
`Ruiz Food Products, Inc.
`Exhibit 1011
`
`

`

`US 8,045,995 B2
`Page 2
`
`FOREIGN PATENT DOCUMENTS
`W0 WO 2005/003920 A2
`1/2005
`W0 WO 2005/081796 A2
`9/2005
`OTHER PUBLICATIONS
`_
`_
`_
`Gangemi, Jeffrey, “Fine-Tuning Local Search,” http://WWW.
`businessweek.com/print/smallbiZ/Content/dec2006/sb20061226i
`63390l.htm, 2 pages (Dec. 26, 2006).
`
`Loki for Internet Explorer, http://softwaretechrepublic.com.con1/
`download.aspx?docid:290960, 2 pages (retrieved May 8, 2007).
`Skyhook Wireless, http://WWW.skyhookWireless.com/, 12 pages
`(retrieved May 29, 2007).
`Trackut: How it Works, http://WWW.trackut.com/help.php, 2 pages
`(retrieved May 8 2007)‘
`
`* cited by examiner
`
`Ruiz Food Products, Inc.
`Exhibit 1011
`
`

`

`US. Patent
`
`0a. 25, 2011
`
`Sheet 1 of6
`
`US 8,045,995 B2
`
`Sponsored
`Applaéaglons
`
`—
`
`External
`Applications
`1.32
`
`Location Broker 19.”;
`User Location
`
`Update APi _1_4_§
`
`I Sponsored
`»
`S93E85
`
`_
`
`NETWORK
`m
`
`User Location
`Export API @
`
`NETWORK
`m
`
`User Permission it
`Privacy Manager
`E
`
`User interface m
`
`NETWORK
`jj?
`
`External
`Services
`E
`
`FIG. 1
`
`Ruiz Food Products, Inc.
`Exhibit 1011
`
`

`

`US. Patent
`
`0a. 25, 2011
`
`Sheet 2 of6
`
`US 8,045,995 B2
`
`112
`
`i
`
`NETWORK
`m
`
`Location Broker M
`
`M
`User Location
`Update API m E
`M
`0
`R
`Y
`
`I
`User Locat|on
`Export AP! 152
`
`User Permission & Privacy
`Management 1_5_6_
`
`PROCESSOR @
`
`User Interface L45
`
`FIG. 2
`
`Ruiz Food Products, Inc.
`Exhibit 1011
`
`

`

`US. Patent
`
`0a. 25, 2011
`
`Sheet 3 of6
`
`US 8,045,995 B2
`
`U2
`
`FIG. 3A
`
`U2
`
`FIG. 3B
`
`Ruiz Food Products, Inc.
`Exhibit 1011
`
`

`

`US. Patent
`
`0a. 25, 2011
`
`Sheet 4 of6
`
`US 8,045,995 B2
`
`ii?
`
`Receive from User Location Granularity for a Location-Providing @
`Application and a Location-based Service Application
`
`Receive Location Inputs From at least one Location-Providing Application
`
`%
`
`Store Location inputs in a Database According to Speci?ed
`Location Granularity
`
`m
`
`.
`
`.
`
`Receive Query from a Location-based Service Application
`
`.
`
`.
`
`Process Location inputs Together to Formulate Estimate of
`Current User Locaiton
`
`%
`
`42_0
`
`1
`i
`
`Update the Location of the User in Memory with the Estimate of g
`the Current Location
`
`Send Updated Location of User to the Location-based Service Application %
`According to Speci?ed Location Granularity
`
`i
`
`Receive a Second-Query from a Location-based Service Application £2
`Before Receiving Additional Location Updates
`
`Send the Stored Location to the Location-based Service Application
`
`4_3Ei
`
`FIG. 4
`
`Ruiz Food Products, Inc.
`Exhibit 1011
`
`

`

`US. Patent
`
`0a. 25, 2011
`
`Sheet 5 of6
`
`US 8,045,995 B2
`
`Register as a Location-based Application for System Access
`
`Receive At Least one of an Apptication Token and a Secret
`
`Query a Location of a User and be Authenticated by the System
`
`5%
`
`E
`
`512
`
`i
`
`Receive an Updated Location for the User According to m
`User-Speci?ed Location Granularity
`
`FIG. 5
`
`Ruiz Food Products, Inc.
`Exhibit 1011
`
`

`

`US. Patent
`
`Oct. 25, 2011
`
`Sheet 6 0f 6
`
`US 8,045,995 B2
`
`Receive
`Location Input
`@Qi
`
`i
`
`Store Location
`in Database at
`Maximum
`Precision
`§_O_§
`
`i
`
`Flag Location
`Stored in
`Memory as
`"State" _6_1_2
`
`Receive Query
`w
`
`Updates Since Last
`Version Stored in
`Memory?
`E
`
`Process One
`or More
`Location Inputs
`521
`
`1'
`Store User’s
`Location in
`Memory
`egg
`
`i
`
`Adjust
`Locationin
`Memory to
`Appropriate
`Granularity
`_6_§_2_
`
`Return to
`Location
`Services
`Application
`@
`
`FIG. 6
`
`Ruiz Food Products, Inc.
`Exhibit 1011
`
`

`

`US 8,045,995 B2
`
`1
`CENTRALIZED LOCATION BROKER
`
`BACKGROUND
`
`1. Technical Field
`The disclosed embodiments relate to a system and its meth
`ods for centralizing location updates, and more particularly,
`for centralizing location updates for location-based applica
`tions based on receipt of location inputs from location-pro
`viding applications.
`2. Related Art
`Consumers are becoming increasingly mobile. This
`increase in mobility creates many opportunities for organiZa
`tions to provide consumers With location-based content and
`services. For example, a consumer may subscribe to a loca
`tion-based restaurant revieW service that presents the con
`sumer With a list of popular eateries that are located Within
`driving distance of the consumer’s current location. This
`service may also use the time of day to customiZe the list
`based on the type of meal (e.g., breakfast, lunch, or dinner).
`Consumers generally value this type of location-based con
`tent more than traditional content because it is more focused,
`relevant, and useful. Another service may provide a Way that
`friends can track each other’s locations, or other more user
`integrated type services. Location-based content is informa
`tion provided to a consumer that is keyed to a past, present or
`future geographic location of the consumer. Similarly, loca
`tion-based services are services keyed to geographic location
`information for the consumer.
`Additionally, the sources of location information related to
`a user of such applications have groWn in recent years. These
`include devices that supply, for instance, a global positioning
`satellite (GPS) latitude and longitude coordinate set, a Global
`System for Mobile Communications (GSM) cell toWer iden
`ti?er, and a location related to a Wi-Fi access point media
`access control (MAC) address. Applications that integrate
`location information as part of a service provided to a user
`have heretofore used a single location source (or type of
`source) to provide location updates, and generally the loca
`tion information obtained is destined for a single device or
`application.
`
`SUMMARY
`
`By Way of introduction, the embodiments described beloW
`include a system and methods for centraliZing location
`updates in a system for providing updated user locations to
`location-based service applications, and in Which third party
`location-providing applications also may participate.
`In a ?rst aspect, a centraliZed location system includes a
`location update application programming interface (API) to
`receive varying types of location inputs for a user from at least
`one location-providing application. A memory stores a loca
`tion of the user and the location inputs, Wherein the location
`update API periodically updates in the memory the location
`inputs When location updates are received from the at least
`one location-providing application. A location export API,
`upon request from a location-based service application, pro
`cesses the location inputs to estimate a location of the user,
`Which location estimate replaces the stored location in
`memory and is sent to the location-based service application.
`A user interface enables the user to specify a location granu
`larity for at least one of the at least one location-providing
`application and the location-based service application.
`In a second aspect, a method is disclosed for centraliZing
`management of user location for third party use With a cen
`traliZed location system. The system receives from a user a
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`2
`location granularity for at least one location-providing appli
`cation and for at least one location-based service application.
`The system receives location inputs from the at least one
`location-providing application. The system stores the loca
`tion inputs in a database according to the location granularity
`speci?ed by the user for each location-providing application.
`The system receives a query from a location-based service
`application for the location of the user. The system processes
`the location inputs together to formulate an estimate of the
`current location of the user, and updates the location of the
`user in memory With the estimate of the current location. The
`system may then send the updated location of the user to the
`location-based service application in response to the query
`and in accordance With the location granularity speci?ed by
`the user for the location-based service application.
`In a third aspect, a method is disclosed for a method for
`centraliZing management of user location for third party use
`With a centraliZed location system. A location-based service
`application registers system access, and receives at least one
`of an application token and a secret. The location-based ser
`vice application queries a location of a user from the system
`after registration, Wherein the system identi?es the location
`based service application based on at least one of the received
`application token and a hashed encrypted version of the
`secret. The location-based service application receives an
`updated location for the user according to a location granu
`larity speci?ed by the user for the location-based service
`application, Wherein the updated location is estimated from
`processing location inputs for the user obtained from at least
`one location-providing application.
`Other systems, methods, features and advantages Will be,
`or Will become, apparent to one With skill in the art upon
`examination of the folloWing ?gures and detailed description.
`It is intended that all such additional systems, methods, fea
`tures and advantages be included Within this description, be
`Within the scope of the invention, and be protected by the
`folloWing claims.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`The system may be better understood With reference to the
`folloWing draWings and description. The components in the
`?gures are not necessarily to scale, emphasis instead being
`placed upon illustrating the principles of the invention. More
`over, in the ?gures, like-referenced numerals designate cor
`responding parts throughout the different vieWs.
`FIG. 1 is a diagram of an exemplary centraliZed location
`system including a location broker that updates a location for
`service applications according to location inputs received
`from one or more location-providing applications.
`FIG. 2 is a more detailed diagram of the system displayed
`in FIG. 1, With a focus on the location broker.
`FIGS. 3A and 3B are examples of hoW various location
`input types are processed together to best estimate a location
`or area Where a user is currently located.
`FIG. 4 is a How chart of an exemplary method for central
`iZing location updates for location-based service applications
`based on inputs received from location-providing applica
`tions.
`FIG. 5 is a How chart of a further exemplary method for
`centraliZing location updates for location-based service
`applications based on inputs received from location-provid
`ing applications.
`FIG. 6 is a How chart of another method for centraliZing
`location updates for location-based service applications
`based on inputs received from location-providing applica
`tions.
`
`Ruiz Food Products, Inc.
`Exhibit 1011
`
`

`

`US 8,045,995 B2
`
`3
`DETAILED DESCRIPTION
`
`In the following description, numerous speci?c details of
`programming, software modules, user selections, network
`transactions, database queries, database structures, etc., are
`provided for a thorough understanding of various embodi
`ments of the systems and methods disclosed herein. However,
`the disclosed system and methods can be practiced with other
`methods, components, materials, etc., or can be practiced
`without one or more of the speci?c details. In some cases,
`well-known structures, materials, or operations are not shown
`or described in detail. Furthermore, the described features,
`structures, or characteristics may be combined in any suitable
`manner in one or more embodiments. The components of the
`embodiments as generally described and illustrated in the
`Figures herein could be arranged and designed in a wide
`variety of different con?gurations.
`The order of the steps or actions of the methods described
`in connection with the disclosed embodiments may be
`changed as would be apparent to those skilled in the art. Thus,
`any order appearing in the Figures, such as in ?ow charts or in
`the Detailed Description is for illustrative purposes only and
`is not meant to imply a required order.
`Several aspects of the embodiments described are illus
`trated as software modules or components. As used herein, a
`software module or component may include any type of com
`puter instruction or computer executable code located within
`a memory device and/ or transmitted as electronic signals over
`a system bus or wired or wireless network. A software module
`may, for instance, include one or more physical or logical
`blocks of computer instructions, which may be organiZed as a
`routine, program, object, component, data structure, etc. that
`performs one or more tasks or implements particular abstract
`data types.
`In certain embodiments, a particular software module may
`include disparate instructions stored in different locations of
`a memory device, which together implement the described
`functionality of the module. Indeed, a module may include a
`single instruction or many instructions, and it may be distrib
`uted over several different code segments, among different
`programs, and across several memory devices. Some embodi
`ments may be practiced in a distributed computing environ
`ment where tasks are performed by a remote processing
`device linked through a communications network. In a dis
`tributed computing environment, software modules may be
`located in local and/ or remote memory storage devices.
`Currently, there are location tracking techniques that use,
`for example, one of global positioning satellite (GPS) latitude
`and longitude coordinate sets, Global System for Mobile
`Communications (GSM) cell tower identi?ers, or locations
`related to Wi-Fi access point media access control (MAC)
`addresses. No interface exists, however, that provides a
`robust, reliable, and centraliZed means for ascertaining and
`updating a user’s location that could integrate multiple types
`location inputs, including from third party applications. What
`is needed is a centraliZed location broker for third-parties to
`obtain and update a user’s location. The broker should also
`allow a user to de?ne the level of location precision available
`to speci?c third-parties. For example, a user may desire to
`only expose the user’ s current city to the third-parties, instead
`of a more precise location, such as the block or intersection in
`which the user is located. Thus, the location broker facilitates
`the adoption of location-based services by allowing users to
`selectively expose their location to service providers.
`FIG. 1 is a diagram of an exemplary centraliZed location
`system 100 including a location broker 104 that updates a
`location for service applications 108 according to location
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`4
`inputs received from one or more location-providing appli
`cations 112. Communication, of course, takes place over a
`network 116 that may include the Internet, an Intranet, a local
`area network (LAN), a wide area network (WAN), or other
`network. The location-based service applications 108 may
`include sponsored services 120 such as those provided by the
`entity that owns and/or controls the location broker 104. The
`service applications 108 may also include external, third
`party services 124 that integrate into their development and
`use the bene?ts of the location broker 104 as described herein.
`The location-based service applications 108 may include, but
`are not limited to, location-based alerts, location-based
`advertising, coupon distribution, and services that use the
`location of the user to provide focused content.
`It would be impossible to include all types of location
`based service applications because many are conceivable, and
`all are contemplated here. For instance, a user location could
`be used to tag Flickr® photos or other media to record where
`the user 140 was when the media was recorded. Also, user 140
`could be allowed to annotate records of holidays or commut
`ing patterns, or for easily tracking tax deductible miles. Addi
`tionally, presence indicators may also be included, such as
`putting a badge on a user website that indicates user location,
`which location is periodically updated through the location
`broker 104.
`Furthermore, the location-providing applications 112 may
`include sponsored applications 128 and external, third-party
`applications 132. Examples of location-providing applica
`tions 112 include, but are not limited to, devices that supply
`location inputs such as a GPS latitude and longitude coordi
`nate sets, a GSM cell tower identi?er, and a Bluetooth iden
`ti?er. Further examples of location-providing applications
`112 also include persons or entities that supply the location
`inputs, such as a user- speci?ed identi?er or location, or a third
`party location tracking application such as PlaZes® (based on
`tracking Wi-Fi access point MAC addresses). PlaZes® is a
`social community that connects friends by use of a client
`downloadable through beta.plaZes.com; the company is
`headquartered in Zurich and Berlin. Recently, updates to
`location were made available through the PlaZes® website or
`through text messaging, both of which require the user to
`enter his or her location manually.
`Users 140 are the bene?ciaries of the system 100 and are
`the customers to the location-based service applications 108.
`Users 140 communicate with the location broker 104, usually
`also over the network 116, and through a user interface 144 of
`the location broker 104. The location broker 104 further
`includes a user location update application programming
`interface (API) 148 to update a location stored in the location
`broker 104 for each user 140 based on one or more location
`inputs from the location-providing applications. A user loca
`tion export API 152 then communicatively interfaces with the
`location-based service applications 108 to provide updates of
`the users’ locations upon request, or periodically, as an inte
`gral part of the services provided to the users 140.
`To ensure attention to privacy on a need-to-know basis, the
`user 140 may, through the user interface 144 and in conjunc
`tion with a user permission and privacy manager 156 (vari
`ably referred to as “privacy manager 156”), con?gure a loca
`tion granularity for reads and writes by applications 108 and
`112, respectively, which participate in the system 100. The
`location granularity includes at least a level of location pre
`cision, which may include, but is not limited to, a street
`address, a Zip code, a city, a state, a country, and a latitude/
`longitude coordinate set. While a current location as updated
`in the location broker 104 may be provided down to the street
`address, a given application 108, 112 may only be afforded
`
`Ruiz Food Products, Inc.
`Exhibit 1011
`
`

`

`US 8,045,995 B2
`
`5
`
`20
`
`25
`
`30
`
`5
`access, as con?ned by the user 140, to a Zip code or a city. In
`such a case, only the Zip code or the city Will be provided to
`the application 108, 112 upon request by the application 108,
`112. In addition, the applications 108, 112 may also be cut off
`completely from any location information access, eg from
`reading and Writing, respectively.
`Location granularity control may also be a Way by Which
`the users 140 may adjust sensitivity to the reads or Writes of
`their location, thereby also affecting accuracy of their loca
`tion, as desired. The natural consequence of such control is
`that sometimes a user 140 Will choose to prioritize privacy
`over accuracy. In this manner, the location broker 104 acts as
`a centraliZed interface for updating and exporting a user’s
`location in accordance With the location granularity dictated
`by a user 140. The system 100 thus facilitates the creation,
`adoption, and Wide-spread use of location-based services.
`The location-providing applications 112 may ef?ciently
`update the location of a user 140 and location-based service
`applications 108 may reliably receive the location of a user. In
`addition, the user 140 remains in control over the level of
`location precision distributed to the service providers.
`FIG. 2 is a more detailed diagram of the system 100 dis
`played in FIG. 1, With a focus on the location broker 104. A
`plurality of location-based service applications 108 are des
`ignated as Q1, Q2, .
`.
`. On, and a plurality of location
`providing applications 112 are designated as U1, U2, .
`.
`. Un,
`all able to communicate through the netWork 116 With the
`location broker 104. The location broker 104 includes, as
`before, the user interface 144, the user location update API
`148, the user location export API 152, and the userpermission
`and privacy manager 156.
`Additionally, the location broker 104 may further include a
`processor 160, a memory 164, a location inputs database 168,
`and a service data database 172. One of skill in the art Will
`appreciate that the databases 168 and 172 may be integrated
`in the memory 164 on a single server acting as a location
`broker 104, or may be located remotely across the netWork
`116. One of skill in the art Will also appreciate that the pro
`cessor 160 may include hardWare and/or softWare operatively
`executed on hardWare, and may integrate one or more of the
`user location update API 148, the user location export API
`152, the user permission and privacy manager 156, and the
`user interface 144.
`To use the system 100, a user 140 signs up for one or more
`applications 108, 112 and authoriZes them to, respectively,
`update their location and query their location at a certain
`location granularity. Again, the privacy manager 160 Will
`facilitate this interaction by the user 140, providing the user
`140 With con?guration access to a current list of applications
`108, 112. The users 140 are provided a username and pass
`Word in order to identify themselves to the location broker
`104 for future access. The users 140 are also issued an appli
`cation token (or “userid”) that the applications 108, 112 use to
`identify the user 140 in the system 100.
`The applications 108, 112 may communicate With the loca
`tion broker 104 through an authenticated API (148 and/or
`152). The applications 108, 112 use this token (referred to in
`the API as an appid) and an application-speci?c secret to
`
`35
`
`40
`
`45
`
`50
`
`6
`identify themselves to the location broker 104 When reading
`or Writing user location data. The authentication Works simi
`lar to a hash-based message authentication code in Which
`submitted API parameters are combined With a shared secret
`(betWeen the location broker 104 and each application 108,
`112) by a one-Way hash algorithm to generate a signature
`Which ensures that API calls actually originate from an appli
`cation 108, 112 that knoWs the secret (veri?ed by encrypting
`the parameters and secret sent by the API With the same
`one-Way hash algorithm and comparing this value to the
`submitted signature). The hash-based authentication code
`Works as a unique signature, Which can only be produced by
`introduction of the proper secret.
`Additionally, a timestamp parameter may be required to
`prevent replaysithat is, each application 108, 112 cannot
`query or update a user’s location With a smaller timestamp
`value than has been previously supplied by that application
`108, 112. Without knoWledge of the shared secret, an attacker
`cannot formulate a request containing an updated timestamp;
`checking the timestamp ensures than a request intercepted by
`an attacker and sent unmodi?ed Will be rejected after the
`timestamp has expired (i.e. a request cannot be “replayed”).
`Username, passWords, tokens, secrets, and other account
`speci?c information for users 140 and applications 108, 112
`are stored in the services data database 172.
`The location broker 104 stores in the location inputs data
`base 168 the most recent location supplied by each location
`providing application 108 for each user 140, and in accor
`dance With the location granularity speci?ed by each user
`140. The location-providing applications 108 can specify
`location in a number of Ways, Which include, but are not
`limited to: a latitude/longitude coordinate set, a postal code, a
`street address, a GSM cell toWer identi?er, a Bluetooth iden
`ti?er, a user-speci?ed identi?er or location, and an identi?er
`from an external system (PlaZes®, Upcoming.org, etc.). See
`also Table 1 below, Which provides an exemplary manner of
`storing location data in the location inputs database 168.
`One location per user-application pair is stored in the loca
`tion inputs database 168, thus the location broker 104 gener
`ally provides access to a user’ s current location, not a location
`history of user locations. When a user’s location is requested,
`the location broker 104 combines location information (raW
`data from database 168) for that user 140 into a current
`estimate of the user’s location, Which is returned in extensible
`markup language @(ML) or another compatible format,
`Which provides a standardized location-reporting format With
`Which to export to location-based applications 108. To do so,
`the raW location inputs are jointly processed by at least the
`user location export API 152 and possibly also via otherAPIs
`(not shoWn) internal to the location broker 104 and Which
`may be integrated as part of the user location update API 148
`or the processor 160. One embodiment of such processing
`includes use of a set of softWare objects that are mapped to
`various input type parameters, such as shoWn in Table 1,
`wherein each object is accessed in turn according to prece
`dence until the closest estimate of a user’s location is
`achieved. The ordering of precedence as indicated is exem
`plary only, and is not intended to limit the scope of hoW raW
`location inputs are processed.
`
`TABLE 1
`
`Map of Objects to Processing Precedence
`
`Parameter Required
`
`Format Description
`
`Precedence
`
`Formatted Address
`
`addr
`
`(+city or
`postal)
`
`String
`
`Street address (e. g. 1350
`University) — requires city or
`
`7
`
`po stal
`
`Ruiz Food Products, Inc.
`Exhibit 1011
`
`

`

`US 8,045,995 B2
`
`TABLE l-continued
`
`Map of Obiects to Processing Precedence
`
`Parameter Required
`
`Format Description
`
`Precedence
`
`city
`
`state
`postal
`
`country
`lat
`lon
`mnc
`mcc
`lac
`cellid
`loc
`
`(+state,
`country,
`or postal)
`N
`N (need + country
`if not US)
`N
`1
`1
`3
`3
`3
`3
`N
`
`name
`
`N
`
`GPS
`
`GSM
`
`Free-form
`
`External Identi?er
`
`Street Intersection
`
`N
`woeid
`plaZesid N
`ylocalid N
`upvenueid N
`street1
`2 (+postal
`or city)
`2
`
`street2
`
`String
`
`City name — requires state,
`country or postal
`
`String
`String
`
`State name
`Postal code
`
`String
`Float
`Float
`Int
`Int
`Int
`Int
`String
`
`String
`
`Int
`String
`Int
`Int
`String
`
`String
`
`Country
`Latitude (decimal degrees)
`Longitude (decimal degrees)
`Mobile Network Code
`Country Code
`LAC (Location Area Identi?er)
`Cell ID (identi?er)
`Free-form location — the system
`100 makes a best guess
`translation
`POI/AOI (area or person of
`interest) name or 3-letter
`Airport code — may include a
`user-speci?ed identi?er
`Where on Earth ID
`PlaZes ® PlaZe key
`Y! ® Local ID
`Upcoming.org venue ID
`Street name 1 for intersection
`lookup
`Street name 2 for intersection
`lookup
`
`11
`
`12
`10
`
`13
`1
`1
`9
`9
`9
`9
`14
`
`6
`
`2
`5
`3
`4
`8
`
`8
`
`Note that Table 1 is in abstract form and is for exemplary
`purposes only to show one way that location inputs of differ
`ent types may be stored and processed to produce a single
`location output. If the location broker 104 ?nds a valid loca
`tion from precedence 1, the location broker 104 uses that
`location; if not, the location broker 104 moves on to location
`input data with precedence 2, etc. In the “Required” column,
`corresponding numbers indicate that the parameters must all
`be present if any are present. Note also that while location
`inputs based on Wi-Fi access point MAC addresses is not
`included in Table 1, they could be, and such inputs are also
`available though the PlaZes® system (among others) from
`which the location broker 104 accepts PlaZe identi?ers.
`Additionally, in some embodiments, a user location that is
`sent by the location broker 104 in response to a location-based
`service application 108 query may also include other loca
`tion-sensitive metadata, such as the nearest metro station,
`current weather forecast, and current local time. Also, such
`metadata (or other message included with the response from
`the location broker 104) may include a note that speci?es the
`types of location inputs that were available and used in esti
`mating the location or the user 140, including what method of
`processing was used to combine location inputs. An example
`of how the system 100 works in conjunction with the process
`ing of raw location inputs may be helpful.
`FIGS. 3A and 3B are examples of how various location
`input types are processed together to best estimate a location
`or area where a user 140 is currently located. Assume a user
`140 has authorized two location-providing app