Intelligent mobile device management client

Intelligent Mobile Device Management Client {INTELLIGENT MOBILE DEVICE MANAGEMENT CLIENT}

<b><u>Cross-referencing of related applications</u></b>

This application claims priority on the basis of U.S. Patent Application Serial No. 12/188,936, entitled Managing and Enforcing Policies on Mobile Devices, filed on August 8, 2008, which U.S. patent application is a transferred to the assignee.

<b><u>technical field</u></b>

Embodiments of a communication device are described, and more particularly, to an intelligent mobile client device usable in a wide area network.

The basic functionality of a typical mobile phone has undergone a radical shift from being voice-only to being able to support complex features and rich data-intensive applications. It is expected that this trend of increased complexity and functionality of mobile devices will continue, resulting in significant increases in product and service innovation. In many respects, mobile device management is very similar to traditional enterprise management. Mobile device management includes providing the ability to set up new devices or services, firmware and software lifecycle management for mobile subscribers, delivery, organization, and retrieval of new or updated programs and data, and phone functions. remote diagnostic routines, software and network connectivity, asset management, reporting, and other functions. To ensure ease of use, a combination of intelligent management, proactive monitoring, and diagnostic routines is essential for wireless/mobile operators.

Current system, network, and enterprise management solutions typically include two key items, a PDU (protocol data unit) (which describes the content exchanged between the managed object and its administrator), and the location and location of the managed object. It is based on a data model that uniquely describes In mobile devices, a widely used standard is the Open Mobile Alliance's Device Management (OMA DM) standard. Typically, a carrier may carry one or more instances of an MDM (Mobile Device Management) platform to manage the associated mobile devices. The OMA DM protocol leverages the popular browser-client web-server interaction model and HTTP delivery method. The interaction between the management platform and the device may be initiated by a server (management platform) or a client (mobile device). The interaction initiated by the client follows the familiar paradigm of a web browser initiating a session with a web server. When the server wants to initiate an interaction, the server must start by notifying the client so that the client can once again start a session with the server, such as a browser. This server-to-client notification is specifically carried out by means of an SMS (Short Message Service) communication channel text message recognized by the mobile device and routed to the OMA DM client software, whereby the client can establish a session with the server. Once the SMS-based notification is received, a client-to-server session is established and proceeds in the same manner as the interaction initiated by the client.

In an MDM system, remote devices may be controlled in a number of different ways. The two fundamental aspects of control are usage control and function control. Usage control relates to control over applications and services available on, running on, or accessible by a device. Examples of usage control include service operator-specific usage of certain applications that allow only paid applications to be available on designated devices, such that a parent subscriber (called a master subscriber) can have their children attend school. can ensure that they are not using a music player or gaming application on their cell phone while they Similar application control is possible. Functional control relates to the operation of the device itself and the operation of various hardware components of the device (eg, power supply, input/output, transceiver circuitry). Examples of functional controls include limiting device power consumption when the battery is near depletion, increasing radio sensitivity when disturbance is detected, increasing speaker volume in noisy environments, and other Similar functional properties are included.

Today, mobile devices are controlled almost exclusively by the user. That is, the user must manually set or modify functional settings (eg, bell mode, speaker volume, keypad configuration, etc.). Regarding usage control, although service providers can generally enable or disable certain functions on a remote device, such control is usually limited to simple on/off settings. Current devices do not support usage control based on dynamic or functional characteristics of the device. As a result, these controls require user preferences. Accordingly, a relatively high level of user input is required to enforce a usage policy or rule, or to set specific functional characteristics. As such, current mobile devices are passive devices that cannot perform significant autonomous operation, but instead require active monitoring and configuration by service providers and users.

In certain cases, a user may retrieve, parse, and set attribute values for a mobile client using standard management protocols. Management attribute values may be stored in a known structure (eg, a device management tree). Although such server-driven management presents a mandatory channel, this means that the server is the component primarily responsible for management decisions for mobile clients. Thus, this existing management paradigm can be considered reactive rather than proactive, as management and monitoring are performed after a problem is reported by a consumer.

Accordingly, there is a need for a mobile device policy distribution and enforcement system that enables autonomous control and operation of mobile devices.

There is a further need for a mobile device resident management framework that facilitates management of a mobile device based on functional usage conditions sensed in the mobile device.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Embodiments of the present invention will be described with reference to the accompanying drawings, in which like reference numerals indicate like elements. 1 illustrates a computer network system implementing one or more embodiments of a mobile policy management system for intelligent mobile clients. Figure 2 illustrates the components of an action rule set that may be used in an intelligent mobile client, in one embodiment. 3 illustrates a general architectural arrangement for a client-side policy management process, in one embodiment. 4A shows an action rule registration step in an embodiment. Fig. 4B shows the action rule evaluation step in one embodiment. Figure 5 is a schematic illustration of UML for the components that form the client-side architecture of an intelligent mobile client, in one embodiment; 6 illustrates an MDM server that may be used in a remote client device that is a managed object, in one embodiment. 7 illustrates a system for mobile device management between an MDM platform and an OMA DM-implemented mobile device, in one embodiment. 8 illustrates example OMA DM management for a mobile client device, in one embodiment. 9 is a block diagram illustrating a system that may provide alarm notifications and alarm retrieval to an intelligent agent, in one embodiment.

The embodiments of the invention described herein provide a solution to the problems of the prior art methods described above. In the following description, various examples are given, but these examples are not intended to be limiting. An embodiment of an intelligent mobile client usable in a massively distributed network is described. The intelligent mobile client may be an OMA DM-enabled mobile client device. and a module by which the intelligent agent of the client can store management attribute values in one or more nodes of the OMA DM management tree of the mobile client device. Some or all of the management values are analyzed and set at a server computer connected to the mobile client device via a wireless network. The intelligent mobile client is configured to manage itself based on initial commands and policies provided by the server, communicated to the client by the OMA DM protocol. For example, a client may perceive that the battery is nearly depleted, and thus the client automatically reduces its backlight light level.

One or more computers executing software instructions may be implemented in aspects of one or more embodiments described herein. Computers may be networked in a client-server arrangement or similarly distributed computer network. 1 illustrates a computer network system 100 implementing one or more embodiments of a mobile policy management system. In system 100 , network server computer 104 is directly connected to one or more network client computers 102 and 118 , via network 110 , and via one or more other networks, such as cellular phone network 111 . /connected indirectly. A network interface between the server computer and the client computer may include one or more routers, the routers function to buffer and route data transmitted between the server and the client computer. Network 110 may be the Internet, a wide area network (WAN), a local area network (LAN), or any combination thereof.

In one embodiment, the server 104 in the network system 100 is the server executing the server-side mobile device policy enforcement process 112 . The process may represent one or more executable program modules stored within the network server 104 and executed locally within the server. Alternatively, however, such program modules may be stored in a remote storage or processing device coupled to the server 104 or network 110 and accessed by the server 104 to be executed locally. In a further alternative embodiment, the policy management process 112 may be implemented in a plurality of different program modules, each of which is connected to one another or two or more distributed server computers individually connected to the network 110 . can be executed by The server and client computers may use dedicated application programs and API (application program interface) communication schemes.

In one embodiment, the client device 102 may execute a client-side policy management system to interact with the server-side policy management process 112 and enable autonomous control of the device. Some or all of the management values are analyzed and stored in a server computer connected to the mobile client device via a wireless network. The intelligent mobile client 102 is configured to manage itself based on initial commands and policies provided by the server, delivered to the client using a designated network protocol optimized for remote device management. A separate content provider 103 may provide some of the data included in the policy management process. Data for any of the policies, business rules, etc. may be provided by the data store 120 close to or loosely coupled to any of the server 104 and/or the client 102 .

A client device is typically a mobile client device that provides various utilities (eg, communication, entertainment, navigation, information management, and basic computing functions). The mobile client 102 may be a cell phone, smartphone, or any mobile communication device that provides access to the network 110 and has a sufficient degree of user input and processing power to execute the client-side policy enforcement process 105 . can The client computer 102 may also be implemented in a standard mobile computing device 118, such as a notebook computer, personal digital assistant (PDA), game console, media playback device, or similar computing device. The client computers 102 and 118 may be connected to the server computer 104 via a wired connection, a wireless connection, or any combination thereof. For example, if the mobile client 102 is a cell phone, the connection between the mobile device and the network 110 will utilize a separate cell network 111 maintained by the communication provider. In an embodiment where the network 110 is the Internet, the network server 104 may execute a World-Wide Web (WWW) server process 116 , the server process storing data in the form of web pages, and It sends these pages to clients 102 and 118 as Hypertext Markup Language (HTML) files via 110 . In this embodiment, a client (eg, client 118 ) runs a web browser program 114 to access web pages served by server computer 104 and any available content providers or supplemental servers 103 . can be accessed

As shown in FIG. 1 , a server computer 104 executes a server-side policy management process 112 . The process 112, together with the client-side process 105, includes a policy management framework, which allows management authorities (eg, carriers and IT managers) to control access, resource and policies that determine aspects such as application usage, functional characteristics, monitoring, and logging. The server-side process 112 provides functionality to create, edit, and present policies for devices, followed by management and monitoring of these policies. The client-side process 105 can then implement these policies and rules to autonomously control its own functional and usage functionality. In this way, the server 104 and/or any system administrator entities, and the user of the mobile device 102 , have only minimal interest in the operation of the device in relation to the specified policies and implementations relating thereto.

In general, policy management refers to the functionality of a management authority defining the behavior of a mobile device so that the mobile device complies with a device usage policy of a specific network or enterprise, and operates according to specified functional constraints or principles. For example, an IT manager may stipulate that a mobile device user cannot use an Internet browser during office hours. Using the server-side policy management functionality, you can define a policy that stipulates that the phone's browser cannot be started during office hours (eg, between 8am-5pm, Monday through Friday). The server sends the policy to the mobile client, or makes the policy available to the client. Then, the client-side policy management process 105 installs and enforces the policy. This enforcement means that the policy framework automatically prevents the browser from starting when the user tries to start the browser at a time that is not allowed. In one embodiment, the policy management framework targets enterprise devices, such as smartphones, that provide functionality to access the Internet, email, and enterprise databases and in many cases store confidential data. With action rule management, IT executives can be confident that these devices adhere to company policies.

The policy framework provides an intelligent autonomous system through which the mobile device can self-manage according to the actions formed by the server, using flexible policies. This approach ensures efficient management without requiring extensive mobile device user input and utilization of resources such as network bandwidth, server power, memory, processor overhead, and other resources.

<b><u>client side</u></b><b><u> process</u></b>

As described above, the policy management framework consists of a server-side component and a client-side component. The server-side process provides the functionality to create, edit, and present action rule sets. The client-side process provides the functionality to activate, deactivate, list, and enforce a set of action rules for a client device.

In one embodiment, the client-side process 105 enforces policies expressed as action rules. Action rule enforcement requires the functionality to dispatch an event, evaluate a condition, and trigger an action when a group of conditions evaluates to true. Moreover, the client-side architecture must be able to monitor action rule compliance, and thus detect and report violations.

An action rule set is a collection of four types of components that enforce a specific action. The components are a trigger, a condition group, a condition, and an action. Figure 2 illustrates the four components of an action rule set in one embodiment. As shown in FIG. 2 , the trigger 202 is an event indicating a change in the state of some variables related to the action rule 204 . A trigger may be related to a policy rule determined by the system and/or a functional characteristic of the device. Some trigger examples include a battery level reaching a certain charge percentage, a device entering a certain location, or a time of day varying by a set time, among others. When the trigger 202 notifies the action rule set 204 , the action rule evaluates its predicate (condition) 206 . Several different conditions 208 may be organized into one or more condition groups 206 . If the condition is true, the action rule 204 causes the associated action 201 to be executed.

In one embodiment, each condition 208 includes a Boolean expression expressed as either true ('1') or false (null or '0'). An example of a condition is battery level &lt;10%. An action rule may have any practical number 0-n conditions, and these conditions may be grouped together by condition group 206 . In general, action 210 is an action to be executed when an action rule predicate evaluates to true. As an example of an action, there may be a local device command "switchOffCamera". Thus, for example, if the trigger is a battery charge level and the condition batteryLevel&lt;10% is true, then the resulting action would be to turn off the camera component of the mobile device.

The client-side process 105 includes functional components capable of activating, deactivating, listing, and enforcing a set of action rules for a client device. These components evaluate conditions and trigger an action when one or more conditions are true. As shown in FIG. 1 , a client-side policy management process 105 includes an event resource 142 and a processing module for a policy manager component 144 . The client-side process provides functionality to enable, disable, and enforce policies for mobile client devices. Policy enforcement generally requires the ability to dispatch an event, evaluate conditions, and trigger an action when a group of conditions evaluates to a true state. Moreover, the client-side process is responsible for monitoring policy compliance and detecting and reporting policy violations. Figure 3 is a schematic illustration of the general overall architecture for a client-side policy management process, in one embodiment; As shown in Figure 3, a policy in which the client-side process includes the following components: event resources (eg, 302 and 304), predicate evaluators, action handlers, trigger managers, and compliance monitors. It consists of a manager component (306).

An event resource is a component responsible for trigger generation. Any number of event resources (eg, event resources 302 and 304 ) may be provided. The event resource encapsulates a specific state and sends a notification to a specific listener whenever a preset specific condition is met. For example, a timer event resource generates an event every "x" seconds (where "x" is configurable). The policy manager 306 coordinates all policy-related client activities, including policy activation, deactivation, and enforcement. The policy manager leverages three components that can accomplish its mission: a predicate evaluator, a trigger manager, and an action handler. The predicate evaluator is responsible for evaluating the conditions of a particular policy. To evaluate conditions, the predicate evaluator relies on a condition handler. All condition handlers know how to evaluate certain types of logical expressions (eg &gt;, &lt;, and =). Action handlers provide functionality to coordinate the execution of action instances. Action handlers provide different semantics (eg, best effort or strictly everything). The trigger manager maintains a table that maps triggers (triggered by event resources) to policies. When the trigger manager receives a trigger notification, the trigger manager can use a table to determine affected policies. Then, for each affected policy, it sends a request to the policy manager to evaluate the policy. The policy manager leverages the predicate evaluator to evaluate the predicate of the policy, and if the predicate is true, the trigger manager can interact with the action handler to execute the action. A compliance monitor identifies and reports policy violations. Any number of condition handlers, event resources, and actions from 1 to n may be accepted by the client-side process 300 , depending on implementation settings.

In one embodiment, a set sequence of actions is required in the actions involved in action rule registration and action rule evaluation. The action rule registration is responsible for implementing the action rule locally in the mobile device. Figure 4a illustrates the action rule registration step in one embodiment. The process is started in the server device management process 402 which creates a new management object (MO) using the action rule information, and then calls the executable command for the action rule manager "Activate" operation. . The action rule process receives an execution command. The action rule manager 404 registers the action rule action nodes (activation, deactivation, and removal) at startup time, and thus receives a callback including the URI of the action rule. Then, the action rule manager 404 of the trigger manager 406<i>RegisterTrigger</i> Invoke the process The process parses the trigger's information from the MO, extracts the ID of each trigger, and finally calls the appropriate trigger 408 to register it.

When the trigger fires, the action rule manager is notified, and the action rule evaluation process is performed. 4B illustrates an action rule evaluation process in one embodiment. When the conditions set at the trigger registration time are satisfied, the event resource sends a notification to the trigger manager 406 . The trigger manager retrieves the action rule URI from the event, and in the action rule manager 404<i>EvaluateActionRule</i> Invoke the process The action rule manager evaluates the predicate of the action rule in the condition evaluator 408 , and if the predicate is true, the action rule manager executes the actions of the action rule through the action manager 410 .

A client-side process may be expressed by a Unified Modeling Language (UML), which includes a set of graphical representation techniques capable of generating an abstract model of a client system. Figure 5 is a UML schematic diagram of the components forming a client-side architecture in one embodiment. In the UML model 500 of FIG. 5, the event resource manager 502 maintains a list of all event resources registered in the system, and provides functionality for managing these event resources. The state of the event resource list is<i>EventSourceList</i>am:

<i>EventSourceList</i>: List including all registered event resources. The methods of the event resource list are as follows:

<i>addEventSource</i><i>(</i><i>EventSource</i><i></i><i>es</i><i>, </i><i>String</i><i></i><i>id</i><i>)</i>: New event resource registration. The above method receives an event resource and a string including an ID to be assigned to the event resource.

<i>removeEventSource</i><i>(</i><i>String</i><i></i><i>id</i><i>)</i>: Delete the event resource identified by "id".

<i>getEventSource</i>: Returns the event resource identified by "id".

<i>listEventSources</i>: Returns a list containing the ids of all event resources registered in the system.

The event resource 504 implements the trigger functionality. The event resource sends a notification to a listener whenever a set of conditions are satisfied. The above conditions are different for every event resource. Event resources are built as dynamically loadable modules, and thus can be added to the system at runtime and deployed using means such as a software component management object (SCoMO). Every event resource has a unique ID. Upon registration with the event resource manager, the event resource ID is stored in a table handled by the event resource manager and made available to the rest of the system.

The state of the event listener list 506 is <i>EventListenerList</i>am.

<i>EventListenerList</i>: A list containing all registered event listeners. The method of the event listener is as follows:

<i>addEventListener(</i><i>EventListener</i><i></i><i>el</i><i>, </i><i>String</i><i></i><i>id</i><i>, </i><i>Tuplecontainer</i><i> regPar)</i>: Registering a new event listener. The above method receives an event listener, a string containing an ID to be assigned to the event listener, and a tuple container that stores all parameters required to configure the action of the trigger. The tuple container stores parameters such as &lt;name, value&gt; objects.

<i>removeEventListener</i><i>(</i><i>String</i><i></i><i>id</i><i>)</i>: Delete the event listener identified by "id".

<i>getEventListener</i><i>(</i><i>String</i><i></i><i>id</i><i>)</i>: Returns the event listener identified by "id".

<i>listEventListener</i><i>()</i>: Returns a list containing the ids of all event listeners registered in the system.

An event listener is an object that receives notifications from an event resource. The event resource calls the notification (TupleContainer event) method when the subscription condition is met. The input parameter is a tuple container with name and value pairs that describe the event. There are two force parameters (EventID and EventName) that identify the type of event.

The policy manager 508 is a central component of the client-side infrastructure 500 . The policy manager leverages four components that can implement its functionality: trigger manager 516 , action manager 512 , predicate evaluator 514 , and compliance monitor 510 .<i>The</i><i></i><i>policyInstantiated</i><i>(</i><i>URI</i><i></i><i>uri</i>) method is called by the management tree callback means. The parameter is the URI to the newly instantiated policy.<i>evaluatePolicy</i><i>(</i><i>URI</i><i></i><i>uri</i><i>)</i> The method evaluates the policy conditions directed by the URI. This process means evaluating a predicate and invoking the associated action if the predicate is true.<i>register</i><i>(</i><i>String</i><i></i><i>URI</i><i>)</i> The method receives the path to the policy trigger, parses the tree information, and registers the appropriate event resource.

The trigger manager 516 is responsible for associating a trigger with a policy and, upon receiving a trigger, is responsible for retrieving an affected policy. The trigger manager is an event listener and thus receives notifications from the event resource. The trigger manager state<i>TriggerToURIMappings</i>am. This is a table that associates triggers with URIs in policies. Upon receiving the trigger event, the trigger manager may check the table to determine what the evaluated policy is.<i>notify</i>(<i>TupleContainer </i><i>event</i>) method is called by the event resource. The input parameter contains information about the event. When the trigger manager receives an event, the trigger manager extracts the event ID and uses it<i>TriggerToURIMappings</i> Index the table. As a result, a list of policies related to the event (trigger) is obtained. The trigger manager repeats this for the policies that are "exported" by the policy manager.<i>evaluatePolicy</i>Invokes a " method, which evaluates a policy predicate (predicate evaluator) and executes a policy action if the predicate is true (action manager). <i>addMapping(String </i><i>evId</i><i>, </i><i>String</i><i></i><i>uri</i><i>)</i> The method saves the new mappings in the TriggerToURIMappings table. <i>removeMapping(</i><i>String</i><i></i><i>evld</i><i>, </i><i>String</i><i> uri)</i> If the method removes a mapping from the TriggerToURIMappings table and the second parameter (URI) is null, the method removes all mappings related to the provided event. If the second parameter is not null, the method deletes only a specific binding.

The predicate evaluator 514 is responsible for evaluating the condition of the predicate of the policy instance. The above component delegates the actual evaluation to the appropriate condition handler according to the condition ID.<i>evaluate</i><i>(</i><i>String</i><i></i><i>URI</i><i>)</i> The method evaluates the conditions of the policy provided as a parameter. The parameter determines the location of the root node of the policy condition in the management tree. The method iterates over the subtree, extracts a condition ID for each condition, and uses the ID to index the table in which the condition handler is registered. Finally, the method calls the condition handler using the parameters extracted from the subtree.

The condition handler 520 is a component that can evaluate certain condition classes (eg, &gt;, &lt;, and string comparisons). These condition handlers are registered with the predicate evaluator using a unique ID. Condition handlers can be dynamically registered with the system.<i>evaluate(Condition </i><i>condition</i><i>)</i> The method receives the condition instance, evaluates it, and returns a boolean value.

The action manager 512 is responsible for executing the action of the policy instance. The above component delegates the actual execution to the appropriate handler based on a specific action ID.<i>execute(String </i><i>URI</i><i>)</i> The method executes the actions of the policy provided as a parameter. The parameter determines the location of the root node of the policy action in the management tree. The method iterates over the subtree, extracts the action ID for each condition, and uses the ID to index the table in which the action handler is registered. Finally, the method calls the action handler using the parameters extracted from the subtree.

The action handler 518 is a component capable of executing a specific action class (eg, application start, application stop, camera switching off). These action handlers are registered with the action manager using a unique ID. Action handlers can be dynamically registered with the system.<i>execute</i><i>(</i><i>Action</i><i></i><i>action</i><i>)</i> A method receives an action instance and executes it. If the action execution fails, the action handler returns an exception. The action manager 512 is then responsible for determining whether to execute the remaining actions, stop execution, and/or report a failure.

The compliance monitor 510 is generally responsible for verifying that the mobile device adheres to the policies set by the management server. The compliance monitor detects policy violations and reports them to the appropriate service, such as a server process.

The client-side process 500 is generally configured to accommodate new functionality in a manner that minimizes down time and avoids requiring a re-installation of the system whenever new functionality is available. The entire client-side process can be split into two components: the core infrastructure and the policy building block handler. The core infrastructure provides the basic functionality that enables policy management, while policy handlers are components that can manipulate policy building blocks (ie triggers, conditions, and actions). In general, the core functionality does not depend on the specific details of each policy instance. The core functionality simply coordinates the interactions between different policy building block handlers according to general rules. On the other hand, policy building block handlers (triggers, action handlers, and condition handlers) are tightly coupled to every specific policy instance. As a result, the client process is implemented to be flexible enough to incorporate new policy building block handlers at runtime. Moreover, this flexibility also helps to configure which policy building blocks mobile devices will support during device configuration or during startup time. This capability can help form a subset of devices with different policy management capabilities, for example, depending on device type or hardware characteristics.

The policy management client architecture leverages a dynamically configurable infrastructure to manipulate available policy building block handlers at runtime. In one embodiment, this is accomplished by using dynamically loadable modules to implement triggers, actions, and condition handlers. These modules can be deployed and installed at runtime, resulting in new handlers made available to the system.

An example of an action rule management client process is described as follows for a device that is already made into a commercially available product, and is currently in use in a device with an installed action rule framework infrastructure. An action that the carrier monitors the battery drain rate and decides to send a notification when the drain rate is higher than a certain value, but the device does not have a trigger to monitor the battery drain and the notification can be sent If it does not have a handler, the carrier can deploy two new modules (battery trigger and notification action) using a specific protocol such as SCoMO. The device receives the module and registers it with the action rule system at runtime by detecting the action rule handler. The action rule (policy) framework loads the trigger module and registers it in the event resource manager. After that, the framework loads the action handler and registers it with the action manager. After registration, the IDs of both the trigger and action handler are available and ready to be used, and the action rules for the policy will be enforced.<u></u>can

<b><u>server side</u></b><b><u> process</u></b>

The overall policy management framework that controls the client-side policy management process for the mobile client device is controlled by the server-side process 112 as shown in FIG. 1 . The server-side policy management process 112 includes a separate user interface that enables interaction with the policy creator 112 , the group policy manager process 124 , the device policy manager process 126 , and the system administrator 140 . It contains several functional blocks. The server-side management system 112 is configured to implement a relatively simple and standards-based policy representation, and addresses a wide variety of use case scenarios. These policy representatives may be loaded and stored in the data store 120 of the server 104 . In one embodiment, the server is configured to dynamically upload new policies to mobile devices based on different criteria. In enterprise implementations, one primary criterion is the group of authorities to which the subscriber belongs, and other criteria may include device type, deployment time, and other similar criteria.

The policy creator component 122 may enable the system administrator user 140 to create as a state machine new instances of policies among the necessary components (triggers, conditions, actions), and also the system administrator user ( 140) edit/update an existing policy, delete an existing policy, or import and export a policy instance. In one embodiment, user interface 128 presents a list of existing policies to user 140 as a state machine. In policy creation or editing, the portions of user interface 128 are dynamic because they represent the components. After the user builds the state machine based on triggers, conditions, and actions, the policy may be stored in the data store 120 . The import and delete functions simply change the list of policies available for the user. Upon export, the user can save the policy instance to a file.

The group policy manager tool allows users to manage target groups and related policies. In general, two views are available: a target group view and a policy view. The target group view allows the user to view all target groups, create, edit, delete target groups, and view policies by the selected target group. Actions available in the view include adding a policy to or removing a policy from a selected target group, enabling or disabling a policy, checking that policy compliance is up-to-date, and synchronizing with the device. In this embodiment, the user interface presents a list of existing target groups. In any target group, it is possible to view the relevant policies. This new view contains a list of the relevant policies and the actions mentioned are available. Add Policy will show a list of all available policies, where the user can select one. When checking for compliance to one or more policies, a list is populated with unsynchronized devices and their reasons. Users have the option to synchronize their devices and thus enforce compliance.

The second view of the group policy manager tool is the policy view. The policy view allows the user to view all policies and view target groups by the selected policy. In this case, the user interface will show all available policies, and the user can view the relevant target group for the policy.

In one embodiment, a policy management server-side process is built into an MDM platform, which provides a modular architecture that simplifies the integration of services such as policy management. The MDM platform implements the OMA DM protocol, which enables standard management of remote mobile devices, which is one of the requirements for remote management. 6 illustrates an MDM server 600 that may be utilized in a managed remote client device, in one embodiment. The server-side service includes a policy creator that creates new policies among the necessary components (triggers, conditions, actions). Via the interface, administrator 604 may edit/update existing policies, delete existing policies, or import and export policy instances. The administrator may also import, export, and delete components of an MDM instance.

The policy management component 602 includes a target group policy manager that enables an administrator to manage a target group and policies related thereto. Via the user interface, viewing of target groups and policies is possible. In the target group view, the manager can view all target groups and create, edit, delete target groups; You can view policies by the selected target group. The user can also add policies to or remove policies from the selected target groups (which will not yet send the policies to the device); can enable or disable the policy (will not send the policy to the device yet); Policy compliance (the latest one), and the possibility of synchronizing with the device (install, uninstall, enable, disable, or update via bulk operation) can be checked. In the policy view, an administrator can view all policies, or view target groups by a selected policy.

Policy management component 602 includes a device/subscription policy manager that allows an administrator to manage existing policies for a single client device. Via the user interface, the user can view all policies for the device (possibility to be filtered directly or indirectly); install, update, uninstall, enable, or disable direct policies in a single operation; update, remove, enable, or disable indirect policies; Policy compliance for indirect policies (the latest one), and the possibility of synchronizing with the device can be checked. A workflow for client interaction allows the user to query, install, update, uninstall, enable, and disable policies.

In one embodiment, the server 600 may be configured to store management policies for a number of different client devices. Different clients may be organized by one or more different characteristics (eg, device type, location, user group, service group, time zone, etc.). The above policies can be stored in an organized database accessible to the server. These grouped policies are then distributed to specific targeted client devices, enabling efficient reconfiguration based on relevant characteristics.

<b><u>mobile </u></b><b><u>device</u></b><b><u></u></b><b><u>of management</u></b><b><u></u></b><b><u>implementation</u></b>

In one embodiment, the mobile device policy management framework of FIG. 1 includes one system, wherein the system is configured to manage policies such as a decision policy and an active policy for the device described above, and the device includes a device policy It includes a repository, a decision point, a decision policy enforcer, and an active policy enforcer. The system includes a method for enforcing policies for a mobile device, the method proactively monitoring an execution environment and automatically triggering an active policy. Additionally, the method provides functionality to export interfaces and to evaluate and enforce decision policies. The system can combine policies from different resources, including detecting and avoiding policy contradictions.

In one embodiment, the client-side process 105 of FIG. 1 is implemented as an intelligent management agent residing on a mobile client device 102 . The intelligent management agent relies on communication between a client-side mobile management process 105 residing on a mobile device and a server-side mobile device management (MDM) process 112 residing on a server 104 .

A standard management protocol such as Open Mobile Alliance Device Management (OMA DM) may be used by the server to retrieve, analyze, and set management attribute values for a mobile client. In general, the OMA DM specification is optimized for the management of small mobile devices such as cell phones, PDAs, and palm top computers, but can also be used to manage virtually any type of networked device. This device management function is intended to support the following typical uses, namely, providing configuration settings of the device, activating and deactivating functions (software upgrade, defect management, etc.), and the like.

In one embodiment, a client-side process may be downloaded to a client device using the OMA DM protocol and a Software Component Management Object (SCoMO) standard that specifies a protocol that can remotely manage software on a mobile device. SCoMO generally denotes the installation, uninstallation, start and end of software on a mobile device. The mobile client 102 of FIG. 1 and all other devices supporting OMA DM have a management tree. The management tree contains and organizes all available management objects, allowing the server 104 to directly access all nodes via a unique uniform resource identifier (URI).

As previously mentioned, policies are expressed at the server using the XML structure for the respective action-condition-trigger components. At the mobile client device, each policy is represented as a subtree. This means leverages the subtree structure provided by OMA DM and facilitates implementation on mobile clients. In one embodiment, the server may leverage XML to store the policy, but the client does not. Clients can use the OMA DM management tree structure to store information. The server parses the XML document and automatically creates a subtree with all the information. The server then creates the subtree on the client device remotely.

In one embodiment, a software manager process may be provided to facilitate downloading of a client-side management process to a mobile client device. In one implementation, the user may take control via the software to be downloaded (user pull scenario), and the application may be provided by the second server. The user first accesses the server computer software management portal on the mobile device itself, or accesses the server computer management portal through a separate computer. The portal, from which the application and its properties are selected, communicates with any third-party application or content server. The MDM server initiates a control connection to the mobile client, after which a connection to the content server is authorized and established. In other implementations, an operator or enterprise controls application downloads (operator push scenario). For example, in an enterprise setting, the IT department can delegate application patches or downloads of new anti-virus signature files. Here, the enterprise or operator sets up the download in motion through the MDM console. The MDM server and any third-party content server then establish a connection to the mobile device.

In one embodiment, a configuration manager in the carrier suite of the MDM server manages the configuration (configuration) on the mobile device via the wireless (cellular) network. In the OMA DM application, the configuration is handled by the carrier suite configuring virtually any application on the mobile device and setting the value of an object in the OMA DM management tree for that application. Certain OMA DM applications may be predefined, such as bootstrap routines, diagnostics, and other applications.

<b><u>MDM</u></b><b><u>client managed by</u></b>

Client device 120 is typically a mobile client device running a number of different application programs that provide various functions or utilities such as communications, entertainment, navigation, information management, and basic computing functions. The mobile client 120 provides access to the network, implements policies managed by the MDM server 102, and has a sufficient degree of user input and processing power to execute tasks, cell phones, smartphones, or any It may be a mobile communication device. In some computing environments, client devices may also be implemented in standard mobile computing devices, such as notebook computers, personal digital assistants, game consoles, media playback devices, or similar computing devices. These client computers may be connected to the server computer via a wired connection, a wireless connection, or any combination thereof.

In one embodiment, the mobile device comprises an intelligent management agent in communication with the processing element of the MDM carrier suite server 102 . In one embodiment, a standard management protocol such as Open Mobile Alliance Device Management (OMA DM) may be used by the server to retrieve, analyze, and set management attribute values for a mobile client. .

7 illustrates a system for mobile device management between an MDM platform and an OMA DM-enabled mobile device, in one embodiment. Using the OMA DM protocol, the server 702 may retrieve, analyze, and set management attribute values stored in the management tree 704 of the mobile device 706 . The device management function is intended to support the following typical uses: providing configuration of the device and enabling and disabling of functions such as software upgrades, defect management, and the like. In one embodiment, the configuration manager 104 in the carrier suite of the MDM server 102 manages the configuration (configuration) for the mobile device over the wireless (cellular) network. In the OMA DM application, the carrier suite configures virtually any application on the mobile device, and the configuration for that application is handled by setting values of objects in the OMA DM management tree. Certain OMA DM applications may be predefined, such as bootstrap routines, diagnostic routines, and other applications.

The management tree 704 represents any type of configuration form of the mobile device and includes a plurality of nodes for storing operational parameters related to relevant settings, functions, and the like. 8 depicts an exemplary OMA DM management tree for a mobile client device in one embodiment. The management tree includes a root node 802 and a plurality of sub-nodes below the root node. These subnodes may include a DMAcc node 804 , a vendor node 806 , and an operator node 808 . Each node has an associated URI. For example, "ABC Inc." in the management tree of FIG. 8 To access a node, the correct URI is "./DMAcc/ABCInc". The DMAcc node 804 generally specifies settings for the device management client in the managed device. Any number of functions, applications, or related settings for a client may be specified by subnodes in the management tree. In the example of FIG. 8 , subnodes are shown for ring signal 812 and screen saver 814 settings of the mobile client. These and other settings may be configured through firmware updates provided by the MDM server administrator, carrier service operator, or any other third party provider.

The management tree contains and organizes all available management objects, allowing the server to directly access all nodes through a unique uniform resource identifier (URI). The management tree includes a number of hierarchically organized nodes. An internal node can have an unlimited number of child nodes, and a leaf node must have a value including null. Each node has a set of run-time attributes associated with it. All attributes are valid only for the relevant node. An access control list (ACL) indicates which servers can manipulate a node. Operations include adding child nodes, obtaining properties of a node, replacing or deleting a node, and other runtime properties. The management tree or any subtree for a mobile device may be accessed by an OMA message call from the MDM server platform 802 .

In one embodiment, a mobile device policy management system comprises means for enhancing node management attributes. In general, the structure of management information forms a management node. The method augments a set of standard management attributes that may include the following set: status, refresh interval, state (enabled/disabled state), and logging flags. In addition, management attributes include minor actions, thresholds, and simple rules, and major actions, thresholds, and simple rules. The "status" attribute is equivalent to the perceived node severity (ie nothing, minor, or major). The "refresh" interval defines a period for rule evaluation. The management state allows the system to stop or restart node evaluation. The logging flag controls the logging policy for a specified node. The attribute group is repeated for each supported severity level. The "action" attribute provides an action that is fired when a simple rule is satisfied. "Threshold" provides a threshold as a rule parameter.

In one embodiment, the system defines a mobile agent behavior that requires periodic monitoring of each active monitoring node in the device management tree. These processes include rule evaluation, logging, and corrective action execution. The mobile agent combines the execution of standard OMA messages sent by the MDM with persistent monitoring of the action node.

The mobile agent process may also include the ability to provide an alarm symbol. For example, whenever a simple rule is satisfied, the agent creates an alarm log including the node URI, node value, severity timestamp, and perceived severity. An agent that wants to send an alarm notation to the server can retrieve all alarms using a dedicated management node. 9 is a block diagram illustrating a system capable of providing alarm symbols and alarm searches for intelligent agents, in one embodiment. As shown in FIG. 9 , the intelligent agent 904 includes an alarm management node 906 . The intelligent agent communicates with the MDM platform, provides an alarm symbol to the platform, and retrieves an alarm from the platform at the alarm management node 906 .

In one embodiment, the intelligent agent provides a status aggregation to each subtree within the device management tree. Due to this, the server can obtain the entire device status without requiring individual query nodes.

Environment settings can be stored and distributed using the MDM server of FIG. 6 . In this embodiment, the procedure forms a monitoring configuration based on a set of augmented node attributes. The management server can be used to create, store, and distribute monitoring configurations.

Through the client-side and server-side policy processing module of FIG. 1 , a plurality of different management functions and values can be analyzed and stored in a server computer connected to a plurality of mobile client devices via a wireless network. Through a client-side process, an intelligent mobile client can implement these policies and essentially self-manage based on initial commands and policies provided by the server, communicated to the client by the OMA DM protocol. Any practical number of conditions and Actions may be accepted.

Using this architecture, a comprehensive remote device provisioning system can be implemented, where policy rules are set for a specific subset of deployed devices. Thereafter, customized modules, patches, updates, etc. can be sent to the devices, and each device can implement and execute the appropriate module. Thereby, a universal module is sent to all devices, thereby reducing the effort associated with the current provisioning system in which the user has to run and manage the updates themselves, or the system administrator has to take on the effort of updating and managing each of the client devices individually. can be significantly reduced. The autonomous operation of mobile devices with minimal user and system administrator input is greatly improved by the policy formation and distribution scheme provided by the client-side process in conjunction with the server-side MDM platform.

Embodiments relate to a method for managing a mobile client device over a network, the method comprising: storing a management attribute value in one or more nodes of a management tree of the mobile client device; analyzing and setting some or all of the management values in a server computer connected to the mobile client device via a wireless network; and forming a set of management attributes to include an attribute group consisting of a status attribute indicating a node severity value, a rule, an action attribute indicating an action to be executed when the rule is satisfied, and a threshold indicating a minimum value used as a rule parameter. includes

In this embodiment, the mobile client device comprises an Open Mobile Alliance Device Management (OMA DM)-implemented mobile client device. Each node may consist of one or more action rule sets, each action rule set comprising: a trigger event indicating a state change of a variable of interest with respect to an action attribute; a condition comprising a yes or no value associated with the variable of interest; and an action including an action to be executed by the mobile device when the corresponding condition is true. In this way, the node severity value may be assigned a severity level selected from the group consisting of non minor and critical. The management attribute may further include a logging flag for controlling a refresh interval defining a time period for rule evaluation by the server computer, or a logging policy for a designated node. The method may further include periodically monitoring each of the active nodes in the management tree. Periodic monitoring may include evaluating each of the rules, logging each of the rules, and executing corrective actions in the event of a fault condition.

In one embodiment, an alarm record is generated whenever a rule is satisfied, the alarm record comprising a resource identifier for the node where the rule was satisfied, a severity timestamp, and a severity value. The method may further comprise receiving all alarm records at a dedicated management node of the server computer.

In this method, the management tree may include a plurality of subtrees, and the method further includes collecting a status for each subtree to obtain an overall status of the mobile device.

Embodiments of the present invention also relate to a managed object mobile device, wherein the mobile device includes an intelligent management agent and a transmission module, wherein the intelligent management is configured to: manage the mobile device in one or more nodes of a management tree of the mobile client device A set of management attributes to store attribute values, to include a status attribute indicating a node severity value, an action attribute indicating an action to be executed when the rule is satisfied, and a threshold value indicating a minimum value used as a rule parameter forming, the transmitting module transmits the management tree data to a remote-connected server computer, configured to analyze and set some or all of the management values of the management tree. In this embodiment, the mobile device comprises an Open Mobile Alliance Device Management (OMA DM)-implemented client device, wherein the transfer operation utilizes the OMA DM communication protocol. Each node may consist of one or more action rule sets, each action rule set including a trigger event indicating a state change of a variable of interest for an action attribute, and a yes or no value associated with the variable of interest. conditions including; and an action including an action to be executed by the mobile device when the corresponding condition is true. A node severity value may be assigned a severity level selected from the group consisting of Minor and Critical.

In one embodiment, the management attribute includes: a refresh interval defining a time period for rule evaluation by the server computer; And it further includes a logging flag to control the logging policy for the specified node. The device of an embodiment may further include a monitoring module for periodically monitoring each of the active nodes in the management tree, wherein the periodic monitoring includes evaluating each rule, logging each rule, and an event of a fault condition. and executing a corrective action at The device may be an alarm management node configured to generate an alarm record whenever a rule is satisfied, wherein the alarm record includes a resource identifier, a severity timestamp, and a severity value for the node where the rule was satisfied. In such an embodiment, all alarm records may be received at a dedicated management node on the server computer.

In an embodiment of the device, the management tree includes a plurality of subtrees, and the method further includes collecting a status for each subtree to obtain an overall status of the mobile device.

Embodiments also relate to a system capable of establishing and enforcing policies for Open Mobile Alliance Device Management (OMA DM)-implemented mobile client devices connected to a server computer via a computer network, the system comprising: a server-side process configured to create, modify, and transmit specified policies for ; a data store that stores specified policies based on implementation requirements defined by one or more characteristics of the mobile client device, one or more characteristics of a user of the mobile client device, and one or more scheduling parameters; a sending process for sending policies to a mobile client device according to the implementation requirement; and a client-side process running on the mobile client device and configured to store, as a managed object, designated policies of the OMA DM management tree of the mobile client device, wherein each of the designated policies is expressed as a subnode of the management tree, the The client-side process is further configured to automatically implement specified policies according to the implementation requirement.

In such a system, one or more characteristics of a user are selected from the group consisting of user identity, user privileges, user location, and user age. In the system, one or more characteristics of the mobile client device are selected from the group consisting of a device location, a device access service type, and a device manufacturer and model.

The systems and methods disclosed herein include, operate under, and/or relate to, a processing system. The processing system, as is known in the art, includes any collection of processor-based devices or computing devices, or components of a processing system or device, that work together. For example, the processing system may include one or more of a portable computer, a portable communication device operating in a communication network, and/or a network server. The portable computer may be any and/or combination of a number of devices selected from, but not limited to, personal computers, cellular phones, personal digital assistants (PDAs), portable computing devices, and portable communication devices. A processing system may include components within a larger computer system.

The processing system of one embodiment includes at least one processor and at least one memory device or subsystem. The processing system may also include, or be coupled to, at least one database. The term "processor" as used generally herein refers to any logic processing unit, such as one or more central processing units (CPUs), digital signal processors (DSPs), application specific integrated circuits (ASICs), and the like. The processor and memory may be monolithically integrated on a single chip, distributed among multiple chips or components, and/or provided by some combination of algorithms. The methods disclosed herein may be implemented in any combination in one or more of a software algorithm, program, firmware, hardware, component, circuit.

The components of the systems and methods disclosed herein may be located together or in separate locations. A communication path connects components and includes any medium capable of communicating or transferring files between components. The communication path includes a wireless connection, a wired connection, and a wired/wireless hybrid connection. Communication paths may also be combined into networks, including local area networks (LANs), metropolitan area networks (MANs), wide area networks (WANs), proprietary networks, interoffice or backend networks, and the Internet. or a connection. Moreover, the communication path can include floppy disks, hard disk drives, and CD-ROM disks, as well as removable fixed media such as flash RAM, Universal Serial Bus (USB) wiring, RS-232 wiring, telephone lines, buses, and e-mail messages. include

Throughout the specification, unless the context clearly requires otherwise, terms such as "including" are to be understood in an inclusive and not exclusive or inclusive sense. Words using the singular or plural also include the plural or singular, respectively. When the word "or" is used in reference to a list of two or more items, the word is meant to encompass any of the items, all items in the list, or any combination of items in the list.

The above description of embodiments of the systems and methods disclosed herein should not be construed as limiting the invention to the forms disclosed. Specific examples or embodiments of the systems and methods disclosed herein are described for illustrative purposes, and as will be apparent to those skilled in the art, various equivalent modifications are possible without departing from the scope of the present invention. The disclosure of the systems and methods disclosed herein is not limited to the systems and methods described above, but may be applied to other processing systems and methods as well.

Elements of the various embodiments described above may be combined to provide additional embodiments. These and other modifications may be made to the systems and methods disclosed herein in light of the foregoing detailed description.