Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
METHOD FOR SCHEDULING DEVICE MANAGEMENT AND TERMINAL THEREOF
Document Type and Number:
WIPO Patent Application WO/2007/083954
Kind Code:
A1
Abstract:
A terminal comprises a first entity adapted to receive a scheduling context from a server, to selectively verify the received scheduling context, and to install the received scheduling context; and a second entity adapted to perform a scheduled device management based on the scheduling context installed by the first element, wherein the scheduling context includes at least one of: a first element to specify a command for a device management; a second element to specify a condition to execute the command; a third element to specify an interaction with a user; a fourth element to specify whether or not a result from executing the command should be reported to the server; and a fifth element to specify whether or not a state of the scheduling context should be reported to the server.

Inventors:
KIM TE-HYUN (KR)
HERNANDEZ PABLO (FR)
Application Number:
PCT/KR2007/000344
Publication Date:
July 26, 2007
Filing Date:
January 19, 2007
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
LG ELECTRONICS INC (KR)
KIM TE-HYUN (KR)
HERNANDEZ PABLO (FR)
International Classes:
H04L12/28; H04L12/24
Domestic Patent References:
WO2002063911A12002-08-15
WO2004107705A12004-12-09
Foreign References:
US20050081020A12005-04-14
EP1326189A22003-07-09
US20030081624A12003-05-01
Attorney, Agent or Firm:
PARK, Jang-Won (200 Nonhyun-Dong, Gangnam-G, Seoul 135-010, KR)
Download PDF:
Claims:

Claims

[ 1 ] A terminal, comprising : a first entity adapted to receive a scheduling context from a server, to selectively verify the received scheduling context, and to install the received scheduling context; and a second entity adapted to perform scheduled device management based on the scheduling context installed by the first entity, wherein the scheduling context includes at least one of: a first element to specify a command for device management; a second element to specify a condition to execute the command; a third element to specify an interaction with a user; a fourth element to specify whether or not a result from executing the command should be reported to the server; and a fifth element to specify whether or not a state of the scheduling context should be reported to the server. [2] The terminal of claim 1, wherein the second entity comprises at least one or more of: a first module adapted to monitor the condition so as to execute the command; a second module adapted to interact with a user with respect to an execution of the command when a matching of the condition is detected; a third module adapted to execute the command; a fourth module adapted to gate a result of the execution; and a fifth module adapted to report a result of the execution having not been gated- off to the server, or to report a status of the terminal to the server. [3] The terminal of claim 1, wherein the scheduling context further includes a sixth element to specify whether or not a history of an operation according to the scheduling context should be logged. [4] The terminal of claim 1, wherein the first entity achieves the installation by creating each node corresponded to the each element of the scheduling context in a device management tree. [5] The terminal of claim 1, wherein the scheduling context can be modified or deleted by the server or by a user of the terminal. [6] The terminal of claim 2, wherein the fifth module reports to the server which has created the scheduling context, when the scheduling context is modified or deleted.

[7] The terminal of claim 1, wherein first entity checks a right of the server.

[8] The terminal of claim 1, wherein the first entity checks correctness in grammar

of the scheduling context, or if there is any wrong configuration of the scheduling context, or if the scheduling context can be executed.

[9] The terminal of claim 1, wherein the condition is at least one of timer-based, threshold-based, and trap-based.

[10] The terminal of claim 1, wherein the condition is disabled when the command is executed according to the condition.

[11] The terminal of claim 2, wherein the third module executes the command by cooperating with another module or entity in the terminal.

[12] The terminal of claim 2, wherein the second entity further comprises a sixth module adapted to log information related to at least one of whether or not the condition matching is detected, whether or not the user interaction is performed, whether or not the command is executed, and whether or not a result of the execution is reported.

[13] A server, comprising: a device management scheduling enabler adapted to create a scheduling context including a first element to specify a command for a device management and a second element to specify a condition to execute the command, to request an installation of the created scheduling context to a terminal, and to receive a response to the installation of the scheduling context.

[14] The server of claim 13, wherein the scheduling context further includes at least one of: a third element to specify an interaction with a user; a fourth element to specify whether or not a result from executing the command should be reported to the server; and a fifth element to specify whether or not a status of the scheduling context should be reported to the server.

[15] The server of claim 14, wherein the scheduling context further includes a sixth element to specify whether a history of an operation according to the scheduling context should be logged in the terminal

[16] The server of claim 13, wherein the device management scheduling enabler establishes a device management session with to the terminal to request the installation of the scheduling context in the terminal.

[17] The server of claim 13, wherein the device management scheduling enabler may request to modify or to delete the scheduling context installed in the terminal.

[18] The server of claim 13, wherein the device management scheduling enabler may process a message received from the terminal when a status of the scheduling context installed in the terminal is changed.

[19] The server of claim 13, wherein the device management scheduling enabler

comprises: a scheduling context management module adapted to create the scheduling context, to request the installation of the created scheduling context, and to receive the response; and a status reporting processing module adapted to receive one or more of a result of the execution of the command and a status report from the terminal, and to parse one or more of the result and the status report. [20] The server of claim 19, wherein the status reporting processing module routes a result of the execution or a status report to a scheduling context management module or another server. [21] A method for performing a scheduled device management in a terminal, comprising: receiving an installation request of a scheduling context including a first element to specify a command for device management and a second element to specify a condition to execute the command; authenticating or verifying the scheduling context; installing the scheduling context; and performing a scheduled device management according to the installed scheduling context. [22] The method of claim 21, wherein the scheduling context further includes at least one of: a third element to specify an interaction with a user; a fourth element to specify whether or not a result of an execution of the command should be reported to the server; and a fifth element to specify whether or not a status of the terminal should be reported to the server. [23] The method of claim 22, wherein the scheduling context further includes: a sixth element to specify whether or not a history related to the device management should be logged. [24] The method of claim 21, wherein in the authenticating or verifying the scheduling context, correctness of the scheduling context in grammar, or a right of the server can be checked. [25] The method of claim 21, wherein in the authenticating or verifying the scheduling context, whether or not there is any wrong configuration of the scheduling context, or whether or not the scheduling context can be executed is checked. [26] The method of claim 21, further comprising sending a message when a status of the scheduling context installed in the

terminal is changed. [27] A method for performing a scheduled device management in a terminal, comprising: receiving an installation request of a scheduling context including a first element to specify a command for device management and a second element to specify a condition to execute the command; checking or verifying the scheduling context; installing the scheduling context; monitoring the condition in the scheduling context; interacting with a user with respect to the execution of the command, when the condition matching is detected as a result of the monitoring; executing the command; gating a result of the execution; and reporting a result of the execution having not been gated to the server. [28] The method of claim 27, wherein the scheduling context further includes at least one of: a third element to specify the interaction with the user; a fourth element to specify whether or not a result of an execution of the command should be reported to the server; and a fifth element to specify whether or not a status of the terminal should be reported to the server. [29] The method of claim 27, further comprising logging information related to at least one of whether or not the condition matching is detected, whether or not the user interaction is executed, whether or not the command is executed, and whether or not a result of the execution is reported. [30] A method for scheduling a device management at a server, comprising: generating a scheduling context including a first element to specify a command for device management and a second element to specify a condition to execute the command; requesting an installation of the generated scheduling context in the terminal; and receiving a response to the requesting of the installation of the scheduling context from the terminal.

Description:

Description

METHOD FOR SCHEDULING DEVICE MANAGEMENT AND

TERMINAL THEREOF

Disclosure of Invention Technical Solution

[1] The present invention relates to a method for scheduling a device management

(DM) and a terminal thereof.

[2] Generally, a device management (DM) technique serves for a DM server to manage a terminal. The DM server accesses to the terminal (client) by referring to resources which are on a DM tree in the form of a DM object, thereby easily managing the terminal.

[3] According to the DM technique, the DM server may request a client to process a command for device management. Then, the client may immediately execute corresponding command, and then report a result of the execution. The DM server may request a change/ update/ deletion of a specific function from a DM object client.

[4] However, in the related art DM technique, the terminal requests the DM server to execute the management command only when an error or an abnormal operation occurs in the terminal. Accordingly, a diagnostic process for the terminal requires a high cost, and it is impossible to execute a suitable step prior to a problem occurrence.

[5] Therefore, an object of the present invention is to provide a device management

(DM) system capable of managing a terminal by a server, and a method for scheduling a DM thereof.

[6] To achieve these and other advantages and in accordance with the purpose of the present invention, as embodied and broadly described herein, there is provided a terminal, comprising: a first entity adapted to receive a scheduling context from a server, to selectively verify the received scheduling context, and to install the received scheduling context; and a second entity adapted to perform scheduled device management based on the scheduling context installed by the first element, wherein the scheduling context includes at least one of: a first element to specify a command for a device management; a second element to specify a condition to execute the command; a third element to specify an interaction with a user; a fourth element to specify whether or not a result from executing the command should be reported to the server; and a fifth element to specify whether or not a state of the scheduling context should be reported to the server.

[7] To achieve these and other advantages and in accordance with the purpose of the present invention, as embodied and broadly described herein, there is also provided a

server, comprising: a device management scheduling enabler adapted to create a scheduling context including a first element to specify a command for a device management and a second element to specify a condition to execute the command, to request an installation of the created scheduling context to a terminal, and to receive a response to the installation of the scheduling context.

[8] To achieve these and other advantages and in accordance with the purpose of the present invention, as embodied and broadly described herein, there is also provided a method for performing a scheduled device management in a terminal, the method comprising: receiving an installation request of a scheduling context including a first element to specify a command for device management and a second element to specify a condition to execute the command; authenticating or verifying the scheduling context; installing the scheduling context; and performing a scheduled device management according to the installed scheduling context.

[9] To achieve these and other advantages and in accordance with the purpose of the present invention, as embodied and broadly described herein, there is also provided a method for performing a scheduled device management in a terminal, comprising: receiving an installation request of a scheduling context including a first element to specify a command for device management and a second element to specify a condition to execute the command; checking or verifying the scheduling context; installing the scheduling context; monitoring the condition in the scheduling context; interacting with a user with respect to the execution of the command, when the condition matching is detected as a result of the monitoring; executing the command; gating a result of the execution; and reporting a result of the execution having not been gated to the server.

[10] The foregoing and other objects, features, aspects and advantages of the present invention will become more apparent from the following detailed description of the present invention when taken in conjunction with the accompanying drawings.

[11] The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and together with the description serve to explain the principles of the invention.

[12] In the drawings :

[13] FlG. 1 is a configuration view showing a terminal and a device management (DM) server according to the present invention;

[14] FlG. 2 is an exemplary view showing a scheduling context;

[15] FlG. 3 is an exemplary view showing a DM tree;

[16] FlG. 4 is a flowchart showing a process for installing a scheduling context by a DM server of FlG. 1 according to a first embodiment of the present invention;

[17] FlG. 5 is a flowchart showing a process for installing a scheduling context by a DM server of FlG. 1 according to a second embodiment of the present invention; and

[18] FlG. 6 is a flowchart showing a method for scheduling a DM according to the present invention.

[19] Reference will now be made in detail to the preferred embodiments of the present invention, examples of which are illustrated in the accompanying drawings.

[20] FlG. 1 is a configuration view showing a terminal and a device management (DM) server according to the present invention, FlG. 2 is an exemplary view showing a scheduling context, and FlG. 3 is an exemplary view showing a DM tree.

[21] As shown in FlG. 1, the DM system according to the present invention comprises a

DM server 100, and a terminal 200.

[22] DM Server 100

[23] The DM server 100 includes a DM scheduling enabler server 10 and a DM enabler server 120.

[24] The DM scheduling enabler server 110 includes a scheduling context management module 111, and a status reporting processing module 112.

[25] The scheduling context management module 111 is a unit for creating a scheduling context, and for installing the created scheduling context in the terminal 200. As shown in FlG. 2, the scheduling context may include a scheduled device management.

[26] Referring to FlG. 2, the scheduling context will be explained. The scheduling context includes general information, and at least one schedule component. The general information may include at least one of an identifier of the scheduling context and a name of the scheduling context, and information relevant to the server. The schedule component may include a scheduled device management. More particularly, the schedule component may include at least one of a command element (or, task element or first element) to specify a command for device management, a condition element (or, second element) to specify a condition to execute the command, a user interaction (UI) element (or, third element) to specify an interaction with a user, a gating element (or, fourth element) to specify whether or not a result of the execution of the command should be reported to the server, and an event element (or, fifth element) to specify whether or not a status of the terminal or an event should be reported to the server.

[27] Here, one or more commands for device management may be packaged in a message. Therefore, the command element specifies a message including one or more commands, instead of specifying each command respectively. And, the schedule component further includes a logging element (or, sixth element) to specify whether or not a history related to the device management should be logged in the terminal. It is noted that the scheduling text is not limited to the above construction.

[28] Above, it has been described that the schedule component includes at leat one or more of the command element, the condition element, the user interaction element, the gating element, and the event element. But, it is noted that these elements may be directly included in the scheduling context.

[29] The scheduling context management module 111 may set a DM session based on an

OMA-DM specification with the terminal 200, and then request the created scheduling context to be installed in the terminal 200 through the set DM session.

[30] The scheduling context management module 111 may request the scheduling context in the terminal 200 to be modified. Also, the scheduling context management module 111 may request the scheduling context in the terminal 200 to be deleted.

[31] When the installed or modified scheduling context is changed in the terminal 200 or an error occurs in the terminal 200, the scheduling context management module 111 receives a message from the terminal 200 thus to process it.

[32] The status reporting processing module 112 is a unit for receiving a result of the execution or a status report from the terminal 200, and parsing it. More concretely, the status reporting processing module 112 receives a result of the execution of the command or a status report from the terminal 200 thus to parse it, and checks to which scheduling context the result or the status report belongs. Then, the status reporting processing module 112 routes the result of the execution or the status report to the scheduling context management module 111. However, when the result or the status report received from the terminal 200 can not be directly processed, the status reporting processing module 112 can route the it to another server.

[33]

[34] Terminal 200

[35] The terminal 200 includes a DM scheduling enabler client 210, and a DM enabler client 220.

[36] The DM scheduling enabler client 210 includes a first entity 210a and a second element 220b. The first entity 210a includes a scheduling context installation module 211. And, the second entity 210b includes a condition matching module 212, a user interaction module 213, a command execution module 214, a gating module 215, a reporting module 216, and a logging module 217.

[37] The scheduling context installation module 211 is a unit for receiving an installation request of the scheduling context from the DM scheduling enabler server 110, and executing the installation. That is, the scheduling context installation module 21 installs at least one node in a DM tree in the terminal 200 by using the scheduling context. The DM tree may include a general part, and at least one schedule component.

[38] Referring to FlG. 3, the DM tree will be explained. The general part may include an

'ID' node for representing an identifier of the scheduling context, a 'Name' node for

representing a name of the scheduling context, and a 'Server' node for representing an owner of the scheduling context.

[39] The schedule component may include a task node (or, first node) for specifying a command for device management, a condition node (or, second node) for specifying a condition to execute the command, a user interaction (UI) node (or, third node) for specifying a user interaction, a gating node (or, fourth node) for specifying whether or not a result of the execution should be reported to the server, and an event node (or, fifth node) for specifying whether or not a status or an event of the terminal should be reported to the server. Also, the schedule component further includes a log control (LogCtrl) node (or, sixth node) for controlling a logging of a history related to the device management. Here, the task node can specify a message including one or more commands, instead of specifying each command respectively. And, the condition node includes one or more of a timer node for specifying a timer-based condition, a trap node for specifying a trap-based condition, and a threshold node for specifying a threshold-based condition, i.e. whether a value of a specific management object in the terminal has reached a threshold. The timer node may specify one of a given point in time, a duration, a period, and an interval. Such timer node includes a base node for specifying point in time expressed in complete representation and, a recurrence rule (RRuIe) node for specifying whether the condition is recursive or not. Therefore, if a recurrence is not specified in recurrence rule node, the timer-based condition may be disabled after the command is once executed.

[40] Above, it has been described that the schedule component includes at least one or more of the task node, the condition node, the user interaction node, the gating node, and the event node. But, it is noted that these nodes may be directly included in the scheduling context, instead of being included in the schedule component.

[41] Before installing the scheduling context by the DM server 100, the scheduling context installation module 21 may perform a user interaction, or may check whether the DM Server 100 has a necessary right. The scheduling context installation module

211 may verify whether the scheduling context to be installed is valid or not. Herein, the verifying may be executed by checking if there is any wrong configuration, if there is an error between components, if it can be executed, etc.

[42] The condition matching module 212 is a unit for monitoring whether or not the condition matching is detected, for requesting a user interaction from the user interaction module 213 when the condition matching is detected, or requesting the command execution module 214 to execute command corresponding to the condition.

[43] The condition matching module 212 may require additional items when monitoring the condition. That is, an item for specifying a way of the condition matching module

212 to monitor the condition may be included in the scheduling context. For instance,

in the scheduling context, may be included a request item for the condition matching module 212 to monitor a measured value or a variable within a preset time interval or at all times.

[44] The user interaction module 213 is a unit for executing a user interaction according to the 'UI' node in the DM tree when the condition is determined to be matched by the condition matching module 212.

[45] The command execution module 214 is a unit for cooperating with the DM enabler client 220 so that the management command can be executed according to the 'Task' node in the DM tree when the condition is determined to be matched or the user allows corresponding management commands to be executed.

[46] The gating module 215 is a unit for specifying whether or not a result of the execution of the command or a status of the terminal 200 should be reported to the DM server 100. As aforementioned, the gating module 215 may specify whether or not a result of the execution should be reported based on the 'Gating' node in the DM tree.

[47] The reporting module 216 is a unit for reporting a result of the execution or a status of the terminal 200 to the DM Server 100. When the result of the execution, that is, a 'status' message , a 'result' message , or an 'alert' message is determined to be reported by the gating module 215, the reporting module 216 creates a report message by using the result of the execution. Then, the reporting module 216 may send the report message to the DM Server 100. The reporting module 216 may report a status of the terminal or a status of the scheduling context according to the 'Event' node in the DM tree. The report message or the status of the terminal 200 may be sent to the DM Server 100 by using a 'generic alert' message.

[48] The logging module 217 is a unit for logging a history related to an operation of a

DM scheduling. As aforementioned, the logging module 217 may log the history based on the 'LogCtrl' node in the DM tree. For instance, the logging module 217 may log information related to each case, that is, when the condition is determined to be matched, when the command is executed, or when a result of the execution is reported to the DM Server 100. The log stored by the logging module 217 may be accessed by the DM Server 100 when necessary. The reason is in order to prevent the DM Server 100 from erroneously determining that the terminal 200 is in a normal status in a case when the status reporting processing module 216 can not perform a status report due to an unexpected error.

[49] As aforementioned, the logging module 217 may manage a storage means in the terminal 200 by referring to the 'LogCtrol' node in the DM tree. For instance, the logging module 217 may adjust a size of an allocated portion in the storage means for a log storage, or may select a storing method in the storage means, e.g., a circular buffer method, a linear buffer method, etc. The logging module 217 may be included in the

DM Scheduler 210, or may be independently constructed.

[50] The DM enabler client 220 is a unit for executing the management commands by cooperating with the command execution module 214. More concretely, the DM enabler client 220 receives the management commands from the command execution module 214, executes the management commands, and then sends a result of the execution to the command execution module 214. Here, as mentioned, one or more commands for device management may be packaged in a message. Therefore, the DM enabler client 220 can receive the message from the command execution module 214, extract a corresponding command from the message, and then execute the extracted command.

[51] So far, it has been explained that the DM Server 100 comprise the DM scheduling enabler server 110 including the scheduling context management module 111 and the status reporting processing module 112, and the DM enabler server 120, and that the terminal 200 includes the DM scheduling enabler client 210, and the DM enabler client 220, but the server 100 or the terminal 200 may be constructed by combining a processor (not shown), a network interface (not shown), and a storage means (not shown) one another.

[52] Hereinafter, an operation of the DM system according to the present invention will be explained with reference to FIGS. 4 to 6. Details were not disclosed in FIGS. 4 to 6 for brevity of the drawings. However, it should be noted that the DM Server 100 and the terminal 200 are implemented by the details.

[53]

[54] Installation of DM Scheduling Context

[55] FlG. 4 is a flowchart showing a process for installing a scheduling context by a DM

Server of FlG. 1 according to a first embodiment of the present invention, and FlG. 5 is a flowchart showing a process for installing a scheduling context by a DM Server of FlG. 1 according to a second embodiment of the present invention.

[56] Referring to FlG. 4, the DM Server 100 sets a DM session with the DM enabler client 220 thereby to install the scheduling context.

[57] Hereinafter, the process for installing a scheduling context according to the first embodiment of the present invention will be explained.

[58] 1) The DM Server 100, more concretely, the scheduling context management module 111 creates a scheduling context.

[59] 2) The DM Server 100 sets a DM session with the DM enabler client 220 of the terminal 200, and sends an installation request of the created scheduling context to the DM enabler client 220 of the terminal 200.

[60] 3) The DM enabler client 220 of the terminal 200 delivers the request to the DM scheduling enabler client 210, more concretely, the scheduling context installation

module 211, and then the scheduling context installation module 211 checks whether or not the scheduling context is valid or not. [61] 4) When the checking is completed, the DM scheduling enabler client 210, more concretely, the scheduling context installation module 211 interacts with a user with respect to the installation of the scheduling context. [62] 5) When the user interaction is completed, the DM scheduling enabler client 210 of the terminal 200, more concretely, the scheduling context installation module 211 installs the scheduling context in a DM tree of the terminal 200. [63] 6) When the installation is completed, the DM scheduling enabler client 210 of the terminal 200 reports a result of the installation of the scheduling context to the DM

Server 100. [64] Referring to FlG. 5, the process for installing a scheduling context according to the second embodiment of the present invention will be explained. [65] As illustrated in FlG 5, according to the second embodiment of the present invention, the DM Server 100 requests an installation of the scheduling context to the

DM scheduling enabler client 210, not to the DM enabler client 220. [66] 1) The DM Server 100, more concretely, the scheduling context management module 111 creates a scheduling context. [67] 2) The DM Server 100 sets a DM session with the DM Enabler scheduling enabler client 210 of the terminal 200, and sends an installation request of the created scheduling context to the DM scheduling enabler client 210 of the terminal 200. [68] 3) Then, the scheduling context installation module 211 of the terminal 200 checks whether or not the scheduling context is valid or not. [69] 4) When the checking is completed, the DM scheduling enabler client 210, more concretely, the scheduling context installation module 211 interacts with a user with respect to the installation of the scheduling context. [70] 5) When the user interaction is completed, the DM scheduling enabler client 210 of the terminal 200, more concretely, the scheduling context installation module 211 installs the scheduling context in a DM tree of the terminal 200. [71] 6) When the installation is completed, the DM scheduling enabler client 210 of the terminal 200 reports a result of the installation of the scheduling context to the DM

Server 100. [72] FlG. 6 is a flowchart showing a method for scheduling a DM according to the present invention. [73] As shown in FlG. 6, the DM Server 100 provides a device management command to be executed in the terminal 200 and a condition to execute the command to the terminal 200. Then, the terminal 200 executes the management command if it is determined that the condition is matched. Accordingly, the terminal 100 recognizes

that the DM Server 100 immediately provides the device management command, whenever the terminal 200 requires the device management command.

[74] Hereinafter, the method for scheduling a DM according to the present invention will be explained with reference to FlG. 6.

[75] 1) The DM scheduling enabler client 210, more concretely, the condition matching module 212 checks a condition based on the 'Cond' node in the DM tree, and monitors whether the condition matching is detected. As aforementioned, the condition may be one of a Timer'-based condition, a Trap'-based condition, and a Threshold'-based condition.

[76] 2) When the condition matching is detected, the DM scheduling enabler client 210, more concretely, the user interaction module 213 selectively interacts with a user. As aforementioned, the user interaction may be implemented according to the 'UI' node included in the DM tree.

[77] 3) When the user interaction is successfully executed, the DM scheduling enabler client 210, more concretely, the command execution module 214 executes the command by cooperating with the DM enabler client 220.

[78] 4) When the execution of the command is completed, the DM scheduling enabler client 210, more concretely, the gating module 215 gates a result of the execution. As aforementioned, the gating may be performed according to the 'Gating' node in the DM tree.

[79] 5) The DM scheduling enabler client 210, more concretely, the reporting module

216 reports a result of the execution having not been gated-off or a status of the terminal 200 to the DM Server 100. That is, the reporting module 216 reports to the DM Server 100 whether or not the command has been successfully executed, or a cause of an error occurrence. For the reporting, the reporting module 216 creates a reporting message by using the result of the execution, and then sends it to the DM Server 100.

[80] 6) The DM Server 100 having received the status report parses it.

[81] Although not shown in FlG. 6, the DM scheduling enabler client 210 of the terminal 200, more concretely, the logging module 217 may log a history related to each process. For instance, when the condition matching is detected, or when the user interaction is performed, or when the command are executed, or when the reporting is performed, a corresponding log may be stored in a storage means in the terminal 200.

[82] The method for scheduling a DM according to the present invention may be implemented by software and hardware or by combination therebetween. For instance, the method may be implemented by codes or commands in a software program that can be stored in a storage means (e.g., an inner memory of a mobile terminal, a flash memory, a hard disc, etc.), or that can be executed by a processor (e.g., an inner micro-

processor of a mobile terminal).

[83] In the present invention, the DM Server provides a device management command to be executed in the terminal and a condition to execute the command to the terminal in advance. Then, the terminal executes the management command based on the condition. Accordingly, the terminal 100 recognizes that the DM Server 100 immediately provides the device management command, whenever the terminal 200 requires the device management command.

[84] As the present invention may be embodied in several forms without departing from the spirit or essential characteristics thereof, it should also be understood that the above-described embodiments are not limited by any of the details of the foregoing description, unless otherwise specified, but rather should be construed broadly within its spirit and scope as defined in the appended claims, and therefore all changes and modifications that fall within the metes and bounds of the claims, or equivalents of such metes and bounds are therefore intended to be embraced by the appended claims.