Patent Description:
Current security features in handheld and portable products allow the location of the product to be identified when requested by the user, such as in instances where the product is lost or stolen. If the wireless device includes positioning technology, the device can be configured to report its last location to the server computer, which is displayed by the service on a map presented to the user. Often wireless devices are used with wireless accessory devices that cannot determine their location and cannot communicate with a remote tracking services over a wide area network. These accessory devices can include, for example, wireless earbuds, headphones, headsets and other wearable devices (e.g., smartwatches, fitness bands, optical head-mounted displays) that communicate directly with the wireless device using peer-to-peer communications. For wireless accessory devices that cannot determine their location and cannot communicate with the remote tracking service, those devices cannot be tracked by the service when lost or stolen.

<CIT> discloses a tracking device which can securely communicate with a secondary device. The secondary device can provide locations associated with the tracking device to a tracking system. When the secondary device determines that the tracking device is lost (for instance, in response to no longer receiving communications from the tracking device), the secondary device can provide additional locations associated with the secondary device to the tracking system. The tracking system can store locations received before and after the tracking device was lost, and can provide these locations to the user for display within a map interface, enabling a user to digitally retrace the user's steps in order to aid the user in locating the lost tracking device.

<CIT> discloses a Bluetooth®-based positioning method. The method includes a mobile terminal receiving a Bluetooth® signal transmitted by at least one Bluetooth® beacon device; obtaining a media access control (MAC) address of each Bluetooth® beacon device according to the received Bluetooth® signal, and selecting Bluetooth® beacon devices having a respective MAC address as a first MAC address to be reference devices; obtaining a Bluetooth® signal strength and a broadcast beacon identifier of each reference device; and calculating a position of the mobile terminal according to the obtained Bluetooth® signal strength and the obtained broadcast beacon identifier of each reference device.

<CIT> discloses a secure wireless communication link (pairing) between two devices established using cleartext wireless transmissions between devices not joined to a network ("probes"). One device can broadcast a first probe indicating that it is seeking to establish a pairing. The other device can respond with a second probe, and the two devices can establish a shared secret, e.g., by exchanging further information using additional probes. Thereafter, either device can send a message to the other by encrypting the message using a cryptographic key derived from the shared secret; encrypted messages can also be sent within probes.

<CIT> discloses a system and mobile device exchange public keys of public key pairs during a pairing process. In some embodiments, an asymmetric transaction process includes generating a shared secret using a key derivation function over a key established using a secure key exchange (e.g., elliptic curve Diffie-Hellman), and verifying a signature of the system before transmitting any information identifying the mobile device.

There is provided a method of broadcasting signal beacons at a wireless accessory according to claim <NUM>. Optional features of the method are set out in the dependent claims. There is provided a wireless accessory device comprising means configured to perform the steps of a method. There is provided a computer readable storage medium storing instructions which, when executed, cause one or more processors of a data processing system to perform the method.

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. Embodiments discussed in relation to <FIG> fall under the scope of the appended claims. Embodiments discussed in relation to <FIG> and <FIG> are not encompassed by the wording of the claims but are considered as useful for understanding the invention. In particular, <FIG> is useful for understanding the invention as it relates to a system for pairing an electronic device with a wireless accessory which performs the method of <FIG>.

A portion of this disclosure contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever. Copyright <NUM> Apple Inc.

In the discussion that follows, a computing device that includes a touch-sensitive display is described. It should be understood, however, that the computing device may include one or more other physical user-interface devices. The various applications that may be executed on the device may use at least one common physical user-interface device, such as the touch-sensitive surface. One or more functions of the touch-sensitive surface as well as corresponding information displayed on the device may be adjusted and/or varied from one application to the next and/or within a respective application. In this way, a common physical architecture (such as the touch-sensitive surface) of the device may support the variety of applications with user interfaces that are intuitive and transparent.

<FIG> is a block diagram of a network operating environment <NUM> for mobile devices, according to an embodiment. The network operating environment <NUM> includes multiple mobile devices, such as mobile device 102A and mobile device 102B. The mobile devices 102A-102B can each be any electronic device capable of communicating with a wireless network and a wireless accessory device. Some example mobile devices include but are not limited to a smartphone, a tablet computer, a notebook computer, a wearable computer (e.g., smartwatch or other wearable computing accessory), a mobile media player, a personal digital assistant, and other similar devices. Each of mobile device 102A and mobile device 102B include a user interface, such as user interface <NUM> of mobile device 102B. Mobile device 102A and mobile device 102B can communicate over one or more wired and/or wireless networks <NUM> to perform data communication. For example, a wireless network <NUM> (e.g., cellular network, Wi-Fi network) can communicate with a wide area network <NUM>, such as the Internet, by use of a gateway <NUM>. Likewise, an access device <NUM>, such as a mobile hotspot wireless access device, can provide communication access to the wide area network <NUM>. The gateway <NUM> and access device <NUM> can then communicate with the wide area network <NUM> over a combination of wired and/or wireless networks.

In some implementations, both voice and data communications can be established over the wireless network <NUM> and/or the access device <NUM>. For example, mobile device 102A can place and receive phone calls (e.g., using VoIP protocols), send and receive e-mail messages (e.g., using POP3 protocol), and retrieve electronic documents and/or streams, such as web pages, photographs, and videos, over the wireless network <NUM>, gateway <NUM>, and wide area network <NUM> (e.g., using TCP/IP or UDP protocols). In some implementations, mobile device 102A can place and receive phone calls, send and receive e-mail messages, and retrieve electronic documents over the access device <NUM> and the wide area network <NUM>. In some implementations, mobile device 102A or mobile device 102B can be physically connected to the access device <NUM> using one or more cables, for example, where the access device <NUM> is a personal computer. In this configuration, mobile device 102A or mobile device 102B can be referred to as a "tethered" device. In one embodiment, mobile device 102A can communicate with mobile device 102B via a wireless peer-to-peer connection <NUM>. The wireless peer-to-peer connection <NUM> can be used to synchronize data between the devices.

Mobile device 102A or mobile device 102B can communicate with one or more services, such as a telephony service <NUM>, a messaging service <NUM>, a media service <NUM>, a storage service <NUM>, and a device locator service <NUM> over the one or more wired and/or wireless networks <NUM>. For example, the telephony service <NUM> can enable telephonic communication between mobile device 102A and mobile device 102B, or between a mobile device and a wired telephonic device. The telephony service <NUM> can route voice over IP (VoIP) calls over the wide area network <NUM> or can access a cellular voice network (e.g., wireless network <NUM>). The messaging service <NUM> can, for example, provide e-mail and/or other messaging services. The media service <NUM> can, for example, provide access to media files, such as song files, audio books, movie files, video clips, and other media data. The storage service <NUM> can provide network storage capabilities to mobile device 102A and mobile device 102B to store documents and media files. The device locator service <NUM> can enable a user to locate a lost or misplaced device that was, at least at some point, connected to the one or more wired and/or wireless networks <NUM>. Other services can also be provided, including a software update service to update operating system software or client software on the mobile devices. In one embodiment, the messaging service <NUM>, media service <NUM>, storage service <NUM>, and device locator service <NUM> can each be associated with a cloud service provider, where the various services are facilitated via a cloud services account associated with the mobile devices 102A-102B.

<FIG> illustrates a system <NUM> to locate a wireless accessory <NUM> that lacks access to a wide area network, according to an embodiment. In one embodiment, the wireless accessory <NUM> includes one or more wireless transceivers and can communicate, either directly or indirectly (e.g., through another device or computer) with a companion device (e.g., mobile device <NUM>) over a wireless network or 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., smartwatches, fitness bands, optical head-mounted displays). The wireless accessory <NUM> can also include other wireless devices such as game controllers or remote controls. The wireless accessory <NUM>, in one embodiment, also includes smartphones, tablet computers, laptop computers, smart speaker devices, televisions, or television set top boxes that at least temporarily are unable to access a wide area network, such as the Internet (e.g., wide area network <NUM> as in <FIG>). The wireless accessory can also be any other wireless device, including beacons or locator tags that can be attached to other devices to enable the tracking or locating of those devices. In one embodiment, the wireless accessory <NUM> can be paired with the mobile device <NUM> using a wireless technology standard, such as but not limited to Bluetooth. The wireless accessory <NUM> can also communicate with the mobile device <NUM> over wireless technologies such as Wi-Fi direct, Zigbee®, or AirPlay®. While the companion device to which the wireless accessory <NUM> is paired is generally referred to as a mobile device <NUM>, companion devices are not limited to mobile devices. Companion devices, in some embodiments, can also include laptop or desktop devices and can additionally include some wearable accessories, such as but not limited to a smart watch device or a wearable display.

In one embodiment, the wireless accessory <NUM> can periodically transmit a wireless beacon signal. The wireless accessory <NUM> can transmit the beacon signal using one of a variety of wireless technologies described herein (e.g., Bluetooth®, Wi-Fi, etc.) and in one embodiment can also beacon using an ultra-wide band (UWB) radio technology. The beacon signal can be transmitted using a single wireless technology, one of multiple selectable wireless technologies, or multiple simultaneous wireless technologies. The beacon signal can transmit a beacon identifier that includes information to specifically identify the wireless accessory <NUM>. In one embodiment, the beacon identifier is a public encryption key associated with the device.

The beacon signal can also convey information about the wireless accessory <NUM>, such as a beacon type, device classification, battery level. In one embodiment the beacon signal can also convey device status, such as a lost status, alarm status, or a near-owner status. The beacon signal can also include information that specifies battery life, charging status, and/or other status information. The lost status can indicate that the wireless accessory <NUM> has determined itself to be lost or has been placed into a lost state by the owner of the device. The alarm status can indicate that the wireless accessory <NUM> was placed in a state that the device should trigger an alarm if moved from a current location. The near-owner status can indicate that the wireless accessory <NUM> has detected the nearby presence of the mobile device <NUM> associated with the owner of the accessory.

The beacon signal can be detected by a finder device <NUM>, which is locally proximate to the wireless accessory <NUM>. The finder device <NUM> can be a similar device as the mobile device <NUM> and can receive and transmitting data over a wide area network <NUM> and receiving and transmitting using similar wireless technologies as the wireless accessory <NUM> (e.g., Bluetooth, etc.). Particularly, the finder device <NUM> can receive data using the wireless protocol over which the beacon signal is transmitted. The finder device <NUM> can determine a location using one or more location and/or positioning services including, but not limited to a satellite positioning service <NUM> or a terrestrial positioning system using RF signals received from wireless base stations <NUM> such as Wi-Fi access points or cell tower transmitters of a cellular telephone network. In an embodiment, the finder device <NUM> periodically stores its location as determined based on the one or more location and/or positioning services. The stored location can be associated with a timestamp for which the location was determined. When the finder device <NUM> receives a beacon signal from the wireless accessory <NUM>, the finder device <NUM> can transmit a location for the finder device over the wide area network <NUM> to a device locator server <NUM>. The timestamp for a determined location for the finder device <NUM> can be correlated with a timestamp for which a beacon signal was received to associate a geographic location with a received beacon signal.

Where the wireless accessory <NUM> provides a public key within the beacon signal, the finder device <NUM> can encrypt the determined location data and transmit the encrypted location data to the device locator server <NUM> over the wide area network <NUM>. In one embodiment, additional data can either be encrypted and transmitted along with the location data or transmitted unencrypted to the device locator server <NUM>. For example, a received signal strength indicator (RSSI) for the beacon signal can be transmitted along with the location data. The RSSI data can then be used to determine the distance of the wireless accessory <NUM> from the finder device <NUM> and assist in triangulation on the owner device. Where the RSSI data is transmitted in an unencrypted state, in one embodiment the server can use 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.

In one embodiment, the finder device <NUM> can behave differently upon receiving a beacon signal from a wireless accessory <NUM> depending upon a device status conveyed by the wireless accessory <NUM>. For standard beacon signals, the finder device <NUM> can place encrypted location data into a queue and transmit the location data to the device locator server <NUM> during a periodic transmission window. However, if the wireless accessory <NUM> is indicating an alarm state, the finder device <NUM> can transmit the location data to the device locator server <NUM> immediately. Additionally, the finder device <NUM> may not transmit the location data to the device locator server <NUM> if the beacon signal of the wireless accessory <NUM> indicates that the accessory is near the owner of the accessory. Alternatively, the finder device <NUM> may delay transmission of encrypted location data.

If the owner of the wireless accessory <NUM> wishes to locate the wireless accessory, the owner can access a device locator user interface <NUM> on the mobile device <NUM>. The device locator user interface <NUM> can be associated with a device locator application that is used to locate electronic devices and accessories that are registered with an online account of the user, such as a cloud services account or another type of online account. The device owner, using the device locator UI <NUM>, can query the device locator server <NUM> for location data that may have been transmitted to the device locator server by a finder device <NUM> of the wireless accessory <NUM>. In one embodiment, the mobile device <NUM> can transmit the public encryption key associated with the wireless accessory <NUM> to the device locator server <NUM>. The device locator server <NUM> can then return any stored location data that corresponds with the public encryption key. The location data returned to the mobile device <NUM> can be encrypted data that is encrypted by the finder device <NUM> using the public encryption key. The mobile device <NUM> can use an associated private key to decrypt the encrypted location data. The decrypted location data can then be processed by the mobile device <NUM> to determine a most probable location for the wireless accessory <NUM>. In various embodiments, the most probable location for the wireless accessory <NUM> can be determined by triangulation from multiple received locations and using other data, such as a beacon signal RSSI associated with each location and timestamp or UWB ranging data included within the location data.

<FIG> illustrates a system <NUM> for pairing and locating a wireless accessory, according to embodiments described herein. In one embodiment a mobile device <NUM> of a user of the wireless accessory <NUM> can present an accessory pairing UI <NUM> by which the user can pair the mobile device <NUM> with the wireless accessory <NUM>. During an initial pairing (<NUM>) between the mobile device <NUM> and the wireless accessory, a public key exchange (<NUM>) can be performed between the mobile device and the wireless accessory. In one embodiment, during the public key exchange (<NUM>) the mobile device <NUM> and the wireless accessory <NUM> exchange public keys of public key pairs generated by the device and the accessory. In one embodiment the public key exchange (<NUM>) is a one-way transfer, in which the mobile device <NUM> transmits a public key of a public/private key pair to the wireless accessory <NUM>. Alternatively, or additionally, the public key exchange (<NUM>) may be a Diffie-Hellman key exchange in which the device and the accessory establish a shared secret between two parties. In one embodiment, the public key exchange (<NUM>) additionally uses elliptic curve cryptography to establish the shared secret. For example, Elliptic-curve Diffie-Hellman (ECDH) can be used to enable the establishment of a public key pair and one or more shared secrets. The one or more shared secrets include an anti-tracking secret, which the wireless accessory <NUM> uses to periodically derive additional public keys.

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

The value M, in one embodiment, is <NUM> minutes, such that a new K-byte key is generated every <NUM> minutes. The public key can be derived deterministically based on a timestamp and an anti-tracking secret generated during the public key exchange <NUM>. The public key derivation (<NUM>) process enables the wireless accessory <NUM> to use different keys over time, preventing the long-term association with a specific key with a specific device. The key can be derived based on an anti-tracking secret known only to the mobile device <NUM> and the wireless accessory <NUM>, allowing the mobile device <NUM>, and only the mobile device, to determine which public key will be broadcast by the wireless accessory <NUM> at any given timestamp. The anti-tracking secret can be generated along with an ECDH public key and transferred to the wireless accessory <NUM>. The anti-tracking secret can then be used to enable the wireless accessory <NUM> to generate a sequence of public keys Pi. In one embodiment, the sequence of public keys Pi = λi. P, which defines a group operation between a scalar or exponent value λi and group elements, such as, for example, Elliptic Curve points P. The scalar or exponent value λ = KDF(AT, i), where KDF is a key derivation function, AT is the anti-tracking secret, and i is a counter or timestamp.

In one embodiment, backtracking resistance can be enabled to protect the anti-tracking secret in the event the wireless accessory <NUM> is compromised. When backtracking resistance is enabled, the anti-tracking secret is transferred to the wireless accessory <NUM> but is not retained by the wireless accessory. Instead, the accessory computes a value λi+<NUM> = H(λi ∥ time), with λ<NUM> = AT and H being a cryptographic hash function. The wireless accessory <NUM> then stores λi for a given time period i. If the wireless accessory <NUM> is compromised, only λi for current and future values of i is exposed, without exposing the anti-tracking secret AT. In one embodiment, backtracking resistance is performed by periodically writing λi to non-volatile memory of the wireless accessory <NUM>.

In one embodiment the wireless accessory <NUM> can transmit the beacon signal <NUM> every two seconds, although other beacon rates can be used, and the beacon rate can vary under certain circumstances. For example, the wireless accessory <NUM> can decrease a beacon rate when in a near-owner state. Beacon rate can also vary based on accelerometer triggered events. For example, the wireless accessory <NUM> can increase the beacon rate when in an alarm state, which can be triggered by the accelerometer on the wireless accessory <NUM>.

The wireless accessory <NUM> can enter the near-owner state if, after transmitting the beacon signal <NUM>, the wireless accessory <NUM> receives a reply from the mobile device <NUM> associated with the user of the accessory, which indicates that the mobile device <NUM> is within range of the wireless accessory. Additionally, while the wireless accessory is in the near-owner state, the amount of data transmitted by the beacon signal <NUM> may be reduced. In one embodiment, the rate at which new public keys are generated can also be reduced while the wireless accessory is in the near-owner state.

The wireless accessory <NUM> can enter an alarm state upon receiving a message from the mobile device <NUM> that indicates that the wireless accessory <NUM> should enter the alarm state. When in the alarm state, the wireless accessory can initially enter an armed state in which the wireless accessory <NUM> can reduce or cease the transmission of locator beacon signals, although other types of wireless signaling can persist. The wireless accessory <NUM> can remain in the armed state until the state is deactivated by the mobile device <NUM> or alarm is triggered. The alarm can be triggered, in one embodiment, upon detection of movement, for example, via an accelerometer within the wireless accessory <NUM>. The alarm can also be triggered, in one embodiment, upon detection that the wireless accessory has moved out of range of the mobile device and is no longer in the near-owner state. When the alarm is triggered, the rate at which the beacon signal <NUM> can be increased, to increase the speed by which the wireless accessory <NUM> can be located.

The beacon signal <NUM> transmitted by the wireless accessory <NUM> can be detected by a set of finder devices <NUM>, which are other electronic devices that can receive the beacon signal transmitted by the wireless accessory and are transmit location and other data associated with the beacon signal <NUM> to the device locator server <NUM> via the wide area network <NUM>. In one embodiment the set of finder devices <NUM> include variants of the mobile device <NUM> or can be other types of electronic devices. The set of finder devices <NUM> can include a variant of the finder device <NUM> of <FIG> and can determine similar location determination techniques. For example, the set of finder devices can perform operations (<NUM>) to correlate the beacon signal <NUM> received from the wireless accessory <NUM> with a device location associated with the finder device. As described with respect to <FIG>, the device location can be determined via a satellite positioning service or a terrestrial positioning system that uses RF signals received from wireless base stations (e.g., Wi-Fi access points or cell tower transmitters). In one embodiment the set of finder devices <NUM> can also include stationary devices such as smart speaker devices, televisions, or television set top boxes that can receive the beacon signal <NUM>.

The set of finder devices <NUM> can encrypt the location data with the beacon identifier (e.g., public key) received within the beacon signal <NUM> and send the location data (<NUM>) to the device locator server <NUM>. The data sent by the set of finder devices <NUM> is send anonymously and no identifying information for the finder devices is stored with the data sent by the finder devices.

The device locator server <NUM> can store encrypted location data in a data store <NUM>, which in one embodiment can be a distributed database having multiple nodes. Hashes of the beacon identifier/public key of an accessory can be sent along with encrypted location data. The encrypted location data can be stored to a database node based on a hash of the beacon identifier. The encrypted location data can be indexed by the device locator server <NUM> using the hash of the beacon identifier. Sending the hash of the beacon identifier instead of the full beacon identifier prevents the storage of the full beacon identifier to the server. Other information can also be sent and stored with the location data, either in an encrypted or unencrypted state. The other information can include timestamps for when the beacon signal <NUM> was received, RSSI information for the received beacon, and/or ranging information determined, for example, via UWB ranging.

When the user or owner of the wireless accessory <NUM> wishes to locate the accessory, the user or owner can access the device locator UI <NUM> on the mobile device <NUM>. The device locator UI <NUM> can be associated with a device locator application or feature of the mobile device <NUM>. The device locator UI <NUM> may also have a web-based interface that can be accessed from the mobile device <NUM> or another type of electronic device, such as a laptop or desktop device. The mobile device <NUM>, upon loading the device locator UI <NUM>, can send a request (<NUM>) for location data to the device locator server <NUM>. The request <NUM> can include a set of public keys or public key hashes, which can serve as beacon identifiers for the beacon data. The mobile device <NUM> can generate the set of public keys based on the secret information held by the mobile device <NUM> and the wireless accessory <NUM> and the timestamps over which the mobile device <NUM> wishes to receive location data. In one embodiment the set of public keys is the sequence of public keys Pi that are generated based on the anti-tracking secret. The sequence of public keys Pi corresponds to a matching sequence of private keys di. The mobile device <NUM> can generate the sequence of public keys, as well as the corresponding sequence of public keys di, where i is a counter or timestamp. In one embodiment, the mobile device <NUM> can generate and send the previous <NUM> hours of public keys (or hashes of the <NUM> hours of public keys) within the request <NUM>. If no data is found for <NUM> hours of public keys, the mobile device <NUM> can send generate keys for an earlier period, back to a pre-determined location data retention limit.

In one embodiment the encrypted location data is stored and indexed based on a hash of the public key instead of the public key to prevent the provider of the location service data from storing data that can be used to tie the encrypted location data to a specific device, and thus a specific user or user account. The finder device can send the hash of the public key that is broadcast within the beacon signal <NUM> associated with an observation location. The owner of the device can query the device locator server <NUM> using a hash of the public key that is determined for a query period.

In some embodiments, if a location query is to be performed via the web-based interface from an electronic device, such as a laptop or desktop device, keys to enable the decryption of the location data may be required to be sent to the electronic device. In one embodiment, decryption keys for the location data may be sent to the server that provides the web-based interface to enable the server to decrypt location data, at least while the location data is being viewed through the web-based interface. Before location data is displayed via the web-based interface, a notice may be presented to inform the user that location decryption keys are being temporarily shared with the web-based interface server to enable location data to be decrypted and presented. In one embodiment, the sharing of the location decryption keys can be performed via an automatic and temporarily delegation of location query rights with a proxy account associated with the web-based interface.

In one embodiment, the wireless accessory <NUM> can be placed in a light lost mode. In the light lost mode, a set of future public keys can be generated for the wireless accessory and transmitted to the device locator server <NUM>. The device locator server <NUM> can then notify the mobile device <NUM> if any location data is received that correspond with a key in the set of future public keys. In one embodiment, a finder device that sends a location for a wireless accessory that is in the light lost mode can be directed by the device locator server <NUM> to relay a message to the wireless accessory <NUM> that notifies the wireless accessory that it is in the light lost mode. A similar mechanism can be used to relay a message to the wireless accessory <NUM> that places the accessory in an explicit lost mode. The explicit lost mode can be enabled by the user via the device locator UI <NUM>. In the explicit lost mode, the wireless accessory <NUM> cannot be paired with another device unless unlocked by the owner.

<FIG> are flow diagrams illustrating methods for use with the device locator systems described herein. <FIG> illustrates a method <NUM> to pair a mobile device with a wireless accessory. <FIG> illustrates a method <NUM> to determine a location for a wireless accessory via a device locator server. <FIG> illustrates an additional method <NUM> to determine a location for a wireless accessory via a device locator server. Aspects of method <NUM>, <NUM>, and <NUM> are also illustrated in <FIG> and <FIG>, as described above. For example, the description of the operations below refers to the mobile device <NUM>, wireless accessory <NUM> and device locator server <NUM>.

As shown in <FIG>, method <NUM> includes an operation (block <NUM>) that performs an initial pairing with a wireless accessory. The initial pairing can be a Bluetooth pairing or another type of pairing using other wireless radio technologies. During the initial pairing, the mobile device and the wireless accessory can exchange identifiers, passkeys, or other credentials that enables a wireless data exchange to be performed between a mobile or another electronic device and the wireless accessory. On one embodiment the initial paring with the wireless accessory can include the exchange of credentials associated with the wireless protocol for which the pairing is performed, allowing all data exchanged wirelessly to have at least a first layer of encryption.

The mobile device can then generate a public/private key pair and one or more additional shared secrets (block <NUM>). The device can then send the public key and one or more additional shared secrets to the wireless accessory (block <NUM>). 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.

After generating the public/private keypair and one or more additional shared secrets, the mobile device can store public/private key pair to keystore (block <NUM>). In one embodiment the keystore is a cloud-based keystore that can be synchronized with other devices associated with the same cloud services account, or family of cloud services accounts, to which the mobile device and wireless accessory are associated. The cloud-based keystore 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 <NUM>). Registering the wireless accessory with the device management server can form an association between the wireless accessory and the cloud services account to which the mobile device is associated. The device management server can be associated with other cloud-based servers that are used to facilitate cloud-based services accessible to the mobile device, such as the device locator server <NUM> of <FIG> and <FIG>.

As shown in <FIG>, method <NUM> includes an operation in which an electronic device launches a device locator UI (block <NUM>). In response to launching the device locator UI, the electronic device, which can be a mobile device as described herein, or another electronic device associated with the same cloud services account as the mobile electronic device, can perform an operation to generate a set of public keys that were included within a beacon signal broadcast by a wireless accessory during a first period (block <NUM>). The first period can be, for example, a previous <NUM> hours. The electronic device is aware of the frequency in which the wireless accessory is to generate new public keys and, using a shared secret generated with the wireless accessory, can generate a set of public keys that correspond with the keys that were generated by the wireless accessory over the first period. The electronic device can then send the set of public keys within a request for the device locator server to send location data that corresponds with the set of public keys (block <NUM>). In one embodiment, 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 decrypt the encrypted location data received by the server using the private key generated during the initial pairing with the wireless accessory (block <NUM>). The electronic device can then process the location data to determine the highest probability location for the wireless accessory (block <NUM>).

Processing the location data can include a variety of different operations. In one embodiment the location data includes latitude and longitude information along with a timestamp for which the location was determined. The electronic device can triangulate based on the timestamps and remove noise or outlier locations. In one embodiment the location data specifies the location of the finder device that detected the beacon. The location data can additionally include UWB ranging information and/or RSSI information for the beacon detected by the finder device. The electronic device can analyze the UWB ranging information and/or RSSI information in context with the device locations to develop a more accurate location for the wireless accessory. Data that can be transmitted by a finder device and used for location processing is shown in <FIG> and described below.

As shown in <FIG>, method <NUM> includes operations that can be performed if the device locator server does not have location data to provide to the electronic device in response to a request. The electronic device can generate a first set of public keys that were included within a beacon signal broadcast by wireless accessory during a first period (block <NUM>). The first period can be, for example, <NUM> hours, although other initial search periods can be used. The electronic device can perform a subsequent operation to request the device locator server to send location data that corresponds with first set of public keys (block <NUM>). If the data is returned by the server (block <NUM>, "yes"), the electronic device can decrypt the location data received from the server using the private key that corresponds with the set of public keys (block <NUM>).

If data is not returned by the server (block <NUM>, "no") the electronic device can generate a second set of public keys that were included within a beacon signal broadcast by the wireless accessory during a second period (block <NUM>). The second period can be the <NUM>, <NUM>, or another number of hours before the first period. The electronic device can then request for the device locator server to send data that corresponds with the second set of public keys (block <NUM>). If, in response to the request, data is returned by the server (block <NUM>, "yes"), method <NUM> can proceed to block <NUM>, in which the electronic device decrypts the received data. If data is not returned by the server (block <NUM>, "no"), or the server sends a reply that indicates data is not available, method <NUM> includes for the electronic device can widen the search time by requesting successively older time periods until the max period is reached (block <NUM>).

<FIG> is a flow diagram illustrating a method <NUM> of broadcasting a signal beacon at a wireless accessory, according to an embodiment. Aspects of method <NUM> are also illustrated in <FIG> and <FIG>. Method <NUM> includes for the wireless accessory to derive a public key (block <NUM>). The public key is derived based on a shared secret and a timestamp determined based on a clock or time keeping device of the wireless accessory. The wireless accessory then transmits a beacon signal at a first frequency, where the beacon signal includes the public key (block <NUM>). The first frequency can vary, and in one embodiment is one beacon every two seconds.

After transmitting a beacon signal, the wireless accessory listens for a response from the owner device. If the wireless signal receives a response from the owner device (block <NUM>, "yes"), the wireless accessory can enter a near-owner state (block <NUM>) and begin to transmit the beacon signal at a second, lower frequency (block <NUM>). If the wireless accessory does not receive a response from the owner device (block <NUM>, "no"), the wireless accessory can continue beaconing at the first frequency (block <NUM>).

Method <NUM> additionally includes for the wireless device, while beaconing, to rotate the public key every M minutes, where the value of M can vary across embodiments and/or based on the device state. Based on a timer expiration, counter, or another mechanism, the wireless accessory determines whether the accessory has entered a new key period (block <NUM>). While the wireless accessory has not entered a new key period (block <NUM>, "no"), the accessory can continue beaconing using the current public key (block <NUM>). When the wireless accessory detects that it has entered a new key period (block <NUM>, "yes") the accessory derives a new public key using the current timestamp and the anti-tracking secret (block <NUM>).

<FIG> illustrate operations of a method <NUM> that can be performed by a finder device, according to embodiments described herein. Aspects of method <NUM> are also illustrated in <FIG> and <FIG>.

As shown in <FIG>, method <NUM> includes for the finder device to perform a periodic beacon scan using a wireless baseband processor while an application processor of the finder device is in a low power mode (block <NUM>). While the beacon scan can also be performed when the application processor is active, beacon scans can be performed by the wireless processor and a wireless radio receiver as a low power operation while the finder device is idle, inactive, or otherwise in a low power state. The finder device can store a timestamp and a beacon identifier to a beacon scan buffer for any beacon data received by the finder device (block <NUM>). The beacon identifier, in one embodiment, is a public key that is generated by the wireless device based on a timestamp and a shared secret generated with the mobile device of the owner.

Method <NUM> additionally includes for the finder device to perform periodic Wi-Fi scans using the wireless processor while application processor is in a low power mode (block <NUM>). While the Wi-Fi scans can also be performed when the application processor is active, Wi-Fi scans can be performed by the wireless processor and a wireless radio receiver as a low power operation while the finder device is idle, inactive, or otherwise in a low power state. The finder device can then store Wi-Fi service set identifiers (SSIDs) and scan timestamps to a Wi-Fi scan buffer on the finder device (block <NUM>).

In one embodiment, the Wi-Fi scan buffer is a rolling buffer that stores the most recently detected SSIDs, while overwriting older detected SSIDs. In one embodiment the beacon scan buffer can be a fixed-size buffer having space for a pre-determined number of entries. The finder device can wake the application processor when the beacon scan buffer becomes full (block <NUM>) and correlate those beacon scan with the most recently detected SSIDs in the Wi-Fi scan buffer. That correlation can enable the finder device to determine a set of device locations that correspond with received beacons based on Wi-Fi scan buffer data (block <NUM>).

Method <NUM> continues in <FIG> and includes for the finder device to correlate device locations from the Wi-Fi scan buffer data with other location data if other location data is available (block <NUM>), to generate refined device locations. If refined device locations are generated, the finder device can optionally combine the beacon data with refined device locations (block <NUM>). The finder device can also add signal strength (RSSI) or ranging data to the location data (block <NUM>). The signal strength and ranging data (e.g., UWB ranging data) can be gathered when the beacon signal is received by the finder device. The finder device can then encrypt the location data with one or more public keys received within the beacon data (block <NUM>). The signal and ranging data may be encrypted along with the location data or can be send unencrypted along with the encrypted location data. The finder device can enqueue encrypted location data for transmission to the device locator server (block <NUM>). The device locator server can be one of multiple cloud services servers to which communication is generally performed in a batched and throttled manner. A batch of encrypted data can be gathered and placed in the transmission queue until a transmit interval arrives, during which the finder device can transmit data to the cloud services servers (block <NUM>).

<FIG> illustrates the gathering of signal and ranging data by a finder device, according to an embodiment. In one embodiment, the finder device <NUM> can gather signal strength information (e.g., RSSI 704A-704N) for a beacon signal <NUM> received from the wireless accessory <NUM> across multiple locations 702A-702N. The finder device <NUM> can also represent multiple finder devices, such as the set of finder devices <NUM> in <FIG>, where each finder device detects the beacon signal at a different location. Each finder device <NUM> can send different locations and signal strengths and the location and signal strength data received from the multiple finder devices will be aggregated by the device locator server. In one embodiment, where a finder device and the wireless device each include UWB radios, UWB ranging <NUM> can be performed if the finder device and the wireless device are within range of UWB transmissions. UWB ranging and signal strength data can be transmitted along with location data for the finder devices to the device locator server.

The owner device can retrieve the RSSI or UWB information from the device locator server along with location data, which in one embodiment is provided the form of latitude and longitude information, along with timestamps for which the locations were determined. The owner device can then use the location data, timestamps, and signal information to triangulate a most probable location for the wireless accessory <NUM>.

<FIG> illustrates a networked system <NUM> for locating devices and wireless accessories, according to an embodiment. The system <NUM> also illustrates an exemplary server architecture for the device locator server <NUM>, according to an embodiment. In one embodiment the device locator server <NUM> is a cluster of interconnected server devices, which may be physical or virtual servers within a single datacenter or distributed across multiple datacenters and/or geographic locations. As described above, the device locator server <NUM> can communicate with a mobile device <NUM> of an accessory owner or user and the set of finder devices <NUM> over a wide area network <NUM>. The mobile device <NUM> includes a UI provided by a local or web application that enables the location of a wireless accessory and the finder devices <NUM> receive beacon signals from wireless accessories and transmits location data associated with the received signals to the device locator server <NUM>.

In one embodiment the device locator server <NUM> includes a locator server front-end <NUM>, an account database <NUM>, a database cluster manager <NUM>, and a set of database cluster nodes 823A-823C. The locator server front-end <NUM> is a front-end interface to which the mobile device <NUM> and the set of finder devices <NUM> can communicate. The account database <NUM> stores account profile data for accounts of a cloud service provider to which the mobile device <NUM> and the finder devices <NUM> are associated. The database cluster manager <NUM> can configure the database cluster nodes 823A-823C as a distributed location database that can store location, signal, and ranging data in association with beacon identifiers for signal beacons received by the set of finder devices <NUM>.

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

In one embodiment, the database cluster manager <NUM> can select a database cluster node 823A-823C to which beacon data is to be stored by hashing the beacon ID associated with a set of location data. Each database cluster node 823A-823C can be associated with a range of hash values. The database cluster manager can then store location data to the cluster node that corresponds with the range of hash values associated with the hash of a given beacon ID. Although three database cluster nodes are illustrated, embodiments are not limited to any specific number of nodes and greater or fewer nodes may be used.

<FIG> illustrate a device locator UI <NUM>, according to an embodiment. <FIG> shows a first graphical user interface of the device locator UI <NUM>, according to an embodiment, which shows a location for various electronic devices and wireless accessories of a user. <FIG> shows a second graphical user interface of the device locator UI <NUM>, according to an embodiment, which enables a wireless accessory to be set to an alarm mode. <FIG> shows a third graphical user interface of the device locator UI <NUM>, according to an embodiment, which enables a wireless accessory to be set to a lost mode.

As shown in <FIG>, the device locator UI <NUM> can be displayed on an electronic device <NUM>, which can be a mobile device, or any other type of electronic device described herein. The device locator UI <NUM> can present a unified graphical interface through which multiple different types of devices and accessories can be located, including wireless devices with network or cellular access and wireless accessories without native network access. The device locator UI <NUM> can include a map <NUM> with a marker <NUM> that shows the current or last known location of a wireless device or accessory. The marker <NUM> can be an icon, image, graphic or any other user interface element that identifies the accessory and conveys a location for the accessory. A selectable element <NUM> in the device locator UI can present a description or name of the wireless device or accessory and can show an estimated distance between the wireless device or accessory and the current location of the electronic device <NUM>.

As shown in <FIG>, the device locator UI <NUM> can present a second user interface that enables a wireless accessory to be set to an alarm mode. The second user interface can be displayed, in one embodiment, in response to the selection of the selectable element <NUM> shown in <FIG>. The second user interface can present a user interface element <NUM> that represents and/or describes the wireless accessory in question, as well as the map <NUM> and marker <NUM> that show the current or last known location of the wireless accessory. In one embodiment, the device locator UI <NUM> can present a selectable element <NUM>, such as a button or another user interface element, that allows a user of the device locator UI <NUM> to place a selected wireless accessory into an alarm mode. While in the alarm mode, the wireless accessory can be configured to trigger a notification to the user if the wireless accessory is moved from its current location.

In one embodiment the wireless accessory can detect movement via an accelerometer or another type of motion sensor within the wireless accessory. The notification can be initiated by the wireless accessory by setting a flag in the data packet transmitted by the beacon signal of the wireless accessory that indicates the wireless accessory alarm has been triggered. In various embodiments, other trigger or notification modes can be used. In one embodiment, the alarm can optionally be triggered by the mobile device upon detection that the wireless accessory has moved out of range of the mobile device and is no longer in the near-owner state. In one embodiment, the alarm can optionally be triggered when the wireless accessory is out of range of, or otherwise cannot be located by, any of the devices associated with the account or family of user accounts to which the wireless accessory is associated.

As shown in <FIG>, the device locator UI <NUM> can present a third graphical user interface that enables a wireless accessory to be set to a lost mode. In one embodiment, when a wireless accessory cannot be located via the device locator UI <NUM>, the map <NUM> will not display a marker that indicates a location for the accessory. The device locator UI <NUM> can present the user interface element <NUM> that represents and/or describes the wireless accessory in question and a set of selectable user interface elements. One selectable user interface element <NUM> can present the option to notify the user when the accessory is found. When notify when found is enabled, in one embodiment the wireless accessory can be placed into a light lost mode. The electronic device associated with the device locator UI <NUM> can generate a set of public keys that the wireless accessory will broadcast with the beacon signal during a future time period (e.g., next <NUM> hours, next <NUM> hours, etc.). If a signal is detected by a finder device using one of the future keys, the device locator server can notify one or more electronic devices associated with the user.

Another selectable user interface element <NUM> can place the wireless accessory into an explicit lost mode. When explicitly placed into lost mode, the wireless accessory will be unable to be paired with other devices until the accessory is unlocked by the user or owner that places the device into lost mode. When sending a request to place a wireless accessory into lost mode, the requesting user can be required to enter authenticating information to ensure that the requesting user is authorized to request that lost mode be initiated on the lost accessory. The authenticating information can include a username or password associated with an account of a user, such as a cloud services account to which the user, electronic device, and wireless accessory are associated. The authenticating information can also include biometric information, such as a fingerprint or facial recognition data.

In one embodiment, a message and contact information provided by the requesting user can be displayed on the user device to alert a person who finds the lost wireless accessory on 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.

<FIG> illustrates an accessory pairing UI <NUM> that is displayed when attempting to pair with a lost wireless accessory, according to an embodiment. In one embodiment, when an electronic device <NUM> that is different from the electronic device <NUM> of <FIG> and is not associated with the registered user or owner of a wireless accessory attempts to pair with a lost wireless accessory, the accessory pairing UI of the electronic device can be displayed as shown in <FIG>. In one embodiment, the accessory pairing UI <NUM> can display a name or description <NUM> associated with the wireless accessory, as well as a message <NUM> entered by the user of the accessory upon placing the accessory into lost mode. Contact information <NUM> can also be displayed, along with a user interface element <NUM>, such as a button, that enables the electronic device <NUM> to contact the requesting user by using the provided contact information <NUM>.

Embodiments described herein include one or more application programming interfaces (APIs) in an environment in which calling program code interacts with other program code that is called through one or more programming interfaces. Various function calls, messages, or other types of invocations, which further may include various kinds of parameters, can be transferred via the APIs between the calling program and the code being called. In addition, an API may provide the calling program code the ability to use data types or classes defined in the API and implemented in the called program code.

An API allows a developer of an API-calling component (which may be a third-party developer) to leverage 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 can be a source code interface that a computer system or program library provides to support requests for services from an application. An operating system (OS) can have multiple APIs to allow applications running on the OS to call one or more of those APIs, and a service (such as a program library) can have multiple APIs to allow an application that uses the service to call one or more of those APIs. An API can be specified in terms of a programming language that can be interpreted or compiled when an application is built.

In some embodiments, the API-implementing component may provide more than one API, each providing a different view of or with different aspects that access different aspects of the functionality implemented by the API-implementing component. For example, one API of an API-implementing component can provide a first set of functions and can be exposed to third party developers, and another API of the API-implementing component can 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 which are not in the first set of functions. In other embodiments, the API-implementing component may itself call one or more other components via an underlying API and thus be both an API-calling component and an API-implementing component.

An API defines the language and parameters that API-calling components use when accessing and using specified features of the API-implementing component. For example, an API-calling component accesses the specified features of the API-implementing component through one or more API calls or invocations (embodied for example by function or method calls) exposed by the API and passes data and control information using parameters via the API calls or invocations. The API-implementing component may return a value through the API in response to an API call from an API-calling component. While the API defines the syntax and result of an API call (e.g., how to invoke the API call and what the API call does), the API may not reveal how the API call accomplishes the function specified by the API call. Various API calls are transferred via the one or more application programming interfaces between the calling (API-calling component) and an API-implementing component. Transferring the API calls may include issuing, initiating, invoking, calling, receiving, returning, or responding to the function calls or messages; in other words, transferring can describe actions by either of the API-calling component or the API-implementing component. The function calls or other invocations of the API may send or receive one or more parameters through a parameter list or other structure. A parameter can be a constant, key, data structure, object, object class, variable, data type, pointer, array, list or a pointer to a function or method or another way to reference a data or other item to be passed via the API.

Furthermore, data types or classes may be provided by the API and implemented by the API-implementing component. Thus, the API-calling component may declare variables, use pointers to, use or instantiate constant values of such types or classes by using definitions provided in the API.

Generally, an API can be used to access a service or data provided by the API-implementing component or to initiate performance of an operation or computation provided by the API-implementing component. By way of example, the API-implementing component and the API-calling component may each be any one of an operating system, a library, a device driver, an API, an application program, or other module (it should be understood that the API-implementing component and the API-calling component may be the same or different type of module from each other). API-implementing components may in some cases be embodied at least in part in firmware, microcode, or other hardware logic. In some embodiments, an API may allow a client program to use the services provided by a Software Development Kit (SDK) library. In other embodiments, an application or other client program may use an API provided by an Application Framework. In these embodiments, the application or client program may incorporate calls to functions or methods provided by the SDK and provided by the API or use data types or objects defined in the SDK and provided by the API. An Application Framework may in these embodiments provide a main event loop for a program that responds to various events defined by the Framework. The API allows the application to specify the events and the responses to the events using the Application Framework. In some implementations, an API call can report to an application the capabilities or state of a hardware device, including those related to aspects such as input capabilities and state, output capabilities and state, processing capability, power state, storage capacity and state, communications capability, etc., and the API may be implemented in part by firmware, microcode, or other low-level logic that executes in part on the hardware component.

The API-calling component may 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 different data processing system from the API-implementing component) that communicates with the API-implementing component through the API over a network. It should be understood that an API-implementing component may also act as an API-calling component (i.e., it may make API calls to an API exposed by a different API-implementing component) and an API-calling component may also act as an API-implementing component by implementing an API that is exposed to a different API-calling component.

The API may allow multiple API-calling components written in different programming languages to communicate with the API-implementing component (thus the API may include features for translating calls and returns between the API-implementing component and the API-calling component); however, the API may be implemented in terms of a specific programming language. An API-calling component can, in one embedment, call APIs from different providers such as a 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., the provider of a software library) or creator of another set of APIs.

<FIG> is a block diagram illustrating an exemplary API architecture, which may be used in some embodiments of the invention. As shown in <FIG>, the API architecture <NUM> includes the API-implementing component <NUM> (e.g., an operating system, a library, a device driver, an API, an application program, software or other module) that implements the API <NUM>. The API <NUM> specifies one or more functions, methods, classes, objects, protocols, data structures, formats and/or other features of the API-implementing component that may be used by the API-calling component <NUM>. The API <NUM> can specify at least one calling convention that specifies how a function in the API-implementing component receives parameters from the API-calling component and how the function returns a result to the API-calling component. The API-calling component <NUM> (e.g., an operating system, a library, a device driver, an API, an application program, software or other module), makes API calls through the API <NUM> to access and use the features of the API-implementing component <NUM> that are specified by the API <NUM>. The API-implementing component <NUM> may return a value through the API <NUM> to the API-calling component <NUM> in response to an API call.

It will be appreciated that the API-implementing component <NUM> may include additional functions, methods, classes, data structures, and/or other features that are not specified through the API <NUM> and are not available to the API-calling component <NUM>. It should be understood that the API-calling component <NUM> may be on the same system as the API-implementing component <NUM> or may be located remotely and accesses the API-implementing component <NUM> using the API <NUM> over a network. While <FIG> illustrates a single API-calling component <NUM> interacting with the API <NUM>, it should be understood that other API-calling components, which may be written in different languages (or the same language) than the API-calling component <NUM>, may use the API <NUM>.

The API-implementing component <NUM>, the API <NUM>, and the API-calling component <NUM> 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 magnetic disks, optical disks, random-access memory; read only memory, flash memory devices, etc..

<FIG> is a block diagram of a device architecture <NUM> for a mobile or embedded device, according to an embodiment. The device architecture <NUM> includes a memory interface <NUM>, a processing system <NUM> including one or more data processors, image processors and/or graphics processing units, and a peripherals interface <NUM>. The various components can be coupled by one or more communication buses or signal lines. The various components can be separate logical components or devices or can be integrated in one or more integrated circuits, such as in a system on a chip integrated circuit.

The memory interface <NUM> can be coupled to memory <NUM>, which can include highspeed 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.).

Sensors, devices, and subsystems can be coupled to the peripherals interface <NUM> to facilitate multiple functionalities. For example, a motion sensor <NUM>, a light sensor <NUM>, and a proximity sensor <NUM> can be coupled to the peripherals interface <NUM> to facilitate the mobile device functionality. One or more biometric sensor(s) <NUM> may also be present, such as a fingerprint scanner for fingerprint recognition or an image sensor for facial recognition. Other sensors <NUM> can also be connected to the peripherals interface <NUM>, such as a positioning system (e.g., GPS receiver), a temperature sensor, or other sensing device, to facilitate related functionalities. A camera subsystem <NUM> and an optical sensor <NUM>, e.g., a charged coupled device (CCD) or a complementary metal-oxide semiconductor (CMOS) optical sensor, can be utilized to facilitate camera functions, such as recording photographs and video clips.

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

An audio subsystem <NUM> can be coupled to a speaker <NUM> and a microphone <NUM> to facilitate voice-enabled functions, such as voice recognition, voice replication, digital recording, and telephony functions. In smart media devices described herein, the audio subsystem <NUM> can be a high-quality audio system including support for virtual surround sound.

The I/O subsystem <NUM> can include a touch screen controller <NUM> and/or other input controller(s) <NUM>. For computing devices including a display device, the touch screen controller <NUM> can be coupled to a touch sensitive display system <NUM> (e.g., touch-screen). The touch sensitive display system <NUM> and touch screen controller <NUM> can, for example, detect contact and movement and/or pressure using any of a plurality of touch and pressure sensing technologies, including but not limited to capacitive, resistive, infrared, and surface acoustic wave technologies, as well as other proximity sensor arrays or other elements for determining one or more points of contact with a touch sensitive display system <NUM>. Display output for the touch sensitive display system <NUM> can be generated by a display controller <NUM>. In one embodiment, the display controller <NUM> can provide frame data to the touch sensitive display system <NUM> at a variable frame rate.

In one embodiment, a sensor controller <NUM> is included to monitor, control, and/or processes data received from one or more of the motion sensor <NUM>, light sensor <NUM>, proximity sensor <NUM>, or other sensors <NUM>. The sensor controller <NUM> can include logic to interpret sensor data to determine the occurrence of one of more motion events or activities by analysis of the sensor data from the sensors.

In one embodiment, the I/O subsystem <NUM> includes other input controller(s) <NUM> that can be coupled to other input/control devices <NUM>, such as one or more buttons, rocker switches, thumb-wheel, infrared port, USB port, and/or a pointer device such as a stylus, or control devices such as an up/down button for volume control of the speaker <NUM> and/or the microphone <NUM>.

In one embodiment, the memory <NUM> coupled to the memory interface <NUM> can store instructions for an operating system <NUM>, including portable operating system interface (POSIX) compliant and non-compliant operating system or an embedded operating system. The operating system <NUM> may include instructions for handling basic system services and for performing hardware dependent tasks. In some implementations, the operating system <NUM> can be a kernel.

The memory <NUM> can also store communication instructions <NUM> to facilitate communicating with one or more additional devices, one or more computers and/or one or more servers, for example, to retrieve web resources from remote web servers. The memory <NUM> can also include user interface instructions <NUM>, including graphical user interface instructions to facilitate graphic user interface processing.

Additionally, the memory <NUM> can store sensor processing instructions <NUM> to facilitate sensor-related processing and functions; telephony instructions <NUM> to facilitate telephone-related processes and functions; messaging instructions <NUM> to facilitate electronic-messaging related processes and functions; web browser instructions <NUM> to facilitate web browsing-related processes and functions; media processing instructions <NUM> to facilitate media processing-related processes and functions; location services instructions including GPS and/or navigation instructions <NUM> and Wi-Fi based location instructions to facilitate location based functionality; camera instructions <NUM> to facilitate camera-related processes and functions; and/or other software instructions <NUM> to facilitate other processes and functions, e.g., security processes and functions, and processes and functions related to the systems. The memory <NUM> may also store other software instructions such as web video instructions to facilitate web video-related processes and functions; and/or web shopping instructions to facilitate web shopping-related processes and functions. In some implementations, the media processing instructions <NUM> are divided into audio processing instructions and video processing instructions to facilitate audio processing-related processes and functions and video processing-related processes and functions, respectively. A mobile equipment identifier, such as an International Mobile Equipment Identity (IMEI) <NUM> or a similar hardware identifier can also be stored in memory <NUM>.

Each of the above identified instructions and applications can correspond to a set of instructions for performing one or more functions described above. These instructions need not be implemented as separate software programs, procedures, or modules. The memory <NUM> can include additional instructions or fewer instructions. Furthermore, various functions may be implemented in hardware and/or in software, including in one or more signal processing and/or application specific integrated circuits.

<FIG> is a block diagram of a computing system <NUM>, according to an embodiment. The illustrated computing system <NUM> is intended to represent a range of computing systems (either wired or wireless) including, for example, desktop computer systems, laptop computer systems, tablet computer systems, cellular telephones, personal digital assistants (PDAs) including cellular-enabled PDAs, set top boxes, entertainment systems or other consumer electronic devices, smart appliance devices, or one or more implementations of a smart media playback device. Alternative computing systems may include more, fewer and/or different components. The computing system <NUM> can be used to provide the computing device and/or a server device to which the computing device may connect.

The computing system <NUM> includes bus <NUM> or other communication device to communicate information, and processor(s) <NUM> coupled to bus <NUM> that may process information. While the computing system <NUM> is illustrated with a single processor, the computing system <NUM> may include multiple processors and/or co-processors. The computing system <NUM> further may include memory <NUM> in the form of random access memory (RAM) or other dynamic storage device coupled to the bus <NUM>. The memory <NUM> may store information and instructions that may be executed by processor(s) <NUM>. The memory <NUM> may also be main memory that is used to store temporary variables or other intermediate information during execution of instructions by the processor(s) <NUM>.

The computing system <NUM> may also include read only memory (ROM) <NUM> and/or another data storage device <NUM> coupled to the bus <NUM> that may store information and instructions for the processor(s) <NUM>. The data storage device <NUM> can be or include a variety of storage devices, such as a flash memory device, a magnetic disk, or an optical disc and may be coupled to computing system <NUM> via the bus <NUM> or via a remote peripheral interface.

The computing system <NUM> may also be coupled, via the bus <NUM>, to a display device <NUM> to display information to a user. The computing system <NUM> can also include an alphanumeric input device <NUM>, including alphanumeric and other keys, which may be coupled to bus <NUM> to communicate information and command selections to processor(s) <NUM>. Another type of user input device includes a cursor control <NUM> device, such as a touchpad, a mouse, a trackball, or cursor direction keys to communicate direction information and command selections to processor(s) <NUM> and to control cursor movement on the display device <NUM>. The computing system <NUM> may also receive user input from a remote device that is communicatively coupled via one or more network interface(s) <NUM>.

The computing system <NUM> further may include one or more network interface(s) <NUM> to provide access to a network, such as a local area network. The network interface(s) <NUM> may include, for example, a wireless network interface having antenna <NUM>, which may represent one or more antenna(e). The computing system <NUM> can include multiple wireless network interfaces such as a combination of Wi-Fi, Bluetooth®, near field communication (NFC), and/or cellular telephony interfaces. The network interface(s) <NUM> may also include, for example, a wired network interface to communicate with remote devices via network cable <NUM>, which may be, for example, an Ethernet cable, a coaxial cable, a fiber optic cable, a serial cable, or a parallel cable.

In one embodiment, the network interface(s) <NUM> may provide access to a local area network, for example, by conforming to IEEE <NUM> wireless standards and/or the wireless network interface may provide access to a personal area network, for example, by conforming to Bluetooth standards. Other wireless network interfaces and/or protocols can also be supported. In addition to, or instead of, communication via wireless LAN standards, network interface(s) <NUM> may provide wireless communications using, for example, Time Division, Multiple Access (TDMA) protocols, Global System for Mobile Communications (GSM) protocols, Code Division, Multiple Access (CDMA) protocols, Long Term Evolution (LTE) protocols, and/or any other type of wireless communications protocol.

The computing system <NUM> can further include one or more energy sources <NUM> and one or more energy measurement systems <NUM>. Energy sources <NUM> can include an AC/DC adapter coupled to an external power source, one or more batteries, one or more charge storage devices, a USB charger, or other energy source. Energy measurement systems include at least one voltage or amperage measuring device that can measure energy consumed by the computing system <NUM> during a predetermined period of time. Additionally, one or more energy measurement systems can be included that measure, e.g., energy consumed by a display device, cooling subsystem, Wi-Fi subsystem, or other frequently used or high-energy consumption subsystem.

In some embodiments, the hash functions described herein can utilize specialized hardware circuitry (or firmware) of the system (client device or server). For example, the function can be a hardware-accelerated function. In addition, in some embodiments, the system can use a function that is part of a specialized instruction set. For example, the can use an instruction set which may be an extension to an instruction set architecture for a particular type of microprocessor. Accordingly, in an embodiment, the system can provide a hardware-accelerated mechanism for performing cryptographic operations to improve the speed of performing the functions described herein using these instruction sets.

Claim 1:
A method (<NUM>) of broadcasting beacon signals at a wireless accessory (<NUM>) comprising:
performing a key exchange between the wireless accessory and an electronic device to establish an anti-tracking secret for paired devices, wherein the wireless accessory (<NUM>) is paired with the electronic device (<NUM>);
deriving (<NUM>), at the wireless accessory (<NUM>), a first public key based on a current timestamp and the anti-tracking secret;
transmitting (<NUM>) a first beacon signal at a first frequency during a first period,
wherein the first beacon signal includes the first public key, wherein the first frequency defines a beacon rate for transmission of each beacon during the first period;
determining (<NUM>) a second frequency for transmission of a second beacon signal based on whether a response is received from the electronic device (<NUM>) in response to the transmission of the first beacon signal;
in response to determining (<NUM>) the wireless accessory (<NUM>) has entered a new key period, deriving (<NUM>) a second public key based on a current timestamp and the anti-tracking secret; and
transmitting the second beacon signal at the second frequency during a second period, wherein the second beacon signal includes the second public key.