JP2016505942A - 無線通信システムにおいて接近権限認証のための方法及び装置 - Google Patents

Abstract

本発明の一実施例に係る無線通信システムで特定動作命令に対する権限認証のための方法において、前記方法は、端末によって行われ、第１サーバーから、特定リソースグループに対する生成動作命令の権限を認証するために用いられる接近制御のためのリソースグループを生成するための動作命令を受信するステップと、前記接近制御のためのリソースグループを生成するステップと、第２サーバーから、前記特定リソースグループを生成するための動作命令を受信するステップと、前記生成された接近制御のためのリソースグループに基づいて、前記特定リソースグループを生成するための動作命令を認証するステップと、を有する。【選択図】図８

Description

本発明は、無線通信システムにおいて接近権限認証のための方法及びそのための装置に関する。

ユビキタス時代の渡来に伴ってＭ２Ｍ（Ｍａｃｈｉｎｅ ｔｏ Ｍａｃｈｉｎｅ）通信技術が脚光を浴びている。Ｍ２Ｍ技術は、ｅ−ヘルス（ｅ−Ｈｅａｌｔｈ）、スマートグリッド（ｓｍａｒｔ ｇｒｉｄ）、スマートホーム（ｓｍａｒｔ ｈｏｍｅ）などの各種の応用分野に用いることができる。このような応用分野では、様々なハードウェア諸元を有するＭ２Ｍ機器が扱われているため、全てのＭ２Ｍ機器を受容できるプロトコルが必要である。このため、リソース制約的なＭ２Ｍ機器に合うアプリケーション層（ａｐｐｌｉｃａｔｉｏｎ ｌａｙｅｒ）プロトコルの開発が要望されている。このようなプロトコルは、リソース制約的なＭ２Ｍ機器に適用可能であるから、異なる諸元を有するＭ２Ｍ機器には十分に適用することができる。

一方、Ｍ２Ｍ機器にも接近制御のための技術が要求され、特定の場合、一般的なＭ２Ｍ機器に相対的に大きい接近権限が与えられ、これに対する制御が必要である。そこで、従来とは格別な接近制御のための手段が必要であり、本明細書でそれについて議論する。

本発明の一実施例では、Ｍ２Ｍサーバーに、特定機能又は特定リソースに対するアップデート、又は上記アップデートによって変更された情報を通知するための方案を提案する。

本発明が遂げようとする技術的課題は、以上に言及した技術的課題に制限されず、言及していない他の技術的課題が、以下の発明の詳細な説明から、本発明の属する技術の分野における通常の知識を有する者には明確に理解されるであろう。

本発明の一実施例に係る無線通信システムで特定動作命令に対する権限認証のための方法において、前記方法は、端末によって行われ、第１サーバーから、特定リソースグループに対する生成動作命令の権限を認証するために用いられる接近制御のためのリソースグループを生成するための動作命令を受信するステップと、前記接近制御のためのリソースグループを生成するステップと、第２サーバーから、前記特定リソースグループを生成するための動作命令を受信するステップと、前記生成された接近制御のためのリソースグループに基づいて、前記特定リソースグループを生成するための動作命令を認証するステップとを有することができる。

好適には、前記接近制御のためのリソースグループは、前記特定リソースグループを指示するＩＤ（Ｉｄｅｎｔｉｆｉｅｒ）及び特定サーバーの前記生成動作命令が許容されることを指示する接近制御リスト（Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｌｉｓｔ；ＡＣＬ）リソースを含むことができる。

好適には、前記ＡＣＬリソースのビットのうちの四番目の最下位ビットが１に設定されてもよい。

好適には、前記接近制御のためのリソースグループを生成するための動作命令は、ブートストラップインターフェースを介して受信されてもよい。

好適には、前記特定リソースグループを生成するための動作命令は、装置管理及びサービスイネーブルメント（ｄｅｖｉｃｅ ｍａｎａｇｅｍｅｎｔ ａｎｄ ｓｅｒｖｉｃｅ ｅｎａｂｌｅｍｅｎｔ）インターフェースを介して受信されてもよい。

好適には、前記特定リソースグループが生成されると、前記方法は、前記特定リソースグループに対する動作命令の権限を認証するために用いられる接近制御のためのリソースグループを生成するステップを有し、前記生成動作命令は前記動作命令から除外されてもよい。

本発明の他の実施例に係る無線通信システムで特定動作命令に対する権限認証のための方法において、前記方法は、端末によって行われ、サーバーから、特定動作命令を受信するステップと、前記特定動作命令が特定リソースグループを生成するための動作命令であると、前記特定リソースグループに対する生成動作命令の権限を認証するために用いられる接近制御のためのリソースグループ（以下、“第１接近制御リソースグループ”）に基づいて前記特定動作命令を認証するステップと、前記特定動作命令が特定リソースグループを生成するための動作命令でないと、前記特定リソースグループに対する生成動作命令以外の動作命令の権限を認証するために用いられる接近制御のためのリソースグループ（以下、“第２接近制御リソースグループ”）に基づいて前記特定動作命令を認証するステップと、を有することができる。

好適には、前記第１接近制御リソースグループは、前記特定リソースグループを指示するＩＤ（Ｉｄｅｎｔｉｆｉｅｒ）及び特定サーバーの前記生成動作命令が許容されることを指示する接近制御リスト（Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｌｉｓｔ；ＡＣＬ）リソースを含むことができる。

好適には、前記ＡＣＬリソースのビットのうちの四番目の最下位ビットが１に設定されてもよい。

好適には、前記第１接近制御リソースグループは、ブートストラップインターフェースを介して受信される生成するための動作命令によって生成されてもよい。

好適には、前記特定命令は、装置管理及びサービスイネーブルメント（ｄｅｖｉｃｅ ｍａｎａｇｅｍｅｎｔ ａｎｄ ｓｅｒｖｉｃｅ ｅｎａｂｌｅｍｅｎｔ）インターフェースを介して受信されてもよい。

好適には、前記特定リソースグループが生成されると、前記方法は、前記特定リソースグループに対する動作命令の権限を認証するために用いられる接近制御のためのリソースグループを生成するステップを有し、前記生成動作命令は前記動作命令から除外されてもよい。

本発明の他の実施例に係る無線通信システムで特定動作命令に対する権限認証のための端末は、無線周波数（ｒａｄｉｏ ｆｒｅｑｕｅｎｃｙ；ＲＦ）ユニットと、前記ＲＦユニットを制御するように構成されたプロセッサとを備えることができ、前記プロセッサは、第１サーバーから、特定リソースグループに対する生成動作命令の権限を認証するために用いられる接近制御のためのリソースグループを生成するための動作命令を受信し、前記接近制御のためのリソースグループを生成し、第２サーバーから、前記特定リソースグループを生成するための動作命令を受信し、及び前記生成された接近制御のためのリソースグループに基づいて、前記特定リソースグループを生成するための動作命令を認証するように構成されてもよい。

本発明の他の実施例に係る無線通信システムで特定動作命令に対する権限認証のための端末は、無線周波数（ｒａｄｉｏ ｆｒｅｑｕｅｎｃｙ；ＲＦ）ユニットと、前記ＲＦユニットを制御するように構成されたプロセッサとを備えることができ、前記プロセッサは、サーバーから特定動作命令を受信し、前記特定動作命令が特定リソースグループを生成するための動作命令であると、前記特定リソースグループに対する生成動作命令の権限を認証するために用いられる接近制御のためのリソースグループ（以下、“第１接近制御リソースグループ”）に基づいて前記特定動作命令を認証するように構成され、及び前記特定動作命令が特定リソースグループを生成するための動作命令でないと、前記特定リソースグループに対する生成動作命令以外の動作命令の権限を認証するために用いられる接近制御のためのリソースグループ（以下、“第２接近制御リソースグループ”）に基づいて前記特定動作命令を認証するように構成されてもよい。

上記の課題解決方法は、本発明の実施例の一部に過ぎず、本発明の技術的特徴が反映された様々な実施例が、当該技術の分野における通常の知識を有する者にとって、以下に詳述する本発明の詳細な説明に基づいて導出され理解されるであろう。

本発明の一実施例によれば、Ｍ２Ｍサーバーに、Ｍ２Ｍクライアント／装置の特定機能又はリソースに対するアップデート関連情報を通知することができ、これによって、上記アップデートを開始したＭ２Ｍサーバーだけでなく、他のＭ２Ｍサーバーも、上記Ｍ２Ｍクライアント／装置の特定機能又はリソースに対するアップデートを確認できるようにし、しかも、上記アップデートによって変更された特定機能又はリソースを利用できるようにする。

本発明による効果は、以上で言及した効果に制限されず、言及していない他の効果は、以下の発明の詳細な説明から、本発明の属する技術の分野における通常の知識を有する者には明らかになるであろう。

Ｍ２Ｍクライアントに記憶されたデータ（又は、資料）構造を示す図である。 本発明の一実施例と係るリソースモデルを示す図である。 本発明の一実施例と係るインターフェースのモデルを示す図である。 本発明の一実施例に係るファームウェア又はソフトウェアのアップデートによる通報の概念を示す図である。 本発明の一実施例に係る購読機能を説明するためのフローチャートである。 本発明の一実施例に係るファームウェア又はソフトウェアのアップデート及びそれによって変更された情報の通報手順を示すフローチャートである。 本発明の実施例と対比する例を示す図である。 本発明の一実施例に係る認証手順を示すフローチャートである。 本発明の一実施例に係る認証手順を示すフローチャートである。 本発明の実施例を具現するための装置のブロック図である。

本発明に関する理解を助けるために詳細な説明の一部として含まれる添付の図面は、本発明に関する実施例を提供し、詳細な説明と共に本発明の技術的思想を説明する。
以下、本発明に係る好適な実施の形態を、添付の図面を参照して詳しく説明する。添付の図面と共に以下に開示される詳細な説明は、本発明の例示的な実施の形態を説明するためのもので、本発明を実施し得る唯一の実施の形態を示すためのものではない。以下の詳細な説明は、本発明の完全な理解を提供するために具体的な細部事項を含む。しかし、当業者にとってはこのような具体的な細部事項無しにも本発明を実施することができる。

いくつかの場合、本発明の概念が曖昧になることを避けるために、公知の構造及び装置を省略したり、各構造及び装置の核心機能を中心にしたブロック図の形式で図示することができる。また、本明細書全体において同一の構成要素については同一の図面符号を付して説明する。

本発明において、機器間通信のためのデバイス、すなわち、Ｍ２Ｍクライアント又は端末は、固定されていてもよく、移動性を有してもよい。その例には、機器間通信のためのサーバー、すなわち、Ｍ２Ｍサーバー、又はサーバーと通信してユーザデータ及び／又は各種の制御情報を送受信する各種機器がある。Ｍ２Ｍクライアントは、端末（Ｔｅｒｍｉｎａｌ Ｅｑｕｉｐｍｅｎｔ）、ＭＳ（Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ）、ＭＴ（Ｍｏｂｉｌｅ Ｔｅｒｍｉｎａｌ）、ＵＴ（Ｕｓｅｒ Ｔｅｒｍｉｎａｌ）、ＳＳ（Ｓｕｂｓｃｒｉｂｅ Ｓｔａｔｉｏｎ）、無線機器（ｗｉｒｅｌｅｓｓ ｄｅｖｉｃｅ）、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）、無線モデム（ｗｉｒｅｌｅｓｓ ｍｏｄｅｍ）、携帯機器（ｈａｎｄｈｅｌｄ ｄｅｖｉｃｅ）などと呼ぶことができる。また、本発明において、Ｍ２Ｍサーバーは、一般に、Ｍ２Ｍ端末及び／又は他のＭ２Ｍサーバーと通信する固定された地点（ｆｉｘｅｄ ｓｔａｔｉｏｎ）のことを指し、Ｍ２Ｍ端末及び／又は他のＭ２Ｍサーバーと通信して各種データ及び制御情報を交換する。

以下、本発明に係わる背景技術について説明する。

装置管理（Ｄｅｖｉｃｅ Ｍａｎａｇｅｍｅｎｔ）

装置管理（ＤＭ；Ｄｅｖｉｃｅ Ｍａｎａｇｅｍｅｎｔ）は、様々な管理当局（Ｍａｎａｇｅｍｅｎｔ Ａｕｔｈｏｒｉｔｉｅｓ）の観点から、装置構成、及び装置の他の管理された客体を管理することをいう。装置管理は、装置において連続する情報の順次的アップデート、装置から管理情報の検索、及び装置によって生成されたイベントとアラームの処理を含むが、装置における初期構成情報を設定することに限定されない。

管理ツリー（Ｍａｎａｇｅｍｅｎｔ Ｔｒｅｅ）

管理ツリーは、管理サーバーがＤＭクライアントと相互作用するためのインターフェースであり、例えば、管理ツリーに値を記憶したり、管理ツリーから値を検索することによって、そして管理ツリーの属性を操作することによって相互作用することができる。例えば、管理ツリーの一属性としてＡＣＬ（ａｃｃｅｓｓ ｃｏｎｔｒｏｌ ｌｉｓｔ）がある。本明細書では、管理ツリーは、装置管理ツリー又はＤＭツリーと同じ意味で使うことができる。

ＭＯ（管理客体；Ｍａｎａｇｅｍｅｎｔ Ｏｂｊｅｃｔ）

管理客体は、互いにいくつかの方式で関連しているノードの集合（単独のノードも可能）になると予想される管理ツリーのサブツリーである。例えば、．／ＤｅｖＩｎｆｏノードとその子ノードが管理客体を形成することができる。簡単な管理客体は、１つの単一（ｓｉｎｇｌｅ）ノードで構成されてもよい。

ＤＭサーバー（Ｄｅｖｉｃｅ Ｍａｎａｇｅｍｅｎｔ Ｓｅｒｖｅｒ）

ＤＭサーバー（ＤＭ Ｓｅｒｖｅｒ）は、ＤＭサーバーに特定のＯＭＡ装置管理イネーブラ静的適合性要件に従う装置管理インフラストラクチャーにおける概念的なソフトウェアコンポーネントであってよい。このＤＭサーバーは、ＤＭクライアント−サーバープロトコル及びＤＭサーバー−サーバーインターフェースのエンド−ポイントとして働くことができる。

また、本明細書で、ＤＭサーバーは、通信モジュール、プロセッサモジュールなどを具備する装置、デバイス、コンピュータなどに組み込んで提供することができ、よって、一つの装置として具現することができる。

ＤＭクライアント（Ｄｅｖｉｃｅ Ｍａｎａｇｅｍｅｎｔ Ｃｌｉｅｎｔ）

ＤＭクライアント（ＤＭ Ｃｌｉｅｎｔ）は、該ＤＭクライアントに特定のＯＭＡ装置管理イネーブラ静的適合性要件に従う装置具現（ｉｍｐｌｅｍｅｎｔａｔｉｏｎ）における概念的ソフトウェアコンポーネントであってよい。このＤＭクライアントは、ＤＭクライアント−サーバープロトコルのエンド−ポイントとして働くことができる。

また、本明細書で、ＤＭクライアントは、通信モジュール、プロセッサモジュールなどを具備するＤＭの対象となる装置に組み込んで提供することができ、よって、一つの装置として具現することができる。

ＡＣＬ（Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｌｉｓｔ）

ＡＣＬは、管理ツリー内の特定ノードに対するＤＭサーバー識別子、及びそれぞれのＤＭサーバー識別子と関連付く接近権限（ａｃｃｅｓｓ ｒｉｇｈｔ）のリストを意味する。

ノード（Ｎｏｄｅ）

ノードは、管理ツリーにおける単一エレメントである。管理ツリーにおいてノードは２種類、すなわち、インテリアーノードとリーフノードがある。ノードのフォーマット属性は、ノードがリーフノードかインテリアーノードかに関する情報を提供する。

インテリアーノード（Ｉｎｔｅｒｉｏｒ Ｎｏｄｅ）

インテリアーノードは、子ノードを有することができるが、ノードに割り当てられた値すなわち、ノード値（ｎｏｄｅ ｖａｌｕｅ）を有することはできない。インテリアーノードのフォーマット属性は”ｎｏｄｅ”である。

リーフノード（Ｌｅａｆ Ｎｏｄｅ）

リーフノードは、子ノードを有することはできないが、ノード値を有することができる。リーフノードのフォーマット属性は”ｎｏｄｅ”ではない。

したがって、全ての親（ｐａｒｅｎｔ）ノードはインテリアーノードにならなければならない。

永久ノード（Ｐｅｒｍａｎｅｎｔ Ｎｏｄｅ）

永久ノードは、ＤＤＦ属性スコープがパーマネント（Ｐｅｒｍａｎｅｎｔ）に設定されたノードである。ノードは、永久ノード以外は動的ノードに該当する。永久ノードは、サーバーによって動的に生成したり、削除したりすることができない。

動的ノード（Ｄｙｎａｍｉｃ Ｎｏｄｅ）

動的ノードは、ＤＤＦ属性スコープ（Ｓｃｏｐｅ）がダイナミック（Ｄｙｎａｍｉｃ）に設定されているか、又は、ＤＤＦ属性スコープが特定されていないノードである。

サーバー識別子（Ｓｅｖｅｒ Ｉｄｅｎｔｉｆｉｅｒ）

サーバー識別子は、ＤＭサーバーに対するＯＭＡ ＤＭ内部名称を表す。ＤＭサーバーは、ＯＭＡ ＤＭアカウントを通じて装置に存在するサーバー識別子と関連付けられる。

ＡＣＬ属性及びＡＣＬ値

ＤＭ（ｄｅｖｉｃｅ ｍａｎａｇｅｍｅｎｔ）プロトコルで管理される全ての端末は、ルートノード（ｒｏｏｔ ｎｏｄｅ）から始まる一つのＤＭツリー（ｔｒｅｅ）を有し、ＤＭプロトコルはＤＭツリーの各ノードを操作することによって端末に管理命令を実行する。例えば、端末にダウンロードされたソフトウェアを設置するためには、該ソフトウェアとマッチされているインストール（ｉｎｓｔａｌｌ）というノードを実行（Ｅｘｅｃ）し、これで、当該ソフトウェアを設置することができる。それぞれのノードは、数字のような単純な情報を表すこともでき、絵データやログデータのように複雑なデータを表すこともできる。また、ノードは、実行、ダウンロードなどのような一つの命令を表すこともできる。

それぞれのノードは、ノードと関連するメタ情報を提供する属性（ｐｒｏｐｅｒｔｙ）を有する。この属性の中にはランタイム（ｒｕｎｔｉｍｅ）属性があるが、この属性は、ノードがＤＭツリー内に生成されて消滅するまで使用可能な属性を意味する。このようなランタイム属性には、ＡＣＬ、Ｆｏｒｍａｔ、Ｎａｍｅ、Ｓｉｚｅ、Ｔｉｔｌｅ、ＴＳｔａｍｐ、Ｔｙｐｅ、ＶｅｒＮｏがある。

ＡＣＬ（Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｌｉｓｔ）は、ＤＭ １．３プロトコルでは端末とサーバーの両方とも具現すべき必須機能である。ＡＣＬは、特定ＤＭサーバーが特定ノードに実行可能なＤＭ命令（ｃｏｍｍａｎｄ）を明示し、明示されていないＤＭ命令を行うことはできない。言い換えると、ＡＣＬは、特定ＤＭサーバーが特定ノードに対して許容された権限を意味する。ＤＭプロトコルで、ＡＣＬはＤＭサーバーのサーバー識別子に与えられ、ＵＲＩ、ＩＰアドレス、ＤＭサーバー資格（ｃｅｒｔｉｆｉｃａｔｅ）に与えられない。このサーバー識別子は、ＤＭプロトコルでＤＭサーバーを認証する識別子として用いられる。また、このようなＡＣＬは、ＡＣＬ属性（ｐｒｏｐｅｒｔｙ）と該ＡＣＬ属性に与えられたＡＣＬ値で提供することができる。一方、本明細書で、ＡＣＬ値は、ＡＣＬ情報（ＡＣＬ ｉｎｆｏｒｍａｔｉｏｎ）又はＡＣＬに関する情報と同じ意味で使うことができる。ＤＭ １．３プロトコルでは、全ノードがＡＣＬ属性を有するように定義されており、ＡＣＬ属性を有する全ノードは、空の（ｅｍｐｔｙ）ＡＣＬ値又は空でない（ｎｏｎ−ｅｍｐｔｙ）ＡＣＬ値を有するように定義される。

ＡＣＬは、他のランタイム属性と異なる独特の性質を有するが、その代表としてＡＣＬ相続（ＡＣＬ ｉｎｈｅｒｉｔａｎｃｅ）がある。ＡＣＬ相続は、ＤＭツリーにおけるあるノードがＡＣＬ値を有しないとき、該ノードに対するＡＣＬ値を親ノードのＡＣＬ値からゲットする概念である。仮に親ノードもＡＣＬ値を有していないと、その親ノードの親ノードからＡＣＬ値をゲットする。ＤＭプロトコルでは、ＤＭツリーの最上位ノードであるルートノードが必ずＡＣＬ値を有するように明示しているため、ＡＣＬ値は必ず相続される。このようなＡＣＬ相続は、個別ＤＭ命令別になされず、全体ＡＣＬ値に対して行われるため、ＡＣＬ値が空である場合にのみ親ノードからＡＣＬ相続が行われる。すなわち、あるノードのＡＣＬ値がＡｄｄ権限のみを明示していると、明示されていないＧｅｔ（ゲット）権限などは相続されない。

ＤＭプロトコルではルートノードはＡＣＬに対する基本値として”Ａｄｄ＝＊＆Ｇｅｔ＝＊”を有し、ここで、”＊”は、ワイルドカード（ｗｉｌｄ ｃａｒｄ）であって、任意のＤＭサーバーを意味する。ＤＭサーバーがＡＣＬ値を得るためにはＧｅｔ命令を用いればよく、”．／ＮｏｄｅＡ／Ｎｏｄｅ１？ｐｒｏｐ＝ＡＣＬ”に対するＧｅｔ命令は、．／ＮｏｄｅＡ／Ｎｏｄｅ１のＡＣＬ値をゲットする。また、ＡＣＬ値を変えるためには取替え（Ｒｅｐｌａｃｅ）命令を用いればよく、”．／ＮｏｄｅＡ／Ｎｏｄｅ１？ｐｒｏｐ＝ＡＣＬ”に取替え命令を行って、”Ａｄｄ＝ＤＭＳ１＆Ｄｅｌｅｔｅ＝ＤＭＳ１＆Ｇｅｔ＝ＤＭＳ１”に値を変えると、ＡＣＬ値が取り替えられる。ＤＭプロトコルでは個別ＡＣＬエントリー（ａｃｌ ｅｎｔｒｙ）を変えることができず、全体ＡＣＬ値を変えることができるように定義されている。ＡＣＬ値をゲットし、修正する権限もＡＣＬに基づいて定義されるが、インターリアノードとリーフノードに対する権限がやや異なって定義されている。

− インテリアーノード
当該ノードにＧｅｔとＲｅｐｌａｃｅ権限を有していると、当該ノードのＡＣＬ値をそれぞれゲットし取替えできる権限がある。また、Ｒｅｐｌａｃｅ権限は、全子ノードのＡＣＬ値を取り替えることができる権限を意味する。

− リーフノード
当該ノードの親ノードにＲｅｐｌａｃｅ権限を有していると、そのノードのＡＣＬ値を取り替えることができる権限がある。当該ノードのＡＣＬをゲットするためには、親ノードにＧｅｔ権限を有していなければならない。同様に、当該ノードにＲｅｐｌａｃｅ権限を有していると、該ノードの値を取り替えることができる権限を有することを意味し、ＡＣＬを取り替えるためには親ノードにＲｅｐｌａｃｅ権限を有していなければならない。

インテリアーノードであれリーフノードであれ、該当のノードのＡＣＬ値を取り替える権限は、親ノードのＡＣＬ値によって制御することができる。インテリアーノードにリプレイス（Ｒｅｐｌａｃｅ）権限を有していると、当該インテリアーノードはもとより、全ての子ノードのＡＣＬ値を取り替えることができる権限を意味する。したがって、ルートノードにＲｅｐｌａｃｅ権限を有していると、ＤＭツリー内の全ノードにいずれの権限も有し得るという意味となる。しかし、親ノードにＲｅｐｌａｃｅ権限を有するということが、子ノードにＧｅｔのような特定権限が含まれるということを意味のではなく、当該子ノードに直接的にＧｅｔのような権限が明示されていなければならない。したがって、命令実行前にＡＣＬ値を修正しなければならず、修正しようとするノードへの経路にある全ノードに対するＡＣＬ値の修正によって最終的に当該子ノードのＡＣＬ値を修正する。しかし、これは不便であり、ＤＭプロトコルでは、親ノード或いは先祖ノード（ａｎｃｅｓｔｏｒ ｎｏｄｅ）にＲｅｐｌａｃｅ権限を有していると、中間ノードのＡＣＬ値の修正無しで直接該当のノードのＡＣＬ値の修正を許容している。

ＤＭサーバーが新しいノードを追加（Ａｄｄ）命令によって生成した場合、生成されたノードは、一般にＡＣＬ値を有さず、全ての権限を親から相続するようになる。しかし、生成したノードがインテリアーノードであり、親ノードにＲｅｐｌａｃｅ権限を有していない場合、生成と同時にＡＣＬ値を設定し、当該ノードを管理するための十分の権限を有することが必要である。

ＡＣＬ値を示すための文法は［ＤＭ−ＴＮＤ］に定義されており、ＡＣＬ値の一例としては”Ｇｅｔ＝ＤＭＳ１＆Ｒｅｐｌａｃｅ＝ＤＭＳ１＆Ｄｅｌｅｔｅ＝ＤＭＳ２”を挙げることができる。ここで、ＤＭＳ１とＤＭＳ２はＤＭサービーのサーバー識別子であり、Ｇｅｔ、Ｒｅｐｌａｃｅ、Ｄｅｌｅｔｅは、ＤＭ命令である。したがって、該当のノードに対してＤＭＳ１はＧｅｔとＲｅｐｌａｃｅ命令を行うことができ、ＤＭＳ２はＤｅｌｅｔｅ命令を行うことができる。ここで、Ｇｅｔ＝ＤＭＳ１、Ｒｅｐｌａｃｅ＝ＤＭＳ１、Ｄｅｌｅｔｅ＝ＤＭＳ２はそれぞれＡＣＬ−エントリー（ａｃｌ−ｅｎｔｒｙ）であり、ＤＭサーバーの個別命令権限を表す。すなわち、ＡＣＬ値は個別ＡＣＬ−エントリー（ａｃｌ−ｅｎｔｒｙ）の集合であり、各ノードのＡＣＬ値は、少なくとも一つのＡＣＬエントリーを含むことができる。

ＤＤＦ（Ｄｅｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｆｒａｍｅｗｏｒｋ）

ＤＤＦは、特定デバイスタイプに対する管理シンタックスとセマンティックスを記述する方法に関する説明である。ＤＤＦは、端末のＭＯ、管理機能及びＤＭツリー構造に関する情報を提供する。

ＤＭ １．３認証

ＤＭ １．３ではＡＣＬに基づいて認証を行う。ＤＭ認証は、それぞれのＤＭ命令に対して個別に行われる。仮にＤＭサーバーが複数のＤＭ命令を送信すると、ＤＭクライアントは、個別命令を行う前に認証を行い、その結果として許可されたＤＭ命令のみを行う。

ＤＭツリー
ＤＭツリーは、ＤＭクライアントによって露出されたＭＯインスタンスの集合を意味する。ＤＭツリーは、クライアントと相互作用する管理サーバーによるインターフェースとして働き、例えば、管理サーバーは、ＤＭツリーから特定値を記憶し、検索（ｒｅｔｒｉｅｖｅ）し、当該ＤＭツリーの属性を操作することができる。

既存のサーバー−クライアントモデルでサーバーとクライアント間の通信を行うためには、これら両エンティティ（サーバー、クライアント）とも通信実行前に共有／記憶すべき情報が存在する。そのために、ＤＭでは、ＤＭクライアントをブートストラップ（ｂｏｏｔｓｔｒａｐ）し、ＤＭサーバーとの通信に必要な事前情報を、ＤＭサーバー又はＤＭブートストラップサーバーが伝達する。すなわち、ＤＭクライアントは、特定ＤＭサーバーとの通信に必要な事前情報を、ブートストラップ技法によって伝達し、その後、当該ＤＭクライアントとＤＭサーバー間の通信を可能にさせる。

実際の配置（ｄｅｐｌｏｙｍｅｎｔ）状況でＤＭクライアントを再−ブートストラップ（ｒｅ−ｂｏｏｔｓｔｒａｐ）する場合が発生するが、例えば、特定ＤＭサーバーと特定ＤＭクライアント間の通信に持続的に誤りが発生する場合がある。このような場合は、保安キー（ｓｅｃｕｒｉｔｙ ｋｅｙ）不一致（ｍｉｓｍａｔｃｈ）又は他の理由などから発生しうる。ＤＭでは再−ブートストラップについては明示していないが、ブートストラップが再び発生する場合を意味するものと判断される。このようなブートストラップの場合は、ブートストラップ情報の他に特定サーバー関連情報（例えば、ＡＣＬ中の当該サーバーの権限情報）も初期化されるため、再−ブートストラップの後にも当該サーバーに関する情報をクライアントに伝達する必要がある。そこで、本発明では、再−ブートストラップの際に、全体ブートストラップを全て行わず、特定情報のみを提供／更新する方法を用いて、他の情報を維持しながら再−ブートストラップを行う方法を提示する。

図１は、Ｍ２Ｍクライアントに記憶されたデータ（又は、資料）構造を示す図である。Ｍ２Ｍクライアント（又は、端末）は、該Ｍ２Ｍクライアントが実現できる機能に該当する“客体（Ｏｂｊｅｃｔ）”と呼ばれる、リソース（ｒｅｓｏｕｒｃｅ）がグループ化されたエンティティを有することができる。客体の識別子は、客体説明（ｓｐｅｃｉｆｉｃａｔｉｏｎ）で定義されてもよく、客体説明で定義されていない識別子は、Ｍ２Ｍシステムを用いる事業者又はメーカが設定してもよい。リソースは実際データを記憶するエンティティであり、リソースは複数個のリソースインスタンス（ｉｎｓｔａｎｃｅ）を有することができる。各客体は、特定動作命令によって客体インスタンス（ｏｂｊｅｃｔ ｉｎｓｔａｎｃｅ）として生成されて実体化され、Ｍ２Ｍクライアントは、上記客体インスタンスを介して実際該当のリソースに接近することができる。

“客体”は、特定機能（ｆｕｎｃｔｉｏｎａｌｉｔｙ）又は目的のために用いられるリソースのグループと定義され、“客体インスタンス”は、客体が端末に実体化（ｉｎｓｔａｎｔｉａｔｉｏｎ、ｃｒｅａｔｉｏｎ）されたリソースグループを意味し、客体の機能を用いるには客体インスタンスが必ず生成されなければならない。

具体的に、“客体”は、実体化されるリソースグループのテンプレート（ｔｅｍｐｌａｔｅ）、青写真（ｂｌｕｅ ｐｒｉｎｔ）のような概念であり、実体化されるリソースグループがいかなるリソースを有することができ、リソースがいかなる属性（例えば、リソースの識別子、ネーム、支援される動作命令、範囲、単位、説明）を有するか、特定動作命令に対していかなる動作をするかについて定義する。“客体インスタンス”は、客体の定義に従って端末に存在する又は実体化されたリソースグループであり、リソースグループのリソースは、リソースに該当する値を有することができる。

以下、明細書で、別の言及がない限り、“客体”は“支援されるリソースのグループ”又は“リソースグループ定義”同じ意味で使われてもよく、“客体インスタンス”は、“実体化されたリソースのグループ”又は“リソースグループ”と同じ意味で使われてもよい。

また、各リソースには当該リソースがいかなる動作命令（ｏｐｅｒａｔｉｏｎ）を支援するかを示すための情報が含まれたり添付され、動作命令には、例えば、読み取り（Ｒｅａｄ）、書き込み（Ｗｒｉｔｅ）、実行（Ｅｘｅｃｕｔｅ）、書き込み属性（Ｗｒｉｔｅ Ａｔｔｒｉｂｕｔｅｓ）、探索（Ｄｉｓｃｏｖｅｒ）、観察（Ｏｂｓｅｒｖｅ）などがある。

図２は、本発明の一実施例に係るリソースモデルを示す図である。本発明の一実施例に係るＭ２Ｍシステムで用いられるリソースに対する接近権限の制御のためにＡＣＬ（Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｌｉｓｔ）とＡＴ（Ａｃｃｅｓｓ Ｔｙｐｅ）を割り当てる。

ＡＣＬは、特定機能が実体化されたリソース、すなわち、客体インスタンス別に割り当てられ、客体インスタンスの下位リソースは同一のＡＣＬが割り当てられたものと見なす。すなわち、ＡＣＬが客体インスタンス別に割り当てられることから、その下位リソースは同一のＡＣＬを有すると約束される。

客体インスタンスは、リソースがグループ化されているエンティティであり、特定機能を行うために集まった集団であるから、特定サーバーに特定機能に対する権限を与える際、集団中の全リソースに対して同一の権限を与えることが妥当である。同一権限を与えないと、一つの機能に対して部分的に動作を行うことがあり、この場合には、当該サーバーの役目が曖昧になり、権限附与の意味が褪せる。このため、本発明の一実施例では、上述したように各客体インスタンス別にＡＣＬを割り当てることによって、個別リソース別に記憶される従来の場合に比べてオーバーヘッドを減らすことができ、また、ＡＣＬを探すために同一のメカニズムを用いるため、接近権限認証手順を簡素化させることができる。

参考として、各客体は、複数個の客体インスタンスとして実体化（ｉｎｓｔａｎｔｉａｔｅ）することができる。

また、ＡＴは、個別リソース別に割り当てることができ、各個別リソースが支援する接近方式を定義することができる。例えば、接近方式を動作命令（ｏｐｅｒａｔｉｏｎ）と定義すると、ＡＴは、特定動作命令、例えば、読み取り（Ｒｅａｄ）、書き込み（Ｗｒｉｔｅ）、実行（Ｅｘｅｃｕｔｅ）などと定義することができる。

一方、ＡＣＬとＡＴはそれぞれ他の名称としてもよく、例えば、ＡＣＬは接近権限（Ａｃｃｅｓｓ Ｒｉｇｈｔ）、ＡＴは支援可能な動作命令などと呼ぶこともできる。

インターフェース

本発明の具体的な実施例を説明するに前に、まず、特定動作命令がサーバーとクライアント（端末）間に伝達されるインターフェースについて説明する。

本発明と関連して、４個のインターフェースが存在する。１）ブートストラップ、２）装置（クライアント、デバイス）登録、３）装置管理及びサービスイネーブルメント、４）情報報告。これら４つのインターフェースのための動作命令は、上りリンク動作と下りリンク動作とに分類できる。それぞれのインターフェースの動作命令を次の表に定義する。

図３には、４つのインターフェースを示す。図３の（ａ）は、ブートストラップインターフェースのための動作モデルを示す。ブートストラップインターフェースのために、動作命令は、“ブートストラップ要求要求”と名づけられた上りリンク動作命令（すなわち、クライアント開始ブートストラップ）と、“書き込み”及び“削除”と名づけられた下りリンク動作命令（すなわち、サーバー開始ブートストラップ）がある。これらの動作命令は、一つ以上のサーバーに登録するためにクライアントのための必要な客体インスタンスを初期化するために用いられる。ブートストラップはまた、メーカーブートストラップ（ｆａｃｔｏｒｙ ｂｏｏｔｓｔｒａｐ）又はスマートカードからのブートストラップ（ｂｏｏｔｓｔｒａｐ ｆｒｏｍ ｓｍａｒｔｃａｒｄ）（スマートカードに記憶）を用いて定義される。

図３の（ｂ）は、“装置（クライアント）登録”インターフェースのための動作モデルを示す。装置登録インターフェースのために、動作命令は、“登録”“アップデート”及び“登録−解除”と名づけられた上りリンク動作命令がある。“登録”は、サーバーにクライアントの情報を登録するために用いられ、“アップデート”は、周期的に又はクライアントに発生したイベントによって、サーバーに登録されたクライアントの情報又は状態をアップデートするために用いられる。“登録−解除”は、サーバーに対するクライアントの登録を解除する段階であり、サーバーはクライアントの情報を削除することができる。

図３の（ｃ）は、“装置管理及びサービスイネーブルメント（ｄｅｖｉｃｅ ｍａｎａｇｅｍｅｎｔ ａｎｄ ｓｅｒｖｉｃｅ ｅｎａｂｌｅｍｅｎｔ）”インターフェースのための動作モデルを示す。装置管理及びサービスイネーブルメントインターフェースのために、動作命令は、“読み取り”、“生成”、“削除”、“書き込み”及び“実行”と名づけられた下りリンク動作命令がある。これらの動作命令は、クライアントのリソース、リソースインスタンス、客体及び客体インスタンスとの相互作用のために用いられる。“読み取り”動作命令は、一つ以上のリソースの現在値を読むために用いられ、“書き込み”動作命令は、一つ以上のリソースの値をアップデートするために用いられ、“実行”動作命令は、リソースによって定義された動作を開始するために用いられる。“生成”及び“削除”動作命令は、客体インスタンスを生成又は削除するために用いられる。“書き込み属性”は、“観察”動作命令と関連した属性を設定するために用いられ、“探索”は、該当の属性を検索するために用いられる。

図３の（ｄ）は、“情報報告”インターフェースのための動作モデルを示す。情報報告インターフェースのために、動作命令は、下りリンク動作命令“観察”又は“取消観察”及び上りリンク動作命令“通知（Ｎｏｔｉｆｙ）”を含む。この情報報告インターフェースは、サーバーにクライアント上のリソースと関連した新しい値を送信するために用いられる。“観察”は、サーバーがリソースの変化に関心がある場合、特定リソースを観察するために用いられ、“取消観察”は、該当の観察をそれ以上しない時（リソースの変化をそれ以上知りたくない時）に用いられる。“通知”は、“書き込み属性”を通じて設定された観察条件属性が一致する場合、それをサーバーに知らせるために用いられる。

接近制御のためのデータモデル

Ｍ２Ｍデバイスのパーシング（ｐａｒｓｉｎｇ）プロセスオーバーヘッドを減らし、空間オーバーヘッド（ｓｐａｃｅ ｏｖｅｒｈｅａｄ）を減らすために、Ｍ２Ｍ環境に適したサーバー識別子（Ｉｄｅｎｔｉｆｉｅｒ；ＩＤ）、ＡＣＬ（又は、接近権限）、ＡＴ（又は、支援可能な動作命令）にモデリングする。

− 短いサーバーＩＤ
ＡＣＬに含まれなければならない情報としては、いかなるサーバーがいかなる動作命令（ｏｐｅｒａｔｉｏｎ）を命令できるかを含まなければならない。サーバーＩＤは、一般にＵＲＩで表現されるため、環境によってはＵＲＩがだいぶ長くなることもある。客体インスタンス別にＡＣＬが表現されなければならず、客体インスタンスごとに長いサーバーＩＤが重なって用いられるため、サーバーＩＤによって客体インスタンス数に依存して相当な空間オーバーヘッドを招きうる。そこで、短くて固定された長さ（例えば、２バイト）の短いサーバーＩＤをＡＣＬで使用することを提案する。Ｍ２Ｍクライアントは、短いサーバーＩＤとサーバーＩＤ間のマッピング関係を記憶しており、サーバーＩＤから受信される動作命令に対して短いサーバーＩＤを探し、これを用いてＡＣＬを通じて認証を行うことができる。

接近制御リスト（ＡＣＬ）又は接近権限

ＡＣＬは、各客体インスタンスに割り当てられ、それぞれのＭ２Ｍサーバーに対する接近権限を指定するＡＣＬエントリー（ｅｎｔｒｙ）のリストで構成される。ＡＣＬエントリーは、短いサーバーＩＤと当該サーバーの接近権限で表現することができる。短いサーバーＩＤと接近権限値はいずれも固定された短い長さに設定し、認証手順時の空間オーバーヘッド及び処理効率性を高める。接近権限ではＭ２Ｍの各動作命令に対して一つのビット値を割り当て、特定動作命令に対する認証手順を行う際、一つのビットのみを読むだけで済むようにすることで処理効率性を高めた。ＡＣＬで明示されているサーバー以外のサーバーに対するデフォルト（ｄｅｆａｕｌｔ）ＡＣＬエントリーを設定することができ、ＡＣＬに明示されていない全てのサーバーに対する動作命令を受信すると、Ｍ２Ｍクライアントは、特定の短いサーバーＩＤ（例えば、０ｘ００００）を探し、該当の接近権限を用いて該当の動作命令を認証することができる。

上記の表に例示したＡＣＬエントリー中の値は一例であり、他の例示も可能であることは当業者には明らかである。

接近タイプ（ＡＴ）又は支援可能動作命令

ＡＴは、リソースがいなかる動作命令を支援するかを指定することができる。ＡＣＬエントリーの接近権限と同様の形態とし、一つのビットごとに一つの動作命令をマップした。

上記の表に例示したＡｃｃｅｓｓ Ｔｙｐｅ中の値は一例であり、他の例示も可能であることは当業者には明らかである。

以下、本明細書で使われるＭ２Ｍ関連動作命令及び客体（インスタンス）について簡略に説明する。

− 登録（Ｒｅｇｉｓｔｅｒ）
登録は、Ｍ２Ｍクライアントが“登録”動作命令をＭ２Ｍサーバーに送信する場合に行われる。Ｍ２Ｍ装置がオン（ｔｕｒｎｅｄ ｏｎ）になり、ブートストラップ手順が完了すると、Ｍ２Ｍクライアントは、自身が有しているサーバー客体インスタンスに該当するＭ２Ｍサーバーのそれぞれ（すなわち、該Ｍ２Ｍクライアントが登録された各サーバー）に“登録”動作命令を行わなければならない。下記の表に、“登録”動作命令のために用いられるパラメータを説明する。

− アップデート（Ｕｐｄａｔｅ）
周期的に、又はＭ２Ｍクライアント内特定イベントに基づいて、又はＭ２Ｍサーバーによって開始されて、Ｍ２ＭクライアントはＭ２Ｍサーバーに“アップデート”動作命令を送信することによって、Ｍ２Ｍサーバーと自身の登録情報をアップデートすることができる。“アップデート”動作命令は、Ｍ２Ｍサーバーに送信された最後の登録パラメータと比較して変更された、下記の表に列挙されたパラメータのみを含まなければならない。

Ｍ２ＭクライアントがＭ２Ｍサーバーとの通信のためのＵＤＰバインディング及びＭ２ＭクライアントのＩＰアドレス又はポート変更を利用する場合、上記Ｍ２ＭクライアントはＭ２Ｍサーバーに“アップデート”動作命令を送信しなければならない。

上記“アップデート”動作命令は、Ｍ２Ｍサーバー客体の“登録アップデートトリガー（Ｒｅｇｉｓｔｒａｔｉｏｎ Ｕｐｄａｔｅ Ｔｒｉｇｇｅｒ）”リソースに対する“実行”動作命令によってＭ２Ｍサーバーで開始することができる。

− 登録−解除（Ｄｅ−ｒｅｇｉｓｔｅｒ）
Ｍ２ＭクライアントがＭ２Ｍサーバーにそれ以上利用可能でないと判断すると（例えば、Ｍ２Ｍ装置動作リセット）、Ｍ２Ｍクライアントは、Ｍ２Ｍサーバーに“登録−解除”動作命令を送信しなければならない。この動作命令を受信すると、Ｍ２Ｍサーバーは、該Ｍ２Ｍサーバーから上記Ｍ２Ｍクライアントに関する登録情報を除去しなければならない。

− 読み取り（Ｒｅａｄ）
“読み取り”動作命令は、個別リソース、アレイ（ａｒｒａｙ）のリソースインスタンス、客体インスタンス又は客体の全ての客体インスタンスの値に接近（読み取り）するために用いられ、次のようなパラメータを有する。

− 探索（Ｄｉｓｃｏｖｅｒ）
“探索”動作命令は、個別リソース、客体インスタンス、客体に設定された属性（ａｔｔｒｉｂｕｔｅ、ｐａｒａｍｅｔｅｒ）を探索するために用いられる。探索動作命令はまた、特定客体内でいかなるリソースが具現（ｉｍｐｌｅｍｅｎｔ）されたかを探索するために用いられる。リターンされる値は、リソースの属性を含む各リソースに対するアプリケーション／リンク−フォーマットＣｏＲＥリンク（ＲＦＣ６６９０のａｐｐｌｉｃａｔｉｏｎ／ｌｉｎｋ−ｆｏｒｍａｔ ＣｏＲＥ形式に従うリンク）のリストである。この探索動作命令は、次のようなパラメータを有する。

上記探索命令の特異な機能としては、上記パラメータのうち、客体ＩＤのみが明示された場合には、いなかるリソースが具現されているかリターンされ、且つ客体に設定された観察（ｏｂｓｅｒｖｅ）パラメータがリターンされてもよく、上記パラメータのうち、客体インスタンスＩＤまで明示されている（すなわち、客体ＩＤと客体インスタンスＩＤが明示されている） 場合には、明示された客体インスタンスに設定された観察パラメータがリターンされてもよく、上記パラメータのうちリソースＩＤまで明示されている（すなわち、客体ＩＤ、客体インスタンスＩＤ、及びリソースＩＤが明示されている）場合には、明示されたリソースに設定された観察パラメータがリターンされてもよい。

− 書き込み（Ｗｒｉｔｅ）
“書き込み”動作命令は、リソース、アレイ（ａｒｒａｙ）のリソースインスタンス、又は客体インスタンスに、複数のリソースの値を変更（書き込み）するために用いられる。書き込み動作命令は、一つの命令によって同一の客体インスタンス内で複数のリソースが変更されることを許容する。すなわち、書き込み動作命令は、（個別リソースだけでなく）一客体インスタンスにも接近可能である。書き込み動作命令は、次のようなパラメータを有する。

− 書き込み属性（Ｗｒｉｔｅ Ａｔｔｒｉｂｕｔｅｓ）
“書き込み属性”動作命令は、リソース又は客体インスタンス、客体の属性を変更（書き込み）するために用いられる。書き込み属性動作命令は、次のようなパラメータを有する。

上記の最小周期、最大周期、超過（Ｇｒｅａｔｅｒ Ｔｈａｎ）、未満（Ｌｅｓｓ Ｔｈａｎ）及びステップ（Ｓｔｅｐ）は、観察動作命令でのみ用いられる。最大及び／又は最小周期パラメータは、どれくらい頻繁に“通知（Ｎｏｔｉｆｙ）”動作命令が観察された客体インスタンス又はリソースのためにＭ２Ｍクライアントによって送信されるかを制御するために用いられる。超過、未満、及びステップパラメータは、リソースＩＤが指示された場合にのみ有効である。超過、未満、及びステップパラメータは、リソースタイプが数（例えば、整数、小数（ｄｅｃｉｍａｌ））である場合にのみ支援されるべきである。

− 実行（Ｅｘｅｃｕｔｅ）
“実行”動作命令は、ある動作を開始するためにＭ２Ｍサーバーで使用し、個別リソースに対してのみ行うことができる。Ｍ２Ｍクライアントは、“実行”動作命令が客体インスタンス又はリソースインスタンスに対して受信された場合、エラーをリターンする。実行動作命令は次のようなパラメータを有する。

− 生成（Ｃｒｅａｔｅ）
“生成”動作命令は、Ｍ２Ｍクライアント内に客体インスタンスを生成するためにＭ２Ｍサーバーで用いる。“生成”動作命令は、客体又はまだインスタンス化（又は、実体化（ｉｎｓｔａｎｔｉａｔｅ））されていない客体インスタンスの一つをターゲット（ｔａｒｇｅｔ）としなければならない。

Ｍ２ＭサーバーによってＭ２Ｍクライアントで生成された客体インスタンスは、Ｍ２Ｍクライアントによって支援される客体タイプでなければならず、デバイス登録インターフェースの“登録”及び“更新”動作命令を用いてＭ２Ｍサーバーに、Ｍ２Ｍクライアントによって通知される客体インスタンスでなければならない。

最大一つの客体インスタンスを支援する客体には、該客体インスタンスが生成されると、０の客体インスタンスＩＤを割り当てなければならない。“生成”動作命令は、次のパラメータを有する。

− 削除（Ｄｅｌｅｔｅ）
“削除”動作命令は、Ｍ２Ｍクライアント内客体インスタンスを削除するためにＭ２Ｍサーバーのために用いられる。Ｍ２ＭサーバーによってＭ２Ｍクライアントから削除された客体インスタンスは、デバイス登録インターフェースの“登録”及び“更新”動作命令を用いてＭ２Ｍサーバーに、Ｍ２Ｍクライアントによって通知される客体インスタンスでなければならない。削除動作命令は、次のようなパラメータを有する。

− 観察（Ｏｂｓｅｒｖｅ）
Ｍ２Ｍサーバーは、Ｍ２Ｍクライアント内特定リソース、客体インスタンス内のリソース、又は客体の全客体インスタンスの変更に対する観察要求を開始することができる。“観察”動作命令のための関連パラメータは、“書き込み属性”動作命令で設定される。観察動作命令は、次のパラメータを有する。

− 取消観察（Ｃａｎｃｅｌ Ｏｂｓｅｒｖｅ）
“取消観察”動作命令は、Ｍ２ＭサーバーからＭ２Ｍクライアントに客体インスタンス又はリソースに対する観察関係を終了するために送信される。取消観察動作命令は、次のパラメータを有する。

接近制御技法
以下、Ｍ２Ｍで用いられる接近制御方法を説明する。

− 接近権限取得
Ｍ２Ｍクライアントが一つのＭ２Ｍサーバー客体インスタンスを有すると、Ｍ２Ｍクライアントは、上記一つのＭ２Ｍサーバーに対する接近制御を行わず、すなわち、接近制御客体インスタンスを確認せず、上記Ｍ２Ｍサーバーは当該リソースに対する全ての権限を有する。

仮に、Ｍ２Ｍクライアントが２つ以上のＭ２Ｍサーバー客体インスタンスを有すると、上記Ｍ２Ｍクライアントは、接近しようとする客体インスタンス又はリソースの属した客体インスタンスに対する当該サーバーのＡＣＬを、接近制御客体インスタンスから探す。仮に、当該Ｍ２ＭサーバーＩＤに該当する接近権限がＡＣＬに存在すると、当該Ｍ２Ｍサーバーは当該接近権限を有する。該当するＭ２ＭサーバーＩＤのＡＣＬエントリーが存在しないと、Ｍ２Ｍクライアントは、デフォルトサーバーＩＤに割り当てられた接近権限がＡＣＬに存在するか確認し、上記デフォルトサーバーＩＤが存在すると、当該Ｍ２ＭサーバーはデフォルトサーバーＩＤの接近権限を有する。Ｍ２ＭサーバーＩＤに該当する接近権限が存在せず、上記デフォルトサーバーＩＤの接近権限も存在しないと、当該Ｍ２Ｍサーバーは当該リソースに対する接近権限を有しない。

− 接近制御客体（Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｏｂｊｅｃｔ）
接近制御客体は、Ｍ２Ｍサーバーが動作命令を行うための接近権限を有しているか否かをチェックするために用いられる。それぞれの接近制御客体インスタンスは、特定客体インスタンスに対するＡＣＬ（Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｌｉｓｔ）を含む。

− 認証手順
Ｍ２Ｍサーバーから伝達された動作命令に対して認証手順を通過するためには、次の２つを満たさなければならない。第一に、Ｍ２Ｍサーバーが該当のリソース（例えば、客体インスタンス、リソース）に対して上記伝達された動作命令を行う権限（すなわち、接近権限）があるか、第二に、該当のリソースが上記伝達された動作命令を支援するか、を満たさなければならない。このように、本発明の一実施例による接近権限認証手順は、２ステップ、すなわち、階層的な構造で行われる。

Ｍ２Ｍクライアントは、該当のリソースに対して接近権限がないと、エラーメッセージを送信し、該当のリソースが上記伝達された動作命令を支援できない場合には、該当のリソースに関する情報をＭ２Ｍサーバーに伝達することによって、どのリソースによって上記伝達された動作命令が行われなかったことを知らせる。認証手順は、３−レベル、すなわち、リソース、客体インスタンス、客体に対してやや異なる。

−リソースに対する動作命令
仮にＭ２Ｍサーバーが個別リソースに接近すると、すなわち、Ｍ２Ｍサーバーが個別リソースに対する動作命令をＭ２Ｍクライアントに送信すると、該Ｍ２Ｍクライアントは、上述した接近権限を取得する方法によって上記個別リソースの属する客体インスタンスに対するＭ２Ｍサーバーの接近権限を取得し、この接近権限が上記動作命令を行うように承認されているか否かをチェックすることができる。

仮に上記動作命令が許容されないと、上記Ｍ２Ｍクライアントは上記Ｍ２Ｍサーバーに“接近権限許容が拒絶される”というエラーコードを送信しなければならない。

仮に上記動作命令が許容されると、Ｍ２Ｍクライアントは、上記個別リソースが上記動作命令を支援するか否かを検証することができる。

仮に上記動作命令が上記個別リソースによって支援されないと、上記Ｍ２Ｍクライアントは上記Ｍ２Ｍサーバーに“動作命令が支援されない”というエラーコードを送信しなければならない。

仮に上記個別リソースが上記動作命令を支援すると、上記Ｍ２Ｍクライアントは上記動作命令を実行することができる。

− 客体インスタンスに対する動作命令
仮にＭ２Ｍサーバーが客体インスタンスにアクセスすると、すなわち、上記Ｍ２Ｍサーバーが客体インスタンスに対する動作命令をＭ２Ｍクライアントに送信すると、上記Ｍ２Ｍクライアントは、上述した接近権限取得方法によって客体インスタンスに対するＭ２Ｍサーバーの接近権限を取得し、上記接近権限が上記動作命令を行うように承認されているか否かチェックすることができる。

仮に上記動作命令が許容されないと、上記Ｍ２Ｍクライアントは上記Ｍ２Ｍサーバーでに“接近権限許容が拒絶される”というエラーコードを送信しなければならない。

仮に上記動作命令が許容されると、上記Ｍ２Ｍクライアントは、上記動作命令に基づいて次の手順を行うことができる。

“書き込み（Ｗｒｉｔｅ）”動作命令に対して、上記Ｍ２Ｍクライアントは、上記動作命令で伝達された全てのリソースが“書き込み”動作命令を行うように許容された場合にのみ、上記客体インスタンスに対する動作命令を行うことができる。仮に（上記動作命令で伝達された）いなかるリソースでも上記“書き込み”動作命令を支援しないと、上記Ｍ２Ｍクライアントは上記Ｍ２Ｍサーバーに“動作命令が支援されない”というエラーコードを送信することによって、上記動作命令を支援しないリソースを知らせることができる。

“読み取り（Ｒｅａｄ）”動作命令に対して、上記Ｍ２Ｍクライアントは、“読み取り”動作命令を支援しないリソースを除く全てのリソースを読み（ｒｅｔｒｉｅｖｅ）、上記読み取ったリソース（ｒｅｔｒｉｅｖｅｄ Ｒｅｓｏｕｒｃｅｓ）情報を上記Ｍ２Ｍサーバーに送信することができる。

“生成（Ｃｒｅａｔｅ）”動作命令に対して、上記Ｍ２Ｍクライアントは、上記動作命令で伝達された全てのリソースが“書き込み”動作命令を行うように許容され、全ての必須リソースが特定された場合にのみ、上記客体インスタンスに対する動作命令を行うことができる。仮に、（上記動作命令に含まれた）いなかるリソースでも上記“書き込み”動作命令を支援しなと、上記Ｍ２Ｍクライアントは、上記Ｍ２Ｍサーバーに“動作が支援されない”というエラーコードを送信することによって、上記動作命令を支援しないリソースを知らせることができる。仮に全ての必須リソースが特定されないと、上記Ｍ２Ｍクライアントは上記Ｍ２Ｍサーバーに“Ｂａｄ Ｒｅｑｕｅｓｔ”というエラーコードを送信することができる。

“削除（Ｄｅｌｅｔｅ）”、“観察（Ｏｂｓｅｒｖｅ）”、“書き込み属性（Ａｔｔｒｉｂｕｔｅ）”、又は“探索（Ｄｉｓｃｏｖｅｒ）”動作命令に対して、上記Ｍ２Ｍクライアントは上記動作命令を行わなければならない。すなわち、上記Ｍ２Ｍクライアントは、上記客体インスタンスに対する動作命令が上記客体インスタンスに属した全てのリソースによって支援されるか否かをチェックせずに、上記の削除（Ｄｅｌｅｔｅ）”、“観察（Ｏｂｓｅｒｖｅ）”、“書き込み属性（Ａｔｔｒｉｂｕｔｅ）”、又は“探索（Ｄｉｓｃｏｖｅｒ）”動作命令を行わなければならない。

仮に前述した動作命令以外の動作命令に対しては、上記Ｍ２Ｍクライアントは上記動作命令を行ってはならず、上記Ｍ２Ｍサーバーに“動作が支援されない”というエラーコードを送信しなければならない。

客体インスタンスに対する動作命令についてまとめると、客体インスタンスに対してＭ２Ｍサーバーが接近権限を有するか否かが上記の接近権限取得方法によって行われる。その後、上記客体インスタンスに属した個別リソースが上記動作命令を支援するか否かが確認されるが、この過程は、上記動作命令の種類によっては行われなくてもよい。

− 客体に対する動作命令
客体に対する動作命令も、動作命令の種類によって定義される。

Ｍ２Ｍサーバーが“読み取り”動作命令を客体に送信すると、すなわち、客体に対する“読み取り”動作命令をＭ２Ｍクライアントに送信すると、上記Ｍ２Ｍクライアントは、上記客体に属する（又は、下位の）客体インスタンスのうち、上記Ｍ２Ｍサーバーが接近権限を有する客体インスタンスの情報を集めてＭ２Ｍサーバーに伝達することができる。上記Ｍ２Ｍサーバーが接近権限を有するか否かは、前述した接近権限取得方法によって行われる。

上記Ｍ２Ｍサーバーが接近権限を有する客体インスタンスの情報は、上記Ｍ２Ｍクライアントが上記“読み取り”動作命令を支援しないリソースを除く全てのリソースを読み（ｒｅｔｒｉｅｖｅ）、上記Ｍ２Ｍサーバーに上記読み取ったリソース情報を意味する。

上記Ｍ２Ｍサーバーが“生成（Ｃｒｅａｔｅ）”動作命令を客体に送信すると、すなわち、上記Ｍ２Ｍサーバーが客体に対する“生成”動作命令をＭ２Ｍクライアントに送信すると、上記Ｍ２Ｍクライアントは、前述した接近権限取得方法によって、上記Ｍ２Ｍサーバーが上記客体に対する接近権限を有するか否かを確認することができる。

上記Ｍ２Ｍサーバーが上記客体に対する接近権限があると、上記Ｍ２Ｍクライアントは、単に上記動作命令で伝達された全てのリソースが“書き込み（Ｗｒｉｔｅ）”動作命令を行うように許容され、全ての必須リソースが特定される場合にのみ、上記動作命令を行うことができる。仮に（上記動作命令で伝達された）いかなるリソースも上記“書き込み”動作命令を支援しないと、上記Ｍ２Ｍクライアントは、上記Ｍ２Ｍサーバーに“動作命令が支援されない”というエラーコードを送信することによって、上記動作命令を支援しないリソースを知らせることができる。仮に、全ての必須リソースが特定されないと、上記Ｍ２Ｍクライアントは、“Ｂａｄ Ｒｅｑｕｅｓｔ”というエラーコードを上記Ｍ２Ｍサーバーに送信することができる。すなわち、上記Ｍ２Ｍクライアントは、この場合、上記Ｍ２Ｍサーバーによる動作命令が誤っていることを上記Ｍ２Ｍサーバーに知らせる。

“探索（Ｄｉｓｃｏｖｅｒ）”動作命令に対して、Ｍ２Ｍクライアントは、上記動作命令を行わなければならない。すなわち、“探索”動作命令に対しては、上記Ｍ２Ｍクライアントは、上記Ｍ２Ｍサーバーが上記客体下位の全ての客体インスタンスに対する接近権限を有するか否かと、上記全ての客体インスタンスに属した全てのリソースが上記“探索”動作命令を支援するか否か、をチェックしない。

“観察（Ｏｂｓｅｒｖｅ）”又は“書き込み属性（Ｗｒｉｔｅ Ａｔｔｒｉｂｕｔｅｓ）”動作命令に対して、上記Ｍ２Ｍクライアントは上記動作命令を行わなければならない。すなわち、“観察”又は“書き込み属性”動作命令に対しては、上記Ｍ２Ｍクライアントは、上記Ｍ２Ｍサーバーが上記客体下位の全ての客体インスタンスに対する接近権限を有するか否かと、上記全ての客体インスタンスに属した全てのリソースが上記“観察”又は“書き込み属性”動作命令を支援するか否かをチェックしない。

上述した動作命令以外の動作命令に対しては、上記Ｍ２Ｍクライアントは動作命令を行ってはならず、“動作が支援されない”というエラーコードを上記Ｍ２Ｍサーバーに送信することができる。

客体に対する動作命令についてまとめると、客体に対してＭ２Ｍサーバーが接近権限を有するか否かは、上記客体に対する特定動作命令によって上記の接近権限取得方法によって行われるか否かが決定される。その後、上記客体インスタンスに属した個別リソースが上記動作命令を支援するか否かが確認され、この過程は、上記動作命令の種類によっては行われなくてもよい。また、客体に対する動作命令の場合、特定動作命令に対しては、接近権限を有するか否かと上記特定動作命令を支援するか否かは確認しなくてもよい。

ファームウェア／ソフトウェア変更の通知

本発明の一実施例によれば、Ｍ２Ｍクライアントは、ファームウェア又はソフトウェアの変更（例えば、アップデート、設置、除去など）による自身の変更された情報を、自身が登録されている又は連結（ｃｏｎｎｅｃｔｉｏｎ）を有する一つ以上のＭ２Ｍサーバーに通知することができる。この動作の本発明の一実施例を図４に示す。

図４を参照すると、サーバー１は、クライアントローファームウェア又はソフトウェアの変更を指示することができる。これは、前述した“実行”動作命令を送信することによって行い、例えば、ファームウェア又はソフトウェア関連客体インスタンスの特定リソース（例えば、アップデートリソース）の実行を上記クライアントに要求することによって行うことができる。なお、上記動作命令に対する認証手順も、前述したとおりに行われるが、本実施例では、説明の簡略化のためにその具体的な説明を省略する。

上記の“実行”動作命令に対する認証手順が完了すると、クライアントは“実行”動作命令を行い、これによってファームウェア又はソフトウェアを変更することができる。クライアントはファームウェア又はソフトウェアが変更されると、これに関する情報を、前述した装置登録インターフェースでアップデート動作命令又は登録動作命令を用いて各Ｍ２Ｍサーバーに通知することができる。以下、このような通知ついてより詳しく説明する。

− 通知対象
通知の対象は、Ｍ２Ｍクライアントと現在接続又はセッションを結びつけているＭ２Ｍサーバーであってもよく、又はＭ２Ｍクライアント内のＭ２Ｍサーバーアカウントに記憶されている全Ｍ２Ｍサーバーであってもよい。現在接続又はセッションを結びつけていないＭ２Ｍサーバーに送信する場合、現在接続又はセッションを結びつけていないＭ２Ｍサーバーであっても、当該通知から、Ｍ２Ｍクライアントのファームウェア又はソフトウェア変更によってＭ２Ｍクライアントの支援する機能が変更されたことを認識できるようにし、これによって当該Ｍ２Ｍサーバーが上記の変更された機能を使用できるようにする。

又は、通知の対象は、あらかじめ各Ｍ２Ｍクライアント別に特定されており、各Ｍ２Ｍクライアントは、特定された通知の対象に通知を伝達することもできる。通知対象は、Ｍ２Ｍサーバーに限定されず、Ｍ２Ｍクライアントが通知対象の接続関連情報（例えば、識別子、アドレス）を持っていて接続可能な他のエンティティ（例えば、アプリケーション）であってもよい。

又は、Ｍ２Ｍクライアントが登録されたＭ２Ｍサーバーにアップデート動作命令又は登録動作命令を送信して通知を伝達することもできる。

− 通知指示子
通知の伝達又は送信は、通知のための指示子（以下、通知指示子）が設定されている場合にのみ行われる方案を考慮することができる。この場合には、通知指示子の値が通知の活性化を示す場合にのみ通知が行われ、そうでない場合には通知は行われなくてもよい。通知指示子は、ファームウェア又はソフトウェア関連アップデート客体に存在するアップデート又は登録指示子リソースの値であってもよい。

又は、ファームウェア又はソフトウェア変更されたとき、１）Ｍ２Ｍクライアントで支援する機能が変更されたとき、２）Ｍ２Ｍクライアントが、変更された機能が重要だと判断するとき、又は３）Ｍ２Ｍサーバーがあらかじめ設定しておいた基準を満たすとき、変更に対する通知が行われてもよい。

要するに、Ｍ２Ｍクライアントは、通知指示子が特定値に設定されており、ファームウェア又はソフトウェアの変更によって支援する機能が変更（すなわち、支援する客体の変更）されると、アップデート又は登録動作命令を該当のＭ２Ｍサーバーに送信することができる。

通知指示子はＭ２Ｍサーバーが設定し、設定は、前述した“書き込み”動作命令を用いて通知指示子に該当する特定リソースに特定値を記録することによって行うことができる。Ｍ２Ｍクライアントは、その設定された値を読み込み（例えば、“読み取り”動作命令を用いて）、それによって行う。通知指示子の値が設定されていなくてもよく、その場合には、デフォルト（ｄｅｆａｕｌｔ）値が存在し、Ｍ２Ｍクライアントはこのデフォルト値で通知指示子を認識する。

− 通知時間
通知を伝達又は送信する際、Ｍ２Ｍクライアントは、ファームウェア又はソフトウェアの変更直後に又はできるだけ早く通知を送信することができる。

なお、Ｍ２Ｍクライアントはアップデート動作命令を周期的にＭ２Ｍサーバーに送信するが、このアップデート動作命令を送信する周期でなくても、ファームウェア又はソフトウェアの変更を通知するためにアップデート動作命令又は登録動作命令をＭ２Ｍサーバーに送信することができる。

又は、通知のための時間があらかじめ設定されていたり、ファームウェア又はソフトウェアをアップデートするための動作命令に含まれていてもよく、Ｍ２Ｍクライアントは当該時間に通知を送信してもよい。又は、Ｍ２Ｍクライアントは特定時間における任意選択した時点で通知を送信してもよい。

− 通知内容
− 第１案
Ｍ２Ｍクライアントはファームウェア又はソフトウェア変更によって支援される又は使用可能な機能又は客体（又は、客体インスタンス）（以下、簡略に“機能（ｆｕｎｃｔｉｏｎａｌｉｔｙ）”という。）をＭ２Ｍサーバーに知らせることができる。支援される又は使用可能な機能は、Ｍ２Ｍクライアントで支援されたり使用可能な全ての機能を含んでもよく、又は変更によって新しく支援されたり使用可能になった機能のみを含んでもよい。すなわち、Ｍ２Ｍクライアントは、自身が支援する機能のリスト及び／又は変更によって新しく支援したり使用可能になった機能のリストを、アップデート／登録動作命令を用いてＭ２Ｍサーバーに知らせることができる。

− 第２案
Ｍ２Ｍクライアントは、ファームウェア又はソフトウェアの変更事実のみをＭ２Ｍサーバーに知らせることができる。その後、Ｍ２Ｍサーバーは、Ｍ２Ｍクライアントがいかなる機能を支援したり使用可能であるかを読み込み（ｒｅｔｒｉｅｖｅ）、それに関する情報を取得することができる。言い換えると、Ｍ２ＭサーバーはＭ２Ｍクライアントが支援する又は使用可能な機能のリストを読み込むことができる。一方、接近制御によって通知を受けた全てのＭ２Ｍサーバーがリストを読み込むこともでき、いくつかのＭ２Ｍサーバーのみがリストを読み込むこともできる。

機能削除
ファームウェア変更又はソフトウェア変更を通じて特定機能が追加されてもよいが、削除されてもよい。機能が削除される場合、関連資料構造は削除される。ファームウェア変更又はソフトウェア変更によって通知を受けたＭ２Ｍサーバーが、削除された機能関連資料構造を削除してもよく、削除された機能関連資料構造をＭ２Ｍクライアント自体で削除してもよい。このとき、資料構造の関連資料構造も削除する。例えば、Ｍ２Ｍクライアントは削除された機能（客体）に対して関連客体インスタンスを削除し、客体と関連した接近制御客体インスタンスを削除する。

Ｍ２Ｍサーバーによって使用可能な機能
Ｍ２Ｍサーバーが特定Ｍ２Ｍクライアントで使用可能な機能があらかじめ設定されていてもよい。この場合には、Ｍ２Ｍサーバーが使用可能な機能とＭ２Ｍクライアントが支援する機能とを比較し、両者間の積集合から、実際に使用可能な機能を導出することができる。Ｍ２Ｍサーバーが積集合以外の機能に接近すると、エラーが発生する。

Ｍ２ＭクライアントのＭ２ＭサーバーアカウントにＭ２Ｍサーバーが生成可能な客体（ｃｒｅａｔａｂｌｅ Ｏｂｊｅｃｔ）が設定されていてもよい。このようにＭ２Ｍサーバーが生成可能な客体とＭ２Ｍクライアントの支援オブジェクトのリストとの比較（積集合）から、Ｍ２ＭサーバーがＭ２Ｍクライアントに生成可能な客体のリストが導出される。リストに明示されていない客体を生成しようとするとエラーが発生し、リストに明示されている客体は、Ｍ２Ｍサーバーが生成することができる。

また、Ｍ２ＭサーバーアカウントにＭ２Ｍサーバーが生成可能な客体にワイルドカード（ｗｉｌｄｃａｒｄ）を挿入することもできる。これは、Ｍ２ＭサーバーがＭ２Ｍクライアントの全客体を生成できる権限を有するということを意味する。今までは、新しく追加される機能（Ｏｂｊｅｃｔ）に対して権限を有するには、常に、新しく追加される機能に対してＡＣＬを変更しなければならない設定（ｃｏｎｆｉｇｕｒａｔｉｏｎ）が必要であり、また、該当機能を生成する権限を有するには、ブートストラップが必要であり、面倒だった。しかし、ワイルドカードを挿入すると、将来に使用される機能に対しても生成できる権限が与えられる。このような機能は、最高の権限を有するＭ２Ｍサーバーが存在する場合に容易に使用できる。

利用可能な機能購読（ｓｕｂｓｃｒｉｐｔｉｏｎ）
Ｍ２Ｍサーバーは、Ｍ２Ｍクライアントで可能な機能が変更されることを知るために購読（ｓｕｂｓｃｒｉｐｔｉｏｎ）を設定することができる。すなわち、Ｍ２Ｍクライアントで可能な機能が変更されたとき、これを購読したＭ２Ｍサーバーが、変更された結果を得ることができる。購読は、Ｍ２Ｍサーバーから可能な機能変更通知を得ようとする場合に用いられるため、購読したＭ２Ｍサーバーのみが該当の結果値を得ることができる。購読時にフィルターが存在してもよく、フィルターは、特定機能又は特定機能分類、機能識別子範囲に該当する機能が追加／変更された際に知らせるようにする機能を提供することができる。購読のターゲットは、特定ＵＲＩ（ＵＲＬ）に設定することができる。これによって、ファームウェア又はソフトウェアアップデート（例えば、アプリケーションアップデート）によって変更される機能についてサーバーは認知することができる。一方、購読無しに、新しい機能が発見されると、接続されている（登録されている）全サーバーに機能を送信することもできる。

また、特定時間があらかじめ設定されていたり、特定時間が購読要求メッセージに含まれていると、Ｍ２Ｍクライアントは、当該時間にＭ２Ｍサーバーに、変更される機能通知を送信することができる。又は、Ｍ２Ｍクライアントが、特定時間における任意選択された時点で機能通知を送信することもできる。

図５に、本発明の一実施例に係る購読関連手順を示す。

エンティティ１は、エンティティ２の支援されるリソース又はリソースグループ（以下、図５に関す説明では簡略に“支援されるリソース”という。）が変更されることを確認するために、エンティティ２に対して購読（ｓｕｂｓｃｒｉｐｔｉｏｎ）を行うことができる（Ｓ５１）。このとき、購読はデフォルト（ｄｅｆａｕｌｔ）として全体又は特定リソースに対して設定することができる。一方、図５に関する説明で、“支援されるリソース”を他の用語で表現することもできる。例えば、“支援されるリソース”は、支援されるリソース又は支援されるリソースグループだけでなく、支援されるリソース類型（ｒｅｓｏｕｒｃｅ ｔｙｐｅ）又は支援される属性（ａｔｔｒｉｂｕｔｅ）など、リソース又はリソースグループの定義、機能変更と関連したあらゆる情報を意味する用語に言い換えてもよい。

また、エンティティ１は、変更の通知のための購読に特定条件を設定することができる（Ｓ５２）。すなわち、設定された特定条件を満たす場合にのみ、変更に対する通知がなされてもよい。特定条件を設定することを、フィルタリング、又はフィルターを設定すると表現することができる。

一方、上記Ｓ５２は上記Ｓ５１より先に行われたり、同時に行われたりしてもよい。また、上記Ｓ５１及びＳ５２の購読及びフィルタリングの設定は、“支援されるリソース”と関連した特定リソースを生成して特定値を記録（生成）したり、当該特定リソースの値を変更することによって行うことができる。

エンティティ２の上記購読が設定された“支援されるリソース”が変更されたと仮定する（Ｓ５３）。エンティティ２は、上記Ｓ５２で設定された特定条件を満たすか否かを確認することができる（Ｓ５４）。特定条件を満たすと、エンティティ２は、上記“支援されるリソース”が変更されたことをエンティティ１に通知することができる（Ｓ５５）。

図５に関連する本発明の他の実施例は、“支援されるリソース”に代えて、エンティティ２の特定機能又は性能（ｃａｐａｂｉｌｉｔｙ）（以下、簡略に“機能”という。）に対して行われてもよい。この場合、端末に実体化されたリソースの変更購読のためのメッセージと“機能”の変更購読のためのメッセージとが、異なる形態を有することができる。当該メッセージがターゲットとする対象が同一であっても、エンティティ２は両メッセージを区別することができる。この区別は、例えば、クエリーストリング（ｑｕｅｒｙ ｓｔｒｉｎｇ）から可能である。

また、“機能”に対しては特定動作命令（例えば、生成、読み取り、アップデート、削除など）を行うことができないか、又はいくつかの動作命令のみを行うことができる。“機能”に対する特定動作命令は、端末に実体化されたリソースに対する動作命令と異なる方式で行われる。このため、好ましくは、購読が、リソースに対するものか又は“機能”に対するものかを示すための情報（例えば、指示子）を当該メッセージに含めることができる。

より具体的に、“機能”に対する変更購読のためのメッセージは、リソースタイプネーム又はリソースタイプを識別できる識別子を含み、属性に対する変更購読のためのメッセージは、属性ネームを含むことができる。

リソースの変更購読のためのメッセージは、リソースタイプネーム又はリソースタイプを識別できる識別子を含まなくてもよい。

例えば、エンティティ１が“読み取り（ｒｅｔｒｉｅｖｅ）”動作命令をエンティティ２のリソースタイプをターゲットとして送信する場合、エンティティ２は、リソースタイプが支援されると、リソースタイプが支援されること又はリソースタイプが支援する機能のリストを、エンティティ１に応答メッセージで送信し、当該リソースタイプが支援されないと、支援されないこと（存在しないこと）を、応答メッセージでエンティティ１に伝達することができる。また、エンティティ１が“読み取り”動作命令をエンティティ２のリソースタイプをターゲットとして送信する場合、エンティティ２は、属性が支援されると、属性が支援されることを、エンティティ１に応答メッセージで送信し、属性が支援されないと、支援されないこと（存在しないこと）をエンティティ１に応答メッセージで伝達することができる。

リソースタイプに対する“読み取り”動作命令は、リソースタイプネーム又はリソースタイプを識別できる識別子が含むことができる。

“読み取り”動作命令が、リソースタイプが実体化されたリソースに対して送信される場合、当該リソース、属性の実際値を応答メッセージで送信することができる。当該“読み取り”動作命令には、リソースタイプネーム又はリソースタイプを識別できる識別子が含まれなくてもよい。他の動作命令はリソースタイプに対して用いられなくてもよい。

“機能”
“機能”は、リソースタイプ又は属性を支援するか否かで表現することができる。すなわち、ある機能をエンティティが提供するという意味は、特定のリソースタイプ又は属性を支援することを意味でき、リソースタイプ又は属性として他のエンティティに露出されない機能は支援されないことを意味する。すなわち、エンティティ１がエンティティ２のリソースタイプ又は属性に動作命令を送信した場合、当該動作命令に対する応答に、当該リソースタイプ又は属性が支援されない（ｎｏｔ ｓｕｐｐｏｒｔｅｄ）、又は存在しない（ｎｏｔ ｆｏｕｎｄ）という内容が含まれる（例えば、応答コードに含まれる）と、当該リソースタイプ又は属性はエンティティ２で支援されなく、当該リソースタイプ又は属性が提供する機能も支援されないことを意味する。上記応答に、上記の内容以外の内容（例えば、支援される（ｓｕｐｐｏｒｔｅｄ）、存在する（ｅｘｉｓｔ）、又は当該機能関連情報）が含まれると、当該リソースタイプ又は属性がエンティティ２で支援され、エンティティ２は、当該リソースタイプ又は属性が提供する機能を有しているということを意味する。

リソースタイプは、言葉の通り、リソースのタイプであり、タイプごとに（下位、ｃｈｉｌｄ）特定リソースタイプ又は属性群の集合を有する。リソースタイプは、テンプレート（ｔｅｍｐｌａｔｅ）又は型の概念であり、このリソースタイプに属するリソースタイプ又は属性群は、値を有することができず、リソースタイプが“生成”動作命令によって実体化されると、このリソースタイプが実体化されたリソース又は属性群は値を有することができ、このリソース又は属性群、又はそれぞれのリソース又は属性に対して動作命令（すなわち、読み取り、アップデート、削除など）を行うことができる。

リソースタイプは、（子孫）リソースタイプ及び属性で構成することができ、動作命令の実行は、リソースタイプ、子孫リソースタイプ、属性ごとにあらかじめ設定されている。

図５と関連した説明で、エンティティ１はＡＥ又はＣＳＥであり、エンティティ２はＣＳＥであり、エンティティ１とエンティティ２は、互いに異なるエンティティである。以下、ＡＥとＣＳＥについて具体的に説明する。

ＡＥ（Ａｐｐｌｉｃａｔｉｏｎ Ｅｎｔｉｔｙ）：ＡＥは、端−対−端Ｍ２Ｍソリューションのためのアプリケーションロジックを提供する。ＡＥの例には、物流追跡アプリケーション、遠隔血糖モニタリングアプリケーション、遠隔パワーメータリングアプリケーションなどがある。

ＣＳＥ（Ｃｏｍｍｏｎ Ｓｅｒｖｉｃｅｓ Ｅｎｔｉｔｙ）：ＣＳＥは、サービス機能の集合で構成され、これらのサービス機能は、Ｍ２Ｍ環境で共通に用いられる機能であり、ｏｎｅＭ２Ｍで明示した機能である。このようなサービス機能は、Ｍｃａ、Ｍｃｃレファレンスポイント（インターフェース）を介して他のエンティティに露出される。

Ｎｏｄｅ：ｏｎｅＭ２Ｍのノードは機能的なエンティティであり、少なくとも一つのＣＳＥ及び／又はＡＥを有しなければならない。ノードは、Ｍ２Ｍデバイス、ゲートウェイ、サーバー内に存在することができる。

ＡＥとＣＳＥは論理的にノード（例えば、ａｐｐｌｉｃａｔｉｏｎ ｓｅｒｖｉｃｅ ｎｏｄｅ、ａｐｐｌｉｃａｔｉｏｎ ｄｅｄｉｃａｔｅｄ ｎｏｄｅ、ｍｉｄｄｌｅ ｎｏｄｅ、ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ｎｏｄｅ）に存在し、物理的には、Ｍ２Ｍ装置、Ｍ２Ｍゲートウェイ、Ｍ２Ｍサーバー、すなわちＭ２Ｍ関連装置に存在することができる、この側面から、ＡＥとＣＳＥは、Ｍ２Ｍ装置、Ｍ２Ｍゲートウェイ又はＭ２Ｍサーバー（インフラストラクチャー）と呼ぶこともできる。

以下、サーバー保安客体（又は、客体インスタンス）、サーバー客体（又は、客体インスタンス）、及びファームウェアアップデート客体（又は、客体インスタンス）について簡略に説明する。

Ｍ２Ｍサーバー保安客体（又は、客体インスタンス）は、特定されたＭ２Ｍサーバー又はＭ２Ｍブートストラップサーバーに接近するに適したＭ２Ｍクライアントのキー材料（ｋｅｙｉｎｇ ｍａｔｅｒｉａｌ）を提供する。一つの客体インスタンスはＭ２Ｍブートストラップサーバーをアドレス（ａｄｄｒｅｓｓ）することを推奨する。Ｍ２Ｍサーバー保安客体のリソースは、Ｍ２Ｍブートストラップサーバー又はスマートカードからのブートストラップインターフェースを介して変更されてもよいが、他のいかなるＭ２Ｍサーバーによっても接近不可能である。

次に、Ｍ２Ｍサーバー客体（又は、客体インスタンス）について説明する。Ｍ２Ｍサーバー客体は、Ｍ２Ｍサーバーと関連したデータを提供する。Ｍ２Ｍブートストラップサーバーは、それと関連したこのような客体インスタンスを有しない。

次に、ファームウェアアップデート客体（又は、客体インスタンス）を説明する。ファームウェアアップデート客体は、Ｍ２Ｍクライアントにアップデートされるファームウェアの管理を可能にする。ファームウェアアップデート客体は、ファームウェアパッケージ設置、ファームウェアアップデート、及びファームウェアアップデート以降の動作を行うことを定義する。

図６は、本発明の一実施例に係るファームウェアアップデートの結果を通知する手順を示す図である。本実施例を説明では、前述した内容を参照するものとする。

Ｍ２Ｍサーバー（以下、“サーバー”という。）は、通知を指示するための指示子の設定をＭ２Ｍクライアント（以下、“端末”という。）に要求することができる（Ｓ６１）。通知を指示するための指示子は、即刻の非周期的な通知のためのものであり、前述したように、指示子が非周期的な通知のための特定値を有するように設定されないと、周期的な通知によってアップデートの結果（例えば、変更された客体、支援するリソースグループ、又は機能など）を伝達することができる。

さらにいうと、指示子は、端末内の特定実体化されたリソースグループ（すなわち、客体インスタンス）内の特定リソースであってもよく、例えば、上述したファームウェアアップデート客体インスタンスの“Ｕｐｄａｔｅ Ｓｕｐｐｏｒｔｅｄ Ｏｂｊｅｃｔｓ”リソースであってもよい。“Ｕｐｄａｔｅ Ｓｕｐｐｏｒｔｅｄ Ｏｂｊｅｃｔｓ”リソースの値をｔｒｕｅに設定することによって、非周期的な通知を端末に要求することができる。

なお、“Ｕｐｄａｔｅ Ｓｕｐｐｏｒｔｅｄ Ｏｂｊｅｃｔｓ”リソースの値を特定値へと設定の要求は、上記サーバーが前述のリソースをターゲットとして“書き込み”動作命令を上記端末に送信することによって実行することができる。この“書き込み”動作命令には新しく記録する値（すなわち、ペイロード）（例えば、ｔｒｕｅ）が含まれる。

上記要求を受信すると、端末は、上記要求に対する認証手順及びその結果に基づく動作を行うことができる（Ｓ６２）。

上記認証手順は、前述した階層的認証手順であり、具体的には、接近制御客体インスタンスを通じた上記サーバーの上記リソースに対する接近権限の認証と、上記リソースが上記“書き込み”動作命令を支援するか否かの判断である。上記認証手順についての説明は、前述した内容を参照して行われるとする。

仮に上記サーバーが上記リソースに対する接近権限があり、上記リソースが上記“書き込み”動作命令を支援すると判断されると、上記端末は、上記リソースに上記新しく記録する値（すなわち、ｔｒｕｅ）を記録することができる。そうでないと、上記端末は上記サーバーに上記認証手順に失敗したことを知らせるエラーコードを送信することができる。

以下、上記認証手順が成功的に完了し、上記“Ｕｐｄａｔｅ Ｓｕｐｐｏｒｔｅｄ Ｏｂｊｅｃｔｓ”リソースの値がｔｒｕｅに設定されていると仮定する。

その後、上記サーバーは上記端末にファームウェアのアップデートを要求することができる（Ｓ６３）。例えば、上記端末に設置されたファームウェアの新しいバージョンが配布（設置）された場合である。上記要求は、上記ファームウェアアップデート客体インスタンス内の特定リソースに対する“実行”動作命令によって行われ、例えば、上記特定リソースは“Ｕｐｄａｔｅ”リソースである。上記“Ｕｐｄａｔｅ”リソースに対する実行動作命令は、“Ｐａｃｋａｇｅ”リソースのパッケージ又は“Ｐａｃｋａｇｅ ＵＲＩ”からダウンロードしたファームウェアパッケージ（イメージ）を用いて端末のファームウェアアップデートを行うように設定されている。

一方、この場合にも、上記“実行”動作命令に対する認証手順及びその結果に基づく動作実行、すなわち、ファームウェアアップデート（Ｓ６４）が必要であり、これについての説明は、前述の説明を参照すればいいので、本実施例では省略する。以下、上記Ｓ６４の認証手順も成功的に完了したと仮定する。

その後、上記端末は、上記ファームウェアアップデートが完了すると、特定条件を満たすか否か判断することができる（Ｓ６５）。さらにいうと、上記特定条件は、ｉ）上記ファームウェアアップデートによって、上記端末が支援する客体、存在する客体インスタンス、支援するリソースグループ、実体化されたリソースグループ又は機能が変更されたか、及びii）上記指示子がｔｒｕｅ値に設定されているかを含むことができる。

上記特定条件を全て満たすと、上記端末は上記サーバーに、上記ファームウェアアップデートによって変更された、自身が支援する客体又は使用可能な客体インスタンスのリストを通報することができる（Ｓ６６）。上記端末が支援する客体又は使用可能な客体インスタンスのリストは、上記ファームウェアアップデートによって変更された客体／客体インスタンスだけでなく、変更されていない客体／客体インスタンスも含む。すなわち、上記ファームウェアアップデート後に上記端末が支援する客体又は使用可能な客体インスタンスの全てを含む。これは、変更された客体／客体インスタンスのみを通報した場合に発生しうる問題点を補完するためである。これについては後述する。

一方、上記通報は、可能な限り早く伝達されることが好ましい。上記通報は、前述した“アップデート”動作命令（又は、メッセージ）又は“登録”動作命令（又は、メッセージ）を用いて行うことができる。

上記の特定条件の一つでも満たさない場合は、上記端末は、周期的に送信されるアップデート動作命令を用いて、次の周期的アップデート動作命令送信時点に、自身が支援する客体又は使用可能な客体インスタンスのリストを上記サーバーに伝達することができる（Ｓ６６−１）。

通報される情報＝客体／客体インスタンスのリスト

上記のＳ６６で、上記サーバーに伝達される情報は、上記ファームウェアアップデートによって変更された、支援される客体又は客体インスタンス（すなわち、支援されるリソースグループ又は実体化されたリソースグループ）だけでなく、変更されていない客体又は客体インスタンス（すなわち、支援されるリソースグループ又は実体化されたリソースグループ）も含むとした。次のシナリオは、上記のように、ファームウェアアップデート後に、端末が支援する客体及び利用可能な客体インスタンスの全てに関する情報（リスト）をサーバー側に通報する必要がある理由を説明する。ここで、利用可能な客体インスタンスは、端末に存在する客体インスタンスのうち、当該サーバーに露出（ｅｘｐｏｓｅ）可能な客体インスタンスを意味することができる（例えば、当該サーバーが接近できない（当該サーバーに露出されない）サーバー保安客体インスタンスを除く全ての客体インスタンス）。

表６と関連した“アップデート”動作命令（又は、メッセージ）を用いて、端末はサーバーに周期的に登録情報に対するアップデートを行う。上記登録情報には、表６に示したように、“Ｏｂｊｅｃｔｓ ａｎｄ Ｏｂｊｅｃｔ Ｉｎｓｔａｎｃｅｓ”が含まれており、これは、上記端末が支援する客体及び使用可能な客体インスタンスのリストに該当する。したがって、周期的に上記端末は上記リストを“アップデート”動作命令を通じて上記サーバーに送信し、これによって上記サーバーは少なくとも周期的に上記端末の上記リストを確認することができる。したがって、あらかじめ設定された周期の間に少なくとも２回のファームウェアアップデートが発生する場合について説明する。一方、あらかじめ設定された周期の間に１回のファームウェアアップデートがあってもよく、このファームウェアアップデートに対して変更された情報のみを通報しても、サーバーは、最も最近の周期的な通報から取得した上記端末の上記リストと上記変更された情報とを結合することで、現在の上記端末が支援する客体及び使用可能な客体インスタンスがわかる。

図７には、ファームウェアアップデート時に、変更された情報のみを通報した場合における問題点を示す。図７は、図６の一部を選択的に簡略に示しているが、実際には、図６で説明したいくつかの手順（例えば、認証手順）がさらに必要である。また、図７は、図６と違い、端末の通報時に、ファームウェアアップデートによって変更された支援客体及び使用可能な客体インスタンスのみをサーバーに送信すると仮定する。

端末は周期的な通報ｎをサーバーに送信する（Ｓ７１）。上記周期的な通報ｎには、上記端末が支援する客体及び使用可能な客体インスタンスを含むことができる。その後、上記端末はファームウェアアップデートを行うことができる（Ｓ７２）。しかし、図６と関する説明を参照して説明すると、上記通報のための指示子がｆａｌｓｅに設定されており、上記端末は上記サーバーに通報をしない。

その後、上記端末は、他のファームウェアアップデートを行うことができる（Ｓ７３）。この時、上記通報のための指示子がｔｒｕｅに設定されているため、上記端末は上記サーバーに、上記ファームウェアアップデートによって変更された情報のみを通報することができる（Ｓ７４）。すなわち、周期的通報の間に、上記サーバーは、上記Ｓ７３のファームウェアアップデートによって変更された情報のみを取得し、上記Ｓ７２のファームウェアアップデートによって変更された情報は取得できる。このため、期間Ａにおいて上記サーバーは、上記端末が支援する客体又は使用可能な客体インスタンスの正確な情報が確認できず、よって、それによる機能を利用／支援することができない。

その後、上記端末は、周期的な通報ｎ＋１をサーバーに送信し（Ｓ７５）、これによって、上記サーバーは、上記端末が支援する全ての客体及び使用可能な全ての客体インスタンスのリストを取得することができる。

一方、ファームウェアアップデートによる通報がＳ７２のファームウェアアップデートと関連してなされるとしても、同様の問題が発生する（すなわち、Ｓ７４がＳ７２とＳ７３との間で行われる）。この場合にはむしろ上記期間Ａの長さがより増えてしまう。

したがって、図６と関連して説明したように、ファームウェアアップデートによる通報であっても、上記アップデートによって変更された情報を含め、全ての情報を送信するようにすることによって、上記端末は、登録されたサーバーが上記端末の支援／使用可能な機能を全て使用できるようにすることができる。

一方、前述した実施例では“ファームウェア”を挙げて説明したが、“ファームウェア”は、“ソフトウェア”、“プログラム”、“アプリケーション”などの包括的な意味で使われたため、本発明の範囲が上記“ファームウェア”に対してのみ限定されるわけではない。

接近制御客体インスタンス類型

本発明の他の実施例によって２類型の接近制御客体インスタンスを提案する。“生成”動作命令は、これによって特定客体インスタンスが生成されると、上記“生成”動作命令を送信したＭ２Ｍサーバーは、上記生成された特定客体インスタンスに対する全ての権限を有するようになる。このように、上記“生成”動作命令は、相対的に大きい権限を付与できるため、上記“生成”動作命令のための専用接近制御客体インスタンス（以下、“第１タイプ客体インスタンス”）を提案する。

第１タイプ客体インスタンスは、特定客体インスタンスの“生成”動作命令に対する接近権限を認証するために用いることができる。一般的な接近制御客体インスタンス（表１６）を参照すると、第１タイプ客体インスタンスは、一般的な接近制御客体インスタンスのリソースのうち、Ｏｂｊｅｃｔ ＩＤとＡＣＬリソースのみが設定され、残りのリソースは設定されなくてもよい。又は、第１タイプ客体インスタンスは、一般的な接近制御客体インスタンスのリソースのうち、Ｏｂｊｅｃｔ ＩＤとＡＣＬリソースのみが設定され、残りのリソースは任意の値に設定されてもよい。ＡＣＬリソースにはＭ２Ｍサーバー及び生成可能か否かが明示されているため、Ｍ２ＭサーバーがＯｂｊｅｃｔ ＩＤに該当する客体の客体インスタンスを生成できるか否かをＭ２Ｍクライアントが判断できる。

第１タイプ客体インスタンスによって指示される値によって、“生成”動作命令に対する接近権限認証を行うことができる。当然ながら、上記第１タイプ客体インスタンスのリソース及びリソースの値が指示するＭ２Ｍサーバーのみが、上記リソースの値が指示する特定客体の客体インスタンスに対して上記“生成”動作命令の接近権限を有することができる。

なお、第１タイプ客体インスタンスは“生成”動作命令だけのためのものであるから、他の動作命令に対しては用いられない。また、第１タイプ客体インスタンスは、ブートストラップインターフェースを介してのみで設定、生成又は管理することができる。

次に、第２タイプ客体インスタンスも提案する。第２タイプ客体インスタンスは、“生成”動作命令以外の動作命令の接近権限認証のためのものであり、表１６に示した一般的な接近制御客体インスタンスと同一である（すなわち、Ｏｂｊｅｃｔ ＩＤ、Ｏｂｊｅｃｔ Ｉｎｓｔａｎｃｅ ＩＤ、ＡＣＬ、Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｏｗｎｅｒが設定される）が、単に“生成”動作命令を支援しないだけである。したがって、第２タイプ客体インスタンスは、接近制御所有者によって管理され、“生成”動作命令に対しては用いられない。

図８は、本発明の他の仕事実施例に係る接近制御のための客体インスタンスの生成及びこれを用いた認証手順を示す図である。

Ｍ２Ｍブートストラップサーバー（以下、ブートストラップサーバー）は、Ｍ２Ｍクライアント（以下、端末）に第１タイプ客体インスタンス生成のための動作命令を送信することができる（Ｓ８１）。このブートストラップサーバーは、ブートストラップインターフェースを介して上記端末に特定動作命令を送信することができる。例えば、第１タイプ客体インスタンスの生成のための動作命令は“書き込み”（又は、“生成”）動作命令であってよく、端末は、ブートストラップインターフェースを介した“書き込み”動作命令の対象が当該端末に存在しない客体インスタンス又はリソースであっても（動作命令の対象である客体インスタンス又はリソースが存在するか否かによらず）、上記“書き込み”動作命令のペイロードを上記端末中に記録しなければならない。すなわち、端末は、第１タイプ客体インスタンスを生成することができる（Ｓ８２）。一方、第１タイプ客体インスタンスは、“生成（Ｃｒｅａｔｅ）”動作命令に関するものであり、ブートストラップインターフェースを介して、すなわち、ブートストラップサーバーのみが生成及び管理することができる。これは、“生成”動作命令を送信したＭ２Ｍサーバーは、当該“生成”動作命令によって生成された客体インスタンスに対する全ての接近権限を有し、これに対して管理するため、ブートストラップインターフェースのみを介して生成ができるように制限される。ここで、Ｍ２Ｍブートストラップサーバーを介した送信に限定されず、ブートストラップインターフェースを使用するスマートカードからのブートストラップ、メーカーブートストラップが用いられてもよい。

端末は“書き込み”動作命令に対する実行結果をブートストラップサーバーに送信することができる（Ｓ８３）。

その後、特定Ｍ２Ｍサーバー（以下、サーバー）が端末に特定客体インスタンスの生成のための動作命令を送信することができる（Ｓ８４）。この特定客体インスタンスの生成のための動作命令は“生成”動作命令であってよく、これに対する認証手順が、前述した“接近制御技法”と同様に行われなければならない。また、“生成”動作命令は、“装置管理及びサービスイネーブルメント（ｄｅｖｉｃｅ ｍａｎａｇｅｍｅｎｔ ａｎｄ ｓｅｒｖｉｃｅ ｅｎａｂｌｅｍｅｎｔ）”インターフェースを介して受信される。本実施例では、上記認証手順を具体的に説明せず、前述した内容を参照するものとする。

端末は、上記第１タイプ客体インスタンスに基づいて“生成”動作命令に対して認証を行い（Ｓ８５）、認証が成功裏に終了すると、それに対する結果をサーバーに送信し（Ｓ８６−１）、そうでないと、それに対する結果をサーバーに送信することができる（Ｓ８６−２）。上記認証に成功すると、端末は特定客体インスタンスを生成し、そうでないと、特定客体インスタンスを生成しない。

図９には、本発明の他の実施例に係る接近制御のための客体インスタンスの生成及びこれを用いた認証手順を示す。

端末は、サーバーから特定動作命令を受信することができる（Ｓ９１）。この特定動作命令は、“装置管理及びサービスイネーブルメント（ｄｅｖｉｃｅ ｍａｎａｇｅｍｅｎｔ ａｎｄ ｓｅｒｖｉｃｅ ｅｎａｂｌｅｍｅｎｔ）”インターフェースを介して受信することができる。また、上記特定動作命令は、“読み取り”、“生成”、“削除”、“書き込み”及び“実行”のうちの一つであってもよい。

前述したように、２類型の接近制御客体インスタンスが存在すると、特定動作命令がいかなる動作命令かによって、特定動作命令の認証のために用いられる接近制御客体インスタンスが異なる。

したがって、上記端末は、受信した特定動作命令が“生成”動作命令であるか否かを判断することができる（Ｓ９２）。

特定動作命令が“生成”動作命令であると、端末は、生成動作命令の接近権限を認証するための接近制御客体インスタンスを用いることができる（Ｓ９３−１）。仮に、生成動作命令の接近権限を認証するための接近制御客体インスタンスが存在しないと、すなわち、まだ生成されていない状態なら、認証は失敗に終わる。

特定動作命令が“生成”動作命令でないと、端末は、特定動作命令の接近権限を認証するための接近制御客体インスタンスを用いることができる（Ｓ９３−２）。

上記Ｓ９３−１又はＳ８３−２の後に、端末は認証の結果をサーバーに送信することができる。

前述の実施例では、ブートストラップインターフェースを介して伝達される動作命令と明示しているが、これに限定されず、ブートストラップメッセージ、ブートストラップインストラクション（ｉｎｓｔｒｕｃｔｉｏｎ）など、端末の設定のためにブートストラップサーバー、スマートカードから伝達される関連命令又は情報、又はブートストラップのために特定領域（例えば、フラッシュメモリ、Ｓｅｃｕｒｅｄ Ｅｎｖｉｒｏｎｍｅｎｔ、ＴＰＭ（Ｔｒｕｓｔｅｄ Ｐｌａｔｆｏｒｍ Ｍｏｄｕｌｅ））に記憶されている関連命令又は情報のいずれであってもよい。

本実施例で、ブートストラップサーバー用語は、ブートストラップのための特定記憶領域（例えば、フラッシュメモリ、Ｓｅｃｕｒｅｄ Ｅｎｖｉｒｏｎｍｅｎｔ、ＴＰＭ（Ｔｒｕｓｔｅｄ Ｐｌａｔｆｏｒｍ Ｍｏｄｕｌｅ））、Ｍ２Ｍサービスブートストラップファンクション（Ｍ２Ｍ ｓｅｒｖｉｃｅ ｂｏｏｔｓｔｒａｐ ｆｕｎｃｔｉｏｎ）など、端末の基本情報（例えば、保安キー、端末／アプリケーション識別子、アドレス、他のエンティティと接続／登録のための情報）を伝達又は記憶する役割を担う他の用語に代えてもよい。

図１０は、本発明の実施例を実行するように構成された装置のブロック図である。送信装置１０及び受信装置２０は、情報及び／又はデータ、信号、メッセージなどを運ぶ無線信号を送信又は受信できるＲＦ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ）ユニット１３，２３と、無線通信システムにおける通信と関連した各種情報を記憶するメモリ１２，２２、ＲＦユニット１３，２３及びメモリ１２，２２などの構成要素と動作的に連結され、該当の装置が前述の本発明の実施例のうち少なくとも一つを実行するようにメモリ１２，２２及び／又はＲＦユニット１３，２３を制御するように構成されたプロセッサ１１，２１とをそれぞれ備える。

メモリ１２，２２は、プロセッサ１１，２１の処理及び制御のためのプログラムを格納することができ、入／出力される情報を臨時記憶することができる。メモリ１２，２２がバッファーとして活用されてもよい。

プロセッサ１１，２１は、通常、送信装置又は受信装置における各種モジュールの動作全般を制御する。特に、プロセッサ１１，２１は、本発明を実行するための各種制御機能を果たすことができる。プロセッサ１１，２１は、コントローラ（ｃｏｎｔｒｏｌｌｅｒ）、マイクロコントローラ（ｍｉｃｒｏｃｏｎｔｒｏｌｌｅｒ）、マイクロプロセッサ（ｍｉｃｒｏｐｒｏｃｅｓｓｏｒ）、マイクロコンピュータ（ｍｉｃｒｏｃｏｍｐｕｔｅｒ）などと呼ぶことができる。プロセッサ１１，２１は、ハードウェア（ｈａｒｄｗａｒｅ）、ファームウェア（ｆｉｒｍｗａｒｅ）、ソフトウェア、又はそれらの結合によって具現することができる。ハードウェアを用いて本発明を具現する場合には、本発明を実行するように構成されたＡＳＩＣｓ（ａｐｐｌｉｃａｔｉｏｎ ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔｓ）、ＤＳＰｓ（ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒｓ）、ＤＳＰＤｓ（ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｉｎｇ ｄｅｖｉｃｅｓ）、ＰＬＤｓ（ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ｄｅｖｉｃｅｓ）、又はＦＰＧＡｓ（ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙｓ）などをプロセッサ１１，２１に備えることができる。一方、ファームウェアやソフトウェアを用いて本発明を具現する場合には、本発明の機能又は動作を実行するモジュール、手順又は関数などを含むようにファームウェアやソフトウェアを構成することができ、本発明を実行できるように構成されたファームウェア又はソフトウェアは、プロセッサ１１，２１内に設けられたりメモリ１２，２２に格納されてプロセッサ１１，２１によって駆動されるようにすることができる。

本発明の実施例において、Ｍ２Ｍサーバー又はＭ２Ｍクライアント、又はサーバー又は端末などは、それぞれ、それらが設置されていたり搭載されている装置、すなわち、送信装置１０又は受信装置２０として動作することができる。

このような受信装置又は送信装置としてＭ２Ｍサーバー、Ｍ２Ｍクライアント、サーバー又は端末などの具体的な構成は、図面を参照して前述した本発明の様々な実施例で説明した事項が独立して適用されたり又は２つ以上の実施例が同時に適用されるように具現することができる。

以上、開示された本発明の好適な実施例に関する詳細な説明は、当業者が本発明を具現して実施できるように提供された。上記では本発明の好適な実施例を参照して説明したが、当該技術の分野における熟練した当業者にとっては、添付の特許請求の範囲に記載された本発明の思想及び領域から逸脱しない範囲内で本発明を様々に修正及び変更させることができるは明らかである。したがって、本発明は、ここに開示された実施の形態に制限されるものではなく、ここに開示された原理及び新規な特徴と一致する最も広い範囲を与えようとするものである。

本発明は、無線移動通信システムの端末機、基地局、サーバー又はその他の装備に用いることができる。

その後、上記端末は、他のファームウェアアップデートを行うことができる（Ｓ７３）。この時、上記通報のための指示子がｔｒｕｅに設定されているため、上記端末は上記サーバーに、上記ファームウェアアップデートによって変更された情報のみを通報することができる（Ｓ７４）。すなわち、周期的通報の間に、上記サーバーは、上記Ｓ７３のファームウェアアップデートによって変更された情報のみを取得し、上記Ｓ７２のファームウェアアップデートによって変更された情報は取得できない。このため、期間Ａにおいて上記サーバーは、上記端末が支援する客体又は使用可能な客体インスタンスの正確な情報が確認できず、よって、それによる機能を利用／支援することができない。

Claims (14)

1. 無線通信システムで特定動作命令に対する権限認証のための方法において、前記方法は端末によって行われ、
   第１サーバーから、特定リソースグループに対する生成動作命令の権限を認証するために用いられる接近制御のためのリソースグループを生成するための動作命令を受信するステップと、
   前記接近制御のためのリソースグループを生成するステップと、
   第２サーバーから、前記特定リソースグループを生成するための動作命令を受信するステップと、
   前記生成された接近制御のためのリソースグループに基づいて、前記特定リソースグループを生成するための動作命令を認証するステップと、
   を有する、権限認証方法。
2. 前記接近制御のためのリソースグループは、
   前記特定リソースグループを指示するＩＤ（Ｉｄｅｎｔｉｆｉｅｒ）及び特定サーバーの前記生成動作命令が許容されることを指示する接近制御リスト（Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｌｉｓｔ；ＡＣＬ）リソースを含む、請求項１に記載の権限認証方法。
3. 前記ＡＣＬリソースのビットのうちの四番目の最下位ビットが１に設定される、請求項２に記載の権限認証方法。
4. 前記接近制御のためのリソースグループを生成するための動作命令は、ブートストラップインターフェースを介して受信される、請求項１に記載の権限認証方法。
5. 前記特定リソースグループを生成するための動作命令は、装置管理及びサービスイネーブルメント（ｄｅｖｉｃｅ ｍａｎａｇｅｍｅｎｔ ａｎｄ ｓｅｒｖｉｃｅ ｅｎａｂｌｅｍｅｎｔ）インターフェースを介して受信される、請求項１に記載の権限認証方法。
6. 前記特定リソースグループが生成されると、前記特定リソースグループに対する動作命令の権限を認証するために用いられる接近制御のためのリソースグループを生成するステップを有し、
   前記生成動作命令は、前記動作命令から除外される、請求項１に記載の権限認証方法。
7. 無線通信システムで特定動作命令に対する権限認証のための方法において、前記方法は、端末によって行われ、
   サーバーから、特定動作命令を受信するステップと、
   前記特定動作命令が特定リソースグループを生成するための動作命令であると、前記特定リソースグループに対する生成動作命令の権限を認証するために用いられる接近制御のためのリソースグループ（以下、「第１接近制御リソースグループ」という。）に基づいて前記特定動作命令を認証するステップと、
   前記特定動作命令が特定リソースグループを生成するための動作命令でないと、前記特定リソースグループに対する生成動作命令以外の動作命令の権限を認証するために用いられる接近制御のためのリソースグループ（以下、「第２接近制御リソースグループ」という。）に基づいて前記特定動作命令を認証するステップと、
   を有する、権限認証方法。
8. 前記第１接近制御リソースグループは、
   前記特定リソースグループを指示するＩＤ（Ｉｄｅｎｔｉｆｉｅｒ）及び特定サーバーの前記生成動作命令が許容されることを指示する接近制御リスト（Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｌｉｓｔ；ＡＣＬ）リソースを含む、請求項７に記載の権限認証方法。
9. 前記ＡＣＬリソースのビットのうちの四番目の最下位ビットが１に設定される、請求項８に記載の権限認証方法。
10. 前記第１接近制御リソースグループは、ブートストラップインターフェースを介して受信される、生成するための動作命令によって生成される、請求項７に記載の権限認証方法。
11. 前記特定命令は、装置管理及びサービスイネーブルメント（ｄｅｖｉｃｅ ｍａｎａｇｅｍｅｎｔ ａｎｄ ｓｅｒｖｉｃｅ ｅｎａｂｌｅｍｅｎｔ）インターフェースを介して受信される、請求項７に記載の権限認証方法。
12. 前記特定リソースグループが生成されると、前記特定リソースグループに対する動作命令の権限を認証するために用いられる接近制御のためのリソースグループを生成するステップを有し、
    前記生成動作命令は、前記動作命令から除外される、請求項７に記載の権限認証方法。
13. 無線通信システムにおいて特定動作命令に対する権限認証のための端末であって、
    無線周波数（ｒａｄｉｏ ｆｒｅｑｕｅｎｃｙ；ＲＦ）ユニットと、
    前記ＲＦユニットを制御するように構成されたプロセッサと、
    を備え、
    前記プロセッサは、第１サーバーから、特定リソースグループに対する生成動作命令の権限を認証するために用いられる接近制御のためのリソースグループを生成するための動作命令を受信し、前記接近制御のためのリソースグループを生成し、第２サーバーから、前記特定リソースグループを生成するための動作命令を受信し、及び前記生成された接近制御のためのリソースグループに基づいて、前記特定リソースグループを生成するための動作命令を認証するように構成された、端末。
14. 無線通信システムにおいて特定動作命令に対する権限認証のための端末であって、
    無線周波数（ｒａｄｉｏ ｆｒｅｑｕｅｎｃｙ；ＲＦ）ユニットと、
    前記ＲＦユニットを制御するように構成されたプロセッサと、
    を備え、
    前記プロセッサは、サーバーから特定動作命令を受信し、
    前記特定動作命令が特定リソースグループを生成するための動作命令であると、前記特定リソースグループに対する生成動作命令の権限を認証するために用いられる接近制御のためのリソースグループ（以下、「第１接近制御リソースグループ」）に基づいて前記特定動作命令を認証するように構成され、
    前記特定動作命令が特定リソースグループを生成するための動作命令でないと、前記特定リソースグループに対する生成動作命令以外の動作命令の権限を認証するために用いられる接近制御のためのリソースグループ（以下、「第２接近制御リソースグループ」）に基づいて前記特定動作命令を認証するように構成された、端末。

Images