Server-mediated management of accessory device sharing

Abstract

A method, non-temporary machine-readable medium, and system comprising a delegate server receiving authentication credentials from a first shared electronic device, determining at least one cryptographic key and metadata accessible to the first shared device corresponding to the received authentication credentials, wherein the metadata defines a set of conditions for sharing location information of an accessory device, evaluates the metadata to determine if the set of conditions is met, and if it is determined that the set of conditions is met, transmits the metadata and at least one cryptographic key to the first shared electronic device, receives an indication that a second shared electronic device is participating in sharing location information of an accessory device, and transmits an update of at least one cryptographic key and metadata.

Description

Technical Field

[0001] This application claims the benefit of priority of U.S. Non-Provisional Application No. 18 / 646,601, filed Apr. 25, 2024, entitled “Server-Mediated Management of Accessory Device Sharing”; U.S. Provisional Application No. 63 / 501,083, filed May 9, 2024, entitled “Server-Mediated Management of Accessory Device Sharing”; and U.S. Provisional Application No. 63 / 552,619, filed Feb. 12, 2023, entitled “Server-Mediated Management of Accessory Device Sharing”, each of which is incorporated herein by reference.

[0002] The embodiments described herein relate to location services for accessory devices.

[0003] Background Information Previous solutions for device locator services for shared accessory devices transferred an encryption key between an owner device and a shared-with device, thereby enabling the shared-with device to use the encryption key to access the location information of the accessory device as if the shared-with party were the owner. Directly providing the owner encryption key to the shared-with party makes it difficult to restrict access to the location information. Thus, a solution for sharing accessory device location information that restricts access to the locator service by the shared-with party is desirable.

Summary of the Invention

[0004] Embodiments described herein provide a system, a non-temporary machine-readable medium, and a method for providing location services. One embodiment provides a delegate server that receives authentication credentials from a first shared electronic device, determines at least one cryptographic key and metadata accessible to the first shared device corresponding to the received authentication credentials, wherein the metadata defines a set of conditions for sharing location information of an accessory device, evaluates the metadata to determine whether the set of conditions is met, transmits the metadata and at least one cryptographic key to the first shared electronic device if it is determined that the set of conditions is met, receives an indication that a second shared electronic device is participating in sharing location information of an accessory device, and transmits an update of at least one cryptographic key and metadata.

[0005] The embodiment provides metadata including an access policy for the first shareholder to access the location information of the accessory device. The embodiment further provides an access policy including the first shareholder's conditions regarding access to retrieve location information provided to the device location service by the second shareholder, which were established when the first and second shareholders agreed to share. The embodiment further provides metadata including the first shareholder's account identifier and the duration of the sharing.

[0006] One embodiment provides a device location server that receives a location service request from a shared electronic device to an accessory device, decrypts an encrypted blob using at least one encryption key included in the location service request, wherein the encrypted blob was received from the owner device for the requested sharing of the accessory device's location information, decrypts the blob, retrieves encrypted location information for the accessory device from a location information database using at least one hashed public key obtained from the decrypted encrypted blob, and transmits the retrieved encrypted location information and the encrypted encryption key for the encrypted location information to the shared electronic device in response to the location service request. Another embodiment provides verifying an access policy for a shared user corresponding to metadata included in a location service request, wherein the access policy defines a set of conditions for sharing the accessory device's location information, verifies the access policy, evaluates the metadata to determine whether the set of conditions is met for the shared user, and, upon determining that the set of conditions is met, decrypts the blob encrypted using at least one encryption key included in the location service request.

[0007] The embodiment further provides decrypting an encrypted blob with at least one cryptographic key included in the location service request and transmitting an cryptographic key for at least one device location service capability for the accessory device. The embodiment provides that at least one hashed public key corresponds to a public key generated by a shared secret on both the owner device and the wireless accessory. The embodiment further provides location information including location information provided to the device location server by a second shared device that has detected a beacon from the wireless accessory.

[0008] One embodiment provides receiving acceptance of a request to share access to location information of a paired accessory device; generating a set of hashed public keys corresponding to a set of public keys that are expected to be used by a device location service server to encrypt the received location information of the accessory device during the sharing duration; encrypting the set of hashed public keys and sending it to the device location service server; and sending an encryption key to a delegate server for decrypting the set of hashed public keys and metadata, wherein the metadata includes an identifier of a first shareee and a set of conditions for sharing. The embodiment further provides establishing a shared secret with the paired accessory device; and generating public keys in the set of public keys based on the shared secret and timestamps expected during the sharing duration. The embodiment further provides that the metadata includes an access policy for accessing the location information. The embodiment further provides transmitting an encrypted blob to a device location service server, the encrypted blob containing an encrypted encryption key that allows a first shared user to access the accessory device's location service, and transmitting a decryption key for the encrypted blob to a delegate server. The embodiment further provides receiving an acknowledgment from a first shared user device for a request to include a second shared user in the accessory device's sharing, and transmitting updated encryption keys and metadata for each shared user in the sharing.One embodiment provides an accessory device that, in accordance with an access policy, sends an acknowledgment to a request to share access to the accessory device's location information, which is paired with an owner device; receives metadata, which includes the access policy, and at least one encryption key from a delegate server; sends a request to a device location server to perform a lookup of the accessory device's location information by at least one encryption key, the request including metadata; and receives encrypted location information of the accessory device and an encrypted encryption key for the encrypted location information, in accordance with the access policy. The embodiment further provides that the access policy includes conditions relating to access to retrieve location information provided to the device location service by a second shareee, which is established when the second shareee accepts the sharing. [Brief explanation of the drawing]

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

[0010] [Figure 2] This document describes a system for locating wireless accessory devices according to one embodiment.

[0011] [Figure 3] This document describes a system for pairing and locating wireless accessories according to one embodiment.

[0012] [Figure 4] This is a flowchart illustrating a method for use in a device locator system according to one embodiment.

[0013] [Figure 5A]A network operating environment for an electronic device according to one embodiment.

[0014] [Figure 5B] A network operating environment for an electronic device according to one embodiment.

[0015] [Figure 5C] A network operating environment for an electronic device according to one embodiment.

[0016] [Figure 5D] A network operating environment for an electronic device according to one embodiment.

[0017] [Figure 6A] A flowchart showing a method for use in a device locator system according to one embodiment.

[0018] [Figure 6B] A flowchart showing a method for use in a device locator system according to one embodiment.

[0019] [Figure 7A] A user interface for a device locator service according to some embodiments. [Figure 7B] A user interface for a device locator service according to some embodiments. [Figure 8A] A user interface for a device locator service according to some embodiments. [Figure 8B] A user interface for a device locator service according to some embodiments. [Figure 8C] A user interface for a device locator service according to some embodiments. [Figure 8D] A user interface for a device locator service according to some embodiments. [Figure 9A] A user interface for a device locator service according to some embodiments. [Figure 9B] A user interface for a device locator service according to some embodiments. [Figure 9C] A user interface for a device locator service according to some embodiments. [Figure 9D] A user interface for a device locator service according to some embodiments.

[0020] [Figure 10] A flowchart showing a method for use in a device locator system according to one embodiment.

[0021] [Figure 11A] An operating environment for an electronic device according to one embodiment.

[0022] [Figure 11B] A user interface for a device locator service according to some embodiments. [Figure 12] A user interface for a device locator service according to some embodiments.

[0023] [Figure 13] A block diagram showing an exemplary API architecture that may be used in some embodiments.

[0024] [Figure 14] A block diagram of a device architecture for a mobile device or an embedded device according to one embodiment.

[0025] [Figure 15] A block diagram of a computing system according to one embodiment.

[0026] [Figure 16] This is a flowchart illustrating a method for use in a device locator system according to one embodiment.

[0027] [Figure 17] Several embodiments of a delegated user interface are shown. [Figure 18] Several embodiments of a delegated user interface are shown.

[0028] [Figure 19A] Several embodiments of a delegated user interface are shown. [Figure 19B] Several embodiments of a delegated user interface are shown. [Modes for carrying out the invention]

[0029] Embodiments described herein generally provide a technology for a device owner to delegate one or more location services of an accessory device to a shared user. The device owner may have a mobile device paired with an accessory device such as a locator tag, and the device owner may have a set of location services provided on request via a device location server and / or the accessory device that can be delegated to a shared user. The location services are a set of functions for tracking and locating the accessory device. For example, the set of capabilities may include, but are not limited to, a location-finding service for the accessory device accessible via a user interface, a request for notification of accessory device location information, a request for audio playback on the accessory device, a request for a shared location service for the accessory device with another shared user, the ability to request muting unwanted tracking notifications, and / or other capabilities related to the accessory device.

[0030] A combination of servers may be used to provide server-mediated management for sharing location services for accessory devices. For example, a combination of servers may include a first delegate server that distributes delegate cryptographic keys (e.g., encryption / decryption keys) and a second location service server that handles service location requests from shared devices in a manner that provides restrictions on the shared device's access to the location services, such as by time limits on the accessory device's access to the location services. The cryptographic key is a string of data used to lock or unlock cryptographic functions, including authentication, authorization to perform location service capabilities, and encryption / decryption of data. In some embodiments, the cryptographic key may be part of a public / private key pair. Those skilled in the art will recognize that any type of cryptographic key, including symmetric and asymmetric cryptographic keys, may be used.

[0031] The first type of delegate key provided to the shared user is a decryption key that enables the shared user to decrypt encrypted blobs (e.g., encrypted capability key blobs, encrypted location blobs, etc.) received by the shared user device from the location service server. For example, a device locator server may send a blob encrypted with an encrypted device locator capability key, and the shared user device may decrypt the encrypted blob to access the capability key. The capability key may be sent in a request from the shared user to the device location server that permits the shared user to access the device locator service corresponding to the capability key. In another example, a device locator server may send a blob encrypted with encrypted location information and the corresponding decryption key(s) for the encrypted location information. Continuing this example, the received encrypted blob may be decrypted by the shared user device with the first type of delegate key to obtain the decryption keys for both the encrypted location information and the encrypted location information, and the shared user device may decrypt the location information with the obtained decryption keys.

[0032] A second type of delegate key is an encryption key (e.g., a decryption key) that can be sent by the shared device on behalf of the shared device in a request for on-demand decryption of an encrypted blob at the device location server. The second type of delegate key enables the shared device to access the accessory device's location service using an encryption key generated and / or accessible by the owner device. By providing the encrypted encryption key (e.g., an encrypted hash of a public key) and the delegate decryption key to the device location server by the owner device, the owner device can grant the shared device access to the location information while maintaining control over access to the encryption key generated based on a shared secret between the accessory device and the owner device. In one embodiment, the encrypted blob stored in the device location server includes a public key or a hash of a public key generated by the owner device and stored in the device location server for accessing the location information of a wireless accessory device. For example, the public key underlying the hashed public key stored in the encrypted blob may be a set of rolling public keys generated by both the owner device and the accessory device based on a shared secret. Continuing with this example, the shared device may request location information and provide a decryption key for an encrypted public hash, thereby allowing a device location server to look up the location information on behalf of the shared device using the public key hash provided by the owner device. The set of encrypted public key hashes may become accessible when the owner device is offline, and the owner may limit the accessory device's access to future location information by not directly providing the shared device with the public key based on the shared secret.

[0033] The location service server may ensure that a shared device meets a set of conditions for accessing each device locator service, and will serve device locator requests from shared devices based on the conditions defined by the accessory device owner in the metadata provided by the delegate server. The metadata provided to the shared device by the delegate server may define a set of sharing conditions, including, but not limited to, a shared device identifier, the duration of sharing (e.g., a defined period), and other shared devices that have been granted access to their individual location information in the presence of the accessory device. In another example, a combination of servers may facilitate the management of access to the location information of accessory devices to restrict the sharing of location information when the accessory device is near the owner device or another shared device.

[0034] In some embodiments, the device owner may select an external entity to act as the shared / delegate entity for a defined period for sharing, and the device owner may grant the entity access to a subset of the device locator services for the accessory device so that the delegate entity can track and locate the accessory device. The delegate device, or sub-delegate device, or shared device may be used interchangeably throughout the specification. Those skilled in the art will recognize that the delegate and sub-delegate devices are variations of the shared device. The 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 a service that is entrusted with items associated with the accessory device, or a service that is otherwise obligated to provide services to the device owner regarding the accessory device itself and / or items associated with the accessory device. Alternatively, the items may be accessory devices such as Apple AirPods that may be left at a location owned by the external entity.

[0035] In some embodiments, metadata on the owner device associated with an event with a delegate entity can be used to automatically establish a defined period during which an external entity acts as a delegate entity and / or to automatically select a subset of device locator services that the delegate entity can access. For example, metadata on the device owner of an event by an external entity selected as a delegate entity, such as calendar data for an event, can be used to determine the defined period and set of locator services that the entity can access. A delegate entity may have sub-delegates (e.g., a set of employees / agents with employee / agent roles) that use delegate / shared devices permitted to use a subset of locator services delegated to the delegate entity. Employees of the delegate entity may authenticate with the delegate server using delegate / shared devices.

[0036] Figure 1 is a block diagram of a network operating environment 100 for electronic devices according to one embodiment. The network operating environment 100 includes a plurality of electronic devices, such as accessory devices 101, a delegate server 107, and a mobile device 102. Accessory devices 101 can be paired with the mobile device 102. In one embodiment, the accessory device itself may be a tracking device such as an Apple AirTag®. 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 lost smartphone or Apple AirPods®. The set of accessory devices may be paired with the mobile device 102, and the set of accessory devices may form a device group. Optionally, a device group having accessory devices 101 may be a case having a wired connection to an accessory device 101 stored internally. In some embodiments, the case itself may be an accessory device 101 that can be paired with the mobile device 102. For example, accessory device 101 may be a set of devices such as Apple AirPods® or EarPods®.

[0037] In some embodiments, the accessory device 101 may not be able to communicate over a wide area network. In other embodiments, devices 101 and 102 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., smartwatches or other wearable computing accessories), mobile media players, personal digital assistants, AirPods®, EarPods®, AirTag®, locator tags, headphones, head-mounted displays, health equipment, speakers, and other similar devices.

[0038] The delegate server 107 may be implemented as a set of one or more servers that serve requests from a mobile device to 102 via a wired or wireless network (as shown by 109 and 111). The device owner may use the mobile device 102 to select an identifier for the shared device and create a shared record for the shared device stored in a shared database associated with the delegate server 107. The mobile device 102 generates a set of delegate keys that are expected to be used for a defined duration for sharing. In one embodiment, the delegate server 107 is a key escrow that holds the decryption keys necessary to decrypt data transmitted between the device owner and the shared device via the device locator server. In another embodiment, the delegate server 107 holds the decryption keys that enable the shared device to request a location service that requires decryption of encrypted blobs in the device locator server (as shown in the device locator service 170). The electronic device 102 and the shared device may use an application programming interface to access the locator service 170.

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

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

[0041] Electronic devices 101 and 102 can communicate with one or more services via one or more wired and / or wireless networks 110, such as telephone service 130, messaging service 140, media service 150, storage service 160, device locator service 170, certification authority 106, delegate server 107, and home service 194. For example, telephone service 130 can enable telephone communication between mobile devices or between mobile devices and wired telephone devices. Telephone service 130 can route Voice over IP (VoIP) calls via a wide area network 114 or access a cellular voice network (e.g., wireless network 112). Messaging service 140 can provide, for example, email and / or other messaging services. Media service 150 can provide access to media files such as song files, audiobooks, movie files, video clips, and other media data. Storage service 160 can provide network storage capabilities to mobile devices 101 and 102 to store documents and media files. The device locator service 170 can enable users to locate lost or misplaced devices. The home service 194 can enable users to manage smart home devices together with the user of the 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, the messaging service 140, media service 150, storage service 160, home service 194, and device locator service 170 can each be associated with a cloud service provider, and the various services are facilitated through cloud service accounts associated with electronic devices 101 and 102.

[0042] In some embodiments, accessory device 101 and / or device group 101 and mobile device 102 may be registered with a Certificate Authority 106. In some embodiments, the 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. Certificates provided by the Certificate Authority 106 may certify the validity of received verifiable information about a device, such as the specific manufacturer of the device, a serial number, a 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 the serial numbers of accessory devices within the device group. In further embodiments, certificates may be encrypted by devices 101 and / or 102 before being sent to a third party, and can be decrypted in a certification service (e.g., a Certificate Authority or another certification service) when the third party requests verification of the information provided by accessory device 101, mobile device 102, smart home devices, and / or devices within the device group. In some embodiments, a 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.

[0043] Electronic devices 101 and 102 may have locally accessible applications, services, and functions on the device. In particular, mobile devices 101 and / or 102 may have a device locator application (e.g., a “Find Me” application) 190 for utilizing a device locator service 170 and a 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 can 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. For example, cluster data analysis can be used to identify, classify, and provide semantic labels for locations or defined spaces, such as locations frequently visited by the user. Secure or trusted locations 184 may be explicitly specified or confirmed as such by the user of mobile device 102 after data analysis. Furthermore, user routines may be explicitly defined by the user of mobile device 102. In other examples, known locations 182, trusted locations 184, and user routines may be classified offline and provided by a 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.).

[0044] Using on-device heuristics and / or machine learning models, relationships between a user and locations (e.g., including defined spaces) can be inferred based on the analysis of locally stored data about frequently visited locations, including locations the user frequently visits, known locations, routines, and / or any other locations. For example, frequently visited locations include home, vehicles, workplaces, any locations frequently visited by a user with mobile devices (e.g., accessory device 101 and mobile device 102), and / or any other locations designated by the user as trusted locations 184. Known locations 182 can be business locations, public spaces, parks, museums, front yards, back yards, and / or any other locations the user may frequently visit. Boundary information for each stored location may be stored along with a classification type for the location and any semantic labels assigned to the location. Stored information may include a defined set of boundaries or radial distances around point locations to enable the creation of geofences for locations. Geofences are virtual boundaries of real-world geographical areas. Using the Global Positioning System (GPS), a virtual fence can be created around a location, and the physical locations of electronic devices 101 and 102 within the geofence boundary, as well as the entrances and exits of the bounded area, can be tracked.

[0045] The machine learning algorithm 186 may include on-device heuristics, machine learning algorithms, or a combination thereof for analyzing and assigning labels to the movement or journey of a device, which is designated as “in transit,” “moving,” or “stable” within a defined space over a defined period of time. The analysis can be performed using a variety of 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 on movement patterns / routines, and / or any other data accessible to the mobile device 102. In some embodiments, the mobile device 102 may be classified with the “stable” semantic label after remaining within a geographic boundary defining a location (e.g., trusted location 184) over a defined period of time. Positioning data for the mobile device 102 may remain within the geofence boundary for a particular location for a certain duration (e.g., 5 minutes). Sensor data, such as accelerometer data, may indicate that the mobile device 102 is stationary, supporting the inference that it is stable.

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

[0047] Figure 2 shows a system 200 for locating a wireless accessory device 201 according to one embodiment. In one embodiment, the wireless accessory device(s) 201 is a locator tag associated with an item such as luggage, and the accessory device 201 is paired with a mobile device 102. Each accessory device 201 includes one or more wireless transceivers and can communicate directly or indirectly (e.g., through another device or computer) with a companion device (e.g., mobile device 102) via a wireless network or 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 by each providing a beacon signal. Some examples of wireless accessory devices 201 include, but are not limited to, wireless earphones, EarPods, Apple AirPods, input devices, charging devices, accessory cases, headphones, headsets, fitness equipment, health equipment, display devices, external hard drives, other wearable devices (e.g., smartwatches, fitness bands, optical head-mounted displays), adapters, speakers, device locator tags, and / or any other mobile devices. 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.).

[0048] The wireless accessory device 201 may also include other wireless devices such as input devices including, but not limited to, credit card readers, stylus devices, mice, keyboards, game controllers, and / or remote controls. In one embodiment, the wireless accessory 201 may also include smartphones, tablet computers, laptop computers, smart speaker devices, televisions, or television set-top boxes that are unable to access a wide area network such as the Internet (e.g., wide area network 114 in Figure 1) at least temporarily. The wireless accessory 201 may also include any other wireless devices, including beacons or locator tags that can be attached to other devices to enable tracking or location identification of those devices. In one embodiment, the wireless accessory 201 may be from a group of accessory devices 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 the shared / delegate device via wireless technology including any implementation of wireless standards and protocols such as Wi-Fi Direct, Zigbee, or AirPlay. The companion device to which the wireless accessory 201 is paired is generally referred to as the mobile device 102, but the companion device is not limited to a mobile device. In some embodiments, the companion device may also include a laptop or desktop device, and in addition, it may include, but is not limited to, several wearable accessories such as a smartwatch device or a wearable display.

[0049] 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, it may use ultra-wideband (UWB) wireless technology for beacon transmission. The beacon signal may be transmitted using a single wireless technology, one of several selectable wireless technologies, or several simultaneous wireless technologies. The beacon signal may transmit a beacon identifier that includes information for specifically identifying individual wireless accessories 201 and / or device groups. In one embodiment, the beacon identifier is a public encryption key associated with the device.

[0050] The beacon signal may also transmit information about the wireless accessory 201, including device status information and / or verifiable information. The device status information in the beacon signal may include, but is not limited to, the beacon type, device classification, battery level, any default device status, device state, lost status, alarm status, separated from owner status, close to owner status, proximity to one or more accessory devices in a device group status, wired or wireless connection status, physically connected to one or more accessory devices in a device group status, pairing status indicating whether the accessory device is paired or not, pairing pending status, battery life status, charging status, close to smart home device status, close to shared device status, close to external entity established status, and / or any other status information. The close to owner status may indicate that the wireless accessory 201 has detected the presence of a mobile device 102 associated with the accessory's owner. The lost status or “separated from owner” status may indicate that the wireless accessory 201 has determined itself to be lost or has been placed in a lost state by the device's owner. An alarm status may indicate that the wireless accessory 201 has been put into a status where an alarm should be triggered if the device moves from its current location. A status close to a smart home device may indicate that the wireless accessory device 201 is communicating with the smart home device of the owner device and / or finder device. A status close to a shared device may indicate that the wireless accessory device 201 is communicating with the recipient of a key sharing from the owner of the wireless accessory device 201. A status close to an external entity may indicate that the wireless accessory device 201 is located near the establishment of an external entity, such as a check-in desk or luggage storage facility.

[0051] In some embodiments, verifiable information may include any information that may be required to establish trust or authority that the pairing process, setup process, device discovery process, and / or finding process can proceed with the device presenting the verifiable information. For example, verifiable information may include information established by the 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 device status or state information. Verifiable information may include, but is not limited to, device type, members of a device group, serial numbers, serial numbers of other devices in the device group, state or status information, software version, and / or any other verifiable information. Verifiable information may be transmitted to a certification authority 106 or other certification service to verify received information presented by one device to another device. Verifiable information may be transmitted encrypted and / or with a token to enable further verification of the device.

[0052] In some embodiments, the beacon signal can be detected by a finder device 202 that is locally close to the lost wireless accessory 201 in order to use crowdsourcing to locate the lost wireless accessory 201. In further embodiments, the shared device may provide additional functionality as the finder device 202. The finder device 202 may be a device similar to the mobile device 102, sending and receiving data over a wide area network 114 and using wireless technology similar to that of the wireless accessory 201 (e.g., Bluetooth). In particular, the finder device 202 may receive data using the wireless protocol on which the beacon signal is transmitted. The finder device 202 may determine the location using one or more location and / or positioning services, including, but not limited to, satellite positioning services 206 or ground positioning systems that use RF signals received from a radio base station 205 such as a Wi-Fi access point or a cell tower transmitter of a cellular telephone network. In one embodiment, the finder device 202 periodically stores its location as determined based on one or more location and / or positioning services. A stored location can be associated with the 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 can transmit its location to the device locator server 203 via the wide area network 114. The timestamp of the determined location of the finder device 202 can be correlated with the timestamp at which the beacon signal was received in order to associate the geographical location with the received beacon signal.

[0053] 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 via 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 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 and such data is available.

[0054] In some embodiments, a beacon signal from the wireless accessory 201 may be detected by a shared device, which is a variation of the finder device 202. In some embodiments, the mobile device 102 may be permitted to transmit a data packet with a request containing one or more public keys for identifying an advertisement from the wireless accessory device 201. If the shared device detects a beacon signal from the wireless accessory device 201, the shared device may communicate to the mobile device 102 that the beacon signal has been received via the device location server 203. For example, if the beacon signal from the wireless accessory device 201 contains an advertisement with a key from one or more public keys transmitted by the mobile device 102, the shared device may respond by transmitting location information of the wireless accessory device 201 (e.g., ranging data, signal strength information, etc.) to the mobile device 102 and / or the device locator server 203.

[0055] In one embodiment, location information of the wireless accessory device 201 received from the shared device may be transmitted to the mobile device 102 and / or the device locator server 203, either encrypted or unencrypted. The received signal strength indicator (RSSI) of the beacon signal may be transmitted to the mobile device 102 along with the location data of the wireless accessory device 201. The RSSI data can then be used to determine the distance of the wireless accessory 201 from the shared device and assist in triangulation on the mobile device 102. The location information provided to the mobile device 102 may include information about the location of the wireless accessory 201 in 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 if other stronger signals from other devices are present.

[0056] 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. In the case of a standard beacon signal, the finder device 202 can queue encrypted location data and send the location data to the device locator server 203 during a periodic transmission window. However, if the wireless accessory 201 indicates an alarm state, the finder device 202 can immediately send the location data to the device locator server 203. If a 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. In addition, if the beacon signal from the wireless accessory 201 indicates that the accessory is near its owner, the finder device 202 does not need to send the location data to the device locator server 203. Alternatively, the finder device 202 may delay the transmission of encrypted location data.

[0057] If the owner of a wireless accessory 201 wants to locate the wireless accessory device 201, the owner can access a device locator user interface (UI) 204 on a 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 corresponding to the public encryption key. The location data returned to the mobile device 102 may 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 is then 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 can be determined by triangulation from multiple received locations, as well as by using the beacon signal RSSI associated with each location and other data such as timestamps or UWB ranging data contained within the location data.

[0058] Figure 3 shows a system 300 for pairing and locating wireless accessory devices according to embodiments described herein. In one embodiment, the user's mobile device 102 (e.g., example device 101) of the wireless accessory 201 may 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) may be performed between the mobile device and the wireless accessory 201. In one embodiment, during the public key exchange (310), the mobile device 102 and the accessory 201 exchange the 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 key / private key pair to the wireless accessory 201. Alternatively or additionally, the public key exchange (310) may be a Diffie-Hellman key exchange in which the device and 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) can be used to enable the establishment of a public key pair and one or more shared secrets. In one embodiment, one or more shared secrets include a tracking-prevention secret that can be used by the wireless accessory 201 to periodically derive additional public keys.

[0059] After the wireless accessory 201 is paired with the mobile device 102, the wireless accessory 201 can periodically broadcast a beacon signal 301 containing 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). Furthermore, 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 the 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 may vary between embodiments. In one embodiment, a 28-byte K value is used. In another embodiment, a 27-byte K value is used. The value K can be determined at least in part based on the beacon length associated with the radio protocol used to transmit the beacon signal 301. In one embodiment, the beacon signal can transmit a variation of a beacon advertisement packet associated with a low-energy radio protocol such as Bluetooth Low Energy.

[0060] In one embodiment, the value M is 15 minutes, and a new K-byte key is generated every 15 minutes. In one embodiment, the default time value M is a privacy window of time in which a new key is generated, as described herein. The public key can be deterministically derived based on a timestamp and a tracking-prevention secret generated during the public key exchange 310. The public key derivation (315) process allows the wireless accessory 201 to use different keys over time and prevents long-term association of a particular key with a particular device. The key can be derived based on a tracking-prevention secret known only to the mobile device 102 and the wireless accessory 201, allowing only the mobile device 102 and the mobile device to determine which public key is broadcast by the wireless accessory 201 at any given timestamp. The tracking-prevention secret is generated along with the ECDH public key and can be transferred to the wireless accessory 201. The tracking-prevention secret can then be used to allow the wireless accessory 201 to generate a sequence Pi of the public key. In one embodiment, the public key sequence Pi = λi·P defines a group operation between a scalar or exponential value λi and a group element, such as an elliptic curve point P, where λ = KDF(AT,i), where KDF is the key derivation function, AT is a tracking-prevention secret, and i is a counter or timestamp.

[0061] In one embodiment, a back-tracking resistor can be enabled to protect the tracking-prevention secret in the event that the wireless accessory 201 is compromised. When the back-tracking resistor is enabled, the tracking-prevention secret is transferred to the wireless accessory 201 but not held by the wireless accessory. Instead, the accessory calculates a value λi+1=H(λi||time) where λ0=AT and H is a cryptographic hash function. The wireless accessory 201 then stores λi for a given time period i. If the wireless accessory 201 is compromised, only the current and future values ​​of λi for i are revealed, and the tracking-prevention secret AT is not revealed. In one embodiment, the back-tracking resistor is implemented by periodically writing λi to the non-volatile memory of the wireless accessory 201.

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

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

[0064] The wireless accessory 201 can enter an alarm state when it receives a message from the mobile device 102 indicating that the wireless accessory 201 should enter an alarm state. When in an alarm state, the wireless accessory can first enter an activatable state in which it can reduce or stop transmitting locator beacon signals, but other types of wireless signaling can continue. The wireless accessory 201 may remain in the activatable state until the state is deactivated by the mobile device 102 or an alarm is triggered. In one embodiment, the alarm may be triggered when movement is detected, for example, via an accelerometer in the wireless accessory 201. In one embodiment, the alarm may also be triggered when it is detected that the wireless accessory 201 has moved out of range of the mobile device 102 and is no longer close to 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.

[0065] The beacon signal 301 transmitted by the radio accessory 201 can be detected by a set of finder devices 303 (the finder devices may be finder devices 202) and / or mobile devices 102, which are other electronic devices that can receive the beacon signal transmitted by the radio accessory and transmit the location and other data associated with the beacon signal 301 to the device locator server 203 via the wide area network 114. In one embodiment, the set of finder devices 303 may include a variant of the mobile device 102 or be other types of electronic devices. For example, the set of finder devices 303 may perform an operation (320) that correlates the beacon signal 301 received from the radio accessory 201 with a device location associated with the finder devices 303. As described with respect to Figure 2, the device location may be determined via a satellite positioning service or a ground positioning system using RF signals received from a radio base station (e.g., a Wi-Fi access point or cell tower transmitter). In one embodiment, the set of finder devices 303 may also include a fixed device such as a smart speaker device, a television, or a television set-top box that can receive a beacon signal 301.

[0066] A set of finder devices 303 can encrypt location data using a beacon identifier (e.g., a 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 along with the data transmitted by the finder devices.

[0067] The device locator server 203 can store encrypted location data in a data store 304, and in one embodiment, the data store 304 can be a distributed database having multiple nodes. The 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 complete beacon identifier prevents the server from storing the complete beacon identifier. Other information can also be transmitted and stored along with the location data, either encrypted or unencrypted. Other information may include a timestamp when the beacon signal 301 was received, RSSI information of the received beacon, and / or distance information determined, for example, via UWB ranging.

[0068] If a user or owner of a wireless accessory 201 wishes to locate the accessory, the user or owner can access a device locator UI 204 on a mobile device 102. The device locator UI 204 may be associated with a locator application 190 or a function 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, it can send a request for location data (330) to the device locator server 203. The request 330 may include a set of public keys or public key hashes that can act as beacon identifiers for beacon data. The mobile device 102 can generate a set of public keys based on secret information held by the mobile device 102 and the wireless accessory 201, and a timestamp on which the mobile device 102 wishes to receive the location data. In one embodiment, the set of public keys is a sequence Pi of public keys generated based on a tracking-prevention secret. The public key sequence Pi corresponds to the private key matching sequence di. The mobile device 102 can generate the public key sequence and the corresponding public key sequence di, where i is a counter or timestamp. In one embodiment, the mobile device 102 can generate the public key (or a 24-hour hash of the public key) for the previous 24 hours and send it within request 330. If no data is found for the 24-hour public key, the mobile device 102 can send a generated key for an earlier period and return to a predetermined location data retention limit.

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

[0070] 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, it may be necessary to send a key to the electronic device to enable the decryption of the location data. In one embodiment, the location data decryption key may be sent to the 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. A notification may be presented to inform the user that the location decryption key is being temporarily shared with the web-based interface server to enable the location data to be decrypted and presented before the location data is displayed via the web-based interface. In one embodiment, the sharing of the location decryption key may be performed via the automatic and temporary delegation of location query rights by a proxy account associated with the web-based interface.

[0071] In one embodiment, the wireless accessory 201 can be put into easy lost mode. In easy 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 easy lost mode can be instructed by the device locator server 203 to relay a message to the wireless accessory 201 informing it that it is in easy lost mode. A similar mechanism can be used to relay a message to the wireless accessory 201 that puts the accessory into 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 unlocked by the owner. Further examples of paired devices using location services can be found in U.S. Patent Application No. 16 / 543,227, “A System and Method for Locating Wireless Accessories,” filed on 16 August 2019, which is incorporated herein by reference in its entirety.

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

[0073] As shown in Figure 4, method 400 includes an operation (402) to perform initial pairing with a wireless accessory. Initial pairing may be Bluetooth pairing or another type of pairing using other wireless technology. During initial pairing, the mobile device and the wireless accessory may exchange identifiers, passkeys, or other authentication credentials that enable wireless data exchange between the mobile or another electronic device and the wireless accessory. In one embodiment, initial pairing with a wireless accessory may include the exchange of authentication credentials associated with the wireless protocol on which pairing is performed, enabling all data exchanged wirelessly to have at least a first encryption layer.

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

[0075] After generating a public / private key pair and one or more additional shared secrets, the mobile device can store the public / private key pair in a keystore (408). In one embodiment, the keystore is a cloud-based keystore that can be synchronized with other devices associated with the same cloud service account or family of cloud service accounts to which the mobile device and wireless accessory are associated. The cloud-based keystore enables the wireless accessory to be located by other synchronized devices. The mobile device can then register the wireless accessory with a device management server (410). Registering the wireless accessory with the device management server can form an association between the wireless accessory and the cloud service account to which the mobile device is associated. In some embodiments, the mobile device may register the wireless accessory and device group 104. Information stored in the device group profile for the device group can also be synchronized between devices associated with 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 the mobile device, such as the device locator server 203 in Figures 2 and 3.

[0076] Figure 5A shows a network operating environment for an electronic device according to one embodiment. Figure 5A shows a system 500 that can delegate access to a subset of locator services of a wireless accessory 530 of an owner device 502 to a shared device 504 for a defined period of time. In one embodiment, the system 500 includes an owner device 502, a shared device 504, a device location server 520, a delegate server 534, and a wireless accessory 530. The owner device 502 and the shared device 504 may each be variations of a mobile device 102 as described herein. The owner device 502 may discover the wireless accessory 530 via ownership 532 or send commands to the wireless accessory 530. The wireless accessory 530 may be a variation of a wireless accessory 201 as described herein. The device location server 520 may be a variation of a device location server 203 as described herein. The delegate server 534 may be a variation of a delegate server 107 as described herein. In some embodiments, the owner device does not directly share the encryption key that the owner device 502 transmits in requesting device location services from the device location server 520 with the shared device. The owner device 502 transmits the delegate encryption key provided to the shared device 504 during authentication to the shared device to the delegate server 534. Server-mediated sharing implemented by the device location server 520 and the delegate server 534 allows the owner device 502 to indirectly share with the device location services of the accessory device 530, which have time limits on sharing.

[0077] The user of owner device 502 may delegate all or a subset of the accessible device location services on device location server 520 to the shared party(s) via the delegation UI 503 and the transfer of a delegate key 505 to the shared record in the shared database established on the delegate server 534 for the shared party(s). If the user of owner device 502 is accepted by the shared party(s) to request participation in the sharing of device location services with the owner and one or more shared parties(s) (multiple shared parties are illustrated in Figure 5B), the user may establish an access policy 531 with the shared party(s). The access policy 531 allows the shared party(s) to set restrictions on whether existing shared parties(s) can access the location information of their shared party(s) devices 504. A shared user is notified of the current shared user to whom location service access of accessory device 530 has been delegated, and via the delegate / shared user delegation UI 506, the shared user can set restrictions on when that location information is leaked to other shared users when the shared user is near the wireless accessory 530 and / or when acting as a finder device that detects accessory devices 533 and uploads device location information 522 of accessory device 530.

[0078] The user of owner device 502 can, via the delegation UI 503, select one or more capabilities presented by a device location service (illustrated as device location server 520) that can be delegated to the shared device 504 for a defined period of time. The shared device can be registered as a shared device in delegate server 534 by identifiers such as the user's account identifier, the account identifier of a set of users, and / or the account identifier for an external entity stored in the shared record of the shared database in delegate server. In one embodiment, delegate server 534 provides the shared device 504 with a delegate key (e.g., an encryption key such as a decryption key) 507 and metadata for sharing to facilitate sharing, upon request. The device owner may request that metadata in the shared record and one or more delegate keys be stored for retrieval by the shared device when authenticating the shared device in delegate server 534.

[0079] Metadata defines a set of conditions for sharing a set of location service capabilities. The metadata may define sharing by an identifier for accessory device 530, an account identifier for the shareholder, a time limit for sharing, an access policy for the shareholder participating in the sharing of accessory device 530, and / or other conditions for sharing. An access policy for each shareholder participating in the sharing of accessory device 530's location services is established when the shareholder accepts a request to join the sharing. The access policy may define when, where, and to whom the shareholder is permitted to notify the location of their individual shareholder device. For example, when a shareholder joins a sharing, the shareholder device may act as a finder device for the accessory device, and the shareholder device may send encrypted location information of the accessory device to the location service server 520 when the shareholder device is within range of receiving a beacon signal from accessory device 530.

[0080] In delegate key transfer 507, the delegate key is an encryption key (e.g., a decryption key) that enables the shared user to access the location service in response to a request to the location service server. In some embodiments, the delegate key is a decryption key that can be provided to the shared user by the owner device 502 via the delegate server 534 to decrypt the encrypted blob 521 stored in the location service server 520. The encrypted blob may be encrypted data padded with additional data designed to minimize data leakage.

[0081] The first type of delegate key 507 transferred to the shared device 504 is a decryption key that enables the shared device to decrypt an encrypted blob (e.g., an encrypted capability key blob or an encrypted location blob) received by the shared device 504 from the location service server 520. For example, the device locator server 520 may send a blob encrypted with an encrypted device locator capability key, and the shared device 504 may decrypt the encrypted blob to access the capability key. The capability key may be sent in a request from the shared device to the device location server 520 that authorizes the shared device 504 to access the device locator service corresponding to the capability key. In another example, the device locator server 520 may send a blob encrypted with encrypted location information and the corresponding decryption key(s) for the encrypted location information. Continuing this example, the received encrypted blob can be decrypted by the shared device 504 using the transferred delegate key 507 to obtain the decryption keys for both the encrypted location information and the encrypted location information, and the shared device 504 can decrypt the location information using the obtained decryption keys.

[0082] A second type of delegate key is an encryption key (e.g., a decryption key) that can be transmitted by the shared device 504 in a request for on-demand decryption 522 of the encrypted blob 521 to the device location server 520 on behalf of the shared device. In one embodiment, the encrypted blob 521 stored in the device location server 520 includes a public key or a hash of a public key generated by the owner device 502 to access the location information of the wireless accessory device 530. The location service server 520 may ensure that the shared device satisfies a set of conditions for accessing each device locator service and will service device locator requests from the shared device based on conditions defined by the owner of the accessory device 530 in the metadata. The second type of delegate key enables the shared device to access the location services of the accessory device 530 using an encryption key generated and / or accessible by the owner device 502. By providing the owner device with an encrypted encryption key (e.g., an encrypted hash of the public key) and a delegate decryption key to the device location server 520, the owner device 502 can grant the shared device 504 access to the location information while maintaining control over access to the encryption key generated based on the shared secret between the accessory device and the owner device.

[0083] In one embodiment, an encrypted blob stored in the device location server 520 includes a public key or a hash of a public key generated by the owner device 502 and stored in the device location server 520 to access the location information of the wireless accessory device 530. For example, the public key underlying the hashed public key stored in the encrypted blob could be a set of rolling public keys generated by both the owner device 502 and the accessory device 530 based on a shared secret (as shown in Figure 3). Continuing this example, the shared device 504 may request location information 522 and provide a decryption key for the encrypted public hash, thereby enabling the device location server 520 to look up the location information using the public key hash provided by the owner device on behalf of the shared device. The set of encrypted public key hashes may be accessible when the owner device 502 is offline, and the device owner may limit access to future location information of the accessory device 530 by not directly providing the shared device with the public key based on the shared secret.

[0084] In one embodiment, the delegation of the accessory device location finding service may be performed by the owner device 502 by generating encrypted public keys or hashes of public keys for one or more privacy windows expected over the duration and providing those keys in the encrypted blobs to the device locator server 520 via the transfer of the encrypted blobs 521. A privacy window is a predetermined period of time, such as M minutes, during which the set of generated keys associated with the wireless accessory is valid. In one embodiment, there is at least one new key for each privacy window. For example, if the duration is 1 hour and the privacy windows are 15 minutes, the set of generated keys for privacy windows (e.g., 15 minutes) within that time will include at least four keys.

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

[0086] In some embodiments, the delegate server 534 may function as a key escrow, holding a set of keys for the shared user that are retained for a defined duration, and the delegate server 534 may, upon request, send the delegate key when the shared user meets a set of conditions. Because the delegate server 534 functions as a key escrow, the device owners and shared users participating in the sharing are opaque to the device locator service provider 520.

[0087] In some embodiments, metadata on the owner device 502 associated with the shared user, and / or metadata selected by the user on the owner device 502 to associate with a delegate entity for sharing, may be used to determine the number of privacy windows and associated hashed public keys that are accessible for location information requests. For example, if the user of the owner device 502 chooses to associate privacy windows over a duration, the public key generated by the owner device in the cryptographic blob 521 may include several privacy windows expected by the owner over that duration. The metadata may also establish the period for which a shared record with a delegate key should exist in the shared database of the delegate server 534. For example, when sharing is terminated by the owner, the share may be automatically dismantled. The metadata may also establish whether a delegate key should be generated for the expected duration or a portion of the expected duration of an event. For example, the metadata may indicate that only a portion of the delegate key for a given duration may need to be generated, and that the key may be generated ad-hoc or on-demand for device locator information. In another example, the metadata may indicate a set of conditions for sharing location information. The metadata may restrict the sharing of location information based on the device status of the accessory device 530 when the location information is stored in the device locator server 520, such as "not near the owner" or "not near another shareee."

[0088] The transferred delegate key may enable the shared device 504 to perform a set of actions, including but not limited to tracking, accessing, using, or controlling the radio accessory 530 via encrypted data in an encrypted blob at the device location server 520. For example, the owner device 502 may delegate to the shared device 504 the ability 533 to discover the radio accessory via a beacon signal 531 transmitted by the radio accessory 530, provided that the shared device 504 meets a set of conditions. The owner device 502 may also delegate to the shared device 504 the ability to query 522 for the location of the radio accessory 530 via the device location server 520, provided that the shared device 504 meets a set of conditions. The device locator server 520 may provide an encrypted key in an encrypted blob for the radio accessory's location service capability, and the shared device 503 may use the delegate key 507 to decrypt the encrypted blob and access the capability key. In some embodiments, a delegate key accessible by a browser or third-party application may be used to decrypt the encrypted blob and access the capability key.

[0089] An authenticated user of a shared device 504 associated with a delegate entity may access the locator service 520 after fulfilling a set of conditions. These conditions may be established by the device owner and / or the delegate entity. The conditions may relate to the status of the owner device, the status of the wireless accessory, the shared device, and / or the authenticated user of the delegate device. The conditions may be time-based, geographically-based, based on the status of the wireless accessory, and / or the location of the owner device or a shared user of the owner device. For example, if the owner device 534 or another shared user is near the wireless accessory 530, the delegate device 504 may not be able to request the device locator service. Continuing this example, in order to ensure that the locator service is not permitted when the owner device 534 requests the locator service, the following conditions may need to be met for the shared device: namely, the wireless accessory status is not near the owner, the wireless accessory status is not near the shared device, the device locator request is requested during the owner device's delegate entity event, the current or last known location of the wireless accessory was not a secure location of the owner device, and / or the user has not explicitly terminated the delegation of the locator service. In one embodiment, each shared device may agree to provide their location information to other shared devices when they are located near the wireless accessory. In some embodiments, the set of conditions for an authenticated user of the shared device 504 to access the locator service of the wireless accessory 530 may be implied based on metadata accessible on the owner device 502 associated with the event. The permitted device locator service may change dynamically, for example, if the wireless accessory has a lost status.

[0090] The delegate server 534 functions as a key escrow and may provide the shared device with a delegate key in the form of a decryption key upon the shared device's request and authentication. In some embodiments, the device location server 520 functions as a key escrow and may perform decryption on behalf of the shared device 504. For example, the shared device 504 may send a request for location information of a wireless accessory and provide the decryption key in the request to the location server 520, which is obtained by the shared device via the delegate server 534. Continuing this example, the decryption key from the shared device may be used by the device location server 540 to decrypt an encrypted blob sent to the device location server 520 by the mobile device 502. The encrypted blob stored in the device location server 520 may contain a set of public keys or public key hashes that can function as beacon identifiers for beacon data. The device location server 520 may use public key hashes to retrieve the corresponding location information of the wireless accessory 530 and provide the encrypted location information and decryption key for decrypting the location information encrypted by the shared device. The shared user 504 can decrypt both the provided decryption key and / or location information using the delegate key provided by the delegate server device 534.

[0091] The owner device 502 may generate a set of public keys based on the confidential information held by the owner device 502 and the wireless accessory 530, and the timestamps on which the owner device 502 wishes to receive location data from the shared device 504. By restricting the decryption capabilities of the owner device 502 and the wireless accessory 530 for decrypting the underlying public keys to the device location server 520, the cryptographic capabilities of the mobile device 502 and the underlying public keys remain opaque to the shared device.

[0092] Embodiments are described herein with an owner device 502 having the ability to maintain and / or create shares, but those skilled in the art will recognize that the owner may provide these abilities to other devices for maintaining and / or creating shares. The ability to maintain and / or create shares includes, but is not limited to, generating a public key based on confidential information (e.g., a shared secret) shared between the owner device 502 and the wireless accessory 530, generating a public hash, generating an encrypted blob, access to metadata, access to an encrypted key, and / or generating a delegate key (e.g., first and second types of delegate keys) to create a shared and / or delegate device locator service. In particular, a user of the owner device 502 may delegate maintenance and / or sharing to other devices when the owner device is offline to ensure that outdated location information is not provided to delegates. The owner device 502 may provide the data and rights necessary to maintain and / or create shares on behalf of the owner. The owner device 502 may grant rights to other devices associated with an online account associated with the owner device. An online account associated with an owner account may be a user account for the owner of the owner device, and the device may be a second device used by the owner of owner device 502. The online account may be an account from a set of online accounts owned by other users, such as a set of online accounts for a family or one or more online accounts of shared users. In one embodiment, a cloud-based (e.g., server-based) keystore may provide sharing information to other devices to provide the ability to maintain and / or create shares, and the keystore may be synchronized with other devices associated with the same cloud service account or family of cloud service accounts to which owner device 502 and optionally wireless accessory 530 are associated.

[0093] In some embodiments, other devices, in one embodiment, the owner device and a set of other devices associated with the owner device, can use an implementation of leader selection 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 a share. The leader device may be selected when the owner device 502 is offline and / or when maintaining or creating a share would be too resource-intensive for the owner device 502 receiving the request.

[0094] Figure 5B shows a network operating environment for an electronic device according to one embodiment. Figure 5B shows a system 501 similar to system 500 in Figure 5A, in which access to a subset of the locator services of the wireless accessory 530 of the owner device 502 can be delegated to one or more shared users for a defined period of time. Figure 5B shows the effect of adding or removing a second shared user 506B with respect to the device location server 520, the delegate server 534, and the encrypted blobs and delegate keys stored in the respective shared user devices 504A and 504B (collectively 504). The user of the owner device 502 can establish an access policy 531B with the second shared user via the delegation UI 503 when the shared user accepts a request to participate in sharing the location services of the accessory device 530. After the access policy 531 is established, an encrypted blob 521 having the encrypted capability key of the shared user and an encrypted public key or hash of a public key corresponding to the location information of the accessory device 530 accessible to the shared user is stored in the device location server 520. The delegate key of the shared user device 504 is transferred to the delegate server device 534. During authentication at the delegate server 534, the first shared user device 504A receives the delegate key and metadata via delegate key transfer 507A. Similarly, the second shared user device 504B receives the delegate key and metadata via delegate key transfer 507B during authentication of the second shared user at the delegate server 534.

[0095] Next, the first shared device 504A may send a query or command request 522A, and the second shared device 504B may send a query or command request 522B along with its respective delegate key and metadata. Whenever a shared user is added to or removed from a share defined in the database of the delegate server device 534, a new set of delegate keys and metadata is sent to the delegate server device 534, in addition to the new encrypted blob 521 stored in the device location server 520. The first shared user having the first shared device 504A may upload its encrypted location to the device location server 509A when the first shared device 504 detects a beacon signal from the accessory device 530. In accordance with the access policy 531A established with the first shared device 504A and / or the access policy 531B with the second shared device 504B, the location information of the first shared device, which is made public when the location information is transmitted to the device location server 520 by the first shared device 504A, may be shared with the owner device 502 and / or the second shared device 504B. If the access policy indicates that the first shared device 504B does not want to share the location information when it is near the accessory device 530, other shared devices and / or finder devices not associated with the sharing, which anonymously provide the crowdsourced location information of the wireless accessory 530, may be used (as shown in Figures 2 and 3).

[0096] Figure 5C shows a network operating environment for an electronic device according to one embodiment. Figure 5C shows a system 5500 having an interaction between a shared device 504 and a device location server 520 when the shared device 504 sends a request 522 for location information 522 about an accessory device 530 to the device location server 520. The shared device 504 sends a request for location information 522 of the accessory device 530 along with metadata and a delegate decryption key of at least one hashed public key received from the delegate server 534. In one embodiment, the shared device 504 sends a request to the device location server 520 having a shared resource locator via a browser or web application (such as a third-party application), the shared resource locator including a unique identifier that can be used to look up a shared identifier for the share. The shared identifier can be used to look up the share and the corresponding metadata and the delegate key for the share. The delegate server 534 can send the metadata and the delegate key on behalf of the shared device 504.

[0097] The encryption blob 521 of the device location server 520 includes an encrypted hashed public key Pi, as described herein with reference to Figures 2 and 3. The encryption blob 521 may include a set of public keys or public key hashes that can function as beacon identifiers for the beacon data of the accessory device 530. The mobile device 502 may generate a set of public keys based on secret information held by the mobile device 502 and the radio accessory 530 (e.g., a shared secret and / or derived from a shared secret) and a timestamp that the mobile device 530 wishes to grant a shareholder access to the location data of the radio accessory 530. In one embodiment, the set of public keys is a sequence of public keys Pi generated based on a tracking-prevention secret. The sequence of public keys Pi corresponds to a matching sequence di of secret keys. The mobile device 502 may generate a sequence of public keys, as well as a corresponding sequence di of public keys, where i is a counter or timestamp. In one embodiment, the mobile device 602 may generate a 24-hour public key (or a hash of a 24-hour public key) within an encrypted blob 521 and transmit it to the device location server 520.

[0098] The delegate decryption key transmitted in a request from the shared device 504 (or on behalf of the shared device 504 via the delegate server 534) to the device location server 520 may be used by the device location server 520 to decrypt a hashed public key that the shared device is permitted to access. The hashed public key may be used by the device location server 520 to look up location information 560 of accessory device 530 provided by a finder device corresponding to the hashed public key (e.g., anonymously and / or by a participating shared device). The device location server 560 may check the conditions of the metadata provided by the shared device 504 in the location request to ensure that the location information 560 satisfies the access conditions established between the shared device and the owner. The delegate decryption key is a decryption key (e.g., a second type of delegate key) transmitted by the shared device in a request for on-demand decryption 522 of the encrypted blob 521 at the device location server 520, which is performed on behalf of the shared device, enabling the shared device to access the location information while maintaining the restrictions determined by the owner. By performing a lookup on the device location server, the owner can control the time frame during which the shared user can access the information. In some embodiments, if the sharing is removed, the shared user will not be able to access the future location information of the accessory device 530 and / or the location information of the accessory device. In some embodiments, by storing an encrypted hashed public key in an encrypted blob 521 on the device location server, the shared user can access the location information of the accessory device 530 when the owner device 502 is offline, powered off, and / or unpaired from the accessory device 530.

[0099] Figure 5D shows a network operating environment for an electronic device according to one embodiment. Figure 5D shows a system 5501 having an interaction between a shared device 504 and a device location server 520, when a shared device 504 sends a request 522 for location information about an accessory device 530 to the device location server 520, and the device location server 520 sends a response having an encrypted location blob 562 and an encrypted location blob key 564 that the shared device is permitted to access. As shown in 560, the device location server 520 looks up the delegate decryption key of the hashed public key to produce a set of encrypted locations for the accessory device 530. The shared device is permitted to access the location information of the shaded locations (as shown by 568, for example) according to the access policy established when setting up the share. The metadata may indicate the conditions for access to the location information of the accessory device 530, such as the access policy established by the share between the owner and one or more shared devices. In some embodiments, the metadata may include conditions such as the time when the location information may be shared and / or whether the location information was sent to the device location server when the accessory device is near the owner or another shared user. As a further example, if a first shared user detects a beacon of the wireless accessory 530 and encrypts the location information with an encryption key associated with the first shared user for subsequent uploading and storage at the device location server, the first shared user may have an established access policy regarding whether the wireless accessory and the first shared user's location information are shared with other shared users and / or the owner. The encrypted location blob 562 that the shared user is permitted to receive is sent to the shared user device 504 along with the encrypted location decryption key 564.The shared user has a delegate decryption key (provided via delegate server 534) to decrypt the encrypted location decryption key 564 and use the location decryption key to access the location information in the encrypted blob. In one embodiment, the delegate decryption key is accessible via a third-party server, via a third-party application and / or web browser, to decrypt the encrypted location blob.

[0100] Figure 6A is a flowchart illustrating a method for use in a device locator system according to one embodiment. Figure 6A shows the interaction between an owner device 502, a device location server 520, and a delegate server 534 for providing server-mediated management for sharing accessory devices. The owner device 502 may establish an access policy with the shared devices when accepting a request to participate in sharing the device location service for accessory device 530 with one or more shared devices (601). The shared devices are notified of the current shared devices to whom they have been entrusted with access to the location service for accessory device 530. In some embodiments, one or more shared devices and the owner device 502 are considered as part of a “circle of trust” for access to accessory device location information. The access policy may define when location information related to the owner or shared device is leaked to other shared devices, such as when accessory device 530 is near a shared device or owner. The owner device and shared device are variations of the finder device and may optionally transmit encrypted location information of accessory device 530.

[0101] The owner device 502 generates a set of public key hashes that can be used to look up the location information of the accessory device 530 over a certain duration (e.g., one or more privacy windows). The owner device 502 may generate a hashed public key Pi as described herein with reference to Figures 2 and 3. A set of public keys or public key hashes that can function as a beacon identifier for the beacon data of the accessory device 530 may be used to look up the location information of the accessory device 530. The mobile device 502 may generate a set of public keys based on secret information held by the mobile device 502 and the wireless accessory 530, and a timestamp on which the mobile device 530 desires the shared party to access the location data of the wireless accessory 530. In one embodiment, the set of public keys is a sequence of public keys Pi generated based on the tracking-prevention secret described with reference to Figures 2 and 3. The sequence of public keys Pi corresponds to a matching sequence di of the secret key. The mobile device 502 can generate a sequence of public keys, as well as a corresponding sequence di of public keys, where i is a counter or timestamp.

[0102] The owner device encrypts a set of public hashes (606) to form an encrypted blob (604) to be stored in the device location server 520. In one embodiment, the owner device 502 may generate a 24-hour public key (or a hash of the 24-hour public key) in the encrypted blob 521 and send it to the device location server 520.

[0103] The owner device may generate one or more capability keys for device location service capabilities, such as playing audio, presenting the Finder Experience user interface, or requesting the addition of another shared user. The capability keys may be provided in an encrypted blob, which is encrypted and stored in the device location server 520 (606). The decryption key for the encrypted blob and metadata providing the conditions for the shared user's location service are sent to the delegate server 534 (610).

[0104] The delegate key (decryption key) and metadata are stored in the delegate server 534's shared database (612). The metadata can determine the shareholder, the expiration time of the share, and / or other conditions of the share (614). The shareholder may request the share information from the delegate server 534, and the delegate key and metadata are provided to the shareholder device in the process of authenticating the shareholder's received credentials (616) (618).

[0105] The shared device 504 may request device location services for accessory device 530 from the device location server 520 using metadata and a hashed public key delegate capability key and / or delegate decryption key, as described with respect to Figures 5A to 5D (622). In another embodiment, the shared user may request device location services for accessory device 530 via a shared resource locator through a browser or third-party application, the shared resource locator may include a unique identifier corresponding to the shared identifier. The shared identifier may be used in the delegate server 534 to look up the share in order to retrieve the request metadata, delegate capability key, and / or delegate decryption key. The shared user's access policy for location services may be verified by determining whether it satisfies conditions in the received metadata (624). In some embodiments, the metadata may identify the expected shared user identifier, 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, an access policy established between the shared user and / or owner participating in the sharing process may specify timeframes and / or accessory device status information during which access is permitted or denied. Continuing this example, the access policy may specify that device statuses "near owner device" and / or "near shared user device" are not permitted during defined timeframes.

[0106] The device locator service may optionally provide an encrypted device location service capability key, and the shared user may decrypt the capability key encrypted with a delegate decryption key provided to the shared user by the delegate server (626). In some embodiments, the device location server 520 may use the delegate key received in a request from the shared user device to decrypt data from an encrypted blob on the device location server 520 and access location information on behalf of the shared user (626). For example, delegate decryption of a hashed public key provided to the device location server 520 in a location request from the shared user device may allow on-demand lookup and provision of location information for an accessory device 530, as described in Figures 5A to 5D. The delegate decryption key may be used by the device location server 520 to retrieve a hash of the public key which can be used to retrieve encrypted location data and an encrypted decryption key for the location information of the wireless accessory 530. The shared metadata may provide conditions for location information that is permitted to be sent to the shared device, such as location information obtained because the accessory device status was not “near owner”. The shared device may receive encrypted location information and a decryption key for the encrypted location information. The shared device 504 may have a delegate key from the delegate server 534 to decrypt the encrypted decryption key and access the location information of the wireless accessory 530. In one embodiment, the delegate key is accessed via a browser and / or from a third-party server.

[0107] Figure 6B is a flowchart illustrating a method for use in a device locator system according to one embodiment. Figure 6B shows the interaction between a shared device 504, a device location server 520, and a delegate server 534 for providing server-mediated management of an accessory device 530. The owner device 502 may establish an access policy with the shared devices when accepting a request to participate in sharing the device location service for the accessory device with one or more shared devices (601). The shared devices are notified of the current shared device to which they have been entrusted with access to the location service of the accessory device 530. In some embodiments, one or more shared devices and the owner device are considered as part of a “circle of trust” for access to accessory device location information.

[0108] A shared device may send a request for shared information from the delegate server 534 along with its authentication credentials (603). Upon authentication of the received credentials of the shared device (616), the delegate key and metadata are provided to the shared device (618). The delegate key (decryption key) and metadata are stored in the shared database of the delegate server 534. The metadata may determine the shared user, the sharing expiration time, the access policy, and / or other conditions of the sharing. Optionally, updated delegate keys and metadata are sent to the shared device 504 in response to the addition or removal of another shared user (620). A first type of delegate key is a decryption key provided to the shared user that enables the shared user to decrypt encrypted blobs (e.g., encrypted capability key blobs, encrypted location blobs, etc.) received by the shared device 504 from the location service server 520. For example, the device locator server 520 may send an encrypted capability key blob along with an encrypted device locator capability key to enable the shared user to request a device locator service corresponding to the capability key. In another example, if the shared user is granted location finding capability by the owner, the device locator server 520 may send encrypted location information in an encrypted location blob that can be decrypted by the shared user using a delegate key 507. A second type of delegate key is a decryption key that can be sent by the shared user on behalf of the shared user in a request for on-demand decryption 522 of the encrypted blob 521 at the device location server 520.

[0109] The shared device 503 may send a request for the device location capability of the shared accessory device 530 (605), the request may include metadata having conditions for sharing with the shared device. The device location server 520 may receive a request for the location service of the accessory device 530 from the shared device (622). After verifying the shared access policy provided in the metadata along with the request (624), the device location server 520 may respond to the request with an optionally encrypted capability key (626A). The shared device 504 may decrypt the capability of the shared accessory device 530 to determine the location service available to the shared device 504.

[0110] Optionally, a request from the shared device (622) may include a delegate key that enables the device location server 520 to decrypt an encrypted blob on the device location server 520. For example, the device location server 520 may use the delegate decryption key received in the request from the shared device 504 to decrypt an encrypted hashed public key in the encrypted blob on the device location server 520 (609). The device location server 520 may decrypt the public hashed key on behalf of the shared device (626B) and perform a lookup to send the encrypted location and the decryption key for the encrypted location generated by the lookup (626C), as described in Figures 5A to 5D. In another embodiment, if the request from the shared device is received via a shared resource locator, the shared identifier may be used to retrieve the delegate decryption key from the delegate server 534.

[0111] Figures 7A to 9B show user interfaces for a device locator service according to several embodiments. As shown in Figure 7A, the owner device's device locator UI 701 can present a graphical user interface on the electronic device 702 having an accessory device location 704 for an accessory device associated with item 708 “house key,” and the location information is presented as shown by the item “house key” which is located together with the shared person 706 in the map. The owner and shared person have access policies that allow them to have the location information of the owner item even when the item has a device status in which it is located near the shared person, as illustrated by the shared person 706 listed as “Sara Parker” 708 in the device locator UI 701. The owner has device locator capabilities to “play audio” 710 and “notify” 712 (provided in more detail in 716 in Figure 7B). As shown in Figure 7B, the owner device's device locator UI 701 can present a graphical user interface on an electronic device 702 having an accessory device location 704. The owner, designated as "I" 718, has the device locator capabilities to "share items" by selecting affordances for "play sound" 710, "notify" 712 (e.g., "notify when found," "notify when left behind," "notify when moved"), and "add person." As shown in Figure 7B, owner "I" 718 shares a "house key" with "Sara Parker."

[0112] As shown in Figure 8A, the device locator UI 803 of the owner device can present a graphical user interface on the electronic device 802 having the accessory device location of the accessory device associated with item 804 "Frank's Backpack," and the location information is presented so as to be indicated by the item "Frank's Backpack" which is location-identified in the map relative to the owner's position in the map. As shown in Figure 8B, the device locator UI 803 can present the graphical user interface to the electronic device 802 with a request from another owner "Frank de Jong" (or a shareholder capable of sharing another owner's accessory device) 806 who should be a shareholder of the item "House Key." As shown in Figure 8C, the device locator UI 803 can present the graphical user interface to the electronic device 802 with a request from another owner "Frank de Jong" (or a shareholder capable of sharing another owner's accessory device) 808 who should be a shareholder of the item "House Key," and a request from "Peter Parker" 810 to share the accessory device associated with "Dylan the Dog." As shown in Figure 8D, the device locator UI 803 may present a graphical user interface on an electronic device 802 that has a shared "house key" 812 in addition to the recipients of the shared item (e.g., "Jane", "Billy", and "David"), and on an accessory device associated with "Dylan the dog" 814 in addition to the recipient (e.g., "Jane"). Each recipient of the accessory devices associated with the "house key" and "Dylan the dog" has agreed to an access policy to share their names with the recipients of the shared item shown in Figure 8D.As shown in Figure 9A, the device locator UI 901 may present a graphical user interface on the electronic device 902 that includes an interface for creating a sharing request for the "house key" 904 to potential recipients (e.g., contacts "Lynne Devine", "Anna Brown", and "Lori Wilson") as shown in Figure 9B, and accessory devices associated with the "dog Dylan" 814 in addition to the recipient (e.g., "Jane"). As shown in Figure 9C, the device locator UI 905 may present a graphical user interface on the electronic device 902 to create a sharing request for the "house key" with contacts (e.g., "John Appleseed" and "John Read"), and in Figure 9D, the device locator UI 907 allows the selection of multiple recipient contacts for the sharing request.

[0113] Figure 10 shows a flowchart 1000 of a method for enabling location services for a target accessory device according to one embodiment. As shown in Figure 10, the method 1000 includes the operation of an electronic device invoking a device locator UI (1001). In response to invoking 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, can perform an operation to retrieve location information contained in a beacon signal broadcast by the radio accessory during a first period (1002). In the case of owner device 502, the electronic generates a set of public keys contained in a beacon signal broadcast by the radio accessory during a first period. The first period may be, for example, the past 24 hours. In another example, the first period may be a 15-minute privacy window. Alternatively, in the case of the shared device 504, encrypted location information is retrieved on demand from the device locator server 534 when the shared device 504 sends a request having metadata and a decryption key for hashing the public key within the key period (1003). The owner electronic device is aware of the frequency at which the radio accessory generates a new public key and can use the shared secret key generated by the radio accessory to generate a set of public keys corresponding to the keys generated by the radio accessory over a first period. The owner electronic device 502 may provide the generated keys to the device location server 520 for retrieval by the shared device 504. The shared electronic device 504 may then send the decryption key of the encrypted hashed public key in a request to the device locator server to send location data corresponding to the set of hashed public keys. In one embodiment, the location data sent by the server on request is encrypted using the public key sent as the beacon identifier of the radio accessory.The shared electronic device 504 can decrypt the encrypted location data received by the device location server using a secret key provided by the delegate server (1003). The shared electronic device 504 can then process the location data to determine the location with the highest probability for the wireless accessory (1004). The process can be continued by acquiring location information during the following period (1002).

[0114] The processing of 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 and 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 may further include UWB ranging information and / or RSSI information about the beacon detected by the finder device. The electronic device can analyze the UWB ranging information and / or RSSI information in relation to the device location to reveal a more accurate location of the wireless accessory. Data transmitted by the finder device and that can be used for location processing is shown in Figure 14 and described below.

[0115] Figure 11A shows an operating environment 800 for an electronic device according to one embodiment. Devices 101 and 504 can communicate wirelessly via wireless communication signals 605, discover each other by scanning wireless channels, transmit and receive beacons or beacon frames on wireless channels, establish connections (e.g., by transmitting connection requests), and / or transmit and receive packets or frames (which may include additional information such as requests and / or data as payloads). In location environment 1108, mobile shared device 504 may receive and discover beacon signals from wireless accessory 101. Wireless communication signals 1110 may be carrier signals compliant with wireless communication technologies such as, but not limited to, Wi-Fi or Bluetooth. In addition to wireless communication, mobile device 504, smart home device(s) 107, and / or wireless accessory device 101 perform wireless ranging operations using wireless ranging signals 1106 (as shown between mobile device 504 and wireless accessory device 101). The wireless ranging signal may be an ultra-wideband signal that can be used, for example, to determine the distance and / or angle between the wireless accessory device 101 and the mobile device 504 using the techniques described herein.

[0116] In one embodiment, the wireless accessory 101 can periodically transmit a wireless beacon signal. The wireless accessory 101 can transmit the beacon signal using one of the various wireless technologies described herein (e.g., Bluetooth, Wi-Fi, etc.), and in one embodiment, it can also use ultra-wideband (UWB) wireless technology for beacon transmission. The beacon signal can be transmitted using a single wireless technology, one of several selectable wireless technologies, or multiple simultaneous wireless technologies. The beacon signal can transmit a beacon identifier that includes information for specifically identifying individual wireless accessories 101 and / or groups of devices. In one embodiment, the beacon identifier is a public encryption key associated with the wireless accessory device.

[0117] The shared device 504 may send a request to the device location server 520 for at least one of the following location service capabilities: 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 11B and 12. The shared device 504 may use the device locator service if the conditions are met for the shared device 504 and its authenticated user. For example, if the authenticated shared user has location finding capabilities, the shared device 504 may send a request for the locator service.

[0118] As shown in Figure 11B, the device locator UI 204 may present a graphical user interface within an electronic device 2100 having a proximity view using signal strength measurements. The proximity view 2124 for finding "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 that represents proximity to the target radio accessory device 101 by size, color, shape, color gradient, shading, pattern, and / or any other technique for visual indicators within the 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 radio accessory device 101 along the trajectory 2138 taken by the user to find the target radio accessory device 101, so that it is represented by a darker color and / or a larger size compared to the other indicators. In some embodiments, the proximity view of the user interface 204 may present distance measurement information using distance measurement values ​​and display an arrow 2128 indicating the direction of the target radio accessory device 101 and the distance 2136 to the target radio accessory device 101. In other embodiments, the trajectory may be shown in a grid such as a hexagonal grid, along with a visual indicator consisting of areas of the grid designated by color, gradient, shading, and / or any other markings 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 devices, and / or a combination thereof.

[0119] In one embodiment, a signal strength measurement from a signal received by the mobile device 102 may be used to represent proximity to the target device within the user interface to indicate when the mobile device 102 is close to the target device. In some embodiments, a proximity indicator may be presented using signal strength information of smart home devices along a trajectory. A “proximity view” 2104, as shown in Figure 12, may present proximity information using visualization techniques and 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 a trajectory 2118 presented within the user interface 204, representing the path taken by the user in their exploration. In some embodiments, the visual indicators may be user interface elements displayed using any other visualization techniques to represent gradients, colors, color gradients, sizes, shapes, and / or signal strength values ​​and corresponding defined proximity categories (e.g., far, near, very 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 in the proximity view 2104 may be a user interface element that represents proximity to the target radio accessory device by size and color gradient within the user interface 204. In the proximity view 2104, for example, indicator 2106 is closest to the target radio accessory device along the trajectory 2118 taken by the user to find the target radio accessory device, so that it is 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 the 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 analyzing a sequence of images collected using a mobile device to estimate camera movement across the sequence of images.

[0120] In some embodiments, the mobile device 102 can be moved so as to be within threshold range of the target accessory device 101, and communication between the mobile device and the target device is used to enable the ranging process to determine the distance from the target device and the direction to the target device. As shown in Figure 12, the “ranging view” 2120 of the user interface 204 can provide distance measurements 2116 in addition to the direction 2108 to the target device, which may be selectively displayed. The proximity view 2104 for finding the target device may be used when ranging data from the ranging view 2120 is unavailable because, in some embodiments, the target device is not within threshold range of the mobile device 102, the transmitter of the target device 101 is not in the field of view of the receiver in the mobile device, and / or the mobile device does not have a nearly unobstructed view of the target device 101. The target device 101 may be in the field of view of the mobile device 102 when the receiver in the mobile device 102 has a view of the target device transmitter.

[0121] In some embodiments, ranging using ultra-wideband (UWB) radio technology can provide relatively accurate location or distance data to a target device, but it is a relatively short-range radio frequency (RF) radio 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 line of sight to the target device in order to acquire optimal ranging location data. Proximity information in the form of signal strength information may be relatively less accurate compared to UWB, but it may cover a wider area and provide a longer range, and can be obtained from advertisements before a radio connection is established. In some embodiments, bidirectional communication may not be established using a connection between the mobile device and the target device, but advertisements received on the mobile device can provide signal strength information to help guide the user to the target device before a connection is established. A combination of technologies can help the user locate the target radio accessory device.

[0122] Various embodiments will be described with reference to the drawings. However, some embodiments can be implemented without using one or more of these specific details, and in combination with other known methods and configurations. The following description will include numerous specific details, such as specific configurations, dimensions, and processes, in order to provide a thorough understanding of the embodiments. In other cases, well-known semiconductor processes and manufacturing techniques will not be described in particular detail, so as not to unnecessarily obscure the embodiments. Throughout this specification, a reference to “one embodiment” means that a particular feature, structure, configuration, or characteristic described in relation to that embodiment is included in at least one embodiment. Thus, references to the phrase “in one embodiment” in various places throughout this specification do not necessarily refer to the same embodiment. Furthermore, certain features, structures, configurations, or characteristics may be optionally and suitably combined in one or more embodiments.

[0123] The following description concerns a computing device that includes a touch-sensitive display. However, it should be understood that the computing device may also include one or more other physical user interface devices. Various applications that can run 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 the corresponding information displayed on the device may be coordinated and / or modified from one application to the next, and / or within each application. Thus, a common physical architecture of the device (such as a touch-sensitive surface) can support a variety of applications with intuitive and transparent user interfaces.

[0124] Some processes are described below in terms of sequential operations. However, please understand that some of the operations described may be performed in a different order. Furthermore, some operations can be performed in parallel rather than sequentially.

[0125] Various embodiments will be described with reference to the drawings. However, some embodiments may be carried out without using one or more of these specific details, and in combination with other known methods and configurations. Throughout this specification, a reference to “one embodiment” means that a particular feature, structure, configuration, or characteristic described in relation to that embodiment is included in at least one embodiment. Thus, references to the phrase “in one embodiment” in various places throughout this specification do not necessarily refer to the same embodiment. Furthermore, certain features, structures, configurations, or characteristics may be optionally and suitably combined in one or more embodiments.

[0126] Various embodiments will be described with reference to the drawings. However, some embodiments can be implemented without using one or more of these specific details, and in combination with other known methods and configurations. The following description will include numerous specific details, such as specific configurations, dimensions, and processes, in order to provide a thorough understanding of the embodiments. In other cases, well-known semiconductor processes and manufacturing techniques will not be described in particular detail, so as not to unnecessarily obscure the embodiments. Throughout this specification, a reference to “one embodiment” means that a particular feature, structure, configuration, or characteristic described in relation to that embodiment is included in at least one embodiment. Thus, references to the phrase “in one embodiment” in various places throughout this specification do not necessarily refer to the same embodiment. Furthermore, certain features, structures, configurations, or characteristics may be optionally and suitably combined in one or more embodiments.

[0127] The following description concerns a computing device that includes a touch-sensitive display. However, it should be understood that the computing device may also include one or more other physical user interface devices. Various applications that can run 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 the corresponding information displayed on the device may be coordinated and / or modified from one application to the next, and / or within each application. Thus, a common physical architecture of the device (such as a touch-sensitive surface) can support a variety of applications with intuitive and transparent user interfaces.

[0128] Some processes are described below in terms of sequential operations. However, please understand that some of the operations described may be performed in a different order. Furthermore, some operations can be performed in parallel rather than sequentially.

[0129] Figure 13 is a block diagram illustrating an exemplary API architecture that may be used in some embodiments of the present invention. As shown in Figure 13, 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 API 2320. API 2320 specifies one or more functions, methods, classes, objects, protocols, data structures, formats, and / or other features of the API implementation component that can be used by an API calling component 2330. API 2320 may specify at least one calling convention that specifies how a function in the API implementation component receives parameters from the API calling component and how a function returns 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 via API 2320 and accesses and uses the features of the API implementation component 2310 specified by API 2320. In response to an API call, the API implementation component 2310 may return a value to the API calling component 2330 via API 2320.

[0130] It should 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 API 2320 and are not available to the API calling component 2330. It should be understood that the API calling component 2330 may reside on the same system as the API implementation component 2310, or it may be located remotely and access the API implementation component 2310 via a network using API 2320. Figure 18 shows a single API calling component 2330 interacting with API 2320, but it should be understood that other API calling components that may be written in a different language (or the same language) as API calling component 2330 may use API 2320.

[0131] The API implementation component 2310, API 2320, and API calling component 2330 may be stored in a machine-readable medium that includes any mechanism for storing information in a machine-readable format (e.g., a computer or other data processing system). Examples of machine-readable media include magnetic disks, optical disks, random-access memory, read-only memory, and flash memory devices.

[0132] Figure 14 is a block diagram of a device architecture 2400 for a mobile device 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 peripheral device interface 2406. Various components can be connected by one or more communication buses or signal lines. Various components may be separate logic components or devices, or they may be integrated into one or more integrated circuits, such as a system on a chip integrated circuit.

[0133] The memory interface 2402 may be coupled to a 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 flash memory (e.g., NAND flash, NOR flash, etc.).

[0134] Sensors, devices, and subsystems may be coupled to the peripheral interface 2406 to facilitate multiple functions. For example, motion sensors 2410, light sensors 2412, and proximity sensors 2414 may be coupled to the peripheral interface 2406 to enable mobile device functions. One or more biosensors 2415 may also be present, such as a fingerprint scanner for fingerprint recognition or an image sensor for facial recognition. 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 peripheral interface 2406 to facilitate related functions. A camera subsystem 2420 and optical sensors 2422, such as a charge-coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) optical sensor, may be used to facilitate camera functions such as recording photographs and video clips.

[0135] 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) on which the mobile device is intended to operate. For example, a mobile device including the illustrated device architecture 2400 may include wireless communication subsystems 2424 designed to operate on a GSM network, a CDMA network, an LTE network, a Wi-Fi network, a Bluetooth network, or any other wireless network. In particular, the wireless communication subsystem 2424 can provide a communication mechanism that allows a media playback application to retrieve resources from a remote media server or scheduled events from a remote calendar or event server.

[0136] The audio subsystem 2426 can be coupled to the speaker 2428 and microphone 2430 to facilitate voice-enabled functions such as speech recognition, voice duplication, digital recording, and telephone functions. In the smart media devices described herein, the audio subsystem 2426 can be a high-quality audio system, including support for virtual surround sound.

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

[0138] 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 may include logic to interpret the sensor data and determine the occurrence of one or more motion events or activities by analyzing the sensor data from the sensors.

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

[0140] 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 may include instructions for handling basic system services and performing hardware-dependent tasks. In some implementations, operating system 2452 may be a kernel.

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

[0142] Furthermore, memory 2450 can store sensor processing instructions 2458 to facilitate sensor-related processing and functions, telephone instructions 2460 to facilitate telephone-related processing and functions, messaging instructions 2462 to facilitate electronic messaging-related processing and functions, web browser instructions 2464 to facilitate web browsing-related processing and functions, media processing instructions 2466 to facilitate media processing-related processing and functions, location service instructions including GPS and / or navigation instructions 2468 and Wi-Fi-based location instructions to facilitate location-based functions, camera instructions 2470 to facilitate camera-related processing and functions, and / or other processing and functions, such as security processing and functions, and other software instructions 2472 to facilitate system-related processing and functions. Memory 2450 can also store other software instructions such as web video instructions to facilitate web video-related processes and functions, and / or web shopping instructions to facilitate web shopping-related processes and functions. In some implementations, media processing instructions 2466 are divided into audio processing instructions and video processing instructions to facilitate audio processing-related processes and functions, and video processing-related processes and functions, respectively. Mobile device identifiers, such as the International Mobile Equipment Identity (IMEI) 2474 or similar hardware identifiers, can also be stored in memory 2450.

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

[0144] Figure 15 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 provide computing devices and / or server devices to which computing devices can connect.

[0145] The computing system 2500 includes a bus 2535 or other communication device for communicating information, and one or more processors 2510 coupled to the bus 2535, capable of processing information. Although the computing system 2500 is shown as having a single processor, the computing system 2500 may include multiple processors and / or coprocessors. The computing system 2500 may further include memory 2520 in the form of random access memory (RAM) or other dynamic storage device coupled to the bus 2535. Memory 2520 can store information and instructions that can be executed by the processor(s) 2510. Memory 2520 may also be main memory used to store temporary variables or other intermediate information during the execution of instructions by the processor(s) 2510.

[0146] The computing system 2500 may also include a read-only memory (ROM) 2530 and / or other data storage device 2540 coupled to the bus 2535, which may store information and instructions for one or more processors 2510. The data storage device 2540 may be or include various storage devices such as flash memory devices, magnetic disks, or optical disks, and may be coupled to the computing system 2500 via the bus 2535 or via a remote peripheral interface.

[0147] The computing system 2500 may also be coupled to a display device 2550 via bus 2535 to display information to the user. The computing system 2500 may also include an alphanumeric input device 2560, which includes alphanumeric and other keys, and the alphanumeric input device may be coupled to bus 2535 to communicate information and command selections to processor(s) 2510. Another type of user input device may include a cursor control device 2570, such as a touchpad, mouse, trackball, or cursor directional keys, which communicates directional information and command selections to processor(s) 2510 and controls cursor movement on display device 2550. The computing system 2500 may also receive user input from remote devices that are communicably coupled via one or more network interfaces 2580.

[0148] The computing system 2500 may further include one or more network interfaces 2580 for providing access to a network such as a local area network. The network interfaces 2580 may include, for example, a wireless network interface having antennas 2585 which may represent one or more antennas. The computing system 2500 may include multiple wireless network interfaces, such as Wi-Fi, Bluetooth®, Near Field Communication (NFC), and / or a combination of cellular interfaces. The network interfaces 2580 may also include a wired network interface for communicating with a remote device via a 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.

[0149] 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, communication via the wireless LAN standard, the network interface(s) 2580 may provide wireless communication using, for example, the Time Division Multiple Access (TDMA) protocol, the Global System for Mobile Communications (GSM) protocol, the Code Division Multiple Access (CDMA) protocol, the Long-Term Evolution (LTE) protocol, and / or any other type of wireless communication protocol.

[0150] 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 supply, one or more batteries, one or more charge storage devices, a USB charger, or other energy sources. The energy measurement system includes at least one voltage or amperage measuring device capable of measuring the energy consumed by the computing system 2500 over a given period of time. Furthermore, it may include one or more energy measurement systems that measure the energy consumed by, for example, a display device, a cooling subsystem, a Wi-Fi subsystem, or other frequently used or high-energy-consuming subsystems.

[0151] Figure 16 is a flowchart illustrating a method for use in a device locator system according to one embodiment. Shared device 504 may directly receive the shared resource locator from owner device 502 (or another shared device) using any number of communication methods, third-party servers (such as via third-party applications), and / or delegate server 534. For example, owner device 502 or shared device 504 may transmit the shared resource locator via electronic messages, text messages, QR codes, third-party applications, file synchronization services, word processing applications, note-taking applications, file transfer services, cloud-based storage, and / or any other form of communication.

[0152] In flow diagram 1600, the device locator server 520 receives a resource locator sharing request from the shared device 504 to access the locator service accessible on the device locator server 520 for the accessory device 530, which is shared by the owner device 502. The owner device 502 can enable sharing, and receiving a resource locator sharing request to access the share using the shared resource locator can initiate delegation. Continuing in flow diagram 1602, the device locator server 520 may receive a resource locator sharing request to access the location service of the accessory device 530 (1602). The shared device 504 may access the share by sending a request to the device locator server 520 via an application that has the shared resource locator, such as choosing to access the shared device locator by submitting a request using a web browser. In one embodiment, the shared / delegate device 504, which is a sub-delegate of a delegate entity, may access the share using the shared resource locator with a third-party application via a third-party server.

[0153] A shared resource locator includes a unique identifier corresponding to an identifier for a share that can be looked up by a 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 a delegate device 504 for a sub-delegate of a delegate entity and / or a shared device 504 for a user not subscribed to the delegate entity. The shared resource locator can be shared with 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 shared identifier corresponds to a shared key and a delegate key stored in the delegate server 534.

[0154] As shown herein, a user of owner device 502 may delegate all or a subset of device locator server 520 services to a delegate entity via the delegation UI 503 and via the transfer of delegate keys 505 to a shared record established on the delegate server 534 of the delegate entity. A user of owner device 502 can enable or disable sharing at any time. Delegation can be performed by owner device 502 by generating keys for one or more privacy windows expected during its duration and providing those keys to the delegate server 534 via the transfer of delegate keys 505. A privacy window is a predetermined period, such as M minutes, during which the 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 duration of the move is expected to be 1 hour and the privacy window is 15 minutes, the set of generated keys for the privacy windows (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 the shared database, and the delegate server 534 can encrypt and decrypt data exchanged with the device locator server 520 in response to a request from the shared device 504.

[0155] 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 shared device 504 to encrypt / decrypt data received in response to requests to the device locator service and / or the owner device 502. In some embodiments, the delegate device 504 associated with the 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 to 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 on the third-party server. The delegate entity may determine whether the delegate shared secret and / or encryption key is shared directly with the delegate entity's sub-delegate devices or used to decrypt location information within a third-party application.

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

[0157] "shareurl.com?parameter=1#cryptographickey",

[0158] Here, "shareurl.com" is the resource address / identifier, "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 shared device 504.

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

[0160] If the user of shared device 504 is authenticated, it is determined whether the rate limit threshold for the number of shared devices (one or more) or shared requests (one or more) has been exceeded. The defined threshold numbers for rate limiting threshold checks and user checks can 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 identifier of the delegate user and / or the shared device 504 to obfuscate the identifier but to allow recording of sharing requests by the user. The identifier of the delegate user or the shared device 504 may be an account identifier, a device identifier, and / or a phone number, etc., for which a hash result is generated using a hash function. A comparison is performed between the hash result and existing hash results associated with the shared resource locator stored in a database. The database is an organized collection of data. The hash result of the identifier associated with the shared device 504 is compared with a set of hash results stored in the database associated with the shared resource locator. If the comparison matches an existing hash result of 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. Figure 17 shows a user interface having an element 2604 that provides a summary of the number of unique users (based on identifiers) for the share. The number of shared access requests may be recorded, at the user's discretion. Alternatively, if the comparison does not yield a match, the hash result is a unique hash result for the share, indicating that it is a new user for the share, and the visitor count value is incremented. Unique hash results for identifiers may also be stored in relation to the shared locator resource in the database records, and the number of unique hash results for a 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 is equal to the defined threshold number of rate limiting thresholds and / or allowed shared requests, the received shared request may be rejected. If the number of unique hash results does not exceed the defined threshold number of rate limiting thresholds and / or allowed shared requests, the unique hash results are added to the hash result database record associated with the shared resource locator.

[0161] Continuing the flow diagram, if the number of unique hash results received for a resource locator request does not exceed a rate limit threshold or a defined threshold, the metadata is evaluated to determine whether the conditions for sharing with an authenticated user of the shared device 504 are met (1606). The metadata defines a set of conditions for sharing a set of location service capabilities. In one embodiment, metadata on the owner device 502, which is associated with a delegate entity and / or selected by the user on the owner device 502 to associate with sharing, may define a set of conditions. The metadata may define time limits for sharing, access policies for shared users participating in the sharing of accessory device 530, and / or any other conditions for sharing. An access policy for each shared user participating in the sharing of the location services of accessory device 530 is established when the shared user accepts a request to participate in the sharing. The access policy may define when, where, and to whom the shared user is allowed to notify individual shared device locations. An authenticated user of the associated shared device 504 may access the locator service 522 upon request after the set of conditions is met. A set of conditions may be established by the device owner and / or delegate entity. The set of conditions may relate to the status of the owner device 502, the status of the wireless accessory 530, the shared device 504, and / or the authenticated user of the shared device 504. The set of conditions may also be time-based conditions, geographical-based conditions, conditions based on the status of the wireless accessory 530, and / or the location of the owner device 502 or the shared user of the owner device (e.g., 504).

[0162] In some embodiments, metadata can identify expected delegate roles, sharing duration, sharing expiration time, location information access policies, and / or any other conditions of sharing. For example, an access policy established between the shared and / or owner participating in the sharing may indicate timeframes in which access is permitted or denied and / or accessory device status information. Continuing this example, the access policy may indicate that accessory device statuses "near owner device" and / or "near shared device" are not permitted. In one embodiment, a wireless accessory 530 is defined as being near a particular device if that device is wirelessly or physically connected to the wireless accessory 530. In another embodiment, a wireless accessory 530 is defined as being near a particular device (owner device or shared device) if that device is within range of receiving a beacon signal from the wireless accessory 530. For example, if owner device 534 is wirelessly or physically connected to wireless accessory 530, then owner device 534 is near the wireless accessory. In another example, a delegate of a delegate entity may transmit information about the location of an accessory device and designate the accessory device as being close to the owner device. For example, a delegate or sub-delegate of a delegate entity can hand over the accessory device 530 to the owner, specify the accessory device in the same way as the owner device, and specify the accessory device 530 as being close to the owner.

[0163] If it is determined that the set of conditions defined in the shared metadata are met, a response to the location service access request is sent to the shared device 504 (1608). 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 retrieve the shared identifier to locate the shared key and / or the corresponding delegate key in the delegate server. A second shared identifier may exist with some degree of indirectness to ensure that the identifier in the resource locator is not the second identifier used to read the share. The device locator server 530 satisfies the request using the delegate key from the delegate server for the share and sends the encrypted location information to the shared device 504 directly 524, from the third-party server via a third-party application, and / or from the delegate server 534. The shared device 504 decrypts the location information using the delegate shared secret in the browser or an encryption key generated by the third-party application.

[0164] Figure 17 shows one embodiment of a delegation user interface on an electronic device 2600 that enables owner device 502 (or shared device) and / or shared device 504 to share location updates. Figures 17 and 18 are variations of the delegation user interface 503 described herein. A shared resource locator 2602 for sharing is displayed within a sharing summary user interface titled “Sharing Location Updates”. In some embodiments, the delegation user interface may be implemented as a web application that runs in a browser. Embodiments may be implemented using an application server such as a delegate entity (e.g., a third-party server) web application server. Information about the sharing for the corresponding shared resource locator 2602, such as “http: / / shareurl.com?param=1#key”, may be summarized within the user interface, along with the number of visitors to the sharing, such as “Number of Visitors=3”, and the expiration date, such as “2 / 14 / 2024” 2604. The user interface element "Share Link" 2606 allows users to share links using various communication methods, as shown in the exemplary embodiment in Figure 18. In one embodiment, the user enables sharing by sending a shared resource locator 2602. In another embodiment, the user can indicate in a setting whether to enable or disable sharing corresponding to the shared resource locator 2602. Alternatively, the user can disable sharing using the user interface element "Stop Sharing" 2608. The user interface element 2610 allows the user to exit the web application, as indicated by "Done".

[0165] Figure 18 shows one embodiment of a delegate user interface on an electronic device 2601 that enables an owner device 502 (or delegate device) and / or a shared 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, file transfer services, cloud services, note-taking applications (as shown in 2612), word processing applications, text editors, saving to a file (as shown in 2614), and / or synchronization. The 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 allows the user to exit the web application, as indicated by “Finish”.

[0166] Figures 19A and 19B show exemplary embodiments of a delegated user interface on the electronic device 2702. An authenticated shared device 504 can access the device locator service using a shared resource locator, as shown in Figures 19A and 19B. Figures 19A and 19B are variations of the delegated UI 506 described herein. An error is displayed if the conditions for sharing the resource locator service are not met, such as when the accessory device 530 is within the beacon signal range of the owner device 502 or another shared device 504. As shown in Figure 19A, the device locator UI 2701 of the shared device 504 can present a graphical user interface on the electronic device 2702 having an accessory device location 2704 for an accessory device associated with item 2708 "house key", where the location information is presented as indicated by the item "house key" located in 2706 on the map. The owner and the shared user have an access policy that allows the shared user to have location information of an item associated with the accessory device 530 when the item has a device status that it is not located near the owner as shown in the figure. The shared user device 530 has device locator capabilities to “play sound” 2710 and “notify” 2712 (provided in more detail in 2716 in Figure 19B). As shown in Figure 19B, the device locator UI 2701 of the shared user device 504 can present a graphical user interface on the electronic device 2702 having the accessory device location 2704, and a delegate designated as “I” 2718 has device locator capabilities to “share item” by selecting affordances for “play sound” 2710, “notify” 2712 (e.g., “notify when found,” “notify when left behind,” “notify when moved”), and “add person.” As shown in Figure 19B, the shared user "I" 2718 is viewing shared information about the "house key," which is also shared with the delegate "Sara Parker."

[0167] While the embodiments have been described in specific language for structural features and / or methodological work, it should be understood that the attached claims are not necessarily limited to the specific features or work described above. The specific features and actions disclosed should rather be understood as explanatory embodiments of the claims.

Claims

1. It is a method, The delegate server receives authentication credentials from the first shared electronic device, Determining at least one cryptographic key and metadata accessible to a first shared user corresponding to the received authentication credentials, wherein the metadata defines a set of conditions for sharing location information of an accessory device, To determine whether the set of conditions is met, the metadata is evaluated, When it is determined that the set of the above conditions is met, the metadata and the at least one encryption key are transmitted to the first shared electronic device. The second shared electronic device receives an indication that it is participating in the sharing of the location information of the accessory device, Updating at least one of the encryption keys and transmitting the metadata, Methods that include...

2. The method according to claim 1, wherein the metadata includes an access policy for the first shared party to access the location information of the accessory device.

3. The method according to claim 2, wherein the access policy is established upon consent of the first and second shared parties to the sharing and includes conditions of the first shared party regarding access to obtain location information provided to the device location service by the second shared party.

4. The method according to claim 1, wherein the metadata includes the account identifier of the first shared party and the duration for the sharing.

5. It is a method, In the device location server, the location service request from the shared electronic device to the accessory device is received, Decrypting an encrypted blob using at least one encryption key included in the location service request, wherein the encrypted blob was received from the owner device for the requested sharing of the accessory device's location information, and decrypting the blob. The encrypted location information for the accessory device is retrieved from the location information database using at least one hashed public key obtained from the decrypted encrypted blob, In response to the location service request, the retrieved encrypted location information and the encrypted encryption key for the encrypted location information are transmitted to the shared electronic device. Methods that include...

6. An access policy for the shareholder corresponding to the metadata included in the location service request, wherein the access policy defines a set of conditions for sharing the location information of the accessory device, and the verification of the access policy. To determine whether the set of conditions is met for the shared owner, the metadata is evaluated. In determining that the set of the above conditions is met, the encrypted blob is decrypted using the at least one encryption key included in the location service request, The method according to claim 5, further comprising:

7. Decrypting the encrypted blob using at least one encryption key included in the location service request, Transmitting an encryption key for at least one device location service capability for the accessory device, The method according to claim 5, further comprising:

8. The method according to claim 5, wherein the at least one hashed public key corresponds to a public key generated by a shared secret on both the owner device and the wireless accessory.

9. The method according to claim 5, wherein the location information includes location information provided to the device location server by a second shared device that has detected a beacon from the wireless accessory.

10. It is a method, Receiving acceptance of a request to share access to the location information of a paired accessory device, During the duration of the sharing, generate a set of hashed public keys corresponding to a set of public keys that are expected to be used by the device location service server to encrypt the location information received by the accessory device, The hashed set of public keys is encrypted and sent to the device location service server, Sending to the delegate server the hashed set of public keys and an encryption key for decrypting the metadata, wherein the metadata includes an identifier for a first shareee and a set of conditions for the sharing. Methods that include...

11. Establishing a shared secret with the aforementioned paired accessory device, To generate a public key in the set of public keys based on the shared secret and the timestamp expected during the duration of the sharing, The method according to claim 10, further comprising:

12. The method according to claim 10, wherein the metadata includes an access policy for accessing location information.

13. Sending an encrypted blob to the device location service server, wherein the encrypted blob includes an encrypted encryption key that allows the first shared party to access the location service of the accessory device, Sending the decryption key for the encrypted blob to the delegate server, The method according to claim 10, further comprising:

14. Receiving an acknowledgment from the first shared device to a request to include the second shared device in the sharing of the accessory device, Transmitting the updated encryption key and metadata of each shareholder in the aforementioned sharing, The method according to claim 10, further comprising:

15. It is a method, Sending an acknowledgment to a request to share access to the location information of an accessory device in accordance with the access policy, wherein the accessory device is paired with the owner device, and the acknowledgment is sent. Receiving metadata and at least one encryption key from the delegate server, wherein the metadata includes the access policy, Sending a request to a device location server to perform a lookup of the location information of the accessory device using the at least one encryption key, wherein the request includes the metadata, In accordance with the access policy, the device receives the encrypted location information of the accessory device and the encrypted encryption key of the encrypted location information. Methods that include...

16. The method of claim 15, wherein the access policy is established when the second shared party consents to the sharing and includes conditions relating to access for obtaining location information provided to the device location service by the second shared party.

17. A non-temporary machine-readable medium for storing instructions for causing one or more processors of an electronic device to perform an operation, wherein the operation is: The delegate server receives authentication credentials from the first shared electronic device, Determining at least one cryptographic key and metadata accessible to a first shared user corresponding to the received authentication credentials, wherein the metadata defines a set of conditions for sharing location information of an accessory device, To determine whether the set of conditions is met, the metadata is evaluated, When it is determined that the set of the above conditions is met, the metadata and the at least one encryption key are transmitted to the first shared electronic device. The second shared electronic device receives an indication that it is participating in the sharing of the location information of the accessory device, Updating at least one of the encryption keys and transmitting the metadata, Non-temporary machine-readable media, including [specific examples of such media].

18. The non-temporary machine-readable medium according to claim 17, wherein the metadata includes an access policy for the first shared party to access the location information of the accessory device.

19. The non-temporary machine-readable medium according to claim 17, wherein the access policy is established upon consent to the sharing by the first and second shared parties and includes the first shared party's conditions regarding access to obtain location information provided to the device location service by the second shared party.

20. A data processing system, Memory for storing instructions for execution, The system comprises one or more processors that execute the instruction stored in memory, and when the instruction is executed, the one or more processors The delegate server receives authentication credentials from the first shared electronic device, Determining at least one cryptographic key and metadata accessible to a first shared user corresponding to the received authentication credentials, wherein the metadata defines a set of conditions for sharing location information of an accessory device, To determine whether the set of conditions is met, the metadata is evaluated, When it is determined that the set of the above conditions is met, the metadata and the at least one encryption key are transmitted to the first shared electronic device. The second shared electronic device receives an indication that it is participating in the sharing of the location information of the accessory device, Updating at least one of the encryption keys and transmitting the metadata, A data processing system that performs this task.

Images