Staged cancellation of device registration to service

Abstract

Large numbers of mobile or desktop electronic devices may sometimes be falsely unregistered from security and management services. Thereafter, re-registration from the device itself must be performed one by one. In order to solve the problem, the call agent in each device is only partially removed or forbidden after receiving a registration cancelling instruction. The remaining portion of the call agent may be removed after a period of chill. During the chill period, a persistent component in an active state in the call agent contacts the monitoring center, and checks whether the registration cancelling instruction has been cancelled. If cancelled, the devices may be re-registered from the monitoring center. This persistent component is intended to reexist after the device is reimaged and in this case to re-instantiate itself. This mechanism provides the ability to reverse unintended device cancellation of registration.

Description

Technical Field

[0001] The present disclosure relates to the management, control, and security of mobile devices. Specifically, it relates to preventing a device from being accidentally deregistered from a service that provides management, control, and security. Background Art

[0002] Systems such as those provided by Absolute Software Corporation are used to manage a large number of remote devices, allowing them to be tracked and blocked, receive software updates, delete data therefrom, and provide monitoring information that helps catch thieves. A persistent agent runs on the protected or managed device, and it periodically calls a monitoring center. If the agent is deleted, the agent can be automatically restored the next time the device calls the monitoring center. Since a non-user-accessible persistence module is embedded in the device's BIOS (Basic Input / Output System), the agent can be regenerated. However, through appropriate communication between the monitoring center and the device, the persistence module can be disabled, causing the device to stop regenerating the agent and stop calling the monitoring center. When this happens, the device will be completely deregistered and unable to call the monitoring center, so the monitoring center can no longer communicate with it either.

[0003] The problem that can occur is that a device may be accidentally deregistered, and if this happens, the monitoring center will not be able to reregister it. There may be an error in the application that performs the automatic deregistration of the device, which may accidentally attempt to deregister an entire group of devices. The same may happen if a malformed script or SQL (Structured Query Language) command is run directly on the registered device database of the monitoring center. The instruction to deregister the device may be accidental or incorrect, and may be a well-intentioned action by a misguided person or a malicious act. If a large number of devices are accidentally deregistered, the problem will be more serious.

[0004] Currently, re-registering a device that has been erroneously deregistered requires manually re-registering each device individually from each device itself. Summary of the Invention

[0005] The inventors have realized that a protection measure is needed to prevent a device from being accidentally deregistered. The solution is to add a cooling-off period between the deregistration request and the complete removal of the agent from the device. This creates a time period for detecting and correcting accidental and / or unintentional deregistration requests. After receiving a deregistration request, the agent responsible for the connection between the device and the monitoring center will be partially disabled. After the cooling-off period ends, the agent will be completely disabled. Brief Description of the Drawings

[0006] Figure 1 is a schematic block diagram of a system showing a device deregistration situation.

[0007] Figure 2is a flowchart showing the steps taken by a system to implement a cooling-off period for a deregistration request according to an embodiment of the present invention.

[0008] Figure 3 is a flowchart of steps taken by a system using a Chromebook (web notebook) according to an embodiment of the present invention, where there is no persistent module in the BIOS. Specific Embodiments

[0009] A. Glossary

[0010] Agent. As used herein, an agent refers to a persistent and optionally stealthy software, hardware, or firmware agent. Generally, an agent comprises or consists of executable instructions residing in a processor-readable memory of a computer or other electronic device. An agent typically provides service functions that require communication with a remote server. An agent has anti-tampering capabilities that can be enabled to support and / or provide various services such as data deletion, firewall protection, data encryption, location tracking, message notification, software deployment, and updates. An exemplary embodiment of an agent is provided in the commercially available product Computrace Agent TM An exemplary embodiment of the agent is provided in Computrace Agent TM The underlying technology of Computrace Agent TM has been disclosed and patented in the United States and other countries / regions, and these patents have been commonly assigned to Absolute Software Corporation. For example, see U.S. Patents 5,715,174, 5,764,892, 5,802,280, 6,244,758, 6,269,392, 6,300,863, 6,507,914, 7,818,803, 7,945,709 and related foreign patents. Details of the persistent functionality of the agent have been disclosed in U.S. Patent Applications Publication Nos. US2005 / 0216757 and US2006 / 0272020. The technical disclosures of these documents are incorporated herein by reference as if fully set forth. An agent equivalent to Computrace Agent

[0011] BIOS - Basic Input / Output System. Also included herein is UEFI, which performs the same tasks in a more modern and secure environment.

[0012] Device. Refers to an electronic device to be protected. Examples of devices include laptop computers, mobile phones, personal digital assistants, smartphones, removable media, personal media devices, gaming devices, personal computers, tablet computers, e-books, and netbooks. The agent resides in the device, and the device can also be referred to as the host of the agent. The device can also be referred to as a client.

[0013] EMS-ESN management system, which is used by the technical support team to view and modify device and account configurations.

[0014] ESN - Electronic Serial Number, usually refers to a device with an agent installed.

[0015] FW – Firmware: Provides programming instructions for controlling, monitoring, and data operation of an electronic device. Firmware is usually stored in a non-volatile memory component in the device, such as ROM (Read-Only Memory), EPROM (Electrically Programmable Read-Only Memory), or flash memory. Firmware such as the ROM BIOS of a personal computer may only contain the basic functions of the computer and may provide services for higher-level software. The firmware of a device may be occasionally changed during the device's life cycle, such as updating the firmware, fixing bugs, or adding functions. The firmware may use settings stored inside the firmware or at other locations in the device's non-volatile memory. The term "firmware" used in this article refers to device firmware, such as BIOS, UEFI, or similar firmware, unless otherwise clearly stated.

[0016] ISV - Independent Software Vendor

[0017] The term "module" can refer to any component in the present invention, as well as any or all features of the present invention, but is not limited thereto. A module can be a software, firmware, or hardware module that runs by a processor executing computer-readable instructions stored in the software or firmware.

[0018] OEM – Original Equipment Manufacturer

[0019] PaaS - Persistence as a Service. Device components are maintained and automatically regenerated when damaged or deleted. Such functions can be, for example, the maintenance of software applications on the device.

[0020] Persistence - The ability of a code module to regenerate after being damaged or deleted. For example, a persistence module is stored in the firmware of an electronic device. The persistence module can contact or generate an agent to establish a connection between the device and the monitoring center. During the connection with the monitoring center, the agent can be instructed to rebuild its missing parts or restore other software components on the device.

[0021] Persistence module - The code part in the persistence agent that can initiate and / or generate a call to the monitoring center even though other parts of the persistence agent are missing or damaged.

[0022] SQL - Structured Query Language, a language for interacting with databases

[0023] UEFI - Unified Extensible Firmware Interface

[0024] B. Exemplary Embodiments

[0025] Figure 1 is a schematic block diagram of an embodiment of an exemplary system that, among other functions, can manage the registration and deregistration of devices. In Figure 1 the example of, the registration and deregistration of devices can be managed in multiple ways. In the system shown, there are 3 components that can call the device deregistration service 90, including but not limited to the Customer Center 100, Google Sync Service 102, or Professional Services 104. The Customer Center 100 is a console where customers can log in to manage their devices. The Google Sync Service (A7 GSS) 102 is used to manage Google devices such as Chromebooks. Professional Services (PSNG) 104 can also call the device deregistration service 90.

[0026] The device deregistration service 90 calls a proxy service which, in this application, is called CTSRV108. CTSRV is a component of the system responsible for handling device persistence and deregistration. CTSRV 108 communicates with the SQL license server 110 which records the currently valid licenses associated with the device and their corresponding status. Although changes can be made to the SQL license server 110 using CTSRV 108, the Internal Management System (EMS) 112, Technical Support, and Database Administrators 114 and other legacy systems 116 can also make changes to the SQL license server 110.

[0027] The SQL license server communicates with CTSRV 108 which deregisters the device at the appropriate time. CTSRV108 can complete the deregistration of Windows, Mac, and Linux devices. For Chromebook devices, CTMSever 120 is used.

[0028] The SQL license server manages the active licenses associated with the device and tracks the status of each license. Each license has an "active" status (A) indicating that the license is being used by the device; or a "deactivated" status (D) indicating that the license can be used freely on other devices. The SQL license server also contains a time field for setting a predetermined "cooling-off" period after receiving a deregistration request.

[0029] The main components include:

[0030] A) For For example: the persistence module 118 in the device, the agent in the device that communicates with the server 108, the server 110, the cool-down time field in the server (not shown), the communication link between the server and the agent.

[0031] Or

[0032] B) For For example: the agent 118 in the device that communicates with the server 108, the server 110, the cool-down time field in the server (not shown), the communication link between the server and the agent.

[0033] Or

[0034] C) For For example: The extension 121, the server 120, the cool-down time field in the server (not shown), the server and the communication link therebetween.

[0035] One embodiment includes at least a portion of the following elements:

[0036] A trigger for deregistering in the server license table;

[0037] The server delays the complete removal of the agent until the end of the cool-down period;

[0038] A PaaS override for maintaining account deregistration.

[0039] Go to Figure 2 And Figure 3 , in a preferred embodiment, the process begins when the system receives a request to deregister one or more devices, see step 200. It should be noted that Figure 2 And Figure 3 are almost identical, however, Figure 2 uses the language standard of Windows, Linux, or Mac, while Figure 3The language standard of Chromebook is used. This deregistration request is usually received by the customer center 100, Google Sync Service 102, or professional service application 104. Through the device deregistration service 90, the SQL license database 110 is updated so that the license of the device for which the deregistration is requested is set to inactive or "D" (see step 202). In step 204, a cooling-off period is generated. The cooling-off period is achieved by setting a time field in the SQL license database 110 to the end time of the cooling-off period. In one embodiment, this timestamp can be called, for example, "RemovalTimeUTC". After receiving the deregistration command, the servers 108 or 120 of the monitoring center (such as CTSRV or CTMServer) do not immediately mark the agent in the device for removal. If the current time is less than RemovalTimeUTC, the server 108 will now delay, ignore, or partially execute the agent removal instruction for the device. In a preferred embodiment, the timestamp is automatically set by a database trigger to the current time of the instruction plus a cooling-off period. When anyone or any subsystem updates the License.Status (license status) corresponding to the device to "D", this trigger will be triggered, where "D" means that the agent will be disabled for this device. If the application or customer needs to immediately remove the agent and the deregistration command cannot be revoked, RemovalTimeUTC can be set to NULL (empty), for example, by performing a second update after setting License.Status to "D".

[0040] During the cooling-off period, the device appears to be deregistered (status "D") in all aspects of the system, and all agent components used to obtain and report payloads to the server have been removed. Since the status is "D", the license is not consumed during the cooling-off period. During this period, the core persistent part of the agent (i.e., the persistence module) remains on the device and maintains a connection with the monitoring center at the callback period configured on the server. Refer to Figure 2 , the system receives an agent call, see step 206, and checks the SQL license table in step 208 to determine whether the status is still "D". If the status is still "D", the deregistration request is considered still valid. Then, the server checks whether the cooling-off period has ended, see step 210. If the cooling-off period has ended, the server will instruct the agent to be completely disabled. However, if the cooling-off period has not ended, the system will instruct the agent to be only partially disabled (if not already done), see step 212. Although partial disabling of the agent is preferred, it can be understood that the agent can also not be disabled without departing from the disclosed embodiments. Then the system returns to step 206.

[0041] Before the cool-down period expires, the device can be re-registered (i.e., its deregistration instruction can be cancelled). This can be done individually for each device or in batches. To do this, the license table will be updated with a new flag or label. In one embodiment, this can be achieved by updating its license status in the license table to inactive (e.g., "I" in one embodiment). When the device makes its next call, see step 206, the system will recognize that they have been marked for re-registration and that the deregistration request is no longer valid. See step 210, its status will be updated to active (e.g., "A"), and the deleted proxy components will be reinstalled on the device in accordance with the normal operation of the proxy 214. This solution is intended to provide "last resort" protection and is not expected to be a normal or frequent use case. After re-registration, the device will consume one license.

[0042] In a preferred embodiment, when setting a cool-down period in the database 110 of the server 108, a trigger is created in the license table. For example: if the status has been updated and the new status is "D", then the RemovalTimeUTC is set to the current time + 72 hours. The default duration can be changed by modifying the trigger. The EMS provides the function of shortening / modifying the removal time or completely disabling the removal time at the device or account level.

[0043] For example, in the server 108 (CTSRV) applicable to the device, when processing a device call immediately after a partial successful removal of the proxy (i.e., after removing all components except the persistence module), step 210 is executed to check whether the current time is greater than the RemovalTimeUTC. If not, the server will stop processing the call. If so, it will continue to process until the proxy is completely removed 216, and the persistence module is deactivated.

[0044] During normal operation of the proxy, the callback time can be set to, for example, 24.5 hours. During partial or complete removal of the proxy, the callback time can be set to, for example, 15 minutes. After partial removal of the proxy, the callback time is set to about one hour, which usually allows for a quick recovery when resetting the status field in the monitoring center database. This is the frequency at which the persistence module calls the monitoring center to check for re-registration instructions.

[0045] and (Android) devices will query the monitoring center (CTMServer) to determine whether their ESN has been disabled and marked for removal. If the device has been marked for removal but the cool-down period has not ended, the system will instruct the device to stop reporting its normal data load, but will continue to callback to obtain the latest removal status.

[0046] Additional changes can be made to adjust the callback time to a shorter time before the RemovalTimeUTC arrives. At the end of the call from the persistence module to the server during the cooling period, the callback time is provided to the agent as part of the EndSession (end of event) processing.

[0047] C.PaaS device

[0048] For some applications, a delay of 48 - 72 hours may be unacceptable for completely removing the agent and deactivating the firewall persistence function. For example, PaaS integration with ISV. This is because customers of non-Absolute Software companies usually cannot monitor the status of their devices through the console. Therefore, the control of registration and deregistration is initiated from the device (rather than the console), and timely uninstallation of the PaaS application is expected. This includes timely deletion of all Absolute Software company software and agents from the device.

[0049] For PaaS devices, when the last application has been uninstalled and the server triggers deregistration from the PaaS-held account, after the license status is set to "D", the RemovalTimeUTC will be updated to NULL.

[0050] Changes

[0051] If the customer requests immediate and complete removal of the Absolute Software company agent / software on the device after requesting deregistration (such as the PaaS customer mentioned above), this solution is not applicable. In addition, this solution is also not applicable to OEM test and demonstration accounts because these accounts need to be completely deregistered within a time limit. However, in some embodiments of the present invention, a function is added to allow the EMS to override the cooling-off period on a per-account basis. Another example is device refurbishment / e-waste recycling, where immediate deregistration may be required.

[0052] In some embodiments, a daily monitoring report can be provided to continue manual review of partially deregistered devices.

[0053] It can be allowed to override the RemovalTimeUTC through DBA / SN (Database Administrator, immediate service ticket).

[0054] The system may provide support to adjust the cooling-off time (increase or decrease) according to each device, mainly for testing, but this can be used in special cases.

[0055] The EMS can provide viewing and editing of the RemovalTimeUTC of the device.

[0056] When the deregistration threshold is reached, an automatic alert may be generated. This focuses on deregistration requests (rather than completed deregistrations) because the goal is to prevent unnecessary deregistrations before they are completed.

[0057] When describing a processor, it may include two or more constituent processors. A computer-readable memory may be divided into multiple constituent memories of the same or different types. Without departing from the scope of the present invention, the steps in flowcharts and other diagrams may be executed in a different order, certain steps may be deleted, or additional steps may be added.

[0058] The detailed description is presented primarily in the form of methods or processes, symbolic representations of operations, and the functions and features of the present invention. These method descriptions and representations are the means by which those skilled in the art most effectively convey the substance of their work to other skilled persons in the art. A method or process implemented in software is generally considered to be a self-consistent sequence of steps for achieving a desired result. These steps involve physical operations on physical quantities. These physical quantities typically (but not necessarily) take the form of electrical or magnetic signals capable of being stored, transmitted, combined, compared, and otherwise manipulated. It can be further understood that the boundaries between hardware, software, and firmware are not always clear, and those skilled in the art should understand that a process implemented in software can be embodied in hardware, firmware, or software, in the form of encoded instructions (such as microcode and / or stored programming instructions). In general, unless otherwise stated, a single element may represent a plurality, and vice versa, without loss of generality.

Claims

1. An electronic device management system for managing electronic services, comprising: A management server; At least one electronic device registered with the electronic service; A call agent installed on the electronic device for calling the management server at a predetermined interval or after a predetermined event; A database containing at least the registration status and identity information of the at least one electronic device; Wherein, when the management server receives a request to cancel the registration service of the electronic device from the at least one electronic device, the management server accesses the database, changes the status of the device to a disabled state, and sets a predetermined cooling-off period; once the status of a device is changed to disabled, the following steps occur: a. The call agent of the device continues to call the server at a predetermined interval or after a predetermined event; b. After receiving a call from the device, the management server accesses the database and checks whether the status of the device has changed from the disabled state; c. If the status is no longer disabled, the device is re-registered to the electronic service, and the process ends; if the status is still disabled, the server determines whether the predetermined cooling-off period has ended; d. If the cooling-off period has ended, the server instructs the call agent to uninstall and end the process; if the cooling-off period has not ended, repeat steps a to d.

2. The electronic device management system according to claim 1, wherein After the status becomes disabled, the cooling-off period is automatically set.

3. The electronic device management system according to claim 1, wherein After the status changes, the agent related to the electronic service will be partially removed.

4. A method for managing the registration or cancellation of multiple electronic devices in an electronic service, comprising: a. A management server receives a request to cancel the registration of at least one of the multiple electronic devices in the electronic service; b. The management server accesses a database containing at least the registration status and identity information of the multiple electronic devices; c. Changes the status of at least one of the multiple electronic devices to a disabled state; d. Sets a predetermined cooling-off period in the database; e. The device continues to call the server; f. The management server receives the call and checks the database to identify the registration status of the at least one device among the multiple devices; g. If the status is no longer disabled, re-register at least one of the multiple devices to the electronic service, and the process ends; h. If the status is still disabled, determine whether the predetermined cooling-off period has ended; i. If the cooling-off period has ended, the server instructs at least one of the multiple devices to uninstall the agent associated with the electronic service, and the process ends; j. If the cooling-off period has not ended, repeat steps e to j.

Images