This is accomplished by using a combination of an application running on the target iOS device and the external BTLE device. When the initial pairing is completed, the pairing/bonding keys and all relevant information is transmitted from the external BTLE device to the application running on the iOS device. This information is then stored locally and/or on a remote server.
From this point forward, the iOS application has all the information required to force a different external BTLE device to “mimic” the BTLE device with which the iOS device was originally paired. In this way, the iOS device believes that the BTLE external device with which it is currently communicating is the “original” device with which it established a Bluetooth pairing—allowing the iOS device and ANCS service to function correctly without requiring a new Bluetooth pairing.
Here is an example of how this is implemented in a DriveID component, as described in the above referenced patents and patent application incorporated by reference:
1. A BTLE module is installed in or otherwise built into the DriveID component;
2. A system application is installed and running on the target iOS device;
3. The target iOS device and the DriveID component begin a pairing sequence;
4. Once the pairing is complete, the DriveID component sends the pairing keys, MAC address, and all relevant information to the iOS application, which is then stored (either on the iOS device or a remote server in communication with or otherwise accessible by the iOS device);
5. The target iOS device can then be carried and used in a new vehicle and communicates with a new DriveID component that is unique to or associated with the new vehicle;