WO2014163280A1 - 무선 통신 시스템에서 서버의 단말의 리소스 요청 또는 단말의 리소스 제공을 위한 방법 및 이를 위한 장치 - Google Patents

무선 통신 시스템에서 서버의 단말의 리소스 요청 또는 단말의 리소스 제공을 위한 방법 및 이를 위한 장치 Download PDF

Info

Publication number
WO2014163280A1
WO2014163280A1 PCT/KR2013/011947 KR2013011947W WO2014163280A1 WO 2014163280 A1 WO2014163280 A1 WO 2014163280A1 KR 2013011947 W KR2013011947 W KR 2013011947W WO 2014163280 A1 WO2014163280 A1 WO 2014163280A1
Authority
WO
WIPO (PCT)
Prior art keywords
instance
node
server
data
cache
Prior art date
Application number
PCT/KR2013/011947
Other languages
English (en)
French (fr)
Inventor
박승규
김성윤
Original Assignee
엘지전자 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 엘지전자 주식회사 filed Critical 엘지전자 주식회사
Priority to CN201380075406.XA priority Critical patent/CN105103505B/zh
Priority to US14/774,608 priority patent/US10084748B2/en
Priority to JP2016506220A priority patent/JP6276380B2/ja
Publication of WO2014163280A1 publication Critical patent/WO2014163280A1/ko

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/30—Types of network names

Definitions

  • the present invention relates to a method for providing a resource of a terminal or a resource of a terminal of a server in a wireless communication system and an apparatus therefor, and more particularly, to a resource request or providing method using a cache verifier.
  • DM Device Management
  • the device management technology is being developed as an international standard based on SynchML Data Synchronization, which is written by the SyncML Initiative (Synchronization Markup Language) Forum at 0pen Mobile Alliance (0MA), and is already being developed for other standardization organizations and operators worldwide. It is accepted as the standard of management skills.
  • the 0MA device management technology is a standard that supports the most diverse functions compared to other device management technologies.
  • the device management protocol standard the standard for the device management document presentation method, the standard for binding with the transport protocol, the device management tree And a standard for a device management node, a standard for a device description framework (DDF), a standard for notification, and the like.
  • DDF device description framework
  • This device management is a device management server (DMS) sends a command to the device for a Management Object (MO) existing inside the device, the device management client (DMC) of the device is the command This can be done by The DMC is mounted on the device and corresponds to an entity that receives and executes the command from the DMS.
  • the M0 is logically connected to a management tree (or tree) existing within the device or a node of the tree. Therefore, the device management server may control the M0 or the tree or node associated with the M0 that is the target of the command through the command for M0.
  • the M0 is generally present in the database of the device, and the device management server can direct the management command by accessing the M0 through the URI of the tree or node.
  • the present invention proposes a resource request method of a terminal of a server, a resource providing method of the terminal, and an apparatus therefor in a wireless communication system.
  • a method for processing a request for M0 data using a cache validator (CV) assigned to an MCKManagement Object) instance according to an embodiment of the present invention, wherein the method is performed by a terminal.
  • the instance consists of a tree structure consisting of one or more nodes, wherein the M0 data includes the name of the node included in the M0 instance, the value of the node and the structure of the node, wherein the method comprises the M0 instance from a server.
  • the method includes verifying the first CV. If the first CV is verified to be valid, a result indicating that the first CV is valid is returned. Transmitting to the server, if the first CV is found to be invalid, transmitting the requested specific M0 data to the server. And if the URI information indicates a root node of the M0 instance, transmitting the second CV for the M0 instance.
  • the method may include updating a second CV for the M0 instance.
  • the M0 instance may be cacheable.
  • the first CV may be provided by a specific field included in the URI.
  • the first CV may be determined to be valid.
  • a method for requesting M0 data using a cache validator (CV) assigned to an MCKManagement Object) instance wherein the method is performed by a server and is performed by the server.
  • the instance is composed of a tree structure consisting of one or more nodes, wherein the M0 data includes the name of the node included in the M0 instance, the value of the node and the structure of the node, wherein the method includes a specific M0 of the M0 instance.
  • URI Uniform Resource Identifier
  • the first CV is not included in the URI information. If the first CV is not included in RI information, receiving the requested specific M0 data from the terminal; And if the URI information indicates a root node of the M0 instance, receiving the second CV for the M0 instance.
  • the first CV when the first CV is included in the URI information, the first CV is verified by the terminal, and when the first CV is validated, a result indicating that the first CV is valid is returned.
  • Receiving from the terminal if the first CV is verified to be invalid, receiving the requested specific M0 data from the terminal; And if the URI information indicates a root node of the M0 instance, receiving a second CV for the M0 instance from the terminal.
  • the second CV for the M0 instance may be updated.
  • the M0 instance may be cacheable.
  • the first CV may be provided by a specific field included in the URI.
  • the first CV may be determined to be valid if no change occurs in the M0 instance.
  • a terminal for processing a M0 data request using a cache validator (CV) f allocated to a M0 (Management Object) instance according to another embodiment of the present invention.
  • the M0 instance is composed of a tree structure consisting of one or more nodes, and the M0 data includes a name of a node included in the M0 instance, a value of a node, and a structure of a node.
  • radio frequency (RF) unit RF
  • a processor configured to control the RF unit, wherein the processor includes Uniform Resource Identifier (URI) information identifying the specific M0 data for requesting specific M0 data of the M0 instance from a server.
  • URI Uniform Resource Identifier
  • the processor transmits the specific M0 data to the server, the URI If the information indicates a root node of the M0 instance, it may be configured to send a second CV for the M0 instance.
  • a server for requesting M0 data using a cache validator (CV) assigned to an MCKManagement Object) instance wherein the M0 instance includes one or more nodes.
  • the M0 data comprises a tree structure, the name of the node included in the M0 instance, the value of the node and the structure of the node, wherein the server comprises: a radio frequency (RF) unit; And a processor configured to control the RF unit, wherein the processor makes a request including Uniform Resource Identifier (URI) information identifying the specific M0 data for requesting specific M0 data of the M0 instance.
  • RF radio frequency
  • URI Uniform Resource Identifier
  • the first CV for the M0 instance is configured to include the first CV in the URI information, and if the first CV is not included in the URI information, the processor requests the request.
  • the processor When receiving specific M0 data from the terminal, and the URI information indicates the root node of the M0 instance, it may be configured to receive a second CV for the M0 instance.
  • Figure 1 shows an HTTP web cache.
  • M0 Management Object
  • DM Device Management
  • Figure 3 shows an example of allocation of the M0 instance-specific cache verifier in accordance with an embodiment of the present invention.
  • FIG. 4 illustrates a resource request method according to an embodiment of the present invention.
  • FIG. 5 illustrates a resource providing method according to an embodiment of the present invention.
  • FIG. 6 shows a method that can be contrasted with an embodiment of the present invention.
  • Figure 7 shows a block diagram of an apparatus for implementing embodiment (s) of the present invention.
  • the device may be fixed or mobile, and various devices that transmit and receive user data and / or various control information by communicating with a server or a gateway belong to the device.
  • the device is a terminal equipment (Terminal Equipment), MS (Mobile Station), MT (Mobile) Terminal), UKUser Terminal), SSCSubscribe Station), wireless device (wireless device), PDA (Personal Digital Assistant), wireless modem (wireless modem), handheld device (handheld device) and the like.
  • a server and a gateway generally refer to a fixed station that communicates with a device, a gateway, and / or another server, and communicates with the device, gateway, and / or another server to provide various data and control information. Exchange it.
  • the server or the gateway may be referred to as a server device or a gateway device, respectively.
  • the device management refers to the management of other managed objects of the apparatus configuration and apparatus in view of the various regulatory authorities (Management authorities).
  • Device management includes sequential updates of constantly persistent information in devices, retrieval of management information from devices, and processing of events and alarms generated by devices, but for setting initial configuration information in devices.
  • Device Management includes, but is not restricted to setting initial conf igurat ion information in Devices, subsequent updates of persistent information in Devices, retrieval of management information from Devices and processing events and alarms generated by Devices.
  • a management tree is an interface for a management server to interact with a DM client, for example by storing values in or retrieving values from the management tree and by manipulating the attributes of the management tree, for example as an attribute of the management tree.
  • ACL access control list
  • the interface by which the management server interacts with the client :, eg by storing and retrieving values from it and by manipulating the properties of it, for exam le the access control lists. May be referred to interchangeably with the DM tree.
  • a management object is a subtree of a management tree that is intended to be a set of nodes (or even one node alone) that are related to each other in some way.
  • a ./Devlnfo node and its child nodes may form a managed object.
  • a Management Object is a subtree of the Management Tree which is intended to be a (possibly singleton) collection of Nodes which are related in some way.For example, the ./Devlnfo Nodes form a Management Object .A simple Management Object may consist of one single Node.)
  • a DM server or DMS may be a conceptual software component in a device management infrastructure that follows the 0MA Device Management Enabler static conformance requirements specified for the DM server or the DMS. have.
  • the DM server or the DMS may serve as an end-point of a DM client-server protocol and a DM server-server interface.
  • An abstract software component in a de loyed Device Management infrastructure that conforms to the OMA Device Management Enabler static conformance requirements specified for DM Servers .It serves as an end-point of the DM Client—Server Protocols and DM Server-Server Interface).
  • the DM server or the DMS may be provided mounted in an apparatus, a device, a computer, etc. having communication modules, processor modules, and the like, and thus may be implemented as one device.
  • a DM client or DMC is a conceptual component in device implementation that follows the 0MA Device Management Enabler static conformance requirements specified for the DM Client or the DMC. It may be a software component.
  • the DM client or the DMC may serve as an end point of a DM client and server protocol. (An abstract software component in a Device im lement at ion that conforms to the OMA Device Management Enabler stat ic conformance requirements specified for DM Clients. It serves as an end-point of the DM CI ient-Server Protocols.).
  • the DM client or the DMC may be provided as mounted in a device that is the target of the DM including a communication module, processor modules, and the like, and thus may be implemented as one device.
  • An ACL refers to a list of DM server identifiers and access rights associated with each DM server identifier for a particular node in the management tree (A list of identifiers and access rights associated with each identifier).
  • a node is a single element in the management tree. There can be two types of nodes in the management tree: interior nodes and leaf nodes.
  • the format attribute of a node provides information as to whether the node is a leaf node or an interior node.
  • the Format property of a Node provides information about whether a Node is a leaf or an Interior Node.).
  • An interior node may have child nodes, while an interior node may not have a value assigned to the node, that is, a node value.
  • the Format property of an Interior Node is node.
  • a leaf node may not have child nodes but may have node values instead.
  • the Format property of a Leaf Node is not node.
  • a persistent node is a node whose DDF attribute scope is set to permanent. If the node is not a permanent node, it is a dynamic node. A Node is permanent if the DDF property Scope is set to Permanent .If a Node is not permanent, it is dynamic .A permanent Node can never be deleted by the server.) [58] Dynamic Node
  • a dynamic node is a node in which a DDF property scope is set to dynamic, or in which the DDF property scope is not specified (A Node is dynamic if the DDF property Scope is set to Dynamic, or if the Scope property is unspecified).
  • the server identifier refers to the OMA DM internal name for the DM server.
  • a DM Server is associated with an existing Server Identifier in a device through OMA DM account.
  • All terminals managed by the DM (device management) 1.3 protocol have one DM tree starting with a root node, and the DM protocol is managed by the terminals by manipulating each node of the DM tree. Perform the command. For example, in order to install the downloaded software on the terminal, the user can install the software by executing a node called install that matches the software.
  • Each node can represent simple information such as numbers, or it can represent complex data such as picture data or log data.
  • a node can also represent a single command, such as run or download.
  • Each node has a property that provides meta information about the node, one of which is the runtime attribute, which is used until the node is created and destroyed in the DM tree. Possible attributes. These runtime attributes include ACL, Format, Name, Size, Title, TSt am, Type, and VerNo.
  • Access Control List is an essential function that both the terminal and the server must implement in the DM 1.3 protocol.
  • ACL specifies DM commands that a specific DM server can execute on a specific node. Unless specified, DM commands cannot be executed. In other words, an ACL means a specific DM server is granted to a specific node.
  • ACLs are assigned to the server identifier of the DM server, not URIs, IP addresses, or DM server certificates (cert if icate). This server identifier is used as an identifier to authenticate the DM server in the DM protocol.
  • such an ACL may be provided as an ACL property and an ACL value assigned to the ACL property.
  • the ACL value is ACL information (ACL). information) or information about an ACL may be referred to interchangeably.
  • ACL ACL information
  • information information about an ACL
  • all nodes are defined to have ACL attributes, and all nodes with ACL attributes are defined to have either empty or non-empty ACL values.
  • ACL has unique properties that differ from other run-time properties, and this unique representative property is ACL inheritance.
  • ACL inheritance is the concept that when a node in the DM tree does not have an ACL value, the ACL value for that node is taken from the ACL value of the parent node. If the parent node also does not have an ACL value, the ACL is taken from the parent node's parent node. Since the DM protocol specifies that the root node, which is the top node of the DM tree, must have an ACL value, the ACL value is necessarily inherited. This ACL inheritance is not done for each DM command, but because it is performed for the entire ACL value, the ACL value must be empty, so that ACL inheritance occurs from the parent node. In other words, if the ACL value of a node specifies only the Add permission, the Get permission that is not specified is not inherited.
  • Replace permission means permission to replace ACL values of all child nodes.
  • the parent node of that node has the R ⁇ lace privilege, the ACL value for that node You have the right to replace it. To get the ACL of the node, the parent node must have Get permission. Likewise, if the node has Replace permission, it means that the value of that node can be replaced. To replace the ACL, the parent node must have Replace permission.
  • the authority to replace the ACL value of the node may be controlled by the ACL value of the parent node. If you have Replace permission on an interior node, this means that you can replace the ACL values of all the child nodes, as well as the interior node. Thus, if the root node has Replace permission, it means that any node in the DM tree can have any permission. However, having the Replace permission on a parent node does not imply a specific permission such as Get on the child node, and the right such as Get must be specified directly on the child node.
  • the ACL value must be modified before the command is executed, and the ACL value of all the nodes on the way to the node to be modified must be modified to finally modify the ACL value of the child node. This is inconvenient.
  • the ACL allows the node to modify its ACL value without modifying the ACL value of the intermediate node.
  • the created node When the DM server creates a new node through the Add command, the created node generally does not have an ACL value, so all permissions are inherited from the parent. However, if the created node is an interior node and the parent node does not have the R ⁇ lace privilege, it is necessary to have sufficient authority to manage the node by setting the ACL value at the same time.
  • DMS1 and DMS2 are the server identifiers of the DM Server, and Get, Replace, Delete are the DM commands. Therefore, DMS1 can execute Get and Replace commands for the node, and DMS2 can execute Delete commands.
  • an ACL value is a set of individual ACL entries, and each node's ACL value may include at least one ACL entry.
  • DDF Device Description Framework
  • DM 1.3 authentication is performed based on the ACL. DM authentication is done separately for each DM command. If the DM server sends multiple DM commands, the DM client (DMC) performs authentication before executing the individual commands, and only the authorized DM commands are executed.
  • DMC DM client
  • the DM tree refers to the set of M0 instances exposed by the DM client, which acts as an interface by the management server interacting with the client, for example the management server stores and retrieves specific values from the DM tree. It can retrieve the attributes of the DM tree.
  • M0 data corresponds to information about the DM tree.
  • the information may be for the entire DM tree or may be part of the DM tree (eg, a subtree in the M0 instance).
  • the DM server requests M0 data using the ClientURI, and the M0 data consists of node name, node value and node structure.
  • Caching is a general term for a technique for reducing unnecessary transfer of resources between a server and a client.
  • the client stores previous voice answers from the server and reuses the stored when requesting the same resource.
  • the cache verifier is a component used to verify the cache.
  • Cache validation is the process of determining whether a resource cached at a resource requestor is up to date or not.
  • freshness means that the resource has not changed since it was delivered to the resource requester.
  • cache validators are the ETag and Last-Modified fields used in the web cache.
  • M0 instances [86] The MO instance is the presence of a Management Object (M0) published by a DM Client. Instances of M0 share the same node definitions and behaviors, and can be represented as a collection of related nodes published by the DM client. Multiple instances of one M0 may exist in the DM tree.
  • M0 Management Object
  • the ClientURI identifies a specific node of the DM tree existing in the terminal.
  • ClientURI may point to an interior node or a leaf node. Accordingly, ClientURI may be represented by an indicator or information indicating a specific node.
  • HTTP is a widely used protocol for sending and receiving resources on the Web.
  • resources are manipulated using HTTP commands such as GET, DELETE, PUT, and POST for the resource called URI.
  • HTTP client must know the URI that refers to a picture file in order to obtain a picture file that exists on the Web, and if that URI is "http: //w.server, com / a.jpg" '' Will send the HTTP GET command to the URI, and the HTTP server will send the picture file to the HTTP client in response to the HTP GET command.
  • Cache Validation is a process of checking whether a cache is valid or expired.
  • a cache validator is called a cache validator.
  • HTTP typically uses ETag and Last—Modi fied as cache validators.
  • ETag is a type of identifier that an HTTP server gives to a particular version of a resource.
  • an HTTP server sends a response to a resource request, it sends the resource indicated by the URI together with the ETag value assigned to the resource.
  • the HTTP server changes the ETag value when the resource changes (when the version of the resource changes), and compares the ETag value sent by the HTTP client with the ETag value sent by the HTTP client during the cache verification process, so that the local copy of the HTTP client has the latest. It will determine if it is a version.
  • the left table of FIG. 1 shows a web cache using ETag and the right table shows a web cache using Last-Modified.
  • an HTTP client requests an image file resource of "a.jpg” through a URI of "http://www.server.com/a.jpg” (S101-a). .
  • the HTTP server transmits an HTTP header called ETag together with the image file which is the requested resource (S102-a).
  • This ETag header indicates the ETag value assigned to the current version of the image file resource.
  • the HTTP client receives a response and stores the image file resource locally (local copy) and also stores the ETag value.
  • the HTTP client When an HTTP client sends a request for the same URI, the HTTP client includes a stored ETag, and for this purpose, an HTTP header called If-None—Match is used (S103-a).
  • the HTTP server receives this request and compares it to the ETag value for the current version of the resource represented by the UI. If the two values are the same, the ⁇ client informs the client that the resource has not been modified using a "304 Not Modified" response code ( S104-a).
  • the HTTP client receives this response from the HTTP server, it confirms that the resource it is storing is the latest version, and uses the latest version resource without sending it back from the server.
  • Last—Modified In addition to ETags, the most commonly used HTTP cache validator is Last—Modified.
  • the basic behavior of Last-Modified is almost identical to ETag, as shown in the table on the right in FIG.
  • Last-Modifier means the time when the resource was last changed. That is, when the HTTP server transmits a resource to the HTTP client, the HTTP server transmits the last changed time in the HTTP Last-Modified header (S102-b).
  • HTTP clients store resources and Last-Modified values locally and then send requests to the same URI.
  • the If-Modified-Since header includes the last modified time of the received resource (S103-b).
  • the HTTP server will update the resource change time whenever the resource changes, and if the request for the same URI contains an If— Modified-Since header, then the time contained in the If-Modified-Since header and stored by itself It compares the last resource change time that it has, and if it thinks the resource has changed, it sends back the requested resource. If the resource has not been changed, transmit a "304 Not Modified" voice answer code (S104-b).
  • the DM server may request the DM client to transmit the information stored in the terminal.
  • this information is configured in the form of a DM tree and stored in the terminal and is commonly referred to as management object data (M0 Data).
  • M0 Data may be the entire DM tree information or may be a value stored in one node.
  • 2 illustrates a DM tree stored in a terminal in 0MA DM 2.0.
  • 0MA DM 2.0 does not restrict the M0 instances in the terminal (that is, the set of M0 related nodes created in the terminal) to be organized in a hierarchical tree structure, where ClientURI, which refers to the node of the DM tree, is based on the M0 instance This is because it specifies the address of.
  • a request for a DM server to obtain M0 data is generally implemented through a GET command.
  • the DM server delivers the ClientURI as a parameter of the GET command in the process of delivering the GET command to the DM Client, and ClientURI refers to a specific node of the DM tree.
  • Package # 2 is used by the DM server to deliver a command to a DM client, and Package # 2 may include a plurality of DM commands. The following is an example of Package # 2 containing two GET commands.
  • the first GET command requests the Devlnfo Management Object stored in the terminal, and the second GET command requests the IDs of all the software components installed in the terminal. do.
  • CMD CMD
  • ⁇ In the above example, it can be seen that two GET commands are included.
  • the element following the GET command is ClientURI. That is, the first GET command requests MO data for the entire Devlnfo Management Object called "oma: mo: oma ⁇ dm ⁇ devinfo: 1.0 //", and the second GET command is "ur n: oma: mo: oma-s como: 1.0 // 1 nvent ory / Dep 1 oyed / * / 1 D "]-Request transmission of all installed software component identifiers (IDs).
  • DM Client When this request is received, it sends the requested M0 Data to the DM server through the following vocal reply message.
  • the response code for each command is transmitted using Package # 3.
  • the DM client transmits the following HTTP message.
  • OMADM-DevID IMEI: 493005100592800
  • the DM client's response is made using HTTP multipart
  • the first encapsulation contains Package # 3
  • the second encapsulation is the answer to the first GET command
  • three The first encapsulation is the answer to the second GET command.
  • the DM server requests MOData to the DM client in this way, and the DM client sends the requested M0 Data to the DM server.
  • inefficiency may occur. That is, the time required for the transmission of the M0 Data is long, the answer time is high, and network resources may be wasted due to unnecessary data transmission.
  • the HTTP web cache described above may be applied to OMA DM 2.0 as it is.
  • the DM client can assign and manage cache verifiers in all nodes of the DM tree, just as the cache verifiers are allocated and managed for each resource.
  • the DM server requests the DM client a resource called ClientURI with a DM GET command, and if there is a cache verifier, additionally delivers it and receives a status code indicating that the resource has not changed unless the requested resource has changed.
  • ClientURI resource
  • the following shows a GET command for requesting the FwV node (storing device firmware version information) of Devlnfo M0.
  • the first GET command to request an FwV node (resource).
  • the DM server will not have a local cache for this as well as a cache verifier for it, so the GET command is sent as follows without the cache verifier.
  • the DM server sends the requested resource as shown below.
  • a DM client sends a resource, it can send a cache verifier for the resource, which is passed through the "CV" key below.
  • ETag as the cache validator.
  • the DM server may store the firmware version of the terminal "android4.0.4" and the cache verifier "686897696a7c876b7e" for this resource.
  • the DM server requests the same resource later, the resource can be requested using the following GET command.
  • the cache validator is "686897696a7c876b7e" which is entered as the second parameter of the GET instruction.
  • the DM client When the DM client receives the Package # 2, the DM client performs a Cache Validation, and if the cache is valid, the DM client transmits a status code 304 indicating "Not Modified" to the DM server. In this case, the DM server knows that the local cache is still valid and can use "android4.0.4" stored in the local cache. Below is Package # 3 which says "304 Not Modified”.
  • OMADM-DevID IMEI: 493005100592800
  • OMADM-DevID IMEI: 493005100592800
  • the DM client In the case of applying the HTTP web cache directly to OMA DM 2.0, the DM client must assign a cache validator to all resources, resulting in heavy management of multiple cache validators and a heavy protocol.
  • a cache validator when a cache validator is assigned to an interior node, there is a problem of the range of resources to be validated by the corresponding cache verifier. That is, in the case of a cache validator assigned to an interior node, whether or not the cache validator should be updated when its child node or descendant node is updated is a problem.
  • ClientURI (urn: oma: mo: oma-scomo: 1.0 // Invent ory), which refers to multiple nodes, is an example of" DM 2.0-based resource acquisition ". Problems occur when / Dep 1 oyed / * / ID ”) is used in the GET command. That is, because ClientURI refers to multiple nodes, it is impossible to select which cache validator to send in the GET command. Moreover, the DM server cannot know how many nodes are designated as ClientURI and thus cannot select the cache validator.
  • FIG 3 shows an example of a cache verifier allocation according to an embodiment of the present invention.
  • a cache validator is an entity that can give validity information about a local cache held by a server.
  • the cache verifier provides freshness information for the local cache.
  • Representative examples of cache validators include last-modified or ETag.
  • the cache verifier is assigned to only the M0 instance as shown in FIG. However, not all M0 instances in the DM tree are assigned a cache validator, and a cache validator can be assigned only to a required M0 instance by selecting the M0 instance.
  • 3 is a diagram illustrating the allocation of a cache validator to two M0 instances (FUM0 instance, SC0M0 instance) among three M0 instances existing in the DM tree of the UE.
  • the M0 instance to which the cache verifier is allocated is called a cacheable MO instance.
  • a cacheable M0 instance In order to use the cache, a cacheable M0 instance must first be selected by a terminal (or DM client) or a DM server, and a cache verifier must be assigned and managed for the selected M0 instance. For each cacheable M0 instance, the DM client must assign a cache verifier and assign it whenever the data in the M0 instance changes (node value changes, new node additions and deletions, node name changes, etc.). The updated cache validator.
  • the cache verifier is assigned only to the M0 instance, the resource request / provision method using the cache can be efficiently performed.
  • the cache validation process is a process of checking whether a cache or cache copy is valid or invalid. Because a cache validator is assigned to a cacheable M0 instance, cache validation returns success (“success” or “true") if no data in the cacheable M0 instance has changed. If it does change, it should return failure ("false”). For example, when the cache verifier is an ETag, the cache verifier may be performed by comparing the ETag value transmitted by the DM server with the ETag value of the corresponding M0 instance managed by the terminal. The terminal returns "success” if the ETag value transmitted from the DM server and the ETag 3 ⁇ 4): that it manages are the same, and "failure” if the value is different.
  • the cache verifier is assigned to the M0 instance, the cache verifier can be used to send GET commands to all nodes in the M0 instance.
  • the DM server may deliver a cache verifier for the M0 instance.
  • the DM client verifies that the M0 instance has not been changed through the cache validator, and if the M0 instance has not been changed, the specific leaf node would not have been changed, and therefore, transmits a "304 Not Modified" code to the DM server.
  • the DM server receiving "304 Not Modified” may refer to locally cached data.
  • the method of delivering the cache verifier to the DM client may vary.
  • the cv field may be included in the ClientURI.
  • Using the cv field simplifies resource requests because the cache validator can be integrated into ClientURI and not passed as a separate parameter.
  • ClientURI points to a specific node, so the cv field will pass the cache validator for the M0 instance that contains that particular node.
  • This ClientURI refers to the "FwV" node of Devlnfo M0. Since the node is included in the Devlnfo M0 instance, the value cache verifier "686897696a7c876b7e '' passed in as the cv field becomes the cache verifier for this Devlnfo M0 instance.
  • FIG. 4 illustrates an example of a resource request using a cache verifier allocated to an M0 instance according to an embodiment of the present invention.
  • the DM server may determine to request MO Data (resource) referred to as ClientURI (S401).
  • MO Data resource
  • S401 ClientURI
  • a GET command can be used for this request.
  • the DM server may send a DM command by including the cv field in the ClientURI (S403).
  • the cv field carries a cache verifier for the corresponding M0 instance. Since the cache verifier can use the command to obtain the resource, it can use the DM GET / HPUT / HPOST command.
  • the DM server may transmit a resource request command to the DM client without the cv field (S403).
  • the DM client (terminal) performs processing according to the method illustrated in FIG.
  • Figure 5 shows an example of the response or processing of the resource request using the cache verifier assigned to the M0 instance in accordance with an embodiment of the present invention.
  • the DM client may receive a DM command for acquiring a resource (MO data) from the DM server (S501).
  • the DM command requesting the resource is one of GET / HPUT / HPOST, and the DM command carries a parameter called ClientURI.
  • This resource acquisition command may be interpreted as a command for requesting MO data for the node indicated by the ClientURI.
  • the DM client may determine whether the ClientURI of the DM command includes a cv field (S502). If the ClientURI of the DM command includes a cv field, the DM client performs a cache verification procedure (S503). In the cache verification procedure, if the MO data corresponding to the CV provided by the cv field is not changed in the terminal, it should return "success", and if any part of the MOData has changed, it should return "failure". Taking ETag as an example, the cache verification procedure is such that the DM client has a CV (hereinafter referred to as “first CV”) provided by the cv field stored or present in the DM client.
  • first CV hereinafter referred to as “first CV”
  • This cache verification procedure may vary depending on the type of cache verifier.
  • first CV is a CV stored in the DM server
  • second CV is a CV stored in the DM client (ie, a terminal).
  • the first CV is derived from the second CV (because, the CV for a specific M0 instance, that is, a set of M0 related nodes is allocated by the DM terminal, and as described below, a DM server that does not have a CV may request cv when requesting a specific resource).
  • the first CV is received from the DM terminal by not including the field in the ClientURI for the request), and the CVs stored by each of the DM server and the DM terminal are respectively referred to as 1CV and 2CV for convenience of description. It can be referred to.
  • the cache validation process is when returns "success” (for Etag cache verifying party, when the same claim 1CV and the second 2CV “success”:)
  • the DM client "304 Not Modified” is transmitted to the DM server, and the requested MOData is not transmitted to the DM server.
  • the DM server receiving this answer uses or references a local cache.
  • the DM client may transmit the M0 data referred to by the ClientURI to the DM server (S505).
  • the cache verification procedure is "Failed", that is, cv (first CV) of the corresponding MOData that the DM server has, the cv (second CV) of the corresponding M0 data managed by the DM client.
  • the DM client may transmit the M0 Data referred to by the ClientURI to the DM server (S505).
  • the DM client sends the resource (ie, MOData) to the DM server.
  • the resource ie, MOData
  • the cv stored by the DM server and the cv managed by the DM client are different, the cv managed by the DM client together with the corresponding resource is transferred to the DM server. send,
  • the DM client may determine whether the DM command, more specifically, ClientURI refers to the root node of the cacheable M0 instance (S506). That is, the DM client may determine whether the M0 instance including the node indicated by the ClientURI is a cacheable M0 instance and whether the node referred to as ClientURI is the root node of the cacheable M0 instance.
  • the DM client may additionally transmit a cache verifier for the M0 instance to the DM server (S507). ).
  • the DM client's answering process ends here.
  • the DM server stores the cache verifier and can be used when requesting MO data later.
  • the DM client does not additionally transmit the cache verifier to the DM server (S508). ).
  • the DM client may transmit a cache verifier to the DM server in S507.
  • the cache verifier is delivered with MOData, and forwards to the DM server if ClientURI refers to the root node of the cacheable M0 instance. If the ClientURI does not refer to the root node of the cacheable M0 instance, then the cache verifier shall not be passed.
  • the cache validator gives the validity information for the entire M0 instance. When only a part of the M0 instance is received by the DM server, a problem occurs in the validation of the DM client later.
  • the DM client may request the requested resource.
  • the changed resource when sending to the DM server If the changed resource is not the resource requested by the DM server, it is not transmitted to the DM server.), If the second CV is reflected to the DM server, the DM server is changed in the terminal but cannot be obtained.
  • the acquisition opportunities for other resource (s) other than resources are lost, which means a loss of functionality of the CV.
  • FIG. 6 illustrates a case in which the DM server includes both a request for a root node of a cacheable M0 instance and a request for a resource other than the root node to the DM client.
  • the DM server requests a M0 instance from the DM client having ClientURI "moid: 1.1" as the MO ID (S601).
  • ClientURI "moid: 1.1 //" refers to the root node of the corresponding M0 instance.
  • the M0 instance owned by the terminal is represented together in the upper right of FIG. 6.
  • the DM client transmits the entire data of the M0 instance requested by the DM server, and transfers the cache verifier "CV1" allocated to the M0 instance to the DM server (S602).
  • the DM client updates the c node such as renaming the c node.
  • the cache validator is updated to "CV2" because the information of the M0 instance (that is, the information about the c node) is changed (S603).
  • the DM client may perform a cache verification procedure based on the received CV1 (S605). That is, the DM client can determine whether the "CV1" is valid. In S603, the DM client has updated the information of the M0 instance and accordingly updated the cache verifier to CV2. Accordingly, the DM client determines that the cache validation fails because the "CV1" received from the DM server in S604 and the cache verifier "CV2" which it has have differed. ETag).
  • the DM client may transmit the requested information (node b and its subnodes d and e) and the cache verifier "CV2" which it has in S604 to the DM server (S606).
  • the DM client uses the cache verifier to the DM server even though the request from the DM server is not a request for the root node of the M0 instance. send.
  • the DM server may store the cache verifier "CV2" (that is, update from the existing "CV1” to "CV2").
  • the DM client may perform a cache verification procedure for verifying a cache verifier from the DM server (S608). Since the cache verifier of the DM client is also "CV2", the DM client determines that the cache verifier "CV2" from the DM server is valid and determines the cache verification procedure as "success”. Since the cache verification procedure is successful, the DM client transmits a male answer code of "304 Not Modified" to the DM server (S609).
  • the DM server receives a "304 Not Modified" response in S609 even though the DM server does not have the latest information of the updated c-node. Misunderstanding that you have a. This is because the DM client delivers the cache verifier "CV2" to the DM server in S606 even though the request from the DM server does not target the M0 instance root node. Since the delivered "CV2" is eventually used when the DM server requests information about the node c in S607, the DM client incorrectly determines that the DM server has the latest information about the node c. Does not transmit to the DM server. To prevent this problem in advance, the request of S607 may include a cache validator for one node. But in the end, this is similar to the HTTP web caching method, where there is a cache validator for each subtree, which complicates the mechanism for managing cache validators and requesting / replying resources.
  • the processing load due to the allocation of the cache verifier may be reduced, and the cache using the cache verifier may be used.
  • the verification procedure can be performed simply and efficiently. That is, an embodiment of the present invention allocates the cache verifier only to the M0 instance itself, unlike in the prior art which allocates the cache verifier (CV) for each of all resources, and to which node to assign the CV. Solve complex problems.
  • the CV (first CV) from the DM server is always checked to the DM terminal even if it is verified to be invalid.
  • the UE checks which resource is the requested resource, and the DM terminal may transmit the second CV to the DM server only when the resource is previously specified. .
  • the DM server sends the requested resource as shown below.
  • the DM client can send a cache verifier for the resource when sending the resource, which carries the cache verifier through the "CV" key below.
  • ETag as the cache validator.
  • OMADM-DevID IMEI: 93005100592800
  • the DM server may store the firmware version ⁇ android4.0.4 '' of the terminal and the cache verifier "686897696a7c876b7e" for the resource.
  • the cache verifier is "686897696a7c876b7e" passed in the cv field of the ClientURI.
  • the DM server After performing the validation), if the cache is valid, the DM server sends a status code 304 indicating "Not Modified". In this case, the DM server knows that the local cache is still valid and can use "android4.0.4" stored in the local cache. Below is Package # 3, which knows "304 Not Modified”.
  • OMADM-DevID IMEI: 4930.05100592800
  • FIG. 7 shows a block diagram of an apparatus configured to perform embodiment (s) of the present invention.
  • the transmitter 10 and the receiver 20 are R radio frequency units 13 and 23 capable of transmitting or receiving radio signals carrying information and / or data, signals, messages, and the like, in a wireless communication system.
  • Memory (12, 22) for storing various kinds of information related to communication.
  • Memo operatively connected to components such as the RF unit 13, 23 and the memory 12, 22, and controls the components so that the device performs at least one of the embodiments of the invention described above.
  • Processor 12, 22 and / or processor 11, 21 configured to control RF units 13, 23, respectively.
  • the memory 12 and 22 may store a program for processing and controlling the processors 11 and 21 and may temporarily store input / output information.
  • Memory 12, 22 can be utilized as a buffer.
  • the processor (11, 21) typically controls the overall operation of the various models in the transmitter or receiver.
  • the processors 11 and 21 may perform various control functions for carrying out the present invention.
  • the processors 11 and 21 may also be blurred by a controller, a microcontroller, a microprocessor, a microcomputer, or the like.
  • the processors 11 and 21 may be implemented by hardware or firmware, software, or a combination thereof. Hardware In the case of implementing the present invention using a language, it is configured to carry out the present invention.
  • ASICs application specific integrated circuits
  • DSPs digital signal processors
  • DSPDs digital signal processing devices
  • PLDs programmable logic devices
  • FPGAs field programmable gate devices
  • pipware or software may be configured to include modules, procedures, or functions for performing the functions or operations of the present invention, and the present invention may be performed.
  • Firmware or software configured to be capable of doing so may be provided in the processors 11 and 21 or stored in the memories 12 and 22 to be driven by the processors 11 and 21.
  • the terminal, the DM client, the DM server, etc. may operate as the transmitting device 10 or the receiving device 20, respectively.
  • the matters described in the various embodiments of the present invention described above with reference to the drawings may be independently applied or two.
  • the above embodiments may be implemented to be applied at the same time.
  • the present invention can be used in a wireless communication device such as a terminal, a base station, a server, and the like.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Telephonic Communication Services (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)

Abstract

본 발명의 일 실시예에 따라 MO 인스턴스에 할당된 캐시 검증자(cache validator; CV)를 이용한 MO 데이터 요청을 처리하기 위한 방법으로서, 상기 MO 인스턴스는 하나 이상의 노드들로 이루어진 트리 구조로 구성되며, 상기 MO 데이터는 상기 MO 인스턴스에 포함된 노드의 이름, 노드의 값 및 노드의 구조를 포함하며, 상기 방법은 단말에 의해 수행되며, 상기 방법은 서버로부터 상기 MO 인스턴스의 특정 MO 데이터를 요청하기 위한 상기 MO 데이터를 식별하는 URI(Uniform Resource Identifier) 정보를 수신하는 단계; 및 상기 URI 정보에 제1CV가 포함되어 있는지 여부를 판단하는 단계를 포함하고, 상기 URI 정보에 상기 제1CV가 포함되어 있지 않으면, 상기 요청된 특정 MO 데이터를 상기 서버로 전송하는 단계; 및 상기 URI 정보가 상기 MO 인스턴스의 루트(root) 노드를 지시하면, 상기 MO 인스턴스에 대한 제2CV를 전송하는 단계를 포함할 수 있다.

Description

【명세서】
【발명의 명칭】
무선 통신 시스템에서 서버의 단말의 리소스 요청 또는 단말의 리소스 제공 을 위한 방법 및 이를 위한 장치
【기술분야】
[1] 본 발명은 무선 통신 시스템에서 서버의 단말의 리소스 요청 또는 단말의 리 소스 제공을 위한 방법 및 이를 위한 장치에 관한 것으로서， 좀더 상세하게는 캐시 검증자를 이용한 리소스 요청 또는 제공 방법쎄 관한 것이다.
【배경기술】
[2] 일반적으로 장치 관리 (Device Management； DM) 기술은 장치 관리 서버가 효과 적인 방법으로 특정 장치에 저장된 변수나 객체의 값을 원격적으로 제어함으로써 그 장치의 설정을 변경할 수 있는 기술이다. 상기 장치 관리 기술은 0MA(0pen Mobile Alliance)에서 SyncML Initiative(Synchronisation Markup Language) 포럼에서 작성한 SynchML Data Synchronisation 을 기반으로 하여 국제 규격으로서 개발 진행 중이며, 이미 다른 표준화 단체와 전 세계 통신 사업자들에게 사실상 향후 장치 관리 기술 표 준으로 받아들여지고 있다. 상기 0MA 장치 관리 기술은 다른 장치 관리 기술에 비해 가장 다양한 기능을 지원하는 규격으로서, 장치 관리 프로토콜 규격, 장치 관리 문서 표현 방식에 관한 규격, 전송 프로토콜과의 연결 (binding)에 관한 규격， 장치 관리 트리와 장치 관리 노드에 관한 규격， DDF(Device Description Framework)에 관한 규격 , 통지 (Notification)에 관한 규격 등을 포함한다.
[3] 이러한 장치 관리는 장치 내부에 존재하는 관리 객체 (Management Object; MO) 에 대한 명령을 장치 관리 서버 (DMS)가 상기 장치로 전송하고, 상기 장치의 장치 관 리 클라이언트 (DMC)는 상기 명령을 수행함으로써 이루어질 수 있다. 상기 DMC 는 상 기 장치에 탑재되어 상기 DMS 로부터의 상기 명령을 전달받아 수행하는 엔티티에 해 당한다. 상기 M0 는 상기 장치 내부에 존재하는 관리 트리 (또는 트리) 또는 상기 트 리의 노드와 논리적으로 연결되어 있다. 따라서, 상기 장치 관리 서버는 M0 에 대한 명령을 통해 상기 명령의 대상이 되는 M0 또는 이러한 M0 와 연관된 트리 또는 노드 에 대한 제어를 수행할 수 있다. 상기 M0 는 일반적으로 상기 장치의 데이터베이스에 존재하며 , 상기 장치 관리 서버는 상기 M0 를 상기 트리 또는 노드의 URI 를 통해 접 근하여 관리 명령을 지시할 수 있다. 【발명의 상세한 설명】
【기술적 과제】
[4] 본 발명은 무선 통신 시스템에서 서버의 단말의 리소스 요청 방법 및 상기 단말의 리소스 제공 방법 및 이를 위한 장치를 제안하고자 한다.
[5] 본 발명에서 이루고자 하는 기술적 과제들은 상기 기술적 과제로 제한되지 않으며, 언급하지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 발명이 속하 는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
【기술적 해결방법】
[6] 본 발명의 일 실시예에 따른 MCKManagement Object) 인스턴스에 할당된 캐시 검증자 (cache validator; CV)를 이용한 M0 데이터의 요청을 처리하기 위한 방법으로서 상기 방법은 단말에 의해 수행되며, 상기 M0 인스턴스는 하나 이상의 노드들로 이루 어진 트리 구조로 구성되며， 상기 M0 데이터는 상기 M0 인스턴스에 포함된 노드의 이 름, 노드의 값 및 노드의 구조를 포함하며， 상기 방법은 서버로부터 상기 M0 인스턴 스의 특정 M0 데이터를 획득하기 위한 상기 특정 M0 데이터를 식별하는 URlOJniform Resource Identifier) 정보를 포함하는 요청을 수신하는 단계; 및 상기 URI 정보에 제 1CV가 포함되어 있는지 여부를 판단하는 단계를 포함하고， 상기 URI 정보에 상기 제 1CV가 포함되어 있지 않으면， 상기 요청된 특정 M0 데이터를 상기 서버로 전송하 는 단계; 및 상기 URI 정보가 상기 M0 인스턴스의 루트 (root) 노드를 지시하면, 상기 M0 인스턴스에 대한 제 2CV를 전송하는 단계를 포함할 수 있다.
[7] 바람직하게는, 상기 URI 정보에 상기 제 1CV가 포함되어 있으면 , 상기 제 1CV 를 검증하는 단계를 포함하되， 상기 제 1CV가 유효한 것으로 검증되면, 상기 제 1CV 의 유효함을 지시하는 결과를 상기 서버로 전송하는 단계를 포함하며， 상기 제 1CV가 유효하지 않은 것으로 검증되면， 상기 요청된 특정 M0 데이터를 상기 서버로 전송하 는 단계 ; 및 상기 URI 정보가 상기 M0 인스턴스의 루트 노드를 지시하면， 상기 M0 인 스턴스에 대한 제 2CV를 전송하는 단계를 포함할 수 있다.
[8] 바람직하게는， 상기 M0 인스턴스에 변경이 발생되면， 상기 방법은 상기 M0 인스턴스에 대한 제 2CV를 업데이트하는 단계를 포함할 수 있다.
[9] 바람직하게는， 상기 M0인스턴스는 캐시가 설정 가능할 (cacheable) 수 있다.
[10] 바람직하게는, 상기 제 1CV는 상기 URI에 포함된 특정 필드에 의해 제공될 수 있다. [11] 바람직하게는， 상기 M0 인스턴스에 어떠한 변경도 발생되지 않았다면 상기 제 1CV는 유효하다고 판단될 수 있다.
[12] 본 발명의 다른 일 실시예에 따른 MCKManagement Object) 인스턴스에 할당된 캐시 검증자 (cache validator; CV)를 이용한 M0 데이터를 요청하기 위한 방법으로서， 상기 방법은 서버에 의해 수행되며, 상기 M0 인스턴스는 하나 이상의 노드들로 이루 어진 트리 구조로 구성되며， 상기 M0 데이터는 상기 M0 인스턴스에 포함된 노드의 이 름， 노드의 값 및 노드의 구조를 포함하며， 상기 방법은 상기 M0 인스턴스의 특정 M0 데이터를 획득하기 위한 상기 특정 M0 데이터를 식별하는 URI (Uniform Resource Identifier) 정보를 포함하는 요청을 상기 단말로 전송하는 단계를 포함하되， 상기 M0 인스턴스에 대한 제 1CV를 알고 있으면， 상기 URI 정보에 상기 제 1CV를 포함시키 며， 상기 M0인스턴스에 대한 제 1CV를 알지 못하면 상기 URI 정보에 상기 제 1CV를 포함시키지 않으며 , 상기 URI 정보에 상기 제 1CV 가 포함되지 않으면, 상기 요청된 특정 M0 데이터를 상기 단말로부터 수신하는 단계; 및 상기 URI 정보가 상기 M0 인스 턴스의 루트 (root) 노드를 지시하면， 상기 M0 인스턴스에 대한 제 2CV를 수신하는 단 계를 포함할 수 있다.
[13] 바람직하게는， 상기 URI 정보에 상기 제 1CV 가 포함되면, 상기 단말에 의해 상기 제 1CV가 검증되며, 상기 제 1CV가 유효한 것으로 검증되면, 상기 제 1CV의 유효 함을 지시하는 결과를 상기 단말로부터 수신하는 단계를 포함하며 , 상기 제 1CV가 유 효하지 않은 것으로 검증되면， 상기 요청된 특정 M0 데이터를 상기 단말로부터 수신 하는 단계 ; 및 상기 URI 정보가 상기 M0 인스턴스의 루트 노드를 지시하면, 상기 M0 인스턴스에 대한 제 2CV를 상기 단말로부터 수신하는 단계를 포함할 수 있다.
[14] 바람직하게는, 상기 M0 인스턴스 내 특정 리소스가 변경되면， 상기 M0 인스 턴스에 대한 제 2CV는 업데이트될 수 있다.
[15] 바람직하게는， 상기 M0 인스턴스는 캐시가 설정 가능할 (cacheable) 수 있다.
[16] 바람직하게는, 상기 제 1CV는 상기 URI에 포함된 특정 필드에 의해 제공될 수 있다.
[17] 바람직하게는, 상기 M0 인스턴스에 어떠한 변경도 발생되지 않았다면 상기 제 1CV가 유효한 것으로 판단될 수 있다.
[18] 본 발명의 다른 일 실시예에 따른 M0(Management Object) 인스턴스에 할당된 캐시 검증자 (cache validator; CV)f 이용한 M0 데이터 요청을 처리하기 위한 단말로 서， 상기 M0 인스턴스는 하나 이상의 노드들로 이루어진 트리 구조로 구성되며, 상기 M0 데이터는 상기 M0 인스턴스에 포함된 노드의 이름, 노드의 값 및 노드의 구조를 포함하며， 상기 단말은: 무선 주파수 (radio frequency, RF) 유닛; 및 상기 RF 유닛을 제어하도록 구성된 프、로세서를 포함하되, 상기 프로세서는 서버로부터 상기 M0 인스 턴스의 특정 M0 데이터를 요청하기 위한 상기 특정 M0 데이터를 식별하는 URI (Uniform Resource Identifier) 정보를 포함하는 요청을 수신하고， 상기 URI 정보 에 제 1CV가 포함되어 있는지 여부를 판단하도록 구성되며 , 상기 URI 정보에 상기 제 1CV 가 포함되어 있지 않으면， 상기 프로세서는 상기 특정 M0 데이터를 상기 서버로 전송하고, 상기 URI 정보가 상기 M0 인스턴스의 루트 (root) 노드를 지시하면, 상기 M0 인스턴스에 대한 제 2CV를 전송하도록 구성될 수 있다.
[19] 본 발명의 다른 일 실시예에 따른 MCKManagement Object) 인스턴스에 할당된 캐시 검증자 (cache validator; CV)를 이용한 M0 데이터를 요청하기 위한 서버로서 , 상 기 M0 인스턴스는 하나 이상의 노드들로 이루어진 트리 구조로 구성되며, 상기 M0 데 이터는 상기 M0 인스턴스에 포함된 노드의 이름, 노드의 값 및 노드의 구조를 포함하 며， 상기 서버는: 무선 주파수 (radio frequency, RF) 유닛; 및 상기 RF 유닛을 제어하 도록 구성된 프로세서를 포함하되 , 상기 프로세서는 상기 M0 인스턴스의 특정 M0 데 이터를 요청하기 위한 상기 특정 M0 데이터를 식별하는 URI (Uniform Resource Identifier) 정보를 포함하는 요청을 상기 단말로 전송하고， 상기 M0 인스턴스에 대 한 제 1CV를 알고 있으면， 상기 URI 정보에 상기 제 1CV를 포함시키도톡 구성되며， 상 기 URI 정보에 상기 제 1CV 가 포함되지 않으면， 상기 프로세서는 상기 요청된 특정 M0 데이터를 상기 단말로부터 수신하고， 상기 URI 정보가 상기 M0 인스턴스의 루트 (root) 노드를 지시하면， 상기 M0 인스턴스에 대한 제 2CV 를 수신하도록 구성될 수 있다.
[20] 상기 과제 해결방법들은 본 발명의 실시예들 중 일부에 불과하며， 본원 발명 의 기술적 특징들이 반영된 다양한 실시예들이 당해 기술분야의 통상적인 지식을 가 진 자에 의해 이하 상술할 본 발명의 상세한 설명을 기반으로 도출되고 이해될 수 있 다.
【유리한 효과】
[21] 본 발명의 일 실시예에 의하면， 서버의 단말의 리소스 요청 및 상기 서버로 의 리소스 제공의 관리를 효율적으로 수행할 수 있다. [22] 본 발명에서 얻은 수 있는 효과는 이상에서 언급한 효과들로 제한되지 않으 며 , 언급하지 않은 또 다른 효과들은 아래의 기재로부터 본 발명이 속하는 기술분야 에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
【도면의 간단한 설명】
[23] 본 발명에 관한 이해를 돕기 위해 상세한 설명의 일부로 포함되는, 첨부 도 면은 본 발명에 대한 실시예를 제공하고, 상세한 설명과 함께 본.발명의 기술적 사상 을 설명한다.
[24] 도 1은 HTTP 웹 캐시를 도시한다.
[25] 도 2는 DM(Device Management)에서 정의된 M0( Management Object) 인스턴스들 의 일 예를 도시한다.
[26] 도 3 은 본 발명의 일 실시예에 따른 M0 인스턴스 -특정 캐시 검증자의 할당 예를 도시한다.
[27] 도 4는 본 발명의 일 실시예에 따른 리소스 요청 방법을 도시한다.
[28] 도 5는 본 발명의 일 실시예에 따른 리소스 제공 방법을 도시한다.
[29] 도 6은 본 발명의 일 실시예와 대비될 수 있는 방법을 도시한다.
[30] 도 7은 본 발명의 실시예 (들)을 구현하기 위한 장치의 블록도를 도시한다. 【발명을 실시를 위한 형태】
[31] 이하， 본 발명에 따른 바람직한 실시 형태를 첨부된 도면을 참조하여 상세하 게 설명한다. 첨부된 도면과 함께 이하에 개시될 상세한 설명은 본 발명의 예시적인 실시형태를 설명하고자 하는 것이며， 본 발명이 실시될 수 있는 유일한 실시형태를 나타내고자 하는 것이 아니다. 이하의 상세한 설명은 본 발명의 완전한 이해를 제공 하기 위해서 구체적 세부사항을 포함한다. 그러나, 당업자는 본 발명이 이러한 구체 적 세부사항 없이도 실시될 수 있음을 안다.
[32] 몇몇 경우, 본 발명의 개념이 모호해지는 것을 피하기 위하여 공지의 구조 및 장치는 생략되거나, 각 구조 및 장치의 핵심기능을 중심으로 한 블록도 형식으로 도시될 수 있다. 또한, 본 명세서 전체에서 동일한 구성요소에 대해서는 동일한 도면 부호를 사용하여 설명한다.
[33] 본 발명에 있어서, 장치는 고정되거나 이동성을 가질 수 있으며， 서버 또는 게이트웨이와 통신하여 사용자데이터 및 /또는 각종 제어정보를 송수신하는 각종 기기 들이 이에 속한다. 장치는 단말 (Terminal Equipment), MS(Mobile Station), MT(Mobile Terminal), UKUser Terminal), SSCSubscribe Station), 무선기기 (wireless device) , PDA(Personal Digital Assistant), 무선 모뎀 (wireless modem) , 휴대기기 (handheld device) 등으로 불릴 수 있다. 또한， 본 발명에 있어서, 서버와 게이트웨이는 일반적 으로 장치， 게이트웨이 및 /또는 다른 서버와 통신하는 고정국 (fixed station)을 말하 며, 장치, 게이트웨이 및 /또는 다른 서버와 통신하여 각종 데이터 및 제어정보를 교 환한다. 한편, 상기 서버 또는 상기 게이트웨이는 각각 서버 장치 또는 게이트웨이 장치로 지칭될 수도 있다.
[34] 이하에서는 본 발명과 관련된 배경기술에 대해 설명한다.
[35] 장치 관리 (Device Management)
[36] 장치 관리 (DM; 'Device Management)는 다양한 관리 당국 (Management Authorities)들의 관점에서 장치 구성 및 장치들의 다른 관리된 객체를 관리하는 것 을 지칭한다. 장치 관리는 장치들 내의 끊임없이 지속되는 정보의 순차적인 업데이트 들， 장치들로부터 관리 정보의 검색， 및 장치들에 의해 생성된 이벤트들과 알람들의 처리를 포함하나， 장치들 내의 초기 구성 정보를 설정하는 것에 한정되지 않는다 (Management of the Device configuration and other managed objects of Devices from the point of view of the various Management Authorities. Device Management includes , but is not restricted to setting initial conf igurat ion information in Devices, subsequent updates of persistent information in Devices , retrieval of management information from Devices and processing events and alarms generated by Devices . )
[37] 관리 트리 (Management Tree)
[38] 관리 트리는 관리 서버가 DM 클라이언트와 상호작용， 예컨대 관리 트리에 값 들을 저장하거나 관리 트리로부터 값들을 검색함으로써 그리고 관리 트리의 속성들을 조작함으로써， 하기 위한 인터페이스이고, 예컨대 관리 트리의 한 속성으로 ACL(access control list)가 있다. (The interface by which the management server interacts with the client：， e.g. by storing and retrieving values from it and by manipulating the properties of it, for exam le the access control lists.) 본 명 세서에서는， 관리 트리는 장치 관리 트리 또는 DM 트리와 상호호환 가능하게 지칭될 수 있다ᅳ
[39] M0 (관리 객체; Management Object) [40] 관리 객체는 서로 몇몇 방식으로 관련된 노드들의 집합 (하나의 노드 단독으 로도 가능)이 될 것이 의도된 관리 트리의 서브 트리이다. 예컨대， ./Devlnfo 노드와 그 자식 노드들은 관리 객체를 형성할 수 있다. 간단한 관리 객체는 하나의 단독 (single) 노드로 구성될 수 있다 (A Management Object is a subtree of the Management Tree which is intended to be a (possibly singleton) collection of Nodes which are related in some way. For example, the ./Devlnfo Nodes form a Management Object . A simple Management Object may consist of one single Node.)
[41] DM Server 또는 DMS(Device Management Server)
[42] DM서버 또는 DMS는 상기 DM 서버 또는 상기 DMS에 대해 특정된 0MA 장치 관 리 인에이블러 (Enabler) 고정 적합 (static conformance) 요구사항들을 따르는 장치 관리 인프라스트럭쳐에 있는 개념적인 소프트웨어 컴포넌트일 수 있다. 상기 DM 서버 또는 상기 DMS 는 DM 클라이언트 -서버 프로토콜 및 DM 서버 -서버 인터페이스의 엔드- 포인트로서 서비스할 수 있다 (An abstract software component in a de loyed Device Management infrastructure that conforms to the OMA Device Management Enabler static conformance requirements specified for DM Servers . It serves as an end-point of the DM Client—Server Protocols and DM Server-Server Interface) .
[43] 또한, 본 명세서에서 DM서버 또는 DMS 는 통신모들， 프로세서모들 등을 구비 하는 장치， 디바이스, 컴퓨터 등 내에 탑재된 채로 제공될 수 있으며, 따라서 하나의 장치로서 구현될 수 있다.
[44] DM Client 또는 DMC(Device Management Client)
[45] DM 클라이언트 또는 DMC는 상기 DM 클라이언트 또는 상기 DMC에 대해 특정된 0MA 장치 관리 인에이블러 (Enabler) 고정 적합 (static conformance) 요구사항들을 따 르는 장치 임플리멘테이션 (implementation)에 있는 개념적인 소프트웨어 컴포넌트일 수 있다. 상기 DM 클라이언트 또는 상기 DMC 는 DM 클라이언트ᅳ서버 프로토콜의 엔드 一포인트로서 서비스할 수 있다 (An abstract software component in a Device im lement at ion that conforms to the OMA Device Management Enabler stat ic conformance requirements specified for DM Clients. It serves as an end-point of the DM CI ient-Server Protocols. ) . [46] 또한， 본 명세서에서 DM 클라이언트 또는 DMC 는 통신모듈， 프로세서모들 등 을 구비하는 상기 DM 의 대상이 되는 장치 내에 탑재된 채로 제공될 수 있으며， 따라 서 하나의 장치로서 구현될 수 있다.
[47] ACKAccess Control List)
[48] ACL 은 관리 트리 내의 특정 노드에 대한 DM 서버 식별자들 및 각각의 DM 서 버 식별자와 연관된 접근 권한 (access right)들의 리스트를 지칭한다 (A list of identifiers and access rights associated with each identifier).
[49] 노드 (Node)
[50] 노드는 관리 트리에 있는 단독 엘리먼트이다. 관리 트리 내에서 노드는 두 종류: 인테리어 노드 및 리프 노드가 있을 수 있다. 노드의 포맷 속성은 노드가 리프 노드인지 인테리어 노드인지 여부에 관한 정보를 제공한다 (A Node is a single element in a Management Tree. There can be two kinds of Nodes in a Management Tree: Interior Nodes and Leaf Nodes . The Format property of a Node provides information about whether a Node is a leaf or an Interior Node.).
[51] 인테리어 노드 (Interior Node)
[52] 인테리어 노드는 자식 노드를 가질 수 있는 반면 노드에 할당된 값 즉, 노 드 값 (node value)은 가질 수 없다. 인테리어 노드의 포맷 속성은 "node' '이다 (A Node that may have child Nodes , but cannot store any value. The Format property of an Interior Node is node) .
[53] 리프 노드 (Leaf Node)
[54] 리프 노드는 자식 노드를 가질 수 없고 대신 노드 값을 가질 수 있다. 리프 노드의 포맷 속성은 "node"가 아니다 (A Node that can store a value, but cannot have child Nodes . The Format property of a Leaf Node is not node.).
[55] 따라서 모든 부모 (parent) 노드는 인테리어 노드가 되어야만 한다,
[56] 영구 노드 (Permanent Node)
[57] 영구 노드는 DDF 속성 스코프가 퍼머넌트 (Permanent)로 설정되있는 노드이다. 노드가 영구 노드가 아니면， 동적 노드에 해당한다. 영구 노드는 서버에 의해 동적으 로 생성되거나 삭제될 수 없다 (A Node is permanent if the DDF property Scope is set to Permanent . If a Node is not permanent , it is dynamic . A permanent Node can never be deleted by the server . ) [58] 동적 노드 (Dynamic Node)
[59] 동적 노드는 DDF 속성 스코프 (Scope)가 다이내믹 (Dynamic)으로 설정되있거나, 상기 DDF 속성 스코프가 특정되지 않은 노드이다 (A Node is dynamic if the DDF property Scope is set to Dynamic, or if the Scope property is unspecified) .
[60] 서버 식별자 (Sever Identifier)
[61] 서버 식별자는 DM 서버에 대한 OMA DM 내부 이름을 지칭한다. DM 서버는 0MA DM 계정을 통해 장치에 존재하는 서버 식별자와 연관된다 (The OMA DM internal name for a DM Server . A DM Server is associated with an existing Server Identifier in a device through OMA DM account.).
[62] ACL 속성 및 ACL 값
[63] DM(device management ) 1.3 프로토콜로 관리되는 모든 단말은 루트 노드 (root node)로 시작되는 하나의 DM 트리 (tree)를 갖게 되고, DM 프로토콜은 DM 트리의 각 노드를 조작함으로써 단말에 관리 명령을 수행한다. 예로, 단말에 다운로드 된 소프 트웨어를 설치하기 위해서는 그 소프트웨어와 매칭되어 있는 인스톨 (install)이라는 노드를 실행 (Exec)하면， 해당 소프트웨어를 설치할 수가 있다. 각각의 노드는 숫자와 같은 단순한 정보를 나타낼 수도 있고， 그림 데이터나 로그 데이터처럼 복잡한 데이 터를 나타낼 수도 있다. 또한 노드는 실행， 다운로드 등과 같이 하나의 명령을 나타 낼 수도 있다.
[64] 각각의 노드는 노드와 관련된 메타 정보를 제공해 주는 속성 (property)을 갖 는다, 이 속성 중에 런타임 (runtime) 속성이 있는데 , 이 속성은 노드가 DM 트리안에 생성이 되어 소멸될 때까지 사용 가능한 속성을 뜻한다. 이러한 런타임 속성에는 ACL, Format , Name, Size, Title, TSt am , Type, VerNo가 있다.
[65] ACL(Access Control List)는 DM 1.3 프로토콜에서는 단말과 서버가 모두 구현 해야 하는 필수 기능이다. ACL 은 특정 DM 서버가 특정 노드에 수행 가능한 DM 명령 (command)들을 명시하며， 명시되지 않는 DM 명령은 수행될 수 없다. 다시 말하면， ACL 은 특정 DM 서버가 특정 노드에 대해 허용된 권한을 의미한다. DM 프로토콜에서 ACL은 DM서버의 서버 식별자에 부여되며, URI, IP 주소, DM 서버 자격 (cert i f icate) 에 부여되지 않는다. 이 서버 식별자는 DM 프로토콜에서 DM 서버를 인증하는 식별자 로써 사용된다. 또한， 이러한 ACL 은 ACL 속성 (property)과 상기 ACL 속성에 부여된 ACL 값으로 제공될 수 있다. 한편， 본 명세서에서 ACL 값은 ACL 정보 (ACL information) 또는 ACL에 관한 정보로 상호호환 가능하게 지칭될 수 있다. DM 1.3 프 로토콜에서는 모든 노드가 ACL 속성을 갖도록 정의되었으며， ACL 속성을 갖는 모든 노드는 비어있는 (empty) ACL 값 또는 비어있지 않은 (non-empty) ACL 값을 갖도록 정의 된다.
[66] ACL 은 다른 런타임 속성과 다른 독특한 성질을 갖는데， 이러한 독특한 대표 적인 성질로서 ACL 상속 (ACL inheritance)이 있다. ACL 상속은 DM 트리안의 어떤 노드 가 ACL 값을 가지고 있지 않을 때， 그 노드에 대한 ACL 값을 부모 노드의 ACL 값에서 가져오는 개념이다. 만약 부모 노드 역시 ACL 값을 가지고 있지 않다면， 그 부모 노 드의 부모 노드에서 ACL 값을 가져오게 된다. DM 프로토콜에서는 DM 트리의 최상위 노드인 루트 노드가 반드시 ACL 값을 갖도록 명시하고 있기 때문에， ACL 값은 반드시 상속되게 된다. 이러한 ACL 상속은 개별 DM 명령별로 이루어지지 않고, 전체 ACL 값 에 대해 수행되기 때문에， ACL 값이 비어 있어야만， 부모 노드로부터 ACL 상속이 이 루어지게 된다. 즉， 어떤 노드의 ACL 값이 Add 권한만올 명시하고 있다면， 명시되어 있지 않는 Get (가져오기) 권한 등은 상속되지 않는다.
[67] DM 프로토콜에서는 루트 노드는 ACL 에 대한 기본 값으로 ''Add=*&Get=*"을 갖 게 되며 , 여기서 는 와일드 카드 (wild card)로써 , 임의의 DM 서버를 뜻한다 . DM 서 버가 ACL 값을 얻기 위해서는 Get 명령을 이용하면 되며, "./NodeA/Nodel?prop=ACL" 에 대한 Get 명령은 ./NodeA/Nodel 의 ACL 값을 가져오게 된다. 또한 ACL 값을 바꾸 기 위해서는 교체 (Replace) 명령을 이용하면 되며， " ./NodeA/Nodel?prop=ACL' '에 Replace 명령을 수행하여 "Add=DMSl&Delete=DMSl&Get=DMSl"로 값을 바꾸게 되면 ACL 값이 바뀌게 된다. DM 프로토콜에서는 개별 ACL 엔트리 (acl entry)를 바꿀 수가 없고, 전체 ACL 값을 바꿀 수 있도록 정의되어 있다. ACL 값을 얻어 오고， 수정하는 권한 역시 ACL 에 기반하여 정의되는데, 인터리어 노드와 리프 노드에 대한 권한이 조금 다르게 정의되어 있다.
[68] - 인테리어 노드
해당 노드에 Get 과 Replace 권한을 가지고 있다면， 해당 노드의 ACL 값을 각 각 가져오고 교체할 수 있는 권한이 있다. 또한 Replace 권한은 모든 자식 노드의 ACL 값을 교체할 수 있는 권한을 의미한다.
[69] - 리프 노드
해당 노드의 부모 노드에 R印 lace 권한을 가지고 있다면, 그 노드의 ACL 값을 교체할 수 있는 권한이 있다. 해당 노드의 ACL 을 가져오기 위해서는 부모 노드에 Get 권한을 가지고 있어야 한다. 마찬가지로， 해당 노드에 Replace 권한을 가지고 있 다면， 그 노드의 값을 교체할 수 있는 권한을 뜻하며 , ACL을 교체하기 위해서는 부모 노드에 Replace 권한을 가지고 있어야 한다.
[70] 인테리어 노드이건 리프 노드이건 상관없이 해당 노드의 ACL 값을 교체하는 권한은 부모 노드의 ACL 값에 의해 제어될 수 있다. 인테리어 노드에 Replace 권한을 가지고 있다면， 해당 인테리어 노드는 물론， 모든 자식 노드의 ACL 값을 교체할 수 있는 권한을 뜻한다. 따라서， 루트 노드에 Replace 권한을 가지고 있다면, DM 트리 내의 모든 노드에 어떤 권한이든지 가질 수 있다는 뜻이 된다. 하지만 부모 노드에 Replace 권한을 갖고 있다는 것이 곧바로, 자식 노드에 Get 과 같은 특정 권한을 내 포하지는 않으며， 해당 자식 노드에 직접적으로 Get 과 같은 권한이 명시되어 있어야 만 한다. 따라서 명령 수행 전에 ACL 값을 수정해 줘야만 하며， 수정하려는 노드로 가는 길에 있는 모든 노드에 대한 ACL 값의 수정을 통해 최종적으로 해당 자식 노드 의 ACL 값을 수정하게 된다. 이는 불편하기 때문에 , DM 프로토콜에서는 부모 혹은 선 조 노드 (ancestor node)에 Replace 권한을 가지고 있을 경우, 중간 노드의 ACL 값 수 정 없이 바로 해당 노드의 ACL 값의 수정을 허용하고 있다.
[71] DM 서버가 새로운 노드를 추가 (Add) 명령을 통해 생성한 경우 생성된 노드 는 일반적으로 ACL 값을 갖지 않게 되어, 모든 권한을 부모에게서 상속받게 된다. 하 지만 생성한 노드가 인테리어 노드이고, 부모 노드에 R印 lace 권한을 가지고 있지 않 을 경우, 생성과 동시에 ACL 값을 설정하여 해당 노드를 관리하기 위한 층분한 권한 을 갖는 것이 필요하다.
[72] ACL 값을 나타내기 위한 문법은 [DM— TND]에 정의되어 있으며， ACL 값의 한 예 는 "Get=DMSl&Replace=DMSl&Delete=DMS2"를 들 수 있다. 여기서 DMS1 과 DMS2 는 DM Server의 서버 식별자이며， Get, Replace, Delete는 DM 명령이다. 따라서 해당 노드 에 대해 DMS1은 Get 과 Replace 명령을 수행할 수가 있고， DMS2는 Delete 명령을 수 행할 수 있다. 여기서 Get=DMSl, Replace=DMSl, Delete=DMS2 는 각각이 ACL-엔트리 (acl-entry)이며， DM서버의 개별 명령 권한을 나타낸다. 다시말하면, ACL 값은 개별 ACLᅳ엔트리 (acl— entry)의 집합이며， 각 노드의 ACL 값은 적어도하나의 ACL 엔트리를 포함할 수 있다.
[73] DDF(Device Description Framework) [74] DDF 는 특정 디바이스 타입에 대한 관리 신택스와 시멘틱을 기술하는 방법에 관한 설명이다 (A specification for how to describe the management syntax and semantics for a particular device type). DDF는 단말의 MO, 관리 기능 및 DM 트리 구 조에 대한 정보를 제공한다.
[75] DM 1.3 인증
[76] DM 1.3에서는 ACL에 기반하여 인증을 수행한다. DM 인증은 각각의 DM 명령에 대해 별도로 이루어진다. 만약 DM서버가 다수의 DM 명령을 전송했으면, DM 클라이언 트 (client, 이하 DMC)는 개별 명령을 수행하기 전에 인증을 수행하고， 그 결과로 허 가된 DM 명령만 수행하게 된다.
[77] DM트리
[78] DM 트리는 DM 클라이언트에 의해 노출된 M0 인스턴스들의 집합을 지칭한다, DM 트리는 클라이언트와 상호작용하는 관리 서버에 의한 인터페이스로 기능하며, 예 컨대 상기 관리 서버는 DM 트리로부터 특정 값들을 저장하고 검색 (retrieve)하며, 상 기 DM 트리의 속성을 조작할 수 있다.
[79] M0 데이터 (Data)
[80] M0 데이터는 상기 DM 트리에 관한 정보에 해당한다. 상기 정보는 상기 DM 트 리 전체에 대한 것일 수도 상기 DM 트리의 일부 (예컨대, M0 인스턴스 내 서브트리)일 수도 있다. DM 2.0 프로토콜에서， DM 서버는 ClientURI를 이용해 M0 데이터를 요청하 고, M0 데이터는 노드 이름, 노드 값 및 노드 구조로 구성된다.
[81] 리소스 캐성 (Resource Caching)
[82] 캐싱은 서버와 클라이언트 간에 리소스들의 불필요한 전송을 줄이는 기술을 지칭하는 일반 용어이다. 클라이언트는 서버로부터 이전의 웅답들을 저장하고, 동일 한 리소스를 요청할 때 상기 저장된 것을 재사용한다.
[83] 캐시 검증자 (Cache Validator)
[84] 캐시 검증자는 캐시를 검증하는데 사용되는 컴포넌트이다. 캐시 검증은 리소 스 요청자에 캐싱된 리소스가 최신인지 아닌지 여부를 결정하는 프로세스이다. 용어 "최신 (freshness)" 은 상기 리소스가 상기 리소스 요청자로 전달된 이후로 변경되지 않았는지를 의미한다. 캐시 검증자의 일반적 예는 웹 캐시에서 사용되는 ETag 및 Last -Modified 필드이다.
[85] M0 인스턴스 [86] MO 인스턴스는 DM 클라이언트에 의해 공개된 관리 객체 (Management Object; M0)의 존재 (occurrence)이다. M0의 인스턴스들은 동일한 노드 정의들 및 행동들을 공 유하고， DM클라이언트에 의해 공개된 관련 노드들의 집합으로서 표현될 수 있다. 하 나의 M0의 다중 인스턴스들이 DM트리 내 존재할 수 있다.
[87] ClientURI
[88] ClientURI는 단말에 존재하는 DM트리의 특정 노드를 식별한다. ClientURI는 인테리어 노드 또는 리프 노드를 지시 (point)할 수 있다. 따라서， ClientURI 는 특정 노드를 지시하는 지시자 또는 정보로 표현될 수 있다.
[89] HTTP 웹 캐시
[90] HTTP는 웹에서 리소스를 주고 받기 위해 널리 쓰이는 프로토콜이다. HTTP 에 서는 URI 로 지칭되는 리소스에 대해 GET, DELETE, PUT, POST등의 HTTP 명령를 사용 하여 리소스를 조작하게 된다. 예를 들면， HTTP 클라이언트는 웹 상에 존재하는 그림 파일을 획득하기 위해 해당 그림 파일을 지칭하는 URI 를 알고 있어야 하며, 만약 해 당 URI가 "http://w而. server, com/a. jpg' '라고 하면 해당 URI를 대상으로 HTTP GET 명 령을 보내게 된다. HTTP 서버는 HTP GET 명령에 대한 응답으로 해당 그림 파일을 HTTP클라이언트에게 보내주게 된다.
[91] Ηπρ 클라이언트가 한번 다운로드한 동일한 리소스를 추후에 다시 요청했을 때, 만약 해당 그림 파일이 업데이트 되지 않았다면 동일한 리소스를 Ηπρ클라이언 트에게 다시 전송해 주는 것은 비효율적일 수 있다. 이러한 비효율을 해결하기 위한 대표적인 방법으로 웹 캐시 (web cache)가 널리 사용되고 있다. 이러한 웹 캐시는 HTTP 서버와 HTTP 클라이언트 사이에서 응답 속도를 높이고 (low latency), 네트워크 트래픽을 줄일 수 있다. 웹 캐시를 위해 HTTP 클하이언트는 HTTP서버로부터 전송 받 은 리소스를 로컬에 저장 (로컬 카피; local copy)하고 동일 URI 로 다시 요청할 때， 해당 리소스가 변경된 경우에만 HPPT서버로부터 다시 전송 받게 된다ᅳ ᅵ를 ί위해 해 당 리소스가 변경되었는지를 판단할 수 있는 절차가 '필요하며 이를 통상 캐시 검증 절차 (Cache Validation Process 혹은 Cache Validation)라고 칭한다. 캐시 검증 절차 (Cache Validation)는 캐시가 유효한지 만료가 되었는지를 확인하는 절차이며, 이러 한 캐시 검증 절차에서 캐시에 대한 유효성 정보를 주는 것을 캐시 검증자 (Cache Validator)라고 한다. HTTP에서는 대표적으로 ETag와 Last—Modi fied를 캐시 검증자 로 사용한다. [92] ETag 는 HTTP 서버가 특정 버전의 리소스에게 부여하는 일종의 아이디 (identifier)이다. HTTP서버는 리소스 요청에 대한 웅답을 전송할 때， URI가 지칭하 는 리소스와 그 리소스에 할당된 ETag 값을 함께 전송해 준다. HTTP 서버는 리소스가 변경되면 (리소스의 버전이 바뀌게 되면)， ETag값을 바꾸게 되며 캐시 검증 절차에서 HTTP 클라이언트가 보내온 ETag 값과 자신이 가지고 있는 ETag 값을 비교함으로써 HTTP 클라이언트가 가지고 있는 로컬 카피가 최신 버전인지 판단하게 된다.
[93] 만약 최신 버전의 리소스를 HTTP 클라이언트가 가지고 있다면, HTTP 서버는 리소스를 다시 전송할 필요가 없다. 도 1의 왼쪽 테이블은 ETag를 이용한 웹 캐시를 대략적으로 보여주고 있으며 오른쪽 테이블은 Last-Modified 를 이용한 웹 캐시를 보 여준다.
[94] 도 1 의 왼쪽 테이블에서 HTTP 클라이언트는 "http://而 w. server. com/a. jpg" 라는 URI를 통해 "a.jpg"라는 이미지 파일 리소스를 요청하고 있다 (S101-a). HTTP 서 버는 요청된 리소스인 이미지 파일과 함께 ETag 라는 HTTP 헤더를 포함시켜 전송한다 (S102-a). 이 ETag 헤더는 현재 버전의 이미지 파일 리소스에 부여된 ETag 값을 나타 낸다. HTTP 클라이언트는 웅답을 받아 이미지 파일 리소스를 로컬에 저장 (local copy)하몌 ETag값도 함께 저장한다.
[95] HTTP 클라이언트가 동일한 URI 에 대한 요청을 보낼 때， 저장하고 있는 ETag 를 포함시키는데 이를 위해 If-None— Match 라는 HTTP 헤더를 사용하게 된다 (S103-a). HTTP 서버는 이 요청을 받아 U I 가 나타내는 리소스의 현재 버전에 대한 ETag 값과 비교하게 되고, 두 값이 동일하면， ΗπΡ클라이언트에게 리소스가 수정되지 않았음을 "304 Not Modified" 응답 코드를 이용해 알려준다 (S104-a) . HTTP 클라이언트는 HTTP 서버로부터 이러한 웅답을 받으면 자신이 저장하고 있는 리소스가 최신 버전임을 확 인하게 되고 최신 버전 리소스를 서버로부터 다시 전송 받는 일 없이 사용하게 된다.
[96] ETag 외에 주로 사용되는 HTTP 캐쉬 검증자로써 Last— Modified 가 있다. Last-Modified의 기본 동작은 도 1의 오른쪽 테이블에서 보는 것처럼， ETag와 거의 동일하다. ETag와의 차이점은 ETag가 특정 버전의 리소스에 부여된 임의의 식별자라 면， Last-Modifier는 리소스가 마지막으로 변경된 시간을 의미한다. 즉, HTTP 서버는 HTTP 클라이언트에게 리소스를 전송할 때, 리소스가 마지막으로 변경된 시간을 HTTP 의 Last-Modified 헤더에 포함시켜 보내준다 (S102-b) . HTTP 클라이언트는 리소스와 Last -Modified 값을 로컬에 저장하고 있다가， 동일 URI 로 요청을 보낼 때 If-Modified-Since 헤더에 수신한 리소스의 마지막 변경 시간을 포함시켜 보낸다 (S103-b) . HTTP 서버는 리소스가 변경될 때마다 리소스 변경 시간을 업데이트하게 되 고， 동일 URI 에 대한 요청이 If— Modified-Since 헤더를 포함하고 있다면, If-Modified-Since 헤더에 포함된 시간과 자신이 저장하고 있는 마지막 리소스 변경 시간을 비교하여， 리소스가 변경되었다고 생각되면 요청한 리소스를 다시 전송하게 된다. 만약 리소스가 변경되지 않았다면 "304 Not Modified" 웅답 코드를 전송한다 (S104-b) .
[97] DM 2.0 기반 리소스 획득
[98] DM 서버는 단말에 저장되어 있는 정보의 전송을 DM 클라이언트에게 요청할 수 있다. 0MA DM 2.0 에서 이러한 정보는 DM 트리의 형태로 구성이 되어 단말에 저장 되며 통상 관리 객체 데이터 (Management Object data; M0 Data)라고 지칭한다. M0 Data 는 전체 DM 트리 정보가 될 수도 있고 하나의 노드에 저장되어 있는 값일 수도 있다. 도 2는 0MA DM 2.0에서 단말에 저장된 DM 트리를 예시한 것이다. 0MA DM 2.0은 단말 에 있는 M0 인스턴스 (즉， 단말에 생성된 M0 관련 노드들의 집합)들이 계층적인 트리 구조로 구성되도록 제한하지 않으며， 이는 DM 트리의 노드를 지칭하는 ClientURI 가 M0 인스턴스에 기반하여 노드의 주소를 지정하기 때문이다.
[99] 0MA DM 2.0 에서 DM 서버가 M0 Data 를 획득하는 요청은 일반적으로 GET 명령 을 통해 구현된다. DM서버는 GET 명령을 DM Client에게 전달하는 과정에서 GET 명령 의 파라미터로 ClientURI를 함께 전달하며 ClientURI는 DM 트리의 특정 노드를 지칭 한다. DM 서버가 DM 클라이언트에게 명령을 전달하기 위해 Package#2 가 사용되며， Package#2 는 복수개의 DM 명령을 포함할 수 있다. 아래는 두 개의 GET 명령을 포함 하는 Package#2 를 예시하는데， 첫번째 GET 명령은 단말에 저장되어 있는 Devlnfo Management Object 를 요청하고 두번째 GET 명령은 단말에 설치가 되어 있는 모든 소 프트웨어 컴포넌트의 아이디를 요청한다.
HTTP/1.1 200 OK
Conten.:t—Type.:' application/vnd . oma .dm. request+ j son
ί ' .
"CMD"： . [ . ..
[ "GET", "oma :mo： oma-dm-devinfo : 1.0//" ] ,
[ "GET", urn： oma： mo： oraa-scomo： 1.0/ /Inventory/Deployed/ I D"：
] - '
} [100] 위의 예에서 두 개의 GET 명령이 들어 있음을 확인할 수 있으며， GET 명령어 다음에 오는 요소는 ClientURI 이다. 즉， 첫 번째 GET 명령은 "oma:mo:oma一 dm一 devinfo: 1.0//"로 지칭되는 Devlnfo Management Object 전체에 대한 MO Data 를 요청하는 명령이고, 두 번째 GET 명령은 " ur n： oma： mo： oma-s como： 1.0// 1 nvent ory /Dep 1 oyed/ * / 1 D " ]- 지칭하는 설치되어 있는 모 든 소프트웨어 컴포넌트 식별자 (ID)에 대한 전송을 요청한다. DM 클라이언 이러 한 요청을 받으면 아래와 같은 웅답 메시지를 통해 DM 서버에게 요청받은 M0 Data 를 전달해 준다. 각 명령에 대한 응답 코드 전송은 Package#3 를 이용하여 이루어지며, 위 Package#2 에 대한 웅답으로 DM 클라이언트는 아래와 같은 HTTP 메시지를 전송한 다.
POST /dmserver/dm20 HTTP/1.1
Content-Type： multipart/ form-data; bounciary=boundary Accept： application/vnd. oma .dm. request + j son
OMADM-DevID: IMEI : 493005100592800
Host： www . dms , com
—— boundary
Content -Disposition: form-data
Content-Type： application/vnd . oma . dm. response+ j son
{
"Status"： [
200,
200
}
""一 boundary
Content -Disposition: form-data; name:
Content-Type： application/dmmo+ j son
{
"DDF"： "http: //www . endor . com/DDF/devinf ol .0. ddf "ClientURI "： "oma : mo： oma-dm-devinf o :1.0//",
"Data"： {
"Devlnfo"： {
"DevID": "IMEI: 493005100592800",
"Man"： "Vendor" ,
"Mod": "DM— Client",
"DmV": "2,0",
"Lang"： "en",
"DevType"： "smartphone" ,
"OEM":
" FwV"： "android4.0.4",
"SwV": "Vendorl.2",
"HwV":
}
}
--boundary
Content -Disposition： form-data; name="I Gontent-Type : app>licat-ion/.dinmo+ j:son
{ ■ . ： ; ' '. · ■■ ',
"DDF"： . "http': //www-, vendor . com/DDF/.qma-scomol .0. ddf 'V, - ' ' .,
"ClientURI"： "urn: omai!mo： oma-scbmo: 1.0//Inventory/Deployed/pkgl ID", ' ■
"MOData":- {.
"ID"： "pkgl id"
} . ■ ~ ' ' '/
.}, . V ..
{ . ᅳ ——
. "DDF"： "http: //www. vendor . com/DDF/oma-scomol .0. ddf " ,
"ClientURI"： "urn: oma :mo： oma-scomo： 1.0//Inventory/Deployed/pkg2/ ID",.
"MOData":' { '.
. "ID"： "pkg2_id"
} . ' ᅳ
} .
--boundary-- .
[101] 위의 예에서 DM 클라이언트의 응답은 HTTP 멀티파트 (multipart)를 이용하여 이뤄지고 있으며, 첫 번째 encapsulation 은 Package#3 를 포함하고 있고， 두 번째 encapsulation 은 첫 번째 GET 명령에 대한 웅답이고， 세 번째 encapsulation 은 두 번째 GET 명령에 대한 웅답이다. DM서버는 DM 클라이언트에게 이러한 식으로 MOData 를 요청하고 DM 클라이언트는 요청받은 M0 Data를 DM 서버에게 전달하게 된다.
[102] 위와 같이 DM 서버가 GET을 이용해 요청한 M0 Data 를 DM 클라이언트가 항상 전송하게 되면 비효율이 발생할 수 있다. 즉, 상기 M0 Data 의 전송에 필요한 시간이 길어져 웅답 시간이 높아지고 필요없는 데이터의 전송으로 인해 네트워크 자원이 낭 비될 수 있다.
[103] DM 2.0에 HTTP 웹 캐시를 적용한 예
[104] 위에서 설명한 HTTP 웹 캐시를 OMA DM 2.0 에 그대로 적용할 수도 있다. 이를 위해 ΗΠΡ 에서 리소스 별로 캐시 검증자를 할당하여 관리하는 것처럼 DM 클라이언트 는 DM 트리의 모든 노드에 캐시 검증자를 할당하고 관리할 수 있다 . DM 서버는 DM 클 라이언트에게 ClientURI 로 지칭되는 리소스를 DM GET 명령으로 요청하면서, 캐시 검 증자가 있다면 이를 추가로 전달하여 요청하는 리소스가 변경되지 않았다면 리소스가 변경되지 않았다는 상태 코드를 받게 된다. 물론 ClientURI 로 요청하는 리소스에 대 해서 캐시 검증자를 가지고 있지 않다면， 캐시 검증자 없이 요청을 전송하게 된다.
[105] 아래는 Devlnfo M0의 FwV노드 (Device의 Firmware 버전 정보를 저장)를 요청 하는 GET 명령을 나타낸 것이다. FwV 노드 (리소스)를 요청하는 첫번째 GET 명령이라 고 보면, DM 서버는 이에 대한 로컬 캐시는 물론 이에 대한 캐시 검증자로 가지고 있 지 않을 것이기 때문에 캐시 검증자 없이 GET 명령을 아래와 같이 전송하게 된다.
HTTP/1.1 200 OK
Content-Type： application/vnd . oma .dm. request+j son
{
"C D"： [
[ "GET", "oma: mo： oma-dm-devinf o： 1.0//FwV
[106] DM 클라이언트가 위의 GET 명령을 받게 되면， 캐시 검증자가 없기 때문에 아 래와 같이 DM 서버가 요청한 리소스를 보내게 된다. DM 클라이언트는 리소스를 전송 할 때 리소스에 대한 캐시 검증자를 함께 보낼 수 있으며 이는 아래에 "CV" 키를 통 해 캐시 검증자를 전달한다. 여기서는 ETag를 캐시 검증자로 가정하였다.
POST /dmserver/dm20 HTTP/1.1
Content-Type： multipart /form-data; boundary=boundary Accept： application/vnd. oma . dm. request+j son
OMADM一 DevID: IMEI :493005100592800
Host： www. dms . com
--boundary
Content -Disposition: form-data
Content-Type： application/vnd . omaᅳ dm. response+ j son {
"Status"： [
200
]
--boundary
Content -Disposition: form-data; name="0"
Content-Type： application/dmmo+ j son
{
"DDF"： "http: //www. vendor . com/ DDF/ devinfol .0 , ddf "ClientURI "： " oma： mo： oma-dm-devinf o： 1.0 / / FwV " ,
"CV"： "686897696a7c876b7e",
"Data": {
"FwV"： "android .0.4"
}
-boundary--
[107] DM 클라이언트로부터 위와 같은 응답을 받았을 경우， DM 서버는 단말의 펌웨 어 버전인 "android4.0.4"와 이 리소스에 대한 캐시 검증자인 "686897696a7c876b7e" 를 함께 저장할 수 있다. 이 경우， 추후 동일한 리소스를 DM 서버가 요청할 때 아래 와 같은 GET 명령을 사용하여 리소스 요청할 수 있다. GET 명령의 두 번째 파라미터 로 들어간 "686897696a7c876b7e"가 캐시 검증자이다.
HTTP/1.1 200 O
Content-Type： application/vnd . oma .dm. request+j son "CMD": [
[ "GET " , oma： mo： oma-dm-devinf o :1.0// FwV" , "686897696a7c876b7e" ]
[108] DM 클라이언트는 이러한 Package#2 를 받았을 때 캐시 검증 절차 (Cache Validation)을 수행한 후, 캐시가 유효하다면 DM 서버에게 "Not Modified "를 알리는 상태 코드 (304)를 전송한다. 이 경우, DM 서버는 로컬 캐시가 여전히 유효함을 알게 됨으로 로컬 캐시에 저장된 "android4.0.4"를 사용할 수 .있다. 아래는 "304 Not Modified"를 알리는 Package#3이다.
POST /dmserver/dm20 HTTP/1.1
Content-Type： application/vnd. oma .dm. response+ j son Accept： application/vnd. oma .dm. request+ j son
OMADM-DevID: IMEI :493005100592800
Host： www.dms.com '
{
Status"
304
[109] 만약 DM 클라이언트가 캐시 검증 절차를 통해 캐시가 유효하지 않았음을 알 게되면 리소스를 보내게 되고 그에 해당하는 캐시 검증자 역시 보낼 수 있다. 아래는 이 경우에 대한 Package#3이다.
POST 7dmserver/dm20 HTTP/1.1
Content-Type： multipart /form-data; boundary=boundary Accept： application/vnd. oma .dm. request + j son
OMADM-DevID: IMEI :493005100592800
Host： www . dms . com
--boundary
Content-Disposition： form-data
Content-Type： application/vnd. oma .dm. response+j son
(
"Status"： [
200
}
--boundary
Content- Disposition： form-data; name=
Content-Type： application/dmitio+ j son
t
"DDF"： "http: //www. vendor . com/DDF/devinfol .0.ddf "ClientURI "： "oma： mo： oma-dm-devinf o： 1.0//FwV" ,
"CV": "6a7c876b7e68689769",
"Data": {
"FwV"： "android4.0.5"
} --boundairy-.-.. ' ' '' , - V' '： ' . ... '
[110] 이렇게 HTTP 웹 캐시를 OMA DM 2.0에 바로 적용한 경우 DM클라이언트는 모든 리소스에 대해서 캐시 검증자를 부여해야 하기 때문에 다수의 캐시 검증자에 대한 관 리 문제와 전체 프로토콜이 무거워지는 결과를 초래한다. 또한， 인테리어 노드에 캐 시 검증자가 할당되었을 때， 해당 캐시 검증자가 유효성을 검증해야 할 리소스의 범 위는 어디까지인가 하는 문제가 생긴다. 즉， 인테리어 노드에 할당된 캐시 검증자의 경우， 그 자식 노드나 후손 노드가 업데이트 된 경우 캐시 검증자를 업데이트해야 하 는지 등이 문제가 된다.
[111] 또， 모든 리소스마다 캐시 검증자가 할당되기 때문에 "DM 2.0 기반 리소스 획득" 에서 예를 든 것처럼 다수의 노드를 지칭하는 ClientURI ( " urn： oma： mo： oma-scomo： 1.0// Invent ory/Dep 1 oyed/*/ ID" ) 를 GET 명령에 사용할 경우 문제가 발생한다. 즉， ClientURI 가 다수의 노드를 지칭하기 때문에 GET 명령에서 어 떤 캐시 검증자를 보내야 할지 선택할 수 없고, 더욱이 DM 서버는 얼마나 많은 노드 가 ClientURI로 지정되는지 알 수가 없어 캐시 검증자를 선택할 수가 없다.
[112] 아울러， 모든 리소스마다 캐시 검증자를 할당하지 않고, 일부 리소스에 선택 적으로 캐시 검증자를 할당하는 방안이 고려될 수 있으나， 이러한 방안도 결국 어떤 리소스에 캐시 검증자를 할당할 것인가 또는 캐시 검증자가 할당되지 않은 리소스는 어떤식으로 버전 또는 업데이트를 관리할지가 문제된다.
[113] 이러한 종래 기술의 문제점을 해결하기 위한 본 발명의 일 실시예를 설명하 도록 한다.
[114] 도 3은 본 발명의 일 실시예에 따른 캐시 검증자 할당 예를 도시한다.
[115] 캐시 검증자 (cache validator)는 서버가 가지고 있는 로컬 캐시에 대한 유효 성 정보를 줄 수 있는 엔티티이다. 다시 말하면, 상기 캐시 검증자는 로컬 캐시에 대 한 최신성 정보를 제공한다. 캐시 검증자의 대표적인 예로 시간정보 (Last-Modified) 나 ETag등을 들 수가 있다. 본 발명의 일 실시예에서는 도 3 에 도시된 것처럼 오직 M0 인스턴스 (Instance)에만 캐시 검증자를 할당한다. 그러나， DM트리 내 모든 M0 인 스턴스에 캐시 검증자를 할당하는 것은 아니며， M0 인스턴스를 선택하여 필요한 M0 인스턴스에만 캐시 검증자를 할당할 수 있다. 도 3 은 단말의 DM 트리에 존재하는 3 개의 M0 인스턴스 중에서 2개의 M0 인스턴스 (FUM0 인스터스, SC0M0 인스턴스)에 캐시 검증자를 할당한 것을 도식화 하였다. [116] 이렇게 캐시 검증자가 할당된 M0 인스턴스를 캐시 가능 M0 인스턴스 (cacheableMO Instance)라고 부른다. 캐시를 사용하기 위해서 캐시 가능 M0 인스턴스 가 먼저 단말 (또는 DM클라이언트)이나 DM서버에 의해 먼저 선택이 되어야 하고， 선 택된 M0 인스턴스에 캐시 검증자를 할당하여 관리해야 한다. 각각의 캐시 가능 M0 인 스턴스에 대해서 , DM클라이언트는 반드시 캐시 검증자를 할당해야 하며， M0 인스턴스 의 데이터 (노드 값 변경, 새로운 노드의 추가 및 삭제, 노드 이름 변경 등)가 변하 게 될 때마다， 할당된 캐시 검증자를 업데이트해야 한다.
[117] 이렇게 캐시 검증자를 M0 인스턴스에만 할당하게 되면 캐시를 이용한 리소스 요청 /제공 방법이 효율적으로 수행할 수 있다.
[118] 캐시 검증 절차 (Cache Validation Process)는 캐시 또는 캐시 저장본 (cache copy)이 유효한지 유효하지 않은지 검사하는 과정이다. 캐시 검증자 (Cache validator)는 캐시 가능 M0 인스턴스에 할당되어 있기 때문에, 캐시 검증은 상기 캐 시 가능 M0 인스턴스 내 어떤 데이터라도 변경되지 않았다면 성공 ( "success" 또는 "true" )를 반환하고， 어떤 데이터라도 변경되었다면 실패 ( "false" )를 리턴해야 한다. 예를 들어， 상기 캐시 검증자가 ETag 일 경우， DM서버가 전송한 ETag 값과 단 말이 관리하는 해당 M0 인스턴스의 ETag 값을 비교함으로써 수행될 수 있다. 상기 단 말은 상기 DM 서버로부터의 전송된 ETag 값과 자신이 관리하는 ETag ¾):이 같으면 "성공" 을 반환하고 값이 다르면 "실패" 를 반환한다.
[119] 비록 캐시 검증자가 M0 인스턴스에 할당이 되어 있지만 캐시 검증자는 M0 인스턴스 안의 모든 노드에 대해 GET 명령을 전송할 때 사용될 수 있다. 예를 들면， ClientURI 가 특정 리프 노드를 대상으로 하는 GET 명령의 경우에도 DM서버는 M0 인 스턴스에 대한 캐시 검증자를 전달할 수 있다. DM 클라이언트는 M0 인스턴스가 변경 되지 않은지를 전달 받은 캐시 검증자를 통해 검증하고， M0 인스턴스가 변경되지 않 았다면 상기 특정 리프 노드도 당연히 변경되지 않았을 것이므로 "304 Not Modified" 코드를 DM서버에게 전달하게 된다. "304 Not Modified"를 전송받은 DM서 버는 로컬 캐시된 데이터를 참조할 수 있다.
[120] 캐시 검증자를 DM 서버가 DM 클라이언트에게 전달하는 방법은 다양할 수 있 으나 본 발명의 일 실시예에서는 ClientURI 에 포함될 수 있는 cv 필드 (field)를 사 용하도톡 한다. cv 필드를 사용하면 별도의 파라미터로 캐시 검증자를 전달할 필요가 없이 캐시 검증자가 ClientURI 에 통합되어 전달하면 되므로 리소스 요청이 간편하다. ClientURI 는 특정 노드를 가리키므로 해당 특정 노드가 포함된 M0 인스턴스에 대한 캐시 검증자를 cv 필드가 전달하게 된다. 예로, cv 필드가 포함된 ClientURI 는 "oma:mo:oma— dm-devinfo:1.0//FwV?cv=686897696a7c876b7e"와 같을 수 있다ᅳ 이 ClientURI는 Devlnfo M0의 "FwV" 노드를 지칭하는데 이 노드는 Devlnfo M0 인스턴스 에 포함되어 있는 노드이기 때문에 cv 필드로 전달된 값 캐시 검증자 "686897696a7c876b7e' '은 이 Devlnfo M0 인스턴스에 대한 캐시 검증자가 된다.
[121] 도 4 는 본 발명의 일 실시예에 따라 M0 인스턴스에 할당된 캐시 검증자를 이 용한 리소스 요청의 예를 도시한다.
[122] DM 서버는 ClientURI 로 지칭되는 MO Data (리소스)를 요청할 것을 결정할 수 있다 (S401). 상기 요청을 위해 GET 명령이 사용될 수 있다.
[123] 그리고나서ᅳ 상기 DM 서버가 ClientURI 가 지칭하는 노드를 포함하고 있는 M0 인스턴스에 대한 캐시 검증자를 가지고 있는지 여부를 결정할 수 있다 (S402).
[124] 만약 상기 DM서버가 ClientURI 가 지칭하는 노드를 포함하고 있는 M0 인스턴 스에 대한 캐시 검증자를 가지고 있다면， 상기 DM 서버는 cv 필드를 ClientURI 에 포 함시켜서 DM 명령을 보낼 수 있다 (S403). 상기 cv 필드는 해당 M0 인스턴스에 대한 캐시 검증자를 전달하게 된다. 상기 캐시 검증자는 리소스를 획득하는 명령에 대해서 사용할 수가 있기 때문에, DM GET/HPUT/HPOST 명령에 대해 사용할 수 있다..
[125] 만약 DM 서버가 ClientURI 가 지칭하는 노드를 포함하고 있는 M0 인스턴스에 대한 캐시 검증자를 가지고 있지 않다면， DM 서버는 cv 필드없이 리소스 요청 명령을 DM 클라이언트에게 전달할 수 있다 (S403).
[126] DM 클라이언트 (단말)는 상기 DM 서버가 리소스를 요청해 온 경우， 도 5 에 예 시한 방법에 따라 처리를 하게 된다.
[127] 도 5 는 본 발명의 일 실시예에 따라 M0 인스턴스에 할당된 캐시 검증자를 이 용한 리소스 요청에 대한 응답 또는 처리의 예를 도시한다.
[128] DM 클라이언트는 리소스 (MO Data)를 획득하는 DM 명령을 DM 서버로부터 수신 할 수 있다 (S501). 상기 리소스를 요청하는 DM 명령은 GET/HPUT/HPOST 중 하나이며, DM 명령은 ClientURI 라는 파라미터를 함께 전달하게 된다. 이 리소스 획득 명령은 ClientURI가 지칭하는 노드에 대한 MO Data를 요청하는 명령으로 해석될 수 있다.
[129] 상기 DM 클라이언트는 상기 DM 명령의 ClientURI 가 cv 필드를 포함하고 있는 지 여부를 판단할 수 있다 (S502). [130] 만약 상기 DM 명령의 ClientURI 가 cv 필드를 포함하고 있다면, 상기 DM 클라 이언트는 캐시 검증 절차를 수행하게 된다 (S503). 상기 캐시 검증 절차에서， 상기 cv 필드에 의해 제공된 CV에 대웅하는 MO Data가 단말에서 변경되지 않았다면 "성공" 을 반환하고， 상기 MOData의 일 부분이라도 변경되었다면 "실패" 를 리턴해야 한다. ETag 를 예로 들면, 상기 캐시 검증 절차는, 상기 DM 클라이언트가 상기 cv 필드에 의해 제공된 CV (이하, "제 1CV" )가 상기 DM 클라이언트 내에 저장 또는 존재하는. CV (이하， "제 2CV" )와 동일한 지 여부를 판단하는 절차이며， 상기 제 1CV와 상기 제 2CV 가 동일하면 상기 절차는 성공이고， 그렇지 않으면 상기 절차는 실패이다. 본 캐 시 검증 절차는 캐시 검증자의 종류에 따라 달라질 수 있다.
[131] 한편， 앞서 설명의 편의를 위해 "제 1CV" 와 "제 2CV" 로 구분하여 설명하였 다. 간단히 설명하면 , 상기 제 1CV는 상기 DM 서버 내 저장된 CV이며 , 상기 제 2CV는 상기 DM 클라이언트 (즉， 단말) 내 저장된 CV이다. 상기 제 1CV는 상기 제 2CV로부터 비롯되나 (왜냐하면， 특정 M0 인스턴스, 즉 M0 관련 노드들의 집합에 대한 CV 는 DM 단말에 의해 할당되며， 후술할 것처럼 CV 를 갖고 있지 않은 DM 서버는 특정 리소스 요청 시 cv 필드를 상기 요청을 위한 ClientURI 에 포함시키지 않음으로써 상기 DM 단말로부터 CV 를 최초로 수신하게 된다)， 설명의 편의를 위해 상기 DM 서버와 상기 DM 단말 각각이 저장하고 있는 CV를 각각 제 1CV와 제 2CV로 지칭할 수 있음을 알려 둔다.
[132] 상기 MOData가 변경되지 않았으면， 즉 상기 캐시 검증 절차가 "성공" 을 반 환하면 (Etag 캐시 검증자의 경우, 제 1CV와상기 제 2CV가 동일하면 "성공" ：)， 상기 DM 클라이언트는 "304 Not Modified" 를 상기 DM 서버로 전송하고， 요청받은 MOData 를 상기 DM 서버로 전송하지 않는다. 이 웅답을 받은 상기 DM서버는 로컬 캐시를 이 용 또는 참조한다.
[133] 만약 상기 DM 명령의 ClientURI 가 cv 필드를 포함하고 있지 않다면, DM 클라 이언트는 ClientURI에 의해 지칭되는 M0 Data를 DM서버에게 전송할 수 있다 (S505). 또한， 상기 S503 에서， 상기 캐시 검증 절차가 "실패" 인 경우, 즉 DM 서버가 가지 고 있는 해당 MOData의 cv (제 1CV)가 상기 DM 클라이언트가 관리하고 있는 상기 해당 M0 Data의 cv (제 2CV)와 상이한 경우， 상기 DM 클라이언트는 상기 ClientURI 에 의해 지칭되는 M0 Data를 상기 DM서버로 전송할 수 있다 (S505). [134] 한편， 상기 리소스를 요청하는 DM 명령 내 cv 필드 (간단히， cv)가 포함되지 않았거나 상기 캐시 검증 절차가 실패인 경우에 상기 DM 클라이언트는 상기 리소스 (즉, MOData)를 상기 DM서버로 전송하는데, 추가적으로 cv를 전송할지 여부를 결정 할 수 있다. 반면에 종래 기술의 경우ᅳ 어떠한 이유 (예컨대， 주로 업데이트)로 인해 DM서버가 저장하고 있는 cv와 DM 클라이언트가 관리하는 cv가 다르면, 해당 리소스 와 함께 상기 DM 클라이언트가 관리하는 cv를 상기 DM서버로 전송한다,
[135] 추가적으로 cv 를 전송할지 여부를 결정하기 위해， 상기 DM 클라이언트는 상 기 DM 명령， 좀더 상세히는 ClientURI 가 캐시 가능 M0 인스턴스의 루트 노드를 지칭 하고 있는지 여부를 판단할 수 있다 (S506). 즉, DM 클라이언트는 상기 ClientURI 가 지칭하는 노드가 포함된 M0 인스턴스가 캐시 가능 M0 인스턴스인지 여부와 ClientURI 로 지칭된 상기 노드가 상기 캐시 가능 M0 인스턴스의 루트 노드인지 여부를 판단할 수 있다.
[136] 만약 ClientURI 가 M0 인스턴스의 루트 노드를 지칭하고 상기 M0 인스턴스가 캐시 가능 M0 인스턴스 (cacheableMO Instance)이면, 상기 DM 클라이언트는 M0 인스턴 스에 대한 캐시 검증자를 추가적으로 DM 서버에게 전송할 수 있다 (S507). DM 클라이 언트의 웅답 과정은 여기서 종료된다. 상기 DM 서버는 상기 캐시 검증자를 저장하고, 추후에 MO Data를 요청할 때 사용할 수 있다.
[137] 만약 ClientURI 가 M0 인스턴스의 루트 노드를 지칭하지 않거나, 상기 M0 인 스턴스가 캐시 가능 M0 인스턴스 (cacheableMO Instance)가 아니면， 상기 DM 클라이언 트는 추가적으로 상기 캐시 검증자를 상기 DM서버로 전송하지 않는다 (S508).
[138] DM 클라이언트는 S507 에서 캐시 검증자를 DM 서버로 전송할 수 있다. 캐시 검증자는 MOData와 함께 전달되며 , ClientURI가 캐시 가능 M0 인스턴스의 루트 노드 를 지칭하는 경우에 DM 서버에게 전달한다. ClientURI가 캐시 가능 M0 인스턴스의 루 트 노드를 지칭하지 않는 경우는 캐시 검증자를 전달해서는 안 된다. 상기 캐시 검증 자는 M0 인스턴스 전체에 대한 유효성 정보를 주게 되는데， M0 인스턴스의 일부만을 DM 서버가 전송 받은 경우는 추후 DM 클라이언트의 유효성 검증에 문제가 생기기 때 문이다.
[139] 즉， DM 서버로부터 요청된 리소스가 M0 인스턴스의 루트 노드의 하위에 있는 노드 (리소스)이고 상기 요청된 리소스 외 다른 리소스 (들)가 변경된 경우라면， DM 클 라이언트가 상기 요청된 리소스를 상기 DM 서버로 전송할 때 상기 변경된 리소스 (이 변경된 리소스는 DM서버가 요청한 리소스가 아니기 때문에 DM 서버에게 전송되지 않 는다)가 반영된 제 2CV를 상기 DM서버로 전송한다면， 상기 DM서버는 상기 단말에서 는 변경이 되었으나 자신이 획득하지 못한 상기 요청된 리소스 외 다른 리소스 (들)에 대한 획득 기회는 상실하며， 이는 곧 CV의 기능 상실을 의미한다.
[140] 이러한 유효성 검증 문제에 대해 좀더 구체적으로 도 6을 참조하여 설명하도 록 한다. 도 6 은 상기 DM 서버가 상기 DM 클라이언트로 캐시 가능 M0 인스턴스의 루 트 노드에 대한 요청 및 루트 노드가 아닌 리소스에 대한 요청을 모두 포함한 경우를 예시한다.
[141] DM서버는 DM 클라이언트에게 ClientURI "moid: 1.1"을 MO ID 로 갖는 M0 인스 턴스를 요청한다 (S601). ClientURI "moid: 1.1//"은 해당 M0 인스턴스의 루트 노드를 지칭한다. 단말이 가지고 있는 M0 인스턴스는 도 6의 오른쪽 위에 함께 표현하였다.
[142] 상기 DM 클라이언트는 상기 DM 서버가 요청한 M0 인스턴스 전체 데이터를 전 송하고， M0 인스턴스에 할당된 캐시 검증자 "CV1" 을 상기 DM 서버로 전달한다 (S602) . 상기 DM 클라이언트는 c 노드의 이름을 바꾸는 등 c 노드에 대한 업데이트를 수행한다. 그리고나서, M0 인스턴스의 정보 (즉， c 노드에 대한 정보)가 바뀌었기 때문 에 상기 캐시 검증자를 "CV2" 로 업데이트한다 (S603).
[143] 상기 DM 서버는 ClientURI "moid: 1. l//b?cv=CVl"으로 인테리어 노드 b 와 그 하위 노드에 대한 정보를 요청한다 (S604). 이때 , S602에서 수신한 "CV1" 을 cv 필드 를 통해서 상기 DM 클라이언트에게 전달한다.
[144] 그리고나서 , 상기 DM 클라이언트는 수신된 CV1 에 기반하여 캐시 검증 절차를 수행할 수 있다 (S605). 즉， 상기 DM 클라이언트는 상기 "CV1" 이 유효한지 여부를 판단할 수 있다. S603 에서， 상기 DM 클라이언트는 M0 인스턴스의 정보를 업데이트했 고, 그에 따라 상기 캐시 검증자를 CV2 로 업데이트하였다. 따라서, 상기 DM 클라이 언트는 상기 DM 서버로부터 상기 S604 에서 수신된 "CV1" 과 자신이 가지고 있는 캐 시 검증자 "CV2" 가 다르므로， 상기 캐시 유효성 검증을 실패로 판단한다 (예에서는 캐시 검증자가 ETag임을 가정하였다) .
[145] 따라서， 상기 DM 클라이언트는 S604에서 요청된 정보 (노드 b와 그 하위 노드 d 및 e)와 자신이 가지고 있는 캐시 검증자 "CV2" 를 상기 DM 서버로 전송할 수 있 다 (S606). 앞서 도 5와 관련하여 설명한 본 발명의 일 실시예는 S606에 대웅하는 경 우에 "CV2" 의 전달을 허용하지 않지만， 캐시 검증자 "CV2" 를 전달하도록 설정하 고 문제점을 보여주도록 한다. 즉, S606에선 앞서 도 5와 관련하여 설명한 본 발명의 일 실시예와 달리， DM 클라이언트는 DM 서버로부터의 요청이 M0 인스턴스의 루트 노 드에 대한 요청이 아님에도 불구하고 캐시 검증자를 상기 DM 서버로 전송한다.
[146] 이에， 상기 DM 서버는 상기 캐시 검증자 "CV2" 를 저장 (즉， 기존의 "CV1" 에서 "CV2" 로 업데이트)할 수 있다.
[147] 상기 DM 서버는 ClientURI "moid: 1. l//c?cv=CV2"를 사용하여 c 노드에 대한 정보를 요청한다 (S607). 이 때， 상기 DM 서버는 상기 S606 에서 상기 DM 클라이언트 로부터 전달받은 캐시 검증자 "CV2" 를 cv 필드의 형태로 함께 전달한다.
[148] 상기 DM 클라이언트는 S605 에서와 마찬가지로 상기 DM 서버로부터의 캐시 검 증자를 검증하기 위한 캐시 검증 절차를 수행할 수 있다 (S608). 상기 DM 클라이언트 가 가지고 있는 캐시 검증자도 "CV2" 이므로, 상기 DM 클라이언트는 상기 DM 서버로 부터의 캐시 검증자 "CV2" 가 유효하다고 판단하여 상기 캐시 검증 절차를 "성공" 으로 결정한다. 상기 캐시 검증 절차가 성공이므로, 상기 DM 클라이언트는 "304 Not Modified"라는 웅답 코드를 상기 DM서버로 보낸다 (S609).
[149] 여기서 문제는, 상기 DM 서버가 업데이트된 c 노드의 최신 정보를 가지고 있 지 않음에도 불구하고 S609에서 "304 Not Modified" 라는 웅답을 받게 된어 상기 DM 서버가 자신이 c 노드에 대한 최신 정보를 가지고 있다고 오인하는 점이다. 이는 DM 서버의 요청이 M0 인스턴스 루트 노드를 대상으로 하지 않음에도 불구하고 DM 클라이 언트가 S606 에서 캐시 검증자 "CV2" 를 상기 DM 서버로 전달하기 때문이다. 전달된 "CV2" 는 결국 DM 서버가 S607 에서 c 노드에 대한 정보를 요청할 때 사용되므로, 상기 DM 클라이언트는 상기 DM 서버가 c 노드에 대한 최신 정보를 가지고 있다고 잘 못 판단하여 c 노드의 업데이트된 정보를 상기 DM 서버에게 전송하지 않는다. 이러한 문제점을 사전에 방지하기 위해 S607의 요청에 c노드 하나에 대한 캐시 검증자를 포 함할 수도 있다. 하지만 결국 이는 서브 트리마다 캐시 검증자가 존재하는 HTTP 웹 캐시 방법과 유사하고, 따라서 캐시 검증자를 관리하고 리소스를 요청 /웅답하는 메커 니즘이 복잡해지게 된다.
[150] 하지만， 도 5 와 관련된 본 발명의 일 실시예에 따르면， 캐시 검증자를 M0 인 스턴스 자체에만 선택적으로 할당하여， 캐시 검증자의 할당으로 인한 프로세싱 부하 를 줄일 수 있고, 상기 캐시 검증자를 이용한 캐시 검증 절차가 간략하고 효율적으로 수행될 수 있다, [151] 즉, 본 발명의 일 실시예는 종래 기술에서 모든 리소스 각각에 대하여 캐시 검증자 (CV)를 할당한 것과 달리 캐시 검증자를 M0 인스턴스 자체에만 할당하며 , CV를 어떤 노드에 할당할지 여부에 대한 복잡한 문제를 해소할 수 있다. 또한, 이러한 M0 인스턴스 자체에 할당된 CV를 통해 모든 리소스의 최신성을 DM 서버 -DM 단말간 공유 하기 위해, 상기 DM 서버로부터의 CV (제 1CV)가 유효하지 않은 것으로 검증되더라도 항상 상기 DM 단말에 저장된 CV (제 2CV)를 상기 DM 서버로 전송하지 않는다. 이 경우 에, 상기 제 2CV 의 전송 여부를 판단하기 위해 상기 요청된 리소스가 어떤 리소스인 지를 확인하고， 사전에 특정된 리소스인 경우에만 상기 DM 단말은 상기 제 2CV 를 상 기 DM서버로 전송할 수 있다.
[152] 다음으로 본 발명의 일 실시예를 구체적인 예로 설명하도톡 한다.
[153] 아래는 Devlnfo M0의 FwV노드 (Device의 Firmware 버전 정보를 저장)를 요청 하는 GET 명령을 나타낸 것이다. FwV 노드를 요청하는 첫번째 GET 명령이라고 보면， DM 서버는 이에 대한 로컬 캐시는 물론 이에 대한 캐시 검증자로 가지고 있지 않을 것이기 때문에 캐시 검증자 없이 GET 명령을 아래와 같이 전송하게 된다.
HTTP/1.1 200 OK
Content-Type： application/vnd . oma .dm. request+j son
{
"CMD"：
GET", "oma： mo： oma-dm-devinf o： 1.0//FwV" ]
[154] DM 클라이언트가 위의 GET 명령을 받게 되면， 캐시 검증자가 없기 때문에 아 래와 같이 DM 서버가 요청한 리소스를 보내게 된다. DM 클라이언트는 리소스를 전송 할 때 상기 리소스에 대한 캐시 검증자를 함께 보낼 수 있으며， 이는 아래에 "CV" 키 를 통해 캐시 검증자를 전달한다. 여기서는 ETag를 캐시 검증자로 가정하였다.
POST /dmserver/dm20 HTTP/1.1
Content-Type： multipart/f orm-data ; boundary=boundary Accept： application/vnd. oma .dm. request+j son
OMADM-DevID: IMEI : 93005100592800
Host: www.dms.com
--boundary
Content-Disposition: form-data
Content-Type： application/vnd. oma .dm. respons,e+ j son
Status"
200 --boundary
Content -Disposition： form-data; name="0"
Content-Type： application/drnmo+ j son
"DDF"： "http: //www. vendor . com/DDF/devinfol .0. ddf" "Client URI"： "oma :mo： oma-dm-devinf o： 1.0//FwV",
"CV"： " 686897696a7c876b7e",
"Data"： {
"FwV": "android4.0.4"
[155] DM 클라이언트로부터 위와 같은 웅답을 받았을 경우, DM 서버는 단말의 Firmware 버전인 ''android4.0.4''와 이 리소스에 대한 캐시 검증자인 "686897696a7c876b7e"를 함께 저장할 수 있다. 이 경우, 추후 동일한 리소스를 DM 서 버가 요청할 때 아래와 같은 GET 명령을 사용하여 리소스 요청할 수 있다. ClientURI 의 cv 필드로 전달된 "686897696a7c876b7e"가 캐시 검증자이다.
[156] DM
Figure imgf000030_0001
Validation)을 수행한 후, 캐시가 유효하다면 DM 서버에게 "Not Modified"를 알리는 상태 코드 (304)를 전송한다. 이 경우， DM 서버는 로컬 캐시가 여전히 유효함을 알게 됨으로 로컬 캐시에 저장된 "android4.0.4"를 사용할 수 있다. 아래는 "304 Not Modified"를 알래는 Package#3이다.
[157] 만약
Figure imgf000030_0002
게되면 리소스를 보낼 수 있다. 아래는 이 경우에 대한 Package#3이다.
POST /dmserver/dm20 HTTP/1.1
Content-Type： multipart/ form-data; boundary=boundary Accept： application/vnd. oma . dm. request+j son .
OMADM-DevID: IMEI : 4930.05100592800
Host： www.dms.com
--boundary
Content-Disposition: form-data
Content-Type： application/vnd. oma .dm. response+j son
{
Status"
200
}
--boundary
Content -Disposition: form-data; name="0
Content-Type： application/dmmo+ j son
"DDF"： "http: //www. endor . com/DDF/devinf ol .0.ddf " "ClientURI "： "oma : mo： oma-dm-devinf o： 1.0//FwV" ,
"Data"： {
"FwV": "android .0.5"
}
}
-boundary——
[158] 도 7 은 본 발명의 실시예 (들)을 수행하도록 구성된 장치의 블록도를 도시한 다. 전송장치 (10) 및 수신장치 (20)는 정보 및 /또는 데이터， 신호， 메시지 등을 나르 는 무선 신호를 전송 또는 수신할 수 있는 R Radio Frequency) 유닛 (13, 23)과， 무선 통신 시스템 내 통신과 관련된 각종 정보를 저장하는 메모리 (12， 22). 상기 RF 유닛 (13， 23) 및 메모리 (12， 22)등의 구성요소와 동작적으로 연결되고， 상기 구성요소를 제어하여 해당 장치가 전술한 본 발명의 실시예들 중 적어도 하나를 수행하도록 메모 리 (12， 22) 및 /또는 RF유닛 (13,23)을 제어하도록 구성된 프로세서 (11, 21)를 각각 포 함한다.
[159] 메모리 (12, 22)는 프로세서 (11， 21)의 처리 및 제어를 위한 프로그램을 저장 할 수 있고, 입 /출력되는 정보를 임시 저장할 수 있다. 메모리 (12， 22)가 버퍼로서 활용될 수 있다.
[160] 프로세서 (11， 21)는 통상적으로 전송장치 또는 수신장치 내 각종 모들의 전반 적인 동작을 제어한다. 특히, 프로세서 (11, 21)는 본 발명을 수행하기 위한 각종 제 어 기능을 수행할 수 있다. 프로세서 (11， 21)는 컨트롤러 (controller), 마이크로 컨 트를러 (microcontroller), 마이크로 프로세서 (microprocessor) , 마이크로 컴퓨터 (microcomputer) 등으로도 블릴 수 있다. 프로세서 (11， 21)는 하드웨어 (hardware) 또 는 펌웨어 (firmware), 소프트웨어, 또는 이들의 결합에 의해 구현될 수 있다. 하드웨 어를 이용하여 본 발명을 구현하는 경우에는, 본 발명을 수행하도록 구성된
ASICs(appl ication specific integrated circuits) 또는 DSPs(digital signal processors) , DSPDs(digital signal processing devices) , PLDsCprogrammable logic devices)ᅳ FPGAs(field progra隱 able gate arrays) 등이 프로세서 (11， 21)에 구비될 수 있다. 한편， 핍웨어나 소프트웨어를 이용하여 본 발명을 구현하는 경우에는 본 발명 의 기능 또는 동작들을 수행하는 모들, 절차 또는 함수 등을 포함하도록 핍웨어나 소 프트웨어가 구성될 수 있으며, 본 발명을 수행할 수 있도록 구성된 펌웨어 또는 소프 트웨어는 프로세서 (11, 21) 내에 구비되거나 메모리 (12， 22)에 저장되어 프로세서 (11, 21)에 의해 구동될 수 있다.
[161] 본 발명의 실시예들에 있어서， 단말， DM클라이언트， DM서버 등은 각각 전송 장치 (10) 또는 수신장치 (20)로 동작할 수 있다.
[162] 이와 같은, 수신장치 또는 전송장치로 단말, DM클라이언트, DM서버 등의 구 체적인 구성은, 도면과 관련하여 전술한 본 발명의 다양한 실시예에서 설명한 사항들 이 독립적으로 적용되거나 또는 둘 이상의 실시예가 동시에 적용되도록 구현될 수 있 다.
[163] 상술한 바와 같이 개시된 본 발명의 바람직한 실시예들에 대한 상세한 설명 은 당업자가 본 발명을 구현하고 실시할 수 있도록 제공되었다. 상기에서는 본 발명 의 바람직한 실시예들을 참조하여 설명하였지만， 해당 기술 분야의 숙련된 당업자는 하기의 특허 청구의 범위에 기재된 본 발명의 사상 및 영역으로부터 벗어나지 않는 범위 내에서 본 발명을 다양하게 수정 및 변경시킬 수 있음을 이해할 수 있을 것이다ᅳ 따라서, 본 발명은 여기에 나타난 실시형태들에 제한되려는 것이 아니라， 여기서 개 시된 원리들 및 신규한 특징들과 일치하는 최광의 범위를 부여하려는 것이다.
【산업상 이용가능성】
[164] 본 발명은 단말, 기지국, 서버 등과 같은 무선 통신 장치에 사용될 수 있다.

Claims

【청구의 범위】
【청구항 1】
MOCManagement Object) 인스턴스에 할당된 캐시 검증자 (cache validator; CV) 를 이용한 M0 데이터의 요청을 처리하기 위한 방법으로서， 상기 방법은 단말에 의 해 수행되며， 상기 M0 인스턴스는 하나 이상의 노드들로 이루어진 트리 구조로 구 성되며， 상기 M0 데이터는 상기 M0 인스턴스에 포함된 노드의 이름， 노드의 값 및 노드의 구조를 포함하며， 상기 방법은;
서버로부터 상기 M0 인스턴스의 특정 M0 데이터를 획득하기 위한 상기 특정 M0 데이터를 식별하는 URKUniform Resource Identifier) 정보를 포함하는 요청을 수신하는 단계 ; 및
상기 URI 정보에 제 1CV가 포함되어 있는지 여부를 판단하는 단계를 포함하 고，
상기 URI 정보에 상기 제 1CV가 포함되어 있지 않으면 ,
상기 요청된 특정 M0 데이터를 상기 서버로 전송하는 단계; 및 상기 URI 정보가 상기 M0 인스턴스의 루트 (root) 노드를 지시하면， 상 기 M0 인스턴스에 대한 제 2CV를 전송하는 단계를 포함하는 것을 특징으로 하 는， 리소스 요청 처리 방법.
【청구항 2】
제 1항에 있어서, 상기 URI 정보에 상기 제 1CV가 포함되어 있으면 ,
상기 제 1CV를 검증하는 단계를 포함하되 ,
상기 제 1CV가 유효한 것으로 검증되면，
상기 제 1CV의 유효함을 지시하는 결과를 상기 서버로 전송하는 단계를 포함하며，
상기 제 1CV가 유효하지 않은 것으로 검증되면,
상기 요청된 특정 M0 데이터를 상기 서버로 전송하는 단계; 및 상기 URI 정보가 상기 M0 인스턴스의 루트 노드를 지시하면， 상기 M0 인스턴스에 대한 제 2CV를 전송하는 단계를 포함하는 것을 특징으로 하는， 리 소스 요청 처리 방법 .
【청구항 3】
제 1항에 있어서, 상기 M0 인스턴스에 변경이 발생되면，
상기 M0 인스턴스에 대한 제 2CV를 업데이트하는 단계를 포함하는 것을 특징 으로 하는, 리소스 요청 처리 방법 .
【청구항 4】
제 1항에 있어서, 상기 M0 인스턴스는 캐시가 설정 가능한 (cacheable) 것을 특징으로 하는, 리소스 요청 처리 방법 .
【청구항 5】
제 1항에 있어서， 상기 제 1CV는 상기 URI에 포함된 특정 필드에 의해 제공되 는 것을 특징으로 하는, 리소스 요청 처리 방법 .
【청구항 6]
제 2항에 있어서,
상기 M0 인스턴스에 어떠한 변경도 발생되지 않았다면 상기 제 1CV는 유효하 다고 판단되는 것을 특징으로 하는， 리소스 요청 처리 방법.
【청구항 7】
MOCManagement Object) 인스턴스에 할당된 캐시 검증자 (cache validator; CV) 를 이용한 M0 데이터를 요청하기 위한 방법으로서， 상기 방법은 서버에 의해 수행 되며， 상기 M0 인스턴스는 하나 이상의 노드들로 이루어진 트리 구조로 구성되며， 상기 M0 데이터는 상기 M0 인스턴스에 포함된 노드의 이름， 노드의 값 및 노드의 구조를 포함하며， 상기 방법은;
상기 M0 인스턴스의 특정 M0 데이터를 획득하기 위한 상기 특정 M0 데이터를 식별하는 URI (Uniform Resource Identifier) 정보를 포함하는 요청을 상기 단말로 전송하는 단계를 포함하되，
상기 M0 인스턴스에 대한 제 1CV를 알고 있으면， 상기 URI 정보에 상기 제 1CV 를 포함시키며，
상기 M0 인스턴스에 대한 제 1CV를 알지 못하면 상기 URI 정보에 상기 제 1CV 를 포함시키지 않으며，
상기 URI 정보에 상기 제 1CV가 포함되지 않으면，
상기 요청된 특정 M0 데이터를 상기 단말로부터 수신하는 단계; 및 상기 URI 정보가 상기 M0 인스턴스의 루트 (root) 노드를 지시하면， 상 기 MO 인스턴스에 대한 제 2CV를 수신하는 단계를 포함하는 것을 특징으로 하 는， 리소스 요청 방법.
【청구항 8]
제 7항에 있어서， 상기 URI 정보에 상기 제 1CV가 포함되면, 상기 단말에 의해 상기 제 1CV가 검증되며，
상기 제 1CV가 유효한 것으로 검증되면， 상기 제 1CV의 유효함을 지시하는 결 과를 상기 단말로부터 수신하는 단계를 포함하며 ,
상기 제 1CV가 유효하지 않은 것으로 검증되면，
상기 요청된 특정 M0 데이터를 상기 단말로부터 수신하는 단계; 및 상기 URI 정보가 상기 M0 인스턴스의 루트 노드를 지시하면, 상기 M0 인스턴스에 대한 제 2CV를 상기 단말로부터 수신하는 단계를 포함하는 것을 특징으로 하는， 리소스 요청 방법 .
【청구항 9】
제 7항에 있어서， 상기 M0 인스턴스 내 특정 리소스가 변경되면，
상기 M0 인스턴스에 대한 제 2CV는 업데이트되는 것을 특징으로 하는 리소스 요청 방법 .
【청구항 10】
제 7항에 있어서， 상기 M0 인스턴스는 캐시가 설정 가능한 (cacheable) 것을 특징으로 하는， 리소스 요청 방법 .
【청구항 11】
제 7항에 있어서， 상기 제 1CV는 상기 URI에 포함된 특정 필드에 의해 제공되 는 것을 특징으로 하는， 리소스 요청 방법.
【청구항 12】
제 8항에 있어서， . .
상기 M0 인스턴스에 어떠한 변경도 발생되지 않았다면 상기 제 1CV는 유효하 다고 판단되는 것을 특징으로 하는, 리소스 요청 방법.
【청구항 13]
M0(Management Object) 인스턴스에 할당된 캐시 검증자 (cache validator; CV) 를 이용한 M0 데이터 요청을 처리하기 위한 단말로서， 상기 M0 인스턴스는 하나 이 상의 노드들로 이루어진 트리 구조로 구성되며, 상기 M0 데이터는 상기 M0 인스턴 스에 포함된 노드의 이름， 노드의 값 및 노드의 구조를 포함하며， 상기 단말은: 무선 주파수 (radio frequency, RF) 유닛; 및
상기 RF 유닛을 제어하도록 구성된 프로세서를 포함하되，
상기 프로세서는 서버로부터 상기 M0 인스턴스의 특정 M0 데이터를 요청하기 위한 상기 특정 M0 데이터를 식별하는 URKUniform Resource Identifier) 정보를 포 함하는 요청을 수신하고， 상기 URI 정보에 제 1CV가 포함되어 있는지 여부를 판단하 도록 구성되며，
상기 URI 정보에 상기 제 1CV가 포함되어 있지 않으면， 상기 프로세서는 상기 특정 M0 데이터를 상기 서버로 전송하고， 상기 URI 정보가 상기 M0 인스턴스의 루 트 (root) 노드를 지시하면， 상기 M0 인스턴스에 대한 제 2CV를 전송하도록 구성되는 것을 특징으로 하는 단말.
【청구항 14]
MOCManagement Object) 인스턴스에 할당된 캐시 검증자 (cache validator; CV) 를 이용한 M0 데이터를 요청하기 위한 서버로서， 상기 M0 인스턴스는 하나 이상의 노드들로 이루어진 트리 구조로 구성되며, 상기 M0 데이터는 상기 M0 인스턴스에 포함된 노드의 이름, 노드의 값 및 노드의 구조를 포함하며， 상기 서버는:
무선 주파수 (radio frequency, RF) 유닛; 및
상기 RF 유닛을 제어하도록 구성된 프로세서를 포함하되 ,
상기 프로세서는 상기 M0 인스턴스의 특정 M0 데이터를 요청하기 위한 상기 특정 M0 데이터를 식별하는 URKUniform Resource Identifier) 정보를 포함하는 요 청을 상기 단말로 전송하고, 상기 M0 인스턴스에 대한 제 1CV를 알고 있으면， 상기 URI 정보에 상기 제 1CV를 포함시키도록 구성되며,
상기 URI 정보에 상기 제 1CV가 포함되지 않으면， 상기 프로세서는 상기 요청 된 특정 M0 데이터를 상기 단말로부터 수신하고, 상기 URI 정보가 상기 M0 인스턴 스의 루트 (root) 노드를 지시하면 상기 M0 인스턴스에 대한 제 2CV를 수신하도록 구성되는 것을 특징으로 하는， 서버.
PCT/KR2013/011947 2013-04-04 2013-12-20 무선 통신 시스템에서 서버의 단말의 리소스 요청 또는 단말의 리소스 제공을 위한 방법 및 이를 위한 장치 WO2014163280A1 (ko)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN201380075406.XA CN105103505B (zh) 2013-04-04 2013-12-20 在无线通信系统中由服务器的终端请求或提供资源的方法和装置
US14/774,608 US10084748B2 (en) 2013-04-04 2013-12-20 Method and apparatus for requesting or providing resource by terminal of server in wireless communication system
JP2016506220A JP6276380B2 (ja) 2013-04-04 2013-12-20 無線通信システムにおけるサーバーの端末のリソース要請又は端末のリソース提供のための方法及びこのための装置

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201361808586P 2013-04-04 2013-04-04
US61/808,586 2013-04-04

Publications (1)

Publication Number Publication Date
WO2014163280A1 true WO2014163280A1 (ko) 2014-10-09

Family

ID=51658534

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2013/011947 WO2014163280A1 (ko) 2013-04-04 2013-12-20 무선 통신 시스템에서 서버의 단말의 리소스 요청 또는 단말의 리소스 제공을 위한 방법 및 이를 위한 장치

Country Status (4)

Country Link
US (1) US10084748B2 (ko)
JP (1) JP6276380B2 (ko)
CN (1) CN105103505B (ko)
WO (1) WO2014163280A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230031114A1 (en) * 2021-07-27 2023-02-02 Synchrony Bank Unique device identification system

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111090514B (zh) * 2018-10-24 2023-06-20 阿里巴巴集团控股有限公司 一种分配计算能力的方法及系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050010552A1 (en) * 2003-07-11 2005-01-13 Nokia Corporation Specifying nodes in device management system
US20060015626A1 (en) * 2004-07-01 2006-01-19 Mika Hallamaa Device management system
WO2012124999A2 (ko) * 2011-03-17 2012-09-20 엘지전자 주식회사 단말의 리소스 제공 방법 및 서버의 리소스 획득 방법
US20130031262A1 (en) * 2011-07-27 2013-01-31 Htc Corporation Methods for handling multiple device management (dm) server addresses in a dm account management object (mo)
US20130078984A1 (en) * 2007-11-15 2013-03-28 Huawei Technologies Co., Ltd. Method and device for creating management object instance in management tree of terminal device

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8701010B2 (en) * 2007-03-12 2014-04-15 Citrix Systems, Inc. Systems and methods of using the refresh button to determine freshness policy
TW201202956A (en) * 2010-06-01 2012-01-16 Htc Corp Method for exchanging device management (DM) tree information and communication apparatus

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050010552A1 (en) * 2003-07-11 2005-01-13 Nokia Corporation Specifying nodes in device management system
US20060015626A1 (en) * 2004-07-01 2006-01-19 Mika Hallamaa Device management system
US20130078984A1 (en) * 2007-11-15 2013-03-28 Huawei Technologies Co., Ltd. Method and device for creating management object instance in management tree of terminal device
WO2012124999A2 (ko) * 2011-03-17 2012-09-20 엘지전자 주식회사 단말의 리소스 제공 방법 및 서버의 리소스 획득 방법
US20130031262A1 (en) * 2011-07-27 2013-01-31 Htc Corporation Methods for handling multiple device management (dm) server addresses in a dm account management object (mo)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230031114A1 (en) * 2021-07-27 2023-02-02 Synchrony Bank Unique device identification system

Also Published As

Publication number Publication date
US20160036776A1 (en) 2016-02-04
CN105103505B (zh) 2018-02-27
JP2016525728A (ja) 2016-08-25
US10084748B2 (en) 2018-09-25
CN105103505A (zh) 2015-11-25
JP6276380B2 (ja) 2018-02-07

Similar Documents

Publication Publication Date Title
US9615346B2 (en) Method and apparatus for notifying information change in wireless communication system
US10506432B2 (en) Method and apparatus for authenticating access authority for specific resource in wireless communication system
US9769801B2 (en) Method and apparatus for updating information regarding specific resource in wireless communication system
US9900727B2 (en) Method and apparatus for controlling access in wireless communication system
US8965958B2 (en) File fetch from a remote client device
CN108289098B (zh) 分布式文件系统的权限管理方法和装置、服务器、介质
CN110673881B (zh) 微服务集群的配置管理方法、装置和计算机设备
US8117293B1 (en) Method of receiving, storing, and providing device management parameters and firmware updates to application programs within a mobile device
US9438603B2 (en) Method for managing access right of terminal to resource by server in wireless communication system, and device for same
CN112688983A (zh) 代理权限管理装置、终端设备及存储介质
US20140040973A1 (en) Method for controlling initial access rights to open mobile alliance device management servers
WO2014163280A1 (ko) 무선 통신 시스템에서 서버의 단말의 리소스 요청 또는 단말의 리소스 제공을 위한 방법 및 이를 위한 장치
JP2015118459A (ja) 画像形成装置、情報端末、サーバ装置、データ処理システム、画像形成装置の通信方法、情報端末の通信方法、サーバ装置の通信方法、及びプログラム
JP5658516B2 (ja) アクセス権管理システムおよび方法

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 201380075406.X

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13881331

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 14774608

Country of ref document: US

ENP Entry into the national phase

Ref document number: 2016506220

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13881331

Country of ref document: EP

Kind code of ref document: A1