WO2018012707A1 - 가상 리소스의 그룹 멤버 유효성 검증 방법 - Google Patents

가상 리소스의 그룹 멤버 유효성 검증 방법 Download PDF

Info

Publication number
WO2018012707A1
WO2018012707A1 PCT/KR2017/003141 KR2017003141W WO2018012707A1 WO 2018012707 A1 WO2018012707 A1 WO 2018012707A1 KR 2017003141 W KR2017003141 W KR 2017003141W WO 2018012707 A1 WO2018012707 A1 WO 2018012707A1
Authority
WO
WIPO (PCT)
Prior art keywords
resource
group
type
virtual resource
virtual
Prior art date
Application number
PCT/KR2017/003141
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 US16/316,577 priority Critical patent/US20190294478A1/en
Publication of WO2018012707A1 publication Critical patent/WO2018012707A1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/008—Reliability or availability analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]

Definitions

  • the present invention relates to a Machine to Machine (M2M) / Internet of Things (IoT) technology, and more particularly, to a method for validating a group member to be included in a group resource.
  • M2M Machine to Machine
  • IoT Internet of Things
  • 1 is a diagram provided to explain a group resource. 1 illustrates a situation in which a "group1" resource, which is a group resource, is generated.
  • the "group1" resource contains a ⁇ fanOutPoint> resource.
  • the ⁇ fanOutPoint> resource is a virtual resource that can be viewed as a type of function only for function execution that does not contain any type, attribute, or any other information or data.
  • the ⁇ fanOutPoint> resource forwards the request of the Originator device to the "/ CSE02 / base1 / res2" resource and the "/ CSE03 / base1 / res3" resource, which are members included in the "group1" resource.
  • the responses are then collected and forwarded to the Originator device.
  • FIG. 2 is a view provided to explain a conventional group member validation method.
  • the member type is designated as “container” and the member IDs are designated as "/ CSE02 / base1 / res2" and "/ CSE03 / base1 / res3". It was.
  • Group-hosted CSEs retrieve resources of "/ CSE02 / base1 / res2" and "/ CSE03 / base1 / res3" to validate the members that the Originator device wants to include in the group. Can be identified. In addition, it is also possible to partially grasp only the resource type attribute instead of acquiring all resources.
  • the resource type of the group members identified as shown in FIG. 2 will be "container”, which is consistent with the member type “container” included in the group creation request, so the group validation succeeds.
  • FIG. 3 is a view provided to explain a problem in conventional group member validation.
  • the Originator device sets the member type to "latest” while requesting the creation of the "group1" resource, and specifies "/ CSE02 / base1 / cnt / latest" as the member ID.
  • the ⁇ latest> resource is a virtual resource that performs the function of returning the last generated ⁇ contentInstance> resource among the child resources of the parent ⁇ container> resource when receiving a retrieve request.
  • the ⁇ latest> resource is a virtual resource and thus does not have information about its type.
  • the ⁇ latest> resource refers to the last ⁇ contentInstance> resource created among the ⁇ contentInstance> resources that are siblings with it, so that the group hosting CSE is the "/ CSE02 / base1 / cnt / latest" resource.
  • the resource type to be obtained and verified will be "contentInstance” which is the resource type of "inst9" that he refers to, not the type of the ⁇ latest> resource.
  • the present invention has been made to solve the above problems, and an object of the present invention is to provide a method for validating a virtual resource as a group member.
  • a group validation method includes: checking a type attribute of a parent resource of a member to be included in a group; And determining the validity as a member of the group based on the confirmation result.
  • the checking may be performed when the member is a resource that does not hold type information.
  • the checking may be performed when the member is a virtual resource.
  • the virtual resource may be addressed by adding the resource name of the virtual resource to the resource ID of the parent resource.
  • the resource name of the virtual resource may be predetermined.
  • the parent resource of the virtual resource may be limited to a predetermined resource.
  • the virtual resource may include a latest resource that applies the latest resource among the existing resources when the request exists, and an oldest that applies the oldest resource among the existing resources when the request exists. It may include at least one of the resources.
  • the checking may further include a first checking step of checking whether a parent resource is a type capable of using the virtual resource as a child.
  • the checking may further include a second checking step of checking whether a type of the virtual resource matches a member type of a group.
  • the step of determining the validity as a member of the group by checking the type attribute of the general resource may further include.
  • the checking step may be performed in a group creation procedure.
  • the checking may be performed in a group update procedure.
  • an electronic device includes a processor that checks a type attribute of a parent resource of a member to be included in a group, and determines validity as a member of the group based on a result of the confirmation; And a storage unit to provide a storage space required for the processor.
  • the processor may be performed when the member is a virtual resource.
  • the processor may determine whether the type of the virtual resource matches the member type of the group to determine the validity.
  • virtual resources can be organized into groups based on virtual resource validation that is not currently supported.
  • 3 is another diagram provided to explain a conventional group member validity determination method
  • FIG. 4 is a view provided for explaining a group member validation method according to an embodiment of the present invention.
  • FIG. 5 is a flowchart provided for explaining a group member validation method according to an embodiment of the present invention.
  • FIG. 6 is a diagram illustrating an M2M / IoT system to which the present invention is applicable;
  • FIG. 7 is an internal block diagram of the electronic devices illustrated in FIG. 6.
  • FIG. 4 is a view provided to explain a group member validation method according to an embodiment of the present invention.
  • the Originator device requests creation of a "group1" resource, while the member type is designated as “latest”, and the member ID list (indicated as “memberIDs” in FIG. 4) is the address of the virtual resource "/ CSE02 /”. base1 / cnt / latest "was assumed to be included.
  • the group hosting CSE can guess from the list of member IDs whether the originator device is a virtual resource or a generic resource that the member wants to include in the group.
  • the member ID list consists of IDs of member resources.
  • the resource ID (or resource address) is defined as adding a virtual resource name with "/" after the ID of the parent resource.
  • a virtual resource does not define a procedure to instantiate a resource. Therefore, a resource name cannot be given separately by a request of a device and an application, and a predefined virtual resource type name is used as the virtual resource name. . Therefore, the virtual resource name and the virtual resource type (name) used in the embodiment of the present invention may be regarded as the same. Since this virtual resource is automatically created virtually when the parent resource is created, the parent resource of this resource cannot create a generic child resource with the same name as the virtual resource name (or the virtual resource type name).
  • the member type of the group resource is ⁇ latest> and the first member ID ends with "latest”. Therefore, the group hosting CSE is responsible for verifying that this member "/ CSE02 / base1 / cnt / latest" resource that the Originator device wants to include in the group is actually a virtual resource of type ⁇ latest> or another type of resource instance named "latest”. You should check
  • the type information of the resource can be directly checked through the resourceType property value of the resource, but since the virtual resource has no property value, the type information cannot be directly checked.
  • the group-hosted CSE obtains information to identify the type of the resource "/ CSE02 / base1 / cnt / latest”, it is assumed that the resource is actually a type of ⁇ latest>.
  • the contentInstance> resource is returned, which can be mistaken for the ⁇ contentInstance> resource type.
  • the specific virtual resource is automatically created as a resource of the specific general resource, and the name of the virtual resource and the type of the parent resource are obtained by using a relationship that the name is previously defined as the resource type name. Check the virtual resource type information by checking together.
  • the group hosting CSE checks the parent resource type of the corresponding resource and verifies whether the parent resource is a type that can have the virtual resource as a child. If the verification is successful, the group hosting CSE confirms that the resource referred to as the member ID is a virtual resource of the type indicated by the corresponding name. In addition, it verifies that the resource type of the member is the same as the member type (memberType attribute) included in the group creation request, and validates the group resource including the virtual resource member.
  • ⁇ contentInstance> is indicated to the group member type and the type information of the resource indicated by the member ID is obtained as in the conventional general resource, and this is a ⁇ latest> type.
  • a group that has a ⁇ latest> resource for another member and a ⁇ oldest> resource for another member turns out to be a ⁇ contentInstance> type. Remains. Because the specific application may require the oldest information and the latest information at the same time, this alternative cannot be applied because these two resource types cannot be distinguished.
  • Originator sends the address of the child resource that is common to each member to the address performing the fan-out, such as "/ CSE02 / grp2 / fanOutPoint / latest", and the group-hosted CSE sends "cnt1 / latest", "cnt2 / latest "to each request.
  • FIG. 5 is a flowchart provided for explaining a group member validation method according to an embodiment of the present invention.
  • the group hosting CSE obtains a group member ID included in a group creation request received from an Originator device (S110).
  • step S110 If the group member ID (address) obtained in step S110 includes a virtual resource type name at the end (S120-Yes), the group hosting CSE obtains the type information of the parent resource of the resource designated as the group member (S140). .
  • the group hosting CSE determines that the group member type included in the group creation request received from the Originator device is S120.
  • the group member validity is verified by checking whether the virtual resource type matches the identified virtual resource type in step S170.
  • the step S150 corresponds to a procedure for checking whether the parent resource identified through the step S140 is a type capable of using the virtual resource identified in the step S120 as a child. This is because the parent resource type of the virtual resource is limited to a predetermined specific resource type.
  • the virtual resource type identified in operation S120 corresponds to a procedure of checking whether the virtual resource type matches the group member type included in the group creation request.
  • the group validation fails (S160).
  • the parent resource type identified in step S140 is a type that cannot include the virtual resource identified in step S120 (S150-No)
  • group validation fails (S160).
  • the group hosting CSE is directly from the group member resource.
  • the group hosting CSE is directly from the group member resource.
  • Validation of a general resource is a virtual resource that uses the type attribute of the parent resource for validation in that it validates as a member of the group by checking the type attribute of the resource designated as a group member rather than the type attribute of the parent resource. There is a difference.
  • steps S110 to S190 are repeated until all of the group member IDs included in the group creation request are performed (S180). If the group member validation is successful for all group member IDs ( S180-No), the group validation is successful (S190).
  • the group validation fails (S160).
  • the ⁇ latest> resource mentioned in the above embodiment is a child resource of the parent ⁇ container> resource when requested, and is the most recent ⁇ contentInstance> resource among ⁇ contentInstance> resources existing in sibling relationship with itself.
  • Another kind of virtual resource that does not hold type information such as the oldest ⁇ contentInstance> resource among the ⁇ contentInstance> resources that exist in siblings as a child resource of the parent ⁇ container> resource when requested.
  • the technical spirit of the present invention may also be applied to a ⁇ oldest> resource, another ⁇ fanOutPoint> resource, a ⁇ semanticFanOutPoint> resource, a ⁇ pollingChannelURI> resource, a ⁇ notificationTargetSelfReference> resource, and the like.
  • the technical idea of the present invention may be applied to any type of resource.
  • the resource performs the same function as the virtual resource but does not hold the type information even if it is not a different resource or a virtual resource called different name
  • the technical idea of the present invention may be applied to any type of resource.
  • the technical idea of the present invention may be applied to any type of resource. Of course.
  • the technical idea of the present invention is applicable to a method of referring to a type attribute of a parent resource of a member other than a member.
  • the virtual resource validation process used when creating a ⁇ group> resource may be used in the same manner even when the member ID list is changed during the ⁇ group> resource update.
  • Structured resource ID (hierarchical address) is referred to as a resource ID and a group member ID, but it is merely an example.
  • the technical idea of the present invention can also be applied when the resource ID is designated / used as an Unstructured resource ID (non-hierarchical address).
  • a structured resource ID (hierarchical resource ID) is referred to as a resource ID and a group member ID, which is a concatenation of a resource name on the resource tree from "/" to the corresponding resource. It is merely exemplary. As another example, the case where a mixture of Unstructured resource ID (non-hierarchical resource ID) and resource name (s) is equally applicable. In the case of the "/ CSE02 / base1 / cnt / latest" resource ID of the above example, when the non-hierarchical resource ID named "cnt" is "res123", the same resource may be represented as "res123 / latest". Application of the present invention will be performed by obtaining a resource "res123" and confirming that the resource is a ⁇ container> type.
  • the M2M / IoT system to which the present invention is applicable includes a server 200-1, a gateway 200-21, 200-22, and a device 200-31, 200-32, 200-33.
  • Various electronic devices such as 200-34 are connected to each other so as to communicate with each other.
  • the technical idea of the present invention may be applied to a case where the electronic device is implemented differently.
  • connection structure of the electronic devices shown in FIG. 6 may also be replaced in other ways as necessary.
  • All electronic devices shown in FIG. 6 may create and update a resource group. That is, the server 200-1, the gateways 200-21, 200-22, and the devices 200-31, 200-32, 200-33, and 200-34 may all create / update resource groups. In this process, they also perform group member validation according to the flowchart shown in FIG. 5.
  • FIG. 7 is an internal block diagram of the electronic devices illustrated in FIG. 6. Configurations necessary for implementing an embodiment of the present invention are the server (200-1), gateways (200-21, 200-22), devices (200-31, 200-32, 200-33, 200-34) Is common. Therefore, in Fig. 7, these are referred to collectively as "200", which will be referred to collectively as electronic devices hereinafter.
  • electronic devices include a communication unit 210, a processor 220, a storage unit 230, and a function block 240.
  • the communication unit 210 is a communication interface means for communicating with an external device and accessing an external network.
  • the processor 220 includes at least one Application Entitr (AE) and Common Service Entity (CSE). Depending on the type and function of the electronic device, the AE may not be included.
  • AE Application Entitr
  • CSE Common Service Entity
  • the CSE of the processor 220 may create / update a resource group, and performs member validation according to the algorithm shown in FIG. 5 in this process.
  • the storage unit 230 provides the storage space required for the operation of the processor 220, such as creating / updating a resource group and validating a member in this process.
  • the function block 240 performs an inherent function of the electronic device. For example, if the electronic device is a device 200-31, 200-32, 200-33, 200-34, the sensor and / or actuator correspond to this functional block 240.
  • the technical idea of the present invention can be applied to a computer-readable recording medium containing a computer program for performing the functions of the apparatus and method according to the present embodiment.
  • the technical idea according to various embodiments of the present disclosure may be implemented in the form of computer readable codes recorded on a computer readable recording medium.
  • the computer-readable recording medium can be any data storage device that can be read by a computer and can store data.
  • the computer-readable recording medium may be a ROM, a RAM, a CD-ROM, a magnetic tape, a floppy disk, an optical disk, a hard disk drive, or the like.
  • the computer-readable code or program stored in the computer-readable recording medium may be transmitted through a network connected between the computers.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Stored Programmes (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

가상 리소스의 그룹 멤버 유효성 검증 방법이 제공된다. 본 발명의 실시예에 따른 그룹 유효성 검증 방법은, 그룹 생성 요청에 수록된 그룹 멤버 ID가 지정하는 리소스의 부모 리소스 타입 정보를 획득하고, 획득된 부모 리소스의 정보를 이용하여 그룹 유효성을 검증한다. 이에 의해, 그룹 멤버로서 가상 리소스의 유효성을 검증할 수 있게 된다.

Description

가상 리소스의 그룹 멤버 유효성 검증 방법
본 발명은 M2M(Machine to Machine)/IoT(Internet of Things) 기술에 관한 것으로, 더욱 상세하게는 그룹 리소스에 포함시킬 그룹 멤버의 유효성을 검증하는 방법에 관한 것이다.
도 1은 그룹 리소스의 설명에 제공되는 도면이다. 도 1에는 그룹 리소스인 "group1" 리소스가 생성되어 있는 상황을 나타내었다.
"group1" 리소스에는 <fanOutPoint> 리소스가 포함되어 있다. <fanOutPoint> 리소스는 타입, 속성은 물론 기타 어떠한 정보나 데이터를 포함하고 있지 않은, 기능 실행만을 위한 일종의 함수로 볼 수 있는 가상 리소스이다.
<fanOutPoint> 리소스는, 도 1에 도시된 바와 같이, Originator 디바이스의 요청을 "group1" 리소스에 포함된 멤버들인 "/CSE02/base1/res2" 리소스와 "/CSE03/base1/res3" 리소스로 전달하고, 그에 대한 응답들을 취합하여 Originator 디바이스에 전달한다.
도 2는 종래의 그룹 멤버 유효성 검증 방법의 설명에 제공되는 도면이다. 도 2에는 Originator 디바이스가 "group1" 리소스의 생성을 요청하면서, 멤버 타입은 "container"로 지정하고, 멤버 ID로 "/CSE02/base1/res2"와 "/CSE03/base1/res3"을 지정한 것을 상정하였다.
그룹 호스팅 CSE는 Originator 디바이스가 그룹에 포함시키고자 하는 멤버들에 대한 유효성을 검증하기 위해, "/CSE02/base1/res2"와 "/CSE03/base1/res3"의 리소스를 획득(retrieve)하여 리소스 타입을 파악할 수 있다. 그리고, 리소스 전부를 획득하는 것이 아닌 리소스 타입 속성만을 부분적으로 획득(partial retrieve)하여 파악하는 것도 가능하다.
도 2에 도시된 바와 같이 파악된 그룹 멤버들의 리소스 타입은 "container" 가 될 것인데, 이는 그룹 생성 요청에 수록된 멤버 타입인 "container"와 일치하므로, 그룹 유효성 검증은 성공한다.
도 3은 종래의 그룹 멤버 유효성 검증시 문제점의 설명에 제공되는 도면이다. 도 3에는 Originator 디바이스가 "group1" 리소스의 생성을 요청하면서, 멤버 타입을 "latest"로 지정하고, 멤버 ID로 "/CSE02/base1/cnt/latest"을 지정한 것을 상정하였다.
<latest> 리소스는 획득(retrieve) 요청 수신 시, 부모 <container> 리소스의 자녀(child) 리소스 중에서 가장 마지막에 생성된 <contentInstance> 리소스를 반환하는 기능을 수행하는 가상 리소스이다.
전술한 <fanOutPoint> 리소스와 마찬가지로, <latest> 리소스도 가상 리소스이므로, 자신의 타입에 대한 정보는 보유하고 있지 않다.
게다가, <latest> 리소스는 자신과 형제(sibling) 관계에 있는 <contentInstance> 리소스 중 가장 마지막에 생성된 <contentInstance> 리소스를 참조하고 있으므로, 그룹 호스팅 CSE가 "/CSE02/base1/cnt/latest" 리소스를 획득하여 확인하게 되는 리소스 타입은 <latest> 리소스의 타입이 아닌, 그가 참조하고 있는 "inst9"의 리소스 타입인 "contentInstance"가 될 것이다.
따라서, 그룹 멤버로서 종래의 기술로 가상 리소스의 유효성을 검증하는 것은 불가능하다.
본 발명은 상기와 같은 문제점을 해결하기 위하여 안출된 것으로서, 본 발명의 목적은, 그룹 멤버로서 가상 리소스의 유효성을 검증할 수 있는 방법을 제공함에 있다.
상기 목적을 달성하기 위한 본 발명의 일 실시예에 따른, 그룹 유효성 검증 방법은, 그룹에 포함할 멤버의 부모 리소스의 타입 속성을 확인하는 단계; 확인 결과를 기초로, 그룹의 멤버로써 유효성을 판단하는 단계;를 포함한다.
그리고, 상기 확인단계는, 상기 멤버가 타입 정보를 보유하고 있지 않은 리소스인 경우에 수행될 수 있다.
또한, 상기 확인단계는, 상기 멤버가 가상 리소스인 경우에 수행될 수 있다.
그리고, 상기 가상 리소스는, 부모 리소스의 리소스 ID에 가상 리소스의 리소스 이름이 추가되어 어드레스 될 수 있다.
또한, 상기 가상 리소스의 리소스 이름은, 사전에 정해져 있을 수 있다.
그리고, 상기 가상 리소스의 부모 리소스는, 사전에 정해져 있는 리소스로 제한될 수 있다.
또한, 상기 가상 리소스는, 요청이 있으면 존재하는 리소스들 중 가장 최근의(latest) 리소스를 요청에 적용하는 latest 리소스 및 요청이 있으면 존재하는 리소스들 중 가장 오래된(oldest) 리소스를 요청에 적용하는 oldest 리소스 중 적어도 하나를 포함할 수 있다.
그리고, 상기 확인단계는, 부모의 리소스가 상기 가상 리소스를 자식으로 할 수 있는 타입인지 확인하는 제1 확인단계;를 더 포함할 수 있다.
또한, 상기 확인단계는, 상기 가상 리소스의 타입이 그룹의 멤버 타입과 일치하는지 확인하는 제2 확인단계;를 더 포함할 수 있다.
그리고, 본 발명의 일 실시예에 따른, 그룹 유효성 검증 방법은, 그룹에 포함할 멤버가 일반(normal) 리소스이면, 상기 일반 리소스의 타입 속성을 확인하여 그룹의 멤버로써 유효성을 판단하는 단계;를 더 포함할 수 있다.
또한, 상기 확인단계는, 그룹 생성 절차에서 수행될 수 있다.
그리고, 상기 확인단계는, 그룹 갱신 절차에서 수행될 수 있다.
한편, 본 발명의 다른 실시예에 따른 전자 기기는, 그룹에 포함할 멤버의 부모 리소스의 타입 속성을 확인하고, 확인 결과를 기초로 그룹의 멤버로써 유효성을 판단하는 프로세서; 및 상기 프로세서에 필요한 저장 공간을 제공하는 저장부;를 포함한다.
그리고, 상기 프로세서는, 상기 멤버가 가상 리소스인 경우에 수행될 수 있다.
또한, 상기 프로세서는, 부모의 리소스가 상기 가상 리소스를 자식으로 할 수 있는 타입으로 확인되면, 상기 가상 리소스의 타입이 그룹의 멤버 타입과 일치하는지 확인하여 유효성을 판단할 수 있다.
이상 설명한 바와 같이, 본 발명의 실시예들에 따르면, 그룹 멤버로서 가상 리소스의 유효성을 검증할 수 있게 된다. 따라서 현재 지원되지 않은 가상 리소스 유효성 검증을 기반으로 가상 리소스를 그룹으로 구성하여 사용할 수 있게 된다.
도 1은 가상 리소스의 설명에 제공되는 도면,
도 2는 종래의 그룹 멤버 유효성 검증 방법의 설명에 제공되는 도면,
도 3은 종래의 그룹 멤버 유효성 판단 방법의 설명에 제공되는 또 다른 도면,
도 4는 본 발명의 실시예에 따른 그룹 멤버 유효성 검증 방법의 설명에 제공되는 도면,
도 5는 본 발명의 실시예에 따른 그룹 멤버 유효성 검증 방법의 설명에 제공되는 흐름도,
도 6은 본 발명이 적용 가능한 M2M/IoT 시스템을 도시한 도면,
도 7은 도 6에 도시된 전자 기기들의 내부 블럭도이다.
이하에서는 도면을 참조하여 본 발명을 보다 상세하게 설명한다.
도 4는 본 발명의 실시예에 따른 그룹 멤버 유효성 검증 방법의 설명에 제공되는 도면이다.
본 발명의 실시예에 따른 그룹 멤버 유효성 검증 방법에서는, 가상 리소스를 그룹 멤버로 포함시키고자 하는 경우, 가상 리소스에 대한 유효성을 검증하기 위한 기법을 제시한다.
도 4에는 Originator 디바이스가 "group1" 리소스의 생성을 요청하면서, 멤버 타입은 "latest"로 지정하고, 멤버 ID 목록(도 4에는, "memberIDs"로 표기)에 가상 리소스의 주소인 "/CSE02/base1/cnt/latest"를 포함한 것을 상정하였다.
그룹 호스팅 CSE는 멤버 ID 목록으로부터 Originator 디바이스가 그룹에 포함시키고자 하는 멤버가 가상 리소스인지 일반 리소스인지 짐작 할 수 있다. 멤버 ID목록은 멤버 리소스들의 ID들로 구성된다. 가상 리소스의 경우 리소스 ID(혹은 리소스 어드레스)는 부모 리소스의 ID 뒤에 "/"와 함께 가상 리소스 이름을 추가하는 것으로 정의된다.
가상 리소스는 일반 리소스와는 달리 인스턴스 생성하는 프로시저가 정의되지 않으므로 리소스 이름을 디바이스 및 어플리케이션의 요청에 의해 별도로 부여할 수 없고 사전에 정의한 가상 리소스 타입 이름을 그 가상 리소스 이름으로 사용하는 것으로 되어 있다. 따라서 본 발명의 실시예에서 사용하는 가상 리소스 이름과 가상 리소스 타입(이름)은 동일한 것으로 볼 수 있다. 이 가상 리소스는 부모 리소스가 생성 되면서 자동으로 가상적으로 생성되므로 이 리소스의 부모 리소스에는 가상 리소스의 이름(혹은 가상 리소스의 타입 이름)과 동일한 이름의 일반 자녀 리소스를 생성할 수 없다.
위 예에서 그룹 리소스의 멤버 타입은 <latest>이고 첫 번째 멤버 ID는 "latest"로 끝난다. 따라서 그룹 호스팅 CSE는 Originator 디바이스가 그룹에 포함시키고자 하는 본 멤버 "/CSE02/base1/cnt/latest" 리소스가 실제 <latest> 타입의 가상 리소스인지 아니면 "latest"라는 이름의 다른 타입의 리소스 인스턴스인지를 확인해야 한다.
일반 리소스의 경우 해당 리소스의 resourceType 속성 값을 통해 그 리소스의 타입 정보를 직접 확인할 수 있지만 가상 리소스는 그 어떤 속성 값도 가지지 않으므로 타입 정보를 직접 확인할 수 없다. 예를 들어 상기 예시에서 그룹 호스팅 CSE가 "/CSE02/base1/cnt/latest" 리소스의 타입을 확인하기 위해 정보를 획득하면 실제 <latest> 타입의 리소스라는 가정에는 이 가상 리소스가 가리키고 있는 그 어떤 <contentInstance> 리소스가 반환되어 <contentInstance> 리소스 타입으로 오판단 할 수 있다.
이에 따라, 본 발명의 실시예에서는, 특정 가상 리소스는 특정 일반 리소스의 리소스로 자동적으로 생성되고 이름이 리소스 타입 이름으로 사전에 정의되어 있다는 관계를 이용하여, 가상 리소스의 이름과 부모 리소스의 타입 정보를 함께 확인하는 것으로 가상 리소스의 타입 정보를 확인한다.
따라서 도 4에 도시된 상황의 경우 "/CSE02/base1/cnt/latest" 리소스가 "latest"라고 지시되어 있으므로 "latest"의 부모 리소스인 "/CSE02/base1/cnt" 리소스가 <container> 타입의 리소스임을 확인하면 "/CSE02/base1/cnt/latest"가 실제 <latest> 타입의 리소스임을 확인할 수 있다. <container> 리소스(도 4에서는 "cnt" 리소스로 표기)는 인스턴스로 생성 시 항상 "latest"라는 이름의 자녀 가상 리소스를 가지기 때문이다.
가상 리소스의 타입 정보를 확인할 때 부모 리소스의 타입을 확인해야 하는 추가적인 이유로는 예를 들어 <container> 타입의 리소스가 아니라도 "latest"라는 이름의 리소스를 생성할 수 있기 때문이다. 예를 들어 <CSEBase> 리소스에 <AE> 타입의 리소스를 자녀로 가질 때 이는 "latest"라는 이름을 사용할 수 있다.
따라서, 그룹 호스팅 CSE는 가상 리소스의 이름(혹은 가상 리소스 타입 이름)이 멤버 ID로 포함된 경우 해당 리소스의 부모 리소스 타입을 확인하여, 부모 리소스가 가상 리소스를 자녀로 가질 수 있는 타입인지 검증한다. 검증에 성공하면, 그룹 호스팅 CSE는 해당 멤버 ID로 지칭되는 리소스가 해당 이름으로 지시되는 타입의 가상 리소스임을 확인한다. 또한 해당 멤버의 리소스 타입이 그룹 생성 요청에 수록된 멤버 타입(memberType 속성)과 동일함을 확인하여, 가상 리소스 멤버를 포함하는 그룹 리소스에 대한 유효성을 검증한다.
상기 서술된 가상 리소스에 대한 타입 검증 방법의 대안으로 예를 들어 그룹 멤버 타입에 <contentInstance>을 지시하고 멤버 ID로 지시된 리소스의 타입 정보를 종래 일반 리소스와 같이 획득하여 이것이 <latest> 타입인 경우 <contentInstance> 타입으로 인식하여 확인하는 방법을 생각할 수 있다. 하지만 예를 들어 어떤 멤버는 <latest> 리소스를 또 다른 멤버는 <oldest> 리소스를 가지는 그룹의 경우에는 둘 다 <contentInstance> 타입으로 판명되므로 그룹 호스팅 CSE 입장에서는 유효성 검사에서 두 타입을 구분할 수 없는 문제가 남아있다. 특정 어플리케이션의 경우 서비스에 따라 가장 오래된 정보와 가장 최신의 정보를 동시에 필요로 할 수 있기 때문에 이 두 리소스 타입을 구분할 수 없는 본 대안을 적용할 수 없다.
또 다른 대안으로 <latest>와 같은 자녀 리소스를 그룹으로 생성하는 것이 아닌 부모 리소스인 <container> 리소스들을 그룹으로 생성하는 방안을 생각해볼 수 있다. 예를 들어 멤버 1이 "cnt1/latest", 멤버 2가 "cnt2/latest"인 경우 "latest"가 아닌 "cnt1"과 "cnt2"를 그룹으로 구성 후 각각의 <latest> 가상 리소스에 한 번에 접근하기 위해서 Originator가 "/CSE02/grp2/fanOutPoint/latest"와 같이 fan-out을 수행하는 주소에 각 멤버에 공통으로 적용되는 자녀 리소스의 주소를 보내면 그룹 호스팅 CSE는 "cnt1/latest", "cnt2/latest" 각각에 요청을 전달한다. 하지만 이 방법은 상기 예시와 같이 원본 요청 메시지의 "fanOutPoint" 이후의 주소인 "/latest"가 "cnt1", "cnt2"의 멤버 자원 주소 뒤에 붙게 되므로 모든 멤버 리소스가 동일한 이름(가상 리소스의 경우 동일 리소스 타입) 인 경우에만 매우 제한적으로 적용될 수 있다. 즉, <latest>외의 다른 가상 리소스나 일반 리소스를 하나의 그룹으로 묶어서 사용하는 경우 이를 검증할 수 없다.
도 5는 본 발명의 실시예에 따른 그룹 멤버 유효성 검증 방법의 설명에 제공되는 흐름도이다.
도 5에 도시된 바와 같이, 먼저, 그룹 호스팅 CSE는 Originator 디바이스로부터 수신한 그룹 생성 요청에 수록된 그룹 멤버 ID를 획득한다(S110).
S110단계에서 획득된 그룹 멤버 ID(어드레스)가 맨 뒤에 가상 리소스 타입 이름을 포함하고 있는 경우(S120-Yes), 그룹 호스팅 CSE는 그룹 멤버로 지정된 리소스의 부모 리소스의 타입 정보를 획득한다(S140).
S140단계를 통해 파악한 부모 리소스 타입이 S120단계에서 파악된 가상 리소스를 포함할 수 있는 타입으로 검증되면(S150-Yes), 그룹 호스팅 CSE는 Originator 디바이스로부터 수신한 그룹 생성 요청에 수록된 그룹 멤버 타입이 S120단계에서 파악된 가상 리소스 타입과 일치하는지 확인하여, 그룹 멤버 유효성을 검증한다(S170).
S150단계는 S140단계를 통해 파악한 부모 리소스가 S120단계에서 파악된 가상 리소스를 자식으로 할 수 있는 타입인지 확인하는 절차에 해당한다. 가상 리소스의 부모 리소스 타입은 사전에 정해진 특정 리소스 타입로 제한되어 있음에 기인한다.
그리고, S170단계는 S120단계에서 파악된 가상 리소스 타입이 그룹 생성 요청에 수록된 그룹 멤버 타입과 일치하는지 확인하는 절차에 해당한다.
그룹 멤버 타입이 가상 리소스 타입과 일치하지 않는 것으로 확인되면(S170-No), 그룹 유효성 검증은 실패한다(S160). 또한, S140단계를 통해 파악한 부모 리소스 타입이 S120단계에서 파악된 가상 리소스를 포함할 수 없는 타입으로 확인된 경우에도(S150-No), 그룹 유효성 검증은 실패한다(S160).
한편, S110단계에서 획득된 그룹 멤버 ID가 가상 리소스 타입 이름을 포함하고 있지 않은 경우, 즉, 그룹 멤버가 모두 일반(normal) 리소스인 경우(S120-No), 그룹 호스팅 CSE는 그룹 멤버 리소스로부터 직접 지정된 리소스의 타입 정보를 획득하고(S130), Originator 디바이스로부터 수신한 그룹 생성 요청에 수록된 그룹 멤버 타입이 S130단계에서 파악된 타입과 일치하는지 확인하여, 그룹 멤버 유효성을 검증한다(S170).
일반 리소스에 대한 유효성 검증은, 부모 리소스의 타입 속성이 아닌 그룹 멤버로 지정된 리소스 자신의 타입 속성을 확인하여 그룹의 멤버로써 유효성을 검증한다는 점에서, 유효성 검증에 부모 리소스의 타입 속성을 이용하는 가상 리소스와 차이가 있다.
그룹 멤버 유효성 검증에 실패하지 않는다면, S110단계 내지 S190단계는 그룹 생성 요청에 수록된 그룹 멤버 ID 모두에 대해 수행될 때까지 반복되며(S180), 모든 그룹 멤버 ID에 대해 그룹 멤버 유효성 검증이 성공하면(S180-No), 그룹 유효성 검증에 성공한다(S190).
반면, 단 하나의 그룹 멤버 ID에 대해서라도 그룹 멤버 유효성 검증에 실패하면, 그룹 유효성 검증은 실패한다(S160).
지금까지, 가상 리소스의 그룹 멤버 유효성 검증 방법에 대해 바람직한 실시예를 들어 상세히 설명하였다.
위 실시예에서 언급한 <latest> 리소스는, 요청이 있으면 부모 <container> 자원의 자녀 리소스로서 자신과 형제(Sibling) 관계로 존재하는 <contentInstance> 리소스들 중 가장 최근의(latest) <contentInstance> 리소스를 요청에 적용하는 기능을 나타내는 리소스로, 리소스의 타입 정보를 보유하고 있지 않은 리소스의 일종인 가상 리소스의 하나로써 언급한 것이다. 타입 정보를 보유하고 있지 않은 다른 종류의 가상 리소스, 이를 테면, 요청이 있으면 부모 <container> 자원의 자녀 리소스로서 자신과 형제 관계로 존재하는 <contentInstance> 리소스들 중 가장 오래된(oldest) <contentInstance> 리소스를 요청에 적용하는 <oldest> 리소스 및 기타 <fanOutPoint> 리소스, <semanticFanOutPoint> 리소스, <pollingChannelURI> 리소스, <notificationTargetSelfReference> 리소스 등의 경우도 본 발명의 기술적 사상이 적용될 수 있다.
나아가, 가상 리소스와 동일한 기능을 수행하지만 그와 다른 명칭으로 불리는 다른 리소스나 가상 리소스가 아니더라도 타입 정보를 보유하고 있지 않은 리소스라면, 그 어떠한 형태의 리소스라 할지라도 본 발명의 기술적 사상이 적용될 수 있음은 물론이다.
즉, 그룹에 포함할 멤버의 멤버로써 유효성을 검증함에 있어, 멤버가 아닌 그의 부모 리소스의 타입 속성을 참고하는 방법에 대해 본 발명의 기술적 사상이 적용가능한 것이다.
위 실시예에서 <group> 리소스 생성(Create) 시 사용한 가상 리소스 유효성 검사 과정은 <group> 리소스 갱신(Update) 시 멤버 ID 목록이 변경되는 경우에도 동일하게 사용될 수 있다.
또한, 위 실시예에서 리소스 ID, 그룹 멤버 ID로 Structured resource ID(계층적 어드레스)를 언급하였는데, 예시적인 것에 불과하다. 리소스 ID가 Unstructured resource ID(비계층적 어드레스)로 지정/사용되는 경우도 본 발명의 기술적 사상이 적용될 수 있다.
또한, 위 실시예에서 리소스 ID, 그룹 멤버 ID로 Structured resource ID(계층적 리소스 ID)를 언급하였는데, 이는 리소스 트리 상 리소스 이름을 "/"로 상위부터 해당 리소스까지 연접한 것이다. 예시적인 것에 불과하다. 다른 예시로 Unstructured resource ID(비계층적 리소스 ID)와 리소스 이름(들)이 혼합된 경우도 동일하게 적용 가능하다. 상기 예의 "/CSE02/base1/cnt/latest" 리소스 ID의 경우 "cnt"라는 이름의 비계층적 리소스 ID가 "res123"인 경우 동일한 리소스를 "res123/latest"로 나타낼 수 있으며, 이 경우에 본 발명의 내용을 적용하면 "res123" 리소스를 획득하여 이 리소스가 <container> 타입인지 확인하는 절차로 수행될 것이다.
도 6은 본 발명이 적용 가능한 M2M/IoT 시스템을 도시한 도면이다. 본 발명이 적용 가능한 M2M/IoT 시스템은, 도 6에 도시된 바와 같이, 서버(200-1), 게이트웨이(200-21, 200-22), 디바이스(200-31, 200-32, 200-33, 200-34)와 같은 다양한 전자 기기들이 상호 통신가능하도록 연결되어 구축된다.
도 6에 도시된 전자 기기들의 개수, 이를 테면, M2M/IoT 시스템을 구성하는 서버(200-1)의 대수는 예시적인 것이므로, 이와 다르게 구현하는 경우도 본 발명의 기술적 사상이 적용될 수 있다.
나아가, 도 6에 도시된 전자 기기들의 연결 구조 역시, 필요에 따라 다른 방식으로 대체될 수 있음은 물론이다.
도 6에 도시된 모든 전자 기기들은 리소스 그룹을 생성하고 업데이트 할 수 있다. 즉, 서버(200-1), 게이트웨이(200-21, 200-22), 디바이스(200-31, 200-32, 200-33, 200-34) 모두 리소스 그룹을 생성/업데이트할 수 있는 것이다. 그리고, 이 과정에서 이들은 도 5에 도시된 흐름도에 따른 그룹 멤버 유효성 검증을 아울러 수행한다.
도 7은 도 6에 도시된 전자 기기들의 내부 블럭도이다. 본 발명의 실시예를 구현함에 있어 필요한 구성들은 서버(200-1), 게이트웨이(200-21, 200-22), 디바이스(200-31, 200-32, 200-33, 200-34) 모두가 공통된다. 따라서, 도 7에서는 이들을 참조 부호 "200"으로 통칭하여 도시하였으며, 이하에서 전자 기기로 통칭한다.
도 7에 도시된 바와 같이, 본 발명의 다른 실시예에 따른 전자 기기들은, 통신부(210), 프로세서(220), 저장부(230) 및 기능 블록(240)을 포함한다.
통신부(210)는 외부 기기와 통신하고 외부 네트워크에 액세스하기 위한 통신 인터페이스 수단이다.
프로세서(220)는 적어도 하나의 AE(Application Entitr)와 CSE(Common Service Entity)를 포함한다. 전자 기기의 종류와 기능에 따라서는, AE가 포함되지 않을 수도 있다.
프로세서(220)의 CSE는 리소스 그룹을 생성/업데이트할 수 있고, 이 과정에서 멤버 유효성 검증을 도 5에 도시된 알고리즘에 따라 수행한다.
저장부(230)는 프로세서(220)가 동작, 이를 테면, 리소스 그룹을 생성/업데이트하고, 이 과정에서 멤버 유효성을 검증하는 과정에 있어 필요한 저장 공간을 제공한다.
기능 블록(240)은 전자 기기 본연의 기능을 수행한다. 이를 테면, 전자 기기가 디바이스(200-31, 200-32, 200-33, 200-34)인 경우, 센서 및/또는 액츄에이터가 이 기능 블록(240)에 해당한다.
한편, 본 실시예에 따른 장치와 방법의 기능을 수행하게 하는 컴퓨터 프로그램을 수록한 컴퓨터로 읽을 수 있는 기록매체에도 본 발명의 기술적 사상이 적용될 수 있음은 물론이다. 또한, 본 발명의 다양한 실시예에 따른 기술적 사상은 컴퓨터로 읽을 수 있는 기록매체에 기록된 컴퓨터로 읽을 수 있는 코드 형태로 구현될 수도 있다. 컴퓨터로 읽을 수 있는 기록매체는 컴퓨터에 의해 읽을 수 있고 데이터를 저장할 수 있는 어떤 데이터 저장 장치이더라도 가능하다. 예를 들어, 컴퓨터로 읽을 수 있는 기록매체는 ROM, RAM, CD-ROM, 자기 테이프, 플로피 디스크, 광디스크, 하드 디스크 드라이브, 등이 될 수 있음은 물론이다. 또한, 컴퓨터로 읽을 수 있는 기록매체에 저장된 컴퓨터로 읽을 수 있는 코드 또는 프로그램은 컴퓨터간에 연결된 네트워크를 통해 전송될 수도 있다.
또한, 이상에서는 본 발명의 바람직한 실시예에 대하여 도시하고 설명하였지만, 본 발명은 상술한 특정의 실시예에 한정되지 아니하며, 청구범위에서 청구하는 본 발명의 요지를 벗어남이 없이 당해 발명이 속하는 기술분야에서 통상의 지식을 가진자에 의해 다양한 변형실시가 가능한 것은 물론이고, 이러한 변형실시들은 본 발명의 기술적 사상이나 전망으로부터 개별적으로 이해되어져서는 안될 것이다.

Claims (15)

  1. 그룹에 포함할 멤버의 부모 리소스의 타입 속성을 확인하는 단계;
    확인 결과를 기초로, 그룹의 멤버로써 유효성을 판단하는 단계;를 포함하는 것을 특징으로 하는 그룹 멤버 유효성 검증 방법.
  2. 청구항 1에 있어서,
    상기 확인단계는,
    상기 멤버가 타입 정보를 보유하고 있지 않은 리소스인 경우에 수행되는 것을 특징으로 하는 그룹 멤버 유효성 검증 방법.
  3. 청구항 1에 있어서,
    상기 확인단계는,
    상기 멤버가 가상 리소스인 경우에 수행되는 것을 특징으로 하는 그룹 멤버 유효성 검증 방법.
  4. 청구항 3에 있어서,
    상기 가상 리소스는,
    부모 리소스의 리소스 ID에 가상 리소스의 리소스 이름이 추가되어 어드레스 되는 것을 특징으로 하는 그룹 멤버 유효성 검증 방법.
  5. 청구항 3에 있어서,
    상기 가상 리소스의 리소스 이름은,
    사전에 정해져 있는 것을 특징으로 하는 그룹 멤버 유효성 검증 방법.
  6. 청구항 3에 있어서,
    상기 가상 리소스의 부모 리소스는,
    사전에 정해져 있는 리소스 타입으로 제한되는 것을 특징으로 하는 그룹 멤버 유효성 검증 방법.
  7. 청구항 3에 있어서,
    상기 가상 리소스는,
    요청이 있으면 존재하는 리소스들 중 가장 최근의(latest) 리소스를 요청에 적용하는 latest 리소스 및 요청이 있으면 존재하는 리소스들 중 가장 오래된(oldest) 리소스를 요청에 적용하는 oldest 리소스 중 적어도 하나를 포함하는 것을 특징으로 하는 그룹 멤버 유효성 검증 방법.
  8. 청구항 3에 있어서,
    상기 확인단계는,
    부모의 리소스가 상기 가상 리소스를 자식으로 할 수 있는 타입인지 확인하는 제1 확인단계;를 더 포함하는 것을 특징으로 하는 그룹 멤버 유효성 검증 방법.
  9. 청구항 8에 있어서,
    상기 확인단계는,
    상기 가상 리소스의 타입이 그룹의 멤버 타입과 일치하는지 확인하는 제2 확인단계;를 더 포함하는 것을 특징으로 하는 그룹 멤버 유효성 검증 방법.
  10. 청구항 3에 있어서,
    그룹에 포함할 멤버가 일반(normal) 리소스이면, 상기 일반 리소스의 타입 속성을 확인하여 그룹의 멤버로써 유효성을 판단하는 단계;를 더 포함하는 것을 특징으로 하는 그룹 멤버 유효성 검증 방법.
  11. 청구항 1에 있어서,
    상기 확인단계는,
    그룹 생성 절차에서 수행되는 것을 특징으로 하는 그룹 멤버 유효성 검증 방법.
  12. 청구항 1에 있어서,
    상기 확인단계는,
    그룹 갱신 절차에서 수행되는 것을 특징으로 하는 그룹 멤버 유효성 검증 방법.
  13. 그룹에 포함할 멤버의 부모 리소스의 타입 속성을 확인하고, 확인 결과를 기초로 그룹의 멤버로써 유효성을 판단하는 프로세서; 및
    상기 프로세서에 필요한 저장 공간을 제공하는 저장부;를 포함하는 것을 특징으로 하는 전자 기기.
  14. 청구항 13에 있어서,
    상기 프로세서는,
    상기 멤버가 가상 리소스인 경우에 수행되는 것을 특징으로 하는 전자 기기.
  15. 청구항 14에 있어서,
    상기 프로세서는,
    부모의 리소스가 상기 가상 리소스를 자식으로 할 수 있는 타입으로 확인되면, 상기 가상 리소스의 타입이 그룹의 멤버 타입과 일치하는지 확인하여 유효성을 판단하는 것을 특징으로 전자 기기.
PCT/KR2017/003141 2016-07-09 2017-03-23 가상 리소스의 그룹 멤버 유효성 검증 방법 WO2018012707A1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US16/316,577 US20190294478A1 (en) 2016-07-09 2017-03-23 Method for validating validity of group member of virtual resource

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
KR10-2016-0087194 2016-07-09
KR20160087194 2016-07-09
KR10-2016-0148536 2016-11-09
KR1020160148536A KR20180006259A (ko) 2016-07-09 2016-11-09 가상 리소스의 그룹 멤버 유효성 검증 방법

Publications (1)

Publication Number Publication Date
WO2018012707A1 true WO2018012707A1 (ko) 2018-01-18

Family

ID=60952536

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2017/003141 WO2018012707A1 (ko) 2016-07-09 2017-03-23 가상 리소스의 그룹 멤버 유효성 검증 방법

Country Status (3)

Country Link
US (1) US20190294478A1 (ko)
KR (1) KR20180006259A (ko)
WO (1) WO2018012707A1 (ko)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060085440A1 (en) * 2004-10-18 2006-04-20 Srinivas Jandhyala Apparatus, system, and method for efficiently managing membership in a hierarchical data structure
US7383430B1 (en) * 2004-07-29 2008-06-03 Emc Corporation System and method for validating resource groups
US20120174097A1 (en) * 2011-01-04 2012-07-05 Host Dynamics Ltd. Methods and systems of managing resources allocated to guest virtual machines
KR20140133779A (ko) * 2013-05-09 2014-11-20 전자부품연구원 개방형 m2m 시스템 및 방법
WO2016047864A1 (ko) * 2014-09-23 2016-03-31 엘지전자 주식회사 무선 통신 시스템에서 그룹 리소스를 재배치하기 위한 방법 및 장치
WO2016064235A2 (ko) * 2014-10-24 2016-04-28 엘지전자 주식회사 무선 통신 시스템에서 그룹 멤버의 자식 자원을 관리하기 위한 방법 및 이를 위한 장치

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8683103B2 (en) * 2011-08-19 2014-03-25 International Business Machines Corporation Hierarchical multi-tenancy support for host attachment configuration through resource groups

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7383430B1 (en) * 2004-07-29 2008-06-03 Emc Corporation System and method for validating resource groups
US20060085440A1 (en) * 2004-10-18 2006-04-20 Srinivas Jandhyala Apparatus, system, and method for efficiently managing membership in a hierarchical data structure
US20120174097A1 (en) * 2011-01-04 2012-07-05 Host Dynamics Ltd. Methods and systems of managing resources allocated to guest virtual machines
KR20140133779A (ko) * 2013-05-09 2014-11-20 전자부품연구원 개방형 m2m 시스템 및 방법
WO2016047864A1 (ko) * 2014-09-23 2016-03-31 엘지전자 주식회사 무선 통신 시스템에서 그룹 리소스를 재배치하기 위한 방법 및 장치
WO2016064235A2 (ko) * 2014-10-24 2016-04-28 엘지전자 주식회사 무선 통신 시스템에서 그룹 멤버의 자식 자원을 관리하기 위한 방법 및 이를 위한 장치

Also Published As

Publication number Publication date
US20190294478A1 (en) 2019-09-26
KR20180006259A (ko) 2018-01-17

Similar Documents

Publication Publication Date Title
WO2018155822A1 (ko) 계정 등록의 간소화 서비스 및 사용자 인증 서비스를 제공하는 방법 및 이를 이용한 인증 서버
WO2019198885A1 (ko) 블록체인 기반의 다수의 서비스 노드를 사용하는 탈중앙화 서비스 플랫폼
US10581849B2 (en) Data packet transmission method, data packet authentication method, and server thereof
US20170257383A1 (en) Deterministic reproduction of client/server computer state or output sent to one or more client computers
WO2018182126A1 (ko) 안전 소프트웨어 인증 시스템 및 방법
WO2011071265A2 (en) Method and apparatus for using service of plurality of internet service providers
WO2014027859A1 (en) Device and method for processing transaction request in processing environment of trust zone
WO2012144849A2 (en) Access authentication method for multiple devices and platforms
WO2021215864A1 (ko) Api 게이트웨이 엑셀레이터 시스템 및 방법
WO2011099690A2 (en) Method and apparatus for using service of home network device based on remote access
WO2012108613A1 (en) Method and apparatus for controlling connection between devices
WO2020213763A1 (ko) 블록체인과는 다른 형식의 저장소에 저장되는 블록체인 데이터를 검증하는 방법 및 시스템
WO2014084490A1 (en) Method of executing application installed in outside server and image forming apparatus to perform the same
WO2018004020A1 (ko) 마크업 언어 기반 문서에 대한 동시 편집 정합성 검증 장치 및 방법
WO2020171273A1 (ko) 공개 원장 기반 크리덴셜 자율적 운영 시스템 및 방법
WO2018105867A1 (en) Server for providing cloud service and operating method thereof
WO2024090845A1 (ko) 서명 기능 없는 블록체인 지갑의 소유권 인증 방법 및 이를 이용한 시스템
WO2019168219A1 (ko) M2m 시스템에서의 시맨틱 리소스 검색 방법
WO2018012707A1 (ko) 가상 리소스의 그룹 멤버 유효성 검증 방법
WO2018182065A1 (ko) M2m 시스템에서 다중 리소스 구독 연관 방법
WO2023277532A1 (ko) 블록체인 네트워크 상에서 발행된 토큰을 통한 서비스 이용 방법 및 이를 이용하는 시스템
WO2021137397A1 (ko) 블록체인 네트워크 기반의 가상 공통 아이디 서비스 방법 및 이를 이용한 서비스 제공 서버
WO2019066319A1 (en) METHOD FOR PROVIDING KEY INFORMATION AND APPARATUS USING THE METHOD
WO2016108478A1 (ko) 데이터 접근 관리 방법, 이를 위한 컴퓨터 프로그램, 그 기록매체
WO2012077966A1 (en) Apparatus and method for removing malicious code

Legal Events

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

Ref document number: 17827781

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17827781

Country of ref document: EP

Kind code of ref document: A1