Low power and privacy key resolution using always on processors

Abstract

An apparatus configured to process an indication of a wireless communication device with which the apparatus is allowed to perform a location finding operation, where the indication includes a first identity resolution key (IRK) unique to the wireless communication device; processing a payload including the announcement of the IRK; and comparing the IRK to a first IRK received by the always-on processor.

Description

Priority / Citation

[0001] This application claims priority to U.S. Provisional Application Serial No. 63 / 581,454, filed September 8, 2023, entitled “Low-Power and Privacy Key Resolution for People Finding Using an Always on Processor,” the entire contents of which are incorporated herein by reference. Background Technology

[0002] Various features exist that allow wireless devices to locate each other. However, these features are implemented when the wireless devices are online, for example, when they actively connect to a wireless network. There may be situations where users of wireless devices expect to find each other in offline environments, for example, when one or both devices are not connected to a wireless network. Currently, there is no way to locate another device in an offline environment. Summary of the Invention

[0003] Some example implementations relate to an apparatus having processing circuitry configured to: process an indication that the apparatus is permitted to perform a location lookup operation with a wireless communication device, wherein the indication includes a first identity resolution key (IRK) unique to the wireless communication device; process a payload including the declared IRK; and compare the IRK with a first IRK received by an always-on processor.

[0004] Other example implementations relate to a method for: receiving an indication to a wireless communication device that is permitted to perform a location lookup operation, wherein the indication includes a first identity resolution key (IRK) unique to the wireless communication device; receiving a payload of a declaration including the IRK; and comparing the IRK with the first IRK.

[0005] A further example embodiment relates to a first wireless communication device having a transceiver configured to communicate with a second wireless communication device; and an always-on processor configured to: process an instruction to the second wireless communication device that is permitted to perform a location lookup operation with the first wireless communication device, wherein the instruction includes a first identity resolution key (IRK) unique to the second wireless communication device; process a payload including an announcement of the IRK; and compare the IRK with the first IRK received by the always-on processor. Attached Figure Description

[0006] Figure 1Example layouts based on various example implementation schemes are shown.

[0007] Figure 2 Examples of wireless communication devices according to various example implementation schemes are shown.

[0008] Figure 3 Example call flows for establishing a friendship relationship between the seeker and the seeker, based on various example implementations, are shown.

[0009] Figure 4 Example call flows for performing a location lookup operation between the lookup party and the lookupee, based on various example implementations, are shown.

[0010] Figure 5 Example methods for performing a location lookup operation are shown according to various example implementations. Detailed Implementation

[0011] The example embodiments can be further understood by referring to the following description and related figures, wherein similar elements have the same reference numerals. The example embodiments involve using low-power communication to locate wireless communication devices.

[0012] Exemplary embodiments are described in relation to wireless communication devices. As will be described in more detail below, a wireless communication device may include any electronic components, hardware, software, and / or firmware configured to establish a short-range wireless connection to another wireless communication device.

[0013] The example implementations include the use of short-range communication connections. In some examples, the short-range communication connection may be a Bluetooth connection, such as Bluetooth Classic, Bluetooth Low Energy (BLE), etc. This is merely an example, and the principles described herein for exemplary implementations are applicable to other types of short-range communication connections.

[0014] Exemplary implementations are described in relation to the seeker and the seeker. In this context, the "seeker" is a user who shares their location with others. The "seeker" is a user who receives the location from another user.

[0015] The example implementation allows the target party to share its location while continuing to protect user privacy. Specifically, the target party may not broadcast its location. Instead, the target party can form a friendship relationship with the searcher, which allows the searcher to search for the target party without the target party broadcasting its location. The friendship relationship allows the searcher and the target party to perform the search operation using low-power communication when one or both of them are offline. Low-power communication allows the searcher and the target party to discover each other, and once discovery occurs, the searcher and the target party can perform ranging operations (e.g., ultra-wideband (UWB) ranging operations) to determine a more accurate location for the target party. These exemplary implementations will be described in more detail below.

[0016] Figure 1 An exemplary arrangement 100 according to various exemplary embodiments is shown. The exemplary arrangement 100 includes a first wireless communication device 110 and a second wireless communication device 120. Examples of these wireless communication devices 110 and 120 will be described in more detail below. Figure 1 In the example, the first wireless communication device 110 and the second wireless communication device 120 may not currently have a connection to each other.

[0017] In this example, a user of the first wireless communication device 110 may wish to locate a user of the second wireless communication device 120. As will be described in more detail below, the users of the first wireless communication device 110 and the second wireless communication device 120 may form a relationship that allows the first wireless communication device 110 and the second wireless communication device 120 to find each other. In the example where the user of the first wireless communication device 110 wishes to locate the user of the second wireless communication device 120, the user of the second wireless communication device 120 may be considered the "searched party," for example, a user who shares their location with others. The user of the first wireless communication device 110 may be considered the "searcher," for example, a user who receives their location from another user.

[0018] Figure 2 An exemplary wireless communication device 200 according to various exemplary embodiments is shown. Figure 2 Wireless communication device 200 can represent about Figure 1 The described wireless communication device 110 or wireless communication device 120. Wireless communication device 200 can be any type of electronic component configured to connect to another wireless communication device via a short-range communication connection. Non-limiting examples include mobile phones, smartphones, tablet computers, desktop computers, wearable devices, embedded devices, Internet of Things (IoT) devices, etc.

[0019] The wireless communication device 200 may include a processor 205, an always-on processor (AOP) 208, a controller 203, a memory arrangement 210, a display device 215, an input / output (I / O) device 220, a transceiver 225, and other components 230. Other components 230 may include, for example, audio input devices, audio output devices, data acquisition devices, ports for electrical connection to other electronic devices, sensors for detecting the status of the device, etc.

[0020] The processor 205 may be configured to execute multiple engines of the wireless communication device 200. For example, these engines may perform operations related to locating another wireless communication device, including but not limited to: establishing a relationship with the other wireless communication device, notifying other components of the wireless communication device of the relationship, and generating a response to another wireless communication device attempting to locate the other wireless communication device. Examples of these operations will be described in more detail below.

[0021] The engines described above, as applications (e.g., programs) executed by processor 205, are merely examples. The functionality associated with the engines can also be represented as independent integrated components of the wireless communication device 200, or as modular components coupled to the wireless communication device 200, such as integrated circuits with or without firmware. For example, the integrated circuit may include input circuitry for receiving signals and processing circuitry for processing signals and other information. These engines can also be embodied as one application or multiple separate applications. Furthermore, in some parent devices, the functionality described for processor 205 is split among two or more processors (such as a baseband processor and an application processor). Example implementations can be implemented according to any of these or other configurations of the parent devices.

[0022] AOP 208 is communicatively coupled to processor 205. AOP 208 can also be configured to execute one or more engines to perform operations related to locating another wireless communication device, including but not limited to: determining whether to allow another wireless communication device to locate the other wireless communication device based on an announcement received from the other wireless communication device, and waking up the application processor when the other wireless communication device, if allowed, wants to perform a location lookup procedure with the other wireless communication device. Examples of these operations will be described in more detail below.

[0023] The engine described above in AOP 208, as an application (e.g., a program) executed by AOP 208, is merely an example. The functions associated with the engine can also be represented as independent components of the wireless communication device 200, or as modular components coupled to the wireless communication device 200, such as integrated circuits with or without firmware.

[0024] Memory arrangement 210 may be a hardware component configured to store data related to operations performed by wireless communication device 200. Display device 215 may be a hardware component configured to display data to a user (e.g., display a user interface (UI), text messages, etc.). I / O device 220 may be a hardware component enabling a user to input information (e.g., locating another person, allowing the use of a location service, etc.). Display device 215 and I / O device 220 may be separate components or may be integrated together (such as a touchscreen).

[0025] Transceiver 225 may be a hardware component configured to establish a wireless connection with one or more networks or with one or more other wireless communication devices. The transceiver may be configured to operate using more than one radio access technology. Therefore, transceiver 225 may operate on a variety of different frequencies or channels (e.g., a set of consecutive frequencies) to communicate with networks and / or other wireless communication devices. The transceiver may be configured to operate using a short-range communication protocol, such as Bluetooth. Transceiver 225 may include separate transceiver circuitry for each of the corresponding types of wireless connectivity, radio access technologies, and / or operating frequency ranges. The transceiver may include transceiver circuitry configured to operate using Bluetooth communication. Transceiver 225 includes circuitry configured to transmit and / or receive signals (e.g., control signals, data signals). Such signals may be encoded using information from implementing any of the methods described herein. Processor 205 is operatively coupled to transceiver 225 and configured to receive signals from and / or transmit signals to transceiver 225. Processor 205 may be configured to encode and / or decode signals for use in implementing any of the methods described herein.

[0026] Controller 203 may be a hardware component configured to manage various aspects of communication over a wireless link. Controller 203 may be a Bluetooth controller. In some examples, controller 203 may perform tasks for managing physical layer and link layer operations. Such operations may include, for example, frequency hopping, modulation, packet formatting, error correction, etc. Controller 203 may be operatively coupled to processor 205 (and also operatively coupled to AOP 208) and may assist in the execution of any of the engines described herein.

[0027] Figure 3 A call flow 300 for establishing a friendly relationship between seeker 305 and seeker 310, according to various example implementations, is shown. Reference Figure 1The call flow 300 is described using an arrangement 100, wherein the seeking party 305 may be a wireless communication device 120, and the seeking party 310 may be a wireless communication device 110. When the seeking party 305 and the seeking party 310 are online, for example, connected to a wireless network, some operations of the call flow 300 can be performed. This will be noted in the following description of the call flow 300.

[0028] The lookup party 305 may include client / system 306 (e.g., executed by processor 205), AOP 307, and Bluetooth (BT) controller 308. Similarly, the lookup party 310 may include client / system 313, AOP 312, and BT controller 311. Not all of these components perform the operations in call flow 300. However, these components are shown to maintain consistency with other call flows described herein, such as... Figure 4 The call process is consistent with 400.

[0029] In step 320, the client / system 313 of the party being searched 310 generates a Friendship Identity Resolution Key (IRK). The Friendship IRK can be a one-to-one key that associates the party being searched 310 with the searcher 305. For example, the Friendship IRK generated in step 320 is unique to the searcher / searchee pair, and only that pair knows the Friendship IRK; no other device can use the Friendship IRK to resolve the relationship between the searcher 305 and the searchee 310. Although not shown in call flow 300, a user sharing their location can revoke permission at any time, whether offline (e.g., by disabling a specific Friendship IRK) or online (e.g., by instructing the searcher that the Friendship IRK is no longer valid).

[0030] Before the searched party 310 generates a friendship IRK in 320, the searcher 305 and the searched party 310 (or their user) may have already conveyed their intention to form a friendship relationship to initiate the generation of the friendship IRK. For example, the searcher 305 and / or the searched party 310 may have a location search application, and the user may input their intention to form a friendship via the application's user interface (UI).

[0031] In step 325, the party being looked up 310 may send a friendship IRK to the party looking up 305, for example, the client / system 306 of the party looking up 305. As described above, some operations of the call flow 300 can be performed online. Operation 325 may be one of the operations performed online; for example, the party looking up 305 and the party being looked up 310 may need to communicate for the party looking up 310 to receive the friendship IRK.

[0032] In 330, the client / system 313 of the searched party 310 can update the matching table to include the friend IRKs of the searched party 305 / searched party 310. The BT controller can maintain the matching table (e.g., a table in the firmware that identifies all friend IRKs of the searched party 310). The use of this table will be described in more detail below.

[0033] In 335, the BT controller 311 of the sought party 310 may begin scanning for BT announcements from other wireless communication devices attempting to find the sought party 310. The scanning operation can be any scanning operation supported by the Bluetooth protocol performed by the sought party 310. The sought party 310 may perform a scanning operation when the table in the BT firmware includes any entry, for example, an indication that the sought party 310 has at least one friend that allows the seeker to find the sought party 310. Furthermore, the scanning operation may be performed when the sought party 310 is offline, for example, without a connection to the wireless network. In the example call flow 300, the scanning operation is shown as a discrete operation with an end time. This is for illustrative purposes only. The scanning operation 335 may be continuous until the user of the sought party 310 disables the capability or until the sought party 310 has identified the seeker (e.g., seeker 310) and begins full-power operation, as will be described in more detail below. In some examples, the target will perform a scan at a rate of 30ms or 50ms every 966ms. These scan rates are just examples, and other scan rates may be used.

[0034] In 340, the BT controller 311 may send one or more friend IRKs from the BT firmware table to the AOP 312, including friend IRKs for the lookup party 305 / lookuped party 310. The use of this information by the AOP 312 will be described in more detail below.

[0035] Figure 4 A call flow 400 is illustrated according to various example embodiments for performing a location lookup operation between a lookup party 405 and a lookup target 410. The lookup party 405 may include a client / system 406, an AOP 407, and a BT controller 408. The lookup target 410 may include a client / system 413, an AOP 412, and a BT controller 411. The lookup party 405 and the lookup target 410 may include [missing information - likely related to communication or collaboration]. Figure 3 The components described are similar to those in the call flow 300. Call 400 can be considered a continuation of the call flow 300, for example, the party being searched 410 can actively scan (e.g., refer to...). Figure 3 The described scanning operation 335) is attempting to locate the wireless communication device of the party being searched 410. Furthermore, as mentioned above, at the start of the call process 400, one or both of the searcher 405 and the party being searched 410 may be offline, for example, without a connection to the wireless network.

[0036] In 420, the client / system 406 of the seeker 405 instructs the BT controller 408 to begin sending BT announcements and perform a scan operation on the sought party 410. For example, the user of the seeker 405 can use the client / system 406 to open the location search application and enter information on the UI indicating that the user of the seeker 405 wishes to locate the sought party 410.

[0037] Operation 420 may include the client / system 406 providing information to the BT controller 408 to be included in the declared payload. For example, the declared payload may include an authorization tag encrypted using the lookup / lookup party's friendship IRK, such that only the lookup party can decrypt the authorization tag. In one example, the SipHash function can be used to encrypt the lookup party's BT address and friendship IRK. This can be used to generate a 6-byte SipHash, and the authorization tag can be the first 3 bytes of the SipHash. When this authorization tag is included in the BT declared payload, the other party (e.g., the lookup party) can parse the payload because the other party can run the corresponding SipHash function based on its own BT address and friendship IRK. Using this type of authorization tag protects user privacy because BT addresses rotate approximately every 15 minutes, so the authorization tag will also change. Therefore, this example authorization tag is neither static nor plaintext. This payload of the BT declared payload is merely an example, and other payloads may be used.

[0038] In step 425, the BT controller 408 of the lookup party 405 sends a BT announcement including a payload related to the discovery of the lookup target 410. In step 430, the BT controller 408 performs a scan operation to determine whether the lookup target 410 has responded to the BT announcement. Similarly, in call flow 400, operations 425 and 430 are shown as discrete operations. However, these operations can be performed continuously until the lookup target 410 is located or the user of the lookup party 405 stops attempting to locate the lookup target 410. In some examples, the BT announcement can be sent at a rate of 30 ms, and the scan operation can be performed at a rate of 30 ms / 40 ms. However, these rates are only examples, and other rates can be used.

[0039] Continuing with the call flow 400 shown below scan operation 430, another BT announcement 425 is shown. As described above, an announcement operation may include sending one or more announcements. The searched party 410 may receive any of these one or more announcements. In this example, the BT announcement can be considered to be received by the BT controller 411 of the searched party 410, for example, by a BT scan operation performed by the BT controller 411 that detects BT announcement 425. However, the searched party 410 may receive a previous or subsequent BT announcement, rather than as shown above. Figure 4 The received BT announcement is shown in diagram 435. In 435, the BT controller 411 may pass the BT announcement 425 through a duplication filter; for example, the BT controller 411 may only pass a unique BT announcement to AOP 412. In this example, it can be assumed that BT announcement 425 has passed the duplication filter, and in 440, the BT controller 411 forwards BT announcement 425 to AOP 412.

[0040] In step 445, AOP 412 resolves whether the lookup party 405, identified in BT announcement 425, has a friendship IRK with the lookupee 410. As described above, BT controller 411 may send entries to AOP 410 of other wireless communication devices (e.g., lookup parties) with which the lookupee 410 has formed a friendship IRK. AOP 412 may decrypt the payload information from BT announcement 425, such as the BT address and friendship IRK, and compare it with any friendship IRK entries previously provided by BT controller 411. If the decrypted payload information matches an entry, AOP 412 may determine that the lookup party 405 is authorized to locate the lookupee 405. If no matching entry exists, AOP 412 may ignore BT announcement 425.

[0041] By using AOP 412 to resolve the friend IRK, the party being located 410 can better control its privacy. As can be seen from call flows 300 and 400, although the party being located 410 has allowed other wireless communication devices to locate it (or 310), it does not broadcast its location. Instead, the party being located 410 is scanning for other wireless communication devices (e.g., the seeker) that might attempt to locate it. Therefore, the example implementation eliminates the need for the party being located to broadcast its location, which could otherwise compromise the privacy of the party being located (or the user of the party being located's device).

[0042] In some example implementations, when the sought party 410 is offline, the application and / or baseband processor can be in a low-power mode (e.g., standby mode, sleep mode, etc.). Example implementations allow the application and / or baseband processor to remain in a low-power mode during the localization process because the BT controller 411 and AOP 412 can perform all relevant operations until AOP 412 resolves the seeker 405 with which the sought party 410 has formed a friendship.

[0043] In 450, when AOP 412 has identified a looker 405 with a friendly IRK with the lookupee, AOP 412 may notify the lookupee's client / system 413. In 455, this may trigger the client / system 413 to wake up from low-power mode. In 460, the client / system 413 may instruct the BT controller 411 to respond to BT announcement 425 by sending a BT announcement, as shown in 465. BT announcement 465 may include a friendly IRK that can be used by the lookupee 405, as described below. In one example, BT announcement 425 may have an announcement rate of 30 ms, but other announcement rates may be used.

[0044] As described above, when the lookup party 405 begins the location lookup operation, it initiates a scan operation 430 to determine whether the lookuped party 410 has responded to the BT announcement 425. Therefore, in this example, it can be assumed that the lookup party 405 has already received the BT announcement 465 sent in response to the BT announcement 425.

[0045] In 470, the BT controller 408 can compare the information in the BT announcement 465 with a matching table included in the BT firmware of the lookup party 405. For example, the lookup party 405 may have a table similar to the table of the firmware of the lookupee 410 that includes the friendship IRK formed by the lookup party 405. The BT controller 408 can perform this operation to ensure that the BT announcement 465 is intended as a response to the BT announcement 425 before the information is passed to the client / system 406.

[0046] Once the seeker 405 and the seeker 410 have confirmed their relationship, they can perform more precise location operations, such as UWB ranging. Therefore, the BT declaration 465 may also include information instructing the seeker 405 to begin ranging operations to determine a more precise location of the seeker.

[0047] In 470, the BT controller 408 may send the information included in the BT announcement 465 to the client / system 406, and then in 475, the client / system may perform a ranging operation with the sought party to determine a more accurate location of the sought party 410. Similarly, in 480, the sought party 410 may also perform a ranging operation with the seeker 405. The ranging operation is outside the scope of this example embodiment and will not be described further herein.

[0048] Figure 5 An example method 500 for performing a location lookup operation is shown according to various example implementations. Method 500 is described from the perspective of the party being looked up, such as the wireless communication device 120 in the example above.

[0049] In 505, wireless communication device 120 forms friendships with other wireless communication devices that are allowed to find wireless communication device 120, for example, generating a friendship IRK with wireless communication device 110.

[0050] In 510, wireless communication device 120 populates its AOP with friendship IRKs. As described above, in some examples, the BT firmware store includes a table of entries for all wireless communication devices with which wireless communication device 120 has formed friendships, and the BT controller can use this information to populate the AOP.

[0051] In 515, wireless communication device 120 receives a BT announcement, which includes information indicating that the wireless communication device sending the BT announcement is attempting to perform a location lookup operation with another wireless communication device, for example, by including a Friendship IRK in the BT announcement.

[0052] In 520, the wireless communication device 120 determines whether the BT announcement is for the wireless communication device 120. For example, the AOP of the wireless communication device 120 compares the friend IRK in the BT announcement with the stored friend IRK.

[0053] If no match is found, method 500 terminates (at least with respect to the BT announcement), because the BT announcement is not destined for wireless communication device 120. Wireless communication device 120 may continue scanning for additional announcements and perform operation 520 for these additional announcements.

[0054] If a match exists, in step 525, wireless communication device 120 can respond to the wireless communication device that sent the BT announcement. This response may include sending a BT announcement that can be received by the other wireless communication device. As described above, the match may also cause wireless communication device 120 to perform certain operations, such as waking up an application or baseband processor. Furthermore, a successful location lookup operation may cause wireless communication device 120 and the other wireless communication device to perform ranging operations to allow the other wireless communication device to obtain a more accurate location of wireless communication device 120.

[0055] Example In a first embodiment, a method includes: receiving an indication to a second wireless communication device that is permitted to perform a location lookup operation with a first wireless communication device, wherein the indication includes a first identity resolution key (IRK) unique to the second wireless communication device; receiving a payload including the IRK; and comparing the IRK with the first IRK received by the always-on processor.

[0056] In a second embodiment, according to the method of the first embodiment, the method further includes ignoring the declaration when the IRK does not match the first IRK.

[0057] In a third embodiment, according to the method of the first embodiment, the method further includes sending a message to the application processor of the first wireless communication device indicating that the second wireless communication device has been identified in the location lookup operation when the IRK matches the first IRK.

[0058] In the fourth embodiment, according to the method of the first embodiment, the method further includes receiving the first IRK from the Bluetooth controller of the first wireless communication device.

[0059] In the fifth embodiment, the method of the fourth embodiment is used, wherein the declared payload is received from the Bluetooth controller.

[0060] In a sixth embodiment, according to the method of the first embodiment, the payload of the announcement is encrypted based on the IRK and the Bluetooth address of the wireless communication device that sent the announcement.

[0061] In the seventh embodiment, according to the method of the sixth embodiment, the method further includes using the Bluetooth addresses of the first IRK and the second wireless communication device to decrypt the payload.

[0062] In the eighth embodiment, the method described in the seventh embodiment is used, wherein the SipHash function is used to encrypt the declared payload.

[0063] In the ninth embodiment, a always-on processor is provided, the always-on processor being configured to perform any of the methods described according to the first through eighth embodiments.

[0064] In a tenth embodiment, a wireless communication device is configured to perform any of the methods described according to the first to eighth embodiments.

[0065] Those skilled in the art will understand that the example embodiments described above can be implemented with any suitable software or hardware configuration or combination thereof. Example hardware platforms for implementing the example embodiments may include, for example, Intel x86-based platforms with compatible operating systems, Windows OS, Mac platforms and MAC OS, and mobile devices with operating systems such as iOS, Android, etc. Example embodiments of the methods described above may be embodied as programs containing lines of code stored on a non-transitory computer-readable storage medium, which, at compile time, can be executed on a processor or microprocessor.

[0066] Although this application describes various embodiments that have different features in various combinations, those skilled in the art will understand that any feature of one embodiment can be combined with features of other embodiments in any way that is not expressly denied or that is not functionally or logically inconsistent with the operation of the device or the specified function of the disclosed embodiment.

[0067] As described above, one aspect of this technology involves collecting and using data from specific and lawful sources to improve the delivery of inspirational or other content that may be of interest to users. This disclosure contemplates that, in some instances, the collected data may include personal information data that uniquely identifies or can be used to identify specific individuals. Such personal information data may include demographic data, location-based data, online identifiers, telephone numbers, email addresses, home addresses, data or records related to a user's health or fitness level (e.g., vital sign measurements, medication information, exercise information), date of birth, or any other personal information.

[0068] This disclosure recognizes that the use of such personal information data in the present invention's techniques can be used to benefit users.

[0069] This disclosure anticipates that entities responsible for collecting, analyzing, disclosing, transmitting, storing, or otherwise using such personal information data will comply with established privacy policies and / or privacy practices. Specifically, it is expected that such entities will implement and consistently apply privacy practices generally recognized as meeting or exceeding industry or governmental requirements for protecting user privacy. Such information regarding the use of personal data should be highlighted and easily accessible to users, and should be updated as the collection and / or use of data changes. Users' personal information should be collected only for lawful use. Furthermore, such collection / sharing should only occur after receiving user consent or other lawful grounds provided for in applicable law. Additionally, such entities should consider taking any necessary steps to protect and safeguard the right to access such personal information data and to ensure that other entities with access to personal information data comply with the privacy policies and procedures of other entities. Moreover, such entities may subject themselves to third-party assessments to demonstrate their compliance with widely accepted privacy policies and practices. Furthermore, policies and practices should be tailored to the specific types of personal information data collected and / or accessed, and made applicable to applicable laws and standards, including jurisdiction-specific considerations that may be applied to impose higher standards. For example, in the United States, the collection or access to certain health data may be governed by federal and / or state laws, such as the Health Insurance Portability and Accountability Act (HIPAA); while health data in other countries may be subject to other regulations and policies and should be handled accordingly.

[0070] Regardless of the foregoing, this disclosure also contemplates implementation schemes for users to selectively block the use or access to personal information data. That is, this disclosure contemplates providing hardware and / or software components to prevent or block access to such personal information data. For example, the technology of this invention can be configured to allow users to opt-in or opt-out at any time during or after registering for a service. In addition to providing "opt-in" and "opt-out" options, this disclosure also contemplates providing notifications related to access to or use of personal information. For example, users may be notified when downloading an application that their personal information data will be accessed, and then reminded again just before the application accesses the personal information data.

[0071] Furthermore, the intent of this disclosure is that personal information data should be managed and processed in a manner that minimizes the risk of unintentional or unauthorized access or use. Once data is no longer needed, this risk can be minimized by restricting data collection and deleting data. Additionally, and where applicable, including in certain health-related applications, data deidentification can be used to protect user privacy. Deidentification can be facilitated, where appropriate, by removing identifiers, controlling the amount or specificity of stored data (e.g., collecting location data at the city level rather than the address level), controlling how data is stored (e.g., aggregating data among users), and / or other methods (such as differentiated privacy).

[0072] Therefore, while this disclosure broadly covers the use of personal information data to implement one or more of the various disclosed embodiments, it also contemplates that various embodiments can be implemented without access to such personal information data. That is, various embodiments of the present invention will not become inoperable due to the absence of all or part of such personal information data. For example, content can be selected and delivered to the user based on aggregated non-personal information data or an absolute minimum amount of personal information, such as content processed solely on the user's device or other non-personal information available for content delivery services.

[0073] It will be apparent to those skilled in the art that various modifications can be made to this disclosure without departing from its spirit or scope. Therefore, this disclosure is intended to cover modifications and variations thereof, provided they fall within the scope of the appended claims and their equivalents.

Claims

1. An apparatus comprising processing circuitry configured to: process an indication of a wireless communication device with which the apparatus is permitted to perform a find location operation, wherein the indication comprises a first identity resolution key (IRK) unique to the wireless communication device; process a payload of an announcement comprising an IRK; and compare the IRK to the first IRK received by an always-on processor.

2. The apparatus of claim 1, wherein the processing circuitry is further configured to: ignore the announcement when the IRK does not match the first IRK.

3. The apparatus of claim 1, wherein the processing circuitry is further configured to: send a message to an application processor indicating that the wireless communication device has been identified in a find location operation when the IRK matches the first IRK.

4. The apparatus of claim 1, wherein the processing circuitry is further configured to: process the first IRK based on signaling received from a Bluetooth controller.

5. The apparatus of claim 4, wherein the payload of the announcement is received from the Bluetooth controller.

6. The apparatus of claim 1, wherein the payload of the announcement is encrypted based on the IRK and a Bluetooth address of a device that sent the announcement.

7. The apparatus of claim 6, wherein the processing circuitry is further configured to: decrypt the payload using the first IRK and a Bluetooth address of the wireless communication device.

8. The apparatus of claim 6, wherein the payload of the announcement is encrypted using a SipHash function.

9. The apparatus of claim 1, wherein the processing circuitry comprises an always-on processor.

10. A method comprising: receiving an indication of a wireless communication device permitted to perform a find location operation, wherein the indication comprises a first identity resolution key (IRK) unique to the wireless communication device; receiving a payload of an announcement comprising an IRK; and comparing the IRK to the first IRK.

11. The method of claim 10, further comprising: ignoring the announcement when the IRK does not match the first IRK.

12. The method of claim 10, further comprising: sending a message to an application processor indicating that the wireless communication device has been identified in a find location operation when the IRK matches the first IRK.

13. The method of claim 10, further comprising: receiving the first IRK from a Bluetooth controller.

14. The method of claim 13, wherein the payload of the announcement is received from the Bluetooth controller.

15. The method of claim 10, wherein the payload of the announcement is encrypted based on the IRK and a Bluetooth address of a device that sent the announcement.

16. The method of claim 15, further comprising: decrypt the payload using the first IRK and a Bluetooth address of the wireless communication device.

17. The method of claim 16, wherein the payload of the announcement is encrypted using a SipHash function.

18. The method of claim 10, wherein the method is performed by an always-on processor.

19. A first wireless communication device, the first wireless communication device comprising: a transceiver configured to communicate with a second wireless communication device; and an always-on processor configured to: process an indication of the second wireless communication device that is permitted to perform a find location operation with the first wireless communication device, wherein the indication includes a first identity resolution key (IRK) that is unique to the second wireless communication device; process a payload of an announcement that includes an IRK; and compare the IRK to the first IRK received by the always-on processor.

20. The first wireless communication device of claim 19, wherein the always-on processor is further configured to: ignore the announcement when the IRK does not match the first IRK; and send a message to an application processor of the first wireless communication device indicating that the second wireless communication device has been identified in a find location operation when the IRK matches the first IRK.

Images