WO2009021200A1 - Managing and enforcing policies on mobile devices - Google Patents

Managing and enforcing policies on mobile devices Download PDF

Info

Publication number
WO2009021200A1
WO2009021200A1 PCT/US2008/072667 US2008072667W WO2009021200A1 WO 2009021200 A1 WO2009021200 A1 WO 2009021200A1 US 2008072667 W US2008072667 W US 2008072667W WO 2009021200 A1 WO2009021200 A1 WO 2009021200A1
Authority
WO
WIPO (PCT)
Prior art keywords
policy
policies
client device
mobile
mobile client
Prior art date
Application number
PCT/US2008/072667
Other languages
French (fr)
Inventor
Manuel Roman
Gregory D. Buzzard
Shahid Shoaib
Eugene Krivopaltsev
Michael Diener
Original Assignee
Innopath Software, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Innopath Software, Inc. filed Critical Innopath Software, Inc.
Priority to PCT/US2008/072667 priority Critical patent/WO2009021200A1/en
Priority to EP08782690.5A priority patent/EP2188730A4/en
Priority to US12/188,936 priority patent/US20090049518A1/en
Publication of WO2009021200A1 publication Critical patent/WO2009021200A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/12Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H04L67/125Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • H04L41/0894Policy-based network configuration management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/22Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks comprising specially adapted graphical user interfaces [GUI]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/34Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/50Service provisioning or reconfiguring
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • H04L41/0866Checking the configuration
    • H04L41/0873Checking configuration conflicts between network elements

Definitions

  • Embodiments are described relating to telecommunication devices, and more specifically to managing and enforcing policies on mobile devices.
  • Mobile and remotely managed devices such as cellular phones, television set- top boxes, home internet gateways and so forth are becoming increasingly prevalent and increasingly complex. As the complexity of such devices increases, so does the necessity to enable service providers to assume much of the burden of being able to remotely manage them. Many management activities that control the operational behavior of a remote device require a complex interaction of policies that derive from one or more sources. Such sources may include the service operator (e.g., cell phone company or cable company), the subscriber (customer of the service operator), enterprises or business customers, and other third parties.
  • Remote devices may be controlled in a number of different ways. Two fundamental dimensions of control are usage control and the other is operational control. Usage control pertains to control over application and services available to and executed on or accessed by the device.
  • Examples of usage control include a service operator restricting usage of certain applications so that only applications that have been paid for may be used on a given device, a subscribing parent (referred to as a master subscriber) attempting to ensure that their child does not use the music player or game application on their cell phone while at school, or an enterprise dictating that their employees' cell phones vibrate, rather than ring, when they are in executive meeting rooms, and other similar application controls.
  • Operational control pertains to the operation of the device itself, and the various hardware elements of the device, such as power, input/output, and transceiver circuits
  • Examples of operational control include limiting device power consumption if the battery is running low, increasing radio sensitivity if interference is detected, increasing speaker volume in noisy environments, and other similar operational characteristics.
  • mobile devices are controlled almost exclusively by the user.
  • the user must manually set or modify operational settings, such as ring mode, speaker volume, keypad configuration, and so on.
  • operational settings such as ring mode, speaker volume, keypad configuration, and so on.
  • service providers are generally able to enable or disable certain functions on a remote device, but control is generally limited to simple on/off settings
  • Present devices do not support usage control based on dynamic or operational characteristics of the device. Consequently, such control requires user configuration.
  • a relatively high level of user input is required.
  • present mobile devices are passive devices that are not capable of significant autonomic operation, but instead require active monitoring and configuration by service providers and users.
  • Some systems have been developed with some form of remote policy management for networked devices.
  • One such system manages network elements using a proxy that detects events of interest.
  • Such systems typically work only on network elements and not remote devices or terminals and require a central policy processing point to handle detected events.
  • standard management protocols may be used by a server to retrieve, analyze and set management properties values for a mobile client.
  • the management property values can be stored within known structure, such as a device management tree.
  • server-driven management presents a mandatory channel, it implies that the server is the component primary responsible for taking management decisions for the mobile client.
  • Such existing management paradigms can thus be viewed as reactive rather than proactive because management and monitoring is conducted after a problem is reported by a consumer
  • a mobile device management framework that facilitates proactive management of mobile devices based on operational and use conditions sensed on the mobile device.
  • Figure 1 illustrates a computer network system 100 that implements one or more embodiments of a mobile policy management system.
  • Figure 2 illustrates the components of an action rule set, under an embodiment.
  • Figure 3 illustrates an overall architecture for the client-side action rule management process, under an embodiment.
  • Figure 4 A illustrates the steps of registering an action rule, under an embodiment.
  • Figure 4B illustrates the steps of evaluating an action rule, under an embodiment.
  • Figure 5A is a block diagram of a decision policy example, under an embodiment
  • Figure 5B is a block diagram of an active policy example, under an embodiment.
  • Figure 6 is a block diagram of a client-side system configured to manage and enforce decision policies and active policies, under an embodiment
  • Figure 7 is a block diagram showing an example of policy conflict detection and resolution, under an embodiment.
  • Figure 8 is a flow diagram illustrating a method of enforcing decision policies, under an embodiment
  • Figure 9 is a flow diagram illustrating a method of enforcing active policies, under an embodiment.
  • Figure 10 is a flow diagram of a method for analyzing and resolving policy conflicts, under an embodiment.
  • Figure 11 illustrates a management tree representation for policies within the policy management system, under an embodiment DETAILED DESCRIPTION
  • Embodiments of the invention as described herein provide a solution to the problems of conventional methods as stated above.
  • Embodiments of a system configured to manage policies, including decision policies and active policies, on mobile devices are described.
  • the system includes a device policy repository, a policy decision point, a decision policy enforcer, and an active policy enforcer.
  • the system includes a method for enforcing policies on mobile devices that proactively monitors the execution environment and automatically triggers active policies
  • the method further exports an interface and provides functionality to evaluate and enforce decision policies.
  • the system can combine policies from different sources, including detecting and avoiding policy conflicts.
  • the embodiments described herein provide a method and apparatus for managing a set of machine interpretable policy directions and enabling the enforcement of such policies on a mobile, or similarly remotely managed, device
  • the embodiments described herein include a system for enforcing policies on mobile devices and methods for enforcing policies on mobile devices.
  • FIG. 1 illustrates a computer network system 100 that implements one or more embodiments of a mobile policy management system.
  • a network server computer 104 is coupled, directly or indirectly, to one or more network client computers 102 and 118 through a network 110, and one or more possible other networks, such as cellular telephone network 111.
  • the network interface between server computer 104 and client computer 102 may include one or more routers that serve to buffer and route the data transmitted between the server and client computers
  • Network 110 may be the Internet, a Wide Area Network (WAN), a Local Area Network (LAN), or any combination thereof.
  • WAN Wide Area Network
  • LAN Local Area Network
  • server 104 in network system 100 is a server that executes a server-side mobile device policy enforcement process 112
  • This process may represent one or more executable programs modules that are stored within network server 104 and executed locally within the server. Alternatively, however, it may be stored on a remote storage or processing device coupled to server 104 or network 110 and accessed by server 104 to be locally executed.
  • the policy management process 112 may be implemented in a plurality of different program modules, each of which may be executed by two or more distributed server computers coupled to each other, or to network 110 separately
  • network server 104 executes a World-Wide Web (WWW) server process 116 that stores data in the form of web pages and transmits these pages as Hypertext Markup Language (HTML) files over the Internet 110 to the clients 102 and 118.
  • WWW World-Wide Web
  • HTML Hypertext Markup Language
  • the client or clients may run a web browser program 114 to access the web pages served by server computer 104 and any available content provider or supplemental server 103.
  • the server and client computer may use a dedicated application program and API (application program interface) communication scheme.
  • API application program interface
  • the client device 102 executes a client-side policy management system to interact with the server-side policy management process 112 and to allow autonomous control of the device.
  • a separate content provider 103 may provide some of the data that is included in the policy management process
  • Data for any of the policies, business rules, and the like may be provided by a data store 120 closely or loosely coupled to any of the server 104 and/or client 102.
  • the client device is typically a mobile client device that provides various utilities, such as communication, entertainment, navigation, information management, and basic computing functions.
  • 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 capability to execute the client-side policy enforcement process 105.
  • the client computer 102 may also be embodied in a standard mobile computing device 118 such as a notebook computer, personal digital assistant, game console, media playback unit, or similar computing device.
  • the client computers 102 and 118 may be coupled to the server computer 104 over a wired connection, a wireless connection or any combination thereof. For example, if the mobile client 102 is a cell phone, access between the mobile device and network 110 will likely utilize a separate cell network 111 that is maintained by a telecommunications provider
  • the server computer 104 executes a server-side policy management process 112.
  • This process along with the client-side process 105 comprises a policy management framework that allows management authorities (e.g., carrier and IT administrator) to control the behavior of mobile devices according to policies that determine aspects such as access control, resource and application utilization, operational characteristics, monitoring, and logging.
  • management authorities e.g., carrier and IT administrator
  • the server-side process 112 provides functionality to create, edit, and submit policies to devices and then subsequently to manage and monitor these policies.
  • policy management is the functionality that allows a management authority to define the behavior of a mobile device, so that it conforms to particular network or corporate device usage policy, or operates in accordance with defined operational constraints or principles
  • an IT manager could specify that mobile device users are not allowed to use the Internet browser during working hours
  • they can define a policy that specifies that the phone's browser cannot be launched during work hours (e.g., from 8am to 5pm from Monday to Friday).
  • the server sends the policy to the mobile client, or otherwise makes it available to the client
  • the client-side policy management process 105 then installs the policy and enforces it.
  • the policy management framework targets enterprise devices, such as smartphones that provide functionality to access the Internet, e-mail, and corporate databases, and in many cases store confidential data.
  • Action rule management allows IT administrators to guarantee that these devices adhere to the company policies.
  • This framework provides an intelligent and autonomous system that allows mobile-devices to self-manage according to the behavior defined by the server, using flexible policies. This approach ensures efficient management without requiring extensive mobile device user input, and resource utilization such as network bandwidth, server power, memory, processor overhead, and other resources Client-Side Process
  • the policy management framework consists of the server-side and client-side components
  • the server-side process 112 provides functionality to create, edit, and distribute action rule sets.
  • the client-side process 105 provides functionality to activate, deactivate, list and enforce action rule sets on the client device 102.
  • the client side process 105 enforces policies that are represented as action rules Action rule enforcement requires functionality to deliver events, evaluate conditions, and trigger actions when a group of conditions evaluates to true
  • the client-side architecture must be able to monitor action rule compliance, and therefore, must detect and report violations
  • An action rule set is a collection of four types of components that enforce a specific behavior of the mobile device These components are: the trigger, the condition group, the condition, and the action Figure 2 illustrates the four components of an action rule set, under an embodiment.
  • a trigger 202 is an event that denotes a change in the state of some variable of interest to the action rule 204. Triggers may be related to an operational characteristic of the device and/or a policy rule defined by the system Some trigger examples include the battery level reaching certain percentage of charge, the device entering a specific location, or the time of day changing to set time, among others.
  • the action rule evaluates its predicate (conditions) 206. Several different conditions 208 may be organized into one or more condition groups 206. If a condition is true, the action rule 24 then causes execution of an associated action 210.
  • each condition 208 comprises a Boolean expression, that is an expression that is either true (' 1 ') or false (null or O').
  • An example of a condition is batteryLevel ⁇ 10%
  • Action rules can have any practical number 0-n conditions, and these conditions can be grouped together by condition groups 206.
  • an action 210 is a task that is executed when the action rule predicate evaluates to true.
  • An example of an action may be the local device command "switchOffCamera".
  • the client-side process 105 includes functional components to active, deactivate, list, and enforce action rule sets on the client device. These components evaluate conditions and trigger actions when one or more conditions are true
  • Figure 3 illustrates an overall architecture for the client-side action rule management process, under an embodiment
  • the action rule policy framework of the client-side process 300 consists of components including an action rule manager 302, a predicate evaluator 304, an action manager 306, one or more triggers 312, a trigger manager 310, and a variable manager 308.
  • the action rule manager 302 coordinates all action rule-related client activities, including activation, deactivation, and enforcement. It leverages three components to achieve the task: Predicate Evaluator, Trigger Manager, and Action Manager.
  • OS native operating system
  • the condition handlers may rely on an abstraction layer 307 that provides a platform independent interface.
  • the action manager 306 provides functionality to coordinate the execution of actions, and provides different semantics, such as best effort, or strictly all
  • the action manager forwards the action execution request to action handlers 309, which encapsulate the specific details of each action.
  • Action handlers may interact with native OS 303 services through procedure calls (IPC), or with mobile device management services 318 through local calls. If the action manager 306 requires interaction with the native OS 303, it leverages the abstraction layer 307, which provides a platform independent API.
  • Triggers 312 are the components responsible for generating notifications when certain conditions are met.
  • a trigger encapsulates a specific state and sends a notification whenever certain preconfigured conditions are met. For example, the timer trigger generates an event every "x" seconds (where "x" is configurable). Triggers maintain a list of listeners.
  • the trigger manager 310 forwards incoming trigger notifications to the appropriate action rule sets. For each affected action rule set it sends a request to the action rule manager 302 to evaluate the action rule.
  • the action rule manager 302 leverages the predicate evaluator 304 to evaluate the action rule's predicate and if the predicate is true, the trigger manager 310 interacts with the action handler 309 to execute the actions.
  • System 300 also includes a variable manager 308 that provides an interface to store and retrieve variables that the different action rule sets use.
  • the client-side policy management system is configured to accommodate new functionality as policies and rules are developed and evolved over time. Update mechanisms are employed to minimize down time, and avoiding reinstallation of the system each time a new feature is available.
  • the client-side process is divided into two main elements of a core infrastructure and the action rule building block handlers (i.e., trigger handlers, condition handlers, and action handlers).
  • the core infrastructure provides the basic functionality for action rule management by orchestrating the different components, and the action rule building block handlers are the components capable of controlling trigger, condition, and action handlers.
  • the core functionality is independent on the specific details of each action rule instance. It simply orchestrates the interaction among the different action rule building block handlers according to defined rules.
  • the core is configured to be stable and to not require changes, except for maintenance or upgrades.
  • the action rule building block handlers (triggers, action handlers, and condition handlers) are tightly coupled to every specific action rule instance.
  • upgrade processes incorporate new action rule building block handlers at runtime, to accommodate new types of action rules over time.
  • These components also assist in configuring which action rule building blocks a mobile device will support during device configuration or at start up time. This mechanism helps create subsets of devices with different action rule management capabilities depending, for example, on the device type or hardware characteristics.
  • the action rule management client architecture leverages a dynamically configurable infrastructure that allows manipulating the available action rule building block handlers at runtime.
  • Dynamically loadable modules implement the triggers, actions, and condition handlers. These modules can be deployed and installed at runtime, so that new handlers are made available to the system as they are available.
  • An example of the action rule management client process is described as follows for a device that has already been shipped and is currently in use has the action rule framework infrastructure installed. If the carrier decides to monitor the battery drainage rate and send a notification if this rate is higher than a certain value, but the device does not have a trigger to monitor battery drainage and does not have an action handler to send a notification, the carrier uses a defined protocol (e.g., SCoMO, software component management object) to deploy two new modules: battery trigger and notification action.
  • SCoMO software component management object
  • the device receives the modules, detects that are action rule handlers and therefore registers them with the action rule system at runtime.
  • the action rule framework loads the trigger module and registers it with the event source manager It then loads the action handler and registers it with the action manager. After registration, both the trigger and the action handler IDs are available and ready to use, and the action rule can be enforced.
  • Action rule registration is responsible for enabling an action rule locally in a mobile device
  • Figure 4A illustrates the steps of registering an action rule under an embodiment
  • the process starts with a server device management process 402 creating a new management object (MO) with the action rule information and then invoking an executable command for the action rule manager 404 "Activate" operation.
  • the action rule process receives the execute command.
  • the action rule manager 404 registers at start up time with the action rule operation nodes (activate, deactivate, and remove) and therefore gets a callback with the URI of the action rule.
  • the action rule manager 404 invokes a RegisterTriggers process of Trigger Manager 406. This process parses the triggers' information from the MO, extracts the ID of each trigger, and finally invokes the appropriate trigger 408 to register with it.
  • FIG. 4B illustrates an action rule evaluation process, under an embodiment.
  • the event source sends a notification to the trigger manager 406.
  • the trigger manager retrieves the action rule URI from the event and invokes an EvaluateActionRule process on the action rule manager 404.
  • 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 action rule's actions through action manager 410.
  • the overall policy management framework that controls the client-side policy management process on the mobile client device is controlled by a server side process 112, as shown in Figure 1
  • the server-side policy management process 112 comprises several distinct functional blocks including policy creator 122, a group policy manager process 124, a device policy manager process 126, and a user interface 128 that allows interaction with a system administrator 140.
  • the server-side management system 112 is configured to implement a policy representation that is relatively simple and standards-based, and addresses a wide variety of use case scenarios. These policy representations can be loaded and stored in a data store 120 of server 104
  • the server is configured to upload new policies dynamically to the mobile devices based on different criteria.
  • one primary criterion is the authority group the subscriber belongs to, and other criteria can include device types, deployment locations, deployment times, and other similar criteria.
  • the policy creator component 122 allows the system administrator user 140 to create new instances of policies out of the needed components (triggers, conditions, actions) as a state machine, as well as to edit/update existing policies, delete existing policies, or import and export policy instances.
  • the user interface 128 presents to user 140 a list of existing policies as state machines.
  • parts of the user interface 128 are dynamic as they represent the components
  • the import and delete functions simply change the list of available policies for the user.
  • On export the user can save the policy instance as file.
  • the group policy manager tool 124 allows the user to manage target groups and associated policies.
  • two views available a target group view, and a policy view.
  • the target group view allows the user to view all target groups, create, edit, delete a target group, and view policies by a selected target group.
  • the available tasks in the view include adding or removing a policy to or from selected target group, activate or deactivate a policy, check if policy compliance is up to date, synchronize with the device.
  • the user interface presents a list of existing target groups For any target group it is possible to view the associated policies. This new view contains a list of these policies and the mentioned actions are available.
  • Adding a policy will show a list of all available policies where the user can select one When checking the compliance for one or more policies a list is populated containing devices that are out of sync and why. The user has the option to synchronize to the device and so to enforce the compliance.
  • the second view in the group policy manager tool is the policy view.
  • This view allows the user to view all policies, and view target groups by selected policy
  • the user interface shows all available policies and the user can view the associated target groups for a policy Policy Management
  • the mobile device policy management system comprising both the client-side process 105 and the server-side process 112 is used to manage and enforce policies on the mobile device 102 that fall generally into two types of policies, decision policies and active policies
  • the decision policies are generally used to control access to some resource or capability from or within the mobile client device For example, defining whether the mobile user entitled to use a resident application, such as the camera or music player.
  • the embodiment described herein provides a mechanism that enables requests for policy decisions to be quickly and efficiently handled
  • the decision policies include a component (policy enforcement point) that checks whether or not access to the resource is allowed, based on the user request and the resource associated to the decision policy as well as evaluation of some additional predicates, such as time of day, device location, and so on.
  • the active policies initiate an action on the mobile client device when certain conditions are met For example, switching from "ring” mode to "vibrate” mode to indicate an incoming call when the device moves within certain geographic coordinates, (e g., when the device has moved inside of a concert hall or conference room).
  • the active policy relies on the policy enforcement component, which receives events from different event generators (e.g., context sensors and hardware and software notifications) and triggers actions when the conditions specified in the active policies are met.
  • Figure 5A is a block diagram of a decision policy example, under an embodiment.
  • the decision policy enforcer 502 is invoked when the user 506 attempts to access a policy controlled resource on the mobile client
  • the user has elected to use the resident MP3 player 504.
  • the decision policy enforcer applies applicable policy rules along with any additional relevant predicates and determines whether or not access to the requested resource is allowed. If access is allowed, as shown in Figure 5 A, the decision policy enforcer 502 causes execution of the appropriate command, in this case start J ⁇ 4P3player 508
  • Figure 5B is a block diagram of an active policy example, under an embodiment
  • one or more context sensors 524 in the mobile device provide sensor data to a policy enforcement component 522.
  • Sensors can be any type of sensor within, or coupled to the mobile device that provides relevant data. Examples include clocks, timers, GPS (global positioning system) circuitry, temperature, environmental/weather, radio status, signal strength, power monitoring, and any other similar type of sensor device
  • the sensors may be embodied in hardware circuitry or software processes, or any combination of hardware and software.
  • the policy enforcement component 522 includes a process that receives and interprets the sensor data. For the example of Figure 5B, this component has determined that the location sensor 524 has provided data indicating that the mobile device is inside of a concert hall.
  • the policy enforcement component 522 also includes a process to enforce any applicable policy rule based on the sensor data. In this case, the policy rule based on the location of the device dictates that the device be placed in silent mode
  • FIG. 6 is a block diagram of a client-side system configured to manage and enforce decision policies and active policies, under an embodiment.
  • System 600 includes a decision policy enforcer component 602 that is responsible for enforcing decision policies together with the policy decision point 604.
  • An active policy enforcer component 606 is responsible for enforcing active policies.
  • the decision policy enforcer stores a list of resources 608 to which it controls access These resources are typically application programs, utilities, circuitry, functions, or features that are resident on the mobile device itself, such as phone, input/output (I/O), camera, music player, audio recorder, video recorder, scanner, GPS, data storage and other functions.
  • the policy decision point 604 is responsible for determining whether or not access to a resource 608 should be granted based on the information stored in the policy Policy rules are stored in a device policy repository 610 is a data base that stores both active and decision policies.
  • a policy conflict resolution subsystem 612 is responsible for analyzing policy conflicts through a policy conflict analyzer, and resolving any conflicts by selecting the most appropriate policy or returning an exception through a policy selector.
  • the decision policy enforcer 602 intercepts the request and interacts with the policy decision point 604 to determine whether or not the request is authorized.
  • the policy decision point 604 extracts the associated policy from the device policy repository 610, evaluates it, and returns either "grant" or "deny" to the policy enforcement point 602. If the decision is "deny,” then the policy enforcement point cancels the request. If the decision is "grant", then the policy enforcement point allows the request to proceed
  • the active policy enforcer 606 periodically receives events from different event generators 616 Event generators can include hardware and software status and context events, as well as other similar events. The active policy enforcer 606 matches these events against the conditions (predicates) defined in the active policies database of the device policy repository 610. When the predicate of an active policy evaluates to true, the active policy enforcer executes the action defined in the policy
  • FIG. 7 is a block diagram showing an example of policy conflict detection and resolution, under an embodiment.
  • the policy conflict detection and resolution of an embodiment ensures that the results of combining policies from multiple parties are deterministic and predictable. In a case in which more than one policy applies, the policies can be active, decision, or a combination of both. Furthermore, these policies can belong to the same administration domain or different domains.
  • a policy conflict analyzer 702 receives a number of policies 706 as an input parameter and analyzes whether there is a conflict among them.
  • policy 1 may allow the user to access a particular file, while policy 2 does not.
  • policy 3 does not conflict with either policy 1 or policy 2 and can therefore be applied
  • the policy conflict analyzer 702 forwards policies 1 and 2 to a policy selector component 704, which chooses one of them based on a priority scheme
  • the priority scheme for policies may be defined by the system administrator or other management function and stored in a central database accessible to the policy conflict resolution module 612.
  • a policy priority dictates that policy 1 overrules policy 2, and therefore, the policy selector 704 allows policy 2 to be applied.
  • the device policy repository component 610 stores policies on the mobile device.
  • the device policy repository of an embodiment can store two types of policies on the device, including decision policies and active policies, but is not so limited. Active policies describe a set of actions that must be taken based on an event occurrence (e.g., time of day, smart card insertion, and so on) and/or evaluation of some predicates. For a given resource, decision policies of an embodiment describe what roles (or entities) can perform/access what operations under specified conditions. Decision policies may also describe additional predicates (e g , time of day) which need to be evaluated before a decision is made. Decision policies may be expressed in standard languages such as XACML[X], for example.
  • XACML extensible Access Control Markup Language
  • XML Extensible Markup Language
  • processing model describing how to interpret the policies.
  • XACML makes possible a simple, flexible way to express and enforce access control policies in a variety of operating environments, using a single language.
  • the policy decision point component 604 of an embodiment makes a policy decision as to whether access to a resource 608 is granted or not based on attributes of a request from the decision policy enforcer 602 and the decision policy stored in the device policy repository 610.
  • the decision policy enforcer 602 enforces policies for access control in response to a request from an entity 614 wanting to perform an operation or access a resource. There may be more than one decision policy enforcer on the mobile client device.
  • the decision policy enforcer 602 passes the incoming access requests to the policy decision point 604, which makes an access allowed or access denied decision. If access is allowed, the decision policy enforcer 602 allows access to the requested resource. If access is denied, the decision policy enforcer 602 returns an appropriate status message back to the access requester.
  • FIG. 8 is a flow diagram illustrating a method of enforcing decision policies, under an embodiment.
  • the flow diagram starts with an access requester (principal) 802 requesting access to a resource 812, such as a file
  • the decision policy enforcer 804 intercepts the request, and creates and sends a request to the policy decision point 806.
  • the policy decision point 806 retrieves the resource associated policy or policies from the device policy repository 808, and performs any predicate evaluations (if necessary).
  • the policy decision point 806 then sends a request to the conflict resolution unit 810.
  • the conflict resolution unit 810 analyzes the policies and in case of conflicts, it resolves these conflicts and returns the policy or policies that prevail.
  • the policy decision point 806 gets the result, makes a decision and returns it to the decision policy enforcer 804, which allows or denies the access to the resource 812.
  • the active policy enforcer 606 enforces active policies in response to an event occurrence (e.g., time of day) in addition to evaluating some predicates (e.g., location of the device).
  • the active policy enforcer may be notified of an event occurrence in a multitude of ways including, but not limited to, using an event bus mechanism, or direct notification from the event generators.
  • FIG. 9 is a flow diagram that illustrates a method of enforcing active policies, under an embodiment
  • the active policy enforcer is registered with event generators that notify it about changes in the state of the mobile device context.
  • a Global Positioning System (GPS) service is an example of an event generator.
  • Other examples include timers, clocks, signal strength indicators, battery charge indicators, and the like
  • the number of event generators that the active policy enforcer is registered with depends on the predicates of the active policies. It is possible for the active policy enforcer to respond to both device as well as remote network events. In the case of remote network events, the event disseminator receives and processes remote network events and notifies the active policy enforcer for appropriate action.
  • the flow of active policy enforcement starts with an event generator (disseminator) 902 sending an event to the active policy enforcer 904.
  • the active policy enforcer 904 retrieves from the device policy repository 906 all the policies for which the predicates depend on the specific event
  • the active policy enforcer 904 then sends the policies to the conflict resolution unit 906, which looks for conflicts and selects the prevailing policies. With these results, the active policy enforcer 904 evaluates the predicates, and performs the actions defined in the policies
  • the policy conflict resolution subsystem 612 receives a number of policies and determines whether or not policies that are to be applied are in conflict with one another. For example, when the system detects an event such as "start application X", the system checks the existing active policies to determine whether they affect the current event.
  • an event such as "start application X”
  • the system checks the existing active policies to determine whether they affect the current event.
  • One possible scenario could be two active policies matching the specified event. It could also happen that the policies have been set by two different administrators, and one of them allows the application to run, while the other one does not.
  • the policy conflict analyzer analyzes the two active policies, and determines that they conflict As a result, the Policy Conflict Analyzer 702 of Figure 7 forwards the two or more conflicting policies to the policy selector component 704 that determines which policy prevails
  • the decision algorithm is programmable, and can be based on defined rules, such as policy priorities, device user input, or even decision policies, to name a few.
  • the policy selector 704 it is also possible for the policy selector 704 to ask a network server to make an arbitration decision.
  • Policy conflict detection and resolution is implemented at the mobile device itself, to handle the cases where conflicts are due to dynamic properties, such as time and location For example, during working hours, a policy may allow the use of a game, while another policy may not. Such a conflict only arises at a specific time of day. Server-based conflict detection and resolution might not be sufficient to handle these dynamic cases, because they would only be checked during submission time, and not at the time when the policy must be enforced.
  • FIG 10 is a flow diagram illustrating a process of analyzing and resolving policy conflicts, under an embodiment.
  • the policy conflict analyzer 1004 gets a set of policies from the policy requester 1002 The policy conflict analyzer 1004 then analyzes the policies and checks for conflicts If the policy conflict analyzer detects conflicts, it sends the affected policies to the policy selector 1006, which makes a decision as to the prevailing policy (if any). The decision can be done according to priorities or any other configurable algorithm (which could use a policy to decide). Implementation of Mobile Device Management
  • the mobile device policy management framework of Figure 1 includes a system configured to manage policies, including decision policies and active policies, on mobile devices is described above that includes a device policy repository, a policy decision point, a decision policy enforcer, and an active policy enforcer
  • the system includes a method for enforcing policies on mobile devices that proactively monitors the execution environment and automatically triggers active policies
  • the method further exports an interface and provides functionality to evaluate and enforce decision policies.
  • the system can combine policies from different sources, including detecting and avoiding policy conflicts.
  • the client-side process 105 of Figure 1 incorporates system 600 of Figure 6 and is implemented as an intelligent management agent residing in the mobile client device 102.
  • the intelligent management agent relies on communication between the client-side mobile management process 105 residing on a mobile device and the server-side mobile device management (MDM) process 112 residing in server 104.
  • MDM server-side mobile device management
  • a standard management protocol such as OMA DM (Open Mobile Alliance Device Management) is used by the server retrieve, analyze and set management properties values for the mobile client.
  • OMA DM Open Mobile Alliance Device Management
  • the OMA DM specification is designed for management of small mobile devices such as cell phones, PDAs and palm top computers, and can be used to manage virtually any type of networked device
  • the device management function is intended to support the following typical uses: provisioning including configuration of the device, enabling and disabling features; software upgrades, fault management, and the like.
  • a client-side process is downloaded to the client device using the OMA DM protocol and SCoMO (Software Component Management Object) standard that specifies the protocol to manage software remotely on mobile devices.
  • SCoMO Software Component Management Object
  • SCoMO generally dictates the installation, uninstallation, launching and termination of software on mobile devices.
  • the mobile client 102 of Figure 1, and every other device that supports OMA DM contains a management tree.
  • the management tree contains and organizes all the available management objects so that the server 104 can access every node directly through a unique URI (uniform resource identifier).
  • each policy is represented as a subtree.
  • This mechanism leverages the subtree structure provided by OMA DM and facilitates execution on the mobile client.
  • the server leverages XML to store the policies, but the client does not.
  • the client uses the OMA DM management tree structure to store the 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.
  • a software manager process may be provided to facilitate download of the client-side management process to the mobile client device.
  • the user has control over the software to be downloaded (user pull scenario), and applications may be provided by a third party server.
  • the user first accesses the server computer software management portal, whether on the mobile device itself or through a separate computer
  • the portal where the application and its attributes 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.
  • the operator or enterprise controls the application download (operator push scenario). For example, in an enterprise setting, the IT department may mandate the download of an application patch or new anti-virus signature file. Here, the enterprise or operator sets the download in motion through an MDM console.
  • the MDM server and any third party content server then establish connections to the mobile device.
  • a configuration manager in a ca ⁇ iei suite of the MDM server manages configuration settings on the mobile device over the wireless (cellular) network.
  • the carrier suite configures virtually any application on the mobile device for which configuration is handled by setting the values of objects in the OMA DM management tree.
  • Certain OMA DM applications may be predefined, such as bootstrap routines, diagnostics, and other applications.
  • Figure 11 illustrates a management tree representation for policies within the policy management system, under an embodiment.
  • the management tree comprises a number of hierarchically organized nodes, which are entities that are managed through the OMA DM protocol.
  • An interior node can have an unlimited number of child nodes, while a leaf node must contain a value, including null.
  • Each node has a set of run-time properties associated with it. All properties are only valid for the associated node.
  • An Access Control List (ACL) for a represents which server can manipulate that node. The manipulation includes adding a child node, getting the node's properties, replacing this node, or deleting this node, as well as other run-time properties.
  • ACL Access Control List
  • the management tree contains all relevant information about a policy.
  • a policy group 1102 may have one or more policy instances 1104. Each policy instance has a version number for revision control purposes and may have a common name. Each policy has a number of subnodes that contain various data objects related to the policies A number of these subnodes can have further subnodes, as shown.
  • the main subnodes for use in the policy management system include the policy condition subnode 1106, the policy action subnode 1108 and the policy triggers subnode, 1110. These represent key subtrees within the policy management tree 1100
  • the server 104 takes the XACML file of the management tree, parses it and generates one or more different subtrees.
  • the server-side process 112 takes the entire policy group management tree under the URI for root node 1102 and parses it into at least subnodes for the policy conditions subtree under node 1106, the policy action subtree under node 1108, and the policy trigger subtree under node 1110.
  • This processing of the management tree XACML to manage policies that are autonomously executed on the mobile device represents a unique usage of the OMA DM specification, and advantageously facilitates the creation, management, and dissemination of policies among various mobile devices in a distributed network environment,
  • a system comprises: a server computer executing a server- side policy management process including an interface component configured to allow a system administrator to define and modify action rule sets, and a transmission function to distribute the action rule sets to client devices over one or more networks; and a mobile client device coupled to the server computer over the one or more networks, and executing a client-side policy management process configured to activate, deactivate, and enforce the action rule sets distributed by the server computer to implement at least one of defining one or more operational characteristics of the mobile client device or allowing access to one or more resources on the mobile client device or accessible by the mobile client device over the one or more networks.
  • the action rule sets comprise: trigger events denoting a change in state of a variable of interest to an action rule of the action rule sets; conditions comprising a yes or no value associated with the variable of interest; and actions comprising a task to be executed by the mobile client device when a corresponding condition is true
  • the action rule sets comprise policies defined by the server-side policy management process and enforced by the client-side policy management process,
  • the policies may comprise one or more policies, each defined as a first type of policy or a second type of policy.
  • the first type of policy comprises a decision policy that returns either a true or false value and that enables access to a resource or function resident on the mobile client device or accessible to the mobile client device over the one or more networks
  • the second type of policy comprises an active policy that initiates an action on the mobile client device when a defined condition is satisfied.
  • the resource is selected from the group consisting essentially of: application programs resident on the mobile client device, hardware functionality provided by the mobile client device, and computer files accessible by the mobile client device.
  • the defined condition is determined to be satisfied through one or more sensor elements on the mobile client device, and wherein the defined condition is selected from the group consisting essentially of: time, location, user profile, and environmental conditions.
  • the one or more sensor elements may include a timer circuit, a timer software routine, a location determination circuit, and at least one environmental sensor.
  • the hardware functionality provided by the mobile client device may include a telecommunications interface, a music player, and a camera. In this system the plurality of conditions are grouped together by one or more condition groups.
  • the client-side policy management process is further configured to monitor compliance with an action rule, and to detect and report to the server computer any violations of an action rule.
  • the server computer may comprise an enterprise server, and further wherein the policies comprise enterprise rules implemented to restrict access to corporate resources in accordance with defined business rules.
  • the corporate resources comprise information databases and related files, and the defined business rules restrict access based on identification and access privileges of a user of the mobile client device
  • the policies comprise usage rules implemented to restrict mobile client device operation based on defined conditions.
  • the client device operation comprise access to functions available on the mobile client device and one or more operational settings of the mobile client device, and wherein the defined conditions include time of usage or location of the mobile client device.
  • the server-side policy management process comprises: a policy creator module configured to allow the system administrator to create, edit, and delete policies; a target group policy manager module configured to define and manage target groups consisting of users of mobile devices coupled to the server computer; a device policy manager module configured to install, remove, update, activate, or deactivate policies on the mobile client device; and a user interface providing access to the system administrator to define and manage policies through the server-side policy management process.
  • An embodiment is directed to a system for implementing policy management on a mobile device, comprising: a device policy repository storing one or more policies on the mobile device, the policies comprising at least one of a decision policy that dictates user access to operations or resources of the mobile device under defined conditions, and an active policy describing one or more actions to be taken based on an event occurrence; a decision policy enforcer enforcing policies for access control in response to a request from a requesting entity; a policy decision point configured to decide whether or not access to a resource is granted based on attributes of a request from the decision policy enforcer and a decision policy stored in the device policy repository; and an active policy enforcer enforcing active policies in response to an event occurrence.
  • This system further comprises a policy conflict resolution component comprising: a policy conflict analyzer configured to determine whether one or more policies conflict with one or more other policies; and a policy selector component configured to deteimine which policy of two conflicting policies prevail.
  • the policy selector applies a defined policy priority rule to determine which policy of the two conflicting policies prevail.
  • the mobile device may include one or more sensors monitoring defined operational and environmental characteristics related to operation of the mobile device.
  • the policies consist of one or more action rule sets, each action rule set comprising, trigger events denoting a change in state of a variable of interest to an action rule of the action rule sets; conditions comprising a yes or no value associated with the variable of interest; and actions comprising a task to be executed by the mobile device when a corresponding condition is true.
  • the decision policy returns either a true or false value and that enables access to a resource or function resident on the mobile client device or accessible to the mobile device over one or more networks, and wherein the resource is selected from the group consisting essentially of: application programs resident on the mobile client device, hardware functionality provided by the mobile client device, and computer files accessible by the mobile client device.
  • the active policy initiates an action on the mobile client device when a defined condition is satisfied, and wherein the defined condition is determined to be satisfied through one or more sensor elements on the mobile client device, and wherein the defined condition is selected from the group consisting essentially of: time, location, user profile, and environmental conditions.
  • Embodiments are also directed to a method of defining and enforcing policies on a mobile client device coupled to a server computer over a computer network, comprising: executing a client- side process on an Open Mobile Alliance Device Management (OMA DM) enabled mobile client device and configured to monitor the execution environment of the mobile device and automatically trigger one or more defined active policies upon the occurrence of an event; and executing a server-side process configured to allow creation, modification and transmission of defined active policies to the mobile client device.
  • OMA DM Open Mobile Alliance Device Management
  • the policies consist of one or more action rule sets, each action rule set comprising: trigger events denoting a change in state of a variable of interest to an action rule of the action rule sets; conditions comprising a yes or 1 no value associated with the variable of interest; and actions comprising a task to be executed by the mobile device when a corresponding condition is true
  • the policies are stored on the server in extended markup language (XML) structures for the respective action-condition-trigger components.
  • the mobile client device stores the policies as subnodes in an OMA DM management tree as management objects.
  • Embodiments are further directed to a system to define and enforce policies on an Open Mobile Alliance Device Management (OMA DM) enabled mobile client device coupled to a server computer over a computer network, comprising: a server- side process configured to allow creation, modification and transmission of defined policies to the mobile client device; a client-side process executed on the mobile client device and configured store the defined policies in an OMA DM management tree in the mobile client device as management objects, wherein each policy of the defined policies is represented as a subnode of the management tree.
  • OMA DM Open Mobile Alliance Device Management
  • the management tree comprises a root node defining a policy group that has one or more policy instance subnodes
  • Each policy represents a subtree within the management tree, and wherein each policy subtree has a policy condition subnode, a policy action subnode, and a policy triggers subnode.
  • the client-side process includes a module to monitor the execution environment of the mobile device and automatically trigger one or more defined policies upon the occurrence of an event, and wherein the policies consist of one or more action rule sets, each action rule set comprising: trigger events denoting a change in state of a variable of interest to an action rule of the action rule sets; conditions comprising a yes or no value associated with the variable of interest, and actions comprising a task to be executed by the mobile device when a corresponding condition is true.
  • the data objects related to each of the trigger events, conditions, and actions are specified within a corresponding subnode of the policy subtree.
  • the policies are stored on the mobile device as subtrees within the management tree.
  • the policies are created by the server computer as nodes directly on the mobile device.
  • the mobile client device of this embodiment may comprise a smartphone coupled to server computer over one or more wireless networks.
  • Embodiments include a method of defining and enforcing policies on an Open Mobile Alliance Device Management (OMA DM) enabled mobile client device coupled to a server computer over a computer network, comprising: executing a server- side process that is operable to allow creation, modification and transmission by a system administrator of defined policies to the mobile client device; executing a client- side process on the mobile client device that is operable to store the defined policies in an OMA DM management tree in the mobile client device as management objects, wherein each policy of the defined policies is represented as a subnode of the management tree, and further wherein the management tree comprises a root node defining a policy group that has one or more policy instance subnodes
  • the method further comprises organizing the management tree under a policy group root node including at least one policy instance subnode.
  • the method yet further comprises parsing the management tree a first subtree for policy conditions of the policy instance, a second subtree for policy actions of the policy instance, a third subtree for policy triggers
  • Additional steps of this embodiment include monitoring the execution environment of the mobile device and automatically trigger the policy instance upon the occurrence of an event.
  • the policies consist of one or more action rule sets, each action rule set comprising: trigger events denoting a change in state of a variable of interest to an action rule of the action rule sets; conditions comprising a yes or no value associated with the variable of interest; and actions comprising a task to be executed by the mobile device when a corresponding condition is true.
  • the method further comprises storing data objects related to each of the trigger events, conditions, and actions within a corresponding subnode of the policy instance subtree.
  • the policies are stored on the mobile device as subtrees within the management tree.
  • the method further comprises creating the required nodes directly on the mobile device.
  • the processing system of an embodiment includes at least one processor and at least one memory device or subsystem
  • the processing system can also include or be coupled to at least one database.
  • the term "processor” as generally used herein refers to any logic processing unit, such as one or more central processing units (CPUs), digital signal processors (DSPs), application-specific integrated circuits (ASIC), etc.
  • the processor and memory can be monolithically integrated onto a single chip, distributed among a number of chips or components, and/or provided by some combination of algorithms.
  • the methods described herein can be implemented in one or more of software algorithm(s), programs, firmware, hardware, components, circuitry, in any combination.
  • Communication paths couple the components and include any medium for communicating or transferring files among the components.
  • the communication paths include wireless connections, wired connections, and hybrid wireless/wired connections.
  • the communication paths also include couplings or connections to networks including local area networks (LANs), metropolitan area networks (MANs), wide area networks (WANs), proprietary networks, interoffice or backend networks, and the Internet.
  • LANs local area networks
  • MANs metropolitan area networks
  • WANs wide area networks
  • proprietary networks interoffice or backend networks
  • the Internet and the Internet.
  • the communication paths include removable fixed mediums like floppy disks, hard disk drives, and CD-ROM disks, as well as flash RAM, Universal Serial Bus (USB) connections, RS-232 connections, telephone lines, buses, and electronic mail messages.
  • USB Universal Serial Bus

Abstract

Embodiments of a system configured to manage policies, including decision policies and active policies, on mobile devices is described. The system is configured to manage policies, including decision policies and active policies, on mobile devices is described that includes a device policy repository, a policy decision point, a decision policy enforcer, and an active policy enforcer. The system includes a method for enforcing policies on mobile devices that proactively monitors the execution environment and automatically triggers active policies. The method further exports an interface and provides functionality to evaluate and enforce decision policies The system can combine policies from different sources, including detecting and avoiding policy conflicts.

Description

MANAGING AND ENFORCING POLICIES ON MOBILE DEVICES
CROSS-REFERENCE TO RELATED APPLICATIONS
This application claims priority from U.S. Provisional Patent Application No. 60/964,131, entitled "Managing and Enforcing Policies on Mobile Devices", filed August 08, 2007, which is incorporated by reference in its entirety herein; and from U.S. Provisional Patent Application No. 60/964,180 , entitled "Integrated Mobile Device Management," filed August 08, 2007, which is incorporated by reference in its entirety herein.
The present application is related to U.S. Patent No. 12/188,874, entitled "Defining and Implementing Policies on Managed Object-Enabled Mobile Devices," filed August 8, 2008, and which is assigned to the assignee of the present invention.
TECHNICAL FIELD
Embodiments are described relating to telecommunication devices, and more specifically to managing and enforcing policies on mobile devices.
BACKGROUND
Mobile and remotely managed devices such as cellular phones, television set- top boxes, home internet gateways and so forth are becoming increasingly prevalent and increasingly complex. As the complexity of such devices increases, so does the necessity to enable service providers to assume much of the burden of being able to remotely manage them. Many management activities that control the operational behavior of a remote device require a complex interaction of policies that derive from one or more sources. Such sources may include the service operator (e.g., cell phone company or cable company), the subscriber (customer of the service operator), enterprises or business customers, and other third parties. Remote devices may be controlled in a number of different ways. Two fundamental dimensions of control are usage control and the other is operational control. Usage control pertains to control over application and services available to and executed on or accessed by the device. Examples of usage control include a service operator restricting usage of certain applications so that only applications that have been paid for may be used on a given device, a subscribing parent (referred to as a master subscriber) attempting to ensure that their child does not use the music player or game application on their cell phone while at school, or an enterprise dictating that their employees' cell phones vibrate, rather than ring, when they are in executive meeting rooms, and other similar application controls. Operational control pertains to the operation of the device itself, and the various hardware elements of the device, such as power, input/output, and transceiver circuits Examples of operational control include limiting device power consumption if the battery is running low, increasing radio sensitivity if interference is detected, increasing speaker volume in noisy environments, and other similar operational characteristics.
At present, mobile devices are controlled almost exclusively by the user. The user must manually set or modify operational settings, such as ring mode, speaker volume, keypad configuration, and so on. With regard to usage control, service providers are generally able to enable or disable certain functions on a remote device, but control is generally limited to simple on/off settings Present devices do not support usage control based on dynamic or operational characteristics of the device. Consequently, such control requires user configuration. Thus, in order to enforce usage policies or rules, or set certain operational characteristics, a relatively high level of user input is required. As such, present mobile devices are passive devices that are not capable of significant autonomic operation, but instead require active monitoring and configuration by service providers and users.
Some systems have been developed with some form of remote policy management for networked devices. One such system manages network elements using a proxy that detects events of interest. Such systems typically work only on network elements and not remote devices or terminals and require a central policy processing point to handle detected events.
In certain cases, standard management protocols may be used by a server to retrieve, analyze and set management properties values for a mobile client. The management property values can be stored within known structure, such as a device management tree. Though such server-driven management presents a mandatory channel, it implies that the server is the component primary responsible for taking management decisions for the mobile client. Such existing management paradigms can thus be viewed as reactive rather than proactive because management and monitoring is conducted after a problem is reported by a consumer
What is needed, therefore, is a mobile device policy enforcement system that allows for true autonomous operation of mobile devices.
What is further needed is a mobile device management framework that facilitates proactive management of mobile devices based on operational and use conditions sensed on the mobile device.
BRIEF DESCRIPTION OF THE DRAWINGS
Embodiments of the present invention are illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which:
Figure 1 illustrates a computer network system 100 that implements one or more embodiments of a mobile policy management system.
Figure 2 illustrates the components of an action rule set, under an embodiment.
Figure 3 illustrates an overall architecture for the client-side action rule management process, under an embodiment.
Figure 4 A illustrates the steps of registering an action rule, under an embodiment.
Figure 4B illustrates the steps of evaluating an action rule, under an embodiment.
Figure 5A is a block diagram of a decision policy example, under an embodiment
Figure 5B is a block diagram of an active policy example, under an embodiment.
Figure 6 is a block diagram of a client-side system configured to manage and enforce decision policies and active policies, under an embodiment
Figure 7 is a block diagram showing an example of policy conflict detection and resolution, under an embodiment.
Figure 8 is a flow diagram illustrating a method of enforcing decision policies, under an embodiment
Figure 9 is a flow diagram illustrating a method of enforcing active policies, under an embodiment.
Figure 10 is a flow diagram of a method for analyzing and resolving policy conflicts, under an embodiment.
Figure 11 illustrates a management tree representation for policies within the policy management system, under an embodiment DETAILED DESCRIPTION
Embodiments of the invention as described herein provide a solution to the problems of conventional methods as stated above. Embodiments of a system configured to manage policies, including decision policies and active policies, on mobile devices are described. The system includes a device policy repository, a policy decision point, a decision policy enforcer, and an active policy enforcer. The system includes a method for enforcing policies on mobile devices that proactively monitors the execution environment and automatically triggers active policies The method further exports an interface and provides functionality to evaluate and enforce decision policies. The system can combine policies from different sources, including detecting and avoiding policy conflicts.
In the following description, various examples are given for illustration, but none are intended to be limiting. The embodiments described herein provide a method and apparatus for managing a set of machine interpretable policy directions and enabling the enforcement of such policies on a mobile, or similarly remotely managed, device The embodiments described herein include a system for enforcing policies on mobile devices and methods for enforcing policies on mobile devices.
Aspects of the one or more embodiments described herein may be implemented on one or more computers executing software instructions The computers may be networked in a client-server arrangement or similar distributed computer network. Figure 1 illustrates a computer network system 100 that implements one or more embodiments of a mobile policy management system. In system 100, a network server computer 104 is coupled, directly or indirectly, to one or more network client computers 102 and 118 through a network 110, and one or more possible other networks, such as cellular telephone network 111. The network interface between server computer 104 and client computer 102 may include one or more routers that serve to buffer and route the data transmitted between the server and client computers Network 110 may be the Internet, a Wide Area Network (WAN), a Local Area Network (LAN), or any combination thereof.
In one embodiment, server 104 in network system 100 is a server that executes a server-side mobile device policy enforcement process 112 This process may represent one or more executable programs modules that are stored within network server 104 and executed locally within the server. Alternatively, however, it may be stored on a remote storage or processing device coupled to server 104 or network 110 and accessed by server 104 to be locally executed. In a further alternative embodiment, the policy management process 112 may be implemented in a plurality of different program modules, each of which may be executed by two or more distributed server computers coupled to each other, or to network 110 separately
For an embodiment in which network 110 is the Internet, network server 104 executes a World-Wide Web (WWW) server process 116 that stores data in the form of web pages and transmits these pages as Hypertext Markup Language (HTML) files over the Internet 110 to the clients 102 and 118. For this embodiment, the client or clients may run a web browser program 114 to access the web pages served by server computer 104 and any available content provider or supplemental server 103.
Alternatively, the server and client computer may use a dedicated application program and API (application program interface) communication scheme.
In one embodiment, the client device 102 executes a client-side policy management system to interact with the server-side policy management process 112 and to allow autonomous control of the device. A separate content provider 103 may provide some of the data that is included in the policy management process Data for any of the policies, business rules, and the like may be provided by a data store 120 closely or loosely coupled to any of the server 104 and/or client 102.
The client device is typically a mobile client device that provides various utilities, such as communication, entertainment, navigation, information management, and basic computing functions. 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 capability to execute the client-side policy enforcement process 105. The client computer 102 may also be embodied in a standard mobile computing device 118 such as a notebook computer, personal digital assistant, game console, media playback unit, or similar computing device. The client computers 102 and 118 may be coupled to the server computer 104 over a wired connection, a wireless connection or any combination thereof. For example, if the mobile client 102 is a cell phone, access between the mobile device and network 110 will likely utilize a separate cell network 111 that is maintained by a telecommunications provider
As shown in Figure 1, the server computer 104 executes a server-side policy management process 112. This process, along with the client-side process 105 comprises a policy management framework that allows management authorities (e.g., carrier and IT administrator) to control the behavior of mobile devices according to policies that determine aspects such as access control, resource and application utilization, operational characteristics, monitoring, and logging. The server-side process 112 provides functionality to create, edit, and submit policies to devices and then subsequently to manage and monitor these policies.
In general, policy management is the functionality that allows a management authority to define the behavior of a mobile device, so that it conforms to particular network or corporate device usage policy, or operates in accordance with defined operational constraints or principles For example, an IT manager could specify that mobile device users are not allowed to use the Internet browser during working hours Using the server -side policy management functionality, they can define a policy that specifies that the phone's browser cannot be launched during work hours (e.g., from 8am to 5pm from Monday to Friday). The server sends the policy to the mobile client, or otherwise makes it available to the client The client-side policy management process 105 then installs the policy and enforces it. This enforcement means that if the user tries to start the browser during a time that is not allowed, the policy framework automatically prevents the browser from starting Many different types of policies and rules may be defined by the system and enforced on the client device In one embodiment, the policy management framework targets enterprise devices, such as smartphones that provide functionality to access the Internet, e-mail, and corporate databases, and in many cases store confidential data. Action rule management allows IT administrators to guarantee that these devices adhere to the company policies.
This framework provides an intelligent and autonomous system that allows mobile-devices to self-manage according to the behavior defined by the server, using flexible policies. This approach ensures efficient management without requiring extensive mobile device user input, and resource utilization such as network bandwidth, server power, memory, processor overhead, and other resources Client-Side Process
As stated above, the policy management framework consists of the server-side and client-side components The server-side process 112 provides functionality to create, edit, and distribute action rule sets. The client-side process 105 provides functionality to activate, deactivate, list and enforce action rule sets on the client device 102. In one embodiment, the client side process 105 enforces policies that are represented as action rules Action rule enforcement requires functionality to deliver events, evaluate conditions, and trigger actions when a group of conditions evaluates to true Furthermore, the client-side architecture must be able to monitor action rule compliance, and therefore, must detect and report violations
An action rule set is a collection of four types of components that enforce a specific behavior of the mobile device These components are: the trigger, the condition group, the condition, and the action Figure 2 illustrates the four components of an action rule set, under an embodiment. As shown in Figure 2, a trigger 202 is an event that denotes a change in the state of some variable of interest to the action rule 204. Triggers may be related to an operational characteristic of the device and/or a policy rule defined by the system Some trigger examples include the battery level reaching certain percentage of charge, the device entering a specific location, or the time of day changing to set time, among others. When a trigger 202 notifies an action rule set 204, the action rule evaluates its predicate (conditions) 206. Several different conditions 208 may be organized into one or more condition groups 206. If a condition is true, the action rule 24 then causes execution of an associated action 210.
In one embodiment, each condition 208 comprises a Boolean expression, that is an expression that is either true (' 1 ') or false (null or O'). An example of a condition is batteryLevel<10% Action rules can have any practical number 0-n conditions, and these conditions can be grouped together by condition groups 206. In general, an action 210 is a task that is executed when the action rule predicate evaluates to true. An example of an action may be the local device command "switchOffCamera". Thus, for example, if the trigger is the battery charge level, and the condition batteryLevel<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 to active, deactivate, list, and enforce action rule sets on the client device. These components evaluate conditions and trigger actions when one or more conditions are true Figure 3 illustrates an overall architecture for the client-side action rule management process, under an embodiment For the embodiment of Figure 3, the action rule policy framework of the client-side process 300 consists of components including an action rule manager 302, a predicate evaluator 304, an action manager 306, one or more triggers 312, a trigger manager 310, and a variable manager 308. The action rule manager 302 coordinates all action rule-related client activities, including activation, deactivation, and enforcement. It leverages three components to achieve the task: Predicate Evaluator, Trigger Manager, and Action Manager. The predicate evaluator 304 evaluates the conditions of the specified action rule. To evaluate the conditions, it relies on one or more condition handlers 305. Every condition handler knows how to evaluate a specific type of expression (e.g , >, <, and =). Some condition handlers may be required to interact with a native operating system (OS) 303 to evaluate a condition. For example, a file or directory management function may be used to determine a particular file size (e.g., File >100KB) The condition handlers may rely on an abstraction layer 307 that provides a platform independent interface.
The action manager 306 provides functionality to coordinate the execution of actions, and provides different semantics, such as best effort, or strictly all The action manager forwards the action execution request to action handlers 309, which encapsulate the specific details of each action. Action handlers may interact with native OS 303 services through procedure calls (IPC), or with mobile device management services 318 through local calls. If the action manager 306 requires interaction with the native OS 303, it leverages the abstraction layer 307, which provides a platform independent API.
Triggers 312 are the components responsible for generating notifications when certain conditions are met. A trigger encapsulates a specific state and sends a notification whenever certain preconfigured conditions are met. For example, the timer trigger generates an event every "x" seconds (where "x" is configurable). Triggers maintain a list of listeners. The trigger manager 310 forwards incoming trigger notifications to the appropriate action rule sets. For each affected action rule set it sends a request to the action rule manager 302 to evaluate the action rule. The action rule manager 302 leverages the predicate evaluator 304 to evaluate the action rule's predicate and if the predicate is true, the trigger manager 310 interacts with the action handler 309 to execute the actions. System 300 also includes a variable manager 308 that provides an interface to store and retrieve variables that the different action rule sets use.
In order to ensure implementation flexibility, the client-side policy management system is configured to accommodate new functionality as policies and rules are developed and evolved over time. Update mechanisms are employed to minimize down time, and avoiding reinstallation of the system each time a new feature is available. In embodiment, the client-side process is divided into two main elements of a core infrastructure and the action rule building block handlers (i.e., trigger handlers, condition handlers, and action handlers). The core infrastructure provides the basic functionality for action rule management by orchestrating the different components, and the action rule building block handlers are the components capable of controlling trigger, condition, and action handlers.
The core functionality is independent on the specific details of each action rule instance. It simply orchestrates the interaction among the different action rule building block handlers according to defined rules. The core is configured to be stable and to not require changes, except for maintenance or upgrades. In contrast, the action rule building block handlers (triggers, action handlers, and condition handlers) are tightly coupled to every specific action rule instance. As a result, upgrade processes incorporate new action rule building block handlers at runtime, to accommodate new types of action rules over time. These components also assist in configuring which action rule building blocks a mobile device will support during device configuration or at start up time. This mechanism helps create subsets of devices with different action rule management capabilities depending, for example, on the device type or hardware characteristics.
In one embodiment, the action rule management client architecture leverages a dynamically configurable infrastructure that allows manipulating the available action rule building block handlers at runtime. Dynamically loadable modules implement the triggers, actions, and condition handlers. These modules can be deployed and installed at runtime, so that new handlers are made available to the system as they are available.
An example of the action rule management client process is described as follows for a device that has already been shipped and is currently in use has the action rule framework infrastructure installed. If the carrier decides to monitor the battery drainage rate and send a notification if this rate is higher than a certain value, but the device does not have a trigger to monitor battery drainage and does not have an action handler to send a notification, the carrier uses a defined protocol (e.g., SCoMO, software component management object) to deploy two new modules: battery trigger and notification action. The device receives the modules, detects that are action rule handlers and therefore registers them with the action rule system at runtime. The action rule framework loads the trigger module and registers it with the event source manager It then loads the action handler and registers it with the action manager. After registration, both the trigger and the action handler IDs are available and ready to use, and the action rule can be enforced.
In one embodiment, a set sequence of actions is required for the operations involving registering action rules and evaluating action rules. Action rule registration is responsible for enabling an action rule locally in a mobile device Figure 4A illustrates the steps of registering an action rule under an embodiment The process starts with a server device management process 402 creating a new management object (MO) with the action rule information and then invoking an executable command for the action rule manager 404 "Activate" operation. The action rule process receives the execute command. The action rule manager 404 registers at start up time with the action rule operation nodes (activate, deactivate, and remove) and therefore gets a callback with the URI of the action rule. Next, the action rule manager 404 invokes a RegisterTriggers process of Trigger Manager 406. This process parses the triggers' information from the MO, extracts the ID of each trigger, and finally invokes the appropriate trigger 408 to register with it.
When a trigger is fired, the action rule manager is notified and an action rule evaluation process is performed Figure 4B illustrates an action rule evaluation process, under an embodiment. When the conditions specified at trigger registration time are met, the event source sends a notification to the trigger manager 406. The trigger manager retrieves the action rule URI from the event and invokes an EvaluateActionRule process on the action rule manager 404. 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 action rule's actions through action manager 410. Server-Side Process
The overall policy management framework that controls the client-side policy management process on the mobile client device is controlled by a server side process 112, as shown in Figure 1 The server-side policy management process 112 comprises several distinct functional blocks including policy creator 122, a group policy manager process 124, a device policy manager process 126, and a user interface 128 that allows interaction with a system administrator 140. The server-side management system 112 is configured to implement a policy representation that is relatively simple and standards-based, and addresses a wide variety of use case scenarios. These policy representations can be loaded and stored in a data store 120 of server 104 In one embodiment, the server is configured to upload new policies dynamically to the mobile devices based on different criteria. In an enterprise implementation, one primary criterion is the authority group the subscriber belongs to, and other criteria can include device types, deployment locations, deployment times, and other similar criteria.
The policy creator component 122 allows the system administrator user 140 to create new instances of policies out of the needed components (triggers, conditions, actions) as a state machine, as well as to edit/update existing policies, delete existing policies, or import and export policy instances. In one embodiment, the user interface 128 presents to user 140 a list of existing policies as state machines. For creating or editing a policy, parts of the user interface 128 are dynamic as they represent the components After the user builds a state machine based on the triggers, conditions, and actions, the policy can be saved to data store 120. The import and delete functions simply change the list of available policies for the user. On export the user can save the policy instance as file.
The group policy manager tool 124 allows the user to manage target groups and associated policies. In general, two views available, a target group view, and a policy view. The target group view allows the user to view all target groups, create, edit, delete a target group, and view policies by a selected target group. The available tasks in the view include adding or removing a policy to or from selected target group, activate or deactivate a policy, check if policy compliance is up to date, synchronize with the device. In this embodiment, the user interface presents a list of existing target groups For any target group it is possible to view the associated policies. This new view contains a list of these policies and the mentioned actions are available. Adding a policy will show a list of all available policies where the user can select one When checking the compliance for one or more policies a list is populated containing devices that are out of sync and why. The user has the option to synchronize to the device and so to enforce the compliance.
The second view in the group policy manager tool is the policy view. This view allows the user to view all policies, and view target groups by selected policy In this case, the user interface shows all available policies and the user can view the associated target groups for a policy Policy Management In one embodiment, the mobile device policy management system comprising both the client-side process 105 and the server-side process 112 is used to manage and enforce policies on the mobile device 102 that fall generally into two types of policies, decision policies and active policies
The decision policies (yes/no policies) are generally used to control access to some resource or capability from or within the mobile client device For example, defining whether the mobile user entitled to use a resident application, such as the camera or music player. The embodiment described herein provides a mechanism that enables requests for policy decisions to be quickly and efficiently handled The decision policies include a component (policy enforcement point) that checks whether or not access to the resource is allowed, based on the user request and the resource associated to the decision policy as well as evaluation of some additional predicates, such as time of day, device location, and so on.
The active policies initiate an action on the mobile client device when certain conditions are met For example, switching from "ring" mode to "vibrate" mode to indicate an incoming call when the device moves within certain geographic coordinates, (e g., when the device has moved inside of a concert hall or conference room). The active policy relies on the policy enforcement component, which receives events from different event generators (e.g., context sensors and hardware and software notifications) and triggers actions when the conditions specified in the active policies are met.
Figure 5A is a block diagram of a decision policy example, under an embodiment. As shown in Figure 5 A, the decision policy enforcer 502 is invoked when the user 506 attempts to access a policy controlled resource on the mobile client For the example of Figure 5 A, the user has elected to use the resident MP3 player 504. The decision policy enforcer applies applicable policy rules along with any additional relevant predicates and determines whether or not access to the requested resource is allowed. If access is allowed, as shown in Figure 5 A, the decision policy enforcer 502 causes execution of the appropriate command, in this case start J\4P3player 508
Figure 5B is a block diagram of an active policy example, under an embodiment For the example of Figure 5B, one or more context sensors 524 in the mobile device provide sensor data to a policy enforcement component 522. Sensors can be any type of sensor within, or coupled to the mobile device that provides relevant data. Examples include clocks, timers, GPS (global positioning system) circuitry, temperature, environmental/weather, radio status, signal strength, power monitoring, and any other similar type of sensor device The sensors may be embodied in hardware circuitry or software processes, or any combination of hardware and software. The policy enforcement component 522 includes a process that receives and interprets the sensor data. For the example of Figure 5B, this component has determined that the location sensor 524 has provided data indicating that the mobile device is inside of a concert hall. The policy enforcement component 522 also includes a process to enforce any applicable policy rule based on the sensor data. In this case, the policy rule based on the location of the device dictates that the device be placed in silent mode
Figure 6 is a block diagram of a client-side system configured to manage and enforce decision policies and active policies, under an embodiment. System 600 includes a decision policy enforcer component 602 that is responsible for enforcing decision policies together with the policy decision point 604. An active policy enforcer component 606 is responsible for enforcing active policies. The decision policy enforcer stores a list of resources 608 to which it controls access These resources are typically application programs, utilities, circuitry, functions, or features that are resident on the mobile device itself, such as phone, input/output (I/O), camera, music player, audio recorder, video recorder, scanner, GPS, data storage and other functions. The policy decision point 604 is responsible for determining whether or not access to a resource 608 should be granted based on the information stored in the policy Policy rules are stored in a device policy repository 610 is a data base that stores both active and decision policies.
Under certain circumstances, policy conflicts may arise, such as when two conflicting policies may be applied, or predicate conditions may be confusing. A policy conflict resolution subsystem 612 is responsible for analyzing policy conflicts through a policy conflict analyzer, and resolving any conflicts by selecting the most appropriate policy or returning an exception through a policy selector.
With regard to enforcing of policies on mobile device, under an embodiment, when a request for accessing a resource arrives from an access requester 614, the decision policy enforcer 602 intercepts the request and interacts with the policy decision point 604 to determine whether or not the request is authorized. The policy decision point 604 extracts the associated policy from the device policy repository 610, evaluates it, and returns either "grant" or "deny" to the policy enforcement point 602. If the decision is "deny," then the policy enforcement point cancels the request. If the decision is "grant", then the policy enforcement point allows the request to proceed
In the case of active policies, the active policy enforcer 606 periodically receives events from different event generators 616 Event generators can include hardware and software status and context events, as well as other similar events. The active policy enforcer 606 matches these events against the conditions (predicates) defined in the active policies database of the device policy repository 610. When the predicate of an active policy evaluates to true, the active policy enforcer executes the action defined in the policy
Both, the policy decision point 602 and the active policy enforcer 606 may face situations where more than one policy applies to the specific action. Furthermore, there are cases where these multiple policies contradict each other. The policy conflict resolution module 612 is responsible for dealing with such conflicts. Figure 7 is a block diagram showing an example of policy conflict detection and resolution, under an embodiment. The policy conflict detection and resolution of an embodiment ensures that the results of combining policies from multiple parties are deterministic and predictable. In a case in which more than one policy applies, the policies can be active, decision, or a combination of both. Furthermore, these policies can belong to the same administration domain or different domains. As shown in Figure 7, a policy conflict analyzer 702 receives a number of policies 706 as an input parameter and analyzes whether there is a conflict among them. For example, policy 1 may allow the user to access a particular file, while policy 2 does not. Under the example illustrated in Figure 7, policy 3 does not conflict with either policy 1 or policy 2 and can therefore be applied The policy conflict analyzer 702 forwards policies 1 and 2 to a policy selector component 704, which chooses one of them based on a priority scheme The priority scheme for policies may be defined by the system administrator or other management function and stored in a central database accessible to the policy conflict resolution module 612. For the example of Figure 7, a policy priority dictates that policy 1 overrules policy 2, and therefore, the policy selector 704 allows policy 2 to be applied.
With reference to Figure 6, the device policy repository component 610 stores policies on the mobile device. The device policy repository of an embodiment can store two types of policies on the device, including decision policies and active policies, but is not so limited. Active policies describe a set of actions that must be taken based on an event occurrence (e.g., time of day, smart card insertion, and so on) and/or evaluation of some predicates. For a given resource, decision policies of an embodiment describe what roles (or entities) can perform/access what operations under specified conditions. Decision policies may also describe additional predicates (e g , time of day) which need to be evaluated before a decision is made. Decision policies may be expressed in standard languages such as XACML[X], for example. XACML (extensible Access Control Markup Language) is a declarative access control policy language implemented in XML (Extensible Markup Language) and a processing model, describing how to interpret the policies. The use of XACML makes possible a simple, flexible way to express and enforce access control policies in a variety of operating environments, using a single language.
With reference to Figure 6, the policy decision point component 604 of an embodiment makes a policy decision as to whether access to a resource 608 is granted or not based on attributes of a request from the decision policy enforcer 602 and the decision policy stored in the device policy repository 610. The decision policy enforcer 602 enforces policies for access control in response to a request from an entity 614 wanting to perform an operation or access a resource. There may be more than one decision policy enforcer on the mobile client device. The decision policy enforcer 602 passes the incoming access requests to the policy decision point 604, which makes an access allowed or access denied decision. If access is allowed, the decision policy enforcer 602 allows access to the requested resource. If access is denied, the decision policy enforcer 602 returns an appropriate status message back to the access requester.
Figure 8 is a flow diagram illustrating a method of enforcing decision policies, under an embodiment. The flow diagram starts with an access requester (principal) 802 requesting access to a resource 812, such as a file The decision policy enforcer 804 intercepts the request, and creates and sends a request to the policy decision point 806. The policy decision point 806 retrieves the resource associated policy or policies from the device policy repository 808, and performs any predicate evaluations (if necessary). The policy decision point 806 then sends a request to the conflict resolution unit 810. The conflict resolution unit 810 analyzes the policies and in case of conflicts, it resolves these conflicts and returns the policy or policies that prevail. The policy decision point 806 gets the result, makes a decision and returns it to the decision policy enforcer 804, which allows or denies the access to the resource 812.
As shown in Figure 6, the active policy enforcer 606 enforces active policies in response to an event occurrence (e.g., time of day) in addition to evaluating some predicates (e.g., location of the device). The active policy enforcer may be notified of an event occurrence in a multitude of ways including, but not limited to, using an event bus mechanism, or direct notification from the event generators.
Figure 9 is a flow diagram that illustrates a method of enforcing active policies, under an embodiment The active policy enforcer is registered with event generators that notify it about changes in the state of the mobile device context. A Global Positioning System (GPS) service is an example of an event generator. Other examples include timers, clocks, signal strength indicators, battery charge indicators, and the like The number of event generators that the active policy enforcer is registered with depends on the predicates of the active policies. It is possible for the active policy enforcer to respond to both device as well as remote network events. In the case of remote network events, the event disseminator receives and processes remote network events and notifies the active policy enforcer for appropriate action. As shown in Figure 9, the flow of active policy enforcement starts with an event generator (disseminator) 902 sending an event to the active policy enforcer 904. The active policy enforcer 904 retrieves from the device policy repository 906 all the policies for which the predicates depend on the specific event The active policy enforcer 904 then sends the policies to the conflict resolution unit 906, which looks for conflicts and selects the prevailing policies. With these results, the active policy enforcer 904 evaluates the predicates, and performs the actions defined in the policies
As shown in Figure 6, the policy conflict resolution subsystem 612 receives a number of policies and determines whether or not policies that are to be applied are in conflict with one another. For example, when the system detects an event such as "start application X", the system checks the existing active policies to determine whether they affect the current event One possible scenario could be two active policies matching the specified event. It could also happen that the policies have been set by two different administrators, and one of them allows the application to run, while the other one does not. The policy conflict analyzer analyzes the two active policies, and determines that they conflict As a result, the Policy Conflict Analyzer 702 of Figure 7 forwards the two or more conflicting policies to the policy selector component 704 that determines which policy prevails The decision algorithm is programmable, and can be based on defined rules, such as policy priorities, device user input, or even decision policies, to name a few. In addition, it is also possible for the policy selector 704 to ask a network server to make an arbitration decision. Policy conflict detection and resolution is implemented at the mobile device itself, to handle the cases where conflicts are due to dynamic properties, such as time and location For example, during working hours, a policy may allow the use of a game, while another policy may not. Such a conflict only arises at a specific time of day. Server-based conflict detection and resolution might not be sufficient to handle these dynamic cases, because they would only be checked during submission time, and not at the time when the policy must be enforced.
Figure 10 is a flow diagram illustrating a process of analyzing and resolving policy conflicts, under an embodiment. As shown in Figure 10, the policy conflict analyzer 1004 gets a set of policies from the policy requester 1002 The policy conflict analyzer 1004 then analyzes the policies and checks for conflicts If the policy conflict analyzer detects conflicts, it sends the affected policies to the policy selector 1006, which makes a decision as to the prevailing policy (if any). The decision can be done according to priorities or any other configurable algorithm (which could use a policy to decide). Implementation of Mobile Device Management
In one embodiment, the mobile device policy management framework of Figure 1 includes a system configured to manage policies, including decision policies and active policies, on mobile devices is described above that includes a device policy repository, a policy decision point, a decision policy enforcer, and an active policy enforcer The system includes a method for enforcing policies on mobile devices that proactively monitors the execution environment and automatically triggers active policies The method further exports an interface and provides functionality to evaluate and enforce decision policies. The system can combine policies from different sources, including detecting and avoiding policy conflicts.
In one embodiment, the client-side process 105 of Figure 1 incorporates system 600 of Figure 6 and is implemented as an intelligent management agent residing in the mobile client device 102. The intelligent management agent relies on communication between the client-side mobile management process 105 residing on a mobile device and the server-side mobile device management (MDM) process 112 residing in server 104.
In one embodiment, a standard management protocol, such as OMA DM (Open Mobile Alliance Device Management), is used by the server retrieve, analyze and set management properties values for the mobile client. In general, the OMA DM specification is designed for management of small mobile devices such as cell phones, PDAs and palm top computers, and can be used to manage virtually any type of networked device
The device management function is intended to support the following typical uses: provisioning including configuration of the device, enabling and disabling features; software upgrades, fault management, and the like.
In one embodiment, a client-side process is downloaded to the client device using the OMA DM protocol and SCoMO (Software Component Management Object) standard that specifies the protocol to manage software remotely on mobile devices. SCoMO generally dictates the installation, uninstallation, launching and termination of software on mobile devices. The mobile client 102 of Figure 1, and every other device that supports OMA DM contains a management tree. The management tree contains and organizes all the available management objects so that the server 104 can access every node directly through a unique URI (uniform resource identifier).
As stated previously, the policies are represented in the server using XML structures for the respective action-condition-trigger components On the mobile client device, each policy is represented as a subtree. This mechanism leverages the subtree structure provided by OMA DM and facilitates execution on the mobile client. In an embodiment, the server leverages XML to store the policies, but the client does not. The client uses the OMA DM management tree structure to store the 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.
A software manager process may be provided to facilitate download of the client-side management process to the mobile client device. In one implementation, the user has control over the software to be downloaded (user pull scenario), and applications may be provided by a third party server. The user first accesses the server computer software management portal, whether on the mobile device itself or through a separate computer The portal, where the application and its attributes 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 another implementation, the operator or enterprise controls the application download (operator push scenario). For example, in an enterprise setting, the IT department may mandate the download of an application patch or new anti-virus signature file. Here, the enterprise or operator sets the download in motion through an MDM console. The MDM server and any third party content server then establish connections to the mobile device.
In one embodiment, a configuration manager in a caπiei suite of the MDM server manages configuration settings on the mobile device over the wireless (cellular) network. For OMA DM applications, the carrier suite configures virtually any application on the mobile device for which configuration is handled by setting the values of objects in the OMA DM management tree. Certain OMA DM applications may be predefined, such as bootstrap routines, diagnostics, and other applications.
Figure 11 illustrates a management tree representation for policies within the policy management system, under an embodiment. In general, the management tree comprises a number of hierarchically organized nodes, which are entities that are managed through the OMA DM protocol. An interior node can have an unlimited number of child nodes, while a leaf node must contain a value, including null. Each node has a set of run-time properties associated with it. All properties are only valid for the associated node. An Access Control List (ACL) for a represents which server can manipulate that node. The manipulation includes adding a child node, getting the node's properties, replacing this node, or deleting this node, as well as other run-time properties.
As shown in Figure 11, the management tree contains all relevant information about a policy. A policy group 1102 may have one or more policy instances 1104. Each policy instance has a version number for revision control purposes and may have a common name. Each policy has a number of subnodes that contain various data objects related to the policies A number of these subnodes can have further subnodes, as shown. The main subnodes for use in the policy management system include the policy condition subnode 1106, the policy action subnode 1108 and the policy triggers subnode, 1110. These represent key subtrees within the policy management tree 1100
In an embodiment, the server 104 takes the XACML file of the management tree, parses it and generates one or more different subtrees. For the management tree example of Figure 11, the server-side process 112 takes the entire policy group management tree under the URI for root node 1102 and parses it into at least subnodes for the policy conditions subtree under node 1106, the policy action subtree under node 1108, and the policy trigger subtree under node 1110. This processing of the management tree XACML to manage policies that are autonomously executed on the mobile device represents a unique usage of the OMA DM specification, and advantageously facilitates the creation, management, and dissemination of policies among various mobile devices in a distributed network environment,
In an embodiment, a system comprises: a server computer executing a server- side policy management process including an interface component configured to allow a system administrator to define and modify action rule sets, and a transmission function to distribute the action rule sets to client devices over one or more networks; and a mobile client device coupled to the server computer over the one or more networks, and executing a client-side policy management process configured to activate, deactivate, and enforce the action rule sets distributed by the server computer to implement at least one of defining one or more operational characteristics of the mobile client device or allowing access to one or more resources on the mobile client device or accessible by the mobile client device over the one or more networks. In this system the action rule sets comprise: trigger events denoting a change in state of a variable of interest to an action rule of the action rule sets; conditions comprising a yes or no value associated with the variable of interest; and actions comprising a task to be executed by the mobile client device when a corresponding condition is true, The action rule sets comprise policies defined by the server-side policy management process and enforced by the client-side policy management process, The policies may comprise one or more policies, each defined as a first type of policy or a second type of policy. The first type of policy comprises a decision policy that returns either a true or false value and that enables access to a resource or function resident on the mobile client device or accessible to the mobile client device over the one or more networks, and the second type of policy comprises an active policy that initiates an action on the mobile client device when a defined condition is satisfied.
In this system, the resource is selected from the group consisting essentially of: application programs resident on the mobile client device, hardware functionality provided by the mobile client device, and computer files accessible by the mobile client device. The defined condition is determined to be satisfied through one or more sensor elements on the mobile client device, and wherein the defined condition is selected from the group consisting essentially of: time, location, user profile, and environmental conditions. The one or more sensor elements may include a timer circuit, a timer software routine, a location determination circuit, and at least one environmental sensor. The hardware functionality provided by the mobile client device may include a telecommunications interface, a music player, and a camera. In this system the plurality of conditions are grouped together by one or more condition groups. The client-side policy management process is further configured to monitor compliance with an action rule, and to detect and report to the server computer any violations of an action rule. The server computer may comprise an enterprise server, and further wherein the policies comprise enterprise rules implemented to restrict access to corporate resources in accordance with defined business rules. The corporate resources comprise information databases and related files, and the defined business rules restrict access based on identification and access privileges of a user of the mobile client device The policies comprise usage rules implemented to restrict mobile client device operation based on defined conditions.
In this system, the client device operation comprise access to functions available on the mobile client device and one or more operational settings of the mobile client device, and wherein the defined conditions include time of usage or location of the mobile client device. For this embodiment, the server-side policy management process comprises: a policy creator module configured to allow the system administrator to create, edit, and delete policies; a target group policy manager module configured to define and manage target groups consisting of users of mobile devices coupled to the server computer; a device policy manager module configured to install, remove, update, activate, or deactivate policies on the mobile client device; and a user interface providing access to the system administrator to define and manage policies through the server-side policy management process.
An embodiment is directed to a system for implementing policy management on a mobile device, comprising: a device policy repository storing one or more policies on the mobile device, the policies comprising at least one of a decision policy that dictates user access to operations or resources of the mobile device under defined conditions, and an active policy describing one or more actions to be taken based on an event occurrence; a decision policy enforcer enforcing policies for access control in response to a request from a requesting entity; a policy decision point configured to decide whether or not access to a resource is granted based on attributes of a request from the decision policy enforcer and a decision policy stored in the device policy repository; and an active policy enforcer enforcing active policies in response to an event occurrence. This system further comprises a policy conflict resolution component comprising: a policy conflict analyzer configured to determine whether one or more policies conflict with one or more other policies; and a policy selector component configured to deteimine which policy of two conflicting policies prevail. The policy selector applies a defined policy priority rule to determine which policy of the two conflicting policies prevail.
In this system, the mobile device may include one or more sensors monitoring defined operational and environmental characteristics related to operation of the mobile device. The policies consist of one or more action rule sets, each action rule set comprising, trigger events denoting a change in state of a variable of interest to an action rule of the action rule sets; conditions comprising a yes or no value associated with the variable of interest; and actions comprising a task to be executed by the mobile device when a corresponding condition is true. The decision policy returns either a true or false value and that enables access to a resource or function resident on the mobile client device or accessible to the mobile device over one or more networks, and wherein the resource is selected from the group consisting essentially of: application programs resident on the mobile client device, hardware functionality provided by the mobile client device, and computer files accessible by the mobile client device. In this system, the active policy initiates an action on the mobile client device when a defined condition is satisfied, and wherein the defined condition is determined to be satisfied through one or more sensor elements on the mobile client device, and wherein the defined condition is selected from the group consisting essentially of: time, location, user profile, and environmental conditions.
Embodiments are also directed to a method of defining and enforcing policies on a mobile client device coupled to a server computer over a computer network, comprising: executing a client- side process on an Open Mobile Alliance Device Management (OMA DM) enabled mobile client device and configured to monitor the execution environment of the mobile device and automatically trigger one or more defined active policies upon the occurrence of an event; and executing a server-side process configured to allow creation, modification and transmission of defined active policies to the mobile client device. In this method, the policies consist of one or more action rule sets, each action rule set comprising: trigger events denoting a change in state of a variable of interest to an action rule of the action rule sets; conditions comprising a yes or1 no value associated with the variable of interest; and actions comprising a task to be executed by the mobile device when a corresponding condition is true, The policies are stored on the server in extended markup language (XML) structures for the respective action-condition-trigger components. The mobile client device stores the policies as subnodes in an OMA DM management tree as management objects.
Embodiments are further directed to a system to define and enforce policies on an Open Mobile Alliance Device Management (OMA DM) enabled mobile client device coupled to a server computer over a computer network, comprising: a server- side process configured to allow creation, modification and transmission of defined policies to the mobile client device; a client-side process executed on the mobile client device and configured store the defined policies in an OMA DM management tree in the mobile client device as management objects, wherein each policy of the defined policies is represented as a subnode of the management tree. In this system, the management tree comprises a root node defining a policy group that has one or more policy instance subnodes Each policy represents a subtree within the management tree, and wherein each policy subtree has a policy condition subnode, a policy action subnode, and a policy triggers subnode.
For this embodiment, the client-side process includes a module to monitor the execution environment of the mobile device and automatically trigger one or more defined policies upon the occurrence of an event, and wherein the policies consist of one or more action rule sets, each action rule set comprising: trigger events denoting a change in state of a variable of interest to an action rule of the action rule sets; conditions comprising a yes or no value associated with the variable of interest, and actions comprising a task to be executed by the mobile device when a corresponding condition is true. The data objects related to each of the trigger events, conditions, and actions are specified within a corresponding subnode of the policy subtree. The policies are stored on the mobile device as subtrees within the management tree. The policies are created by the server computer as nodes directly on the mobile device. The mobile client device of this embodiment may comprise a smartphone coupled to server computer over one or more wireless networks.
Embodiments include a method of defining and enforcing policies on an Open Mobile Alliance Device Management (OMA DM) enabled mobile client device coupled to a server computer over a computer network, comprising: executing a server- side process that is operable to allow creation, modification and transmission by a system administrator of defined policies to the mobile client device; executing a client- side process on the mobile client device that is operable to store the defined policies in an OMA DM management tree in the mobile client device as management objects, wherein each policy of the defined policies is represented as a subnode of the management tree, and further wherein the management tree comprises a root node defining a policy group that has one or more policy instance subnodes The method further comprises organizing the management tree under a policy group root node including at least one policy instance subnode. The method yet further comprises parsing the management tree a first subtree for policy conditions of the policy instance, a second subtree for policy actions of the policy instance, a third subtree for policy triggers of the policy instance.
Additional steps of this embodiment include monitoring the execution environment of the mobile device and automatically trigger the policy instance upon the occurrence of an event. For this embodiment, the policies consist of one or more action rule sets, each action rule set comprising: trigger events denoting a change in state of a variable of interest to an action rule of the action rule sets; conditions comprising a yes or no value associated with the variable of interest; and actions comprising a task to be executed by the mobile device when a corresponding condition is true. The method further comprises storing data objects related to each of the trigger events, conditions, and actions within a corresponding subnode of the policy instance subtree. The policies are stored on the mobile device as subtrees within the management tree. The method further comprises creating the required nodes directly on the mobile device.
The processing system of an embodiment includes at least one processor and at least one memory device or subsystem The processing system can also include or be coupled to at least one database. The term "processor" as generally used herein refers to any logic processing unit, such as one or more central processing units (CPUs), digital signal processors (DSPs), application-specific integrated circuits (ASIC), etc. The processor and memory can be monolithically integrated onto a single chip, distributed among a number of chips or components, and/or provided by some combination of algorithms. The methods described herein can be implemented in one or more of software algorithm(s), programs, firmware, hardware, components, circuitry, in any combination.
Components of the systems and methods described herein can be located together or in separate locations. Communication paths couple the components and include any medium for communicating or transferring files among the components. The communication paths include wireless connections, wired connections, and hybrid wireless/wired connections. The communication paths also include couplings or connections to networks including local area networks (LANs), metropolitan area networks (MANs), wide area networks (WANs), proprietary networks, interoffice or backend networks, and the Internet. Furthermore, the communication paths include removable fixed mediums like floppy disks, hard disk drives, and CD-ROM disks, as well as flash RAM, Universal Serial Bus (USB) connections, RS-232 connections, telephone lines, buses, and electronic mail messages.
Unless the context clearly requires otherwise, throughout the description, the words "comprise," "comprising," and the like are to be construed in an inclusive sense as opposed to an exclusive or exhaustive sense; that is to say, in a sense of "including, but not limited to " Words using the singular or plural number also include the plural or singular number respectively. Additionally, the words "herein," "hereunder," "above," "below," and words of similar import refer to this application as a whole and not to any particular portions of this application. When the word "or" is used in reference to a list of two or more items, that word covers all of the following interpretations of the word: any of the items in the list, all of the items in the list and any combination of the items in the list.
The above description of embodiments of the systems and methods described herein is not intended to be exhaustive or to limit the systems and methods described to the precise form disclosed. While specific embodiments of, and examples for, the systems and methods described herein are described herein for illustrative purposes, various equivalent modifications are possible within the scope of other systems and methods, as those skilled in the relevant art will recognize. The teachings of the systems and methods described herein provided herein can be applied to other processing systems and methods, not only for the systems and methods described above.
The elements and acts of the various embodiments described above can be combined to provide further embodiments. These and other changes can be made to the systems and methods described herein in light of the above detailed description

Claims

CLAIMSWhat is claimed is.
1. A system comprising: a server computer executing a server-side policy management process including an interface component configured to allow a system administrator to define and modify action rule sets, and a transmission function to distribute the action rule sets to client devices over one or more networks; and a mobile client device coupled to the server computer over the one or more networks, and executing a client-side policy management process configured to activate, deactivate, and enforce the action rule sets distributed by the server computer to implement at least one of defining one or more operational characteristics of the mobile client device or allowing access to one or more resources on the mobile client device or accessible by the mobile client device over the one or more networks.
2 The system of claim 1 wherein the action rule sets comprise: trigger events denoting a change in state of a variable of interest to an action rule of the action rule sets; conditions comprising a yes or no value associated with the variable of interest, and actions comprising a task to be executed by the mobile client device when a corresponding condition is true.
3. The system of claim 2 wherein the action rule sets comprise policies defined by the server-side policy management process and enforced by the client-side policy management process.
4. The system of claim 3 wherein the policies comprise one or more policies, each defined as a first type of policy or a second type of policy.
5. The system of claim 4 wherein the first type of policy comprises a decision policy that returns either a true or false value and that enables access to a resource or function resident on the mobile client device or accessible to the mobile client device over the one or more networks, and wherein the second type of policy comprises an active policy that initiates an action on the mobile client device when a defined condition is satisfied
6 The system of claim 5 wherein the resource is selected from the group consisting essentially of: application programs resident on the mobile client device, hardware functionality provided by the mobile client device, and computer files accessible by the mobile client device.
7. The system of claim 5 wherein the defined condition is determined to be satisfied through one or more sensor elements on the mobile client device, and wherein the defined condition is selected from the group consisting essentially of: time, location, user profile, and environmental conditions
8 The system of claim 7 wherein the one or more sensor elements include a timer circuit, a timer software routine, a location determination circuit, and at least one environmental sensor.
9. The system of claim 8 wherein the hardware functionality provided by the mobile client device include a telecommunications interface, a music player, and a camera
10 The system of claim 1 wherein a plurality of conditions are grouped together by one or more condition groups.
1 1. The system of claim 1 wherein the client-side policy management process is further configured to monitor compliance with an action rule, and to detect and report to the server computer any violations of an action rule.
12. The system of claim 3 wherein the server computer comprises an enterprise server, and further wherein the policies comprise enterprise rules implemented to restrict access to corporate resources in accordance with defined business rules
13. The system of claim 12 wherein the corporate resources comprise information databases and related files, and the defined business rales restrict access based on identification and access privileges of a user of the mobile client device
14. The system of claim 13 wherein the policies comprise usage rules implemented to restrict mobile client device operation based on defined conditions
15. The system of claim 14 wherein the client device operation comprise access to functions available on the mobile client device and one or more operational settings of the mobile client device, and wherein the defined conditions include time of usage or location of the mobile client device.
16. The system of claim 15 wherein the server-side policy management process comprises: a policy creator module configured to allow the system administrator to create, edit, and delete policies; a target group policy manager module configured to define and manage target groups consisting of users of mobile devices coupled to the server computer; a device policy manager module configured to install, remove, update, activate, or deactivate policies on the mobile client device; and a user interface providing access to the system administrator to define and manage policies through the server-side policy management process
17. A system for implementing policy management on a mobile device, comprising: a device policy repository storing one or more policies on the mobile device, the policies comprising at least one of a decision policy that dictates user access to operations or resources of the mobile device under defined conditions, and an active policy describing one or more actions to be taken based on an event occurrence; a decision policy enforcer enforcing policies for access control in response to a request from a requesting entity; a policy decision point configured to decide whether or not access to a resource is granted based on attributes of a request from the decision policy enforcer and a decision policy stored in the device policy repository; and an active policy enforcer enforcing active policies in response to an event occurrence.
18. The system of claim 17 further comprising a policy conflict resolution component comprising: a policy conflict analyzer configured to determine whether one or more policies conflict with one or more other policies; and a policy selector component configured to determine which policy of two conflicting policies prevail.
19. The system of claim 18 herein the policy selector applies a defined policy priority rule to determine which policy of the two conflicting policies prevail.
20. The system of claim 17 wherein the mobile device includes one or more sensors monitoring defined operational and environmental characteristics related to operation of the mobile device.
21. The system of claim 17 wherein the policies consist of one or more action rule sets, each action rule set comprising: trigger events denoting a change in state of a variable of interest to an action rule of the action rule sets; conditions comprising a yes or no value associated with the variable of interest; and actions comprising a task to be executed by the mobile device when a corresponding condition is true.
22. The system of claim 21 wherein the decision policy returns either a true or false value and that enables access to a resource or function resident on the mobile client device or accessible to the mobile device over one or more networks, and wherein the resource is selected from the group consisting essentially of: application programs resident on the mobile client device, hardware functionality provided by the mobile client device, and computer files accessible by the mobile client device.
23. The system of claim 21 wherein the active policy initiates an action on the mobile client device when a defined condition is satisfied, and wherein the defined condition is determined to be satisfied through one or more sensor elements on the mobile client device, and wherein the defined condition is selected from the group consisting essentially of: time, location, user profile, and environmental conditions,
24. A method of defining and enforcing policies on a mobile client device coupled to a server computer over a computer1 network, comprising: executing a client-side process on an Open Mobile Alliance Device Management (OMA DM) enabled mobile client device and configured to monitor the execution environment of the mobile device and automatically trigger one or more defined active policies upon the occurrence of an event; and executing a server-side process configured to allow creation, modification and transmission of defined active policies to the mobile client device.
25. The method of claim 24 wherein the policies consist of one or more action rule sets, each action rule set comprising: trigger events denoting a change in state of a variable of interest to an action rule of the action rule sets; conditions comprising a yes or no value associated with the variable of interest; and actions comprising a task to be executed by the mobile device when a corresponding condition is true.
26. The method of claim 25 wherein the policies are stored on the server in extended markup language (XML) structures for the respective action-condition-trigger components.
27. The method of claim 26 wherein the mobile client device stores the policies as subnodes in an OMA DM management tree as management objects.
28. A system to define and enforce policies on an Open Mobile Alliance Device Management (OMA DM) enabled mobile client device coupled to a server computer over a computer network, comprising: a server-side process configured to allow creation, modification and transmission of defined policies to the mobile client device; a client-side process executed on the mobile client device and configured store the defined policies in an OMA DM management tree in the mobile client device as management objects, wherein each policy of the defined policies is represented as a subnode of the management tree.
29. The system of claim 28 wherein the management tree comprises a root node defining a policy group that has one or more policy instance subnodes.
30. The system of claim 29 wherein each policy represents a subtree within the management tree, and wherein each policy subtree has a policy condition subnode, a policy action subnode, and a policy triggers subnode.
31. The system of claim 30 wherein the client-side process includes a module to monitor the execution environment of the mobile device and automatically trigger one or more defined policies upon the occurrence of an event, and wherein the policies consist of one or more action rule sets, each action rule set comprising: trigger events denoting a change in state of a variable of interest to an action rule of the action rule sets; conditions comprising a yes or no value associated with the variable of interest; and actions comprising a task to be executed by the mobile device when a corresponding condition is true.
32. The system of claim 31 wherein data objects related to each of the trigger events, conditions, and actions are specified within a corresponding subnode of the policy subtree.
33. The system of claim 32 wherein the policies are stored on the mobile device as subtrees within the management tree.
34 The system of claim 33 wherein the policies are created by the server compute as nodes directly on the mobile device.
35. The system of claim 34 wherein the mobile client device comprises a smartphone coupled to server computer over one or more wireless networks.
36. A method of defining and enforcing policies on an Open Mobile Alliance Device Management (OMA DM) enabled mobile client device coupled to a server computer over a computer network, comprising: executing a server-side process that is operable to allow creation, modification and transmission by a system administrator of defined policies to the mobile client device; executing a client-side process on the mobile client device that is operable to store the defined policies in an OMA DM management tree in the mobile client device as management objects, wherein each policy of the defined policies is represented as a subnode of the management tree, and further wherein the management tree comprises a root node defining a policy group that has one or more policy instance subnodes.
37. The method of claim 36 further comprising organizing the management tree under a policy group root node including at least one policy instance subnode.
38. The method of claim 37 further comprising parsing the management tree a first subtree for policy conditions of the policy instance, a second subtree for policy actions of the policy instance, a third subtree for policy triggers of the policy instance.
39. The method of claim 38 further comprising monitoring the execution environment of the mobile device and automatically trigger the policy instance upon the occurrence of an event.
40. The method of claim 38 wherein the policies consist of one or more action rule sets, each action rule set comprising: trigger events denoting a change in state of a variable of interest to an action rule of the action rule sets; conditions comprising a yes or no value associated with the variable of interest; and actions comprising a task to be executed by the mobile device when a corresponding condition is true.
41. The method of claim 40 further comprising storing data objects related to each of the trigger events, conditions, and actions within a corresponding subnode of the policy instance subtree
42. The method of claim 41 further comprising storing the policies on the mobile device as subtrees within the management tree.
43 The method of claim 42 further comprising creating the required nodes directly on the mobile device
PCT/US2008/072667 2007-08-08 2008-08-08 Managing and enforcing policies on mobile devices WO2009021200A1 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
PCT/US2008/072667 WO2009021200A1 (en) 2007-08-08 2008-08-08 Managing and enforcing policies on mobile devices
EP08782690.5A EP2188730A4 (en) 2007-08-08 2008-08-08 Managing and enforcing policies on mobile devices
US12/188,936 US20090049518A1 (en) 2007-08-08 2008-08-08 Managing and Enforcing Policies on Mobile Devices

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US96418007P 2007-08-08 2007-08-08
US96413107P 2007-08-08 2007-08-08
US60/964,180 2007-08-08
US60/964,131 2007-08-08
PCT/US2008/072667 WO2009021200A1 (en) 2007-08-08 2008-08-08 Managing and enforcing policies on mobile devices

Publications (1)

Publication Number Publication Date
WO2009021200A1 true WO2009021200A1 (en) 2009-02-12

Family

ID=41666717

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2008/072667 WO2009021200A1 (en) 2007-08-08 2008-08-08 Managing and enforcing policies on mobile devices

Country Status (2)

Country Link
EP (1) EP2188730A4 (en)
WO (1) WO2009021200A1 (en)

Cited By (35)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011121143A1 (en) * 2010-03-29 2011-10-06 Telefonica, S.A. System and method for dynamic and remote configuration of mobile devices
WO2012001475A1 (en) * 2010-06-28 2012-01-05 Fujitsu Limited Consigning authentication method
WO2012001476A3 (en) * 2010-06-28 2012-03-01 Fujitsu Limited Consigning authentication method
WO2013043527A2 (en) * 2011-09-19 2013-03-28 Jordan Lawrence Group, L.C. Management of compliance with policies, procedures and/or directives
EP2645293A2 (en) 2012-03-28 2013-10-02 Eitan Bauch Method and apparatus for controlling operations performed by a mobile computing device
USRE44746E1 (en) 2004-04-30 2014-02-04 Blackberry Limited System and method for handling data transfers
US8656016B1 (en) 2012-10-24 2014-02-18 Blackberry Limited Managing application execution and data access on a device
US20140113593A1 (en) * 2012-10-22 2014-04-24 Zheng Zhou Method and system for monitoring and restricting use of mobile devices
EP2725513A1 (en) * 2012-10-24 2014-04-30 BlackBerry Limited Managing permission settings applied to applications
US20140215555A1 (en) * 2012-10-15 2014-07-31 Citrix Systems, Inc Conjuring and Providing Profiles that Manage Execution of Mobile Applications
US8799227B2 (en) 2011-11-11 2014-08-05 Blackberry Limited Presenting metadata from multiple perimeters
US9075955B2 (en) 2012-10-24 2015-07-07 Blackberry Limited Managing permission settings applied to applications
US9161226B2 (en) 2011-10-17 2015-10-13 Blackberry Limited Associating services to perimeters
US9215225B2 (en) 2013-03-29 2015-12-15 Citrix Systems, Inc. Mobile device locking with context
US9213850B2 (en) 2011-10-11 2015-12-15 Citrix Systems, Inc. Policy-based application management
US9282099B2 (en) 2005-06-29 2016-03-08 Blackberry Limited System and method for privilege management and revocation
US9280377B2 (en) 2013-03-29 2016-03-08 Citrix Systems, Inc. Application with multiple operation modes
US9286471B2 (en) 2011-10-11 2016-03-15 Citrix Systems, Inc. Rules based detection and correction of problems on mobile devices of enterprise users
US9355223B2 (en) 2013-03-29 2016-05-31 Citrix Systems, Inc. Providing a managed browser
US9369449B2 (en) 2013-03-29 2016-06-14 Citrix Systems, Inc. Providing an enterprise application store
US9369466B2 (en) 2012-06-21 2016-06-14 Blackberry Limited Managing use of network resources
US9386120B2 (en) 2012-10-12 2016-07-05 Citrix Systems, Inc. Single sign-on access in an orchestration framework for connected devices
US9455886B2 (en) 2013-03-29 2016-09-27 Citrix Systems, Inc. Providing mobile device management functionalities
US9497220B2 (en) 2011-10-17 2016-11-15 Blackberry Limited Dynamically generating perimeters
US9516022B2 (en) 2012-10-14 2016-12-06 Getgo, Inc. Automated meeting room
US9521117B2 (en) 2012-10-15 2016-12-13 Citrix Systems, Inc. Providing virtualized private network tunnels
US9602474B2 (en) 2012-10-16 2017-03-21 Citrix Systems, Inc. Controlling mobile device access to secure data
US9606774B2 (en) 2012-10-16 2017-03-28 Citrix Systems, Inc. Wrapping an application with field-programmable business logic
US9659165B2 (en) 2011-09-06 2017-05-23 Crimson Corporation Method and apparatus for accessing corporate data from a mobile device
US9848330B2 (en) 2014-04-09 2017-12-19 Microsoft Technology Licensing, Llc Device policy manager
US9971585B2 (en) 2012-10-16 2018-05-15 Citrix Systems, Inc. Wrapping unmanaged applications on a mobile device
US9985850B2 (en) 2013-03-29 2018-05-29 Citrix Systems, Inc. Providing mobile device management functionalities
US10284627B2 (en) 2013-03-29 2019-05-07 Citrix Systems, Inc. Data management for an application with multiple operation modes
US10848520B2 (en) 2011-11-10 2020-11-24 Blackberry Limited Managing access to resources
US10908896B2 (en) 2012-10-16 2021-02-02 Citrix Systems, Inc. Application wrapping for application management framework

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050055397A1 (en) * 2003-09-08 2005-03-10 Microsoft Corporation System and method for an OMA DM extension to manage mobile device configuration settings
US20050260973A1 (en) * 2004-05-24 2005-11-24 Van De Groenendaal Joannes G Wireless manager and method for managing wireless devices
US20060161646A1 (en) * 2005-01-19 2006-07-20 Marc Chene Policy-driven mobile forms applications
US7240015B1 (en) * 1999-09-17 2007-07-03 Mitel Networks Corporation And The University Of Ottawa Policy representations and mechanisms for the control of software

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7873357B2 (en) * 2004-11-04 2011-01-18 Telefonaktiebolaget L M Ericsson (Publ) Selective disablement of mobile communication equipment capabilities
CA2604312C (en) * 2005-04-15 2014-12-09 Esprida Corporation Apparatus and method for managing a network of intelligent devices
CN100361456C (en) * 2005-10-13 2008-01-09 华为技术有限公司 Terminal equipment managing method

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7240015B1 (en) * 1999-09-17 2007-07-03 Mitel Networks Corporation And The University Of Ottawa Policy representations and mechanisms for the control of software
US20050055397A1 (en) * 2003-09-08 2005-03-10 Microsoft Corporation System and method for an OMA DM extension to manage mobile device configuration settings
US20050260973A1 (en) * 2004-05-24 2005-11-24 Van De Groenendaal Joannes G Wireless manager and method for managing wireless devices
US20060161646A1 (en) * 2005-01-19 2006-07-20 Marc Chene Policy-driven mobile forms applications

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP2188730A4 *

Cited By (70)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
USRE49721E1 (en) 2004-04-30 2023-11-07 Blackberry Limited System and method for handling data transfers
USRE46083E1 (en) 2004-04-30 2016-07-26 Blackberry Limited System and method for handling data transfers
USRE48679E1 (en) 2004-04-30 2021-08-10 Blackberry Limited System and method for handling data transfers
USRE44746E1 (en) 2004-04-30 2014-02-04 Blackberry Limited System and method for handling data transfers
US9282099B2 (en) 2005-06-29 2016-03-08 Blackberry Limited System and method for privilege management and revocation
US10515195B2 (en) 2005-06-29 2019-12-24 Blackberry Limited Privilege management and revocation
US9734308B2 (en) 2005-06-29 2017-08-15 Blackberry Limited Privilege management and revocation
WO2011121143A1 (en) * 2010-03-29 2011-10-06 Telefonica, S.A. System and method for dynamic and remote configuration of mobile devices
US8726335B2 (en) 2010-06-28 2014-05-13 Fujitsu Limited Consigning authentication method
US9467448B2 (en) 2010-06-28 2016-10-11 Fujitsu Limited Consigning authentication method
WO2012001475A1 (en) * 2010-06-28 2012-01-05 Fujitsu Limited Consigning authentication method
WO2012001476A3 (en) * 2010-06-28 2012-03-01 Fujitsu Limited Consigning authentication method
US9659165B2 (en) 2011-09-06 2017-05-23 Crimson Corporation Method and apparatus for accessing corporate data from a mobile device
WO2013043527A3 (en) * 2011-09-19 2013-06-27 Jordan Lawrence Group, L.C. Management of compliance with policies, procedures and/or directives
WO2013043527A2 (en) * 2011-09-19 2013-03-28 Jordan Lawrence Group, L.C. Management of compliance with policies, procedures and/or directives
US9213850B2 (en) 2011-10-11 2015-12-15 Citrix Systems, Inc. Policy-based application management
US11134104B2 (en) 2011-10-11 2021-09-28 Citrix Systems, Inc. Secure execution of enterprise applications on mobile devices
US10044757B2 (en) 2011-10-11 2018-08-07 Citrix Systems, Inc. Secure execution of enterprise applications on mobile devices
US10063595B1 (en) 2011-10-11 2018-08-28 Citrix Systems, Inc. Secure execution of enterprise applications on mobile devices
US9529996B2 (en) 2011-10-11 2016-12-27 Citrix Systems, Inc. Controlling mobile device access to enterprise resources
US9286471B2 (en) 2011-10-11 2016-03-15 Citrix Systems, Inc. Rules based detection and correction of problems on mobile devices of enterprise users
US9521147B2 (en) 2011-10-11 2016-12-13 Citrix Systems, Inc. Policy based application management
US10402546B1 (en) 2011-10-11 2019-09-03 Citrix Systems, Inc. Secure execution of enterprise applications on mobile devices
US10469534B2 (en) 2011-10-11 2019-11-05 Citrix Systems, Inc. Secure execution of enterprise applications on mobile devices
US9378359B2 (en) 2011-10-11 2016-06-28 Citrix Systems, Inc. Gateway for controlling mobile device access to enterprise resources
US9497220B2 (en) 2011-10-17 2016-11-15 Blackberry Limited Dynamically generating perimeters
US9402184B2 (en) 2011-10-17 2016-07-26 Blackberry Limited Associating services to perimeters
US9161226B2 (en) 2011-10-17 2015-10-13 Blackberry Limited Associating services to perimeters
US10735964B2 (en) 2011-10-17 2020-08-04 Blackberry Limited Associating services to perimeters
US10848520B2 (en) 2011-11-10 2020-11-24 Blackberry Limited Managing access to resources
US8799227B2 (en) 2011-11-11 2014-08-05 Blackberry Limited Presenting metadata from multiple perimeters
US9720915B2 (en) 2011-11-11 2017-08-01 Blackberry Limited Presenting metadata from multiple perimeters
EP2645293A2 (en) 2012-03-28 2013-10-02 Eitan Bauch Method and apparatus for controlling operations performed by a mobile computing device
US11032283B2 (en) 2012-06-21 2021-06-08 Blackberry Limited Managing use of network resources
US9369466B2 (en) 2012-06-21 2016-06-14 Blackberry Limited Managing use of network resources
US9854063B2 (en) 2012-10-12 2017-12-26 Citrix Systems, Inc. Enterprise application store for an orchestration framework for connected devices
US9392077B2 (en) 2012-10-12 2016-07-12 Citrix Systems, Inc. Coordinating a computing activity across applications and devices having multiple operation modes in an orchestration framework for connected devices
US9386120B2 (en) 2012-10-12 2016-07-05 Citrix Systems, Inc. Single sign-on access in an orchestration framework for connected devices
US9516022B2 (en) 2012-10-14 2016-12-06 Getgo, Inc. Automated meeting room
US9467474B2 (en) * 2012-10-15 2016-10-11 Citrix Systems, Inc. Conjuring and providing profiles that manage execution of mobile applications
US9654508B2 (en) 2012-10-15 2017-05-16 Citrix Systems, Inc. Configuring and providing profiles that manage execution of mobile applications
US9521117B2 (en) 2012-10-15 2016-12-13 Citrix Systems, Inc. Providing virtualized private network tunnels
US20140215555A1 (en) * 2012-10-15 2014-07-31 Citrix Systems, Inc Conjuring and Providing Profiles that Manage Execution of Mobile Applications
US9973489B2 (en) 2012-10-15 2018-05-15 Citrix Systems, Inc. Providing virtualized private network tunnels
US10908896B2 (en) 2012-10-16 2021-02-02 Citrix Systems, Inc. Application wrapping for application management framework
US9606774B2 (en) 2012-10-16 2017-03-28 Citrix Systems, Inc. Wrapping an application with field-programmable business logic
US9602474B2 (en) 2012-10-16 2017-03-21 Citrix Systems, Inc. Controlling mobile device access to secure data
US9971585B2 (en) 2012-10-16 2018-05-15 Citrix Systems, Inc. Wrapping unmanaged applications on a mobile device
US9858428B2 (en) 2012-10-16 2018-01-02 Citrix Systems, Inc. Controlling mobile device access to secure data
US10545748B2 (en) 2012-10-16 2020-01-28 Citrix Systems, Inc. Wrapping unmanaged applications on a mobile device
US20140113593A1 (en) * 2012-10-22 2014-04-24 Zheng Zhou Method and system for monitoring and restricting use of mobile devices
US9942753B2 (en) * 2012-10-22 2018-04-10 Pervasive Group, Inc. Method and system for monitoring and restricting use of mobile devices
US9075955B2 (en) 2012-10-24 2015-07-07 Blackberry Limited Managing permission settings applied to applications
US9065771B2 (en) 2012-10-24 2015-06-23 Blackberry Limited Managing application execution and data access on a device
EP2725513A1 (en) * 2012-10-24 2014-04-30 BlackBerry Limited Managing permission settings applied to applications
US8656016B1 (en) 2012-10-24 2014-02-18 Blackberry Limited Managing application execution and data access on a device
US9280377B2 (en) 2013-03-29 2016-03-08 Citrix Systems, Inc. Application with multiple operation modes
US9355223B2 (en) 2013-03-29 2016-05-31 Citrix Systems, Inc. Providing a managed browser
US10476885B2 (en) 2013-03-29 2019-11-12 Citrix Systems, Inc. Application with multiple operation modes
US10097584B2 (en) 2013-03-29 2018-10-09 Citrix Systems, Inc. Providing a managed browser
US9985850B2 (en) 2013-03-29 2018-05-29 Citrix Systems, Inc. Providing mobile device management functionalities
US10701082B2 (en) 2013-03-29 2020-06-30 Citrix Systems, Inc. Application with multiple operation modes
US9948657B2 (en) 2013-03-29 2018-04-17 Citrix Systems, Inc. Providing an enterprise application store
US9413736B2 (en) 2013-03-29 2016-08-09 Citrix Systems, Inc. Providing an enterprise application store
US9215225B2 (en) 2013-03-29 2015-12-15 Citrix Systems, Inc. Mobile device locking with context
US10965734B2 (en) 2013-03-29 2021-03-30 Citrix Systems, Inc. Data management for an application with multiple operation modes
US10284627B2 (en) 2013-03-29 2019-05-07 Citrix Systems, Inc. Data management for an application with multiple operation modes
US9369449B2 (en) 2013-03-29 2016-06-14 Citrix Systems, Inc. Providing an enterprise application store
US9455886B2 (en) 2013-03-29 2016-09-27 Citrix Systems, Inc. Providing mobile device management functionalities
US9848330B2 (en) 2014-04-09 2017-12-19 Microsoft Technology Licensing, Llc Device policy manager

Also Published As

Publication number Publication date
EP2188730A4 (en) 2014-09-17
EP2188730A1 (en) 2010-05-26

Similar Documents

Publication Publication Date Title
US8375136B2 (en) Defining and implementing policies on managed object-enabled mobile devices
US20090049518A1 (en) Managing and Enforcing Policies on Mobile Devices
WO2009021200A1 (en) Managing and enforcing policies on mobile devices
US8010842B2 (en) Intelligent mobile device management client
US8139509B2 (en) Installation and management of mobile device [{S]} configuration
US10601875B2 (en) Automated multi-level federation and enforcement of information management policies in a device network
US10693708B2 (en) Defining configurable characteristics of a product and associating configuration with enterprise resources
EP3007408B1 (en) Service method for managing transactions using application properties and system therefor
JP5055410B2 (en) Device management system and device management instruction scheduling method in the system
US20020091819A1 (en) System and method for configuring computer applications and devices using inheritance
US20060143179A1 (en) Apparatus and method for managing security policy information using a device management tree
KR20150093663A (en) Method and apparatus for authenticating access authorization in wireless communication system
EP3378217A1 (en) Cross-resource subscription for m2m service layer
US20060248181A1 (en) Formatted and/or tunable QOS data publication, subscription, and/or distribution servers and clients
WO2008024501A2 (en) System and method for mobile device application management
KR20140072164A (en) Privacy management for subscriber data
US20190236292A1 (en) Restricting access and edit permissions of metadata
US20150059006A1 (en) Secure Device Management Abstraction and Unification Module
CA2604113C (en) System and method of waste management
US8200823B1 (en) Technique for deployment and management of network system management services
Thanh et al. VISECO: An annotated security management framework for 5G
Marchiori et al. Android Private Compute Core Architecture
CA2606036C (en) Access control system and method for wireless application provisioning
KR100913976B1 (en) Use of configurations in device with multiple configurations

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08782690

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2008782690

Country of ref document: EP