JP2020506564A

JP2020506564A - 汎用インターワーキングおよび拡張性のためのサービス層リソース管理

Info

Publication number: JP2020506564A
Application number: JP2019518452A
Authority: JP
Inventors: リ，クァン; シード，デイル，エヌ．; ４世，ウィリアム，ロバートフリン; ムラディン，カタリナ，エム．; ワン，チョンガン; ディジローラモ，ロッコ; チェン，チュオ
Original assignee: コンヴィーダワイヤレス，エルエルシー
Priority date: 2016-10-07
Filing date: 2017-10-06
Publication date: 2020-02-27
Anticipated expiration: 2037-10-06
Also published as: KR102389004B1; WO2018067939A1; US11240093B2; EP3523724B1; US20220131738A1; US20240080235A1; US20180102934A1; EP3523724A1; JP7090603B2; US11799711B2; CN117170876A; KR102224379B1; KR20190065372A; CN109997114B; CN109997114A; KR20210027527A

Abstract

サービス層インターワーキングおよびリソースの拡張性をサポートする軽量で動的な仕組みが提供される。たとえば、本願において開示される１つの仕組みは、第三者技術リソースを代表するサービス層リソースのカスタム属性の指定を可能にする新しいサービス層（Service Layer: SL）リソース定義登録手順の定義を含む。本願において開示される第２の仕組みは、サービス層リソースを第三者データモデルにマッピングし、かつ、新しいインターワーキング対象目標変更インジケータをサービス層に与える新しいSLデータモデルマッピング登録手順の定義を含んでいる。さらに、本願において開示される第３の仕組みは、要求をデータモデルマッピングにより与えられるインターワーキング対象目標変更インジケータに基づいてインターワーキング対象リソースに向かって知的に目標変更するSL汎用インターワーキング手順の定義を含んでいる。

Description

（関連出願への相互参照）
本願は、２０１６年１０月７日に提出され、参照によりその内容が全面的に本願に援用されている米国仮特許出願第６２／４０５，５３４号の利益を主張する。

oneM2Mなどの現在のサービス層インターワーキングアーキテクチャは、第三者技術のノードまたはデバイスとインターワークする種々の方法を提供する。これらは、以下を含む。１）第三者技術リソース（LWM2Mオブジェクトためのリソースなど）からサービス層リソースへの標準マッピング、２）非oneM2MデータモデルがoneM2Mリソース内にカプセル化されるトランスペアレントインターワーキング、３）マッピングされたインターフェースがoneM2Mリソースとして顕示され、そのリソースがアクセスされたときに当該要求が目標変更される目標変更インターワーキング、４）非oneM2Mデータモデルインターワーキングのセマンティクスの完全マッピング。各方法には、それぞれの限界がある。標準マッピング方法では、標準化中に第三者技術リソースがサービス層リソースにマッピングされる。このマッピングプロセスは維持が困難であり、かつ、軽量マシンツーマシン（Lightweight Machine-to-Machine:LWM2M）オブジェクトの場合には、維持が不完全であるか、分かりにくいか、または完全に欠けている。トランスペアレントインターワーキングおよび目標変更インターワーキングの両方法は、インターワーキング対象デバイスのデータモデルを完全に隠すので、それによりこれらリソースの使用が対象ドメイン内のアプリケーションに限定される。非oneM2Mデータモデルインターワーキングのセマンティクスの完全マッピングはリソースの１対１マッピングを与えるが、多数の種々の種類のデバイスが存在する場合にはスケーラビリティに欠ける。

サービス層インターワーキングが例外なく効率的に働くようにするために、インターワーキング対象デバイスのデータモデルはすべてのアプリケーションに顕示されるべきであり、かつ、インターワーキング対象デバイスのデータモデルのリソース定義およびマッピングを追加または更新するダイナミックな仕組みを設けるべきである。これらの性能は、サービス層アーキテクチャが種々の垂直市場を単一の水平プラットフォームに集めることを可能にするであろう。また、拡張性のために新しいリソースタイプをサービス層に追加することも可能であろう。本願において開示するのは、サービス層インターワーキングおよびリソース拡張性をサポートする軽量かつダイナミックな仕組みである。

たとえば、本願において開示される１つの仕組みは、第三者技術リソースを代表するサービス層リソースのカスタム属性の指定を可能にする新しいサービス層（service layer:SL）リソース定義登録手順の定義を含む。新しい機能性の一部として、これらのリソース定義を管理する追加手順が導入される。

本願において開示される第２の仕組みは、サービス層リソースを第三者データモデルにマッピングし、かつ、新しいインターワーキング対象目標変更インジケータをサービス層に与える新しいSLデータモデルマッピング登録手順の定義を含む。リソース定義を管理するために使用される同じ手順がデータモデルマッピングを管理するためにも使用され得る。

さらに、本願において開示される第３の仕組みは、データモデルマッピングにより与えられる目標変更インジケータに基づいて要求をインターワーキング対象リソースに向けて知的に目標変更するSL汎用インターワーキング手順の定義を含む。

この概要は、以下の発明を実施するための形態において詳述されるコンセプトのいくつかを簡略化して示すことを目的としている。この概要は、請求される主題事項の重要な特徴または本質的な特徴を示すことも請求される主題事項の範囲を制限するために使用されることも意図していない。さらに、請求される主題事項は、この開示のいずれかの部分において記述されているなんらかの不便を解決する範囲内に限られない。

添付図面とともに例示される以下の説明によりより詳細な理解が得られるであろう。図面の内容は次のとおりである。

図１は、例示oneM2Mサービス層アーキテクチャを示す。図２は、例示oneM2Mリソースを示す。図３は、例示oneM2M XMLスキーマ定義（XML Schema Definition:XSD）ドキュメントを示す。図４は、例示oneM2Mインターワーキングアーキテクチャを示す。図５は、例示軽量M2M（LightWeight M2M:LWM2M）アーキテクチャを示す。図６は、oneM2Mなどのサービス層標準により定義される汎用インターワーキングを含む例示使用事例を示す。図７は、４つのoneM2M mgmtObjリソースにマッピングされたLWM2M Device Objectを示す。図８は、サービス層汎用インターワーキングの例示エンドツーエンド手順を示す。図９は、例示サービス層リソース定義ドキュメント登録手順を示す。図１０は、例示簡略化サービス層リソース定義発見手順を示す。図１１は、例示サービス層リソース定義起動手順を示す。図１２は、例示サービス層リソース定義中止手順を示す。図１３は、例示サービス層データモデルマッピングドキュメント登録手順を示す。図１４は、例示汎用サービス層インターワーキング手順を示す。図１５は、１つの新しい１つのM2M共通サービス機能（Common Services Function:CSF）の作成および既存CSFの更新の例を示す。図１６は、例示oneM2Mリソース定義ドキュメントを示す。図１７は、インターワーキングプロキシエンティティ（Interworking Proxy Entity:IPE）の例示oneM2Mデータモデルマッピングドキュメントを示す。図１８は、サービス層の例示oneM2Mデータモデルマッピングドキュメントを示す。図１９は、oneM2M CSEが新しい特殊化<mgmtObj>リソースをサポートする例示手順を示す。図２０は、例示汎用インターワーキング手順を示す。図２１は、<flexContainer>動作例を示す。図２２は、２社の販売会社に関係するインターワーキング例を示す。図２３は、多数のLWM2Mサーバに関係する知的目標変更を示す。図２４は、例示ユーザインターフェースを示す。図２５Ａは、１つまたは複数の開示実施形態が実現され得る例示マシンツーマシン（Machine-to-Machine:M2M）通信システム、インターネットオブシングス（Internet of Things:IoT）通信システム、またはウェブオブシングス（Web of Things:WoT）通信システムの系統図である。図２５Ｂは、図２５Ａに示したM2M／IoT／WoT通信システムにおいて使用され得る例示アーキテクチャの系統図である。図２５Ｃは、図２５Ａおよび２５Ｂに示した通信システムにおいて使用され得るM2M／IoT／WoTデバイス、ゲートウェイまたはサーバなどの例示通信ネットワーク装置の系統図である。図２５Ｄは、図２５Ａおよび２５Ｂの通信システムのノードが具体化され得る例示コンピュータシステムのブロック図である。

（用語および定義）
この項は、請求される主題事項の範囲を制限するために使用することも以下において述べる用語の範囲をここで与えた定義に限定するために使用することも意図していない。

インターワーキングは、第２の技術のドメイン内における外部技術の働きを指す。たとえば、LWM2Mは、oneM2M内におけるインターワーキングの対象とすることができる。通常、インターワーキングは、２つの技術間のなんらかの形態のプロコトル変換およびデータモデルマッピングを伴う。

LWM2Mは、SLアーキテクチャ内においてインターワーキング対象とされる第三者技術と考えられる。それは、処理（CPU、MCU）およびメモリ（RAM、ROM）の性能の限界により概して本質的に制約されるデバイスの管理およびデバイスのサービスイネーブルメントにおいて使用するために定義される軽量クライアント−サーバプロコトルである。

SLリソースの名称は、名称resourceNameにより表すことができる。この規約は、oneM2Mにおいて使用されている規約のそれと同じである。

リソース起動は、リソース定義がサービス層により使用されるために利用可能にされるSLプロセスである。このプロセスは、要求元を認証すること、リソース定義ドキュメントから情報を抽出してリソース／リソースタイプのスキーマドキュメントを作成すること、サポートされるリソースタイプ属性を発見のために更新すること等を含み得る。

リソース停止は、SLリポジトリからスキーマドキュメントを除去して、それ以降、除去されたスキーマに基づくリソースが作成され得ないようにするSLプロセスである。このプロセスは、リソースタイプがもはや使われなくなり、かつ、以降使われないようにする場合にのみ実行される。

リソース定義は、サービス層リソースタイプを詳細に記述するドキュメントである。このドキュメントは、リソースタイプ、特殊化リソースタイプが存在する場合におけるその名称（たとえば、oneM2Mでは、バッテリはmgmtObjリソースタイプの特殊化である）、バージョン番号、当該リソースツリーにおいてそのリソースのインスタンスを作成できる場合におけるリソースインスタンスの属性、起動手順等のような情報を含む。

リソースインスタンスは、リソースタイプに対応するサービス層リソースツリーのエントリである。インスタンスの属性は、それが作成された目的に関するデータを含む。

リソースタイプは、アプリケーション、コンテナまたはサブスクリプションリソースなど当該リソースの目的を示す。

目標変更は、１つのSLエンティティＡ（たとえば、サーバ）におけるSLのリソースまたは属性に対する要求が要求された情報の存在する別のエンティティＢ（たとえば、デバイス）に向け直されるプロセスである。この場合におけるエンティティＡにおけるSLは、要求元と別のエンティティＢ（たとえば、デバイス）間の変換の仕組みとして働く。

リソーススキーマは、リソースタイプのコンテンツを指定するためのテンプレートである。XSDは、拡張マークアップ言語（Extensible Markup Language:XML）フォーマットのリソーススキーマドキュメントの例である。

XSDは、XMLドキュメントに出現し得る要素および属性、子要素の個数および順序、関連データタイプ、および要素／属性の許容されるデフォルトまたは固定値を示すことによりこのドキュメントの構造を記述する。oneM2Mでは、各リソースタイプが対応するXSDを持ち、それが当該リソースの構造およびリソースに含まれる情報を示す。

（M2M／IoTサービス層）
M2M／IoTサービス層（SL）は、特にM2M／IoTデバイスおよびアプリケーション向けの付加価値サービスの提供を目指す技術である。oneM2Mなどの世界標準団体により、TS-0001 oneM2M Functional Architecture, V-2.10.0において明示されたインターネット／ウェブ、セルラーネットワーク、企業ネットワークおよびホームネットワークの展開へのM2M／IoTデバイスおよびアプリケーションの統合に関する諸問題に対処するM2M／IoT SLが開発されつつある。oneM2M SLアーキテクチャの例を図１に示す。この図は、共通サービスエンティティ（Common Services Entity:CSE）に関する種々の基準点を示している。Mcaインターフェースはアプリケーションエンティティ（Application Entity:AE）へのサービス層アクセスを与えるのに対し、Mcc基準点およびMcc’基準点は、CSE〜CSE通信を可能にする。最後に、Mcnインターフェースは基盤ネットワーク技術へのアクセスを提供する。

oneM2Mアーキテクチャは、図１に示すように非oneM2M技術とインターワーキングする性能も提供する。これらのインターワーキング対象デバイスは、非oneM2Mデバイスノード（Non-oneM2M Device Node:NoDN）とも呼ばれ、そしてそれらの当該アーキテクチャへの包含は、oneM2Mがすべての垂直市場と相互運用できる水平プラットフォームであるとそれが正しく主張できる１つの主要な理由である。

M2M／IoT SLは、アプリケーションおよびデバイスに一連のM2M／IoT指向性能へのアクセスを提供し得る。これらの性能の例は、セキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニングおよび接続性の管理を含む。これらの性能は、M2M／IoT SLによりサポートされるメッセージフォーマット、リソース構造、およびリソース表現を利用するアプリケーションプログラミングインターフェース（Application Programming Interface:API）経由でアプリケーションにとって利用可能となる。

（サービス層リソース管理）
リソース指向サービス層アーキテクチャでは、リソース管理によりアプリケーションおよびデバイスが相互に通信する手段を提供する。oneM2Mでは、リソースは、エンティティ間のデータ交換を提供するために属性および子リソースを持っている。たとえば、図２に例示するoneM2Mリソースでは、楕円形が属性を示し、また、矩形（たとえば、<subscription>）が子リソースを表している。属性は、対応するリソースのデータモデルを指定するが（たとえば、memAvailableおよびmemTotal）、属性は、当該リソースのmgmtDefinitionおよび記述属性などの追加情報を提供するメタデータを含むこともできる。リソースは、標準により指定される属性および子リソースを定義している可能性がある。これを踏まえて、リソースおよび属性の内容、サポートされるデータタイプ、特定のリソースがリソースツリーに属する場合における一定のリソースまたは属性の多重度、当該リソースタイプを記述するスキーマドキュメント、リソースの作成中に行われるXSD検証等は、すでに標準により定義されている。リソースのセマンティクスおよびリソースへのアクセスを管理するために使用される手順は、総称してリソース管理と呼ばれる。

定義された属性を持つ大部分のoneM2Mリソースとは異なって、リソース属性をカスタマイズできる２つのoneM2Mリソースタイプが存在する。<mgmtObj>および<flexContainer>リソースである。<mgmtObj>および<flexContainer>リソースは、対応する汎用リソースの特殊化の定義を可能にする。換言すると、これらのリソースは、他のoneM2Mリソースには存在しない特殊化機能性のための<mgmtObj>または<flexContainer>リソースのカスタム属性の定義を可能にする。<mgmtObj>リソースは、TS-0004 Service Layer Core Protocol, V-2.5.0およびTS-0006 Management Enablement (BBF), V-1.1.4において考察されている基盤技術に対する標準化マッピングを必要とすることがある。<flexContainer>リソースはcontainerDefinition属性を含んでおり、この属性では当該リソースのスキーマへのリンクまたはユニフォームリソースインジケータ（Uniform Resource Indicator:URI）がサービス層に与えられている。しかし、サービス層がこの属性により行うことを記述する手順は、現在、定義されていない。

各リソース定義に関連するものは、属性および親リソースが持ち得る子リソースを記述するXSDドキュメントである。また、XSDドキュメントは、属性および子リソースが出現しなければならない順序、それぞれの多重度および関連データタイプを指定する。XSDからのこれらの「規則」は、リソース作成時に検証される。［メモリ］特殊化<mgmtObj>リソースのoneM2M XSDドキュメントの例を図３に示す。このXSDドキュメントは、［メモリ］リソースが２つのリソース固有属性（“memAvailable”および“memTotal”）を持っていること、および当該リソースが公表可能であるか否かの表示を示している。また、すべての属性の順序およびそれぞれの属性に関するその多重度、それが必須または任意であるか、および関連データタイプは、すべてXSDドキュメントにより与えられる。その結果、XSDドキュメントは、SLが当該リソースを管理し、かつ、そのリソースへのアクセスに関心を持つアプリケーションにそれを顕示するために必要とする情報を定義する。

（サービス層インターワーキング）
SLインターワーキングは、SLアーキテクチャがすべての垂直市場にとっての水平プラットフォームになることを可能にする主要な構成要素である。oneM2M内の典型的インターワーキング構成を図４に示す。非oneM2Mエンティティがインターワーキング対象である場合、非oneM2MプロコトルとoneM2Mプロコトル間の変換のためにインターワーキングプロキシエンティティ（Interworking Proxy Entity:IPE）が必要である。変換の構成要素は、oneM2Mリソースから非oneM2Mデータモデルへのマッピングおよびその反対を含む。一般的にIPEは、Mcaインターフェースを使用するCSEにインターフェースするoneM2M AEとして実現される。Mcaインターフェースのほかに、IPEは、インターワーキング対象エンティティと自己のネイティブプロコトルにより通信する非oneM2Mインターフェースを持つ。

３つの形態のoneM2MインターワーキングがTS-0001により規定されている。これらは、非oneM2MデータモデルのセマンティクスからMcaへの完全マッピングによるインターワーキング、コード化非oneM2MデータのトランスペアレントなトランスポートのためのコンテナおよびMca経由のコマンドを使用するインターワーキングおよびAEまたはCSEリソース経由で目標変更の仕組みを使用するインターワーキングを含む。

非oneM2Mデータモデルインターワーキングのセマンティクスの完全マッピングは、インターワーキング対象デバイスのリソースを適切なoneM2Mリソースおよび属性に１対１でマッピングするIPEまたはAEを含む。たとえば、温度、湿度および光のセンサを備えるデバイスの場合、IPEまたはAEは、それぞれ個々のセンサを表す３つのoneM2Mリソースを作成する。これは、完全マッピングと考えられる。その結果、インターワーキングのためのデバイスをサポートするIPE／AEの設計中に手作業プロセスが開始される。このプロセスは、サービス層とのインターワーキングの対象となるそれぞれの新しいデバイスにとって必要である。

トランスペアレントなインターワーキングは、非oneM2MデータモデルをoneM2Mコンテナリソース内にカプセル化することおよびAEに対しデータのコード化および復号を要求することを含む。oneM2Mリソース内における情報のこのトンネリングは非効率的であり、かつ、AEを複雑化する。その結果、基盤のデータモデルおよびプロコトルの必須知識を持つAEのみこのコンテナリソース中にカプセル化されたデータを使用し得る。

他方、目標変更インターワーキングは、サービス層の提供する大部分の機能性を完全に回避する。この形態のインターワーキングでは、AEまたはCSEは、oneM2Mリソースのマッピングされるインターフェースを提供し、かつ、リソースがアクセスされるときに動作はIPEに目標変更される。この場合、データモデルの内容に関する情報は提供されない。

上述した３つの形態のインターワーキングのほかに、４番目の形態のインターワーキングがoneM2M仕様書TS-0001、TS-0004、およびTS-0006のデバイス管理の節において記述されている。デバイス管理の場合、<mgmtObj>リソースは、基盤デバイス管理（Device Management:DM）技術のデータモデルを表す標準化oneM2Mリソースであり、そしてAEはこれらの<mgmtObj>リソースにアクセスしてデバイスを管理する。

（OMA LWM2M）
LWM2Mプロコトルは、制約の多いデバイスにより適する簡単かつ平板なリソース構造を特徴とするクライアント−サーバアーキテクチャに基づいている。LWM2Mプロコトルに関する追加情報は、Open Mobile Alliance（OMA）Lightweight Machine to Machine Technical Specification, Version 1.0に記載されている。リソースツリーは、階層レベルの少ない平板な構造で組織された基盤リソースを持つLWM2Mオブジェクトとして定義される。LWM2Mにおけるオブジェクトおよびリソースの定義は、それぞれ、oneM2Mアーキテクチャにおけるリソースおよび属性の定義にマッピングされる。典型的LWM2Mアーキテクチャを図５に示す。

デバイス管理をサポートするほか、LWM2Mプロコトルは、制約されるデバイスにより提供されるサービスイネーブルメントもサポートする。制約されるデバイスは主に特定のアプリケーションのデータ測定値を提供するので、情報報告がプロコトルにおいて指定される主要なサービスイネーブルメントである。したがって、オブジェクトの設計は、デバイス管理および情報報告をサポートするリソースの提供に重点を置く。

（既存サービス層標準を使用する例示展開シナリオ）
図６は、例示サービス層展開シナリオを示す。この例では、サービス層（たとえば、oneM2Mサーバ）がLWM2Mインターワーキングをサポートする。展開時点において、サービス層は、TS-0001、TS-0005 Management Enablement (OMA), V-1.4.1、およびOMA LWM2M Technical Specificationにおいて指定されているLWM2Mオブジェクトをサポートする。図６に示されているように、Customer1はOMA LWM2M Technical Specificationにおいて定義されているLWM2MオブジェクトをサポートするDevice1を最初に展開し、そしてApp1がDevice1を管理するために使用される。しばらく後に、Device1がTS-0001または TS-0005において定義されていないLockWipeおよびConnectivity Managementオブジェクトなどの一定の拡張LWM2Mオブジェクトにより更新される。新しいLWM2Mオブジェクトは、当初にTS-0001およびTS-0005において指定されていないので、それはサービス層によりサポートされない。さらに、Customer1は、TS-0005またはOMA LWM2M Technical Specificationのいずれにおいても定義されていない一定の販売会社固有LWM2Mオブジェクトを含むDevice2を展開する。ここでも、サービス層は、これらの新しいオブジェクトをサポートできない。

別の例では、２つの異なる技術、たとえば、oneM2Mおよびオープンインターネットコンソーシアム（Open Internet Consortium:OIC）によりデバイスを管理しているCustomer2がその操作の一元管理を希望する。Customer2は、すでにApp2を使用してそのサービス層デバイスを管理しているので、このサービス層にOICデバイスを移行させたい。このように、Customer2はApp2のみを使用してそのデバイスのすべてを管理し得る。前述したＬＷＭ２Ｍシナリオと同様に、Customer２は、このサービス層を使用するDevice3を管理することはできない。このOICデバイスはサポートされないからである。

上述したシナリオは、汎用インターワーキングがoneM2Mなどのサービス層標準により定義されているという点における相違を示している。現在、oneM2Mは、たとえば、LWM2M（TS-0014 TWM2M Interworking, V-0.13.0において記述されている）、AllJoyn（TS-0021 oneM2M and AllJoyn Interworking, V-0.3.0において記述されている）、およびOIC（TS-0024 OIC Interworking, V-0.4.0において記述されている）などのインターワーキング対象技術のデータモデルのリソースマッピングを抽象的な方法により定義している。これらのマッピングは、不完全であるか、分かりにくいか、または完全に欠けている。たとえば、LWM2Mの場合、データモデル間の１対１マッピングが存在しない。さらに、LWM2M Firmware Update Objectは、そのリソースすべてをoneM2M[firmware]属性にマッピングさせない。図７に示すように、LWM2M Device Objectは、４種類の異なるoneM2M <mgmtObj>にマッピングされる。最後に、LWM2M Connectivity Monitoring and Connectivity Statusオブジェクトは、oneM2Mリソースにマッピングされない。

２つの別のoneM2Mインターワーキング方法は、インターワーキング対象デバイスのデータモデルをサービス層から完全に隠す。これらの場合、インターワーキング対象リソースは、CSE、AE、またはコンテナリソースとして表現され得る“Content Sharing Resources”中にカプセル化される。トランスペアレントなインターワーキングでは、非oneM2Mデータモデルはコンテナリソース中にカプセル化されるが、この場合、アプリケーションはデータのコード化および復号を要求される。このコード化および復号の要求のために、oneM2Mアプリケーションは、oneM2Mプロコトルおよびインターワーキング対象技術のプロコトルを理解する必要がある。同様に、目標変更インターワーキングは、サービス層の提供する大部分の機能性を完全に回避する。この形態のインターワーキングでは、CSEまたはAEリソースを作成してインターワーキング対象エンティティを表現し、かつ、このリソースに対する要求がIPEに目標変更されるのが通例である。インターワーキング対象データモデルをサービス層から隠すことにより、これらの２つの方法は、インターワーキングを対象ドメイン内のアプリケーションに限定する。

非oneM2Mデータモデルインターワーキングのセマンティクスの完全マッピングでは、インターワーキング対象データモデルのoneM2Mリソースへの１対１マッピングが行われる。しかし、この完全マッピングが行われるプロセスは本質的に手作業であり、また、IPE／AEの設計中に行われる。この方法は、多数の異なる種類のタイプのデバイスが存在する場合には規模の変化に適切に対応しない。各デバイスがそれ自身のマッピングおよびIPE／AE設計の更新を必要とする。

最後に、図６に示した例は、oneM2Mなどの水平サービス層プラットフォームの重要な機能のサポートの欠如を強調している（販売会社固有のデータモデルを効率的かつ動的にサポートする能力）。oneM2M標準は、インターワーキングをサポートするためにカスタマイズされ得るリソース、たとえば、<mgmtObj>および<flexContainer>リソースをすでに提供している。しかし、oneM2Mは、現在、リソース属性を動的にカスタマイズする機能を活用する手順を欠いている。これらの販売会社固有のリソースは、同一の垂直市場に存在する販売会社にとって自己の製品提供物を差別化し、かつ、自己のプラットフォームの付加価値を示すために重要である。拡張されて種々の垂直市場の販売業者を包含するようになった場合、かかる動的なインターワーキングの仕組みの便益が拡大する。

（サービス層アーキテクチャ内の汎用インターワーキング）
サービス層インターワーキングが例外なく、かつ、効率的に働くために、インターワーキング対象デバイスのデータモデルがすべてのアプリケーションに顕示されるべきであり、また、インターワーキング対象データモデルのリソース定義およびマッピングを追加または更新する動的な仕組みが存在するべきである。これらの機能は、サービス層アーキテクチャが種々の垂直市場を単一の水平プラットフォームに集めることを可能にする。さらに、拡張性のために新しいリソースタイプをサービス層に追加することができる。本願において開示されるのは、サービス層インターワーキングおよびリソース拡張性をサポートする軽量で動的な仕組みである。

たとえば、図８は、サービス層アーキテクチャ内の汎用インターワーキングを可能にする典型的エンドツーエンド手順の高レベル概要を示す。図８は、図４に示したインターワーキングアーキテクチャの１つの実現である。本願において考察されているように、第三者データモデルの１対１マッピングは、インターワーキングの一環としてサービス層リソースに提供し得る。さらに、このサービス層は、新しいリソースタイプまたは既存リソースタイプの組み合わせをサポートするように構成され得る。しかし、新しいリソースタイプは、当該サービス層によりサポートされる動作に限定される。新しいリソースタイプのために新しい機能性またはサービスが必要な場合、新しいリソースタイプをサポートするためにはそれらの機能性またはサービスを可能にする代わりの手段を利用可能にしなければならない。

本願において開示される１つの特徴に従って、標準仕様におけるリソースタイプの定義方法に準じてリソース定義ドキュメントによりリソースタイプを記述する。たとえば、oneM2M＜AE＞はTS-0001において記述され、その中においてAEの属性および子リソースがリストされ、AEの一般的な属性、それがリソースツリー中に存在する場所、その属性の多重度、および対応するデータタイプを持つ子リソース等が示されている。さらに、プロコトルバインディングは、TS-0004において規定される。ここでは、以下が指定され得る。データタイプおよびXSDまたはスキーマファイル、使用されるショートネーム、要素属性の選択性、リソースへのアクセスの手順等。これらの情報のすべては、リソース定義ドキュメントに含まれている。このドキュメントは、サービス層がリソース定義を起動して使用のためにそれを有効にする方法に関する追加指示も含んでいる。

本願において開示される別の特徴に従って、データモデルマッピングドキュメントを使用して第三者リソースからサービス層リソース属性への１対１マッピングを行うことができる。その結果、それは、リソース固有属性を記述するスキーマファイルの一部に類似する。このドキュメントは、サービス層リソース属性からLWM2Mに関するTS-0005において規定されているリソースなどの第三者リソースへのマッピングを提供する。この情報は、プロコトル変換中に使用される。さらに、このデータモデルマッピングドキュメントは、各リソース属性がメッセージングトラフィックを最小にする検索要求の目標変更時期についてサービス層に指示する目標変更インジケータを含んでいる。

図８に示すように、IPEは、インターワーキング対象デバイスに関する新しいリソース定義によりまずプロビジョニングされる。このリソース定義は次にサービス層に登録され、それにより新しいリソースの管理がサービス層の動作に追加される。次に、データモデルマッピングがIPEに対してプロビジョニングされ、インターワーキング対象デバイスのデータモデルがこのIPEにおいてSLリソース属性に対してマッピングされる。このデータモデルマッピングもサービス層に登録されて、インターワーキング対象リソースに対するメッセージングを最適化する目標変更インジケータを与える。インターワーキング対象デバイスは次に登録されるかまたはIPEに対してプロビジョニングされ、これによりIPEは当該デバイスをサービス層に登録する。たとえば、LWM2MデバイスはLWM2Mサーバ（これはIPEの一部である）に登録し、次にIPEはこのデバイスをサービス層に登録する。

最初の手順として、図８には示されていないが、IPEおよびサービス層は、たとえば、SL登録およびアクセス制御プロビジョニングを包含することにより、相互に安全に通信するためにプロビジョニングされる。図８は、リソース定義とデータモデルマッピングドキュメントの両方をサービス層に登録するIPEを示している。同様に、SL管理アプリケーションまたはサーバアドミニストレータもこれらのドキュメントをIPEではなくサービス層に登録することができる。用語、IPE、SL管理アプリケーション、およびサービス層アドミニストレータは、同じ意味で使用することができる。

登録手順のすべてが完了した後（すなわちステップ１〜５が完了した後）、アプリケーションはサービス層のリソース発見手順を使用して新しいインターワーキング対象デバイスリソースを見出すことができる。次にアプリケーションは、インターワーキング対象リソースを目標にする要求を行い、また、サービス層は、汎用インターワーキング手順を開始するか否かの決定を下すためにインターワーキング対象目標変更インジケータの基準を評価する。開始する場合、サービス層は、アプリケーションの要求をIPEに目標変更し、これによりIPEはSLプロコトルからインターワーキング対象デバイスのネイティブプロコトルへの汎用インターワーキングマッピングを行う。ここで注意すべきは、一部のSL要求は、要求されたデータの性質が静的である場合には、IPEに目標変更されないことである。しかし、静的データを検索するためには少なくとも１つの目標変更される要求が必要である。インターワーキング対象デバイスから返された応答は、IPEからサービス層に中継され、最後にアプリケーションに達する。サービス層は、目標変更インジケータに応じて応答をキャッシュし得る。

（SLリソース定義ドキュメント登録手順）
本願において開示される第１の特徴に従って、サービス層におけるインターワーキングを有効にする前に、インターワーキング対象デバイスリソースからSLのリソースおよび属性への１対１マッピングを与えるためにリソース定義を規定する。このリソース定義は、リソースタイプが定義される標準化中に行われる同じ作業、特殊化リソースタイプが存在する場合にそれに与えられた名称、リソースタイプの属性および子リソース、リソースの作成の検証のために使用されるリソースを記述するスキーマドキュメント、およびリソースを管理するその他の情報および手順を本質的に反映する。リソース定義のために必要な情報は、本文書中の着想を使用するサービス層への登録のために、そのときにIPEにプロビジョニングされているドキュメント、管理アプリケーション、またはサーバアドミニストレータ中に取り込まれる。

１対１マッピングは、２つのステップからなる。すなわち、当該デバイスへのアクセスや管理のために必要なネイティブデータモデルを識別すること、および当該デバイスのネイティブデータモデルをサービス層のリソースおよび属性にマッピングすること。マッピングの結果は、SLリソース定義ドキュメントとデータモデルマッピングドキュメントの両方を作成する。リソース定義ドキュメントは、新しいリソースまたはリソースタイプ、すなわち新しいカスタムリソースまたはカスタムリソースタイプを定義するためにSLに与えられる一方、データモデルマッピングドキュメントはインターワーキングのためにSLに与えられる。SL内において、データモデルマッピングドキュメントは、サービス層がリソースの要求を目標変更するべき時期を示す目標変更インジケータを与える。IPEは、プロコトル変換と目標変更の両方のためにデータモデルマッピングドキュメントを使用する。プロコトル変換は、インターワーキング対象デバイスが理解する新しいメッセージの作成を含み得る。目標変更は、IPEがサービス層に返す応答を得るためにインターワーキング対象デバイスと通信することを含み得る。

リソース定義およびデータモデルマッピングが完了した後、ドキュメントがIPEにプロビジョニングされてサービス層への対応する登録が開始される。IPEは最初にリソース定義をサービス層に登録する。この登録は、現在のSL登録とは異なる。それは、SLにSLリソースの新しいインスタンスの作成を要求するのではなく、新しいリソース定義を登録するからである。その結果、登録要求の目標URIは仮想リソース宛てであり、それはSLにとってリソース定義が登録中であることを意味する。

通常のSLリソースの代わりに仮想リソースを目標にすることの目的は、当該登録動作が通常モードの動作ではなく、かつ、リソースインスタンスがリソースツリー中に作成されないことをサービス層に通知することである。しかし、新しいサービス層リソースは、サービス層がサポートするすべてのリソース定義をホストするリソースツリー中にも作成され得る。この場合、登録要求の目標URIは、新しいSLリソースを目標にする。たとえば、新しい“resourceDefinitions”リソースは、すべてのリソース定義を記憶するＳＬリソースツリー中に作成され得る。目標URIは、たとえば、“/resourceDefinitions”または“/<SL_name>/resourceDefinitions”の形態とすることができる。この場合、リソース定義は、仮想リソース方法を使用するリソース定義がもたない２つの追加属性を包含しなければならない。すなわち起動および停止。これらの属性は、以下において説明するリソース定義の使用を可能にするために利用される。

サービス層は、いくつかの方法によりリソース定義登録を管理することができる。サービス層は内部リポジトリにリソース定義を保存し、そこで当該リソースを目標にする将来の要求を検証するためにそれを使用することもできる。これは、サービス層サーバ内の一定の場所にファイルを保存することとして実現し得る。別の方法として、サービス層は、サービス層のレジストラントに通常のリソース発見経由でリソース定義を顕示するためにリソースツリー中にリソースを作成することもできる。これは、現在のサービス層リソースが処理される方法である。さらに、２つの別案を組み合わせて、よりトランスペアレントであり、弾力的かつ機能的な動作を実現し得る。

図９は、以下において説明するようにIPEがサービス層に対して行う典型的なリソース定義登録手順を示す。

ステップ１において、インターワーキング対象デバイスのリソース定義ドキュメントによりIPEがプロビジョニングされた後に、IPEはこのドキュメントをサービス層に登録する。登録要求において、IPEは、当該登録がリソース定義のための登録であることを示すために仮想リソースを目標にする。仮想リソースの例示URIは、/<SL_name>/resourceDefinitionsの形態とし得る。要求に含まれるのは、インターワーキング対象デバイスのリソース定義ドキュメントである。このドキュメントは、サービス層がリソースを管理し、かつ、リソース発見のためにそれを顕示するために必要な情報を含む。表１は、リソース定義ドキュメントを構成する種々の構成要素を示す。提供される情報は、サービス層がリソース定義ドキュメントから起動後に使用するためにoneM2M XSDドキュメントを抽出することを可能にする。別の方法としてURIを登録要求中に与えることもできる。この場合、サービス層はこの登録要求からリソース定義ドキュメントを取り出すことができる。

リソース定義をサービス層に明示的に登録する代わりに、リソース定義登録は、スキーマドキュメントへのURIを与える属性を持つリソースの作成により暗黙に引き起こされ得る。この場合、サービス層は、ステップ２において要求を処理してスキーマドキュメントを登録するとともに定義を起動する。この代替案は、スキーマファイルのロケーションを指定する属性を含む既存サービス層リソースに限られ、かつ、サービス層において新しいリソースタイプを作成するために使用することはできない。

ステップ２において、サービス層は、IPEにより与えられたリソース定義を評価してそれが表１において指定されている必要な要素のすべておよび各要素内の必須情報のすべてを含んでいることを検証する。情報要件は実施形態固有であることに注意する。これは、提供された起動基準のコンテンツについて特に重要である。URIがステップ１において与えられた場合、サービス層はリソース定義を評価する前にまずドキュメントをダウンロードする。リソース定義が有効であり、かつ、受け入れ可能であると決定した後、サービス層は、リソース定義の起動において使用するために、当該ドキュメントをそのリソース定義リポジトリに追加する。

この手順がスキーマドキュメントへのURIを含むサービス層リソースの作成により引き起こされたとき、サービス層は、取り出したスキーマドキュメントを起動するために追加処理を行う。この追加処理は実施形態に依存し、かつ、以下を含み得る。スキーマドキュメントが適切に形成されていることを検証すること、スキーマドキュメントをサービス層のローカルリポジトリに保存すること、スキーマドキュメントをリソース発見のために利用可能とすること等。

ステップ３において、サービス層は、適切な応答をIPEに送る。作成が正常であった場合、サービス層は、リソース定義の検索において使用するためのURIを提供することができる。このURIは、ステップ１からの仮想URIプレフィックス、リソース定義のためにサービス層によりプロビジョニングされたリソース名称またはその他の識別子、およびリソース定義のバージョンから構成され得る。スキーマドキュメントへのURIを含むリソースの作成により手順が引き起こされた場合には、サービス層は通常の作成応答を当該スキーマドキュメントにアクセスするURIとともに返す。

図９に記載した手順は、リソース定義登録要求を行うIPEを示している。別案として、この要求は、サービス層管理アプリケーションにより行い得る。この管理アプリケーションは、サービス層の動作を管理するために使用することができ、また、サーバの動作を変更するための特殊アクセス特権を持ち得る。このアプリケーションは、サービス提供会社またはサービス層所有者により制御され得る。第３の代案は、サービス層アドミニストレータがリソース定義登録を行うことである。この機能性はサービス層動作に組み込むことができ、また、ウェブインターフェース、コマンドラインインターフェース、またはその他の仕組みにより実現し得る。

図９に示した手順を使用してサービス層展開時点において存在しなかった新しいリソースタイプを定義し得ることに注意する必要がある。たとえば、サービス層は、リソース定義のリリース１に基づいて展開される。展開後、新しいリソースタイプがリリース２において作成される。この項において概説した手順を使用して、サービス層を更新して新しいリソースタイプをサポートすることができる。さらに、この手順は、同一リソースタイプの種々のバージョンをサポートすることも可能にする。これは、サービス層が同一リソースの異なるバージョンを使用するレガシーデバイスと新しいデバイスの両方とともに動作することを可能にする。

（SLリソース定義管理手順）
リソース定義が登録された後、サービス層は、当該定義を発見、検索、更新、削除、起動、および停止する手順により管理する機能を提供する。注意すべきは、リソース定義の管理により定義にアクセスする手順の進め方が決定されることである。サービス層がリソース定義をソースツリー中のリソースとして顕示する場合、通常のSL要求（発見、検索、更新、および削除）を使用してリソース定義にアクセスする。しかし、サービス層がリソース定義をファイルに保存し、かつ、それを内部リポジトリに格納する場合、リソース定義にアクセスする以下の手順が定義される。

リソース定義の管理は、２組のリポジトリに関係する。１つはリソース定義ドキュメント用であり、他の１つはスキーマドキュメント用である。リソース定義ドキュメントは、以下に述べる起動手順中にサービス層により使用されて対応するスキーマドキュメントを生成する。その結果、それらのドキュメントは、別々のリポジトリに格納される。リソース定義リポジトリは、IPE、管理アプリケーション、または厳重な許可プロセスによりアクセスを与えられるサービス層アドミニストレータにとってのみアクセス可能とすることができる。このリポジトリを使用してサービス層がサポートするすべてのリソースのリソース定義を示すことができ、また、このリポジトリには通常のサービス層動作中にはアクセスできない。スキーマドキュメントリポジトリに対するアクセスは、サービス層自体およびそのアドミニストレータのみに限定することができる。それは、リソースの作成要求の検証などの通常の動作中に使用されるからである。この制限は、IPEなどの外部エンティティによるサービス層の動作の妨害を予防するために設けることができる。その結果、IPEおよび管理アプリケーションは、スキーマリポジトリに対する読み取りアクセスのみ可能となる。

これらの管理手順は、サーバアドミニストレータなどの許可されたエンティティが新しいリソースタイプを作成するためのみならず既存リソースタイプに基づいて新しいリソースタイプを定義するためにサービス層と相互動作することを可能にする。アドミニストレータは、このインターフェースを使用して既存リソースタイプを発見し、読み出して、読み出したリソースタイプに基づいて新しいリソースタイプを作成することができる。サービス層もこのインターフェースを使用してリソース定義ドキュメントを他のサービス層と交換することにより自己の動作を更新することができる。さらに、リソースタイプの変更が標準化により行われた場合に同一リソースタイプの新しいバージョンを作成することができる。最後に、許可された販売会社は、自社の製品提供物を差別化するために、自社固有のリソースを定義し、かつ、このインターフェースを使用して自社のリソースを登録することができる。

（リソース定義発見）
既存SLリソース発見と同様に、リソース定義発見は、サービス層によりサポートされるリソース定義を見出すために行われる。リソース定義登録のために使用される同一目標URIをリソース定義発見のために使用することができる。サービス層リソース発見手順の簡素化バージョンを使用してこれらのリソース定義を発見し得る。既存SL発見とこの簡素化発見間の差異は、目標URIが仮想リソースであり、かつ、濾過基準が発見基準により置き換えられることである。この発見要求はリソース定義に重点を置いているので、より複雑な濾過基準を使用する必要がない。より前に作成された、以降に変更された、より上のサイズ、限界、semanticsFilter等のような属性は、リソース定義発見要求に適用されない。図１０は、以下において説明される典型的簡素化発見手順を示す。

ステップ１において、アプリケーションまたはIPEは、リソース定義を登録するときに使用されるURIなどのSLリソースを目標にするRetrieve動作を行う。この要求は、特定のリソース定義の探索を狭める発見基準を含むことができる。この発見基準は、キーと値の対のリストから構成することができる。これらの基準の例を表２に示す。

ステップ２において、サービス層は要求を受け取り、発見基準を識別し、かつ、その内部リポジトリを探索して要求されたリソース定義を見出す。複数のリソース定義が見出された場合、サービス層はリソース定義名称のリストを作成することができる。

ステップ３において、サービス層は、発見基準に合致するリソース定義名称および関連バージョンのリストを適切な応答コードとともに返す。ここで注意すべきは、リソース定義名称がバージョン番号および同一リソース定義の複数のバージョンを含み得ることである。オプションとして、返されるリストは、リソース定義ドキュメントやスキーマドキュメントのURIを含むことができ、これらのドキュメントによりIPEは当該定義またはスキーマドキュメントのコンテンツを検索することができる。

（リソース定義検索）
リソース定義の名称またはURIが発見された後、アプリケーションまたはIPEは所望定義のコンテンツを検索することができる。この要求はリソースのSL検索要求のそれと同様であるが、相違は、当該要求のURI（それは仮想URIとリソース定義名称の連結である）およびサービス層がその内部リポジトリからリソース定義名称をフェッチしてくるという点で異なる。検索要求に対する応答は、リソース定義および当該定義が起動されているか否かのインジケータを含む。URIをスキーマドキュメントに与えるリソースの作成によりリソース定義登録が自動的に開始された場合、スキーマドキュメントにアクセスするURIが当該作成要求に応じてまたは上述したリソース定義発見手順経由で与えられる。

（リソース定義更新）
リソース定義が内部リポジトリにより管理される場合、それはファイル経由となるので当該定義の更新について若干の規則がある。更新がリソース定義ドキュメント中にすでに存在する項目の値の変更に関係する場合、部分的な更新が許容される。更新要求は、変更を要する値を示す。しかし、更新がファイルのコンテンツの追加または削除に関係する場合、アプリケーションまたはIPEは、図９により指定されるCreate要求を使用して定義ファイル全体を更新する必要がある。これは、サービス層に対し当該ファイルの構文解析、当該ファイル更新箇所の特定および当該ファイルへの新しいコンテンツの追加を要求しないことにより定義ファイルの管理の簡素化をもたらす。

（リソース定義削除）
リソース定義は、起動される前に、または停止された後に削除することができる。この手順はリソースのSL削除と同様であるが、この削除はリソースツリー中のリソースインスタンスではなくリソース定義ファイルを対象とする点が異なる。ここで注意すべきは、リソース定義が起動されている場合、それをリポジトリから除去できないことである。これは、当該定義に基づくリソースが依然として使用されている間にリソース定義が削除されることを防止する。リソース定義が起動されているが、リソースが使用されていない場合、当該リソース定義ファイルの削除を許容するか否かはサービス層次第である。

（リソース定義起動）
リソース定義が登録された後、当該リソース定義はサービス層による使用のためには起動されなければならない。リソース定義がサービス層により使用できるようになる前に起動のプロセスを使用して種々のチェックおよび手順を開始することができる。開始できることの例は、以下を含む。１）要求元がリソース定義を起動できることを確認するサービス提供会社またはサービス層の所有者による許可チェック、２）図３において説明したようなスキーマドキュメントのリソース定義ドキュメントからの抽出、３）抽出されたスキーマドキュメントが適切に作成されていることの検証、および４）スキーマドキュメントをサービス層スキーマリポジトリに保存すること、およびリソース発見の仕組みの更新を含むサービス層動作への組み込み。この起動プロセスにはその他の用途が考えられ、また、上述の種々の用途は起動プロセスの一環として組み合わせることができる。起動が完了した後、サービス層は抽出されたスキーマドキュメントを使用して自分自身のリソースツリー中にリソースを作成することができる。

起動プロセスは、それが、たとえば、新しいリソースタイプの作成要求または既存リソースタイプの変更、およびスキーマおよびデータベースのリポジトリの変更（リソースインスタンスを作成するため）を検証することによりサービス層の動作を変更するので、重要である。さらに、標準アクセスコントロールチェックの場合より多くの許可チェックが行われ得る。起動は、正しく行われない場合にサービス層における不要な動作を引き起こすからである。図１１は、以下において説明する起動プロセスから生じ得るいくつかの動作を示す。

ステップ１において、アプリケーションまたはIPEは、仮想リソースのURIを目標にするCreate要求、リソース定義名称（そのバージョン付き）、およびURIの末尾の“/activate”を送る。別案として、リソース定義がSLリソースツリーに作成された場合には“activate”属性を目標にすることもできる。この要求は、当該サービス層内で起動手順を開始させる。リソース定義ファイルは起動基準を与える。次にこれらの基準はサービス層により読み取られ、それにより行うべき動作が決定される。動作によっては、それは前に行われた他の動作に依存する。たとえば、リソース定義ドキュメントからのスキーマドキュメントの抽出は、スキーマドキュメントが適切に作成されていることを確認する前に行われるべきである。その結果、リソース定義ドキュメントの起動基準項のコンテンツは、リソース定義登録が受け入れられる前の厳しいガイドラインおよび検証を含むべきである。

ステップ２において、サービス層は、オプションとして、アプリケーションまたはIPEがリソース定義を起動できるか否かチェックする要求を許可サーバに送ることができる。サービス層の規模および複雑性に応じて、この要求は、第三者またはサービス提供業者の許可サーバに送られ得る。代案として、一定の方針または設定パラメータに基づいてサービス層内においてそれを評価することも可能である。この許可チェックは、URIをスキーマドキュメントに与えるリソースインスタンスの作成により起動手順が開始されたときに行うこともでき、かつ、必要な許可チェックを指定する新しい許可パラメータが追加され得る。

ステップ３において、許可サーバは、適切なメッセージにより応答する。その応答が当該アプリケーションまたはIPEが権限をもたないことを示した場合、サービス層は起動プロセスを中止し、かつ、それに応じてステップ７で応答する。

ステップ４において、アプリケーションまたはIPEが許可された場合、サービス層は、リソース定義をサーバの動作に組み込む。これは、スキーマファイルのリソース定義ドキュメントからの抽出およびその結果のファイルが適切に作成されていることの検証を引き起こし得る。代案として、有効なリソース定義ファイルのデータベースを更新して新しいリソース定義を含めることもできる。さらに、更新を行って発見目的のために新しいリソースタイプを顕示することもできる。

ステップ５において、スキーマドキュメントが適切に作成されていることをサービス層が検証した後に、サービス層は当該ドキュメントを将来使用するためにその内部リポジトリに保存することができる。たとえば、サービス層は、スキーマドキュメントがXML 1.0仕様の明確な構文規則に合致していることを検証し得る。この仕様は、XMLドキュメントが適切に作成されるためには、それが一定の物理的かつ論理的構造を満たさなければならないことを規定している。

ステップ６において、スキーマドキュメントのサービス層動作への組み込みに関する状態が返される。

ステップ７において、サービス層は、起動要求に対する適切な応答を返す。起動プロセス／手順のいずれかが失敗した場合、応答は、アプリケーション／IPEによる欠陥のデバッグを支援するために、失敗したプロセス／手順部分を指示することができる。

（リソース定義停止）
リソース定義停止は起動より簡単である。このプロセスは、サービス層に対し、目標にされた定義を使用するリソースツリー中にリソースが存在しないことを確実にするよう要求するのみであるからである。これは、サービス層が当該リソース定義を目標にする将来の要求を検証する必要がある場合に、定義が利用可能であることを確実にすることである。当該サービス層リソースツリー中のどのリソースも当該定義を使用しない場合、SLは当該リソース定義を停止することができる。図１２は、以下において説明する停止プロセスから導かれ得るいくつかの動作を示す。

ステップ１において、アプリケーションまたはIPEは、リソースインスタンスが該当タイプのSL中に存在しないことから、リソース定義がもはや不要であると決定する。当該リソース定義を目標にする要求がそのバージョンおよび目標URIの末尾に添付された“/deactivate”とともにサービス層に送られる。代案として、当該リソース定義がSLリソースツリーに作成された場合には“deactivate”属性を目標にすることができる。

ステップ２において、サービス層は、それ自身のリソースツリーをチェックして既存リソースインスタンスが当該リソース定義を使用していないことを確認する。当該リソース定義を使用している未解決のリソースインスタンスが存在する場合、停止要求は拒否される。使用中のリソースインスタンスが存在しない場合、サービス層は当該リソース定義を削除する。

ステップ３において、サービス層は、その内部リポジトリからスキーマドキュメントを除去し、かつ、当該リソースタイプを発見対象から削除することができる。

ステップ４において、スキーマドキュメントの除去に関する状態が返される。

ステップ５において、サービス層は、停止要求に関する適切な応答コードを返す。

（SLデータモデルマッピングドキュメント登録手順）
リソース定義が起動された後、IPE、管理アプリケーション、またはサーバアドミニストレータは、データモデルマッピングドキュメントをサービス層に登録することができる。データモデルマッピングドキュメントは、サービス層が要求をインターワーキング対象サービス層リソースに目標変更する方法を記述する目標変更インジケータを与える。データモデルマッピングはプロコトル変換においても使用される。サービス層がこの登録要求中に与えられたデータモデルマッピングをリソース定義から生成されたスキーマファイルに対して処理できるように、最初にリソース定義が起動されることが重要である。データモデルマッピングドキュメントは、生成されたスキーマドキュメントにおいて与えられたリソース固有属性の完全なリストを含むべきである。さらに、このドキュメントは、各SLリソース固有属性のインターワーキング対象データモデルの関連URIを含む。データモデルマッピング（目標変更インジケータを伴わない）のいくつかの例は、LWM2Mに関するTS-0005に記載されている。データモデルマッピングドキュメントは、サービス層リソース固有属性とインターワーキング対象データモデルリソースURI間の１対１対応を与える。

IPEは、リソース定義ドキュメント中のリソース固有属性のリストと同じリストを含むデータモデルマッピングドキュメントによりプロビジョニングされる。リソース固有属性の名称のみ保持される一方、新しいパラメータがデータモデルマッピングドキュメントに追加される。新しいパラメータの一部は、インターワーキング対象データモデルのリソースURIのほか関連データタイプおよび目標変更インジケータを含む。他のパラメータを追加してIPEの追加特徴を説明することができる。リソースURIは、プロコトル変換中にサービス層リソース属性から第三者リソースにマッピングするため、およびその逆のマッピングのために使用されるが、目標変更インジケータパラメータについては以下においてさらに詳しく説明する。

IPEがデータマッピングドキュメントによりプロビジョニングされた後、IPEはこのドキュメントをさらに処理してサービス層への登録において使用するためのコピーを作成することができる。これは、以下において説明するようにIPEの性能に基づく目標変更インジケータ（または他のパラメータ）の変更を含み得る。その場合、IPEにより使用されるデータモデルマッピングドキュメントは、サービス層に登録されるドキュメントとは異なる。

ここで注意すべきは、リソース定義ドキュメントおよびデータモデルマッピングドキュメントのコンテンツを組み合わせて１つのドキュメントにまとめ得ることである。このシナリオでは、やはり上述の手順が適用されるが、ここではリソース定義情報とデータモデルマッピング情報の両方を含む複合ドキュメントに適用される。その結果、リソース定義登録および管理の手順がデータモデルマッピング登録および管理の手順と組み合わされる。リソース定義ドキュメントはデータモデルマッピング情報も含み、また、サービス層は新しい情報をスキーマドキュメントに保存するかまたはそれらを２つのドキュメントとして分離することができる。データモデルマッピング情報は、新しいサービス層リソースタイプまたは変更されたリソースタイプのリソース定義が登録され、かつ、インターワーキングが要求されない場合をサポートするためのオプションとすることができる。

図１３は、以下において説明するデータモデルマッピングドキュメントからサービス層への典型的登録手順を示す。

ステップ１において、IPEは、仮想リソース“/resourceMappings”を目標にするCreate要求を送り、当該登録がリソースマッピングのための登録であることを指示する。完全なリソースマッピングドキュメントがメッセージのペイロードに追加される。

ステップ２において、サービス層は、当該要求により与えられたマッピングドキュメント中のリソース属性名称および関連データタイプが対応スキーマドキュメント中のそれらと合致することを検証する。このチェックは、すべてのリソース固有属性がインターワーキング対象データモデルリソースにマッピングされることを確保する。ここで、マッピング管理が舞台裏で行われ、かつ、リソースツリーにサービス層リソースが作成されないことにも注意するべきである。その代わりに、マッピングは、将来のインターワーキング要求を目標変更するときのサービス層による使用のためにファイルに保存される。

ステップ３において、作成が正常であった場合、サービス層は、リソースマッピングドキュメントのロケーションおよび関連バージョン番号とともに適切な応答を返す。

目標URIの変更を除き、データモデルマッピングの管理手順が上述したリソース定義の手順に続く。“/resourceDefinitions”を使用する代わりに、目標URIは代わりの“/resourceMappings”である。データモデルマッピングの発見基準は、リソース定義のために使用された基準のサブセットである。最後に、データモデルマッピングは、起動または停止される必要がない。これは、リソース定義と連動して動作するからである。リソース定義ドキュメントとデータモデルマッピングドキュメントが結合された場合、この複合ドキュメントのために１組の管理手順のみ必要となる。

（インターワーキング目標変更インジケータ）
インターワーキング対象リソースのURIを与えるほかに、データモデルマッピングはマッピングされる各リソースに関する目標変更インジケータも含み得る。このインジケータは、検索要求を目標変更する時期について各マッピングに関して与えられる目標変更インジケータに基づいてIPEとサービス層の両方に指示を与えることができる。作成要求、更新要求、および削除要求の場合、これらは、SLリソースとインターワーキング対象デバイス上のリソース間の同期を確保するために常に目標変更される。表３は、１つの実施形態による目標変更インジケータの例を示す。他の実施形態でも程度の差はあるが、目標変更インジケータはサポートされ得る。これらの目標変更インジケータの使用は、サービス層を静的または半静的な性質を持つデータに関する不必要な検索要求の実行から解放するのに役立ち得る。

表３に示した目標変更インジケータは、サービス層上でホストされるインターワーキング対象リソースを管理するためにIPEにより使用され得る。サービス層に登録されるマッピングドキュメントは、２つのインジケータのみ含み得る。すなわち１回目標変更および常時目標変更。目標変更インジケータ２および３の場合、インジケータが２または３から１または０のいずれへ自主的に変化するのか否かIPEの性能により決定される。IPEがインターワーキング対象デバイスを管理する第三者サーバと統合されている場合、IPEは目標変更インジケータ２を持つ属性が変化する時期を知り、かつ、SLリソースに対する対応する更新を行い得る。同様に、IPEが周期的更新をサポートする場合、IPEは、目標変更インジケータ３を持つ属性がSLリソースにおいて更新され続けるようにすることができる。両方の場合において、IPEは、サービス層中のリソース属性を動的に更新して新鮮性を確保し、かつ、これらの属性をデータモデルマッピングドキュメント中において１回目標変更に設定する動作を継続する。IPEが２つの性能のうち一方のみをサポートする場合、その性能に関連する属性のみ１回目標変更に設定される。IPEによりサポートされない機能を必要とする目標変更インジケータを持つ属性は、常時目標変更に設定される。

目標変更インジケータは、特定のリソースタイプに適用されるデータモデルマッピングドキュメントの一部として与えられる。これは、同一リソースタイプを使用するすべてのデバイスにとって一貫する目標変更インジケータを保証する。しかし、目標変更インジケータは、各リソースインスタンスに基づくより汎用的な方法で使用されるように拡張され得る。これは、リソースインスタンスレベルにおけるよりきめ細かな目標変更制御を与える。各リソースインスタンスおよび対応するインターワーキング対象リソースは、リソースタイプから独立したそれ自身の目標変更インジケータをもち得る。たとえば、２つのセンサが同一のリソースタイプを使用して温度測定値を異なるアプリケーションに与え得る。家庭に設定される一方のセンサは３０分ごとに温度測定値を必要とする。もう一方の温度センサは、毎分測定値を必要とする化学処理研究所に設置される。関連温度リソースインスタンスが作成されたとき、それぞれが「周期的目標変更」として設定されるが、相異なる周期が指定される。

目標変更インジケータはインターワーキングにおける用途のために提案されるが、このコンセプトは既存サービス層の目標変更にも適用され得る。たとえば、表３において説明した属性のような新しい目標変更インジケータ属性を公表されているリソースに追加してサービス層に目標変更するタイミングについて指示を与えることができる。

（サービス層汎用インターワーキング手順）
本願において開示される第３の特徴に従って、リソース定義ドキュメントとリソースマッピングドキュメントの両方が登録された後、SLアプリケーションは、インターワーキング対象リソースが作成された後に、それらに関する要求を行い得る。SLアプリケーションは、リソース発見を使用してインターワーキング対象リソースを他のSLリソースと同様に見出すことができる。発見した後、アプリケーションは、インターワーキング対象リソースについてRESTful動作を行って他のSLリソースの場合と同様に応答を得ることができる。インターワーキング対象リソースを目標にする要求が行われたとき、汎用SLインターワーキング手順がサービス層とIPEの間で開始され得る。以下において説明するこの手順は、図１４の例に大まかに示されている。

図１４を参照する。ステップ０において、インターワーキングシステムが設定され、かつ、動作可能となる。これは、リソース定義およびデータモデルマッピングの登録、IPEおよびApplicationのSL登録、IWデバイスのIPEへの登録、IPEによるインターワーキング対象リソースおよびサービス層に関する関連サブスクリプションの作成、および種々の関係作用子間の通信を可能にするために必要なすべてのその他の設定を含む。

ステップ１において、アプリケーションは、サービス層リソース発見を行い、探しているインターワーキング対象リソースを見出す。

ステップ２において、サービス層のインターワーキング対象リソースを目標にする要求が行われる。

ステップ３において、サービス層は目標にされたインターワーキング対象リソースの目標変更インジケータを評価し、かつ、データモデルマッピングドキュメントを使用するIPEに当該要求を目標変更するか否か決定する。１回目標変更属性の検索要求の場合、SLは、ステップ９において、先行する目標変更された要求に起因して属性が存在する場合にキャッシュされている当該属性の値を返す。キャッシュ値が見出されない場合、目標変更された要求は、インターワーキング対象デバイスから値をフェッチさせられる。すべてのその他の要求の場合、サービス層は要求を目標変更し、かつ、IPEに送る通知メッセージを作成する。

ステップ４において、要求されたリソースに関する通知がIPEに送られる。

ステップ５において、IPEは、目標にされたリソースを通知メッセージから抽出し、かつ、データモデルマッピングドキュメントを使用してサービス層リソースをインターワーキング対象リソースに変換する。さらに、IPEは、プロコトル変換を行ってデータモデルマッピングドキュメントから得たインターワーキング対象リソースURIを目標にする新しい要求メッセージを作成する。

ステップ６において、IPEがデバイスの技術（たとえば、LWM2M、OIC等）に準拠するフォーマットのメッセージをインターワーキング対象デバイスに送ると、デバイスは適切な応答をIPEに返す。このステップは、IPEが当該デバイスを管理する第三者サーバに統合されていない場合、マルチステッププロセスとなり得る。IPEと第三者サーバ間および第三者サーバと当該デバイス間においてメッセージ交換が行われる。IPEが応答を受け取った後、IPEは逆方向のプロコトル変換およびデータモデルマッピングを行ってサービス層への新しい応答メッセージを作成する。

ステップ７において、IPEは適切な応答をサービス層に送る。

ステップ８において、サービス層は、目標変更インジケータに基づいてインターワーキング対象リソース属性について対応値をキャッシュするか否か決定を下す。当該インジケータが１回目標変更として設定されている場合、サービス層は応答中のその情報を将来使用するために保存する。その後に別のアプリケーションまたは同一アプリケーションがサービス層内に保存された情報の検索を行ったとき、当該情報はすでにフェッチされているので目標変更は不要であり、サービス層は保存されている情報を返すことができる。

ステップ９において、適切な応答が要求したアプリケーションに返される。

（例示oneM2M実施形態）
図１５は、新しいoneM2M CSFが作成され、かつ、既存CSFが更新される例示実施形態を示す。新しいResource Management CSFはリソース定義登録とリソースマッピング登録の両方を処理することができ、また、新しいInterworking CSFを使用してインターワーキング対象リソースの目標変更基準を評価することができる。別の方法として、Resource Management CSFの代わりにData Management and Repositoryを更新して新しいリソースタイプの作成を可能にすることもできる。

CSF変更のほかに、新しいoneM2Mのリソースやリソース属性をサービス層に追加することができる。表４は、サービス層に追加できる典型的な新しい「リソース」を示す。

（例示oneM2Mリソース定義ドキュメント）
oneM2M内で使用できるリソース定義ドキュメントの例を図１６に示す。このドキュメントは、リソース定義ドキュメントの５つの主要な節を示している。すなわち、リソース定義情報、サービス層リソース属性、リソース固有属性、インターワーキング対象リソースの子リソース、および起動基準。ここで注意すべきは、リソース固有属性内において、ドキュメント全体を図中に収めるためにdmServerInfoAnnc要素タグが単一行に簡略化されていることである。

特に、図１６に示したドキュメントは、LWM2M Server Infoオブジェクトのリソース定義の例を描いている。最上部に記載した種々のリソース情報は、リソースを名称およびタイプにより識別し、かつ、バージョン番号、ショートネーム、リソースラベル、当該リソースが存在し得るリソースツリー中の場所などリソースに関するメタデータを示す。Resource Attributes、Resource Specific Attributes、およびChild Resourcesの節は、oneM2M XSDファイルについて詳述するコンテンツを含んでいる。最後に、Activation Criteriaの節は、リソースの使用を可能にするために定義ドキュメントを起動する方法に関する指示をサービス層に与える。

リソース定義ドキュメントはインターワーキングサポートの一環として使用されるが、それは通常のサービス層動作において新しいリソースタイプまたは既存タイプに基づくリソースを登録するためにも使用できる。たとえば、一定のリソースタイプバージョン１．０により展開されたサービス層は、将来において上述の着想を使用して同じリソースのバージョン１．１をサポートするようにアップグレードされ得る。このリソースは、データモデルマッピングドキュメントを必要としないサービス層のみのリソースとすることもできる。これが、リソース定義ドキュメントおよびデータモデルマッピングドキュメントが別々に登録され、かつ、リソース定義のみ起動される必要がある理由である。同一リソースの種々のバージョンをサポートするほかに、サービス層は、ホームオートメーションにおけるローカライズされたサービス層展開の場合のようにサービス層所有者により作成されたカスタムリソースもサポートすることができる。

（oneM2Mデータモデルマッピングドキュメントの例）
データモデルマッピングドキュメントは、リソース定義ドキュメントのResource Specific Attributes節中の情報を抽出し、名称パラメータを保持し、かつ、各リソース固有属性のtargetURIパラメータおよびretargetLevelパラメータを追加することにより生成される。図１７は、XMLフォーマットのLWM2M Server Informationオブジェクトのデータモデルマッピングドキュメントの例を示す。プレーンテキスト、JSON、CoRE Linkフォーマット等のような他のフォーマットも使用できる。注意すべきことに、図１６のリソース定義ドキュメントのResource Specific Attributes節と図１７のデータモデルマッピングドキュメントは同様である（たとえば、これらは両方とも同一のリソース固有属性を含んでいる）。

図１７に示した例示データモデルマッピングドキュメントは、プロコトル変換中にIPEにより使用される。このドキュメントは、表３により指定された目標変更インジケータをすべて使用する。前述したように、サービス層に登録されるデータモデルマッピングドキュメントは、２つのインジケータのみ含む。すなわち、１回目標変更および常時目標変更。その結果、IPEは、サービス層への登録において使用される新しいデータモデルマッピングドキュメントを生成する。この新しいドキュメントは、目標変更インジケータ２および３をIPEの性能に基づいて０または１に変更する。この場合の例は別々のエンティティとしてIPEおよび第三者サーバを含んでおり、IPEは周期的目標変更のみサポートする。

図１８は、IPEがサービス層に登録する例示データモデルマッピングドキュメントを示す。このIPEは周期目標変更をサポートするので、存続期間属性の目標変更レベルは０（１回目標変更）に設定される。このIPEはこの性能をサポートし、かつ、このリソース属性を動的に更新してこのサービス層が常に最新の値を持つようにする。図１７に示されている２（変更時に目標変更）の目標変更インジケータを持つ他の属性の場合、このIPEはこの機能をサポートしない。したがって、これらの値は１（常時目標変更）に設定される。

（処理要求および応答の流れの例）
上述したように、種々のシステムおよび種々の垂直市場または同一の垂直市場の販売会社から提供されるインターワーキング対象リソースの動的なリソース管理をサポートする柔軟性を与えることにより莫大な価値がサービス層展開に付加され得る。さらに、既存サービス層リソース（たとえば、<mgmtObj>および<flexContainer>）は、サービス層サービスの供給会社または所有者のためにカスタマイズされ得る。これら多数の利点は、以下において説明するoneM2M<mgmtObj>および<flexContainer>インターワーキングの諸例、多数の販売会社インターワーキング例およびLWM2Mインターワーキング例において証明される。

（oneM2M<mgmtObj>XSD起動例）
oneM2Mの<mgmtObj>リソースは、objectAttribute属性によるデバイス管理（たとえば、LWM2M）において使用される特殊化リソースを作成する機能を提供する。これは、基盤デバイス管理技術のデータモデルリソースに直接マッピングするために使用できるカスタマイズ可能な属性である。mgmtDefinition属性およびobjectIDs属性は、どのようなタイプの特殊化オブジェクトのために<mgmtObj>リソースがカスタマイズ化されるか定義する。現在、これらの属性は標準化プロセス内で定義され、したがって新しい特殊化を動的に定義する柔軟性は提供しない。

上述した着想を使用して、現在のoneM2M<mgmtObj>リソースを更新して新しい特殊化リソースを動的にサポートすることができる。表５は、<mgmtObj>リソースのリソース固有属性ならびに新しい特殊化リソースの動的定義をサポートするためにobjectIDｓ属性に対して提案された変更を示す。この変更は、<mgmtObj>リソースの定義に及んでobjectIDs属性を変更し、LWM2M Object定義に対応する特殊化<mgmtObj>リソースのXSDに関するURNまたはURIを与える。objectIDsは、特殊化<mgmtObj>リソースの作成中に指定することができる。objectIDs属性においてURIを指定するオプションは、CSEがCSEの最初の展開時点においては利用可能でなかった新しいLWM2Mオブジェクトをサポートすることを可能にする。これは、販売会社固有のLWM2Mオブジェクトの場合に特に当てはまる。このURIは、CSEにより使用されるために新しい特殊化<mgmtObj>リソースのXSDが見出され、かつ、読み出され得るロケーションをポイントする。

図１９は、objectIDs属性を使用する新しい特殊化<mgmtObj>リソースを作成するためにoneM2M Hosting CSEが実行する更新手順を示す。

ステップ００１において、Originatorは、特殊化<mgmtObj>リソースのCREATE動作のためのRequestメッセージにおける必須パラメータおよびオプションのパラメータを送る。特殊化<mgmtObj>リソースは、基盤LWM2M Objectの完全マッピングを含み、かつ、objectIDs属性中の新しい特殊化リソースのXSDのURIを包含している。

ステップ００２において、Receiverは以下の動作を行う。

Originatorが当該要求を行う適切な特権を持っているか否かチェックし、かつ、

コンテンツパラメータ中のresourceName属性により示された作成リソースの名称が目標リソースの子リソース内にすでに存在しないか検証する。

ステップ００３において、Receiverは、特殊化された<mgmtObj>リソースがCSEBaseのsupportedResourceType属性中に見出されるか否かチェックする。特殊化された<mgmtObj>リソースがsupportedResourceType属性中で見出された場合、ステップ８に進み、そうでない場合はステップ４に進む。

ステップ００４において、Receiverは、objectIDs属性のコンテンツを抽出し、かつ、XSD RepositoryからXSDを取り出す。

ステップ００５において、XSD Repositoryは、特殊化<mgmtObj>リソースのXSDを返す。

ステップ００６において、Receiverは、受信したXSDが適切に作成されているかチェックし、適切である場合、XSDをレシーバのローカルXSDリポジトリに保存する。

ステップ００７において、Receiverは、特殊化<mgmtObj>の名称によりsupportedResourceType属性を更新する。

ステップ００８において、ReceiverはCREATE要求の処理を完了する。これは以下を含む。

作成されるリソースにResource-IDを割り当てること。

当該リソースの必須読み出し専用（Read only:RO）モード属性の値を割り当てること、およびリソースタイプ定義により許容され、かつ、Originator自身により与えられていない場合に他の必須属性のために与えられた値をオーバーライドすること。

Receiverは以下の共通属性に値を割り当てる。

parentID；

creationTime;

expirationTime。Originatorにより与えられない場合、Receiverは、可能な最大値（Receiverの方針の制限範囲内）を割り当てる。方針またはサブスクリプション制約のためにOriginatorにより与えられた値がサポートされない場合、Receiverは、新しい値を割り当てる。

lastModifiedTime。これはcreationTimeに等しい。かつ

Receiver方針の制約の範囲内のその他のＲＯ属性。

Receiverは、クリエータ属性が要求のContentパラメータに含まれているか否かチェックする。含まれている場合、クリエータ属性は要求のContentパラメータ中の値を持ち得ない。他方、クリエータ属性が要求のContentパラメータに含まれていない場合、Receiverは作成されるリソース中にクリエータ属性を含めることができない。

Create Requestの正常検証後、Receiverは要求されたリソースを作成する。また、

Receiverは、作成された子リソースがその親リソースの属性の変更をもたらすか否かチェックし、もたらす場合、親リソースの属性が更新される。

ステップ００９において、Receiverは必須パラメータで応答し、かつ、CREATE動作のResponseメッセージ中でオプションのパラメータを送る。

一般的例外を以下に示す。

Originatorは、Receiver上にリソースを作成する特権を持ち得ない。このような場合、Receiverは、エラーで応答する。

指定された名称（与えられた場合）を持つリソースがすでにReceiverに存在する。このような場合、Receiverはエラーで応答する。

Content中に与えられた情報がReceiverにより受け入れられない（たとえば、必須パラメータが見当たらない）。このような場合、Receiverはエラーで応答する。

（oneM2M LWM2Mインターワーキング例）
図２０は、図１４で指定した典型的汎用インターワーキング手順をLWM2M Server InfoオブジェクトリソースのdefMinPeriod属性の検索に適用する状況を示す。図１６は、CSEがLWM2M Server Infoリソースを認識し、かつ、それが作成されてアクセスされることを可能にするためのリソース定義を示す。他方、図１８は、LWM2M Server Infoリソースの属性の目標変更インジケータおよびプロコトル変換のために使用されるデータモデルマッピング情報を示す。ここで注意すべきは、図１４のデータモデルマッピングおよびプロコトル変換の特徴を強調するために説明対象の情報のみ処理要求および応答の流れに含まれていることである。

ステップ０において、インターワーキングシステムが設定されて動作可能となる。これは、LWM2M Server Infoオブジェクトのためのリソース定義およびデータモデルマッピングの登録、LWM2M DeviceのLWM2M Server／IPEへの登録、IPEによるLWM2M DeviceのCSEへの登録およびLWM2M Server Infoリソース（lwm2m1）および関連サブスクリプションの作成、および種々の関係作用子間の通信を可能にするために必要なすべてのその他の設定を含む。

ステップ１において、AEは、LWM2M Server Infoリソースlwm2m1のdefMinPeriod属性の検索を行う。

ステップ２において、CSEは、図１８に示したように、defMinPeriod属性のために与えられた目標変更インジケータをチェックする。目標変更インジケータは１（常時目標変更）に設定されているので、CSEは要求を目標変更する決定を行う。

ステップ３において、CSEは、作成されたサブスクリプションに基づいてメッセージをＩＰＥに送る。別案として、CSEは、LWM2M Deviceに関係するAEリソースのpointOfAccess属性を使用して当該メッセージを目標変更するかまたはCSEがIPEに目標変更要求を通知する別の仕組みを使用することもできる。

ステップ４においてメッセージを受け取った後、IPEは、oneM2MプロコトルからLWM2Mプロコトルへの要求のプロコトル変換を行う。プロコトル変換の一環として、新しいLWM2Mメッセージが作成され、その過程においてデータモデルマッピングが利用される。図１８に示したマッピングに基づいてdefMinPeriod属性がLWM2M URI “／１／０／２”に変換される。この場合、“０”は、lwm2m1リソースに関係するインスタンス番号である。この番号は、lwm2m1リソースが作成されたときにIPEにより与えられた。

ステップ５において、IPE／LWM2M Serverは、新しく作成したメッセージをLWM2M Deviceに送る。メッセージ“Get/1/0/2”は、defMinPeriodの値を検索するLWM2M要求である。

ステップ６において、LWM2M Deviceは、適切な値８６４００を持つ“2.05 Content”応答コードを返す。

ステップ７において、IPEは、LWM2M応答をoneM2M応答フォーマットに変換した後に、同じ値をCSEに返す。

ステップ８において、CSEは、defMinPeriodの目標変更インジケータを使用して値を将来使用するためにキャッシュするべきか否か決定する。この場合には、インジケータが常時目標変更に設定されているので、キャッシングは不要である。

ステップ９において、CSEは、適切な応答を値８６４００とともにAEに返す。

（oneM2M<flexContainer>XSD起動例）
oneM2M<flexContainer>リソースは、containerDefinition属性経由で基礎<flexContainer>リソースから導かれる新しいリソースのコンテンツを記述するXSDファイルのロケーションを指定する機能を与える。oneM2M仕様TS-0001は、CSEがかかる要求を処理する方法を指定していないが、しかし<flexContainer>リソースを使用する特殊化のリストを明示している。図２１は、<flexContainer>リソースに基づいて新しいリソース定義を登録し、かつ、起動する機能を与えるために<flexContainer>リソースの作成を組み込む方法の例を示す。これらの新しいリソースは、やはり<flexContainer>タイプとして分類される。したがって、リソース定義は不要である。

ステップ１において、AEは<flexContainer>リソースを作成し、かつ、XSDファイルのロケーションのURIを持つcontainerDefinition属性を指定する。

ステップ２において、CSEは、アクセスコントロール方針（Access Control Policy:ACP）チェックを実行してAEが<flexContainer>リソースを作成できることを確認する。さらに、CSEは、XSDファイルがCSEのローカルリポジトリ中に存在しない場合に、権限チェックを行ってAEがXSDファイルを登録し、かつ、起動できることも確認できる。

ステップ３において、ACPチェックが正常であった場合、CSEは、すべての必要な情報が要求中に存在することを確認するために要求を検証する。この検証の一環として、CSEは、containerDefinition属性が存在することを確認する。

ステップ４において、ステップ３の検証要求およびステップ２の権限チェックが正常である場合、CSEは、XSDファイルが当該要求のペイロード中で与えられた<flexContainer>リソースに一致するそのローカルリポジトリに存在するか否かチェックする。

ステップ５において、ステップ４で一致が見出されなかった場合に、CSEは、containerDefinition属性からURIを抽出し、かつ、XSDリポジトリからXSDファイルをフェッチする。

ステップ６において、CSEはXSDファイルを受け取る。

ステップ７において、起動手順の一環として、CSEは、XSDファイルが適切に作成されていることを確認する。

ステップ８において、XSDファイルが適切に作成されている場合にCSEは、将来の使用のためにXSDファイルをそのローカルリポジトリに保存する。

ステップ９において、CSEは、CSE基礎リソースのsupportedResourceType属性の更新も行う。

ステップ１０において、CSEは、要求されたリソースをXSD対比で検証する。

ステップ１１において、これまでのすべてのチェックが正常であった場合、CSEは<flexContainer>リソースを作成する。

ステップ１２において、CSEは、この手順におけるチェックの状態に応じて適切な応答を送る。

（多数販売会社インターワーキング例）
図２２は、以下において説明するようにそれぞれのデバイスをCSEとインターワーキングさせている２社の販売会社の例を示す。この実行に際し、各販売会社は、それぞれのサービスを共通サービス層プラットフォームに提供し、かつ、それぞれの製品提供物の差別化を図ることができる。AEは、各販売会社のデータモデルを理解する必要なしに、これらのリソースを発見し、それにアクセスして各販売会社からサービスを入手することができる。

ステップ０において、インターワーキングシステムが設定されて動作可能となり、すべてのCSE登録（IPEおよびAE）が正常に完了している。販売業者ＡおよびＢは、それぞれのリソースをリソース定義手順およびデータモデルマッピング登録手順を使用するCSEにインターワーキングさせている。AEは、両販売会社のリソースをすでに発見しており、それに対するアクセスを希望している。

ステップ１において、AEは、Vendor Ａリソースに関する要求を行う。

ステップ２において、CSEは目標変更インジケータをチェックし、かつ、要求をVendor A／IPEに目標変更する決定を下す。

ステップ３において、CSEはVendor A／IPEに目標変更された要求を送り、そして応答を受け取る。

ステップ４において、CSEは、応答をVendor AのリソースのデータとともにAEに返す。

ステップ５〜８において、Vendor Bのリソースについてステップ１〜４を繰り返す。

図２２に示した例は、図６において提示した例と非常によく類似しており、主な差異は後者が異なるシステム間のインターワーキングを含んでいることに対し、前者が異なる分野の販売会社または同じ分野の販売会社さえ含み得ることである。それぞれの場合において、アプリケーションは、ネイティブサービス層手順を使用するこれらの種々のリソースにシームレスにアクセスすることができる。

（インテリジェントな目標変更インターワーキングの例）
別の例では、LWM2Mアーキテクチャにより、多数のLWM2Mサーバが同一のLWM2Mクライアントまたはデバイスを管理することを可能にする。あるインターワーキングシナリオでは、同一デバイスを管理する２つのLWM2Mサーバ、一方は在来のLWM2Mサーバおよび他方はIPEに統合されたLWM2Mサーバが存在し得る。図２３は、これから説明する在来のサーバであるLWM2M Server1およびインターワーキング対象サーバであるLWM2M Server2によるかかる例示シナリオを示す。この例では、両方のLWM2Mサーバが能動的にLWM2M Deviceを管理する。LWM2M Server2／IPEは、Firmware Updateオブジェクトのファームウェアバージョンリソースの“Change on update”の目標変更インジケータをすでに設定している。その結果、LWM2M Server2は、ＦＷ更新の通知を入手するために観察要求をすでに行っている。

ステップ０において、インターワーキングシステムが設定されて動作可能となり、すべてのＣＳＥ登録が正常に完了している。LWM2M Deviceは在来のLWM2M Server1およびインターワーキング対象LWM2M Server2により管理されている。IPEに統合されているLWM2M Server2は、LWM2M Deviceのファームウェアバージョンリソースの状況を観察しており、かつ、ファームウェア更新が正常に行われる時点を知る。その結果、IPEは、CSE上でファームウェアバージョン属性が更新され続けることをサポートし、かつ、関連データモデルマッピングを１回目標変更に設定する。

ステップ１において、LWM2M Server1は、LWM2M Deviceについてファームウェア更新を行い、かつ、正常応答を受け取る。

ステップ２において、LWM2M Deviceは、新しいファームウェアバージョンでLWM2M Server2に通知を送る。

ステップ３において、IPEは、目標変更インジケータに基づいてCSE上のファームウェアバージョンを更新する決定を下す。

ステップ４において、IPEは、CSE上のファームウェアバージョン属性を新しいバージョン番号により更新する。

（ユーザインターフェース）
図２４は、サービス層がサーバ内に登録されているリソース定義を表示する例示ユーザインターフェースを示す。別案として、これは、SLアプリケーションにより、このリソース定義を発見し、かつ、LWM2M:1定義ドキュメントを読み出した後に表示され得る。このユーザインターフェースは、ウィンドウの左ペインに定義名称およびバージョン番号のほかインターワーキング対象標準のロゴを含むリソース定義のリストを示している。図２４は、強調表示されているLWM2M:1リソース定義をユーザが選択したことを示している。ウィンドウの右ペインには、LWM2M:1のリソース定義のコンテンツが示されている。同様な表示を使用してデータモデルマッピングドキュメントを示すことができる。

（例示環境）
当然のことながら図９〜１４および１９〜２３のステップは、これらの図において描かれているそれぞれのエンティティにより実行可能である。これらは、通信ネットワークにおける論理的エンティティを表し、かつ、かかるネットワークの装置のメモリに格納され、そのプロセッサ上に実行されるソフトウェア（すなわち、コンピュータ実行可能命令）の形態により実現され得る。かかるネットワーク装置は、図２５Ｃまたは２５Ｄに示し、これからより詳しく説明する一般的アーキテクチャの１つを含み得る。すなわち、図９〜１４および１９〜２３に示した動作は、ネットワーク装置のメモリに格納されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実現され得る。かかる装置は、たとえば、図２５Ｃまたは２５Ｄに示されているアーキテクチャの１つを有し、そのコンピュータ実行可能な命令は、この装置のプロセッサにより実行されたときに図に示されているステップを実行する。さらに当然のことながら図９〜１４および１９〜２３に示されているステップの送信および受信は、この装置のプロセッサおよびそれが実行するコンピュータ実行可能命令（たとえば、ソフトウェア）の制御の下でこの装置の通信回路（たとえば、それぞれ図２５Ｃおよび２５Ｄの回路３４または９７）により行われ得る。

図２５Ａは、１つまたは複数の開示される実施形態を実現し得る例示M2M、IoT、またはWoT通信システム１０の略図である。一般的にM2M技術はIoT／WoTの構成要素を与えるものであり、また、M2Mデバイス、M2Mゲートウェイ、M2Mサーバ、またはM2Mサービスプラットフォームは、IoT／WoTおよびIoT／WoT Service Layer等の構成要素または装置となり得る。図１、４〜１５、および１９〜２３に示したエンティティのいずれも図２５Ａ〜２５Ｄに示した通信システムのネットワーク装置を含み得る。

サービス層は、ネットワークサービスアーキテクチャ内の機能層とすることができる。
サービス層は、一般的にHTTP、CoAPまたはMQTTなどのアプリケーションプロコトル層の上に位置し、かつ、付加価値サービスをクライアントアプリケーションに提供する。サービス層は、たとえば、制御層およびトランスポート／アクセス層などの下のリソース層においてコアネットワークへのインターフェースも与える。サービス層は、サービス定義、サービス実行時イネーブルメント、方針管理、アクセス制御、およびサービスクラスタリングを含む多数のカテゴリの（サービス）性能または機能性をサポートする。最近、いくつかの業界標準団体、たとえば、oneM2Mにより、インターネット／ウェブ、セルラーネットワーク、企業ネットワーク、およびホームネットワークなどの展開へのM2M型のデバイスおよびアプリケーションの統合に関する問題に対処するM2Mサービス層が開発されてきた。M2Mサービス層は、CSEまたはSCLと呼ばれるサービス層によりサポートされる一連のまたは一組の上述の性能または機能性へのアクセスをアプリケーションや種々のデバイスに与え得る。いくつかの例は、種々のアプリケーションにより一般的に使用され得るセキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニング、および接続性管理を含むがこれらのみには限られない。これらの性能または機能性は、M2Mサービス層により定義されるメッセージフォーマット、リソース構造、およびリソース表現を使用するAPI経由でこうした多様なアプリケーションにとって利用可能にされる。CSEまたはSCLは、ハードウェアやソフトウェアにより実現され得る機能的エンティティである。このエンティティは、種々のアプリケーションやデバイスに顕示される（サービス）性能または機能性（すなわち、かかる機能的エンティティ間の機能的インターフェース）を提供して、上述のアプリケーションやデバイスにかかる性能または機能性を使用させる。

図２５Ａに示したように、M2M／IoT／WoT通信システム１０は、通信ネットワーク１２を含んでいる。通信ネットワーク１２は、固定ネットワーク（たとえば、イーサネット（登録商標）、ファイバー、ISDN、PLC等）または無線ネットワーク（たとえば、WLAN、セルラー等）または異種ネットワークのネットワークであり得る。たとえば、通信ネットワーク１２は、ボイス、データ、ビデオ、メッセージング、放送等のようなコンテンツを多数のユーザに提供する多数のアクセスネットワークから構成され得る。たとえば、通信ネットワーク１２は、符号分割多重アクセス方式（Code Division Multiple Access:CDMA）、時分割方式（Time Division Multiple Access:TDMA）、周波数分割多重アクセス方式（Frequency Division Multiple Access:FDMA）、直交ＦＤＭＡ（Orthogonal FDMA:OFDMA）、シングルキャリアFDMA（Single-Carrier FDMA:（SC−FDMA））等のような１つまたは複数のチャネルアクセス方法を使用し得る。さらに、通信ネットワーク１２は、たとえば、コアネットワーク、インターネット、センサネットワーク、産業制御ネットワーク、パーソナルエリアネットワーク、融合パーソナルネットワーク、サテライトネットワーク、ホームネットワーク、または企業ネットワークなどの他のネットワークを含み得る。

図２５Ａに示すように、M2M／IoT／WoT通信ネットワーク１０は、Infrastructure DomainおよびField Domainを含み得る。Infrastructure DomainはエンドツーエンドM2M展開のネットワーク側を指し、また、Field Domainは、通常M2Mゲートウェイの背後にあるエリアネットワークを指す。Field DomainおよびInfrastructure Domainは、両方ともネットワークの多種多様なネットワーク装置（たとえば、サーバ、ゲートウェイ、装置等）を含み得る。たとえば、Field Domainは、M2Mゲートウェイ１４およびデバイス１８を含み得る。当然のことながらM2M／IoT／WoT通信システム１０は、必要に応じて任意の個数のM2Mゲートウェイ装置１４およびM2Mデバイス１８を含み得る。M2Mゲートウェアデバイス１４およびM2M装置１８のそれぞれは、通信回路を使用して通信ネットワーク１２または直接無線リンクを経由して信号を送受するように設定される。

M2Mゲートウェイ１４は、無線M2Mデバイス（たとえば、セルラーおよび非セルラー）および固定ネットワークM2Mデバイス（たとえば、PLC）が通信ネットワーク１２などの事業者ネットワークまたは直接無線リンク経由で通信することを可能にする。たとえば、M2Mデバイス１８は、データを収集し、通信ネットワーク１２または直接無線リンクを経由してM2Mアプリケーション２０またはその他のM2Mデバイス１８にそのデータを送ることができる。M2Mデバイス１８は、M2Mアプリケーション２０またはM2Mデバイス１８からデータを受け取ることもできる。さらに、以下で説明するように、データおよび信号は、M2Mアプリケーション２０との間でM2M Service Layer２２経由で送受され得る。M2Mデバイス１８およびゲートウェア１４は、たとえば、セルラー、WLAN、WPAN（たとえば、Zigbee、6LoWPAN、Bluetooth（登録商標））、直接無線リンク、および有線を含む種々のネットワーク経由で通信することができる。典型的M2Mデバイスは、タブレット、スマートフォン、医療デバイス、温度および気象の監視装置、コネクテッドカー、スマートメーター、ゲーム機器、個人用デジタル補助装置、健康フィットネスモニタ、照明、サーモスタット、電気製品、ガレージドアおよびその他のアクチュエータ応用デバイス、セキュリティデバイス、スマートアウトレットを含むがこれらのみには限られない。

図２５Ｂを参照する。フィールドドメインに示されているM2M Service Layer２２は、M2Mアプリケーション２０、M2Mゲートウェイ１４、およびM2Mデバイス１８ならびに通信ネットワーク１２にサービスを提供する。当然のことながら、M2M Service Layer２２は、必要に応じて任意の個数のM2Mアプリケーション、M2Mゲートウェイ１４、M2Mデバイス１８、および通信ネットワーク１２と通信し得る。M2M Service Layer２２は、サーバ、コンピュータ、装置等を含み得るネットワークの１つまたは複数のネットワーク装置により実現され得る。M2M Service Layer２２は、M2Mデバイス１８、M2Mゲートウェイ１４、およびM2Mアプリケーション２０に当てはまるサービス性能を提供する。M2M Service Layer２２の機能は、セルラーコアネットワークにおいて、クラウド等において、種々の方法、たとえば、ウェブサーバとして実現され得る。

図示されているM2M Service Layer２２と同様に、Infrastructure DomainにM2M Service Layer２２’が存在する。M2M Service Layer２２’は、インフラストラクチャドメインのM2Mアプリケーション２０’および基盤通信ネットワーク１２にサービスを提供する。M2M Service Layer２２’は、フィールドドメインのM2Mゲートウェイ１４およびM2Mデバイス１８にもサービスを提供する。当然のことながら、M2M Service Layer２２’は、任意の個数のM2Mアプリケーション、M2MゲートウェイおよびM2Mデバイスと通信し得る。M2M Service Layer２２’は、別のサービス提供会社によるService Layerと相互動作することができる。M2M Service Layer２２’は、当該ネットワークの１つまたは複数のネットワーク装置により実現され得る。このネットワーク装置は、サーバ、コンピュータ、デバイス、仮想マシン（たとえば、クラウドコンピューティング／記憶ファーム等）などを含み得る。

やはり図２５Ｂを参照する。M2M Service Layer２２および２２’は、種々のアプリケーションおよび垂直アプリケーションが活用し得る一連のコアとなるサービス提供性能を提供する。これらのサービス性能は、M2Mアプリケーション２０および２０’がデバイスと相互作用し、かつ、データ収集、データ分析、デバイス管理、セキュリティ、課金、サービス／デバイス発見等などの機能を果たすことを可能にする。基本的に、これらのサービス性能は、アプリケーションをこれらの機能性を実現する仕事から解放し、それによりアプリケーション開発を単純化するとともにコストおよび商品化に要する時間を低減する。Service Layer２２および２２’は、M2Mアプリケーション２０および２０’がネットワーク１２などの種々のネットワーク経由でService Layer２２および２２’が提供するサービスに関連して通信することも可能にする。

M2Mアプリケーション２０および２０’は、輸送、保健福祉、コネクテッドホーム、エネルギー管理、資産管理、およびセキュリティと監視を含むがこれらのみには限られない種々の産業におけるアプリケーションを含み得る。上述したように、システムのデバイス、ゲートウェイ、サーバ、およびその他のネットワーク装置に関わって動作するM2M Service Layerは、たとえば、データ収集、デバイス管理、セキュリティ、課金、位置追尾／ジオフェンシング、デバイス／サービス発見、およびレガシーシステム統合なとの機能をサポートし、かつ、これらの機能をサービスとしてM2Mアプリケーション２０および２０’に提供する。

一般的に、図２５Ｂに示されているService Layer２２およびService Layer２２’などのService Layerは、一連のAPIおよび基盤ネットワークインターフェース経由で付加価値サービス性能をサポートするソフトウェアミドルウェア層を定義する。ETSI M2MとoneM2Mアーキテクチャの両方ともService Layerを定義する。ETSI M2MのService Layerは、サービス性能層（Service Capability Layer:SCL）と呼ばれる。SCLは、ETSI M2Mアーキテクチャの種々様々なノードにおいて実現され得る。たとえば、Service Layerのインスタンスは、M2Mデバイス（そこでは、それはデバイスSCL（device SCL:DSCL）と呼ばれる）、ゲートウェイ（そこでは、それはゲートウェイSCL（gateway SCL:GSCL）と呼ばれる）やネットワークノード（そこでは、それはネットワークSCL（network SCL:NSCL）と呼ばれる）内において実現することができる。oneM2M Service Layerは、一連のCSF（すなわち、サービス性能）をサポートする。一組の１つまたは複数の特定のタイプのCSFのインスタンス化はCSEと呼ばれ、種々のタイプのネットワークノード（たとえば、インフラストラクチャノード、ミドルノード、アプリケーション固有ノード）上でホストされ得る。第三世代パートナーシッププロジェクト（Third Generation Partnership Project:3GPP）は、マシンタイプ通信（Machine-Type Communications:MTC）のアーキテクチャも定義している。そのアーキテクチャでは、Service Layerおよびそれが与えるサービス性能は、サービス性能サーバ（Service Capability Server:SCS）の一環として実現される。ETSI M2MアーキテクチャのDSCL、GSCL、またはNSCLにおいて、3GPPアーキテクチャのMTCのSCSにおいて、oneM2MのアーキテクチャのCSFまたはCSEにおいて、またはネットワークの他のノードにおいてのうち、いずれにおいて実現されるにせよ、Service Layerのインスタンスは、ネットワーク中の１つまたは複数の独立型ノード（サーバ、コンピュータ、およびその他のコンピュータデバイスまたはノードを含む）または１つまたは複数の既存ノードの一部の上で走行する論理的エンティティ（たとえば、ソフトウェア、コンピュータ実行可能命令等）として実現され得る。一例として、Service Layerまたはその構成要素のインスタンスは、これから説明する図２５Ｃまたは図２５Ｄに示されている一般的アークテクチャを持つネットワーク装置（たとえば、サーバ、コンピュータ、ゲートウェイ、デバイス等）上で走行するソフトウェアの形態で実現され得る。

さらに、本願において記述する方法および機能性は、サービス指向アーキテクチャ（Service Oriented Architecture:SOA）やリソース指向アーキテクチャ（Resource-Oriented Architecture:ROA）を使用してサービスにアクセスするM2Mネットワークの一部として実現され得る。

図２５Ｃは、ネットワークの装置の例示ハードウェア／ソフトウェアのアーキテクチャのブロック図である。かかる装置は、図１、４〜１５、および１９〜２３において示したエンティティの一例であり、図２５Ａおよび２５Ｂにおいて示したM2Mネットワーク中のM2Mサーバ、ゲートウェイ、デバイス、またはその他のネットワーク装置として動作し得る。図２５Ｄに示されているように、ネットワーク装置３０は、プロセッサ３２、非着脱式メモリ４４、着脱式メモリ４６、スピーカ／マイクロフォン３８、キーパッド４０、ディスプレイ、タッチパッドやインジケータ４２、電源４８、全地球測位システム（Global Positioning System:GPS）チップセット５０、およびその他の周辺機器５２を含み得る。ネットワーク装置３０は、トランシーバ３４および送信／受信要素３６などの通信回路も含み得る。当然のことながら、ネットワーク装置３０は前記諸要素のサブコンビネーションを含みつつ、実施形態との一貫性を保ち得る。このネットワーク装置は、図９〜１４および１９〜２３に関連して図解し、説明した方法などの本願記載のメッセージテンプレート管理の性能および方法を実現する装置とすることができる。

プロセッサ３２は、汎用プロセッサ、専用プロセッサ、在来型プロセッサ、デジタルシグナルプロセッサ（Digital Signal Processor:DSP）、複数のマイクロプロセッサ、DSPコアと連携する１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（Application Specific Integrated Circuit:ASIC）、フィールドプログラマブルゲートアレイ（Field Programmable Gate Array:FPGA）回路、その他のタイプの集積回路（Integrated Circuit:IC）、状態機械等とすることができる。一般的に、プロセッサ３２は、ネットワーク装置の種々の必須機能を実行するためにネットワーク装置のメモリ（たとえば、メモリ４４やメモリ４６）に格納されているコンピュータ実行可能命令を実行することができる。たとえば、プロセッサ３２は、ネットワーク装置３０が無線または有線環境において動作できるようにする信号コード化、データ処理、電源制御、入出力処理やその他の機能性を行い得る。プロセッサ３２は、アプリケーション層プログラム（たとえば、ブラウザ）や無線アクセス層（Radio Access-Layer:RAN）プログラムやその他の通信プログラムを実行することができる。プロセッサ３２は、たとえばアクセス層やアプリケーション層における認証、セキュリティキー一致や暗号化動作などのセキュリティ動作も行い得る。

図２５Ｃに示すように、プロセッサ３２は、その通信回路（たとえば、トランシーバ３４および送信／受信要素３６）に結合される。プロセッサ３２は、コンピュータ実行可能な命令の実行により、通信回路を制御してネットワーク装置３０にそれが接続されているネットワーク経由で他のネットワーク装置と通信させることができる。特に、プロセッサ３２は、本明細書（たとえば、図９〜１４および２４〜２６）および本願請求項において記述される送信および受信ステップを実行するために通信回路を制御することができる。図２５Ｃはプロセッサ３２およびトランシーバ３４を別々の構成要素として描いているが、当然のことながらプロセッサ３２およびトランシーバ３４は、電子パッケージまたはチップ中に統合することができる。

送信／受信要素３６は、M2Mサーバ、ゲートウェイ、デバイス等を含む他のネットワーク装置との間で信号を送受するように構成され得る。たとえば、１つ実施形態では、送信／受信要素３６は、RF信号を送受するように構成されたアンテナとすることができる。送信／受信要素３６は、種々のネットワークおよびWLAN、WPAN、セルラー等の無線インターフェースをサポートし得る。ある実施形態では、送信／受信要素３６は、たとえば、IR、UV、または可視光線信号を送受するように構成されたエミッタ／ディテクタとすることができる。さらに別の実施形態では、送信／受信要素３６は、RFと光両方の信号を送受するように構成し得る。当然のことながら送信／受信要素３６は、無線または有線信号の組み合わせを送受するように構成することができる。

さらに、送信／受信要素３６は図２５Ｃでは単一の要素として描かれているが、ネットワーク装置３０は多数の送信／受信要素３６を含み得る。より具体的には、ネットワーク装置３０は、MIMO技術を使用することができる。したがって、ある実施形態ではネットワーク装置３０は、無線信号を送受するために２つ以上の送信／受信要素３６（たとえば、多数のアンテナ）を含み得る。

トランシーバ３４は、送信／受信要素３６により送信される信号を変調し、かつ、送信／受信要素３６により受信される信号を復調するように構成され得る。上述したように、ネットワーク装置３０は、多重モードの性能を持ち得る。したがって、トランシーバ３４は、ネットワーク装置３０がたとえば、UTRAおよびIEEE 802.11などの多数のＲＡＴ経由で通信することを可能にする多数のトランシーバを含むことができる。

プロセッサ３２は、非着脱式メモリ４４や着脱式メモリ４６など任意の種類の適切なメモリの情報にアクセスし、かつ、それにデータを格納することができる。たとえば、プロセッサ３２は、上述したように、そのメモリにセッションコンテキストを格納する。非着脱式メモリ４４は、ランダムアクセスメモリ（Random-Access Memory:RAM）、読み出し専用メモリ（Read-Only Memory:ROM）、ハードディスク、またはその他の種類のメモリ格納デバイスを含み得る。着脱式メモリ４６は、加入者識別モジュール（Subscriber Identity Module:SIM）カード、メモリスティック、セキュアデジタル（Secure Digital:SD）メモリカード等を含むことができる。別の実施形態では、プロセッサ３２は、サーバまたはホームコンピュータ上などネットワーク装置３０上に物理的に置かれていないメモリの情報にアクセスし、かつ、それにデータを格納することができる。プロセッサ３２は、ネットワーク装置と通信している装置、特に基盤ネットワーク、アプリケーション、またはその他のサービスの状況を反映するかまたはそれらを設定するためにディスプレイまたはインジケータ４２上の発光パターン、画像、またはカラーを制御するように構成され得る。１つの実施形態では、ディスプレイ／インジケータ４２は、図２４に示されており、これから説明するグラフィカルユーザインターフェースを提供し得る。

プロセッサ３２は電源４８から電力を受け取ることができ、かつ、電力をネットワーク装置３０中の他の構成要素への電力の分配や制御を行うように構成し得る。電源４８は、ネットワーク装置３０に電力を供給するための適切なデバイスとすることができる。たとえば、電源４８は、１つまたは複数の乾電池（たとえば、ニッケルカドミウム（Nickel-Cadmium:NiCd）、ニッケル亜鉛（Nickel-Zinc:NiZn）、ニッケル水素（Nickel Metal Hydride:NiMH）、リチウムイオン（Lithium-ion:Li−ion）等）、太陽電池、燃料電池等を含み得る。

プロセッサ３２は、ネットワーク装置３０の現在の位置に関する位置情報（たとえば、経度および緯度）を与えるように構成されたGPSチップセット５０にも結合され得る。当然のことながら、ネットワーク装置３０は位置情報を任意の適切な位置決定方法により位置情報を取得しつつ、実施形態との一貫性を維持することができる。

プロセッサ３２は、さらに他の周辺機器５２と結合され得る。それは、さらなる特徴、機能性や有線または無線接続性を与える１つまたは複数のソフトウェアやハードウェアのモジュールを含むことができる。たとえば、周辺機器５２は、加速度計、バイオメトリクス（たとえば、指紋）センサなどの種々のセンサ、電子コンパス、衛星トランシーバ、センサ、デジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（Universal Serial Bus:USB）ポートまたはその他の相互接続インターフェース、振動デバイス、テレビトランシーバ、ハンズフリーヘッドセット、Bluetooth（登録商標）モジュール、周波数変調（Frequency Modulated:FM）無線装置、デジタル音楽プレーヤ、メディアプレーヤ、ゲーム機モジュール、インターネットブラウザ等を含み得る。

ネットワーク装置３０は、センサ、家庭電気製品、スマートウォッチまたはスマートクロージングなどのウエアラブルデバイス、医療またはｅヘルスデバイス、ロボット、産業装置、ドローン、乗用車、トラック、列車、または航空機などの乗り物のような他の装置またはデバイスにおいて具現化し得る。ネットワーク装置３０は、周辺機器５２の１つを含み得る相互接続インターフェースなどの１つまたは複数の相互接続インターフェース経由で、かかる装置またはデバイスの他の構成要素、モジュール、またはシステムと接続することができる。

図２５Ｄは、本願の図１、４〜１５、および１９〜２３に示し、かつ、説明したエンティティなどのネットワークの１つまたは複数のネットワーク装置を実現するためにも使用できる典型的コンピュータシステム９０のブロック図である。これらの装置は、図２５Ａおよび２５Ｂに示したM2MネットワークにおけるM2Mサーバ、ゲートウェイ、デバイス、またはその他のネットワーク装置として動作することができる。

コンピュータシステム９０はコンピュータまたはサーバを含み、かつ、主としてコンピュータ読み取り可能命令により制御され得る。この命令はソフトウェアの形態とし、その格納箇所および格納方法およびアクセス方法などの手段は任意に決定できる。かかるコンピュータ読み取り命令は、コンピュータシステム９０に仕事をさせるために中央処理装置（Central Processing Unit:CPU）９１などのプロセッサ内で実行され得る。多数の既知ワークステーション、サーバ、およびパソコンにおいて、CPU９１は、マイクロプロセッサと呼ばれる単一チップCPUとして実現される。他のマシンでは、CPU９１は、多数のプロセッサを含み得る。コプロセッサ８１は主CPU９１とは異なる任意のプロセッサであり、追加機能を実行するかまたはCPU９１を補助する。ＣＰＵ９１やコプロセッサ８１は、E2E M2M Service Layerセッションのための開示対象のシステムおよび方法に関するデータの受信、生成、および処理（セッション認証情報の受信またはセッション認証情報に基づく認証など）を行い得る。

動作において、CPU９１は、命令のフェッチ、復号、および実行を行い、かつ、コンピュータの主たるデータ転送経路、システムバス８０を経由して他のリソースとの間で情報を送受する。かかるシステムバスは、コンピュータシステム９０中の構成要素を接続し、かつ、データ交換のための媒体を規定する。システムバス８０は、一般的にデータを送るデータライン、アドレスを送るアドレスライン、および割り込みを送り、かつ、システムバスを動作させる制御ラインを含む。かかるシステムバス８０の例は、ペリフェラルコンポーネントインターコネクト（Peripheral Component Interconnect:PCI）バスである。

システムバス８０に結合されるメモリは、RAM８２およびROM９３を含む。かかるメモリは、情報の格納および検索を可能にする回路を含む。ROM９３は、一般的に容易に変更され得ない格納データを含む。RAM８２に格納されているデータは、CPU９１またはその他のハードウェアデバイスによる読み取りまたは変更が可能である。RAM８２やROM９３へのアクセスは、メモリコントローラ９２により制御され得る。メモリコントローラ９２は、命令が実行されるときに仮想アドレスを物理的アドレスに変換するアドレス変換機能を与え得る。メモリコントローラ９２は、システム内のプロセス相互を分離し、かつ、システムプロセスをユーザプロセスから分離するメモリ保護機能も与えることもできる。したがって、第１モードで走行するプログラムは、それ自身のプロセス仮想アドレス空間によりマッピングされたメモリにのみアクセスできる。それは、プロセス間でメモリ共有が設定されていない限り別のプロセスの仮想アドレス空間内のメモリにはアクセスできない。

さらに、コンピュータシステム９０は、CPU９１からプリンタ９４、キーボード８４、マウス９５、およびディスクドライブ８５などの周辺機器への命令の伝達を受け持つ周辺機器コントローラ８３を含み得る。

ディスプレイコントローラ９６により制御されるディスプレイ８６は、コンピュータシステム９０により作成された視覚出力を表示するために使用される。かかる視覚出力は、テキスト、グラフィックス、動画グラフィックス、およびビデオを含み得る。ディスプレイ８６は、CRT応用ビデオディスプレイ、LCD応用フラットパネルディスプレイ、ガスプラズマ応用フラットパネルディスプレイ、またはタッチパネルにより実現され得る。ディスプレイコントローラ９６は、ディスプレイ８６に送られるビデオ信号を生成するために必要な電子構成部品を含む。ディスプレイ８６は、CPU９１により実行されるコンピュータ実行可能命令と共同して、図２５に示され、かつ、それに伴う記述により説明されているグラフィカルユーザインターフェースを生成し、かつ、運用することができる。

さらに、コンピュータシステム９０は、たとえば、ネットワークアダプタ９７などの通信回路を含み得る。この回路を使用して、コンピュータシステム９０を図２５Ａ〜２５Ｄのネットワーク１２などの外部通信ネットワークに接続し、コンピュータシステム９０をネットワークの他の装置と通信可能にすることができる。この通信回路は、本明細書（たとえば、図９〜１４および１９〜２３）およびその請求項において記述されている送信および受信ステップを実行するために、単独でまたはCPU９１とともに使用され得る。

当然のことながら、本願において記述されているシステム、方法およびプロセスのいずれもコンピュータ読み取り可能な格納媒体に格納されているコンピュータ実行可能な命令（すなわち、プログラムコード）の形態で具体化され得る。これらの命令は、M2Mネットワークの装置などのマシン（たとえば、M2Mのサーバ、ゲートウェイ、デバイス等を含む）により実行されたときに、本願において記述されているシステム、方法およびプロセスの実行や実現を行う。具体的には、上述のステップ、動作または機能のいずれも、かかるコンピュータ実行可能な命令の形態で実現され得る。コンピュータ読み取り可能な記憶媒体は、情報の記憶のための持続的な（すなわち有形または物理的な）方法または技術により実現される揮発性と非揮発性両方の着脱式および非着脱式の媒体を含むが、しかしかかるコンピュータ読み取り可能な記憶媒体は信号を含まない。コンピュータ読み取り可能記憶媒体は、RAM、ROM、EEPROM、フラッシュメモリまたはその他のメモリ技術、CD−ROM、デジタル多用途ディスク（Digital Versatile Disk:DVD）またはその他の光ディスク記憶、磁気カセット、磁気テープ、磁気ディスク記憶またはその他の磁気記憶デバイス、または所望の情報を格納するために使用され、かつ、コンピュータによりアクセスされ得るその他の有形または物理的媒体を含むがこれらのみには限られない。

この書面記述は、発明を開示し、かつ、当業者によるデバイスまたはシステムの製造または使用ならびに取り入れられている方法の実行を含む本発明の実施を可能にするためにベストモードを含む例を使用する。本発明の特許を受けることができる範囲は本願請求項により定義されるが、当業者の心に浮かぶその他の例も含み得る。かかる他の例は、それが本願請求項の文言と異ならない要素を含むか、またはそれが本願請求項の文言と実質的に異ならない等価要素を含む場合には、本願請求項の範囲内に含まれることを意図している。

Claims

プロセッサ、メモリ、および通信回路を含む装置であって、その通信回路経由でネットワークに接続される装置であり、そのメモリに格納されるコンピュータ実行可能命令であって、前記プロセッサにより実行されたときに前記装置に、
サービス層において新しいリソースまたはリソースタイプの少なくとも一方を定義する情報を登録する要求を受け取ることと、
前記情報を前記サービス層の動作に組み入れることと、
前記情報を前記ネットワーク上で通信する他のネットワーク装置による発見のために顕示することと、
を含む動作を行わせる命令をさらに含む装置。
前記情報は、リソース定義ドキュメントを含む、請求項１に記載の装置。
前記リソース定義ドキュメントは、前記リソース定義に関する情報、継承されるリソース属性、リソース固有属性、子リソース属性、または起動基準の少なくとも１つを含む、請求項２に記載の装置。
前記サービス層において前記情報を管理することをさらに含む、請求項１に記載の装置。
前記情報を管理することは、前記サービス層における前記情報の検索、更新、除去、起動、および停止の少なくとも１つを含む、請求項４に記載の装置。
前記情報を起動することは、要求元が前記情報の起動を要求することを許可されていることを確認する前記サービス層における認可チェックを引き起こす、請求項５に記載の装置。
前記サービス層において前記情報の評価に基づいて応答を作成することをさらに含む、請求項１に記載の装置。
前記サービス層において前記情報を受け取ることは、前記サービス層内の仮想または物理的リソースに前記情報を受け取ることを含む、請求項１に記載の装置。
前記サービス層において前記情報を受け取ることは、前記サービス層において第１のユニフォームリソースインジケータ（Uniform Resource Indicator:URI）を受け取ることを含む、請求項１に記載の装置。
前記サービス層において前記情報を前記第１のURI経由でダウンロードすることをさらに含む、請求項９に記載の装置。
前記サービス層において前記情報に基づいて対応するスキーマドキュメントを作成することをさらに含む、請求項１に記載の装置。
前記スキーマドキュメントは、前記サービス層およびサービス層アドミニストレータのみによりアクセスされ得るリポジトリに格納される、請求項１１に記載の装置。
第三者デバイスに関連するリソースであって、前記サービス層に関連するリソースを定義するプロコトルとは異なるプロコトルに従って定義されるリソースと、前記サービス層に関連する前記リソースまたはリソースタイプとの間の１対１マッピングを与えるデータを登録する要求を受け取ることと、
前記データを前記サービス層に登録することと、
をさらに含む、請求項１に記載の装置。
プロセッサ、メモリ、および通信回路を含む装置であって、その通信回路経由でネットワークに接続される装置であり、そのメモリに格納されるコンピュータ実行可能命令であって、前記プロセッサにより実行されたときに前記装置に、
前記ネットワークのサービス層において前記サービス層に関連するリソースを検索する要求を受け取ることと、
前記リソースにアクセスするためにインターワーキングが必要であると決定することと、
前記サービス層において、前記要求されたサービス層リソースから、第三者デバイスに関連するリソースであって、前記サービス層に関連するリソースを定義するプロコトルとは異なるプロコトルに従って定義されるリソースへのマッピングを行うデータにアクセスすることと、
を含む動作を行わせる命令をさらに含む装置。
前記要求されたサービス層リソースを第三者デバイスに関連する前記リソースにマッピングする前記データは、複数の種々のインジケータの１つを含む、請求項１４に記載の装置。
前記複数のインジケータのそれぞれにより、前記サービス層がリソースを検索する要求を目標変更し得る方法が指示される、請求項１５に記載の装置。
前記要求に応じてキャッシュされたデータが前記要求されたリソースにとって利用可能であるか否か評価することと、利用可能でない場合に前記受け取った要求を前記アクセスされたデータ中の前記インジケータに従って目標変更することと、をさらに含む、請求項１６に記載の装置。
前記複数のインジケータは、
サービス層がリソースを１回のみ検索し、かつ、それを将来使用するために保存することを指示する第１インジケータと、
前記リソースを検索する要求を受け取る都度サービス層がリソースを検索することを指示する第２インジケータと、
ある事象の発生時にサービス層がリソースを検索することを指示する第３インジケータと、
サービス層が周期的にリソースを検索することを指示する第４インジケータと、
を含む、請求項１７に記載の装置。
前記要求されたリソースのデータを含む応答を受け取ることと、そのデータを将来使用するために保存することと、をさらに含む、請求項１７に記載の装置。
前記データはデータモデルマッピングドキュメントを含み、該データモデルマッピングドキュメントは前記サービス層に登録される、請求項１７に記載の装置。