Abstract:
A device for use in a communication system and a method for its operation are provided. The method of operating a Device Management (DM) client of a device in a communication system includes receiving an out-of-band DM message from a DM server, determining if out-of-band message response (OOBMsgResponse) reporting is inhibited based on an OOBMsgResponse node in a Management Object (MO), and if it is determined that OOBMsgResponse reporting is not inhibited, sending a response message in response to the out-of-band DM message received from the DM server.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application claims the benefit under 35 U.S.C. §119(e) of a U.S. Provisional application filed on Jul. 24, 2009 in the U.S. Patent and Trademark Office and assigned Ser. No. 61/228,317, the entire disclosure of which is hereby incorporated by reference. 
    
    
     BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     The present invention relates to Device Management (DM) messaging in a communication system. More particularly, the present invention relates to a technique for controlling DM response messages in a communication system. 
     2. Description of the Related Art 
     With the growth in ubiquitous communications technologies and systems, devices are increasing in functionality and complexity. However, with the increase in the functionality and complexity of the devices, a need for the management of the devices has developed. To address that need, the Open Mobile Alliance (OMA) established a Device Management (DM) Working Group to specify protocols and mechanisms that achieve management of devices. The OMA DM Working Group has developed the OMA-DM specification, which defines a two-way protocol between a DM server and a DM client associated with a device that is used for remote management of the device. An instance of an association between a DM Sever and a DM Client is referred to as a DM session and may be initiated by either the DM client or the DM server. The DM client resides in the device and the DM server manages the device by invoking commands on the DM client. The DM client processes the command and sends a response back to the DM server. Communication between the server and the client is over Synchronization Markup Language (SyncML). Historically, the devices have been wireless devices, but of late, OMA-DM has begun addressing the remote management needs of wired devices as well. Examples of OMA-DM include the setting of initial configuration information in devices, the subsequent installation and update of persistent information in devices, the retrieval of management information from devices, and the processing of events and alarms generated by devices. 
     An example of the OMA-DM architecture is described below with reference to  FIG. 1 . 
       FIG. 1  illustrates an OMA-DM architecture according to the related art. 
     Referring to  FIG. 1 , the OMA-DM architecture includes a DM server  100 , a DM client  110  and DM standard Management Objects (MOs)  120 . The OMA-DM architecture may include additional structural elements. However, a description of additional structural elements of the OMA-DM architecture is omitted for conciseness. 
     The DM server  100  and DM client  110 , which have been described above, communicate via interfaces DM- 1   130  and DM- 2   132 . DM client  110  communicates via interface DM- 5   134  with the DM Standard Objects  120 . 
     The DM protocol defines three standard Management Objects (MOs)  120  that all implementations of a DM Client  110  must support. These DM standard MOs  120  include DM Account (DMAcc) MO  122 , Device Information (DevInfo) MO  124  and Device Details (DevDetail) MO  126 . 
     The DMAcc MO  122  is used to manage information pertaining to bootstrapped DM servers  100 . For each DM server  100  that has been successfully bootstrapped for DM device  110 , the DMAcc MO  122  maintains information on a DM Server Identifier (ID), connectivity information, server address, server and client credentials, etc. The DevInfo MO  124  provides basic information about a device associated with the DM client  110 . The basic information includes a device ID, a device manufacturer ID, a model identifier, and language settings. The DevDetail MO  126  provides additional information about the device associated with the DM client  110 . The additional information includes device type, Original Equipment Manufacturer (OEM), hardware version, firmware version, software version, an indication of whether the device supports optional features (e.g. large-object handling capability), maximum depth of the management tree, maximum total length of any Uniform Resource ID (URI), and maximum total length of any URI segment. 
     An example of a communication system employing OMA-DM is described below with reference to  FIG. 2 . 
       FIG. 2  illustrates an exemplary communication system employing OMA-DM according to the related art. 
     Referring to  FIG. 2 , the exemplary communication system employing OMA-DM may include a wired network  200 , a wireless network  202 , a wired device  210 , a wireless device  212 , a DM server  220 , and a DM authority  230 . Each of the wired device  210  and the wireless device  212  has associated therewith a DM client (not shown). In addition, the DM authority  230  may be an Operations Support System (OSS). In  FIG. 2 , solid lines represent physical connectivity and dotted lines represent logical connectivity. 
     The exemplary communication system employing OMA-DM illustrated in  FIG. 2  is merely one of a number of possible implementations. For example, one of the wired network  200  and the wireless network  202  may be omitted. Alternatively, the wired network  200  and the wireless network  202  may be combined. Further, while the DM server  220  and the DM authority  230  are shown as connected to the wired network  200 , one or both of the DM server  220  and the DM authority  230  may alternatively be connected to the wireless network  202 . 
     To facilitate OMA-DM in the communication system illustrated in  FIG. 2 , a two-way protocol based on the OMA-DM specification is utilized between the DM server  220  and the DM client associated with wireless device  212 , and between the DM server  220  and the DM client associated with the wired device  210 . The DM authority  230  may direct the DM operations of the DM client associated with each of the wired device  210  and wireless device  212  via the DM server  220 . Only the interaction between the DM server  220  and a DM client associated with each of the wired device  210  and wireless device  212 , is within the scope of the OMA-DM specification. 
     An example of a DM server initiated DM session with a DM client is described below with reference to  FIG. 3 . 
       FIG. 3  is a signal diagram for a DM server initiated DM session with a DM client in a communication system according to the related art. 
     Referring to  FIG. 3 , the DM server initiated DM session between the DM server  302  and the DM client  304  includes two phases. The first phase is a setup phase  310  and the second phase is a management phase  320 . The setup phase  310  includes an exchange of information for authentication and device information. The exchange of information in the setup phase  310  includes three packages, each of which may contain multiple messages, namely Package  0  ( 312 ), Package  1  ( 314 ), and Package  2  ( 316 ). Package  0  ( 312 ) is sent from DM server  302  to DM client  304  and includes alert information. Package  1  ( 314 ) is sent from DM client  304  to DM server  302 . Package  1  ( 314 ) includes client initialization information and device information. The client initialization information includes client credentials. Package  2  ( 316 ) is sent from DM server  302  to DM client  304 . Package  2  ( 316 ) includes server initialization information and an initial management operation. The server initialization information includes one or more server credentials. 
     The management phase  320  includes the exchange of two packages, namely Package  3  ( 322 ), and Package  4  ( 324 ). Package  3  ( 322 ) is sent from DM client  304  to DM server  302 . Package  3  ( 322 ) includes client response information to the management operation triggered by Package  2  ( 316 ). Package  4  ( 324 ) is sent from DM server  302  to DM client  304 . Package  4  ( 324 ) includes at least one of an additional management operation and one or more additional user interaction commands, if the DM session is continued beyond the Package  2  message  316 . Additional cycles of a Package  3  message  322  and a Package  4  message  324  may be transmitted between the DM server  302  and DM client  304  until the DM session is terminated. 
     However, the DM server initiated DM session described above with reference to  FIG. 3  was developed under the OMA-DM specification in the context of session oriented management operations via unicast communication. Recently, the OMA, under the aegis of the DM-BroadCAST (BCAST) Birds-of-a-Feather (BoF) interest group, started looking at non-session oriented management operations that enable a trusted DM server to push DM commands to a DM device, without the overhead of establishing and maintaining a session. Such DM commands may hereafter be referred to as out-of-band DM messages or session-less messages. 
     One technique to push out-of-band DM commands to a DM device, without the overhead of establishing and maintaining a session, is to simultaneously execute DM commands in a broadcast mode on a large number of devices. An exemplary communication system employing DM-BCAST is similar to the communication system described above with reference to  FIG. 2 . However, a communication system employing DM-BCAST includes a BCAST server (not shown). In operation, an out-of-band DM command to be communicated via BCAST originates at the DM server, is transmitted to a BCAST server, and is then transmitted to a plurality of devices. While this feature can be made use of by any service provider that chooses to use it, the DM-BCAST BoF study group identified specific cases where this capability has certain utility. Such identified use cases include firmware/software updates, audience/network measurements, and device capability control. 
     The DM protocol has been designed so that a DM client reports back the response/status of any DM command issued by a DM server. However, the DM protocol does not support any mechanism to control the flow of messages from the DM client to the DM server. This is problematic in the broadcast setting as there is a need to regulate the flow of response/status messages back from the DM client to the DM server so as not to overwhelm the DM server with response messages. 
     An example of a flow of messages from a DM server to DM clients in a broadcast setting are described below with reference to  FIG. 4 . 
       FIG. 4  illustrates a flow of messages from a DM server to DM clients in a broadcast setting according to the related art. 
     Referring to  FIG. 4 , a DM Request R  400  is sent from DM Server  410  to a BCAST Server  420  for delivery to DM client  1   430 - 1 , DM client  2   430 - 2  . . . DM Client n  430 - n . The DM Request R  400  is sent from BCAST Server  420  to each of DM client  1   430 - 1 , DM client  2   430 - 2  . . . DM Client n  430 - n . 
     However, the responses from each of DM client  1   430 - 1 , DM client  2   430 - 2  . . . DM Client n  430 - n  to DM Request R  400  are sent immediately. Further the responses from each of DM client  1   430 - 1 , DM client  2   430 - 2  . . . DM Client n  430 - n  to DM Request R  400  are sent to either a single designated response server (denoted by the RespURI element in the SyncML message) or sent directly to DM Server  410  if no RespURI element is present. The responses from each of DM client  1   430 - 1 , DM client  2   430 - 2  . . . DM Client n  430 - n  to DM Request R  400  may not follow the path of DM Request R  400  through the BCAST Server  420 . 
     As a result the DM Server  410  or designated single response server will receive a significant number of effectively simultaneous response messages from a DM Request R  400  from an unknown number of clients. 
     Therefore, a need exists for an architecture that provides scale-able response handling as well as a mechanism by which the generation of response/status messages from DM clients to a DM server can be controlled. 
     SUMMARY OF THE INVENTION 
     An aspect of the present invention is to address at least the above-mentioned problems and/or disadvantages and to provide at least the advantages described below. Accordingly, an aspect of the present invention is to provide a technique for controlling Device Management (DM) response messages in a communication system. 
     In accordance with an aspect of the present invention, a method for operating a DM client of a device in a communication system is provided. The method includes receiving an out-of-band DM message from a DM server, determining if out-of-band message response (OOBMsgResponse) reporting is inhibited based on an OOBMsgResponse node in a Management Object (MO), and if it is determined that OOBMsgResponse reporting is not inhibited, sending a response message in response to the out-of-band DM message received from the DM server. 
     In accordance with another aspect of the present invention, a device for use in a communication system is provided. The device includes a memory for storing code of a DM client, a processor for executing the code of the DM client stored in the memory, a communications unit for receiving and sending messages for the DM client, and the DM client. The DM client receives an out-of-band DM message from a DM server, determines if OOBMsgResponse reporting is inhibited based on an OOBMsgResponse node in a MO, and if it is determined that OOBMsgResponse reporting is not inhibited, sends a response message in response to the out-of-band DM message received from the DM server. 
     Other aspects, advantages, and salient features of the invention will become apparent to those skilled in the art from the following detailed description, which, taken in conjunction with the annexed drawings, discloses exemplary embodiments of the invention. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The above and other aspects, features, and advantages of certain exemplary embodiments of the present invention will be more apparent from the following description taken in conjunction with the accompanying drawings, in which: 
         FIG. 1  illustrates an Open Mobile Alliance (OMA)-Device Management (DM) architecture according to the related art; 
         FIG. 2  illustrates an exemplary communication system employing OMA-DM according to the related art; 
         FIG. 3  is a signal diagram for a DM server initiated DM session with a DM client in a communication system according to the related art; 
         FIG. 4  illustrates a flow of messages from a DM server to DM clients in a broadcast setting according to the related art; 
         FIG. 5  illustrates a network architecture for controlling responses to out-of-band DM messages according to an exemplary embodiment of the present invention; 
         FIG. 6  illustrates a DM Account (DMAcc) Management Object (MO) according to the related art; 
         FIG. 7  illustrates a DMAcc MO according to an exemplary embodiment of the present invention; 
         FIG. 8  is a flowchart illustrating a method for controlling responses to out-of-band DM messages in a communication system according to an exemplary embodiment of the present invention; and 
         FIG. 9  is a block diagram of a device including a DM client for controlling responses to out-of-band DM messages in a communication system according to an exemplary embodiment of the present invention. 
     
    
    
     Throughout the drawings, like reference numerals will be understood to refer to like parts, components, and structures. 
     DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS 
     The following description with reference to the accompanying drawings is provided to assist in a comprehensive understanding of exemplary embodiments of the invention as defined by the claims and their equivalents. It includes various specific details to assist in that understanding but these are to be regarded as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the invention. In addition, descriptions of well-known functions and constructions are omitted for clarity and conciseness. 
     The terms and words used in the following description and claims are not limited to the bibliographical meanings, but, are merely used by the inventor to enable a clear and consistent understanding of the invention. Accordingly, it should be apparent to those skilled in the art that the following description of exemplary embodiments of the present invention are provided for illustration purpose only and not for the purpose of limiting the invention as defined by the appended claims and their equivalents. 
     It is to be understood that the singular forms “a,” “an,” and “the” include plural referents unless the context clearly dictates otherwise. Thus, for example, reference to “a component surface” includes reference to one or more of such surfaces. 
     By the term “substantially” it is meant that the recited characteristic, parameter, or value need not be achieved exactly, but that deviations or variations, including for example, tolerances, measurement error, measurement accuracy limitations and other factors known to those of skill in the art, may occur in amounts that do not preclude the effect the characteristic was intended to provide. 
     Exemplary embodiments of the present invention described below relate to a technique for controlling Device Management (DM) response messages in a communication system. More particularly, exemplary embodiments of the present invention described below relate to a technique for controlling a DM response message by a DM client to out-of-band DM messages received from a DM server. While the technique for controlling DM response messages in a communication system is described below in the context of Open Mobile Alliance (OMA)-DM response messages, the present invention is similarly applicable to the control of other messages. Further, while the technique for controlling DM response messages in a communication system is described hereafter in the context of broadcast, such as OMA-BroadCAST (BCAST), the present invention is similarly applicable in a non-broadcast scenario, such as unicast. 
     It should be understood that the following description may refer to terms utilized in various standards merely for simplicity of explanation. For example, the following description may refer to terms utilized in one of the OMA standards, such as the OMA-DM or OMA-BCAST standards. However, this description should not be interpreted as being limited to such standards. Independent of the mechanism used to control DM response messages in a communication system, it is preferable that DM response messages be controlled and it is advantageous for that ability to conform to a standardized mechanism. 
     Exemplary embodiments of the present invention control DM response messages in a communication system, and more specifically, OMA-DM response messages sent by a DM client in response to out-of-band DM messages received from a DM server. In addition, Exemplary embodiments of the present invention include a flexible scale-able architecture for the handling of OMA-DM response messages in a broadcast scenario as well as regulate the generation of response/status messages from a DM client back to a DM server. 
     A network architecture for controlling responses to out-of-band DM messages according to an exemplary embodiment of the present invention is described below with reference to  FIG. 5 . 
       FIG. 5  illustrates a network architecture for controlling responses to out-of-band DM messages according to an exemplary embodiment of the present invention. 
     Referring to  FIG. 5 , the network architecture includes response proxy servers  500 - 1  to  500 - n , DM server  510 , BCAST server  520 , DM client  530 , and a DM Application (DMA)  540 . The response proxy servers  500 - 1  to  500 - n  communicate with DM server  510  over a DM-Response (DM-Resp) interface  550 . The DM client  530  communicates with DM server  510  over a DM- 2  interface  560 . The DM application  540  communicates with DM server  510  over a DMA-DM Server (DMA-DMS) interface  570 . 
     Each DM client  530  is only aware of a single response proxy server of the response proxy servers  500 - 1  to  500 - n . However, there may be ‘n’ response proxy servers  500 - 1  to  500 - n  per set of responses generated by a single broadcast request. The response proxy servers  500 - 1  to  500 - n  communicate with the DM server  510  over a DM-Resp interface. 
     The DMA  540  may communicate with the DM server  510  in order to trigger DM requests. However, the DMA  540  is unaware of the topology used to handle the response load triggered by the same requests. 
     The DM-Resp interface  550  is a new interface defined by an exemplary embodiment of the present invention, over which the DM server  510  and response proxy servers  500 - 1  to  500 - n  communicate to provide aggregated response data as potentially required by the DM server  510 . In addition, information that is shared may include (but is not restricted to) session Identifiers (IDs) of a DM session. 
     In an exemplary embodiment of the present invention, the DM-Resp interface  550  may be realized via OMA DM Management Objects (MOs). More specifically, in an exemplary embodiment of the present invention, the DM-Resp interface  550  may be realized via OMA DM Account (DMAcc) MOs. The OMA DMAcc MO includes the settings for a DM client associated with a device. The OMA DM standard specifies that OMA DM MOs be represented as a tree of named nodes. An example of the OMA DMAcc MO according to the related art is provided in  FIG. 6 . 
       FIG. 6  illustrates a DMAcc MO according to the related art. 
     Referring to  FIG. 6 , a pictorial description of a tree of named nodes of a DMAcc MO of the related art is shown. The nodes depicted in  FIG. 6  are outside the scope of the present invention and therefore a description of each node is omitted herein for conciseness. A description of each node depicted in  FIG. 6  can be found in section 5.3.1 of version 1.2.1 of the OMA DM Standardized Objects, the entire disclosure of which is hereby incorporated by reference. 
     In an exemplary implementation of the DM-Resp interface via an OMA DMAcc MO, a plurality of new nodes are added to the DMAcc MO of the related art shown in  FIG. 6 . A DMAcc MO according to an exemplary embodiment of the present invention is described below with reference to  FIG. 7   
       FIG. 7  illustrates a DMAcc MO according to an exemplary embodiment of the present invention. 
     Referring to  FIG. 7 , the DMAcc MO includes a parent Out-Of-Band Message Response (OOBMsgResponse) node  700  and an Out-Of-Band Message Response Inhibit (OOBMsgResponseInhibit) node  710 , an Out-Of-Band Message Response Wait Time (OOBMsgResponseWaitTime) node  720 , and an Out-Of-Band Message Response Uniform Resource Locator (URL) (OOBMsgResponseRespURL) node  730 , which has been added to the DMAcc MO of the related art. The specific node names (e.g., OOBMsgResponse) referred to herein are merely illustrative; it is the function of the respective node that corresponds to exemplary embodiments of the present invention. The other nodes depicted in  FIG. 7  are the nodes of the DMAcc MO of the related art depicted in  FIG. 6  and are outside the scope of the present invention. Therefore a description of each these nodes is omitted herein for conciseness. 
     The OOBMsgResponse node  700  may be added to the DMAcc MO of the related art as the parent node for each of the OOBMsgResponseInhibit node  710 , the OOBMsgResponseWaitTime node  720 , and the OOBMsgResponseRespURL node  730 . The OOBMsgResponse node  700  is located in the DMAcc MO at Node: &lt;x&gt;/OOBMsgResponse. The OOBMsgResponse node  700  includes the properties shown in Table 1. 
     
       
         
               
               
               
               
               
             
           
               
                 TABLE 1 
               
               
                   
               
               
                   
                   
                   
                   
                 Minimum Access 
               
               
                   
                 Status 
                 Occurrence 
                 Format 
                 Types 
               
               
                   
               
             
             
               
                   
                 Optional 
                 ZeroOrOne 
                 node 
                 Get 
               
               
                   
               
             
          
         
       
     
     If the OOBMsgResponse node  700  is absent, no response will be sent by the DM device for out-of-band DM messages. 
     The OOBMsgResponseInhibit  710 , may be added to the DMAcc MO of the related art to explicitly control (allow or inhibit) a response to an out-of-band DM Request message received by a DM Client. The OOBMsgResponseInhibit node is located in the DMAcc MO at Node: &lt;x&gt;/OOBMsgResponseInhibit. The OOBMsgResponseInhibit node includes the properties shown in Table 2. 
     
       
         
               
               
               
               
               
             
           
               
                 TABLE 2 
               
               
                   
               
               
                   
                   
                   
                   
                 Minimum Access 
               
               
                   
                 Status 
                 Occurrence 
                 Format 
                 Types 
               
               
                   
               
             
             
               
                   
                 Required 
                 One 
                 boolean 
                 Get, Replace 
               
               
                   
               
             
          
         
       
     
     The OOBMsgResponseInhibit node  710  indicates whether or not responses for out-of-band DM messages received from the associated DM Server are inhibited. If the value of OOBMsgResponseInhibit node  710  is true, no response will be sent for out-of-band DM messages. 
     The OOBMsgResponseWaitTime node  720  may be added to the DMAcc MO of the related art to provide the ability to specify a time delay interval after which the DM Client provides a response to the received out-of-band DM Request message. This allows responses to be staggered across Management Authority (MA) defined client groups, thereby equalizing a load on the system. The OOBMsgResponseWaitTime node  720  is located in the DMAcc MO at Node: &lt;x&gt;/OOBMsgResponseWaitTime. The OOBMsgResponseWaitTime node  720  includes the properties shown in Table 3. 
     
       
         
               
               
               
               
               
             
           
               
                 TABLE 3 
               
               
                   
               
               
                   
                   
                   
                   
                 Minimum Access 
               
               
                   
                 Status 
                 Occurrence 
                 Format 
                 Types 
               
               
                   
               
             
             
               
                   
                 Optional 
                 ZeroOrOne 
                 int 
                 Get, Replace 
               
               
                   
               
             
          
         
       
     
     The OOBMsgResponseWaitTime node  720  indicates the minimum amount of time, in seconds, that a DM Client should wait before sending out a response/status message to an out-of-band DM message. If this node is not present, the response message to an out-of-band DM message should be sent out immediately. 
     The OOBMsgResponseRespURL node  730  may be added to the DMAcc MO of the related art to provide the location of a response proxy server for the DM device. The OOBMsgResponseRespURL node  730  is located in the DMAcc MO at Node: &lt;x&gt;/OOBMsgResponseRespURL. The OOBMsgResponseRespURL node  730  includes the properties shown in Table 4. 
     
       
         
               
               
               
               
               
             
           
               
                 TABLE 4 
               
               
                   
               
               
                   
                   
                   
                   
                 Minimum Access 
               
               
                   
                 Status 
                 Occurrence 
                 Format 
                 Types 
               
               
                   
               
             
             
               
                   
                 Optional 
                 ZeroOrOne 
                 chr 
                 Get, Replace 
               
               
                   
               
             
          
         
       
     
     The OOBMsgResponseRespURL node  730  contains a URL of a response proxy server to which a response message should be sent. This value shall have precedence over the URL that may be indicated by a Response Uniform Resource ID (URI) (RespURI) element in a Synchronization Markup Language (SyncML) message header (SyncHdr) of the out-of-band DM message. 
     A method for controlling responses to out-of-band DM messages in a communication system according to an exemplary embodiment of the present invention will be described below with reference to  FIG. 8 . 
       FIG. 8  is a flowchart illustrating a method for controlling responses to out-of-band DM messages in a communication system according to an exemplary embodiment of the present invention 
     Referring to  FIG. 8 , in step  800 , after an out-of-band DM message is received from a DM server, a DM client determines if an OOBMsgResponse node is present. If the DM client determines that the OOBMsgResponse node is not present at step  800 , the DM client terminates the procedure and no response is sent. However, if the DM client determines that the OOBMsgResponse node is present at step  800 , the DM client proceeds to step  802 . 
     In step  802 , the DM client determines if OOB response reporting is inhibited. The DM client determines if OOB response reporting is inhibited by checking the OOBMsgResponseInhibit node. If the DM client determines that OOB response reporting is inhibited at step  802 , the DM client terminates the procedure and no response is sent. However, if the DM client determines that OOB response reporting is allowed, the DM client proceeds to step  804 . 
     In step  804 , the DM client determines if a OOBMsgResponseWaitTime node is present. If the DM client determines that the OOBMsgResponseWaitTime node is present, the DM client proceeds to step  806  and waits for a specified time interval to elapse before proceeding to step  808 . However, if the DM client determines that the OOBMsgResponseWaitTime node is absent, the DM client proceeds to step  808 . 
     In step  808 , the DM client determines if the OOBMsgResponseRespURL node is present. If the DM client determines that the OOBMsgResponseRespURL node is present at step  808 , the response is sent to the location indicated by the OOBMsgResponseRespURL node in step  810 . Thereafter, the DM client ends the procedure. However, if the DM client determines that the OOBMsgResponseRespURL node is absent, the DM client proceeds to step  812 . 
     In step  812 , the DM client determines if a SyncHdr contains a RespURI element. The RespURI element is an optional element for the SyncML message header. If the DM client determines that the SyncML message header contains the RespURI element at step  812 , the DM client sends a response to a location identified by the RespURI element in step  814 . Thereafter, the DM client ends the procedure. However, if the DM client determines that the SyncML message header does not contain the RespURI element at step  812 , the DM client sends the response back to the source that issued the out-of-band DM message. Thereafter, the DM client ends the procedure. 
     In an exemplary embodiment of the present invention, instead of adding new nodes to the DMAcc MO of the related art as described above, a new MO may be defined that includes the parent OOBMsgResponse node, the OOBMsgResponseInhibit node, the OOBMsgResponseWaitTime node, and the OOBMsgResponseRespURL node. In this exemplary embodiment of the present invention, the DMAcc MO may provide references to pertinent instances of the new MO. 
     A structure of a device including a DM client for controlling OMA-DM response messages in a communication system according to an exemplary embodiment of the present invention will be described below with reference to  FIG. 9 . 
       FIG. 9  is a block diagram of a device including a DM client for controlling responses to out-of-band DM messages in a communication system according to an exemplary embodiment of the present invention. 
     Referring to  FIG. 9 , the device  900  includes a DM client  910 , a processor  920 , a memory  930 , and a communications unit  940 . The device  900  may include any number of additional structural elements. However, a description of additional structural elements of device  900  is omitted for conciseness. 
     The DM client  910  may be implemented as code that is executed by the processor  920  or may be implemented as hardware. The term “code” may be used herein to represent one or more of executable instructions, operand data, configuration parameters, and other information stored in memory  930  of the device  900 . The operations of the DM client  910  include any of the operations explicitly or implicitly described above as being performed by a DM client. For example, the DM client receives an out-of-band DM message from a DM server. In addition, the DM client determines if out-of-band message response reporting is inhibited based on an OOBMsgResponse node in an MO. Also, if the DM client determines that out-of-band message response reporting is not inhibited, the DM client sends a response message in response to the out-of-band DM message received from the DM server. 
     The processor  920  is used to process general operations of the device  900  and may be used to execute the code of the DM client  910 . 
     The memory  930  may store the code of the DM client  910  in addition to one or more of executable instructions, operand data, configuration parameters, and other information stored of the device  900 . Depending on the exact configuration and type of device, memory  930  may be volatile (such as Random Access Memory (RAM)), non-volatile (such as Read Only Memory (ROM), flash memory, etc.) or some combination of the two. 
     The communications unit  940  sends and receives data between the DM client  910  and other entities, such as a DM server, BCAST server, proxy response server, etc. For example, the communications unit  940  may receive out-of-band DM messages and may send response messages to the received out-of-band DM messages. The communications unit  940  may includes any number of transceivers, receivers, and transmitters of any number of types, such as wired, wireless, etc. 
     Exemplary embodiments of the present invention address the issue of regulating a response/status messages from a DM client to a DM server for out-of-band DM messages. 
     Certain aspects of the present invention may also be embodied as computer readable code on a non-transitory computer readable recording medium. A non-transitory computer readable recording medium is any data storage device that can store data, which can be thereafter read by a computer system. Examples of the non-transitory computer readable recording medium include ROM, RAM, Compact Disc (CD)-ROMs, magnetic tapes, floppy disks, and optical data storage devices. The non-transitory computer readable recording medium can also be distributed over network coupled computer systems so that the computer readable code is stored and executed in a distributed fashion. Also, functional programs, code, and code segments for accomplishing the present invention can be easily construed by programmers skilled in the art to which the present invention pertains. 
     While the invention has been shown and described with reference to certain exemplary embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined by the appended claims and their equivalents.