Patent Publication Number: US-9838848-B2

Title: Venue data prefetch

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
     This application claims priority to U.S. Provisional Patent Application No. 62/172,022, entitled “Venue Data Prefetch,” filed Jun. 5, 2015, the entire contents of which are incorporated herein by reference. 
    
    
     TECHNICAL FIELD 
     This disclosure relates generally to location determination. 
     BACKGROUND 
     People often carry mobile devices to venues such as office buildings, stadiums or shopping centers. In a venue, various walls, doors, hallways or stairs limit people&#39;s movement. A mobile device can display a map of a venue and a location of the mobile device on the map, if the mobile device has the map and can determine the location. A mobile device may visit many venues. Storing maps including detailed structural information of venues that the mobile device may visit on the mobile device can take up much resource on the mobile device. Downloading venue information for each venue in real time when the mobile device visits that venue may be impractical. This can be due to unreliable wireless data transmission or high cellular data transmission cost. 
     SUMMARY 
     Techniques for prefetching venue data based on predicted user behavior are disclosed. A mobile device can request, from a user routine subsystem of the mobile device, a list of locations that a user of the mobile device routinely visits while the user carries the mobile device. The mobile device can determine a cluster of these locations that are within a specified distance between one another. The mobile device can request venue data for these locations from a location server, even if the user is not at one of these locations. The venue data can include a venue map and a venue location fingerprint for each location. Upon detecting that the user entered a venue at one of these locations, the mobile device can determine a location of the user inside of the venue using the venue location fingerprint. The mobile device can then display the location on a venue map. 
     The features described in this specification can be implemented to achieve various advantages. For example, compared to conventional techniques for storing venue data of all venues on a mobile device, the techniques disclosed in this specification allow a mobile device to store venue data only for those venues that the mobile device determines that a user is likely to visit, thereby saving storage space. Compared to conventional techniques of downloading venue data only upon determining that the user entered a venue, the techniques disclosed in this specification allow a mobile device to fetch venue data before the user arrives at a venue and at a time that is most convenient (e.g., when fast Wi-Fi™ connections are available), thereby avoiding having to download data at a time when wireless connection is slow or expensive (e.g., through cellular network with bandwidth limit). 
     The details of one or more implementations of the techniques are set forth in the accompanying drawings and the description below. Other features, aspects and advantages of the indoor location survey techniques will become apparent from the description, the drawings and the claims. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a diagram illustrating example venue data prefetching based on locations of interests. 
         FIG. 2  is a diagram illustrating an example venue data update. 
         FIG. 3  is a diagram illustrating tiered data delivery in venue data prefetching. 
         FIG. 4  is a block diagram illustrating components of an example mobile device implementing venue data prefetching. 
         FIG. 5  is an example user interface for displaying a location on a venue map. 
         FIG. 6A  is a flowchart of an example process of location estimation. 
         FIG. 6B  is a flowchart of an example process of cluster generation. 
         FIG. 7  is a block diagram illustrating an exemplary device architecture of a mobile device implementing the features and operations described in reference to  FIGS. 1-6 . 
         FIG. 8  is a block diagram of an exemplary network operating environment for the mobile devices of  FIGS. 1-7 . 
     
    
    
     Like reference symbols in the various drawings indicate like elements. 
     DETAILED DESCRIPTION 
     Exemplary Venue Data Prefetching 
       FIG. 1  is a diagram illustrating example venue data prefetching based on locations of interests. Mobile device  102  can be carried by user  104  to various locations. A user routine subsystem (also referred to as a core routine subsystem) of mobile device  102  can record the locations visited on mobile device  102 . The user routine subsystem can determine that, among various locations mobile device  102  has visited, locations  106 ,  108 ,  110 ,  112 ,  114  and  116  are locations of interests (LOIs, also referred to as routine locations). An LOI can be a geographic location that is determined to have a significant meaning to user  104  of mobile device  102  such that user  104  is likely to visit the location in the future. Mobile device  102  can determine LOIs  106 ,  108 ,  110 ,  112 ,  114  and  116  based on frequency of past visits of mobile device  102  to locations  106 ,  108 ,  110 ,  112 ,  114  and  116 . Mobile device  102  can transition from one LOI to another, from an LOI to another location, or to another location to a LOI. For example, mobile device  102  can travel from LOI  110  to LOI  116  through path  117  or paths  118  and  119 . Mobile device  102  can designate a location previously not significant to user  104  as an LOI if user  104  starts to visit that location regularly. 
     Mobile device  102  can determine one or more clusters (e.g., cluster  120 ) of LOIs previous determined by mobile device  102 . Cluster  120  can include a group of LOIs. Mobile device  102  can determine cluster  120  upon determining that at least a threshold number of LOIs are located within a threshold distance from one another. Mobile device  102  can designate the LOIs that are located within a threshold distance from one another as LOIs in the cluster, e.g., cluster  120 . In the example shown, cluster  120  includes LOIs  108 ,  110 ,  112 ,  114  and  116 . 
     Mobile device  102  can determine cluster  120  using various clustering techniques. Mobile device  102  can use current location of user  104  as a parameter of the clustering. Cluster  120  can overlap with another cluster of LOIs. Additional details and examples of creating and managing clusters are described below in reference to  FIG. 6B . 
     Mobile device  102  can determine that mobile device  102  is located within cluster  120  at a given time. Mobile device  102  can make the determination upon determining that mobile device  102  is located within a threshold radius from a centroid of cluster  120 . Mobile device  102  can determine the centroid from the LOIs in the group. Mobile device  102  can determine the threshold radius based on a user travel pattern, e.g., a maximum distance that the user of mobile device  102  is likely to travel in a given time period. For example, mobile device  102  can determine that the radius is a maximum distance that the user can travel by a motor vehicle in one day, e.g., 50 kilometers, 200 kilometers or 300 kilometers. The radius of the cluster may or may not be the same as the threshold distance for forming the cluster. Mobile device  102  may choose a threshold distance that is smaller than the radius. 
     Upon determining that mobile device  102  is located within cluster  120 , mobile device  102  can obtain venue data for each LOI in cluster  120 . Mobile device  102  can submit request  124  to location server  128  through a communications network. Request  124  can include a list of LOIs  108 ,  110 ,  112 ,  114  and  116 . LOIs  108 ,  110 ,  112 ,  114  and  116  can be represented in request  124  by identifiers or geographic coordinates. In response, location server  128  can provide venue data  132  for each of LOIs  108 ,  110 ,  112 ,  114  and  116 , if available. 
     Upon receiving an identifier or geographic coordinates for a location, location server  128  can determine whether that location is within the boundary of a venue, and whether location server  128  has venue data  132  for that venue. A venue can be a structure (e.g., a building) accessible by a pedestrian. Data for a venue can include a location fingerprint for the venue that indicates, for example, expected wireless signal measurements at various locations in the venue. Venue data  132  can include a map of the venue. Venue data  132  can include venue floor data, including floor plan for each floor, and wireless access points detectable at each floor. Location server  128  can acquire venue data  132  by performing one or more surveys for each venue. 
     Upon receiving venue data  132 , mobile device  102  can store venue data  132  on mobile device  102 . Upon entering a LOI  108 ,  110 ,  112 ,  114  or  116 , mobile device  102  can determine if venue data for that LOI is available. If yes, mobile device  102  can determine a location of mobile device  102  in that venue using the location fingerprint data in venue data  132 . The location can indicate, for example, on which floor, in which room, which hallway or which lobby mobile device  102  is located. Mobile device  102  can display a map of that venue, and display a representation of the location of mobile device  102  on the map. 
     Mobile device  102  can transition from one LOI to another. For example, mobile device  102  can travel from LOI  110  to LOI  116 . Upon transitioning from LOI  110  to LOI  116 , mobile device  102  can enter a venue at LOI  116 . LOI  116  being inside cluster  120 , mobile device  102  already stores venue data for the venue at LOI  116 , including location fingerprint data and a venue map. Mobile device  102  can determine a location of mobile device  102  inside the venue and display the location on the venue map without having to download the venue data again. If mobile device  102  moves from LOI  110  to LOI  106  that is outside of cluster  120 , mobile device  102  may request a venue data update. 
     Venue data  132  is used as an example in  FIG. 1 . In addition to venue data, mobile device  102  can prefetch various location data related to cluster  120 . The location data can include location-specific information on each LOI in cluster  120 . The information can include data or application programs. 
       FIG. 2  is a diagram illustrating an example venue data update. Mobile device  102  can prefetch venue data of a venue before mobile device  102  visits that venue. Mobile device  102  can update the prefetched data in various manners. In some implementations, mobile device  102  can update the prefetched venue data periodically. Mobile device  102  can determine periodically (e.g., daily) whether mobile device  102  is outside of a cluster of LOIs for which mobile device  102  already prefetched venue data. For example, after prefetching venue data for cluster  120 , mobile device  102  can determine, at a predetermined and user configurable time (e.g., midnight) whether a distance between mobile device  102  and a centroid of cluster  120  is greater than the threshold radius (e.g., 200 kilometers). If yes, mobile device  102  can determine new cluster  202  of LOIs, and prefetch venue data for LOIs in new cluster  202 . 
     For example, mobile device  102  can determine that mobile device  102  has travelled to LOI  106 , 350 kilometers from the centroid, farther away than a 200 kilometer radius. Mobile device  102  can then determine new cluster  202 . Determining new cluster  202  can include clustering LOIs using various techniques, where mobile device  102  uses a new location of mobile device  102  (e.g., LOI  106 ) as a parameter of clustering. New cluster  202  may or may not overlap cluster  120 . To trigger mobile device  102  to determine new cluster  202  and to fetch of new venue data, mobile device  102  need not travel more than the threshold radius of cluster  120 . For example, traveling from LOI  108  to LOI  106  can trigger the update, if LOI  108  is at the edge of cluster  120  and LOI  106  is farther away from the centroid than LOI  108  is. 
     Example Venue Data 
       FIG. 3  is a diagram illustrating tiered data delivery in venue data prefetching. Mobile device  102  can pre-fetch venue data by tiles. A tile can be a geographic area that is treated as a unit in data delivery. 
     For example, mobile device  102  can fetch venue data for cluster  120  of LOIs including LOI  110 . Mobile device  102  can submit a location request including geographic coordinates of LOI  110  to a location server, e.g., location server  128 . Location server  128  can determine that LOI  110  geographically correspond to tile  302 . Tile  302  can be a geographic area that corresponds to a campus of, for example, an office compound, a university or a shopping mall. In the example shown, two venues, venue  304  and venue  306  are located in tile  302 . 
     Each of venue  304  and venue  306  can be a space accessible by a pedestrian. Each of venue  304  and venue  306  can include one or more constraints limiting the pedestrian&#39;s movement in the space. These constraints can include, for example, map constraints (e.g., walls, railings, or cubicle separators), pathway constraints (e.g., a pedestrian walking on a pathway defined by road signs tends to follow the pathway), or pedestrian motion constraints (e.g., a pedestrian cannot move faster than X miles per hour, or move vertically when not in a stairway or elevator). Each of venue  304  and venue  306  can be a physical structure. The physical structure can be closed (e.g., an office building) or open (e.g., an open stadium). The space can be indoor space inside of the physical structure, or if the physical structure is open, space inside of a bounding space of the physical structure. Each of venue  304  and venue  306  can be mobile (e.g., an airplane, a cruise ship or a mobile oil platform). 
     Upon receiving the location request, location server  128  can provide tile location data  308  to mobile device  102  as a response. Tile location data  308  can include coarse location data  310  for venue  304  and coarse location data  312  for venue  306 . Each of coarse location data  310  and  312  can include a respective identifier for venues  304  and  306 , and a two-dimensional or three-dimensional bounding box corresponding to space that venues  304  and  306  occupy on Earth. For example, the coarse location data of venue  304  can include bounding box that encloses venue  304 . Mobile device  102  can use the bounding boxes to determine whether to request venue data from location server  128 . 
     Using the bounding boxes in tile location data  308 , mobile device  102  can determine that mobile device entered venue  306 . Upon determining that mobile device  102  entered venue  306 , mobile device  102  can request detailed venue data  314 . Detailed venue data  314  corresponding to venue  306  can include venue map  316  and location fingerprint  318 . Venue map  316  can include a map of internal structures of venue  306 , including a floor plan for each floor of venue  306 . Location fingerprint  318  can include expected measurements of various signal sources (e.g., wireless access points of a Wi-Fi™ network) at each location inside venue  306 . Mobile device  102  can use detected signals and location fingerprint  318  to determine a location inside venue  306 . 
     In some implementations, during prefetching of venue data, location server  128  can provide detailed venue data  314  to mobile device  102  as part of tile location data  308 . Accordingly, mobile device  102  can store detailed location data for each venue in cluster  120  of LOIs after a successful prefetch. After storing the detailed location data, mobile device  102  can request venue data from location server  128  only during a venue data update, if mobile device  102  visits a venue outside of cluster  120  or if mobile device  102  visits a venue that is not located at an LOI. 
     Exemplary Device 
       FIG. 4  is a block diagram illustrating components of example mobile device  102  implementing venue data prefetching. Each component of mobile device can include a combination of hardware, software and firmware subcomponents. 
     Mobile device  102  can include core routine subsystem  402 . Core routine subsystem  402  is a component of mobile device  102  configured to determine one or more LOIs, including LOIs  106 ,  108 ,  110 ,  112 ,  114 , and  116 . Core routine subsystem  402  can include LOI module  404  and LOI data store  406 . LOI module  404  is a component of core routine subsystem  402  configured to determine a location of mobile device  102  using various technologies. For example, LOI module  404  can determine a location using known locations of wireless access points detected by radio frequency (RF) receiver  408 . LOI module  404  can then determine that the location is an LOI upon determining that mobile device  102  visited that location for more than a threshold number of times during a time period. LOI module  404  can then store data representing the LOI, including an identifier, geographic coordinates and a size (e.g., radius) of the location in LOI data store  406 . 
     Mobile device  102  can include location data prefetch subsystem  410 . Location data prefetch subsystem  410  is a component of mobile device configured to prefetch location data for LOIs before mobile device  102  visits anyone of the LOIs. Location data prefetch subsystem  410  can include location cluster module  412 . Location cluster module  412  is a component of location data prefetch subsystem  410  configured to determine a cluster of LOIs (e.g., cluster  120 ). Location cluster module  412  can determine a frequency (e.g., daily) of prefetching the venue data. At given time (e.g., midnight every day), location cluster module  412  can determine whether mobile device  102  has moved out of a cluster. If yes, location cluster module  412  can cause location interface  414  to request venue data from a location server. In some implementations, location cluster module  412  can cause location interface  414  to request venue data upon determining that mobile device  102  moved out of a cluster, regardless of whether the time is the given time. 
     Location interface  414  is a component of venue data subsystem configured to submit a request to a location server, and receive venue data from the location server in response. The request can include geographic coordinates of the LOIs in a cluster. The received venue data can include tiled location data or detailed venue data or both. Upon receiving the venue data, location interface  414  can store the venue data in location data store  416 . 
     Mobile device  102  can include venue location subsystem  418 . Venue location subsystem  418  is a component of mobile device  102  configured to determine a location of mobile device  102  inside of a venue. Venue location subsystem  418  can include location calculator  420 . Location calculator  420  is a component of venue location subsystem  418  configured to determine the location using wireless signals from signal sources including wireless access points. Location calculator  420  can receive identifiers (e.g., media access control (MAC) addresses) of detected signal sources from RF receiver  408 , receive measurements (e.g., received signal strength indicators or RSSIs) of the detected signals. Location calculator  420  can then determine a probability distribution of various possible locations of mobile device  102  using location fingerprint data retrieved from location data store  416 . Location calculator  420  can then estimate a location of mobile device  102  based on the probability distribution. 
     Venue location subsystem  418  can include location user interface module  422 . Location user interface module  422  is a component of venue location subsystem  418  configured to retrieve a venue map from location data store  416 . Location user interface module  422  can receive a location of mobile device  102  inside a venue. Location user interface module  422  can then display the location of mobile device  102  on the venue map on a display device (e.g., a touch sensitive screen or other display surface) of mobile device  102 . 
     Example User Interface 
       FIG. 5  is an example user for displaying a location on a venue map. Mobile device  102  can include display surface  501 . Display surface  501  can include a display screen. Mobile device  102  can move between locations. For example, mobile device  102  can move between venues at LOIs  110 ,  112 ,  114  and  116 . Mobile device  102  can prefetch venue data for these venues. 
     While mobile device  102  moves into a venue located at a LOI, mobile device  102  can determine a location of mobile device  102  in the venue, and determine a floor level on which mobile device  102  is located. While mobile device  102  into the venue, mobile device  102  can display map  502  of the venue. Map  502  can include a floor plan of a current floor level (e.g., ground floor) of mobile device  102 . Mobile device  102  can display marker  504  indicating the location, and uncertainty indicator  506  to indicate a radius of uncertainty of the location. Upon determining mobile device  102  moved up or down to a different floor, mobile device  102  can automatically update map  502  to display a new floor plan. Mobile device  102  can display respective floor indicator  508  (e.g., a label) in association with each floor plan. 
     If mobile device  102  moves to another LOI inside of a current cluster, mobile device  102  can display a new venue map. Since the venue map has been prefetched, mobile device  102  need not communicate with a location server each time mobile device enters a new venue. 
     Example Procedures 
       FIG. 6A  is a flowchart of example process  600  of location estimation. Process  600  can be performed by mobile device  102 . 
     Mobile device  102  can determine ( 602 ) LOIs using data from a user routine determination component of mobile device  102 . The user routine determination component can include core routine subsystem  402 . Each LOI can include a location that, according to the data from the user routine determination component of mobile device  102 , a user of mobile device  102  is likely to visit. Each LOI can be at least one of a location that the user visited multiple times in the past, a location at which the user is presently located, or a location that the user routine determination component of the mobile device has determined that the user will visit in the future 
     Mobile device  102  can determine ( 604 ) a cluster of one or more LOIs from the LOIs determined using the data from the user routine determination subsystem. In some implementations, determining the cluster can be based on a user movement radius. The user movement radius can correspond to a distance that the user is able to travel in a specified time span. The user movement radius can be a radius from a centroid of the one or more LOIs. Determining the cluster of one or more LOI is further based on a current location of mobile device  102 . Mobile device  102  can require that an area that encloses the cluster of one or more LOIs cover the current location. The time span can correspond to a time interval (e.g., one day) between the mobile device requests venue data. 
     Mobile device  102  can request ( 606 ) location data from a location server using the one or more LOIs in the cluster prior to visiting the one or more locations of interests by mobile device  102 . The location data can include various location dependent information. For example, the location data can include application programs specific to an LOI. The location data can include venue data including location fingerprint data of one or more venues. Each of the one or more venues can correspond to a respective LOI. The venue data can include respective location fingerprint data for each venue. Each venue can include a space accessible by a pedestrian. The venue data can include a venue map representing constraints in each venue that limit movement of the pedestrian. Determining the cluster and requesting the venue data can occur at a pre-determined interval or upon detecting that mobile device  102  moved out of an area covering the cluster of one or more LOIs 
     Mobile device  102  can perform ( 608 ) a task that is specific to an LOI among the one or more LOIs in the cluster upon determining that mobile device  102  is visiting the LOI. The task can include estimating a location of mobile device  102  inside a venue located at the LOI being visited. Mobile device  102  can provide for display on a display surface mobile device  102  a map of the venue and presenting for display the location inside the venue on the map. 
       FIG. 6B  is a flowchart of example process  620  of cluster generation. Process  620  can be performed by mobile device  102 . 
     Mobile device  102  can determine ( 622 ) multiple LOIs. Determining the LOIs can include predicting locations that will be visited until the next time mobile device  102  prefetches data. The prefetch can occur daily (every 24 hours). Mobile device  102  can sort the predicted location by time of expected visit, e.g., a location that is predicted to be visited sooner (referred to as a sooner prediction) is ahead of a location that is predicted to be visited later (referred to as a later prediction). Mobile device  102  can determine a location that is to be visited based on past user behavior (e.g., a particular user has traveled to that location in the past), crowd-sourced data (e.g., many users visited location A and will visit location B), or a combination of the two. Mobile device  102  can determine a current location. Mobile device  102  can determine historical locations visited. Mobile device  102  can sort the historical locations from most frequently visited to least frequently visited. 
     Mobile device  102  can join ( 624 ) data sets of predicted LOIs, current location, and historical locations in that order. 
     Mobile device  102  can generate ( 626 ) clusters. To generate a cluster Cl, mobile device can start from a LOI designated as a most interesting LOI. Mobile device  102  can designate a sooner prediction as the most interesting LOI. Mobile device  102  can designate the most interesting LOI as an initial centroid of the cluster Cl. Mobile device  102  can merge an LOI into the cluster C 1  upon determining that the LOI is located within a cluster area around the centroid of cluster C 1 . The cluster area can have a radius (e.g., 50 kilometers) that represents a geographic region that a user might travel around a given LOI in a given day. If mobile device  102  determines that an LOI is not contained within cluster area of cluster C 1  or of another cluster, mobile device  102  can generate a new cluster around that LOI. 
     Mobile device  102  can erase ( 628 ) clusters that have not been visited recently (e.g., within the last X number of hours). 
     Mobile device  102  can identify ( 630 ) a specified number (e.g., 200) of venues that are located closest to any cluster. Mobile device can prefetch venue data for those venues. Mobile device can filter out venues that are located beyond a given radius (e.g., 200 kilometers) that represents the maximum distance that a user would likely travel within a day. 
     Mobile device  102  can fetch ( 632 ) venue data for the identified venues. Fetching the venue data can include canceling any pending download tasks for venues that are not in a list of identified venues (e.g., that of a prior venue data prefetch). Mobile device  102  can instruct an operating system of mobile device  102  to download the venue data. The instruction or instructions can specify criteria of the download. The criteria can include, for example, power requirements, availability of cellular data, availability of hotspots, etc. Mobile device  102  can then use holistic knowledge of ongoing network activities to prioritize and optimize a time when the download will occur. 
     Mobile device  102  may visit a location and use data for that location where mobile device  102  has not downloaded the data fully. Mobile device  102  can promote a task that uses the data. The task can use data that mobile device  102  has already downloaded if the download is partially complete. Mobile device  102  can ignore data that has been recently prefetched. Mobile device  102  can download missing data that the prefetch did not cover. 
     Exemplary Mobile Device Architecture 
       FIG. 7  is a block diagram of an exemplary architecture  700  for mobile device  102 . A mobile device (e.g., mobile device  102 ) can include memory interface  702 , one or more data processors, image processors and/or processors  704 , and peripherals interface  706 . Memory interface  702 , one or more processors  704  and/or peripherals interface  706  can be separate components or can be integrated in one or more integrated circuits. Processors  704  can include application processors, baseband processors, and wireless processors. The various components in mobile device  102 , for example, can be coupled by one or more communication buses or signal lines. 
     Sensors, devices and subsystems can be coupled to peripherals interface  706  to facilitate multiple functionalities. For example, motion sensor  710 , light sensor  712  and proximity sensor  714  can be coupled to peripherals interface  706  to facilitate orientation, lighting and proximity functions of the mobile device. Location processor  715  (e.g., GPS receiver) can be connected to peripherals interface  706  to provide geopositioning. Electronic magnetometer  716  (e.g., an integrated circuit chip) can also be connected to peripherals interface  706  to provide data that can be used to determine the direction of magnetic North. Thus, electronic magnetometer  716  can be used as an electronic compass. Motion sensor  710  can include one or more accelerometers configured to determine change of speed and direction of movement of the mobile device. Barometer  717  can include one or more devices connected to peripherals interface  706  and configured to measure pressure of atmosphere around the mobile device. 
     Camera subsystem  720  and an optical sensor  722 , e.g., a charged coupled device (CCD) or a complementary metal-oxide semiconductor (CMOS) optical sensor, can be utilized to facilitate camera functions, such as recording photographs and video clips. 
     Communication functions can be facilitated through one or more wireless communication subsystems  724 , which can include radio frequency receivers and transmitters and/or optical (e.g., infrared) receivers and transmitters. The specific design and implementation of the communication subsystem  724  can depend on the communication network(s) over which a mobile device is intended to operate. For example, a mobile device can include communication subsystems  724  designed to operate over a GSM network, a GPRS network, an EDGE network, a Wi-Fi™ or WiMax™ network and a Bluetooth™ network. In particular, the wireless communication subsystems  724  can include hosting protocols such that the mobile device can be configured as a base station for other wireless devices. 
     Audio subsystem  726  can be coupled to a speaker  728  and a microphone  730  to facilitate voice-enabled functions, such as voice recognition, voice replication, digital recording, and telephony functions. Audio subsystem  726  can be configured to receive voice commands from the user. 
     I/O subsystem  740  can include touch surface controller  742  and/or other input controller(s)  744 . Touch surface controller  742  can be coupled to a touch surface  746  or pad. Touch surface  746  and touch surface controller  742  can, for example, detect contact and movement or break thereof using any of a plurality of touch sensitivity technologies, including but not limited to capacitive, resistive, infrared, and surface acoustic wave technologies, as well as other proximity sensor arrays or other elements for determining one or more points of contact with touch surface  746 . Touch surface  746  can include, for example, a touch screen. 
     Other input controller(s)  744  can be coupled to other input/control devices  748 , such as one or more buttons, rocker switches, thumb-wheel, infrared port, USB port, and/or a pointer device such as a stylus. The one or more buttons (not shown) can include an up/down button for volume control of speaker  728  and/or microphone  730 . 
     In one implementation, a pressing of the button for a first duration may disengage a lock of the touch surface  746 ; and a pressing of the button for a second duration that is longer than the first duration may turn power to mobile device  102  on or off. The user may be able to customize a functionality of one or more of the buttons. The touch surface  746  can, for example, also be used to implement virtual or soft buttons and/or a keyboard. 
     In some implementations, mobile device  102  can present recorded audio and/or video files, such as MP3, AAC, and MPEG files. In some implementations, mobile device  102  can include the functionality of an MP3 player. Mobile device  102  may, therefore, include a pin connector that is compatible with the iPod. Other input/output and control devices can also be used. 
     Memory interface  702  can be coupled to memory  750 . Memory  750  can include high-speed random access memory and/or non-volatile memory, such as one or more magnetic disk storage devices, one or more optical storage devices, and/or flash memory (e.g., NAND, NOR). Memory  750  can store operating system  752 , such as Darwin, RTXC, LINUX, UNIX, OS X, WINDOWS, or an embedded operating system such as VxWorks. Operating system  752  may include instructions for handling basic system services and for performing hardware dependent tasks. In some implementations, operating system  752  can include a kernel (e.g., UNIX kernel). 
     Memory  750  may also store communication instructions  754  to facilitate communicating with one or more additional devices, one or more computers and/or one or more servers. Memory  750  may include graphical user interface instructions  756  to facilitate graphic user interface processing; sensor processing instructions  758  to facilitate sensor-related processing and functions; phone instructions  760  to facilitate phone-related processes and functions; electronic messaging instructions  762  to facilitate electronic-messaging related processes and functions; web browsing instructions  764  to facilitate web browsing-related processes and functions; media processing instructions  766  to facilitate media processing-relate processes and functions; GPS/Navigation instructions  768  to facilitate GPS and navigation-related processes and instructions; camera instructions  770  to facilitate camera-related processes and functions; magnetometer data  772  and calibration instructions  774  to facilitate magnetometer calibration. The memory  750  may also store other software instructions (not shown), such as security instructions, web video instructions to facilitate web video-related processes and functions, and/or web shopping instructions to facilitate web shopping-related processes and functions. In some implementations, the media processing instructions  766  are divided into audio processing instructions and video processing instructions to facilitate audio processing-related processes and functions and video processing-related processes and functions, respectively. An activation record and International Mobile Equipment Identity (IMEI) or similar hardware identifier can also be stored in memory  750 . Memory  750  can store location data instructions  776  that, when executed, can cause processor  704  to perform operations of example processes  600  and  620  as described above in reference to  FIGS. 6A and 6B . 
     Each of the above identified instructions and applications can correspond to a set of instructions for performing one or more functions described above. These instructions need not be implemented as separate software programs, procedures or modules. Memory  750  can include additional instructions or fewer instructions. Furthermore, various functions of the mobile device may be implemented in hardware and/or in software, including in one or more signal processing and/or application specific integrated circuits. 
     Example Operating Environment 
       FIG. 8  is a block diagram of an exemplary network operating environment  800  for the mobile devices of  FIGS. 1-7 . Mobile devices  802   a  and  802   b  can, for example, communicate over one or more wired and/or wireless networks  810  in data communication. For example, a wireless network  812 , e.g., a cellular network, can communicate with a wide area network (WAN)  814 , such as the Internet, by use of a gateway  816 . Likewise, an access device  818 , such as an 802.11g wireless access point, can provide communication access to the wide area network  814 . Each of mobile devices  802   a  and  802   b  can be mobile device  102 . 
     In some implementations, both voice and data communications can be established over wireless network  812  and the access device  818 . For example, mobile device  802   a  can place and receive phone calls (e.g., using voice over Internet Protocol (VoIP) protocols), send and receive e-mail messages (e.g., using Post Office Protocol 3 (POP3)), and retrieve electronic documents and/or streams, such as web pages, photographs, and videos, over wireless network  812 , gateway  816 , and wide area network  814  (e.g., using Transmission Control Protocol/Internet Protocol (TCP/IP) or User Datagram Protocol (UDP)). Likewise, in some implementations, the mobile device  802   b  can place and receive phone calls, send and receive e-mail messages, and retrieve electronic documents over the access device  818  and the wide area network  814 . In some implementations, mobile device  802   a  or  802   b  can be physically connected to the access device  818  using one or more cables and the access device  818  can be a personal computer. In this configuration, mobile device  802   a  or  802   b  can be referred to as a “tethered” device. 
     Mobile devices  802   a  and  802   b  can also establish communications by other means. For example, wireless device  802   a  can communicate with other wireless devices, e.g., other mobile devices, cell phones, etc., over the wireless network  812 . Likewise, mobile devices  802   a  and  802   b  can establish peer-to-peer communications  820 , e.g., a personal area network, by use of one or more communication subsystems, such as the Bluetooth™ communication devices. Other communication protocols and topologies can also be implemented. 
     The mobile device  802   a  or  802   b  can, for example, communicate with one or more services  830 ,  840 , and  850  over the one or more wired and/or wireless networks. For example, one or more venue services  830  can provide venue information to a location server, or to mobile devices  802   a  and  802   b  directly, from a venue data source. The venue information can include venue identifiers associated with venue maps. Survey service  840  can receive survey data from one or more sampling devices and provide the survey data to location server  128 . Location server  128  can provide location service  850 . Location service  850  can include providing venue maps and location fingerprints generated from survey data to mobile devices  802   a  and  802   b.    
     Mobile device  802   a  or  802   b  can also access other data and content over the one or more wired and/or wireless networks. For example, content publishers, such as news sites, Really Simple Syndication (RSS) feeds, web sites, blogs, social networking sites, developer networks, etc., can be accessed by mobile device  802   a  or  802   b . Such access can be provided by invocation of a web browsing function or application (e.g., a browser) in response to a user touching, for example, a Web object. 
     A number of implementations of the invention have been described. Nevertheless, it will be understood that various modifications can be made without departing from the spirit and scope of the invention.