A device management method, apparatus, device, storage medium, and program product

Abstract

The application provides a device management method, device, apparatus, storage medium and program product, which are applied to various scenes such as cloud technology, artificial intelligence, intelligent transportation and vehicle-mounted devices. In the device management method provided by the application, each device to be managed can provide a device management interface to display at least two devices to be managed that are bound or logged in with a same management account; and in response to a management operation on a target device to be managed, a management request is sent to a server device to enable the server device to perform management processing on the target device to be managed in response to the management request; and a device management execution result interface is provided to display a management processing result on the target device to be managed sent by the server device in response to the management request; wherein the management account binds or logs in on each device to be managed through a management client to manage at least two devices to be managed. In this way, unified management of multiple devices is achieved, and therefore the management efficiency of the devices can be improved.

Description

Technical Field

[0001] This application relates to device management technology in the field of computer applications, and more particularly to a device management method, apparatus, device, storage medium, and program product. Background Technology

[0002] With the rapid development of electronic devices, all kinds of electronic devices have emerged. Usually, a person will own multiple devices, such as portable smartphones, tablets for entertainment, laptops for mobile office work, and desktop computers for working from home; therefore, it is necessary to manage multiple devices.

[0003] Generally, in order to manage multiple devices, each device manages itself based on its own data and information; that is, the management of multiple devices is carried out separately, resulting in low management efficiency. Summary of the Invention

[0004] This application provides a device management method, apparatus, device, computer-readable storage medium, and computer program product that can improve device management efficiency.

[0005] The technical solution of this application embodiment is implemented as follows:

[0006] This application provides a device management method, including:

[0007] A device management interface is provided to display at least two devices to be managed that are bound or logged in with the same management account, wherein the management account is bound or logged in to each of the devices to be managed through a management client, so as to manage the at least two devices to be managed through the management client;

[0008] In response to a management operation on a target device to be managed, a management request is sent to a server device, so that the server device performs management processing on the target device to be managed in response to the management request, wherein the target device to be managed is any one of the at least two devices to be managed;

[0009] Provide a device management execution result interface to display the management processing result sent by the server device in response to the management request for the target device to be managed.

[0010] This application also provides a device management method, including:

[0011] The system receives a management request sent by a device to be managed, wherein the management request is sent in response to a management operation on a target device to be managed, and the target device to be managed is any one of at least two devices to be managed, the at least two devices to be managed are bound or logged in with the same management account, and the management account is bound or logged in to each device to be managed through a management client, so as to manage the at least two devices to be managed through the management client;

[0012] In response to the management request, management processing is performed on the target device to be managed;

[0013] Send the management processing result to the device to be managed, so that the device to be managed displays the management processing result for the target device on the device management execution result interface.

[0014] This application provides a device management apparatus, including:

[0015] The device display module is used to provide a device management interface to display at least two devices to be managed that are bound or logged in with the same management account. The management account is bound or logged in to each of the devices to be managed through a management client, so as to manage the at least two devices to be managed through the management client.

[0016] The management trigger module is used to send a management request to the server device in response to a management operation on the target device to be managed, so that the server device performs management processing on the target device to be managed in response to the management request, wherein the target device to be managed is any one of the at least two devices to be managed;

[0017] The result processing module is used to provide a device management execution result interface to display the management processing result sent by the server device in response to the management request for the target device to be managed.

[0018] This application embodiment also provides a device management apparatus, including:

[0019] A request receiving module is used to receive management requests sent by devices to be managed, wherein the management request is sent in response to a management operation on a target device to be managed, the target device to be managed is any one of at least two devices to be managed, the at least two devices to be managed are bound or logged in with the same management account, and the management account is bound or logged in to each device to be managed through a management client, so as to manage the at least two devices to be managed through the management client;

[0020] The device management module is used to perform management processing on the target device to be managed in response to the management request;

[0021] The result sending module is used to send management processing results to the device to be managed, so that the device to be managed can display the management processing results for the target device on the device management execution result interface.

[0022] This application provides a managed device for device management, including:

[0023] The first memory is used to store executable instructions;

[0024] The first processor, when executing executable instructions stored in the first memory, implements the device management method for a device to be managed provided in the embodiments of this application.

[0025] This application provides a server-side device for device management, including:

[0026] The second memory is used to store executable instructions;

[0027] The second processor, when executing executable instructions stored in the second memory, implements the device management method for server devices provided in the embodiments of this application.

[0028] This application provides a computer-readable storage medium storing executable instructions. When executed by a first processor, the executable instructions implement the device management method for a device to be managed provided in this application; or, when executed by a second processor, the executable instructions implement the device management method for a server device provided in this application.

[0029] This application provides a computer program product, including a computer program or instructions. When the computer program or instructions are executed by a first processor, they implement the device management method provided in this application embodiment; or, when the computer program or instructions are executed by a second processor, they implement the device management method provided in this application embodiment.

[0030] The embodiments of this application have at least the following beneficial effects: by binding or logging into the management account in the management client running on at least two devices to be managed, the management account is bound to multiple devices to be managed, so that each device to be managed can manage any one of the multiple devices to be managed; thus, unified management of multiple devices to be managed is achieved, thereby improving the management efficiency of the devices. Attached Figure Description

[0031] Figure 1This is a schematic diagram of the architecture of the device management system provided in an embodiment of this application;

[0032] Figure 2 This is provided by the embodiments of this application. Figure 1 A schematic diagram of the composition structure of one type of terminal;

[0033] Figure 3 This is provided by the embodiments of this application. Figure 1 A schematic diagram of the composition structure of a server;

[0034] Figure 4 This is an interactive illustration of the device management method provided in the embodiments of this application. Figure 1 ;

[0035] Figure 5 This is a schematic diagram of a page illustrating the device management method provided in an embodiment of this application;

[0036] Figure 6 This is an interactive illustration of the device management method provided in the embodiments of this application. Figure 2 ;

[0037] Figure 7 This is an interactive illustration of the device management method provided in the embodiments of this application. Figure 3 ;

[0038] Figure 8 This is an exemplary interactive diagram for establishing a binding relationship provided in an embodiment of this application;

[0039] Figure 9 This is an exemplary schematic diagram of a client before login provided in an embodiment of this application;

[0040] Figure 10 This is an exemplary diagram illustrating a client login process provided in an embodiment of this application;

[0041] Figure 11 This is an exemplary interaction diagram for removing a device provided in an embodiment of this application;

[0042] Figure 12 This is a schematic diagram illustrating an exemplary control working state provided in an embodiment of this application;

[0043] Figure 13 This is an exemplary interactive diagram for querying device location provided in an embodiment of this application;

[0044] Figure 14 This is a schematic diagram illustrating an exemplary function activation method provided in an embodiment of this application;

[0045] Figure 15 This is an exemplary positioning result diagram provided in an embodiment of this application;

[0046] Figure 16 This is a schematic diagram illustrating an exemplary method for enabling the location function, provided in an embodiment of this application.

[0047] Figure 17 This is an exemplary flowchart of obtaining location query results provided in an embodiment of this application;

[0048] Figure 18 This is an interactive diagram of an exemplary control device provided in an embodiment of this application;

[0049] Figure 19 This is an exemplary interactive diagram for determining device risk provided in an embodiment of this application;

[0050] Figure 20 This is an exemplary schematic diagram showing a risk status provided in an embodiment of this application;

[0051] Figure 21 This is an exemplary interactive diagram of device risk handling provided in an embodiment of this application;

[0052] Figure 22 This is a schematic diagram of an exemplary risk handling process provided in an embodiment of this application. Detailed Implementation

[0053] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0054] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0055] In the following description, the terms "first" and "second" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first" and "second" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0056] Unless otherwise defined, all technical and scientific terms used in the embodiments of this application have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used in the embodiments of this application is for the purpose of describing the embodiments of this application only and is not intended to limit this application.

[0057] In the implementation of this application, the collection and processing of relevant data should strictly comply with the requirements of relevant laws and regulations, obtain the informed consent or separate consent of the personal information subject, and carry out subsequent data use and processing within the scope of laws and regulations and the authorization of the personal information subject.

[0058] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0059] 1) A control is a triggerable piece of information displayed in the form of a button, icon, link, text, selection box, input box, tab, etc. The triggering method can be contact triggering, non-contact triggering, or instruction-based triggering, etc. In addition, the various controls in the embodiments of this application can be a single control or a collective term for multiple controls.

[0060] 2) An operation is a way to trigger a device to perform processing, such as a click operation, a double-click operation, a long press operation, a swipe operation, a gesture operation, a received trigger command, etc. In addition, the various operations in the embodiments of this application can be a single operation or a collective term for multiple operations; and the various operations in the embodiments of this application can be touch operations or non-touch operations.

[0061] 3) In response to, used to indicate the conditions or states on which the performed processing depends, when the conditions or states on which it depends are met, one or more operations performed may be performed in real time or may have a set delay; unless otherwise specified, there is no restriction on the order in which the multiple operations are performed.

[0062] 4) Client: An application running in a terminal that provides various services; this application embodiment involves a management client.

[0063] 5) Cloud computing is a computing model that distributes computing tasks across a resource pool composed of a large number of computers, enabling various application systems to obtain computing power, storage space, and information services as needed. The network providing resources to this resource pool is called the "cloud." From the user's perspective, the resources in the "cloud" are infinitely scalable, readily available, on-demand, expandable, and pay-as-you-go. In this embodiment, the server-side device can be a cloud device.

[0064] 6) Artificial Intelligence (AI) is a theory, method, technology, and application system that uses digitally controlled machines to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use that knowledge to obtain optimal results. In the embodiments of this application, risk monitoring can be implemented based on artificial intelligence.

[0065] Generally, in order to manage multiple devices, each device manages itself based on its own data and information; that is, the management of multiple devices is carried out separately, resulting in low management efficiency.

[0066] In addition, although some clients can bind multiple devices based on the same account and record a list of devices that have logged in with the same account by obtaining the device identifier, this only records the information of multiple devices and still cannot prevent the devices from managing each other.

[0067] Based on this, embodiments of this application provide a device management method, apparatus, device, computer-readable storage medium, and computer program product, which can improve device management efficiency. The exemplary applications of the device provided in this application embodiment are described below. The device provided in this application embodiment can be implemented as various types of terminals such as smartphones, smartwatches, laptops, tablets, desktop computers, smart home appliances, set-top boxes, smart in-vehicle devices, portable music players, personal digital assistants, dedicated messaging devices, smart voice interaction devices, portable gaming devices, and smart speakers, or it can be implemented as a server. The exemplary applications when the device to be managed for device management is implemented as a terminal, and the server-side device for device management is implemented as a server, will be described below.

[0068] See Figure 1 , Figure 1 This is a schematic diagram of the architecture of the device management system provided in the embodiments of this application; as shown Figure 1 As shown, to support a device management application, in the device management system 100, at least two terminals 300 (referred to as managed devices) are connected to a server 200 (referred to as server-side devices) via a network 400. The network 400 can be a wide area network (WAN), a local area network (LAN), or a combination of both. Additionally, the device management system 100 also includes a database 500 for providing data support to the server 200; and... Figure 1 The example shown illustrates a scenario where the database 500 is independent of the server 200. However, the database 500 can also be integrated into the server 200, and this embodiment does not limit this to any particular case.

[0069] Terminal 300 is used to provide a device management interface to display at least two terminals bound or logged in with the same management account, wherein the management account is bound or logged in to each terminal through a management client to manage at least two terminals through the management client; in response to a management operation for a target terminal, it sends a management request to server 200 through network 400, so that server 200 performs management processing on the target terminal in response to the management request, wherein the target terminal is any one of the at least two terminals; and receives the management processing result sent by server 200 in response to the management request through network 400, and provides a device management execution result interface to display the management processing result.

[0070] Server 200 is used to receive management requests sent by terminal 300 via network 400. The management request is sent in response to a management operation on a target terminal. The target terminal is any one of at least two terminals. The at least two terminals are bound or logged in with the same management account. The management account is bound or logged in to each terminal through a management client to manage at least two terminals through the management client. In response to the management request, server 200 performs management processing on the target terminal. Server 200 sends the management processing result to terminal 300 via network 400 so that terminal 300 displays the management processing result for the target device to be managed on the device management execution result interface.

[0071] In some embodiments, server 200 may be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. Terminal 300 may be a smartphone, smartwatch, laptop, tablet, desktop computer, smart TV, set-top box, smart in-vehicle device, portable music player, personal digital assistant, dedicated messaging device, portable gaming device, and smart speaker, but is not limited to these. Terminals and servers can be directly or indirectly connected via wired or wireless communication, which is not limited in this embodiment.

[0072] See Figure 2 , Figure 2 This is provided by the embodiments of this application. Figure 1 A schematic diagram of the structural composition of one type of terminal. Figure 2The terminal 300 shown includes at least one first processor 310, a first memory 350, at least one first network interface 320, and a first user interface 330. The various components in the terminal 300 are coupled together via a first bus system 340. It is understood that the first bus system 340 is used to implement communication between these components. In addition to a data bus, the first bus system 340 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in… Figure 2 The general designated all buses as the first bus system 340.

[0073] The first processor 310 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc., wherein the general-purpose processor can be a microprocessor or any conventional processor, etc.

[0074] The first user interface 330 includes one or more first output devices 331 that enable the display of media content, including one or more speakers and / or one or more visual displays. The first user interface 330 also includes one or more first input devices 332, including user interface components that facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, other input buttons and controls.

[0075] The first memory 350 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state storage, hard disk drives, optical disk drives, etc. The first memory 350 may optionally include one or more storage devices physically located remote from the first processor 310.

[0076] The first memory 350 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), and the volatile memory may be random access memory (RAM). The first memory 350 described in this application embodiment is intended to include any suitable type of memory.

[0077] In some embodiments, the first memory 350 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or subsets or supersets thereof, as illustrated below.

[0078] The first operating system 351 includes system programs for handling various basic system services and performing hardware-related tasks, such as the framework layer, core library layer, and driver layer, for implementing various basic business functions and handling hardware-based tasks.

[0079] The first network communication module 352 is used to reach other computer devices via one or more (wired or wireless) first network interfaces 320, exemplary first network interfaces 320 including: Bluetooth, Wi-Fi, and Universal Serial Bus (USB), etc.

[0080] The first display module 353 is configured to enable the display of information (e.g., a user interface for operating peripheral devices and displaying content and information) via one or more first output devices 331 (e.g., a display screen, a speaker, etc.) associated with the first user interface 330.

[0081] The first input processing module 354 is configured to detect and translate one or more user inputs or interactions from one or more first input devices 332.

[0082] In some embodiments, the device management apparatus provided in this application can be implemented in software. Figure 2 A device management device 355 stored in a first memory 350 is shown. This device can be software in the form of programs and plug-ins, and includes the following software modules: a device display module 3551, a management trigger module 3552, a result processing module 3553, a device binding module 3554, and an information integration module 3555. These modules are logically connected and can therefore be arbitrarily combined or further separated according to their implemented functions. The functions of each module will be described below.

[0083] See Figure 3 , Figure 3 This is provided by the embodiments of this application. Figure 1 A schematic diagram of the composition structure of a server. Figure 3 The server 200 shown includes at least one second processor 210, a second memory 250, at least one second network interface 220, and a second user interface 230. The various components of the server 200 are coupled together via a second bus system 240. It is understood that the second bus system 240 is used to implement communication between these components. In addition to a data bus, the second bus system 240 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in… Figure 3 The various buses are all labeled as the second bus system 240.

[0084] The second processor 210 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor, or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc., wherein the general-purpose processor can be a microprocessor or any conventional processor, etc.

[0085] The second user interface 230 includes one or more second output devices 231 that enable the display of media content, including one or more speakers and / or one or more visual displays. The second user interface 230 also includes one or more second input devices 232, including user interface components that facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, other input buttons and controls.

[0086] The second memory 250 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state storage, hard disk drives, optical disk drives, etc. The second memory 250 may optionally include one or more storage devices physically located remote from the second processor 210.

[0087] The second memory 250 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory, and the volatile memory may be random access memory. The second memory 250 described in the embodiments of this application is intended to include any suitable type of memory.

[0088] In some embodiments, the second memory 250 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or subsets or supersets thereof, as illustrated below.

[0089] The second operating system 251 includes system programs for handling various basic system services and performing hardware-related tasks, such as the framework layer, core library layer, and driver layer, for implementing various basic business functions and handling hardware-based tasks.

[0090] The second network communication module 252 is used to reach other computer devices via one or more (wired or wireless) second network interfaces 220, exemplary second network interfaces 220 including: Bluetooth, wireless compatibility authentication, and Universal Serial Bus, etc.

[0091] The second display module 253 is configured to enable the display of information (e.g., a user interface for operating peripheral devices and displaying content and information) via one or more second output devices 231 (e.g., a display screen, a speaker, etc.) associated with the second user interface 230.

[0092] The second input processing module 254 is used to detect and translate one or more user inputs or interactions from one or more second input devices 232.

[0093] In some embodiments, the device management apparatus provided in this application can be implemented in software. Figure 3 A device management device 255 stored in a second memory 250 is shown. This device can be software in the form of programs and plug-ins, and includes the following software modules: a request receiving module 2551, a device management module 2552, a result sending module 2553, and a device update module 2554. These modules are logically linked and can therefore be arbitrarily combined or further separated according to their implemented functions. The functions of each module will be described below.

[0094] In some embodiments, the device management device provided in this application can be implemented in hardware. As an example, the device management device provided in this application can be a processor in the form of a hardware decoding processor, which is programmed to execute the device management method provided in this application. For example, the processor in the form of a hardware decoding processor can be one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0095] In some embodiments, the terminal or server can implement the device management method provided in this application by running a computer program. For example, the computer program can be a native program or software module in an operating system; it can be a native application (APP), that is, a program that needs to be installed in the operating system to run, such as a device management APP; it can also be a mini-program, that is, a program that only needs to be downloaded into a browser environment to run; or it can be a mini-program that can be embedded in any APP. In short, the above-mentioned computer program can be any form of application, module or plugin.

[0096] The device management method provided in this application will be described below with reference to exemplary applications and implementations of the managed device and server device provided in the embodiments of this application. Furthermore, the device management method provided in this application can be applied to various scenarios such as cloud technology, artificial intelligence, smart transportation, and vehicle-mounted systems.

[0097] See Figure 4 , Figure 4 This is an interactive illustration of the device management method provided in the embodiments of this application. Figure 1 , will combine Figure 4 The steps shown are explained.

[0098] S401. The device to be managed provides a device management interface to display at least two devices bound or logged in with the same management account.

[0099] In this embodiment, the same client for managing is run on multiple electronic devices, and the same management account is bound or logged in on the management client running on each of the multiple electronic devices. Each electronic device with the management account bound or logged in is considered a device to be managed. Therefore, for multiple electronic devices, there are at least two devices to be managed corresponding to the management account being bound or logged in. Here, each device to be managed can obtain information about at least two devices bound or logged in with the same management account, and can display these at least two devices through the device management interface.

[0100] It should be noted that the management account is used to bind or log in to the management client running on at least two devices to be managed. The management client is used to manage at least two devices to be managed. That is, the management account is bound or logged in to each device to be managed through the management client, so as to manage at least two devices to be managed through the management client. In addition, the management account bound or logged in on at least two devices to be managed is the same account, the management client running on at least two devices to be managed is the same client, and the management client running on each device to be managed is compatible with the operating system of that device. Furthermore, at least two devices to be managed include at least one operating system. That is, at least two devices to be managed can be the same operating system or different operating systems. Here, when at least two devices to be managed include at least two operating systems, it indicates that at least two devices to be managed are multiple devices to be managed across system platforms. Here, on the device management interface, at least two devices to be managed can be displayed in a list format, or at least two devices to be managed can be displayed in a card format, etc., and this application embodiment does not limit this.

[0101] S402. In response to a management operation targeting the device to be managed, the device to be managed sends a management request to the server device.

[0102] In this embodiment, when a user manages any one of the at least two devices displayed in the list of devices to be managed, the managed device receives a management operation for that target device. In response to this management operation, the managed device sends a management request to a server device, causing the server device to perform management processing on the target device. The management request is used to request the server device to perform management processing on the target device, and the server device is the backend server corresponding to the management client.

[0103] It should be noted that any one of the at least two devices to be managed can manage itself, and can also manage other devices to be managed besides itself; that is, each device to be managed can manage any one of the at least two devices to be managed. Here, the device to be managed is called the target device to be managed, and the target device to be managed is any one of the at least two devices to be managed.

[0104] It should also be noted that a management request is a response sent by any device to be managed in response to a management operation targeting a target device to be managed. The target device to be managed is any one of at least two devices to be managed, and each device to be managed is a device in which the management account is bound or logged in.

[0105] In addition, the device management interface can display corresponding device management information for each device to be managed, such as device name, device icon, available space, whether it is a local device, device details, device operation information, working status, risk status, and removal entry.

[0106] S403. The server device responds to the management request and performs management processing on the target device to be managed.

[0107] In this embodiment, when a device to be managed sends a management request to a server device, the server device receives the management request. In response, the server device performs management processing on the target device. This management processing can be achieved by processing the device information of the target device, or by sending management instructions adapted to the management request to the target device, etc. This embodiment does not limit the scope of the implementation.

[0108] It should be noted that the management process includes at least one of the following: equipment removal, equipment status control, equipment location, and equipment risk handling. Specifically, equipment removal refers to the process of removing the target equipment from at least two equipment to be managed; equipment location refers to the process of locating the target equipment to be managed; equipment status control refers to the process of controlling the working status of the target equipment to be managed; and equipment risk handling refers to the process of handling the risks of the target equipment to be managed.

[0109] It should also be noted that when the server device responds to a management request and sends a management instruction to the target device to be managed, so that the target device to be managed can execute the management instruction to complete the management process, the management instruction includes at least one of a status control instruction, a location instruction, and a risk handling instruction; wherein, the status control instruction is an instruction to control the working state of the target device to change to the target working state, the location instruction is an instruction to obtain the location of the target device to be managed, and the risk handling instruction is an instruction to perform risk handling on the target device to be managed.

[0110] S404. The server device sends the management processing result to the device to be managed.

[0111] In this embodiment of the application, after the server device completes the management process on the target device to be managed, it obtains the management process result. Here, the management process result may be the processing result generated by processing the device information of the target device to be managed, or it may be the information received from the target device to be managed after executing the management instruction, etc. This embodiment of the application does not limit this.

[0112] It should be noted that after the server-side device obtains the management processing result, it will send the management processing result to each device to be managed, so that each device to be managed can display the device update information of the target device to be managed based on the management processing result.

[0113] S405. The device to be managed provides a device management execution result interface to display the management processing results sent by the server in response to the management request for the target device to be managed.

[0114] In this embodiment of the application, after the server device sends the management processing result to each device to be managed, the device to be managed also receives the management processing result; then, the device to be managed updates the relevant information of the target device to be managed based on the management processing result, and displays the device update information of the target device to be managed, so as to display the management processing result sent by the server device in response to the management request for the target device to be managed.

[0115] For example, see Figure 5 , Figure 5 This is a schematic diagram of a device management method provided in an embodiment of this application; as shown Figure 5As shown, page 5-1 includes a multi-device management prompt message 5-11 (Managing your 4 devices), at least two devices to be managed 5-12 (Phone A|local|94G, Phone B|7.9G, Phone C|6.6G, Computer D), and a device addition entry 5-13. The device addition entry 5-13 is used to trigger the establishment of a binding between a new electronic device and at least two devices to be managed.

[0116] Understandably, by binding or logging into management accounts in management clients running on at least two devices to be managed, the management account is linked to multiple devices, allowing each device to manage any one of the multiple devices. This achieves unified management of multiple devices, thereby improving management efficiency. Furthermore, when at least two devices to be managed include at least two different operating systems, it indicates that these are cross-platform devices, enabling multi-device management across different platforms and enhancing the versatility of device management.

[0117] See Figure 6 , Figure 6 This is an interactive illustration of the device management method provided in the embodiments of this application. Figure 2 ;like Figure 6 As shown, S406 to S410 are included before S401; that is, before the device to be managed provides a device management interface to display at least two devices to be managed that are bound or logged in with the same management account, the device management method also includes S406 to S410. The steps are explained below.

[0118] S406. The device to be managed receives a success message after binding to the management account or logging into the locally running management client.

[0119] It should be noted that the binding relationship between at least two devices under management is established based on the same management account. Each device under management establishes an association with at least one other device under management that is already bound or logged in to the management account by running a local management client, thereby enabling the mutual management of multiple devices. Here, a success message indicates that the management account has successfully bound or logged in on the management client running on the device under management.

[0120] In this embodiment of the application, when the device to be managed is running a management client locally, an account binding or login entry is displayed. By responding to the account binding or login operation of the account binding or login entry, the management account is bound or logged in on the management client running locally.

[0121] S407. The device to be managed sends its local device identifier to the server device based on the success message.

[0122] In this embodiment, after the device to be managed determines that the management account has successfully logged in on the management client it is running based on the success information, it sends its own device identifier (i.e., the local device identifier) ​​to the server device, so that the server device updates the corresponding device to be managed to the device list corresponding to the management account based on the device identifier.

[0123] S408. The server device updates the corresponding device to be managed to the device list corresponding to the management account based on the device identifier, and obtains the first device update data.

[0124] In this embodiment, when the device to be managed sends a device identifier to the server device, the server device receives the device identifier. Then, the server device adds the device to be managed corresponding to the device identifier to the device list corresponding to the management account and generates first device update data. Here, for the added device to be managed, the first device update data is the device list after the addition; while for the devices to be managed that are already in the device list, the first device update data refers to the difference data between the device list after the addition and the device list before the addition.

[0125] It should be noted that the device list corresponding to the management account includes all devices to be managed that are in a bound or logged-in state by the management account; the first device update data refers to the device update data in the device list, and specifically refers to the update data for adding devices to be managed to the device list.

[0126] S409. The device to be managed receives the first device update data sent by the server device for the device identifier.

[0127] In this embodiment, after obtaining the first device update data, the server device sends the first device update data to each device to be managed in the current device list; at this time, the devices to be managed also receive the first device update data. Here, the server device can use a broadcast method to send the first device update data to each device to be managed in the current device list to achieve synchronization of the current device list.

[0128] S410. Based on the updated data of the first device, the device to be managed obtains at least two devices bound or logged in with the same management account.

[0129] It should be noted that the devices to be managed are updated based on the data from the first device, and can obtain at least two devices to be managed in the current device list.

[0130] It is understandable that by binding or logging into the management client running on different electronic devices using the same management account, multiple electronic devices associated with the same management account can be obtained, thus providing the conditions for mutual management between multiple electronic devices; in this way, mutual management between multiple electronic devices can be achieved, improving the efficiency of device management.

[0131] In this embodiment of the application, when the management process includes device removal, the management operation is a removal operation and the management request is a device removal request; S402 can be implemented through S4021 (not shown in the figure); that is, the device to be managed responds to the management operation for the target device to be managed by sending a management request to the server device, including S4021, and after S4021, it also includes S4022 (not shown in the figure). The steps are described below.

[0132] S4021. In response to a removal operation targeting the device to be managed, the device to be managed sends a device removal request to the server device.

[0133] It should be noted that in the device management interface, each managed device also displays a removal control for removing the managed device (such as an unbind button or a remove device button). When a user removes the target managed device from at least two managed devices by triggering the removal control corresponding to the target managed device, the managed device receives the removal operation for the target managed device. At this time, the managed device responds to the removal operation by sending a device removal request to the server device. The device removal request is used to request the removal of the target managed device from the current device list.

[0134] S4022. In response to the device removal request, the server device changes the login status of the management account in the target device to be managed and obtains the updated data of the second device.

[0135] In this embodiment of the application, after the device to be managed sends a device removal request to the server device, the server device also receives the device removal request. At this time, in response to the device removal request, the server device changes the binding status of the management account in the target device to the unbound status, or changes the login status to the offline status, and removes the target device to be managed from the current device list.

[0136] It should be noted that the second device update data refers to the difference between the device list after removal and the device list before removal, and it is the update data of the device to be managed removed from the device list; the management processing result includes the second device update data.

[0137] Here, the server-side device sends the second device update data to each device to be managed in the removed device list, and sends an unbinding notification or offline notification to the target managed device.

[0138] Accordingly, in this embodiment of the application, the device to be managed in S405 provides a device management execution result interface to display the management processing result sent by the server device in response to the management request for the target device to be managed, including S4051 and S4052. Each step is described below.

[0139] S4051. The set of devices to be managed is determined based on the second device update data sent by the server device in response to the device removal request.

[0140] In this embodiment, the server device sends second device update data to the device to be managed, and the device to be managed receives the second device update data. At this time, the device to be managed updates its own device list based on the second device update data, that is, removes the target device to be managed from at least two devices to obtain a set of devices to be managed. The at least two devices to be managed include the set of devices to be managed and the target device to be managed.

[0141] S4052. The device to be managed provides an interface for the execution results of device management, which displays the set of devices to be managed.

[0142] In this embodiment, the device update information of the target managed device includes a set of managed devices. The managed device displays the device update information of the target managed device by displaying the set of managed devices through the device management order result interface. That is, the display has changed from displaying at least two managed devices to displaying the set of managed devices.

[0143] It should be noted that the device management execution result interface is used to display at least two devices to be managed, and the device management interface is used to display the results of the management process performed on the target device to be managed. Therefore, the device management execution result interface and the device management interface can be the same interface. In this case, the management process of the target device to be managed is achieved by updating the displayed information in the interface. Alternatively, the device management execution result interface and the device management interface can be different interfaces. In this case, the management process of the target device to be managed is achieved by switching between the interfaces.

[0144] It is understandable that the device to be managed sends a device removal request to the server device, so that the server device responds to the device removal request and removes the target device to be managed from the device list corresponding to the management account, thereby realizing the exit management of the management account on the management client of the target device to be managed.

[0145] In this embodiment of the application, when the management process includes device status control, the management operation is a status control operation and the management request is a device status control request; S402 can be implemented through S4023 (not shown in the figure); that is, the device to be managed responds to the management operation for the target device to be managed by sending a management request to the server device, including S4023, and after S4023, it also includes S4024 (not shown in the figure). The steps are described below.

[0146] S4023. In response to a status control operation targeting the target device to be managed, the device to be managed sends a device status control request to the server device.

[0147] It should be noted that for each managed device, there are also status control controls (such as a lock screen button and a power off button) displayed to change the working state of the managed device. When a user controls the working state of the target managed device by triggering the status control control corresponding to the target managed device, the managed device receives the status control operation for the target managed device. At this time, the managed device responds to the status control operation by sending a status control request to the server device. The status control request refers to the request to control the target managed device to enter the target working state.

[0148] S4024. The server device responds to the device status control request and controls the target device to be managed to enter the target working state.

[0149] In this embodiment, after the device to be managed sends a device status control request to the server device, the server device receives the device status control request. At this time, in response to the device status control request, the server device sends a status control instruction to the target device to be managed. The status control instruction is used to control the target device to enter the target working state. After receiving the status control instruction, the target device to be managed executes the status control instruction to call the functional module that matches the status control instruction, so as to realize the management processing adapted to the status control instruction.

[0150] It should be noted that the target working state includes at least one of the following: screen on, screen locked, power off, and sleep. Furthermore, after the target device under management completes the execution of the state control command and sends feedback information to the server device, or after the server device polls the target device to determine whether it has entered the target working state, and after confirming that the target device has entered the target working state, the server device obtains the management processing result including the target working state. At this point, the server device sends the target working state to each device under management.

[0151] Accordingly, in this embodiment of the application, the device to be managed in S405 provides a device management execution result interface to display the management processing result sent by the server device in response to the management request for the target device to be managed, including S4053, which will be described below.

[0152] S4053. The device to be managed provides a device management execution result interface to display the target working status sent by the server device in response to the device status control request.

[0153] In this embodiment of the application, the device update information of the target device to be managed includes the target working status. The device to be managed displays the device update information by providing a device management execution result interface to display the target working status.

[0154] It is understandable that the device under management sends status control commands to the target device under management through the server device, thereby enabling the device under management to control the working status of the target device under management.

[0155] In this embodiment of the application, when the management process includes device positioning, the management operation is a positioning operation and the management request is a device positioning request; S402 can be implemented through S4025 (not shown in the figure); that is, the device to be managed responds to the management operation for the target device to be managed by sending a management request to the server device, including S4025, and after S4025, it also includes S4026 (not shown in the figure). The steps are described below.

[0156] S4025. In response to the location operation for the target device to be managed, the device to be managed sends a device location request to the server device.

[0157] It should be noted that each managed device also displays a location control (such as a "Find Device" button) for locating the managed device. When a user locates the target managed device by triggering the location control corresponding to the target managed device, the managed device receives the location operation for the target managed device. At this time, the managed device responds to the location operation by sending a device location request to the server device. The device location request is used to request the target location of the target managed device.

[0158] S4026. The server device responds to the device location request and obtains the target location of the target device to be managed.

[0159] In this embodiment of the application, after the device to be managed sends a device location request to the server device, the server device also receives the device location request; at this time, the server device responds to the device location request and obtains the target location of the target device to be managed.

[0160] It should be noted that the target location includes at least one of the following: estimated location, current location, and historical location. When the server device obtains the target location by analyzing information such as the network address of the target device to be managed, the obtained target location is the estimated location. When the server device obtains the target location by sending a current location acquisition request to the target device to be managed, the obtained target location is the current location. Here, the target device to be managed responds to the current location acquisition request, obtains its current location, and sends it to the server device. When the server device obtains the target location by obtaining the most recent location actively reported by the target device to be managed, the obtained target location is the historical location. In this case, the management processing result includes the target location.

[0161] Accordingly, in this embodiment of the application, the device to be managed in S405 provides a device management execution result interface to display the management processing result sent by the server device in response to the management request for the target device to be managed, including S4054, which will be described below.

[0162] S4054. The device to be managed provides a device management execution result interface to display the target location sent by the server device in response to the device location request.

[0163] In this embodiment of the application, the device update information of the target device to be managed includes the target location. The device to be managed displays the device update information by providing a device management execution result interface to display the target location.

[0164] It is understandable that the device under management obtains the target location of the target device under management through the server-side device, thereby realizing the location of the target device under management through the device under management.

[0165] In this embodiment of the application, when the management process includes device risk processing, the management operation is a risk processing operation and the management request is a device risk processing request; S402 can be implemented through S4027 (not shown in the figure); that is, the device to be managed responds to the management operation for the target device to be managed by sending a management request to the server device, including S4027, and after S4027, it also includes S4028 (not shown in the figure). The steps are described below.

[0166] S4027. In response to a risk handling operation targeting the device to be managed, the device to be managed sends a device risk handling request to the server device.

[0167] It should be noted that each managed device also displays a risk handling control (such as a one-click cleanup button) for handling risks. When a user triggers the risk handling control corresponding to the target managed device to handle risks, the managed device receives the risk handling operation for the target managed device. At this time, the managed device responds to the risk handling operation by sending a device risk handling request to the server device. The device risk handling request is used to request risk handling for the target managed device.

[0168] S4028. The server device responds to the device risk processing request, performs risk processing on the target device to be managed, and obtains risk update data.

[0169] In this embodiment, after the device to be managed sends a device risk handling request to the server device, the server device receives the device risk handling request. At this time, the server device responds to the device risk handling request and performs risk handling on the target device to be managed. Here, the server device can send risk handling prompts to the device to be managed to implement risk handling; the server device can also implement risk handling by sending risk handling instructions to the target device to be managed; the server device can also perform risk handling by processing the target device to be managed itself, etc., and this embodiment does not limit these methods. When the server device sends a risk handling instruction to the target device to be managed (e.g., an instruction to clear abnormal information, an instruction to update the protection resource library), the target device to be managed calls the adapted functional modules on its own device based on the received risk handling instruction, executes the risk handling matching the risk handling instruction, and sends feedback information to the server device upon completion of the execution of the risk handling instruction.

[0170] It should be noted that the risk update data obtained by the server-side device is the result of risk processing, such as the current risk status; in this case, the management processing result includes the risk update data. Here, the server-side device sends risk update data to each device to be managed.

[0171] Accordingly, in this embodiment of the application, in S405, the device to be managed displays the device update information of the target device to be managed based on the management processing result sent by the server device in response to the management request, including S4055 and S4056, which will be described below.

[0172] S4055. Based on the risk update data sent by the server device in response to the device risk request, determine the current risk status of the target device to be managed.

[0173] In this embodiment of the application, the server device sends risk update data to the device to be managed, and the device to be managed receives the risk update data; at this time, the device to be managed determines the current risk status of the target device to be managed based on the risk update data.

[0174] S4056. Provide an interface for the execution results of equipment management to display the current risk status.

[0175] In this embodiment of the application, the device update information of the target device to be managed includes the current risk status. The device to be managed displays the device update information by providing a device management execution result interface to display the current risk status.

[0176] Understandably, the device under management obtains the current risk status of the target device under management through the server-side device, thereby enabling the risk management of the target device under management through the device under management.

[0177] See Figure 7 , Figure 7 This is an interactive illustration of the device management method provided in the embodiments of this application. Figure 3 ;like Figure 7 As shown in the embodiment of this application, S411 to S416 are included before S402; that is, before the management device sends a management request to the server device in response to the management operation for the target device to be managed, the device management method further includes S411 to S416. Each step is described below.

[0178] S411. The device to be managed sends local device information to the server device.

[0179] In this embodiment, each device to be managed sends its own device information to the server device, so that the server device can collect device information from at least two devices to be managed. The device information includes at least one of device status information, device location, device operating status, and device risk information.

[0180] It should be noted that device risk information refers to risk information from multiple dimensions, including at least one of the following: device-specific risk information and application account risk information. Device-specific risk information includes at least one of the following: hardware risk information (e.g., using non-specified parts, device performance values ​​below the threshold), application risk information (e.g., abnormal installation packages, the amount of data to be cleaned exceeding the threshold, the update time of the protection database exceeding the specified time), and environmental risk information (e.g., connecting to an abnormal network, accessing an abnormal website, receiving abnormal communication information). Application account risk information includes setting risk information (e.g., password complexity lower than the specified complexity, no security protection set) and usage risk information (e.g., logging in from a different location, including abnormal contacts). Furthermore, application account risk information refers to the risk associated with the account corresponding to the functional application on the target device to be managed.

[0181] S412. The server-side device combines the device information corresponding to at least two devices to be managed to generate updated device information data for each device to be managed.

[0182] In this embodiment of the application, the server device integrates the device information corresponding to at least two devices to be managed, so as to integrate the device information update data of each device to be managed and synchronize it to each device to be managed, and sends the device information update data of each device to each device to be managed.

[0183] S413. The device to be managed receives the device information update data sent by the server device for each device.

[0184] In this embodiment of the application, when the server device sends the device information update data of each device to be managed to each device to be managed, the device to be managed also receives the device information update data of each device to be managed.

[0185] S414. Based on the updated equipment information data, determine the equipment information to be managed for the corresponding equipment to be managed.

[0186] In this embodiment of the application, the device to be managed updates the data to be managed for the corresponding device based on the device information update data of each device to be managed, thereby obtaining the device information to be managed for each device (i.e., the device management information mentioned above).

[0187] It should be noted that the information of the device to be managed includes device type, device name, whether it is the local machine, management that can be performed (removal, risk handling and working status control, etc.), current working status, risk status, location records, binding time, and device operation data (such as processor utilization, memory utilization, hard disk utilization, processor Q&A, system disk utilization, upload speed, download speed, etc.).

[0188] S415. The managed devices display the information of each managed device.

[0189] It should be noted that the device management interface displays the device information corresponding to each device to be managed, so that any device to be managed can be managed based on the displayed device information.

[0190] S416. The device to be managed receives management operations for the target device based on the device information.

[0191] In this embodiment, when the device information includes device risk information, and after the device to be managed sends its local device information to the server device, the device management method further includes: the device to be managed providing a device management interface to display a risk list sent by the server device in response to the device risk information, wherein the risk list is integrated by the server device based on the device risk information of each device to be managed; and risk management is performed on at least two devices to be managed based on the risk list. In other words, the device to be managed can display the pending risks of at least two devices as a whole, thereby improving risk handling efficiency and ultimately enhancing device management effectiveness.

[0192] In this embodiment of the application, the server device can also receive risk notifications sent by the service device, thereby combining risk communication and device risk information to determine the risk of the device to be managed.

[0193] The following describes an exemplary application of the embodiments of this application in a real-world application scenario. This exemplary application describes binding multiple devices (referred to as at least two devices to be managed) across a cross-system platform, and collecting, synchronizing, and intelligently analyzing device data from these devices through a server (referred to as a server-side device), thereby enabling any device to manage other devices and perform risk monitoring and handling. Here, the explanation focuses on three aspects: binding multiple devices, device status management, and device risk management.

[0194] The following explains how to establish binding relationships between multiple devices across a cross-system platform.

[0195] See Figure 8 , Figure 8 This is an exemplary interaction diagram for establishing a binding relationship provided in an embodiment of this application; such as Figure 8 As shown, the exemplary steps for establishing a binding relationship include S801 to S810, and each step is described below.

[0196] S801. The new device (referred to as the device to be managed) sends an account login request to the server.

[0197] It should be noted that the same client (referred to as the management client) runs on multiple devices, and the same account (referred to as the management account) is used to log in to the running client on multiple devices.

[0198] See Figure 9 , Figure 9 This is an exemplary schematic diagram of a client before login provided in an embodiment of this application; as shown... Figure 9 As shown, page 9-1 is the client's running page before account login, including the login entry point 9-11 and a description of manageable devices 9-12. Here, when accessed via... Figure 9 When logging in through login portals 9-11, the process of the new device sending an account login request to the server is triggered.

[0199] S802, The server sends a login success message to the new device.

[0200] It should be noted that, in response to the account login request, the server sends a login success message to the new device; the login success message is the success message in this embodiment of the application.

[0201] S803, The new device sends device data to the server.

[0202] It should be noted that the new device determines that the account has been successfully logged in on the new device based on the received login success information. When the account is successfully logged in on the new device, the new device reports device data (including device identifier) ​​to the server through the client.

[0203] It should also be noted that different system platforms have different types of device identifiers, which in turn correspond to different types of device identifiers in the device list. For example, some system platforms use a Vendor Identifier (IDFV) for device identifiers, while others use a different Vendor Identifier (VID, an identifier calculated from a Globally Unique Identifier (GUID) and device information).

[0204] S804. The server checks the list of devices under the account based on device data.

[0205] It should be noted that the server maintains a device list for each account. Based on the received device data, the server checks whether the device identifier in the device list corresponding to the account is included. If the device list includes the device identifier from the device data, no update process is performed on the device list; otherwise, if the device list does not include the device identifier from the device data, step S805 is executed.

[0206] S805. When the device list does not include a new device, the server will update the device list with the new device.

[0207] It should be noted that after the server updates the new device to the device list, it indicates that a binding relationship has been established between the new device and the device list corresponding to the account. After the binding relationship is established, the new device will report its local information (such as location) to the server at a certain frequency (such as a fixed time interval of 1 hour). After receiving the local information reported by the new device, the server processes the local information reported by the new device to obtain the latest device information, and broadcasts the latest device information to the existing devices in the device list.

[0208] S806. The server sends device list update data to the new device and other devices in the device list.

[0209] See Figure 10 , Figure 10 This is an exemplary diagram illustrating a client login process provided in an embodiment of this application; as shown... Figure 10 As shown, page 10-1 is the client running page after account login, including statistical information of the devices to be managed 10-11, a list of devices to be managed 10-12, and management trigger controls 10-13 corresponding to each device to be managed. Page 10-1 is the device management interface provided in this embodiment of the application.

[0210] S807, The new device sends an account logout request to the server.

[0211] It should be noted that devices in the device list can actively log out of their accounts on the client. Here, we will take the example of a new device actively logging out of its account on the client. When a new device actively logs out of its account on the client, it sends an account logout request to the server, requesting the server to process the account logout on the new device's client.

[0212] S808, The server sends a logout success message to the new device.

[0213] It should be noted that in response to the account logout request, the server sends a logout success message to the new device.

[0214] S809. The server removes new devices from the device list.

[0215] It should be noted that in response to an account logout request, the server also removes new devices from the device list; the device list will no longer include new devices after the cleanup is complete.

[0216] S810, The server sends device list update data (referred to as first device update data) to other devices in the device list.

[0217] It should be noted that after a new device actively logs out of the account and logs in on the client, the new device will no longer report its local information to the server through the client. Simultaneously, the server will remove the new device from the device list associated with the account and broadcast the data of the removed new device to other devices in the device list.

[0218] The following describes the process of managing multiple devices across system platforms based on binding relationships.

[0219] It should be noted that the management of multiple devices across system platforms includes device status management and device risk management; among which, device status management includes removing devices, querying device locations, and controlling devices, while device risk management includes determining and handling device risks.

[0220] See Figure 11 , Figure 11 This is an exemplary interaction diagram for removing a device provided in an embodiment of this application; as shown... Figure 11 As shown, the process of removing device B (referred to as the device to be processed) from device A in the device list is described, including steps S1101 to S1108. Each step is explained below.

[0221] S1101, Device A requests a device list from the server.

[0222] It should be noted that when device A has just completed logging in, or when device A is managing devices in the device list, it sends a request to the server to obtain the device list.

[0223] S1102, The server sends a device list to device A.

[0224] It should be noted that after receiving the request for a device list from device A, the server responds by sending the device list to device A.

[0225] S1103. Device A sends a request to the server to remove device B (referred to as a device removal request).

[0226] For example, see Figure 12 , Figure 12 This is a schematic diagram illustrating an exemplary control working state provided in an embodiment of this application; as shown... Figure 12 As shown, when triggered Figure 10When managing device 12-1, the management trigger control 10-13 displays page 12-2. Page 12-2 displays basic information about device 12-1 and also shows an unbind button 12-21; when button 12-21 is triggered, a request to remove device 12-1 is sent to the server.

[0227] S1104. The server removes device B from the device list.

[0228] It should be noted that, in response to the request to remove device B, the server removes device B from the device list to achieve the management process of removing device B from device A.

[0229] S1105. The server changes the login status of device B to the logout status (or unbind or offline status).

[0230] It should be noted that, in response to the request to remove device B, the login status of device B is changed to the logout status. S1104 and S1105 do not have a specific execution order; for example, S1104 can be executed first and then S1105, or S1105 can be executed first and then S1104, or S1104 and S1105 can be executed in parallel, and so on.

[0231] S1106. The server sends an account offline notification (or simply offline notification) to device B.

[0232] It should be noted that device B, which was removed this time, will receive an account offline notification from the server.

[0233] S1107. Device B clears the local cached binding information based on the account offline notification.

[0234] It should be noted that, based on the account offline notification, the client of device B clears the local cached binding information, and device B will no longer report local information to the server.

[0235] S1108. The server sends device list update data (referred to as second device update data) to device A and other devices in the device list.

[0236] It should be noted that the removal of a device is performed by any device in the device list corresponding to the account. The removed device is any device in the device list corresponding to the account, and each device in the device list has successfully logged into the same account on the running client. Here, after receiving the removal request, the server removes the specified device from the device list and broadcasts it to other devices already in the list.

[0237] See Figure 13 , Figure 13This is an exemplary interactive diagram for querying device location provided in an embodiment of this application; such as Figure 13 As shown, the process of querying the positions of devices B, C, and D in the device list from device A in the device list is described, including steps S1301 to S1319. Each step is explained below.

[0238] S1301, Device C sends a message to the server indicating that the local machine has enabled the retrieval function.

[0239] It should be noted that the device sends information indicating that it has enabled the retrieval function to the server only when the device has enabled the retrieval function. This information enables the server to return the location to the device that requested the location.

[0240] For example, see Figure 14 , Figure 14 This is a schematic diagram illustrating an exemplary function activation method provided in an embodiment of this application; as shown... Figure 14 As shown, page 14-1 is used to enable the "Allow Retrieval" function for device C in the device list, including basic device management information 14-11, a toggle control for enabling the "Allow Retrieval" function 14-12, and device information 14-13. Here, the "Allow Retrieval" function is enabled and disabled by touching the toggle control 14-12; and only when the "Allow Retrieval" function is enabled will the device report its location to the server and allow other devices in the device list to obtain that location.

[0241] S1302, Device D sends information to the server indicating that the local machine has enabled the retrieval function.

[0242] It should be noted that the process of device D sending information to the server that the local retrieval function is enabled is similar to the process of device C sending information to the server that the local retrieval function is enabled in S1301, and will not be described again here.

[0243] S1303, Device D obtains its current location.

[0244] It should be noted that when device D has a positioning function and the positioning function is enabled, device D periodically obtains its current location and sends its current location to the server.

[0245] S1304. Device D sends its current location to the server.

[0246] It should be noted that after device D obtains its current location within the current positioning cycle, it sends its current location to the server. Here, device D executes S1303 and S1304 cyclically at fixed intervals.

[0247] S1305, Device A requests a device list from the server.

[0248] It should be noted that the process of device A requesting a device list from the server is similar to the process of device A requesting a device list from the server in S1101, and will not be described again in this embodiment.

[0249] S1306. The server sends a device list to device A.

[0250] It should be noted that the process of the server sending the device list to device A is similar to the process of the server sending the device list to device A in S1102, and will not be described again in this embodiment.

[0251] S1307. Device A sends a request to the server to query the location of Device B in the device list (called a device location request).

[0252] It should be noted that when the server sends the device list to device A, device A also receives the device list; when a user performs a location retrieval operation on device B in the device list on device A, device A responds to the location retrieval operation by sending a request to the server to query the location of device B in the device list, in order to request the server to obtain the location of device B.

[0253] S1308, The server sends a message to device A indicating that the query is unavailable.

[0254] It should be noted that since device B did not send information to the server indicating that it had enabled the retrieval function, it means that device B has not enabled the retrieval function. Therefore, when device A queries the location of device B, the server sends a message to device A indicating that the retrieval function is not available.

[0255] S1309. Device A sends a request to the server to query the location of device C in the device list (called a device location request).

[0256] It should be noted that the request sent by device A to the server to query the location of device C in the device list is similar to the request sent by device A to the server to query the location of device B in the device list in S1307, and will not be described again in this embodiment.

[0257] S1310. In response to a request to query the location of device C in the device list, the server resolves the Internet Protocol (IP) address of device C.

[0258] It should be noted that since device C does not include location functionality, or its location functionality is not enabled, device C does not periodically report its current location to the server. Therefore, the server cannot obtain the location of device C from the information reported by device C. Thus, in response to a request to query the location of device C in the device list, the server obtains the location of device C by resolving the Internet Protocol address of device C.

[0259] S1311. The server sends the estimated location of device C to device A based on the parsing result.

[0260] It should be noted that the estimated location is obtained by the server by resolving the Internet Protocol address of device C.

[0261] S1312. Device A requests the server to query the location of device D.

[0262] It should be noted that when device A requests the server to query the location of device D, it is similar to when device A sends a request to the server to query the location of device B in the device list in S1307. This embodiment of the application will not repeat the description here.

[0263] S1313, The server sends the most recent location of device D (referred to as historical location, e.g., ...) to device A. Figure 15 Information 15-11 is shown on page 15-1.

[0264] S1314. Device A sends a request to the server to query the current location of device D (called a device location request).

[0265] It should be noted that when a user performs a current location retrieval operation on device A for device D in the device list, device A responds to the current location retrieval operation by sending a request to the server to query the current location of device D, in order to request the server to obtain the current location of device D.

[0266] S1315, The server sends a query request to device D.

[0267] It should be noted that after receiving a request from device A to query the current location of device D, the server responds by sending a query request to device D to obtain the current location of device D.

[0268] S1316, Device D obtains its current location.

[0269] It should be noted that after receiving the query request sent by the server, device D responds to the query request by obtaining its current location.

[0270] S1317, Device D plays an alarm.

[0271] It should be noted that device D is pre-configured with an alarm. When device D receives a query request from the server, it responds by playing an alarm. S1316 and S1317 are not executed in any particular order.

[0272] S1318, Device D sends its current location to the server.

[0273] It should be noted that after obtaining its current location, device D sends the current location to the server in order to respond to the query request sent by the server.

[0274] S1319. The server sends the current location of device D to device A.

[0275] It should be noted that location lookup is based on location reporting, which includes active reporting and passive reporting. Active reporting refers to a device (e.g., device D) reporting its location to the server at a certain frequency (e.g., a fixed time interval of 1 hour), as shown in S1303 and S1304. The conditions for active reporting are that the device has a positioning function and that the positioning function is enabled.

[0276] See Figure 16 , Figure 16 This is an exemplary schematic diagram illustrating the activation of the location function provided in an embodiment of this application; as shown... Figure 16 Page 16-1 is used to enable location services to activate the location function; it includes a location service switch control 16-11; the location function is turned on and off by triggering the switch control 16-11, wherein the location function is used to determine the device location through the Global Positioning System, Bluetooth and crowdsourced Wi-Fi hotspots and cell tower locations, etc.

[0277] Here, when the device does not include location functionality, or when the device fails to report its location to the server, if the server receives a location query request for the device, it estimates the device's location based on the device's connection URL (e.g., IP address). This is referred to as S1310 and S1311.

[0278] Passive reporting refers to a situation where, when another device (e.g., device A) requests the current location of this device (e.g., device C) from the server (e.g., when the phone cannot be found), this device, based on a notification sent by the server, activates its client to report its location to the server. In addition, while passively reporting, this device will also emit attention-grabbing information such as light, vibration, and sound (i.e., the aforementioned alarm).

[0279] It should also be noted that the location query determines the final query result based on whether the location retrieval function is enabled and whether the current location is being queried. See also Figure 17 , Figure 17 This is an exemplary flowchart of obtaining location query results provided in an embodiment of this application; as shown... Figure 17 As shown, the execution entity for obtaining the location query result in this exemplary case is the server, including steps S1701 to S1706. Each step is described below.

[0280] S1701, Start querying the location of the device to be queried.

[0281] It should be noted that the server responds to the request sent by the device to query the location of the device and begins to query the location of the device.

[0282] S1702. Determine whether the device to be queried has enabled the retrieval function. If yes, proceed to S1704; otherwise, proceed to S1703. Here, the server determines whether the retrieval function is enabled by checking whether it has received a "retrieval function enabled" message from the device to be queried. If the server receives such a message, it is determined that the device to be queried has enabled the retrieval function; otherwise, it is determined that the device to be queried has not enabled the retrieval function.

[0283] S1703, Confirm that the query is not available.

[0284] It should be noted that when the server determines that the device to be queried has enabled the retrieval function, it means that the device to be queried does not provide its own location to other devices. Here, the prompt message that the location cannot be queried may include at least one of the reasons for the inability to be queried and the suggested processing for the location query. This application embodiment does not limit this.

[0285] S1704. Determine whether to query the current position. If yes, execute S1706; otherwise, execute S1705.

[0286] It should be noted that after receiving a location query request sent by a device used for managing other devices, the server determines whether it is querying the current location based on the content requested in the location query request.

[0287] S1705, Confirm return to the most recent position.

[0288] In this embodiment of the application, when the location requested by the device from the server is not the current location of the device to be queried, the server sends the most recent location of the device to be queried to the device; wherein, the most recent location is the location that the device to be queried last actively reported.

[0289] S1706, Confirm and return to the current position.

[0290] In this embodiment of the application, when the location requested by the device from the server is the current location of the device to be queried, the server sends the current location of the device to be queried to the device; wherein, the current location is the current location sent by the device to be queried to the server at this time through positioning.

[0291] See Figure 18 , Figure 18 This is an interaction diagram of an exemplary control device provided in an embodiment of this application; as shown below. Figure 18 As shown, the process of controlling device B in the device list by device A in the device list is described, including steps S1801 to S1812. Each step is explained below.

[0292] S1801. Device A sends a request to the server to lock the screen of Device B (called a device status control request).

[0293] See also Figure 12 On page 12-2, a screen lock button 12-22 is also displayed; when button 12-22 is triggered, a request is sent to the server to lock device 12-1.

[0294] S1802, The server sends a screen lock command to device B.

[0295] Here, in response to the request to lock the screen of device B, the server sends a screen lock command to device B.

[0296] S1803, Device B locks the screen by executing a screen lock command.

[0297] It should be noted that when the server sends a screen lock command to device B, device B also receives the screen lock command; at this time, device B executes the screen lock command, which also locks its own screen; thus, device management is achieved, where device A controls device B to lock its screen.

[0298] S1804, Equipment B detects changes in the status of the equipment.

[0299] It should be noted that because device B performed screen locking, its device state changed; and because device B periodically checks whether its own device state has changed, it can detect the change in device state (from screen on to screen locked) when it detects the change in device state.

[0300] S1805. Device B reports the changed device status (referred to as the target operating status) to the server.

[0301] It should be noted that because device B locked its screen, device B detected a change in its device status and then reported the changed device status to the server.

[0302] S1806. The server sends device status update data to device A and other devices in the device list.

[0303] It should be noted that the device status update data represents the change in the device status of device B. Furthermore, S1804 to S1806 are executed cyclically. Additionally, S1801 to S1806 describe the process by which device A controls device B in the device list to lock its screen. The process by which device A controls device B in the device list to shut down is described below.

[0304] S1807. Device A sends a request to the server to shut down Device B (called a device status control request).

[0305] See also Figure 12 On page 12-2, a power off button 12-23 is also displayed; when button 12-23 is triggered, a request to the server to power off device 12-1 is sent.

[0306] S1808, The server sends a shutdown command to device B.

[0307] Here, in response to the request to shut down device B, the server sends a shutdown command to device B.

[0308] S1809. Device B shuts down by executing a shutdown command.

[0309] It should be noted that when the server sends a shutdown command to device B, device B also receives the shutdown command; at this time, device B executes the shutdown command, which also shuts down itself; thus, device management is achieved, where device A controls device B to shut down.

[0310] S1810, The server sends polling information to device B.

[0311] It should be noted that S1810 is executed cyclically to poll whether the shutdown is complete.

[0312] S1811. The server has determined that device B is powered off.

[0313] It should be noted that when the control command is a shutdown command, since the device under control is offline after executing the shutdown command and has been disconnected from the server, it cannot send feedback on the control result. Therefore, the server uses a polling mechanism at specified time intervals (e.g., five minutes) to determine whether the device under control is offline by sending polling information to it. When it is determined that the device is offline, it is confirmed that the processing indicated by the shutdown command has been completed. At this point, it can be determined that device B has been shut down.

[0314] S1812, The server sends device status update data to device A and other devices in the device list.

[0315] It should be noted that when the device to be controlled (e.g., device B) receives a control command (e.g., screen lock command, power off command) sent by the server, the client on the device to be controlled initiates a function call corresponding to the control command to the local machine so that the local machine enters the corresponding state; here, when the device to be controlled completes the execution of the control command, the state of the device to be controlled changes, and at this time, the device to be controlled sends the control result back to the server.

[0316] See Figure 19 , Figure 19 This is an exemplary interaction diagram for determining device risk provided in an embodiment of this application; as shown... Figure 19 As shown, the process of determining the device risk of device A and device B in the device list by the server is described, including S1901 to S1908. Each step is explained below.

[0317] S1901. The server establishes a connection with the business server.

[0318] It should be noted that the business server is the backend server corresponding to the functional application managed by the client, such as the backend server corresponding to the instant messaging application, the backend server corresponding to the browser, and so on.

[0319] S1902, Equipment A detects the risk status of the machine.

[0320] It should be noted that each device periodically detects changes in its own equipment information, and thus device A also periodically detects its own risk status.

[0321] S1903, Device A sends risk status information to the server.

[0322] It should be noted that when device A detects a change in its own risk status, it sends risk status information to the server.

[0323] S1904. The server determines the current risk status of device A based on the risk status information.

[0324] It should be noted that when device A sends risk status information to the server, the server also receives the risk status information of device A; then, the server determines the current risk status of device A based on the risk status information.

[0325] S1905. The server sends the current risk status of device A to the devices in the device list.

[0326] It should be noted that S1902 to S1905 are executed cyclically.

[0327] S1906. Equipment B detects the risk status of the machine.

[0328] It should be noted that the process by which device B detects the risk status of its own machine is similar to the process by which device A detects the risk status of its own machine in S1902, and will not be described again in this embodiment of the application.

[0329] S1907, Device B sends risk status information to the server.

[0330] It should be noted that the process of device B sending risk status information to the server is similar to the process of device A sending risk status information to the server in S1903, and will not be described again in this embodiment of the application.

[0331] S1908. The server determines the current risk status of device B based on the risk status information.

[0332] It should be noted that the process by which the server determines the current risk status of device B based on the risk status information is similar to the process in S1904 where the server determines the current risk status of device A based on the risk status information. Therefore, this embodiment will not be described again here.

[0333] S1909. The server sends the current risk status of device B to the devices in the device list.

[0334] It should be noted that S1906 to S1909 are executed cyclically.

[0335] S1910, The business server sends a risk notification to the server.

[0336] It should be noted that, since the server has established a connection with the business server, when the business server detects that the corresponding device is at risk, it sends a risk notification to the server for that device.

[0337] S1911. The server sends risk update data to the devices in the device list based on the risk notification.

[0338] It should be noted that S1910 and S1911 are executed cyclically.

[0339] It should also be noted that risk status information refers to relevant information used to determine risk status, including device risk information and account risk information. Device risk information includes hardware risk information, application risk information, and environmental risk information, while account risk information includes settings risk information and usage risk information. Specifically, hardware risk information includes changes to hardware and hardware performance values ​​(such as battery level); application risk information includes abnormal applications, abnormal installation packages, expired or outdated libraries, changes to available space, and changes to data that can be cleaned; environmental risk information includes changes to network connection, browsing history, and communication records (such as received phone calls, notifications, and SMS messages); settings risk information includes account passwords, security settings, and authentication information; and usage risk information includes changes to login location and associated accounts.

[0340] The server comprehensively analyzes information from relevant dimensions to identify potential security risks (including devices in a risky state and accounts of functional applications on those devices), generates security logs, and broadcasts them to various devices for viewing and handling.

[0341] For example, see Figure 20 , Figure 20 This is an exemplary schematic diagram showing a risk status provided in an embodiment of this application; as shown... Figure 20 As shown, page 20-1 includes risk statistics information 20-11 and an immediate action button 20-12 for handling risks; when button 20-12 is triggered, page 20-2 is displayed, which includes a list of detected risks 20-21.

[0342] See Figure 21 , Figure 21 This is an exemplary interactive diagram of device risk handling provided in an embodiment of this application; such as Figure 21 As shown, the process of device risk handling for device A in the device list to device B in the device list is described, including steps S2101 to S2110. Each step is explained below.

[0343] S2101, Equipment A handles the equipment risk of this machine.

[0344] It should be noted that devices in the equipment list can handle their own equipment risks, as well as the equipment risks of other devices in the equipment list besides device A.

[0345] S2102, Device A reports the risk-processed data to the server.

[0346] It should be noted that each device in the device list will send corresponding change information to the server when its own device information changes. Here, after device A completes the processing of its own device risks, device A's device information also changes. Device A sends the change information to the server by reporting the risk processing data to the server.

[0347] S2103. The server determines the current risk status of device A based on the risk data reported by device A.

[0348] It should be noted that after the server obtains the risk-processed data, it assesses the risk of its own device A based on the risk-processed data reported by device A, thus determining the current risk status of device A.

[0349] S2104. The server sends updated data on the current risk status of device A to both device A and device B.

[0350] It should be noted that the server sends the updated risk status data of device A to device A and device B in order to synchronize the current risk status of device A with each device in the device list.

[0351] S2105. Device A sends a request to the server to handle the risk of device B.

[0352] It should be noted that when device A handles device risks for other devices in the device list besides itself (such as device B), it triggers this by sending a request to the server to handle the risks of device B.

[0353] S2106. The server sends a risk handling instruction to device B.

[0354] It should be noted that, in response to a request to handle the risk of device B, the server issues a risk handling instruction to device B.

[0355] S2107. Device B handles local risks by executing risk handling instructions.

[0356] It should be noted that the process by which device B reports the risk-processed data to the server is similar to the process by which device B shuts down by executing a shutdown command in S1809, and will not be described again in this embodiment of the application.

[0357] S2108, Device B reports the risk-processed data to the server.

[0358] It should be noted that the process of device B reporting risk-processed data to the server is similar to the process of device A reporting risk-processed data to the server in S2102, and will not be described again in this embodiment.

[0359] S2109. The server determines the current risk status of device B based on the risk data reported by device B.

[0360] It should be noted that the process by which the server determines the current risk status of device B based on the risk data reported by device B is similar to the process in S2104 where the server sends updated data on the current risk status of device A to both device A and device B. This embodiment of the application will not repeat the description here.

[0361] S2110. The server sends updated data on the current risk status of device B to both device A and device B.

[0362] It should be noted that risks can be handled locally or through other devices. When risks are handled remotely through other devices, the server can send risk handling instructions to the corresponding device.

[0363] It should also be noted that some risks can be handled with a single click, such as deleting and updating risk content (cleaning up useless data, deleting abnormal data, upgrading the protection database, and switching Wi-Fi, etc.). Other risks cannot be handled by the client (e.g., hardware risks). In these cases, the corresponding risk details can be displayed to allow for offline handling.

[0364] For example, see Figure 22 , Figure 22 This is a schematic diagram of an exemplary risk handling process provided in an embodiment of this application; as shown below. Figure 22 As shown, this exemplary risk processing is performed by the server, including steps S2201 to S2206, which are described below.

[0365] S2201, Begin handling the risk.

[0366] It should be noted that the server responds to the request sent by the device to handle the risk of the device to be handled and begins to handle the risk.

[0367] S2202. Determine whether the risk to be processed is a non-automatic processing risk. If yes, proceed to S2203; otherwise, proceed to S2204.

[0368] It should be noted that non-automatic processing risks are hardware risk statuses determined based on hardware risk information.

[0369] S2203, Instructs the device to display risk details and processing prompts.

[0370] It should be noted that when the risk to be processed is a non-automatic risk, it is not possible to request the device to handle the risk. Therefore, the server instructs the requesting device to display risk details and processing prompts. The risk details may be a detailed description of the risk, and the processing prompts may be the specific steps for handling the risk.

[0371] S2204. Determine whether the risk to be processed is an account risk. If yes, proceed to S2206; otherwise, proceed to S2205.

[0372] It should be noted that account risk is a risk status determined based on account risk information.

[0373] S2205, Instructs the requesting device to display a page for handling environmental and application risks.

[0374] It should be noted that when the risk to be processed is not an account risk, the WeChat risk to be processed is determined to be an environment risk and an application risk. The processing of environment risks and application risks can be achieved by responding to the operation on the page.

[0375] S2206. Determine if authorization is required. If yes, proceed to S2208; otherwise, proceed to S2207.

[0376] It should be noted that authorization refers to the process by which the system grants operational permissions to the client; for example, the system grants the client the permission to switch the Wi-Fi connection of the device through the system interface.

[0377] S2207, Instructs the device to display a one-click processing entry.

[0378] It should be noted that the one-click processing entry is, for example, the "one-click processing" button; by triggering the one-click processing entry, the pending risks can be processed.

[0379] S2208. Determine if authorization has been granted. If yes, proceed to S2207; otherwise, proceed to S2209.

[0380] S2209, Instruct the device to be processed to perform authorized processing.

[0381] It should be noted that when the risk information to be processed is account risk information, since the object involved in account risk information is an account, such as a chat account, the processing of account risk information requires user authorization; therefore, at this time, the server instructs the device to be processed to perform authorization processing.

[0382] S2210. Determine if authorization was successful. If yes, proceed to S2207; otherwise, proceed to S2203.

[0383] It is understood that the embodiments of this application bind multiple devices across system platforms, enabling any device to manage and control other devices, thereby improving device management efficiency. In addition, by performing intelligent risk detection on multiple devices, cross-device risk handling can be achieved, displaying and handling security risks in multiple dimensions, thereby improving the quality of device management.

[0384] The following description continues to illustrate the exemplary structure of the device management device 355 provided in the embodiments of this application as a software module. In some embodiments, such as... Figure 2 As shown, the software modules stored in the device management device 355 of the first memory 350 may include:

[0385] The device display module 3551 is used to provide a device management interface to display at least two devices to be managed that are bound or logged in with the same management account. The management account is bound or logged in to each of the devices to be managed through a management client, so as to manage the at least two devices to be managed through the management client.

[0386] The management trigger module 3552 is used to send a management request to the server device in response to a management operation on the target device to be managed, so that the server device performs management processing on the target device to be managed in response to the management request, wherein the target device to be managed is any one of the at least two devices to be managed;

[0387] The result processing module 3553 is used to provide a device management execution result interface to display the management processing result sent by the server device in response to the management request for the target device to be managed.

[0388] In this embodiment, the device management device 355 further includes a device binding module 3554, used to bind or log in to the locally running management client based on the management account and obtain success information; based on the success information, send a local device identifier to the server device, so that the server device updates the corresponding device to be managed to the device list corresponding to the management account based on the device identifier, and obtains first device update data; receive the first device update data sent by the server device for the device identifier; and based on the first device update data, obtain the at least two devices to be managed that are bound or logged in with the same management account.

[0389] In this embodiment of the application, the management process includes at least one of device removal, device status control, device location, and device risk handling. The device removal refers to the process of removing the target device to be managed from the at least two devices to be managed. The device location refers to the process of locating the target device to be managed. The device status control refers to the process of controlling the working status of the target device to be managed. The device risk handling refers to the process of handling the risk of the target device to be managed.

[0390] In this embodiment, when the management process includes device removal, the management operation is a removal operation, and the management request is a device removal request. The management triggering module 3552 is further configured to send the device removal request to the server device in response to the removal operation for the target device to be managed, so that the server device changes the binding or login status of the management account in the target device to be managed in response to the device removal request, and obtains second device update data, wherein the management processing result includes the second device update data. The result processing module 3553 is further configured to determine a set of devices to be managed based on the second device update data sent by the server device in response to the device removal request, wherein the at least two devices to be managed include the set of devices to be managed and the target device to be managed; and to provide a device management execution result interface to display the set of devices to be managed.

[0391] In this embodiment, when the management process includes device status control, the management operation is a status control operation, and the management request is a device status control request. The management triggering module 3552 is further configured to send the device status control request to the server device in response to the status control operation for the target device to be managed, so that the server device controls the target device to be managed to enter a target working state in response to the device status control request. The target working state includes at least one of screen-on state, screen-locked state, power-off state, and sleep state, and the management processing result includes the target working state. The result processing module 3553 is further configured to provide a device management execution result interface to display the target working state sent by the server device in response to the device status control request.

[0392] In this embodiment of the application, when the management process includes device positioning, the management operation is a positioning operation, and the management request is a device positioning request; the management triggering module 3552 is further configured to send the device positioning request to the server device in response to the positioning operation for the target device to be managed, so that the server device obtains the target location of the target device to be managed in response to the device positioning request, wherein the target location includes at least one of the estimated location, the current location, and the historical location, and the management processing result includes the target location; the result processing module 3553 is further configured to provide the device management execution result interface to display the target location sent by the server device in response to the device positioning request.

[0393] In this embodiment, when the management process includes device risk processing, the management operation is a risk processing operation, and the management request is a device risk processing request. The management triggering module 3552 is further configured to send the device risk processing request to the server device in response to the risk processing operation for the target device to be managed, so that the server device performs risk processing on the target device to be managed in response to the device risk processing request and obtains risk update data, wherein the management processing result includes the risk update data. The result processing module 3553 is further configured to determine the current risk status of the target device to be managed based on the risk update data sent by the server device in response to the device risk request; and provide a device management execution result interface to display the current risk status.

[0394] In this embodiment, the device management device 355 further includes an information integration module 3555, configured to send local device information to the server device, so that the server device integrates the device information corresponding to the at least two devices to be managed to generate device information update data for each device to be managed. The device information includes at least one of device status information, device location, device working status, and device risk information. The module also receives device information update data sent by the server device for the device information; determines the device information to be managed corresponding to the device to be managed based on the device information update data; provides the device management interface to display the device information corresponding to each device to be managed; and receives management operations for the target device to be managed based on the device information.

[0395] In this embodiment of the application, the result processing module 3553 is further configured to provide the device management interface to display the risk list sent by the server device in response to the device risk information, wherein the risk list is integrated by the server device in combination with the device risk information of each device to be managed; and risk processing is performed on the at least two devices to be managed based on the risk list.

[0396] The following description continues to illustrate the exemplary structure of the device management device 255 provided in the embodiments of this application as a software module. In some embodiments, such as... Figure 3 As shown, the software modules stored in the device management device 255 of the second memory 250 may include:

[0397] The request receiving module 2551 is used to receive a management request sent by a device to be managed, wherein the management request is sent in response to a management operation on a target device to be managed, the target device to be managed is any one of at least two devices to be managed, the at least two devices to be managed are bound or logged in with the same management account, and the management account is bound or logged in to each device to be managed through a management client, so as to manage the at least two devices to be managed through the management client;

[0398] Device management module 2552 is used to perform management processing on the target device to be managed in response to the management request;

[0399] The result sending module 2553 is used to send management processing results to the device to be managed, so that the device to be managed can display the management processing results for the target device on the device management execution result interface.

[0400] In this embodiment, the device management device 255 further includes a device update module 2554, configured to receive a local device identifier sent by the device to be managed, wherein the device identifier is sent by the device to be managed when the management account successfully logs in to the locally running management client; based on the device identifier, update the corresponding device to be managed to the device list corresponding to the management account to obtain first device update data; and send the first device update data to each device to be managed so that each device to be managed binds or logs in to at least two devices to be managed with the same management account based on the first device update data.

[0401] In this embodiment of the application, the device management module 2552 is further configured to send a management instruction to the target device to be managed in response to the management request, so that the target device to be managed executes the management instruction to complete the management process, wherein the management instruction includes at least one of a status control instruction, a positioning instruction, and a risk handling instruction.

[0402] In this embodiment of the application, the device management module 2552 is further configured to receive local device information sent by each of the devices to be managed, and obtain device information corresponding to the at least two devices to be managed respectively; based on the device information corresponding to the at least two devices to be managed respectively, integrate the device information update data corresponding to the at least two devices to be managed respectively; and send the device information update data corresponding to the at least two devices to be managed to each of the devices to be managed, so that the devices to be managed display the device information corresponding to each device to be managed, wherein the management operation is received based on the device information corresponding to the target device to be managed.

[0403] This application provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A first processor of a computer device (referred to as a managed device) reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the device management method for the managed device described in this application embodiment. Alternatively, a second processor of the computer device (referred to as a server device) reads the computer instructions from the computer-readable storage medium, and the first processor executes the computer instructions, causing the computer device to perform the device management method for the server device described in this application embodiment.

[0404] This application provides a computer-readable storage medium storing executable instructions. When the executable instructions are executed by a first processor, the first processor will execute the device management method for a managed device provided in this application embodiment; or, when the executable instructions are executed by a second processor, the second processor will execute the device management method for a server device provided in this application embodiment. For example, ... Figure 4 The equipment management method is shown.

[0405] In some embodiments, the computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or it may be a variety of devices including one or any combination of the above-mentioned memories.

[0406] In some embodiments, executable instructions may take the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0407] As an example, executable instructions may, but do not necessarily, correspond to files in a file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a Hyper Text Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple collaborating files (e.g., a file that stores one or more modules, subroutines, or code sections).

[0408] As an example, executable instructions can be deployed to execute on a single computer device (in which case, this single computer device is the managed device or server device), or to execute on multiple computer devices located in one location (in which case, multiple computer devices located in one location are the managed device or server device), or to execute on multiple computer devices distributed across multiple locations and interconnected via a communication network (in which case, multiple computer devices distributed across multiple locations and interconnected via a communication network are the managed device or server device).

[0409] It is understood that in the embodiments of this application, data related to device information is involved. When the embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0410] In summary, this application embodiment achieves the binding of management accounts with multiple devices by binding or logging into management clients running on at least two devices to be managed. This allows each device to manage any one of the multiple devices to be managed, thus realizing unified management of multiple devices and improving device management efficiency.

[0411] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A method for managing equipment, characterized in that, The method includes: A device management interface is provided to display at least two devices to be managed that are bound or logged in with the same management account. The management account is bound or logged in to each of the devices to be managed through a management client to manage the at least two devices to be managed. The at least two devices to be managed include at least one operating system. The management client running on the at least two devices to be managed is the same client, and the management client running on each device to be managed is compatible with the operating system of the device to be managed. Send local device information to the server device so that the server device can combine the device information corresponding to the at least two devices to be managed to generate device information update data for each device to be managed; receive the device information update data sent by the server device in response to the device information; Based on the updated device information, determine the device information to be managed corresponding to the device to be managed; provide the device management interface to display the device information to be managed for each device to be managed; and receive management operations for the target device to be managed based on the device information to be managed. In response to the management operation for the target device to be managed, a management request is sent to the server device, so that the server device performs management processing on the target device to be managed in response to the management request, wherein the target device to be managed is any one of the at least two devices to be managed; Provide a device management execution result interface to display the management processing result sent by the server device in response to the management request for the target device to be managed.

2. The method according to claim 1, characterized in that, Before providing the device management interface to display at least two devices to be managed that are bound or logged in with the same management account, the method further includes: Based on the management account binding or login to the locally running management client, a success message is obtained; Based on the success information, a local device identifier is sent to the server device, so that the server device updates the corresponding device to be managed to the device list corresponding to the management account based on the device identifier, thereby obtaining the first device update data; Receive the first device update data sent by the server device in relation to the device identifier; Based on the update data of the first device, at least two devices to be managed are obtained that are bound or logged in with the same management account.

3. The method according to claim 1, characterized in that, The management process includes at least one of equipment removal, equipment status control, equipment location, and equipment risk handling. Equipment removal refers to the process of removing the target device to be managed from the at least two devices to be managed. Equipment location refers to the process of locating the target device to be managed. Equipment status control refers to the process of controlling the working status of the target device to be managed. Equipment risk handling refers to the process of handling the risks of the target device to be managed.

4. The method according to any one of claims 1 to 3, characterized in that, When the management process includes device removal, the management operation is a removal operation, and the management request is a device removal request; The step of sending a management request to the server device in response to the management operation for the target device to be managed includes: In response to the removal operation for the target device to be managed, a device removal request is sent to the server device, so that the server device changes the binding or login status of the management account in the target device to be managed in response to the device removal request, and obtains second device update data, wherein the management processing result includes the second device update data; The provided device management execution result interface displays the management processing result sent by the server device in response to the management request for the target device to be managed, including: Based on the second device update data sent by the server device in response to the device removal request, a set of devices to be managed is determined, wherein the at least two devices to be managed include the set of devices to be managed and the target device to be managed; Provide an interface for the execution results of the device management to display the set of devices to be managed.

5. The method according to any one of claims 1 to 3, characterized in that, When the management process includes device status control, the management operation is a status control operation, and the management request is a device status control request. The step of sending a management request to the server device in response to the management operation for the target device to be managed includes: In response to the state control operation for the target device to be managed, a device state control request is sent to the server device, so that the server device controls the target device to be managed to enter a target working state in response to the device state control request, wherein the target working state includes at least one of screen-on state, screen-locked state, power-off state and sleep state, and the management processing result includes the target working state; The provided device management execution result interface displays the management processing result sent by the server device in response to the management request for the target device to be managed, including: Provide the device management execution result interface to display the target working status sent by the server device in response to the device status control request.

6. The method according to any one of claims 1 to 3, characterized in that, When the management process includes device location, the management operation is a location operation, and the management request is a device location request. The step of sending a management request to the server device in response to the management operation for the target device to be managed includes: In response to the positioning operation for the target device to be managed, a device positioning request is sent to the server device, so that the server device obtains the target location of the target device to be managed in response to the device positioning request, wherein the target location includes at least one of the estimated location, the current location and the historical location, and the management processing result includes the target location; The provided device management execution result interface displays the management processing result sent by the server device in response to the management request for the target device to be managed, including: Provide a device management execution result interface to display the target location sent by the server device in response to the device location request.

7. The method according to any one of claims 1 to 3, characterized in that, When the management process includes equipment risk handling, the management operation is a risk handling operation, and the management request is an equipment risk handling request. The step of sending a management request to the server device in response to the management operation for the target device to be managed includes: In response to the risk processing operation for the target device to be managed, a device risk processing request is sent to the server device, so that the server device performs risk processing on the target device to be managed in response to the device risk processing request and obtains risk update data, wherein the management processing result includes the risk update data; The provided device management execution result interface displays the management processing result sent by the server device in response to the management request for the target device to be managed, including: Based on the risk update data sent by the server device in response to the device risk handling request, the current risk status of the target device to be managed is determined; Provide an interface for the execution results of the device management to display the current risk status.

8. The method according to any one of claims 1 to 3, characterized in that, The equipment information includes at least one of the following: equipment status information, equipment location, equipment operating status, and equipment risk information.

9. The method according to claim 1, characterized in that, When the device information includes device risk information, after sending the local device information to the server device, the method further includes: The device management interface is provided to display the risk list sent by the server device in response to the device risk information, wherein the risk list is integrated by the server device in combination with the device risk information of each device to be managed; Based on the risk list, risk management is performed on the at least two devices to be managed.

10. A method for managing equipment, characterized in that, The method includes: The system receives a management request from a device to be managed, wherein the management request is sent in response to a management operation targeting the target device to be managed, and the target device to be managed is any one of at least two devices to be managed, the at least two devices to be managed are bound or logged in with the same management account, the management account is bound or logged in to each device to be managed through a management client, so as to manage the at least two devices to be managed through the management client, the at least two devices to be managed include at least one operating system, the management client running on the at least two devices to be managed is the same client, and the management client running on each device to be managed is adapted to the operating system of the device to be managed; The system receives local device information from each of the managed devices; integrates device information update data for each of the at least two managed devices based on the device information corresponding to each of the managed devices; sends the device information update data to each managed device so that the managed device can determine the managed device information corresponding to the managed device based on the device information update data, and provides a device management interface to display the managed device information corresponding to each managed device, and receives the management operation for the target managed device based on the managed device information; In response to the management request, management processing is performed on the target device to be managed; Send the management processing result to the device to be managed, so that the device to be managed displays the management processing result for the target device on the device management execution result interface.

11. The method according to claim 10, characterized in that, Before receiving the management request sent by the device to be managed, the method further includes: Receive the local device identifier sent by the device to be managed, wherein the device identifier is sent by the device to be managed when the management account successfully logs in to the management client running locally; Based on the device identifier, the corresponding device to be managed is updated in the device list corresponding to the management account to obtain the first device update data; The first device update data is sent to each of the devices to be managed, so that each of the devices to be managed displays the data of at least two devices bound or logged in with the same management account based on the first device update data.

12. The method according to claim 10, characterized in that, The management process includes at least one of equipment removal, equipment status control, equipment location, and equipment risk handling. Equipment removal refers to the process of removing the target device to be managed from the at least two devices to be managed. Equipment location refers to the process of locating the target device to be managed. Equipment status control refers to the process of controlling the working status of the target device to be managed. Equipment risk handling refers to the process of handling the risks of the target device to be managed.

13. The method according to any one of claims 10 to 12, characterized in that, The step of performing management processing on the target device to be managed in response to the management request includes: In response to the management request, a management instruction is sent to the target device to be managed, so that the target device to be managed executes the management instruction to complete the management process, wherein the management instruction includes at least one of a status control instruction, a location instruction, and a risk handling instruction.

14. An equipment management device, characterized in that, The equipment management device includes: A device display module is used to provide a device management interface to display at least two devices to be managed that are bound or logged in with the same management account. The management account is bound or logged in to each of the devices to be managed through a management client to manage the at least two devices to be managed through the management client. The at least two devices to be managed include at least one operating system. The management client running on the at least two devices to be managed is the same client, and the management client running on each device to be managed is adapted to the operating system of the device to be managed. The information integration module is used to send local device information to the server device, so that the server device can integrate the device information corresponding to the at least two devices to be managed to generate device information update data for each device to be managed; and to receive the device information update data sent by the server device in response to the device information. Based on the updated device information, determine the device information to be managed corresponding to the device to be managed; provide the device management interface to display the device information to be managed for each device to be managed; and receive management operations for the target device to be managed based on the device information to be managed. A management trigger module is used to send a management request to the server device in response to the management operation for the target device to be managed, so that the server device performs management processing on the target device to be managed in response to the management request, wherein the target device to be managed is any one of the at least two devices to be managed; The result processing module is used to provide a device management execution result interface to display the management processing result sent by the server device in response to the management request for the target device to be managed.

15. The apparatus according to claim 14, characterized in that, The device further includes: The device binding module is used to bind or log in to the locally running management client based on the management account and obtain a success message; Based on the success information, a local device identifier is sent to the server device, so that the server device updates the corresponding device to be managed to the device list corresponding to the management account based on the device identifier, thereby obtaining the first device update data; Receive the first device update data sent by the server device in relation to the device identifier; Based on the update data of the first device, at least two devices to be managed are obtained that are bound or logged in with the same management account.

16. The apparatus according to claim 14, characterized in that, The management process includes at least one of equipment removal, equipment status control, equipment location, and equipment risk handling. Equipment removal refers to the process of removing the target device to be managed from the at least two devices to be managed. Equipment location refers to the process of locating the target device to be managed. Equipment status control refers to the process of controlling the working status of the target device to be managed. Equipment risk handling refers to the process of handling the risks of the target device to be managed.

17. The apparatus according to any one of claims 14 to 16, characterized in that, When the management process includes device removal, the management operation is a removal operation, and the management request is a device removal request; The management triggering module is further configured to send a device removal request to the server device in response to the removal operation for the target device to be managed, so that the server device changes the binding or login status of the management account in the target device to be managed in response to the device removal request, and obtains second device update data, wherein the management processing result includes the second device update data; The result processing module is further configured to determine a set of devices to be managed based on the second device update data sent by the server device in response to the device removal request, wherein the at least two devices to be managed include the set of devices to be managed and the target device to be managed; Provide an interface for the execution results of the device management to display the set of devices to be managed.

18. The apparatus according to any one of claims 14 to 16, characterized in that, When the management process includes device status control, the management operation is a status control operation, and the management request is a device status control request. The management triggering module is further configured to send a device status control request to the server device in response to the status control operation for the target device to be managed, so that the server device controls the target device to be managed to enter a target working state in response to the device status control request, wherein the target working state includes at least one of screen-on state, screen-locked state, power-off state and sleep state, and the management processing result includes the target working state; The result processing module is also used to provide the device management execution result interface to display the target working status sent by the server device in response to the device status control request.

19. The apparatus according to any one of claims 14 to 16, characterized in that, When the management process includes device location, the management operation is a location operation, and the management request is a device location request. The management triggering module is further configured to send a device location request to the server device in response to the location operation for the target device to be managed, so that the server device can obtain the target location of the target device to be managed in response to the device location request, wherein the target location includes at least one of the estimated location, the current location and the historical location, and the management processing result includes the target location; The result processing module is also used to provide the device management execution result interface to display the target location sent by the server device in response to the device positioning request.

20. The apparatus according to any one of claims 14 to 16, characterized in that, When the management process includes equipment risk handling, the management operation is a risk handling operation, and the management request is an equipment risk handling request. The management triggering module is further configured to send the device risk processing request to the server device in response to the risk processing operation for the target device to be managed, so that the server device performs risk processing on the target device to be managed in response to the device risk processing request and obtains risk update data, wherein the management processing result includes the risk update data; The result processing module is further configured to determine the current risk status of the target device to be managed based on the risk update data sent by the server device in response to the device risk processing request; Provide an interface for the execution results of the device management to display the current risk status.

21. An equipment management device, characterized in that, The equipment management device includes: A request receiving module is configured to receive management requests sent by devices to be managed, wherein the management request is sent in response to a management operation targeting a target device to be managed, the target device to be managed is any one of at least two devices to be managed, the at least two devices to be managed are bound or logged in with the same management account, the management account is bound or logged in to each device to be managed through a management client, so as to manage the at least two devices to be managed through the management client, the at least two devices to be managed include at least one operating system, the management client running on the at least two devices to be managed is the same client, and the management client running on each device to be managed is adapted to the operating system of the device to be managed; The device management module is used to receive local device information sent by each of the devices to be managed; integrate device information update data for each device to be managed based on the device information corresponding to the at least two devices to be managed respectively; send the device information update data to each device to be managed so that the device to be managed can determine the device information to be managed corresponding to the device to be managed based on the device information update data; provide a device management interface to display the device information to be managed corresponding to each device to be managed; and receive the management operation for the target device to be managed based on the device information to be managed. The device management module is also used to perform management processing on the target device to be managed in response to the management request; The result sending module is used to send management processing results to the device to be managed, so that the device to be managed can display the management processing results for the target device on the device management execution result interface.

22. A device to be managed for equipment management, characterized in that, The devices to be managed include: The first memory is used to store executable instructions; The first processor, when executing executable instructions stored in the first memory, implements the device management method according to any one of claims 1 to 9.

23. A server-side device for device management, characterized in that, The server-side equipment includes: The second memory is used to store executable instructions; The second processor, when executing executable instructions stored in the second memory, implements the device management method according to any one of claims 10 to 13.

24. A computer-readable storage medium storing executable instructions, characterized in that, The executable instructions, when executed by a first processor, implement the device management method according to any one of claims 1 to 9; or, when executed by a second processor, the executable instructions implement the device management method according to any one of claims 10 to 13.

25. A computer program product comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by the first processor, they implement the device management method according to any one of claims 1 to 9; or, when the computer program or instructions are executed by the second processor, they implement the device management method according to any one of claims 10 to 13.

Images