Remote management of a user device

The present invention relates to remote management of user devices, such as smart phones, utilizing novel control techniques within the user device.

In certain circumstances, the ability to remotely control some user device functions is beneficial to businesses. For example, an enterprise may wish to restrict software applications that can be accessed by a user device, or remotely apply settings, such as security settings, for one or more software applications or the entire device. An example of a situation in which an enterprise would like remote control of user devices is when employees use smartphones or other communication devices exclusively or partially for work purposes. In such instances, businesses may wish to apply minimal security settings to the device and have the ability to remotely wipe work-related data from the device if the smartphone is reported lost or stolen. be.

For certain smartphone operating systems, software tools are available that allow businesses to remotely manage mobile phones loaded with the operating system. Such tools are provided by device and/or operating system manufacturers as part of their mobile device management (MDM) framework. To take advantage of this feature, a special software application called DMA (device management application) is installed on the smartphone. DMA has enhanced privileges compared to other software applications (apps) running on smartphones. A DMA enforces enterprise-defined device policies that limit or otherwise alter the capabilities of user devices. DMA cannot be changed or deleted by the user of the device.

Existing tools for enterprise management of user devices are primarily configured to ensure that the device meets the security requirements imposed by the enterprise, independent of actions taken by the user of the device.

According to a first aspect of the invention, a user device is provided that includes a transceiver, a processor and a memory. The memory is a device management application (DMA) configured to control the functions of the user device according to the effective device policy states of the user device and a device policy schedule including a queue of device policy states; , each device policy state includes a respective set of policy data, and a device policy schedule. In response to receiving the first synchronization data from the remote system via the transceiver indicating the first device policy state in the queue of device policy states, the DMA places the effective device policy state of the user device in the indicated first device policy state. Configured to update to 1 device policy state.

According to a second aspect of the invention, there is provided a computer program product comprising machine-readable instructions. The machine-readable instructions, when executed by a processor of the user device, are stored in the user device to queue a device policy state in response to receiving first synchronization data from a remote system via a transceiver of the user device. selecting a first device policy state from a device policy schedule comprising: each device policy state containing a respective set of policy data; and valid device policy states for the user device in a queue of device policy states. to a first device policy state; and controlling user device functionality according to the updated effective device policy state.

According to a third aspect of the invention, a method is provided for remotely managing a user device. The method includes setting up a user device using DMA configured to control user device functionality according to the user device's effective device policy state, and using a device policy schedule that includes a queue of device policy states. and setting up the user device, each device policy state containing a respective set of policy data; and from the remote system to the user device to the first device policy state in the queue of device policy states. sending first synchronization data indicating an update of the effective device policy state of the user device of the device.

Further features and advantages of the invention will become apparent from the following description of embodiments of the invention, given by way of example only, made with reference to the accompanying drawings.

<figref num="1">1 is a schematic block diagram illustrating an example system for remotely managing a smartphone; FIG.</figref><figref num="2">2 is a schematic block diagram showing additional details of components of the system of FIG. 1; FIG.</figref><figref num="3">4 shows an example of a device policy schedule data structure for a smart phone.</figref><figref num="4">4 is a flowchart representing a method for synchronizing data between a backend system and a smart phone;</figref><figref num="5">Figure 10 is a flow chart representing a method for initiating an end device policy state on a smart phone;</figref><figref num="6">FIG. 4 is a sequence diagram representing a method for registering a smart phone with a server, according to one embodiment of the present invention;</figref>

FIG. 1 shows an example system 100 including a smartphone 102, a web console 104, a backend system 106, and a mobile device management (MDM) system 108. FIG. A smartphone is a mobile phone that, in addition to being configured for conventional voice communication, has processing circuitry that can run downloaded software applications, commonly referred to as apps. In other examples, the methods described herein may instead be applied with respect to desktop computers, laptop computers, or tablet computers, for example.

In the example of FIG. 1, smart phone 102 includes the following software components.

OS (operating system) 110 One or more apps 112 App management component 114 DMA (device management application) 116

DMA 116 is a custom software component configured to perform the method according to the invention. DMA 116 enforces device policies on user devices on behalf of remote parties other than the user of the device. Device policies can be used to restrict or otherwise modify user device functionality. A device user cannot change or delete the DMA 116 .

OS 110 may be, for example, a version of the Android® OS, in which case DMA 116 may be implemented as a custom DPC (device policy controller) or system app. System apps are apps installed under the read-only system/app folder on Android® devices. Device users cannot uninstall apps installed under the system/app folder. Alternatively, OS 110 may be a version of iOS® or Tizen®, or any other suitable OS. DMA may be integrated within the Samsung Knox® Workspace for Samsung® devices running on versions of the Tizen® operating system or versions of the Android® operating system. It will be appreciated that the methods described herein can be implemented in a device.

During the registration process, which is described in more detail below, DMA 116 is appointed as the owner of smartphone 102's managed device profile. A profile owner is an application that is installed within a managed profile and has exclusive control over the policies enforced on that profile. In this example, smartphone 102 is a fully managed device, which means that the only device profile for smartphone 102 is the managed device profile owned by DMA 116 (in other words, DMA 116 is appointed as the device owner of smart phone 102).

DMA 116 is configured to communicate with backend system 106 via backend application programming interface (API) 120 and with MDM system 108 via MDM API 122 .

In the example of FIG. 1, smart phone 102 is for lease to a user by a leasing company under an associated payment agreement. The leasing company would like to have a means to prompt the user of the smart phone 102 to pay late fees, for example, by remotely limiting or otherwise controlling the functionality of the smart phone 102 . Accordingly, the leasing company's billing platform (not shown) communicates with the backend system 106 to notify the backend system 106 of various events related to the smartphone 102, for example, if a payment is overdue. and the back-end system 106 communicates with the DMA 116 to control smartphone functions accordingly.

The DMA 116 can access a device policy schedule 118 stored on the smartphone 102, which includes a queue of device policy states, each device policy state having an associated respective set of policy data. In this example, each device policy state in the queue of device policy states is more restrictive than the previous device policy state in the queue. Specifically, the device policy states in the queue cumulatively disable smartphone 102 functionality as the device policy schedule progresses. For example, a first device policy state may specify that a first category of apps 112 (eg, social apps) is disabled. The second device policy state may further specify that a second category of apps 112 is also disabled (eg, entertainment apps). The third device policy state is voice call, SMS (short messaging service), and emergency apps to disable all functionality of the smartphone 102, so that the functionality of the smartphone 102 is reduced to that of a so-called feature phone. A final device policy state (referred to as a terminal device policy state) may provide for disabling all functionality of smartphone 102, except for the ability to make emergency calls. In another example, a device policy state can provide for disabling a predetermined number of apps 112 based on usage data (eg, the most used apps 112 can be disabled). . In other examples, device policy states may be configured such that features are not cumulatively disabled. For example, a first device policy state may disable only a first category of apps and a second device policy state may disable only a second, different category of apps. In some examples, the device policy schedule does not specify a device policy state, but instead specifies actions to be performed by the DMA 116, such as presenting a notification to the user of the smart phone 102 via the user interface. May include procedures. Such notifications may be used, for example, to notify a user that a bill is overdue.

As will be described in more detail below, the backend system 106 can remotely activate the device policy schedule 118 on the smartphone 102 by sending a signal to the DMA 116 via the backend API 120 so that the smartphone 102 through the queued device policy states in the device policy schedule 118 . For example, the device policy schedule 118 can be activated in response to bills that are not paid on time or are overdue for a predetermined period of time.

As with other apps, the user can open DMA 116 by selecting the icon representing DMA 116 . Upon opening by the user, the DMA 116 presents a user interface through which the smartphone 102 user can view information regarding the device policy schedule 118 . In particular, the user interface informs the user of smartphone 102 of the current status of the smartphone within the device policy schedule and whether or not to perform a prescribed action by a prescribed time, such as paying a leasing company for smartphone 102. Present the consequences of not paying what you should. DMA 116 may be further configured to notify the user when device policy schedule 118 is activated and/or when the effective device policy state is updated. The notification can inform the user which features of the smartphone 102 will be disabled or changed upon the next update of the effective device policy state and when this is scheduled to occur.

The DMA 116 can utilize framework APIs inside the operating system 110 that other apps 112 cannot access. These framework APIs allow the DMA 116 to restrict or modify the functionality of the smart phone 102 according to the set of device policies in effect. As described in more detail below, during registration of smartphone 102 with backend system 106, the factory reset feature is disabled by DMA 116 so that the user of smartphone 102 either directly or e.g. It is impossible to remove the DMA 116 from the smart phone 102 by performing a factory reset of the 102.

In the example of FIG. 1, backend system 106 is operated by a third party service provider. Third-party service providers provide enterprise management of user devices according to the present invention on behalf of multiple enterprises, including smartphone 102 leasing companies. In other examples, enterprise management may be performed directly by an enterprise rather than a third party service provider. In such examples, the backend system is operated directly by the enterprise.

Web console 104 is a website operated by a third party service provider. An enterprise administrator (hereinafter referred to as an enterprise administrator) can log into the web console 104 to perform actions related to enterprise management of user devices associated with the enterprise, such as transferring new user devices to the enterprise. It is possible to register or update the policy settings of a registered user device. In other words, web console 104 provides an interface between the enterprise and backend systems 106 . In this example, the web console 104 uses AWS (Amazon Web Service) (registered trademark) S3 (Simple Storage Service) bucket, but it will be appreciated that in other examples alternative services may be used for this purpose. Web console 104 communicates with backend system 106 via backend API 120 . Backend system 106 stores data associated with multiple user devices, including smartphone 102 . In this example, user devices are grouped by enterprise such that an enterprise administrator for a particular enterprise can manage groups of user devices associated with that enterprise. In another example, an enterprise can be divided into several groups, allowing greater flexibility for large enterprises that may wish to define different device policy schedules for different groups of users. In accordance with the present invention, backend system 106 stores backend device policy schedules for user devices, including backend device policy schedule 124 for smartphone 102 . Device policy schedules 118 stored by smartphone 102 may be synchronized with backend device policy schedules 124 .

In this example, the MDM system 108 is operated by the OS 110 provider, but in other examples, the MDM system is operated by the device manufacturer or by a third party, such as the third party that operates the backend system 106. may be In some examples, the MDM system may include the functionality of the backend system 106, or vice versa. The MDM system 108 manages the apps 112 installed on the smart phone 102 using the app management component 114 installed on the smart phone 102 on behalf of the enterprise administrator. The MDM system 108 receives information from the backend system 106 regarding preferences defined at the enterprise level by the enterprise administrator of the web console 104 . For example, a company administrator may request that a given app be installed on smartphone 102, prevented from being installed on smartphone 102, or prevented from being removed from smartphone 102. Well, and may define a managed configuration for one or more apps 112 installed on smartphone 102 . An app's managed configuration specifies permissions for various features of the app, and related features are specified by the app's developer within a managed configurations schema. Depending on the managed configuration, permission may be ``granted'', ``denied'', or ``user-determined''. decide) can be set. For example, an app's managed configuration stipulates that permission to exchange data over mobile networks is denied, but permission to exchange data over Wi-Fi is granted. be able to. A managed configuration can provide that a user can decide whether an app is authorized to use the smartphone's 102 on-board camera. The managed configuration can also define further restrictions, such as blacklisting or whitelisting certain URLs (universal resource locators) for access by web browsers and other apps.

As described in more detail below, during the registration process, DMA 116 is associated with an account on MDM system 108, which DMA 116 delegates to app management component 114 to perform managed configurations. enable In other examples, the DMA may directly enforce enterprise-defined managed configurations of apps, as well as device policies.

FIG. 2 shows components of the backend API 120 and smart phone 102 configured in accordance with the present invention. In this example, the backend API uses sync adapter 126 , push notifications 128 and SMS messages 130 to communicate with DMA 116 installed on smartphone 102 . In this example, the push notification 128 is sent using the FCM (Firebase Cloud Messaging) service and the SMS message 130 is sent using the AWS SMS service, but in other examples, the push Notifications and/or SMS messages may be sent using alternative services or sent directly from the backend system. Sync adapters 126 include device data sync adapters and application data sync adapters, which are configured to synchronize device policy data and app management data, respectively.

DMA 116 includes broadcast receiver module 132 , which is configured to receive broadcasts related to specific events occurring within smartphone 102 . Broadcasts are messages generated by OS 110 or apps 112 when certain events occur within smartphone 102 . In this example, broadcast receiver module 132 sends push notifications to smartphone 102 when an app is installed or uninstalled from smartphone 102, when smartphone 102 is activated, when an SMS message is received by smartphone 102, and when an SMS message is received by smartphone 102. and if the OS 110 generates an alarm based on the built-in clock 134 of the smart phone 102, it is set to receive the broadcast.

As noted above, DMA 116 also includes a user interface 136 that allows a user of smart phone 102 to interact with DMA 116 in the same manner as app 112 . In this example, the user interface 136 includes active device policy states, allows the user to view information related to the device policy schedule 118, and information related to queued device policy states. User interface 136 does not allow the user to change the device policy state enforced by DMA 116 . This is because enterprise administrators can only change these via the web console 104 .

DMA 116 includes a service module 138 for enforcing device policy according to the effective device policy state. Service module 138 calls functions in DMA support library 140 to enable service module 138 to communicate device policy to OS 110 via device policy manager API 142 . DMA support library 140 also includes functionality for registration of smart phone 102, which in this example includes delegation of managed configuration of apps 112 to app management component 114, as described above.

In this example, device policy schedule 118 is stored in policy database 144, which is a virtual object database configured with an object-relational mapping (ORM). The policy database 144 also stores a set of default permissions 146 that the DMA 116 enforces during registration of the smartphone 102 with the backend system 106 (ie, upon installation of the DMA 116). Default permissions 146 are necessary to ensure that smartphone 102 users cannot circumvent the restrictions imposed by DMA 116 . In this example, default permissions 146 for USB debugging and factory reset of smart phone 102, and for changing the time on internal clock 134 are all set to "deny." The default license 146 is valid as long as the DMA 116 is installed on the smartphone 102 and corresponds to the period the smartphone 102 is managed by the leasing company.

FIG. 3 shows the structure of device policy schedule 118 . Device policy schedule 118 includes multiple device policy states 302, each of which has associated policy data including a Policy Name and a set of permissions. In the example of FIG. 3, two device policy states 302 are defined named "Block 1" and "Feature Phone". The permission associated with Block 1 provides for disabling all apps 112 in the "Social" category. The permissions associated with Feature Phone stipulate that all features of smartphone 102 are disabled except for voice calls, short messaging service (SMS), and emergency apps. Because the Feature Phone device policy state disables apps 112 in the Social category as well as other apps 112 and other features of the smartphone 102 (including, for example, use of the smartphone's 102 built-in camera), the Feature Phone device policy state is , which is more restrictive than the Block 1 device policy state.

Device policy schedule 118 includes scheduling data 304 . Scheduling data 304 includes a "Start Time" data field, which takes as argument a timestamp that provides a reference time from which subsequent "Offset" times are measured. The Offset time then defines the time at which DMA 116 takes action, as described below. The Start Time data field argument may initially be set to zero or NULL, indicating that no device policy schedule has been started and that the only action the DMA 116 will take is to enforce the default grant 146. is interpreted to mean

Scheduling data 304 includes a "Max Sync Age" data field. Max Sync Age defines the maximum period of time the DMA 116 will wait for sync data from the backend API 120 before enforcing the end device state. Max Sync Age can be set as, for example, 10 days, 30 days, 60 days, or any other suitable period, depending on the requirements of the leasing company. The terminal device state is selected to be the most restrictive of device policy states 302 and, in this example, is the only device policy state that DMA 116 enforces without receiving data from backend API 120 . In this way, a user of smartphone 102 cannot continue to use the offline functionality of smartphone 102 indefinitely, for example, by taking smartphone 102 to a location where a communication link with backend API 120 cannot be established. In this example, Feature The phone device policy state is the end device policy state. Scheduling data 304 further includes a list of steps each having a step ID. This example includes two steps with step IDs 1 and 2 respectively.

Device policy schedule 118 includes step data 306 that includes information about steps defined in scheduling data 304 . For each step defined in the scheduling data, step data 306 includes step ID, Action, and Offset. Action refers to the action the DMA 116 will take if the step is performed. In this example, the Action for each step is one Policy for device policy state 302 Corresponds to Name. To perform one of these steps, DMA 116 changes the effective device policy state of smart phone 102 to device policy state 302 with the defined name. In other examples, a step may define Actions that do not correspond to device policy states. For example, the step is that the DMA 116 notifies the user of the smart phone 102 that the bill is overdue and/or that if the bill is not paid by a certain date, the DMA 116 will enforce a restrictive action. You may define an Action to do so. The Offset for each step defines the interval from the Start Time at which DMA 116 will perform that step.

Device policy state 302, scheduling data 304, and step data 306 define a queue of device policy states, each device policy state having a respective set of policy data associated with it. It will be appreciated that the configuration of device policy schedule 118 is exemplary and equivalent information may be configured differently without departing from the scope of the present invention.

FIG. 4 shows an example method 400 by which the device policy schedule 118 on the smartphone 102 is updated by the backend system 106. As shown in FIG. Periodically, the device data sync adapter determines that it is time to synchronize device policy data between the backend system 106 and the smartphone 102 at S401. The synchronization period may be, for example, 1 hour, 12 hours, 24 hours, or any other suitable period. At the sync time, if a data connection is available between the smartphone 102 and the backend API 120 (e.g., via a cellular or Wi-Fi connection on the smartphone 102), the device data sync adapter , S 404 , perform a data synchronization that updates the device policy schedule 118 stored in the policy database 146 to match the backend device policy schedule 124 . In this way, any changes made to the backend device policy schedule 124 by the corporate administrator of the web console 104 will automatically be made in the locally stored device policy schedule 118 at the next scheduled synchronization time. is updated to Additionally, if a start time was entered into the backend device policy schedule 124 (e.g., because a message was received from the leasing company's billing platform indicating that the bill was overdue for smartphone 102), this Start Time would be will be copied to policy schedule 118. When the Start Time is defined in the backend device policy schedule 124, the backend system 106 It automatically progresses through the device policy state queue according to the Time and each Offset defined in the backend device policy schedule 124 . Each time a step whose Action corresponds to a device policy state is reached, the backend device policy schedule 124 is updated to indicate the effective device policy state change. Upon synchronizing this data to smartphone 102, DMA 116 enforces the permissions defined within the indicated valid device policy state.

To perform data synchronization at S404, the device data synchronization adapter causes DMA 116 and backend system 106 to generate checksums from device policy schedule 118 and backend device policy schedule 124, respectively. A checksum is a small sized piece of data derived from a block of digital data and has the property that a slight change to the block of digital data will result in a completely different checksum, thus making two blocks of data Comparing the checksums of is an efficient way to check if two blocks are identical. The checksums generated by DMA 116 and backend system 106 are compared by backend system 106, for example. If the checksums match, device policy schedule 118 and backend device policy schedule 124 are identical and no further synchronization is required. If the checksums do not match, backend system 106 sends a copy of device policy schedule 124 to smartphone 102 to replace device policy schedule 118 locally stored on smartphone 102 . When device policy schedule 118 is updated, DMA 116 determines whether updated device policy schedule 118 indicates an effective device policy state that is different from the current effective device policy state of smartphone 102, and if so, If so, it changes the effective device policy state of smart phone 102 accordingly. It will be appreciated that the use of sync adapters described above is exemplary and that other methods of synchronizing data between the server and the user device may be used without departing from the scope of the present invention.

If there is no data connection available between the smartphone 102 and the backend API 120, or if data synchronization otherwise fails, the backend system 106, at S406, activates the valid device policy state has changed since the last successful synchronization. If it is determined that the effective device policy state has not changed, the backend system 106 will not take further action until the next scheduled synchronization time. On the other hand, if it is determined that the effective device policy state has changed, the backend system 106 generates and sends a push notification to the smart phone 102 at S408. Push notifications are sent as JSON (JavaScript (registered trademark) Object Notation) format and is encrypted so that it can only be decrypted by smartphone 102 using the private key provided to smartphone 102 during registration of smartphone 102 with backend system 106 . Push notification defines one of the device policy states of backend device policy schedule 124 .

Broadcast receiver module 132 of DMA 116 receives a broadcast from OS 110 indicating that a push notification has been received. DMA 116 determines that the push notification is intended for processing by DMA 116 and decrypts the push notification using the private key provided during registration. The DMA 116 reads the JSON data stored within the push notification and attempts to send an acknowledgment message to the backend system (eg, via one of the sync adapters 126) indicating that the push notification was received by the DMA 116. . If the device policy state defined in the push notification corresponds to one of the device policy states 302 stored by the smartphone 102, the acknowledgment message indicates that the DMA 116 recognizes the defined device policy state and sends the smartphone 102 accordingly. indicates that you want to change the effective device policy for DMA 116 changes the effective device policy state of smart phone 102 to the device policy state specified in the push notification. If the backend system 106 receives an acknowledgment message from the DMA 116 within the predetermined time period, the backend system 106 will not take further action until the next scheduled synchronization time.

If the backend system 106 does not receive an acknowledgment message from the DMA 116 within a predetermined amount of time, the backend system 106, at S410, sends an SMS message containing the same encrypted JSON data sent in the push notification at S408. is generated and transmitted to the smartphone 102. Broadcast receiver module 132 of DMA 116 receives a broadcast from OS 110 indicating that an SMS message has been received. DMA 116 determines that the SMS message is intended for processing by DMA 116, decodes the SMS message, and reads the JSON data stored within the push notification. If the DMA 116 does not receive a corresponding push notification and the DMA 116 recognizes the device policy state specified in the SMS message, the DMA 116 sets the effective device policy state of the smart phone 102 to the device policy state specified in the SMS message. change to

The method 400 of FIG. 4 includes three alternative methods of sending sync data to the smart phone 102. The method 400 of FIG. The initial synchronization attempt using the sync adapter 126 allows the effective device policy state of the smart phone 102 to be updated periodically in an efficient manner, while allowing the corporate administrator of the web console 104 to schedule the device policy. Allows 118 flexible updates. However, full data synchronization requires a trusted connection established between the backend API 120 and smartphone 102 . In certain circumstances, such connections may not be available. One such example is when smart phone 102 has a cellular data coverage area. coverage) is used in countries or regions with insufficient coverage. Method 400 thus provides two alternative methods for updating the valid device profile state of a smart phone when full data synchronization is not possible. Note that sending the entire backend device policy schedule 124 to the smartphone 102 may not be feasible if full data synchronization is not possible. In accordance with the present invention, smart phone 102 locally stores device policy schedule 118, which is a copy of backend device policy schedule 124 at the time of the last successful data synchronization. Therefore, if a reliable data connection between the backend API 120 and the smartphone 102 is not available, the active device profile can be changed remotely with only a small amount of data needing to be transferred.

In this example, changes to the effective device state of smart phone 102 are not locally initiated by smart phone 102, but forwarded from backend system 106, as described above with reference to FIG. 4, for example. Data driven. In this way, for example, if a bill is actually paid but a data connection with smartphone 102 is not available, the effective device policy of smartphone 102 cannot be accidentally changed. However, smartphone 102 users are expected to attempt to circumvent the system by avoiding synchronization with the backend system 106 . A simple way to do this is to avoid any form of data connection (e.g., by keeping smartphone 102 away from any cellular or Wi-Fi signals, or by keeping smartphone 102 in airplane mode). ), and more sophisticated methods are also envisioned. To prevent such attempts from succeeding, the device policy schedule 118 stored on the smartphone 102 includes a terminal device policy state, and the DMA 116 defaults to a default if data synchronization is not successful after a predetermined amount of time. be it. Note that as an alternative embodiment, all changes to effective device policy state may be initiated locally by the user device.

FIG. 5 illustrates an exemplary method 500 for DMA 116 to implement end device policy states. DMA 116 attempts to perform data synchronization using the device data sync adapter of sync adapter 126 at S502. If data synchronization is successful, DMA 116 resets alarms in OS 110 according to the max sync age defined in device policy schedule 118 at S504. Specifically, an alarm is set to activate when the time measured using internal clock 134 exceeds the time at which data synchronization was performed by max sync age. The default permission 146 ensures that the smartphone 102 user cannot change the time measured by the internal clock 134, which allows the user to otherwise prevent the OS alarm from activating. Please note.

The device data sync adapter periodically attempts to perform data sync as described above with reference to FIG. If the sync adapter's repeated attempts to perform data synchronization have failed, the broadcast module 134 of the DMA 116 receives an alarm signal from the OS 110 at S506 at the time specified in S504. In response to receiving the alarm signal 110, the DMA 116 retrieves the terminal device policy state defined by the device policy schedule 118 from the policy database 144 at S508. The DMA 116 then changes the effective device policy state of the smart phone 102 to the retrieved end device policy state at S510. It will be appreciated that other methods of activating end device policy states may be used as an alternative to method 500 of FIG. For example, in some embodiments, the DMA checks between each data synchronization attempt whether the time measured by the internal clock 134 exceeds the time of the most recent successful data synchronization by more than max sync age. You may

As described above, during registration of smartphone 102 with backend system 106, DMA 116 is appointed as the owner of smartphone 102's managed profile. FIG. 6 shows an exemplary method 600 by which smartphone 102 is registered with backend system 106 . Before the method 600 is executed, the enterprise is onboarded with the backend system 106 and the MDM system 108. with), resulting in the creation of respective enterprise resources in backend system 106 and MDM system 108 . An enterprise administrator of the web console 104 can manage apps that are automatically added to user devices that are enrolled with the enterprise and managed configurations for those apps and/or other apps that users can install. You can define preferences such as options and These preferences are communicated to the MDM system 108 so that the MDM system 108 can perform app management for user devices registered as corporate devices. The backend system generates a registration token for registering the user device with the enterprise at S602. In this example, the registration token includes a key-value pair that defines information unique to the enterprise and essential for registration of the device, including, for example, the download location for the DMA 116 .

The smartphone 102 receives the registration token at S604. The smartphone 102 can receive the registration token by any suitable means, for example by scanning a 2D barcode (such as a QR (Quick Response) code) or by NFC (Near Field Communication). . Smartphone 102 communicates data from the registration token to MDM system 108, which initiates the process of creating a managed profile for smartphone 102 at S606. In this example, creating the managed profile includes creating an account with the app management system for the managed profile. DMA 116 (which is an instance of DMA provided by the operator of backend system 106) is appointed as the owner of the managed profile at S608.

The backend system 106 and MDM system 108 add managed profiles to the respective enterprise resources above at S610. In some examples, the backend system 106 can also add managed profiles to groups within enterprise resources.

MDM system 108 installs app 112 , DMA 116 and DMA support library 140 on smartphone 102 . DMA support library 140 ensures that DMA 116 updates app management component 114 on smartphone 102 to meet the minimum version requirements necessary for app management component 114 to perform app management, as described above. Contains enabling functionality (ie, helper and utility classes). The DMA 116 updates the app management component 114 accordingly at S614, and once the app management component 114 is updated, the DMA 116 delegates app management to the app management component 114 at S616.

The above embodiments should be understood as illustrative examples of the invention. Further embodiments of the invention are envisioned. For example, in some embodiments, the DMA is configured to enforce managed configuration of apps as well as device policies without delegating app management to an app management component as described above. In such embodiments, the device policy schedule may further include managed configuration states for apps, providing additional flexibility for an enterprise to manage devices in accordance with the present invention.

In a further example, the DMA is configured to monitor app usage on the user device, for example, by configuring a broadcast receiver module to receive broadcasts when the app is opened on the user device. may be The DMA can use this information, for example to determine the most used apps for a particular period of time, DMA stipulates disabling one or more of the most used apps. Allow device policy states to be enforced. Additionally, the DMA may send data to the backend system indicating how often and when different categories of apps are used. By collecting such data from a large number of devices (e.g., within a single enterprise or across multiple enterprises), the backend system can develop more effective device policy schedules to incentivize users. can be set. Alternatively, or in addition, the backend system processes data associated with a large number of user devices, for example using reinforcement learning or other machine learning techniques, to determine whether a particular device policy schedule or a particular device policy state is claimed. It can be determined how effective it was in terms of prompting the user to pay the bill.

In a further example, a user device can have multiple profiles (e.g., a work profile and a personal profile) such that the functionality of the user device with respect to that profile is controlled only by the respective DMA, and one Each DMA above may be the owner of one or more profiles.

As already mentioned, the present invention is applicable to desktop computers, laptop computers, and tablet computers, as well as smart phones. More broadly, the present invention applies to any user device having a transceiver, a processor, and a memory storing a device management application configured to control the functionality of the user device according to the user device's effective device policy state. has application to Thus, in addition to smartphones, the present invention can be applied to Internet-of-Things (IOT)-enabled consumer devices such as, for example, televisions, central heating controllers, washing machines, refrigerators, and the like. In the IOT-enabled TV example, different policy states in the policy schedule block specific TV services or classes of TV services. In the example of an IOT-enabled washing machine, policy states with different policy schedules may block features such as the ability to operate the washing machine over the Internet.

From the above description, it will be appreciated that the techniques of the present invention are applicable to leasing businesses in which user devices are leased to consumers or businesses and the leasing company maintains some degree of control over the leased user devices. be. The technique of the present invention is useful, for example, when a company provides user devices to its employees, but requires that the user devices be connected to the Internet periodically for security reasons, or when the user devices are connected to the Internet during office hours. is further applicable when requiring the user to disable all social media apps.

As noted above, the device policy schedule defines a queue of policy states, each policy state defining rules for user device behavior. These rules may include disabling software applications or classes of software applications. These rules may include disabling hardware features such as cameras or GPS location devices. These rules may allow finer control, such as disabling the ability of certain software applications to access certain hardware functions.

With respect to FIG. 5, as described above, a timer function can be used to switch the user device to a terminal state if the user device fails to perform device policy schedule synchronization for a predetermined period of time. Monitoring the time since last synchronization and, as that time increases, updating some or all of the policy states of the device policy schedule from the most recent synchronization of the device policy schedule until the terminal policy state is finally reached. This functionality can be extended by advancing at each elapsed time interval.

Any feature described in relation to any one embodiment may be used alone or in combination with any other feature described, and may be combined with one or more features of any other embodiment, or It should be understood that it may be used in combination with any combination of any of the other embodiments. Moreover, equivalents and modifications not described above may be used without departing from the scope of the invention as defined in the appended claims.