Remote control method and electronic equipment

Abstract

The invention discloses a remote control method and electronic equipment, and relates to the field of control, the method is applied to first equipment, and the method comprises the following steps: obtaining a target request; analyzing the target request, and determining a target task; and executing the target task based on the communication relationship with the second device and the third device, the first device transmits data to the second device in a one-way mode, the second device transmits data to the third device in a one-way mode, and the third device transmits data to the first device in a one-way mode.

Description

Technical Field

[0001] This application relates to the field of control, and more particularly to a remote control method and electronic device. Background Technology

[0002] In current enterprise or large local area network environments, there are multiple devices. To facilitate management, remote management of these devices is usually adopted.

[0003] However, when the device is integrated into an enterprise or local area network, or when operations requiring a high level of security are performed, manual control of the device is necessary, which makes operation inconvenient. Summary of the Invention

[0004] The first aspect of this application provides a remote control method applied to a first device, comprising:

[0005] Obtain the target request;

[0006] Analyze the target request to determine the target task;

[0007] Based on the communication relationship with the second and third devices, the target task is executed;

[0008] The first device transmits data unidirectionally to the second device, the second device transmits data unidirectionally to the third device, and the third device transmits data unidirectionally to the first device.

[0009] A second aspect of this application provides an electronic device applied to a first device, comprising:

[0010] An interface used to obtain the target request;

[0011] The processor is configured to parse the target request and determine the target task; execute the target task based on the communication relationship with the second device and the third device; the first device transmits data unidirectionally to the second device, the second device transmits data unidirectionally to the third device, and the third device transmits data unidirectionally to the first device.

[0012] A third aspect of this application provides a computer program product including computer-readable instructions that, when executed on an electronic terminal device, cause the electronic terminal device to implement the remote control method of the first aspect or any implementation thereof.

[0013] A fourth aspect of this application provides an electronic terminal device, comprising at least one processor and a memory connected to the processor, wherein:

[0014] The memory is used to store computer programs;

[0015] The processor is used to execute the computer program so that the electronic terminal device can implement the remote control method of the first aspect or any implementation thereof.

[0016] The fifth aspect of this application provides a computer storage medium carrying one or more computer programs, which, when executed by an electronic terminal device, enable the electronic terminal device to perform the remote control method described in the first aspect or any implementation thereof. Attached Figure Description

[0017] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale.

[0018] Figure 1 This is a schematic diagram of the remote control system structure provided in an embodiment of this application;

[0019] Figure 2 This is a flowchart illustrating a remote control method provided in an embodiment of this application;

[0020] Figure 3 This is a flowchart illustrating the process of obtaining a target request, parsing the target request, and determining the target task, provided in an embodiment of this application.

[0021] Figure 4 This is another schematic diagram of the remote control system structure provided in the embodiments of this application;

[0022] Figure 5 This is a schematic diagram of the user interface of the application platform provided in this application embodiment;

[0023] Figure 6 This is a flowchart illustrating the execution of a target task based on the communication relationship with a second device and a third device, as provided in an embodiment of this application.

[0024] Figure 7 This is a flowchart illustrating the process of obtaining a target request, parsing the target request, and determining the target task, provided in an embodiment of this application.

[0025] Figure 8 This is a flowchart illustrating the execution of a target task based on the communication relationship with the second and third devices, as provided in an embodiment of this application.

[0026] Figure 9 This is another schematic diagram of the remote control system structure provided in the embodiments of this application;

[0027] Figure 10This is yet another schematic diagram of the remote control system structure provided in the embodiments of this application;

[0028] Figure 11 This is a flowchart illustrating the process of obtaining a target request, parsing the target request, and determining the target task, provided in an embodiment of this application.

[0029] Figure 12 This is a flowchart illustrating the execution of a target task based on the communication relationship with a second device and a third device, as provided in an embodiment of this application.

[0030] Figure 13 This is a schematic diagram of the structure of an electronic device for a remote control method provided in an embodiment of this application;

[0031] Figure 14 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0032] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is for explaining specific embodiments only and is not intended to limit the scope of this application.

[0033] The embodiments of this application will now be described with reference to the accompanying drawings. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are equally applicable to similar technical problems.

[0034] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or terminal device that comprises a series of elements is not necessarily limited to those elements, but may include other elements not explicitly listed or inherent to such processes, methods, products, or terminal devices.

[0035] Figure 1 This is a schematic diagram of the remote control system structure provided in an embodiment of this application, including: a first device 101, a second device 102, and a third device 103. The first device serves as the central control device and is capable of responding to requests uploaded by the second device and the third device.

[0036] The first device can be a platform server for a remote control system, which can be a cloud server or a regular server, and it can manage a large number of devices. The devices managed by the first device can be located in different physical spaces from the first device, and each managed device can also be located in a different physical space. The second and third devices are any two of the large number of devices, and they are the devices that need to be remotely managed by the first device. The first device transmits data unidirectionally to the second device, the second device transmits data unidirectionally to the third device, and the third device transmits data unidirectionally to the first device. In the diagram, arrows indicate the direction of data transmission.

[0037] Reference Figure 2 , Figure 2 This is a flowchart illustrating a remote control method provided in an embodiment of this application. The method is applied to... Figure 1 The first device in the remote control system shown, such as Figure 1 As shown in the embodiment of this application, a remote control method may include steps 201 to 203, which are described in detail below.

[0038] 201. Obtain the target request;

[0039] The target request can be to operate a device in the remote control system, or to operate on data in the first device of the remote control system.

[0040] As an example, the target request could be a request transmitted from a third device to the first device, or it could be a request sent by another device to the first device for the first device to control the transmission of data to the third device.

[0041] This target request could be a request for devices in a remote control system that have high security requirements.

[0042] 202. Analyze the target request and determine the target task;

[0043] Based on the established parsing rules, the target request is parsed to obtain the content requested by the target request, and then the target task is determined based on the content of the request.

[0044] The target task can be a task related to a third device.

[0045] 203. Based on the communication relationship with the second and third devices, execute the target task; the first device transmits data unidirectionally to the second device, the second device transmits data unidirectionally to the third device, and the third device transmits data unidirectionally to the first device.

[0046] Since the first device can transmit data unidirectionally to the second device, the second device can transmit data unidirectionally to the third device, and the third device can transmit data unidirectionally to the first device, a unidirectional transmission route can be formed among the three. Therefore, after the first device determines the target task, it can execute the target task based on the communication relationship between the first device and the second and third devices.

[0047] In one possible implementation, the objective is to transmit data to a third device, in which case the data can be transmitted from the second device to the third device.

[0048] In one possible implementation, the target task is to respond to a request uploaded by a third device, which may be based on an upload from a second device. Therefore, executing the target task may be in response to this request.

[0049] It should be noted that the unidirectional data transmission from the first device to the second device, from the second device to the third device, and from the third device to the first device indicates that data can be transmitted between the three devices in a sequential unidirectional manner. However, it does not restrict any two devices to unidirectional transmission only; for example, the second device may also transmit data to the second device. Besides the sequential unidirectional transmission between the first, second, and third devices, other transmission directions are also possible and can be determined based on the actual situation. This application does not impose any restrictions on these directions.

[0050] In this embodiment, in the system consisting of a first device, a second device, and a third device, the first device can unidirectionally transmit data to the second device, the second device can unidirectionally transmit data to the third device, and the third device can unidirectionally transmit data to the first device. The first device receives a target request; parses the target request to determine the target task; and executes the target task based on its communication relationships with the second and third devices. This system utilizes the characteristic that each of the three devices can unidirectionally transmit data to another device. The first device, upon receiving a target request and determining the target task, executes the target task using its data transmission communication relationships with the second and third devices, thus achieving remote operation of the third device without manual intervention. Furthermore, due to the unidirectional data transmission characteristics among the three devices, data security can be guaranteed during data transmission, fulfilling the security requirements of the target request.

[0051] Figure 3 This is a flowchart illustrating the process of obtaining a target request, parsing the target request, and determining the target task, provided in an embodiment of this application. It may include steps 301 to 303, which are described in detail below.

[0052] 301. Received a power-on request;

[0053] This power-on request can be a request to power on a device that is currently powered off in the system.

[0054] The power-on request can be a request sent from another terminal to the first device. This terminal may contain a control application that requests the remote device in the system to be powered on.

[0055] The power-on request can be used to power on devices that have already joined the device cluster in the remote control system.

[0056] Figure 4 This is another schematic diagram of the remote control system structure provided in this application embodiment, including: a first device 401, a second device 402, a third device 403, and a terminal device 404. The first device 401 serves as a server device, while the second device 402 and the third device 404 are devices that need to be remotely managed by the first device 401. The terminal device 404 is equipped with a platform application that can remotely control the third device 403. The relationship of remote control between the terminal device 404 and the third device is represented by dashed lines in the diagram. The user triggers the power-on of the third device 403, which is in a powered-off state, through the operation interface of the terminal device 404, generating a power-on request, which is uploaded to the first device 401. Upon receiving the power-on request, the first device 401 executes the remote control method described in this application.

[0057] Furthermore, each device managed by the remote control system is equipped with a terminal application, enabling each device to respond to remote operations.

[0058] Figure 5 This is a schematic diagram of the operation interface of the application platform provided in this application embodiment. The interface includes the operating status and executable operations of computer 1, computer 2, and computer 3. Computer 1 is in a powered-off state, and the executable operation includes "Power on". Computers 2 and 3 are in a powered-on state, and the executable operation includes "Power off". The user can click the "Power on" button on the interface to generate a power-on request for computer 1 and upload the power-on request to the first device.

[0059] Of course, other executable operations can also be performed on this interface. Figure 5 The text is for illustrative purposes only and does not limit the specific content contained in the interface.

[0060] In one possible implementation, the remote control system may have a platform application and a terminal application corresponding to each remote device. The platform application can be installed on a mobile terminal to control the corresponding remote device, while the terminal application can be installed on each remote device to respond to remote operation commands. The platform application and the terminal application may be the same application or different parts of the same application.

[0061] As an example, this remote control system includes 10 remote devices: 7 desktop computers and 3 laptops. These devices can be controlled via mobile devices. Users of each remote device can install a terminal application on their mobile devices to remotely control the device. For example, user a can remotely control desktop computer A using the terminal application installed on their mobile phone. If the 10 remote devices belong to a company, the company's asset managers can download a remote management terminal application to their mobile phones to remotely control all 10 devices.

[0062] In one possible implementation, this remote control system also allows each device to remotely control other devices. A terminal application installed on any one device can trigger control of other devices.

[0063] As an example, the remote control system includes 5 remote devices (3 computers on the 8th floor and 2 computers on the 1st floor). For instance, the terminal of any computer on the 8th floor can trigger control of the computer on the 1st floor, thus achieving remote control.

[0064] 302. Parse the power-on request and find that the target device corresponding to the power-on request is a third device, which is in a power-off state;

[0065] The power-on request will carry information about the target device for which power-on is requested.

[0066] For example, the power-on request can carry a target device identifier, which can be a name set by the user for the third device. Based on this identifier, the hardware capability information and network information of the third device can be queried. The hardware capability information of the third device includes whether the network card of the third device supports remote power-on and the network connection method (wired or wireless). The network information can include the device address of the third device (such as MCA (Media Access Control, hardware address)), network card address, gateway IP (Internet Protocol Address), network status, whether the network card supports WoL (Wake-up On LAN), and the organization to which it belongs, etc.

[0067] Parsing the power-on request reveals that the target device is a third device, and that the third device is in a powered-off state.

[0068] Correspondingly, by parsing the boot request, information such as the device address, network card address, and local area network of the third device can also be obtained.

[0069] 303. The target task is to power on a third device that is currently powered off.

[0070] Accordingly, if the target device for powering on is determined to be the third device, then the target task for this operation is to power on the third device.

[0071] In one possible implementation, multiple devices in the system can be remotely powered on at the same time. Accordingly, each device that serves as the target device can be regarded as a third device in this application and can execute the remote control method provided in this application to remotely power on.

[0072] In one possible implementation, the device cluster to which the third device belongs can be determined first, and the target task can be determined to be to power on the third device in the device cluster.

[0073] In this embodiment, after obtaining the power-on request, the power-on request is parsed to find that the target device corresponding to the power-on request is a third device, and the third device is in a power-off state. Then, the target task is determined to be to power on the third device in the power-off state. The corresponding target task is determined for the power-on request, so as to realize the determination of the target task for remote power-on.

[0074] Figure 6 This is a flowchart illustrating the execution of a target task based on the communication relationship with a second device and a third device, provided in an embodiment of this application. It may include steps 601 to 603, which are described in detail below.

[0075] 601. Based on the target task, identify the second device in the device cluster. The second device and the third device belong to the same device cluster.

[0076] To enable remote power-on of the third device, a second device needs to be identified as a relay device. This relay device must be in the same device cluster as the target third device, and the second device must be powered on.

[0077] This device cluster can be a cluster of devices belonging to the same local area network (LAN). Of course, to improve security, the devices in this cluster can also be devices belonging to the same organization within the same LAN, such as the same company or the same department, enabling unified security management for each device and making it suitable for enterprise-level environments.

[0078] Since devices within the same local area network (LAN) can communicate within the LAN, the second device, which is powered on, acts as a relay device. This second device can receive information from the first device via the internet, and it can also send information to the third device via the LAN, thereby enabling remote power-on of the third device.

[0079] In one possible implementation, the local area network to which the third device belongs can be determined based on the information carried in the target request, such as the gateway IP and network card address (e.g., MCA), and a device that is powered on in that local area network can be selected as the second device.

[0080] When a device registers to join a device cluster, its information needs to be reported to the first device for recording. This information may include the device's hardware capabilities and network information. For example, hardware capabilities may include whether the device's network interface card (NIC) supports remote power-on, and the network connection method (wired or wireless). Network information may include some or all of the following: device identifier, device address, NIC address, gateway IP, network status, whether the NIC supports WoL (Wolf-Likely) and its affiliated organization. The device identifier is the name set by the user for the device.

[0081] The boot request can carry a target device identifier. Based on this identifier, the first device can query relevant information recorded for the third device to obtain its device address, network interface card (NIC) address, gateway IP, network status, and affiliated organization. Using this NIC address and IP information, the local area network and affiliated organization of the third device can be determined, thus identifying the device cluster to which the third device belongs.

[0082] After determining the device cluster to which the third device belongs, a device that is powered on in the device cluster can be selected as the second device. This device can be a relay device used to power on other devices in the device cluster last time, or a relay device randomly selected this time. No restrictions are placed on the selection rules in this application.

[0083] 602. Generate boot instructions based on the target task;

[0084] Since the target task is to power on a third device, a power-on command for powering on the third device can be generated accordingly.

[0085] In one possible implementation, the boot command may carry information about the third device, such as the device address of the third device.

[0086] 603. Send the power-on command to the second device so that the second device sends the power-on command to the third device based on the information transmission path within the device cluster.

[0087] Since the third device is remotely powered on by the second device acting as a relay device, the network address of the second device can also be determined during the generation of the power-on command.

[0088] After generating the power-on command, the command is sent to the second device based on its network address. Correspondingly, upon receiving the power-on command, the second device can then forward it to the third device via the local area network.

[0089] The information transmission path within the device cluster can be an information transmission path within a local area network.

[0090] In one possible implementation, the second device can convert the power-on command into a magic packet, which is a data packet developed in conjunction with the remote control application. The magic packet is then transmitted to the third device through the wired network interface of the third device to trigger the third device to power on.

[0091] In one possible implementation, the format of the magic packet can be a preset format prefix repeated N times by the MAC address of the third device's network interface card. N is a positive integer greater than 1.

[0092] For example, the format of this magic packet is: FF FFFFFFFF FF+<target MAC address repeated 16 times>, the default format prefix is ​​6 bytes, the network card MAC address is 6 bytes, and the amount of data required by this magic packet is 6+6×16=102 bytes.

[0093] The second device can send the magic packet to the local area network. The network card of the device in the local area network that is in a powered-off state will listen for data in this format. After listening to the magic packet, the network card will parse it to obtain the network card MAC address. If it matches the local machine's MAC address, the device will be triggered to start; otherwise, the magic packet will be discarded.

[0094] In one possible implementation, the remote control method further includes:

[0095] The system receives startup information from the third device, which indicates that the third device has been powered on. The third device sends startup information after receiving the power-on command from the second device.

[0096] After a device in the remote management system starts up (remotely or manually, etc.), it also reports startup information to the first device. This startup information may include hardware capability information and network information obtained during the device's self-test at startup.

[0097] After the third device is started, it sends a startup message to the first device. Therefore, based on the receipt of this startup message, it can be determined that the third device has been powered on.

[0098] To ensure the third device is powered on, the second device can periodically send the magic packet according to a preset duration until the third device is powered on.

[0099] After receiving the startup information from the third device, the first device can notify the second device, which will then stop sending startup commands to the third device.

[0100] In one possible implementation, in the remote control system, after each remote device is powered on, it sends detection data packets to the first device at a preset cycle to detect whether the remote device is in a running state. The first device can send the third device's startup message and the monitoring data packet together to the second device. After the second device reports receipt of the message, it stops sending the message.

[0101] Moreover, the second device, as a device in the device cluster, begins to monitor the local area network corresponding to the device cluster after sending a power-on command to the third device.

[0102] After a device powers on, it negotiates an address with the local area network (LAN) gateway. During this negotiation, the third device sends its network card address information to the gateway. The second device on the LAN can detect this information. When the second device detects the address negotiation between the third device and the network device, it can determine that the third device has started and can also use this information as a basis to stop sending power-on commands to the third device.

[0103] In one possible implementation, after sending a power-on command to the second device, a timer is started. If the startup information of the third device is not received within a preset time, it can be determined that the power-on of the third device by the second device has failed. Another device in operation is selected from the set of devices as the new second device (relay device), and steps 602-603 are re-executed until the third device starts.

[0104] It should be noted that data transmission between the first, second, and third devices uses MTLS and authentication tokens for two-way authentication and encrypted transmission to ensure data transmission security. However, the magic packet itself does not involve encryption, ensuring that it can start the third device even when it is powered off.

[0105] In one possible implementation, the first device records any operation in the remote control system into a log to support auditing and anomaly handling.

[0106] After the third device is powered on, it can update the current configuration and upload the updated information to the first device so that the third device can use the updated information when it is remotely powered on again in the future.

[0107] In this embodiment, based on the target task, a second device is determined within the device cluster. This second device and the third device belong to the same device cluster. A power-on command is generated based on the target task and sent to the second device, enabling the second device to forward the power-on command to the third device via the information transmission path within the device cluster. During this process, a second device belonging to the same device cluster as the third device is identified and used as a relay device to send the power-on command to the third device via the message transmission path within the device cluster, thus powering on the third device. Using a relay device for the power-on process improves the reliability of remote power-on, reduces single-point wake-up failures between the first and third devices, and overcomes the limitations of the local area network topology.

[0108] Figure 7 This is a flowchart illustrating the process of obtaining a target request, parsing the target request, and determining the target task, provided in an embodiment of this application. It may include steps 701 to 703, which are described in detail below.

[0109] 701. Received a join request to join the device cluster;

[0110] This target request can be a join request to join a device cluster.

[0111] The join request can be initiated by any device outside the device cluster.

[0112] In one possible implementation, a terminal application is installed on a device, and the user requests to join the cluster by operating the terminal application. This request can be either an active request or a passive request.

[0113] In one possible implementation, the device cluster can be a cluster of multiple devices for the same user, which can be of the same brand, and correspondingly, the first device can be a platform of that brand.

[0114] As an example, a user registers a new account on the A brand platform on the terminal application of their A brand computer and uploads the registration request to the platform server of the first device, which processes the registration request as a join request.

[0115] As an example, when a user logs into their account on the A brand platform for the first time on the terminal application of their A brand mobile phone, the account has already been registered and logged in on the computer. The login request is uploaded to the first device, which acts as the server of the A brand platform, and the first device processes the login request as a join request.

[0116] In one possible implementation, the device cluster can be a cluster of multiple devices for the same user, and these multiple devices can be from multiple brands. Correspondingly, the first device can be a platform for managing multiple devices.

[0117] For example, as a case study, a user logs into their account on the management platform for the first time on the terminal application of their Brand A mobile phone. This account has already been registered and logged in on a Brand B computer. The user uploads the login request to the first device, which acts as the management platform server. The first device then processes the login request as a join request.

[0118] In one possible implementation, the device cluster can be a cluster of multiple devices with different accounts for the same user, where the user can log in to a fixed account on each device.

[0119] As an example, a user uses account 'a' to log in to their account on the management platform using a terminal application on their mobile phone. During the login process, information about the user logging in using account 'b' on a terminal application on their computer is added. The login request for account 'a' is then uploaded to the first device, which acts as the management platform server. The first device processes this login request as a join request.

[0120] 702. Parsing the join request reveals that the device joining the cluster is a third device;

[0121] The join request will carry information about the device that is requesting to join.

[0122] For example, the join request may include information such as the device's MAC address and device code.

[0123] In one possible implementation, the first device has record information about the devices in the device cluster, and can query the relevant information of the device requesting to join in the record information to determine whether the device has not joined the device cluster.

[0124] In one possible implementation, the first device is equipped with a platform application, and each device in the device cluster can be equipped with a terminal application, through which data interaction occurs between the terminal application and the platform application. After the terminal application is installed on the third device, it sends a join request to the first device through the terminal application.

[0125] In one possible implementation, the first device manages multiple device clusters. When parsing the join request, it can obtain information about the device cluster to which the user is joining. For example, the request may be to join the device cluster of user "Zhang San," which contains Zhang San's various devices, such as Zhang San's laptop, mobile phone, and tablet.

[0126] The third device can join the device cluster passively, for example, by remotely binding with the second device in the device cluster and generating a join request; or it can join actively, for example, by actively requesting to join the device cluster, or by actively joining the device cluster through registration.

[0127] 703. The objective task is to add the third device to the device cluster.

[0128] If it is determined that the request to join the device cluster is made by a third device, then the objective task is to verify whether the third device can join the device cluster. If it can, then the third device is added to the device cluster.

[0129] In one possible implementation, if the request is to join a specific device cluster, the objective task could be to verify whether the third device can join the specific device cluster, and if so, to join the device cluster.

[0130] In this embodiment, after receiving a join request to join the device cluster, the join request is parsed to determine that the device cluster to join is a third device; accordingly, the target task is determined to be to join the device cluster with the third device. For each join request, a corresponding target task is determined to achieve the goal of determining the target task for joining the device cluster with the third device.

[0131] Figure 8 This is a flowchart illustrating the execution of a target task based on the communication relationship with a second device and a third device, as provided in this application embodiment. It may include steps 801 to 802, which are described in detail below.

[0132] 801. Parse the join request to obtain target information. The target information is the authentication information received by the third device from the second device. This authentication information can identify the identity of the second device as belonging to the device cluster.

[0133] The target information is the authentication information received by the third device from the second device, which represents the identity of the second device as belonging to the device cluster.

[0134] In one possible implementation, the authentication information can be obtained directly from the second device by the third device, or indirectly through other devices.

[0135] Parsing the join request reveals the target information carried within, indicating that the third device received authentication information from the second device, and that the third device's operation of joining the device cluster is permitted by the second device.

[0136] The authentication information can be the token of the second device, which records the ID (Identification, unique code) and operation token of the second device, which indicates that the operation is allowed.

[0137] The ID can be the serial number, IMEI (International Mobile Equipment Identity), or MEID (Mobile Equipment Identifier) ​​of the second device.

[0138] The authentication information of the second device is already stored in the first device. Subsequent embodiments will explain how the authentication information of the second device is stored in the first device; details will not be provided here.

[0139] In one possible implementation, the third device and the second device are in the same physical space, such as the same room. The third device and the second device transmit data through close-range methods, such as scanning a QR (Quick Response) code or Bluetooth, to ensure that the user of the second device is aware that the authentication information is being transmitted to the third device. Generally, the second device and the third device are used by the same user.

[0140] Figure 9 This is another schematic diagram of the remote control system structure provided in this application embodiment, including: a first device 901, a second device 902, and a third device 903. The first device 901 acts as a server device, and the second device 902 belongs to a device set. The first device manages the device set and can record information about each device in the device set. The token of the second device 902 is transferred to the third device 903, and the third device 903 uses the token to invoke the platform. The second device 902 and the third device 903 are in the same room, and the second device 902 is connected to the third device 903 via Bluetooth. The second device 902 transmits the token to the third device 903 via Bluetooth.

[0141] In one possible implementation, the third device and the second device are in different physical spaces, such as different buildings, different floors of the same building, different rooms on the same floor, or different addresses. The second device transmits authentication information to the mobile device, and the user moves the mobile device to the location of the third device to transmit the authentication information to the third device. For example, the second device and the mobile device, or the mobile device and the third device, can transmit the authentication information using methods such as scanning a QR code or Bluetooth transmission to ensure that the user of the second device is aware that the authentication information has been transmitted to the third device. Generally, the second device, the mobile terminal, and the third device are used by the same user.

[0142] The mobile device can be a mobile phone, a USB flash disk, or other mobile device, and this application does not impose any restrictions.

[0143] Figure 10 This is another schematic diagram of the remote control system structure provided in this application embodiment, including: a first device 1001, a second device 1002, a third device 1003, and a mobile device 1004. The first device 1001 serves as a server device, the second device 1002 belongs to a device set, and the first device manages the device set, recording information about each device in the set. The second device 1002 and the third device 1003 are in different physical spaces. The mobile device 1004 is connected to the second device 1002 via Bluetooth, and the token from the second device is transferred to the mobile device 1004. When a user moves the mobile device 1004 to the space where the third device 1003 is located, the mobile device 1004 connects to the third device 1003 via Bluetooth and then transfers the token from the second device 1002 to the third device 1003.

[0144] 802. If target information exists in the storage area, add the third device to the device cluster; the existence of target information indicates that the second device agrees to add the third device to the device cluster.

[0145] The storage area of ​​the first device stores the authentication information of each device in the device cluster.

[0146] The target information obtained from the join request will be queried in the storage area of ​​the first device. If the target information exists in the storage area, it indicates that the second device will uniformly join the third device to the device cluster.

[0147] Since the second device transmits data unidirectionally to the third device, the authentication information is transmitted from the second device to the third device. As the active source of information transmission, if the join request issued by the third device contains the authentication information of the second device, it can indicate that the second device agrees to add the third device to the device cluster.

[0148] To verify the validity of the authentication information in the third device's join request, the system checks the authentication information stored in the electronic device's storage area to see if the second device's authentication information exists. If it does, the authentication information in the third device's join request is considered valid, and the join request can be responded to positively, allowing the third device to join the device cluster. Otherwise, the authentication information in the third device's join request is considered invalid, and the join request can be responded to negatively, prohibiting the third device from joining the device cluster.

[0149] In one possible implementation, if the first device, which serves as the management platform server, records multiple device clusters, after confirming that the authentication information in the third device's join request is valid, it can be determined that the second device belongs to a device cluster, and the third device can be added to the device cluster to which the second device belongs.

[0150] In one possible implementation, the first device obtains authentication information by parsing the third device's join request, queries the storage area to find that the authentication information is the second device's authentication information, and can then add the third device to the device cluster where the second device resides.

[0151] For example, the device cluster to which the second device belongs is the device cluster of user "Zhang San". The third device is a tablet computer and the second device is Zhang San's mobile phone. The tablet computer connects to the mobile phone via Bluetooth and obtains its token from the mobile phone. This token can represent the authentication information of the mobile phone. The tablet computer sends a join request to the first device. The join request contains the token. After receiving the join request, the first device parses the token, determines that the token belongs to the mobile phone and that the mobile phone belongs to Zhang San, and then adds the tablet computer to Zhang San's device cluster.

[0152] Adding a third device to the device cluster can be achieved by adding the relevant information of the third device to the device list of the device cluster. This relevant information may include the device ID, MAC address, user account information, etc. This application does not limit the specific content of this relevant information.

[0153] In one possible implementation, when recording the relevant information of the third device, the recorded information of the second device can be obtained based on the authentication information of the second device and recorded as the relevant information of the third device. In addition, the ID information, MAC address, etc. of the third device are also recorded as the relevant information of the third device, so as to automatically add the third device to the device cluster without the need for manual operation of adding the device cluster to the first device.

[0154] In one possible implementation, after the first device completes the parsing of the target request and obtains the information contained in the target request, it calls the large model to perform subsequent analysis functions, determines the target task, and calls the corresponding function or method to execute the target task.

[0155] This large model is a model with massive parameters, which can be in the tens of thousands or even hundreds of millions. It has powerful data analysis and processing capabilities and can be used to analyze request instructions and determine the target task process.

[0156] Furthermore, since the third device and the second device are added to the same device cluster, they can be automatically bound together, and the data stored in the first device can be shared between them in the future.

[0157] In one possible implementation, a prompt message can also be generated and fed back to the third device to indicate whether the third device has successfully joined the device cluster or failed.

[0158] In this embodiment, the target information is obtained by parsing the join request. This target information is the authentication information received by the third device from the second device, which indicates that the second device belongs to the device cluster. If the target information exists in the storage area, it indicates that the second device agrees to add the third device to the device cluster, and the third device is added to the device cluster. By checking whether the target information in the join request exists in the storage area, it can be determined whether the join operation of the third device is agreed upon by the second device. If agreed, the third device can be added to the device cluster. This process does not require the administrator to manually add the third device to the device cluster at the first device. The user can pass the authentication information to the third device from the second device that has already joined the device cluster, and the third device can then request to join the device cluster from the first device. Since the join operation of the third device is agreed upon by the user of the second device, this join process can achieve both timely joining and information security.

[0159] Figure 11 This is a flowchart illustrating the process of obtaining a target request, parsing the target request, and determining the target task, provided in an embodiment of this application. It may include steps 1101 to 1103, which are described in detail below.

[0160] 1101. Obtain a download request to download the target file to a third device. The download request is obtained from the third device.

[0161] The target request can be a download request to download a target file to a third device, which can be sent from the third device to the first device.

[0162] The download request may include information such as the identifier of the target file, as well as the device address (MAC address) and device code of the third device.

[0163] In one possible implementation, the third device may have a terminal application installed, while the first device has a platform application installed, which can act as a cloud server. The first device performs file management and device management on the devices with the terminal application installed. File management may involve receiving and downloading files from various devices; device management may involve managing the devices recorded on the platform.

[0164] By parsing the download request, it can be determined that the requested file is a target file and that the requester is a third-party device.

[0165] 1102. Parse the download request to find that the target device is the third device in the device cluster and the download target is the target file;

[0166] By parsing the download request, it can be determined that the requested file is a target file and that the requester is a third-party device.

[0167] In one possible implementation, after parsing the download request and obtaining the requester, the requester can be verified to determine whether the requester is legitimate.

[0168] In the device list of each device cluster stored in the first device, query whether the identity information of the third device exists. If the identity information of the third device exists in the device list of any device cluster, it can be determined that the third device is a device managed by the platform. The requester is preliminarily judged to be legitimate, and subsequent steps can be executed.

[0169] 1103. The objective task is to download the target file to a third device.

[0170] If the download request is determined to be to download the target file to a third device, then the objective task is to verify whether the third device has downloaded the target file. If so, the target file will be downloaded to the third device.

[0171] In one possible implementation, if the third device belongs to a device cluster, the target task could be to verify whether the third device belonging to the device cluster is qualified to download the target file, and if so, to download the target file to the third device.

[0172] In this embodiment, after receiving a download request to download a target file to a third device, the download request is parsed to determine that the target device is a third device in the device cluster and the download target is a target file; the target task is determined to be downloading the target file to the third device. For each download request, a corresponding target task is determined to achieve the goal of determining the target task for downloading the target file to the third device.

[0173] Figure 12 This is a flowchart illustrating the execution of a target task based on the communication relationship with a second device and a third device, provided in an embodiment of this application. It may include steps 1201 to 1203, which are described in detail below.

[0174] 1201. Parse the download request to obtain the target information, which is the authentication information received by the third device from the second device;

[0175] The target information is the authentication information received by the third device from the second device, which represents the identity of the second device as belonging to the device cluster.

[0176] In one possible implementation, the authentication information can be obtained directly from the second device by the third device, or indirectly through other devices.

[0177] Parsing the download request reveals the target information carried within. This target information is the authentication information of the second device, which indicates that the third device received authentication information from the second device. Since the authentication information is data that can only be output unidirectionally by the second device, it also indicates that the third device's operation of downloading the target file is permitted by the second device.

[0178] The authentication information can be a token of the second device, which records the ID information and operation flag of the second device. The operation flag indicates that the operation is permitted. The ID can be the serial number, IMEI number, or MEID number of the second device, etc.

[0179] The authentication information of the second device is already stored in the first device. Subsequent embodiments will explain how the authentication information of the second device is stored in the first device; details will not be provided here.

[0180] The remote control system containing the second and third devices can be referred to in the aforementioned... Figure 9 and Figure 10 The second device can directly transmit the authentication information to the third device, or it can transmit the authentication information to the third device through a mobile terminal.

[0181] 1202. Based on the target information, determine the second device. If the second device and the third device belong to the same device cluster, query the target file with the first information in the storage area. The first information can identify that the target file is a file uploaded by the second device. The first information contains the authentication information of the second device.

[0182] Based on the fact that the target information contains the authentication information of the second device provided by the third device, the legitimacy of this download can be verified using this target information.

[0183] In one possible implementation, the target file and its corresponding first information can be queried in the storage area of ​​the first device. This first information is used to identify the uploader of the target file. If the target file is found and the uploader is the second device, it indicates that the target file requested by the third device exists in the first device.

[0184] In one possible implementation, the uploader of the target file on the second device can decide whether to share the target file with other devices, and can also determine whether the third device is qualified to download the target file. The authentication information of the second device carried in the download request uploaded by the third device can be compared with the authentication information of the second device stored in the storage area of ​​the first device. If the two match, then the operation of the third device to download the target file is allowed by the second device; otherwise, it is not allowed.

[0185] In one possible implementation, it can also be determined whether the third device and the second device belong to the same device cluster. Based on the authentication information in the target information, the authentication information can be queried in the storage area to determine if it belongs to the second device. The device cluster to which the second device belongs can then be determined. If the relevant information of the third device exists in the device cluster, it indicates that the third device and the second device belong to the same device cluster. Devices belonging to the same device cluster are generally from the same user. Therefore, devices in the same device cluster can be bound together, and devices with a binding relationship can share data. Otherwise, the two are not in the same device cluster.

[0186] To improve data security, the target file uploaded by the second device can only be shared with the third device if the third device and the second device belong to the same device cluster; otherwise, sharing is not allowed.

[0187] 1203. Based on the matching of the first information and the target information, the target file is sent to the third device.

[0188] If the target information of the download request matches the first information of the target file in the storage area, it indicates that the target file requested by the third device was uploaded by the second device, and the download operation of the third device is authorized by the second device, and the target file can be sent to the third device.

[0189] As an example application scenario, a user has a computer in the office and a computer at home. The office computer (as a second device) and the home computer (as a third device) are used by the user. The user obtains a file on the office computer and uploads it to the cloud server (as the first device). The office computer generates a token for the user's mobile phone. When the user returns home, they turn on their home computer, and the phone transmits the token to the home computer. The home computer then requests to download the file from the cloud server. The cloud server uses the token to verify that the home computer is authorized by the office computer and that both computers are used by the same user. Therefore, the cloud server sends the file to the home computer.

[0190] In this embodiment, the download request is parsed to obtain target information, which is the authentication information received by the third device from the second device. Based on this target information, the second device is determined. If the second device and the third device belong to the same device cluster, the devices in the same device cluster can set up binding relationships, and devices with binding relationships can share data. The target file with first information is queried in the storage area. The first information can indicate that the target file is a file uploaded by the second device. The first information includes the authentication information of the second device. Based on the matching of the first information and the target information, it is determined that the target file requested by the third device was uploaded by the second device, and the download operation of the third device was authorized by the second device. Then, the target file is sent to the third device, realizing automatic file transfer between different devices through the first device. This transmission process can achieve timely transmission and ensure information security.

[0191] In one possible implementation, the remote control method also includes:

[0192] The source of the authentication information of the second device stored in the first device, prior to receiving the target request, also includes any of the following:

[0193] 1. Based on the second device joining the device cluster, generate the authentication information of the second device; send the authentication information of the second device to the second device;

[0194] After the second device joins the device cluster, the authentication information of the second device is generated from the relevant information of the second device recorded in the first device, and the authentication information of the second device is stored in the storage area of ​​the first device.

[0195] The first device also sends authentication information to the second device, which saves the authentication information locally after receiving it, providing a basis for subsequent transmission to the third device.

[0196] Since the authentication information is generated by the first device, it is transmitted unidirectionally to the second device. The second device then transmits the authentication information unidirectionally to the third device. When the third device sends a join request and a download request to the first device, it can transmit the authentication information of the second device unidirectionally to the first device. This allows the first device to use the authentication information to determine whether the join operation and download request of the third device are legitimate and whether to respond, thereby improving the data security in the remote control system composed of the first, second, and third devices.

[0197] 2. Join the device cluster based on the second device and receive the authentication information uploaded by the second device.

[0198] After the second device joins the device cluster, it can proactively generate authentication information and upload it to the first device.

[0199] In one possible implementation, the authentication information contains fixed information, and the first device receiving the authentication information can store it in a record list, which may be a list of devices in the device cluster to which the second device belongs.

[0200] After joining the device cluster, the second device can immediately generate and upload authentication information, or it can be triggered to generate and upload information as needed.

[0201] In one possible implementation, the authentication information contains variable information. The first device can temporarily store the authentication information for a preset time period, after which it can be deleted. Within this preset time period, the first device can use the stored authentication information to process join and download requests transmitted from the third device. In this case, the second device's authentication information can be generated and uploaded to the first device on demand.

[0202] In this embodiment, before obtaining the target request, the following steps are included: generating authentication information for the second device based on the second device joining the device cluster; sending the authentication information for the second device to the second device; and receiving authentication information uploaded by the second device based on the second device joining the device cluster. The authentication information for the second device recorded in the first device can be generated and uploaded by the second device that has joined the device cluster, or it can be assigned by the first device to the second device. The authentication information for the second device recorded in the first device can be flexibly set to improve the flexibility of operation.

[0203] The above describes a remote control method provided by an embodiment of this application. The following will describe an electronic device that performs the above remote control method.

[0204] Please see Figure 13 , Figure 13 This is a schematic diagram of an electronic device for a remote control method provided in an embodiment of this application. This electronic device serves as… Figure 1 The first device in the remote control system shown, such as Figure 13 As shown, the electronic device 1300 includes:

[0205] Interface 1301 is used to obtain the target request;

[0206] This interface can use Internet transfer protocols such as HTTP (Hypertext Transfer Protocol).

[0207] Processor 1302 is used to parse target requests and determine target tasks; execute target tasks based on communication relationships with the second and third devices; the first device transmits data unidirectionally to the second device, the second device transmits data unidirectionally to the third device, and the third device transmits data unidirectionally to the first device.

[0208] The processor can be a data processing component, such as a CPU (Central Processing Unit) or an NPU (Neural Network Processing Unit).

[0209] It should be noted that the specific implementation and explanation of the processor execution steps can be found in the explanations in the foregoing method embodiments, and will not be repeated here.

[0210] In this embodiment, an interface is used to obtain a target request; a processor is used to parse the target request and determine the target task; based on the communication relationship with the second and third devices, the target task is executed; the first device transmits data unidirectionally to the second device, the second device transmits data unidirectionally to the third device, and the third device transmits data unidirectionally to the first device. Utilizing the characteristic that the first, second, and third devices can each transmit data unidirectionally to another device, the first device, upon obtaining the target request and determining the target task, executes the target task using its communication relationship with the second and third devices, thus achieving remote operation of the third device without manual intervention. Furthermore, due to the unidirectional data transmission characteristic among the three devices, data security can be guaranteed during data transmission, fulfilling the security requirements of the target request.

[0211] This application also provides an electronic terminal device in its embodiments. (See reference...) Figure 14 The diagram illustrates a structural schematic suitable for implementing the electronic terminal device in the embodiments of this application. The electronic terminal device in the embodiments of this application may include, but is not limited to, fixed terminals such as mobile phones, laptops, PDAs (personal digital assistants), PADs (tablet computers), desktop computers, etc. Figure 14 The electronic terminal device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0212] like Figure 14As shown, the electronic terminal device may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 1401, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1402 or a program loaded from a storage device 1408 into a random access memory (RAM) 1403. When the electronic terminal device is powered on, the RAM 1403 also stores various programs and data required for the operation of the electronic terminal device. The processing unit 1401, ROM 1402, and RAM 1403 are interconnected via a bus 1404. An input / output (I / O) interface 1405 is also connected to the bus 1404.

[0213] Typically, the following devices can be connected to I / O interface 1405: input devices 1406 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 1407 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1408 including, for example, memory cards, hard drives, etc.; and communication devices 1409. Communication device 1409 allows electronic terminal devices to exchange data via wireless or wired communication with other terminal devices. Although Figure 14 Electronic terminal equipment with various devices is shown; however, it should be understood that implementation or possession of all the devices shown is not required. More or fewer devices may be implemented or possessed alternatively.

[0214] This application also provides a computer program product including computer-readable instructions, which, when executed on an electronic terminal device, cause the electronic terminal device to implement any of the remote control methods provided in this application.

[0215] This application also provides a computer-readable storage medium that carries one or more computer programs. When the one or more computer programs are executed by an electronic terminal device, the electronic terminal device can implement any of the remote control methods provided in this application.

[0216] It is understood that before using the technical solutions disclosed in the various embodiments of this application, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this application in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.

[0217] For example, upon receiving a user's active request, a prompt message is sent to the user to explicitly inform them that the requested operation will require the acquisition and use of the user's personal information. This allows the user to independently choose whether to provide personal information to the software or hardware, such as the electronic terminal device, application program, server, or storage medium, that performs the operation of this application's technical solution, based on the prompt message.

[0218] As an optional but non-limiting implementation, in response to a user's active request, sending a prompt message to the user can be done via a pop-up window, where the prompt message can be presented in text format. Furthermore, the pop-up window can also include a selection control allowing the user to choose "agree" or "disagree" to provide personal information to the electronic terminal device.

[0219] It is understood that the above notification and user authorization process are merely illustrative and do not constitute a limitation on the implementation of this application. Other methods that comply with relevant laws and regulations may also be applied to the implementation of this application.

[0220] It is understood that the data involved in this technical solution (including but not limited to the data itself, the acquisition or use of the data) shall comply with the requirements of relevant laws, regulations and related provisions.

[0221] It should also be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. In addition, in the device embodiment drawings provided in this application, the connection relationship between modules indicates that they have a communication connection, which can be implemented as one or more communication buses or signal lines.

[0222] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware, or it can be implemented by special-purpose hardware including application-specific integrated circuits, special-purpose CPUs, special-purpose memory, special-purpose components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for this application, software program implementation is more often the preferred implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk, or optical disk, etc., and includes several instructions to cause a computer terminal device (which may be a personal computer, training terminal device, or network terminal device, etc.) to execute the methods described in the various embodiments of this application.

[0223] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.

[0224] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, training terminal device, or data center to another website, computer, training terminal device, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage terminal device such as a training terminal device or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).

Claims

1. A remote control method, applied to a first device, comprising: Obtain the target request; Analyze the target request to determine the target task; Based on the communication relationship with the second and third devices, the target task is executed; The first device transmits data unidirectionally to the second device, the second device transmits data unidirectionally to the third device, and the third device transmits data unidirectionally to the first device.

2. The remote control method according to claim 1, wherein obtaining the target request includes: Received a boot request; Accordingly, parsing the target request and determining the target task includes: Parsing the power-on request reveals that the target device corresponding to the power-on request is a third device, which is in a powered-off state. The target task is to power on a third device that is currently powered off.

3. The remote control method according to claim 2, wherein executing the target task based on the communication relationship with the second device and the third device includes: Based on the target task, a second device is identified in the device cluster, and the second device and the third device belong to the same device cluster; Based on the target task, a power-on command is generated; The power-on command is sent to the second device, so that the second device sends the power-on command to the third device based on the information transmission path within the device cluster.

4. The remote control method according to claim 3 further includes: Receive startup information from a third device, wherein the startup information indicates that the third device has been powered on; The third device sends the startup information after receiving the power-on command from the second device.

5. The remote control method according to claim 1, wherein obtaining the target request includes: Receive a join request to join the device cluster; Accordingly, parsing the target request and determining the target task includes: Parsing the join request reveals that the device joining the device cluster is a third device; The target task is to add the third device to the device cluster.

6. The remote control method according to claim 5, wherein executing the target task based on the communication relationship with the second device and the third device includes: The target information is obtained by parsing the join request. The target information is the authentication information received by the third device from the second device. The authentication information can characterize the identity of the second device as belonging to the device cluster. If the target information exists in the storage area, the third device will be added to the device cluster. The existence of the target information indicates that the second device agrees to add the third device to the device cluster.

7. The remote control method according to claim 1, wherein obtaining the target request includes: A download request to download a target file to a third device is obtained, wherein the download request is obtained from the third device; Accordingly, parsing the target request and determining the target task includes: Parsing the download request reveals that the target device is a third device in the device cluster and the download target is a target file. The objective task is to download the target file to a third device.

8. The remote control method according to claim 7, wherein executing the target task based on the communication relationship with the second device and the third device includes: The download request is parsed to obtain target information, which is authentication information received by the third device from the second device; Based on the target information, a second device is determined. If the second device and the third device belong to the same device cluster, the target file containing the first information is queried in the storage area. The first information can characterize that the target file is a file uploaded by the second device, and the first information includes the authentication information of the second device; Based on the matching of the first information and the target information, the target file is sent to the third device.

9. The remote control method according to claim 6 or 8, further comprising, before obtaining the target request, any one of the following: Based on the second device joining the device cluster, generate the authentication information for the second device; Send the authentication information of the second device to the second device; The device joins the device cluster based on the second device and receives the authentication information uploaded by the second device.

10. An electronic device applied to a first device, comprising: An interface used to obtain the target request; The processor is used to parse the target request and determine the target task; Based on the communication relationship with the second and third devices, the target task is executed; the first device transmits data unidirectionally to the second device, the second device transmits data unidirectionally to the third device, and the third device transmits data unidirectionally to the first device.

Images