System and method for positioning a wireless accessory

Abstract

This application relates to "systems and methods for locating wireless accessories". The embodiments described herein provide systems and methods for crowdsourcing the location of wireless devices and accessories lacking wide area network connectivity. One embodiment provides a data processing system configured to perform operations including: loading a user interface on an electronic device, the user interface enabling the determination of the location of a wireless accessory associated with the electronic device; generating a set of public keys included in a signal broadcast by the wireless accessory during a first time period; sending the set of public keys to a server and requesting the return of data corresponding to one of the public keys in the set; decrypting the location data using a private key associated with the public key; and processing the location data to determine the possible location of the wireless accessory.

Description

[0001] This application is a divisional application of the invention patent application filed on August 30, 2019, with application number 201910810966.4 and entitled "System and method for locating wireless accessories". Technical Field

[0002] The implementation schemes described herein relate generally to systems and methods for locating wireless devices and accessories. More specifically, the implementation schemes relate to crowdsourcing the location of wireless devices and accessories not connected to a wide area network. Background Technology

[0003] Current security features in handheld and portable products allow for identification of the product's location upon user request, such as in the event of loss or theft. If the wireless device includes positioning technology, it can be configured to report its last location to a server computer, which is then displayed on a map presented to the user via a service. Typically, wireless devices are used in conjunction with wireless accessory devices that cannot determine their location and cannot communicate with the remote tracking service over a wide area network. These accessory devices can include, for example, wireless earbuds, binoculars, headphones, and other wearable devices that communicate directly with the wireless device using peer-to-peer communication (e.g., smartwatches, fitness trackers, optical head-mounted displays). When wireless accessory devices that cannot determine their location and cannot communicate with the remote tracking service are lost or stolen, those devices cannot be tracked by the service. Summary of the Invention

[0004] The embodiments described herein provide systems and methods for crowdsourcing the locations of wireless devices and accessories lacking wide area network connectivity. One embodiment provides a data processing system configured to perform operations including: loading a user interface on an electronic device that enables the determination of the location of a wireless accessory associated with the electronic device; generating a set of public keys included in a signal broadcast by the wireless accessory during a first time period; sending the set of public keys to a server and requesting the return of data corresponding to one of the public keys in the set; decrypting the location data using a private key associated with the public key; and processing the location data to determine the possible location of the wireless accessory.

[0005] One embodiment provides a data processing system comprising: a memory for storing execution instructions; and one or more processors for executing the instructions stored in the memory. These instructions, when executed, cause the one or more processors to: load a user interface on an electronic device including the data processing system, the user interface enabling the determination of the location of a wireless accessory associated with the electronic device; generate a set of public keys included in a signal broadcast by the wireless accessory during a first time period; send the set of public keys to a server and request the return of data corresponding to one of the public keys in the set; in response to receiving location data from the server, decrypt the location data using a private key associated with the public key; and process the location data to determine the possible location of the wireless accessory.

[0006] One implementation provides a method implemented on an electronic device, comprising performing a beacon scan using the electronic device's baseband processor. The beacon scan can be performed when the electronic device's application processor is in a low-power state. The method further includes receiving beacon data via a wireless device coupled to the baseband processor, the beacon data being used to identify a wireless accessory. The beacon identifier can be a public key generated by the wireless accessory. The method further includes: storing a timestamp and the beacon identifier in a beacon scan buffer; determining the location of the electronic device corresponding to the timestamp when the electronic device's application processor is active; encrypting the location of the electronic device using the beacon identifier of the wireless accessory; and transmitting the encrypted location data, the beacon identifier, and the timestamp to a server device, the server storing the encrypted location data for retrieval by the electronic device associated with the wireless accessory.

[0007] The above overview does not include an exhaustive list of all embodiments of this disclosure. All systems and methods may be practiced in all suitable combinations of the aspects and embodiments outlined above and those disclosed in the following detailed description. Attached Figure Description

[0008] The invention is illustrated by way of example and is not limited to the figures in the accompanying drawings, in which similar reference numerals indicate similar elements, and wherein:

[0009] Figure 1 It is a block diagram of the network operating environment for mobile devices according to the implementation plan;

[0010] Figure 2 A system for locating wireless accessories that cannot access a wide area network, according to an embodiment, is shown;

[0011] Figure 3 A system for pairing and locating wireless accessories according to an embodiment described herein is shown;

[0012] Figures 4A to 4C This is a flowchart illustrating a method for use with the device locator system described herein;

[0013] Figure 5 This is a flowchart illustrating a method for broadcasting a signal beacon at a wireless attachment according to an implementation scheme;

[0014] Figures 6A to 6B The operation of a method that can be performed by a detector device according to the embodiments described herein is illustrated;

[0015] Figure 7 The acquisition of signal and ranging data performed by the detector device according to the implementation scheme is illustrated;

[0016] Figure 8 A networking system for locating devices and wireless accessories, according to an embodiment, is shown;

[0017] Figures 9A to 9C The device locator user interface according to the implementation scheme is shown;

[0018] Figure 10 The accessory pairing user interface displayed when attempting to pair with a lost wireless accessory, according to the embodiment, is shown.

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

[0020] Figure 12 It is a block diagram of a device architecture for mobile or embedded devices according to the implementation plan; and

[0021] Figure 13 It is a block diagram of the computing system according to the implementation plan. Detailed Implementation

[0022] The embodiments described herein provide techniques for enabling secure crowdsourced locator services for lost or misplaced devices unable to communicate with a wide area network. Various embodiments and aspects will be described with reference to the details of the following discussion, 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 comprehensive understanding of the various embodiments. However, in some instances, well-known or conventional details have not been described in order to provide a concise discussion of the embodiments.

[0023] The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. Unless the context clearly indicates otherwise, the singular forms “a” and “an” are intended to also cover the plural forms as used in this specification and the appended claims. It should also be understood that the term “and / or” as used herein refers to and covers any and all possible combinations of one or more of the associated listed items. It should be further understood that the term “comprising” as used in this specification specifies the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0024] This disclosure contains copyrighted material. Because this patent document or this patent disclosure appears in patent documents or records of the Patent and Trademark Office, the copyright holder does not object to any reproduction of this patent document or this patent disclosure, but otherwise reserves all copyright rights in any form. Copyright 2018 Apple Inc.

[0025] 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 run on the device may use at least one common physical user interface device, such as a touch-sensitive surface. One or more functions of the touch-sensitive surface, and the corresponding information displayed on the device, may be adjusted and / or changed from one application to another, and / or within the respective application. In this way, the shared physical architecture of the device (such as the touch-sensitive surface) can support various applications using an intuitive and transparent user interface.

[0026] The following describes some procedures for sequential operations. However, it should be understood that some of these operations can be performed in a different order. Furthermore, some operations can be performed in parallel rather than sequentially.

[0027] Figure 1This is a block diagram of a network operating environment 100 for mobile devices according to an embodiment; the network operating environment 100 includes multiple mobile devices, such as mobile device 102A and mobile device 102B. Mobile devices 102A to 102B may each be any electronic device capable of communicating with wireless networks and wireless accessory devices. Some exemplary mobile devices include, but are not limited to, smartphones, tablets, laptops, wearable computers (e.g., smartwatches 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 for mobile device 102B. Mobile devices 102A and 102B can communicate via one or more wired and / or wireless networks 110 to perform data communication. For example, wireless network 112 (e.g., cellular network, Wi-Fi network) can communicate with wide area network 114 (such as the Internet) using gateway 116. Similarly, access device 118, such as a mobile hotspot wireless access device, can provide communication access to wide area network 114. Then, gateway 116 and access device 118 can communicate with wide area network 114 via a combination of wired and / or wireless networks.

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

[0029] Mobile device 102A or mobile device 102B can communicate with one or more services, such as telephone service 130, instant messaging service 140, media service 150, storage service 160, and device locator service 170, via one or more wired and / or wireless networks 110. For example, telephone service 130 enables telephone communication between mobile devices 102A and 102B, or between a mobile device and a wired telephone device. Telephone service 130 can route IP-based voice (VoIP) calls via wide area network 114, or can access a cellular voice network (e.g., wireless network 112). Instant messaging service 140 can, for example, provide email and / or other instant messaging services. Media service 150 can, for example, provide access to media files, such as song files, audiobooks, movie files, video clips, and other media data. Storage service 160 can provide network storage capabilities to mobile devices 102A and 102B to store documents and media files. Device locator service 170 enables a user to locate a lost or misplaced device that was connected to one or more wired and / or wireless networks 110 at least at some point in time. Other services may also be provided, including software update services for updating operating system software or client software on mobile devices. In one embodiment, messaging service 140, media service 150, storage service 160, and device locator service 170 may each be associated with a cloud service provider, wherein the various services are facilitated via cloud service accounts associated with mobile devices 102A to 102B.

[0030] Figure 2 A system 200 for locating a wireless accessory 201 that cannot access a wide area network (WAN) is illustrated according to an embodiment. In one embodiment, the wireless accessory 201 includes one or more wireless transceivers and communicates directly or indirectly (e.g., via another device or computer) with an accompanying device (e.g., mobile device 102) via a wireless network or peer-to-peer communication link. Some examples of wireless accessory devices include, but are not limited to, wireless earbuds, binocular headphones, headsets, and other wearable devices (e.g., smartwatches, fitness trackers, optical head-mounted displays). The wireless accessory 201 may also include other wireless devices, such as game controllers or remote controls. In one embodiment, the wireless accessory 201 also includes smartphones, tablets, laptops, smart speaker devices, televisions, or devices that at least temporarily cannot access a WAN such as the Internet (e.g., as...). Figure 1The wireless accessory 201 is a set-top box for a wide area network (WAN 114). The wireless accessory can also be any other wireless device, including beacons or locator tags that can be attached to other devices to enable tracking or location of those devices. In one embodiment, the wireless accessory 201 can be paired with the mobile device 102 using wireless technology standards such as, but not limited to, Bluetooth. The wireless accessory 201 can also communicate with the mobile device 102 via wireless technologies such as Wi-Fi Direct, Zigbee, or AirPlay. Although the accompanying device paired with the wireless accessory 201 is generally referred to as the mobile device 102, the accompanying device is not limited to the mobile device. In some embodiments, the accompanying device may also include a laptop or desktop device, and may additionally include wearable accessories such as, but not limited to, smartwatch devices or wearable displays.

[0031] In one embodiment, the wireless accessory 201 may periodically transmit a wireless beacon signal. The wireless accessory 201 may utilize one of the various wireless technologies described herein (e.g., Bluetooth, Wi-Fi, etc.) to transmit the beacon signal, and in one embodiment, ultra-wideband (UWB) radio technology may also be used for beacon transmission. The beacon signal may be transmitted using a single wireless technology, one of several alternative wireless technologies, or several concurrently occurring wireless technologies. The beacon signal may transmit a beacon identifier, which includes information specifically identifying the wireless accessory 201. In one embodiment, the beacon identifier is a public encryption key associated with the device.

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

[0033] The beacon signal can be detected by a detector device 202 located locally near the wireless accessory 201. The detector device 202 can be a device similar to the mobile device 102 and can receive and transmit data via the wide area network 114, utilizing wireless technologies similar to the wireless accessory 201 (e.g., Bluetooth, etc.). Specifically, the detector device 202 can utilize the wireless protocol through which it transmits the beacon signal to receive data. The detector device 202 can utilize one or more location and / or positioning services to determine its location, including but not limited to satellite positioning service 206 or a terrestrial positioning system utilizing RF signals received from a wireless base station 205 (such as a Wi-Fi access point in a cellular phone network or a cell tower transmitter). In one embodiment, the detector device 202 periodically stores its location determined based on one or more location and / or positioning services. The stored location can be associated with a timestamp for determining that location. 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 detector device 202 can be associated with the timestamp of receiving the beacon signal to associate the geographic location with the received beacon signal.

[0034] With the wireless accessory 201 providing 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 may be transmitted encrypted along with the location data, or transmitted unencrypted to the device locator server 203. For example, the signal strength indicator (RSSI) of the received beacon signal may 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 to assist in triangulation on the owner device. In the case where the RSSI data is transmitted unencrypted, in one embodiment, the server may use the RSSI information to reduce noise by discarding very weak signals if other stronger signals are present. In one embodiment, UWB ranging data may also be provided, where such data is available.

[0035] In one implementation, the detector device 202 may play different roles when receiving a beacon signal from the wireless accessory 201, depending on the device status conveyed by the wireless accessory 201. For a standard beacon signal, the detector device 202 may queue 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 status, the detector device 202 may immediately transmit the location data to the device locator server 203. Alternatively, if the beacon signal from the wireless accessory 201 indicates that the accessory is near its owner, the detector device 202 may not transmit the location data to the device locator server 203. Alternatively, the detector device 202 may delay the transmission of encrypted location data.

[0036] If the owner of wireless accessory 201 wishes to locate the wireless accessory, the owner can access device locator user interface 204 on mobile device 102. Device locator user interface 204 may be associated with a device locator application 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 can 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 the 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 the associated private key. The decrypted location data is then processed by mobile device 102 to determine the most probable location of wireless accessory 201. In various implementations, the most probable location of the wireless accessory 201 can be determined by triangulation of multiple received locations and by using other data, such as the beacon signal RSSI associated with each location and timestamps or UWB ranging data included in the location data.

[0037] Figure 3A system 300 for pairing and locating a wireless accessory according to an embodiment described herein is illustrated. In one embodiment, a user's mobile device 102 of the wireless accessory 201 may present an accessory pairing UI 302 through which the user pairs the mobile device 102 with the wireless accessory 201. During the initial pairing (305) between the mobile device 102 and the wireless accessory, a public key exchange (310) may be performed between the mobile device and the wireless accessory. In one embodiment, during the public key exchange (310), the mobile device 102 and the wireless accessory 201 exchange the public key in a public key pair generated by the device and the accessory. In one embodiment, the public key exchange (310) is a one-way transmission, wherein the mobile device 102 transmits the public key in the public / private key pair to the wireless accessory 201. Alternatively or in addition, the public key exchange (310) may be a Diffie-Hellman key exchange, wherein the device and the accessory establish a shared secret between the two parties. In one embodiment, the public key exchange (310) further utilizes elliptic curve cryptography to establish the shared secret. For example, Elliptic Curve Diffie-Hellman (ECDH) can be used to establish public key pairs and one or more shared secrets. In one implementation, the one or more shared secrets include an anti-tracking secret, which allows the wireless accessory 201 to periodically derive additional public keys.

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

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

[0040] In one implementation, reverse tracking resistance can be enabled to protect the anti-tracking secret in the event that the wireless accessory 201 is compromised. When reverse tracking resistance is enabled, the anti-tracking secret is transmitted to the wireless accessory 201, but the wireless accessory does not retain the anti-tracking secret. Instead, the accessory calculates the value... ( (||time), among which, H is a cryptographic hash function. Then, the wireless accessory 201 stores the hash function within a given time period i. If wireless accessory 201 is compromised, only the value i used for current and future data will be exposed. And without exposing the anti-tracking secret AT. In one implementation, reverse tracking resistance is achieved by periodically... The process is executed by writing to the non-volatile memory of the wireless accessory 201.

[0041] In one implementation, the wireless accessory 201 may transmit the beacon signal 301 every two seconds, but other beacon rates may also be used, and the beacon rate may be changed in certain situations. For example, when in a near-owner state, the wireless accessory 201 may reduce the beacon rate. The beacon rate may also be changed based on an event triggered by an accelerometer. For example, when in an alarm state, the wireless accessory 201 may increase the beacon rate, which may be triggered by an accelerometer on the wireless accessory 201.

[0042] If, after transmitting beacon signal 301, wireless accessory 201 receives a response from 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 may enter a near-owner state. Additionally, when the wireless accessory is in a near-owner state, the amount of data transmitted by beacon signal 301 may be reduced. In one embodiment, the rate of generating new public keys may also be reduced when the wireless accessory is in a near-owner state.

[0043] Wireless accessory 201 may enter an alarm state upon receiving a message from mobile device 102 instructing it to enter an alarm state. While in an alarm state, the wireless accessory may initially enter a standby state in which it reduces or stops the transmission of locator beacon signals, but other types of wireless signaling may persist. Wireless accessory 201 may remain in this standby state until mobile device 102 deactivates the state or an alarm is triggered. In one embodiment, the alarm may be triggered, for example, when movement is detected via an accelerometer within wireless accessory 201. In another embodiment, the alarm may 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 an alarm is triggered, the rate of beacon signal 301 may be increased to increase the speed at which the locator wireless accessory 201 can be located.

[0044] The beacon signal 301 transmitted by the wireless accessory 201 can be detected by a set of detector devices 303. This set of detector devices is other electronic equipment capable of receiving the beacon signal transmitted by the wireless accessory and transmitting 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, this set of detector devices 303 includes a variant of the mobile device 102, or may be other types of electronic equipment. This set of detector devices 303 may include... Figure 2 A variant of the detector device 202, and capable of determining similar location techniques. For example, this set of detector devices can perform operation (320) to associate a beacon signal 301 received from the wireless accessory 201 with the location of the device associated with the detector device. As relative to Figure 2 The device location can be determined via satellite positioning services or by a terrestrial positioning system using RF signals received from a wireless base station (e.g., a Wi-Fi access point or a cell tower transmitter). In one embodiment, the detector device 303 may also include fixed devices, such as a smart speaker device, a television, or a set-top box capable of receiving beacon signals 301.

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

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

[0047] When the user or owner of wireless accessory 201 wishes to locate the accessory, the user or owner can access device locator UI 204 on mobile device 102. Device locator UI 204 may be associated with a device locator application or feature of mobile device 102. Device locator UI 204 may also have a web-based interface accessible from mobile device 102 or another type of electronic device, such as a laptop or desktop device. When device locator UI 204 is loaded, mobile device 102 may send a request (330) for location data to device locator server 203. Request 330 may include a set of public keys or public key hashes that can 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 indicating that mobile device 102 wishes to receive location data. In one embodiment, this set of public keys is a sequence of public keys generated based on an anti-tracking secret. Public key sequence Matching sequence with private key Correspondingly, mobile device 102 can generate a public key sequence and a corresponding public key sequence. , where i is a counter or timestamp. In one implementation, mobile device 102 may generate and send the public key (or a hash of the public key for the previous 24 hours) within request 330. If no data for the 24-hour public key is found, mobile device 102 may send the generated key in an earlier time period, returning to a predetermined location data retention limit.

[0048] In one implementation, encrypted location data is stored and indexed based on a hash of the public key, rather than the public key itself, to prevent the location service data provider from storing data that could be used to associate the encrypted location data with a specific device, and thus with a specific user or user account. The detector device may send a hash of the public key broadcast within a beacon signal 301 associated with the observed location. The device owner can use the hash of the public key, determined for a specific query period, to query the device locator server 203.

[0049] In some implementations, if a location query is to be performed via a web-based interface from an electronic device (such as a laptop or desktop device), it may be necessary to send a key that enables the decryption of the location data to the electronic device. In one implementation, the decryption key for the location data may be sent to a server providing the web-based interface, enabling the server to decrypt the location data at least when it is viewed through the web-based interface. Before displaying the location data via the web-based interface, a notification may be presented to inform the user that a location decryption key is being temporarily shared with the web-based interface server to enable the decryption and presentation of the location data. In one implementation, the sharing of the location decryption key may be performed via automatic and temporary authorization of location query permissions for an agent account associated with the web-based interface.

[0050] In one implementation, the wireless accessory 201 can be placed in a lightly lost mode. In lightly lost mode, a set of future public keys can be generated for the wireless accessory and transmitted to the device locator server 203. Then, if any location data corresponding to a key in this set of future public keys is received, the device locator server 203 can notify the mobile device 102. In one implementation, a detector device sending the location of the wireless accessory in lightly lost mode can be guided by the device locator server 203 to relay a message to the wireless accessory 201 notifying it that it is in lightly lost mode. A similar mechanism can also be used to relay messages to the wireless accessory 201 that puts it 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 be paired with another device unless the owner unlocks the wireless accessory.

[0051] Figures 4A to 4CThis is a flowchart 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 for determining the location of a wireless accessory via a device locator server is shown. Figure 4C An additional method 420 for determining the location of a wireless accessory via a device locator server is shown. Aspects of methods 400, 410, and 420 are also described. Figure 2 and Figure 3 As shown above, the following description of operations relates to mobile device 102, wireless accessory 201, and device locator server 203.

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

[0053] The mobile device can then generate a public / private key pair and one or more additional shared secrets (box 402). The device can then send the public key and one or more additional shared secrets to a wireless accessory (box 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 may include a trace-proof secret that enables the wireless accessory to derive a new public key based on the existing public key.

[0054] After generating a public / private key pair and one or more additional shared secrets, the mobile device can store the public / private key pair in a keystore (box 404). In one implementation, the keystore is a cloud-based keystore 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 wireless accessory are associated. The cloud-based keystore allows the wireless accessory to be located by other synchronized devices. The mobile device can then register the wireless accessory with a device management server (box 405). Registering the wireless accessory with the device management server establishes an association between the wireless accessory and the cloud service account to which the mobile device is associated. The device management server can also be connected to other cloud-based servers (such as...) Figure 2 and Figure 3The device locator server (203) is associated with this other cloud-based server, which is used to facilitate cloud-based services accessible to mobile devices.

[0055] like Figure 4B As shown, method 410 includes the operation of an electronic device activating a device locator UI (box 411). In response to activating 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 an operation to generate a set of public keys, which are included in a beacon signal broadcast by the wireless accessory during a first time period (box 412). The first time period may be, for example, a previous 24 hours. The electronic device knows the frequency at which the wireless accessory generates new public keys, and the electronic device may use a shared secret generated by the wireless accessory to generate a set of public keys that correspond to the keys generated by the wireless accessory during the first time period. The electronic device may then send this set of public keys and request the device locator server to send location data corresponding to this set of public keys (box 413). In one embodiment, the location data sent by the server in response to the request is encrypted using the public key transmitted as a beacon identifier of the wireless accessory. The electronic device may decrypt the encrypted location data received by the server using a private key generated during the initial pairing with the wireless accessory (box 414). The electronic device may then process the location data to determine the highest probability location of the wireless accessory (box 415).

[0056] Processing location data can include a variety of different operations. In one embodiment, the location data includes latitude and longitude information along with a timestamp used to determine the location. Electronic devices can perform triangulation based on the timestamp and remove noise or anomalous locations. In one embodiment, the location data specifies the location of a detector device that detected a beacon. The location data may additionally include UWB ranging information and / or RSSI information of the beacon detected by the detector device. Electronic devices can combine the device location analysis with the UWB ranging information and / or RSSI information to develop a more accurate location for the wireless accessory. Data that can be transmitted by the detector device and used for location processing is... Figure 10 It is shown and described below.

[0057] like Figure 4CAs shown, method 420 includes operations that can be performed if the device locator server does not have location data to provide to the electronic device in response to a request. The electronic device may generate a first set of public keys included in a beacon signal broadcast by a wireless accessory during a first time period (box 421). The first time period may be, for example, 24 hours, but other initial search time periods may be used. The electronic device may 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 this set of public keys to decrypt the location data received from the server (box 429).

[0058] If the server does not return data (box 423, "No"), the electronic device may generate a second public key included in the beacon signal broadcast by the wireless accessory during a second time period (box 424). The second time period may be 24, 48, or other hours prior to the first time period. The electronic device may then request the device locator server to send data corresponding to the second public key (box 425). If the server returns data in response to the request (box 426, "Yes"), method 420 may proceed to box 429, where the electronic device decrypts the received data. If the server does not return data (box 426, "No"), or the server sends a reply indicating that the data is unavailable, method 420 includes widening the search time by continuously requesting earlier time periods until a maximum time period is reached (box 427).

[0059] Figure 5 This is a flowchart illustrating a method 500 for broadcasting a signal beacon at a wireless location according to an embodiment. Aspects of method 500 are also... Figure 2 and Figure 3 As shown in the diagram. Method 500 includes deriving a public key from a wireless accessory (box 502). The public key can be derived based on a shared secret and a timestamp determined by a clock or timing device of the wireless accessory. The wireless accessory can then transmit a beacon signal at a first frequency, wherein the beacon signal includes the public key (box 503). The first frequency can be varied, and in one embodiment, a beacon is transmitted every two seconds.

[0060] After transmitting the beacon signal, the wireless accessory can listen for a response from the owner device. If a response is received from the owner device (box 504, "Yes"), the wireless accessory can enter near-owner state (box 505) and begin transmitting the beacon signal at a lower second frequency (box 507). If the wireless accessory does not receive a response from the owner device (box 504, "No"), the wireless accessory can continue transmitting the beacon at a first frequency (box 506).

[0061] Method 500 further includes, while transmitting beacons, the wireless device rotating the public key every M minutes, where the value of M may change between implementations and / or based on device state. Based on timer expiration, a counter, or other mechanism, the wireless attachment can determine whether it has entered a new key period (box 508). Even if the wireless attachment has not yet entered a new key period (box 508, "No"), the attachment can continue transmitting beacons using the current public key (box 510). When the wireless attachment detects that it has entered a new key period (box 508, "Yes"), the attachment can derive a new public key using the current timestamp (box 509). In one implementation, the new public key can be derived using an existing public key, a timestamp, and an anti-tracking secret.

[0062] Figures 6A to 6B The operation of method 600, which can be performed by a detector device according to the embodiment described herein, is illustrated. Aspects of method 600 are also... Figure 2 and Figure 3 As shown in the image.

[0063] like Figure 6A As shown, method 600 includes the detector device performing periodic beacon scanning using a wireless baseband processor when the application processor of the detector device is in a low-power mode (box 601). While beacon scanning can also be performed when the application processor is active, it can be performed by the wireless processor and radio receiver as low-power operations 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 scanning buffer for use with any beacon data received by the detector device (box 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.

[0064] Method 600 further includes the detector device performing periodic Wi-Fi scans using the wireless processor when the application processor is in a low-power mode (box 603). While Wi-Fi scanning can also be performed when the application processor is active, when the detector device is idle, inactive, or otherwise in a low-power state, the Wi-Fi scan can be performed by the wireless processor and radio receiver in low-power operation. The detector device can then store the Wi-Fi Service Set Identifier (SSID) and scan timestamp in a Wi-Fi scan buffer on the detector device (box 604).

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

[0066] Method 600 in Figure 6B The process continues, and includes: if other location data is available, the detector device correlates the device location from the Wi-Fi scan buffer data with other location data (box 607) to generate a refined device location. If a refined device location is generated, the detector device may optionally combine 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 transmitted 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 batches and throttling. A batch of encrypted data can be collected and placed in a transmission queue until the transmission interval is reached. During this period, the detector device can transmit the data to the cloud service server (box 612).

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

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

[0069] Figure 8 A networking system 800 for locating devices and wireless accessories according to an embodiment is illustrated. System 800 also illustrates 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 may be physical or virtual servers within a single data center, or distributed across multiple data centers and / or geographical locations. As described above, the device locator server 203 can communicate via a wide area network 114 with a mobile device 102 of the accessory owner or user and this group of detector devices 303. The mobile device 102 includes a UI provided by a local or web application that enables the location of the wireless accessory, and the detector devices 303 receive beacon signals from the wireless accessory and transmit the location data associated with the received signals to the device locator server 203.

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

[0071] In one implementation, account database 825 may contain a list of devices associated with each cloud service account. In response to a request to locate a given device (including wireless accessories as described herein), account database 825 may verify that the request originates from a device authorized to request the location of the given device. In one implementation, when a user initiates the device locator UI and communicates with locator service frontend 803, the locator service frontend may communicate with 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.

[0072] In one implementation, the database cluster manager 813 can select database cluster nodes 823A to 823C to store beacon data by performing a hash operation on beacon IDs 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 into the cluster nodes corresponding to the range of hash values ​​associated with a hash of a given beacon ID. Although three database cluster nodes are shown, the implementation is not limited to any particular number of nodes and more or fewer nodes can be used.

[0073] Figures 9A to 9C The device locator UI 204 according to the implementation scheme is shown. Figure 9A A first graphical user interface of a device locator UI 204 according to one embodiment is shown, which displays the location of the user's various electronic devices and wireless accessories. Figure 9B A second graphical user interface for a device locator UI 204 according to one embodiment is shown, which enables the wireless accessory to be set to alarm mode. Figure 9C A third graphical user interface for a device locator UI 204 according to one embodiment is shown, which enables the wireless accessory to be set to lost mode.

[0074] 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 various types of devices and accessories can be located, including wireless devices with network or cellular access and wireless accessories without local network access. The device locator UI 204 may include a map 901 with markers 902 indicating the current or last known location of the wireless device or accessory. Markers 902 can be icons, images, graphics, or any other user interface element that identifies the accessory and conveys its location. Optional elements 903 in the device locator UI can present a description or name of the wireless device or accessory and can show the estimated distance between the wireless device or accessory and the current location of the electronic device 900.

[0075] like Figure 9B As shown, the device locator UI 204 can present a second user interface that allows the wireless accessory to be set to alarm mode. In one embodiment, the second user interface can respond to selection Figure 9A The optional element 903 shown is displayed. The second user interface may present user interface elements 904 representing and / or describing the wireless accessory under consideration, as well as a map 901 and markers 902 displaying the current or last known location of the wireless accessory. In one embodiment, the device locator UI 204 may present selectable elements 905, such as buttons or another user interface element, that allow the user of the device locator UI 204 to put the selected wireless accessory into alarm mode. When in alarm mode, the wireless accessory can be configured to trigger a notification to the user if the wireless accessory moves from its current location.

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

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

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

[0079] In one implementation, a message and contact information provided by the requesting user can be displayed on the user's device to indicate how the person who found the lost wireless accessory can contact the requesting user. In another implementation, the message and contact information can be displayed when another user attempts to pair another electronic device with the lost accessory.

[0080] Figure 10 The illustration 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, different from the electronic device 9000 of FIG9 and not associated with the registered user or owner of the wireless accessory, attempts to pair with the lost wireless accessory, the accessory pairing UI of that electronic device may be as follows: Figure 10As shown in the diagram. In one embodiment, the accessory pairing UI 302 may display a name or description 1001 associated with the wireless accessory, and a message 1002 entered by the user of the accessory when the accessory is placed in lost mode. Contact information 1004 may also be displayed along with user interface elements 1006, such as buttons, which enable the electronic device 1000 to contact the requesting user using the provided contact information 1004.

[0081] The implementation described herein includes one or more application programming interfaces (APIs) in an environment, where calling program code interacts with other program code invoked through one or more programming interfaces. Various function calls, messages, or other types of calls may further include various parameters, which can be transferred via the API between the calling program and the called program code. Furthermore, 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.

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

[0083] In some implementations, 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, while another API of the API implementation component may be hidden (not exposed) and provide a subset of the first set of functions, as well as another set of functions, such as test or debug functions not in the first set. In other implementations, the API implementation component itself may call one or more other components via a lower-level API, thus acting as both an API calling component and an API implementation component.

[0084] An API defines the language and parameters used by an API-invoking component when accessing and using specified features of an API-implemented component. For example, an API-invoking component accesses specified features of an API-implemented 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 these API calls or references. An API-implemented component may return a value via the API in response to an API call from an API-invoking component. While an API defines the syntax and results of API calls (e.g., how an API call is initiated and what it can do), it 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 invoking component (API-invoking component) and the API-implemented component. Transmitting API calls may include issuing, initiating, referencing, calling, receiving, returning, or responding to function calls or messages; in other words, transmission can describe the actions of either the API-invoking component or the API-implemented component. API function calls or other references may send or receive one or more parameters via parameter lists or other structures. Parameters can be constants, keys, data structures, objects, object classes, variables, data types, pointers, arrays, lists, or pointers to functions or methods, or references to data or other items to be passed via the API.

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

[0086] Typically, APIs can be used to access services or data provided by API implementation components, or to initiate operations or computations provided by API implementation components. By way of example, API implementation components and API calling components can each be any of an operating system, library, device driver, API, application, or other module (it should be understood that API implementation components and API calling components can be the same or different types of modules). In some cases, API implementation components may be implemented at least partially in firmware, microcode, or other hardware logic components. In some implementations, an API may allow client programs to use services provided by a Software Development Kit (SDK) library. In other implementations, applications or other client programs may use APIs provided by an application framework. In these implementations, applications or client programs may incorporate calls into functions or methods provided by both the SDK and the API, or use data types or objects defined in the SDK and provided by the API. In these implementations, the application framework may provide a main event loop for the program, which responds to various events defined by the framework. APIs allow applications to utilize the application framework to specify events and responses to events. In some implementations, API calls can report the capabilities or status of hardware devices to the application, including capabilities or status related to input capabilities and status, output capabilities and status, processing capabilities, power status, storage capacity and status, communication capabilities, etc., and the API may be implemented in part by firmware, microcode, or other low-level logic components that execute in part on the hardware components.

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

[0088] An API can allow multiple API calling components written in different programming languages ​​to communicate with an API implementation component (therefore, the API may include features for translating calls and returns between the API implementation component and the API calling component); however, the API may be implemented in a specific programming language. In one implementation, 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 plugin provider, as well as another set of APIs from another provider (e.g., a software library provider) or the creator of another set of APIs.

[0089] Figure 11 This is a block diagram illustrating an exemplary API architecture that can be used in some embodiments of the present invention. For example... Figure 11 As shown, API architecture 1100 includes API implementation component 1110 (e.g., operating system, library, device driver, API, application, software, or other module) that implements API 1120. API 1120 specifies one or more functions, methods, classes, objects, protocols, data structures, formats, and / or other characteristics of the API implementation component that can be used by API calling component 1130. API 1120 is capable of specifying 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., operating system, library, device driver, API, application, software, or other module) makes API calls through API 1120 to access and use the characteristics 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 API calls.

[0090] It should be understood that API implementation component 1110 may include additional functions, methods, classes, data structures, and / or other features not specified through API 1120 and not available to API calling component 1130. It should be understood that API calling component 1130 may be on the same system as API implementation component 1110, or may be remotely located and accessed via a network using API 1120. Although Figure 11 The example shows a single API call component 1130 interacting with API 1120, but it should be understood that other API call components, written in different languages ​​(or the same language) and different from API call component 1130, can use API 1120.

[0091] API implementation component 1110, API 1120, and API call component 1130 may be stored in machine-readable media, including any mechanism for storing information in a machine-readable form (e.g., a computer or other data processing system). For example, machine-readable media include disks, optical disks, random access memory, read-only memory, flash memory devices, etc.

[0092] Figure 12This is a block diagram of a device architecture 1200 for a mobile or embedded device according to an implementation scheme. Device architecture 1200 includes a memory interface 1202, a processing system 1204 including one or more data processors, an image processor and / or graphics processing unit, and a peripheral device interface 1206. Various components can be coupled via one or more communication buses or signal lines. These components can be individual logic components or devices or can be integrated into one or more integrated circuits, such as system-on-a-chip (SoC) integrated circuits.

[0093] 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.).

[0094] Sensors, devices, and subsystems can be coupled to peripheral interface 1206 to enable multiple functions. For example, motion sensor 1210, light sensor 1212, and proximity sensor 1214 can be coupled to peripheral interface 1206 to enable mobile device functionality. One or more biometric sensors 1215, such as fingerprint scanners for fingerprint recognition or image sensors for facial recognition, may also be present. Other sensors 1216 may also be connected to peripheral interface 1206, such as positioning systems (e.g., GPS receivers), temperature sensors, or other sensing devices to enable related functions. Camera subsystem 1220 and optical sensors 1222 (such as charge-coupled devices (CCDs) or complementary metal-oxide-semiconductor (CMOS) optical sensors) can be used to enable camera functions, such as taking photos and video clips.

[0095] Communication functions can 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 through which the mobile device intends 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, CDMA network, LTE network, Wi-Fi network, Bluetooth network, or any other wireless network. Specifically, the wireless communication subsystem 1224 may provide a communication mechanism in which a media playback application can retrieve resources from a remote media server or retrieve scheduled events from a remote calendar or event server.

[0096] The audio subsystem 1226 can be coupled to the speaker 1228 and microphone 1230 to facilitate voice-enabled functions such as speech recognition, speech copying, digital recording, and telephone functionality. In the smart media device described herein, the audio subsystem 1226 may include a high-quality audio system supporting virtual surround sound.

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

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

[0099] 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, thumbwheels, infrared ports, USB ports, and / or pointing devices such as styluses, or up / down buttons of volume controls for control devices such as speakers 1228 and / or microphones 1230.

[0100] In one implementation, memory 1250, coupled to memory interface 1202, may store instructions for operating system 1252, including POSIX-compliant and incompatible operating systems or embedded operating systems. Operating system 1252 may include instructions for handling basic system services and for performing hardware-related tasks. In some specific implementations, operating system 1252 may be a kernel.

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

[0102] Furthermore, memory 1250 may store sensor processing instructions 1258 to facilitate sensor-related processing and functions; telephone instructions 1260 to facilitate telephone-related processes and functions; instant messaging instructions 1262 to facilitate electronic message processing and functions; web browser instructions 1264 to facilitate web browsing-related processes and functions; media processing instructions 1266 to facilitate media processing-related processes and functions; location service instructions including GPS and / or navigation instructions 1268 and Wi-Fi-based location instructions to facilitate location-based functionality; camera instructions 1270 to facilitate 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. 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 specific implementations, media processing instructions 1266 are divided into audio processing instructions and video processing instructions, used to facilitate audio processing-related processes and functions and video processing-related processes and functions, respectively. Mobile device identifiers, such as International Mobile Equipment Identity (IMEI) 1274 or similar hardware identifiers, may also be stored in memory 1250.

[0103] Each of the instructions and applications identified above may correspond to a set of instructions for performing one or more of the functions described above. These instructions do not need to be implemented as a separate software program, process, or module. Memory 1250 may include additional instructions or fewer. Furthermore, various functions may be performed in hardware and / or software, including in one or more signal processing and / or application-specific integrated circuits.

[0104] Figure 13This is a block diagram of a computing system 1300 according to an embodiment. The computer system 1300 shown is intended to represent one or more specific implementations of a series of computing systems (wired or wireless), including, for example, desktop computer systems, laptop computer systems, tablet computer systems, cellular phones, personal digital assistants (PDAs) including cellular-enabled PDAs, set-top boxes, entertainment systems or other consumer electronic devices, smart electrical devices, or smart media playback devices. Alternative computing systems may include more, fewer, and / or different components. The computing system 1300 can be used to provide computing devices and / or server devices that may be connected to the computing devices.

[0105] Computer system 1300 includes a bus 1335 or other communication device for transmitting information, and a processor 1310 coupled to the bus 1335 for processing information. Although computing system 1300 is illustrated as having a single processor, computing system 1300 may include multiple processors and / or coprocessors. Computing system 1300 may further include memory 1320 in the form of random access memory (RAM) or other dynamic storage device coupled to the bus 1335. Memory 1320 may store information and instructions executable by processor 1310. Memory 1320 may also be main memory used to store temporary variables or other intermediate information during the execution of instructions by processor 1310.

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

[0107] The computing system 1300 may also be coupled to a display device 1350 via a bus 1335 to display information to a user. The computing system 1300 may also include a numeric / alphanumeric input device 1360, which includes numeric / alphanumeric keys and other keys, and can be coupled to the bus 1335 to transmit information and command options to the processor 1310. Another user input device includes a cursor control device 1370, such as a touchpad, mouse, trackball, or cursor arrow keys, for transmitting directional information and command selections to the processor 1310 and controlling cursor movement on the display device 1350. The computing system 1300 may also receive user input from a communicatively coupled remote device via one or more network interfaces 1380.

[0108] The computing system 1300 may further include one or more network interfaces 1380 to provide access to a network such as a local area network (LAN). The network interface 1380 may include, for example, a wireless network interface with 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 Bluetooth. ® A combination of Near Field Communication (NFC) and / or cellular telephone interfaces. Network interface 1380 may also include, for example, a wired network interface for communicating with remote devices via network cable 1387, which may be, for example, an Ethernet cable, coaxial cable, fiber optic cable, serial cable, or parallel cable.

[0109] In one implementation, network interface 1380 may provide access to a local area network (LAN) for example, via a wireless standard compliant with the IEEE 802.11 standard, and / or wireless network interface may provide access to a personal area network (PAN) for example, via a Bluetooth standard compliant with the standard. Other wireless network interfaces and / or protocols may also be supported. In addition to or instead of communicating via wireless LAN standards, network interface 1380 may use, for example, Time Division Multiple Access (TDMA), Global System for Mobile Communications (GSM), Code Division Multiple Access (CDMA), Long Term Evolution (LTE), and / or any other type of wireless communication protocol to provide wireless communication.

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

[0111] In some implementations, the hash function described herein may utilize dedicated hardware circuitry (or firmware) of the system (client device or server). For example, the function may be a hardware-accelerated function. Furthermore, in some implementations, the system may use a function as part of a dedicated instruction set. For example, an instruction set may be used, which may be an extension of the instruction set architecture for a specific type of microprocessor. Thus, in one implementation, the system may provide a hardware acceleration mechanism for performing cryptographic operations, thereby increasing the speed of executing the function described herein using these instruction sets.

[0112] In this document, references to “an embodiment” or “an embodiment” mean that a particular feature, structure, or characteristic described in connection with that embodiment can be included in at least one embodiment of the invention. The phrase “in an embodiment” appearing in various places throughout this specification does not necessarily refer to the same embodiment. The processes depicted in the following figures are performed by processing logic, which includes hardware (e.g., circuitry, special-purpose logic, etc.), software (as instructions on a non-transitory machine-readable storage medium), or a combination of hardware and software. Various embodiments will now be referenced in detail, examples of which are shown in the accompanying drawings. Numerous specific details are set forth in the following detailed description in order to provide a thorough understanding of the invention. However, it will be apparent to those skilled in the art that the invention can be practiced without these specific details. In other instances, well-known methods, processes, components, circuits, and networks have not been described in detail so as not to unnecessarily obscure various aspects of the embodiments.

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

[0114] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit all embodiments. As used in this specification and the appended claims, the singular forms “a” and “described” are intended to also cover the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and covers any and all possible combinations of one or more of the items listed in connection with the invention. It should be further understood that the term “comprising” as used in this specification specifies the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0115] As used herein, depending on the context, the term "if" can be interpreted as meaning "when..." or "in response to determination" or "in response to detection". Similarly, depending on the context, the phrase "if it is determined..." or "if [the stated condition or event] is detected" can be interpreted as meaning "when it is determined..." or "in response to determination..." or "when [the stated condition or event] is detected" or "in response to detection".

[0116] Implementations of computing devices, user interfaces for such devices, and associated processes for using such devices are described. In some implementations, the computing device is a portable communication device, such as a mobile phone, that also includes other functions, such as PDA and / or music player functions. Exemplary implementations of portable multi-functional devices include, but are not limited to, the iPhone from Apple Computer, Inc. (Cupertino, California). ® iPad ® and iPod touch ® equipment.

[0117] Exemplary embodiments of this disclosure have been described in the foregoing description. It will be apparent that various modifications may be made thereto without departing from the broader spirit and scope of this disclosure. Accordingly, the specification and drawings are to be regarded as illustrative rather than limiting. Specific details in the descriptions and examples provided can be used anywhere in one or more embodiments. Various features of different embodiments or examples may be combined differently with some of the included features and others excluded features to suit a variety of different applications. Examples may include subjects such as methods, means for performing the actions of the method, at least one machine-readable medium including instructions that, when executed by a machine, cause the machine to perform the actions of the method, or the actions of an apparatus or system according to the embodiments and examples described herein. Additionally, the various components described herein may be means for performing the operations or functions described herein.

[0118] The embodiments described herein provide systems and methods for crowdsourcing the locations of wireless devices and accessories lacking wide area network connectivity. One embodiment provides a data processing system configured to perform operations including: launching a user interface on an electronic device that enables the determination of the location of a wireless accessory associated with the electronic device; generating a set of public keys included in a beacon signal broadcast by the wireless accessory during a first time period; sending the set of public keys to a server and requesting the return of data corresponding to one of the public keys; decrypting the location data using a private key associated with the public key; processing the location data to determine the possible location of the wireless accessory; and displaying the possible location of the wireless accessory via the user interface.

[0119] One embodiment provides a data processing system comprising: a memory for storing execution instructions; and one or more processors for executing the instructions stored in the memory. When executed, the instructions cause the one or more processors to initiate a user interface on an electronic device including the data processing system, the user interface enabling the determination of the location of a wireless accessory associated with the electronic device; generating a set of public keys included in a beacon signal broadcast by the wireless accessory, the beacon signal being broadcast during a first time period; sending the set of public keys to a server and requesting the return of data corresponding to one of the public keys; decrypting the location data using a private key associated with the public key in response to receiving location data from the server; processing the location data to determine the possible location of the wireless accessory; and displaying the possible location of the wireless accessory via the user interface.

[0120] One embodiment provides a method implemented on an electronic device, the method including performing a beacon scan using a baseband processor of the electronic device. The beacon scan can be performed when the application processor of the electronic device is in a low-power state. The method further includes receiving beacon data via a radio device coupled to the baseband processor, the beacon data being used to identify a wireless accessory. The beacon identifier can be a public key generated by the wireless accessory. The method further includes: storing a timestamp and the beacon identifier in a beacon scan buffer; determining the location of the electronic device corresponding to the timestamp when the application processor of the electronic device is active; encrypting the location of the electronic device using the beacon identifier for the wireless accessory; and transmitting the encrypted location data, the beacon identifier, and the timestamp to a server device, the server storing the encrypted location data for retrieval by electronic devices associated with the wireless accessory.

[0121] From the foregoing description, those skilled in the art will understand that the broad techniques of these embodiments can be implemented in many forms. Therefore, although these embodiments have been described with reference to specific examples, their true scope should not be so limited, as other modifications will become apparent to those skilled in the art upon review of the drawings, specification, and the following claims.

[0122] Cross-references

[0123] This patent application claims the benefit and priority of U.S. Provisional Application No. 62 / 738,983, filed on September 28, 2018, the entire contents of which are incorporated herein by reference.

Claims

1. A computer-implemented method, comprising: When the application processor of the electronic device is in a low-power state, the wireless processor of the electronic device is used to scan beacon advertisements; In response to the detection of the beacon advertisement via the wireless processor, the beacon advertisement and timestamp are stored in the beacon advertisement buffer; as well as The wireless processor is configured to process the advertisement based on status information contained in the beacon advertisement, wherein the status information indicates that the location of the device associated with the beacon advertisement will be determined.

2. The computer-implemented method according to claim 1 further includes: When the electronic device is active, the location of the electronic device is determined by the application processor.

3. The computer-implemented method according to claim 2 further includes: The beacon advertisement is associated with the stored location data of the electronic device to determine the location estimate of the device associated with the beacon advertisement.

4. A computer-implemented method, comprising: The owner device associated with the first account performs a key exchange with the accessory device to determine a set of encryption keys; A registration request is sent to the server to establish an association between an account set and the accessory device, wherein the association authorizes a first account associated with the owner device and a second account associated with the second device to access one or more locator services for the accessory device, wherein the account set includes the first account and the second account; as well as The set of encryption keys is sent to a key store to enable the second device associated with the second account to perform the one or more locator services for the accessory device.

5. The computer-implemented method of claim 4, wherein the one or more locator services include at least one of: accessing crowdsourced location lookup for the accessory device, or transmitting information between the device and the accessory device associated with an account from the set of accounts.

6. A computer-implemented method, comprising: The association between a first account and a second account is stored on the server, wherein the association authorizes the second account user to access the locator service for the accessory device, wherein the first account is registered with the accessory device through a request from the first device on the server; as well as A set of encryption keys is sent to a second device associated with the second account to enable the second device to perform the set of locator services for the accessory device.

7. A computer-implemented method, comprising: When the first electronic device is in a low-power state, the first electronic device scans the first beacon advertisement, wherein the first beacon advertisement is associated with the second electronic device; The first electronic device stores the first beacon advertisement as an entry in the first beacon advertisement buffer; The first electronic device is switched from the low-power state to the active state based at least in part on the entry; as well as When the first electronic device is in the active state, the first electronic device determines the location of the second electronic device by associating the first beacon advertisement with the stored location data.

8. The computer-implemented method of claim 7, wherein when the first beacon advertising buffer is filled with entries, the first electronic device transitions from the low-power state to the active state.

9. The computer-implemented method according to claim 7 further includes scanning the second beacon advertisement simultaneously with scanning the first beacon advertisement.

10. A computer-implemented method, comprising: The beacon advertisement is scanned by a first electronic device; The first electronic device determines, at least in part, whether the beacon advertisement is a first beacon signal associated with a first state or a second beacon signal associated with a second state based on the beacon advertisement. as well as In response to determining that the beacon advertisement is the first beacon signal associated with the first state, a key matching operation is performed on the beacon advertisement to determine whether the beacon advertisement is associated with a second electronic device.

11. The computer-implemented method according to claim 10, further comprising: Generate the first public and private keys; Exchange the first public key with the second electronic device; as well as The private key is stored in a storage device, wherein the key matching operation is associated with the private key.

12. The computer-implemented method of claim 10, wherein determining whether the beacon advertisement is a first beacon signal associated with a first state or a second beacon signal associated with a second state is based on the state of the second electronic device.

13. A computer-implemented method, comprising: A first electronic device sends a first key to a second electronic device, wherein the first electronic device is associated with a first account; In response to sending the first key, the first electronic device receives the second key from the second electronic device; The first electronic device sends a registration request to the server to form an association between the second electronic device and the first account and a second account associated with the third electronic device, wherein the association authorizes the first account associated with the first electronic device and the second account associated with the third electronic device to access one or more locator services for the second electronic device. as well as The first electronic device sends the first key and the second key to the storage device so that the third electronic device associated with the second account can perform the one or more locator services for the second electronic device.

14. The computer-implemented method of claim 13, wherein the third electronic device is capable of performing operations to generate a set of public keys, the set of public keys having an encryption key contained in a beacon signal broadcast by the second electronic device.

15. The computer-implemented method of claim 13, wherein the one or more locator services comprise at least one of the following: Access the crowdsourced location of the second electronic device; or Information is transmitted between the second electronic device and the third electronic device.

16. A computer-implemented method, comprising: The beacon signal is scanned by the first electronic device; The state of the second electronic device is determined by the first electronic device at least in part based on the beacon signal; The first electronic device delays displaying an indication of the location of the second electronic device for a period of time, based at least in part on the state of the second electronic device; as well as After the stated time period, the instruction is displayed by the user interface of the first electronic device.

17. The computer-implemented method of claim 16, wherein determining the state includes determining whether the first electronic device is within the response range of the second electronic device.

18. The computer-implemented method of claim 17, wherein delaying the display of the indication comprises delaying the display of the indication when the first electronic device is within the response range of the second electronic device.

19. A system comprising: Memory, including computer-executable instructions; as well as A processor is configured to access the memory and execute the computer-executable instructions to perform operations including a computer-implemented method according to any one of claims 1-18.

20. One or more non-transitory computer-readable media, comprising computer-executable instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform operations including a computer-implemented method according to any one of claims 1-18.

Images