Location Data Collection and Pruning for Wireless Accessory Devices

Abstract

The embodiments described herein provide an electronic device that includes a wireless processor coupled to a radio device, a memory for storing instructions, and one or more processors for executing the instructions. The one or more processors, based on the instructions: use the wireless processor to scan for beacon advertisements; in response to detecting the beacon via the wireless processor, store the beacon and a timestamp in a beacon advertisement buffer; associate the beacon advertisement with stored location data to determine a location estimate of a device associated with the beacon advertisement; use a beacon identifier broadcast with the beacon identifier to encrypt the location estimate of the beacon advertisement; and transmit a hash of the beacon identifier and the encrypted location estimate of the beacon advertisement to a device locator server. The embodiments also provide techniques for enabling known device matching and horizontal accuracy adjustment during location data collection of wireless accessory devices.

Description

[0001] Cross - reference

[0002] This patent application claims priority to U.S. Provisional Patent Application Serial No. 62 / 835,494, filed on April 17, 2019, U.S. Provisional Patent Application No. 62 / 855,975, filed on June 1, 2019, and U.S. Provisional Patent Application No. 62 / 897,789, filed on September 9, 2019, each of which is hereby incorporated by reference herein. Technical Field

[0003] The embodiments described herein generally relate to systems and methods for locating wireless devices and accessories. More specifically, the embodiments relate to an infrastructure capable of collecting and pruning location data of wireless accessories. Background Art

[0004] Current security features in handheld and portable products allow the location of the product to be identified upon user request, such as in the case where the product is lost or stolen. If a wireless device includes location 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 via a service. Typically, a wireless device is used with wireless accessory devices that cannot determine their location and cannot communicate with a remote tracking service via a wide - area network. These accessory devices can include, for example, wireless earbuds, earphones, headphones, and other wearable devices (e.g., smartwatches, fitness bands, optical head - mounted displays) that communicate directly with the wireless device using peer - to - peer communication. When a wireless accessory device that cannot determine its location and cannot communicate with a remote tracking service is lost or stolen, those devices cannot be tracked via the service. Summary of the Invention

[0005] The embodiments described herein provide an electronic device that includes a wireless processor coupled to a radio device, a memory for storing instructions, and one or more processors for executing those instructions. When executed by the one or more processors, the instructions cause the one or more processors to: scan for beacon advertisements using the wireless processor; store the beacon and a timestamp in a beacon advertisement buffer in response to detecting the beacon via the wireless processor; associate the beacon advertisement with stored location data to determine a location estimate of the device associated with the beacon advertisement; encrypt the location estimate of the beacon advertisement using a beacon identifier broadcast with the beacon identifier; and transmit a hash of the beacon identifier and the encrypted location estimate of the beacon advertisement to a device locator server. In one embodiment, the one or more processors can use the wireless processor to scan for beacon advertisements when an application processor of the one or more processors is in a low - power state.

[0006] One embodiment provides a non-transitory machine-readable medium storing instructions that cause one or more processors of an electronic device to perform operations including: when an application processor of the electronic device is in a low-power state, using a wireless processor of the electronic device to scan for beacon advertisements; in response to detecting the beacon advertisement via the wireless processor, storing the beacon advertisement and a timestamp as an entry in a beacon advertisement buffer; when the application processor wakes up from the low-power state, transferring the buffer entry to the application processor; and associating the beacon advertisement with stored location data to determine a location estimate of a device associated with the beacon advertisement.

[0007] One embodiment provides a method that includes: on an electronic device having a wireless processor coupled to a radio device, when an application processor of the electronic device is in a low-power state, using the wireless processor of the electronic device to scan for beacon advertisements; in response to detecting the beacon advertisement via the wireless processor, storing the beacon advertisement and a timestamp as an entry in a beacon advertisement buffer; processing the beacon advertisement buffer to remove duplicate entries; when the application processor wakes up from the low-power state, transferring the buffer entry to the application processor; and associating the beacon advertisement with stored location data to determine a location estimate of a device associated with the beacon advertisement.

[0008] Embodiments described herein also provide techniques for known device matching and horizontal accuracy adjustment during location data acquisition of a wireless accessory device. One embodiment provides a method that includes, on an electronic device having a wireless processor coupled to a radio device, using the wireless processor of the electronic device to scan for beacon advertisements, and detecting a beacon advertisement and having a beacon advertisement packet. The beacon advertisement packet can be a first type of advertisement packet or a second type of advertisement packet. The first type of the advertisement packet is broadcast by a device that has been connected to an accompanying device within a threshold time period, and the second type of the advertisement packet is broadcast by a device that has not been connected to an accompanying device within the threshold time period. The method also includes determining whether the beacon advertisement packet is the first type of advertisement packet based on the structure of the beacon advertisement packet, and in response to determining that the beacon advertisement packet is the first type of advertisement packet, performing a first key matching operation on the beacon advertisement packet to determine whether the beacon advertisement is associated with a known device. The first key matching operation can include comparing a key in a set of keys with an advertisement address in the beacon advertisement packet; and determining that the beacon advertisement is associated with a known device when a set of bits in these advertisement addresses matches a corresponding set of bits in the key in the set of keys. The method also includes, in response to determining that the beacon advertisement packet is the second type of advertisement packet, storing the beacon advertisement and an observed timestamp in a beacon advertisement database for deferred processing.

[0009] One embodiment provides a data processing system on an electronic device, the system including a memory device, a radio device coupled to the memory device, and one or more processors coupled to the radio device. The one or more processors include a wireless processor and an application processor. The one or more processors are configured to execute instructions stored in the memory device. When executed, the instructions cause the one or more processors to: detect a beacon advertisement from a beacon wireless device; associate the beacon advertisement with a location estimate determined by the electronic device; sample motion state data of the electronic device during an interval between detecting the beacon advertisement and determining the location estimate associated with the beacon advertisement; and adjust a horizontal accuracy of the location estimate based on a speed determined via the motion state data.

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

[0011] The invention is illustrated by way of example and is not limited to the figures of the drawings, in which like reference numerals indicate like 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 illustrates a system for locating a wireless accessory that cannot access a wide area network according to an embodiment;

[0014] Figure 3 illustrates a system for pairing and locating a wireless accessory according to an embodiment described herein;

[0015] Figures 4A to 4C is a flowchart showing a method used in conjunction with the device locator system described herein;

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

[0017] Figures 6A to 6B illustrates operations of a method executable by a detector device according to an embodiment described herein;

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

[0019] Figure 8Shows a networking system for locating devices and wireless accessories according to an embodiment;

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

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

[0022] Figure 11 Is a block diagram showing an exemplary API architecture that can be used in some embodiments of the present invention;

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

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

[0025] Figure 14 Shows a system for detecting and processing beacon data from a wireless accessory;

[0026] Figure 15 Shows a system for associating detected beacon advertisements with locations according to an embodiment;

[0027] Figure 16 Shows a method for collecting beacon advertisements when a detector device is in a low power state;

[0028] Figures 17A to 17B Shows a method for pruning detected locations for an object;

[0029] Figure 18 Is a method for processing device location data on a server according to an embodiment;

[0030] Figures 19A to 19C Shows a system and method for sending advertisement beacons on a laptop device;

[0031] Figure 20 Shows an advertisement beacon packet for a wireless accessory;

[0032] Figure 21 Shows a method for enabling the transition from a near-owner advertisement mode to a wild advertisement mode;

[0033] Figures 22A to 22B Shows a system for performing real-time and deferred key matching to detect beacons of known devices according to an embodiment;

[0034] Figure 23 Shows a method for performing matching for near-owner beacon advertisements according to an embodiment;

[0035] Figure 24 shows the adjustment of the horizontal accuracy of a mobile detector device;

[0036] Figure 25 shows a system that can be used on a detector device to perform horizontal accuracy adjustment on a detected beacon device; and

[0037] Figure 26 shows a method for horizontal accuracy adjustment of a detected beacon device. DETAILED DESCRIPTION

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

[0039] The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used in the specification of the present invention and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term "and / or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. It will also be understood that the term "comprises" and / or "comprising", when used in this specification, specifies the presence of the stated features, integers, steps, operations, elements, and / or components, but does not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0040] In the following discussion, a computing device including a touch-sensitive display is described. However, it should be understood that the computing device may include one or more other physical user interface devices. Various applications that can be executed on the device may use at least one shared physical user interface device, such as a touch-sensitive surface. One or more functions of the touch-sensitive surface and the corresponding information displayed on the device may be adjusted and / or varied from one application to the next, and / or may be adjusted and / or varied within the respective application. Thus, the shared physical architecture of the device, such as the touch-sensitive surface, can support various applications with an intuitive and transparent user interface.

[0041] Some processes are described below for a sequence of operations. However, it should be understood that some of the operations may be performed in a different order. In addition, certain operations may also be performed in parallel rather than sequentially.

[0042] Figure 1 FIG. 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 mobile devices 102A and 102B. The mobile devices 102A to 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, tablets, laptop 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 the 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 communication. For example, the wireless network 112 (e.g., cellular network, Wi-Fi network) may communicate with the wide area network 114 (such as the Internet) via the 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. Then, the gateway 116 and the access device 118 may communicate with the wide area network 114 via a combination of wired and / or wireless networks.

[0043] In some embodiments, both voice communication and data communication may be established via the wireless network 112 and / or the access device 118. For example, the mobile device 102A may make and receive phone calls (e.g., using VoIP protocol), send and receive email messages (e.g., using POP3 protocol), and retrieve electronic documents and / or streams, such as web pages, photos, and videos, via the wireless network 112, the gateway 116, and the wide area network 114 (e.g., using TCP / IP or UDP). In some embodiments, the mobile device 102A may make and receive phone calls, send and receive email messages, and retrieve electronic documents via the access device 118 and the wide area network 114. In some embodiments, the mobile device 102A or the mobile device 102B may 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 may be referred to as a "tethered" device. In one embodiment, the mobile device 102A may 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.

[0044] Mobile device 102A or mobile device 102B may communicate with service provider 115 that provides or enables one or more services. Exemplary services include telephone service 130, instant messaging service 140, media service 150, storage service 160, and device locator service 170 via one or more wired and / or wireless networks 110. For example, telephone service 130 may enable telephone communication between mobile device 102A and mobile device 102B or between a mobile device and a wired telephone device. Telephone service 130 may route Internet Protocol (IP)-based voice (VoIP) calls via wide area network 114 or may access a cellular voice network (e.g., wireless network 112). Instant messaging service 140 may provide, for example, email and / or other instant messaging services. Media service 150 may provide access to media files such as song files, audiobooks, movie files, video clips, and other media data. Storage service 160 may provide network storage capabilities to mobile device 102A and mobile device 102B to store documents and media files. Device locator service 170 may enable a user to locate a lost or misplaced device that is connected to one or more wired and / or wireless networks 110 at least at some point. For example, mobile device 102A may perform a location query for mobile device 102B. Device locator service 170 may also enable location queries for devices that do not have a network connection via a network using a discovery device, as follows Figures 2 to 3 shown. Other services may also be provided, including a software update service for updating operating system software or client software on a mobile device. In one embodiment, message delivery service 140, media service 150, storage service 160, and device locator service 170 may each be associated with a cloud service provider, where various services are facilitated via a cloud service account associated with mobile devices 102A-102B.

[0045] Figure 2 System 200 for locating wireless accessory 201 that cannot access a wide area network is shown in accordance with an embodiment. System 200 may also be used to locate devices that cannot access a WAN or LAN and thus cannot transmit device location. In one embodiment, wireless accessory 201 includes one or more wireless transceivers and may communicate directly or indirectly (e.g., via another device or computer) with an accompanying device (e.g., mobile device 102) 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, earphones, headphones, and other wearable devices (e.g., smartwatches, fitness bands, optical head-mounted displays). Wireless accessory 201 may also include other wireless devices such as a game controller or remote control. In one embodiment, wireless accessory 201 also includes at least temporarily being unable to access a wide area network such as the Internet (e.g., as Figure 1Smartphones, tablets, laptops, smart speaker devices, televisions, or television set-top boxes of the wide area network 114) shown. The wireless accessory can also be any other wireless device including beacons or locator tags 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 can be paired with the mobile device 102 using a wireless technology standard such as, but not limited to, Bluetooth. The wireless accessory 201 can 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 commonly referred to as the mobile device 102, the companion device is not limited to mobile devices. In some embodiments, the companion device can also include a laptop device or a desktop device and can additionally include some wearable accessories such as, but not limited to, smartwatch devices or wearable displays.

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

[0047] The beacon signal can also convey information about the wireless accessory 201 such as beacon type, device classification, battery level. In one embodiment, the beacon signal can also convey device status such as lost status, alert status, or near-owner status. The beacon signal can also include information specifying battery life, charge status, and / or other status information. The lost status can 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 alert status can indicate that the wireless accessory 201 is in a state where the device should trigger an alert if it moves from the current location. The near-owner status can indicate that the wireless accessory 201 has detected the presence of the mobile device 102 associated with the owner of the accessory in the vicinity.

[0048] The beacon signal can be detected by a detector device 202 local to the wireless accessory 201. The detector device 202 can be a device similar to the mobile device 102 and can receive and transmit data over the wide area network 114 and receive and transmit using a wireless technology similar to that of the wireless accessory 201 (e.g., Bluetooth, etc.). Specifically, the detector device 202 can use the wireless protocol over which the beacon signal is transmitted to receive data. The detector device 202 can use one or more location and / or positioning services to determine its location, the one or more location and / or positioning services including but not limited to satellite positioning service 206 or a terrestrial positioning system that uses RF signals received from wireless base stations 205 such as Wi-Fi access points or cellular towers of a cellular phone network. 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 was determined. When the detector device 202 receives the 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 over the wide area network 114. The timestamp for the location of the detector device 202 used for determination can be associated with the timestamp when the beacon signal was received to correlate the geographical location with the received beacon signal. In one embodiment, the wireless accessory 201 includes location determination capabilities via an integrated satellite positioning service (e.g., GPS) receiver. If the wireless accessory is unable to access the network to send its location to the device locator server 203, the wireless accessory can encode the encrypted location data within the beacon signal 301. Then, the detector device 202 can relay the encrypted location data to the device locator server 203.

[0049] In the case where the wireless accessory 201 provides a public key within the beacon signal, the detector device 202 can encrypt the determined location data and transmit the encrypted location data to the device locator server 203 over the wide area network 114. In one embodiment, additional data can be encrypted and transmitted together with the location data or transmitted unencrypted to the device locator server 203. For example, the received signal strength indicator (RSSI) of the beacon signal can be transmitted together with the location data. Then, the RSSI data can be used to determine the distance between the wireless accessory 201 and the detector device 202 and assist in the triangulation of the owner device. In the case where the RSSI data is transmitted in an unencrypted state, in one embodiment, if there are other stronger signals, the server can use the RSSI information to reduce noise by discarding very weak signals. In one embodiment, UWB ranging data can also be provided where such data is available.

[0050] In one embodiment, the detector device 202 may behave differently when receiving a beacon signal from the wireless accessory 201 based on the device state communicated by the wireless accessory 201. For a standard beacon signal, the detector device 202 may queue the encrypted location data and transmit the location data to the device locator server 203 during a periodic transmission window. However, if the wireless accessory 201 is indicating an alarm state, the detector device 202 may 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 may delay the transmission of the encrypted location data.

[0051] If the owner of the wireless accessory 201 wishes to locate the wireless accessory, the owner may access the 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 for locating electronic devices and accessories registered to the 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 use the associated private key to decrypt the encrypted location data. 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 the wireless accessory 201 may be determined by triangulation from multiple received locations and using other data, such as the beacon signal RSSI associated with each location and timestamp or UWB ranging data included within the location data.

[0052] Figure 3FIG. 300 shows a system for pairing and locating a wireless accessory according to an embodiment described herein. In one embodiment, a mobile device 102 of a user of the 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 an 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 transfer in which the mobile device 102 transmits the public key in the public key / private key pair to the wireless accessory 201. Additionally 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 the shared secret. For example, Elliptic Curve Diffie-Hellman (ECDH) may be used to implement the establishment of the public key pair and one or more shared secrets. In one embodiment, the one or more shared secrets include an anti-tracking secret that may be used by the wireless accessory 201 to periodically derive additional public keys. In one embodiment, the wireless accessory may advertise a temporary identity and then use identity-based encryption instead of public key encryption with a broadcast public key. With identity-based encryption, the public key is some unique element of information about the user's identity, or the public key 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 may obtain the decryption key from a trusted central authority.

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

[0054] In one embodiment, the value of M is 15 minutes such that a new K - byte key is generated every 15 minutes. The public key can be derived deterministically based on the timestamp and the anti - tracking secret generated during the public key exchange 310. The public key derivation (315) process enables the wireless accessory 201 to use different keys over time, thus preventing long - term association with a specific key and a specific device. The key can be derived based on the anti - tracking secret known only to the mobile device 102 and the wireless accessory 201, 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 and transmitted to the wireless accessory 201 together with the ECDH public key. Then, the anti - tracking secret can be used to enable the wireless accessory 201 to generate a sequence of public keys . In one embodiment, the sequence of public keys , which defines a group operation between a scalar or exponent value and a group element, such as an elliptic curve point . 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.

[0055] In one embodiment, reverse - tracking resistance can be enabled to protect the anti - tracking secret in the event that the wireless accessory 201 is compromised. When reverse - tracking 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 computes the value ( || time), where and are cryptographic hash functions. Then, the wireless accessory 201 stores i within a given time period . If the wireless accessory 201 is compromised, only the i for the current and future values is exposed, without exposing the anti - tracking secret AT. In one embodiment, reverse - tracking resistance is performed by periodically 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 key generation and diversification techniques described below with respect to Figures 15 to 16 can be used.

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

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

[0058] 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 transmitting locator beacon signals, but other types of wireless signaling can continue. 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.

[0059] 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 2As described, the device location can be determined via satellite positioning services or a terrestrial positioning system that uses RF signals received from wireless base stations (e.g., Wi-Fi access points or cellular tower transmitters). In one embodiment, the set of detector devices 303 may also include stationary devices that can receive beacon signals 301, such as smart speaker devices, televisions, or television set-top boxes.

[0060] The set of detector devices 303 can encrypt the location data using a 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 this set of detector devices 303 is sent anonymously, and the identification information of the detector devices is not stored together with the data sent by the detector devices.

[0061] The device locator server 203 can store the encrypted location data in a data repository 304, which in one embodiment can be a distributed database with multiple nodes. A hash of the attached beacon identifier / public key can be sent together with the encrypted location data. The encrypted location data can be stored in database nodes based on the hash of the beacon identifier. The device locator server 203 can use the hash of the beacon identifier to index the encrypted location data. Sending the hash of the beacon identifier instead of the full beacon identifier can prevent the full beacon identifier from being stored on the server. Other information can also be sent and stored together with the location data in encrypted or unencrypted form. Other information can include a timestamp of when the beacon signal 301 was received, RSSI information of the received beacon, and / or ranging information determined via UWB ranging, for example.

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

[0063] Store and index the encrypted location data based on the hash of the public key rather than the public key to prevent a provider of location service data from storing data that can be used to bind the encrypted location data to a specific device and thus to a specific user or user account. The detector device sends the hash of the public key broadcast within the beacon signal 301 associated with the observed location. The owner of the device may use the hash of the public key determined for the query time period to query the device locator server 203.

[0064] 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, it may be necessary to send the key to the electronic device to enable decryption of the location data. In one embodiment, the decryption key for the location data may be sent to a server that provides a web-based interface such that the server can decrypt the location data at least when viewing the location data via the web-based interface. Before displaying the location data via the web-based interface, a notification may be presented to notify 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 an automatic and temporary authorization of the location query privilege of a proxy account associated with the web-based interface.

[0065] In one embodiment, the wireless accessory 201 may be placed in a light-loss mode. In the light-loss mode, a set of future public keys may be generated for the wireless accessory and the hashes of those public keys may be transmitted to the device locator server 203. Then, if any location data corresponding to the keys in this set of future public keys is received, the device locator server 203 may notify the mobile device 102. In one embodiment, the detector device that sends the location of the wireless accessory in the light-loss mode may 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 the light-loss mode. A similar mechanism may also be used to relay a message to the wireless accessory 201 that places the accessory in an explicit loss mode. The user may enable the explicit loss mode via the device locator UI 204. In the explicit loss mode, the wireless accessory 201 cannot be paired with another device unless unlocked by the owner.

[0066] Figures 4A to 4C is a flowchart showing a method for use with the device locator system described herein. Figure 4A Shows a method 400 for pairing a mobile device with a wireless accessory. Figure 4B Shows a method 410 for determining the location of a wireless accessory via a device locator server. Figure 4C Shows an additional method 420 for determining the location of a wireless accessory via a device locator server. Aspects of methods 400, 410, and 420 are also in Figure 2 and Figure 3 shown, as described above. For example, the description of the following operations relates to mobile device 102, wireless accessory 201, and device locator server 203.

[0067] As Figure 4A shown, method 400 includes an operation of performing an initial pairing with the wireless accessory (block 401). The initial pairing can be a Bluetooth pairing or another type of pairing 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 an exchange of credentials associated with the wireless protocol for which the pairing is performed, thereby allowing all wirelessly exchanged data to have at least a first encryption layer.

[0068] Then, the mobile device can generate a public / private key pair and one or more additional shared secrets (block 402). The device can then send the public key and 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 the public key pair for encryption. In one embodiment, one or more additional shared secrets can include anti-tracking secrets that enable the wireless accessory to derive a new public key based on the existing public key.

[0069] 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 vault (block 404). In one embodiment, the key vault is a cloud-based key vault that can be synchronized with other devices associated with the same cloud service account or a series of cloud service accounts associated with the mobile device and the wireless accessory. The cloud-based key vault allows the wireless accessory to be located by other synchronized devices. The mobile device can then register the wireless accessory with the 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 associated with the mobile device. The device management server can communicate with other cloud-based servers such as Figure 2 and Figure 3associated with the device locator server 203), where the other cloud-based server is used to facilitate cloud-based services accessible to the mobile device.

[0070] As Figure 4B shown, method 410 includes an operation of an electronic device to initiate a device locator UI (block 411). In response to initiating the device locator UI, an operation may be performed for the electronic device of the mobile device as described herein or for another electronic device associated with the same cloud service account as the mobile electronic device to generate a set of public keys included within beacon signals broadcast by the wireless accessory during a first time period (block 412). The first time period may be, for example, the previous 24 hours. The electronic device knows the frequency at which the wireless accessory generates or rotates new public keys, and the electronic device may use a shared secret generated by the wireless accessory to generate a set of public keys corresponding to the keys generated by the wireless accessory during the first time period. Then, the electronic device may send the set of public keys within a request to request the device locator server to send location data corresponding to the set of public keys (block 413). In one embodiment, the public keys transmitted as the beacon identifier of the wireless accessory will be used to encrypt the location data sent by the server in response to the request. The electronic device may use the private key generated during the initial pairing with the wireless accessory to decrypt the encrypted location data received by the server (block 414). Then, the electronic device may process the location data to determine the most probable location of the wireless accessory (block 415).

[0071] 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 when the location was determined. The electronic device may perform triangulation based on the timestamp and remove noise or anomalous 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 the context of the device location to produce a more accurate location of the wireless accessory. In Figure 10 shown and described below are the data that may be transmitted by the detector device and used for location processing.

[0072] As Figure 4CAs shown, method 420 includes operations that can be performed when the device locator server does not have location data to provide to the electronic device in response to a request. The electronic device can generate a first set of public keys included within beacon signals broadcast by the wireless accessory during a first time period (block 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 (block 422). If the data is returned by the server (block 423, "yes"), the electronic device can use the private key corresponding to this set of public keys to decrypt the location data received from the server (block 429).

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

[0074] Figure 5 is a flowchart showing method 500 for broadcasting signal beacons at a wireless accessory according to an embodiment. Aspects of method 500 are also shown in Figure 2 and Figure 3 Method 500 includes the wireless accessory exporting a public key (block 502). The public key can be exported based on a shared secret and a timestamp determined based on the clock or timing device of the wireless accessory. Then, the wireless accessory can transmit a beacon signal at a first transmission interval, where the beacon signal includes the public key (block 503). The first transmission interval can vary and, in one embodiment, is one beacon transmitted every two seconds.

[0075] After transmitting the beacon signal, the wireless accessory can listen for a response from the owner device. If the wireless accessory 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 slower second 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).

[0076] Method 500 also includes, when transmitting a beacon, causing the wireless device to rotate the public key every M minutes, where the value of M can vary across 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 (block 508). While the wireless accessory has not entered a new key time period (block 508, "no"), the accessory can continue to transmit the beacon using the current public key (block 510). When the wireless accessory detects that it has entered a new key time period (block 508, "yes"), the accessory can derive a new public key using the current timestamp (block 509). In one implementation, the existing public key, the timestamp, and an anti-tracking secret can be used to derive the new public key.

[0077] Figures 6A to 6B Illustrates operations of method 600 that can be performed by a detector device according to an implementation described herein. Aspects of method 600 are also shown in Figure 2 and Figure 3 shown.

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

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

[0080] In one embodiment, the Wi-Fi scan buffer is a rolling buffer that stores the most recently detected SSIDs while overwriting earlier detected SSIDs. In one embodiment, the beacon scan buffer can be a fixed-size buffer with space for a predetermined number of entries. When the beacon scan buffer becomes full, the detector device can wake 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 detector device to determine a set of device locations corresponding to the received beacons based on the Wi-Fi scan buffer data (block 606).

[0081] Method 600 continues at Figure 6B and includes: If other location data is available, the detector device associates the device locations from the Wi-Fi scan buffer data with the other location data (block 607) to generate refined device locations. If refined device locations are generated, the detector device can optionally combine the beacon data with the refined device locations (block 608). The detector device can also add signal strength (RSSI) or ranging data to the location data (block 609). When the detector device receives a beacon signal, signal strength and ranging data (e.g., UWB ranging data) can be collected. Then, the detector device can encrypt the location data using one or more public keys received within the beacon data (block 610). The signal and ranging data can be encrypted with the location data or sent unencrypted along with the encrypted location data. The detector device can enqueue the encrypted location data for transmission to a device locator server (block 611). The device locator server can be one of multiple cloud service servers and typically communicates in a batch and throttled manner. A batch of encrypted data can be collected and placed in a transmission queue until a transmission interval is reached, during which the detector device can transmit the data to the cloud service server (block 612). The encrypted data can be sent along with hashes of the beacon identifiers corresponding to the encrypted locations, and the server will store the encrypted locations indexed by the hashes of the beacon identifiers.

[0082] Figure 7 illustrates the acquisition of signal and ranging data performed by a detector device according to an embodiment. In one embodiment, the detector device 202 can collect signal strength information (e.g., RSSI 704A to 704N) for beacon signals 301 received from a wireless accessory 201 across multiple locations 702A to 702N. The detector device 202 can also represent multiple detector devices, such as Figure 3a set of detector devices 303 therein, where each detector device detects a beacon signal at a different location. Each detector device 202 can send different locations and signal strengths, and the location and signal strength data received from multiple detector devices will be aggregated by the device locator server. In one embodiment, in the case where both the detector device and the wireless device include UWB radio devices, if the detector device and the wireless device are within the range of UWB transmission, UWB ranging 706 can be performed. The UWB ranging and signal strength data can be transmitted to the device locator server together with the location data of the detector device.

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

[0084] Figure 8 A networked system 800 for locating a device and a wireless accessory according to an embodiment is shown. According to one embodiment, the system 800 also shows an exemplary server architecture for the device locator server 203. 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 geographical locations. As described above, the device locator server 203 can communicate with the mobile device 102 of the accessory owner or user and this 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 enables the location of the wireless accessory, and the detector devices 303 receive beacon signals from the wireless accessory and transmit the location data associated with the received signals to the device locator server 203.

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

[0086] In one embodiment, the account database 825 can include 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 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 associated with other users in the account family associated with the requesting user and / or wireless accessories.

[0087] In one embodiment, the database cluster manager 813 can select the database cluster nodes 823A through 823C to store beacon data by performing a hash on the beacon ID associated with a set of location data. Each of the database cluster nodes 823A through 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 range of hash values associated with the hash of the given beacon ID. Although three database cluster nodes are shown, embodiments are not limited to any particular number of nodes, and more or fewer nodes can be used.

[0088] Figures 9A to 9C A device locator UI 204 according to an embodiment is shown. Figure 9A A first graphical user interface of a device locator UI 204 according to one embodiment is shown, which shows the locations of various electronic devices and wireless accessories of a user. Figure 9B A second graphical user interface of a device locator UI 204 according to one embodiment is shown, which enables a wireless accessory to be set to an alert mode. Figure 9C A third graphical user interface of a device locator UI 204 according to one embodiment is shown, which enables a wireless accessory to be set to a lost mode.

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

[0090] As Figure 9B shown, the device locator UI 204 can present a second user interface that enables a wireless accessory to be set to an alert mode. In one embodiment, the second user interface can be displayed in response to selecting Figure 9A the optional element 903 shown. The second user interface can present user interface elements 904 that represent and / or describe the wireless accessory under consideration, as well as a map 901 and a marker 902 that show 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 the 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.

[0091] In one embodiment, the wireless accessory can detect movement via an accelerometer or other type of motion sensor within the wireless accessory. The wireless accessory can initiate a notification by setting a marker in the data packet transmitted by the beacon signal of the wireless accessory indicating that the wireless accessory alert has been triggered. In various embodiments, other triggering or notification modes can be used. In one embodiment, the alert can optionally be triggered by the mobile device when it is detected that the wireless accessory has moved out of the range of the mobile device and is no longer in a near-owner state. In one embodiment, the alert can optionally be triggered when the wireless accessory is outside the range of any device associated with the user account or account family with which the wireless accessory is associated or cannot be located by these devices.

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

[0093] Another optional user interface element 907 can 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 it is unlocked by the user or owner who placed the device in lost mode. When a request to place the wireless accessory in lost mode is sent, the requesting user may be required to enter authentication information to ensure that the requesting user is authorized to request the activation of lost mode on the lost accessory. The authentication information can include a username or password associated with the user's account, 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 identification information.

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

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

[0096] Embodiments described herein include one or more application programming interfaces (APIs) in an environment, where calling program code interacts with other program code called through the one or more programming interfaces. Various function calls, messages, or other types of calls may also include various parameters, and these calls may be transmitted via the APIs between the calling program and the called code. Additionally, the API may give the calling program code the ability to use data types or categories defined in the API and implemented in the called program code.

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

[0098] In some embodiments, the API implementing 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 implementing component. For example, one API of the API implementing component may provide a first set of functions and may be exposed to third - party developers, and another API of the API implementing 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 test or debug functions not in the first set of functions. In other embodiments, the API implementing component itself may call one or more other components via a lower - level API, thus being both an API calling component and an API implementing component.

[0099] The API definition is the language and parameters used by an API calling component when accessing and using the specified features of an 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 (e.g., implemented by a function or method call), and uses parameters via the API call or reference to pass data and control information. The API implementation component may return an API return value in response to an API call from the API calling component. Although the API defines the syntax and results of an API call (e.g., how to initiate an API call and what an API call can do), the API may not reveal how the API call accomplishes the function specified by the API call. Various API calls are transmitted via one or more application programming interfaces between the calling (API calling component) and the API implementation component. Transmitting an API call may include issuing, initiating, referencing, calling, receiving, returning, or responding to a function call or message; 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 to the API may send or receive one or more parameters through a parameter list or other structure. The parameters can be constants, keys, data structures, objects, object classes, variables, data types, pointers, arrays, lists, or pointers to functions or methods or another way of referring to data or other items to be passed via the API.

[0100] In addition, data types or classes may be provided by the API and implemented by the API implementation component. Thus, the API calling component can utilize 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.

[0101] Typically, an API can be used to access services or data provided by an API implementation component, or to initiate the execution of operations or computations provided by the API implementation component. By way of example, the API implementation component and the API calling component can each be any one of an operating system, a library, a device driver, an API, an application, or other module (it should be understood that the API implementation component and the API calling 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 a client program to use services provided by a Software Development Kit (SDK) library. In other embodiments, an application or other client program can use an API provided by an application framework. In these embodiments, the application or client program can incorporate calls into functions or methods provided by the SDK and the API, or use data types or objects defined in the SDK and provided by the API. In these embodiments, the application framework can provide the main event loop for the program, which responds to various events defined by the framework. The API allows the application to utilize the application framework to specify events and responses to events. In some specific implementations, an API call can report the capabilities or status of a hardware device to an application, 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 implemented partially by firmware, microcode, or other low-level logic components executed partially on hardware components.

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

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

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

[0105] It should be understood that the API implementation component 1110 can 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 call component 1130. It should be understood that the API call component 1130 can be on the same system as the API implementation component 1110, or can be remotely located and use the API 1120 to access the API implementation component 1110 through a network. Although Figure 11 a single instance of the API call component 1130 interacting with the API 1120 is shown, it should be understood that other API call components, possibly written in a different language (or the same language) as the API call component 1130, can also use the API 1120.

[0106] The API implementation component 1110, the API 1120, and the API call component 1130 can 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, the machine-readable medium includes magnetic disks, optical disks, random access memories; read-only memories, flash memory devices, etc.

[0107] Figure 12is 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.

[0108] The memory interface 1202 may be coupled to a 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.).

[0109] Sensors, devices, and subsystems may be coupled to the peripheral device interface 1206 to facilitate a plurality of 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 face 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.

[0110] 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 photos 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 reproduction, digital recording, and telephone functions. In the intelligent media devices described herein, the audio subsystem 1226 may be a high-quality audio system including support for virtual surround sound.

[0111] 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 scheduling events from a remote calendar or event server.

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

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

[0114] In one embodiment, the I / O subsystem 1240 includes other input controllers 1245, which 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 up / down buttons for volume controls of controls / devices such as speakers 1228 and / or microphones 1230.

[0115] In one embodiment, the memory 1250 coupled to the memory interface 1202 may store instructions for an operating system 1252, including both POSIX - compliant and non - compliant operating systems or embedded operating systems. The operating system 1252 may include instructions for handling basic system services and for performing hardware - related tasks. In some embodiments, the operating system 1252 may be a kernel.

[0116] 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 retrieving 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.

[0117] In addition, the memory 1250 may store sensor processing instructions 1258 to facilitate sensor - related processing and functions; telephone instructions 1260 to facilitate telephone - related processes and functions; instant message 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 the camera; 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 video; and / or online shopping instructions to facilitate processes and functions related to online shopping. In some embodiments, the media processing instructions 1266 are divided into audio processing instructions and video processing instructions to respectively facilitate processes and functions related to audio processing and processes and functions related to video processing. Mobile device identifiers, such as the International Mobile Equipment Identity (IMEI) 1274 or similar hardware identifiers may also be stored in the memory 1250.

[0118] Each of the instructions and applications identified above may correspond to a set of instructions for performing one or more of the above - described functions. These instructions need not be implemented as separate software programs, processes, or modules. The 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.

[0119] Figure 13FIG. 1300 is a block diagram of a computing system 1300 according to an embodiment. The illustrated computer system 1300 is intended to represent a family of computing systems (wired or wireless), including, for example, one or more specific implementations of a desktop computer system, a laptop computer system, a tablet computer system, a cellular phone, a personal digital assistant (PDA) including a cellular-enabled PDA, a set-top box, an entertainment system or other consumer electronic device, a smart appliance device, or a smart media playback device. Alternative computing systems may include more, fewer, and / or different components. The computing system 1300 may be used to provide a computing device and / or a server device to which the computing device may be connected.

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

[0121] 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 and storing information and instructions for the processor 1310. The data storage device 1340 may be or include various storage devices, such as a flash memory device, a magnetic disk, or an optical disk, and may be coupled to the computing system 1300 via the interconnect 1335 or via a remote peripheral interface.

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

[0123] 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, and the antenna may represent one or more antennas. The computing system 1300 may include multiple wireless network interfaces, such as a combination of Wi-Fi and Bluetooth ® , near field communication (NFC), and / or cellular phone interfaces. The network interface 1380 may also include, for example, a wired network interface to communicate with a remote device via a network cable 1387, which may be, for example, an Ethernet cable, a coaxial cable, an optical fiber cable, a serial cable, or a parallel cable.

[0124] In one embodiment, the network interface 1380 may provide access to a local area network, for example, by conforming to the IEEE 802.11 wireless standard, and / or the wireless network interface may provide access to a personal area network, for example, by conforming to the Bluetooth standard. Other wireless network interfaces and / or protocols may also be supported. In addition to or instead of communicating via the wireless LAN standard, the network interface 1380 may use, 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 to provide wireless communication.

[0125] The computing system 1300 may also include one or more power sources 1305 and one or more energy measurement systems 1345. The power source 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 sources. The energy measurement system includes at least one voltage or current measurement device and can measure the energy consumed by the computing system 1300 over a predetermined period of time. In addition, one or more energy measurement systems may be included to measure, for example, the energy consumed by a display device, a cooling subsystem, a Wi-Fi subsystem, or other commonly used or high-energy-consuming subsystems.

[0126] Position data acquisition and trimming

[0127] Figure 14FIG. 1400 shows a system 1400 according to an embodiment, where a detector device may collect and prune location information of detected wireless beacon signals. The system 1400 includes hardware components such as a Bluetooth controller 1433, a real-time response processor (AOP) 1459, a Wi-Fi controller 1463, and an application processor 1434. The application processor 1434 (which may be a multi-core application processor) may execute an illustrated operating system daemon that facilitates location determination for detected wireless beacon signals. In one embodiment, the operating system components include a Bluetooth daemon 1427, a Wi-Fi daemon 1453, a location daemon 1401, and a search daemon 1437. Although Bluetooth beacon signals are described, these techniques are not limited to Bluetooth advertising, and other types of wireless advertising from wireless accessories may be used for crowdsourcing location determination of wireless accessories and devices.

[0128] The Bluetooth controller 1433 may execute including a low-power scanner 1431 that performs operations when the controller is activated. The low-power scanner 1431 may be used to detect the presence of nearby Bluetooth (e.g., Bluetooth Low Energy) devices that are broadcasting advertisements using radio signals. The specific configuration details of the Bluetooth controller 1433 may be determined by the Bluetooth daemon 1427, which includes Bluetooth processor logic 1423 and object discovery logic 1425. The Bluetooth processor logic 1423 may control the operation of the Bluetooth controller 1433. The object discovery logic 1425 may forward the time-tagged advertisements 1413 detected by the Bluetooth controller 1433 to the location daemon 1401 for further processing. In one embodiment, not all detected advertisements are forwarded for processing. Instead, only advertisements including a bit or flag indicating that the location of the device that is broadcasting should be determined and uploaded to the cloud server 1470 are forwarded, while other advertisements are ignored for the purposes of the illustrated system 1400. In one embodiment, the Bluetooth controller 1433 is configured to filter the scanned advertisements based on the type of advertisement, and may store only advertisements including a bit or flag indicating that the location of the device that is broadcasting should be determined and uploaded to the cloud server 1470.

[0129] In one embodiment, the Bluetooth controller 1433 may perform scanning and processing operations while the application processor 1434 is in a low-power state. The Bluetooth controller 1433 may buffer detected advertisements in the Bluetooth advertisement buffer 1429 instead of repeatedly interrupting the application processor when an advertisement is detected. The Bluetooth controller 1422 may include logic 1424 to deduplicate the Bluetooth advertisement buffer 1429 so that the buffer does not fill with the same advertisement. During a wake event of the application processor 1434, the Bluetooth advertisement buffer 1429 may opportunistically unload. The Wi-Fi controller 1463 may perform a scanning operation (1465) and store information related to detected Wi-Fi signals in the Wi-Fi scan buffer 1461. The application processor 1434 may attempt to match the detected advertisements with Wi-Fi signal data stored in the Wi-Fi scan buffer 1461 within the Wi-Fi controller 1463 via the Location Daemon 1401.

[0130] In one embodiment, the Wi-Fi scan buffer 1461 is a rolling buffer that stores the most recently detected SSIDs while overwriting earlier detected SSIDs. In one embodiment, the Wi-Fi scan buffer may be a fixed-size buffer having space for a predetermined number of entries. The Wi-Fi Daemon may configure the Wi-Fi controller 1463 to wake the application processor 1434 when the scan buffer becomes full or simply overwrite earlier detected SSIDs based on the WSB Wake / Full Roll Policy 1455 configured for the Wi-Fi Daemon 1453.

[0131] The Location Daemon 1401 includes a Cluster Location Service Interface 1403 and a Cluster Location Service Sub-collector 1405. The Cluster Location Service Interface 1403 is a service provider interface that enables the Search Daemon 1437 to query location information, including information about wireless accessories tracked by the Location Query Application 1435. The Cluster Location Service Sub-collector 1405 collects time-tagged advertisements 1413 and associates them with location information. The Cluster Location Service Sub-collector 1405 receives the time-tagged advertisements 1413 and stores these advertisements into the Beacon Cache 1407. The Zipper Logic 1409 uses data associated with the GPS Provider 1415, Wi-Fi Location Provider 1417, Signal Environment Provider 1419, and Motion Activity State 1421 to associate the time-tagged location data with the time-tagged advertisements 1413. This associated data is provided to the Service Provider Probe Framework 1411, which delivers the associated beacon data to the Beacon Payload Cache 1441 within the Search Daemon 1437.

[0132] In one embodiment, a GPS provider 1415 provides location data determined via signals received from a GPS device that communicates with a set of satellites associated with a global positioning or global navigation system (e.g., Global Positioning System, Global Navigation Satellite System, BeiDou-2, Galileo Global Navigation Satellite System, etc.). Generally speaking, in cases where GPS is specifically described herein and satellite-based positioning services are generally described, it should be understood that the satellite positioning technology may be performed using any Global Navigation Satellite System (GNSS). Location may also be determined via a Wi-Fi positioning provider that estimates the device location based on detected Wi-Fi SSIDs and / or Media Access Control (MAC) addresses. The location estimate may be further refined based on the RSSI associated with the detected signals. A signal environment provider 1419 may provide classification data regarding, for example, whether GPS or Wi-Fi positioning is optimal for a given geographic area. The signal environment provider 1419 may use an on-device classifier that estimates the likely accuracy of Wi-Fi positioning based on the number of detected Wi-Fi signals.

[0133] A motion activity state 1421 provides information regarding whether the detector device is stationary or in motion. The motion activity state 1421 may be determined, in part, based on a motion update 1457 provided by an AOP 1459. The AOP 1459 remains powered on while other processors within the detector device are in a low-power state. The AOP 1459 may collect data from motion sensors and defer the motion update 1457 until the application processor 1434 or other processors wake from the low-power state. Operations performed by a cluster location service sub-collector 1405 are further described in Figure 15 .

[0134] A search daemon 1437 communicates with a location query application 1435 that may be used to present a device locator UI 204. The search daemon 1437 also communicates with a set of cloud servers 1470 via a network (e.g., a device locator server 203 via network 114). The search daemon 1437 may process observations provided by a location daemon 1401 and provide those observations to the set of cloud servers 1470. The search daemon 1437 may also include an observation downloader and storage unit 1439 that downloads and stores location data for attachments and devices tracked by the location query application 1435. The location data may be downloaded from the cloud servers 1470 and queried from the location daemon 1401 via a cluster location service interface 1403.

[0135] The search daemon 1437 receives beacon data from the service provider detector framework 1411 and stores the beacon data in the beacon payload cache 1441. The search daemon 1437 includes a deduplication logic component 1443 to deduplicate the beacon payloads. The public key (e.g., beacon ID) broadcast with the beacon is used to encrypt (1447) the location data within the deduplicated beacon payloads. The beacon data and associated encrypted locations can be stored in the beacon upload cache 1449 before being uploaded to the cloud server 1470. When the beacon data is ready for upload, the search daemon 1437 can activate the queue and request upload logic component 1451. The queue and request upload logic component 1451 can communicate with the active scheduler 1445 to upload the data to the cloud server 1470 during the next server upload interval. The number of beacons uploaded to the cloud server 1470 can be limited. Additionally, data can be sent opportunistically when other unrelated data is to be transmitted over the network.

[0136] The uploaded beacon data includes: the location associated with the beacon, which is encrypted using the public key transmitted as the beacon identifier; a timestamp associated with when the beacon was detected; and a hash of the public key used to encrypt the location data. The cloud server 1470 can use the hash of the public key to index the encrypted location data and the timestamp. Using the hash of the public key prevents the cloud server 1470 from obtaining direct information about the owner of the attachment associated with the stored data, while allowing the owner of the attachment to query the device location using the hash of the public key known to the owner of the attachment.

[0137] Figure 15 A system 1500 for associating detected beacon advertisements with locations in accordance with an embodiment is shown. The system 1500 includes the aforementioned cluster location service sub-collector 1405, which includes the aforementioned beacon cache 1407, zipper logic component 1409, and service provider detector framework 1411. The cluster location service sub-collector 1405 also includes context data, which includes at least a subset of the last location 1521 of the device, the last motion state 1523, the last signal environment state 1525, and the current operation settings 1527. The context data is updated upon receiving or detecting various events. The last location 1521 is updated based on receiving a power-on location event 1529. The last motion state 1523 is updated based on receiving a power-on motion state event 1531. The last signal environment 1525 is updated based on receiving a power-on signal environment event 1533. The operation settings 1527 are updated in response to an update operation settings event 1535.

[0138] In one embodiment, when a new advertisement is received at the beacon cache 1407, the zipper logic component 1409 may determine (1507) whether the advertisement can be position-tagged. The zipper logic component 1409 may examine the last position 1521 and the timestamp associated with the last position. If the time at which the last position was determined is more than a threshold number of seconds after the time the beacon advertisement was detected, it may not be possible to reliably determine the position for the beacon advertisement. In such a case, the beacon advertisement may be discarded. If the time at which the last position was determined is more than a threshold number of seconds before the time the beacon advertisement was detected, the position may be expired and the zipper logic component 1409 may actively request a position (1509). If the last position 1521 is within a threshold number of seconds of the time of the timestamp associated with the beacon advertisement, it is determined that the advertisement can be position-tagged. The position is attached to the beacon advertisement and saved as a beacon payload by the service provider detector framework 1411.

[0139] If the zipper logic component 1409 actively requests a position (1509), the logic component may determine whether to allow GPS (1511). For various reasons, such as if the last signal environment 1525 indicates that GPS may be inaccurate or Wi-Fi may be more accurate, the use of GPS may be allowed or not allowed. The use of GPS may also be determined based on the operating settings 1527. If GPS is allowed, the zipper logic component 1409 may use Figure 14 the GPS provider 1415 shown to request a position via GPS (1515). If GPS is not allowed, the zipper logic component 1409 may use Figure 14 the Wi-Fi location provider 1417 shown to request a position (1513) using the Wi-Fi location service. In some embodiments, the request for Wi-Fi position determination may also utilize positioning techniques based on RF signals received from other wireless base stations (such as cellular or mobile network towers). After the request, the cluster location service sub-collector 1405 may perform an operation (1517) to monitor for a timeout of the position request. If a position is received, the received power-on position event 1529 will fire and the last position 1521 will be updated. If a position is received within a threshold number of seconds of the indicated advertisement time, the position may be associated with the advertisement.

[0140] The specific threshold used to determine whether a position can be attached to an advertisement may be changed based on the last motion state 1523 of the detector device or historical motion state data stored by the device. If the detector device is moving, the threshold is decreased such that the time between advertisement detection and position determination before associating the position with the advertisement will be relatively short (e.g., 45 seconds). However, if the device is not moving, the threshold may be increased (e.g., 600 seconds) because the position data of the detector device is more likely to be accurate and not change during that time period.

[0141] When determining a location for a beacon advertisement, a confidence score may also be assigned to the location. The confidence score allows the search daemon 1437 to deduplicate and refine the beacon payload. The confidence score also allows the cloud server 1470 to refine the location estimates received for an attachment or device across multiple detectors that may be sending location data for the attachment or device.

[0142] The confidence score may be determined based on an uncertainty value associated with the location. The degree of uncertainty may be determined based on an assessment of the accuracy of the location determined for the advertisement. Specifically, the location determined by the detector device is the location of the device. Additional calculations are performed to attempt to determine the location of the beacon device relative to the detector device as the detector device and wireless attachment enter and leave each other's range. In one embodiment, beacon RSSI or UWB ranging may be used, as Figure 7 shown. The cluster location service may obtain a cluster of locations and the certainties associated with those locations, and refine the cluster of locations into one or more locations that are the best estimate of the location of the object during the time the object was detected.

[0143] To refine the cluster of locations, a list of potential locations of the detected advertisement may be sorted by time. The location list may be traversed from most recent to earliest, and each location may be analyzed to determine if the location is contiguous with a previous reading. If the locations appear to be contiguous, a weighted average of the locations is taken and used as the location of the beacon, where the weights used for the averaging are the uncertainty measures of the locations. If there is a single non-contiguous location, that location may be discarded. However, if multiple locations are detected that indicate the beacon object is moving, the averaging process is stopped and multiple locations may be reported for the object. Using these analysis techniques, the cluster location service may determine, for example, whether the beacon object is moving past a stationary detector device, whether the beacon object is stationary while the detector device moves past, or whether the beacon object and the detector device are in motion relative to each other. This determination may be used to further refine the location data and produce one or more estimated locations of the beacon object, rather than simply producing a set of locations of the detector device when the beacon object was detected.

[0144] Figure 16 A method 1600 for collecting beacon advertisements while the detector device is in a low power state is shown. Method 1600 may be performed by a device having similar to Figure 14performed by the devices of the system 1400 of the system. In one embodiment, method 1600 includes using a wireless processor to scan for beacon advertisements when the application processor is in a low-power state (block 1601). The advertisement scan is performed by a wireless controller, such as but not limited to a Bluetooth controller (e.g., Bluetooth controller 1433) including an advertisement buffer (e.g., Bluetooth advertisement buffer 1429), which can store detected advertisements when the application processor (e.g., application processor 1434) is in a low-power state. When a beacon advertisement is detected, the wireless controller may store the beacon and timestamp in the beacon advertisement buffer (block 1602). The wireless controller may also include logic for performing an operation to process the beacon advertisement buffer to remove duplicate entries (block 1603). When the application processor wakes up from the low-power state, the wireless controller may transfer the buffer entries to the application processor (block 1604). Then, the application processor may associate the beacon advertisement with stored location data to determine a location estimate of the device associated with the beacon advertisement (block 1605).

[0145] Figures 17A to 17B Method 1700 for pruning the detected locations for objects is shown. In one embodiment, method 1700 may be performed by a search daemon 1437 on data stored in a beacon upload cache 1449. In one embodiment, method 1700 may be performed by a deduplication logic 1443 during deduplication of data stored in a beacon payload cache 1441.

[0146] As Figure 17A shown, method 1700 includes an operation of sorting the stored observations by scan date (block 1701). Observations of individual beacon objects may be sorted separately. Method 1700 also includes an operation of calculating the median horizontal accuracy of the observations (block 1702). A separate median horizontal accuracy may be calculated for each individual object observed. Method 1700 also includes an operation of retaining the first observation and scan date for each unique key (block 1703). Each unique key within a privacy period may represent a separate detected object. For subsequent observations with the same key, method 1700 includes performing a prune / discard operation on the observation (block 1704). Method 1700 continues in Figure 17B this regard.

[0147] As Figure 17B shown, for each observation and for each object, a prune / discard operation 1704 including multiple sub-operations may be performed. In one embodiment, the sub-operations include a sub-operation for determining whether the current number of retained observations for the object is greater than the maximum configured number of observations for the observation (block 1711). The maximum number of observations for an object may be a predetermined number that can vary dynamically. If the maximum number of observations has been retained, the observation is discarded (block 1715).

[0148] Additional sub - operations include determining whether the scan date of an observation is greater than N seconds since the last retained observation (block 1712), because when multiple observations of the same object are very close in time, retaining these observations may not be beneficial. If the scan date is not greater than N seconds since the last retained observation, the observation is discarded (block 1715).

[0149] Additional sub - operations include determining the observed value of the observation and determining whether the observed value is greater than a threshold (block 1713). In one embodiment, an observed value (e.g., high, medium, low) can be assigned to an observation based on multiple factors, including the confidence score of the location associated with the observation. The observed value can also be based on factors such as RSSI associated with the observation, e.g., an observation based on a weak / remote signal can be considered to have a lower value than an observation based on a stronger / closer signal. If the observed value is not greater than or equal to the threshold observed value (e.g., medium), the observation can be discarded (block 1715).

[0150] Referring to the operation for calculating the median - level accuracy of observations of an object at block 1702, additional sub - operations are performed to determine whether the level accuracy of an observation is greater than the median - level accuracy of the currently retained observations (block 1714). If the level accuracy of the observation is not greater than the median, the observation can be discarded (block 1715). If the observation passes the review of the previous sub - operations (block 1711, block 1712, block 1713) and the sub - operation at block 1714, the observation and the associated scan date (e.g., timestamp) are retained (block 1716). The retained observations can be further processed to upload to a cloud server (e.g., cloud server 1470) that stores the locations submitted by the detectors of the wireless object and beacon.

[0151] Figure 18 is a method 1800 for processing device location data on a server according to an embodiment. Method 1800 can be executed by a device locator server such as device locator server 203 and / or cloud server 1454. Method 1800 includes an operation of reviewing a set of submitted locations of a device (block 1801). The review is for observations of a single device or attachment and includes all observations submitted from multiple detector devices. For example, if a wireless attachment or device is sending beacons in a signal - busy area, multiple devices may send the location of the attachment or device. Then, the server can review the locations of the device submitted by the multiple detector devices to further define the device location data. Reviewing the locations can include analyzing the confidence scores of the individual locations (block 1802).

[0152] If the server detects an active location query for a device whose location data is being refined (block 1803), the server may bypass some steps of the refinement process and send the current location data to the client device in response to the location query (block 1804). If there are no location queries pending for the device, the server may spend additional time refining the location data based on a location confidence score (block 1805). Refining the data may include, for example, determining an estimated location of the device or attachment based on the locations reported by multiple detector devices. In one implementation, refining the location data based on the confidence score may additionally include a weighted averaging operation across the locations submitted by multiple detectors, where the average is weighted based on the confidence score. If a location query is received at any time during the refinement (block 1803), the server may send the current location data in response to the query (block 1804).

[0153] If, after sending the current location data, the server receives an indication that the device is in motion (block 1806), the server may be configured to send a continuous feed of location data when new location data is received (block 1808). Since the location data may be encrypted, the server will not directly know whether the queried device or attachment is in motion. However, various detector devices may be able to determine that the observed device or attachment is in motion and may send a motion state flag to the server. If the device is not in motion, the server may continue to refine the location data based on the confidence score (block 1805).

[0154] Figures 19A to 19C A system and method for sending advertising beacons on a laptop device are shown. Crowdsourced location determination based on beacon advertising as described herein can be used for a variety of different types of devices and attachments, including wireless devices with network or cellular access and wireless attachments without current or local network access. Generally, a laptop device will be able to access the network via a Wi-Fi access point and send location updates to a device location server. In one implementation, when the laptop device is not connected to the network, the device may begin broadcasting wireless advertisements, such as Bluetooth Low Energy advertisements, which can be used to determine the location of the device via nearby detector devices.

[0155] As Figure 19AAs shown, an electronic device 1902 such as a laptop computer or a tablet computer can connect to a network 114 via a wireless network protocol (e.g., Wi-Fi), a mobile wireless network (e.g., cellular), or via a wired network connection (e.g., Ethernet). Location updates of the device can be sent via the network 114 to enable the device to be located. If the laptop device 1902 becomes disconnected from the network 114 for any of a variety of reasons, the laptop device 1902 can begin to broadcast beacon advertisements 1904 via a radio device that allows nearby detector devices to determine the location of the electronic device 1902 and upload that location to a device location server. A method 1910 for enabling an advertising beacon is shown in Figure 19B In. Figure 19C A method 1920 for cycling advertising beacons is shown in for privacy and power saving purposes.

[0156] As Figure 19B shown, the method 1910 includes preparing an electronic device such as a laptop device or a tablet computer into a low-power state (block 1911). For example, the electronic device can be prepared to be placed in a sleep state in which parts of the device are turned off or in a low-power state while the memory of the device remains at least partially powered on to retain application programs and system states. In some embodiments, the data in the memory can be written to a non-volatile storage device, and the electronic device can enter a standby state in which a greater number of components of the electronic device (including the memory storing the device state) can be powered down. After the device has been in the sleep state for a period of time, it can enter the standby state.

[0157] When the electronic device is initially prepared to transition to a low-power (sleep or standby) state, the electronic device can determine whether there is a connection to a known network (block 1912). For example, the electronic device can determine whether the device is connected to a known Wi-Fi access point or a switch / router with a known MAC address. In one embodiment, the known network is a network to which the electronic device has previously connected. In one embodiment, the known network is a network to which the electronic device has previously connected and is configured to automatically join. In one embodiment, the known network can be a network at a pre-configured location such as a home network or a work network. In one embodiment, the known network is a network at a frequently visited location of interest and the electronic device is configured to automatically join.

[0158] If the electronic device is connected to a known network, the electronic device may remain connected to the network for a period of time (block 1913). After this time period, the electronic device may disconnect from the network (block 1914). The electronic device may disconnect from the network, for example, in response to entering a deeper sleep state (e.g., standby). The electronic device may also remain in a sleep state (e.g., with the memory powered on), but disconnected from the network to conserve power. The time period may be a pre-determined time period (e.g., 12 hours) or may vary based on the battery state of the electronic device. In one embodiment, if the electronic device is connected to a power source, the device may remain connected to the network indefinitely. Depending on the power configuration of the device, even if the electronic device is connected to an external power source, the electronic device may disconnect from the network after a pre-determined time period to reduce overall power consumption.

[0159] When the electronic device is disconnected from the network, the electronic device may determine whether the current location of the device is a secure location of interest (block 1915). In one embodiment, multiple secure locations of interest may be configured. By default, the user's "home" location is the default location of interest. If the electronic device disconnects from the network while in a secure location of interest, the user may know the location of the device before the electronic device disconnects from the network or will attempt to locate the device. In such scenarios, the electronic device will not transmit a beacon (block 1917).

[0160] If not connected to a known network (block 1912), then after disconnecting from the network (block 1914) or upon entering a low power state when not in a secure location of interest (block 1915), the electronic device may start a wireless beacon cycle (block 1916). During the wireless beacon cycle, the device broadcasts beacon advertisements so that a detector device can detect the presence of the device. Then, the detector device may upload the location of the electronic device to the device location server, as described above. The wireless beacon cycle may be implemented via Figure 19B method 1920.

[0161] As Figure 19BAs shown, method 1920 includes an electronic device configuring a wireless controller on the electronic device to broadcast a beacon identifier based on a set of keys (block 1921). The wireless controller can be, but is not limited to, a Bluetooth or Bluetooth Low Energy controller. In some embodiments, other types of low-power wireless protocols can be used. The wireless controller can be configured by the electronic device when active, and the electronic device can enter a low-power state when the wireless controller broadcasts beacon advertisements. The beacon identifier is based on a set of keys that includes a public key associated with the electronic device. The electronic device can broadcast the beacon identifier during a first time period (block 1922). In one embodiment, the first time period can be a first privacy time period during which advertisements will be broadcast based on the public key. After the first privacy time period, the electronic device can use the anti-tracking secret as described above to generate a new set of keys, including a new public key that can be used as the next beacon identifier.

[0162] Then, the electronic device can configure the wireless controller to broadcast the next beacon identifier based on the new set of keys (block 1923). Then, the electronic device can broadcast the next beacon identifier during a second time period (block 1924). The electronic device can continue to cycle the beacon identifier until a broadcast timeout is reached (block 1925). Once the broadcast timeout is reached, the electronic device can stop broadcasting during a third time period (block 1926). The electronic device can stop broadcasting to conserve battery life or reduce the power consumption of the electronic device. Depending on the location and time, the electronic device can also stop broadcasting during a time period when it is unlikely that a detector will detect the device nearby.

[0163] The electronic device can also periodically reconfigure the broadcast schedule (block 1927) before resuming broadcasting (block 1921). When resuming broadcasting, the electronic device can broadcast using a beacon identifier different from the previously advertised beacon identifier. When reconfiguring the broadcast schedule, the electronic device can change the time when the beacon is advertised and / or the number of times the beacon is advertised during a 24-hour period.

[0164] In one embodiment, the wireless controller is directly controlled by an application processor of the electronic device, and the electronic device is temporarily awakened from a sleep state to change the advertisement broadcast by the wireless controller. In such embodiments, the electronic device can broadcast more frequently during the first day of broadcasting and less frequently during the second day of broadcasting. For example, during the first day of advertisement broadcasting, the electronic device can broadcast for two hours, with the beacon identifier cycling every 15 minutes. Then, the electronic device can stop broadcasting for three hours and then resume broadcasting for two hours. During the second day, the electronic device can broadcast twice a day, with each broadcast period lasting one hour.

[0165] In one embodiment, the wireless controller includes a buffer that may include a plurality of pre-generated key sets and beacon identifiers. The wireless controller may then be configured to automatically cycle through the beacon identifiers without requiring the electronic device to wake up from a low-power state.

[0166] Detecting beacon advertisements broadcast by known devices

[0167] The embodiments described herein provide a wireless beacon device that can be used to track or locate an item to which a wireless beacon device is attached. The wireless beacon device and an accompanying device may be cryptographically associated using, for example, Figure 3 the public key exchange (310) shown or via a collaborative key generation process. During the collaborative key generation process, the accompanying device and the wireless beacon device may work together to generate a set of base keys. The collaborative key generation algorithm enables the accompanying device and the wireless beacon device to separately generate the set of base keys after exchanging baseline cryptographic material. Each device can then use the base keys to generate additional diversified keys. The diversified keys may be used to determine the wireless hardware broadcast address (e.g., MAC address) used by the wireless beacon device. The diversified keys may also be used to derive cryptographic keys that enable an encrypted communication link to be established between the accompanying device and the wireless beacon device.

[0168] The collaboratively generated keys may be used to configure the wireless hardware address of the beacon advertised by the wireless beacon device. The accompanying device may detect a known device by searching for beacon advertisements that have a hardware address that matches the public key of the known device. Various different classes of mobile devices (e.g., mobile phones, laptop devices, tablet computers, locator tags, etc.) may be configured to broadcast beacons (e.g., field mode beacons) that enable a detector device to detect the presence of these devices and upload an estimated location of the device to a device locator server. The wireless beacon device may also be configured to send beacons in a near-owner mode when the device is within the wireless communication range of its accompanying device or for a period of time after an encrypted communication session between the accompanying device and the wireless beacon device has terminated. The wireless beacon device may be configured to transition to sending beacons in a field mode state after the device has sent beacons in the near-owner mode for a threshold period of time.

[0169] The advertisement packets broadcast by the wireless beacon device may vary according to the advertisement mode of the device. Figure 20 Near-owner and field mode advertisement packets are shown in Figure 21A method for converting from a near-owner mode to a wild mode is shown. Based on the type of packet detected for a beacon device, a matching process is performed to determine whether the beacon device is a known device, and this matching process can occur in real time or be postponed to a later time period. In one embodiment, real-time matching is performed for a device that sends a beacon in the near-owner mode, while the matching for a device in the wild mode can be postponed until a beacon announcement event.

[0170] Figure 20 An advertisement beacon packet 2010 for a wireless accessory is shown. The advertisement packet broadcast by the wireless accessory can vary based on whether the accessory is in the near-owner mode (packet 2011), in the wild beacon state (packet 2012), or is advertising unwanted tracking determination or suppression data (packet 2013). In one embodiment, the advertisement packet can be a Bluetooth Low Energy advertisement packet. However, the embodiments are not limited to this. Additionally, the packet format can be different from the standard wireless protocol advertisement packet.

[0171] In one embodiment, the near-owner advertisement packet 2011 includes a first public key portion (PubKey1 / 2) that serves as an advertisement address. The first public key portion can include the first six bytes of the current public key of the wireless accessory. In one embodiment, the most significant bits of the advertisement address are constrained to the value 0b11, which designates a static device address. In contrast, if the wireless accessory is a wireless beacon tag, the actual address bits are stored in the EK (extra key) field along with the bits that define the tag type of the wireless accessory. The near-owner packet can additionally include fields L1, T1, CID, T2, L2, and S1. L1 is the length of the advertisement type field, T1 is the advertisement type field, CID is the companion ID field, T2 is the payload type (e.g., object discovery), L2 is the length of the object discovery field, and S1 is the status flag field. The length of the object discovery payload can vary depending on whether the wireless accessory is in the near-owner mode or the wild mode. The status flag field can include, for example, the battery status and additional device type markers, such as whether the wireless accessory is a wireless beacon tag.

[0172] In one embodiment, the wild mode advertisement packet 2012 can include fields similar to those of the near-owner advertisement packet 2011. The wild mode advertisement packet 2012 can additionally include a second public key portion (PubKey2 / 2) that includes additional bits of the public key. In one embodiment, the additional bits of the public key or the combined public key (PubKey1 / 2, PubKey2 / 2, EK) can be used as a static identifier for the wireless accessory, which allows suppression of unwanted tracking notifications. In one embodiment, the combined public key can also be used by a detector device as an encryption key to encrypt the observed location of the wireless beacon when uploading the observation to a device locator server.

[0173] In one embodiment, the wireless accessory is configured to broadcast separate UT advertisement packets 2013 and field mode advertisement packets 2012 in an alternating sequence when the accessory is in field mode. The UT advertisement packets 2013 may include RPA1 and RPA2 values that can be used to ignore or suppress notifications until the end of the day or indefinitely. The RPA1 and RPA2 values are based on a diversified public key and an IRK value, and the diversified public key rolls over every privacy period (e.g., every 15 minutes). In one embodiment, the IRK_EOD rolls over every 24 hours, and the IRK_INDEF does not roll over unless the wireless accessory undergoes a factory reset. The wireless accessory may undergo a factory reset in response to unpairing the accessory from an accompanying device.

[0174] The UT advertisement packets 2013 are optional. In one embodiment, the UT advertisement packets 2013 may be excluded and suppression may be performed by using one or more static identifiers associated with the wireless accessory. The static identifier may be configured to roll over every 24 hours, allowing suppression of unwanted tracking notifications for the accessory once per day. For example, in one embodiment, the diversified public key of the device while in field mode may continue to roll internally for the accessory, while the field mode advertisement address is configured to roll for the wireless accessory, e.g., at midnight local time. During key rollover, the currently active internal public key may be configured as the advertisement address for beacon advertisements. To assist the owner device in reconnecting to the accessory while in field mode, the field mode advertisement packet 2012 may include a hint field HT that contains a set of bits (e.g., a set of least significant bits) of the public key currently used by the accessory. The owner device may use this information to generate the correct owner key, owner token, and / or connection key to place the wireless accessory in near-owner mode. Once in near-owner mode, the wireless accessory may start advertising using the near-owner advertisement packet 2011.

[0175] Figure 21 A method 2100 for enabling a transition from near-owner advertisement mode to field advertisement mode is shown. The method 2100 may be performed by any wireless device, wireless accessory, or wireless accessory device as described herein. In one embodiment, after the wireless device disconnects from an encrypted connection established with an electronic device (block 2101), the wireless device may send a beacon in near-owner mode using the near-owner advertisement packet (block 2102). The near-owner advertisement packet may be Figure 20Variant of the Near Owner Mode Packet 2011. The wireless device may also configure or update the Near Owner timeout (block 2103) based on location and / or motion state. The Near Owner timeout may be increased from a default value when the wireless device is at a home location or a point of interest or another location or point of interest designated as a secure location. The Near Owner timeout may be decreased from a default value when the wireless device is not at a secure location, is in motion, and / or has recently been in motion. The Near Owner timeout may be configured after the wireless device disconnects from an encrypted connection with an accompanying device. The Near Owner timeout may also be configured during the connection with the accompanying device based on context information determined by the wireless device during the connection or based on status information received from the accompanying device. Reducing the Near Owner timeout period reduces the amount of time that other devices configured to report detection of a Wild Mode beacon may take to detect a potentially lost wireless device.

[0176] After a period of time, the wireless device may determine whether the Near Owner timeout has been reached (block 2104). If the Near Owner timeout has not been reached (No at block 2104), the wireless device may continue to send beacons in Near Owner mode. If the Near Owner timeout has been reached (Yes at block 2104), the wireless device may send beacons in Wild Mode using a Wild Mode advertisement packet (block 2105). When in Wild Mode, the wireless device broadcasts a Wild Mode advertisement packet that can be discovered by detector devices within the wireless range of the wireless accessory. The Wild Mode advertisement packet may be Figure 20 a variant of the Wild Mode advertisement packet 2012. The beacon rate of the wireless device may be increased relative to the beacon rate when in Near Owner mode. When a Wild Mode advertisement is detected, nearby detector devices may attempt to determine or estimate the location of the wireless device relative to the detector device and upload the determined or estimated location to a device location server, where the determined or estimated location is indexed on the device location server by a hash of the Wild Mode address broadcast by the wireless device.

[0177] When the wireless device is in Wild Mode, privacy period key rolling may continue to be performed during each privacy period. Privacy period key rolling results in a change in the encryption key to be used to establish a connection with the wireless device. In one embodiment, unlike when in Near Owner mode, the advertisement address of the device in Wild Mode is not updated for each key roll. Instead, the advertisement address may be updated once every R key rolls, resulting in the advertisement address changing, for example, between every 24 - 36 hours. Keeping the same advertisement address for a period of time in Wild Mode may be beneficial in suppressing or ignoring unwanted tracking warnings for a period of time without the need for encryption techniques to determine whether multiple Wild Mode addresses of the wireless device resolve to the same device.

[0178] To reconnect with a wireless device in near-owner mode, the companion device may attempt to establish a connection with the wireless device using the wireless device's current advertising address and the wireless device's current encryption key. The companion device may maintain an estimate of the counter value on the wireless device that is used to generate a new key during each key roll. The companion device may connect to a wireless device in wild mode using a wild mode advertising address and a privacy period key, which may be generated by the companion device based on the counter estimate. In one embodiment, a key block may be pre-generated by the companion device over a period of time (e.g., 24 hours), and additional keys may be periodically generated to maintain a set of keys over that period.

[0179] Figures 22A to 22B A system for performing real-time and deferred key matching to detect beacons of known devices according to an embodiment is shown. Figure 22A A system for performing real-time key matching to detect known devices is shown. Figure 22B A system for performing real-time key matching to detect known devices for devices in near-owner mode and deferred key matching to detect known devices for devices in wild mode is shown.

[0180] As Figure 22A shown, entries in the beacon cache 1407 that store beacon advertisements may be read by the matching logic component 2202. In one embodiment, the matching logic component 2202 is configured to perform real-time detection of beacon advertisements of known devices that are broadcasting in near-owner mode and wild mode by performing a key matching operation. The matching logic component 2202 may use keys generated by the key generation logic component 2208 to detect beacons broadcast by known devices in the beacon cache 1407. Beacons may be sorted into a known device cache 2204 and an unknown device cache 2206. The known device cache 2204 may store a set of observations of devices known to the detecting electronic device. Devices known to the detecting electronic device include devices that are cryptographically associated with the detecting electronic device such that the detecting electronic device is, for example, the owner device of the detected wireless device (e.g., the companion device) or a device that has been authorized to interact with the detected wireless device. Locations may be determined for beacon entries in the known device cache, and these entries may be used to perform location updates for these devices. Entries in the unknown device cache 2206 may be processed by the filter logic component 2210 to enhance the location estimate determined for those beacons before the beacons and the estimated locations are stored in the beacon payload cache 1441.

[0181] Known devices in near-owner mode may be detected by matching a set of bytes broadcast as the wireless address of the wireless device. For example, a wireless device in near-owner mode may broadcast a near-owner advertisement packet 2011, asFigure 20 As shown, the near-owner advertisement packet includes a first public key portion (PubKey1 / 2) that serves as an advertisement address. The first public key portion (PubKey1 / 2) may include, for example, the first six bytes of the current public key for a wireless device, although the specific number of bytes may vary. The current public key for the wireless device may rotate every M minutes, and the current public key may be calculated in real time by the key generation logic 2208.

[0182] A wireless device in the wild mode may also be detected by matching a set of bytes broadcast as the wireless address of the wireless device. The number of bytes in the set of bytes to be matched for the wild mode is greater than that for the near-owner mode. For example, as Figure 20 shown, the wild mode advertisement packet 2012 may include a first public key portion (PubKey1 / 2) and a second public key portion (PubKey2 / 2). When the wireless device is in the wild mode, the public key for the wireless device may continue to rotate every M minutes. However, the first public key portion (PubKey1 / 2) and the second public key portion (PubKey2 / 2) advertised in the wild mode advertisement packet 2012 may not be updated during each key roll. Instead, one or more portions of the advertised public key may remain static during a predetermined number of key rolls. Thus, the number of public keys that can be checked for a wireless device in the wild mode may be greater than the number of keys that can be checked for a wireless device in the near-owner mode. The key generation logic 2208 is aware of the address update schedule and may generate multiple potential public keys for the wireless device, and these multiple potential public keys may be compared with entries in the beacon cache 1407 to determine whether any of these entries is associated with a known device transmitting a beacon in the wild mode.

[0183] Some embodiments described herein may be configured as shown in Figure 22B where the matching logic 2202 is configured to match entries in the beacon cache 1407 to perform known device detection for a wireless device transmitting a beacon in the near-owner mode. Beacons detected for known devices in the near-owner mode may be added as entries in the near-owner beacon cache 2214. In one embodiment, a near-owner beacon may be detected based on the specific structure of the near-owner advertisement packet 2011 relative to the wild mode advertisement packet 2012. Then, the matching logic 2212 may perform a key matching operation to determine whether the detected near-owner beacon is broadcast by a known device.

[0184] Real-time detection of beacons of wireless devices transmitting in near-owner mode, e.g., to facilitate maintenance operations on these devices. Maintenance operations may include periodic counter update operations to prevent counter drift, adjusting the near-owner mode timeout value, and / or configuring the field mode address update time and update interval. Beacons detected for devices transmitting in field mode may be placed in the field mode beacon cache 2216 without determining whether any detected devices in field mode are known devices. The greater number of potential keys and the more complex matching operations performed to detect known devices in field mode make field mode matching more processor-intensive than near-owner mode matching. Accordingly, some embodiments defer the key matching operation for field mode beacons. The matching operation may be deferred until processor resource requirements are low, such that the processor resource requirements are below a threshold. In one embodiment, the key matching operation for field mode beacons may be completely bypassed, where field mode observations of known devices are retrieved from the cloud server 1470 using device location queries.

[0185] As described above, the matching logic component 2212 may perform key matching of detected near-owner beacons by comparing a specific set of bytes in the address field of the near-owner beacon advertisement packet with the associated bytes of an encryption key (e.g., public key) associated with the wireless device. In one embodiment, unlike the real-time key generation using the key generation logic component 2208 as in Figure 22A a key block stored in the key store 2218 may be pre-generated (e.g., via the key generation logic component 2208), which will be valid for the set of known devices for a pre-determined period of time. The key block stored in the key store 2218 may be periodically refreshed to ensure that the keys are available within a pre-determined range, which may extend across a specified period of time before and after the current time.

[0186] For each detected beacon advertisement in the beacon cache 1407, the matching logic component 2212 may request the appropriate key for each device in a set of known devices during the time period in which the beacon advertisement is detected. If the bits in the appropriate key of the device match the bits in the address field (and / or another appropriate field in some embodiments) of the near-owner beacon advertisement, the beacon advertisement may be determined to be a near-owner beacon and stored in the near-owner beacon cache 2214.

[0187] Beacons detected as not matching the near-owner beacon can be stored in the field-mode beacon cache 2216. In one implementation, the known device matching for field-mode beacons can be deferred and executed in response to a processing event or another triggering event. For example, in response to a processing event 2217 scheduled by the activity scheduler 1445, the known device determination can be performed for the beacons in the field-mode beacon cache 2216. The processing event can be a trigger for the filter logic component 2210 to perform a location estimate for the beacon, enhance the location estimate determined for these beacons, perform the known device matching, or perform other activities before the beacon and the estimated location are stored in the beacon payload cache 1441. The known device determination can be performed in response to the startup of the device locator application of the device locator service and / or the presentation of the device locator user interface 204 on the mobile device 102. The known device determination can also be performed for the beacons in the field-mode beacon cache 2216 during the location estimation process of the detected beacons or during the publishing event when the beacon payload is uploaded to a set of cloud servers 1470. In one implementation, the known device matching for field-mode beacons can be bypassed, and all field-mode beacons can be filtered without performing a determination on whether the field-mode beacons are associated with known devices. Then, the location data of the known devices in the field mode can be determined by querying the cloud servers 1470 via the device locator user interface 204.

[0188] Figure 23 A method 2300 for performing matching for near-owner beacon advertisements according to an implementation is shown. The method 2300 can be executed on an electronic device that is an accompanying device of a wireless device (including a wireless beacon device). In one implementation, the electronic device can scan for beacon advertisements using the wireless processor of the electronic device (block 2301). Then, the electronic device can detect a beacon advertisement having a beacon advertisement packet (block 2302). Then, the electronic device can determine whether the beacon advertisement packet is a near-owner advertisement packet based on the structure of the beacon advertisement packet (block 2303). If the electronic device determines that the beacon advertisement packet is a near-owner packet (block 2304), the device can perform a key matching operation on the beacon advertisement packet to determine whether the beacon advertisement is associated with a known device (block 2305). Otherwise, the device can store the beacon advertisement and the timestamp in the beacon advertisement database for deferred processing (block 2306). In one implementation, if the beacon advertisement is associated with a known device, the electronic device can determine whether to establish a connection with the known device to perform the periodic maintenance operation as described above.

[0189] Horizontal accuracy adjustment for detected beacon devices

[0190] As described above, the horizontal accuracy associated with location determination can be used to refine and filter location estimates determined for detected wireless devices. In one embodiment, a location estimate for a detected wireless device can be determined based on an estimate of the location of the detector device and the range and direction between the detector device and the detected wireless device. Depending on the location determination technique (e.g., satellite positioning service 206 or a terrestrial positioning system that uses RF signals received from wireless base station 205, as Figure 2 shown), the horizontal accuracy or location uncertainty of a wireless device can vary.

[0191] Refer to Figure 14 , in one embodiment, the location daemon 1401 can provide a horizontal accuracy value and a location estimate of the electronic device to the cluster location service sub-collector 1405. Based on the on-device classifier associated with the signal environment provider 1419, the location daemon 1401 can request a location via the GPS provider 1415 or the Wi-Fi location provider 1417. The received location includes geographical coordinates (e.g., latitude and longitude) and an associated horizontal accuracy estimate representing the uncertainty of the geographical coordinates. The detector device can use the horizontal accuracy to filter beacon observations and refine the location estimates of the beacon observations. The horizontal accuracy of the location of the beacon observations can also be used by a set of cloud servers 1470 to refine, filter, and combine beacon observations reported by multiple detector devices for the same beacon identifier.

[0192] In one embodiment, the location determination of the detector device can be performed asynchronously with the detection of beacon advertisements. The location of the detector device will not be actively determined unless the most recent location data determined for the detector device is outside a time threshold before or after the detection of the beacon advertisement, where the time threshold is reduced when the detector device is in motion. For example, the zipper logic component 1409 in the cluster location service sub-collector 1405 can determine whether the advertisement can be location-tagged, where the location is determined by the detector device based on a timestamp associated with the detection of the beacon advertisement and the determination of the location estimate of the detector device.

[0193] Figure 24Illustrates the adjustment of the horizontal accuracy of a mobile detector device. The wireless accessory 201 may periodically broadcast a beacon signal 301 that includes device status information and a beacon identifier (e.g., a public key). The detector device 202 may detect the beacon signal and cache the advertisement packets received via the beacon signal 301. The determination of the position of the detector device 202 may occur asynchronously with the detection of the beacon signal 301. For example, when the detector device 202 is moving, the device may detect a beacon from the wireless accessory 201 at a first position 2402A, and the position subsystem of the detector device 202 may determine a position estimate of the detector device at a second position 2402B. The position determination at the second position 2402B may have an associated horizontal accuracy value (e.g., X meters), which allows for the determination of an uncertainty range 2404 of the position estimate. However, in this case, the uncertainty range 2404 associated with the detector device 202 does not accurately reflect the true degree of uncertainty of the beacon observations of the wireless accessory 201.

[0194] In one embodiment, the horizontal accuracy of the position estimate of the detector device may be adjusted by determining the horizontal accuracy associated with the beacon observation based on the distance the detector device has traveled between the beacon observation time and the position determination time, so as to achieve the adjusted horizontal accuracy 2406. The distance traveled may be estimated based on an estimate of the speed of the detector device 202 during the interval between beacon detection and position determination. Various speed estimation techniques may be applied, as described below with respect to Figure 25 described.

[0195] The adjusted horizontal accuracy 2406 may be provided as an input to the beacon position estimation logic component together with the estimates of the distance and angle between the detector device 202 and the wireless accessory 201 when the beacon signal 301 is detected. The estimates of the distance and angle may be determined via techniques such as RSSI analysis or UWB ranging, as described herein. The beacon position estimation logic component may then estimate the position of the detected beacon, which may have an associated beacon uncertainty range 2408.

[0196] Although the beacon signal 301 is shown as being detected before determining the position estimate associated with the beacon, position determinations that occur within a threshold time period before the detection of the beacon signal 301 may also be used. In one embodiment, if multiple position determinations are made within the threshold before and after the detection of the beacon signal 301, the multiple position determinations may be used to refine the estimated position of the wireless accessory.

[0197] Figure 25Shown is a system 2500 that can be used on a detector device to perform horizontal accuracy adjustment on a detected beacon device. In one embodiment, system 2500 includes a motion classifier 2501, a position subsystem 2502, and a horizontal accuracy adjustment subsystem 2505. Based on the motion activity state 2503 received from the motion classifier 2501 and the position state 2504 received from the position subsystem, the horizontal accuracy adjustment subsystem 2505 can determine the adjusted horizontal accuracy of the beacon observation 2506 to be stored in the beacon payload cache 1441. The components of the system, as well as the techniques and processes performed by these components, will be described in the context of a detector device, which is any electronic device configured to detect beacon signals (e.g., field mode beacons) broadcast by the wireless devices, wireless accessories, and / or wireless accessory devices described herein and upload an estimated position of the detected device to a server associated with a crowdsourced device positioning system (e.g., cloud server 1470, device locator server 203).

[0198] The motion activity state 2503 can be the same as or similar to the motion activity state 1421 of Figure 14 and provides information on whether the detector device is stationary or in motion. The motion classifier 2501 can determine the motion activity state based on the motion context determined from measurements provided by a motion sensor (e.g., motion sensor 1210 as shown in Figure 12 ). The motion sensor can include multiple sensors such as an accelerometer or a gyroscope. Data from other sensors (e.g., magnetometer, gravity sensor, etc.) can also be used to define the motion context of the device. The motion classifier 2501 can determine an estimate of the type of motion the detector device is performing. The type of motion can be the motion activity being performed by the user carrying the device. For example, the motion classifier 2501 can analyze the sensor data to determine whether the user carrying or wearing the detector device is walking, running, cycling, skiing, swimming, or moving via another means based on the motion context data. The motion classifier 2501 can also determine whether the detector device 202 is in a moving vehicle. Such a determination can be included in the motion activity state 2503. The motion activity state 2503 can also include a speed, which can be the average speed determined for the detector device when the device is in a moving state or a default speed associated with determining the motion state when the speed of the device cannot be determined.

[0199] The position subsystem 2502 includes hardware components and software components that can use a position determination system to determine an estimated position of an electronic device. In one embodiment, the position subsystem 2502 includes logic components that determine or estimate the device position based on satellite positioning services 206 or a terrestrial positioning system that uses RF signals received from a wireless base station 205, as shown in Figure 2As shown, for example, Figure 14 the position determination component shown. The position subsystem 2502 can maintain a position state 2504 that includes the most recently determined position of the detector device and the horizontal accuracy associated with that determined position. In some embodiments, the position state 2504 also includes an instantaneous velocity or velocity metric. For example, if the position state is determined based on data from a satellite positioning service, the velocity determined via the satellite positioning data can be included in the position state 2504.

[0200] In one embodiment, the horizontal accuracy adjustment subsystem 2505 includes hardware and software logic components that adjust the initial horizontal accuracy of a beacon observation 2506 to account for the interval between the beacon observation and the position determination. In one embodiment, the horizontal accuracy of the beacon observation 2506 can be input into the horizontal accuracy adjustment subsystem 2505 along with the position determination interval, which specifies the amount of time between the detection of a beacon advertisement associated with the beacon observation and the position estimate used to tag the beacon observation. One or more velocities associated with one or more instances of the motion activity state 2503 during the interval and the velocity data from the position state 2504 can be analyzed synergistically to estimate the average velocity of the detector device during the position determination interval. The average velocity can then be multiplied by the duration of the position determination interval to determine an adjustment amount for adjusting the horizontal accuracy of the position determination to generate an adjusted horizontal accuracy. The adjusted horizontal accuracy can be stored to the beacon observation 2506, which can then be stored to the beacon payload cache 1441. In one embodiment, the horizontal accuracy adjustment can be performed before the beacon observation is stored in the beacon payload cache 1441. In one embodiment, the beacon observation can be stored to the beacon payload cache and the horizontal accuracy adjustment can be performed asynchronously.

[0201] Figure 26 A method 2600 for horizontal accuracy adjustment of a detected beacon device is shown. The method 2600 can be performed by an electronic device (e.g., a detector device) to adjust the horizontal accuracy metric of a beacon observation detected while the detector device is in motion.

[0202] The detector device can detect beacon advertisements from the beacon wireless device (block 2601). The detector device can then associate the beacon advertisement with a location estimate determined by the electronic device (block 2602). The detector device can then sample the motion state data of the electronic device during a location determination interval, which is the interval between the detection of the beacon advertisement and the determination of the associated location estimate (block 2603). If the position state information of the detector device during the location determination interval includes velocity data (Yes at block 2604), the detector device can adjust the horizontal accuracy of the location estimate based on a comparison of the velocity data with the velocity determined via the motion state (block 2605). In one embodiment, the velocity data includes velocity and direction data determined via a satellite-based positioning and navigation system (e.g., GPS).

[0203] In one embodiment, the adjustment is based on the greater of the magnitude of the velocity indicated by the velocity data and the velocity indicated for the motion state. The velocity indicated for the motion state can be a sensor-based velocity calculation or can be a default velocity associated with each motion state. In one embodiment, the adjustment can be based on other calculations, such as a weighted average of the instantaneous velocity determined via the velocity data and the velocity associated with the motion state. If no velocity data is available (No at block 2604), the detector device can adjust the horizontal accuracy of the location estimate based entirely on the velocity determined via the motion state data (block 2606). The adjustment of the horizontal accuracy improves the accuracy of location filtering and processing on the detector device and downstream after the beacon observations are uploaded to the server of the device locator service.

[0204] References herein to "one embodiment" or "an embodiment" mean that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the invention. The phrase "in one embodiment" appearing in various places in this specification is not necessarily all referring to the same embodiment. The processes depicted in the subsequent figures can be executed by processing logic that includes hardware (e.g., circuits, dedicated logic), software (as instructions on a non-transitory machine-readable storage medium), or a combination of hardware and software. Reference will now be made in detail to various embodiments, examples of which are illustrated in the figures. Numerous specific details are set forth in the following detailed description in order to provide a thorough understanding of the invention. However, it will be apparent to those skilled in the art that the invention can be practiced without these specific details. In other instances, well-known methods, processes, components, circuits, and networks have not been described in detail so as not to unnecessarily obscure aspects of the embodiments.

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

[0206] The terms used herein are for the purpose of describing particular embodiments only and are not intended to limit all embodiments. As used in the specification of the present invention 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 term "and / or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. It will also be understood that the term "comprises" (or "comprises" and / or "comprising") when used in this specification is specifying the presence of the stated features, integers, steps, operations, elements, and / or components, but does not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or their groups.

[0207] As used herein, depending on the context, the term "if" can be interpreted to mean "when", "at the time of", "in response to a determination", or "in response to detecting". Similarly, depending on the context, the phrase "if a determination is made..." or "if [the stated condition or event] is detected" can be interpreted to mean "when a determination is made...", "in response to a determination...", "at the time of detecting [the stated condition or event]", or "in response to detecting [the stated condition or event]".

[0208] Computing devices, user interfaces for such devices, and associated processes for using such devices are described. In some embodiments, the computing device is a portable communication device, such as a mobile phone, that also includes other functions, such as 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 generally apply to any type of wireless device, wireless accessory, or wireless accessory device capable of broadcasting a wireless beacon.

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

[0210] The embodiments described herein provide an electronic device that includes a wireless processor coupled to a radio device, a memory for storing instructions, and one or more processors for executing these instructions. When executed by the one or more processors, the instructions cause the one or more processors to: scan for beacon advertisements using the wireless processor; store the beacon and a timestamp in a beacon advertisement buffer in response to detecting the beacon via the wireless processor; associate the beacon advertisement with stored location data to determine a location estimate of a device associated with the beacon advertisement; encrypt the location estimate of the beacon advertisement using a beacon identifier broadcast with the beacon identifier; and transmit a hash of the beacon identifier and the encrypted location estimate of the beacon advertisement to a device locator server. In one embodiment, when an application processor of the one or more processors is in a low power state, the one or more processors can scan for beacon advertisements using the wireless processor.

[0211] One embodiment provides a non-transitory machine-readable medium storing instructions that cause one or more processors of an electronic device to perform operations including: scanning for beacon advertisements using a wireless processor of the electronic device when an application processor of the electronic device is in a low power state; storing the beacon advertisement and a timestamp as an entry in a beacon advertisement buffer in response to detecting the beacon advertisement via the wireless processor; transmitting the buffer entry to the application processor when the application processor wakes up from the low power state; and associating the beacon advertisement with stored location data to determine a location estimate of a device associated with the beacon advertisement.

[0212] One embodiment provides a method that includes: on an electronic device having a wireless processor coupled to a radio device, when the application processor of the electronic device is in a low power state, using the wireless processor of the electronic device to scan for beacon advertisements; in response to detecting the beacon advertisement via the wireless processor, storing the beacon advertisement and a timestamp as an entry in a beacon advertisement buffer; processing the beacon advertisement buffer to remove duplicate entries; when the application processor wakes up from the low power state, transmitting the buffer entries to the application processor; and associating the beacon advertisement with stored location data to determine a location estimate of the device associated with the beacon advertisement.

[0213] The embodiments described herein also provide techniques for known device matching and horizontal accuracy adjustment during location data acquisition of a wireless accessory device. One embodiment provides a method that includes, on an electronic device having a wireless processor coupled to a radio device, using the wireless processor of the electronic device to scan for beacon advertisements, and detecting a beacon advertisement and having a beacon advertisement packet. The beacon advertisement packet can be a first type of advertisement packet or a second type of advertisement packet. The first type of the advertisement packet is broadcast by a device that has been connected to an accompanying device within a threshold time period, and the second type of the advertisement packet is broadcast by a device that has not been connected to an accompanying device within the threshold time period. The method further includes determining whether the beacon advertisement packet is the first type of advertisement packet based on the structure of the beacon advertisement packet, and in response to determining that the beacon advertisement packet is the first type of advertisement packet, performing a first key matching operation on the beacon advertisement packet to determine whether the beacon advertisement is associated with a known device. The first key matching operation can include comparing a key in a set of keys with an advertisement address in the beacon advertisement packet; and determining that the beacon advertisement is associated with a known device when a set of bits in these advertisement addresses matches a corresponding set of bits in the key in the set of keys. The method further includes, in response to determining that the beacon advertisement packet is the second type of advertisement packet, storing the beacon advertisement and an observation timestamp in a beacon advertisement database for deferred processing.

[0214] One embodiment provides a method that includes: on an electronic device having a wireless processor coupled to a radio device: detecting a beacon advertisement from a beacon wireless device; associating the beacon advertisement with a location estimate determined by the electronic device; sampling motion state data of the electronic device during an interval between detecting the beacon advertisement and determining the location estimate associated with the beacon advertisement; and adjusting a horizontal accuracy of the location estimate based on a speed determined via the motion state data. The speed determined via the motion state data can be a default speed for determining the motion state. The method may further include: determining whether speed data of the electronic device is available during the interval between detecting the beacon advertisement and determining the location estimate associated with the beacon advertisement; and in response to determining that the speed data is available, determining a magnitude of the speed of the electronic device during the interval between detecting the beacon advertisement and determining the location estimate associated with the beacon advertisement. In one embodiment, adjusting the horizontal accuracy of the location estimate based on the speed determined via the motion state data further includes adjusting the horizontal accuracy based on a comparison of the speed determined via the motion state data and the magnitude of the speed determined via the speed data. The comparison can be determining a larger value of the magnitude of the speed and the speed determined via the motion state, and adjusting the horizontal accuracy based on the larger value.

[0215] The speed data can be determined based on satellite positioning data. One embodiment provides a data processing system that includes means for performing the method as described herein.

[0216] From the foregoing description, those skilled in the art will appreciate that the broad techniques of these embodiments can be implemented in many forms. Thus, while embodiments have been described in connection with specific examples of the embodiments, the true scope of the embodiments should not be so limited, as other modifications will become apparent to the skilled person after studying the drawings, the specification, and the following claims.

Claims

1. An electronic device, comprising: A wireless processor coupled to a radio device; A memory for storing instructions; and One or more processors for executing the instructions, wherein the instructions cause the one or more processors to: When the application processor of the one or more processors is in a low power state, use the wireless processor to scan for beacon advertisements; Filter the beacon advertisements based on the advertisement type of the beacon advertisements, including determining whether the beacon advertisement includes an indicator that the location of the device associated with the beacon advertisement is to be determined; In response to detecting the beacon advertisement via the wireless processor, store the beacon advertisement and a timestamp as an entry in a beacon advertisement buffer; In response to determining that the application processor has transitioned out of the low power state, transmit the buffer entry to the application processor; and Associate the beacon advertisement within the buffer entry with stored location data to determine a location estimate of the device associated with the beacon advertisement.

2. The electronic device according to claim 1, wherein the one or more processors are further configured to process the beacon advertisement buffer to remove duplicate entries.

3. The electronic device according to claim 1, wherein the beacon advertisement buffer is a circular buffer.

4. The electronic device according to claim 1, wherein the stored location data includes location data determined based on a Wi-Fi scan performed when the application processor of the one or more processors is in a low power state.

5. The electronic device according to claim 1, wherein the stored location data includes location data determined based on data received from a satellite-based positioning service.

6. The electronic device according to claim 1, the one or more processors: use a beacon identifier broadcast together with the beacon advertisement to encrypt the location estimate of the beacon advertisement; and transmit a hash of the beacon identifier and the encrypted location estimate of the beacon advertisement to a device locator server.

7. A non-transitory machine-readable medium storing instructions for causing one or more processors of an electronic device to perform operations, the operations including: When the application processor of the electronic device is in a low power state, use the wireless processor of the electronic device to scan for beacon advertisements; Filter the beacon advertisements based on the advertisement type of the beacon advertisements, including determining whether the beacon advertisement includes an indicator that the location of the device associated with the beacon advertisement is to be determined; In response to detecting the beacon advertisement via the wireless processor, store the beacon advertisement and a timestamp as an entry in a beacon advertisement buffer; When the application processor wakes up from the low power state, transmit the buffer entry to the application processor; and Associate the beacon advertisement with stored location data to determine a location estimate of the device associated with the beacon advertisement.

8. The non-transitory machine-readable medium according to claim 7, the operations further including processing the beacon advertisement buffer to remove duplicate entries.

9. The non-transitory machine-readable medium according to claim 7, wherein the beacon advertisement buffer is a circular buffer.

10. The non-transitory machine-readable medium according to claim 7, wherein the stored location data includes location data determined based on Wi-Fi scanning, and the Wi-Fi scanning is performed when the application processor of the one or more processors is in a low power state.

11. The non-transitory machine-readable medium according to claim 7, wherein the stored location data includes location data determined based on data received from a satellite-based positioning service.

12. The non-transitory machine-readable medium according to claim 7, wherein the operation further comprises: Use a beacon identifier broadcast together with the beacon advertisement to encrypt the location estimate of the beacon advertisement; and Transmit a hash of the beacon identifier and the encrypted location estimate of the beacon advertisement to a device locator server.

13. A method, comprising: On an electronic device having a wireless processor coupled to a radio device: When the application processor of the electronic device is in a low power state, use the wireless processor of the electronic device to scan for beacon advertisements; Filter the beacon advertisements based on the advertisement type of the beacon advertisements, including determining whether the beacon advertisement includes an indicator that the location of the device associated with the beacon advertisement is to be determined; In response to detecting the beacon advertisement via the wireless processor, store the beacon advertisement and a timestamp as an entry in a beacon advertisement buffer; Process the beacon advertisement buffer to remove duplicate entries; When the application processor wakes up from the low power state, transmit the buffer entry to the application processor; and Associate the beacon advertisement with stored location data to determine a location estimate of the device associated with the beacon advertisement.

14. The method according to claim 13, further comprising: Use a beacon identifier broadcast together with the beacon advertisement to encrypt the location estimate of the beacon advertisement; and Transmit a hash of the beacon identifier and the encrypted location estimate of the beacon advertisement to a device locator server.

15. A computer program product, the computer program product comprising a computer program, the computer program comprising instructions that, when run, cause an electronic device to perform the method according to any one of claims 13-14.

Images