Equipment unbinding method, equipment and storage medium

Abstract

The embodiment of the invention provides a device unbinding method, a device and a storage medium. The method comprises the following steps: in response to a service discovery request sent by a second terminal device, sending authentication request information to the second terminal device; wherein the authentication request information comprises an authentication challenge code; receiving authentication response data generated by the second terminal device according to the authentication challenge code; wherein the authentication response data at least comprises equipment identification information of the second terminal equipment; if it is determined that the second terminal equipment is unbound to-be-processed equipment according to the equipment identification information, generating a first authentication result; wherein the first authentication result comprises a first status code; the first state code is used for representing that the first terminal equipment and the second terminal equipment are unbound offline; and sending the first authentication result to the second terminal device, so that the second terminal device is unbound with the first terminal device according to the first authentication result. According to the method, the accuracy, safety and reliability of synchronization of the unbinding state of the equipment can be improved.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a device unbinding method, device, and storage medium. Background Technology

[0002] Bluetooth Low Energy (BLE) technology has become the preferred communication method for IoT, wearables, smart homes, and automotive scenarios due to its advantages such as ultra-low power consumption, low cost, native device support, and fast connection speed.

[0003] Currently, when unbinding terminal devices, one terminal device (e.g., an in-vehicle terminal) typically triggers a depairing command and checks if the other device is online. If the other device is detected as online, a depairing command is sent to that device to complete the device unbinding.

[0004] If the peer device is offline (or out of communication range), it will not be able to detect that the binding relationship has been broken, resulting in inconsistent unbinding states between the two devices. In this case, when the peer device approaches one of the terminal devices, authentication fails due to the use of expired credentials, preventing pairing. The peer device may then repeatedly attempt to reconnect, wasting resources, impacting communication efficiency, and degrading the user experience. Furthermore, during the period between successful Bluetooth connection and authentication failure, the connection status in the peer device's application interface initially displays "connected" and then randomly changes to "not connected," causing screen flickering. Summary of the Invention

[0005] This application provides a device unbinding method, device, and storage medium, which can improve the accuracy, security, and reliability of device unbinding status synchronization.

[0006] In a first aspect, embodiments of this application provide a device unbinding method, applied to a first terminal device, the method comprising:

[0007] In response to a service discovery request sent by a second terminal device, an authentication request information is sent to the second terminal device; wherein, the authentication request information includes an authentication challenge code;

[0008] The system receives authentication response data generated by the second terminal device based on the authentication challenge code; wherein the authentication response data includes at least the device identification information of the second terminal device.

[0009] If the second terminal device is determined to be the device to be unbound based on the device identification information, a first authentication result is generated; wherein, the first authentication result includes a first status code; the first status code is used to indicate that the first terminal device has been unbound offline from the second terminal device;

[0010] The first authentication result is sent to the second terminal device so that the second terminal device can unbind from the first terminal device based on the first authentication result.

[0011] In one possible implementation, determining the second terminal device as the device to be unbound based on the device identification information includes:

[0012] Obtain a list of devices to be processed; wherein, the list of devices to be processed includes device identification information of terminal devices that have been unbound offline by the first terminal device;

[0013] If the device identification information of the second terminal device is determined to be included in the list of devices to be processed, then the second terminal device is determined to be the device to be unbound.

[0014] In one possible implementation, prior to responding to a service discovery request sent by a second terminal device, the method further includes:

[0015] In response to the device unbinding command, the binding record of the terminal device to be unbound as indicated by the device unbinding command is deleted from the local device registry of the first terminal device;

[0016] The device identification information of the terminal device to be unbound as instructed by the device unbinding command is stored in the list of devices to be processed.

[0017] In one possible implementation, after sending the first authentication result to the second terminal device, the method further includes:

[0018] Delete the device identifier information of the second terminal device included in the list of devices to be processed to obtain a new list of devices to be processed.

[0019] In one possible implementation, the number of the second terminal devices is multiple, and the method further includes:

[0020] Based on the device type of each second terminal device, determine the unbinding priority of multiple second terminal devices;

[0021] According to the unbinding priority, the first authentication result is sent to the corresponding second terminal device in sequence.

[0022] In one possible implementation, after sending the first authentication result to the second terminal device, the method further includes:

[0023] Determine the signal strength information of the communication connection between the first terminal device and the second terminal device;

[0024] Based on the signal strength information, determine the disconnection delay time;

[0025] Based on the disconnection delay time, the communication connection with the second terminal device is disconnected.

[0026] Secondly, embodiments of this application provide a device unbinding method, applied to a second terminal device, the method comprising:

[0027] Receive a first authentication result sent by a first terminal device; wherein the first authentication result includes a first status code; the first status code is used to indicate that the first terminal device has been unbound offline from the second terminal device;

[0028] Based on the first authentication result, delete the binding record with the first terminal device from the local device registry of the second terminal device, and disconnect the communication connection with the first terminal device;

[0029] The connection status between the device and the first terminal device is determined to be unconnected based on the objective function, and the unconnected status is sent to the display interface of the second terminal device.

[0030] In one possible implementation, before receiving the first authentication result sent by the first terminal device, the method further includes:

[0031] After detecting that it has entered the communication range of the first terminal device, it initiates a communication connection request with the first terminal device and establishes a communication connection with the first terminal device.

[0032] Send a service discovery request to the first terminal device and prohibit the distribution of connection status callback data;

[0033] Receive authentication request information sent by the first terminal device; wherein the authentication request information includes an authentication challenge code;

[0034] Based on the authentication challenge code, authentication response data is generated and sent to the first terminal device.

[0035] Thirdly, embodiments of this application provide a device unbinding device, applied to a first terminal device, the device comprising:

[0036] An authentication unit is configured to send authentication request information to the second terminal device in response to a service discovery request sent by the second terminal device; wherein the authentication request information includes an authentication challenge code;

[0037] The first receiving unit is configured to receive authentication response data generated by the second terminal device based on the authentication challenge code; wherein the authentication response data includes at least the device identification information of the second terminal device;

[0038] The determining unit is configured to generate a first authentication result if the second terminal device is determined to be an unbinding device based on the device identification information; wherein the first authentication result includes a first status code; the first status code is used to indicate that the first terminal device has been unbound offline from the second terminal device;

[0039] The sending unit is configured to send the first authentication result to the second terminal device, so that the second terminal device can unbind itself from the first terminal device based on the first authentication result.

[0040] In one possible implementation, the determining unit is used for:

[0041] Obtain a list of devices to be processed; wherein, the list of devices to be processed includes device identification information of terminal devices that have been unbound offline by the first terminal device;

[0042] If the device identification information of the second terminal device is determined to be included in the list of devices to be processed, then the second terminal device is determined to be the device to be unbound.

[0043] In one possible implementation, prior to responding to a service discovery request sent by the second terminal device, the device is further configured to:

[0044] In response to the device unbinding command, the binding record of the terminal device to be unbound as indicated by the device unbinding command is deleted from the local device registry of the first terminal device;

[0045] The device identification information of the terminal device to be unbound as instructed by the device unbinding command is stored in the list of devices to be processed.

[0046] In one possible implementation, after sending the first authentication result to the second terminal device, the device is further configured to:

[0047] Delete the device identifier information of the second terminal device included in the list of devices to be processed to obtain a new list of devices to be processed.

[0048] In one possible implementation, the number of the second terminal devices is multiple, and the device is further used for:

[0049] Based on the device type of each second terminal device, determine the unbinding priority of multiple second terminal devices;

[0050] According to the unbinding priority, the first authentication result is sent to the corresponding second terminal device in sequence.

[0051] In one possible implementation, after sending the first authentication result to the second terminal device, the device is further configured to:

[0052] Determine the signal strength information of the communication connection between the first terminal device and the second terminal device;

[0053] Based on the signal strength information, determine the disconnection delay time;

[0054] Based on the disconnection delay time, the communication connection with the second terminal device is disconnected.

[0055] Fourthly, embodiments of this application provide a device unbinding device applied to a second terminal device, the device comprising:

[0056] The second receiving unit is configured to receive a first authentication result sent by the first terminal device; wherein the first authentication result includes a first status code; the first status code is used to indicate that the first terminal device has been unbound offline from the second terminal device;

[0057] The unbinding unit is used to delete the binding record with the first terminal device from the local device registry of the second terminal device according to the first authentication result, and disconnect the communication connection with the first terminal device.

[0058] The display unit is used to determine the connection status between the device and the first terminal device as an unconnected state based on the objective function, and to send the unconnected state to the display interface of the second terminal device.

[0059] In one possible implementation, before receiving the first authentication result sent by the first terminal device, the device is further configured to:

[0060] After detecting that it has entered the communication range of the first terminal device, it initiates a communication connection request with the first terminal device and establishes a communication connection with the first terminal device.

[0061] Send a service discovery request to the first terminal device and prohibit the distribution of connection status callback data;

[0062] Receive authentication request information sent by the first terminal device; wherein the authentication request information includes an authentication challenge code;

[0063] Based on the authentication challenge code, authentication response data is generated and sent to the first terminal device.

[0064] Fifthly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0065] The memory stores computer-executed instructions;

[0066] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above, or to perform the second aspect and / or various possible implementations of the second aspect as described above.

[0067] In a sixth aspect, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect, or to implement the second aspect and / or various possible implementations of the second aspect.

[0068] In a seventh aspect, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect, or implements the second aspect and / or various possible implementations of the second aspect.

[0069] The device unbinding method, device, and storage medium provided in this application can determine the matching authentication result instruction by determining whether the second terminal device is a device to be unbound during the authentication response phase between the second terminal device and the first terminal device. For example, if the second terminal device is determined to be a device to be unbound, a first authentication result is generated to represent that the first terminal device has been unbound offline from the second terminal device, and the first authentication result is sent to the second terminal device so that the second terminal device can unbind from the first terminal device according to the first authentication result. This implementation can extend the status code included in the authentication result instruction through an unbinding status carrying mechanism based on the extended authentication protocol, thereby intercepting invalid connection operations before the service connection is established. This enables device unbinding status synchronization at the protocol level without modifying the upper-layer business logic, and also avoids repeated reconnection by the second terminal device, saving resources and reducing energy consumption. At the same time, this implementation relies on Bluetooth short-range communication to achieve device unbinding status synchronization without relying on the network and cloud, improving the security and reliability of device unbinding status synchronization. Attached Figure Description

[0070] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0071] Figure 1A flowchart illustrating a device unbinding method applied to a first terminal device, provided as an embodiment of this application;

[0072] Figure 2 A flowchart illustrating a device unbinding method applied to a second terminal device, provided as an embodiment of this application;

[0073] Figure 3 A schematic diagram illustrating the implementation process of a device unbinding method provided in this application embodiment;

[0074] Figure 4 A schematic diagram of a device unbinding device applied to a first terminal device provided in an embodiment of this application;

[0075] Figure 5 A schematic diagram of a device unbinding device applied to a second terminal device provided in an embodiment of this application;

[0076] Figure 6 This is a schematic diagram of a device unbinding system provided in an embodiment of this application;

[0077] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0078] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0079] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0080] The term "and / or" in this article merely describes a relationship, indicating that three relationships can exist. For example, A and / or B can represent three cases: A exists alone, A and B exist simultaneously, and B exists alone.

[0081] In addition, the term "at least one" in this document means any combination of at least two of any one or more of a plurality of elements, such as including at least one of A, B, and C, and may mean including any one or more elements selected from the set consisting of A, B, and C.

[0082] BLE technology, with its advantages of ultra-low power consumption, low cost, native device support, and fast connection speed, has become the preferred communication method in IoT, wearable, smart home, and automotive scenarios.

[0083] Currently, when unbinding terminal devices, one terminal device (e.g., an in-vehicle terminal) typically triggers a depairing command and checks if the other device is online. If the other device is detected as online, a depairing command is sent to that device to complete the device unbinding.

[0084] If the peer device is offline (or out of communication range), it will not be able to detect that the binding relationship has been broken, resulting in inconsistent unbinding states between the two devices. In this case, when the peer device approaches one of the terminal devices, authentication fails due to the use of expired credentials, preventing pairing. The peer device may then repeatedly attempt to reconnect, wasting resources, impacting communication efficiency, and degrading the user experience. Furthermore, during the period between successful Bluetooth connection and authentication failure, the connection status in the peer device's application interface initially displays "connected" and then randomly changes to "not connected," causing screen flickering.

[0085] At this point, the other device cannot automatically clear the locally invalid binding credentials. It is usually necessary to manually "ignore this device" in the Bluetooth settings to unbind the other terminal device, which is cumbersome and inefficient.

[0086] In related technologies, cloud servers can be used to unbind devices, thereby ensuring the consistency of the states of both terminal devices. This implementation relies on the reliability and security of the network environment. When the server malfunctions, the network is down, or there are network security issues, there may be problems such as the inability to issue unbinding commands or the commands being tampered with, thus affecting the timeliness, security, and reliability of device unbinding.

[0087] The device unbinding method provided in this application can identify whether the peer device has been unbound offline by extending the authentication result command to carry the binding status during the Bluetooth connection authentication handshake phase. When it is detected that the peer device has been unbound offline, it can directly notify the peer device to silently clear its credentials at the underlying protocol level without triggering the connection callback of the upper-layer business. At this time, on the one hand, it can solve the problem of inconsistent unbinding status at the protocol level without relying on the cloud or network status. On the other hand, it can eliminate the problem of false connection flickering by blocking the upper-layer UI (User Interface) notification, thereby achieving unbinding status synchronization without the user's awareness.

[0088] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0089] Figure 1 This application provides a schematic flowchart of a device unbinding method applied to a first terminal device, as illustrated in the embodiments of this application. Figure 1 As shown, the method includes:

[0090] S101. In response to the service discovery request sent by the second terminal device, send authentication request information to the second terminal device; wherein, the authentication request information includes an authentication challenge code.

[0091] In the embodiments of this application, the first terminal device can be used to represent the terminal device that has been unbound offline, and the second terminal device can be used to represent the terminal device that has been unbound offline, that is, the terminal device that needs to be synchronized with the unbound status.

[0092] For example, in a BLE communication scenario between an in-vehicle terminal and a mobile terminal, if the in-vehicle terminal needs to unbind a mobile terminal, but the mobile terminal is currently not within the communication range, the in-vehicle terminal can be used as the first terminal device in this application embodiment, and the mobile terminal can be used as the second terminal device in this application embodiment. The device unbinding method provided in this application embodiment can then be used to unbind the devices.

[0093] In one example, the authentication request information may include an authentication challenge code. This authentication challenge code may indicate a random challenge code, for example, by using a generated random number as the authentication challenge code.

[0094] Optionally, to ensure the reliability and security of the authentication challenge code, the authentication challenge code may also include, but is not limited to, timestamps and session IDs.

[0095] S102. Receive authentication response data generated by the second terminal device based on the authentication challenge code; wherein the authentication response data includes at least the device identification information of the second terminal device.

[0096] In one example, authentication response data can be understood as data generated by the second terminal device after encrypting the authentication challenge code and identity authentication information (e.g., device identification information and timestamp) using a locally stored key.

[0097] In one example, after receiving the authentication response data, the first terminal device can first decrypt the authentication response data and verify the validity of the authentication response data based on the authentication challenge code (or the authentication challenge code and the timestamp).

[0098] After confirming that the authentication response data is valid, the device identification information of the mobile terminal can be extracted from the authentication response data.

[0099] S103. If the second terminal device is determined to be the device to be unbound based on the device identification information, a first authentication result is generated; wherein the first authentication result includes a first status code; the first status code is used to indicate that the first terminal device has been unbound offline from the second terminal device.

[0100] S104. Send the first authentication result to the second terminal device so that the second terminal device can unbind from the first terminal device based on the first authentication result.

[0101] As described above, in this embodiment, the first terminal device can determine the matching authentication result instruction by determining whether the second terminal device is a device to be unbound during the authentication response phase with it. For example, if the second terminal device is determined to be a device to be unbound, a first authentication result is generated, including a first status code indicating that the first terminal device has been unbound offline from the second terminal device, and the first authentication result is sent to the second terminal device so that the second terminal device can unbind from the first terminal device according to the first authentication result. This implementation can extend the status code included in the authentication result instruction through an unbinding status carrying mechanism based on the extended authentication protocol, thereby intercepting invalid connection operations before the service connection is established. This enables device unbinding status synchronization at the protocol level without modifying the upper-layer business logic, and also avoids the second terminal device repeatedly reconnecting, saving resources and reducing energy consumption. At the same time, this implementation relies on Bluetooth short-range communication to achieve device unbinding status synchronization without relying on the network and cloud, improving the security and reliability of device unbinding status synchronization.

[0102] In one possible implementation, after the first terminal device sends the first authentication result to the second terminal device, the embodiments of this application may further determine the signal strength information of the communication connection between the first terminal device and the second terminal device; then, based on the signal strength information, determine the disconnection delay time; and finally, based on the disconnection delay time, disconnect the communication connection with the second terminal device.

[0103] In one example, the stability of the communication environment between the first terminal device and the second terminal device can be determined based on signal strength information.

[0104] At this point, the disconnection delay time can be flexibly adjusted based on the signal strength information, ensuring that the first authentication result can be completely sent to the second terminal device, thereby ensuring that the second terminal device can complete the unbinding process from the first terminal device and improving the reliability of device unbinding status synchronization.

[0105] For example, if the signal strength information is greater than the first strength value, it indicates that the communication environment is stable. In this case, a shorter disconnection delay time can be determined, such as 100ms. If the signal strength information is greater than the second strength value and less than or equal to the first strength value, it indicates that the communication environment is normal. In this case, a normal disconnection delay time can be determined, such as 300ms. If the signal strength information is less than or equal to the second strength value, it indicates that the communication environment is unstable. In this case, a longer disconnection delay time can be determined, such as 500ms.

[0106] In one possible implementation, if the second terminal device is determined not to be the device to be unbound based on the device identification information, and the authentication response data is authenticated successfully, a second authentication result can be generated. The second authentication result may include a second status code, which indicates that the second terminal device has been successfully authenticated.

[0107] In one example, after the second authentication result is sent to the second terminal device, the second terminal device can trigger the onConnected callback. At this time, the UI of the second terminal device displays the connection status, and then the normal communication process can begin.

[0108] In one possible implementation, if the second terminal device is determined not to be the device to be unbound based on the device identification information, and the authentication response data authentication fails, a third authentication result can be generated. This third authentication result may include a third status code, which indicates that the second terminal device authentication failed.

[0109] In one example, after the third authentication result is sent to the second terminal device, the second terminal device can trigger the onDisconnected callback. At this time, the UI of the second terminal device displays a disconnected state, and then an automatic reconnection mechanism can be implemented.

[0110] As described above, the embodiments of this application can extend the authentication result instruction by expanding its status code to include: a first status code, a second status code, and a third status code. The first status code indicates offline unbinding; the second status code indicates successful authentication; and the third status code indicates authentication failure.

[0111] Optionally, the first, second, and third status codes can be preset with specific values. For example, the first status code can be set to 0x02, the second status code to 0x01, and the third status code to 0x00, etc. The specific content of the values ​​corresponding to each status code is not limited here; the implementation is the only requirement.

[0112] At this point, existing authentication result commands can be reused without adding new protocol commands, ensuring good compatibility without affecting the normal authentication process.

[0113] The device unbinding method provided in this application embodiment is described below from the perspective of the second terminal device. See also Figure 2 , Figure 2 This application provides a schematic flowchart of a device unbinding method for a second terminal device, as illustrated in the embodiments of this application. Figure 2 As shown, the method includes:

[0114] S201. Receive the first authentication result sent by the first terminal device; wherein the first authentication result includes a first status code; the first status code is used to indicate that the first terminal device has been unbound offline from the second terminal device.

[0115] S202. Based on the first authentication result, delete the binding record with the first terminal device from the local device registry of the second terminal device, and disconnect the communication connection with the first terminal device.

[0116] In one example, disconnecting the communication connection with the first terminal device may include, but is not limited to, two steps: clearing the GATT (Generic Attribute Profile) reference and disconnecting the physical link.

[0117] Optionally, you can clear the GATT reference by setting it to null, causing the isConnected() function to immediately return false. The isConnected() function determines the device connection status; false indicates the device is not connected. In this case, the isConnected() function can be used to promptly and proactively report the connection status between the second and first terminal devices as not connected.

[0118] Optionally, the physical link between the second terminal device and the first terminal device can be disconnected by calling the `gatt.disconnect()` and `gatt.close()` functions. The `gatt.disconnect()` function can be used to disconnect the current GATT connection, and the `gatt.close()` function can be used to release GATT resources.

[0119] Optionally, before deleting the binding record with the first terminal device from the local device registry in the second terminal device based on the first authentication result, this embodiment of the application may also set a silent disconnection flag, for example, silentDisconnect=true. In this case, setting the silent disconnection flag can indicate that the second terminal device is performing a silent cleanup / silent unbinding process, thereby helping to achieve seamless unbinding of the user by the second terminal device.

[0120] S203. Determine the connection status between the device and the first terminal device as unconnected based on the objective function, and send the unconnected status to the display interface of the second terminal device.

[0121] In one example, the target function can be used to indicate the function that is actively triggered. For example, the target function could be the `isConnected()` function mentioned above. In this case, `isConnected()` can return false to determine that the connection status is not connected, and this disconnected status can be sent to the display interface (UI) of the second terminal device. The UI can then display the disconnected status. By actively triggering the function, rather than passively triggering the display of the device's connection status through a callback function, the accuracy and stability of the connection status display can be guaranteed, thus eliminating the problem of connection status jumps / flickers in the display interface.

[0122] Furthermore, in order to block disconnection notifications from the second terminal interface and achieve seamless unbinding of the second terminal device from the user, the silentDisconnect flag can be checked in the onConnectionStateChange callback. If it is true, the onDisconnected callback will not be triggered.

[0123] In one possible implementation, the second terminal device may also retain a scan cache, for example, retaining the first terminal device in the scannedDevices collection, thereby preventing the second terminal device from repeatedly triggering the device discovery callback.

[0124] In one possible implementation, after the second terminal device completes the device unbinding based on the first authentication result, the state machine in the second terminal device is restored to the unbound state, thus completing the synchronization of the unbinding state between the first terminal device and the second terminal device.

[0125] As described above, in this embodiment, the second terminal device can receive a first authentication result sent by the first terminal device, including a first status code indicating that the first terminal device has been unbound from the second terminal device offline. Based on the first authentication result, the second terminal device deletes the binding record with the first terminal device from its local device registry and disconnects the communication connection with the first terminal device. This allows the second terminal device to unbind from the first terminal device during the authentication response phase, avoiding the resource waste caused by repeated reconnections after authentication failure. Subsequently, the connection status with the first terminal device is determined to be disconnected according to the objective function, and this disconnected status is sent to the display interface of the second terminal device. This implementation method can promptly and accurately send the disconnected status to the display interface of the second terminal device through the objective function, not only promptly reminding the user that the second terminal device is not connected to the first terminal device, but also avoiding changes in the connection status.

[0126] Figure 3 This is a schematic diagram illustrating the implementation process of a device unbinding method provided in this application embodiment. This embodiment... Figure 1 and Figure 2 Based on the embodiments, and in conjunction with the interactive communication process between the first terminal device and the second terminal device, the device unbinding method provided in this application embodiment will be described in detail, such as... Figure 3 As shown, the method includes the following steps:

[0127] Step 1: In response to the device unbinding command, the first terminal device deletes the binding record of the terminal device to be unbound as indicated by the device unbinding command from the local device registry of the first terminal device.

[0128] Step 2: Store the device identification information of the terminal device to be unbound as instructed by the device unbinding command into the list of devices to be processed.

[0129] In one example, the device identification information of the terminal devices that have been unbound offline can be persistently stored through a list of devices to be processed.

[0130] This implementation method ensures that the device identification information of the unbound terminal device is not lost when the first terminal device restarts, thereby supporting offline unbinding status synchronization at any time interval.

[0131] On the other hand, the embodiments of this application can also store the device identification information of multiple unbound terminal devices simultaneously through the list of devices to be processed, thereby supporting scenarios of batch unbinding of multiple devices and improving the robustness of the device unbinding method.

[0132] Step 3: After detecting that it has entered the communication range of the first terminal device, the second terminal device initiates a communication connection request with the first terminal device and establishes a communication connection with the first terminal device.

[0133] In one example, a communication connection request can be used to characterize a GATT connection request. In this case, the second terminal device can establish a physical link with the first terminal device by initiating a GATT connection request, thereby establishing a communication connection with the first terminal device.

[0134] Step 4: The second terminal device sends a service discovery request to the first terminal device and prohibits the distribution of connection status callback data.

[0135] In one example, connection status callback data can indicate onConnected callback data.

[0136] At this point, after the second terminal device sends a service discovery request to the first terminal device, the Service layer of the second terminal device does not distribute the onConnected callback data to the upper-layer UI or business logic. At this time, the UI of the second terminal device remains in the "not connected" state and waits for the authentication result.

[0137] This implementation prevents the problem of abnormal UI state transitions caused by displaying "connected" in the UI after the onConnected callback is dispatched, and then switching to "not connected" after authentication failure.

[0138] Step 5: In response to the service discovery request sent by the second terminal device, the first terminal device sends an authentication request information to the second terminal device; wherein, the authentication request information includes an authentication challenge code.

[0139] In one example, this step can be referred to the content described in S101 above, and will not be repeated in detail here.

[0140] Step 6: The second terminal device receives the authentication request information sent by the first terminal device and generates authentication response data based on the authentication challenge code.

[0141] In one example, the second terminal device can encrypt the authentication challenge code and identity authentication information (e.g., device identification information and timestamp) based on a locally stored key to generate authentication response data.

[0142] For example, the authentication response data can indicate encrypted data in the format deviceId:timestamp:nonce. Here, deviceId represents the device identification information, timestamp represents a timestamp, and nonce represents a random number / authentication challenge code.

[0143] Step 7: The second terminal device sends the authentication response data to the first terminal device.

[0144] Step 8: The first terminal device receives the authentication response data generated by the second terminal device based on the authentication challenge code; wherein the authentication response data includes at least the device identification information of the second terminal device.

[0145] In one example, this step can be referred to the content described in S102 above, and will not be repeated in detail here.

[0146] Step 9: The first terminal device obtains a list of devices to be processed; wherein, the list of devices to be processed includes the device identification information of terminal devices that the first terminal device has unbound offline.

[0147] In one example, the list of devices to be processed can be determined based on the content described in steps 1 to 2 above.

[0148] Step 10: If the first terminal device determines that the device identification information of the second terminal device is included in the list of devices to be processed, then the second terminal device is determined to be the device to be unbound.

[0149] Optionally, the device identification information of the second terminal device can be determined by calling the hasPendingOfflineUnbind(deviceId) method.

[0150] At this point, the list of devices to be processed can be used to easily, quickly, and accurately determine whether the second terminal device is a device to be unbound and processed. In other words, it can be quickly determined whether the second terminal device is a device whose unbound status is not synchronized.

[0151] Step 11: If the first terminal device determines that the second terminal device is the device to be unbound based on the device identification information, then the first authentication result is generated.

[0152] The first authentication result includes a first status code; the first status code is used to indicate that the first terminal device has been unbound from the second terminal device offline.

[0153] For example, the first status code can be the aforementioned specific value: 0x02.

[0154] Step 12: The first terminal device sends the first authentication result to the second terminal device so that the second terminal device can unbind from the first terminal device based on the first authentication result.

[0155] In one possible implementation, since the list of devices to be processed can support batch unbinding of multiple devices, when there are multiple second terminal devices, this embodiment of the application can determine the unbinding priority of multiple second terminal devices according to the device type of each second terminal device, and then send the first authentication result to the corresponding second terminal device in sequence according to the unbinding priority.

[0156] In one example, the device type of the second terminal device can indicate the product type corresponding to the second terminal device. For example, the device type of the second terminal device can be a mobile phone / Bluetooth key type, a Bluetooth headset type, or a Bluetooth watch type.

[0157] Alternatively, the device type of the second terminal device can also indicate the usage frequency type of the second terminal device. For example, the device type of the second terminal device can be high-frequency usage type, medium-frequency usage type, and low-frequency usage type, etc. Here, the device type of the second terminal device is not specifically limited, but is determined by what is feasible.

[0158] In one example, the first terminal device can maintain a device priority mapping table locally, recording the processing priority corresponding to each device type. Then, if there are multiple second terminal devices, this device priority mapping table can be queried to determine the processing priority of each second terminal device, thereby determining the unbinding priority.

[0159] This implementation prioritizes the synchronization of the unbinding status of critical terminal devices, avoiding invalid connection attempts by low-priority terminal devices that could interfere with the synchronization of the unbinding status of high-priority terminal devices.

[0160] Step 13: The first terminal device deletes the device identifier information of the second terminal device included in the list of devices to be processed, and obtains a new list of devices to be processed.

[0161] At this point, by promptly clearing the device identification information of the offline unbound terminal device stored locally in the first terminal device, strict synchronization of the unbound status between the first and second terminal devices can be ensured. This not only avoids the repeated transmission of the unbound status but also prevents it from affecting the next authentication response process.

[0162] Step 14: The first terminal device determines the signal strength information of the communication connection between the first terminal device and the second terminal device; based on the signal strength information, it determines the disconnection delay time; based on the disconnection delay time, it disconnects the communication connection with the second terminal device.

[0163] In one example, this step can be referred to the content described after S104 above, and will not be repeated in detail here.

[0164] Step 15: The second terminal device receives the first authentication result sent by the first terminal device.

[0165] The first authentication result includes a first status code; the first status code is used to indicate that the first terminal device has been unbound from the second terminal device offline.

[0166] Step 16: Based on the first authentication result, the second terminal device deletes the binding record with the first terminal device from the local device registry of the second terminal device and disconnects the communication connection with the first terminal device.

[0167] In one example, this step can be referred to the content described in S202 above, and will not be repeated in detail here.

[0168] Step 17: The second terminal device determines the connection status with the first terminal device to be unconnected based on the objective function, and sends the unconnected status to the display interface of the second terminal device.

[0169] In one example, this step can be referred to the content described in S203 above, and will not be repeated in detail here.

[0170] Figure 4 This application provides a schematic diagram of the structure of a device unbinding device applied to a first terminal device, as shown in the embodiment of the present application. Figure 4 As shown, the device unbinding device 40 provided in this embodiment includes:

[0171] The authentication unit 401 is used to send authentication request information to the second terminal device in response to a service discovery request sent by the second terminal device; wherein the authentication request information includes an authentication challenge code.

[0172] The first receiving unit 402 is used to receive authentication response data generated by the second terminal device based on the authentication challenge code; wherein the authentication response data includes at least the device identification information of the second terminal device.

[0173] The determining unit 403 is used to generate a first authentication result if the second terminal device is determined to be the device to be unbound based on the device identification information; wherein the first authentication result includes a first status code; the first status code is used to indicate that the first terminal device has been unbound offline from the second terminal device.

[0174] The sending unit 404 is used to send the first authentication result to the second terminal device so that the second terminal device can unbind from the first terminal device according to the first authentication result.

[0175] In one possible implementation, the determining unit 403 is configured to:

[0176] Obtain the list of devices to be processed; the list of devices to be processed includes the device identification information of the terminal devices that were unbound offline by the first terminal device;

[0177] If the device identifier information of the second terminal device is found in the list of devices to be processed, then the second terminal device is determined to be the device to be unbound.

[0178] In one possible implementation, prior to responding to a service discovery request sent by the second terminal device, the device is further configured to:

[0179] In response to the device unbinding command, delete the binding record of the terminal device to be unbound as indicated by the device unbinding command from the local device registry of the first terminal device;

[0180] The device identification information of the terminal device to be unbound as instructed by the device unbinding command is stored in the list of devices to be processed.

[0181] In one possible implementation, after sending the first authentication result to the second terminal device, the device is further configured to:

[0182] Delete the device identifier information of the second terminal device included in the list of devices to be processed, and obtain a new list of devices to be processed.

[0183] In one possible implementation, the number of second terminal devices is multiple, and the device is further used for:

[0184] Determine the unbinding priority of multiple second terminal devices based on the device type of each second terminal device;

[0185] Based on the unbinding priority, the first authentication result is sent to the corresponding second terminal device in sequence.

[0186] In one possible implementation, after sending the first authentication result to the second terminal device, the device is further configured to:

[0187] Determine the signal strength information of the communication connection between the first terminal device and the second terminal device;

[0188] Determine the disconnection delay time based on the signal strength information;

[0189] Based on the disconnection delay time, the communication connection with the second terminal device is disconnected.

[0190] Figure 5 This application provides a schematic diagram of the structure of a device unbinding device applied to a second terminal device, as shown in the embodiment of the present application. Figure 5 As shown, the device unbinding device 50 provided in this embodiment includes:

[0191] The second receiving unit 501 is used to receive the first authentication result sent by the first terminal device; wherein the first authentication result includes a first status code; the first status code is used to indicate that the first terminal device has been unbound offline from the second terminal device.

[0192] The unbinding unit 502 is used to delete the binding record with the first terminal device from the local device registry of the second terminal device according to the first authentication result, and disconnect the communication connection with the first terminal device.

[0193] Display unit 503 is used to determine the connection status between the device and the first terminal device as unconnected based on the objective function, and to send the unconnected status to the display interface of the second terminal device.

[0194] In one possible implementation, before receiving the first authentication result sent by the first terminal device, the device is further configured to:

[0195] After detecting that it has entered the communication range of the first terminal device, it initiates a communication connection request with the first terminal device and establishes a communication connection with the first terminal device.

[0196] Send a service discovery request to the first terminal device and prohibit the distribution of connection state callback data;

[0197] Receive authentication request information sent by the first terminal device; wherein, the authentication request information includes an authentication challenge code;

[0198] Based on the authentication challenge code, generate authentication response data and send the authentication response data to the first terminal device.

[0199] The device unbinding device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0200] Figure 6 This is a schematic diagram of a device unbinding system provided in an embodiment of this application, as shown below. Figure 6 As shown, the device unbinding system includes a first terminal device and a second terminal device, wherein the first terminal device may include... Figure 4 The device unbinding device 40 shown may include the second terminal device. Figure 5 The device unbinding device 50 shown above enables the unbinding of the device according to the method described in the above-described method embodiment.

[0201] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 7As shown, the electronic device 70 provided in this embodiment includes at least one processor 701 and a memory 702. Optionally, the electronic device 70 further includes a communication component 703. The processor 701, memory 702, and communication component 703 are connected via a bus 704.

[0202] In a specific implementation, at least one processor 701 executes computer execution instructions stored in memory 702, causing at least one processor 701 to perform the above-described method.

[0203] The specific implementation process of processor 701 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0204] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0205] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0206] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0207] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0208] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0209] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0210] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0211] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0212] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0213] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0214] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause an electronic device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0215] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0216] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A method for unbinding a device, characterized in that, Applied to a first terminal device, the method includes: In response to a service discovery request sent by a second terminal device, an authentication request information is sent to the second terminal device; wherein, the authentication request information includes an authentication challenge code; The system receives authentication response data generated by the second terminal device based on the authentication challenge code; wherein the authentication response data includes at least the device identification information of the second terminal device. If the second terminal device is determined to be the device to be unbound based on the device identification information, a first authentication result is generated; wherein, the first authentication result includes a first status code; the first status code is used to indicate that the first terminal device has been unbound offline from the second terminal device; The first authentication result is sent to the second terminal device so that the second terminal device can unbind from the first terminal device based on the first authentication result.

2. The method according to claim 1, characterized in that, Based on the device identification information, the second terminal device is determined to be the device to be unbound, including: Obtain a list of devices to be processed; wherein, the list of devices to be processed includes device identification information of terminal devices that have been unbound offline by the first terminal device; If the device identification information of the second terminal device is determined to be included in the list of devices to be processed, then the second terminal device is determined to be the device to be unbound.

3. The method according to claim 2, characterized in that, Prior to responding to a service discovery request sent by a second terminal device, the method further includes: In response to the device unbinding command, the binding record of the terminal device to be unbound as indicated by the device unbinding command is deleted from the local device registry of the first terminal device; The device identification information of the terminal device to be unbound as instructed by the device unbinding command is stored in the list of devices to be processed.

4. The method according to claim 2, characterized in that, After sending the first authentication result to the second terminal device, the method further includes: Delete the device identifier information of the second terminal device included in the list of devices to be processed to obtain a new list of devices to be processed.

5. The method according to any one of claims 1-4, characterized in that, The number of the second terminal devices is multiple, and the method further includes: Based on the device type of each second terminal device, determine the unbinding priority of multiple second terminal devices; According to the unbinding priority, the first authentication result is sent to the corresponding second terminal device in sequence.

6. The method according to any one of claims 1-4, characterized in that, After sending the first authentication result to the second terminal device, the method further includes: Determine the signal strength information of the communication connection between the first terminal device and the second terminal device; Based on the signal strength information, determine the disconnection delay time; Based on the disconnection delay time, the communication connection with the second terminal device is disconnected.

7. A method for unbinding a device, characterized in that, Applied to a second terminal device, the method includes: Receive a first authentication result sent by a first terminal device; wherein the first authentication result includes a first status code; the first status code is used to indicate that the first terminal device has been unbound offline from the second terminal device; Based on the first authentication result, delete the binding record with the first terminal device from the local device registry of the second terminal device, and disconnect the communication connection with the first terminal device; The connection status between the device and the first terminal device is determined to be unconnected based on the objective function, and the unconnected status is sent to the display interface of the second terminal device.

8. The method according to claim 7, characterized in that, Before receiving the first authentication result sent by the first terminal device, the method further includes: After detecting that it has entered the communication range of the first terminal device, it initiates a communication connection request with the first terminal device and establishes a communication connection with the first terminal device. Send a service discovery request to the first terminal device and prohibit the distribution of connection status callback data; Receive authentication request information sent by the first terminal device; wherein the authentication request information includes an authentication challenge code; Based on the authentication challenge code, authentication response data is generated and sent to the first terminal device.

9. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-8.

Images