Method and device for defining objects allowing to establish a device management tree for mobile communication devices

Description of equivalent WO 2004046963 A1

METHOD AND DEVICE FOR DEFINING OBJECTS ALLOWING TO ESTABLISH A DEVICE MANAGEMENT TREE FOR MOBILE COMMUNICATION DEVICES

The present invention relates to a method and device for defining and adding objects in a hierarchical object structure which allows to establish a device management tree structure for storing management related information of a mobile communication device. In particular, the present invention relates to a method for creating one or several objects within the management tree resulting in a management tree which has dynamic structures and which provides an efficient, clear, manageable and preferable organization. Moreover, the present invention relates to devices and systems being adapted to operate the aforementioned method.

The synchronization of data is a well known problem for all users processing same data with at least two different electronic devices. In general, synchronization takes place between a terminal device (e.g., a mobile phone) and a server device (e.g., an application in a local PC or a dedicated synchronization server). Data of portable terminals, such as portable computers, PDA terminals (personal digital assistant), mobile stations or pagers, can be synchronized with network applications, applications of desktop computers or with other databases of the telecommunications system, wherein the term database should be understood as broad as possible, i.e. shall cover arbitrary sets of data. In particular, data of calendar and e-mail applications are typically synchronized.

Synchronization has been based on the use of different manufacturer-specific protocols which are incompatible. This restricts the use of terminal or data types and often causes troubles to the user. In mobile communication, in particular, it is important that data can be retrieved and updated regardless of the terminal and application used.

To improve synchronization of application data, a language known as synchronization markup language SyncML, which is based on the extensible markup language (XML) and a corresponding standardized document type description (DTD), has been developed. By using a SyncML synchronization protocol, which employs messages in the SyncML format, data of any application can be synchronized between networked terminals and a network server of any kind. The SyncML synchronization protocol works both in wireless and in fixed networks and supports several transmission protocols. The above presented SyncML synchronization technology addresses preferably the synchronization of databases. A problem similar to the synchronization of databases is given by the managing of configuration data and settings necessary for the operation of electronic devices within changing environments, for example of mobile phone operating within mobile communication networks of different network carriers requiring individual carrier related sets of configurations e.g. network access point (NAP) definitions, proxy and gateway server addresses, information and definitions, address information of servers providing certain services such as short message service (SMS), multimedia message service (MMS) and the like. The SyncML device management relates to the harmonizing of such configuration data and settings. The respective configuration data and information is contained in management objects, respectively, associated with respective device feature(s) and operable application(s), respectively.

SyncML device management (SyncML DM) protocol allows management commands to be executed on management objects and it uses a package format similar SyncML synchronization protocol and related definitions and is based also on XML or related XML encoding such as binary encoded XML. A management object might reflect a set of configuration parameters for a device, i.e. configuration parameters of device features and/or configuration parameters and settings of software applications executed on the device. Actions that can be taken against this object might include reading and setting parameter keys and values. Another management object might be the run-time environment for software applications on a device. Actions that can be taken against this type of object might include installing, upgrading, or uninstalling software elements. Preferably, dedicated management servers provide the required configuration parameters, settings, keys and values for synchronization of the device management information aforementioned.

The device management in accordance with the SyncML DM allows to structure the management objects in a hierarchical management tree containing all information which can be managed using the SyncML DM protocol. The management tree is based on a permanent part of the management tree defined and provided by the manufacturer of the respective electronic device supporting SyncML device management. The real management tree present in such an operated electronic device is composed of this permanent part of the management tree which is expanded by one or several dynamically created parts of the management tree. The real management tree is described in some way from a kind of pre-determined tree framework, the device description framework. It is obviously, that the hierarchical structure of such a management tree containing management information required for operating an electronic device of a type as described above is rather complex depending on the functions provided by the terminal device to a user and the applications operable on the terminal device which all access the management tree for storing, managing and/or retrieving configuration data and settings. Especially, each further function added to the electronic device or application implemented into the electronic device results in an increasing of the total hierarchical structure of the management tree causing a more complicated hierarchical structure. The kind and number of functions and/or applications for improving the operation of the terminal devices is unknown. But it is desired to maintain the introduced hierarchical management tree for storing, retrieving and/or managing configuration data and settings even for future use.

An object of the invention is to provide a method for defining and adding at least one object of a hierarchical object structure constituted by a plurality of individual objects, wherein the hierarchical object structure describes a management tree of an electronic device such that the resulting management tree is structured as efficient and future proofed as possible. An efficient structured management tree provides an efficient management and retrieval of one or more certain management objects for managing, retrieving their contents. Moreover, an efficient structured management tree also takes the limited resources (memory, processing capability etc.) into consideration. The method for defining and adding of one or more objects to be included in the hierarchical object structure, in particular a management tree, is based on a couple of definition rules and regulations the consideration of which results in such an efficient and optimized structured management tree.

The objects of the invention are achieved with a method for adding at least one object into a hierarchical object structure, corresponding systems and device adapted to perform this method, computer programs and software tools which are disclosed in the independent claims. Preferred embodiments of the invention are disclosed in the dependent claims.

According to an embodiment of the invention, a method for adding at least one object into a hierarchical object structure is provided. The hierarchical object structure is constituted by a plurality of objects. The objects are hierarchically associated to each other. The hierarchical association of the objects is obtained by using at least two different types of object, a first object type and a second object type. Both the first object type and a second object type are allowed to have subordinately arranged objects being associated directly therewith. The at least one object is defined to be associated to a parent object which will be arranged superordinately to and directly associated with the at least one object, i.e. the at least one object to be defined is a child object of the parent object. The parent object is part of the hierarchical object structure. The object type of the parent object is obtained to be compared with the object type of the child object to be defined. In case the object types of both the parent object and the at least one child object agree with each other and both object types match with the first type, an object having the second object type is interposed between the parent object and the child object. The separation ensures, that objects having the first object type are always separated in their hierarchical arrangement by at least one object having the second object type.

According to an embodiment of the invention, the at least two different object types comprises a run-time object type and a fixed object type. The aforementioned first object type corresponds to the run-time object type and the aforementioned second type corresponds to the fixed object type.

According to an embodiment of the invention, at least following object types are suitable for being applied: the fixed object type, run-time object type and leaf object type.

Each object having any one of the aforementioned object types has one directly associated object being arranged superordinately which is denoted as parent object. But objects having fixed object type or run-time object type are allowed to have none, one or more objects being directly associated therewith and being arranged subordinately thereto. The different object types allow to form the hierarchical object structure constituted by a plurality of objects each having one of the described object types.

Accordingly, the aforementioned method for adding at least one object according to an embodiment of the invention may be described alternatively in the following way. The at least one object is defined to be associated to a parent object. The object type of the parent object is obtained to be inspected. In case object type of the parent object is the fixed object type, the at least one object is allowed to have either the fixed object type, the run-time object type or the leaf object type. In case the object type of the parent object is the type run-time object type, the at least one object is allowed to have either the fixed object type or the leaf object type.

The defining of the at least one object may further require a defining of object properties. The object properties may comprise one or more properties out of a group comprising AccessType, DefaultValue, Description, DFFormat, Occurrence, Scope, DFTitle and DFType. The possible object properties is not limited to the presented ones, further different object properties may be also valid. According to an embodiment of the invention, it is further examined if the parent object has already one or more directly arranged objects being associated subordinately. In case there are existing already one or more objects, the one or more object types of these one or more objects are determined and the obtained one ore more object types are compared with the object type of the child object to be added to the hierarchical object structure. In case it is proved that at least one of the obtained one ore more object types and the object type of the child object have all the first object type (i.e. run-time object type), the child object is added to the parent object under the condition that the child object and the at least one already existing object have a common format.

The format of an object shall define which kind of management related information is allowed and/or suitable for being distributed among the respective object and hierarchically arranged objects being associated subordinately with that respective object. Objects having a common format define that similar management related information being associated with the same device function and/or device application is distributed among these objects and subordinately arranged objects.

According to an embodiment of the invention, the object type of the parent object is determined. Further it is checked whether the parent object has already one or more child objects. In case that the parent object has not any child objects and the parent object and the at least one object to be defined have both the second object types, the parent object and the at least one object are concentrated to a single object having the second object type. The concentrating is performed by replacing the parent object and the at least one object with the single object.

According to an embodiment of the invention, at least a part of a description document is coded in accordance with the at least one object being defined. At least the part of the description document being coded comprises information relating to the at least one object and the properties of the at least one object being defined previously. The coded description document allows to obtain a hierarchical object structure for storing the management related information of an electronic device being distributed among the plurality of objects comprised in the hierarchical structure. The obtaining of one or several objects and at least a part of the hierarchical object structure may be performed by parsing the coded description document or one or more relevant part(s) thereof, respectively.

According to an embodiment of the invention, the hierarchical object structure comprising a plurality of objects describes a hierarchical management structure. The hierarchical management structure may be understood as the hierarchical framework of a database within which in accordance to the hierarchical structure management related information of an electronic device, especially, of a mobile communication terminal is stored. Certain parts of the management related information being configuration data and/or settings, are associated with or included in at least one of the objects,

According to an embodiment of the invention, the format of an object defines which kind of management related information is allowed and/or suitable for being distributed among the respective object and hierarchically arranged objects being associated subordinately with that respective object. Objects having a common format define that similar management related information being associated with the same device function and/or device application is distributed among these objects and subordinately arranged objects.

According to an embodiment of the invention, the hierarchical object structure comprising the plurality of objects corresponds to a device description framework (DDF) information and/or the hierarchical object structure comprising the plurality of objects corresponds to a management tree employed for device management of an electronic device. The device description framework (DDF) information and/or the management tree are provided and standardized by the SyncML Initiative in form of the synchronization markup language device management (SyncML DM) standard.

According to an embodiment of the invention, the description document corresponds to a device description framework (DDF) document. The DDF document is an extended markup language (XML) encoded document being encoded in accordance with a corresponding description framework document type description (DTD). The extended markup language (XML) is not limited to the below presented clear (plain) text XML encoding but shall cover also binary encoding being based on XML and the like.

According to an embodiment of the invention, a software tool for adding at least one object into a plurality of objects establishing a hierarchical object structure is provided. The software tool comprises program portions for carrying out the operations of the aforementioned methods according to any embodiment of the invention when the software tool is implemented in a computer program and/or executed.

According to an embodiment of the invention, there is provided a computer program for adding at least one object into a plurality of objects establishing a hierarchical object structure. The computer program comprises loadable program code portions for carrying out the operations of the aforementioned methods according to any embodiment of the invention when the program is executed on a processing device, a computer or a network device.

According to an embodiment of the invention, a computer program product is provided which comprises program code portions stored on a computer readable medium for carrying out the aforementioned methods according to any embodiment of the invention when said program product is executed on a processing device, a computer or network device.

According to an embodiment of the invention, computer data signal is provided. The computer data signal is embodied in a carrier wave and represents a program or program code portions which, when executed by a processor, causes the aforementioned methods according to any embodiment of the invention be carried out.

According to an embodiment of the invention, a processing device comprising a processing unit, a memory unit and a communication interface is provided. The processing unit is coupled to the memory unit and the communication unit allowing for exchanging data in-between them. The processing unit of the processing device is configured allowing for adding at least one object into a hierarchical object structure. The hierarchical object structure is constituted by a plurality of objects. The objects are hierarchically associated to each other. The hierarchical association of the objects is obtained by using at least two different types of object, a first object type and a second object type. Both the first object type and a second object type are allowed to have subordinately arranged objects being associated directly therewith.

The at least one object is defined to be associated to a parent object which will to be arranged superordinately to and directly associated with the at least one object, i.e. the at least one object to be defined is at least one child object of the parent object. The parent object is part of the hierarchical object structure. The object type of the parent object is obtained to be compared with the object type of the at least one object to be defined. In case the object types of both the parent object and the at least one child object agree with each other and both object types match with the first type, an object having the second object type is interposed between the parent object and the at least one object. The separation ensures, that objects having the first object type are always separated in their hierarchical interdependency by at least one object having the second object type.

According to an embodiment of the invention, the processing device is further configured allowing for operating any one of the aforementioned embodiments of methods for adding at least one object into a hierarchical object structure. According to an embodiment of the invention, a management system is provided which comprises a processing device such as a managed client device or a management server device and a hierarchical object structure. The hierarchical object structure is constituted by a plurality of objects being hierarchically associated. Each object of the plurality of objects has a certain object type which is at least two object types, a first object type and a second object type, are applicable. Each object which has the first object type or the second object type is allowed to have directly arranged objects being associated subordinately therewith.

Each two objects which are arranged hierarchically to each other, which are associated with each other and which have both the first object type are separated by at least one interposed object having the second object type in the hierarchical structure. That is, hierarchically associated objects having the first object type are not allowed to be directly arranged to each other.

The processing device includes at least one management component which is capable to generate at least a part of a hierarchical object structure. The hierarchical arrangement of the hierarchical object structure is mapped thereby to the hierarchical arrangement of the resulting at least part of the hierarchical object structure. The hierarchical object structure serves for retrieving and storing and managing management related information of a managed mobile communication enabled device.

According to an embodiment of the invention, the at least two different object types comprises a run-time parent object type and a fixed parent object type. The aforementioned first object type corresponds to the run-time parent object type and the aforementioned second type corresponds to the fixed parent object type.

According to an embodiment of the invention, at least following object types are suitable for being applied: the fixed parent object type, run-time parent object type and leaf object type.

Each object having any one of the aforementioned object types has one directly associated object being arranged superordinately which is denoted as parent object. But objects having fixed parent object type or run-time parent object type are allowed to have none, one or more objects being directly associated therewith and being arranged subordinately thereto. The different object types allow to form the hierarchical object structure constituted by a plurality of objects each having one of the described object types. According to an embodiment of the invention, two or more objects which have the first type and which are directly arranged to an object being associated superordinately therewith have a common format. The format of an object shall define which kind of management related information is allowed and/or suitable for being distributed among the respective object and hierarchically arranged objects being associated subordinately with that respective object. Objects having a common format define that similar management related information being associated with the same device function and/or device application is distributed among these objects and subordinately arranged objects.

According to an embodiment of the invention, two directly arranged objects being associated with each other and having both said first type, i.e. a parent object and a child object both having the second type are substituted in the hierarchical object tree with a concentrated object having the second object type. The concentrated object is built of the two replaced objects. That is, the hierarchical object structure comprises a concentrated objects which has been from the above described two directly arranged objects such that an direct arrangement of a parent object and its only child object (both being of the second type) do not occur in the hierarchical object structure.

According to an embodiment of the invention, the processing device is a managed mobile communication enabled device comprising at least a client device management component, i.e. a client management agent, and a storage component. The client device management component allows to generate the at least part of the hierarchical object structure, to establish the part of the hierarchical object structure and to implement the at least part of the hierarchical object structure into the storage component of the managed mobile communication enabled device. The implementing may be an implementing of the generated at least part of the hierarchical object structure into a present existing hierarchical object structure for dynamically extending the hierarchical object structure. The client device management component further is capable to distribute management related information among the plurality of object constituting the hierarchical object structure and to retrieve at least parts of the management related information from one or more object of the plurality of objects for configuring functions of the device and/or applications operable with the device.

According to an embodiment of the invention, the processing device is a management server device comprising at least a server device management component, i.e. a server management agent and/or service management engine, and a communication interface. The server device management component allows to generate the at least part of the hierarchical object structure, to generate one or more management messages including management instructions and corresponding management related data in accordance with the generated at least part of the hierarchical object structure. The server device management component further is capable to transmit the obtained one or more management messages in conjunction with the communication interface to a managed mobile communication enabled device.

The one or more management messages may instruct the managed mobile communication enabled device to extend its stored hierarchical object structure dynamically in accordance with the transmitted management information, to distribute management related information provided by the server device among the certain objects of the hierarchical object structure, to retrieve management related information from certain objects of the hierarchical object structure being identified (addressed) by the means of address information gained from the generated at least part of the hierarchical object structure and the like.

Invention will be described in greater detail by means of embodiments with reference to the accompanying drawings, in which

Fig. la shows a schematic diagram illustrating a set of exemplary electronic devices between which synchronization of information can be operated; Fig. lb shows an example overall part of a management tree; Fig. 2a shows a table illustrating elements used for graphical notation of objects of the device description framework;

Fig. 2b shows a table illustrating special characters used additionally for graphical notation of objects of the device description framework; Fig. 3a shows a first arrangement of description objects according to an embodiment of the invention; Fig. 3b shows a second arrangement of description objects according to an embodiment of the invention; Fig. 3c shows arrangements of description objects to be avoided according to an embodiment of the invention; Fig. 3d shows an arrangement of description objects to be concentrated to a single description object according to an embodiment of the invention;

Fig. 3e shows an arrangement of description objects to be avoided according to an embodiment of the invention; Fig. 4a shows a first flow chart illustrating the defining of a description object according to an embodiment of the invention; Fig. 4b shows a second flow chart illustrating a defining and creating, respectively, of at least a part of a DDF document in accordance with an embodiment of the invention; Fig. 4c shows a third flow chart illustrating the parsing and generating of at least a part of a management tree being based on a DDF document according to an embodiment of the invention; Fig. 5a shows an example excerpt of a graphical depiction of a device description framework according to an embodiment of the invention;

Fig. 5b shows a first part of an excerpt of a DDF document corresponding to the graphical depiction shown in Fig. 5a and according to an embodiment of the invention; Fig. 5c shows a second part of the excerpt of the DDF document shown in Fig. 5b according to an embodiment of the invention;

Fig. 5d shows an example excerpt of a graphical depiction of a management tree in accordance with the graphical depiction of a device description framework illustrated in Fig. 5 a according to an embodiment of the invention; and Fig. 6 shows a block diagram illustrating devices containing components for operating the aforementioned methods according to embodiments of the invention.

In the following, the embodiments of the invention will be described with respect to a system supporting the SyncML device management standard or the related SyncML standard without limiting the invention thereto. Information about the SyncML standard and the SyncML device management (SyncML DM) standard can be obtained from the SyncML Initiative providing publicly the full standard documentation. Same or equal parts, features and/or operations shown in the figures will be referred to using the same reference numerals.

Fig. 1 shows a schematic diagram illustrating a set of exemplary electronic device between which synchronization of information can be operated. A certain database content of preferably mobile terminals shall be harmonized with database content provided by designated devices. Conventionally, mobile terminals act as synchronization clients harmonizing or synchronizing certain pre-defined data with the contents of a database or several databases provided by dedicated server devices. Fig. 1 illustrates a plurality of possible client devices and server devices for the synchronization operation. Typically, client devices are mobile stations like mobile phones 17 or personal digital assistants (PDA), mobile computers like notebooks 15, digital cameras 16 or personal computers (PC). Further, dedicated synchronization server devices may be desktop computers like a personal computer 10, a dedicated network server 11 or even a mobile computer like a notebook 12. It shall be noted that the client device functionality is not limited to mobile terminals as described above although the presented concept of synchronization is described in view of mobile terminals connected to dedicated serving devices. A corresponding synchronization process in accordance with the SyncML protocol standard or the SyncML device management protocol standard, respectively, may be established via an appropriate logical communication connection. The logical communication connection may be provided by any communication networks in combination with transport protocols to which the synchronization protocol is adapted. A suitable communication network may be a local area network (LAN), a wide area network (WAN) which may comprise the internet and an intranet of a company but also wire-based serial networks such as universal serial bus (USB) or standardized serial communication (e.g. RS-323). The participating synchronization devices may be also connected via a wireless communication network such as a mobile network supporting global system for mobile communication (GSM) services and/or supporting general packet radio services (GPRS), a third generation mobile communication network such as a universal mobile telecommunication system (UMTS) network, a wireless local area network (WLAN), a Bluetooth network or an infrared network (IrDA). The logical communication connection between the participating synchronization devices may be provided by a single communication network of the aforementioned type but also may be provided by several communication networks of the aforementioned types interconnected by dedicated network routing devices.

With respect to the SyncML protocol standard the SyncML synchronization protocol and hence also with respect to the SyncML device management protocol standard the SyncML device management protocol can be implemented on the top of appropriate protocols in accordance with the type of employed communication network. Appropriate protocols on top of which the SyncML synchronization protocol may be implemented are the hyper text transfer protocol (HTTP), the wireless session protocol (WSP) of the wireless application protocol (WAP) standard, wireless datagram protocol (WDP), the object exchange protocol (OBEX) used for cable connections, such as universal serial bus (USB) or RS-232, for short-range radio frequency connections (Bluetooth) or for infrared connections (IrDA), the transport control protocol/internet protocol (TCP/TP) stack and on top of the transport layer service which is offered by the e-mail protocol (e.g. simple mail transfer protocol, SMTP).

Transfer at the lower layer can be performed according to the underlying network using e.g. short messages SMS (short message service) or other signaling type transmission methods (e.g. USSD; unstructured supplementary service data), circuit-switched data calls or packet-switched data transfer services. Whereas the description above referred to a general synchronization and therefore also to the device management synchronization, the following description of the innovative concept will refer explicitly to the SyncML DM protocol.

The SyncML DM service itself is based on the exchange of a management document, which may be divided into a plurality massages or packages, respectively, comprising instructions in order to synchronize the device management data, i.e. the configuration data and settings. SyncML DM protocol comprises two parts: setup phase comprising authentication and device information exchange and management phase. Management phase can be repeated as many times as the server wishes.

Management phase consists of a number of protocol iterations, i.e. protocol iteration means a package from managed client device to management server and a package from management server to managed client device. Content of package sent from the management server to managed client device determines whether the session must be continued or not. If the management server sends management operations in packages that need responses (status or results) from the managed client device, the management phase of the protocol continues with new package from managed client device to management server containing client responses to management operations. Response package from managed client device starts new protocol iteration. The management server can send new management operation package and therefore initiate new protocol iteration as many times as it wishes.

An exemplary and valid total sequence of packages in accordance with the setup phase and the management phase is described in the following section in order to provide a coarse overview of the package exchange.

Package 0 - initiation of the management session: Most managed client devices can receive unsolicited messages, sometimes called "notifications". A management server can use this notification capability to cause the client to initiate a connection back to the management server. several bearers can be used for transmitting management initiation notifications. Note that an identical effect to receiving a management initiation notification can be caused in other ways.

Package 1 - initialization from managed client device to management server: The purpose of the initialization package sent by the managed client device is: - to send managed client device information (like manufacturer, model etc) to a device management server, to identify the managed client device to the management server, - to inform the server whether the management session was initiated by the server (by sending a trigger in Package 0) or by the client (like end user selecting a menu item).

Package 2 - initialization from management server to managed client device: The purpose of the initialization package sent by the management server is:

- to identify the device management server to the managed client device,

- to send optionally management commands and management data to the managed client device,

- to send optionally further commands like user interaction commands.

Packages 1 and 2 are part of the setup phase of the management process. Following packages 3 and 4 are part of the management phase of the management session.

Package 3 - managed client device response to management server: The purpose of this management package is:

- to transmit results of the management commands sent from the management server to the managed client,

- to transmit results of optional user interaction commands.

Package 4 - further management server operations: The purpose of this management package is:

- to transmit any further necessary management operations or commands from the management server to the managed client, respectively, or

- to close the management session.

A package 4 containing further management operations causes a response of the managed client device in kind of a package 3. Hence, the management session can comprise an arbitrary number of iterations of the packages 3 and 4.

The aforementioned SyncML DM service being based on management message exchanges in accordance with the above described phases and packages, respectively, takes actions against objects constituting the management tree which structures and contains information to be managed, respectively. The management tree is a well-defined hierarchical structured arrangement of all available and used management entities, wherein the position and correspondingly its addressing of certain information contained in a certain management entity reflects the content of the management information, respectively. In view of the above described broad definition of databases, the management tree may be understood as a database for storing configuration data and settings in a well-defined hierarchical organization. The position of management related information within the management tree is correlated with a certain device function and/or device application employing the respective management related information for operation, respectively. This well-defined hierarchical structure is referred to as management tree. The hierarchical organization of the management objects primarily addresses the need for providing an adequate and unique addressing scheme for each single management object corresponding to the hierarchical structured arrangement. A specific superordinate object, the root entity, provides the origin of all hierarchically arranged management objects, i.e. the root object of the management tree is that object relative to which the management objects are arranged.

Different kind of management objects are distinguished. The hierarchical object structure, in particular the management tree, comprises interior objects, in the following also denoted as (interior) nodes, and leaf objects. The leaf objects may be further distinguished between leaf objects which are allowed to include any but pre-defined contents and link objects, which include address information of a certain object within the hierarchical object structure. An interior object or an interior node represents an entity used for associating one or several dependent objects thereto, i.e. represents a hierarchically structuring entity having one or several but in a certain manner predetermined number of directly (immediately) associated objects being hierarchically arranged subordinately, which will be denoted as one or more child objects or child nodes being associated with and arranged to a parent object or parent node, respectively. Each interior object or interior node itself is associated to one superordinate interior object or interior node or the root object/node which is the interior object or interior node having the highest hierarchical level. Based on this inter-concatenation the hierarchical object structure, i.e. the management tree, is set up. The interior objects are further distinguished between permanent interior objects and into dynamic interior objects. As the naming "permanent" indicates, permanent objects are always present in the management tree independently from any operational state of the managed client device or application(s) running, whereas the dynamic objects may be added, replaced, modified and/or deleted by the managed client device or the management server corresponding on the need of information being contained in the hierarchical structure (dynamic part of the management tree) being associated with such a dynamic object.

A leaf object is associated to a superordinate interior object but allows no association of subordinate objects, i.e. have no associated child object(s). Instead leaf objects are employed as container for including certain content of any but pre-defined content type, i.e. may include a certain content, value(s) etc. such like integer values, larger values (plain text, array of values), complex data types, pictures and program code. The leaf objects include the configuration data and/or settings required for device and/or application operation. Leaf objects represent the "end"- objects of branches of the management tree, i.e. the lowest hierarchical level of the respective branches of the management tree.

Fig. lb shows an example part of a management tree as implemented in a managed client device, e.g. a mobile communication device. The example part of the management tree comprise the root object "/" emerging from which the management tree is set up. Herein the depiction of the example part of the management tree is limited to a highest level structure. Subordinate to the root object, there are depicted a device description framework (DDF) object, a device information (Devlnfo) object, a device detail information (DevDetail) object and an example object AP which all represent interior objects allowing for arranging subordinately further objects thereto. The number of objects associated to the root object (root node) "/" is not limited to the depicted ones, these are just for example illustration, i.e. non, one or more additional objects may be associated subordinately with the root object "/". The objects DDF, Devlnfo and DevDetail represent a selection of mandatory objects (but not limiting thereto) for a managed client device allowing to operate with SyncML device management service. The DevDetail object and the DevDetail object are interior objects which means that an unlimited number of further interior objects and leaf objects (and link objects) are arranged subordinately thereto. The management tree may be set up at a switching on of the managed device clients. Adaptations and/or modifications of the management tree may be operated in accordance with the above described exchange of management information corresponding to the SyncML device management service.

Each object and hence each information contained in a certain object is addressable. The addressing of a certain object is based on a instance identifier. Instance identifiers are assigned to each object of the management tree. At assigning instance identifiers to objects it is to be considered that the addressing of each object has to be unique. That means, an interior object may have one or more directly associated subordinate objects (interior objects, leaf objects, link objects). In order to obtain a unique addressing for each object within the management tree the instance identifiers of these directly associated subordinate objects have to differ to each other. An address information comprises all instance identifiers originating from the root object to the object to be addressed, which are passed by following the hierarchical structure of management tree. A adequate delimiter separates the respective instance identifiers.

The concept of the management tree is provided to a broad number of managed client devices implementing different functions and/or to a managed client devices operation a board number of different application which are not identical, which means that the managed client device are not describable with the same structure of the management tree and consequently the behavior of the managed client devices in view of the SyncML device management service differ. This problem is addressed by the device description framework (DDF). The usage of the device description framework (DDF) allows a manufacturer of a managed client device for providing information describing the management tree in all its different dynamic (run-time) representations such that the managed client device is capable to be managed by a management server being based on the SyncML device management service. The device description framework (DDF) should be embodied in such a way that it is applicable in a flexible and easily expandable way and also covers future demands to the management tree. The device description framework (DDF) is an abstract description of the objects. Consequently the management tree itself is derivable from the device description framework (DDF), wherein the device description framework (DDF) allows for deriving a broad number of individual management tree structures all valid for use with the corresponding managed client device and adapted to different situations. Therefore, the device description framework (DDF) comprises description objects allowing for deriving objects (permanent/dynamic interior objects, leaf objects and link objects), their properties and their concatenation (association, arrangement within the management tree). The description objects of the device description framework (DDF) include therefore definitions describing in detail information required for setting up the objects and consequently the management tree, respectively, in a valid manner. The description objects of the device description framework (DDF) reflect the hierarchical object structure and acts as a template hierarchical structure of a resulting management tree.

The inventive concept of the present invention relates to rules and regulations which are to be applied during defining and adding of objects described in the device description framework (DDF) such that the above mentioned proclaimed advantages are achieved.

The description of the management tree and the corresponding device description framework (DDF) will be given in reference to graphical depictions.

Fig. 2a shows a table illustrating elements used for graphical notation of object distinguished by their object types. The illustrative representation is compared with the meaning (object type) of the object. Corresponding to the objects available for forming a management tree, the table comprises a fixed (parent) object type, a run- time (parent) object type and a leaf object type. Herein a further object type is presented, a link object type. As aforementioned, the link object type is a specific leaf object type which stores addressing information of a certain different object within the hierarchical object structure, i.e. the link object type defines a leaf object type which includes a link value which is a plain text value to code a uniform resource indicator (URI) or any similar or related addressing value. A fixed parent object having the fixed parent object type is represented by a rectangular containing a title representing the instance identifier, herein replaced with the word "Fixed", a run-time object having the run-time object type is represented by a rectangular having rounded comers and containing a title, herein replaced with the word "Run-Time", a leaf object having the leaf object type is represented simply by its title representing the instance identifier, herein replaced with the word "Leaf, and finally a link object having the link object type is represented simply by its title being bold styled and underlined and representing the instance identifier, herein replaced with the word "Link".

The title (i.e. the instance identifier) of an object is one property element, designated as NodeName element, of the description objects. As aforementioned, an object is identifiable by its NodeName element, which has a predefined value (fixed object) or a dynamic assigned value (run-time object). Further property elements must or may be contained: AccessType, DefaultValue, Description, DFFormat, Occurrence, Scope, DFTitle and DFType. The presented list of property elements is just for example and it is to be understood as not limiting thereto. The AccessType element specifies which commands are allowed on the object (which actions are allowed to be taken against the object) and must be defined. Possible specifications for the AccessType element are Get, Delete, Add and Replace. The DefaultValue element defines optionally the object value to be used in a device unless the object value is not specifically set to a different value. The Description element defines an optional human readable description of the object. The DFFormat element defines a mandatory data format of the object. The Occurrence element specifies optionally the number of instances that may occur of that object within the management tree, i.e. specifically the number of child objects being arranged directly to associated subordinately with one parent object. The Scope element specifies optionally whether this object describes a permanent or dynamic object. The DFTitle element defines an optional human readable name of the object. The DFType element defines for leaf objects the MIME type (multipurpose internet mail extension type) of the object value and for interior objects null or a DDF document name.

The fixed parent object represents a permanent or a dynamic interior object. The title of the parent object is fixed and used as instance identifier in the management tree. In case the Occurrence of the fixed parent object may be one (One), the corresponding interior object is a permanent interior object, i.e. the Scope is permanent, whereas in case the Occurrence of the fixed parent object is none or one (ZeroOrOne) the Scope of the fixed parent object is dynamic such that the interior object can be created and deleted at run-time by a management server.

The run-time (parent) object represents a dynamic interior object. The title of the run-time object is not fixed, i.e. the name of a dynamic interior object is defined dynamically at run-time during its creation and is used as instance identifier in the management tree. The dynamically defined instance identifier may comprise any sequence of alphanumeric characters (max. 9 characters). In the following the title of a run-time object will be represented by <X> or <Y>.

The titles of the leaf object and the link object are fixed, respectively. The content type of the content included in the leaf object has to be specified, i.e. its MIME type, whereas the content type of the link object specifies a content type of the corresponding leaf object for coding an address information, for example a URI (uniform resource indicator).

In the following rules, regulations and methods presented in conjunction with objects having these certain objects types. The presented object type should not limit the object types thereto, since further object types may be included which do not interfere the inventive concept.

Fig. 2b shows a table illustrating special characters used additionally for graphical notation of objects. The table compares characters and their meanings. The characters represent the

Occurrence property element of an object. The Occurrence element specifies optionally the number of object instances that may occur thereof in the management tree. By default and in case no additional character is appended to the title of the object the occurrence of the corresponding object in the management tree is (exactly) one. The "+" sign appended to the title of the object indicates that the occurrence of the corresponding object in the management tree is once or may be also more times than once (Occurrence: OneOrMore, OneOrN). The "*" sign appended to the title of the object indicates that the occurrence of the corresponding object in the management tree is none or may be also more times than none (Occurrence: ZeroORMore, ZeroOrN). The "?" sign appended to the title of the description object indicates that the occurrence of the corresponding object in the management tree is none or once (Occurrence: ZeroOrOne).

The following Fig. 3 a to Fig. 3e illustrate rules and regulation to be applied and to be observed during the defining and adding of an object in the hierarchical object structure which will be embodied in the following Fig. 4a by the means of an example method for adding at least one object according to embodiments of the invention.

Fig. 3a shows a first arrangement of description objects according to an embodiment of the invention. This first arrangement includes a first fixed (parent) object "Node_l", one or more run-time (parent) objects <X> * and a second fixed (parent) object "Node_2". The one or more run-time objects <X> * are associated subordinately with the first fixed (parent) object "Node_l", whereas the second fixed parent object "Node_2" is associated subordinately with each of the one or more the run-time objects <X> *. Basing on the above described device description framework (DDF) structure and on the graphical definition of description objects, a resulting part of a management tree may comprises the first fixed parent object "Node_l" with the instance identifier "Node_l" and none, one or more run- time objects <X> *. The instance identifier(s) of these run-time objects <X> * are defined at run-time and may be for example "run-time 1", "run-time_2" and so on.

It may be assumed that one run-time object <X> * with an instance identifier "run-time 1" has been created (in accordance with the depiction). The run-time object "run-time 1" is associated subordinately with the fixed object "Node_l", i.e. the run-time object "run-time_ l" is a child object of the fixed object "Node_l". In accordance with the scope definition (Scope element) of the second fixed object "Node_2", the run-time object "run-time_ l" is be parent object to the fixed object "Node_2" or the fixed object "Node_2" is a child object to the run-time object "run- time_l".

It may be assumed that two run-time objects <X> * with the instance identifiers "run-time_l" and "run-time_2" has been created. The run-time objects "run-time_ l" and "run-time_2" are child objects to the fixed object "Node_l". And in accordance with the scope definition (Scope element) of the second fixed object "Node_2", the run-time object "run-time_l" is a parent object to the fixed object "Node_2" and in parallel the run-time object "run-time_2" is analogously a parent object to the fixed object "Node_2". The both child objects with the same instance identifier "Node_2" are distinguishable via their different dependencies (association, parent objects) within the management tree.

Fig. 3b shows a second arrangement of description objects according to an embodiment of the invention. This second arrangement includes a first fixed object "Node_3", one or more run-time objects <Y> +, a second fixed object "Node_4" and a leaf object "Leaf. The one or more runtime objects <Y> + are associated subordinately with the first fixed object "Node_3", whereas the second fixed object "Node_4" and the leaf object "Leaf l" are associated subordinately with each of the one or more the run-time objects <Y> +. The Fig. 3b illustrates the "simplest" situation, that means only one time object <Y> + which has two child objects, one fixed object "Node_4" and one leaf object "Leaf_l".

Basing on the above described device description framework (DDF) structure, a resulting part of a management tree comprises the first fixed object "Node_ 3" with the instance identifier

"Node_3" and at least one or more run-time objects <Y> + which are directly arranged to and associated subordinately with the first fixed object "Node_3", i.e. are child objects of the first fixed object "Node_3". The instance identifier(s) of these child objects are defined at run-time and may be referred analogously as for example "run-time_l", "run-time_2" and so on. Each of the run-time objects "run-time_l", "run-time_2", ... have two child objects, the second fixed object "NodeJ" and the leaf object "Leaf_l".

The structures described with respect to Fig. 3a and Fig. 3b represent device description framework (DDF) definition structure allowed for use. Contrary thereto, Fig. 3c shows arrangements of objects which are to be avoided in accordance with the rules and regulations of the inventive concept.

The first arrangement of description objects exhibits several first run-time objects <X> * in detail the occurrence of which is none, once or more times and several second run-time objects <Y> * in detail the occurrence of which is also none, once or more times. The depiction of Fig. 3c shows a concatenation of one first run-time object <X> * and one second run-time objects <Y> *. More generally, in case there exists one or more first run-time objects <X> * and one or more second run- time objects <Y> *, each of the first run-time objects <X> * is a parent object to one or several second run-time objects <Y> *, being child objects thereto. Consequently, each of the one or more first run-time objects <X> * being a parent object has a dynamical assigned instance identifier. Moreover, each of the one or more second run-time objects <Y> * being a child object has also a dynamical assigned instance identifier.

It is easy to understand, that such a hierarchical object structure which comprises consecutive directly arranged run-time objects with dynamical assigned instance identifiers in different hierarchical levels exhibits a complex structure which is hard to manage due to the lacking ability to identify objects easily especially in view of exploring the management tree.

As an overall rule for defining objects, a run-time object has to be associated subordinately with a fixed parent object and further this run-time object has to act as a parent object to at least one subordinately associated fixed object and/or a leaf object and/or a link object.

Fig. 3d shows an arrangement of objects to be concentrated to a single object according to an embodiment of the invention. The arrangement comprises two consecutive fixed objects, a fixed object "Node_5" and a fixed object "Node_6", wherein the only child object of the fixed object "Node_5" is the fixed object "NodejS". The stringing together of fixed parent objects in the described kind do not exhibit any useful information such that both the fixed object "Node_5" and a fixed object "Node_6" may be concentrated to a single fixed object "Node_5Node_6" which exhibits the same information. The concentration simplifies a resulting management tree in view of exploring the management tree and accessing object arranged subordinately with the concentrated fixed parent object "Node _5N ode _6" by simplifying e.g. their addressing.

Fig. 3e shows an arrangement of objects which is to be avoided according to an embodiment of the invention. The arrangement comprises a fixed object "Node_7" being associated directly to child objects, a first run-time object <X> * and a second run-time object <Y> +. The first runtime object <X> * and a second run-time object <Y> + each related to a different format of object. That means, the first run-time object <X> * and the second run-time object <Y> + further relate to different functions and applications, respectively. The format of an object shall define which kind of management related information is allowed and/or suitable for being distributed among the respective object and hierarchically arranged objects being associated subordinately with that respective object. Objects having a common format define that similar management related information being associated with the same device function and/or device application is distributed among these objects and subordinately arranged objects.

In order to obtain a manageable and clear management tree different type of run- time objects should not be associated subordinately with a common parent object (being a fixed object) such as shown in Fig. 3e. Rather, run-time objects of different format relating to different functions and applications of the managed client device, respectively, are to be associated to different parent objects (being a fixed object) to provide a clearly systematic, useable and manageable management tree.

Fig. 4a shows a first flow chart illustrating the defining of an object in accordance with an embodiment of the invention. The illustrated first flow chart represents an example embodiment taking into account the above illustrated and described rules and regulations, respectively, for defining objects and their properties and dependencies.

In an operation SI 00, the operational sequence according to an embodiment of the present invention for defining/adding at least one new object is started.

In an operation SI 10, the object type of the parent object is determined. The parent object to a new object can be a fixed object or a run-time object. In accordance to the rule and regulation described with reference to Fig. 3c, it is to be avoided that two run-time objects are arranged consecutively in the hierarchical object structure and device document framework (DDF), respectively. Correspondingly, it is checked whether the parent object is a run- time object or a fixed object. In case the parent object is of a run-time type the depicted operational sequence is continued with operation SI 40, ensuring that no consecutive run-time object can be defined and added. In case the parent object is of the fixed type the depicted operational sequence is continued with operation SI 20 allowing for associating any type of object to the parent object being a fixed object.

In an operation SI 20, it is checked whether a new run-time object is to be defined/added and in case it is the operational sequence continues with operation SI 30. Otherwise the operational sequence continues with operation SI 40.

In an operation SI 30, the new run-time object is defined. The defining involves an associating (or adding or including) of the new run- time object to the superordinately arranged parent object and the hierarchical object structure, respectively. In correspondence with the above described rules and regulations the superordinately arranged parent object is a fixed object. The defining of the new run-time object further may include the defining of further property elements comprising AccessType, DefaultValue, Description, DFFormat, Occurrence, Scope, DFTitle and DFType. After a complete defining of all necessary and required property elements and the adding of the new run-time object into the hierarchical object structure the operational sequence for defining a new object is continued with operation S200, where the operational sequence ends. Further new objects may be defined by starting again the described operational sequence.

In an operation S140, it is checked whether a new fixed object is to be defined and in case it is the operational sequence continues with operation SI 50. Otherwise the operational sequence continues with operation SI 60.

In an operation SI 50, the new fixed object is defined. The defining involves an associating (or adding or including) of the new fixed parent object to the superordinately arranged parent object and the hierarchical object structure, respectively. In correspondence with the above described rules and regulations the superordinately arranged parent object is either a fixed parent object or a run-time (parent) object. The defining of the new fixed parent object further may include the defining of further property elements comprising AccessType, DefaultValue, Description, DFFormat, Occurrence, Scope, DFTitle and DFType. After a complete defining of all necessary and required property elements and the adding of the new fixed parent object into the hierarchical object structure the operational sequence for defining a new object is continued with operation

S200, where the operational sequence ends. Further new objects may be defined by starting again the described operational sequence. In an operation S160, it is checked whether a new leaf object is to be defined and in case it is the operational sequence continues with operation SI 70. Otherwise the operational sequence continues with operation SI 80.

In an operation SI 70, the new leaf object is defined. The defining involves an associating (or adding or including) of the new leaf object to the superordinately arranged parent object and the hierarchical object structure, respectively. In correspondence with the above described rules and regulations the superordinately arranged parent object is either a fixed parent object or a run-time (parent) object. The defining of the new leaf object further may include the defining of further property elements comprising AccessType, DefaultValue, Description, DFFormat, Occurrence, Scope, DFTitle and DFType. After a complete defining of all necessary and required property elements and the adding of the new leaf object into the hierarchical object structure the operational sequence for defining a new object is continued with operation S200, where the operational sequence ends. Further new objects may be defined by starting again the described operational sequence.

In an operation SI 80, it is checked whether a new link object is to be defined and in case it is the operational sequence continues with operation SI 80. In the present invention four different types of objects are presented. Correspondingly, the checking operations S120, S140, SI 60 and SI 80 cover this four types. It should be noted that one or more further types of objects may be included into the device document framework (DDF). In accordance with the current situation in case new link object is not to be defined the operational sequence is continued with operation S200, i.e. the operational sequence ends without any new object definition. The operations of checking, defining and adding for one or more further types of objects may be implemented in the present operational sequence analogously to the checking, defining and defining operations described above with reference to the respective types of objects.

In an operation S190, the new link object is defined. The defining involves an associating(or adding or including) of the new link object to the superordinately arranged parent object and the hierarchical object structure, respectively. In correspondence with the above described rules and regulations the superordinately arranged parent object is either a fixed parent object or a run-time (parent) object. The defining of the new link object further may include the defining of further property elements comprising AccessType, DefaultValue, Description, DFFormat, Occurrence, Scope, DFTitle and DFType. After a complete defining of all necessary and required property elements and the adding of the new link object into the hierarchical object structure the operational sequence for defining a new object is continued with operation S200, where the operational sequence ends. Further new objects may be defined by starting again the described operational sequence.

In an operation S200, the operational sequence according to an embodiment of the present invention for defining/adding a new object is finished.

It shall be noted that alternatively to the presented operational sequence which ensures that runtime objects are not arranged consecutively in a hierarchical object structure, an operation of adding and interposing of a fixed object within two consecutively arranged run-time objects also fulfills this regulation. The interposing of a fixed object within the consecutive run-time objects prevents this consecutive arrangement and leads finally to the same resulting hierarchical object structure.

According to a further (improved) embodiment of the invention, the operational sequence also takes into account a checking of the object formats of run-time objects being already associated to the parent object to which the new object is to be directly associated as an additional client object. The corresponding rule and regulation is described in detail with reference to Fig. 3e, respectively.

In the operation SI 30, the existing "parallel" child objects of the parent object are determined. In case there are existing description child objects, it should be avoided that run-time objects of different formats are associated to the same parent object. In case a run- time object of different format is to be defined to be associated in parallel to an existing run-time object having a certain format the defining rejected and the operational sequence is continued with operation S200, i.e. the operational sequence ends.

According to a further (improved) embodiment of the invention, the operational sequence also takes into account a checking of the object types being already associated to the parent object to which the new object is to be directly associated as a/an (additional) client object. The corresponding rule and regulation is described in detail with reference to Fig. 3d, respectively.

In the operation S150, the existing "parallel" child objects of the parent object are determined. In case no "parallel" description child objects exists and the parent object is a fixed object, the new fixed object and the existing superordinately associated fixed parent object are concentrated into a new single fixed object replacing the parent object in order to simplify the hierarchical object structure and the device description framework (DDF), respectively. Fig. 4b shows a second flow chart illustrating a defining and creating, respectively, of at least a part of a device description framework (DDF) and DDF document in accordance with an embodiment of the invention. This operational sequence involves the operational sequence depicted in Fig. 4a according to an embodiment of the present invention.

In an operation S300, the operational sequence for creating a DDF document in accordance with the defining of new objects according to an embodiment of the invention is started.

In an operation S310, an object is defined. By default, the root object is existent, i.e. being the basis relative to which the device description framework (DDF) is structured and consequently the DDF document is built-up. The defining of an object in the operation S310 comprises the operations depicted in Fig. 4a and described in detail with reference thereto.

In an operation S320, the resulting defined new object is coded in the DDF document in accordance with the definitions having been performed in the operation S310. The coding of the DDF document may base on extended markup language (XML) coding. The XML coding is based on a type description provided in a corresponding document type description (DTD) defining the language elements of the XML encoding required for the DDF document. The XML encoding may be any suitable XML encoding such as a binary coded XML encoding.

In an operation S330, in case a further new object is to be added to the current device description framework and the DDF document, respectively, the operational sequence returns to the operation S310. Otherwise in case the current device description framework and the DDF document is complete, respectively, i.e. no further object is to be added thereto, the operational sequence continues with operation S340.

In an operation S340, the resulting device description framework and DDF document is stored in or may be transmitted to a management server and/or a managed client device, respectively, to be applied for establishing, generating, modifying etc. of a management tree. Moreover, the resulting device description framework and DDF document is processed for generating at least a part of a management tree, respectively. Such a processing of a device description framework and DDF document will be described below with reference to Fig. 4c, respectively.

In an operation S350, the operational sequence for creating a DDF document in accordance with the defining of new objects according to an embodiment of the invention is finished. It shall be noted, that the operation S310 of defining a new object and the operation S320 of coding the new object has been described as separated operations. It is to be understood, that both the operation S310 and the operation S320 may be embodied as a comprehensive operation, such that the defining and coding are operated simultaneously.

Fig. 4c shows a third flow chart illustrating the parsing and generating of at least a part of a management tree being based on a device description framework (DDF) and a DDF document, respectively, in accordance with an embodiment of the invention.

In an operation S400, the operational sequence for creating/generating at least a pert of a management tree being based on a device description framework (DDF) and a DDF document according to an embodiment of the invention is started, respectively.

In an operation S410, the device description framework (DDF) and the DDF document comprising the coded objects in correspondence to which objects of a management tree are to be generated is retrieved from a storage or may be received from a providing entity such as a device management server or a supporting server of the manufacturer of the electronic device, . For example, a device description framework (DDF) and a DDF document may be received by a managed client device from a management server or may be received by a management server from a DDF providing networked server. As aforementioned, the availability of the device description framework (DDF) and the DDF document, respectively, allows a processing device to generate valid and appropriate management tree structures and guaranties their applicability.

In an operation S420, the device description framework (DDF) and the DDF document, respectively, is parsed. The parsing may comprise an extracting of information and/or an interpreting of the information obtained by parsing. The parsing may be operated object by object as embodied herein or may be operated block-wise, i.e. may be operated by parsing a set of related description objects. The parsing of the device description framework (DDF) and the DDF document may further comprise an identifying operation, respectively, in order to parse/extract the required object(s) information from the total device description framework (DDF) and the DDF document, respectively.

In an operation S430, based on the information obtained by operation S420, one or several objects are generated. The generation of each object is performed in correspondence with the object information comprised in the device description framework (DDF) and the DDF document, respectively. The generated objects are included in the at least part of the management tree to be generated. The including of the new objects is performed under consideration of the hierarchical association defined in the device description framework (DDF) and the DDF document, respectively, in order to generate the at least part of a management tree with the correct hierarchical structure. Moreover the method for adding an object to a hierarchical object structure as embodiment with reference to Fig. 4a may be applied to ensure that (even in case the DDF document has not taken the aforementioned rules and regulation into consideration) the resulting hierarchical object tree (the management tree) meet the inventive rules and regulations.

If necessary, in the operation S430 one or more values are further assigned to the new generated object(s).

In an operation S440, in case the object information required is parsed/extracted object by object and the generation of the at least part of the management tree has not been completed, the operational sequence returns to the operation S420 for parsing/extracting a further required object information. Otherwise the generation of the at least part of the management tree is completed and the operational sequence continues with operation S450.

In an operation S450, the resulting at least part of the management tree generated is applied. The applying of the resulting at least part of the management tree may be an establishment of a management tree in a managed client device, an implementation of an additional branch into an existing management tree for adding additional configuration data or settings to the management tree required by one or more device functions and/or applications. Moreover, the resulting at least part of the management tree may have been generated by a management server and transmitted to a managed client to be implemented therein.

The applying of the resulting at least part of the management tree should been understood in conjunction with the above described SyncML device management service and the exchange of a management document.

In an operation S460, the operational sequence for creating/generating at least a part of a management tree in accordance with a device description framework (DDF) and a DDF document according to an embodiment of the invention is finished, respectively.

The following Fig. 5a will show a graphical depiction of an example part of a device description framework. The Fig. 5b and Fig. 5c show the corresponding DDF document and the Fig. 5d illustrate an example management tree which is in agreement with the example device description framework illustrated in Fig. 5a and coded in form of a document shown in Fig. 5b and Fig. 5c. Fig. 5a shows an example part of a graphical depiction of a device description framework according to an embodiment of the invention. The graphical depiction relates to the access point (AP) settings of a mobile data communication enabled client device. The graphical depiction shows a part of the relevant objects being based on that one or more branches of the management tree of the mobile data communication enabled client device are derived.

The access point settings are sub-summarized below a highest level interior object "./AP" directly associated to the root object "/", i.e. the object "./AP" is a child object of the root object "/" and is a parent object to all access point (AP) settings. Correspondingly, the depicted highest level object "./AP" defines a fixed parent object with the instant identifier "./AP". The fixed parent object "./AP" is associated to a run-time object <Xι> * arranged subordinately thereto. The runtime object <Xι> * allows to derive none, one or more corresponding interior objects with dynamically assigned instant identifiers being child objects of the corresponding interior parent objects "./AP". Each set of information relating to individual access point settings is stored in one of the management tree substructure below one of the run-time objects <Xι> *. The instant identifier of these run-time objects <Xι> * indicate preferably the kind of access point to which the individual access point settings relate.

Each one of the run-time objects <Xι> * is associated with a fixed object "Px", a fixed object "NAPDef ?", a leaf object "ClientID ?" and a fixed object "BS ?". These objects are allowed to occur not or exactly once in the management tree being arranged subordinately to each one of the run-time objects <Xj> *.

The fixed object "Px" is parent object to one or more run-time objects <X > *, the fixed object "NAPDef ?" is parent object to one or more run-time objects <X₃> * and the fixed object "BS ?" is parent object to a run-time object <X₄> *. Assuming that the fixed object "Px" is existing in the management tree the fixed object "Px" may have none, one or more run-time objects <X₃> *with dynamically defined instant identifiers. Analogously on assumption that a fixed object "NAPDef ?" is existing in the management tree the fixed object "NAPDef ?" may have none, one or more run-time objects <X₃> * and on assumption that the fixed object "BS ?" is existing in the management tree the fixed object "BS ?" may have none, one or more run-time objects <X₄> *. The further structures of the run-time objects <X₂> * and <X₃> * are omitted.

The run-time object <X > * has several child objects comprising among other for example a leaf object "Name ?", a fixed parent object "Network ?" and a leaf object "Country ?". In turn, the fixed object "Network ?" is associated to one or more run-time object <X5> + being arranged subordinately thereto. According to the definition of the run-time object <X5> + in case the fixed object "Network ?" is existing at least one or more run-time object <X₅> + are associated to the fixed object "Network ?" as interior child objects.

It can be seen, that run-time objects in the depicted structure are always separated by at least one fixed object and that a consecutive arranging of fixed objects has been avoided and that not different formats of run-time objects coexist as child objects of one superordinate (fixed/run-time object) parent object such that the depiction fulfills the above described rules and regulations, respectively.

The graphical depiction of the device description framework may be employed for obtaining a corresponding DDF document. The meanings of the graphical elements comprised by the graphical depiction may be translated into the corresponding DDF document to at least obtain a framework of the DDF document.

Fig. 5b shows a first part of an excerpt of a DDF document corresponding to the graphical depiction shown in Fig. 5a. Fig. 5c shows a second part of the excerpt of the DDF document shown in Fig. 5b. In the following, the Fig. 5b and Fig. 5c will be described together.

The following DDF document excerpts are based on an extended markup language (XML) encoding of the device description framework. The XML encoding is moreover based on a document type description defining tags for defining the objects and their properties in a manner such that the resulting DDF document is interpretable in a unique way. The XML encoding is one of a board number of possible encoding methods. The following DDF document is based on a document type description for device description framework provided by the SyncML Initiative.

Lines 001 to 007 include the header section of the DDF document. The header sections defines the XML encoding version (1.0), a character encoding (UTF-8), the version of the DTD to be considered (1.1), a manufacturer (Nokia) a model identification (omitted by comment) of the client device to which the DDF document relates.

In lines 008 to 018 the part of the XML encoded DDF document is comprises that is dedicated to the fixed object "AP", its position in the management tree relative to the root object "/" and the property elements of the fixed object "AP". In correspondence with the aforementioned properties of the fixed object "AP", a set of object property elements specify the properties thereof. In detail, the access is limited to read operations, the format of the object is set to node indicating an interior object, the occurrence is defined as one and the scope is permanent, Additionally, a human readable description and a human readable title are defined.

In lines 019 to 026 the run-time object <Xι> * is defined. A name is omitted, since the instance identifier of the run-time object is assigned at run-time. The object property elements specify the access to add, delete, get and replace, the format of the object is defined as node, the occurrence is none, one or more (ZeroOrMore) and the scope is dynamic. A human readable title is defined.

In lines 027 to 037 the fixed parent object "Px" is specified. The name is correspondingly defined as "Px". The object property elements specify the access limited to read operations (get), the format of the object is defined as node, the occurrence is one and the scope is dynamic. A human readable title is defined.

In line 036 omission marks indicate the position in the depicted DDF document at which the specification of the run-time object <X > * is to be included. The specification of the run-time object <X₂> * is performed analogously to the specification of run-time objects presented herein.

In lines 038 to 048 the fixed object "NAPDef ?" is specified. The name is correspondingly defined as "NAPDef. The object property elements specify the access limited to read operations (get), the format of the object is defined as node, the occurrence is none or one and the scope is dynamic. A human readable title is defined.

In line 047 omission marks indicate the position in the depicted DDF document at which the specification of the run-time object <X > * is to be included. The specification of the run- time object <X₃> * is performed analogously to the specification of run- time objects presented herein.

In lines 049 to 059 the leaf object "ClientlD ?" is specified. The name is correspondingly defined as "ClientlD". The object property elements specify the access to add, delete, get and replace, the format of the object is defined as character format (chr) being a certain leaf object, the occurrence is none or one and the scope is dynamic. A human readable title is defined. The leaf object contains information. The kind of information, i.e. the content type format of the data representing the information, has to be predefined. Therefore, the corresponding type element (DFType) comprises a MIME type definition of the content to be stored, herein a plain text information. In lines 060 to 069 the fixed parent object "BS ?" is specified. The name is correspondingly defined as "BS". The object property elements specify the access limited to read operations (get), the format of the object is defined as node, the occurrence is none or one and the scope is dynamic. A human readable title is defined.

In lines 070 to 077 the run-time object <X₅> * is defined. A name is omitted, since the instance identifier of the run-time object is assigned at run-time. The object property elements specify the access to add, delete, get and replace, the format of the object is defined as node, the occurrence is none, one or more (ZeroOrMore) and the scope is dynamic. A human readable title is defined.

The lines 078 to 088 the leaf object "Name ?" is specified. The name is correspondingly defined as "Name". The object property elements specify the access to add, delete, get and replace, the format of the object is defined as character format (chr) being a certain leaf object, the occurrence is none or one and the scope is dynamic. A human readable title is defined. The content type is specified by a MIME type definition as being plain text.

The lines 089 to 100 the fixed parent object "Network ?" is specified. The name is correspondingly defined as "Network". The object property elements specify the access limited to read operations (get), the format of the object is defined as node, the occurrence is none or one and the scope is dynamic. A human readable title is defined.

In line 098 omission marks indicate the position in the depicted DDF document at which the specification of the run-time object <X₅> * is to be included. The specification of the run-time object <X₅> * is performed analogously to the specification of run-time objects presented herein.

The lines 101 to 110 the leaf object "Country ?" is specified. The name is correspondingly defined as "Country". The object property elements specify the access to add, delete, get and replace, the format of the object is defined as character format (chr) being a certain leaf object, the occurrence is none or one and the scope is dynamic. A human readable title is defined. The content type is specified by a MIME type definition as being plain text.

In line 111 omission marks indicate the position in the depicted DDF document at which further objects associated to the run-time object <X₅> * are to be included.

The hierarchical structure of the device description framework shown accordingly by its graphical depiction in Fig. 5a is mapped to the device description framework and the DDF document, respectively, by encapsulating of the specifications presented and described above. Due to the employment of the device description framework and the DDF document, respectively, the hierarchical structure being realized by the encapsulations of the object specification represents a hierarchical template structure of the management tree being derived therefrom. Alternatively, instead of using encapsulating of specifications for defining the hierarchical structure, a path information may be added to object specifications. The path information specifies the position within the hierarchical structure of the corresponding object.

The specification range of the fixed object "./AP" covers the object specifications of subordinately arranged objects beginning in line 007 and ending with line 115 wherein the specification of the fixed object "./AP" itself is comprised in this encapsulation.

The specification range of the run-time object <Xι> * covers the object specifications of subordinately arranged objects beginning in line 018 and ending with line 114 wherein the specification of the run-time object <Xι> * itself is comprised in this encapsulation.

The specification range of the fixed object "Px" covers the object specifications of subordinately arranged objects beginning in line 027 and ending with line 037 wherein the specification of the fixed object "Px" itself is comprised in this encapsulation and the omission marks in line 036 indicate omitted object specifications being hierarchically arranged subordinate.

The specification range of the fixed object "NAPDef ?" covers the object specifications of subordinately arranged objects beginning in line 038 and ending with line 048 wherein the specification of the fixed object "NAPDef ?" itself is comprised in this encapsulation and the omission marks in line 047 indicate omitted object specifications being hierarchically arranged subordinate.

The specification range of the fixed object "BS ?" covers the object specifications of subordinately arranged objects beginning in line 060 and ending with line 113 wherein the specification of the parent object "BS ?" itself is comprised in this encapsulation.

The specification range of the run-time object <X₄> * covers the object specifications of subordinately arranged objects beginning in line 069 and ending with line 112 wherein the specification of the run-time object <X₄> * itself is comprised in this encapsulation and the omission marks in line 111 indicate omitted object specifications being hierarchically arranged subordinate. The specification range of the fixed object "Network ?" covers the object specifications of subordinately arranged objects beginning in line 089 and ending with line 099 wherein the specification of the fixed object "Network ?" itself is comprised in this encapsulation.

Fig. 5d shows an example excerpt of a graphical depiction of a management tree in accordance with the graphical depiction of a device description framework illustrated in Fig. 5a according to an embodiment of the invention. The presented management tree is constituted from a plurality of objects being derived from the corresponding objects and being associated with each other in correspondence with the defined hierarchical structure described by the device description framework.

The fixed object "./AP" represents in this depiction the object of the highest hierarchical level, i.e. the object "./AP" is directly arranged to and subordinately associated with the root object "/" of the management tree. The object "./AP" shall comprise management related information concerning the network access of an mobile communication terminal.

The object "./AP" has three child objects, i.e. objects which are directly arranged thereto and subordinately associated therewith, the object "Prov_l", object "Prov_2", object "Prov_3" and further objects. These objects are run-time objects corresponding to the aforementioned run-time object <Xι> *. In accordance with the aforementioned regulation for arranging run-time objects being child objects of a common parent, all these run-time objects have to serve for the same subordinate structure. The real subordinate structure of the run-time objects may differ, since directly and indirectly arranged and subordinately associated objects may be dynamical objects. But the run-time object "Prov_l", object "Prov_2" and object "Prov_3" are set up in such a way that they relate to the same functional or applicational management configuration information. Herein, the run-time object "Prov_l", object "Prov_2" and object "Prov_3" relate to configuration information of network service providers. The fixed object "./AP" serves to sub- summarize all management information concerning network service provider configuration information.

The run-time object "Prov_l" has two child objects, the object "Px" and the object "NAPDef.. In accordance with the aforementioned regulation for consecutively arranging run- time objects, the object "Px" and the object "NAPDef are both fixed objects . Corresponding to the occurrences defined for further possible directly arranged and subordinately associated objects, a leaf object "ClientlD" and a fixed object "BS" may be dynamically arranged as child objects to the object "Prov_l" but must not. Herein, none of these possible further objects are implemented in the management sub-tree of the object "Prov_l". The object "Px" relates to proxy configuration information of the network provider service "Prov_l" and the object "NAPDef relates to network access point definition configuration information of the network provider service "Prov_l".

The fixed object "Px" being arranged subordinately to object "Prov_l" has two child objects, a run-time object "Def_Px" and a run-time object "Px_l". Both the run-time object "Def Px" and the run-time object "Px_l" correspond tp run-time object <X₂> *. The object "Px" serves to sub- summarize all proxy configuration information of the network provider service "Prov_l". Further run-time objects are only allowed to be associated as child objects to the object "Px" if these further run-time objects also correspond to the definitions described under consideration of the run-time object <X > *, i.e. have the same (and a common, respectively) format.

The fixed object "NAPDef being arranged subordinately to object "Prov 1" has two child objects, a run-time object "NAP_Def and a run-time object "NAP_1". Both the run-time object "NAP_Def and the run-time object "NAP_1" correspond to the run-time object <X₃> *. The object "NAPDef serves to sub-summarize all network access point definition configuration information of the network provider service "Prov 1". Further run-time objects are only allowed to be associated as child objects to the object "NAPDef if these further run-time objects also correspond to the definitions provided by the run-time object <X > *, i.e. have the same (and a common, respectively) format.

In case of the run-time objects "Def Px" and "Px_l" the fixed object "Px" separates these runtime objects from the superordinately arranged run-time object "Prov_l" which corresponds to the aforementioned regulation for separating run-time objects. Analogously, in case of the run- time objects "NAP_Def and "NAP l" the fixed object "NAPDef separates these run-time objects from the superordinately arranged run-time object "Prov_l" which corresponds to the aforementioned regulation for separating run-time objects.

The fixed object "Prov_2" has three child objects, a fixed object "NAPDef, a leaf object "ClientlD" and a fixed object "BS". As the directly arranged and superordinately associated object "Prov_2" is of the run-time type, the parent object "NAPDef as well as the parent object "BS" have both the fixed object type.

The fixed parent object "NAPDef being arranged subordinately to object "Prov_2" has one child object, a run-time object "NAP_Def . The fixed object "BS" being arranged subordinately to object "Prov_2" has one child object, a run-time parent object "Boot". The object "BS" relates to bootstrap configuration information of the network provider service "Prov_2". In correspondence with the object <X₃> * the object "BS" has the child objects "Name" and "Country" both having leaf object type. Further child objects corresponding to the object <X₃> * may be associated to the object "BS".

Fig. 6 shows a block diagram illustrating devices containing components for operating the aforementioned methods according to embodiments of the invention. A server device management agent 220 represents a networked service that provides device management with another counterpart client device management agent 320. The device management data may be provided or processed by the server device management agent 220 or client device management agent 320, respectively. The server device management agent 220 is hosted by the server 20 which may be a server device corresponding with the server device mentioned with reference to Fig. 1. Analogously, the client device management agent 320 is hosted by the client 30 which may be a client device corresponding with the client device mentioned with reference to Fig. 1. The device management is performed between a server 20 and a client 30.

The server 20 and client 30 are connected over any network. The network provides a logical communication connection between the server 20 and client 30, allowing the establishment of the end-to-end communication during the device management which may be termed as device management session. A selection of logical connections and bearers thereof are described in Fig. 1.

The client 30 may use the client device management agent 320 in conjunction with the synchronization adapter 340 and synchronization interface 330 to access the network and send messages to the server via the synchronization adapter 340 and synchronization interface 330 in accordance to the SyncML DM protocol standard. The server 20 or server device management 220, respectively, receives or sends messages via the synchronization adapter 240 and synchronization interface 230, and manages the entire device management process through the server device management engine 210. Device management operations are conceptually bound into a device management frame, which is a conceptual frame for one or more required packages.

The server device management engine 210 has the possibility to access an adapted device management database 200 containing information about the client 30 to be managed such as configuration data and settings relating to certain client device functions or applications operable with the client 30 which are to be transmitted to the client 30 for allowing a user to use well- configured device functions and/or device applications. The device management database 200 may further contain the client related device description framework (DDF) information such as a DDF document defined and provided by the manufacturer for deriving at least a part of the management tree valid for the client device 30, a part of the management tree itself, information about the actual position within the management tree of the client 30 to be processed and further device management relevant information. Further, the server device management engine 210 of the server 20 is able to generate the device management documents exchanged with the client 30. This generation is possible since the DDF information (DDF document) enables the server 20 to code device specific management documents required for being exchanged with the client 30 in an appropriate manner such that the management related information are conform with the management tree implemented in the client 30. For example in case certain management related information shall be transmitted to the client for enabling a certain client function. This management related information shall further be distributed among a certain management tree sub-area (a certain branch) which is at first to be set up dynamically. The server 20 as well as the client 30 are known about the device description framework (DDF) 310 such that the dynamical extension of the management tree is operated in an adequate way which enables the server 20 to instruct the client the distribute transmitted management retailed information among the correct objects of the specific dynamic management tree sub-area and which enables the client 30 to manage and retrieve the dynamical implemented in a correct way which includes providing of this information to the corresponding device function and/or device application requiring it.

The counterpart client 30 is able to response to the management request employing the client device management agent 320. Especially, the client device management agent 320 has access to its device management tree 300 and its device description framework (DDF) 310 defining the hierarchical structure and objects of the management tree 300.

Both, the server 20 and the client 30 may use the DDF information (DDF document) stored therein in order to code action to be performed against management tree of the client 20. The DDF information (DDF document) allows to generate dynamic part(s) of the management tree required for storing new or dynamic management related information concerning the operation of the client 30. The generating of the part(s) of the management tree being based on the DDF information (DDF document) is operated by the server device management agent 220 and the client device management agent 320, respectively, depending in which device the modifications or adaptations of the management tree 300 are operated.

Primarily, the device description framework (DDF) is supplied by a manufacturer of a certain client device such as client 30 to a device management server such as server 20, such that the server is capable to operate the device management with this client by generating management actions such as described above in a client device appropriate way. Moreover, the DDF information (DDF document) being available to the client 30 allows the client for generating a management tree at switching on of the client 30 in case that no management tree is available for the client 30 up to now. The DDF information (DDF document) serves as mentioned above as a template representing and describing the management tree and the possible management trees in a common, extensible and flexible way, respectively.

The presented components of the server 20 or the client 30, respectively, the server device management agent 220, the server device management engine 210 and the device database 200 respectively, as well as the client device management agent 320 and the device management free 200, respectively, may be constituted by a data processing device which may be comprised by the server 20 or the client 30, respectively. Further these components may be constituted by a code section for executing on the server 20 or the client 30, respectively, containing instructions for carrying out the necessary processing operations.

It will be obvious for those skilled in the art that as the technology advances, the inventive concept can be implemented in a broad number of ways. The invention and its embodiments are thus not limited to the examples described above but may vary within the scope of the claims.