JP2016507823A - 無線通信システムにおいて接近制御のための方法及び装置 - Google Patents

Abstract

本発明の一実施例に係る、無線通信システムでサーバーのアカウント削除による、前記サーバーと関連した特定オブジェクトインスタンスの処理方法において、前記方法は、端末によって行われ、第１サーバーから特定サーバーのアカウントを削除するための動作命令を受信するステップと、前記特定オブジェクトインスタンスが、前記特定サーバーのみがアクセス可能なオブジェクトインスタンスであれば、前記特定オブジェクトインスタンス及びそれと関連したアクセス制御オブジェクトインスタンスを削除するステップとを有し、前記特定オブジェクトインスタンスが、前記特定サーバーを含めた複数のサーバーがアクセス可能なオブジェクトインスタンスであれば、前記特定オブジェクトインスタンスと関連したアクセス制御オブジェクトインスタンスにおいて前記特定サーバーのアクセス権限情報を削除するステップと、前記特定サーバーが前記アクセス制御オブジェクトインスタンスの唯一のアクセス制御所有者であれば、前記特定サーバー以外の前記複数のサーバーのそれぞれが有するアクセス権限に与えられた値の和が最も大きいサーバーを前記アクセス制御所有者に変更するステップとを有することができる。【選択図】図９

Description

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

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

一方、Ｍ２Ｍ機器にもアクセス制御のための技術が要求され、特に、Ｍ２Ｍクライアントに登録されたＭ２Ｍサーバーアカウントが削除される場合に、それに対する処理と、削除されるＭ２Ｍサーバーと関連付けられているリソースに対する処理が必要である。このＭ２Ｍサーバーアカウント削除によって、特定リソースがアクセス権限の存在しないリソースになったり、又はＭ２Ｍクライアント内のリソースのアクセス権限を管理するＭ２Ｍサーバーがなくなる状況が発生することがあり、これに対するソリューションが必要である。

本発明は、アクセス制御のための方案を提案する。

より詳しくは、本発明の一実施例は、特定サーバーアカウントが削除される場合に、それに関連付けられているリソースに対する処理方案を提案する。

また、本発明は、通知に対する認証方案を提案する。

また、本発明は、端末の接続モード設定のための方案を提案する。

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

本発明の一実施例に係る、無線通信システムでサーバーアカウント削除による、前記サーバーと関連した特定オブジェクトインスタンスの処理方法において、前記方法は、前記端末によって行われ、第１サーバーから、特定サーバーのアカウントを削除するための動作命令を受信するステップと、前記特定オブジェクトインスタンスが、前記特定サーバーのみがアクセス可能なオブジェクトインスタンスであれば、前記特定オブジェクトインスタンス及びそれと関連したアクセス制御オブジェクトインスタンスを削除するステップと、前記特定オブジェクトインスタンスが、前記特定サーバーを含めた複数のサーバーがアクセス可能なオブジェクトインスタンスであれば、前記特定オブジェクトインスタンスと関連したアクセス制御オブジェクトインスタンスにおいて前記特定サーバーのアクセス権限情報を削除するステップと、前記特定サーバーが前記アクセス制御オブジェクトインスタンスの唯一のアクセス制御所有者であれば、前記特定サーバー以外の前記複数のサーバーのそれぞれが有するアクセス権限に与えられた値の和が最も大きいサーバーを前記アクセス制御所有者に変更するステップとを有することができる。

好適には、前記値の和が最も大きいサーバーが２つ以上であれば、前記方法は、前記２つ以上のサーバーから一つを選択し、前記選択されたサーバーを前記アクセス制御所有者に変更するステップをさらに有することができる。

好適には、前記特定サーバーのアカウントを削除するための動作命令は、ブートストラップインターフェースを介して受信されてもよい。

好適には、前記第１サーバーは、ブートストラップサーバーであってもよい。

好適には、第２サーバーによる前記アクセス制御オブジェクトインスタンスのアクセス制御所有者に対して観察動作が設定されていると、前記方法は、前記アクセス制御所有者の変更時に、前記第２サーバーに前記変更に対する通知を送信するステップをさらに有することができる。

好適には、前記方法は、前記特定サーバーが送信した観察動作命令によって記憶した観察動作命令関連設定情報を削除するステップをさらに有することができる。

好適には、前記特定サーバーのアカウントは、前記特定サーバーの短いサーバーＩＤ及び前記特定サーバーとの通信のための保安キーを含むことができる。

本発明の他の実施例に係る、無線通信システムでサーバーアカウント削除による、前記サーバーと関連した特定オブジェクトインスタンスを処理するように構成された端末であって、無線周波数（ｒａｄｉｏ ｆｒｅｑｕｅｎｃｙ；ＲＦ）ユニットと、前記ＲＦユニットを制御するように構成されたプロセッサとを備えることができ、前記プロセッサは、第１サーバーから特定サーバーのアカウントを削除するための動作命令を受信し、前記特定オブジェクトインスタンスが、前記特定サーバーのみがアクセス可能なオブジェクトインスタンスであれば、前記特定オブジェクトインスタンス及びそれと関連したアクセス制御オブジェクトインスタンスを削除し、前記特定オブジェクトインスタンスが、前記特定サーバーを含めた複数のサーバーがアクセス可能なオブジェクトインスタンスであれば、前記特定オブジェクトインスタンスと関連したアクセス制御オブジェクトインスタンスにおいて前記特定サーバーのアクセス権限情報を削除し、前記特定サーバーが前記アクセス制御オブジェクトインスタンスの唯一のアクセス制御所有者であれば、前記特定サーバー以外の前記複数のサーバーのそれぞれが有するアクセス権限に与えられた値の和が最も大きいサーバーを前記アクセス制御所有者に変更するように構成されてもよい。

好適には、前記値の和が最も大きいサーバーが２つ以上であれば、前記プロセッサは、前記２つ以上のサーバーから一つを選択し、前記選択されたサーバーを前記アクセス制御所有者に変更するように構成されてもよい。

好適には、前記特定サーバーのアカウントを削除するための動作命令は、ブートストラップインターフェースを介して受信されてもよい。

好適には、前記第１サーバーは、ブートストラップサーバーであってもよい。

好適には、第２サーバーによる前記アクセス制御オブジェクトインスタンスのアクセス制御所有者に対して観察動作が設定されていると、前記プロセッサは、前記アクセス制御所有者の変更時に、前記第２サーバーに前記変更に対する通知を送信するように構成されてもよい。

好適には、前記プロセッサは、前記特定サーバーが送信した観察動作命令によって記憶した観察動作命令関連設定情報を削除するように構成されてもよい。

好適には、前記特定サーバーのアカウントは、前記特定サーバーの短いサーバーＩＤ及び前記特定サーバーとの通信のための保安キーを含むことができる。

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

本発明の一実施例によれば、リソースの効率的な管理を図ることができる。

また、本発明の一実施例によれば、観察に対応して効率的な通知を可能にさせることができる。

また、本発明の一実施例によれば、端末の電力を效率的に管理することができる。

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

Ｍ２Ｍクライアントに記憶されたデータ（又は、資料）構造を示す図である。 本発明の一実施例と係るリソースモデルを示す図である。 本発明の一実施例と係るインターフェースのモデルを示す図である。 本発明の一実施例に係るブートストラップ動作を示す図である。 本発明の一実施例に係るブートストラップ動作を示す図である。 本発明の一実施例に係る観察登録動作を示す図である。 本発明の一実施例に係る観察による報告（通知）動作を示す図である。 本発明の一実施例に係る観察登録及びそれによる報告の動作例を示す図である。 本発明の一実施例に係るアクセス権限所有者変更設定動作を示す図である。 本発明の実施例を具現するための装置のブロック図である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

サーバー識別子（Ｓｅｖｅｒ Ｉｄｅｎｔｉｆｉｅｒ）
サーバー識別子は、ＤＭサーバーに対するＯＭＡ ＤＭ内部名称を表す。ＤＭサーバーは、ＯＭＡ ＤＭアカウントを通じて装置に存在するサーバー識別子と関連付けられる。

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

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

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

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

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

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

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

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

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

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

ＤＤＦ（Ｄｅｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｆｒａｍｅｗｏｒｋ）
ＤＤＦは、特定デバイスタイプに対する管理シンタックスとセマンティックスを記述する方法に関する説明である。ＤＤＦは、端末のＭＯ、管理機能及びＤＭツリー構造に関する情報を提供する。

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

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

多重サーバー環境では、一つの端末に接続して端末管理又は端末が提供するサービスを使用するサーバーが複数個存在してもよい。端末が提供するサービスは、リソースの形態、リソース群の形態であってもよい。すなわち、端末が特定サービスをサーバーに提供することによって端末が特定リソース（群）をサーバーに露出し、サーバーが上記リソースを操作し、これで、特定サービスを実行することができる。

リソース（群）は、当該リソース（群）のアクセス権限を管理するアクセス権限管理者であるサーバーが存在するが、当該リソースのアクセス権限管理者が唯一であり、当該リソースにアクセス可能な他のサーバーがある環境で当該リソース管理者のサーバーアカウントが削除される場合がある。この場合、当該リソースのアクセス権限管理者が削除されたため、いかなるサーバーも当該リソースのアクセス権限管理を行うことができなくなる。このため、いかなるサーバーも、当該リソースにいかなるサーバーがいかなるアクセス（例えば、サーバーが当該リソースの特定命令に対して権限を有すること）ができるかについて設定／解除することができない。そこで、本発明では、アクセス権限管理者であるサーバーのアカウントが削除されても、持続して当該リソースに対するアクセス権限管理ができるように、当該リソースにアクセス可能な他のサーバーのうち、他のサーバーのアクセス権限に基づいてアクセス権限管理者サーバーを設定する方法を提示する。

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

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

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

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

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

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

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

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

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

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

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

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

本発明と関連して、４個のインターフェースが存在する。１）ブートストラップ（Ｂｏｏｔｓｔｒａｐ）、２）装置（クライアント、デバイス）登録（Ｄｅｖｉｃｅ（Ｃｌｉｅｎｔ）Ｒｅｇｉｓｔｒａｔｉｏｎ）、３）装置管理及びサービスイネーブルメント（Ｄｅｖｉｃｅ Ｍａｎａｇｅｍｅｎｔ ａｎｄ Ｓｅｒｖｉｃｅ Ｅｎａｂｌｅｍｅｎｔ）、４）情報報告（Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ）。これら４つのインターフェースのための動作命令は、上りリンク動作と下りリンク動作とに分類できる。それぞれのインターフェースの動作命令を次の表に定義する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

− ２．「装置管理及びサービスイネーブルメント（ｄｅｖｉｃｅ ｍａｎａｇｅｍｅｎｔ ａｎｄ ｓｅｒｖｉｃｅ ｅｎａｂｌｅｍｅｎｔ）」インターフェースのための動作

− 読み取り（Ｒｅａｄ）
「読み取り」動作命令は、個別リソース、アレイ（ａｒｒａｙ）のリソースインスタンス、オブジェクトインスタンス又はオブジェクトの全てのオブジェクトインスタンスの値にアクセス（読み取り）するために用いられ、次のようなパラメータを有する。

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

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

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

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

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

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

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

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

最大一つのオブジェクトインスタンスを支援するオブジェクトには、該オブジェクトインスタンスが生成されると、０のオブジェクトインスタンスＩＤを割り当てなければならない。「生成」動作命令は、次のパラメータを有する。

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

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

− 通知（Ｎｏｔｉｆｙ）
「通知」動作命令は、Ｍ２ＭクライアントからＭ２Ｍサーバーに、オブジェクトインスタンス又はリソースに対する有効な観察の間に送信される。この動作命令は、上記オブジェクトインスタンス又はリソースの新しい値を含む。上記「通知」動作命令は、「観察」動作命令のための「書き込み属性（Ｗｒｉｔｅ Ａｔｔｒｉｂｕｔｅ）」動作命令によって設定される全ての条件（すなわち、Ｍｉｎｉｍｕｍ Ｐｅｒｉｏｄ、Ｍａｘｉｍｕｍ Ｐｅｒｉｏｄ、Ｇｒｅａｔｅｒ Ｔｈａｎ、Ｌｅｓｓ Ｔｈａｎ、Ｓｔｅｐ）を満たすと送信される。上記通知動作命令は、次のパラメータを含む。

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

アクセス制御技法
以下、Ｍ２Ｍで用いられるアクセス制御方法を説明する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

− オブジェクトに対する動作命令
オブジェクトに対する動作命令も、動作命令の種類によって定義される。

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

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

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

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

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

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

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

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

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

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

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

本発明は、Ｍ２ＭクライアントからＭ２Ｍサーバーのアカウントが削除される場合に発生しうる非効率性を解決するためのものである。Ｍ２Ｍサーバーのアカウントが削除されると、当該Ｍ２Ｍサーバーが特定リソースに持つアクセス権限も削除されるが、削除されるアクセス権限が、リソースを持続して管理する上で困難を招くことがある。また、アクセス権限削除のみが行われると、アクセス権限の存在しないリソースがＭ２Ｍクライアントに残るが、当該リソースは誰もアクセスできないエンティティとなる。Ｍ２Ｍクライアントにイベントが発生する場合、これを知らせる設定（ｃｏｎｆｉｇｕｒａｔｉｏｎ）が設定されていてもよいが、当該設定も解除をすることによって、Ｍ２Ｍサーバーのアカウントが削除される時に効率的にリソースを管理するメカニズムを紹介する。

アクセス権限所有者（Ａｃｃｅｓｓ Ｒｉｇｈｔ Ｏｗｎｅｒ）
アクセス権限所有者は、特定リソースのＡＣＬを変更し得るエンティティである。このアクセス権限所有者は、特定アクセス権限を有していてもよく（例えば、ｄｅｌｅｇａｔｉｏｎ ａｃｃｅｓｓ ｒｉｇｈｔ）、特定フィールドに別に記憶（例えば、Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｏｗｎｅｒ ｆｉｅｌｄ、ｓｅｌｆ−ｐｅｒｍｉｓｓｉｏｎ ｆｉｅｌｄ）されて、該当のＡＣＬを管理することができる。表１７に示したように、アクセス権限所有者は一つであってもよく、複数個であってもよい。

一方、Ｍ２Ｍサーバーアカウントの削除は、上述したブートストラップインターフェースを介してＭ２Ｍブートストラップサーバーで行うことができる。このため、上記Ｍ２Ｍサーバーアカウントの削除は、上記Ｍ２Ｍブートストラップサーバーと対象Ｍ２Ｍクライアントとの間で特定動作命令の送受信によって行われる。これについて参照説明する。

ブートストラップインターフェースは、Ｍ２Ｍクライアントが一つ以上のＭ２Ｍサーバーと「登録（Ｒｅｇｉｓｔｅｒ）」動作命令を行うようにするべく、該Ｍ２Ｍクライアントに必須情報を提供（ｐｒｏｖｉｓｉｏｎ）するために用いられる。Ｍ２Ｍイネーブラ（ｅｎａｂｌｅｒ）によって支援される４個のブートストラップモードが存在する。

− 工場ブートストラップ：Ｍ２Ｍクライアントにあらかじめブートストラップ情報が設定されている。

− スマートカードからのブートストラップ：Ｍ２Ｍクライアントがスマートカードからブートストラップ情報を取り込む。

− クライアント開始ブートストラップ：Ｍ２ＭクライアントがＭ２Ｍブートストラップサーバーにブートストラップを要求し、Ｍ２Ｍブートストラップサーバーは、Ｍ２Ｍクライアントのブートストラップ情報を追加／削除／更新する。

− サーバー開始ブートストラップ：Ｍ２ＭブートストラップサーバーがＭ２Ｍクライアントのブートストラップ情報を追加／削除／更新する。

Ｍ２Ｍクライアントは、上記ブートストラップインターフェースで特定された少なくとも一つのブートストラップモードを支援することができる。Ｍ２Ｍサーバーは、上記ブートストラップインターフェースで特定されたいずれのブートストラップモードも支援することができる。

ブートストラップ情報は、Ｍ２Ｍサーバー又はＭ２Ｍブートストラップサーバーに接続するためにＭ２Ｍクライアントで設定される必要がある情報を指す。このブートストラップ情報は、ブートストラップシーケンスを行う前に用いてもよく、又は上記ブートストラップシーケンスの結果として取得してもよい。ブートストラップ情報は、２つの類型、すなわち、Ｍ２Ｍサーバーのためのブートストラップ情報とＭ２Ｍブートストラップサーバーのためのブートストラップ情報とに区別することができる。

Ｍ２Ｍクライアントは、ブートストラップシーケンス以降にＭ２Ｍサーバーのためのブートストラップ情報（例えば、Ｍ２Ｍサーバーとの接続のために必要な情報）を有することができる。また、Ｍ２Ｍブートストラップサーバーのためのブートストラップ情報（例えば、Ｍ２Ｍブートストラップサーバーとの接続のために必要な情報）を有することができる。Ｍ２Ｍサーバーのためのブートストラップ情報は、Ｍ２Ｍサーバーに登録及び接続する上でＭ２Ｍクライアントのために用いられる。

Ｍ２Ｍサーバーのためのブートストラップ情報は少なくとも、「ブートストラップサーバー」リソースが「ｆａｌｓｅ」に設定されたＭ２Ｍサーバー保安オブジェクトインスタンスを含むことができる。Ｍ２Ｍサーバーのためのブートストラップ情報は、他のオブジェクトインスタンスを含むことができる。

Ｍ２Ｍクライアントは、それぞれのＭ２Ｍサーバーのためのブートストラップ情報の集合を含む２つ以上のＭ２Ｍサーバーを用いるように構成することができる。Ｍ２Ｍブートストラップサーバーのためのブートストラップ情報は、Ｍ２Ｍサーバーのためのブートストラップ情報を取得するためにＭ２Ｍブートストラップ情報に接続する上でＭ２Ｍクライアントが用いることができる。このＭ２Ｍブートストラップサーバーのためのブートストラップ情報は、「ブートストラップサーバー」リソースが「ｔｒｕｅ」に設定されたＭ２Ｍサーバー保安オブジェクトインスタンスであってもよい。

ブートストラップ情報は、次のように分類することができる。

Ｍ２Ｍクライアントは、ブートストラップインターフェースを介して送信されたブートストラップ情報を、認証手順（アクセス制御）無しで受諾することができる。

ブートストラップインターフェースはＭ２Ｍクライアントを選択的に設定し、該Ｍ２Ｍクライアントが成功裏にＭ２Ｍサーバーに登録されたり又はＭ２Ｍブートストラップサーバーに接続されるようにする。クライアントブートストラップ動作命令は、Ｍ２Ｍブートストラップサーバーの／ｂｓ経路によって、クエリー（ｑｕｅｒｙ）ストリング（ｓｔｒｉｎｇ）パラメータはＭ２Ｍクライアント識別子を含めてＣｏＡＰ ＰＯＳＴ要求を送信することによって行われる。

クライアント開始ブートストラップで、Ｍ２Ｍブートストラップサーバーがブートストラップ要求（Ｒｅｑｕｅｓｔ Ｂｏｏｔｓｔｒａｐ）動作命令を受信すると、該ブートストラップサーバーは、書き込み（Ｗｒｉｔｅ）及び／又は削除（Ｄｅｌｅｔｅ）動作命令を行うことができる。サーバー開始ブートストラップで、ブートストラップサーバーは、書き込み（Ｗｒｉｔｅ）動作命令を行うことができる。書き込み及び／又は削除動作命令は、オブジェクトインスタンス又はリソースをターゲットとすることができる。この書き込み及び削除動作命令は、複数回（ｍｕｌｔｉｐｌｅ ｔｉｍｅｓ）送信されてもよい。ブートストラップインターフェースでのみ、削除動作命令は、Ｍ２ＭブートストラップサーバーがＭ２Ｍクライアントに書き込み動作命令を送信する前に、Ｍ２Ｍクライアントの初期化のために、Ｍ２ＭクライアントでＭ２Ｍブートストラップサーバーアカウント以外の、存在する全てのオブジェクトインスタンスを削除するために「／」ＵＲＩをターゲットとすることができる。装置管理及びサービスイネーブルインターフェースにおける書き込み動作命令と違い、上記Ｍ２Ｍクライアントは、ターゲットとするオブジェクトインスタンス又はリソースの存在にかかわらず、上記動作命令のペイロード（すなわち、上記書き込み動作命令で記録しようとする（書き込もうとする）特定値）を記録することができる。次に、ブートストラップインターフェースにおける動作命令を示す。上記書き込み動作命令は、他の動作命令（例えば、生成）に取り替えてもよい。

ブートストラップシーケンス
Ｍ２Ｍクライアントは、Ｍ２Ｍ機器をブートストラップしようとするとき、次のブートストラップシーケンス（段階）に従わなければならない。

Ｍ２Ｍ機器にスマートカードがあると、Ｍ２Ｍクライアントは、ブートストラップ情報をスマートカードから得ようと試みる。

Ｍ２Ｍクライアントがスマートカードから設定されないと、Ｍ２Ｍクライアントは、メーカーブートストラップ（ｆａｃｔｏｒｙ ｂｏｏｔｓｔｒａｐ）モードでブートストラップ情報を得ようと試みる。(If the LWM2M Client is not configured using the Bootstrap from Smartcard mode, the LWM2M Client tries to obtain the Bootstrap Information by using Factory Bootstrap mode.)

Ｍ２Ｍクライアントが以前段階によってＭ２Ｍサーバーオブジェクトインスタンスを持っていると、Ｍ２Ｍクライアントは、当該Ｍ２Ｍサーバーオブジェクトインスタンスに該当するＭ２Ｍサーバーに登録を要求する。

Ｍ２Ｍクライアントが全てのＭ２Ｍサーバーへの登録に失敗した場合又はクライアントがＭ２Ｍサーバーオブジェクトインスタンスを持っていない場合に、Ｍ２Ｍクライアントは、特定リソース（ＣｌｉｅｎｔＨｏｌｄＯｆｆＴｉｍ）が明示した時間だけサーバー開始ブートストラップを待ち、この時間にサーバー開始ブートストラップが発生しないと、クライアント開始ブートストラップを用いてブートストラップ情報を得ようと試みる。

クライアント開始ブートストラップ
Ｍ２ＭサーバーアカウントがＭ２Ｍクライアント内に設定されていないか（存在していないか）、Ｍ２Ｍサーバーとの「登録」動作命令を行うことに失敗する場合がある。このような場合、Ｍ２Ｍクライアントは、Ｍ２Ｍブートストラップサーバーからブートストラップ情報を取り込む（ｒｅｔｒｉｅｖｅ）ために、クライアント−開始ブートストラップモードを用いることができる。クライアント−開始ブートストラップモードは、Ｍ２Ｍブートストラップサーバーを示す（参照する）Ｍ２Ｍ保安サーバーオブジェクトインスタンスがＭ２Ｍクライアントに設定されている（存在する）ことを要求することができる。

図４に、本発明の一実施例に係るクライアント−開始ブートストラップモードの動作を示す。Ｍ２Ｍクライアントは、あらかじめ−提供された（ｐｒｅ−ｐｒｏｖｉｓｉｏｎｅｄ）Ｍ２ＭブートストラップサーバーＵＲＩに、「ブートストラップ要求」動作命令を送信することができる（Ｓ４１０）。ここで、ブートストラップを要求するとき、Ｍ２Ｍクライアントは、Ｍ２Ｍブートストラップサーバーが上記Ｍ２Ｍクライアントのための適切なブートストラップ情報を提供するように、パラメータとして上記Ｍ２Ｍクライアントの「エンドポイント（ｅｎｄｐｏｉｎｔ）クライアント名」（Ｍ２Ｍクライアント識別子）を送信することができる。

上記Ｍ２Ｍブートストラップサーバーは、「書き込み」及び／又は「削除」動作命令を用いて上記Ｍ２Ｍクライアントにブートストラップ情報を設定（ｃｏｎｆｉｇｕｒｅ又はｓｅｔ）することができる（Ｓ４２０）。

上記クライアント−開始ブートストラップは、最初のブートストラップ後に、ブートストラップ情報を更新する目的で、上記Ｍ２Ｍクライアントの上記ブートストラップ情報のいくつかのリソースを設定するために用いることができる。この例で、ブートストラップ情報はいずれも選択事項（ｏｐｔｉｏｎａｌ）であり、伝達されても伝達されなくてもよい。

サーバー開始ブートストラップ
サーバー−開始ブートストラップは、Ｍ２ＭクライアントがＭ２Ｍブートストラップサーバーにブートストラップ要求を送信することなく、Ｍ２ＭブートストラップサーバーがＭ２Ｍクライアントにブートストラップ情報を設定することができる。上記Ｍ２Ｍクライアントが上記Ｍ２Ｍブートストラップサーバーに「ブートストラップ要求」動作命令を開始しないことから、上記Ｍ２Ｍブートストラップサーバーは、上記Ｍ２Ｍクライアントが上記Ｍ２Ｍブートストラップサーバーによって設定される前に、Ｍ２Ｍ装置又はＭ２Ｍクライアントがブートストラップする準備ができているか否かを知る必要がある。上記Ｍ２Ｍブートストラップサーバーがこのような知識を取得するためのメカニズムは、本発明では取り扱われない。一例として、Ｍ２Ｍ装置がネットワークプロバイダのネットワークに接続する場合、ネットワークプロバイダのネットワークがＭ２Ｍブートストラップサーバーに、Ｍ２Ｍ装置のブートストラップ準備ができているか否かを知らせるシナリオが可能である。

上記Ｍ２Ｍブートストラップサーバーが、上記Ｍ２Ｍ装置が上記ブートストラップ情報を受信する準備ができているという通知を受けると、上記Ｍ２Ｍブートストラップサーバーは、「書き込み」及び／又は「削除」動作命令を用いて上記Ｍ２Ｍクライアントに上記ブートストラップ情報を設定することができる。

図５には、本発明の一実施例に係るサーバー−開始ブートストラップモードの動作を示す。Ｍ２Ｍブートストラップサーバーは、「書き込み」及び／又は「削除」動作命令を用いて上記Ｍ２Ｍクライアントに上記ブートストラップ情報を設定することができる（Ｓ５１０）。

上記サーバー−開始ブートストラップは、最初のブートストラップ後に、ブートストラップ情報をアップデートする目的で、上記Ｍ２Ｍクライアントの上記ブートストラップ情報のいくつかのリソースを設定するために用いることができる。この例で、ブートストラップ情報はいずれも選択事項（ｏｐｔｉｏｎａｌ）であり、伝達されても伝達されなくてもよい。

ブートストラップ情報（Ｂｏｏｔｓｔｒａｐ Ｉｎｆｏｒｍａｔｉｏｎ）
ブートストラップ情報は、Ｍ２Ｍブートストラップサーバーを介して伝達される情報であり、Ｍ２ＭクライアントがＭ２Ｍサーバー又はＭ２Ｍブートストラップサーバーと接続／通信する上で必要な情報を意味する。ブートストラップ情報は、ブートストラップインターフェースを介して伝達することができ、ブートストラップシーケンス以前に用いたり、ブートストラップシーケンスの結果として取得することができる。

ブートストラップ情報は、Ｍ２Ｍサーバーブートストラップ情報（Ｍ２Ｍ Ｓｅｒｖｅｒ Ｂｏｏｔｓｔｒａｐ Ｉｎｆｏｒｍａｔｉｏｎ）とＭ２Ｍブートストラップサーバーブートストラップ情報（Ｍ２Ｍ Ｂｏｏｔｓｔｒａｐ Ｓｅｒｖｅｒ Ｂｏｏｔｓｔｒａｐ Ｉｎｆｏｒｍａｔｉｏｎ）とに分類される。Ｍ２Ｍサーバーブートストラップ情報は、Ｍ２Ｍサーバーアカウントと、選択的に追加のオブジェクトインスタンス（例えば、アクセス制御（ａｃｃｅｓｓ ｃｏｎｔｒｏｌ）オブジェクトインスタンス、ネットワーク接続情報（ｃｏｎｎｅｃｔｉｖｉｔｙ）オブジェクトインスタンス）を含み、Ｍ２Ｍブートストラップサーバーブートストラップ情報は、Ｍ２Ｍブートストラップサーバーアカウントを含む。

Ｍ２Ｍサーバーアカウントは、Ｍ２Ｍサーバーに接続する上で必要な情報とサーバー関連機能、サーバー関連機能情報を記憶することができる。Ｍ２Ｍブートストラップサーバーアカウントは、Ｍ２Ｍブートストラップサーバーに接続する上で必要な情報を記憶する。

Ｍ２Ｍクライアントは、Ｍ２Ｍサーバーからの保安要件（例えば、データ機密性（ｃｏｎｆｉｄｅｎｔｉａｌｉｔｙ）、データ完全性（ｄａｔａ ｉｎｔｅｇｒｉｔｙ）、ソース認証（ｓｏｕｒｃｅ ａｕｔｈｅｎｔｉｃａｔｉｏｎ））を満たすブートストラップメッセージ、又はブートストラップインターフェースを介して提供されるいなかる情報も全て信頼して受け入れる。

サーバー情報
Ｍ２ＭクライアントとＭ２Ｍサーバーとが通信をするには、Ｍ２Ｍサーバーと通信するための基本的な情報と付加的な情報（ブートストラップを用いて伝達される情報）がＭ２Ｍブートストラップサーバーを介して提供されなければならない。このような情報の例には、サーバーＩＤ、サーバーアドレス（例えば、ＩＰ、ＵＲＩ）、保安資格（ｓｅｃｕｒｉｔｙ ｃｒｅｄｅｎｔｉａｌ）、ネットワークベアラー情報（ｎｅｔｗｏｒｋ ｂｅａｒｅｒ ｉｎｆｏｒｍａｔｉｏｎ）、好まれるネットワークベアラー情報（ｐｒｅｆｅｒｒｅｄ ｎｅｔｗｏｒｋ ｂｅａｒｅｒ ｉｎｆｏｒｍａｔｉｏｎ）、Ｍ２Ｍサーバーが生成可能なリソース（例えば、管理オブジェクト、オブジェクト）などがある。特定Ｍ２Ｍサーバー（関連）ブートストラップ情報は、上記サーバー情報を意味することができる。

アクセス制御情報（Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）
Ｍ２ＭサーバーがＭ２Ｍクライアントの特定リソースにアクセスするには、当該リソースへのアクセス権限を有しなければならない。ブートストラップを用いてこのようなアクセス制御に関連した情報（すなわち、ＡＣＬ（Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｌｉｓｔ）又はＡＣＬを含むリソース）も変更可能である。当該情報はブートストラップを通じて提供されても提供されなくてもよい。

サーバーアカウント削除のためのアクセス権限設定（Ａｃｃｅｓｓ Ｒｉｇｈｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ ｆｏｒ ｔｈｅ Ｓｅｒｖｅｒ Ａｃｃｏｕｎｔ Ｄｅｌｅｔｉｏｎ）
Ｍ２Ｍサーバーアカウントが削除される場合、該当のＭ２ＭクライアントのＡＣＬから当該Ｍ２Ｍサーバーのアクセス権限も削除されなければならない。このとき、当該Ｍ２Ｍサーバーが特定リソース（例えば、オブジェクト）の唯一のアクセス権限所有者である場合、前述したようにいくつかの問題点がある。このため、上記Ｍ２ＭクライアントのＡＣＬに、削除されるＭ２Ｍサーバーだけでなく、他のＭ２Ｍサーバーに対するアクセス権限が存在する場合、次のようなプロシージャが可能である。

Ａ）サーバーアカウント削除の遮断
Ｍ２Ｍサーバーアカウントが削除されるとき、当該削除要求がされないように防ぐことができる。そのために、上記削除要求を受信したＭ２Ｍクライアントは、当該削除要求をしたＭ２Ｍサーバーが唯一のアクセス権限所有者であるというメッセージと併せてエラー応答を送ることができる。この場合、削除を要求したＭ２Ｍサーバー（すなわち、ブートストラップＭ２Ｍサーバー）は、アクセス権限所有者を他のＭ２Ｍサーバーに変更したり又は当該アクセス権限（ＡＣＬ）を削除した後に再び上記Ｍ２Ｍサーバーのアカウント削除を要求し、上記Ｍ２Ｍクライアントは当該Ｍ２Ｍサーバーアカウントを削除することができる。

Ｂ）アクセス権限所有者の変更（Ａｃｃｅｓｓ Ｒｉｇｈｔ Ｏｗｎｅｒ Ｃｈａｎｇｅ）
Ｍ２Ｍサーバーアカウントが削除される際、Ｍ２Ｍクライアントは独自でアクセス権限所有者を変更することができる。変更する方法は、
Ｂ−１）一般に、ＡＣＬにおいて最高のアクセス権限を有するＭ２Ｍサーバーを新しいアクセス権限所有者として設定する。「最高」のアクセス権限とは、各種のアクセス権限のうち、当該リソース又はこれと関連した他のリソースに影響を及ぼす範囲が最も広いアクセス権限を意味し、例えば、「読み取り」に対するアクセス権限よりは「書き込み」に対するアクセス権限が、高いアクセス権限である。

このとき、各動作命令に対するアクセス権限ごとに特定値を与え、該当の値の和（ｓｕｍ）が最も高いＭ２Ｍサーバーを、新しいアクセス権限所有者に変更することができる。例えば、Ｍ２Ｍサーバー１は書き込み、読み取りに対するアクセス権限を有し、Ｍ２Ｍサーバー２は書き込み、実行に対するアクセス権限を有する場合、Ｍ２Ｍサーバー１が新しいアクセス権限所有者となる（命令別に与えられた値−書き込み：４、読み取り：２、実行：１）。

なお、上記の各動作命令に対するアクセス権限に与えられる値は一例であり、全ての動作命令に対するアクセス権限に同一の値（例えば、１）を与えてもよい。これはすなわち、最も多い種類の動作命令に対するアクセス権限を有するＭ２Ｍサーバーを新しいアクセス権限所有者として指定できるということを意味する。

Ｂ−２）全てのＭ２Ｍサーバーをアクセス権限所有者として指定する。このとき、当該Ｍ２Ｍクライアントに登録されている全てのＭ２Ｍサーバーをアクセス権限所有者として指定してもよく、又は該当のリソースに対してアクセス権限があるＭ２Ｍサーバーのみをアクセス権限所有者として指定してもよい。このような方法は、例えば、ＡＣＬに明示されていないサーバーのためのデフォルト（ｄｅｆａｕｌｔ）ＡＣＬエントリーのみが残っている場合に有用である。

Ｂ−３）アクセス権限オブジェクトインスタンスにおける最初のＭ２Ｍサーバーをアクセス権限所有者として指定する。

Ｂ−４）アクセス権限所有者を空に残しておき、該当のリソースに初めてアクセスするＭ２Ｍサーバーをアクセス権限所有者として指定する。

Ｃ）リソースの削除（Ｒｅｓｏｕｒｃｅ Ｄｅｌｅｔｉｏｎ）
アクセス権限所有者であるＭ２Ｍサーバーのアカウントが削除される際、上記Ｍ２Ｍサーバーがアクセス権限所有者として指定されているリソース（例えば、特定アクセス制御オブジェクトインスタンス）を削除することができる。すなわち、リソースの主人の役割をするＭ２Ｍサーバーが削除されることから、当該リソースも削除をする。このとき、上記リソースと関連した特定リソースと該特定リソースのアクセス権限値も削除する。

Ｄ）新しいアクセス権限所有者の指定
削除されるＭ２Ｍサーバーが、自身がアクセス権限所有者であるリソースに対して権限委任を頼む命令を送信することができる。すなわち、サーバーアカウント削除のための動作命令が入る前に、特定Ｍ２Ｍサーバー（当該アクセス権限を委任してもらうＭ２Ｍサーバー）が設定されており、削除されたＭ２Ｍサーバーがアクセス権限所有者であったリソースのアクセス権限所有者として、上記特定Ｍ２Ｍサーバーを追加する。

又は、サーバーアカウント削除のための動作命令内に、当該サーバーアカウントの削除後のアクセス権限所有者（すなわち、他のＭ２ＭサーバーのＩＤなど）を含めることで、上記サーバーのアカウントが削除される際、削除されたサーバーがアクセス権限所有者であるリソースに対して、上記削除のための動作命令内に含まれているサーバーが新しいアクセス権限所有者となるように指定することができる。

リソース削除（Ｒｅｓｏｕｒｃｅ Ｄｅｌｅｔｉｏｎ）
特定Ｍ２Ｍサーバーのアカウントが削除される際、上記特定Ｍ２ＭサーバーをＡＣＬから削除するが、特定リソース（例えば、オブジェクト）に対して上記削除されるＭ２Ｍサーバーがアクセス権限所有者であり、ＡＣＬに存在する唯一のサーバーである場合には、ＡＣＬを含んでいるアクセス制御オブジェクトインスタンスだけでなく、当該アクセス制御オブジェクトインスタンスと関連付けられた特定オブジェクトインスタンスも削除することができる。

特定Ｍ２Ｍサーバーのアカウントが削除されると、クライアントは、上記特定Ｍ２Ｍサーバーが以前に特定イベントに対する報告のために設定した値を解除することができる。

また、上述したアクセス権限設定、リソース削除、報告解除などのような作業は、サーバーに知らせることができる。

観察のためのアクセス制御（Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ ｆｏｒ Ｏｂｓｅｒｖａｔｉｏｎ）
Ｍ２Ｍサーバーは、Ｍ２Ｍクライアントから特定リソース又はリソースグループ（例えば、オブジェクトインスタンス）の変化について報告を受けることを希望してもよい。このような報告のために、前述した「観察」機能を用いて該当のリソース又はリソースグループの変化を確認することができる。しかし、「観察」機能を登録するにあって何ら制約がなく、当該リソースに対して読み取った（「読み取り」動作命令による）場合と同一の効果を出すことがあり、このため、上記「読み取り」動作命令に対するアクセス権限のないＭ２Ｍサーバーが、当該リソースの値を読むことができる。

このようなことを防止するために観察機能を登録するとき、それによる報告時のアクセス制御技法を説明する。

このような技法は、他の動作命令にも適用可能である。すなわち、同一の効果（又は、結果）を出す動作命令の場合、両動作命令に対するアクセス権限を別々にせず、一つのアクセス権限にしてアクセス制御を行うことができる。その一例は、次のとおりである。

− 観察登録（Ｏｂｓｅｒｖａｔｉｏｎ Ｒｅｇｉｓｔｒａｔｉｏｎ）
図６は、本発明の一実施例に係る観察登録を示すフローチャートである。

サーバー１００はクライアント２００に特定リソースに対する観察登録を要求することができる（Ｓ６１０）。すると、上記クライアントは、当該リソースに対してＭ２Ｍサーバーが当該リソースを読み得る権限（例えば、「読み取り」動作命令に対するアクセス権限）があるか確認することができる（Ｓ６２０）。上記権限があると、上記クライアントは、当該サーバーＩＤと当該リソースを記憶し（Ｓ６３０−１）、上記観察登録が成功的に処理されたことを上記サーバーに応答することができる（Ｓ６４０）。その後、当該リソースが変更される場合、報告プロセスに移行する。

しかし、上記権限がないと、登録はなされず、上記クライアントは、上記観察登録に失敗したことを上記サーバーに応答することができる（Ｓ６３０−２）。

認証を行う範囲を超えるリソースに対しても観察を行うことができるが、例えば、Ｍ２Ｍサーバーの観察動作命令がオブジェクトＩＤのみをターゲットとする場合に、上記オブジェクトＩＤが示すオブジェクトと関連付けられたオブジェクトインスタンスが複数個存在し、上記Ｍ２Ｍサーバーは少なくとも一つのオブジェクトインスタンスに対する「読み取り」権限がない場合がありうる。この場合、２つの方法が存在する。

１．観察登録時には認証を行わずに無条件で受諾するように設定することができる。この場合、オブジェクトインスタンスのうち、認証（該当のＭ２Ｍサーバーが読み取り権限を有するか）に成功したオブジェクトインスタンスに対してのみ報告を行うことができる。又は、認証に成功したオブジェクトインスタンスを個別的に取扱い、それぞれの認証に成功したオブジェクトインスタンスのうち一つのオブジェクトインスタンスに変更が発生したとき、該当のＭ２Ｍサーバーが変更の発生したオブジェクトインスタンスに対して認証に成功すると（すなわち、該当のサーバーが当該オブジェクトインスタンスに対して「読み取り」権限を有すると）、一つのオブジェクトインスタンス（すなわち、個別オブジェクトインスタンス）に対する報告を行うことができる。

２．観察登録時に、全てのオブジェクトインスタンスごとに認証を行い、認証に成功したオブジェクトインスタンスに対してのみ観察を行うことができる。この場合、観察報告時には、登録時に認証に成功したオブジェクトインスタンスの全体に対して認証（該当のＭ２Ｍサーバーが読み取り動作命令に対するアクセス権限を有するか否かによって判断）に成功した場合にのみ報告が行われてもよく、又は、登録時に認証に成功したオブジェクトインスタンスのうち、報告時に認証（該当のＭ２Ｍサーバーが読み取り動作命令に対するアクセス権限を有するか否かによって判断）に成功したオブジェクトインスタンスのみに対して報告が行われてもよい。又は、登録時に認証に成功したオブジェクトインスタンスを個別的に取扱い、それぞれの成功したオブジェクトインスタンスに変更が発生したとき、該当のＭ２Ｍサーバーが変更の発生したオブジェクトインスタンスに対して認証（該当のＭ２Ｍサーバーが読み取り動作命令に対するアクセス権限を有するか否かによって判断）成功時に報告が行われてもよい。

− 観察登録報告（Ｏｂｓｅｒｖａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ）
図７は、本発明の一実施例に係る観察報告を示すフローチャートである。

観察機能に対する登録をする時点と報告をする時点との間にＭ２Ｍサーバーのアクセス権限が変更されることもある。このため、上記観察機能に対する報告をする時点にも（すなわち、観察報告対象のリソースに対する変更の発生時に）、Ｍ２Ｍクライアントは、Ｍ２Ｍサーバーが当該リソースに「読み取り」アクセス権限を有しているか否かを確認することができる（Ｓ７２０）。上記「読み取り」アクセス権限を有していると、上記Ｍ２Ｍクライアントは、当該リソースに対する報告（通知）を行うことができる（Ｓ７３０−１）。上記「読み取り」アクセス権限がないと、上記Ｍ２Ｍクライアントは独自で観察取消し（なお、該当の観察機能設定を削除してもよい）、これをＭ２Ｍサーバーに知らせることができる（Ｓ７３０−２）。

一方、上記の観察に対する報告は、前述した情報報告インターフェースを介した通知（Ｎｏｔｉｆｙ）動作命令によって行うことができる。これについてより詳しく説明する。

図８は、本発明の一実施例に係る観察及びそれによる通知を示すフローチャートである。

Ｍ２Ｍサーバーは、Ｍ２Ｍクライアント内で非周期的に更新される温度に対して観察を要求する。

さらにいうと、上記Ｍ２Ｍサーバーは、上記温度と関連したリソースに対して、最小周期＝１０秒且つ最大周期＝６０秒が設定された観察を要求することができる。これは、前述したように、「装置管理及びサービスイネーブルメントインターフェース」を介した「書き込み属性」動作命令と「情報報告インターフェース」を介した「観察」動作命令によって行うことができる。具体的に、上記「通知」の具体的な設定値のためのパラメータ設定（すなわち、最小周期及び最大周期）は、「書き込み属性」動作命令によって行われ（Ｓ８１０）、これに対する応答として、Ｍ２Ｍクライアントは、上記「書き込み属性」動作命令に対する結果（例えば、成功）を応答することができる（Ｓ８２０）。

その後、上記Ｍ２Ｍサーバーは、上記Ｍ２Ｍクライアントに上記温度に関連したリソースに対する観察を要求することができる（Ｓ８３０）。これに対する応答として、Ｍ２Ｍクライアントは、上記「観察」動作命令に対する結果（例えば、成功）を応答することができる（Ｓ８４０）。

上記Ｍ２Ｍクライアントは上記Ｍ２Ｍサーバーに「通知」を送信する前に、その前に上記リソースの値が変更されても、少なくとも１０秒を待つはずであり、１０秒経過後に上記Ｍ２Ｍサーバーに上記リソースに対する値を通知することができる（Ｓ８５０）。

また、上記通知から４０秒後に、上記リソースの値に変更があると、上記Ｍ２Ｍクライアントは上記Ｍ２Ｍサーバーに上記リソースに対する値を通知することができる（Ｓ８６０）。

続いて、上記リソースの値が変更されていなくても、６０秒が経過する前に、上記Ｍ２Ｍクライアントは上記「通知」を送信しなければならない（Ｓ８７０）。

すなわち、上記通知に関する設定（すなわち、最小周期及び最大周期）に従って、上記通知がなされる時点が制限され、より詳しくは、上記最小周期以降に且つ上記最大周期以前に少なくとも１回は必ず通知がある。

上記の設定に従って、上記「通知」は、上記リソースに変更が発生すると、１０乃至６０秒範囲の任意の時点で送信することができる。

なお、上記観察に対する取消も可能である。これは、前述した「観察取消」動作命令によって行うことができる。

「観察取消」動作命令は、Ｍ２ＭサーバーからＭ２Ｍクライアントに、オブジェクトインスタンス又はリソースに対する観察関係を終了するために送信される。この動作命令は、Ｍ２Ｍレイヤでいかなるパラメータも含まない。上記「観察取消」動作命令は、「通知」動作命令の応答として用いられなければならない。

観察取消のために、Ｍ２Ｍサーバーは次の２つの方法が可能である。

− 「観察取消」動作命令の送信
このオプションの制限は、Ｍ２Ｍサーバーがそれ以上関心のない「通知」動作を受信するということであり、Ｍ２Ｍサーバーはそれ以上関心のない「通知」動作を受信すると、この「通知」動作に応答して「観察取消」を送信することができる。

− 取消パラメータを含んでいる「書き込み属性」動作命令の送信
このオプションは制限がない。Ｍ２ＭサーバーがＭ２Ｍクライアント内の特定ＵＲＩに、取消パラメータを含んでいる「書き込み属性」動作命令を送信すると、上記Ｍ２Ｍクライアントは、特定のＵＲＩのための観察を独自で取消すことができる。

接続モード（Ｃｏｎｎｅｃｔｉｏｎ Ｍｏｄｅ）設定
Ｍ２Ｍサーバーは接続モードを設定することができる。このような設定は、デバイスのスリープ（Ｓｌｅｅｐ）を長くさせてバッテリーの電力消耗を減らすためのものであり、設定によってより安定した通信を維持する目的で用いることができる。

− 常時オンライン（Ａｌｗａｙｓ Ｏｎｌｉｎｅ）
Ｍ２Ｍサーバーは、設定によってＭ２Ｍクライアントの状態をオンラインに維持することができる。この状態では、Ｍ２Ｍサーバーが必要時にはいつでも命令（管理又は動作命令）をＭ２Ｍクライアントに送信することができる。

− イベント基盤オンライン（Ｅｖｅｎｔ Ｄｒｉｖｅｎ Ｏｎｌｉｎｅ）
Ｍ２Ｍサーバーは、設定によって、イベントを用いてＭ２Ｍクライアントをオンライン状態にすることができる。この場合、イベント発生時にＭ２Ｍクライアントは、自身がオンラインであることを知らせるメッセージを送信し、Ｍ２Ｍサーバーの命令（管理又は動作命令）を特定時間待ったり、又は命令を待つ間にＭ２Ｍサーバーから特定命令を持続して送信する場合、最後の命令を基点に特定時間を待つことができる。

− 周期的オンライン（Ｐｅｒｉｏｄｉｃ Ｏｎｌｉｎｅ）
Ｍ２Ｍサーバーは、設定によって、Ｍ２Ｍクライアントを周期的にオンライン状態に維持させることができる。Ｍ２Ｍサーバーによって又はあらかじめ設定された周期が設定されており、該当の周期になると、Ｍ２ＭクライアントはＭ２Ｍサーバーに、自身がオンライン状態であることを知らせるメッセージを送信し、Ｍ２Ｍサーバーの命令（管理又は動作命令）を特定時間待ったり、又は命令を待つ間に上記Ｍ２Ｍサーバーから特定命令を持続して送信する場合は、最後の命令を基点に特定時間を待つことができる。当該周期は、Ｍ２Ｍクライアントに発生するイベントとは別個として発生し、当該周期になると、オフライン時に蓄えておいた報告情報をＭ２Ｍサーバーに送信することができる。

又は、Ｍ２Ｍサーバーは、Ｍ２Ｍクライアントがオンラインになる時点を決定することができる。例えば、毎日午後３時５分と設定されていると、当該時間にＭ２Ｍクライアントは更新メッセージを送信し、Ｍ２Ｍサーバーが特定動作命令を行えるようにする。当該設定にはタイムアウト（Ｔｉｍｅｏｕｔ）が存在してもよいが、タイムアウトが存在すると、該当の時間までＭ２ＭクライアントはＭ２Ｍサーバーとオンライン状態を維持する。

− モード変更考慮（Ｍｏｄｅ Ｃｈａｎｇｅ Ｃｏｎｓｉｄｅｒａｔｉｏｎｓ）
イベント基盤オンライン又は周期的オンラインの場合、Ｍ２ＭサーバーはＭ２Ｍクライアントとの安定した通信がし難い。持続した通信が必要な場合（例えば、ファームウェアアップデートなど）、Ｍ２Ｍサーバーは、当該Ｍ２Ｍクライアントが臨時的にオンライン状態の時に、オンラインモードへの変更命令を送信し、持続した通信が終了すると、再びモード変更によって、既存のモードに変更又は他のモードに変更させることができる。又は、常時オンラインモードが持続するようにしてもよい。

− イベントレベル考慮（Ｅｖｅｎｔ Ｌｅｖｅｌ Ｃｏｎｓｉｄｅｒａｔｉｏｎｓ）
イベントにはレベルが存在してもよいが、レベルは、スリープモード（又は、接続解除状態）からオンラインモードに変更する必要かあるか否かによって、２つに分類することができる。

オンラインモードへの変更が必要なレベルのイベントであると、該当の時点に直ちにＭ２Ｍクライアントはオンライン状態になって報告を行い、オンラインモードへの変更が必要なレベルのイベントでないと、他の理由でオンライン状態になる時点に当該イベントを報告することができる。

図９は、本発明の一実施例に係る動作を示すフローチャートである。

端末は、第１サーバーから特定サーバーのアカウントを削除するための動作命令（例えば、「削除」動作命令）を受信することができる（Ｓ９１０）。本発明でサーバーのアカウント（又は、サーバーアカウント）は、オブジェクトインスタンス名に制限されず、特定サーバーに関する情報の集合を意味する。より具体的に、上記サーバーのアカウント（又は、サーバーアカウント）は、上述したサーバーオブジェクト（インスタンス）及び保安オブジェクト（インスタンス）を含む包括的な概念であり、さらに、上記保安オブジェクト（インスタンス）で「ブートストラップサーバー」リソースがｆａｌｓｅであることを意味する。

上記の削除するための動作命令は、ブートストラップインターフェースを介して受信することができ、このため、上記第１サーバーはブートストラップサーバーであってもよい。

上記端末は、上記特定サーバーと関連付けられたオブジェクトインスタンスのうち、上記特定サーバーのみがアクセスできるオブジェクトインスタンスがあるか否か判断することができる（Ｓ９２０）。

上記特定サーバーと関連付けられたオブジェクトインスタンスのうち、上記特定サーバーのみがアクセスできるオブジェクトインスタンスがあると、上記端末は、当該オブジェクトインスタンスとこれと関連付けられたアクセスオブジェクトインスタンスを削除することができる（Ｓ９３０）。すなわち、上記端末は、上記特定サーバーのアクセス権限情報を削除することができる。これは、当該オブジェクトインスタンスは他のサーバーといかなる関連付けもなく、当該オブジェクトインスタンス及びこれと関連付けられたアクセスオブジェクトインスタンスは、上記特定サーバーのアカウントが削除されるといかなるサーバーによってもアクセス可能でなく、よって、削除する方がリソース活用及び管理の観点で好ましいためである。

一方、上記特定サーバーと関連付けられたオブジェクトインスタンスのうち、上記特定サーバーを含む複数のサーバーがアクセスできるオブジェクトインスタンスがあると、上記端末は、そのオブジェクトインスタンスと関連付けられたアクセスオブジェクトインスタンスから上記特定サーバーと関連したリソース、例えば、前述したアクセス制御オブジェクトインスタンスのＡＣＬエントリーを削除することができる（Ｓ９３１）。これは、Ｓ９３０と違い、他のサーバーが上記オブジェクトインスタンスにアクセスすることができ、よって、上記特定サーバーと関連したリソースのみを削除することが好ましいためである。

なお、上記端末は、上記特定サーバーが上記アクセス制御オブジェクトインスタンスのアクセス制御所有者であるか否かを判断することができる（Ｓ９３２）。

上記特定サーバーが上記アクセス制御オブジェクトインスタンスのアクセス制御所有者であれば、上記端末は、次のような方式を用いて上記アクセス制御オブジェクトインスタンスのための新しいアクセス制御所有者を設定することができる（Ｓ９３３）。これによって、アクセス制御オブジェクトインスタンスに対する管理者（すなわち、アクセス制御所有者）の不在によるリソース管理の不便さ及びリソースの活用制約を解消／防止することができる。

上記アクセス制御オブジェクトインスタンスで指定された（又は、許容された）それぞれのアクセス権限別に特定値が与えられる。例えば、「書き込み」動作命令に対するアクセス権限には「１」を、「読み取り」動作命令に対するアクセス権限には「２」を与えることができる。上記端末は、各サーバーに対する上記値の和を計算し、和が最も大きいサーバーを新しいアクセス制御所有者と設定することができる。仮に、同一の和を有するサーバーが２つ以上であれば、上記端末は、それらの中から一つを選択して新しいアクセス制御所有者として設定することができる。

上記特定サーバーが上記アクセス制御オブジェクトインスタンスのアクセス制御所有者でないと、Ｓ９３３は行われない。

その後、端末は、自身が持っている全てのオブジェクトインスタンスに対して上記特定サーバーがアクセス権限を有するか否かを確認することができる（Ｓ９４０）。すなわち、ある動作命令に対してアクセス権限があるか否かを確認することができる。仮に、ある動作命令に対して上記特定サーバーがアクセス権限を有するオブジェクトインスタンスが存在すると、上記端末は、Ｓ９２０に戻って本発明の動作を繰り返すことができる。すなわち、上記特定サーバーがアクセス権限を有する動作命令が明示されたリソースが存在しないまで本発明の動作を行うことができる。

上記特定サーバーがアクセス権限を有する動作命令が存在しないと判断されると、上記端末は、上記特定サーバーによって設定された観察動作設定を取消すことができる（Ｓ９５０）。すなわち、上記端末は、上記特定サーバーが送信した観察動作命令に応じて記憶した設定情報を削除することができる。

その後、上記端末は、上記特定サーバーのアカウントを完全に削除することができる（Ｓ９６０）。すなわち、上記特定サーバーのアカウント削除の要求はＳ９１０で受信されたが、実質的にこの段階で上記特定サーバーのアカウントが削除される。上記削除命令を先に処理すると、サーバーアカウント内の短いサーバーＩＤの情報が削除されため、アクセス制御オブジェクトインスタンスから上記サーバーの短いサーバーＩＤに基づいてＡＣＬエントリーを削除しなければならないが、短いサーバーＩＤが既に削除されて探すことができず、よって、上記特定サーバーのアカウントを最後に削除するわけである。続いて、上記端末は、上記特定サーバーに対する「登録解除（Ｄｅ−ｒｅｇｉｓｔｅｒ）」動作命令を送信することができる（Ｓ９７０）。

図９と関連して説明した実施例は、図１乃至図８を参照して説明した内容を参照することができ、したがって、当業者は、図１乃至図８に関する説明（特に、表）を参照して、図９に関する実施例をより具体的に限定することもできる。

また、上記端末は、図９に示した段階の一部のみを選択して行うこともできる。

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

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

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

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

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

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

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

Claims (14)

1. 無線通信システムでサーバーのアカウント削除による、前記サーバーと関連した特定オブジェクトインスタンスの処理方法において、前記方法は、端末によって行われ、
   第１サーバーから特定サーバーのアカウントを削除するための動作命令を受信するステップと、
   前記特定オブジェクトインスタンスが、前記特定サーバーのみがアクセス可能なオブジェクトインスタンスであれば、前記特定オブジェクトインスタンス及びそれと関連したアクセス制御オブジェクトインスタンスを削除するステップと、
   前記特定オブジェクトインスタンスが、前記特定サーバーを含めた複数のサーバーがアクセス可能なオブジェクトインスタンスであれば、前記特定オブジェクトインスタンスと関連したアクセス制御オブジェクトインスタンスにおいて前記特定サーバーのアクセス権限情報を削除するステップと、
   前記特定サーバーが前記アクセス制御オブジェクトインスタンスの唯一のアクセス制御所有者であれば、前記特定サーバー以外の前記複数のサーバーのそれぞれが有するアクセス権限に与えられた値の和が最も大きいサーバーを前記アクセス制御所有者に変更するステップと、
   を有する、特定オブジェクトインスタンスの処理方法。
2. 前記変更するステップは、
   前記値の和が最も大きいサーバーが２つ以上であれば、前記２つ以上のサーバーから一つを選択し、前記選択されたサーバーを前記アクセス制御所有者に変更するステップを有する、請求項１に記載の特定オブジェクトインスタンスの処理方法。
3. 前記特定サーバーのアカウントを削除するための動作命令は、ブートストラップインターフェースを介して受信される、請求項１に記載の特定オブジェクトインスタンスの処理方法。
4. 前記第１サーバーは、ブートストラップサーバーである、請求項１に記載の特定オブジェクトインスタンスの処理方法。
5. 第２サーバーによる前記アクセス制御オブジェクトインスタンスのアクセス制御所有者に対して観察動作が設定されていると、前記アクセス制御所有者の変更時に、前記第２サーバーに前記変更に対する通知を送信するステップをさらに有する、請求項１に記載の特定オブジェクトインスタンスの処理方法。
6. 前記特定サーバーが送信した観察動作命令によって記憶した観察動作命令関連設定情報を削除するステップをさらに有する、請求項１に記載の特定オブジェクトインスタンスの処理方法。
7. 前記特定サーバーのアカウントは、前記特定サーバーの短いサーバーＩＤ及び前記特定サーバーとの通信のための保安キーを含む、請求項１に記載の特定オブジェクトインスタンスの処理方法。
8. 無線通信システムでサーバーのアカウント削除による、前記サーバーと関連した特定オブジェクトインスタンスを処理するように構成された端末であって、
   無線周波数（ｒａｄｉｏ ｆｒｅｑｕｅｎｃｙ：ＲＦ）ユニットと、
   前記ＲＦユニットを制御するように構成されたプロセッサと、
   を備え、
   前記プロセッサは、第１サーバーから特定サーバーのアカウントを削除するための動作命令を受信し、
   前記特定オブジェクトインスタンスが、前記特定サーバーのみがアクセス可能なオブジェクトインスタンスであれば、前記特定オブジェクトインスタンス及びそれと関連したアクセス制御オブジェクトインスタンスを削除し、
   前記特定オブジェクトインスタンスが、前記特定サーバーを含めた複数のサーバーがアクセス可能なオブジェクトインスタンスであれば、前記特定オブジェクトインスタンスと関連したアクセス制御オブジェクトインスタンスにおいて前記特定サーバーのアクセス権限情報を削除し、
   前記特定サーバーが前記アクセス制御オブジェクトインスタンスの唯一のアクセス制御所有者であれば、前記特定サーバー以外の前記複数のサーバーのそれぞれが有するアクセス権限に与えられた値の和が最も大きいサーバーを前記アクセス制御所有者に変更するように構成された、端末。
9. 前記プロセッサは、
   前記値の和が最も大きいサーバーが２つ以上であれば、前記２つ以上のサーバーから一つを選択し、前記選択されたサーバーを前記アクセス制御所有者に変更するように構成された、請求項８に記載の端末。
10. 前記特定サーバーのアカウントを削除するための動作命令は、ブートストラップインターフェースを介して受信される、請求項８に記載の端末。
11. 前記第１サーバーは、ブートストラップサーバーである、請求項８に記載の端末。
12. 第２サーバーによる前記アクセス制御オブジェクトインスタンスのアクセス制御所有者に対して観察動作が設定されていると、前記プロセッサは、前記アクセス制御所有者の変更時に、前記第２サーバーに前記変更に対する通知を送信するように構成された、請求項８に記載の端末。
13. 前記プロセッサは、前記特定サーバーが送信した観察動作命令によって記憶した観察動作命令関連設定情報を削除するように構成された、請求項８に記載の端末。
14. 前記特定サーバーのアカウントは、前記特定サーバーの短いサーバーＩＤ及び前記特定サーバーとの通信のための保安キーを含む、請求項８に記載の端末。