KR20170100646A - M2m 시스템들에 대한 시맨틱 주석 및 시맨틱 저장소 - Google Patents

Abstract

"정상 리소스들의 시맨틱(semantics of normal resources)"(이하 리소스 시맨틱)에 주석을 달고 이를 저장하는데 사용될 수 있는 방법들, 시스템들, 및 디바이스들. 이러한 방법들, 시스템들, 및 디바이스들은 시맨틱 지원을 위한 기능적 아키텍처의 일부일 수 있고 시맨틱 기반 쿼리를 고려할 수 있다. 또한, 시맨틱 정보를 표현하기 위해 시맨틱 자식 리소스와 관련된 방법들, 시스템들, 및 디바이스들이 리소스 내에 생성될 수 있다.

Description

M2M 시스템들에 대한 시맨틱 주석 및 시맨틱 저장소

<관련 출원들에 대한 상호 참조>

본 출원은 2014년 12월 30일 출원된 "Semantics Annotation and Semantics Repository for M2M Systems"라는 명칭의 미국 임시 특허 출원 제62/098011호 및 2015년 3월 20일 출원된 "Semantics Annotation and Semantics Repository for M2M Systems"라는 명칭의 미국 임시 특허 출원 제62/136,198호의 혜택을 주장하며, 양자 모두의 내용들은 본 명세서에 참조로 원용된다.

<배경기술>

물리적 환경들에 배치된 네트워크-가능 디바이스들 및 센서들의 개수에서의 급속한 증가는 통신 네트워크들을 변경하고 있다. 향후 10년 내에 수십억 개의 디바이스들이 스마트 그리드들, 스마트 홈들, e-헬스, 자동차, 수송, 물류, 및 환경 모니터링과 같은 다양한 영역들에서 서비스 제공자들에 의한 많은 애플리케이션들 및 서비스들에 대해 무수한 실세계 데이터를 발생시킬 것으로 예측된다. 현재의 정보 네트워킹 기술들로의 실세계 데이터 및 서비스들의 통합을 가능하게 하는 관련 기술들 및 솔루션들은 IoT(Internet of things) 또는 M2M(machine-to-machine) 통신이라는 포괄적인 용어들 하에서 종종 설명된다. 디바이스들에 의해 생성되는 다량의 데이터 때문에, 이러한 데이터를 식별 및 쿼리하기 위한 효율적인 방식에 대한 필요성이 존재한다.

종합 포인트(aggregation point)로서 액추에이터를 사용하는 컴팩트한 바이오메디컬 무선 센서 모트들(compact biomedical wireless sensor motes)을 사용하여 환자의 병원 또는 재활 센터에 의해 제공될 수 있는 환자 모니터링 애플리케이션이 예이다. 액추에이터는 데이터를 네트워크에 송신한다. 이러한 소형의 웨어러블 리소스 제약형 디바이스들은, 다른 것들 중에서, 혈압과 혈류, 심부 체온(core temperature), 산소 포화도, 모션, 심박수, 청력 및 시력과 같은 바이탈 사인들을 계속해서 모니터링하기 위해 환자 상에 배치될 수 있는 M2M 디바이스들의 예들이다. M2M 디바이스들에 의해 수집되는 다양한 종류들의 M2M 데이터는, 다른 것들 중에서, 환자의 의사, 개인 트레이너(예를 들어, 24 시간 피트니스), 또는 구급차 서비스에 의해 사용될 수 있다. 의사, 개인 트레이너, 및 구급차 서비스가 M2M 디바이스들로부터 발생되는 데이터를 사용하는 것을 가능하게 하기 위해서는, 이러한 리소스들의 시맨틱이 또한 이용 가능하여야 한다. 시맨틱은 데이터의 구조 및 포맷이 이해될 수 있도록 데이터의 설명적 정의(descriptive definition)를 제공한다(즉, 시맨틱은 데이터에 대한 의미를 제공함).

M2M 시맨틱 지원은 이들에 관한 임의의 진보된 처리, 예를 들어 시맨틱 쿼리, 데이터 분석 등 뿐만 아니라, 이들의 범용 이해/해석을 위해 리소스들에 대한 시맨틱을 가능하게 하도록 의도된다. 이하 배경기술 섹션에서는 예시적인 M2M 아키텍처(예를 들어, oneM2M 아키텍처) 뿐만 아니라 시맨틱 웹에서 개발되는 기존 기술이 소개된다.

개발중인 oneM2M 표준(oneM2M-TS-0001 oneM2M Functional Architecture-V-1.1.0)은, 도 3에 도시되는 바와 같이, CSE(common service entity)라 불리우는 서비스 레이어를 정의한다. Mca 참조 포인트는 AE(application entity)와 인터페이스한다. Mcc 참조 포인트는 동일한 서비스 제공자 도메인 내의 다른 CSE와 인터페이스하고, Mcc' 참조 포인트는 상이한 서비스 제공자 도메인에서의 다른 CSE와 인터페이스한다. Mcn 참조 포인트는 기본 NSE(network service entity)와 인터페이스한다. NSE는 디바이스 관리, 위치 서비스들 및 디바이스 트리거링과 같은 CSE들에 대한 기본 네트워크 서비스들을 제공한다. CSE는 "Discovery"또는 "Data Management & Repository"와 같은 "CSF들(Common Service Functions)"이라 불리우는 다수의 논리 함수들을 포함한다. 도 4는 oneM2M에 대한 CSF의 예를 도시한다.

oneM2M 아키텍처는 ASN(application service node), ADN(application dedicated node), MN(middle node), 및 IN(infrastructure node)를 가능하게 한다. ASN은, 하나의 CSE를 포함하며 적어도 하나의 AE를 포함하는 노드이다. 물리적 매핑의 예는 M2M 디바이스에 존재하는 ASN이다. ADN은, 적어도 하나의 AE를 포함하며 CSE를 포함하지 않는 노드이다. 물리적 매핑의 예는 M2M 디바이스에 존재하는 ADN이다. MN은, 하나의 CSE를 포함하며 0개 이상의 AE들을 포함하는 노드이다. MN에 대한 물리적 매핑의 예는 M2M 게이트웨이에 존재하는 MN이다. IN은, 하나의 CSE를 포함하며 0개 이상의 AE들을 포함하는 노드이다. IN에 대한 물리적 매핑의 예는 M2M 서비스 인프라스트럭처에 존재하는 IN이다.

(Service Component Architecture, TS-0007 Service Component Architecture-V-1.1.0)에 설명되는 M2M 서비스 아키텍처는 M2M 서비스 제공자들 및 M2M 애플리케이션에 제공되는 M2M 서비스들을 특정함으로써 oneM2M 기능적 아키텍처를 증대시킨다. 도 5에 도시된 컴포넌트들은 서비스 노출 컴포넌트, 네트워크 서비스 이용 컴포넌트, 및 원격 서비스 노출 컴포넌트이다. 서비스 노출 컴포넌트는 AE들에 대해 서비스들을 노출시킨다. 네트워크 서비스 이용 컴포넌트는 NSE로부터의 서비스들을 소비한다. 그리고 원격 서비스 노출 컴포넌트는 상이한 M2M 환경들로부터의 서비스들을 접속시킨다.

시맨틱 웹이 이하 논의된다. 시맨틱 웹은 스키마 언어와 온톨로지 언어의 조합을 사용하여 온톨로지들의 능력들을 제공한다. 온톨로지는 미리 정의된, 예약된 어휘를 사용하여 구체적인 관심 영역에 대한 클래스들 및 이들 사이의 관계들, 또는 그 이상을 정의한다. W3C(World Wide Web Consortium)에 의해 정의되는 바와 같은 RDFS(Resource Description Framework Schema) (예를 들어, RDF Vocabulary Description Language 1.0: RDF Schema)는 클래스들 및 특성들을 정의하는데 사용될 수 있는 RDF(Resource Description Framework)에 대한 구체적인 어휘를 제공한다. OWL(Web Ontology Language)는 웹에 대해 보다 표현력이 있는 온톨로지들을 구축하는데 사용될 수 있는 추가 리소스들로 RDFS 어휘를 확장한다. 특성은 리소스들 사이의 관계를 수립한다. 본 명세서에 논의되는 것과 동일한 관계로 고려될 수 있다. 특성은 URI/URL에 의해 식별될 수 있다. 이것은 온톨로지를 구성하는 기본 요소들 중 하나이다.

RDF는 웹에서의 정보를 나타내기 위한 프레임워크이다. RDF는 본질적으로 데이터 모델이다. 그 기본 빌딩 블록은 문장이라 불리우는 리소스-특성-값 3종(resource-property-value triple)이다. RDF에는 XML, JSON 등의 구문이 주어졌다.

도 1은 RDF를 사용할 수 있는 시맨틱 예를 도시한다. 정보를 나타내기 위한 툴로서의 RDF 그래프. 이러한 그래프는 추상적으로 - 인간의 분석에는 우수하지만, 애플리케이션 교환에 대해서는 덜 그러하다. RDF 문장들은 파일 또는 다른 바이트 스트림과 같은 구체적 포맷으로 또한 표현될 수 있다. 가장 대중적으로 사용되는 표현 포맷들은 RDF/XML(RDF 언어)(802) 및 Terse RDF Triple Language(Turtle)(804)이다. RDF는 3개의 컴포넌트들: 주어, 술어, 및 목적어를 갖는다. 주어는 설명되고 있는 리소스이다. RDF에서, 리소스는 URI(Uniform Resource Identifier)를 통해 고유하게 식별가능한 임의의 것일 수 있다. 문장의 목적어는 주어에 대해 작용되고 있는 타겟이다. 주어와 마찬가지로, 이것은 URI에 의해 식별되는 리소스일 수 있지만, 이것은 대안적으로 문자열 또는 숫자와 같이 문자 값일 수 있다. 문장의 술어는 주어와 목적어 사이에 어떤 종류의 관계가 유지되는지 결정한다. 이것은 URI에 의해서 또한 식별된다.

예에서, 도 1에 도시되는 바와 같이, 문장(801)은 John Smith의 직책이 교수라는 점을 나타내고, 이는 RDF 언어(802)로 표현될 수 있다. xmlns:uni(803)은 자체 정의되는 도메인 명칭이며, 여기서 특성들(이름 및 직책)이 RDFS의 일부로서 정의된다. RDF는 도메인 독립적이어서, 특정한 사용의 도메인에 관한 가정들이 행해지지 않는다. RDFS(RDF Schema)라 불리우는 스키마 언어로 자신의 용어를 정의하는 것은 사용자들에게 달려 있다. RDFS는 RDF 데이터 모델들에서 사용되는 어휘를 정의한다. RDFS에서, 어휘가 정의될 수 있고, 목적어 사이의 관계들이 설명될 수 있고, 특정 종류의 목적어들에 적용되도록 특성들이 명시될 수 있으며, 이는 목적어들이 취할 수 있는 값들을 포함할 수 있다.

OWL(web ontology language)는 웹에 대해 보다 표현력이 있는 온톨로지들을 구축하는데 사용될 수 있는 추가 리소스들로 RDFS 어휘를 확장한다. OWL은 처리 및 추론을 보다 계산적으로 실현가능하게 하기 위해 RDF 문서들의 구조와 콘텐츠에 관한 추가적인 제약들을 도입한다. 예를 들어, OWL은 표준 집합 연산자들: 부울리언 조합들(Boolean combinations)의 클래스들을 정의하기 위한 교집합, 합집합, 및 여집합에 대응하는 특성들을 정의한다. 도 2는 개념 Father를 정의하는데 교집합을 사용하는 예를 도시한다. Father는 정확히 클래스들 Parent와 Male의 교집합이다. 달리 말하면, Father인 누군가는 Parent 및 Male 양쪽 모두이며, Parent 및 Male 양쪽 모두인 누군가는 Father이다. 언뜻 보기에는, OWL은 Father is rdfs:subClassOf Parent라는 것 및 Father is rdfs:subclassOf Male이라는 것과 등가인 것처럼 보일 수 있다. 그러나, 이러한 2개의 subClassOf 문장들은 모든 아버지들이 부모이고 남성이어야 한다고 진술할 뿐이다. 그것들은, owl:intersectionOf를 이용하여 행해질 수 있는 바와 같이, 누군가가 그들의 성별 및 친자관계로부터만 아버지라고 추론하는데 사용될 수 없다.

OWL은 RDF와 RDFS, XML 스키마 데이터타입들, 및 OWL 네임스페이스들을 사용한다. OWL 어휘 자체는 네임스페이스 http://www.w3.org/2002/07/owl#에서 정의되고, 프리픽스 owl에 의해 통상적으로 참조된다. 데이터타입들은 URI들을 사용하여 식별되는 데이터 값들의 범위들을 나타낸다. OWL은 여러분이 다수의 미리 정의된 데이터타입들을 사용하게 하며, 이들 대부분은 XSD(XML Schema Definition)에서 정의된다. OWL은 사용자가 XSD를 확장함으로써 그 자신의 데이터 타입들을 정의하게 한다.

RDF 데이터는 3종 스토어 프레임워크를 사용하여 저장되고 쿼리될 수 있다. 3종 스토어는 RDF 그래프들의 영구 저장 및 액세스를 위한 메커니즘을 제공한다. 기존 3종 스토어 구현들의 몇몇 예들은 Jena와 Sesame이다. Jena(https://jena.apache.org/)는 시맨틱 웹 애플리케이션들을 구축하기 위한 자바 프레임워크이다. Jena는 RDF 및 OWL과 같은 시맨틱 웹 빌딩 블록들을 다루기 위한 API들(application programming interfaces)을 구현한다. Jena의 사용자들에 대한 기본 클래스는 Model이며, 이는 RDF 3종들의 집합을 다루기 위한 API이다. Model은 파일 시스템으로부터 또는 원격 파일로부터 생성될 수 있다. Sesame(http://rdf4j.org/)은 RDF 데이터의 저장, 추론, 및 쿼리를 위한 오픈 소스 프레임워크이다. Sesame은 Jena의 특징들을 접속 API의 가용성, 추론 지원, 웹 서버의 가용성 및 SPARQL 엔드포인트와 매칭시킨다.

시맨틱 및 M2M 아키텍처의 이러한 배경으로, 시맨틱이 M2M 아키텍처 내에서 어떻게 작용할 것인지 결정할 필요성이 존재한다.

시맨틱 인식의 결핍은 M2M 애플리케이션들에 의해 생성되는 데이터가 M2M 서비스 레이어에 의해 효과적으로 추상화되거나 가상화되게 하는 서비스들을 M2M 서비스 레이어들이 제공하는 것을 방지하여, 그들이 데이터가 유래된 애플리케이션의 사전 지식을 전혀 갖지 않더라도 이것은 다른 애플리케이션들에 의해 발견, 액세스, 해석 및 공유될 수 있다.

"정상 리소스들의 시맨틱(semantics of normal resources)"(이하 리소스 시맨틱)에 주석을 달고 이를 저장하는데 사용될 수 있는 방법들, 시스템들, 및 디바이스들이 본 명세서에 개시된다. 이러한 방법들, 시스템들, 및 디바이스들은 시맨틱 지원을 위한 기능적 아키텍처의 일부일 수 있고 시맨틱 기반 쿼리를 고려할 수 있다. 다수 리소스들에 대한 단일 주석의 사용 및 주석 대상으로부터 먼 주석들의 저장을 용이하게 하는 방식들이 개시된다. 또한, 본 명세서에서는, 다른 것들 중에서, 시맨틱 정보를 표현하는 것을 돕는데 시맨틱 자식 리소스를 사용하는 방법들, 시스템들, 및 디바이스들이 논의된다.

예에서, 디바이스는 프로세서 및 이러한 프로세서와 연결되는 메모리를 포함할 수 있다. 이러한 메모리는, 프로세서에 의해 실행될 때, 프로세서로 하여금, 리소스의 시맨틱 주석 인스턴스를 자동으로 생성하는 단계 및 요청에 기초하여 시맨틱 주석 인스턴스를 클라이언트에 제공하는 단계를 포함하는 동작들을 달성하게 하는 실행가능 명령어들을 포함한다.

본 내용은 아래 상세한 설명에서 추가로 설명되는 개념들의 선택을 간략화된 형태로 소개하도록 제공된다. 본 내용은 청구 대상의 주요한 특징들 또는 필수 특징들을 식별하고자 의도되는 것이 아니며, 청구 대상의 범위를 제한하는데 사용되고자 의도되는 것도 아니다. 또한, 청구 대상은 본 개시내용의 임의의 부분에서 언급되는 임의의 또는 모든 단점들을 해결하는 제한사항들에 제한되는 것은 아니다.

첨부 도면들과 연계하여 예에 의거하여 주어지는 이하의 설명으로부터 보다 상세한 이해를 가질 수 있을 것이다.
도 1은 RDF를 사용하는 시맨틱 예를 도시한다.
도 2는 owl:intersection의 예를 도시한다.
도 3은 예시적인 oneM2M 아키텍처를 도시한다.
도 4는 예시적인 oneM2M 공통 서비스 기능들을 도시한다.
도 5는 예시적인 oneM2M 서비스들 아키텍처를 도시한다.
도 6은 체육관의 정황에서의 사용 사례를 도시한다.
도 7은 체육관 사용 사례에 대해 그래프로 표현되는 시맨틱 정보를 도시한다.
도 8은 M2M 시맨틱 지원의 예시적인 기능적 아키텍처를 도시한다.
도 9는 시맨틱 저장소의 예시적인 아키텍처를 도시한다.
도 10은 예시적인 M2M 리소스 계층을 도시한다.
도 11은 쳬육관 사용 사례에서의 시맨틱 자식 리소스의 예를 도시한다.
도 12는 시맨틱 주석 인스턴스 생성의 예시적인 메시지 흐름을 도시한다.
도 13은 BSR에서의 시맨틱 주석 인스턴스들의 예시적인 계층을 도시한다.
도 14는 클라이언트의 요청에 의해 트리거되는 시맨틱 주석의 예시적인 메시지 흐름을 도시한다.
도 15는 클라이언트의 요청에 의해 트리거되는 시맨틱 주석의 예시적인 방법을 도시한다.
도 16은 예시적인 메시지 흐름 시맨틱 주석 인스턴스 업데이트를 도시한다 - 사례 1.
도 17은 예시적인 메시지 흐름 시맨틱 주석 인스턴스 업데이트를 도시한다 - 사례 2.
도 18은 예시적인 메시지 흐름 시맨틱 주석 인스턴스 업데이트를 도시한다 - 사례 3.
도 19는 시맨틱 주석 인스턴스 마이그레이션을 위한 예시적인 방법을 도시한다.
도 20은 시맨틱 주석 인스턴스 발견 요청의 메시지 흐름을 도시한다.
도 21은 <semantics>의 예시적인 리소스 구조를 도시한다.
도 22는 쳬육관 사용 사례에서의 시맨틱 자식 리소스의 예이다.
도 23은 <semantics>의 예시적인 대안적 리소스 구조를 도시한다.
도 24는 <relationDouble>의 예시적인 리소스 구조를 도시한다.
도 25는 쳬육관 사용 사례에서의 시맨틱 자식 리소스의 예를 도시한다.
도 26은 <SD> 리소스의 예시적인 자식 리소스들을 도시한다.
도 27은 예시적인 <annotation> 리소스를 도시한다.
도 28은 시맨틱 주석 인스턴스 표현의 예를 도시한다.
도 29는 예시적인 oneM2M 시맨틱 주석 CSF를 도시한다.
도 30은 예시적인 oneM2M 서비스 컴포넌트 아키텍처를 도시한다.
도 31은 시맨틱 주석 인스턴스와 리소스(예를 들어, 주석 대상) 사이의 예시적인 관계 또는 관련성을 도시한다.
도 32a는 하나 이상의 개시되는 실시예들이 구현될 수 있는 예시적인 M2M(machine-to-machine) 또는 IoT(Internet of Things) 통신 시스템의 시스템 도면이다.
도 32b는 도 32a에 도시되는 M2M/IoT 통신 시스템 내에서 사용될 수 있는 예시적인 아키텍처의 시스템 도면이다.
도 32c는 도 32a에 도시되는 통신 시스템 내에서 사용될 수 있는 예시적인 M2M/IoT 단말 또는 게이트웨이 디바이스의 시스템 도면이다. 및
도 32d는 도 32a의 통신 시스템의 양상들이 구현될 수 있는 예시적인 컴퓨팅 시스템의 블록도이다.

종래의 M2M(machine-to-machine) 시스템들에서, M2M 애플리케이션들(백엔드 네트워크 서버들뿐만 아니라 최종 디바이스들 상에 호스팅됨)은 교환된 데이터의 공통 정의에 대해 사전에 합의할 필요가 있다. 이것은 주로 애플리케이션들을 대신하여 M2M 데이터를 파싱하거나, 해석하거나 또는 처리할 수 있는 시맨틱 인식 M2M 서비스 레이어들의 결핍으로 인한 것이다. 종래의 M2M 시스템들에서, M2M 서비스 레이어들은 시맨틱 인식 능력들이 결핍되어 있고, 따라서 M2M 서비스 레이어들을 통해 흐르거나 이러한 서비스 레이어들 내에 저장되는 데이터는 불투명 정보(opaque information)로서 취급된다.

이러한 시맨틱 인식의 결핍은 M2M 애플리케이션들에 의해 생성되는 데이터가 M2M 서비스 레이어에 의해 효과적으로 추상화되거나 가상화되게 하는 서비스들을 M2M 서비스 레이어들이 제공하는 것을 방지하여, 그들이 데이터가 유래된 애플리케이션의 사전 지식을 전혀 갖지 않더라도 이것은 다른 애플리케이션들에 의해 발견, 액세스, 해석 및 공유될 수 있다. 결과적으로, 감지 및 작동되는 물리 엔티티들(예를 들어, 가전기기들, 사람들, 자동차들, 빌딩의 룸들 등)은 M2M 서비스 레이어들에 의해 효과적으로 가상화/추상화되지 않을 수 있고, 물리 엔티티들은 환경에 내재된 일반 엔티티들로서 취급되며, 구체적인 M2M 애플리케이션에 얽매이지는 않는다. 이러한 제한을 극복하기 위해서, M2M 시스템들에서 송신되는 데이터는 시맨틱 정보와 관련되고 통합될 수 있어, 시맨틱 인식 M2M 서비스 레이어들이 이 데이터에 대하여 M2M 애플리케이션들과 동일한 지식을 가질 수 있다. 그렇게 함으로써, M2M 서비스 레이어들은 애플리케이션들에 걸쳐 데이터의 공유를 더 우수하게 용이하게 하며, M2M 애플리케이션들에 대해 부가 가치 시맨틱 인식 서비스들(예를 들어, 상이한 애플리케이션들 사이의 데이터 공유, 데이터 종합 등)을 제공할 수 있다.

예를 들어, 환자 모니터링 애플리케이션에서, 환자의 바이탈 사인들(예를 들어, 혈압, 체온, 산소, 심박수 등)을 모니터링하는 무선 센서 디바이스들 각각 상에 호스팅되는 별개의 애플리케이션들이 존재할 수 있다. 마찬가지로, 이러한 정보를 사용할 수 있는 네트워크에서 호스팅되는 별개의 애플리케이션들(예를 들어, 환자의 의사, 개인 트레이너, 가족 구성원들, 구급차 의료 보조자 등과 관련되는 애플리케이션들)이 존재할 수 있다. 그러나, 무선 센서 디바이스들 각각으로부터의 M2M 시맨틱 인식 서비스들 데이터가 없으면, 네트워크 애플리케이션들은, 네트워크 애플리케이션들이 무선 센서 디바이스들 상에 호스팅되는 애플리케이션들 및 그들이 생성하는 정보의 타입(예를 들어, 위치/어드레스, 데이터의 단위들, 데이터의 컨텍스트 등)에 대한 사전 지식을 갖지 않으면, 디바이스 애플리케이션들로부터의 정보를 발견하고, 공유하며 이해하는데 어려움이 있을 수 있다.

"정상 리소스들의 시맨틱(semantics of normal resources)"(이하 리소스 시맨틱)에 주석을 달고 이를 저장하는데 사용될 수 있는 방법들, 시스템들, 및 디바이스들이 본 명세서에 개시된다. 이러한 방법들, 시스템들, 및 디바이스들은 시맨틱 지원을 위한 기능적 아키텍처의 일부일 수 있고 시맨틱 기반 쿼리를 고려할 수 있다. 또한, 본 명세서에서는, 시맨틱 정보를 표현하는 것을 돕는데 시맨틱 자식 리소스를 사용하는 방법들, 시스템들, 및 디바이스들이 논의된다. 설명적 형용사가 없는 "리소스들(resources)"은 본 명세서에 논의되는 "정상 리소스들(normal resources)"과 동일하다. "정상 리소스" 또는 "리소스"는 아래 표 1에서의 열 1에서 리소스 타입 아래에 보여지는 바와 같이(예를 들어, AE, container, contentInstance 등) oneM2M에서의 리소스 트리와 같은 리소스 저장소에 저장되는 리소스이다.

이하는 oneM2M RESTful 아키텍처에 따른 추가적인 컨텍스트이다. CSF들(Capability service functions)은 "리소스들"의 집합으로서 표현된다. 리소스는 oneM2M 아키텍처에서 고유하게 어드레싱 가능한 엔티티이다. 리소스는 CRUD(Create, Retrieve, Update, 및 Delete)와 같은 RESTful 방법들을 통해 조작되고 전달될 수 있는 표현을 가지며, URI(uniform resource identifier)를 사용하여 어드레싱된다. 리소스는 자식 리소스(들) 및 속성(들)을 포함할 수 있다. 자식 리소스는 부모 리소스와 포함 관계(containment relationship)를 갖는 리소스이다. 부모 리소스 표현은 자신의 자식 리소스(들)에 대한 참조들을 포함한다. 자식 리소스의 수명은 부모의 리소스 수명에 의해 제한될 수 있다. 각각의 리소스는 리소스의 정보를 저장하는 "속성들"의 집합을 지원한다.

표 1은 oneM2M-TS-0001 oneM2M Functional Architecture-V-1.1.0에서 논의되는 바와 같이 정의되는 리소스 타입들 및 관련 자식 또는 부모 리소스 타입들의 예들을 제공한다.

리소스 발견 프로시저들은 CSE에 존재하는 리소스들의 발견을 허용한다. filterCriteria 파라미터의 사용은 결과들의 범위를 제한하는 것을 허용한다. 리소스 발견은 발견이 시작된 근원을 또한 포함하는 발신자에 의해 RETRIEVE 방법을 사용하여 달성될 수 있다(예를 들어, <CSEBase>). 리소스 발견 프로시저의 필터링되지 않은 결과는 발견이 시작된 근원 아래의 자식 리소스들을 포함하고, 이는 발신자(예를 들어, 발견 요청 전송자)가 발견 액세스 권한을 갖고 있는 것이다. 발견 액세스 권한은 요청자/요청 전송자가 그 CSE 상의 리소스들을 발견할 액세스 권한을 갖는 것이다.

필터 기준 조건들은 RETRIEVE 방법에 파라미터들로서 제공될 수 있다. 필터 기준 조건들은 리소스 발견에 대한 규칙들(예를 들어, 리소스 타입들, 생성 시간, 또는 매칭 문자열)을 설명한다. 필터 기준은 답변의 최대 크기(상한)을 명시하기 위한, 및/또는 탐색 결과가 어떤 순서로 정리되어야 하는지 명시하는 기준을 정렬하기 위한 파라미터들을 또한 포함할 수 있다. 표 2는 filterCriteria 파라미터를 설명하며, 이는 시맨틱 주석에 관하여 이하 보다 상세히 논의된다.

구성된 필터 기준 조건들에 리소스가 매칭되고 발신자가 리소스에 대한 발견 액세스 권한을 가질 때 매칭이 일어난다. 성공적 응답은 매칭된 리소스들에 대한 리스트를 포함할 수 있다.

도 6은 체육관의 정황에서의 사용 사례를 도시한다. 도 6에 도시되는 체육관의 사용 사례에서는, 체육관의 양쪽 바닥 상에 배치되는 상이한 디바이스들, 예를 들어, 주변 온도/습도 등을 감지하기 위한 주위 센서(734), 체육관 사용자들이 운동하기 위한 트레드밀(737), 저울(736) 및 체육관 사용자들이 그들의 바이탈들을 기록하기 위한 혈압 모니터(735)가 존재한다. 일부 배치들에서 각각의 디바이스는 동일한 바닥 상에 위치되는 게이트웨이(예를 들어, 게이트웨이(731) 또는 게이트웨이(733)) 또는 일부 다른 타입의 관련물에 등록할 수 있다. 각각의 디바이스에 관련되는 리소스들(예를 들어, 애플리케이션 리소스) 및 각각의 디바이스에 의해 생성되고 보고되는 데이터 리소스들이 리소스 저장소에 저장될 수 있다. 시맨틱 지원의 기능들은 게이트웨이(731) 또는 게이트웨이(733)와 같은 하나 이상의 게이트웨이들 상에 호스팅될 수 있다.

(예를 들어, oneM2M-TS-0001 oneM2M Functional Architecture-V-1.1.0에서 정의되는) 종래의 M2M 서비스 레이어 메커니즘들은 표 2에 설명되는 필터 기준에 기초하여 리소스 발견을 허용한다. 그러나, 보다 진보된 리소스 쿼리가 요구될 수 있다. 체육관 사용 사례에서, 체육관 사용자는 특정 시간대에 특정 제조사, 연도 및 가용성의 것인 트레드밀(737)을 발견하기를 원할 수 있다. 종래의 발견 메커니즘은 이러한 진보된 리소스 쿼리를 달성하는 것이 불가능할 수 있다. 그러나 시맨틱 기반의 쿼리는, 본 명세서에 개시되는 바와 같이, 그 스키마가 데이터의 일부인 데이터에 대한 분석적 쿼리 동작들의 집합을 제공할 수 있다. 시맨틱 기반의 쿼리를 실현하기 위해, 리소스 시맨틱은 주석이 달린다. 본 개시내용의 정황에서, 시맨틱 주석은 쿼리 및 다른 진보된 동작들에 대해 이용 가능하게 될 수 있는 리소스의 시맨틱을 추가하고 표현하는 것으로서 정의될 수 있다. 시맨틱 저장소는 반드시 리소스들에 대해서는 아니지만 시맨틱에 대해 특히 중앙집권형 위치로 고려될 수 있다. 이러한 관계 및 값 정보는 리소스와 함께 그 시맨틱 자식 리소스에 저장될 수 있어, 이러한 정보는 추출되어 시맨틱 저장소에 넣어질 수 있다. 시맨틱 주석 인스턴스들은 시맨틱 저장소에 저장되며, 이는 3종들의 집합을 포함한다. 리소스 시맨틱은 리소스의 시맨틱 자식 리소스에 저장된다.

도 7은 도 6의 쳬육관 사용 사례와 관련된 예시적인 추상화를 도시한다. 리소스의 시맨틱은 리소스, 관계, 및 값으로 구성되는 리소스-관계-값 3종에 의해 설명될 수 있다. 값들은 클래스들 또는 다른 리소스들일 수 있다. 클래스는 정상 리소스들의 집합을 나타낸다. 클래스는 URI/URL에 의해 식별될 수 있다. 클래스는 온톨로지를 구성한다. 관계는 "작성자(created by)", "수명(lifetime)", "가입자(subscribed by)"등과 같이 리소스들 사이의 관계를 설명한다. 관계는 URI/URL에 의해 식별될 수 있다. 이것은 온톨로지를 구성하는 기본 요소들 중 하나이다. 도 7에 도시되는 체육관 사용 사례에서의 리소스-관계-값 3종의 예들은 표 3에 나열된다. 예를 들어 표 3에서, 리소스 = <treadmillAE>, 관계 = locatedIn, 및 값 = treadmill이다. treamdmillAE는 트레드밀 디바이스로부터 CSE에 등록된다. 이 3종은 등록시 표시되며, 시맨틱 자식 리소스로 표현되지 않는다. 그래서 도 22는 이러한 3종을 포함하지 않는다. 물리 엔티티들은 사람, 체육관, 또는 배치된 디바이스들(예를 들어, 게이트웨이, 트레드밀, 주변 센서, 혈압 모니터, 또는 체중계)이다. 체육관에서, 게이트웨이(731) 및 게이트웨이(732)는 체육관 CSE(common service entity)를 호스팅할 수 있다. 달리 말해서, 게이트웨이는 체육관 CSE로 추상화된다. 유사하게, 트레드밀은 treadmillAE로 추상화된다. 도 7에서의 엔티티들은 oneM2M에서 정의되는 리소스 타입들을 이용할 수 있다.

이하는 시맨틱 주석의 구현에 관한 세부 사항뿐만 아니라 M2M 시맨틱 지원을 위한 기능적 아키텍처에 대한 검토이다. 도 8은 M2M 시맨틱 지원을 위한 예시적인 기능적 아키텍처를 도시한다. 이하 보다 상세히 논의되는, 블록 701에서의 예시적인 시맨틱 아키텍처의 컴포넌트들은 기능적으로 리소스 저장소(710), 온톨로지 프로세서(705), 온톨로지 저장소(706), 시맨틱 저장소(720), 규칙 저장소(707), 추론기(704) 또는 시맨틱 쿼리 프로세서(702)를 포함할 수 있다. 블록 701 또는 그 컴포넌트들은 독립형 디바이스(예를 들어, 1 차적 시맨틱 기능을 갖는 디바이스)이거나 다른 디바이스 (예를 들어, 게이트웨이(731))에 통합 될 수 있다. 블록 701은 클라이언트 디바이스(703), 온톨로지 공표(또는 요청) 디바이스(700), 또는 M2M 애플리케이션들을 갖거나 다른 방식으로 이와 상호 작용하는 다른 디바이스(708)와 통신 가능하게 접속될 수 있다.

리소스 저장소(710)는 M2M 디바이스들로부터 수집되는 리소스들 및 M2M 애플리케이션들에 관련된 개인들, 디바이스들 등과 관련된 프로파일들(정상 리소스들)과 같은 M2M 애플리케이션들에 관련된 임의의 리소스들을 저장한다. M2M 시맨틱 지원은 리소스들에 대한 진보된 처리(예를 들어, 시맨틱 쿼리, 데이터 분석 등) 뿐만 아니라 이들의 보편적인 이해/해석을 위해 리소스들에 대한 시맨틱을 가능하게 할 수 있다.

온톨로지 프로세서(705)는 M2M 도메인의 외부 및 내부에 공표되거나 생성된 온톨로지들의 발견 기능을 처리, 분류, 저장, 및 제공하는 것을 담당한다. 온톨로지 저장소(706)는 클래스들 및 관계들의 기본 요소로 구성된 온톨로지들을 저장한다. 이러한 온톨로지들은 정상 리소스가 시맨틱을 가능하게 하는데 사용된다. 온톨로지 저장소는 시맨틱 노드에 대한 다른 용어로 고려될 수 있다. 도메인은 아이덴티티들을 살펴보는 아이덴티티 공간으로 고려될 수 있다. 식별자는 상이한 공간들에서 동일하게 보일지라도 고유할 수 있다. 본 명세서의 정황에서, 도메인은 상이한 버티컬들, 애플리케이션들 등과 같은 상이한 엔티티들에 의해 정의되는 클래스들 및 관계들을 살펴보는데 사용될 수 있어, 그들의 명칭들이 상이한 도메인들에서 동일하게 보일지라도 그들의 정의들은 동일한 도메인에서 고유할 것이다.

시맨틱 저장소(720)는 주석이 달린 시맨틱 정보를 특정 표현들에 저장하며, 이는 RDF를 이용하는 옵션을 가질 수 있다.

규칙 저장소(707)는 종종 리소스 저장소(710)에서의 리소스들과 관련되는 기존의 시맨틱을 넘어서는 새로운 지식을 표현하는데 사용되는 규칙들을 저장한다. 규칙들은 통상적으로 조건문(예를 들어, if-then 절)이다.

추론기(704)는 규칙 저장소(710)로부터의 입력 및 시맨틱 저장소(720)에서의 기존의 리소스 시맨틱 정보를 취하여, 규칙들에서의 조건들이 충족되면 새로운 리소스 시맨틱 정보를 생성한다. 새로운 리소스 시맨틱 정보는 시맨틱 저장소(720)에 추가된다.

시맨틱 쿼리 프로세서(702)는 시맨틱 저장소(720)에 저장되는 리소스 시맨틱 정보를 탐색하기 위한 클라이언트들로부터의 쿼리를 취급하고, 그 결과를 클라이언트 디바이스(703)에 반환할 수 있다. 클라이언트는 본 개시내용의 정황에서 시맨틱 주석 요청 또는 시맨틱 주석 인스턴스 발견 요청을 SAP에 전송할 수 있다.

도 9는 시맨틱 주석에 대한 예시적인 기능적 아키텍처를 도시한다. 시맨틱 주석은, 예에서 RR(resource repository)(710)로부터의 리소스들의 URI 및 그것의 대응하는 시맨틱 자식 리소스에서의 관계-값 2종으로 구성되는 3종을 초래할 수 있다. 3종의 집합은 시맨틱 저장소(720)에 저장되며, 이는 시맨틱 주석 인스턴스라 불리운다. 도 9에 도시되는 바와 같이, 시맨틱 저장소(720)는 SAP(semantics annotation processor)(721), BSR(base semantics repository)(722), 및 TSR(transit semantics repository)(723)로 구성될 수 있으며, 이들은 본 명세서에서 보다 상세히 논의될 것이다. 각각의 시맨틱 주석 인스턴스는 그 시맨틱 정보가 시맨틱 주석 인스턴스에 포함되는 리소스들의 리스트와 대응한다. 각각의 시맨틱 주석 인스턴스는 그것과 관련된 식별자(예를 들어, 알파벳, 숫자, 또는 영숫자일 수 있는 코드)를 가질 수 있다.

시맨틱 저장소(720) 및 리소스 저장소(710)가 물리적으로 분리될 필요는 없다. 이들은 상이한 정보를 저장할 수 있기 때문에, 기능적으로 상이할 수 있다. 시맨틱 저장소(720)는 리소스 저장소(710)에 포함되는 리소스와 관련된 3종을 저장할 수 있는 반면, 리소스 저장소(710)는 리소스들을 저장한다. 구현 관점에서, 리소스 저장소(710)는 관계형 데이터베이스로서 구현될 수 있다. 시맨틱 저장소(720)는, 다른 것들 중에서, 3종 스토어 또는 그래프 스토어로서 구현될 수 있다. 시맨틱 저장소(720)는, Jena 또는 Sesame 같은, 종래의 3종 스토어 구현들을 이용하여, 시맨틱 주석 인스턴스를 저장할 수 있다.

SAP(721)는 시맨틱 주석 인스턴스들을 생성하거나 업데이트하는 것을 포함하는 다수의 책임들을 가질 수 있다. 제1 시나리오에서, SAP(721)는 리소스 저장소(710)에서의 각각의 리소스에 대해 자동으로 시맨틱 주석 인스턴스들을 생성할 수 있다. 제2 시나리오에서, SAP(721)는 클라이언트(703) (도 8), 또는 다른 디바이스로부터의 시맨틱 주석 요청들에 기초하여 시맨틱 주석 인스턴스들을 생성할 수 있다. SAP(721)는, 다른 것들 중에서, 그것이 리소스 계층(계층은 이하 보다 상세히 논의됨)에서의 어떤 레이어에 대해 주석을 수행하고 있는지에 기초하여, 클라이언트(703)로부터의 요청에서의 명령어 또는 요청의 타입에 기초하여, 요청이 유래되는 디바이스의 타입에 기초하여, 어떤 리소스들이 리소스 저장소(710)로부터 주석을 달지 결정할 수 있다.

시맨틱 주석 인스턴스는 리소스-관계-값 3종에서의 그 시맨틱이 이러한 시맨틱 주석 인스턴스들에 포함되는 리소스들과 관련된다. SAP(721)는, 표 4에 보여지는 바와 같이, 시맨틱 주석 인스턴스 대 리소스 관련 형태를 유지한다. 따라서 각각의 시맨틱 주석 인스턴스는 리소스 저장소(710)의 리소스들의 URI들에 매핑된다. 리소스 저장소(710)는, 도 10에 도시되는 바와 같이, M2M 리소스들을 계층적 방식으로 저장할 수 있으며, 이는 표 1에 관하여 논의된 바와 같이 부모 및 자식 리소스들과 관련될 수 있다. 이러한 계층 구조는 표 4의 "포함되는 리소스(contained resource)" 필드가 리소스-관계-값 3종 등이 시맨틱 주석 인스턴스에 포함되는 모든 리소스들의 URI들을 나열할 필요가 없는 상황들을 고려할 수 있다. 리소스들 중 일부가 동일한 계층 구조 아래에 있고, 이들이 그 계층 아래의 유일한 리소스들이면, 이러한 리소스들을 표현하는데 그 계층의 부모 URI가 사용될 수 있다. 달리 말하면, 모든 자식 리소스들이 동일한 인스턴스에서 주석이 달리면, 부모 URI는 시맨틱 주석 인스턴스와 관련되도록 명시될 수 있다. 예로서: 컨테이너가 2개의 인스턴스들만을 갖는 경우(예를 들어, /<container>/<inst1>, /<container>/<inst2>의 URI들이 있음). 이러한 2개의 리소스들이 시맨틱 주석 인스턴스에서 설명되면, 그 대응하여 포함되는 리소스 필드는, 2개의 개별 URI들 대신에, /<container>/로서 작성될 수 있다.

SAP(721)는 또한, 표 5에 도시되는 바와 같이, 역 관련 형태(리소스 대 시맨틱 주석 인스턴스 관련 형태)를 유지할 수 있다. 표 5의 형태의 사용은 SAP(721)가 관련 시맨틱 주석 인스턴스를 찾아 리소스의 시맨틱 정보가 변경될 때 관련 시맨틱 주석 인스턴스들을 주기적으로 업데이트하게 할 수 있다. 변경의 통지가 즉시 전송되는 대신에, 하나 이상의 변경들(예를 들어, 누적 업데이트)에 관한 정보가 주기적으로 전송될 수 있다. 예를 들어, SAP(721)는 주기적으로(예를 들어, 구현의 타입에 따라 1분, 1일 또는 1주마다) 리소스 저장소(710)에게 리소스 대 시맨틱 주석 인스턴스 관련을 통지할 수 있다. 또한 SAP(721)는 관련 관계가 생성, 업데이트 또는 삭제될 때 리소스 저장소(710)에게 리소스 대 시맨틱 주석 인스턴스 관련을 통지할 수 있다. 예에서, 리소스 저장소(710)는, annotationInst 속성(본 명세서에서보다 상세히 논의됨)과 같은, 시맨틱 주석을 갖는 oneM2M에서의 리소스들에 대한 속성을 통해 리소스 자체와 함께 저장된 전술된 관련 관계를 가질 수 있다.

표 4 및 표 5의 사용을 더 설명하기 위해, 도 11이 이제 참조된다. 여기서, 시맨틱 주석 인스턴스의 식별자는, 다음 리소스들의 3종을 포함하는, treadmillAnnotation이라고 가정하자:

/gymCSE1F/treadmillAE/trainingContainer/contInst1; 및

/gymCSE1F/treadmillAE/trainingContainer/contInst2.

다음으로 시맨틱 주석 인스턴스 대 리소스 관련 형태는 표 6에 보여지는 바와 같이 추가되는 시맨틱 주석 인스턴스 엔트리를 가질 것이다(표 4에 관련됨). 리소스 대 시맨틱 주석 인스턴스 관련 형태는 표 7에 보여지는 바와 같이 리소스들 각각에 대해 추가되는 2개의 엔트리들을 가질 것이다(표 5에 관련됨). 이러한 리소스들은 도 11에 도시되는 바와 동일한 시맨틱 2종을 갖기 때문에 표 6은 간략화될 수 있다. 표 6은 표 8에 보여지는 것으로 간략화된다. 표 7은 동일하게 유지된다.

도 12는 시맨틱 주석 인스턴스 생성의 예시적인 메시지 흐름을 도시한다. 블록 741에서, SAP(721)는 주석이 달릴 RR(710)에서의 리소스들을 결정한다. 이러한 리소스는, 다른 것들 중에서, 그것이 리소스 계층에서의 어떤 레이어에 대해 주석을 수행하고 있는지에 기초하여, 또는 클라이언트의 요청들에 기초하여 결정될 수 있다. 블록 742에서, SAP(721)는 대응하는 리소스들의 시맨틱 자식 리소스 표현을 검색한다. 블록 743에서, SAP(721)는 시맨틱 자식 리소스들로부터 3종을 생성하며, 이는 본 명세서에 설명되는 시맨틱 주석을 위한 방법에 따라 행해질 수 있다. 또한, SAP(721)는 생성된 3종을 시맨틱 주석 인스턴스로 조합한다. 블록 744에서, SAP(721)는 시맨틱 주석 인스턴스 대 리소스 관련 레코드들 및 광고들을 표 4에 보여지는 형태로 생성한다. SAP(721)는 또한 표 5에 보여지는 리소스 대 시맨틱 주석 인스턴스 관련 레코드를 생성하거나 또는 업데이트한다. 블록 745에서, SAP(721)는 표 4에 보여지는 바와 같은 포맷으로 시맨틱 주석 인스턴스 및 리소스 관련의 레코드를 RR(710)에 전송한다. 블록 746에서, RR(710)은 레코드로부터 관련 정보를 추출하고, 관련 리소스(들)와 함께 시맨틱 주석 인스턴스 식별자를, 예를 들어, 리소스(들)의 속성에 저장한다.

리소스 저장소(710)의 각각의 리소스에 대해 하나 이상의 시맨틱 주석 인스턴스들을 자동으로 생성하는 SAP(721)에 관한 제1 시나리오(위에 논의되었음)가 이하 논의된다. 이러한 예에서는, 리소스 계층에서 생성되는 새로운 레이어가 존재한다는 점을 리소스 저장소(710)가 SAP(721)에 통지하면, SAP(721)는 새 레이어 아래의 모든 리소스들의 시맨틱에 주석을 달 수 있다. 기존 레이어에서 리소스들이 추가, 삭제, 또는 업데이트되면, 대응하는 시맨틱 주석 인스턴스들이 마찬가지로 SAP(721)에 의해 업데이트될 수 있다. 이러한 제1 시나리오에서, 리소스 저장소(710)는 oneM2M이 정의하는 바와 같은 계층 구조를 가질 수 있다(예를 들어, 표 1 및 도 10). SAP(721)는 각각의 레이어에 대해 시맨틱 주석 인스턴스를 생성할 수 있다. 본 명세서에 논의되는 바와 같은 oneM2M 리소스 구조 구현에서, SAP는 <CSEBase>, <AE>, <container> 등과 같은 리소스들의 시맨틱에 주석을 달 수 있다. 다음은 시맨틱 자식 리소스가 이들에 추가되면 시맨틱 정보를 가능하게 할 수 있는 리소스들의 예시적인 리스트이다: <CSEBase>, <remoteCSE>, <AE>, <container>, <contentInstance>, <group> 및 <node>.

이러한 제1 시나리오에서, 생성된 시맨틱 주석 인스턴스들은 BSR(722)에 저장될 수 있다. 여기서, BSR(722)에서의 시맨틱 주석 인스턴스들은, 표 1에서 제공되는 바와 같이, 대응하는 리소스들과 유사한 계층 관계를 물려받는다. 도 13은 제1 시나리오에 대한 BSR(722) 상의 시맨틱 주석 인스턴스들의 계층의 예시도이다. 각각의 시맨틱 주석 인스턴스는 시맨틱 저장소(720)에서 고유한 식별자를 가질 수 있다. BSR(722)에서의 시맨틱 주석 인스턴스에 대해, 식별자는 일부 랜덤 기증을 갖는 레이어의 부모 리소스의 명칭처럼 보일 수 있다. 도 13에 도시되는 바와 같이, CSEBase 레이어의 시맨틱 주석 인스턴스는 CSEbaseSAI(751)이다. CSEBaseSAI(751)는 CSEBase 레이어의 시맨틱 주석 인스턴스를 나타내며, 유사하게 remoteCSE 레이어에 대해서는 remoteCSESAI(752), AE에 대해서는 AESAI(753), container에 대해서는 containerSAI(757), container에 대한 contentInstance containerSAI(754)에 대해서는 contentinstanceSAI(758), group에 대해서는 groupSAI(755), node에 대해서는 nodeSAI(756) 등이다. 과잉인 3종이 주석 인스턴스들에 저장될 가능성이 있을 수 있다. 예를 들어, CSEBaseSAI는 CSEBase 아래의 리소스들에 대한 모든 3종을 포함할 수 있으며, AESAI는 CSEBaseSAI에 저장된 3종의 일부에 과잉일 수 있는 AE 아래의 리소스들에 대한 모든 3종을 포함할 수 있다. CSEBaseSAI를 모든 그 서브 주석 인스턴스에 링크하는 것은 SR(720) 상의 저장 공간을 절약할 수 있다. 예를 들어, 시맨틱 기반의 쿼리가 CSEBaseSAI로 살펴지면, CSEBaseSAI 아래의 모든 3종은 CSEBaseSAI의 이러한 3종 플러스 이러한 계층에서의 CSEBaseSAI 레이어 아래의 모든 3종들이며, 이는 탐색될 것이다. 전술된 예들을 더욱 설명하는데 도 28을 사용하면, CSEBaseSAI(751)는 도 28에 도시되는 바와 같은 모든 정보(3종)를 포함할 수 있다. 이러한 정보는 각각의 AESAI들(예를 들어, 도 28의 treadmill1, treadmill2 등)에서 다시 반복될 수 있다. 대안적으로, AESAI들로의 링크들이 CSEBaseSAI(751)에 저장될 수 있고, 상세 정보(3종)는 각각의 AESAI에 포함될 수 있다.

계속해서 도 13 및 제1 시나리오를 참조하면, 리프 시맨틱 주석 인스턴스에 대해, 리소스는 시맨틱 정보를 갖는 자식 리소스들을 전혀 가지지 않기 때문에, 이것은 리소스 자체의 시맨틱 주석을 포함한다. 예로서, <contentInstance> 리소스의 시맨틱 주석 인스턴스(예를 들어, contentInstanceSAI(758))는 리소스 자체의 3종을 포함할 수 있다.

비-리프 시맨틱 주석 인스턴스에 대해, 이것은 리소스 자체의 3종 및 그 자식 리소스들에 대한 시맨틱 주석 인스턴스(들)로 구성될 수 있다. 예를 들어 도 13에 대해서, <AE>의 시맨틱 주석 인스턴스는 <AE>의 3종과 <container> 및 <contentInstance>의 시맨틱 주석 인스턴스들로 구성된다. 또한, 추가의 관점에 대해, <container>의 시맨틱 주석 인스턴스는 <container>의 3종 및 <contentInstance>에 대한 시맨틱 주석 인스턴스들로 구성된다.

도 12 뿐만 아니라 도 14, 및 도 16 내지 도 20에 도시되는 단계들을 수행하는 엔티티들이 논리 엔티티들일 수 있다는 점이 이해된다. 이러한 단계들은, 도 32c 또는 도 32d에 도시되는 것들과 같은, 디바이스, 서버, 또는 컴퓨터 시스템의 메모리에 저장될 수 있고 그 프로세서 상에서 실행될 수 있다. 예에서, M2M 디바이스들의 상호 작용에 관한 이하의 보다 상세한 사항과 함께, 도 8의 클라이언트(703)는 도 32a의 M2M 단말 디바이스(18) 상에 존재할 수 있고, 한편 도 8의 시맨틱 저장소(720)는 도 32a의 M2M 게이트웨이 디바이스(14) 상에 존재할 수 있다.

도 14는 클라이언트의 요청에 의해 트리거되는 시맨틱 주석의 예시적인 메시지 흐름을 도시한다. 도 14는, SAP(721)가 클라이언트(703)와 같은 클라이언트들로부터 주석 요청을 수신할 수 있는 제2 시나리오와 관련된다. 시맨틱 주석 요청 메시지에서의 예시적인 필드들이 표 9에 보여진다.

도 14는 클라이언트 요청에 의해 트리거되는 시맨틱 주석 생성의 예시적인 메시지 흐름을 도시한다. 단계 761에서, 클라이언트(703)는 시맨틱 주석 요청 메시지를 SAP(721)에 전송한다. 시맨틱 주석 요청 메시지는 표 9에 보여지는 정보를 포함할 수 있다. 단계 762에서, SAP(721)는 요청을 처리하고, 요청 메시지의 범위 필드에서의 콘텐츠가 주석이 달릴 리소스들의 URI들의 리스트 또는 주석이 달릴 리소스들을 필터링하는 필터 기준을 포함하는지 검증한다. 단계 763에서, SAP(721)는 필터 기준이 범위에 포함되는지 검증한다. 그것은 필터 기준을 갖는 리소스 발견 요청을 리소스 발견 기능(772)에 전송하며, 이는 리소스 저장소(710)에서의 리소스 발견을 담당한다. 단계 764에서, 리소스 발견 기능(772)은 필터 기준에 매칭되는 리소스들의 URI들의 리스트를 반환한다.

단계 765에서, SAP(721)는 시맨틱 주석 인스턴스 대 리소스 관련 레코드들을 탐색하여, 리소스들의 동일한 리스트를 관련시키는 기존의 시맨틱 주석 인스턴스가 존재하는지 알아낼 수 있다. 매칭이 존재하지 않으면, 단계 766으로 점프한다. 그렇지 않으면, 시맨틱 주석 요청 응답은 대응하는 시맨틱 주석 인스턴스이고, 단계 767로 점프한다. SAP(721)는 시맨틱 주석 인스턴스 대 리소스 관련 형태에서의 상이한 엔트리들의 조합을 행함으로써 리소스들을 매칭하는데 더 많은 지능을 가질 수 있다. 시맨틱 주석 요청 응답은 매칭되는 시맨틱 주석 인스턴스들의 조합을 포함할 것이다. 단계 766에서, SAP(721)는 관심있는 리소스들과 관련되는 새로운 시맨틱 주석 인스턴스를 생성한다. 각각의 시맨틱 주석 인스턴스는 SAP(721)에서의 고유 식별자를 갖는다. TSR(723)에서의 시맨틱 주석 인스턴스들에 대해, 이러한 식별자는 리소스들 URI들의 키워드들로 구성될 수 있다. 단계 767에서, SAP(721)는 시맨틱 주석 인스턴스의 표현(관심있는 리소스들의 3종의 리스트)과 함께 시맨틱 주석 요청 응답을 클라이언트(703)에 전송한다. 클라이언트(703)는 시맨틱 주석 인스턴스의 표현이 그 자체의 시맨틱 주석 인스턴스에 대해 시맨틱 기반의 쿼리를 실행하기를 바랄 수 있거나, 또는 클라이언트(703)는 관심있는 리소스들의 시맨틱 정보를 3종의 포맷으로 원할 수 있다. 달리 말하면, 클라이언트(703)는 시맨틱 주석 인스턴스의 표현을 검색하고, 그 끝에 있는 이러한 3종에 대해 시맨틱 기반의 쿼리를 실행할 수 있다. 예를 들어, 도 28에서의 3종이 클라이언트(703)에 의해 검색될 수 있고, 클라이언트(703)는 "그것을 행하기 위한 서비스 레이어없이 19:00-19:30 사이에 이용 가능한 트레드밀들 무엇인가와 같은 3종에 대한 쿼리를 실행할 수 있다.

단계 768에서, SAP(721)이 백그라운드에서 유지하는 클라이언트의 주석 요청 이력에 기초하여, SAP(721)는 새로 생성되는 시맨틱 주석 인스턴스가 TSR(723)에 저장하기 위한 특정 정책을 충족시키는 것으로 결정한다. TSR(723)은 더 빠른 액세스를 위해 설계될 수 있다. BSR과 같은 계층을 갖지 않을 수 있다. 예를 들어, TSR(723)은 몇몇 최근 액세스된 시맨틱 주석 인스턴스들을 포함할 수 있다. 이러한 타입의 저장 정책은 시맨틱 주석 요청들의 범위에서 보여지는 리소스들의 빈도에 기초하거나, 또는 시맨틱 주석 인스턴스를 생성함에서의 오버헤드에 기초할 수 있고, 예를 들어, 일부 리소스들은 로컬로 저장되지 않으며, 이는 리소스 시맨틱 정보의 원격 검색을 요구한다. TSR(723)에 저장되는 시맨틱 주석 인스턴스들은 유효 시간 주기를 가지며, 이는 만료 시간 이후에 무효가 될 수 있다. 도 6의 체육관 사용 사례에서 취한 예에서, 요청은 모든 트레드밀 애플리케이션들에 주석을 다는 것일 수 있다. 이러한 주석을 요청하는 많은 클라이언트가 존재하면, SAP(721)는 미래의 동일한 요청들에 대해 TSR(723)에 주석 인스턴스를 저장하기로 결정할 수 있다. 단계 769에서, SAP(721)는 새로 생성되는 시맨틱 주석 인스턴스를 저장될 TSR(723)에 전송할 수 있다. 단계 770에서, TSR(723)은 시맨틱 주석 인스턴스의 성공적인 저장을 SAP(721)에 확인한다. 단계 771에서, SAP(721)는 표 4 및 표 5에 보여지는 바와 같이 2개의 표들 모두에서 리소스 및 시맨틱 주석 인스턴스 관계를 추가한다. 도 15는 도 13의 예시적인 메시지 흐름과 밀접하게 정렬되는 방법의 예시도이다.

SAP(721)는 관련된 리소스 시맨틱이 업데이트될 때 시맨틱 주석 인스턴스들을 업데이트한다. SAP(721)는 또한 범위 아래의 리소스가 생성/삭제될 때 시맨틱 주석 인스턴스들을 업데이트한다. 시맨틱 주석 인스턴스에 업데이트를 수행하기 위해 SAP(721)를 트리거하는 다수의 방식들이 존재한다. 제1 예에서, SAP(721)는 RR(710)에서 리소스 및 그것의 시맨틱 자식 리소스에 가입한다(예를 들어, 새로운 리소스가 리소스 저장소에 추가되는 것 또는 리소스의 시맨틱 자식 리소스가 업데이트되는 것이 SAP에 통지될 것임). 제2 예에서, RR(710)은 리소스 자체에 첨부되는 관련 정보를 유지한다(예를 들어, 본 명세서에 논의되는 annotationInst 속성은 이러한 속성에서의 시맨틱 주석 인스턴스들이 리소스와 관련됨을 표시함). 이하에서는 이러한 방법을 상세히 논의할 것이다. 제2 예에서는, 가입이 존재하지 않는다. annotationInst 속성은 이러한 리소스와 관련된 주석 인스턴스들을 유지한다. 리소스 시맨틱이 변경될 때, RR(710)은 관련된 시맨틱 주석 인스턴스들을 업데이트하라는 요청을 시맨틱 저장소(720)에 전송할 것이다.

도 16 내지 도 18은 시맨틱 주석 인스턴스 업데이트들을 수반하는 사례들에 대한 예시적인 방법들이다. 요약하면, 본 명세서에서 논의되는 바와 같이, 사례 1(도 16)은 리소스의 시맨틱 정보가 변경되는 사례이고, 사례 2(도 17)는 리소스가 리소스 저장소에 추가되는 사례이며, 사례 3(도 18)은 리소스가 리소스 저장소로부터 삭제되는 사례이다. 사례 번호들은, 표 10에 보여지는 바와 같이, 시맨틱 주석 인스턴스 업데이트 요청 메시지에서의 필드에 삽입될 수 있다. 표 10에 표시되는 바와 같은 사례 번호가 필수는 아니며, 리소스의 추가, 삭제, 또는 업데이트를 표시하는 다른 표시자가 허용될 수 있다는 점이 이해되어야 한다.

도 16은 리소스에 대한 시맨틱 정보의 업데이트와 관련된 시맨틱 주석 인스턴스 업데이트에 대한 예시적인 방법(774)을 도시한다(예를 들어, 시맨틱 자식 리소스가 업데이트 됨). 단계 780에서, 시맨틱 자식 리소스가 업데이트된다. 단계 781에서, RR(710)은 1의 사례 값을 갖는 시맨틱 주석 인스턴스 업데이트 요청 메시지를 SR(720)에 전송한다. 시맨틱 주석 인스턴스 업데이트 요청 메시지는, 리소스의 URI를 표시하는 URI 필드, 리소스의 새로운 시맨틱 정보를 포함하는 semanticsResource 필드, 및 영향을 받은 시맨틱 주석 인스턴스들을 표시하는 식별자 필드를 또한 포함할 수 있다. SR(720)은 RR(710)에서의 리소스 및 그 시맨틱 자식 리소스에 가입될 수 있다(예를 들어, 새로운 리소스가 리소스 저장소에 추가되거나 리소스의 시맨틱 자식 리소스가 업데이트되는 것은 SR(720)으로의 통지를 트리거 할 것임). 단계 782에서, SR(720)은 영향을 받은 시맨틱 주석 인스턴스들에 대해 리소스의 3종을 새로운 것들로 대체한다. 단계 783에서, SR(720)은 시맨틱 주석 인스턴스 업데이트 확인을 RR(710)에 반환한다.

사례 2는 리소스가 RR에 추가되는 것에 관한 것이다(도 17). 부모 리소스의 시맨틱 주석 인스턴스가 그 자식으로 구성되기 때문에, 이것은 BSR에서의 시맨틱 주석 인스턴스들에 종종 영향을 미친다. 따라서 리소스가 레이어에 추가될 때, 이것은 그 위의 레이어 리소스들에 대해 BSR에서의 시맨틱 주석 인스턴스들에 영향을 미칠 수 있다. 예를 들어, 새로운 contentInstance에 시맨틱 정보가 추가되면, 이러한 contentInstance에 대해 새로운 시맨틱 주석 인스턴스가 생성될 것이다. 그 부모 컨테이너 리소스의 시맨틱 주석 인스턴스는 이러한 새로운 시맨틱 주석 인스턴스를 포함할 것이며, 이는, 예를 들어, AE, CSEBase의 시맨틱 주석 인스턴스들에 결국 영향을 미친다.

도 17은 RR(710)에 리소스를 추가하는 것과 관련된 시맨틱 주석 인스턴스 업데이트를 위한 예시적인 방법(776)을 도시한다. 단계 784에서, RR(710)은 RR(710)에 추가된 리소스에 관한 2의 사례 값을 갖는 시맨틱 주석 인스턴스 업데이트 요청 메시지를 SAP(721)에 전송한다. 또한, URI 필드는 새로운 리소스의 URI를 표시하며, semanticsResource 필드는 리소스의 시맨틱 정보를 포함한다. 단계 785에서, SAP(721)는 BSR(722)에서 RR(710)에서의 새로운 리소스에 대한 새로운 시맨틱 주석 인스턴스를 생성한다. SAP(721)는 이러한 시맨틱 주석 인스턴스를 계층 아래에 추가하거나 새로운 리소스들의 3종을 모든 부모 시맨틱 주석 인스턴스들에 추가함으로써 모든 부모 시맨틱 주석 인스턴스들을 업데이트할 수 있다. 단계 786에서, SAP(721)는 새로운 시맨틱 주석 인스턴스 대 리소스 관련 엔트리 뿐만 아니라 새로운 리소스 대 시맨틱 주석 인스턴스 엔트리를 생성한다. 시맨틱 주석 인스턴스 대 리소스 관련 엔트리는 새로운 시맨틱 주석 인스턴스의 식별자와 리소스의 URI를 포함한다. 리소스 대 시맨틱 주석 인스턴스 관련 엔트리는 리소스의 URI, 새로운 시맨틱 주석 인스턴스의 식별자 뿐만 아니라 모든 그 부모 시맨틱 주석 인스턴스들의 식별자들을 포함한다. 단계 787에서, SAP(721)는 시맨틱 주석 인스턴스 업데이트 확인을 RR(710)에 전송하고, 시맨틱 주석 인스턴스 대 리소스 관련 레코드를 첨부한다. 단계 788에서, RR(710)은 (예를 들어, 추가된 리소스의 속성에) 리소스와 함께 시맨틱 주석 인스턴스 식별자를 저장할 수 있다.

도 18은 RR(710)로부터 리소스를 삭제하는 것과 관련된 시맨틱 주석 인스턴스 업데이트에 대한 예시적인 방법(778)을 도시한다. 단계 791에서, RR(710)은 RR(710)로부터 리소스를 삭제하는 것에 관한 3의 사례 값을 갖는 시맨틱 주석 인스턴스 업데이트 요청 메시지를 SAP(721)에 전송한다. 시맨틱 주석 인스턴스 업데이트 요청 메시지는 삭제된 리소스의 URI를 표시하는 URI 필드 및 영향받은 시맨틱 주석 인스턴스들을 표시하는 식별자 필드를 또한 포함할 수 있다. 단계 792에서, SAP(721)는 영향받은 시맨틱 주석 인스턴스들로부터 리소스의 3종을 삭제한다. 삭제된 리소스의 3종만을 포함하는 하나의 시맨틱 주석 인스턴스는 비어 있게 될 것이다. 단계 793에서, SAP(721)는 리소스 대 시맨틱 주석 인스턴스 관련 형태에서의 리소스의 레코드를 삭제한다. SAP(721)는 단계 792에서, 식별된 시맨틱 주석 인스턴스의 엔트리를 시맨틱 주석 인스턴스 대 리소스 관련 형태로부터 삭제한다. SAP(721)는 리소스의 URI를 시맨틱 주석 인스턴스 대 리소스 관련 형태에서의 다른 영향받은 엔트리들로부터 삭제한다. 단계 794에서, SAP(721)는 시맨틱 주석 인스턴스 업데이트 확인을 RR(721)에 반환할 수 있다.

RR(710)로부터 리소스를 삭제하는 것과 관하여, 삭제된 리소스가 정상 자식 리소스를 갖는다면, 예를 들어, <container>가 <contentInstance> 자식 리소스들을 갖는다면, 방법(778)에 관하여 설명되는 바와 같은 위 단계들은 삭제된 리소스의 최하위 레이어 자식으로부터 리소스 자체까지 재귀적으로 수행될 수 있다. 예를 들어, <container>를 삭제할 때, RR(710)은 먼저 <contentInstance>가 삭제될 것이라고 가정하고, <contentInstance>의 삭제를 취급하기 위해 방법(778)에 관하여 도시되는 단계들을 시작한다. 컨테이너 아래의 모든 <contentInstance> 리소스가 취급될 때, <container> 리소스는 방법(778)의 적절한 단계들에 의해 취급될 수 있다.

시맨틱 주석 인스턴스 마이그레이션이 이하 논의된다. 관련 리소스들이 새로운 위치(물리적 또는 논리적)로 이동될 때, SAP(721)는 시맨틱 주석 인스턴스들을 다른 시맨틱 저장소로 이동시킬 수 있다. SAP(721)는 관련 리소스들 중 일부가 새로운 위치로 이동될 때 영향받은 시맨틱 주석 인스턴스들을 업데이트할 수 있다. 예를 들어, 도 6의 트레드밀(737)이 2층에서 1층으로 이동되고, 따라서 트레드밀 AE는 2층의 게이트웨이(731)로부터 등록을 취소하고 1층의 게이트웨이(733)에 등록한다. 결과적으로, 트레드밀 AE는 2층 게이트웨이(731) CSE에 존재하는 현재의 RR(710)로부터 삭제되고, 1층 게이트웨이(733) CSE에 존재하는 새로운 RR에 생성된다. 시맨틱 주석 인스턴스 마이그레이션은 각각 사례 3(방법 778)과 사례 2(방법 776)의 시맨틱 주석 인스턴스 업데이트의 조합에 의해 실제로 달성될 수 있다. 도 19는 도 6, 도 17 및 도 18을 참조하여 시맨틱 주석 인스턴스 마이그레이션에 대한 예시적인 방법을 도시한다. 단계 796에서, 2층의 게이트웨이 상의 SAP(721)는 사례 3(방법 778)에 따라 시맨틱 주석 인스턴스를 업데이트 할 것이며, 그 이유는 트레드밀 AE 리소스가 2층의 게이트웨이 상의 CSEBase로부터 삭제되기 때문이다. 단계 797에서, 1층의 게이트웨이 상의 SAP는 사례 2(방법 776)에 따라 시맨틱 주석 인스턴스를 업데이트 할 것이며, 그 이유는 새로운 트레드밀 AE 리소스가 1층의 게이트웨이 상의 CSEBase 아래에 생성될 것이기 때문이다.

이하는 시맨틱 주석 인스턴스 발견의 논의이다. SAP(예를 들어, SAP(721))는 클라이언트의 쿼리들에 기초하여 로컬 SR에서의 시맨틱 주석 인스턴스들을 발견하고 반환하거나 또는 쿼리들을 전달하는 것에 의해 다른 M2M 엔티티들에서의 다른 SR과 협력할 수 있다. 도 20은 시맨틱 주석 인스턴스 발견의 예시적인 메시지 흐름을 도시한다. 단계 814에서, 클라이언트(811)는 시맨틱 주석 인스턴스 발견 요청을 전송한다. 단계 814의 시맨틱 주석 인스턴스 발견 요청은 표 11에 보여지는 바와 같은 포맷으로 있을 수 있다. 표 11에 표시되는 바와 같은 옵션 번호가 필수 형태는 아니며 옵션에 관하여 동일하거나 유사한 정보를 중계하는 다른 표시자가 사용될 수 있다는 점이 이해되어야 한다.

계속해서 도 20을 참조하면, 단계 815에서, 요청된 SAP(812)는 단계 814의 요청을 처리하고, 협력 SAP(813)에 요청을 제공하기로 결정할 수 있다. 요청된 SAP(812) 및 협력 SAP(813)는 서로를 인식할 수 있고, 물리적으로 서로 가깝거나, 또는 비즈니스 관계를 가질 수 있다. 옵션 1에 대해, 리소스들의 URI들은 리소스들이 협력 RR에 저장됨을 표시할 수 있다(도시되지 않음). 대응하는 시맨틱 주석 인스턴스를 발견하기 위해, 요청된 SAP(812)는 단계 814의 요청을 협력 SAP(813)에 제공하기로 결정한다. 옵션 2에 대해, 협력 RR(도시되지 않음)은 필터 기준에 매칭되는 리소스들을 가질 수 있다. 따라서, 요청된 SAP(812)는 협력 SAP(813)에 단계 814의 요청을 제공하기로 결정한다.

단계 816에서, 시맨틱 주석 인스턴스 발견 요청 메시지가 협력 SAP(813)에 제공된다. 단계 817에서, 협력 SAP(813)는 요청을 처리하고, 매칭되는 시맨틱 주석 인스턴스 식별자(들) 및/또는 표현을 반환한다. 단계 818에서, 요청된 SAP(812)는 발견 결과들을 조합한다. 단계 819에서, 요청된 SAP는 시맨틱 주석 인스턴스 발견 결과로 클라이언트(811)에 응답한다.

방법(810)에 관한 예시적인 상황은 도 6의 체육관 사용 사례를 참조하여 알 수 있다. 예를 들어, 클라이언트(811)는 도 6의 체육관에서의 모든 트레드밀들에 대한 시맨틱 주석 인스턴스들을 발견하기를 원할 수 있다. 1층의 게이트웨이(733) 상의 SAP(721)가 이러한 요청을 수신하고; 이것은 요청을 전달하고 발견 결과들을 조합함으로써 2층의 게이트웨이(731)와 협력할 것이다.

oneM2M과 관련된 추가적인 예들이 이하 논의된다. 본 명세서에서 논의되는 바와 같이, 리소스의 시맨틱은 리소스, 관계, 및 값으로 구성되는 리소스-관계-값(Resource-Relationship-Value) 3종에 의해 설명될 수 있다. 값들은 클래스들 또는 다른 리소스들일 수 있다. 다음은 일부 예들이다:

. A content instance (리소스) hasType (관계) temperatureReading (클래스)

. A content instance (리소스) generatedBySameApplicationAs (관계) another content instance (리소스)

정상 리소스(예를 들어, <AE>, <container>)에 대해, 리소스-관계-값 3종에서는, 리소스 자체가 고정되고 알려지기 때문에, 누락되는 것은 관계-값 2종의 집합이다. 시맨틱 설명을 리소스들에 제공하는 새로운 <semantics> 자식 리소스가 추가될 수 있다. 리소스의 <semantics> 자식 리소스는 리소스의 시맨틱을 설명하는 그 설명 속성에서의 관계-값 2종을 포함한다.

도 21은 <semantics> 리소스의 리소스 구조를 도시한다. <semantics> 리소스의 description 속성은 관계-값 2종의 리스트를 포함하며, 이는 복합 데이터타입이다. 복합 데이터타입은 표 17에 보여지는 포맷을 갖는 관계-값 2종의 목록이다. 표 12 및 표 13은 각각 <semantics> 리소스의 자식 리소스 및 속성들을 보여준다. 표 12, 표 13, 및 본 명세서에서 논의되는 다른 표들은 예들이다. 다음은 <semantics> 자식 리소스가 이들에 추가되면 시맨틱 정보를 가능하게 할 수 있는 리소스들의 예시적인 리스트이다: <CSEBase>, <remoteCSE>, <AE>, <container>, <contentInstance>, <group> 및 <node>.

도 22는 도 7에 표현되는 트레드밀 AE들의 시맨틱 정보를 반영하는 시맨틱 자식 리소스 설명을 도시한다. 대안적으로, 설명 속성의 콘텐츠는 도 23에 도시되는 바와 같이 <semantics> 리소스의 자식 리소스로 이동될 수 있다. 표 14는 <semantics> 리소스가 새로운 자식 리소스 <relationDouble>을 갖는 것을 보여준다.

계속해서 도 23 및 표 14를 참조하면, SAP(721)는 단일 시맨틱 주석 인스턴스들을 생성 및 사용하여 subject 리소스로부터 멀리 떨어져 저장되는 여러 리소스들 및 주석 인스턴스들을 설명할 수 있고, 스토리지 최적화 및 유연성을 제공한다. SAP(721)는 발견 기능성을 보존하기 위해, 원격으로 저장될 때, 리소스들과 그들의 주석들 사이의 관련성을 유지할 수 있다. 예를 들어, <semantics> 리소스에 의해 제공되는 설명이 추가적 유연성을 제공하기 위해 증대될 수 있다. subject 속성은 단일 시맨틱 주석 인스턴스들이 여러 리소스들을 설명할 수 있게 하고, 저장 위치에 대한 유연성을 제공한다. 동시에, 이것은, 간략화 및 스토리지 최적화를 위해, <relationDouble>의 단일 subject가 부모 리소스일 때, 생략될 수 있다. 리소스들과 그들의 주석들 사이의 관련성은, 원격으로 저장될 때, link 속성의 사용을 통해 보존되며, 이는 원격 주석들이 있는 <semantics> 리소스들을 지향한다.

<relationDouble>의 리소스 트리 구조가 도 24에 도시된다. 표 15는 자식 리소스를 보여준다. 표 16은 <relationDouble> 리소스의 속성들을 보여준다. 여기에 적용될 수 있는 공통 속성들은 표 13에 나열된다.

<relationDouble>의 description 속성은 표 17에 보여지는 바와 같은 복합 데이터타입을 갖는다. description 속성은 "relationship"및 "value" 필드들을 포함한다. relationship 필드는 AnyURI의 데이터 타입을 가지며, 이는 온톨로지 저장소에 저장되는 관계 리소스를 지향한다. 값은 임의의 데이터 타입 수 있다. 따라서 클래스 또는 XSD에 정의되는 이들의 원시 데이터 타입들(예를 들어, duration, dateTime 등)과 같은 임의의 가능한 데이터 타입들의 열거로 임의의 것이 구성될 수 있다. 도 25는 <AE> 리소스 및 <container> 리소스의 시맨틱 자식 리소스의 예를 도시하며, 이는 트레드밀 AE에 대한 관계-값 2종을 포함한다.

새로운 annotationInst 속성이 개시된다. annotationInst 속성은 시맨틱 주석 인스턴스에서 주석이 달리는 리소스에 추가 될 수 있다. annotationInst 속성은 시맨틱 주석 인스턴스(들)의 식별자(들)를 저장한다. 이러한 annotationInst 속성으로, 리소스와 시맨틱 주석 인스턴스가 관련될 수 있다. 리소스의 시맨틱에 대한 업데이트가 존재할 때, 시맨틱 주석 인스턴스가 마찬가지로 업데이트될 수 있다. <semantics> 자식 리소스를 갖는 리소스가 또한 annotationInst 속성과 함께 추가될 것이다.

시맨틱 데이터베이스(예를 들어, 시맨틱 저장소(720))가 이하 논의된다. <SD>는, 도 26에 도시되는 바와 같이, 시맨틱 데이터베이스에 시맨틱 주석의 RESTFUL 동작들에 대한 리소스들을 저장한다. <SD> 리소스는 CSEBase 아래에 위치될 수 있다. <SD>의 format 속성은 시맨틱 데이터베이스에서의 시맨틱 정보의 포맷을 나타내며, 이는 임의의 수의 3종 (N-triples)일 수 있다. 표 18은 <SD>의 자식 리소스들을 보여준다. 표 19는 <SD>의 속성들을 보여주며 표 13은 여기에 적용될 수 있는 더 많은 속성들을 보여준다. 대안적으로, <SD> 리소스는 시맨틱 데이터베이스를 액세스하기 위한 RESTFUL 인터페이스로서 작용하는 가상 리소스 일 수 있다. 다음으로 <SD> 리소스는 자식 리소스 또는 속성을 갖지 않을 수 있다. 주석 자식 리소스는 CSEBase 아래에 위치될 수 있다. "가상 리소스(virtual resource)"가 ETSI m2m 및 oneM2M에서 사용된다. 가상 리소스는 인터페이스로 작용하는 것으로 고려될 수 있으며 일반적으로 자식 리소스 또는 속성들을 갖지 않는다.

<annotation> 리소스는 시맨틱 주석 요청이 전송될 때 타겟이 된다. <annotation>의 리소스 트리 구조가 도 27에 도시된다. 표 20은 <annotation>의 자식 리소스들을 보여준다. <annotation> 리소스의 속성들은 표 21에 보여지며 표 13은 여기에 적용될 수 있는 더 많은 속성들을 보여준다. 대안적으로, <annotation> 리소스는 리소스들에 대해 시맨틱 주석을 수행하는 RESTFUL 인터페이스로 작용할 수 있는 가상 리소스일 수 있다.

도 22에서의 트레드밀 AE의 시맨틱은, 도 28에 도시되는 바와 같이, Turtle format의 시맨틱 주석 인스턴스로 주석이 달린다.

이하는 시맨틱 주석에 관한 ROA 및 SOA의 논의이다. 이전에 논의된 바와 같이, oneM2M은 oneM2M 서비스 레이어에 의해 지원되는 능력들을 정의한다. oneM2M 서비스 레이어는 CSF(common service functions)의 집합을 포함하는 CSE(common services entity)로서 인스턴스화된다. 일 예로서, 개시된 SAP(721)는 도 29에 도시되는 바와 같이 시맨틱 주석 아래에 oneM2M CSF로서 CSE에서 호스팅될 수 있다. 다른 예에서, SAP(721)는 시맨틱 CSF 또는 데이터 관리 및 저장소 CSF의 일부일 수 있으며, 이는 M2M 시맨틱 지원의 기능성들을 지원한다(예를 들어, 도 8). oneM2M 버티컬들(예를 들어, 리소스들의 시맨틱 주석을 요청하기 위해 Mca 참조 포인트를 통해 시맨틱 주석 CSF와 통신하는 AE들)은 시맨틱 주석 인스턴스들을 발견한다. 다른 CSE들은 리소스들의 시맨틱 주석을 요청하거나 시맨틱 주석 인스턴스들을 발견하기 위해 Mcc 참조 포인트를 통해 시맨틱 주석 CSF와 대화할 수 있다.

도 30은 oneM2M 서비스 컴포넌트 아키텍처(TS-0007 Service Component Architecture-V-0.4.0)에서의 시맨틱 주석의 구현 아키텍처를 도시한다. oneM2M 버티컬들(예를 들어, 리소스들의 시맨틱 주석을 요청하기 위해 Mca 참조 포인트를 통해 시맨틱 주석 서비스 컴포넌트와 통신하는 AE들)은 시맨틱 주석 인스턴스들을 발견한다. 본 명세서에 개시되는 메시지들 및 프로시저가 참조 포인트들에 적용된다.

도 31은 본 명세서에 논의되는 방법들 및 시스템들에 기초하여 생성될 수 있는 예시적인 디스플레이(예를 들어, 그래픽 사용자 인터페이스)를 도시한다. 디스플레이 인터페이스(910) (예를 들어, 터치 스크린 디스플레이)는, 표 1 내지 표 21의 파라미터들과 같이, 시맨틱 주석 또는 시맨틱 저장소와 관련된 블록 911에서의 텍스트를 제공할 수 있다. 다른 예에서, 본 명세서에서 논의된 임의의 단계들 중 임의의 것의 진행(예를 들어, 전송된 메시지들 또는 단계들의 성공)이 블록 911에서 디스플레이 될 수있다. 또한, 그래픽 출력(912)이 디스플레이 인터페이스(910) 상에 디스플레이 될 수 있다. 그래픽 출력(912)은 시맨틱 주석 또는 시맨틱 저장소와 관련된 디바이스들 또는 리소스들의 토폴로지(예를 들어, 도 6, 도 11, 도 13 등), 본 명세서에서 논의된 임의의 방법 또는 시스템들의 진행(예를 들어, 도 12, 도 14 등)의 그래픽 출력 등일 수 있다.

본 명세서에 나타나는 청구항들의 범위, 해석, 또는 적용을 전혀 제한하지 않고, 본 명세서에 개시되는 하나 이상의 예들의 기술적 효과는, 효율적인 시맨틱 기반의 쿼리를 용이하게 하는 방식(예를 들어, 쿼리 처리 시간을 감소시킴)으로 리소스 시맨틱 정보를 저장하고 구조화하는 방법에 대한 조절들 제공하는 것이다.

종래의 ETSI M2M 시스템에서, M2M 리소스들의 시맨틱 주석은 M2M 리소스들에 시맨틱 정보를 추가하여 이종 M2M 애플리케이션들에 일관된 데이터 변환 및 데이터 상호 운영성을 제공하는 방법이다. 시맨틱으로 주석이 달린 M2M 리소스들은 어떤 데이터가 리소스들에 의해 제공되는지 및 제공된 데이터가 무엇을 의미하는지 이해하는 M2M 애플리케이션에 의해 접촉될 수 있다. 이러한 주석들은 통상적인 M2M 시스템 단독에 비해 보다 의미있는 설명들을 제공하고 M2M 데이터를 노출시킨다. 리소스들과 다른 것들 사이의 관계들을 설명하기 위해, 이것은 관계 속성을 정의하며, 이는 다른 ETSI M2M 리소스를 지향하는 URI를 갖는다.

본 명세서에서는 oneM2M 아키텍처가 배경을 통해 설명되고, 본 명세서에서 설명되는 주제를 예시하는데 사용될 수 있지만, 본 명세서에서 설명되는 주제의 구현들은 본 개시내용의 범위 내에서 유지되면서 변경될 수 있다는 점이 이해된다. 본 분야에서의 기술자는, 개시된 주제들이 위에서 논의된 oneM2M 아키텍처를 사용하는 구현들에 제한되는 것은 아니며, 오히려 ETSI M2M과 다른 M2M 시스템들 및 아키텍처들과 같은 다른 아키텍처들 및 시스템들에서 구현될 수 있다는 점을 또한 인식할 것이다.

도 32a는 시맨틱 아키텍처(701) 및 그 안의 컴포넌트들과 같은 하나 이상의 개시된 개념들이 구현될 수 있는 예시적인 M2M(machine-to machine), IoT(Internet of Things), 또는 WoT(Web of Things) 통신 시스템(10)의 도면이다. 일반적으로, M2M 기술들은 IoT/WoT에 대한 빌딩 블록들을 제공하고, 임의의 M2M 디바이스, M2M 게이트웨이 또는 M2M 서비스 플랫폼은 이러한 IoT/WoT는 물론이고 IoT/WoT 서비스 레이어 등의 컴포넌트일 수 있다.

도 32a에 도시되는 바와 같이, 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), 위성 네트워크, 홈 네트워크, 또는 기업 네트워크와 같은 다른 네트워크들을 포함할 수 있다.

도 32a에 도시되는 바와 같이, 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 디바이스들(예를 들어, 셀룰러 및 비-셀룰러) 뿐만 아니라 고정형 네트워크 M2M 디바이스들(예를 들어, PLC)가 통신 네트워크(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), 직접 무선 링크, 및 유선을 포함하는 다양한 네트워크들을 통해 통신할 수 있다.

도 32b를 참조하면, 필드 도메인에 도시되는 M2M 서비스 레이어(22)(예를 들어, 본 명세서에서 설명되는 바와 같은 CSE)는 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')는 하나 이상의 서버들, 컴퓨터들, 가상 머신들(예를 들어, 클라우드/계산/스토리지 팜들 등) 등에 의해 구현될 수 있다.

도 32b를 참조하면, M2M 서비스 레이어(22 및 22 ')는 다양한 애플리케이션 및 버티컬들이 이용할 수 있는 서비스 전달 능력들의 코어 세트를 제공한다. 이러한 서비스 능력들은 M2M 애플리케이션들(20, 20')이 디바이스들과 상호작용하고 또한 데이터 수집, 데이터 분석, 디바이스 관리, 보안, 과금, 서비스/디바이스 발견 등과 같은 기능들을 수행할 수 있게 한다. 본질적으로, 이러한 서비스 능력들은 이러한 기능성들을 구현하는 부담으로부터 애플리케이션들을 자유롭게 하고, 마케팅하기 위한 비용 및 시간을 감소시킨다. 서비스 레이어(22 및 22')는 또한 M2M 애플리케이션들(20 및 20')이 서비스 레이어(22 및 22')가 제공하는 서비스들과 관련하여 다양한 네트워크들(12 및 12')을 통해 통신할 수 있게 한다.

일부 예들에서, M2M 애플리케이션들(20 및 20 ')은 본 명세서에서 논의된 바와 같이, 시맨틱 주석 인스턴스들을 제공하는 바람직한 애플리케이션들을 포함할 수 있다. M2M 애플리케이션들(20 및 20')은, 이에 제한되는 것은 아니지만, 운송, 건강 및 보건, 커넥티드 홈(connected home), 에너지 관리, 자산 추적, 그리고 보안 및 감시와 같은 다양한 산업들에서의 애플리케이션들을 포함할 수 있다. 위에 언급된 바와 같이, 시스템의 디바이스들, 게이트웨이들 및 다른 서버들에 걸쳐 실행되는 M2M 서비스 레이어는, 예를 들어, 데이터 수집, 디바이스 관리, 보안, 과금, 위치 추적/지오펜싱(geofencing), 디바이스/서비스 발견, 및 레거시 시스템들 통합과 같은 기능들을 지원하고, 이러한 기능들을 서비스들로서 M2M 애플리케이션들(20, 20')에 제공한다.

본 출원의 시맨틱 주석 및 시맨틱 저장소는 서비스 레이어의 일부로서 구현될 수 있다. 서비스 레이어(예를 들어, CSE(901))는 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)라고 지칭되며, 이는 상이한 타입들의 네트워크 노드들(예를 들어, 인프라스트럭처 노드, 중간 노드, 애플리케이션 특정적 노드) 상에서 호스팅될 수 있다. 또한, 본 출원의 시맨틱 저장소는 본 출원의 시맨틱 저장소와 같은 서비스들에 액세스하기 위해 SOA(Service Oriented Architecture) 및/또는 ROA(resource-oriented architecture)를 사용하는 M2M 네트워크의 일부로서 구현될 수 있다.

도 32c는 예를 들어 M2M 단말 디바이스(18) 또는 M2M 게이트웨이 디바이스(14)와 같은 예시적인 M2M 디바이스(30)의 시스템 다이어그램이다. 도 32c에 도시되는 바와 같이, M2M 디바이스(30)는 프로세서(32), 송수신기(34), 송신/수신 엘리먼트(36), 스피커/마이크로폰(38), 키패드(40), 디스플레이/터치 패드(42), 비-이동식 메모리(44), 이동식 메모리(46), 전원(48), GPS(global positioning system) 칩셋(50), 및 다른 주변기기들(52)을 포함할 수 있다. M2M 디바이스(30)는 개시된 주제와 일관성을 유지하면서 전술한 엘리먼트들의 임의의 하위 조합을 포함할 수 있다는 점이 이해될 것이다. (게이트웨이(733), 주변 센서(734), 저울(736), 트레드밀(737), 혈압 모니터(735), 클라이언트(710), 시맨틱 저장소(720) 등과 유사한) 이러한 디바이스는 시맨틱 주석을 위해 개시된 시스템들 및 방법들을 사용하는 디바이스일 수 있다.

프로세서(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)에 연결될 수 있다. 도 32c는 프로세서(32) 및 송수신기(34)를 별개의 컴포넌트들로서 묘사하지만, 프로세서(32) 및 송수신기(34)는 전자 패키지 또는 칩에 함께 통합될 수 있다는 점이 이해될 것이다. 프로세서(32)는 애플리케이션 레이어 프로그램들(예를 들어, 브라우저들) 및/또는 RAN(radio access-layer) 프로그램들 및/또는 통신 프로그램들을 수행할 수 있다. 프로세서(32)는 예를 들어 액세스-레이어 및/또는 애플리케이션 레이어에서와 같이, 인증, 보안 키 합의, 및/또는 암호화 동작들과 같은 보안 동작들을 수행할 수 있다.

송신/수신 엘리먼트(36)는 신호들을 M2M 서비스 플랫폼(22)에 송신하거나 또는 그로부터 신호들을 수신하도록 구성될 수 있다. 예를 들어, 송신/수신 엘리먼트(36)는 RF 신호들을 송신 및/또는 수신하도록 구성되는 안테나일 수 있다. 송신/수신 엘리먼트(36)는 WLAN, WPAN, 셀룰러 등과 같은, 다양한 네트워크들 및 에어 인터페이스들을 지원할 수 있다. 예에서, 송신/수신 엘리먼트(36)는, 예를 들어, IR, UV 또는 가시광 신호들을 송신 및/또는 수신하도록 구성되는 방출기/검출기일 수 있다. 또 다른 예에서, 송신/수신 엘리먼트(36)는 RF 및 광 신호들 양자 모두를 송신 및 수신하도록 구성될 수 있다. 송신/수신 엘리먼트(36)는 무선 또는 유선 신호들의 임의의 조합을 송신 및/또는 수신하도록 구성될 수 있다는 점이 이해될 것이다.

또한, 도 32c에는 송신/수신 엘리먼트(36)가 단일 엘리먼트로서 묘사되지만, 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) 상에서 조명 패턴들, 이미지들 또는 컬러들을 제어하도록(예를 들어, 표 4 또는 표 5), 또는 다른 방식으로 시맨틱 저장소 및 관련 컴포넌트들의 상태를 표시하도록 구성될 수 있다. 디스플레이 또는 표시자들(42) 상에서 조명 패턴들, 이미지들 또는 컬러들을 제어하는 것은 본 명세서에서 도시되거나 또는 논의되는 도면들(예를 들어, 도 12, 도 14 내지 도 20 등)에서의 방법 흐름들 또는 컴포넌트들 중 임의의 것의 상태를 반영하거나 또는 본 명세서에서의 표들 중 임의의 것에서의 정보를 반영할 수 있다. 본 명세서에는 시맨틱 주석 서비스들의 메시지들 및 프로시저들이 개시된다. 이러한 메시지들 및 프로시저들은, 디스플레이(42) 상에 디스플레이될 수 있는 다른 것들 중에서, 사용자들이 입력 소스(예를 들어, 스피커/마이크로폰(38), 키패드(40), 또는 디스플레이/터치 패드(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) 라디오 유닛, 디지털 음악 플레이어, 미디어 플레이어, 비디오 게임 플레이어 모듈, 인터넷 브라우저 등을 포함할 수 있다.

도 32d는, 예를 들어, 도 32a 및 도 32b의 M2M 서비스 플랫폼(22)이 구현될 수 있는 예시적인 컴퓨팅 시스템(90)의 블록도이다. 컴퓨팅 시스템(90)은 컴퓨터 또는 서버를 포함할 수 있으며, 이러한 소프트웨어가 어디에 또는 어떤 수단에 의해 저장되거나 액세스되든, 소프트웨어의 형태일 수 있는 컴퓨터 판독 가능 명령어들에 의해 주로 제어될 수 있다. 이러한 컴퓨터 판독가능 명령어들은 컴퓨팅 시스템(90)으로 하여금 동작하게 하도록 CPU(central processing unit)(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)은 컴퓨팅 시스템(90)을 도 32a 및 도 32b의 네트워크(12)와 같은, 외부 통신 네트워크에 접속하는데 사용될 수 있는 네트워크 어댑터(97)를 포함할 수 있다.

본 명세서에 설명되는 시스템들, 방법들 및 프로세스들 중 임의의 것 또는 모든 것은 컴퓨터 판독가능 스토리지 매체에 저장된 컴퓨터 실행가능 명령어들(즉, 프로그램 코드)의 형태로 구현될 수 있다는 점이 이해되며, 이 명령어들은, 컴퓨터, 서버, M2M 단말 디바이스, M2M 게이트웨이 디바이스 등과 같은 머신에 의해 실행될 때, 본 명세서에 설명되는 시스템들, 방법들 및 프로세스들을 수행 및/또는 구현한다. 구체적으로, 위에 설명된 단계들, 동작들 또는 기능들 중 임의의 것이 이러한 컴퓨터 실행가능 명령어들의 형태로 구현될 수 있다. 컴퓨터 판독가능 스토리지 매체는 정보의 저장을 위한 방법 또는 기술로 구현되는 휘발성 및 비휘발성, 이동식 및 비-이동식 매체 모두를 포함하지만, 이러한 컴퓨터 판독가능 스토리지 매체는 신호들을 포함하지 않는다. 컴퓨터 판독가능 스토리지 매체는, 이에 제한되는 것은 아니지만, RAM, ROM, EEPROM, 플래시 메모리 또는 다른 메모리 기술, CD-ROM, DVD(digital versatile disks) 또는 다른 광학 디스크 스토리지, 자기 카세트들, 자기 테이프, 자기 디스크 스토리지 또는 다른 자기 스토리지 디바이스들, 또는 원하는 정보를 저장하는데 사용될 수 있는 그리고 컴퓨터에 의해 액세스될 수 있는 임의의 다른 물리적 매체를 포함한다.

도면들에 도시되는 바와 같이, 본 개시내용의 주제의 바람직한 방법들, 시스템들, 또는 장치들을 설명함에 있어서, 구체적인 용어가 명료성을 위해 채택된다. 그러나, 청구되는 주제는 그와 같이 선택되는 구체적인 용어로 제한되는 것으로 의도되는 것이 아니며, 각각의 구체적인 엘리먼트가 유사한 목적을 달성하기 위해 유사한 방식으로 동작하는 모든 기술적 등가물들을 포함하는 것으로 이해되어야 할 것이다.

본 작성 명세서는 최상의 모드를 포함하는 본 발명을 개시하고, 또한 관련분야에서의 임의의 숙련된 자가 임의의 디바이스들 또는 시스템들을 제작하고 사용하고 임의의 통합된 방법들을 수행하는 것을 포함하여 본 발명을 실시할 수 있도록 하기 위해 예를 사용한다. 본 발명의 특허가능한 범위는 청구항들에 의해 정의되고, 관련분야에서의 숙련된 자들에게 발생하는 다른 예들(예를 들어, 청구항들에서 제공되는 바와 같은 것을 포함하는 본 명세서에 개시되는 예시적인 방법들 사이에서 단계들을 생략하거나, 단계들을 조합하거나, 단계들을 추가하는 것)을 포함할 수 있다. 이러한 다른 예들은, 이들이 청구항들의 문자 그대로의 표현과 상이하지 않은 엘리먼트들을 갖거나, 또는 이들이 청구항들의 문자 그대로의 표현과 실질적인 차이가 없는 등가적 엘리먼트들을 포함하면, 청구항들의 범위 내에 있는 것으로 의도된다.

Claims (20)

1. 디바이스로서,
   프로세서; 및
   상기 프로세서와 연결되는 메모리
   를 포함하고, 상기 메모리는 상기 프로세서에 의해 실행될 때 상기 프로세서로 하여금 동작들을 수행하게 하는 실행 가능한 명령어들을 포함하며, 상기 동작들은,
   클라이언트 디바이스의 요청에 기초하여 리소스의 시맨틱 주석 인스턴스를 생성하는 단계- 상기 시맨틱 주석 인스턴스는 상기 리소스를 반영하는 방식으로 계층적으로 저장되며, 상기 시맨틱 주석 인스턴스는 상기 클라이언트 디바이스로부터의 요청들의 이력과 관련된 정책에 기초하여 저장됨 -; 및
   상기 요청에 기초하여 상기 클라이언트 디바이스에 상기 시맨틱 주석 인스턴스를 제공하는 단계
   를 포함하는 디바이스.
2. 제1항에 있어서,
   상기 요청은 시맨틱 주석 요청인 디바이스.
3. 제1항에 있어서,
   상기 정책은 상기 요청들의 범위에서 보여지는 상기 리소스들의 빈도에 기초하는 디바이스.
4. 제1항에 있어서,
   상기 정책은 상기 시맨틱 주석 인스턴스를 생성하는 단계에서의 오버헤드에 기초하는 디바이스.
5. 제1항에 있어서,
   상기 정책은 상기 리소스 시맨틱 정보의 검색을 위해 원격 검색이 사용되는지에 기초하는 디바이스.
6. 제1항에 있어서, 상기 리소스는 상기 리소스의 시맨틱 정보를 나타내는 시맨틱 자식 리소스를 갖는 디바이스.
7. 제1항에 있어서,
   상기 요청은 상기 리소스의 시맨틱 주석 인스턴스의 균일한 리소스 표시자를 포함하는 디바이스.
8. 제1항에 있어서,
   상기 동작들은 어떤 시맨틱 주석 인스턴스들이 상기 리소스에 관련되는지의 통지를 제공하는 단계를 더 포함하는 디바이스.
9. 제1항에 있어서,
   상기 동작들은 상기 리소스의 관련된 시맨틱이 업데이트될 때 상기 리소스의 시맨틱 주석 인스턴스를 업데이트하는 단계를 더 포함하는 디바이스.
10. 제1항에 있어서,
    상기 동작들은 미리 결정된 범위 하의 리소스가 생성되거나 삭제될 때 상기 리소스의 시맨틱 주석 인스턴스를 업데이트하는 단계를 더 포함하는 디바이스.
11. 제1항에 있어서,
    상기 동작들은, 상기 리소스가 제1 위치로부터 제2 위치로 이동되는 것에 응답하여, 상기 시맨틱 주석 인스턴스를 다른 디바이스로 이동시키라는 명령어들을 제공하는 단계를 더 포함하는 디바이스.
12. 제1항에 있어서,
    상기 동작들은 상기 요청에 기초하여 상기 시맨틱 주석 인스턴스를 발견하는 단계를 더 포함하는 디바이스.
13. 제1항에 있어서,
    상기 요청은 상기 리소스의 균일한 리소스 표시자를 포함하고, 상기 균일한 리소스 표시자는 상기 리소스의 대응하는 시맨틱 주석 인스턴스를 발견하는데 사용되는 디바이스.
14. 제1항에 있어서,
    상기 요청은 상기 리소스의 대응하는 시맨틱 주석 인스턴스를 발견하기 위해 상기 리소스와 관련된 필터 기준을 포함하는 디바이스.
15. 제14항에 있어서,
    상기 필터 기준은 관계-값(relationship-value) 값을 포함하는 디바이스.
16. 시맨틱 주석을 위한 방법으로서,
    리소스의 시맨틱 주석 인스턴스를 자동으로 생성하는 단계;
    상기 리소스를 반영하는 계층적인 방식으로 시맨틱 주석 인스턴스를 저장하는 단계; 및
    요청에 기초하여, 어떤 시맨틱 주석 인스턴스들이 상기 리소스에 관련되는지의 통지를 제공하는 단계
    를 포함하는 방법.
17. 제16항에 있어서,
    상기 리소스의 수반된 시맨틱이 업데이트될 때 상기 리소스의 시맨틱 주석 인스턴스를 업데이트하는 단계를 더 포함하는 방법.
18. 제16항에 있어서,
    미리 결정된 범위 하의 상기 리소스가 생성되거나 삭제될 때 상기 리소스의 시맨틱 주석 인스턴스를 업데이트하는 단계를 더 포함하는 방법.
19. 제16항에 있어서,
    상기 리소스가 제1 위치로부터 제2 위치로 이동될 때 상기 시맨틱 주석 인스턴스를 다른 디바이스로 이동시키라는 명령어들을 제공하는 단계를 더 포함하는 방법.
20. 제16항에 있어서,
    상기 요청은 상기 리소스의 대응하는 시맨틱 주석 인스턴스를 발견하기 위해 상기 리소스와 관련된 필터 기준을 포함하는 방법.

Images