Device binding method, device, electronic device and server

Abstract

The present application provides a device binding method, apparatus, electronic device and server, the method comprising: receiving activation request information, the activation request information including the device identification of the device to be bound; the activation request information is used to request the server to activate the device to be bound according to the device identification of the device to be bound; storing the activation request information in a task waiting queue; obtaining binding request information, the binding request information including the device identification of the device to be bound; the binding request information is used to request binding of the device identification of the device to be bound and a user account; migrating the activation request information corresponding to the device identification from the task waiting queue to the task consumption queue; activating the device to be bound corresponding to the activation request information in the task consumption queue, establishing a binding relationship between the device to be bound and the user account, and pushing binding status information to the device to be bound. The present application completes the device binding function while activating the device, thereby improving the efficiency of device binding.

Description

Technical Field

[0001] The present application relates to the field of communications, and more specifically, to a device binding method, apparatus, electronic device and server. Background Art

[0002] With the rapid development of the Internet of Things technology, more and more smart devices can be connected through the network and play an important role in various application scenarios, such as smart watches, sports bracelets, sweeping robots, etc. These smart devices often need to be activated on the server before use. In addition, after the smart device is activated, the user needs to bind the terminal device through the application program to view, control, adjust and other operations of the smart device, or bind it with the user account to realize the intelligence and data synchronization of the smart device.

[0003] In actual applications, the activation and binding of smart devices are divided into two stages, which require multiple operations on the smart device to be bound and the application. Sometimes, it is even necessary to manually enter information such as user account or device model. If the information is entered incorrectly, it will lead to incorrect binding or binding failure.

[0004] In addition, during the activation and binding process of smart devices, the server needs to respond to the activation and binding of smart devices multiple times, resulting in low activation and binding efficiency of smart devices. Therefore, how to improve the binding efficiency of smart devices has become an important issue that needs to be solved urgently. Summary of the invention

[0005] The present application provides a device binding method, apparatus, electronic device and server, which can complete the device binding function while the device is activated, thereby improving the device binding efficiency.

[0006] In a first aspect, a device binding method is provided, which is applied to a server, and the method includes: receiving activation request information, the activation request information including a device identification of a device to be bound; the activation request information is used to request a server to activate the device to be bound according to the device identification of the device to be bound; storing the activation request information in a task waiting queue; obtaining binding request information, the binding request information including the device identification of the device to be bound; the binding request information is used to request binding of the device identification of the device to be bound and a user account; migrating the activation request information corresponding to the device identification from the task waiting queue to the task consumption queue; activating the device to be bound corresponding to the activation request information in the task consumption queue, establishing a binding relationship between the device to be bound and the user account, and pushing binding status information to the device to be bound.

[0007] In the above scheme, the server can manage activation request information and binding request information through the message middleware to ensure that the activation and binding operations of the device to be bound are carried out synchronously. After receiving the binding request information, the server will first confirm that the activation request information corresponding to the device ID of the device to be bound already exists (that is, the activation request information has been migrated from the task waiting queue to the task consumption queue and entered the ready state), and complete the binding of the device ID and the user account while the device to be bound is activated. This synchronization mechanism can effectively avoid the problem of binding failure or device failure due to asynchronous operation, and improve the binding efficiency of the device to be bound.

[0008] The design of task waiting queue and task consumption queue can efficiently handle a large number of concurrent requests. After the activation request information is received, it is first placed in the task waiting queue, and then gradually migrated to the task consumption queue for processing according to the processing capacity of the server. This mechanism can improve the throughput and response speed of the server. After the server completes the device activation and binding, it will immediately push the binding status information to the device to be bound. This instant feedback allows users to understand the binding progress and results in a timely manner, so as to make corresponding operations or adjustments.

[0009] In one implementation, the task waiting queue includes multiple activation request messages; the activation request information corresponding to the device identifier is migrated from the task waiting queue to the task consumption queue, including: determining the target activation request information in the task waiting queue according to the push time of each activation request message, the push time of the target activation request information being earlier than the current time; migrating the target activation request information from the task waiting queue to the task consumption queue; or, upon receiving the binding request information of the device to be bound, migrating the activation request information of the device to be bound from the task waiting queue to the task consumption queue, and the binding request information of the device to be bound and the activation request information of the device to be bound correspond to the same device identifier.

[0010] In the above scheme, after receiving the binding request information, the server can quickly find the corresponding activation request information according to the device identification, and migrate the activation request information to the task consumption queue for processing. This synchronization mechanism can ensure the consistency of activation and binding operations, and avoid the situation where binding failure or the device to be bound cannot be used normally due to asynchronous operations. By determining the target activation request information based on the push time, the server can give priority to activation request information that is about to expire or has timed out, and optimize the utilization of server resources. This time-sensitive task scheduling mechanism ensures that the activation request information can be processed in a timely manner, improving the response speed and accuracy of the server.

[0011] In one implementation, the task waiting queue includes multiple activation request messages; pushing binding status information to the device to be bound includes: determining the device identifier corresponding to each activation request message, and pushing the corresponding binding status information to the device to be bound according to the device identifier; the binding status information is the binding status of the device identifier of the device to be bound and the user account.

[0012] In the above scheme, the device binding process is optimized by introducing a time-sensitive task scheduling mechanism. It ensures that activation request information that is about to expire or has timed out can be processed in a timely manner, thereby improving the response speed and accuracy of the server. By regularly checking the task waiting queue, the activation request information that is about to expire or has timed out is determined, ensuring that the activation request information can be processed in a timely manner, avoiding server response delays caused by long waiting times, and improving the timeliness of activation request information processing.

[0013] In one implementation, the target activation request information is determined in the task waiting queue based on the push time of each activation request information, including: determining a message set of multiple activation request information in the task waiting queue; determining the push time of each activation request information in the message set; sorting the activation request information in the message set according to the push time of the activation request information to obtain a sorting result; and determining the target activation request information according to the sorting result.

[0014] In the above scheme, determining the push time of each activation request information is the basis for subsequent sorting and scheduled scanning, ensuring that each activation request information has a clear time node, and the server can accurately determine whether it is about to expire or needs priority processing. According to the push time of the activation request information, the activation request information in the task waiting queue is sorted. The priority management of the activation request information is implemented to ensure that the activation request information that is about to expire or has a higher priority can be processed first. It helps to reduce waiting time and improve the response speed of the server.

[0015] In one implementation, the method also includes: determining the network load of the server, the network load being positively correlated with the number of activation request information in the task waiting queue; determining a waiting time parameter based on the network load of the server; and sending the waiting time parameter to the device to be bound, so that the device to be bound determines the time to send the next activation request information based on the waiting time parameter.

[0016] In the above scheme, the network load of the server is determined, and the current working status of the server can be evaluated in real time. The network load is positively correlated with the number of activation request information in the task waiting queue. The waiting time parameter is determined according to the network load of the server, and the waiting time parameter is sent to the device to be bound. The sending frequency of the activation request information of the device to be bound is dynamically adjusted according to the network load, thereby reducing the risk of server overload.

[0017] In one implementation, the server includes a business module and a query module; the business module is used to receive the activation request information and the binding request information; the device to be bound is activated according to the device identification of the device to be bound, a binding relationship between the device identification of the device to be bound and the user account is established, binding status information is obtained, and the binding status information is written into a database; the query module is used to query the binding status information of the device to be bound in the database according to the device identification of the device to be bound, and send the binding status information to the device to be bound.

[0018] In the above solution, the business module is responsible for receiving and processing activation request information and binding request information. This design allows the server to quickly respond to requests from users, and judge and execute corresponding operations through business logic, such as activating the device to be bound with the corresponding device ID or establishing a binding relationship between the device ID and the user account. The business module activates the device to be bound, ensuring that the device to be bound has been verified and authorized by the server before use, thereby improving the security and legality of the use of the device to be bound.

[0019] By establishing a binding relationship between the device ID and the user account, the server can track or manage the usage of the corresponding device. The query module writes the binding relationship between the device ID and the user account of the device to be bound to the database to achieve persistent storage of data and provide efficient data query and retrieval capabilities, so that the server can quickly respond to subsequent query requests for the binding relationship. The separation design of the business module and the query module makes the system more modular. If you need to add a new device type or binding rule, you only need to modify the relevant logic of the business module, which improves the flexibility of the system to adapt to different application scenarios.

[0020] In one implementation, the method also includes: when the business module receives the activation request information sent by the device to be bound, it sends a query request to the query module to query the device identification of the device to be bound and the binding status information of the user account in the database; if the device identification of the device to be bound and the binding status information of the user account exist in the database, the business module pushes the binding status information to the device to be bound; if the device identification of the device to be bound and the binding status information of the user account do not exist in the database, the business module sends the waiting time parameter to the device to be bound.

[0021] In the above solution, the business module receives the activation request information sent by the device to be bound for the Nth time, and queries the database for the binding status information of the device identification and user account of the device to be bound. This step ensures that when the server processes the activation request information, it can first check whether the device to be bound has been bound, thereby avoiding repeated binding or invalid binding.

[0022] When the database already contains the binding status information of the device ID and user account of the device to be bound, the business module will push the binding status information to the device to be bound. This means that the server can accurately identify the binding status of the device to be bound and provide correct feedback to the device to be bound, ensuring that the user can understand the binding status of the device to be bound in a timely manner.

[0023] If the database does not contain the binding status information of the device ID and user account of the device to be bound, the business module will send a waiting time parameter to the device to be bound to control the request frequency of the device to be bound. This design allows the device to be bound to perform an appropriate delay retry according to the waiting time parameter after multiple attempts to bind have failed, avoiding excessive server load or network congestion caused by frequent sending of activation request information.

[0024] In a second aspect, a device binding method is provided, which is applied to a device to be bound, and the method includes: displaying QR code information on a display screen, wherein the QR code information is associated with a device identification of the device to be bound; creating activation request information corresponding to the device identification, and sending the activation request information to a server; the activation request information is used to request the server to activate the device to be bound; receiving binding status information, and displaying the binding status information on the display screen, wherein the binding status information is the binding status of the device identification of the device to be bound and a user account.

[0025] In the above scheme, the device to be bound directly displays the QR code information through the display screen, and the QR code is closely associated with the device identification of the device to be bound. The user only needs to use the application of the mobile terminal device to scan this QR code to easily start the binding process. The device to be bound automatically creates activation request information corresponding to the device identification and actively sends the activation request information to the server to improve the efficiency and accuracy of the binding process. After receiving the activation request information, the server will activate the device identification and generate binding status information. The device to be bound can receive and display the binding status information in real time, so that the user can immediately understand the binding progress and results.

[0026] In one implementation, the method further includes: sending the activation request information to the server again at a preset time interval within a first preset time period until the binding status information is received; the number of times the activation request information is sent is less than N; after the first preset time period ends, if the device to be bound does not receive the binding status information, the activation request information is no longer sent to the server within a second preset time period; the first preset time period and the second preset time period are two consecutive time periods.

[0027] In the above scheme, the orderliness and controllability of request sending are enhanced. By sending activation request information at preset time intervals within the first preset period, it is ensured that the request is sent in an orderly manner at a certain time interval. The limit on the number of sending times (i.e., stop sending when the number of sending times is greater than N, N can be 10) makes the entire request sending process more controllable. When the device to be bound fails to receive the binding status information within the first preset period, it stops sending the activation request information to avoid unnecessary resource consumption and message redundancy.

[0028] In practical applications, an orderly request sending strategy helps reduce network congestion and server processing pressure, thereby improving the efficiency of request processing. At the same time, by limiting the first preset time period and the number of sending times, network resources can be used more effectively to avoid invalid request sending. Send activation request information multiple times within the first preset time period, set an upper limit on the number of sending times, and if the device to be bound still does not receive the binding status information within the first preset time period, it can be considered that the request has expired or the status of the device to be bound is abnormal, thereby avoiding further invalid requests.

[0029] In a third aspect, a device binding method is provided, which is applied to a mobile terminal device, and the method includes: logging in to a user account on an application side, the application side connecting to a server; obtaining a device identifier of a device to be bound on the application side; creating binding request information corresponding to the device identifier; the binding request information is used to request binding of the device identifier of the device to be bound and the user account; sending the binding request information to the server, so that the server activates the device to be bound and establishes a binding relationship between the device identifier of the device to be bound and the user account after responding to the activation request information of the device to be bound.

[0030] In the above scheme, after receiving the binding request information, the server responds to the activation request information of the device to be bound, activates the device to be bound, and establishes a binding relationship between the device identifier of the device to be bound and the user account. This step ensures that the activation and binding of the device to be bound are carried out synchronously, avoiding the problem of binding failure or the inability to use the device to be bound normally due to asynchronous operations. After completing the activation and binding of the device to be bound, the server will push the binding status information to the device to be bound. This real-time feedback mechanism allows users to understand the binding progress and results in a timely manner, so as to make corresponding operations or adjustments.

[0031] In a fourth aspect, a device binding apparatus is provided, the apparatus comprising:

[0032] A receiving module, configured to receive activation request information, wherein the activation request information includes a device identification of a device to be bound; the activation request information is used to request a server to activate the device to be bound according to the device identification of the device to be bound; and the activation request information is stored in a task waiting queue;

[0033] an acquisition module, configured to acquire binding request information, wherein the binding request information includes a device identifier of the device to be bound; the binding request information is used to request binding of the device identifier of the device to be bound and a user account; and to migrate activation request information corresponding to the device identifier from the task waiting queue to the task consumption queue;

[0034] The response module is used to activate the device to be bound corresponding to the activation request information in the task consumption queue, establish a binding relationship between the device to be bound and the user account, and push binding status information to the device to be bound.

[0035] In a fifth aspect, a device binding apparatus is provided, the apparatus comprising:

[0036] A display module, used to display QR code information on a display screen, wherein the QR code information is associated with a device identifier of a device to be bound;

[0037] A processing module, used to create activation request information corresponding to the device identification, and send the activation request information to the server; the activation request information is used to request the server to activate the device to be bound and push binding status information to the device to be bound;

[0038] The receiving module is used to receive binding status information and display the binding status information on the display screen, wherein the binding status information is the binding status of the device identification of the device to be bound and the user account.

[0039] In a sixth aspect, a device binding apparatus is provided, the apparatus comprising:

[0040] A scanning module, used to log in to a user account of an application terminal, the application terminal being connected to a server; scanning a QR code information on the application terminal, the QR code information being associated with a device identifier of a device to be bound;

[0041] A processing module, used for creating binding request information corresponding to the device identification; the binding request information is used for requesting binding between the device identification of the device to be bound and the user account;

[0042] The sending module is used to send binding request information to the server, so that the server responds to the activation request information of the device to be bound, activates the device to be bound, establishes a binding relationship between the device identification of the device to be bound and the user account, and pushes binding status information to the device to be bound.

[0043] In a seventh aspect, a server is provided, the server comprising a memory and a processor, the processor being configured to execute any one of the device binding methods described above.

[0044] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0046] Figure 1 An application scenario diagram of the device binding method provided in an embodiment of the present application;

[0047] Figure 2 Schematic diagram of the device binding method provided in the embodiment of the present application Figure 1 ;

[0048] Figure 3 An interactive schematic diagram of a device binding method provided in an embodiment of the present application;

[0049] Figure 4 Schematic diagram of the device binding method provided in the embodiment of the present application Figure 2 ;

[0050] Figure 5 Schematic diagram of the device binding method provided in the embodiment of the present application Figure 3 ;

[0051] Figure 6 A timing diagram of a device binding method provided in an embodiment of the present application;

[0052] Figure 7 A schematic diagram of the structure of the device binding device provided in the embodiment of the present application Figure 1 ;

[0053] Figure 8 A schematic diagram of the structure of the device binding device provided in the embodiment of the present application Figure 2 ;

[0054] Fig. 9 A schematic diagram of the structure of the device binding device provided in the embodiment of the present application Figure 3 . DETAILED DESCRIPTION

[0055] In order to make the purpose, technical solution and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the embodiments and the accompanying drawings. Here, the illustrative embodiments of the present invention and their descriptions are used to explain the present invention, but are not intended to limit the present invention.

[0056] In the following, the terms "first" and "second" are used for descriptive purposes only and are not to be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the features.

[0057] Figure 1 For an application scenario diagram of the device binding method provided in the embodiment of the present application, see Figure 1, this application takes the public network intercom as an example, and activates and binds it as a device to be bound. The public network intercom adopts a public network communication chip module, and with the support of the operator network, it realizes cluster communication capabilities. The public network server in the cloud platform adopts software-defined media routing and control strategies, and cooperates with the public network intercom to provide cluster intercom services to public network users. In actual applications, the public network intercom often needs to be activated on the public network server before use. After the device identifier of the public network intercom is activated on the public network server, the public network server will assign business permissions to the activated public network intercom, and the business permissions include the right to use the public network intercom service. At the same time, the public network intercom is charged for business according to the time when the public network intercom is first activated. Therefore, it is necessary for the user to actively activate it, and the user's active activation is deemed that the user has known the business billing rules on the public network server.

[0058] After the public network intercom is activated, it needs to be bound to the user account on the application side to implement public network intercom functions such as group settings and group management on the application side. In order to implement the corresponding functions on the application side, the public network server needs to activate the public network intercom according to the device identification of the public network intercom and establish a binding relationship between the user account on the application side and the device identification of the public network intercom.

[0059] The following is a detailed introduction to the method flow executed by the server provided in the embodiment of the present application.

[0060] Figure 2 A schematic diagram of the device binding method provided in the embodiment of the present application. Figure 2 The device binding method provided in the embodiment of the present application is applied to a server, and the server performs the following steps:

[0061] Step 201: receiving activation request information, the activation request information including the device identification of the device to be bound; the activation request information is used to request the server to activate the device to be bound according to the device identification of the device to be bound; and storing the activation request information in a task waiting queue.

[0062] In the example, when the device to be bound is a public network intercom, the server is a public network server. The public network server is configured with a listening port to receive activation request information from the public network intercom. When receiving the activation request information, the public network server parses its content, extracts the device identification, user account and request type (i.e., querying the binding status) of the public network intercom from the activation request information, sets the request expiration time, and delivers the activation request information to the task waiting queue. The task waiting queue can be a memory queue, a database queue, or a message middleware queue. Each element in the task waiting queue is a query task, which contains the device identification, user account information, request timestamp, etc.

[0063] In the example, the activation request information contains a device ID and a delay time, which means that after the delay time, the corresponding activation request information needs to be migrated to the task consumption queue for processing. Binding request information can be stored in a database, memory cache, or message middleware, waiting for a scheduled task or event to be triggered. The public network server regularly checks whether there is binding request information that needs to be processed through a scheduled task or event monitoring mechanism.

[0064] After receiving the activation request information, the message middleware stores it in the task waiting queue. This task waiting queue mechanism ensures the orderly processing of the activation request information, and also makes it easy to monitor and manage the activation request information. Since all activation request information is processed by the task waiting queue, the public network server can process the requests in the order in which they are received, avoiding confusion or errors caused by concurrent processing. When the binding request information arrives, the message middleware can migrate the activation request information corresponding to the device identifier from the task waiting queue to the task consumption queue, so as to achieve rapid response and processing of the request.

[0065] Step 202: Obtain binding request information, the binding request information includes the device identifier of the device to be bound; the binding request information is used to request binding of the device identifier of the device to be bound and the user account; and migrate activation request information corresponding to the device identifier from the task waiting queue to the task consumption queue.

[0066] In the example, when receiving the binding request information, the public network server parses the device ID in the binding request information, modifies the expiration time of the corresponding activation request information in the task waiting queue to the current time according to the device ID, and triggers the delayed expiration of the query request information corresponding to the device ID. The scheduled task is started to scan the expired activation request information, and the message middleware performs the migration operation to migrate the activation request information corresponding to the specified device ID from the task waiting queue to the task consumption queue.

[0067] The message middleware and business module are configured in the public network server. The message middleware executes the delayed message mechanism, pre-sets the expiration time of the delayed request, and waits for the delayed request to expire automatically after reaching the time point. Before the expiration time point of the delayed request, the business module of the public network server will receive the periodic activation request information of the public network intercom.

[0068] The delayed expiration mechanism is introduced to put the activation request information into the task waiting queue, and migrate it to the task consumption queue for processing when the delay expires, so as to realize batch processing and optimized scheduling of query requests, allow the public network server to process the query request at the appropriate time point (that is, when the delay expires), and automatically push the relevant binding status information after the delay expires, thereby avoiding congestion of query requests and improving the response speed and stability of the public network server. The delayed expiration mechanism allows the public network server to process query requests during non-peak hours, thereby reducing the pressure during peak hours.

[0069] By storing the activation request information in the task waiting queue, the public network server can dynamically allocate processing tasks based on resource usage to avoid resource waste and bottlenecks. As an intermediate layer, the message middleware can buffer or adjust the congestion of requests, so that the public network server can maintain efficiency and stability when processing a large number of requests. While migrating the activation request information to the task consumption queue, the message middleware pushes the binding status information to the device to be bound (public network intercom). As the number of devices to be bound increases and the binding demand grows, the message middleware can flexibly adjust the queue capacity and processing capacity of the task waiting queue to meet business expansion needs.

[0070] Step 203: Activate the device to be bound corresponding to the activation request information in the task consumption queue, establish a binding relationship between the device to be bound and the user account, and push binding status information to the device to be bound.

[0071] In the example, request delivery and scheduled tasks are two independent threads that can be executed in parallel. The request delivery thread is responsible for delivering the newly created activation request information to the task waiting queue, while the scheduled task thread is responsible for regularly scanning the activation request information in the task waiting queue and processing expired activation request information. In the task consumption queue, when the public network server processes each activation request information, it obtains the binding status information of the public network intercom device identification and user account by querying the database or calling other services.

[0072] The public network server encapsulates the queried binding status information into a response message, including the device identifier, user account, binding status (such as bound, unbound, binding expired, etc.) and possible additional information (such as binding time, unbinding time, etc.). The public network server uses the appropriate communication protocol to push the encapsulated binding status information to the public network intercom or the client device connected to it. After receiving the binding status information, the public network intercom can display it on the screen.

[0073] The following is a detailed introduction to the migration process of activation request information between the task waiting queue and the task consumption queue.

[0074] In one implementation, the task waiting queue includes multiple activation request information; the activation request information corresponding to the device identifier is migrated from the task waiting queue to the task consumption queue, including: determining the target activation request information in the task waiting queue according to the push time of each activation request information, the push time of the target activation request information is earlier than the current time; and migrating the target activation request information from the task waiting queue to the task consumption queue.

[0075] Alternatively, when receiving the binding request information of the device to be bound, the activation request information of the device to be bound is migrated from the task waiting queue to the task consumption queue, and the binding request information of the device to be bound and the activation request information of the device to be bound correspond to the same device identifier.

[0076] In the example, the server receives activation request information from the device to be bound, which includes the device identification of the device to be bound, etc. These activation request information are stored in the task waiting queue. The server periodically checks the activation request information in the task waiting queue. For each activation request information, the server checks its push time to determine whether it has reached or exceeded the current time. If the push time of the activation request information is earlier than the current time, then these activation request information are regarded as target activation request information. The server migrates these target activation request information from the task waiting queue to the task consumption queue for subsequent processing.

[0077] In the example, the server will receive binding request information from the application side, which also contains the device ID of the device to be bound. If the server receives the binding request information of the device to be bound, and the binding request information corresponds to the same device ID as an activation request information in the task waiting queue, the server will also migrate the corresponding activation request information to the task consumption queue. In the task consumption queue, the server will process the activation request information, including activating the device to be bound and establishing a binding relationship between its device ID and the user account. After completing the activation and binding, the server will push the binding status information to the device to be bound.

[0078] Those skilled in the art should understand that the server manages activation request information through the message middleware to ensure that the activation and binding operations of the device to be bound are carried out synchronously. The server compares the push time in each activation request information with the current time to determine whether the activation request information needs to be migrated to the task consumption queue. Alternatively, when the binding request information arrives, the server will search for the corresponding activation request information in the task waiting queue according to the device identifier therein and perform the migration operation. The task consumption queue is used to store the activation request information to be processed, and the server will complete the activation and binding operations of the device to be bound in this queue.

[0079] In the above scheme, two migration strategies are provided: (1) Migration based on push time. The server will traverse each activation request information in the task waiting queue and determine the target activation request information based on its push time. The target activation request information is migrated from the task waiting queue to the task consumption queue for subsequent activation and binding processes. (2) Migration based on binding request information. When the server receives the binding request information of the device to be bound, it will check whether the activation request information of the device to be bound already exists in the task waiting queue. If it does exist, and the binding request information and the activation request information correspond to the same device identifier, the server will migrate the activation request information of the device to be bound from the task waiting queue to the task consumption queue. This migration method ensures that the device to be bound can be responded to and processed as soon as possible after the binding request information is issued, thereby improving the binding efficiency of the device to be bound.

[0080] In one implementation, the task waiting queue includes multiple activation request information; pushing binding status information to the device to be bound includes: determining the device identifier corresponding to each activation request information, and pushing the corresponding binding status information to the device to be bound according to the device identifier; the binding status information is the device identifier of the device to be bound and the binding status of the user account.

[0081] Determine the target activation request information in the task waiting queue, and the push time of the target activation request information is earlier than the current time; migrate the target activation request information to the task consumption queue; determine the device identification corresponding to each activation request information, and push the corresponding binding status information to the device to be bound according to the device identification; the binding status information is the device identification of the public network intercom and the binding status of the user account.

[0082] In the example, the public network server accesses the task waiting queue storing the activation request information. For each activation request information in the task waiting queue, the public network server checks the push time contained therein (i.e., the time when the binding status information is scheduled to be pushed). The push time is a timestamp indicating when the information should be processed and the binding status information should be pushed.

[0083] The public network server compares the current time with the push time of each activation request information. If the push time reaches or exceeds the current time, then the activation request information is regarded as the target activation request information. The public network server determines and filters the target activation request information from the task waiting queue.

[0084] The public network server ensures that there is a task consumption queue available to store the activation request information to be processed. The task consumption queue can be a queue of the same type as the task waiting queue, but is used in different processing stages. The public network server implements the migration of the target activation request information from the task waiting queue to the task consumption queue by calling the API (data interface) of the task consumption queue and the task waiting queue.

[0085] For each activation request message, the public network server executes the necessary business logic to query the binding status of the public network intercom's device identification and user account. The public network server communicates with the database or other services to retrieve the binding status information associated with the device identification. The binding status information includes the binding status, the bound user account, the binding time, etc.

[0086] The public network server encapsulates the queried binding status information into a response message. The response message contains enough information for the public network intercom or client device to understand and process. The public network server uses the communication protocol to push the encapsulated binding status information to the public network intercom. The push operation involves steps such as establishing a network connection, sending data, and receiving confirmation.

[0087] The following is a detailed description of the process of determining target activation request information in the task waiting queue.

[0088] In one implementation, target activation request information is determined in a task waiting queue based on the push time of each activation request information, including: determining a message set of multiple activation request information in the task waiting queue; determining the push time of each activation request information in the message set; sorting the activation request information in the message set based on the push time of the activation request information to obtain a sorting result; and determining the target activation request information based on the sorting result.

[0089] In the example, request sorting and request consumption are two independent operations that can be executed in parallel. The scheduled task thread is responsible for sorting the activation request information in the task waiting queue according to the expiration time, regularly scanning the push time of each activation request information in the task waiting queue, realizing dynamic monitoring and scheduling of tasks, and timely discovering and processing the activation request information that is about to expire. The application side can monitor the task consumption queue in parallel and process the expired activation request information. The scheduled task sorts the activation request information in the task waiting queue from small to large according to the expiration time at a predetermined time interval (such as 1 minute), determines the activation request information that is less than or equal to the current time as the target activation request information, and puts it from the task waiting queue to the task consumption queue, waiting for the application side to monitor and process.

[0090] The server accesses the task waiting queue and parses the activation request information in the task waiting queue one by one. Each activation request information contains a push time field, which indicates when the binding status information associated with the activation request information should be pushed. The server extracts the value of the push time field from each activation request information. The push time is a timestamp that represents a specific date and time. The server can store the extracted push time in a memory data structure (such as a hash table, dictionary) for fast access. Or it can be stored in the form of a key-value pair, where the key can be a unique identifier of the activation request information (such as the device ID of the device to be bound), and the value can be the push time.

[0091] The server creates a new list, the message set, to store activation request information sorted by push time. The server traverses each activation request information in the task waiting queue. For each activation request information, the server inserts it into the appropriate position in the message set according to its push time. If the sorted message set will be used as a new task waiting queue, the server can update the queue reference to point to the message set.

[0092] The server sets a timer or schedules a task that is executed periodically (e.g., every second, every minute). Each time the timer is triggered, the server obtains the current system time. The server traverses each activation request message in the sorted list (i.e., message set). If the push time of an activation request message is less than or equal to the current time, the activation request message is used as the target activation request message. The server can mark the target activation request message as pending, or migrate it from the task waiting queue to the task consumption queue for further processing.

[0093] The server maintains a pointer to the earliest expired activation request information in the message set, so that each time the timer is triggered, it only needs to start scanning from this pointer until it finds the first activation request information with a push time earlier than the current time. If the message set is sorted by push time and the timer is triggered frequently, the server can consider using a priority queue (such as a minimum heap) to store activation request information, so that the earliest expired activation request information can be quickly found each time. Through the above steps, the server can determine the target activation request information in the task waiting queue and migrate it to the task consumption queue for further processing.

[0094] The following is a detailed description of the process of determining the waiting time parameter according to the network load of the server.

[0095] In one implementation, the method also includes: determining the network load of the server, the network load is positively correlated with the number of activation request information in the task waiting queue; determining the waiting time parameter based on the network load of the server; and sending the waiting time parameter to the device to be bound, so that the device to be bound determines the time to send the next activation request information based on the waiting time parameter.

[0096] In the example, the number of activation request messages in the task waiting queue directly reflects the pressure of the server in processing the activation request messages. A monitoring component is deployed inside the server to monitor the number of activation request messages in the task waiting queue in real time or regularly and calculate the current network load. A threshold is set to evaluate the size of the network load based on the length of the task waiting queue. If the length of the task waiting queue exceeds the threshold, the network load is considered to be heavy. Once the severity of the network load is determined, the server can determine the waiting time parameters based on a preset strategy or algorithm.

[0097] In the example, the waiting time parameter can be a fixed time interval (such as 5 seconds, 10 seconds, etc.) or a dynamically adjusted value that changes according to the real-time changes in the network load. If the network load is light, the waiting time parameter can be set shorter; if the network load is heavy, the waiting time parameter is extended accordingly to reduce the pressure on the server. After determining the waiting time parameter, the server constructs a response message containing the waiting time parameter through the communication protocol and sends the waiting time parameter to the device to be bound.

[0098] In the example, after receiving this response message, the device to be bound will parse the waiting time parameter and arrange the time to send the next activation request information accordingly. After receiving the waiting time parameter, the device to be bound will start a timer or timer to wait for the specified time interval. Once the timer reaches the set time point, the device to be bound will send the activation request information to the server again. This process may be repeated multiple times until the device to be bound is successfully bound to the server or a predetermined retry limit is reached.

[0099] The following is a detailed introduction to the business processes executed by the business module and the query module in the server.

[0100] In one implementation, the server includes a business module and a query module; the business module is used to receive activation request information and binding request information; the device to be bound is activated according to the device identification of the device to be bound, a binding relationship between the device identification of the device to be bound and the user account is established, the binding status information is obtained, and the binding status information is written into a database; the query module is used to query the binding status information of the device to be bound in the database according to the device identification of the device to be bound, and send the binding status information to the device to be bound.

[0101] In the example, the server contains two core modules: business module and query module. The two modules can communicate through internal interfaces or message queues. The business module is responsible for processing requests from clients (such as devices to be bound or application terminals), including activation request information and binding request information. The query module is responsible for persistent storage and retrieval of data, especially data related to the binding relationship between device identification and user account.

[0102] The business module receives activation request information and binding request information from the device to be bound through its network communication interface. The binding request information contains necessary parameters, such as device identification (such as MAC address, device ID, etc.), user account (such as user name, password, token, etc.) and possible additional information (such as device type, operating system version, etc.). After receiving the binding request information, the business module will perform preliminary verification to ensure that the format and content of the binding request information meet expectations.

[0103] After verifying the validity of the binding request information, the business module will check whether the device ID has been activated or bound to other user accounts. If the device ID is new or has not been bound, the business module will generate a unique activation code or token and associate it with the device ID. This activation code or token can be used in subsequent device verification and binding processes.

[0104] After the device ID is activated, the business module verifies the user's identity based on the user account (such as username and password). If the user identity verification is successful, the business module creates a new binding record to associate the device ID with the user account. The binding record contains the device ID, user account, and possible additional information such as binding time and status. After creating the binding record, the business module passes the binding status information to the query module.

[0105] After receiving the binding status information, the query module writes it to the database. The database can be a relational database or a non-relational database. Before writing to the database, the query module may perform additional validation and formatting operations to ensure the integrity and consistency of the binding status information. Once the binding status information is successfully written to the database, the query module returns a confirmation message to the business module, indicating that the binding operation has been completed.

[0106] The following is a detailed introduction to the business processes executed by the business module and the query module in the server.

[0107] In one implementation, the server includes a business module and a query module, and the method also includes: when the business module receives activation request information sent by the device to be bound, it sends a query request to the query module to query the device identification and binding status information of the user account of the device to be bound in the database; if the device identification and binding status information of the user account of the device to be bound exist in the database, the business module pushes the binding status information to the device to be bound; if the device identification and binding status information of the user account of the device to be bound do not exist in the database, the business module sends a waiting time parameter to the device to be bound.

[0108] In the example, after receiving the Nth (exemplarily set to 10) activation request information sent by the device to be bound, the business module will call the interface provided by the query module and pass the device identifier and user account as parameters to the query module. After receiving these parameters, the query module will perform a database query operation to check whether there is binding status information matching the given device identifier and user account in the database. The query results will be returned to the business module, and the business module will perform subsequent operations based on the query results.

[0109] If the query result shows that the database already has binding status information that matches the given device ID and user account, the business module will construct a response message containing the binding status information. The response message contains confirmation information of successful binding, device ID, user account, and possible additional information (such as binding time, binding validity period, etc.). The business module sends the response message to the device to be bound through the network communication interface, notifying the device to be bound that it has been successfully bound to the user account.

[0110] If the query result indicates that there is no binding status information matching the given device ID and user account in the database, the business module will determine a waiting time parameter based on the current load of the server. The waiting time parameter can be a fixed time interval (such as 5 seconds, 10 seconds, etc.) or a dynamically adjusted value that changes according to the real-time load of the server. The business module constructs a response message containing the waiting time parameter and sends it to the device to be bound through the network communication interface. After receiving the response message, the device to be bound will wait for the specified time interval according to the waiting time parameter before sending the next activation request information.

[0111] The following is a detailed introduction to the interaction process of the device binding method provided in the embodiment of the present application.

[0112] Figure 3 This is an interactive diagram of the device binding method provided in the embodiment of the present application; see Figure 3 The device binding method provided in the embodiment of the present application involves the following interactive process:

[0113] Application side: Log in to the user account on the application side, and the application side connects to the server; scan the QR code information on the application side, and the QR code information is associated with the device ID of the device to be bound; create a binding request information corresponding to the device ID; the binding request information is used to request the binding of the device ID and user account of the device to be bound; send the binding request information to the server.

[0114] Device to be bound: Display the QR code information on the display screen, the QR code information is associated with the device ID of the device to be bound; create activation request information corresponding to the device ID, and send the activation request information to the server; receive binding status information, and display the binding status information on the display screen. The binding status information is the binding status of the device ID of the device to be bound and the user account.

[0115] Server: receiving activation request information, the activation request information includes the device identification of the device to be bound; the activation request information is used to request the server to activate the device to be bound according to the device identification of the device to be bound; storing the activation request information in the task waiting queue; obtaining binding request information, the binding request information includes the device identification of the device to be bound; migrating the activation request information corresponding to the device identification from the task waiting queue to the task consumption queue; activating the device to be bound corresponding to the activation request information in the task consumption queue, establishing a binding relationship between the device to be bound and the user account, and pushing binding status information to the device to be bound.

[0116] The following is a detailed introduction to the method flow executed by the application side provided in the embodiment of the present application.

[0117] Figure 4 This is a flow chart of the device binding method provided in the embodiment of the present application. Figure 4 The device binding method provided in the embodiment of the present application is applied to the application side, and the application side performs the following steps:

[0118] Step 401: Log in to the user account of the application end, and the application end connects to the server; scan the QR code information on the application end, and the QR code information is associated with the device identification of the device to be bound.

[0119] In the example, the device to be bound is a smart device that needs to activate the device identification in the server and establish a binding relationship with the user account of the application side, such as a public network intercom. The application side can be an application side configured on a smart phone, such as the application side of a public network intercom. The application side (APP) of the public network intercom is used to implement parameter configuration such as group setting and group management as well as user management functions.

[0120] The user opens the application end of the public network intercom and enters the user name and password. The application end sends the information entered by the user to the public network server for verification. The public network server verifies the validity of the information and returns the verification result. The application end displays the information of successful or failed login based on the verification result. The user selects the "Scan QR code" function in the application end. The application end calls the camera function of the device and displays the camera preview interface. The user scans the QR code containing the device logo of the public network intercom.

[0121] The application parses the QR code content and determines the device ID. The application sends the device ID to the public network server. The public network server verifies the validity of the device ID (for example, checking whether the device ID exists in the database, whether it has been bound, etc.). If the device ID is valid and has not been bound, the public network server binds the user account to the device ID.

[0122] When the user scans the QR code on the application side, the application side will send the public network intercom device ID to the public network server, and the public network server will bind the public network intercom device ID and user account. After receiving the binding request information, the public network server needs to perform some data processing operations, such as querying the database, updating records, etc. These operations often take a certain amount of time to complete. Therefore, the public network server cannot immediately return the binding result to the public network intercom.

[0123] Step 402: Create binding request information corresponding to the device identifier; the binding request information includes the device identifier of the device to be bound; the binding request information is used to request binding of the device identifier of the device to be bound and the user account.

[0124] In the example, after associating the user account and device ID, the application creates a binding request message according to the business logic. The binding request message is sent to the server and placed in a specific queue or database, waiting for the scheduled task to process. The scheduled task (for example, running once a minute) checks the binding request message in the queue or database and processes it according to the delay time of the binding request message. When the scheduled task finds that the delay time of a binding request message has expired, the activation request message corresponding to the device ID in the binding request message is migrated from the task waiting queue to the task consumption queue. After the activation request message is migrated to the task consumption queue, the server will process these activation request messages and binding request messages in sequence.

[0125] Step 403: Send a binding request message to the server, so that the server responds to the activation request message of the device to be bound, activates the device to be bound, establishes a binding relationship between the device identifier of the device to be bound and the user account, and pushes binding status information to the device to be bound.

[0126] When the device to be bound is a public network intercom, the server is a public network server, and a listening port is configured on the public network server to receive activation request information from the public network intercom. When receiving the activation request information, the public network server parses the content of the activation request information, extracts the device identification, user account and request type of the public network intercom from the activation request information, sets the expiration time, and delivers the activation request information to the task waiting queue.

[0127] In the example, after receiving the binding request information, the public network server records the binding relationship between the device identification of the public network intercom and the user account in the database, and pushes the binding status information to the public network intercom according to the device identification of the public network intercom. The public network server pushes the binding status information to the public network intercom through a long connection, short message or other communication method.

[0128] The following is a detailed description of the method flow performed by the device to be bound provided in an embodiment of the present application.

[0129] Figure 5 A schematic diagram of the device binding method provided in the embodiment of the present application; see Figure 5 The device binding method provided in the embodiment of the present application is applied to a public network intercom, and the public network intercom performs the following steps:

[0130] Step 501: Displaying QR code information on a display screen, wherein the QR code information is associated with a device identifier of a device to be bound.

[0131] In the example, the device to be bound is a smart device that needs to activate the device identity in the server and establish a binding relationship with the user account on the application side, such as a public network intercom. Figure 1 The public network intercom adopts the public network communication chip module and realizes the cluster communication capability with the support of the operator network. The public network server in the cloud platform adopts software-defined media routing and control strategies, cooperates with the public network intercom, and provides cluster intercom services for public network users.

[0132] A QR code containing the device identification of the public network intercom is loaded on the display screen of the public network intercom. The QR code image data is sent to the display screen. After the display screen receives the QR code image data, it is displayed on the screen for the user to scan.

[0133] The user opens the public network intercom setting interface, selects the device binding function menu, and displays a QR code on the public network intercom screen. At the same time, the user can click the Add Device function option on the application interface to enter the QR code scanning state. After the application scans the QR code displayed on the public network intercom screen, the application sends the device ID of the public network intercom to the public network server for binding. The public network server establishes a binding relationship between the device ID of the public network intercom and the user account of the public network intercom in the database.

[0134] Step 502: Create activation request information corresponding to the device identification, and send the activation request information to the server; the activation request information is used to request activation of the device to be bound according to the device identification of the device to be bound, and push binding status information to the device to be bound.

[0135] In the example, while the QR code information is displayed on the screen, the public network intercom creates an activation request message. The activation request message contains the device identification of the public network intercom and necessary request parameters (such as request type, timestamp, signature, etc.). The public network intercom sends the activation request message to the public network server through the network. After receiving the activation request message, the public network server queries the database or calls the corresponding service to retrieve the binding status of the public network intercom and the user account according to the device identification in the activation request message.

[0136] When the public network intercom displays the QR code, the binding status is queried in the public network server at preset intervals. If the public network server has written the corresponding binding status information, the public network intercom can query the corresponding binding status. In this case, a prompt message "Binding Successful" is displayed on the screen of the public network intercom.

[0137] Step 503: receiving binding status information, and displaying the binding status information on a display screen, wherein the binding status information is the device identification of the device to be bound and the binding status of the user account.

[0138] In the example, the public network server encapsulates the queried binding status information into a response message and sends it back to the public network intercom through the network. After receiving the response message, the public network intercom parses the binding status information. The public network intercom sends the parsed binding status information to the display screen. After receiving the binding status information, the display screen displays it on the screen for the user to view.

[0139] The following is a detailed description of the control process of sending the activation request information to the server again.

[0140] In one implementation, the device binding method provided in the embodiment of the present application also includes the following steps: sending activation request information to the server again at a preset time interval within a first preset time period until the binding status information is received; the number of times the activation request information is sent is less than N, for example, N is a natural number 10; after the first preset time period ends, if the device to be bound does not receive the binding status information, no activation request information is sent to the server within a second preset time period; the first preset time period and the second preset time period are two consecutive time periods.

[0141] In order to avoid users waiting for a long time, a delayed message mechanism is used to process the binding status query. When the public network intercom displays the QR code, the binding status is queried in the public network server at a preset time interval (for example, 15 seconds). If the public network server has not completed data processing, the public network intercom will not receive any response. When the public network server completes data processing and writes the corresponding binding status information, the public network intercom can query the corresponding binding status. At this time, the public network intercom will display a prompt message of "binding successful" to inform the user that the binding operation has been completed.

[0142] In the example, a query request is initialized, and a first preset time period and a preset time interval are set. Figure 6 In the figure, T represents the preset time interval, t0 represents the start time of the first preset time period, t1 represents the end time of the first preset time period and the start time of the second preset time period, t2 represents the end time of the second preset time period, t represents time, and s represents seconds. Exemplarily, the first preset time period is 3 minutes and the preset time interval is 15 seconds. These parameters can be set in the configuration file on the application side, or entered by the user when the application side is started. The activation request information contains necessary request parameters, such as device identification, request type, timestamp, etc. The public network intercom uses the network communication protocol to send the activation request information to the public network server, and waits for the response of the public network server, including binding status information or error message.

[0143] Send query requests at intervals within the first preset period. Record the sending time and number of times. After sending the query request for the first time, record the sending time and initialize a counter to track the number of times it is sent. Check whether the preset time interval has been reached. Use a timer or polling mechanism to regularly check the difference between the current time and the last sending time. If the difference reaches the preset time interval, proceed to the next step and send the activation request information again.

[0144] When the preset time interval is reached, create an activation request message again (parameters such as timestamps may need to be updated). Send the new activation request message to the public network server, and update the sending time and counter. During the first preset period, send the activation request message to the public network server again until the first preset period is reached. After each query request is sent, check whether the current time exceeds the end time of the first preset period. If it exceeds the end time of the first preset period, execute the next step and stop sending the activation request message.

[0145] When the preset time interval is reached, create the activation request information again (parameters such as timestamp may need to be updated). Send the new activation request information to the public network server, and update the sending time and counter. During the first preset period, send the activation request information to the public network server again until the number of sending times exceeds the limit (for example, 10 times). After each query request is sent, check whether the counter reaches the preset sending limit N. If the counter reaches N (set to 10 times), execute the next step and stop sending the activation request information.

[0146] The following is a detailed description of the device binding apparatus provided in the embodiment of the present application, which may be a server. The method flow executed by each module in the server refers to the above method embodiment, which will not be repeated here. In practical applications, the server includes a memory and a processor, and the processor is used to execute any of the above device binding methods.

[0147] Figure 7 A schematic diagram of the structure of the device binding device provided in the embodiment of the present application Figure 1 See also Figure 7 The device binding apparatus provided in the embodiment of the present application is a server, including:

[0148] The receiving module 701 of the server is used to receive activation request information, which includes the device identification of the device to be bound; the activation request information is used to request the server to activate the device to be bound according to the device identification of the device to be bound; and the activation request information is stored in the task waiting queue.

[0149] The acquisition module 702 of the server is used to obtain binding request information, which includes the device identification of the device to be bound; the binding request information is used to request binding of the device identification of the device to be bound and the user account; and the activation request information corresponding to the device identification is migrated from the task waiting queue to the task consumption queue.

[0150] The response module 703 of the server is used to activate the device to be bound corresponding to the activation request information in the task consumption queue, establish a binding relationship between the device to be bound and the user account, and push binding status information to the device to be bound.

[0151] The following is a detailed introduction to the device binding apparatus provided in the embodiment of the present application, which may be an application end. The method flow executed by each module in the application end is referred to the above method embodiment, which will not be repeated here.

[0152] Figure 8 A schematic diagram of the structure of the device binding device provided in the embodiment of the present application Figure 2 See also Figure 8 The device binding apparatus provided in the embodiment of the present application is an application program end, including:

[0153] The scanning module 801 of the application side is used to log in to the user account of the application side, and the application side connects to the server; scans the QR code information on the application side, and the QR code information is associated with the device identification of the device to be bound.

[0154] The processing module 802 of the application side is used to create binding request information corresponding to the device identifier; the binding request information is used to request binding of the device identifier of the device to be bound and the user account.

[0155] The sending module 803 on the application side is used to send binding request information to the server, so that the server responds to the activation request information of the device to be bound, activates the device to be bound, establishes a binding relationship between the device identifier of the device to be bound and the user account, and pushes binding status information to the device to be bound.

[0156] The following is a detailed introduction to the device binding apparatus provided in the embodiment of the present application, which may be a device to be bound. The method flow executed by each module in the device to be bound is referred to the above method embodiment, which will not be repeated here.

[0157] Fig. 9 A schematic diagram of the structure of the device binding device provided in the embodiment of the present application Figure 3 See also Fig. 9 The device binding apparatus provided in the embodiment of the present application is a device to be bound, including:

[0158] The display module 901 of the device to be bound is used to display QR code information on the display screen, where the QR code information is associated with the device identification of the device to be bound.

[0159] The processing module 902 of the device to be bound is used to create activation request information corresponding to the device identification and send the activation request information to the server; the activation request information is used to request activation of the device to be bound according to the device identification of the device to be bound and push binding status information to the device to be bound.

[0160] The receiving module 903 of the device to be bound is used to receive binding status information and display the binding status information on the display screen. The binding status information is the binding status of the device identification of the device to be bound and the user account.

[0161] The description of each embodiment above tends to emphasize the differences between the embodiments, and the same or similar parts can be referenced to each other. The features disclosed in each product embodiment provided by this application can be combined arbitrarily without conflict to obtain a new product embodiment.

[0162] The product embodiments described above are only illustrative. For example, the division of units is only a logical function division. There may be other division methods in actual implementation, such as: multiple units or components can be combined, or can be integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the components shown or discussed can be through some interfaces, and the indirect coupling or communication connection of the units can be electrical or mechanical.

[0163] This specification uses the phrase "in an embodiment", which can refer to one or more embodiments of the same or different embodiments. The terms "including", "comprising", "having", etc. as used with respect to the embodiments of the present application are synonymous. The ordinal adjectives "first", "second", and "third" merely indicate that different instances of similar objects are being referenced and are not intended to imply that the objects so described must be in a given sequence in time, space, order, or in any other way.

[0164] The above are only specific implementations of the present application, but the protection scope of the present application is not limited thereto, and any changes or substitutions within the technical scope disclosed in the present application should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A device binding method, applied to a server, characterized in that: The method comprises: receiving activation request information, the activation request information including the device identification of the device to be bound; the activation request information is used to request the server to activate the device to be bound according to the device identification of the device to be bound; and storing the activation request information in a task waiting queue; Obtain binding request information, the binding request information including the device identification of the device to be bound; the binding request information is used to request binding of the device identification of the device to be bound and the user account; and migrate activation request information corresponding to the device identification from the task waiting queue to the task consumption queue; The device to be bound corresponding to the activation request information in the task consumption queue is activated, a binding relationship between the device to be bound and the user account is established, and binding status information is pushed to the device to be bound.

2. The method according to claim 1, characterized in that The task waiting queue includes a plurality of activation request information; The step of migrating the activation request information corresponding to the device identifier from the task waiting queue to the task consumption queue includes: Determine target activation request information in the task waiting queue according to the push time of each activation request information, the push time of the target activation request information being earlier than the current time; migrate the target activation request information from the task waiting queue to the task consumption queue; Alternatively, when the binding request information of the device to be bound is received, the activation request information of the device to be bound is migrated from the task waiting queue to the task consumption queue, and the binding request information of the device to be bound and the activation request information of the device to be bound correspond to the same device identifier.

3. The method according to claim 1, characterized in that: The task waiting queue includes a plurality of activation request information; The pushing the binding status information to the device to be bound includes: Determine the device identification corresponding to each activation request information, and push the corresponding binding status information to the to-be-bound device according to the device identification; The binding status information is the binding status of the device identification of the device to be bound and the user account.

4. The method according to claim 2, characterized in that: The step of determining target activation request information in the task waiting queue according to the push time of each activation request information includes: Determine a message set of multiple activation request messages in the task waiting queue; determine a push time for each activation request message in the message set; sorting the activation request information in the message set according to the push time of the activation request information to obtain a sorting result; The target activation request information is determined according to the sorting result.

5. The method according to claim 1, characterized in that The method further comprises: Determining a network load of the server, wherein the network load is positively correlated with the number of activation request information in the task waiting queue; Determining a waiting time parameter according to a network load of the server; The waiting time parameter is sent to the device to be bound, so that the device to be bound determines the time to send the next activation request information according to the waiting time parameter.

6. The method according to claim 5, characterized in that The server includes a business module and a query module; The business module is used to receive the activation request information and the binding request information; activate the device to be bound according to the device identification of the device to be bound, establish a binding relationship between the device identification of the device to be bound and the user account, obtain binding status information, and write the binding status information into a database; The query module is used to query the database for binding status information of the device to be bound according to the device identification of the device to be bound, and send the binding status information to the device to be bound.

7. The method according to claim 6, characterized in that The method further comprises: When the service module receives the activation request information sent by the device to be bound, it sends a query request to the query module to query the device identification of the device to be bound and the binding status information of the user account in the database; If the database contains the device identifier of the device to be bound and the binding status information of the user account, the service module pushes the binding status information to the device to be bound; If the device identification of the device to be bound and the binding status information of the user account do not exist in the database, the service module sends the waiting time parameter to the device to be bound.

8. A device binding apparatus, characterized in that: The device comprises: A receiving module, configured to receive activation request information, wherein the activation request information includes a device identification of a device to be bound; the activation request information is used to request a server to activate the device to be bound according to the device identification of the device to be bound; and the activation request information is stored in a task waiting queue; an acquisition module, configured to acquire binding request information, wherein the binding request information includes a device identifier of the device to be bound; the binding request information is used to request binding of the device identifier of the device to be bound and a user account; and to migrate activation request information corresponding to the device identifier from the task waiting queue to the task consumption queue; The response module is used to activate the device to be bound corresponding to the activation request information in the task consumption queue, establish a binding relationship between the device to be bound and the user account, and push binding status information to the device to be bound.

9. An electronic device, characterized in that: The electronic device comprises a memory and a processor, and the processor is used to execute the device binding method according to any one of claims 1 to 7.

10. A server, characterized in that: The server includes a memory and a processor, and the processor is used to execute the device binding method according to any one of claims 1 to 7.

Images