Waypoint for the last known network connection

Abstract

Waypoints are automatically created by monitoring network radio signal strength, allowing mobile device users in non-urban locations to find previous locations using known network connectivity and make emergency calls. In some embodiments, a backtrack route to the nearest previous location with network connectivity is displayed on the mobile device. In some embodiments, for privacy reasons, access to waypoint information stored in secure storage / database is restricted based on location status determination, and the backtrack route is displayed in stages.

Description

Technical Field

[0004] ,

[0001] (Cross - Reference to Related Applications) Cross - Reference to Related Applications This application claims the benefit and priority of U.S. Provisional Application No. 63 / 506,362, filed on June 5, 2023, entitled "WAYPOINTS FOR LAST KNOWN NETWORK CONNECTIVITY", and U.S. Non - Provisional Application No. 18 / 733,658, filed on June 4, 2024, entitled "WAYPOINTS FOR LAST KNOWN NETWORK CONNECTIVITY", which are hereby incorporated by reference in their entirety for all purposes.

Background Art

[0002] When in a remote area (e.g., while hiking), cell coverage may be lost. In case of an emergency, a person may not be able to make an emergency call, for example, to 911. To make such an emergency call, it is desirable to provide the user with information regarding the nearest location. Summary

[0003] One or more computer systems can be configured to perform certain operations or actions by installing software, firmware, hardware, or combinations thereof into an operating system and causing the system to execute that operation. One or more computer programs can be configured to perform certain operations or actions by comprising instructions that, when executed by a data processing apparatus, cause the apparatus to execute that operation.

[0004] One general embodiment includes a method performed by one or more processors of a first mobile device. The method also includes monitoring the strength of a network radio signal. The method also includes storing a first previous location of the first mobile device at a first previous time when the strength of the network radio signal exceeded a threshold. The method also includes receiving a request to provide information about the first mobile device's previous network connection. The method also includes retrieving the first previous location upon request. The method also includes providing the first previous location to the user of the first mobile device. Other embodiments of this embodiment include corresponding computer systems, devices, and computer programs recorded in one or more computer storage devices, each configured to perform the operations of the Method.

[0005] Another general embodiment includes a method performed by one or more processors of a first mobile device. The method also includes receiving a target altitude. The method also includes monitoring the current altitude of the first mobile device. The method also includes providing a first notification when the current altitude matches the target altitude. The method also includes disabling a notification after the first notification. The method also includes continuing to monitor the current altitude of the first mobile device. The method also includes enabling a notification when the current altitude differs from the target altitude by more than a threshold amount.

[0006] These and other embodiments of the Disclosure are described in detail below. For example, other embodiments cover systems, devices, and computer-readable media associated with the methods described herein.

[0007] A better understanding of the nature and advantages of the embodiments of this disclosure can be obtained by referring to the following detailed description and accompanying drawings. [Brief explanation of the drawing]

[0008] [Figure 1]This is a block diagram of a network operating environment for an electronic device according to one embodiment.

[0009] [Figure 2] This is a block diagram of a location service according to one embodiment.

[0010] [Figure 3A] This document shows a user interface for a location service according to one embodiment. [Figure 3B] This document shows a user interface for a location service according to one embodiment.

[0011] [Figure 4] This is a flowchart illustrating a location service method according to one embodiment.

[0012] [Figure 5] This figure shows the last known network connection and waypoints for backtracking according to several embodiments.

[0013] [Figure 6] The diagrams illustrate how to provide location information about when the network signal was last available, according to several embodiments.

[0014] [Figure 7] This flowchart shows a method for providing location information about when a network signal was last available, according to several embodiments.

[0015] [Figure 8] This flowchart shows a method for providing location information with privacy protection, according to several embodiments.

[0016] [Figure 9A]An exemplary user interface for transitioning between different views of location indication according to some embodiments is shown. [Figure 9B] An exemplary user interface for transitioning between different views of location indication according to some embodiments is shown. [Figure 9C] An exemplary user interface for transitioning between different views of location indication according to some embodiments is shown. [Figure 9D] An exemplary user interface for transitioning between different views of location indication according to some embodiments is shown. [Figure 9E] An exemplary user interface for transitioning between different views of location indication according to some embodiments is shown. [Figure 9F] An exemplary user interface for transitioning between different views of location indication according to some embodiments is shown. [Figure 9G] An exemplary user interface for transitioning between different views of location indication according to some embodiments is shown. [Figure 9H] An exemplary user interface for transitioning between different views of location indication according to some embodiments is shown. [Figure 9I] An exemplary user interface for transitioning between different views of location indication according to some embodiments is shown. [Figure 9J] An exemplary user interface for transitioning between different views of location indication according to some embodiments is shown. [Figure 9K] An exemplary user interface for transitioning between different views of location indication according to some embodiments is shown. [Figure 9L]An exemplary user interface for transitioning between different views of location indication according to some embodiments is shown. [Figure 9M] An exemplary user interface for transitioning between different views of location indication according to some embodiments is shown. [Figure 9N] An exemplary user interface for transitioning between different views of location indication according to some embodiments is shown. [Figure 9O] An exemplary user interface for transitioning between different views of location indication according to some embodiments is shown. [Figure 9P] An exemplary user interface for transitioning between different views of location indication according to some embodiments is shown. [Figure 9Q] An exemplary user interface for transitioning between different views of location indication according to some embodiments is shown.

[0017] [Figure 10] A flowchart showing a method for transitioning between different views of location indication according to some embodiments.

[0018] [Figure 11] Vertical geofence at a target altitude (elevation) and an alert when the target altitude is reached are shown according to some embodiments.

[0019] [Figure 12] Vertical geofence notifications when a user moves up and down the target altitude are shown according to some embodiments.

[0020] [Figure 13] A mechanism for preventing unnecessary notifications is shown according to some embodiments.

[0021] [Figure 14] Several embodiments of a mechanism for preventing unwanted notifications using vertical geofence signals are shown.

[0022] [Figure 15] This document demonstrates the operation of a framework for tracking altitude and providing notifications through several embodiments.

[0023] [Figure 16] This flowchart shows how to trigger an alert at a target altitude according to several embodiments.

[0024] [Figure 17] This is a block diagram of an exemplary device that may be a mobile device, according to several embodiments. [Modes for carrying out the invention]

[0025] term A waypoint is an intermediate point or location on a route or path traveled by a user, which may be defined by a set of coordinates (e.g., latitude and longitude, GPS point, etc.) used to identify a point in physical space. Navigation applications can use the coordinates of a waypoint position to track and display distance and direction information of the waypoint position compared to the current position of an electronic device.

[0026] Directional information provides the compass direction from the electronic device position to the waypoint position. In some embodiments, the directional information is, depending on the implementation, the horizontal angle between the waypoint position and the direction of movement of the electronic device, or the horizontal angle between the position determined by the electronic device and magnetic north or true north. For example, if a user holds the electronic device and points it towards true north, moves with the electronic device, and the waypoint position is directly behind where the electronic device is pointing, the direction would be south. Relative direction refers to the angle between the direction of movement of the electronic device and the location of the waypoint position.

[0027] In some embodiments, the device context is a set of conditions that, when met, determine what location type (e.g., urban or backcountry) a mobile device is in. For example, the location type may be determined using motion classification (e.g., driving, walking, stationary), wireless signals (e.g., Wi-Fi, cellular, Bluetooth) and their number, and map tile categories (e.g., whether the tile is classified as urban). The data may be analyzed to determine whether the device context exists in order to trigger a change in location type.

[0028] Detailed explanation In the following description, specific details are provided for illustrative purposes to provide a complete understanding of a particular embodiment. However, it will be understood that various embodiments may be practiced without these specific details. The drawings and description are not intended to be limiting.

[0029] Location services can, but are not limited to, repeatedly request waypoint information, including positioning information and directional information (e.g., GPS data, GPS points), over a period of time to assist in tracking and navigation to waypoint locations. In some embodiments, an electronic device may provide direction to a waypoint location, trajectory of movement to the waypoint location, and distance to the waypoint location. For example, an electronic device may repeatedly request positioning information about its current position while the user is moving in order to continuously calculate the distance to a waypoint location. In another example, directional information can be repeatedly calculated using the received positioning information.

[0030] In some embodiments, two types of waypoint positions (also called waypoints) may be created: cellular waypoints for tracking cellular connections and SOS waypoints for tracking SOS connections. Waypoint information may include the time and / or location when a mobile device (e.g., a wearable device such as a watch) or companion device (e.g., a phone or tablet paired with the device) last had a network signal, such as a cellular signal or other wide-area network signal. Signal reception may be tracked, for example, using the same module for providing signal strength to a display on the mobile device or companion device. Signal strength may be monitored and stored periodically, and potentially only the time and / or location when the signal strength fell below a threshold may be stored. Signal strength may be stored as a bit flag indicating whether the signal was above or below a threshold, or as a numerical value. The time and signal strength may be stored in a first table or database. For example, one or more times and / or locations when the mobile device last had a network signal above a threshold may be stored.

[0031] In some embodiments, the location of a mobile device can be stored separately (e.g., in a second table or database) from time events of network signal strength (e.g., in a first table or database). This location database can be stored in secure storage accessible only by specific system routines, and such information can be provided to the user only when certain criteria are met (e.g., when the location type is one where signal loss is likely, such as a non-urban location).

[0032] The time when the signal strength last exceeded a threshold can be used to retrieve the corresponding location from a second table that includes time as a field. In some implementations, for privacy reasons, the location in the last available network radio signal may only be provided when the device is classified as being in a non-urban location state (e.g., rural, mountainous, etc.). For example, such a state (also called a location type) may be determined using motion classification (e.g., driving, walking, stationary, etc.), radio signal (e.g., Wi-Fi, cellular, Bluetooth, etc.) and its number, as well as map tile category (e.g., whether the tile is classified as urban or not). In some embodiments, access to location information may be limited to specific times when the device is still determined to be in a non-urban location state, rather than all recorded history. In this way, location information is provided only when needed, thereby reducing the possibility of such location information being misused.

[0033] A mobile device can retrieve one or more previous locations when it has an available signal (i.e., the signal is above a threshold). These locations can be displayed on the device as waypoints. For example, multiple locations may be retrieved if it is easier or faster for the user of the mobile device to reach a previous location using the available signal, as may occur during hiking. Waypoints may be displayed with an icon or text indicating that the waypoint represents a previous location where an available signal was present. In some embodiments, for privacy reasons, if the signal strength at a particular waypoint changes when the mobile device reaches that particular waypoint, the waypoint may be displayed in stages.

[0034] In some implementations, two or more types of network signals may be monitored. For example, out-of-network signals (e.g., for any carrier other than those used by mobile devices) may be tracked because such other networks may still allow emergency calls to be made. If in-network waypoints and out-of-network waypoints are close to each other (e.g., within a proximity threshold), only in-network waypoints may be displayed.

[0035] The display of waypoints (e.g., available signal waypoints) may be provided in a compass or map application. Previous locations stored in a second database may be used to provide a route for the user to backtrack to the last known location at a signal.

[0036] In some embodiments, the current altitude of a mobile device may be monitored to trigger an alert (or notification) when the device reaches a target altitude. Unwanted notifications can be reduced by adding a programmable threshold amount of altitude around the monitored altitude to enable and disable notifications at appropriate times.

[0037] Embodiments of this disclosure offer several advantages. For example, instead of the user of a mobile device having to manually create waypoints while on the move, the automatically generated cellular / SOS waypoints are more accurate because the network radio signal strength is continuously monitored.

[0038] Furthermore, network wireless signals are crucial and potentially life-saving when mobile device users are in non-urban locations (or remote mountain areas). Automatically generated cellular / SOS waypoints can also avoid distractions for mobile device users while hiking in difficult or unfamiliar terrain.

[0039] Finally, privacy protections for location-based historical information access (e.g., restricted access to location information within secure storage / databases and within a time frame) and backtracking route display (e.g., a single waypoint, multiple waypoints, or step-by-step display of waypoints) address concerns when an individual's travel route is automatically tracked. I. Network communication and location determination

[0040] Electronic devices (e.g., mobile devices) may have locally accessible services such as location services, or services that are accessible from the outside via a network connection (e.g., the Internet) (e.g., telephone services, storage services, and device locator services). A. Network operating environment

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

[0042] Each of the electronic devices 102 may optionally include a user interface, such as a user interface 104 for the electronic device 102. In other embodiments, the electronic device 102 may not have a user interface. The electronic device 102 may be a third-party device that utilizes an application programming interface to access the 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., an operating system) than the electronic device 102. The electronic device 102 may communicate via one or more wired and / or wireless networks 110 to perform data communication. For example, a wireless network 112 (e.g., a cellular network, a 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.

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

[0044] The electronic 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 communication between electronic devices or between an electronic device and a wired telephone device. The telephone service 130 can route Voice over IP (VoIP) calls via a wide area network 114 or access a cellular voice network (e.g., 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, for example, song files, audiobooks, movie files, video clips, and other media data. The storage service 160 can provide the electronic device 102 with network storage capabilities to store documents and media files. The device locator service 170 can enable a user to locate a lost or misplaced device that was connected to one or more wired and / or wireless networks 110 at some point in time. Other services may also be provided, including a software update service for updating operating system software or client software on an electronic device. 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, and the various services are facilitated through a cloud service account associated with the electronic device 102.

[0045] The electronic device 102 may have locally accessible applications, services, application programming interfaces, and functions on the device that includes and / or utilizes the location service 180. The electronic 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 locate the location of accessory devices using the device locator service 170 and the location service 180, and may provide mapping and navigation applications. The navigation application (e.g., a "Compass" application) assists the user in navigating to historical positions on the user's route and in backtracking. The navigation application is an application that indicates the basic direction used for navigation and geographic bearing using any number of methods, including a gyroscope, magnetometer, and / or positioning system (e.g., a GPS receiver). The mapping application is an application that uses maps delivered by a Geographic Information System (GIS). The backtrack route may be a set of historical positions taken over a time window that allows the user to retrace steps.

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

[0047] In some cases, a machine learning algorithm 186 may be used to identify known locations 182 and / or trusted locations 184. For example, cluster data analysis may be used to identify, classify, and provide semantic labels for locations such as locations frequently visited by the user. Secure and trusted locations 184 may be explicitly designated or confirmed as such by the user of the electronic 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). While cluster analysis is provided as an example of a machine learning algorithm that may be used, those skilled in the art will recognize that other algorithms may be used to identify potential known or trusted locations.

[0048] On-device heuristics and / or machine learning models may be used to infer relationships between a user and a location based on the 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 include home, a vehicle, a workplace, any location frequently visited by the user with electronic devices (e.g., accessory devices and electronic devices 102), and / or any other location designated by the user as a trusted location 184. Known locations 182 may be business locations, public spaces, parks, museums, and / or any other locations that the user may frequently visit.

[0049] A defined location may have associated fence information that, when detected, provides a set of conditions that enable the designation or classification of an electronic device for 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 the 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 the region of the defined location. The fence information may be a geofence with boundary information about the defined location, such as a point location and the extent of a region from the point location (e.g., a circular region defined by 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 characteristics of a particular region of the defined location (e.g., fingerprint data including radio frequency (RF) scan data such as Wi-Fi scan traces). The fence information for each defined location may be stored along 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 radial distances around the point location to enable the creation of a fence for the location. In some embodiments, the fence is a virtual boundary of a real-world geographical area. Using the Global Positioning System (GPS), a virtual fence can be created around a location, and the physical location of electronic devices 102 within the geofence boundary, as well as the entrances and exits of the bounded area, can be tracked. In some embodiments, there are at least two layers of fences that can be used to reduce conventional geofence latency. For example, the mode selected based on analysis of user context data to determine intent may consider the selection of the granularity of the established fence. In some embodiments, multiple fences may be used to refine the positioning information determined by the coarse-grained geofence.

[0050] The machine learning algorithm 186 may include on-device heuristics, machine learning algorithms, or a combination thereof to analyze and assign labels that describe user context, such as location status. Location status may be a label for the user context (e.g., a set of conditions, a motion classification) used by a particular positioning technique and resource of an electronic device to acquire positioning information. Location status may define the current location state of the user while moving with the electronic device and / or predictions of changes in the location state. By proactively acquiring positioning information using a technique appropriate to the location status, latency in providing information for device applications is reduced without causing a significant degradation in the performance of the electronic device that may be experienced due to constant requests for positioning information. For example, user context may indicate the movement or motion of an electronic device, allowing the electronic device to be designated as having a motion classification such as "moving," "stable" at a particular defined location for a period of time, or any other defined motion classification. The analysis can be performed using various signals from contextual user data sources available to the electronic device 102, including but not limited to sensor data, positioning data, calendar data, transit card usage data, application data, historical data on movement 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 electronic device 102. In one embodiment, wireless connection status with various devices may indicate that the device is stable or “in motion.” For example, loss of connection to appliances, security systems, heating / cooling systems, vehicles, other modes of transport, and / or any other devices may indicate that the electronic device is “in motion.”

[0051] In some embodiments, the electronic device 102 may be classified with the “stable” semantic label after remaining within a geographical boundary defining a location (e.g., a trusted location 184) for a defined period of time. For example, received positioning data for the electronic device 102 may indicate that the electronic device 102 remains within the boundaries of a fence for a particular location for a certain duration (e.g., 5 minutes). Sensor data, such as accelerometer data, may support the inference that the electronic device 102 is stable by indicating that it is stationary. Application data may support the inference that the electronic device 102 is stable, such as the electronic device being located at a calendar reservation location. Application data indicating the type of application being used may also provide the inference that the device is in a stable state, such as using a media application. User history data regarding routines or patterns while on the move, such as a bedtime routine at a home or hotel location, may be used to determine whether the electronic device 102 is in a stable state.

[0052] Electronic device 102 may be classified as having the label "in transit" based on previously detected behavior, patterns, or routines about the user, and can be analyzed on electronic device 102. For example, a user may have a routine of working at the same time every day, and if the data on the device supports that the pattern is repeating, the "in transit" state may be assigned. The speed at which the electronic device is moving or entering and exiting a known geographic area (e.g., using a fence) may allow for the inference that electronic device 102 is in transit. If electronic device 102 is detected accelerating in an area of ​​known transit (e.g., a road, highway, rail line, etc.), electronic device 102 may be given the motion classification "in transit". Similarly, if a transit application / card is being used / in use, electronic device 102 may be designated as "in transit".

[0053] The electronic device 102 may be classified as "threshold distance," "near entrance," "near exit," "entrance," and / or "exit" for a set of locations or a specific location, based on detecting patterns of sensor values ​​characteristic of being in a location, such as Wi-Fi scan results characteristic of crossing fence boundaries for individual locations or sets of locations, and / or being inside a location or transitioning to a location. B. Location Services

[0054] Figure 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., a fence event monitor, a location status monitor, a sensor monitor, etc.) that can help determine when the power mode and performance mode should be adjusted to determine positioning and / or directional information. The event monitor module 264 may also function as a queue of user contexts, depending on data from a context user data source, and may use heuristics and / or machine learning algorithms 186 to determine the user context that triggers the mode adjustment. In some embodiments, the user context and location state may determine the adjustment to the power and performance modes running on the electronic device 102. The user's location state is either being in a defined location or moving between locations. By considering the user's location state and user context (e.g., information from motion sensors, application data), positioning and / or directional information may be provided in anticipation of when the user needs the information.

[0055] In some embodiments, the event monitor module 264 may use data to determine adjustments to modes that may affect the power or performance of the operation of the electronic device 102. For example, the user context of the electronic device 102 may include a “moving” designation using the motion classifier 280 and wireless connectivity status data indicating that the Bluetooth connection between the electronic device 102 and an accessory device such as a vehicle entertainment system has been lost. Continuing this example, the event monitor module 264 may determine from one or more context user data sources (e.g., motion classifier, wireless connectivity status) that there is at least one indication that there is a change in the location status and / or motion classification of the electronic device 102, such as the user being “moving” and the electronic device 102 being “moving to a defined location” because it has lost its Bluetooth connection to the vehicle entertainment system, and therefore the user may be leaving the vehicle and moving to a certain location. Crossing the fence boundary of one or more defined locations may indicate that the user intends to enter a defined location. User context data, such as fence boundary crossings, vehicle exits, transfer station exits, user routines, sensor data, and application data, may be analyzed to predict when an electronic device is at a threshold distance from a defined location and when the mode of the electronic device should be adjusted.

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

[0057] The visitor monitoring module 270 can utilize the event monitoring module 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 anticipating when a user will request positioning data. The visitor monitoring module 270 can retrieve fence information 290 to define a more precise boundary for a defined location when it is detected that the electronic device 102 is crossing a coarser-grained geofence boundary, as detected using the intrusion detection module 266. In another embodiment, the visitor monitoring module 270 can retrieve expected sensor data (e.g., fingerprint data) characteristics of the electronic device 102 along with its location status.

[0058] The proactive service 268 can be used to predict applications and / or services that a user may want to access, using a given user context, movement classification, and / or location status. For example, a user may want to access a specific application immediately before or upon entering a certain location. The proactive service 268 can select an application based on the user's application selection history, or suggest a new application associated with a specific defined location.

[0059] In one embodiment, an electronic device 102 (having an event monitor module 264) may detect a set of conditions that enable the inference that a user may request a backtrack route to allow them to retrace those steps, and the electronic device 102 may initiate an enhanced power-saving mode to acquire positioning information without affecting the performance of the electronic device 102. In one embodiment, a proactive service 268 may adjust the rate of periodic requests for determining positioning information. To handle intermittent reception of positioning information, a 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.

[0060] In some embodiments, map data accessed by the mapping application 250 is used to estimate distance. The 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., angle from magnetic north) information about the electronic device 102 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 caused by the movement of the device as the user moves along their trajectories (e.g., pushing of the device, hand shake if the device is worn on the user's wrist).

[0061] The proactive service 268 and event monitor module 264 may utilize 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 about whether the electronic device 102 is stationary or moving with the user. While embodiments are not limited to specific sensor types, specific sensor data representations, or specific features, exemplary sensors and features capable of distinguishing specific movements within 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 identification based on the supplied features. In some implementations, the electronic device may receive motion classifications from the electronic device or from a server indicating that the mobile device is moving in a specific mode of movement. The backtrack classifier 278 classifies the acquired historical positions of the mobile device 102 as a potential part of the user's backtrack route for the electronic device 102.

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

[0063] Location services in electronic devices (e.g., wearable devices) may be accessible through a user interface that includes complications that display information for the corresponding application. When a specific complication (e.g., one corresponding to a navigation application) is activated, waypoints can be displayed as icons.

[0064] Figure 3A shows a user interface 201 for a location service according to one embodiment. The illustrated user interface 104 is a smartwatch face having location service complications 203, 205, 207, and 209. A “complication” is an object on the watch face that represents and displays information for an application, such as date, weather information, barometric pressure, calendar information, a navigation application 220, and waypoints, and does not tell the time. A particular complication corresponds to a particular application (e.g., a navigation application) that may be run on the device displaying the watch face. Complications may be displayed within a particular “style window” of the watch face. A “style window” may correspond to a part of the watch face designated to display complications. In some embodiments, the user can configure the watch face by deciding which information is displayed in a particular style window (e.g., by selecting a watch application). As used herein, the term “affordance” refers to a user-interactive graphical user interface object that may optionally be displayed on the display screen of an electronic device 102. For example, images (e.g., icons), buttons, and text (e.g., hyperlinks) can each optionally constitute affordances.

[0065] As shown in the figure, complications 203, 205, and 207 are deactivated, and the corresponding application (e.g., navigation application 220 with waypoints) does not respond to requests for the deactivated complications on the electronic device 102. As shown in the figure, the deactivated complications 203, 205, and 207 may be grayed out with a specific shade to indicate that the navigation application 220 does not respond to requests for the complications. Complications 203, 205, and 207 represent the navigation application 220, which provides directional information for the waypoint position selected by the user when selecting affordances corresponding to individual complications. In the case of dynamic waypoint complications, the user may be presented with a dialog (e.g., a user interface) to select the waypoint position of the complication displayed on the watch face when activated. In the case of static complications, the waypoint positions are already assigned to the complication, or the complication is predefined, and the navigation application 220 can provide directional information for individual waypoints. For example, the default or initial complication may be related to the car's position and / or home location. In another example, the user may select a waypoint for a campground and / or park that may have been defined while the user was hiking, and the user may want to select the waypoint to find their way back. In yet another example, complication 209 is activated and displays directional information from true north of the electronic device 102 using the navigation application 220.

[0066] In some embodiments, complications can be activated by interacting with affordances that represent the complication. For example, if a user selects an affordance representing the “park” waypoint complication 203 in Figure 3A, the navigation application 220 responds to a request for waypoint information (e.g., the direction to the “park” waypoint 302 and the distance to waypoint 304 in the activated complication 301), and the information is displayed in the activated complication 301 in Figure 3B, which corresponds to the deactivated complication 203 in Figure 3A.

[0067] Figure 3B shows a user interface 300 for a location service according to one embodiment. The user interface 104 shows activated complications 301 (corresponding to the deactivated complication 203 in Figure 3A), 304 (corresponding to the deactivated complication 205 in Figure 3A), 209, and 306 (corresponding to 207 in Figure 3A). In some embodiments, waypoint icons (such as the leaf icon 302, house icon 306, and sign icon 304 in the activated complication) are either predefined (e.g., a car icon for a parked car, a house icon for the user's home or campsite 306, a leaf icon for a park location 301, etc.) or assigned by the user (e.g., a sign with a specific color 304).

[0068] As shown in complication 301, the navigation application 220 provides directional information by displaying a marker 302 within the complication to indicate how far to the right the waypoint position of “park” waypoint 301 is from the user’s current position. After the complication is activated, it may be updated with information for requests at a first period (e.g., every 15 minutes), but the frequency may decrease or increase based on the motion classification and / or mode of transport. For example, complications 304, 209, and 306 may be responded to by duty cycle requests that operate at a first period (e.g., every 15 minutes), and complication 301 may be responded to by requests that occur at a first time interval value (e.g., every second) as the user is moving toward the waypoint. In some embodiments, when the user selects affordance complication 301 (e.g., by long-pressing on the screen), a user interface for a target view of the waypoint may be provided, as shown in Figure 4. III. Backtracking

[0069] 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. One or more backtracking conditions are a set of conditions that allow for the inference that the user is on an unfamiliar route, in nature, as part of an exercise session, unable to recharge their device over an extended period of time, and / or engaged in any other activity that may require retrace steps taken along the route. Based on the observed set of backtracking conditions, a prediction is made that the user may need historical positioning information in order to retrace the user's steps using a backtrack route and to proactively request the electronic device to acquire historical positioning information. The backtrack route may be a set of historical positions acquired over a lookback window of time that allows the user to retrace their steps. The lookback window is a set of historical positions over the most recent period that is likely to be needed to retrace steps, while protecting the user's privacy from malicious actors looking for more routes than the most recent backtrack route. In some embodiments, the lookback window of the position returned upon request is adjusted to provide positioning information relevant only to the immediate need for a backtrack route (e.g., truncated, pruned, etc.).

[0070] Embodiments described herein provide a backtrack classifier that, in response to a request for an electronic device, classifies acquired historical positions as either candidate positions or non-candidate positions in a backtrack route for the user of the electronic device. In one embodiment, historical positions are classified to find the most recent historical position for which a backtrack route may be required. Historical positions designated as part of a backtrack route may be provided to a location service application on request to assist the user in retrace steps when they are potentially missing and / or when assistance is requested in an emergency situation.

[0071] Nonstop or continuous collection of positioning information can consume resources (e.g., battery, processor usage) when the user is unable to recharge their devices (e.g., in the wilderness or lost), so electronic devices may acquire position information in a power-saving extended mode when one or more backtracking conditions are met.

[0072] In one embodiment, one or more backtracking conditions may include, but are not limited to, motion classifications in motion (e.g., not stationary), threshold periods without network access, sparse environmental classifications (e.g., low population density or density of man-made structures in the area), and threshold distances from frequently visited locations and / or locations that are part of a user routine. While specific categories of conditions are provided, those skilled in the art will recognize that any other user context data may complement and / or form the basis for the inference that a user will request historical positioning information for backtracking.

[0073] Figure 4 is a flowchart 400 illustrating a backtracking technique according to one embodiment. The electronic device 102 detects one or more backtracking conditions that trigger the collection of a set of historical positions for a lookback time window (401). The one or more backtracking conditions are a set of conditions determined by analyzing user context data, enabling the inference that the user may need to backtrack historical positioning data (e.g., being in nature and / or an unfamiliar area). Based on the one or more backtracking conditions, the electronic device 102 predicts that the user may desire historical position information to enable backtracking (e.g., retrace a route) in a navigation application and / or a mapping application. In some embodiments, the detected one or more backtracking conditions are a subset of conditions that may be determined from an analysis of accessible user context data as shown in Figure 3 using an extended mode. While a specific technique for collecting historical positions is described, a set of conditions for inferring that the user is missing before collecting historical positions, and a subsequent review of the conditions before responding to a request for historical positions, can be performed using any implementation form for collecting historical positions.

[0074] User context data can supplement backtracking conditions to provide a decision on initiating an extended mode and acquiring positioning information. In one embodiment, one or more backtracking conditions may include, but are not limited to, motion classifications in motion (e.g., not stationary), threshold periods without network access, sparse environment classifications (e.g., not densely populated or densely populated with man-made structures in the area), and exceeding a threshold distance from frequently visited locations and / or locations that are part of a user routine. While specific categories of conditions are provided, those skilled in the art will recognize that any other user context data may complement and / or form the basis for inference that a user will request historical positioning information for backtracking.

[0075] The motion type classification condition is met when a motion classification is received that the electronic device 102 is not stationary and / or is “in motion”. In one embodiment, the motion type classification condition is met when the mode of movement is human-powered (e.g., walking, cycling, skateboarding, etc.) or electric-assisted vehicle (e.g., electric-assisted bicycle) and not electric vehicle or automated vehicle (e.g., car, airplane, electric vehicle). A motion classifier 280, trained on a feature set from data acquired using the electronic device sensor, can provide information about whether the electronic device 102 is stationary or in motion, including a mode of movement. In some embodiments, the motion classification may indicate an inference of a user’s activity or mode of movement in motion, including, but not limited to, walking, cycling, exercise equipment, scooter, skateboarding, inside a vehicle, airplane, transport vehicle, train, subway, human-powered vehicle, motor-assisted vehicle, electric-assisted vehicle, automated vehicle, and / or any other motion classification.

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

[0077] The electronic device 102 uses a density classifier 282 to determine whether a type of environmental backtracking condition is met, based on the classification of the geographic area as having a sparse density of structures within that geographic area. The density classifier 282, trained on a feature set from data acquired using the electronic device sensor, can provide information on whether the electronic device 102 is in a dense or sparse geographic area with respect to radio access point density, radio frequency signal (e.g., Bluetooth, UWB, etc.) density information, and density and landscape map data. In some embodiments, the density of radio access points within an area is a feature provided in the classification of the density of structures within the geographic area. For example, if there are many different radio access points in each area, the likelihood of a dense urban environment increases. As another example, the time span recorded between radio access point observations may 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 the electronic device 102 with a tile-based mapping service that enables the electronic device 102 to retrieve map data and metadata relating to the geographical area of ​​the electronic device 102 or the 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 may include the classification of the current map tile or subtile. The map tile metadata may also include digital elevation model (DEM) data showing a surface model including the structure of the estimated geographical area, which can be featured in the density classifier 282.

[0078] Next, if the electronic device 102 exceeds a threshold distance from a frequently visited location, a location that is part of a user routine, a secure location, or a trusted location, the fulfilled backtracking conditions can be analyzed to determine whether sufficient conditions have been met to proactively proceed to acquire historical positioning information.

[0079] 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 the classification of a single historical position has been described with reference, those skilled in the art will recognize that multiple historical positions may be classified in order to determine the lookback window of the historical positions to include in the backtrack route.

[0080] An electronic device may classify at least one historical position as a candidate position for a backtrack route based on one or more features (e.g., signals) observed when collecting historical positions (e.g., duration of lookback window, no locations further than 250 km, no previous locations in the vehicle, etc.) (403). Features considered when classifying historical positions include, but are not limited to, duration of lookback window, distance from frequently visited, safe and / or reliable locations, position information collected before and after entry of electric vehicles (e.g., cars, airplanes, etc.) and / or electric vehicles, structural density classification (e.g., urban areas, etc.), access point density, motion classification, transport mode classification, user activity (e.g., hiking events from calendar data), and / or any other features that may indicate that a user may need a backtrack route.

[0081] For example, the most recent historical position considered a lookback window candidate may not be as far back as the maximum duration from the current time. Similarly, historical positions that are greater than the maximum distance from the current position may be excluded from consideration as lookback window candidates. Position information acquired during flight and / or other movement within a vehicle may be truncated from the lookback window and not considered a lookback window candidate. In some embodiments, historical positions that do not exceed a reliable threshold distance may be truncated from the lookback window unless the user requests recording of historical positions near frequently visited locations and / or safe, reliable locations. Access point density and structural density classification indications that 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.

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

[0083] In some embodiments, an application requesting access to the lookback window must possess a qualification. A qualification can identify an application as having the right or privilege to access positioning information. When a user requests access to historical positioning information through an application, the lookback window positioning information may be conveniently provided, as opposed to requiring the user to make redundant efforts to obtain historical positioning information. IV. Tracking the last known location of the network signal

[0084] Embodiments provided herein describe automatically generated waypoints for tracking the last known location using wireless network signals. Time and location information associated with these waypoints may be stored in secure storage / database with privacy protections. When a user of a mobile device in a non-urban location launches a navigation application (e.g., a compass application or a map application), a backtrack route to one or more of these waypoints may be displayed on the mobile device.

[0085] Figure 5 shows waypoints for the last known network connection and backtracking according to several embodiments. Figure 5 shows an urban location 510 and a non-urban location 512. The urban location may have many building structures, network radio signals (e.g., cellular connectivity and Wi-Fi), and movement activities using electric-assist vehicles. The non-urban location may be in a remote area with few building structures, uneven network radio signals, and human-powered activities (e.g., cycling, running, hiking). A user of a mobile device 530 can travel from urban location 510 to non-urban location 512 via a rural road 514 with several rest stops (e.g., 520).

[0086] In Figure 5, several waypoints (e.g., W1, W2, W3, and W4) may be marked along the path taken by a user of mobile device 530. For example, waypoint W1 is just outside urban location 510 and may have cellular connectivity. W2 is after rest stop 520, which has a Wi-Fi signal. W3 and W4 are inside non-urban location 512. W2' may or may not be present during the transition from urban to non-urban location. If the user takes route B instead of route A, waypoint W4 may be created. Further details regarding waypoint creation are described below.

[0087] When a user of a mobile device 530 in a specific non-urban location 540 attempts to communicate (e.g., make a phone call or text message) but network radio signals are unavailable, the techniques or embodiments disclosed herein may enable the user to find a route to backtrack to the last known location (e.g., W3 or W4 in Figure 5) using a network connection that has an appropriate network radio signal (e.g., either a cellular network connection or an SOS connection) for sending an emergency message or making an emergency call. In some embodiments, the user may launch an application, such as a compass application or a map application, on the user's mobile device (e.g., a mobile phone, watch, or companion device). The launched application may access a secure database (or storage) and, based on the user's status (e.g., non-urban location status), determine whether the user has permission to access specific waypoint information (e.g., historical information related to time, location, signal strength, signal type, etc.), and then display a backtrack route from the current location to a previous location (i.e., a waypoint) using an appropriate network radio signal strength (e.g., above a threshold) for communication. A. Creating Waypoints

[0088] As described above, waypoints can be automatically created to track the last known location using radio network signals. In some embodiments, the techniques disclosed herein can automatically create two types of system waypoints: cellular waypoints for tracking cellular connections and SOS waypoints for tracking SOS connections. SOS is the common name for the International Morse Code distress signal. An SOS connection can refer to a network radio signal that enables a user to send an emergency message or make an emergency telephone call. Network radio signals for SOS purposes may include, but are not limited to, intra-network signals provided by the user's subscriber radio carrier, extra-network signals provided by other radio carriers, and satellite signals. For example, in some countries such as the United States, Canada, and Australia, a user can make a cross-carrier emergency call. A cellular connection, on the other hand, typically refers to an intra-network signal provided by the user's subscriber radio carrier.

[0089] In some embodiments, a mobile device employing the disclosed technique can track all types of network radio signals, automatically determine which types of waypoints to create, and create them accordingly. For example, a cellular waypoint is automatically created when an in-network cellular signal falls below a threshold. An SOS waypoint is automatically created when an out-of-network signal and / or satellite signal falls below a threshold.

[0090] In certain embodiments, signal reception, including its intensity, of both types of network radio signals (cellular and SOS) is continuously monitored and tracked. Signal intensity can be stored in a database in various representations, such as bit flags or numerical values, indicating whether the signal is above or below a threshold. For example, signal intensity may be stored as 1, 2, or 3 bars. In another example, signal intensity may be stored as the numerical value 1, 2, or 3.

[0091] Whenever the signal strength falls below a threshold (e.g., two bars or a value of 2), the location service can create waypoints (either cellular waypoints or SOS waypoints), such as waypoints W1-W4 in Figure 5, along the path the user is traveling. In other words, a waypoint indicates that the cellular or SOS network radio signal may exceed the threshold for communication immediately preceding a marked location along the path. For example, a user of a mobile device may be hiking up a hill using a cellular connection. At some point, the signal strength of the user's in-network radio signal falls below two bars, and the user's mobile device may automatically generate a cellular waypoint (e.g., waypoint W3 in Figure 5) along the user's hiking path. If the user wants to make a call but finds there is no available signal or the signal is too weak, the user may launch an application to find their way back to the cellular waypoint with a suitable signal strength. On the other hand, if the signal strength returns to or recovers above the threshold, the waypoint is not created because the user does not need to use this waypoint feature and can simply use their mobile device to communicate. In some embodiments, several cellular or SOS waypoints can be created when the signal strength drops and recovers multiple times. B. Waypoint Information Database and Privacy

[0092] As mentioned above, information related to waypoints may be stored in secure storage / databases with privacy protections. As part of the privacy protections, time and location information may be stored separately, and the location status of the mobile device (e.g., city or non-city) may be determined for information access and display purposes.

[0093] Figure 6 shows Figure 600 for providing location information about when the network signal was last available, according to one embodiment. In Figure 6, Figure 600 includes secure storage 630, which further includes two tables or databases, namely a first table / database 632 and a second table / database 634. In some embodiments, secure storage 630 may include a single database divided into two securely isolated parts. Secure storage (or database) 630 may be shared by multiple mobile devices. As shown in Figure 6, two mobile devices, namely a first mobile device 610 (e.g., a wearable device) and a second mobile device 620 (e.g., a mobile phone), access the shared secure storage 630. The first mobile device 610 may further include a location state classifier 612. The location state classifier can classify the location state of the first mobile device 610 (e.g., urban location or non-urban location). Further details describing the classification process are described below.

[0094] In some embodiments, signal strength may be stored in a secure database (or storage) 630 shared among the user's mobile devices, such as a mobile phone, watch, or other companion device. These companion devices can communicate locally with each other, for example, by using Bluetooth, even without a cellular signal or the internet. The shared storage may be synchronized among the companion devices so that if one mobile device is unavailable, for example due to a lack of power, another mobile device can still access the shared storage.

[0095] In addition to signal strength, the shared secure storage (or shared database) may include, but is not limited to, other waypoint information including, time, location, signal strength, cellular status (e.g., connected, disconnected, roaming, airplane mode), motion classification (e.g., driving, running, walking, stationary), sequence or order of events (e.g., driving then walking, or in-network connection then out-of-network connection), network radio signal type (e.g., cellular or SOS), map tile category, and altitude, although only signal strength and location information are shown in Figure 6. Waypoint information may be stored for a certain period (e.g., ranging from one week to one month) before new information can overwrite older information previously stored.

[0096] In some embodiments, one of the mobile devices can store waypoint information in shared storage and retrieve it from shared storage, while another mobile device can only store waypoint information in shared storage. For example, in Figure 6, the first mobile device 610 may be a wearable device such as a wristwatch, which stores signal strength and location information in shared storage 630 and can retrieve the stored location information for analysis and use by the location state classifier 612. The second mobile device 620 may be a mobile phone that is a companion device to the first mobile device 610, which can also store signal strength and location information in shared storage 630 when the first mobile device 610 has a weak signal or no power.

[0097] In some implementations, for privacy purposes, two tables may be used to store signal strength (e.g., Received Signal Strength Indicator (RSSI)) and location separately. For example, in Figure 6, if two tables are used, storing previous locations (e.g., cellular waypoints or SOS waypoints such as W3 in Figure 5) may include storing network radio signal strength information (indicated as time-RSSI) for one or more time periods in a first table 632, and storing the location of a first mobile device (indicated as time-location) for one or more time periods in a second table 634. Shared storage 630 may be synchronized between a user's first mobile device 610 (e.g., a wristwatch) and a second mobile device 620 (e.g., a mobile phone).

[0098] In some embodiments, access to a second table 634 of secure storage 630 that stores location information for one or more time periods is accessible only by specific system routines, which can provide such information to the user only when certain criteria are met, for example, when the location type is such that the signal is likely to be lost, such as a non-urban location state. For example, if a user loses cellular connectivity at 1 p.m. in an urban location (e.g., San Francisco or 510 in Figure 5), the compass application launched by the user may not access the second table that stores location information. However, at 2:30 p.m., the user loses cellular connectivity again on a hiking trail (e.g., 540 in Figure 5). The location service (including a location state classifier 612) may enable the compass application launched by the user to access the second table 634 for location information by making an API request to retrieve the location information from the second table, for example, using a timestamp.

[0099] As shown in Figure 6, the first mobile device 610 can use the location service location state classifier 612 to determine whether to provide the user with a previous location (e.g., a cellular waypoint or an SOS waypoint). For example, the location state classifier 612 can determine whether the first mobile device is in a non-urban location state. In this way, location information may only be exposed when it is likely to be needed, for example, when the user has lost signal or needs to make an emergency call in a sparsely populated area. In such situations, the previous location may be retrieved based on the fact that the location (e.g., W3 in Figure 5) is in a non-urban location state. In other words, location information is tracked continuously and periodically, but access to location information may be restricted.

[0100] In addition to determining non-urban location status for accessing location information, the location service may, based on historical information, set limits (or thresholds) on how far back in time stored location information in secure storage 630 can be accessed. The access limit may be the earliest time the mobile device is considered to be in a non-urban location state. For example, continuing the above example, in Figure 5, a user of mobile device 530 on hiking trail 540 launches the compass application at 2:30 p.m. The location service may perform a check to determine whether the user is in a non-urban location state. The location service further checks the recorded historical information and finds that the user was driving on a cellular connection at 1:30 p.m. before waypoint W2 in Figure 5 (e.g., 522) and was in an urban location (e.g., waypoint W1 in Figure 5) at 1 p.m. As a result, the compass application may be allowed to access a second table 634 containing location information up to 1:30 p.m. (or up to waypoint W2 in Figure 5), because driving is a motion state that is considered unlikely to be in a non-urban location state.

[0101] Furthermore, after accessing secure storage 630, the compass application can display backtrack routes to waypoint positions with cellular connections (i.e., cellular waypoints) or SOS connections (SOS waypoints) (e.g., previous locations associated with the most recent waypoint or the nearest waypoint), but it will not display routes beyond that waypoint position due to restricted access to location information in the second table 634. For example, the route from point 540 in Figure 5 to waypoint W3 (route A) or W4 (route B) may be displayed, but the route from waypoint W3 to W2 may not be displayed. As a result, only a portion, rather than all, of the historical routes the user has traveled using their mobile device is displayed as needed.

[0102] In other words, the location service ensures two things when the compass application requests database access: firstly, the user is in a non-urban location state, and secondly, database access to location information is only available for the time period up to the point in time when the user's location state changes from urban to non-urban. In this way, location information is provided only when needed and in sufficient quantities for use, thereby reducing the possibility of such location information being misused.

[0103] In some embodiments, if a user reaches a previously recorded displayed waypoint position (e.g., W3) with a suitable signal strength (i.e., above a threshold), but the signal strength changes to a weaker level than previously recorded due to, for example, weather conditions, and the mobile device is still in a non-urban location state, an alternative backtrack route from W3 to W2' (or W2) may be displayed. In other words, the display of the backtrack route (and access to the location information in secure storage 630) may be performed in stages.

[0104] In further embodiments, all cellular / SOS waypoints within a non-urban location state can be displayed, but other waypoints during the transition between urban and non-urban locations are displayed sequentially (i.e., stepped display). For example, in Figure 5, waypoints W4, W3, and W2' may be displayed when the mobile device is in a non-urban location state (if it is determined to be in a non-urban location state). Waypoint W2 is not displayed until the user of the mobile device reaches the W2' waypoint position, as W2 is required due to a weak signal at W2'. Further details on backtrack route display are described below. 1. Location Status Classification

[0105] Location status classification refers to determining the location category to which a mobile device belongs (e.g., urban or non-urban). Location categories may be used as part of the aforementioned privacy protections.

[0106] In some embodiments, the location state classifier 612 can determine that a mobile device (e.g., a first mobile device 610) is in a non-urban location state by using one or more of the following methods: (1) The discoverability of network radio signals, such as intra-network signals, extra-network signals, or other types of radio signals including satellite signals and Wi-Fi signals, at the time waypoint information is requested or earlier, (2) One or more motion states of the first mobile device 610 at that time or earlier (e.g., walking, running, cycling, driving, standing still, etc.) (3) Classification of one or more map tiles in which the first mobile device 610 was located at that time or earlier. Map tiles may be generated by a tile-based mapping service that can retrieve map data and metadata for the geographic area around the mobile device based on GPS information.

[0107] For example, when the first mobile device 610 requests access to waypoint information stored in the shared storage 630, the location state classifier 612 may determine the location state of the first mobile device using network radio signals, motion status, map tiles, and one or more combinations of these pieces of information. As an example of location state determination, the detection of network radio signals, such as a Wi-Fi connection (e.g., 520 in Figure 5), may indicate that the mobile device is in an urban location state. However, in certain embodiments, if the network radio signal is uneven and as a result many waypoints are created at short distances, for example, if an additional waypoint W2' is created only one mile away from waypoint W2, the location at waypoint W2' may be determined to be in a non-urban location state. Therefore, network radio signals detected at or before the time the waypoint information is requested can help determine the location state of the mobile device.

[0108] As another example, motion states or classifications such as driving (e.g., 522 in Figure 5) are more likely to occur in urban locations, while walking, cycling, or running are more likely to occur in non-urban locations. The motion state immediately preceding the request for waypoint information can help determine the location state of the mobile device, as the user of the mobile device may have stopped that activity to make the request.

[0109] Furthermore, in another example, the classification of one or more map tiles in which a mobile device was located may indicate a non-urban location (e.g., 512) condition due to the absence of building structures (e.g., 504) or high altitude (e.g., 506) within the geographical area covered by the map tile(s) In some embodiments, map tiles may also include elevation information. In some embodiments, signal strength and motion status may be pre-calculated and incorporated into a tile-based mapping service to generate map tiles. C. Displaying Waypoint Positions and Backtrack Routes

[0110] As mentioned above, as part of backtracking, the backtrack route (or path) from the mobile device's current location (e.g., 540 in Figure 5) to the most recent (or last created) cellular / SOS waypoint (e.g., waypoint W3 on Route A in Figure 5) may be displayed on the requesting user's mobile device (e.g., 610 in Figure 6). Sometimes, the most recent waypoint is also the closest (or closest in distance) to the current location. At other times, the most recent waypoint and the closest waypoint may be different. For example, in Figure 5, if the user is traveling along a relatively straight line (e.g., Route A), the closest cellular waypoint and the most recent cellular waypoint are the same, which is waypoint W3. On the other hand, if the user is traveling along a winding road (e.g., Route B), the closest cellular waypoint (e.g., W3) and the most recent cellular waypoint (e.g., W4) may be different. In such a situation, multiple waypoints, each with a path to it (for example, both the nearest cellular waypoint and the latest cellular waypoint), may be displayed for the user of the mobile device 530 to select from, thereby helping the user choose an easier or faster route to reach the waypoint. In certain embodiments, the backtrack route may be displayed in three dimensions, including the elevation of the waypoints to show the terrain of the route.

[0111] In other embodiments, a set of previous locations (or waypoints) within a non-urban location state may be retrieved. The route between the current location (e.g., 540 in Figure 5) and a first cellular / SOS waypoint determined to be in a non-urban location state (e.g., suppose waypoint W2 is determined to be a non-urban location) may be displayed. Other waypoints (e.g., waypoints W2', W3, and W4) may be included in the displayed route.

[0112] Cellular / SOS waypoints can be displayed with an icon or text indicating that the waypoint was a previous location with an available network radio signal. Other previous locations considered to be urban locations will not be displayed, regardless of cellular connectivity.

[0113] A message may be sent after the first mobile device has reached a previous location (e.g., W3 or W4 in Figure 5) that has network connectivity (cellular or SOS). The message may be an emergency message. The emergency message may be an emergency phone call. D. Process flow for providing location information

[0114] Figure 7 is a flowchart of Method 700 for providing location information about when a network signal was last available, according to several embodiments. In some implementations, one or more method blocks of Method 700 may be executed by one or more processors of a first mobile device. Additionally or alternatively, one or more method blocks of Method 700 may be executed by one or more components of a mobile device, such as processor 1918 in Figure 19. The first mobile device may be a wearable device (e.g., a wristwatch).

[0115] In block 710, the strength of the network radio signal is monitored. Such monitoring can use the same module that measures the strength for display on a screen. Figure 6 shows bars corresponding to the network strength. The signal strength may be monitored using the signal received by the first mobile device 610, in the second mobile device 620, or both. Thus, the strength of the network radio signal may be monitored in the second mobile device which is communicating locally with the first mobile device (for example, paired via Bluetooth).

[0116] The network radio signal may be for cellular or SOS connectivity. In the case of SOS connectivity, the signal may be an in-network signal or an out-of-network signal (i.e., from a different carrier than the one the user of the first mobile device subscribes to). If in-network signals are available, cellular and SOS connectivity may overlap. In some embodiments, these two different signals may have locations that provide different icons or text to the user.

[0117] In block 720, the first previous location of the first mobile device is stored at a first previous time when the network radio signal strength exceeded a threshold. The first previous location can be measured using GPS. Storing the first previous location uses shared storage / database (e.g., 630 in Figure 6) between the first and second mobile devices. The first previous time may be the first time when a cellular or SOS waypoint (or first previous location) is created in a non-urban location state when the network radio signal changes from above to below the threshold. In other embodiments, the first previous time and the first previous location may be the time and location when a cellular / SOS waypoint (e.g., the most recent waypoint or the nearest waypoint) is created in a non-urban location state.

[0118] In some embodiments, as described above, signal strength (RSSI) may be stored in a first table (e.g., 632 in Figure 6), and location information may be stored in a second table (e.g., 634 in Figure 6) for privacy reasons. Access to the location information in the second table may be permitted only when certain criteria are met, such as being a non-urban location.

[0119] In block 730, a request is received to provide information about the first mobile device's previous network connections. For example, if a user of a mobile device wants to communicate (e.g., make a phone call or text message) but the network radio signal is unavailable, the user may launch an application such as a compass application or a map application, which automatically requests the location service to retrieve information about previous network connections, such as cellular waypoints or SOS waypoints.

[0120] In block 740, the first previous location is retrieved upon request. For example, if the location service determines, by the location state classifier 612, that the first mobile device is in a non-urban location state, it may access secure storage 630 to retrieve signal strength information from the first table 632 and location information from the second table 634. In some embodiments, a set of previous locations in a non-urban location state between the current location of the first mobile device and the first previous location (either a cellular waypoint or an SOS waypoint) may be retrieved.

[0121] In block 750, a first previous location is provided to the user of the first mobile device. For example, a compass or map application may display the route (or backtrack route) from the current location to the first previous location. For example, in Figure 5, the route from the current location (540) to the very first waypoint created in the non-urban location (e.g., W2 in Figure 5) may be displayed along with other waypoints in the route (e.g., W2' and W3, and / or W4).

[0122] In some embodiments, for privacy reasons, as described above, waypoints may be displayed incrementally by displaying the most recent (or nearest) waypoint. Other waypoints created before the most recent waypoint may not be displayed unless necessary. For example, in Figure 5, if the user has reached a displayed waypoint (e.g., W3 in Figure 5) but the signal strength at that waypoint has changed (e.g., weaker than previously observed), the location service may retrieve more location information from secure storage 630 so that the application can display the next cellular waypoint or SOS waypoint (e.g., W2 or W2' in Figure 5) if the mobile device is still in a non-urban location state.

[0123] Figure 8 is a flowchart illustrating a method 800 for providing privacy-protected location information according to several embodiments. Figure 8 illustrates further details in block 740 of Figure 7.

[0124] In block 810, it is determined whether the first mobile device is in a non-urban location state. As mentioned above, a non-urban location state may indicate a higher probability of network radio signal loss. Therefore, the user of the first mobile device needs to access the location information of the first mobile device.

[0125] If the first mobile device is in a non-urban location state in block 820, the process proceeds to block 830.

[0126] In block 830, the first previous location information is retrieved from a limited portion of the storage. For example, in Figure 5, waypoint W2 may be retrieved from a second table 634 in the secure storage 630 in Figure 6, which contains location information that requires certain criteria to be met, such as in a non-urban location state.

[0127] In block 840, restrictions (or thresholds) are imposed on accessing more location information that does not extend beyond the first prior time and enter a non-urban location state. As mentioned above, historical information (e.g., location information) that extends beyond a time considered not to be in a non-urban location state may be restricted for privacy reasons. For example, in Figure 5, information about waypoint W1 may be restricted because its relevant time is determined to be in an urban location state.

[0128] Returning to block 820, if the first mobile device is not in a non-urban location state, processing proceeds to block 860. In block 860, requests for access to secure storage for information outside of a non-urban location state may be rejected, and the corresponding waypoints cannot be displayed. In some embodiments, the location service may further request identification information (e.g., biometric data, passwords, etc.) from the requesting user for access in order to protect privacy. E. Accessibility of Waypoint Information and Backtracking Features

[0129] SOS / cellular waypoint and backtrack (e.g., displaying backtrack routes to waypoints) features can help mobile device users when they most need their mobile devices (e.g., wearable watches) in non-urban locations. Therefore, it is beneficial to make users aware of these features or to make them discoverable at the appropriate time and provide easy access when needed.

[0130] In some embodiments, if one or more SOS / cellular waypoints are available and the user is determined to be in a non-urban location, a prompt may appear on the mobile device asking if the user wishes to view the information. For example, if the user has attempted to make a phone call or send a text message but has failed, a notification or prompt may also appear asking if the user wishes to find available services (e.g., cellular waypoints). If the user responds to the prompt and requests the information, the backtrack route display process described above (e.g., Figure 7) follows.

[0131] In certain embodiments, for certain activities such as hiking, running, or skiing, the backtracking feature may automatically start at an appropriate time and prompt the user while the user is determined to be in a non-urban location.

[0132] In some embodiments, backtrack features can be started either manually or automatically. For example, if a user manually starts a backtrack feature before engaging in an activity, the backtrack feature may not stop unless the user stops it. However, if a backtrack feature is started automatically in a non-urban location as described above, the backtrack feature may automatically terminate if the user does not access the feature.

[0133] Finally, in certain embodiments, if a user turns on an application, such as an application running during a live activity (e.g., running, cycling), the compass application can become part of the smart stack, allowing for easy user access as needed. The smart stack is a set of widgets that automatically displays the most relevant widgets at the appropriate time of day, using information such as time, user location, and user activity. The user can access the compass app by turning the digital crown on a mobile device (e.g., a wearable watch) and use the backtrack feature. V. User interface for displaying the last known location of a network signal.

[0134] Figures 9A to 9Q show exemplary user interfaces for navigating between different views of location indications in several embodiments. These user interfaces are used to illustrate processes described later, including the process shown in Figure 10.

[0135] In Figure 9A, device 2000 displays a home screen user interface 902 containing multiple icons on the display 2001, and each icon, when activated (e.g., via tap input), causes device 2000 to display a user interface for its individual corresponding application. In Figure 9A, device 2000 detects a tap input 950A on the compass icon 902A corresponding to the compass application (e.g., via a touch-sensitive surface that is part of the display 2001). In response to detecting the tap input 950A on the compass icon 902A, device 2000 displays a high-visibility view 910 of the compass application, as shown in Figure 9B.

[0136] In Figure 9B, the high-visibility view 910 includes an arrow 910A, a text direction indicator 910B, and a numerical direction indicator 910C. The arrow 910A acts like a compass needle, pointing north and updating on the display as the device 2000 rotates so that the arrow 910A continues to point north. The text direction indicator 910B indicates the basic or intermediate direction (e.g., N, S, W, E, NE, SE, SW, and / or NW) that the device 2000 is pointing to (e.g., when the device is worn on the user's hand). The numerical direction indicator 910C indicates the degree of the number that the device 2000 is pointing to. The high-visibility view 910 does not include an indication of the device 2000's current location or any other location. In Figure 9B, the device 2000 detects the rotation 950B (e.g., clockwise rotation) of a rotating element 2032 (e.g., a rotatable input mechanism and / or crown). Upon detecting rotation 950B, device 2000 switches from displaying the high-visibility view 910 to displaying the hybrid view 912, as shown in Figure 9C.

[0137] In Figure 9C, the hybrid view 912 includes an arrow 912A, a text direction indicator 910B, a numerical direction indicator 910C, location indicators 920A-920E, the current elevation option 930, and backtrack affordances 2014. The hybrid view 912 includes many of the same features as those described above with respect to the navigation user interface 2002. The arrow 912A acts like a compass needle, pointing north and updating on the display as the device 2000 rotates so that the arrow 912A continues to point north. The text direction indicator 912B indicates the basic or intermediate direction (e.g., N, S, W, E, NE, SE, SW, and / or NW) that the device 2000 is pointing to (e.g., when the device is worn on the user's hand). The numerical direction indicator 912C indicates the degree of the number that the device 2000 is pointing to. Location indicators 920A–920E each correspond to a different location (e.g., a historical location where the user placed a waypoint marker, and / or a significant location (e.g., the last known cell service, and / or where the user's vehicle is parked)). In the hybrid view 912, location indicators 920A–920E are distributed around a circle, and each of these locations represents the direction in which a corresponding individual physical location (e.g., a campsite, the last known cell service location, and / or the user's vehicle) is located. Thus, the hybrid view 912 provides the user with information about the direction of various locations relative to the current location of device 2000, but it does not provide information about the distance to the various locations, nor does it provide information about the (absolute or relative) elevation of the various locations. The current elevation option 930 shows the current elevation of device 2000 relative to sea level (e.g., 85 feet above sea level). When activated, the backtrack affordance 2014 causes device 2000 to display information about the path device 2000 traversed to arrive at its current location (as described in more detail, for example, with respect to the historical location indicator 2028 above).When the new waypoint affordance 2058 is activated, it initiates the process of adding a new waypoint. In some embodiments, the device 2000 detects a tap input 950C on the current elevation option 930, and accordingly, the device 2000 displays the elevation view 916. In some embodiments, the device 2000 detects a rotation 950D (e.g., clockwise rotation) of a rotating element 2032 (e.g., a rotatable input mechanism and / or crown). In response to detecting the rotation 950D, the device 2000 transitions from displaying the hybrid view 912 to displaying the distance view 914, as shown in Figure 9D.

[0138] In some embodiments, the device 2000 detects user input (e.g., a two-finger tap and hold on the display 2001) (e.g., while displaying a high-visibility view 910, a hybrid view 912, a distance view 914, an elevation view 916, and / or a target navigation interface 2094), and accordingly outputs audio (e.g., spoken audio) including the current location of the device 2000, the current orientation of the device 2000, and / or direction of travel.

[0139] In Figure 9D, the distance view 914 includes arrow 912A, location indicators 920A-920E, the current elevation option 930, and backtrack affordance 2014. The distance view 914 includes many of the same features as those described above with respect to the navigation user interface 902. In the distance view 914, the positions of the location indicators 920A-920E indicate the direction and distance (e.g., from the current location of device 2000) to the location corresponding to the location indicators 920A-920E. In some embodiments, in the distance view 914, the positions of the location indicators 920A-920E indicate the direction and distance between the locations corresponding to the location indicators 920A-920E, as well as the direction and distance from the current location to the location. The current location indicator 932 represents the current location of device 2000. Thus, the distance view 914 provides the user with information regarding the distances and directions of the various locations represented by the location indicators 920A-920E, as well as the current location of device 2000. In the distance view 914, the positions of the location indicators 920A to 920E do not indicate the elevation of the location corresponding to the location indicators 920A to 920E (e.g., relative to sea level and / or the current elevation of device 2000). In some embodiments, as shown in Figure 9D, device 2000 detects a rotation 950E of a rotating element 2032 (e.g., a rotatable input mechanism and / or crown). In response to the detection of rotation 950E and the determination that the rotation is counterclockwise, device 2000 transitions from the display of the distance view 914 to the display of the hybrid view 912, as shown in Figure 9C. In response to the detection of rotation 950E and the determination that the rotation is clockwise, device 2000 changes the scale of the distance view 914 (e.g., zooms out).In some embodiments, as shown in Figure 9D, device 2000 detects a tap input 950F on the current elevation option 930, and accordingly, device 2000 transitions from displaying the distance view 914 to displaying the elevation view 916, as shown in Figure 9G.

[0140] As shown in Figure 9G, in some embodiments, the elevation view 916 is a simulated three-dimensional view and / or perspective view including location indicators 920A-920E. In the elevation view 916, the positions of the location indicators 920A-920E and the current location indication 932 indicate the elevation of the locations corresponding to the location indicators 920A-920E and the current location of the device 2000 (e.g., relative to the lowest elevation of the location and device 2000, relative to sea level, and / or relative to the current elevation of the device 2000). In addition, in the elevation view 916, the positions of the location indicators 920A-920E indicate the direction and distance between the locations corresponding to the location indicators 920A-920E, as well as the direction and distance from the current location to the location. Thus, the elevation view 916 provides the user with information regarding the distances, directions, and elevations of the various locations represented by the location indicators 920A-920E, as well as the current location of the device 2000.

[0141] In some embodiments, when transitioning from distance view 914 to elevation view 916, device 2000 displays an animation in which circle 934 is tilted to an oblique view to represent the base plane, as shown in Figures 9D to 9G. In some embodiments, when transitioning from distance view 914 to elevation view 916, device 2000 displays an animation in which each indicator (e.g., 920A and 920B) of locations within the area defined by (between) 936 is raised, and optionally, the current location indicator 932 is raised. In some embodiments, each indicator of a location and the current location indicator 932 are raised by a separate amount based on the elevation of the respective location corresponding to the indicator. For example, in Figure 9E, location indicators 920A and 920B rise by the same amount, while in Figures 9F to 9G, location indicator 920A stops rising and location indicator 920B continues to rise, indicating that location indicator 920B corresponds to a location at a higher elevation than the location corresponding to location indicator 920A. In some embodiments, the various location indicators rise at the same level but over different periods of time (and thus over different distances) based on the respective elevations of the locations corresponding to the various location indicators. In some embodiments, 934 represents a base plane having (equal) elevations based on the lowest elevation among the current location and the locations represented by the location indicators contained within the area defined by 936. In some embodiments, the elevation of each indication (e.g., 920A, 920B, and / or 932 in Figure 9G) (e.g., relative to sea level and / or another elevation) is represented by a line (e.g., a vertical line) extending from the base plane 934, the length of which is proportional to the elevation of the location corresponding to each indication (e.g., relative elevation).

[0142] In Figure 9G, in the elevation view 916, the device 2000 displays directional and distance information for the location corresponding to the location indicators 920C-920E without raising the location indicators 920C-920E to indicate the corresponding elevation information (for example, because the location indicators 920C-920E are not in the area defined by 936). In some embodiments, in Figure 9G, the device 2000 detects a tap input 950G on the current elevation option 930, and accordingly, the device 2000 transitions from displaying the elevation view 916 to displaying the distance view 914, as shown in Figure 9D (for example, reversing the animation from Figure 9D to Figure 9G). In some embodiments, the device 2000 detects a rotation 950H and accordingly changes the scale of the elevation view 916 (for example, zooming in or zooming out based on the direction of rotation). In some embodiments, by changing the scale of the elevation view 916, additional location indicators are displayed (for example, within an area defined by 936), and / or some location indicators are no longer displayed.

[0143] In Figure 9G, device 2000 detects a rotation 950I of device 2000, causing it to change from pointing northwest to pointing southeast. In response to detecting the rotation 950I of device 2000, device 2000 updates the positions of location indicators 920A-920E in elevation view 916, as shown in Figure 9I, by moving location indicators 920A and 920B outside the area defined by 936 and moving location indicator 920D inside the area defined by 936. As a result, as shown in the animation in Figures 9G-9I, device 2000 lowers location indicators 920A and 920B to the base plane 934 and optionally raises location indication 920D above the base plane 934 to represent the elevation of the location corresponding to location indication 920D. The base plane 934 represents the lowest of the elevations of the locations having indicators in the area defined by the current location and 936 (for example, in Figure 9H, the elevation of the base plane 934 corresponds to the lower of the elevation of the current location of device 2000 and the elevation of the location corresponding to location indication 920D). Thus, in some embodiments, the elevation of the base plane 934 changes when device 2000 rotates and / or when the scale of elevation view 916 changes.

[0144] In Figure 9I, since the elevation of the location indicator 920D has been newly displayed, the device 2000 displays a numerical indication 938 (e.g., "200 feet") of the elevation of the location corresponding to the location indicator 920D (e.g., sea level) on the display 2001 adjacent to 920D (for a predetermined time). In Figure 9J, after a predetermined amount of time, the device 2000 stops displaying the numerical indication 938. In Figure 9J, the device 2000 detects a tap input 950J on the backtrack affordance 2014. In response to detecting the tap input 950J on the backtrack affordance 2014, the device 2000 displays a path 940 showing the path the device 2000 traveled to arrive at the current location. As shown in Figure 9K, the location indicator 920D corresponds to the location where cellular service was last available, and the device 2000 automatically adds the location indicator 920D corresponding to the location where cellular service was last available as a waypoint, thereby allowing the user to backtrack to that location and make a phone call (e.g., an emergency call).

[0145] In Figure 9K, device 2000 detects a tap input 950K on the base plane 934 (and / or on the displayed location indicator (e.g., 920A)) and accordingly displays the waypoint menu 942 as shown in Figure 9L. In Figure 9L, the waypoint menu 942 includes a first option 942A corresponding to a waypoint (e.g., the last location of a cellular service, which has been automatically added by user selection) and a second option 942B corresponding to a nearby point of interest (e.g., within a threshold distance). In Figure 9L, device 2000 detects a tap input 950L on the first option 942A and accordingly displays a (e.g., scrollable) list 944 of locations (waypoints) corresponding to location indicators 920A-920E. In Figure 9M, the list 944 includes items 944A-944E. Device 2000 detects a tap input 950M on item 944A and, accordingly, displays a target navigation interface 2094 for navigating to the location corresponding to item 944A, as shown in Figure 9N.

[0146] In Figure 9N, device 2000 detects one or more inputs (including, for example, a tap input 950N on information object 946) and accordingly displays option 948 for setting an elevation alert, as shown in Figure 90. In Figure 90, device 2000 detects a tap input 950O on option 948 that displays the elevation setting user interface 960. In Figure 9P, device 2000 receives inputs 950P and 950Q for setting a target elevation of 300 feet. Device 2000 then monitors its current elevation. In Figure 9Q, device 2000 detects that it has reached (or crossed) the target elevation and accordingly outputs an alert 962 indicating that the target elevation has been reached.

[0147] Figure 10 is a flowchart illustrating how to transition between different views of location indication according to several embodiments. Method 1000 is performed in a computer system communicating with display generating components (e.g., 1100 and / or 2000) (e.g., smartwatches, smartphones, tablets, laptop computers, and / or head-mounted devices (e.g., head-mounted augmented reality devices)) (e.g., 2001) (e.g., display controllers, touch-sensitive display systems, monitors, and / or head-mounted display systems) and one or more input devices (e.g., 2001 and / or 2032) (e.g., touch-sensitive surfaces, keyboards, rotatable input mechanisms, and / or mice). Some operations of Method 1000 are optionally combined, the order of some operations is optionally changed, and some operations are optionally omitted.

[0148] As described below, Method 1000 provides an intuitive way to transition between different views of location indications. This method reduces the cognitive burden on users viewing location indications, thereby creating a more efficient human-machine interface. For battery-powered computing devices, it saves power and extends battery life by enabling users to browse location indications more quickly and efficiently.

[0149] The computer system (e.g., 2000) displays a first view (e.g., 914 in Figure 9D) (e.g., a two-dimensional view) via a display generation component (e.g., 2001) that simultaneously includes one or more indications of one or more locations (e.g., 920A-920E in Figure 9D) (e.g., indications of one or more historical locations where the computer system has been, and / or waypoint indications, and / or a first indication of a first location and a second indication of a second location) and an indication of the computer system's current location (e.g., 932 in Figure 9D) (1002).

[0150] The displayed relationships (1004) (e.g., distance between them and / or relative positions between them) in the first view (e.g., 914 in Figure 9D) between one or more indications (e.g., 920A-920E in Figure 9D) of one or more locations (e.g., location of a parked car, location of a trailhead, and / or location of a point of interest) and the indication of the current location (e.g., 932 in Figure 9D) correspond to the distance and relative position relationships (e.g., scaled based on and with them) between one or more locations (e.g., geographic location data, estimated (e.g., based on data from one sensor type (e.g., gyroscope or accelerometer sensor)) or actual (e.g., based on different sensor types (e.g., GPS sensor))) and the current location of the computer system (e.g., 2000), and do not correspond to the displayed relationships in the first view (e.g., 914 in Figure 9D) corresponding to the elevation relationships between one or more locations and the current location of the computer system. In some embodiments, the first view is a two-dimensional view including indications of various locations. The indications are arranged to show the relative distances between the various locations and the relative positions of the various positions of the locations relative to each other. In some embodiments, in the first view, the indications are not arranged to reflect / disclose the elevation of the various locations (e.g., absolute elevation or elevation relative to each other).

[0151] While displaying the first view (e.g., 914 in Figure 9D), the computer system (e.g., 2000) detects a first input (e.g., 950F and / or 950E) via one or more input devices (1006).

[0152] In response to detecting a first input (e.g., 950F and / or 950E), the computer system (e.g., 2000) transitions via a display generation component from displaying a first view (e.g., 914 in Figure 9D) to displaying a second view (e.g., 916 in Figure 9G) which simultaneously includes one or more indications of one or more locations (e.g., 920A-920E in Figure 9G) (e.g., indications of one or more historical locations the computer system has been and / or waypoint indications) and an indication of the computer system's current location (e.g., 932 in Figure 9G) (1008) (e.g., Figures 9D-9G).

[0153] The displayed relationships (1010) (e.g., distance between them, relative position between them, and elevation between them) in a second view (e.g., 916 in Figure 9G) between one or more indications of one or more locations (e.g., 920A-920E in Figure 9G) and the indication of the current location (e.g., 932 in Figure 9G) correspond to (e.g., based on and / or scaled with) the distance relationships, relative position relationships, and elevation relationships (e.g., based on location data (e.g., geographic location data, estimated (e.g., based on data from one sensor type (e.g., gyroscope or accelerometer sensor)) or actual (e.g., based on different sensor types (e.g., GPS sensor))) between one or more locations of the computer system and the current location. Displaying a second view including elevation relationships provides the user with visual feedback regarding the relative elevation between various locations, thereby providing improved visual feedback.

[0154] In some embodiments, transitioning from displaying a first view (e.g., 914 in Figure 9D) to a second view (e.g., 916 in Figure 9G) includes animating at least one of the following relative to a base plane (e.g., 934) (e.g., displayed or not displayed): one or more indications of one or more locations (e.g., 920A and 920B in Figures 9E-9G) and an indication of the computer system's current location (e.g., 932 in Figures 9E-9G) (e.g., raising location indication 920A and / or current location indication) (e.g., one or more indications of one or more locations and / or current location indication are located on the base plane while in the first view). In some embodiments, the first view is a two-dimensional view and the second view is a three-dimensional view (e.g., an oblique view). In some embodiments, the first view displays indicators for various locations (one or more locations and the current location) on a single plane, while the second view displays indicators for various locations on different planes (for example, the planes are based on the elevation of each location). In some embodiments, the animation from the first view to the second view includes indicators for various locations on their respective planes (based on elevation) above a base plane. Animating the indicators to rise to show their respective elevations provides the user with visual feedback that the placement of the indicators represents elevation, thereby providing improved visual feedback.

[0155] In some embodiments, the base plane (e.g., 934) represents the elevation, which is the lowest elevation of one or more locations and the current location. In some embodiments, if the current location has a lower elevation than one or more locations, the base plane represents the elevation of the current location, and the indication of the current location is represented on the base plane. In some embodiments, if a first location among one or more locations has a lower elevation than the current location (and one or more other locations), the base plane represents the elevation of the first location, and the indication of the first location is represented on the base plane (and the location of the current location is represented as being above the base plane). The base plane representing the lowest elevation among various locations allows the indications of all other locations to be displayed above the base plane and therefore not obscured by the base plane, thereby providing improved visual feedback.

[0156] In some embodiments, an animation (e.g., Figures 9D-9G) that raises individual indicators (e.g., 920A and / or 920B) (e.g., one indicator out of one or more indicators and / or the current location indicator) includes raising the individual indicators by an amount based on the difference between the elevation of the location corresponding to the individual indicator and the elevation represented by the base plane (e.g., 934). Raising each indicator above the base plane provides the user with visual feedback on how high the elevation of each corresponding location is, thereby providing improved feedback.

[0157] In some embodiments, the second view (e.g., 916 in Figure 9G) includes one or more indications of one or more locations (e.g., 920A-920B) and an indication of the computer system's current location, along with multiple other indications of multiple other locations (e.g., 920C-920E). In some embodiments, the displayed relationships in the second view between the multiple other indications of multiple other locations (e.g., distance, relative position, and elevation) correspond to distance and relative position relationships (e.g., scaled based on and / or with them) without the displayed relationships in the second view corresponding to elevation relationships between the multiple other indications. In some embodiments, the second view includes indications of multiple other locations that show the distance and relative position of the other locations, but do not show the relative elevation of the multiple locations. Displaying distance and directional relationship information for several points without showing elevation relationships for those points helps to avoid confusing the user interface, thereby allowing the user to better recognize elevation differences for points of interest and thus providing improved visual feedback.

[0158] In some embodiments, the computer system (e.g., 2000) detects the rotation of the computer system (e.g., 950I) (e.g., via a magnetometer) (e.g., detecting that the computer system has rotated relative to North). In response to detecting the rotation of the computer system, the computer system (e.g., 2000) raises the first individual indication of several other indications (e.g., 920D in Figures 9H to 9I) relative to the base plane (e.g., 934) (by animating the update of the second view) based on the altitude of the first individual location corresponding to the first individual indication, and the computer system (e.g., 2000) lowers the second individual indication of one or more indications (e.g., 920A in Figure 9H) relative to the base plane (e.g., 934) (by animating the update of the second view) regardless of the altitude of the second individual location corresponding to the second individual indication. In some embodiments, a directional indicator is displayed that overlaps a portion of the base plane, and indicators within the directional indicator are raised to indicate their altitude, while indicators not within the directional indicator are displayed on the base plane (without indicating their altitude). In some embodiments, the raising of indicators entering the directional indicator and the lowering of indicators leaving the directional indicator occur simultaneously. By rotating the device to show elevation for several indicators, the user can specify which points should show elevation, thereby providing the user with more control and improved feedback.

[0159] In some embodiments, in response to detecting a rotation (e.g., 950I) of the computer system (e.g., 2000), the computer system displays a text representation (e.g., 938 in Figure 9I) of the altitude (e.g., absolute amount, 300 feet, 350 feet, or 654 feet above sea level) of the first individual location over a certain period of time (e.g., a predetermined period of time) (e.g., before the display ends without requiring additional user input) via a display generation component (e.g., adjacent to the second individual indication). In some embodiments, the computer system temporarily displays the elevation in text next to the point where the direction indicator is entered (e.g., ascending). Temporarily displaying the elevation information in text next to the indication provides the user with accurate feedback regarding the elevation (e.g., above sea level) of the corresponding location, thereby providing improved visual feedback.

[0160] In some embodiments, the computer system (e.g., 2000) displays a text representation (e.g., 930) of the computer system's current elevation (e.g., 65 feet, 102 feet, or 322 feet above sea level) simultaneously with a first view (e.g., 912 in Figure 9C) via a display generation component (e.g., 2001). In some embodiments, the elevation of one or more locations is not displayed in the first view. Displaying the text of the computer system's current elevation provides the user with accurate feedback about the device's current elevation, thereby providing improved feedback.

[0161] In some embodiments, detecting a first input via one or more input devices includes detecting a touch input (e.g., 950C) (e.g., tap or tap-and-hold) at a location corresponding to a textual representation (e.g., 930) of the current elevation of the computer system. Displaying a second view including elevation relationships provides the user with visual feedback regarding relative elevations between various locations, thereby providing improved visual feedback.

[0162] In some embodiments, while displaying a second view (e.g., 916 in Figure 9G), the computer system (e.g., 2000) detects a second input (e.g., 950G) via one or more input devices (e.g., a tap input on the computer system's text representation of the current elevation). In response to the detection of the second input (e.g., 950G), the computer system (e.g., 2000) transitions from the second view (e.g., 916 in Figure 9G) to the first view (e.g., 914 in Figure 9D) (e.g., including an animation). Displaying the first view, which does not include elevation relationships, provides the user with a simplified view of the distances and positions of various locations, thereby providing improved visual feedback.

[0163] In some embodiments, before displaying a first view (e.g., 914 in Figure 9D), the computer system (e.g., 2000) displays a third view (e.g., 912 in Figure 9C) (e.g., a two-dimensional view) via a display generation component, which simultaneously includes one or more indications of one or more historical locations where the computer system has been, and / or waypoint indications, and / or a first indication of a first location and a second indication of a second location) and an indication of the computer system's current location. The displayed relationship in the third view between one or more indications of one or more locations (e.g., 920A-920E) and the indication of the current location (e.g., the distance between them and / or their relative positions) corresponds to (e.g., based on and / or scaled with) the relative position relationship between one or more locations and the current location of the computer system (e.g., based on location data (e.g., geographic location data, estimation (e.g., based on data from one sensor type (e.g., gyroscope or accelerometer sensor)) or actual (e.g., based on different sensor types (e.g., GPS sensor))) and does not involve a displayed relationship in the first view corresponding to the distance relationship and elevation relationship between one or more locations and the current location of the computer system. In some embodiments, the third view is a two-dimensional view containing indications of various locations. The indications are arranged to show the relative positions of the various positions of the locations relative to each other. In some embodiments, the third view is not arranged to reflect / disclose the distance and / or elevation between various locations (e.g., absolute elevation or elevation relative to each other). In some embodiments, the computer system receives user input (e.g., a tap input on the computer system's current elevation text representation) and transitions accordingly from the third view to the first view.Displaying a first view that does not include elevation and distance relationships provides users with a simplified view of the positions of various locations, thereby providing improved visual feedback.

[0164] In some embodiments, before displaying a third view (e.g., 912), the computer system (e.g., 2000) displays a fourth view (e.g., 910) (e.g., a two-dimensional view) via a display generation component, which includes the current orientation of the computer system (e.g., 2000) (e.g., 910A) but does not include one or more indications of one or more locations (e.g., indications of one or more historical locations the computer system has been, and / or waypoint indications, and / or a first indication of a first location and a second indication of a second location). In some embodiments, the fourth view does not include directional / distance / elevation relationships between various points / locations. In some embodiments, the computer system receives user input (e.g., tap input on a text representation of the computer system's current elevation and / or rotation on a rotatable input mechanism) and, accordingly, transitions from the fourth view to the third view. By indicating the current direction without showing its relationship to various locations, the user is provided with a simplified view of the computer system's orientation, thereby providing improved visual feedback.

[0165] In some embodiments, while displaying a second view (e.g., 916 in Figure 9K), the computer system (e.g., 2000) detects a set of one or more inputs via one or more input devices, including inputs (e.g., 950K, 950L, and / or 950M) directed to individual indications (e.g., tap inputs on them) corresponding to individual locations. In response to detecting inputs directed to individual indications, the computer system (e.g., 2000) displays, via a display generation component, the text distance from the current location to the individual location (e.g., 100 meters, 0.3 miles, and / or 1.21 miles) (e.g., 944A in Figure 9M), and the difference in text elevation between the current location and the individual location (e.g., 944A in Figure 9M) (e.g., 300 feet up, 33 feet up, or 120 feet down). In some embodiments, the computer system detects tap inputs on individual indications and, accordingly, displays a list corresponding to one or more indications. In response to the detection of tap input on individual items in a list corresponding to individual locations, the computer system displays text distance and text elevation. By allowing the user to select a specific location and view additional details about that location, the user is provided with additional feedback about that location, thereby providing improved feedback.

[0166] In some embodiments, the computer system (e.g., 2000) receives user input (e.g., 950O, 950P, and / or 950Q) to select a target elevation (e.g., as shown in Figure 9P). The computer system (e.g., 2000) detects that the computer system has reached the target elevation (e.g., the user wearing the computer system has hiked down or up to the target elevation). In response to the computer system (e.g., 2000) detecting that the target elevation has been reached, the computer system (e.g., 2000) outputs an alert (e.g., 960 in Figure 9P) (e.g., audio, visual, and / or tactile) indicating that the target elevation has been reached. Receiving an alert that the computer system has reached the target elevation provides the user with feedback regarding the computer system's elevation, thereby providing improved feedback.

[0167] In some embodiments, while displaying a second view (e.g., 916 in Figure 9K), a computer system (e.g., 2000) detects rotational input via a rotatable input device among one or more input devices. In response to detecting rotational input, the computer system changes the scale of the distance between one or more indications of one or more locations and the indication of the current location (and optionally, display the scale indication (e.g., on the base plane)). Changing the scale of the second view provides the user with additional feedback regarding additional locations and / or finer-grained feedback regarding fewer locations, thereby providing improved visual feedback.

[0168] In some embodiments, the computer system (e.g., 2000) detects that the computer system is no longer within the communication range of the computer system's cellular service provider. In response to detecting that the computer system is no longer within the communication range of the computer system's cellular service provider, the computer system adds an indication (e.g., 920D) as part of the first and / or second view corresponding to the last location where the computer system was within the communication range of the cellular service provider. In some embodiments, when the computer system moves out of the service provider's cellular connection range, the first and / or second view automatically indicate a point corresponding to the location of the last place where cellular connectivity was available (even if other service providers are available and within the computer system's communication range). Automatically indicating an indication corresponding to the last cellular connection (e.g., the device's cellular service provider) when out of cellular connection range provides the user with feedback on where to return to obtain cellular service (e.g., in an emergency).

[0169] In some embodiments, the computer system (e.g., 2000) detects that the computer system is no longer within the communication range of any cellular service provider. In response to detecting that the computer system is no longer within the communication range of any cellular service provider, the computer system (e.g., 2000) adds, as part of the first and / or second views, an indication (e.g., 920D) corresponding to the last location where the computer system was within the communication range of any cellular service provider. In some embodiments, when the computer system is outside the cellular connectivity range of all cellular service providers, the first and / or second views automatically indicate a point corresponding to the location of the last place where cellular connectivity (of any service provider) was available. Automatically indicating the last emergency cellular communication connection (e.g., of any cellular service provider working with the computer system) when out of cellular connectivity range provides the user with feedback on where to return to obtain cellular service (e.g., in an emergency). VI. High Alert

[0170] In some embodiments, a mobile device (e.g., a wearable device such as a phone or watch) can alert the user when the device reaches a set altitude (or elevation) threshold. This can be used in the following use cases: increasing pace to avoid altitude sickness, celebrating the moment of reaching a certain altitude, limiting fires or camping above a certain altitude, and limiting backcountry skiing below a certain altitude.

[0171] Mobile devices (such as phones or wearable devices like watches) can alert the user when the device reaches a target altitude, or when it is above or below the target. However, frequent and unwanted notifications can occur when the device moves up or down while close to the target altitude, or when the user accidentally raises or lowers their arm along with the device. A. Architecture

[0172] The disclosed technique reduces or prevents unwanted notifications by adding a programmable threshold amount of altitude around the monitored (or measured) altitude, thereby enabling and disabling notifications at appropriate times when the mobile device moves up and down while near the target altitude. The threshold amount around the monitored (or measured) altitude can be viewed as a band along the trajectory line of the monitored altitude.

[0173] Figures 11 and 12 below show altitude alerts triggered by vertical geofences whenever the target altitude is reached or crossed. Excessive and unnecessary alerts are shown. Figure 12 shows additional vertical geofence signal changes.

[0174] Figure 11 shows vertical geofencing at a target altitude and an alert when the target altitude is reached, according to several embodiments. Line 1110 shows the change in altitude over time. When the device's altitude reaches the target altitude 1101, an alert can be provided on the device's screen. Typically, when a user of a mobile device moves up a hill (or elevation increases) and down (or elevation decreases), that movement can be classified as crossing the target altitude or achieving the target altitude. Crossing the target altitude may include crossing in the upward direction 1126 and crossing in the downward direction 1120. Reaching the target altitude may include reaching the summit 1140 or reaching a valley (not shown, but similar in the opposite direction). When crossing the target altitude, the user typically wants an alert when the device reaches the target altitude. However, when the target altitude is reached, the orbital line may be above or below the target altitude, but still close to it, which can result in excessive and unnecessary alerts (e.g., 1122 and 1124).

[0175] Figure 12 shows vertical geofencing notifications in several embodiments when the user moves above and below the target altitude. The vertical geofencing signal 1202 changes with the monitored current altitude and can control the notifications (as described below). For vertical geofencing, the signal 1202 changes from true (or true / high) to false (or false / low) when the mobile device is below the target altitude (e.g., 1220 and 1224), and changes from false to true when the mobile device is above the target altitude (e.g., 1222 and 1226). B. Preventing unnecessary notifications

[0176] Figures 13 and 14 below illustrate the disclosed techniques for preventing unnecessary or excessive notifications during the achievement of a target altitude (e.g., a mountaintop or valley). A framework for utilizing the disclosed techniques is also shown in Figure 15.

[0177] Figure 13 shows a mechanism for preventing unwanted notifications according to several embodiments. Figure 13 shows a shaded band around the trajectory line. This band indicates that after an alert is triggered, no new alerts will be provided until the mobile device is at least a threshold amount away from the target altitude. In some embodiments, the threshold amount (i.e., the band) may be a programmable height (e.g., a few feet) set by the user or manufacturer of the mobile device. As seen at time 1324, no new alerts (notifications) are provided because the band does not leave the vertical geofence. That is, the altitude does not significantly (sufficiently) exceed the target altitude for the notification mechanism to reset.

[0178] Figure 14 illustrates a mechanism for preventing unwanted notifications using a vertical geofencing signal, according to several embodiments. As described above, the vertical geofencing signal 1402 changes with the monitored current altitude and can control notifications (e.g., a neutral state disables notifications, and a true or false state enables notifications). The vertical geofencing signal 1402 (e.g., acting as a control signal) may be reset after each notification (i.e., by disabling the notification) and will not start again (i.e., enable notifications) until the current altitude differs from the target altitude by a threshold. For example, when the mobile device falls below the target altitude at time 1420 (i.e., descends), the signal 1402 changes from true (or true / high state) to false (or false / low state), triggering notification 1460. The signal 1402 is then immediately reset (i.e., the notification is disabled and returns to the "initial" (or neutral) state). When the mobile device moves below the target altitude by exceeding a threshold amount (e.g., a band), the notification is re-enabled, for example, at time 1421, by returning signal 1402 to a false / low state.

[0179] At time 1422, signal 1402 changes from false to true as the mobile device rises above the target altitude, triggering notification 1462. Signal 1402 is then reset again (i.e., the notification is disabled). However, the trajectory around the summit 1440 is still within the threshold amount (e.g., the band). Thus, excessive, unnecessary alerts (e.g., 1424) can be avoided. The notification is not re-enabled until time 1425 when the mobile device moves below the target altitude beyond the threshold amount. At time 1426, the mobile device moves above the target altitude (i.e., crosses during ascent), and accordingly signal 1402 changes from false to true, followed by notification 1466.

[0180] In summary, signal 1402 can be reset each time a notification is triggered (e.g., 1420, 1422, and 1426) (i.e., the notification is disabled and returns to the “initial” (or neutral) state). The notification can be re-enabled by changing signal 1402 from the “initial” state to the “true” state (not shown) if the mobile exceeds the target altitude, or to the “false” state (e.g., 1421 and 1425) if the mobile falls below the target altitude, respectively, when the mobile exceeds or falls above the target altitude by a threshold amount (i.e., outside the band).

[0181] Figure 15 illustrates the operation of a framework for tracking and providing altitude notifications in several embodiments. The always-on processor (AOP) can use an altimeter to take measurements and compare the current altitude to a target altitude / elevation, including arbitrary upper and lower thresholds (as shown, for example, in Figure 14). The altimeter can correct itself for weather-related issues and provide compensation according to weather drift. C. Flowchart

[0182] Figure 16 is a flowchart showing how to trigger an alert at a target altitude according to several embodiments. In some implementations, one or more method blocks in Figure 16 may be executed by a mobile device (e.g., architecture 1500, electronic device 1700). In some implementations, one or more method blocks in Figure 16 may be executed by a separate device or group of devices, either separate from or including the mobile device. Additionally or alternatively, one or more method blocks in Figure 16 may be executed by one or more components of the mobile device, such as a computer-readable medium 1702, an input / output (I / O) subsystem 1706, a wireless circuit 1708, a sensor 1716, or an application processor 1718.

[0183] In block 1610, the target altitude is received and stored. The target altitude can be received from the user. For example, if the target altitude is stored in a wearable mobile device such as a wristwatch, the user may input the information into the wristwatch via a user interface such as voice commands, sliders, or typing. Alternatively, the target altitude can be input into a mobile device paired with the wristwatch, for example, via Bluetooth. The mobile phone can transmit the input information to the wristwatch.

[0184] In block 1620, the device's current altitude is monitored using an altimeter. The altimeter in the mobile device can measure the device's current altitude. For example, in Figure 14, the altimeter in the mobile device measures the device's current altitude at different points in time.

[0185] In block 1630, the current altitude (also called the measured altitude) is compared to the target altitude. For example, the two values ​​may be determined to be equal or different but within a threshold or tolerance. For example, as shown in Figure 14, the current measured altitude of the mobile device is determined to be equal to the target altitude 1401 at time 1422. However, at 1440 (summit), the measured altitude and the target altitude 1401 are different but within a threshold (e.g., the shaded band).

[0186] In block 1640, a notification is provided when the current altitude matches the target altitude. For example, in Figure 14, a notification is triggered or provided (i.e., signal 1402 changes from "false" to "true") when the current altitude of the mobile device matches the target altitude 1410 at time 1422.

[0187] In block 1650, the notification is disabled after notification 1640 has been provided. For example, in Figure 14, notification signal 1402 is reset to its "initial" state after the notification was triggered at time 1422.

[0188] In block 1660, the current altitude of the mobile device is continuously monitored. For example, in Figure 14, during the init state of the signal, the altimeter continues to monitor the current altitude of the device at times 1440 and 1424.

[0189] In block 1670, a notification is enabled when the current altitude differs from the target altitude by more than a threshold amount. For example, in Figure 14, if the current (or measured) altitude differs from the target altitude 1401 by a threshold amount (e.g., the shaded band) at time 1425, the notification feature is enabled by changing the notification signal 1402 from the "initial" state to the "false" state. VII. Exemplary Devices

[0190] Figure 17 is a block diagram of device example 1700, which may be a mobile device. Device 1700 generally includes a computer-readable medium 1702, a processing system 1704, an input / output (I / O) subsystem 1706, a wireless circuit 1708, and an audio circuit 1710 including a speaker 1750 and a microphone 1752. These components can be connected by one or more communication buses or signal lines 1703. Device 1700 can be any portable mobile device, including handheld computers, tablet computers, mobile phones, laptop computers, tablet devices, media players, personal digital assistants (PDAs), key fobs, car keys, access cards, multifunction devices, mobile phones, portable gaming devices, car display units, etc. (including combinations of two or more of these items).

[0191] The architecture shown in Figure 17 is merely one example of an architecture for device 1700, and it will be clear that device 1700 may have more or fewer components, or different configurations of components than those shown. The various components shown in Figure 17 may be implemented in hardware, software, or a combination of both hardware and software, including one or more signal processing and / or application-specific integrated circuits.

[0192] The wireless circuit 1708 is used to transmit and receive information to and from the conventional circuits of one or more other devices, such as an antenna system, an RF transceiver, one or more amplifiers, a tuner, one or more oscillators, a digital signal processor, a codec chipset, or memory, via a wireless link or network. The wireless circuit 1708 can use various protocols, such as those described herein.

[0193] The wireless circuit 1708 is coupled to the processing system 1704 via a peripheral device interface 1716. The interface 1716 may include conventional components to establish and maintain communication between the peripheral device and the processing system 1704. The wireless circuit 1708 transmits the received voice and data information (for example, in a speech recognition application or a voice command application) to one or more processors 1718 via the peripheral device interface 1716. The one or more processors 1718 can be configured to process various data formats for one or more application programs 1734 stored on the medium 1702.

[0194] The peripheral interface 1716 connects the input and output peripheral devices of the device to the processor 1718 and the computer-readable medium 1702. One or more processors 1718 communicate with the computer-readable medium 1702 via the controller 1720. The computer-readable medium 1702 can be any device or medium capable of storing code and / or data for use by one or more processors 1718. The medium 1702 may include a memory hierarchy including a cache, main memory, and auxiliary memory.

[0195] Device 1700 also includes a power system 1742 that supplies power to various hardware components. The power system 1742 may include a power management system, one or more power sources (e.g., a battery, alternating current (AC)), a recharge system, a power failure detection circuit, a power converter or inverter, a power status indicator (e.g., a light-emitting diode (LED)), and other components typically associated with the generation, management, and distribution of power in the mobile device.

[0196] In some embodiments, device 1700 includes a camera 1744. In some embodiments, device 1700 includes a sensor 1746. The sensor 1746 may include an accelerometer, compass, gyrometer, pressure sensor, sound sensor, light sensor, barometer, altimeter, etc. The sensor 1746 can be used to sense aspects of a location, such as an auditory signature or a light signature of the location.

[0197] In some embodiments, device 1700 may include a GPS receiver, sometimes referred to as a GPS unit 1748. The mobile device can obtain position information, timing information, altitude, or other navigation information using a satellite navigation system such as the Global Positioning System (GPS). During operation, the GPS unit can receive signals from GPS satellites orbiting the Earth. The GPS unit analyzes the signals to estimate travel time and distance. The GPS unit can determine the mobile device's current position (current location). Based on these estimates, the mobile device can determine its location lock, altitude, and / or current speed. Location lock can be geographic coordinates such as latitude and longitude information. In other embodiments, device 1700 may be configured to identify GLONASS signals or any other similar type of satellite navigation signal.

[0198] One or more processors 1718 execute various software components stored in the medium 1702 to perform various functions for the device 1700. In some embodiments, the software components include an operating system 1722, a communications module (or set of instructions) 1724, a location module (or set of instructions) 1726, a network coverage module 1728, a predictive app manager module 1730, and other applications (or sets of instructions) 1734 such as vehicle positioning and navigation applications.

[0199] Operating System 1722 can be any suitable operating system, including embedded operating systems such as iOS, MacOS, Darwin, RTXC, LINUX, UNIX, OS X, WINDOWS, or VxWorks. The operating system may include a set of procedures, instructions, software components, and / or drivers for controlling and managing common system tasks (e.g., memory management, storage device control, power management, etc.) and facilitating communication between various hardware and software components.

[0200] The communication module 1724 facilitates communication with other devices via one or more external ports 1736 or via the wireless circuit 1708, and includes various software components for handling data received from the wireless circuit 1708 and / or the external ports 1736. The external ports 1736 (e.g., USB, FireWire®, Lightning connector, 60-pin connector, etc.) are adapted to connect directly to other devices or indirectly via a network (e.g., the Internet, Wi-Fi, etc.).

[0201] The location / motion module 1726 can help determine the current position (e.g., coordinates or other geographic location identifiers) and movement of device 1700. Modern positioning systems include satellite-based positioning systems such as the Global Positioning System (GPS), cellular network positioning based on "cell IDs," and Wi-Fi positioning technology based on Wi-Fi networks. GPS can also determine position estimates based on the visibility of multiple satellites, but satellites may not be visible (or have weak signals) indoors or in "canyons of buildings." In some embodiments, the location / motion module 1726 receives data from the GPS unit 1748 and analyzes the signal to determine the current position of the mobile device. In some embodiments, the location / motion module 1726 can determine the current location using Wi-Fi or cellular location technology. For example, the location of the mobile device can be estimated using knowledge of nearby cell sites and / or Wi-Fi access points, and knowledge of their locations. Information identifying the Wi-Fi or cellular transmitter is received by the radio circuit 1708 and passed to the location / motion module 1726. In some embodiments, the location module receives one or more transmitter IDs. In some embodiments, a set of transmitter IDs can be compared with a reference database (e.g., a cell ID database, a Wi-Fi reference database), which maps or correlates the transmitter IDs to the position coordinates of the corresponding transmitters to calculate estimated position coordinates for device 1700 based on the position coordinates of the corresponding transmitters. Regardless of the specific location technology used, the location / motion module 1726 receives information from which the location fix can be derived, interprets that information, and returns location information such as geographic coordinates, latitude / longitude, or other location fix data.

[0202] The network coverage module 1728 may include various submodules or systems, for example, as described herein with respect to Figures 6-7. Furthermore, the advanced module (not shown) may include various submodules or systems, for example, as described herein with respect to Figures 11-16.

[0203] One or more application programs 1734 on a mobile device may include, without limitation, any applications installed on device 1700, including browsers, address books, contact lists, email, instant messaging, word processing, keyboard emulation, widgets, Java-enabled applications, encryption, digital rights management, speech recognition, voice duplication, and music players (for playing recorded music stored in one or more files such as MP3 or AAC files).

[0204] Other modules or instruction sets (not shown), such as a graphics module and a time module, may be present. For example, a graphics module may include various conventional software components for rendering, animating, and displaying graphic objects (including, but not limited to, text, web pages, icons, digital images, animations, etc.) on a display surface. In another example, a timer module may be a software timer. A timer module may also be implemented in hardware. A time module may maintain various timers for any number of events.

[0205] The I / O subsystem 1706 can be coupled to a display system (not shown). The display system can be a touch-sensitive display. The display system displays visual output to the user on a GUI. This visual output may include text, graphics, video, and any combination thereof. Some or all of the visual output may correspond to user interface objects. The display may use LED (light-emitting diode), LCD (liquid crystal display) technology, or LPD (polymer light-emitting display) technology, but other display technologies may be used in other embodiments.

[0206] In some embodiments, the I / O subsystem 1706 may include a display, as well as user input devices such as a keyboard, mouse, and / or trackpad. In some embodiments, the I / O subsystem 1706 may include a touch-sensitive display, which may also accept user input based on tactile and / or haptic touch. In some embodiments, the touch-sensitive display forms a touch-sensitive surface that accepts user input. The touch-sensitive display / touch-sensitive surface (together with any associated modules and / or instruction sets in medium 1702) detects contact (and any movement or release of contact) on the touch-sensitive display and translates the detected contact into interaction with user interface objects (e.g., one or more soft keys) that appear on the touchscreen when contact occurs. In some embodiments, the contact points between the touch-sensitive display and the user correspond to one or more of the user's fingers. The user may touch the touch-sensitive display using any suitable object or attachment such as a stylus, pen, or finger. The touch-sensitive display surface can detect contact and any movement or release using any suitable touch sensitivity technology, which includes capacitive, resistive, infrared, and surface acoustic wave technologies, as well as other elements for determining one or more contact points with other proximity sensor arrays or touch-sensitive displays.

[0207] Furthermore, the I / O subsystem can be coupled to one or more other physical control devices (not shown), such as push buttons, keys, switches, locker buttons, dials, slider switches, sticks, and LEDs, to control or perform various functions such as power control, speaker volume control, ringtone volume, keyboard input, scrolling, hold, menu, screen lock, and clearing and ending communications. In some embodiments, in addition to the touchscreen, the device 1700 may include a touchpad (not shown) for activating or deactivating specific functions. In some embodiments, the touchpad is a touch-sensitive area of ​​the device that, unlike the touchscreen, does not display a visual output. The touchpad may be a touch-sensitive surface separate from the touch-sensitive display, or an extension of the touch-sensitive surface formed by the touch-sensitive display.

[0208] In some embodiments, some or all of the operations described herein can be performed using applications running on a user's device. Circuits, logic modules, processors, and / or other components may be configured to perform the various operations described herein. Those skilled in the art will understand that such configurations can be achieved, depending on the implementation, through the design, setup, interconnection, and / or programming of specific components, and that, similarly, depending on the implementation, the configured components may or may not be reconfigurable for different operations. For example, a programmable processor can be configured by providing suitable executable code, and a dedicated logic circuit can be configured by suitably connecting logic gates and other circuit elements.

[0209] Any of the software components or functions described in this application may be implemented as software code to be executed by a processor, for example, using conventional or object-oriented techniques, in any suitable computer language such as Java, C, C++, C#, Objective-C, Swift, or scripting languages ​​such as Perl or Python. The software code may be stored as a series of instructions or commands on a computer-readable medium for storage and / or transmission. Suitable non-temporary computer-readable media include random access memory (RAM), read-only memory (ROM), magnetic media such as hard drives or floppy disks, optical media such as compact disks (CDs) or DVDs (digital versatile disks), flash memory, and the like. The computer-readable medium may be any combination of such storage devices or transmission devices.

[0210] Computer programs incorporating various features of this disclosure may be encoded on various computer-readable storage media, including optical storage media such as magnetic disks or tapes, compact discs (CDs) or digital versatile discs (DVDs), and flash memory. The computer-readable storage media encoded with the program code may be packaged with a compatible device or provided separately from other devices. In addition, the program code may be encoded and transmitted over wired optical networks and / or wireless networks compliant with various protocols, including the Internet, thus enabling distribution, for example, via Internet download. Any such computer-readable media may reside on or within a single computer product (e.g., a solid-state drive, hard drive, CD, or an entire computer system), or on or within different computer products within a system or network. The computer system may include a monitor, printer, or other suitable display that provides the user with any of the results described herein.

[0211] As described above, one aspect of the technology involves collecting and using data available from various sources to improve the expectation that users may be interested in communicating with it. This disclosure suggests that in some cases, such collected data may include personal information data that uniquely identifies a particular person, or personal information data that can be used to contact a particular person or locate them. Such personal information data may include demographic data, location-based data, telephone numbers, email addresses, Twitter IDs, home addresses, data or records relating to a user's health or fitness level (e.g., vital signs measurements, medication information, exercise information), birth dates, or any other identifying or personal information.

[0212] This disclosure acknowledges that the use of such personal data in the technology may be for the benefit of the user. For example, personal data may be used to predict which users may want to communicate with at a given time and place. Thus, the use of such personal data in contextual information enables predictions about people who may want to interact with a given user at a given time and place. Furthermore, other uses of personal data that benefit the user are also intended by this disclosure. For example, health and fitness data may be used to provide insights into a user's overall wellness or as positive feedback to individuals using the technology to pursue wellness goals.

[0213] This disclosure is intended to ensure that entities involved in the collection, analysis, disclosure, transmission, storage, or other use of such personal data comply with established privacy policies and / or privacy practices. Specifically, such entities should implement and consistently use privacy policies and practices that are generally recognized as meeting or exceeding industry or government requirements for keeping personal data confidential and secure. Such policies must be readily accessible to users and updated as data collection and / or use changes. Personal data from users should be collected for the lawful and legitimate use of the entity and should not be shared or sold for any other purpose. Furthermore, such collection / sharing should only occur after informing and obtaining the user's consent. In addition, such entities should consider taking all necessary steps to protect and secure access to such personal data and to ensure that others with access to personal data faithfully adhere to those privacy policies and procedures. Furthermore, such entities may undergo third-party evaluations to demonstrate their compliance with widely accepted privacy policies and practices. Furthermore, policies and practices should be adapted to the specific types of personal data collected and / or accessed, and should comply with applicable laws and standards, including jurisdiction-specific considerations. For example, in the United States, the collection or access to certain health data may be subject to federal and / or state laws, such as the Health Insurance Portability and Accountability Act (HIPAA). Health data in other countries, on the other hand, may be subject to other regulations and policies and should be addressed accordingly. Therefore, different privacy practices should be maintained in each country with respect to different types of personal data.

[0214] Notwithstanding the foregoing, the Disclosure also intends embodiments that allow a user to selectively prevent the use of or access to personal data. That is, the Disclosure intends that hardware and / or software elements may be provided to prevent or prevent access to such personal data. For example, in the case of a people-centered predictive service, the technology could be configured to allow a user to choose to “opt in” or “opt out” of participating in the collection of personal data during or at any time thereafter when registering for the service. In another example, a user may choose not to provide location information to a recipient suggestion service. In yet another embodiment, a user may choose not to provide precise location information but to allow the transfer of location zone information. In addition to providing “opt-in” and “opt-out” options, the Disclosure intends to provide notices regarding access to or use of personal data. For example, a user may be notified when downloading an app that will access their personal data, and then reminded again immediately before the app accesses the personal data.

[0215] Furthermore, the intent of this disclosure is that personal data should be managed and handled in a manner that minimizes the risk of unintentional or unauthorized access or use. Risks can be minimized by limiting data collection and deleting data when it is no longer needed. In addition, where applicable in certain health-related applications, data anonymization can be used to protect user privacy. Anonymization can be facilitated, where appropriate, by removing certain identifiers (e.g., birth dates), controlling the amount or specificity of data stored (e.g., collecting location data at the city level rather than the address level), controlling how data is stored (e.g., aggregating data across all users), and / or by other means.

[0216] Therefore, while this disclosure broadly covers the use of personal data to implement one or more different disclosed embodiments, it is also intended that these embodiments can be implemented without requiring access to such personal data. In other words, the various embodiments of the technology will not be rendered inoperable by the absence of all or part of such personal data. For example, it may be predicted for multiple users that a user wishes to communicate at a certain time and place based on a minimum amount of personal information, such as non-personal data or content requested by a device associated with the user, other available non-personal information, or publicly available information.

[0217] While this disclosure has been described in relation to specific embodiments, it should be understood that this disclosure is intended to extend to all modifications and equivalents within the scope of the following claims.

[0218] All patents, patent applications, publications, and descriptions referenced herein are incorporated in their entirety by reference for all purposes. Nothing is considered prior art. In the event of any conflict between this application and the references provided herein, this application shall prevail.

Claims

1. A method executed by one or more processors of a first mobile device, Monitoring the strength of the network wireless signal, The first previous location of the first mobile device at a first previous time when the intensity of the network wireless signal exceeded a threshold, Receiving a request to provide information about the previous network connection of the first mobile device, In response to the above request, retrieve the first previous location, Providing the first previous location to the user of the first mobile device, Methods that include...

2. Remembering the first previous location is The first table stores the strength information of the network wireless signal for one or more time periods, The method according to claim 1, further comprising storing the location of the first mobile device at one or more time intervals in a second table.

3. Determining that the first mobile device is in a non-urban location state, Based on the fact that the first previous location is in the state of a non-urban location, the first previous location is retrieved, The method according to claim 2, further comprising:

4. Retrieving a set of previous locations between the current location of the first mobile device and the first previous location, The first mobile device further includes displaying a route from the current location to the first previous location, wherein the route includes the set of previous locations. The method according to claim 3.

5. The method according to claim 3, wherein determining that the first mobile device is in the non-urban location state is done by using one or more of the following: the detectability of other network radio signals at an earlier time than the first prior time; one or more movement states of the first mobile device at the earlier time; and the classification of one or more map tiles in which the first mobile device was located at the earlier time.

6. The method according to claim 5, wherein the classification of one or more map tiles is whether or not the map tile is located within a city area.

7. The method according to claim 1, wherein the first prior location is measured using GPS.

8. The method according to claim 1, wherein the network wireless signal is an in-network signal, an out-of-network signal, or a satellite signal.

9. The method according to claim 1, wherein the intensity of the network wireless signal is monitored by a second mobile device that is communicating locally with the first mobile device.

10. The method according to claim 9, wherein storing the first previous location uses a shared database between the first mobile device and the second mobile device.

11. The method according to claim 1, wherein the network wireless signal is received by the first mobile device.

12. The first mobile device further includes sending a message after it has reached the first previous location, wherein the message is an urgent message. The method according to claim 1.

13. The method according to claim 12, wherein the emergency message is an emergency telephone call.

14. The method according to claim 1, wherein the first mobile device is a wearable device.

15. The method according to claim 14, wherein the wearable device is a wristwatch.

16. It is a mobile device, One or more processors, A mobile device comprising: a memory coupled to one or more processors, wherein the memory stores instructions, and the instructions cause the one or more processors to execute one or more of the operations described in claims 1 to 15.

17. A non-temporary computer-readable medium for storing multiple instructions, wherein, when the multiple instructions are executed by one or more processors of a mobile device, the one or more processors cause the one or more processors to perform one or more of the operations described in claims 1 to 15.

18. A method executed by one or more processors of a first mobile device, Receiving the target altitude, To monitor the current altitude of the first mobile device and To provide a first notification when the current altitude matches the target altitude, Disabling the notification after the first notification, The first mobile device continues to monitor the current altitude, If the current altitude differs from the target altitude by more than a threshold amount, the notification will be enabled. Methods that include...

19. The method according to claim 18, wherein the first notification is provided when the elevation of the first mobile device is reduced.

20. The method according to claim 18, wherein the first notification is provided when the elevation of the first mobile device increases.

21. The method according to claim 18, wherein receiving the target altitude includes the user inputting the target altitude to the first mobile device via a user interface.

22. The method of claim 18, wherein monitoring the current altitude of the first mobile device is done using an altimeter.

23. The method according to claim 18, wherein disabling the notification includes resetting the control signal to a neutral state.

24. The method according to claim 18, wherein enabling the notification includes setting a control signal to a high or low state.

25. The method according to claim 18, wherein the threshold amount is a programmable height.

26. It is a mobile device, One or more processors, A mobile device comprising: a memory coupled to one or more processors, wherein the memory stores instructions, and the instructions cause the one or more processors to perform one or more of the operations described in claims 18 to 25.

27. A non-temporary computer-readable medium for storing a plurality of instructions, wherein, when the plurality of instructions are executed by one or more processors of a mobile device, the one or more processors cause the one or more processors to perform one or more of the operations described in claims 18 to 25.

Images