KR20050085093A - Method and device for defining objects allowing to establish a device management tree for mobile communication devices - Google Patents

Abstract

The present invention disclose an advantageous method for defining object to be included into a hierarchical structured device description framework (DDF). The device description framework (DDF) is constituted by a plurality of objects being hierarchically inter-associated to each other forming a kind of tree-like structure. The hierarchical structure is obtained by using different types of object comprising at least: fixed parent object, run- time parent object, i.e. parent object, whereas objects of the types fixed parent object and run-time parent object are allowed for having none one or more objects being directly associated subordinate, i.e. child objects. At least one new object is defined to be associated to a parent object. The object type of parent object is checked. In case the parent object is a run-time object, the at least one new object is allowed to be either fixed object or leaf object. Further, properties of the at least one object are defined. The device description framework (DDF) is employed for generating at least a part of a management tree comprising a plurality of objects among which management related information of an mobile communication enabled device is distributed.

Description

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 apparatus for adding objects to a hierarchical object structure that can establish a device management tree structure for defining objects and storing management related information of a mobile communication device. In particular, the present invention relates to a method of creating one or more objects in a management tree, which is a management tree that provides an efficient, explicit, manageable, desirable configuration and has a dynamic structure. The invention also relates to devices and systems suitable for operating the above-mentioned method.

Synchronization of data is a well known problem for all users who process the same data with at least two different electronic devices. In general, synchronization occurs between a terminal device (e.g., a mobile phone) and a server device (e.g., a dedicated synchronization server or an application on a local PC). The data of portable terminals, such as portable computers, personal digital assistants (PDAs), mobile stations or pagers, can be synchronized with network applications, applications of desktop computers or other databases of a communication system. The term database should be understood as broadly as possible. That is, it will contain arbitrary sets of data. In particular, the data of calendar and email applications is typically synchronized.

Synchronization is based on using different manufacturer specific protocols that are incompatible. This limits the use of terminals or data types and often causes problems for users. In mobile communications, it is particularly important that data can be retrieved and updated regardless of the terminal and application used.

In order to improve the synchronization of application data, known as synchronization markup language (SyncML) based on extensible markup language (XML) and corresponding standardized document type description (DTD). The language was developed. By using the SyncML synchronization protocol using messages with SyncML format, the data of any application between network terminals and some kind of network server can be synchronized. SyncML synchronization protocols operate on both wireless and fixed networks and support several transport protocols.

The SyncML synchronization technique presented above preferably deals with the synchronization of databases. A problem similar to the synchronization of databases is given by managing the settings and configuration data necessary for the operation of electronic devices in a changing environment. The electronic devices are for example configured of individual carrier related sets, for example network access point (NAP) definitions, proxy and gateway server addresses, information and definitions, short message service (SMS) Mobile phone operating in a mobile communication network of different network carriers that needs address information of servers providing certain services such as multimedia message service (MMS) and others of that kind. SyncML device management relates to the coordination of such configuration data and settings. Each configuration data and information is contained in managed objects associated with device characteristic (s) and operable application (s), respectively.

The SyncML device management (SyncML DM) protocol allows management commands to be executed on managed objects, uses a package format similar SyncML synchronization protocol and related definitions, and is also based on an associated XML encoding such as XML or binary encoded XML. . The management object may represent a set of configuration parameters for the device, that is, settings and configuration parameters of software applications running on the device and / or configuration parameters of the device characteristics. Operations that may be performed on such an object may include reading and setting parameter keys and values. Another managed object may be a run-time environment for software applications on the device. Actions that may be taken on this type of object may include installing, upgrading, or uninstalling software components. Preferably, dedicated management servers provide the necessary configuration parameters, settings, keys and values for the synchronization of the above mentioned device management information.

Device management in accordance with SyncML DM may organize managed objects in a hierarchical management tree containing all information that can be managed using the SyncML DM protocol. The management tree is based on a permanent part of the management tree provided and defined by the manufacturer of each electronic device supporting SyncML device management. The actual management tree provided by the operative electronic device includes a permanent portion of the management tree that is extended by one or more dynamically generated portions of the management tree. The actual management tree is described in some way from one kind of predetermined tree framework, the device description framework.

The hierarchical structure of the management tree, which includes the management information necessary to operate an electronic device of the type described above, manages to store, manage and / or retrieve the functions and configuration data and settings provided to the user by the terminal device. It is somewhat complex depending on the applications that are operable in the terminal device accessing the tree. In particular, each additional function added to the electronic device or application implemented in the electronic device results in an increase in the overall hierarchical structure of the management tree resulting in a more complex hierarchical structure. The number and type of applications and / or functions for improving the operation of terminal devices are not known. However, it is desirable to maintain a hierarchical management tree that is introduced to store, retrieve and / or manage configuration data and settings even for future use.

1A shows a schematic diagram illustrating a set of exemplary electronic devices with which information synchronization can be performed therebetween.

1B shows an exemplary overall part of the management tree.

2A shows a table representing elements used for graphical representation of objects of the device description framework.

2B shows a table representing special characters used in addition to the graphical representation of objects of the device description framework.

3A shows a first arrangement of description objects in accordance with one embodiment of the present invention.

3B illustrates a second arrangement of description objects in accordance with one embodiment of the present invention.

3C illustrates arrangements of description objects to be avoided in accordance with one embodiment of the present invention.

3D illustrates an arrangement of descriptive objects concentrated into a single descriptive object in accordance with one embodiment of the present invention.

3E illustrates arrangements of description objects to be avoided in accordance with one embodiment of the present invention.

4A shows a first flowchart illustrating the definition of a description object according to an embodiment of the present invention.

4B shows a second flow diagram illustrating defining and generating at least a portion of a DDF document in accordance with one embodiment of the present invention.

4C illustrates a third flow diagram illustrating analyzing and generating at least a portion of a management tree based on a DDF document in accordance with one embodiment of the present invention.

5A illustrates an exemplary excerpt of a graphical representation of a device description framework, in accordance with an embodiment of the invention.

5B illustrates a first portion of an excerpt of a DDF document corresponding to the graphical representation shown in FIG. 5A in accordance with an embodiment of the present invention.

5C illustrates a second portion of an excerpt of the DDF document shown in FIG. 5B in accordance with an embodiment of the present invention.

FIG. 5D illustrates an exemplary excerpt of a graphical representation of a management tree according to the graphical representation of the device description framework shown in FIG. 5A in accordance with an embodiment of the present invention.

Figure 6 shows a block diagram illustrating apparatuses comprising elements for performing the above-described methods according to an embodiment of the present invention.

It is an object of the present invention to provide a method for defining and adding at least one object of a hierarchical object structure comprising a plurality of individual objects. The hierarchical object structure describes the management tree of the electronic device, and the resulting management tree is configured to be as efficient and future as possible. An efficient structured management tree provides for the efficient management and retrieval of one or more certain managed objects in order to manage and retrieve the contents of the objects. Moreover, an efficient structured management tree also takes into account limited resources (memory, processing power, etc.). The method of defining and adding a hierarchical object structure, in particular one or more objects included in the management tree, is based on a pair of definition rules and regulations, and such considerations lead to an efficient and optimal structure of the management tree.

The objects of the present invention are achieved by a method of adding at least one object disclosed in the independent claim to a hierarchical object structure, corresponding systems and apparatus, computer programs and software tools suitable for carrying out the method. Preferred embodiments of the invention are disclosed in the dependent claims.

According to one embodiment of the invention, a method of adding at least one object to a hierarchical object structure is provided. The hierarchical object structure includes a plurality of objects. The objects are hierarchically related to each other. The hierarchical association of the objects is achieved by using at least two different types of objects, a first object type and a second object type. The first object type and the second object type allow to have objects arranged directly below.

At least one object is defined to be related to a parent object. The parent object is directly associated with and arranged above the at least one object. That is, the at least one object defined is a child object of the parent object. The parent object is part of a hierarchical object structure. The object type of the parent object is compared with the object type of the child object being defined. When the types of the at least one child object and the parent object match each other and the object types are all first types, an object having the second type is inserted between the parent object and the child object. This separation ensures that objects with a first object type are always separated in a hierarchical arrangement by at least one object with a second object type.

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

According to one embodiment of the invention, it is suitable for applying at least the following object types. Fixed object types, run-time object types, and leaf object types.

Each object having any of the above mentioned object types has one directly related object arranged above it represented by the parent object. However, objects with a fixed object type or run-time object type may have one or more objects that are directly related and arranged above. Different object types allow to form a hierarchical object structure, each containing a plurality of objects having one of the aforementioned object types.

Thus, the above mentioned method for adding at least one object according to an embodiment of the present invention may alternatively be described in the following manner. At least one object is defined to be related to the parent object. The object type of the parent object is examined and obtained. If the object type of the parent object is a fixed object type, the at least one object may have a fixed object type, a run-time object type, or a leaf object type. If the object type of the parent object is a run-time object type, the at least one object may have a fixed object type or a leaf object type.

The definition of at least one object may also require the definition of object properties. Object attributes include AccessType, DefaultValue, Description, DFFormat, Occurrence, Scope, DF Title, and DFType. A group may include one or more attributes. Possible object attributes are not limited to those presented, and additional different object attributes may also be valid.

According to one embodiment of the invention, it is further checked whether the parent object has one or more directly arranged objects that are already subordinately related. If there are one or more objects already present, one or more object types of these one or more objects are determined and the obtained one or more object types are compared with the object type of the child object added to the hierarchical object structure. If at least one of the obtained one or more object types and the object type of the child object are both proven to have a first object type (ie, a run-time object type), the child object is the child object and the at least one An already existing object is added to the parent object under conditions that have a common format.

The format of an object will define what kind of management related information is allowed and / or suitable to be distributed among each object and the hierarchically arranged objects subordinately associated with each object. Objects with a common format define that similar management related information relating to the same device function and / or device application is distributed among the objects and the objects arranged below.

According to one embodiment of the invention, the object type of the parent object is determined. It is also checked whether the parent object already has one or more child objects. If the parent object does not have child objects and both the parent object and the at least one object defined both have a second object type, the parent object and the at least one object are concentrated into a single object with a second object type. do. The concentrating is performed by replacing the parent object and the at least one object with a single object.

According to one embodiment of the invention, at least part of the technical document is encoded according to at least one object defined. At least a portion of the technical document to be encoded includes information about at least one object and attributes of at least one object previously defined. The encoded technical document allows obtaining a hierarchical object structure for storing management related information of an electronic device distributed among a plurality of objects included in the hierarchical structure. Obtaining one or more objects and at least a portion of the hierarchical object structure may be performed by analyzing each encoded technical document or one or more related portion (s) of the document.

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

According to one embodiment of the present invention, the format of an object defines what kind of management related information is allowed and / or suitable to be distributed among each object and hierarchically arranged objects subordinately associated with said each object. do. Objects with a common format define whether similar management related information relating to the same device function and / or device application is distributed among the objects and the objects arranged below.

According to an embodiment of the present invention, the hierarchical object structure comprising a plurality of objects corresponds to device description framework (DDF) information and / or the hierarchical object structure comprising a plurality of objects is an electronic device. Corresponds to the management tree used for device management. The Device Description Framework (DDF) information and / or management tree is provided and standardized by the SyncML Initiative in the form of a Sync Generation Language Device Management (SyncML DM).

According to one embodiment of the invention, the technical document corresponds to a device description framework (DDF) document. The DDF document is an Extensible Generation Language (XML) encoded document encoded according to a corresponding description framework document type description (DTD). Extensibility Generation Language (XML) is not limited to the clear (plain) text XML encodings presented below and also includes binary encoding based on XML and others of that kind.

In accordance with one embodiment of the present invention, a software tool is provided for adding at least one object to a plurality of objects forming a hierarchical object structure. The software tool includes program portions for performing the operations of the above-mentioned methods according to any embodiment of the present invention when the software tool is implemented and / or executed in a computer program.

According to one embodiment of the present invention, a computer program for adding at least one object to a plurality of objects forming a hierarchical object structure is provided. When the program is run on a processing device, computer or network device, the computer program includes loadable program code portions for performing the operations of the above-mentioned methods according to any embodiment of the present invention.

According to one embodiment of the invention, when the program is executed in a processing device, a computer or a network device, program code portions stored in a computer readable medium for performing the above-mentioned methods according to any embodiment of the present invention. A computer program product is provided that includes.

According to one embodiment of the invention, a computer data signal is provided. The computer data signal represents a program or program code portions that, when executed by a processor, cause the above-mentioned methods according to some embodiments of the invention to be performed and are implemented on a carrier wave.

According to one embodiment of the invention, there is provided a processing apparatus having a processing unit, a memory unit and a communication interface. The processing unit may be connected with the memory unit and the communication interface to exchange data therebetween. The processing unit of the processing device is configured to be able to add at least one object to the hierarchical object structure. The hierarchical object structure consists of a plurality of objects. The objects are hierarchically related to each other. The hierarchical association of the objects is achieved by using at least two different types of objects, a first object type and a second object type. The first object type and the second object type allow to have objects arranged directly below.

At least one object is defined to be related to the parent object. The parent object is directly associated with and arranged above the at least one object. That is, the at least one object defined is at least one child object of the parent object. The parent object is part of a hierarchical entity structure. The object type of the parent object is compared with the object type of at least one object being defined. When the types of the at least one child object and the parent object match each other and the object types are all first types, an object having the second type is inserted between the parent object and the at least one object. This separation ensures that objects with a first object type are always separated in hierarchical interdependence by at least one object with a second object type.

According to one embodiment of the invention, the processing apparatus is further configured to operate any one of the above-mentioned embodiments of methods for adding at least one object to a hierarchical object structure.

According to one embodiment of the invention, there is provided a management system comprising a hierarchical object structure and a processing device such as a managed client device or a management server device. The hierarchical object structure includes a plurality of objects that are hierarchically related. Each of the plurality of objects has a certain object type that is at least two object types, and a first object type and a second object type are applicable. Each object having a first object type or a second object type may have directly arranged objects that are subordinately related.

Each two objects arranged hierarchically with respect to each other, both having a first object type, are separated by at least one inserted object having a second object type in a hierarchical structure. That is, hierarchically related objects having a first object type are not allowed to be arranged directly with each other.

The processing apparatus includes at least one management element capable of generating at least part of a hierarchical object structure. The hierarchical arrangement of the hierarchical object structure is mapped to at least a portion of the hierarchical arrangement resulting from the hierarchical object structure. The hierarchical object structure may retrieve, store and manage management related information of the managed mobile communication enabled device.

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

According to one embodiment of the invention, it is suitable for applying at least the following object types. Fixed parent object type, run-time parent object type, and leaf object type.

Each object having any of the above mentioned object types has one directly related object arranged above it represented by the parent object. However, objects with a fixed parent object type or run-time parent object type may have one or more objects that are directly related and arranged above. Different object types allow to form a hierarchical object structure, each containing a plurality of objects having one of the aforementioned object types.

According to one embodiment of the invention, two or more objects of the first type and arranged directly in the object to which they are related have a common format. The format of an object will define what kind of management related information is allowed and / or suitable to be distributed among each object and the hierarchically arranged objects subordinately associated with each object. Objects with a common format define that similar management related information relating to the same device function and / or device application is distributed among the objects and the objects arranged below.

According to one embodiment of the invention, two directly arranged objects that are related to each other and have said first type, ie a parent object and a child object, having a second type are concentrated with a second object type in a hierarchical object tree. Replaced by an object The concentrated object consists of two substituting objects. In other words, the hierarchical object structure includes concentrated objects made up of the two directly arranged objects described above. Thus a direct array of parent objects and their only child objects (both of which are of the second type) does not occur in the hierarchical object structure.

According to one embodiment of the invention, the processing device is a managed mobile communication capable device comprising at least a client device management element, ie a client management agent and a storage element. The client device management element creates the at least a portion of the hierarchical object structure to establish the portion of the hierarchical structure and stores the at least a portion of the hierarchical object structure in the managed mobile communications enabled device. Can be stored in an element. The storage may be storage of at least a portion of the hierarchical object structure into a currently existing hierarchical object structure for dynamically extending the hierarchical object structure. The client device management element may further distribute management object related information among the plurality of objects constituting the hierarchical object structure, wherein at least a portion of the management related information from one or more of the plurality of objects Can be configured to set the device's functions and / or applications operable with the device.

According to one embodiment of the invention, the processing device is a management server device comprising at least a server device management element, namely a server management agent and / or a service management engine, and a communication interface. The server device management element may generate at least a portion of the hierarchical object structure and generate one or more management messages including management commands and corresponding management related data according to the generated at least part of the hierarchical object structure. have. The server device management element may also send one or more management messages obtained with the communication interface to the managed mobile communication enabled device.

One or more management messages allow a managed mobile communication device to extend a dynamically stored hierarchical object structure in accordance with the transmitted management information, and distribute management related information provided by the server among any objects in the hierarchical object structure. And to retrieve management-related information from certain objects of the hierarchical object structure identified (addressed) by address information obtained from at least a portion of the hierarchical object structure created and others of that kind.

The invention will be described in more detail by the embodiments with reference to the accompanying drawings.

In the following, embodiments of the present invention will be described with respect to a system supporting the SyncML device management standard or related SyncML standard, but the present invention is not limited thereto. Information about the SyncML standard and the SyncML Device Management (SyncML DM) standard can be obtained from the SyncML Initiative, which publicly provides the entire standard document. Like parts, features, and / or actions shown in the drawings will be denoted using the same reference numerals.

1A shows a schematic diagram illustrating a set of exemplary electronic devices in which synchronization of information can be performed therebetween. Preferably, some database content of mobile terminals will match the database content provided by the designated devices. Conventionally, mobile terminals operate as synchronization clients that synchronize or coordinate some predefined data with the contents of one database or several databases provided by dedicated server devices. 1 illustrates a plurality of possible client and server devices for a synchronization operation. Typically, client devices are mobile stations such as personal digital assistants (PDAs) or mobile phones 17, mobile computers such as notebooks 15, digital cameras 16 or personal computers (PCs). In addition, the dedicated synchronization server devices may be a desktop computer such as a personal computer 10, a dedicated network server 11 or even a mobile computer such as a notebook 12. Note that although the concept of synchronization presented is described with respect to mobile terminals connected to dedicated service devices, the client device functionality is not limited to the mobile terminals as described above.

Corresponding synchronization processes in accordance with the SyncML protocol standard or SyncML device management protocol standard may be established through a suitable logical communication connection. The logical communication connection may be provided by some communication networks in conjunction with the transport protocols to which the synchronization protocol is adapted. Suitable communication networks may be a wide area network (WAN), an on-premises information network (LAN), which may include the company's intranet and the Internet, but may also be a universal serial bus (USB) or standardized serial communication (eg RS-323). Wire-based serial network). Participating synchronization devices may also include mobile networks that support Mobile Communications Global System (GSM) services and / or General Packet Radio Services (GPRS), third generation mobile communications networks such as Universal Mobile Telecommunications Systems (UMTS) networks, wireless premises information. It may be connected via a wireless communication network, such as a communication network (WLAN), a Bluetooth network or an infrared network (IrDA). Logical communication connections between participating synchronization devices may be provided by a single communication network of the above-mentioned type, but may also be provided by several communication networks of the above-mentioned type that are interconnected by dedicated network routing devices. have.

With regard to the SyncML protocol standard The SyncML device management protocol and also with respect to the SyncML device management protocol standard, suitable protocols can be implemented on top depending on the type of communication network used. On top of that, suitable protocols on which the SyncML synchronization protocol can be implemented are Hypertext Transfer Protocol (HTTP), Wireless Session Protocol (WSP) in the Wireless Application Protocol (WAP) standard, Wireless Datagram Protocol (WDP), Universal Serial Bus (USB). Or object exchange protocol (OBEX), transmission control protocol / Internet protocol (TCP) used for cable connections, such as RS-232, for short range radio frequency connections (Bluetooth) or for infrared connections (IrDA). / IP) stack and sits on top of a transport layer service provided by an email protocol (e.g., a simple mail transfer protocol (SMTP)).

The transmission at the lower layer is for example short message service (SMS) or other signaling type transmission methods (e.g. unstructured supplementary service data (USSD)), circuit switched data call or packet switched data. It may be performed according to a lower network using the transport service.

Although the above description refers to general synchronization and thus also to device management synchronization, the following description of the innovative concept will explicitly refer to the SyncML DM protocol.

The SyncML DM service itself is based on the exchange of a management document, which can be divided into a plurality of messages or packages containing device management data, i.e. instructions for synchronizing configuration data and settings. The SyncML DM protocol includes two parts: a setup phase and a management phase that include authentication and device information exchange. The management phase can be repeated as many times as the server desires.

The management phase consists of a number of protocol iterations. That is, protocol repetition means a package of a management server from a managed client device and a package from a management server to a managed client device. The contents of the package sent from the management server to the managed client device determine whether the session should continue or not. When the management server sends management operations in packages that require responses (status or results) from the managed client device, the management phase of the protocol may be from the managed client device that includes client responses to the management operations. Continue with the new package to the management server. The response package from the managed client device starts a new protocol iteration. The management server may send a new management operation package and thus initiate a new protocol iteration as many times as the server desires.

An exemplary and valid full sequence of packages according to the setup and management phases is described in the next section to provide a rough overview of the package exchange.

Package 0-Initiation of Management Session: Most managed client devices may receive unsolicited messages, sometimes referred to as "notifications." The management server can use this notification capability to allow the client to initiate a connection to the management server. Several bearers can be used to send management initiation notifications. Note that the same effect as receiving the management initiation notification can be brought about in other ways.

Package 1-Initialization from the Managed Client Device to the Management Server: The purpose of the initialization package sent by the managed client device is to:

To transmit managed client device information (such as manufacturer, model, etc.) to the 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 on package 0) or by the client (such as an end user selecting a menu item).

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

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

To optionally transmit management commands and management data to the managed client device,

-Optionally send additional commands, such as user interaction commands.

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

Package 3-Managed Client Device Response to Management Server Response: The purpose of this management package is to:

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

To send the results of optional user interaction commands.

Package 4-Additional Management Server Operations: The purpose of this management package is to:

To send any further necessary management actions or commands, respectively, from the management server to the managed client, or

To end the management session.

Package 4, including additional management operations, causes a response from the managed client device, such as package 3. Therefore, the management session may include any number of iterations of packages 3 and 4.

The aforementioned SyncML DM service based on management message exchanges in accordance with the steps and packages described above operate on the objects that make up the management tree, which each structure and contain managed information. The management tree is an array of well defined hierarchical structures of all available and used management entities. The location of some information contained in a management entity and its addressing correspondingly represent the content of the management information, respectively. In view of the broad definition of databases described above, the management tree can be understood as a database for storing configuration data and settings in a well defined hierarchical organization. The location of management related information in the management tree is associated with device applications and / or certain device functions, each using each management related information for its operation. This well-defined hierarchical structure is referred to as a management tree. The hierarchical organization of managed objects raises the need to provide a suitable and unique addressing scheme for each single managed object, which mainly corresponds to a hierarchical structured arrangement. A particular parent object, the root entity, provides the origin of all hierarchically arranged managed objects. In other words, the root object of the management tree is the object on which managed objects are arranged for that object.

Different kinds of managed objects are classified. The hierarchical object structure, in particular the management tree, includes leaf objects, and interior objects, hereafter also represented as (internal) nodes. The leaf objects may further be classified into link objects containing address information of any object in the hierarchical object structure and leaf objects allowed to contain some but predefined contents. An internal object or internal node represents an entity used to associate one or more dependent objects with it. That is, one or more, but in some way, any number of directly (immediately) related objects arranged hierarchically, represented by one or more child objects or child nodes, each associated and arranged with a parent object or parent node. Represents a hierarchically structured entity with Each internal object or internal node itself is related to one parent internal object or internal node or to a root object / node that is an internal object or internal node having the highest hierarchy level. Based on this interconnection, a hierarchical object structure, i.e. a management tree, is established. The internal objects are further classified into permanent internal objects and dynamic internal objects. As the name "permanent" indicates, persistent objects are always in the management tree independent of any operational state of the managed client device or application (s) in operation. In contrast, dynamic objects may be added, replaced, modified, and / or deleted by a management server or managed client device corresponding to the need for information contained in a hierarchical structure (dynamic part of the management tree) associated with the dynamic object. .

Leaf objects are related to parent internal objects, but do not allow child objects to be related. That is, they do not have associated child object (s). Instead, leaf objects are used as containers that contain some content of any but predefined content type. That is, it may include integer values, larger values (plain text, array of values), complex data types, some content such as pictures and program code, value (s), and the like. The leaf objects contain configuration data and / or settings necessary for device and / or application operation. Leaf objects represent the "end" objects of the branches of the management tree. In other words, it represents the lowest hierarchical level of each fork in the management tree.

1B illustrates an exemplary portion of a management tree implemented at a managed client device, eg, a mobile communication device. An exemplary part of the management tree includes the root object "/" that appears when the management tree is set up. In this specification, the display of exemplary portions of the management tree is limited to the top level structure. Below the root object, a device description framework (DDF) object, a device information (DevInfo) device, a device detail information (DevDetail) device, and all additional objects may be arranged below. There is an example object (AP) that represents internal objects that may be. The number of objects related to the root object (root node) " / " is not limited to that shown, they are just shown for example. That is, objects may not be associated with the root object "/" at all or one or more additional objects may be associated with the root object "/". Objects (DDF, DevInfo, and DevDetail) represent a selection of required objects for (but not limited to) managed client devices that can operate with SyncML device management services. The DevInfo object and the DevDetail object are internal objects meaning that unlimited additional internal objects and leaf objects (and link objects) are arranged below. The management tree may be set at switch on of managed device clients. Adaptation and / or modification of the management tree may be performed in accordance with the above-mentioned exchange of management information corresponding to the SyncML device management service.

Each object and hence each information contained in an object is addressable. Addressing of an object is based on an instance identifier. Instance identifiers are assigned to each object in the management tree. When assigning instance identifiers to objects, it is considered that the addressing of each object must be unique. This means that an internal object can have one or more directly related sub-objects (internal objects, leaf objects, link objects). In order to obtain unique addressing for each object in the management tree, the instance identifiers of these directly related subordinate objects must be different from each other. The address information includes all instance identifiers ranging from the root object to the addressed object, carried by following the hierarchical structure of the management tree. A suitable delimiter separates each instance identifier.

The concept of a management tree is provided for multiple managed client devices that implement different functions and / or managed client devices that operate multiple different applications that are not the same, which means that the managed client device has a management tree of the same structure. This means that the behavior of managed client devices is different in terms of SyncML device management services.

This problem is addressed by the device description framework (DDF). The use of the Device Description Framework (DDF) allows a manufacturer of managed client devices to manage the management tree in all different dynamic (run-time) representations so that managed client devices can be managed by a management server based on SyncML device management services. Allows you to provide information describing The device description framework (DDF) is applicable in a flexible and easily extensible way and must be implemented in such a way that corresponds to future needs for the management tree. Device description framework (DDF) is an abstract description of objects. Thus, the management tree itself is derivable from the device description framework (DDF), and the device description framework (DDF) provides a number of individual management tree structures that are suitable for different situations and effective for use with corresponding managed client devices. Allow to induce. Thus, the Device Management Framework (DDF) is a descriptive object that allows to derive objects (permanent / dynamic internal objects, leaf objects and link objects), properties and associations of objects (combination, arrangement in the management tree). Include them. Thus, the descriptive objects of the device description framework (DDF) contain definitions describing the objects and thus the detailed information required to set up the management tree in a valid manner, respectively. Descriptive objects in the Device Description Framework (DDF) represent a hierarchical object structure and operate as a template hierarchical structure of the resulting management tree.

The inventive concept relates to rules and regulations that must be applied during the definition and addition of objects described in the device description framework (DDF) such that the above-mentioned advantages are achieved.

The description of the management tree and the corresponding device description framework (DDF) will be provided with reference to the graphical representation.

2A shows a table representing elements used in the graphical representation of an object distinguished by object types. An example representation is compared with the meaning of the object (object type). Corresponding to the objects available for forming the management tree, the table includes fixed (parent) object types, run-time (parent) object types, and leaf object types. Additional object types are provided herein. Link object type. As mentioned above, the link object type is a specific leaf object type that stores addressing information of any different object in the hierarchical object structure. That is, the link object type defines a leaf object type that includes a link value that is a plain text value for encoding a uniform resource indicator (URI) or any similar or related addressing value. Fixed parent objects with a fixed parent object type are represented herein as rectangles containing titles representing instance identifiers replaced with the words “Fixed”. A run-time object having a run-time object type is represented herein as a rectangle with rounded corners and containing a title that replaces the word "Run-Time". Leaf objects having a leaf object type are simply indicated herein with titles representing instance identifiers replaced with the word "Leaf". Finally, the link having a link object indicates the type of object instance identifier in place of the word "link (Link)" herein is simply displayed as a title with underlined bold.

The title (ie, instance identifier) of an object is one attribute element represented by the NodeName element of the description objects. As mentioned above, an object can be identified by a node name element with a predefined value (fixed object) or a dynamically assigned value (run-time object). Additional attribute elements may or may not be included: AccessType, DefaultValue, Description, DFFormat, Occurrence, Scope, DF Title and DFTitle. DF Type. The presented list of attribute elements is to be understood as illustrative only and not limiting. The AccessType element specifies which commands should be defined for the object (which actions are allowed to be performed on the object). Possible specifications for an access type element are Get, Delete, Add, and Replace. The DefaultValue element optionally defines the object value used in the device if the object value is not explicitly set to a different value. The Description element defines a human readable description of an optional object. The DFFormat element defines the required data format of an object. The Occurrence element optionally specifies the number of instances that can occur in the object in the management tree. That is, it explicitly specifies the number of directly arranged child objects related to one parent object. The scope element optionally specifies whether the object describes a permanent object or an action object. The DF Title element defines the optional human readable name of the object. The DFType element defines the MIME type (multipurpose internet mail extension type) of the object value for leaf objects and the null or DDF document name for internal objects. .

Fixed parent objects represent persistent or dynamic internal objects. The title of the parent object is fixed and used as an instance identifier in the management tree. If the occurrence of a fixed parent object is one, the corresponding inner object is a permanent inner object, that is, the scope is permanent. On the other hand, if the occurrence of a fixed parent object is none or one (ZeroOrOne), the scope of the fixed parent object is dynamic, and internal objects are created and deleted at runtime by the management server. Can be.

Run-time (parent) objects represent dynamic internal objects. The title of a run-time object is not fixed. That is, during creation, the name of the dynamic internal object is dynamically defined at run time and used as an instance identifier in the management tree. The dynamically defined instance identifier may include any sequence of numeric characters (up to nine characters). In the following, the title of the run-time object will be indicated as <X> or <Y>.

The titles of the leaf object and the link object are fixed respectively. The content type of the content contained in the leaf object must be specified. That is, the MIME type. On the other hand, the content type of the link object specifies the content type of the corresponding leaf object, for example for encoding address information such as a uniform resource indicator (URI).

In the following, rules, regulations and methods are presented with respect to objects having certain object types. Since additional object types may be included that do not contradict the inventive concept, the object types presented should not limit the object types.

2B shows a table showing special characters used in addition to the graphical representation of objects. The table compares the characters and their meanings. The characters represent the Occurrence attribute element of the object. The generation element optionally specifies the number of object instances that can occur in the management tree. By default and when no additional characters are appended to the title of the object, the occurrence of the corresponding object in the management tree is (exactly) one. The "+" sign added to the title of the object indicates that the occurrence of the corresponding object in the management tree can be one or more times than once (Occurrence: OneOrMore, OneOrN). The "*" symbol added to the title of an object indicates that there is no occurrence of a corresponding object in the management tree or that it can be more than one (Occurrence: ZeroOrMore, ZeroOrN). A "?" Added to the title of the description object. The symbol indicates that there is no or only one occurrence of the corresponding object in the management tree (Occurrence: ZeroOrOne).

3A-3E are the rules observed and applied when defining and adding objects to the hierarchical object structure implemented in FIG. 4A by an exemplary method for adding at least one object in accordance with embodiments of the present invention. And regulations.

3A shows a first arrangement of description objects in accordance with one embodiment of the present invention. The first arrangement comprises a first fixed (parent) object "Node_1", 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 subordinately associated with the first fixed (parent) object "Node_1", while the second fixed parent object "Node_2" is the one or more run-time objects <X > * Subordinate to each

Based on the device description framework (DDF) structure and the graphic definition of the description objects described above, the resulting portion of the management tree is the first fixed parent object "Node_1" with instance identifier "Node_1" and one or more, one or more run-times. May contain objects <X> *. The instance identifier (s) of the run-time objects <X> * are defined at run-time and may be, for example, "run-time_1", "run-time_2", and the like.

It may be assumed that one run-time object <X> * with instance identifier "run-time_1" (as shown) has been created. The run-time object "run-time_1" is subordinately related to the fixed object "Node_1". That is, the run-time object "run-time_1" is a child object of the fixed object "Node_1". According to the scope definition (scope element) of the second fixed object "Node_2", the run-time object "run-time_1" is the parent object for the fixed object "Node_2" or the fixed object "Node_2" is the run-time object "run- Child object for "time_1".

It can be assumed that two run-time objects <X> * with instance identifiers "run-time_1" and "run-time_2" have been created. The run-time objects "run-time_1" and "run-time_2" are child objects for the fixed object "Node_1". According to the scope definition (scope element) of the second fixed object "Node_2", the run-time object "run-time_1" is the parent object for the fixed object "Node_2" and the run-time object "run-time_2" in parallel Similarly it is the parent object for the fixed object "Node_2". Two child objects with the same instance identifier "Node_2" are distinguishable through different dependencies (binding, parent objects) in the management tree.

3B illustrates a second arrangement of description objects in accordance with one embodiment of the present invention. The second array 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_1". The one or more run-time objects <Y> + are subordinately associated with the first fixed object "Node_3", but the second fixed object "Node_4" and the leaf object "Leaf_1" are the one or more run-time objects Each of these <Y> + is subordinately related. FIG. 3B shows a "simplest" situation, meaning only one run-time object <Y> + with two child objects, one fixed object "Node_4" and one leaf object "Leaf_1".

Based on the device description framework (DDF) structure described above, the resulting part of the management tree is associated with the first fixed object "Node_3" and the first fixed object "Node_3" having an instance identifier "Node_3", i.e. And at least one run-time objects <Y> + that are child objects of the first fixed object "Node_3" and are arranged directly. The instance identifier (s) of the child objects are defined run-time and may be similarly referred to, for example, "run-time_1", "run-time_2" and the like. Run-time objects "run-time_1", "run-time_2", ... each have two child objects, a second fixed object "Node_4" and a leaf object "Leaf_1".

The structures described in connection with FIGS. 3A and 3B represent device description framework (DDF) definition structures allowed for use. In contrast, FIG. 3C shows arrangements of objects that are avoided in accordance with the rules and regulations of the inventive concept.

The first array of description objects is specifically some first run-time objects <X> * with no occurrence or more than one occurrence, and some second run-time objects with no occurrence or more than one occurrence <Y> in detail. Indicates *. 3C shows the concatenation of one first run-time object <X> * and one second run-time object <Y> *. More generally, if one or more first run-time objects <X> * and one or more second run-time objects <Y> * are present, each of the first run-time objects <X> * may be It is the parent object for one second run-time objects <Y> * that are child objects. Thus, each of the one or more first run-time objects <X> * that is the parent object has a dynamically assigned instance identifier. Furthermore, each of the one or more second run-time objects <Y> * that are child objects also have a dynamically assigned instance identifier.

A hierarchical object structure comprising successively directly arranged run-time objects with dynamically assigned instance identifiers with different hierarchical levels is particularly capable of easily identifying objects in terms of exploring the management tree. It can be easily understood that the lack represents a complex structure that is difficult to manage.

As a general rule for defining objects, a run-time object must be subordinately associated with a fixed parent object, and such a run-time object must also be associated with at least one subordinately associated fixed object and / or leaf object and / or link object. It must act as the parent object for the.

3D illustrates an arrangement of descriptive objects concentrated into a single descriptive object in accordance with one embodiment of the present invention. The arrangement comprises two consecutive fixed objects, fixed object "Node_5" and fixed object "Node_6". The only child object of the fixed object "Node_5" is the fixed object "Node_6". Stringing fixed parent objects of the described type together does not represent any useful information and thus the fixed object "Node_5" and fixed object "Node_6" can be concentrated into a single fixed object "Node_5Node_6" representing the same information. . The concentration simplifies the resulting management tree in that it accesses the centralized fixed parent object " Node_5Node_6 " and the objects arranged subordinately by exploring the management tree and, for example, simplifying their addressing.

3E illustrates an arrangement of descriptive objects to be avoided in accordance with one embodiment of the present invention. The array includes fixed objects "Node_7" directly related to the child objects, the first run-time object <X> * and the second run-time object <Y> +. The first run-time object <X> * and the second run-time object <Y> + are each associated with objects of different formats. This means that the first run-time object <X> * and the second run-time object <Y> + are also related to different functions and applications, respectively. The format of an object allows and / or suitably allows some kind of management related information to be distributed among each object and hierarchically arranged objects that are subordinately associated with each object. Objects with a common format define that similar management related information relating to the same device function and / or device application is distributed among the objects and the objects arranged below.

In order to obtain a manageable and unambiguous management tree, different types of run-time objects should not be subordinately associated with a common parent object (which is a fixed object) as shown in FIG. 3E. Rather, run-time objects of different formats for each of the different functions and applications of the managed client device must be related to different parent objects (which are fixed objects) in order to provide a clearly organized, usable and manageable management tree. do.

4A shows a first flowchart illustrating the definition of an object according to an embodiment of the present invention. The illustrated first flow diagram illustrates an exemplary embodiment that takes into account the rules and regulations shown and described above to define the objects and their attributes and dependencies.

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

In step S110, the object type of the parent object is determined. The parent object for the new object may be a fixed object or a run-time object. In accordance with the rules and regulations described with reference to FIG. 3C, it should be avoided that two run-time objects are arranged consecutively in a hierarchical object structure and device document framework (DDF). Correspondingly, it is checked whether the parent object is a run-time object or a fixed object. If the parent object has a run-time type, the illustrated operation sequence continues at step S140, which ensures that successive run-time objects cannot be defined and added. If the parent object has a fixed type, the illustrated sequence of operations continues at step S120 which allows to associate some type of object with the parent object that is a fixed object.

In step S120, it is checked whether a new run-time object should be defined / added, and in that case the operation sequence continues in step S130. Otherwise, the operation sequence continues at step S140.

In step S130, a new run-time object is defined. The definition includes associating (or adding or including) the new run-time object to the parent object and the hierarchical object structure that are superarrayed, respectively. Parent objects arranged above in accordance with the above rules and regulations are fixed objects. The definition of the new run-time object also includes the AccessType, DefaultValue, Description, DFFormat, Occurrence, Scope, DF Title, and DF. May contain definitions of additional attribute elements, including type (DFType). After fully defining all the required and required attribute elements and adding the new run-time object to the hierarchical object structure, the operation sequence for defining the new object continues at step S200 in which the operation sequence ends. Additional new objects can be defined by resuming the above-described operation sequence.

In step S140, it is checked whether a new fixed object should be defined, in which case the operation sequence continues in step S150. Otherwise, the operation sequence continues at step S160.

In step S150, a new fixed object is defined. The definition includes associating (or adding or including) the new fixed parent object to the parent object and the hierarchical object structure that are superarrayed, respectively. Parent objects arranged above in accordance with the rules and regulations described above are fixed parent objects or run-time (parent) objects. The definition of the new fixed parent object also includes the AccessType, DefaultValue, Description, DFFormat, Occurrence, Scope, DF Title, and DF Type. May contain definitions of additional attribute elements, including (DFType). After fully defining all the required and required attribute elements and adding the new fixed parent object to the hierarchical object structure, the operation sequence for defining the new object continues at step S200 in which the operation sequence ends. Additional new objects can be defined by resuming the above-described operation sequence.

In step S160, it is checked whether a new leaf object should be defined, in which case the operation sequence continues in step S170. Otherwise, the operation sequence continues at step S180.

In step S170, a new leaf object is defined. The definition includes associating (or adding or including) the new leaf object to the parent object and the hierarchical object structure that are superarrayed, respectively. Parent objects arranged above in accordance with the rules and regulations described above are fixed parent objects or run-time (parent) objects. The definition of the new leaf object also includes the AccessType, DefaultValue, Description, DFFormat, Occurrence, Scope, DF Title, and DF Type ( DFType), which may include definitions of additional attribute elements. After fully defining all the required and required attribute elements and adding the new leaf object to the hierarchical object structure, the operation sequence for defining the new object continues at step S200 in which the operation sequence ends. Additional new objects can be defined by resuming the above-described operation sequence.

In step S180, it is checked whether a new link object should be defined, and if so, the operation sequence continues in step S190. The present invention presents four different types of objects. Correspondingly, inspection steps S120, S140, S160 and S180 include these four types. It should be noted that one or more additional types of objects may be included in the device document framework (DDF). According to the current case, if no new link object is defined, the operation sequence continues at step S200. That is, the sequence of operations ends without defining any new objects. Checking, defining and adding steps to one or more additional types of objects may be implemented in the current sequence of operations similar to the checking, defining and adding steps described above with reference to each type of object.

In step S190, a new link object is defined. The definition includes associating (or adding or including) the new link object to the parent object and the hierarchical object structure that are superarrayed, respectively. Parent objects arranged above in accordance with the rules and regulations described above are fixed parent objects or run-time (parent) objects. The definition of the new link object also includes the AccessType, DefaultValue, Description, DFFormat, Occurrence, Scope, DF Title, and DF Type ( DFType), which may include definitions of additional attribute elements. After fully defining all the required and required attribute elements and adding the new link object to the hierarchical object structure, the operation sequence for defining the new object continues at step S200 in which the operation sequence ends. Additional new objects can be defined by resuming the above-described operation sequence.

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

As an alternative to the proposed sequence of operations, which ensures that run-time objects are not arranged in a hierarchical object structure, the addition and insertion of a fixed object in two consecutively arranged run-time objects also obeys this provision. Remember to meet. Inserting a fixed object into consecutive run-time objects prevents this continuous arrangement and finally results in the same resulting hierarchical object structure.

According to a further (improved) embodiment of the present invention, the sequence of operations also contemplates examining the object formats of run-time objects that are already associated with the parent object with which the new object is directly related as an additional client object. Corresponding rules and regulations are described in detail with reference to FIG. 3E.

In step S130, existing "parallel" child objects of the parent object are determined. If there are existing technical child objects, it should be avoided that run-time objects of different formats are related to the same parent object. If run-time objects of different formats are defined to relate in parallel to existing run-time objects having a certain format, the definition is rejected and the operation sequence continues at step S200. In other words, the operation sequence ends.

According to a further (improved) embodiment of the present invention, the sequence of operations also contemplates checking for object types already associated with the parent object with which the new object is directly related as a (additional) client object. Corresponding rules and regulations are each described in detail with reference to FIG. 3D.

In step S150, existing "parallel" child objects of the parent object are determined. If the "parallel" description child objects do not exist and the parent object is a fixed object, then the new fixed object and the existing parent are related to a new single fixed object in place of the parent object, hierarchical object structure and Simplify the device description framework (DDF).

4B shows a second flow diagram illustrating defining and generating at least a portion of a Device Description Framework (DDF) and a DDF document in accordance with one embodiment of the present invention. This operation sequence includes the operation sequence shown in FIG. 4A according to an embodiment of the present invention.

In step S300, an operation sequence for generating a DDF document begins according to defining new objects according to an embodiment of the present invention.

In step S310, an object is defined. By default, there is a root object. In other words, the Device Description Framework (DDF) is constructed and thus the basis on which the DDF document is constructed. The definition of the object in step S310 includes the steps shown in FIG. 4A and is described in more detail with reference to the steps above.

In step S320, the resulting new object is encoded in the DDF document according to the definition performed in step S310. The encoding of the DDF document may be based on Extensible Generation Language (XML) encoding. XML encoding is based on the type description provided in the corresponding Document Type Description (DTD), which defines the language elements of XML encoding required for a DDF document. The XML encoding may be any suitable XML encoding, such as binary encoded XML encoding.

In step S330, when additional new objects are added to the current device description framework and the DDF document, respectively, the operation sequence returns to step S310. Otherwise, when the current device description framework and the DDF document are respectively completed, no additional object is added and the operation sequence continues in step S340.

In step S340, the resulting device description framework and the DDF document may be stored or transmitted to the management server and / or managed client device and applied to the setting up, creation, modification, etc. of the management tree. Moreover, the resulting device description framework and the DDF document are each processed to generate at least a portion of the management tree. This processing of the device description framework and the DDF document will be described below with reference to FIG. 4C.

In step S350, the operation sequence for generating a DDF document ends according to defining new objects according to an embodiment of the present invention.

Note that step S310 of defining a new object and step S320 of encoding a new object are described as separate steps. Both step S310 and step S320 may be implemented as a comprehensive step in which definition and encoding are performed simultaneously.

4C illustrates a third flow diagram illustrating analyzing and generating at least a portion of a management tree based on a device description framework (DDF) and a DDF document in accordance with one embodiment of the present invention.

In step S400, an operation sequence for generating at least a portion of a management tree based on a device description framework (DDF) and a DDF document begins according to an embodiment of the present invention.

In step S410, a device description framework (DDF) and a DDF document including objects encoded corresponding to which objects of the management tree are generated are retrieved from a storage unit, such as a support server or device management server of a manufacturer of an electronic device. May be received from a providing entity. For example, the device description framework (DDF) and the DDF document may be received by the management client device from the management server or by the management server from the DDF providing network server. As mentioned above, the availability of Device Description Framework (DDF) and DDF documents allows the processing device to create valid and suitable management tree structures and ensure their adaptability.

In step S420, the device description framework (DDF) and the DDF document are analyzed, respectively. The analysis may include extracting information and / or interpreting the information obtained by the analysis. The analysis may be performed by object by object or block-wise as implemented herein. That is, by analyzing a set of related description objects. The analysis of the device description framework (DDF) and the DDF document may further comprise an identification operation to analyze / extract required object (s) information from each of the entire device description framework (DDF) and the DDF document.

In step S430, one or more objects are created based on the information obtained by step S420. The creation of each object is performed according to the object description framework (DDF) and the object information contained in the DDF document. The generated objects are included in at least part of the generated management tree. Including new objects is performed taking into account the hierarchical associations defined in the Device Description Framework (DDF) and the DDF document, in order to create at least part of the management tree with the correct hierarchical structure. Moreover, the method of adding an object to a hierarchical object structure, as in the embodiment with reference to FIG. 4A, may result in a resulting hierarchical object tree (even if the DDF document does not take into account the rules and regulations mentioned above). ) May be applied to ensure that the rules and regulations of the present invention are met.

If necessary, in step S430 one or more values are additionally assigned to the newly created object (s).

In step S440, if necessary object information is analyzed / extracted for each object and generation of at least a part of the management tree is not completed, the operation sequence returns to step S420 to analyze / extract additional required object information. Otherwise, generation of at least a portion of the management tree is completed and the operation sequence continues at step S450.

In step S450, the resulting at least part of the generated management tree is applied. The resulting at least some application of the management tree is the setting of the management tree at the managed client device or the existing management to add additional configuration data or settings to the management tree required by one or more device functions and / or applications. It may be an implementation of an additional branch to the tree. Moreover, at least some of the resulting portions of the management tree may be sent to managed clients that are created and implemented by the management server.

The resulting application of at least some of the management trees should be understood with the exchange of management documents and SyncML device management services described above.

In step S460, the operation sequence for generating at least a portion of the management description framework according to the device description framework (DDF) and the DDF document ends according to an embodiment of the present invention.

5A shows a graphical representation of an example portion of a device description framework. 5B and 5C show corresponding DDF documents, and FIG. 5D shows an exemplary management tree in accordance with the example device description framework shown in FIG. 5A and encoded in the form of documents shown in FIGS. 5B and 5C. do.

5A illustrates an exemplary portion of a graphical representation of a device description framework in accordance with an embodiment of the present invention. The graphical representation relates to access point (AP) settings of a mobile data communication capable client device. The graphical representation represents some of the related objects based on which one or more forks in the management tree of the mobile data device enabled client device are derived.

The access point settings are sub-summed below the top level internal object "./AP" which is directly related to the root object "/". That is, the object "./AP" is a child object of the root object "/" and a parent object for all access point (AP) settings. Correspondingly, the top level object "./AP" shown defines a fixed parent object with an instance identifier "./AP". The fixed parent object "./AP" relates to a run-time object <X ₁ > * arranged subordinate to it. The run-time object <X ₁ > * allows to derive none or one or more corresponding internal objects with dynamically assigned instantaneous identifiers that are child objects of the corresponding internal parent objects "./AP". Each set of information about individual access point settings is stored in one of the management tree substructures under one of the run-time objects <X ₁ > *. The instantaneous identifiers of these run-time objects <X ₁ > * preferably indicate the type of access point with which the individual access point settings are associated.

Run-time objects <X ₁ > * Each one is a fixed object "Px", a fixed object "NAPDef?", A leaf object "ClientID?" And the fixed object "BS?". The objects are allowed to occur exactly once or none at all in the management tree arranged subordinate to each of the run-time objects <X ₁ > *.

The fixed object "Px" is the parent object for one or more run-time objects <X ₂ > *. The fixed object "NAPDef?" Is the parent object for one or more run-time objects <X ₃ > *. The fixed object "BS?" Is the parent object for one run-time object <X ₄ > *. Assuming that the fixed object "Px" exists in the management tree, the fixed object "Px" may have none or one or more run-time objects <X ₂ > * with dynamically defined instantaneous identifiers. . Similarly, assuming that a fixed object "NAPDef?" Exists in the management tree, the fixed object "NAPDef?" May be none or may have one or more run-time objects <X ₃ > *. Assuming that the fixed object "BS?" Exists in the management tree, the fixed object "BS?" May not exist at all or may have one or more run-time objects <X ₄ > *. Further structures of the run-time objects <X ₂ > * and <X ₃ > * are omitted.

The run-time object <X ₄ > * is the leaf object "Name?", Among other things, the fixed parent object "Network?" And leaf objects "Country?".

Then, the fixed object "Network?" Is related to one or more run-time objects <X ₅ > + arranged below it. According to the definition of the run-time object <X ₅ > +, if there is a fixed object "Network?", At least one run-time object <X ₅ > + is an internal child object and is attached to the fixed object "Network?". Related.

Run-time objects in the depicted structure are always separated by at least one fixed object and a continuous array of fixed objects is avoided and run-time objects of different formats satisfy each of the rules and regulations described above by the indication. You can see that it does not coexist as child objects of a parent (fixed / run-time object) parent object.

The graphical representation of the device description framework can be used to obtain the corresponding DDF document. The meaning of the graphic elements included by the graphical representation may be translated into the corresponding DDF document to obtain at least the framework of the DDF document.

FIG. 5B shows a first portion of an excerpt of a DDF document corresponding to the graphical representation shown in FIG. 5A. FIG. 5C shows a second portion of an excerpt of the DDF document shown in FIG. 5B. 5B and 5C are described together below.

The following DDF document excerpt is based on the Extensible Generation Language (XML) encoding of the device description framework. XML encoding is also based on document type descriptions that define tags for defining objects and their attributes so that the resulting DDF document can be interpreted in a unique manner. XML encoding is one of a number of possible encoding methods. The following DDF document is based on the document type description for the device description framework provided by the SyncML initiative.

Lines 001 to 007 include a header section of a DDF document. The header section contains the XML encoded version (1.0), the character encoding (UTF-8), the version of the DTD under consideration (1.1), the manufacturer (Nokia), and the model identification of the client device with which the DDF document is associated (omitted by comments). Define.

In lines 008 through 018, the portion of the XML-encoded DDF document contains the dedicated to the fixed object "AP", the attribute elements of the fixed object "AP" and the position in the management tree for the root object "/". do. In accordance with the above mentioned attributes of the fixed object "AP", a set of object attribute elements specify the attributes. Specifically, access is restricted to read operations, the format of the object is set to a node representing an internal object, the occurrence is defined as 1 and the range is permanent. In addition, human readable technology and human readable titles are defined.

In lines 019 to 026, a run-time object <X ₁ > * is defined. The name is omitted because the instance identifier of the run-time object is assigned at run time. Object attribute elements specify access to add, delete, get and replace, the format of the object is defined as a node, none, zero or more, and the scope is dynamic. Human readable titles are defined.

In lines 027 to 037, a fixed parent object "Px" is specified. The name is correspondingly defined as "Px". Object attribute elements specify access limited to read operations (intake), the format of the object is defined as a node, occurrence is 1 and the range is dynamic. Human readable titles are defined.

In line 036, the ellipsis indicates the position in the indicated DDF document that contains the specification of the run-time object <X ₂ > *. The specification of the run-time object <X ₂ > * is performed similarly to the specification of the run-time objects presented herein.

In lines 038 to 048, the fixed object "NAPDef?" Is specified. The name is correspondingly defined as "NAPDef". Object attribute elements specify access limited to read operations (intake), the format of the object is defined as a node, with no occurrence or 1 and the range is dynamic. Human readable titles are defined.

In line 047, the ellipsis indicates the position in the indicated DDF document that contains the specification of the run-time object <X ₃ > *. The specification of the run-time object <X ₃ > * is performed similarly to the specification of the run-time objects presented herein.

In lines 049 to 059, the leaf object "ClientID?" Is specified. The name is correspondingly defined as "ClientID". Object attribute elements specify access to add, delete, get, and replace, and the format of the object is defined as the character format (chr), which is a leaf object, with no occurrence or 1 and the range is dynamic. Human readable titles are defined. Leaf objects contain information. The type of information, i.e. the content type format of the data representing the information, must be defined in advance. Accordingly, the corresponding type element (DFType) includes a MIME type definition of the content being stored, which is plain text information herein.

In lines 060 to 069, the fixed parent object "BS?" Is specified. The name is correspondingly defined as "BS". Object attribute elements specify access limited to read operations (intake), the format of the object is defined as a node, with no occurrence or 1 and the range is dynamic. Human readable titles are defined.

At lines 070 through 077, run-time object <X ₅ > * is defined. The name is omitted because the instance identifier of the run-time object is assigned at run time. Object attribute elements specify access to add, delete, get and replace, the format of the object is defined as a node, no occurrence, zero or more, and the scope is dynamic. Human readable titles are defined.

In lines 078 to 088, the leaf object "Name?" Is specified. The name is correspondingly defined as "Name". Object attribute elements specify access to add, delete, get, and replace, and the format of the object is defined as the character format (chr), which is a leaf object, with no occurrence or 1 and the range is dynamic. Human readable titles are defined. The content type is plain text, specified by the MIME type definition.

In lines 089 to 100, a fixed parent object "Network?" Is specified. The name is correspondingly defined as "Network". Object attribute elements specify access limited to read operations (intake), the format of the object is defined as a node, with no occurrence or 1 and the range is dynamic. Human readable titles are defined.

In line 098, the ellipsis indicates the position in the indicated DDF document that includes the specification of the run-time object <X ₅ > *. The specification of the run-time object <X ₅ > * is performed similarly to the specification of the run-time objects presented herein.

In lines 101 through 110, the leaf object "Country?" Is specified. The name is correspondingly defined as "Country". Object attribute elements specify access to add, delete, get, and replace, and the format of the object is defined as the character format (chr), which is a leaf object, with no occurrence or 1 and the range is dynamic. Human readable titles are defined. The content type is plain text, specified by the MIME type definition.

In line 111, the ellipsis indicates the position in the indicated DDF document that contains additional objects related to the run-time object <X ₅ > *.

The hierarchical structure of the device description framework shown by the graphical representation in FIG. 5A is mapped to the device description framework and the DDF document by encapsulating the specification described and presented above.

Due to the use of device description frameworks and DDF documents, the hierarchical structure realized by the encapsulation of object specification represents the hierarchical template structure of the derived management tree. Alternatively, instead of using explicit encapsulation to define a hierarchical structure, path information may be added to the object specification. The path information specifies a location within the hierarchical structure of the corresponding object.

The explicit scope of the fixed object "./AP" includes the object specification of the objects arranged in descending order starting at line 007 and ending at line 115. The specification of the fixed object "./AP" itself is included in the encapsulation.

The explicit scope of the run-time object <X ₁ > * includes the object specification of the objects arranged starting at line 018 and ending at line 114. The specification of the run-time object <X ₁ > * itself is included in the encapsulation.

The specification range of the fixed object "Px" includes the object specification of the objects arranged in descending order starting at line 027 and ending at line 037. The specification of the fixed object "Px" itself is included in the encapsulation. The abbreviation in line 036 indicates an omitted object specification arranged hierarchically.

The explicit scope of the fixed object "NAPDef?" Includes the object specification of the objects arranged in descending order beginning at line 038 and ending at line 048. Fixed object "NAPDef?" Declaration of its own is included in the encapsulation. The abbreviation in line 047 indicates an omitted object specification arranged hierarchically.

The explicit range of the fixed object "BS?" Includes the object specification of the objects arranged in descending order starting at line 060 and ending at line 113. The parent object "BS?" Declaration of its own is included in the encapsulation.

The explicit scope of the run-time object <X ₄ > * includes the object specification of the objects arranged starting at line 069 and ending at line 112. The specification of the run-time object <X ₄ > * itself is included in the encapsulation. The abbreviation in line 111 indicates an omitted object specification arranged hierarchically.

The explicit scope of the fixed object "Network?" Includes the object specification of the objects arranged starting at line 089 and ending at line 099. Fixed object "Network?" Declaration of its own is included in the encapsulation.

FIG. 5D illustrates an exemplary excerpt of a graphical representation of a management tree according to the graphical representation of the device description framework shown in FIG. 5A in accordance with an embodiment of the present invention. The management tree presented is constructed from a plurality of objects that are related to each other and derived from corresponding objects according to a defined hierarchical structure described by the device description framework.

The fixed object "./AP" represents the object of the highest hierarchy level in this representation. That is, the object "./AP" is subordinately related to the root object "/" of the management tree and arranged directly. The object "./AP" contains management related information regarding network access of the mobile communication terminal.

The object "./AP" has three child objects, namely the object "Prov_1", the object "Prov_2", the object "Prov_3", and the objects which are directly associated with and are arranged directly below. The objects are run-time objects corresponding to the aforementioned run-time object <X ₁ > *. In accordance with the above-mentioned provision for arranging run-time objects that are child objects of a common parent, all the run-time objects must serve for the same substructure. The actual substructure of run-time objects may be different because the objects directly and indirectly arranged and subordinately related may be dynamic objects. However, the run-time objects "Prov_1", the object "Prov_2", and the object "Prov_3" are set such that they relate to management structure information of the same function or application. In this specification, the run-time object "Prov_1", the object "Prov_2", and the object "Prov_3" relate to configuration information of network service providers. The fixed object "./AP" functions to summarize all management information about the network service provider configuration information.

The run-time object "Prov_1" has two child objects, the object "Px" and the object "NAPDef". In accordance with the above-mentioned provision for arranging run-time objects continuously, the object "Px" and the object "NAPDef" are both fixed objects. Corresponding to the cases defined for the appendable directly arranged and subordinately related objects, the leaf object "ClientID" and the fixed object "BS" can be dynamically arranged as child objects for the object "Prov_1", but the array It does not have to be. Here, none of these possible additional objects are implemented in the management sub-tree of the object "Prov_1". The object "Px" relates to proxy configuration information of the network provider service "Prov_1" and the object "NAPDef" relates to network access point definition configuration information of the network provider service "Prov_1".

The fixed object "Px" arranged subordinate to the object "Prov_1" has two child objects, the run-time object "Def_Px" and the run-time object "Px_1". Both run-time object "Def_Px" and run-time object "Px_1" correspond to run-time object <X ₂ > *. The object "Px" functions to summarize all proxy configuration information of the network provider service "Prov_1". If the additional run-time objects also correspond to the definitions described taking into account the run-time object <X ₂ > *, ie they have the same (and each common) format, then the additional run-time objects are the object "Px". Allowed to be associated as child objects for "

The fixed object "NAPDef" arranged subordinate to the object "Prov_1" has two child objects, the run-time object "NAP_Def" and the run-time object "NAP_1". Both run-time object "NAP_Def" and run-time object "NAP_1" correspond to run-time object <X ₃ > *. The object "NAPDef" functions to summarize all network access point definition configuration information of the network provider service "Prov_1". If the additional run-time objects also correspond to the definitions provided by the run-time object <X ₃ > *, that is, have the same (and each common) format, the additional run-time objects are assigned to the object "NAPDef". Allowed to be associated as child objects to

In the case of the run-time objects "Def_Px" and "Px_1", the fixed object "Px" is the above-mentioned from the run-time object "Prov_1" arranged above corresponding to the above-mentioned provision for separating run-time objects. Separate run-time objects. Similarly, for the run-time objects "NAP_Def" and "NAP_1", the fixed object "NAPDef" is the run-time object "Prov_1" arranged higher up corresponding to the above-mentioned provision for separating run-time objects. Separate the run-time objects from the.

The fixed object "Prov_2" has three child objects, the fixed object "NAPDef", the leaf object "ClientID" and the fixed object "BS". Since the directly-arranged and related parent object "Prov_2" has a run-time type, both the parent object "BS" as well as the parent object "NAPDef" have a fixed object type.

The fixed parent object "NAPDef" arranged subordinate to the object "Prov_2" has one child object, the run-time object "NAP_Def".

The fixed object "BS" arranged subordinate to the object "Prov_2" has one child object, the run-time parent object "Boot". The object "BS" relates to bootstrap configuration information of the network provider service "Prov_2". According to the object <X ₃ > *, the object "BS" has both child objects "Name" and "Country" having a leaf object type. Additional child objects corresponding to object <X ₃ > * may be related to object "BS".

6 shows a block diagram showing apparatuses comprising elements for performing the above-mentioned methods according to an embodiment of the present invention. The server device management agent 220 represents a network service that provides device management to the other counterpart client device management agent 320. The device management data may be provided or processed by each of the server device management agent 220 or the client device management agent 320. The server device management agent 220 is hosted by the server 20, which may be a server device corresponding to the server device mentioned with reference to FIG. 1. Similarly, client device management agent 320 is hosted by client 30, which may be a client device corresponding to the client device mentioned with reference to FIG. 1. Device management is performed between server 20 and client 30.

The server 20 and the client 30 are connected via some network. The network provides a logical communication connection between the server 20 and the client 30 that allows for the establishment of end-to-end communication during device management, which may be referred to as a device management session. The selection of logical connections and their bearers is described in FIG. 1.

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

The server device management engine 210 may apply to any client device functions or applications operable with the client 30 sent to the client 30 to allow a user to use well-configured device functions and / or device applications. Appropriate device management database 200 may be accessed, including information about managed client 30, such as configuration data and settings relating thereto. The device management database 200 also includes a portion of the management tree itself, a client related device description framework such as a DDF document defined and provided by the manufacturer to derive at least a portion of the management tree valid for the client device 30. DDF) information, information about the actual location in the management tree of the client 30 being processed, and additional device management related information. In addition, the server device management engine 210 of the server 20 may generate device management documents exchanged with the client 30. Since the DDF information (DDF document) allows the server 20 to encode the device specific management documents needed to be exchanged with the client 30 in a suitable manner according to the management tree implemented in the client 30. This generation is possible. For example, some management related information is sent to the client to enable certain client functions. This management related information will further be distributed among any management tree sub-areas (some divisions) that are initially set dynamically. Enable client 30 to discover and manage dynamics implemented in the correct manner, including providing information to corresponding device functions and / or device applications, and allows server 20 to provide a specific dynamic management tree to clients The client technology framework (DDF) as well as the client 30 as well as the client 30 operate the dynamic extension of the management tree in a suitable manner that enables the command to distribute the management details sent among the correct objects in the sub-area. Known for 310.

The counterpart client 30 may respond to a management request using the client management agent 320. In particular, the client device management agent 320 can access the device description framework (DDF) 310 and the device management tree 300, which define the hierarchical structures and objects of the management tree.

Both the server 20 and the client 30 can use the stored DDF information (DDF document) to encode the operations performed on the management tree of the client 20. The DDF information (DDF document) allows to create the dynamic portion (s) of the management tree needed to store new or dynamic management related information about client 30 operation. The generation of the portion (s) of the management tree based on the DDF information (DDF document) depends on which device the modification or adaptation of the management tree 300 is performed, so that the server device management agent 220 and the client device management agent Performed by 320.

First, a device description framework (DDF) is provided to a device management server, such as server 20, by the manufacturer of some client device, such as client 30. The server may perform device management with the client by generating the management operations as described above in a manner suitable for the client device. Moreover, the DDF information available to the client 30 (DDF document) allows the client to create a management tree upon switch-on of the client 30 if no management tree is available for the client 30 so far. do. The DDF information (DDF document) functions as mentioned above as a template for presenting and describing possible management trees and management trees in a common, extensible and flexible manner.

Presented elements of server 20 or client 30, server device management agent 220, server device management engine 210 and device database 200, as well as client device management agent 320, and device management tree ( 200 may also be configured by a data processing apparatus that may be included by server 20 or client 30. In addition, these elements may be constituted by a section of code for execution on the server 20 or the client 30 that includes instructions for performing the necessary processing operations.

As technology advances, it will be apparent to those skilled in the art that the present concepts may be implemented in a number of ways. The invention and its embodiments are thus not limited to the examples described above but may be modified within the scope of the claims.

Claims (20)

A method of adding at least one object to a hierarchical object structure, wherein the hierarchical object structure includes a plurality of objects that are hierarchically related, and the plurality of objects may have at least a first object that may have objects arranged subordinately. In a method comprising two different types of objects, referred to as a type and a second type, Defining at least one object, referred to as a child object, wherein the child object is part of the hierarchical object structure and referred to as a parent object arranged directly on top of the child object Relating to one of said objects being; And Comparing the types of the parent object and the child object, And if both types of the child object and the parent object are known to be of the first type, the second type of object is added between the parent object and the child object. The method of claim 1, The at least two different types of objects are a run-time type and a fixed type, the type of the first object is the run-time type, and the type of the second object is the fixed type How to. The method according to claim 1 or 2, Determining whether the parent object already has one or more directly arranged objects that are subordinately related; If there are one or more already existing objects, comparing the types of the one or more already existing objects and the child object; And If the types of the one or more already existing objects and the child object are known to be of the first type, adding the child object having a common format with the matching one or more additional objects. How to. The method according to any one of claims 1 to 3, Determining a type of the parent object; Determining if the parent object has one or more directly arranged objects already existing that are subordinately related; And If the parent object does not have already existing objects and both the parent object and the child object are known to be of the second type, Concentrating the parent object and the child object by adding a concentrated object having the second type and obtained from the parent object and the child object. The method according to any one of claims 1 to 4, Encoding at least a portion of a description document comprising information on the at least one object and the properties of the at least one object and based on the definition of the at least one object. Way. The method according to any one of claims 1 to 5, The hierarchical object structure constituted by the plurality of objects describes a hierarchical management structure; The hierarchical management structure is used for distributing management related information of a mobile communication enabled device among the plurality of objects, and some portions of the management related information are assigned to at least one of the plurality of objects. . The method according to any one of claims 1 to 6, The object format of an object specifies what kind of management related information is to be distributed among the object and the underlying objects associated with the object. The method according to any one of claims 1 to 7, The hierarchical object structure is information that is part of a device description framework and / or the hierarchical structure made up of a plurality of objects is a management tree, all of which are synchronization defined by the SyncML initiative. Method for producing a device according to a production language device management (SyncML DM). The method according to any one of claims 1 to 8, The technical document is at least part of a device description framework (DDF) document and / or the device description framework (DDF) document is in accordance with the corresponding technical framework document type description (DTD). A method for encoding an Extensible Generation Language (XML) encoded document. In a software tool for adding an entity to a hierarchical structure composed of a plurality of entities, When the program is implemented as a computer program for execution in a processing device, a network device, a network server, a terminal device, or a communication terminal device, the program part includes program portions for performing the operations of any one of claims 1 to 9. Featured software tool. In a computer program product for adding an entity to a hierarchical structure composed of a plurality of entities, 10. A computer program, when executed in a processing device, network device, network server, terminal device or communication terminal device, comprising loadable program code sections for performing the operations of any one of claims 1 to 9. And a computer program product. In a computer program product for adding an entity to a hierarchical structure composed of a plurality of entities, 10. When the computer program product is executed in a processing device, a network device, a network server, a terminal device or a communication terminal device, the computer program product is a computer readable medium for performing the method of any one of claims 1 to 9. And program code sections stored in the computer program product. A computer data signal implemented on a carrier wave representing a program which, when executed by a processor, causes the method of any one of claims 1 to 9 to be performed. A processing apparatus having a processing unit, a memory unit, and a communication interface, comprising: The processing unit is interconnected with the memory unit and the communication interface, the processing unit is configured to define at least one object included in a hierarchical object structure, the hierarchical object structure being a plurality of hierarchically related Consisting of objects, the plurality of objects comprising two different types of objects referred to as at least first and second objects, which may have objects arranged subordinately, The processing unit Define at least one object referred to as a child object, said child object being part of the hierarchical object structure and referred to as a parent object arranged directly on top of the child object Set to relate to one of the objects; The processing unit Set to compare types of the parent object and the child object, And if both types of the child object and the parent object are known to be of the first type, the second type of object is added between the parent object and the child object. A management system comprising a processing device and a hierarchical object structure, The hierarchical object structure is composed of a plurality of objects hierarchically related; The plurality of objects includes two different types of objects, referred to as at least first and second objects, which may have objects arranged in a row; Two objects of the plurality of objects of the first type are each separated by at least one object of the second type independent of their hierarchical position in the hierarchical object structure; The processing apparatus has at least one management element, wherein the hierarchical object structure manages management related information of a managed mobile communication enabled device, and the management element includes at least one of a hierarchical object structure including at least a plurality of objects. A management system, characterized in that a part can be created. The method of claim 15, The at least two different types of objects are a run-time type and a fixed type, the type of the first object is the run-time type, and the type of the second object is the fixed type Management system. The method of claim 15, And two or more objects having the first type and arranged directly to objects related to each other have a common format. The method according to claim 15 or 16, Two directly arranged objects that are related to each other and have the second type are composed of concentrated objects having the second type, wherein the concentrated objects are constructed from the two directly arranged objects that are associated with each other Management system. The method according to any one of claims 15 to 17, The processing device is a managed mobile communication enabled device including at least a device management element and a storage element, wherein the device management element is Generate the at least part of the hierarchical object structure, store the generated part of the hierarchical object structure in the storage element, and establish the part of the hierarchical structure; Distribute management object related information among the plurality of objects constituting the hierarchical object structure; Retrieve at least portions of the management related information from one or more of the plurality of objects to allow setting functions of the managed mobile communicable device or applications that are operable with the managed mobile communication enabled device; Management system, characterized in that. The method according to any one of claims 15 to 18, The processing device is a management server capable of providing management related information to a managed mobile communication enabled device; The management server includes a communication interface and a device management element for communicating with at least the managed mobile communication enabled device; The device management element Generate at least a portion of the hierarchical object structure; Generate one or more management messages for sending management related instructions in accordance with at least part of the hierarchical object structure; -Permit the transmission of the one or more management messages to the managed mobile communication enabled device in cooperation with the communication interface.