Road point for last known network connectivity

Abstract

A waypoint may be automatically created by monitoring network wireless signal strength to assist a user of a mobile device in a non-city location in finding a previous location with known network connectivity and making an emergency call. In some embodiments, a backtracking route to a closest previous location with network connectivity is displayed on a mobile device. In some embodiments, for privacy considerations, access to waypoint information stored in a secure storage / database is restricted based on the determination of location status, and backtracking routes are displayed in stages.

Description

Cross-reference to related applications

[0001] This application claims the benefits and priority of U.S. Provisional Application No. 63 / 506,362, entitled “WAYPOINTS FOR LAST KNOWN NETWORK CONNECTIVITY,” filed June 5, 2023, and U.S. Non-Provisional Application No. 18 / 733,658, entitled “WAYPOINTS FOR LAST KNOWN NETWORK CONNECTIVITY,” filed June 4, 2024, the entire contents of which are incorporated herein by reference for all purposes. Background Technology

[0002] When in remote areas (e.g., while hiking), cell coverage may be lost. In the event of an emergency, a person may be unable to make an emergency call, such as to 911. It is desirable to provide users with information about the nearest location to make such an emergency call. Summary of the Invention

[0003] A system comprising one or more computers can be configured to perform a specific operation or action by means of software, firmware, hardware, or a combination thereof installed on the system, which, in operation, causes the system to perform that action. One or more computer programs can be configured to perform an action by means of instructions comprising instructions that, when executed by a data processing device, cause that device to perform a specific operation or action.

[0004] One general aspect includes a method executed by one or more processors of a first mobile device. The method further includes monitoring the strength of a network wireless signal. The method further includes storing a first previous location of the first mobile device at a first previous time when the strength of the network wireless signal is above a threshold. The method further includes receiving a request to provide information about the previous network connectivity of the first mobile device. The method further includes retrieving the first previous location in response to the request. The method further includes providing the first previous location to a user of the first mobile device. Other embodiments of this aspect include corresponding computer systems, devices, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the method.

[0005] Another general aspect includes a method executed by one or more processors of a first mobile device. The method further includes receiving a target altitude. The method further includes monitoring the current altitude of the first mobile device. The method further includes providing a first notification when the current altitude matches the target altitude. The method further includes disabling the notification after the first notification. The method further includes continuing to monitor the current altitude of the first mobile device. The method further includes enabling the notification when the difference between the current altitude and the target altitude exceeds a threshold amount.

[0006] These and other embodiments of this disclosure will be described in detail below. For example, other embodiments relate to systems, devices, and computer-readable media associated with the methods described herein.

[0007] The essence and advantages of the embodiments of this disclosure can be better understood by referring to the following detailed description and accompanying drawings. Attached Figure Description

[0008] Figure 1 It is a block diagram of the network operating environment for electronic devices according to the implementation plan.

[0009] Figure 2 This is a block diagram for location services based on the implementation plan.

[0010] Figures 3A to 3B A user interface for location services according to an implementation scheme is depicted.

[0011] Figure 4 This is a flowchart illustrating the location service method according to the implementation plan.

[0012] Figure 5 This is an example of a graph illustrating waypoints for backtracking based on some implementation schemes, where the network connectivity and backtracking are finally known.

[0013] Figure 6 A diagram is shown, according to some implementation schemes, for providing location information about when network signals were last available.

[0014] Figure 7 This is a flowchart illustrating a method for providing location information about when network signals were last available, according to some implementation schemes.

[0015] Figure 8 This is a flowchart illustrating a method for providing privacy-preserving location information according to some implementation schemes.

[0016] Figures 9A to 9Q An exemplary user interface for switching between different views of location indication is illustrated according to some implementations.

[0017] Figure 10 This is a flowchart illustrating a method for changing between different views indicating a location, according to some implementation schemes.

[0018] Figure 11 Examples of vertical geofencing at a target altitude (elevation) and alarms when the target altitude is reached are shown according to some implementation schemes.

[0019] Figure 12Examples of vertical geofence notifications are shown according to some implementation schemes when a user is moving above and below a target height.

[0020] Figure 13 Examples of mechanisms for preventing unwanted notifications are provided based on some implementation schemes.

[0021] Figure 14 An example is given of a mechanism, according to some implementation schemes, for using vertical geofence signals to prevent unwanted notifications.

[0022] Figure 15 The operation of a framework for tracking altitude and providing notifications, according to some implementation schemes, is illustrated.

[0023] Figure 16 This is a flowchart illustrating a method for triggering an alarm at a target altitude according to some implementation schemes.

[0024] Figure 17 This is a block diagram of an example device based on some implementation schemes, which may be a mobile device.

[0025] the term A waypoint is a midpoint or location on a user's route or path, defined by a set of coordinates (e.g., latitude and longitude, GPS points, etc.) to identify a point in physical space. Navigation applications can use the coordinates of waypoint locations to track and display the distance and orientation information of the waypoint location compared to the current location of the electronic device.

[0026] Orientation information provides compass direction from the electronic device's location to the waypoint location. In some implementations, orientation information is the horizontal angle between the waypoint location and the direction of travel of the electronic device, or the horizontal angle between the location determined by the electronic device and magnetic north or true north, depending on the specific implementation. For example, if a user is holding the electronic device pointing due north and is traveling due north with the device, and the waypoint location is directly behind the location pointed to by the electronic device, then the orientation will be south. Relative orientation refers to the angle between the direction of travel of the electronic device and the location of the waypoint location.

[0027] In some implementations, device context is a set of conditions that determine the location type (e.g., urban or remote) of the mobile device when these conditions are met. As an example, the location type can be determined using motion classification (e.g., driving, walking, stationary, etc.), wireless signal strength (e.g., Wi-Fi, cellular, Bluetooth, etc.) and quantity, and map tile category (e.g., whether a tile is classified as urban). Data can be analyzed to determine if a device context exists to trigger a change in location type. Detailed Implementation

[0028] In the following description, specific details are set forth for illustrative purposes to provide a thorough understanding of certain implementations. However, it will be apparent that various implementations can be practiced without these specific details. The accompanying drawings and descriptions are not intended to be limiting.

[0029] Location services can repeatedly request waypoint information, including but not limited to location and orientation information (e.g., GPS data, GPS points, etc.), over a period of time to aid in tracking and navigation to waypoint locations. In some implementations, the electronic device can provide the direction to the waypoint location, the travel trajectory to the waypoint location, and the distance to the waypoint location. For example, the electronic device can repeatedly request location information of its current location while the user is en route to continuously calculate the distance relative to the waypoint location. In another example, orientation information can be repeatedly calculated using the received location information.

[0030] In some implementations, two types of waypoint locations (also referred to as waypoints) can be created: cellular waypoints for tracking cellular connectivity and SOS waypoints for tracking SOS connectivity. Waypoint information may include the time and / or location when a mobile device (e.g., a wearable device such as a watch) or an accompanying device (e.g., a phone or tablet paired with the device) last had a network signal (e.g., a cellular signal or other wide area network signal). Signal reception can be tracked, for example, using the same module used to provide signal strength to a display on the mobile device or accompanying device. Signal strength can be monitored and saved periodically, possibly only saving the time and / or location when the signal strength drops below a threshold. Signal strength can be saved as a bit flag indicating whether the signal is above or below a threshold, or as a numerical value. Time and signal strength can 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 can be saved.

[0031] In some implementations, the location of a mobile device may be stored separately from time-based events related to network signal strength (e.g., in a first table or database) (e.g., in a second table or database). This location database may be stored in a secure storage device accessible only by certain system routines that provide such information to the user only when certain criteria are met (e.g., the location type is a type of location where signal loss is possible, such as in a non-urban location state).

[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 at the last available network wireless signal is provided only if the device is classified as being in a non-urban location state (e.g., rural state, remote area state, etc.). As an example, such a state (also known as location type) can be determined using motion classification (e.g., driving, walking, stationary, etc.), wireless signal (e.g., Wi-Fi, cellular, Bluetooth, etc.) and quantity, and map tile category (e.g., whether the tile is classified as urban). In some implementations, access to location information can be restricted to a specific time when the device was determined to still be in a non-urban location state, rather than the entire recorded history. In this way, information about the location is provided only when needed, thereby reducing the chance of potential misuse of such location information.

[0033] When a mobile device has a usable signal (i.e., a signal strength above a threshold), it can retrieve one or more previous locations. These locations can be displayed as waypoints on the device. For example, multiple locations can be retrieved if the user of the mobile device can reach an earlier location with a usable signal more easily or quickly, such as during a hiking trip. Waypoints can be displayed along with icons or text indicating that the waypoint points to a previous location with a usable signal. In some implementations, for privacy reasons, waypoints can be displayed in stages if the signal strength at a particular waypoint has changed when the mobile device reaches that waypoint.

[0034] In some implementations, more than one type of network signal can be monitored. For example, signals outside the network (e.g., any other carrier used by a mobile device) can be tracked because such other networks can still allow emergency calls. If in-network waypoints and out-of-network waypoints are close together (e.g., within a proximity threshold), only in-network waypoints can be displayed.

[0035] Waypoints (e.g., available signal waypoints) can be displayed in compass or map applications. Previous locations stored in a second database can be used to provide users with paths to trace back to the last known location using signals.

[0036] In some implementations, the current altitude of the mobile device can be monitored to trigger an alarm (or notification) when the device reaches a target altitude. Programmable threshold altitude values ​​can be added around the monitored altitude to reduce unwanted notifications by enabling and disabling notifications at appropriate times.

[0037] The embodiments disclosed herein offer several advantages. For example, instead of requiring users of mobile devices to manually create waypoints while traveling, automatically generated cellular / SOS waypoints are more accurate due to continuous monitoring of network wireless signal strength.

[0038] Furthermore, when mobile device users are in non-urban (or remote) locations, Wi-Fi signal strength can be crucial and potentially life-saving. Automatically generated cellular / SOS waypoints can also prevent mobile device users from being distracted while hiking in difficult or unfamiliar terrain.

[0039] Finally, privacy protections based on access to historical information about location status (e.g., restricted access to location information and time in secure storage / databases) and backtracking route display (e.g., single waypoints, multiple waypoints, or staged display of waypoints) address the issues when automatically tracking personal travel routes.

[0040] I. Network communication and location determination Electronic devices (e.g., mobile devices) may have locally accessible services, such as location services, or externally accessible services (e.g., telephone services, storage services, and device locator services) via a network connection (e.g., the Internet).

[0041] A. Network operating environment Figure 1 This is a block diagram of a network operating environment 100 for an electronic device according to an implementation scheme. The network operating environment 100 includes an electronic device 102, such as a mobile device. The mobile device can be any electronic device 102 capable of communicating via a wireless network and wireless accessory devices. Some examples of mobile devices include, but are not limited to, smartphones, tablets, laptops, wearable devices (e.g., smartwatches or other wearable computing accessories), mobile media players, personal digital assistants, and AirPods. ® EarPods ® PowerBeats ® AirTag ® Locator tags, earphones, head-mounted displays, health equipment, speakers, and other similar devices. In this implementation, the accessory device may be paired with electronic device 102. For example, the accessory device could be something like Apple AirPods. ® EarPods ® PowerBeats ® Fitness equipment, vehicles, bicycles, scooters, smart TVs, HomePod ® HomePod mini ® Devices such as automated auxiliary devices, home security systems, and / or any other mobile accessory devices.

[0042] Each electronic device in electronic device 102 may optionally include a user interface, such as user interface 104 of electronic device 102. In other embodiments, electronic device 102 may not have a user interface. Electronic device 102 may be a third-party device that utilizes an application programming interface to access device locator services. The third-party device may be provided by different device manufacturers or be part of a different ecosystem (e.g., operating system) of electronic device 102. Electronic device 102 may communicate via one or more wired and / or wireless networks 110 to perform data communication. For example, wireless network 112 (e.g., cellular network, Wi-Fi network) may communicate with wide area network 114 (such as the Internet) using gateway 116. Similarly, access device 118, such as a mobile hotspot wireless access device, may provide communication access to wide area network 114. Gateway 116 and access device 118 may then communicate with 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 wireless network 112 and / or access device 118. For example, electronic device 102 can make and receive telephone calls (e.g., using VoIP), send and receive email messages (e.g., using POP3), and retrieve electronic documents and / or streams, such as web pages, photos, and videos, via wireless network 112 (as shown with 120), gateway 116, and wide area network 114 (e.g., using TCP / IP or UDP protocols). In some implementations, electronic device 102 can make and receive telephone calls, send and receive email messages, and retrieve electronic documents via access device 118 and 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, where access device 118 is a personal computer. In this configuration, electronic device 102 may be referred to as a “tethered” device. In one implementation, electronic device 102 can communicate with accessory devices via a wireless peering connection. The wireless peering connection (not shown) can be used to synchronize data between devices.

[0044] Electronic device 102 can communicate with one or more services via one or more wired and / or wireless networks 110, such services as telephone service 130, instant messaging service 140, media service 150, storage service 160, and device locator service 170. For example, telephone service 130 enables telephone communication between electronic devices or between an electronic device and a wired telephone device. Telephone service 130 can route IP-based voice (VoIP) calls via wide area network 114 or can access a cellular voice network (e.g., wireless network 112). Instant messaging service 140 can provide, for example, email and / or other instant messaging services. Media service 150 can provide, for example, access to media files such as song files, audiobooks, movie files, video clips, and other media data. Storage service 160 can provide network storage capabilities to electronic device 102 to store documents and media files. Device locator service 170 enables users to locate lost or misplaced devices that are connected to one or more wired and / or wireless networks 110 at least at some point. Other services may also be provided, including software update services for updating operating system software or client software on electronic devices. In one implementation, instant messaging service 140, media service 150, storage service 160, and device locator service 170 may each be associated with a cloud service provider, wherein the various services are facilitated via a cloud service account associated with electronic device 102.

[0045] Electronic device 102 may have applications, services, application programming interfaces, and functions that are natively accessible on the device, including and / or utilizing location service 180. Electronic device 102 may provide one or more device locator applications 190 (e.g., a "Find My" application, a "Compass" application, a map application, etc.) to utilize device locator service 170 and location service 180 to locate accessory devices, provide map applications, and provide navigation applications. Navigation applications (e.g., a "Compass" application) help users navigate and trace back to historical locations along their routes. A navigation application is an application that uses any number of methods, including gyroscopes, magnetometers, and / or positioning systems (e.g., a GPS receiver), to display basic directions for navigation and geographic orientation. A map application is an application that uses maps delivered by a Geographic Information System (GIS). Route tracing can be a set of historical locations obtained within a time window that allows the user to trace their path.

[0046] Locally accessible data can be stored in defined locations, such as known locations 182 and secure, trusted locations 184. In some implementations, machine learning algorithm 186 can be used to classify locations, infer relationships between users and locations, provide path reconstruction, and / or distance estimation. In some implementations, machine learning algorithm 186 can be used to provide distance estimates for a set of features, including but not limited to location fixation of intermittently received paths and straightness measures of the location fixation set.

[0047] In some cases, machine learning algorithm 186 can be used to identify known locations 182 and / or trusted locations 184. By way of example, cluster data analysis can be used to identify, classify, and provide semantic labels for locations, such as locations frequently visited by a user. The secure, trusted location 184 can be explicitly specified or confirmed by the user of electronic device 102 after data analysis. In other cases, known locations 182 or trusted locations 184 can be classified offline and provided by 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 can be used, those skilled in the art will recognize that other algorithms can be used to identify potential known or trusted locations.

[0048] On-device heuristics and / or machine learning models can be used to infer relationships between users and locations based on analysis of locally stored data on frequently visited locations, including locations the user frequently visits, known locations, and / or any other locations. For example, frequently visited locations include homes, vehicles, workplaces, any location the user frequently visits with electronic devices (e.g., accessory devices and electronic device 102), and / or any other location designated by the user as a trusted location 184. Known locations 182 can be commercial locations, public spaces, parks, museums, and / or any other locations the user might frequently visit.

[0049] A defined location may have associated fence information that provides a set of conditions (if detected) allowing an electronic device to be specified or classified for at least a portion of the defined location relative to a region of physical space. For example, the fence information may provide conditions for classifying an electronic device as being inside or outside a region of physical space associated with the defined location. In another example, the fence information may provide conditions for classifying an electronic device as transitioning between being inside or outside a region of the defined location. The fence information may be a geofence with boundary information for the defined location, such as a point location and the extent of a region from that 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 (e.g., fingerprint data including radio frequency (RF) scan data such as Wi-Fi scan traces, etc.) that characterize a specific area of ​​the defined location. The fence information for a given defined location may be stored along with the location's classification type and any semantic labels assigned to the location. Boundary information may include a set of defined boundaries or radii around a point location to allow the creation of a fence for that location. In some implementations, a fence is a virtual perimeter of a real-world geographic area. The Global Positioning System (GPS) can be used to create virtual fences around a location and track the physical location of electronic device 102 within the geofence boundaries, as well as its entry into and exit from the bounded area. In some implementations, at least two layers of fences exist to reduce latency associated with traditional geofencing. For example, the choice of granularity of the established fence can be a factor in selecting a pattern to determine intent based on analysis of user context data. In some implementations, multiple fences can be used to refine the location information determined by a coarse-grained geofence.

[0050] Machine learning algorithm 186 may include on-device heuristics, machine learning algorithms, or combinations thereof to analyze and assign labels describing user context, such as location status. Location status can be a label representing user context (e.g., a set of conditions, motion classification) in which location information is obtained using specific positioning technologies and the resources of the electronic device. Location status can define the current location status and / or predictions of changes in the user's location status while carrying the electronic device. By proactively obtaining location information using technologies suitable for location status, latency in providing information to device applications is reduced without causing a significant degradation in electronic device performance that might be experienced under continuous requests for location information. For example, user context may indicate the movement or travel of the electronic device to allow the electronic device to be designated as having a motion classification, such as "on the way," "stationed," remaining in a specific defined location for a certain period of time, or any other defined motion classification. Analysis can be performed using various signals from contextual user data sources available to electronic device 102, including but not limited to: sensor data, location data, calendar data, transit card usage data, application data, historical data about travel patterns / routine, wireless connectivity status with accessory devices and / or services (e.g., Bluetooth connectivity status), device location history, and / or any other data accessible to electronic device 102. In an embodiment, the wireless connectivity status with various devices can indicate that the device is stationary or "on the way." For example, loss of connection with electrical appliances, security systems, heating / cooling systems, vehicles, other modes of transportation, and / or any other device can indicate that the electronic device is "on the way."

[0051] In some implementations, electronic device 102 can be categorized using the semantic label "stationed" after remaining within the geographic boundaries of a defined location (e.g., trusted location 184) for a defined period of time. In the example, received location data of electronic device 102 may indicate that electronic device 102 remains within the fenced boundaries of a specific location for a period of time (e.g., 5 minutes). Sensor data (such as accelerometer data) may indicate that electronic device 102 is stationary to support the inference that it is stationary. Application data may support the inference that electronic device 102 is stationary, such as the electronic device being at a calendar-appointed location. Application data indicating the type of application in use may also provide inference for a stationary device, such as using a media application. Historical data about a user's routines or patterns of travel may be used to determine whether electronic device 102 is stationary, such as a bedtime routine at home or a hotel location.

[0052] Electronic device 102 can be categorized as having an "on the way" label based on a user's previously detected behaviors, patterns, or routines, and this can be analyzed on electronic device 102. For example, a user may have a routine of working at approximately the same time each day, and if data on the device supports repeating this pattern, the "on the way" state can be assigned. The speed at which the electronic device moves or enters and leaves a known geographical area (e.g., using a fence) can allow inference that electronic device 102 is on the way. If electronic device 102 is detected accelerating within a known transportation area (e.g., on a road, highway, train route, etc.), electronic device 102 can be given a "on the way" motion classification. Similarly, if a transportation app / card is being used / applied to, electronic device 102 can be designated as "on the way."

[0053] Electronic device 102 can be classified as “threshold distance,” “approaching entry,” “approaching departure,” “entering,” and / or “leaving” of a corresponding location or set of locations based on the fence boundary of a specific location or set of locations and / or the pattern of sensor values ​​that characterize being in a location (such as Wi-Fi scan results characterizing being inside a location or transitioning to a location).

[0054] B. Location Services Figure 2 This is a block diagram for location services according to an implementation scheme. Location service 180 may include an event monitor module 264 (e.g., a fence event monitor, location status monitor, sensor monitor, etc.) that helps determine when power and performance modes should be adjusted to determine positioning and / or orientation information. Event monitor module 264 may rely on data from a contextual user data source to act as a cue for user context, and event monitor module 264 may use heuristics and / or machine learning algorithms 186 to determine the user context that triggers mode adjustment. In some implementations, user context and location status can determine the adjustment of power and performance modes performed on electronic device 102. The user's location status is being in a defined location or traveling between locations. By taking into account the user's location status and user context (e.g., information from motion sensors, application data), positioning and / or orientation information can be provided when the user is expected to need information.

[0055] In some implementations, the event monitor module 264 may use data to determine adjustments to power or performance modes that could affect the operation of the electronic device 102. For example, the user context of the electronic device 102 may include a designation of "on the way" using a motion classifier 280, and wireless connectivity status data indicating a loss of Bluetooth connectivity between the electronic device 102 and an accessory device such as a vehicle entertainment system. Continuing this example, the event monitor module 264 may determine from one or more contextual user data sources (e.g., motion classifier, wireless connectivity status) at least one indication that the location state and / or motion classification of the electronic device 102 will change, such as the electronic device 102 may be "on the way to a defined location" because the user is "on the way" and has lost Bluetooth connectivity to the vehicle entertainment system, therefore the user may have left the vehicle and is on their way to a 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 crossing fence boundaries, leaving a vehicle, leaving a transit point, user routines, sensor data, application data, etc.) may be analyzed to predict whether the electronic device is at a threshold distance from a defined location and whether the mode of the electronic device should be adjusted.

[0056] In the implementation, the event monitor module 264 can detect from user context data that the user is in a remote location (e.g., wilderness), on an unfamiliar route, and / or is unlikely to charge their device over an extended period of time. For example, various signals from the user context data can indicate that the user is unlikely to charge their device, such as application data instructing the user to track exercise, a map application with selected hiking routes for display, loss of cellular service, and / or any other data accessible on the device that provides context for the user's activities. In another example, the user can select a mode that indicates they will not be able to recharge the electronic device 102.

[0057] Access monitoring module 270 can utilize event monitoring module 264, fence information 290, and entry detection module 266 to accurately detect entry into a defined location and reduce the waiting time for providing location information by predicting that the user will request location data. When electronic device 102 is detected crossing a coarser-grained geofence boundary (as detected using entry detection module 266), access monitoring module 270 can retrieve fence information 290 to define a more precise boundary for the defined location. In another embodiment, access monitoring module 270 can retrieve expected sensor data (e.g., fingerprint data) characteristics of electronic device 102 with location status.

[0058] Proactive service 268 can be used to predict which apps and / or services a user might want to access given a user context, motion classification, and / or location status. For example, a user might want to access a specific app just before or when entering a location. Proactive service 268 can select apps based on the user's app selection history or suggest new apps associated with a specific, defined location.

[0059] In one implementation, electronic device 102 (with event monitor module 264) can detect a set of conditions that allow inference that a user can request a route retracing to allow them to turn back their steps, and electronic device 102 can initiate an extended power-saving mode to obtain location information without affecting the performance of electronic device 102. In another implementation, proactive service 268 can adjust the rate of periodic requests for determining location information. To handle the intermittent reception of location information, machine learning model 240 can be used to reconstruct the path from user-accessible data and estimate the distance of the path taken by the user.

[0060] In some implementations, map data accessed by map-making application 250 is used to estimate distances. The map application is an application that uses maps delivered by a Geographic Information System (GIS). Navigation application 220 can provide heading or orientation (e.g., degrees relative to magnetic north) information of electronic device 102 collected as the user moves, and averages the heading data to eliminate errors in the collected heading information caused by changes in heading measurements due to device movement (e.g., device impact, hand swinging when the device is worn on the user's wrist, etc.) as the user moves along their trajectory.

[0061] The proactive service 268 and event monitor module 264 may use a motion classifier 280, a density classifier 282, and a backtracking classifier 278. The motion classifier 280, trained on a feature set from data obtained using sensors of the electronic device, can provide information about whether the electronic device 102 is stationary or traveling with a user. While implementations are not limited to specific sensor types, specific sensor data representations, or specific features, this document describes exemplary sensors and features capable of distinguishing between specific movements within sensor data. The motion classifier can analyze the features provided from the sensor data using one or more models trained to perform identification of the type of motion 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 traveling in a specific transportation mode. The backtracking classifier 278 classifies the obtained historical location of the mobile device 102 as possible portions of the user's backtracking route for the electronic device 102.

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

[0063] II. Complex Function Blocks and Waypoints Location services in electronic devices (e.g., wearable devices) can be accessed through a user interface that includes complex function blocks that display information for the corresponding application. When certain complex function blocks (e.g., for navigation applications) are activated, waypoints can be displayed as icons.

[0064] Figure 3A A user interface 201 for location services according to an embodiment is depicted. The depicted user interface 104 is a smart watch face with location service complication blocks 203, 205, 207, and 209. A “complication block” is an object on the watch face that represents and displays application information but does not display time, such as date, weather information, atmospheric pressure, calendar information, navigation application 220, waypoints, etc. A particular complication block corresponds to a specific application (e.g., a navigation application) that can be executed on the device displaying the watch face. Complication blocks may be displayed within a specific “style window” of the watch face. A “style window” may correspond to a portion of the watch face designated as displaying a complication block. In some embodiments, the user can configure the watch face by determining which information to display in a specific style window (e.g., by selecting a watch application). As used herein, the term “enabled representation” refers to a user-interactive graphical user interface object that may optionally be displayed on the display screen of electronic device 102. For example, images (e.g., icons), buttons, and text (e.g., hyperlinks) may optionally each constitute an enabled representation.

[0065] As illustrated, complexity blocks 203, 205, and 207 are disabled, and the corresponding application (e.g., a navigation application 220 with waypoints) does not serve requests for disabled complexity blocks on electronic device 102. As illustrated, disabled complexity blocks 203, 205, and 207 can be grayed out with a specific shade to indicate that navigation application 220 does not serve requests for complexity blocks. Complexity blocks 203, 205, and 207 represent navigation application 220 and provide orientation information for waypoint positioning selected by the user when the corresponding capability representation for the complexity block is selected. For dynamic waypoint complexity blocks, a dialog box (e.g., a user interface) may be presented to the user to select the waypoint positioning of the complexity block to be displayed on the dial when activated. For static complexity blocks, waypoint positioning may have already been assigned to the complexity block, or the complexity block may be predefined, and navigation application 220 can provide orientation information for the corresponding waypoint. By way of example, predefined or default complexity blocks may be used for vehicle positioning and / or home location. In another example, a user can select waypoints that may have been defined during a hike, such as campsites and / or parks, and may want to select waypoints to find their return route. In yet another example, complexity block 209 is activated and uses navigation application 220 to display orientation information from true north to electronic device 102.

[0066] In some implementations, a complex function block can be activated by interacting with a power representation that represents the complex function block. For example, if the user selects a power representation... Figure 3A If the complex function block 203 for the "park" waypoint is enabled, then the navigation application 220 serves requests for waypoint information (e.g., the direction to the "park" waypoint 302 and the distance to waypoint 304 in the activated complex function block 301), and this information is displayed. Figure 3B In the activated complex function block 301, corresponding to Figure 3A The deactivated complex function block 203 in the system.

[0067] Figure 3B A user interface 300 for location services according to an implementation scheme is depicted. User interface 104 depicts activated complex function blocks: 301 (corresponding to...) Figure 3A The deactivated complex function blocks 203 and 304 (corresponding to) in the middle Figure 3A The deprecated complex function blocks 205), 209, and 306 (corresponding to) Figure 3A(207 in the example). In some implementations, the icons used for waypoints (such as the leaf icon 302, house icon 306, and sign icon 304 shown in the activated complex function block) are predefined (e.g., car icon for parked cars, house icon 306 for a user's home or campsite, leaf icon 301 for a park location, etc.) or assigned by the user (e.g., sign 304 with a specific color).

[0068] As shown in complexity block 301, navigation application 220 provides orientation information by displaying marker 302 within the complexity block to indicate how far to the right the waypoint location of "Park" waypoint 301 is from the user's current location. After activation of the complexity block, it can be updated with requested information over a first time period (e.g., every 15 minutes), but the frequency can be reduced or increased based on motion classification and / or transportation mode. For example, complexity blocks 304, 209, and 306 may be served by duty cycle requests operating over the first time period (e.g., every 15 minutes), and complexity block 301 may be served by requests occurring at a first time interval value (e.g., every 1 second) as the user moves toward the waypoint. In some embodiments, if the user selects an indication (e.g., long-presses on the screen) of complexity block 301, a user interface providing a target view of the waypoint can be provided, such as... Figure 4 As shown.

[0069] III. Backtracking The implementation described herein describes obtaining location information from a Global Navigation Satellite System (GNSS) such as the Global Positioning System (GPS) when one or more backtracking conditions are met. One or more backtracking conditions are a set of conditions that allow inference that the user is on an unfamiliar route, in the field, exercising, unable to recharge their device within an extended time period, and / or engaged in any other activity that may require backtracking of footprints along the route. Based on the observed set of backtracking conditions, a prediction is made that the user may need historical location information to be able to backtrack their footprints using the backtracking route and requests the electronic device to proactively obtain historical location information. The backtracking route can be a set of historical locations obtained within a review time window that allows the user to backtrack their footprints. The review window is a set of historical locations that may be needed within an immediate time period to backtrack the user's footprints while protecting user privacy from malicious actors seeking content outside of the most recent backtracking route. In some implementations, the review window of locations returned upon request is adjusted (e.g., truncated, clipped, etc.) to provide location information relevant only to the immediate need for backtracking the route.

[0070] The embodiments described herein provide a backtracking classifier that categorizes obtained historical locations as candidate or non-candidate locations in the user's backtracking route when requesting an electronic device. In one embodiment, historical locations are classified to find the most recent historical location from which a backtracking route may need to be started. Historical locations designated as part of the backtracking route can be provided to location services applications upon request to help users retrace their steps if they may be lost and / or request assistance in emergency situations.

[0071] Because non-stop or continuous collection of location information can deplete resources (e.g., battery, processor usage, etc.) when a user is unable to recharge their device (e.g., when in the wild or lost), electronic devices can obtain location information in a power-saving extended mode when one or more backtracking conditions are met.

[0072] In the implementation, one or more backtracking conditions may include, but are not limited to, the following: classification of movement en route (e.g., non-stationary), threshold time periods of no network access, classification of sparse environments (e.g., population density or low density of man-made structures in the area), and threshold distances from frequently visited locations and / or locations as part of a user routine. While specific categories of conditions are provided, those skilled in the art will recognize that any additional user contextual data may supplement and / or form the basis for inferences that a user will request historical location information for backtracking.

[0073] Figure 4 This is a flowchart 400 illustrating a backtracking method according to an implementation scheme. Electronic device 102 detects one or more backtracking conditions (401) that trigger a review time window for the collection of a set of historical locations. These one or more backtracking conditions are a set of conditions determined by analyzing user contextual information, which allows inference that the user may need to backtrack historical location information (e.g., in the wilderness and / or in unfamiliar areas). Electronic device 102 predicts, based on one or more backtracking conditions, that the user might want historical location information to allow backtracking (e.g., tracing routes) in navigation applications and / or mapping applications. In some implementations, the detected one or more backtracking conditions are a subset of conditions that can be determined based on analysis of accessible user contextual data, as indicated in extended mode in Figure 3. While a specific method for collecting historical locations has been described, any specific implementation for collecting historical locations can be used to practice a set of conditions for inferring that a user is lost before the collection of historical locations, and a subsequent review of these conditions before responding to a request for historical locations.

[0074] User contextual data can supplement backtracking conditions to provide a basis for decision-making regarding initiating extended patterns and obtaining location information. In one implementation, one or more backtracking conditions may include, but are not limited to, the following: classification of movement en route (e.g., non-stationary), threshold time periods without network access, sparse environment classification (e.g., low population density or low density of man-made structures in the area), and a threshold distance exceeding a frequently visited location and / or a location as part of a user routine. While specific categories of conditions are provided, those skilled in the art will recognize that any additional user contextual data can supplement and / or form the basis for inference that a user will request historical location information for backtracking.

[0075] If electronic device 102 receives a motion classification of non-stationary and / or "on the way," then the motion type classification condition is met. In one embodiment, the motion type classification condition is met if the mode of transport is human-powered (e.g., walking, cycling, skateboarding, etc.) or motor-assisted vehicle (e.g., motor-assisted bicycle) rather than motorized vehicle or automobile (e.g., car, airplane, electric vehicle). A motion classifier 280, trained on a feature set from data obtained using sensors of the electronic device, can provide information about whether electronic device 102 is stationary or on the way, including the mode of transport. In some embodiments, the motion classification can indicate an inference about the user's activity or mode of transport while on the way, including but not limited to: walking, on a bicycle, on fitness equipment, on a scooter, on a skateboard, inside a vehicle, on an airplane, on a vehicle, on a train, on a subway, human-powered vehicle, motor-assisted vehicle, electric-assisted vehicle, automobile, and / or any other motion classification.

[0076] If electronic device 102 is not within communication range of a wireless access point (e.g., internet access, WiFi, cellular network access point, etc.) in a geographic area, or if the geographic area has a relatively low access point density compared to a defined access point density threshold, then the network access backtracking condition is met. Electronic device 120 may, for example, perform one or more wireless surveys to detect the presence of wireless access points in the geographic area while the device is en route for a period of time. For example, electronic device 120 may continuously, periodically, or intermittently search for wireless signals transmitted using one or more frequency bands specified for wireless communication. If the number of access points observed during this period is lower than a defined access point density threshold, then the network access backtracking condition is met.

[0077] Electronic device 102 determines whether an environment type backtracking condition is met by classifying a geographic region as having sparse structure density within the geographic region using density classifier 282. Density classifier 282, trained on a feature set from data obtained using sensors of the electronic device, can provide information about whether the electronic device 102 is in a dense or sparse geographic region regarding wireless access point density, radio frequency signal (e.g., Bluetooth, UWB, etc.) density information, and map data about density and landscape. In some embodiments, the density of wireless access points in a region is a feature provided in the classification of structure density for the geographic region. For example, if a large number of different wireless access points exist in each region, there is a higher probability of a dense urban environment. As another example, the time span recorded between observations of wireless access points can be a feature provided to density classifier 282 and act as an indicator of a sparse environment. In some embodiments, a map tile service can provide electronic device 102 with a tile-based mapping service that enables electronic device 102 to retrieve map data and metadata for a geographic region of electronic device 102 or the region that electronic device 102 is searching for. Map tile metadata can be retrieved from a remote map tile database or a local (e.g., cached) subset of a map tile database. Metadata may include the classification of the current map tile or sub-tile. Map tile metadata may also include digital elevation model (DEM) data, which indicates a surface model including the structure of the geographic area used for estimation and may be features used for density classifier 282.

[0078] Next, if the electronic device 102 is more than a threshold distance from its usual location, a location that is part of a user routine, a safe or trusted location, the backtracking conditions that are met can be analyzed to determine whether sufficient conditions are met to continue to actively obtain historical location information.

[0079] If sufficient backtracking conditions are met, electronic device 102 receives at least one historical location from a set of historical locations within the review period (402). Although described with reference to the classification of a single historical location, those skilled in the art will recognize that multiple historical locations can be classified to determine the review window of historical locations included in the backtracking route.

[0080] Electronic devices may classify at least one historical location as a candidate location for route retracement based on one or more features (e.g., signals) observed during the collection of historical locations (e.g., duration of the review window, no location exceeding 250 km, no previous location in a vehicle, etc.). Features considered when classifying historical locations include, but are not limited to, the following: duration included in the review window, distance from frequently visited, safe and / or trusted locations, location information collected before and after entering a motor vehicle (e.g., car, airplane, etc.) and / or electric vehicle, structural density classification (e.g., urban area, etc.), access point density, motion classification, transportation mode classification, user activity (e.g., hiking events from calendar data), and / or any other features that may indicate the user may need to retrace a route.

[0081] For example, the most recent historical location considered a candidate for a review window may not be as far back as the maximum duration from the current time. Similarly, historical locations greater than the maximum distance from the current location may be excluded from consideration as candidates for a review window. Location information acquired during flight and / or other journeys within the vehicle may be truncated from the review window and not considered as candidates for a review window. In some implementations, historical locations not exceeding a trusted threshold distance may be truncated from the review window unless the user requests recording of historical locations near frequently visited and / or secure and trusted locations. Access point density and structure density classification indicators of the user's possible urban locations may allow truncating of review windows with associated locations. The described features are examples, and the backtracking classifier 278 may or may not use any of the described features to determine the review window.

[0082] Electronic device 102 determines whether to provide at least one historical location as part of a review window based on classification (404). In one embodiment, the classification of historical locations in the review window begins with historical locations previously classified in the review window, and classification continues until the most recent candidate is identified. Historical locations prior to the most recently classified candidate can be cleared. By selectively providing historical locations when conditions indicate that the user is lost, malicious actors are prevented from accessing and / or causing exposure of the user's previous location, which could be contrary to the user's own interests.

[0083] In some implementations, the application requesting access to the review window must have permission. This permission identifies the application as having the right or privilege to access location information. Instead of requiring the user to make repeated efforts to obtain historical location information, the review window location information can be provided opportunistically if the user requests access to historical location information via an application.

[0084] IV. Track the last known location of the network signal The implementation described herein illustrates an automated waypoint system for tracing the last known location using wireless network signals. The time and location information associated with these waypoints can be stored in a secure storage device / database with privacy protection. When a user of a mobile device in a non-urban location launches a navigation application (e.g., a compass app or map app), a route back to one or more of these waypoints can be displayed on the mobile device.

[0085] Figure 5 This is an example of a graph illustrating waypoints for backtracking based on some implementation schemes, where the network connectivity and backtracking are finally known. Figure 5 Urban location 510 and non-urban location 512 are illustrated. Urban locations may have numerous buildings, network wireless signals (e.g., cellular connectivity and Wi-Fi), and motorized vehicle activity. Non-urban locations may be remote areas with few buildings, unstable network wireless signals, and human activity (e.g., cycling, running, hiking). A user of mobile device 530 can travel from urban location 510 to non-urban location 512 via rural road 514 with several rest stops (e.g., 520).

[0086] exist Figure 5 In this process, several waypoints (e.g., W1, W2, W3, and W4) can be marked along the path traveled by the user on mobile device 530. For example, waypoint W1 is located just outside urban location 510 and may have cellular connectivity. W2 is after rest location 520, where there is Wi-Fi signal. W3 and W4 are within non-urban location 512. W2' may or may not exist during the transition from urban to non-urban location. Waypoint W4 can be created if the user takes route B instead of route A. Further details regarding waypoint creation are described below.

[0087] When a user of mobile device 530 in a specific non-urban location 540 attempts to communicate (e.g., make a phone call or text message) but no network wireless signal is available, the technology or implementation disclosed in this disclosure can allow the user to locate back to the last known location with network connectivity (e.g., Figure 5The path (W3 or W4) of the network connection has sufficient wireless signal strength (e.g., cellular internet connection or SOS connection) for transmitting emergency messages or making emergency calls. In some implementations, the user can launch an application, such as a compass app or map app, on the user's mobile device (e.g., mobile phone, watch, or companion device). The launched app can access a secure database (or storage device) and determine whether the user has permission to access certain waypoint information (e.g., historical information related to time, location, signal strength, signal type, etc.) based on the user's status (e.g., non-urban location status), and then display a backtracking path from the current location to a previous location (i.e., a waypoint) with sufficient wireless signal strength (e.g., above a threshold) for communication.

[0088] A. Waypoint Creation As discussed above, waypoints can be automatically created for tracing the last known location using wireless network signals. In some implementations, the techniques disclosed in this disclosure can automatically create two types of system waypoints: cellular waypoints for tracing cellular connectivity and SOS waypoints for tracing SOS connectivity. SOS is the common name for the international Morse code distress signal. SOS connectivity can refer to a network wireless signal that allows a user to send an emergency message or make an emergency telephone call. Network wireless signals used for SOS purposes can include, but are not limited to, signals within the network provided by the user's subscribed wireless operator, signals outside the network provided by other wireless operators, and satellite signals. In some countries, such as the United States, Canada, and Australia, users can make cross-operator emergency calls. On the other hand, cellular connectivity typically refers to signals within the network provided by the user's subscribed wireless operator.

[0089] In some implementations, mobile devices employing the disclosed technology can track all types of network wireless signals and automatically determine which type of waypoint to create, and create it accordingly. For example, a cellular waypoint is automatically created when the cellular signal strength within the network falls below a threshold. An SOS waypoint is automatically created when the signal strength outside the network and / or satellite signal strength drops below a threshold.

[0090] In some implementations, signal reception of both types of network wireless signals (cellular and SOS) is continuously monitored and tracked, including their strength. Signal strength 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 strength can be stored as one, two, or three bars. In another example, signal strength can be stored as the numerical values ​​1, 2, or 3.

[0091] Whenever the signal strength drops below a threshold (e.g., two bars or a value of 2), location services can create waypoints (cellular waypoints or SOS waypoints) along the user's path, such as... Figure 5 Waypoints W1 through W4. In other words, waypoints indicate that the cellular or SOS network wireless signal might be above a communication threshold just before a marked location on the path. For example, a user of a mobile device might be hiking on a mountain trail with cellular connectivity. At a point, the signal strength of the wireless signal within the user's network drops below two bars, and the user's mobile device can automatically generate cellular waypoints along the user's hiking trail path (e.g., ...). Figure 5 Waypoint W3). When a user wants to make a phone call but finds no signal available or the signal is too weak, the user can launch the application to find a path back to the cellular waypoint with sufficient signal strength. On the other hand, if the signal strength returns or recovers above the threshold, no waypoint is created because the user does not need to use the waypoint feature and can communicate using only the mobile device. In some implementations, several cellular or SOS waypoints may be created when the signal strength drops and recovers more than once.

[0092] B. Waypoint Information Database and Privacy As previously mentioned, waypoint-related information can be stored in a secure storage device / database with privacy protection. As part of the privacy protection, time and location information can be stored separately, and the location status of the mobile device (e.g., urban or non-urban) can be determined for the purpose of information access and display.

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

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

[0095] In addition to signal strength, the shared secure storage device (or shared database) may also contain other waypoint information, including but not limited to time, location, signal strength, cellular status (e.g., connected, disconnected, roaming, airplane mode), motion classification (e.g., driving, running, walking, stationary, etc.), sequence or order of events (e.g., driving then walking, or intranet connection followed by extranet connection), network radio signal type (e.g., cellular or SOS), map tile category, and altitude, but Figure 6 Only signal strength and location information are shown. Waypoint information can be stored for a period of time (e.g., from one week to one month) before new information can overwrite previously saved old information.

[0096] In some implementations, one mobile device can store waypoint information in and retrieve waypoint information from the shared storage device, while another mobile device can only store waypoint information in the shared storage device. For example, in Figure 6 In this configuration, the first mobile device 610 can be a wearable device, such as a watch, and can store signal strength and location information in a shared storage device 630, and retrieve the stored location information for analysis and use by the location state classifier 612. The second mobile device 620 can be a mobile phone or a companion device to the first mobile device 610. When the first mobile device 610 has a weak signal or lacks power, the second mobile device can also store signal strength and location information in the shared storage device 630.

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

[0098] In some implementations, access to the second table 634 of the secure storage device 630, which stores location information once or multiple times, is only available through certain system routines that can provide such information to the user only when certain criteria are met (e.g., the location type is a type where signal loss is possible, such as in a non-urban location state). As an example, if the user is in an urban location (e.g., San Francisco or...), Figure 5 If a user loses cellular connectivity at 1 PM, the compass app launched by the user may be unable to access the second table storing location information. However, if the user loses cellular connectivity again at 2:30 PM while on a hiking trail (e.g., ...), Figure 5 (540). The location service (including the location status classifier 612) may allow a compass application initiated by the user to access the second table 634 to obtain location information, for example, by using a timestamp to make an API request to retrieve location information from the second table.

[0099] like Figure 6 As shown, the first mobile device 610 can use the location state classifier 612 of the location service to determine whether to provide the user with a previous location (e.g., cellular waypoint or 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 can only be exposed when necessary; for example, when a user needs to make an emergency call in an area with lost or sparse signal. In this case, it can be based on location (e.g., Figure 5 W3) is a non-urban location status used to retrieve previous locations. In other words, location information is tracked continuously and periodically, but access to location information may be limited.

[0100] In addition to determining the non-urban location status used to access location information, the location service can set restrictions (or thresholds) on how far in time the location information stored in the secure storage device 630 can be accessed, based on historical information. The access restriction could be the earliest time when the mobile device is considered to be in a non-urban location status. For example, continuing the example above, in Figure 5In this scenario, when a user on mobile device 530 on hiking trail 540 launches the compass app at 2:30 PM, location services can perform checks to determine if the user is in a non-urban location. Location services also examine recorded historical information and find that the user used a cellular connection at 1:30 PM... Figure 5 Driving before waypoint W2 (e.g., 522), and being in a city location at 1 PM (e.g., Figure 5 Waypoint W1). Therefore, since driving is considered a state of motion that is unlikely to be in a non-urban location, the compass application can be allowed to access the second table 634 with location information only until 1:30 PM (or until...). Figure 5 Waypoint W2).

[0101] Furthermore, after the compass application accesses the secure storage device 630, it can display a backtracking route to a waypoint location (e.g., a previous location associated with the nearest or closest waypoint) with a cellular connection (i.e., a cellular waypoint) or an SOS connection (SOS waypoint), but does not display paths beyond that waypoint location because access to the location information in the second table 634 is restricted. For example, it can display... Figure 5 The path from point 540 to waypoint W3 (Route A) or W4 (Route B) is displayed, but the path from waypoint W3 to W2 is not shown. Therefore, only some, not all, of the historical paths traveled by the user with the mobile device are displayed as needed.

[0102] In other words, when the compass application requests database access, the location service ensures two things: first, that the user is in a non-urban location state; and second, that database access to location information is only available at 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 sufficiently so, thus reducing the chance of misuse of this location information.

[0103] In some implementations, if the user has reached a previously recorded waypoint location (e.g., W3) with sufficient signal strength (i.e., above a threshold), but the signal strength has changed, for example, become weaker than previously recorded, such as due to weather conditions, then an alternative backtracking route from W3 to W2' (or W2) can be displayed, provided that the mobile device remains in a non-urban location. In other words, the display of the backtracking route (and access to the location information in the secure storage device 630) can be performed in stages.

[0104] In another implementation, all cellular / SOS waypoints within a non-urban location state can be displayed, but other waypoints during the transition between urban and non-urban location states are displayed in stages (i.e., phased display). For example, in Figure 5In the context of a mobile device in a non-urban location, waypoints W4, W3, and W2' can be displayed (if the non-urban location is determined to be confirmed). Waypoint W2 is only displayed when the user of the mobile device reaches waypoint W2', and W2 is required due to weak signal at W2'. Further details regarding the display of backtracking routes are described below.

[0105] 1. Location Status Classification Location status classification refers to determining the location category to which a mobile device belongs (e.g., urban or non-urban). Location category can be used as part of the privacy protections discussed earlier.

[0106] In some implementations, the location state classifier 612 may determine that the mobile device (e.g., the first mobile device 610) is in a non-urban location state using one or more of the following: (1) The detectability of a network wireless signal at or before the time of requesting waypoint information, such as a signal within the network, a signal outside the network, or other types of wireless signals, including satellite signals and Wi-Fi signals. (2) The first mobile device 610's one or more states of motion (e.g., walking, running, cycling, driving, stationary, etc.) at or before that time, and (3) Classification of one or more map tiles in which the first mobile device 610 resides at or before this time. The map tiles may be generated by a tile-based mapping service that can retrieve map data and metadata of the geographic area surrounding 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 device 630, the location state classifier 612 can determine the location state of the first mobile device using network wireless signals, motion status, map tiles, and a combination of one or more of these. For location state determination, as an example, network wireless signals (such as Wi-Fi connections, e.g., Figure 5 The detection of waypoint W2(520) can indicate that the mobile device is in an urban location state. However, in some implementations, when the network radio signal is unstable, resulting in the creation of many waypoints over a short distance, such as creating an additional waypoint W2' only one mile away from waypoint W2, the location at waypoint W2' can be determined to be in a non-urban location state. Therefore, the network radio signal detected at or before requesting waypoint information can help determine the location state of the mobile device.

[0108] As another example, such as driving (e.g., Figure 5The motion state or category of (522) is more likely to be in an urban location, while walking, cycling, or running are more likely to be in a non-urban location. The motion state shortly before requesting waypoint information can help determine the location state of the mobile device, as the user of the mobile device can stop their activity to make the request.

[0109] However, for another example, the classification of one or more map tiles residing on a mobile device may indicate a non-urban location (e.g., 512) status because there are no building structures (e.g., 504) or high elevations (e.g., 506) in the geographic area covered by that map tile. As previously mentioned, map tiles can be generated by a tile-based mapping service. A map tile can be a geographic area covering the mobile device, where the area can be a square with each side approximately five to ten miles long, or other shapes (e.g., rectangles, circles, hexagons, etc.). In some implementations, the size of the geographic area may vary depending on the location status. For example, for urban locations, the size of the geographic area may be smaller, such as five miles in length, because more data (such as buildings, streets, highways, parks, etc.) is associated with the tile. For non-urban locations, the size may be larger, such as 50 miles or more in length, if the landscape is relatively unchanged. Map tiles can be cached at any time in the secure storage / database of the mobile device when network wireless signals and power are available for such services. In some implementations, map tiles may also include elevation information. In some implementations, signal strength and motion state can be pre-calculated and incorporated into a tile-based mapping service to generate map tiles.

[0110] C. Display waypoint locations and trace the route As discussed earlier, as part of the backtracking process, from the current location of the mobile device (e.g., Figure 5 (540) to the latest (or most recently or last created) cellular / SOS waypoint (e.g., Figure 5 The backtracking route (or path) of route A (waypoint W3) can be displayed on the requesting user's mobile device (e.g., Figure 6 On (610). Sometimes, the nearest waypoint is also the closest (or most distant) to the current location. At other times, the nearest waypoint and the closest waypoint may be different. For example, in Figure 5In this scenario, if the user is traveling along a relatively straight line (e.g., route A), the nearest cellular waypoint and the closest cellular waypoint are the same, i.e., waypoint W3. On the other hand, if the user is traveling on a winding road (e.g., route B), the nearest cellular waypoint (e.g., W3) and the closest cellular waypoint (e.g., W4) may be different. In such cases, multiple waypoints (e.g., both the nearest and closest cellular waypoints) with paths to each waypoint can be displayed for the user of mobile device 530 to choose from, thereby helping the user select an easier or faster route to the waypoint. In some embodiments, the route can be displayed in three dimensions, including the elevation of the waypoints to indicate the terrain of the route.

[0111] In other implementations, a set of previous locations (or waypoints) within a non-urban location state can be retrieved. The current location can be displayed (e.g., Figure 5 The path between waypoint W2 (W2', W3, and W4) and the first cellular / SOS waypoint identified as being in a non-urban location (e.g., assuming waypoint W2 is identified as being in a non-urban location). Other waypoints (e.g., waypoints W2', W3, and W4) may be included in the displayed path.

[0112] Cellular / SOS waypoints can be displayed along with an icon or text indicating that the waypoint is a previous location with available network wireless signal. Other previous locations considered to be in a city location state are not displayed, regardless of cellular connectivity.

[0113] When the first mobile device arrives at a previous location with network connectivity (cellular or SOS) (e.g., Figure 5 After W3 or W4, a message can be transmitted. This message can be an emergency message. An emergency message can be an emergency phone call.

[0114] D. Process flow for providing location information Figure 7 This is a flowchart illustrating a method 700 for providing location information about when a network signal was last available, according to some embodiments. In some embodiments, 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 the mobile device (e.g., processor 1918 of FIG. 19). The first mobile device may be a wearable device (e.g., a watch).

[0115] At box 710, the strength of the network wireless signal is monitored. This monitoring can use the same module that measures the strength and displays it on the screen. Figure 6A bar corresponding to network strength is shown. Signal strength can be monitored using signals received by the first mobile device 610, the second mobile device 620, or both. Therefore, the strength of the network wireless signal can be monitored at the second mobile device, which is in local communication with the first mobile device (e.g., via Bluetooth pairing).

[0116] The network wireless signal can be used for cellular connectivity or SOS connectivity. For SOS connectivity, the signal can be an intranet signal or an extranet signal (i.e., a different operator than the one subscribed to by the user of the first mobile device). If an intranet signal is available, cellular connectivity and SOS connectivity may overlap. In some implementations, these two different signals may have locations that provide different icons or text to the user.

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

[0118] In some implementations, as discussed above, for privacy purposes, the signal strength (RSSI) may be stored in a first table (e.g., Figure 6 In table 632), and location information can be stored in a second table (e.g., Figure 6 In section 634), access to the location information in the second table is permitted only if certain criteria (such as non-city location status) are met.

[0119] At box 730, a request for information about the previous network connectivity of the first mobile device is received. For example, when a user of the mobile device wants to communicate (e.g., make a phone call or text message) but no wireless network signal is available, the user can launch an application such as a compass app or a map app, which automatically requests location services to obtain information about the previous network connectivity, such as cellular waypoints or SOS waypoints.

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

[0121] At box 750, the first previous location is provided to the user of the first mobile device. For example, a compass app or map app could display a path (or backtracking route) from the current location to the first previous location. Figure 5 In the middle, from the current location (540) to the first waypoint created in a non-city location (e.g., Figure 5 The path of W2 can be displayed together with other waypoints in the path (e.g., W2' and W3 and / or W4).

[0122] In some implementations, for privacy reasons, as discussed above, waypoints can be displayed in stages by showing the most recent (or closest) waypoint. Other waypoints created before the most recent waypoint may not be displayed unless necessary. For example, in... Figure 5 In the process, if the user arrives at the displayed waypoint (e.g., Figure 5 If the signal strength at the waypoint has changed (e.g., weaker than previously observed), the location service can retrieve more location information from secure storage device 630 to display the next cellular or SOS waypoint (e.g., W3) even when the mobile device is still in a non-urban location state. Figure 5 (W2 or W2').

[0123] Figure 8 This is a flowchart illustrating a method 800 for providing privacy-preserving location information according to some implementation schemes. Figure 8 Described Figure 7 Further details in box 740.

[0124] At box 810, it is determined whether the first mobile device is in a non-urban location state. As previously discussed, a non-urban location state can indicate that network wireless signals are more likely to be lost. Therefore, the user of the first mobile device needs to access the location information of the first mobile device.

[0125] At box 820, if the first mobile device is in a non-city location state, the process proceeds to box 830.

[0126] At box 830, first previous location information is retrieved from a restricted portion of the storage device. For example, in Figure 5From the middle, one can Figure 6 The waypoint W2 is retrieved from the second table 634 containing location information in the secure storage device 630, which requires certain criteria to be met, such as in a non-urban location state.

[0127] At box 840, restrictions (or thresholds) are set for accessing further location information beyond the first prior time and not falling into a non-urban location state. As previously discussed, for privacy reasons, historical information (e.g., location information) beyond that time that is considered not to be in a non-urban location state can be restricted. For example, in Figure 5 Information about waypoint W1 may be restricted because its associated time is determined to be in a city location state.

[0128] Returning to box 820, if the first mobile device is not in a non-city location state, processing proceeds to box 860. At box 860, access requests to secure storage devices for information falling outside of a non-city location state may be denied, and the corresponding waypoints cannot be displayed. In some implementations, the location service may also request identification information (e.g., biometric data, passwords, etc.) from the requesting user for access to protect privacy.

[0129] E. Accessibility of waypoint information and backtracking features Since SOS / cellular waypoint and backtracking (e.g., displaying backtracking routes to waypoints) features can help users of mobile devices (e.g., wearable watches) when they need them most in non-urban locations, it would be beneficial to make users aware of these features or to make them discoverable at appropriate times and to provide easy access when needed.

[0130] In some implementations, when one or more SOS / cellular waypoints are available and the user is determined to be in a non-urban location, a prompt may be displayed on the mobile device asking the user if they want to see the information. For example, when a user attempts to make a phone call or send a text message but fails, a notification or prompt may also be displayed asking the user if they want to find available services (e.g., cellular waypoints). Once the user responds to the prompt and requests the information, the aforementioned route retracing process (e.g., ...) will be followed. Figure 7 ).

[0131] In some implementations, for activities such as hiking, running, or skiing, the backtracking feature can be automatically initiated and the user prompted at an appropriate time when it is determined that the user is in a non-urban location.

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

[0133] Finally, in some implementations, if a user opens an application (such as a running app) during a live activity (e.g., running, cycling, etc.), the compass app can be part of the smart stack, allowing the user easy access when needed. The smart stack is a set of desktop applets that use information such as time, user location, and user activity to automatically display the most relevant applets at the appropriate time of day. Users can access the compass app by rotating the digital crown on their mobile device (e.g., a wearable watch) to utilize the backtracking feature.

[0134] V. User interface for displaying the last known location of a network signal. Figures 9A to 9Q Exemplary user interfaces for switching between different views of location indication, according to some embodiments, are illustrated. The user interfaces in these figures are used to illustrate the processes described below, including... Figure 10 The process in.

[0135] exist Figure 9A At this location, device 2000 displays a main screen user interface 902 comprising multiple icons on display 2001, each of which, when activated (e.g., via tap input), causes device 2000 to display a user interface for its corresponding application. Figure 9A At this location, 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 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, such as... Figure 9B As shown.

[0136] exist Figure 9BIn this high-visibility view 910, an arrow 910A, a text direction indicator 910B, and a digital direction indicator 910C are included. The arrow 910A operates like a compass needle and points north, updating on the display as the device 2000 rotates, ensuring the arrow continues to point north. The text direction indicator 910B indicates the fundamental or ordinal direction (e.g., N, S, W, E, NE, SE, SW, and / or NW) that the device 2000 is pointing in (e.g., when the device is worn on a user's hand). The digital direction indicator 910C indicates the numerical degree that the device 2000 is pointing in. The high-visibility view 910 does not include indications of the device 2000's current position or other positions. Figure 9B At this point, device 2000 detects rotation 950B (e.g., clockwise rotation) of rotating element 2032 (e.g., rotatable input mechanism and / or crown). In response to detecting rotation 950B, device 2000 switches from displaying a high-visibility view 910 to displaying a mixed view 912, as... Figure 9C As shown.

[0137] exist Figure 9CAt this location, the hybrid view 912 includes an arrow 912A, a text direction indicator 910B, a digital direction indicator 910C, position indicators 920A-920E, a current altitude option 930, and a retrospective energy display 2014. The hybrid view 912 includes many of the same features as described above in the reference navigation user interface 2002. The arrow 912A operates like a compass needle and points north, updating on the display as the device 2000 rotates, ensuring that the arrow 912A continues to point north. The text direction indicator 912B indicates the basic or ordinal direction (e.g., N, S, W, E, NE, SE, SW, and / or NW) that the device 2000 is pointing in (e.g., when the device is worn on the user's hand). The digital direction indicator 912C indicates the numerical degree that the device 2000 is pointing in. Location indicators 920A-920E each correspond to a different location (e.g., historical locations where the user has placed waypoint markers and / or important locations (e.g., the last known cell service location and / or the location where the user's car is parked)). In the hybrid view 912, location indicators 920A-920E are distributed around a circle, where each of their positions indicates the direction of the corresponding physical location (e.g., campsite, last known cell service location, and / or the user's vehicle). Therefore, while the hybrid view 912 provides the user with information about the direction of various locations relative to the current location of device 2000, it does not provide information about the distance to the various locations or about the (absolute or relative) altitude of the various locations. The current altitude option 930 indicates the current altitude of device 2000 relative to sea level (e.g., 85 feet above sea level). The backtracking indicator 2014, when activated, causes device 2000 to display information about the path traversed by device 2000 to reach its current location (e.g., as described in more detail above with respect to the historical location indicator 2028). The new waypoint indicator 2058 initiates the process of adding a new waypoint when activated. In some embodiments, device 2000 detects a tap input 950C on the current elevation option 930, and in response, device 2000 displays an elevation view 916. In some embodiments, device 2000 detects a rotation 950D (e.g., clockwise rotation) of the rotating element 2032 (e.g., a rotatable input mechanism and / or crown). In response to detecting rotation 950D, device 2000 switches from displaying a mixed view 912 to displaying a distance view 914, as... Figure 9D As shown.

[0138] In some implementations, device 2000 detects user input (e.g., a two-finger tap and hold on display 2001) (e.g., when displaying a high visibility view 910, a mixed view 912, a distance view 914, an elevation view 916, and / or a target navigation interface 2094), and in response, device 2000 outputs audio (e.g., spoken audio) including device 2000's current position, device 2000's current orientation, and / or heading.

[0139] exist Figure 9D At this location, distance view 914 includes arrow 912A, position indicators 920A-920E, current altitude option 930, and backtracking indicator 2014. Distance view 914 includes many of the same features as described above with reference to navigation user interface 902. In distance view 914, the positioning indications of position indicators 920A-920E correspond to the direction and distance of the position of position indicators 920A-920E (e.g., from the current position of device 2000). In some embodiments, in distance view 914, the positioning indications of position indicators 920A-920E correspond to the direction and distance between the positions of position indicators 920A-920E and the direction and distance from the current position to these positions. Current position indicator 932 indicates the current position of device 2000. Therefore, distance view 914 provides the user with information about the distance and direction of the various positions represented by position indicators 920A-920E and the current position of device 2000. In distance view 914, the positioning of position indicators 920A-920E does not indicate the altitude (e.g., relative to sea level and / or relative to the current altitude of device 2000) corresponding to the position of position indicators 920A-920E. In some embodiments, in Figure 9D At this location, device 2000 detects rotation 950E of rotating element 2032 (e.g., rotatable input mechanism and / or crown). In response to detecting rotation 950E and determining that the rotation is counterclockwise, device 2000 switches from displaying distance view 914 to displaying mixed view 912, as shown. Figure 9C As shown. In response to detecting a rotation 950E and determining that the rotation is clockwise, device 2000 changes the scale of the distance view 914 (e.g., zooms out). In some embodiments, in Figure 9D At this point, device 2000 detects a tap input 950F on the current altitude option 930, and in response, device 2000 switches from displaying distance view 914 to displaying altitude view 916, as shown. Figure 9G As shown.

[0140] like Figure 9GAs shown, in some embodiments, the elevation view 916 is a simulated three-dimensional view and / or perspective view including position indicators 920A-920E. In the elevation view 916, the positioning indications of position indicators 920A-920E and the current position indicator 932 correspond to the elevation of the positions of position indicators 920A-920E and the current position of device 2000 (e.g., relative to the lowest elevation in device 2000, relative to sea level, and / or about the current elevation of device 2000). Additionally, in the elevation view 916, the positioning indications of position indicators 920A-920E correspond to the direction and distance between the positions of position indicators 920A-920E and the direction and distance from the current position to these positions. Therefore, the elevation view 916 provides the user with information about the distance, direction, and elevation of the various positions represented by position indicators 920A-920E and the current position of device 2000.

[0141] In some implementations, during the transition from distance view 914 to elevation view 916, device 2000 displays an animation of tilting circle 934 into the perspective view to represent a reference plane, such as... Figures 9D to 9G As shown. In some embodiments, during the transition from distance view 914 to elevation view 916, device 2000 displays a corresponding indicator of the position (e.g., 920A and 920B) within the area defined (between) by 936 and optionally an animation of the current position indicator 932, as shown. Figures 9D to 9G As shown. In some embodiments, the corresponding indicator for the location and the current location indicator 932 are increased by a corresponding amount based on the altitude of the corresponding location of the indicator. For example, in Figure 9E At this point, position indicators 920A and 920B have been raised by the same amount, and... Figures 9F to 9G At this point, position indicator 920A has stopped rising and position indicator 920B has risen further, thus indicating that position indicator 920B corresponds to a position at a higher altitude than the position corresponding to position indicator 920A. In some embodiments, the various position indicators rise at the same level based on the corresponding altitude of the positions corresponding to the various position indicators, but for different durations (and therefore different distances). In some embodiments, 934 represents a reference plane having an altitude based on (equal to) the current position and the lowest altitude among the positions represented by position indicators contained within the area defined by 936. In some embodiments, the corresponding indicators (e.g., Figure 9G The elevations (e.g., relative to sea level and / or another elevation) of 920A, 920B and / or 932 in the reference plane are represented by corresponding lines (e.g., vertical lines) extending from the reference plane 934, and the length of the lines is proportional to the elevation (e.g., relative elevation) of the corresponding indicated location.

[0142] exist Figure 9G In elevation view 916, device 2000 displays direction and distance information about the location corresponding to position indicators 920C-920E, without raising position indicators 920C-920E to display the corresponding elevation information (e.g., because position indicators 920C-920E are not within the area defined by 936). In some embodiments, in Figure 9G At this point, device 2000 detects a tap input 950G on the current altitude option 930, and in response, device 2000 switches from displaying the altitude view 916 to displaying the distance view 914 (e.g., inverting the display). Figures 9D to 9G (Animations), such as Figure 9D As shown. In some embodiments, device 2000 detects rotation 950H and, in response, changes the scale of elevation view 916 (e.g., zooming in or out based on the direction of rotation). In some embodiments, changing the scale of elevation view 916 results in the display of additional position indicators (e.g., within the area defined by 936) and / or results in some position indicators no longer being displayed.

[0143] exist Figure 9G At this point, device 2000 detects a rotation 950I, causing device 2000 to turn from pointing northwest to pointing southeast. In response to detecting the rotation 950I, device 2000 updates the positioning of position indicators 920A-920E in the elevation view 916, moving position indicators 920A and 920B out of the area defined by 936 and bringing position indicator 920D into the area defined by 936, as shown. Figure 9I As shown. Therefore, device 2000 lowers position indicators 920A and 920B to reference plane 934 and optionally raises position indicator 920D above reference plane 934 to indicate the elevation corresponding to the position of position indicator 920D, as... Figures 9G to 9I The animation at that location is shown. Reference plane 934 represents the current position and the lowest elevation of the location with indicators within the area defined by 936 (e.g., in...). Figure 9H In this context, the elevation of reference plane 934 corresponds to the lower of the elevation of the current position of device 2000 and the elevation of the position corresponding to position indicator 920D. Therefore, in some embodiments, the elevation of reference plane 934 changes when device 2000 rotates and / or when the scale of elevation view 916 changes.

[0144] exist Figure 9IBecause the elevation of location indicator 920D is newly displayed, device 2000 displays (on display 2001 adjacent to 920D) a digital indication 938 (e.g., "200 feet") corresponding to the elevation of location indicator 920D's position (e.g., above sea level) (for a predetermined amount of time). Figure 9J At that point, after a predetermined amount of time, device 2000 stops displaying digital indicator 938. Figure 9J At this location, device 2000 detects a tap input 950J on the traceback indicator 2014. In response to the detection of the tap input 950J on the traceback indicator 2014, device 2000 displays path 940, which shows the path traveled by device 2000 to reach its current position. (As...) Figure 9K As shown, location indicator 920D corresponds to the last location where cellular service was available, and device 2000 automatically adds location indicator 920D corresponding to the last location where cellular service was available as a waypoint, thereby allowing the user to trace back to that location to make a call (e.g., an emergency call).

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

[0146] exist Figure 9N At this point, device 2000 detects one or more inputs (e.g., including a tap input 950N on information object 946), and in response, displays option 948 for setting an altitude warning, such as... Figure 9O As shown. In Figure 9O At this point, tapping the input 950O on device 2000 detection option 948 displays the altitude setting user interface 960. Figure 9P At this location, device 2000 receives inputs 950P and 950Q to set a target altitude of 300 feet. Device 2000 then monitors its current altitude. Figure 9Q At this point, device 2000 detects that device 2000 has reached (or surpassed) the target altitude, and in response, outputs an alarm 962 indicating that the target altitude has been reached.

[0147] Figure 10 This is a flowchart illustrating a method for transitioning between different views indicating a location, according to some embodiments. Method 1000 is performed at a computer system (e.g., 1100 and / or 2000) (e.g., a smartwatch, smartphone, tablet, laptop, and / or head-mounted device (e.g., a head-mounted augmented reality and / or extended reality device)), which communicates with display generating components (e.g., 2001) (e.g., a display controller, touch-sensitive display system, monitor, and / or head-mounted display system) and one or more input devices (e.g., 2001 and / or 2032) (e.g., a touch-sensitive surface, keyboard, rotatable input mechanism, and / or mouse). Some operations in 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 switch between different views of a location indicator. This method reduces the cognitive burden on users when viewing the location indicator, thus creating a more efficient human-computer interface. For battery-powered computing devices, enabling users to view the location indicator faster and more efficiently saves power and increases the time interval between battery charging.

[0149] A computer system (e.g., 2000) displays (1002) a first view (e.g., ) via a display generation component (e.g., 2001). Figure 9D (e.g., a two-dimensional view), the first view concurrently includes one or more indications of one or more locations of the computer system (e.g., location 914) Figure 9D 920A-920E (e.g., indications of one or more historical locations that the computer system has visited and / or waypoints and / or a first indication for a first location and a second indication for a second location) and indications of the current location (e.g., Figure 9D (932 at the location).

[0150] First view (e.g., Figure 9D One or more indications in 914 for one or more locations (e.g., the location of a parked car, the location of a path entrance, and / or the location of a point of interest) (e.g., Figure 9D(920A-920E at the location) and indication of the current location (e.g., Figure 9D The display relationship (1004) between locations 932) (e.g., distance and / or relative positioning between them) corresponds to (e.g., based on and / or proportional to) the distance and relative positioning relationship between one or more locations of a computer system (e.g., 2000) and the current location (e.g., based on location data (e.g., geographic location data, estimated (e.g., based on data from one type of sensor (e.g., gyroscope or accelerometer sensor)) or actual (e.g., based on different sensor types (e.g., GPS sensor))), while the first view (e.g., Figure 9D The displayed relationships in (914) do not correspond to the elevation relationships between one or more locations of the computer system and the current location. In some embodiments, the first view is a two-dimensional view that includes indications of various locations. These indications are arranged to show the relative distances between the various locations and to show the various positions of these locations relative to each other. In some embodiments, in the first view, the indications are not arranged in a manner that reflects / discloses the elevation of the various locations (e.g., absolute elevation or elevation relative to each other).

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

[0152] In response to the detection of a first input (e.g., 950F and / or 950E), the computer system (e.g., 2000) displays a first view (e.g., Figure 9D (914) Transformation (1008) (e.g., Figures 9D to 9G (e.g.,) to display a second view via a display generation component (e.g., Figure 9G (at 916), this second view concurrently includes one or more indications of one or more locations of the computer system (e.g., Figure 9G Locations 920A-920E (e.g., indications of one or more historical locations that the computer system has visited and / or waypoints) and indications of the current location (e.g., Figure 9G (932 at the location).

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

[0154] In some implementations, from displaying the first view (e.g., Figure 9D From 914 at the location to the second view (e.g., Figure 9G The transformation at 916) includes one or more indications (e.g., 934) that animate the elevation of one or more locations of the computer system relative to (e.g., a displayed or undisplayed) reference plane (e.g., 934). Figures 9E to 9G At least one of the indicators in 920A and 920B and the indicator of the current location (e.g., Figures 9E to 9G The first view is a two-dimensional view, and the second view is a three-dimensional view (e.g., a raised position indicator 920A and / or an indication of the current position). In some embodiments, the first view is a two-dimensional view, and the second view is a three-dimensional view (e.g., a perspective view). In some embodiments, in the first view, the indications of various positions (one or more positions and the current position) are displayed on a single plane, and in the second view, the indications of various positions are displayed on different planes (e.g., these planes are based on the height of the respective positions). In some embodiments, the animation from the first view to the second view includes the indications of various positions being raised from the reference plane to above their respective planes (based on their height). Animating the elevation of the indications to show the corresponding elevation provides the user with visual feedback indicating the placement of the indications at an elevation, thus providing improved visual feedback.

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

[0156] In some implementations, the animation of the corresponding indicator (e.g., 920A and / or 920B) (e.g., the indicator of one or more indicators and / or the indicator of the current position) is enhanced (e.g., in...). Figures 9D to 9G This includes raising the corresponding indicator by a certain amount, based on the difference between the elevation of the location corresponding to the indicator and the elevation represented by a reference plane (e.g., 934). Raising the corresponding indicator above the reference plane provides the user with visual feedback on how much higher the corresponding location is in terms of elevation, thereby providing improved feedback.

[0157] In some implementations, the second view (e.g., Figure 9G The second view (916) concurrently includes one or more indicators (e.g., 920A-920B) at one or more locations of the computer system and an indicator of the current location with multiple other indicators (e.g., 920C-920E) at multiple other locations. In some embodiments, the display relationships (e.g., distances, relative positions, and altitudes) between the multiple other indicators (e.g., 920C-920E) at multiple other locations in the second view correspond (e.g., based on and / or proportional to) the distance and relative position relationships, while the display relationships in the second view do not correspond to the altitude relationships between the multiple other indicators. In some embodiments, the second view includes indicators of multiple other locations that show the distances and relative positions of the other locations, but do not show the relative altitudes of the multiple locations. Displaying distance and orientation relationship information for some points without displaying the altitude relationships of those points helps to avoid cluttering the user interface, allowing the user to better identify the altitude differences of points of interest, thereby providing improved visual feedback.

[0158] In some implementations, the computer system (e.g., 2000) detects (e.g., via a magnetometer) the rotation of the computer system (e.g., 950I) (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 (by an animated display of an update of a second view) a first corresponding indicator relative to a reference plane (e.g., 934) based on the height of a first corresponding position corresponding to the first corresponding indicator (e.g., 934). Figures 9H to 9I (920D at the location); and the computer system (e.g., 2000) independently of the height of the second corresponding position corresponding to the second corresponding indication, displays one or more second corresponding indications (e.g., Figure 9H The directional indicator (at point 920A) descends (by an animated update of the second view) to a reference plane (e.g., 934). In some embodiments, the directional indicators are displayed as if overlapping a portion of the reference plane, and indicators within the directional indicator are raised to show their altitude, while indicators not within the directional indicator are displayed on the reference plane (without showing their altitude). In some embodiments, the raising of the indicator entering the directional indicator and the lowering of the indicator leaving the directional indicator occur concurrently. Rotating the device to display the altitude for some indicators allows the user to specify which points should be displayed with altitude, thus providing the user with more control and improved feedback.

[0159] In some implementations, in response to detecting a rotation (e.g., 950°I) of the computer system (e.g., 2000), the computer system displays a textual representation of the altitude (e.g., absolute value, 300 feet, 350 feet, or 654 feet above sea level) of the first corresponding position via a display generation component (e.g., proximity second corresponding indicator). Figure 9I The time (e.g., a predefined amount) at which the directional indicator (938) reaches a certain amount (e.g., before stopping the display without requiring additional user input) is specified. In some implementations, the computer system temporarily displays text elevation next to the point (e.g., the rising point) within the directional indicator. Temporarily displaying text elevation information next to the indicator provides the user with accurate feedback on the elevation (e.g., above sea level) of the corresponding location, thereby providing improved visual feedback.

[0160] In some implementations, the computer system (e.g., 2000) generates a display via a display generation component (e.g., 2001) and a first view (e.g., Figure 9C(e.g., 930) concurrently displays a text representation of the computer system's current elevation (e.g., 65 feet, 102 feet, or 322 feet above sea level). In some implementations, 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, thus providing improved feedback.

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

[0162] In some implementations, when displaying a second view (e.g., Figure 9G When 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 text representation of the computer system's current altitude), in response to the detection of the second input (e.g., 950G), the computer system (e.g., 2000) retrieves a second view (e.g., ...) from the second view (e.g., ...). Figure 9G The 916th position is transformed (e.g., including animation) to the first view (e.g., ...). Figure 9D (914 at the location). Displaying a first view that does not include elevation relationships provides the user with a simplified view of distances and locations for various positions, thus offering improved visual feedback.

[0163] In some implementations, when displaying the first view (e.g., Figure 9D Prior to point 914, the computer system (e.g., 2000) displays a third view (e.g., ...) via a display generation component. Figure 9CThe third view (e.g., a two-dimensional view) concurrently includes one or more indications of one or more locations (e.g., indications of one or more historical locations the computer system has visited and / or waypoints and / or a first indication for a first location and a second indication for a second location) and an indication of the computer system's current location. The displayed relationship (e.g., distance and / or relative positioning) between one or more indications of one or more locations (e.g., 920A-920E) in the third view and the indication of the current location corresponds (e.g., based on and / or proportional to) the relative positioning relationship between one or more locations of the computer system and the current location (e.g., based on location data (e.g., geographic location data, estimated (e.g., based on data from one type of sensor (e.g., gyroscope or accelerometer sensor))) or actual (e.g., based on different sensor types (e.g., GPS sensor))))), while the displayed relationship in the first view does not correspond to the distance and elevation relationships between one or more locations of the computer system and the current location. In some embodiments, the third view is a two-dimensional view including indications of various locations. These indications are arranged to show the relative positioning of these locations with respect to each other. In some implementations, the indications in the third view are not arranged in a manner that reflects / discloses the distances and / or elevations (e.g., absolute elevations or elevations relative to each other) between various locations. In some implementations, the computer system receives user input (e.g., a tap input on a text representation of the computer system's current elevation) and, in response, transitions from the third view to the first view. Displaying a first view that excludes elevation and distance relationships provides the user with a simplified view of the location of various locations, thereby providing improved visual feedback.

[0164] In some embodiments, before displaying the 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. This fourth view includes the current orientation of the computer system (e.g., 2000) (e.g., 910A) and 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 visited and / or waypoint indications and / or a first indication for a first location and a second indication for 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 of a rotatable input mechanism) and switches from the fourth view to the third view in response. Displaying the current orientation without showing any relationship to various locations provides the user with a simplified view of the computer system's orientation, thereby providing improved visual feedback.

[0165] In some implementations, when displaying a second view (e.g., Figure 9K When at position 916), the computer system (e.g., 2000) detects a group of one or more inputs via one or more input devices, including inputs pointing to a corresponding indication corresponding to the corresponding position (e.g., a tap input thereon) (e.g., 950K, 950L, and / or 950M). In response to detecting input pointing to the corresponding indication, the computer system (e.g., 2000) displays, via a display generation component, a path from the current position to the corresponding position (e.g., at position 916). Figure 9M The text distance (e.g., 100 meters, 3 miles, and / or 1.21 miles) between the current location and the corresponding location (e.g., in 944A) and the text elevation (e.g., in 944A) between the current location and the corresponding location. Figure 9M The difference is as follows: (e.g., 300 feet up, 33 feet up, or 120 feet down). In some implementations, the computer system detects a tap input on the corresponding indicator and, in response, displays a list corresponding to one or more indicators. In response to detecting a tap input on the corresponding item in the list corresponding to the location, the computer system displays text distance and text elevation. This allows the user to select a specific location to view additional details about that location, providing the user with additional feedback about that location, thus offering improved feedback.

[0166] In some implementations, the computer system (e.g., 2000) receives the selected target altitude (e.g., as in...). Figure 9P User input (e.g., 950O, 950P, and / or 950Q) is input from the computer system. The computer system (e.g., 2000) detects that the computer system has reached the target altitude (e.g., the user wearing the computer system has hiked downhill or uphill to the target altitude). In response to detecting that the computer system (e.g., 2000) has reached the target altitude, the computer system (e.g., 2000) outputs (e.g., audio, visual, and / or tactile) alarms (e.g., Figure 9P (e.g., indicating that the target altitude has been reached). A warning that the computer system has reached the target altitude provides the user with feedback on the computer system's altitude, thus offering improved feedback.

[0167] In some implementations, when displaying a second view (e.g., Figure 9KWhen a rotational input is detected (e.g., at position 916), the computer system (e.g., 2000) detects the rotational input via a rotatable input device among one or more input devices. In response to the detection of the rotational input, the computer system changes the scale of the distance between one or more indicators of one or more positions and the indicator of the current position (and optionally displays an indication of the scale (e.g., on a reference plane)). Changing the scale of the second view provides the user with additional feedback on additional positions and / or provides the user with more granular feedback on fewer positions, thereby providing improved visual feedback.

[0168] In some implementations, 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) corresponding to the last location within the communication range of the cellular service provider as part of a first view and / or a second view. In some implementations, when the computer system leaves the cellular connection range of the service provider, the first view and / or the second view automatically display a point corresponding to the last location where cellular connectivity was available (of that service provider, even if other services are available and within the communication range of the computer system). Automatically displaying an indication corresponding to the last cellular connection (e.g., of the device's cellular service provider) when outside the cellular connection range provides the user with feedback on where to return to obtain cellular service (e.g., in an emergency).

[0169] In some implementations, 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 an indication (e.g., 920D) corresponding to the last location where the computer system was within the communication range of any cellular service provider as part of a first view and / or a second view. In some implementations, when the computer system leaves the cellular connectivity range of all cellular service providers, the first view and / or the second view automatically display a point corresponding to the last location where cellular connectivity was available (for any service provider). Automatically displaying an indication corresponding to the last emergency cellular communication connection (e.g., with any cellular service provider that worked with the computer system) when outside the cellular connectivity range provides the user with feedback on where to return to for cellular service (e.g., in an emergency).

[0170] VI. High Alert In some implementations, mobile devices (e.g., phones or wearable devices such as watches) can warn users when the device reaches a set altitude (or altitude) threshold. This can be used for use cases such as rhythmic climbing to avoid altitude sickness, celebrations of reaching a certain altitude, fire or camp restrictions above a certain altitude, and skiing restrictions in remote areas below a certain altitude.

[0171] Mobile devices (such as phones or wearable devices like watches) can alert users when the device reaches a target height (above or below the target). However, frequent and undesirable notifications can occur when the device moves up and down while approaching the target height, or when the user accidentally raises or lowers their arm with the device.

[0172] A. Architecture The disclosed technology adds a programmable height threshold around the monitored (or measured) height to reduce or prevent unwanted notifications by enabling and disabling notifications at appropriate times as the mobile device moves up and down while approaching the target height. The threshold around the monitored (or measured) height can be viewed as a band along a trajectory line of the monitored height.

[0173] The following Figure 11 and Figure 12 This example illustrates height alerts triggered by a vertical geofence whenever a target height is reached or exceeded. Excessive and unnecessary alerts are also shown. Figure 12 The additional vertical geofence signal changes are shown.

[0174] Figure 11 An illustration shows a vertical geofence at a target height according to some implementations, and an alarm when the target height is reached. Line 1110 shows the change in altitude over time. When the device reaches the target height 1101, an alarm can be provided on the device's screen. Typically, when a user of a mobile device moves upward (or ascends in altitude) and downward (or descends in altitude), their movement can be categorized as crossing or reaching the target height. Crossing the target height can include crossing 1126 on an upward journey and crossing 1120 on a downward journey. Reaching the target height can include reaching a mountain peak 1140 or reaching a valley (not shown, but similar to 1140 in the opposite direction). When crossing the target height, the user typically expects an alarm to sound when the device reaches the target height. However, when reaching the target height, there may be too many and unnecessary alarms (e.g., 1122 and 1124) because the trajectory line may be above or below but close to the target height.

[0175] Figure 12This illustrates vertical geofence notifications as a user moves above and below a target height, according to some implementation schemes. The vertical geofence signal 1202 can change based on the monitored current height and control notifications (described below). For vertical geofences, signal 1202 changes from true (or true / high state) to false (or false / low state) when the mobile device descends below the target height (e.g., 1222 and 1226), and from false to true when the mobile device rises above the target height (e.g., 1220 and 1224).

[0176] B. Prevent unnecessary notifications The following are attached figures ( Figure 13 and Figure 14 The disclosed techniques illustrate methods for preventing unwanted or excessive notifications, such as during the attainment of a target altitude (e.g., a mountaintop or valley). Figure 15 The document also illustrates a framework for utilizing the disclosed technology.

[0177] Figure 13 Examples of mechanisms for preventing unwanted notifications are provided based on some implementation schemes. Figure 13 The shaded band around the trajectory line is shown. This band indicates that no new alerts will be provided after the alarm is triggered until the mobile device reaches a height at least a threshold amount different from the target height. In some implementations, the threshold amount (i.e., the band) can be a programmable height (e.g., a few feet) set by the user of the mobile device or the manufacturer of the mobile device. As seen at time 1324, no new alert (notification) will be provided because the band has not left the vertical geofence. That is, the height is not significantly (sufficiently) higher than the target height to reset the notification mechanism.

[0178] Figure 14 An example is illustrated of a mechanism for using a vertical geofence signal to prevent unwanted notifications, according to some implementations. As discussed above, the vertical geofence signal 1402 can change with the monitored current height and control notifications (e.g., a neutral state disables notifications, and a true or false state enables notifications). The vertical geofence signal 1402 (e.g., acting as a control signal) can be reset after each notification (i.e., by disabling notifications) and will not start again until the current height differs from the target height by a threshold (i.e., enabling notifications). For example, when the mobile device descends below the target height at time 1420 (i.e., crosses a downward path) and triggers notification 1460, signal 1402 changes from true (or true / high state) to false (or false / low state). Then, signal 1402 is quickly reset (i.e., the notification is disabled and enters an "initial" (or neutral) state). When the mobile device moves below the target height by more than a threshold amount (e.g., a band), the notification is re-enabled, for example at time 1421, by returning signal 1402 to the false / low state.

[0179] At time 1422, when the mobile device is above the target height and triggers notification 1462, signal 1402 changes from false to true. Signal 1402 is then reset again (i.e., notification is disabled). However, the trajectory around the summit 1440 remains within a threshold amount (e.g., a band). Therefore, excessive and unnecessary alarms (e.g., 1424) are avoided. Notification is re-enabled only at time 1425 when the mobile device moves below the target height beyond the threshold amount. At time 1426, the mobile device is above the target height (i.e., it crosses it on its upward journey), and signal 1402 changes from false to true accordingly, followed by notification 1466.

[0180] In summary, signal 1402 can be reset (i.e., the notification is disabled and enters an "initial" (or neutral) state) each time a notification is triggered (e.g., 1420, 1422, and 1426). When the mobile device is above or below the target height by more than a threshold amount (i.e., outside the band), the notification can be re-enabled by changing signal 1402 from the "initial" state to a "true" state (not shown) (if above the target height) or a "false" state (e.g., 1421 and 1425) (if below the target height), respectively.

[0181] Figure 15 The operation of a framework for tracking altitude and providing notifications, according to some implementation schemes, is illustrated. The normally open processor (AOP) can use an altimeter to perform measurements and compare the current altitude with the target altitude / elevation, including any upper and lower thresholds (e.g., such as...). Figure 14 (As shown). The altimeter can correct itself due to weather conditions and provide compensation for weather drift.

[0182] C. Flowchart Figure 16 This is a flowchart illustrating methods for triggering an alarm at a target altitude according to some implementation schemes. In some specific implementations, Figure 16 One or more method boxes can be executed by a mobile device (e.g., architecture 1500, electronic device 1700). In some specific implementations, Figure 16 One or more method boxes can be executed by another device or a group of devices, either separate from or including the mobile device. Additionally or alternatively, Figure 16 One or more method boxes may be executed by one or more components of the mobile device, such as computer-readable medium 1702, input / output (I / O) subsystem 1706, wireless circuit 1708, sensor 1716, application processor 1718, etc.

[0183] At box 1610, the target height is received and stored. The target height can be received from the user. For example, if the target height is to be stored in a wearable mobile device (such as a watch), the user can input the information into the watch via a user interface (such as voice commands, sliders, typing, etc.). Alternatively, the target height can also be input into, for example, a mobile phone paired with the watch via Bluetooth. The mobile phone can then transmit the input information to the watch.

[0184] At box 1620, an altimeter is used to monitor the device's current height. The altimeter in the mobile device can measure the device's current height. For example, in... Figure 14 In this context, the altimeter in the mobile device measures the current altitude of the device at different points in time.

[0185] At box 1630, the current height (also known as the measured height) is compared to the target height. For example, it can be determined whether the two values ​​are equal or different, but within a threshold or tolerance. For example, as... Figure 14 As illustrated, at time 1422, the current measured height of the mobile device is determined to be equal to the target height 1401. However, at 1440 (the mountaintop), the measured height differs from the target height 1401, but is within a threshold (e.g., the shadow band).

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

[0187] At box 1650, disable notifications after providing the notification in 1640. For example, in Figure 14 In the event that a notification is triggered at time 1422, notification signal 1402 is reset to the "initial" state.

[0188] At box 1660, continue monitoring the current height of the mobile device. For example, in Figure 14 During the initial state of the signal, the altimeter continued to monitor the device's current altitude at times 1440 and 1424.

[0189] At box 1670, a notification is enabled when the difference between the current height and the target height exceeds a threshold amount. For example, in Figure 14 In the process, when the current (or measured) height differs from the target height 1401 by a threshold (e.g., a shadow band) at time 1425, the notification feature is enabled by changing the notification signal 1402 from an “initial” state to a “false” state.

[0190] VII. Example Device Figure 17 This is a block diagram of example device 1700, which can be a mobile device. Device 1700 typically includes computer-readable medium 1702, processing system 1704, input / output (I / O) subsystem 1706, wireless circuitry 1708, and audio circuitry 1710 including speaker 1750 and microphone 1752. These components can be coupled via 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 fob cards, car keys, access cards, multifunction devices, mobile phones, portable gaming devices, automotive display units, etc., including combinations of two or more of these items.

[0191] Obviously, Figure 17 The architecture shown is only an example of the architecture of device 1700, and device 1700 may have more or fewer components or components with different configurations than shown. Figure 17 The various components shown can be implemented in hardware, software, or a combination of both, including one or more signal processing circuits and / or application-specific integrated circuits.

[0192] The wireless circuit 1708 is used to transmit and receive information over a wireless link or network to conventional circuitry of one or more other devices, such as antenna systems, RF transceivers, one or more amplifiers, tuners, one or more oscillators, digital signal processors, CODEC chipsets, memories, etc. The wireless circuit 1708 can use various protocols, such as those described herein.

[0193] Wireless circuit 1708 is coupled to processing system 1704 via peripheral device interface 1716. Interface 1716 may include conventional components for establishing and maintaining communication between peripheral devices and processing system 1704. Voice and data information received via wireless circuit 1708 (e.g., in speech recognition or voice command applications) is transmitted via peripheral device interface 1716 to one or more processors 1718. One or more processors 1718 can be configured to process various data formats of one or more applications 1734 stored on medium 1702.

[0194] Peripheral interface 1716 couples the device's input and output peripherals to processor 1718 and computer-readable medium 1702. One or more processors 1718 communicate with computer-readable medium 1702 via controller 1720. 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. Medium 1702 may include a memory hierarchy, including cache, main memory, and secondary memory.

[0195] Device 1700 also includes a power system 1742 for powering various hardware components. Power system 1742 may include a power management system, one or more power sources (e.g., a battery, alternating current (AC)), a recharging system, power fault detection circuitry, a power converter or inverter, a power status indicator (e.g., a light-emitting diode (LED)), and any other components typically associated with the generation, management, and distribution of power in mobile devices.

[0196] In some embodiments, device 1700 includes camera 1744. In some embodiments, device 1700 includes sensor 1746. Sensor 1746 may include an accelerometer, compass, gyroscope, pressure sensor, audio sensor, light sensor, barometer, altimeter, etc. Sensor 1746 can be used to sense positional aspects, such as auditory or optical markers of location.

[0197] In some embodiments, device 1700 may include a GPS receiver, sometimes referred to as GPS unit 1748. Mobile devices may use satellite navigation systems such as the Global Positioning System (GPS) to obtain positioning information, timing information, altitude, or other navigation information. During operation, the GPS unit may receive signals from GPS satellites orbiting the Earth. The GPS unit analyzes the signals to estimate transmission time and distance. The GPS unit may determine the current location (current position) of the mobile device. Based on these estimates, the mobile device may determine its orientation, altitude, and / or current speed. The orientation may 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 run various software components stored in medium 1702 to perform various functions of device 1700. In some embodiments, the software components include operating system 1722, communication module (or instruction set) 1724, location module (or instruction set) 1726, network coverage module 1728, predictive application manager module 1730, and other applications (or instruction sets) 1734, such as car locator applications and navigation applications.

[0199] Operating system 1722 can be any suitable operating system, including iOS, Mac OS, Darwin, RTXC, LINUX, UNIX, OS X, WINDOWS, or embedded operating systems such as VxWorks. The operating system may include various programs, instruction sets, software components, and / or drivers for controlling and managing general system tasks (e.g., memory management, storage device control, power management, etc.) and facilitate 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 wireless circuit 1708, and includes various software components for processing data received from wireless circuit 1708 and / or external ports 1736. External ports 1736 (e.g., USB, FireWire, Lightning connector, 60-pin connector, etc.) are adapted to be coupled directly or indirectly to other devices via a network (e.g., Internet, WLAN, etc.).

[0201] Location / motion module 1726 helps determine the current location (e.g., coordinates or other geographic identifiers) and movement of device 1700. Modern positioning systems include satellite-based positioning systems such as Global Positioning System (GPS), cellular network positioning based on “cell IDs,” and Wi-Fi positioning technology based on Wi-Fi networks. GPS also relies on the visibility of multiple satellites to determine location estimates, which may be invisible (or have weak signals) indoors or in “urban canyons.” In some embodiments, location / motion module 1726 receives data from GPS unit 1748 and analyzes the signals to determine the current location of the mobile device. In some embodiments, location / motion module 1726 may use Wi-Fi or cellular location technology to determine the current location. For example, the location of the mobile device may be estimated using knowledge of nearby cell sites and / or Wi-Fi access points and their locations. Information identifying the Wi-Fi or cellular transmitter is received at wireless circuit 1708 and transmitted to location / motion module 1726. In some embodiments, the location module receives one or more transmitter IDs. In some implementations, a sequence of transmitter IDs can be compared with a reference database (e.g., a cell ID database, a Wi-Fi reference database) that maps or associates transmitter IDs with the location coordinates of the corresponding transmitter, and the estimated location coordinates of device 1700 can be calculated based on the location coordinates of the corresponding transmitter. Regardless of the specific positioning technology used, the location / motion module 1726 receives information from which location orientation can be derived, interprets the information, and returns location information, such as geographic coordinates, latitude / longitude, or other location orientation data.

[0202] Network coverage module 1728 may include various submodules or systems, such as those described herein with respect to... Figure 6 and Figure 7 As described herein. Furthermore, a high-level module (not shown) may include various submodules or systems, such as those described herein relative to... Figures 11 to 16 As described.

[0203] One or more applications 1734 on the mobile device may include any application installed on device 1700, including but not limited to browsers, address books, contact lists, email, instant messaging, word processing, keyboard emulation, desktop applets, Java-enabled applications, encryption, digital rights management, speech recognition, speech copying, music players (playing back recorded music stored in one or more files such as MP3 or AAC files), and so on.

[0204] Other modules or instruction sets (not shown) may exist, such as graphics modules, time modules, etc. For example, a graphics module may include various conventional software components for rendering, animate, and displaying graphical 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. Timer modules may also be implemented in hardware. A time module may maintain various timers for any number of events.

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

[0206] In some embodiments, the I / O subsystem 1706 may include a display and user input devices such as a keyboard, mouse, and / or touchpad. In some embodiments, the I / O subsystem 1706 may include a touch-sensitive display. The touch-sensitive display may also accept input from a user based on tactile and / or haptic contact. In some embodiments, the touch-sensitive display forms a touch-sensitive surface for accepting user input. The touch-sensitive display / surface (along with any associated modules and / or instruction sets in the medium 1702) detects contact (and any movement or release of contact) on the touch-sensitive display and translates the detected contact into an interaction with a user interface object, such as one or more soft keys displayed on the touchscreen when the contact occurs. In some embodiments, the point of contact between the touch-sensitive display and the user corresponds to one or more of the user's fingers. The user may use any suitable object or accessory, such as a stylus, pen, or finger, to contact the touch-sensitive display. The touch-sensitive display surface may use any suitable touch-sensitive technology to detect contact and any movement or release of contact, including capacitive technology, resistive technology, infrared technology, and surface acoustic wave technology, as well as other proximity sensor arrays or other elements for determining one or more points of contact with the touch-sensitive display.

[0207] In addition, the I / O subsystem may be coupled to one or more other physical control devices (not shown), such as buttons, keys, switches, joysticks, dial pads, slide switches, joysticks, LEDs, etc., for controlling or performing various functions, such as power control, speaker volume control, telephone ring volume, keypad input, scrolling, holding, menus, screen lock, clearing, and ending communication. In some embodiments, in addition to the touchscreen, device 1700 may also 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 visual output. The touchpad may be a separate touch-sensitive surface from the touch-sensitive display, or an extension of the touch-sensitive surface formed by the touch-sensitive display.

[0208] In some implementations, an application executing on a user's device may be used to perform some or all of the operations described herein. 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, depending on the specific implementation, such configuration can be accomplished through the design, setup, interconnection, and / or programming of particular components, and again, depending on the specific implementation, the configured components may be reconfigurable or not reconfigurable for different operations. For example, a programmable processor can be configured by providing appropriate executable code; a dedicated logic circuit can be configured by appropriately connecting logic gates and other circuit elements; and so on.

[0209] Any software component or function described in this patent application may be implemented as software code executed by a processor using any suitable computer language, such as, for example, Java, C, C++, C#, Objective-C, Swift, or a scripting language such as Perl or Python using, for example, conventional or object-oriented techniques. 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-transitory computer-readable media may include random access memory (RAM), read-only memory (ROM), magnetic media (such as hard disk drives or floppy disks), or optical media (such as optical discs (CDs) or DVDs (Digital Multifunction Disks)), flash memory, etc. The computer-readable medium may be any combination of such storage or transmission devices.

[0210] Computer programs incorporating various features of this disclosure can be encoded on a variety of computer-readable storage media; suitable media include magnetic disks or magnetic tapes, optical storage media such as optical discs (CDs) or DVDs (Digital Multipurpose Discs), flash memory, etc. Computer-readable storage media encoding program code can be packaged with compatible devices or provided separately from other devices. Furthermore, program code can be encoded and transmitted via wired, optical, and / or wireless networks conforming to various protocols (including the Internet), thereby allowing distribution, for example, via download over the Internet. Any such computer-readable medium can reside on or within a single computer product (e.g., a solid-state drive, hard disk drive, CD, or an entire computer system) and can exist on or within different computer products within a system or network. A computer system may include a monitor, printer, or other suitable display for providing any results mentioned herein to a user.

[0211] As described above, one aspect of the technology of this invention lies in collecting and using data from various sources to improve predictions of users with whom the user may be interested in interacting. This disclosure contemplates that, in some instances, such collected data may include personal information data that uniquely identifies or can be used to contact or locate specific individuals. Such personal information data may include demographic data, location-based data, telephone numbers, email addresses, Twitter IDs, home addresses, data or records related to a user's health or fitness level (e.g., vital sign measurements, medication information, exercise information), date of birth, or any other identifying information or personal information.

[0212] This disclosure recognizes that the use of such personal information data in the techniques of this invention can be used to benefit users. For example, personal information data can be used to predict which users a user might want to communicate with at a particular time and place. Thus, using such personal information data included in contextual information allows for human-centered prediction of which people a user might want to interact with at a specific time and place. Furthermore, this disclosure also contemplates other uses of personal information data that benefit users. For example, health and fitness data can be used to provide insights into a user's overall health status or as positive feedback for individuals using technology to pursue health goals.

[0213] This disclosure anticipates that entities responsible for the collection, analysis, disclosure, transmission, storage, or other use of such personal information data will comply with robust privacy policies and / or privacy measures. Specifically, such entities should implement and adhere to privacy policies and measures that are recognized as meeting or exceeding industry or governmental requirements for maintaining the privacy and security of personal information data. These policies should be readily accessible to users and should be updated as data collection and / or use change. Personal information from users should be collected for legitimate and reasonable entity purposes and should not be shared or sold outside of these legitimate purposes. Furthermore, such collection / sharing should be conducted only after receiving informed consent from users. Additionally, such entities should consider taking any necessary steps to protect and safeguard the right to access such personal information data and ensure that other entities with access to such personal information data comply with the privacy policies and procedures of those other entities. Additionally, such entities may subject themselves to third-party assessments to demonstrate their compliance with widely accepted privacy policies and privacy measures. Moreover, policies and measures should be adapted to the specific types of personal information data collected and / or accessed, and to applicable laws and standards, including considerations of specific jurisdictions. For example, in the United States, the collection or acquisition of certain health data may be governed by federal and / or state laws, such as the Health Insurance Portability and Accountability Act (HIPAA); while in other countries, health data may be subject to other regulations and policies and should be handled accordingly. Therefore, different privacy measures should be advocated for different types of personal data in each country.

[0214] Regardless of the foregoing, this disclosure also contemplates implementation schemes for users to selectively block the use or access to personal information data. That is, this disclosure contemplates providing hardware and / or software components to prevent or block access to such personal information data. For example, with regard to a human-centered prediction service, the inventive technology can be configured to allow users to opt-in or opt-out at any time during or after service registration to participate in the collection of personal information data. In another example, a user may choose not to provide location information to the recipient's suggested service. Furthermore, a user may choose not to provide precise location information but allow the transmission of location area information. In addition to providing "opt-in" and "opt-out" options, this disclosure also contemplates providing notifications related to access to or use of personal information. For example, users may be notified when downloading an application that their personal information data will be accessed, and then reminded again just before the application accesses the personal information data.

[0215] Furthermore, the intent of this disclosure is that personal information data should be managed and processed in a manner that minimizes the risk of unintentional or unauthorized access or use. Once data is no longer needed, this risk can be minimized by restricting data collection and deleting data. Additionally, and where applicable, including in certain health-related applications, data deidentification can be used to protect user privacy. Deidentification can be facilitated, where appropriate, by removing specific identifiers (e.g., date of birth, etc.), controlling the amount or specificity of stored data (e.g., collecting location data at the city level rather than the address level), controlling how data is stored (e.g., aggregating data among users), and / or other methods.

[0216] Therefore, while this disclosure broadly covers the use of personal information data to implement one or more of the various disclosed embodiments, it is also contemplated that various embodiments can be implemented without access to such personal information data. That is, various embodiments of the present invention will not become inoperable due to the absence of all or part of such personal information data. For example, a user's desired communication time and place can be predicted based on non-personal information data or an absolute minimum amount of personal information (such as content requested by a device associated with the user, other non-personal information, or publicly available information).

[0217] Although this disclosure has been described with respect to specific embodiments, it should be understood that this disclosure is intended to cover all modifications and equivalents within the scope of the following claims.

[0218] For all purposes, all patents, patent applications, publications, and specifications mentioned herein are incorporated herein by reference in their entirety. No document is recognized as prior art. In the event of any conflict between this application and the references provided herein, this application shall prevail.

Claims

1. A method performed by one or more processors of a first mobile device, the method comprising: monitoring a strength of a network wireless signal; storing a first previous location of the first mobile device at a first previous time when the strength of the network wireless signal is above a threshold; receiving a request to provide information about previous network connectivity of the first mobile device; retrieving the first previous location in response to the request; and providing the first previous location to a user of the first mobile device.

2. The method of claim 1, wherein storing the first previous location comprises: storing strength information of the network wireless signal at one or more times in a first table; and storing locations of the first mobile device at the one or more times in a second table.

3. The method of claim 2, further comprising: determining that the first mobile device is in a non-urban location state; and retrieving the first previous location based on the first previous location being the non-urban location state.

4. The method of claim 3, further comprising: retrieving a set of previous locations between a current location of the first mobile device and the first previous location; and displaying a path from the current location to the first previous location on the first mobile device, the path including the set of previous locations.

5. The method of claim 3, wherein determining that the first mobile device is in the non-urban location state uses one or more of: detectability of other network wireless signals at an earlier time than the first previous time, one or more motion states of the first mobile device at the earlier time, and a classification of one or more map tiles in which the first mobile device camped at the earlier time.

6. The method of claim 5, wherein the classification of one or more map tiles is whether a map tile is within an urban area.

7. The method of claim 1, wherein the first previous location is measured using GPS.

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

9. The method of claim 1, wherein the strength of the network wireless signal is monitored at a second mobile device in local communication with the first mobile device.

10. The method of 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 of claim 1, wherein the network wireless signal is received at the first mobile device.

12. The method of claim 1, further comprising: transmitting a message after the first mobile device arrives at the first previous location, wherein the message is an emergency message.

13. The method of claim 12, wherein the emergency message is an emergency phone call.

14. The method of claim 1, wherein the first mobile device is a wearable device. ​ ​ ​ ​ 15. The method of claim 14, wherein the wearable device is a watch.

16. A mobile device, the mobile device comprising: one or more processors; and a memory coupled to the one or more processors, the memory storing instructions that cause the one or more processors to perform any one or more of the operations recited in claims 1-15.

17. A non-transitory computer-readable medium storing a plurality of instructions that, when executed by one or more processors of a mobile device, cause the one or more processors to perform any one or more of the operations recited in claims 1-15.

18. A method performed by one or more processors of a first mobile device, the method comprising: receiving a target altitude; monitoring a current altitude of the first mobile device; providing a first notification when the current altitude matches the target altitude; disabling notifications after the first notification; continuing to monitor the current altitude of the first mobile device; and enabling notifications when the current altitude differs from the target altitude by more than a threshold amount.

19. The method of claim 18, wherein the first notification is provided when the first mobile device descends in elevation.

20. The method of claim 18, wherein the first notification is provided when the first mobile device ascends in elevation.

21. The method of claim 18, wherein receiving the target altitude comprises inputting the target altitude into the first mobile device by a user via a user interface.

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

23. The method of claim 18, wherein disabling notifications comprises resetting a control signal to a neutral state.

24. The method of claim 18, wherein enabling notifications comprises setting a control signal to a high state or a low state.

25. The method of claim 18, wherein the threshold amount is a programmable altitude.

26. A mobile device, the mobile device comprising: one or more processors; and a memory coupled to the one or more processors, the memory storing instructions that cause the one or more processors to perform any one or more of the operations recited in claims 18-25.

27. A non-transitory computer-readable medium storing a plurality of instructions that, when executed by one or more processors of a mobile device, cause the one or more processors to perform any one or more of the operations recited in claims 18-25. ​ ​

Images