Binding method, device and system, and intelligent terminal

Abstract

The application relates to the technical field of intelligent device binding, further relates to a binding method, device and system, and an intelligent terminal. The method comprises the following steps: sending device proof of a second device to a cloud end for verification, and receiving a binding token issued by the cloud end after the verification is passed; when the signal quality of a current network is less than a preset threshold, determining a target sending time according to a current time, a current sending frequency and a backoff parameter; sending the binding token to the cloud end for verification according to the target sending time; repeatedly performing the steps of determining the target sending time and sending the binding token until the cloud end receives the binding token; and when the binding token verification is passed, the first device is successfully bound with the second device. The method enables the first device and the second device to efficiently complete the binding, and improves the binding efficiency of the first device and the second device.

Description

Technical Field

[0001] This application relates to the field of smart device binding technology, and further to a binding method, apparatus and system, and smart terminal. Background Technology

[0002] With the development of modern technology, various smart devices are becoming increasingly popular, such as smartphones, smart TVs, and smart home appliances. These devices usually need to establish a secure binding relationship through the network so that users can remotely control and manage them.

[0003] Currently, a common binding method involves one smart device obtaining a unique binding token and sending it to another smart device. Upon receiving the token, the receiving device accurately parses it and then sends the parsing result back. Through this series of interactive operations, the binding process between the two smart devices is completed.

[0004] However, in offline environments with no network signal, or in weak network scenarios with unstable connections and weak signal strength, this binding method has significant drawbacks. For example, the binding process may be forced to stop due to network fluctuations, greatly reducing binding efficiency. Summary of the Invention

[0005] To address the aforementioned technical problems, this application provides a binding method, apparatus, system, and smart terminal, which improves the binding efficiency of the first device and the second device.

[0006] Firstly, this application provides a binding method applied to a first working mode of a first device. The first working mode is used to bind the first device and a second device. The binding method includes: sending the device certificate of the second device to the cloud for verification, and receiving a binding token issued by the cloud after the verification is successful; when the signal quality of the current network is less than a preset threshold, determining a target transmission time based on the current time, the current number of transmissions, and backoff parameters; sending the binding token to the cloud for verification based on the target transmission time; repeating the steps of determining the target transmission time and sending the binding token until the cloud receives the binding token; and successfully binding with the second device after the binding token is verified.

[0007] The above binding method involves the first device receiving the binding token from the cloud and determining the target sending time based on network signal quality, number of transmissions, and backoff parameters. This avoids the binding process being interrupted due to network fluctuations and ensures that the binding token is accurately sent to the cloud for verification. The second device sends its device certificate to the first device before participating in the binding process. The cloud is responsible for verifying the device certificate, generating and sending the binding token, and performing the final verification of the binding token. This allows the first and second devices to complete the binding process efficiently, improving the binding efficiency between the two devices.

[0008] One implementation also includes: when the binding token expires and the current time is within the renewal window, renewing the binding token; and updating the binding token after successful renewal.

[0009] In one implementation, the method further includes: when sending a binding token to the cloud, simultaneously sending a binding request; the cloud is used to merge duplicate binding requests according to an idempotent key algorithm.

[0010] The above binding method, by combining the exponential backoff strategy with mechanisms such as binding token renewal and merging binding requests, can further ensure that the first and second devices automatically retry and resume binding in offline or weak network scenarios, or other abnormal scenarios, and avoid the problem of the binding process being forced to be interrupted due to network fluctuations, thereby further improving the binding efficiency of the first and second devices.

[0011] Secondly, this application also provides a binding method applied to a first working mode of a second device. The first working mode is used to bind the first device and the second device. The binding method includes: sending the device certificate of the second device to the first device; the first device is configured to: send the device certificate of the second device to the cloud for verification, and after successful verification, receive a binding token issued by the cloud; when the signal quality of the current network is less than a preset threshold, determine a target transmission time based on the current time, the current number of transmissions, and backoff parameters; send the binding token to the cloud for verification based on the target transmission time; repeat the steps of determining the target transmission time and sending the binding token until the cloud receives the binding token; when the binding token is successfully verified, the device is successfully bound to the first device.

[0012] In one implementation, the method further includes: receiving a random string sent by a first device, the random string being generated when the first device performs the target operation; signing the random string, device identifier, timestamp or counter, and random number based on the device's private key; and generating a device certificate based on the signature result and the random string.

[0013] The above binding method receives a random string sent by the first device and signs the random string, device identifier, timestamp or counter, and random number using the device's private key to generate a device certificate. This effectively ensures the uniqueness and security of the device's identity. This method of signing the random string, timestamp, or counter guarantees that each generated device certificate is unique, reducing the risk of reuse and ensuring the security of device authentication during the binding process. It also further improves the binding efficiency between the first and second devices.

[0014] In one implementation, the method further includes: comparing the privacy versions of the second device and the cloud; updating the privacy version of the second device when the privacy version of the second device is lower than the privacy version of the cloud and the difference is a mandatory clause; and updating the privacy version of the second device synchronously if the first device and the second device are successfully bound and the first device has updated its privacy version.

[0015] The above binding method involves version updates across the first device, the second device, and the cloud, ensuring cross-device privacy version consistency. This effectively avoids duplicate pop-up prompts on both the first and second devices, significantly reducing user interruptions and improving binding completion rates and user experience. Furthermore, version number maintenance, evidence storage mechanisms, and hash alignment ensure version consistency across both the client and cloud, while providing a complete audit trail.

[0016] Thirdly, this application provides a binding device applied to a first working mode of a first device. The first working mode is used to bind the first device and a second device. The binding device includes: a communication module configured to send the device certificate of the second device to the cloud for verification, and receive a binding token issued by the cloud after successful verification; a processing module configured to determine a target transmission time based on the current time, the current number of transmissions, and backoff parameters when the signal quality of the current network is less than a preset threshold; the communication module configured to send the binding token to the cloud for verification based on the target transmission time; and the processing module configured to repeatedly execute the steps of determining the target transmission time and sending the binding token until the cloud receives the binding token; and to successfully bind with the second device after the binding token is verified.

[0017] Fourthly, this application provides a binding device applied to a first working mode of a second device. The first working mode is used to bind the first device and the second device. The binding device includes: a communication module configured to send the device certificate of the second device to the first device; the first device configured to: send the device certificate of the second device to the cloud for verification, and receive a binding token issued by the cloud after successful verification; when the signal quality of the current network is less than a preset threshold, determine a target transmission time based on the current time, the current number of transmissions, and backoff parameters; send the binding token to the cloud for verification based on the target transmission time; and repeatedly execute the steps of determining the target transmission time and sending the binding token until the cloud receives the binding token; and a processing module configured to successfully bind with the first device after the binding token is verified.

[0018] Fifthly, this application provides a binding system, comprising: a cloud; a first device, communicatively connected to the cloud, configured to execute the binding method implemented above; and a second device, communicatively connected to the first device and the cloud, configured to execute the binding method implemented above.

[0019] Sixthly, this application provides a smart terminal, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of any of the above-described binding methods.

[0020] In a seventh aspect, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of any of the above-described binding methods.

[0021] Eighthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the binding method steps of any of the above implementations.

[0022] Compared with the prior art, the present invention has at least one of the following beneficial effects:

[0023] 1. After receiving the binding token from the cloud, the first device determines the target sending time by combining network signal quality, number of transmissions, and backoff parameters. This avoids the binding process being interrupted due to network fluctuations and ensures that the binding token is accurately sent to the cloud for verification. The second device sends its device certificate to the first device and then participates in the binding process. The cloud is responsible for device certificate verification, binding token generation and sending, and final verification of the binding token. This enables the first and second devices to complete the binding process efficiently, improving the binding efficiency between the first and second devices.

[0024] 2. By combining the exponential backoff strategy with mechanisms such as binding token renewal and merging binding requests, the binding efficiency of the first and second devices can be further improved by automatically retrying and resuming binding in offline or weak network scenarios or other abnormal scenarios, and by avoiding the binding process being interrupted due to network fluctuations.

[0025] 3. By receiving a random string sent by the first device and signing the random string, device identifier, timestamp or counter, and random number using the device's private key, a device certificate is generated. This effectively ensures the uniqueness and security of the device's identity. This method of signing the random string, timestamp, or counter guarantees that each generated device certificate is unique, reducing the risk of reuse and ensuring the security of device authentication during the binding process. This further improves the binding efficiency between the first and second devices.

[0026] 4. Version updates are performed across the first device, the second device, and the cloud, ensuring cross-device privacy version consistency. This effectively avoids duplicate pop-up prompts on both the first and second devices, significantly reducing user interruptions and improving binding completion rates and user experience. Furthermore, version number maintenance, evidence storage mechanisms, and hash alignment ensure version consistency across both the client and cloud, while providing a complete audit trail. Attached Figure Description

[0027] The preferred embodiments will now be described in a clear and easy-to-understand manner, in conjunction with the accompanying drawings, to further explain the above-mentioned characteristics, technical features, advantages, and implementation methods of the present invention.

[0028] Figure 1 A flowchart of a binding system provided in an embodiment of this application is shown;

[0029] Figure 2 A flowchart of a binding method provided in an embodiment of this application is shown;

[0030] Figure 3 This document illustrates a flowchart of a second device generating device certificate according to an embodiment of this application.

[0031] Figure 4 A flowchart illustrating a version update provided in an embodiment of this application is shown;

[0032] Figure 5 This paper shows a structural block diagram of a binding device provided in an embodiment of the present application;

[0033] Figure 6 A structural block diagram of a smart terminal provided in an embodiment of this application is shown. Detailed Implementation

[0034] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the specific implementation methods of the present invention will be described below with reference to the accompanying drawings. Obviously, the drawings described below are merely some embodiments of the present invention. For those skilled in the art, other drawings and other implementation methods can be obtained based on these drawings without any creative effort.

[0035] To keep the drawings concise, each figure only schematically shows the parts relevant to the invention, and these do not represent the actual structure of the product. Furthermore, to facilitate understanding, in some figures, only one of components with the same structure or function is schematically depicted, or only one is labeled. In this document, "one" not only means "only one," but can also mean "more than one."

[0036] It should also be further understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0037] In this document, it should be noted that, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to fixed connections, detachable connections, or integral connections; they can refer to mechanical connections or electrical connections; they can refer to direct connections or indirect connections through an intermediate medium; and they can refer to the internal communication between two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0038] Furthermore, in the description of this application, the terms "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0039] It should be noted that the above embodiments can be freely combined as needed. The above are merely preferred embodiments of the present invention. It should be pointed out that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

[0040] With the development of modern technology, various smart devices are becoming increasingly popular, such as smartphones, smart TVs, and smart home appliances. These devices usually need to establish a secure binding relationship through the network so that users can remotely control and manage them.

[0041] In one binding implementation, one smart device obtains a unique binding token and sends it to another smart device. The receiving device, upon receiving the token, parses it precisely and then sends the parsing result back. Through this series of interactions, the binding process between the two smart devices is completed. However, this binding method has significant drawbacks. For example, the binding process may be interrupted due to network fluctuations, greatly reducing binding efficiency.

[0042] In another binding implementation, the watch first connects to the network and sends a binding request to the server, which carries the device identifier. After verifying the device's identity, the server generates a one-time binding code and records its status. The watch displays this binding code as a QR code on its screen. The user scans the QR code with their mobile phone to obtain the binding code. The mobile phone must immediately send the binding code to the server for verification. The server checks whether the code has already been used; if not, the binding between the phone and the watch is complete, and the code is marked as used. This binding method also has the problem that the binding process may be interrupted due to network fluctuations, reducing binding efficiency. Furthermore, since the binding code is displayed on the screen as a QR code, it may be screenshotted and saved, posing a risk of reuse.

[0043] Therefore, this application provides a binding method to improve binding efficiency and binding reliability.

[0044] The following explanation is based on the accompanying diagram:

[0045] Reference Appendix Figure 1 The diagram illustrates a flowchart of a binding system provided in an embodiment of this application. Figure 1 As shown, the binding system may include a first device, a second device, and the cloud (or an edge node).

[0046] The first device and the second device can be the same device or different devices. For example, the first device and the second device can include, but are not limited to, mobile phones, computers, smartwatches, smart bracelets, smart glasses, tablets, etc. This application does not limit the types of the first device and the second device. That is, any device in this application can have the working mode and function of the first device or the second device when participating in the binding, or any device can have the working mode and function of the first device and the second device when participating in the binding. This application does not limit this.

[0047] The first and second devices can be configured to operate in a first mode. In this mode, the first device generates a random string (or challenge digest, which can be a random number) and sends it to the second device. In this first mode, the second device can process the random string sent by the first device to generate a device certificate. This device certificate may include, but is not limited to, a device identifier, public key fingerprint, timestamp, random number, challenge digest, signature, algorithm identifier, secure element version, counter, etc.

[0048] The first device receives the device certificate from the second device and then sends the device certificate to the cloud for verification. After successful verification, the cloud immediately issues a binding token (temporary binding token). This binding token may include, but is not limited to, device identifier, application identifier, expiration time (preferably 10 minutes, which can be set according to the user's actual needs), renewal window (preferably 3 minutes, which can be set according to the user's needs), purpose, signature, key identifier, and renewal identifier.

[0049] The first device receives the binding token and, when the current network signal quality is less than (i.e., a weak network / offline scenario, meaning normal data transmission is impossible) or not less than a preset threshold (i.e., an online scenario), submits a binding request and binding token to the cloud for verification (or confirmation and binding). The cloud verifies the validity of the binding token and checks the device's online reachability, then writes the binding relationship into the binding relationship table and returns a verification result (or confirmation result). The second device receives this verification result and updates the local binding status of the first and second devices based on it, completing the local database entry, thus achieving the binding of the first and second devices.

[0050] In weak network / offline scenarios, the first device first writes the binding token and binding request to a local retry queue, using transactional key-value pairs or SQLite write-along storage to support crash recovery. The flushing cycle of the local retry queue can be set according to user needs, preferably 5 seconds. Then, the binding token and binding request are submitted when the network becomes available, following an exponential backoff strategy. The retry queue entries in the local retry queue can include the payload hash (payload_sha256), the first enqueue time, the current number of transmissions (or attempts), the target transmission time (or next execution time), the backoff coefficient, the last error, and the idempotent key.

[0051] The cloud can send relevant parameters to the first and second devices, such as, but not limited to, backoff base, backoff coefficient, maximum number of retries, renewal window, maximum number of renewals, queue flushing cycle, etc. The cloud policy service sends these policy parameters with a version number, and the first and second devices can execute them according to the version.

[0052] Reference Appendix Figure 2 The diagram illustrates a flowchart of a binding method provided in an embodiment of this application. Figure 2 As shown, the binding method includes a portion executed by the first device, comprising:

[0053] S210 sends the device certificate of the second device to the cloud for verification, and receives the binding token issued by the cloud after the verification is successful.

[0054] S211, when the signal quality of the current network is less than a preset threshold, determine the target transmission time based on the current time, the current number of transmissions, and the backoff parameters.

[0055] S212, based on the target sending time, sends the binding token to the cloud for verification.

[0056] S213, Repeat the steps of determining the target sending time and sending the binding token until the cloud receives the binding token.

[0057] S214. Once the binding token verification is successful, the device is successfully bound to the second device.

[0058] like Figure 2 As shown, the binding method also includes a portion executed by the second device, including:

[0059] S220, send the device certificate of the second device to the first device.

[0060] S221, Once the binding token verification is successful, the device is successfully bound to the first device.

[0061] like Figure 2 As shown, this binding method also includes a portion executed by the cloud, including:

[0062] S230, verify the device certificate of the second device, and generate a binding token after the verification is successful.

[0063] S231, send the binding token to the first device.

[0064] S232, receive the binding token and binding request sent by the first device, and verify the binding token.

[0065] S233, send the verification result to the first device and the second device.

[0066] After the first and second devices enter the first working mode, the first device can generate a random string and send it to the second device; that is, the first device sends the random string as a challenge digest to the second device. The method that triggers the first device to generate the random string may include, but is not limited to, communication between the first and second devices in the first working mode. This communication method includes, but is not limited to, Near Field Communication (NFC), Bluetooth, Wi-Fi, and cellular communication. This application does not limit the communication method. Alternatively, the first device may receive a trigger command. The implementation of this trigger command may include, but is not limited to, a user inputting a trigger command on the first device, the cloud or the second device sending a trigger command to the first device, or a user using the first device to scan a QR code on the second device to obtain the trigger command. This application does not limit the source or form of the trigger command.

[0067] After receiving the random string sent by the first device, the second device can process it accordingly to generate a device certificate for the second device. The first device receives the device certificate and sends it to the cloud for verification. Once the verification is successful in the cloud, a binding token is immediately issued.

[0068] In an example of an offline or weak network scenario, the first device receives the binding token and, when the signal quality of the current network is less than a preset threshold, writes the binding token and binding request into a local retry queue. Then, it submits the binding request and binding token when the network becomes available, following an exponential backoff strategy. The purpose of the exponential backoff strategy is to retry when the binding request and binding token submission fails. Specifically, the target sending time, i.e., the next retry time, can be determined based on the current time, the current number of transmissions, and backoff parameters. The backoff parameters can include the backoff base, backoff coefficient, random jitter, and target backoff time. Therefore, the formula for determining the target sending time is next = min(now + base · β^k + jitter, now + Tmax), where base is the backoff base (preferably 2 seconds, which can be set according to user needs), k is the current number of transmissions (or the current number of retries), Tmax is the target backoff time (or the maximum backoff time), β is the backoff coefficient (preferably any value within the initial value range [1.8, 2.4]), jitter is random jitter, and now is the current time. The maximum number of retries for the exponential backoff strategy can be set according to user needs.

[0069] The first device can send a binding request and binding token from its local retry queue to the cloud according to the target sending time. The first device repeatedly executes the steps of determining the target sending time and sending the binding token until the cloud receives the binding token and binding request, which means that the network between the first device and the cloud is available at this time, and the current network signal quality is not less than a preset threshold. After receiving the binding token and binding request, the cloud can verify the binding token and send the verification result to the first device and the second device.

[0070] In one example of an online scenario, the first device receives the binding token and directly sends the binding request and binding token to the cloud. Upon receiving the binding token and binding request, the cloud can verify the binding token and send the successful verification result to both the first and second devices.

[0071] The second device receives the verification result and updates the local binding status of the first and second devices based on the verification result, thus completing the local database write-in and achieving the binding of the first and second devices.

[0072] In this embodiment, after receiving the binding token from the cloud, the first device determines the target sending time by combining network signal quality, number of transmissions, and backoff parameters. This avoids the binding process being interrupted due to network fluctuations and ensures that the binding token is accurately sent to the cloud for verification. The second device sends its device certificate to the first device and then participates in the binding process. The cloud is responsible for device certificate verification, binding token generation and sending, and final verification of the binding token. This enables the first and second devices to complete the binding efficiently, improving the binding efficiency and reliability of the first and second devices.

[0073] In one embodiment of this application, the method further includes: renewing the binding token when it expires and the current time is within the renewal window; and updating the binding token after successful renewal.

[0074] In an example of an offline or weak network scenario, the first device, upon receiving a binding token, can also check the token's expiration time. If the binding token expires and the current time falls within the renewal window, it is renewed. If the renewal is successful, the binding token can replace the one in the local retry queue, thus updating the binding token. If renewal fails, an exponential backoff strategy is used to renew it. If the number of renewal attempts exceeds the maximum, the user is prompted to retry online.

[0075] In one embodiment of this application, the method further includes: when sending a binding token to the cloud, simultaneously sending a binding request; the cloud is used to merge duplicate binding requests according to an idempotent key algorithm.

[0076] The idempotency key algorithm generates the following formula: idempotencyKey = hash(deviceId, appId, t0). Here, deviceId is the device identifier of the second device, appId is the application identifier of the first device, and t0 is the initial enqueue time. In an example from an offline or weak network scenario, if the first device sends multiple duplicate binding requests to the cloud, the cloud can merge these duplicate binding requests using the idempotency key algorithm.

[0077] This application embodiment, by combining the exponential backoff strategy with mechanisms such as binding token renewal and merging binding requests, can further ensure that the first and second devices automatically retry and resume binding in offline or weak network scenarios, or other abnormal scenarios, and avoid the problem of the binding process being forced to be interrupted due to network fluctuations, thereby further improving the binding efficiency of the first and second devices.

[0078] Reference Appendix Figure 3 This illustrates a flowchart of a second device generating device certificate provided in an embodiment of this application. For example... Figure 3 As shown, it includes:

[0079] S300: Receive a random string sent by the first device. The random string is generated by the first device when performing the target operation.

[0080] S310 signs a random string, device identifier, timestamp or counter, and random number based on the device's private key.

[0081] S320 generates a device certificate based on the signature result and a random string.

[0082] The target operation refers to the method by which the first device generates a random string in the foregoing embodiments. After the first and second devices enter the first operating mode, the first device can generate a random string and send it to the second device; that is, the first device sends the random string as a challenge digest to the second device. After receiving the random string sent by the first device, the second device's internal security element can use its device private key to sign the random string, device identifier, timestamp or counter, and random number. Then, the second device can generate a device proof based on the signature result, the random string, device identifier, timestamp or counter, random number, and the parameters included in the device proof listed in the foregoing embodiments.

[0083] This application embodiment receives a random string sent by a first device and signs the random string, device identifier, timestamp or counter, and random number using the device's private key to generate a device certificate. This effectively ensures the uniqueness and security of the device's identity. This method of signing the random string, timestamp, or counter guarantees that each generated device certificate is unique, reducing the risk of reuse and ensuring the security of device authentication during the binding process. It further improves the binding efficiency between the first and second devices.

[0084] Reference Appendix Figure 4 This illustrates a flowchart of a version update provided in an embodiment of this application. For example... Figure 4 As shown, it includes:

[0085] S400 compares the privacy version of the second device with that of the cloud.

[0086] S410: When the privacy version of the second device is lower than the privacy version in the cloud, and the difference is a mandatory clause, update the privacy version of the second device.

[0087] S420: If the first device and the second device are successfully bound and the first device has been updated to the privacy version, the privacy version of the second device will be updated synchronously.

[0088] Maintain the privacy version numbers of the first device, the second device, and the cloud. In an example of an online scenario, the second device can trigger a version query at preset intervals to compare the privacy version of the second device with that of the cloud.

[0089] When the privacy version of the second device is lower than the privacy version in the cloud, and the difference is a mandatory clause, update the privacy version of the second device. The second device can also block pop-ups and report the version number after user confirmation.

[0090] If the first device and the second device are successfully bound together and the first device has updated its privacy version, the privacy version of the second device will be updated synchronously. Specific examples may include, but are not limited to, if the first device and the second device are successfully bound together and the first device has agreed to the latest privacy version on the cloud, the privacy version of the second device will be updated synchronously; if the first device has agreed to the latest version upon its first boot and is in the "bind later" path, and the first device has already agreed to the latest version when binding the first device and the second device, the second device will update its privacy version synchronously without a pop-up prompt.

[0091] In other examples, when any agreement (privacy policy or user agreement) is updated, pop-up windows on both the first and second devices simultaneously display the agreement entry. When the pop-up appears, the network connectivity of both the first and second devices is restricted. The second device also records the time of consent, version number, and device identifier when updating, and performs hash alignment with the cloud to avoid duplicate pop-ups and disputes.

[0092] This application embodiment performs version updates across the first device, the second device, and the cloud, achieving cross-device privacy version consistency. This effectively avoids duplicate pop-up prompts on the first and second devices, significantly reducing user interruptions and improving binding completion rates and user experience. Furthermore, through version number maintenance, evidence storage mechanisms, and hash alignment, version consistency across both the device and cloud is ensured, while providing a complete audit trail.

[0093] In one embodiment of this application, after the second device generates the device certificate but before receiving the verification result, the second device enters the "Pending Confirmation" interface, displaying prompt text (e.g., "Binding request has been submitted, will be completed automatically once network availability is available") and a synchronous animation to avoid users misjudging the failure. The first device displays the "Pending Upload" status, the countdown to the next retry, and the remaining retry count in the retry queue module, and provides entry points such as "Try Submit Now" and "Cancel Binding". The first device automatically triggers a retry when the network recovers and a link becomes available. If the user manually clicks "Submit Now", the current backoff waiting is skipped, and a retry is performed directly. After the binding relationship is written to the cloud, the first and second devices are updated simultaneously via push / short link receipts, displaying "Binding Successful". If the local retry queue is exhausted and the process still fails, the user is prompted to move to an area with better network and re-execute the binding process.

[0094] In one embodiment of this application, data transmission between the first device, the second device, and the cloud can be encrypted. When verifying device credentials, the cloud can also verify the second device's device certificate and device whitelist to prevent forged devices from accessing the network.

[0095] Reference Appendix Figure 5 This illustration shows a structural block diagram of a binding device provided in an embodiment of this application. The binding device 500 can be located on a first device, such as... Figure 5 As shown, the system includes: a communication module 510 configured to send the device certificate of the second device to the cloud for verification, and receive a binding token issued by the cloud after successful verification; a processing module 520 configured to determine the target transmission time based on the current time, the current number of transmissions, and backoff parameters when the signal quality of the current network is less than a preset threshold; the communication module 510 configured to send the binding token to the cloud for verification based on the target transmission time; and the processing module 520 configured to repeatedly execute the steps of determining the target transmission time and sending the binding token until the cloud receives the binding token; and to successfully bind with the second device after the binding token is verified.

[0096] Continue to refer to the appendix Figure 5In another embodiment of this application, the binding device 500 may be located on a second device and includes: a communication module 510 configured to send the device certificate of the second device to a first device; the first device is configured to: send the device certificate of the second device to the cloud for verification, and after the verification is successful, receive a binding token issued by the cloud; when the signal quality of the current network is less than a preset threshold, determine a target sending time based on the current time, the current number of transmissions, and backoff parameters; send the binding token to the cloud for verification based on the target sending time; repeat the steps of determining the target sending time and sending the binding token until the cloud receives the binding token; and a processing module 520 configured to successfully bind with the first device after the binding token is verified.

[0097] In this embodiment, after receiving the binding token from the cloud, the first device determines the target sending time by combining network signal quality, number of transmissions, and backoff parameters. This avoids the binding process being interrupted due to network fluctuations and ensures that the binding token is accurately sent to the cloud for verification. The second device sends its device certificate to the first device and then participates in the binding process. The cloud is responsible for device certificate verification, binding token generation and sending, and final verification of the binding token, enabling the first and second devices to complete the binding efficiently and improving the binding efficiency between the first and second devices.

[0098] This application also provides a binding system, including a cloud; a first device, communicatively connected to the cloud, configured to execute the steps of the binding method of any of the above embodiments; and a second device, communicatively connected to the first device and the cloud, configured to execute the steps of the binding method of any of the above embodiments.

[0099] Reference Appendix Figure 6 This application also provides a smart terminal 600, which includes a memory 610, a processor 620, and a computer program stored on the memory 610. The processor 620 executes the computer program to implement the steps of the binding method of any of the above embodiments.

[0100] The memory 610 may be non-volatile memory (NVM), such as, but not limited to, semiconductor non-volatile memory, disk storage, or optical storage. Semiconductor non-volatile memory includes, but is not limited to, read-only memory (ROM) or flash memory, such as mask ROM, programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), NAND flash memory, or NOR flash memory.

[0101] The memory 610 can also be volatile memory, such as random access memory (RAM). RAM includes, for example, static random-access memory (SRAM) or dynamic random-access memory (DRAM). DRAM includes, for example, synchronous dynamic RAM (SDRAM) or double data rate SDRAM (DDR). With the development of technology, DDR includes, but is not limited to, DDR1, DDR2, DDR3, ..., DDR5, and may also include future DDR6.

[0102] Processor 620 is a circuit with signal processing capabilities. In one example, the processor can be a circuit with instruction read and execute capabilities; such as a central processing unit (CPU), microcontroller unit (MCU), microprocessor unit (MPU), graphics processing unit (GPU), or digital signal processor (DSP). In another example, the processor can realize its processing capabilities through the logical relationships of hardware circuits, which can be fixed or reconfigurable; for example, the processor can be a dedicated processor, such as a processor implemented with an application-specific integrated circuit (ASIC), which realizes its processing capabilities through the design of the logical relationships between components within the circuit; or a processor implemented with a programmable logic device (PLD), which realizes its processing capabilities by configuring the logical relationships between logic devices through a configuration file; for example, a processor implemented with a field-programmable gate array (FPGA). In another example, the processor can be a hardware circuit designed for artificial intelligence, which can be understood as an ASIC, such as a neural network processing unit (NPU), tensor processing unit (TPU), deep learning processing unit (DPU), etc. This application is not limited to the type of processor.

[0103] The smart terminal used in this application embodiment is basically similar to the method embodiment, so the description is relatively simple. For relevant details, please refer to the description of the method embodiment.

[0104] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the binding method of any of the above embodiments.

[0105] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the binding method of any of the above embodiments.

[0106] It should be noted that the above embodiments can be freely combined as needed. The above are merely preferred embodiments of the present invention. It should be pointed out that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A binding method, characterized in that, A first operating mode applied to a first device, the first operating mode being used to bind the first device and a second device, the binding method including: The device certificate of the second device is sent to the cloud for verification, and after the verification is successful, the binding token issued by the cloud is received; When the signal quality of the current network is less than a preset threshold, the target transmission time is determined based on the current time, the current number of transmissions, and backoff parameters. The backoff parameters include backoff base, backoff coefficient, random jitter, and target backoff time. Based on the target sending time, the binding token is sent to the cloud for verification; Repeat the steps of determining the target sending time and sending the binding token until the cloud receives the binding token; Once the binding token is verified, the device is successfully bound to the second device. When the binding token is sent to the cloud, a binding request is sent simultaneously; The cloud is used to merge duplicate binding requests according to an idempotent key algorithm; The second device is configured as follows: Receive a random string sent by the first device, the random string being generated by the first device when performing the target operation; The random string, device identifier, timestamp or counter, and random number are signed based on the device's private key; The device certificate is generated based on the signature result and the random string.

2. The binding method according to claim 1, characterized in that, Also includes: When the binding token expires and the current time is within the renewal window, the binding token is renewed. Once the binding token is successfully renewed, the binding token is updated.

3. A binding method, characterized in that, A first operating mode applied to the second device, the first operating mode being used to bind the first device and the second device, the binding method including: Send the device certificate of the second device to the first device; The first device is configured to: send the device certificate of the second device to the cloud for verification, and receive a binding token issued by the cloud after successful verification; when the signal quality of the current network is less than a preset threshold, determine a target transmission time based on the current time, the current number of transmissions, and backoff parameters; send the binding token to the cloud for verification based on the target transmission time; and repeat the steps of determining the target transmission time and sending the binding token until the cloud receives the binding token. Once the binding token is verified, it is successfully bound to the first device; Receive a random string sent by the first device, the random string being generated by the first device when performing the target operation; The random string, device identifier, timestamp or counter, and random number are signed based on the device's private key; The device proof is generated based on the signature result and the random string. The first device is configured to: simultaneously send a binding request when sending the binding token to the cloud; the cloud is used to merge duplicate binding requests according to an idempotent key algorithm.

4. The binding method according to claim 3, characterized in that, Also includes: Compare the privacy versions of the second device and the cloud; When the privacy version of the second device is lower than the privacy version of the cloud, and the difference is a mandatory clause, update the privacy version of the second device; If the first device and the second device are successfully bound and the first device has been updated to a new privacy version, the privacy version of the second device will be updated synchronously.

5. A binding device, characterized in that, A first operating mode applied to a first device, the first operating mode being used to bind the first device and a second device, the binding device comprising: The communication module is configured to send the device certificate of the second device to the cloud for verification, and receive the binding token issued by the cloud after the verification is successful; The processing module is configured to determine the target transmission time based on the current time, the current number of transmissions, and backoff parameters when the signal quality of the current network is less than a preset threshold. The communication module is configured to send the binding token to the cloud for verification based on the target sending time; The processing module is configured to: repeatedly execute the steps of determining the target sending time and sending the binding token until the cloud receives the binding token; and when the binding token is verified, the binding with the second device is successful. The communication module is configured to send a binding request synchronously when the binding token is sent to the cloud; the cloud is used to merge duplicate binding requests according to an idempotent key algorithm. The second device is configured as follows: Receive a random string sent by the first device, the random string being generated by the first device when performing the target operation; The random string, device identifier, timestamp or counter, and random number are signed based on the device's private key; The device certificate is generated based on the signature result and the random string.

6. A binding device, characterized in that, A first operating mode applied to the second device, the first operating mode being used to bind the first device and the second device, the binding device comprising: A communication module is configured to send the device certificate of the second device to the first device; the first device is configured to: send the device certificate of the second device to the cloud for verification, and after successful verification, receive a binding token issued by the cloud; when the signal quality of the current network is less than a preset threshold, determine a target transmission time based on the current time, the current number of transmissions, and backoff parameters; send the binding token to the cloud for verification based on the target transmission time; and repeat the steps of determining the target transmission time and sending the binding token until the cloud receives the binding token. The processing module is configured to successfully bind with the first device after the binding token verification is passed; The processing module is configured to: receive a random string sent by the first device, the random string being generated by the first device when performing a target operation; sign the random string, device identifier, timestamp or counter, and random number according to the device's private key; and generate the device proof based on the signature result and the random string. The first device is configured to: simultaneously send a binding request when sending the binding token to the cloud; the cloud is used to merge duplicate binding requests according to an idempotent key algorithm.

7. A binding system, characterized in that, include: Cloud; A first device, communicatively connected to the cloud, is configured to perform the steps of the binding method according to any one of claims 1-2; A second device, communicatively connected to the first device and the cloud, is configured to perform the steps of the binding method according to any one of claims 3-4.

8. A smart terminal, comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the steps of the binding method according to any one of claims 1-2 or 3-4.

Images