Sharing keys for wireless accessories

Abstract

Sharing keys for wireless attachments is disclosed. Embodiments described herein provide a non-transitory machine-readable medium storing instructions for causing one or more processors to perform operations to share a set of keys for communicating with a wireless accessory device. By sharing the set of keys, the functionality of the wireless accessory device may be delegated by the owner to other individuals.

Description

[0001] This application is a divisional application based on the Chinese invention patent application with application date of April 15, 2020, application number 202080028950.9, and invention name “Sharing Keys for Wireless Accessories”.

[0002] Cross-references

[0003] This patent application claims priority to U.S. Provisional Patent Application Serial No. 62 / 835,494, filed April 17, 2019, and U.S. Provisional Patent Application Serial No. 62 / 856,020, filed June 1, 2019, each of which is hereby incorporated by reference herein. Technical Field

[0004] The embodiments described herein generally relate to systems and methods for locating wireless devices and accessories. More particularly, the embodiments relate to an infrastructure that enables sharing of keys to access or control wireless accessories. Background Art

[0005] Current security features in handheld and portable products allow the location of the product to be identified upon user request, such as in the event that the product is lost or stolen. If the wireless device includes positioning technology, the device can be configured to report its last location to a server computer, which is displayed on a map presented to the user by the service. Often, wireless devices are used with wireless accessory devices whose location cannot be determined and cannot communicate with the remote tracking service over a wide area network. These accessory devices may include, for example, wireless earbuds, headphones, headsets, and other wearable devices that communicate directly with the wireless device using peer-to-peer communication (e.g., smart watches, fitness bands, optical head-mounted displays). When wireless accessory devices whose location cannot be determined and cannot communicate with the remote tracking service are lost or stolen, those devices cannot be tracked by the service. Summary of the Invention

[0006] The embodiments described herein provide a non-transitory machine-readable medium storing instructions that cause one or more processors to perform operations comprising determining a sharing recipient and a set of capabilities delegated to the sharing recipient for a wireless accessory; creating a storage record comprising fields for storing an identifier of the sharing recipient, an identifier of the wireless accessory, and a set of capabilities to be shared with the sharing recipient; sending a sharing request to a sharing recipient device; marking the cloud storage record as accepted in response to receiving an acceptance message from the sharing recipient device; and sending a set of cryptographic keys to the sharing recipient device to enable the sharing recipient device to execute the set of capabilities on the wireless accessory.

[0007] One embodiment provides a data processing system on an electronic device, the data processing system comprising a memory for storing instructions and one or more processors for executing the instructions. The instructions cause the one or more processors to: determine a sharing recipient and a set of capabilities delegated to the sharing recipient for a wireless accessory; create a storage record comprising fields for storing an identifier of the sharing recipient, an identifier of the wireless accessory, and a set of capabilities to be shared with the sharing recipient; and send a sharing request to a sharing recipient device associated with the sharing recipient. In response to receiving an acceptance message from the sharing recipient device, the one or more processors may mark the storage record as accepted, send a set of cryptographic keys to the sharing recipient device to enable the sharing recipient device to execute the set of capabilities on the wireless accessory.

[0008] One embodiment provides an electronic device comprising a wireless processor coupled to a radio component, a memory for storing instructions, and one or more processors for executing the instructions. The instructions cause the one or more processors to: determine a sharing recipient and a set of capabilities delegated to the sharing recipient for a wireless accessory; create a storage record comprising fields for storing an identifier of the sharing recipient, an identifier of the wireless accessory, and a set of capabilities to be shared with the sharing recipient; and send a sharing request to a sharing recipient device associated with the sharing recipient via the wireless processor. In response to receiving an acceptance message from the sharing recipient device, the one or more processors may mark the storage record as accepted and send a set of cryptographic keys to the sharing recipient device to enable the sharing recipient device to execute the set of capabilities on the wireless accessory.

[0009] One embodiment provides a method that includes receiving, on an electronic device associated with a sharing recipient, a request to accept sharing of capabilities associated with a wireless accessory, the request including a storage record, wherein the storage record includes fields for storing an identifier of the sharing recipient, an identifier of the wireless accessory, and a set of capabilities to be shared with the sharing recipient. The method also includes presenting an interface on a display of the electronic device to accept or deny the request, sending a message indicating acceptance of the request in response to receiving input via the interface, updating the storage record to indicate acceptance of the request, and receiving a set of cryptographic keys to enable the electronic device to perform operations associated with the wireless accessory.

[0010] The above summary does not include an exhaustive list of all embodiments of the present disclosure. All systems and methods can be practiced according to all suitable combinations of the various aspects and embodiments summarized above and those disclosed in the following detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings in which like references indicate similar elements, and in which:

[0012] Figure 1 is a block diagram of a network operating environment for a mobile device according to an embodiment;

[0013] Figure 2 A system for locating a wireless accessory that is unable to access a wide area network is shown according to an embodiment;

[0014] Figure 3 A system for pairing and locating a wireless accessory according to embodiments described herein is shown;

[0015] Figures 4A to 4C is a flow chart illustrating a method for use with the device locator system described herein;

[0016] Figure 5 is a flow chart illustrating a method of broadcasting a signal beacon at a wireless accessory according to an embodiment;

[0017] Figures 6A to 6B illustrates operations of a method that may be performed by a detector device according to embodiments described herein;

[0018] Figure 7 shows the acquisition of signal and ranging data performed by a detector device according to an embodiment;

[0019] Figure 8 A networked system for locating a device and a wireless accessory according to an embodiment is shown;

[0020] Figures 9A to 9C shows a device locator user interface according to an embodiment;

[0021] Figure 10 showing an accessory pairing user interface displayed when attempting to pair with a lost wireless accessory according to an embodiment;

[0022] Figure 11 is a block diagram illustrating an exemplary API architecture that may be used in some embodiments of the present invention;

[0023] Figure 12 is a block diagram of a device architecture for a mobile or embedded device according to an embodiment;

[0024] Figure 13 is a block diagram of a computing system according to an embodiment;

[0025] Figure 14 A system for collaboratively performing key generation between an owner device and a wireless accessory according to an embodiment is shown;

[0026] Figure 15 shows a key hierarchy for collaborative key generation according to an embodiment;

[0027] Figure 16 shows a process of collaborative key generation according to an embodiment;

[0028] Figure 17 is a flow chart of a process for entering a near-owner state at a secondary device according to an embodiment;

[0029] Figure 18 is a flow chart of a process of connecting to a secondary device and commanding the secondary device according to an embodiment;

[0030] Figure 19 A system is shown in which access to a wireless accessory can be delegated to a user for a period of time;

[0031] Figure 20 is a flow chart of a process for delegating functions to a trustee device according to an embodiment;

[0032] Figures 21A to 21B A method for recovering an out-of-sync secondary device according to an embodiment is shown;

[0033] Figure 22 A computing system including a security processor according to an embodiment is shown;

[0034] Figure 23 A system for enabling sharing of trustee keys via a cloud storage system is shown;

[0035] Figure 24 is a diagram illustrating a system for securely storing data items, according to an embodiment;

[0036] FIG. 25A to FIG. 25B A storage container and records of a data repository that can be used to enable key sharing for a wireless accessory are shown;

[0037] Figures 26A to 26C is a sequence diagram of operations for configuring key sharing for a wireless accessory;

[0038] FIG. 27A to FIG. 27B showing a user interface for establishing a key sharing arrangement between user accounts with respect to a wireless accessory; and

[0039] Figures 28A to 28C A method of enabling key sharing for a wireless accessory device according to an embodiment is shown. DETAILED DESCRIPTION

[0040] The embodiments described herein provide techniques for enabling a secure crowdsourced locator service for lost or misplaced devices that are unable to communicate with a wide area network. Various embodiments and aspects will be described with reference to the details discussed below, and the accompanying drawings will illustrate the various embodiments. The following description and drawings are illustrative and should not be construed as limiting. Numerous specific details are described to provide a thorough understanding of the various embodiments. However, in some instances, well-known or conventional details are not described in order to provide a concise discussion of the embodiments.

[0041] The terms used in this specification are only for describing specific embodiments and are not intended to limit the present invention. As used in the present specification and the appended claims, the singular forms "a", "an" and "the" are intended to also cover the plural forms, unless the context clearly indicates otherwise. It will also be understood that the terms "and / or" used herein refer to and cover any and all possible combinations of one or more items in the items listed in association. It will also be understood that the terms "comprises" and / or "comprising" when used in this specification specify the presence of stated features, integers, steps, operations, elements and / or parts, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, parts, and / or their groupings.

[0042] In the following discussion, a computing device including a touch-sensitive display is described. However, it should be understood that the computing device may include one or more other physical user interface devices. Various applications that can be executed on the device can 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 can be adjusted and / or varied from one application to the next and / or can be adjusted and / or varied within a corresponding application. In this way, the common physical architecture of the device (such as the touch-sensitive surface) can support a variety of applications with an intuitive and transparent user interface.

[0043] Below with respect to some sequential operations, some processes are described. However, it should be understood that some operations in the described operations can be performed in different orders. In addition, some operations also can be performed in parallel rather than in order.

[0044] Figure 11 is a block diagram of a network operating environment 100 for mobile devices according to an embodiment; network operating environment 100 includes multiple mobile devices, such as mobile device 102A and mobile device 102B. Mobile devices 102A-102B can each be any electronic device capable of communicating with a wireless network and one or more wireless accessory devices. Some exemplary mobile devices include, but are not limited to, smartphones, tablets, laptops, wearable computers (e.g., smart watches or other wearable computing accessories), mobile media players, personal digital assistants, and other similar devices. Each of mobile devices 102A and 102B includes a user interface, such as user interface 104 of mobile device 102B. Mobile devices 102A and 102B can communicate via one or more wired and / or wireless networks 110 to perform data communications. For example, wireless network 112 (e.g., a cellular network, a Wi-Fi network) can communicate with a wide area network 114 (such as the Internet) using a gateway 116. Similarly, an access device 118, such as a mobile hotspot wireless access device, can provide communication access to wide area network 114. The gateway 116 and access device 118 may then communicate with the wide area network 114 via a combination of wired and / or wireless networks.

[0045] In some implementations, both voice and data communications can be established via the wireless network 112 and / or the access device 118. For example, the mobile device 102A can make and receive phone calls (e.g., using the VoIP 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, via the wireless network 112, the gateway 116, and the wide area network 114 (e.g., using TCP / IP or UDP). In some implementations, the mobile device 102A 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, the mobile device 102A or the mobile device 102B can be physically connected to the access device 118 using one or more cables, for example, where the access device 118 is a personal computer. In this configuration, the mobile device 102A or the mobile device 102B can be referred to as a "tethered" device. In one embodiment, the mobile device 102A can communicate with the mobile device 102B via the wireless peer-to-peer connection 120. The wireless peer-to-peer connection 120 may be used to synchronize data between devices.

[0046] Mobile device 102A or mobile device 102B can communicate with a service provider 115 that provides or enables one or more services. Exemplary services include telephony services 130, instant messaging services 140, media services 150, storage services 160, and device locator services 170 over one or more wired and / or wireless networks 110. For example, telephony services 130 can enable telephony communications between mobile devices 102A and 102B, or between a mobile device and a wired telephone device. Telephony services 130 can route Voice over IP (VoIP) calls over wide area network 114 or can access a cellular voice network (e.g., wireless network 112). Instant messaging services 140 can, for example, provide email and / or other instant messaging services. Media services 150 can, for example, provide access to media files, such as song files, audiobooks, movie files, video clips, and other media data. Storage services 160 can provide network storage capabilities to mobile devices 102A and 102B for storing documents and media files. The device locator service 170 enables a user to locate a lost or misplaced device that was, at least at a certain point in time, connected to one or more wired and / or wireless networks 110. For example, mobile device 102A may perform a location query for mobile device 102B. The device locator service 170 may also enable location queries for devices that do not have network connectivity via the network using a probe device, as follows: Figures 2 to 3 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 message delivery service 140, the media service 150, the storage service 160, and the device locator service 170 may each be associated with a cloud service provider, where the various services are facilitated via cloud service accounts associated with the mobile devices 102A-102B.

[0047] Figure 2A system 200 for locating a wireless accessory 201 that does not have access to a wide area network is shown according to an embodiment. The system 200 can also be used to locate devices that do not have access to a WAN or LAN and therefore cannot transmit the location of the device. In one embodiment, the wireless accessory 201 includes one or more wireless transceivers and can communicate with a companion device (e.g., mobile device 102) directly or indirectly (e.g., through another device or computer) via a wireless network or a peer-to-peer communication link. Some examples of wireless accessory devices include, but are not limited to, wireless earbuds, headphones, headsets, and other wearable devices (e.g., smart watches, fitness bands, optical head-mounted displays). The wireless accessory 201 can also include other wireless devices, such as game controllers or remote controls. In one embodiment, the wireless accessory 201 also includes a smart phone, tablet, laptop computer, smart speaker device, television, or other device that does not have access to a wide area network such as the Internet (e.g., such as a smartwatch). Figure 1 The wireless accessory 201 may also be any other wireless device, including a beacon or locator tag that can be attached to other devices or items to enable tracking or locating of those devices or items. In one embodiment, the wireless accessory 201 may be 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 via wireless technologies such as Wi-Fi Direct, Zigbee, or similar technologies. Although the companion device with which the wireless accessory 201 is paired is generally referred to as the mobile device 102, 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 may additionally include some wearable accessories, such as, but not limited to, a smartwatch device or a wearable display.

[0048] In one embodiment, wireless accessory 201 can periodically transmit a wireless beacon signal. Wireless accessory 201 can transmit the beacon signal using one of the various wireless technologies described herein (e.g., Bluetooth, Wi-Fi, etc.), and in one embodiment, can also beacon using ultra-wideband (UWB) radio technology. The beacon signal can be transmitted using a single wireless technology, one of multiple selectable wireless technologies, or multiple simultaneous wireless technologies. The beacon signal can transmit a beacon identifier that includes information that uniquely identifies wireless accessory 201. In one embodiment, the beacon identifier is a public encryption key associated with the device.

[0049] The beacon signal may also convey information about the wireless accessory 201, such as the beacon type, device classification, and battery level. In one embodiment, the beacon signal may also convey a device status, such as a lost status, an alarm status, or a near-owner status. The beacon signal may also include information specifying battery life, charging status, and / or other status information. The lost status may indicate that the wireless accessory 201 has determined that it has been lost or has been placed in a lost status by the owner of the device. The alarm status may indicate that the wireless accessory 201 is placed in a state in which the device should trigger an alarm if the device is moved from its current location. The near-owner status may indicate that the wireless accessory 201 has detected the presence of a mobile device 102 associated with the accessory's owner nearby.

[0050] The beacon signal can be detected by a detector device 202 in local proximity to the wireless accessory 201. The detector device 202 can be a device similar to the mobile device 102 and can receive and transmit data over the wide area network 114, utilizing similar wireless technologies as the wireless accessory 201 (e.g., Bluetooth, etc.). Specifically, the detector device 202 can receive data using the wireless protocol over which the beacon signal is transmitted. The detector device 202 can determine its location using one or more location and / or positioning services, including but not limited to satellite positioning services 206 or terrestrial positioning systems that utilize RF signals received from wireless base stations 205 (such as Wi-Fi access points or cell tower transmitters for cellular telephone networks). In one embodiment, the detector device 202 periodically stores its location determined based on the one or more location and / or positioning services. The stored location can be associated with a timestamp for which the location was determined. When the detector device 202 receives a beacon signal from the wireless accessory 201, the detector device 202 can transmit the detector device's location to the device locator server 203 via the wide area network 114. The timestamp used to determine the location of the probe device 202 can be associated with the timestamp of the beacon signal received to associate the geographic location with the received beacon signal. In one embodiment, the wireless accessory 201 includes location determination capabilities via an integrated satellite positioning service (e.g., GPS) receiver. If the wireless accessory does not have access to a network to send a location to the device locator server 203, the wireless accessory can encode encrypted location data within the beacon signal 301. The probe device 202 can then relay the encrypted location data to the device locator server 203.

[0051] If the wireless accessory 201 provides a public key within the beacon signal, the detector 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 along with the location data, or transmitted unencrypted to the device locator server 203. For example, the signal strength indicator (RSSI) of the received beacon signal can be transmitted along with the location data. The RSSI data can then be used to determine the distance between the wireless accessory 201 and the detector 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 if other stronger signals are present. In one embodiment, UWB ranging data can also be provided, where such data is available.

[0052] In one embodiment, the detector device 202 can respond differently upon receiving a beacon signal from the wireless accessory 201, depending on the device state communicated by the wireless accessory 201. For a standard beacon signal, the detector device 202 can queue the encrypted location data and transmit the location data to the device locator server 203 during a periodic transmission window. However, if the wireless accessory 201 is indicating an alarm state, the detector device 202 can immediately transmit the location data to the device locator server 203. Additionally, if the beacon signal of the wireless accessory 201 indicates that the accessory is near the owner of the accessory, the detector device 202 may not transmit the location data to the device locator server 203. Alternatively, the detector device 202 can delay the transmission of the encrypted location data.

[0053] If the owner of wireless accessory 201 wishes to locate the wireless accessory, the owner may access a device locator user interface (e.g., device locator UI 204) on mobile device 102. Device locator UI 204 may be associated with a device locator application that is used to locate electronic devices and accessories registered with a user's online account (such as a cloud service account or another type of online account). The device owner may use device locator UI 204 to query device locator server 203 for location data that may have been transmitted to the device locator server by detector device 202 of wireless accessory 201. In one embodiment, mobile device 102 may transmit a public encryption key associated with wireless accessory 201 to device locator server 203. Device locator server 203 may then return any stored location data corresponding to the public encryption key. The location data returned to mobile device 102 may be encrypted data encrypted by detector device 202 using the public encryption key. Mobile device 102 may decrypt the encrypted location data using an associated private key. Mobile device 102 may then process the decrypted location data to determine the most likely location of wireless accessory 201. In various embodiments, the most likely location of wireless accessory 201 can be determined by triangulating multiple received locations and using other data such as beacon signal RSSI associated with each location and timestamp or UWB ranging data included within the location data.

[0054] Figure 3A system 300 for pairing and locating a wireless accessory according to embodiments described herein is shown. In one embodiment, a mobile device 102 of a user of a wireless accessory 201 can present an accessory pairing UI 302 through which the user can pair the mobile device 102 with the wireless accessory 201. During initial pairing (305) between the mobile device 102 and the wireless accessory, a public key exchange (310) can be performed between the mobile device and the wireless accessory. In one embodiment, during the public key exchange (310), the mobile device 102 and the wireless accessory 201 exchange public keys from a public key pair generated by the device and the accessory. In one embodiment, the public key exchange (310) is a one-way transmission, in which the mobile device 102 transmits the public key from the public / private key pair to the wireless accessory 201. Additionally or alternatively, the public key exchange (310) can be a Diffie-Hellman key exchange, in which the device and the accessory establish a shared secret between the two parties. In one embodiment, the public key exchange (310) additionally uses elliptic curve cryptography to establish the shared secret. For example, Elliptic Curve Diffie-Hellman (ECDH) can be used to implement the establishment of a public key pair and one or more shared secrets. In one embodiment, the one or more shared secrets include an anti-tracking secret, which can be used by wireless accessory 201 to periodically derive additional public keys. In one embodiment, the wireless accessory can advertise a temporary identity and then use identity-based encryption instead of using public key cryptography with a broadcast public key. With identity-based encryption, the public key is some unique element of information about the user's identity, or is derived from some unique element of information about the user's identity, such as an email address. An entity that wants to decrypt the encrypted information can obtain the decryption key from a trusted central authority.

[0055] After the wireless accessory 201 has been paired with the mobile device 102, the wireless accessory 201 can periodically broadcast a beacon signal 301 that includes device status information and a beacon identifier. In one embodiment, the beacon identifier is a public key derived from a shared secret established during the public key exchange (310). In addition, the wireless accessory 201 can periodically perform 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, where a new K-byte key is generated or rotated every M minutes. In different embodiments, the values ​​K and M can vary. In one embodiment, a 28-byte K value is used. In one embodiment, a 27-byte K value is used. The value K can be determined at least in part based on a beacon length associated with the wireless protocol used to transmit the beacon signal 301. In one embodiment, the beacon signal can transmit a variant of a beacon advertising packet associated with a low-power radio protocol (such as Bluetooth Low Energy).

[0056] In one embodiment, the value M is 15 minutes, such that a new K-byte key is generated every 15 minutes. The public key can be deterministically derived based on the timestamp and anti-tracking secret generated during the public key exchange 310. The public key derivation (315) process enables the wireless accessory 201 to use different keys over time, thereby preventing long-term association of a particular key with a particular device. The key can be derived based on the anti-tracking secret that is known only to the mobile device 102 and the wireless accessory 201, thereby allowing the mobile device 102, and only the mobile device, to determine which public key the wireless accessory 201 will broadcast at any given timestamp. The anti-tracking secret can be generated along with the ECDH public key and transmitted to the wireless accessory 201. The anti-tracking secret can then be utilized to enable the wireless accessory 201 to generate a sequence of public keys P i In one embodiment, the public key sequence P i =λ i P, which defines the scalar or exponential value λ i Group operations with group elements, such as elliptic curve points P. Scalar or exponent value λ = KDF(AT, i), where KDF is a key derivation function, AT is an anti-tracking secret, and i is a counter or timestamp.

[0057] In one embodiment, backtracking resistance can be enabled to protect the anti-tracking secret in the event that the wireless accessory 201 is compromised. When backtracking resistance is enabled, the anti-tracking secret is transmitted to the wireless accessory 201, but the wireless accessory does not retain the anti-tracking secret. Instead, the accessory calculates the value λ i+1 =H(λ i || time), where λ0=AT and H is a cryptographic hash function. The wireless accessory 201 then stores λ for a given time period i. i If wireless accessory 201 is compromised, only the current and future values ​​of λ are exposed. i In one embodiment, reverse tracking resistance is achieved by periodically changing λ i This method is performed by writing to the non-volatile memory of the wireless accessory 201. This method is one of several methods that can be used. In various embodiments, other key security techniques can also be used. For example, in one embodiment, the following method can be used with respect to Figures 15 and 16 The key generation and diversification techniques described.

[0058] In one embodiment, the wireless accessory 201 can transmit a beacon signal 301 every two seconds, although other beacon rates can be used, and in some cases, the beacon rate can vary. For example, when in a near-owner state, the wireless accessory 201 can reduce the beacon rate. The beacon rate can also vary based on events triggered by an accelerometer. For example, when in an alarm state, the wireless accessory 201 can increase the beacon rate, which can be triggered by the accelerometer on the wireless accessory 201.

[0059] If, after transmitting beacon signal 301, wireless accessory 201 receives a reply from a mobile device 102 associated with a user of the accessory indicating that mobile device 102 is within range of the wireless accessory, then wireless accessory 201 can enter the near owner state. Additionally, the amount of data transmitted by beacon signal 301 can be reduced while the wireless accessory is in the near owner state. In one embodiment, the advertising rate of wireless accessory 201 can be reduced while the wireless accessory is in the near owner state.

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

[0061] The beacon signal 301 transmitted by the wireless accessory 201 can be detected by a set of detector devices 303, which are other electronic devices that can receive the beacon signal transmitted by the wireless 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 detector devices 303 includes a variation of the mobile device 102, or can be other types of electronic devices. The set of detector devices 303 may include Figure 2 The detector devices 202 of the present invention may be variants of the detector devices 202 and may determine similar location determination techniques. For example, the detector devices may perform operations (320) to associate beacon signals 301 received from the wireless accessory 201 with the device location associated with the detector device. Figure 2As described above, the device location can be determined via a satellite positioning service or a terrestrial positioning system utilizing RF signals received from wireless base stations (e.g., Wi-Fi access points or cell tower transmitters). In one embodiment, the set of detector devices 303 may also include fixed devices, such as smart speaker devices, televisions, or TV set-top boxes that can receive beacon signals 301.

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

[0063] The device locator server 203 can store the encrypted location data in a data repository 304, which in one embodiment can be a distributed database with multiple nodes. A hash of the attached beacon identifier / public key can be sent along with the encrypted location data. The encrypted location data can be stored in the 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. Sending the hash of the beacon identifier instead of the full beacon identifier prevents the full beacon identifier from being stored on the server. Other information can also be sent and stored along with the location data in an encrypted or unencrypted state. Other information can include a timestamp for when the beacon signal 301 was received, RSSI information for the received beacon, and / or ranging information determined, for example, via UWB ranging.

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

[0065] Storing and indexing encrypted location data based on a hash of the public key rather than the public key prevents providers of location service data from storing data that could be used to associate the encrypted location data with a specific device, and therefore with a specific user or user account. The detector device transmits a hash of the public key broadcast within the beacon signal 301 associated with the observed location. The owner of the device can query the device locator server 203 using the hash of the public key determined for the query period.

[0066] In some embodiments, if a location query is to be performed via a web-based interface from an electronic device (such as a laptop or desktop device), a key that enables decryption of the location data may need to be sent to the electronic device. In one embodiment, the decryption key for the location data may be sent to a server providing the web-based interface to enable the server to decrypt the location data, at least when the location data is viewed through the web-based interface. Before the location data is displayed 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 decryption and presentation of the location data. In one embodiment, sharing of the location decryption key may be performed via automatic and temporary authorization of location query permissions for a proxy account associated with the web-based interface.

[0067] In one embodiment, the wireless accessory 201 can be placed in light-lost mode. While in light-lost mode, a set of future public keys can be generated for the wireless accessory and hashes of these public keys can be transmitted to the device locator server 203. The device locator server 203 can then notify the mobile device 102 if any location data corresponding to a key in the set of future public keys is received. In one embodiment, a detector device that transmits the location of a wireless accessory in light-lost mode can be directed by the device locator server 203 to relay a message to the wireless accessory 201 notifying the wireless accessory that it is in light-lost mode. A similar mechanism can also be used to relay a message to the wireless accessory 201 that places the accessory in explicit lost mode. The user can enable explicit lost mode via the device locator UI 204. In explicit lost mode, the wireless accessory 201 cannot pair with another device unless the owner unlocks the wireless accessory.

[0068] Figures 4A to 4C is a flow chart illustrating a method for use with the device locator system described herein. Figure 4A A method 400 for pairing a mobile device with a wireless accessory is shown. Figure 4B A method 410 of determining a location of a wireless accessory via a device locator server is shown. Figure 4C An additional method 420 of determining the location of a wireless accessory via a device locator server is shown. Aspects of methods 400, 410, and 420 are also described in Figure 2 and Figure 3 For example, the following description of operations involves mobile device 102, wireless accessory 201, and device locator server 203.

[0069] like Figure 4A As shown, method 400 includes an operation of performing an initial pairing with a wireless accessory (block 401). The initial pairing can be Bluetooth pairing or another type of pairing performed using other radio technologies. During the initial pairing, the mobile device and the wireless accessory can exchange identifiers, keys, or other credentials that enable wireless data exchange between the mobile device or another electronic device and the wireless accessory. In one embodiment, the initial pairing with the wireless accessory can include the exchange of credentials associated with the wireless protocol for which the pairing is performed, thereby allowing all data exchanged wirelessly to have at least a first layer of encryption.

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

[0071] After generating the public / private key pair and one or more additional shared secrets, the mobile device may store the public / private key pair in a key store (block 404). In one embodiment, the key store is a cloud-based key store that can be synchronized with other devices associated with the same cloud service account or a series of cloud service accounts to which the mobile device and the wireless accessory are associated. The cloud-based key store allows the wireless accessory to be located by other synchronized devices. The mobile device may then register the wireless accessory with a device management server (block 405). Registering the wireless accessory with the device management server may form an association between the wireless accessory and the cloud service account to which the mobile device is associated. The device management server may communicate with other cloud-based servers such as Figure 2 and Figure 3The other cloud-based server is associated with a device locator server 203) for facilitating cloud-based services accessible to mobile devices.

[0072] like Figure 4B As shown, method 410 includes an operation by an electronic device to launch a device locator UI (block 411). In response to launching the device locator UI, the electronic device (which may be a mobile device as described herein) or another electronic device associated with the same cloud service account as the mobile electronic device may perform operations to generate a set of public keys to be included in a beacon signal broadcast by the wireless accessory during a first time period (block 412). The first time period may be, for example, the previous 24 hours. The electronic device knows how often the wireless accessory generates or rotates to new public keys, and using a shared secret generated with the wireless accessory, may generate a set of public keys corresponding to the keys generated by the wireless accessory during the first time period. The electronic device may then send the set of public keys in a request to a device locator server to send location data corresponding to the set of public keys (block 413). In one embodiment, the location data sent by the server in response to the request is encrypted using the public key transmitted as the beacon identifier of the wireless accessory. The electronic device may decrypt the encrypted location data received by the server using the private key generated during initial pairing with the wireless accessory (block 414). The electronic device may then process the location data to determine the highest probability location of the wireless accessory (block 415).

[0073] Processing location data may include a variety of different operations. In one embodiment, the location data includes latitude and longitude information and a timestamp for determining the location. The electronic device may perform triangulation based on the timestamp and remove noise or abnormal locations. In one embodiment, the location data specifies the location of the detector device that detected the beacon. The location data may also include UWB ranging information and / or RSSI information of the beacon detected by the detector device. The electronic device may analyze the UWB ranging information and / or RSSI information in conjunction with the device location to obtain a more accurate location of the wireless accessory. Data that may be transmitted by the detector device and used for location processing is in Figure 10 are shown in and described below.

[0074] like Figure 4CAs shown, method 420 includes operations that can be performed when a device locator server does not have location data to provide to the electronic device in response to a request. The electronic device can generate a first set of public keys to be included in a beacon signal broadcast by the wireless accessory during a first time period (box 421). The first time period can be, for example, 24 hours, but other initial search time periods can be used. The electronic device can perform subsequent operations to request the device locator server to send location data corresponding to the first set of public keys (box 422). If the data is returned by the server (box 423, "yes"), the electronic device can use the private key corresponding to the set of public keys to decrypt the location data received from the server (box 429).

[0075] If the server does not return data (block 423, "No"), the electronic device can generate a second set of public keys to be included in a beacon signal broadcast by the wireless accessory during a second time period (block 424). The second time period can be 24, 48, or another number of hours before the first time period. The electronic device can then request the device locator server to send data corresponding to the second set of public keys (block 425). If the server returns data in response to the request (block 426, "Yes"), the method 420 can proceed to block 429, where the electronic device decrypts the received data. If the server does not return data (block 426, "No"), or the server sends a reply indicating that the data is not available, the method 420 includes: the electronic device can widen the search time by continuously requesting earlier time periods until the maximum time period is reached (block 427).

[0076] Figure 5 is a flow chart illustrating a method 500 of broadcasting a signal beacon at a wireless accessory according to an embodiment. Aspects of the method 500 are also described in Figure 2 and Figure 3 . Method 500 includes the wireless accessory deriving a public key (block 502). The public key can be derived based on a shared secret and a timestamp determined based on a clock or timing device of the wireless accessory. The wireless accessory can then transmit a beacon signal at a first transmission interval, wherein the beacon signal includes the public key (block 503). The first transmission interval can vary, and in one embodiment, a beacon is transmitted every two seconds.

[0077] After transmitting the beacon signal, the wireless accessory can listen for a response from the owner device. If the wireless signal receives a response from the owner device (block 504, "yes"), the wireless accessory can enter a near-owner state (block 505) and begin transmitting beacon signals at a second, slower transmission interval (block 507). If the wireless accessory does not receive a response from the owner device (block 504, "no"), the wireless accessory can continue to send beacons at the first transmission interval (block 506).

[0078] Method 500 also includes rotating the public key of the wireless device every M minutes while sending beacons, where the value of M can vary between implementations and / or based on device state. Based on a timer expiration, a counter, or other mechanism, the wireless accessory can determine whether the accessory has entered a new key period (block 508). Although the wireless accessory has not yet entered a new key period (block 508, "No"), the accessory can continue to send beacons using the current public key (block 510). When the wireless accessory detects that it has entered a new key period (block 508, "Yes"), the accessory can derive a new public key using the current timestamp (block 509). In one embodiment, the new public key can be derived using an existing public key, a timestamp, and an anti-tracking secret.

[0079] Figures 6A to 6B 600 operations that may be performed by a detector device according to embodiments described herein. Aspects of method 600 are also described in Figure 2 and Figure 3 Shown in.

[0080] like Figure 6A As shown, method 600 includes the detector device performing periodic beacon scans using a wireless baseband processor when the application processor of the detector device is in a low-power mode (block 601). Although beacon scans can also be performed when the application processor is active, beacon scans can be performed as a low-power operation by the wireless processor and radio device receiver when the detector device is idle, inactive, or otherwise in a low-power state. The detector device can store a timestamp and a beacon identifier in a beacon scan buffer for any beacon data received by the detector device (block 602). In one embodiment, the beacon identifier is a public key generated by the wireless device based on the timestamp and a shared secret generated using the owner's mobile device.

[0081] Method 600 also includes the probe device performing periodic Wi-Fi scans using the wireless processor while the application processor is in low-power mode (block 603). Although Wi-Fi scans can also be performed when the application processor is active, when the probe device is idle, inactive, or otherwise in a low-power state, the Wi-Fi scans can be performed by the wireless processor and radio receiver as a low-power operation. The probe device can then store a Wi-Fi service set identifier (SSID) and a scan timestamp in a Wi-Fi scan buffer on the probe device (block 604).

[0082] In one embodiment, the Wi-Fi scan buffer is a rolling buffer that stores the most recently detected SSID while overwriting earlier detected SSIDs. In one embodiment, the beacon scan buffer can be a fixed-size buffer with space for a predetermined number of entries. When the beacon scan buffer becomes full, the probe device can wake up the application processor (block 605) and associate those beacon scans with the most recently detected SSIDs in the Wi-Fi scan buffer. This association can enable the probe device to determine a set of device locations corresponding to the received beacons based on the Wi-Fi scan buffer data (block 606).

[0083] Method 600 Figure 6B 6 and includes: if other location data is available, the detector device associates the device location from the Wi-Fi scan buffer data with the other location data (box 607) to generate a refined device location. If a refined device location is generated, the detector device may optionally combine the beacon data with the refined device location (box 608). The detector device may also add a received signal strength indicator (RSSI) or ranging data to the location data (box 609). When the detector device receives a beacon signal, it may collect signal strength and ranging data (e.g., UWB ranging data). The detector device may then encrypt the location data using one or more public keys received within the beacon data (box 610). The signal and ranging data may be encrypted along with the location data, or may be sent unencrypted along with the encrypted location data. The detector device may queue the encrypted location data for transmission to a device locator server (box 611). The device locator server may be one of multiple cloud service servers, typically communicating in a batch and throttled manner. A batch of encrypted data may be collected and placed in a transmission queue until a transmission interval arrives, during which time the probe device may transmit the data to the cloud service server (block 612). The encrypted data may be sent along with a hash value of the beacon identifier corresponding to the encrypted location.

[0084] Figure 7 , according to an embodiment, the collection of signal and ranging data performed by a detector device is shown. In one embodiment, the detector device 202 can collect signal strength information (e.g., RSSI 704A to 704N) for beacon signals 301 received from the wireless accessory 201 across multiple locations 702A to 702N. The detector device 202 can also represent multiple detector devices, such as Figure 33. A device locator server comprises a group of detector devices 303, each of which detects beacon signals at a different location. Each detector device 202 can transmit a different location and signal strength, and the location and signal strength data received from multiple detector devices will be aggregated by the device locator server. In one embodiment, where both the detector device and the wireless device include UWB radios, a UWB ranging measurement 706 can be performed if the detector device and the wireless device are within range of the UWB transmission. The UWB ranging and signal strength data can be transmitted to the device locator server along with the location data of the detector device.

[0085] The owner device can retrieve RSSI or UWB information and location data from the device locator server. In one embodiment, this data is provided in the form of latitude and longitude information, as well as a timestamp of the determined location. The owner device can then use the location data, timestamp, and signal information to triangulate the most likely location of the wireless accessory 201.

[0086] Figure 8 A networked system 800 for locating devices and wireless accessories is shown, according to an embodiment. The system 800 also shows an exemplary server architecture for a device locator server 203, according to one embodiment. In one embodiment, the device locator server 203 is a cluster of interconnected server devices, which can be physical or virtual servers within a single data center, or distributed across multiple data centers and / or geographic locations. As described above, the device locator server 203 can communicate with the mobile device 102 of the accessory owner or user and the set of detector devices 303 over the wide area network 114. The mobile device 102 includes a UI provided by a local or web application that is capable of locating the wireless accessory, and the detector device 303 receives beacon signals from the wireless accessory and transmits location data associated with the received signals to the device locator server 203.

[0087] In one embodiment, the device locator server 203 includes a locator service front end 803, an account database 825, a database cluster manager 813, and a set of database cluster nodes 823A-823C. The locator service front end 803 is a front-end interface with which the mobile device 102 and the set of detector devices 303 can communicate. The account database 825 stores account profile data for the cloud service provider accounts associated with the mobile device 102 and the detector device 303. The database cluster manager 813 can configure the database cluster nodes 823A-823C as a distributed location database that can store location, signal, and ranging data associated with beacon identifiers of signal beacons received by the set of detector devices 303.

[0088] In one embodiment, the account database 825 can contain a list of devices associated with each cloud service account. In response to a request to locate a given device (including a wireless accessory as described herein), the account database 825 can verify that the request is from a device that is authorized to request the location of the given device. In one embodiment, when a user launches the device locator UI and communicates with the locator service front end 803, the locator service front end can communicate with the account database 825 and provide the current or last known location for each device associated with the requesting user, including devices and / or wireless accessories associated with other users in the account family associated with the requesting user.

[0089] In one embodiment, the database cluster manager 813 can select database cluster nodes 823A to 823C to store beacon data by performing a hash on the beacon ID associated with a set of location data. Each database cluster node 823A to 823C can be associated with a range of hash values. The database cluster manager can then store the location data in the cluster node corresponding to the hash value range associated with the hash of a given beacon ID. Although three database cluster nodes are shown, embodiments are not limited to any particular number of nodes, and more or fewer nodes can be used.

[0090] Figures 9A to 9C A device locator UI 204 is shown, according to an embodiment. Figure 9A A first graphical user interface of the device locator UI 204 is shown showing the locations of the user's various electronic devices and wireless accessories, according to one embodiment. Figure 9B A second graphical user interface of the device locator UI 204 is shown that enables a wireless accessory to be placed in an alert mode, according to one embodiment. Figure 9C A third graphical user interface of the device locator UI 204 is shown that enables a wireless accessory to be placed in lost mode, according to one embodiment.

[0091] like Figure 9AAs shown, the device locator UI 204 can be displayed on an electronic device 900, which can be a mobile device, or any other type of electronic device described herein. The device locator UI 204 can present a unified graphical interface through which multiple different types of devices and accessories can be located, including wireless devices with network or cellular access and wireless accessories without local network access. The device locator UI 204 can include a map 901 with a marker 902 that shows the current or last known location of the wireless device or accessory. The marker 902 can be an icon, image, graphic, or any other user interface element that identifies the accessory and conveys the location of the accessory. Optional element 903 in the device locator UI can present a description or name of the wireless device or accessory and can show an estimated distance between the wireless device or accessory and the current location of the electronic device 900.

[0092] like Figure 9B As shown, the device locator UI 204 can present a second user interface that enables the wireless accessory to be set to an alarm mode. In one embodiment, the second user interface can be responsive to selecting Figure 9A 903 shown in . The second user interface can present a user interface element 904 representing and / or describing the wireless accessory in question, as well as a map 901 and a marker 902 showing the current or last known location of the wireless accessory. In one embodiment, the device locator UI 204 can present a selectable element 905, such as a button or another user interface element, that allows a user of the device locator UI 204 to place the selected wireless accessory in alert mode. When in alert mode, the wireless accessory can be configured to trigger a notification to the user if the wireless accessory moves from its current location.

[0093] In one embodiment, the wireless accessory can detect movement via an accelerometer or other type of motion sensor within the wireless accessory. Notification can be initiated by the wireless accessory, specifically by setting a flag in a data packet transmitted by the wireless accessory's beacon signal, indicating that the wireless accessory alarm has been triggered. In various embodiments, other triggering or notification modes can be used. In one embodiment, the alarm can optionally be triggered by the mobile device upon detecting that the wireless accessory has moved out of range of the mobile device and is no longer in a near-owner state. In one embodiment, the alarm can optionally be triggered when the wireless accessory is out of range of or cannot be located by any device associated with a user account or account series associated with the wireless accessory.

[0094] like Figure 9CAs shown, the device locator UI 204 can present a third graphical user interface that enables the wireless accessory to be set to lost mode. In one embodiment, when the wireless accessory cannot be located via the device locator UI 204, the map 901 will not display a marker indicating the location of the accessory. The device locator UI 204 can present a user interface element 904 that represents and / or describes the wireless accessory in question and a set of optional user interface elements. An optional user interface element 906 can present an option for notifying the user when the accessory is found. When notification upon discovery is enabled, in one embodiment, the wireless accessory can be placed in a light lost mode. The electronic device associated with the device locator UI 204 can generate a set of public keys that the wireless accessory will broadcast along with the beacon signal during a future time period (e.g., the next 24 hours, the next 48 hours, etc.). If the detector device detects a signal using one of the future keys, the device locator server can notify one or more electronic devices associated with the user.

[0095] Another optional user interface element 907 can mark the wireless accessory as "lost" and place the wireless accessory in explicit lost mode. When explicitly placed in lost mode, the wireless accessory will not be able to pair with other devices until the accessory is unlocked by the user or owner who placed the device in lost mode. When a request is sent to place a wireless accessory in lost mode, the requesting user can be asked to enter authentication information to ensure that the requesting user is authorized to request to initiate lost mode on the lost accessory. The authentication information can include a username or password associated with an account of the user, such as a cloud service account associated with the user, the electronic device, and the wireless accessory. The authentication information can also include biometric information, such as fingerprint or facial recognition data, voice recognition, iris recognition, and other biometric information.

[0096] In one embodiment, a message and contact information provided by the requesting user can be displayed on the user device to prompt the person who finds the lost wireless accessory how to contact the requesting user. In one embodiment, the message and contact information can be displayed when another user attempts to pair another electronic device with the lost accessory.

[0097] Figure 10 302 is shown when attempting to pair with a lost wireless accessory. Figure 9A When an electronic device 900 that is not associated with a registered user or owner of the wireless accessory attempts to pair with a lost wireless accessory, the accessory pairing UI of the electronic device may be as follows: Figure 10In one embodiment, accessory pairing UI 302 can display a name or description 1001 associated with the wireless accessory and a message 1002 entered by the user of the accessory when placing the accessory in lost mode. Contact information 1004 can also be displayed, along with a user interface element 1006, such as a button, that enables electronic device 1000 to contact the requesting user using the provided contact information 1004.

[0098] Embodiments described herein include one or more application programming interfaces (APIs) in an environment, wherein calling program code interacts with other program codes called by one or more programming interfaces. Various function calls, messages, or other types of calls may also include various parameters, which may be transmitted via the API between the calling program and the called code. In addition, the API may provide the calling program code with the ability to use data types or categories defined in the API and implemented in the called program code.

[0099] An API allows developers of API-calling components (which may be third-party developers) to utilize specified features provided by an API-implementing component. There may be one API-calling component or more than one such component. An API may be a source code interface provided by a computer system or program library to support service requests from applications. An operating system (OS) may have multiple APIs to allow applications running on the OS to call one or more of those APIs, and a service (e.g., a program library) may have multiple APIs to allow applications using the service to call one or more of those APIs. An API may be specified in terms of a programming language that can be interpreted or compiled when building an application.

[0100] In some embodiments, the API implementation component may provide more than one API, each API providing a different view or having different aspects that access different aspects of the functionality implemented by the API implementation component. For example, one API of the API implementation component may provide a first set of functions and be exposed to third-party developers, and another API of the API implementation component may be hidden (not exposed) and provide a subset of the first set of functions, and also provide another set of functions, such as testing or debugging functions that are not in the first set of functions. In other embodiments, the API implementation component itself may call one or more other components via the underlying API, thereby being both an API-calling component and an API implementation component.

[0101] The API defines the language and parameters used by the API-calling component when accessing and using the specified features of the API-implementing component. For example, the API-calling component accesses the specified features of the API-implementing component through one or more API calls or references exposed by the API (e.g., implemented by function or method calls), and uses parameters to pass data and control information via the API calls or references. The API-implementing component can return values ​​through the API in response to API calls from the API-calling component. Although the API defines the syntax and results of API calls (e.g., how to cause an API call and what the API call can do), the API may not reveal how the API call completes the function specified by the API call. Various API calls are transmitted via one or more application programming interfaces between the caller (API-calling component) and the API-implementing component. Transmitting API calls may include issuing, initiating, referencing, calling, receiving, returning, or responding to function calls or messages; in other words, the transmission can describe the actions of either the API-calling component or the API-implementing component. Function calls or other references of the API can send or receive one or more parameters via parameter lists or other structures. A parameter can be a constant, a key, a data structure, an object, an object class, a variable, a data type, a pointer, an array, a list, or a pointer to a function or method or another way of referring to data or other items to be passed via an API.

[0102] In addition, data types or classes can be provided by the API and implemented by the API implementation component. Therefore, the API calling component can use the definitions provided in the API to declare variables, use pointers to such types or classes, and use or instantiate constant values ​​of such types or classes.

[0103] Typically, an API can be used to access services or data provided by an API implementation component, or to initiate operations or calculations provided by an API implementation component. By way of example, the API implementation component and the API call component can each be any one of an operating system, a library, a device driver, an API, an application, or other modules (it should be understood that the API implementation component and the API call component can be modules of the same or different types). In some cases, the API implementation component can be implemented at least partially in firmware, microcode, or other hardware logic components. In some embodiments, the API can allow client programs to use services provided by a software development kit (SDK) library. In other embodiments, an application or other client program can use the API provided by an application framework. In these embodiments, the application or client program can combine calls to functions or methods provided by the SDK and provided by the API, or use data types or objects defined in the SDK and provided by the API. In these embodiments, the application framework can provide a main event loop for the program, which responds to various events defined by the framework. The API allows applications to utilize the application framework to specify events and responses to events. In some embodiments, API calls can report the capabilities or status of hardware devices to applications, including capabilities or status related to aspects such as input capabilities and status, output capabilities and status, processing capabilities, power status, storage capacity and status, communication capabilities, etc., and the API can be partially implemented by firmware, microcode, or other low-level logic components that are partially executed on hardware components.

[0104] The API-calling component can be a local component (i.e., on the same data processing system as the API-implementing component) or a remote component (i.e., on a data processing system different from the API-implementing component), which communicates with the API-implementing component via an API over a network. It should be understood that an API-implementing component can also act as an API-calling component (i.e., it can make API calls to APIs exposed by different API-implementing components), and an API-calling component can also act as an API-implementing component by implementing an API exposed to a different API-calling component.

[0105] The API may allow multiple API-calling components written in different programming languages ​​to communicate with the API-implementing component (thus, the API may include features for translating calls and returns between the API-implementing component and the API-calling component); however, the API may be implemented in a specific programming language. In one embodiment, the API-calling component may call APIs from different providers, such as one set of APIs from an OS provider and another set of APIs from a plug-in provider, and another set of APIs from another provider (e.g., a software library provider) or the creator of another set of APIs.

[0106] Figure 11 is a block diagram illustrating an exemplary API architecture that may be used in some embodiments of the present invention. Figure 11 As shown in FIG, API architecture 1100 includes an API implementation component 1110 (e.g., an operating system, library, device driver, API, application, software, or other module) that implements an API 1120. API 1120 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 1130. API 1120 can specify at least one calling convention that specifies how functions in the API implementation component receive parameters from the API-calling component and how functions return results to the API-calling component. API-calling component 1130 (e.g., an operating system, library, device driver, API, application, software, or other module) makes API calls through API 1120 to access and use the features of API implementation component 1110 specified by API 1120. API implementation component 1110 can return values ​​to API-calling component 1130 through API 1120 in response to the API calls.

[0107] It should be understood that the API-implementing component 1110 may include additional functions, methods, classes, data structures, and / or other features that are not specified by the API 1120 and are not available to the API-calling component 1130. It should be understood that the API-calling component 1130 may be on the same system as the API-implementing component 1110, or may be remotely located and access the API-implementing component 1110 using the API 1120 over a network. Figure 11 A single instance of an API calling component 1130 interacting with the API 1120 is shown, but it should be understood that other API calling components written in different languages ​​(or the same language) than the API calling component 1130 may use the API 1120 .

[0108] The API implementation component 1110, API 1120, and API calling component 1130 may be stored in a machine-readable medium, which includes any mechanism for storing information in a form readable by a machine (e.g., a computer or other data processing system). For example, a machine-readable medium includes a magnetic disk, an optical disk, a random access memory, a read-only memory, a flash memory device, etc.

[0109] Figure 121 is a block diagram of a device architecture 1200 for a mobile or embedded device according to an embodiment. The device architecture 1200 includes a memory interface 1202, one or more processors 1204 (e.g., a data processor, an image processor, and / or a graphics processor), and a peripheral device interface 1206. The various components can be coupled via one or more communication buses or signal lines. The various components can be separate logic components or devices or can be integrated into one or more integrated circuits, such as a system-on-chip integrated circuit.

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

[0111] Sensors, devices, and subsystems can be coupled to the peripherals interface 1206 to facilitate a variety of functions. For example, a set of sensors 1210 (including a motion sensor 1211, a light sensor 1212, and a proximity sensor 1214) can be coupled to the peripherals interface 1206 to facilitate mobile device functions. There can also be one or more biometric sensors 1215, such as a fingerprint scanner for fingerprint recognition or an image sensor for facial recognition. Other sensors 1216 can also be connected to the peripherals interface 1206, such as a positioning system (e.g., a GPS receiver), a temperature sensor, or other sensing devices to facilitate related functions.

[0112] Device architecture 1200 also includes an audio / video system 1220. A camera subsystem 1221 and an optical sensor 1222 (e.g., a charge-coupled device (CCD) or complementary metal oxide semiconductor (CMOS) optical sensor) can be utilized to facilitate camera functions, such as taking photos and video clips. An audio subsystem 1226 can be coupled to a speaker 1228 and a microphone 1230 to facilitate voice-enabled functions, such as voice recognition, voice replication, digital recording, and phone functions. In the smart media devices described herein, the audio subsystem 1226 can be a high-quality audio system that includes support for virtual surround sound.

[0113] Communication functionality may be facilitated by one or more wireless communication subsystems 1224, 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 1224 may depend on the communication network over which the mobile device is intended to operate. For example, a mobile device including the illustrated device architecture 1200 may include a wireless communication subsystem 1224 designed to operate over a GSM network, a CDMA network, an LTE network, a Wi-Fi network, a Bluetooth network, or any other wireless network. Specifically, the wireless communication subsystem 1224 may provide a communication mechanism in which a media playback application may retrieve resources from a remote media server or retrieve scheduled events from a remote calendar or event server.

[0114] The I / O subsystem 1240 may include a touch screen controller 1242 and / or other input controllers 1245. For computing devices that include a display device, the touch screen controller 1242 may be coupled to a touch-sensitive display system 1246 (e.g., a touch screen). The touch-sensitive display system 1246 and the touch screen controller 1242 may detect contact and motion or pressure using, for example, any of a variety of touch and pressure sensing technologies, including but not limited to capacitive, resistive, infrared, and surface acoustic wave technologies, as well as other proximity sensor arrays or other elements for determining one or more points of contact with the touch-sensitive display system 1246. Display output for the touch-sensitive display system 1246 may be generated by a display controller 1243. In one embodiment, the display controller 1243 may provide frame data to the touch-sensitive display system 1246 at a variable frame rate.

[0115] In one embodiment, a sensor controller 1244 is included to monitor, control, and / or process data received from one or more of the motion sensor 1211, the light sensor 1212, the proximity sensor 1214, or the other sensors 1216. The sensor controller 1244 may include logic to interpret the sensor data to determine the occurrence of one of a plurality of motion events or activities by analyzing the sensor data from the sensors.

[0116] In one embodiment, the I / O subsystem 1240 includes other input controllers 1245 that can be coupled to other input / control devices 1248, such as one or more buttons, rocker switches, thumb wheels, infrared ports, USB ports, and / or pointer devices such as a stylus or controls / devices such as up / down buttons for volume controls for the speaker 1228 and / or microphone 1230.

[0117] In one embodiment, memory 1250 coupled to memory interface 1202 can store instructions for an operating system 1252, including both Portable Operating System Interface (POSIX)-compliant and non-compliant operating systems or embedded operating systems. Operating system 1252 can include instructions for handling basic system services and for performing hardware-related tasks. In some implementations, operating system 1252 can be a kernel.

[0118] The memory 1250 may also store communication instructions 1254 to facilitate communication with one or more additional devices, one or more computers, and / or one or more servers, such as obtaining web resources from a remote web server. The memory 1250 may also include user interface instructions 1256, including graphical user interface instructions to facilitate graphical user interface processing.

[0119] In addition, the memory 1250 may store sensor processing instructions 1258 to facilitate sensor-related processes and functions; phone instructions 1260 to facilitate phone-related processes and functions; instant messaging instructions 1262 to facilitate electronic messaging-related processes and functions; web browsing instructions 1264 to facilitate web browsing-related processes and functions; media processing instructions 1266 to facilitate media processing-related processes and functions; location services instructions, including GPS and / or navigation instructions 1268 and Wi-Fi-based location instructions, to facilitate location-based functionality; camera instructions 1270 to facilitate camera-related processes and functions; and / or other software instructions 1272 to facilitate other processes and functions, such as security processes and functions and system-related processes and functions. The memory 1250 may also store other software instructions, such as web video instructions to facilitate web video-related processes and functions; and / or online shopping instructions to facilitate online shopping-related processes and functions. In some implementations, the media processing instructions 1266 are divided into audio processing instructions and video processing instructions, respectively, to facilitate audio processing-related processes and functions and video processing-related processes and functions. A mobile device identifier, such as an International Mobile Equipment Identity (IMEI) 1274 or similar hardware identifier may also be stored in memory 1250 .

[0120] Each of the instructions and applications identified above may correspond to an instruction set for performing one or more of the functions described above. These instructions need not be implemented as separate software programs, processes, or modules. Memory 1250 may include additional instructions or fewer instructions. Furthermore, various functions may be implemented in hardware and / or software, including in one or more signal processing and / or application specific integrated circuits.

[0121] Figure 131300 is a block diagram of a computing system 1300 according to an embodiment. The computer system 1300 shown is intended to represent a series of computing systems (wired or wireless), including, for example, a desktop computer system, a laptop computer system, a tablet computer system, a cellular phone, a personal digital assistant (PDA) including a cellular PDA, a set-top box, an entertainment system or other consumer electronic device, an intelligent electrical device, or one or more specific implementations of an intelligent media playback device. Alternative computing systems may include more, fewer, and / or different components. The computing system 1300 can be used to provide a server device that may be connected to a computing device and / or a computing device.

[0122] The computing system 1300 includes an interconnect 1335 (e.g., a bus, a fabric) to enable communication between components of the computing system 1300. One or more processors 1310 may be coupled to the interconnect 1335. The computing system 1300 may also include memory 1320 in the form of random access memory (RAM) or other dynamic storage devices coupled to the interconnect 1335. The memory 1320 may store information and instructions that are executable by the processor 1310. The memory 1320 may also be main memory used to store temporary variables or other intermediate information during the execution of instructions by the processor 1310.

[0123] The computing system 1300 may also include a read-only memory (ROM) 1330 and / or other data storage device 1340 coupled to the interconnect 1335 that may store information and instructions for the processor 1310. The data storage device 1340 may be or include various storage devices, such as a flash memory device, a magnetic disk, or an optical disk, and may be coupled to the computing system 1300 through the interconnect 1335 or through a remote peripheral interface.

[0124] The computing system 1300 may also be coupled to a display device 1350 via an interconnect 1335 for displaying information to a user. The computing system 1300 may also include an alphanumeric input device 1360, which includes alphanumeric and other keys, which may be coupled to the interconnect 1335 to communicate information and command selections to the processor 1310. Another user input device includes a cursor control 1370 device, such as a touchpad, mouse, trackball, or cursor direction keys, for communicating direction information and command selections to the processor 1310 and controlling cursor movement on the display device 1350. The computing system 1300 may also receive user input from communicatively coupled remote devices via one or more network interfaces 1380.

[0125] The computing system 1300 may also include one or more network interfaces 1380 to provide access to a network such as a local area network. The network interface 1380 may include, for example, a wireless network interface having an antenna 1385, which may represent one or more antennas. The computing system 1300 may include multiple wireless network interfaces, such as Wi-Fi and A combination of near field communication (NFC) and / or a cellular phone interface. The network interface 1380 may also include, for example, a wired network interface to communicate with a remote device via a network cable 1387, which may be, for example, an Ethernet cable, a coaxial cable, a fiber optic cable, a serial cable, or a parallel cable.

[0126] In one embodiment, the network interface 1380 can provide access to a local area network, for example, by conforming to the IEEE 802.11 wireless standard, and / or the wireless network interface can 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 in lieu of communicating via a wireless LAN standard, the network interface 1380 can provide wireless communications using, for example, a time division multiple access (TDMA) protocol, a global system for mobile communications (GSM) protocol, a code division multiple access (CDMA) protocol, a long term evolution (LTE) protocol, and / or any other type of wireless communication protocol.

[0127] Computing system 1300 may also include one or more power supplies 1305 and one or more energy measurement systems 1345. Power supply 1305 may include an AC / DC adapter coupled to an external power source, one or more batteries, one or more charge storage devices, a USB charger, or other power source. The energy measurement system may include at least one voltage or current measurement device that can measure the energy consumed by computing system 1300 over a predetermined time period. In addition, one or more energy measurement systems may be included to measure, for example, the energy consumed by a display device, a cooling subsystem, a Wi-Fi subsystem, or other commonly used or high-energy-consuming subsystems.

[0128] Wireless accessory location and communication encryption

[0129] Figure 14 A system 1400 is shown for collaboratively performing key generation between an owner device 1402 and a wireless accessory 1430, according to an embodiment. The owner device can be a version of the mobile device 102 described herein. The wireless accessory 1430 can be a variation of the wireless accessory 201 described herein. The system 1400 shown can be used to implement Figure 31405 and the public key exchange 310 are variations of the initial pairing 305 and public key exchange 310 shown in the system 300, wherein the initial pairing 1405 is performed via a secure data session and the public key exchange 310 is a process of collaborative key generation 1410 performed between the owner device 1402 and the wireless accessory 1430. Furthermore, although a wireless accessory 1430 is shown and described, the device location functionality described herein is applicable to any electronic device that does not have a separate network connection to allow the device to update its location at a device location server and utilizing at least one radio capable of broadcasting a beacon signal 1431.

[0130] Collaborative key generation can begin after initial pairing 1405, which is performed via a secure session. In one embodiment, the initial pairing can be performed via an NFC-initiated Bluetooth connection. NFC data exchange between the owner device 1402 and the wireless accessory 1430 can be used to establish or exchange a shared secret for encrypting the Bluetooth connection. The encrypted Bluetooth connection can then be used to exchange data used to generate cryptographic material for locating the wireless accessory 1430.

[0131] Key Hierarchy for Collaborative Key Generation

[0132] Figure 15 A key hierarchy 1500 for the encryption scheme described herein is shown. The key hierarchy includes three sets of keys. The first set of keys is stored on the owner and accessory devices. The second set of keys is stored on the owner device. The third set of keys is stored on the owner device and any potential trustee devices. Each set of keys can be securely stored on the corresponding device, where the keys are encrypted during storage. In one embodiment, the first set of keys is maintained in a storage object 1510, which is stored in the owner device keystore and non-volatile memory of the accessory device. The first set of keys includes public keys 1511, secret keys 1512, and derivatives of these keys. The second set of keys includes device keys 1520, which are stored only on the owner device. The third set of keys includes location query and decryption keys 1522, intermediate keys 1524, status byte keys 1525, command keys 1526, and connection keys 1527, which can be delegated to trustee devices.

[0133] Public key 1511 is used to derive additional keys broadcast with wireless beacons and to encrypt the accessory's location data. Public key 1511 cannot be used directly because doing so would allow an observer to track the accessory. Therefore, diversified location encryption keys 1515 are derived from a set of anti-tracking secrets 1516. Anti-tracking secrets 1516 are derived from a set of diversified secret keys 1514. Diversified keys 1514 are derived from secret key 1512. In one embodiment, the set of diversified secret keys 1514 includes at least one key for each privacy window. Diversified secret keys 1514 can be used to derive a set of anti-tracking secrets 1516 and an owner command key 1517. Anti-tracking secrets 1516 are used to derive diversified location encryption keys 1515, which are broadcast by the accessory device and used to encrypt the accessory device's location uploaded by the detector device to the location server. The set of diversified location encryption keys 1515, anti-tracking secrets 1516, and owner keys also includes at least one key for each privacy window.

[0134] In one embodiment, device key 1520 can be used to derive a set of location query and decryption keys 1522 that are cryptographically related to the set of diversified location encryption keys 1515 and anti-tracking secret 1516. The set of diversified secret keys 1514 can also be used to derive the set of intermediate keys 1524. The set of intermediate keys 1524 can be used to derive the set of status byte keys 1525, command keys 1526, and connection keys 1527. Like the diversified location encryption keys 1515, diversified secret keys 1514, anti-tracking secret 1516, and owner command keys in the first set of keys, each set of keys in the third set of keys (e.g., owner keys and trustee keys) is derived for a specific privacy window and is valid only during the specific privacy window in which those keys were derived. Collaborative key generation can be used to generate public keys 1511, secret keys 1512, and device keys 1520, where the privacy window keys are derived based on the collaboratively generated keys.

[0135] Collaborative key generation process

[0136] Figure 16 The process of collaborative key generation according to an embodiment is shown. In one embodiment, collaborative key generation can be performed by a primary device 1602 and a secondary device 1630. The primary device 1602 can be an owner device, such as Figure 14 The user device 1402 in , or an equivalent device as described herein. The secondary device 1630 may be, for example, Figure 14 The wireless accessory 1430 or equivalent device described herein.

[0137] During collaborative key generation, primary device 1602 and secondary device 1630 collaboratively generate a key pair {d, P} and a secret key SK. During this process, secondary device 1630 cannot learn the private key d, and neither device can bias P or SK. The collaborative key generation process also prevents primary device 1602 from gaining full control of the secret key SK and key pair {d, P}, allowing an attacker to extract secrets from one device and reprogram them onto another legitimate device.

[0138] In one embodiment, the primary device 1602 and the secondary device 1630 may perform operations 1611A-1611B to establish a secure data communication session. The secure data communication session may be a secure Bluetooth connection established via a secret data exchange via an out-of-band (OOB) mechanism (such as a password, an identification number, or NFC data exchange). The secure data communication session may also be established via a wired connection, such as via an accessory interface cable connecting the primary device 1602 and the secondary device 1630.

[0139] The devices may then perform operations 1612A-1612B to generate key material and randomized data. In one embodiment, secondary device 1630 may generate a P-224 elliptic curve scalar value s and a random value r during operation 1612B. During operation 1612A, primary device 1602 may generate a P-224 elliptic curve scalar value s′ and a 32-byte random value r′. The primary device may also calculate a value S′=s′·G, where G is an elliptic curve generator parameter.

[0140] Primary device 1602 and secondary device 1630 may then perform operations 1613 and 1614 to exchange randomized data via a secure session. During operation 1613, primary device 1602 may send {S′, r′} to secondary device 1630, which in one embodiment is an 89-byte transmission. During operation 1614, secondary device 1630 may send a commitment value to primary device 1602, where commitment = Hash(s||r). In one embodiment, commitment is a 32-byte value. Secondary device 1630 may also send the value {s, r} to primary device 1602.

[0141] Then, primary device 1602 and secondary device 1630 may perform operations 1616A-1616B to calculate shared secret data based on the combined random data. Secondary device 1630 may calculate P = S' + s G. Primary device 1602 may confirm commitment = Hash(s||r). Primary device 1602 may also calculate d = s' + s(modq) and P = d G = (s' + s) G = s' G + s G = S' + s G. Then, both the primary device 1602 and the secondary device 1630 may calculate a shared secret key SK=KDF(x(P), r||r′. In one embodiment, |SK|=32 bytes. Then, the primary device 1602 and the secondary device 1630 may derive key material based on the shared secret in operations 1617 and 1618. In operation 1619, the primary device 1602 may store the key material to a key store, such as a shared cloud key store. The secondary device 1630 may store the key material to a local non-volatile storage device in operation 1620.

[0142] In one embodiment, the device may derive key material based on the secret key using the following techniques. Secondary device 1630 can export SK i , where counter is the current value of the internal counter and N is the number of seconds per privacy window a. For example, for a 15-minute privacy window, N = 900. The owner device can derive SK i , by setting i = or UT lookup is the time corresponding to the period during which position reports should be retrieved, UT now is the current time, and UT delegate UT is the delegation period during which the trustee is allowed to control the secondary device 1630. NVM Refers to the time when the primary device 1602 configures the secondary device 1630, which can be retrieved from the non-volatile memory of the secondary device 1630. In one embodiment, the primary device 1602 can set SK0 = SK for j = 0, ..., i-1. NVM And calculate SK j+1 =KDF(SK j , "update"), where for any x, |SK x | = 32 bytes, but the size of each key may vary between implementations.

[0143] Using a diversified secret key SK i , can generate owner command key OK i and anti-tracking secret AT iIn one embodiment, OK i =KDF(SK i , “owner”). In addition, AT i =(u i , v i )=KDF(SK i , “diversify”), where (u i , v i ) represents the coordinates of the elliptic curve point. In one embodiment, AT i is a 72-byte secret, but this size may vary between implementations.

[0144] The diversified public key Pi is a diversified version of the public key P. Pi can be derived without knowing the private device key d and can be used as a location encryption key instead of P to prevent long-term tracking of the secondary device 1630. i =(u i , v i ), P i =u i P+v i In one embodiment, u is generated in accordance with FIPS 186-4, B.5.1 "Per-Message Secret Number Generation Using Extra Random Bits". i and v i is converted to a valid scalar. For example, u i :=(u i mod(n-1))+1 and v i :=(v i mod(n-1))+1, where n is the order of magnitude of the base point G, as defined for P-224.

[0145] Diversified key d i is the diversified private key d and can be passed to the trustee without revealing d. i and SK i , the main device 1602 can calculate d i =(d·u i +v i ). A set of d i The trustee device can then calculate P i =d i G. The primary device 1602 and the trustee can use Pi to query the location of the secondary device 1630 at the positioning server.

[0146] Intermediate Key IKi =KDF(SK i The state byte key BK can be calculated by the primary device 1602 and shared with the trustee without revealing the private key d. The trustee (and the primary device 1602) can calculate the state byte key BK i , command key CK i and the connection key LTK i .BK i is an encryption key used to protect the secret transmitted via the status byte broadcast by the secondary device 1630 while sending the beacon, where (BK i ,BIV i )=KDF(IK i CK i is a command key used to ensure the authenticity of commands sent to the secondary device 1630, where CK i =KDF(IK i , “command”). LTK i is the connection key used to establish a connection to the secondary device 1630, where LTK i =KDF(IK i In one embodiment, each key is a 32-byte key, and BIV i is a 16-byte value, but this size may vary between implementations.

[0147] Entering near-owner status

[0148] Figure 17 1 is a flow chart of a process for entering a near owner state at a secondary device according to an embodiment. In one embodiment, when the primary device 1602 detects the presence of a secondary device 1630 nearby, the primary device 1602 may place the secondary device 1630 in the near owner state. In one embodiment, the secondary device 1630 is placed in the near owner state before certain commands can be issued. The near owner state may be entered using a command key CK based in part on the primary device 1602. i and the diversified public key P i The exported token places the secondary device 1630 in a near-owner state.

[0149] In one embodiment, the primary device 1602 and the secondary device 1630 may perform operations 1701A-1701B to enter a new privacy window and calculate new key material. The primary device 1602 and the secondary device 1630 may each calculate new key material for the privacy window i based on the key P, SK, or d, as described above.

[0150] The primary device 1602 may perform operation 1702 to update the radio controller lookup table with the expected broadcast address. The expected broadcast address may be based on a derived key. The secondary device 1630 may perform operation 1703 to update the broadcast address based on the derived key. The primary device 1602 and the secondary device 1630 may derive the derived key based on the calculated key material of the privacy window.

[0151] In one embodiment, the derived key is the diversified public key P i The reduced bit representation may be a compressed or compact representation of the diversified public key that stores a reduced number of elliptic curve coordinates. In one embodiment, the derived key is the compact representation x(P i ), where |x(P i )|=28 bytes, where only the x-coordinate of the elliptic curve point is provided. In one embodiment, an indicator of which of the two valid y-coordinates corresponds to the x-coordinate may also be provided.

[0152] In one embodiment, the broadcast address of the secondary device 1630 is updated by encoding the bytes of the derived key into the hardware address of the secondary device, for example, by setting the most significant bytes of the hardware address to the corresponding bytes of the derived key. The primary device 1602 can then update the radio controller (e.g., Bluetooth controller) lookup table to find the updated hardware address.

[0153] The primary device 1602 may perform operation 1704 to detect nearby secondary devices based on the expected broadcast address. The primary device 1602 may then perform operation 1705 to derive additional key material, which may include a nearby owner authorization token. In one embodiment, the diversified public key P i There is a 1:1 mapping between the near owner authorization token and the corresponding near owner authorization token, allowing tokens to be pre-computed for multiple privacy windows. In such an embodiment, the near owner authorization token of a privacy window can be derived as:

[0154] NearOwnerAuthToken i

[0155] =MostSignificant6Bytes(MAC(CK i ,x(P i )||“NearOwnerAuthToken”))

[0156] The primary device 1602 performs operation 1706 to send a message with the near owner authorization token as the source address. In one embodiment, the message is a Bluetooth network packet sent with the near owner authorization token as the Bluetooth source hardware address. The secondary device 1630 can then enter the near owner mode in response to receiving the message with the near owner authorization token as the source address.

[0157] Connection and command tokens

[0158] Figure 18 is a flow chart of a process for connecting to and commanding a secondary device according to an embodiment. The process can be performed by a primary device to connect to and command a secondary device in a manner protected by keys and tokens as described herein.

[0159] In one embodiment, the primary device may perform operation 1801 to detect a nearby secondary device. For example, the primary device may detect a secondary device within wireless range. The secondary device may be a paired secondary device. During operation 1802, the primary device may use the nearby owner authorization token to place the secondary device in a nearby owner mode. The primary device may detect the nearby secondary device and place the secondary device in a nearby owner mode, as described above with respect to Figure 17 As stated.

[0160] The primary device may then perform operation 1803 to trigger a connection with the secondary device using the connection authorization token when the secondary device is in near-owner mode. The primary device and the secondary device may each calculate the connection authorization token as:

[0161] ConnectionAuthToken i

[0162] =MostSignificant6Bytes(MAC(CK i ,x(P i )||“ConnectionAuthToken”))

[0163] In the above formula, MAC refers to the message authentication code. The secondary device can use the ConnectionAuthToken i Placed into the wireless controller lookup table. The primary device can obtain the ConnectionAuthToken from the i The primary device may then perform operation 1804 to connect to the secondary device using the connection key. For example, the primary device and the secondary device may use the connection key LTK iEstablish a wireless connection, such as but not limited to a Bluetooth connection. In one embodiment, to prevent the use of an incorrect LTK i Repeated battery drain attacks can rate-limit the token's responses.

[0164] The primary device may then perform operation 1805 to send a command to the secondary device using the command key. Some commands can only be sent by the owner device using the owner command key OK i For this type of command, the owner device can send a command to the secondary device via the following command:

[0165] send <command> ||MAC(OK i ,x(P i )||“OwnerCommand”|| <command> || <counter>)

[0166] In this command composition, counter is a 32-bit integer that increases monotonically with each valid owner command sent to the secondary device. The counter value can be reset at each privacy period. The primary device and the secondary device each track the counter value. In one embodiment, if the secondary device receives a command with an invalid hardware address, the secondary device will discard the command, not increment the counter value, and terminate the connection. Although authentication commands using command keys are described, some commands can be non-authentication commands that do not require the presence of a command key. The device can support both authentication commands and non-authentication commands. In one embodiment, some commands can be authenticated or non-authenticated depending on the state of the secondary device.

[0167] In one embodiment, the secondary device may determine the validity of a command based in part on the owner or trustee status associated with the primary device and whether the primary device has the appropriate key for the attempted command.Delegation is described in more detail below.

[0168] Delegating functions to a trustee device

[0169] Figure 19 A system 1900 is shown in which access to a wireless accessory can be delegated to a user for a period of time. In one embodiment, system 1900 includes owner device 1402, trustee device 1904, device locator server 1920, and wireless accessory 1430. Owner device 1402 and trustee device 1904 can each be a variation of mobile device 102 as described herein. Wireless accessory 1430 can be a variation of wireless accessory 201 as described herein. Device locator server 1920 can be a variation of location device server 203 as described herein. Wireless accessory 1430 can also be a variation of wireless accessory 201 as described herein. Figure 16 Generic secondary device 1630 is shown.

[0170] The user of the owner device 1402, via the delegation UI 1903, can delegate all or a subset of ownership features to the trustee device 1904 via the transmission of the trustee key 1905. The owner device 1402 can generate a privacy window a for a predetermined number of privacy windows. Figure 15 1402 ). The trustee device 1904 may be configured to perform delegation by using keys from the third set of keys (owner keys and trustee keys) and providing those keys to the trustee device 1904 via a transmission 1905 of the trustee keys. The transmitted trustee keys may enable the trustee device 1904 to perform a set of operations, including but not limited to tracking, accessing, using, or controlling the wireless accessory 1430, via the trustee UI 1906. For example, the trustee keys may be used to derive additional keys that may allow the trustee device 1904 to temporarily use the wireless accessory 1430 in the same manner as the owner device 1402. Alternatively, specific features may be delegated to the trustee device 1904. For example, the owner device 1402 may delegate to the trustee device 1904 the ability to detect 1933 a wireless accessory via a beacon signal 1431 transmitted by the wireless accessory 1430 in the same manner as the owner is able to detect 1932 a wireless device. The owner device 1402 may also have the capability to query 1922 the location of the wireless accessory 1430 via the device locator server 1920 in the same manner that the owner device 1402 may query 1921 the location of the wireless accessory 1430 .

[0171] The specific functionality delegated to the trustee device 1904 may be determined based in part on one of the specific keys provided to the trustee device 1904. For example, and with reference to Figure 15 , the location query and decryption key 1522 can be delegated to enable the trustee to perform location query and decryption of the secondary device location. The delegation of the intermediate key 1524 can enable the trustee to derive the status byte key 1525, command key 1526, and connection key 1527. Alternatively, individual functions can be delegated by providing individual keys.

[0172] Figure 20 2 is a flow chart of a process for delegating functionality to a trustee device according to an embodiment. In one embodiment, the owner device 1402 can perform operation 2001 to generate a set of trustee keys for one or more privacy windows, as described in further detail above. The owner device 1402 can then perform operation 2002 to send the trustee keys to the trustee device 1904 to enable the trustee to interact with the wireless accessory during the one or more privacy windows. The functionality to be delegated to the trustee device 1904 can be determined at least in part based on a specific key generated and provided to the trustee device.

[0173] The trustee device 1904 may then perform operation 2003 to receive the trustee key at the trustee device. The trustee device may optionally perform a consistency check operation 2004 to verify that the trustee key is valid. The consistency check operation 2004 may include performing a consistency check to ensure that the key has not been compromised. In the case of using an elliptic curve cryptography system, the consistency check may include performing cryptographic verification to ensure that the key defines a valid elliptic curve point.

[0174] The trustee device 1904 may then perform operation 2005 to derive additional cryptographic material for communicating with the secondary device accessory and / or querying the location of the secondary device based on the trustee key. The additional cryptographic material may include a subkey in the key hierarchy (e.g., a state byte key, a command key, or a connection key based on an intermediate key). If such a key is provided directly, the additional cryptographic material may also include a token for communicating with or commanding the secondary device to which access is being delegated.

[0175] Then, the trustee device 1904 can perform operation 2006 to detect beacons, query location and / or communicate with the secondary device via the derived and / or delegated derived key. In some embodiments, the trustee device 1904 can perform a subset of the operations of the primary device (e.g., primary device 1602) described herein. Each function can be delegated, wherein the functions of these delegations are defined at least in part based on the delegated key. The delegated functions are only valid for the privacy window in which the key is provided. In one embodiment, some command functions cannot be delegated. For example, unpairing and re-pairing can be limited to the owner device and cannot be delegated.

[0176] In one embodiment, functionality that may be delegated includes the ability to track or find a secondary device. A trustee may be able to find the device for a period of time, but may not be able to locate or track the device outside of the delegated period. In one embodiment, functionality may be delegated for a secondary device while explicitly excluding the ability to track the secondary device via a location server during the delegated period, but the trustee may be able to locate the device if it is nearby. In one embodiment, a user associated with an online account that has been designated as a parent account may be automatically delegated the ability to locally or remotely locate a secondary device associated with an online account that has been designated as a related child account. In one embodiment, the ability to remove a secondary device based on a "lost" status may be delegated.

[0177] In one embodiment, the ability to silence tracking alerts associated with secondary devices may be delegated. For example, in one embodiment, a primary device as described herein may be configured to notify the user of a device if a secondary device that is not owned or delegated by the primary device appears to be following the primary device, for example, if an unowned or undelegated secondary device is continuously detected, particularly when in motion. In such embodiments, the primary device may be configured to notify the user of the persistent and / or multi-location presence of such secondary devices. Such notifications may be used to notify the user of potential covert tracking of the user via a hidden secondary device (e.g., by placing a beacon wireless device in the user's bag). However, scenarios may arise where a beacon secondary device may reasonably be following the user. For example, a secondary device that is in or attached to the bag of another individual (e.g., a child, a passenger) in a vehicle may trigger a tracking notification. The ability to silence such notifications may be delegated so that tracking warnings will not be received for such devices.

[0178] Minor device recovery

[0179] Figures 21A to 21B Methods 2100, 2110 for restoring an out-of-sync secondary device are shown, according to an embodiment. If a secondary device runs out of battery or has its battery removed, an internal counter within the device may stop incrementing. When the battery is recharged or reinserted, the secondary device's counter may resume incrementing. As a result, the counter on the secondary device used to generate the key for each privacy window may lose synchronization with the primary device. To restore an out-of-sync secondary device, the primary device may determine the secondary device's current counter value, resynchronize with the secondary device's privacy window, and then restore the secondary device by resetting the secret key stored on the device. Figure 21A A method 2100 of resynchronizing a private window with an out-of-sync secondary device is shown. Figure 21B A method 2110 of restoring a secondary device after resynchronizing to a privacy window of the secondary device is shown.

[0180] like Figure 21A As shown, the primary device may optionally perform operation 2101 to detect an out-of-sync condition with the wireless accessory. In one embodiment, operation 2101 may be performed by detecting the presence of a valid secondary device that is paired with the primary device but to which the primary device cannot connect or directly command a key associated with the current privacy window. In one embodiment, the primary device may detect (or assume) the presence of a potential out-of-sync condition via stored status byte information. For example, if the primary device detects that a secondary device has entered a severe low power state before going offline or not being detected for a period of time, the primary device may set an internal flag indicating that the diversified cryptographic material on the secondary device may be broadcast out of sync with the diversified cryptographic material of the primary device due to an out-of-sync privacy window caused by an out-of-sync counter.

[0181] At any time when a secondary device is powered back on and begins broadcasting, the probe device may upload location data to the positioning server. The location data may have a timestamp associated with a privacy window i (e.g., the current window), but may be indexed by an unsynchronized diversified public key. The primary device may resynchronize with the secondary device via the device's location records uploaded by the probe device. The primary device may collect this data by requesting location records from the positioning server until location data corresponding to the requested location query key is returned. These requests may be batched or continuous, depending on the configuration of the device positioning server.

[0182] In one embodiment, the primary device may perform operation 2102 to request the device locator server to send location data corresponding to a first set of location query keys. The first set of location query keys may be a set of keys associated with a privacy window and / or a counter range that starts at the current privacy window and extends back to privacy window x, where, in one embodiment, privacy window x corresponds to the last known window in which the secondary device was located or detected. The primary device may then perform operation 2103 to receive an encrypted location report from the device location server, where the encrypted location report corresponds to one of the location query keys. Upon receiving at least one location report, the primary device may perform operation 2104 to decrypt the location report to determine the past location of the secondary device and the timestamp of the location report.

[0183] In one embodiment, the primary device may perform operation 2105 to determine a privacy window offset between the primary device and the secondary device. The privacy window offset may be determined based on a difference between a counter associated with a timestamp of a received location report and a counter associated with a privacy window of a key used to encrypt the location report data. For example, if a secondary device location report has a timestamp associated with privacy window i, and the location data is encrypted with a key from privacy window j, the counter difference may be determined as (ji). The primary device may then perform operation 2106 to derive a second set of keys based on the determined privacy window offset. The primary device may then adjust an internal counter by ji and derive SK based on the adjusted counter. recovery . Can be based on SK recovery Derive a derived key for the second set of keys.

[0184] The primary device may then perform operation 2107 to determine whether a nearby secondary device has been detected via a key from the second set of keys. If no secondary device is detected nearby, the primary device may perform operation 2108 to request the device locator server to send updated location data corresponding to a location query key from the second set of keys, which may enable the user to locate and move closer to the location of the secondary device to attempt recovery. If a secondary device is detected nearby during operation 2107, the primary device may perform operation 2109 to recover the secondary device using one or more keys from the second set of keys (e.g., a connection key and / or a command key). Recovery of the secondary device may include transmitting a new secret key to the secondary device and / or resetting a counter on the secondary device.

[0185] like Figure 21B As shown, the primary device may begin method 2110 of restoring the secondary device by executing operation 2111 to use the determined restoration key (eg, the restoration key based on SK in operation 2106). recovery Alternatively, in one embodiment, a dedicated recovery key can be pre-established during pairing, and the pre-established recovery key can be used to restore the secondary device. Use of the pre-established recovery key can be limited to a period of time after the user performs a specific operation or activity on the secondary device, such as removing and replacing the battery or pressing a button on the secondary device.

[0186] The primary device can update the wireless controller lookup table to search for the MostSianificant6Bytes(x(P recovery )) to detect the advertisement. Once the secondary device is detected, the primary device may perform operation 2112 to place the secondary device in near owner mode using the near owner authorization token. In one embodiment, the primary device may detect a nearby secondary device and place the secondary device in near owner mode, as described above with respect to Figure 17 As stated.

[0187] In one embodiment, the primary device and the secondary device may optionally perform operation 2113 to re-run the Figure 16 The collaborative key generation process shown. Re-running the collaborative key generation process can also protect the secondary device from being compromised against scenarios where an attacker may have been able to extract material from the non-volatile memory of the secondary device while the secondary device was powered off. The primary device can then perform operation 2114 to store the updated diversified secret and / or key to the secondary device. The updated diversified secret can be based on the regenerated key material (e.g., P, SK, d). The primary device can also re-generate the key material by providing a new SK NVM The primary device may also perform operation 2115 to instruct the secondary device to reset one or more counters. For example, the internal time of the secondary device may be reprogrammed during the restoration.

[0188] In some embodiments, the hash functions described herein may utilize specialized hardware circuitry (or firmware) of the system (client device or server). For example, the function may be a hardware-accelerated function. Furthermore, in some embodiments, the system may utilize functions that are part of a specialized instruction set. For example, the system may utilize an instruction set that is an extension of the instruction set architecture for a particular type of microprocessor. Thus, in one embodiment, the system may provide a hardware acceleration mechanism for performing cryptographic operations, thereby increasing the speed at which the functions described herein may be executed using these instruction sets.

[0189] Computing system with a security processor

[0190] Figure 22 A computing system 2200 including a security processor is shown according to an embodiment. In one embodiment, the security processor 2203 shown includes logic for accelerating cryptographic operations as described herein. The computing system 2200 can enable a device to perform secure accelerated cryptographic operations, provide secure storage for a subset of private keys, and enable encryption of other private keys. Versions of the computing system 2200 can be included in primary devices (e.g., smartphones) and secondary devices (e.g., computing devices, wearable devices, wireless accessories), as described herein.

[0191] The computing system 2200 includes an application processor 2221 communicatively coupled to a security processor 2203 via a secure interface 2219. The computing system 2200 can be part of any of the client devices described herein. Additionally, the computing system 2200 can be included in one or more of the servers described herein. In one embodiment, the security processor 2203 can be implemented as a system on a chip. In another embodiment, the application processor 2221 and the security processor 2203 can be implemented on a system on a chip and include one or more processors and a memory controller, among other components, on a single integrated circuit.

[0192] The security processor 2203 can perform cryptographic operations as described herein, as well as other system security operations, such as encrypting user files or verifying code signatures, processing user passwords, or performing other security operations. Cryptographic operations can be performed in part by the security processor core 2215 by executing software stored as firmware 2211 in the security processor 2203. The security processor core 2215 can also be coupled to the ROM 2213, which can be trusted software that can verify the software in the firmware 2211 before allowing it to execute, by checking the code signature of the firmware and verifying that the signature code indicates that the firmware is valid and has not been corrupted, and then allowing the firmware to be executed by the security processor core 2215.

[0193] The security processor 2203 may also include a cryptographic accelerator, such as cryptographic accelerator 2207, which can perform asymmetric cryptography as well as symmetric cryptography using hardware accelerators. The cryptographic accelerator 2207 may be coupled to a memory 2205, which may be a non-volatile and immutable memory for securely storing a device identifier or a set of device identifiers and a set of one or more certificates and private keys, which, in one embodiment, are hidden from and cannot be read by the rest of the system. The cryptographic accelerator 2207 may access the private keys and other data within the memory 2205 and may not allow components outside of the security processor 2203 to access the memory 2205. In one embodiment, the cryptographic accelerator 2207 may be coupled to an accelerator memory 2209, which may be a scratch pad memory for performing the cryptographic operations performed by the cryptographic accelerator 2207. The application processor 2221 can be coupled to one or more buses 2223, which are coupled to one or more input and output (I / O) devices 2227, such as a touch screen display, a Bluetooth radio, an NFC radio, a Wi-Fi radio, etc. Other input and output devices may be included. The application processor 2221 is also coupled to the application processor ROM 2225, which provides software for starting the application processor. Similarly, the ROM 2213 provides code to start the security processor core 2215 within the security processor 2203.

[0194] Trustee Key Sharing System

[0195] Figure 23 A system 2300 for enabling sharing of trustee keys via a cloud storage system is shown. System 2300 includes a network 114 that facilitates communication between an owner device 1402 and a trustee device 1904, to which keys can be shared to enable the trustee device to perform actions with wireless accessories. Owner device 1402 and trustee device 1904 can configure a key sharing arrangement through which pre-computed trustee keys can be shared. System 2300 also includes a network-connected data repository 2313 that can be used to store a record of the key sharing arrangement, and an identity server 2320 that enables owner device 1402 and trustee device 1904 to be located via network 114 using an identity handle for an account associated with the device. While network 114 is a wide area network, such as the Internet, communication between owner device 1402 and trustee device 1904 can also occur via a local network.

[0196] The identity server 2320 includes one or more networked server devices that provide services related to obtaining information related to users, user accounts, and / or devices associated with users and user accounts. When the owner device 1402 and the trustee device 1904 are connected to the network 114, the devices can register with the identity management infrastructure including the identity server 2320 to receive an encrypted identification token for the device. The identification token can be based on one or more user or account identifiers and a unique entity or device identifier that can be combined to generate an entity or device token that at least quasi-uniquely identifies each device. The owner device 1402 and the trustee device 1904 can use the identification token to register for various services provided via the identity management infrastructure. The identification token for each device can be associated with an online user account associated with the device.

[0197] In one embodiment, the owner device 1402 and the trustee device 1904 can communicate via a channel established by or routed through the identity server 2320. For example, the device can send a device information request message to the identity server 2320 to obtain information, thereby enabling the transmission of a message to one or more electronic devices associated with the handle. The handle can be an email address, a phone number, and / or another piece of information that can be used to identify the user or an account associated with the user. Using the handle associated with the user or user account, the mobile device can obtain information, such as a push token, that allows the mobile device to contact a set of mobile devices associated with the handle. In one embodiment, the identity server 2320 can also act as a message relay between the owner device 1402 and the trustee device 1904.

[0198] The network-connected data repository 2313 is a remote storage location that can be used to store data on behalf of the owner device 1402 and the trustee device 1904. The network-connected data repository 2313 can be a server, a network-addressed storage location, a collection of computing devices, or can be part of a cloud storage system that presents virtualized network storage. A shared beacon record can be created that represents a key sharing stream for a wireless accessory with a specified universally unique identifier (UUID). The shared beacon record can be stored on the network-connected data repository 2313 and securely shared between the owner device 1402 and the trustee device 1904.

[0199] In one embodiment, the owner device can select a user to whom a subset of the functions associated with the accessory device (e.g., wireless accessory 1430) will be delegated via the delegation UI 1903. The owner device 1402 can then send a sharing request message 2302 including a sharing beacon record via the network 114. The sharing request message 2302 can be sent directly to the trustee device 1904 via the network 114, where the network address of the trustee device 1904 is resolved via the identity server 2320. If the owner device 1402 cannot send a direct message to the trustee device 1904, a relayed sharing request 2304 can be sent to the trustee device via the identity server 2320. The user of the trustee device 1904 can accept or reject the sharing proposal via the delegation UI 1906. If the sharing proposal is accepted, the sharing beacon record stored in the data repository 2313 of the connection network can be marked as accepted and used to track the sharing arrangement.

[0200] Figure 24 2 is a diagram illustrating a system 2400 for securely storing data items, according to an embodiment. The system 2400 includes a first device 2402, a second device 2404, a third device 2406, and a remote storage location 2408. The first device 2402, the second device 2404, the third device 2406, and the remote storage location 2408 are communicatively coupled together using one or more networks 2410. The one or more networks 2410 may include an example of the wide area network 114 described herein, and may include both wired networks and wireless networks. The network 2410 may be, for example, a local area network or a portion of a wide area network such as the Internet. The system 2400 may be used to enable devices to share a beacon record associated with a key sharing arrangement between an owner and a trustee device.

[0201] The first device 2402, the second device 2404, and the third device 2406 may each be, but are not limited to, a mobile device and may represent either the owner device 1402 or the trustee device 1904. The first device 2402, the second device 2404, and the third device 2406 may include, for example, a desktop or laptop computing device, a mobile device, a tablet device, a personal data assistant, a wearable device, or other computing device. Each of the first device 2402 and the second device 2404 may be associated with a first user or user account 2412. Similarly, the third device 2406 and one or more other devices (not shown) may be associated with a second user or user account 2414. The remote storage location 2408 may also be coupled to many other devices associated with one or more different users or different user accounts.

[0202] In one embodiment, devices can be associated with corresponding users or user accounts by forming an association between a unique or quasi-unique device key or device identifier for each device and a unique or quasi-unique account key or account identifier for each account. For example, the key or device identifier of the first device 2402 and the second device 2404 can be associated with the key or account identifier of the user or user account 2412. The key or device identifier of the third device 2406 can be associated with the key or user account identifier of the user or user account 2414. Such an association can be used to allow authenticated access to account-based storage on the remote storage location 2408.

[0203] Remote storage location 2408 may be a single storage location or multiple storage locations, such as a server, a network address storage location, a collection of computing devices, or as part of a cloud storage system that presents virtualized network storage.

[0204] Remote storage location 2408 includes independent logical containers for storing data from different user / user accounts and application combinations. In some examples, a logical container can be a directory in a file system, a data structure, a database, or another unit of data organization. For example, a first user or user account 2412 can have containers 2416 on remote storage location 2408, each container for each separate application associated with the user or user account. Similarly, a second user or user account 2414 can have containers 2418 for corresponding applications. Application data items received from each device (e.g., first device 2402) are stored in the corresponding container for that application. Remote storage location 2408 can include a storage manager that can create and manage containers and generate notifications for devices.

[0205] The first device 2402 includes one or more applications 2420, a synchronization manager 2422, and an access manager 2424. The one or more applications 2420 may include various types of applications, such as productivity applications, system applications, games, etc. Each application may be associated with a unique key or other identifier that can be used to identify the application and identify specific access rights for the application. In some specific implementations, the one or more applications 2420 are sandboxed so that the applications are isolated from each other.

[0206] Synchronization manager 2422 manages sending data items to remote storage location 2408 and receiving information (e.g., data items or notifications) from remote storage location 2408. Access manager 2424 presents available data items to applications in applications 2420 in response to queries from the corresponding applications. Access manager 2424 applies one or more access policies to determine which data items will be visible to a particular application in applications 2420.

[0207] Similarly, the second device 2404 includes one or more applications 2426, a synchronization manager 2428, and an access manager 2430. Applications 2420 and 2426 may include one or more of the same applications. Similarly, the third device 2406 includes one or more applications 2432, a synchronization manager 2434, and an access manager 2436.

[0208] FIG. 25A to FIG. 25B Shown are storage containers and records of a network-connected data repository that can be used to enable key sharing for a wireless accessory. Figure 25A A storage container 2502 of a storage system 2500 is shown that may be used to store cloud storage records. Figure 25B A storage area 2508 and cloud storage records 2510 are shown that can be used to store shared beacon records.

[0209] like Figure 25A As shown, storage container 2502 includes a shared database 2504 and a private database 2506, which are storage locations for shared and private data, respectively. Shared database 2504 includes data that has been shared with accounts associated with the storage container. Such data can be encrypted using a key generated based on a secret shared between users with legitimate access to the shared data. Data written to private database 2506 is visible only to the user associated with private database 2506, unless the data is shared with other users. Data within private database 2506 shared with other users can be stored in those users' shared databases 2504.

[0210] The data in the private database 2506 can be divided into one of a plurality of zones (e.g., zone 2508, zone 2509). Each zone is associated with a set of asymmetric encryption keys. These encryption keys can be different for each zone so that access to each zone can be managed separately. In one embodiment, an elliptic curve integrated encryption scheme (ECIES) is used, in which each zone has an associated EC key pair. However, various asymmetric encryption techniques can be used to encrypt these zones, and the encryption used for the zones is not limited to any particular encryption algorithm or technique. Different encryption algorithms, such as variants of the Advanced Encryption Standard (AES), such as AES-256, can be used to further encrypt the data within these zones.

[0211] Each zone can include multiple records. For example, zone 2508 can include multiple records 2510A-2510N. In one embodiment, each record 2510A-2510N can store a set of fields, where each field can contain various types of data, such as a string, a number, a date, a location, a reference, or a file. Zone 2509 can store records in a manner similar to zone 2508.

[0212] The data in the shared database 2504 can be arranged similarly to the private database 2506. For example, the shared database 2504 can include one or more sections (e.g., section 2511). The shared database 2504 can also include one or more shares (e.g., share 2512) that can be accessed by users associated with other online accounts. One or more records (e.g., record 2514) can be stored in share 2512. In one embodiment, section 2511, share 2512, and record 2514 can be separately encrypted.

[0213] like Figure 25B As shown, record 2510 in area 2508 can be a shared beacon record for storing a record of a shared arrangement. Record 2510 can represent any one of a plurality of records 2510A-2510N. Record 2510 can include a plurality of fields, including a shared recipient field 2520, a beacon identifier field 2522, a shared capability field 2524, and an accepted field 2526. Record 2510 can be shared by the owner of the wireless accessory with a sharer / trustee via a network-connected data repository (e.g., network-connected data repository 2313) as described herein.

[0214] The share recipient field 2520 may store a share recipient identifier, which may be an identity handle for an account associated with the cloud data repository. The share recipient identifier may be used to specify an account to which the trustee key is to be transferred. The share recipient may use the trustee key to perform a subset of the actions that the owner may perform using the shared wireless accessory. The beacon identifier field 2522 may store a beacon UUID, which is the identifier of the wireless accessory with which the trustee key will be shared. A set of trustee keys may be transferred within a predetermined time period after the initial sharing is established. The owner may periodically send a new set of trustee keys to the share recipient identifier specified by the share recipient field 2520. If the predetermined time period expires before the owner sends the new keys, the sharer / trustee may also request a new set of keys using the beacon UUID.

[0215] The shared capabilities field 2524 may be used to specify a set of capabilities to be shared with the sharer / trustee. The capabilities granted to the sharer or trustee may be determined based on the set of keys being shared. For example, Figure 15 , the ability to query the device locator server for the location of the accessory can be granted by sharing a location query key and a decryption key 1522. The ability to decode status byte information (e.g., battery level, device status, etc.) can be delegated via a status byte key 1525. The ability to connect to the accessory and issue commands to the accessory can be granted by sharing a command key 1526 and a connection key 1527. In one embodiment, a shared intermediate key 1524 allows the trustee to derive the status byte key 1525, the command key 1526, and the connection key 1527. Different capabilities can be shared separately. For example, a trustee may be able to cause the accessory to play a sound when approaching a wireless accessory so that the accessory can be located, but may not be able to query the accessory's location to view the accessory on a map.

[0216] Accepted field 2526 can be used to indicate whether the sharer has accepted record 2510. When record 2510 is created and shared, accepted field 2526 is initially set to false. If the recipient of the share accepts the share, the recipient can set their instance of record 2510 to accepted and send a notification to the owner. When the owner receives notification that the share has been accepted, the owner can update their instance of record 2510 to accepted.

[0217] Figures 26A to 26C is a sequence diagram of operations for configuring key sharing for a wireless accessory. Figure 26A The operation of establishing a share is shown. Figure 26B A key update operation for an established share is shown. Figure 26C An operation of stopping sharing is shown.

[0218] like Figure 26A As shown, owner device 2603 may send a sharing request to share recipient device 2505. Owner device 2603 may be, for example, owner device 1402, and share recipient device 2605 may be trustee device 1904. Share recipient device 2605 may be identified by a share recipient identifier, which may be, for example, an identity handle of an account associated with share recipient device 2605.

[0219] The owner device 2603 can perform operation 2602 to start sharing a beacon (eg, wireless accessory) to the identity handle <id>, which identifies the sharing recipient device 2605 and / or the user account associated therewith. The owner device 2603 then performs operation 2604 to create a sharing beacon record for the sharing recipient and sets the acceptance status to false. The sharing beacon record can be written to a local container that is synchronized with a remote container on a server associated with the cloud data repository. The owner device 2603 then performs operation 2606 to send a sharing request to the sharing recipient device 2605. The sharing can be sent via an identity service (IDS) channel established using the identity server 2320. The sharing beacon record can be sent along with the sharing request. In one embodiment, a universal resource locator (URL) to the sharing beacon record can be sent along with the sharing request, and the sharing recipient device 2605 can retrieve the sharing beacon record via the URL.

[0220] The sharing recipient device 2605 may receive the sharing request and perform operation 2608 to write the sharing beacon record to the cloud storage container. The sharing recipient device 2605 may then perform action 2610 to display an acceptance UI on the device display, allowing the user to accept or reject the sharing. The sharing recipient device 2605 may send an acceptance message or a rejection message 2612 to the owner device 2603 via the IDS channel. When the user of the sharing recipient device 2605 indicates via the acceptance UI that they agree to accept the sharing, an acceptance message may be sent. When the user of the sharing recipient device indicates that they reject the sharing, a rejection message may be sent. If the recipient user rejects the sharing in the UI, the owner device 2603 and the sharing recipient device 2605 may perform operations 2614a-2614b to delete the sharing beacon record from the cloud data repository. If the recipient user accepts the sharing in the UI, the owner device 2603 and the sharing recipient device 2605 may perform operations 2616a-2616b to update the sharing beacon record to indicate that the sharing has been accepted.

[0221] like Figure 26B As shown, every N days, the owner device 2603 may send a key list 2622 to the share recipient device 2605. The share recipient device 2605 may then perform operation 2624 to write these keys to the file system on the device as a key record. The share recipient device 2605 may use these keys stored in the key record to locate and / or communicate with the shared attachment. The value of N may be determined by the user of the owner device 2603 or by system policy. The specific type of key in the key list 2622 may be determined based on the capabilities to be shared with the share recipient device 2605. When the share recipient device 2605 wants to perform an action with the shared attachment, the device may select the appropriate key for the appropriate privacy period and use these keys to detect, locate and / or communicate with the attachment. The share recipient's identity handle may be used to send the key list to multiple devices associated with the share recipient. Alternatively, the share recipient's device may receive the key list and synchronize the key record with other devices.

[0222] The owner device 2603 can transmit a new key to the shared recipient device 2605 at the optimal time based on the owner device's device state (e.g., battery level, network connectivity, etc.). Consequently, the shared recipient may run out of keys, causing the current time period (e.g., number of privacy windows) to exceed the time period during which the key is available. In such a scenario, the shared recipient device 2605 will be unable to perform actions with the accessory until a new key is received. Instead of waiting to send a new key, the shared recipient device 2605 can send a request 2626 for the key of the accessory with a beacon UUID for a specified date interval. The owner device 2603 can perform operation 2628 to check the shared beacon record to determine whether a share exists for the beacon UUID. If no share exists, the owner device can ignore the request (2632). If a shared beacon record exists, the owner device 2603 can send a message 2630 via the IDS channel to the identity handle specified in the shared beacon record. Upon receiving the key, the shared recipient device 2605 can write the key to the key record in the file system (2634).

[0223] In one embodiment, a list of keys may be shared between the owner device 2603 and the share recipient device 2605 via a shared key record that is synchronized through a cloud data repository. The owner device 2603 may periodically generate new keys and write these keys to an encrypted key record that is synchronized with the share recipient device 2605 via a network-connected data repository.

[0224] like Figure 26C As shown, the owner or the share recipient can end sharing. If the owner stops sharing, the owner device 2603 can send an IDS stop sharing message 2640 to the share recipient device, which specifies the beacon UUID to stop sharing. Multiple attachments can be shared between the owner device and the share recipient device 2605, so sending the beacon UUID allows for clear identification of the attachment to stop sharing. Upon receiving message 2640, the share recipient device 2605 can perform operation 2642 to delete the shared beacon record and any stored key records for the identified attachment. The owner device 2603 can also perform operation 2644 to delete the shared beacon record.

[0225] If the share recipient stops sharing, the share recipient device 2605 may send an IDS stop sharing message 2646 to the owner recipient device, specifying the beacon UUID to stop sharing. Upon receiving message 2640, the owner device 2603 may perform operation 2650 to delete the shared beacon record. The share recipient device 2605 may also perform operation 2648 to delete the shared beacon record and any stored key records for the attachment.

[0226] FIG. 27A to FIG. 27B A user interface for establishing a key sharing arrangement between user accounts with respect to a wireless accessory is shown. Figure 27A A delegation UI 1903 is shown. Figure 27B Trusted UI 1906 is shown.

[0227] like Figure 27A As shown, owner device 2603 can present delegation UI 1903 to the user of the owner device. Delegation UI 1903 can be accessed from a settings or configuration menu or application associated with the wireless accessory to be shared. Delegation UI 1903 can present interface element 2701 that prompts the user whether the attachment with displayed attachment identifier 2702 should be shared. Attachment identifier 2702 can be the name or type of the attachment and / or an identifier of the attachment. Delegation UI 1903 can also present interface element 2704 that allows selection of a user with whom the attachment is to be shared. For example, a user can be selected from users in the user's contact list. A user can also be indicated by typing in an identity handle, such as an email address, a phone number, and / or another piece of information that can be used to identify the user or an account associated with the user. The trustee UI 1903 may also present a text prompt 2706 to determine the capabilities to be shared for the attachment, for example, whether the user to whom the attachment is shared should be able to map the attachment by querying the location server for the attachment (e.g., interface element 2707) or enable the attachment to play a sound (e.g., interface element 2708), such as enabling the attachment to be located within a room. If the attachment has some independent functionality, an option may also be presented to enable the trustee to command it (interface element 2709). The selected sharing capabilities may be used to determine which keys to share with the sharing recipient. The specific capabilities presented may vary depending on the type of wireless accessory. In addition, some capabilities may be default capabilities. For example, a default capability may be the ability to wirelessly detect a wireless accessory, connect to a wireless accessory, and / or place a wireless accessory in a near-owner state.

[0228] like Figure 27B As shown, the share recipient device 2605 may present a trustee UI 1906 to the user of the share recipient device. The trustee UI 1906 may include an interface element 2711 to prompt the user whether to accept the sharing of the attachment having the displayed attachment identifier 2712. The trustee UI 1906 may also present an interface element 2714 showing the capability being shared. The trustee UI 1906 may present user interface elements that allow the user to accept (interface element 2715) or reject (interface element 2716) the sharing.

[0229] Figures 28A to 28C Methods 2800, 2810, 2820 of enabling key sharing for wireless accessory devices are shown according to an embodiment. Figure 28A A method 2800 of setting up a key sharing record on a cloud data repository is shown. Figure 28B A method 2810 of sending updated keys is shown. Figure 28C A method 2820 of ending a key sharing arrangement is shown.

[0230] like Figure 28A As shown, method 2800 includes an owner device determining a share recipient and a set of capabilities delegated to the share recipient (block 2801). The owner device may then create a cloud storage record that includes an identifier (e.g., an identity handle) for the share recipient, a UUID for the beacon, and the capabilities shared with the share recipient (block 2802). The cloud storage record may be stored in a local cloud storage container, a remote cloud storage container, or a local cloud storage container synchronized with a remote container on a cloud storage device. The cloud storage record is initially marked as unaccepted. The owner device may then send a share request including the cloud storage record (or a URL to the cloud storage record) to the share recipient's device (block 2803). The share recipient may store the cloud storage record in the cloud storage device and display a UI to prompt the user of the share recipient's device. The user of the share recipient's device may accept or reject the request via the UI. The owner device may then receive an acceptance or rejection message from the share recipient (block 2804) indicating whether the share was accepted or rejected. If the share was rejected (no, block 2805), the owner device may delete the cloud storage record. The share recipient may also delete the cloud storage record in response to declining the share (2806). If the share is accepted (yes, block 2805), the owner device may mark the cloud storage record as accepted (2808). The share recipient may also mark the cloud storage record as accepted in response to accepting the share. The owner device and the share recipient may mark the cloud storage record as accepted by updating an accept field (e.g., accept field 2526) in the cloud storage record to true. In one embodiment, the share recipient may update the accept field in the cloud storage record, and the update may be automatically synchronized with the owner device via the cloud storage record sharing configured for the cloud storage record.

[0231] After the owner device marks the cloud storage record as accepted, the owner device may send the set of cryptographic keys to enable sharing for a period of time (block 2809). The set of cryptographic keys may be, for example, the trustee keys described herein. The owner device may pre-calculate keys for the upcoming period of time during which sharing will be effective. All keys for the period of time may be sent, or a subset of keys may be sent, with new keys sent every N days.

[0232] like Figure 28B As shown, method 2810 includes the owner device receiving a request for updated keys for a date interval corresponding to a beacon UUID (block 2811). A request may be received if the privacy period for keys sent to a sharing recipient has expired but the owner device has not yet had an opportunity to send a new key. The owner device may read a cloud storage record associated with the sharing arrangement (e.g., a shared beacon record) to verify the request (block 2812). If the request is invalid (no, block 2813), for example, if no cloud storage record exists for the beacon UUID, the owner device may ignore the request (block 2816). If the request is valid (yes, block 2813), the owner device may generate a shared key for the shared capability type and send it to the shared identity handle stored in the cloud storage record (block 2818). The type of key to be sent and the identity to which the key is to be sent may be determined based on the cloud storage record. Therefore, regardless of the identifier based on which the request is received, the updated key will be sent to the identity handle stored in the cloud storage record. Additionally, a sharing recipient cannot request a key for a capability that is not part of the sharing arrangement. The number of privacy windows for which keys are generated may be determined based in part on the requested date interval, but the owner device may respond with a different number of privacy windows than requested.

[0233] like Figure 28C As shown, the owner device or the sharing recipient can stop sharing. The owner device or the recipient device can receive or send a request to stop sharing the key for the beacon UUID (block 2821). The owner device and the recipient device can then delete the cloud storage record for the sharing arrangement, and the sharing recipient can delete any stored key record for the beacon UUID (block 2822).

[0234] References herein to "one embodiment" or "an embodiment" mean that the particular features, structures, or characteristics described in conjunction with the embodiment may be included in at least one embodiment of the present invention. The appearance of the phrase "in one embodiment" in various places in this specification does not necessarily refer to the same embodiment. The processes depicted in the subsequent figures may be performed by processing logic that includes hardware (e.g., circuits, dedicated logic), software (as instructions on a non-transitory machine-readable storage medium), or a combination of hardware and software. Reference will now be made in detail to various embodiments, examples of which are shown in the accompanying drawings. Many specific details are given in the detailed description that follows to provide a thorough understanding of the present invention. However, it will be apparent to those skilled in the art that the present invention may be implemented without these specific details. In other cases, well-known methods, processes, components, circuits, and networks are not described in detail so as not to unnecessarily obscure various aspects of the embodiments.

[0235] It will also be understood that, although the terms "first," "second," etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are simply used to distinguish one element from another. For example, a first contact may be named a second contact, and similarly, a second contact may be named a first contact without departing from the scope of the present invention. Both the first contact and the second contact are contacts, but they are not the same contact.

[0236] The terms used herein are intended to describe specific embodiments only and are not intended to be limiting of all embodiments. As used in the present specification and the appended claims, the singular forms "a," "an," and "the" are intended to encompass the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the terms "and / or" as used herein refer to and encompass any and all possible combinations of one or more of the items listed in association. It will also be understood that the terms "comprises" and / or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and / or parts, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, parts, and / or groupings thereof.

[0237] As used herein, the term "if" may be interpreted to mean "when" or "upon" or "in response to determining" or "in response to detecting," depending on the context. Similarly, the phrases "if it is determined that" or "if [stated condition or event] is detected" may be interpreted to mean "upon determining that" or "in response to determining that" or "upon detecting [stated condition or event]" or "in response to detecting [stated condition or event]," depending on the context.

[0238] Embodiments of electronic devices, user interfaces for such devices, and associated processes for using such devices are described herein. In some embodiments, the computing device is a portable communication device, such as a mobile phone, that also includes other functionality, such as a PDA and / or music player functionality. In the description and drawings of this application, where a wireless device, wireless accessory, or wireless accessory device is described or shown, unless otherwise indicated, the properties described or shown are generally applicable to any type of wireless device, wireless accessory, or wireless accessory device capable of broadcasting a wireless beacon.

[0239] In the foregoing description, exemplary embodiments of the present disclosure have been described. It will be apparent that various modifications may be made thereto without departing from the broader spirit and scope of the present disclosure. Accordingly, the description and drawings are to be regarded as illustrative rather than restrictive. The specific details in the description and examples provided may be used anywhere in one or more embodiments. The various features of different embodiments or examples may be combined differently with some features included and other features excluded to accommodate a variety of different applications. Examples may include subject matter, such as methods, devices for performing the actions of the methods, at least one machine-readable medium comprising instructions that, when executed by a machine, cause the machine to perform the actions of the methods, or actions of an apparatus or system according to the embodiments and examples described herein. In addition, the various components described herein may be devices for performing the operations or functions described herein.

[0240] The embodiments described herein provide a non-transitory machine-readable medium storing instructions that cause one or more processors to perform operations comprising determining a sharing recipient and a set of capabilities delegated to the sharing recipient for a wireless accessory; creating a storage record comprising fields for storing an identifier of the sharing recipient, an identifier of the wireless accessory, and a set of capabilities to be shared with the sharing recipient; sending a sharing request to a sharing recipient device; marking the cloud storage record as accepted in response to receiving an acceptance message from the sharing recipient device; and sending a set of cryptographic keys to the sharing recipient device to enable the sharing recipient device to execute the set of capabilities on the wireless accessory.

[0241] One embodiment provides a data processing system on an electronic device, the data processing system comprising a memory for storing instructions and one or more processors for executing the instructions. The instructions cause the one or more processors to: determine a sharing recipient and a set of capabilities delegated to the sharing recipient for a wireless accessory; create a storage record comprising fields for storing an identifier of the sharing recipient, an identifier of the wireless accessory, and a set of capabilities to be shared with the sharing recipient; and send a sharing request to a sharing recipient device associated with the sharing recipient. In response to receiving an acceptance message from the sharing recipient device, the one or more processors may mark the storage record as accepted, send a set of cryptographic keys to the sharing recipient device to enable the sharing recipient device to execute the set of capabilities on the wireless accessory.

[0242] One embodiment provides an electronic device comprising a wireless processor coupled to a radio component, a memory for storing instructions, and one or more processors for executing the instructions. The instructions cause the one or more processors to: determine a sharing recipient and a set of capabilities delegated to the sharing recipient for a wireless accessory; create a storage record comprising fields for storing an identifier of the sharing recipient, an identifier of the wireless accessory, and a set of capabilities to be shared with the sharing recipient; and send a sharing request to a sharing recipient device associated with the sharing recipient via the wireless processor. In response to receiving an acceptance message from the sharing recipient device, the one or more processors may mark the storage record as accepted and send a set of cryptographic keys to the sharing recipient device to enable the sharing recipient device to execute the set of capabilities on the wireless accessory.

[0243] One embodiment provides a method that includes receiving, on an electronic device associated with a sharing recipient, a request to accept sharing of capabilities associated with a wireless accessory, the request including a storage record, wherein the storage record includes fields for storing an identifier of the sharing recipient, an identifier of the wireless accessory, and a set of capabilities to be shared with the sharing recipient. The method also includes presenting an interface on a display of the electronic device to accept or deny the request, sending a message indicating acceptance of the request in response to receiving input via the interface, updating the storage record to indicate acceptance of the request, and receiving a set of cryptographic keys to enable the electronic device to perform operations associated with the wireless accessory.

[0244] From the foregoing description, those skilled in the art will appreciate that the broad techniques of these embodiments can be implemented in a variety of forms. Therefore, while these embodiments have been described in conjunction with specific examples, the true scope of these embodiments should not be so limited, as other modifications will become apparent to the skilled practitioner upon a study of the drawings, the specification, and the following claims.< / id> < / counter>

Claims

1. A method for synchronizing with a secondary device, the method comprising: Detect out-of-sync conditions with secondary devices; receiving a location report for the secondary device; determining a privacy window offset for the secondary device using the location report, the privacy window offset indicating that the secondary device is broadcasting a key that is not synchronized with the primary device; as well as A command is sent to perform a restore operation based on the privacy window offset of the secondary device.

2. The method according to claim 1, wherein the recovery operation further comprises: deriving a set of keys based on the privacy window offset; as well as The set of keys is sent to the secondary device.

3. The method according to claim 2, wherein the sending further comprises: The set of keys is sent to the secondary device via a server.

4. The method according to claim 2, wherein the sending further comprises: If the secondary device is within range, the set of keys is sent to the secondary device.

5. The method according to claim 1, further comprising: The server is requested to send location data corresponding to the location query key.

6. The method according to claim 1, further comprising: The out-of-sync condition is detected based on a failure to perform an operation on the secondary device.

7. The method of claim 1, wherein the location report includes location data, a timestamp associated with a privacy window, and a public key.

8. The method of claim 1, wherein the out-of-sync condition comprises: An indication is received that the secondary device is broadcasting a key that is out of sync with a key derived at the primary device using cryptographic material.

9. The method according to claim 1, wherein the recovery operation comprises: A request is sent to update a counter of the secondary device.

10. A non-transitory machine-readable medium storing instructions that cause one or more processors to perform the operations of the method of any one of claims 1 to 9.

11. A data processing system on an electronic device, the data processing system comprising: a memory storing instructions; One or more processors, the one or more processors being configured to execute the instructions, wherein the instructions cause the one or more processors to perform the method according to any one of claims 1 to 9.

12. A computer program product comprising a computer program comprising instructions which, when executed, cause one or more processors to perform the method according to any one of claims 1 to 9.

Images