JP2009054163A - Method and device for defining object allowing setting of device-managing tree for mobile communication device - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To propose a suitable method for defining an object inside a hierarchically structured device definition framework (DDF). <P>SOLUTION: The DDF comprises a plurality of objects forming a kind of tree-like structure hierarchized and associated to each other. A fixed object and a runtime object are permitted that each of them has zero or more associated child objects directly below it. At least one new object is defined associatively with a parent object. An object type of the parent object is checked. When the parent object is the runtime object, it is possible to make at least the one new object one of the fixed object and a leaf object. The DDF is adopted so as to generate at least a part of a management tree. The management tree has the plurality of objects, and management related information of a device capable of performing mobile communication is distributed to them. <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

  The present invention relates to a method and apparatus for defining and adding objects in the form of a hierarchical object structure that allows setting a device management tree structure for management related information of mobile communication devices. In particular, the present invention relates to a method for creating one to several objects in the management tree. The above management tree results in a management tree having a dynamic structure, providing an efficient, clear, manageable and desirable organization. Furthermore, the invention relates to an apparatus and a system adapted to process the method described above.

  Data synchronization is a well-known problem for all users who process the same data using at least two different electronic devices. In general, synchronization is performed between a terminal device (such as a mobile phone) and a server-side device (such as an application in a local PC or dedicated synchronization server). Data of portable terminals such as portable computers, PDA terminal devices (personal information devices), mobile stations or pagers (registered trademark) can be used for network applications, desktop computer applications, or other communication systems. Although it is possible to synchronize with a database, in this case the term database should be understood as broad as possible, ie covering any set of data. In particular, calendar data and email applications are representative of synchronization.

  Synchronization is based on the use of different incompatible manufacturer specific protocols. Use of this different protocol limits the type of terminal device and data type and often causes trouble for the user. In particular, in mobile communication, it is important that data can be retrieved and updated regardless of the terminal device and application to be used.

  In order to improve the synchronization of application data, a language known as the Sync Markup Language SyncML based on Extensible Markup Language (XML) and a corresponding standardized document type description (DTD) have been developed. ing. By using the SyncML synchronization protocol in which messages in the form of SyncML format are used, it becomes possible to synchronize data of any application between the networked terminal device and any type of network server. The SyncML synchronization protocol works on both wireless and fixed networks and supports several transmission protocols.

  SyncML synchronization technology handles database synchronization. A problem similar to database synchronization is caused by the management of configuration data and settings required to operate electronic devices in a changing environment, such as a mobile telephone, operating in a mobile communications network on a different network carrier. is there. The configuration data and setting values include certain services such as network access point (NAP) definitions, proxy and gateway server addresses, information and definitions, short message service (SMS), multimedia message service (MMS), etc. A setting value associated with each carrier wave is required for the configuration such as address information of the server that provides the information. SyncML device management relates to the harmonization of such configuration data and set values. The respective configuration data and information are included in the form of managed objects, respectively, in association with the respective device characteristics and executable applications.

  The SyncML Device Management (SyncML DM) protocol allows management commands to be executed on managed objects, uses a SyncML synchronization protocol similar to the package format and associated definitions, and is also XML, binary encoded XML, etc. Based on the related XML encoding. The managed object may reflect a set of configuration parameters for the device, i.e., configuration parameters indicative of device characteristics and / or configuration parameters and settings of a software application executed on the device. Actions that can be performed on the object may include read and set parameter keys and values. Another managed object may be a runtime environment for a software application executing on the device. Actions that can be performed on this type of object may include installing, upgrading, or uninstalling software elements. Preferably, it is desirable that a dedicated management server provides desired configuration parameters, setting values, keys, and values for synchronizing the above-described device management information.

  Device management compliant with SyncML DM enables structuring of managed objects in the form of a hierarchical management tree that includes all information that can be managed using the SyncML DM protocol. This management tree is based on a permanent part of the management tree defined and provided by each electronic device manufacturer that supports SyncML device management. The actual management tree that exists in such an electronic device to be operated consists of the above-mentioned permanent part of the management tree that is expanded by one to several dynamically formed parts of the management tree. An actual management tree will be described in a certain way from a kind of pre-defined tree framework (device definition framework).

  Such a hierarchical structure of the management tree including management information necessary for the operation of the electronic device of the type described above is provided to the user by the terminal device, as well as the storage, management and / or configuration data and setting values. Obviously, it becomes quite complicated depending on the application that can be implemented in the terminal device that accesses the entire management tree for search. In particular, as a result of further individual functions added to the electronic device and applications implemented in the electronic device, the overall hierarchical structure of the management tree increases, causing a more complex hierarchical structure. The type and function and / or number of applications that improve the operation of the terminal device are unknown. However, it is desirable to perform maintenance management of the generated management tree for storing, retrieving, and / or managing configuration data and set values for future use.

  An object of the present invention is to provide a method for defining and adding at least one object of a hierarchical object structure composed of a plurality of individual objects. In that case, the management tree of the electronic device is described by the hierarchical object structure, and thereby the management tree obtained as a result is intended to be structured as effective as possible and durable in the future. is there. An efficient structured management tree is intended to perform efficient management and retrieval of one or more certain managed objects and to manage and retrieve the contents of the managed objects. In addition, an efficient structured management tree also takes into account limited resources (memory, processing power, etc.). Hierarchical object structures, in particular one or more objects included in the management tree, are objects based on several definition rules and conventions, and are very efficient and optimized as a result of consideration for these objects. A structured management tree will be obtained.

  The object of the present invention is a method for adding at least one object into a hierarchical object structure, a corresponding system and apparatus adapted to perform the method, and a computer program disclosed in the independent claims. Achieved with software tools. Preferred embodiments of the invention are disclosed in the dependent claims.

  According to embodiments of the present invention, a method for adding at least one object into a hierarchical object structure is provided. The hierarchical object structure is composed of a plurality of objects. These objects are hierarchically related to each other. The hierarchical relationship of the objects can be obtained by using at least two different types of objects, a first object type and a second object type. Both the first object type and the second object type can have subordinate objects directly associated with these objects.

  The at least one object is defined so as to be associated with a parent object that is arranged above the at least one object and is directly associated with the at least one object. That is, the at least one object to be defined is a child object of the parent object. The parent object is part of the hierarchical object structure. The object type of the parent object is acquired, and the object type is compared with the object type of the child object to be defined. If both the object types of the parent object and the at least one child object match each other, and if both object types match the first type, an object having a second object type becomes the parent object. And the child object above. Separation as described above ensures that at least one object having the second object type always separates objects having the first object type in the hierarchical structure of these objects.

  According to embodiments of the present invention, the at least two different object types include a runtime object type and a fixed object type. The first object type described above corresponds to the runtime object type, and the second type described above corresponds to the fixed object type.

  According to embodiments of the invention, at least the following object types are suitable: fixed object type, runtime object type, leaf object type.

  Each object that includes any one of the aforementioned object types has one directly associated object placed on top, denoted as a parent object. However, in the case of an object that includes a fixed object type or a runtime object type, it is permitted to include zero, one, or two or more objects that are directly associated with the object and placed below the object. In these different object types, formation of a hierarchical object structure constituted by a plurality of objects each individually including one of the above object types is allowed.

  Accordingly, the above-described method of adding at least one object according to an embodiment of the present invention can be described as follows, in addition to the above. The at least one object is defined and associated with a parent object. The object type of the parent object is acquired as an inspection target. If the object type of the parent object is a fixed object type, the at least one object is allowed to have a fixed object type, a runtime object type, or a leaf object type. If the object type of the parent object is a runtime object type, at least one object is allowed to have either a fixed object type or a leaf object type.

  By defining at least one object, it may be necessary to further define object properties. These object properties may include one or more properties from the group including AccessType, DefaultValue, Description, DFFormat, Occurrence, Scope, DFTitle, and DFType. These object properties that may occur are not limited to the properties presented above, and other different object properties may be valid properties.

  According to an embodiment of the invention, it is checked whether the parent object contains one or more pre-disposed objects associated as subordinates. If one or more existing objects already exist, one or more object types of these one or more objects are determined and the obtained one or more object types are child object objects. Compared to type and added to hierarchical object structure. If the obtained one or more object types and the object type of the child object are all proved to be the first object type (ie, runtime object type), the child object and at least one existing A child object is added to the parent object under the condition that the object has a common format.

  The format of an object is what kind of management related information is distributed between the respective objects, and objects arranged in a hierarchy are allowed to be associated as subordinates of the respective objects, and / or It shall be defined whether the management related information is suitable for association with the distribution. Objects having a common format define that similar management-related information associated with the same device function and / or device application is distributed between these objects and the objects arranged below.

  The object type of the parent object is determined according to an embodiment of the present invention. In addition, a check is made whether the parent object already has one or more child objects. If the parent object has no child objects, and the parent object and at least one object to be defined both have the second object type, the parent object and the at least one object are the second Aggregated into a single object with object type. This aggregation is performed by replacing the parent object and at least one object with a single object.

  According to an embodiment of the invention, at least a part of the description document is encoded based on at least one predefined object. At least a portion of the encoded description document includes information about at least one object and predefined properties of the at least one object. With this encoded description document, it is possible to obtain a hierarchical object structure for storing management-related information of an electronic device distributed between a plurality of objects included in the hierarchical structure. By parsing the encoded description document or one or more related parts of the description document, respectively, one to several objects and at least a part of the hierarchical object structure are obtained. Also good.

  According to the embodiment of the present invention, the hierarchical management structure is described by the hierarchical object structure including a plurality of objects. This hierarchical management structure may be understood as a hierarchical framework of a database, and management related information of the electronic device of the mobile communication terminal is stored in the database in accordance with the hierarchical structure. Some portion of the management related information that is configuration data and / or set values is associated with or included in the object.

  According to the embodiment of the present invention, the object format is such that any kind of management related information is distributed between the objects, and the objects arranged in a hierarchy are associated as subordinates of the objects. Defines if allowed and / or whether the management related information is suitable for association with the delivery. Objects having a common format define that similar management-related information associated with the same device function and / or device application is distributed between these objects and the objects arranged below.

  According to an embodiment of the present invention, a hierarchical object structure including a plurality of objects corresponds to device definition framework (DDF) information and / or a hierarchical object structure including a plurality of objects is managed for device management of an electronic device. Corresponds to the tree. Device definition framework (DDF) information and / or management trees are provided and standardized by the SyncML initiative in the form of a synchronous markup language device management (SyncML DM) standard.

  According to an embodiment of the present invention, the description document corresponds to a device definition framework (DDF) document. A DDF document is an Extensible Markup Language (XML) encoded document that is encoded based on a corresponding description framework document type description (DTD). Extensible Markup Language (XML) is not limited to the clear (plain) text XML encoding presented below, but also covers binary encoding based on XML or the like.

  According to an embodiment of the present invention, a software tool is provided for adding at least one object defining a hierarchical object structure into a plurality of objects. The software tool includes a program portion that, when implemented and / or executed in the form of a computer program, performs the processing of the method described above according to any embodiment of the present invention.

  According to an embodiment of the present invention, there is provided a computer program for adding at least one object among a plurality of objects for determining a hierarchical object structure. The computer program includes a loadable program code portion for executing the processing of the above-described method based on any embodiment of the present invention, which is executed by a processing device such as a computer or a network device.

  According to an embodiment of the present invention, a computer program product is provided, and when the program product is executed by a processing device of a computer or a network device, the aforementioned method is executed according to any embodiment of the present invention. The program product includes a program code portion stored in a computer readable medium.

  According to an embodiment of the present invention, a computer data signal is provided. The computer data signal is embodied in the form of a carrier wave and represents a program or program code portion that, when executed by a processor, causes the aforementioned method to be performed according to any embodiment of the present invention.

  According to an embodiment of the present invention, a processing apparatus including a processing unit, a memory unit, and a communication interface is provided. The processing unit is connected to a memory unit and a communication unit that enables data exchange between the processing unit and the memory unit. The processing unit of the processing device is configured to allow the addition of at least one object into the hierarchical object structure. The hierarchical object structure is composed of a plurality of objects. These objects are hierarchically related to each other. By using at least two different types of objects, a first object type and a second object type, a hierarchical association of these objects is obtained. Both the first object type and the second object type are allowed to have subordinate objects directly associated with the first and second object types.

  The at least one object is defined to be associated with a parent object that is placed above the at least one object and is directly associated with the at least one object. That is, the at least one object to be defined is at least one child object of the parent object. The parent object is part of the hierarchical object structure. The object type of the parent object is obtained, and the object type is compared with the object type of at least one object to be defined. If both the object types of the parent object and the at least one child object match each other and both object types match the first type, the object having the second object type is It is placed between the at least one object. The at least one object having the second object type ensures that the objects having the first object type are always separated in such a way that their hierarchy depends on each other.

  According to an embodiment of the present invention, there is further configured a processing device that enables the processing of any one of the preceding embodiments that illustrates a method of adding at least one object into a hierarchical object structure. Is done.

  According to the embodiment of the present invention, a management system including a processing device such as a client side device or a management server side device to be managed and a hierarchical object structure is provided. The hierarchical object structure is composed of a plurality of hierarchically related objects. Individual objects of the plurality of objects have a certain object type that is at least two applicable object types, a first object type and a second object type. Individual objects having the first object type or the second object type are allowed to have directly arranged objects associated as subordinates of these individual objects.

  Two individual objects arranged in a hierarchy with each other and associated with each other, both having a first object type, between the two objects having a second object type in the form of a hierarchy Separated by at least one placed object. That is, it is not permitted to arrange hierarchically related objects having the first object type directly with respect to each other.

  The processing device includes at least one management component capable of generating at least a part of the hierarchical object structure. Thereby, the hierarchical configuration of the hierarchical object structure is associated with at least a partial hierarchical configuration of the resulting hierarchical object structure. The hierarchical object structure provides functions for searching, storing, and managing management-related information of a device that can perform management-target mobile communication.

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

  According to embodiments of the present invention, at least the following object types are suitable for use: fixed parent object type, runtime parent object type and leaf object type.

  Each object that includes any one of the aforementioned object types has one directly associated object placed at the top, shown as a parent object. However, in the case of an object including a fixed parent object type or a runtime parent object type, the object is directly related to the object and does not include any objects arranged below the object, or one or more objects are It is allowed to include. With these different object types, formation of a hierarchical object structure composed of a plurality of objects each individually including one of the above object types is allowed.

  According to an embodiment of the present invention, two or more objects having a first type and having a single object directly disposed above and associated therewith have a common format. The format of an object is what kind of management related information is distributed between the respective objects, and objects arranged in a hierarchy are allowed to be associated as subordinates of the respective objects, and / or It shall be defined whether the management related information is suitable for association with the distribution. Objects having a common format define that similar management-related information associated with the same device function and / or device application is distributed between these objects and the objects arranged below.

  According to an embodiment of the present invention, two directly arranged objects that are associated with each other and both have the first type, ie, a parent object and a child object that both have the second type, It is replaced in the form of an object tree that forms a hierarchy with aggregated objects having two object types. This aggregate object is composed of the two replaced objects. That is, the hierarchical object structure comprises an aggregate object obtained from the two directly arranged objects, and as a result, a direct arrangement of only the parent object and its child objects (both objects of the second type). Configuration will not occur in a hierarchical object structure.

  According to the embodiment of the present invention, the processing device is a device capable of mobile communication of a management target including at least a management component of a client side device, that is, a client management agent and a storage component. At least a part of the hierarchical object structure is generated by the client side device management component, a part of the hierarchical object structure is determined, and the hierarchical object structure is entered into the storage component of the device capable of mobile communication to be managed. At least a part can be realized. This implementation may implement at least a portion of the generated hierarchical object structure that dynamically extends the hierarchical object structure into a currently existing hierarchical object structure. The client-side device management component distributes management-related information among a plurality of objects constituting the hierarchical object structure, and further configures a device and / or a function of an application that can be implemented using the device. It is possible to retrieve at least a part of the management related information from one or more objects of a plurality of objects.

  According to the embodiment of the present invention, the processing device is a management server side device including at least a server side device management component, that is, a server management agent and / or a service management engine and a communication interface. The server side device management component generates at least a part of a hierarchical object structure and one or more management messages including a management instruction and corresponding management related data based on at least a part of the generated hierarchical object structure Enabling the generation of The server-side device management component can further control one or two or more acquired management messages with a communication interface and transmit the management message to a device capable of managed mobile communication.

  The one or more management messages dynamically expand the stored hierarchical object structure of the server-side device based on the transmitted management information, and the management-related information provided by the server-side device is stored in the hierarchical object structure. Management-related information is retrieved from a certain object of the hierarchical object structure specified (addressed) by the address information means obtained from at least a part of the generated hierarchical object structure. It is possible to instruct a device capable of mobile communication to be managed.

  The present invention will be further described in detail according to embodiments with reference to the accompanying drawings.

  Hereinafter, embodiments of the present invention relating to a system supporting the SyncML device management standard or the related SyncML standard will be described, but the present invention is not limited to this system. Information regarding the SyncML standard and the SyncML Device Management (SyncML DM) standard can be obtained from the SyncML initiative, which provides publicly available full standard documentation. The same or equivalent parts, features and / or processes shown in the figures will be referred to using the same reference numerals.

  FIG. 1 shows a block diagram illustrating a set of electronic devices that can perform information synchronization between devices. Suppose that certain database contents of the desired mobile terminal device are matched with the contents of the database provided by the instructed device. Conventionally, a mobile terminal device functions as a synchronization client that uses a dedicated server-side device to harmonize or synchronize certain predefined data with the contents of a database or several databases. FIG. 1 is a diagram illustrating a plurality of possible client-side devices and server-side devices for synchronization processing. Typically, the client-side device is a mobile station such as a mobile phone 17, a personal information device (PDA), a mobile computer 15 such as a notebook, a digital camera 16, or a personal computer (PC). Furthermore, the dedicated synchronization server side device may be a desktop computer such as the personal computer 10, a mobile computer such as the dedicated network server 11 or the notebook 12. From the perspective of a mobile terminal device connected to a dedicated service providing device, the above presentation concept for synchronization will be explained, but the function of the client side device is not limited to the above mobile terminal device. Note that there is no.

  Corresponding synchronization processing compliant with the SyncML protocol standard or the SyncML device management protocol standard can also be set via an appropriate logical communication connection. The logical communication connection may be performed by an arbitrary communication network combined with a transport protocol adapted to the synchronization protocol. A suitable communication network may be a local area network (LAN), a local area network (WAN) that may comprise a local area network (LAN), the Internet, and a corporate intranet, but a wired base such as a universal serial bus (USB). Or a standardized serial communication (such as RS-323). Participating synchronization devices can support mobile communication wide area system (GSM) service and / or general packet radio service (GPRS) mobile communication network, general mobile communication system (UMTS) network, wireless local area network ( It may be connected via a wireless communication network such as a third generation mobile communication network such as WLAN), Bluetooth network, or infrared network (IrDA). A single communication network of the type described above may provide logical communication connections between these participating synchronization devices, but some of the types described above interconnected by dedicated network routing devices. It is also possible to make the logical communication connection by using a communication network.

  In conjunction with the SyncML protocol standard, the SyncML device management protocol may also be implemented on top of an appropriate protocol that conforms to the type of communication network employed, in conjunction with the SyncML synchronization protocol, and thus the SyncML device management protocol standard. Good. Suitable protocols that can implement the SyncML synchronization protocol at the top level include hypertext transfer protocol (http), wireless application protocol (WAP) for short-range radio frequency connection (Bluetooth) or infrared connection (IrDA) ) Standard wireless session protocol (WSP), wireless datagram protocol (WDP), universal serial bus (USB), object exchange protocol (OBEX) used for cable connection such as RS-232, transport control protocol / Internet At the top of the protocol (TCP / IP) stack and the transport layer are services provided by email protocols (such as simple mail transfer protocol, SMTP).

  Short message SMS (short message service), another signaling type transmission method (USSD: unstructured supplementary service data, etc.), circuit-switched data calls, and networks that form the basis for using packet-switched data transfer services Correspondingly, it is possible to transfer in the lower layer.

  Although general synchronization as well as device management synchronization has been described above, the following description of the innovative concept makes explicit reference to the SyncML DM protocol.

  The SyncML DM service itself is based on the exchange of management documents, each of which includes instructions intended to synchronize device management data, ie, configuration data and setting values. It can be divided into multiple messages or packages. The SyncML DM protocol includes two parts: a setup phase that includes authentication and exchange of device information and a management phase. The management phase can be repeated as many times as the server desires.

  The management phase consists of multiple protocol iterations. That is, the protocol repetition means a package from the managed client side device to the management server side and a package from the management server side to the managed client side device. Whether the session needs to be continued is determined based on the contents of the package sent from the management server side to the managed client side device. When the management server sends a management operation that requires a response (status or result) from the managed client side device in the form of a package, the management phase of the protocol includes a client side response to the management operation. Continue the new package from the managed client side device to the management server side. The response package from the managed client side device initiates a new protocol iteration. The management server sends a new management operation package and thus can start a new protocol as many times as the management server desires.

  In order to give a general overview of the package exchange, an exemplary and valid total package sequence based on the setup phase and the management phase is described in the following section.

  Package 0-Start Management Session: Most managed client-side devices may receive a no-response message, sometimes called "notification". The management server can take advantage of this notification capability that causes the client to initiate a connection back to the management server. Several bearers can be used to send management start notifications. Note that the same effect of receiving a management start notification can occur in different ways.

Package 1-Initialization from the managed client side device to the management server side: The purpose of the initialization package sent by the managed client side device is as follows:
-Send managed client side device information (manufacturer, model, etc.) to device management server side.
-Identify the client side devices to be managed with respect to the management server.
Notifying the server whether a management session has been initiated by the server (by sending a trigger in package 0) or by a client (such as an end user selecting a menu item).

Package 2-Initialization from the management server side to the managed client side device: The purpose of the initialization package sent by the management server is as follows:
-Specify a device management server for the client side device to be managed.
-Sending management commands and management data as options to the client device to be managed.
-Send another optional command as an option, such as a command for user interaction.

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

Package 3-Response of managed client side device to management server: The purpose of this management package is as follows:
-Send the result of the management command sent from the management server to the managed client.
-Send the result of an optional user interaction command.

Package 4-further management server operations: The purpose of this management package includes:
-Send any additional necessary management operations and commands from the management server side to the managed client side.
Close the management session.

  Further, the package 4 including another management operation causes a response of the managed client side device in the form of a kind of package 3. Accordingly, the management session can include packages 3 and 4 having an arbitrary number of iterations.

  The above-mentioned SyncML DM service, which is performed based on the exchange of management messages according to the above-described phases and packages, is structured to manage information to be managed and to perform actions on the objects constituting the management tree each including this information. is there. This management tree is a well-defined, hierarchically structured arrangement of all available, usage management entities, in which case their location, and correspondingly, some management The address designation of the position indicating certain information included in the business entity reflects the contents of the management information. In light of the above broad definition of a database, the management tree can be understood as a database for storing configuration data and settings in a well-defined hierarchical organization. The position of the management related information in the management tree is correlated with a certain device function and / or device application that employs the respective management related information for operation. This well-defined hierarchical structure is called the management tree. Hierarchical organization of managed objects primarily addresses the need to provide an appropriate and unique unique addressing scheme for each single managed object that corresponds to a hierarchically structured arrangement. is there. The origin of a managed object arranged in all hierarchies by a certain superordinate object (root entity) is provided. That is, the root object of the management tree is an object used as a relative reference when the management object is arranged.

  Different types of managed objects are distinguished. The hierarchical object structure, in particular the management tree, has internal objects as well as leaf objects, also denoted as (internal) nodes below. Leaf objects are distinguished between leaf objects that are allowed to contain any but predefined content and link objects that contain address information of certain objects in the hierarchical object structure. An internal object, or internal node, represents an entity used to associate one or several objects that depend on it. That is, the internal node represents one to several, but in some aspects, a predetermined number of directly (instantly) related entities that perform a hierarchical structuring that includes objects arranged below in the hierarchy. Yes, the object will be shown as one or more child objects or child nodes that are associated and arranged respectively with respect to the parent object or parent node. Each internal object, i.e., the internal node itself, is associated with one internal object, i.e. an internal node, or a root object / node that is an internal object with the highest hierarchical level, i. Based on the inter-concatenation, a hierarchical object structure, that is, a management tree is set. The internal object is distinguished between a permanent internal object and a dynamic internal object. As the “persistent” naming implies, persistent objects always exist in the management tree, regardless of the operational state of any managed client-side device or application that is running. In contrast, dynamic objects are added and replaced by managed client-side devices or management servers that address the need for information contained in a hierarchical structure (dynamic part of the management tree). Changes and / or deletions can also be made.

  The leaf object is associated with the upper internal object, but the lower object is not allowed to be associated. That is, it does not have an associated child object. Instead, the leaf object is used as a container for containing some content of any but predefined content type. That is, the leaf object may include a certain content, a value such as an integer value, a larger value (plain text, an array of values), a complicated data type, an image, and a program code. The leaf object includes configuration data and / or setting values necessary for device operation and / or application operation. The leaf object represents the “end” of the branch object of the management tree. That is, the lowest hierarchical level of each branch of the management tree.

  FIG. 1b shows an example of a part of a management tree implemented in a client side device to be managed such as a mobile communication device. The example portion of the management tree has a root object “/”, and the management tree is set from this root object. In this document, the illustration of the example portion of the management tree is limited to the top level structure. A device definition framework (DDF) object, a device information (DevInfo) object, a device detailed information (DevDetail) object, and an example object AP are drawn below the root object. All of these objects are internal objects, and further objects can be provided below this internal object. The number of objects associated with the root object (root node) “/” is not limited to the number of objects illustrated above. These are merely examples. That is, 0, 1 or 2 or more additional objects can be associated as subordinate objects of the root object “/”. The objects DDF, DevInfo, and DevDetail represent selected mandatory objects (but not limited to these mandatory objects) for the client-side device to be managed, and these mandatory objects perform operations related to the SyncML device management service. An object that allows you to do it. The DevDetail object and the DevDetail object are subordinate objects, which means that an unlimited number of further subordinate objects (and link objects) are arranged below this subordinate object. The management tree may be set when the managed client side device is switched on. It is also possible to perform management tree adaptation processing and / or modification processing in accordance with the above-described exchange of management information corresponding to the SyncML device management service.

  Individual objects, i.e. individual information contained within an object, can be addressed. The addressing of an object is performed based on the instance identifier. Instance identifiers are assigned to individual objects in the management tree. When assigning instance identifiers to objects, it must be taken into account that the addressing of individual objects must be unique. This means that a subordinate object may have one or more directly related subordinate objects (subordinate object, leaf object, link object). In order to obtain unique addressing for individual objects in the management tree, the instance identifiers of these directly associated subordinate objects must be different from each other. The address information includes instance identifiers from the root object to the operation target object, and these instance identifiers are passed according to the hierarchical structure of the management tree. Each instance identifier is separated by an appropriate delimiter.

  The concept of management tree is provided for a wide number of managed client-side devices that perform different functions and / or for managed client-side devices that operate a wide number of different applications that are not identical. . This means that the management target client side device cannot be described in the management tree having the same structure, and therefore the behavior of the management target client side device in terms of the SyncML device management service is different. It is.

  The above problem is handled by the device definition framework (DDF). By using the device definition framework (DDF), the manufacturer of the client-side device to be managed can provide information that describes the management tree in all dynamic (runtime) representations of the device definition framework. As a result, it becomes possible to manage the client side device to be managed by the management server based on the SyncML device management service. It is desirable to implement the device definition framework so that the device definition framework (DDF) can be applied in a flexible and easily extensible manner, and so that future requirements for the management tree can be covered. . The device definition framework (DDF) is a summary description of objects. Thus, it is possible to derive the management tree itself from the device definition framework (DDF), in which case the device definition framework (DDF) corresponds to the corresponding managed client side that is adapted to different situations. Supports all valid wide numbers of individual management tree structures used as devices. Thus, this device definition framework (DDF) includes descriptive objects that enable deriving objects (persistent / dynamic internal objects, leaf objects and link objects), object properties, and object chaining (management Association and arrangement configuration in the tree). Accordingly, the device definition framework (DDF) description objects include definitions that effectively detail each of the objects and therefore the information required to set up the management tree. A device definition framework (DDF) description object reflects the hierarchical object structure and functions as a template hierarchical structure of the resulting management tree.

  The inventive concept of the present invention relates to rules and regulations that are applied when defining and adding objects described in the Device Definition Framework (DDF) so that the above-mentioned advantages are achieved.

  A description of the management tree and corresponding device definition framework (DDF) will be shown in conjunction with the graphical depiction.

  FIG. 2a shows a table illustrating the elements used for the graphical notation of objects distinguished by object type. This graphical representation is compared with the meaning of the object (object type). Corresponding to the objects that can be used to form the management tree, the table includes fixed (parent) object types, runtime (parent) object types, and leaf object types. This document shows another additional object type, the linked object type. As described above, a link object type is a specific leaf object type that stores addressing information of some other object in a 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 and encodes a uniform resource indicator (URI) or any similar corresponding or related addressing value. . A fixed parent object with a fixed parent object type is represented by a rectangle containing a title that displays the instance identifier (replaced by the word “fixed” in this figure), and a runtime object with a runtime object type is A leaf object represented by a rectangle with rounded corners containing a title (replaced by the word “runtime” in this figure), a leaf object with a leaf object type is simply its title (in this figure “leaf” Finally, a link object with a link object type is represented by an underlined title representing an instance identifier (in this figure it is replaced by the word “link”) Thus it is simply represented.

  The object title (ie, instance identifier) is one property element (named NodeName element) of the description object. As described above, an object can be specified by a NodeName element having a preset value (fixed object) or a dynamic assignment value (runtime object). Still other property elements may or may not contain the following property elements: AccessType, DefaultValue, Description, DFFormat, Occurrence, Scope, DFTitle, and DFType. It should be understood that these property element presentation lists are for illustrative purposes only and are not limited to the above property elements. The AccessType element specifies which commands are allowed for an object (which actions are allowed to be taken on an object) and which commands must be defined. AccessType elements can be get, delete, add, and replace. The DefaultValue element defines an object value used in the apparatus as an option when the object value is not explicitly set to another value. The Description element defines an optional object description that can be understood by humans. The DFFormat element defines the required data format of the object. The Occurrence element optionally specifies the number of instances that may arise from the object in the management tree, i.e., the number of child objects that are directly arranged to be associated with, in particular, one parent object. The Scope element specifies as an option whether this object describes a persistent object or a dynamic object. The DFtitle element defines an optional object name that can be understood by humans. The DFType element defines an object value MIME type (multipurpose Internet mail extension type) for leaf objects and a null or DDF document name for internal objects.

  A fixed parent object is a persistent object or a dynamic internal object. The title of the parent object is fixed and used as an instance identifier in the management tree. If the Occurrence of the fixed parent object is 1 (One), the corresponding internal object is a permanent internal object. In other words, the Scope is permanent, but if the Occurrence of the fixed parent object is 0 or 1 (ZeroOrOne), the Scope of the fixed parent object becomes dynamic and, as a result, is executed by the management server. Sometimes it is possible to create and delete internal objects.

  The runtime (parent) object is a dynamic internal object. The title of the run-time object is not fixed. That is, the dynamic internal object name is dynamically defined at the time of creation and execution, and is used as an instance identifier in the management tree. The dynamically defined instance identifier can have an arbitrary character string consisting of alphanumeric characters (up to 9 characters). Hereinafter, the title of the runtime object will be represented by <X> or <Y>.

  The titles of leaf objects and link objects are fixed. While it is necessary to specify the content type (its MIME type) of the content included in the leaf object, in order to encode address information such as URI (Uniform Resource Indicator), the content type of the link object is the corresponding leaf object. Specifies the content type for.

  The following rules show the rules and methods associated with objects having the certain object type. The presented object type does not limit the object type to this object type. This is because it is possible to include additional object types that do not interfere with the inventive concept.

  FIG. 2b is a diagram illustrating a table illustrating special characters further used for graphical representation of objects. The table above compares the characters and their meanings. These characters represent the object's Occurrence property element. This Occurrence element optionally specifies the number of object instances that can occur in the management tree. By default and when no additional characters are added to the title of the object, the number of occurrences of the corresponding object in the management tree is (exactly) once. The “+” sign added to the title of the object indicates that the number of occurrences of the corresponding object in the management tree may be one or more than one (Occurrence: OneOrMore, OneOrN). ). The “*” sign added to the title of the object indicates that the number of occurrences of the corresponding object in the management tree may be zero or more than zero (Occurrence: ZeroORMore, ZeroOrN). The “?” Sign added to the title of the description object indicates the number of occurrences of the corresponding object in the management tree once or zero (Occurrence: ZeroOrOne).

  The following FIGS. 3a-3e illustrate the hierarchy embodied in the next FIG. 4a by way of an example of a method for adding at least one object according to an embodiment of the invention while defining and adding objects. FIG. 4 is a diagram illustrating rules and rules applied and observed in an object structure.

  FIG. 3a is a diagram showing a first arrangement configuration of description objects according to the embodiment of the present invention. The first arrangement configuration includes a first fixed (parent) object “Node_1”, one or more runtime (parent) objects <X> *, and a second fixed (parent) object “Node_2”. Including. One or more runtime objects <X> * are associated as subordinates of the first fixed (parent) object “Node_1”, whereas the second fixed parent object “Node_2” has one or more Associated with each of the subordinates of the runtime object <X> *.

  Based on the device definition framework (DDF) structure described above and based on the graphic definition of the description object, a portion of the resulting management tree is a first fixed parent object “Node_1” with an instance identifier “Node_1”. And zero, one, or two or more runtime objects <X> *. The instance identifier of the runtime object <X> * is defined at the time of execution, for example, “run-time_1”, “run-time_2”, and the like.

  Assume that one runtime object <X> * with instance identifier “run-time_1” has been created (according to the above illustration). The runtime object “run-time_1” is associated as a subordinate of the fixed object “Node_1”. That is, the runtime object “run-time_1” is a child object of the fixed object “Node_1”. According to the range definition (Scope element) of the second fixed object “Node_2”, the runtime object “run-time_1” is a parent object for the fixed object “Node_2”. That is, the fixed object “Node_2” is a child object for the runtime object “run-time_1”.

  Assume that two runtime 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”. Further, according to the range definition (Scope element) of the second fixed object “Node_2”, the runtime object “run-time_1” is a parent object for the fixed object “Node_2”, and at the same time, the runtime object “run-time_2”. "Is a parent object for the fixed object" Node_2 ". Both these child objects with the same instance identifier “Node — 2” can be distinguished by different dependency states (associations, parent objects) of these child objects in the management tree.

  FIG. 3b is a diagram showing a second arrangement configuration of description objects according to the embodiment of the present invention. The second arrangement configuration includes a first fixed object “Node — 3”, one or more runtime objects <Y> +, a second fixed object “Node — 4”, and a leaf object “Leaf”. The one or more runtime objects <Y> + are associated as subordinates of the first fixed object “Node — 3”, whereas the second fixed object “Node — 4” and the leaf object “Leaf — 1” Associated with one or more runtime objects <Y> + as subordinates of each. FIG. 3b illustrates the “simplest” situation, meaning a one-time object <Y> + with two child objects: one fixed object “Node — 4” and one leaf object “Leaf — 1.”

  Based on the device definition framework (DDF) structure described above, a part of the resulting management tree includes a first fixed object “Node — 3” having an instance identifier “Node — 3” and a first fixed object “Node — 3”. ”And at least one or more runtime objects <Y> + (that is, child objects of the first fixed object“ Node — 3 ”that are directly arranged with respect to the first fixed object“ Node — 3 ”. ) And The instance identifiers of these child objects are defined at the time of execution and can be called in the same manner as, for example, “run-time_1”, “run-time_2”, and the like. Run-time objects “run-time_1”, “run-time_2”,. . . Each has two child objects, a second fixed object “Node — 4” and a leaf object “Leaf — 1”.

  The above structure described with reference to FIGS. 3a and 3b represents the definition structure of a device definition framework (DDF) that is allowed to be used. In contrast to this structure, FIG. 3c shows the arrangement of objects to be avoided based on the rules and rules that illustrate the concept of the present invention.

  The first arrangement configuration of the description object includes a number of first run-time objects <X> * whose occurrence count is 0, 1 or more, and the occurrence count is also 0, 1 Some second runtime objects <Y> * that are times or more times. The example of FIG. 3c shows a chain of one first runtime object <X> * and one second runtime object <Y> *. More generally, if there are one or more first runtime objects <X> * and one or more second runtime objects <Y> *, the first runtime object Each of <X> * is a parent object for one to several second runtime objects <Y> * which are child objects for the first runtime object. Accordingly, each of the one or more first runtime objects <X> * that are parent objects has a dynamic assigned instance identifier. Furthermore, each of the one or more second runtime objects <Y> * that are child objects also has a dynamic assigned instance identifier.

  Such a hierarchical object structure that includes a series of directly arranged run-time objects with dynamically assigned instance identifiers at different hierarchical levels makes it easy to identify objects, especially in terms of exploring the management tree It is easily understood that it represents a complex structure that is difficult to manage due to a lack of ability to do so.

  As a whole rule for defining objects, it is necessary to associate a runtime object as a subordinate of a fixed parent object, and this runtime object is a fixed object and / or leaf object associated with at least one subordinate And / or function as a parent object for the link object.

  FIG. 3d is a diagram illustrating an arrangement configuration of objects to be aggregated into a single object according to the embodiment of the present invention. This arrangement configuration has two continuous fixed objects, a fixed object “Node_5” and a fixed object “Node_6”. In this case, the only child object of the fixed object “Node_5” is the fixed object “Node_6”. Arranging this kind of fixed parent objects does not indicate useful information, so that the fixed object “Node_5” and the fixed object “Node_6” may be aggregated into a single fixed object “Node_5Node6” indicating the same information. it can. This aggregation simplifies the resulting management tree in terms of exploring the management tree and accessing the objects placed below the aggregated fixed parent object “Node_5Node6” by simplifying their addressing. Is called.

  FIG. 3e is a diagram illustrating an arrangement of objects to be avoided according to an embodiment of the present invention. The arrangement configuration includes the first runtime object <X> * and the fixed object “Node — 7” directly associated with the second runtime object <Y> + child object. The first runtime object <X> * and the second runtime object <Y> + are individually associated with objects of different formats. This means that the first runtime object <X> * and the second runtime object <Y> + are related to different functions and applications, respectively. The format of the object is what kind of management related information is distributed between the respective objects, and objects arranged in a hierarchy are allowed to be associated as subordinate objects of the respective objects, and / or It is defined whether the management related information is suitable for association with the distribution. Objects having a common format define that similar management-related information associated with the same device function and / or device application is distributed between these objects and the objects arranged below.

  In order to obtain a manageable and clear management tree, different types of runtime objects should not be associated as subordinates of a common parent object (which is a fixed object) as shown in Figure 3e above. is there. Instead, runtime objects of different formats associated with different functions and applications of managed client-side devices are each associated with a different parent object (which is a fixed object), clearly systematic and available, In addition, a manageable management tree is provided.

  FIG. 4a shows a first exemplary flow chart for defining objects in accordance with one embodiment of the present invention. The first exemplary flow chart illustrates an example embodiment that takes into account the rules and conventions illustrated and described above for defining objects, properties of the objects, and dependency states, respectively. ing.

  In process S100, a process sequence is started according to one embodiment of the present invention that defines / adds at least one new object.

  In step S110, the object type of the parent object is determined. This parent object for the new object can be a fixed object or a runtime object. According to the rules and regulations described in connection with FIG. 3c, it is avoided to arrange two runtime objects in succession in the hierarchical object structure and the device document framework (DDF), respectively. Correspondingly, a check is made as to whether the parent object is a runtime object or a fixed object. If the parent object is of runtime type, the illustrated processing sequence continues to step S140 and it is guaranteed that continuous runtime objects cannot be defined and added. If the parent object is of a fixed type, the illustrated processing sequence continues to step S120, and any type of object can be associated with the parent object that is a fixed object.

  In process S120, it is checked whether to define / add a new runtime object. If the definition / addition is performed, the process sequence continues to process S130. If the above definition / addition is not performed, the processing sequence continues to step S140.

  In process S130, a new runtime object is defined. The definition includes a process of associating (that is, adding or containing) a new runtime object with the parent object and the hierarchical object structure positioned above it. Corresponding to the rules and rules described above, the parent object located at the upper level is a fixed object. Further definition of the new runtime object may include the definition of yet another property element with AccessType, DefaultValue, Description, DFFormat, Occurrence, Scope, DFTitle, and DFType. After finishing defining all necessary and desired property elements and adding new runtime objects into the hierarchical object structure, the process sequence for defining new objects continues to process S200, where the process The sequence ends. It is also possible to define another new object by restarting the processing sequence described above.

  In process S140, a check is made as to whether to define a new fixed object. If so, the process sequence continues to process S150. Otherwise, the process sequence continues to process S160.

  In step S150, a new fixed object is defined. The above definition includes a process of associating (that is, adding or containing) a new fixed parent object with a parent object and a hierarchical object structure positioned above it. Corresponding to the rules and rules described above, the parent object positioned at the upper level is either a fixed parent object or a runtime (parent) object. Further definition of the new fixed parent object may include the definition of yet another property element with AccessType, DefaultValue, Description, DFFormat, Occurrence, Scope, DFTitle, and DFType. After finishing defining all necessary and desired property elements and adding new fixed parent objects into the hierarchical object structure, the process sequence for defining new objects continues to process S200, where The sequence ends. Another new object may be defined by restarting the processing sequence described above.

  In process S160, it is checked whether a new leaf object is to be defined. If a new leaf object is to be defined, the process sequence continues to process S170. If no new leaf object is defined, the processing sequence continues to step S180.

  A new leaf object is defined in step S170. The definition includes a process of associating (that is, adding or containing) a new leaf object with each of the parent object and the hierarchical object structure positioned at the upper level. Corresponding to the rules and rules described above, the parent object positioned at the upper level is either a fixed parent object or a runtime (parent) object. Further definitions of new leaf objects may include further property element definitions with AccessType, DefaultValue, Description, DFFormat, Occurrence, Scope, DFTitle, and DFType. After all necessary and desired property elements have been defined and new leaf objects have been added to the hierarchical object structure, the processing sequence for defining new objects continues to step S200, where the processing sequence Ends. Another new object may be defined by restarting the processing sequence described above.

  In step S180, it is checked whether or not a new link object is to be defined. If so, the processing sequence continues to step S190. In the present invention, four different types of objects are presented. Correspondingly, these four types are covered by the check processes S120, S140, S160, and S180. Note that it is possible to include one or more additional types of objects in the device definition framework (DDF). If a new link object is not defined, the processing sequence continues to step S200 according to the situation at that time. That is, if there is no new object definition, the processing sequence ends. Similar to the check process, definition process, and definition process described above in relation to each type of object, the check process, the definition process, and the additional process for this process sequence are performed in one or more other types. It can also be performed on objects.

  In step S190, a new link object is defined. The definition includes a process of associating (that is, adding or containing) a new link object with a parent object and a hierarchical object structure positioned above it. Corresponding to the rules and rules described above, the parent object positioned at the upper level is either a fixed parent object or a runtime (parent) object. Further definition of the new link object may include the definition of yet another property element with AccessType, DefaultValue, Description, DFFormat, Occurrence, Scope, DFTitle, and DFType. After completing the definition of all necessary and desired property elements and the process of adding new link objects into the hierarchical object structure, the processing sequence for defining a new object continues to process S200, where the process The sequence ends. Another new object may be defined by restarting the processing sequence described above.

  In process S200, the process of defining / adding one new object according to one embodiment of the present invention ends.

  Apart from the processing sequence presented above, where runtime objects are guaranteed not to be arranged consecutively in a hierarchical object structure, a fixed object is added and inserted between two consecutively arranged runtime objects It should be noted that the operation to be performed also realizes the above rules. By inserting fixed objects within successive run-time objects, the continuous arrangement is prevented and ultimately led to the same hierarchical object structure that results.

  According to another (improved) embodiment of the invention, the processing sequence checks the object format of a runtime object that is already associated with the parent object of the new object that is to be directly associated as an additional client object. Also consider. The corresponding rules and rules are described in detail below in connection with FIG. 3e.

  In step S130, an existing “parallel” child object of the parent object is determined. If there are existing descriptor objects, it is desirable to avoid associating runtime objects of different formats with the same parent object. If a runtime object of a different format is defined to be associated in parallel with an existing runtime object having a certain format, the definition is rejected and the processing sequence continues to step S200. That is, the processing sequence ends.

  According to another (improved) embodiment of the present invention, the above processing sequence includes checking the object type of an object that is already associated with a parent object for a new object that is to be directly associated as an (additional) client object. Also consider. The corresponding rules and adjustments are described in detail below in connection with FIG. 3d.

  In step S150, an existing “parallel” child object of the parent object is determined. If there is no “parallel” descriptor object and the parent object is a fixed object, the new fixed object and the existing fixed parent object associated with the higher level are aggregated into a new single fixed object, Object replacement is performed to simplify the hierarchical object structure and the device definition framework (DDF), respectively.

  FIG. 4b shows a second example flow chart illustrating the definition and creation of at least a portion of a device definition framework (DDF) and a DDF document, respectively, according to one embodiment of the present invention. This processing sequence includes the processing sequence depicted in FIG. 4a according to one embodiment of the invention.

  In step S300, the above-described processing sequence for creating a DDF document based on the definition of a new object based on the embodiment of the present invention is started.

  In step S310, an object is defined. There is a root object by default. That is, this root object structures the device definition framework (DDF), thereby forming the basis for a relative basis for assembling DDF documents. The definition of the object in step S310 includes the process shown in FIG. 4A described in detail with reference to FIG. 4A.

  In process S320, the resulting new defined object is encoded in the DDF document based on the definition performed in process S310. The encoding of the DDF document may be based on Extensible Markup Language (XML) encoding. XML encoding is performed based on the type description provided in the corresponding document type description (DTD) that defines the language elements of the XML encoding required for the DDF document. The XML encoding may be any suitable XML encoding, such as binary encoding XML encoding.

  In process S330, if another new object is to be added to the current device definition framework and DDF document, the process sequence returns to process S310. If no new object is added, the current device definition framework and DDF document are each completed. That is, another object is not added, and the process sequence continues to process S340.

  In step S340, the resulting device definition framework and DDF document are stored and transmitted to the management server side and / or the client side device to be managed, respectively, for use in finalizing, generating, and changing the management tree. can do. Further, the resulting device definition framework and DDF document are each processed to generate at least a portion of the management tree. Such processing of the device definition framework and the DDF document will be described later respectively with reference to FIG. 4c.

  In step S350, the DDF document creation processing sequence performed in accordance with the definition of the new object according to the embodiment of the present invention ends.

  It should be noted that the process S310 for defining a new object and the process S320 for encoding a new object have been described as separation processes. It should be understood that both the processing S310 and the processing S320 can be embodied as comprehensive processing and simultaneous processing of definition and encoding can be achieved.

  FIG. 4c shows a third exemplary flowchart for parsing and generating at least a portion of the management tree based on a device definition framework and a DDF document, respectively, according to one embodiment of the present invention.

  In process S400, a process sequence for creating / generating at least a part of the management tree is started based on the device definition framework and the DDF document according to the embodiment of the present invention.

  In step S410, the device definition framework and the DDF document having the encoded object corresponding to the generation of the management tree object are retrieved from the storage device, or the device management server or electronic Received from an entity such as a device manufacturer support server. For example, the management target client side device may receive the device definition framework and the DDF document from the management server side, or the management server may receive from a networked server for DDF output. As described above, the availability of the device definition framework and the DDF document enables the processing device to generate an effective and appropriate management tree structure, and guarantees the applicability of the device definition framework and the DDF document. Is done.

  In step S420, syntax analysis of the device definition framework and the DDF document is performed. This parsing may include information extraction and / or interpretation of acquired information by parsing. The parsing process may be performed for each object as embodied in the present application, or the process may be performed for each block. That is, processing may be performed by parsing a set of related description objects. The parsing between the device definition framework (DDF) and the DDF document further includes specific processing, and the desired object information is parsed / extracted from the entire device definition framework and the DDF document. You may do it.

  In step S430, one to several objects are generated based on the information acquired in step S420. The generation of each object is executed corresponding to the object information included in the device definition framework and the DDF document. These generated objects are included in at least a part of the management tree to be generated. A new object is added in consideration of the hierarchical relationship defined by the device definition framework and the DDF document, and at least a part of a management tree having an accurate hierarchical structure is generated. Furthermore, referring to FIG. 4a, as an embodiment, the method of adding an object to the hierarchical object structure is applied, and the resulting hierarchy (even if the DDF document does not take into account the rules and regulations described above). It is possible to guarantee that the rules and regulations according to the present invention are satisfied by the object tree (management tree).

  If necessary, a value of 1 or 2 or more is assigned to a new generated object in step S430.

  In processing S440, the parsing / extraction of desired object information is performed for each object, and if the generation of at least a part of the management tree is not completed, the processing sequence is the parsing / extraction of other desired object information. It returns to processing S420. When the generation of at least a part of the management tree is finished, the generation of at least a part of the management tree is finished, and the processing sequence continues to step S450.

  At step S450, at least a portion of the resulting generated management tree is applied. The resulting application of at least a portion of the management tree is the management tree configuration on the managed client side device, additional configuration data and / or settings required by one or more device functions and / or applications to the management tree. It may be an implementation of an additional branch in an existing management tree for adding. Further, in order to implement at least a part of the resulting management tree on the management target client side, the management server may generate at least a part of the management tree and send it to the management target client side. .

  The application of at least a portion of the resulting management tree should be understood in conjunction with the SyncML device management service and management document exchange described above.

  In step S460, the processing sequence for creating / generating at least a part of the management tree according to the device definition framework and the DDF document according to the embodiment of the present invention ends.

  The next FIG. 5a illustrates an example portion of the device definition framework. FIGS. 5b and 5c show the corresponding DDF document, and FIG. 5d corresponds to the example device definition framework shown in FIG. 5a and is encoded in the form of the document shown in FIGS. 5b and 5c. It is a figure which illustrates the example of a tree.

  FIG. 5a shows an exemplary portion of a device definition framework according to an embodiment of the present invention. This figure relates to setting of an access point (AP) of a client device capable of mobile data communication. This figure shows some of the related objects based on deriving one or more branches of a management tree of client devices capable of mobile data communication.

The access point settings are subsummarized under the top level internal object “./AP” that is directly associated with the root object “/”. That is, the object “./AP” is a child object of the root object “/”, and is a parent object corresponding to all access point (AP) setting values. Correspondingly, the drawn top level object “./AP” defines a fixed parent object with an instant identifier “./AP”. The fixed parent object “./AP” is associated with the runtime object <X ₁ > * arranged below the fixed parent object “./AP”. With this runtime object <X ₁ > *, one or more corresponding internal objects having dynamically assigned instant identifiers that are children of the corresponding internal parent object “./AP” can be derived. Disappear. Individual sets of information regarding individual access point settings are stored in one of the management trees under one of the runtime objects <X ₁ > *. The instant identifiers of these runtime objects <X ₁ > * preferably indicate the type of access point with which the individual access point settings are associated.

Each _{one of the} run-time objects <X ₁ > * is associated with a fixed object “Px”, a fixed object “NAPDef?”, A leaf object “ClientID?”, And a fixed object “BS?”. These objects are allowed to occur 0 times or once in the management tree arranged under the individual objects of the runtime object <X ₁ > *.

The fixed object “Px” is a parent object for one or more runtime objects <X ₂ > *, and the fixed object “NAPDef?” Is a parent object for one or more runtime objects <X ₃ > * The fixed object “BS?” Is a parent object for the runtime object <X ₄ > *. If the fixed object “Px” exists in the management tree, the fixed object “Px” has 0, 1 or more runtime objects <X ₂ > * with dynamically defined instant identifiers. Can do. Similarly, if the fixed object “NAPDef?” Exists in the management tree, the fixed object “NAPDef?” Can have zero, one, or two or more runtime objects <X ₃ > *. If BS? Is present in the management tree, the fixed object "BS?" Can have 0, 1 or more runtime objects <X ₄ > *. The further structure of the runtime objects <X ₂ > * and <X ₃ > * is omitted.

The runtime object <X ₄ > * includes several child objects, for example, a leaf object “Name?”, A fixed parent object “Network?”, And a leaf object “Country?”.

Next, the fixed object “Network?” Is associated with one or more runtime objects <X ₅ > + arranged below the fixed object “Network?”. If there is a fixed object “Network?” According to the definition of the runtime object <X ₅ > +, at least one or two or more runtime objects <X ₅ > + are defined as fixed objects “Network?” As internal child objects. Associated.

  The runtime objects in the structure shown above are always separated by at least one fixed object, the continuous disposition of fixed objects is avoided, and the runtime objects are not different in format Can coexist as child objects of one (fixed / runtime object) parent object, and the above description implements the rules and regulations described above, respectively.

  A corresponding DDF document can be obtained using the illustrated device definition framework. The meaning of the graphic elements included in the figure can be converted into a corresponding DDF document to obtain at least the framework of the DDF document.

  FIG. 5b shows a first portion of a DDF document excerpt corresponding to that shown in FIG. 5a. FIG. 5c shows a second part of the excerpt of the DDF document shown in FIG. 5b. Hereinafter, FIGS. 5b and 5c will be described together.

  The following excerpt from the DDF document is based on the encoding of the device definition framework in Extensible Markup Language (XML). XML encoding is further based on document type description defining tags for defining objects and properties of the objects, and allows the resulting DDF document to be uniquely transformed. . XML encoding is one of the board numbers indicating possible encoding methods. The following DDF document is based on the document type description for the device definition framework provided by the SyncML initiative.

  Lines 001 to 007 include the header section of the DDF document. According to the above header section, XML encoded version (1.0), encoded character (UTF-8), DTD version to be considered (1.1), manufacturer (Nokia), and destination to which DDF document is related The model identifier (omitted by comment) of the client side device is defined.

  Lines 008 to 018 include a part of the XML-encoded DDF document, and a part of the XML-encoded DDF document is relative to the fixed object “AP” and the root object “/”. The position is dedicated to the position of the fixed object “AP” in the management tree and the property element of the fixed object “AP”. Corresponding to the aforementioned properties of the fixed object “AP”, a set of object property elements specify the properties. Specifically, access is limited to read processing, the object format is set to the node that points to the internal object, the occurrence count is defined as one, the range is a permanent range, and human-readable A description and a human-readable title are defined.

Lines 019 to 026 define a runtime object <X ₁ > *. The name is omitted. This is because the instance identifier of the runtime object is assigned at runtime. The object property element specifies access to addition, deletion, acquisition, and replacement, the object format is defined as a node, the occurrence count is 0, 1 or 2 times (ZeroOrMore), and the range is dynamic Range. A human-readable title is defined.

  In lines 027 to 037, the fixed parent object “Px” is designated. Correspondingly, the name is defined as “Px”. The object property element specifies an access (get) limited to read processing, the object format is defined as a node, the number of occurrences is 1, and the range is a dynamic range. A human-readable title is defined.

In line 036, the ellipsis mark is a position in the drawn DDF document, and indicates a position where the specification of the runtime object <X ₂ > * is included. The specification of the runtime object <X ₂ > * is specified in the same manner as the specification of the runtime object specification presented here.

  A fixed object “NAPDef?” Is designated in lines 038 to 048. Correspondingly, the name is defined as “NAPDef”. The object property element specifies an access (get) limited to read processing, the object format is defined as a node, the number of occurrences is 0 or 1, and the range is a dynamic range. A human-readable title is defined.

The omission mark in line 047 indicates a position in the drawn DDF document and includes the specification of the runtime object <X ₃ > *. The specification of the runtime object <X ₃ > * is specified in the same manner as the specification of the runtime object specification presented here.

  In lines 049 to 059, a leaf object “ClientID?” Is designated. This name is defined as “Client Id” corresponding to the above. The object property element specifies access to addition, deletion, acquisition, and replacement. The object format is defined as a character format (chr) that is a certain leaf object, and the occurrence count is 0 or 1. Is a dynamic range. A human-readable title is defined. The leaf object contains information. This type of information, that is, the content type format of data representing the information needs to be defined in advance. Therefore, the corresponding type element (DFType) includes a MIME type definition indicating the content to be stored (in this case, plain text information).

  The fixed parent object “BS?” Is designated in lines 060 to 069. This name is defined as “BS” corresponding to the above. The object property element specifies an access (get) limited to read processing, the object format is defined as a node, the number of occurrences is 0 or 1, and the range is a dynamic range. A human-readable title is defined.

Lines 070 to 077 define a runtime object <X ₅ > *. The name is omitted. This is because the instance identifier of the runtime object is assigned at runtime. The object property element specifies access to addition, deletion, acquisition, and replacement, the object format is defined as a node, the occurrence count is 0, 1 or 2 times (ZeroOrMore), and the range is dynamic Range. A human-readable title is defined.

  The leaf object “Name?” Is designated in lines 078 to 088. This name is defined as “Name” corresponding to the above. The object property element specifies access to addition, deletion, acquisition, and replacement. The object format is defined as a character format (chr) that is a certain leaf object, and the occurrence count is 0 or 1. Is a dynamic range. A human-readable title is defined. The content type is specified as plain text by the MIME type definition.

  In lines 089 to 100, the fixed parent object “Network?” Is designated. This name is defined as “Network” corresponding to the above. The object property element specifies an access (get) limited to read processing, the object format is defined as a node, the number of occurrences is 0 or 1, and the range is a dynamic range. A human-readable title is defined.

In line 098, the ellipsis mark is a position in the drawn DDF document and indicates a position where the specification of the runtime object <X ₅ > * is included. In the same manner as the specification of the runtime object specification presented here, the specification of the runtime object <X ₅ > * is specified.

  A leaf object “Country?” Is designated on lines 101-110. This name is defined as “Country?” Corresponding to the above. The object property element specifies access to addition, deletion, acquisition, and replacement. The object format is defined as a character format (chr) that is a certain leaf object, and the occurrence count is 0 or 1. Is a dynamic range. A human-readable title is defined. The content type is specified as plain text by the MIME type definition.

In line 111, the ellipsis indicates a position in the drawn DDF document that includes a further object associated with the runtime object <X ₅ > *.

  The hierarchical structure of the device definition framework shown in FIG. 5a is associated with the device definition framework and the DDF document, respectively, by encapsulating the specifications described above and the specifications described above.

  By adopting the device definition framework and the DDF document, the hierarchical structure realized by the encapsulation of the object specification represents the hierarchical template structure of the management tree derived from this hierarchical structure. Apart from the above, instead of using the encapsulation of the specification that defines the hierarchical structure, route information may be added to the object specification. This path information specifies the position of the corresponding object in the hierarchical structure.

  The range of the specification of the fixed object “./AP” covers the object specification of the object arranged at the lower level starting from line 007 and ending at line 115. In this case, the specification of the fixed object “./AP” itself Is included in the encapsulation.

The range of the specification of the runtime object <X ₁ > * covers the object specification of the object arranged at the lower level starting from line 018 and ending at line 114. In this case, the specification of the runtime object <X ₁ > * itself is the above Included in the encapsulation.

  The range of the specification of the fixed object “Px” covers the object specification of the object arranged at the lower level starting from the line 027 and ending at the line 037. In this case, the specification of the fixed object “Px” is included in the above encapsulation. The omission mark included in line 036 indicates an omitted object specification arranged at a lower level in the hierarchy.

  The range of the specification of the fixed object “NAPDef?” Covers the object specification of the object arranged at the lower level starting from line 038 and ending at line 048. In this case, the specification of the fixed object “NAPDef?” The omission mark included in the 047 line indicates an omitted object specification arranged at a lower level in the hierarchy.

  The scope of the specification of the fixed object “BS?” Covers the object specification of the object arranged at the lower level starting from line 060 and ending at line 113. In this case, the specification of the parent object “BS?” Included in.

The scope of the specification of the run-time object <X ₄ > * covers the object object specification arranged at the lower level starting at line 069 and ending at line 112. In this case, the specification of the run-time object <X ₄ > * itself is encapsulated above The ellipses on line 111 indicate the omitted object specifications arranged in the lower hierarchy.

  The range of the specification of the fixed object “Network?” Covers the object specification of the object arranged at the lower level starting from line 089 and ending at line 099. In this case, the specification of the fixed object “Network?” Itself is included in the above encapsulation. Included.

  FIG. 5d shows an example of a management tree excerpt according to the device definition framework illustrated in FIG. 5a, in accordance with an embodiment of the present invention. The presented management tree is composed of a plurality of objects derived from the corresponding objects, and is associated with each other in accordance with a defined hierarchical structure described by the device definition framework.

  In the figure, the fixed object “./AP” represents the highest level object. That is, the object “./AP” is arranged directly below the root object “/” of the management tree and is associated with the root object “/” of the management tree. It is assumed that the object “./AP” includes management related information regarding network access of the mobile communication terminal.

The object “./AP” has three child objects, that is, an object “Prov_1” and an object “object” that are directly arranged below the object “./AP” and are associated with the object “./AP”. Prov_2 ", object" Prov_3 ", and yet another object. These objects, which is the runtime object that corresponds to the above-mentioned runtime object <X _1> *. According to the above definition of runtime objects that are child objects of a common parent, all these runtime objects need to provide services to the same substructure. The actual substructure of the runtime object may be different. This is because an object that is directly and indirectly arranged and related to a lower level may be a dynamic object. However, the runtime object “Prov_1”, the object “Prov_2”, and the object “Prov_3” are set such that these objects relate to the same function or configuration information for application management. In this specification, the runtime object “Prov_1”, the object “Prov_2”, and the object “Prov — 3” are related to the configuration information of the network service provider. The fixed object “./AP” functions to subsummarize all management information related to the network service provider configuration information.

  The runtime object “Prov — 1” has two child objects, an object “Px” and an object “NAPDef”. In accordance with the above-described adjustments in which run-time objects are continuously arranged, both the object “Px” and the object “NAPDef” are fixed objects. Further, the leaf object “ClientID” and the fixed object “BS” are set as child objects to the object “Prov_1” corresponding to the number of occurrences defined for another possible directly-associated object. Although it is possible to arrange dynamically, such an arrangement should not be performed. In the present application, none of the possible further objects described above are realized in the management subtree 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 definition configuration information of the network access point of the network provider service “Prov_1”.

The fixed object “Px” arranged below the object “Prov_1” includes a runtime object “DDF_Px” and a runtime object “Px_1”. Both the runtime object “DDF_Px” and the runtime object “Px_1” correspond to the runtime object <X ₂ > *. The object “Px” functions to subsummarize all proxy configuration information of the network provider service “Prov_1”. If another runtime object also corresponds to the definition described when considering the runtime object <X ₂ > * (ie if it has the same (and each common) format), the object “Px It is also allowed to associate the other runtime object as a child object for "".

The fixed object “NAPDef” arranged below the object “Prov_1” includes a runtime object “NAP_def” and a runtime object “NAP_1”. Both the runtime object “NAP_Def” and the runtime object “NAP_1” correspond to the runtime object <X ₃ > *. The object “NAPDef” functions to subsummarize all network access point definition configuration information of the network provider service “Prov_1”. If another runtime object also corresponds to the definition provided by the runtime object <X ₃ > * (ie, it has the same (and common) format), these other runtime objects Can be associated as a child object for the object “NAPDef”.

  In the case of the runtime objects “Def_Px” and “Px_1”, the fixed object “Px” separates the above-mentioned runtime object from the runtime object “Prov_1” arranged at the higher level in accordance with the above-mentioned rules for separating the runtime object. To do. Similarly, in the case of the run-time objects “NAP_Def” and “NAP_1”, the fixed object “NAPDef” is executed from the run-time object “Prov_1” arranged at the higher level in accordance with the above-mentioned definition for separating the run-time objects. Separate objects when.

  The fixed object “Prov_2” includes three child objects, a fixed object “NAPDef”, a leaf object “ClientID”, and a fixed object “BS”. Since the object “Prov — 2” that is directly arranged and related to the upper level is an object of the runtime type, the parent object “NAPDef” and the parent object “BS” both have a fixed object type.

  The fixed parent object “NAPDef” arranged below the object “Prov_2” has one child object, a runtime object “NAP_Def”.

The fixed object “BS” arranged below the object “Prov_2” has one child object (runtime parent object “Boot”). The object “BS” relates to bootstrap configuration information “Prov_2” of the network provider service. Corresponding to the object <X ₃ > *, the object “BS” has child objects “Name” and “Country”, both of which have leaf object types. It is also possible to associate another child object corresponding to the object <X ₃ > * with the object “BS”.

  FIG. 6 shows a block diagram illustrating an apparatus including components for processing the foregoing method according to an embodiment of the present invention. Server-side device management agent 220 represents a networked service that provides another counterpart client device management agent 320 for device management. The server-side device management agent 220 or the client-side device management agent 320 can provide or process device management data, respectively. The server-side device management agent 220 is hosted by the server 20, which may be a server-side device corresponding to the server-side device described above with reference to FIG. Similarly, the host of the client side device management agent 320 is the client 30 and may be a client side device corresponding to the client side device described above with reference to FIG. Device management is executed between the server 20 and the client 30.

  The server 20 and the client 30 are connected via an arbitrary network. The network establishes a logical communication connection between the server 20 and the client 30, thereby enabling end-to-end communication to be established during device management, which can be termed a device management session. The selection of logical connections and bearers of logical connections is described in FIG.

  The client 30 uses the client-side device management agent 320 together with the synchronization adapter 340 and the synchronization interface 330 to access the network, and to the server via the synchronization adapter 340 and the synchronization interface 330 in accordance with the SyncML DM protocol standard. A message may be transmitted. The server 20 or the server-side device management 220 transmits and receives messages via the synchronization adapter 240 and the synchronization interface 230, respectively, and manages the overall management operation of the device via the server-side device management engine 210. Device management operations are conceptually coupled into a device management frame, which is a conceptual frame for one or more required packages.

  Server-side device management engine 210 provides configuration data relating to certain client-side device functions that the user should send to client 30 to allow the use of well-configured device functions and / or devices. In addition, there is a possibility of accessing a device management database 200 adapted to include information related to the client 30 to be managed, such as a setting value or an application that can be executed using the client 30. The device management database 200 is a device definition framework (DDF) information associated with a client such as a DDF document defined and provided by a manufacturer to derive at least a part of a management tree effective for the client side device 30. And a part of the management tree itself, information on the actual position of the operation target client 30 in the management tree, and further device management related information. Further, the server-side device management engine 210 of the server 20 can generate a device management document exchanged with the client 30. This generation is possible. This is because the server 20 appropriately encodes a device-specific management document necessary for exchanging with the client 30 using the DDF information (DDF document), and management related information is realized on the client 30 side. This is because it becomes possible to follow the tree. For example, it is assumed that certain management related information is transmitted to the client in order to activate a certain client function. It is assumed that the management related information is further distributed between a certain management tree area (a certain branch) that is dynamically set first. The server 20 as well as the client 30 are known with respect to the device definition framework (DDF) 310, and the server 20 instructs the client to send the retail transmission information for management between the exact objects in the dedicated dynamic management tree area. Manage and retrieve dynamic execution in an appropriate manner that enables delivery, and in a proper manner that includes providing the information to the corresponding device function and / or device application that requires the information. The management tree is dynamically expanded in an appropriate manner that the client 30 can perform.

  The partner client 30 can respond to the management request by employing the client side device management agent 320. In particular, the client-side device management agent 320 accesses the device management tree 300 of the agent and the device definition framework (DDF) 310 of the agent that defines the hierarchical structure and objects of the management tree 300. .

  Both the server 20 and the client 30 can encode the action to be executed on the management tree of the client 20 using the DDF information (DDF document) stored therein. With this DDF information (DDF document), it is possible to generate a dynamic part of the management tree necessary for storing new or dynamic management related information related to the operation of the client 30. The above generation of a part of the management tree based on the DDF information (DDF document) is processed by the server side device management agent 220 and the client side device management agent 320, respectively. It depends on whether a change or adaptation of the management tree 300 is processed.

  Primarily, a device definition framework (DDF) is supplied to a device management server, such as server 20, by a manufacturer of a certain client device, such as client 30, so that the server has the appropriate capabilities for the client device. By generating the management action as described above by the method, it becomes possible to perform the operation of device management using the client. Furthermore, the DDF information (DDF document) available to the client 30 allows the client to generate a management tree when the client 30 is switched on when the management tree for the client 30 is not available up to that point. Become. The DDF information (DDF document) serves as a template to describe and describe each of the management tree and the management tree that may occur in a conventional, extensible and flexible manner.

  Each of server 20 or client 30, server-side device management agent 220, server-side device management engine 210, device database 200, and client-side device management agent 320 and device management tree 200 are presented. The component can also be configured by a data processing device that the server 20 or the client 30 can have. Further, the component may be configured by a code section including an execution instruction of a necessary processing operation, and the execution instruction may be executed on the server 20 side or the client 30 side, respectively.

  It will be apparent to those skilled in the art that as the technology advances, the inventive concept can be implemented in a wide variety of ways. Therefore, the present invention and its embodiments are not limited to the above-described examples, and can be modified within the scope of the claims.

FIG. 2 shows a block diagram illustrating a set of example electronic devices that can perform synchronized processing of information between the devices. A part of the example management tree is shown. 2 shows a table illustrating elements used for graph representation of device definition framework objects. 7 is a table illustrating special characters that are additionally used for graph notation of an object of the device definition framework. 2 shows a first arrangement configuration of description objects according to an embodiment of the present invention. 6 shows a second arrangement configuration of description objects according to an embodiment of the present invention. FIG. 6 shows an arrangement configuration of description objects to be avoided based on the embodiment of the present invention. FIG. FIG. 7 shows an arrangement configuration of description objects that are aggregated into a single description object according to an embodiment of the present invention. FIG. FIG. 6 shows an arrangement configuration of description objects to be avoided based on the embodiment of the present invention. FIG. 6 shows a first flowchart illustrating the definition of a description object according to an embodiment of the invention. FIG. 6 shows a second flowchart illustrating respectively the definition and creation of at least a portion of a DDF document in accordance with an embodiment of the present invention. 6 illustrates a third exemplary flowchart illustrating the parsing and generation of at least a portion of a management tree based on a DDF document, in accordance with an embodiment of the present invention. Fig. 3 shows an example of an excerpt of a device definition framework according to an embodiment of the present invention. FIG. 5a corresponds to FIG. 5a and shows a first part of an excerpt of a DDF document according to an embodiment of the invention. A second part of the excerpt of the DDF document shown in FIG. 5b according to an embodiment of the present invention is shown. FIG. 5a shows an example of a management tree excerpt according to the example device definition framework according to an embodiment of the present invention. FIG. 2 shows a block diagram illustrating an apparatus including components that process the foregoing method in accordance with an embodiment of the present invention.

Claims (13)

In an apparatus realized by a computer and a software program,
Providing a portion of a hierarchical object structure comprising a plurality of hierarchically related objects by the apparatus;
Here, the plurality of objects include different types of objects from a group including at least a fixed object type and a runtime object type, the fixed object type has a fixed title, and the runtime object is defined during execution Have a possible title,
Checking the type of the parent object by the device;
Checking with the device the type of child object;
Here, the parent object and the child object are part of the hierarchical object and are directly arranged hierarchically with each other,
If the parent object and the child object are runtime object types,
Defining, by the apparatus, at least one new object to be included between the parent object placed directly above and the child object placed directly below. And
The new object is the fixed object type;
The plurality of objects serve as template objects for deriving corresponding device descriptions having a hierarchical node structure,
The hierarchical node structure comprising a plurality of the nodes is employed to establish at least a portion of a management tree of a managed electronic device, and management related information is distributed across the at least a portion of the management tree; Method. Checking by the device whether the parent object already has one or more related objects located directly below it;
Comparing, by the device, the one or more already existing related objects with the type of the child object;
The method of claim 1, wherein the definition of the new object is rejected by the device if at least one of the one or more already existing objects is the runtime object. Checking whether the parent object is a fixed object type;
Checking whether the parent object already has one or more related objects located directly below it,
If the parent object does not already have a related object and the parent object is the fixed object type, then the parent object and the one or more already existing related objects are one combined new that is a fixed object type The method of claim 1, wherein the method is aggregated into objects.   The method of claim 1, comprising encoding at least a portion of the description document that includes information about the new object based on the definition of the new object. The hierarchical object structure is information that is part of a device definition framework;
The method according to claim 1, wherein the hierarchical node information is a template of the management tree adopted for device management conforming to a synchronous markup language device management standard defined by a SyncML initiative.   A document encoded in an extensible markup language, wherein the description document is at least part of a device definition framework document, and the device definition framework document is encoded according to a corresponding description framework document type description. The method of claim 1, wherein   A program code portion for implementing the method according to any one of claims 1 to 6 when executed on a processing device, a networked device, a networked server, a terminal device or a communication terminal device. Program to do. An apparatus comprising a portion of a hierarchical object structure comprising a plurality of hierarchically related objects;
Wherein the plurality of objects includes a fixed object type and different types of objects from a group including at least a runtime object type;
The fixed object type has a fixed title, the runtime object has a title defined during execution;
The processing unit of the device checks the type of the parent object;
Checking the type of the child object,
Here, the parent object and the child object are part of the hierarchical object structure and are directly arranged hierarchically with each other,
Here, if the parent object and the child object are the fixed object type,
Defining at least one new object to be included between the parent object positioned directly above and the child object positioned directly below it,
The new object is the fixed object type;
The plurality of objects serve as template objects for deriving corresponding device descriptions having a hierarchical node structure,
The hierarchical node structure comprising a plurality of the nodes is employed to establish at least a portion of a management tree of a managed electronic device, and management related information is distributed across the at least a portion of the management tree; apparatus. Generating at least a portion of the hierarchical node structure from the hierarchical object structure to establish the portion of the management tree and allowing the managed electronic device to implement the portion of the management tree. Further comprising a configured device management agent;
The device management agent is configured to distribute the management related information to the part of the management tree;
The device management agent searches at least a part of the management related information in a device management database in order to configure at least one function of an application executed on the electronic device and the managed electronic device. 9. The apparatus of claim 8, wherein the apparatus is configured. A management server,
A management system comprising a managed client,
The management server comprises a part of a hierarchical object structure comprising a plurality of hierarchically related objects;
The plurality of objects comprises different types of objects from a group including at least a fixed object type and an executable object type;
The fixed object type has a fixed title, the executable object has a title defined during execution;
The management server
Check the type of the parent object,
Checking the type of the child object,
Here, the parent object and the child object are part of the hierarchical object and are directly arranged hierarchically with each other,
If the parent object and the child object are the fixed object type, at least one new object is included between the parent object arranged directly above and the child object arranged directly below. Defining, and
The new object is the fixed object type;
The plurality of objects serve as template objects for deriving corresponding device descriptions having a hierarchical node structure,
The hierarchical node structure comprising a plurality of the nodes is employed to establish at least part of a management tree of the managed client, and management related information is distributed over the at least part of the management tree; Management system. The managed client is
A device management agent configured to generate the at least part of the management tree from the device description and implement the management tree on a managed client;
The at least part of the management tree is employed to distribute management-related information of the managed clients;
The device management agent is configured to distribute management-related information to the at least part of a management tree;
The device management agent is further configured to retrieve at least a portion of the management related information from the at least a portion of a management tree to configure a function or application to be executed on the managed client; The management system according to claim 10.   The management system according to claim 11, wherein the managed client is a device capable of mobile data communication.   The management system according to claim 11, wherein the management server and the managed client communicate via a data communication connection.

Images