A device authentication method, device and apparatus

Abstract

The application provides a device authentication method and device, and the method comprises the following steps: obtaining the IP address of the electronic device after the electronic device is started, and accessing the wired network based on the IP address of the electronic device; if the electronic device and the client device are not directly connected through the wireless network, a first type of prompt is generated; after a first type of physical key operation is obtained, a cloud service registration message is sent to the server, and the cloud service registration message comprises the unique device identification of the electronic device; if a successful response message returned by the server in response to the cloud service registration message is received, a second type of prompt is generated; and when a second type of physical key operation is obtained and a binding message is received, the binding relationship between the unique device identification of the electronic device and the user account is recorded. Through the technical scheme of the application, the binding security of the electronic device can be improved.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a method, apparatus and device for confirming device ownership. Background Technology

[0002] Electronic devices can consist of hardware and software, and are devices capable of independent operation. The software of an electronic device only includes the software runtime environment and operating system. The hardware of an electronic device includes signal processors, memory, communication modules, etc. In some scenarios, electronic devices cannot achieve large-capacity storage capabilities, and there is no large-capacity medium matching these capabilities. In such cases, the software portion uses API (Application Programming Interface) programming interfaces as the core of the development platform.

[0003] To establish authorization for electronic devices, the devices need to store the binding relationship between user accounts and passwords. After authorization is established, when a client device accesses the electronic device, it can send an access message carrying the user account and password. If the electronic device determines that the user account and password match the stored binding relationship, it will grant access to the client device.

[0004] However, there is no reasonable way to achieve the ownership of electronic devices in the relevant technologies. Summary of the Invention

[0005] This application provides a method for confirming ownership of an electronic device, the method comprising:

[0006] After the electronic device is started, its IP address is obtained, and the wired network is accessed based on the IP address of the electronic device.

[0007] If the electronic device and the client device are not directly connected via a wireless network, a first type of prompt is generated, which prompts the user to perform a first type of physical button operation;

[0008] After receiving the first type of physical button operation, a cloud service registration message is sent to the server, the cloud service registration message including the unique device identifier of the electronic device;

[0009] If a successful response message is received from the server in response to the cloud service registration message, indicating that the electronic device has been successfully registered, a second type of prompt is generated. The second type of prompt is used to prompt the user to perform a second type of physical button operation.

[0010] When a second type of physical button operation is obtained and a binding message is received, including a user account, the binding relationship between the unique device identifier of the electronic device and the user account is recorded.

[0011] This application provides a device for confirming device ownership, applied to electronic devices, the device comprising:

[0012] The acquisition module is used to acquire the IP address of the electronic device after the electronic device is started, and to access the wired network based on the IP address of the electronic device;

[0013] The processing module is configured to generate a first type of prompt if the electronic device and the client device are not directly connected via a wireless network, the first type of prompt being used to prompt the user to perform a first type of physical button operation;

[0014] The sending module is used to send a cloud service registration message to the server after receiving the first type of physical button operation. The cloud service registration message includes the unique device identifier of the electronic device.

[0015] The processing module is configured to generate a second type of prompt if it receives a successful response message from the server for the cloud service registration message, which indicates that the electronic device has been successfully registered. The second type of prompt is used to prompt the user to perform a second type of physical button operation.

[0016] When a second type of physical button operation is obtained and a binding message is received, including a user account, the binding relationship between the unique device identifier of the electronic device and the user account is recorded.

[0017] This application provides an electronic device, including: a processor and a machine-readable storage medium, wherein the machine-readable storage medium stores machine-executable instructions that can be executed by the processor; the processor is used to execute the machine-executable instructions to implement the device ownership confirmation method executable by the above example of this application.

[0018] As can be seen from the above technical solutions, in this embodiment, the binding relationship between the user account and the unique device identifier of the electronic device can be recorded, enabling the client device to access and operate the electronic device. Thus, even if the electronic device cannot be connected to an external display device or can not complete device authorization through operating devices such as a mouse and keyboard, device authorization can still be completed. This is a screenless authorization solution for electronic devices. By utilizing the physical contact of the electronic device's USB port or network port during the authorization process, authorization activation and addition can be achieved, thereby improving the binding security of the electronic device. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments of this application or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings of the embodiments of this application.

[0020] Figure 1 This is a flowchart illustrating a device ownership confirmation method according to one embodiment of this application;

[0021] Figure 2 This is a flowchart illustrating a device ownership confirmation method according to one embodiment of this application;

[0022] Figure 3 This is a flowchart illustrating a device ownership confirmation method according to one embodiment of this application;

[0023] Figure 4 This is a schematic diagram of the structure of a device for confirming ownership in one embodiment of this application;

[0024] Figure 5 This is a hardware structure diagram of an electronic device according to one embodiment of this application. Detailed Implementation

[0025] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to limit the application. The singular forms “a,” “the,” and “the” as used in this application and claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to any and all possible combinations comprising one or more of the associated listed items.

[0026] It should be understood that although the terms first, second, third, etc., may be used to describe various information in embodiments of this application, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" may also be interpreted as "when," "when," or "in response to a determination."

[0027] In one possible implementation, in order to achieve device authorization, an external display device can be connected to the electronic device, and operating devices such as a mouse and keyboard can be connected to the electronic device. The electronic device can then be operated through the mouse and keyboard, and authentication information such as user account and password can be entered on the electronic device. The electronic device stores the binding relationship between the user account and password, thereby completing the device authorization.

[0028] However, if an electronic device cannot be connected to an external display device, it cannot be operated using a mouse, keyboard, or other operating devices (the operating devices need to be used in conjunction with a display device; if there is no display device, the operating devices cannot be used to operate the electronic device), thus making it impossible to complete device ownership verification.

[0029] In another possible implementation, to achieve device authorization, the electronic device can support local area network (LAN) functionality (e.g., the electronic device can support Wi-Fi (Wireless Fidelity)). Client devices can establish a wireless connection with the electronic device via the LAN and log in to the electronic device's configuration interface. Username and password authentication information can be entered on the electronic device's configuration interface, and the electronic device stores the binding relationship between the username and password, thereby completing device authorization.

[0030] However, if the electronic device does not support local area network (LAN) functions (such as WIFI), the client device cannot log in to the configuration interface of the electronic device through the LAN function, and therefore cannot complete the device authorization.

[0031] In response to the above findings, this application proposes a device ownership confirmation method for electronic devices. The electronic device in this embodiment can be an embedded device or other types of devices; the type of electronic device is not limited, and an embedded device will be used as an example in the following description. An embedded device can consist of hardware and software and is a device capable of independent operation. The software content only includes the software runtime environment and operating system, while the hardware content includes signal processors, memory, communication modules, etc. Embedded devices cannot implement large-capacity storage functions and lack large-capacity media compatible with large-capacity storage capabilities. The software portion uses API programming interfaces as the core of the development platform.

[0032] In this embodiment, the embedded device can be a specified type of embedded device, meaning the device authentication method is used to authenticate the embedded device of the specified type. The specified type of embedded device refers to one where: the embedded device is not connected to a display device (i.e., authentication cannot be performed using a mouse, keyboard, or other operating device), and the embedded device and the client device do not communicate via a local area network (LAN). For example, if the embedded device does not support LAN functionality (such as Wi-Fi), the embedded device and the client device cannot establish a wireless connection (the client device cannot authenticate the embedded device through its configuration interface).

[0033] In this embodiment, device ownership confirmation refers to confirming that the user has operating rights to the embedded device and is the owner of the embedded device. For example, after the embedded device completes ownership confirmation, it can record the binding relationship between the user account and the embedded device's unique device identifier. When a client device accesses the embedded device, it can send an access message to the embedded device, and the access message carries the user account. When the embedded device determines that the user account matches the stored binding relationship (i.e., the binding relationship exists for the user account), it allows the client device to access the embedded device, that is, allows it to operate on the embedded device.

[0034] The device ownership confirmation method of this application will be described below with reference to specific embodiments.

[0035] See Figure 1 The diagram shown is a flowchart of the equipment ownership confirmation method, which includes:

[0036] Step 101: After the embedded device starts up, obtain the IP address of the embedded device and connect to the wired network based on the IP address of the embedded device.

[0037] For example, the embedded device can be an NVR (Network Video Recorder) or other types of embedded devices; there is no limitation on the type of embedded device.

[0038] For example, an embedded device can be connected to a network device (such as a router or switch) via a network cable. After the embedded device starts up (e.g., during boot or restart), if it supports DHCP (Dynamic Host Configuration Protocol), it can obtain its IP address from a DHCP server (the network device can act as a DHCP server). This IP address is then used as the embedded device's IP address. Based on this, the embedded device can access a wired network using its IP address.

[0039] For example, the DHCP protocol allows servers (such as DHCP servers) to dynamically assign IP addresses to clients (such as embedded devices). Therefore, after the embedded device starts up, it can obtain an IP address from the DHCP server, and there are no restrictions on the process of obtaining this IP address.

[0040] Step 102: After the embedded device starts up, if the embedded device and the client device are not directly connected via a wireless network, the embedded device generates a first type of prompt, which is used to prompt the user to perform a first type of physical button operation. The first type of prompt can be a prompt sound or a prompt light.

[0041] For example, to ensure the information security of embedded devices, cloud services are not enabled by default at the initial startup. Based on this, the embedded device does not enable cloud services by default upon startup, but instead generates a first type of prompt. For embedded devices that support sound prompts, the first type of prompt can be a sound, such as the embedded device providing a specific sound. For embedded devices that support light prompts, the first type of prompt can also be an indicator light, such as the embedded device providing a specific indicator light, like a light flashing three times.

[0042] For example, after the embedded device starts up, if it is learned that the embedded device and the client device are not directly connected via a wireless network, and that the embedded device is not connected to a display device, then the embedded device can generate a first type of prompt. Otherwise, if it is learned that the embedded device and the client device are directly connected via a wireless network, or that the embedded device is connected to a display device, then other methods can be used to complete the device authorization process, and there are no restrictions on this device authorization process. For ease of description, this embodiment takes the case where the embedded device and the client device are not directly connected via a wireless network and the embedded device is not connected to a display device as an example.

[0043] Step 103: The embedded device detects whether it has acquired the first type of physical button operation.

[0044] For example, when the embedded device starts up, in addition to generating the first type of prompt, the embedded device can also start a detection thread to detect the first type of physical button operation, that is, to detect whether the first type of physical button operation is obtained (i.e., by executing the first type of physical button operation on the embedded device).

[0045] If the embedded device detects a first-type physical button operation, step 103 is executed. If the embedded device does not detect a first-type physical button operation, the detection thread continues to detect the first-type physical button operation, and so on, until a first-type physical button operation is detected.

[0046] For example, the first type of physical button operation may include, but is not limited to, network cable plugging and unplugging operations, mouse button long press, or mouse button clicks, etc. There are no restrictions on the first type of physical button operation.

[0047] For example, after the embedded device generates a first-type prompt, the user can perceive this prompt and, based on it, know that a physical button operation is required. If the physical button is for plugging / unplugging a network cable, the user can unplug the network cable from the embedded device and then plug it back in, performing a plugging / unplugging operation. Upon perceiving this operation, the embedded device detects and acquires the first-type physical button operation. As another example, if the physical button is for holding down a mouse button (e.g., holding down the left and / or right mouse button for 5 seconds), the user can hold down the left or right mouse button for 5 seconds, performing a long-press operation. Upon perceiving this operation, the embedded device detects and acquires the first-type physical button operation. As yet another example, if the physical button is for counting mouse clicks (e.g., clicking the mouse three times), the user can click the mouse three times, and upon perceiving this operation, the embedded device detects and acquires the first-type physical button operation. Of course, these are just a few examples and are not intended to be limiting.

[0048] Step 104: After the embedded device receives the first type of physical button operation, it sends a cloud service registration message to the server. This cloud service registration message includes the embedded device's unique device identifier.

[0049] For example, the embedded device does not enable cloud services by default upon startup. After receiving the first type of physical button operation, it enables cloud services, that is, it starts a cloud service process, which completes the device authorization operation. All subsequent processes are executed by the cloud service process. Of course, this embodiment is not limited to the cloud service process performing the device authorization operation; it is sufficient as long as the embedded device has device authorization functionality.

[0050] After obtaining the first type of physical button operation, since the embedded device has already accessed the wired network based on the embedded device's IP address (see step 101), the embedded device can send a cloud service registration message to the server. This cloud service registration message may include the embedded device's unique device identifier.

[0051] For example, the unique device identifier of an embedded device can be its serial number or other types of identifiers. There are no restrictions on this unique device identifier, as long as it can uniquely represent the embedded device. In one possible implementation, an identification code (such as a format code, barcode, QR code, etc.) can be affixed to a designated location on the embedded device. This identification code can correspond to a unique identifier for the embedded device; that is, the embedded device stores the unique device identifier corresponding to the identification code, and this unique device identifier can be used as the unique device identifier of the embedded device. It should be noted that when a client device scans the identification code on the embedded device, the unique device identifier corresponding to that identification code can be obtained, meaning the unique identifier of the embedded device can be obtained.

[0052] The embedded device sends a cloud service registration message to the server, which may include: obtaining a unique device identifier corresponding to the stored identification code from the embedded device, and using this unique device identifier as the unique device identifier of the embedded device. Then, it generates a cloud service registration message, which includes the unique device identifier corresponding to the identification code, and sends the cloud service registration message to the server. The source IP address of the cloud service registration message can be an IP address obtained by the embedded device via DHCP.

[0053] The server can also be called a cloud server. A cloud server is a server used for registering embedded devices. The cloud server allows embedded devices to register remotely, and the cloud server can be accessed by client devices.

[0054] Step 105: After receiving the cloud service registration message, the server records the correspondence between the unique device identifier of the embedded device and the IP address of the embedded device in the registered list.

[0055] For example, the server can pre-maintain a registered list to record information about all successfully registered embedded devices. Based on this, after receiving a cloud service registration message from an embedded device, the server can parse the embedded device's unique device identifier and IP address (i.e., the source IP address of the cloud service registration message) from the cloud service registration message, and record the correspondence between the embedded device's unique device identifier and the embedded device's IP address in the registered list.

[0056] The successful registration of an embedded device is indicated by recording its unique device identifier in the registered list. In other words, the embedded device's registration is complete if its unique device identifier is in the registered list; otherwise, it has not been successfully registered.

[0057] Step 106: The server sends a success response message to the embedded device, indicating that the embedded device has been successfully registered. For example, after recording the unique device identifier of the embedded device in the registered list, the server determines that the embedded device has been successfully registered and sends a success response message to the embedded device, indicating that the embedded device has been successfully registered.

[0058] Step 107: The server sends a registration success message to the client device, which is received by the client device. This registration success message indicates that the embedded device has been successfully registered.

[0059] For example, after the embedded device generates the first type of prompt, the user can also scan the identification code on the embedded device using a client device to obtain the unique device identifier corresponding to that identification code, which is the unique device identifier of the embedded device. For instance, an identification code can be affixed to a designated part of the embedded device, and this identification code can correspond to the unique device identifier of the embedded device. Therefore, when scanning the identification code on the embedded device using a client device, the unique device identifier corresponding to that identification code can be obtained.

[0060] After obtaining the unique device identifier corresponding to the identification code, the client device can send an inquiry message to the server. This inquiry message can include the unique device identifier corresponding to the identification code, and it is used to inquire whether the embedded device corresponding to the unique device identifier has been successfully registered. If the client device receives a registration success message in response to the inquiry message within a preset time (configurable based on experience, such as 1 second), the client device will stop sending inquiry messages to the server, meaning the client device has successfully received the registration success message from the server.

[0061] If a registration success message is not received in response to the query message within a preset time period, the client device will continue to send query messages to the server after a preset time interval, and so on, until the client device receives a registration success message from the server, at which point it will stop sending query messages.

[0062] For example, each time the server receives an inquiry message from the client device, it parses the unique device identifier corresponding to the identification code from the inquiry message and determines whether the unique device identifier exists in the registered list. If the unique device identifier exists in the registered list, it means that the embedded device corresponding to the unique device identifier has been successfully registered. Therefore, the server sends a registration success message to the client device, which indicates that the embedded device has been successfully registered, prompting the client device to stop sending inquiry messages. If the unique device identifier does not exist in the registered list, it means that the embedded device corresponding to the unique device identifier has not been successfully registered. Therefore, the server does not send a registration success message to the client device, and the client device continues to send inquiry messages. When the server receives the next inquiry message, it continues to determine whether the unique device identifier exists in the registered list, and so on, until the server sends a registration success message to the client device, so that the client device knows that the embedded device has been successfully registered.

[0063] Step 108: After receiving the registration success message, the client device sends a binding message to the server. The binding message may include the user account. The binding message indicates that the user account needs to be bound, that is, it triggers the embedded device to bind the relationship between the embedded device's unique device identifier and the user account.

[0064] For example, the client device can obtain a user account, which is used to establish authorization for the embedded device. For instance, when it is necessary to operate the embedded device through user account A, then user account A is the user account used to establish authorization for the embedded device. It is important to note that the user account can be understood as the login account of the client device (i.e., the user account is registered on the client device). In other words, the user can log in to the client device through the user account and then access the embedded device through the client device.

[0065] Furthermore, users can log in to the client device using multiple user accounts (i.e., a user can register multiple user accounts). For example, a user can log in using user account A and user account B. In this case, if the user logs in using user account A, then the user can access the embedded device through the client device, meaning user account A is allowed to operate the embedded device. However, if the user logs in using user account B, then user account B is not allowed to operate the embedded device; that is, user account B is not a user account authorized by the embedded device and cannot access the embedded device.

[0066] Then, after obtaining the user account, the client device can send a binding message (also known as a binding command) to the server, which may include the user account.

[0067] Step 109: The server sends the binding message to the embedded device.

[0068] In one possible implementation, when the client device sends a binding message to the server, the binding message also includes a unique device identifier for the embedded device. For example, when the server sends a registration success message to the client device, this message carries the unique device identifier for the embedded device. The client device can parse this unique device identifier from the registration success message and include it in the binding message. Alternatively, the client device can obtain the unique device identifier corresponding to an identification code on the embedded device and include it in the binding message. Of course, these are just two examples of sources for the unique device identifier and are not intended to limit the scope of the implementation.

[0069] For example, after receiving the binding message, the server parses the unique device identifier of the embedded device from the binding message and determines whether the unique device identifier exists in the registered list. If not, the binding message is discarded. If so, since the registered list is used to record the mapping between unique device identifiers and IP addresses, the server queries the registered list for the IP address corresponding to the unique device identifier (i.e., the IP address of the embedded device), and sends the binding message to the embedded device based on the IP address.

[0070] Step 110: The embedded device receives the binding message sent by the server.

[0071] Step 111: If the embedded device receives a successful response message from the server regarding the cloud service registration message, indicating that the embedded device has successfully registered, the embedded device generates a second type of prompt, which is used to prompt the user to perform a second type of physical button operation. The second type of prompt is a prompt sound or a prompt light.

[0072] For example, referring to step 106, after receiving the cloud service registration message, the server can send a success response message to the embedded device. Based on this, in step 111, when the embedded device receives this success response message, it can generate a second type of prompt. For embedded devices that support sound prompts, the second type of prompt can be a sound, such as the embedded device providing a specific sound. For embedded devices that support light prompts, the second type of prompt can also be an indicator light, such as the embedded device providing a specific indicator light, like flashing five times.

[0073] Step 112: The embedded device detects whether it has acquired the second type of physical button operation.

[0074] For example, when the embedded device receives a successful response message, in addition to generating the second type of prompt, the embedded device can also start a detection thread to detect the second type of physical button operation, that is, to detect whether the second type of physical button operation has been acquired (i.e., by performing the second type of physical button operation on the embedded device). If the embedded device acquires the second type of physical button operation, then step 113 is executed. If the embedded device does not acquire the second type of physical button operation, then the detection thread continues to detect the second type of physical button operation, and so on, until the second type of physical button operation is detected and acquired.

[0075] For example, the second type of physical button operation may be the same as or different from the first type of physical button operation. The second type of physical button operation may include, but is not limited to, network cable plugging and unplugging operations, mouse button long press operations, or mouse button clicks, etc. There are no restrictions on the second type of physical button operation.

[0076] For example, after the embedded device generates a second type of prompt, the user can perceive this prompt and, based on it, know that a physical button needs to be pressed. If the physical button is for plugging / unplugging a network cable, the user can unplug the network cable from the embedded device and then plug it back in, performing a plugging / unplugging operation. Upon perceiving this operation, the embedded device detects and acquires the second type of physical button operation. As another example, if the physical button is for holding down a mouse button (e.g., holding down the left and / or right mouse button for 5 seconds), the user can hold down the left or right mouse button for 5 seconds, performing a long-press operation. Upon perceiving this operation, the embedded device detects and acquires the second type of physical button operation. As yet another example, if the physical button is for counting mouse clicks (e.g., clicking the mouse three times), the user can click the mouse three times, and upon perceiving this operation, the embedded device detects and acquires the second type of physical button operation. Of course, these are just a few examples and are not intended to be limiting.

[0077] Step 113: When the embedded device receives the binding message (including the user account) and obtains the second type of physical button operation, it records the binding relationship between the unique device identifier of the embedded device and the user account.

[0078] For example, after receiving a second type of physical button operation, the embedded device learns that the user has triggered device binding. Therefore, the embedded device can parse the user account from the binding message and record the binding relationship between the embedded device's unique device identifier and the user account. After the binding relationship is recorded, the embedded device can also provide a prompt sound or indicator light to indicate that the binding is complete.

[0079] Step 114: The embedded device sends the binding relationship to the server, and the server records the binding relationship between the embedded device's unique device identifier and the user account.

[0080] Step 115: The server sends an activation instruction message to the client device.

[0081] For example, after an embedded device records the binding relationship between its unique device identifier and a user account, this binding relationship is not activated (i.e., not effective). Similarly, after the server records this binding relationship, it is not activated (i.e., not effective). Based on this, the server can send an activation instruction message to the client device, which triggers the client device to activate (enable) the binding relationship.

[0082] Step 116: After receiving the activation instruction message, the client device sends an activation request message to the server. This activation request message is used to activate (enable) the binding relationship of the embedded device.

[0083] For example, if the binding relationship only needs to record the unique device identifier of the embedded device and the user account, then the activation request message does not need to carry the user password (i.e., the user password associated with the user account). If the binding relationship needs to record the unique device identifier of the embedded device, the user account, and the user password, then the activation request message may also include the user password associated with the user account.

[0084] For example, after receiving the activation instruction message, the client device can display a configuration interface to the user, where the user enters their username and password. In this way, the client device can obtain the username and password and send an activation request message to the server, which can include the username and password.

[0085] Step 117: After receiving the activation request message, the server sends the activation request message to the embedded device.

[0086] For example, the server can parse the user account and user password (optional) from the activation request message. Based on the user account, it can query the binding relationship corresponding to the embedded device, that is, the binding relationship includes the user account and the unique device identifier of the embedded device. Then, the binding relationship can be activated (taken effect). Furthermore, if the activation request message carries the user password, the user password can also be added to this binding relationship, that is, the binding relationship includes the user account, the user password, and the unique device identifier of the embedded device.

[0087] For example, the server can query the unique device identifier of the embedded device from the binding relationship. Then, the server can query the IP address corresponding to the unique device identifier (i.e., the IP address of the embedded device) from the registered list and send the activation request message to the embedded device based on the IP address.

[0088] Step 118: After receiving the activation request message, the embedded device activates (takes effect) the binding relationship corresponding to the activation request message.

[0089] For example, the embedded device can parse the user account and user password (optionally) from the activation request message. Based on the user account, it can query the binding relationship, which includes the user account and the embedded device's unique device identifier. Then, it can activate (enable) the binding relationship. Furthermore, if the activation request message carries a user password, the user password can also be added to this binding relationship, meaning the binding relationship includes the user account, user password, and the embedded device's unique device identifier.

[0090] At this point, device authorization for the embedded device is successfully completed, and binding relationships are stored on both the embedded device and the server. When a client device accesses the embedded device through the server, it can send an access message to the server, carrying the user account (or user account and password). If the server determines that the user account matches the stored binding relationship, it allows the access message to be sent to the embedded device. If the server determines that the user account does not match the stored binding relationship, it will not send the access message to the embedded device. When the embedded device receives an access message, if it determines that the user account matches the stored binding relationship, it allows the client device to access the embedded device, i.e., allows operation on the embedded device. If it determines that the user account does not match the stored binding relationship, it prohibits operation on the embedded device.

[0091] For example, during the device authorization process, it is possible to associate the same user account with multiple embedded devices. That is, the user account is recorded in the binding relationship of multiple embedded devices. In this way, the user account can access multiple embedded devices, and multiple embedded devices can provide services to the user account.

[0092] During the device authorization process, multiple user accounts are allowed to be associated with the same embedded device. That is, multiple user accounts are recorded in the binding relationship of an embedded device. In this way, multiple user accounts can access the same embedded device, and the embedded device provides services to multiple user accounts.

[0093] Embedded devices can provide video analytics services, as well as other video-related services, without limitation. For example, an embedded device can store a large number of video recordings. User accounts can access the embedded device through client devices, retrieve data from the large number of video recordings, and the embedded device will provide the data retrieval results and analysis of those results. There are no limitations on the functionality of the embedded device in this regard.

[0094] In one possible implementation, if the embedded device does not receive a binding message within a preset first time period (e.g., X minutes, where X can be configured empirically) after sending a cloud service registration message to the server, it sends a cloud service disconnection message to the server. This cloud service disconnection message includes the embedded device's unique device identifier. Upon receiving this message, the server removes the mapping between the embedded device's unique device identifier and its IP address from the registered list, indicating that the embedded device was not successfully registered and needs to re-register in subsequent processes.

[0095] For example, embedded devices may experience operational interruptions during operation, resulting in binding anomalies. To mitigate the risks associated with these anomalies, if the device fails to bind within X minutes of activating the cloud service, the cloud service needs to be disconnected to reduce security risks. Therefore, after sending the cloud service registration message, the embedded device can start a timer. If the embedded device receives the binding message before the preset first timeout (e.g., X minutes) is reached, the timer stops, and the binding is successfully completed. If the embedded device still hasn't received the binding message after the preset first timeout, the embedded device needs to disconnect the cloud service and send a cloud service disconnection message to the server.

[0096] After receiving the cloud service disconnection message, the server can remove the mapping between the unique device identifier and the IP address of the embedded device from the registered list. In other words, the server ends the registration of the embedded device and no longer executes the binding process of the embedded device, thereby reducing security risks.

[0097] In one possible implementation, if the embedded device does not receive an activation request message within a preset second time period (e.g., Y minutes, where Y can be configured empirically) after recording the binding relationship (which includes the embedded device's unique device identifier and user account, but not yet the user password), it deletes the binding relationship and sends a cloud service disconnection message to the server. This cloud service disconnection message includes the embedded device's unique device identifier. Upon receiving this cloud service disconnection message, the server deletes the binding relationship corresponding to the embedded device and removes the mapping between the embedded device's unique device identifier and its IP address from the registered list.

[0098] For example, embedded devices may experience operational flow interruptions during operation, i.e., binding anomalies. To prevent risks caused by abnormal operations, the cloud service will be automatically unbound and disconnected if the bound account (i.e., user account) is not activated within Y minutes, thereby reducing security risks.

[0099] Based on this, after recording the binding relationship between the embedded device's unique device identifier and the user account (step 113), the embedded device can start timing. If the embedded device receives an activation request message (i.e., the binding relationship is activated) before the timing reaches the preset second duration (e.g., Y minutes), the timing stops, and the binding is successfully completed. If the embedded device still has not received an activation request message when the timing reaches the preset second duration, the embedded device needs to delete the binding relationship and disconnect the cloud service.

[0100] When an embedded device disconnects from cloud services, it can send a cloud service disconnection message to the server. Upon receiving this message, the server deletes the corresponding binding relationship of the embedded device and removes the mapping between the embedded device's unique device identifier and IP address from the registered list. In other words, the server terminates the activation of the embedded device and no longer executes the binding process, thus reducing security risks.

[0101] In one possible implementation, if the binding fails within Z minutes after the client initiates the binding process, the user is prompted whether they have already confirmed the binding via physical buttons. If the user has already confirmed the binding via physical buttons, the user is recommended to add the bound device using a display device or Wi-Fi; this process is not restricted. Furthermore, to improve usability, the user is alerted via an indicator light or sound after restoring the default settings.

[0102] For example, the above execution order is merely an example for ease of description. In practical applications, the execution order between steps can be changed, and there is no limitation on this execution order. Moreover, in other embodiments, the steps of the corresponding method are not necessarily executed in the order shown and described in this specification, and the method may include more or fewer steps than described in this specification. Furthermore, a single step described in this specification may be broken down into multiple steps in other embodiments; multiple steps described in this specification may also be combined into a single step in other embodiments.

[0103] As can be seen from the above technical solutions, in this embodiment, the client device can complete device authorization through the server. This involves recording the binding relationship between the user account and the unique device identifier of the embedded device, enabling the client device to access and operate the embedded device. Thus, even if the embedded device cannot be connected to an external display device or authorized via a mouse, keyboard, or other operating devices, device authorization can still be completed through the server. This is a screenless authorization solution for embedded devices. During the authorization process, the physical contact of the embedded device's USB port or Ethernet port is used for authorization activation and addition, improving the binding security of the embedded device. Even in scenarios without a computer, Wi-Fi LAN, or display device, the embedded device can still be authorized, activated, and added using the physical contact of its USB port or Ethernet port. The real-time status of the embedded device can be displayed through sound output and indicator lights. To reduce security issues caused by accidental operation, the cloud service is disconnected after X minutes of registration without binding. If the device is not activated after Y minutes of binding, it is automatically unbound and the cloud service is shut down. To further enhance user-friendliness, if the client fails to register or bind successfully within Z minutes of initiating the binding process, the user is prompted to bind the embedded device via a display device or Wi-Fi.

[0104] See Figure 2 The diagram shown is a flowchart of the equipment ownership confirmation method, which includes:

[0105] Step 201: After the embedded device starts up, obtain the IP address of the embedded device and access the wired network based on the IP address of the embedded device.

[0106] Step 202: After the embedded device starts up, if the embedded device and the client device are not directly connected via a wireless network, the embedded device generates a first type of prompt, which is used to prompt the user to perform a first type of physical button operation. The first type of prompt can be a prompt sound or a prompt light.

[0107] Step 203: The embedded device detects whether a first-type physical button operation has been detected. If yes, proceed to step 204. If no, continue detecting whether a first-type physical button operation has been detected.

[0108] Step 204: After the embedded device receives the first type of physical button operation, it sends a cloud service registration message to the server. This cloud service registration message includes the unique device identifier of the embedded device.

[0109] Step 205: After receiving the cloud service registration message, the server records the correspondence between the unique device identifier of the embedded device and the IP address of the embedded device in the registered list.

[0110] Step 206: The server sends a success response message to the embedded device, which indicates that the embedded device has been successfully registered.

[0111] Step 207: The server sends a registration success message to the client device, which is received by the client device to indicate that the embedded device has been successfully registered.

[0112] For example, steps 201-207 can be referred to steps 101-107, and will not be repeated here.

[0113] Step 208: After receiving the registration success message, the client device sends a binding message to the server. The binding message includes the embedded device's unique device identifier, user account, and user password (the user password is the password associated with the user account and is optional).

[0114] For example, after receiving a registration success message, the client device can display a configuration interface to the user, where the user enters their user account (used to authenticate the embedded device) and the associated password. In this way, the client device obtains the user account and password. Then, the client device can send a binding message (also known as a binding command) to the server. This binding message may include the embedded device's unique device identifier, the user account, and the user password.

[0115] Step 209: The server sends the binding message to the embedded device.

[0116] Step 210: The embedded device receives the binding message sent by the server.

[0117] Step 211: If the embedded device receives a success response message from the server regarding the cloud service registration message, indicating that the embedded device has successfully registered, the embedded device generates a second type of prompt, which is used to prompt the user to perform a second type of physical button operation.

[0118] Step 212: The embedded device detects whether a second type of physical button operation has been detected. If yes, proceed to step 213. If no, continue detecting whether a second type of physical button operation has been detected.

[0119] For example, steps 209-212 can be referred to steps 109-112, and will not be repeated here.

[0120] Step 213: When the embedded device receives the binding message and obtains the second type of physical button operation, it records the binding relationship between the embedded device's unique device identifier, the user account, and the user password. The user password is optional; the binding relationship may or may not include the user password. After obtaining this binding relationship, it can be activated.

[0121] Step 214: The embedded device sends the binding relationship to the server, which records the binding relationship. This binding relationship includes the embedded device's unique device identifier and the relationship between the user account and the user password. After obtaining the binding relationship, it can be activated.

[0122] The device ownership verification has now been successfully completed, and both the embedded device and the server have a binding relationship stored.

[0123] In one possible implementation, if the embedded device does not receive a binding message within a preset first time period (e.g., X minutes, where X can be configured empirically) after sending a cloud service registration message to the server, it sends a cloud service disconnection message to the server. The cloud service disconnection message includes the embedded device's unique device identifier. Upon receiving this cloud service disconnection message, the server removes the mapping between the embedded device's unique device identifier and its IP address from the registered list.

[0124] Based on the same application concept as the above method, this application proposes a device ownership confirmation method, which can be applied to embedded devices. See [link to relevant documentation]. Figure 3 The diagram shown is a flowchart of the method, which includes:

[0125] Step 301: After the embedded device starts up, obtain the IP address of the embedded device and access the wired network based on the IP address of the embedded device.

[0126] Step 302: If the embedded device and the client device are not directly connected via a wireless network, a first type of prompt is generated. The first type of prompt is used to prompt the user to perform a first type of physical button operation.

[0127] Step 303: After obtaining the first type of physical button operation, send a cloud service registration message to the server. The cloud service registration message may include the unique device identifier of the embedded device.

[0128] Step 304: If a success response message is received from the server regarding the cloud service registration message, indicating that the embedded device has been successfully registered, a second type of prompt is generated. The second type of prompt is used to prompt the user to perform a second type of physical button operation.

[0129] Step 305: When the second type of physical button operation is obtained and the binding message is received, which includes the user account, the binding relationship between the unique device identifier of the embedded device and the user account is recorded.

[0130] For example, an identification code is deployed on the embedded device, and the embedded device stores a unique device identifier corresponding to the identification code. Based on this, sending a cloud service registration message to the server may include, but is not limited to: obtaining the unique device identifier corresponding to the stored identification code from the embedded device; generating a cloud service registration message including the unique device identifier; and sending the cloud service registration message to the server.

[0131] For example, after the embedded device sends a cloud service registration message to the server, the server records the embedded device's unique device identifier in the registered list based on the cloud service registration message.

[0132] For example, the binding message is sent by the client device to the embedded device through the server when the client device determines that the embedded device has been successfully registered. Specifically, after scanning the identification code on the embedded device, the client device sends an inquiry message to the server carrying the unique device identifier corresponding to the identification code. The inquiry message is used to inquire whether the embedded device corresponding to the unique device identifier has been successfully registered. If the registered list includes the unique device identifier, the server sends information to the client device that the embedded device has been successfully registered.

[0133] For example, recording the binding relationship between the unique device identifier of the embedded device and the user account may include, but is not limited to: if the binding message also includes the user password corresponding to the user account, then the binding relationship between the unique device identifier of the embedded device, the user account, and the user password is recorded. Alternatively, if the binding message does not include the user password corresponding to the user account, then an activation request message is obtained, which includes the user password corresponding to the user account, and the binding relationship between the unique device identifier of the embedded device, the user account, and the user password is recorded; wherein, the activation request message is sent by the client device to the embedded device through the server after receiving the activation instruction message; the activation instruction message is sent by the server to the client device when it learns that the binding message does not include the user password corresponding to the user account.

[0134] For example, if no binding message is received within a preset first time period after sending a cloud service registration message to the server, a cloud service disconnection message can be sent to the server. The cloud service disconnection message includes the unique device identifier of the embedded device. After receiving the cloud service disconnection message, the server deletes the unique device identifier of the embedded device from the registered list.

[0135] For example, if the binding message does not include the user password corresponding to the user account, and no activation request message is received within a preset second time period after the binding relationship is recorded, the binding relationship is deleted and a cloud service disconnection message is sent to the server. The cloud service disconnection message includes the unique device identifier of the embedded device. After receiving the cloud service disconnection message, the server deletes the unique device identifier of the embedded device from the registered list.

[0136] For example, the embedded device is not connected to a display device; the second type of physical button operation is the same as or different from the first type of physical button operation; wherein, the first type of physical button operation includes network cable plugging / unplugging operation, or mouse button long press operation, or mouse button click count; the second type of physical button operation includes network cable plugging / unplugging operation, or mouse button long press operation, or mouse button click count.

[0137] As can be seen from the above technical solutions, in this embodiment, the binding relationship between the user account and the unique device identifier of the electronic device can be recorded, enabling the client device to access and operate the electronic device. Thus, even if the electronic device cannot be connected to an external display device or can not complete device authorization through operating devices such as a mouse and keyboard, device authorization can still be completed. This is a screenless authorization solution for electronic devices. By utilizing the physical contact of the electronic device's USB port or network port during the authorization process, authorization activation and addition can be achieved, thereby improving the binding security of the electronic device.

[0138] Based on the same application concept as the above method, this application proposes a device ownership confirmation apparatus, which can be applied to electronic devices, such as the embedded devices described in the above embodiments. (See also...) Figure 4 The diagram shown is a structural schematic of the device, which may include:

[0139] The acquisition module 41 is used to acquire the IP address of the electronic device after the electronic device is started, and access the wired network based on the IP address of the electronic device;

[0140] Processing module 42 is used to generate a first type of prompt if the electronic device and the client device are not directly connected through a wireless network. The first type of prompt is used to prompt the user to perform a first type of physical button operation.

[0141] The sending module 43 is used to send a cloud service registration message to the server after obtaining the first type of physical button operation. The cloud service registration message includes the unique device identifier of the electronic device.

[0142] The processing module 42 is configured to generate a second type of prompt if it receives a successful response message from the server for the cloud service registration message, the successful response message indicating that the electronic device has been successfully registered. The second type of prompt is used to prompt the user to perform a second type of physical button operation.

[0143] When a second type of physical button operation is obtained and a binding message is received, including a user account, the binding relationship between the unique device identifier of the electronic device and the user account is recorded.

[0144] For example, the electronic device is equipped with an identification code and stores a unique device identifier corresponding to the identification code. When the sending module 43 sends a cloud service registration message to the server, it is specifically used to: obtain the unique device identifier corresponding to the stored identification code from the electronic device; generate a cloud service registration message including the unique device identifier; and send the cloud service registration message to the server.

[0145] For example, after the sending module 43 sends a cloud service registration message to the server, the server records the unique device identifier of the electronic device in the registered list based on the cloud service registration message; the binding message is sent by the client device to the electronic device through the server when the client device determines that the electronic device has been successfully registered; wherein, after scanning the identification code on the electronic device, the client device sends an inquiry message to the server carrying the unique device identifier corresponding to the identification code, the inquiry message is used to inquire whether the electronic device corresponding to the unique device identifier has been successfully registered; if the registered list includes the unique device identifier, the server sends information to the client device that the electronic device has been successfully registered.

[0146] For example, when the processing module 42 records the binding relationship between the unique device identifier of the electronic device and the user account, it is specifically used to: if the binding message also includes the user password corresponding to the user account, then record the unique device identifier of the electronic device, the binding relationship between the user account and the user password; or, if the binding message does not include the user password corresponding to the user account, then obtain an activation request message, the activation request message including the user password corresponding to the user account, and record the unique device identifier of the electronic device, the binding relationship between the user account and the user password; wherein, the activation request message is sent by the client device to the electronic device through the server after receiving the activation instruction message; the activation instruction message is sent by the server to the client device when it learns that the binding message does not include the user password corresponding to the user account.

[0147] For example, the sending module 43 is further configured to send a cloud service disconnection message to the server if the binding message is not received within a preset first time period after sending the cloud service registration message to the server. The cloud service disconnection message includes the unique device identifier of the electronic device. After receiving the cloud service disconnection message, the server deletes the unique device identifier of the electronic device from the registered list.

[0148] For example, the sending module 43 is further configured to delete the binding relationship and send a cloud service disconnection message to the server if the binding message does not include the user password corresponding to the user account within a preset second time period after recording the binding relationship, and if the activation request message is not received. The cloud service disconnection message includes the unique device identifier of the electronic device, and the server deletes the unique device identifier of the electronic device from the registered list after receiving the cloud service disconnection message.

[0149] For example, the electronic device is not connected to a display device; the second type of physical button operation is the same as or different from the first type of physical button operation; wherein, the first type of physical button operation includes network cable plugging / unplugging operation, or mouse button long press operation, or mouse button click count; the second type of physical button operation includes network cable plugging / unplugging operation, or mouse button long press operation, or mouse button click count.

[0150] Based on the same application concept as the method described above, this application proposes an electronic device (such as the embedded device in the above embodiments), see [link to relevant documentation]. Figure 5 As shown, the electronic device includes a processor 51 and a machine-readable storage medium 52, wherein the machine-readable storage medium 52 stores machine-executable instructions that can be executed by the processor 51; the processor 51 is used to execute the machine-executable instructions to implement the device confirmation method disclosed in the above example of this application.

[0151] Based on the same application concept as the above method, this application embodiment also provides a machine-readable storage medium storing a plurality of computer instructions, which, when executed by a processor, can implement the device confirmation method disclosed in the above example of this application.

[0152] The aforementioned machine-readable storage medium can be any electronic, magnetic, optical, or other physical storage device that can contain or store information, such as executable instructions, data, etc. For example, machine-readable storage media can be: RAM (Random Access Memory), volatile memory, non-volatile memory, flash memory, storage drives (such as hard disk drives), solid-state drives, any type of storage disk (such as optical discs, DVDs, etc.), or similar storage media, or combinations thereof.

[0153] The systems, devices, modules, or units described in the above embodiments can be implemented by a computer entity or by a product with a certain function. A typical implementation device is a computer, which can be a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email sending and receiving device, game console, tablet computer, wearable device, or any combination of these devices.

[0154] For ease of description, the above devices are described separately by function as various units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.

[0155] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, embodiments of this application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0156] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0157] Furthermore, these computer program instructions can also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in the process. Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0158] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for confirming ownership of equipment, characterized in that, Applied to electronic devices, the method includes: After the electronic device is started, its IP address is obtained, and the wired network is accessed based on the IP address of the electronic device. If the electronic device and the client device are not directly connected via a wireless network, a first type of prompt is generated, which prompts the user to perform a first type of physical button operation; After receiving the first type of physical button operation, a cloud service registration message is sent to the server, the cloud service registration message including the unique device identifier of the electronic device; If a successful response message is received from the server in response to the cloud service registration message, indicating that the electronic device has been successfully registered, a second type of prompt is generated. The second type of prompt is used to prompt the user to perform a second type of physical button operation. When a second type of physical button operation is obtained and a binding message is received, including a user account, the binding relationship between the unique device identifier of the electronic device and the user account is recorded.

2. The method according to claim 1, characterized in that, The electronic device is equipped with an identification code, and the electronic device stores a unique device identifier corresponding to the identification code. Sending the cloud service registration message to the server includes: Obtain the unique device identifier corresponding to the stored identification code from the electronic device; Generate a cloud service registration message including the unique device identifier; Send the cloud service registration message to the server.

3. The method according to claim 2, characterized in that, After the electronic device sends a cloud service registration message to the server, the server records the unique device identifier of the electronic device in the registered list based on the cloud service registration message. The binding message is sent by the client device to the electronic device through the server when the client device determines that the electronic device has been successfully registered. Specifically, after scanning the identification code on the electronic device, the client device sends an inquiry message to the server carrying a unique device identifier corresponding to the identification code. This inquiry message is used to ask whether the electronic device corresponding to the unique device identifier has been successfully registered. If the registered list includes the unique device identifier, the server sends information to the client device indicating that the electronic device has been successfully registered.

4. The method according to claim 1, characterized in that, The binding relationship between the unique device identifier of the electronic device and the user account is recorded, including: If the binding message also includes the user password corresponding to the user account, then record the unique device identifier of the electronic device and the binding relationship between the user account and the user password; or, If the binding message does not include the user password corresponding to the user account, then an activation request message is obtained. The activation request message includes the user password corresponding to the user account and records the unique device identifier of the electronic device and the binding relationship between the user account and the user password. The activation request message is sent by the client device to the electronic device through the server after receiving the activation instruction message; the activation instruction message is sent by the server to the client device when it learns that the binding message does not include the user password corresponding to the user account.

5. The method according to claim 1, characterized in that, The method further includes: If the binding message is not received within a preset first time period after sending the cloud service registration message to the server, a cloud service disconnection message is sent to the server. The cloud service disconnection message includes the unique device identifier of the electronic device. After receiving the cloud service disconnection message, the server deletes the unique device identifier of the electronic device from the registered list.

6. The method according to claim 4, characterized in that, The method further includes: If the binding message does not include the user password corresponding to the user account, and if the activation request message is not received within a preset second time period after the binding relationship is recorded, the binding relationship is deleted, and a cloud service disconnection message is sent to the server. The cloud service disconnection message includes the unique device identifier of the electronic device. After receiving the cloud service disconnection message, the server deletes the unique device identifier of the electronic device from the registered list.

7. The method according to any one of claims 1-6, characterized in that, The electronic device is not connected to a display device; the second type of physical button operation is the same as or different from the first type of physical button operation; wherein, the first type of physical button operation includes network cable plugging / unplugging operation, or mouse button long press operation, or mouse button click count; the second type of physical button operation includes network cable plugging / unplugging operation, or mouse button long press operation, or mouse button click count.

8. A device for confirming ownership of equipment, characterized in that, Applied to electronic devices, the device includes: The acquisition module is used to acquire the IP address of the electronic device after the electronic device is started, and to access the wired network based on the IP address of the electronic device; The processing module is configured to generate a first type of prompt if the electronic device and the client device are not directly connected via a wireless network, the first type of prompt being used to prompt the user to perform a first type of physical button operation; The sending module is used to send a cloud service registration message to the server after receiving the first type of physical button operation. The cloud service registration message includes the unique device identifier of the electronic device. The processing module is configured to generate a second type of prompt if it receives a successful response message from the server for the cloud service registration message, which indicates that the electronic device has been successfully registered. The second type of prompt is used to prompt the user to perform a second type of physical button operation. When a second type of physical button operation is obtained and a binding message is received, including a user account, the binding relationship between the unique device identifier of the electronic device and the user account is recorded.

9. The apparatus according to claim 8, Its features are, in, The electronic device is equipped with an identification code and stores a unique device identifier corresponding to the identification code. When the sending module sends a cloud service registration message to the server, it is specifically used to: obtain the unique device identifier corresponding to the stored identification code from the electronic device; generate a cloud service registration message including the unique device identifier; and send the cloud service registration message to the server. Specifically, after the sending module sends a cloud service registration message to the server, the server records the unique device identifier of the electronic device in the registered list based on the cloud service registration message; the binding message is sent by the client device to the electronic device through the server when the client device determines that the electronic device has been successfully registered; wherein, after scanning the identification code on the electronic device, the client device sends an inquiry message to the server carrying the unique device identifier corresponding to the identification code, the inquiry message being used to inquire whether the electronic device corresponding to the unique device identifier has been successfully registered; if the registered list includes the unique device identifier, the server sends information to the client device that the electronic device has been successfully registered; Specifically, when the processing module records the binding relationship between the unique device identifier of the electronic device and the user account, it is used for: if the binding message also includes the user password corresponding to the user account, then recording the unique device identifier of the electronic device, the binding relationship between the user account and the user password; or, if the binding message does not include the user password corresponding to the user account, then obtaining an activation request message, the activation request message including the user password corresponding to the user account, and recording the unique device identifier of the electronic device, the binding relationship between the user account and the user password; wherein, the activation request message is sent by the client device to the electronic device through the server after receiving the activation instruction message; the activation instruction message is sent by the server to the client device when it learns that the binding message does not include the user password corresponding to the user account; The sending module is further configured to send a cloud service disconnection message to the server if it does not receive the binding message within a preset first time period after sending the cloud service registration message to the server. The cloud service disconnection message includes the unique device identifier of the electronic device. After receiving the cloud service disconnection message, the server deletes the unique device identifier of the electronic device from the registered list. The sending module is further configured to, if the binding message does not include the user password corresponding to the user account, delete the binding relationship and send a cloud service disconnection message to the server if no activation request message is received within a preset second time period after the binding relationship is recorded, and the cloud service disconnection message includes the unique device identifier of the electronic device. After receiving the cloud service disconnection message, the server deletes the unique device identifier of the electronic device from the registered list. The electronic device is not connected to a display device; the second type of physical button operation is the same as or different from the first type of physical button operation; the first type of physical button operation includes network cable plugging / unplugging operation, mouse button long press operation, or mouse button click count; the second type of physical button operation includes network cable plugging / unplugging operation, mouse button long press operation, or mouse button click count.

10. An electronic device, characterized in that, include: A processor and a machine-readable storage medium, the machine-readable storage medium storing machine-executable instructions that can be executed by the processor; The processor is configured to execute machine-executable instructions to implement the method of any one of claims 1-7.

Images