JP2020534605A - 通信ネットワークにおけるサービス層メッセージテンプレート - Google Patents

Abstract

【解決手段】要求テンプレートまたは応答テンプレートであり得るサービス層メッセージテンプレートの概念を導入する。メッセージテンプレートは、サービス層で作成および格納できる。各メッセージテンプレートは、要求または応答のパラメータとその値のセットを含むことができる。アプリケーションは、配置されると、メッセージテンプレート（すなわち、要求テンプレート）に含まれる要求パラメータを含まない要求をサービス層に送信することができる。その代わりに、メッセージテンプレート識別子を送信してもよい。要求パラメータはメッセージテンプレートに含まれ、サービス層に格納されるため、サービス層とアプリケーション（または、別のサービス層）の間の通信オーバーヘッドを軽減できる。

Description

関連出願の相互参照
本出願は、２０１７年９月１５日に出願の米国仮出願第６２／５５８，９４０号の利益を主張する。その内容全体は本明細書に参照により援用される。

例えば、ｏｎｅＭ２Ｍ、欧州電気通信標準化機構（European Telecommunications Standards Institute：ＥＴＳＩ）、オープンコネクティビティファウンデーション（Open Connectivity Foundation：ＯＣＦ）などの、多数の標準化団体において、異業種からのものであってもデータの交換と共有をアプリケーション間でするための、単一の水平プラットフォームを規定する、マシンツーマシン（Machine-to-Machine：Ｍ２Ｍ）／モノのインターネット（Internet of Things：ＩｏＴ）サービス層が開発されている。

Ｍ２Ｍ／ＩｏＴサービス層は、サービス層によってサポートされるＭ２Ｍ／ＩｏＴ指向機能（Ｍ２Ｍ／ＩｏＴサービス）のコレクションに対するアクセスを、アプリケーションおよびデバイスに提供することができる。そのような機能は、アプリケーションプログラミングインターフェース（Application Programming Interface：ＡＰＩ）を介してアプリケーションが利用できるようにすることができる。例えば、Ｍ２Ｍ／ＩｏＴサービス層は大量のＭ２Ｍ／ＩｏＴデータを維持することができ、アプリケーションは、Ｍ２Ｍ／ＩｏＴデータを発見、リトリーブ（検索して取得）、サブスクライブのうち少なくともどれか１つをすることができる（アプリケーションが適切なアクセス権を持つ場合）。サービス層が提供可能なＭ２Ｍ／ＩｏＴサービスのさらなる例として、セキュリティ、課金、デバイス管理、プロビジョニング、接続管理などがある。

ｏｎｅＭ２Ｍ標準は、そのサービス層を「共通サービスエンティティ（Common Service Entity：ＣＳＥ）」の形で実装する。ｏｎｅＭ２Ｍサービス層の目的は、異なる「垂直」Ｍ２Ｍシステムやアプリケーションが利用可能な「水平」サービスを提供することである。ｏｎｅＭ２Ｍ ＣＳＥは４つの参照点をサポートする。Ｍｃａ参照点はアプリケーションエンティティ（Application Entity：ＡＥ）とインターフェースをとる。Ｍｃｃ参照点は、同一サービスプロバイダドメイン内の別のＣＳＥとインターフェースをとり、Ｍｃｃ’参照点は、異なるサービスプロバイダドメイン内の別のＣＳＥとインターフェースをとる。Ｍｃｎ参照点は、基礎となるネットワークサービスエンティティ（Network Service Entity：ＮＳＥ）とインターフェースをとる。ＮＳＥは、デバイス管理、ロケーションサービス、およびデバイストリガリングなどの、基礎となるネットワークサービスをＣＳＥに提供する。ＣＳＥは、「発見」、「データ管理およびリポジトリ」などの、共通サービス機能（Common Service Function：ＣＳＦ）と呼ばれる複数の論理機能を含み得る。

ｏｎｅＭ２Ｍでは、そのＭｃａ、Ｍｃｃ、Ｍｃｃ’各参照点に対して要求／応答モデルが採用されている。例えば、ＡＥは、ＣＳＥに要求メッセージを送信して、そのリソースまたはサービスにアクセスできる。ｏｎｅＭ２Ｍは、各種パラメータに従って要求メッセージを処理し、対応する応答メッセージを生成するためのいくつかの拡張機能を提供する。加えて、各応答メッセージは様々な応答パラメータを含み得る。これらのパラメータは、複数の要求および応答メッセージにおいて繰り返される場合があり、結果として大きなサイズの要求／応答メッセージとなり得る。

背景技術で説明したように、サービス層要求メッセージは、要求パラメータのセットを含む場合があり、それによって、要求メッセージのサイズが増加し、サービス層とアプリケーション（または、別のサービス層）の間の通信効率が低下する可能性がある。同様に、サービス層の応答メッセージは、応答メッセージの肥大化につながる複数の応答パラメータを含む場合がある。加えて、同じまたは異なるアプリケーションからの要求メッセージには、同じ値を持つ同じ要求パラメータが冗長的に含まれる場合がある。また、サービス層から要求元への応答メッセージは、冗長な応答パラメータを含む可能性がある。特に、ＩｏＴサービス層においては、多すぎる要求パラメータによって要求メッセージが大きくなることに起因して高オーバーヘッドが不可避となり、第三世代パートナーシッププロジェクト（3rd Generation Partnership Project：３ＧＰＰ）狭帯域ＩｏＴやその他の低出力広域ネットワーク技術などのように、基礎となるネットワークの通信容量が限られている場合、管理が煩雑になる恐れがある。

本明細書では、特に、低出力広域ネットワークなどの限られた帯域幅の基礎ネットワークに関して、通信オーバーヘッドやその他の関連メトリックの観点から、大型の要求および応答メッセージによって引き起こされるサービス層とアプリケーション（または、別のサービス層）の間の通信の効率を改善する装置および方法について説明する。

一態様によれば、要求テンプレートまたは応答テンプレートを含むことができるサービス層メッセージテンプレートを採用することができる。メッセージテンプレートは、サービス層で作成および格納できる。各々のメッセージテンプレートは、要求または応答パラメータのセットとその値を含むことができる。アプリケーションは、配置されると、メッセージテンプレート（すなわち、要求テンプレート）に含まれる要求パラメータを含まない要求をサービス層に送信することができる。その代わりに、メッセージテンプレート識別子を送信してもよい。要求パラメータはメッセージテンプレートに含まれ、サービス層に格納されるため、サービス層とアプリケーション（または、別のサービス層）の間の通信オーバーヘッドを軽減できる。

本発明の概要は、以下の「発明を実施するための形態」でさらに説明される概念の選択を、単純化された形で紹介するために提供されるものである。本発明の概要は、特許請求された主題の主要な特徴または本質的な特徴を特定することを意図するものではなく、特許請求された主題の範囲を制限するために使用されることを意図するものでもない。さらに、特許請求された主題は、本開示のいかなる部分に記載された任意またはすべての短所を解決する制限にも限定されるものではない。

添付の図面と共に例として示される以下の説明から、より詳細な理解を得ることができる。
図１は、ｏｎｅＭ２Ｍによって規定されるネットワークアーキテクチャを示す図である。 図２は、スマートメータリングのユースケースを示し、そこでは、ユーザ装置（User Equipment：ＵＥ）である各スマートメーターが、３ＧＰＰ狭帯域のモノのインターネット（Narrow Band Internet of Things：ＮＢ−ＩｏＴ）などの低出力広域アクセス技術を使用してサーバにアクセスする。 図３は、アプリケーションとサービス層の間の相互作用を示す。 図４は、複数のアプリケーション（例えば、図２のスマートメーター上のスマートメーターアプリケーション）が同一のサービス層と相互作用する例を示す。 図５は、要求テンプレートを活用してサービス層の要求メッセージをサイズ低減の観点から最適化する方法の一実施形態を示す。 図６は、応答テンプレートを活用してサービス層の応答メッセージをサイズ低減の観点から最適化する方法の一実施形態を示す。 図７は、メッセージテンプレート管理の全体的な方法を示す。 図８は、要求元が独立した要求を使用して開始する要求テンプレート作成の方法を示す。 図９は、図８の方法に関連した例を示す図である。 図１０は、通常要求を送信する際に要求元によって開始される要求テンプレート作成の方法を示す。 図１１は、サービス層によって開始される要求テンプレート作成の方法を示し、作成された要求テンプレートの識別子は、別の通知メッセージを使用して要求元に返送される。 図１２は、サービス層が、いくつかの類似する要求パラメータを使用する３つの連続する通常要求を受信する例を示す。 図１３は、サービス層によって開始される要求テンプレート作成の方法を示し、作成された要求テンプレートの識別子は、通常応答にピギーバックされて要求元に返送される。 図１４は、サービス層により開始される自発的な要求テンプレート作成の方法を示す。 図１５は、応答テンプレート作成の手順を示す。 図１６は、メッセージテンプレートの割り当てと発見の方法を示し、起こり得る３つのケースを示す。 図１７は、サービス層登録手順中にメッセージテンプレートを作成／割り当てるための簡便で、より軽量な形式の手法を示す。 図１８は、メッセージテンプレートをリトリーブする方法を示す。 図１９は、要求テンプレートを活用する方法を示す。 図２０は、要求および応答テンプレートを活用する方法を示す。 図２１は、専用メッセージを使用してメッセージテンプレートを更新する方法を示す。 図２２は、要求元が要求メッセージをサービス層に送信する際に、同時にメッセージテンプレートを更新する方法を示す。 図２３は、専用メッセージを使用してメッセージテンプレートを削除する方法を示す。 図２４は、要求元が要求メッセージをサービス層に送信する際に、同時にメッセージテンプレートを削除する方法を示す。 図２５は、１つの要求メッセージで複数の要求テンプレートを活用する方法を示す。 図２６は、トランジットサービス層がテンプレート関連機能をサポートしない場合に、マルチホップサービス層通信のための要求テンプレートを使用する方法を示す。 図２７は、宛先サービス層がテンプレート関連機能をサポートしない場合に、マルチホップサービス層通信において要求テンプレートを使用する方法を示す。 図２８は、トランジットサービス層と宛先サービス層が両方ともテンプレート関連機能をサポートする場合に、マルチホップサービス層通信において要求テンプレートを使用する方法を示す。 図２９は、要求元がテンプレート関連機能をサポートしない場合に、マルチホップサービス層通信において要求テンプレートを使用する方法を示す。 図３０は、メッセージテンプレートポリシーを作成する方法を示す。 図３１は、メッセージテンプレートをメッセージテンプレートポリシーに関連付けたり、逆に、メッセージテンプレートポリシーをメッセージテンプレートに関連付けたりする方法を示す。 図３２は、既存のメッセージテンプレートポリシーをリトリーブ／更新／削除する方法を示す。 図３３は、messageTemplateリソースの構造の一例を示す。 図３４は、<messageTemplate>リソースを操作する（例えば、<messageTemplate>リソースを作成／リトリーブ／更新／削除する）方法を示す。 図３５は、messageTemplatePolicyリソースの構造を示す。 図３６は、<messageTemplatePolicy>リソースを操作する（例えば、<messageTemplatePolicy>リソースを作成／リトリーブ／更新／削除する）方法を示す。 図３７は、サービス層（例えば、ｏｎｅＭ２Ｍ ＣＳＥ）におけるメッセージテンプレート管理のためのユーザインターフェースの一実施形態を示す。 図３８は、サービス層（例えば、ｏｎｅＭ２Ｍ ＣＳＥ）におけるメッセージテンプレートポリシー管理のためのユーザインターフェースを示す。 図３９Ａは、１つまたは複数の開示される実施形態が実施され得るマシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（Web of Things：ＷｏＴ）の例示的な通信システムのシステム図である。 図３９Ｂは、図３９Ａに示されるＭ２Ｍ／ＩｏＴ／ＷｏＴ通信システム内で使用され得る例示的なアーキテクチャのシステム図である。 図３９Ｃは、図３９Ａおよび図３９Ｂに示される通信システム内で使用され得るＭ２Ｍ／ＩｏＴ／ＷｏＴデバイス、ゲートウェイ、サーバなどの例示的な通信ネットワーク装置のシステム図である。 図３９Ｄは、図３９Ａおよび図３９Ｂの通信システムのノードまたは装置を内部に具現化し得る例示的なコンピューティングシステムのブロック図である。

ｏｎｅＭ２Ｍ標準は、サービス層を「共通サービスエンティティ（Common Service Entity：ＣＳＥ）」の形で実装する。ｏｎｅＭ２Ｍサービス層の目的は、異なる「垂直」Ｍ２Ｍシステムやアプリケーションが利用可能な「水平」サービスを提供することである。ＣＳＥは、図１に示すように、４つの参照点をサポートする。Ｍｃａ参照点はアプリケーションエンティティ（Application Entity：ＡＥ）とインターフェースをとる。Ｍｃｃ参照点は、同一サービスプロバイダドメイン内の別のＣＳＥとインターフェースをとり、Ｍｃｃ’参照点は、異なるサービスプロバイダドメイン内の別のＣＳＥとインターフェースをとる。Ｍｃｎ参照点は、基礎となるネットワークサービスエンティティ（Network Service Entity：ＮＳＥ）とインターフェースをとる。ＮＳＥは、デバイス管理、ロケーションサービス、およびデバイストリガリングなどの、基礎となるネットワークサービスをＣＳＥに提供する。ＣＳＥは、「発見」、「データ管理およびリポジトリ」などの、共通サービス機能（Common Service Function：ＣＳＦ）と呼ばれる複数の論理機能を含む。

図１に示すように、ｏｎｅＭ２Ｍアーキテクチャは、アプリケーションサービスノード、アプリケーション専用ノード、中間ノード、インフラストラクチャノード、および非ｏｎｅＭ２Ｍノードの各タイプのノードを可能にする。

アプリケーションサービスノード（Application Service Node：ＡＳＮ）は、１つのＣＳＥを含み、少なくとも１つのアプリケーションエンティティ（ＡＥ）を含むノードである。物理マッピングの例として、ＡＳＮは、センサなどのマシンツーマシン（Ｍ２Ｍ）デバイス内に常駐することもできる。

アプリケーション専用ノード（Application Dedicated Node：ＡＤＮ）は、少なくとも１つのＡＥを含み、ＣＳＥを含まないノードである。ｏｎｅＭ２Ｍシステムのフィールドドメインには、０個以上のＡＤＮが存在し得る。物理マッピングの例として、ＡＤＮは、制約のあるＭ２Ｍデバイス内に常駐することもできる。

中間ノード（Middle Node：ＭＮ）は、１つのＣＳＥを含み、０個以上のＡＥを含むノードである。ｏｎｅＭ２Ｍシステムのフィールドドメインには、０個以上のＭＮが存在し得る。物理マッピングの例として、ＭＮは、Ｍ２Ｍゲートウェイに常駐することもできる。

インフラストラクチャノード（Infrastructure Node：ＩＮ）は、１つのＣＳＥを含み、０個以上のＡＥを含むノードである。インフラストラクチャドメインには、ｏｎｅＭ２Ｍサービスプロバイダごとに正確に１つのＩＮが存在する。ＩＮのＣＳＥは、他のノードタイプには適用できないＣＳＥ機能を含んでもよい。物理マッピングの例として、ＩＮは、Ｍ２Ｍサービスインフラストラクチャに常駐することもできる。

非ｏｎｅＭ２Ｍノード（Non-oneM2M Node：ＮｏＤＮ）は、ｏｎｅＭ２Ｍエンティティを含まない（ＡＥやＣＳＥも含まない）ノードである。このようなノードは、管理などのインターワーキングのためにｏｎｅＭ２Ｍシステムに接続されたデバイスに相当する。

ｏｎｅＭ２Ｍでは、そのＭｃａ、Ｍｃｃ、Ｍｃｃ’各参照点に対して要求／応答モデルが採用されている。例えば、ＡＥは、ＣＳＥに要求メッセージを送信して、そのリソースまたはサービスにアクセスできる。ｏｎｅＭ２Ｍは、表１に説明するいくつかの新しいパラメータを介して要求メッセージを処理し、対応する応答メッセージを生成するためのいくつかの拡張機能を提供する。さらに、各応答メッセージは、表２に示すようないくつかの応答パラメータを含む。これらのパラメータは、複数の要求および応答メッセージにおいて繰り返される可能性があり、結果として大きなサイズのｏｎｅＭ２Ｍ要求や応答メッセージとなり得ることに留意されたい。

本明細書で説明される技術的解決策が対象とする技術的問題をよりよく理解するために、例示のためのユースケースを提示する。図２は、スマートメータリングのユースケースを示し、そこでは、ユーザ装置（ＵＥ）である各スマートスマートメーターが、３ＧＰＰ狭帯域のモノのインターネット（ＮＢ−ＩｏＴ）などの低出力広域アクセス技術を使用して、様々なＵＥからのメーターデータを格納して管理するためのＩｏＴサービス層を備えるサーバにアクセスする。サーバは、電力会社によって配備される可能性がある。例えば、スマートメーターアプリケーションが各ＵＥ上で作動して、メーター指示値を定期的にサーバに送信することもできる。また、（例えば、同一共同体に配備された）複数のスマートメーターが、同じ方法で、指示値をサーバに報告してもよい（例えば、周波数、サーバによる要求メッセージの処理方法などを報告してもよい）。そのため、各スマートメーターは、類似する要求メッセージをサーバに繰り返し送信する場合があり、複数のメーターが類似する要求メッセージを異なる時期にサーバに送信する場合もある。これらの２つの側面を要約して、図３および図４と関連して、さらに説明する。

図３は、アプリケーションとサービス層の間の相互作用を示す。この例では、アプリケーション（例えば、図２のスマートメーター上のスマートメーターアプリケーション「エラー！参照先が見つかりません。」）は、要求メッセージをサービス層に繰り返し送信する。各要求メッセージは、要求パラメータのセットを含んでいる。同様に、対応する応答メッセージは、応答パラメータを含んでいる。さらに、アプリケーションは、特定の期間中、サービス層から同じサービス／リソースを要求できる。したがって、繰り返される要求メッセージの各々は、同じ要求パラメータのセットを含む。

図４は、複数のアプリケーション（例えば、図２のスマートメーター上のスマートメーターアプリケーション）が同一のサービス層と相互作用する別の例を示す。このシナリオでは、３つ（またはそれ以上）のアプリケーションが異なるサービス／リソースにアクセスすることができるが、それらのアプリケーションは、同じ方法で要求メッセージを処理するようにサービス層に指示してもよい。例えば、それらのアプリケーションは、同一の要求メッセージ有効期限や同一の結果有効期限などをサービス層に対して示してもよい。したがって、各アプリケーションからの要求メッセージは、同じ要求パラメータのセットを含み得る。

前述のユースケースによって示された問題に対する技術的解決策に入る前に、もっぱら説明を簡単にするために、ここで特定の用語を定義する。下記用語は以下のような意味としてとらえることができる。

サービス層は、アプリケーションとアプリケーションプロトコル層の間のプロトコル層として説明することができる。サービス層は、リソースを格納し、サービスを提供する。サービスは、アプリケーションや他のサービス層に公開され、アプリケーションや他のサービス層からアクセスおよび操作することができる。

要求／応答モデルは、サービス層とアプリケーションの間（または、２つのサービス層間）の相互作用モデルであり得る。このモデルにおいては、アプリケーション（または、別のサービス層）が要求メッセージをサービス層に送信し、サービス層が応答メッセージをアプリケーション（または、別のサービス層）に返送する。

要求メッセージは、サービス層によって提供されるサービスを要求するために、アプリケーション（または、別のサービス層）からサービス層に送信されるメッセージであり得る。サービス層は、受信した要求メッセージを処理し、要求メッセージの発信元に応答メッセージを送信する。要求メッセージは、サービス層から別のアプリケーションに送出することもできる。

要求パラメータは、要求メッセージに含まれ、かつ、要求メッセージをいつ、どのように処理するか、生成された結果をどのように維持するか、応答メッセージをいつ、どのように返送するかなどをサービス層に指示するパラメータであり得る。

応答メッセージは、要求メッセージの受信と処理の結果として、サービス層からアプリケーション（または、別のサービス層）に送信されるメッセージであり得る。応答メッセージは、アプリケーションからサービス層に送出することもできる。

応答パラメータは、応答メッセージに含まれるパラメータであり得る。例えば、リソースのリトリーブを要求元がサービス層に要求した場合、サービス層が生成する応答メッセージは、リトリーブされたリソースの表現を含むための「コンテンツ」パラメータを含み得る。

メッセージテンプレート（Message Template：ＭＴ）は、要求メッセージを記述するための要求テンプレートまたは応答メッセージを記述するための応答テンプレートであり得る。要求テンプレートは、サービス層および要求元側の少なくとも一方のメモリに格納され、アプリケーションによって発見およびリトリーブできる。応答テンプレートも、サービス層および要求元側の少なくとも一方に格納できる。メッセージテンプレートは、サービス層、アプリケーション、および他のサービス層のうち少なくとも１つが管理することができる。ＭＴは、例えば、表、拡張可能なマーク付け言語（Extensible Markup Language：ＸＭＬ）ドキュメント、またはその他の任意の適切な機械可読データ構造またはドキュメントなどの、テンプレートのパラメータ値を保持する適切なデータ構造の形をとることができる。

要求テンプレート（Request Template：ＲＥＱＴ）は、要求で繰り返し使用される所定のメッセージに対するいくつかの共通要求パラメータとそれらの値を含む。アプリケーションまたは別のサービス層は、要求メッセージテンプレートを活用して、要求パラメータのうち共通に利用されるサブセットがテンプレートに含まれるとその後は省略することができる、最適化された要求を生成することができる。

応答テンプレート（Response Template：ＲＳＰＴ）は、応答メッセージをどのように生成すべきか、および応答メッセージがどのように見えるかを記述する。応答テンプレートを、要求テンプレートまたは要求に関連付けることができる。そのため、サービス層は、受信した最適化された要求を要求テンプレートを使用して処理するとき、どの応答テンプレートを使用して応答メッセージを生成すべきかを理解する。さらに、サービス層は、要求元側で応答テンプレートを作成して、サービス層から要求元に繰り返し送信されることになる応答パラメータを含めることができる。サービス層はこの種の応答テンプレートを使用して、これらの繰り返される応答パラメータを省略することにより、最適化された応答を生成できる。要求元はこの種類の応答テンプレートをローカルに格納し、それを使用して、受信した最適化された応答から元の応答メッセージを復元できる。応答テンプレートを使用して、要求テンプレートを含む要求にも、含まない要求にも返信することができることに留意されたい。

メッセージテンプレート識別子（Message Template Identifier：ＭＴＩＤ）は、サービス層に格納された要求テンプレートまたは応答テンプレートのどちらでもあり得るメッセージテンプレートのユニバーサルリソース識別子（Universal Resource Identifier）または数値識別子のどちらであってもよい。

要求テンプレート識別子（Request Template Identifier：ＲＱＴＩＤ）は、サービス層に格納された要求テンプレートのユニバーサルリソース識別子または数値識別子のどちらであってもよい。

応答テンプレート識別子（Response Template Identifier：ＲＳＴＩＤ）は、サービス層に格納された応答テンプレートのユニバーサルリソース識別子または数値識別子のどちらであってもよい。

メッセージテンプレート管理は、メッセージテンプレートの作成、メッセージテンプレートのリトリーブ、メッセージテンプレートの活用、メッセージテンプレートの更新、メッセージテンプレートの削除、メッセージテンプレートを１つまたは複数のメッセージテンプレートポリシーへの関連付けなどのタスクを含むことができる。

メッセージテンプレートポリシーは、メッセージテンプレートの適用可能性を記述または制限するための条件（例えば、どのメッセージテンプレートを、どのターゲットリソースに対するどの要求元に、いつ適用するか）を含むことができる。

通常要求は、サービス層またはアプリケーション層においてネイティブに定義およびサポートされる要求メッセージであり得る。通常要求は、サービス層によって指定されるような要求パラメータのセットを含めるために使用される。通常要求は、いかなる要求テンプレートも活用しない。

最適化された要求は、要求テンプレートを活用することにより強化された要求メッセージであり得る。一般に、最適化された要求は、要求テンプレート識別子を収容し、要求テンプレートに含まれる要求パラメータを削除することにより、要求元側で作成される。したがって、最適化された要求は通常要求よりも短縮される。

通常応答は、サービス層またはアプリケーション層においてネイティブに定義およびサポートされる応答メッセージであり得る。通常応答は、サービス層によって指定されるような応答パラメータのセットを含めるために使用される。通常応答は、要求元側に格納されたいかなる応答テンプレートも活用しない。

最適化された応答は、応答テンプレートを活用することにより強化された応答メッセージであり得る。一般に、最適化された応答は、応答テンプレート識別子を収容し、応答テンプレートに含まれる応答パラメータを削除することにより、サービス層側で作成される。したがって、最適化された応答は通常応答よりも短縮される。

本説明の残りの部分では、メッセージテンプレートとは、明示的に述べない限り、要求テンプレートまたは応答テンプレートのいずれかのことを指す場合がある。同様に、メッセージテンプレート識別子（ＭＴＩＤ）とは、明示的に述べない限り、要求テンプレート識別子（ＲＱＴＩＤ）または応答テンプレート識別子（ＲＳＴＩＤ）のことを指す場合がある。

以下の説明では、メッセージテンプレートを活用するためのメカニズムについて説明する。次に、メッセージテンプレート管理のための全体的な手順を説明し、続いて、メッセージテンプレートの作成、メッセージテンプレートの割り当てと発見、メッセージテンプレートのリトリーブ、メッセージテンプレートの使用、メッセージテンプレートの更新、メッセージテンプレートの削除などの、実行し得る各メッセージテンプレート管理タスクの実施形態について説明する。

もっぱら説明を簡単にするために、以下の説明では、要求メッセージは、アプリケーション（または、別のサービス層）からサービス層に送出されるものとして説明する。しかし、ここで説明する概念、メカニズム、および実施形態は、サービス層がアプリケーションに要求メッセージを送信し、それに応じてアプリケーションからサービス層に応答メッセージが送信されるシナリオに直接適用可能である。

図５は、要求テンプレートを活用してサービス層の要求メッセージをサイズ低減の観点から最適化する方法の一実施形態を示す。留意すべきことは、図５の要求元は、アプリケーションまたは別のサービス層である可能性があるということであり、さらに、各ステップにはいくつかのサブステップが含まれる可能性があるということであるが、これについては、以下の説明で詳述する。要求テンプレートに含まれる要求パラメータは、特定の順序で並んでいない可能性があることに留意されたい。

図５を参照すると、ステップ１で、要求元は要求テンプレート（ＲＥＱＴ）の作成を要求する。あるいは、サービス層は、いくつかのＲＥＱＴを自発的に作成することもできる。要求は、要求に通常現れる情報要素に用いられる既定値を含んでもよい。これらの既定値に基づいて、ＲＥＱＴを構築することができる。後に、ＲＥＱＴが要求元によって使用される際、ＲＥＱＴが使用されることを示す異なる値が要求中に提供されていない場合、サービス層は既定値を仮定することができる。

ステップ２では、サービス層は、ＲＥＱＴおよびＲＥＱＴ識別子を作成し、それらを、サービス層が実装されるネットワーク装置のメモリにローカルに格納する。

ステップ３では、ＲＥＱＴの作成元ではない要求元が、作成されたＲＥＱＴを活用できるようにするためには、要求元は、サービス層に送信すべき将来の要求メッセージを最適化するために、ＲＥＱＴのコンテンツ（例えば、どの要求パラメータがＲＥＱＴに含まれているか）を知る必要がある。そのため、要求元は、ＲＥＱＴとそれに関連する識別子を発見してリトリーブする必要がある。あるいは、図には示されていないが、サービス層は、１つまたは複数のＲＥＱＴを要求元に能動的に割り当てることができる。

ステップ４では、要求元は、ＲＥＱＴをリトリーブするかまたはＲＥＱＴの割り当てまたは通知を受けた後、それを使用して、ＲＥＱＴの識別子を含み、ＲＥＱＴに既に含まれているパラメータを除いた、最適化された要求を生成する。要求パラメータがＲＥＱＴに含まれていない場合、要求元は、最適化された要求に要求パラメータを含める必要がある。最適化された要求は、通常要求よりも少ないパラメータを含むため、サイズが縮小され、サービス層との通信のオーバーヘッドも軽減される。

ステップ５では、要求元は最適化された要求をサービス層に送信する。最適化された要求には、ステップ４で最適化された要求を生成するために使用されたＲＥＱＴの識別子が含まれていることに留意されたい。要求は、ＲＥＱＴの一部であった情報要素の値も提供することができる。要求元は、その値の存在を利用して、ＲＥＱＴ上の既定値を提供された値でオーバーライドする必要があることを示すことができる。

ステップ６では、サービス層は、最適化された要求を受信し、それをＲＥＱＴに従って処理する。具体的には、サービス層は、まず、最適化された要求に含まれるＲＥＱＴ識別子を使用して、適切なＲＥＱＴを見つけ、その後、ＲＥＱＴに含まれる要求パラメータとその他の情報を、最適化された要求内のその他のパラメータ／情報と共に使用して、受信した最適化された要求を、通常要求の処理に用いる方法で処理する。その後、サービス層が応答テンプレートをサポートしていない場合、サービス層は通常応答を生成し要求元に返送する。サービス層が応答テンプレートをサポートしている場合、サービス層は、応答テンプレートを活用して、最適化された応答を生成することができる（図５参照）。

留意すべきことは、図５に示す全体的な手順によれば、要求テンプレートを作成／発見／リトリーブするためのサービス層と要求元の間のメッセージングがさらに行われるが、要求元が同じタイプの要求をサービス層に繰り返し送信する場合と、メッセージテンプレートが複数の要求元によって使用される場合の少なくとも一方の場合、（メッセージテンプレートを使わない単一の要求／応答と比べて）大きな節約を達成することができるということである。これは、この後に続くすべての要求（または、複数の要求元からの要求）がＲＥＱＴを活用する可能性があるためである。

図６は、応答テンプレートを活用してサービス層の応答メッセージをサイズ低減の観点から最適化する方法の一実施形態を示す。図６の要求元は、アプリケーションまたは別のサービス層である可能性があり、さらに、図６の各ステップにはいくつかのサブステップが含まれる可能性があるということに留意されたい。応答テンプレートに含まれる応答パラメータは、特定の順序で並んでいない可能性があることに留意されたい。

図６を参照すると、ステップ１で、要求元は応答テンプレート（ＲＳＰＴ）の作成を要求する。あるいは、サービス層は、いくつかのＲＳＰＴを自発的に作成することもできる。要求元からの要求は、応答パラメータ、ＲＳＰＴ識別子、またはＲＳＰＴの構築に使用すべき完全な応答を提供し得る。例えば、要求元は、ＲＳＰＴを構築する際にどのような応答パラメータを仮定すべきかを示すことができる。

ステップ２では、サービス層は、ＲＳＰＴおよびＲＳＰＴ識別子を作成し、それらを、サービス層が実装されるネットワーク装置のメモリにローカルに格納する。

ステップ３では、サービス層は、同ＲＳＰＴおよび識別子を要求元に送信して、要求元がそれを使用して、将来受信されるすべての最適化された応答を正しく処理できるようにする。

ステップ４では、要求元はＲＳＰＴをローカルに格納する。

ステップ５では、サービス層は、受信した要求を処理する際に、要求元に既知のＲＳＰＴに従って、最適化された応答を生成する。最適化された応答は、使用されたＲＳＰＴの識別子を含み得る。通常応答と比べて、最適化された応答では、ＲＳＰＴに既に含まれているパラメータ／情報が除かれ、メッセージサイズが縮小される。留意すべきことは、要求元によって送出され受信された要求によって、サービス層への要求の送信時に、特定のＲＳＰＴを作成または使用、あるいはその両方をするようにサービス層に明示的に要求することができ、要求メッセージにＲＳＰＴ識別子または「ＲＳＰＴ使用（USE RSPT）」フラグを含めることで、ＲＳＰＴを使用することへの要求を示すことができるということである。

ステップ６では、サービス層は、最適化された応答を要求元に送信する。最適化された応答には、ＲＳＰＴ識別子が含まれる。最適化された応答では、ＲＳＰＴに含まれる応答パラメータは省略され、ＲＳＰＴ識別子が含まれる。ＲＳＰＴに定義されている値をオーバーライドするために、応答には、ＲＳＰＴに割り当てられた既定値であるパラメータのうちのいくつかの値を含むことができる。

ステップ７では、要求元は最適化された応答を受信して、ＲＳＰＴ識別子を使用して対応するＲＳＰＴを見つけ、ＲＳＰＴに含まれる応答パラメータおよび情報を使用して、最適化された応答を処理する。

ここで、メッセージテンプレート管理の方法を説明する。一態様によれば、要求元（すなわち、アプリケーションまたは別のサービス層）は、サービス層上でメッセージテンプレートの作成を開始することができる。メッセージテンプレートが作成されたら、同要求元または他の要求元に割り当てたり、同要求元または他の要求元が発見したりすることができる。要求元は、適切なメッセージテンプレートを発見するか、またはそれを割り当てられると、それを使用して、いくつかの要求（または応答）パラメータが省略されてメッセージテンプレート識別子に置き換えられた最適化された要求（または応答）を生成することができる。その後は、メッセージテンプレートをＲＥＳＴｆｕｌな方法で操作すること（すなわち、メッセージテンプレートのリトリーブ、メッセージテンプレートの更新、メッセージテンプレートの削除）ができる。

図７は、図５および図６に関連して説明した事項に基づき、かつ、それと整合するメッセージテンプレート管理の全体的な方法を示す。図７に示される概念の１つは、要求元またはサービス層が作成したメッセージテンプレートに関して、他の要求元への割り当て、他の要求元による発見、使用のうち、少なくとも１つが行われるということである。

図７を参照すると、ステップ１で、メッセージテンプレートが作成され、サービス層に格納される。この処理は、要求元１またはサービス層自身が開始することができる。メッセージテンプレートは、図５および図６に説明するように作成できる。

ステップ２では、作成されたメッセージテンプレートに関して、要求元２（または要求元１）への割り当ておよび要求元２（または要求元１）による発見の少なくとも一方が行われる。サービス層は、要求元１によって作成されたメッセージテンプレートを要求元２に割り当てることができる（図には示されていないが、その逆も可能である）ことに留意されたい。要求元２（または要求元１）は、メッセージテンプレートを発見または割り当てられた後、メッセージテンプレートが更新（ステップ５）または削除（ステップ６）されたときに自動通知を受信するために、メッセージテンプレートへのサブスクリプションを作成することができることに留意されたい。ここで、要求元にメッセージテンプレートが割り当てられているとは、次のことを意味する。１）メッセージテンプレートとその識別子が要求元に与えられる。２）要求元は、割り当てられたメッセージテンプレートを使用して、それが要求テンプレートである場合に、最適化された要求を生成し、それが応答テンプレートである場合に、最適化された応答から通常応答を生成する権限を与えられるか、強制される、またはその両方である。

ステップ３では、要求元２（または要求元１）は、サービス層からメッセージテンプレートをリトリーブする。

ステップ４では、要求元２（または要求元１）は、メッセージテンプレート（すなわち、要求テンプレート）を使用して、最適化された要求を生成し、サービス層と相互作用する。複数のテンプレートを共同活用して、最適化された要求を生成することもできることに留意されたい。サービス層は、最適化された要求を受信すると、対応するテンプレートを見つけ、それを使用して最適化された要求を処理する。このプロセスでは、要求元２（または要求元１）は、要求メッセージをサービス層に送信すると、応答テンプレートの作成および使用の少なくとも一方を実行して要求元２（または要求元１）への最適化された応答を生成するように、サービス層に指示することができる。

ステップ５では、メッセージテンプレートは、要求元２（または要求元１）またはサービス層自身によって更新され得る。例えば、メッセージテンプレートに含まれるパラメータまたは情報は更新可能である。更新されたメッセージテンプレートが複数の要求元によって使用およびサブスクライブの少なくとも一方がされている場合、サービス層はそれらの要求元に通知を送信して更新を通知する。

ステップ６では、メッセージテンプレートは、要求元２（または要求元１）またはサービス層自身によって削除され得る。削除されたメッセージテンプレートが複数の要求元によって使用またはサブスクライブされている場合、サービス層はそれらの要求元に通知を送信してメッセージテンプレートの削除を通知する。

一態様においては、要求元は、要求メッセージをサービス層に送信することにより、要求テンプレートの作成を自発的に開始することができる。このステップの前に、要求元は、例えばサービス発見を通じて、サービス層がメッセージテンプレート機能をサポートしていることを発見している可能性もあるが、それを可能にするには、サービス層は、メッセージテンプレート機能を公開／発表して、要求元が発見できるようにする必要がある。要求元が要求テンプレート作成要求をサービス層に送信するには、２つのケースがある。ケース１では、要求元は、専用の要求テンプレート作成要求をサービス層に送信する。この要求には、必要に応じて値を含むいくつかの要求パラメータが含まれる。ケース２では、要求元は、要求テンプレート作成インジケータ（Request Template Creation Indicator：ＲＱＴＣＩ）を通常要求にピギーバックする。ＲＱＴＣＩは、サービス層に、要求テンプレートの作成方法（例えば、作成するメッセージテンプレートにどの要求パラメータとその値を含めるか）を通知する。サービス層は、ＲＱＴＣＩの指定に従って要求テンプレートを作成する。

図８は、要求元が独立した要求を使用して開始する要求テンプレート作成の方法を示す。ステップ１で、要求元は要求テンプレート作成要求をサービス層に送信して、要求テンプレートを作成するようサービス層に指示する。このメッセージは、以下のパラメータを含むことができる。
・templateType：作成すべきメッセージテンプレートのタイプが要求テンプレートであることを示す。
・numOfRequestTemplatesToBeCreated(Nt)：作成すべき要求テンプレートの数を示す。要求元は、複数の要求テンプレートの作成を要求できる。この場合、各テンプレートに含むべき要求パラメータは、listOfRequestParametersに含まれる。
・listOfRequestParameters：作成すべき要求テンプレートに含まれる値を含む要求パラメータのリストを示す。通常、これらのパラメータとその値は、将来の要求で繰り返し使用される。そのため、要求テンプレートを作成してそれらを含めることで、将来の要求でそれらを省略して、将来の要求のサイズを縮小することができる。numOfRequestTemplateToBeCreatedが複数存在する（すなわち、Nt > 1である）場合に備えて、listOfRequestParametersは含まれるすべてのパラメータをNt個のサブグループに分割し、各サブグループのパラメータを使用して個々の要求テンプレートを作成する。図９に示すように、要求メッセージにNp個（例えば、Np = 15）の要求パラメータがあり、Nt = 3であると仮定する。この例では、listOfRequestParametersには、パラメータのサブグループが３つ含まれる。第１のサブグループには２つの要求パラメータが含まれ、第１要求テンプレートＲＥＱＴ１の作成に使用され、第２のサブグループには続く３つの要求パラメータが含まれ、第２要求テンプレートＲＥＱＴ２の作成に使用され、第３のサブグループには最後の２つのパラメータが含まれ、第３要求テンプレートＲＥＱＴ３を作成するために使用される。図８に示すように、いくつかの要求パラメータは要求テンプレートに含まれないか、使用されないことに留意されたい。ｏｎｅＭ２Ｍを例にとると、表１に示す、以下のような、いくつかの要求パラメータを要求テンプレートに含めることができる：操作、要求有効期限タイムスタンプ、結果有効期限タイムスタンプ、操作実行時間、応答タイプ、結果持続性、結果コンテンツ、イベントカテゴリー、配信アグリゲーション、グループ要求識別子、フィルタ基準、発見結果タイプ、セキュリティ情報など。
・listOfExistingRequestTemplateIDs：サービス層で作成および格納済みの既存要求テンプレート識別子のリストを示す。このパラメータは、既存の要求テンプレートに基づいて新しい要求テンプレートを作成するために使用されるため、要求元は要求パラメータを指定する必要はなく、既存要求テンプレートの識別子だけを指定すればよい。このパラメータがステップ１に含まれている場合、作成すべき要求テンプレートは、これらの既存要求テンプレートに加えて、listOfRequestParametersに示されているパラメータに基づく。言い換えれば、作成すべき要求テンプレートには、既存要求テンプレート、およびNt = 1の場合のlistOfRequestParametersに含まれるすべての要求パラメータが含まれる。さらに図９を例として使用すると、図９に示すように、３つの要求テンプレートＲＥＱＴ１、ＲＥＱＴ２、ＲＥＱＴ３がlistOfExistingRequestTemplateIDsに含まれる場合、サービス層は新しい要求テンプレートＲＥＱＴ１２３を作成する。要求テンプレートＲＥＱＴ１２３は、これら３つの既存要求テンプレートの識別子のみを含むことができるが、基本的に要求テンプレートＲＥＱＴ１、ＲＥＱＴ２、ＲＥＱＴ３のすべての要求パラメータを含むことができる。このような新しい要求テンプレートを作成することにより、サービス層は、要求元が既存要求テンプレートを活用または再利用するための柔軟性と効率を高める。例えば、要求元は、後で要求テンプレートＲＥＱＴ１２３を使用するだけで、最適化された要求を生成することができ、サービス層にＲＥＱＴ１２３の識別子を通知するだけでよい。一方、そのような新しいテンプレートを使用しない場合、要求元は、ＲＥＱＴ１、ＲＥＱＴ２、およびＲＥＱＴ３を共に使用して、同じ最適化された要求を生成する必要があり、サービス層に３つの（それぞれ、ＲＥＱＴ１、ＲＥＱＴ２、およびＲＥＱＴ３に関する）識別子を通知する必要がある。numOfRequestTemplatesToBeCreatedが複数存在する（すなわち、Nt > 1である）場合、listOfRequestParametersが要求パラメータをいくつかのサブグループに分割する方法と同様に、listOfExistingRequestTemplateIDsは、含まれるすべてのテンプレート識別子をNt個のサブグループに分割する必要があり、各サブグループのテンプレート識別子を使用して、個々の要求テンプレートを作成することになる。
・listOfAllowedRequestors：ステップ２で作成すべき要求テンプレート活用できる要求元のリストを示す。このパラメータはオプションである。
・listOfTargetResources：ステップ２で作成すべき要求テンプレートを適用可能なターゲットリソースのリストを示す。このパラメータはオプションである。
・MTPList：作成される要求テンプレートに適用される既存のメッセージテンプレートポリシーのリストを示す。このパラメータはオプションである。このパラメータが含まれている場合、listOfAllowedRequestorsとlistOfTargetResourcesは不要となり得る。

さらに図８を参照すると、ステップ２で、サービス層は、ステップ１から要求テンプレート作成要求を受信し、それを処理して、要求元から要求されたように、対応する要求テンプレートを生成する。サービス層は、同じテンプレートが以前に作成されているかどうかを確認することができ、作成されている場合、新しいテンプレートを作成しないようにすることができる。作成された要求テンプレートは、いくつかの要求パラメータとその他のプロパティ（例えば、作成、有効期限、許可された要求元のリスト、ターゲットリソースのリスト、子としての他の要求テンプレートのリストなど）を含み得る。一実施形態では、numOfRequestTemplatesToBeCreatedが１に等しい（すなわち、Nt = 1である）場合、サービス層は、listOfRequestParametersに含まれるすべての要求パラメータと、listOfExistingRequestTemplateIDsに示された任意の既存要求テンプレートを使用するだけで、新しい要求テンプレートを作成することに留意されたい。サービス層は、作成された要求テンプレートに識別子を割り当てる。また、一実施形態では、numOfRequestTemplatesToBeCreatedが１より大きい（すなわち、Nt > 1である）場合、サービス層はNt個の要求テンプレートを作成する必要があることにも留意されたい。作成すべき各要求テンプレートは、listOfRequestParametersのサブグループに含まれる要求パラメータと、サブグループlistOfExistingRequestTemplateIDsに含まれる任意の既存テンプレート識別子に基づいている必要がある。サービス層は、作成された各要求テンプレートに識別子を割り当てる。テンプレートのパラメータ値を格納するための適切なデータ構造を持つ要求テンプレートは、作成されると、サービス層を実装しているネットワーク装置（例えば、サーバ、ゲートウェイ、デバイスなど）のメモリに格納され得る。

要求テンプレートは、例えば、表、拡張可能なマーク付け言語（ＸＭＬ）ドキュメント、またはその他の任意の適切なデータ構造またはドキュメントなどの、任意の適切な形式のデータ構造で実装可能である。上述のスマートメータリングのユースケースを参照して、スマートメーターを、ｏｎｅＭ２Ｍプロトコルを使用してサーバサービス層（すなわち、サーバＣＳＥ）におけるcontentInstanceリソースの作成を通じて定期的にその指示値を報告するＡＥ（すなわち、meterAE123）と仮定して、そのユースケースのコンテキストで作成し得るテンプレートの例を以下に示す。下記の要求テンプレートは、以下の９つのパラメータを含むサーバで作成できるが、ユースケースの要件次第で、要求テンプレートにさらに多くの要求パラメータを含めることも可能である。
１．操作はリソースの作成である。
２．発信元または要求元はスマートメーターであり、識別子meterAE123を割り当てられたアプリケーションとしてサーバに登録されている。
３．リソースは、meterAE123のコンテナmeterContainer234の下に作成される。
４．作成すべきリソースタイプはcontentInstanceである（すなわち、報告された各指示値は異なるcontentInstanceに格納される）。
５．要求有効期限は１８００秒である。言い換えれば、meterAE123から受信した各作成要求は、１８００秒後に期限切れになる。
６．操作実行時間は６００秒である。言い換えれば、サーバは６００秒以内にmeterAE123からの作成要求を処理する必要がある。
７．応答タイプは、サーバがスマートメーターに直ちに肯定応答（acknowledgement：ＡＣＫ）を送信し、その後に応答が続く、ノンブロッキング同期のケースである。
８．サーバが別のＣＳＥに要求を転送する場合に備えて、受信した各作成要求のイベントカテゴリーは「ベストエフォート」に設定される。
９．トークン要求インジケータはtrueに設定される。これは、スマートメーターがトークン要求手順をサポートし、受信側が応答でトークン要求情報パラメータを提供した場合、発信元がトークン要求手順を試行できることを意味する。

以下は、上記の値を含むＸＭＬ形式のテンプレートの例である。
<?xml version="1.0" encoding="UTF-8"?>
<m2m:requestTemplate xmlns:m2m="http://www.onem2m.org/xml/protocols">
<op>1</op> <!-操作(op)はリソースの作成>
<to>//example.net/serverCSE/meterAE123/meterContainer234</to>
<!-To(to)は新しいリソースを作成すべき場所を示す>
<fr>meterAE123</fr>
<!-From（fr）は発信元ＩＤ（すなわちmeterAE123）を示す>
<ty>4</ty> <!-作成すべきリソースタイプ（ty）はcontentInstance>
<rqet>3600</rqet> <!-要求有効期限(rqet)は１８００秒>
<oet>600</oet> <!-操作実行時間(oet)は６００秒>
<rt>1</rt> <!-応答タイプ(rt)はnonBlockingSync>
<ec>3</ec> <!-イベントカテゴリー(ec)はベストエフォート>
<tqi>1</tqi> <!-トークン要求インジケータ(tqi)はtrue>
</m2m:requestTemplate>

さらに図８を参照すると、ステップ３で、サービス層は要求テンプレート作成応答を要求元に送信する。このメッセージには、作成されたすべての要求テンプレートの識別子（すなわち、要求テンプレート識別子（ＲＱＴＩＤ）のリスト）が含まれる。

図１０は、通常要求の送信時に要求元によって開始される要求テンプレート作成の方法を示している。ステップ１で、要求元がサービス層におけるリソースまたはサービスにアクセスするための通常要求を送信するとき、要求元はこのメッセージに新しいパラメータ、要求テンプレート作成インジケータ（ＲＱＴＣＩ）を含める。ＲＱＴＣＩは、この通常要求の処理に加えて要求テンプレートの追加作成をするようサービス層に指示するために使用される。ＲＱＴＣＩは基本的に、図８のステップ１に含まれるようなすべての情報を示すが、唯一の例外は、要求パラメータ値は既に通常要求に含まれているため、ＲＱＴＣＩがそれらを含む必要がないということである。基本的に、ＲＱＴＣＩは、要求に含まれ、ＲＱＴＣＩによって指示／暗示されるパラメータに基づいてテンプレートを構築する必要があることを示すものとして機能する。要求元が同様の後続の要求を送出する場合、同じパラメータを再送する代わりに、テンプレート識別子を使用できる。もちろん、後続の要求では異なっている必要があるパラメータは、要求元がオーバーライドすることができる。オーバーライドとは、テンプレートで使用されている値とは異なるいくつかの値を使用するように、要求元が応答側に指示できることを意味する。この要求には、作成される要求テンプレートに適用される既存のメッセージテンプレートポリシーのリストを示すMTPListが含まれ得ることに留意されたい。

ステップ２では、サービス層はステップ１から受信した要求を処理し、通常応答を生成する。その後、サービス層は、ＲＱＴＣＩが示す要求テンプレートを作成する。

ステップ３では、サービス層は、通常応答を要求元に送信する。図８のステップ３と同様に、この応答メッセージには、ステップ２で作成された要求テンプレートの識別子（すなわち、ＲＱＴＩＤ）が含まれる。

別の態様においては、サービス層は、要求元から通常要求を受信しながら要求テンプレートの作成を自発的に開始することができる。複数の通常要求が同様の要求パラメータを使用していることをサービス層が観察した場合、サービス層はそれらの要求パラメータを含む要求テンプレートを作成できる。その後、サービス層は、作成された要求テンプレートを要求元に通知して、要求元がそれを活用して、通常要求のサイズを縮小し、最適化された要求を生成できるようにする必要がある。サービス層がこのタスクを実行するには、２つのケースがある。ケース１では、サービス層が専用の要求テンプレート通知を要求元に送信する。ケース２では、サービス層は要求元からの次回の通常要求を待ち、作成された要求テンプレートの識別子を対応する応答メッセージにピギーバックする。要求元は、要求テンプレートを使用でき、使用する意思があることをサービス層に示すことができる。この意思表示を、登録中にサービス層に提供するか、あるいは他の要求メッセージに含ませて、要求元は、サービス層によって割り当てられた場合、将来の同様の要求にメッセージテンプレートを使用する意思があるということをサービス層に示すことができる。

図１１は、サービス層によって開始される要求テンプレート作成の方法を示し、作成された要求テンプレートの識別子は、別の通知メッセージを使用して要求元に返送される。

ステップ１から４では、要求元は２つの連続した通常要求をサービス層に送信し、サービス層は２つの連続した応答で応じる。図には明示的に示されていないが、要求元からサービス層への２つを超える通常要求があり得る。要求には、要求元が将来の同様の要求および応答の少なくとも一方に、メッセージテンプレートを使用する意思があるか、使用できるか、あるいはその両方であるという意思表示が含まれ得る。

ステップ５では、サービス層は、これらの通常要求を分析し、要求元が各々の通常要求で類似または同一の要求パラメータを使用することを合理的に見い出す。その後、１つ（または複数の）要求テンプレートを作成することを決定する。サービス層は、作成された要求テンプレートを１つまたは複数の既存のメッセージテンプレートポリシーに関連付けることもできる。例えば、同様の要求パラメータを使用する受信された連続要求（または非連続要求）の数が整数の閾値以上である場合、サービス層は要求テンプレートを作成することを決定する。その後、これらすべての要求で使用される要求パラメータが同じである場合、サービス層は、これらすべてのパラメータを含む１つの要求テンプレートを作成するだけでよい。これらの要求が類似の要求パラメータを使用しているが、全く同じではない場合、サービス層は複数の要求テンプレートを作成することもできる。例えば、これらの要求中で共通に使用される要求パラメータの各セットを使用して、要求テンプレートを作成できる（各要求中で共通に使用されない要求パラメータも、要求テンプレートの作成に使用できる）。

図１２は、サービス層が、図に示すように、いくつかの類似する要求パラメータを使用する３つの連続する通常要求を受信する例を示す。この特定のシナリオでは、サービス層は以下の要求テンプレートを作成できるが、さらにテンプレートを追加することもできる。
・セットＳ１２３に含まれる要求パラメータの要求テンプレートを作成する。
・セットＳ１２に含まれる要求パラメータの要求テンプレートを作成する。
・セットＳ１３に含まれる要求パラメータの要求テンプレートを作成する。
・セットＳ２３に含まれる要求パラメータの要求テンプレートを作成する。
・セットＳ１２―Ｓ１２３に含まれる要求パラメータの要求テンプレートを作成する。
・セットＳ１３―Ｓ１２３に含まれる要求パラメータの要求テンプレートを作成する。
・セットＳ２３―Ｓ１２３に含まれる要求パラメータの要求テンプレートを作成する。
・セットＳ１に含まれる要求パラメータの要求テンプレートを作成する。これは、要求＃１が繰り返される場合に有用である。
・セットＳ２に含まれる要求パラメータの要求テンプレートを作成する。これは、要求＃２が繰り返される場合に有用である。
・セットＳ３に含まれる要求パラメータの要求テンプレートを作成する。これは、要求＃３が繰り返される場合に有用である。

ステップ６では、サービス層は、ステップ５で決定されたように、それに応じて、要求テンプレートを作成する。

ステップ７では、サービス層は要求テンプレート通知を要求元に送信して、ステップ６で作成された要求テンプレートの識別子（すなわち、ＲＱＴＩＤ）を通知する。あるいは、サービス層は、このステップで作成された各要求テンプレートの表現を含むことで、要求元がＲＱＴＩＤに基づいて作成された要求テンプレートをリトリーブするために別途ステップを実行する必要がないようにすることができる。

ステップ８では、要求元は、ステップ７からのＲＱＴＩＤの受信に成功したかどうかを示すために、要求テンプレート通知応答をサービス層に返送する。

図１１では、代替案として、ステップ３とステップ４の間にステップ５とステップ６が発生し得ることに留意されたい。その後、サービス層はステップ４でＲＱＴＩＤをピギーバックすることができる。したがって、ステップ７とステップ８は不要となる。

図１３は、サービス層によって開始される要求テンプレート作成の方法を示し、作成された要求テンプレートの識別子は、通常応答にピギーバックされて要求元に返送される。ステップ１から６は、図１１のステップ１から６と同じである。

ステップ７では、要求元はサービス層に新しい通常要求を送信する。

ステップ８では、サービス層は新しい通常要求を受信する。サービス層はそれを処理し、通常応答を生成する。サービス層は、ステップ６で作成された要求テンプレート（すなわち、ＲＱＴＩＤ）の識別子をこの通常応答メッセージにピギーバックする。

別の態様においては、サービス層自身（または、管理アプリケーション）が、要求テンプレートを自発的に作成することができる。その後、要求元は、サービス層から適切な要求テンプレートを発見し、そのテンプレートを活用して最適化された要求を生成して、通常要求のサイズを縮小できる。

図１４は、サービス層により開始される自発的な要求テンプレート作成の方法を示す。

ステップ１では、サービス層（または、その管理アプリケーション）は、要求元からの通常要求メッセージを考慮することなく、要求元に提供できる自身の能力およびサービスのみに基づいて、いくつかの要求テンプレートを自発的に作成できる。このように、要求元はこれらの要求テンプレートを発見して（または、割り当てられて）、それらを使用してサービス層と相互作用する必要がある。言い換えれば、サービス層は、これらの要求テンプレートを作成することにより、これらの要求テンプレートで記述されているように要求パラメータを使用する要求メッセージのみを受け入れることを明示することができる。サービス層は要求テンプレートに対する制約をなくして、要求元が自身の要求メッセージの新しい値をサービス層に示すことにより、いくつかの要求パラメータの値を上書きできるようにしてもよい。サービス層は、これらの作成された要求テンプレートを要求元に割り当てることができることに留意されたい。これについては、後述する。サービス層は、作成された要求テンプレートを１つまたは複数の既存のメッセージテンプレートポリシーに関連付けることもできる。

ステップ２では、要求元は、テンプレート発見要求をサービス層に送信して、メッセージテンプレートフィルタ（MTFilter）に基づいて要求テンプレートを発見する。MTFilterは、例えば、要求元が使用できる要求テンプレート、特定のターゲットリソースに適用可能な要求テンプレート、特定の要求パラメータを含む要求テンプレート、特定の要求タイプ用の要求テンプレート、要求テンプレートが有するその他のプロパティなどの、様々な検索基準を示すことができる。

ステップ３では、サービス層は、MTFilterによって示された基準に従って、ローカルに格納された要求テンプレートを検索する。その後、MTFilterに適合する要求テンプレートのリスト（すなわち、MTList内のメッセージテンプレート識別子のリスト）を応答メッセージに含めることにより、テンプレート発見応答メッセージを要求元に送信する。図には示していないが、要求元はフォローアップ要求をサービス層に送信して、発見された要求テンプレートのコンテンツをリトリーブした後に、それを使用して、最適化された要求を生成できる。要求テンプレートをリトリーブする方法については、後述する。

さらに別の態様では、要求元は、通常要求（または最適化された要求）をサービス層に送信すると、応答テンプレートインジケータ（Response Template Indicator：ＲＳＴＩ）をピギーバックして、応答テンプレートに関連するいくつかのタスク（例えば、新しい応答テンプレートの作成し）を実行することをサービス層に要求する。ＲＳＴＩが新しい応答テンプレートの作成を指示している場合、サービス層は新しい応答テンプレートを生成し、応答テンプレート識別子（ＲＳＴＩＤ）をそれに割り当てて、それをローカルに格納する。その後、サービス層は通常応答（または、最適化された応答）を要求元に送信する。この応答メッセージには、応答テンプレート作成インジケータ（Response Template Creation Indicator：ＲＳＴＣＩ）とＲＳＴＩＤが含まれる。ＲＳＴＣＩには、サービスが作成したばかりの応答テンプレートが含まれる。その後、要求元はＲＳＴＣＩに従って同じ応答テンプレートを作成し、その識別子をＲＳＴＩＤとし、それをローカルに格納する。要求元が同じ応答テンプレートを作成する理由は、要求元が、将来、いかなる最適化された応答メッセージを受信した際も、元の応答メッセージを回復するために同じ応答テンプレートを使用する必要があるからである。

図１４は、応答テンプレート作成の手順を示す。ステップ１では、要求元が要求メッセージ（通常要求または最適化された要求）をサービス層に送信する。このメッセージには、ステップ３で応答テンプレートを作成するようサービス層に指示する新しいパラメータ、応答テンプレートインジケータ（ＲＳＴＩ）が含まれ得る。そのため、ＲＳＴＩには、応答テンプレートに含まれる応答パラメータとその値も含まれ得る。この要求には、作成される応答テンプレートに適用される既存のメッセージテンプレートポリシーのリストを示すMTPListが含まれ得る。

ステップ２では、サービス層は要求メッセージを処理して、通常応答メッセージを生成する。

ステップ３では、ステップ１にＲＳＴＩが含まれる場合、サービス層は応答テンプレートを作成する。サービス層は、要求元がステップ１で何らかのポリシーを示していても、作成された応答テンプレートを１つまたは複数の既存のメッセージテンプレートポリシーに関連付けることができる。応答テンプレートに含むべき応答パラメータは、ＲＳＴＩから取得するか、サービス層によって決定される。ｏｎｅＭ２Ｍサービス層を例にとると、サービス層は、将来の各応答で同じ値を持つ、以下の応答パラメータを使用することを決定することもできる。そのため、これらのパラメータを含むように応答テンプレートを作成することができる。応答テンプレートに含めることができるｏｎｅＭ２Ｍ応答パラメータには、コンテンツ、送信元、結果有効期限タイムスタンプ、イベントカテゴリーなどがある。

ステップ４では、サービス層は、要求元が自身の側でも同じ応答テンプレートを作成する必要があるかどうかを決定する。必要がある場合、ステップ５に応答テンプレート作成インジケータ（ＲＳＴＣＩ）と応答テンプレート識別子（ＲＳＴＩＤ）が含まれる。必要がない場合、要求元は、後で、いかなる応答テンプレートもサービス層から発見およびリトリーブでき、ステップ５にはＲＳＴＣＩもＲＳＴＩＤも含まれない。

ステップ５では、サービス層は、ステップ２で生成された応答を要求元に送信する。このメッセージには、ステップ４で生成されたＲＳＴＣＩおよびＲＳＴＩＤが含まれ得る。さらに、このステップでは、以前に生成されたいかなる応答テンプレートとその識別子もピギーバックすることができる。

ステップ６では、要求元はステップ５から受信した応答を処理する。ステップ５がＲＳＴＣＩおよびＲＳＴＩＤを含む場合、ＲＳＴＣＩを使用して応答テンプレートを作成し、それをローカルに格納する。作成された応答テンプレートの識別子は、ステップ５から、ＲＳＴＩＤに設定する必要がある。

別の態様においては、サービス層は、初めてそれ自身をサービス層に登録するときに、適切な要求テンプレートを要求元に割り当てるか、またはサービス層が専用のテンプレート割り当て要求を使用して、そのようにしてもよい。あるいは、要求元が、メッセージテンプレートフィルタ（すなわち、MTFilter）を含むテンプレート発見要求をサービス層に送出して、何らかの所望のメッセージテンプレートを調べるように指示することもできる。メッセージテンプレートを発見または割り当てられた後、メッセージテンプレートが将来更新または削除されたときに自動通知を受信するために、要求元はメッセージテンプレートへのサブスクリプションを作成することができる。

図１６は、メッセージテンプレートの割り当てと発見の方法を示し、起こり得る３つのケースを示す。ケース１では、要求元がサービス層に自身を登録するときに、サービス層は既存のメッセージテンプレートを要求元に割り当てる。ケース２では、サービス層は別個の専用要求メッセージを使用して、既存のメッセージテンプレートを要求元に割り当てる。ケース３では、要求元はサービス層から既存のメッセージテンプレートを発見する。これら３つのケースは任意の順序で実行でき、併用する必要はない。言い換えれば、１）ステップ１とステップ２は、ケース１のために、共に実行される必要があるが、他のステップには依存しない。２）ステップ３とステップ４は、ケース２のために、共に実行される必要があるが、他のステップには依存しない。３）ステップ５とステップ６は、共に行われる必要があるが、他のステップには依存しない。

ステップ１では、要求元は、サービス層登録（例えば、ｏｎｅＭ２ＭにおけるＡＥ登録またはＣＳＥ登録）の要求をサービス層に送信する。この登録要求では、要求元は以下の情報を示すことができ、それに基づいて、サービス層は、より適切なメッセージテンプレートを選択して、要求元に割り当てることができる。さらに、サービス層は、それらの情報を活用して、要求元のための新しいメッセージテンプレートを作成することもできる。
・要求元が要求テンプレートか、応答テンプレートか、あるいはその両方を使用できるかどうか。
・要求元がいくつかのメッセージテンプレートを供給されることを希望するかどうか。
・要求元が頻繁に送信する要求のタイプは何か（すなわち、作成、読み出し、更新、削除（Create, Read, Update, Delete：ＣＲＵＤ））。
・要求元がよく使用する要求や応答のパラメータは何か。

ステップ２では、サービス層はステップ１からの要求を処理し、サービス層登録応答を要求元に送信する。この応答には、サービス層が要求元に割り当てるメッセージテンプレート識別子のリストを示す新しいパラメータMTListが含まれている。

ステップ３では、サービス層は、テンプレート割り当て要求を要求元に送信する。この要求には、サービス層が要求元に割り当てるメッセージテンプレート識別子のリストを示す新しいパラメータMTListが含まれている。

ステップ４では、要求元は応答をサービス層に送信する。

ステップ５は図１４のステップ２と同じである。

ステップ６は図１４のステップ３と同じである。

図１７は、サービス層登録手順中にメッセージテンプレートを作成／割り当てるための簡便で、より軽量な形式の手法を示す。ステップ１では、要求元はサービス層登録要求を送信することにより、サービス層に登録する。この要求において、要求元は値を含むいくつかの既定要求パラメータを示すか表現する。要求元はそれらを後続の要求で繰り返し使用することになる。

ステップ２では、サービス層は、これらの既定パラメータを記録するために、要求元用の既定要求テンプレートを作成する。既定テンプレートとは、要求元からの将来の要求メッセージは、それがメッセージテンプレート識別子を明示的に含まない場合、この既定テンプレートに基づいてサービス層によって処理されることを意味する。既定テンプレートは、同じ要求元だけが使用する。

ステップ３では、サービス層はサービス層登録応答を要求元に送信する。サービス層は、サービス層登録が成功したかどうかを示すことに加えて、ステップ２で既定テンプレートが作成されたかどうかも示す。

ステップ４では、サービス層の登録が成功し、既定テンプレートの作成が成功した後、要求元は最適化された要求をサービス層に送信する。今後、この最適化された要求にメッセージテンプレート識別子を含める必要はない。また、この最適化された要求には、ステップ１で含まれていた既定パラメータは含まれていない。

ステップ５では、サービス層は、ステップ２で作成された要求元の既定テンプレートを使用して、受信した最適化された要求を処理する。

ステップ６では、サービス層は、ステップ４から受信した最適化された要求に対する応答として、要求元にメッセージを送信する。

さらに別の態様によれば、要求元は、メッセージテンプレート識別子（ＭＴＩＤ）を使用して、メッセージテンプレートが格納されているサービス層から特定のメッセージテンプレートをリトリーブすることができる。要求元は、上記手順の１つからＭＴＩＤを取得している可能性がある。

図１８は、メッセージテンプレートをリトリーブする方法を示す。

ステップ１では、要求元はテンプレートリトリーブ要求をサービス層に送信する。このメッセージには、サービス層からリトリーブすべきメッセージテンプレートの識別子（すなわち、ＭＴＩＤ）が含まれる。

ステップ２では、サービス層は、ステップ１で、ＭＴＩＤが示すメッセージテンプレートを見つけ、そのメッセージテンプレートの表現を含む応答を生成する。

ステップ３では、サービス層は応答を要求元に返送する。

別の態様によれば、要求テンプレートを発見するか、要求テンプレートを割り当てられるか、もしくは要求テンプレートを自身で作成した後、要求元はそれを使用して、多くの要求パラメータを含む通常要求と比べてメッセージサイズのより小さい、最適化された要求を生成することができる。サービス層は、最適化された要求を受信すると、最適化された要求から要求テンプレート識別子（ＲＱＴＩＤ）を抽出し、対応するテンプレートを使用して最適化された要求を処理する。ＲＱＴＩＤが示す要求テンプレートがネットワーク上の別の位置（例えば、データベース、テンプレートのリポジトリ、別のサービス層など）にある場合、サービス層は、最適化された要求を適切に処理するために、最初に別のサービス層から要求テンプレートをフェッチする必要がある。

図１９は、要求テンプレートを活用する方法を示す。ステップ１では、要求元は最適化された要求をサービス層ＳＬ１に送信する。このメッセージには、要求元が最適化された要求の生成に使用した要求テンプレートの識別子を示すＲＱＴＩＤが含まれている。通常要求から最適化された要求を生成するために、要求元は、要求テンプレートに含まれる要求パラメータを通常要求から基本的に削除し、ＲＱＴＩＤを通常要求に挿入する。

例えば、上記のスマートメーターの例を続けると、図２のスマートメーターからサーバへの最適化された要求メッセージは、ｏｎｅＭ２Ｍがサービス層として使用されると仮定すると、以下の形をとることができる。ただし、rqtid123は上記のスマートメーターテンプレート例を表し、サーバに格納されている。
<?xml version="1.0" encoding="UTF-8"?>
<m2m:optimizedRequest xmlns:m2m="http://www.onem2m.org/xml/protocols">
<rqi>0002bf63</rqi>
<rqtid>rqtid123</rqtid>
<pc>
<m2m:cin>
<cnf>application/xml:1</cnf>
<con>PHRpbWU+MTc4ODkzMDk8L3RpbWU+PHRlbXA+MjA8L3RlbXA+DQo=</con>
</m2m:cin>
</pc>
</m2m:optimizedRequest>

この例では、pcはデータ型m2m:primitiveContentのコンテンツパラメータであり、リソースの属性は発信元によって提供される。cinは、データ型m2m:contentInstanceの<contentInstance>リソースのルート要素である。これには、要求の発信元によって供給される必須属性（および、この例には示されていないオプショナル属性）が含まれる。この例では、コンテンツパラメータには、base64エンコードを指定するcontentInfo（cnf）およびコンテンツ（con）自体の、２つの属性で構成される<contentInstance>リソースのインスタンスが含まれる。

要求テンプレートが利用可能でないか、採用されていないと仮定した場合、スマートメーターは、以下の通常要求メッセージをサーバに送信する必要があるであろう。それに比べて、最適化された要求は、ＲＱＴＩＤを含む必要があるものの、９つの要求パラメータを削除することによってメッセージサイズを削減する。
<?xml version="1.0" encoding="UTF-8"?>
<m2m:regularRequest xmlns:m2m="http://www.onem2m.org/xml/protocols">
<rqi>0002bf63</rqi>
<op>1</op>
<to>//example.net/serverCSE/meterAE123/meterContainer234</to>
<fr>meterAE123</fr>
<ty>4</ty>
<rqet>3600</rqet>
<oet>600</oet>
<rt>1</rt>
<ec>3</ec>
<tqi>1</tqi>
<pc>
<m2m:cin>
<cnf>application/xml:1</cnf>
<con>PHRpbWU+MTc4ODkzMDk8L3RpbWU+PHRlbXA+MjA8L3RlbXA+DQo=</con>
</m2m:cin>
</pc>
</m2m:regularRequest>

さらに図１９を参照すると、ステップ２では、サービス層ＳＬ１は、ＲＱＴＩＤに基づいて、対応する要求テンプレートを見つける。要求テンプレートが別のサービス層ＳＬ２に格納されている場合、サービス層ＳＬ１はステップ３と４を使用して要求テンプレートをリトリーブする。

ステップ３では、サービス層ＳＬ１は、ＲＱＴＩＤが示す要求テンプレートをリトリーブするために、テンプレートリトリーブ要求をサービス層ＳＬ２に送信する。

ステップ４では、サービス層ＳＬ２は、テンプレートリトリーブ応答をサービス層ＳＬ１に送信する。この応答には、取得した要求テンプレートの表現（すなわち、要求パラメータ）が含まれる。

ステップ５では、サービス層ＳＬ１は、リトリーブされた要求テンプレートからの情報を使用して、最適化された要求を通常要求に変換する（すなわち、要求テンプレートに含まれる要求パラメータを最適化された要求にコピーし、最適化された要求からＲＱＴＩＤを削除する）。その後、サービス層ＳＬ１は、通常要求を処理して、通常応答を生成する。

ステップ６では、サービス層ＳＬ１は、要求元に通常応答を返送する。

図２０は、要求および応答テンプレートを活用する方法を示す。ステップ１では、要求元は最適化された要求をサービス層ＳＬ１に送信する。このメッセージには、要求元が最適化された要求の生成に使用した要求テンプレートの識別子を示すＲＱＴＩＤが含まれている。通常要求から最適化された要求を生成するために、要求元は、要求テンプレートに含まれていた要求パラメータを通常要求から基本的に削除し、ＲＱＴＩＤを通常要求に挿入する。さらに、最適化された要求には、応答テンプレートインジケータ（ＲＳＴＩ）も含まれる。ＲＳＴＩは以下の値を持つことができ、それらに基づいて、サービス層ＳＬ１は、ステップ７で応答テンプレートの作成または活用、あるいはその両方をするかどうかを決定する。
・ＲＳＴＩ＝「通常応答」：これによって、ステップ７で、サービス層ＳＬ１に、応答テンプレートの作成や活用をせず、要求元に通常応答を送信するよう指示する。
・ＲＳＴＩ＝「新しい応答テンプレートを作成する」：これによって、ステップ７で、サービス層ＳＬ１に、応答テンプレートを生成するよう指示する。この場合、ＲＳＴＩは、値を含むどの応答パラメータを応答テンプレートに含めるべきかも示す。
・ＲＳＴＩ＝「応答テンプレートを使用して最適化された応答を生成する」：これによって、ステップ７で、サービス層ＳＬ１に、応答テンプレートを活用して最適化された応答を生成するよう指示する。この場合、ＲＳＴＩは、最適化された応答の生成に使用すべき応答テンプレートの識別子（すなわち、ＲＳＴＩＤ）も示す。

ステップ２では、サービス層ＳＬ１は、ＲＱＴＩＤに基づいて、対応する要求テンプレートを見つける。要求テンプレートが別のサービス層ＳＬ２に格納されている場合、サービス層ＳＬ１はステップ３および４を使用して要求テンプレートをリトリーブする。

ステップ３では、サービス層ＳＬ１は、ＲＱＴＩＤによって示されたように要求テンプレートを検索するために、テンプレートリトリーブ要求をサービス層ＳＬ２に送信する。

ステップ４では、サービス層ＳＬ２は、テンプレートリトリーブ応答をサービス層ＳＬ１に送信する。この応答には、リトリーブされた要求テンプレートの表現（すなわち、要求パラメータ）が含まれる。

ステップ５では、サービス層ＳＬ１は、リトリーブされた要求テンプレートを使用して、最適化された要求を通常要求に変換する（すなわち、要求テンプレートに含まれる要求パラメータを最適化された要求にコピーし、最適化された要求からＲＱＴＩＤを削除する）。

ステップ６では、サービス層ＳＬ１は、通常要求を処理して、通常応答を生成する。

ステップ７では、サービス層ＳＬ１は、ステップ１に含まれるＲＳＴＩに従って、以下のアクションを実行する。
・ＲＳＴＩ＝「通常応答」であれば、何もせずに、ステップ８．１で要求元に通常応答を送信する。
・ＲＳＴＩ＝「新しい応答テンプレートを作成する」であれば、ＲＳＴＩに含まれる値を含むすべての応答パラメータを応答テンプレートにコピーすることによって応答テンプレートを作成し、作成された応答テンプレートに識別子（すなわち、ＲＳＴＩＤ）を割り当てる。その後、ステップ８．２で、パラメータＲＳＴＣＩおよびＲＳＴＩＤを介して、生成された応答テンプレートを要求元に送信する。
・ＲＳＴＩ＝「応答テンプレートを使用して最適化された応答を生成する」であれば、ステップ１のＲＳＴＩが示す応答テンプレートを活用して、最適化された応答を生成する。その後、ステップ８．３で、最適化された応答を要求元に送信する。

ステップ８では、サービス層は、以下の３つのステップのうちの１つを使用して、要求元に応答を送信する：
・ステップ８．１：サービス層ＳＬ１は通常応答を要求元に送信する。
・ステップ８．２：サービス層ＳＬ２は通常または最適化された応答を要求元に送信する。ただし、通常応答には、２つの新しいパラメータＲＳＴＣＩおよびＲＳＴＩＤが含まれている。ＲＳＴＣＩにはステップ７で作成された応答テンプレートが含まれ、ＲＳＴＩＤはその識別子である。最適化された応答を送信する場合、最適化された応答は、ステップ７で作成されてＲＳＴＣＩに含まれている新しい応答テンプレートに基づくものである必要がある。
・ステップ８．３：サービス層ＳＬ１は、ステップ７で生成された最適化された応答を要求元に送信する。このメッセージには、ステップ７で最適化された応答を生成するために使用された応答テンプレートの識別子が含まれる。

ステップ９では、要求元は、ステップ８．１、ステップ８．２、またはステップ８．３から受信した応答メッセージを処理する。

応答がステップ８．１からのもの（すなわち、新しいパラメータを持たない通常応答）である場合、要求元はそれを単に通常応答として処理する。

応答がステップ８．２からのもの（すなわち、ＲＳＴＣＩおよびＲＳＴＩＤを含む通常応答）である場合、要求元は、ＲＳＴＣＩに従って、同じ応答テンプレートをローカルに作成／格納し、その識別子をＲＳＴＩＤに設定して、サービス層ＳＬ１と要求元に格納された同じ応答テンプレートが同じ識別子を持つようにする。

応答がステップ８．３からのもの（すなわち、最適化された応答）である場合、要求元は、ＲＳＴＩＤに従って対応する応答テンプレートを見つける。その後、要求元は応答テンプレートを使用して、最適化された応答を通常応答に変換する（すなわち、すべての応答パラメータとその値を応答テンプレートから最適化された応答にコピーする）。

さらに別の態様においては、要求元は、メッセージテンプレート識別子（ＭＴＩＤ）を使用して、サービス層に格納された特定のメッセージテンプレートを更新することができる。２つのシナリオがあり得る。ケース１では、要求元は専用のテンプレート更新要求をサービス層に送信する。ケース２では、要求元がサービス層への任意の種類の通常要求を実行する際、同時に、ＭＴＩＤおよびメッセージテンプレート更新インジケータ（ＭＴＵＩ）をサービス層に送信する。その結果、サービス層は、まず、要求元からの通常要求を処理し、その後、ＭＴＩＤとＭＴＵＩの指定に従って、対応するメッセージテンプレートを更新する。更新されたメッセージテンプレートが他の要求元によって使用およびサブスクライブの少なくとも一方がされている場合、サービス層はそれらの要求元に通知を送信して更新を通知する必要がある。さらに、サービス層は、既存のテンプレートを参照する要求元から着信する要求を監視することもできる。この監視に基づいて、ＳＬは、既存のテンプレートパラメータ値の更新が必要なケース（例えば、要求元が既存のテンプレートの要求パラメータを上書きし続けるケース）および新しい共通パラメータをテンプレートに追加できるケース（例えば、要求元が既存のテンプレートに含まれていない新しいパラメータを使用し続けるケース）の少なくとも一方を検出することができ、サービス層は、既存のテンプレートの既存パラメータ値の更新と、テンプレートへの新しいパラメータの追加の、少なくとも一方を実行することで、既存のテンプレートを自動的に更新できる。

図２１は、専用メッセージを使用してメッセージテンプレートを更新する方法を示す。ステップ１では、要求元はテンプレート更新要求をサービス層に送信する。このメッセージには、メッセージテンプレートの識別子（すなわち、ＭＴＩＤ）と、メッセージテンプレートの更新すべきパラメータ／プロパティ（例えば、メッセージテンプレートの、許可されている要求元やターゲットリソースや子要求テンプレートなど）が含まれている。

ステップ２では、それに応じて、サービス層は、ステップ１に含まれる他の情報に従って、ＭＴＩＤが示すメッセージテンプレートを更新する。更新されたメッセージテンプレートが他の要求元によって使用およびサブスクライブの少なくとも一方がされている場合、サービス層はそれらの要求元に通知を送信して更新を通知する必要がある。

ステップ３では、サービス層は、ステップ１の処理に成功したかどうかを示すために、テンプレート更新応答を要求元に送信する。

図２２は、要求元が要求メッセージをサービス層に送信する際に、同時にメッセージテンプレートを更新する方法を示す。ステップ１では、要求元は要求メッセージ（通常のメッセージまたは最適化されたメッセージ）をサービス層に送信する。このメッセージには以下の情報が含まれる。
・ＭＴＩＤ：更新すべき既存のメッセージテンプレートの識別子。
・ＭＴＵＩ：メッセージテンプレート更新インジケータ。このパラメータは、サービス層に次のことを通知する。１）ＭＴＩＤが示すメッセージ識別子を更新する必要があるということ。２）更新すべきメッセージテンプレートのパラメータおよびプロパティの少なくとも一方。あるいは、このパラメータは、この要求メッセージに含まれるいくつかの要求パラメータを示すことができ、サービス層はそれらを使用して、ＭＴＩＤが示すメッセージテンプレートを更新する必要がある。

ステップ２では、サービス層は要求メッセージを処理して、通常応答（または最適化された応答）を生成する。その後、サービス層は、ステップ１のＭＴＵＩに従って、ＭＴＩＤが示すメッセージテンプレートを更新する。更新されたメッセージテンプレートが他の要求元によって使用およびサブスクライブの少なくとも一方がされている場合、サービス層はそれらの要求元に通知を送信して更新を通知する必要がある。

ステップ３では、サービス層は、ステップ１の処理に成功したかどうかを示すために、要求元に応答を送信する。

別の態様においては、要求元は、メッセージテンプレート識別子（ＭＴＩＤ）を使用して、サービス層に格納されている特定のメッセージテンプレートを削除することができる。２つのシナリオがある。ケース１では、要求元は専用のテンプレート削除要求をサービス層に送信する。ケース２では、要求元がサービス層への任意の種類の通常要求を実行する際、同時に、ＭＴＩＤおよびメッセージテンプレート削除インジケータ（ＭＴＤＩ）をサービス層に送信する。その結果、サービス層は、まず、要求元からの通常要求を処理し、その後、ＭＴＩＤとＭＴＤＩの指定に従って、対応するメッセージテンプレートを削除する。削除されたメッセージテンプレートが他の要求元によって使用およびサブスクライブの少なくとも一方がされている場合、サービス層はそれらの要求元に通知を送信して、メッセージテンプレートの削除を通知する。ここでの削除操作は、要求元が、削除されたメッセージテンプレートを今後使用するつもりがないことを意味するとも考えられる。さらに、サービス層は、既存のテンプレートがどのように使用されたかを監視できる。テンプレートがどの要求元によってもしばらく使用されていないか、適切ではなくなった場合、サービス層はこのテンプレートを自動的に削除できる。

図２３は、専用メッセージを使用してメッセージテンプレートを削除する方法を示す。ステップ１では、要求元はテンプレート削除要求をサービス層に送信する。このメッセージには、削除すべきメッセージテンプレートの識別子（すなわち、ＭＴＩＤ）が含まれている。

ステップ２では、それに応じて、サービス層は、ＭＴＩＤが示すメッセージテンプレートを削除する。削除されたメッセージテンプレートが他の要求元によって使用およびサブスクライブの少なくとも一方がされている場合、サービス層はそれらの要求元に通知を送信して、メッセージテンプレートの削除を通知する。

ステップ３では、サービス層は、ステップ１の処理に成功したかどうかを示すために、テンプレート削除応答を要求元に送信する。

図２４は、要求元が要求メッセージをサービス層に送信する際に、同時にメッセージテンプレートを削除する方法を示す。ステップ１では、要求元は要求メッセージ（通常のメッセージまたは最適化されたメッセージ）をサービス層に送信する。このメッセージには以下の情報が含まれる。
・ＭＴＩＤ：削除すべき既存のメッセージテンプレートの識別子。
・ＭＴＤＩ：メッセージテンプレート削除インジケータ。このパラメータは、サービス層に、ＭＴＩＤが示すメッセージテンプレートを削除するよう通知する。

ステップ２では、サービス層は要求メッセージを処理して、通常応答（または最適化された応答）を生成する。その後、サービス層は、ＭＴＩＤが示すメッセージテンプレートを削除する。削除されたメッセージテンプレートが他の要求元によって使用およびサブスクライブの少なくとも一方がされている場合、サービス層はそれらの要求元に通知を送信して、メッセージテンプレートの削除を通知する。

ステップ３では、サービス層は、ステップ１の処理に成功したかどうかを示すために、要求元に応答を送信する。

別の態様においては、ＲＱＴＩＤが、一般に、要求パラメータの合計サイズよりはるかに短いというという事実に鑑みると、要求元は、１つの最適化された要求に複数のＲＱＴＩＤを含めることができる。そして、サービス層は、これらの複数のＲＱＴＩＤを結合したもの（すなわち、これらのＲＱＴＩＤに含まれるすべての要求パラメータの組み合わせ）を使用して、最適化された要求を処理し、それに応じて要求元に対する１つの応答メッセージを生成する。この機能により、複数の要求テンプレートを共同テンプレートとして共に使用できるようになり、要求テンプレートの管理と再利用にさらなるきめ細かさと柔軟性を持たせることができる。

図２５は、１つの要求メッセージで複数の要求テンプレートを活用する方法を示す。以下を想定する。１）要求元は２つ以上の要求テンプレートを発見した（図では３つのテンプレートを発見した）。２）これらの各テンプレートはいかなる同一のパラメータも含まないが、要求元が使用する要求パラメータのサブセットを含んでいる。３）各テンプレートは、共に、要求元が使用する必要がある要求パラメータをすべて含んでいる。

ステップ１では、要求元はこれら３つの要求テンプレートを使用して、これらのテンプレートにいかなる要求パラメータも含まず、これら３つのテンプレートの識別子（すなわち、ＲＱＴＩＤ１、ＲＱＴＩＤ２、およびＲＱＴＩＤ３）だけを含む、最適化された要求を生成する。

ステップ２では、サービス層は、ＲＱＴＩＤ１、ＲＱＴＩＤ２、およびＲＱＴＩＤ３で示されるこれらの３つの要求テンプレートに含まれるすべての要求パラメータを使用して、最適化された要求を処理する。その後、サービス層は応答メッセージを生成する。要求テンプレートに含まれる要求パラメータは、順序立っている必要はないことに留意されたい。

ステップ３では、サービス層は、ステップ１の最適化された要求の処理に成功したかどうかを示すために、要求元に応答メッセージを送信する。

さらに別の態様によれば、マルチホップサービス層通信の下でメッセージテンプレートを使用することができる。要求元が中間のトランジットサービス層を介して宛先サービス層に要求メッセージを送信すると仮定する。２つのサービス層ホップ（すなわち、要求元とトランジットサービス層間の第１のホップと、トランジットサービス層と宛先サービス層間の第２のホップ）が生じる。例えば、要求元はトランジットサービス層にサービス層グループ操作を送り、トランジットサービス層は１つまたは複数の宛先サービス層（すなわち、グループメンバー）に操作を展開する。したがって、要求テンプレートは次の４つのケースにおいて活用できる。

ケース１では、要求元は要求テンプレートを使用して、最適化された要求を生成してトランジットサービス層に送信し、トランジットサービス層は最適化された要求を、単に宛先サービス層に転送し、宛先サービス層では、最適化された要求は、対応する要求テンプレートに基づいて処理される。この場合、トランジットサービス層は、テンプレート関連機能を持たない。

ケース２では、要求元は依然として要求テンプレートを使用して、最適化された要求を生成してトランジットサービス層に送信するが、一方、トランジットサービス層はその要求テンプレートを活用して、要求元から受信した最適化された要求を処理し、通常要求を宛先サービス層に転送する。この場合、宛先サービス層は、テンプレート関連機能を持たない。

ケース３では、要求元は依然として要求テンプレートを使用して、最適化された要求を生成してトランジットサービス層に送信し、トランジットサービス層はその要求テンプレートを使用して最適化された要求を処理する。さらに、トランジットサービス層は別の要求テンプレートを使用して新しい最適化された要求を生成し、新しい最適化された要求を宛先サービス層に転送する。宛先サービス層では、新しい最適化された要求が、対応する要求テンプレートを使用して処理される。この場合、トランジットサービス層と宛先サービス層は両方ともテンプレート関連機能を持つが、２つのサービス層ホップでは、異なる要求テンプレートが使用される。

ケース４では、要求元は通常要求をトランジットサービス層に送信し、トランジットサービス層は要求テンプレートを使用して最適化された要求を生成し、それを宛先サービス層に送信する。この場合、要求元はテンプレートに関連する機能をサポートしない。

上記のマルチホップシナリオをより効率的に可能にするために、ＲＱＴＩＤを、解決可能なネットワークアドレスまたは識別子（例えば、統一資源識別子（Uniform Resource Identifier：ＵＲＩ））のフォーマットにすることができることに留意されたい。ＲＱＴＩＤをこのフォーマットにすると、宛先サービス層のみならず、中間、すなわち、トランジットサービス層は、当初は要求テンプレートのローカルコピーを有していない場合でも、ネットワーク上の別の位置から要求テンプレートをフェッチしてローカルに格納し、最適化された要求を処理できるようになる。

図２６は、トランジットサービス層がテンプレート関連機能をサポートしない場合に、マルチホップサービス層通信のための要求テンプレートを使用する方法を示す。ステップ１で、要求元は最適化された要求をトランジットサービス層に送信する。このメッセージには、要求元が最適化された要求の生成に使用した要求テンプレートの識別子を示すＲＱＴＩＤが含まれている。要求元は、このメッセージに新しいインジケータを含めることによって、ステップ２で要求を別のサービス層に自動的に転送するよう、サービス層に指示することもできる。

ステップ２では、トランジットサービス層は、最適化された要求を宛先サービス層に単に転送する。

ステップ３では、トランジットサービス層は、最適化された要求を宛先サービス層に送信する。

ステップ４では、宛先サービス層は、最適化された要求を受信し、ＲＱＴＩＤを使用して、対応する要求テンプレートを見つける。その後、宛先サービス層は、最適化された要求を要求テンプレートに基づいて処理し、通常応答を生成する。

ステップ５では、宛先サービス層は、通常応答を送信サービス層に返送する。

ステップ６では、トランジットサービス層は、通常応答を受信し、ステップ７では、トランジットサービス層は、通常応答を要求元に転送する。

図２７は、宛先サービス層がテンプレート関連機能をサポートしない場合に、マルチホップサービス層通信において要求テンプレートを使用する方法を示す。ステップ１で、要求元は最適化された要求をトランジットサービス層に送信する。このメッセージには、要求元が最適化された要求の生成に使用した要求テンプレートの識別子を示すＲＱＴＩＤが含まれている。要求元は、このメッセージに新しいインジケータを含めることによって、ステップ２でこの最適化された要求を別のサービス層に転送する前に処理するよう、サービス層に指示することもできる。

ステップ２では、トランジットサービス層は、ＲＱＴＩＤに基づいて、対応する要求テンプレートを見つける。その後、トランジットサービス層は、要求テンプレートを使用して、最適化された要求を通常要求に変換する（すなわち、要求テンプレートに含まれる要求パラメータを最適化された要求にコピーし、最適化された要求からＲＱＴＩＤを削除する）。

ステップ３では、トランジットサービス層は通常要求を宛先サービス層に送信する。

ステップ４では、宛先サービス層は通常要求を処理し、通常応答をトランジットサービス層に返送する。

ステップ５では、トランジットサービス層は通常応答を受信し、ステップ６では、トランジットサービス層は通常応答を要求元に転送する。

図２８は、トランジットサービス層と宛先サービス層が両方ともテンプレート関連機能をサポートする場合に、マルチホップサービス層通信において要求テンプレートを使用する方法を示す。ステップ１では、要求元は最適化された要求をトランジットサービス層に送信する。このメッセージには、要求元が最適化された要求を生成するために使用した要求テンプレートの識別子を示すＲＱＴＩＤ１が含まれている。要求元は、このメッセージに新しいインジケータを含めることによって、ステップ２でこの最適化された要求を別のサービス層に転送する前に処理するよう、サービス層に指示することもできる。

ステップ２では、トランジットサービス層は、ＲＱＴＩＤ１に基づいて、対応する要求テンプレートを見つける。その後、トランジットサービス層は、要求テンプレートを使用して、最適化された要求を通常要求に変換する（すなわち、要求テンプレートに含まれる要求パラメータを最適化された要求にコピーし、最適化された要求からＲＱＴＩＤ１を削除する）。

ステップ３では、トランジットサービス層は、ＲＱＴＩＤ２が示す別の要求テンプレートを使用して、ステップ２の通常要求を最適化された要求に変換する（すなわち、ＲＱＴＩＤ２が示す要求テンプレートに含まれる要求パラメータを通常要求から削除し、ＲＱＴＩＤ２を通常要求に挿入する）。

ステップ４では、トランジットサービス層は最適化された要求を宛先サービス層に送信する。

ステップ５では、宛先サービス層は、最適化された要求を受信し、ＲＱＴＩＤ２を使用して、対応する要求テンプレートを見つける。その後、宛先サービス層は、最適化された要求を要求テンプレートに基づいて処理し、通常応答を生成する。

ステップ６では、宛先サービス層は、トランジットサービス層に通常応答を送信する。

ステップ７では、トランジットサービス層は通常応答を受信し、ステップ８では、トランジットサービス層は通常応答を要求元に転送する。

図２９は、要求元がテンプレート関連機能をサポートしない場合に、マルチホップサービス層通信において要求テンプレートを使用する方法を示す。ステップ１では、要求元は通常要求をトランジットサービス層に送信する。要求元は、このメッセージに新しいインジケータを含めることによって、ステップ２でこの最適化された要求を別のサービス層に転送する前に処理するよう、サービス層に指示することもできる。

ステップ２では、トランジットサービス層は、ＲＱＴＩＤが示す要求テンプレートを使用して、通常要求を最適化された要求に変換する（すなわち、ＲＱＴＩＤが示す要求テンプレートに含まれる要求パラメータを通常要求から削除し、ＲＱＴＩＤを通常要求に挿入する）。

ステップ３では、トランジットサービス層は最適化された要求を宛先サービス層に送信する。

ステップ４では、宛先サービス層は、最適化された要求を受信し、ＲＱＴＩＤを使用して、対応する要求テンプレートを見つける。その後、宛先サービス層は、最適化された要求を要求テンプレートに基づいて処理し、通常応答を生成する。

ステップ５では、宛先サービス層は、トランジットサービス層に通常応答を送信する。

ステップ６では、トランジットサービス層は通常応答を受信し、ステップ７では、トランジットサービス層は通常応答を要求元に転送する。

別の態様においては、要求元またはサービス層は、１つまたは複数のメッセージテンプレートに対する特定の適用可能性ポリシー（メッセージテンプレートポリシーと呼ばれる）を指定することができる。メッセージテンプレートポリシーは、複数のテンプレートに適用できる。また、テンプレートの適用可能性は、複数のメッセージテンプレートポリシーによって制約または定義され得る。サービス層は、メッセージテンプレートポリシーを使用して、要求元にテンプレートを適用するかどうか、あるいはいつ適用するかを決定できる。メッセージテンプレートポリシーは、テンプレートの一部として、またはテンプレート外の別の情報オブジェクトまたはリソースとして定義することもできる。後者の場合、テンプレートと、対応するメッセージテンプレートポリシーとの間の関連性は、サービス層または要求元によって確立される。したがって、サービス層は、要求元に対して定められたメッセージテンプレートポリシーに従って、適切なテンプレートを自動的に見つけたり特定したりすることができるため、要求元は、テンプレート識別子を明示的に示すことなく、最適化された要求を生成することもできる。例えば、要求元は、指定されたテンプレートをすべての要求に適用するようにサービス層に指示するメッセージテンプレートポリシーを、サービス層に対して指定することができる。

図３０は、メッセージテンプレートポリシー作成する方法を示す。ステップ１では、要求元は、サービス層にメッセージテンプレートポリシーを作成するよう指示するメッセージテンプレートポリシー作成要求をサービスに送信する。メッセージは以下の情報を含み得る。
（ａ）policyType：この作成すべきポリシーはメッセージテンプレート用であることを示す。
（ｂ）policyElement：ポリシーが何を定義、許可、制限などするかを記述する。ポリシーは、ユニオンおよびインターセクション操作の少なくとも一方において、共にポリシー全体を定義する複数のpolicyElementで構成され得る。policyElementは、以下の条件に基づいているか、それらを記述している。
・サービス層によってローカルにホストされるリソースをターゲットとする要求はメッセージテンプレートを使用できる。
・リモートサービス層上でホストされているリソースをターゲットとする要求はメッセージテンプレートを使用できる。
・特定のタイプのリソースをターゲットとする要求はメッセージテンプレートを使用できる。
・サービス層への登録者である要求元からの要求はメッセージテンプレートを使用できる。
・特定の時間枠内に送出される要求はメッセージテンプレートを使用できる。
・特定の場所から送出される要求はメッセージテンプレートを使用できる。
・特定の場所にあるデバイスをターゲットとする要求はメッセージテンプレートを使用できる。
・特定の閾値を超えるサイズの要求はメッセージテンプレートを使用できる。
・特定の閾値を超えるレートで送出される要求はメッセージテンプレートを使用できる。
（ｃ）MTList：これは、作成ポリシーが適用されるメッセージテンプレート識別子のリストである。このパラメータはオプションである。このパラメータがステップ１に含まれていない場合、作成ポリシーを適用できるメッセージテンプレートは保留中である。図３１の手順を使用して、１つまたは複数のメッセージテンプレートを作成ポリシーに関連付けることができる。

ステップ２では、サービス層はステップ１に含まれる情報に従って、対応するメッセージテンプレートポリシーを作成する。あるいは、要求元からの要求がなければ、サービス層自身がメッセージテンプレートポリシーを自発的に作成し、それを既存のメッセージテンプレートに関連付けることもできる。ステップ１にMTListが含まれている場合、サービス層は、MTListに含まれるメッセージテンプレートを、例えば、作成したばかりのメッセージテンプレートポリシーに関連付けることにより、更新する必要がある。

ステップ３では、サービス層は、メッセージテンプレートポリシー作成応答を要求元に送信して、メッセージテンプレートの作成およびMTList内の指定されたメッセージテンプレートとの関連付けの少なくとも一方が成功したかどうかを示す。MTListがステップ１に含まれていない場合、要求元（またはサービス層）は、メッセージテンプレートの作成開始時に、既存のメッセージテンプレートポリシーを示し、作成すべきメッセージテンプレートに関連付けることができることに留意されたい。

図３１は、メッセージテンプレートをメッセージテンプレートポリシーに関連付けたり、逆に、メッセージテンプレートポリシーをメッセージテンプレートに関連付けたりする方法を示す。ステップ１では、要求元はメッセージテンプレート関連付け要求をサービス層に送信する。このメッセージには、以下の２つのパラメータを含める必要がある。
・MTPList：MTListに含まれる各メッセージテンプレートに共に適用されるメッセージテンプレートポリシー識別子のリスト。
・MTList：メッセージテンプレートのリスト。各テンプレートの適用可能性は、MTPListに含まれるすべてのポリシーによって記述される。

ステップ２では、サービス層は、MTPList内のすべてのポリシーをMTList内の各テンプレートに関連付ける。留意すべきことは、サービス層は、要求元から要求を受信することなく、特定のポリシーを既存のメッセージテンプレートに自発的に関連付けることができ、その場合、ステップ１は不要であるということである。

ステップ３では、サービス層は、ステップ１の要求の処理に成功したかどうかを示すために、メッセージテンプレートポリシー関連付け応答を要求元に送信する。

図３２は、既存のメッセージテンプレートポリシーをリトリーブ／更新／削除する方法を示す。ステップ１では、要求元がサービス層に既存のメッセージテンプレートポリシーをリトリーブ、更新、または削除する要求を送信する。このメッセージには、操作すべき既存のメッセージテンプレートポリシーの識別子（すなわち、ＭＴＰＩＤ）が含まれる。

ステップ２では、サービス層はステップ１からの要求を処理する。ステップ１が既存のメッセージテンプレートポリシーの削除を要求し、ポリシーが既に１つまたは複数のメッセージテンプレートに関連付けられている場合、サービス層はそれらのメッセージテンプレートを更新し、それらと削除されるポリシーとの関連を切り離すことができる。

ステップ３では、サービス層は要求元に応答を送信する。ステップ１が既存のメッセージテンプレートポリシーのリトリーブを要求している場合、このメッセージにはその表現が含まれる。

上記のメッセージテンプレート管理および使用の様々な態様は、一実施形態では、ｏｎｅＭ２Ｍ機能アーキテクチャにおける新しいメッセージテンプレート管理（Message Template Management：ＭＴＭ）ＣＳＦとして実装され得る。時間に関連したｏｎｅＭ２Ｍ要求パラメータ（例えば、要求有効期限、結果有効期限、操作実行時間、結果持続性など）の相対値は要求メッセージが異なっても変わらない可能性があるため、相対値は要求テンプレートに含まれる。このＭＴＭ ＣＳＦは、ＣＳＥに常駐し、そのサービスを他のＣＳＥとＡＥの少なくとも一方に公開することができる。ＭＴＭ ＣＳＦには、上記の態様に対応する以下の機能がある。
・ＭＴＭ ＣＳＦは、他のホスティングＣＳＥからの要求を受信して分析することにより、メッセージテンプレート（すなわち、<messageTemplate>）を自動的に生成することができる。
・ＭＴＭ ＣＳＦは、<messageTemplate>リソースを他のＡＥ／ＣＳＥに公開する。言い換えれば、ＡＥ／ＣＳＥは、ＭＴＭ ＣＳＦから<messageTemplate>リソースを作成／リトリーブ／更新／削除できる。<messageTemplate>リソースが作成された後、ＡＥ（またはＣＳＥ）はその表現をリトリーブし、それを使用して、<messageTemplate>が要求テンプレートである場合に、最適化された要求を生成できる。

メッセージテンプレート管理の様々な態様に関連して前述した機能エンティティは、以下のようにｏｎｅＭ２Ｍエンティティにマッピングすることができる。１）サービス層をｏｎｅＭ２Ｍ ＣＳＥにマッピングし、２）要求元をｏｎｅＭ２Ｍ ＡＥまたはｏｎｅＭ２Ｍ ＣＳＥにマッピングする。例えば、ＩＮ−ＡＥ１はＩＮ−ＣＳＥ１において<messageTemplate1>を作成することができる。その後、ＩＮ−ＡＥ１は、最適化された要求を<messageTemplate1>に基づいて生成し、最適化された要求をＩＮ−ＣＳＥ１に送信することができる。次に、ＩＮ−ＣＳＥ１は、<messageTemplate1>を使用して、受信した最適化された要求を処理する。また、<messageTemplatel>をＩＮ−ＡＥ２などの他のアプリケーションが使用して、ＩＮ−ＣＳＥ１に対する最適化された要求を生成することもできる。

いくつかの新しい共通属性を表３に提案する。

表４には、上述のメッセージテンプレート管理および利用技術に基づいてより効率的なＲＥＳＴｆｕｌ操作をサポートするために使用できる、リトリーブ、更新、および削除操作の新しい要求メッセージパラメータが記載されている。

ＡＥ登録またはＣＳＥ登録のための応答メッセージに含めることができる新しい応答パラメータMTListを導入することができる。例えば、ＡＥ／ＣＳＥがホスティングＣＳＥに登録されると、ホスティングＣＳＥは、そのCSEBaseの下に<AE>または<remoteCSE>子リソースを作成する。５．３節で提案されているメッセージテンプレートの割り当てをサポートするために、ホスティングＣＳＥは、登録されたＡＥ／ＣＳＥに対して適切なメッセージテンプレートを選択し、それらの識別子（すなわち、MTListパラメータ）を応答メッセージに含める。さらに、または代替的に、ホスティングＣＳＥはMTListを<AE>または<remoteCSE>リソースの新しい属性として追加することによって、MTListに含まれる任意のテンプレートが<AE>または<remoteCSE>に適用可能であり、それによって使用され得ることを示すことができる。

ＲＳＴＣＩおよびＲＳＴＩＤは、ＣＳＥからＡＥ／ＣＳＥへの任意の応答メッセージに含めることができる２つの新しい応答パラメータとして導入され得る。ＲＳＴＣＩは、新しい応答テンプレートを作成するよう応答メッセージの受信側に通知し、このパラメータには応答テンプレートを作成するために必要なすべての情報が含まれる。作成された応答メッセージの識別子はＲＳＴＩＤに設定される。

MTListを、<CSEBase>、<node>、<AE>、および<remoteCSE>などの既存のｏｎｅＭ２Ｍリソースの新しい属性として導入することができる。MTListには、（<AE>と<node>の少なくとも一方が示す）アプリケーションまたは（<CSEBase>と<remoteCSE>の少なくとも一方が示す）サービス層に適用可能であり、それによって使用され得るメッセージテンプレート識別子のリストが含まれる。この属性は書き込み可能である。

messageTemplateを、メッセージテンプレートを表すために使用することができる。ＡＥ／ＣＳＥは、messageTemplateリソースを発見およびリトリーブでき、その後、その識別子を要求メッセージに含めることができ、個々の要求パラメータを含める必要はない。そのため、要求メッセージのサイズが縮小され、メッセージのオーバーヘッドが大幅に削減され得る。

図３３は、messageTemplateリソースの構造の一例を示す。<messageTemplate>リソースは、表５に指定されている子リソースを含むことができる。

<messageTemplate>リソースは、表６に指定されている属性を含むことができる。

図３４は、<messageTemplate>リソースを操作する（例えば、<messageTemplate>リソースを作成／リトリーブ／更新／削除する）方法を示す。発信元はＣＳＥまたはＡＥであり得る。受信側はＣＳＥである。詳細説明については、それぞれ表７、表８、表９、および表１０に記載する。

表７に説明するように、<messageTemplate>リソースを作成するために、<messageTemplate>作成手順を使用することができる。

表８に説明するように、既存の<messageTemplate>リソースの属性をリトリーブするために、<messageTemplate>リトリーブ手順を使用することができる。

表９に説明するように、既存の<messageTemplate>リソースを更新（例えば、そのlistOfAllowedRequestors属性を更新）するために、<messageTemplate>更新手順を使用することができる。

表１０に説明するように、既存の<messageTemplate>リソースを削除するために、<messageTemplate>削除手順を使用することができる。

新しいmessageTemplatePolicyリソースを使用して、メッセージテンプレートを表すことができる。ＡＥ／ＣＳＥは、messageTemplatePolicyリソースを発見およびリトリーブでき、その後、それを１つまたは複数のメッセージテンプレートに関連付けることができる。図３５は、一実施形態に係るmessageTemplatePolicyリソースの構造を示す。

<messageTemplatePolicy>リソースは、表１１に指定されている子リソースを含むことができる。

<messageTemplatePolicy>リソースは、表１２に指定された属性を含むことができる。

図３６は、<messageTemplatePolicy>リソースを操作する（例えば、<messageTemplatePolicy>リソースを作成／リトリーブ／更新／削除する）方法を示す。発信元はＣＳＥまたはＡＥであり得る。受信側はＣＳＥである。詳細説明については、それぞれ表１３、表１４、表１５、および表１６に記載する。

表１３に説明するように、<messageTemplatePolicy>リソースを作成するために、<messageTemplatePolicy>作成手順を使用することができる。

表１４に説明するように、既存の<messageTemplatePolicy>リソースの属性をリトリーブするために、<messageTemplatePolicy>リトリーブ手順を使用することができる。

表１５に説明するように、既存の<messageTemplatePolicy>リソースを更新（例えば、そのtemplatePolicyElement属性を更新）するために、<messageTemplatePolicy>更新手順を使用することができる。

表１６に説明するように、既存の<messageTemplatePolicy>リソースを削除するために、<messageTemplatePolicy>削除手順を使用することができる。

図３７は、サービス層（例えば、ｏｎｅＭ２Ｍ ＣＳＥ）におけるメッセージテンプレート管理のためのユーザインターフェースの一実施形態を示す。このインターフェースにより、ユーザまたはアプリケーションはＣＳＥを介して以下のタスクを開始して実行できる。
・新しいメッセージテンプレートの作成。
・メッセージテンプレートの検索。
・１つまたは複数のメッセージテンプレートの表示。
・１つまたは複数のメッセージテンプレートの更新。
・１つまたは複数のメッセージテンプレートの削除。

図３８は、サービス層（例えば、ｏｎｅＭ２Ｍ ＣＳＥ）におけるメッセージテンプレートポリシー管理のためのユーザインターフェースを示す。このインターフェースにより、ユーザまたはアプリケーションはＣＳＥを介して以下のタスクを開始して実行できる。
・新しいメッセージテンプレートポリシーの作成。
・メッセージテンプレートポリシーの検索。
・１つまたは複数のメッセージテンプレートポリシーの表示。
・１つまたは複数のメッセージテンプレートポリシーの更新。
・１つまたは複数のメッセージテンプレートポリシーの削除。

上記のメッセージテンプレート管理および使用の様々な態様は、一実施形態では、ワールドワイドウェブコンソーシアム（Ｗ３Ｃ）のモノのウェブ（ＷｏＴ）アーキテクチャにおけるモノの記述（Thing Description：ＴＤ）の一部として実装され得る。そこでは、ＷｏＴサービエントが、クライアントとサーバの両方の機能をサポートするデバイス、ゲートウェイ、およびサーバのうち少なくとも１つにおける論理モジュールとして定義される。各ＷｏＴサービエントは、ＷｏＴサービエントのリソースにアクセスする方法を記述したＴＤを備えている。前述のスマートメーターのユースケースを例にとると、サーバはＷｏＴサービエントを有するか、ＷｏＴサービエントとして実装される。メッセージテンプレート管理をサポートするために、一実施形態では、以下の手順を提案する。１）サーバのＷｏＴサービエントは、そのＴＤにおいて、要求テンプレートを記述するか、または含める。このテンプレートは、上記のＸＭＬ形式テンプレートの例と同じであり得るか、あるいは、より多くの要求パラメータを含むことができる。ＷｏＴサービエントは、ＴＤにおいて、このテンプレートが１つのスマートメーター（または、複数のスマートメーター）にのみ適用可能であることを指定することもできる。２）ＷｏＴクライアントとしてのスマートメーターは、ＷｏＴサービエントまたはＷｏＴサービエントのＴＤを格納している他の場所から、ＴＤを発見およびリトリーブする。３）スマートメーターは、ＴＤからテンプレートを抽出し、テンプレートに含まれる各パラメータの意味を理解する。４）スマートメーターはテンプレートを使用して、テンプレート識別子を含む最適化された要求メッセージを（例えば、メーターの指示値をサーバに報告するために）生成する。５）スマートメーターは、最適化された要求をＷｏＴサービエント（すなわち、サーバ）に送信する。６）ＷｏＴサービエントは、最適化された要求を受信し、対応する（最適化された要求に含まれるテンプレート識別子が示す）テンプレートを使用して、最適化された要求を処理する。７）ＷｏＴサービエントはスマートメーターに応答を送信する。あるいは、スマートメーター（または他のメーター、ＷｏＴクライアント、ＷｏＴサービエントなど）は、ＷｏＴサービエントのＴＤを更新することにより、テンプレートの自発的な作成およびＴＤへの挿入の少なくとも一方をすることできる。

図３９Ａは、１つまたは複数の開示される実施形態が実施され得るマシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（ＷｏＴ）の例示的な通信システム１０の一例の図である。一般に、Ｍ２Ｍ技術はＩｏＴ／ＷｏＴのためのビルディングブロックを提供し、Ｍ２Ｍデバイス、Ｍ２Ｍゲートウェイ、Ｍ２Ｍサーバ、およびＭ２ＭサービスプラットフォームはすべてＩｏＴ／ＷｏＴおよびＩｏＴ／ＷｏＴサービス層の構成要素または装置であり得る。図５〜図８、図１０、図１１、図１３〜３２、図３４および図３６に示すエンティティはすべて、図３９Ａ〜図３９Ｄに示すような通信システムなどのネットワーク装置を備えることができる。

サービス層は、ネットワークサービスアーキテクチャ内の機能層であり得る。サービス層は、通常、ハイパーテキスト転送プロトコル（HyperText Transfer Protocol：ＨＴＴＰ）、制約アプリケーションプロトコル（Constrained Application Protocol：ＣｏＡＰ）、またはメッセージキューテレメトリトランスポート（Message Queuing Telemetry Transport：ＭＱＴＴ）などのアプリケーションプロトコル層の上位に位置し、クライアントアプリケーションに付加価値サービスを提供する。サービス層は、制御層やトランスポート／アクセス層などのより下位のリソース層におけるコアネットワークへのインターフェースも提供する。サービス層は、サービス定義、サービスの実行時有効化、ポリシー管理、アクセス制御、およびサービスクラスタリングなどを含む複数のカテゴリーの（サービス）能力または機能をサポートする。最近、Ｍ２Ｍタイプのデバイスおよびアプリケーションを、インターネット／ウェブ、セルラー、企業、およびホームネットワークなどの展開に統合するということに伴う課題に対処するために、ｏｎｅＭ２Ｍなどのいくつかの業界標準化団体はＭ２Ｍサービス層を開発してきている。Ｍ２Ｍサービス層は、アプリケーションおよび様々なデバイスの少なくとも一方に、ＣＳＥまたはサービス機能層（Service Capability Layer：ＳＣＬ）と呼ばれることもあるサービス層によってサポートされる上記の能力または機能の集合またはセットへのアクセスを提供することができる。いくつかの例として、様々なアプリケーションが共通に使用する可能性のあるセキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニング、および接続管理が挙げられるが、これらに限定されない。これらの能力または機能は、Ｍ２Ｍサービス層によって定義されたメッセージフォーマット、リソース構造、およびリソース表現を利用するＡＰＩを介して、このような様々なアプリケーションが利用できる。ＣＳＥまたはＳＣＬは、ハードウェアおよびソフトウェアの少なくとも一方によって実装することが可能であり、様々なアプリケーションおよびデバイスの少なくとも一方に公開された（サービス）能力または機能（すなわち、そのような機能エンティティ間の機能インターフェース）を提供して、アプリケーションやデバイスがそのような能力または機能を利用できるようにする機能エンティティである。

図３９Ａに示すように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、通信ネットワーク１２を含む。通信ネットワーク１２は、固定ネットワーク（例えば、イーサネット（登録商標）（Ethernet）、ファイバ、サービス総合デジタル網（Integrated Services Digital Network：ＩＳＤＮ）、電力線搬送通信（Power Line Communication：ＰＬＣ）など）、または無線ネットワーク（例えば、無線ローカルエリアネットワーク（Wireless Local Area Network：ＷＬＡＮ）、セルラーなど）、または異種ネットワークのネットワークであり得る。例えば、通信ネットワーク１２は、音声、データ、ビデオ、メッセージング、ブロードキャストなどのコンテンツを複数ユーザに提供する複数のアクセスネットワークから構成され得る。例えば、通信ネットワーク１２は、符号分割多元接続（Code Division Multiple Access：ＣＤＭＡ）、時分割多元接続（Time Division Multiple Access：ＴＤＭＡ）、周波数分割多元接続（Frequency Division Multiple Access：ＦＤＭＡ）、直交周波数分割多元接続（Orthogonal Frequency Division Multiple Access：ＯＦＤＭＡ）、シングルキャリア周波数分割多元接続（Single Carrier Frequency Division Multiple Access：ＳＣ−ＦＤＭＡ）などの１つ以上のチャネルアクセス方法を採用することができる。さらに、通信ネットワーク１２は、例えば、コアネットワーク、インターネット、センサネットワーク、産業用制御ネットワーク、パーソナルエリアネットワーク、融合パーソナルネットワーク、衛星ネットワーク、ホームネットワーク、または企業ネットワークなどの他のネットワークを含むことができる。

図３９Ａに示すように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、インフラストラクチャドメインおよびフィールドドメインを含み得る。インフラストラクチャドメインは、エンドツーエンドＭ２Ｍ展開のネットワーク側を指し、フィールドドメインは、通常はＭ２Ｍゲートウェイの背後にあるエリアネットワークを指す。フィールドドメインとインフラストラクチャドメインは両方とも、ネットワークの様々な異なるネットワーク装置（例えば、サーバ、ゲートウェイ、デバイスなど）を含むことができる。例えば、フィールドドメインは、Ｍ２Ｍゲートウェイ１４およびデバイス１８を含むことができる。任意の数のＭ２Ｍゲートウェイデバイス１４およびＭ２Ｍデバイス１８が、必要に応じて、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０に含まれ得ることは理解されるであろう。Ｍ２Ｍゲートウェイデバイス１４およびＭ２Ｍデバイス１８の各々は、通信回路を使用して通信ネットワーク１２または直接無線リンクを介して信号を送受信するように構成される。

Ｍ２Ｍゲートウェイ１４は、（例えば、セルラーおよび非セルラーの）無線Ｍ２Ｍデバイスおよび固定ネットワークＭ２Ｍデバイス（例えば、ＰＬＣ）が通信ネットワーク１２などの事業者ネットワークまたは直接無線リンクを介して通信することを可能にする。例えば、Ｍ２Ｍデバイス１８は、データを収集し、通信ネットワーク１２または直接無線リンクを介して、Ｍ２Ｍアプリケーション２０または他のＭ２Ｍデバイス１８にデータを送信することができる。Ｍ２Ｍデバイス１８は、Ｍ２Ｍアプリケーション２０またはＭ２Ｍデバイス１８からデータを受信することもできる。さらに、以下に説明するように、データおよび信号は、Ｍ２Ｍサービス層２２を介して、Ｍ２Ｍアプリケーション２０に送信され、Ｍ２Ｍアプリケーション２０から受信され得る。Ｍ２Ｍデバイス１８とゲートウェイ１４は、例えば、セルラー、ＷＬＡＮ、無線パーソナルエリアネットワーク（Wireless Personal Area Network：ＷＰＡＮ）（例えば、Ｚｉｇｂｅｅ、低電力ワイヤレスパーソナルエリアネットワーク上のＩＰｖ６（IPv6 over Low-power Power Wireless Personal Area Networks：６ＬｏＷＰＡＮ）、Ｂｌｕｅｔｏｏｔｈ（登録商標））、直接無線リンク、ワイヤラインなどを含む様々なネットワークを介して、通信することができる。例示的なＭ２Ｍデバイスには、タブレット、スマートフォン、医療機器、温度および気象モニタ、コネクテッドカー、スマートメーター、ゲームコンソール、携帯情報端末、健康およびフィットネスモニタ、ライト、サーモスタット、電気製品、ガレージドア、その他のアクチュエータベースのデバイス、セキュリティデバイス、およびスマートコンセントが含まれるが、これらに限定されない。

図３９Ｂを参照すると、フィールドドメイン内に図示したＭ２Ｍサービス層２２は、Ｍ２Ｍアプリケーション２０、Ｍ２Ｍゲートウェイ１４、およびＭ２Ｍデバイス１８ならびに通信ネットワーク１２にサービスを提供する。Ｍ２Ｍサービス層２２は、必要に応じて、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイ１４、Ｍ２Ｍデバイス１８、および通信ネットワーク１２と通信することができることは理解されるであろう。Ｍ２Ｍサービス層２２は、サーバ、コンピュータ、デバイスなどを備えることができるネットワークの１つまたは複数のネットワーク装置によって実装することができる。Ｍ２Ｍサービス層２２は、Ｍ２Ｍデバイス１８、Ｍ２Ｍゲートウェイ１４、およびＭ２Ｍアプリケーション２０に適用されるサービス機能を提供する。Ｍ２Ｍサービス層２２の機能は、例えば、セルラーコアネットワーク、クラウドなどにおけるウェブサーバとして、様々な方法で実装されてもよい。

図示したＭ２Ｍサービス層２２と同様に、インフラストラクチャドメインにはＭ２Ｍサービス層２２’がある。Ｍ２Ｍサービス層２２’は、インフラストラクチャドメイン内のＭ２Ｍアプリケーション２０’および基礎となる通信ネットワーク１２にサービスを提供する。Ｍ２Ｍサービス層２２’はフィールドドメイン内のＭ２Ｍゲートウェイ１４およびＭ２Ｍデバイス１８にもサービスを提供する。Ｍ２Ｍサービス層２２’は任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイ、およびＭ２Ｍデバイスと通信することができることは理解されるであろう。Ｍ２Ｍサービス層２２’は、異なるサービスプロバイダによってサービス層と相互作用することができる。Ｍ２Ｍサービス層２２’は、サーバ、コンピュータ、デバイス、仮想マシン（例えば、クラウドコンピューティング／ストレージファームなど）などを備えることができるネットワークの１つまたは複数のネットワーク装置によって実装され得る。

図３９Ｂも参照すると、Ｍ２Ｍサービス層２２および２２’は、様々なアプリケーションおよび垂直アプリケーションが活用できるサービス配信機能のコアセットを提供する。これらのサービス機能は、Ｍ２Ｍアプリケーション２０および２０’がデバイスと相互作用し、データ収集、データ分析、デバイス管理、セキュリティ、請求、サービス／デバイスの発見などの機能を実行することを可能にする。基本的に、これらのサービス機能は、アプリケーションをこれらの機能を実装する負担から解放することによって、アプリケーション開発を簡素化し、商品化までのコストと時間を削減する。サービス層２２および２２’は、Ｍ２Ｍアプリケーション２０および２０’が、サービス層２２および２２’が提供するサービスに関連して、ネットワーク１２などの様々なネットワークを通じて通信することも可能にする。

Ｍ２Ｍアプリケーション２０および２０’は、例えば、運輸、健康およびウェルネス、コネクテッドホーム、エネルギー管理、資産追跡、ならびにセキュリティおよびサーベイランスなどであるがこれらに限らない様々な産業におけるアプリケーションを含み得る。上記のように、システムのデバイス、ゲートウェイ、サーバおよびその他のネットワーク装置にわたって実行されるＭ２Ｍサービス層は、例えば、データ収集、デバイス管理、セキュリティ、請求、位置追跡／ジオフェンシング、デバイス／サービス発見、およびレガシーシステム統合などの機能をサポートし、これらの機能をサービスとしてＭ２Ｍアプリケーション２０および２０’に提供する。

一般に、図３９Ｂに示すサービス層２２および２２’などのサービス層は、アプリケーションプログラミングインターフェース（ＡＰＩ）および基礎となるネットワーキングインターフェースのセットを介して付加価値サービス機能をサポートするソフトウェアミドルウェア層を定義する。ＥＴＳＩ Ｍ２ＭとｏｎｅＭ２Ｍの両アーキテクチャがサービス層を定義する。ＥＴＳＩ Ｍ２Ｍ’のサービス層は、サービス機能層（ＳＣＬ）と呼ばれる。ＳＣＬは、ＥＴＳＩ Ｍ２Ｍアーキテクチャの様々な異なるノードに実装できる。例えば、サービス層のインスタンスは、Ｍ２Ｍデバイス（この場合、インスタンスはデバイスＳＣＬ（Device SCL：ＤＳＣＬ）と呼ばれる）、ゲートウェイ（この場合、インスタンスはゲートウェイＳＣＬ（Gateway SCL：ＧＳＣＬ）と呼ばれる）、およびネットワークノード（この場合、インスタンスはネットワークＳＣＬ（Network SCL：ＮＳＣＬ）と呼ばれる）のうち少なくとも１つの範囲内に実装できる。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）のセット（すなわち、サービス機能）をサポートする。１つまたは複数の特定のタイプのＣＳＦのセットをインスタンス化したものは、様々なタイプのネットワークノード（例えば、インフラストラクチャノード、中間ノード、アプリケーション固有ノード）でホストされる共通サービスエンティティ（ＣＳＥ）と呼ばれる。第三世代パートナーシッププロジェクト（３ＧＰＰ）は、マシンタイプ通信（Machine-Type Communications：ＭＴＣ）のアーキテクチャも定義している。そのアーキテクチャにおいては、サービス層とそれが提供するサービス機能は、サービス機能サーバ（Service Capability Server：ＳＣＳ）の一部として実装される。ＥＴＳＩ Ｍ２ＭアーキテクチャのＤＳＣＬ、ＧＳＣＬ、またはＮＳＣＬの中、３ＧＰＰ ＭＴＣアーキテクチャのサービス機能サーバ（ＳＣＳ）の中、ｏｎｅＭ２ＭアーキテクチャのＣＳＦまたはＣＳＥの中、およびネットワークの他のノードの中のうちのどれにおいて具体化されているかにかかわらず、サービス層のインスタンスは、サーバ、コンピュータ、およびその他のコンピューティングデバイスまたはノードを含む、ネットワーク内の１つまたは複数のスタンドアロンノードで実行される論理エンティティ（例えば、ソフトウェア、コンピュータ実行可能命令など）として、または１つ以上の既存のノードの一部として実装できる。一例として、サービス層またはその構成要素のインスタンスは、以下に述べる図３９Ｃまたは図３９Ｄに示す一般的なアーキテクチャを持つネットワーク装置（例えば、サーバ、コンピュータ、ゲートウェイ、デバイスなど）で実行されるソフトウェアの形で実装できる。

さらに、本明細書で説明する方法および機能は、サービスにアクセスするためにサービス指向アーキテクチャ（Service-Oriented Architecture：ＳＯＡ）およびリソース指向アーキテクチャ（Resource-Oriented Architecture：ＲＯＡ）の少なくとも一方を使用するＭ２Ｍネットワークの一部として実装することができる。

図３９Ｃは、例えば、図５〜図８、図１０、図１１、図１３〜図３２、図３４、および図３６に示すエンティティの１つなどの、図３９Ａおよび図３９Ｂに示すようなＭ２Ｍネットワーク内のＭ２Ｍサーバ、ゲートウェイ、デバイス、またはその他のネットワーク装置として動作することができるネットワークの装置の例示的なハードウェア／ソフトウェアアーキテクチャのブロック図である。図３９Ｃに示すように、ネットワーク装置３０は、プロセッサ３２、取り外し不可能メモリ４４、取り外し可能メモリ４６、スピーカ／マイクロフォン３８、キーパッド４０、ディスプレイ、タッチパッド、インジケータ４２、電源４８、全地球測位システム（ＧＰＳ）チップセット５０、およびその他の周辺機器５２を含み得る。ネットワーク装置３０は、トランシーバ３４および送信／受信要素３６などの通信回路も含み得る。ネットワーク装置３０は、実施形態との整合性を保ちながら、前述の要素の任意のサブコンビネーションを含み得ることは理解されるであろう。このネットワーク装置は、例えば、図５〜図８、図１０、図１１、図１３〜図３２、図３４、および図３６に関連して図示および説明される方法や操作などの、本明細書に説明されるメッセージテンプレート管理機能および方法を実装する装置であり得る。

プロセッサ３２は、汎用プロセッサ、専用プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（Digital Signal Processor：ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアに関連する１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（Application Specific Integrated Circuit：ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（Field Programmable Gate Array：ＦＰＧＡ）回路、その他のタイプの集積回路（Integrated Circuit：ＩＣ）、状態マシンなどであり得る。一般に、プロセッサ３２は、ネットワーク装置の様々な必要機能を実行するために、ネットワーク装置のメモリ（例えば、メモリ４４やメモリ４６の）に格納されたコンピュータ実行可能命令を実行することができる。例えば、プロセッサ３２は、信号符号化、データ処理、電力制御、入出力処理、およびネットワーク装置３０が無線または有線環境で動作することを可能にする他の任意の機能のうち少なくとも１つを実行することができる。プロセッサ３２は、アプリケーション層プログラム（例えば、ブラウザ）、無線アクセス層（Radio Access layer：ＲＡＮ）プログラム、および他の通信プログラムのうち少なくとも１つを実行することができる。プロセッサ３２は、例えばアクセス層およびアプリケーション層の少なくとも一方における、認証や、セキュリティ鍵合意や、暗号操作などのセキュリティ操作を実行することもできる。

図３９Ｃに示すように、プロセッサ３２は、その通信回路（例えば、トランシーバ３４および送信／受信要素３６）に接続されている。プロセッサ３２は、ネットワーク装置３０を、それが接続されているネットワークを介して他のネットワーク装置と通信させるために、コンピュータ実行可能命令の実行を通じて、通信回路を制御することができる。特に、本明細書（例えば、図５〜図８、図１０、図１１、図１３〜図３２、図３４、および図３６）および特許請求の範囲に説明する送信および受信ステップを実行するために、プロセッサ３２は通信回路を制御することができる。図３９Ｃは、プロセッサ３２およびトランシーバ３４を別個のコンポーネントとして示しているが、プロセッサ３２およびトランシーバ３４は、共に電子パッケージまたはチップに統合されてもよいことは理解されるであろう。

送信／受信要素３６は、Ｍ２Ｍサーバ、ゲートウェイ、デバイスなどを含む他のネットワーク装置に信号を送信、またはそこから受信するように構成され得る。例えば、一実施形態では、送信／受信要素３６は、無線周波数（Radio Frequency：ＲＦ）信号を送信や受信するように構成されたアンテナであり得る。送信／受信要素３６は、ＷＬＡＮ、ＷＰＡＮ、セルラーなどの様々なネットワークおよびエアインターフェースをサポートすることができる。一実施形態では、送信／受信要素３６は、例えば、赤外線（Infrared：ＩＲ）、紫外線（Ultraviolet：ＵＶ）、または可視光信号を送信や受信するように構成されたエミッタ／検出器であり得る。さらに別の実施形態では、送信／受信要素３６は、ＲＦ信号と光信号の両方を送信および受信するように構成され得る。送信／受信要素３６が、無線または有線信号の任意の組み合わせを送信や受信するように構成され得ることは理解されるであろう。

さらに、図３９Ｃは、送信／受信要素３６を単一の要素として示しているが、ネットワーク装置３０は、任意の数の送信／受信要素３６を含むことができる。より具体的には、ネットワーク装置３０は、多入力多出力（Multiple Input Multiple Output：ＭＩＭＯ）技術を採用することができる。このように、一実施形態では、ネットワーク装置３０は、無線信号を送信および受信するための２つ以上の送信／受信要素３６（例えば、複数のアンテナ）を含み得る。

トランシーバ３４は、送信／受信要素３６によって送信すべき信号を変調し、送信／受信要素３６によって受信された信号を復調するように構成され得る。上述のように、ネットワーク装置３０は、マルチモード機能を有する。したがって、トランシーバ３４は、ネットワーク装置３０が、例えば、ユニバーサル地上無線アクセス（Universal Terrestrial Radio Access：ＵＴＲＡ）やＩＥＥＥ８０２．１１のなどの複数の無線アクセス技術（Radio Access Technology：ＲＡＴ）によって通信することを可能にするための、複数のトランシーバを含み得る。

プロセッサ３２は、取り外し不可能メモリ４４や取り外し可能メモリ４６などの任意のタイプの適切なメモリからの情報にアクセスし、そこにデータを格納することができる。例えば、上記のように、プロセッサ３２は、そのメモリにセッションコンテキストを格納することができる。取り外し不可能メモリ４４は、ランダムアクセスメモリ（random-access memory：ＲＡＭ）、読み出し専用メモリ（Read-Only Memory：ＲＯＭ）、ハードディスク、または任意の他のタイプの記憶装置を含むことができる。取り外し可能メモリ４６は、加入者識別モジュール（Subscriber Identity Module：ＳＩＭ）カード、メモリスティック、セキュアデジタル（Secure Digital：ＳＤ）メモリカードなどを含むことができる。他の実施形態では、プロセッサ３２は、サーバまたはホームコンピュータなどのネットワーク装置３０上に物理的に位置していないメモリからの情報にアクセスし、そこにデータを格納することができる。装置のステータスを反映するか、または装置および、特に、ネットワーク装置と通信する、基礎となるネットワーク、アプリケーション、または他のサービスを構成するために、プロセッサ３２は、ディスプレイまたはインジケータ４２上の照明パターン、画像、または色を制御するように構成されてもよい。一実施形態では、ディスプレイ／インジケータ４２は、図３１に示され、本明細書で説明されたグラフィカルユーザインターフェースを提示することができる。

プロセッサ３２は、電源４８から電力を受けることができ、ネットワーク装置３０内の他の構成要素に電力を分配したり制御したりするように構成され得る。電源４８は、ネットワーク装置３０に電力を供給するための任意の適切なデバイスであり得る。例えば、電源４８は、１つ以上の乾電池（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル金属水素化物（ＮｉＭＨ）、リチウムイオン（Ｌｉイオン）など）、太陽電池、燃料電池などを含み得る。

プロセッサ３２は、また、ネットワーク装置３０の現在の位置に関する位置情報（例えば、経度および緯度）を提供するように構成されたＧＰＳチップセット５０に接続されてもよい。ネットワーク装置３０は、実施形態との整合性を保ちながら、任意の適切な位置決定方法によって位置情報を取得できるということは理解されるであろう。

プロセッサ３２は、さらに、追加的特徴や機能性や有線または無線接続性を提供する１つまたは複数のソフトウェアやハードウェアのモジュール含むことができるその他の周辺機器５２に接続され得る。例えば、周辺機器５２は、加速度計や生体計測（例えば、指紋）センサなどの各種センサ、電子コンパス（ｅ−Ｃｏｍｐａｓｓ）、衛星トランシーバ、センサ、（写真またはビデオ用）デジタルカメラ、ユニバーサルシリアルバス（Universal Serial Bus：ＵＳＢ）ポートまたはその他の相互接続インターフェース、振動デバイス、テレビジョントランシーバ、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（Frequency Modulated：ＦＭ）無線ユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザなどを含み得る。

ネットワーク装置３０は、センサ、家庭用電化製品、スマートウォッチやスマートクロージングのようなウェアラブルデバイス、医療機器やｅＨｅａｌｔｈデバイス、ロボット、産業機器、ドローン、乗用車、トラック、列車、航空機などの輸送手段などの、他の装置またはデバイス内に具現化されてもよい。ネットワーク装置３０は、そのような装置またはデバイスの他の構成要素、モジュール、またはシステムに、周辺機器５２の１つを含み得る相互接続インターフェースなどの１つまたは複数の相互接続インターフェースを介して接続されてもよい。

図３９Ｄは、図５〜図８、図１０、図１１、図１３〜図３２、図３４、および図３６に示され、本明細書で説明されたエンティティなどの、ネットワークの１つまたは複数のネットワーク装置を実装するためにも使用できる例示的なコンピューティングシステム９０のブロック図である。コンピューティングシステム９０は、Ｍ２Ｍサーバ、ゲートウェイ、デバイス、または図３９Ａおよび３９Ｂに示すようなＭ２Ｍネットワーク内の他のネットワーク装置として、動作することができる。

コンピューティングシステム９０は、コンピュータまたはサーバを備えることができ、主としてコンピュータ読み取り可能な命令によって制御され得る。その命令はソフトウェアの形であってもよく、任意の場所に、あるいは任意の手段によって格納もしくはアクセスされてもよい。そのようなコンピュータ読み取り可能な命令は、中央処理装置（Central Processing Unit：ＣＰＵ）９１などのプロセッサ内で実行されて、コンピューティングシステム９０を機能させることができる。多くの既知のワークステーション、サーバ、およびパーソナルコンピュータでは、中央処理装置９１は、マイクロプロセッサと呼ばれるシングルチップＣＰＵによって実装される。他のマシンでは、中央処理装置９１は複数のプロセッサを備え得る。コプロセッサ８１は、追加的機能を実行するかまたはＣＰＵ９１をアシストする、メインＣＰＵ９１とは別のオプションのプロセッサである。ＣＰＵ９１とコプロセッサ８１の少なくとも一方は、例えば、セッション認証情報の受信またはセッション認証情報に基づく認証のような、エンドツーエンド（End-to-End：Ｅ２Ｅ）Ｍ２Ｍサービス層セッションのための開示されたシステムと方法に関連するデータを、受信、生成、および処理することができる。

動作中、ＣＰＵ９１は命令をフェッチし、解読し、実行し、そして、コンピュータの主たるデータ転送経路であるシステムバス８０を介して、他のリソースと情報をやりとりする。そのようなシステムバスは、コンピューティングシステム９０の構成要素を接続し、データ交換の媒介手段を規定する。システムバス８０は、通常、データを送信するためのデータラインと、アドレスを送信するためのアドレスラインと、割り込みを送信するためとシステムバスを動作させるための制御ラインとを含む。そのようなシステムバス８０の一例が、周辺構成要素相互接続（Peripheral Component Interconnect：ＰＣＩ）バスである。

システムバス８０に接続されたメモリには、ランダムアクセスメモリ（ＲＡＭ）８２と読み出し専用メモリ（ＲＯＭ）９３が含まれる。そのようなメモリは、情報を格納し、読み出すことを可能にする回路を含む。ＲＯＭ９３は、一般に、容易に修正できない保存データを格納する。ＲＡＭ８２内に格納されたデータは、ＣＰＵ９１または他のハードウェアデバイスによって読み取られるか、変更され得る。ＲＡＭ８２やＲＯＭ９３へのアクセスは、メモリコントローラ９２によって制御され得る。メモリコントローラ９２は、命令が実行されると、仮想アドレスを物理アドレスに変換するアドレス変換機能を提供することができる。メモリコントローラ９２は、さらに、システム内のプロセスを隔離してシステムプロセスをユーザプロセスから隔離するメモリ保護機能を提供することができる。そのため、第１モードで実行中のプログラムは、それ自身のプロセス仮想アドレス空間によってマッピングされるメモリのみにアクセスすることができ、プロセス間のメモリ共有が設定されていない限り、別のプロセスの仮想アドレス空間内のメモリにアクセスすることはできない。

さらに、コンピューティングシステム９０は、ＣＰＵ９１から、プリンタ９４、キーボード８４、マウス９５、およびディスクドライブ８５などの周辺機器への命令伝達を司る周辺機器コントローラ８３を含むことができる。

ディスプレイコントローラ９６によって制御されるディスプレイ８６は、コンピューティングシステム９０によって生成される視覚出力を表示するために使用される。そのような視覚出力は、テキスト、グラフィックス、動画グラフィックス、およびビデオを含むことができる。ディスプレイ８６は、ブラウン管（Cathode-Ray Tube：ＣＲＴ）ベースのビデオディスプレイ、液晶ディスプレイ（Liquid Crystal Display：ＬＣＤ）ベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、またはタッチパネルを用いて実装され得る。ディスプレイコントローラ９６は、ディスプレイ８６に送信されるビデオ信号を生成するために必要な電子部品を含む。ディスプレイ８６は、ＣＰＵ９１によって実行されるコンピュータ実行可能命令と共同して、図２５とそれに付随する記述に示され説明されたグラフィカルユーザインターフェースを生成および操作し得る。

さらに、コンピューティングシステム９０は、図３９Ａ〜図３９Ｄのネットワーク１２などの外部通信ネットワークにコンピューティングシステム９０を接続するために使用され得る、例えば、ネットワークアダプタ９７などの通信回路を含むことができ、それによって、コンピューティングシステム９０がネットワークの他の装置と通信することを可能にすることができる。通信回路は、単独に、またはＣＰＵ９１と共に使用されて、本明細書（例えば、図５〜図８、図１０、図１１、図１３〜図３２、図３４、および図３６）および特許請求の範囲に記載された送信および受信ステップを実行することができる。

本明細書で説明されるシステム、方法、およびプロセスのうちのいずれかまたはすべては、コンピュータ読み取り可能な記憶媒体上に記憶されたコンピュータ実行可能な命令（すなわち、プログラムコード）の形態で具現化することができ、その命令は、例えば、Ｍ２Ｍサーバ、ゲートウェイ、デバイスなどを含むＭ２Ｍネットワークの装置などのマシンによって実行されると、本明細書で説明されるシステム、方法、およびプロセスを実行または実装することが理解される。具体的には、上記のステップ、動作、または機能のうちのいずれも、そのような、コンピュータ実行可能な命令の形で実装され得る。コンピュータ読み取り可能な記憶媒体には、情報の記憶のための任意の非一時的な（すなわち、有形または物理的な）方法または技術の中に具現化される、揮発性および不揮発性両方の、取り外し可能および取り外し不可能な媒体が含まれるが、そのようなコンピュータ読み取り可能な記憶媒体には信号は含まれない。コンピュータ読み取り可能な記憶媒体は、ＲＡＭ、ＲＯＭ、電気的消去可能プログラマブル読み出し専用メモリ（Electrically Erasable Programmable Read-Only Memory：ＥＥＰＲＯＭ）、フラッシュメモリまたは他のメモリ技術、コンパクトディスク読み出し専用メモリ（Compact Disc Read-Only Memory：ＣＤ−ＲＯＭ）、デジタルバーサタイルディスク（Digital Versatile Disc：ＤＶＤ）または他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶デバイス、または所望の情報を記憶するために使用可能で、コンピュータによってアクセス可能な任意の他の有形すなわち物理的媒体を含むが、それらに限定されない。

以下は、上記の説明に出現する可能性があるサービス層技術に関連する略語のリストである。特に指定のない限り、本明細書で使用される略語は、以下に記載された対応する用語を指す。
3GPP 3rd Generation Partnership Project（第三世代パートナーシッププロジェクト）
AE Application Entity（アプリケーションエンティティ）
CSE Common Service Entity（共通サービスエンティティ）
CSF Common Service Function（共通サービス機能）
IoT Internet of Things（モノのインターネット）
M2M Machine-to-Machine（マシンツーマシン）
MT Message Template（メッセージテンプレート）
MTCI Message Template Creation Indicator（メッセージテンプレート作成インジケータ）
MTID Message Template Identifier（メッセージテンプレート識別子）
MTM Message Template Management（メッセージテンプレート管理）
MTP Message Template Policy（メッセージテンプレートポリシー）
MTPID Message Template Policy Identifier（メッセージテンプレートポリシー識別子）
MTUI Message Template Update Indicator（メッセージテンプレート更新インジケータ）
NB-IoＴ Narrow-Band IoT（狭帯域ＩｏＴ）
OCF Open Connectivity Foundation（オープンコネクティビティファウンデーション）
REST Resource State Transfer（リソース状態転送）
REQT Request Template（要求テンプレート）
RQTCI Request Template Creation Indicator（要求テンプレート作成インジケータ）
RQTID Request Template Identifier（要求テンプレート識別子）
RSPT Response Template（応答テンプレート）
RSTCI Response Template Creation Indicator（応答テンプレート作成インジケータ）
RSTID Response Template Identifier（応答テンプレート識別子）
UE User Equipment（ユーザ装置）
URI Uniform Resource Identifier（統一資源識別子）

この書面による明細書は、実施例を使用して、最良の形態を含む本発明を開示し、また、任意のデバイスまたはシステムを製造および使用することおよび任意の組み込まれた方法を実行することを含めて、当業者が本発明を実施することを可能にする。本発明の特許性のある範囲は特許請求の範囲によって定義されており、当業者が想到する他の例を含み得る。そのような他の例は、それらが請求項の文字通りの言語と異ならない要素を有する場合、またはそれらが請求項の文字通りの言語との非実質的な相違を伴う同等の要素を含む場合、請求項の範囲内にあるものとする。

Claims (20)

1. 少なくとも１つのプロセッサとメモリを備えるネットワーク装置であって、前記メモリは、前記少なくとも１つのプロセッサによって実行されたとき、通信ネットワークのサービス層を実装して、前記サービス層に、
   それぞれが、前記通信ネットワーク上の１つまたは複数のデバイスから前記サービス層が受信し得るそれぞれのタイプのメッセージに関連付けられた１つまたは複数のパラメータの値を含み、それぞれが、メッセージテンプレートを一意的に識別する関連メッセージテンプレート識別子を持つ、１つまたは複数のメッセージテンプレートを前記ネットワーク装置の前記メモリに格納することと、
   前記通信ネットワーク上のデバイスから、情報とメッセージテンプレート識別子を有するメッセージを受信することと、
   前記デバイスからの前記メッセージに対応して、前記デバイスから受信した前記メッセージ中の前記メッセージテンプレート識別子と合致する関連メッセージテンプレート識別子を持つ格納されたメッセージテンプレートを前記メモリからリトリーブ（検索して取得）することと、
   前記受信したメッセージ中の前記情報を前記リトリーブしたメッセージテンプレート中の前記パラメータ値と組み合わせて、完全なメッセージを形成することと、
   前記完全なメッセージを処理することを含む操作を実行させる実行可能命令を格納する、ネットワーク装置。
2. 前記実行可能命令は、さらに、前記サービス層に、
   新しいメッセージテンプレートが表現すべきそれぞれのタイプのメッセージに関連付けられた１つまたは複数のパラメータの値を含む、前記新しいメッセージテンプレートを作成する要求を受信することと、
   前記受信したパラメータ値を有する前記新しいメッセージテンプレートを作成することと、
   前記新しいメッセージテンプレートに関連付けられた識別子を生成することと、
   前記識別子に関連する前記新しいメッセージテンプレートを前記メモリに格納することと、
   前記新しいメッセージテンプレートの作成の前記要求に対応して、前記新しいメッセージテンプレートに関連付けられた前記識別子を含む応答を送信することを含む操作を実行させる、請求項１に記載のネットワーク装置。
3. 前記サービス層は、前記新しいメッセージテンプレートの作成の前記要求を受信する代わりに、前記新しいメッセージテンプレートを作成することを決定し、前記パラメータ値を前記新しいメッセージテンプレートに含めることを決定する、請求項２に記載のネットワーク装置。
4. 新しいメッセージテンプレートを作成することの前記決定は、前記通信ネットワーク上のデバイスから前記サービス層が受信したメッセージに基づく、請求項３に記載のネットワーク装置。
5. 前記実行可能命令は、さらに、前記サービス層に、
   前記デバイスから受信した前記メッセージへの応答に関連付けるパラメータの値を有する、関連する識別子を持つ応答メッセージテンプレートを作成させることと、
   前記デバイスに、前記応答メッセージテンプレートをその識別子と共に提供するか、または前記応答メッセージテンプレートのコピーを自身で作成することを要求することと、
   前記デバイスから受信した前記メッセージに対応して、前記応答メッセージテンプレートに関連する前記識別子を含むが、前記応答メッセージテンプレートの前記パラメータの値は含まない応答メッセージを、前記デバイスに送信することを含む操作を実行させる、請求項１に記載のネットワーク装置。
6. 前記実行可能命令は、さらに、前記サービス層に、
   前記ネットワーク上の１つまたは複数のデバイスのグループを選択することと、
   前記グループの前記デバイスが前記サービス層に応答メッセージを送信する際に使用すべき前記格納されたメッセージテンプレートの識別子の１つを、前記デバイスのグループに割り当てることと、
   前記割り当てられたメッセージテンプレート識別子を前記デバイスのグループに送信することを含む操作を実行させる、請求項１に記載のネットワーク装置。
7. 前記デバイスから受信された前記メッセージは、前記デバイスにホストされたアプリケーションから受信したものである、請求項１に記載のネットワーク装置。
8. それぞれが、通信ネットワーク上の１つまたは複数のデバイスからサービス層エンティティが受信し得るそれぞれのタイプのメッセージに関連付けられた１つまたは複数のパラメータの値を含み、それぞれが、メッセージテンプレートを一意的に識別する関連メッセージテンプレート識別子を持つ、１つまたは複数のメッセージテンプレートを前記通信ネットワークの前記サービス層エンティティのメモリに格納することと、
   前記通信ネットワーク上のデバイスから、情報とメッセージテンプレート識別子を有するメッセージを、前記サービス層エンティティによって受信することと、
   前記デバイスからの前記メッセージに対応して、前記デバイスから受信した前記メッセージ中の前記メッセージテンプレート識別子と合致する関連メッセージテンプレート識別子を持つ格納されたメッセージテンプレートを、前記メモリから、前記サービス層エンティティによってリトリーブすることと、
   前記受信したメッセージ中の前記情報を前記リトリーブしたメッセージテンプレート中の前記パラメータ値と組み合わせて、完全なメッセージを、前記サービス層エンティティによって形成することと、
   前記完全なメッセージを、前記サービス層エンティティによって処理することを含む方法。
9. 新しいメッセージテンプレートが表現すべきそれぞれのタイプのメッセージに関連付けられた１つまたは複数のパラメータの値を含む、前記新しいメッセージテンプレートを作成する要求を、前記サービス層エンティティによって受信することと、
   前記受信したパラメータ値を有する前記新しいメッセージテンプレートを、前記サービス層エンティティによって作成することと、
   前記新しいメッセージテンプレートに関連付けられた識別子を、前記サービス層エンティティによって生成することと、
   前記識別子に関連する前記新しいメッセージテンプレートを、前記サービス層エンティティによって、前記メモリに格納することと、
   前記新しいメッセージテンプレートの作成の前記要求に対応して、前記新しいメッセージテンプレートに関連付けられた前記識別子を含む応答を、前記サービス層エンティティによって送信することをさらに含む、請求項８に記載の方法。
10. 前記新しいメッセージテンプレートの作成の前記要求を受信する代わりに、前記サービス層エンティティによって、前記新しいメッセージテンプレートを作成することを決定し、前記パラメータ値を前記新しいメッセージテンプレートに含めることを決定することをさらに含む、請求項９に記載の方法。
11. 新しいメッセージテンプレートを作成することの前記決定は、前記通信ネットワーク上のデバイスから前記サービス層エンティティが受信したメッセージに基づく、請求項１０に記載の方法。
12. 前記デバイスから受信した前記メッセージへの応答に関連付けるパラメータの値を有する、関連する識別子を持つ応答メッセージテンプレートを、前記サービス層エンティティによって作成することと、
    前記サービス層エンティティによって、前記デバイスに、前記応答メッセージテンプレートをその識別子と共に提供するか、または前記応答メッセージテンプレートのコピーを自身で作成することを要求することと、
    前記サービス層エンティティによって、前記デバイスから受信した前記メッセージに対応して、前記応答メッセージテンプレートに関連する前記識別子を含むが、前記応答メッセージテンプレートの前記パラメータの値は含まない応答メッセージを、前記デバイスに送信することをさらに含む、請求項８に記載の方法。
13. 前記ネットワーク上の１つまたは複数のデバイスのグループを、前記サービス層エンティティによって選択することと、
    前記グループの前記デバイスが前記サービス層エンティティに応答メッセージを送信する際に使用すべき前記格納されたメッセージテンプレートの識別子の１つを、前記サービス層エンティティによって前記デバイスのグループに割り当てることと、
    前記割り当てられたメッセージテンプレート識別子を、前記サービス層エンティティによって前記デバイスのグループに送信することをさらに含む、請求項８に記載の方法。
14. 前記デバイスから受信された前記メッセージは、前記デバイスにホストされたアプリケーションから受信したものである、請求項８に記載の方法。
15. 通信ネットワークに接続され、少なくとも１つのプロセッサとメモリを備えるデバイスであって、前記メモリは、前記少なくとも１つのプロセッサによって実行されたとき、前記デバイスに、
    情報と、要求メッセージに関連する共通パラメータの値を含んで前記通信ネットワークのサービス層に格納されたメッセージテンプレートの識別子と、を含む前記要求メッセージを作成することと、
    前記サービス層に、前記情報と前記メッセージテンプレート識別子を含むが、前記サービス層に格納された前記メッセージテンプレートの前記共通パラメータ値は含まない前記要求メッセージを送信することを含む操作を実行させる実行可能命令を格納する、デバイス。
16. 前記実行可能命令は、さらに、前記デバイスに、
    前記デバイスが前記サービス層に送信し得る要求メッセージのタイプに共通に関連する１つまたは複数のパラメータの値を含む、新しいメッセージテンプレートの作成要求を、前記サービス層に送信することと、
    前記デバイスからの要求に対応して前記サービス層が作成した新しいメッセージテンプレートに関連する識別子を前記サービス層から受信することと、
    そのタイプのメッセージを前記サービス層に送信する際に、前記新しいメッセージテンプレート識別子を使用することを含む操作を実行させる、請求項１５に記載のデバイス。
17. 前記新しいメッセージテンプレートを作成する前記要求は、作成すべき前記新しいメッセージテンプレートのタイプの識別子を含む、請求項１６に記載のデバイス。
18. 前記新しいメッセージテンプレートを作成する前記要求は、前記１つまたは複数のパラメータのリスト、および前記新しいメッセージテンプレートに含まれるべき前記パラメータの値をさらに含む、請求項１７に記載のデバイス。
19. 前記新しいメッセージテンプレートを作成する前記要求は、前記新しいメッセージテンプレートを使用することが許可される他のデバイスのリストをさらに含む、請求項１８に記載のデバイス。
20. 前記新しいメッセージテンプレートを作成する前記要求は、複数の新しいメッセージテンプレート作成する要求を含む、請求項２０に記載のデバイス。

Images