pairing of accessory groups

Abstract

This disclosure relates to "pairing an accessory group." The invention describes embodiments involving pairing and finding a group of accessory devices. In one embodiment, a pairing status is received from a first accessory device; a request is sent to the first accessory device regarding the number of accessory devices in the device group and the number of accessory devices near the first accessory device in the device group; information regarding a second accessory device in the device group is received; if the second accessory device is near, a continue pairing message is sent to the second accessory device; and a device group profile is created using information regarding the number of such devices and the received information regarding the second accessory device.

Description

[0001] Cross-references

[0002] This application claims the benefit of priority to U.S. Provisional Application Serial No. 63 / 197,293, filed June 4, 2021, entitled “Pairing Groups of Accessories,” and U.S. Patent Application Serial No. 17 / 508,334, filed October 22, 2021, entitled “Pairing Groups of Accessories,” each of which is incorporated herein by reference. Technical Field

[0003] The implementation scheme described in this article involves pairing and locating a set of accessory devices. Background Technology

[0004] Previous device locator services provided services for individual devices and did not offer meaningful location services for a group of related devices. Therefore, it is necessary to provide location services for a group of related devices. Summary of the Invention

[0005] In one embodiment, a method for providing pairing with a device group includes: receiving a pairing status from a first accessory device in the device group; selectively pairing with the first accessory device based on the pairing status; sending a request to the first accessory device for information about accessory devices in the device group, including information about at least one accessory device that is near the first accessory device in the device group; receiving information about a second accessory device in the device group; selectively sending a continue pairing message to the second accessory device if the second accessory device is near; and creating a device group profile using the information about the accessory device in the device group and the received information about the second accessory device. In some embodiments, the method may include: sending a request to the first accessory device for status information, including the pairing status and an indication that the first accessory is part of the device group. In some embodiments, the method may provide: sending a request to the first accessory device for status information, the status information including verifiable information of the first accessory device; sending a verification request along with the received information regarding the first accessory device; and selectively performing pairing with the second accessory device if the device is not paired, wherein pairing includes accessing at least one key associated with the second accessory device and a user account. In some embodiments, the first accessory device is a wireless beacon peripheral device. In one embodiment, the method may provide: sending a verification request along with the received information regarding the second accessory device; and selectively sending a continue pairing message to the second accessory device based on a verification result received in response to the verification request. In some embodiments, the method may provide: sending a request to the first accessory device for information regarding the number of accessory devices in the device group and the number of accessory devices close to the first accessory device in the device group.

[0006] In one embodiment, a method for facilitating pairing with a group of devices includes: a first accessory device determining the proximity status of a second accessory device in the group of devices; sending the proximity status of the second accessory device in the group of devices to a host device; sending a handshake message to the second accessory device; receiving verifiable information from the second accessory device; and sending the verifiable information to the host device.

[0007] In one embodiment, a non-transitory machine-readable medium storing instructions instructing one or more processors of an electronic device to perform operations providing: receiving a pairing status from a first accessory device in a device group; selectively pairing with the first accessory device based on the pairing status; sending a request to the first accessory device for information about accessory devices in the device group, including information about at least one accessory device that is near the first accessory device in the device group; receiving information about a second accessory device in the device group; selectively sending a continue pairing message to the second accessory device if the second accessory device is near; and creating a device group profile using the information about the accessory device in the device group and the received information about the second accessory device.

[0008] In a data processing system, the data processing system includes: a memory for storing instructions for execution; one or more processors for executing the instructions stored in the memory, wherein the instructions, when executed, cause the one or more processors to: receive a pairing status from a first accessory device in a device group; selectively pair with the first accessory device based on the pairing status; send a request to the first accessory device for information about accessory devices in the device group, the information including information about at least one accessory device that is close to the first accessory device in the device group; receive information about a second accessory device in the device group; selectively send a continue pairing message to the second accessory device if the second accessory device is close; and create a device group profile using the information about the accessory device in the device group and the received information about the second accessory device. In one embodiment, a method for locating a group of devices includes: receiving an indication that a first accessory device is part of the group of devices, wherein the first accessory device has a physical connection with a second accessory device in the group of devices; receiving a beacon signal from the first accessory device in the group of devices, wherein the beacon signal includes status information about the second accessory device; and storing location data about the group of devices from the beacon signal. In some embodiments, multiple accessory devices in the group of devices are physically connected to a box. In some embodiments, RSSI information is determined based on the beacon signal, wherein the beacon signal includes an advertisement containing RSSI information. In some embodiments, the method includes: presenting location data about the group of devices in a user interface. In some embodiments, the method includes: requesting the storage of location data about the group of devices via a device locator service. In some embodiments, the method includes: generating at least one key for at least one accessory device in the group of devices; requesting the device locator service to send location data corresponding to the at least one key; and receiving and presenting location data about the group of devices.

[0009] In one embodiment, a method for locating a group of devices includes: receiving an indication that a first accessory device is part of the group of devices, wherein the first accessory device is wirelessly connected to a second accessory device in the group of devices; receiving a beacon signal from the first accessory device in the group of devices, wherein the beacon signal includes status information about the second accessory device; and storing location data about the group of devices from the beacon signal. In some embodiments, the method includes: presenting the location data about the group of devices in a user interface. In some embodiments, the method includes: requesting the storage of the location data about the group of devices via a device locator service.

[0010] In one embodiment, a method for presenting a user interface for finding a group of devices includes: receiving a request to launch an application; initiating a connection with at least one accessory device from the group of devices; presenting a user interface having a status of the at least one device from the group of devices; upon receiving an indication that the at least one device from the group of devices has connected to another device from the group of devices; presenting selectable elements having a query about whether to continue searching for devices from the group of devices; and presenting the status of other devices based on the response to the query. Attached Figure Description

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

[0012] Figure 2 A system for locating wireless accessories according to an implementation scheme is shown.

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

[0014] Figure 4 This is a flowchart illustrating a method for pairing a set of accessory devices according to an embodiment of this document.

[0015] Figure 5 This is a flowchart illustrating a method for use with the device locator system described herein.

[0016] Figure 6 This is a flowchart illustrating a method for pairing a set of accessory devices according to an embodiment of this document.

[0017] Figure 7 This is a sequence diagram illustrating a method for presenting a device locator user interface used in conjunction with the device locator system described herein.

[0018] Figure 8This is a flowchart illustrating a method for presenting a device locator user interface for use with the device locator system described herein.

[0019] Figure 9A -D is a flowchart illustrating the method for locating accessory devices in a device group.

[0020] Figure 10 A method for determining the location of a wireless accessory via a device locator server is shown.

[0021] Figure 11 An additional method for determining the location of a wireless accessory via a device locator server is shown.

[0022] Figure 12 This is a flowchart illustrating a method for broadcasting a signal beacon at a wireless accessory according to an implementation scheme.

[0023] Figures 13 to 14 The operation of a method that can be performed by a detector device according to the embodiment described herein is illustrated.

[0024] Figure 15 The acquisition of signal and ranging data performed by the detector device according to the implementation scheme is shown.

[0025] Figures 16 to 21 The device locator user interface according to the implementation scheme is shown.

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

[0027] Figure 23 It is a block diagram of a device architecture for mobile or embedded devices according to the implementation plan.

[0028] Figure 24 It is a block diagram of the computing system according to the implementation plan.

[0029] Figure 25 This is a flowchart illustrating a method for playing sound when an accessory device or group of devices is lost according to a request in an implementation scheme.

[0030] Figures 26 to 28 This is a sequence diagram illustrating a method for requesting one or more lost accessory devices from a device group to play sound according to an embodiment described herein. Detailed Implementation

[0031] The embodiments described herein provide techniques for pairing a group of accessory devices to establish a device group and locator service for locating lost or misplaced accessory devices within the device group. A device group is a set of accessory devices (e.g., a pair of earbuds, such as Apple...). Each of these devices can be independently and separately verified and paired with another device. The association of accessory devices within a device group allows the accessory devices to access information to facilitate pairing with other accessory devices within the device group and to locate accessories within the device group. Various embodiments are described with reference to the accompanying drawings. However, certain embodiments may be practiced without one or more of these specific details or in combination with other known methods and constructions. In the following description, numerous specific details such as particular configurations, dimensions, and processes are shown to provide a thorough understanding of the embodiments. In other instances, well-known semiconductor processes and manufacturing techniques are not described in particular detail to avoid unnecessarily obscuring the embodiments. The phrase "an embodiment" as used throughout the specification means that a particular feature, structure, construction, or characteristic described in connection with an embodiment is included in at least one embodiment. Therefore, the phrase "in an embodiment" appearing multiple times throughout the specification does not necessarily refer to the same embodiment. Furthermore, a particular feature, structure, construction, or characteristic can be combined in any suitable manner in one or more embodiments.

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

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

[0034] Figure 1 This 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 accessory devices 101A and 101B (collectively referred to as 101) and mobile device 102. In one embodiment, mobile devices 101A and 101B may be accessory devices that can be paired into a device group 105. Optionally, the device group having accessory device 101 can be stored in the mobile device via a wired connection, such as a box 103 for holding accessory device 101. In some embodiments, box 103 may also be an accessory device that can be paired with mobile device 102. For example, accessory device 101 may be such as Apple and / or The device. In some embodiments, accessory device 101 may not be able to communicate over a wide area network. In other embodiments, mobile devices 101 and 102 may each be any electronic device capable of communicating with wireless networks and wireless accessory devices. Some exemplary mobile devices 101 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, EarPods, etc. Locator tags, earphones, head-mounted displays, health equipment, speakers, and other similar devices. Each of mobile devices 101 and 102 may optionally include a user interface, such as user interface 104 for mobile device 102. In other embodiments, mobile device 101, as an accessory device, may not have a user interface. Mobile devices 101 and 102 may be third-party devices that utilize application programming interfaces to access device locator services. Third-party devices may be provided by different device manufacturers or be part of different ecosystems (e.g., operating systems) of mobile devices 101 and 102. Mobile devices 101 and 102 may 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) may 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, may provide communication access to wide area network 114. Gateway 116 and access device 118 may then communicate with wide area network 114 via a combination of wired and / or wireless networks.

[0035] In some implementations, both voice and data communications can be established via wireless network 112 and / or access device 118. For example, mobile device 102 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 102 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 101 and / or mobile device 102 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 101 or mobile device 102 may be referred to as a “tethered” device. In one implementation, mobile device 101 can communicate with mobile device 102 via wireless peering connection 120. Wireless peering connection 120 can be used to synchronize data between devices.

[0036] Mobile device 101 or mobile device 102 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 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 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 101 and 102 to store documents and media files. Device locator service 170 enables users to locate lost or misplaced devices that are connected to one or more wired and / or wireless networks 110 at least at some point. Other services may also be provided, including software update services for updating operating system software or client software on mobile devices. In one embodiment, instant 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 101 and 102.

[0037] In some implementations, accessory device 101A, accessory device 101B, mobile device 102, box 103, and / or device group 105 may register with certificate authority 106. In some implementations, certificate authority 106 is the entity that issues digital certificates, and the service may be implemented using a set of servers managed by the device manufacturer, service provider, or registration service. Certificates provided by certificate authority 106 can verify the validity of received verifiable information about the device, such as the device's specific manufacturer, serial number, device group identifier or other identifier, indication that the device is part of device group 105, and / or any other verifiable information. In some implementations, the device manufacturer may create device group 105 by grouping the serial numbers of accessory devices within device group 105. In other implementations, the certificate may be encrypted by device 101, 102, or 103 before being sent to a third party, and may be decrypted at a verification service (e.g., a certificate authority or another verification service) when a third party requests verification of information provided by devices within accessory device 101, mobile device 102, box 103, and / or device group 105. In some implementations, the security token may be provided by the accessory device 101 in the pairing request. Additional examples of pairing devices using location services can be found in U.S. Patent Application No. 17 / 219,595, filed March 21, 2021, entitled "Secure Pairing and Pairing Lock for Accessory Devices," the entire contents of which are incorporated herein by reference.

[0038] Mobile devices 101 and 102 may have locally accessible applications, services, and functions on the device, including location service 180. Mobile device 102 may have a device locator application (e.g., a "Find My" application) 190 to utilize device locator service 170 and location service 180 to locate the attached device 101. Locally accessible data may be stored on known location 182 and secure or trusted location 184. In some cases, machine learning algorithm 186 may be used to identify known location 182 and / or trusted location 184. While cluster analysis is provided as an example of a machine learning algorithm that can be used, those skilled in the art will recognize that other algorithms may be used to identify potential known or trusted locations. For example, cluster data analysis may be used to identify and classify locations and provide semantic labels for locations, such as locations frequently visited by users. Secure or trusted location 184 may be explicitly specified or confirmed by the users of devices 102A-B after data analysis. In other cases, known location 182 or trusted location 184 may be classified offline and provided by device locator service 170 or a third party (e.g., a database with map information).

[0039] On-device heuristics and / or machine learning models can be used to infer relationships between users and locations based on analysis of locally stored data on frequently visited locations, including locations frequently visited by the user, known locations, and / or any other locations. For example, frequently visited locations include homes, vehicles, workplaces, any location frequently visited by users with mobile devices (e.g., accessory devices 101 and mobile device 102), and / or any other location designated by the user as a trusted location 184. Known location 182 can be a commercial location, a public space, a park, a museum, and / or any other location the user might frequently visit. Boundary information for the corresponding stored location can be stored along with the location's classification type and any semantic labels assigned to the location. The stored information may include a defined set of boundaries or radii around the point location to allow the creation of a geofence for that location. A geofence is a virtual perimeter of a real-world geographic area. The Global Positioning System (GPS) can be used to create virtual fences around the location and track the physical location of mobile devices 101 and 102 within the geofence boundaries, as well as entry and exit from the bounded area.

[0040] Machine learning algorithm 186 may include on-device heuristics, machine learning algorithms, or combinations thereof to analyze and assign tags regarding the movement or travel of the device, which is designated as being in a "on-the-go" or "stable" state at a specific location for a certain period of time. The analysis can be performed using various signals from data sources available to mobile device 102, including but not limited to: sensor data, location data, calendar data, transit card usage data, application data, historical data about travel patterns / routines, and / or any other data accessible to mobile device 102. In some embodiments, mobile device 102 may be classified as "stable" semantically after remaining within the geographic boundaries of a defined location (e.g., trusted location 184) for a defined period of time. In the simplest case, location data of mobile device 102 may remain within the boundaries of a geofence at a specific location for a certain period of time (e.g., 5 minutes). Sensor data (such as accelerometer data) may indicate that mobile device 102 is stationary to support the inference of stabilization. Application data may support the inference of stabilization of mobile device 102, such as the mobile device being located at a calendar-approved location. Application data indicating the type of application in use can also provide inferences about the device being stabilized, such as the use of a media application. Historical data about a user's routines or patterns of movement can be used to determine whether mobile device 102 is being stabilized, such as a bedtime routine at home or a hotel location. Mobile device 102 can be categorized with a "on the way" label based on the user's previous behavior, patterns, or routines, and analyzed on mobile device 102. For example, a user may have a routine of working around the same time every day, and if data on the device supports repeating this pattern, the "on the way" status can be assigned. In the simplest case, the speed at which the mobile device moves or enters and exits a known geographic area (e.g., using a geofence) can allow inferences that mobile device 102 is on the way. If mobile device 102 is detected accelerating in a known transportation area (e.g., on a road, highway, train route, etc.), mobile device 102 can be given the "on the way" status. Similarly, if a transportation application / card is being used / used, mobile device 102 can be designated as "on the way".

[0041] Figure 2A system 200 for locating wireless accessories 201A and / or 201B according to an embodiment is shown. In one embodiment, wireless accessories 201A and 201B (collectively referred to as 201) are another embodiment of accessory devices 101A and 101B (and optional box 103), which can be paired as part of device group 105 and are interchangeable throughout the specification. Each wireless accessory includes one or more wireless transceivers and can communicate directly or indirectly (e.g., via another device or computer) with an accompanying device (e.g., mobile device 102) via a wireless network or peer-to-peer communication link. Accessory device 101A is shown as being located in box 103 and can provide beacon signals for box 103 and any accessories in box 103. Accessory device 101B is separate from box 103 and can be located independently and separately by providing beacon signals. Examples of additional wireless accessory devices 101 include, but are not limited to, wireless earbuds, EarPods, AirPods, input devices, charging devices, accessory cases, headphones, headband headphones, fitness equipment, health equipment, display devices, external hard drives, other wearable device (e.g., smartwatches, fitness trackers, optical head-mounted displays) adapters, speakers, and / or other devices. Paired accessory groups can be of the same type of device (e.g., speakers, AirPods, fitness weights, etc.) or different types of devices (e.g., smartphones and credit card readers, etc.). Wireless accessory 201 may also include other wireless devices, such as input devices, including but not limited to credit card readers, stylus devices, mice, keyboards, game controllers, or remote controls. In one embodiment, wireless accessory 201 also includes devices that at least temporarily cannot access a wide area network such as the Internet (e.g., [missing information - likely a network name]). Figure 1 The wide area network 114 shown includes smartphones, tablets, laptops, smart speaker devices, televisions, or set-top boxes. Wireless accessory 201 can also be any other wireless device, including beacons or locator tags that can be attached to other devices to allow tracking or locating those devices. In one embodiment, wireless accessory 201 may be from a group of accessory devices that pair with mobile device 102 using wireless technology standards such as, but not limited to, Bluetooth. Wireless accessory 201 can also communicate with mobile device 102 via wireless technologies, including specific implementations of any wireless standards and protocols such as Wi-Fi Direct, Zigbee, or AirPlay. Although the companion device to which wireless accessory 201 is paired is generally referred to as mobile device 102, the companion device is not limited to mobile devices. In some embodiments, the companion device may also include laptops or desktop devices, and may also include wearable accessories such as, but not limited to, smartwatches or wearable displays.

[0042] In one embodiment, wireless accessory 201 may periodically transmit a wireless beacon signal. Wireless accessory 201 may use 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 to transmit the beacon. 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 individual wireless accessory 201A or 201B and / or device group 105. In one embodiment, the beacon identifier is a public encryption key associated with the device.

[0043] The beacon signal may also transmit information about the wireless accessory 201, such as device status information and / or verifiable information. Device status information in the beacon signal may include, but is not limited to, the following: beacon type, device classification, battery level, any predefined device status, device status, lost status, alarm status, separated from owner status, near owner status, near owner status, near one or more accessory devices 101 in the device group, wired or wireless connection status, physically connected to one or more accessory devices 101 in the device group, pairing status indicating whether the accessory device is paired, pending pairing status, battery life status, charging status, and / or any other status information. A lost or "separated from owner" status may indicate that the wireless accessory 201 has determined that it is 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.

[0044] In some implementations, verifiable information may include any information that may be needed to establish trust or authorization, i.e., the pairing and / or search process can proceed, where the device presents verifiable information. For example, verifiable information may include information established by the device manufacturer, such as a serial number or set of serial numbers in device group 105. In some implementations, verifiable information may include device status or condition information. Verifiable information may include, but is not limited to, the following: device type, member of the device group, serial number, device group, serial numbers of other devices within the device group, status or condition information, software version, and / or any other verifiable information. Verifiable information may be sent to a Certificate Authority 106 or other verification service to verify the information presented by the device to another device. Verifiable information may be encrypted and / or sent with a token to allow further verification of the device.

[0045] In some implementations, the beacon signal can be detected by a detector device 202 locally proximate to wireless accessory 201A or 201B to enable crowdsourcing for locating the lost wireless accessory 201. The detector device 202 can be a device similar to mobile device 102 and can receive and transmit data over a wide area network 114, using wireless technologies similar to those used with wireless accessory 201 (e.g., Bluetooth). Specifically, the detector device 202 can use a wireless protocol to receive data, through which the beacon signal is transmitted. The detector device 202 can use 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 using RF signals received from a cellular tower transmitter such as a Wi-Fi access point or a cellular telephone network from wireless base station 205. In one implementation, 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 indicating that location was determined. When detector device 202 receives a beacon signal from wireless accessory 201, detector device 202 can transmit its location to device locator server 203 via wide area network 114. The timestamp used to determine the location of detector device 202 can be associated with the timestamp of receiving the beacon signal to associate the geographic location with the received beacon signal.

[0046] 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 can be encrypted and transmitted along with the location data, or transmitted to the device locator server 203 unencrypted. For example, the received signal strength indication (RSSI) of the beacon signal can be transmitted along with the location data. The RSSI data can then be used to determine the distance between the wireless accessory 201 and the detector device 202 and can aid in triangulation on the owner device. In the case where the RSSI data is transmitted unencrypted, in one embodiment, the server can use the RSSI information to reduce noise by discarding very weak signals if other stronger signals are present. In one embodiment, UWB ranging data may also be provided, where such data is available.

[0047] In one implementation, the detector device 202 may behave differently 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.

[0048] 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 use an associated private key to decrypt the encrypted location data. 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 from multiple receiving locations and by using other data, such as beacon signal RSSI associated with each location and timestamp or UWB ranging data included in the location data.

[0049] 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 (e.g., examples of devices 101A, 101B, or 103) 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 201, a public key exchange (310) may be performed between the mobile device and the wireless accessory 201. In one embodiment, during the public key exchange (310), the mobile device 102 and the wireless accessory 201 exchange the public key in the public key pair generated by the device and the accessory 201. 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 concurrently, 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 implementation, the public key exchange (310) further utilizes elliptic curve cryptography to establish a 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 can be used by the wireless accessory 201 to periodically derive additional public keys.

[0050] 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. The values ​​K and M may vary between embodiments. 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.

[0051] In one implementation, the value M is 15 minutes, such that a new K-byte key is generated every 15 minutes. The public key can be derived qualitatively based on a timestamp and an 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, thereby preventing a specific key from being associated with a specific device for an extended period. The key can be derived based on an anti-tracking secret known only to mobile device 102 and wireless accessory 201, thereby 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 can be generated along with the ECDH public key 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 P. i In one implementation, the public key sequence P i =λ i P is defined as a scalar or exponential value λ. i Group operations between group elements, such as an elliptic curve point P. A scalar or exponential value λ = KDF(AT,i), where KDF is the key-derived function, AT is the anti-tracking secret, and i is a counter or timestamp.

[0052] 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 λ. i+1 =H(λ) i ||Time), where λ0=AT and H are cryptographic hash functions. Wireless accessory 201 then stores λ i For a given time period i, if wireless accessory 201 is compromised, only the current and future values ​​of λ used for i are exposed. i And without exposing the anti-tracking secret AT. In one implementation, anti-tracking resistance is achieved by periodically sending λ i The process is executed by writing to the non-volatile memory of the wireless accessory 201.

[0053] In one implementation, the wireless accessory 201 may transmit the beacon signal 301 every two seconds, but other beacon rates may be used, and these beacon rates may vary under certain conditions. For example, when in a near-owner state, the wireless accessory 201 may reduce the beacon rate. The beacon rate may also vary 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.

[0054] 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 at which a new public key is generated may also be reduced when the wireless accessory is in a near-owner state.

[0055] Wireless accessory 201 may enter an alarm state upon receiving a message from mobile device 102 instructing it to do so. While in an alarm state, the wireless accessory may initially enter a standby state in which it reduces or stops transmitting 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.

[0056] The beacon signal 301 transmitted by the wireless accessory 201 can be detected by a set of detector devices 303 (which may be detector device 202) and / or mobile devices 102. These detector devices and / or mobile devices are other electronic devices 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, the set of detector devices 303 includes a variant of the mobile device 102, or may be other types of electronic devices. For example, the set of detector devices 303 may perform an operation (320) to associate the beacon signal 301 received from the wireless accessory 201 with the device location associated with the detector device 303. (See also...) Figure 2 The device location can be determined via satellite positioning services or 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 group of detector devices 303 may also include a fixed device, such as a smart speaker device, a television, or a television set-top box, capable of receiving beacon signals 301.

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

[0058] 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 may be stored in the database nodes based on the hash of the beacon identifier. The encrypted location data may be indexed by the device locator server 203 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 an encrypted or unencrypted state. This other information may include a timestamp of when the beacon signal 301 was received, the RSSI information of the received beacon, and / or ranging information, such as that determined via UWB ranging.

[0059] 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 locator application 190 or features 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 when mobile device 102 wishes to receive location data. In one embodiment, this set of public keys is a public key sequence P generated based on an anti-tracking secret. i Public key sequence P i The matching sequence d with the private key i Correspondingly, mobile device 102 can generate a public key sequence and the corresponding public key sequence d. i , 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.

[0060] 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 location service data providers from storing data that could be used to bind encrypted location data to a specific device and thus to 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 may use the hash of the public key, determined for a specific query period, to query the device locator server 203.

[0061] 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 to the electronic device to enable decryption of the location data. In one implementation, the decryption key for the location data may be sent to a server that provides a web-based interface so that the server can decrypt the location data, at least when the location data 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 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.

[0062] In one implementation, the wireless accessory 201 can be placed in a light-loss mode. In light-loss 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 light-loss 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 light-loss mode. A similar mechanism can also be used to relay messages to the wireless accessory 201 that puts it in explicit loss mode. The user can enable explicit loss mode via the device locator UI 204. In explicit loss mode, the wireless accessory 201 cannot pair with another device unless it is unlocked by its owner. Additional examples of paired devices using location services can be found in U.S. Patent Application No. 16 / 543,227, filed August 16, 2019, entitled “A System and Method for Locating Wireless Accessories,” the entire contents of which are incorporated herein by reference.

[0063] Figure 4This is a flowchart 400 illustrating a method for pairing a group of accessory devices according to an embodiment of this document. Mobile device 102 may receive a pairing status (402) from first accessory device 101A indicating whether the first accessory device 101A is paired. Pairing exists between devices when mobile device 102 can access at least one key associated with the first accessory device of a user account (e.g., a cloud-based account) of mobile device 102. Pairing status, status information, and / or verifiable information indicating whether the first accessory device 101A is currently paired, pending pairing, or unpaired may be provided in a beacon signal.

[0064] If, based on the pairing status, the first accessory device 101A and the mobile device 102 are not currently paired, the pairing process can selectively begin (404), such as... Figure 5 As shown. In some implementations, the pairing status may indicate that pairing is pending for the first accessory device 101A, and the device group profile of device group 105 can be retrieved from the database of device locator server 203. The device group profile may be part of the data model of the device group, containing location data crowdsourced for device locator service 170. The device group profile may be stored on mobile device 102 and synchronized between devices linked to a cloud-based account. Additionally, the device group profile may be stored in databases on mobile device 102 and device locator server 203. For example, the device group profile may record relationships between accessory devices, status information, and verifiable information received from accessory devices and / or device manufacturers. The device group profile can be updated using information received from accessory device 101 via mobile device. The device group profile may include, but is not limited to, the following information: the number of accessory devices in the device group, the number of paired devices, the serial number of the accessory devices in the device group, the pairing status of the accessory devices, and any other information used to provide device location service 170. Therefore, any status and / or verifiable information previously stored in the device group profile can be compared with the status and / or verifiable information received from devices in device group 105 and stored in the device profile of device group 105. In some embodiments, the pairing process can be stopped if there is a mismatch between the information received from the first accessory device 101A and the device profile, and / or if the verifiable information received from the first accessory device 101A cannot be verified. Each member device or accessory device 101 that is part of device group 105 can be a beacon peripheral device, which can be individually identified to allow the locating and verification of all accessory devices 101 in device group 105.

[0065] The first accessory device 101A can provide verifiable information from a beacon signal, which can be verified by a certificate authority or other authentication service. Specifically, the first accessory device 101A has a serial number consistent with that of devices from device group 105, as expected by the device manufacturer or user-defined device group. Furthermore, a certificate authority or other authentication service can use the verifiable information to authenticate the first accessory device 101A with a specific device manufacturer. Those skilled in the art will recognize that there are various ways to verify the information provided by the first accessory device, and this verification can be performed before proceeding with the pairing process to confirm that the first accessory device is trustworthy.

[0066] Alternatively, the pairing process cannot proceed if the first accessory device 101A does not provide verifiable information. An implementation may request the first accessory device 101A to provide verifiable information (e.g., cryptographically verifiable information, such as certificates and / or tokens) to initiate pairing. This verifiable information includes, but is not limited to, the following: serial number, manufacturer identifier, software version, indication that the accessory device is part of a device group, expected accessory device identifiers of other accessory devices in the device group, expected number of accessory devices in the device group, and / or any other information. In one implementation, the verifiable information may be cryptographically verified and authenticated by a certificate authority 106.

[0067] A request (406) for information about accessory devices in a device group can be sent to the first accessory device 101A. For example, the requested information may include an indication that accessory device 101A is part of a multipart device group or device group 105, the number of devices in device group 105, and the number of devices near the first accessory device 101A in the device group (406). The received accessory device information about device group 105 may be stored in a device group profile and referenced by mobile device 102 for use in the pairing process.

[0068] Information about a second accessory device 101B in device group 105 can be received (408). Information about the second accessory device 101B received from the first accessory device 101A can assist in further pairing of the remaining unpaired accessory devices in device group 105. In one embodiment, if the second accessory device 101B approaches the first accessory device 101A, the first accessory device 101A can send verifiable information about the second accessory device 101B. If the second accessory device approaches (410), a pairing message can be sent to the second accessory device to attempt pairing with the second accessory device 101B. If the second accessory device does not approach and / or pairing is unsuccessful, the verifiable information of the second accessory device can be stored in the corresponding device group profile. The information about the second accessory device 101B can be stored in the device group profile for access by the mobile device 102 for later attempts to pair with the second accessory device 101B, and the pairing status of the second accessory device can be set to "pairing pending". Alternatively, if the received information from the second accessory device 101B is consistent with the verifiable information from the first accessory device 101A, the pairing process can be initiated. Figure 5 The pairing process continues with the second accessory device 101B. For ease of description, only the pairing of two accessory devices is described; those skilled in the art will recognize that pairing can continue for any number of accessory devices as they provide verifiable information to the mobile device 102.

[0069] Information about the partial quantity of device group 105, reception information about the second accessory device, and any other status information and / or verifiable information can be stored (412). If a device profile for device group 105 does not exist, a device profile for device group 105 can be created. The device profile can be updated to store information about device group 105 received from accessory device 101 and / or mobile device 102. Information that can be stored in the device profile includes, but is not limited to, the following: verifiable information received on devices in device group 105, the last received beacon signal (e.g., status, advertisement, proximity information, location data, etc.) received from any device within device group 105, and any other information for pairing and / or using devices in device group 105. Optionally, for the first and / or second accessory device 101, pairing can continue with respect to other nearby devices (414). The next device to be paired can be considered the first accessory device, and the process can continue (402).

[0070] Figure 5 This is a flowchart illustrating a method for use with the device locator system described herein. Figure 5 A method 500 for pairing a mobile device with a wireless accessory is shown. Aspects of method 500 are also described in... Figure 2 and Figure 3As shown above, the following description of operations relates to mobile device 102, wireless accessory 201, and device locator server 203.

[0071] like Figure 5 As shown, method 500 includes performing an initial pairing operation with a wireless accessory (502). 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 wirelessly exchanged data to have at least a first encryption layer.

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

[0073] 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 (508). In one embodiment, 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 (510). 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. In some embodiments, the mobile device can register the wireless accessory and device group 105. Information stored in the device group profile of device group 105 can also be synchronized between devices bound to a cloud service account (e.g., a user account). The device management server can be synchronized with other cloud-based servers (such as... Figure 2 and Figure 3 The device locator server 203 is associated with this other cloud-based server, which facilitates cloud-based services accessible to mobile devices.

[0074] Figure 6This is a flowchart 600 illustrating a method for pairing a group of accessory devices according to an embodiment of the present document. A first accessory device 101A may send a status regarding its pairing status with a host device (e.g., mobile device 102) and verifiable information about the first accessory device 101A to a host mobile device 102. If the first accessory device 101A is not paired with the host mobile device 102, selective execution may be performed based on the determination of the mobile device 102. Figure 5 The pairing process in, such as Figure 4 As described. The first accessory device 101A can determine the proximity status (602) of the second accessory device 101A in the device group 105 and send the status to the host mobile device 102 (604). For example, if the devices are in the same box 103, if the devices are wirelessly connected, and / or if the first accessory device 101A can detect or receive beacon signals from the second accessory device 101B, then the first accessory device 101A can approach the second accessory device 101B.

[0075] Next, a handshake message is sent to the second accessory device 101B (606). The handshake message is used to establish communication between the accessory devices 101. In response to the message, the first accessory device 101A can receive verifiable information from the second accessory device 101B (608). The verifiable information can be sent to the host mobile device 102, and this verifiable information can be stored in a profile and used for pairing with the second accessory device 101B (610).

[0076] Figure 7 This is a sequence diagram 700 illustrating a method for presenting a device locator user interface for use with the device locator system described herein. Accessory devices 101 of device group 105 can be located individually and independently during the search process. When accessory devices 101 of the device group are physically connected, at least one accessory device 101A from the device group, physically connected to another accessory device 101B, can provide a beacon signal to locate device group 101. For example, the beacon signal of a single AirPod 101A can be used to locate all AirPods in case 103.

[0077] In one implementation, accessory device 101 may be within range of a wireless connection (e.g., Bluetooth connection), but may not be currently connected. Accessory devices 101 may be connected together or connected to different locations within a given area, such as a first accessory device 101A in a bedroom and a second accessory device 101B in a garage. Mobile device 102 may initiate device locator application 204 (706). Device locator application 204 may request a warm-up connection (708) with at least one accessory device in device group 105. For example, device locator application 204 may cause mobile device 102 to warm up the connection by initiating or attempting to establish a wireless connection with accessory devices 101A and / or 101B in device group 105. In some implementations, there is a delay period, such as six seconds, before establishing a wireless connection. In some implementations, whether attempting to establish a wireless connection in parallel or sequentially, device locator application 204 may request information about the last known location of accessory device 101 from device locator service 170.

[0078] Mobile device 102 may establish a connection with accessory device 101A, or mobile device 102 may request the last known location of accessory device 101A determined based on previously received advertisements. After the user locates accessory device 101A (710), a connection is established between device 102 and accessory device 101A (712). In some embodiments, if the user places accessory device 101A in box 103, accessory device 101A and / or box 103 may detect a physical connection to accessory device 101A and communicate that accessory device 101A was recently placed in box 103. In response to the detection that accessory device 101A is placed in box 103, the search process may continue to search for the next accessory device 101B. User interface 204 (714) may be presented with information about the location of the searched accessory device 101A (716). Selectable user interface elements may be presented along with a user interface that asks the user whether to continue searching for accessory devices in group 105 (718), and the search experience may continue for the next accessory device 101B if it needs to be located (as determined by the user via the selectable user interface element). If the user selects to continue the search by selecting a selectable user interface element, mobile device 102 may connect to at least one accessory device 101B that needs to be searched (720). A user interface 204 (722) with location information received in a beacon signal may be presented to guide the user in searching for the remaining accessory devices (e.g., 101B) until accessory device 101B is found (724). User interface 204 may present the found accessory device (726).

[0079] Figure 8This is a flowchart illustrating a method for presenting a device locator user interface for use with the device locator system described herein. A request to launch the application can be received (802). A connection to at least one accessory device from a group of devices can be warmed up (804). In some embodiments, previously received beacon signals can indicate status information, such as whether the accessory devices in the device group are separated or together when attempting to connect. A user interface with information about the status of at least one device from the device group can be presented (806). Upon receiving an indication that at least one device from the device group is connected to another device from that group, selectable elements with queries about whether to continue searching for devices from that group can be presented (808). In some embodiments, an indication that at least one device is physically connected to box 103 is a good indicator that other devices can also be found. The status of other devices can be presented based on the response to the query (810). For example, if a selectable element is selected to continue searching for devices from device group 105, the mobile device can begin the search experience for locating the second accessory device 101B.

[0080] Figure 9A This is a flowchart 900 illustrating a method for locating accessory devices 101 in device group 105. In some embodiments, a search technique may be performed to provide a search experience for accessory devices in device group 105, which may be performed by an owner mobile device 102 paired with at least one accessory device in device group 105. The search technique may also be performed by mobile device 102 acting as a detector device 202 to crowdsource location data of device group 105. Optionally, if mobile device 102 receives a request from the owner of device group 105 to locate accessory devices 101 in device group 105, mobile device 102 may display the status of accessory devices 101 in device group 105 (902). For example, user interface 204 may provide location information for each of the accessory devices 101 in device group 105. Beacon signals received by mobile device 102 from first accessory device 101A may indicate the status of other accessory devices 101 in device group 105, including but not limited to: whether the accessory device is near mobile device and / or another accessory device in device group 105 and is wired and / or wirelessly connected to another device. The status information of the accessory devices provided in the received beacon signal can determine the method used to locate the accessory devices within device group 105. Although a description of the search is provided for a pair of devices, those skilled in the art will recognize that a similar method can be used with respect to any number of devices in device group 105 having any number of accessory devices.

[0081] The accessory device 101A can receive an indication that it is part of device group 105 (904). Mobile device 102 can receive the indication from the beacon signal from accessory device 101A. In some embodiments, the beacon signal can be any type of advertisement sent by accessory device 101A, including advertisements sent to establish a connection with mobile device 102 and / or prior to establishing a connection with that mobile device. The status information provided in the beacon signal can indicate whether the devices are physically separated (906). If the accessory devices are not physically separated (906), the beacon signal from at least one accessory device in the device group can provide location information from a second accessory device in the device group (910). For example, if accessory device 101 is in a box and has a wired connection to box 103, the beacon signal received from accessory device 101A can provide location data, such as RSSI data (e.g., measurements determined based on the beacon signal), to help locate accessory device 101 in the device group. The beacon signal can provide status information and / or verifiable information about the coupled accessory device 101B, such as the accessory device 101B serial number, pairing status, etc. RSSI data determined from the beacon signal from accessory device 101A can be attributed to accessory device 101B because device 101 is located in box 103.

[0082] continue Figure 9A If at least one accessory device in device group 105 is physically separated (906), it is determined whether accessory device 101 is wirelessly connected (908). If the first accessory device 101A and the second accessory device 101B are wirelessly connected (908), a beacon signal from the first accessory device in the device group can provide location information of the device group (910). For example, if accessory device 101 has a wireless connection, a beacon signal received from the first accessory device 101A can provide location data, such as RSSI data determined based on the beacon signal, to help locate accessory device 101 in the device group. Although exemplary embodiments have been described for device groups with two accessory devices, those skilled in the art will recognize that any number of accessory devices can be connected and / or disconnected from a given accessory device, and a beacon signal from a given accessory device can represent any number of accessory devices in the device group connected to that accessory device. In one embodiment, a set of bits in the beacon signal received from a given accessory device can be specified to indicate which devices are connected to and / or disconnected from the accessory device. The beacon signal can provide status information about the coupled accessory device 101B, such as the serial number of the first accessory device 101B, its pairing status, and whether the second accessory device 101B is close to the first accessory device 101A. RSSI data determined based on the beacon signal from the accessory device 101A (e.g., a measurement determined by the mobile device when receiving a Bluetooth advertisement) can be attributed to the accessory device 101B as device 101.

[0083] Alternatively, if the accessory device is not wirelessly connected (908), beacon signals from the first accessory device 101A and the second accessory device 101B are used to locate device 101 (912). For example, the beacon signal received from the first accessory device 101A can provide location data, such as RSSI data determined based on advertising, to help locate accessory device 101 in device group 105. The beacon signal can provide the last known state information about the coupled accessory device 101B, such as the serial number of the first accessory device 101B, its pairing status, and whether the second accessory device 101B is currently or previously near the first accessory device 101A. If any other device to be located exists in the device group (914), the process continues (902).

[0084] Alternatively, RSSI data can be used to present the status of the devices, such as the latest location information (916). Location data of the accessory device 101 can also be stored in a profile for each device and / or for a group of devices (916). The location data can be stored for use with, for example, […]. Figures 16 to 21 The search user interface 204 shown is used together and / or stored together with the locator service 170.

[0085] Figure 9B This is a flowchart 920 illustrating a method for locating accessory device 101 in device group 105. In one embodiment, the owner uses a detector mobile device 102 to request a search experience via user interface 204, thereby locating device group 105 for AirPod accessory device 101 with AirPod case 103. In another embodiment, detector mobile device 102 may perform a search method to provide location data of AirPod accessory device 101 with AirPod case 103 to device locator service 170 for crowdsourcing location data. An indication (921) that a first accessory device is part of device group 105 may be received by the mobile device. Status and / or verifiable information provided in a beacon signal may indicate that the first accessory device 101A is part of device group 105. In some embodiments, the indication that the first accessory device 101A is part of device group 105 may be verified by a certificate authority or verification service.

[0086] Status information received in the beacon signal from the first accessory device 101A can indicate that the first accessory device 101A (e.g., the right or left AirPod) has a physical connection with the second accessory device 101B (e.g., the remaining AirPod) in device group 105 (922). For example, AirPods 101 may be stored in case 103 and physically coupled. In some embodiments, the primary AirPod 101A providing the beacon signal is the last AirPod 101A placed in case 103, and the beacon signal may include advertisements, status information (including proximity information about the second accessory device 101B), and RSSI data.

[0087] The mobile device 102 can receive a beacon signal (923) from a first accessory device 101A in device group 105. The beacon signal includes status information (924) about a second accessory device 101B and location data (924) about device group 105 from the beacon signal. The location data can be displayed on AirPods 101 using user interface 204 and / or stored in a location server.

[0088] Figure 9C This is a flowchart 930 illustrating a method for locating accessory devices in a device group. In one embodiment, the owner uses a detector mobile device 102 to request a search experience via a user interface 204, thereby locating the device group 105 for an AirPod accessory device 101 with an AirPod case 103. In another embodiment, the detector mobile device 102 may perform a search method to provide location data of the AirPod accessory device 101 with an AirPod case 103 to a device locator service 170 for crowdsourcing location data. An indication that a first accessory device is part of the device group is received (931). Status and / or verifiable information provided in a beacon signal may indicate that the first accessory device 101A is part of the device group 105. In some embodiments, the indication that the first accessory device 101A is part of the device group 105 may be verified by a certificate authority or verification service.

[0089] The status information received in the beacon signal from the first accessory device 101A can indicate that the first accessory device 101A (e.g., the right or left AirPod) has a wireless connection with the second accessory device 101B (e.g., the remaining AirPods) in the device group 105 (932). Therefore, it can be inferred that the first accessory device is close to the second accessory device 101B and / or has access to the location information of the second accessory device, and the beacon signal from the first accessory device 101A can be relied upon for coupling the location information of the accessory device.

[0090] The mobile device 102 can receive a beacon signal (933) from a first accessory device 101A in device group 105. The beacon signal includes status information (933) about a second accessory device 101B and location data (933) about device group 105 from the beacon signal. The status information may also include information about whether the first accessory device 101A is close to the second accessory device 101B. The location data can be displayed on AirPods 101 using user interface 204 and / or stored in a location server (934).

[0091] Figure 9D This is a flowchart 940 illustrating a method for locating accessory devices in a device group. In one embodiment, the owner uses a detector mobile device 102 to request a search experience via a user interface 204, thereby locating the device group 105 for an AirPod accessory device 101 with an AirPod case 103. In another embodiment, the detector mobile device 102 may perform a search method to provide location data of the AirPod accessory device 101 with an AirPod case 103 to a device locator service 170 for crowdsourcing location data. An indication that a first accessory device is part of the device group is received (941). Status and / or verifiable information provided in a beacon signal may indicate that the first accessory device 101A is part of the device group 105. In some embodiments, the indication that the first accessory device 101A is part of the device group 105 may be verified by a certificate authority or verification service.

[0092] Status information received in the beacon signal from the first accessory device 101A may indicate that the first accessory device 101A (e.g., the right or left AirPod) is not connected to another accessory device in device group 105 (e.g., 101B, the remaining AirPod) (942). A first beacon signal from the first accessory device 101A in device group 105 (943) and a second beacon signal from the second accessory device 101B in device group 105 may be received sequentially or in parallel (944). In some embodiments, if the AirPods (101A or 101B) are in case 103, proximity information may not be provided in the status information in the beacon signals. Location data from the first and second beacon signals may be presented on the AirPods 101 using user interface 204 and / or stored in a location server (945).

[0093] Figure 10 A method 1000 for determining the location of a wireless accessory via a device locator server 203 is shown. Figure 11 An additional method 1100 for determining the location of a wireless accessory via a device locator server 203 is illustrated. In one embodiment, via... Figure 10and / or Figure 11 The location data retrieved by the method shown may include data from accessory device 101 in device group 105. In another embodiment, this can be performed for each accessory in device group 105. Figure 10 and / or Figure 11 The method shown. (As illustrated) Figure 10 As shown, method 1000 includes an electronic device activating a device locator UI (1001). In response to activating the device locator UI, an electronic device, such as mobile device 102 as described herein, or another electronic device associated with the same cloud service account as mobile electronic device 102, may perform an operation to generate a set of public keys included in a beacon signal broadcast by the wireless accessory during a first time period (1002). 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, using a shared secret generated by the wireless accessory, can generate a set of public keys corresponding to the keys generated by the wireless accessory during the first time period. The electronic device may then send the set of public keys to send location data corresponding to the set of public keys upon request to device locator server 203 (1003). 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 (1004). The electronic device may then process the location data to determine the highest probability location of the wireless accessory (1005).

[0094] Processing location data can include a variety of different operations. In one embodiment, the location data includes latitude and longitude information and a timestamp determining 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 also include UWB ranging information and / or RSSI information of the beacon detected by the detector device. Electronic devices can analyze the UWB ranging information and / or RSSI information in the context of the device's location to obtain a more accurate location of the wireless accessory. Data that can be transmitted by the detector device and used for location processing is... Figure 12 It is shown in the figure and described below.

[0095] like Figure 11As shown, method 11 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. In the case of a group of devices, the electronic device (e.g., mobile device 102) can provide location data about the devices in the device group 105. The electronic device can generate a first set of public keys (1101) included in a beacon signal broadcast by a wireless accessory during a first time period. The first time period can be, for example, 24 hours, but other initial search time periods can be used. The electronic device can perform subsequent operations to request the device locator server to send location data corresponding to the first set of public keys (1102). If the data is returned by the server (1103, "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 1109).

[0096] If the server does not return data (1103, "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 (1104). 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 (1105). If the server returns data in response to the request (1106, "Yes"), method 1100 may proceed to box 1109, whereby the electronic device decrypts the received data. If the server does not return data (1106, "No"), or if the server sends a reply indicating that the data is unavailable, method 1100 includes widening the search time by continuously requesting earlier time periods until a maximum time period is reached (1107).

[0097] Figure 12 This is a flowchart illustrating method 1200 for broadcasting a signal beacon at a wireless location according to an embodiment. Aspects of method 1200 are also... Figure 2 and Figure 3As shown in the diagram. Method 1200 includes deriving a public key from a wireless accessory (box 1202). 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. Optionally, it is determined whether the wireless accessory is part of a device group (1204). If the wireless accessory is part of a device group (1204), status information and / or verifiable information of other accessory devices 101 in device group 105 are provided in the beacon signal (1206). The wireless accessory may indicate status information and / or verifiable information, such as whether any other wireless accessory in the device group is near, connected (physically or wirelessly), and / or any other information about other wireless accessories in device group 105. In one embodiment, a set of bits included in the beacon signal may represent each accessory in the device group, and setting a Boolean value (e.g., true (1) or false (0)) may indicate whether the corresponding accessory is near and / or connected to the accessory device that sent the beacon signal. Alternatively, if the wireless accessory is not part of a device group (1204), no information is provided on the device group. The wireless accessory can then transmit beacon signals at a first frequency, wherein the beacon signals include the public key (1208). The first frequency can be varied, and in one implementation, it is one beacon every two seconds.

[0098] After transmitting the beacon signal, the wireless accessory can listen for a response from the owner device (1210). If the wireless accessory receives a response from the owner device (1210, "Yes"), it can enter a near-owner state (1212) and begin transmitting the beacon signal at a second lower frequency (1216). If the wireless accessory does not receive a response from the owner device (1210, "No"), it can continue transmitting the beacon at a first frequency (1214).

[0099] Method 1200 further includes rotating the public key once every M minutes when transmitting beacons, where the value of M may vary 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 (1218). Even if the wireless attachment has not yet entered a new key period (1218, "No"), it can continue transmitting beacons using the current public key (1222). When the wireless attachment detects that it has entered a new key period (1218, "Yes"), it can derive a new public key using the current timestamp (box 1220). In one implementation, the new public key can be derived using an existing public key, a timestamp, and an anti-tracking secret.

[0100] Figures 13 to 14 Operation of method 1300, which can be performed by a detector device according to the embodiment described herein, is illustrated. Aspects of method 1300 are also... Figure 2 and Figure 3As shown in the image.

[0101] like Figure 13 As shown, method 1300 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 (1301). 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 (1302). 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.

[0102] Method 1300 also includes the detector device performing periodic Wi-Fi scans using the wireless processor when the application processor is in a low-power mode (1303). 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 as a 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 (1304).

[0103] In one implementation, the Wi-Fi scan buffer is a rolling buffer that stores the most recently detected SSID while overwriting earlier detected SSIDs. In one implementation, 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 (1305) and associate those beacon scans with the most recently detected SSIDs in the Wi-Fi scan buffer. If a beacon signal is received from the device group (1306), a set of device locations corresponding to the received beacon may be performed based on the Wi-Fi scan buffer data for the beacon signal from the device group 105 (1310). For example, if a beacon signal is received from a first accessory device from the device group 105, and the beacon signal includes information about a set of proximity devices physically or wirelessly connected to the first accessory device, the last known location of the first accessory device may be attributed to / stored in the device group 105 for each of the first accessory device and the proximity devices. Alternatively, this correlation can enable the detector device to determine a set of device locations corresponding to the received beacons based on Wi-Fi scan buffer data (1308).

[0104] Method 1300 in Figure 14 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 (1407) 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 (1408). The detector device may also add signal strength (RSSI) and / or ranging data to the location data (1409). 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 (1410). 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 enqueue the encrypted location data for transmission to a device locator server (1411). 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 which the detector device can transmit the data to the cloud service server (1412).

[0105] Figure 15 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 1504A-1504N) for beacon signals 301 received from wireless accessory 201 across multiple locations 1502A-1502N. Detector device 202 may also represent multiple detector devices, such as... Figure 3 A group of detector devices 303 are configured, each detecting beacon signals at a different location. Each detector device 202 can transmit different locations and signal strengths, and the location and signal strength data received from multiple detector devices are aggregated by a device locator server. In one embodiment, where both the detector devices and the wireless device include UWB radio equipment, UWB ranging 1506 can be performed if the detector devices and the wireless device are within UWB transmission range. The UWB ranging and signal strength data can be transmitted to the device locator server along with the location data of the detector devices.

[0106] The owner device can retrieve RSSI and / or UWB information, as well as location data, from the device locator server. In one embodiment, the location data is provided in the form of latitude and longitude information and a timestamp determining 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.

[0107] Figures 16 to 21 The device locator UI 204 according to the implementation scheme is shown. Figure 16 A first graphical user interface of device locator UI 204 according to an embodiment is shown, which displays notifications for various wireless accessories of the user. Device locator UI 204 enables separate notifications 1602 to be displayed on the main screen 1601 of electronic device 1600. Figure 17 A second graphical user interface for the device locator UI204 according to the embodiment is shown, which enables viewing of left-behind devices on a map, adding trusted locations, or requesting to stop notifications for items. Figure 18 A third graphical user interface (GUI) of device locator UI 204 according to an embodiment is shown, which enables the location of accessory device 101 in device group 105. As shown, electronic device 1500, including mobile device 102, can be used to scan for accessory devices in device group 105 using location data from beacon signals and the search methods described herein (as indicated by the “L” left and “R” right options in 1804). Selectable element 1805 can be selected to continue searching for accessory devices in device group 105.

[0108] Figure 19 A fourth graphical user interface of the device locator UI 204 according to the embodiment is shown, which enables the location of the accessory device 101 (including devices in device group 105) on a map. Figure 20 A fifth graphical user interface of the device locator UI 204 according to an embodiment is shown, which enables the wireless accessory to be set to lost mode or to notify when it is found. The device locator UI 204 can be displayed on an electronic device, which can be the mobile device 102, or any other type of electronic device described herein. Figure 21 A sixth graphical user interface of the device locator UI 204 according to the embodiment is shown, which enables wireless accessories to add trusted locations.

[0109] like Figure 17As shown, the device locator UI 204 can present a unified graphical interface on the electronic device 1700, 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 1704 with markers 1505 indicating the current or last known location of the wireless device or accessory. Markers 1505 may be icons, images, graphics, or any other user interface element that identifies the accessory and conveys its location. Selectable elements 1706 in the device locator UI 204 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 1900, such as... Figure 19 As shown.

[0110] like Figure 19 As shown, the device locator UI 204 can present a fourth user interface that allows the wireless accessory to view the distance of item 1903 and electronic device 1900. In one embodiment, the second user interface can respond to selection. Figure 17 The selectable element 1706 shown is displayed. The second user interface may present user interface element 1902 representing and / or describing the wireless accessory under consideration, as well as a map 1901 and markers 1902 displaying the current or last known location of the wireless accessory.

[0111] like Figure 20As shown, the device locator UI 204 may present a fifth 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, the map 2001 will not display a marker indicating the location of the accessory. The device locator UI 204 may present user interface elements 2004 representing and / or describing the wireless accessory under consideration and a set of selectable user interface elements. A selectable user interface element 2006 may present an option to notify the user when the accessory is found. When notification upon discovery 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 that 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. The device locator UI 204 may present a selectable user interface element 2005 to allow the user to give the option to request the lost device to play a sound. If a connection is established with the lost device from device group 105, a request to play a sound can be sent to the lost device. If a connection cannot be established, the user can be given the option to queue the sound playback request to be sent to the lost device via a selectable user interface element (not shown), if a connection can be established within a limited time period. If the user chooses to queue the request at mobile device 102, the status of the queued request can be provided on the user interface, such as by a selectable user interface element 2008 indicating that the request is pending with "Sound pending".

[0112] Another optional user interface element 2007 allows the wireless accessory to be placed in explicit lost mode. When explicitly placed in lost mode, the wireless accessory cannot be paired 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.

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

[0114] like Figure 21As shown, the device locator UI 204 can present a sixth graphical user interface in the electronic device 100, which enables the designation of a known location 2106 shown on a map with 2104 to become a reliable location upon selection of selectable element 2103. The device locator UI 204 can present user interface elements 2105 that represent and / or describe the wireless accessory under consideration.

[0115] Figure 22 This is a block diagram illustrating an exemplary API architecture that can be used in some embodiments of the present invention. For example... Figure 22 As shown, API architecture 2200 includes API implementation component 110 (e.g., operating system, library, device driver, API, application, software, or other module) that implements API 1120. API 2220 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 2230. API 2220 may specify at least one calling convention that specifies how functions in the API implementation component receive parameters from the API calling component and how functions return results to the API calling component. API calling component 2230 (e.g., operating system, library, device driver, API, application, software, or other module) makes API calls through API 2220 to access and use the characteristics of API implementation component 2210 specified by API 2220. API implementation component 2210 may return values ​​to API calling component 2230 through API 2220 in response to API calls.

[0116] It should be understood that API implementation component 2210 may include additional functions, methods, classes, data structures, and / or other features not specified through API 2220 and not available to API invocation component 2230. It should be understood that API invocation component 2230 may be on the same system as API implementation component 2210, or may be remotely located and accessed via a network using API 2220. Although Figure 22 The diagram illustrates a single API call component 2230 interacting with API 2220, but it should be understood that other API call components written in a different language (or the same language) than API call component 2230 can use API 2220.

[0117] API implementation component 2210, API 2220, and API calling component 2230 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.

[0118] Figure 23 This is a block diagram of a device architecture 2300 for a mobile or embedded device according to an implementation scheme. Device architecture 2300 includes a memory interface 2302, a processing system 2304 including one or more data processors, an image processor and / or graphics processing unit, and a peripheral device interface 2306. 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.

[0119] The memory interface 2302 can be coupled to the memory 2350, 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.).

[0120] Sensors, devices, and subsystems can be coupled to peripheral interface 2306 to facilitate a variety of functions. For example, motion sensor 2310, light sensor 2312, and proximity sensor 2314 can be coupled to peripheral interface 2306 to facilitate mobile device functionality. One or more biometric sensors 2315 may also be present, such as a fingerprint scanner for fingerprint recognition or an image sensor for facial recognition. Other sensors 2316 may also be connected to peripheral interface 2306, such as positioning systems (e.g., GPS receivers), temperature sensors, or other sensing devices to facilitate related functions. Camera subsystem 2320 and optical sensor 2322 (e.g., charge-coupled device (CCD) or complementary metal-oxide-semiconductor (CMOS) optical sensor) can be used to facilitate camera functions such as recording photos and video clips.

[0121] Communication functionality can be facilitated by one or more wireless communication subsystems 2324, 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 2324 may depend on the communication network through which the mobile device intends to operate. For example, a mobile device including the illustrated device architecture 2300 may include a wireless communication subsystem 2324 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 2324 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.

[0122] The audio subsystem 2326 can be coupled to the speaker 2328 and the microphone 2330 to facilitate voice-enabled functions such as voice recognition, voice copying, digital recording, and telephone functionality. In the smart media device described herein, the audio subsystem 2326 can be a high-quality audio system that includes support for virtual surround sound.

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

[0124] In one embodiment, a sensor controller 2344 is included to monitor, control, and / or process data received from one or more motion sensors 2310, light sensors 2312, proximity sensors 2314, or other sensors 2316. The sensor controller 2344 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.

[0125] In one implementation, the I / O subsystem 2340 includes other input controllers 2345 that can be coupled to other input / control devices 2348, such as one or more buttons, rocker switches, thumbwheels, infrared ports, USB ports, and / or pointer devices such as styluses, or up / down buttons for volume controls of control devices such as speakers 2328 and / or microphones 2330.

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

[0127] The memory 2350 may also store communication instructions 2354 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 2350 may also include user interface instructions 2356, including graphical user interface instructions to facilitate graphical user interface processing.

[0128] In addition, memory 2350 may store sensor processing instructions 2358 to facilitate sensor-related processing and functions; telephone instructions 2360 to facilitate telephone-related processes and functions; instant messaging instructions 2362 to facilitate electronic messaging-related processes and functions; web browser instructions 2364 to facilitate web browsing-related processes and functions; media processing instructions 2366 to facilitate media processing-related processes and functions; location service instructions including GPS and / or navigation instructions 2368 and Wi-Fi-based location instructions to facilitate location-based functionality; camera instructions 2370 to facilitate camera-related processes and functions; and / or other software instructions 2372 to facilitate other processes and functions, such as security processes and functions, and system-related processes and functions. Memory 2350 may also store other software instructions, such as web video instructions to facilitate web video-related processes and functions; and / or web shopping instructions to facilitate online shopping-related processes and functions. In some embodiments, media processing instructions 2366 are divided into audio processing instructions and video processing instructions, respectively used to facilitate audio processing-related processes and functions and video processing-related processes and functions. Mobile device identifiers, such as International Mobile Equipment Identity (IMEI) 2374 or similar hardware identifiers, may also be stored in memory 2350.

[0129] 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 2350 may include additional instructions or fewer instructions. Furthermore, various functions may be performed in hardware and / or software, including in one or more signal processing and / or application-specific integrated circuits.

[0130] Figure 24This is a block diagram of a computing system 2400 according to an implementation scheme. The computer system 2400 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 2400 can be used to provide computing devices and / or server devices that may be connected to the computing devices.

[0131] Computer system 2400 includes a bus 2435 or other communication device for transmitting information, and a processor 2410 coupled to the bus 2435 for processing information. Although computing system 2400 is illustrated as having a single processor, computing system 2400 may include multiple processors and / or coprocessors. Computing system 2400 may also include memory 2420 in the form of random access memory (RAM) or other dynamic storage device coupled to bus 2435. Memory 2420 may store information and instructions executable by processor 2410. During the execution of instructions by processor 2410, memory 2420 may also be main memory for storing temporary variables or other intermediate information.

[0132] The computing system 2400 may also include a read-only memory (ROM) 2430 and / or other data storage device 2440 coupled to the bus 2435 for storing information and instructions for the processor 2410. The data storage device 2440 may be or include various storage devices, such as flash memory devices, disks, or optical disks, and may be coupled to the computing system 2400 via the bus 2435 or via a remote peripheral device interface.

[0133] The computing system 2400 can also be coupled to a display device 2450 via a bus 2435 to display information to a user. The computing system 2400 may also include a numeric-alphanumeric input device 2460, which includes numeric keys and other keys, and can be coupled to the bus 2435 to send information and command options to the processor 2410. Another user input device includes a cursor control device 2470, such as a touchpad, mouse, trackball, or cursor arrow keys, for transmitting directional information and command selections to the processor 2410 and controlling cursor movement on the display device 2450. The computing system 2400 can also receive user input from a communicatively coupled remote device via one or more network interfaces 2480.

[0134] The computing system 2400 may also include one or more network interfaces 2480 to provide access to a network such as a local area network (LAN). The network interface 2480 may include, for example, a wireless network interface with an antenna 2485, which may represent one or more antennas. The computing system 2400 may include multiple wireless network interfaces, such as Wi-Fi and... A combination of Near Field Communication (NFC) and / or a cellular telephone interface. Network interface 2480 may also include, for example, a wired network interface for communicating with remote devices via network cable 2487, which may be, for example, an Ethernet cable, a coaxial cable, a fiber optic cable, a serial cable, or a parallel cable.

[0135] In one implementation, network interface 2480 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 2480 may provide wireless communication using, 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.

[0136] The computing system 2400 may also include one or more energy sources 2405 and one or more energy measurement systems 2445. The energy source 2405 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 2400 over a predetermined time period. Furthermore, 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.

[0137] Figure 25 This is a flowchart 2500 illustrating a method for playing sound from a lost accessory device or group of devices according to an implementation scheme. The mobile device 102 may receive a request (2502) to play sound at the accessory device 101A via a device locator application UI 204, such as... Figure 20 As shown. If the initial attempt (2502) to establish a wireless connection with accessory device 101A is successful, a request to play sound can be sent to accessory device 101A.

[0138] Optionally, if the initial attempt to establish a wireless connection fails, status information (2504) regarding device group 105 can be received. Information about the beacon transmission rate of accessory device 101 can be provided based on the last known status information obtained from the beacon signal from accessory device 101 in the device group. For example, in some embodiments, the beacon transmission rate may depend on whether the accessory device is inside or outside box 103. Optionally, if necessary, a request can be sent to accessory device 101A to increase the beacon transmission rate. The timeout period for attempting to connect to accessory device 101A can be determined based on the beacon transmission rate determined by the status of accessory device 101 (e.g., waveguide rate per minute if inside box, every two seconds if outside box, etc.).

[0139] The user can be given the option (2506) via the device locator UI 204 to continue attempting to establish a connection with the accessory device 101A and to queue the request to play sound on the accessory device 101A. If the user chooses to queue the request to play sound on the accessory device 101A at the mobile device 102 (2506), the request will be sent to the accessory device 101A when establishing a wireless connection, if the connection is established before the timeout period expires (2508). The status of the sound playback request, indicating success or failure, can be displayed in the device locator application UI 204 (2510).

[0140] Figures 26 to 28 This is a sequence diagram illustrating a method for requesting one or more lost accessory devices from a device group to play sound according to an embodiment described herein. Figure 26This is sequence diagram 2600 illustrating a method for requesting one or more lost accessory devices from a device group to play a sound, according to an embodiment. Sequence diagram 2600 illustrates a method for playing a sound on accessory 101 in device group 105 to help a user locate a lost accessory when the accessory device is outside box 103. Mobile device 102 initiates device locator application 204 and requests that a sound be played on lost accessory device 101 in device group 105 (2606). An attempt is made to establish a wireless connection with first accessory device 101A and the connection status is presented in the user interface (2608). Optionally, a request is sent to first accessory and second accessory 101 to detect whether the accessory is in the body (e.g., in the ear, on the wrist, etc.) (2610). A warning may be presented in the user interface of device locator application 204 to notify whether any accessory is currently being worn (2610). If the accessory is detected in the body, the volume and / or type of the sound may be changed. When a wireless connection is established with first accessory device 101A, a request to play a sound is sent to the first accessory (2612). Optionally, the user interface of the device locator application 204 may display a message indicating a pending sound request (2614). An attempt to establish a wireless connection with each of the accessory devices may be performed for a configurable duration (2614). If a wireless connection is established, a sound is played on the first accessory device 101A (2616). When a wireless connection is established with the second accessory device 101B, a request to play a sound is sent to the second accessory device 101B (2618). If a wireless connection is established, a sound is played on the second accessory device 101B (2620). The status (e.g., success or failure) of the sound playback request for each accessory may be presented within the user interface of the device locator application 204 (2622).

[0141] Figure 27This is sequence diagram 2700 illustrating a method for requesting sound playback from one or more lost accessory devices in a device group, according to an embodiment. Sequence diagram 2700 illustrates a method for playing sound on two accessories 101 in a device group 105 when the accessory device is in box 103. Mobile device 102 initiates device locator application 204 and requests sound playback on lost accessory device 101 in device group 105 (2706). An attempt is made to establish a wireless connection with first accessory device 101A and the connection status is presented in the user interface (2708). Optionally, a request is sent to first and second accessories 101 to detect whether the accessory is in the body (e.g., in the ear, on the wrist, etc.) (2710). A warning may be presented in the user interface of device locator application 204 to notify whether any accessory is currently being worn (2710). If the accessory is detected in the body, the volume and / or type of the sound may be changed. When a wireless connection is established with first accessory device 101A, a request to play sound is sent to the first accessory (2712). Optionally, the user interface of the device locator application 204 may display a message indicating that a sound request is pending (2714). An attempt to establish a wireless connection with each of the accessory devices in box 103 may be performed for a configurable duration (2714). If a wireless connection is established, a sound is played on the first accessory device 101A (2716). The device locator application 204 may receive a confirmation message from the first accessory device 101A confirming the sound playback. The status of the sound playback request for each accessory (e.g., success or failure) may be presented within the user interface of the device locator application 204 (2722).

[0142] Figure 28This is sequence diagram 2600 illustrating a method for requesting sound playback from one or more lost accessory devices in a device group, according to an embodiment. Sequence diagram 2800 illustrates a method for playing sound on two accessories 101 in a device group 105 when a first accessory device 101A is outside a case 103 and a second accessory device 101B is inside a case 103. The mobile device 102 initiates a device locator application 204 and requests sound playback on the lost accessory device 101 in the device group 105 (2806). An attempt is made to establish a wireless connection with the first accessory device 101A and the connection status is presented within the user interface (2808). Optionally, a request is sent to the first and second accessories 101 to detect whether the accessory is in the body (e.g., in the ear, on the wrist, etc.) (2810). A warning may be presented in the user interface of the device locator application 204 to notify whether any accessory is currently being worn (2810). If the accessory is detected in the body, the volume and / or type of the sound may be changed. When a wireless connection is established with the first accessory device 101A, a request to play a sound is sent to the first accessory (2812). Optionally, the user interface of the device locator application 204 may display a message indicating that the sound request is pending (2814). An attempt to establish a wireless connection with each of the accessory devices may be performed for a configurable duration (2814). If a wireless connection is established, a sound is played on the first accessory device 101A (2816). When a wireless connection is established with the second accessory device 101B, a request to play a sound is sent to the second accessory device 101B (2818). Optionally, the user interface of the device locator application 204 may display a message indicating that the sound request is pending (2821). An attempt to establish a wireless connection with each of the accessory devices may be performed for a configurable duration (2821). If a wireless connection is established, a sound is played on the second accessory device 101B (2820). The status of the sound playback request for each accessory (e.g., success or failure) may be presented within the user interface of the device locator application 204 (2822).

[0143] Although the embodiments are described in language specific to structural features and / or methodological behavior, it should be understood that the appended claims are not necessarily limited to the specific features or behaviors described. Rather, the specific features and behaviors disclosed should be understood as embodiments of the illustrative claims.

Claims

1. A method for finding a group of devices, the method comprising: receiving an indication that a first accessory device is part of a group of devices, wherein the first accessory device is connected to a second accessory device in the group of devices; receiving a beacon signal from the first accessory device in the group of devices, wherein the beacon signal includes at least connection state information indicating that the first accessory device is physically coupled to the second accessory device; determining to attribute location data of the first accessory device to the second accessory device based on the at least connection state information; and storing the location data corresponding to the beacon signal for the group of devices.

2. The method of claim 1, wherein a plurality of accessory devices in the group of devices are physically connected, and the plurality of accessory devices includes the first accessory device and the second accessory device.

3. The method of claim 1, wherein RSSI information is determined from the beacon signal, and wherein the beacon signal includes an advertisement containing RSSI information.

4. The method of claim 1, further comprising: presenting the location data about the group of devices in a user interface.

5. The method of claim 1, further comprising: requesting to store the location data about the group of devices with a device locator service.

6. The method of claim 1, further comprising: generating at least one key for at least one accessory device in the group of devices; requesting a device locator service to send the location data corresponding to the at least one key; and receiving and presenting location data about the group of devices.

7. The method of claim 1, wherein the first accessory device is wirelessly connected to the second accessory device in the group of devices.

8. The method of claim 1, wherein: the first accessory device and the second accessory device are physically connected to a third accessory device; and the first accessory device is physically coupled to the second accessory device through the third accessory device.

9. The method of claim 8, wherein the third accessory device is in the group of devices.

10. The method of claim 8, wherein the first accessory device and the second accessory device are located in the third accessory device.

11. A method for finding a group of devices, the method comprising: receiving an indication that a first accessory device is part of a group of devices; receiving at least connection state information indicating that the first accessory device is not connected to another accessory device in the group of devices; receiving a first beacon signal from the first accessory device in the group of devices; receiving a second beacon signal from a second accessory device in the group of devices; determining that the first accessory device and the second accessory device are physically connected to a third accessory device based on the first beacon signal and the second beacon signal; and storing first location data corresponding to the first beacon signal and second location data from the second beacon signal for the group of devices based on the determination and the at least connection state information.

12. The method of claim 11, further comprising: ​ ​ ​ requesting storage of the first location data and the second location data regarding the group of devices with a device locator service.

13. The method of claim 11, further comprising: presenting the first location data and the second location data regarding the group of devices in a user interface.

14. The method of claim 11, wherein: the at least connection status information indicates that the first accessory device and the second accessory device are not physically connected to each other; and the at least connection status information indicates that the first accessory device and the second accessory device are physically coupled to each other.

15. The method of claim 14, wherein: the first accessory device and the second accessory device are physically connected to a third accessory device; and the first accessory device is physically coupled to the second accessory device through the third accessory device.

16. The method of claim 14, wherein the third accessory device is in the group of devices.

17. The method of claim 14, wherein the first accessory device and the second accessory device are located in the third accessory device.

18. A non-transitory machine-readable medium storing instructions that, when executed, cause one or more processors of a data processing system to perform operations of the method of any of claims 1-17.

19. An electronic device, comprising: a memory to store instructions for execution; one or more processors to execute the instructions stored in the memory, wherein the instructions, when executed, cause the one or more processors to perform operations of the method of any of claims 1-17.

Images