KR20170075000A - 머신-투-머신 시스템에서의 애플리케이션 관계 관리 - Google Patents

머신-투-머신 시스템에서의 애플리케이션 관계 관리 Download PDF

Info

Publication number
KR20170075000A
KR20170075000A KR1020177014421A KR20177014421A KR20170075000A KR 20170075000 A KR20170075000 A KR 20170075000A KR 1020177014421 A KR1020177014421 A KR 1020177014421A KR 20177014421 A KR20177014421 A KR 20177014421A KR 20170075000 A KR20170075000 A KR 20170075000A
Authority
KR
South Korea
Prior art keywords
application
relationship
resource
service layer
request
Prior art date
Application number
KR1020177014421A
Other languages
English (en)
Other versions
KR102036420B1 (ko
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 콘비다 와이어리스, 엘엘씨
Publication of KR20170075000A publication Critical patent/KR20170075000A/ko
Application granted granted Critical
Publication of KR102036420B1 publication Critical patent/KR102036420B1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/20—Software design
    • 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/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • 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/54—Interprogram communication
    • G06F9/541—Interprogram communication via adapters, e.g. between incompatible applications
    • 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/54—Interprogram communication

Landscapes

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

Abstract

애플리케이션 관계는 애플리케이션 관계를 생성하고, 애플리케이션 관계를 업데이트하고, 애플리케이션 관계를 검색하고, 애플리케이션 관계를 삭제하거나, 애플리케이션 관계를 발견하는 것과 같이, 서비스 계층에서 분류 및 관리될 수 있다. 서비스는 애플리케이션 관계 인식에 기초할 수 있다.

Description

머신-투-머신 시스템에서의 애플리케이션 관계 관리{MANAGING APPLICATION RELATIONSHIPS IN MACHINE-TO-MACHINE SYSTEMS}
본 출원은 "머신-투-머신 시스템에서의 애플리케이션 관계 관리(MANAGING APPLICATION RELATIONSHIPS IN MACHINE-TO-MACHINE SYSTEMS)"라는 명칭의 2014년 10월 31일자로 출원된 미국 가특허출원 제62/073,582호의 우선권을 주장하며, 상기 출원은 그 전체가 본 명세서에서 참조로서 포함된다.
OneM2M 기능적 아키텍처 베이스라인(그 전체가 참조로서 포함되는 oneM2M-TS-0001 - V-2014-08)은 다양한 하드웨어 및 소프트웨어 내에 쉽게 내장되어 다른 것들 중에서 컨넥티드 자동차 또는 스마트 건강과 같은 상이한 머신-투-머신(M2M) 애플리케이션을 지원할 수 있는 CSL(common service layer)을 명시한다. CSL인 oneM2M은 한 세트의 공통 서비스 기능들(CSF)(예를 들어, 등록 CSF)을 정의한다. 하나 이상의 특정 타입의 CSF들의 세트의 인스턴스 생성은, 상이한 타입들의 네트워크 노드들(예를 들어, 기반구조 노드, 미들 노드, 애플리케이션 특징적 노드) 상에서 호스팅될 수 있는 CSE(common services entity)로서 지칭된다.
도 1은 oneM2M 기능적 아키텍처를 도시한다. 애플리케이션 엔티티(AE)(101) 또는 AE(103)는 기반구조 도메인(107) 또는 필드 도메인(105)에 각각 상주할 수 있는 상이한 M2M 애플리케이션을 지칭한다. oneM2M-TS-0011-Definitions 및 Acronyms-V0.7.0에 따라, 필드 도메인(107)은 "M2M 디바이스, M2M 게이트웨이, 감지 및 작동(Sensing and Actuation; S&A) 장비 및 M2M 영역 네트워크로 구성"되는 한편, 기반구조 도메인(105)은 "애플리케이션 기반구조 및 M2M 서비스 기반구조로 구성"된다. AE(101)는 Mca 인터페이스(108)를 통해 CSE(109)의 CSF에 액세스하여 이를 레버리지할 수 있다. 또한, CSE(109)는 CSF의 세트를 제공하고 CSE(109)는 Mcc 인터페이스(110)를 통해 또 다른 CSE(111)와 통신할 수 있다. CSE(109)는 또한 Mcn 인터페이스(112)를 통해 하부 네트워크들로부터 네트워크 서비스 엔티티(NSE)(113)를 레버리지할 수 있다.
oneM2M 기능적 아키텍처 베이스라인에 따르면, oneM2M 참조점에는 Mca(108), Mcc(110), Mcc'(114) 및 Mcn(112)가 포함된다. Mca 참조점(108)(Mca 인터페이스라고도 함)은 AE(예를 들어, AE(101))와 CSE(예를 들어, CSE(109)) 간의 통신 흐름을 지정한다. Mca 참조점(108)은 AE(101)가 CSE(109)에 의해 제공되는 서비스를 사용하고 CSE(109)가 AE(101)와 통신하는 것을 허용한다. Mcc 참조점(110)은 2개의 CSE(예를 들어, CSE(109) 및 CSE(111)) 간의 통신 흐름을 지정한다. Mcc 참조점(110)은 CSE(109)가 필요한 기능성을 제공하기 위해 CSE(111)의 서비스를 사용할 수 있게 한다. Mcc 참조점(110)을 통해 제공되는 서비스는 CSE(109) 및 CSE(111)에 의해 지원되는 기능성에 의존한다.
Mcc' 참조점(114)은 oneM2M을 따르고 상이한 M2M SP 도메인에 상주하는 기반구조 노드 내의 2개의 CSE 간의 통신 흐름을 지정한다. 따라서, 이는 M2M 서비스 제공자의 네트워크 도메인에 상주하는 기반구조 노드(105)의 CSE(111)가 또 다른 M2M 서비스 제공자(115)의 네트워크 도메인에 상주하는 또 다른 기반구조 노드(도시 생략)의 CSE와 통신하여 그 서비스를 사용하게 하고, 그 반대의 경우도 마찬가지이다. Mcn 참조점(112)은 CSE(109)와 하부 NSE(113) 간의 통신 흐름을 지정한다. Mcn 참조점(112)은 CSE(109)가 필요한 기능성을 제공하기 위해 하부 NSE(113)가 제공하는 서비스(전송 및 연결 서비스 제외)를 사용할 수 있게 한다.
등록(REG) CSF, 애플리케이션 및 서비스 계층 관리(ASM) CSF, 디바이스 관리(DM) CSF, 데이터 관리 및 리포지토리(DMR) CSF, 통신 및 메시지 전달 처리(CMDH) CSF, 서비스 청구 및 회계(SCA) CSF 등을 포함하는 oneM2M 기능적 아키텍처 베이스라인에서 CSE(109) 또는 CSE(111) 내에 몇가지 공통 서비스 기능(CSF)이 정의되었다. 예를 들어, CSE(예를 들어, M2M 서비스 계층 엔티티)는 CSE에 의해 제공되는 다른 CSF들을 레버리지하기 위해 AE가 먼저 자신을 CSE에 등록할 수 있도록 REG CSF를 제공한다. 이 아키텍처는 다수의 AE가 동일한 CSE와 독립적으로 등록할 수 있게 한다. 등록이 완료되면, CSE는 각 AE에 대해 별도의 자원(예를 들어 <application> 자원)을 생성한다. 종래의 oneM2M 기능적 아키텍처 베이스라인은 상이한 애플리케이션 간의 관계를 지원하는 기능이 부족하다.
종래의 oneM2M 아키텍처는 상이한 M2M 애플리케이션(예를 들어, AE) 간의 자원 액세스 및 메시지 교환을 지원한다. 이 아키텍처는 다수의 AE가 동일한 CSE에 등록할 수 있게 하지만, 각 AE는 CSE에 독립적으로 애플리케이션 등록을 행한다. 종래의 M2M/IoT 서비스 계층(예를 들어, oneM2M 기능적 아키텍처 베이스라인, oneM2M-TS-0001 - V-2014-08)은 상이한 애플리케이션 간의 관계를 효율적으로 지원하고 레버리지하는 기능이 부족하다. 본 명세서에는 M2M 또는 IoT 서비스 계층에서 애플리케이션 관계(예를 들어, 부모/자식)를 활용하는 방법이 개시되어 있다.
본 명세서에는 애플리케이션 관계를 생성하고, 애플리케이션 관계를 업데이트하고, 애플리케이션 관계를 검색하고, 애플리케이션 관계를 삭제하거나, 애플리케이션 관계를 발견하는 것과 같이, 서비스 계층에서 공통 서비스로서 애플리케이션 관계 분류 및 애플리케이션 관계 관리가 논의된다. 서비스는 애플리케이션 관계 인식에 기초할 수 있다.
본 내용은 아래 상세한 설명에서 추가로 설명되는 개념들의 선택을 단순화된 형태로 소개하도록 제공된다. 본 내용은 청구 대상의 주요한 특징들 또는 필수 특징들을 식별하기 위한 의도가 아니며, 청구 대상의 범위를 제한하기 위해 사용될 의도도 아니다. 또한, 청구 대상은 본 개시내용의 임의의 부분에서든 언급되는 임의의 또는 모든 단점들을 해결하는 제한 사항들에 제한되는 것은 아니다.
도 1은 예시적인 oneM2M 기능적 아키텍처를 도시한다.
도 2는 예시적인 체육관 사용 사례를 도시한다.
도 3은 예시적인 환경 모니터링 사용 사례를 도시한다.
도 4a는 예시적인 부모/자식 애플리케이션 관계를 도시한다.
도 4b는 예시적인 합성/입력 애플리케이션 관계를 도시한다.
도 5a는 예시적인 애플리케이션 관계 기록 자원을 도시한다.
도 5b는 예시적인 애플리케이션 관계 기록 자원을 도시한다.
도 6은 애플리케이션 관계를 생성하기 위한 예시적인 방법을 도시한다.
도 7은 예시적인 부모/자식 애플리케이션 관계 생성을 도시한다.
도 8은 기존의 등록된 애플리케이션 간의 애플리케이션 관계를 검색하기 위한 예시적인 방법을 도시한다.
도 9은 기존의 등록된 애플리케이션 간의 애플리케이션 관계를 갱신하기 위한 예시적인 방법을 도시한다.
도 10은 기존의 등록된 애플리케이션들 간의 애플리케이션 관계를 삭제하기 위한 예시적인 방법을 도시한다.
도 11은 기존의 등록된 애플리케이션들 간의 애플리케이션 관계를 발견하기 위한 예시적인 방법을 도시한다.
도 12는 예시적인 부모/자식 애플리케이션 등록 프로세스를 도시한다.
도 13은 예시적인 부모/자식 애플리케이션 등록 프로세스를 도시한다.
도 14는 합성/입력 애플리케이션 등록을 위한 예시적인 방법을 도시한다.
도 15는 부모/자식 애플리케이션 등록 해제를 위한 예시적인 방법을 도시한다.
도 16은 합성/입력 애플리케이션 등록 해제를 위한 예시적인 방법을 도시한다.
도 17은 부모/자식 애플리케이션 발표를 위한 예시적인 방법을 도시한다.
도 18은 관계-인식 부모/자식 애플리케이션 소프트웨어 관리를 위한 예시적인 방법을 도시한다.
도 19는 관계-인식 합성/입력 애플리케이션 소프트웨어 관리를 위한 예시적인 방법을 도시한다.
도 20은 관계-인식 애플리케이션 발견을 위한 예시적인 방법을 도시한다.
도 21은 애플리케이션 관계의 가입 및 통지를 위한 예시적인 방법을 도시한다.
도 22는 CSF로서의 애플리케이션 관계 관리(ARM)를 도시한다.
도 23은 <appRelationRecord> 자원 구조를 도시한다.
도 24는 <application> 자원의 구조를 도시한다.
도 25는 <application> 자원의 구조를 도시한다.
도 26은 예시적인 그래픽 사용자 인터페이스를 도시한다.
도 27a는 하나 이상의 개시된 예가 구현될 수 있는 예시적인 머신-투-머신(M2M) 또는 사물 인터넷(IoT) 통신 시스템의 시스템 도면이다.
도 27b는 도 27a에 도시된 M2M/IoT 통신 시스템 내에서 사용될 수 있는 예시적인 아키텍처의 시스템 도면이다.
도 27c는 도 27a에 도시된 통신 시스템 내에서 사용될 수 있는 예시적인 M2M/IoT 단말기 또는 게이트웨이 디바이스의 시스템 도면이다.
도 27d는 도 27a의 통신 시스템의 양태들이 구체화될 수 있는 예시적인 컴퓨팅 시스템의 블록도이다.
종래의 oneM2M 아키텍처는 필수 기능성들을 포함하여 다양한 CSF를 정의하고 다른 CSE 또는 AE에 의해 구현되고 레버리지되어야 하는 방식에 중점을 둔다. 종래의 oneM2M 아키텍처는 또한 상이한 M2M 애플리케이션(예를 들어, AE) 간의 자원 액세스 및 메시지 교환을 지원한다. 이 아키텍처는 다수의 AE가 동일한 CSE에 등록할 수 있게 하지만, 각 AE는 CSE에 독립적으로 애플리케이션 등록을 행한다. 종래의 M2M/IoT 서비스 계층(예를 들어, oneM2M 기능적 아키텍처 베이스라인, oneM2M-TS-0001 - V-2014-08)은 상이한 애플리케이션 간의 관계를 효율적으로 지원하고 레버리지하는 기능이 부족하다. 본 명세서에는 M2M 또는 IoT 서비스 계층(이하, "M2M 서비스 계층")에서 애플리케이션 관계(예를 들어, 부모/자식)를 활용하는 방법이 개시되어 있다.
M2M 사용 사례에는 스마트 운송, 스마트 홈, 스마트 건강, 스마트 그리드, 스마트 도시 등이 포함될 수 있다. 각 사용 사례는 기반구조 도메인(예를 들어, M2M 애플리케이션 서버)과 필드 도메인(예를 들어, M2M 디바이스에서) 양측 모두에서 다수의 관련 애플리케이션을 생성할 수 있다. 이러한 M2M 애플리케이션은 상이한 수직 도메인으로부터의 애플리케이션에 대해서도 서로 완전히 독립적이지 않다. 아래에 설명된 체육관 사용 사례 및 환경 모니터링 사용 사례는 상이한 M2M 애플리케이션 간에 관계가 존재할 수 있음을 보여준다.
도 2는 부모/자식 관계가 있을 수 있는, 고객의 모바일 디바이스 상에 3개의 애플리케이션이 있는 체육 사용 사례를 도시한다. AE(134)는 모바일 디바이스(132)와 태블릿(137)(예를 들어, 코치) 간의 훈련 애플리케이션이다. AE(133)는 모바일 디바이스(132)와 러닝 머신(136) 간의 러닝 머신 애플리케이션이다. AE(135)는 모바일 디바이스(132)와 자전거(138) 간의 자전거 애플리케이션이다. AE(133), AE(134) 및 AE(135)는 그들 자신을 체육관 게이트웨이(131)(예를 들어, oneM2M CSE)에 등록한다. AE(134)는 태블릿(137)에서 훈련 요법(training regimen)에 액세스하는데 사용된다. 그런 다음, 고객은 AE(134)에 의해 제공되는 훈련 프로그램에서 지정된 장비(예를 들어, 러닝 머신(136) 및 자전거(138))와의 상호 작용을 위해 AE(133) 또는 AE(135)를 사용한다. 예를 들어, 고객은 AE(133)를 통해 러닝 머신(136)을 동적으로 속도를 줄이거나 높이기 위한 명령을 보낼 수 있다. 이 예에서, AE(134)는 AE(133) 및 AE(135)에 정보(예를 들어, 훈련 프로그램)를 제공하는 부모 애플리케이션으로 간주될 수 있다. AE(133) 및 AE(135)는 자식 애플리케이션으로 간주될 수 있으며 둘 다 훈련 결과를 AE(134)로 피드백으로서 제공할 수 있다. 또한, AE(134)는 AE(133) 또는 AE(135)의 작동을 제어하고 심지어 무효화(override)할 수 있는 액세스 권한을 가질 수 있다.
도 3은 합성/입력 관계의 예를 포함하는 환경 모니터링을 위한 사용 사례를 도시한다. 도 3에서, 몇몇 유형의 센서(예를 들어, 습도 센서(145), 연기 센서(142), 온도 센서(144) 및 바람 센서(143))가 물리적 영역(141)에 배치된다. 센서는 상이한 밀도로 상이한 위치에 배치될 수 있다. 각각의 센서는 자신을 센서 애플리케이션으로서 M2M 게이트웨이(149)에 등록한다. 센서는 M2M 게이트웨이(149)를 통해 인터넷으로부터 액세스될 수 있다.
계속해서 도 3을 참조하면, 하나의 배치에서, M2M 게이트웨이(149)는 상이한 목적을 위해 2개의 게이트웨이 애플리케이션(예를 들어, AE(147) 및 AE(148))을 설치할 수 있지만, 양측 모두는 센서 애플리케이션에 의존할 수 있다. 예를 들어, AE(147)는 날씨 예측을 위해 습도 센서(145)의 습도 센서 애플리케이션과 온도 센서(144)의 온도 센서 애플리케이션의 조합을 이용할 수 있다. AE(148)는 화재 예측을 위해 온도 센서(144)의 온도 센서 애플리케이션, 연기 센서(142)의 연기 센서 애플리케이션, 및 바람 센서(143)의 바람 센서 애플리케이션의 조합을 이용할 수 있다. 센서 애플리케이션은 게이트웨이 애플리케이션(합성 애플리케이션)이 출력을 생성을 위해 의존하는 입력이다. 개별 센서 애플리케이션은 인터넷으로부터의 다른 네트워크 애플리케이션에 의해 활용될 수 있다.
종래의 M2M 서비스 계층(예를 들어, oneM2M 기능적 아키텍처 베이스라인, oneM2M-TS-0001 - V-2014-08)은 상이한 애플리케이션 간의 관계를 효율적으로 지원하고 활용하는 기능이 부족하다. 종래의 oneM2M에서, M2M 애플리케이션(예를 들어, AE)은 Mca 인터페이스를 통해 독립적으로 서비스 플랫폼(예를 들어, CSE)에 간단하게 등록하고 Mca 또는 Mca/Mcc/Mca 인터페이스의 조합을 통해 다른 M2M 애플리케이션과 통신한다. oneM2M 아키텍처에서 애플리케이션 등록 또는 다른 애플리케이션 관련 절차(예를 들어, 애플리케이션 가입)에서는 M2M 애플리케이션 간의 종속성 또는 관계가 지원되지 않는다.
종래의 M2M 서비스 계층에서의 애플리케이션 관계 비인식에는 여러 단점이 있을 수 있다. 첫번째, 상속되거나 필요로 하는 애플리케이션 관계(예를 들어, 도 2의 체육관 사용 사례)를 갖는 사용 사례를 지원하기 위해, 종래의 M2M 서비스 계층은 대응하는 서비스를 제공하지 않고, 애플리케이션 레벨에서 그것을 처리하기 위해 애플리케이션 자체에 의존하는데, 이는 예를 들어, 애플리케이션 개발 복잡성이 증가하고 소프트웨어 재사용 가능성이 감소하는 애플리케이션의 부담을 증가시킬 수 있다. 두번째, 종래의 M2M 서비스 계층의 경우, 애플리케이션 관계의 동적 변경은 애플리케이션 자체적으로 효율적으로 지원되지 않을 수 있다.
본 명세서에 개시된 바와 같이, 상이한 애플리케이션들의 관계가 관리될 때 M2M 서비스 계층에서의 공통 서비스(예를 들어, oneM2M에서의 등록 서비스)가 강화될 수 있다(예를 들어, 메시지 오버헤드의 감소). 애플리케이션 관계 관리는 애플리케이션 관계를 생성하고, 애플리케이션 관계를 업데이트하고, 애플리케이션 관계를 검색하고, 애플리케이션 관계를 삭제하거나, 애플리케이션 관계를 발견하는 공통 서비스 계층 기능을 수반할 수 있다.
도 4a는 예시적인 부모/자식 관계를 도시한다. 자식 애플리케이션인 AE(152) 및 AE(153)는 부모 애플리케이션인 AE(151)의 일부이다. AE(151)는 AE(152) 및 AE(153)에 대한 실질적인 액세스 및 제어를 가질 수 있다. 자식 애플리케이션, AE(152) 및 AE(153)의 등록은 부모 애플리케이션, AE(151)의 성공적인 등록에 의존할 수 있다. AE(151)는 AE(152) 및 AE(153) 전에 등록 또는 활성화될 수 있다. 대안적으로, 부모/자식 관계는 AE(151), AE(152) 및 AE(153)이 독립적으로 등록된 후에 설정될 수 있다. 예를 들어, AE(152) 및 AE(153)는 부모 애플리케이션, AE(151)가 아직 등록되지 않았더라도 등록할 수 있지만, AE(152) 및 AE(153)의 소정 기능성(예를 들어, 액세스 권한)은 적용 가능하지 않거나 인에이블되지 않을 수 있다. 일단 AE(151)가 등록되면, AE(152) 및 AE(153)는 AE(151)를 발견하고 AE(152) 및 AE(153)와 관계를 설정할 수 있다. 따라서, 디스에이블된 기능성이 인에이블될 수 있다. 한편, 자식 애플리케이션, AE(152) 및 AE(153)는 부모 애플리케이션, AE(151)가 삭제되거나 등록 해제될 때 자동으로 제거될 수 있다. 부모 애플리케이션, AE(151)와 자식 애플리케이션, AE(152) 및 AE(153)은 양측 모두가 동일한 로컬 서비스 계층 인스턴스 생성에 등록할 수 있지만, 동일한 물리적 M2M 디바이스, 게이트웨이 또는 서버에 상주하거나 상주하지 않을 수 있다. 요약하자면, 부모 애플리케이션, AE(151)는 자식 애플리케이션, AE(152) 및 AE(153)을 실질적으로 제어할 수 있으며, AE(152) 및 AE(153)는 AE(151)에 의존하여이를 제공할 수 있다. 본 명세서에서는 부모 애플리케이션이 임의의 수의 자식 애플리케이션을 가질 수 있는 것으로 고려된다.
도 4b는 예시적인 합성/입력 관계를 도시한다. AE(156)는 AE(154) 및 AE(155) 상에 구축되며, 이들은 입력 애플리케이션으로 지칭된다. AE(156)는 입력 또는 자원에 대해 AE(154) 및 AE(155)에 의존하지만, 실질적으로 그들을 제어하지는 않는다. AE(156)는 합성 애플리케이션으로 지칭될 수 있다. 예를 들어, 합성 애플리케이션, AE(156)는 입력 애플리케이션, AE(154) 및 AE(155)의 자원에 액세스할 수 있지만, AE(156)의 제거 또는 등록 해제는 AE(154) 또는 AE(155)의 자동 삭제로 이어지지 않을 수 있다. 그러나, AE(154) 또는 AE(155)의 제거 또는 등록 해제는 합성 애플리케이션, AE(156)에 영향을 미친다. 일반적으로, 합성 애플리케이션은 다수의 입력 애플리케이션을 가질 수 있고, 합성 애플리케이션은 다른 합성 애플리케이션에 대한 입력 애플리케이션일 수 있다.
도 5a 및 도 5b는 애플리케이션 자원 및 대응 관계를 설명하고 링크시키기 위한 접근법을 도시한다. 도 5a는 링크를 위한 특별한 애플리케이션 관계 기록 자원을 갖는 접근법을 도시한다. 도 5a에 도시된 바와 같이, 각각의 애플리케이션 관계는 애플리케이션 관계 관리(ARM) 기능에 의해 애플리케이션 관계 기록으로서 생성되고 캡처될 수 있다. 본 명세서에서 보다 상세하게 개시된 바와 같이, ARM은 애플리케이션 관계 기록을 저장하기 위한 특별한 데이터베이스를 유지 관리한다. 그런 다음, 애플리케이션이 다른 애플리케이션과의 관계를 설명하는 대응하는 관계 기록에 링크하기 위해 새로운 속성(예를 들어, 링크)이 도입된다. 애플리케이션 관계 기록 데이터베이스는 ARM에 의해 서비스 계층에서 유지 관리된다. 데이터베이스는 상이한 애플리케이션에 의해 액세스되거나 레버리지될 수 있는 일반적 기능이다. ARM은 애플리케이션에 액세스하거나 애플리케이션과 공유할 수 있는 기록을 제어할 수 있다. 예를 들어, 애플리케이션은, 서비스 계층에 등록한 후 다른 애플리케이션에 대한 특정 애플리케이션 관계 기록을 데이터베이스에서 검색할 수 있다. 또 다른 예에서, 애플리케이션은 새로운 애플리케이션 관계 기록을 추가함으로써 데이터베이스를 업데이트하여 또 다른 애플리케이션과의 관계를 보여줄 수 있다.
도 5b는 특별한 애플리케이션 관계 기록 자원이 없는 접근법을 도시한다. 각 애플리케이션 관계는 대응하는 애플리케이션 자원에 첨부된 추가 정보 또는 속성으로서 생성된다. 예를 들어, oneM2M 아키텍처의 문맥에서 <application> 자원에 새로운 속성을 추가하여 애플리케이션 관계를 설명할 수 있다. 이러한 접근법에서, ARM은 도 5a의 접근법 1에서와 같이 임의의 관계 기록을 유지 관리할 필요가 없다.
계속해서 도 5b의 접근법을 참조하면, 선택적으로, 기존의 애플리케이션 자원(예를 들어, oneM2M에 있는 <application>)이 또 다른 애플리케이션 자원(예를 들어, oneM2M에 있는 또 다른 <application>)의 하위 자원으로서 추가되어 애플리케이션 자원의 계층 구조를 형성할 수 있는데, 이는 애플리케이션 관계를 암시하며 애플리케이션 관계를 명시적으로 나타내는데 새로운 속성이 필요하지 않을 수 있다. 애플리케이션이 부모 애플리케이션을 하위 자원(예들 들어, 자식 애플리케이션)으로 추가하는 것을 제한할 수 있다는 점에 유의하라. 이러한 제한을 달성하기 위해, 애플리케이션은 전체 계층 구조를 체크하여 추가될 새로운 하위 자원(예를 들어, 자식 애플리케이션)이 계층 구조 상에 나타나지 않도록 보장할 수 있다. 잠재적인 루프 관계를 피하기 위해 계층 구조의 깊이가 제한될 수 있다는 점에 유의하라.
애플리케이션 관계 기록과 관련하여, 서비스 계층(예를 들어, ARM 서비스)은 애플리케이션 관계 기록의 유지 관리를 담당할 수 있다. 애플리케이션 관계 기록은 선택적으로 애플리케이션 자원의 하위 자원 또는 속성으로 추가될 수 있다. 표 1에 나타낸 바와 같이, 각각의 애플리케이션 관계 기록은 다른 것들 중에서, 애플리케이션 관계 기록 식별자(ARRI) 필드, 애플리케이션 관계 유형 필드, 애플리케이션 목록 필드, 주요 애플리케이션 필드, 관계 수명 필드, 또는 허용 엔티티 목록 필드와 같은 필드들을 포함할 수 있다. ARRI는 각 애플리케이션 관계 기록의 식별자이다. 기록이 저장되고 액세스될 수 있는 위치를 나타내는 URI(universal resource identifier)일 수 있다. 애플리케이션 관계에 관련된 애플리케이션은 하나 이상의 ARRI를 속성으로 추가하여, 애플리케이션에 대한 모든 애플리케이션 관계를 ARRI에 기초하여 검색할 수 있다.
애플리케이션 관계 기록
식별자		 애플리케이션
관계 유형		 애플리케이션의 목록 주요 애플리케이션 관계 수명
<URI1> 부모/자식 AE(151), AE(152), AE(153) AE(151) 60분
<URI2> 합성/입력 AE(156), AE(154), AE(155) AE(156) 10일
표 1. 애플리케이션 관계 기록
표 1은 애플리케이션 관계 기록에 사용될 수 있는 상이한 필드를 나타낸다. 애플리케이션 관계 유형 필드는 애플리케이션 관계의 유형(예를 들어, 부모/자식 관계 또는 합성/입력 관계)를 표시한다. 이 파라미터는 다른 관계 유형을 포함하도록 확장될 수 있다. 애플리케이션 목록 필드에는 직접적으로 관계에 있는 모든 애플리케이션의 명칭, 레이블 또는 식별자가 포함된다. 식별자는 URI의 형식일 수 있다. 주요 애플리케이션 필드는 부모/자식 관계에 대한 부모 애플리케이션 또는 합성/입력 관계에 대한 합성 애플리케이션의 명칭, 레이블 또는 식별자를 표시한다. 관계 수명 필드는 애플리케이션 관계의 수명을 표시한다. 허용된 엔티티 목록 필드(표 1에는 명시적으로 나타나 있지 않음)는 애플리케이션 관계 기록에 액세스하도록 허용된 애플리케이션 또는 다른 M2M 엔티티(예를 들어, M2M/IoT 서버, 게이트웨이, 디바이스 등)의 목록이다. ARM 서비스는 전체 애플리케이션 관계 기록 데이터베이스에 대해 하나의 "허용된 엔티티 목록"을 사용할 수 있다.
표 1은 도 4a 및 도 4b에 따른 2개의 예시적인 애플리케이션 관계 기록을 나타낸다. 도 4a와 대응하는 표 1의 제1 기록은 <URI1>을 통해 액세스될 수 있다. 이 애플리케이션 관계에서, AE(151)는 부모 애플리케이션이고 AE(152) 및 AE(153)는 자식 애플리케이션이다. 도 4b에 대응하는 표 1의 제2 기록은 <URI2>을 통해 액세스될 수 있다. 이 애플리케이션 관계에서, AE(156)는 합성 애플리케이션이고 AE(154) 및 AE(155)는 입력 애플리케이션이다.
애플리케이션 관계 속성(ARA)은 애플리케이션이 다른 애플리케이션과 가질 수 있는 관계를 설명하기 위해 정의될 수 있다. ARA는 각각의 애플리케이션 자원(예를 들어, 도 24 및 도 25에 나타낸 바와 같이 oneM2M의 <application>)에 대한 속성으로 추가될 수 있고, 결국 각 속성은 액세스될 수 있는 어드레스(예를 들어, URI)를 가질 수 있다. 예를 들어, ARA는 parentApp, childApp, siblingApp, inputApp, compositeApp 또는 relationshipLifetime을 포함할 수 있다. parentApp은 부모 애플리케이션 명칭 또는 식별자의 목록일 수 있고, childApp은 자식 애플리케이션 명칭 또는 식별자의 목록일 수 있고, siblingApp은 형제 애플리케이션 명칭 또는 식별자의 목록일 수 있고, inputApp은 입력 애플리케이션 명칭 또는 식별자의 목록일 수 있고, compositeApp은 합성 애플리케이션 명칭 또는 식별자의 목록일 수 있고, relationshipLifetime은 수명 정보의 목록일 수 있으며, 여기서 각 수명은 개별 애플리케이션 관계에 대한 것이다.
M2M 애플리케이션이 서비스 계층(예를 들어, oneM2M CSE)에 등록되기 때문에, 서비스 계층은 애플리케이션 관계를 관리하는데 사용될 수 있다. 애플리케이션 관계 관리(ARM) 서비스는 기존 또는 새롭게 등록된 애플리케이션 간의 관계를 관리하기 위해 일반적인 작업 수행을 용이하게 할 수 있도록 M2M 서비스 계층에서 새로운 공통 서비스로 간주될 수 있다. 작업에는 새로운 애플리케이션 관계를 생성하는 것, 기존 애플리케이션 관계를 검색하는 것, 기존 애플리케이션 관계를 업데이트하는 것, 기존 애플리케이션 관계를 삭제하는 것, 및 기존 애플리케이션 관계를 발견하는 것이 포함될 수 있다. ARM 서비스가 애플리케이션 관계와 관련이 있다고 해도, 다양한 애플리케이션을 지원하고 사용할 수 있는 일반적인 기능을 제공할 수 있는데, 그 이유는 1) 본 명세서에 개시된 유형의 애플리케이션 관계가 충분히 일반적이고(상이한 애플리케이션에 특정적이지 않음), 2) 앞서 언급한 일반적인 ARM 작업이 특정 애플리케이션에 의존하지 않으며 또한 일반적이기 때문이다.
일반적인 작업에는 새로운 애플리케이션 관계를 생성하는 것이 포함된다. 예를 들어, M2M/IoT 서버(이하, M2M 서버)는 M2M 서버에 등록된 2개 이상의 애플리케이션에 대한 부모/자식 또는 합성/입력 관계를 생성하는데 도움이 될 수 있다. 따라서, M2M 서버에 의해 유지 관리되는 애플리케이션 관계 기록 데이터베이스에 새로운 애플리케이션 관계 기록이 도 5a의 접근법에 따라 추가되거나, 도 5b의 접근법에 따라 다른 관련 애플리케이션에 대해 새로운 속성/링크가 생성될 것이다. 이러한 프로세스는 기존 애플리케이션 관계의 검색, 업데이트, 삭제 및 발견에 사용될 수 있다.
본 명세서에서, 도 6 - 도 21 및 도처에 도시된 단계들을 수행하는 엔티티들은, 도 27c 또는 도 27d에 도시된 것과 같은 디바이스, 게이트웨이, 서버, 또는 컴퓨터 시스템의 메모리에 저장되고, 이들의 프로세서 상에서 실행되는 소프트웨어의 형태(즉, 컴퓨터 실행가능 명령어들)로 구현될 수 있는 논리적 엔티티들일 수 있다는 것으로 고려된다. 다시 말해서, 도 6 - 도 21 및 도처에 도시된 방법(들)은, 컴퓨팅 디바이스의 프로세서에 의해 실행될 때, 컴퓨터 실행가능 명령어들이 도 6 - 도 21 등에 도시된 임의의 단계들을 수행하는, 도 27c 또는 도 27d에 도시된 디바이스 또는 컴퓨터 시스템과 같은 컴퓨팅 디바이스의 메모리에 저장된 소프트웨어의 형태(즉, 컴퓨터 실행가능 명령어들)로 구현될 수 있다.
도 6은 기존의 등록된 애플리케이션의 세트 간의 애플리케이션 관계를 생성하기 위한 예시적인 방법을 도시한다. 단계 174에서, 요청자(171)(예를 들어, oneM2M AE 또는 oneM2M CSE)는 서비스 계층(172)(예를 들어, ARM 서비스를 갖는 oneM2M CSE)에 애플리케이션 관계를 생성(예를 들어, 애플리케이션 관계 요청을 생성)하라는 요청을 송신한다. 단계 174의 요청은 애플리케이션 관계 유형, 서비스 계층(172)에 등록된 애플리케이션들의 목록, 주요 애플리케이션, 또는 관계 수명에 관한 ARA를 포함할 수 있다. 단계 175에서, 단계 174에서 수신된 정보에 기초하여, 서비스 계층(172)은 대응하는 애플리케이션 관계 자원을 생성할 수 있다. 애플리케이션 관계 자원은 표 1에 도시된 애플리케이션 관계 기록일 수 있다. 대안적으로, 단계 174와 관련하여 열거된 것들과 같은 대응하는 ARA는 각각의 관련 애플리케이션에 추가될 수 있다. 단계 176에서, 서비스 계층(172)은 응답을 요청자(171)에게 되돌려 보낸다. 이 메시지는 생성된 애플리케이션 자원(예를 들어, 애플리케이션 관계 기록 또는 ARA)의 식별자(예를 들어, URI)를 포함할 수 있다. 단계 177에서, 서비스 계층(172)은 단계 174의 애플리케이션들의 목록 상의 다른 애플리케이션들에게 통지를 보낸다.
도 7은 부모/자식 애플리케이션 관계를 생성하기 위한 예시적인 방법을 도시한다. AE(151)는 부모 애플리케이션이고, AE(152) 및 AE(153)는 도 4a에 유사하게 도시된 바와 같이 자식 애플리케이션이다. 단계 184에서, AE(151)는 서비스 계층(172)(예를 들어, oneM2M CSE - ARM 서비스)에 등록한다. 단계 185에서, 서비스 계층(172)은 AE(151)에 대한 자원을 생성한다. 단계 186에서, AE(152)는 서비스 계층(172)에 등록한다. 단계 187에서, 서비스 계층(172)은 AE(152)에 대한 자원을 생성한다. 단계 188에서, AE(153)는 서비스 계층(172)에 등록한다. 단계 189에서, 서비스 계층(172)은 AE(153)에 대한 자원을 생성한다. oneM2M에 대한 통상적인 애플리케이션 등록 절차는 단계 184 내지 단계 189에 레버리지될 수 있다.
단계 190에서, 요청자(171)는 AE(151), AE(152) 및 AE(153)의 부모/자식 관계를 생성 또는 업데이트하기 위해 서비스 계층(172)에 애플리케이션 관계 요청 메시지를 전송한다. 요청자(171)는 AE(151), AE(152), AE(153), 또 다른 애플리케이션, 또는 또 다른 서비스 계층(172) 엔티티(예를 들어, 또 다른 CSE)일 수 있다. 동일한 서비스 계층 (172)은 또한 AE(151), AE(152) 및 AE(153) 간에 부모/자식 관계를 설정하도록 트리거할 수 있으며; 이 경우, 단계 190는 스킵될 수 있다. 애플리케이션 관계 생성 요청 메시지는 다음 정보: AE(151), AE(152) 및 AE(153) 사이의 관계; 단계 185, 단계 187 및 단계 189에서 각각 생성된 AE(151), AE(152) 및 AE(153)에 대한 자원에 대한 링크; AE(151), AE(152) 및 AE(153)의 명칭, 레이블 또는 식별자를 포함할 수 있다. 단계 191에서, 서비스 계층(172)은 AE(151), AE(152) 및 AE(153)에 대한 자원을 업데이트하여 AE(151), AE(152) 및 AE(153) 애플리케이션 간의 부모/자식 관계를 구축할 수 있다. AE(151)의 자원에는 AE(152) 및 AE(153)에 대한 자원에 연결되는 자식 포인터 또는 링크가 추가될 수 있다. AE(152)(또는 AE(153))의 자원에는 AE(151)에 대한 자원에 연결되는 부모 포인터 또는 링크가 추가될 수 있다. 자식 포인터 또는 링크는 AE(151)의 자원의 새로운 속성 또는 하위 자원이 될 것이고, 그 값은 AE(152) 및 AE(153)에 대한 자원의 URI이다. 마찬가지로, 추가된 부모 포인터 또는 링크는 AE(152)(또는 AE(153))의 자원의 새로운 속성 또는 하위 자원이 될 것이고, 그 값은 AE(151)에 대한 자원의 URI이다. AE(152)(또는 AE(153))의 자원에는 AE(153)(또는 AE(152))에 대한 자원에 연결되는 형제 포인터 또는 링크가 추가될 수 있다. 이 형제 포인터 또는 링크는 AE(152) 및 AE(153)가 애플리케이션 관계에 관련되고 동일한 부모 애플리케이션을 갖는다는 것을 표시하는데 사용될 수 있다. AE(152)의 자원에 새로운 속성 또는 하위 자원으로서 추가된 형제 포인터 또는 링크는 AE(153)의 자원의 URI의 값을 갖는다. AE(153)의 자원에 새로운 속성 또는 하위 자원으로서 추가된 형제 포인터 또는 링크는 AE(152)의 자원의 URI의 값을 갖는다.
단계 192에서, 서비스 계층(172)은 AE(151), AE(152) 및 AE(153) 간의 부모/자식 관계의 성공적인 생성을 통지하기 위해 요청자(171)에게 응답을 되돌려 보낼 수 있다. 단계 193에서, 서비스 계층(172)은 애플리케이션 관계 통지를 AE(151)에게 전송한다. 단계 193의 애플리케이션 관계 통지는 다음 정보: AE(151), AE(152) 및 AE(153) 간의 관계; 단계 187 및 단계 189에서 각각 생성된 AE(152) 및 AE(153)에 대한 자원에 대한 링크; 또는 AE(152) 및 AE(153)의 명칭, 레이블 또는 식별자를 가질 수 있다. 단계 194에서, 서비스 계층(172)은 애플리케이션 관계 통지를 AE(152)에게 전송할 수 있다. 단계 194의 애플리케이션 관계 통지는 다음 정보: AE(151), AE(152) 및 AE(153) 간의 관계; 단계 185 및 단계 189에서 각각 생성된 AE(151) 및 AE(153)에 대한 자원에 대한 링크; 또는 AE(151) 및 AE(153)의 명칭, 레이블 또는 식별자를 포함할 수 있다. 단계 195에서, 서비스 계층(172)은 애플리케이션 관계 통지를 AE(153)에게 전송할 수 있다. 메시지는 다음 정보: AE(151), AE(152) 및 AE(153) 간의 관계; 단계 185 및 단계 187에서 각각 생성된 AE(151) 및 AE(152)에 대한 자원에 대한 링크; 또는 AE(151) 및 AE(152)의 명칭, 레이블 또는 식별자를 포함할 수 있다.
도 7에 도시된 것과 유사한 절차는 AE(156), AE(154), 및 AE(155) 간의 합성/입력 애플리케이션 관계를 생성하기 위해 적용될 수 있으며, 여기서 AE(156)는 합성 애플리케이션이고 AE(154) 및 AE(155)는 입력 애플리케이션이다.
또 다른 일반적인 작업에는 기존 애플리케이션 관계를 검색하는 작업이 포함될 수 있다. 예를 들어, M2M 애플리케이션은 도 5a의 접근법 1에 따라 특정 애플리케이션 관계를 검색하기 위해 M2M 서버에서 유지 관리되는 애플리케이션 관계 기록 데이터베이스에 액세스할 수 있거나, 도 5b의 접근법 2에 따라 관련 애플리케이션을 위해 생성된 새로운 속성/링크에 액세스할 수 있다. 도 8은 기존의 등록된 애플리케이션 간의 애플리케이션 관계를 검색하기 위한 예시적인 방법을 도시한다. 단계 197에서, 요청자(171)(예를 들어, oneM2M AE, oneM2M CSE)는 서비스 계층(172)(예를 들어, ARM 서비스를 갖는 oneM2M CSE)에 하나 이상의 애플리케이션의 관계를 검색(예를 들어, 애플리케이션 관계 요청을 검색)하라는 요청을 송신할 수 있다. 애플리케이션 관계 검색 요청은 ARRI(예를 들어, 검색될 애플리케이션 관계 기록의 식별자)와 같은 애플리케이션 관계 자원의 어드레스를 포함할 수 있거나, 본 명세서에 정의된 ARA의 어드레스를 포함할 수 있다. 단계 198에서, 단계 197에서 수신된 정보에 기초하여, 서비스 계층(172)은 표 1에 나타낸 정보와 같은 대응하는 애플리케이션 관계 기록을 찾는다. 단계 199에서, 서비스 계층(172)은 요청자(171)에게 응답을 되돌려 보낼 수 있다. 단계 199의 응답은 원하는 애플리케이션 관계 기록 또는 ARA의 표현을 포함할 수 있다.
또 다른 일반적인 작업에는 기존 애플리케이션 관계를 업데이트하는 작업이 포함될 수 있다. 예를 들어, M2M 애플리케이션은 M2M 서버에서 유지 관리되는 애플리케이션 관계 기록 데이터베이스를 업데이트하여 도 5a의 접근법에 따라 기존 애플리케이션 관계를 업데이트(예를 들어, 자식 애플리케이션 또는 입력 애플리케이션을 변경)할 수 있거나, 도 5b의 접근법에 따라 관련 애플리케이션들을 위해 생성된 새로운 속성/링크를 업데이트할 수 있다. 도 9는 기존의 등록된 애플리케이션들 간의 애플리케이션 관계를 업데이트하기 위한 예시적인 방법을 도시한다. 단계 201에서, 요청자(171)는 애플리케이션 관계를 업데이트(예를 들어, 애플리케이션 관계 요청을 업데이트)하라는 요청을 서비스 계층(172)에게 송신할 수 있다. 애플리케이션 관계 업데이트 요청은 다음 정보: ARRI(예를 들어, 업데이트될 애플리케이션 관계 기록의 식별자), 애플리케이션들의 목록과 같은 원하는 애플리케이션 관계 기록에 대해 업데이트될 다른 속성, 또는 본 명세서에 논의된 ARA의 어드레스 또는 값을 포함할 수 있다. 단계 202에서, 단계 201에서 수신된 정보에 기초하여, 서비스 계층(172)은 단계 201에서 요청된 바와 같이 대응하는 애플리케이션 관계 기록 또는 ARA를 찾아서 업데이트할 수 있다. 단계 203에서, 서비스 계층(172)은 요청자(171)에게 응답을 되돌려 보낼 수 있다. 단계 203의 응답은 업데이트된 애플리케이션 관계 기록 또는 ARA의 표현을 포함할 수 있다. 단계 204에서, 서비스 계층(172)은 애플리케이션 관계 기록 또는 ARA의 변경에 관한 업데이트된 애플리케이션의 목록 상의 관련 애플리케이션들(205)에게 통지를 송신할 수 있다.
일반적인 작업에는 기존 애플리케이션 관계를 삭제하는 작업이 포함될 수 있다. 예를 들어, M2M 애플리케이션은 도 5a의 접근법에 따라 M2M 서버에서 유지 관리되는 애플리케이션 관계 기록 데이터베이스로부터 기존 애플리케이션 관계를 삭제할 수 있거나, 도 5b의 접근법에 따라 관련 애플리케이션을 위해 생성된 새로운 속성/링크를 삭제할 수 있다. 도 10은 기존의 등록된 애플리케이션들 간의 애플리케이션 관계를 삭제하기 위한 예시적인 방법을 도시한다. 단계 206에서, 요청자(171)는 애플리케이션 관계를 삭제(예를 들어, 애플리케이션 관계 요청을 삭제)하라는 요청을 서비스 계층(172)에게 송신한다. 이 삭제 애플리케이션 관계 요청은 ARRI(예를 들어, 삭제될 애플리케이션 관계 기록의 식별자) 또는 애플리케이션 관계 속성의 어드레스를 포함할 수 있다. 단계 206에서, 요청자(171)는 명시적으로 ARRI를 표시하지 않고, 삭제될 애플리케이션 관계 기록에 대한 소정의 기준을 제공하도록 선택할 수 있다. 예를 들어, 하나 이상의 특정 애플리케이션(예를 들어, AE(151))이 관련되는 애플리케이션 관계 기록를 삭제할 수 있다. 단계 207에서, 단계 206에서 수신된 정보에 기초하여, 서비스 계층(172)은 대응하는 애플리케이션 관계 기록 또는 ARA를 찾아서 삭제한다. 단계 208에서, 서비스 계층(172)은 응답을 요청자(171)에게 되돌려 보낸다. 단계 208의 이러한 응답은 삭제 결과(예를 들어, 성공 또는 실패)를 포함할 수 있다. 단계 209에서, 서비스 계층(172)은 애플리케이션들의 목록(예를 들어, 부모/자식 또는 합성/입력 애플리케이션) 상의 모든 관련 애플리케이션(예를 들어, 애플리케이션들(173))에게 통지를 송신할 수 있다.
일반적인 작업에는 기존 애플리케이션 관계를 발견하는 작업이 포함될 수 있다. 예를 들어, M2M 애플리케이션은 M2M 서버에서 유지 관리되는 애플리케이션 관계 기록 데이터베이스에 액세스하여 도 5a의 접근법에 따라 다른 애플리케이션과 갖는 애플리케이션 관계를 발견할 수 있거나, 도 5b의 접근법에 따라 관련 애플리케이션를 위해 생성된 새로운 속성/링크에 액세스하여 대응하는 애플리케이션 관계를 발견할 수 있다. 도 11은 기존의 등록된 애플리케이션들 간의 애플리케이션 관계를 발견하기 위한 예시적인 방법을 도시한다. 단계 211에서, 요청자(171)는 애플리케이션 관계를 발견(예를 들어, 애플리케이션 관계 요청을 발견)하라는 요청을 서비스 계층(172)에게 송신한다. 이 애플리케이션 관계 발견 요청은 특정 애플리케이션 명칭/식별자와 연관된 애플리케이션 관계 발견, 특정 애플리케이션의 세트 간의 애플리케이션 관계 발견, 특정 유형의 애플리케이션 관계 발견 또는 애플리케이션 관계 발견과 같은 특정 검색 기준을 포함할 수 있으며, 이는 특정 수의 애플리케이션이 관련되어 있다. 단계 212에서, 단계 211에서 수신된 정보에 기초하여, 서비스 계층(172)은 대응하는 애플리케이션 관계 기록 또는 애플리케이션 관계 속성을 찾는다. 단계 213에서, 서비스 계층(172)은 응답을 요청자(171)에게 되돌려 보낸다. 단계 213의 응답은 발견된 애플리케이션 관계 기록 또는 ARA(예를 들어, 그들의 식별자 또는 어드레스)의 목록을 포함할 수 있다.
이하, 향상된 애플리케이션 등록 서비스, 향상된 애플리케이션 발표 서비스, 향상된 애플리케이션 소프트웨어 관리 서비스, 관계 인식 애플리케이션 발견, 또는 애플리케이션 관계의 가입 및 통지와 같은 애플리케이션 관계(예를 들어, 부모/자식 관계 및 합성/입력 관계)를 사용할 수 있는 몇가지 새로운 부가 가치(향상된) 서비스가 논의된다. 향상된 애플리케이션 등록에는 부모/자식 애플리케이션, 합성/입력 애플리케이션, 및 기타 관계에 적용될 수 있는 향상된 등록 절차 및 등록 해제 절차가 포함될 수 있다. 향상된 등록 프로세스 동안, 애플리케이션 관계 기록 또는 ARA가 자동으로 생성될 수 있다. 향상된 등록 해제 프로세스 동안, 애플리케이션 관계 기록 또는 ARA가 자동으로 업데이트되거나 제거될 수 있다. 예를 들어, 부모 애플리케이션과 자식 애플리케이션은 체육관 사용 사례에서와 같이 동일한 M2M 디바이스, 게이트웨이, 또는 서버에 함께 배치될 수 있다. 등록을 수행하기 전에, 애플리케이션이 먼저 부트스트랩하고 자체와 서비스 계층 간의 개별 보안 연결을 설정할 수 있다. 이 부트스트랩 프로세스에서, 부모 애플리케이션은 그 자신의 보안 부트스트랩 프로세스 동안 자식 애플리케이션이 서비스 계층과의 보안 연결을 설정하는 것을 도울 수 있다.
도 12는 부모/자식 애플리케이션 등록 프로세스를 위한 예시적인 방법을 도시한다. AE(151)는 부모 애플리케이션이고, AE(152) 및 AE(153)는 자식 애플리케이션이다. 단계 215에서, AE(151)는 애플리케이션을 등록하라는 요청(예를 들어, 애플리케이션 등록 요청)을 서비스 계층(172)에게 송신한다. 이 애플리케이션 등록 요청은 AE(151), AE(152) 및 AE(153) 간의 관계; AE(151), AE(152) 또는 AE(153)의 설명; 또는 AE(151), AE(152) 또는 AE(153)의 명칭, 레이블 또는 식별자와 같은 정보를 포함할 수 있다. 단계 216에서, 서비스 계층(172)은 AE(151), AE(152) 또는 AE(153)에 대한 대응하는 자원을 생성한다. 단계 217에서, 서비스 계층(172)은 대응하는 애플리케이션 관계 기록 또는 ARA를 생성할 수 있다. 생성된 ARA는 각각의 생성된 애플리케이션 자원에 대한 속성을 생성하는데 사용될 수 있다. 예를 들어, AE(151)에 대한 생성된 자원은 AE(152) 및 AE(153)에 대한 자원에 연결되는 자식 포인터 또는 링크를 가질 수 있다. 또 다른 예에서, AE(151)(또는 AE(153))에 대한 생성된 자원은 AE(152)에 대한 자원에 연결되는 부모 포인터 또는 링크를 가질 수 있다. 또 다른 예에서, AE(152)(또는 AE(153))에 대한 생성된 자원은 AE(153)(또는 AE(152))에 대한 자원에 연결되는 형제 포인터 또는 링크를 가질 수 있다. 단계 218에서, 서비스 계층(172)은 AE(151), AE(152) 또는 AE(153)에 대해 생성된 자원들의 링크를 포함할 수 있는 응답을 AE(151)로 되돌려 보낸다.
도 13은 부모/자식 애플리케이션 등록을 위한 또 다른 예시적인 방법을 도시한다. AE(151)는 부모 애플리케이션일 수 있고, AE(152) 및 AE(153)는 자식 애플리케이션이다. 단계 220에서, AE(151)는 AE(151)만을 등록하기 위해 애플리케이션 등록 요청을 서비스 계층(172)에 송신할 수 있다. 단계 221에서, 서비스 계층(172)은 AE(151)에 대한 대응하는 자원을 생성할 수 있다. 단계 222에서, 서비스 계층(172)은 응답을 AE(151)로 되돌려 보낸다. 단계 22에서의 응답은 AE(151)에 대한 자원을 생성한 결과, 예를 들어, 성공 또는 실패는 물론이고 생성된 자원의 내용을 포함할 수 있다. 단계 223에서, AE(151)는 AE(151)를 등록하기 위해 또 다른 애플리케이션 등록 요청을 서비스 계층(172)에 송신할 수 있다. 단계 223의 애플리케이션 등록 요청은 단계 221에서 생성된 AE(151)에 대한 자원에 대한 링크, AE(151)와 AE(152) 간의 관계, AE(152)의 설명, AE(151) 및 AE(152)의 명칭, 레이블 또는 식별자와 같은 정보를 포함할 수 있다. 단계 224에서, 서비스 계층(172)은 AE(152)에 대한 대응하는 자원을 생성한다. 단계 225에서, 서비스 계층(172)은 대응하는 애플리케이션 관계 기록 또는 ARA를 생성한다. 생성된 ARA는 각각의 생성된 애플리케이션 자원에 대한 새로운 속성을 생성하는데 사용될 수 있다. AE(152)에 대한 생성된 자원은 AE(151)에 대한 자원에 연결되는 부모 포인터 또는 링크를 가질 수 있다. 서비스 계층(172)은 AE(152)에 대한 자원에 연결되는 자식 포인터 또는 링크를 추가하기 위해 AE(151)의 자원을 업데이트할 수 있다.
단계 226에서, 서비스 계층(172)은 AE(151)에 응답을 송신할 수 있다. 단계 226의 이러한 응답은 AE(152)에 대한 생성된 자원들의 링크를 포함할 수 있다. 단계 227에서, AE(151)는 AE(153)를 등록하기 위해 또 다른 애플리케이션 등록 요청을 서비스 계층(172)에 송신할 수 있다. 단계 227의 이 애플리케이션 등록 요청은 단계 221에서 생성된 AE(151)에 대한 자원에 대한 링크; AE(151)과 AE(153) 간의 관계; AE(153)의 설명; 또는 AE(151)과 AE(153)의 명칭, 레이블 또는 식별자와 같은 정보를 포함할 수 있다. 단계 228에서, 서비스 계층(172)은 AE(153)에 대한 대응하는 자원을 생성한다. 단계 229에서, 서비스 계층(172)은 단계 191에서 생성된 애플리케이션 관계 기록 또는 ARA를 업데이트한다. ARA는 각각의 생성된 애플리케이션 자원에 대한 속성에 사용될 수 있다. AE(153)에 대한 생성된 자원은 AE(151)에 대한 자원에 연결되는 부모 포인터 또는 링크를 가질 수 있다. 서비스 계층(172)은 AE(153)에 대한 자원에 연결되는 자식 포인터 또는 링크를 추가하기 위해 AE(151)에 대한 자원을 업데이트할 수 있다. 단계 230에서, 서비스 계층(172)은 응답을 AE(151)로 되돌려 보낼 수 있다. 단계 230의 응답은 AE(153)에 대한 생성된 자원들의 링크를 포함할 수 있다.
도 14는 합성 애플리케이션 등록을 위한 예시적인 방법을 도시한다. AE(156)는 합성 애플리케이션이고, AE(154) 및 AE(155)는 입력 애플리케이션이다. 또한, 이 등록 프로세스는 AE(155)에 대한 최초 등록이 아닐 수 있으며, 결국 AE(156)는 AE(154) 및 AE(155)에 대한 지식을 가질 수 있다. 단계 233 내지 단계 236에서, AE(154) 및 AE(155)는 그들 자신을 서비스 계층(172)에 독립적으로 등록한다. 단계 233에서, 서비스 계층(172)(예를 들어, ARM)은 AE(154)에 대한 등록 메시지를 교환할 수 있다. 단계 234에서, 서비스 계층(172)은 AE(154)에 대한 자원을 생성할 수 있다. 단계 235에서, 서비스 계층(172)은 AE(155)에 대한 등록 메시지를 교환할 수 있다. 단계 236에서, 서비스 계층(172)은 AE(155)에 대한 자원을 생성할 수 있다. 단계 237에서, AE(156)는 자신(AE(156))을 등록하고 그 사이에 AE(156)가 AE(154) 및 AE(155)를 2개의 입력 애플리케이션으로서 갖는 합성 애플리케이션인 것을 서비스 계층(172)에게 알리기 위해 서비스 계층(172)에게 애플리케이션 등록 요청을 송신할 수 있다. 단계 237의 애플리케이션 등록 요청은 AE(156), AE(154) 및 AE(155) 간의 관계, AE(156), AE(154) 및 AE(155)의 설명, AE(156), AE(154) 및 AE(155)의 명칭, 레이블 또는 식별자 같은 정보; 또는 단계 234 및 단계 236에서 각각 생성된 AE(154) 또는 AE(155)의 자원에 대한 링크를 포함할 수 있다. AE(156)가 이 정보를 획득하기 위한 한가지 방법은 발견 기능(예를 들어, oneM2M에서의 발견 CSF)을 사용하는 것이다.
단계 238에서, 서비스 계층(172)은 AE(151)에 대한 자원을 생성하고 AE(154) 및 AE(155)에 대한 자원을 업데이트할 수 있다. 단계 239에서, 서비스 계층(172)은 대응하는 애플리케이션 관계 기록 또는 ARA를 생성할 수 있다. 생성된 ARA는 AE(154) 및 AE(155)에 대한 자원에 연결되는 입력 포인터 또는 링크를 포함하는 AE(156)에 대한 자원; AE(156)에 대한 자원에 연결되는 합성 링크를 포함하는 AE(154)에 대한 자원; 또는 AE(156)에 대한 자원에 연결되는 합성 링크를 포함하는 AE(155)에 대한 자원과 같은, 각각의 생성된 애플리케이션 자원에 대한 속성을 가질 수 있다. 단계 240에서, 서비스 계층(172)은 AE(156)에 애플리케이션 등록 응답을 송신할 수 있다. 단계 241에서, 서비스 계층(172)은 애플리케이션 관계 통지를 AE(154)에게 송신할 수 있다. 이 애플리케이션 관계 통지는 AE(156)와 AE(154) 간의 관계, AE(156)에 대한 자원에 대한 링크, 또는 AE(156)의 명칭, 레이블 또는 식별자와 같은 정보를 포함할 수 있다. 단계 242에서, 서비스 계층(172)은 애플리케이션 관계 통지를 AE(155)에게 송신할 수 있다. 이 애플리케이션 관계 통지는 AE(156)와 AE(155) 간의 관계, AE(156)에 대한 자원에 대한 링크, AE(156)의 명칭, 레이블 또는 식별자와 같은 정보를 포함할 수 있다.
도 15는 부모/자식 애플리케이션 등록 해제를 위한 예시적인 절차를 나타낸다. AE(151)는 부모 애플리케이션이고, AE(152) 및 AE(153)는 자식 애플리케이션이다. 블록(243)은 자식 애플리케이션의 등록 해제를 포함하는 한편, 블록(251)은 부모 애플리케이션의 등록 해제를 포함한다. 단계 245에서, AE(151)는 자식 애플리케이션들 중 하나(예를 들어, AE(152))를 등록 해제하기 위해 애플리케이션 계층(예를 들어, 애플리케이션 등록 해제 요청)으로부터의 애플리케이션을 등록 해제하라는 요청을 서비스 계층(172)에 송신한다. 단계 245의 이러한 애플리케이션 등록 해제 요청은 등록 해제될 자식 애플리케이션의 명칭, 레이블 또는 식별자; 또는 등록 해제될 자식 애플리케이션의 자원에 대한 링크와 같은 정보를 포함할 수 있다. 단계 246에서, 서비스 계층(172)은 등록 해제될 자식 애플리케이션의 자원(예를 들어, AE(152)의 자원)을 제거한다. 서비스 계층(172)은 AE(152)에 연결되는 자식 포인터 또는 링크를 AE(151)의 자원으로부터 제거할 수도 있다. 서비스 계층(172)은 AE(152)에 연결되는 형제 포인터 또는 링크를 AE(153)의 자원으로부터 제거할 수도 있다. 또한, 서비스 계층(172)은 대응하는 애플리케이션 관계 기록을 업데이트할 수도 있다. 단계 247에서, 서비스 계층(172)은 응답을 AE(151)로 되돌려 보낼 수 있다.
도 15의 블록(251)에서 부모 애플리케이션을 등록 해제하는 것과 관련하여, 단계 252에서, AE(151)는 자신(AE(151))을 등록 해제하기 위해 애플리케이션 등록 해제 요청을 서비스 계층(172)에 전송한다. 단계 253에서, AE(153)는 AE(151)의 자식 애플리케이션이기 때문에, 서비스 계층(172)은 AE(151) 및 AE(153)에 대한 자원을 제거할 수 있다. 서비스 계층(172)은 또한 대응하는 애플리케이션 관계 기록을 제거할 수 있다. 단계 254에서, 서비스 계층(172)은 AE(151)에 응답을 송신할 수 있다. 블록(243) 또는 블록(251)에 도시된 단계들의 대안으로서, 자식 애플리케이션은 자신을 등록 해제한 다음 그 부모 애플리케이션에게 통지할 수 있다.
도 16은 합성 애플리케이션 등록 해제를 위한 예시적인 방법을 도시한다. 여기서, AE(156)는 합성 애플리케이션이고, AE(154) 및 AE(155)는 입력 애플리케이션이다. 블록(261)은 입력 애플리케이션의 등록 해제를 포함하는 한편, 블록(266)은 합성 애플리케이션의 등록 해제를 포함한다. 단계 262에서, AE(155)는 자신을 등록 해제하기 위해 애플리케이션 등록 해제 요청을 서비스 계층(172)에 전송할 수 있다. 이러한 애플리케이션 등록 해제 요청은 등록 해제될 입력 애플리케이션의 명칭, 레이블 또는 식별자; 또는 등록 해제될 입력 애플리케이션의 자원에 대한 링크와 같은 정보를 포함할 수 있다. 단계 263에서, 서비스 계층(172)은 등록 해제될 입력 애플리케이션의 자원(예를 들어, AE(155)의 자원)을 제거할 수 있다. 서비스 계층(172)은 AE(155)에 연결되는 입력 포인터 또는 링크를 AE(156)의 자원으로부터 제거할 수도 있다. 서비스 계층(172)은 또한 대응하는 애플리케이션 관계 기록을 업데이트할 수 있다. 단계 264에서, 서비스 계층(172)은 응답을 AE(155)로 되돌려 보낼 수 있다. 단계 265에서, 서비스 계층(172)은 애플리케이션 관계 통지를 AE(156)에게 전송할 수 있다. 이 애플리케이션 관계 통지는 등록 해제된 입력 애플리케이션(예를 들어, AE(155))의 명칭, 레이블 또는 식별자; 또는 등록 해제된 입력 애플리케이션(예를 들어, AE(155)의 자원)의 자원에 대한 링크와 같은 정보를 포함할 수 있다.
도 16의 블록(266)과 관련하여, 단계 267에서, AE(156)는 자신(AE(156))을 등록 해제하기 위해 애플리케이션을 등록 해제하기 위한 요청(예를 들어, 애플리케이션 등록 해제 요청)을 서비스 계층(172)에 전송할 수 있다. 단계 268에서, 서비스 계층(172)은 AE(156)의 자원을 제거할 수 있다. 서비스 계층(172)은 AE(156)에 연결되는 합성 포인터 또는 링크를 AE(154)의 자원으로부터 제거할 수도 있다. 또한, 서비스 계층(172)은 대응하는 애플리케이션 관계 기록을 제거할 수 있다. 단계 269에서, 서비스 계층(172)은 AE(156)에 응답을 송신할 수 있다. 단계 270에서, 서비스 계층(172)은 애플리케이션 관계 통지를 AE(154)에 송신할 수 있다. 이 애플리케이션 관계 통지는 등록 해제된 합성 애플리케이션(예를 들어, AE(156))의 명칭, 레이블 또는 식별자; 또는 등록 해제된 합성 애플리케이션(예를 들어, AE(156)의 자원)의 자원에 대한 링크와 같은 정보를 포함할 수 있다. 도 16과 관련한 또 다른 예에서, 서비스 계층(172)은 단계 264 이후에(예를 들어, 입력 애플리케이션이 등록 해제된 이후에 또는 소정 개수의 입력 애플리케이션이 등록 해제된 이후에) 합성 애플리케이션 AE(156)를 자동으로 등록 해제할 수 있다.
향상된 애플리케이션 발표는 부모/자식 애플리케이션 또는 합성/입력 애플리케이션을 발표하기 위한 절차를 참조할 수 있다. 도 17은 부모/자식 애플리케이션 발표를 위한 예시적인 절차를 도시한다. 여기서, 애플리케이션 블록(272)은 부모/자식 관계(예를 들어, 도 4a), 합성/입력 관계(예를 들어, 도 4b) 등을 갖는 애플리케이션을 나타내는 것으로 가정된다. 단계 274에서, 애플리케이션 블록(272)의 애플리케이션은 서비스 계층(172)에 자신을 등록할 수 있으며, 이는 본 명세서에서 논의된 절차로 완료될 수 있다. 단계 275에서, 서비스 계층(172)은 애플리케이션 발표 요청을 서비스 계층(273)에 전송할 수 있다. 단계 275의 이러한 애플리케이션 발표 요청은 애플리케이션 블록(272)의 애플리케이션의 관계, 애플리케이션 블록(272)의 애플리케이션의 명칭, 레이블 또는 식별자, 또는 애플리케이션 블록(272)의 애플리케이션의 자원에 대한 링크와 같은 정보를 포함할 수 있다. 단계 276에서, 서비스 계층(273)은 블록(272)의 애플리케이션들에 대한 발표된 자원을 생성할 수 있다. 생성된 발표된 자원은 블록(272)의 애플리케이션들의 관계가 내장된 하나의 계층 자원일 수 있다. 또 다른 예에서, 생성된 발표된 자원은 블록(272)의 애플리케이션들에 대한 각각의 애플리케이션에 대해 개별적이지만 교차 참조된 자원일 수 있다. 단계 277에서, 서비스 계층(273)은 응답을 서비스 계층(172)에 전송한다.
서비스 계층은 OMA(open mobile alliance) SCOMO(Software Component Management Objects)와 같은 디바이스 관리(DM) 기술에 기초하여 애플리케이션 소프트웨어(예를 들어, 업그레이드)를 관리할 수 있다. 다음은 애플리케이션 관계를 레버리지하여 애플리케이션 소프트웨어 관리를 향상시킬 수 있다. 도 18은 부모/자식 애플리케이션과 같은, 관계 인식의 소프트웨어 관리를 위한 예시적인 방법을 도시한다. 단계 284에서, 서비스 계층(172)은 M2M 디바이스(281) 상에 위치된 자식 애플리케이션(283)에 대한 소프트웨어를 검색한다. 소프트웨어는 서비스 계층(172)과 동일한 장치 상에 또는 도시되지 않은 또 다른 장치(예를 들어, 서버) 상에 위치될 수 있다. 여기서, 자식 애플리케이션(283)은 서비스 계층(172)의 도움으로 소프트웨어를 다운로딩한다. 단계 285에서, 서비스 계층(172)은 애플리케이션 관계 기록 또는 ARA를 분석하여 대응하는 부모 애플리케이션(예를 들어, 부모 애플리케이션(282))을 발견할 수 있다. 단계 286에서, 서비스 계층(172)이 자식 애플리케이션에 대한 소프트웨어의 검색을 도와준 후에(소프트웨어가 자식 애플리케이션(283)에 아직 설치되어 있지 않음), 서비스 계층(172)은 M2M 디바이스(281)의 부모 애플리케이션(282)에게 통지를 전송할 수 있다. 통지에는 다음 정보: 1) 새로운 소프트웨어가 다운로딩된 자식 애플리케이션의 명칭, 레이블 또는 식별자; 또는 2) 새로운 소프트웨어 버전이 포함될 수 있다. 단계 287에서, 부모 애플리케이션(282)은 자식 애플리케이션(283)을 트리거하여 새로운 소프트웨어를 설치할 수 있다. 단계 287의 이러한 트리거에는 설치될 소프트웨어 버전이 포함될 수 있다. 이 예에서, 부모 애플리케이션(282)은 다운로딩된 소프트웨어의 자식 애플리케이션(283)으로의 설치를 허용하는 허가를 결정할 수 있다. 허가하기 위한 결정은 다운로딩된 소프트웨어가 설치될 경우 부정적인 영향이나 기타 문제점이 있을 수 있는지를 결정하는데 기초할 수 있다. 설치의 효과는 부모 애플리케이션(282), 자식 애플리케이션(283), 또는 부모 애플리케이션(282)의 다른 연관된 자식 애플리케이션(도시 생략)에 직접적일 수 있다. 단계 288에서, 자식 애플리케이션(283)은 대응하는 애플리케이션을 설치할 수 있다. 단계 289에서, 부모 애플리케이션(282)은 확인 메시지를 서비스 계층(172)에 전송할 수 있다. 단계 289에서의 메시지는 자식 애플리케이션(283)의 최신 소프트웨어 버전의 표시 또는 단계 284의 소프트웨어가 설치되었다는 표시를 포함할 수 있다.
도 19는 관계-인식 합성/입력 애플리케이션 소프트웨어 관리를 위한 예시적인 방법을 도시한다. 단계 293에서, 서비스 계층(172)은 입력 애플리케이션(292)의 소프트웨어를 업데이트할 수 있다. 단계 294에서, 서비스 계층(172)은 애플리케이션 관계 기록 또는 ARA를 분석하여 대응하는 합성 애플리케이션을 발견할 수 있다. 단계 295에서, 서비스 계층(172)은 새로운 소프트웨어로 업데이트된 입력 애플리케이션(292)의 명칭, 레이블 또는 식별자; 또는 새로운 소프트웨어 버전을 통지하기 위해 합성 애플리케이션(291)에게 통지를 전송할 수 있다. 합성 애플리케이션(291)은 새로운 버전의 통지 및 단계 295에서 수신된 임의의 다른 세부 사항에 기초하여 입력을 수신하는 방법을 변경하거나 다른 동작을 조정할 수 있다. 변경에는 합성 애플리케이션(291)의 소프트웨어 업데이트가 포함될 수 있다. 단계 296에서, 합성 애플리케이션(291)은 통지에 확인응답하는 확인 메시지를 서비스 계층(172)에 전송할 수 있고 합성 애플리케이션(291)에 관한 다른 세부 사항을 포함시킬 수 있다. 세부 사항은 입력 애플리케이션(292)과의 관계를 끝내기 위한 통지를 포함할 수 있는데, 이것은 소프트웨어의 비호환성으로 인한 것일 수 있다.
도 20은 관계 인식의 맥락에서 애플리케이션 발견을 위한 예시적인 절차를 도시한다. 단계 301에서, 요청자(171)는 애플리케이션을 발견(예를 들어, 애플리케이션 요청을 발견)하라는 요청을 서비스 계층(172)에게 송신할 수 있다. 단계 301의 애플리케이션 발견 요청은 특정 애플리케이션의 부모 애플리케이션을 발견하는 것; 특정 애플리케이션의 자식 애플리케이션을 발견하는 것; 특정 애플리케이션의 입력 애플리케이션을 발견하는 것; 특정 애플리케이션의 합성 애플리케이션을 발견하는 것; 특정 애플리케이션 관계 내에서 애플리케이션을 발견하는 것; 또는 한 세트의 애플리케이션 관계 내에서 공통 애플리케이션을 발견하는 것과 같은 검색 기준을 포함할 수 있다. 단계 302에서, 단계 301에서 수신된 정보에 기초하여, 서비스 계층(172)은 대응하는 애플리케이션을 찾는다. 단계 303에서, 서비스 계층(172)은 응답을 요청자(171)에게 송신한다. 단계 303의 응답은 발견된 애플리케이션의 목록(예를 들어, 그들의 식별자 또는 명칭)을 포함할 수 있다.
도 21은 애플리케이션 관계에 대한 가입 및 통지 절차를 도시하며, 이를 통해 애플리케이션은 다른 애플리케이션과의 새로운 관계 또는 다른 애플리케이션과의 기존 관계에 대한 임의의 변경에 관한 자동 통지를 수신할 수 있다. 단계 305에서, 요청자(171)는 애플리케이션 관계를 가입(예를 들어, 애플리케이션 관계 요청을 가입)하라는 요청을 서비스 계층(172)에게 송신할 수 있다. 단계 305의 요청은 발견된 타겟 애플리케이션의 목록(예를 들어, 그들의 식별자 또는 명칭)을 포함할 수 있다. 단계 306에서, 서비스 계층(172)은 가입 요청이 승인되었는지의 여부를 표시하기 위해 요청자(307)에게 가입 애플리케이션 관계 응답 메시지를 송신할 수 있다. 단계 307에서, 소정량의 시간 이후에, 타겟 애플리케이션에 관한 또는 이와 관련된 관계가 변경된다. 예를 들어, 단계 305의 목록에서 타겟 애플리케이션들 중 하나와 새로운 관계가 생성될 수 있다. 단계 308에서, 서비스 계층(172)은 애플리케이션 관계 통지를 요청자(171)에게 전송할 수 있다. 단계 308의 통지는 단계 307와 관련하여 발생할 수 있는 관계 변화를 포함할 수 있다.
이하, oneM2M 아키텍처에서 본 명세서에서 논의된 방법을 적용하거나 구현하는 것에 관한 추가 세부 사항이 개시된다. 본 방법은 oneM2M CSF(예를 들어, 도 22에서의 애플리케이션 관계 관리(Application Relationship Management: ARM) CSF)로서 구현될 수 있다. 도 22에서는 구조에 대해 하기에서 보다 상세히 설명된다. 전술한 절차들에서 "서비스 계층" 행위자(예를 들어, 서비스 계층(172))는 ARM CSF로 대체될 수 있다. 바꾸어 말하자면, ARM CSF는 서비스 계층과 관련하여 본 명세서에서 설명된 기능성을 수행한다. 앞서 언급된 절차들에서 "요청자"(예를 들어, 요청자(171))는 oneM2M AE, ARM CSF, 또는 oneM2M CSE일 수 있다. 본 명세서에서 개시된 방법은 기존의 oneM2M 참조점(예를 들어, Mca 및 Mcc)에 영향을 미칠 수 있다. 바꾸어 말하자면, 메시지 교환은 oneM2M 참조 포인트의 일부로서 구현될 수 있다. 예를 들어, 애플리케이션과 서비스 계층(예를 들어, CSE) 간의 메시지는 이동될 수 있으며 이와는 달리 Mca 참조점을 포함할 수 있다. 또 다른 예에서, 서비스 계층들(CSE들) 간의 메시지는 Mcc 참조점을 포함할 수 있다.
본 명세서에서 논의된 강화된 애플리케이션 등록 서비스는 기능성을 향상시키기 위해 REG CSF에서 구현될 수 있다. 본 명세서에서 논의된 소프트웨어 관리 방법은 예를 들어, DM CSF 또는 ASM CSF에서 구현될 수 있다.
도 23 및 도 24는 강화된 자원 또는 새로운 자원의 예시적인 자원 트리를 나타낸다. 애플리케이션 관계 기록(예를 들어, <appRelationRecord>(321))은 제안된 애플리케이션 관계 관리를 가능하게 할 수 있다. <appRelationRecord>(321)은 <application>(331)이 포함하는 애플리케이션 관계를 기록하기 위해 <application>(331) 자원의 하위 자원으로서 추가될 수 있다. 도 23에 도시된 바와 같이, <appRelationRecord>(321)은 설명(322), 수명(323), 유형(324), lifeOfApp(325) 및 primaryApp(326)과 같은 속성들을 가질 수 있다. 설명(322)은 <appRelationRecord>(321)의 텍스트 설명의 표시이다. 수명(323)은 <appRelationRecord>(321)의 수명의 표시일 수 있다. 유형(324)은 <appRelationRecord>(321)의 애플리케이션 관계 유형(예를 들어, 부모/자식 애플리케이션 또는 합성/입력 애플리케이션)의 표시일 수 있다. listOfApp(325)는 <appRelationRecord>에 포함된 애플리케이션들의 목록의 표시일 수 있다. 이 속성의 값은 목록에 있는 애플리케이션의 명칭, 레이블 또는 식별자일 수 있다. primaryApp(326)은 <appRelationRecord>(321)의 주요 애플리케이션(예를 들어, 부모 애플리케이션 또는 합성 애플리케이션)의 표시이다.
도 24는 새로운 <application>(331) 자원의 예시적인 구조를 도시한다. <application>(331)은 개시된 애플리케이션 관리(예를 들어, 애플리케이션 등록, 애플리케이션 업데이트, 애플리케이션 등록 해제, 애플리케이션 발표 및 애플리케이션 소프트웨어 관리)를 지원하기 위한 하위 자원 또는 속성을 포함할 수 있다. <application>(331)은 속성들, arri(333), parentApp(334), childApp(335), siblingApp(336), compositeApp(337) 및 inputApp(338)을 가질 수 있다. arri(333)는 <application>(331)이 포함할 수 있는 ARRI의 표시일 수 있다. 각각의 arri(333)는 <appRelationRecord>(321) 자원을 가리킨다. parentApp(334)는 <application>(331) 자원이 있다면, 이 자원의 부모 애플리케이션의 표시일 수 있다. childApp(335)는 <application>(331) 자원이 있다면, 이 자원의 자식 애플리케이션의 표시일 수 있다. siblingApp(336)은 <application>(331) 자원이 있다면, 이 자원의 형제 애플리케이션의 표시일 수 있다. compositeApp(337)은 <application>(331) 자원이 있다면, 이 자원의 합성 애플리케이션의 표시일 수 있다. inputApp(338)은 <application>(331) 자원이 있다면, 이 자원의 입력 애플리케이션의 표시일 수 있다.
도 25는 개시된 계층 <application> 구조의 또 다른 예시적인 구조를 도시한다. <application>(342)는 애플리케이션을 의미한다. 수명(343)은 <application>(341)과 <sub-application>(345) 간의 애플리케이션 관계 유형의 수명 표시일 수 있다. 유형(344)은 <application>(341)(제1 애플리케이션)과 <sub-application>(344) 간의 애플리케이션 관계 유형의 표시일 수 있다. <sub-application>(345)는 <application>(341)의 자식 애플리케이션(유형 = "부모/자식 관계"인 경우) 또는 입력 애플리케이션(유형 = "합성/입력 관계"인 경우)을 표시한다. <application>(341)은 하위 자원으로서 다수의 <sub-application>을 가질 수 있다.
계속해서 도 25를 참조하면, <sub-application> 자원은 그 하위 자원으로서 또 다른 <sub-application> 자원(예를 들어, <sub-application>(346))을 가질 수 있다. 이 경우, <sub-application>은 위에서 설명한 "유형" 속성을 가질 수 있다. <sub-application>의 값은 실제 <sub-application> 자원에 링크하는 포인터 또는 URI일 수 있다. <sub-application>은 arri, parentApp, childApp, siblingApp, compositeApp 및inputApp을 포함하는, 도 24에 도시된 <application>(331)과 동일한 구조를 가질 수 있다. CoAP를 갖는 oneM2M 아키텍처가 본 명세서에서 배경 기술에 의해 기술되고 이하 기술되는 다양한 예를 예시하기 위해 사용될 수 있지만, 이하에 설명되는 예들의 구현들이 본 개시내용의 범위 내에서 변경될 수 있다는 것이 이해된다. 본 기술분야의 통상의 기술자라면, 개시된 예들이 위에서 논의된 oneM2M 아키텍처를 이용하는 구현들로 제한되지는 않으며, 오히려 ETSI M2M, MQTT 및 다른 M2M 시스템들 및 아키텍처들과 같은 다른 아키텍처들 및 시스템들에서 구현될 수 있다는 점을 또한 인식할 것이다.
도 26은 본 명세서에서 논의된 방법들 및 시스템들에 기초하여 생성될 수 있는 예시적인 디스플레이(예를 들어, 그래픽 사용자 인터페이스)를 도시한다. 디스플레이 인터페이스(350)(예를 들어, 터치 스크린 디스플레이)는 표 1의 파라미터와 같은 애플리케이션 관계와 관련된 블록(352)의 텍스트, 합성 애플리케이션 또는 부모 애플리케이션의 목록 등을 제공할 수 있다. 디바이스가 제약된 디바이스인지에 대한 추가 정보(도시 생략)이거나 또는 디바이스가 제약된 디바이스인지에 기초한 단순화된 인터페이스일 수 있다. 다른 예에서, 본 명세서에서 논의된 단계들 중 임의의 것의 진행(예를 들어, 송신된 메시지들 또는 단계들의 성공)이 블록(352)에서 디스플레이될 수 있다. 추가로, 그래픽 출력(354)이 디스플레이 인터페이스(350) 상에 디스플레이될 수 있다. 그래픽 출력(354)은 애플리케이션 관계들, 본 명세서에서 논의된 임의의 방법 또는 시스템들의 진행의 그래픽 출력 등과 관련하여 디바이스들 또는 애플리케이션들의 토폴로지일 수 있다.
도 27a는 하나 이상의 개시된 예가 구현될 수 있는 예시적인 머신-투-머신(M2M), 사물 인터넷(IoT) 또는 사물 웹(WoT)(Web of Things) 통신 시스템(10)의 도면이다. 일반적으로, M2M 기술들은 IoT/WoT를 위한 빌딩 블록을 제공하며, 임의의 M2M 디바이스, 게이트웨이 또는 서비스 플랫폼은 IoT/WoT의 컴포넌트는 물론이고 IoT/WoT 서비스 계층, 등일 수 있다.
도 27a에 도시된 바와 같이, M2M/IoT/WoT 통신 시스템(10)은 통신 네트워크(12)를 포함한다. 통신 네트워크(12)는 고정 네트워크(예를 들어, Ethernet, Fiber, ISDN, PLC 등) 또는 무선 네트워크(예를 들어, WLAN, 셀룰러 등) 또는 이종 네트워크들의 네트워크일 수 있다. 예를 들어, 통신 네트워크(12)는 음성, 데이터, 비디오, 메시징, 브로드캐스트, 또는 이와 유사한 것과 같은 콘텐츠를 복수의 사용자에게 제공하는 다중 액세스 네트워크로 구성될 수 있다. 예를 들어, 통신 네트워크(12)는 CDMA(code division multiple access), TDMA(time division multiple access), FDMA(frequency division multiple access), OFDMA(orthogonal FDMA), SC-FDMA(single-carrier FDMA) 등과 같은 하나 이상의 채널 액세스 방법들을 이용할 수 있다. 또한, 통신 네트워크(12)는 예를 들어 코어 네트워크, 인터넷, 센서 네트워크, 산업 제어 네트워크, 개인 영역 네트워크, 융합 개인 네트워크(fused personal network), 위성 네트워크, 홈 네트워크, 또는 기업 네트워크와 같은 다른 네트워크들을 포함할 수 있다.
도 27a에 도시된 바와 같이, M2M/IoT/WoT 통신 시스템(10)은 기반구조 도메인 및 필드 도메인을 포함할 수 있다. 기반구조 도메인은 엔드-투-엔드 M2M 배치(end-to-end M2M deployment)의 네트워크측을 지칭하고, 필드 도메인은 보통 M2M 게이트웨이 후방에 있는 영역 네트워크들(area networks)을 지칭한다. 필드 도메인은 M2M 게이트웨이들(14) 및 단말 디바이스들(18)을 포함한다. 임의의 수의 M2M 게이트웨이 디바이스들(14)과 M2M 단말 디바이스들(18)이 원하는 바에 따라 M2M/IoT/WoT 통신 시스템(10)에 포함될 수 있다는 점이 이해될 것이다. M2M 게이트웨이 디바이스들(14) 및 M2M 단말기 디바이스들(18) 각각은 통신 네트워크(12) 또는 직접 무선 링크를 통해 신호를 전송 및 수신하도록 구성된다. M2M 게이트웨이 디바이스(14)는 고정 네트워크 M2M 디바이스들(예를 들어, PLC)뿐만 아니라 무선 M2M 디바이스들(예를 들어, 셀룰러 및 비-셀룰러)이 직접 무선 링크 또는 통신 네트워크(12)와 같은 운영자 네트워크들을 통해 통신하는 것을 허용한다. 예를 들어, M2M 디바이스들(18)은 통신 네트워크(12) 또는 직접 무선 링크를 통해 데이터를 수집할 수 있고 M2M 애플리케이션(20) 또는 M2M 디바이스들(18)에 전송할 수 있다. M2M 디바이스들(18)은 또한 M2M 애플리케이션(20) 또는 M2M 디바이스(18)로부터 데이터를 수신할 수 있다. 또한, 데이터 및 신호들은 아래 설명되는 것처럼 M2M 서비스 계층(22)을 통해 M2M 애플리케이션(20)에 송신될 수 있고 그로부터 수신될 수 있다. M2M 디바이스들(18) 및 게이트웨이들(14)은, 예를 들어, 셀룰러, WLAN, WPAN(예를 들어, Zigbee, 6LoWPAN, Bluetooth), 직접 무선 링크, 및 유선을 포함하는 다양한 네트워크들을 통해 통신할 수 있다.
도 27b를 참조하면, 필드 도메인에서 도시된 M2M 서비스 계층(22)(예를 들어, 본 명세서에서 설명된 도 1의 CSE(109))은 M2M 애플리케이션(20), M2M 게이트웨이 디바이스(14) 및 M2M 단말 디바이스들(18) 및 통신 네트워크(12)에 서비스를 제공한다. M2M 서비스 계층(22)은 원하는 대로 임의의 개수의 M2M 애플리케이션들, M2M 게이트웨이 디바이스들(14), M2M 단말 디바이스들(18) 및 통신 네트워크들(12)과 통신할 수 있다는 점이 이해될 것이다. M2M 서비스 계층(22)은 하나 이상의 서버, 컴퓨터, 또는 다른 유사한 것에 의해 구현될 수 있다. M2M 서비스 계층(22)은 M2M 단말기 디바이스(18), M2M 게이트웨이 디바이스(14) 및 M2M 애플리케이션(20)에 적용되는 서비스 능력들을 제공한다. M2M 서비스 계층(22)의 기능들은 다양한 방식들로, 예를 들어, 웹 서버로서, 셀룰러 코어 네트워크에서, 클라우드에서 등으로 구현될 수 있다.
도시되는 M2M 서비스 계층(22)과 유사하게, 기반구조 도메인에는 M2M 서비스 계층(22')이 있다. M2M 서비스 계층(22')은 기반구조 도메인 내의 M2M 애플리케이션(20') 및 하부 통신 네트워크(12')에 서비스를 제공한다. M2M 서비스 계층(22')은 또한, 필드 도메인의 M2M 게이트웨이 디바이스(14)와 M2M 단말 디바이스(18)에 서비스를 제공한다. M2M 서비스 계층(22')은 임의 수의 M2M 애플리케이션, M2M 게이트웨이 디바이스 및 M2M 단말 디바이스와 통신할 수 있다는 것을 이해할 것이다. M2M 서비스 계층(22')은 상이한 서비스 제공자에 의해 서비스 계층과 상호작용할 수 있다. M2M 서비스 계층(22')은 하나 이상의 서버, 컴퓨터, 가상 머신(예를 들어, 클라우드/컴퓨터/스토리지 팜 등) 등에 의해 구현될 수 있다.
여전히 도 27b를 참조하면, M2M 서비스 계층(22 및 22')은 다양한 애플리케이션들 및 버티컬들이 레버리지할 수 있는 서비스 전달 능력들의 핵심 세트를 제공한다. 이러한 서비스 능력은 M2M 애플리케이션(20 및 20')이 디바이스와 상호 작용할 수 있게 하고 데이터 수집, 데이터 분석, 디바이스 관리, 보안성, 빌링, 서비스/디바이스 탐색, 등의 기능을 수행할 수 있게 한다. 본질적으로, 이러한 서비스 능력들은 이러한 기능성들을 구현하는 애플리케이션들의 부담을 없애고, 따라서 애플리케이션 개발을 간단화하고 마케팅하기 위한 비용 및 시간을 줄인다. 서비스 계층(22 및 22')은 M2M 애플리케이션(20 및 20')이 서비스 계층(22 및 22')이 제공하는 서비스와 관련하여 다양한 네트워크(12 및 12')를 통해 통신할 수 있게 한다.
일부 예들에서, M2M 애플리케이션들(20 및 20')은 본 명세서에서 논의된 바와 같이 그들의 애플리케이션 관계와 관련하여 CSE와 통신하는 부모 및 자식을 각각 포함할 수 있다. M2M 애플리케이션들(20 및 20')은, 이에 제한되는 것은 아니지만, 운송, 건강 및 웰빙, 커넥티드 홈(connected home), 에너지 관리, 자산 추적, 그리고 보안 및 감시와 같은 다양한 산업들에서의 애플리케이션들을 포함할 수 있다. 앞서 언급한 바와 같이, 시스템의 디바이스들, 게이트웨이들, 및 다른 서버들에 걸쳐 실행되는 M2M 서비스 계층은, 예를 들어, 데이터 수집, 디바이스 관리, 보안, 과금, 위치 추적 트래킹/지오펜싱(tracking/geofencing), 디바이스/서비스 발견, 및 레거시 시스템들 통합과 같은 기능들을 지원하고, 이러한 기능들을 서비스들로서 M2M 애플리케이션들(20 및 20')에 제공한다.
본 애플리케이션의 애플리케이션 관계의 관리는 서비스 계층의 일부로서 구현될 수 있다. 서비스 계층(예를 들어, 서비스 계층(172))은 API들(application programming interfaces) 및 하위 네트워킹 인터페이스들의 세트를 통해 부가 가치의 서비스 능력들을 지원하는 소프트웨어 미들웨어 계층이다. M2M 엔티티(예를 들어, 하드웨어와 소프트웨어의 조합에 의해 구현될 수 있는 서비스/플랫폼, 게이트웨이 또는 디바이스와 같은 M2M 기능 엔티티)는 애플리케이션 또는 서비스를 제공할 수 있다. ETSI M2M 및 oneM2M 둘 모두는 본 애플리케이션의 애플리케이션 관계의 관리를 포함할 수 있는 서비스 계층을 사용한다. ETSI M2M의 서비스 계층은 SCL(Service Capability Layer)이라고 지칭된다. SCL은 M2M 디바이스(여기서 이것은 DSCL(Device SCL)이라고 지칭됨), 게이트웨이(여기서 이것은 GSCL(gateway SCL)이라고 지칭됨) 또는 네트워크 노드(여기서 이것은 NSCL(network SCL)이라고 지칭됨) 내에 구현될 수 있다. oneM2M 서비스 계층은 한 세트의 CSF들(Common Service Functions)(즉, 서비스 능력들)을 지원한다. CSF들 중의 하나 이상의 특정 타입들의 세트의 인스턴스 생성은 상이한 타입들의 네트워크 노드들(예를 들어, 기반구조 노드, 미들 노드, 애플리케이션 특정적 노드)상에서 호스팅될 수 있는 CSE(Common Services Entity)로서 지칭될 수 있다. 또한, 본 애플리케이션의 애플리케이션 관계의 관리는 서비스 지향 아키텍처(Service Oriented Architecture; SOA) 또는 자원 지향 아키텍처(resource-oriented architecture; ROA)를 사용하여 본 애플리케이션의 애플리케이션 관계를 관리하는 것과 같은 서비스에 액세스하는 M2M 네트워크의 일부로서 구현될 수 있다.
도 27c는 예를 들어, M2M 단말 디바이스(18) 또는 M2M 게이트웨이 디바이스(14) 등과 같은 예시적 M2M 디바이스(30)의 시스템 다이어그램이다. 도 27c에 도시된 바와 같이, M2M 디바이스(30)는 프로세서(32), 송수신기(34), 송신/수신 엘리먼트(36), 스피커/마이크로폰(38), 키패드(40), 디스플레이/터치패드(42), 비-이동식 메모리(44), 이동식 메모리(46), 전원(48), GPS(global positioning system) 칩셋(50), 및 다른 주변 장치들(52)을 포함할 수 있다. M2M 디바이스(30)가 개시되는 과제와 일관성을 유지하면서 전술한 엘리먼트의 어떠한 세부 조합이라도 포함할 수 있음이 인식될 것이다. M2M 디바이스(30)(예를 들어, 서비스 계층(172), AE(151), M2M 디바이스(281) 등)는 애플리케이션 관계를 관리하기 위한 개시된 시스템 및 방법을 수행하는 예시적인 구현일 수 있다.
프로세서(32)는 범용 프로세서, 특수 목적 프로세서, 종래의 프로세서, DSP(digital signal processor), 복수의 마이크로프로세서들, DSP 코어와 연관되는 하나 이상의 마이크로프로세서들, 제어기, 마이크로제어기, ASIC들(Application Specific Integrated Circuits), FPGA(Field Programmable Gate Array) 회로들, 임의의 다른 타입의 IC(integrated circuit), 상태 머신 등일 수 있다. 프로세서(32)는 신호 코딩, 데이터 처리, 전력 제어, 입/출력 처리, 및/또는 M2M 디바이스(30)가 무선 환경에서 동작할 수 있게 하는 임의의 다른 기능성을 수행할 수 있다. 프로세서(32)는 전송/수신 엘리먼트(36)에 결합될 수 있는 송수신기(34)에 결합될 수 있다. 도 27c가 프로세서(32)와 송수신기(34)를 별도의 컴포넌트들로서 묘사하고 있지만, 프로세서(32)와 송수신기(34)는 전자 패키지 또는 칩 내에 함께 통합될 수 있다는 것을 이해할 것이다. 프로세서(32)는 애플리케이션 계층 프로그램들(예를 들어, 브라우저들) 또는 라디오 액세스 계층(radio access-layer)(RAN) 프로그램들 또는 통신들을 수행할 수 있다. 프로세서(32)는 예를 들어, 액세스-계층 또는 애플리케이션 계층 등에서의 인증, 보안 키 일치, 또는 암호화 연산들 등과 같은 보안 동작을 수행할 수 있다.
전송/수신 엘리먼트(36)는 신호를 M2M 서비스 플랫폼(22)에 전송하거나 또는 그로부터 신호를 수신하도록 구성될 수 있다. 예를 들어, 전송/수신 엘리먼트(36)는 RF 신호를 전송하거나 수신하도록 구성된 안테나일 수 있다. 전송/수신 엘리먼트(36)는 WLAN, WPAN, 셀룰러 등과 같이, 다양한 네트워크들 및 에어 인터페이스들을 지원할 수 있다. 예에서, 전송/수신 엘리먼트(36)는, 예를 들어, IR, UV 또는 가시광 신호들을 전송하거나 수신하도록 구성된 에미터/검출기일 수 있다. 또 다른 예에서, 전송/수신 엘리먼트(36)는 RF 및 광 신호 양쪽 모두를 전송 및 수신하도록 구성될 수 있다. 전송/수신 엘리먼트(36)는 무선 또는 유선 신호들의 임의의 조합을 전송하거나 수신하도록 구성될 수 있다는 점이 이해될 것이다.
추가로, 전송/수신 엘리먼트(36)가 도 27c에 단일 엘리먼트로서 도시되어 있지만, M2M 디바이스(30)는 임의의 개수의 전송/수신 엘리먼트(36)를 포함할 수 있다. 더 구체적으로, M2M 디바이스(30)는 MIMO 기술을 채택할 수 있다. 따라서, 예에서, M2M 디바이스(30)는 무선 신호들을 전송 및 수신하기 위한 2개 이상의 전송/수신 엘리먼트(36)(예를 들어, 다수의 안테나)를 포함할 수 있다.
송수신기(34)는 전송/수신 엘리먼트(36)에 의해 전송될 신호들을 변조하고, 전송/수신 엘리먼트(36)에 의해 수신되는 신호들을 복조하도록 구성될 수 있다. 상기한 바와 같이, M2M 디바이스(30)는 다중 모드 능력들을 가질 수 있다. 따라서, 송수신기(34)는 M2M 디바이스(30)가 예를 들어, UTRA 및 IEEE 802.11과 같은 다중 RAT를 통해 통신할 수 있게 하는 다중 송수신기를 포함할 수 있다.
프로세서(32)는 비-이동식 메모리(44) 및/또는 이동식 메모리(46)와 같은 임의의 타입의 적합한 메모리로부터 정보를 액세스하거나 거기에 데이터를 저장할 수 있다. 비-이동식 메모리(44)는 RAM(random-access memory), ROM(read-only memory), 하드 디스크, 또는 임의의 다른 타입의 메모리 저장 디바이스를 포함할 수 있다. 이동식 메모리(46)는 SIM(subscriber identity module) 카드, 메모리 스틱, SD(secure digital) 메모리 카드 등을 포함할 수 있다. 다른 예들에서, 프로세서(32)는 M2M 디바이스(30) 상에, 예컨대 서버나 홈 컴퓨터 상에 물리적으로 위치되지는 않은 메모리로부터의 정보에 액세스하고, 이러한 메모리에 데이터를 저장할 수 있다. 프로세서(32)는 애플리케이션 관계(예를 들어, 부모/자식 관계 또는 합성/입력 관계)에 응답하여 디스플레이 또는 표시기(42) 상의 조명 패턴, 이미지 또는 컬러를 제어하도록 구성될 수 있다. 예를 들어, 디스플레이상의 조명 패턴, 이미지 또는 컬러 중 일부는 애플리케이션 관계의 적용 가능성, 애플리케이션 관계의 성공적인 등록, 적용 가능한 관계 기록에대한 링크 등과 같은 애플리케이션 관계를 관리하는 표시기일 수 있음은 물론이고, 기존 애플리케이션 관계를 검색, 업데이트, 삭제 및 발견과 관련한 다른 것들일 수도 있다.
프로세서(32)는 본 명세서에서 설명된 일부 예들에서의 LMS가 성공적인지 여부에 응답하여 디스플레이 또는 표시기(42)상의 조명 패턴, 이미지 또는 컬러를 제어하거나(예를 들어, 애플리케이션 관계에 가입하고, 애플리케이션 관계에 기초하여 애플리케이션을 등록하고, 관계를 발견하는 것, 기타등등) , 또는 이와는 달리 애플리케이션 관계 및 관련 컴포넌트의 상태를 표시하도록 구성될 수 있다. 디스플레이 또는 표시기(42) 상의 제어 조명 패턴, 이미지 또는 컬러들은 본 명세서에서 예시되거나 논의된 도면들(예를 들어, 도 6 내지 도 21 등)에서의 방법 흐름들 또는 컴포넌트들 중 임의의 것의 상태를 반영할 수 있다. 본 명세서에는 M2M에서의 애플리케이션 관계의 메시지들 및 절차들이 개시되어 있다. 메시지들 및 절차들은 사용자들이 입력 소스(예를 들어, 스피커/마이크(38), 키패드(40) 또는 디스플레이/터치패드(42))를 통해 애플리케이션 관계 및 관리 컴포넌트들을 요청하거나, 디스플레이(42) 상에 표시될 수 있는 많은 것 가운데 애플리케이션 관계를 요청, 구성 또는 질의하기 위한 인터페이스/API를 제공하도록 확장될 수 있다.
프로세서(32)는 전원(48)으로부터 전력을 수신할 수 있고, 전력을 M2M 디바이스(30) 내의 다른 컴포넌트들에 분배 또는 제어하도록 구성될 수 있다. 전원(48)은 M2M 디바이스(30)에 전력을 공급하기에 적절한 임의의 디바이스일 수 있다. 예를 들어, 전원(48)은 하나 이상의 건전지 배터리들(예를 들어, 니켈-카드뮴(NiCd), 니켈-아연(NiZn), 니켈 금속 수소화물(NiMH), 리튬-이온(Li-ion) 등), 태양 전지들, 연료 전지들 등을 포함할 수 있다.
프로세서(32)는 M2M 디바이스(30)의 현재 위치에 관한 위치 정보(예를 들어, 경도와 위도)를 제공하도록 구성되는 GPS 칩셋(50)에 또한 결합될 수 있다. M2M 디바이스(30)는 예에 일관성을 유지하면서 임의의 적합한 위치 결정 방법에 의해 위치 정보를 취득할 수 있다는 점이 인식될 것이다.
프로세서(32)는 다른 주변 장치들(52)에 또한 결합될 수 있으며, 이러한 주변 장치들은, 추가적인 특징들, 기능성, 또는 유선 또는 무선 접속성을 제공하는 하나 이상의 소프트웨어 또는 하드웨어 모듈들을 포함할 수 있다. 예를 들어, 주변 장치들(52)은 가속도계, e-나침반, 위성 송수신기, 센서, (사진들 또는 비디오를 위한) 디지털 카메라, USB(universal serial bus) 포트, 진동 디바이스, 텔레비전 송수신기, 핸즈프리 헤드셋, Bluetooth® 모듈, FM(frequency modulated) 무선 유닛, 디지털 음악 플레이어, 미디어 플레이어, 비디오 게임 플레이어 모듈, 인터넷 브라우저 등을 포함할 수 있다.
도 27d는 예를 들어, 도 27a 및 도 27b의 M2M 서비스 플랫폼(22)이 구현될 수 있는 예시적인 컴퓨팅 시스템(90)의 블록도이다. 컴퓨팅 시스템(90)은 컴퓨터 또는 서버를 포함할 수 있으며, 이러한 소프트웨어가 어디에 또는 어떤 수단에 의해 저장되고 액세스되든 간에, 소프트웨어의 형태일 수 있는 컴퓨터 판독 가능 명령어들에 의해 주로 제어될 수 있다. 이러한 컴퓨터 판독 가능 명령어들은 컴퓨팅 시스템(90)이 작업할 수 있도록 중앙 처리 유닛(CPU)(91) 내에서 실행될 수 있다. 많은 공지된 워크스테이션들, 서버들, 및 개인용 컴퓨터들에서, 중앙 처리 유닛(91)은 마이크로프로세서라 불리는 단일-칩 CPU에 의해 구현된다. 다른 머신들에서, 중앙 처리 유닛(91)은 다수의 프로세서들을 포함할 수 있다. 코프로세서(81)는 추가적인 기능들을 수행하거나 또는 CPU(91)를 도와주는, 주 CPU(91)와는 별개인, 선택적 프로세서이다. CPU(91) 또는 코프로세서(81)는 향상된 애플리케이션 등록(예를 들어, 한번에 다수의 애플리케이션의 등록)을 수신하는 것과 같이, 애플리케이션 관계의 관리를 위한 개시된 시스템 및 방법과 관련된 데이터를 수신, 생성 및 처리할 수 있다.
동작에 있어서, CPU(91)는 명령어들을 페치, 디코드, 및 실행하고, 컴퓨터의 주 데이터 이송 경로인 시스템 버스(80)를 통해 다른 자원들로/로부터 정보를 이송한다. 이러한 시스템 버스는 컴퓨팅 시스템(90) 내의 컴포넌트들을 접속하고, 데이터 교환을 위한 매체를 정의한다. 시스템 버스(80)는 데이터를 전송하기 위한 데이터 라인들, 어드레스들을 전송하기 위한 어드레스 라인들, 및 인터럽트들을 전송하고 시스템 버스를 동작시키기 위한 제어 라인들을 통상적으로 포함한다. 이러한 시스템 버스(80)의 예는 PCI(Peripheral Component Interconnect) 버스이다.
시스템 버스(80)에 결합된 메모리 디바이스는 RAM(random access memory)(82) 및 ROM(read only memory)(93)을 포함한다. 이러한 메모리들은 정보가 저장 및 검색되게 하는 회로를 포함한다. ROM들(93)은 쉽게 수정될 수 없는 저장된 데이터를 일반적으로 포함한다. RAM(82)에 저장되는 데이터는 CPU(91) 또는 다른 하드웨어 디바이스들에 의해 판독 또는 변경될 수 있다. RAM(82) 또는 ROM(93)에 대한 액세스는 메모리 제어기(92)에 의해 제어될 수 있다. 메모리 제어기(92)는 명령어들이 실행됨에 따라 가상 어드레스들을 물리적 어드레스들로 변환하는 어드레스 변환 기능을 제공할 수 있다. 메모리 제어기(92)는 시스템 내의 프로세스들을 격리하고 시스템 프로세스들을 사용자 프로세스들로부터 격리하는 메모리 보호 기능을 또한 제공할 수 있다. 따라서, 제1 모드에서 실행되는 프로그램은 그 자신의 프로세스 가상 어드레스 공간에 의해 매핑되는 메모리만 액세스할 수 있고; 이것은 프로세스들 사이의 메모리 공유가 마련되지 않는 한 다른 프로세스의 가상 어드레스 공간 내의 메모리를 액세스할 수 없다.
또한, 컴퓨팅 시스템(90)은 CPU(91)로부터 프린터(94), 키보드(84), 마우스(95), 및 디스크 드라이브(85)와 같은 주변 장치들로 명령어들을 통신하는 것을 담당하는 주변 장치 제어기(83)를 포함할 수 있다.
디스플레이 제어기(96)에 의해 제어되는 디스플레이(86)는 컴퓨팅 시스템(90)에 의해 생성되는 시각적 출력을 디스플레이하는데 사용된다. 이러한 시각적 출력은 텍스트, 그래픽, 애니메이션 그래픽, 및 비디오를 포함할 수 있다. 디스플레이(86)는 CRT 기반 비디오 디스플레이, LCD 기반 평면 패널 디스플레이, 가스 플라즈마 기반 평면 패널 디스플레이, 또는 터치 패널로 구현될 수 있다. 디스플레이 제어기(96)는 디스플레이(86)에 전송되는 비디오 신호를 생성하는데 요구되는 전자 컴포넌트들을 포함한다.
또한, 컴퓨팅 시스템(90)은 도 27a 및 도 27b의 네트워크(12)와 같은 외부 통신 네트워크에 컴퓨팅 시스템(90)을 연결하는데 사용될 수 있는 네트워크 어댑터(97)를 포함할 수 있다.
본 명세서에서 설명된 시스템들, 방법들, 및 프로세스들 중 임의의 것 또는 모두가 컴퓨터 판독 가능 저장 매체 상에 저장된 컴퓨터 실행가능 명령어들(즉, 프로그램 코드)의 형태로 구체화될 수 있고, 명령어들은 컴퓨터, 서버, M2M 단말 디바이스, M2M 게이트웨이 디바이스 등과 같은 머신에 의해 실행되는 경우, 본 명세서에서 설명된 시스템들, 방법들 및 프로세스들을 수행 또는 구현한다. 구체적으로, 위에 설명된 단계들, 동작들 또는 기능들 중 임의의 것이 그러한 컴퓨터 실행가능 명령어들의 형태로 구현될 수 있다. 컴퓨터 판독 가능 저장 매체는 정보의 저장을 위해 임의의 방법 또는 기술로 구현된 휘발성 및 비휘발성의, 이동식 및 비-이동식 매체 양쪽 모두를 포함하지만, 이러한 컴퓨터 판독 가능 저장 매체는 신호들을 포함하지는 않는다. 컴퓨터 판독 가능 저장 매체는 RAM, ROM, EEPROM, 플래시 메모리 또는 다른 메모리 기술, CD-ROM, DVD(digital versatile disks) 또는 다른 광학 디스크 스토리지, 자기 카세트, 자기 테이프, 자기 디스크 스토리지 또는 다른 자기 스토리지 디바이스, 또는 원하는 정보를 저장하는데 이용될 수 있으며 컴퓨터에 의해 액세스될 수 있는 임의의 다른 물리적 매체를 포함하지만, 이에 제한되지는 않는다.
본 명세서에 기재된 바와 같이, 다른 것들 중에서도, 방법, 시스템 및 장치는 다른 것들 중에서 애플리케이션 관계를 요청, 구성 또는 결정하기 위한 수단을 제공할 수 있다. 방법, 시스템, 컴퓨터 판독 가능 저장 매체 또는 장치는 제1 애플리케이션에 대한 소프트웨어의 검색을 도와주기 위한 수단; 제2 애플리케이션에 대한 제1 애플리케이션의 관계를 결정하는 수단 -제2 애플리케이션은 부모 애플리케이션임- ; 및 제2 애플리케이션에 대한 제1 애플리케이션의 관계에 기초하여 상기 제2 애플리케이션에 제1 메시지를 전송하는 수단 -메시지는 제1 애플리케이션에 대한 소프트웨어 검색의 경보를 포함함- 을 갖는다. 제2 애플리케이션은 제1 애플리케이션에 대한 부모 애플리케이션일 수 있다. 메시지는 제2 애플리케이션에 대한 제1 애플리케이션의 관계를 포함할 수 있다. 메시지는 제1 애플리케이션의 식별자 또는 상기 소프트웨어의 버전을 포함할 수 있다. 방법, 시스템, 컴퓨터 판독 가능 저장 매체 또는 장치는 제1 애플리케이션의 소프트웨어의 가장 최근에 설치된 버전의 통지를 수신하는 것을 포함할 수 있는 추가 동작을 위한 수단을 갖는다. 제1 애플리케이션은 제2 애플리케이션에 대한 입력 애플리케이션일 수 있다. 메시지는 제1 애플리케이션이 검색된 소프트웨어를 설치했음을 제2 애플리케이션에 통지할 수 있다. 제2 애플리케이션은 제1 애플리케이션이 검색된 소프트웨어를 설치했다는 통지에 기초하여 제1 애플리케이션으로부터의 데이터를 처리하는 프로세스를 변경할 수 있다.
방법, 시스템, 컴퓨터 판독 가능 저장 매체 또는 장치는 애플리케이션 관계에 대한 자원을 생성하라는 요청을 송신하기 위한 수단 -요청은 애플리케이션 관계의 유형을 포함함- ; 및 애플리케이션 관계에 대한 자원의 생성을 확인하는 응답을 수신하기 위한 수단 -응답은 애플리케이션 관계에 대한 자원의 식별자를 포함함- 을 갖는다. 요청은 서비스 계층에 등록된 애플리케이션의 목록 또는 존재하는 애플리케이션 관계에 대한 기간을 더 포함할 수 있다.
방법, 시스템, 컴퓨터 판독 가능 저장 매체 또는 장치는 제1 등록 요청에 기초하여 제1 애플리케이션에 대한 제1 자원을 생성하는 수단; 제2 등록 요청에 기초하여 제2 애플리케이션에 대한 제2 자원을 생성하는 수단; 제1 애플리케이션과 제2 애플리케이션 간의 관계를 생성하라는 요청을 포함하는 제1 요청을 수신하는 수단; 및 제1 요청에 기초하여, 제1 애플리케이션과 제2 애플리케이션 간의 관계를 생성하는 수단을 갖는다. 관계의 생성은 제1 자원 및 제2 자원을 업데이트하는 것을 포함할 수 있다. 방법, 시스템, 컴퓨터 판독 가능 저장 매체 또는 장치는 제1 자원을 제2 자원과 접속하는 포인터로 업데이트하는 수단을 가지고, 포인터는 제1 애플리케이션이 제2 애플리케이션의 부모임을 표시한다. 방법, 시스템, 컴퓨터 판독 가능 저장 매체 또는 장치는 제1 애플리케이션과 제2 애플리케이션 간의 관계 생성을 제1 애플리케이션에게 통보하는 수단을 갖는다. 관계는 제1 애플리케이션과 제2 애플리케이션 간의 부모/자식 관계를 포함할 수 있다. 관계는 제1 애플리케이션과 제2 애플리케이션 간의 합성/입력 관계를 포함할 수 있다. 상기 관계는 상기 제1 자원 내의 제1 애플리케이션 관계 속성을 업데이트하는 것을 포함할 수 있다. 제1 요청은 공통 서비스 엔티티의 애플리케이션 관계 관리 서비스 상에서 수신될 수 있다.
본 개시내용의 요지의 바람직한 방법들, 시스템들 또는 장치들을 설명함에 있어서, 도면에 예시된 바와 같이, 명확성을 기하기 위해 특정 용어가 사용된다. 그러나, 청구되는 요지는 그와 같이 선택되는 구체적인 용어로 제한되는 것으로 의도되는 것이 아니며, 각각의 구체적인 엘리먼트가 유사한 목적을 달성하기 위해 유사한 방식으로 동작하는 모든 기술적 등가물들을 포함하는 것으로 이해되어야 할 것이다.
본 작성 명세서는 최상의 모드를 포함하는 본 발명을 개시하고, 또한 본 기술분야의 통상의 기술자가 임의의 디바이스들 또는 시스템들을 제작하고 사용하고 임의의 통합된 방법들을 수행하는 것을 포함하여 본 발명을 실시할 수 있도록 하기 위해 예를 사용한다. 본 발명의 특허가능한 범위는 청구항들에 의해 정의되며, 본 기술분야의 통상의 기술자에게 떠오르는 다른 예들을 포함할 수 있다(예를 들어, 본 명세서에 개시된 예시적인 방법들 사이에서의 단계들의 추가, 단계들의 결합, 또는 단계들의 스킵). 이러한 다른 예들은, 그것들이 청구항들의 기재(literal language)와 상이하지 않은 구조적 엘리먼트들을 갖는 경우에 또는 그것들이 청구항들의 기재와 미미한(insubstantial) 차이를 갖는 등가의 구조적 엘리먼트들을 포함하는 경우에, 청구항들의 범위 내에 있는 것으로 의도된다.

Claims (20)

  1. 애플리케이션 관계를 관리하기 위한 장치로서,
    프로세서; 및
    상기 프로세서와 결합된 메모리를 포함하고, 상기 메모리는 저장되어 있는 실행 가능한 명령어들을 갖고, 상기 명령어들은 상기 프로세서에 의해 실행될 때, 상기 프로세서로 하여금:
    제1 등록 요청에 기초하여 제1 애플리케이션에 대한 제1 자원을 생성하기 위한 명령어들을 제공하는 동작;
    제2 등록 요청에 기초하여 제2 애플리케이션에 대한 제2 자원을 생성하기 위한 명령어들을 제공하는 동작;
    상기 제1 애플리케이션과 상기 제2 애플리케이션 간의 관계를 생성하기 위한 요청을 포함하는 제1 요청을 수신하는 동작;
    상기 제1 요청에 기초하여, 상기 제1 애플리케이션과 상기 제2 애플리케이션 간의 관계를 생성하기 위한 명령어들을 제공하는 동작 -상기 관계의 생성은 상기 제1 자원과 상기 제2 자원을 업데이트하는 것을 포함함- ; 및
    상기 제1 자원을 상기 제2 자원과 접속하는 포인터로 업데이트하는 동작 -상기 포인터는 상기 제1 애플리케이션이 상기 제2 애플리케이션의 부모 애플리케이션임을 표시함- 을 포함하는 동작들을 수행하게 하는 장치.
  2. 제1항에 있어서,
    상기 동작들은 상기 제1 애플리케이션에게 상기 제1 애플리케이션과 상기 제2 애플리케이션 간의 관계의 생성을 통지하는 동작을 더 포함하는 장치.
  3. 제1항에 있어서,
    상기 관계는 그래픽 사용자 인터페이스 상에 디스플레이되는 장치.
  4. 제1항에 있어서,
    상기 동작들은 상기 관계에 기초하여 서비스 계층으로부터 등록 해제(de-registration)하는 동작을 더 포함하는 장치.
  5. 제1항에 있어서,
    상기 관계는 상기 제1 자원 내의 제1 애플리케이션 관계 속성을 업데이트하는 것을 포함하는 장치.
  6. 제1항에 있어서,
    상기 제1 요청은 공통 서비스 엔티티의 애플리케이션 관계 관리 서비스 상에서 수신되는 장치.
  7. 제1항에 있어서,
    상기 장치는 머신-투-머신(machine-to-machine) 디바이스 또는 머신-투-머신 게이트웨이인 장치.
  8. 애플리케이션 관계를 관리하기 위한 방법으로서, 상기 방법은,
    제1 등록 요청에 기초하여 제1 애플리케이션에 대한 제1 자원을 생성하는 단계;
    제2 등록 요청에 기초하여 제2 애플리케이션에 대한 제2 자원을 생성하는 단계;
    상기 제1 애플리케이션과 상기 제2 애플리케이션 간의 관계를 생성하기 위한 요청을 포함하는 제1 요청을 수신하는 단계;
    상기 제1 요청에 기초하여, 상기 제1 애플리케이션과 상기 제2 애플리케이션 간의 관계를 생성하는 단계 -상기 관계의 생성은 상기 제1 자원 및 상기 제2 자원을 업데이트하는 것을 포함함- ; 및
    상기 제1 자원을 상기 제2 자원과 접속하는 포인터로 업데이트하는 단계 -상기 포인터는 상기 제1 애플리케이션이 상기 제2 애플리케이션의 부모 애플리케이션임을 표시함- 를 포함하는 방법.
  9. 제8항에 있어서,
    상기 제1 애플리케이션에게 상기 제1 애플리케이션과 상기 제2 애플리케이션 간의 관계의 생성을 통지하는 단계를 더 포함하는 방법.
  10. 제8항에 있어서,
    상기 관계는 그래픽 사용자 인터페이스 상에 디스플레이되는 방법.
  11. 제8항에 있어서,
    상기 관계에 기초하여 서비스 계층으로부터 등록 해제하는 단계를 더 포함하는 방법.
  12. 제8항에 있어서,
    상기 관계는 상기 제1 자원 내의 제1 애플리케이션 관계 속성을 업데이트하는 것을 포함하는 방법.
  13. 제8항에 있어서,
    상기 제1 요청은 공통 서비스 엔티티의 애플리케이션 관계 관리 서비스 상에서 수신되는 방법.
  14. 제8항에 있어서,
    머신-투-머신 게이트웨이는 상기 관계를 관리하는 방법.
  15. 컴퓨팅 디바이스에 의해 실행될 때 상기 컴퓨팅 디바이스가 동작들을 수행하게 하는 컴퓨터 실행가능 명령어들을 포함하는 컴퓨터 판독 가능 저장 매체로서, 상기 동작들은,
    제1 등록 요청에 기초하여 제1 애플리케이션에 대한 제1 자원을 생성하는 동작;
    제2 등록 요청에 기초하여 제2 애플리케이션에 대한 제2 자원을 생성하는 동작;
    상기 제1 애플리케이션과 상기 제2 애플리케이션 간의 관계를 생성하기 위한 요청을 포함하는 제1 요청을 수신하는 동작;
    상기 제1 요청에 기초하여, 상기 제1 애플리케이션과 상기 제2 애플리케이션 간의 관계를 생성하는 동작을 포함하는 컴퓨터 판독 가능 저장 매체.
  16. 제15항에 있어서,
    상기 관계의 생성은 상기 제1 자원 및 상기 제2 자원을 업데이트하는 것을 포함하는 컴퓨터 판독 가능 저장 매체.
  17. 제16항에 있어서,
    상기 동작들은 상기 제1 자원을 상기 제2 자원과 접속하는 포인터로 업데이트하는 동작 -상기 포인터는 상기 제1 애플리케이션이 상기 제2 애플리케이션의 부모 애플리케이션임을 표시함- 을 더 포함하는 컴퓨터 판독 가능 저장 매체.
  18. 제16항에 있어서,
    상기 동작들은 상기 제1 애플리케이션에게 상기 제1 애플리케이션과 상기 제2 애플리케이션 간의 관계의 생성을 통지하는 동작을 더 포함하는 컴퓨터 판독 가능 저장 매체.
  19. 제15항에 있어서,
    상기 관계는 상기 제1 애플리케이션과 상기 제2 애플리케이션 간의 부모/자식 관계를 포함하는 컴퓨터 판독 가능 저장 매체.
  20. 제15항에 있어서,
    상기 관계는 상기 제1 애플리케이션과 상기 제2 애플리케이션 간의 합성/입력 관계를 포함하는 컴퓨터 판독 가능 저장 매체.
KR1020177014421A 2014-10-31 2015-10-30 머신-투-머신 시스템에서의 애플리케이션 관계 관리 KR102036420B1 (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201462073582P 2014-10-31 2014-10-31
US62/073,582 2014-10-31
PCT/US2015/058344 WO2016070064A1 (en) 2014-10-31 2015-10-30 Managing application relationships in machine-to-machine systems

Publications (2)

Publication Number Publication Date
KR20170075000A true KR20170075000A (ko) 2017-06-30
KR102036420B1 KR102036420B1 (ko) 2019-10-24

Family

ID=54705794

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020177014421A KR102036420B1 (ko) 2014-10-31 2015-10-30 머신-투-머신 시스템에서의 애플리케이션 관계 관리

Country Status (6)

Country Link
US (1) US10990449B2 (ko)
EP (1) EP3213205A1 (ko)
JP (1) JP2017533523A (ko)
KR (1) KR102036420B1 (ko)
CN (1) CN107430512B (ko)
WO (1) WO2016070064A1 (ko)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3213205A1 (en) 2014-10-31 2017-09-06 Convida Wireless, LLC Managing application relationships in machine-to-machine systems
KR102046700B1 (ko) * 2015-02-20 2019-11-19 콘비다 와이어리스, 엘엘씨 메시지 버스 서비스 디렉토리
WO2016196947A1 (en) * 2015-06-05 2016-12-08 Convida Wireless, Llc Method and appparatus of interworking m2m and iot devices and applications with different service layers
JP6612437B2 (ja) * 2015-09-01 2019-11-27 コンヴィーダ ワイヤレス， エルエルシー サービス層登録
WO2017040931A1 (en) 2015-09-02 2017-03-09 Convida Wireless, Llc Methods and apparatus for enhancing native service layer device management functionality
US10922089B2 (en) * 2016-09-22 2021-02-16 Groupon, Inc. Mobile service applications
CN108111465B (zh) * 2016-11-24 2021-08-31 华为技术有限公司 一种用于管理用户设备的方法和装置
CN109309654B (zh) * 2017-07-28 2022-01-21 京东方科技集团股份有限公司 创建资源的方法及相应的注册方法、服务器和客户端装置
WO2019040609A1 (en) * 2017-08-22 2019-02-28 Convida Wireless, Llc OVERLAY RESOURCE ARBORESCENCE IN A COMMUNICATION NETWORK

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003076958A (ja) * 2001-09-03 2003-03-14 Sony Corp 携帯端末装置および機能関連付け登録方法、機能選択画面表示方法
US20040216122A1 (en) * 2002-07-23 2004-10-28 Charles Gram Method for routing data through multiple applications
JP2004348715A (ja) * 2003-04-28 2004-12-09 Matsushita Electric Ind Co Ltd サービス管理システム、ならびにそれに用いられる方法、通信機器および集積回路
JP2014010512A (ja) * 2012-06-28 2014-01-20 Psc:Kk アプリケーション連携システム、アプリケーション連携方法及びアプリケーション連携プログラム
WO2014129802A1 (ko) * 2013-02-19 2014-08-28 엘지전자 주식회사 M2m 서비스 설정 변경 방법 및 이를 위한 장치
US20140282189A1 (en) * 2013-03-18 2014-09-18 International Business Machines Corporation Chaining applications

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3866466B2 (ja) * 1999-12-13 2007-01-10 株式会社東芝 データ構造管理装置、データ構造管理システム、データ構造管理方法およびデータ構造管理プログラムを格納する記録媒体
US6947946B2 (en) * 1999-12-28 2005-09-20 International Business Machines Corporation Database system including hierarchical link table
EP1473906A2 (en) * 2003-04-28 2004-11-03 Matsushita Electric Industrial Co., Ltd. Service management system, and method, communications unit and integrated circuit for use in such system
EP1542123B1 (en) * 2003-12-10 2008-01-23 International Business Machines Corporation Method and system for automatically generating service interfaces for a service oriented architecture
EP1617326A1 (en) * 2004-07-14 2006-01-18 Sap Ag Technique for handling hierarchical application data
US7836088B2 (en) * 2006-10-26 2010-11-16 Microsoft Corporation Relationship-based processing
US20090049422A1 (en) * 2007-05-10 2009-02-19 Joseph Hage Method and system for modeling and developing a software application
CN101377737B (zh) 2007-08-28 2012-01-11 上海宝信软件股份有限公司 应用系统资源管理装置
TWI569615B (zh) * 2010-03-01 2017-02-01 內數位專利控股公司 機器對機器閘道器
CN102467672B (zh) 2010-11-11 2014-08-06 中国移动通信集团公司 智能卡片的子应用管理方法及设备
CN102547686B (zh) 2010-12-07 2015-03-04 中国电信股份有限公司 M2m终端安全接入方法及终端、管理平台
CN102186164B (zh) 2011-02-18 2014-04-02 华为技术有限公司 操作设备资源的方法和管理装置
US8818946B2 (en) * 2011-07-08 2014-08-26 Telefonaktiebolaget L M Ericsson (Publ) Machine to machine (M2M) application server, XDMS server, and methods for M2M applications group management
KR101469427B1 (ko) 2011-07-21 2014-12-04 엘지전자 주식회사 다수의 랜덤 엑세스 우선순위 등급을 갖는 무선 통신 시스템에서 랜덤 엑세스 프리앰블을 관리하는 방법 및 장치
CN103200209B (zh) * 2012-01-06 2018-05-25 华为技术有限公司 成员资源的访问方法、群组服务器和成员设备
US9760843B1 (en) * 2012-01-25 2017-09-12 Sprint Communications Company L.P. Pooling network devices
KR102034736B1 (ko) 2012-05-30 2019-10-22 삼성에스디에스 주식회사 M2m 통신용 관리 장치 및 방법
US9280253B2 (en) 2012-06-28 2016-03-08 Findex Inc. Application coordinating system, application coordinating method, and application coordinating program
CN103596118B (zh) 2012-08-13 2017-06-20 华为终端有限公司 发现机器对机器业务的方法、设备及系统
CN103596117B (zh) * 2012-08-13 2017-12-15 华为终端（东莞）有限公司 发现机器对机器业务的方法、设备及系统
CN103618800B (zh) * 2013-12-05 2017-11-03 华为技术有限公司 订阅通知的实现方法和装置
CN105323186B (zh) * 2014-06-20 2020-04-21 中兴通讯股份有限公司 一种通知消息的负载控制方法和装置
CN104035804B (zh) * 2014-06-26 2017-11-17 北京中电普华信息技术有限公司 一种应用集成方法及装置
EP3213205A1 (en) 2014-10-31 2017-09-06 Convida Wireless, LLC Managing application relationships in machine-to-machine systems

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003076958A (ja) * 2001-09-03 2003-03-14 Sony Corp 携帯端末装置および機能関連付け登録方法、機能選択画面表示方法
US20040216122A1 (en) * 2002-07-23 2004-10-28 Charles Gram Method for routing data through multiple applications
JP2004348715A (ja) * 2003-04-28 2004-12-09 Matsushita Electric Ind Co Ltd サービス管理システム、ならびにそれに用いられる方法、通信機器および集積回路
JP2014010512A (ja) * 2012-06-28 2014-01-20 Psc:Kk アプリケーション連携システム、アプリケーション連携方法及びアプリケーション連携プログラム
WO2014129802A1 (ko) * 2013-02-19 2014-08-28 엘지전자 주식회사 M2m 서비스 설정 변경 방법 및 이를 위한 장치
US20140282189A1 (en) * 2013-03-18 2014-09-18 International Business Machines Corporation Chaining applications

Also Published As

Publication number Publication date
KR102036420B1 (ko) 2019-10-24
US10990449B2 (en) 2021-04-27
JP2017533523A (ja) 2017-11-09
EP3213205A1 (en) 2017-09-06
CN107430512B (zh) 2021-02-02
US20170337088A1 (en) 2017-11-23
CN107430512A (zh) 2017-12-01
WO2016070064A1 (en) 2016-05-06

Similar Documents

Publication Publication Date Title
KR102036420B1 (ko) 머신-투-머신 시스템에서의 애플리케이션 관계 관리
CN108353094B (zh) 用于m2m服务层的跨资源订阅
US11799711B2 (en) Service layer resource management for generic interworking and extensibility
CN110149616B (zh) 轻量级iot信息模型
US20160227346A1 (en) Service Layer Resource Propagation Across Domains
CN109964495B (zh) 应用的服务层移动性管理
CN113434780A (zh) 增强的restful操作
US11936749B2 (en) Cross-domain discovery between service layer systems and web of things systems
EP3332335A1 (en) Mechanisms for multi-dimension data operations
CN107950005B (zh) 服务元素主机选择
CN111201804B (zh) 启用数据连续性服务的方法、装置和计算机可读存储介质
KR102500594B1 (ko) 통신 네트워크에서의 서비스 계층 메시지 템플릿들
US20200220919A1 (en) Overlay resource trees in a communication network
CN108028852B (zh) 服务元素
US20220141309A1 (en) Efficient resource representation exchange between service layers
US20240187495A1 (en) Cross-domain discovery between service layer systems and web of things systems

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
AMND Amendment
E601 Decision to refuse application
AMND Amendment
X701 Decision to grant (after re-examination)