(57)【特許請求の範囲】
【請求項１】
マシン対マシン（Ｍ２Ｍ）通信システムにおいてアナウンスされたリソースを生成する方法であって、
生成元Ｍ２Ｍノードが生成した属性がリストされている生成リクエストを発行するステップ、
前記発行された生成リクエストに対する許可応答を受信するステップ、
前記生成した属性に対する更新リクエストを発行するとともに、ターゲットリソース上に存在しない１以上の属性に対する更新リクエストを発行するステップであって、前記１以上の属性は前記更新リクエストのリソースコンテンツパラメータに含まれている、ステップ、
前記発行した更新リクエストに対する許可応答を受信するステップであって、前記発行した更新リクエストに対する許可応答は、前記更新リクエストを発行したオリジネータにおいて前記生成した属性を更新することを許可する応答であり、前記発行した更新リクエストに対する前記許可応答は、前記１以上の属性を生成したことを示す応答メッセージを含む、ステップ、
を有することを特徴とする方法。
【請求項２】
前記更新リクエストは、前記ターゲットリソースのＵＲＩ、前記更新リクエストを発行したオリジネータのＩＤ、更新すべき前記生成した属性に関連する情報、または生成すべき前記１以上の属性に関する情報を含む
ことを特徴とする請求項１記載の方法。
【請求項３】
前記方法はさらに、前記発行した更新リクエストに対する前記許可応答を受信しなかった場合は前記ターゲットリソースにおける属性について別の生成リクエストを発行するステップを有する
ことを特徴とする請求項１記載の方法。
【請求項４】
Ｍ２Ｍ通信システムにおいてアナウンスされたリソースを生成する装置であって、
生成元Ｍ２Ｍノードが生成した属性がリストされている生成リクエストを発行するモジュール、
前記発行された生成リクエストに対する許可応答を受信するモジュール、
前記生成した属性に対する更新リクエストを発行するとともに、ターゲットリソース上に存在しない１以上の属性に対する更新リクエストを発行するモジュールであって、前記１以上の属性は前記更新リクエストのリソースコンテンツパラメータに含まれている、モジュール、
前記発行した更新リクエストに対する許可応答を受信するモジュールであって、前記発行された更新リクエストに対する前記許可応答は、前記更新リクエストを発行したオリジネータにおいて前記生成した属性を更新することを許可する応答であり、前記発行した更新リクエストに対する前記許可応答は、前記１以上の属性を生成したことを示す応答メッセージを含む、モジュール、
を備えることを特徴とする装置。
【請求項５】
前記更新リクエストは、前記ターゲットリソースのＵＲＩ、前記オリジネータのＩＤ、更新すべき前記生成した属性に関連する情報、または生成すべき前記１以上の属性に関する情報を含む
ことを特徴とする請求項４記載の装置。
【請求項６】
前記装置はさらに、前記発行した更新リクエストに対する前記許可応答が受信されなかった場合は前記ターゲットリソースにおける属性について別の生成リクエストを発行するモジュールを備える
ことを特徴とする請求項４記載の装置。
【請求項７】
前記オリジネータは、アプリケーションエンティティ（ＡＥ）または共通サービスエンティティ（ＣＳＥ）を含む
ことを特徴とする請求項１記載の方法。
【請求項８】
前記オリジネータは、アプリケーションエンティティ（ＡＥ）または共通サービスエンティティ（ＣＳＥ）を含む
ことを特徴とする請求項４記載の装置。
【請求項９】
前記生成した属性は、前記更新リクエストのＯｐｔｉｏｎａｌ  Ａｎｎｏｕｎｃｅｄ（ＯＡ）の属性と対応している
ことを特徴とする請求項１記載の方法。
【請求項１０】
前記生成した属性は、前記更新リクエストのＯｐｔｉｏｎａｌ  Ａｎｎｏｕｎｃｅｄ（ＯＡ）の属性と対応している
ことを特徴とする請求項４記載の装置。
【請求項１１】
前記生成した属性に関する情報または前記生成すべき前記１以上の属性に関する情報は、前記生成した属性の名称と新たに提案する値を含む
ことを特徴とする請求項２記載の方法。
【請求項１２】
前記生成した属性に関する情報または前記生成すべき前記１以上の属性に関する情報は、前記生成した属性の名称と新たに提案する値を含む
ことを特徴とする請求項５記載の装置。
【請求項１３】
各前記生成した属性または各前記１以上の属性は、特定のリソースタイプについて読み書きアクセスできるように示されている
ことを特徴とする請求項１記載の方法。
【請求項１４】
各前記生成した属性または各前記１以上の属性は、特定のリソースタイプについて読み書きアクセスできるように示されている
ことを特徴とする請求項４記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
＜関連出願に対する相互参照＞
本特許文書は、２０１４年３月１８日出願の米国仮特許出願６１／９５５，１８０号、２０１４年４月３日出願の米国仮特許出願６１／９７４，９２３号、２０１４年４月２３日出願の米国仮特許出願６１／９８３，４１１号、および２０１４年５月３０日出願の米国仮特許出願６２／００５，９６１号の優先権を主張する。これら特許出願の全体は、参照により本文書の開示の一部として組み込まれる。
【０００２】
＜技術分野＞
本特許文書は、マシンタイプ通信（ＭＴＣ）とマシン対マシン（Ｍ２Ｍ）通信を含む通信に関するものである。
【背景技術】
【０００３】
多くのアプリケーションにおいて、無線ネットワーク内で動作する無線デバイスは、当該無線ネットワークにおいては動作していないが通信可能な他のデバイスおよびサーバと通信する。様々な標準規格を用いて、そのような無線デバイスに対する接続を提供することができる。例えばインターネットプロトコル（ＩＰ）は、無線デバイスに対して割り当てられたＩＰアドレスに基づいて、無線デバイスが他デバイスと接続することができるフレームワークの１つである。
【０００４】
例えばマシンタイプ通信（ＭＴＣ）やマシン対マシン通信の無線デバイスを含むシステムの場合においては、ＩＰ接続のフレームワークがないことがある。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本文書は、Ｍ２Ｍデバイス間の通信を促進する技術を記載している。開示する技術を用いて、実施形態において、Ｍ２Ｍデバイスがリソースを生成し、他のＭ２Ｍデバイスがこれを知ることができるようにし、Ｍ２Ｍデバイスがこれを削除することができる。
【課題を解決するための手段】
【０００６】
１側面において、Ｍ２Ｍ通信システムにおいてアナウンスされた属性から情報を取得する技術は、前記アナウンスされた属性のアドレスを指定するとともに前記アナウンスされた属性のＩＤを含めることにより情報取得リクエストを発行するステップ；前記情報取得リクエストに応じて情報応答を受信するステップ；前記受信した情報応答をローカルで処理するかまたは他のＭ２Ｍデバイスへ転送して処理させるかを選択するステップ；を有する。
【０００７】
他側面において、Ｍ２Ｍ通信システムにおいてアナウンスされた属性を削除する技術は、削除すべき属性が省略されたリソースの属性リストを生成するステップ；前記削除すべき属性をホストしているＭ２Ｍノードに対して前記リストを送信するステップ；を有する。
【０００８】
他側面において、Ｍ２Ｍ通信システムにおいてアナウンスされたリソースを生成する技術は、生成元Ｍ２Ｍノードが生成した属性がリストされている生成リクエストを発行するステップ；前記発行された生成リクエストに対する許可応答を受信するステップ；を有する。
【０００９】
これらおよびその他側面、その実装および変形例は、図面、明細書、および特許請求範囲に記載されている。
【図面の簡単な説明】
【００１０】
【図１】無線ネットワークアーキテクチャの例を示す。
【００１１】
【図２】無線ネットワークで動作する無線デバイスの例のブロック図である。
【００１２】
【図３】Ｍ２Ｍ通信システムのアーキテクチャ例を示す。
【００１３】
【図４Ａ】ＣＳＥＢａｓｅリソースの例を示す。
【００１４】
【図４Ｂ】ｒｅｍｏｔｅＣＳＥリソースの例を示す。
【００１５】
【図５】Ｍ２Ｍシステムにおける情報フローの例を示す。
【００１６】
【図６】属性取得手順におけるメッセージ交換の例を示す。
【００１７】
【図７】属性更新手順におけるメッセージ交換の例を示す。
【００１８】
【図８】属性削除手順におけるメッセージ交換の例を示す。
【００１９】
【図９】Ｍ２Ｍ通信方法の例フローチャートである。
【００２０】
【図１０】Ｍ２Ｍ通信装置の例のブロック図である。
【００２１】
【図１１】Ｍ２Ｍ通信方法の例のフローチャートである。
【００２２】
【図１２】Ｍ２Ｍ通信装置の例のブロック図である。
【００２３】
【図１３】Ｍ２Ｍ通信方法の例のフローチャートである。
【００２４】
【図１４】Ｍ２Ｍ通信装置の例のブロック図である。
【発明を実施するための形態】
【００２５】
マシン対マシン通信（Ｍ２Ｍ）において、２つのデバイス間の通信は自動的にトリガされる。すなわち、人間ユーザが積極的に参加することはない。例えばＭ２Ｍ通信は、時間的境界において開始する場合がある。例えば週１回、または特定イベント発生時（例：雨の後にマシンが記録した降雨測定）である。Ｍ２Ｍ通信に参加するデバイスは、長期間（例：数時間から数か月）パワーダウンまたはスリープモード（他デバイスと通信しない）になる場合がある。Ｍ２Ｍデバイスによる長時間のスリープサイクルの結果、通信エンドポイントにおけるリソースなどの動作パラメータは、２つのデバイス起動サイクル間で変化する場合がある。さらにＭ２Ｍデバイスはバッテリ動作する場合があり、バッテリ寿命を節約してこれらデバイスがバッテリ交換しなくて済むようにすることは有用である。
【００２６】
Ｍ２Ｍデバイスは、特定のリソースを搭載する場合がある。リソースの例としては、メモリ、演算パワー、センサ、別ネットワークへの接続、エネルギー貯蔵能力、ディスプレイリソース、などが挙げられる。各リソースは、当該リソースを記述するために用いる、対応する属性セットを有する。通信メッセージの観点において、リソースはＭ２Ｍデバイスを記述するために用いるデータ構造を表す。データ構造の各要素は、属性とみなすことができる。Ｍ２Ｍデバイスにとってローカルで利用可能なリソースは、経時変化する場合がある。例えばＭ２Ｍデバイスがスリープモードであって他のＭ２Ｍデバイスと通信していない間である。例えばオフライン中にストレージ機能をビデオ監視カメラに対して追加することができる。他例として、ｏｎ／ｏｆｆタイプの光バルブは、薄暗くなるタイプの光バルブと交換することにより、証明を調整するリソースを提供することができる。同様にＭ２Ｍデバイスからリソースを剥奪または削除することができる。
【００２７】
他のＭ２Ｍデバイスに対して利用可能リソースの最新スナップショットを提供することは、Ｍ２Ｍデバイスによっては厄介なことである場合がある。リソース管理はバッテリパワーを消費するからである（例：計算および／または通信のため）。さらにＭ２Ｍデバイスのなかには、人間が到達することが困難なものがあり、あるいはローカルユーザインターフェースを備えておらず遠隔管理するものがある。アプリケーションサーバは、Ｍ２Ｍデバイス上で利用可能なリソースの属性を知ることを望む場合がある。現在通信していないＭ２Ｍデバイスにとって、この情報は以下によって収集することができる：（１）アプリケーションサーバがＭ２Ｍデバイスを起動してその属性を照会する、または（２）ネットワークにおいて他デバイス（例：ゲートウェイデバイス）が保持しているＭ２Ｍデバイスの属性のシャドーコピーまたはクローンコピーを読み取る。このデバイスは通信可能なものである。
【００２８】
後者の方法は、Ｍ２Ｍ通信に対してある種の利点を提供する。アプリケーションサーバからのクエリは、複数のサービスプロバイダの制御下におくことができ、個々のＭ２Ｍデバイスを起動する必要はなく、したがってバッテリパワーとネットワークの通信帯域幅を節約できるからである。個々のＭ２Ｍデバイスの属性の総数は、数百エントリに達する場合があり、したがって数キロバイトまたは数メガバイト（例：８Ｋｂｙｔｅから４Ｍｂｙｔｅ）の帯域幅と、全属性のクローンコピーまたはシャドーコピーを保存する記憶領域とを使用する。アプリケーションサーバは、Ｍ２Ｍデバイスの全属性値を必要としない場合もある。したがって、Ｍ２Ｍデバイスの属性をそのシャドーコピーと同期することは、通信時間、パワー、帯域幅を不必要に消費する場合がある。
【００２９】
現在のＭ２Ｍ通信システムおよびプロトコルは、Ｍ２Ｍ通信システムにおいて生じる動作状況に対して適切に対処することができていない。本文書が開示する技術を用いて、Ｍ２Ｍ通信システムにおけるリソースの属性の効率的な生成、広告、および削除を提供することができる。これは複数のサービスプロバイダにとって有用である。
【００３０】
Ｍ２Ｍエコシステムをエンドトゥエンド（Ｅ２Ｅ）の観点から見ると、Ｍ２Ｍアプリケーションサーバ（ＡＳ）がホストするＭ２Ｍアプリケーションと、Ｍ２Ｍデバイス／ゲートウェイとが存在する。このＥ２Ｅビューにおいて、Ｍ２Ｍサービスプラットフォームは、データ管理、デバイス管理、サービス有効化機能、などを提供する。基盤送信ネットワークは、Ｍ２Ｍデバイス／ゲートウェイがホストするＭ２Ｍアプリケーションとアプリケーションサーバとの間のデータフローの送受信サービスを提供する。
【００３１】
以下の定義セットは、ｏｎｅＭ２Ｍが開発している仕様からのものである。
【００３２】
アプリケーション機能（ＡＦ）：エンドトゥエンドＭ２Ｍソリューションのアプリケーションロジックを提供する。アプリケーション機能の例は、艦隊トラッキングアプリケーション、遠隔血糖監視アプリケーション、遠隔パワー計測制御アプリケーションである。
【００３３】
アプリケーションレイヤ：Ｍ２Ｍアプリケーションと関連するビジネスおよび動作ロジックを備える。
【００３４】
共通サービスエンティティ（ＣＳＥ）：共通サービスエンティティは、共通サービス機能の集合である。Ｍ２Ｍノードにおける共通サービスエンティティは、当該Ｍ２ＭノードにおけるＭ２Ｍアプリケーションが使用するサービスセット、または他のＭ２Ｍノードがアクセスするサービスを提供する。共通サービスエンティティは、基盤ネットワーク機能を利用し、相互通信してサービスを充足することができる。
【００３５】
共通サービス機能（ＣＳＦ）：Ｍ２ＭノードがＭ２Ｍシステムにおける他のエンティティに対して提供するサービス／機能のセットである。このサービス／機能は、ｏｎｅＭ２Ｍ規格に基づき、Ｍ２Ｍシステムにおける参照ポイントＸおよびＹを通じて、他の共通サービス機能（ＣＳＦ）に対して公開される。共通サービス機能は、参照ポイントＺを使用して基盤ネットワークサービスにアクセスする。ＣＳＦの例は以下の通りである：データ管理＆リポジトリ、デバイス管理、Ｍ２Ｍセッション管理、など。
【００３６】
共通サービスレイヤ：Ｍ２Ｍアプリケーションを有効化するＭ２Ｍサービス機能を備える（例えば管理、ディスカバリ、およびポリシ監視を通じて）。
【００３７】
ネットワークサービスレイヤ：送信、接続、およびサービス機能を提供する。
【００３８】
Ｍ２Ｍアプリケーション：サービスロジックを実施し、ｏｎｅＭ２Ｍ規格のオープンインターフェースセットを介してアクセスできるＭ２Ｍ共通サービスを使用する、アプリケーションである。
【００３９】
Ｍ２Ｍアプリケーションサービスプロバイダ：ユーザに対してＭ２Ｍアプリケーションサービスを提供するエンティティ（例：企業）である。
【００４０】
Ｍ２Ｍデバイス：検出および／または起動サービスを提供する機器である。Ｍ２Ｍデバイスは、１以上のＭ２Ｍアプリケーションをホストし、１以上のＣＳＥを収容する。Ｍ２Ｍデバイスは、検出＆起動機器と同じ場所に配置できるが、必ずしもそうしなくともよい。
【００４１】
Ｍ２Ｍゲートウェイ：１以上のＣＳＥを収容し、Ｍ２Ｍアプリケーションを収容する場合もある機器である。Ｍ２Ｍゲートウェイは、Ｍ２Ｍサービスインフラおよび１以上のＭ２Ｍデバイスと通信する。
【００４２】
Ｍ２Ｍノード：ＣＳＥおよび／またはＭ２Ｍアプリケーションを備え、Ｍ２Ｍデバイス、Ｍ２Ｍゲートウェイ、Ｍ２ＭサービスインフラなどのＭ２Ｍ物理エンティティを表す、論理エンティティである。
【００４３】
Ｍ２Ｍサービスインフラ：Ｍ２Ｍサービスプロバイダのデータ管理と協調機能を提供し、Ｍ２Ｍデバイスおよび／またはＭ２Ｍゲートウェイと通信する機器である。Ｍ２Ｍサービスインフラは、１以上のＣＳＥを収容する。
【００４４】
Ｍ２Ｍサービスプロバイダ：Ｍ２Ｍアプリケーションサービスプロバイダに対してまたはユーザに対してＭ２Ｍサービスを提供するエンティティ（例：企業）である。
【００４５】
基盤ネットワークサービス機能（ＮＳＦ）：基盤ネットワークサービス機能は、ＣＳＥに対してＭ２Ｍノード外のエンティティからのサービスを提供する。このサービスの例は、デバイス管理、位置サービス、デバイス到達可能性状態、デバイストリガリング、などである。
【００４６】
検出および起動（Ｓ＆Ａ）機器：１以上のＭ２Ｍアプリケーションサービスと通信することにより物理環境の検出および／または有効化機能を提供する機器である。検出および起動機器は、Ｍ２Ｍシステムと通信するが、Ｍ２Ｍアプリケーションをホストしない。Ｓ＆Ａ機器は、Ｍ２Ｍデバイスと同じ位置に配置できるが、必ずしもそうでなくともよい。
【００４７】
Ｘ参照ポイント
【００４８】
Ｍ２ＭアプリケーションとＣＳＥとの間の参照ポイントである。Ｘ参照ポイントにより、Ｍ２ＭアプリケーションはＣＳＥが提供するサービスを使用することができ、ＣＳＥはＭ２Ｍアプリケーションと通信することができる。
【００４９】
Ｙ参照ポイント
【００５０】
２つのＣＳＥ間の参照ポイントである。Ｙ参照ポイントにより、ＣＳＥは他のＣＳＥのサービスを使用して、必要な機能を充足することができる。
【００５１】
Ｚ参照ポイント
【００５２】
ＣＳＥと基盤ネットワークとの間の参照ポイントである。Ｚ参照ポイントにより、ＣＳＥは基盤ネットワークが提供するサービス（送信および接続サービスを除く）を用いて、必要な機能を充足することができる。
【００５３】
Ｍ２ＭサービスのＥ２Ｅビューによれば、Ｍ２Ｍアプリケーションサーバ、Ｍ２Ｍデバイス／ゲートウェイ、Ｍ２Ｍサービスプラットフォーム、および送信ネットワークは、Ｅ２Ｅ  Ｍ２Ｍサービスフレームワークにおける別のエンティティとみなすことができる。これらエンティティそれぞれは、異なるビジネスエンティティを表しているとみなすこともできる。例えばＭ２Ｍアプリケーションサービスプロバイダは、Ｍ２Ｍアプリケーションサービスをエンドユーザに対して提供するビジネスエンティティ（例：企業）である。Ｍ２Ｍサービスプロバイダ（ＳＰ）は、Ｍ２Ｍアプリケーションサービスプロバイダが使用してＭ２Ｍデバイス／ゲートウェイからのサービスを実現するＭ２Ｍサービスプラットフォームを提供する他のビジネスエンティティ（例：企業）である。これは検出および起動（Ｓ＆Ａ）機器と統合することができる。基盤ネットワークサービスプロバイダは、有線および／無線技術に基づく基盤送信ネットワークを提供する。例えばＩＥＥＥ、ＩＥＴＦ、３ＧＰＰ、３ＧＰＰ２、ＢＢＦなどが規定するものである。
【００５４】
Ｍ２Ｍサービスフレームワーク内において、Ｍ２Ｍデバイス／ゲートウェイは、異なるＭ２Ｍサービスプロバイダ（ＳＰ）固有のアプリケーションをホストすることができる。例えば、エネルギー管理、ホームセキュリティ、健康監視などのサービスをサポートするＳ＆Ａ機器を有するスマートホームの場合を考える。これらサービス（エネルギー管理、ホームセキュリティ、健康監視など）は、異なるＭ２Ｍサービスプロバイダによって提供される。これら全てのサービスは、単一のホームゲートウェイ上でスマートホーム内においてホストされる。これは、異なるサービスについてＳ＆Ａ機器を用いることによる。このサービスシナリオにおいて、ホームゲートウェイは通常、家屋所有者が所有しており、Ｓ＆Ａ機器はサービス固有である（Ｓ＆Ａ機器を誰が所有しているかはこの文書の主題ではない）。例えばエネルギー管理サービスと健康監視サービスのためのＳ＆Ａ機器は、提供されるサービス固有のものであり、それぞれのＭ２Ｍサービスプロバイダが管理する必要がある（この場合はエネルギー管理サービスプロバイダと健康監視サービスプロバイダ）。同様にＭ２Ｍサービスプロバイダは、他のＭ２Ｍサービスプロバイダから独立したホームゲートウェイ上のそれぞれの動作環境セットを管理したい場合がある。例えばエネルギー管理サービスプロバイダは、ホームゲートウェイにインストールされているエネルギー監視ソフトウェア／ファームウェアを更新したい場合がある。ただしこの更新は、健康監視サービスプロバイダが提供するサービスに対して影響を与えるべきではない。このような様々なサービスセットを提供していると、ホームゲートウェイは、異なるＭ２Ｍサービスプロバイダが提供するサービスを分離するセキュア環境を提供する必要があることになりがちである。
【００５５】
図１は、無線通信ネットワークまたはシステムの例を示す。この無線通信ネットワークは、１以上のベースステーション（ＢＳ）１０５と１０７、１以上の無線デバイス１１０を含む。ベースステーション１０５と１０７は、１以上の無線デバイス１１０に対して、フォワードリンク（ＦＬ）上でシグナル（ダウンリンク（ＤＬ）シグナルとして知られている）を送信することができる。無線デバイス１１０は、１以上のベースステーション１０５と１０７に対して、リバースリンク（ＲＬ）上でシグナル（アップリンク（ＵＬ）シグナルとして知られている）を送信することができる。無線通信システムは、１以上のネットワーク１２５を備え、１以上のベースステーション１０５と１０７を制御することができる。１以上のベースステーションは、無線アクセスネットワークを形成する。ベースステーションは、単独でまたは他のベースステーションとの組み合わせにより無線デバイスに無線アクセスを提供するという性質上、アクセスポイント（ＡＰ）、アクセスネットワーク（ＡＮ）、またはｅＮｏｄｅＢと呼ばれる場合がある。本技術とシステムを実装することができる無線通信システムの例としては、ＣＤＭＡ２０００  １ｘなどのＣｏｄｅ ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ（ＣＤＭＡ）、Ｈｉｇｈ  Ｒａｔｅ  Ｐａｃｋｅｔ  Ｄａｔａ（ＨＲＰＤ）、Ｌｏｎｇ−Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ（ＬＴＥ）、 Ｕｎｉｖｅｒｓａｌ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ（ＵＴＲＡＮ）、Ｗｏｒｌｄｗｉｄｅ  Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ  ｆｏｒ  Ｍｉｃｒｏｗａｖｅ  Ａｃｃｅｓｓ（ＷｉＭＡＸ）などに基づく無線通信システムが挙げられる。
【００５６】
図２は、無線デバイス、ベースステーション、その他無線通信モジュールを実装する無線トランシーバステーションの例を示す。無線ステーションの例として、図１のベースステーションや無線デバイスが挙げられる。ベースステーションや無線デバイスなどの無線ステーション２０５は、プロセッサ電子部品２１０を備える。プロセッサ電子部品２１０は、例えば本文書が提示する技術のうち１以上の方法を実装するマイクロプロセッサである。無線ステーション２０５は、トランシーバ電子部品２１５を備え、例えば１以上のアンテナ２２０などの１以上の通信インターフェースを介して無線シグナルを送受信することができる。無線ステーション２０５は、データを送受信するためのその他通信インターフェースを備えることもできる。実装例において無線ステーション２０５は、１以上の有線通信インターフェースを備え、有線ネットワークと通信することができる。無線ステーション２０５は、データおよび／または命令などの情報を格納するように構成された１以上のメモリ２２５を備える。実装例においてプロセッサ電子部品２１０は、トランシーバ電子部品２１５とメモリ２２５のうち少なくとも一部を備えることができる。
【００５７】
実装例において無線ステーション２０５は、ＣＤＭＡまたはＧＳＭ(登録商標)ベース無線インターフェースに基づき相互通信することができる。実装例において無線ステーション２０５は、直交周波数分割多重（ＯＦＤＭ）インターフェースに基づき相互通信することができる。このインターフェースは、例えば直交周波数分割多重アクセス（ＯＦＤＭＡ）インターフェースを含む。実装例において無線ステーション２０５は、１以上の無線技術を用いて通信することができる。例えばＣＤＭＡ２０００  １ｘ、ＨＲＰＤ、ＷｉＭＡＸ、ＧＳＭ、ＬＴＥ、Ｕｎｉｖｅｒｓａｌ  Ｍｏｂｉｌｅ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｓｙｓｔｅｍ（ＵＭＴＳ）である。
【００５８】
実装例において無線ステーション２０５は、例えば８０２．１１（ａ／ｂ／ｇ／ｎ）インターフェースなどのローカルエリアネットワーク接続を用いて構成することができる。このようなインターフェースを利用することにより、ローカルエリア接続を介してインターネットに対して無線ステーション２０５を接続することができる。例えばユーザは、ケーブルモデムネットワークやＤＳＬネットワークなどの固定ブロードバンドネットワーク経由で無線ローカルエリアネットワーク接続（例えばホームＷｉ−Ｆｉアクセス）を通じてサービスに接続することにより、自身の装置（ＵＥ）を介してサービスにアクセスすることができる。上記無線ステーション２０５を用いて、本文書が開示する技術を実装することができる。同様に、アクセスネットワーク１２５（例：コアまたはバックボーンネットワークまたはこれに接続されたアプリケーションサーバ）と接続された他のエンティティまたはモジュールは、本技術を実装することができる。
【００５９】
ｏｎｅＭ２Ｍシステムに対する配置の第１実施形態
【００６０】
本文書が記載する技術は、ｏｎｅＭ２Ｍ規格に準拠したデバイスと共同するように配置された実装において実施することができる。その現行バージョンを１例として以下に説明する。
【００６１】
本文書において以下の略語を用いる。
【００６２】
ＡＮＤ：アプリケーション専用ノード
【００６３】
ＡＤＮ−ＡＥ：アプリケーション専用ノード上のＡＥ
【００６４】
ＡＥ：アプリケーションエンティティ
【００６５】
Ａｐｐ：アプリケーション
【００６６】
ＡＳＮ：アプリケーションサービスノード
【００６７】
ＡＳＥ−ＡＥ：アプリケーションサービスノードにおいてＣＳＥとともに登録されたアプリケーションエンティティ
【００６８】
ＡＳＮ−ＣＳＥ：アプリケーションサービスノード上のＣＳＥ
【００６９】
ＢＢＦ：ブロードバンドフォーラム
【００７０】
ＣＳＥ：共通サービスエンティティ
【００７１】
ＣＳＦ：共通サービス機能
【００７２】
ＥＦ：イネーブラ機能
【００７３】
ＩＥＥＥ：Ｉｎｓｔｉｔｕｔｅ  ｏｆ  Ｅｌｅｃｔｒｉｃａｌ  ａｎｄ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｅｎｇｉｎｅｅｒｓ
【００７４】
ＩＥＴＦ：Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ
【００７５】
ＩＮ：インフラノード
【００７６】
ＩＮ−ＡＥ：インフラノードにおいてＣＳＥとともに登録されたアプリケーションエンティティ
【００７７】
ＩＮ−ＣＳＥ：インフラノード上のＣＳＥ
【００７８】
ＪＮＩ：Ｊａｖａ(登録商標)  Ｎａｔｉｖｅ  Ｉｎｔｅｒｆａｃｅ
【００７９】
ＬＴＥ：Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ
【００８０】
ＭＡＣ：Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ
【００８１】
Ｍ２Ｍ：マシンツーマシン
【００８２】
ＭＮ：ミドルノード
【００８３】
ＭＮ−ＣＳＥ：ミドルノード上のＣＳＥ
【００８４】
ＮＳＥ：ネットワークサービスエンティティ
【００８５】
ＳＤＯ：規格開発団体
【００８６】
ＳＰ：サービスプロバイダ
【００８７】
ＵＮｅｔ：基盤ネットワーク（Ｍ２Ｍデバイスが存在するネットワーク）
【００８８】
マシンツーマシン（Ｍ２Ｍ）通信において、２つのデバイス（例えばアプリケーションサーバとＭ２Ｍデバイス）は、人間のユーザが明示的に通信を開始することなく、互いに通信することができる。Ｍ２Ｍ通信において、通信が発生する２つのエンドポイントは、異なるネットワーク上に存在する場合がある。一般的なアプリケーションシナリオにおいて、１つのエンドポイントはある期間オフラインになるセンサまたはユーティリティボックスであり、他のエンドポイントはユーティリティ請求サーバやＭ２Ｍサーバなどのような管理ネットワーク上に配置されるアプリケーションサーバである。これら２つのエンドポイント間を行き交うデータパケットは、様々なルーティングオプションによってルーティングすることができる。例えば１つのエンドポイントは、ライセンスされたスペクトル上で（例えばＬｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）またはライセンスされていないスペクトル上で（例えばＷｉ−Ｆｉ）、通信することができる。１つのエンドポイントがある期間オフラインになると（例えば数日あるいは数週間）、最後の通信セッションの間においてパケットがそのエンドポイントへルーティングされた方法は、パケットを現在の通信セッションにおいてルーティングすることができる方法とは、必ずしも一致しない。さらに様々なルーティングオプションを用いると、様々なコストが生じる（例えば帯域幅チャージや通信中のパワー散逸）。
【００８９】
電力その他リソースを節約するため、Ｍ２Ｍデバイスやこれらデバイス上で動作するアプリケーションエンティティのなかには、時間経過にともなって“オフライン”になるものがある。アプリケーションレイヤ通信を再確立するため、これらＭ２Ｍエンティティを通信の前に起動する必要がある。トリガリングを実施する態様や起動されるモジュールもしくはエンティティは、個々のＭ２Ｍデバイスの設定や性能に依拠する。
【００９０】
ｏｎｅＭ２Ｍ、ＥＴＳＩ  ＴＣ  Ｍ２Ｍ、ＴＩＡ  ＴＲ−５０などの団体（Ｍ２Ｍ  ＳＤＯ）が開発しているサービスレイヤ仕様は、広範な市場（垂直）組織によるＭ２Ｍソリューションの効率的な配置をサポートする必要がある。サービスレイヤにフォーカスすると、これら組織は送信ネットワークから独立してエンドツーエンドサービスを把握している。ただし、異なるタイプの送信ネットワークとインターフェースをとるため、サービスレイヤ仕様が確実に効率的に使われるようにする必要がある。送信ネットワークの例としては、３ＧＰＰ、３ＧＰＰ２、ＩＥＥＥ、ＩＥＴＦ、ＢＢＦが規定する無線および有線ネットワークが挙げられるが、これに限らない。
【００９１】
サービスレイヤ仕様において、現在、共通サービスリソースを保持するエンティティに関連付けられた特定のＭ２Ｍデバイスをサービスリクエストが識別してＭ２Ｍリクエストを充足する手段はない。さらに、スリープ中のＭ２Ｍデバイスをトリガリング起動してＭ２Ｍ通信リクエストを充足する必要がある場合、リクエストをルーティングすべきトリガリングデバイスを現行システムが特定する方法は、限られている。本文書が提示する技術は、これらおよびその他課題を解決する。
【００９２】
図３は、ｏｎｅＭ２Ｍシステムがサポートする構成３００の例を示す。図３は、ｏｎｅＭ２Ｍが開発している機能アーキテクチャ仕様の抜粋である。
【００９３】
この例３００において、ＡＤＮ（ＡＤＮ−ＡＥ）上のアプリケーションエンティティ（ＡＥ）は、ＩＮ−ＣＳＥに登録する。同様に非ノードＡＥも、ＩＮ−ＣＳＥに登録する。ＡＤＮ−ＡＥは、ＭＮ−ＣＳＥにも登録する。これら登録は、リモートエンティティ／ノードにおけるＡＥとＣＳＥとの間の登録である。
【００９４】
ＣＳＥは、１以上のＣＳＦのインスタンスである。ＣＳＥは、Ｍ２Ｍアプリケーションが使用し共有することができるＣＳＦのサブセットを提供する。ＣＳＥは、ＵＮｅｔ機能を利用することができ、他のＣＳＥと通信してサービスを充足することができる。ＣＳＥは、Ｍ２Ｍ環境において共通の“サービス機能”セットを備える。このサービス機能は、ｏｎｅＭ２Ｍが規定するＭｃａ参照ポイントやＭｃｃ参照ポイントなどの参照ポイント（図３参照）を介して、他のエンティティに対して公開される。Ｍｃｃ参照ポイントは、ＣＳＥ間の通信フローを定義する。参照ポイントＭｃｎは、基盤ネットワークサービスエンティティにアクセスするために用いられる。ＣＳＥが提供するサービス機能の例は以下である：データ管理、デバイス管理、Ｍ２Ｍサブスクリプション管理、位置サービス、など。ＣＳＥが提供するこれら“サブ機能”は、論理的に共通サービス機能（ＣＳＦ）として把握することができる。共通サービスエンティティ（ＣＳＥ）内部において、ＣＳＦのうちいくつかは固定であり、その他はオプションである。ＣＳＦ内部において、サブ機能のうちいくつかは固定またはオプションである（例えば“デバイス管理”ＣＳＦ内部において、“アプリケーションソフトウェアインストール”、“ファームウェアアップデート”、“ログ”、“監視”などのサブ機能のうちいくつかは、固定またはオプションである）。
【００９５】
ＣＳＦは、Ｍ２Ｍ環境において共通のサービス機能セットであり、ｏｎｅＭ２Ｍなどの相互仕様によって規定される。
【００９６】
図３において、以下の略語を用いる：
【００９７】
非ノードＡＥ：このエンティティは、ＩＮ−ＡＥがアプリケーションサービスプロバイダによってホストされていることを示す。
【００９８】
ノード：少なくとも１つの共通サービスエンティティ（ＣＳＥ）および／またはアプリケーションエンティティ（ＡＥ）を保持する機能エンティティ。ノードは、例えばＭ２Ｍデバイス、ゲートウェイ、サーバ設備などの物理装置内に保持することができる。異なるノード上のＣＳＥは一般に同一ではなく、当該ノードのＣＳＥがサポートするサービスに依拠する。実施形態において、２つのタイプのノードが定義される。１つのノードタイプは、少なくとも１つの共通サービスエンティティおよび／または１以上のｏｎｅＭ２Ｍアプリケーションエンティティを保持する機能エンティティである。このノードをＣＳＥ機能ノードと呼ぶ。もう１つのノードタイプは、１以上のアプリケーションエンティティを保持し共通サービスエンティティを保持しない機能エンティティである。このノードを非ＣＳＥ機能ノードと呼ぶ。ｏｎｅＭ２Ｍアーキテクチャにおいて、ＣＳＥ機能ｏｎｅＭ２Ｍノードは、物理オブジェクト内に保持することができる。例えばＭ２Ｍデバイス、ゲートウェイ、サーバ設備である。非ＣＳＥ機能ｏｎｅＭ２Ｍノードは、例えばセンサ、アクチュエータなどの物理オブジェクト内に保持することができる。ＣＳＥ機能ノードと非ＣＳＥ機能ノードは、Ｍｃａ参照ポイントを介して通信する。
【００９９】
Ｍｃｃ’参照ポイントは、可能な限りＭｃｃ参照ポイントと同様のものであることを意図している。ただしＭ２Ｍ間サービスプロバイダ通信の性質により、いくつかの違いが存在する。
【０１００】
構成２００において、様々なタイプのノードが存在し得る。ノードは実際の物理オブジェクトにマッピングされる場合があるが、必ずしも単一の実際の物理オブジェクトに対してマッピングされる必要はない。以下のノードが存在する：
【０１０１】
アプリケーションサービスノード（ＡＳＮ）：アプリケーションサービスノードは、１つの共通サービスエンティティと少なくとも１つのアプリケーションエンティティを保持するノードである。アプリケーションサービスノードは、Ｍｃｃ参照ポイントを介して、１つのミドルノードまたは１つのインフラノードと通信することができる。物理マッピングの例としては、アプリケーションサービスノードがＭ２Ｍデバイス上に配置される場合が挙げられる。
【０１０２】
アプリケーション専用ノード（ＡＤＮ）：アプリケーション専用ノードは、少なくとも１つのアプリケーションエンティティを保持し、共通サービスエンティティを保持しない。アプリケーション専用ノードは、Ｍｃａ参照ポイントを通じてミドルノードまたはインフラノードと通信する。物理マッピングの例としては、アプリケーション専用ノードが制約Ｍ２Ｍデバイス上に配置される場合が挙げられる。
【０１０３】
ミドルノード（ＭＮ）：ミドルノードは、１つの共通サービスエンティティとゼロ以上のアプリケーションエンティティを保持するノードである。ミドルノードは、Ｍｃｃを介してＩＮまたは他のＭＮと通信し、さらにＭｃｃを介してＩＮ／ＭＮ／ＡＳＮの少なくともいずれかと通信し、またはＭｃａを介してＡＤＮと通信する。物理マッピングの例としては、ミドルノードがＭ２Ｍゲートウェイ上に配置される場合が挙げられる。
【０１０４】
インフラノード（ＩＮ）：インフラノードは、共通サービスエンティティとゼロ以上のアプリケーションエンティティを保持するノードである。インフラノードは、Ｍｃｃ参照ポイントを介して１以上のミドルノードと通信し、および／または１以上のアプリケーションサービスノードと通信する。インフラノードは、Ｍｃａ参照ポイントを介して１以上のアプリケーション専用ノードと通信する。物理マッピングの例としては、インフラノードがＭ２Ｍサーバ設備上に配置される場合が挙げられる。
【０１０５】
Ｍ２Ｍ外部ＩＤ（Ｍ２Ｍ−Ｅｘｔ−ＩＤ）
【０１０６】
Ｍ２Ｍ−Ｅｘｔ−ＩＤは、ＣＳＥ−ＩＤによって識別されるＣＳＥ向けのサービスが基盤ネットワークからリクエストされたとき、Ｍ２Ｍ  ＳＰによって用いられる。
【０１０７】
Ｍ２Ｍ外部ＩＤにより、基盤ネットワークはサービスリクエストについてＣＳＥ−ＩＤと関連付けられたＭ２Ｍデバイスを識別することができる。その意味において、基盤ネットワークはＭ２Ｍ−Ｅｘｔ−ＩＤをターゲットＭ２Ｍデバイスに割り当てられたＵＮｅｔ固有ＩＤにマッピングする。Ｍ２Ｍ  ＳＰは、ＣＳＥ−ＩＤ、Ｍ２Ｍ−Ｅｘｔ−ＩＤ、およびＵＮｅｔ  ＩＤの間の対応関係を維持することができる。
【０１０８】
様々な実施形態において、ＣＳＥ−ＩＤとＭ２Ｍ−Ｅｘｔ−ＩＤとの間の事前準備した対応関係と動的対応関係をともに実装することができる。
【０１０９】
各ＣＳＥ−ＩＤについて、特定の基盤ネットワークＩＤまたはＵＮｅｔｗｏｒｋ−ＩＤについてＭ２Ｍ−Ｅｘｔ−ＩＤが１つのみ存在すべきである。したがって、複数の基盤ネットワークと相互作用するＭ２Ｍ  ＳＰは、同一のＣＳＥ−ＩＤに対応付けられた異なるＭ２Ｍ−Ｅｘｔ−ＩＤを基盤ネットワークごとに有し、基盤ネットワークに対して発するサービスリクエストに対して適切なＭ２Ｍ−Ｅｘｔ−ＩＤを選択する。
【０１１０】
一般に、Ｍ２Ｍ−Ｅｘｔ−ＩＤとＭ２ＭデバイスのＵＮｅｔによるマッピングは、ＵＮｅｔ固有のものである。
【０１１１】
構成例において、ＵＮｅｔプロバイダとＭ２Ｍサービスプロバイダは、ＣＳＥ−ＩＤによって識別される各ＣＳＥに対してＭ２Ｍ−Ｅｘｔ−ＩＤを割り当てるに際して、協調することができる。同時にＵＮｅｔプロバイダは、ＣＳＥをホストするＭ２Ｍデバイスに対して割り当てられた、Ｍ２Ｍ−Ｅｘｔ−ＩＤとＵＮｅｔ固有ＩＤとの間の対応関係を維持する。
【０１１２】
事前準備Ｍ２Ｍ−Ｅｘｔ−ＩＤについて、対応付けられたＣＳＥ−ＩＤとＭ２Ｍ−Ｅｘｔ−ＩＤは、インフラノードにおいて準備することができる。Ｍ２ＭデバイスにおけるＣＳＥは、割り当てられたＭ２Ｍ−Ｅｘｔ−ＩＤを知っておく必要はない。動的Ｍ２Ｍ−Ｅｘｔ−ＩＤについて、基盤ネットワーク固有のＭ２Ｍ−Ｅｘｔ−ＩＤは、フィールドドメイン内の各Ｍ２Ｍデバイスにおいて準備することができる。このＭ２Ｍ−Ｅｘｔ−ＩＤは、ＣＳＥ登録プロセスにおいてＩＮ−ＣＳＥに対して搬送される。
【０１１３】
トリガ受信者ＩＤ（Ｔｒｉｇｇｅｒ−Ｒｅｃｉｐｉｅｎｔ−ＩＤ）
【０１１４】
Ｔｒｉｇｇｅｒ−Ｒｅｃｉｐｉｅｎｔ−ＩＤは、ＵＮｅｔからデバイストリガリングサービスがリクエストされたとき、実行環境上のトリガをルーティングすべきＡＳＮ／ＭＮ−ＣＳＥインスタンスを識別するために用いられる。例えば３ＧＰＰデバイストリガリングを用いる場合、Ｔｒｉｇｇｅｒ−Ｒｅｃｉｐｉｅｎｔ−ＩＤはＡｐｐｌｉｃａｔｉｏｎ−Ｐｏｒｔ−Ｉｄｅｎｔｉｆｉｅｒにマッピングされる。例えば３ＧＰＰ  ２３．６８２規格で規定されているものである。
【０１１５】
事前準備Ｍ２Ｍ−Ｅｘｔ−ＩＤについて、Ｔｒｉｇｇｅｒ−Ｒｅｃｉｐｉｅｎｔ−ＩＤは、Ｍ２Ｍ−Ｅｘｔ−ＩＤおよび関連するＣＳＥ−ＩＤとともにインフラノードにおいて準備される。動的Ｍ２Ｍ−Ｅｘｔ−ＩＤについて、基盤ネットワーク固有のＴｒｉｇｇｅｒ−Ｒｅｃｉｐｉｅｎｔ−ＩＤは、フィールドドメイン内の各Ｍ２Ｍデバイスにおいて準備される。Ｔｒｉｇｇｅｒ−Ｒｅｃｉｐｉｅｎｔ−ＩＤは、ＣＳＥ登録プロセスにおいてＩＮ−ＣＳＥに対して搬送される。
【０１１６】
表１は、Ｍ２Ｍ  ＩＤとその使用属性を例示するリストである。具体的には、表１にリストするように、外部ＩＤはＵＮｅｔプロバイダとＭ２Ｍ  ＳＰとの間で連結して割り当てられ、ＵＮｅｔサービスを利用することを望むＣＳＥに属するＭ２Ｍノードに対して割り当てられ、２つの準備モードを有する。すなわち事前準備モードと動的モードであり、外部ＩＤは対応するＣＳＥの登録プロセスにおいて搬送される。
【０１１７】
Ｍ２Ｍ  ＩＤ  ライフサイクルおよび特徴
【表１】
0006514315.tif 000002
0006514315.tif 000003
0006514315.tif 000004
【０１１８】
リソースタイプＣＳＥＢａｓｅ
【０１１９】
＜ＣＳＥＢａｓｅ＞リソースを用いて、ＣＳＥを表すことができる。この＜ＣＳＥＢａｓｅ＞リソースは、ＣＳＥ上の全てのリソースのルートである。
【０１２０】
図４Ａは、ＣＳＥＢａｓｅリソースに含まれる属性を例示するリストを示す。
【０１２１】
＜ＣＳＥＢａｓｅ＞リソースは、表２に示す子リソースを含む。
【表２】
0006514315.tif 000005
【０１２２】
＜ＣＳＥＢａｓｅ＞リソースは、表３に示す属性を含む。
【表３】
0006514315.tif 000006
【０１２３】
リソースタイプｒｅｍｏｔｅＣＳＥ
【０１２４】
＜ｒｅｍｏｔｅＣＳＥ＞リソースは、登録ＣＳＥに登録されたリモートＣＳＥを表す。＜ｒｅｍｏｔｅＣＳＥ＞リソースは、＜ＣＳＥＢａｓｅ＞の下に直接配置される。反対に登録された各ＣＳＥは、登録ＣＳＥの＜ＣＳＥＢａｓｅ＞における＜ｒｅｍｏｔｅＣＳＥ＞リソースのサブセットとして表すことができる。例えば、ＣＳＥ１がＣＳＥ２を登録するとき、２つの＜ｒｅｍｏｔｅＣＳＥ＞リソースが生成される：１つはＣＳＥ１における＜ＣＳＥＢａｓｅ１＞／＜ｒｅｍｏｔｅＣＳＥ２＞であり、もう１つはＣＳＥ２における＜ＣＳＥＢａｓｅ２＞／＜ｒｅｍｏｔｅＣＳＥ１＞である。２つのリソースの生成は、必ずしも相互登録を示すものではない。＜ＣＳＥＢａｓｅ１＞／＜ｒｅｍｏｔｅＣＳＥ２＞は、上記例においてＣＳＥ２がＣＳＥ１に登録されることを自動的に意味するものではない。
【０１２５】
＜ｒｅｍｏｔｅＣＳＥ＞リソースは、例えば表４に示すような子リソースを含む。
【０１２６】
図４Ｂは、＜ｒｅｍｏｔｅＣＳＥ＞リソースに含まれる子リソースを例示するリストである。
【表４】
0006514315.tif 000007
【０１２７】
実施形態において、＜ｒｅｍｏｔｅＣＳＥ＞リソースは表５にリストする属性を含む。
【表５】
0006514315.tif 000008
【０１２８】
実施形態において、＜ｒｅｍｏｔｅＣＳＥ＞とアナウンスされた＜ｒｅｍｏｔｅＣＳＥ＞は、２つのリソース間で識別できるようにするため、異なるｒｅｓｏｕｒｃｅＴｙｐｅコードを有する。
【０１２９】
ｏｎｅＭ２Ｍシステムにおける実施形態
【０１３０】
変形例を提供して、現行のｏｎｅＭ２Ｍ仕様を実施形態においてどのように変更して本文書の技術を実装できるかを説明する。本例は、アプリケーションエンティティまたは共通サービスエンティティ（ＣＳＥ）からのアナウンスされた属性を生成または削除するためｏｎｅＭ２Ｍが既定する現行手順に対する変更を開示する。さらに、元リソースをホストするＣＳＥが属性をアナウンスまたはアナウンス失効させるための新たな技術を開示する。
【０１３１】
変形例は、属性をアナウンスまたはアナウンス失効させることをサポートする方法を提案する。属性アナウンス／アナウンス失効は、ＵＰＤＡＴＥ動作とＤＥＬＥＴＥ動作を用いることによりサポートされる。
【０１３２】
例１
【０１３３】
１０．２．１８．６  ＡＥとＣＳＥがアナウンス属性を生成開始する手順
【０１３４】
本節は、ＡＥとＣＳＥがアナウンスする属性を生成（属性アナウンス）する手順を記載している。
【０１３５】
オリジネータ：リクエストのオリジネータは、属性アナウンスを開始し、これはＡＥでもＣＳＥでもよい。オリジネータは、元リソースにおけるａｎｎｏｕｎｃｅｄＡｔｔｒｉｂｕｔｅ属性を更新することにより、属性アナウンスをリクエストする：
【０１３６】
オリジネータは、ＵＰＤＡＴＥリクエストを用いることによってアナウンスする必要がある属性を追加することにより、元リソースにおけるａｎｎｏｕｎｃｅｄＡｔｔｒｉｂｕｔｅ属性を更新することができる。ＯＡとマークされた属性のみが、遠隔アナウンスリソースに対してアナウンスすることができる。
【０１３７】
レシーバ：オリジネータが認証されると、レシーバ（例えば元リソースをホストしているＣＳＥ）はリクエストを検証した後にリクエストを許可する。
【０１３８】
リクエストにおいて受信した属性は、ＯＡとマークされていなければ、不正である。
【０１３９】
リクエストにおいて受信した属性は、元リソース構造において存在しなければ、不正である。
【０１４０】
リクエストにおいて受信した属性がａｎｎｏｕｎｃｅｄＡｔｔｒｉｂｕｔｅ属性において既に存在している場合、レシーバはａｎｎｏｕｎｃｅＴｏ属性にリストされている全てのアナウンス先リソースに対してその属性をアナウンスすることができる。これは１０．２．１８．８節の手順にしたがったものである。
【０１４１】
１０．２．１８．８節の手順にしたがって属性のアナウンスが成功すると、レシーバは以下を実施することができる：
【０１４２】
レシーバは、１０．１．３節が規定するように、リクエストを発行したＡＥ／ＣＳＥに対してＵＰＤＡＴＥ応答で応答することができる。アナウンスされた属性の名称は、その応答で提供することができる。
【表６】
0006514315.tif 000009
【０１４３】
例２
【０１４４】
１０．２．１８．７  ＡＥとＣＳＥがアナウンスする属性を削除開始する手順
【０１４５】
本節は、ＡＥとＣＳＥがアナウンスする属性を削除（属性アナウンス失効）する手順を記載している。
【０１４６】
オリジネータ：リクエストのオリジネータは、属性アナウンス失効を開始し、これはＡＥでもＣＳＥでもよい。オリジネータは、以下のように元リソースにおけるａｎｎｏｕｎｃｅｄＡｔｔｒｉｂｕｔｅ属性を更新することにより、属性アナウンス失効をリクエストする：
【０１４７】
オリジネータは、ＵＰＤＡＴＥリクエストを用いることによってアナウンス失効する必要がある属性を削除することにより、元リソースにおけるａｎｎｏｕｎｃｅｄＡｔｔｒｉｂｕｔｅ属性を更新することができる。ＯＡとマークされた属性のみが、遠隔アナウンスリソースに対してアナウンス失効させることができる。
【０１４８】
レシーバ：オリジネータが認証されると、レシーバ（例えば元リソースをホストしているＣＳＥ）はリクエストを検証した後にリクエストを許可する。
【０１４９】
リクエストにおいて受信した属性は、ＯＡとマークされていなければ、不正である。
【０１５０】
ａｎｎｏｕｎｃｅｄＡｔｔｒｉｂｕｔｅ属性において既に存在している属性がリクエストにおいて受信されなかった場合、レシーバはａｎｎｏｕｎｃｅＴｏ属性にリストされている全てのアナウンス先リソースに対してその属性をアナウンス失効させることができる。これは１０．２．１８．９節の手順にしたがったものである。
【０１５１】
１０．２．１８．９節の手順にしたがって全属性のアナウンス失効が成功すると、レシーバは以下を実施することができる：
【０１５２】
レシーバは、１０．１．３節が規定するように、リクエストを発行したＡＥ／ＣＳＥに対してＵＰＤＡＴＥ応答で応答することができる。アナウンス失効する属性の名称は、その応答で提供することができる。
【表７】
0006514315.tif 000010
【０１５３】
例３
【０１５４】
１０．２．１８．８  元リソースをホストするＣＳＥが属性をアナウンスする手順
【０１５５】
本節は、元リソースをホストするＣＳＥが遠隔アナウンスリソース（すなわち属性アナウンス）においてアナウンスする属性を生成する手順を記載している。
【０１５６】
オリジネータ：このリクエストのオリジネータは、元リソースをホストしているＣＳＥである。オリジネータは、１０．１．３節が規定するように、ＵＰＤＡＴＥリクエストを用いることにより、アナウンスリソースにおいてアナウンスする属性を生成するようリクエストすることができる。
【０１５７】
レシーバ：オリジネータが認証されると、レシーバ（アナウンスするリソースをホストするＣＳＥ）は、リクエストを検証した後、リクエストを許可することができる。レシーバは以下を実施することができる：
【０１５８】
１０．１．３節の部分アドレシング手順にしたがって、アナウンスリソースにおいてアナウンスする属性を生成する。
【０１５９】
１０．１．３節にしたがって、ＵＰＤＡＴＥ応答でオリジネータに対して応答する。
【０１６０】
オリジネータは、レシーバから応答を受け取った後、以下のステップを実施することができる：アナウンスされた属性が生成された場合、ａｎｎｏｕｎｃｅｄＡｔｔｒｉｂｕｔｅ属性が更新され、アナウンスされた属性の属性名が含まれるようになる。
【０１６１】
ａｎｎｏｕｎｃｅｄＡｔｔｒｉｂｕｔｅ属性において新たにアナウンスする属性について、オリジネータはその値がアナウンスリソースにおいて同期されることにつき責任を有する。これは、１０．１．３節のＵＰＤＡＴＥ動作を用いることによる。
【表８】
0006514315.tif 000011
【０１６２】
例４
【０１６３】
１０．２．１８．９  元リソースホストＣＳＥが属性をアナウンス失効する手順
【０１６４】
本節は、元リソースをホストしているＣＳＥが遠隔アナウンスリソースにおいてアナウンスされた属性を削除する手順を記載している（すなわち属性アナウンス失効）。
【０１６５】
オリジネータ：このリクエストのオリジネータは、元リソースをホストしているＣＳＥである。オリジネータは、１０．１．４節が規定するＤＥＬＥＴＥリクエストを用いることにより、アナウンスされた属性を削除することを要求できる。
【０１６６】
レシーバ：オリジネータが認証されると、レシーバ（アナウンスされたリソースをホストしているＣＳＥ）はリクエストを検証した後、リクエストを許可することができる。レシーバは以下を実施することができる：
【０１６７】
１０．１．４節の部分アドレシング手順にしたがってアナウンス失効された属性を削除する。
【０１６８】
１０．１．４節の適切なＤＥＬＥＴＥ応答でオリジネータに対して応答する。
【０１６９】
オリジネータはレシーバから応答を受け取った後、以下のステップを実施することができる：アナウンス失効された属性が削除された場合、ａｎｎｏｕｎｃｅｄＡｔｔｒｉｂｕｔｅ属性を更新して、アナウンス失効した属性の属性名を削除することができる。
【表９】
0006514315.tif 000012
【０１７０】
現行ｏｎｅＭ２Ｍ規格に対する変形
ｏｎｅＭ２Ｍにおける部分アドレシングのサポートを提案する。部分アドレシングを提案して、ＵＰＤＡＴＥおよびＤＥＬＥＴＥ動作を用いることによりサポートする。
【０１７１】
例５
【０１７２】
８．１．１  説明
【０１７３】
図５は、手順内の情報交換をカバーする通信の一般的フローを示す図である。これはリクエストと応答の方式を用いることに基づいている。この方式は以下のような通信に適用される：
【０１７４】
ＡＥとＣＳＥとの間（Ｍｃａ参照ポイント）；および
【０１７５】
ＣＳＥ間（Ｍｃｃ参照ポイント）
【０１７６】
通信は、リクエストメッセージの動作にしたがって、ＡＥまたはＣＳＥいずれかによって開始される。
【０１７７】
８．１．２  応答
【０１７８】
オリジネータからのリクエストは、以下の情報を含む：
【０１７９】
ｔｏ：動作のターゲットリソースまたはターゲット属性のＵＲＩ。ｔｏ情報は９．３．１節に合致する。
【０１８０】
ｔｏターゲットリソースまたはターゲット属性は、オリジネータが知る必要がある。これは事前準備によってまたはディスカバリによって知ることができる。
【０１８１】
用語ターゲットリソースは、特定の動作が対処するリソースのことを指す。例えばリソース“ｅｘａｍｐｌｅ”に対するＣｒｅａｔｅ動作のパラメータは、“／ｍ２ｍ．ｐｒｏｖｉｄｅｒ．ｃｏｍ／ｅｘａｍｐｌｅＢａｓｅ”となる。同じリソース“ｅｘａｍｐｌｅ”に対するＲｅｔｒｉｅｖｅ動作のパラメータは、“／ｍ２ｍ．ｐｒｏｖｉｄｅｒ．ｃｏｍ／ｅｘａｍｐｌｅＢａｓｅ／ｅｘａｍｐｌｅ”となる。ＲＥＴＲＩＥＶＥ動作で特定の属性を対処する際に用いるとき、上述の例における“ｃｏｎｔａｉｎｅｒ”属性のパラメータは、“／ｍ２ｍ．ｐｒｏｖｉｄｅｒ．ｃｏｍ／ｅｘａｍｐｌｅＢａｓｅ／ｅｘａｍｐｌｅ／ｃｏｎｔａｉｎｅｒ”となる。
【０１８２】
ｆｒ：オリジネータを表すＩＤ
【０１８３】
レシーバはｆｒ情報を用いて、オリジネータＩＤが特権アクセスできるかチェックすることができる。
【０１８４】
ｃｎ：送信するリソースコンテンツ
【０１８５】
ｏｐ：実行すべき動作：Ｃｒｅａｔｅ（Ｃ）、Ｒｅｔｒｉｅｖｅ（Ｒ）、Ｕｐｄａｔｅ（Ｕ）、Ｄｅｌｅｔｅ（Ｄ）。
【０１８６】
ｏｐ情報は、レシーバにおいて実行すべき動作を示すことができる。
【０１８７】
Ｃｒｅａｔｅ（Ｃ）：ｔｏパラメータで処理できる新しいリソースが生成される。
【０１８８】
Ｒｅｔｒｉｅｖｅ（Ｒ）：既存のｔｏ処理可能リソースが読み取られ、オリジネータに対して提供される。
【０１８９】
Ｕｐｄａｔｅ（Ｕ）：既存のｔｏ処理可能リソースのコンテンツがｃｎパラメータの新たなコンテンツで置き換えられる。ｃｎパラメータの属性がターゲットリソースにおいて存在しない場合、その属性は割り当てられた属性で生成される。
【０１９０】
Ｄｅｌｅｔｅ（Ｄ）：既存のｔｏ処理可能リソースとその全てのサブリソースが、リソースストレージから削除される。特定の属性を処理するｔｏパラメータについて、その属性はリソースストレージから削除される。
【０１９１】
Ｎｏｔｉｆｙ（Ｎ）：レシーバに対する情報、レシーバにおける処理はオリジネータによって示されない。
【０１９２】
以下の動作について、ｔｙ情報をリクエスト内に含めることができる：
【０１９３】
Ｃｒｅａｔｅ：ｔｙは生成するリソースのタイプである。
【０１９４】
ｃｎ：送信するリソースコンテンツ。
【０１９５】
以下の動作について、ｃｎ情報をリクエスト内に含めることができる：
【０１９６】
Ｃｒｅａｔｅ：ｃｎは新しいリソースのコンテンツである。リソースタイプタグは表９．２−１のものである。
【０１９７】
Ｕｐｄａｔｅ：ｃｎは既存リソースにおいて置き換えるコンテンツである。ｃｎは、ｔｏパラメータが指定するリソースにおいて生成する属性について、対応する値とともに新たな属性を含むこともできる。
【０１９８】
Ｒｅｔｒｉｅｖｅ：ｃｎは、ディスカバリ目的で適用されるフィルタである。
【０１９９】
Ｎｏｔｉｆｙ：ｃｎは通知情報である。
【０２００】
ｃｎ情報は空であってもよい。
【０２０１】
その他用いることができる情報は以下の通りである：
【０２０２】
ｎｍ：生成するリソースのオプション名。
【０２０３】
名称の使用例としては、新たに生成するリソースのＩＤとしてＣｒｅａｔｅリソースのオリジネータが使用希望する名称が挙げられる。名称“ｍｙＣｏｎｔａｉｎｅｒ”を有するｃｏｎｔａｉｎｅｒを生成する際に、リクエストはパラメータｎｍの値を“ｍｙＣｏｎｔａｉｎｅｒ”とし、生成されるリソースは：／＜ＳＣＥＢａｓｅ＞／ｍｙＣｏｎｔａｉｎｅｒである。
【０２０４】
ｏｔ：メッセージが構築されたときのオプション送信元タイムスタンプ。
【０２０５】
送信元タイムスタンプの使用例としては以下が挙げられる：動作を測定および有効化する（例：メッセージログ、相関、メッセージ優先順位付け／スケジューリング、パフォーマンス受諾リクエスト、変更、など）、パフォーマンスを測定する（配信および処理レイテンシ、閉ループレイテンシ、ＳＬＡ、分析、など）。
【０２０６】
ｒｑｅｔ：オプションリクエストメッセージ期限タイムスタンプ。
【０２０７】
リクエスト期限タイムスタンプの使用例は以下を含む：リクエストが古くなって値の意味をなさず期限切れになるとき（遅延耐性を含む）を示す、メッセージスケジューリング／優先順位付けを通知する。リクエストが特定時刻にリクエスト期限タイムスタンプをセットし、リクエストを現在処理しているＣＳＥではないホストＣＳＥにおける動作をリクエストが要求する場合、現在のＣＳＥはリクエスト期限タイムスタンプまでリクエストをホストＣＳＥに対して配信し続けようとする。これは準備したポリシにしたがってなされる。
【０２０８】
ｒｓｅｔ：オプション結果メッセージ期限タイムスタンプ。
【０２０９】
結果期限タイムスタンプの使用例は以下を含む：結果が古くなって値の意味をなさず結果メッセージが期限切れになるとき（遅延耐性を含む）を示す、メッセージスケジューリング／優先順位付けを通知する。最大許可総リクエスト／結果メッセージシーケンスラウンドトリップ期限をセットするために用いることができる。
【０２１０】
ｒｔ：オプション応答メッセージタイプ：発行したリクエストに対する応答内容と、いつ応答をオリジネータに対して送信したかを示す。
【０２１１】
Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ：ローカルＣＳＥが応答を受け取った場合、ローカルＣＳＥはＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔで受け取った後に応答する。これは、ローカルＣＳＥがさらにリクエストを処理することを確認するものである。
【０２１２】
Ｒｅｓｕｌｔ：ローカルＣＳＥが応答を受け取った場合、ローカルＣＳＥは要求された動作が完了すると要求された動作の結果を応答する。
【０２１３】
Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔにセットする応答タイプの使用例：通信時間とエネルギー消費を最小化するように最適化されたオリジネータは、ローカルＣＳＥに対して応答を通知しようとし、リクエストが受け取られたか否かの確認応答を取得する。その後、オリジネータは低パワー消費モードへスイッチし、後時刻において要求した動作の結果を取得する。
【０２１４】
ｒｄ：オプション結果メッセージ宛先。
【０２１５】
ローカルＣＳＥ：ローカルＣＳＥは、受け取ったリクエストに対する応答において、リクエストのステータスと要求した動作の結果にアクセスするために後時刻において用いることができる参照情報を含む。
【０２１６】
オリジネータ：要求した動作の結果は、オリジネータに対する通知として送信する必要がある。
【０２１７】
ローカルＣＳＥに対してセットする結果宛先の使用例は以下を含む：結果コンテンツが非常に大きい場合、または結果が非同期で集約されたターゲットグループからの複数のコンテンツ部分を含む場合。
【０２１８】
ｒｃ：オプション結果メッセージコンテンツ：要求した動作の結果の期待されるコンポーネントを示す。リクエストのオリジネータは、動作の結果を全く必要としない場合がある。これはｒｃ情報に示すことができる。ｒｃを正確にセットすることができるかは、ｏｐが指定する要求動作に依拠する。ｒｃの値として取り得るものは以下である：
【０２１９】
“ｒｅｓｏｕｒｃｅ”：要求したリソース表現のみがコンテンツとして戻される。要求したリソースの他リソースに対するリンクは言及されない。これはデフォルト値である。
【０２２０】
“ｒｅｓｏｕｒｃｅ；ｌｉｎｋｓ”：他リソースに対する全てのリンクとともに（取得したリンクの最大数によって制限され得る）、要求したリソースの表現が、コンテンツとして戻される。
【０２２１】
“ｌｉｎｋｓ”：要求されたリソースの他リソースに対するリンクのみが（取得したリンクの最大数によって制限され得る）、要求したリソースの実物なしで、コンテンツとして戻される。
【０２２２】
“ｎｏｔｈｉｎｇ”：応答のコンテンツとして何も戻されない。
【０２２３】
“ｒｅｓｕｌｔ−ｎｏｔｉｆｉｃａｔｉｏｎ”：動作が完了すると通知が戻される。
【０２２４】
注：ｒｃについてどのような設定が可能かについての詳細は、後に要求可能な特定の動作が定義されたとき、追加することができる（例：ＡＥを登録する、ｃｏｎｔａｉｎｅｒのコンテンツを変更する、など）。
【０２２５】
ｒｐ：オプション応答持続性：応答を含むアドレスが持続する期間を示す。
【０２２６】
応答持続の使用例は以下を含む：非同期で集約した応答コンテンツを分析処理するのに十分な持続期間を要求する。結果期限タイムスタンプが指定された場合、応答持続は応答期限を超えて存続すべきである。
【０２２７】
ｒｉ：リクエストＩＤ
【０２２８】
リクエストＩＤの使用例は、リクエストと多数の受信した応答との間の相関を可能にすることを含む。
【０２２９】
ｏｅｔ：オプション動作実行時間：ターゲットＣＳＥによって特定の動作ｏｐが実行される時間を示す。ターゲットＣＳＥは、動作実行時間から開始する動作実行時間がセットされたリクエストの特定の動作を実行する。実行時間が既に過ぎるかまたはセットされていない場合、指定された動作は、セットされたリクエスト期限に達していない限り、即時実行される。
【０２３０】
動作実行時間の使用例は、フローの非同期分散を含む。これは動作実行時刻において同期実行される。
【０２３１】
ＮＯＴＥ４：時刻ベースフローは、ＣＳＥにおいて利用可能な時刻サービスによってはサポートできない場合がある。
【０２３２】
ｅｃ：オプションイベントカテゴリ：このリクエストを取り扱うために用いるべきイベントカテゴリを示す。イベントカテゴリは、遠隔ホストされているリソースに対してアクセスするリクエストがＣＭＤＨ  ＣＳＦにおいてどのように処理されるかに影響する。ＣＭＤＨを介する接続の選択とスケジューリングは、イベントカテゴリを区別するポリシによって制御される。
【０２３３】
特定値Ｘにセットされた“イベントカテゴリ”の使用例は以下を含む：リクエストがローカルＣＳＥとは異なるホストＣＳＥ上で実行する動作を要求しているとき、リクエストはホストＣＳＥへの途中で現在リクエストを処理しているＣＳＥに格納される。これは、そのイベントカテゴリＸについて準備したポリシによって通信リンクを使用してホストＣＳＥに至る過程の次のＣＳＥに到達することが許可されるまで、またはリクエスト期限タイムスタンプが超過するまでである。
【０２３４】
ｄａ：オプション配信集約ｏｎ／ｏｆｆ：＜ｄｅｌｉｖｅｒｙ＞リソースのＣＲＵＤ動作を用いて、１以上の元リクエストを同じターゲットＣＳＥへ転送することを表す。
【０２３５】
ｄａはオプションであるので、リクエスト内に存在しない場合のデフォルト値が存在する。このパラメータは、Ｍｃａを介してＡＥに公開されない場合がある。
【０２３６】
配信集約をｏｎにセットする使用例は以下を含む：リクエストを処理するＣＳＥは、ターゲットＣＳＥへの途中の次のＣＳＥ上で＜ｄｅｌｉｖｅｒｙ＞リソースのＣＲＥＡＴＥを要求することにより、同じターゲットＣＳＥに対するリクエストの集約を用いることができる。
【０２３７】
ｇｉｄ：オプショングループリクエストＩＤ：グループメンバそれぞれに対して広がるグループリクエストに対して追加されるＩＤである。
【０２３８】
ｆｃ：オプションフィルタ条件：フィルタリングした取得動作の条件を表８．１．２−１に示す。
【表１０】
0006514315.tif 000013
【０２３９】
ＨＴＴＰクエリにおけるフィルタ条件の使用例は以下を含む：ＨＴＴＰ  ＧＥＴ動作をリクエストし、リクエスト自身のクエリ部分のフィルタを適用することができる：
【０２４０】
GET /root?label=one&label=two&createdBefore=2014-01-01T00:00:00&limit=128
【０２４１】
例えば以下の論理条件に合致する最大１２８個のリソースを発見できる：ｃｒｅａｔｅｄＢｅｆｏｒｅ＜２０１４−０１−０１Ｔ００：００：００  ＡＮＤ  （ｌａｂｅｌ＝ｏｎｅ  ＯＲ  ｌａｂｅｌ＝ｔｗｏ）
【０２４２】
リクエストが配信されると、レシーバはリクエストを分析してターゲットリソースを判定する。
【０２４３】
ターゲットリソースが他のＭ２Ｍモジュールによって処理されている場合、レシーバはリクエストを適切にルーティングする。
【０２４４】
ターゲットリソースがレシーバによって処理されている場合、以下を実施できる：
【０２４５】
ｔｏアドレスリソースの存在をチェックする。
【０２４６】
表９．２−１のタグ値でリソースタイプを識別する。
【０２４７】
ｆｒオリジネータが要求された動作を実施する権限をチェックする。
【０２４８】
上述のように提供されたリクエストパラメータにしたがって要求された動作（ｃｎコンテンツが提供される場合はこれを用いて）を実施する。
【０２４９】
リクエスト結果コンテンツに応じて、動作結果が成功または失敗したことを示して、オリジネータに対して応答する。特定の場合において（例：バインディングプロトコルの制約またはアプリケーション指示に基づき）、応答を回避できる。
【０２５０】
オリジネータリクエストから開始したメッセージフロー手順は、以下の場合に完了したとみなすことができる：
【０２５１】
ｒｑｅｔ（リクエスト期限タイムスタンプ）にしたがってリクエストメッセージが期限切れになった。
【０２５２】
応答メッセージがオリジネータに配信された。
【０２５３】
８．１．２．１  リクエストメッセージパラメータの概要
【０２５４】
表８．１．２．１−１は、８．１．２節のリクエストメッセージのパラメータの概要である。Ｃ、Ｒ、Ｕ、Ｄ、Ｎ動作の違いを示す。“Ｍ”は固定を示す。“Ｏ”はオプションであることを示す。“Ｎ／Ａ”は“適用しない”を示す。
【表１１】
0006514315.tif 000014
0006514315.tif 000015
【０２５５】
例６
【０２５６】
８．１．３  成功動作
【０２５７】
要求した動作が成功した場合、そのリクエストのレシーバからオリジネータに対する応答は以下の情報を含む：
【０２５８】
ｔｏ：オプション。オリジネータのＩＤ。非ブロックリクエストによりトリガされた動作の結果を応答する場合、“ｒｄ”情報を用いることができる。
【０２５９】
ｆｒ：オプション。レシーバのＩＤ。
【０２６０】
ｒｓ：動作結果：例：Ｏｋａｙ、Ｏｋａｙ  ａｎｄ  Ｄｏｎｅ；Ｏｋａｙ  ａｎｄ  Ｓｃｈｅｄｕｌｅｄ；Ｏｋａｙ  ａｎｄ  Ｉｎ  Ｐｒｏｇｒｅｓｓ、など。
【０２６１】
ｃｎ：送信または生成するオプションリソースコンテンツ（オプション）。
【０２６２】
メタ情報は以下を含む：
【０２６３】
ｏｔ：メッセージが構築されたときのオプション元タイムスタンプ。
【０２６４】
ｒｓｅｔ：オプション結果期限タイムスタンプ。レシーバは、リクエストメッセージにセットされている場合は結果期限タイムスタンプを繰り返し、あるいは結果期限タイムスタンプそのものをセットする。
【０２６５】
レシーバが結果期限タイムスタンプをセットする例：配信時刻の値が変化するレシーバコンテキストに依拠する場合。例：速度に基づく航空機位置の結果メッセージデッドライン。
【０２６６】
ｒｉ：リクエストＩＤ
【０２６７】
レスポンスのｒｉは、対応するリクエストのｒｉと合致する。
【０２６８】
ｃｓ：オプション、状態コード（例：認証タイムアウトなど）。
【０２６９】
ｒａ：オプション、エンドノード応答の一時ストレージのアドレス。
【０２７０】
ｃｎ情報は、以下の場合において応答内に含まれる：
【０２７１】
Ｃｒｅａｔｅ：ｃｎは、生成したリソースのアドレスおよび／またはコンテンツである。
【０２７２】
Ｕｐｄａｔｅ：ｃｎは、既存リソースにおいて置き換えるコンテンツである。ｃｎは、新たに生成した属性とその値である。
【０２７３】
Ｄｅｌｅｔｅ：ｃｎは、実際に削除するコンテンツである。
【０２７４】
ｃｎ情報は、以下の場合において応答内に含まれる：
【０２７５】
Ｒｅｔｒｉｅｖｅ：ｃｎは、取得したリソースコンテンツまたは発見したリソースの集約したコンテンツである。
【０２７６】
８．１．４  失敗動作
【０２７７】
リクエストのレシーバからリクエストのリジネータに対する応答は、要求した動作が失敗した場合、以下の情報を含む：
【０２７８】
ｔｏ：オプション。オリジネータのＩＤ。非ブロックリクエストによりトリガされた動作の結果を応答する場合、“ｒｄ”情報を用いることができる。
【０２７９】
ｆｒ：オプション。レシーバのＩＤ。
【０２８０】
ｒｓ：動作結果：例：Ｎｏｔ  Ｏｋａｙ。
【０２８１】
ｃｎ：オプション、状態コード（例：認証、タイムアウト、など）。
【０２８２】
メタ情報は以下を含む：
【０２８３】
ｏｔ：メッセージが構築されたときのオプション元タイムスタンプ。
【０２８４】
ｒｓｅｔ：オプション結果期限タイムスタンプ。
【０２８５】
ｒｉ：リクエストＩＤ
【０２８６】
レスポンスのｒｉは、対応するリクエストのｒｉと合致する。
【０２８７】
ｃｓ：オプション、状態コード（例：認証タイムアウトなど）。
【０２８８】
８．１．５  応答メッセージパラメータの概要
【０２８９】
表８．１．５−１は、応答メッセージについての８．１．１節と８．１．３節が規定するパラメータの概要である。成功したＣ、Ｒ、Ｕ、Ｄ、Ｎ動作、および失敗動作の違いを示す。“Ｍ”は固定を示す。“Ｏ”はオプションであることを示す。“Ｎ／Ａ”は“適用しない”を示す。
【表１２】
0006514315.tif 000016
【０２９０】
例７
【０２９１】
１０．１．３  ＵＰＤＡＴＥ（Ｕ）
【０２９２】
ＵＰＤＡＴＥ動作は、ターゲットリソースにおいて格納している任意の属性の情報を更新するために用いることができる。更新はタイミングよく実施する必要がある。例えば“ＥｘｐｉｒａｔｉｏｎＴｉｍｅ”情報更新に失敗すると、リソースを削除することになる。オリジネータＣＳＥまたはＡＥは、リクエストメッセージ内に属性とその値を含めることにより、ターゲットリソースにおいて特定の属性の更新または生成をリクエストすることができる。
【０２９３】
オリジネータは、ＵＰＤＡＴＥリクエストメッセージを用いることにより、ターゲットリソースにおける任意属性の更新をリクエストする。オリジネータは、更新する必要がある属性の新たな（提案する）値を送信する。ＵＰＤＡＴＥ動作により、特定のリソースタイプについて、“ＲＷ”（Ｒｅａｄ  Ｗｒｉｔｅ）指定されている属性（９．６節に規定）を変更することができる。
【０２９４】
オリジネータは、ＵＰＤＡＴＥリクエストメッセージを用いることにより、ターゲットリソースにおいて属性を生成するようリクエストする。オリジネータは、特定のリソースタイプについて、“ＲＷ”（Ｒｅａｄ  Ｗｒｉｔｅ）指定されている生成すべき属性（９．６節に規定）の名称および関連する値を、リクエストメッセージで送信することができる。
【０２９５】
リクエストメッセージに含まれる情報について８．１．２節  参照
【０２９６】
レシーバは、オリジネータが認証されると、アドレスリソースの存在を検証し（提供される属性とこれを変更する権限の妥当性）、提供される属性を更新し、８．１．３節にしたがってオリジネータに対して動作結果の応答メッセージを返信する。提供された属性が存在しない場合、アドレスリソースの存在を検証した後、レシーバは提供された属性とこれを生成する権限を検証する。検証成功した場合、レシーバは提供された属性を関連する値とともに生成し、８．１．３節にしたがって動作結果をオリジネータに対して応答メッセージを返信する。
【０２９７】
図６は、リソースを取得する手順の例を示す。ステップ００１において、オリジネータはリソースの取得をリクエストする。ステップ００２において、レシーバはリクエストを処理する。ステップ００３において、レシーバは取得リクエストに対して応答メッセージで応答する。
【０２９８】
図７は、リソースを更新する手順の例である。ステップ００１において、オリジネータはＵＰＤＡＴＥリクエストメッセージ内で以下の情報を送信する。
【０２９９】
ｏｐ：Ｕ（Ｕｐｄａｔｅ）
【０３００】
ｔｏ：ターゲットリソースのＵＲＩ
【０３０１】
ｆｒ：オリジネータのＩＤ（ＡＥまたはＣＳＥ）
【０３０２】
ｃｎ：ターゲットリソースにおいて更新または生成する属性に関する情報。ｃｎパラメータにおける属性の名称と関連する更新値または割当値。
【０３０３】
ステップ００２において、レシーバはオリジネータがターゲットリソースを変更する適切な権限を有しているかを検証する。検証成功すると、レシーバはリソースを要求されたように更新する。提供された属性が存在しない場合、レシーバはオリジネータがターゲットリソースにおいて属性を生成する適切な権限を有しているかを検証する。検証成功した場合、レシーバは当該リソースにおいて関連する値で属性を生成する。
【０３０４】
ステップ００３において、レシーバは以下の情報を含む応答メッセージを返信する：
【０３０５】
ｔｏ：オプション。オリジネータのＩＤ。非ブロックリクエストによってトリガされた動作の結果を応答する場合、ｒｄ情報を用いることができる。
【０３０６】
ｆｒ：オプション。レシーバのＩＤ。
【０３０７】
ｒｓ：動作結果
【０３０８】
ｃｎ：オプション。置換または生成するコンテンツ。
【０３０９】
一般例外：
【０３１０】
ｔｏ情報におけるターゲットリソースが存在しない。レシーバはエラーを応答する。
【０３１１】
オリジネータは、レシーバにおいてリソースを変更しまたは属性を生成する権限を有していない。レシーバはエラーを応答する。
【０３１２】
ｃｎにおいて提供された情報がレシーバによって受け取られなかった。レシーバはエラーを応答する。
【０３１３】
例８
【０３１４】
１０．１．４  ＤＥＬＥＴＥ（Ｄ）
【０３１５】
オリジネータＣＳＥまたはＡＥは、ＤＥＬＥＴＥ動作を用いて、レシーバＣＳＥにおけるリソースを削除することができる。
【０３１６】
オリジネータＣＳＥまたはＡＥは、ＤＥＬＥＴＥ動作を用いて、レシーバＣＳＥにおけるターゲットリソースから特定の属性を削除することができる。
【０３１７】
ＤＥＬＥＴＥ手順は、ターゲットリソースの関連する全情報を削除することを含む。
【０３１８】
オリジネータは、ＤＥＬＥＴＥリクエストメッセージを用いることにより、リソースまたは属性を削除するようリクエストする。
【０３１９】
レシーバは、オリジネータが認証されると、要求されたリソースまたは属性の存在と、そのリソースまたは属性を削除する権限を、検証する。
【０３２０】
図８は、リソースまたは属性を削除する手順の例を示す。ステップ００１において：オリジネータはレシーバに対してＤＥＬＥＴＥリクエストメッセージを送信する。
【０３２１】
ｏｐ：Ｄ（Ｄｅｌｅｔｅ）
【０３２２】
ｔｏ： ターゲットリソースまたは属性のＵＲＩ
【０３２３】
ｆｒ：オリジネータのＩＤ（ＡＥまたはＣＳＥ）
【０３２４】
ステップ００２において、レシーバは要求されたリソースまたは属性の存在、およびオリジネータがリソース／属性を削除する適切な権限を有しているかを、検証する。リソースの削除について、検証成功すると、レシーバは子リソースをチェックし、全ての子リソースと親リソースの関連する関連する参照を削除し、リソース自身を削除する。属性の削除について、検証成功すると、レシーバはアドレス属性を削除する。
【０３２５】
ステップ００３において、レシーバは以下の情報を含む応答メッセージを返信する：
【０３２６】
ｔｏ：オプション。オリジネータのＩＤ。非ブロックリクエストによってトリガされた動作の結果を応答する場合、ｒｄ情報を用いることができる。
【０３２７】
ｆｒ：オプション。レシーバのＩＤ。
【０３２８】
ｒｓ：動作結果
【０３２９】
一般例外：
【０３３０】
ｔｏ情報のターゲットリソース／属性が存在しない。レシーバはエラーを応答する。
【０３３１】
オリジネータは、レシーバにおけるリソース／属性を削除する権限を有していない。レシーバはエラーを応答する。
【０３３２】
上述の変形例は、現行のｏｎｅＭ２Ｍ規格の特定セクションをどのように変更できるかの例を提供した。実施形態において、本文書が開示する技術の実装を示した。上述の変形例は、ｏｎｅＭ２Ｍが既定するリソースまたは属性メッセージを交換する現行手順に対する変更を開示している。これはＲｅｑｕｅｓｔ、Ｒｅｔｒｉｅｖｅ、Ｒｅｓｐｏｎｓｅ、Ｄｅｌｅｔｅ、Ｕｐｄａｔｅメッセージを含む。上述の変形例は、デバイスに対して送信しこれを受信したデバイスが解釈実行することにより、メッセージパラメータおよびパラメータを使用する方法に対する変更を提供している。
【０３３３】
上記において参照するｏｎｅＭ２Ｍ規格は、実施形態を説明するための例として用いたものであり、本技術の範囲を限定するものではない。
【０３３４】
図９に示すように、実施形態において、Ｍ２Ｍ通信システムにおけるアナウンスされたリソースから情報を取得する方法６００は、アナウンスするリソースのアドレスを指定するとともにアナウンスするリソースのＩＤを含めることにより、情報取得リクエストを発行するステップ（６０２）；前記情報取得リクエストに応じて情報応答を受信するステップ（６０４）；前記受信した情報応答をローカルで処理するかまたは他Ｍ２Ｍデバイスに処理させるため転送するかを選択するステップ（６０６）；を有する。
【０３３５】
図１０に示すように、実施形態において、Ｍ２Ｍ通信システムにおけるアナウンスされたリソースから情報を取得する装置７００は、アナウンスするリソースのアドレスを指定するとともにアナウンスするリソースのＩＤを含めることにより、情報取得リクエストを発行するモジュール７０２；前記情報取得リクエストに応じて情報応答を受信するモジュール７０４；前記受信した情報応答をローカルで処理するかまたは他Ｍ２Ｍデバイスに処理させるため転送するかを選択するモジュール７０６；を備える。
【０３３６】
図１１に示すように、実施形態において、Ｍ２Ｍ通信システムにおけるアナウンスされたリソースを削除する方法８００は、削除する属性が省略されたリソースの属性のリストを生成するステップ（８０２）；前記削除する属性をホストするＭ２Ｍノードに対して前記リストを送信するステップ（８０４）；を有する。方法８００は、図１〜図１０で説明した技術を用いることができる。
【０３３７】
図１２に示すように、実施形態において、Ｍ２Ｍ通信システムにおけるアナウンスされたリソースを削除する装置９００は、削除する属性が省略されたリソースの属性のリストを生成するモジュール９０２；前記削除する属性をホストするＭ２Ｍノードに対して前記リストを送信するモジュール９０４；を備える。
【０３３８】
図１３に示すように、実施形態において、Ｍ２Ｍ通信システムにおけるアナウンスされたリソースを生成する方法１０００は、元Ｍ２Ｍノードが生成した属性がリストされた生成リクエストを発行するステップ（１００２）；前記発行された生成リクエストに対する許可応答を受信するステップ（１００４）；を有する。方法１０００は、図１〜図１０で説明した技術を用いることができる。
【０３３９】
図１４に示すように、実施形態において、Ｍ２Ｍ通信システムにおけるアナウンスされたリソースを生成するシステム１１００は、元Ｍ２Ｍノードが生成した属性がリストされた生成リクエストを発行するモジュール１１０２；前記発行された生成リクエストに対する許可応答を受信するモジュール１１０４；を備える。
【０３４０】
Ｍ２Ｍ通信システムにおけるリソースを管理する技術を開示したことを理解されたい。
【０３４１】
本文書が開示したものその他の実施形態、モジュール、および機能動作は、デジタル電子回路内、またはコンピュータソフトウェア、ファームウェア、ハードウェア内に実装することができる。これらは本文書が開示する構造およびその等価構造、さらにはこれらの１以上の組み合わせを含む。開示する実施形態およびその他の実施形態は、１以上のコンピュータプログラム製品として実装することができる。すなわち、コンピュータ読取可能媒体に記録され、データ処理装置が実行しまたはその動作を制御する、１以上のコンピュータプログラム命令のモジュールである。コンピュータ読取可能媒体は、機械読取可能記憶装置、機械読取可能記憶基板、メモリデバイス、機械読取可能伝搬信号を生成する合成物、またはこれらの１以上の組み合わせである。データ処理装置という用語は、全ての装置、デバイス、データ処理機械を包含する。これらは例えばプログラム可能プロセッサ、コンピュータ、マルチプロセッサまたはコンピュータを含む。装置は、ハードウェアに加えて、コンピュータプログラムの命令環境を生成するコードを含む。例えば、プロセッサファームウェア、プロトコルスタック、データベース管理システム、オペレーティングシステム、またはこれらの１以上の組み合わせを構成するコードである。伝搬信号は、人工生成された信号である。例えば、適当な受信装置に対して送信するために情報をコード化するように生成された、機械生成による電気的、光学的、または電磁的信号である。
【０３４２】
コンピュータプログラム（プログラム、ソフトウェア、ソフトウェアアプリケーション、スクリプト、またはコードとしても知られている）は、任意形態のプログラム言語で記述することができる。これはコンパイル言語またはインタプリタ言語を含み、任意形態で配布することができる。これはスタンドアロンプログラムまたはモジュール、コンポーネント、サブルーチン、その他のコンピュータ環境において使用するのに適したユニットを含む。コンピュータプログラムは、ファイルシステムに対応している必要はない。プログラムは、他のプログラムまたはデータ（例えば、マークアップ言語文書内に格納された１以上のスクリプト）を保持する、当該プログラム専用の単一ファイル内または複数協調ファイル（例えば、１以上のモジュール、サブプログラム、またはコードの一部を格納するファイル）内におけるファイルの一部に格納することができる。コンピュータプログラムを配布して、１サイトに配置されまたは複数サイトをまたがって通信ネットワークによって相互接続配置された１以上のコンピュータによって実行することができる。
【０３４３】
本文書において開示するプロセスとロジックフローは、１以上のコンピュータプログラムを実行する１以上のプログラム可能プロセッサによって実施して、入力データ上で動作し出力を生成することにより機能を実施することができる。プロセスとロジックフローは例えばＦＰＧＡ（ｆｉｅｌｄ  ｐｒｏｇｒａｍｍａｂｌｅ  ｇａｔｅ  ａｒｒａｙ）やＡＳＩＣ（ａｐｐｌｉｃａｔｉｏｎ  ｓｐｅｃｉｆｉｃ  ｉｎｔｅｇｒａｔｅｄ  ｃｉｒｃｕｉｔ）のような特定用途論理回路によって実施することもできる。装置はこれら回路として実装することもできる。
【０３４４】
コンピュータプログラムを実行するのに適したプロセッサは、例えば汎用および特定用途マイクロプロセッサ、または任意タイプのデジタルコンピュータの１以上のプロセッサを含む。一般にプロセッサは、読取専用メモリまたはランダムアクセスメモリまたはこれら双方から命令とデータを受信する。コンピュータの必須要素は、命令を実施するプロセッサと、命令およびデータを格納する１以上のメモリデバイスである。一般にコンピュータはさらに、データを格納する１以上の大規模記憶デバイスを備え、またはこれらと動作可能に連結されデータを受信または送信する。例えば磁気ディスク、光磁気ディスク、または光ディスクである。しかしコンピュータはこれらデバイスを必ずしも備えなくともよい。コンピュータプログラム命令とデータを格納するのに適したコンピュータ読取可能媒体は、不揮発性メモリ、媒体、およびメモリデバイスの全ての形態を含む。これは例えば、ＥＰＲＯＭやＥＥＰＲＯＭのような半導体メモリデバイス、フラッシュメモリデバイス、例えば内部ハードディスクやリムーバブルディスクのような磁気ディスク、光磁気ディスク、ＣＤＲＯＭおよびＤＶＤ−ＲＯＭディスクを含む。プロセッサとメモリは、特定用途論理回路内によって補充され、またはその内部に設けることができる。
【０３４５】
本文書は詳細記述を含むが、これらは特許請求しまたはする可能性のある本発明の範囲に対する制約として解釈すべきではない。むしろ特定実施形態に固有の構成の記述として解釈すべきである。個々の実施形態の文脈において本文書が開示する特定要素は、単一実施形態の組み合わせにおいて実装することができる。これとは反対に、単一実施形態の文脈において開示する様々な要素は、複数の実施形態またはその任意の組み合わせにおいて個別に実装することができる。さらに、要素は特定の組み合わせにおいて動作することを説明し、そのように特許請求しているが、特許請求する組み合わせからの１以上の要素は場合によっては組み合わせから除去することができる。特許請求する組み合わせは、サブ組み合わせまたはサブ組み合わせの変形物とすることができる。同様に、図面内の動作は特定順序で示したが、所望結果を実現するために、そのような動作を図示する特定順序で実施することが必要であり、また全動作を実施することが必要であると解釈すべきではない。
【０３４６】
数個の例と実装のみを開示した。開示内容に基づき、説明した例および実装に対する変形、修正、拡張、その他の実装をすることも可能である。
【図１】
0006514315.tif 000017
【図２】
0006514315.tif 000018
【図３】
0006514315.tif 000019
【図４Ａ】
0006514315.tif 000020
【図４Ｂ】
0006514315.tif 000021
【図５】
0006514315.tif 000022
【図６】
0006514315.tif 000023
【図７】
0006514315.tif 000024
【図８】
0006514315.tif 000025
【図９】
0006514315.tif 000026
【図１０】
0006514315.tif 000027
【図１１】
0006514315.tif 000028
【図１２】
0006514315.tif 000029
【図１３】
0006514315.tif 000030
【図１４】
0006514315.tif 000031