RELATED APPLICATIONS

[0001] This application claims the benefit of priority of U.S. Patent Application No. 18/304,104, filed April 20, 2023, U.S. Provisional Application No. 63/374,730, filed September 06, 2022, and U.S. Provisional Application No. 63/339,889, filed May 09, 2022, each of which is herein incorporated by reference.

FIELD

[0002] Embodiments described herein relate to provision of location services.

BACKGROUND INFORMATION

[0003] Current approaches to providing device applications with accurate positioning information require continuous requests for positioning information (e.g., 1Hz or every 1 second) by the device. Continuous requests for positioning information drain the device battery when performed for an extended period of time without an ability to recharge the battery of the device. As such, there is a need to provide location services with positioning information while preserving the life of the device battery.

SUMMARY

[0004] Methods, non-transitory machine-readable mediums, and system to provide location services are described. In an embodiment, a method provides receiving at least two position fixes for a trajectory of an electronic device, where the at least two position fixes are obtained intermittently, matching the at least two position fixes to points on a path indicated in map data, and computing a distance for the trajectory using distance information using the map data. [0005] In an embodiment, the method provides obtaining position fixes intermittently by determining whether to send a request for positioning information, determining whether positioning information received from another location services application is stale, sending a request for positioning information if the positioning information is stale, and obtaining the position fix from another location services application if the positioning information is not stale. In an embodiment, the method provides determining whether to send a request for positioning information by deferring a request for positioning information until an application processor is woken by another application executing on the electronic device. In an embodiment, the method provides obtaining position fixes intermittently by determining whether to send a request for positioning information, where the determining includes deferring a request for positioning information until a radio processor is woken by another application executing on the electronic device. In an embodiment, the method provides intermittently received position fixes are received at varying times within the N minute period. In an embodiment, the method provides where the intermittently received position fixes are continuously requested and received for varying durations of time during the duty cycling period. In an embodiment, the method provides where the map data is cached on the electronic device.

[0006] In an embodiment, the method provides receiving at least two position fixes for a trajectory of an electronic device, where the at least two position fixes are obtained intermittently, computing a straightness metric for the trajectory using heading information obtained from sensor data as the electronic device traveled between the at least two position fixes, training a machine learning model to compute a distance between position fixes using a plurality of features, where the plurality of features includes a straightness metric computation, and receiving a distance computation for the trajectory from the machine learning model using the straightness metric and the at least two position fixes. The method provides the plurality of features further comprises at least one of a distance calculated every N minutes, an absolute height change determined every N minutes, an absolute course change every N minutes, an accumulated step counts provided every N minutes, or a current speed determined every N minutes. In an embodiment, the method provides that the machine learning model uses a multiple regression algorithm. In an embodiment, the method provides the straightness metric is computed between the at least two position fixes using the sensor data by comparing a distance for a reconstructed path traveled between two position fixes to the distance between the at least two position fixes. In an embodiment, the method provides duty cycling of requests for positioning information to obtain intermittent position fixes. In an embodiment, the method provides the machine learning model reconstructs a path from user accessible data and estimates a distance for the path taken with the electronic device.

[0007] In an embodiment, a method provides analyzing user context data to determine a set of conditions are met for proactively obtaining positioning data in an extended mode, initiating the extended mode based on the analysis of user contextual data, where the extended mode comprises duty cycling position information requests to obtain intermittent position fixes, and performing at least one mitigation using the intermittently obtained position fixes to determine a trajectory and a distance traveled along the trajectory. In an embodiment, the method provides performing the at least one mitigation includes receiving at least two intermittently obtained position fixes for the trajectory of an electronic device, matching the at least two position fixes to points on a path indicated in map data to determine the trajectory, and computing the distance for the trajectory using distance information using the map data. In an embodiment, the method provides performing the at least one mitigation includes receiving at least two intermittently obtained position fixes for a trajectory of an electronic device, computing a straightness metric for the trajectory using heading information obtained from sensor data as the electronic device traveled between the at least two position fixes, training a machine learning model to compute a distance between position fixes using a plurality of features, where the plurality of features includes a straightness metric computation, and receiving a distance computation for the trajectory from the machine learning model using the straightness metric and at least two intermittently obtained position fixes. In an embodiment, the method provides the conditions include at least one of a motion classification, a comparison result between a time span of the electronic device without network access and a threshold period of time without network access, a sparse density environment classification, or a comparison result between a distance to a frequented location and a threshold distance from a frequented location. In an embodiment, the method provides obtaining position fixes intermittently includes determining whether to send a request for positioning information, where the determining includes determining whether positioning information received from another location services application is stale, sending a request for positioning information if the positioning information is stale, and obtaining the position fix from another location services application if the positioning information is not stale. In an embodiment, the method provides obtaining position fixes intermittently includes determining whether to send a request for positioning information, where the determining further includes deferring a request for positioning information until an application processor or a radio processor is woken by another application executing on the electronic device. In an embodiment, the method provides altering functionality of the electronic device, and prioritizing execution of services on the electronic device.

BRIEF DESCRIPTION OF THE DRAWINGS

[0008] FIG. 1 is a block diagram of a network operating environment for mobile devices, according to an embodiment.

[0009] FIG. 2 is a block diagram for location services according to an embodiment. [0010] FIG. 3A is a flow chart illustrating an extended mode approach according to an embodiment.

[0011] FIG. 3B is a diagram illustrating an extended mode approach according to an embodiment. [0012] FIG. 3C is a flow chart illustrating a map matching approach to determining a distance according to an embodiment.

[0013] FIG. 4A-C illustrates map matching techniques in accordance with an embodiment.

[0014] FIG. 5 is a flow chart illustrating a mitigation approach to determining a distance according to an embodiment.

[0015] FIG. 6A and 6B illustrate approaches for computing a distance in an embodiment.

[0016] FIG. 7 is a flow chart illustrating an approach to determining a distance according to an embodiment.

[0017] FIG. 8 is a flow chart for location services in accordance with an embodiment.

[0018] FIG. 9 depicts a user interface for location services in accordance with an embodiment.

[0019] FIG. 10 is a block diagram illustrating an exemplary API architecture, which may be used in some embodiments of the invention

[0020] FIG 11 is a block diagram of a device architecture for a mobile or embedded device, according to an embodiment.

[0021] FIG. 12 is a block diagram of a computing system, according to an embodiment.

DETAILED DESCRIPTION

[0022] Embodiments provided herein describe power saving modes for devices 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 request positioning information (e.g., GPS data) repeatedly over a period of time to provide a trajectory of travel for the device and/or a distance that the device has traveled over the period of time. In some embodiments, an extended power saving mode (extended mode) approach is described to extend a battery life of the device (e.g., smart watch, step tracking devices, location service devices, etc.) while executing the location services application and/or collecting positioning information for the location services application during an extended period of time when a user may not be able to recharge their device. The battery life is a length of time that the 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 locations of the device for a user on a hike, a run, participating in a marathon, on a camping trip, and/or any other activity may need to record positioning information using GNSS over an extended period of time without access to a method for recharging the battery and may need to alter functionality of the device to extend the life of the battery. In another example, positioning information may be collected to be able to provide location information if the user is lost or in an emergency situation and requires location information be accessible for the user and/or a provider of aid to the user after the extended period of time that the user is unable to recharge the device. In a non-extended mode, positioning information is obtained continuously at defined intervals of time (e.g., every second) that may drain the battery if positioning information is collected over a period of time that exceeds the battery life for the device available before it is necessary to recharge the device.

[0023] In an embodiment, an extended mode provides duty cycling GNSS requests for positioning information is performed to save power. Duty cycling is the fraction of a defined period of time in which a system is active. In extended mode, collection of positioning information may be requested every N minute period with intermittently received position fixes. Intermittently received position fixes may be requested and received at any time within the period such that the position fixes are received at irregular intervals of time. For example, the intermittently received position fixes are received at varying times within the N minute period and/or the position fixes are continuously requested and received for varying durations of time during the duty cycling period. The intermittent receipt of position fixes allows the application processor (AP) and/or a radio processor (e.g., GPS processor) to sleep in between requests and/or to handle requests by other applications. Some embodiments may turn off all other functionality of the device in extended mode to allow for collection of positioning information, health information, location services applications, and/or any other limited set of applications. [0024] When positioning information is collected intermittently (e.g., received at irregular intervals, not continuously or steadily, etc.) over time, mitigations are performed to provide an estimate for the trajectory taken by the user of the device and/or an estimate for the distance traveled with a collected set of position fixes. The user may not be traveling in a straight line between each position fix collected and mitigations are performed to provide an estimate for the actual trajectory and/or distance traveled by the user. In a first mitigation approach, map matching may be performed with the positioning information collected. Map matching involves taking the set of intermittent position fixes collected and matching the collected positions fixes to positions along on a path and/or a street defined in map data accessible to the device. However, map matching mitigation approaches are not always an option. In a second mitigation approach, sensor data (e.g., inertial data) is collected to determine if the user is walking in a straight path or taking a winding path while traveling with the device.

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

[0026] FIG. 1 is a block diagram of a network operating environment 100 for mobile devices, according to an embodiment. The network operating environment 100 includes electronic devices, such as mobile device 102. Mobile device 102 can be any electronic device capable of communicating over a wireless network and/or a wireless accessory device. Some examples of mobile devices 102 include, but are not limited to, the following: a smartphone, a tablet computer, a notebook computer, a wearable device (e.g., smartwatch or other wearable computing accessory), a mobile media player, a personal digital assistant, AirPods®, EarPods®, PowerBeats®, AirTag®, locator tags, headphones, head mounted display, health equipment, speakers, and other similar devices. In an embodiment, an accessory device may be paired with mobile device 102. By way of example, accessory devices may be devices such as Apple AirPods®, EarPods®, PowerBeats®, exercise equipment, vehicles, bicycles, scooters, smart televisions, Homepods, automated assistant devices, home security systems, and/or any other mobile accessory device.

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

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

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

[0030] Mobile device 102 may have applications, services, and functionality locally accessible on the devices including location services 180. Mobile devices 102 may offer one or more device locator applications 190 (e.g., a “Find my” application, a “Compass” application, a mapping application, etc.) to utilize device locator services 170 and location services 180 to locate accessory devices, provide a mapping application, and a navigation application. The navigation application (e.g., a “Compass” application) to aid the user in navigating and backtracking to historical positions on their route. The navigation application is an application that shows the cardinal directions used for navigation and geographic orientation using any number of methods including gyroscopes, magnetometers and/or positioning systems (e.g., GPS receivers). The mapping application is an application that uses maps delivered by a geographic information system (GIS).

[0031] Locally accessible data may be stored on defined locations, such as known locations 182 and safe, trusted locations 184. Machine learning algorithms 186 may be used to classify locations, infer relationships between a user and locations, provide path reconstruction and/or distance estimates in embodiments. In some embodiments, machine learning algorithms 186 may be used to provide an estimate for a distance with a set of features, including, but not limited to, intermittently received position fixes for a path and a straightness metric for a set of position fixes.

[0032] In some instances, machine learning algorithms 186 may be used to identify known locations 182, and/or trusted locations 184. By way of example, cluster data analysis may be used to identify, classify, and provide semantic labels for locations, such as locations frequented by a user. Safe, trusted locations 184 may be designated explicitly or confirmed as such by a user of the mobile device 102 after data analysis. In other instances, the known locations 182 or the trusted locations 184 may be classified offline and provided by device locator service 170 or a third-party (e.g., a database with map information). Although cluster analysis is provided as an example of machine learning algorithms that may be used, those with skill in the art will recognize that other algorithms may be used to identify potential known or trusted locations. [0033] On-device heuristics and/or machine learning models may be used to infer relationships between a user and locations based on analysis of the locally stored data on frequented locations including frequently visited locations by the user, known locations, and/or any other locations. For example, a frequently visited location such as a home, a vehicle, a workplace, any location frequented by a user with mobile device (e.g., accessory devices, and mobile device 102) and/or any other location designated as a trusted location 184 by the user. Known locations 182 may be business locations, public spaces, parks, museums, and/or any other location that may be frequented by a user.

[0034] Defined locations may have associated fence information that provides a set of conditions, if detected, allow for designating or classifying an electronic device relative to a region of physical space for at least a portion of the defined location. For example, fence information may provide the conditions for classifying the electronic device as either inside or outside a region of physical space associated with the defined location. In another example, fence information may provide the conditions for classifying the electronic device as transitioning between inside or outside the region of the defined location. Fence information may be a geofence with boundary information for the defined location, such as a point location and the extents of the region from the point location (e.g., a circular region defined with a radius from the point location, a polygon shape with distance measurements from the point location, etc.). Fence information may include a set of sensor measurements received by electronic devices (e.g., fingerprint data including radio frequency (RF) scan data, such as Wi-Fi scan traces, etc.) that are characteristic of a particular region of the defined location. Fence information for the respective defined locations may be stored along with classification type for the location and any semantic label assigned to the location. Boundary information may include a defined set of boundaries or a radius distance around a point location to allow for creation of a fence for the location. In some embodiments, the fence is a virtual perimeter for a real-world geographic area. 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 of 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 analysis of user contextual data to determine intent may factor into selection of the granularity of the fence established. In some embodiments, multiple fences may be used to refine positioning information determined by a coarse-grained geofence.

[0035] Machine learning algorithms 186 may include on-device heuristics, machine learning algorithms, or a combination thereof to analyze and assign a label regarding a user context, such as a location status. The location status may be a label for a user context (e.g., set of conditions, a motion classification) in which specific positioning techniques and resources of the electronic device are used to obtain positioning information. The location status may define a current location state and/or a prediction of a change in location state of a user while traveling with the electronic device. By proactively obtaining positioning information using techniques appropriate for the location status, latency is reduced in provision of the information for device applications without incurring a noticeable decline in performance of the electronic device that may be experienced with constant requests for positioning information. For example, the user context may indicate movement or travel of an electronic device to allow the electronic device to be designated as having a motion classification, such as “in transit”, “settled” in a particular defined location for a time period, or any other defined motion classification. Analysis may be performed using a variety of signals from contextual user data sources available to the mobile device 102, including, but not limited to, the following: sensor data, positioning data, calendar data, transit card usage data, application data, historical data on patterns/routines of travel, 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 an embodiment, the wireless connection status with various devices may indicate that the device is settled or “in transit.” For example, a loss of a connection to an appliance, a security system, a heating/cooling systems, vehicles, other modes of transport, and/or any other devices may indicate that the mobile device is “in transit”.

[0036] In some embodiments, a mobile device 102 may be classified with a “settled” semantic label after remaining within the geographic boundaries that define a location (e.g., the trusted location 184) for a defined time period. In an example, received positioning data for the mobile device 102 may indicate the electronic device 102 remained within the boundaries of a fence for a particular location for a duration of time (e.g., 5 minutes). Sensor data, such as accelerometer data, may indicate that the mobile device 102 is at rest to support an inference of being settled. Application data may support the inference that the mobile device 102 is settled, such as the mobile device being located at a calendar appointment location. Application data indicating a type of application in use may also provide an inference of the device being settled, such as using a media application. Historical data for the user on routines or patterns in travel may be used to determine whether the mobile device 102 is settled, such as a bedtime routine at a home or a hotel location.

[0037] Mobile device 102 may be classified as with an “in transit” label based on prior detected behavior, patterns, or routines for the user, and analyzed on mobile device 102. For example, the user may have routine of going to work around the same time every day and an “in transit” state may be assigned if the data on the device supports that the pattern is being repeated. A speed at which the mobile device is moving or entering and exiting known geographic areas (e.g., using fences) may allow for the inferring that the mobile device 102 is in transit. If the mobile device 102 is detected as accelerating in known areas of transit (e.g., on roads, highways, train routes, etc.), then the mobile device 102 may be given the motion classification of “in transit.” Similarly, if transit applications/cards are used/in use, then the mobile device 102 may be designated as “in transit”.

[0038] Mobile device 102 may be classified as a “threshold distance,” “near an entry,” “near an exit,” “entry” and/or “exit” of a set of locations or a particular location based on crossing fence boundaries for the respective location or set of locations and/or detecting a pattern of sensor values that are characteristic of being in a location, such as Wi-Fi scan results characteristic of being inside a location or transitioning into a location.

[0039] FIG. 2 is a block diagram for location services according to an embodiment. Location services 180 may include an event monitor module 264 (e.g., a fence event monitor, location status monitor, sensor monitor, etc.) that may aid in determining when power and performance modes should be adjusted for determining positioning information. Event monitor module 264 may rely on data from contextual user data sources to serve as cues for user context and event monitor module 264 may use heuristics and/or machine learning algorithms 186 to determine user contexts that trigger adjustment of modes. Event monitor module 264 may detect whether a user is entering a defined location and a location that location that is unfamiliar to the user. For example, mobile device 102 may be designated with an “in transit” state using a motion classifier 280 and wireless connection status data may indicate that a Bluetooth connection is lost between the mobile device 102 and an accessory device, such as a vehicle entertainment system. Continuing with the example, the events 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 location status and/or motion classification of the mobile device 102, such as the mobile device 102 may be “in transit to a defined location.” User contextual data, such as crossing fence boundaries, exiting a vehicle, exiting a transit station, user routines, sensor data, application data, etc., may be analyzed to predict that the electronic device is a threshold distance from a defined location and that the mode for electronic device should be adjusted.

[0040] In an embodiment, event monitor 264 may detect from user contextual data that the user is in a remote location (e.g., wilderness), on an unfamiliar route, and/or unlikely to charge their device for an extended period of time. For example, a variety of signals from user contextual data may indicate that the user will be unlikely to charge their device, such as application data indicating a user tracking a workout, a maps application with a hiking path selected for display, a loss of cellular service, and/or any other data accessible on the device that provides context for activities of a user that may allow for the inference that the user will not be able to recharge the electronic device 102. In another example, the user may select a mode that indicates the user will not be able to recharge the electronic device 102.

[0041] The visit monitor module 270 may utilize event monitor 264, fence information 290, and entry detection module 266 to accurately detect entry to a defined location and reduce latency for provision of positioning information by predicting the user will request the positioning data. The visit monitor module 270 may retrieve fence information 290 to define a more precise boundary for a defined location when the electronic device 102 is detected crossing a more coarse-grained geofence boundary, as detected using the entry detection module 266. In another embodiment, the visit monitor module 270 may retrieve expected sensor data (e.g., fingerprint data) characteristic of an electronic device 102 with the location status.

[0042] The proactive services 268 may be used to predict what applications and/or services that the user may want to access with a given user context, motion classification, and/or location status. For example, the user may want to access a particular application just prior to or upon entry to a location. Proactive services 268 may select applications based on user history of application selection or suggest a new application associated with a particular defined location. [0043] In an embodiment, the electronic device 102 (with the event monitor 264) may detect a set of conditions that allow for an inference that user may request a backtrack route to allow for retracing their steps and the electronic device 102 may initiate an extended power saving mode to obtain the positioning information so as not to affect the performance of the electronic device 102. In an embodiment, proactive service 268 may adjust a rate for periodic requests for determining positioning information. To handle intermittent receipt of positioning information, a machine learning model 240 may be used to reconstruct a path from user accessible data and estimate a distance for the path taken by the user. [0044] In some embodiments, map data accessed by a mapping application 250 is used to estimate distances. The mapping application is an application that uses maps delivered by a geographic information system (GIS). The navigation application 220 may provide heading or direction (e.g., degrees from magnetic north) information for the mobile device 102 that is collected as the user is traveling, and the heading data is averaged to eliminate errors in heading information collected due to variations in heading measurements collected due to movement of the device (e.g., jostling of device, swinging of hand if device worn on wrist of user, etc.) as the user travels along their trajectory.

[0045] Proactive services 268 and event monitor 264 may use a motion classifier 280 and a backtrack classifier 278. A motion classifier 280 that has been trained on a feature set from data obtained using electronic device sensors may provide information on whether electronic device 102 is stationary or in transit with a user. While embodiments are not limited to a specific sensor type, specific sensor data representations, or specific features, exemplary sensors, and features are described herein that are capable of distinguishing between specific movements within the sensor data. The motion classifier can analyze provided features from sensor data using one or more models that are trained to perform identification of motion type based on the supplied features. In some implementations, the electronic device can receive motion classification from the electronic device or from a server indicating that the mobile device is traveling in a particular mode of transport. The backtrack classifier classifies obtained historical positions for the mobile device 102 as potentially part of a backtrack route for a user of the electronic device

[0046] In some embodiments, the electronic device 102 in FIGS. 3A-12 is a mobile device 102 as described with FIGS. 1-2.

Rhythmic GNSS

[0047] FIG. 3A is a flow chart 300 illustrating an extended mode approach according to an embodiment. In some embodiments, a user explicitly selects an extended mode via a user interface on the electronic device 102. The mode change may be a de-escalation from higher power state with more precise location monitoring (e.g., non-extended mode) to a low power state with coarse location monitoring (e.g., extended mode) to extend the life of the battery. Alternatively, or additionally, the electronic device 102 may rely on user contextual data to determine selection of a mode that causes either escalation or de-escalation of power usage including duty cycling of requests for positioning information in some embodiments. User contextual data is analyzed to determine whether to begin an extended location services session in the extended mode (302). The electronic device 102 analyzes user context data to determine a set of conditions are met for proactively obtaining positioning data in the extended mode. The set of conditions allow for an inference that a user is on a route that is unfamiliar and/or in the wilderness and a prediction that a user may need to be able to retrace their steps with a backtrack route and proactively obtain the historical positioning information. A variety of data sources may be analyzed to determine user context, including, but not limited to, the following: sensor data, application data, known user routines, known locations of interest, detection of entry and/or exit of a vehicle (e.g., loss of Bluetooth connection to vehicle). In an embodiment, the electronic device 102 selects a mode based on conditions met in user contextual data, such as time or events, that indicate time intervals for capturing positioning information. For example, if a user is in transit for a long period of time or cell service is limited (e.g., weak, intermittent access, etc.) potentially indicating a user is on a hike, then positioning information may proactively be captured to allow a user to retrace their steps.

[0048] In an embodiment, the one or more backtrack conditions may include, but are not limited to, the following: in transit (e.g., not stationary) motion classification, threshold period of time without network access, sparse (e.g., not densely populated or density of manmade structures in the area, etc.) environment classification, and threshold distance from a frequented location and/or location that is part of a user routine. While specific categories of conditions are provided, those with skill in the art will recognize that any other user contextual data may supplement and/or form the basis of an inference that the user will request historical positioning information for backtracking.

[0049] Electronic device 102 initiates an extended location services session in the extended mode to perform duty cycling of requests for positioning information (e.g., GNSS requests) to obtain intermittent position fixes and extend the battery life (304). Electronic device 102 requests for positioning information may be intermittent to allow the AP to sleep in between requests and/or to handle requests by other applications. By way of further example, electronic device 102 may collect positioning information every N minutes (e.g., every 2 minutes) and the duration of time for obtaining a position fix using GNSS may vary each time. Continuing with the example, electronic device 102 may request positioning information every two minutes and the duration of time that the request for positioning information is serviced may depend on operating conditions of the device.

[0050] Optionally, the functionality offered by the electronic device 102 may be altered (306).

In some embodiments, 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 a priority and the provision of services and applications on the electronic device 102 may execute in accordance with the assigned priority (308), including initiating the duty cycling period. The electronic device 102 initiates the duty cycling period (308) in accordance with the priority assigned to obtaining positioning information. If a position fix is available from other services (310), then the position fix may be obtained from the other service (312). Alternatively, the electronic device determines whether to wake the processor (e.g., AP and/or radio controller) in accordance with the priority assigned to obtaining positioning information (314). In some embodiments, the mode may determine a particular processor type for determining positioning information, such as whether positioning information requests are executed on an AP, a radio controller, or a low power “always on” processor (AOP), or whether the device executes requests on the AP, the radio controller, or the AOP intermittently with irregular time intervals to preserve the device battery.

[0051] The electronic device 102 may collect positioning information opportunistically when the AP is already executing instructions (e.g., for another application) (316). For example, if obtaining health information for the user, communication services, etc. is prioritized over obtaining positioning information, then 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 positioning information requests (318). Mitigations are performed to provide estimates for a trajectory as described in FIG. 3C and FIG 5 (320). The extended locations services session may continue (322) and optionally, alter functionality of services and applications (306). User context may continue to be analyzed in some embodiments (324) and (302). Alternatively, the process may end until the user initiates an extended location services session (326).

[0052] FIG. 3B is a diagram 311 illustrating an extended mode approach according to an embodiment. After one or more conditions 317 are detected within user contextual data indicating the need to begin the extended mode, positioning information requests 315 are performed intermittently within a duty period cycle 313, as shown. A lookback window is a period of time 319, as illustrated, with a set of historical positions that are likely to be needed in order to allow a user to retrace their steps.

Map Matching Approach

[0053] FIG. 3C is a flow chart 301 illustrating a map matching approach to determining a distance according to an embodiment. Electronic device 102 obtains position fixes intermittently with duty cycling as described in FIG. 3A (303). In some embodiments, a user explicitly selects an extended mode via a user interface on the electronic device 102. Alternatively, the electronic device 102 may rely on user contextual data to determine selection of a mode that causes either escalation or de-escalation of power usage including duty cycling of requests for positioning information. A variety of data sources may be analyzed to determine user context, including, but not limited to, the following: sensor data, application data, known user routines, known locations of interest, detection of entry and/or exit of a vehicle (e.g., loss of Bluetooth connection to vehicle). In an embodiment, the electronic device 102 selects a mode based on user contextual data, such as time or events, that indicate time intervals for capturing positioning information. For example, if a user is in transit for a long period of time or cell service is limited (e.g., weak, intermittent access, etc.) potentially indicating a user is on a hike, then positioning information may proactively be captured to allow a user to retrace their steps. In some embodiments, the mode may determine a particular processor type for determining positioning information, such as whether positioning information requests are executed on an AP or a low power “always on” processor (AOP), or whether the device executes requests on the AP or AOP intermittently with irregular time intervals to preserve the device battery. In another embodiment, the mode change may be a de-escalation from higher power state with more precise location monitoring (e.g., non-extended mode) to a low power state with coarse location monitoring (e.g., extended mode) to extend the life of the battery.

[0054] Optionally, electronic device 102 performs duty cycling of requests for positioning information (e.g., GNSS requests) to extend the battery life in an extended mode. Electronic device 102 requests for positioning information may be intermittent to allow the AP to sleep in between requests and/or to handle requests by other applications. By way of further example, electronic device 102 may collect positioning information every N minutes (e.g., every 2 minutes) and the duration of time for obtaining a position fix using GNSS may vary each time. Continuing with the example, electronic device 102 may request positioning information every two minutes and the duration of time that the request for positioning information is serviced may depend on operating conditions of the device. The electronic device may collect positioning information opportunistically when the AP is already executing instructions (e.g., for another application) and/or the electronic device 102 may request to wake the AP for positioning information requests.

[0055] The electronic device 102 receives at least two position fixes for a trajectory (305). Although examples are provided with two position fixes, those with skill in the art will recognize that a plurality of position fixes may be collected over the extended period of time. For example, the collection of positioning information may coincide with the use of the application processor for other applications such that the request for positioning information does not cause the application processor to wake up. In some instances, the location information may be collected from other applications executing on the device that request location information, if the location information is not stale. For example, if a mapping application is executing on the device, then when a request for location information is received for the location services application, then the location information acquired by the mapping application may satisfy the request for positioning information. A threshold period of time after receipt of the location information may determine whether the location information is stale. In some embodiments, collection of location information may be prioritized such that other functionality of the device may be turned off to allow for positioning information to be collected.

[0056] When positioning information is collected intermittently (e.g., collected at irregular intervals, not continuously or steadily, etc.) over time, mitigations are performed to provide an estimate for the trajectory taken by the user of the device and/or an estimate for the distance traveled with a collected set of position fixes. The user may not be traveling in a straight line between each position fix collected and mitigations are performed to provide an estimate for the actual trajectory and/or distance traveled by the user.

[0057] The electronic device 102 performs matching of the at least two position fixes to points on a path indicated in the map data (307). Map matching involves taking the set of intermittent position fixes collected and matching the collected positions fixes to positions along on a path and/or a street defined in map data accessible to the device. In some embodiments, a map tile service can provide a tile-based mapping service to the electronic devices 102 that enables the electronic device 102 to retrieve map data and metadata for a geographic region of the electronic device 102 or a region that is being searched by the mobile 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 sub-tile. The map tile metadata can also include digital elevation model (DEM) data that indicates an elevation for the estimated geographic location. If an altitude can be determined by the electronic device 102 based on map data or GPS data, the altitude information may be used in calculating the distance for the trajectory.

[0058] The electronic device computes the distance for the trajectory using distance information from the map data (309). To compute the distance between each of the collected position fixes, the distance provided between positions on the path in the map data that closely matches the collected position fixes may be used instead of straight-line computations between the position fixes collected along the user’s trajectory with electronic device 102. For example, two collected position fixes may be matched (e.g., “snapped”) to positions along a path in the map data. Continuing with the example, the distance between the two collected position fixes may be determined using the map data for the trajectory along the path in the map data as opposed to calculating a distance between the two collected position fixes. The altitude information may be used to calculate the distance by accounting for the terrain that the user took on their trajectory. Various algorithms may be used to determine the shortest distance between the two position fixes along the path matched in the map data.

[0059] In some embodiments, the mode selection may have an impact on the performance of the electronic device due to the selection of technique used to determine positioning information. For example, global positioning systems (GPS) techniques may be used when analysis of the contextual user data indicates that the user may need greater precision in positioning data and the use of a particular GPS technique over other techniques may impact performance of other applications on the electronic device. The mode selected may rely on various techniques and sources to determine positioning information, such as use of a cell tower, motion sensors, Wi-Fi scans, GPS, etc..

[0060] FIG. 4A-C illustrates map matching techniques in accordance with an embodiment. In FIG. 4 A, block diagram 400 illustrates position fixes 403 that are collected at every 100 seconds and the position fixes are snapped to a path found in maps data. As shown in FIG. 4B, block diagram 401 illustrates a path constructed with map data. In FIG. 4C, block diagram 402 illustrates a path 405 of points from which a distance can be calculated with extrapolated points along the path 405.

Straightness Metric and Machine Learning Model Approach

[0061] FIG. 5 is a flow chart 500 illustrating a mitigation approach to determining a distance according to an embodiment. Electronic device 102 obtains position fixes intermittently with duty cycling as described in FIG. 3A (501). Initially, the electronic device 102 receives at least two position fixes for a trajectory of (502). Duty cycling of requests for positioning information (e.g., GNSS requests) is performed to save power. Duty cycling is the fraction of a defined period of time in which a system is active. For example, collection of positioning information may be requested intermittently to allow the application processor to sleep in between requests and/or to handle requests by other applications.

[0062] A straightness metric is computed for the trajectory using electronic device 102 heading information obtained from sensor data as the electronic device 102 travels between the at least two position fixes (503). The straightness metric is used to correct a straight-line estimate of distance between position fix endpoints. Heading or direction (e.g., degrees from magnetic north) information for the electronic device 102 is collected as the user is traveling, and the heading data is averaged to eliminate errors in heading information collected due to variations in heading measurements collected due to movement of the device (e.g., jostling of device, swinging of hand if device worn on wrist of user, etc.) as the user travels along their trajectory. The heading information collected as the user is traveling between each position fix is used to reconstruct the path between each position fix collected. A straightness metric is computed, for example, between two position fixes (e.g., endpoints) using the sensor data by comparing a distance for the reconstructed path traveled between two position fixes (e.g., endpoints) to the distance between the two position fixes. In an embodiment, the straightness metric is a number between 0 and 1, with 1 representing a straight line. The straightness metric is calculated for endpoints (e.g., position fixes collected), as follows:

Straightness = dendpoints / 2 d _£ where dendpoints is the distance between endpoints and S d _£ is the sum of distances between endpoints in a reconstructed path between each endpoint computed using heading data and assuming the user is traveling at a constant speed.

[0063] The electronic device 102 requests a computation of a distance between position fixes from the path reconstruction machine learning model 240 (504). The path reconstruction machine learning model 240 is trained to compute a distance between position fixes. The electronic device 102 may submit a plurality of features as input, including the straightness metric computation, to the path reconstruction machine learning model 240. The straightness metric is used as input along with other features to the path reconstruction machine learning model 240 to determine the distance between collected position fixes along the user’s trajectory with the electronic device 102. Other features that may, optionally, be provided as inputs to the path reconstruction machine learning model 240. include, but are not limited to, the following: intermittent distance (e.g., 3D distance determined every two minutes), height change (e.g., absolute height change every two minutes), course change (e.g., absolute course change every two minutes), step counts (e.g., accumulated step counts every two minutes), and/or speed changed (e.g., current speed and speed change between two minutes). The path reconstruction machine learning model 240 may be trained to estimate the distance with the set of features. The path reconstruction machine learning model 240 can be implemented using, for example, a convolutional neural network (CNN) or a recurrent neural network (RNN), including a long short-term memory (LSTM) variant of an RNN. Other types of machine learning models and/or neural networks can be used. In another embodiment, the path reconstruction machine learning model 240 may be implemented using multiple regression algorithms. Multiple regression is a machine learning algorithm to predict dependent variable with two or more predictors. The electronic device 102 receives a distance computation for the trajectory from the path reconstruction machine learning model 240 using the straightness metric and the machine learning model (505).

[0064] FIG. 6A and 6B illustrate approaches for computing a distance in an embodiment. Fig. 6A 600 illustrates computation of a straightness metric with a comparison of distance between endpoints dendpoints and paths traveled di and d2. FIG. 6B illustrates examples of straightness metrics for illustrated paths of distances taken by the user 602, 604, and 606 between endpoints. As illustrated, a straight line path 602 between two endpoints produces a straightness metric of 1. Path 606 illustrate a path with a switch-back with a straightness metric of .22 whereas path 604 has a straightness metric of .9 with a windy path.

[0065] FIG. 7 is a flow chart 700 illustrating an approach to determining a distance according to an embodiment. Initially, the electronic device 102 receives an indication for a location services session 102 (702). The indication may be directly as a user selection to begin the location session, such as selection of tracking a workout. In another embodiment, the location services session may begin to proactively obtain positioning information in anticipation of the user needing historical positioning information.

[0066] Next, if the location services will not be an extended session (704), then the electronic device sends periodic positioning requests at constant time intervals (716). In an embodiment, the electronic device 102 sends positioning information requests every second. An odometer (718) relying on positioning information may be used to determine the distance that the user has traveled with the electronic device 102. Alternatively, if there is an indication that the location service session will be an extended session with no ability to recharge the electronic device 102 battery (704), then the electronic device 102 begins duty cycling in the extended mode with intermittent positioning requests (706). If map data is accessible (708), then the electronic device 102 map matching may be used to calculate a distance as shown in FIG. 3. Alternatively, the electronic device 102 calculates a straightness metric using the position fixes and inputs the straightness metric to the trained the path reconstruction machine learning model 240 as shown in FIG. 5 (710). Optionally, a pedometer may be used to perfect the distance estimate (720). A pedometer, or step-counter, application the electronic device 102 that counts each step a person takes by detecting the motion of the person's hands. In some embodiments, the pedometer is used to calculate the distance for the user’s trajectory instead of distance calculated using positioning information.

[0067] FIG. 8 is a flow chart 800 for location services in accordance with an embodiment. In some embodiments, location services may proactively obtain positioning information in anticipation of the user requesting access to the historical positioning information for use with an application, such as a map application. Contextual user data may be analyzed to predict that the user may request historical positioning information (801). For example, analysis of contextual user data may provide a prediction that positioning information for the most recent path or transit route taken may be requested by the user to allow the user to retrace their path. In some embodiments, contextual user data is analyzed to determine if the user is likely to get lost and/or not have access to positioning information due to loss of services (e.g., cellular or wifi services). In another example, historical routine data and/or application data (e.g., calendar data) may be analyzed to determine if the most recent positioning information for the user in transit is not part of the user’s routine.

[0068] At least one indication of the intention of the user to request access to the historical positioning information may be received (802). The intention of the user to request such historical positioning data may be indicated by the electronic device 102 designated as in transit for a threshold duration and/or on a path with reduced access to services (e.g., cellular service, losing power). Certain activities or events indicated by contextual user data (e.g., application data) may serve as a predictor for needing access to historical positioning information and an intention to potentially request historical positioning information, such as sensor data or application data that indicates the user is exercising or walking. In another embodiment, analysis of user historical data may provide information on a routine transit route or path taken by the user, and the electronic device 102 may receive user contextual data that indicates the intention of the user to repeat the routine, such as exiting a vehicle at a parking lot near a recreational park, a hiking area, a ski area, and/or any other remote location.

[0069] Upon receiving an indication of the location status of a user intent to use an application that allows for retracing a path, periodic requests for positioning information in accordance with the power capabilities of the device may be performed (803). Coarse-grained geofences may be established where defined locations (e.g., ski chalets, national park offices, etc.) are found along the path to detect to obtain the positioning information of the user while in transit. In some embodiments, the AOP may be used to execute requests for positioning information (e.g., GPS). The positioning information over time may be presented upon request by the user at the electronic device 102 (804).

[0070] The user may be prompted to opt-in to allow the electronic device to proactively obtain positioning information when user contextual data indicates that the user may need to retrace their path, and the positioning information may be deleted when access to services, such as wireless connectivity or cellular service, have resumed.

[0071] FIG. 9 depicts a user interface 900 for location services in accordance with an embodiment. A navigation application 220 is depicted with an icon representing the location of a user’s vehicle 904, waypoints 906 and a path 902 that a user has taken. The waypoint 906 and user vehicle 904 position may mark a place of special interest to the user and are depicted with an icon or marker as a relative position to a user’s current location.

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

[0073] It will be appreciated that the API-implementing component 1010 may include additional functions, methods, classes, data structures, and/or other features that are not specified through the API 1020 and are not available to the API-calling component 1030. It should be understood that the API-calling component 1030 may be on the same system as the API-implementing component 1010 or may be located remotely and accesses the API- implementing component 1010 using the API 1020 over a network. While Fig. 10 illustrates a single API-calling component 1030 interacting with the API 1020, it should be understood that other API-calling components, which may be written in different languages (or the same language) than the API-calling component 1030, may use the API 1020. [0074] The API-implementing component 1010, the API 1020, and the API-calling component 1030 may be stored in 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, a machine-readable medium includes magnetic disks, optical disks, random-access memory; read only memory, flash memory devices, etc.

[0075] FIG. 11 is a block diagram of a device architecture 1100 for a mobile or embedded device, according to an 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 can be coupled by one or more communication buses or signal lines. The various components can be separate logical components or devices or can be integrated in one or more integrated circuits, such as in a system on a chip integrated circuit.

[0076] The memory interface 1102 can be coupled to memory 1150, which can include highspeed 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.).

[0077] Sensors, devices, and subsystems can be coupled to the peripherals interface 1106 to facilitate multiple functionalities. For example, a motion sensor 1110, a light sensor 1112, and a proximity sensor 1114 can be coupled to the peripherals interface 1106 to facilitate the mobile device functionality. One or more biometric sensor(s) 1115 may also be present, such as a fingerprint scanner for fingerprint recognition or an image sensor for facial recognition. Other sensors 1116 can also be connected to the peripherals interface 1106, such as a positioning system (e.g., GPS receiver), a temperature sensor, or other sensing device, to facilitate related functionalities. In an embodiment, the positioning system may have a radio processor capable of solving navigation equations to determine user position, velocity, and/or time by processing the signals broadcast. A camera subsystem 1120 and an optical sensor 1122, 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. [0078] Communication functions can be facilitated through one or more wireless communication subsystems 1124, which can include radio frequency receivers and transmitters and/or optical (e.g., infrared) receivers and transmitters. The specific design and implementation of the wireless communication subsystems 1124 can depend on the communication network(s) over which a mobile device is intended to operate. For example, a mobile device including the illustrated device architecture 1100 can include wireless communication subsystems 1124 designed to operate over 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 subsystems 1124 can provide a communications mechanism over which a media playback application can retrieve resources from a remote media server or scheduled events from a remote calendar or event server.

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

[0080] The VO subsystem 1140 can include a touch screen controller 1142 and/or other input controlled s) 1145. For computing devices including a display device, the touch screen controller 1142 can be coupled to a touch sensitive display system 1146 (e.g., touch-screen). The touch sensitive display system 1146 and touch screen controller 1142 can, for example, detect contact and movement and/or pressure using any of a plurality of touch and pressure sensing 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 a touch sensitive display system 1146. Display output for the touch sensitive display system 1146 can be generated by a display controller 1143. In one embodiment, the display controller 1143 can provide frame data to the touch sensitive display system 1146 at a variable frame rate.

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

[0082] 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-wheel, infrared port, USB port, and/or a pointer device such as a stylus, or control devices such as an up/down button for volume control of the speaker 1128 and/or the microphone 1130.

[0083] In one embodiment, the memory 1150 coupled to the memory interface 1102 can store instructions for an operating system 1152, including portable operating system interface (POSIX) compliant and non-compliant operating system or an embedded operating system. The operating system 1152 may include instructions for handling basic system services and for performing hardware dependent tasks. In some implementations, the operating system 1152 can be a kernel.

[0084] The memory 1150 can also store communication instructions 1154 to facilitate communicating with one or more additional devices, one or more computers and/or one or more servers, for example, to retrieve web resources from remote web servers. The memory 1150 can also include user interface instructions 1156, including graphical user interface instructions to facilitate graphic user interface processing.

[0085] Additionally, the memory 1150 can store sensor processing instructions 1158 to facilitate sensor-related processing and functions; telephony instructions 1160 to facilitate telephone- related processes and functions; messaging instructions 1162 to facilitate electronic-messaging related processes and functions; web browser instructions 1164 to facilitate web browsing- related processes and functions; media processing instructions 1166 to facilitate media processing-related processes and functions; location services instructions including GPS and/or navigation instructions 1168 and Wi-Fi based location instructions to facilitate location based functionality; camera instructions 1170 to facilitate camera-related processes and functions; and/or other software instructions 1172 to facilitate other processes and functions, e.g., security processes and functions, and processes and functions related to the systems. The memory 1150 may also store other software instructions such as web video instructions to facilitate web videorelated processes and functions; and/or web shopping instructions to facilitate web shopping- related processes and functions. In some implementations, the media processing instructions 1166 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. A mobile equipment identifier, such as an International Mobile Equipment Identity (IMEI) 1174 or a similar hardware identifier can also be stored in memory 1150.

[0086] 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. The memory 1150 can include additional instructions or fewer instructions. Furthermore, various functions may be implemented in hardware and/or in software, including in one or more signal processing and/or application specific integrated circuits.

[0087] FIG. 12 is a block diagram of a computing system 1200, according to an embodiment. The illustrated computing system 1200 is intended to represent a range of computing systems (either wired or wireless) including, for example, desktop computer systems, laptop computer systems, tablet computer systems, cellular telephones, personal digital assistants (PDAs) including cellular-enabled PDAs, set top boxes, entertainment systems or other consumer electronic devices, smart appliance devices, or one or more implementations of a smart media playback device. Alternative computing systems may include more, fewer and/or different components. The computing system 1200 can be used to provide the computing device and/or a server device to which the computing device may connect.

[0088] The computing system 1200 includes bus 1235 or other communication device to communicate information, and processor(s) 1210 coupled to bus 1235 that may process information. While the computing system 1200 is illustrated with a single processor, the computing system 1200 may include multiple processors, low power processors, and/or coprocessors. The computing system 1200 further may include memory 1220 in the form of 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 processor(s) 1210. In an embodiment, the memory 1420 may store instructions that may be executed by a low power processor 1415, such as the AOP. In an embodiment, the low power processor 1415 may be a component of a system on a chip (SOC) that remains powered when the remainder of the SOC is powered off. Implementations of the low power processor 1415 may be found in U.S. Patent Application No. 11,079,261, which is herein incorporated by reference. The memory 1220 may also be main memory that is used to store temporary variables or other intermediate information during execution of instructions by the processor(s) 1210.

[0089] The computing system 1200 may also include read only memory (ROM) 1230 and/or another data storage device 1240 coupled to the bus 1235 that may store information and instructions for the processor(s) 1210. The data storage device 1240 can be or include a variety of storage devices, such as a flash memory device, a magnetic disk, or an optical disc and may be coupled to computing system 1200 via the bus 1235 or via a remote peripheral interface. [0090] The computing system 1200 may also be coupled, via the bus 1235, to a display device 1250 to display information to a user. The computing system 1200 can also include an alphanumeric input device 1260, including alphanumeric and other keys, which may be coupled to bus 1235 to communicate information and command selections to processor(s) 1210.

Another type of user input device includes a cursor control 1270 device, such as a touchpad, a mouse, a trackball, or cursor direction keys to communicate direction information and command selections to processor(s) 1210 and to control cursor movement on the display device 1250. The computing system 1200 may also receive user input from a remote device that is communicatively coupled via one or more network interface(s) 1280.

[0091] The computing system 1200 further may 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 antenna 1285, which may represent one or more antenna(e). The computing system 1200 can include multiple wireless network interfaces such as a combination of Wi-Fi, Bluetooth®, near field communication (NFC), and/or cellular telephony interfaces. The network interface(s) 1280 may also include, for example, a wired network interface to communicate with remote devices via 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.

[0092] In one embodiment, the network interface(s) 1280 may provide access to a local area network, for example, by conforming to IEEE 802.11 wireless standards and/or the wireless network interface may provide access to a personal area network, for example, by conforming to Bluetooth standards. Other wireless network interfaces and/or protocols can also be supported. In addition to, or instead of, communication via wireless LAN standards, network interface(s) 1280 may provide wireless communications using, for example, Time Division, Multiple Access (TDMA) protocols, Global System for Mobile Communications (GSM) protocols, Code Division, Multiple Access (CDMA) protocols, Long Term Evolution (LTE) protocols, and/or any other type of wireless communications protocol.

[0093] The computing system 1200 can further include one or more energy sources 1205 and one or more energy measurement systems 1245. Energy sources 1205 can include an AC/DC adapter coupled to an external power source, one or more batteries, one or more charge storage devices, a USB charger, or other energy source. Energy measurement systems include at least one voltage or amperage measuring device that can measure energy consumed by the computing system 1200 during a predetermined period of time. Additionally, one or more energy measurement systems can be included that measure, e.g., energy consumed by a display device, cooling subsystem, Wi-Fi subsystem, or other frequently used or high-energy consumption subsystem.

[0094] In various embodiments, description is made with reference to figures. However, certain embodiments may be practiced without one or more of these specific details, or 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, etc., in order to provide a thorough understanding of the embodiments. In other instances, well-known semiconductor processes and manufacturing techniques have not been described in particular detail in order to not unnecessarily obscure the embodiments. Reference throughout this specification to “one embodiment” means that a particular feature, structure, configuration, or characteristic described in connection with the embodiment is included in at least one embodiment. Thus, the appearances of the phrase “in one embodiment” in various places throughout this specification are not necessarily referring to the same embodiment. Furthermore, the particular features, structures, configurations, or characteristics may be combined in any suitable manner in one or more embodiments.

[0095] Although the embodiments have been described in language specific to structural features and/or methodological acts, it is to be understood that the appended claims are not necessarily limited to the specific features or acts described. The specific features and acts disclosed are instead to be understood as embodiments of the claims useful for illustration.