Proactive recording of locations for backtracking

Abstract

A method, non-transitory machine-readable medium, and system for providing historical positioning information are described. In one embodiment, a device detects one or more conditions in user context data that trigger collection of a set of historical positions for a lookback window, the device receives at least one historical position from the set of historical positions for the lookback window, the device classifies the at least one historical position as a candidate location for a backtrack route based on one or more characteristics, and the device determines to provide the at least one historical position as part of the lookback window based on the classification.

Description

[Technical field]

[0001] (Related Applications) This application claims the benefit of priority to U.S. patent application Ser. No. 18 / 299,011, entitled "Proactive Recording of Locations for Backtracking," filed April 11, 2023, and U.S. Provisional Application No. 63 / 339,863, entitled "Proactive Recording of Locations for Backtracking," filed May 09, 2022, each of which is incorporated herein by reference.

[0002] SUMMARY OF THE DISCLOSURE The embodiments described herein relate to the presentation of location services. [Background technology]

[0003] Hikers, walkers, and cyclists do not usually plan to get lost, and as a result, previous route information may not be readily available on the user's device when the user needs it and / or when network access is unavailable because positioning information cannot be obtained. Even if the user has access to map data, they may not know where they are located relative to the trail in the map data during a hike if they deviate from the trail. Thus, techniques are needed to help users find their way back to familiar locations or provide directions for emergency services to locate the user. [Brief description of the drawings]

[0004] [Figure 1] FIG. 1 is a block diagram of a network operating environment for a mobile device, according to one embodiment.

[0005] [Diagram 2] FIG. 2 is a block diagram for a location service according to one embodiment.

[0006] [Diagram 3] FIG. 1 is a flow diagram of an extended mode technique according to one embodiment.

[0007] [Figure 4] FIG. 1 is a flow diagram illustrating a location services approach according to one embodiment.

[0008] [Diagram 5] FIG. 2 illustrates a block diagram of a lookback window, according to one embodiment.

[0009] [Figure 6] 1 is a flow diagram of a location service according to one embodiment.

[0010] [Figure 7] FIG. 2 illustrates a block diagram of a lookback window, according to one embodiment.

[0011] [Figure 8] 1 illustrates a user interface for a location service according to one embodiment.

[0012] [Figure 9] 1 illustrates a user interface for a location service according to one embodiment.

[0013] [Figure 10] FIG. 1 is a block diagram illustrating an example API architecture that may be used in some embodiments.

[0014] [Figure 11] FIG. 1 is a block diagram of a device architecture for a mobile or embedded device, according to one embodiment.

[0015] [Figure 12] FIG. 1 is a block diagram of a computing system, according to one embodiment. Summary of the Invention

[0016] A method, non-transitory machine-readable medium, and system for providing historical positioning information are described. In one embodiment, a device detects one or more conditions in user context data that triggers collection of a set of historical positions for a lookback window. The device receives at least one historical position from a set of historical positions for a lookback window, the device classifies the at least one historical position as a candidate location for a backtrack route based on one or more characteristics, and the device determines to provide the at least one historical position as part of the lookback window based on the classification. In one embodiment, the one or more conditions are at least one of a motion classification during motion, a threshold period of time without network access, a classification of a sparse environment, or a threshold distance from a frequently visited location. In another embodiment, the device receives a request for the lookback window from an application, and in response to the request, sorts historical positions in the set of historical positions within the lookback window from a last classified historical position in the set to truncate historical positions in the set of historical positions prior to the most recent candidate position to identify a most recent candidate historical position for starting a backtrack route. In one embodiment, the device deletes the truncated historical positions from the electronic device. In another embodiment, an application is entitled to request a lookback window. An embodiment may provide for the device to analyze the user context data to determine that a set of conditions are met for proactively acquiring positioning data in an extended mode, the extended mode including a duty cycle position information request for acquiring intermittent position fixes. In one embodiment, the one or more characteristics include a duration of a lookback window, a distance from a frequently visited or trusted location, a timing for acquiring historical positioning information before and after entry of a motorized or electric vehicle, a structural density classification, an access point density, a movement classification, a transportation mode classification, or a user activity. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0017] The embodiments provided herein describe obtaining positioning information from a Global Navigation Satellite System (GNSS), such as a Global Positioning System (GPS), when one or more backtracking conditions are met. The one or more backtracking conditions are a set of conditions that allow for an inference that the user is on an unfamiliar route, in the wilderness, is part of an athletic session, is unable to recharge their device for an extended period of time, and / or is engaged in any other activity that may require retracing steps taken on the route. Based on the observed set of backtracking conditions, a prediction is made that the user may require historical positioning information to be able to retrace the user's steps using a backtrack route and to request the electronic device to proactively obtain historical positioning information. The backtrack route may be a set of historical positions obtained over a lookback window of time that allows the user to retrace the steps. The lookback window is a set of historical positions over a recent period that are likely to be required to retrace the steps while protecting the user's privacy from bad actors looking for more routes than the recent backtrack route. In some embodiments, the lookback window of positions returned upon request is adjusted (e.g., truncated, pruned, etc.) to provide positioning information relevant only to the immediate need for the backtrack route.

[0018] The embodiments described herein provide a backtrack classifier that, upon request to the electronic device, classifies retrieved historical positions as candidate positions or not candidate positions in a backtrack route for a user of the electronic device. In one embodiment, the historical positions are classified to find the most recent historical position for which a backtrack route may be required. The historical positions specified as part of a backtrack route may be provided to a location services application upon request to assist the user in retracing steps when potentially missing and / or requesting assistance in an emergency situation.

[0019] Because nonstop or continuous collection of positioning information can drain resources (e.g., battery, processor usage, etc.) when users are unable to recharge their devices (e.g., in the wilderness or lost), electronic devices may obtain position information in a power-saving extended mode when one or more backtrack conditions are met. The mode change may be a deceleration from a higher power state with more accurate location monitoring (e.g., non-extended mode) to a lower power state with coarse location monitoring (e.g., extended mode) to extend battery life. Some embodiments provided herein describe a power-saving mode for a device capable of receiving information from a global navigation satellite system (GNSS), such as a global positioning system (GPS), to execute a location services application. The location services application may repeatedly request positioning information (e.g., GPS data) over a period of time to provide a trajectory of the device's movement and / or a distance the device has traveled over a period of time. In some embodiments, an extended power saving mode (extended mode) approach is described for extending the battery life of a device (e.g., a smart watch, a step tracking device, a location services device, etc.) while running a location services application and / or collecting positioning information for a location services application during an extended period of time during which a user may not be able to recharge their device. Battery life is the length of time that a device can continue to execute instructions before the device battery needs to be recharged. For example, a location services application that receives a request to record the location of a device for a user hiking, running, participating in a marathon, going on a camping trip, and / or any other activity may need to record positioning information using GNSS for an extended period of time without access to a way to recharge the battery and may need to change the functionality of the device to extend the battery life.In another example, positioning information may be collected so that location information can be provided if the user is lost or in an emergency situation and requires that the user and / or a provider of assistance to the user be able to access the location information after an extended period of time when the user is unable to recharge the device. In a non-extended mode, positioning information is obtained continuously at defined time intervals (e.g., every second) which may drain a battery if the positioning information is collected for a period that exceeds the device's battery life available before the device needs to be recharged.

[0020] In one embodiment, the extended mode provides duty cycled GNSS requests for positioning information. The duty cycle is a portion of a defined period during which the system is active. In the extended mode, collection of positioning information may be requested every N minute period with intermittently received position fixes. The intermittently received position fixes may be requested and received at any time within the period such that position fixes are received at irregular time intervals. For example, the intermittently received position fixes are received at various times within the N minute period and / or position fixes are requested and received continuously for various durations during the duty cycle period. The intermittent reception of position fixes allows the application processor (AP) and / or radio processor (e.g., GPS processor) to sleep between requests and / or process requests by other applications. Some embodiments may turn off all other functions of the device in the extended mode to allow collection of positioning information, health information, location services applications, and / or any other limited set of applications.

[0021] In some embodiments, a user context (e.g., a set of conditions) may determine which mode (e.g., enhanced mode, non-enhanced mode) with corresponding positioning techniques and resources of the electronic device used to acquire positioning information. User data may be analyzed to determine whether a user context exists to trigger a change in the corresponding mode for determining the positioning information performed on the electronic device. Alternatively, the enhanced mode may be explicitly selected by a user via a user interface of the device.

[0022] 1 is a block diagram of a network operating environment 100 for a mobile device, according to one embodiment. The network operating environment 100 includes an electronic device, such as a mobile device 102. The mobile device 102 can be any electronic device capable of communicating with a wireless network and / or wireless accessory devices. Some examples of the mobile device 102 include, but are not limited to, smartphones, tablet computers, notebook computers, wearable devices (e.g., smart watches or other wearable computing accessories), mobile media players, personal digital assistants, AirPods®, EarPods®, PowerBeats®, AirTags®, locator tags, headphones, head-mounted displays, health devices, speakers, and other similar devices. In one embodiment, an accessory device can be paired with the mobile device 102. By way of example, the accessory device may be a device such as Apple AirPods®, EarPods®, PowerBeats®, exercise equipment, vehicles, bicycles, scooters, smart TVs, Homepods, automated assistant devices, home security systems, and / or any other mobile accessory device.

[0023] Each of the mobile devices 102 may optionally include a user interface, such as the user interface 104 of the mobile device 102. In other embodiments, the mobile device may not have a user interface. The mobile device 102 may be a third-party device that utilizes an application programming interface to access a device locator service. The third-party device may be provided by a different device manufacturer or may be part of a different ecosystem (e.g., operating system) than the mobile device 102. The mobile device 102 may communicate via one or more wired and / or wireless networks 110 to perform data communications. For example, the wireless network 112 (e.g., cellular network, Wi-Fi network) may communicate with a wide area network 114, such as the Internet, by using a gateway 116. Similarly, an access device 118, such as a mobile hotspot wireless access device, may provide communication access to the wide area network 114. The gateway 116 and the access device 118 may then communicate with the wide area network 114 via a combination of wired and / or wireless networks.

[0024] In some implementations, both voice and data communications may be established via the wireless network 112 and / or the access device 118. For example, the mobile device 102 may make and receive telephone calls (e.g., using a VoIP protocol), send and receive email messages (e.g., using a POP3 protocol), and retrieve electronic documents and / or streams, such as web pages, photos, and videos (e.g., using a TCP / IP or UDP protocol) via the wireless network 112 (e.g., as shown at 120), the gateway 116, and the wide area network 114. In some implementations, the mobile device 102 may make and receive telephone calls, send and receive email messages, and retrieve electronic documents, such as web pages, photos, and videos, via the access device 118 and the wide area network 114. In some implementations, the mobile device 102 may be physically connected to the access device 118 using one or more cables, for example, when the access device 118 is a personal computer. In this configuration, the mobile device 102 may be referred to as a "tethered" device. In one embodiment, the mobile device 102 can communicate with the accessory device via a wireless peer-to-peer connection (not shown) that can be used to synchronize data between the devices.

[0025] The mobile device 102 can communicate with one or more services, such as a telephone service 130, a messaging service 140, a media service 150, a storage service 160, and a device locator service 170, via one or more wired and / or wireless networks 110. For example, the telephone service 130 can enable telephone communications between mobile devices or between a mobile device and a wired telephone device. The telephone service 130 can route Voice over IP (VoIP) calls over the wide area network 114 or can access a cellular voice network (e.g., the wireless network 112). The messaging service 140 can provide, for example, email and / or other messaging services. The media service 150 can provide access to media files, such as, for example, song files, audiobooks, movie files, video clips, and other media data. The storage service 160 can provide network storage capabilities to the mobile device 102 to store documents and media files. The device locator service 170 may enable a user to locate a lost or misplaced device that was, at least at some point, connected to one or more wired and / or wireless networks 110. Other services may also be provided, including software update services for updating operating system or client software on the mobile device. In one embodiment, the messaging service 140, media service 150, storage service 160, and device locator service 170 may each be associated with a cloud service provider, and the various services are facilitated via a cloud service account associated with the mobile device 102.

[0026] The mobile device 102 may have applications, services, and features accessible locally on the device, including location services 180. The mobile device 102 may provide one or more device locator applications 190 (e.g., a "Find my" application, a "Compass" application, a mapping application, etc.) to utilize the device locator service 170 and location services 180 to locate accessory devices, provide mapping applications, and provide navigation applications. A navigation application (e.g., the "Compass" application) assists a user in navigating and backtracking to a historical position on the user's route. A navigation application is an application that provides cardinal directions used for navigation and geographic orientation using any number of methods, including gyroscopes, magnetometers, and / or positioning systems (e.g., GPS receivers). A mapping application is an application that uses maps delivered by a geographic information system (GIS).

[0027] The locally accessible data may be stored in defined locations, such as known locations 182 and secure or trusted locations 184. Machine learning algorithms 186 may be used in embodiments to classify locations, infer relationships between users and locations, and provide route reconstruction and / or distance estimation. In some embodiments, machine learning algorithms 186 may be used to provide estimates for distance using a set of features including, but not limited to, intermittently received position fixes for a route and a straightness metric for the set of position fixes.

[0028] In some cases, machine learning algorithms 186 may be used to identify known locations 182 and / or trusted locations 184. As an example, cluster data analysis may be used to identify, classify, and provide semantic labels for locations, such as locations frequently visited by a user. Safe and trusted locations 184 may be explicitly designated or confirmed as such by a user of the mobile device 102 after data analysis. In other examples, known locations 182 or trusted locations 184 may be classified offline and provided by the device locator service 170 or a third party (e.g., a database with map information). Although cluster analysis is provided as an example of a machine learning algorithm that may be used, one skilled in the art will recognize that other algorithms may be used to identify potential known or trusted locations.

[0029] On-device heuristics and / or machine learning models may be used to infer relationships between users and locations based on analysis of locally stored data at frequently visited locations, including locations frequently visited by the user, known locations, and / or any other locations. For example, frequently visited locations such as home, vehicle, workplace, any location frequently visited by a user with a mobile device (e.g., accessory device and mobile device 102), and / or any other location designated by the user as a trusted location 184. The known locations 182 may be business locations, public spaces, parks, museums, and / or any other locations that the user may frequently visit.

[0030] The defined location may have associated fence information that provides a set of conditions that, when detected, allows for designating or classifying an electronic device to a region of physical space for at least a portion of the defined location. For example, the fence information may provide conditions for classifying an electronic device as either inside or outside a region of physical space associated with the defined location. In another example, the fence information may provide conditions for classifying an electronic device as transitioning between inside or outside a region of the defined location. The fence information may be a geofence having boundary information for the defined location, such as a point location and a range of the region from the point location (e.g., a circular region defined with a radius from the point location, a polygonal shape with distance measurements from the point location, etc.). The fence information may include a set of sensor measurements received by the electronic device that are characteristic of a particular region of the defined location (e.g., fingerprint data including radio frequency (RF) scan data such as Wi-Fi scan traces, etc.). The fence information for each defined location may be stored with a classification type for the location and any semantic labels assigned to the location. The boundary information may include a defined set of boundaries or a radius distance around the point location to allow for creation of a fence for the location. In some embodiments, the fence is a virtual boundary of a real-world geographic area. A global positioning system (GPS) may be used to create a virtual fence around a location and track the physical location of the mobile device 102 within the geofence boundary as well as entry and exit into the bounded area. In some embodiments, there are at least two tiers of fences that may be used to reduce traditional geofence latency. For example, the mode selected based on the analysis of user context data to determine intent may take into account the selection of the granularity of the established fence. In some embodiments, multiple fences may be used to refine the positioning information determined by a coarse-grained geofence.

[0031] The machine learning algorithms 186 may include on-device heuristics, machine learning algorithms, or a combination thereof, to analyze and assign labels for user contexts, such as location status. The location status may be a label for a user context (e.g., a set of conditions, a motion classification) for which a particular positioning technique and resource of the electronic device is used to acquire positioning information. The location status may define a user's current location state and / or a prediction of changes in location state while moving with the electronic device. By proactively acquiring positioning information using techniques appropriate for the location status, latency in providing information for device applications is reduced without incurring a noticeable degradation in the performance of the electronic device that may be experienced by constant requests for positioning information. For example, the user context may indicate the movement or movement of the electronic device, allowing the electronic device to be designated as having a motion classification, such as "on the move", "stable" at a particular defined location for a period of time, or any other defined motion classification. The analysis may be performed using various signals from contextual user data sources available to the mobile device 102, including, but not limited to, sensor data, positioning data, calendar data, transportation card usage data, application data, historical data regarding travel patterns / routines, wireless connection status with accessory devices and / or services (e.g., Bluetooth connection status), device location history, and / or any other data accessible to the mobile device 102. In one embodiment, the wireless connection status with various devices may indicate that the device is stable or "on the move." For example, loss of connection to appliances, security systems, heating / cooling systems, vehicles, other modes of transportation, and / or any other devices may indicate that the mobile device is "on the move."

[0032] In some embodiments, the mobile device 102 may be classified with a “stable” semantic label after remaining within a geographic boundary that defines a location (e.g., trusted location 184) for a defined period of time. In one example, received positioning data for the mobile device 102 may indicate that the electronic device 102 remains within a fence boundary for a particular location for a certain duration (e.g., 5 minutes). Sensor data, such as accelerometer data, may indicate that the mobile device 102 is stationary and support the inference that it is stable. Application data may support the inference that the mobile device 102 is stable, such as the mobile device being located at a calendar appointment location. Application data indicating the type of application in use may also provide an inference that the device is stable, such as using a media application. A user's historical data regarding their on-the-go routines or patterns, such as a bedtime routine at home or a hotel location, may be used to determine whether the mobile device 102 is stable.

[0033] A mobile device 102 may be classified as having an "in motion" label based on previous detected behaviors, patterns, or routines for the user and analyzed on the mobile device 102. For example, a user may have a routine of going to work at the same time every day, and if the data on the device supports that the pattern is repeated, the "in motion" status may be assigned. The speed at which the mobile device is moving or entering and leaving a known geographic area (e.g., using a fence) may allow for the inference that the mobile device 102 is in motion. If the mobile device 102 is detected accelerating in an area of ​​known movement (e.g., roads, highways, railroad tracks, etc.), the mobile device 102 may be given an "in motion" motion classification. Similarly, if a transit application / card is used / in use, the mobile device 102 may be designated as "in motion".

[0034] A mobile device 102 may be classified as “threshold distance,” “near an entrance,” “near an exit,” “entrance,” and / or “exit” of a set of locations or a particular location based on detecting a pattern of sensor values ​​characteristic of being at a location, such as crossing a fence boundary for the individual location or set of locations and / or Wi-Fi scan results characteristic of being within or moving into a location.

[0035] 2 is a block diagram of a location service, according to one embodiment. The location service 180 may include an event monitor module 264 (e.g., fence event monitor, location status monitor, sensor monitor, etc.) that may assist in determining when power and performance modes should be adjusted to determine positioning information. The event monitor module 264 may rely on data from a contextual user data source to act as a cue for user context, and the event monitor module 264 may use heuristics and / or machine learning algorithms 186 to determine user context that triggers mode adjustments. The event monitor module 264 may detect whether a user is entering a defined location and a location location that is unfamiliar to the user. For example, the mobile device 102 may be designated in an "in motion" state using the motion classifier 280, and wireless connection status data may indicate that a Bluetooth connection has been lost between the mobile device 102 and an accessory device, such as a vehicle entertainment system. Continuing with this example, the event monitor module 264 may determine from one or more contextual user data sources that there is at least one indication that there will be a change in the location status and / or movement classification of the mobile device 102, such as that the mobile device 102 may be “moving to a defined location.” User contextual data, such as fence boundary crossings, vehicle exits, transit station exits, user routines, sensor data, application data, etc., may be analyzed to predict that the electronic device is a threshold distance from the defined location and that the mode of the electronic device should be adjusted.

[0036] In one embodiment, the event monitor 264 can detect from the user context data that the user is in a remote location (e.g., the great outdoors), on an unfamiliar route, and / or is unlikely to charge the user's device for an extended period of time. For example, various signals from the user context data, such as application data indicating that the user is tracking a workout, a map application with a hiking path selected for display, loss of cellular service, and / or any other data accessible on the device that provides context for the user's activity that may allow an inference that the user is unable to recharge the electronic device 102, may indicate that the user is unlikely to charge the device. In another example, the user may select a mode that indicates that the user is unable to recharge the electronic device 102.

[0037] The visit monitor module 270 may utilize the event monitor 264, fence information 290, and intrusion detection module 266 to accurately detect intrusion into a defined location and reduce latency for providing positioning information by predicting that a user will request positioning data. The visit monitor module 270 may retrieve fence information 290 to define more precise boundaries for a defined location when the electronic device 102 is detected to cross a coarser granularity geofence boundary, as detected using the intrusion detection module 266. In another embodiment, the visit monitor module 270 may retrieve expected sensor data (e.g., fingerprint data) characteristics of the electronic device 102 along with the location status.

[0038] Proactive services 268 may be used to predict applications and / or services a user may want to access given user context, motion classification, and / or location status. For example, a user may want to access a particular application just before or upon entering a location. Proactive services 268 may select an application based on a user history of application selection or suggest new applications associated with a particular defined location.

[0039] In one embodiment, the electronic device 102 (having the event monitor 264) may detect a set of conditions that allow for the inference that the user may require a backtrack route to allow retracing their steps, and the electronic device 102 may initiate an enhanced mode to obtain positioning information without affecting the performance of the electronic device 102. In one embodiment, the proactive service 268 may adjust the rate of periodic requests to determine positioning information. To handle intermittent receipt of positioning information, the machine learning model 240 may be used to reconstruct a route from user-accessible data and estimate the distance of the route taken by the user.

[0040] In some embodiments, map data accessed by a mapping application 250 is used to estimate distance. A mapping application is an application that uses maps delivered by a geographic information system (GIS). The navigation application 220 can provide heading or direction (e.g., degrees from magnetic north) information about the mobile device 102 that is collected as the user is moving, and the heading data is averaged to eliminate errors in the heading information collected due to variations in heading measurements collected due to device motion (e.g., jostling of the device, hand shaking if the device is worn on the user's wrist, etc.) as the user moves along their trajectory.

[0041] The proactive service 268 and the event monitor 264 can use a motion classifier 280, a density classifier 282, and a backtrack classifier 278. The motion classifier 280, trained on a set of features from data acquired using electronic device sensors, can provide information regarding whether the electronic device 102 is stationary or moving with the user. Although embodiments are not limited to a particular sensor type, a particular sensor data representation, or a particular feature, exemplary sensors and features that can distinguish a particular motion in the sensor data are described herein. The motion classifier can analyze the features provided from the sensor data using one or more models trained to perform motion type discrimination based on the provided features. In some implementations, the electronic device can receive a motion classification from the electronic device or from a server that indicates that the mobile device is moving in a particular mode of movement. The backtrack classifier 278 classifies the acquired historical positions of the mobile device 102 as potential parts of a backtrack route of the user of the electronic device 102.

[0042] A density classifier 282 trained on a set of features from data acquired using electronic device sensors may provide information regarding the density of structure and / or population for a given geographic area. Features considered when classifying a geographic area include, but are not limited to, wireless access point density, radio frequency signal (e.g., Bluetooth, UWB, etc.) density information, and / or map data regarding density and landscape, providing information regarding whether the electronic device 102 is in a dense or sparse geographic area.

[0043] In some embodiments, the electronic device 102 of FIGS. 3A-12 is the mobile device 102 described in FIGS. Rhythmic GNSS

[0044] FIG. 3 is a flow diagram 300 illustrating an enhanced mode technique according to one embodiment. Although a particular technique for acquiring historical positioning information is described, one skilled in the art will recognize that positioning information may be acquired in various ways, and the techniques described with respect to adjusting the lookback window may be implemented with any set of positions to protect user privacy. In some embodiments, the user explicitly selects the enhanced mode via a user interface on the electronic device 102. The mode change may be a relaxation from a higher power state with more accurate location monitoring (e.g., non-enhanced mode) to a lower power state with coarse location monitoring (e.g., enhanced mode) to extend battery life. Alternatively or additionally, in some embodiments, the electronic device 102 may rely on user context data to determine a selection of a mode that causes either an expansion or relaxation of power usage, including a duty cycle of requests for positioning information. The user context data is analyzed (302) to determine whether to initiate an enhanced location services session in the enhanced mode. The electronic device 102 analyzes the user context data to determine that a set of conditions are met for proactively acquiring positioning data in the enhanced mode. The set of conditions allows for the inference that the user is on an unfamiliar route and / or in the wilderness and the prediction that the user may need to retrace his steps with a backtrack route so that he can proactively obtain historical positioning information. A variety of data sources may be analyzed to determine the user context, including but not limited to sensor data, application data, frequently visited locations, trusted locations, known user routines, known locations of interest, detection of vehicle entry and / or exit (e.g., loss of Bluetooth connection to the vehicle). In one embodiment, the electronic device 102 selects the mode based on a condition met in the user context data, such as a time or an event indicating a time interval for capturing positioning information.For example, if a user is on the move for an extended period of time or if cell service is limited (e.g., weak, intermittent access, etc.), potentially indicating that the user is hiking, positioning information may be proactively captured to allow the user to retrace their steps.

[0045] In one embodiment, the one or more backtracking conditions may include, but are not limited to, a moving (e.g., not stationary) motion classification, a threshold period of time without network access, a sparse (e.g., not densely populated or density of manmade structures in the area, etc.) environment classification, and a threshold distance from frequently visited locations and / or locations that are part of the user routine. Although specific categories of conditions are provided, one skilled in the art will recognize that any other user context data may complement and / or form the basis of an inference that a user will require historical positioning information for backtracking.

[0046] The electronic device 102 initiates an enhanced location services session in an enhanced mode to duty cycle requests for positioning information (e.g., GNSS requests) to obtain intermittent position fixes and extend battery life (304). The electronic device 102's requests for positioning information may be intermittent to allow the AP to sleep between requests and / or process requests by other applications. As a further example, the electronic device 102 may collect positioning information every N minutes (e.g., every 2 minutes), and the duration for obtaining a position fix using GNSS may vary each time. Continuing with this example, the electronic device 102 may request positioning information every 2 minutes, and the duration for which the request for positioning information is serviced may depend on the operating state of the device.

[0047] Optionally, functionality provided by the electronic device 102 may be modified (306). In some embodiments, the functionality of applications and services (e.g., 130-180), sensors, processor usage, other hardware, and / or network access may be reduced. Services and applications accessible on the electronic device 102 may be assigned priorities, and provision of the services and applications on the electronic device 102 may be performed according to the assigned priorities, including initiating a duty cycle period (308). The electronic device 102 initiates a duty cycle period according to the priority assigned to obtaining positioning information (308). If a position fix is ​​available from another service (310), the position fix may be obtained from the other service (312). Alternatively, the electronic device determines whether to wake a processor (e.g., an AP or a radio processor) according to the priority assigned to obtaining positioning information (314). In some embodiments, the mode may determine a particular processor type for determining the positioning information, such as whether the positioning information request is performed on an AP, wireless controller, or a low power "always on" processor (AOP), or whether the device performs requests on the AP, wireless controller, or AOP intermittently at irregular intervals to conserve the device battery.

[0048] The electronic device 102 may conveniently collect positioning information when the AP is already executing instructions (e.g., for another application) (316). For example, if obtaining health information about the user, communication services, etc., takes priority over obtaining positioning information, obtaining positioning information may be performed in the background when the priority application is idle. Alternatively, the electronic device 102 may request to wake the AP for a positioning information request (318). The enhanced location services session may continue (320), and optionally, the functionality of the services and applications may be modified (306). The user context may continue to be analyzed in some embodiments (322) and (302). Alternatively, the process may end (324) until the user initiates an enhanced location services session.

[0049] FIG. 4 is a flow diagram 400 illustrating a backtracking technique according to one embodiment. The electronic device 102 detects 401 one or more backtrack conditions that trigger collection of a set of historical positions for a lookback time window. The one or more backtrack conditions are a set of conditions determined by analyzing user context data that allow for inference that the user may need to backtrack historical positioning data (e.g., in the wilderness and / or in an unfamiliar area). Based on the one or more backtrack conditions, the electronic device 102 predicts that the user may desire historical position information to allow for backtracking (e.g., retracing a route) in a navigation application and / or mapping application. In some embodiments, the one or more detected backtrack conditions are a subset of conditions that may be determined from analysis of accessible user context data as shown in FIG. 3 using the extended mode. Although a particular technique is described for collection of historical positions, the set of conditions for inferring that the user is missing prior to collection of historical positions, and the subsequent review of the conditions before responding to a request for historical positions, may be implemented with any implementation for collection of historical positions.

[0050] The user context data can supplement the backtracking conditions to provide a decision to initiate an extended mode and obtain positioning information. In one embodiment, the one or more backtracking conditions can include, but are not limited to, a moving motion classification (e.g., not stationary), a threshold period of no network access, a sparse environment classification (e.g., not densely populated or high density of manmade structures in an area, etc.), and exceeding a threshold distance from a frequently visited location and / or a location that is part of a user routine. Although specific categories of conditions are provided, one skilled in the art will recognize that any other user context data can supplement and / or form the basis of an inference that a user will require historical positioning information for backtracking.

[0051] The motion type classification condition is met if the electronic device 102 receives a motion classification that is not stationary and / or "moving". In one embodiment, the motion type classification condition is met if the mode of travel is human powered (e.g., walking, biking, skateboarding, etc.) or electric assisted vehicle (e.g., electric bicycle), and not a motorized vehicle or a motorized vehicle (e.g., car, airplane, electric car). The motion classifier 280, which is trained on a feature set from data acquired using the electronic device sensors, may provide information about whether the electronic device 102 is stationary or moving, including a moving mode. In some embodiments, the motion classification may indicate an inference of the user's activity or mode of travel while moving, including, but not limited to, walking, biking, exercise equipment, scooter, skateboard, in a vehicle, airplane, transit vehicle, train, subway, human powered vehicle, motor assisted vehicle, electric assisted vehicle, motorized vehicle, and / or any other motion classification.

[0052] The network access backtrack condition is met if the electronic device 102 is not within communication range of a wireless access point (e.g., Internet access, WiFi, cellular network access point, etc.) in the geographic area or if the geographic area has a relatively low access point density compared to a defined access point density threshold. The electronic device 120 may perform one or more wireless surveys to survey the geographic area for the presence of wireless access points, for example, while the device is moving over a period of time. For example, the electronic device 120 may continuously, periodically, or intermittently search for wireless signals transmitted using one or more frequency bands designated for wireless communication. If the observed number of access points is lower than the defined access point density threshold over the period of time, the network access backtrack condition is met.

[0053] The electronic device 102 uses a density classifier 282 to determine whether the type of environmental backtrack condition 102 is met based on the classification of the geographic area as having a sparse density of structures within the geographic area. The density classifier 282 trained on a feature set from data acquired using the electronic device sensor can provide information regarding whether the electronic device 102 is in a dense or sparse geographic area with respect to wireless access point density, radio frequency signal (e.g., Bluetooth, UWB, etc.) density information, and map data regarding density and landscape. In some embodiments, the density of wireless access points within an area is a feature provided in the classification of the density of structures within a geographic area. For example, if there are a large number of different wireless access points per area, the likelihood of a dense urban environment is high. As another example, the time span recorded during the observation of wireless access points can be a feature provided to the density classifier 282 and can act as an indicator of a sparse environment. In some embodiments, the map tile service can provide a tile-based mapping service to the electronic device 102 that enables the electronic device 102 to retrieve map data and metadata about a geographic region of the electronic device 102 or an area being searched by the electronic device 102. The map tile metadata can be retrieved from a remote map tile database or a local (e.g., cached) subset of the map tile database. The metadata can include a classification of the current map tile or subtile. The map tile metadata can also include digital elevation model (DEM) data that indicates a surface model including the structure of the estimated geographic region and can be a feature of the density classifier 282.

[0054] Next, if the electronic device 102 is beyond a threshold distance from a frequently visited location, a location that is part of a user routine, a safe location, or a trusted location, the met backtrack conditions can be analyzed to determine whether sufficient conditions are met to proceed to proactively obtain historical positioning information.

[0055] If sufficient backtracking conditions are met, the electronic device 102 receives at least one historical position from the set of historical positions during the lookback period 402. Although described with reference to classifying a single historical position, one skilled in the art will recognize that multiple historical positions may be classified to determine a lookback window of historical positions to include in the backtrack route.

[0056] The electronic device may classify (403) at least one historical position as a candidate position for a backtrack route based on one or more features (e.g., signals) observed during collection of the historical positions (e.g., duration of lookback window, no locations farther than 250 km, no previous locations in the vehicle, etc.). Features considered when classifying the historical positions include, but are not limited to, duration included in the lookback window, distance from a frequently visited, safe and / or trusted location, position information collected before and after entry of a motorized vehicle (e.g., automobile, airplane, etc.) and / or electric vehicle, structural density classification (e.g., urban, etc.), access point density, motion classification, transportation mode classification, user activity (e.g., hiking events from calendar data), and / or any other feature that may indicate that a user may need a backtrack route.

[0057] As an example, the most recent historical position considered as a lookback window candidate may not go back as far as a maximum duration from the current time. Similarly, historical positions that are greater than a maximum distance from the current position may be excluded from consideration as candidates for the lookback window. Position information acquired during flight and / or other movements within the vehicle may be truncated from the lookback window and considered not to be candidates for the lookback window. In some embodiments, historical positions that do not exceed a reliable threshold distance may be truncated from the lookback window unless the user requests a record of historical positions near frequently visited locations and / or safe reliable locations. Access point density and structural density classification indications where the user may be in an urban location may allow for truncation of lookback windows with associated positions. The described features are examples, and any number of described features may or may not be used by the backtrack classifier 278 to determine the lookback window.

[0058] The electronic device 102 determines whether to provide at least one historical position as part of the lookback window based on the classification (404). In one embodiment, the classification of the historical positions within the lookback window begins with a previously classified historical position within the lookback window, and classification continues until a current candidate is identified. Historical positions prior to the most recent classified candidate may be purged. By selectively providing historical locations when conditions suggest that a user is missing, bad actors are prevented from gaining access and / or causing exposure of previous locations for a user that may be contrary to the user's own interests.

[0059] In some embodiments, an application requesting access to a lookback window must possess an entitlement. The entitlement may identify the application as having a right or privilege to access the positioning information. When a user requests access to historical positioning information via an application, the lookback window positioning information may be conveniently provided, as opposed to requiring the user to require duplicate efforts to obtain historical positioning information.

[0060] 5 is a diagram 500 illustrating an extended mode approach according to one embodiment. After one or more conditions 508 indicating the need to initiate extended mode are detected within the user context data, positioning information requests 506 are performed intermittently within a duty period cycle 502, as shown. The lookback window is a period 504, as shown, with a set of historical positions (as shown in FIG. 5 with an "X" for each collected position) likely to be needed to allow the user to retrace their steps.

[0061] FIG. 6 is a flow diagram 800 for location services according to one embodiment. In some embodiments, location services may proactively obtain positioning information in anticipation of a user requesting access to historical positioning information for use with an application, such as a map application. Contextual user data may be analyzed to predict that a user may request historical positioning information (801). For example, analysis of the contextual user data may provide a prediction that positioning information about a recent route taken or traveled may be requested by a user to enable the user to retrace his or her route. In some embodiments, the contextual user data is analyzed to determine whether a user is likely to be lost and / or unable to access positioning information due to loss of service (e.g., cellular or wi-fi service). In another example, historical routine data and / or application data (e.g., calendar data) may be analyzed to determine whether recent positioning information for a user on the move is not part of the user's routine.

[0062] At least one indication of a user's intent to request access to historical positioning information may be received (802). Such user intent to request historical positioning data may be indicated by the electronic device 102 being designated as being in motion for a threshold duration and / or being on a route with reduced access to services (e.g., cellular service, power loss). Some activities or events indicated by contextual user data (e.g., application data) may act as predictors for needing access to historical positioning information and intent to potentially request historical positioning information, such as sensor data or application data indicating the user is exercising or walking. In another embodiment, analysis of user historical data may provide information regarding a routine route or path taken by the user, and the electronic device 102 may receive user context data indicating the user's intent to repeat the routine, such as exiting the vehicle at a parking lot near an amusement park, a hiking area, a ski slope, and / or any other remote location.

[0063] Upon receiving an indication of the location status of the user's intent to use an application that allows for retracing a route, periodic requests for positioning information may be performed according to the power capabilities of the device (803). Coarse-grained geofences may be established and defined locations (e.g., ski resorts, national park offices, etc.) may be found along the route to be detected to obtain the user's positioning information during travel. In some embodiments, the AOP may be used to perform requests for positioning information (e.g., GPS). Positioning information over time may be presented upon request by the user at the electronic device 102 (804).

[0064] A user may be prompted to opt-in to allow the electronic device to proactively obtain positioning information when user context data indicates that the user may need to retrace their route, and the positioning information may be deleted when wireless connectivity or access to services such as cellular service resumes.

[0065] FIG. 7 is a diagram 700 illustrating an extended mode approach according to one embodiment. After one or more conditions 508 indicating the need to initiate extended mode are detected in the user context data, positioning information requests 506 are executed intermittently within the duty period cycle 502 as shown. The lookback window is a period 504 having a set of historical positions likely to be needed in a backtrack route to allow the user to retrace steps, as shown. At 702, a maximum duration (e.g., 4 days) is provided within which the lookback window 504 may be defined. The backtrack classifier 278 classifies historical positions prior to 704 as not being candidates for the lookback window 504 because the user was stationary in a trusted location (home) and walked more than a threshold distance from home. The historical positions at 702 may be the last processed historical positions and may be the starting point for classification with the latest request for a lookback window. The lookback window 504 has been truncated, and 20 km of positioning information in a low access point density area while the user is walking is included in the backtrack route with the lookback window 504 shown.

[0066] 8 illustrates a user interface 800 for location services according to one embodiment. The user interface 104 of the electronic device 102 allows a user, via a user interface element 806, to configure a lookback window of historical positioning information (as shown at 804) by selecting "<App Name> " application 802 entitled "Lookback Window." Alternatively, the user may choose not to allow access to the lookback window via user interface element 808.

[0067] 9 illustrates a user interface 900 for location services according to one embodiment. The Compass location services application is shown along with an icon representing the location of the user's vehicle 904, waypoints 906, and the route taken by the user 902. The waypoints 906 and the position of the user's vehicle 904 can mark places of particular interest to the user and are shown relative to the user's current location.

[0068] FIG. 10 is a block diagram illustrating an exemplary API architecture that may be used in some embodiments of the present invention. As shown in FIG. 10, the API architecture 1000 includes an API implementation component 1010 (e.g., an operating system, library, device driver, API, application program, software, or other module) that implements an API 1020. The API 1020 specifies one or more functions, methods, classes, objects, protocols, data structures, formats, and / or other features of the API implementation component that may be used by an API calling component 1030. The API 1020 may specify at least one calling convention that specifies how a function of the API implementation component receives parameters from the API calling component and how the function returns results to the API calling component. The API calling component 1030 (e.g., an operating system, library, device driver, API, application program, software, or other module) executes API calls through the API 1020 to access and use the features of the API implementation component 1010 specified by the API 1020. The API implementation component 1010 may return a value through the API 1020 to the API calling component 1030 in response to the API call.

[0069] It will be understood that the API implementation component 1010 may include additional functions, methods, classes, data structures, and / or other features not specified through the API 1020 and not available to the API invocation component 1030. It should be understood that the API invocation component 1030 may be on the same system as the API implementation component 1010 or may be located remotely and the API implementation component 1010 may be accessed using the API 1020 over a network. Although FIG. 10 shows a single API invocation component 1030 interacting with the API 1020, it should be understood that other API invocation components, which may be written in a different language (or the same language) as the API invocation component 1030, may use the API 1020.

[0070] The API implementation component 1010, the API 1020, and the API invocation component 1030 can be stored on a machine-readable medium, which includes any mechanism for storing information in a form readable by a machine (e.g., a computer or other data processing system). For example, machine-readable media include magnetic disks, optical disks, random access memory, read-only memory, flash memory devices, and the like.

[0071] 11 is a block diagram of a device architecture 1100 for a mobile or embedded device, according to one embodiment. The device architecture 1100 includes a memory interface 1102, a processing system 1104 including one or more data processors, image processors, and / or graphics processing units, and a peripherals interface 1106. The various components may be coupled by one or more communication buses or signal lines. The various components may be separate logic components or devices, or may be integrated into one or more integrated circuits, such as a system on a chip integrated circuit.

[0072] The memory interface 1102 can be coupled to memory 1150, which can include high-speed random access memory, such as static random access memory (SRAM) or dynamic random access memory (DRAM), and / or non-volatile memory, such as, but not limited to, flash memory (e.g., NAND flash, NOR flash, etc.).

[0073] Sensors, devices, and subsystems can be coupled to the peripheral interface 1106 to facilitate multiple functions. For example, a motion sensor 1110, a light sensor 1112, and a proximity sensor 1114 can be coupled to the peripheral interface 1106 to facilitate mobile device functions. There may also be one or more biometric sensor(s) 1115, such as a fingerprint scanner for fingerprint authentication or an image sensor for face authentication. Other sensors 1116 can also be connected to the peripheral interface 1106, such as a positioning system (e.g., a GPS receiver), a temperature sensor, or other sensing devices, to facilitate related functions. In one embodiment, the positioning system can have a wireless processor that can solve navigation equations to determine the user's position, velocity, and / or time by processing the signal broadcast. A camera subsystem 1120 and an optical sensor 1122 (e.g., a charge-coupled device (CCD) or a complementary metal-oxide semiconductor (CMOS) optical sensor) can be utilized to facilitate camera functions such as recording pictures and video clips.

[0074] Communication functions may be facilitated via one or more wireless communication subsystems 1124, which may include radio frequency receivers and transmitters and / or optical (e.g., infrared) receivers and transmitters. The specific design and implementation of the wireless communication subsystem 1124 may depend on the communication network(s) in which the mobile device is intended to operate. For example, a mobile device including the illustrated device architecture 1100 may include a wireless communication subsystem 1124 designed to operate on a GSM network, a CDMA network, an LTE network, a Wi-Fi network, a Bluetooth network, or any other wireless network. In particular, the wireless communication subsystem 1124 may provide a communication mechanism by which a media playback application may retrieve resources from a remote media server or scheduled events from a remote calendar or event server.

[0075] The audio subsystem 1126 can be coupled to a speaker 1128 and a microphone 1130 to facilitate voice-enabled functions such as voice recognition, voice duplication, digital recording, and telephony functions. In the smart media devices described herein, the audio subsystem 1126 can be a high quality audio system that includes support for virtual surround sound.

[0076] The I / O subsystem 1140 may include a touchscreen controller 1142 and / or other input controller(s) 1145. In the case of a computing device that includes a display device, the touchscreen controller 1142 may be coupled to a touch-sensitive display system 1146 (e.g., a touchscreen). The touch-sensitive display system 1146 and the touchscreen controller 1142 may detect contact and movement and / or pressure using any of a number of touch and pressure sensing technologies, including, for example, but not limited to, capacitive, resistive, infrared, and surface acoustic wave technologies, as well as other proximity sensor arrays or other elements to determine one or more points of contact with the touch-sensitive display system 1146. Display output for the touch-sensitive display system 1146 may be generated by a display controller 1143. In one embodiment, the display controller 1143 may provide frame data to the touch-sensitive display system 1146 at a variable frame rate.

[0077] In one embodiment, a sensor controller 1144 is included to monitor, control, and / or process data received from one or more of the motion sensor 1110, the light sensor 1112, the proximity sensor 1114, or the other sensors 1116. The sensor controller 1144 can include logic to interpret the sensor data and determine the occurrence of one of a number of motion events or activities through analysis of the sensor data from the sensors.

[0078] In one embodiment, the I / O subsystem 1140 includes other input controller(s) 1145 that can be coupled to other input / control devices 1148 such as one or more buttons, rocker switches, thumb wheels, infrared ports, USB ports, and / or pointer devices such as a stylus, or control devices such as up / down buttons for volume control of the speaker 1128 and / or microphone 1130.

[0079] In one embodiment, memory 1150 coupled to memory interface 1102 can store instructions for operating system 1152, including Portable Operating System Interface (POSIX) compliant and non-compliant operating systems or embedded operating systems. Operating system 1152 can include instructions to handle basic system services and perform hardware-dependent tasks. In some implementations, operating system 1152 can be a kernel.

[0080] Memory 1150 may also store communication instructions 1154 to facilitate communication with one or more additional devices, one or more computers, and / or one or more servers, for example, to retrieve web resources from a remote web server. Memory 1150 may also include user interface instructions 1156, including graphical user interface instructions that facilitate processing of a graphical user interface.

[0081] In addition, the memory 1150 can store sensor processing instructions 1158 for facilitating sensor-related processes and functions, telephone instructions 1160 for facilitating telephone-related processes and functions, messaging instructions 1162 for facilitating electronic messaging-related processes and functions, web browser instructions 1164 for facilitating web browsing-related processes and functions, media processing instructions 1166 for facilitating media processing-related processes and functions, location services instructions including GPS and / or navigation instructions 1168 and Wi-Fi based location instructions for facilitating location-based functions, camera instructions 1170 for facilitating camera-related processes and functions, and / or other software instructions 1172 for facilitating other processes and functions, such as security processes and functions, and system-related processes and functions. The memory 1150 can also store other software instructions, such as web video instructions for facilitating web video-related processes and functions, and / or web shopping instructions for facilitating web shopping-related processes and functions. In some implementations, the media processing instructions 1166 are divided into audio processing instructions that facilitate audio processing related processes and functions and video processing instructions that facilitate video processing related processes and functions. A mobile device identifier, such as an International Mobile Equipment Identity (IMEI) 1174 or similar hardware identifier, may also be stored in the memory 1150.

[0082] Each of the instructions and applications identified above may correspond to a set of instructions that perform one or more of the functions described above. These instructions need not be implemented as separate software programs, procedures, or modules. Memory 1150 may include additional instructions or may include fewer instructions. Furthermore, various functions may be implemented in hardware and / or software, including one or more signal processing and / or application specific integrated circuits.

[0083] 12 is a block diagram of a computing system 1200 according to one embodiment. The computing system 1200 shown in the figure is intended to represent a variety of computing systems (wired or wireless) including, for example, one or more implementations of a desktop computer system, a laptop computer system, a tablet computer system, a cellular telephone, a personal digital assistant (PDA) including a cellular-enabled PDA, a set-top box, an entertainment system or other consumer electronic device, a smart home appliance device, or a smart media playback device. Alternative computing systems may include more, fewer, and / or different components. The computing system 1200 may be used to host a computing device and / or a server device to which a computing device may connect.

[0084] The computing system 1200 includes a bus 1235 or other communication device for communicating information, and a processor(s) 1210 coupled to the bus 1235 that may process information. Although the computing system 1200 is illustrated with a single processor, the computing system 1200 may include multiple processors, low power processors, and / or co-processors. The computing system 1200 may further include a memory 1220 in the form of a random access memory (RAM) or other dynamic storage device coupled to the bus 1235. The memory 1220 may store information and instructions that may be executed by the processor(s) 1210. In one embodiment, the memory 1420 may store instructions that may be executed by a low power processor 1415, such as an AOP. In one embodiment, the low power processor 1415 may be a component of a system on chip (SOC) that remains powered when the rest of the SOC is powered off. An implementation of the low power processor 1415 can be found in U.S. Patent Application Serial No. 11,079,261, which is incorporated herein by reference. The memory 1220 may also be a main memory used for storing temporary variables or other intermediate information during execution of instructions by the processor(s) 1210.

[0085] Computing system 1200 may also include a read only memory (ROM) 1230 and / or another data storage device 1240 coupled to bus 1235 that may store information and instructions for processor(s) 1210. Data storage device 1240 may be or include a variety of storage devices, such as a flash memory device, a magnetic disk, or an optical disk, and may be coupled to computing system 1200 via bus 1235 or via a remote peripheral interface.

[0086] Computing system 1200 may also be coupled to a display device 1250 via bus 1235 to display information to a user. Computing system 1200 may also include an alphanumeric input device 1260, including alphanumeric and other keys, that may be coupled to bus 1235 for communicating information and command selections to processor(s) 1210. Another type of user input device includes a cursor control device 1270, such as a touchpad, mouse, trackball, or cursor direction keys, to communicate directional information and command selections to processor(s) 1210 and control cursor movement on display device 1250. Computing system 1200 may also receive user input from remote devices communicatively coupled via one or more network interface(s) 1280.

[0087] The computing system 1200 may further include one or more network interface(s) 1280 to provide access to a network, such as a local area network. The network interface(s) 1280 may include, for example, a wireless network interface having an antenna 1285, which may represent one or more antennas (e). The computing system 1200 may include multiple wireless network interfaces, such as a combination of Wi-Fi, Bluetooth, near field communication (NFC), and / or cellular telephone interfaces. For example, the network interface(s) 1280 may also include a wired network interface for communicating with remote devices via a network cable 1287, which may be, for example, an Ethernet cable, a coaxial cable, a fiber optic cable, a serial cable, or a parallel cable.

[0088] In one embodiment, network interface(s) 1280 may provide access to a local area network, for example by conforming to the IEEE 802.11 wireless standard, and / or the wireless network interface may provide access to a personal area network, for example by conforming to the Bluetooth standard. Other wireless network interfaces and / or protocols may also be supported. In addition to or instead of communication via a wireless LAN standard, network interface(s) 1280 may provide wireless communication using, for example, a time division multiple access (TDMA) protocol, a Global System for Mobile Communications (GSM) protocol, a code division multiple access (CDMA) protocol, a long term evolution (LTE) protocol, and / or any other type of wireless communication protocol.

[0089] The computing system 1200 may further include one or more energy sources 1205 and one or more energy measurement systems 1245. The energy sources 1205 may include an AC / DC adapter coupled to an external power source, one or more batteries, one or more charging storage devices, a USB charger, or other energy source. The energy measurement system includes at least one voltage or amperage measurement device that can measure the energy consumed by the computing system 1200 during a given period of time. Additionally, the computing system may include one or more energy measurement systems that measure the energy consumed by, for example, a display device, a cooling subsystem, a Wi-Fi subsystem, or other frequently used or high energy consuming subsystems.

[0090] Various embodiments are described with reference to the figures. However, certain embodiments can be implemented without one or more of these specific details and in combination with other known methods and configurations. In the following description, numerous specific details are set forth, such as specific configurations, dimensions, and processes, to provide a thorough understanding of the embodiments. In other cases, well-known semiconductor processes and manufacturing techniques are not described in particular detail so as not to unnecessarily obscure the embodiments. Throughout this specification, references to "one embodiment" mean that a particular feature, structure, configuration, or characteristic described in connection with that embodiment is included in at least one embodiment. Thus, references to the phrase "in one embodiment" in various places throughout this specification are not necessarily referring to the same embodiment. Moreover, certain features, structures, configurations, or characteristics may be combined in any suitable manner in one or more embodiments.

[0091] Although the embodiments have been described in language specific to structural features and / or methodological acts, it should be understood that the appended claims are not necessarily limited to the specific features or acts described above. Rather, the specific features and acts disclosed should be understood as illustrative embodiments of the claims.

Claims

1. 1. A system for performing classification on an electronic device, comprising: one or more processors, the one or more processors comprising: Detecting one or more conditions in the user context data that trigger collection of a set of historical positions for a lookback window; receiving at least one historical position from the set of historical positions for the lookback window; classifying the at least one historical position as a candidate location for a backtrack route based on one or more characteristics; The system includes one or more processors that perform the operation of determining, based on the classification, to provide the at least one historical position as part of the lookback window.

2. The system of claim 1 , wherein the one or more conditions include at least one of an in-motion motion classification, a threshold period of time without network access, a sparse environment classification, or a threshold distance from a frequently visited location.

3. the one or more processors: receiving a request for the lookback window from an application; in response to the request, sorting through the set of historical positions within the lookback window from a last sorted historical position in the set to identify a most recent candidate historical position for beginning a backtrack route; and truncating historical positions in the set of historical positions prior to the most recent candidate position.

4. the one or more processors: The system of claim 3 , further comprising: deleting the truncated historical positions from the electronic device.

5. The system of claim 3 , wherein the application is entitled to request the lookback window.

6. the one or more processors:

2. The system of claim 1, further comprising: analyzing user context data to determine that a set of conditions for proactively acquiring positioning data is met in an expanded mode, the expanded mode including a duty cycled position information request to obtain intermittent position fixes.

7. The one or more features are 2. The system of claim 1, comprising at least one of a duration of the lookback window, a distance from a frequently visited or trusted location, a timing for obtaining the historical positioning information before and after entry of a motorized or electric vehicle, a structural density classification, an access point density, a movement classification, a transportation mode classification, or a user activity.

8. A non-transitory machine-readable medium storing instructions, the instructions configured to cause one or more processors to: Detecting one or more conditions in the user context data that trigger collection of a set of historical positions for a lookback window; receiving at least one historical position from the set of historical positions for the lookback window; classifying the at least one historical position as a candidate location for a backtrack route based on one or more characteristics; and determining, based on the classification, to provide the at least one historical position as part of the lookback window.

9. 10. The non-transitory machine-readable medium of claim 8, wherein the one or more conditions include at least one of an in-motion motion classification, a threshold period of time without network access, a sparse environment classification, or a threshold distance from a frequently visited location.

10. the one or more processors: receiving a request for the lookback window from an application; in response to the request, sorting through the set of historical positions within the lookback window from a last sorted historical position in the set to identify a most recent candidate historical position for beginning a backtrack route; and truncating historical positions in the set of historical positions prior to the most recent candidate position.

11. the one or more processors: The non-transitory machine-readable medium of claim 10 , further comprising: deleting the truncated history positions from the electronic device.

12. The non-transitory machine-readable medium of claim 10 , wherein the application is eligible to request the lookback window.

13. the one or more processors:

10. The non-transitory machine-readable medium of claim 8, further comprising: analyzing user context data to determine that a set of conditions for proactively acquiring positioning data is met in an enhanced mode, the enhanced mode including duty cycled position information requests to obtain intermittent position fixes.

14. The one or more features are 10. The non-transitory machine-readable medium of claim 8, comprising at least one of: a duration of the lookback window, a distance from a frequently visited or trusted location, a timing for obtaining the historical positioning information before and after entry of a motorized or electric vehicle, a structural density classification, an access point density, a movement classification, a transportation mode classification, or a user activity.

15. 1. A method comprising: Detecting one or more conditions in the user context data that trigger collection of a set of historical positions for a lookback window; receiving at least one historical position from the set of historical positions for the lookback window; classifying the at least one historical position as a candidate location for a backtrack route based on one or more characteristics; and determining, based on the classification, to provide the at least one historical position as part of the lookback window.

16. 16. The method of claim 15, wherein the one or more conditions include at least one of an in-motion motion classification, a threshold period of time without network access, a sparse environment classification, or a threshold distance from a frequently visited location.

17. receiving a request for the lookback window from an application; in response to the request, sorting through the set of historical positions within the lookback window from a last sorted historical position in the set to identify a most recent candidate historical position for beginning a backtrack route; truncating historical positions in the set of historical positions prior to the most recent candidate position; and The method of claim 15 further comprising:

18. the one or more processors:

20. The method of claim 17, further comprising performing operations including deleting the truncated historical positions from the electronic device.

19. The method of claim 17 , wherein the application is entitled to request the lookback window.

20. analyzing the user context data to determine that a set of conditions are satisfied for proactively acquiring positioning data in an enhanced mode, the enhanced mode including a duty cycled position information request to obtain intermittent position fixes; The method of claim 15 further comprising:

21. The one or more features are 16. The method of claim 15, comprising at least one of a duration of the lookback window, a distance from a frequently visited or trusted location, a timing for obtaining the historical positioning information before and after entry of a motorized or electric vehicle, a structural density classification, an access point density, a movement classification, a transportation mode classification, or a user activity.

Images