Gradually unenroll your device from the service

Abstract

Fleets of mobile or desktop electronic devices may be accidentally deregistered from security and management services, after which they must be individually reregistered from the devices themselves. To resolve this, the call agent within each device is only partially deleted or disabled upon receipt of a deregistration command. The remainder of the call agent is deleted after a cool-off period. During the cool-off period, the persistence component of the call agent that remains active connects to the monitoring center to check for the presence of a cancel deregistration command. If present, the device can be reregistered from the monitoring center. This persistence component is designed to survive device reimaging, re-instantiating itself in such an event. This connection provides the ability to recover from unintentional device deregistration.

Description

[Technical Field]

[0001] This disclosure relates to the management, control and security of mobile devices, and in particular to preventing unwanted deregistration of devices from services that provide management, control and security. [Background technology]

[0002] Systems such as those offered by Absolute Software Corporation exist to manage fleets of remote devices, allowing them to be tracked and blocked, receive software updates, have data deleted from them, and provide monitoring information useful in catching thieves. Protected or managed devices run a persistent agent that periodically calls a monitoring center. If the agent is deleted, it can be automatically restored the next time the device calls the monitoring center. Regeneration of the agent is made possible by a user-inaccessible persistence module embedded in the device's BIOS. However, with appropriate communication from the monitoring center to 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 is completely unregistered and no longer has the ability to call the monitoring center, and therefore the monitoring center can no longer communicate with the device.

[0003] A problem that can arise is that a device can unintentionally deregister, in which case the monitoring center cannot re-register the device. A bug in the application that performs the automatic deregistration of devices could attempt to accidentally deregister an entire fleet. The same could happen with a rogue script or SQL command run directly on the registered device database in the monitoring center. The command to deregister a device could be an accident or mistake, it could be an action taken in good faith by someone who was misinformed, or it could be a malicious action. The problem becomes even greater when larger fleets of devices are unintentionally deregistered.

[0004] Currently, re-registering devices that have been accidentally unregistered involves manually re-registering the devices one by one from each device itself. Summary of the Invention

[0005] The inventors recognized the need for protection against unintentional device deregistration. The solution is to add a cool-off period between the deregistration request and the complete removal of the agent from the device. This creates a period for detection and correction of accidental and / or unintentional deregistration requests. Upon receiving an unregistration request, the agent responsible for the connection between the device and the monitoring center is partially disabled. After the cool-off period expires, the agent is fully disabled. [Brief explanation of the drawings]

[0006] [Figure 1] FIG. 1 is a schematic block diagram of a system illustrating the context of device deregistration. [Figure 2] 1 is a flowchart illustrating steps taken by a system to implement a deregistration request using a cool-off period, according to an embodiment of the present invention. [Figure 3]1 is a flowchart illustrating steps performed by a system using a Chromebook without a persistence module in the BIOS, in accordance with an embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0007] A. Glossary Agent - As used herein, an agent is a software, hardware, or firmware agent that is persistent and optionally covert. Typically, an agent includes or consists of executable instructions that reside in processor-readable memory within a computer or other electronic device. Agents typically provide service functionality that requires communication with a remote server. Agents are tamper-resistant and can be enabled to support and / or provide a variety of services, such as data deletion, firewall protection, data encryption, location tracking, message notification, software deployment and updates. An exemplary embodiment of an agent is the commercially available product Computrace Agent. TM Seen in Computrace Agent TM The technology underlying Computrace Agent has been disclosed and patented in the United States and other countries, and these patents are generally assigned to Absolute Software Corporation. See, for example, U.S. Patent Nos. 715,174, 5,764,892, 5,802,280, 6,244,758, 6,269,392, 6,300,863, 6,507,914, 7,818,803, and 7,945,709, and related foreign patents. Details of the agent's persistence capabilities are disclosed in U.S. Patent Application Publication Nos. US2005 / 0216757 and US2006 / 0272020, the technical disclosures of which are incorporated by reference in their entirety as if fully set forth herein. TMIt is possible to use an agent equivalent to the agent, and less preferably, an alternative agent with less functionality may be used. For purposes of this disclosure, the minimum functional attribute of an agent is to facilitate communication between the electronic device and a monitoring center or other remote computer or server. Communication is typically initiated by the agent, but in some embodiments may be initiated by the monitoring center.

[0008] BIOS - Basic Input / Output System. As used herein, it also includes UEFI, which performs the same tasks in a more modern and secure context.

[0009] Device - This is the electronic device to be protected. Examples of devices include laptops, cell phones, personal digital assistants, smart phones, removable media, personal media devices, gaming devices, personal computers, tablet computers, e-books, and netbooks. The agent resides on the device, which may also be called a host for the agent. The device may also be called a client.

[0010] EMS-ESN management system, used by the technical support team to view and change device and account configurations.

[0011] ESN - Electronic Serial Number, typically indicates the device on which the agent is installed.

[0012] FW—Firmware. Programming instructions that provide control, monitoring, and data manipulation for an electronic device. Firmware is typically stored in a device's non-volatile memory components, such as read-only memory (ROM), electronically programmable ROM (EPROM), or flash memory. Firmware, such as a personal computer's ROM BIOS, may contain only basic, fundamental computer functions and may provide services to higher-level software. Changes to a device's firmware may occur occasionally during its lifetime, for example, to update the firmware, fix bugs, or add features. Firmware may use settings stored within the firmware or elsewhere in the device's non-volatile memory. As used herein, the term "firmware" refers to device firmware, such as BIOS, UEFI, or the like, unless otherwise specified.

[0013] ISV - Independent Software Vendor.

[0014] The term "module" can refer, without limitation, to any component of the present invention and any or all of the functionality of the present invention. A module may be a software, firmware, or hardware module that is functioned by a processor executing computer-readable instructions stored in the software or firmware.

[0015] OEM - Original Equipment Manufacturer.

[0016] PaaS - Persistence as a Service. Components of a device are maintained and automatically regenerated if they are damaged or deleted. Such functionality may be, for example, the maintenance of software applications on the device.

[0017] Persistence - the ability of a module of code to regenerate if it is damaged or deleted. For example, a persistence module is stored in the FW within an electronic device. The persistence module can connect to or spawn an agent that connects the device to a monitoring center. While connected to the monitoring center, the agent can be instructed to rebuild its lost parts or restore other software components on the device.

[0018] Persistence Module - A portion of code within the Persistence Agent that can initiate or generate calls to the Monitoring Center even if other parts of the Persistence Agent are absent or corrupted.

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

[0020] UEFI - Unified Extensible Firmware Interface.

[0021] B. Exemplary Embodiments FIG. 1 is a schematic block diagram of one embodiment of an exemplary system that can manage, among other functions, device registration and deregistration. In the example of FIG. 1, there are multiple ways in which device registration and deregistration can be managed. In the illustrated system, there are three components that can invoke the device deregistration service 90, including, but not limited to, a customer center 100, a Google sync service 102, or a professional service 104. The customer center 100 is a console that customers can log in to manage their devices. The Google sync service (A7 GSS) 102 is used to manage Google devices such as Chromebooks. The professional service (PS NG) 104 can also invoke the device deregistration service 90.

[0022] The device deregistration service 90 performs calls to a proxy service, which for purposes of this application is referred to as CTSRV 108. CTSRV is the component of the system that handles both device persistence and deregistration. CTSRV 108 communicates with a SQL license server 110, which documents the current active licenses associated with devices and their corresponding states. Changes to the SQL license server 110 can be made using CTSRV 108, but changes can also be made to the SQL license server 110 by an internal management system (EMS) 112, technical support and database administrators 114, and other legacy systems 116.

[0023] The SQL license server communicates with CTSRV 108 and deregisters devices when appropriate. CTSRV 108 completes deregistration for Windows, Mac, and Linux-based devices. For Chromebook devices, CTMSever 120 is used.

[0024] The SQL License Server manages active licenses associated with devices and tracks the state of each license. Each license can have an active state (A), where the license is in use by a device, or an inactive state (D), where the license is free to be used by a different device. The SQL License Server also includes a time field to set to reflect a predetermined "cool-off" period after a request to deregister is received.

[0025] The main components are as follows: A) For Windows®, for example, a persistence module 118 in the device, an agent in the device communicating with the server 108, the server 110, a cool-off time field in the server (not shown), and a communication link between the server and the agent. or B) For MacOS, for example, an agent 118 in the device communicating with the server 108, the server 110, a cool-off time field in the server (not shown), and a communication link between the server and the agent. or C) For Chromebooks, for example, the Chromebook extension 121, the server 120, a cool-off time field in the server (not shown), and a communication link between the server and the Chromebook.

[0026] One embodiment includes at least some of the following elements: Triggers deregistration in the server's license table Servers that delay complete agent removal until the end of the cool-off period PaaS override to preserve account deregistration

[0027] 2 and 3, in a preferred embodiment, the process begins with the system receiving a request to deregister one or more devices 200. It should be noted that while FIGS. 2 and 3 are nearly identical, FIG. 2 uses the language standards of Windows, Linux, or Mac, while FIG. 3 uses the language standards of Chromebooks. This deregistration request is typically received by the customer center 100, the Google sync service 102, or the professional services application 104. Through the device deregistration service 90, the SQL license database 110 is updated so that the license for the device requesting deregistration is set to inactive, or "D" (see step 202). In step 204, a cool-off period is created. This is accomplished by setting a time field in the SQL license database 110 to the end of the cool-off period. In one embodiment, this timestamp may be called, for example, "RemovalTimeUTC." When the server 108 or 120 in the monitoring center (e.g., CTSRV or CTMServer) receives an unregistration command, instead of immediately flagging the agent in the device for removal, the server 108 delays, ignores, or partially executes the agent removal instruction for the device if the current time is less than RemovalTimeUTC. In a preferred embodiment, the timestamp is automatically set to the current time of the instruction plus a cool-off period by a database trigger that is fired when the device's corresponding license status is updated to "D" by anyone or any subsystem, where "D" is a flag indicating the agent is to be disabled for that device. If an application or customer requires immediate agent removal without the ability to cancel the unregistration command, for example, as the second update after setting the license status to "D," RemovalTimeUTC can be set to NULL.

[0028] During the cool-off period, the device appears unregistered from all aspects of the system (state equals "D") and has all agent components that retrieve payloads and report to the server removed. Because the state is "D," no licenses are consumed during the cool-off period. During this time, the core persistence portion of the agent (i.e., the persistence module) remains on the device and maintains a connection to the monitoring center via a callback period configured on the server. Referring to FIG. 2, the system receives an agent call 206 and checks the SQL license table in step 208 to see if the state is still "D." If the state is still "D," the unregistration request is considered still valid. The server then checks 210 whether the cool-off period has expired. If the cool-off period has expired, the server instructs the agent to fully disable itself. However, if the cool-off period has not expired, the system instructs the agent to only partially disable itself 212 (if it has not already completed). While partial disabling of the agent is preferred, it can be appreciated that the agent need not be disabled without departing from the disclosed embodiments. The system then returns to step 206.

[0029] Before the cool-off period expires, the device can re-register (i.e., have these de-registration commands revoked). This can be done individually for each device or collectively. To do this, the license table is updated with a new flag or tag. In one embodiment, this can be done, for example, by updating the license status to inactive ("I" in one embodiment) in the license table. The next time the device calls at 206, the system identifies that the flag for re-registration is set and that the de-registration request is no longer valid 210, the status is updated to active (e.g., "A"), and any removed agent components are reinstalled on the device according to the normal operation of the agent 214. This solution provides "last resort" protection and is not expected to be a common or frequent use case. Upon re-registration, the license is consumed by the device.

[0030] When setting a cool-off period, in a preferred embodiment, a trigger is created in the license table in database 110 in server 108. For example, if the status is updated and the new status is "D", set RemovalTimeUTC to the current time + 72 hours. The default value of the period can be changed by modifying the trigger. The ability to shorten / modify or completely disable the removal time is provided by the EMS on a per-device or per-account level.

[0031] In the Server for Windows® Devices 108 (CTSRV), for example, when processing a device call immediately after a successful partial removal of the agent (i.e., after removal of all components except the persistence module), a check is performed in step 210 to determine whether the current time is greater than RemovalTimeUTC. If not, the server stops processing the call. If so, processing continues to completely remove the agent 216 by deactivating the persistence module.

[0032] During normal execution of the agent, the callback time may be set to, for example, 24.5 hours. During the process of partial or complete deletion of an agent, the callback time may be, for example, 15 minutes. After a partial agent deletion, a value on the order of one hour for the callback time generally allows for quick recovery when the status field is reset in the monitoring center database. This is how often the persistence module calls the monitoring center to check for re-registration instructions.

[0033] Chromebooks and Android devices query the monitoring center (CTMServer) to determine if the ESN has been invalidated and flagged for deletion. If the ESN has been flagged for deletion but the cool-off period has not elapsed, the device is instructed to stop reporting the normal payload of data, but continues to call back with the latest deletion status.

[0034] A further modification can be made to adjust the callback time to a short period before the RemovalTimeUTC has elapsed. The callback time is given to the agent as part of EndSession processing at the end of a call from the persistence module to the server during the cool-off period.

[0035] C. PaaS Devices For certain applications, having a 48-72 hour delay for complete agent removal and deactivation of FW persistence may not be acceptable. An example is PaaS integrations with ISVs, where non-Absolute customers typically do not have console access to monitor the state of their devices. Instead, the control of registration and deregistration is expected to be initiated from the device (not the console), uninstalling the PaaS application at the appropriate time. This includes the timely removal of all Absolute software and agents from the device.

[0036] For PaaS devices where the last application is uninstalled and the server triggers unregistration from the PaaS holding account, RemovalTimeUTC is updated to NULL after the license state is set to "D".

[0037] Variations This solution is not applicable when the Absolute agent / software needs to be completely removed from the device immediately after the customer requests deregistration (e.g., PaaS customers mentioned above). It is also not applicable to OEM test and demo accounts where complete deregistration is required under time constraints. However, some embodiments of the present invention incorporate functionality that allows the EMS to override the cool-off period on a per-account basis. Another example is device refurbishment / waste recycling, where immediate deregistration may be required.

[0038] In some embodiments, a daily report may be provided for monitoring so that partially deregistered devices continue to be manually reviewed.

[0039] Overriding RemovalTimeUTC via a DBA / SN, Database Administrator, Service Now ticket may be allowed.

[0040] The system may provide support for adjusting the cool-off time (up or down) on a per-device basis, primarily for testing purposes, but this may also be used in special circumstances.

[0041] The EMS may provide the ability to view and edit the RemovalTimeUTC of a device.

[0042] When the unsubscription threshold is met, an automated alert may be generated, focusing on unsubscription requests (rather than their completion) with the goal of blocking unwanted unsubscriptions before they can be completed.

[0043] Where a processor is described, it may include two or more component processors. The computer-readable memory may be divided into multiple component memories of the same or different types. Steps in the flowcharts and other figures may be performed in a different order, steps may be omitted, or additional steps may be included, without departing from the invention.

[0044] The detailed description has been presented largely in terms of methods or processes, symbolic representations of operations, functions, and characteristics of the invention. These method descriptions and representations are the means used by those skilled in the art to most effectively convey the substance of their work to others skilled in the art. A software-implemented method or process is herein generally conceived to be a self-consistent sequence of steps leading to a desired result. These steps involve physical manipulations of physical quantities. Often, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. The boundary between hardware, software, and firmware is not always clear, and it will be understood by those skilled in the art that a software-implemented process may be embodied in hardware, firmware, or software in the form of coded instructions, such as microcode and / or stored programming instructions. Generally, unless otherwise indicated, singular elements may refer to plural and vice versa, without loss of generality.

Claims

1. 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 said electronic device, configured to effectuate calls to said management server at predetermined intervals or after predetermined events; a database containing at least the registration status and identity of said at least one electronic device; Including, when the management server receives a request from the electronic service to deregister the at least one electronic device, the management server accesses the database and changes the state of the device to a disabled state, and a predetermined cool-off period is established; Once the device state is changed to disabled, the following steps are performed: a. the call agent of the device continuing to call the server according to the predetermined interval or after the predetermined event; b. after receiving a call from the device, the management server accesses the database and checks whether the state of the device has changed from disabled; c. if the status is no longer invalid, the device is re-registered with the electronic service and the process ends, and if the status remains invalid, the server determines whether the predetermined cool-off period has expired; d. if the cool-off period has expired, the server instructs the call agent to uninstall, the process ends and steps a to d are repeated if the cool-off period has not expired; An electronic device management system.

2. The electronic device management system of claim 1 , wherein the cool-off period is set automatically after the state is changed to disabled.

3. The electronic device management system of claim 1 , wherein after the state is changed, a partial deletion of an agent associated with the electronic service is performed.

4. 1. A method for managing a plurality of electronic devices configured to be registered or deregistered with an electronic service, comprising: a. a management server receiving a request from the electronic service to deregister at least one device of the plurality of electronic devices; b. said management server accessing a database containing at least the registration status and identities of said plurality of electronic devices; c. changing the state of at least one of the plurality of electronic devices to a disabled state; d. setting a predetermined cool-off period in said database; e. the device continues to call the server; f. said management server receiving said call and checking said database to identify the registration status of said at least one device of a plurality of devices; g. if the status is no longer invalid, re-registering the at least one device of the plurality of devices with the electronic service, and the process ends; h if the state remains invalid, determining whether the predetermined cool-off period has expired; i. when the cool-off period expires, the server instructs the at least one device of the plurality of devices to uninstall an agent associated with the electronic service, and the process ends; j. if the cool-off period has not expired, repeating steps e through j; A method comprising:

Images