Location data acquisition and pruning for wireless accessory devices

Abstract

The invention relates to location data acquisition and pruning for wireless accessory devices. Embodiments described herein generally relate to methods, electronic devices, media, and computer program products for locating wireless devices and accessories. The method includes, on an electronic device having a wireless processor coupled to a radio device: scanning a beacon advertisement using the wireless processor of the electronic device; detecting a beacon advertisement with a beacon advertisement packet, wherein the beacon advertisement packet is an advertisement packet of a near owner type or an advertisement packet of a field mode type; determining whether the beacon advertisement packet is a near owner type advertisement packet based on detecting a specific structure of the near owner type beacon advertisement packet with respect to a structure of the field mode type beacon advertisement packet; in response to determining that the beacon advertisement packet is a near owner type advertisement packet, a first key matching operation is performed on the beacon advertisement packet to determine whether the beacon advertisement is associated with a known device.

Description

[0001] This application is a divisional application of the Chinese invention patent application with the application date of April 15, 2020, the national application number 202080028897.2, and the invention name “Position data collection and trimming of wireless accessory devices”.

[0002] Cross-references

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

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

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

[0006] Embodiments described herein provide 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. 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 for a device associated with the beacon advertisement; encrypt the location estimate for 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 for the beacon advertisement to a device locator server. In one embodiment, the one or more processors may scan for beacon advertisements using the wireless processor while an application processor of the one or more processors is in a low power state.

[0007] 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 while 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 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.

[0008] One embodiment provides a method comprising: on an electronic device having a wireless processor coupled to a radio device, scanning for beacon advertisements using the wireless processor of the electronic device while the application processor of the electronic device is in a low power state; 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; transmitting the buffer entries to the application processor when the application processor wakes 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.

[0009] Embodiments described herein also provide techniques for performing known device matching and level accuracy adjustment during location data collection for a wireless accessory device. One embodiment provides a method that includes, on an electronic device having a wireless processor coupled to a radio device, scanning for beacon advertisements using the wireless processor of the electronic device, and detecting a beacon advertisement and a beacon advertisement packet. The beacon advertisement packet may be an advertisement packet of a first type or an advertisement packet of a second type. The advertisement packet of the first type is broadcast by a device that has been connected to a companion device within a threshold time period, and the advertisement packet of the second type is broadcast by a device that has not been connected to the companion device within a threshold time period. The method also includes determining whether the beacon advertisement packet is an advertisement packet of the first type based on a structure of the beacon advertisement packet, and in response to determining that the beacon advertisement packet is an advertisement packet of the first type, 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 may include comparing a key from 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 the advertisement address matches a corresponding set of bits in a key from 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 the observation timestamp in a beacon advertisement database to defer processing.

[0010] One embodiment provides a data processing system on an electronic device, the system comprising 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 in an interval between detecting the beacon advertisement and determining the location estimate associated with the beacon advertisement; and adjust the horizontal accuracy of the location estimate based on a speed determined via the motion state data.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0026] Figure 14 A system for detecting and processing beacon data from a wireless accessory is shown;

[0027] Figure 15 A system for associating detected beacon advertisements with locations is shown, according to an embodiment;

[0028] Figure 16A method for collecting beacon advertisements when a detector device is in a low-power state is shown;

[0029] 17A to 17B A method of pruning locations detected for objects is shown;

[0030] Figure 18 is a method of processing device location data on a server according to an embodiment;

[0031] 19A to 19C Systems and methods for sending advertising beacons on a laptop device are shown;

[0032] Figure 20 An advertising beacon packet for a wireless accessory is shown;

[0033] Figure 21 A method of enabling a transition from a near-owner advertising mode to an in-the-wild advertising mode is shown;

[0034] FIG. 22A to FIG. 22B A system for performing real-time and deferred key matching to detect beacons of known devices is shown according to an embodiment;

[0035] Figure 23 A method of performing matching for near-owner beacon advertisements according to an embodiment is shown;

[0036] Figure 24 Shows the adjustment of the horizontal accuracy of the mobile detector device;

[0037] Figure 25 A system is shown that can be used on a detector device to perform horizontal accuracy adjustments on detected beacon devices; and

[0038] Figure 26 A method for horizontal accuracy adjustment of detected beacon devices is shown. DETAILED DESCRIPTION

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

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

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

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

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

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

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

[0046] Figure 2 A system 200 for locating a wireless accessory 201 that is unable to access a wide area network is shown according to an embodiment. The system 200 can also be used to locate devices that are unable to access a WAN or LAN and therefore cannot transmit the location of the device. In one embodiment, the wireless accessory 201 includes one or more wireless transceivers and can communicate with a companion device (e.g., mobile device 102) directly or indirectly (e.g., through another device or computer) via a wireless network or a peer-to-peer communication link. Some examples of wireless accessory devices include, but are not limited to, wireless earbuds, headphones, headsets, and other wearable devices (e.g., smart watches, fitness bands, optical head-mounted displays). The wireless accessory 201 can also include other wireless devices, such as a game controller or remote control. In one embodiment, the wireless accessory 201 also includes a device that is at least temporarily unable to access a wide area network, such as the Internet (e.g., such as a smartwatch). Figure 1The wireless accessory 201 may be a smartphone, tablet, laptop, smart speaker device, television, or television set-top box connected to a wide area network 114 as shown. The wireless accessory may also be any other wireless device that includes a beacon or locator tag that can be attached to other devices or items to enable tracking or locating those devices or items. In one embodiment, the wireless accessory 201 may be paired with the mobile device 102 using a wireless technology standard such as, but not limited to, Bluetooth. The wireless accessory 201 may also communicate with the mobile device 102 via wireless technologies such as Wi-Fi Direct, Zigbee, or similar technologies. Although the companion device with which the wireless accessory 201 is paired is generally referred to as the mobile device 102, the companion device is not limited to a mobile device. In some embodiments, the companion device may also include a laptop or desktop device, and may additionally include some wearable accessories such as, but not limited to, a smartwatch device or a wearable display.

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

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

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

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

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

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

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

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

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

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

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

[0058] If, after transmitting beacon signal 301, wireless accessory 201 receives a reply from a mobile device 102 associated with the 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.

[0059] 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 rate at which the wireless accessory 201 can be located.

[0060] The beacon signal 301 transmitted by the wireless accessory 201 can be detected by a set of detector devices 303, which are other electronic devices that can receive the beacon signal transmitted by the wireless accessory and transmit the location and other data associated with the beacon signal 301 to the device locator server 203 via the wide area network 114. In one embodiment, the set of detector devices 303 includes a variation of the mobile device 102, or can be other types of electronic devices. The set of detector devices 303 may include Figure 2 The detector devices 202 of the present invention may be variants of the detector devices 202 and may determine similar location determination techniques. For example, the detector devices may perform operations (320) to associate beacon signals 301 received from the wireless accessory 201 with the device location associated with the detector device. Figure 2As described, the device location can be determined via a satellite positioning service or a terrestrial positioning system using 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.

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

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

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

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

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

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

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

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

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

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

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

[0072] 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 abnormal locations. In one embodiment, the location data specifies the location of the detector device that detected the beacon. The location data may also include UWB ranging information and / or RSSI information of the beacon detected by the detector device. The electronic device may analyze the UWB ranging information and / or RSSI information in the context of the device location to produce a more accurate location of the wireless accessory. Figure 10 Data that can be transmitted by a detector device and used for position processing is shown in and described below.

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

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

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

[0076] After transmitting the beacon signal, the wireless accessory can listen for a response from the owner device. If the wireless signal receives a response from the owner device (block 504, "Yes"), the wireless accessory can enter a near-owner state (block 505) and begin transmitting beacon signals at a 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).

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

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

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

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

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

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

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

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

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

[0086] 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 a front-end interface with which the mobile device 102 and the set of detector devices 303 can communicate. The account database 825 stores account profile data for the cloud service provider accounts associated with the mobile device 102 and the detector device 303. The database cluster manager 813 can configure the database cluster nodes 823A to 823C as a distributed location database that can store location, signal, and ranging data associated with beacon identifiers of signal beacons received by the set of detector devices 303.

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

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

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

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

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

[0092] 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 flag in a data packet transmitted by the wireless accessory's beacon signal indicating that the wireless accessory alarm has been triggered. In various embodiments, other triggering or notification modes can be used. In one embodiment, the alarm can optionally be triggered by the mobile device upon detecting that the wireless accessory has moved out of range of the mobile device and is no longer in a near-owner state. In one embodiment, the alarm can optionally be triggered when the wireless accessory is out of range of or cannot be located by any device associated with a user account or family of accounts associated with the wireless accessory.

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

[0094] 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 the accessory is unlocked by the user or owner who placed the device in lost mode. When a request is sent to place a wireless accessory in lost mode, the requesting user can be asked to enter authentication information to ensure that the requesting user is authorized to request that lost mode be initiated on the lost accessory. The authentication information can include a username or password associated with an account of the user, such as a cloud service account associated with the user, the electronic device, and the wireless accessory. The authentication information can also include biometric information, such as fingerprint or facial recognition data, voice recognition, iris recognition, and other biometric identification information.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0112] Communication functionality may be facilitated by one or more wireless communication subsystems 1224, which may include radio frequency receivers and transmitters and / or optical (e.g., infrared) receivers and transmitters. The specific design and implementation of the wireless communication subsystem 1224 may depend on the communication network over which the mobile device is intended to operate. For example, a mobile device including the illustrated device architecture 1200 may include a wireless communication subsystem 1224 designed to operate over a GSM network, a CDMA network, an LTE network, a Wi-Fi network, a Bluetooth network, or any other wireless network. Specifically, the wireless communication subsystem 1224 may provide a communication mechanism in which a media playback application may retrieve resources from a remote media server or retrieve scheduled events from a remote calendar or event server.

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

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

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

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

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

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

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

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

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

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

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

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

[0125] In one embodiment, the network interface 1380 can provide access to a local area network, for example, by conforming to the IEEE 802.11 wireless standard, and / or the wireless network interface can provide access to a personal area network, for example, by conforming to the Bluetooth standard. Other wireless network interfaces and / or protocols may also be supported. In addition to or in lieu of communicating via a wireless LAN standard, the network interface 1380 can provide wireless communications using, for example, a time division multiple access (TDMA) protocol, a global system for mobile communications (GSM) protocol, a code division multiple access (CDMA) protocol, a long term evolution (LTE) protocol, and / or any other type of wireless communication protocol.

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

[0127] Position data collection and pruning

[0128] Figure 14A system 1400 is shown in accordance with an embodiment in which a detector device can collect and trim location information of detected wireless beacon signals. The system 1400 includes hardware components such as a Bluetooth controller 1433, an real-time response processor (AOP) 1459, a Wi-Fi controller 1463, and an application processor 1434. The application processor 1434 (which can be a multi-core application processor) can execute an exemplified 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. While Bluetooth beacon signals are described, these techniques are not limited to Bluetooth advertisements, and other types of wireless advertisements from wireless accessories can be used for crowdsourced location determination of wireless accessories and devices.

[0129] The Bluetooth controller 1433 may include a low-power scanner 1431 that operates 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 a Bluetooth processor logic component 1423 and an object discovery logic component 1425. The Bluetooth processor logic component 1423 may control the operation of the Bluetooth controller 1433. The object discovery logic component 1425 may forward advertisements 1413 with time tags 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 that include a bit or a marker indicating that the location of the broadcasting device 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 only store advertisements that include a bit or flag indicating that the location of the broadcasting device should be determined and uploaded to the cloud server 1470.

[0130] 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 rather than repeatedly interrupting the application processor when an advertisement is detected. The Bluetooth controller 1422 may include logic 1424 to de-duplicate the Bluetooth advertisement buffer 1429 so that the buffer does not fill with the same advertisement. The Bluetooth advertisement buffer 1429 may be opportunistically unloaded during a wake event of the application processor 1434. The Wi-Fi controller 1463 may perform scanning operations (1465) and store information related to detected Wi-Fi signals in the Wi-Fi scan buffer 1461. The application processor 1434, via the location daemon 1401, may attempt to match the detected advertisements with the Wi-Fi signal data stored in the Wi-Fi scan buffer 1461 within the Wi-Fi controller 1463.

[0131] In one embodiment, the Wi-Fi scan buffer 1461 is a rolling buffer that stores recently detected SSIDs while overwriting earlier detected SSIDs. In one embodiment, the Wi-Fi scan buffer can be a fixed-size buffer with space for a predetermined number of entries. The Wi-Fi daemon can configure the Wi-Fi controller 1463 to wake up the application processor 1434 when the scan buffer becomes full, or simply overwrite earlier detected SSIDs based on the WSB wakeup / full rollover policy 1455 configured for the Wi-Fi daemon 1453.

[0132] Location daemon 1401 includes a cluster location service interface 1403 and a cluster location service sub-collector 1405. Cluster location service interface 1403 is a service provider interface that enables search daemon 1437 to query location information, including information about wireless accessories tracked by location query application 1435. Cluster location service sub-collector 1405 collects time-tagged advertisements 1413 and associates them with location information. Cluster location service sub-collector 1405 receives time-tagged advertisements 1413 and stores them in beacon cache 1407. Zip logic 1409 uses data associated with GPS provider 1415, Wi-Fi location provider 1417, signal environment provider 1419, and motion activity status 1421 to associate time-tagged location data with time-tagged advertisements 1413. This association data is provided to service provider probe framework 1411, which delivers the associated beacon data to beacon payload cache 1441 within search daemon 1437.

[0133] In one embodiment, 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, while this document specifically describes GPS and generally describes satellite-based positioning services, it should be understood that the satellite positioning technology can be performed using any global navigation satellite system (GNSS). Location can also be determined via a Wi-Fi positioning provider that estimates the device location based on a detected Wi-Fi SSID and / or media access control (MAC) address. The location estimate can be further refined based on the RSSI associated with the detected signal. Signal environment provider 1419 can provide classification data regarding, for example, whether GPS or Wi-Fi positioning is optimal for a given geographic area. Signal environment provider 1419 can use an on-device classifier that estimates the likely accuracy of Wi-Fi positioning based on the number of detected Wi-Fi signals.

[0134] The motion activity state 1421 provides information about whether the detector device is stationary or in motion. The motion activity state 1421 can be determined based in part on the motion updates 1457 provided by the AOP 1459. The AOP 1459 remains powered while other processors within the detector device are in a low power state. The AOP 1459 can collect data from the motion sensors and defer motion updates 1457 until the application processor 1434 or other processor wakes up from the low power state. Figure 15 The operations performed by the cluster location service sub-collector 1405 are further described in .

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

[0136] The search daemon 1437 receives beacon data from the service provider probe framework 1411 and stores the beacon data in a beacon payload cache 1441. The search daemon 1437 includes a deduplication logic component 1443 to dedupe the beacon payload. The location data within the deduplicated beacon payload is encrypted (1447) using a public key (e.g., a beacon ID) broadcast with the beacon. The beacon data and the associated encrypted location can be stored in a beacon upload cache 1449 before being uploaded to the cloud server 1470. When beacon data is ready to be uploaded, the search daemon 1437 can activate a queue and request upload logic component 1451. The queue and request upload logic component 1451 can communicate with the activity 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. In addition, data can be sent opportunistically when other unrelated data is to be transmitted over the network.

[0137] The uploaded beacon data includes: the location associated with the beacon, encrypted using a 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. Cloud server 1470 can use the hash of the public key to index the encrypted location data and timestamp. Using the hash of the public key prevents 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 a hash of the public key known to the owner of the attachment.

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

[0139] In one embodiment, when a new advertisement is received at the beacon cache 1407, the zip logic 1409 may determine (1507) whether the advertisement can be tagged with a location. The zip logic 1409 may check the last location 1521 and the timestamp associated with the last location. If the time of the last location determination is more than a threshold number of seconds after the time the beacon advertisement was detected, the location may not be reliably determined for the beacon advertisement. In this case, the beacon advertisement may be discarded. If the time of the last location determination is more than a threshold number of seconds before the beacon advertisement is detected, the location may be expired and the zip logic 1409 may actively request a location (1509). If the last location 1521 is within a threshold number of seconds of the time of the timestamp associated with the beacon advertisement, the advertisement is determined to be tagged with a location. The location is attached to the beacon advertisement and saved as a beacon payload by the service provider probe framework 1411.

[0140] If the zipper logic component 1409 actively requests location (1509), the logic component can determine whether GPS is allowed (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. 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 is shown requesting a location via GPS (1515). If GPS is not enabled, the zipper logic 1409 may use Figure 14 Wi-Fi location provider 1417 is shown requesting a location using a Wi-Fi location service (1513). In some embodiments, the request for a Wi-Fi location determination may also utilize positioning techniques based on RF signals received from other wireless base stations (such as cellular or mobile network towers). Following the request, cluster location service sub-collector 1405 may perform operations (1517) to monitor the timeout of the location request. If a location is received, a power-on location received event 1529 is fired and the last location 1521 is updated. If a location is received within a threshold number of seconds of the indicated advertisement time, the location may be associated with the advertisement.

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

[0142] When a location is determined for a beacon advertisement, a confidence score can also be assigned to the location. The confidence score allows the search daemon 1437 to de-duplicate and refine the beacon payload. The confidence score also allows the cloud server 1470 to refine the location estimate received for the accessory or device across multiple probes that may be sending location data for the accessory or device.

[0143] 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 or wireless accessory enter and leave range of each other. In one embodiment, beacon RSSI or UWB ranging may be used, such as Figure 7 The cluster location service may obtain clusters of locations and certainties associated with those locations and refine the clusters of locations into one or more locations that are best estimates of the location of the object during the time the object was detected.

[0144] To refine the clustering of locations, the list of potential locations of detected advertisements can be sorted by time. The list of locations can be traversed from most recent to oldest, and each location can be analyzed to determine whether it is continuous with previous readings. If the locations appear to be continuous, a weighted average of the locations is taken and used as the location of the beacon, where the weight used for averaging is a measure of the uncertainty of the location. If there is a single location that is discontinuous, that location can be discarded. However, if multiple locations are detected that indicate the beacon object is moving, the averaging process is stopped and multiple locations can be reported for the object. Using these analysis techniques, the cluster location service can determine, for example, whether a beacon object is moving past a stationary detector device, or whether the beacon object is stationary when the detector device moves past, or whether the beacon object and the detector device are in motion relative to each other. This determination can 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 is detected.

[0145] Figure 16 A method 1600 for collecting beacon advertisements when a detector device is in a low power state is shown. The method 1600 may be implemented by a device having a configuration similar to Figure 14The method 1600 is performed by a device of the system 1400. In one embodiment, the method 1600 includes scanning for beacon advertisements using a wireless processor while 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) that includes an advertisement buffer (e.g., Bluetooth advertisement buffer 1429) that can store detected advertisements while the application processor (e.g., application processor 1434) is in a low-power state. When a beacon advertisement is detected, the wireless controller can store the beacon and a timestamp in the beacon advertisement buffer (block 1602). The wireless controller can also include logic to process the beacon advertisement buffer to remove duplicate entries (block 1603). When the application processor wakes from the low-power state, the wireless controller can transmit the buffer entries to the application processor (block 1604). The application processor can then associate the beacon advertisement with stored location data to determine a location estimate of the device associated with the beacon advertisement (block 1605).

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

[0147] like Figure 17A As shown, method 1700 includes an operation of sorting the stored observations by scan date (box 1701). Observations of individual beacon objects can be sorted individually. Method 1700 also includes an operation of calculating a median level of precision for the observations (box 1702). A separate median level of precision can 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 (box 1703). Each unique key within the privacy period can represent a separate object detected. For subsequent observations with the same key, method 1700 includes performing a decimation / discarding operation on the observation (box 1704). Method 1700 Figure 17B Continue.

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

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

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

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

[0152] Figure 18 1800 is a method for processing device location data on a server according to an embodiment. Method 1800 can be performed 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 (box 1801). Observations for a single device or accessory are reviewed, including all observations submitted from multiple detector devices. For example, if a wireless accessory or device is transmitting a beacon in a signal-heavy area, multiple devices may transmit the location of the accessory or device. The server can then review the locations of the device submitted by the multiple detector devices to further qualify the location data of the device. Reviewing the locations can include analyzing confidence scores for each location (box 1802).

[0153] If the server detects that there is an active location query for the device whose location data is being refined (box 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 (box 1804). If there is no location query pending for the device, the server may spend additional time refining the location data based on the confidence score of the location (box 1805). Refining the data may include, for example, determining an estimated location of the device or accessory based on locations reported by multiple detector devices. In one embodiment, refining the location data based on the confidence score may additionally include a weighted average 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 (box 1803), the server may send the current location data in response to the query (box 1804).

[0154] 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 as new location data is received (block 1808). Because the location data may be encrypted, the server will not directly know whether the queried device or accessory is in motion. However, various detector devices may be able to determine that the observed device or accessory is in motion and may send a motion status flag to the server. If the device is not in motion, the server may continue to refine the location data based on a confidence score (block 1805).

[0155] 19A to 19C A system and method for sending advertising beacons on a laptop device is described. Crowdsourced location determination based on beacon advertising as described herein can be used for a variety of different types of devices and accessories, including wireless devices with network or cellular access and wireless accessories without current or local network access. Generally, the 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 embodiment, when the laptop device is not connected to a network, the device can begin broadcasting wireless advertisements, such as Bluetooth Low Energy advertisements, which can be used to determine the device's location via nearby detector devices.

[0156] like Figure 19AAs shown, an electronic device 1902, such as a laptop or tablet, may be connected 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 for the device may be sent over the network 114 to enable the device to be located. If, for any of a variety of reasons, the laptop 1902 becomes disconnected from the network 114, the laptop 1902 may begin broadcasting beacon advertisements 1904 via a radio that allows nearby detector devices to determine the location of the electronic device 1902 and upload the location to a device location server. A method 1910 for enabling advertising beacons is shown in FIG. Figure 19B middle. Figure 19C A method 1920 of cycling advertising beacons for privacy and power conservation purposes is shown.

[0157] like Figure 19B As shown, method 1910 includes preparing an electronic device, such as a laptop or tablet, to a low-power state (block 1911). For example, the electronic device may be prepared to be placed in a sleep state in which portions of the device are turned off or placed in a low-power state, while the device's memory remains at least partially powered to retain application and system states. In some embodiments, data in the memory may be written to a non-volatile storage device, and the electronic device may enter a standby state in which a greater number of components of the electronic device (including the memory storing the device state) may be powered off. The device may enter the standby state after a period of time in the sleep state.

[0158] When the electronic device is initially preparing to transition to a low-power (sleep or standby) state, the electronic device may determine whether there is a connection to a known network (block 1912). For example, the electronic device may 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, a known network is a network that the electronic device has previously connected to. In one embodiment, a known network is a network that the electronic device has previously connected to and is configured to automatically join. In one embodiment, a known network may be a network at a preconfigured location, such as a home network or a work network. In one embodiment, a known network is a network at a frequently visited location of interest that the electronic device is configured to automatically join.

[0159] If the electronic device is connected to a known network, the electronic device may remain connected to the network for a period of time (box 1913). After this period of time, the electronic device may be disconnected from the network (box 1914). The electronic device may be disconnected 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., memory powered on) but disconnected from the network to maintain power. The period of time may be a predetermined period of time (e.g., 12 hours) or may vary based on the battery status 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 be disconnected from the network after a predetermined period of time to reduce overall power consumption.

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

[0161] 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 safe location of interest (block 1915), the electronic device may begin a wireless beacon cycle (block 1916). During the wireless beacon cycle, the device broadcasts a beacon advertisement to enable detector devices to detect the presence of the device. The detector device may then upload the location of the electronic device to a device location server, as described above. The wireless beacon cycle may be performed via Figure 19B This is achieved by method 1920.

[0162] like 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 a beacon advertisement. 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 within a first time period (block 1922). In one embodiment, the first time period can be a first privacy time period, during which advertisements are broadcast based on the public key. After the first privacy time period, the electronic device can use the anti-tracking secret described above to generate a new set of keys, including a new public key that can be used as the next beacon identifier.

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

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

[0165] In one embodiment, the wireless controller is directly controlled by the electronic device's application processor, and the electronic device temporarily wakes up from a sleep state to change the advertisements broadcast by the wireless controller. In such an embodiment, the electronic device may 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 broadcasting, the electronic device may broadcast for two hours, with the beacon identifier cycling every 15 minutes. The electronic device may then stop broadcasting for three hours, and then resume broadcasting for two hours. During the second day, the electronic device may broadcast twice a day, with each broadcast period lasting one hour.

[0166] 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 the beacon identifiers without requiring the electronic device to wake up from a low power state.

[0167] Detect beacon advertisements broadcast by known devices

[0168] The embodiments described herein provide a wireless beacon device that can be used to track or locate an item to which the wireless beacon device is attached. The wireless beacon device and the companion device can be used as Figure 3 The public key exchange (310) shown may be cryptographically associated via a collaborative key generation process. During the collaborative key generation process, the companion device and the wireless beacon device may work together to generate a set of base keys. The collaborative key generation algorithm enables the companion device and the wireless beacon device to independently generate the set of base keys after exchanging baseline cryptographic material. Each device may 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 encryption keys that enable an encrypted communication link to be established between the companion device and the wireless beacon device.

[0169] The collaboratively generated keys may be used to configure the wireless hardware addresses of beacons advertised by wireless beacon devices. Companion devices may detect known devices by searching for beacon advertisements that have hardware addresses that match the public keys of known devices. Various different mobile device categories (e.g., mobile phones, laptops, tablets, locator tags, etc.) may be configured to broadcast beacons (e.g., field mode beacons) that enable detector devices to detect the presence of these devices and upload the device's estimated location to a device locator server. The wireless beacon device may also be configured to transmit beacons in near-owner mode when the device is within wireless communication range of its companion device or for a period of time after the encrypted communication session between the companion device and the wireless beacon device is terminated. The wireless beacon device may be configured to transition to transmitting beacons in a field mode state after the device has been transmitting beacons in near-owner mode for a threshold period of time.

[0170] The advertising packets broadcast by a wireless beacon device may vary depending on the device's advertising mode. Figure 20 Near owner and wild mode advertising packages are shown in. Figure 21A method for transitioning from near-owner mode to wild mode is shown in FIG. Based on the type of packet detected for the beaconing device, a matching process is performed to determine whether the beaconing device is a known device. This matching process can occur in real time or be deferred to a later time period. In one embodiment, matching is performed in real time for devices transmitting beacons in near-owner mode, while matching for devices in wild mode can be deferred until a beacon publish event.

[0171] Figure 20 An advertising beacon packet 2010 for a wireless accessory is shown. The advertising packet broadcast by the wireless accessory can vary based on whether the accessory is in near-owner mode (packet 2011), in a field beacon state (packet 2012), or advertising unwanted tracking determinations or suppression data (packet 2013). In one embodiment, the advertising packet can be a Bluetooth low energy advertising packet. However, embodiments are not limited thereto. Additionally, the packet format can differ from standard wireless protocol advertising packets.

[0172] In one embodiment, the near-owner advertisement packet 2011 includes a first public key portion (PubKey1 / 2) that serves as the advertisement address. The first public key portion may include the first six bytes of the wireless accessory's current public key. In one embodiment, the most significant bits of the advertisement address are constrained to the value 0b11, which specifies a static device address. Conversely, if the wireless accessory is a wireless beacon tag, the actual address bits are stored in the EK (Extra Key) field, along with bits defining the wireless accessory's tag type. The near-owner packet may 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 may vary depending on whether the wireless accessory is in near-owner mode or field mode. The status flag field may include, for example, battery status and an additional device type flag, such as whether the wireless accessory is a wireless beacon tag.

[0173] In one embodiment, the wild mode advertising packet 2012 may include similar fields as the near owner advertising packet 2011. The wild mode advertising packet 2012 may 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 combined public key (PubKey1 / 2, PubKey2 / 2, EK) may be used as a static identifier for the wireless accessory, which allows for suppression of unwanted tracking notifications. In one embodiment, the combined public key may also be used by the detector device as an encryption key to encrypt the observed location of the wireless beacon when uploading the observations to the device locator server.

[0174] In one embodiment, the wireless accessory is configured to broadcast separate UT advertising packets 2013 and wild mode advertising packets 2012 in an alternating sequence when the accessory is in wild mode. The UT advertising 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, which is rolled over every privacy period (e.g., every 15 minutes). In one embodiment, IRK_EOD rolls over every 24 hours, while IRK_INDEF does not roll over unless the wireless accessory undergoes a factory reset. The wireless accessory can be factory reset in response to unpairing the accessory from a companion device.

[0175] UT Advertising Packet 2013 is optional. In one embodiment, UT Advertising Packet 2013 can be excluded and suppression can be performed using one or more static identifiers associated with the wireless accessory. Static identifiers can be configured to roll over every 24 hours, allowing for suppression of unwanted tracking notifications from the accessory once a day. For example, in one embodiment, the device's diversified public key can continue to roll internally for the accessory while in field mode, while the field mode advertising address is configured to roll over for the wireless accessory at, for example, midnight local time. During key rollover, the currently active internal public key can be configured as the advertising address for beacon advertisements. To facilitate reconnection to the accessory while in field mode, Field Mode Advertising Packet 2012 can include a Hint Field HT containing a set of bits (e.g., a set of least significant bits) of the public key currently used by the accessory. The owner device can use this information to generate the correct owner key, owner token, and / or join key to place the wireless accessory in near-owner mode. Once in near-owner mode, the wireless accessory can begin advertising using Near-Owner Advertising Packet 2011.

[0176] Figure 21 A method 2100 is shown for enabling a transition from a near-owner advertising mode to a wild advertising mode. 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 transmit a beacon in near-owner mode using a near-owner advertising packet (block 2102). The near-owner advertising packet may be Figure 20The wireless device may also configure or update a near-owner timeout based on location and / or motion status (block 2103). The near-owner timeout may be increased from a default value when the wireless device is at a home location or point of interest, or another location or point of interest that has been designated as a safe location. The near-owner timeout may be decreased from a default value when the wireless device is not at a safe 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 a companion device. The near-owner timeout may also be configured during a connection with a companion device based on contextual information determined by the wireless device during the connection or based on state information received from the companion device. Reducing the near-owner timeout period reduces the amount of time that may be required for other devices configured to report detection of a wild mode beacon to detect a potentially lost wireless device.

[0177] 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 transmit beacons in near owner mode. If the near owner timeout has been reached (yes at block 2104), the wireless device may transmit beacons in wild mode using a wild mode advertising packet (block 2105). When in wild mode, the wireless device broadcasts wild mode advertising packets that are discoverable by detector devices within wireless range of the wireless accessory. The wild mode advertising packets may be Figure 20 A variant of the wild mode advertisement packet 2012 of FIG. The beacon rate of the wireless device may be increased relative to the beacon rate when in near-owner mode. Upon detecting a wild mode advertisement, a nearby detector device 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.

[0178] While the wireless device is in wild mode, privacy period key rollover can continue during each privacy period. Privacy period key rollover results in a change in the encryption key used to establish connections with the wireless device. In one embodiment, unlike when in near-owner mode, the advertising address of a device in wild mode is not updated for each key rollover. Instead, the advertising address can be updated every R key rollovers, resulting in the advertising address changing, for example, every 24-36 hours. Maintaining the same advertising address for a period of time in wild mode can be advantageous for suppressing or ignoring unwanted tracking alerts for a period of time, without requiring cryptographic techniques to determine whether multiple wild mode addresses of a wireless device resolve to the same device.

[0179] 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 a counter value on the wireless device that is used to generate new keys during each key rollover. The companion device may connect to the wireless device in wild mode using the 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 for a period of time (e.g., 24 hours), and additional keys may be generated periodically to maintain a set of keys for that period of time.

[0180] FIG. 22A to FIG. 22B A system that performs real-time and deferred key matching to detect beacons of known devices is shown, according to an embodiment. Figure 22A A system is shown that performs key matching in real time to detect known devices. Figure 22B A system is shown that performs key matching in real time for devices in near-owner mode to detect known devices, and defers performing key matching in a delayed manner for devices in wild mode to detect known devices.

[0181] like Figure 22A As shown, entries in the beacon cache 1407 storing beacon advertisements can 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 being broadcast by known devices in near-owner mode and wild mode by performing a key matching operation. The matching logic component 2202 can use the key generated by the key generation logic component 2208 to detect beacons broadcast by known devices in the beacon cache 1407. Beacons can be sorted into a known device cache 2204 and an unknown device cache 2206. The known device cache 2204 can store a set of observations for 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, an owner device (e.g., a companion device) of the detected wireless device or a device that has been authorized to interact with the detected wireless device. Locations can be determined for the beacon entries in the known device cache, and these entries can 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 position estimates determined for those beacons before the beacons and estimated positions are stored in the beacon payload cache 1441 .

[0182] A known device in near-owner mode can 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 can broadcast a near-owner advertisement packet 2011 such as Figure 20 As shown, the near-owner advertisement packet includes a first public key portion (PubKey1 / 2) used 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 the wireless device, although the specific number of bytes may vary. The current public key for the wireless device may be rotated every M minutes and may be calculated in real time by the key generation logic component 2208.

[0183] A wireless device in wild mode can also be detected by matching a set of bytes broadcast as the wireless device's wireless address. The number of bytes in the set of bytes to match is larger for wild mode than for near owner mode. For example, Figure 20 As shown, wild mode advertisement packet 2012 may include a first public key portion (PubKey1 / 2) and a second public key portion (PubKey2 / 2). While the wireless device is in 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 wild mode advertisement packet 2012 may not be updated during each key rollover. Instead, one or more portions of the advertised public key may remain static during a predetermined number of public key rollovers. Therefore, the number of public keys that may be checked for a wireless device in wild mode may be greater than the number of keys that may be checked for a wireless device in near-owner mode. Key generation logic 2208 is aware of the address update schedule and may generate multiple potential public keys for the wireless device, which may be compared with entries in beacon cache 1407 to determine whether any of the entries are associated with a known device that is transmitting a beacon in wild mode.

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

[0185] Beacons of wireless devices transmitting in near-owner mode are detected in real time, for example, to facilitate performing maintenance operations on these devices. Maintenance operations may include periodic counter update operations to prevent counter drift, adjust near-owner mode timeout values, and / or configure field mode address update times and intervals. 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 larger 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. Therefore, some embodiments defer key matching operations for field mode beacons. Matching operations may be deferred until processor resource requirements are low, such that processor resource requirements fall below a threshold. In one embodiment, key matching operations for field mode beacons may be bypassed entirely, where field mode observations of known devices are retrieved from the cloud server 1470 using device location queries.

[0186] As described above, the matching logic component 2212 may perform key matching of a detected near-owner beacon 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., a public key) associated with the wireless device. Figure 22A In the real-time key generation using the key generation logic component 2208, a key block stored in the key store 2218 can be pre-generated (e.g., via the key generation logic component 2208) and will be valid for the set of known devices for a predetermined period of time. The key block stored in the key store 2218 can be periodically refreshed to ensure that the key is available within a predetermined range, which can extend across a specified period of time before and after the current time.

[0187] For each detected beacon advertisement in the beacon cache 1407, the matching logic component 2212 can request the appropriate key for each device in a set of known devices during the time period when the beacon advertisement was 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 can be determined to be a near-owner beacon and stored in the near-owner beacon cache 2214.

[0188] Beacons detected as not matching near-owner beacons may be stored in the wild-mode beacon cache 2216. In one embodiment, known device matching for wild-mode beacons may be deferred and performed in response to a processing event or another triggering event. For example, in response to a processing event 2217 scheduled by activity schedule 1445, known device determination may be performed for the beacons in the wild-mode beacon cache 2216. A processing event may be a trigger for the filter logic 2210 to perform a position estimate for the beacons, enhance the position estimate determined for those beacons, perform known device matching, or perform other activities before the beacons and estimated positions are stored in the beacon payload cache 1441. Known device determination may be performed in response to the launch of a device locator application of the device locator service and / or the presentation of the device locator user interface 204 on the mobile device 102. Known device determination may also be performed for the beacons in the wild-mode beacon cache 2216 during the position estimation process for detected beacons or during a publish event when a beacon payload is uploaded to a set of cloud servers 1470. In one embodiment, known device matching for field mode beacons can be bypassed, and all field mode beacons can be filtered without performing a determination as to whether the field mode beacon is associated with a known device. Location data for known devices in field mode can then be determined by querying the cloud server 1470 via the device locator user interface 204.

[0189] Figure 23 A method 2300 for performing matching for near-owner beacon advertisements according to an embodiment is shown. Method 2300 may be performed on an electronic device that is a companion device to a wireless device (including a wireless beacon device). In one embodiment, the electronic device may scan for beacon advertisements using a wireless processor of the electronic device (block 2301). The electronic device may then detect a beacon advertisement having a beacon advertisement packet (block 2302). The electronic device may then 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 may 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 may store the beacon advertisement and timestamp in a beacon advertisement database to defer processing (block 2306). In one embodiment, if the beacon advertisement is associated with a known device, the electronic device may determine whether to establish a connection with the known device to perform periodic maintenance operations as described above.

[0190] Horizontal accuracy adjustment for detected beacon devices

[0191] As described above, the horizontal accuracy associated with the position determination may be used to refine and filter the position estimate determined for the detected wireless device. In one embodiment, the position estimate of the detected wireless device may be determined based on the position estimate of the probe device and the estimate of the range and direction between the probe device and the detected wireless device. Figure 2 ), the horizontal accuracy or position uncertainty of the wireless device may vary.

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

[0193] In one embodiment, the location determination of a detector device can be performed asynchronously with respect to the detection of a beacon advertisement. 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 decreases 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 an advertisement can be tagged with a location determined by the detector device based on a timestamp associated with the detection of the beacon advertisement and the determination of the detector device's location estimate.

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

[0195] In one embodiment, the horizontal accuracy associated with a beacon observation may be determined to arrive at an adjusted horizontal accuracy 2406 by adjusting the horizontal accuracy of the probe device's position estimate based on the distance the probe device has traveled between the beacon observation time and the position determination time. The distance traveled may be estimated based on an estimate of the velocity of the probe device 202 during the interval between the beacon detection and the position determination. Various velocity estimation techniques may be applied, as described below with respect to Figure 25 As stated.

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

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

[0198] Figure 25A system 2500 is shown that can be used on a detector device to perform horizontal accuracy adjustment on detected beacon devices. In one embodiment, the system 2500 includes a motion classifier 2501, a position subsystem 2502, and a horizontal accuracy adjustment subsystem 2505. The horizontal accuracy adjustment subsystem 2505 can determine an adjusted horizontal accuracy for a beacon observation 2506 to be stored in the beacon payload cache 1441 based on a motion activity state 2503 received from the motion classifier 2501 and a position state 2504 received from the position subsystem. The components of the system and 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 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 location system (e.g., cloud server 1470, device locator server 203).

[0199] Motion activity status 2503 can be Figure 14 The motion classifier 2501 may be similar to or identical to the motion activity state 1421 of the detector device and provide information about whether the detector device is stationary or in motion. Figure 12 The motion context determined based on the measurement results provided by the motion sensor 1210 shown in the figure is used to determine the motion activity state. The motion sensor may include multiple sensors such as an accelerometer or a gyroscope. Data from other sensors (e.g., a magnetometer, a 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 being performed by the detector device. The motion type 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 in another way based on the motion context data. The motion classifier 2501 can also determine whether the detector device 202 is in a moving vehicle. Such determination can be included in the motion activity state 2503. The motion activity state 2503 can also include a rate, which can be an average rate determined for the detector device when the device is in motion, or a default rate associated with determining the motion state when the rate of the device cannot be determined.

[0200] The location subsystem 2502 includes hardware and software components that can use a location determination system to determine an estimate of the location of the electronic device. In one embodiment, the location subsystem 2502 includes logic components that determine or estimate the location of the device based on a satellite positioning service 206 or a terrestrial positioning system using RF signals received from a wireless base station 205, such as Figure 2As shown, for example, Figure 14 The position determination components shown. Position subsystem 2502 can maintain position state 2504, which includes the most recently determined position of the probe device and the horizontal accuracy associated with the determined position. In some embodiments, position state 2504 also includes an instantaneous rate 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 position state 2504.

[0201] In one embodiment, the horizontal accuracy adjustment subsystem 2505 includes hardware and software logic that adjusts the initial horizontal accuracy of beacon observations 2506 to account for the interval between the beacon observation and the position determination. In one embodiment, the horizontal accuracy of a beacon observation 2506 may be input to 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 rates associated with one or more instances of motion activity state 2503 during the interval and rate data from position state 2504 may be analyzed collaboratively to estimate the average speed of the detector device during the position determination interval. The average speed may 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 may be stored in the beacon observation 2506, which may then be stored in the beacon payload cache 1441. In one embodiment, the horizontal accuracy adjustment may be performed before the beacon observation is stored in the beacon payload cache 1441. In one embodiment, beacon observations may be stored to a beacon payload cache and horizontal precision adjustments may be performed asynchronously.

[0202] Figure 26 A method 2600 for horizontal accuracy adjustment of detected beacon devices is shown. The method 2600 may be performed by an electronic device (eg, a probe device) to adjust a horizontal accuracy metric of beacon observations detected while the probe device is in motion.

[0203] A probe device may detect a beacon advertisement from a beacon wireless device (block 2601). The probe device may then associate the beacon advertisement with a location estimate determined by the electronic device (block 2602). The probe device may then sample 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 location state information of the probe device during the location determination interval includes velocity data (yes at block 2604), the probe device may adjust the horizontal accuracy of the location estimate based on a comparison of the velocity data with a speed determined via the motion state (block 2605). In one embodiment, the velocity data includes speed and direction data determined via a satellite-based positioning and navigation system (e.g., GPS).

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

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

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

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

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

[0209] 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 functionality, such as a PDA and / or music player functionality. In the description and drawings of this application, where a wireless device, wireless accessory, or wireless accessory device is described or shown, unless otherwise indicated, the properties described or shown are generally applicable to any type of wireless device, wireless accessory, or wireless accessory device capable of broadcasting a wireless beacon.

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

[0211] Embodiments described herein provide 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. 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 for a device associated with the beacon advertisement; encrypt the location estimate for 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 for the beacon advertisement to a device locator server. In one embodiment, the one or more processors may scan for beacon advertisements using the wireless processor while an application processor of the one or more processors is in a low power state.

[0212] 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 while 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 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.

[0213] One embodiment provides a method comprising: on an electronic device having a wireless processor coupled to a radio device, scanning for beacon advertisements using the wireless processor of the electronic device while the application processor of the electronic device is in a low power state; 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; transmitting the buffer entries to the application processor when the application processor wakes 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.

[0214] Embodiments described herein also provide techniques for performing known device matching and level accuracy adjustment during location data collection for a wireless accessory device. One embodiment provides a method that includes, on an electronic device having a wireless processor coupled to a radio device, scanning for beacon advertisements using the wireless processor of the electronic device, and detecting a beacon advertisement and a beacon advertisement packet. The beacon advertisement packet may be an advertisement packet of a first type or an advertisement packet of a second type. The advertisement packet of the first type is broadcast by a device that has been connected to a companion device within a threshold time period, and the advertisement packet of the second type is broadcast by a device that has not been connected to the companion device within a threshold time period. The method also includes determining whether the beacon advertisement packet is an advertisement packet of the first type based on a structure of the beacon advertisement packet, and in response to determining that the beacon advertisement packet is an advertisement packet of the first type, 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 may include comparing a key from 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 the advertisement address matches a corresponding set of bits in a key from 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 the observation timestamp in a beacon advertisement database to defer processing.

[0215] One embodiment provides a method comprising: at 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 the horizontal accuracy of the location estimate based on a rate determined via the motion state data. The rate determined via the motion state data may be a default rate for determining motion state. The method may also include: determining whether speed data is available for the electronic device 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 rate determined via the motion state data further comprises adjusting the horizontal accuracy based on a comparison of the rate determined via the motion state data and the magnitude of the speed determined via the speed data. The comparison may be determining a greater value of the magnitude of the speed and the rate determined via the motion state, and adjusting the horizontal accuracy based on the greater value.

[0216] The speed data may be determined based on satellite positioning data.One embodiment provides a data processing system comprising means for performing the method as described herein.

[0217] From the foregoing description, those skilled in the art will appreciate that the broad techniques of these embodiments can be implemented in a variety of forms. Therefore, while the embodiments have been described in conjunction 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. A method comprising: On an electronic device having a wireless processor coupled to a radio device: scanning for beacon advertisements using the wireless processor of the electronic device; detecting a beacon advertisement having a beacon advertisement packet, wherein the beacon advertisement packet is a near-owner type advertisement packet or a wild mode type advertisement packet; determining whether the beacon advertising packet is an advertising packet of the near-owner type based on detecting a specific structure of the beacon advertising packet of the near-owner type relative to a structure of the beacon advertising packet of the field mode type; In response to determining that the beacon advertisement packet is the advertisement packet of the near-owner type, a first key matching operation is performed on the beacon advertisement packet to determine whether the beacon advertisement is associated with a known device.

2. The method according to claim 1, wherein the first key matching operation comprises: comparing a key from a set of keys to an advertisement address in the beacon advertisement packet; as well as The beacon advertisement is determined to be associated with a known device when a set of bits in the advertisement address matches a corresponding set of bits in a key in the set of keys.

3. The method according to claim 2, further comprising: In response to determining that the beacon advertisement is associated with a known device, an encrypted communication channel is established with the wireless device associated with the beacon advertisement.

4. The method of claim 3, further comprising establishing the encrypted communication channel with the wireless device associated with the beacon advertisement using an encryption key derived from the key in the set of keys.

5. The method according to claim 1, further comprising: In response to determining that the beacon advertisement packet is the field mode type advertisement packet, the beacon advertisement and the observation timestamp are stored in a beacon advertisement database for deferred processing. 6 . The method of claim 5 , wherein the deferred processing comprises a set of processing operations performed when demand for processing resources on the electronic device is below a threshold.

7. The method of claim 6, wherein the deferring processing comprises processing location data determined by the electronic device to determine a location estimate of a device associated with the beacon advertisement.

8. A method according to claim 7, wherein processing the location data determined by the electronic device includes sampling motion state data of the electronic device in an interval between detecting the beacon advertisement and determining a location estimate associated with the beacon advertisement, and adjusting the horizontal accuracy of the location estimate based on a rate determined via the motion state data.

9. The method of claim 8, wherein the rate determined via the motion state data is a default rate for a determined motion state.

10. The method of claim 1, wherein the advertising packets of the near-owner type are broadcast by devices that have been connected to a companion device within a threshold time period, and the advertising packets of the wild mode type are broadcast by devices that have not been connected to a companion device within the threshold time period.

11. An electronic device comprising: a memory for storing instructions; and One or more processors configured to execute the instructions, wherein the instructions cause the one or more processors to perform the method according to any one of claims 1 to 10.

12. A non-transitory machine-readable medium storing instructions for causing one or more processors of an electronic device to perform the operations of the method according to any one of claims 1 to 10.

13. A computer program product comprising a computer program, the computer program comprising instructions which, when executed, cause one or more processors of an electronic device to perform the method according to any one of claims 1 to 10.

14. A method comprising: preparing to transition an electronic device at a current location to a low power state; According to determining that there is no network connection between the electronic device and a known network: determining that the current location is a safe location based at least in part on characteristics of the current location; as well as A wireless beacon cycle is initiated on the electronic device.

15. The method according to claim 14, further comprising: According to determining that the network connection does exist between the electronic device and the known network: maintaining the network connection for a period of time; as well as disconnecting the network connection; determining the current location to be the safe location based at least in part on the characteristics of the current location; as well as The wireless beacon cycle is initiated on the electronic device.

16. The method of claim 15, wherein maintaining the network connection for the period of time comprises: The network connection is maintained according to a fixed time period or according to a power configuration of the electronic device.

17. The method of claim 15, wherein disconnecting the network connection comprises disconnecting due to the electronic device transitioning to the low-power state.

18. The method of claim 14, wherein preparing to transition the electronic device to the low-power state comprises preparing to place the electronic device into a sleep state or a standby state.

19. The method of claim 14, wherein determining that the network connection does not exist between the electronic device and the known network comprises determining whether the electronic device is connected to a known Wi-Fi access point or a known router.

20. The method of claim 14, wherein the characteristics of the safe location correspond to a home configuration stored by the electronic device for the current location.

21. The method of claim 14, further comprising broadcasting, by the electronic device, a beacon advertisement within the wireless beacon loop.

22. The method of claim 21, wherein the beacon advertisement is configured to enable a detector device to detect the electronic device.

23. The method of claim 14, wherein the electronic device comprises a personal electronic user device.

24. An electronic device comprising: a memory for storing instructions; and One or more processors configured to execute the instructions, wherein the instructions cause the one or more processors to perform the method according to any one of claims 14 to 23.

25. A non-transitory machine-readable medium storing instructions for causing one or more processors of an electronic device to perform the operations of the method according to any one of claims 14 to 23.

26. A computer program product comprising a computer program comprising instructions which, when executed, cause one or more processors of an electronic device to perform the method according to any one of claims 14 to 23.

27. A method comprising: configuring a wireless controller of an electronic device to broadcast a first beacon identifier based at least in part on a first public key associated with the electronic device; broadcasting the first beacon identifier within a first time period; configuring the wireless controller to broadcast a second beacon identifier based at least in part on a second public key associated with the electronic device and generated using an anti-tracking secret; as well as The second beacon identifier is broadcast during a second time period.

28. The method of claim 27, further comprising, based on determining that a timeout condition is not satisfied after broadcasting the second beacon identifier: configuring the wireless controller to broadcast a third beacon identifier based at least in part on a third public key associated with the electronic device; and The third beacon identifier is broadcast during a third time period.

29. The method of claim 27, further comprising, based on determining that a timeout condition has been met after broadcasting the second beacon identifier: ceasing to broadcast the second beacon identifier; and The broadcast schedule is reconfigured before resuming broadcast using the third beacon identifier.

30. The method of claim 29, wherein reconfiguring the broadcast schedule comprises at least one of changing a first number of times each beacon identifier is advertised during each time period, or changing a total number of times a single beacon identifier is advertised during a predefined time period.

31. The method of claim 27, further comprising: before configuring the wireless controller to broadcast the first beacon identifier, transitioning the electronic device to a first power state; as well as Prior to broadcasting the first beacon identifier, the electronic device is transitioned from the first power state to a second power state.

32. The method of claim 31 , wherein the first power state comprises an active power state.

33. The method of claim 31 , wherein the second power state comprises a low power state.

34. The method of claim 27, wherein configuring the wireless controller of the electronic device to broadcast the first beacon identifier comprises configuring the wireless controller using an application processor while the electronic device is in an active power state.

35. The method of claim 27, wherein broadcasting the first beacon identifier during the first time period comprises broadcasting the first beacon identifier using the wireless controller when the electronic device is in a low-power state.

36. The method of claim 27, wherein the wireless controller includes a buffer comprising a set of pre-generated key sets and a set of beacon identifiers.

37. The method of claim 36, wherein: Configuring the wireless controller to broadcast the first beacon identifier includes accessing the first beacon identifier from the buffer when the electronic device is in a low power state; as well as Configuring the wireless controller to broadcast the second beacon identifier includes accessing the second beacon identifier from the buffer while the electronic device is in the low power state.

38. An electronic device comprising: a memory for storing instructions; and One or more processors configured to execute the instructions, wherein the instructions cause the one or more processors to perform the method according to any one of claims 27 to 37.

39. A non-transitory machine-readable medium storing instructions for causing one or more processors of an electronic device to perform the operations of the method according to any one of claims 27 to 37.

40. A computer program product comprising a computer program comprising instructions which, when executed, cause one or more processors of an electronic device to perform the method according to any one of claims 27 to 37.

41. A method performed by an accessory device, comprising: When the accessory device is in near-owner mode, broadcasting a near-owner type advertising packet; determining, based on a near-owner timeout condition, to switch from the near-owner mode to the field mode; When the near-owner timeout condition is met, switching from the near-owner mode to the field mode; as well as When the accessory device is in the field mode, a field mode type advertising packet is broadcast.

42. The method of claim 41, wherein the near-owner type advertising packet includes a first specific structure, and the wild mode type advertising packet includes a second specific structure different from the first specific structure.

43. A method according to claim 41, wherein the near-owner timeout condition is based on at least one of the following items: the location of the accessory device, the motion state of the accessory device, status information received from the electronic device, and a time associated with the accessory device being in the near-owner mode after the encrypted connection with the electronic device is disconnected.

44. The method of claim 41, wherein the near-owner timeout condition comprises a default value.

45. The method of claim 44, wherein the near-owner timeout condition is updateable based on at least one of a location of the accessory device or a motion state of the accessory device.

46. ​​The method of claim 41, further comprising configuring the near-owner timeout condition when the accessory device is connected to the electronic device.

47. The method of claim 41, wherein broadcasting the near-owner type advertising packet and determining to transition from the near-owner mode to the wild mode are performed after disconnecting an encrypted connection with the electronic device.

48. The method of claim 41, wherein the field mode type advertising packet is discoverable by a detector device within wireless range of the accessory device.

49. The method of claim 41 , wherein broadcasting the near-owner type advertising packet in the near-owner mode comprises broadcasting at a first beacon rate, and wherein Broadcasting the wild mode type advertising packet in the wild mode includes broadcasting at a second beacon rate that is greater than the first beacon rate.

50. The method of claim 41, wherein Broadcasting the wild mode-type advertising packet in the wild mode includes updating encryption keys less frequently while broadcasting than broadcasting the near-owner-type advertising packet in the near-owner mode.

51. An accessory device comprising: a memory for storing instructions; and One or more processors configured to execute the instructions, wherein the instructions cause the one or more processors to perform the method according to any one of claims 41 to 50.

52. A non-transitory machine-readable medium storing instructions for causing one or more processors of an accessory device to perform the operations of the method of any one of claims 41 to 50.

53. A computer program product comprising a computer program comprising instructions which, when executed, cause one or more processors of an accessory device to perform the method of any one of claims 41 to 50.

54. A method comprising: detecting, by the electronic device, a beacon advertisement from the beacon wireless device at the first opportunity; determining, by the electronic device, a location estimate of the beacon wireless device at a second time; Sampling the motion state data of the electronic device in an interval between the first time and the second time; as well as Based on determining that the motion state data includes speed data, the horizontal accuracy of the position estimate is adjusted based at least in part on a comparison of the speed data with velocity data derived from the motion state data.

55. The method of claim 54, wherein sampling the motion state data indicates motion of the electronic device between the first time and the second time.

56. The method of claim 54, wherein the velocity data comprises speed and direction data determined via a satellite-based positioning and navigation system of the electronic device.

57. The method of claim 54, wherein the velocity data is determined via a sensor-based velocity calculation.

58. The method of claim 54, further comprising storing the horizontal accuracy in a beacon payload cache of the electronic device.

59. The method of claim 54, further comprising storing the beacon advertisement along with other beacon advertisements in a beacon payload cache.

60. The method of claim 59, wherein adjusting the horizontal accuracy of the position estimate is performed asynchronously by accessing the beacon payload cache.

61. The method of claim 54, wherein the electronic device comprises a detection system comprising a motion classifier, a position subsystem, a horizontal precision adjustment subsystem, and a beacon payload cache.

62. The method of claim 61, wherein determining the location estimate of the beacon wireless device is performed by the location subsystem.

63. The method of claim 61 , wherein adjusting the horizontal accuracy of the position estimate is performed by the horizontal accuracy adjustment subsystem.

64. An electronic device comprising: a memory for storing instructions; and One or more processors configured to execute the instructions, wherein the instructions cause the one or more processors to perform the method according to any one of claims 54 to 63.

65. A non-transitory machine-readable medium storing instructions for causing one or more processors of an electronic device to perform the operations of the method according to any one of claims 54 to 63.

66. A computer program product comprising a computer program comprising instructions which, when executed, cause one or more processors of an electronic device to perform the method according to any one of claims 54 to 63.

Images