Pairing of accessory groups

Abstract

The present invention provides a method for pairing and finding groups of accessory devices, a non-temporary machine-readable medium, and a data processing system. [Solution] In the network operating environment 100, the mobile device 102 receives a pairing status from the first accessory device 101A, sends 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 adjacent to the first accessory device in the device group, receives information regarding the second accessory device 101B in the device group, and if the second accessory device is nearby, sends a pairing continuation message to the second accessory device, and creates a device group profile using information regarding the number of components and the received information regarding the second accessory device.

Description

[Technical Field]

[0001] (Cross-reference of related applications) This application, which cross-references related applications, claims the benefit of priority from U.S. Patent Application No. 17 / 508,334, entitled “Pairing Groups of Accessories,” filed on 22 October 2021, and U.S. Provisional Application No. 63 / 197,293, entitled “Pairing Groups of Accessories,” filed on 4 June 2021, both of which are incorporated herein by reference. (Technical field)

[0002] Embodiments described herein relate to pairing and finding groups of accessory devices. [Background technology]

[0003] Previous device locator services provided services for individual devices, but did not provide meaningful location services for a set of related devices. Therefore, it is necessary to provide location services for a set of related devices. [Overview of the Initiative]

[0004] In one embodiment, the method provides a method for pairing with a device group, the method being to receive a pairing status from a first accessory device in the device group, selectively pair with the first accessory device based on the pairing status, send a request for information to the first accessory device, the information being about accessory devices in the device group, the information being about at least one accessory device in close proximity to the first accessory device in the device group, receive information about a second accessory device in the device group, selectively send a pairing continuation message to the second accessory device if the second accessory device is in close proximity, and create a device group profile having the information about accessory devices in the device group and the received information about the second accessory device. In some embodiments, the method may be to send a request for status information to the first accessory device, the status information being about status information, the status information being about pairing status and an indication that the first accessory is part of a device group. In some embodiments, the method may provide: sending a request to a first accessory device for status information, wherein the status information includes verifiable information of the first accessory device; sending a verification request along with the received information relating to the first accessory device; and selectively performing a pairing, if the device is not paired, with a second accessory device, the pairing including having access to at least one key associated with the second accessory device for a user account. In some embodiments, the first accessory device is a radio beacon peripheral device. In one embodiment, the method may include sending a verification request along with the received information relating to the second accessory device; and selectively sending a pairing continuation message to the second accessory device based on the verification result received in response to the verification request.In some embodiments, the method provides sending a request to a first accessory device for information regarding the number of accessory devices in a device group and the number of accessory devices adjacent to the first accessory device in the device group.

[0005] In one embodiment, there is a method for facilitating the pairing of a device group, the method providing a first accessory device that determines the proximity status of a second accessory device in the device group, transmits the proximity status of the second accessory device in the device group to a host device, transmits a handshake message to the second accessory device, receives verifiable information from the second accessory device, and transmits the verifiable information to the host device.

[0006] In one embodiment, the device is a non-temporary machine-readable medium that stores instructions for causing one or more processors of an electronic device to perform an operation, and the operation provides 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 for information to the first accessory device, the information being about the accessory devices in the device group, the information being about at least one accessory device in close proximity to the first accessory device in the device group; receiving information about a second accessory device in the device group; selectively sending a pairing continuation message to the second accessory device if the second accessory device is in close proximity; and creating a device group profile having information about the accessory devices in the device group and the received information about the second accessory device.

[0007] In a data processing system having a memory for storing instructions for execution and one or more processors for executing instructions stored in memory, when an instruction is executed, it causes one or more processors to receive a pairing status from a first accessory device in a device group, to selectively pair with the first accessory device based on the pairing status, to send a request to the first accessory device for information relating to accessory devices in the device group, the information including information relating to at least one accessory device adjacent to the first accessory device in the device group, to receive information relating to a second accessory device in the device group, to selectively send a pairing continuation message to the second accessory device if the second accessory device is nearby, and to create a device group profile having information relating to accessory devices in the device group and the received information relating to the second accessory device. In one embodiment, the method provides for finding a device group, the method comprising: receiving an indication that a first accessory device is part of a device group, the first accessory device having a physical connection to a second accessory device in the device group; receiving a beacon signal from the first accessory device in the device group, the beacon signal containing status information relating to the second accessory device; and storing location data from the beacon signal on the device group. In some embodiments, multiple accessory devices in the device group are physically connected to a case. In some embodiments, RSSI information is determined from the beacon signal, and the beacon signal contains an advertisement containing the RSSI information. In some embodiments, the method provides for presenting location data on the device group to a user interface. In some embodiments, the method provides for requesting storage of location data on the device group using a device locator service.In some embodiments, the method provides generating at least one key for at least one accessory device in a device group, requesting a device locator service to transmit location data corresponding to at least one key, and receiving and presenting location data on the device group.

[0008] In one embodiment, the method provides for finding a device group, the method comprising: a first accessory device, which is wirelessly connected to a second accessory device in the device group, receiving an indication that the first accessory device is part of a device group; receiving a beacon signal from the first accessory device in the device group, the beacon signal containing status information relating to the second accessory device; and storing location data from the beacon signal on the device group. In some embodiments, the method provides for presenting the location data on the device group to a user interface. In some embodiments, the method provides for requesting the storage of location data on the device group using a device locator service.

[0009] In one embodiment, there is a method for presenting a user interface for finding a group of devices, the method providing: receiving a request to launch an application; initiating a connection to at least one accessory device from the group of devices; presenting a user interface having the status on at least one device from the group of devices; receiving an indication that at least one device from the group of devices is connected to another device from the group of devices, presenting a selectable element having a query about whether to continue finding devices from the group of devices; and presenting the status of other devices based on the response to the query. [Brief explanation of the drawing]

[0010] [Figure 1] A block diagram of a network operating environment for a mobile device according to an embodiment.

[0011] [Figure 2] A system for locating a wireless accessory according to an embodiment is shown.

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

[0013] [Figure 4] A flowchart showing a method for pairing a group of accessory devices according to embodiments of the present specification.

[0014] [Figure 5] A flowchart showing a method for use with the device locator system described herein.

[0015] [Figure 6] A flowchart showing a method for pairing a group of accessory devices according to embodiments of the present specification.

[0016] <� [Figure 7] A sequence diagram showing a method for presenting a device locator user interface for use with the device locator system described herein.

[0017] [Figure 8] A flowchart showing a method for presenting a device locator user interface for use with the device locator system described herein.

[0018] [Figure 9A]is a flowchart showing a method for finding accessory devices within a device group. [Figure 9B] is a flowchart showing a method for finding accessory devices within a device group. [Figure 9C] is a flowchart showing a method for finding accessory devices within a device group. [Figure 9D] is a flowchart showing a method for finding accessory devices within a device group.

[0019] [Figure 10] Shows a method for determining the location of a wireless accessory via a device locator server.

[0020] [Figure 11] Shows an additional method for determining the location of a wireless accessory via a device locator server.

[0021] [Figure 12] Is a flowchart showing a method for broadcasting a signal beacon in a wireless accessory according to one embodiment.

[0022] [Figure 13] Illustrates the operation of a method that can be performed by a finder device according to the embodiments described herein. [Figure 14] Illustrates the operation of a method that can be performed by a finder device according to the embodiments described herein.

[0023] [Figure 15] Illustrates the collection of signals and ranging data by a finder device according to an embodiment.

[0024] [Figure 16] Shows a device locator user interface according to one embodiment. [Figure 17]This shows a device locator user interface according to one embodiment. [Figure 18] This shows a device locator user interface according to one embodiment. [Figure 19] A device locator user interface according to one embodiment is shown. [Figure 20] A device locator user interface according to one embodiment is shown. [Figure 21] A device locator user interface according to one embodiment is shown.

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

[0026] [Figure 23] This is a block diagram of a device architecture for a mobile device or embedded device according to one embodiment.

[0027] [Figure 24] This is a block diagram of a computing system according to one embodiment.

[0028] [Figure 25] This flowchart illustrates a method, according to one embodiment, for requesting a lost accessory device or device group to play a sound.

[0029] [Figure 26] This is a sequence diagram illustrating a method for requesting one or more accessory devices that have been lost from a group of devices to play sound, according to embodiments described herein. [Figure 27] This is a sequence diagram illustrating a method for requesting one or more accessory devices that have been lost from a group of devices to play sound, according to embodiments described herein. [Figure 28] This is a sequence diagram illustrating a method for requesting one or more accessory devices that have been lost from a group of devices to play sound, according to embodiments described herein. [Modes for carrying out the invention]

[0030] Embodiments described herein provide techniques for enabling the pairing of sets of accessory devices in order to establish a device group and locator service for locating lost or misplaced accessory devices within a device group. A device group is a set of accessory devices (e.g., a pair of earphones such as Apple AirPods®) that can be individually, independently verified, and paired with another device. The association of accessory devices within a device group allows accessory devices to access information to facilitate pairing with other accessory devices within the device group and to enable the locating of accessories within the device group. Various embodiments are described with reference to the figures. However, some embodiments can be implemented without using one or more of these specific details and in combination with other known methods and configurations. The following description mentions a number of specific details, such as specific configurations, dimensions, and processes, in order to provide a thorough understanding of the embodiments. In other cases, well-known semiconductor processes and manufacturing techniques are not described in particular detail so as not to unnecessarily obscure the embodiments. Throughout this specification, a reference to “an embodiment” means that certain features, structures, configurations, or characteristics described in relation to that embodiment are included in at least one embodiment. Therefore, references to the phrase "in one embodiment" in various places throughout this specification do not necessarily refer to the same embodiment. Furthermore, certain features, structures, configurations, or characteristics may be optionally combined in one or more embodiments.

[0031] The following description concerns a computing device that includes a touch-sensitive display. However, it should be understood that the computing device may also 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 coordinated and / or modified from one application to the next, and / or within each application. Thus, a common physical architecture of the device (such as a touch-sensitive surface) can support a variety of applications with intuitive and transparent user interfaces.

[0032] Some processes are described below in terms of sequential operations. However, please understand that some of the operations described may be performed in a different order. Furthermore, some operations can be performed in parallel rather than sequentially.

[0033] Figure 1 is a block diagram of a network operating environment 100 for a mobile device according to one embodiment. The network operating environment 100 includes accessory devices having 101A and 101B (collectively 101) and a plurality of mobile devices such as mobile device 102. In one embodiment, mobile devices 101A and 101B may be accessory devices that can be paired as a device group 105. Optionally, the device group having accessory device 101 may be housed in a mobile device with a wired connection, such as a case 103 that holds the accessory device 101. The case 103 may also be an accessory device that can be paired with mobile device 102 in some embodiments. For example, accessory device 101 may be a device such as Apple AirPods®, EarPods®, and / or PowerBeats®. In some embodiments, accessory device 101 may not be able to communicate over a wide area network. In many embodiments, mobile devices 101 and 102 can each be any electronic device that can communicate with a wireless network and a wireless accessory device. Some exemplary mobile devices 101 include, but are not limited to, smartphones, tablet computers, notebook computers, wearable computers (e.g., smartwatches or other wearable computing accessories), mobile media players, personal digital assistants, EarPods, AirPods®, PowerBeats®, locator tags, headphones, head-mounted displays, health devices, speakers, and other similar devices. Each of mobile devices 101 and 102 may optionally include a user interface, such as the user interface 104 of mobile device 102. In other embodiments, mobile device 101 may not have a user interface as an accessory device.Mobile devices 101 and 102 may be third-party devices that utilize an application programming interface to access the device locator service. Third-party devices may be provided by different device manufacturers or may be part of a different ecosystem (e.g., an operating system) than 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, a wireless network 112 (e.g., a cellular network, a Wi-Fi network) may communicate with a wide area network 114, such as the Internet, by using a gateway 116. Similarly, an access device 118, such as a mobile hotspot wireless access device, may provide communication access to the wide area network 114. The gateway 116 and access device 118 may then communicate with the wide area network 114 via a combination of wired and / or wireless networks.

[0034] In some implementations, both voice and data communications can be established via the wireless network 112 and / or the access device 118. For example, mobile device 102 can make and receive phone calls (e.g., using the VoIP protocol) via the wireless network 112, gateway 116, and wide area network 114 (e.g., using the TCP / IP or UDP protocol), send and receive email messages (e.g., using the POP3 protocol), and retrieve electronic documents and / or streams such as web pages, photos, and videos. In some implementations, mobile device 102 can make and receive phone calls, send and receive email messages, and retrieve electronic documents via the access device 118 and the wide area network 114. In some implementations, mobile devices 101 and / or mobile device 102 can be physically connected to access device 118 using one or more cables, for example, if 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 embodiment, mobile device 101 can communicate with mobile device 102 via a wireless peer-to-peer connection 120. The wireless peer-to-peer connection 120 may be used to synchronize data between devices.

[0035] Mobile device 101 or mobile device 102 can communicate with one or more services, such as telephone service 130, 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 can enable telephone communication between mobile devices or between a mobile device and a wired telephone device. Telephone service 130 can route Voice over IP (VoIP) calls via a wide area network 114 or access a cellular voice network (e.g., wireless network 112). Messaging service 140 can provide, for example, email and / or other messaging services. Media service 150 can provide access to media files, for example, 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. The device locator service 170 can enable a user to locate a lost or misplaced device that was connected to one or more wired and / or wireless networks 110 at least at some point in time. Other services may also be provided, including a software update service for updating operating system software or client software on a mobile device. In one embodiment, the messaging service 140, media service 150, storage service 160, and device locator service 170 can each be associated with a cloud service provider, and the various services are facilitated through cloud service accounts associated with mobile devices 101 and 102.

[0036] In some embodiments, accessory device 101A, accessory device 101B, mobile device 102, case 103, and / or device group 105 may be registered with a Certificate Authority 106. In some embodiments, the Certificate Authority 106 is an entity that issues digital certificates, and the service may be implemented using a set of servers managed by a device manufacturer, a service provider, or a registration service. Certificates provided by the Certificate Authority 106 may prove the validity of received verifiable information about the device, such as the specific manufacturer of the device, serial number, device group identifier or other identifier, indicator that the device is part of device group 105, and / or any other verifiable information. In some embodiments, a device manufacturer may establish device group 105 by grouping the serial numbers of accessory devices within device group 105. In further embodiments, the certificate may be encrypted by device 101, 102, or 103 before being transmitted to a third party and may be decrypted in an authentication service (e.g., a certificate authority or another authentication service) when the third party requests verification of the information provided by the accessory device 101, mobile device 102, case 103, and / or devices within device group 105. In some embodiments, a secure token may be provided in a pairing request by accessory device 101. Further examples of paired devices using a location service 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," which is incorporated herein by reference in its entirety.

[0037] Mobile devices 101 and 102 may have locally accessible applications, services, and functions on the device, including a location service 180. Mobile device 102 may have a device locator application (e.g., a "Find my" application) 190 for locating accessory device 101 using a device locator service 170 and location service 180. Locally accessible data may be stored in known locations 182 and secure or trusted locations 184. In some cases, a machine learning algorithm 186 may be used to identify known locations 182 and / or trusted locations 184. Cluster analysis is provided as an example of a machine learning algorithm that may be used, but 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, classify, and provide semantic labels for locations, such as locations frequently visited by a user. Secure or trusted locations 184 may be explicitly designated or confirmed as such by the user of devices 102A-B after data analysis. In other examples, known locations 182 or trusted locations 184 may be classified offline and provided by a device locator service 170 or a third party (e.g., a database with map information).

[0038] On-device heuristics and / or machine learning models may be used to infer relationships between a user and a location based on the analysis of locally stored data at frequently visited locations, including locations frequently visited by the user, known locations, and / or any other locations. For example, frequently visited locations include home, vehicles, workplaces, any locations frequently visited by a user with mobile devices (e.g., accessory device 101 and mobile device 102), and / or any other locations designated by the user as trusted locations 184. Known locations 182 may be business locations, public spaces, parks, museums, and / or any other locations that a user may frequently visit. Boundary information for each stored location may be stored along with a classification type for the location and any semantic labels assigned to the location. Stored information may include a defined set of boundaries or radial distances around point locations to enable the creation of geofences for locations. Geofences are virtual boundaries of real-world geographical areas. The Global Positioning System (GPS) can be used to create a virtual fence around a location and track the physical location of mobile devices 101 and 102 within the geofence boundary, as well as their entry into and exit from the bounded area.

[0039] The machine learning algorithm 186 may include on-device heuristics, machine learning algorithms, or a combination thereof, to analyze and assign labels to the movement or motion of a device so that it is designated as “moving” or “stable” at a particular location over a period of time. The analysis may be performed using a variety of signals from data sources available to the mobile device 102, including but not limited to sensor data, positioning data, calendar data, transit card usage data, application data, historical data on movement patterns / routines, and / or any other data accessible to the mobile device 102. In some embodiments, the mobile device 102 may be classified with the “stable” semantic label after remaining within a geofence boundary defining a location (e.g., trusted location 184) over a defined period of time. In the simplest case, positioning data for the mobile device 102 may indicate that it remains within the geofence boundary for a particular location for a certain duration (e.g., 5 minutes). Sensor data, such as accelerometer data, may indicate that the mobile device 102 is stationary, supporting the inference that it is stable. Application data can support the inference that mobile device 102 is in a stable state, such as when the mobile device is located at a calendar reservation location. Application data indicating the type of application being used can also provide the inference that the device is in a stable state, such as when a media application is being used. User history data regarding routines or patterns while on the move can be used to determine whether mobile device 102 is in a stable state, such as a bedtime routine at home or a hotel location. Mobile device 102 can be classified as having the "on the move" label based on the user's previous behavior, patterns, or routines, and can be analyzed on mobile device 102. For example, a user may have a routine of working at the same time every day, and if data on the device supports that the pattern is repeating, the "on the move" state may be assigned.In its simplest form, the speed at which a mobile device is moving or entering or leaving a known geographic area (e.g., using geofencing) may allow for the inference that mobile device 102 is in motion. If mobile device 102 is detected accelerating in a known transit area (e.g., a road, highway, rail line, etc.), mobile device 102 may be given the status "in motion". Similarly, if a transit application / card is being used / in use, mobile device 102 may be designated as "in motion".

[0040] Figure 2 shows a system 200 for locating wireless accessories 201A and / or 201B according to one embodiment. In one embodiment, wireless accessories 201A and 201B (collectively 201) are another embodiment of accessory devices 101A and 101B (and optionally case 103), which may be paired as part of device group 105 and may be used interchangeably throughout this specification. Each accessory device includes one or more wireless transceivers and can communicate directly or indirectly (e.g., through another device or computer) with a companion device (e.g., mobile device 102) via a wireless network or peer-to-peer communication link. Accessory device 101A is shown in case 103 and can provide beacon signals to case 103 and any accessories within case 103. Accessory device 101B is separated from case 103 and can be found independently and separately by providing beacon signals. Some examples of additional wireless accessory devices 101 include, but are not limited to, wireless earphones, EarPods, AirPods®, input devices, charging devices, accessory cases, headphones, headsets, fitness equipment, health equipment, display devices, external hard drives, other wearable device adapters (e.g., smartwatches, fitness bands, optical head-mounted displays), speakers, and / or other devices. A paired group of accessories may be devices of the same type (e.g., speakers, AirPods®, fitness weights, etc.) or different types (e.g., smartphones and credit card readers, etc.). Wireless accessories 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, the wireless accessory 201 also includes a smartphone, tablet computer, laptop computer, smart speaker device, television, or television set-top box that is unable to access a wide area network such as the Internet (e.g., wide area network 114 in Figure 1) at least temporarily. The wireless accessory 201 may also include any other wireless device, including a beacon or locator tag that can be attached to another device to enable tracking or location of that device. In one embodiment, the wireless accessory 201 may be from a group of accessory devices paired with the mobile device 102 using a wireless technology standard such as, but not limited to, Bluetooth®. The wireless accessory 201 may also communicate with the mobile device 102 via wireless technology, including implementations of any wireless standards and protocols such as Wi-Fi Direct, Zigbee®, or AirPlay. The companion device with which the wireless accessory 201 is paired is generally referred to as the mobile device 102, but the companion device is not limited to a mobile device. The companion device may also include, in some embodiments, a laptop or desktop device, and in addition, may include, but not limited to, several wearable accessories such as a smartwatch device or a wearable display.

[0041] In one embodiment, the wireless accessory 201 can periodically transmit a wireless beacon signal. The wireless accessory 201 can transmit the beacon signal using one of the various wireless technologies described herein (e.g., Bluetooth®, Wi-Fi, etc.), and in one embodiment, it can also transmit the beacon using ultra-wideband (UWB) wireless technology. The beacon signal can be transmitted using a single wireless technology, one of a plurality of selectable wireless technologies, or a plurality of simultaneous wireless technologies. The beacon signal can transmit a beacon identifier that includes information for specifically identifying individual wireless accessories 201A or 201B and / or device group 105. In one embodiment, the beacon identifier is a public cryptographic key associated with the device.

[0042] The beacon signal may also transmit information about the wireless accessory 201, including device status information and / or verifiable information. The device status information in the beacon signal may include, but is not limited to, the beacon type, device classification, battery level, any predefined device status, device state, lost status, alarm status, separated from owner status, near owner status, near one or more accessory devices 101 in a device group status, wired or wireless connection status, physically connected to one or more accessory devices 101 in a device group status, pairing status indicating whether the accessory device is paired or not, pairing pending status, battery life status, charging status, and / or any other status information. A lost status or "separated from owner" status may indicate that the wireless accessory 201 has determined itself to be lost or has been placed in a lost state by the device owner. An alarm status may indicate that the wireless accessory 201 has been placed in a status that should trigger an alarm if the device 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.

[0043] In some embodiments, the verifiable information may include any information that may be necessary to establish trust or authority that the pairing process and / or discovery process can proceed with the device presenting the verifiable information. For example, the verifiable information may include information established by the device manufacturer, such as a serial number or set of serial numbers within device group 105. In some embodiments, the verifiable information may include device status or state information. The verifiable information may include, but is not limited to, device type, members of a device group, serial numbers, device group, serial numbers of other devices in the device group, state or status information, software version, and / or any other verifiable information. The verifiable information may be transmitted to a certification authority 106 or other certification service to verify the received information presented by one device to another device. The verifiable information may be encrypted and / or transmitted with a token to enable further verification of the device.

[0044] In some embodiments, the beacon signal can be detected by a finder device 202 that is locally close to the radio accessory 201A or 201B in order to use crowdsourcing to locate the lost radio accessory 201. The finder device 202 may be a device similar to the mobile device 102, capable of sending and receiving data over a wide area network 114, and capable of sending and receiving data using radio technology similar to that of the radio accessory 201 (e.g., Bluetooth®). In particular, the finder device 202 may receive data using the radio protocol on which the beacon signal is transmitted. The finder device 202 may determine the location using one or more location and / or positioning services, including, but not limited to, satellite positioning services 206 or ground positioning systems that use RF signals received from radio base stations 205, such as Wi-Fi access points or cell tower transmitters of cellular telephone networks. In one embodiment, the finder device 202 periodically stores the location determined based on one or more location and / or positioning services. The stored location may be associated with the timestamp on which the location was determined. When the finder device 202 receives a beacon signal from the wireless accessory 201, the finder device 202 can transmit its location to the device locator server 203 via the wide area network 114. The timestamp of the determined location of the finder device 202 can be correlated with the timestamp of when the beacon signal was received in order to associate the geographical location with the received beacon signal.

[0045] If the wireless accessory 201 provides a public key in the beacon signal, the finder 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 with the location data, or transmitted unencrypted to the device locator server 203. For example, the received signal strength indicator (RSSI) of the beacon signal can be transmitted with the location data. The RSSI data can then be used to determine the distance of the wireless accessory 201 from the finder device 202 and assist in triangulation on the owner device. If the RSSI data is transmitted unencrypted, in one embodiment, the server can use the RSSI information to reduce noise by discarding very weak signals in the presence of other stronger signals. In one embodiment, UWB ranging data can also be provided and is available.

[0046] In one embodiment, when the finder device 202 receives a beacon signal from the wireless accessory 201, it can behave differently depending on the device status communicated by the wireless accessory 201. In the case of a standard beacon signal, the finder device 202 can queue the encrypted location data and send the location data to the device locator server 203 during a periodic transmission window. However, if the wireless accessory 201 indicates an alarm state, the finder device 202 can immediately send the location data to the device locator server 203.

[0047] In addition, if the beacon signal of the wireless accessory 201 indicates that the accessory is near its owner, the finder device 202 does not need to send location data to the device locator server 203. Alternatively, the finder device 202 may delay the transmission of encrypted location data. If the owner of the wireless accessory 201 wants to locate the wireless accessory, the owner can access the device locator user interface 204 on the mobile device 102. The device locator user interface 204 may be associated with a device locator application used to locate electronic devices and accessories registered to a user's online account, such as a cloud service account or another type of online account. The device owner can use the device locator UI 204 to query the device locator server 203 for location data that may have been sent to the device locator server by the finder device 202 of the wireless accessory 201. In one embodiment, the mobile device 102 may send the public encryption key associated with the wireless accessory 201 to the device locator server 203. The device locator server 203 can then return any stored location data corresponding to a public encryption key. The location data returned to the mobile device 102 may be encrypted data encrypted by the finder device 202 using the public encryption key. The mobile device 102 can then decrypt the encrypted location data using the associated secret key. The decrypted location data can then be processed by the mobile device 102 to determine the most likely location of the wireless accessory 201. In various embodiments, the most likely location of the wireless accessory 201 can be determined by triangulation from multiple received locations, as well as by using the beacon signal RSSI associated with each location and other data such as timestamps or UWB ranging data contained within the location data.

[0048] Figure 3 shows a system 300 for pairing and locating a wireless accessory according to an embodiment described herein. In one embodiment, the user's mobile device 102 (e.g., device 101A, 101B, or 103) of the wireless accessory 201 may present an accessory pairing UI 302 that allows the user to pair 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 accessory 201 exchange the public keys of a public key pair generated by the device and the wireless accessory 201. In one embodiment, the public key exchange (310) is a one-way transfer in which the mobile device 102 transmits the public key of a public key / private key pair to the wireless accessory 201. Alternatively or additionally, the public key exchange (310) may be a Diffie-Hellman key exchange in which the device and accessory establish a shared secret between the two parties. In one embodiment, the public key exchange (310) further establishes the shared secret using elliptic curve cryptography. For example, elliptic curve Diffie-Hellman (ECDH) can be used to enable the establishment of a public key pair and one or more shared secrets. In one embodiment, one or more shared secrets include a tracking prevention secret from which the wireless accessory 201 can periodically derive additional public keys.

[0049] After the wireless accessory 201 is paired with the mobile device 102, the wireless accessory 201 can periodically broadcast a beacon signal 301 containing device status information and a beacon identifier. In one embodiment, the beacon identifier is a public key derived from a shared secret established during a public key exchange (310). Furthermore, the wireless accessory 201 can periodically perform a 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, and 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 can be determined at least in part based on the beacon length associated with the radio protocol used to transmit the beacon signal 301. In one embodiment, the beacon signal can transmit a variation of a beacon advertisement packet associated with a low-energy radio protocol such as Bluetooth® Low Energy.

[0050] In one embodiment, the value M is 15 minutes, and a new K-byte key is generated every 15 minutes. The public key can be deterministically derived based on the timestamp and the tracking-prevention secret generated during the public key exchange 310. The public key derivation (315) process allows the wireless accessory 201 to use different keys over time and prevents long-term association of a particular key with a particular device. The key can be derived based on a tracking-prevention secret known only to the mobile device 102 and the wireless accessory 201, allowing only the mobile device 102 and the mobile device to determine which public key is broadcast by the wireless accessory 201 at any given timestamp. The tracking-prevention secret is generated along with the ECDH public key and can be transferred to the wireless accessory 201. The wireless accessory 201 then uses the tracking-prevention secret to perform the sequence P of the public key. iIt can be made possible to generate. In one embodiment, a sequence P of public keys i = λ i · P defines a group operation between a scalar value or exponent value λ i and a group element such as, for example, an elliptic curve point P. The scalar value or exponent value λ = KDF(AT, i), where KDF is a key derivation function, AT is a tracking prevention secret, and i is a counter or timestamp.

[0051] In one embodiment, to protect the tracking prevention secret when the wireless accessory 201 is damaged, a backtracking resistance can be enabled. When the backtracking resistance is enabled, the tracking prevention secret is transferred to the wireless accessory 201 but is not held by the wireless accessory. Instead, the accessory calculates a value λ i+1 = H(λ i || time), where λ0 = AT and H is a cryptographic hash function. The wireless accessory 201 then stores λ i over a given period i. If the wireless accessory 201 is damaged, only the current and future values of λ i for i are exposed, and the tracking prevention secret AT is not exposed. In one embodiment, the backtracking resistance is implemented by periodically writing λ i to the non-volatile memory of the wireless accessory 201.

[0052] In one embodiment, the wireless accessory 201 can transmit a beacon signal 301 every 2 seconds, but other beacon rates can be used, and the beacon rate can vary under certain circumstances. For example, the wireless accessory 201 can decrease the beacon rate when it is in a state close to the owner. The beacon rate can also vary based on events triggered by an accelerometer. For example, the wireless accessory 201 can increase the beacon rate when it is in an alarm state, which can be triggered by an accelerometer on the wireless accessory 201.

[0053] The wireless accessory 201 can enter a near-owner state after transmitting a beacon signal 301, if it receives a response from a mobile device 102 associated with the accessory's user indicating that the mobile device 102 is within range of the wireless accessory. Furthermore, while the wireless accessory is in a near-owner state, the amount of data transmitted by the beacon signal 301 can be reduced. In one embodiment, the rate at which new public keys are generated can also be reduced while the wireless accessory is in a near-owner state.

[0054] The wireless accessory 201 can enter an alarm state when it receives a message from the mobile device 102 indicating that the wireless accessory 201 should enter an alarm state. When in an alarm state, the wireless accessory can first enter an activatable state in which the wireless accessory 201 can reduce or stop transmitting locator beacon signals, but other types of wireless signaling can continue. The wireless accessory 201 may remain in the activatable state until the state is deactivated by the mobile device 102 or an alarm is triggered. In one embodiment, the alarm may be triggered when movement is detected, for example, via an accelerometer in the wireless accessory 201. In one 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 close to its owner. When an alarm is triggered, the rate of the beacon signal 301 can be increased to increase the speed at which the wireless accessory 201 can be located.

[0055] The beacon signal 301 transmitted by the radio accessory 201 can be detected by a set of finder devices 303 (the finder devices may be finder devices 202) and / or mobile devices 102, which are other electronic devices that can receive the beacon signal transmitted by the radio accessory and transmit the location and other data associated with the beacon signal 301 to the device locator server 203 via the wide area network 114. In one embodiment, the set of finder devices 303 may include a variant of the mobile device 102 or be other types of electronic devices. For example, the set of finder devices 303 may perform an operation (320) that correlates the beacon signal 301 received from the radio accessory 201 with a device location associated with the finder devices 303. As described with respect to Figure 2, the device location may be determined via a satellite positioning service or a ground positioning system using RF signals received from a radio base station (e.g., a Wi-Fi access point or cell tower transmitter). In one embodiment, the set of finder devices 303 may also include a fixed device such as a smart speaker device, a television, or a television set-top box that can receive a beacon signal 301.

[0056] A set of finder devices 303 can encrypt location data using a beacon identifier (e.g., a public key) received in the beacon signal 301 and transmit the location data (325) to the device locator server 203. The data transmitted by the set of finder devices 303 is transmitted anonymously, and the identification information of the finder devices is not stored along with the data transmitted by the finder devices.

[0057] The device locator server 203 can store encrypted location data in a data store 304, and in one embodiment, the data store 304 can be a distributed database having multiple nodes. The hash of the accessory's beacon identifier / public key can be transmitted along with the encrypted location data. The encrypted location data can be stored in a database node based on the hash of the beacon identifier. The encrypted location data can be indexed by the device locator server 203 using the hash of the beacon identifier. Transmitting the hash of the beacon identifier instead of the complete beacon identifier prevents the server from storing the complete beacon identifier. Other information can also be transmitted and stored along with the location data, either encrypted or unencrypted. Other information may include a timestamp when the beacon signal 301 was received, RSSI information of the received beacon, and / or distance information determined, for example, via UWB ranging.

[0058] If a user or owner of a wireless accessory 201 wishes to locate the accessory, the user or owner can access a device locator UI 204 on a mobile device 102. The device locator UI 204 may be associated with a locator application 190 or a function of the mobile device 102. The device locator UI 204 may also have a web-based interface that can be accessed from the mobile device 102 or another type of electronic device such as a laptop or desktop device. Once the mobile device 102 loads the device locator UI 204, it can send a request for location data (330) to the device locator server 203. The request 330 may include a set of public keys or public key hashes that can act as beacon identifiers for beacon data. The mobile device 102 can generate a set of public keys based on secret information held by the mobile device 102 and the wireless accessory 201, and a timestamp on which the mobile device 102 wishes to receive the location data. In one embodiment, the set of public keys is a sequence P of public keys generated based on a tracking prevention secret. i The public key is P. i The sequence is the secret key d j The mobile device 102 corresponds to the sequence of public keys and the corresponding sequence of public keys d j A public key can be generated, where i is a counter or timestamp. In one embodiment, the mobile device 102 can generate a public key (or a hash of a public key) for the previous 24 hours and send it within request 330. If no data is found for the 24-hour public key, the mobile device 102 can send a generated key for an earlier period and return to a predetermined location data retention limit.

[0059] In one embodiment, encrypted location data is stored and indexed based on a hash of the public key instead of the public key, in order to prevent the location service data provider from storing data that could be used to associate the encrypted location data with a specific device, and therefore a specific user or user account. A finder device can transmit a hash of the public key broadcast within a beacon signal 301 associated with an observed location. The device owner can query the device locator server 203 using the hash of the public key determined for the query period.

[0060] In some embodiments, when a location query is 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 the decryption of the location data. In one embodiment, the location data decryption key may be sent to the server providing the web-based interface to enable the server to decrypt the location data, at least while the location data is being viewed via the web-based interface. A notification may be presented to inform the user that the location decryption key is being temporarily shared with the web-based interface server to enable the location data to be decrypted and presented before the location data is displayed via the web-based interface. In one embodiment, the sharing of the location decryption key can be performed via the automatic and temporary delegation of location query rights by a proxy account associated with the web-based interface.

[0061] In one embodiment, the wireless accessory 201 can be put into easy lost mode. In easy lost mode, a set of future public keys can be generated for the wireless accessory and sent to the device locator server 203. The device locator server 203 can then notify the mobile device 102 whether any location data corresponding to a key in the set of future public keys has been received. In one embodiment, a finder device transmitting the location of a wireless accessory in easy lost mode can be instructed by the device locator server 203 to relay a message to the wireless accessory 201 informing it that it is in easy lost mode. A similar mechanism can be used to relay a message to the wireless accessory 201 that puts the accessory into explicit lost mode. Explicit lost mode can be enabled by the user via the device locator UI 204. In explicit lost mode, the wireless accessory 201 cannot be paired with another device unless unlocked by the owner. Further examples of paired devices using location services can be found in U.S. Patent Application No. 16 / 543,227, “A System and Method for Locating Wireless Accessories,” filed on 16 August 2019, which is incorporated herein by reference in its entirety.

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

[0063] If the first accessory device 101A is not currently paired with the mobile device 102 according to its pairing status, the pairing process can be selectively initiated, as shown in Figure 5 (404). In some embodiments, the pairing status may indicate that pairing is pending for the first accessory device 101A, and a device group profile for device group 105 may be retrieved from the device locator server 203 database. The device group profile may be part of a data model for a device group having location data crowdsourced using the device locator service 170. The device group profile may be stored on the mobile device 102 and synchronized between devices linked to a cloud-based account. In addition, the device group profile may be stored in databases on the mobile device 102 and the device locator server 203. The device group profile may record, for example, relationships between accessory devices, status information, and verifiable information received from the accessory devices and / or device manufacturers. The device group profile may be updated with information received from the accessory device 101 via the 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 numbers of the accessory devices in the device group, the pairing status of the accessory devices, and any other information for providing the device location service 170. Therefore, any status and / or verifiable information previously stored in the device group profile can be received from devices in device group 105 and compared with the status and / or verifiable information stored in the device profile of device group 105.In some embodiments, the pairing process can be stopped if there is an information 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 the device group 105 may be a separately identifiable beacon transmitting peripheral device that enables all accessory devices 101 within the device group 105 to be found and verified.

[0064] The first accessory device 101A may provide verifiable information within its beacon signal that allows a certification authority or other certification service to verify that the first accessory device 101A has a serial number that matches a device from device group 105, as expected from a device manufacturer or a user-defined device group. Furthermore, a certification authority or other certification service may use the verifiable information to certify that the first accessory device 101A has a specific device manufacturer. A person skilled in the art will recognize that there are various methods for verifying the information provided by the first accessory device that can be performed before proceeding with the pairing process to confirm that the first accessory device can be trusted.

[0065] Alternatively, if the first accessory device 101A does not provide verifiable information, the pairing process may not proceed. Embodiments may require the first accessory device 101A to provide verifiable information (e.g., cryptographically verifiable information such as certificates and / or tokens) including, but not limited to, a serial number, a manufacturer identifier, a software version, an indication that the accessory device is part of a device group of accessory devices, an expected accessory device identifier relative to other accessory devices in the device group, an expected number of accessory devices in the device group, and / or any other information, in order for the first accessory device 101A to initiate pairing. In one embodiment, the verifiable information may be cryptographically verifiable and authenticated by the certification authority 106.

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

[0067] The information may be received on the second accessory device 101B within the device group 105 (408). The information received on the second accessory device 101B from the first accessory device 101A can assist in the further pairing of the remaining unpaired accessory devices within the device group 105. In one embodiment, if the second accessory device 101B is in proximity to the first accessory device 101A, the first accessory device 101A may transmit verifiable information about the second accessory device 101B. If the second accessory device is in proximity (410), the first accessory device 101A may attempt to pair the second accessory device 101B by sending a pairing continuation message to the second accessory device. If the second accessory device is not in proximity and / or if pairing fails, the verifiable information about the second accessory device may be stored in the corresponding device group profile. Information about the second accessory device 101B may be stored in the device group profile so that it is accessible to the mobile device 102 for subsequent attempts to pair the second accessory device 101B, and the pairing status of the second accessory device may be set to "pending". Alternatively, if the information received from the second accessory device 101B matches the verifiable information from the first accessory device 101A, the pairing process can proceed to Figure 5 to pair the second accessory device 101B. For the sake of simplicity, only the pairing of two accessory devices is described, but those skilled in the art will recognize that pairing can continue for any number of accessory devices if the accessory devices in the device group provide verifiable information to the mobile device 102.

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

[0069] Figure 5 is a flowchart illustrating a method for use with the device locator system described herein. Figure 5 shows method 500 for pairing a mobile device with a wireless accessory. Embodiments of method 500 are also shown in Figures 2 and 3, as described above. For example, the following description of operation refers to a mobile device 102, a wireless accessory 201, and a device locator server 203.

[0070] As shown in Figure 5, Method 500 includes an operation (502) to perform initial pairing with a wireless accessory. Initial pairing may be Bluetooth® pairing or another type of pairing using other wireless technology. During initial pairing, the mobile device and the wireless accessory may exchange identifiers, passkeys, or other authentication information that enables wireless data exchange between the mobile or another electronic device and the wireless accessory. In one embodiment, initial pairing with a wireless accessory may include the exchange of authentication information associated with the wireless protocol on which pairing is performed, enabling all data exchanged wirelessly to have at least a first encryption layer.

[0071] The mobile device can then generate a public / private key pair and one or more additional shared secrets (504). The device can then transmit 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 variation of ECDH is used to generate a public key pair for encryption. In one embodiment, one or more additional shared secrets may include tracking prevention secrets that enable the wireless accessory to derive a new public key based on an existing public key.

[0072] 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 family of cloud service accounts to which the mobile device and wireless accessory are associated. The cloud-based keystore enables 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 can form 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 for device group 105 can also be synchronized between devices associated with a cloud service account (e.g., a user account). The device management server may be associated with other cloud-based servers used to facilitate cloud-based services accessible to the mobile device, such as the device locator server 203 in Figures 2 and 3.

[0073] Figure 6 is a flowchart 600 illustrating a method for pairing a device group of accessory devices according to an embodiment of this specification. The first accessory device 101A can transmit a status regarding the pairing status to the host device (e.g., mobile device 102) and verifiable information about the first accessory device 101A to the host mobile device 102. If the first accessory device 101A is not paired with the host mobile device 102, the pairing process in Figure 5 can be selectively performed at the discretion of the mobile device 102, as described in Figure 4. The first accessory device 101A can determine a status regarding the proximity of the second accessory device 101A in the device group 105 (602), and the status is transmitted to the host mobile device 102 (604). For example, if the devices are in the same case 103, if the devices are wirelessly connected, and / or if the first accessory device 101A can detect or receive a beacon signal from the second accessory device 101B, then the first accessory device 101A may be in close proximity to the second accessory device 101.

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

[0075] Figure 7 is a sequence diagram 700 showing how to present a device locator user interface for use with the device locator system described herein. Accessory devices 101 of device group 105 can be found separately and independently in the discovery experience. When accessory devices 101 of a device group are physically connected, at least one accessory device 101A from the device group that is physically connected to another accessory device 101B can provide a beacon signal to find device group 101. For example, a beacon signal for a single AirPod 101A may be used to find all of the AirPods® in case 103.

[0076] In one embodiment, accessory devices 101 may be within range of a wireless connection (e.g., a Bluetooth® connection), but may not currently be connected. Accessory devices 101 may be in the same location or in different locations within a location, such as a first accessory device 101A being in the bedroom and a second accessory device 101B being in the garage of the home. Mobile device 102 can launch a device locator application 204 (706). The device locator application 204 may request a connection to at least one accessory device (708) in device group 105. For example, the device locator application 204 may preheat the connection for mobile device 102 by initiating or attempting to establish a wireless connection to accessory devices 101A and / or 101B in device group 105. In some embodiments, there is a delay period, such as 6 seconds, before the wireless connection is established. In some embodiments, while attempting to establish a wireless connection in parallel or sequentially, the device locator application 204 can request information from the device locator service 170 regarding the last known location of the accessory device 101.

[0077] Mobile device 102 can establish a connection with accessory device 101A, or mobile device 102 can request the last known location of accessory device 101A determined from previously received advertisements. After the user finds 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 inside case 103, accessory device 101A and / or case 103 can detect a physical connection with accessory device 101A and communicate that accessory device 101A has recently been placed inside case 103. In response to the detection that accessory device 101A has been placed inside case 103, the discovery experience may continue to find the next accessory device 101B. The user interface 204 may present information regarding the location of the discovered accessory device 101A (716) (714). The selectable user interface element may present a user interface that asks the user whether to continue discovering accessory devices within group 105 (718), and the discovery experience may continue to the next accessory device 101B if the next accessory device 101B needs to be positioned as determined by the user using the selectable user interface element. If the user chooses to continue the search by selecting the selectable user interface element, the mobile device 102 may connect to at least one accessory device 101B that needs to be discovered (720). Until accessory device 101B is found (724), location information received via beacon signals may be presented to the user interface 204 to guide the user in finding the remaining accessory devices (e.g., 101B) (722). The user interface 204 may indicate that an accessory device has been found (726).

[0078] Figure 8 is a flowchart showing how to present a device locator user interface for use with the device locator system described herein. A request to launch the application may be received (802). A connection to at least one accessory device from a group of devices may be preheated (804). In some embodiments, previously received beacon signals may indicate status information, such as whether the accessory devices in the device group are separated or together while the connection is being attempted. The user interface may be presented with the status on at least one device from the device group (806). Upon receiving an indication that at least one device is connected to another device from the device group, an selectable element may be presented with a query about whether to continue finding devices from the group of devices (808). In some embodiments, an indication that at least one device is physically connected to case 103 is a good indicator that other devices may also have been found. The status of the other devices may be presented based on the response to the query (810). For example, if an optional element is selected to continue discovering devices from device group 105, the mobile device can initiate a discovery experience to locate the second accessory device 101B.

[0079] Figure 9A is a flowchart 900 illustrating a method for finding accessory devices 101 within device group 105. The discovery technique may be performed to provide a discovery experience for accessory devices within device group 105, which in some embodiments may be performed by an owner mobile device 102 paired with at least one accessory device within device group 105. The discovery technique may also be performed by a mobile device 102 used as a finder device 202 to crowdsource location data for device group 105. Optionally, if the mobile device 102 receives a request from the owner of device group 105 to find device group 105 for accessory devices 101, the mobile device 102 may display the status of accessory devices 101 within device group 105 (902). For example, a user interface 204 may provide location information for each of the accessory devices 101 within device group 105. A beacon signal received by the mobile device 102 from the first accessory device 101A may indicate the status of other accessory devices 101 in the device group 105, including, but not limited to, whether the accessory device is in proximity to the mobile device and / or another accessory device in the device group 105, and whether it is connected to another device by wire and / or wirelessly. The status information of the accessory device provided in the received beacon signal can determine the approach taken to find the accessory device in the device group 105. While the description of discovery is provided for a pair of devices, those skilled in the art will recognize that a similar approach may be taken for any number of devices in the device group 105, including any number of accessory devices.

[0080] Accessory device 101A can receive an indication that it is part of device group 105 (904). Mobile device 102 can receive an indication from accessory device 101A by a beacon signal. In some embodiments, the beacon signal may be any type of advertisement transmitted by accessory device 101A, including an advertisement transmitted to form and / or before forming a connection with mobile device 102. Status information provided by the beacon signal may indicate whether the devices are physically isolated (906). If the accessory devices are not physically isolated (906), a beacon signal from at least one accessory device in the device group may provide location information about a second accessory device from the device group (910). For example, if accessory device 101 is in a case and has a wired connection to case 103, a beacon signal received from accessory device 101A may provide location data, such as RSSI data (e.g., a measurement determined from the beacon signal), to help locate accessory device 101 in the device group. The beacon signal may provide status information and / or verifiable information about the coupled accessory device 101B, such as the serial number of the accessory device 101B and its paired status. RSSI data determined from the beacon signal from accessory device 101A may be attributed to accessory device 101B, since device 101 is inside case 103.

[0081] Continuing to refer to Figure 9A, if at least one accessory device in device group 105 is physically isolated (906), a determination is made as to 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 for 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 from the beacon signal, to help locate the accessory device 101 in the device group. While exemplary embodiments describe a device group having two accessory devices, those skilled in the art will recognize that any number of accessory devices may be connected to and / or isolated from a given accessory device, and that a beacon signal for a given accessory device may represent any number of accessory devices in a device group connected to the accessory device. In one embodiment, a set of bits in a beacon signal received from a given accessory device may be specified to indicate which device is 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 in proximity to the first accessory device 101A. RSSI data determined from the beacon signal from accessory device 101A (e.g., a measurement determined by a mobile device when it receives a Bluetooth® advertisement) can be attributed to accessory device 101B as device 101.

[0082] 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, a beacon signal received from the first accessory device 101A may provide location data, such as RSSI data determined from an advertisement, to help locate the accessory device 101 within the device group 105. The beacon signal may provide last known 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 or was in proximity to the first accessory device 101A. If there are other devices to find within the device group (914), the process continues (902).

[0083] Alternatively, optionally, RSSI data (916) can be used to present the device status, such as the most up-to-date location information. Location data for accessory device 101 may also be stored for each device and / or device group profile (916). Location data may be stored for use with the discovery user interface 204 as shown in Figures 16–21, and / or with the locator service 170.

[0084] Figure 9B is a flowchart 920 illustrating a method for finding an accessory device 101 within a device group 105. In one embodiment, the owner uses a discoverer mobile device 102 to request a discovery experience via a user interface 204 to find the device group 105 for the AirPod accessory device 101 having an AirPod case 103. In another embodiment, the discoverer mobile device 102 can perform a discovery method that provides location data for the AirPod accessory device 101 using the AirPod case 103 to a device locator service 170 for crowdsourced location data. An indication that the first accessory device is part of device group 105 may be received by the mobile device (921). Status and / or verifiable information provided in the 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 using a certification authority or certification service.

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

[0086] A beacon signal from the first accessory device 101A in device group 105 may be received by the mobile device 102 (923). The beacon signal includes status information about the second accessory device 101B (924) and location data from the beacon signal for device group 105 (924). The location data may be presented on the AirPods® 101 using the user interface 204 and / or stored in a location server.

[0087] Figure 9C is a flowchart 930 illustrating a method for finding an accessory device within a device group. In one embodiment, the owner uses a discoverer mobile device 102 to request a discovery experience via a user interface 204 to find a device group 105 for an AirPod accessory device 101 having an AirPod case 103. In another embodiment, the discoverer mobile device 102 can perform a discovery method that provides location data for the AirPod accessory device 101 using the AirPod case 103 to a device locator service 170 for crowdsourced location data. An indication is received that the first accessory device is part of a device group (931). Status and / or verifiable information provided in the 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 using a certification authority or certification service.

[0088] Status information received via a 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 to the second accessory device 101B (e.g., the remaining AirPod) in the device group 105 (932). Thus, it can be inferred that the first accessory device is in proximity to and / or has access to the location information of the second accessory device 101B, and the beacon signal from the first accessory device 101A can depend on the location information of the coupled accessory devices.

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

[0090] Figure 9D is a flowchart 940 illustrating a method for finding an accessory device within a device group. In one embodiment, the owner uses a discoverer mobile device 102 to request a discovery experience via a user interface 204 to find a device group 105 for an AirPod accessory device 101 having an AirPod case 103. In another embodiment, the discoverer mobile device 102 can perform a discovery method that provides location data for the AirPod accessory device 101 using the AirPod case 103 to a device locator service 170 for crowdsourced location data. An indication is received that the first accessory device is part of a device group (941). Status and / or verifiable information provided in the 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 using a certification authority or certification service.

[0091] Status information received from the beacon signal of 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 the device group 105 (e.g., 101B remains an AirPod) (942). The first beacon signal from the first accessory device 101A in the device group 105 (943) and the second beacon signal from the second accessory device 101B in the device group 105 may be received sequentially or in parallel (944). In some embodiments, if the AirPod (either 101A or 101B) is inside the case 103, proximity information may not be provided in the status information within the beacon signal. Location data from the first and second beacon signals may be presented on the AirPods® 101 using the user interface 204 and / or stored in a location server (945).

[0092] Figure 10 shows a method 1000 for determining the location of a wireless accessory via a device locator server 203. Figure 11 shows an additional method 1100 for determining the location of a wireless accessory via a device locator server 203. In one embodiment, the location data retrieved using the method shown in Figure 10 and / or Figure 11 may include data for accessory devices 101 in a device group 105. In another embodiment, the method shown in Figure 10 and / or Figure 11 may be performed for each accessory in the device group 105. As shown in Figure 10, method 1000 includes an action in which an electronic device invokes a device locator UI (1001). In response to the invocation of the device locator UI, an electronic device, which may be a mobile device 102 as described herein, or another electronic device associated with the same cloud service account as the mobile electronic device 102, may perform an action to generate a set of public keys that were contained in a beacon signal broadcast by the wireless accessory during a first period (1002). The first period may be, for example, the past 24 hours. The electronic device is aware of the frequency at which the radio accessory generates a new public key, and can use the shared secret key generated by the radio accessory to generate a set of public keys corresponding to the keys generated by the radio accessory over a first period. The electronic device can then transmit the set of public keys in a request for the device locator server 203 to transmit location data corresponding to the set of public keys (1003). In one embodiment, the location data transmitted by the server in response to the request is encrypted using the public key transmitted as the beacon identifier of the radio accessory. The electronic device can use the secret key generated during initial pairing with the radio accessory to decrypt the encrypted location data received by the server (1004). The electronic device can then process the location data to determine the highest probability location of the radio accessory (1005).

[0093] The processing of location data can include a variety of different operations. In one embodiment, the location data includes latitude and longitude information along with a timestamp at which the location was determined. The electronic device can triangulate based on the timestamp and remove noise or outlier locations. In one embodiment, the location data specifies the location of the finder device that detected the beacon. The location data may further include UWB ranging information and / or RSSI information about the beacon detected by the finder device. The electronic device can analyze the UWB ranging information and / or RSSI information in relation to the device location to reveal a more accurate location of the wireless accessory. Data transmitted by the finder device and that can be used for location processing is shown in Figure 12 and described below.

[0094] As shown in Figure 11, method 1100 includes actions that can be performed when the device locator server does not have location data to provide to an electronic device upon request. In the case of device group 105, an electronic device (e.g., mobile device 102) can provide location data about the devices in the device group. The electronic device can generate a first set of public keys contained in a beacon signal broadcast by a radio accessory during a first period (1101). The first period can be, for example, 24 hours, but other initial discovery periods can also be used. The electronic device can perform a subsequent action requesting 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 decrypt the location data received from the server using the secret key corresponding to the set of public keys (block 1109).

[0095] If no data is returned by the server (1103, "no"), the electronic device may generate a second set of public keys contained in the beacon signal broadcast by the radio accessory during a second period (1104). The second period may be 24 hours prior, 48 hours prior, or any other time prior to the first period. The electronic device may then request the device locator server to send data corresponding to the second set of public keys (1105). If the data is returned by the server in response to the request (1106, "yes"), method 1100 may proceed to block 1109, in which case the electronic device decodes the received data. If no data is returned by the server (1106, "no"), or if the server sends a response indicating that the data is unavailable, method 1100 includes the electronic device extending the search time by continuously requesting older periods until the maximum period is reached (1107).

[0096] Figure 12 is a flowchart illustrating a method 1200 for broadcasting a signal beacon in a wireless accessory according to one embodiment. Embodiments of method 1200 are also shown in Figures 2 and 3. Method 1200 includes the wireless accessory deriving a public key (block 1202). The public key can be derived based on a shared secret and a timestamp determined based on the wireless accessory's clock or timing device. Optionally, a determination is made as to 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 about other accessory devices 101 in device group 105 is provided in the beacon signal (1206). The wireless accessory may indicate status information and / or verifiable information such as whether any other wireless accessories in the device group are nearby or connected (physically or wirelessly), and / or any other information about other wireless accessories in device group 105. In one embodiment, the set of bits contained in the beacon signal can represent each accessory in the device group, and setting a Boolean value (e.g., true (1) or false (0)) can indicate whether the individual accessory is in proximity to and / or connected to the accessory device transmitting the beacon signal. Alternatively, if the wireless accessory is not part of the device group, no information about the device group is provided (1204). The wireless accessory can then transmit a beacon signal at a first frequency, the beacon signal containing a public key (1208). The first frequency can be varied, and in one embodiment, there is one beacon every two seconds.

[0097] After transmitting a beacon signal, the radio accessory may listen for a response from the owner device (1210). If the radio signal receives a response from the owner device (1210, "yes"), the radio accessory may enter a state close to the owner (1212) and begin transmitting a beacon signal on a second, lower frequency (1216). If the radio accessory does not receive a response from the owner device (1210, "no"), the radio accessory may continue transmitting the beacon on the first frequency (1214).

[0098] Method 1200 further includes, for a wireless device, rotating the public key every M minutes during beacon transmission, where the value of M may vary across embodiments and / or based on the device state. Based on timer expiration, counters, or another mechanism, the wireless accessory can determine whether the accessory has entered a new key period (1218). While the wireless accessory has not entered a new key period (1218, "no"), the accessory can continue beacon transmission using the current public key (1222). Upon detecting that the wireless accessory has entered a new key period (1218, "yes"), the accessory can derive a new public key using the current timestamp (block 1220). In one embodiment, the new public key can be derived using the existing public key, timestamp, and tracking-prevention secret.

[0099] Figures 13-14 show the operation of Method 1300 as it may be performed by a finder device according to embodiments described herein. Embodiments of Method 1300 are also shown in Figures 2 and 3.

[0100] As shown in Figure 13, Method 1300 includes the Finder device performing a periodic beacon scan using a radio baseband processor while the Finder device's application processor is in low-power mode (1301). The beacon scan may also be performed when the application processor is active, but the beacon scan may be performed by the radio processor and radio receiver as a low-power operation while the Finder device is idle, inactive, or otherwise in a low-power state. The Finder device may store a timestamp and a beacon identifier in a beacon scan buffer for any beacon data received by the Finder device (1302). In one embodiment, the beacon identifier is a public key generated by the radio device based on the timestamp and a shared secret generated on the owner's mobile device.

[0101] Method 1300 further includes the Finder device performing periodic Wi-Fi scans using the radio processor while the application processor is in low-power mode (1303). Wi-Fi scans may also be performed when the application processor is active, but Wi-Fi scans may be performed by the radio processor and radio receiver as low-power operation while the Finder device is idle, inactive, or otherwise in a low-power state. The device can then store Wi-Fi service set identifiers (SSIDs) and scan timestamps in a Wi-Fi scan buffer on the Finder device (1304).

[0102] In one embodiment, the Wi-Fi scan buffer is a rolling buffer that stores the most recently detected SSID while overwriting older detected SSIDs. In one embodiment, the beacon scan buffer may be a fixed-size buffer with space for a predetermined number of entries. The finder device can invoke the application processor when the beacon scan buffer is full (1305) and correlate those beacon scans with the most recently detected SSIDs in the Wi-Fi scan buffer. If a beacon indicates that the beacon signal was received from a device group (1306), a set of device locations corresponding to the received beacon may be performed for the beacon signal from device group 105 based on the Wi-Fi scan buffer data (1310). For example, if the beacon signal is received from a first accessory device in device group 105 and contains information about a set of nearby devices physically or wirelessly connected to the first accessory device, the last known location of the first accessory device may be attributed / stored to each of the first accessory device and the nearby devices in device group 105. Alternatively, the correlation could allow a finder device to determine a set of device locations corresponding to received beacons based on Wi-Fi scan buffer data (1308).

[0103] Method 1300, following Figure 14, includes the Finder device generating a refined device location by correlating the device location from Wi-Fi scan buffer data with other location data (1407), if other location data is available. Once a refined device location is generated, the Finder device may optionally combine beacon data with the refined device location (1408). The Finder device may also add signal strength (RSSI) and / or ranging data to the location data (1409). Signal strength and ranging data (e.g., UWB ranging data) can be collected when the beacon signal is received by the Finder device. The Finder device may then encrypt the location data using one or more public keys received in the beacon data (1410). The signal and ranging data may be encrypted together with the location data, or transmitted unencrypted together with the encrypted location data. The Finder device may enqueue the encrypted location data for transmission to the device locator server (1411). The device locator server may be one of several cloud service servers, and communication with these cloud service servers is generally performed in batch and suppression manner. Batches of encrypted data can be collected and placed in a transmission queue until a transmission interval arrives, during which the finder device can send data to the cloud service server (1412).

[0104] Figure 15 illustrates the collection of signal and distance measurement data by a finder device according to one embodiment. In one embodiment, the finder device 202 can collect signal strength information (e.g., RSSI 1504A to 1504N) of beacon signals 301 received from the wireless accessory 201 across multiple locations 1502A to 1502N. The finder device 202 can also represent multiple finder devices, such as the set of finder devices 303 in Figure 3, each finder device detecting beacon signals at different locations. Each finder device 202 can transmit different locations and signal strengths, and the location and signal strength data received from multiple finder devices are aggregated by a device locator server. In one embodiment, where the finder device and wireless device each include a UWB radio, UWB distance measurement 1506 can be performed when the finder device and wireless device are within the range of UWB transmission. The UWB distance measurement and signal strength data can be transmitted to the device locator server along with the location data from the finder device.

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

[0106] Figures 16 to 21 show a device locator UI 204 according to one embodiment. Figure 16 shows a first graphical user interface of the device locator UI 204 according to one embodiment, showing notifications for various wireless accessories of the user. The device locator UI 204 can display isolation notifications 1602 on the home screen 1601 of the electronic device 1600. Figure 17 shows a second graphical user interface of the device locator UI 204 according to one embodiment, which allows the user to request that the abandoned accessory device be seen on the map, that a trusted location be added, or that notifications for the item be stopped. Figure 18 shows a third graphical user interface of the device locator UI 204 according to one embodiment, which allows the user to locate an accessory device 101 within a device group 105. As shown, the electronic device 1500, including the mobile device 102, may be used to scan for any accessory device in device group 105 (as indicated by the "L" left and "R" right options in 1804) using location data from the beacon signal and the discovery method described herein. The selectable element 1805 can be selected to continue finding accessory devices in device group 105.

[0107] Figure 19 shows a fourth graphical user interface of the device locator UI 204 according to one embodiment, which allows the accessory device 101, including devices within device group 105, to be found on a map. Figure 20 shows a fifth graphical user interface of the device locator UI 204 according to one embodiment, which allows notification when a wireless accessory is set to lost mode or when it is found. The device locator UI 204 can be displayed on an electronic device which may be a mobile device 102 or any other type of electronic device described herein. Figure 21 shows a sixth graphical user interface of the device locator UI 204 according to one embodiment, which allows a wireless accessory to add a trusted location.

[0108] As shown in Figure 17, the device locator UI 204 can present a unified graphical interface on the electronic device 1700 through which multiple different types of devices and accessories can be located, including wireless devices with network or cellular access and wireless accessories without native network access. The device locator UI 204 may include a map 1704 having markers 1505 that indicate the current or last known location of a wireless device or accessory. The markers 1505 can be icons, images, graphics, or any other user interface elements that identify the accessory and communicate the accessory's location. Selectable elements 1706 within the device locator UI 204 can present a description or name of the wireless device or accessory and, as shown in Figure 19, can indicate the estimated distance between the wireless device or accessory and the current location of the electronic device 1900.

[0109] As shown in Figure 19, the device locator UI 204 may present a fourth user interface that allows the wireless accessory to see the distance from item 1903 and electronic device 1900. In one embodiment, a second user interface may be displayed depending on the selection of selectable element 1706 shown in Figure 17. The second user interface may present a user interface element 1902 that represents and / or describes the wireless accessory in question, as well as a map 1901 and markers 1902 that show the current or last known location of the wireless accessory.

[0110] As shown in Figure 20, the device locator UI 204 may present a fifth graphical user interface that allows the wireless accessory to be set to lost mode. In one embodiment, if the wireless accessory cannot be located via the device locator UI 204, the map 2001 does not display a marker indicating the accessory's location. The device locator UI 204 may present a user interface element 2004 that represents and / or describes the wireless accessory in question and a set of selectable user interface elements. One selectable user interface element 2006 may present an option to notify the user when the accessory is found. When found notification is enabled, in one embodiment the wireless accessory can be set to easy lost mode. An 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 over a future period (e.g., the next 24 hours, the next 48 hours, etc.). If a signal is detected by a finder device using one of the future keys, the device locator server may notify one or more electronic devices associated with the user. The device locator UI 204 may present selectable user interface elements 2005 to allow the user to give the option to request that the lost device 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 may be given the option via a selectable user interface element (not shown) to queue the sound playback request to be sent to the lost device, provided that a connection can be formed within a defined period. If the user chooses to queue the request on the mobile device 102, the status of the queued request may be provided on the user interface, for example, using a selectable user interface element 2008 indicating that the request is on hold as "sound pending".

[0111] Another selectable user interface element 2007 allows the wireless accessory to be put into explicit lost mode. When explicitly put into lost mode, the wireless accessory cannot be paired with other devices until the accessory is unlocked by the user or owner who puts the device into lost mode. When submitting a request to put a wireless accessory into lost mode, the requesting user may be required to enter authentication credentials to ensure that the requesting user is authorized to request that lost mode be initiated on the lost accessory. Authentication credentials may include a username or password associated with the user's account, such as a cloud service account to which the user, electronic device, and wireless accessory are associated. Authentication credentials may also include biometric information, such as fingerprint or facial recognition data.

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

[0113] As shown in Figure 21, the device locator UI 204 can present a sixth graphical user interface within the electronic device 100, which, by selecting a selectable element 2103, allows the designation of a known location 2106 shown on a map having 2104 to become a reliable location. The device locator UI 204 can present a user interface element 2105 that represents and / or describes the wireless accessory in question.

[0114] Figure 22 is a block diagram illustrating an exemplary API architecture that may be used in some embodiments of the present invention. As shown in Figure 22, the API architecture 2200 includes an API implementation component 110 (e.g., an operating system, library, device driver, API, application program, 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 functionalities of the API implementation component that may be used by an API calling component 2230. API 2220 may specify at least one calling convention that specifies how a function of the API implementation component receives parameters from an API calling component and how a function returns results to the API calling component. The API calling component 2230 (e.g., an operating system, library, device driver, API, application program, software, or other module) makes API calls through API 2220 to access and use the functionalities of the API implementation component 2210 specified by API 2220. The API implementation component 2210 can return a value to the API call component 2230 via API 2220 in response to an API call.

[0115] It will be understood that the API implementation component 2210 may include additional functions, methods, classes, data structures, and / or other functionalities not specified through API 2220 and not available to the API invocation component 2230. It will be understood that the API invocation component 2230 may be on the same system as the API implementation component 2210 or may be located remotely and can access the API implementation component 2210 via a network using API 2220. Figure 22 shows a single API invocation component 2230 interacting with API 2220, but it will be understood that other API invocation components that can be written in a different language (or the same language) as API invocation component 2230 may use API 2220.

[0116] The API implementation component 2210, API 2220, and API calling component 2230 can be stored in a machine-readable medium, which includes any mechanism for storing information in a format that can be read by a machine (e.g., a computer or other data processing system). Examples of machine-readable media include magnetic disks, optical disks, random-access memory, read-only memory, and flash memory devices.

[0117] Figure 23 is a block diagram of a device architecture 2300 for a mobile or embedded device according to one embodiment. The device architecture 2300 includes a memory interface 2302, a processing system 2304 including one or more data processors, image processors, and / or graphics processing units, and a peripheral device interface 2306. Various components can be connected by one or more communication buses or signal lines. Various components may be separate logic components or devices, or they may be integrated into one or more integrated circuits, such as a system on a chip integrated circuit.

[0118] The memory interface 2302 can be coupled to a 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.).

[0119] Sensors, devices, and subsystems can facilitate multiple functions by coupling with the peripheral interface 2306. For example, a motion sensor 2310, a light sensor 2312, and a proximity sensor 2314 can be coupled to the peripheral interface 2306 to facilitate mobile device functions. One or more biometric sensors 2315 may also be present, such as a fingerprint scanner for fingerprint authentication or an image sensor for facial recognition. Other sensors 2316 can also be connected to the peripheral interface 2306, such as a positioning system (e.g., a GPS receiver), a temperature sensor, or other detection devices, to facilitate related functions. Camera functions, such as recording photographs and video clips, can be facilitated by utilizing a camera subsystem 2320 and an optical sensor 2322 (e.g., a charge-coupled device (CCD) or a capture-type metal-oxide-semiconductor (CMOS) optical sensor).

[0120] Communication functions can be facilitated via one or more wireless communication subsystems 2324, such subsystems as radio frequency receivers and transmitters and / or optical (e.g., infrared) receivers and transmitters. The specific design and implementation of the wireless communication subsystems 2324 may depend on the communication network(s) on which the mobile device is intended to operate. For example, a mobile device including the illustrated device architecture 2300 may include wireless communication subsystems 2324 designed to operate on a GSM network, CDMA network, LTE network, Wi-Fi network, Bluetooth® network, or any other wireless network. In particular, the wireless communication subsystems 2324 can provide a communication mechanism that allows a media playback application to retrieve resources from a remote media server or scheduled events from a remote calendar or event server.

[0121] By coupling the audio subsystem 2326 with the speaker 2328 and microphone 2330, voice-enabled functions such as voice recognition, voice duplication, digital recording, and telephone functions can be easily implemented. In the smart media devices described herein, the audio subsystem 2326 may be a high-quality audio system including support for virtual surround sound.

[0122] The I / O subsystem 2340 may include a touchscreen controller 2342 and / or other input controllers (one or more) 2345. In the case of a computing device including a display device, the touchscreen controller 2342 may be coupled to a touch-sensitive display system 2346 (e.g., a touchscreen). The touch-sensitive display system 2346 and the touchscreen controller 2342 may detect contact and movement and / or pressure using any of a plurality of touch and pressure sensing technologies, including, but not limited to, capacitive, resistive, infrared, and surface acoustic wave technologies, and other proximity sensor arrays, or other elements for determining one or more contact points with the touch-sensitive display system 2346. Display outputs for the touch-sensitive display system 2346 may be generated by a display controller 2343. In one embodiment, the display controller 2343 may provide frame data to the touch-sensitive display system 2346 at a variable frame rate.

[0123] In one embodiment, the sensor controller 2344 is included for monitoring, controlling, and / or processing data received from one or more of the motion sensor 2310, the light sensor 2312, the proximity sensor 2314, or other sensors 2316. The sensor controller 2344 may include logic for interpreting the sensor data and determining the occurrence of one of more motion events or activities by analyzing the sensor data from the sensors.

[0124] In one embodiment, the I / O subsystem 2340 includes one or more 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 control devices such as up / down buttons for volume control of speaker 2328 and / or microphone 2330.

[0125] In one embodiment, memory 2350 coupled to memory interface 2302 can store instructions for operating system 2352, including portable operating system interface (POSIX) compliant and non-compliant operating systems or embedded operating systems. Operating system 2352 may include instructions for handling basic system services and performing hardware-dependent tasks. In some implementations, operating system 2352 can be the kernel.

[0126] Memory 2350 can also store communication instructions 2354 to facilitate communication with one or more additional devices, one or more computers, and / or one or more servers, for example, to retrieve web resources from a remote web server. Memory 2350 may also include user interface instructions 2356, which include graphical user interface instructions to facilitate the processing of a graphical user interface.

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

[0128] Each of the instructions and applications identified above may correspond to an instruction set that performs one or more of the above functions. These instructions do not need to be implemented as separate software programs, procedures, or modules. Memory 2350 may contain additional instructions or fewer instructions. Furthermore, various functions can be implemented in hardware and / or software, including one or more signal processing and / or application-specific integrated circuits.

[0129] Figure 24 is a block diagram of a computing system 2400 according to one embodiment. The computing system 2400 shown in the figure is intended to represent various computing systems (wired or wireless), including, for example, one or more implementations of a desktop computer system, a laptop computer system, a tablet computer system, a cellular telephone, a personal digital assistant (PDA) including a cellular-enabled PDA, a set-top box, an entertainment system or other consumer electronic device, a smart home appliance device, or a smart media playback device. Alternative computing systems may include more, fewer, and / or different components. The computing system 2400 may be used to provide computing devices and / or server devices to which computing devices can connect.

[0130] The computing system 2400 includes a bus 2435 or other communication device for communicating information, and one or more processors 2410 coupled to the bus 2435 capable of processing information. Although the computing system 2400 is illustrated with a single processor, the computing system 2400 may include multiple processors and / or coprocessors. The computing system 2400 may further include memory 2420, such as random access memory (RAM) or other dynamic storage device coupled to the bus 2435. Memory 2420 may store information and instructions that can be executed by the processor(s) 2410. Memory 2420 may also be main memory used to store temporary variables or other intermediate information during the execution of instructions by the processor(s) 2410.

[0131] The computing system 2400 may also include a read-only memory (ROM) 2430 and / or another data storage device 2440 coupled to a bus 2435 that can store information and instructions for one or more processors 2410. The data storage device 2440 may be or include various storage devices such as a flash memory device, a magnetic disk, or an optical disk, and may be coupled to the computing system 2400 via the bus 2435 or via a remote peripheral interface.

[0132] The computing system 2400 may also be coupled to a display device 2450 via bus 2435 to display information to the user. The computing system 2400 may also include an alphanumeric input device 2460, which includes alphanumeric and other keys, and may be coupled to bus 2435 to communicate information and command selections to a processor(s) 2410. Another type of user input device may include a cursor control device 2470, such as a touchpad, mouse, trackball, or cursor directional keys, which communicates directional information and command selections to a processor(s) 2410 and controls cursor movement on the display device 2450. The computing system 2400 may also receive user input from remote devices that are communicably coupled via one or more network interfaces 2480.

[0133] The computing system 2400 may further include one or more network interfaces 2480 to provide access to a network such as a local area network. The network interfaces 2480 may include a wireless network interface having, for example, one or more antennas 2485 which may represent one or more antennas (e). The computing system 2400 may include multiple wireless network interfaces, such as a combination of Wi-Fi, Bluetooth®, Near Field Communication (NFC), and / or a cellular telephone interface. For example, the network interfaces 2480 may also include a wired network interface for communicating with a remote device via a 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.

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

[0135] The computing system 2400 may further include one or more energy sources 2405 and one or more energy measurement systems 2445. The energy sources 2405 may include an external power supply, one or more batteries, one or more charge storage devices, a USB charger, or an AC / DC adapter coupled to another energy source. The energy measurement systems include at least one voltage or amperage measuring device capable of measuring the energy consumed by the computing system 2400 over a given period of time. Furthermore, it may include one or more energy measurement systems that measure the energy consumed by, for example, a display device, a cooling subsystem, a Wi-Fi subsystem, or other frequently used or high-energy-consuming subsystems.

[0136] Figure 25 is a flowchart 2500 illustrating a method for requesting a lost accessory device or device group to play a sound according to one embodiment. Mobile device 102 can receive a request to play a sound on accessory device 101A via a device locator application UI 204 as shown in Figure 20 (2502). If the initial attempt to establish a wireless connection with accessory device 101A (2502) is successful, a request to play a sound can be sent to accessory device 101A.

[0137] Optionally, if the initial attempt to establish a wireless connection is unsuccessful, status information regarding device group 105 can be received (2504). The last known status information obtained from the beacon signal from accessory device 101 in the device group can provide information regarding the beacon rate of accessory device 101. For example, the beacon rate may, in some embodiments, depend on whether the accessory device is inside or outside case 103. Optionally, a request to increase the beacon rate may be sent to accessory device 101A as needed. The timeout period for attempting to connect to accessory device 101A may be determined based on the beacon rate, such as that determined by the state of accessory device 101 (e.g., a beacon rate of every minute if inside the case, or every 2 seconds if outside the case).

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

[0139] Figures 26–28 are sequence diagrams illustrating a method for requesting one or more accessory devices lost from a device group to play a sound, according to embodiments described herein. Figure 26 is sequence diagram 2600, illustrating a method for requesting one or more accessory devices lost from a device group to play a sound, according to one embodiment. Sequence diagram 2600 illustrates a method for helping a user find a lost accessory by playing a sound on an accessory 101 in device group 105 when the accessory device is outside case 103. Mobile device 102 launches device locator application 204 and requests that it play a sound on the lost accessory device 101 in device group 105 (2606). 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 (2608). Optionally, requests are sent to the first and second accessories 101 to detect whether the accessory is on-body (e.g., in the ear, on the wrist, etc.) (2610). The user interface of the device locator application 204 may display a warning to indicate whether any of the accessories are currently attached (2610). The volume and / or type of the sound may be changed if the accessory is detected on-body. When a wireless connection is established with the 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 that the sound request is pending (2614). Attempts to establish a wireless connection with each of the accessory devices may be made 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, sound is played on the second accessory device 101B (2620). The status of the request to play sound for each accessory (e.g., success or failure) may be presented within the user interface of the device locator application 204 (2622).

[0140] Figure 27 is a sequence diagram 2700 illustrating a method for requesting one or more accessory devices lost from a device group to play a sound, according to one embodiment. Sequence diagram 2700 illustrates a method for playing a sound on both accessories 101 in device group 105 when the accessory device is inside case 103. Mobile device 102 launches device locator application 204 and requests that it play a sound on the lost accessory device 101 in device group 105 (2706). An attempt is made to establish a wireless connection with the first accessory device 101A, and the connection status is presented in the user interface (2708). Optionally, requests are sent to the first and second accessories 101 to detect whether the accessory is on-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 either accessory is currently worn (2710). The volume and / or type of the sound may be changed when the accessory is detected on-body. Once a wireless connection is established with the first accessory device 101A, a request to play a sound is sent to the first accessory (2712). Optionally, the user interface of the device locator application 204 may display a message indicating that the sound request is pending (2714). Attempts to establish a wireless connection with each of the accessory devices in case 103 may be made 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 an acknowledgment message from the first accessory device 101A indicating that the sound has been played. The status of the request to play a sound for each accessory (e.g., success or failure) may be presented within the user interface of the device locator application 204 (2722).

[0141] Figure 28 is a sequence diagram 2600 illustrating a method according to one embodiment for requesting one or more accessory devices lost from a device group to play a sound. Sequence diagram 2800 illustrates a method for playing a sound on both accessories 101 in device group 105 when the first accessory device 101A is outside the case 103 and the second accessory device 101B is inside the case 103. The mobile device 102 launches the device locator application 204 and requests that it play a sound on the lost accessory device 101 in 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, requests are sent to the first and second accessories 101 to detect whether the accessories are on-body (e.g., in the ear, on the wrist, etc.) (2810). The user interface of the device locator application 204 may display a warning to indicate whether any of the accessories are currently attached (2810). The volume and / or type of the sound may be changed if the accessory is detected on-body. 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). Attempts to establish a wireless connection with each of the accessory devices may be made 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 can display a message indicating that a sound request is pending (2821).An attempt to establish a wireless connection with each accessory device may be made 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 request to play a sound for each accessory (e.g., success or failure) may be presented within the user interface of the device locator application 204 (2822).

[0142] While the embodiments have been described in specific language for structural features and / or methodological work, it should be understood that the attached claims are not necessarily limited to the specific features or work described above. The specific features and actions disclosed should rather be understood as explanatory embodiments of the claims.

Claims

1. A method for pairing with a device group, wherein the method is Receiving the pairing status from the first accessory device in the device group, Based on the pairing status, selective pairing with the first accessory device, A request for information is sent to the first accessory device, relating to an accessory device within the device group, wherein the information includes information about at least one accessory device adjacent to the first accessory device within the device group. Receiving information about a second accessory device within the aforementioned device group, When the second accessory device is nearby, a pairing continuation message is selectively sent to the second accessory device. A method comprising creating a device group profile having information about the accessory devices in the device group and received information about the second accessory device.

2. A request for status information is sent to the first accessory device, the status information comprising the pairing status and an indication that the first accessory is part of the device group. The method according to claim 1, further comprising:

3. A request for status information, wherein the status information includes verifiable information of the first accessory device, is transmitted to the first accessory device. Sending a verification request along with the received information relating to the first accessory device, If the aforementioned device is not paired, selectively perform pairing with the second accessory device, the pairing comprising having access to at least one key associated with the second accessory device for a user account. The method according to claim 1, further comprising:

4. The method according to claim 1, wherein the first accessory device is a wireless beacon peripheral device.

5. Sending a verification request along with the received information relating to the second accessory device, Based on the verification results received in response to the verification request, a pairing continuation message is selectively sent to the second accessory device. The method according to claim 1, further comprising:

6. A request is sent to the first accessory device for information regarding the number of accessory devices in the device group and the number of accessory devices in the device group that are adjacent to the first accessory device. The method according to claim 1, further comprising:

7. A method for facilitating the pairing of device groups, wherein the method is The first accessory device determines the proximity status of the second accessory device within the device group, The status regarding the proximity of the second accessory device within the device group is transmitted to the host device, Sending a handshake message to the second accessory device, A method comprising receiving verifiable information from the second accessory device and transmitting the verifiable information to the host device.

8. A non-temporary machine-readable medium for storing instructions for causing one or more processors of an electronic device to perform an operation, wherein the operation is: Receiving the pairing status from the first accessory device in the device group, Based on the pairing status, selective pairing with the first accessory device, A request for information is sent to the first accessory device, relating to an accessory device within the device group, wherein the information includes information about at least one accessory device adjacent to the first accessory device within the device group. Receiving information about a second accessory device within the device group, and selectively sending a pairing continuation message to the second accessory device when the second accessory device is nearby. A non-temporary machine-readable medium, comprising creating a device group profile having information about the accessory devices in the device group and received information about the second accessory device.

9. A data processing system, Memory for storing instructions for execution, The system comprises one or more processors that execute the instruction stored in memory, and when the instruction is executed, the one or more processors The first accessory device in the device group receives the pairing status, Based on the pairing status, the first accessory device is selectively paired. A request for information is sent to the first accessory device, which includes information about an accessory device in the device group, wherein the information includes information about at least one accessory device in the device group that is adjacent to the first accessory device. The device receives information about a second accessory device within the device group, and if the second accessory device is nearby, it selectively sends a pairing continuation message to the second accessory device. A data processing system that causes the creation of a device group profile having information about the accessory devices within the device group and received information about the second accessory device.

10. A method for finding a device group, wherein the method is A first accessory device, the first accessory device having a physical connection to a second accessory device within the device group, receiving an indication that the first accessory device is part of the device group, Receiving a beacon signal from the first accessory device within the device group, wherein the beacon signal includes status information relating to the second accessory device, A method comprising storing location data from the beacon signal on the device group.

11. The method according to claim 10, wherein the plurality of accessory devices within the device group are physically connected to the case.

12. The method according to claim 10, wherein RSSI information is determined from the beacon signal, and the beacon signal includes an advertisement containing RSSI information.

13. To present location data on the aforementioned device group to the user interface, The method according to claim 10, further comprising:

14. Requesting the storage of location data on the device group using the device locator service, The method according to claim 10, further comprising:

15. To generate at least one key for at least one accessory device within the device group, and to request the device locator service to transmit location data corresponding to the at least one key, Receiving and presenting location data on the aforementioned device group, The method according to claim 14, further comprising:

16. A method for finding a device group, wherein the method is A first accessory device, the first accessory device being wirelessly connected to a second accessory device in the device group, receiving an indication that the first accessory device is part of the device group, Receiving a beacon signal from the first accessory device within the device group, wherein the beacon signal includes status information relating to the second accessory device, A method comprising storing location data from the beacon signal on the device group.

17. To present location data on the aforementioned device group to the user interface, The method according to claim 16, further comprising:

18. Requesting the storage of location data on the device group using the device locator service, The method according to claim 16, further comprising:

19. A method for finding a group of devices, the method is Receiving an indication that the first accessory device is part of a device group, Receiving status information indicating that the first accessory device is not connected to another accessory device in the device group, Receiving a first beacon signal from the first accessory device within the device group, and receiving a second beacon signal from the second accessory device within the device group, A method comprising storing location data from the first beacon signal and the second beacon signal for the device group.

20. To present location data on the aforementioned device group to the user interface, The method according to claim 19, further comprising:

21. Requesting the storage of location data on the device group using the device locator service, The method according to claim 19, further comprising:

22. A method for presenting a user interface for finding a group of devices, the method is Receiving a request to launch the application, Initiating a connection to at least one accessory device from a device group, and presenting a user interface having the status on the at least one device from the device group, Upon receiving an indication that at least one device from the device group is connected to another device from the device group, the system presents an selectable element having a query about whether to continue finding devices from the group of devices. A method comprising presenting the status of other devices based on the response to the aforementioned query.

Images