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 on April 17, 2019 and U.S. Provisional Patent Application Serial No. 62 / 856,020 filed on June 1, 2019, each of which is hereby incorporated by reference herein. Technical Field

[0004] Embodiments described herein generally relate to systems and methods for locating wireless devices and accessories. More specifically, 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 a 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. Typically, wireless devices are used with wireless accessory devices whose location cannot be determined and cannot communicate with a 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 communications (e.g., smart watches, fitness bands, optical head-mounted displays). When wireless accessory devices whose location cannot be determined and cannot communicate with a 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, the 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, the 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, the method comprising receiving a request on an electronic device associated with a sharing recipient to accept sharing of capabilities associated with a wireless accessory, the request comprising a storage record, wherein the storage record comprises 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 comprises presenting an interface on a display of the electronic device to accept or deny the request, in response to receiving input via the interface, sending a message indicating acceptance of the request, 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 according to an embodiment is shown;

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

[0015] FIG. 4A to FIG. 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] FIG. 6A to FIG. 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] 9A to 9C showing a device locator user interface according to an embodiment;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0035] Fig.24 is a diagram showing 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] FIG. 26A to FIG. 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] FIG. 28A to FIG. 28C A method of enabling key sharing for a wireless accessory device according to an embodiment is shown. DETAILED DESCRIPTION

[0040] Embodiments described herein provide techniques for enabling secure crowdsourced locator services 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. Many specific details are described to provide a comprehensive understanding of 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 of "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 grouping.

[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 may be executed on the device may use at least one common physical user interface device, such as a touch-sensitive surface. One or more functions of the touch-sensitive surface and corresponding information displayed on the device may be adjusted and / or varied from one application to the next, and / or may be adjusted and / or varied within a corresponding application. In this way, the common physical architecture of the device (such as a touch-sensitive surface) may support a variety of applications with an intuitive and transparent user interface.

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

[0044] Figure 11 is a block diagram of a network operating environment 100 for a mobile device according to an embodiment; the network operating environment 100 includes a plurality of mobile devices, such as a mobile device 102A and a mobile device 102B. The mobile devices 102A-102B may 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, smart phones, tablet computers, notebook computers, wearable computers (e.g., smart watches or other wearable computing accessories), mobile media players, personal digital assistants, and other similar devices. Each of the mobile devices 102A and 102B includes a user interface, such as a user interface 104 of the mobile device 102B. The mobile devices 102A and 102B may communicate via one or more wired and / or wireless networks 110 to perform data communications. For example, a wireless network 112 (e.g., a cellular network, a Wi-Fi network) may communicate with a wide area network 114 (such as the Internet) using a gateway 116. Similarly, an access device 118, such as a mobile hotspot wireless access device, may provide communication access to the wide area network 114. The gateway 116 and access device 118 may then communicate with the wide area network 114 via a combination of wired networks and / or wireless networks.

[0045] In some implementations, both voice communications and data communications can be established through 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, through 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 through 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 a 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 telephone 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, telephone services 130 can enable telephone communications between mobile device 102A and mobile device 102B or between a mobile device and a wired telephone device. Telephone services 130 can route voice over IP (VoIP) calls through 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 device 102A and mobile device 102B to store documents and media files. The device locator service 170 may enable a user to locate a lost or misplaced device that was connected to one or more wired and / or wireless networks 110 at least at a certain point in time. For example, the mobile device 102A may perform a location query for the 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 software update services 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 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 is unable to access a wide area network is shown according to an embodiment. The system 200 can also be used to locate devices that are unable to access a WAN or LAN and therefore cannot transmit the device location. 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 a game controller or remote control. In one embodiment, the wireless accessory 201 also includes a smart phone, a tablet computer, a laptop computer, a smart speaker device, a television, or a device that is at least temporarily unable to access a wide area network such as the Internet (e.g., such as a headset). 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 smart watch device or a wearable display.

[0048] In one embodiment, the wireless accessory 201 can periodically transmit a wireless beacon signal. The 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 optional wireless technologies, or multiple simultaneous wireless technologies. The beacon signal can transmit a beacon identifier that includes information that specifically identifies the 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, 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 state by the owner of the device. The alarm state may indicate that the wireless accessory 201 is placed in a state in which the device should trigger an alarm if the device moves from its current location. The near-owner status may indicate that the wireless accessory 201 has detected that a mobile device 102 associated with the owner of the accessory is present nearby.

[0050] The beacon signal can be detected by a detector device 202 that is locally near the wireless accessory 201. The detector device 202 can be a device similar to the mobile device 102 and can receive and transmit data through the wide area network 114, using wireless technology similar to the wireless accessory 201 (e.g., Bluetooth, etc.) for reception and transmission. Specifically, the detector device 202 can receive data using a wireless protocol through which the beacon signal is transmitted. The detector device 202 can determine the location using one or more location and / or positioning services, including but not limited to satellite positioning services 206 or terrestrial positioning systems that use RF signals received from wireless base stations 205 (such as Wi-Fi access points or cell tower transmitters of cellular telephone networks). In one embodiment, the detector device 202 periodically stores its location determined based on one or more location and / or positioning services. The stored location can be associated with a timestamp for which the location is determined. When the detector device 202 receives a beacon signal from the wireless accessory 201, the detector device 202 can transmit the location of the detector device to the device locator server 203 through the wide area network 114. The timestamp used to determine the location of the probe device 202 can be associated with the timestamp of receiving the beacon signal to associate the geographic location with the received beacon signal. In one embodiment, the wireless accessory 201 includes a location determination capability via an integrated satellite positioning service (e.g., GPS) receiver. If the wireless accessory cannot access a network to send a location to the device locator server 203, the wireless accessory can encode the 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] In the event that the wireless accessory 201 provides a public key within the beacon signal, the probe 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 of the wireless accessory 201 from the probe device 202 and assist in triangulation on the owner's device. In the event that the RSSI data is transmitted in an unencrypted state, 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 place the encrypted location data in a queue 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 the 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 the mobile device 102. The device locator UI 204 may be associated with a device locator application that is used to locate electronic devices and accessories registered to a user's online account (such as a cloud service account or another type of online account). The device owner may use the device locator UI 204 to query the device locator server 203 for location data that may have been transmitted to the device locator server by the detector device 202 of the wireless accessory 201. In one embodiment, the mobile device 102 may transmit a public encryption key associated with the wireless accessory 201 to the device locator server 203. The device locator server 203 may then return any stored location data corresponding to the public encryption key. The location data returned to the mobile device 102 may be encrypted data encrypted by the detector device 202 using the public encryption key. The mobile device 102 may decrypt the encrypted location data using the associated private key. The decrypted location data is then processed by the mobile device 102 to determine the most likely location of the wireless accessory 201. In various embodiments, the most likely location of 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 may present an accessory pairing UI 302 through which the user may pair the mobile device 102 with the wireless accessory 201. During the initial pairing (305) between the mobile device 102 and the wireless accessory, a public key exchange (310) may 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 in 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 a public key in a public / private key pair to the wireless accessory 201. In addition or alternatively, the public key exchange (310) may 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 a 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 the 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 a 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 including 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 a 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 a 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 an anti-tracking secret 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 used 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 period of time i. i If the wireless accessory 201 is compromised, only the λ for the current and future values ​​i are exposed. i In one embodiment, reverse tracking resistance is achieved by periodically changing λ i The 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 can be used with respect to Figure 15 to Figure 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, but 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 the 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 stop the transmission of locator beacon signals, but other types of wireless signal transmissions can continue to exist. The wireless accessory 201 can remain in the 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 device 202 of the present invention may be a variant of the detector device 202 and may determine similar location determination techniques. For example, the detector device may perform operations (320) to associate a beacon signal 301 received from the wireless accessory 201 with a device location associated with the detector device. Figure 2The device location can be determined via a satellite positioning service or a terrestrial positioning system utilizing RF signals received from a wireless base station (e.g., a Wi-Fi access point or a cell tower transmitter). In one embodiment, the set of detector devices 303 may also include fixed devices, such as a smart speaker device, a television, or a television set-top box that can receive the beacon signal 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 beacon identifier / public key of the attachment can be sent along with the encrypted location data. The encrypted location data can be stored in a database node based on the hash of the beacon identifier. The encrypted location data can be indexed by the device locator server 203 using the hash of the beacon identifier. Sending a hash of the beacon identifier instead of the complete beacon identifier prevents the complete beacon identifier from being stored in the server. Other information can also be sent and stored along with the location data in an encrypted or unencrypted state. Other information may include a timestamp for when the beacon signal 301 is received, RSSI information for the received beacon, and / or ranging information determined, for example, via UWB ranging.

[0064] When a user or owner of wireless accessory 201 wishes to locate the accessory, the user or owner may access device locator UI 204 on mobile device 102. Device locator UI 204 may be associated with a device locator application or feature of mobile device 102. Device locator UI 204 may also have a web-based interface accessible from mobile device 102 or another type of electronic device, such as a laptop or desktop device. Upon loading device locator UI 204, mobile device 102 may send a request (330) for location data to device locator server 203. Request 330 may include a set of public key hashes that may be used as beacon identifiers for beacon data. Mobile device 102 may generate this set of public keys based on secret information held by mobile device 102 and wireless accessory 201 and a timestamp at which 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 previous 24 hours of public keys in the request 330. If no 24 hours of 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] The encrypted location data is stored and indexed based on a hash of the public key rather than the public key to prevent the provider of location service data from storing data that can be used to associate the encrypted location data with a specific device, and thus with a specific user or user account. The detector device sends a hash of the public key broadcast in 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 viewing the location data through the web-based interface. Prior to displaying the location data 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, the 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 loss mode. In light loss 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 sends the location of the wireless accessory in light loss mode can be directed by the device locator server 203 to relay a message to the wireless accessory 201 that notifies the wireless accessory that it is in light loss mode. A similar mechanism can also be used to relay a message to the wireless accessory 201 that places the accessory in explicit loss mode. The user can enable explicit loss mode via the device locator UI 204. In explicit loss mode, the wireless accessory 201 cannot be paired with another device unless the owner unlocks the wireless accessory.

[0068] FIG. 4A to FIG. 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 a 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). A variety of 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 can 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 can then register the wireless accessory with a device management server (block 405). Registering the wireless accessory with the device management server can form an association between the wireless accessory and the cloud service account to which the mobile device is associated. The device management server can 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 of the electronic device launching a device locator UI (box 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 included in the beacon signal broadcast by the wireless accessory during the first time period (box 412). The first time period may be, for example, the previous 24 hours. The electronic device knows the frequency of the wireless accessory generating or rotating to a new public key, and using the shared secret generated with the wireless accessory, a set of public keys corresponding to the keys generated by the wireless accessory during the first time period can be generated. The electronic device can then send the set of public keys in a request to request the device locator server to send location data corresponding to the set of public keys (box 413). In one embodiment, the location data sent by the server in response to the request will be encrypted using the public key transmitted as the beacon identifier of the wireless accessory. The electronic device can use the private key generated during the initial pairing with the wireless accessory to decrypt the encrypted location data received by the server (box 414). The electronic device can then process the location data to determine the highest probability location of the wireless accessory (box 415).

[0073] Processing the 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 Fig.10 is 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 an electronic device in response to a request. The electronic device can generate a first set of public keys included in a beacon signal broadcast by a 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 (box 423, "No"), the electronic device can generate a second set of public keys included in a beacon signal broadcast by the wireless accessory during a second time period (box 424). The second time period can be 24, 48, or other 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 (box 425). If the server returns data in response to the request (box 426, "Yes"), the method 420 can proceed to box 429, where the electronic device decrypts the received data. If the server does not return data (box 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 (box 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 5. 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 sent 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 the beacon, where the value of M can vary between implementations and / or based on the 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 time period (box 508). Although the wireless accessory has not yet entered a new key time period (box 508, "No"), the accessory can continue to send beacons using the current public key (box 510). When the wireless accessory detects that it has entered a new key time period (box 508, "Yes"), the accessory can derive a new public key using the current timestamp (box 509). In one embodiment, the new public key can be derived using an existing public key, a timestamp, and an anti-tracking secret.

[0079] FIG. 6A to FIG. 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 Fig. 6A As shown, method 600 includes the detector device performing periodic beacon scans using a wireless baseband processor when an 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 in an active state, beacon scans can be performed by the wireless processor and the radio device receiver as a low power operation 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 to 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] The method 600 also includes the probe device performing periodic Wi-Fi scans using the wireless processor while the application processor is in a low power mode (block 603). Although the Wi-Fi scans may also be performed while the application processor is active, the Wi-Fi scans may be performed by the wireless processor and the radio device receiver as a low power operation when the probe device is idle, inactive, or otherwise in a low power state. The probe device may then store a Wi-Fi service set identifier (SSID) and a scan timestamp to 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 recently detected SSIDs while overwriting earlier detected SSIDs. In one embodiment, the beacon scan buffer can be a fixed size buffer that has room 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 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, signal strength and ranging data (e.g., UWB ranging data) may be collected. 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 with the location data, or may be sent unencrypted 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 a plurality of 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 the probe device may transmit the data to a cloud service server (block 612). The encrypted data may be sent along with a hash value of a beacon identifier corresponding to the encrypted location.

[0084] Figure 7 202 can also represent multiple detector devices, such as a plurality of detector devices, such as a plurality of detector devices, such as a plurality of detector devices, and ... and a plurality of detector devices, such as a plurality of detector devices, and a plurality of detector devices, and a plurality of detector devices, such as a plurality of detector devices, and a plurality of detector devices, and a plurality of detector devices, such as a plurality of detector devices, and a plurality of detector devices, and a plurality of detector devices, such as a plurality of detector devices, and a plurality of detector devices, and a plurality of detector devices, and a plurality of detector devices, such as a plurality of detector devices, and a plurality of detector devices, and a plurality of detector devices Figure 3303 in which each detector device detects beacon signals at a different location. Each detector device 202 may send 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, UWB ranging 706 may be performed if the detector device and the wireless device are within range of the UWB transmission. The UWB ranging and signal strength data may 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, which in one embodiment is provided in the form of latitude and longitude information, and 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 according to an embodiment is shown. 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 via 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 of the cloud service provider's account associated with the mobile device 102 and the detector device 303. The database cluster manager 813 can configure the database cluster nodes 823A to 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 series 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 a 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 to 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, the embodiment is not limited to any particular number of nodes, and more or fewer nodes can be used.

[0090] 9A to 9C A device locator UI 204 is shown according to an embodiment. Fig. 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. Fig. 9B A second graphical user interface of the device locator UI 204 is shown that enables a wireless accessory to be set to an alert mode, according to one embodiment. Fig. 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 Fig. 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 a variety of 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 may include a map 901 with a mark 902, which shows the current or last known location of the wireless device or accessory. The mark 902 can be an icon, image, graphic, or any other user interface element that identifies the accessory and conveys the location of the accessory. The optional element 903 in the device locator UI can present a description or name of the wireless device or accessory, and can show the estimated distance between the current location of the wireless device or accessory and the electronic device 900.

[0092] like Fig. 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 Fig. 9A 903 shown in . The second user interface can present a user interface element 904 representing and / or describing the wireless accessory under consideration, 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 an alert mode. When in the 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 beacon signal of the wireless accessory, which indicates 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 be optionally triggered by the mobile device 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. In one embodiment, the alarm can be optionally 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 Fig. 9CAs shown, the device locator UI 204 may 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 mark indicating the location of the accessory. The device locator UI 204 may present a user interface element 904 representing and / or describing the wireless accessory under consideration and a set of optional user interface elements. An optional user interface element 906 may present an option for notifying the user when the accessory is found. When notification when discovery is enabled, in one embodiment, the wireless accessory may be placed in a light lost mode. An electronic device associated with the device locator UI 204 may generate a set of public keys, and the wireless accessory will broadcast this set of public keys together 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 may 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 an 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 required 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, the 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] Fig.10 302 is shown when attempting to pair with a lost wireless accessory according to an embodiment. Fig. 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 shown in FIG. Fig.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, as well as user interface elements 1006, such as buttons, that enable electronic device 1000 to contact the requesting user by using the provided contact information 1004.

[0098] Embodiments described herein include one or more application programming interfaces (APIs) in an environment, wherein the 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 there may be more than one such component. An API may be a source code interface provided by a computer system or a program library to support service requests from an application. 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 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 may 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 implementation component. For example, the API calling component accesses the specified features of the API implementation component through one or more API calls or references exposed by the API (for example, implemented by function or method calls), and uses parameters to pass data and control information via API calls or references. The API implementation 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 (for example, how to cause API calls and what API calls 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 call (API calling component) and the API implementation 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 implementation component. Function calls or other references of the API can send or receive one or more parameters through parameter lists or other structures. A parameter may 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 referencing 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, API can be used to access the services or data provided by the API implementation component, or to start the operation or calculation provided by the 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 the services provided by the software development kit (SDK) library. In other embodiments, the application or other client programs can use the API provided by the application framework. In these embodiments, the application or client program can be combined with the call to the function or method provided by the SDK and provided by the API, or use the data type or object 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 the application to specify events and responses to events using the application framework. In some specific implementations, 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 through the API via a network. It should be understood that the 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 the API calling component can also act as an API implementing component by implementing APIs exposed to different API calling components.

[0105] The API may allow multiple API-calling components written in different programming languages ​​to communicate with the API-implementing component (so that the API may include features for converting 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 provider of a software library) or a creator of another set of APIs.

[0106] Fig.11 is a block diagram illustrating an exemplary API architecture that may be used in some embodiments of the present invention. Fig.11 As shown in , the 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. The 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. The 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. The API calling component 1130 (e.g., an operating system, library, device driver, API, application, software, or other module) makes an API call through the API 1120 to access and use the features of the API implementation component 1110 specified by the API 1120. The API implementation component 1110 can return a value to the API calling component 1130 through the API 1120 in response to the API call.

[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 located remotely and access the API implementing component 1110 using the API 1120 over a network. Fig.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 different from the API calling component 1130 that may be written in a different language (or the same language) 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 disk, an optical disk, a random access memory, a read-only memory, a flash memory device, etc.

[0109] Fig.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 may be coupled via one or more communication buses or signal lines. The various components may be separate logic components or devices or may be integrated in 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 may be coupled to the peripheral device interface 1206 to facilitate multiple functions. For example, a set of sensors 1210 (including a motion sensor 1211, a light sensor 1212, and a proximity sensor 1214) may be coupled to the peripheral device interface 1206 to facilitate mobile device functions. There may 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 may also be connected to the peripheral device interface 1206, such as a positioning system (e.g., a GPS receiver), a temperature sensor, or other sensing devices to facilitate related functions.

[0112] The 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 a complementary metal oxide semiconductor (CMOS) optical sensor) may be utilized to facilitate camera functions, such as taking pictures and video clips. An audio subsystem 1226 may be coupled to a speaker 1228 and a microphone 1230 to facilitate voice-enabled functions, such as voice recognition, voice replication, digital recording, and telephone functions. In the smart media devices described herein, the audio subsystem 1226 may be a high-quality audio system including support for virtual surround sound.

[0113] Communication functions 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] I / O subsystem 1240 may include touch screen controller 1242 and / or other input controller 1245. For computing devices that include a display device, touch screen controller 1242 may be coupled to a touch-sensitive display system 1246 (e.g., a touch screen). Touch-sensitive display system 1246 and 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 touch-sensitive display system 1246. Display output of touch-sensitive display system 1246 may be generated by display controller 1243. In one embodiment, display controller 1243 may provide frame data to 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, light sensor 1212, proximity sensor 1214, or other sensor 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 may 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 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 specific 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 processing and functions; phone instructions 1260 to facilitate processes and functions related to phone calls; instant messaging instructions 1262 to facilitate processes and functions related to electronic message processing; web browsing instructions 1264 to facilitate processes and functions related to web browsing; media processing instructions 1266 to facilitate processes and functions related to media processing; location service instructions including GPS and / or navigation instructions 1268 and Wi-Fi-based location instructions to facilitate location-based functionality; camera instructions 1270 to facilitate processes and functions related to cameras; 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 processes and functions related to web videos; and / or web shopping instructions to facilitate processes and functions related to web shopping. In some specific implementations, the media processing instructions 1266 are divided into audio processing instructions and video processing instructions to facilitate processes and functions related to audio processing and processes and functions related to video processing, respectively. 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. In addition, various functions may be performed in hardware and / or software, including in one or more signal processing and / or application specific integrated circuits.

[0121] Fig.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 appliance, or one or more specific implementations of an intelligent media playback device. Alternative computing systems may include more, less 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., bus, architecture) 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 a memory 1320 in the form of a random access memory (RAM) or other dynamic storage device coupled to the interconnect 1335. The memory 1320 may store information and instructions that may be executed by the processor 1310. The memory 1320 may also be a 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 a variety of 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 to display 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 options to the processor 1310. Another user input device includes a cursor control 1370 device, such as a touch pad, 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 a communicatively coupled remote device 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. 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 may provide access to a local area network, for example by complying with the IEEE 802.11 wireless standard, and / or the wireless network interface may provide access to a personal area network, for example by complying with 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 may 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] The computing system 1300 may also include one or more power supplies 1305 and one or more energy measurement systems 1345. The 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 includes at least one voltage or current measurement device that can measure the energy consumed by the 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 consumption subsystems.

[0128] Wireless accessory location and communication encryption

[0129] Fig.14 A system 1400 is shown for cooperatively 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 31402 and the public key exchange 310 is a variation of the initial pairing 305 and public key exchange 310 shown in the system 300 of , wherein the initial pairing 1405 is performed through 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. In addition, although the wireless accessory 1430 is shown and described, the device location functionality described herein can be applied to any electronic device without an independent network connection to allow the device to update its location at a device location server and using at least one radio component capable of broadcasting a beacon signal 1431.

[0130] Collaborative key generation can begin after the initial pairing 1405 performed through the secure session. In one embodiment, the initial pairing can be performed through an NFC initiated Bluetooth connection. The 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 for generating cryptographic material for locating the wireless accessory 1430.

[0131] Key Hierarchy for Collaborative Key Generation

[0132] Fig.15 A key hierarchy 1500 for the encryption scheme described herein is shown. The key hierarchy includes three groups of keys. The first group of keys is stored on the owner and accessory devices. The second group of keys is stored on the owner device. The third group of keys is stored on the owner device and any potential trustee devices. Each group of keys can be securely stored on the corresponding device, where the keys are encrypted during storage. In one embodiment, the first group of keys is maintained in a storage object 1510, which is stored to the owner device key store and non-volatile memory of the accessory device. The first group of keys includes public keys 1511, secret keys 1512, and derivatives of these keys. The second group of keys includes device keys 1520 stored only on the owner device. The third group 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 location data of the attachment. Public key 1511 cannot be used directly because direct use of the public key may allow an observer to track the attachment. Therefore, a diversified location encryption key 1515 is derived based on 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 keys 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 owner command keys 1517. Anti-tracking secrets 1516 are used to derive diversified location encryption keys 1515, which are broadcast by the attachment device and used to encrypt the location of the attachment device uploaded by the detector device to the positioning server. The set of diversified location encryption keys 1515, anti-tracking secrets 1516 and owner keys also include 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 secrets 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 are 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] Fig.16 1602 may be an owner device, such as a secondary device 1630. Fig.14 The user device 1402 in , or an equivalent device described herein. The secondary device 1630 may be, for example Fig.14 The wireless accessory 1430 or an equivalent device described herein.

[0137] During collaborative key generation, the primary device 1602 and the secondary device 1630 collaboratively generate a key pair {d, P} and a secret key SK. During this process, the secondary device 1630 cannot learn the private key d, and neither device can bias P or SK. The collaborative key generation process also prevents the primary device 1602 from fully controlling the secret key SK and the key pair {d, P}, which an attacker can extract from one device to 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, the secondary device 1630 may generate a P-224 elliptic curve scalar value s and a random value r during operation 1612B. During operation 1612A, the primary device 1602 may generate a P-224 elliptic curve scalar value s′ and a 32-byte random value r′. The primary device may additionally calculate a value S′=s′·G, where G is an elliptic curve generator parameter.

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

[0141] Then, the primary device 1602 and the secondary device 1630 may perform operations 1616A-1616B to calculate the shared secret data based on the combined random data. The secondary device 1630 may calculate P=S′+s·G. The primary device 1602 can confirm that commitment=Hash(s||r). The primary device 1602 can also calculate d=s′+s(mod q) 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 can calculate the 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 can derive key material based on the shared secret in operations 1617 and 1618. In operation 1619, the primary device 1602 can store the key material in a key store, such as a shared cloud key store. The secondary device 1630 can store the key material in 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. For example, for a privacy window of 15 minutes, N=900. The owner device can derive SK i , by setting or Among them, UT lookup is the time corresponding to the period for which position reports should be retrieved, UT now is the current time, and UT delegate It 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 SK for j=0, ..., i-1 0 =SK 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 the diversified secret key SK i , can generate owner command key OK i and anti-tracking secret AT i In one embodiment, OK i =KDF(SK i In addition, ATi =(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] Diversified public key P i is a diversified version of the public key P. P can be derived without knowing the private device key d i , 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 G. In one embodiment, u is generated in accordance with FIPS 1 86-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] Diversification 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 main device 1602 and the trustee can use P i The location of the secondary device 1630 is queried at the positioning server.

[0146] Intermediate Key IK i =KDF(SKi The “intermediate” key may 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) may 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 LTK i is a 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] Fig.17 1 is a flow chart of a process of 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 command key CK may be used in part to 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 storing a reduced number of elliptic curve coordinates. In one embodiment, the derived key is a compact representation x(Pi), where |x(Pi)|=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 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 =MostSignificant6Bytes(MAC(CK i ,x(P i )||“NearOwnerAuthToken”))

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

[0156] Connection and Command Tokens

[0157] Fig.18 1 is a flow chart of a process for connecting to and commanding a secondary device according to an embodiment. The process may 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.

[0158] 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 a nearby secondary device and place the secondary device in a nearby owner mode, as described above with respect to Fig.17 described.

[0159] 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:

[0160] ConnectionAuthToken i =MostSignificant6Bytes(MAC(CK i ,x(P i )||"ConnectionAuthToken"))

[0161] In the above formula, MAC refers to the message authentication code. The secondary device can use ConnectionAuthToken i Placed into the wireless controller lookup table. The primary device can get the ConnectionAuthToken from 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 i Establish 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.

[0162] 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. i For this type of command, the owner device can send the command to the secondary device via the following command:

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

[0164] 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.

[0165] In one embodiment, the secondary device may determine the validity of a command based in part on an 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.

[0166] Delegating functions to a trustee device

[0167] Fig.19 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 locating device server 203 as described herein. Wireless accessory 1430 can also be a variation of wireless accessory 201 as described herein. Fig.16 Generic secondary device 1630 is shown.

[0168] The user of the owner device 1402 via the delegation UI 1903 can delegate all or a subset of the ownership features to the trustee device 1904 via the transmission 1905 of the trustee key. The owner device 1402 can generate a privacy window for a predetermined number of privacy windows. Fig.15 The trustee device 1904 may be provided with keys from the third set of keys (owner keys and trustee keys) shown and those keys may be provided to the trustee device 1904 via transmission 1905 of the trustee keys to perform delegation. 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 .

[0169] 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 Fig.15 , location query and decryption key 1522 may be delegated to enable the trustee to perform location query and decryption of the secondary device location. Delegation of intermediate key 1524 may enable the trustee to derive status byte key 1525, command key 1526, and connection key 1527. Alternatively, individual functions may be delegated by providing individual keys.

[0170] Fig. 20 1 is a flow diagram of a process of delegating functionality to a trustee device according to an embodiment. In one embodiment, the owner device 1402 may 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 may 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 may be determined at least in part based on a specific key generated and provided to the trustee device.

[0171] Then, the trustee device 1904 may 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 a cryptographic verification to ensure that the key defines a valid elliptic curve point.

[0172] Then, the trustee device 1904 may perform operation 2005 to derive additional cryptographic material for communicating with the secondary device attachment 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 delegated.

[0173] Then, the trustee device 1904 can perform operation 2006 to detect beacons, query locations and / or communicate with secondary devices via derived and / or delegated derived keys. 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 keys. The delegated functions are only effective for privacy windows that provide keys. In one embodiment, some command functions cannot be delegated. For example, unpairing and re-pairing can be limited to owner devices and cannot be delegated.

[0174] In one embodiment, the functionality that may be delegated includes the ability to track or find a secondary device. The 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 positioning server during the delegated period, but the trustee may be able to locate the device if the device 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 an associated child account. In one embodiment, the ability to remove a secondary device based on a "lost" status may be delegated.

[0175] 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 a user of a device when a secondary device that is not owned or delegated to the primary device appears to be following the primary device, for example, when a secondary device that is not owned or delegated is continuously detected, particularly when in motion. In such embodiments, the primary device may be configured to notify the user of the continued 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, there may be scenarios where a beacon secondary device may reasonably follow the user. For example, a secondary device 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.

[0176] Minor device recovery

[0177] FIG. 21A to FIG. 21B Methods 2100, 2110 for recovering an out-of-sync secondary device according to an embodiment are shown. 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 counter of the secondary device may resume incrementing. As a result, the counter on the secondary device used to generate a key for each privacy window may lose synchronization with the primary device. To recover an out-of-sync secondary device, the primary device may determine the current counter value of the secondary device, resynchronize with the privacy window of the secondary device, and then recover the secondary device by resetting the secret key stored on the device. Fig.21A A method 2100 of resynchronizing a privacy window with an out-of-sync secondary device is shown. Fig.21B A method 2110 of restoring a secondary device after resynchronizing to a privacy window of the secondary device is shown.

[0178] like Fig.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.

[0179] At any time when a secondary device is repowered 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 record 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. Depending on the configuration of the device positioning server, these requests may be batched or continuous.

[0180] In one embodiment, the primary device may perform operation 2102 to request a 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 from a current privacy window and extends back to a 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 a past location of the secondary device and a timestamp of the location report.

[0181] 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 of a timestamp associated with the received location report and a counter associated with the privacy window of a key used to encrypt the location report data. For example, if the 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 3K based on the adjusted counter. recovery . Can be based on SK recovery Derive a derived key for the second set of keys.

[0182] The primary device may then perform operation 2107 to determine whether a nearby secondary device has been detected via a key by the second set of keys. If no secondary device is detected nearby, the primary device may perform operation 2108 to request a device locator server to send updated location data corresponding to a location query key in the second set of keys, which may enable a 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 in the second set of keys (e.g., a connection key and / or a command key). The operation of recovering the secondary device may include transmitting a new secret key to the secondary device and / or resetting a counter on the secondary device.

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

[0184] The primary device can update the wireless controller lookup table to search for the MostSignificant6Bytes(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 Fig.17 described.

[0185] In one embodiment, the primary device and the secondary device may optionally perform operation 2113 to re-run the Fig.16 Re-running the collaborative key generation process may 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 device while the secondary device was powered off. The primary device may then perform operation 2114 to store the updated diversified secret and / or key to the secondary device. The updated diversified secret may be based on the regenerated key material (e.g., P, SK, d). The primary device may also re-generate the key material by providing a new SK NVM The primary device may also perform operation 2115 to command the secondary device to reset one or more counters. For example, the internal time of the secondary device may be reprogrammed during the restoration.

[0186] In some embodiments, the hash functions described herein may utilize dedicated hardware circuitry (or firmware) of a system (client device or server). For example, the function may be a hardware accelerated function. Additionally, in some embodiments, the system may use functions that are part of a dedicated instruction set. For example, the system may use an instruction set that may be an extension of an 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 are performed using these instruction sets.

[0187] Computing system with a secure processor

[0188] Fig. 22 A computing system 2200 including a security processor according to an embodiment is shown. In one embodiment, the security processor 2203 shown includes logic for accelerating cryptographic operations 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.

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

[0190] The security processor 2203 may 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 may 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 may also be coupled to the ROM 2213, which may be trusted software capable of verifying 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.

[0191] The security processor 2203 may also include a cryptographic accelerator such as a cryptographic accelerator 2207, which may 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 storing a device identifier or a set of device identifiers and a set of one or more certificates and private keys in a secure manner, which in one embodiment are hidden from the rest of the system and cannot be read by the rest of the system. The cryptographic accelerator 2207 may access private keys and other data within the memory 2205, and does not allow components outside 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 cryptographic operations performed by the cryptographic accelerator 2207. The application processor 2221 may 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 component, an NFC radio component, a Wi-Fi radio component, etc. Other input and output devices may be included. The application processor 2221 is also coupled to an application processor ROM 2225, which provides software for starting the application processor. Similarly, the ROM 2213 provides code to start the security processor kernel 2215 within the security processor 2203.

[0192] Trustee Key Sharing System

[0193] Fig.23 A system 2300 for enabling sharing of trustee keys via a cloud storage system is shown. The system 2300 includes a network 114 that enables 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 a wireless accessory. The owner device 1402 and the trustee device 1904 can configure a key sharing arrangement through which pre-computed trustee keys can be shared. The system 2300 also includes a network-connected data repository 2313 that can be used to store records of the key sharing arrangement, and an identity server 2320 that enables the owner device 1402 and the trustee device 1904 to be located via the network 114 using an identity handle of an account associated with the device. Although the network 114 is a wide area network, such as the Internet, communication between the owner device 1402 and the trustee device 1904 can also occur over a local network.

[0194] 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 device 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 of each device can be associated with an online user account associated with the device.

[0195] 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 a user or an account associated with a user. Using a handle associated with a user or user account, a mobile device can obtain information that allows the mobile device to contact a set of mobile devices associated with the handle, such as a push token. In one embodiment, the identity server 2320 can also act as a message relay between the owner device 1402 and the trustee device 1904.

[0196] 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 a virtualized network storage device. 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.

[0197] 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 relay 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 trustee 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.

[0198] Fig.24 2400 is a diagram showing 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 instance 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 part of a local area network or 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.

[0199] The first device 2402, the second device 2404, and the third device 2406 may each be, but not limited to, a mobile device, and may represent any one of 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 be additionally coupled to many other devices associated with one or more different users or different user accounts.

[0200] In one embodiment, a device may be associated with a corresponding user or user account 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, a key or device identifier for a first device 2402 and a second device 2404 may be associated with a key or account identifier for a user or user account 2412. A key or device identifier for a third device 2406 may be associated with a key or user account identifier for a user or user account 2414. Such associations may be used to allow authenticated access to account-based storage on a remote storage location 2408.

[0201] 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.

[0202] Remote storage location 2408 includes independent logical containers for storing data from different user / user accounts and application combinations. In some examples, the logical container can be a directory, data structure, database, or another data organization unit in a file system. For example, a first user or user account 2412 may 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 may have a container 2418 for a corresponding application. Application data items received from each device (e.g., first device 2402) are stored in a corresponding container for the application. Remote storage location 2408 may include a storage manager that can create and manage containers and generate notifications for devices.

[0203] 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.

[0204] 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 corresponding applications. Access manager 2424 applies one or more access policies to determine which data items will be visible to specific applications in applications 2420.

[0205] 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.

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

[0207] like Fig.25A As shown, storage container 2502 includes shared database 2504 and private database 2506, which are storage locations for shared data and private data, respectively. Shared database 2504 includes data shared with an account associated with the storage container. Such data can be encrypted using a key generated based on a secret shared between users with legal access to sharing. The 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. The data in private database 2506 shared with other users can be stored in the shared database 2504 of these users.

[0208] The data in 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 for zones is not limited to any specific 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 in these zones.

[0209] Each zone may include multiple records. For example, zone 2508 may include multiple records 2510A-2510N. In one embodiment, each record 2510A-2510N may store a set of fields, each of which may contain various types of data, such as strings, numbers, dates, locations, references, or files. Zone 2509 may store records in a manner similar to zone 2508.

[0210] 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 zones (e.g., zone 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 the share 2512. In one embodiment, the zone 2511, the share 2512, and the record 2514 can be encrypted separately.

[0211] like Fig.25B As shown, the record 2510 in area 2508 can be a shared beacon record for storing a record of a shared arrangement. The record 2510 can represent any one of a plurality of records 2510A-2510N. The 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. The record 2510 can be shared with a sharer / trustee by the owner of the wireless accessory via a data repository of the connection network described herein (e.g., the data repository 2313 of the connection network).

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

[0213] 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, Fig.15 , the ability to query the device locator server for the location of the accessory can be granted by sharing the location query key and decryption key 1522. The ability to decode status byte information (e.g., battery level, device status, etc.) can be delegated via the status byte key 1525. The ability to connect to the accessory and issue commands to the accessory can be granted by sharing the command key 1526 and the connection key 1527. In one embodiment, the 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 location of the accessory to view the accessory on a map.

[0214] Accepted field 2526 may 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 may 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 may update their instance of record 2510 to accepted.

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

[0216] like Fig.26A As shown, the owner device 2603 may send a sharing request to the share recipient device 2505. The owner device 2603 may be, for example, the owner device 1402, and the share recipient device 2605 may be the trustee device 1904. The 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 the share recipient device 2605.

[0217] The owner device 2603 can perform operation 2602 to start sharing a beacon (eg, a wireless accessory) to the identity handle <id>, the identity handle identifies the sharing recipient device 2605 and / or the user account associated therewith. Then, the owner device 2603 performs operation 2604 to create a sharing beacon record for the sharing recipient and sets the acceptance state 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 a cloud data repository. Then, the owner device 2603 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.

[0218] 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. Then, the sharing recipient device 2605 may perform action 2610 to show the acceptance UI on the device display, thereby allowing the user to accept or reject 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 the user agrees to accept sharing, an acceptance message may be sent. When the user of the sharing recipient device indicates rejection of 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 sharing has been accepted.

[0219] like Fig.26B As shown, every N days, the owner device 2603 may send a key list 2622 to the shared recipient device 2605. Then, the shared recipient device 2605 may perform operation 2624 to write these keys to the file system on the device as a key record. The shared recipient device 2605 may use these keys stored in the key record to locate the shared attachment and / or communicate with the shared attachment. The value of N may be determined by the user of the owner device 2603, or may be determined by a system policy. The key of a specific type in the key list 2622 may be determined based on the ability to be shared with the shared recipient device 2605. When the shared recipient device 2605 is 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 the attachment and / or communicate with the attachment. The identity handle of the shared recipient may be used to send the key list to multiple devices associated with the shared recipient. Alternatively, the shared recipient's device may receive the key list and synchronize the key record with other devices.

[0220] The owner device 2603 may transmit a new key to the shared recipient device 2605 at the best time based on the device state of the owner device (e.g., battery power, network connectivity, etc.). Therefore, the shared recipient may run out of keys, so that the current time period (e.g., number of privacy windows) exceeds the time period in which the key is available. In such scenarios, the shared recipient device 2605 will not be able to perform actions with the attachment until a new key is received. Instead of waiting to send a new key, the shared recipient device 2605 may send a request 2626 for a key of an attachment with a beacon UUID with a specified date interval. The owner device 2603 may perform operation 2628 to check the shared beacon record to determine whether there is sharing for the beacon UUID. If there is no sharing, the owner device may ignore the request (2632). If there is a shared beacon record, the owner device 2603 may send a message 2630 to the identity handle specified in the shared beacon record via the IDS channel. Upon receiving the key, the shared recipient device 2605 may write the key to the key record in the file system (2634).

[0221] 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.

[0222] like Fig.26C As shown, the owner or the sharing recipient can end sharing. If the owner stops sharing, the owner device 2603 can send an IDS stop sharing message 2640 to the sharing recipient device, which specifies the beacon UUID to stop sharing. Multiple attachments can be shared between the owner device and the sharing recipient device 2605, so sending the beacon UUID allows the attachment to be stopped from being clearly determined. Upon receiving message 2640, the sharing 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.

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

[0224] 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. Fig.27A A delegation UI 1903 is shown. Fig.27B Trustee UI 1906 is shown.

[0225] like Fig.27A As shown, the owner device 2603 can present a delegation UI 1903 to the user of the owner device. The delegation UI 1903 can be accessed from a settings or configuration menu or application associated with the wireless accessory to be shared. The delegation UI 1903 can present an interface element 2701 that prompts the user whether the attachment with the displayed attachment identifier 2702 should be shared. The attachment identifier 2702 can be the name or type of the attachment and / or an identifier of the attachment. The delegation UI 1903 can also present an interface element 2704 that allows selection of the user to whom the attachment is to be shared. For example, the user can be selected from the users in the user's contact list. The 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 identify an account associated with the user. Trustee UI 1903 may also present 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 location of 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 in a room. If the attachment has some independent functions, an option for enabling the trustee to command may also be presented (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.

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

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

[0228] like Fig.28A As shown, method 2800 includes the owner device determining a sharing recipient and a set of capabilities delegated to the sharing recipient (box 2801). The owner device may then create a cloud storage record including an identifier (e.g., an identity handle) of the sharing recipient, a UUID of the beacon, and the capabilities shared with the sharing recipient (box 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 sharing request including the cloud storage record (or the URL of the cloud storage record) to the sharing recipient's device (box 2803). The sharing recipient may store the cloud storage record in a cloud storage device and display a UI to prompt the user of the sharing recipient's device. The user of the sharing recipient's device may accept or reject the request via the UI. The owner device may then receive an acceptance or rejection message (box 2804) from the sharing recipient to indicate whether the sharing is accepted or rejected. If the sharing is rejected (no, box 2805), the owner device may delete the cloud storage record. The share recipient may also delete the cloud storage record in response to rejecting 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.

[0229] After the owner device marks the cloud storage record as accepted, the owner device may send the set of cryptographic keys to enable sharing capabilities for a period of time (block 2809). The set of cryptographic keys may be, for example, trustee keys as described herein. The owner device may pre-compute keys for an upcoming period of time for 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 being sent every N days.

[0230] like Fig.28B As shown, method 2810 includes an owner device receiving a request for an updated key for a date interval of a beacon UUID (box 2811). If the privacy period of the key sent to the sharing recipient has passed but the owner device has not yet had the opportunity to send a new key, the request may be received. The owner device may read a cloud storage record associated with the sharing arrangement (e.g., a shared beacon record) to verify the request (box 2812). If the request is invalid (no, box 2813), for example, if there is no cloud storage record for the beacon UUID, the owner device may ignore the request (box 2816). If the request is valid (yes, box 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 (box 2818). The type of key to be sent and the identity to which the key is sent may be determined based on the cloud storage record. Therefore, regardless of the identifier according to which the request is received, the updated key will be sent to the identity handle stored in the cloud storage record. In addition, the 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.

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

[0232] References to "one embodiment" or "embodiment" herein refer to specific features, structures, or characteristics described in conjunction with the embodiment that may be included in at least one embodiment of the present invention. The phrase "in one embodiment" appears at various locations in this specification and does not necessarily refer to the same embodiment. The processes depicted in the subsequent figures may be performed by processing logic, which includes hardware (e.g., circuits, dedicated logic), software (as instructions on a non-transient 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 below in order 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.

[0233] It will also be understood that, although the terms "first", "second", etc. may be used to describe various elements in this article, these elements should not be limited by these terms. These terms are only used to distinguish an element from another element. For example, the first contact can be named as the second contact, and similarly, the second contact can be named as the 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.

[0234] The terms used herein are only for describing specific embodiments and are not intended to limit all embodiments. 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 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 exclude the presence or addition of one or more other features, integers, steps, operations, elements, parts, and / or their groupings.

[0235] 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 [a stated condition or event] is detected" may be interpreted to mean "upon determining that" or "in response to determining that" or "upon detecting [a stated condition or event]" or "in response to detecting [a stated condition or event]," depending on the context.

[0236] 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 functions (such as a PDA and / or music player functions). In the description and drawings of the present 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.

[0237] In the foregoing description, exemplary embodiments of the present disclosure have been described. It is apparent that various modifications may be made thereto without departing from the broader essence and scope of the present disclosure. Accordingly, the specification and the accompanying 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 of the included features and other excluded features to accommodate a variety of different applications. Examples may include subject matter, such as methods, devices for performing the behavior of the method, at least one machine-readable medium including instructions, the instructions causing the machine to perform the behavior of the method when executed by the machine, or the actions of the device 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.

[0238] The embodiments described herein provide a non-transitory machine-readable medium storing instructions that cause one or more processors to perform operations, the 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.

[0239] 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, the 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.

[0240] 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.

[0241] One embodiment provides a method, the method comprising receiving a request on an electronic device associated with a sharing recipient to accept sharing of capabilities associated with a wireless accessory, the request comprising a storage record, wherein the storage record comprises 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 comprises presenting an interface on a display of the electronic device to accept or deny the request, in response to receiving input via the interface, sending a message indicating acceptance of the request, 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.

[0242] 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, although 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 after studying the drawings, the specification and the following claims.< / id> < / counter>

Claims

1. A method, comprising: Establishing shared key material by the first device and the second device; determining a defined time period for sharing the location service of the second device with a trustee device; generating a set of trustee keys using the shared key material, the set of trustee keys comprising at least one key for each privacy time window occurring within the defined time period; as well as The set of trustee keys is sent to the trustee device.

2. The method according to claim 1, further comprising: performing an exchange of random data between the first device and the second device; deriving the shared key material using the random data; as well as The shared key material is stored in a key store, the shared key material comprising at least one key pair and at least one key.

3. The method according to claim 1, further comprising: At least one diversified key is derived using the shared key material for inclusion in the set of trustee keys, the diversified key restricting access to a capability for the defined period of time. 4 . The method of claim 1 , wherein the set of trustee keys enables the trustee device to access a set of capabilities associated with the second device. The method of claim 4 , wherein the set of capabilities includes tracking or finding the second device. The method of claim 4 , wherein the set of capabilities includes silencing a tracking alert associated with the second device. The method of claim 1 , wherein the trustee device has an account associated with the second device.

8. The method of claim 7, wherein the set of capabilities includes removing the second device from a lost state when the trustee device establishes a connection with the second device within range.

9. The method according to claim 1, further comprising: A set of trustee keys is generated using the shared key material for one or more privacy time windows occurring within the defined time period.

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

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

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

Images