The Open Mobile Alliance (OMA) Device Management (DM) is a protocol designed to allow, for example, network operators to remotely manage mobile devices, such as cellular telephones, Personal Digital Assistants (PDAs), and palm top computing devices. With OMA DM, the network operators can perform functions such as provision the devices remotely, manage configuration settings, install and upgrade the software, and monitor and manage faults on the device.
Each device that supports OMA DM exposes a management tree that contains and organizes all available Management Objects (MOs) on the device to device management servers. A MO is an object associated with a specific functionality on the device and contains one or more nodes that support that functionality. A first MO, for example, may relate to Multimedia Messaging Service (MMS) functionality and settings on the device, while a second MO relates to email functionality on the device. A third MO may relate to the functionality associated with connectivity. Other MOs associated with other functions on the device are also possible. To manage this functionality and settings on mobile devices, network operators utilize servers that have rights to access the nodes in the MOs.
Currently, access control is handled at the node-level. Each node includes an Access Control List (ACL) identifying the servers that are allowed to manage the functions of the node. A given server can manage the function on a given node only if an associated ACL for the node identifies the server as being valid. This node-level access control provides a great deal of flexibility, but makes device management complicated. In practice, network operators generally already have full control of all the nodes on the device or for all management objects they are supporting. Further, ACLs are not very useful for multiple management authorities as ACLs only support delegation.
Another problem with existing ACL mechanisms is that each node needs an associated ACL value. However, in some platforms, there is only an Application Programming Interface (API) available to get/set the node values. As one example, the conventional implementations of ACL mechanisms do not support operations to retrieve and store connectivity settings, including ACL values, on the ANDROID platform. This is because the API to the database where the connectivity settings are stored does not contain ACL, thereby prohibiting the modification of the database. Avoiding current ACL mechanisms on this platform, as well as other platforms, will reduce complexity.
USPTO Backgrounds
USPTO Backgrounds