Search using delegated locations

Abstract

A method, a non-transitory machine-readable medium, and a system for providing location services are described. In one embodiment, the method includes, at a delegate server, receiving authentication credentials from a sub-delegate of a delegate entity, determining at least one locator service of a wireless accessory device accessible to the sub-delegate using the received authentication credentials, receiving a request for the at least one locator service from the sub-delegate, evaluating a set of inputs to determine whether a set of conditions corresponding to the at least one locator service and the sub-delegate are met, and upon determining that the set of conditions are met, sending the request for the at least one locator service to a device locator server, and decrypting a response to the request received from the device locator server using an encryption key stored for the delegate entity.

Description

[Technical Field]

[0001] This application claims the benefit of priority to U.S. Provisional Patent Application No. 63 / 484,664, entitled "Find My using Delegated Location," filed February 13, 2023, U.S. Provisional Patent Application No. 63 / 508,197, entitled "Find My using Delegated Location," filed June 14, 2023, and U.S. Non-Provisional Patent Application No. 18 / 439,609, entitled "Find My using Delegated Location," filed February 12, 2024, each of which is incorporated herein by reference.

[0002] The embodiments described herein relate to locating a device using a device locator service. [Background technology]

[0003] Previous device locator services generally provide locator services for wireless devices to owner devices and do not provide meaningful assistance to entities external to the device locator system in locating the device. Thus, there is a need to provide an improved locator service. Summary of the Invention

[0004]

[0003] Embodiments described herein provide a system, a non-transitory machine-readable medium, and a method for providing location services. One embodiment provides, at a delegate server, receiving authentication credentials for a sub-delegate of a delegate entity from a delegate device, determining at least one locator service of an accessory device, where the at least one locator service is accessible to the delegate device using the received authentication credentials, receiving a request for the at least one locator service for the sub-delegate from the delegate device, evaluating a set of inputs to determine whether a set of conditions corresponding to the at least one locator service and the delegate device are met, and upon determining that the set of conditions is met, sending the request for the at least one locator service to a device locator server, and decrypting a response to the request received from the device locator server using one or more encryption keys stored for the delegate entity. Embodiments provide for sending a set of locator services authorized by the role of the sub-delegate to the delegate device using the received authentication credentials. The embodiment further provides at least one condition from the set of conditions that the sub-delegate is associated with the delegate entity, and the at least one condition from the set of conditions is that the accessory device status is not at least one of a close-to-owner status or a close-to-sharee status, and the close-to-owner status includes the owner device within a beacon signal range of the accessory device, and / or sending a response to the request to the delegate device, the response being encrypted using an encryption key generated using a shared secret between the delegate device and the device paired with the accessory device.

[0005] Another embodiment provides for, in an electronic device, determining a set of delegate keys for one or more privacy periods of an accessory device, the one or more privacy periods corresponding to a defined period for sharing a locator service with a delegate entity; sending a request to a delegate server to add the set of delegate keys to the share; sending metadata associated with the delegate entity to the delegate server, the metadata indicating an event with the delegate entity; receiving location information of the accessory device and displaying the location information along with the metadata associated with the delegate entity. Embodiments provide for the delegate entity sending a set of conditions for accessing the set of locator services of the accessory device to the delegate server. Embodiments further provide for sending a set of locator services accessible by sub-delegates of the delegate entity to the delegate server. Embodiments further provide for the metadata including the set of locator services of the accessory device and information regarding the defined period for sharing the locator service. Embodiments further provide for the set of conditions to be provided by the delegate entity. Embodiments further provide for sending at least one shared secret to the delegate device to generate an encryption key.

[0010] Embodiments further provide for transmitting the set of delegate keys and metadata to the delegate device.

[0011] Embodiments further provide for the delegate device and the electronic device to communicate via near field communication, Bluetooth Low Energy, or other wireless protocols.

[0012] Embodiments further provide for the electronic device to be associated with an online account of the owner device paired with the accessory device.

[0013] Embodiments further provide for an electronic device selected from a set of electronic devices associated with a trusted online account, the trusted online account receiving a shared secret from the owner device to generate the delegate keys, the owner device paired with the accessory device.

[0006] Another embodiment provides for sending authentication credentials for a sub-delegate of the delegate entity and information regarding at least one condition for accessing a location service of an accessory device to a delegate server, receiving information regarding a set of accessible location services for the authentication credentials that satisfy the at least one condition, sending a request for locator services of the accessory device to the delegate server, and receiving an encrypted response to the request. An embodiment further provides for receiving a set of a delegate key and metadata from the electronic device, the metadata indicating an event with the delegate entity. An embodiment further provides for receiving a delegate shared secret from the electronic device and decrypting the encrypted response with a decryption key generated in part using the delegate shared secret. An embodiment further provides for the at least one condition for accessing the location service to be determined based on a sub-delegate role in the delegate entity. An embodiment further provides for satisfying the at least one condition by sending location information of the delegate device to the delegate server and receiving an indication that a delegate device with authenticated credentials for the sub-delegate role is at at least one delegate entity location authorized for the request.

[0010] Embodiments further provide for detecting a beacon signal from the accessory device and transmitting location information of the accessory device to at least one of the owner device or a location server. Embodiments further provide for the location information to be encrypted using an encryption key generated using at least a shared secret between the delegate device and a device paired with the accessory device.

[0007]

[0010] Yet another embodiment provides for receiving, at a delegate device, a shared resource locator for accessing a location service of an accessory device, the shared resource locator including a portion of the shared resource locator accessible within an application on the delegate device, the portion of the shared resource locator including an encryption key; sending, via the application, a request to a device locator server to access the location service using the shared resource locator; and decrypting a response to the request from the device locator server using the encryption key within the application.

[0011] Embodiments further provide that the shared resource locator is a uniform resource locator, the portion of the uniform resource locator including an anchor link.

[0012] Embodiments further provide that the application is a third-party application, and the portion of the shared resource locator is stored on a third-party server.

[0008] Another embodiment provides for receiving a resource locator sharing request to access a location service of an accessory device, receiving authentication credentials from a delegate device, evaluating the metadata to determine whether conditions are met for sharing with an authenticated user of the delegate device, and, in response to determining that a set of conditions are met for sharing, sending a response to the delegate device regarding the location service. The embodiment further provides for the metadata including an access policy and a rate limiting policy for the delegate entity. The embodiment further provides for applying a hash function to the identifier to generate a hash result of the identifier, and comparing the hash result to a set of hash results associated with the shared resource locator to determine whether a rate limiting threshold for sharing is exceeded. The embodiment Further provided is evaluating the metadata to determine if a condition is met by determining if the owner device is within beacon signal range of the accessory device. Embodiments further provide for evaluating the metadata to determine whether a condition is met by determining whether a delegate device associated with the delegate entity has designated the accessory device as being near the owner device.Embodiments further provide for receiving, at a third-party server, a resource locator sharing request via a third-party application to access location services of the accessory device. [Brief explanation of the drawings]

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

[0010] [Figure 2] 1 illustrates a system for locating a wireless accessory device, according to one embodiment.

[0011] [Figure 3] 1 illustrates a system for pairing and locating a wireless accessory, according to one embodiment.

[0012] [Figure 4] FIG. 1 is a flow diagram illustrating a method for use in a device locator system, according to one embodiment.

[0013] [Figure 5] 1 is a network operating environment for an electronic device, according to one embodiment.

[0014] [Figure 6] FIG. 1 is a flow diagram illustrating a method for use in a device locator system, according to one embodiment.

[0015] [Figure 7] FIG. 1 is a flow diagram illustrating a method for use in a device locator system, according to one embodiment.

[0016] [Figure 8] 1 is an operating environment for an electronic device, according to one embodiment.

[0017] [Figure 9A] 1 illustrates a delegation user interface according to some embodiments. [Figure 9B] 1 illustrates a delegation user interface according to some embodiments. [Figure 10A] 1 illustrates a delegation user interface according to some embodiments. [Figure 10B] 1 illustrates a delegation user interface according to some embodiments. [Figure 10C] 1 illustrates a delegation user interface according to some embodiments. [Figure 10D] 1 illustrates a delegation user interface according to some embodiments. [Figure 10E] 1 illustrates a delegation user interface according to some embodiments. [Figure 11A] 1 illustrates a delegation user interface according to some embodiments. [Figure 11B] 1 illustrates a delegation user interface according to some embodiments. [Figure 11C] 1 illustrates a delegation user interface according to some embodiments. [Figure 11D] 1 illustrates a delegation user interface according to some embodiments. [Figure 11E] 1 illustrates a delegation user interface according to some embodiments. [Figure 12A] 1 illustrates a delegation user interface according to some embodiments. [Figure 12B] 1 illustrates a delegation user interface according to some embodiments. [Figure 12C] 1 illustrates a delegation user interface according to some embodiments. [Figure 12D] 1 illustrates a delegation user interface according to some embodiments. [Figure 12E] 1 illustrates a delegation user interface according to some embodiments.

[0018] [Figure 13] 1 shows a flowchart of a method that may be performed by a finder device, according to an embodiment. [Figure 14] 1 shows a flowchart of a method that may be performed by a finder device, according to an embodiment.

[0019] [Figure 15] 1 is a flow diagram illustrating a method for broadcasting a signal beacon in a wireless accessory, according to one embodiment.

[0020] [Figure 16] 1 illustrates a delegation user interface according to some embodiments. [Figure 17] 1 illustrates a delegation user interface according to some embodiments.

[0021] [Figure 18] FIG. 1 is a block diagram illustrating an exemplary API architecture that may be used in some embodiments.

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

[0023] [Figure 20] FIG. 1 is a block diagram of a computing system, according to one embodiment.

[0024] [Figure 21] FIG. 1 is a flow diagram illustrating a method for use in a device locator system, according to one embodiment.

[0025] [Figure 22] 1 illustrates a delegation user interface according to some embodiments. [Figure 23] 1 illustrates a delegation user interface according to some embodiments.

[0026] [Figure 24A] 1 illustrates a delegation user interface according to some embodiments. [Figure 24B] 1 illustrates a delegation user interface according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0027] Embodiments described herein generally provide techniques for delegation of an accessory device's locator service to a delegate entity by a device owner. In some embodiments, the techniques are for delegation of an accessory device's locator service to an external entity by a device owner. In some embodiments, techniques are described for sharing an accessory device's locator service by a device owner with a rate-limited set of users, including users who are or are not affiliated with the delegate entity. By rate-limiting the number of users who have a locator service delegated by the device owner, the device locator service can be shared without impacting the performance of the locator service. A device owner can have a mobile device paired with an accessory device, such as a locator tag, and the device owner can have a set of locator services provided on request via a device locator server. The locator service allows the device owner to track and locate the accessory device. The device owner registers the external entity as a delegate entity with the delegate server, and the device owner can select a subset of the device locator services delegated to the external entity for a defined period of time. By registering an external entity as a delegate entity, sub-delegates of the delegate entity may have the right to access the locator service, provided other conditions are met for the sub-delegate.

[0028] An external entity is an entity that is a third-party to the device locator service provider and the device owner. For example, the external entity may be an airline or other service that is entrusted with an item associated with the accessory device or that is obligated to provide services to the device owner regarding the accessory device itself and / or the item associated with the accessory device. In another example, the item may be baggage with an accessory device such as a locator tag attached, and the external entity's airline may be obligated to transport the baggage for the device owner during a scheduled flight. Alternatively, the item may be an accessory device such as Apple AirPods that may be left on the external entity's airplane during a scheduled flight.

[0029] A device owner can select an external entity to act as a delegate entity for a defined period of time, and the device owner can grant the delegate entity access to a subset of the accessory device's device locator services to enable the delegate entity to track and locate the accessory device. In some embodiments, metadata on the owner device related to an event with the delegate entity can be used to automatically establish the defined period of time during which the external entity acts as the delegate entity and / or automatically select the subset of device locator services accessible to the delegate entity. For example, metadata on the device owner's device of a scheduled flight event with the selected airline as the delegate entity, such as a boarding pass or calendar data for the scheduled flight, can be used to determine the defined period of time and the set of locator services to allow the airline to access.

[0030] A delegate entity may have sub-delegates (e.g., a set of employees / agents with employee / agent roles) who use delegate devices authorized to use a subset of the locator services delegated to the delegate entity. Employees of the delegate entity may authenticate with a delegate server using delegate devices. The delegate server may ensure that delegate devices meet a set of conditions to access each device locator service and service device locator requests on behalf of the delegate entity via requests to the device locator server. In some embodiments, the delegate server may have a set of identifiers for sub-delegates or delegate devices associated with the delegate entity. Sub-delegates and / or delegate devices may need to send credentials to the delegate server to be authenticated. The delegate server may ensure that connections or relationships between sub-delegates and delegate entities are maintained by removing sub-delegates that no longer have a relationship with the delegate entity.

[0031] In some embodiments, the delegate server can function as a key escrow with a set of keys for the delegate entity held for the duration of a defined period, and the delegate server can encrypt data sent to or decrypt data sent from the device locator server upon request when the requesting delegate device and / or sub-delegate meets a set of conditions. Because the delegate server is acting as a key escrow, the location data of the accessory device is opaque to both the device locator service provider and the delegate entity. FIG. 1 is a block diagram of a network operating environment 100 for electronic devices, according to one embodiment. The network operating environment 100 includes accessory device(s) 101, a delegate server 107, and multiple electronic devices, such as a mobile device 102. The accessory device(s) 101 can be paired with the mobile device 102. In one embodiment, the accessory device itself can be a tracking device, such as an Apple AirTag®.

[0032] In another embodiment, the mobile accessory device 101 may be a single device or a set of accessory devices. For example, the mobile accessory device 101 may be a smartphone or an Apple AirPod® that includes a set of accessory devices forming a device group (e.g., a left AirPod, a right AirPod, an AirPod case, etc.) that is lost en route to an external entity, such as an airline. While examples describing the mobile accessory device 101 as a locator tag may be provided throughout, those skilled in the art will recognize that the mobile accessory device 101 may be a second owner device, such as a laptop computer, a smartphone, a tablet computer, a wearable computer (e.g., a smartwatch), and / or any other mobile device. The accessory device 101 may be a device associated with the same user account as the owner device 102, and the owner device 102 may be used to delegate locator services for the accessory device 101 to an external entity. In another example, a set of accessory devices may be paired with the mobile device 102, and the set of accessory devices may form a device group. Optionally, the device group with the accessory device 101 may have a wired connection to the accessory device 101 stored internally. In some embodiments, the case itself may be an accessory device 101 that may be paired with the mobile device 102. By way of example, the accessory device 101 may be a collective set of devices such as Apple AirPods® or EarPods®.

[0033] In some embodiments, accessory device 101 may not be able to communicate over a wide area network. In other embodiments, devices 101, 102, and 107 may each be electronic devices capable of communicating over a wireless network. Some exemplary mobile electronic devices include, but are not limited to, smartphones, tablet computers, notebook computers, wearable computers (e.g., smart watches or other wearable computing accessories), mobile media players, personal digital assistants, AirPods®, EarPods®, AirTags®, locator tags, headphones, head-mounted displays, health devices, speakers, and other similar devices.

[0034] The delegate server 107 may be implemented as a set of one or more servers that service requests from the mobile device 102 and the delegate entity's delegate device. Using the mobile device 102, the device owner can select an external entity as a delegate entity and create a shared record of the external entity stored in a shared database with the delegate server 107. The mobile device 102 generates a set of keys expected to be used for the duration of the defined period during which the external entity serves as the delegate entity. In one embodiment, the delegate server 107 is a key escrow that holds the keys necessary to decrypt and encrypt data transmitted between the delegate server and the device locator server. The electronic device 102 and the delegate entity device can use an application programming interface to access the delegate locator service.

[0035] Electronic devices 101, 102, and 107 can communicate over one or more wired and / or wireless networks 110 to perform data communications. For example, wireless network 112 (e.g., cellular network, Wi-Fi network) can communicate with wide area network 114, such as the Internet, by using gateway 116. Similarly, access device 118, such as a mobile hotspot wireless access device, can provide communication access to wide area network 114. Gateway 116 and access device 118 can then communicate with wide area network 114 via a combination of wired and / or wireless networks.

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

[0037] Electronic devices 101, 102, and 107 can communicate with one or more services, such as telephone service 130, messaging service 140, media service 150, storage service 160, device locator service 170, authentication authority 106, and home service 194, via one or more wired and / or wireless networks 110. For example, telephone service 130 can enable telephone communications between mobile devices or between mobile devices and wired telephone devices. Telephone service 130 can route Voice over IP (VoIP) calls over wide area network 114 or can access a cellular voice network (e.g., wireless network 112). Messaging service 140 can provide, for example, email and / or other messaging services. Media service 150 can provide access to media files, such as, for example, song files, audiobooks, movie files, video clips, and other media data. Storage service 160 can provide network storage capabilities to mobile device 101 and mobile device 102 to store documents and media files. Device locator service 170 may enable a user to locate a lost or misplaced device. Home services 194 may enable a user to manage smart home devices in conjunction with a user of home application 192. Other services may also be provided, including a software update service for updating operating system software or client software on mobile devices. In one embodiment, messaging service 140, media service 150, storage service 160, home service 194, and device locator service 170 may each be associated with a cloud service provider, and the various services are facilitated via cloud service accounts associated with electronic devices 101, 102, and 107.

[0038] In some embodiments, accessory device 101 and / or device group 101 and mobile device 102 may be registered with certificate authority 106. In some embodiments, certificate authority 106 is an entity that issues digital certificates, and the service may be implemented using a set of servers managed by a device manufacturer, a service provider, or a registration service. The certificate provided by certificate authority 106 may attest to the validity of received verifiable information about the device, such as the device's specific manufacturer, serial number, device group identifier or other identifier, an indicator that the device is part of a device group, and / or any other verifiable information. In some embodiments, a device manufacturer may establish a device group by grouping serial numbers of accessory devices within the device group. In further embodiments, the certificate may be encrypted by device 101 and / or 102 before being sent to a third party and may be decrypted at an attestation service (e.g., a certificate authority or another attestation service) when the third party requests verification of information provided by accessory device 101, mobile device 102, smart home device, and / or devices in a device group. In some embodiments, the secure token may be provided in a pairing request by accessory device 101. Additional examples of devices paired using location services can be found in U.S. Patent Application No. 17 / 219,595, filed March 21, 2021, entitled "Secure Pairing and Pairing Lock for Accessory Devices," which is incorporated herein by reference in its entirety.

[0039] The electronic devices 101 and 102 may have locally accessible applications, services, and features on the device. In particular, the mobile device 101 and / or 102 may have a device locator application (e.g., a "Find" application) 190 for utilizing the device locator service 170 and location service 180. Locally accessible data may be stored in known locations 182 and secure or trusted locations 184. In some examples, a machine learning algorithm 186 may be used to identify user routines, known locations 182, and / or trusted locations 184. Cluster analysis is provided as an example of a machine learning algorithm that may be used, but those skilled in the art will recognize that other algorithms may be used to identify potential known or trusted locations. By way of example, cluster data analysis may be used to identify, classify, and provide semantic labels for locations or defined spaces, such as locations frequently visited by a user. Secure or trusted locations 184 may be explicitly designated or confirmed as such by the user of the mobile device 102 after data analysis. Additionally, user routines may be explicitly defined by the user of the mobile device 102. In other examples, known locations 182, trusted locations 184, and user routines may be classified offline and provided by the device locator service 170, a home application or service, or a third party (e.g., a database with map information, a home hub device, etc.).

[0040] On-device heuristics and / or machine learning models can be used to infer relationships between users and locations (e.g., including defined spaces) based on analysis of locally stored data about frequently visited locations, including user-frequently visited locations, known locations, routines, and / or any other locations. For example, frequently visited locations such as home, vehicle, workplace, any location frequently visited by a user with a mobile device (e.g., accessory device 101 and mobile device 102), and / or any other location designated by the user as a trusted location 184. Known locations 182 can be business locations, public spaces, parks, museums, front yards, back yards, and / or any other locations that a user may frequently visit. Boundary information for each stored location can be stored along with a classification type for the location and any semantic labels assigned to the location. The stored information can include a defined set of boundaries or a radius distance around a point location to enable creation of a geofence for the location. A geofence is a virtual boundary of a real-world geographic area. A global positioning system (GPS) can be used to create a virtual fence around a location and track the physical location of electronic devices 101 and 102 within the geofence perimeter, as well as the entrances and exits of the bounded area.

[0041] The machine learning algorithm 186 may include on-device heuristics, machine learning algorithms, or a combination thereof to analyze and assign labels for the device's movements or journey designated as “in transit,” “in motion,” or “stable” within a defined space over a period of time. The analysis may be performed using various signals from data sources available to the mobile device 102, including, but not limited to, sensor data, positioning data, calendar data, transit card usage data, application data, historical data regarding travel patterns / routines, and / or any other data accessible to the mobile device 102. In some embodiments, the mobile device 102 may be classified with a “stable” semantic label after remaining within the geographic boundaries defining a location (e.g., trusted location 184) for a defined period of time. Positioning data for the mobile device 102 may remain within the boundaries of a geofence for a particular location for a duration (e.g., 5 minutes). Sensor data, such as accelerometer data, may indicate that the mobile device 102 is stationary, supporting the inference that it is stable.

[0042] Application data can support the inference that the mobile device 102 is in a stable state, such as being located at a calendar reservation location. Application data indicating the type of application in use can also provide an inference of a stable device, such as using a media application and / or a smart home device. A user's historical data regarding routines or patterns while traveling can be used to determine whether the mobile device 102 is stable within a defined space, such as a bedtime routine at home or a hotel location. A mobile device 102 can be classified as having an "in transit" label based on previous behavior, patterns, or routines for the user and analyzed on the mobile device 102. For example, a user may have a routine of going to work at the same time every day, and if data on the device supports that the pattern is repeating, an "in transit" state can be assigned. In another example, the speed at which the mobile device is moving or entering and leaving a known geographic area (e.g., using a geofence) can allow for the inference that the mobile device 102 is in transit. If the mobile device 102 is detected accelerating in a known transit area (e.g., road, highway, railroad line, etc.), the mobile device 102 may be given a status of "in transit." Similarly, if a transit application / card is used / in use, the mobile device 102 may be designated as "in transit."

[0043] 2 illustrates a system 200 for locating a wireless accessory device 201, according to one embodiment. The wireless accessory device 201 may be the accessory device 101 described with reference to FIG. 1. In one embodiment, the wireless accessory device(s) 201 are locator tags associated with an item such as luggage, and the accessory device 201 is paired with the mobile device 102. Each accessory device 201 includes one or more wireless transceivers and can communicate either directly or indirectly (e.g., through another device or computer) with a companion device (e.g., the mobile device 102) over a wireless network or a peer-to-peer communication link. The accessory device(s) 201 can provide a beacon signal to one or more accessory devices, and / or each accessory device 201 can be found independently and separately by each providing a beacon signal. Some examples of wireless accessory devices 201 include, but are not limited to, wireless earbuds, EarPods, Apple AirPods, input devices, charging devices, accessory cases, headphones, headsets, fitness equipment, health equipment, display devices, external hard drives, other wearable device (e.g., smart watches, fitness bands, optical head-mounted displays) adapters, speakers, device locator tags, and / or any other mobile device. A paired group of accessories may be devices of the same type (e.g., speakers, AirPods, fitness weights, etc.) or different types (e.g., smartphones and credit card readers, etc.).

[0044] The wireless accessory device 201 may also include other wireless devices, such as input devices, including, but not limited to, a credit card reader, a stylus device, a mouse, a keyboard, a game controller, and / or a remote control. In one embodiment, the wireless accessory 201 also includes a smartphone, a tablet computer, a laptop computer, a smart speaker device, a television, or a television set-top box that is at least temporarily unable to access a wide area network such as the Internet (e.g., wide area network 114 of FIG. 1 ). The wireless accessory 201 may also be any other wireless device, including a beacon or locator tag that can be attached to other devices to enable tracking or locating the other devices. In one embodiment, the wireless accessory 201 may be from a device group of accessory devices that are paired with the mobile device 102 using a wireless technology standard, such as, but not limited to, Bluetooth. The wireless accessory 201 may also communicate with the mobile device 102 and / or a delegate device via wireless technology, including implementations of any wireless standards and protocols, such as Wi-Fi Direct, Zigbee, or AirPlay. The companion device with which the wireless accessory 201 is paired is generally referred to as the mobile device 102, although the companion device is not limited to a mobile device. The companion device may also include a laptop or desktop device in some embodiments, as well as some wearable accessories, such as, but not limited to, a smartwatch device or a wearable display.

[0045] In one embodiment, the wireless accessory 201 may periodically transmit a wireless beacon signal. The wireless accessory 201 may transmit the beacon signal using one of the various wireless technologies described herein (e.g., Bluetooth, Wi-Fi, etc.), and in one embodiment may also transmit the beacon using ultra-wideband (UWB) wireless technology. The beacon signal may be transmitted using a single wireless technology, one of multiple selectable wireless technologies, or multiple simultaneous wireless technologies. The beacon signal may transmit a beacon identifier that includes information to specifically identify an individual wireless accessory 201 and / or a device group. In one embodiment, the beacon identifier is a public encryption key associated with the device.

[0046] The beacon signal may also convey information about the wireless accessory 201, such as device status information and / or verifiable information. The device status information in the beacon signal may include, but is not limited to, a beacon type, a device classification, a battery level, any predefined device status, a device state, a lost status, an alarm status, a status away from owner, a status near owner, proximity to one or more accessory devices in a device group status, a wired or wireless connection status, a physically connected to one or more accessory devices in a device group status, a pairing status indicating whether the accessory device is paired or unpaired, a pairing pending status, a battery life status, a charging status, a status near a smart home device, a status near a recipient device, an established status near an external entity, and / or any other status information. The status near owner may indicate that the wireless accessory 201 has detected the nearby presence of a mobile device 102 associated with the accessory's owner. The lost or “away from owner” status may indicate that the wireless accessory 201 has determined itself lost or has been placed in a lost state by the device's owner. The alarm status may indicate that the wireless accessory device 201 has been placed in a state that should trigger an alarm if the wireless accessory device 201 is moved from its current location. The near smart home device status may indicate that the wireless accessory device 201 is in communication with a smart home device of an owner device and / or a finder device. The sharee device status may indicate that the wireless accessory device 201 is in communication with a recipient (e.g., a sharee) of a key share from the owner of the wireless accessory device 201. A sharee is a recipient of a key share of a wireless accessory device. A sharee may be a user to whom the owner (or another sharee) has directly entrusted location services and / or a sub-delegate of a delegate entity.If the owner of the wireless accessory device 201 establishes that the sharee can share a key with another recipient, the key sharing allows the sharee to use a particular location service and / or create a key share for the wireless accessory device. The establishment status near an external entity may indicate that the wireless accessory device 201 is located near an establishment of an external entity, such as an airline check-in desk or a baggage storage facility.

[0047] In some embodiments, verifiable information may include any information that may be needed to establish trust or authority that a pairing process, setup process, device discovery process, and / or finding process may proceed with a device presenting the verifiable information. By way of example, verifiable information may include information established by a device manufacturer, such as a serial number or set of serial numbers within a device group or smart home device. In some embodiments, verifiable information may include status or state information of a device. The verifiable information may include, but is not limited to, a device type, membership in a device group, a serial number, a device group, serial numbers of other devices in the device group, state or status information, software version, and / or any other verifiable information. The verifiable information may be transmitted to a certificate authority 106 or other attestation service to verify received information presented by the device to another device. The verifiable information may be encrypted and / or transmitted with a token to enable further verification of the device.

[0048] In some embodiments, the beacon signals can be detected by a finder device 202 in local proximity to the wireless accessory 201 to use crowdsourcing to locate the lost wireless accessory 201. In further embodiments, the delegate device can provide additional functionality as the finder device 202. The finder device 202 can be a device similar to the mobile device 102 and can transmit and receive data over the wide area network 114 and using similar wireless technologies (e.g., Bluetooth, etc.) as the wireless accessory 201. In particular, the finder device 202 can receive data using the wireless protocol over which the beacon signals are transmitted. The finder device 202 can determine its location using one or more location and / or positioning services, including, but not limited to, satellite positioning services 206 or terrestrial positioning systems using RF signals received from wireless base stations 205, such as Wi-Fi access points or cell tower transmitters of a cellular telephone network. In one embodiment, the finder device 202 periodically stores its location determined based on one or more location and / or positioning services. The stored location may be associated with a timestamp at which the location was determined. When the finder device 202 receives a beacon signal from the wireless accessory 201, the finder device 202 may transmit the location of the finder device 202 to the device locator server 203 over the wide area network 114. The timestamp of the determined location of the finder device 202 may be correlated with the timestamp at which the beacon signal was received to associate a geographic location with the received beacon signal.

[0049] If the wireless accessory 201 provides a public key in the beacon signal, the finder device 202 can encrypt the determined location data and transmit the encrypted location data to the device locator server 203 over the wide area network 114. In one embodiment, additional data can be encrypted and transmitted with the location data, or transmitted unencrypted to the device locator server 203. For example, the RSSI of the beacon signal can be transmitted along with the location data. The RSSI data can then be used to determine the distance of the wireless accessory 201 from the finder device 202 and assist in triangulation on the owner device. If the RSSI data is transmitted unencrypted, in one embodiment, the server can use the RSSI information to reduce noise by discarding very weak signals in the presence of other stronger signals. In one embodiment, UWB ranging data can also be provided, where such data is available.

[0050] In some embodiments, beacon signals from the wireless accessory 201 can be detected by a delegate device, which is a variation of the finder device 202. The mobile device 102 can send a request via the delegate server 107 to perform a beacon scan to determine whether the delegate device can detect the beacon signal transmitted from the wireless accessory device 201. Alternatively, the mobile device 102 may communicate directly with the delegate device. In some embodiments, the mobile device 102 can be authorized to send a data packet with the request that includes one or more public keys to identify advertisements from the wireless accessory device 201. If the delegate device detects a beacon signal from the wireless accessory device 201, the delegate device can communicate to the mobile device 102 that the beacon signal was received via the delegate server 107. For example, if a beacon signal from the wireless accessory device 201 includes an advertisement with a key from one or more public keys transmitted by the mobile device 102, the delegate server 107 can respond to the request by transmitting location information (e.g., ranging data, signal strength information, etc.) of the wireless accessory device 201 to the mobile device 102 and / or the device locator server 203.

[0051] In one embodiment, location information of the wireless accessory device 201 received from the delegate device 107 may be transmitted encrypted or unencrypted to the mobile device 102 and / or the device locator server 203. A received signal strength indicator (RSSI) of the beacon signal may be transmitted to the mobile device 102 along with location data of the wireless accessory device 201. The RSSI data may then be used to determine the distance of the wireless accessory 201 from the delegate device and to assist triangulation on the mobile device 102. The location information provided to the mobile device 102 may include information regarding the location of the wireless accessory 201 within the location environment. If the RSSI data is transmitted unencrypted, in one embodiment, the device locator server 203 and / or the mobile device 102 may use the RSSI information to reduce noise by discarding very weak signals in the presence of other, stronger signals from other devices.

[0052] In one embodiment, when the finder device 202 receives a beacon signal from the wireless accessory 201, it can behave differently depending on the device status communicated by the wireless accessory 201. For standard beacon signals, the finder device 202 can queue encrypted location data and transmit the location data to the device locator server 203 during periodic transmission windows. However, if the wireless accessory 201 indicates an alarm state, the finder device 202 can immediately transmit the location data to the device locator server 203. If the smart home device receives an indication that the wireless accessory device 201 is in an alarm state, the smart home device can immediately play a media file on behalf of the wireless accessory device 201. Additionally, if the beacon signal of the wireless accessory 201 indicates that the accessory is near the accessory's owner, the finder device 202 may not transmit the location data to the device locator server 203. Alternatively, the finder device 202 may delay transmitting the encrypted location data.

[0053] When the owner of the wireless accessory 201 wants to locate the wireless accessory device 201, the owner can access a device locator user interface (UI) 204 on the mobile device 102. The device locator UI 204 can be associated with a device locator application used to find electronic devices and accessories registered to a user's online account, such as a cloud service account or another type of online account. The device owner can use the device locator UI 204 to query the device locator server 203 for location data that may have been sent to the device locator server by the finder device 202 of the wireless accessory 201. In one embodiment, the mobile device 102 can send a public encryption key associated with the wireless accessory 201 to the device locator server 203. The device locator server 203 can then return any stored location data that corresponds to the public encryption key. The location data returned to the mobile device 102 can be encrypted data encrypted by the finder device 202 using the public encryption key. The mobile device 102 can decrypt the encrypted location data using the associated private key. The decoded location data may then be processed by the mobile device 102 to determine the most likely location of the wireless accessory 201. In various embodiments, the most likely location of the wireless accessory 201 may be determined by triangulation from multiple received locations and using other data, such as the beacon signal RSSI associated with each location and timestamps or UWB ranging data included within the location data.

[0054] 3 illustrates a system 300 for pairing and locating a wireless accessory device according to embodiments described herein. In one embodiment, a mobile device 102 (e.g., an example of the device 101) of a user of a wireless accessory 201 can present an accessory pairing UI 302 that allows the user to pair the mobile device 102 with the wireless accessory 201. During the initial pairing (305) between the mobile device 102 and the wireless accessory 201, a public key exchange (310) can be performed between the mobile device 102 and the wireless accessory 201. In one embodiment, during the public key exchange (310), the mobile device 102 and the accessory 201 exchange public keys of a public key pair generated by the device and the wireless accessory 201. In one embodiment, the public key exchange (310) is a one-way transfer in which the mobile device 102 sends the public key of a public / private key pair to the wireless accessory 201. Alternatively or additionally, the public key exchange (310) can be a Diffie-Hellman key exchange in which the device and the accessory establish a shared secret between the two parties. In one embodiment, the public key exchange (310) further establishes a shared secret using elliptic curve cryptography. For example, elliptic curve Diffie-Hellman (ECDH) may be used to enable the establishment of a public key pair and one or more shared secrets. In one embodiment, the one or more shared secrets include an anti-tracking secret that may be used by wireless accessory 201 to periodically derive additional public keys.

[0055] After the wireless accessory 201 is paired with the mobile device 102, the wireless accessory 201 can periodically broadcast a beacon signal 301 that includes device status information and a beacon identifier. In one embodiment, the beacon identifier is a public key derived from a shared secret established during a public key exchange (310). Additionally, the wireless accessory 201 can periodically perform a public key derivation (315) to generate a new public key and begin broadcasting the new public key as a beacon identifier. The public key is a K-byte key, and a new K-byte key is generated every M minutes. The values ​​K and M can vary between embodiments. In one embodiment, a K value of 28 bytes is used. In one embodiment, a K value of 27 bytes is used. The value K can be determined based at least in part on a beacon length associated with a wireless protocol used to transmit the beacon signal 301. In one embodiment, the beacon signal can transmit a variant of a beacon advertisement packet associated with a low energy wireless protocol, such as Bluetooth Low Energy.

[0056] In one embodiment, the value M is 15 minutes, and a new K-byte key is generated every 15 minutes. The public key can be derived deterministically based on the timestamp and the anti-tracking secret generated during public key exchange 310. The public key derivation (315) process allows wireless accessory 201 to use different keys over time, preventing long-term association of a particular key with a particular device. The key can be derived based on the anti-tracking secret known only to mobile device 102 and wireless accessory 201, allowing only mobile device 102 and wireless accessory 201 to determine which public key is broadcast by wireless accessory 201 at any given timestamp. The anti-tracking secret can be generated along with the ECDH public key and transferred to wireless accessory 201. The anti-tracking secret can then be used by wireless accessory 201 to derive the sequence of public keys P iIn one embodiment, the sequence of public keys P i =λ i ·P is a scalar or exponential value λ i We define a group operation between a scalar or exponent value λ=KDF(AT,i), where KDF is a key derivation function, AT is an anti-tracking secret, and i is a counter or timestamp.

[0057] In one embodiment, backtracking resistance can be enabled to protect the anti-tracking secret if wireless accessory 201 is compromised. When backtracking resistance is enabled, the anti-tracking secret is transferred to wireless accessory 201 but is not retained by the wireless accessory. Instead, the accessory uses the value λ i+1 =H(λ i || time), where λ = A T and H is a cryptographic hash function. Wireless accessory 201 then computes λ for a given time period i. i If the wireless accessory 201 is damaged, λ for the current and future values ​​of i is stored. i In one embodiment, the backtracking resistor is stored in the non-volatile memory of the wireless accessory 201 as λ i This is done by periodically writing

[0058] In one embodiment, the wireless accessory 201 may transmit a beacon signal 301 every two seconds, although other beacon rates may be used, and the beacon rate may change under certain circumstances. For example, the wireless accessory 201 may decrease its beacon rate when in close proximity to its owner. The beacon rate may also change based on an event triggered by an accelerometer. For example, the wireless accessory 201 may increase its beacon rate when in an alarm state, which may be triggered by an accelerometer on the wireless accessory 201.

[0059] The wireless accessory 201 may enter the near-owner state if, after transmitting the beacon signal 301, the wireless accessory 201 receives a response from the mobile device 102 associated with the accessory's user indicating that the mobile device 102 is within range of the wireless accessory. Additionally, while the wireless accessory is in the near-owner state, the amount of data transmitted by the beacon signal 301 may be reduced. In one embodiment, the rate at which new public keys are generated may also be reduced while the wireless accessory is in the near-owner state.

[0060] The wireless accessory 201 can enter an alarm state upon receiving a message from the mobile device 102 indicating that the wireless accessory 201 should enter an alarm state. When in the alarm state, the wireless accessory can first enter an armed state in which the wireless accessory 201 can reduce or stop transmitting locator beacon signals, although other types of wireless signaling can continue. The wireless accessory 201 can remain in the armed state until the state is deactivated by the mobile device 102 or an alarm is triggered. In one embodiment, the alarm can be triggered when movement is detected, for example, via an accelerometer within the wireless accessory 201. In one embodiment, the alarm can also be triggered when the wireless accessory 201 detects that it has moved out of range of the mobile device 102 and is no longer near its owner. When an alarm is triggered, the rate of the beacon signal 301 can be increased to increase the speed at which the wireless accessory 201 can be located.

[0061] The beacon signal 301 transmitted by the wireless accessory 201 can be detected by a set of finder devices 303 (the finder devices can be finder devices 202) and / or mobile devices 102, which are other electronic devices that can receive the beacon signal transmitted by the wireless accessory and transmit location and other data associated with the beacon signal 301 to the device locator server 203 over the wide area network 114. In one embodiment, the set of finder devices 303 can include variations of mobile devices 102 or can be other types of electronic devices. For example, the set of finder devices 303 can perform an operation (320) to correlate the beacon signal 301 received from the wireless accessory 201 with a device location associated with the finder devices 303. As described with respect to FIG. 2 , device location can be determined via a satellite positioning service or a terrestrial positioning system using RF signals received from wireless base stations (e.g., Wi-Fi access points or cell tower transmitters). In one embodiment, the set of finder devices 303 may also include fixed devices such as smart speaker devices, televisions, or television set-top boxes that are capable of receiving the beacon signals 301 .

[0062] The set of finder devices 303 may encrypt the location data using the beacon identifier (e.g., public key) received in the beacon signal 301 and transmit the location data (325) to the device locator server 203. The data transmitted by the set of finder devices 303 is transmitted anonymously, and the identification information of the finder devices is not stored with the data transmitted by the finder devices.

[0063] The device locator server 203 can store the encrypted location data in a data store 304, which in one embodiment can be a distributed database having multiple nodes. A hash of the accessory's beacon identifier / public key can be transmitted along with the encrypted location data. The encrypted location data can be stored in a database node based on the hash of the beacon identifier. The encrypted location data can be indexed by the device locator server 203 using the hash of the beacon identifier. Transmitting the hash of the beacon identifier instead of the full beacon identifier prevents storage of the full beacon identifier in the server. Other information, either encrypted or unencrypted, can also be transmitted and stored along with the location data. The other information can include a timestamp of when the beacon signal 301 was received, RSSI information of the received beacon, and / or ranging information determined, for example, via UWB ranging.

[0064] When a user or owner of the wireless accessory 201 wishes to locate the accessory, the user or owner can access a device locator UI 204 on the mobile device 102. The device locator UI 204 may be associated with the locator application 190 or a feature of the mobile device 102. The device locator UI 204 may also have a web-based interface that can be accessed from the mobile device 102 or another type of electronic device, such as a laptop or desktop device. Once the mobile device 102 loads the device locator UI 204, the mobile device 102 can send a request (330) for location data to the device locator server 203. The request 330 can include a set of public keys or public key hashes that can serve as beacon identifiers for the beacon data. The mobile device 102 can generate a set of public keys based on secret information maintained by the mobile device 102 and the wireless accessory 201 and a timestamp at which the mobile device 102 wishes to receive location data. In one embodiment, the set of public keys is generated based on a sequence P of public keys generated based on an anti-tracking secret. i The sequence of public keys P i is the matching sequence of the private key d i The mobile device 102 receives the sequence of public keys and the corresponding sequence of public keys d i where i is a counter or timestamp. In one embodiment, the mobile device 102 may generate a public key for the previous 24 hours (or a hash of the 24 hour public key) and send it in the request 330. If no data is found for the 24 hour public key, the mobile device 102 may send a generated key for an earlier period to revert to a predetermined location data retention limit.

[0065] In one embodiment, the encrypted location data is stored and indexed based on a hash of the public key instead of the public key to prevent location service data providers from storing data that can be used to tie the encrypted location data to a particular device and therefore a particular user or user account. A finder device can transmit a hash of the public key broadcast in a beacon signal 301 associated with the observed location. The device owner can query the device locator server 203 using the hash of the public key determined for the query period.

[0066] In some embodiments, when a location query is performed via a web-based interface from an electronic device such as a laptop or desktop device, a key to enable decryption of the location data may be required to be sent to the electronic device. In one embodiment, a location data decryption key may be sent to a server providing the web-based interface to enable the server to decrypt the location data, at least while the location data is being viewed via the web-based interface. Before the location data is displayed via the web-based interface, a notice may be presented to inform the user that a location decryption key has been temporarily shared with the web-based interface server to enable the location data to be decrypted and presented. In one embodiment, the sharing of the location decryption key may be performed via automatic and temporary delegation of location query rights by a proxy account associated with the web-based interface.

[0067] In one embodiment, the wireless accessory 201 can be placed in simple lost mode. In simple lost mode, a set of future public keys can be generated for the wireless accessory and sent to the device locator server 203. The device locator server 203 can then notify the mobile device 102 whether any location data corresponding to a key in the set of future public keys has been received. In one embodiment, a finder device transmitting the location of a wireless accessory in simple lost mode can instruct the device locator server 203 to relay a message to the wireless accessory 201 informing the wireless accessory that it is in simple lost mode. A similar mechanism can be used to relay a message to the wireless accessory 201 to place the accessory in explicit lost mode. Explicit lost mode can be enabled by the user via the device locator UI 204. In explicit lost mode, the wireless accessory 201 cannot be paired with another device unless it is unlocked by the owner. Further examples of paired devices using location services can be found in U.S. Patent Application No. 16 / 543,227, entitled "A System and Method for Locating Wireless Accessories," filed August 16, 2019, which is incorporated herein by reference in its entirety.

[0068] Figure 4 is a flow diagram illustrating a method for use with a device locator system according to one embodiment described herein. Figure 4 illustrates a method 400 for pairing a mobile device with a wireless accessory. Aspects of method 400 are also illustrated in Figures 2 and 3, as discussed above. For example, the following operational description refers to a mobile device 102, a wireless accessory 201, and a device locator server 203.

[0069] As shown in FIG. 4 , method 400 includes an act of performing (402) initial pairing with a wireless accessory. The initial pairing can be Bluetooth pairing or another type of pairing using other wireless technologies. During initial pairing, the mobile device and wireless accessory can exchange identifiers, passkeys, or other authentication information that enables wireless data exchange to occur between the mobile or other electronic device and the wireless accessory. In one embodiment, the initial pairing with the wireless accessory can include an exchange of authentication information associated with the wireless protocol over which pairing is being performed, allowing all data exchanged wirelessly to have at least a first layer of encryption.

[0070] The mobile device may then generate a public / private key pair and one or more additional shared secrets (404). The device may then send the public key and one or more additional shared secrets to the wireless accessory (406). Various key generation techniques may be used. In one embodiment, a variant of ECDH is used to generate the public key pair for encryption. In one embodiment, the one or more additional shared secrets may include an anti-tracking secret that allows the wireless accessory to derive a new public key based on an existing public key.

[0071] After generating the public / private key pair and one or more additional shared secrets, the mobile device may store the public / private key pair in a key store (408). In one embodiment, the key store is a cloud-based key store that can be synchronized with other devices associated with the same cloud service account or family of cloud service accounts with which the mobile device and wireless accessory are associated. The cloud-based key store allows the wireless accessory to be located by other synchronized devices. The mobile device may then register the wireless accessory with a device management server (410). Registering the wireless accessory with the device management server may form an association between the wireless accessory and the cloud service account with which the mobile device is associated. In some embodiments, the mobile device may register the wireless accessory and a device group. Information stored in a device group profile for the device group may also be synchronized among devices bound to the cloud service account (e.g., a user account). The device management server may be associated with other cloud-based servers used to facilitate cloud-based services accessible to mobile devices, such as device locator server 203 of FIGS. 2 and 3 .

[0072] FIG. 5 illustrates a network operating environment for an electronic device, according to one embodiment. FIG. 5 illustrates a system 500 that can delegate access to all or a subset of the locator services of a wireless accessory 530 of an owner device 502 to an external entity for a defined period of time. In one embodiment, the system 500 includes an owner device 502, a delegate device 504, a device locator server 520, a delegate server 534, a third-party server 536, and a wireless accessory 530. The owner device 502 and the delegate device 504 may each be a variation of a mobile device 102 as described herein. The wireless accessory 530 may be a variation of a wireless accessory 201 and / or 101 as described herein. The device locator server 520 may be a variation of a device locator server 203 as described herein. The delegate server 534 may be a variation of a delegate server 107 as described herein. The delegate server 534 may act as a key escrow and perform all encryption and decryption on behalf of the delegate device 504 communicating with the device locator server 520. By restricting the encryption capabilities and underlying location information of the wireless accessory 530 to the delegate server 534, the encryption capabilities and underlying location information remain opaque to the device locator service provider and the delegate entity.

[0073] A user of the owner device 502 can delegate all or a subset of the device locator 520 services to a delegate entity via a delegation UI 503 and a delegate key transfer 505 to a sharing record established on the delegate entity's delegate server 534. The user of the owner device 502 can enable or disable sharing at any time. Delegation can be performed by the owner device 502 generating keys for one or more privacy windows expected for the duration of the trip and providing those keys to the delegate server 534 via a delegate key transfer 505. A privacy window is a predetermined period of time, such as M minutes, during which a set of generated keys associated with the wireless accessory 530 is valid. In one embodiment, there is at least one new key for each privacy window. For example, if the trip is expected to last one hour and the privacy window is 15 minutes, the set of generated keys for a privacy window within that time (e.g., 15 minutes) will include at least four keys. The delegate server 534 can store the delegate key in a shared record in a shared database, and the delegate server 534 can use the delegate key to encrypt and decrypt data exchanged with the device locator server 520 in response to a request by the delegate device 504.

[0074] In one embodiment, a delegate entity (e.g., delegate device, sub-delegate device) can exchange a set of delegate shared secrets between the delegate device 504 and the owner device 502. The exchange of delegate shared secrets enables encryption key generation by both the delegate device 504 and the owner device 502 to exchange encryption keys and / or data in response to location information queries. The exchange of delegate shared secrets may be performed out-of-band from the device locator server 520 and / or the delegate server 534. The exchange of delegate shared secrets may be transmitted between the delegate device 504 and the owner device 502, as shown at 507. In another embodiment, the delegate entity may have a third-party application and, optionally, a corresponding third-party server 536 (e.g., a third-party application server) for the application that facilitates the provision of the delegate shared secret. The delegate shared secret and / or encryption key are generated by the owner device and shared with the delegate entity via the third-party application 536. The delegate shared secret may be stored in the delegate entity's third-party server 536. The delegate entity may determine whether the sub-delegate receives the shared secret and / or encryption key. Data and / or encryption keys encrypted using encryption keys generated using the delegate shared secret may be considered "wrapped" by the delegate shared secret and may be cryptographically verifiable as having been received by a delegate device 504 in possession of a valid delegate shared secret.

[0075] In one embodiment, the owner device 502 can generate a shared resource locator to enable delegation of the locator service. The shared resource locator can include a delegate shared secret for generating one or more encryption keys and / or an encryption key that can be used by the delegate device to encrypt / decrypt data received in response to a request to the device locator service and / or the owner device 502. In one embodiment, the shared resource locator can be implemented as a uniform resource locator (URL), and the delegate device 504 can access the share of the locator service 524 using an application such as a web browser. In another embodiment, the delegate device 504 can access the device locator server 520 using a third-party application provided by a third-party server 536. In the case of a third-party application, the shared secret and / or encryption key may be stored on the third-party server 536 of the delegate device 504. Some embodiments can include the shared secret and / or one or more encryption keys in a portion of the shared resource locator string that is accessed only within an application (e.g., a web browser) on the delegate device 504 and is not sent with a request having the shared resource locator. For example, a portion of the shared resource locator string may be implemented as an anchor link in a uniform resource locator request. The owner device 503 can send the shared resource locator directly to the delegate device 504 (as shown at 507), to the third-party server 536, and / or via the delegate server device 534. One embodiment of a shared resource locator for sharing a locator service is described herein with respect to FIG. 21.

[0076] Metadata on the owner device 502 associated with the delegate entity and / or metadata selected by a user on the owner device 502 to associate with the delegate entity for sharing may be used to determine the number of privacy windows and associated delegate keys to provide to the delegate entity. For example, if a user of the owner device 502 selects to associate a particular flight with a delegate entity, the delegate key generated by the owner device may include the number of expected privacy windows for the duration of the owner's travel and / or the expected duration for which the delegate entity may need to transport baggage for the owner. The metadata may also establish the period of time for which a shared record with a delegate key should reside in the shared database of the delegate server 534. For example, the shared record may be automatically discarded when the duration of the owner's travel is expected to end or when the bag is likely to be retrieved.

[0077] The transferred delegate key may enable the delegate device 504 to perform a set of actions, including but not limited to, tracking, accessing, using, or controlling the wireless accessory 530, via the delegate server 534. For example, the owner device 502 may delegate to the delegate entity the ability 533 to detect the wireless accessory 530 via a beacon signal 531 transmitted by the wireless accessory 530, provided that the delegate device 504 meets a set of conditions. The owner device 502 may also delegate the ability to query 522 the location of the wireless accessory 530 via the delegate server 534, provided that the delegate device 504 meets a set of conditions.

[0078] An authenticated user of a delegate device 504 associated with a delegate entity can access the locator service 522 in response to a request to the delegate server 534 after satisfying a set of conditions. The set of conditions may be established by the device owner and / or the delegate entity. The set of conditions may relate to the state of the owner device 502, the status of the wireless accessory 530, the delegate device 504, and / or the authenticated user of the delegate device 504. The set of conditions may be time-based conditions, geography-based conditions, conditions based on the status of the wireless accessory 530, and / or the location of the owner device 502 or the sharee (e.g., 504) of the owner device. For example, if the owner device 502 is near the wireless accessory 530, the delegate device 504 may not be able to request the device locator service. Continuing with this example, to ensure that locator services are not allowed when the owner device 534 requests them, the following conditions may need to be met for the delegate device 504: the wireless accessory status is not near the owner, the wireless accessory status is not near the sharee, the device locator request is requested during a delegate entity event of the owner device 502, the current or last known location of the wireless accessory was not a safe location of the owner device 502, and / or the user has not explicitly terminated the delegation of the locator services.

[0079] In another example, the geography-based condition establishes that the delegate must be located in a geographic location associated with the delegate entity. Continuing with this example, the delegate entity can use a geofence to determine whether the delegate device 504 is in a geographic location that meets the geography-based condition. In one embodiment, a wireless accessory 530 is defined to be near a particular device if the particular device is wirelessly or physically connected to the wireless accessory 530. In another embodiment, a wireless accessory 530 is defined to be near a particular device (owner device or sharee device) if the particular device is within range to receive a beacon signal from the wireless accessory 530. For example, if the owner device 534 is wirelessly or physically connected to the wireless accessory 530, the owner device 534 is near the wireless accessory. In another example, a delegate of the delegate entity can send information about the location of the accessory device and designate the accessory device as near the owner device. For example, a sub-delegate of the delegate entity can hand the accessory device 530 to the owner, designate the accessory device as the owner device, and designate the accessory device 530 as near the owner.

[0080] In some embodiments, a set of conditions for an authenticated user of a delegate device 504 to access the locator service of a wireless accessory 530 may be implied based on metadata accessible on the owner device 502 associated with an event with the delegate entity. For example, a condition for servicing a device locator request for baggage may be that the owner device 502 dropped off their baggage upon checking in for their flight. The set of conditions for a user of a delegate device 504 may optionally be explicitly provided by the owner device 502 and / or the delegate entity. The delegate entity may establish a set of conditions for accessing the device locator service of a delegate device. For example, the delegate entity may create a set of conditions based on a specific employee role (i.e., role-based conditions), a specific employee, geography-based conditions, wireless accessory status, time-based conditions, delegate device identifier, and / or any other conditions. The delegate entity airline may establish a time-based condition for each agent role that is expected to need device locator services while the item is en route to its destination. For example, a delegate entity airline can set time-based conditions for the use of device locator services for roles such as check-in agents, baggage handlers, baggage retrieval agents, etc. As a further example, check-in agents and baggage handlers may be permitted to play sounds on the wireless accessory only when baggage is expected to be near the check-in agent, and check-in agents may have limited time to use the sound playing feature tied to the expected location of the baggage en route. The allowed device locator services can change dynamically, for example, if the wireless accessory 530 has a lost status.

[0081] The particular functions delegated to the delegate device 504 can be determined based in part on the set of particular keys 507 that are permitted to be used by the authenticated user of the delegate device 504. For example, the employee role of the authenticated user of the delegate device 504 and the location of the delegate device 504 may determine the particular set of keys that are accessible to the delegate device 504. Continuing with this example, a baggage handler located in a baggage storage facility may be permitted to play a sound on the wireless accessory 530 to locate baggage only if the status of the wireless accessory is lost or if the owner is about to miss a flight.

[0082] In one embodiment, the owner device 502 can provide a particular public key 507 directly to the delegate device 504 to enable direct communication with the wireless accessory 530, the delegate server 534, or the device locator server 520. For example, the owner device 502 can provide the public key 507 directly to the delegate device 504 to enable the delegate device 504 to directly request that the wireless accessory 530 play a sound to enable the user of the delegate device 504 to locate a wireless accessory, such as a locator tag attached to luggage. In another example, the locator tag wireless accessory 530 may have a low battery, and the owner device 502 can request that the delegate server 534 provide the public key to enable the delegate device 504 to encrypt and transmit location information about the item, such as luggage, to the device locator server 520. The owner device 502 can create a set of conditions for the delegate device 504 to use the public key. For example, the owner device 502 may provide an agent of a delegate entity, such as a check-in agent or baggage handler, with a set of delegate public keys for a single privacy window of N minutes, allowing the agent to instruct the wireless accessory 530 to play audio, enabling the agent to locate baggage when the wireless accessory 530 has a status of lost and / or not near the owner.

[0083] 6 is a flow diagram illustrating a method for use in a device locator system, according to one embodiment. In flow diagram 600, the owner / shareee device 502 uses an application programming interface (API) to send a request to the delegate server 534 to create a share record and establish a delegate entity for the wireless accessory 530 based on metadata accessible on the owner device 502. While specific examples are provided throughout the description that refer to the owner device 502 delegating locator services, those skilled in the art will recognize that the owner device 502 may share cryptographic information with the sharee device, which may be capable of generating keys in the same manner as the owner device 502 to create a share with the delegate entity as described herein.

[0084] Initially, the owner device 502 may generate (601) delegate keys for one or more privacy windows for the wireless accessory device 530. The number of privacy windows for the wireless accessory and the corresponding number of delegate keys generated may be based at least in part on the expected duration of an upcoming event with the delegate entity. Metadata on the owner device 502 associated with the delegate entity may be used to predict the expected duration of the event. For example, the owner device 502 may associate metadata with the delegate external entity airline, including, but not limited to, calendar data related to the flight, flight number, baggage claim identifier, boarding pass, historical data regarding the airline's flight duration, historical data regarding the average time it takes passengers to retrieve their baggage, flight gate information, baggage carousel location at the arrival airport, weather data, and / or any other information accessible on the owner device 502 that may indicate the duration of the trip and / or the duration for retrieving the baggage. Continuing with this example, the delegate keys are generated according to the number of privacy windows expected during the expected duration that baggage associated with the wireless accessory 530 will be in the airline's custody. In one embodiment, a set of delegate keys may be provided to the delegate server 534 for each device locator request by the delegate device 504, and / or a set of delegate keys may be provided for a portion of a period for sharing the device locator service with the delegate entity.

[0085] While embodiments are described herein with the owner device 502 (or sharee device) possessing the capabilities to maintain and / or create shares, one skilled in the art will recognize that the owner may provide these capabilities to other devices to maintain and / or create shares. The capabilities to maintain and / or create shares include, but are not limited to, generating keys based on secret information (e.g., a shared secret) shared between the owner device 502 and the wireless accessory 530, generating public hashes, accessing metadata, accessing encryption keys, transmitting shared resource locators, and / or generating delegate keys to create shares and / or delegate device locator services. In particular, the user of the owner device 502 may delegate maintenance and / or shares to other devices when the owner device 502 is offline to ensure that stale location information is not provided to the delegate. For example, if the owner device 502 (or a sharee device) is offline, and / or if the owner device 502 is not accessible when a location request is received, and / or if a set of delegate keys is required for generation to service the location request, another device from the set of devices associated with the owner device 502 may be selected to generate the delegate keys.

[0086] The owner device 502 can provide the data and rights necessary to maintain and / or create shares on behalf of the owner. The owner device 502 can grant rights to other devices associated with an online account associated with the owner device. The online account associated with the owner account can be a user account for the owner of the owner device, and the device can be a second device used by the owner of the owner device 502. The online account can be an account from a set of online accounts owned by other users, such as a set of family online accounts or one or more online accounts of a sharee. In one embodiment, a cloud-based (e.g., server-based) key store may provide the share information to provide other devices with the ability to maintain and / or create shares, and the key store can be synchronized with other devices associated with the same cloud service account or family of cloud service accounts to which the owner device 502 and, optionally, the wireless accessory 530 are associated. The set of devices associated with the owner device can be associated with an online account for the user of the owner device, such as a cloud-based (e.g., server-based) service account and / or another type of online account for the user of the owner device 502. For example, one or more of the set of devices associated with the owner device may be used to log in to and / or access online accounts for the user of the owner device 502, such as a laptop, smartphone, wearable device, and / or smart home device. In another example, one or more of the set of devices associated with the owner device is a set of online accounts that the user of the owner device has designated as trusted and shared the ability to generate delegate keys.

[0087] In some embodiments, the other device: In one embodiment, the owner device and a set of other devices associated with the owner device can use a leader election implementation to select a "leader" device from the owner device 502 and the set of devices associated with the owner device 502 to act as the selected device "leader" for maintaining and / or creating shares. A leader device can be selected when the owner device 502 is offline and / or when maintaining or creating shares may be too resource intensive for the owner device 502 from which the request is received.

[0088] The owner device 502 then sends (603) the generated delegate key to the delegate server 534 of the delegate entity. The delegate key enables the delegate device of the delegate entity to utilize the locator service of the wireless accessory device 530 and update location information for items associated with the wireless accessory device. The delegate entity can specify a set of delegate devices 504 and / or delegate agent / employee roles that are authorized to utilize the delegated locator service. The delegate server 534 receives (602) the delegate key and creates a temporary sharing record for the delegate entity and stores (604) the delegate key in the sharing database. The temporary sharing record can exist for the duration of an event for the delegate entity and / or define a set of sharing expiration conditions to cause the sharing record to be destroyed and / or deleted from the sharing database. For example, in the case of an airline delegate entity, sharing expiration conditions may include, but are not limited to, baggage being retrieved by the owner or sharee, trip cancellation, and / or an explicit request by the owner / sharee device 502 to terminate the delegation of the locator service.

[0089] The owner device 502 transmits (605) metadata associated with the delegate entity and, optionally, a set of locator services accessible by the delegate entity. In response, the delegate server 534 determines the delegate entity, a sharing expiration time, a set of conditions for the delegate entity, and / or a delegate entity sub-delegate from the received metadata. Optionally, the owner device 502 may transmit (607) a set of conditions for the delegate entity to access the set of device locator services. Upon receiving an explicit request from the owner device 502, the delegate server 534 may adjust (608) a share for the delegate entity with the set of conditions received from the owner device 502 for the delegate entity and / or delegate entity sub-delegate stored in the share for the delegate entity to access the device locator services.

[0090] In one embodiment, the device locator service is accessible to the delegate entity when a set of actions is performed by the device owner that indicates the initiation of a scheduled event with the delegate entity. For example, the delegate entity airline and its respective sub-delegate agents may be granted access to the device locator service after the device owner checks in and drops off baggage with the airline.

[0091] 7 is a flow diagram illustrating a method for use in a device locator system, according to one embodiment. Initially, the delegate device 502 sends authentication credentials to the delegate server 534 (701). If the delegate server 534 successfully authenticates the user of the delegate device 502, the process continues for the delegate device 502. The delegate server 534 authenticates the delegate device 504 and / or sub-delegate users using the authentication credentials (702). The delegate device 502 may send on-device accessibility condition information for the delegate device 502 and sub-delegate users to the delegate server 534 (703). In parallel with this, or in response to successful authentication by the delegate server 534 (702), the delegate device 502 may send a request for locator services to the delegate server 534 (705). In some embodiments, the request may be sent by the delegate device 502 having a shared resource locator. The resource locator sharing request may be received by the delegate server 534 via the third party server 536 and / or the device locator server 520 .

[0092] The delegate server 534 determines 704 a set of locator services accessible to the authenticated delegate device 504 and / or sub-delegate user. The delegate server 534 determines 704 a corresponding set of conditions that the delegate device 504 and / or sub-delegate user must satisfy for each individual locator service in the set of locator services. By way of example, a delegate device 504 having a particular device identifier and / or being used by an authenticated sub-delegate user can access the following locator services: reporting the location of an item, locating a wireless accessory device, and / or requesting that a wireless accessory device play audio. In one embodiment, a sub-delegate user must satisfy the condition that the sub-delegate user has a particular agent role with the delegate entity (e.g., check-in agent, baggage handler, etc.) in order to access the device locator services. Each locator service in the set of locator services accessible to an authenticated delegate device 502 may have a corresponding set of conditions that must be met in order for the delegate server 534 to respond to the request and / or send a request to the device locator server 520 on behalf of the delegate device 504. For example, a baggage handler may require the following set of conditions to be met in order to play a sound on the wireless accessory device 530: a request to play a sound at an airline baggage claim area must be sent from the delegate device 504 assigned by the delegate entity, the delegate device 504 must be located in the expected area of ​​a baggage storage facility or near an airplane, and the status of the wireless accessory device 530 must be not near the owner.

[0093] In one embodiment, the device locator server 520 receives a resource locator share request 520 from the delegate device 504, where the shared resource locator includes a unique identifier that can be used to look up the shared identifier and corresponding shared key and delegate key at the delegate server. The device locator server can send the request for device locator services and the unique identifier to identify the shared identifier to the delegate server 534 to look up the share and delegate key for the share.

[0094] Upon receiving a request for device locator services, the delegate server 534 receives input regarding all relevant conditions for the requested device locator services, evaluates the conditions, and determines whether to send a request to the device locator server 520 on behalf of the delegate device 504 and / or sub-delegate user. The input evaluated by the delegate server 534 may include, but is not limited to, the status of the wireless accessory device, the location of the item, the location of the owner, the duration of the scheduled event, environmental factors (e.g., weather), the state or location of the delegate device, and / or the sub-delegate authorized user. By way of example, the conditions may be time-based conditions, location-based conditions, conditions related to wireless accessory status, sub-delegate role conditions, user-based conditions, conditions related to accessible device locator services, and / or any combination thereof.

[0095] Optionally, the delegate server 534 may transmit a set of locator services accessible to the delegate device for display and selection on the delegate device (706). If encryption or decryption is required to send or receive a response from the device locator server 520, the delegate server 534 uses an encryption key stored for the delegate entity at the delegate server 534. The delegate server 534 sends a request for locator services to the device locator server 520 if the conditions for the request are met (708). The delegate device 502 receives a response to the selected locator service request from the delegate server 534 (707). In some embodiments, the delegate server may transmit the response to the device locator server 520 to respond to the request, which may then be forwarded to the delegate device 504.

[0096] 8 illustrates an operating environment 800 for electronic devices, according to one embodiment. Devices 101 and 502 may communicate wirelessly via wireless communication signals 605, detect each other by scanning wireless channels, send and receive beacons or beacon frames on the wireless channels, establish connections (e.g., by sending connection requests), and / or send and receive packets or frames (which may include requests and / or additional information, such as data, as payloads). In location environment 808, the mobile delegate device may receive and detect beacon signals from the wireless accessory 101. The wireless communication signals 810 may be carrier signals that comply with wireless communication technologies, such as, but not limited to, Wi-Fi or Bluetooth. In addition to wireless communication, the mobile device 102, the smart home device(s), and / or the wireless accessory device 101 may perform wireless ranging operations using wireless ranging signals 806 (as shown between the mobile device 502 and the wireless accessory device 101). The wireless ranging signal may be, for example, an ultra-wideband signal that can be used to determine the distance and / or angle between the wireless accessory device 101 and the mobile device 102 using the techniques described herein.

[0097] In one embodiment, the wireless accessory 101 may periodically transmit a wireless beacon signal. The wireless accessory 101 may transmit the beacon signal using one of the various wireless technologies described herein (e.g., Bluetooth, Wi-Fi, etc.), and in one embodiment may beacon using ultra-wideband (UWB) wireless technology. The beacon signal may be transmitted using a single wireless technology, one of multiple selectable wireless technologies, or multiple simultaneous wireless technologies. The beacon signal may transmit a beacon identifier that includes information to specifically identify an individual wireless accessory 101 and / or a device group. In one embodiment, the beacon identifier is a public encryption key associated with the wireless accessory device.

[0098] The delegate device 502 can send a request to the delegate server 534 for at least one of the following locator services: a request to update the location of the wireless accessory device along the expected route using a delegate entity, a request to play audio on the wireless accessory, and / or a request to locate the wireless accessory device using locator finding as described in Figures 16 and 17. If conditions are met for the delegate device 502 and the authenticated user of the delegate device 502, the delegate device can provide the locator service. As an example, if the authenticated user has a baggage handler agent role and is at a scheduled airline storage facility, the delegate device can send a request for the locator service.

[0099] 9A-12E illustrate delegation user interfaces according to some embodiments. As shown in FIG. 9A , the device locator UI 204 can present a graphical user interface within the electronic device 900 with the accessory device location 902 of the item 904, “Frank’s Suitcase,” and information is presented from the delegate entity regarding the location status of the baggage, as shown at 908A. As shown in FIG. 9B , the device locator UI 204 can present a graphical user interface within the electronic device 900 with information is presented from the delegate entity regarding the location status of the baggage on the lock screen at various locations, “Drop Off,” “Baggage Depot,” 910, “Baggage Transport,” 912, and “Airplane” 914, within the care of the delegate entity, as shown at 908B. As shown in FIG. 10A , the device locator UI 204 can present a graphical user interface within the electronic device 1000 with the location 1002 of the wireless accessory device, along with a map and presentation of affordances for the device locator services “Play Audio” 1008 and “Find Nearby” 1012 for the item 1006, “Frank’s Suitcase.” 10B, the device locator UI 204 can present a graphical user interface within the electronic device 1000 with an affordance 1010 for sharing the location of an item with an airline and a device locator service 1014 for notification when a wireless accessory device is found or misplaced. As shown in FIG. 10C, the device locator UI 204 can present a graphical user interface within the electronic device 1000 with information about the selected device locator service when the "Continue" affordance 1016 is selected. As shown in FIG. 10D, the device locator UI 204 can present a graphical user interface within the electronic device 1000 with information about a boarding pass 1018 with associated on-device metadata of the owner device that can be associated with a delegate entity.As shown in FIG. 10E, the device locator UI 204 can present a graphical user interface for the device locator services of the electronic device 1000, including "Play Audio" 1008, "Find Nearby" 1012, "Share Location" 1010, and "Notify When Item Found or Left Behind" 1014, for an owner device with a delegate entity "Airline." As shown in FIGS. 11A-11B, the device owner can exchange messages with the delegate entity, the airline, to "Report Lost Baggage," "View Boarding Pass," and / or "Stop Sharing with Affordances," as shown at 1102. As shown in FIGS. 11C-11E, the device owner can report lost baggage by submitting a form with affordance 1106 and exchange messages with an employee of the delegate entity. As shown in FIGS. 12A-12D, on-device metadata associated with a wallet application with selected boarding pass information 1201 can be associated with the delegate entity. As shown in FIG. 12E, the device owner may select to travel with the AirTag 1206 from the lock screen within the device 1200 user interface.

[0100] FIG. 13 shows a flowchart 1300 of a method for enabling location services for a target accessory device, according to one embodiment. As shown in FIG. 13 , method 1300 includes an operation in which an electronic device launches a device locator UI (1301). In response to launching the device locator UI, the electronic device, which may be a mobile device as described herein or another electronic device associated with the same cloud service account as the mobile electronic device, may perform an operation to generate a set of public keys that were included in beacon signals broadcast by the wireless accessory during a first period of time (1302). The first period of time may be, for example, the past 24 hours. The electronic device, knowing the frequency at which the wireless accessory generates new public keys, may use a shared secret key generated with the wireless accessory to generate a set of public keys corresponding to the keys generated by the wireless accessory over the first period of time. The electronic device may then transmit the set of public keys in a request to a device locator server to transmit location data corresponding to the set of public keys (1303). In one embodiment, the location data transmitted by the server in response to the request is encrypted using the public key transmitted as the beacon identifier of the wireless accessory. The electronic device may decrypt the encrypted location data received by the server using a private key generated during initial pairing with the wireless accessory (1304). The electronic device may then process the location data to determine the most probable location for the wireless accessory (1305). In one embodiment, the location data may include data regarding accessory devices 201 in a device group.

[0101] Processing the location data can include a variety of different operations. In one embodiment, the location data includes latitude and longitude information along with a timestamp at which the location was determined. The electronic device can triangulate based on the timestamp to remove noise or outlier locations. In one embodiment, the location data specifies the location of the finder device that detected the beacon. The location data can further include UWB ranging information and / or RSSI information for the beacon detected by the finder device. The electronic device can analyze the UWB ranging information and / or RSSI information in conjunction with the device location to reveal a more precise location of the wireless accessory. Data transmitted by the finder device and that can be used for location processing is shown in FIG. 14 and described below.

[0102] As shown in FIG. 14, method 1400 includes operations that can be performed when the device locator server does not have location data to provide to the electronic device in response to a request. In the case of a device group, the electronic device (e.g., mobile device 102) can provide location data for devices in the device group. The electronic device can generate a first set of public keys that were included in a beacon signal broadcast by the wireless accessory during a first period of time (1401). The first period can be, for example, 24 hours, although other initial search periods can also be used. The electronic device can perform a subsequent operation to request the device locator server to send location data corresponding to the first set of public keys (1402). If data is returned by the server (1403, “Yes”), the electronic device can decrypt the location data received from the server using a private key corresponding to the set of public keys (block 1409).

[0103] If the data is not returned by the server (1403, “No”), the electronic device may generate a second set of public keys that were included in the beacon signals broadcast by the wireless accessory during a second time period (1404). The second time period may be 24 hours, 48 ​​hours, or another time period before the first time period. The electronic device may then request the device locator server to send data corresponding to the second set of public keys (1405). If the data is returned by the server in response to the request (1406, “Yes”), method 1400 may proceed to block 1409, where the electronic device decrypts the received data. If the data is not returned by the server (1406, “No”) or the server sends a response indicating that the data is not available, method 1400 includes the electronic device extending the search time by successively requesting older time periods until the maximum time period is reached (1407).

[0104] FIG. 15 is a flow diagram illustrating a method 1500 of broadcasting a signal beacon in a wireless accessory, according to one embodiment. Aspects of method 1500 are also shown in FIGS. 2 and 3. Method 1500 includes the wireless accessory deriving a public key (block 1502). The public key may be derived based on a shared secret and a timestamp determined based on a clock or timing device of the wireless accessory. Optionally, a determination is made as to whether the wireless accessory is part of a device group (1504). If the wireless accessory is part of the device group, status and / or verifiable information of other accessory devices 201 in the device group is provided in the beacon signal (1506). The wireless accessory may indicate status and / or verifiable information, such as whether any other wireless accessories in the device group are in proximity or connected (physically or wirelessly), and / or any other information regarding other wireless accessories in the device group. In one embodiment, a set of bits included in the beacon signal can represent each accessory in the device group, and setting a Boolean value (e.g., true (1) or false (0)) can indicate whether the individual accessory is in proximity to and / or connected to the accessory device transmitting the beacon signal. Alternatively, if the wireless accessory is not part of a device group, no information about the device group is provided (1504). The wireless accessory can then transmit a beacon signal at a first frequency, the beacon signal including the public key (1508). The first frequency can vary, and in one embodiment is one beacon every two seconds.

[0105] After transmitting the beacon signal, the wireless accessory may listen for a response from the owner device (1510). If the wireless signal receives a response from the owner device (1510, "yes"), the wireless accessory may enter a near-owner state (1512) and begin transmitting a beacon signal at a second, lower frequency (1516). If the wireless accessory does not receive a response from the owner device (1510, "no"), the wireless accessory may continue beacon transmission at the first frequency (1514).

[0106] Method 1500 additionally includes rotating the public key every M minutes while the wireless device is beaconing, where the value of M can vary across embodiments and / or based on device state. Based on a timer expiration, a counter, or another mechanism, the wireless accessory can determine whether the accessory has entered a new key period (1518). While the wireless accessory has not entered a new key period (1518, “No”), the accessory can continue beaconing using the current public key (1522). Upon detecting that the wireless accessory has entered a new key period (1518, “Yes”), the accessory can derive a new public key using the current timestamp (1520). In one embodiment, the new public key can be derived using the existing public key, timestamp, and anti-tracking secret.

[0107] As shown in FIG. 16 , the device locator UI 204 can present a graphical user interface within the electronic device 2100 with a proximity view using signal strength measurements. The proximity view 2124 for locating “Frank’s Luggage” has indicators 2122, 2126, 2130, 2132, 2134, and 2128 at various positions along a trajectory 2138 within the user interface 204. Each indicator may be a user interface element representing proximity to the target wireless accessory device 101 by size, color, shape, color gradient, shading, pattern, and / or any other technique for visual indicators within a user interface. The indicators may be displayed along the trajectory 2138 as the user moves through the location environment. In the proximity view 2104, for example, indicator 2106 is closest to the target wireless accessory device 101 along the trajectory 2138 taken by the user to locate the target wireless accessory device 101, as represented by a darker color and / or larger size compared to the other indicators. In some embodiments, the proximity view of the user interface 204 may present ranging information using ranging measurements and present an arrow 2128 indicating the direction of the target wireless accessory device 101 and the distance 2136 to the target wireless accessory device 101. In other embodiments, the trajectory may be shown in a grid, such as a hexagonal grid, with a visual indicator consisting of areas of the grid designated with color, gradient, shading, and / or any other marking along the trajectory plotted on the grid to represent proximity values ​​for signal strength observed in each area by the mobile device 102, smart home device, and / or combinations thereof.

[0108] In one embodiment, signal strength measurements from signals received at the mobile device 102 may be used to represent proximity to a target device in a user interface to indicate when the mobile device 102 is in proximity to the target device. In some embodiments, signal strength information of smart home devices along a trajectory may be used to present a proximity indicator. A "proximity view" 2104, such as that shown in FIG. 16, may present proximity information using visualization techniques to present proximity information related to the target wireless accessory device 101. In one embodiment, the proximity view 2104 has visual indicators, such as user interface elements positioned along the trajectory 2118 presented in the user interface 204, representing the path the user took in their search. In some embodiments, the visual indicators may be user interface elements displayed using gradients, colors, color gradients, sizes, shapes, and / or any other visualization techniques to represent signal strength values ​​and corresponding defined proximity categories (e.g., far, close, up close, etc.) to the target device. The proximity view 2104 for finding "Frank's Luggage" has indicators 2102, 2106, 2110, 2112, and 2114 at various positions along a trajectory 2118 within the user interface 204. Each indicator within the proximity view 2104 may be a user interface element that represents proximity to the target wireless accessory device by its size and color gradient within the user interface 204. In the proximity view 2104, for example, indicator 2106 is closest to the target wireless accessory device along the trajectory 2118 taken by the user to find the target wireless accessory device, as represented by a darker color and / or larger size compared to the other indicators (e.g., 2102, 2110, 2112, and 2114). Embodiments may use visual inertial odometry (VIO) measurements to determine the trajectory 2118 taken by the user in their search within the user interface 204. VIO provides the ability to track the movement of the mobile device 102 in any initial coordinate system.The VIO technique involves the analysis of a sequence of images collected with a mobile device to estimate camera motion over the sequence of images.

[0109] In some embodiments, the mobile device 102 can move to be within a threshold range of the target accessory device 101, enabling a ranging process using communication between the mobile device and the target device to determine the distance from and direction to the target device. As shown in FIG. 17 , the “ranging view” 2120 of the user interface 204 can provide distance measurements 2116 in addition to a direction 2108 to the target device, which can be selectively displayed. The proximity view 2104 for locating the target device can, in some embodiments, be used when ranging data in the ranging view 2120 is unavailable because the target device is not within a threshold range of the mobile device 102, the target device 101’s transmitter is not in the field of view of a receiver at the mobile device, and / or the mobile device does not have a substantially unobstructed view of the target device 101. The target device 101 can be in the field of view of the mobile device 102 when the receiver at the mobile device 102 has a view of the target device transmitter.

[0110] In some embodiments, ranging using ultra-wideband (UWB) wireless technology may provide relatively accurate location or distance data to the target device, but is a relatively short-range radio frequency (RF) technology wireless communication compared to Bluetooth technology. In some embodiments, it may be desirable for the UWB receiver of the mobile device 102 to have a line of sight to the target device transmitter or a nearly unobstructed view of the target device to obtain optimal ranging location data. Proximity information in the form of signal strength information may be relatively less accurate compared to UWB, but may cover a wider area providing a longer range and can be obtained from advertisements before a wireless connection is established. In some embodiments, two-way communication may not be established using a connection between the mobile device and the target device, but advertisements received at the mobile device may provide signal strength information to help guide the user to the target device before establishing a connection. A combination of technologies can assist a user in locating a target wireless accessory device.

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

[0112] In the following description, a computing device including a touch-sensitive display is described. However, it should be understood that the computing device may include one or more other physical user interface devices. Various applications that may be executed on the device may use at least one common physical user interface device, such as a touch-sensitive surface. One or more functions of the touch-sensitive surface and corresponding information displayed on the device may be adjusted and / or changed from one application to the next and / or within each application. In this way, a common physical architecture of the device (such as a touch-sensitive surface) may support a variety of applications with intuitive and transparent user interfaces.

[0113] Some processes are described below with respect to some sequential operations. However, it should be understood that some of the described operations may be performed in a different order. Furthermore, some operations may be performed in parallel rather than sequentially.

[0114] FIG. 18 is a block diagram illustrating an exemplary API architecture that may be used in some embodiments of the present invention. As shown in FIG. 18, the API architecture 2300 includes an API implementation component 2310 (e.g., an operating system, library, device driver, API, application program, software, or other module) that implements an API 2320. The API 2320 specifies one or more functions, methods, classes, objects, protocols, data structures, formats, and / or other features of the API implementation component that may be used by an API calling component 2330. The API 2320 may specify at least one calling convention that specifies how functions within the API implementation component receive parameters from the API calling component and how the functions return results to the API calling component. The API calling component 2330 (e.g., an operating system, library, device driver, API, application program, software, or other module) makes API calls through the API 2320 to access and use the features of the API implementation component 2310 specified by the API 2320. The API implementation component 2310 may return values ​​to the API calling component 2330 via the API 2320 in response to the API call.

[0115] It will be understood that the API implementation component 2310 may include additional functions, methods, classes, data structures, and / or other features that are not specified through the API 2320 and available to the API invocation component 2330. It should be understood that the API invocation component 2330 may be on the same system as the API implementation component 2310 or may be located remotely and access the API implementation component 2310 using the API 2320 over a network. While Figure 18 shows a single API invocation component 2330 interacting with the API 2320, it should be understood that other API invocation components, which may be written in a different language (or the same language) than the API invocation component 2330, may use the API 2320.

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

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

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

[0119] Sensors, devices, and subsystems may be coupled to the peripherals interface 2406 to facilitate multiple functions. For example, a motion sensor 2410, a light sensor 2412, and a proximity sensor 2414 may be coupled to the peripherals interface 2406 to enable mobile device functionality. One or more biometric sensors 2415(s), such as a fingerprint scanner for fingerprint recognition or an image sensor for facial recognition, may also be present. Other sensors 2416, such as a positioning system (e.g., a GPS receiver), a temperature sensor, or other sensing devices, may also be connected to the peripherals interface 2406 to facilitate related functions. A camera subsystem 2420 and an optical sensor 2422, such as a charge-coupled device (CCD) or a complementary metal-oxide semiconductor (CMOS) optical sensor, may be utilized to facilitate camera functions such as recording photographs and video clips.

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

[0121] Audio subsystem 2426 may be coupled to speaker 2428 and microphone 2430 to facilitate voice-enabled functions such as voice recognition, voice duplication, digital recording, and telephony. In the smart media devices described herein, audio subsystem 2426 may be a high-quality audio system that includes support for virtual surround sound.

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

[0123] In one embodiment, a sensor controller 2444 is included to monitor, control, and / or process data received from one or more of the motion sensor 2410, light sensor 2412, proximity sensor 2414, or other sensors 2416. The sensor controller 2444 can include logic to interpret the sensor data and determine the occurrence of one or more motion events or activities through analysis of the sensor data from the sensors.

[0124] In one embodiment, I / O subsystem 2440 includes other input / control devices 2448 such as one or more buttons, rocker switches, thumbwheels, infrared ports, USB ports, and / or pointer devices such as a stylus, or other input controller(s) 2445 that may be coupled to control devices such as up / down buttons for volume control of speaker 2428 and / or microphone 2430.

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

[0126] Memory 2450 may also store communications instructions 2454 for facilitating communication with one or more additional devices, one or more computers, and / or one or more servers, for example, to retrieve web resources from a remote web server. Memory 2450 may also include user interface instructions 2456, including graphical user interface instructions for facilitating graphical user interface processing.

[0127] Additionally, memory 2450 may store sensor processing instructions 2458 for facilitating sensor-related processes and functions, telephone instructions 2460 for facilitating telephone-related processes and functions, messaging instructions 2462 for facilitating electronic messaging-related processes and functions, web browser instructions 2464 for facilitating web browsing-related processes and functions, media processing instructions 2466 for facilitating media processing-related processes and functions, location services instructions including GPS and / or navigation instructions 2468 and Wi-Fi-based location instructions for facilitating location-based functions, camera instructions 2470 for facilitating camera-related processes and functions, and / or other software instructions 2472 for facilitating other processes and functions, e.g., security processes and functions, and system-related processes and functions. Memory 2450 may also store other software instructions, such as web video instructions for facilitating web video-related processes and functions, and / or web shopping instructions for facilitating web shopping-related processes and functions. In some implementations, the media processing instructions 2466 are split into audio and video processing instructions to facilitate audio and video processing related processes and functions, respectively. A mobile device equipment identifier, such as an International Mobile Equipment Identity (IMEI) 2474 or similar hardware identifier, can also be stored in memory 2450.

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

[0129] 20 is a block diagram of a computing system 2500, according to one embodiment. The illustrated computing system 2500 is intended to represent a range of computing systems (either wired or wireless), including, for example, one or more implementations of a desktop computer system, a laptop computer system, a tablet computer system, a cellular telephone, a personal digital assistant (PDA) including a cellular-enabled PDA, a set-top box, an entertainment system or other consumer electronics device, a smart appliance device, or a smart media playback device. Alternative computing systems may include more, fewer, and / or different components. The computing system 2500 may be used to host a computing device and / or a server device to which a computing device may connect.

[0130] Computing system 2500 includes a bus 2535 or other communication device for communicating information and processor(s) 2510 coupled to bus 2535 that may process information. While computing system 2500 is shown with a single processor, computing system 2500 may include multiple processors and / or coprocessors. Computing system 2500 may further include memory 2520 in the form of random access memory (RAM) or other dynamic storage device coupled to bus 2535. Memory 2520 may store information and instructions that may be executed by processor(s) 2510. Memory 2520 may also be main memory, used for storing temporary variables or other intermediate information during execution of instructions by processor(s) 2510.

[0131] Computing system 2500 may also include a read-only memory (ROM) 2530 and / or another data storage device 2540 coupled to bus 2535 that may store information and instructions for processor(s) 2510. Data storage device 2540 may be or include various storage devices such as a flash memory device, a magnetic disk, or an optical disk, and may be coupled to computing system 2500 via bus 2535 or via a remote peripheral interface.

[0132] The computing system 2500 may also be coupled to a display device 2550 via bus 2535 for displaying information to a user. The computing system 2500 may also include an alphanumeric input device 2560, including alphanumeric and other keys, which may be coupled to the bus 2535 for communicating information and command selections to the processor(s) 2510. Another type of user input device includes a cursor control 2570 device, such as a touchpad, mouse, trackball, or cursor direction keys, for communicating direction information and command selections to the processor(s) 2510 and controlling cursor movement on the display device 2550. The computing system 2500 may also receive user input from remote devices communicatively coupled via one or more network interface(s) 2580.

[0133] Computing system 2500 may further include one or more network interface(s) 2580 for providing access to a network, such as a local area network. Network interface(s) 2580 may include, for example, a wireless network interface having antenna 2585, which may represent one or more antennas. Computing system 2500 may include multiple wireless network interfaces, such as a combination of Wi-Fi, Bluetooth, near field communication (NFC), and / or cellular interfaces. Network interface(s) 2580 may also include a wired network interface for communicating with remote devices via network cable 2587, which may be, for example, an Ethernet cable, a coaxial cable, a fiber optic cable, a serial cable, or a parallel cable.

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

[0135] The computing system 2500 may further include one or more energy sources 2505 and one or more energy measurement systems 2545. The energy source 2505 may include an AC / DC adapter coupled to an external power source, one or more batteries, one or more charge storage devices, a USB charger, or other energy source. The energy measurement system includes at least one voltage or amperage measurement device capable of measuring energy consumed by the computing system 2500 over a predetermined period of time. The computing system 2500 may further include one or more energy measurement systems that measure energy consumed by, for example, a display device, a cooling subsystem, a Wi-Fi subsystem, or other frequently used or high energy consuming subsystems.

[0136] 21 is a flow diagram illustrating a method for use in a device locator system, according to one embodiment. The delegate device 504 can receive the shared resource locator directly from the owner device 502 (or another sharee device) using any number of communication methods, a third-party server 536 (e.g., via a third-party application), and / or the delegate server 534. For example, the owner device 502 or the sharee device can transmit the shared resource locator in an electronic message, a text message, via a QR code, via a third-party application, a file synchronization service, a word processing application, a note-taking application, a file transfer service, cloud-based storage, and / or any other form of communication.

[0137] In flow diagram 2200, the device locator server 520 receives a resource locator sharing request from a delegate device 504 to access a locator service accessible at the device locator server 520 of an accessory device 530 shared by the owner device 502. The owner device 502 can enable sharing, and receiving the resource locator sharing request to access the share using the shared resource locator can initiate delegation. Continuing with flow diagram 2100, the device locator server 520 can receive a resource locator sharing request to access the location service of the accessory device (2202). The delegate device 504 can access the share by sending a request to the device locator server 520 through an application having the shared resource locator, such as selecting to access the shared device locator by submitting a request using a web browser. In one embodiment, the delegate device 504, which is a sub-delegate of the delegate entity, can access the share using the shared resource locator with a third-party application via a third-party server 536.

[0138] The shared resource locator includes a unique identifier that corresponds to an identifier for a share that can be looked up by the unique identifier and accessed via the device locator server 520. The shared resource locator can resolve to a web page and / or web application to access the share. In one embodiment, a single shared resource locator can be used to access the share by both delegate devices 504 for sub-delegates of the delegate entity and / or delegate devices 504 of users not affiliated with the delegate entity (e.g., sharee devices). The shared resource locator can be shared by both users and delegate entities. In one embodiment, the shared resource locator is a unique identifier for the resource (e.g., the address of a web page that can be used to access the share). In one embodiment, the share identifier corresponds to a share key and a delegate key stored in the delegate server 534.

[0139] As shown herein, a user of the owner device 502 can delegate all or a subset of the device locator 520 services to a delegate entity via a delegation UI 503 and a delegate key transfer 505 to a sharing record established on the delegate entity's delegate server 534. The user of the owner device 502 can enable or disable sharing at any time. Delegation can be performed by the owner device 502 by generating keys for one or more privacy windows expected for that duration and providing those keys to the delegate server 534 via a delegate key transfer 505. A privacy window is a predetermined period of time, such as M minutes, during which a set of generated keys associated with the wireless accessory 530 is valid. In one embodiment, there is at least one new key for each privacy window. For example, if a trip is expected to last one hour and the privacy window is 15 minutes, the set of generated keys for a privacy window (e.g., 15 minutes) within that time will include at least four keys. The delegate server 534 can store the delegate key in a shared record in a shared database, and the delegate server 534 can encrypt and decrypt data exchanged with the device locator server 520 upon request by the delegate device 504.

[0140] The shared resource locator may also include an encryption key and / or a delegate shared secret for generating the encryption key. The encryption key may be used by the delegate device 504 to encrypt / decrypt data received in response to a request to the device locator service and / or the owner device 502. In some embodiments, the delegate device 504 associated with a delegate entity (e.g., a sub-delegate) may obtain the delegate shared secret and / or encryption key from a third-party server. The delegate entity, as a trusted entity for the owner device 502, may receive the delegate shared secret and / or encryption key via a third-party application and store the delegate shared secret and / or encryption key in the third-party server 536. The delegate entity may determine whether the delegate shared secret and / or encryption key are shared directly with the delegate entity's sub-delegate devices or used to decrypt location information within the third-party application.

[0141] In one embodiment, the shared resource locator may be implemented as a uniform resource locator (URL), and the delegate device 504 may use the shared resource locator in conjunction with an application, such as a web browser, web application, or third-party application, to access the share of the locator service. Some embodiments may include a shared secret and / or encryption key as part of the shared resource locator string that is accessed only within the application (e.g., a web browser) on the delegate device 504, and the shared secret and / or encryption key is not sent with the request to the device locator server 520 that has the shared resource locator. In this way, location information may not be shared with the device locator service provider. In some embodiments, the encryption key may be accessed within the application on the delegate device 504 only once a request has been sent to the device locator server 520 (directly or via the delegate server 534) and a response has been received from the device locator server 520 and / or the delegate server 534. For example, a portion of the shared resource locator string may be implemented as an anchor link in a uniform resource locator, and the anchor link containing the encryption key may only be accessed in a browser. As a further example, the URL may be:

[0142] “shareurl.com?parameter=1#cryptographickey”,

[0143] where "shareurl.com" is the address / identifier of the resource, "parameter" is a parameter with a value assigned as 1, and the anchor link follows "cryptographickey." In another embodiment, a shortened URL of the shared resource locator may be generated and sent to the delegate device 504.

[0144] The device locator server 520 can receive requests directly from the delegate device 504, from the delegate server device 534, and / or from a third-party server 536. The device locator server 520 can request and receive 2204 authentication credentials from the delegate device 504, and the device locator server 520 can attempt to authenticate the delegate device 504 using the received authentication credentials. The authentication credentials can include a multi-factor authentication type, a passkey, a user identifier and password, an account identifier and password, an out-of-band verification method (e.g., a passcode sent via message, text, and / or email, etc.). In some embodiments, the delegate entity may authenticate the user (e.g., a sub-delegate), and the third-party server may provide credentials indicating that the delegate device 504 has been authenticated.

[0145] If the user of the delegate device 504 is authenticated, it is determined whether a rate limit threshold for the number of sharee(s) or sharee request(s) has been exceeded. The rate limit threshold checks and the defined threshold number of user checks may be implemented using techniques to avoid providing user identifiers for sharing to the device locator provider. In one embodiment, a hash function is applied to the delegate user's and / or delegate device's identifier to obfuscate the identifier but allow for recording of user sharing requests. The delegate user's or delegate device's identifier may be an account identifier, device identifier, and / or phone number, etc., to generate a hash result using the hash function. A comparison is performed between the hash result and existing hash results associated with the shared resource locator stored in a database. A database is an organized collection of data. The hash result of the identifier associated with the delegate device 504 is compared to a set of hash results stored in the database associated with the shared resource locator. If the comparison results in a match with an existing hash result for the shared resource locator stored in the database, the authenticated user has previously accessed the share and there is no need to increase the number of users for the share. FIG. 23 shows a summary of the number of unique users (based on identifiers) for a share in the user interface element 2604. The number of share access requests may optionally be recorded. Alternatively, if the comparison does not yield a match, the hash result is a unique hash result for the share, indicating a new user for the share, and the visitor count value is incremented. The unique hash results for the identifier may be stored in association with the shared locator resource in a database record, and the number of unique hash results for the shared resource locator may be incremented for each unique hash result to indicate a new user visit. If the number of unique hash results received for a resource locator request exceeds or equals a rate limiting threshold and / or a defined threshold number of allowed share requests, the received share request may be rejected. If the number of unique hash results does not exceed a rate limiting threshold and / or a defined threshold number of allowed share requests, the unique hash result is added to the hash result database record associated with the shared resource locator.

[0146] Continuing with the flow diagram, if the number of unique hash results received for the resource locator request does not exceed the rate limit threshold or a defined threshold, metadata is evaluated to determine whether conditions are met for sharing with an authenticated user of the delegate device (2206). The metadata defines a set of conditions for sharing a set of location service capabilities. In one embodiment, metadata on the owner device 502 associated with the delegate entity and / or selected by a user on the owner device 502 to associate with the share can define the set of conditions. The metadata can define a time limit for the share, an access policy for sharees participating in the accessory device 530 share, and / or any other conditions for the share. The access policy for each sharee participating in the accessory device 530 share of location services is established when the sharee accepts the request to join the share. The access policy can define when, where, and to whom the sharee is allowed to notify the individual sharee device location. After meeting a set of conditions, the authenticated user of the associated delegate device 504 can access the locator service 522 as requested. The set of conditions can be established by the device owner and / or the delegate entity. The set of conditions may relate to the state of the owner device 502, the status of the wireless accessory 530, the delegate device 504, and / or the authorized user of the delegate device 504. The set of conditions may be time-based conditions, geography-based conditions, conditions based on the status of the wireless accessory 530, and / or the location of the owner device 502 or the sharee of the owner device (e.g., 504).

[0147] In some embodiments, the metadata may identify the expected delegate role, the duration of the share, the expiration time of the share, the access policy for the location information, and / or any other conditions of the share. For example, the access policy established between the sharee and / or owner participating in the share may indicate a time frame and / or accessory device status information for which access is allowed or denied. Continuing with this example, the access policy may indicate that an accessory device status of "near the owner device" and / or "near the sharee device" is not allowed. In one embodiment, a wireless accessory 530 is defined to be near a particular device if the particular device is wirelessly or physically connected to the wireless accessory 530. In another embodiment, a wireless accessory 530 is defined to be near a particular device (owner device or sharee device) if the particular device is within range to receive a beacon signal from the wireless accessory 530. For example, if the owner device 534 is wirelessly or physically connected to the wireless accessory 530, the owner device 534 is near the wireless accessory. In another example, a delegate of a delegate entity may send information regarding the location of the accessory device and designate the accessory device as near the owner device. For example, a delegate or sub-delegate of a delegate entity can hand over accessory device 530 to the owner, designate the accessory device as the owner device, and designate accessory device 530 as proximate to the owner.

[0148] If the set of conditions defined in the metadata of the share is determined to be met, a response to the location service access request is sent to the delegate device 504 (2208). The shared resource locator includes a unique identifier that can be used to retrieve the shared identifier associated with the shared resource locator. The unique identifier can be used to look up and search the shared identifier to locate the shared key and / or corresponding delegate key at the delegate server. The second shared identifier may ensure that a level of indirection exists and that the identifier in the resource locator is not the second identifier used to retrieve the share. The device locator server 530 fulfills the request with the delegate key from the delegate server for the share and sends encrypted location information to the delegate device 504 directly 524, from the third-party server 536 via a third-party application, and / or from the delegate server 534. The delegate device 504 decrypts the location information using the delegate shared secret in the browser or an encryption key generated in the third-party application.

[0149] Throughout the description, specific examples are provided with reference to a delegate device affiliated with a delegate entity, but those skilled in the art will recognize that the delegate device may also be a recipient device with a recipient not affiliated with the delegate entity.

[0150] FIG. 22 illustrates one embodiment of a delegation user interface on an electronic device 2600 that enables an owner device 502 (or sharee device) and / or a delegate device 504 to share location updates. FIGS. 22 and 23 are variations of the delegation user interface 503 described herein. The shared resource locator 2602 for the share is displayed in a share summary user interface titled "Share Location Update." In some embodiments, the delegation user interface may be implemented as a web application running in a browser. An embodiment may be implemented using an application server, such as a delegate entity (e.g., a third-party server) web application server. Information about the share for the corresponding shared resource locator 2302, such as "http: / / shareurl.com?param=1#key," may be summarized in the user interface along with the number of visitors to the share, such as "Number of Visitors=3," and the expiration date, such as "2 / 14 / 2024" 2604. The user interface element "Share Link" 2606 enables a user to share a link using various communication methods, as shown in the exemplary embodiment of FIG. 23. In one embodiment, a user enables sharing by submitting a shared resource locator 2602. In another embodiment, a user can indicate in a setting whether to enable or disable sharing corresponding to shared resource locator 2602. Alternatively, a user can disable sharing using user interface element "stop sharing" 2608. User interface element 2610 allows a user to exit the web application, as indicated by "Done."

[0151] FIG. 23 illustrates one embodiment of a delegation user interface on an electronic device 2601 that enables an owner device 502 (or a sharee device) and / or a delegate device 504 to share a shared resource locator. As shown in the user interface on the electronic device 2601, a user can send the shared resource locator 2602 using various communication methods 2608, as indicated by icons for a file transfer application, a text messaging application, and email. Those skilled in the art will recognize that a user may use any type of communication method, such as text messaging, email, a file transfer service, a cloud service, a note-taking application (as indicated by 2612), a word processing application, a text editor, saving to a file (as indicated by 2614), and / or synchronization. A user can use the copy and paste functionality of the electronic device 2601 with the shared resource locator 2602, as indicated by user interface element 2610 “Copy Link.” User interface element 2610 also enables a user to exit the web application, as indicated by “Done.”

[0152] 24A and 24B show an example embodiment of a delegation user interface on an electronic device 2702. An authenticated delegate device 504 can access a device locator service using a shared resource locator, as shown in FIGS. 24A and 24B. FIGS. 24A and 24B are variations of the delegation UI 506 described herein. If the conditions for sharing the resource locator service are not met, such as if the accessory device 530 is within beacon signal range of the owner device 502 or another delegate device 504, an error is displayed. As shown in FIG. 24A, the device locator UI 2701 of the delegate device 504 can present a graphical user interface on the electronic device 2702 with an accessory device location 2704 of the accessory device associated with the item 2708 "house key," with the location information presented as indicated by the item "house key" located at 706 in the map. The owner and sharee have an access policy that allows the sharee to have location information for an item associated with the accessory device 530 when the item has a device status of not being located near the owner as shown. The delegate device 530 has device locator functions of "play sound" 2710 and "notification" 2712 (provided in more detail at 2716 in FIG. 24B ). As shown in FIG. 24B , the device locator UI 2701 of the delegate device 504 can present a graphical user interface on the electronic device 2702 with the accessory device location 2704, and the delegate designated as "me" 2718 has device locator functions of "play sound" 2710, "notification" 2712 (e.g., "notify when found," "notify when left behind," "notify when moved"), and "share item" by selecting affordances for "add person." As shown in FIG. 24B, the sharee "I" 2718 is viewing shared information about a "house key" that is also shared with the delegate "Sara Parker."

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

Claims

1. 1. A method for managing delegation of location services, the method comprising: receiving, at the delegate server, from the delegate device, authentication credentials for a sub-delegate of the delegate entity; determining at least one locator service of an accessory device, the at least one locator service being accessible to the delegate device using the received authentication credentials; receiving a request for the at least one locator service from the delegate device; evaluating a set of inputs to determine whether a set of conditions corresponding to the at least one locator service and the delegate device are satisfied; upon determining that the set of conditions is satisfied, sending the request for the at least one locator service to a device locator server; and decrypting a response to the request received from the device locator server using one or more encryption keys stored for the delegate entity.

2. The method comprises: The method of claim 1 , further comprising: using the received authentication credentials to send to the delegate device a set of locator services authorized by the sub-delegate role.

3. The method of claim 1 , wherein at least one condition from the set of conditions is that the sub-delegate is associated with the delegate entity.

4. The method of claim 1 , wherein at least one condition from the set of conditions is that the accessory device status is not at least one of a close-to-owner status or a close-to-sharee status.

5. The method of claim 4 , wherein the near-to-owner status includes the owner device being within beacon signal range of the accessory device.

6. and transmitting the response to the request to the delegate device, the response comprising: The method of claim 1 , wherein the access control information is encrypted using an encryption key generated using a shared secret between the delegate device and a device paired with the accessory device.

7. 1. A method for delegating location services for an accessory device, the method comprising: In an electronic device, one or more privacy periods for the accessory device, determining a set of delegate keys for one or more privacy periods, the one or more privacy periods corresponding to defined periods for sharing one or more locator services with a delegate entity; sending a request to a delegate server to add said set of delegate keys to said share; sending metadata associated with a delegate entity to the delegate server, the metadata indicating an event with the delegate entity; receiving location information of the accessory device; and displaying the location information along with the metadata associated with the delegate entity.

8. sending to the delegate server a set of conditions under which the delegate entity may access the set of locator services of the accessory device; The method of claim 7 further comprising:

9. sending to the delegate server a set of locator services accessible by sub-delegates of the delegate entity; The method of claim 7 further comprising:

10. The method of claim 7 , wherein the metadata includes a set of locator services for the accessory device and information about the defined time period for the sharing of one or more locator services.

11. The method of claim 7 , wherein the set of conditions is provided by the delegate entity.

12. transmitting at least one shared secret to a delegate device for generating a cryptographic key; The method of claim 7 further comprising:

13. sending the set of delegate keys and the metadata to the delegate device; The method of claim 7 further comprising:

14. The method of claim 7 , wherein the delegate device and the electronic device communicate via near field communication, Bluetooth Low Energy, or other wireless protocol.

15. The method of claim 7 , wherein the electronic device is associated with an online account of an owner device paired with the accessory device.

16. 16. The method of claim 15, wherein the electronic device is selected from a set of electronic devices associated with a trusted online account, the trusted online account receiving a shared secret from an owner device to generate a delegate key, and the owner device being paired with the accessory device.

17. 1. A method of a delegate device for accessing location services of an accessory device, the method comprising: sending authentication credentials for a sub-delegate of the delegate entity and information regarding at least one condition for accessing location services of the accessory device to the delegate server; receiving information regarding a set of accessible location services for the authentication credentials that satisfy the at least one condition; sending a request for a locator service of the accessory device to a delegate server; receiving an encrypted response to the request.

18. receiving, from an electronic device, a set of a delegate key and metadata, the metadata indicating an event with the delegate entity; 20. The method of claim 17, further comprising:

19. receiving a delegate shared secret from the electronic device; decrypting the encrypted response using a decryption key generated in part using the delegate shared secret; 20. The method of claim 17, further comprising:

20. The method of claim 17 , wherein the at least one condition for accessing a location service is determined based on the sub-delegate role in the delegate entity.

21. Satisfying at least one of the conditions means: transmitting location information of the delegate device to the delegate server; and receiving an indication that the delegate device having the authenticated credentials for the sub-delegate role is located at at least one delegate entity location authorized for the request.

22. Detecting a beacon signal from the accessory device; transmitting location information about the accessory device to at least one of an owner device or a location server; 20. The method of claim 17, further comprising:

23. 23. The method of claim 22, wherein the location information is encrypted using an encryption key generated using a shared secret between at least the delegate device and a device paired with the accessory device.

24. 1. A method for accessing location services of a delegated accessory device, the method comprising: receiving, at a delegate device, a shared resource locator for accessing a location service of an accessory device, the shared resource locator including a portion of the shared resource locator accessible within an application on the delegate device, the portion of the shared resource locator including a cryptographic key; sending, via the application, a request to a device locator server to access the location service using the shared resource locator; and decrypting a response to the request from the device locator server using the encryption key in the application.

25. 25. The method of claim 24, wherein the shared resource locator is a uniform resource locator, and the portion of the uniform resource locator includes an anchor link.

26. 25. The method of claim 24, wherein the application is a third-party application and the portion of the shared resource locator is stored on a third-party server.

27. 1. A method for accessing location services of a delegated accessory device, the method comprising: receiving a resource locator sharing request for accessing a location service of the accessory device; receiving authentication credentials from a delegate device; evaluating the metadata to determine whether conditions are met for sharing with an authenticated user of the delegate device; and transmitting a response regarding the location services to the delegate device in response to determining that a set of conditions is met regarding sharing.

28. 28. The method of claim 27, wherein the metadata includes an access policy and a rate limiting policy for the delegate entity.

29. applying a hash function to the identifier to generate a hash result of the identifier; comparing the hash result to a set of hash results associated with the shared resource locator to determine whether a rate limit threshold for the share has been exceeded; 28. The method of claim 27, further comprising:

30. Evaluating the metadata to determine if the condition is met includes:

28. The method of claim 27, comprising determining whether the owner device is within beacon signal range of the accessory device.

31. Evaluating the metadata to determine if the condition is met includes:

28. The method of claim 27, comprising determining whether the delegate device associated with a delegate entity has designated the accessory device as being proximate to an owner device.

32. receiving, at a third-party server, a resource locator sharing request via a third-party application to access location services of the accessory device; 28. The method of claim 27, further comprising:

Images