(57)【要約】【課題】アクセス制御規則の記述量を削減することができるデータ構造、生成装置、生成方法およびプログラムを提供すること。【解決手段】前記コンポーネントが管理するデータであるポイントのポイント情報を記述する領域と、前記ポイントのポイント識別情報を記述する領域と、要求を送信するイニシエータのイニシエータ識別情報を記述する領域と、前記要求に対する応答をする側の装置であるレスポンダーの識別情報を記述する領域と、前記イニシエータがレジストリへのアクセスを許可するか否かを表すアクセス可否情報を記述する領域と、を含むデータ構造。【選択図】図１
2015099572.tif 000002
【特許請求の範囲】
【請求項１】
通信システムの構成機器であるコンポーネントから取得されるデータであるポイントのポイント情報を記述する領域と、
前記ポイントのポイント識別情報を記述する領域と、
要求を送信するイニシエータのイニシエータ識別情報を記述する領域と、
前記要求に対する応答をする側の装置であるレスポンダーの識別情報を記述する領域と、
前記イニシエータがリソース情報管理装置へのアクセスを許可するか否かを表すアクセス可否情報を記述する領域と、
を含むこと
を特徴とするデータ構造。
【請求項２】
通信システムの構成機器であるコンポーネントから取得されるデータであるポイントのポイント情報を記述する領域と、
前記ポイントのポイント識別情報を記述する領域と、
要求を送信するイニシエータのイニシエータ識別情報を記述する領域と、
前記要求に対する応答をする側の装置であるレスポンダーの識別情報を記述する領域と、
前記イニシエータがリソース情報管理装置へのアクセスを許可するか否かを表すアクセス可否情報を記述する領域と、
を含むデータ構造のアクセス制御規則を生成する生成装置。
【請求項３】
通信システムの構成機器であるコンポーネントから取得されるデータであるポイントのポイント情報を記述する領域と、
前記ポイントのポイント識別情報を記述する領域と、
要求を送信するイニシエータのイニシエータ識別情報を記述する領域と、
前記要求に対する応答をする側の装置であるレスポンダーの識別情報を記述する領域と、
前記イニシエータがリソース情報管理装置へのアクセスを許可するか否かを表すアクセス可否情報を記述する領域と、
を含むデータ構造のアクセス制御規則を生成する生成方法。
【請求項４】
コンピュータに、
通信システムの構成機器であるコンポーネントから取得されるデータであるポイントのポイント情報を記述する領域と、
前記ポイントのポイント識別情報を記述する領域と、
要求を送信するイニシエータのイニシエータ識別情報を記述する領域と、
前記要求に対する応答をする側の装置であるレスポンダーの識別情報を記述する領域と、
前記イニシエータがリソース情報管理装置へのアクセスを許可するか否かを表すアクセス可否情報を記述する領域と、
を含むデータ構造のアクセス制御規則を生成させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ構造、生成装置、生成方法およびプログラムに関する。
【背景技術】
【０００２】
電力の見える化、省エネ制御や生活利便性向上などを実現するために、各種センサまたはアクチュエータなどのデバイス、データ蓄積機能を有するストレージ、アプリケーション、システムのマネージャ機能を有する装置などが相互に連携するシステムとそれを実現するための仕組みが普及しつつある。特に大規模なシステムでは、大量のデバイスが存在し、それらのデバイスから取得されストレージに蓄積される大量のデータが扱われる。このため、システムは、多種の機器を接続可能な柔軟性と、機器の構成管理と、が可能であることが重要となる。
【０００３】
これを実現するための仕組みの一つとして、デバイス、ストレージ、アプリケーションなどが相互に連携するための標準化プロトコルとしてＩＥＥＥ１８８８が規定されている。ＩＥＥＥ１８８８では、デバイス、ストレージ、アプリケーションなどのそれぞれを「コンポーネント」として扱う。
【０００４】
このようなシステムでは、デバイスに対するアクセスを制御することによって第三者からのアクセスを制限するだけではシステム全体のセキュリティを確保することは困難である。例えば、あるアプリケーションに対しては、センサデータを渡さないようにセンサ側で設定した場合でも、そのデータを別のストレージで蓄積し、そのストレージがアプリケーションのアクセス制御を行わなければ、結果としてアプリケーションにセンサデータが取得されることになる。また、複数のセンサで取得されたデータが同一のストレージに蓄積されるなどの事例も発生するため、ストレージは、データごとにアクセス制御する必要がある。
【０００５】
このように、デバイスとデータとの所属関係が複雑化するシステム内で、適切なセキュリティを実現する仕組みとしてＩＥＥＥ１８８８の拡張仕様であるＩＥＥＥ１８８８．３が定義されている。ＩＥＥＥ１８８８では、当該デバイスから取得されるデータの単位を「ポイント」として扱う（例えば、非特許文献１参照）。ＩＥＥＥ１８８８．３では、ポイント、手順、メソッドレベルでのアクセス制御ルールの記述とその運用が定義されており、これらの機能は、アクセス制御装置（ＡＣＭ：Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ  Ｍａｎａｇｅｒ）で実現すると規定されている。また、ＩＥＥＥ１８８８．１では、アクセス制御装置に対してアクセス制御規則（ＡＣＬ：Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ  Ｌｉｓｔ）を管理して配布するリソースアクセス制御装置（ＲＡＭ：Ｒｅｓｏｕｒｃｅｓ  Ａｃｃｅｓｓ  Ｍａｎａｇｅｒ）について規定されている。また、ＩＥＥＥ１８８８．１では、アクセス制御規則を配布する方法、またはアクセス制御規則を取得する方法について、コンポーネント通信を用いることが規定されている。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】「スマートコミュニティを支える基盤技術―大量センシングポイント・コンポーネントの管理、アドレス解決技術ＩＥＥＥ１８８８レジストリの概要」、ＮＴＴ技術ジャーナル、２０１２年１１月、ｐｐ．３８−４１
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、ＩＥＥＥ１８８８．１で規定されているコンポーネントがリソースアクセス制御装置に対してアクセス制御規則を取得する方法では、コンポーネント通信で用いられるマークアップ言語（ＸＭＬ：Ｅｘｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）上で表現できるように記述され、例えば、識別情報（ｉｄ：Ｉｄｅｎｔｉｆｅｒ）の属性に必要な情報をすべて記述するため、アクセス制御規則の記述量が多くなるという問題があった。
【０００８】
そこで本発明は、上記問題に鑑みてなされたものであり、アクセス制御規則の記述量を削減することができるデータ構造、及び生成装置を提供することを課題とする。
【課題を解決するための手段】
【０００９】
（１）本発明の一態様は、通信システムの構成機器であるコンポーネントから取得されるデータであるポイントのポイント情報を記述する領域と、前記ポイントのポイント識別情報を記述する領域と、要求を送信するイニシエータのイニシエータ識別情報を記述する領域と、前記要求に対する応答をする側の装置であるレスポンダーの識別情報を記述する領域と、前記イニシエータがリソース情報管理装置へのアクセスを許可するか否かを表すアクセス可否情報を記述する領域と、を含むことを特徴とするデータ構造である。
【００１０】
（２）また、本発明の一態様は、通信システムの構成機器であるコンポーネントから取得されるデータであるポイントのポイント情報を記述する領域と、前記ポイントのポイント識別情報を記述する領域と、要求を送信するイニシエータのイニシエータ識別情報を記述する領域と、前記要求に対する応答をする側の装置であるレスポンダーの識別情報を記述する領域と、前記イニシエータがリソース情報管理装置へのアクセスを許可するか否かを表すアクセス可否情報を記述する領域と、を含むデータ構造のアクセス制御規則を生成する生成装置である。
【００１１】
（３）また、本発明の一態様は、通信システムの構成機器であるコンポーネントから取得されるデータであるポイントのポイント情報を記述する領域と、前記ポイントのポイント識別情報を記述する領域と、要求を送信するイニシエータのイニシエータ識別情報を記述する領域と、前記要求に対する応答をする側の装置であるレスポンダーの識別情報を記述する領域と、前記イニシエータがリソース情報管理装置へのアクセスを許可するか否かを表すアクセス可否情報を記述する領域と、を含むデータ構造のアクセス制御規則を生成する生成方法である。
【００１２】
（４）また、本発明の一態様は、コンピュータに、通信システムの構成機器であるコンポーネントから取得されるデータであるポイントのポイント情報を記述する領域と、前記ポイントのポイント識別情報を記述する領域と、要求を送信するイニシエータのイニシエータ識別情報を記述する領域と、前記要求に対する応答をする側の装置であるレスポンダーの識別情報を記述する領域と、前記イニシエータがリソース情報管理装置へのアクセスを許可するか否かを表すアクセス可否情報を記述する領域と、を含むデータ構造のアクセス制御規則を生成させるためのプログラムである。
【発明の効果】
【００１３】
本発明のデータ構造、生成装置、生成方法およびプログラムによれば、アクセス制御規則の記述量を削減することができる。
【図面の簡単な説明】
【００１４】
【図１】本発明の実施形態に係る通信システムの構成の一例を示す概略図である。
【図２】本発明の実施形態に係るアクセス制御規則を表すデータの一例を示す概略図である。
【図３】本発明の実施形態に係る通信システムの一例を示す概略ブロック図である。
【図４】本発明の実施形態に係る通信システムの処理の一例を示すシーケンス図である。
【図５】本発明の実施形態に係るリソースアクセス制御装置のハードウェア構成の一例を示すハードウェア構成図である。
【発明を実施するための形態】
【００１５】
（実施形態）
以下、本発明の実施形態について、図面を参照して詳細に説明する。
【００１６】
図１は、本発明の実施形態に係る通信システム１の構成の一例を示す概略図である。
通信システム１は、ゲートウェイ（ＧＷ：ＧａｔｅＷａｙ）１１〜１２と、ストレージ２１〜２２と、アプリケーション３１〜３２と、レジストリ（リソース情報管理装置）４０と、リソースアクセス制御装置（ＲＡＭ：Ｒｅｓｏｕｒｃｅ  Ａｃｃｅｓｓ  Ｍａｎａｇｅｒ）５０と、センサ１１１およびセンサ１２１〜１２２と、アクチュエータ１１２と、ＡＣＭ（アクセス制御装置）６０およびアクセス制御装置７０と、を備える。ＧＷ１１には、センサ１１１と、アクチュエータ１１２と、ＡＣＭ６０と、が接続されている。ＧＷ１２には、センサ１２１およびセンサ１２２が接続されている。センサ１１１、１２１、１２２およびアクチュエータ１１２を総称して、デバイス機器と称する。デバイス機器、ストレージ２１〜２２、およびアプリケーション３１〜３２は、それぞれコンポーネントの一例である。また、各ＧＷ１１〜１２で管理される各デバイス機器から取得されるデータの単位をポイントと称する。
【００１７】
各デバイス機器は、購入・移設やメンテナンスの管理の単位となる機器製品であり、例えば電力センサ、温度センサなどのセンサやスマートタップ、スマートメータ、空調機器などの電源・温度制御などが可能なアクチュエータなどであり、一つまたは複数のセンサ、スイッチなどを搭載する。各デバイス機器は、例えば、各ＧＷ１１〜１２に接続されている。例えば、デバイス機器が電力計測器である場合、デバイス機器は、電力値などのセンサデータを管理される各ＧＷ１１〜１２に送信する。また、例えば、各デバイス機器は、各ＧＷ１１〜１２によるスイッチ制御に従って、搭載するスイッチのオンとオフを切り替える。
【００１８】
各ＧＷ１１〜１２は、配下に１または複数のデバイス機器を収容し、ネットワークを介して他のコンポーネント（例えば、他のＧＷ、ストレージ２１〜２２、アプリケーション３１〜３２）やレジストリ４０と通信する。また、各ＧＷ１１〜１２は、配下に管理するデバイス機器の情報を管理、記憶する。
また、各ＧＷ１１〜１２は、レジストリ４０に対してコンポーネントの情報の登録、ポイントの情報の登録や、通信対象のコンポーネント、通信対象のポイントなどの検索を行う。また、各ＧＷ１１〜１２が何らかの要求に対して応答するレスポンダー（Ｒｅｓｐｏｎｄｅｒ）となる場合には、アクセス制御規則（ＡＣＬ：Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ  Ｌｉｓｔ）をレジストリ４０（またはリソースアクセス制御装置５０）から取得し、さらに通信対象のコンポーネントのコンポーネント情報、通信対象のポイントのポイント情報を取得する。
【００１９】
各ストレージ２１〜２２は、各ＧＷ１１〜１２の配下に接続され、かつ各ＧＷ１１〜１２によって各デバイス機器から取得されたデータや、各アプリケーション３１〜３２によって生成または加工されたデータを記憶する。各ストレージ２１〜２２は、他のコンポーネントに対してデータを提供したり、他のコンポーネントからデータを取得したりする。各ストレージ２１〜２２は、レジストリ４０とも通信を行い、レジストリ４０に対して通信対象のコンポーネントや通信対象のポイントを検索する。また、各ストレージ２１〜２２は、アクセス制御規則をレジストリ４０（またはリソースアクセス制御装置５０）から取得する。
【００２０】
各アプリケーション３１〜３２は、例えば、各ＧＷ１１〜１２や各ストレージ２１〜２２からデータを取得し、取得したデータを表示する。また、各アプリケーション３１〜３２は、例えば、取得したデータを加工して他のコンポーネントに提供する。また、各アプリケーション３１〜３２は、例えば、各ＧＷ１１〜１２の配下のデバイス機器に対して制御の命令を行う。また、各アプリケーション３１〜３２は、レジストリ４０と通信を行い、レジストリ４０に対して通信対象のコンポーネントや通信対象のポイントを検索する。また、各アプリケーション３１〜３２は、アクセス制御規則をレジストリ４０(またはリソースアクセス制御装置５０)から取得する。
【００２１】
レジストリ４０は、各種コンポーネントのコンポーネント情報と各種ポイントのポイント情報とを一元管理して提供することが可能なディクショナリ機能として機能する機構である。例えば、レジストリ４０は、リソース情報（例えば、各種コンポーネントの情報と各種ポイントの情報と）を一元管理する。ここで、リソース情報は、通信システム１を構成し、稼動させるためのハードウェアに関する情報や、ソフトウェアに関する情報である。レジストリ４０は、記憶している各種コンポーネントの情報と各種ポイントの情報とをリソースアクセス制御装置５０に送信する。レジストリ４０は、コンポーネント情報だけでなく、コンポーネントの配下で管理されているポイント情報も管理する。コンポーネント情報は、例えばコンポーネントのそのものの情報と当該コンポーネントが管理するポイント情報である。ポイント情報は、ポイントそのものの属性情報（場所、センサの種別など）である。
【００２２】
具体的には、例えばレジストリ４０は、コンポーネントを識別するコンポーネント識別情報と該コンポーネントに属するポイントを識別するポイント識別情報との対応関係が記憶されている記憶部を備える。これにより、コンポーネントとポイントの所属関係を管理することができる。レジストリ４０で管理されている情報は、各種コンポーネントから専用のインターフェースを用いて登録、更新および削除などが可能である。
【００２３】
リソースアクセス制御装置（ＲＡＭ：Ｒｅｓｏｕｒｃｅ  Ａｃｃｅｓｓ  Ｍａｎａｇｅｒ）５０は、アクセス制御規則を管理して配布する機構である。具体的には、リソースアクセス制御装置５０は、アクセス制御規則を生成して、生成したアクセス制御規則を管理・記憶し、管理・記憶するアクセス制御規則を配布する。なお、リソースアクセス制御装置５０は、生成したアクセス制御規則をレジストリ４０に記憶させてもよい。なお、リソースアクセス制御装置５０は、セキュリティのポリシー情報を事前に記憶し、システムの構成が変更された場合やポリシー情報が変更された場合に、随時、当該リソースアクセス制御装置５０を起動することでＡＣＬを更新してもよい。
【００２４】
各ＡＣＭ（アクセス制御装置）６０、７０は、アクセス制御を行う。具体的には、例えば、各ＡＣＭ６０、７０はコンポーネントレベルの認証（ＩＥＥＥ１８８８．３の規定の中ではＡＭ（Ａｃｃｅｓｓ  Ｍａｎａｇｅｒ）とも呼ばれる）と、コンポーネントレベルのアクセス制御と、ポイントのアクセス制御と、手順レベルやメソッドレベルのアクセス制御などを実行する。各ＡＣＭ６０、７０は、主としてレスポンダーとなるコンポーネント（コンポーネントレベルの認証の場合にはレスポンダー、イニシエータの両方）や、レジストリ４０が使用する。各ＡＣＭ６０、７０の運用形態は、２つ存在し、コンポーネントやレジストリ４０などがそれぞれ各ＡＣＭ６０、７０を実装して運用する運用形態と、通信システム１内に各ＡＣＭ６０、７０が存在し、当該各ＡＣＭ６０、７０に各コンポーネントやレジストリ４０が問い合わせを行うことで運用する運用形態と、がある。
【００２５】
本実施形態では、コンポーネントやレジストリ４０などがそれぞれ、各ＡＣＭ６０、７０を実装する場合には、コンポーネントの各ＡＣＭ６０、７０が用いるアクセス制御規則をリソースアクセス制御装置５０から取得する。一方、通信システム１内に各ＡＣＭ６０、７０が存在し、当該各ＡＣＭ６０、７０に各コンポーネントやレジストリ４０が問い合わせを行うことで運用する場合には、コンポーネントがリソースアクセス制御装置５０に特定のアクセス制御規則を問い合わせるため、リソースアクセス制御装置５０がＡＣＭのように振る舞ってもよい。
【００２６】
次いで、本実施形態に係るアクセス制御規則に含まれるアクセス制御ルールの記述形式の一例について説明する。当該記述形式は、レジストリ４０が管理しているポイント情報の登録および検索を行うマークアップ言語（ＸＭＬ：Ｅｘｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）に従う。
例えば、アクセス制御ルールの記述が以下に示す場合について説明する。
＜ｐｏｉｎｔ  ｉｄ  ＝“ｈｔｔｐ：／／｛ｍｅｔａ｝／｛ｒｅｓｐｏｎｄｅｒ｝／｛ｉｎｉｔｉａｔｏｒ｝／｛ｍｅｔｈｏｄ｝／｛ｐｏｉｎｔ｝”    ｐｏｉｎｔ  ＝“｛ｐｏｉｎｔ｝”    ｒｅｓｐｏｎｄｅｒ  ＝“｛ｒｅｓｐｏｎｄｅｒ｝”    Ｉｎｉｔｉａｔｏｒ＝  “｛Ｉｎｉｔｉａｔｏｒ｝”    ｐｏｌｉｃｙ  ＝“｛ｐｏｌｉｃｙ｝”    ｍｅｔｈｏｄ  ＝“｛ｍｅｔｈｏｄ｝”  ／＞
【００２７】
まず、アクセス制御ルールの記述のうち領域｛ｍｅｔａ｝について説明する。
この領域は、コンポーネントが管理するデータであるポイントのポイント情報を記述する領域である。当該領域は、ｐｏｉｎｔ情報がアクセス制御規則の記述形式であることを表す。特に、レジストリ４０においてポイント情報とアクセス制御規則の情報とをまとめて管理している場合、当該領域｛ｍｅｔａ｝において、レジストリ４０および通信するコンポーネントがその情報がポイント情報かアクセス制御規則の情報かを区別することができることが望ましい。これを簡易に実現するには、アクセス制御規則の情報であることを表すような記述をｉｄ内に記述すればよい。なお、レジストリ４０とリソースアクセス制御装置５０が独立して運用される場合などではこの記述を用いなくてもよい。
【００２８】
次いで、アクセス制御ルールの記述のうち領域｛ｒｅｓｐｏｎｄｅｒ｝について説明する。当該領域は、レスポンダーの識別情報を記述する領域である。レスポンダーの識別情報とは、例えば、レスポンダーのコンポーネントＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｅｒ）またはレスポンダーの識別情報（ＩＥＥＥ１８８８．３のコンポーネント識別で用いられる証明書内のＳＡＮ（Ｓｕｂｊｅｃｔ  Ａｌｔｅｒｎａｔｉｖｅ  Ｎａｍｅ）など）である。
【００２９】
次いで、アクセス制御ルールの記述のうち領域｛ｉｎｉｔｉａｔｏｒ｝について説明する。当該領域は、イニシエータの識別情報を記述する領域である。イニシエータについては、コンポーネントＵＲＩを持たない場合も多い。このため、イニシエータの識別情報ＳＡＮを用いることが好ましい。
【００３０】
次いで、アクセス制御ルールの記述のうち領域｛ｐｏｉｎｔ｝について説明する。当該領域｛ｐｏｉｎｔ｝は、コンポーネントが管理するポイントのＩＤ（識別情報：Ｉｄｅｎｔｉｆｅｒ）（ポイントレベルでのアクセスコントロール時のアクセスコントロールの対象となるポイント）記述する領域である。また、すべてのポイントに共通のアクセス制御規則を設定する場合には、当該領域にワイルドカード「＊」といった記述を用いてもよい。
【００３１】
次いで、アクセス制御ルールの記述のうち領域｛ｐｏｌｉｃｙ｝について説明する。当該領域は、アクセス可否を表すアクセス可否情報を記述する領域である。具体的には、当該領域には、ＯＫ、ＮＧ、またはａｌｌｏｗ、ｄｅｎｙなどが記述される。例えば、ＯＫ、ａｌｌｏｗは、アクセスを許可することを表し、ＮＧ、ｄｅｎｙは、アクセスを許可しないことを表す。なお、アクセス制御規則において、アクセスを許可することを表すアクセス可の情報しか扱わない、またはアクセスを許可しないことを表すアクセス否の情報しか扱わないといった運用をする場合には、この記述はなくてもよい。
【００３２】
次いで、アクセス制御ルールの記述のうち領域｛ｍｅｔｈｏｄ｝について説明する。当該領域は、手順またはメソッドレベルでのアクセス制御を実現する場合に用いる領域である。具体的には、手順はＦＥＴＣＨ、ＷＲＩＴＥ、ＴＲＡＰなどであり、メソッドレベルでのアクセス制御は、ｑｕｅｒｙ、ｄａｔａなどである。なお、手順またはメソッドレベルでのアクセス制御を行わない場合、当該領域は不要である。
【００３３】
次に、アクセス制御ルールの記述におけるＸＭＬ形式の記述について説明する。
ｉｄ属性の記述形式については、以下に示す形式が必須ではなく、一例として説明する。例えば、アクセス制御ルールの記述が上述のように「ｐｏｉｎｔ  ｉｄ  ＝“ｈｔｔｐ：／／｛ｍｅｔａ｝／｛ｒｅｓｐｏｎｄｅｒ｝／｛Ｉｎｉｔｉａｔｏｒ｝／｛ｍｅｔｈｏｄ｝／｛ｐｏｉｎｔ｝”」である場合、当該記述が「ｐｏｉｎｔ  ｉｄ  ＝“ｈｔｔｐ：／／｛ｍｅｔａ｝／｛Ｉｎｉｔｉａｔｏｒ｝／｛ｍｅｔｈｏｄ｝／｛ｐｏｉｎｔ｝／｛ｒｅｓｐｏｎｄｅｒ｝”」のように、記載順序が変わってもよい。ｉｄ属性の記述形式で必須の条件は、以下の通りである。
（１）異なるアクセス制御規則（例えば、あるレスポンダーの特定のポイントに対するアクセス制御規則についてイニシエータがＡのものとＢのものとが存在するときなど）は異なるｉｄになること。
（２）同じアクセス制御規則（例えばポイントレベルまでのアクセス制御規則を記述しているのであれば、あるレスポンダーの特定のポイントに対して特定のイニシエータからのアクセスに関するアクセス制御規則）は同じｉｄになること。
【００３４】
上記２つのｉｄ属性の記述形式で必須の条件は、レジストリ４０のポイント情報がｉｄを主キーとしているためである。そのためこれらの条件を満たすことで、以下のことが可能となる。
（１）管理したいアクセス制御規則を漏れなくレジストリで管理すること（異なるアクセス制御規則を上書きしない）。
（２）アクセス制御規則が更新される場合などに、適切にアクセス制御規則を更新すること（アクセス制御規則が変更された場合に、そのアクセス制御規則を上書きできる）。
【００３５】
また、アクセス制御ルールの記述におけるＸＭＬ形式の記述について、システム内で必要とするアクセス制御規則の粒度に従って、アクセス制御規則の記述形式は書き換えてよい。例えば、メソッド単位のアクセス制御を行わない場合には、ｍｅｔｈｏｄ属性およびｉｄの｛ｍｅｔｈｏｄ｝部分は省略してもよい。逆に、時間ごとのアクセス制御まで必要とする場合は、随時、属性に「ｔｉｍｅ＝“｛ｔｉｍｅ｝”」のような属性を追記し、ｉｄもそれにあわせて、例えば、「ｉｄ＝“ｈｔｔｐ：／／｛ｍｅｔａ｝／｛Ｉｎｉｔｉａｔｏｒ｝／｛ｍｅｔｈｏｄ｝／｛ｐｏｉｎｔ｝／｛ｒｅｓｐｏｎｄｅｒ｝／｛ｔｉｍｅ｝”」といった属性を追加してもよい。
【００３６】
また、アクセス制御ルールの記述におけるＸＭＬ形式の記述について、アクセス制御規則で記述される属性は、アクセス制御規則ではないポイント情報と異なる名前（名前空間）であることが望ましい。例えば、システム構築段階で単なる（アクセス制御規則ではない）ポイント情報でも「Ｉｎｉｔｉａｔｏｒ」属性を登録または検索する可能性がある場合は、アクセス制御規則では異なる属性名もしくは名前空間を使用する。これは、ポイントの検索時（アクセス制御規則の検索時）にアクセス制御規則の情報（ポイント情報）が応答されないようにするためである。
【００３７】
また、レジストリ４０がポイント情報の削除機能を持っていない場合も想定される。この場合には、アクセス制御規則が不要になった場合でも、一旦登録されたアクセス制御規則をレジストリ４０から削除することが困難になる。このような場合は、以下のようなデータモデルを用いることで対応することが可能である。
＜ｐｏｉｎｔ  ｉｄ  ＝“ｈｔｔｐ：／／｛ｍｅｔａ｝／｛ｒｅｓｐｏｎｄｅｒ｝／｛Ｉｎｉｔｉａｔｏｒ｝／｛ｍｅｔｈｏｄ｝／｛ｐｏｉｎｔ｝”    ｐｏｉｎｔ  ＝“｛ｐｏｉｎｔ｝”    ｒｅｓｐｏｎｄｅｒ  ＝“｛ｒｅｓｐｏｎｄｅｒ｝”    Ｉｎｉｔｉａｔｏｒ  ＝“｛Ｉｎｉｔｉａｔｏｒ｝”    ｐｏｌｉｃｙ  ＝“｛ｐｏｌｉｃｙ｝”    ｍｅｔｈｏｄ  ＝“｛ｍｅｔｈｏｄ｝”    ｖａｌｉｄ＝“｛ｖａｌｉｄ｝”／＞
ここで、ｖａｌｉｄには、“ｔｒｕｅ”または“ｆａｌｓｅ”が記述される。
【００３８】
この記述例を用いて運用する場合、アクセス制御規則が不要になった場合には、ｖａｌｉｄ＝“ｆａｌｓｅ”と記述して登録する（有効であれば“ｔｒｕｅ”と記述する）。この場合、アクセス制御規則を取得するコンポーネントは、ポイント検索の条件に「ｖａｌｉｄ＝“ｔｒｕｅ”」と記述することで、必要のないアクセス制御規則を除外して取得することができる。
このように、アクセス制御規則を記述することで、ルールが更新されて、特定のアクセス制御規則が存在しなくなった場合でもそれを識別することが可能である。また、レジストリ４０側もその情報に基づいて、ポイント情報を削除することも可能になる。
【００３９】
具体例として、図２、３に示す通信システムとその運用ルールが定義されている場合におけるアクセス制御規則の記述の一例を以下に示す。
図２は、本実施形態に係る通信システムの一例を示す概略図である。また、図３は、図２に示す通信システムの運用ルールの定義の一例を示す概略図である。
図２に図示する例では、テーブルＴ１は、レスポンダー（ｒｅｓｐｏｎｄｅｒ）、イニシエータ（ｉｎｉｔｉａｔｏｒ）、ポリシー（Ｐｏｌｉｃｙ）、ポイント（ｐｏｉｎｔ）の各項目列を有する。
テーブルＴ１では、レスポンダーと、それに対応する各イニシエータと、アクセス可否情報とポイント情報とが対応付けられている。
図３に図示する例では、リソースアクセス制御装置５０は、レジストリ４０と、アプリケーション３１、３２と、ＧＷ１１と、ストレージ２１と、通信する。ＧＷ１１は、配下に第１ポイントと第２ポイントとが接続され、これらのポイントと通信する。ストレージ２１は、第１ポイントと第３ポイントとが接続され、これらのポイントと通信する一例である。
【００４０】
＜ｐｏｉｎｔ  ｉｄ  ＝“ｈｔｔｐ:／／．ＡＣＬ／Ｓｔｏｒａｇｅ／ＡＰＰ１／Ａ”  ｐｏｉｎｔ＝“Ａ”    ｒｅｓｐｏｎｄｅｒ  ＝“Ｓｔｏｒａｇｅ”    Ｉｎｉｔｉａｔｏｒ  ＝“ＡＰＰ１”    ｐｏｌｉｃｙ  ＝“ＯＫ”    ｖａｌｉｄ  ＝“ｔｒｕｅ”／＞
＜ｐｏｉｎｔ  ｉｄ  ＝“ｈｔｔｐ：／／．ＡＣＬ／Ｓｔｏｒａｇｅ／ＡＰＰ１／Ｃ”    ｐｏｉｎｔ  ＝“Ｃ”    ｒｅｓｐｏｎｄｅｒ    ＝“Ｓｔｏｒａｇｅ”    Ｉｎｉｔｉａｔｏｒ  ＝“ＡＰＰ１”    ｐｏｌｉｃｙ  =“ＯＫ”    ｖａｌｉｄ  =“ｔｒｕｅ”／＞
＜ｐｏｉｎｔ  ｉｄ  ＝“ｈｔｔｐ：／／．ＡＣＬ／Ｓｔｏｒａｇｅ／ＡＰＰ２／Ａ”    ｐｏｉｎｔ  ＝“Ａ”    ｒｅｓｐｏｎｄｅｒ  ＝“Ｓｔｏｒａｇｅ”    Ｉｎｉｔｉａｔｏｒ  =“ＡＰＰ２”    ｐｏｌｉｃｙ  ＝“ＯＫ”    ｖａｌｉｄ  ＝“ｔｒｕｅ”  ／＞
＜ｐｏｉｎｔ  ｉｄ  ＝“ｈｔｔｐ：／／．ＡＣＬ／Ｓｔｏｒａｇｅ／ＡＰＰ２／Ｃ”    ｐｏｉｎｔ  ＝“Ｃ”    ｒｅｓｐｏｎｄｅｒ  ＝“Ｓｔｏｒａｇｅ”    Ｉｎｉｔｉａｔｏｒ  ＝“ＡＰＰ２”    ｐｏｌｉｃｙ  ＝“ＮＧ”    ｖａｌｉｄ  ＝“ｔｒｕｅ”  ／＞
＜ｐｏｉｎｔ  ｉｄ  ＝“ｈｔｔｐ：／／．ＡＣＬ／ＧＷ／ＡＰＰ１／Ａ”    ｐｏｉｎｔ  ＝“Ａ”    ｒｅｓｐｏｎｄｅｒ  ＝“ＧＷ”    Ｉｎｉｔｉａｔｏｒ  ＝“ＡＰＰ１”    ｐｏｌｉｃｙ  ＝“ＯＫ”    ｖａｌｉｄ  ＝“ｔｒｕｅ”／＞
＜ｐｏｉｎｔ  ｉｄ  ＝“ｈｔｔｐ：／／．ＡＣＬ／ＧＷ／ＡＰＰ１／Ｂ”    ｐｏｉｎｔ  ＝“Ｂ”    ｒｅｓｐｏｎｄｅｒ  ＝“ＧＷ”    ｉｎｉｔｉａｔｏｒ  ＝“ＡＰＰ１”    ｐｏｌｉｃｙ  ＝“ＮＧ”    ｖａｌｉｄ  ＝“ｔｒｕｅ”／＞
＜ｐｏｉｎｔ  ｉｄ  ＝“ｈｔｔｐ：／／．ＡＣＬ／ＧＷ／ＡＰＰ２／Ａ”    ｐｏｉｎｔ  ＝“Ａ”    ｒｅｓｐｏｎｄｅｒ  ＝“ＧＷ”    Ｉｎｉｔｉａｔｏｒ  ＝“ＡＰＰ２”    ｐｏｌｉｃｙ  ＝“ＯＫ”    ｖａｌｉｄ  ＝“ｔｒｕｅ”／＞
＜ｐｏｉｎｔ  ｉｄ  ＝“ｈｔｔｐ：／／．ＡＣＬ／ＧＷ／ＡＰＰ２／Ｂ”    ｐｏｉｎｔ  ＝“Ｂ”    ｒｅｓｐｏｎｄｅｒ  ＝“ＧＷ”    Ｉｎｉｔｉａｔｏｒ  ＝“ＡＰＰ２”    ｐｏｌｉｃｙ  ＝“ＮＧ”    ｖａｌｉｄ  ＝“ｔｒｕｅ”／＞
【００４１】
上記アクセス制御規則をレジストリ４０に登録する場合は、ＩＥＥＥ１８８８で標準化されているレジストリ４０のインターフェースを用いることが可能である。以下、レジストレーション手順（ＲＥＧＩＳＴＲＡＴＩＯＮ手順）を用いてレジストリ４０に登録する場合に、送信すべき電文の一例を示す。なお、ここでは名前空間（ｎａｍｅｓｐａｃｅ）の記述などは省略する。
【００４２】
＜ｔｒａｎｓｐｏｒｔ＞
＜ｂｏｄｙ＞
＜ｐｏｉｎｔ  ｉｄ  ＝“ｈｔｔｐ：／／．ＡＣＬ／Ｓｔｏｒａｇｅ／ＡＰＰ１／Ａ”    ｐｏｉｎｔ  ＝“Ａ”    ｒｅｓｐｏｎｄｅｒ  ＝“Ｓｔｏｒａｇｅ”    Ｉｎｉｔｉａｔｏｒ  ＝“ＡＰＰ１”    ｐｏｌｉｃｙ  ＝“ＯＫ”    ｖａｌｉｄ  ＝“ｔｒｕｅ”  ／＞
＜ｐｏｉｎｔ  ｉｄ  ＝“ｈｔｔｐ：／／．ＡＣＬ／Ｓｔｏｒａｇｅ／ＡＰＰ１／Ｃ”    ｐｏｉｎｔ  ＝“Ｃ”    ｒｅｓｐｏｎｄｅｒ  ＝“Ｓｔｏｒａｇｅ”    Ｉｎｉｔｉａｔｏｒ  ＝“ＡＰＰ１”    ｐｏｌｉｃｙ  ＝“ＯＫ”    ｖａｌｉｄ  ＝“ｔｒｕｅ”  ／＞
＜ｐｏｉｎｔ  ｉｄ  ＝“ｈｔｔｐ：／／．ＡＣＬ／Ｓｔｏｒａｇｅ／ＡＰＰ２／Ａ”    ｐｏｉｎｔ  ＝“Ａ”    ｒｅｓｐｏｎｄｅｒ  ＝“Ｓｔｏｒａｇｅ”    Ｉｎｉｔｉａｔｏｒ  ＝“ＡＰＰ２”    ｐｏｌｉｃｙ  ＝“ＯＫ”    ｖａｌｉｄ  ＝“ｔｒｕｅ”  ／＞
＜ｐｏｉｎｔ  ｉｄ  ＝“ｈｔｔｐ：／／．ＡＣＬ／Ｓｔｏｒａｇｅ／ＡＰＰ２／Ｃ”    ｐｏｉｎｔ  ＝“Ｃ”    ｒｅｓｐｏｎｄｅｒ  ＝“Ｓｔｏｒａｇｅ”    Ｉｎｉｔｉａｔｏｒ  ＝“ＡＰＰ２”    ｐｏｌｉｃｙ  ＝“ＮＧ”    ｖａｌｉｄ  ＝“ｔｒｕｅ”  ／＞
＜ｐｏｉｎｔ  ｉｄ  ＝“ｈｔｔｐ：／／．ＡＣＬ／ＧＷ／ＡＰＰ１／Ａ”    ｐｏｉｎｔ  ＝“Ａ”    ｒｅｓｐｏｎｄｅｒ  ＝“ＧＷ”    Ｉｎｉｔｉａｔｏｒ  ＝“ＡＰＰ１”    ｐｏｌｉｃｙ  ＝“ＯＫ”    ｖａｌｉｄ  ＝“ｔｒｕｅ＞
＜ｐｏｉｎｔ  ｉｄ  ＝“ｈｔｔｐ：／／．ＡＣＬ／ＧＷ／ＡＰＰ１／Ｂ”    ｐｏｉｎｔ  ＝“Ｂ”    ｒｅｓｐｏｎｄｅｒ  ＝“ＧＷ”    Ｉｎｉｔｉａｔｏｒ  ＝“ＡＰＰ１”    ｐｏｌｉｃｙ  ＝“ＮＧ”    ｖａｌｉｄ  ＝“ｔｒｕｅ”＞
＜ｐｏｉｎｔ  ｉｄ  ＝“ｈｔｔｐ：／／．ＡＣＬ／ＧＷ／ＡＰＰ２／Ａ”    ｐｏｉｎｔ  ＝“Ａ”    ｒｅｓｐｏｎｄｅｒ  ＝“ＧＷ”    Ｉｎｉｔｉａｔｏｒ  ＝“ＡＰＰ２”    ｐｏｌｉｃｙ  ＝“ＯＫ”    ｖａｌｉｄ  ＝“ｔｒｕｅ”＞
＜ｐｏｉｎｔ  ｉｄ  ＝“ｈｔｔｐ：／／．ＡＣＬ／ＧＷ／ＡＰＰ２／Ｂ”    ｐｏｉｎｔ  ＝“Ｂ”    ｒｅｓｐｏｎｄｅｒ  ＝“ＧＷ”    Ｉｎｉｔｉａｔｏｒ  ＝“ＡＰＰ２”    ｐｏｌｉｃｙ  ＝“ＮＧ”    ｖａｌｉｄ  ＝“ｔｒｕｅ”＞
＜／ｂｏｄｙ＞
＜／ｔｒａｎｓｐｏｒｔ＞
【００４３】
上記電文は、さらに、記述のグループ化により、電文量（アクセス制御規則の管理量）を削減することが可能である。ここでは、イニシエータのグループ化の記述と、複数のアクセス制御規則をまとめた記述について述べる。グループについては前述したアクセス制御規則の情報を補足するものとして活用する。
これらの記述についても、特定の記述形式としての制限はないが、別のグループ情報やアクセス制御規則、ポイント情報、ｉｄ属性が重複しないようにする。
まず、グループ化の表記方法としてイニシエータのグループ化記述の一例を説明する。これは、大量のイニシエータが存在し、かつそれらが共通のアクセスポリシーを持つ場合などに有効である。
【００４４】
イニシエータのグループを記述するには以下のような情報をpoint 情報として登録する。
（１）
記述例
＜ｐｏｉｎｔ  ｉｄ  ＝“ｈｔｔｐ：／／．ＡＣＬ／ｇｒｏｕｐ／｛ｇｒｏｕｐ｝”    ｇｒｏｕｐ  ＝“｛ｇｒｏｕｐ｝”    Ｉｎｉｔｉａｔｏｒ  ＝“｛Ｉｎｉｔｉａｔｏｒ｝”＞
具体例
＜ｐｏｉｎｔ  ｉｄ  ＝“ｈｔｔｐ：／／．ＡＣＬ／ｇｒｏｕｐ／ｉｎｉｔｉａｔｏｒＡ”    ｇｒｏｕｐ  ＝“ＧｒｏｕｐＡ”    Ｉｎｉｔｉａｔｏｒ  ＝“ｉｎｉｔｉａｔｏｒＡ”＞
＜ｐｏｉｎｔ  ｉｄ  ＝“ｈｔｔｐ：／／．ＡＣＬ／ｇｒｏｕｐ／ｉｎｉｔｉａｔｏｒＢ”    ｇｒｏｕｐ  ＝“ＧｒｏｕｐＡ”    Ｉｎｉｔｉａｔｏｒ  ＝“ｉｎｉｔｉａｔｏｒＢ”＞
【００４５】
（２）
記述例
＜ｐｏｉｎｔ  ｉｄ  ＝“ｈｔｔｐ：／／．ＡＣＬ／ｇｒｏｕｐ／｛ｇｒｏｕｐ｝”  ｉｎｉｔｉａｔｏｒｎｕｍ＝“｛ｎｕｍ｝”  ｉｎｔｉａｔｏｒ｛ｎ｝＝“｛Ｉｎｉｔｉａｔｏｒ｝”（ｎ個分記述）＞
具体例
＜ｐｏｉｎｔ  ｉｄ  ＝“ｈｔｔｐ：／／．ＡＣＬ／ｇｒｏｕｐ／ｇｒｏｕｐＡ”    ｉｎｉｔｉａｔｏｒｎｕｍ  ＝“２”    ｉｎｔｉａｔｏｒ０  ＝“ｉｎｉｔｉａｔｏｒＡ”    ｉｎｔｉａｔｏｒ１  ＝“ｉｎｉｔｉａｔｏｒＢ”＞
【００４６】
これらの記述は、（１）、（２）のどちらでも「ｉｎｉｔｉａｔｏｒＡ」 と「ｉｎｉｔｉａｔｏｒＢ」とを同じグループとして表現している。このとき、アクセス制御規則の記述は、以下のようになる。
＜ｐｏｉｎｔ  ｉｄ  ＝“ｈｔｔｐ：／／．ＡＣＬ／ＧＷ／ｇｒｏｕｐＡ／Ｂ”    ｐｏｉｎｔ  ＝“Ｂ”    ｒｅｓｐｏｎｄｅｒ  ＝“ＧＷ”    Ｉｎｉｔｉａｔｏｒ  ＝“ｇｒｏｕｐＡ”    ｐｏｌｉｃｙ  ＝“ＮＧ”    ｖａｌｉｄ  ＝“ｔｒｕｅ”＞
【００４７】
これらの情報は、（１）、（２）のどちらでもレジストリ４０のポイント情報として管理される。レスポンダーは、必要に応じてその情報を検索する。
この情報は、リソースアクセス制御装置５０から登録される。この場合、レスポンダーは、アクセス制御規則だけでなく、グループの情報もレジストリ４０（またはリソースアクセス制御装置５０）に対して問い合わせる必要がある。
次に複数のアクセス制御規則をまとめて記述し、情報量を削減する場合の記述について説明する。具体例として、複数のポイントをまとめてアクセス制御規則として記述する一例について説明する。
【００４８】
＜ｐｏｉｎｔ  ｉｄ  ＝“ｈｔｔｐ：／／．ＡＣＬ／ｒｅｓｐｏｎｄｅｒＡ／ｉｎｉｔｉａｔｏｒＡ／ＰｏｉｎｔＡ／ｐｏｉｎｔＢ”    Ｉｎｉｔｉａｔｏｒ  ＝“ｉｎｉｔｉａｔｏｒＡ”    ｒｅｓｐｏｎｄｅｒ  ＝“ｒｅｓｐｏｎｄｅｒＡ”    ｍｅｔｈｏｄ  ＝“ＦＥＴＣＨ”    ｐｏｌｉｃｙ  ＝“ＯＫ”    ｐｏｉｎｔｎｕｍ＝“２”    ｐｏｉｎｔ０  ＝“ｐｏｉｎｔＡ”    ｐｏｉｎｔ１  ＝“ｐｏｉｎｔＢ”＞
【００４９】
この記述では、「ｐｏｉｎｔＡ」と「ｐｏｉｎｔＢ」についてＦＥＴＣＨメソッドで、「ｉｎｉｔｉａｔｏｒＡ」からのアクセスに対し「ｒｅｓｐｏｎｄｅｒＡ」がＯＫであることを表している。
【００５０】
また、同様に複数のメソッドをまとめて表記することなども可能である。
＜ｐｏｉｎｔ  ｉｄ  ＝“ｈｔｔｐ：／／．ＡＣＬ／Ｓｔｏｒａｇｅ／ＡＰＰ２／Ｃ”    ｐｏｉｎｔ  ＝“Ｃ”    ｒｅｓｐｏｎｄｅｒ  ＝“Ｓｔｏｒａｇｅ”    Ｉｎｉｔｉａｔｏｒ  ＝“ＡＰＰ２”    ｐｏｌｉｃｙ  ＝“ＮＧ”    ｍｅｔｈｏｄ  ＝“ＦＥＴＣＨ｜ＷＲＩＴＥ”＞
これらのＸＭＬ記述の効率化については、システム内で記述ルールを統一することで実現することが可能である。
【００５１】
図４は、本発明の実施形態に係る通信システムにおけるシーケンス図である。
ステップＳＴ１００において、レスポンダーは自装置を起動させる。
ステップＳＴ１０１において、レスポンダーは、自身のコンポーネント情報やポイント情報をレジストリ４０に登録する。
ステップＳＴ１０２において、レジストリ４０は、リソースアクセス制御装置５０にレスポンダーのコンポーネント情報やポイント情報の登録が完了したことを表す登録通知を送信する。リソースアクセス制御装置５０は、登録通知を受信すると、登録されたコンポーネント情報やポイント情報に基づいて、レスポンダーのアクセス制御規則を生成する。または、リソースアクセス制御装置５０は、予めレスポンダーに対するアクセス制御規則を生成しておく。
【００５２】
ステップＳＴ１０３において、リソースアクセス制御装置５０は、生成したアクセス制御規則を、ＲＥＧＩＳＴＲＡＴＩＯＮ手順を用いてレジストリ４０に登録する。なお、リソースアクセス制御装置５０とレジストリ４０とが同一の装置である場合には、直接追加すればよい。
ステップＳＴ１０３ａにおいて、イニシエータは自装置を起動させる。
ステップＳＴ１０４において、イニシエータは、通信相手であるレスポンダーを見つけるために、ＬＯＯＫＵＰ手順を用いてレジストリ４０を検索する。
ステップＳＴ１０５において、レジストリ４０は、応答としてコンポーネント情報やポイント情報をイニシエータに送信する。このとき、レジストリ４０の情報自体にもアクセス制御規則が設定されている場合は、通信先として許可された装置にのみ応答を送信する。この場合に、イニシエータのアクセス制御が実施されることになる。
【００５３】
ステップＳＴ１０６において、イニシエータは、ＦＥＴＣＨ／ＷＲＩＴＥ／ＴＲＡＰ手順によるデータや制御結果を取得するための問合せ（要求）をレスポンダーに対して行う。
ステップＳＴ１０７において、レスポンダーは、ＬＯＯＫＵＰ手順を用いてアクセスしてきたイニシエータがアクセス可能か否かを表すアクセス制御規則をレジストリ４０に対して問い合わせる。
【００５４】
具体的には、以下のようなＬＯＯＫＵＰ手順を用いてアクセス制御規則を問い合わせる。
（１）全てのアクセス制御規則を取得する場合（自身を「ｒｅｓｐｏｎｄｅｒＡ」とする）
＜ｔｒａｎｓｐｏｒｔ＞
＜ｈｅａｄｅｒ＞
＜ｌｏｏｋｕｐ  ｔｙｐｅ＝“ｐｏｉｎｔ” ｉｄ＝“．．．”＞
＜ｐｏｉｎｔ  ｒｅｓｐｏｎｄｅｒ=“ｒｅｓｐｏｎｄｅｒＡ”／＞
＜／ｌｏｏｋｕｐ＞
＜／ｈｅａｄｅｒ＞
＜／ｔｒａｎｓｐｏｒｔ＞
（２）特定のアクセス制御規則を取得する場合（イニシエータが「ｉｎｉｔｉａｔｏｒＡ」であり、ｐｏｉｎｔＸにアクセスしてきた場合）
＜ｔｒａｎｓｐｏｒｔ＞
＜ｈｅａｄｅｒ＞
＜ｐｏｉｎｔ  ｒｅｓｐｏｎｄｅｒ  ＝“ｒｅｓｐｏｎｄｅｒＡ”    Ｉｎｉｔｉａｔｏｒ  ＝“Ｉｎｉｔｉａｔｏｒ
＜ｐｏｉｎｔ  ｒｅｓｐｏｎｄｅｒ  ＝“ｒｅｓｐｏｎｄｅｒＡ”    Ｉｎｉｔｉａｔｏｒ  ＝“Ｉｎｉｔｉａｔｏｒａ”  ｐｏｉｎｔ  ＝“ｐｏｉｎｔＸ”  ／＞
＜／ｌｏｏｋｕｐ＞
＜／ｈｅａｄｅｒ＞
＜／ｔｒａｎｓｐｏｒｔ＞
【００５５】
ステップＳＴ１０８において、レジストリ４０は、応答としてアクセス可否情報を含むアクセス制御規則をレスポンダーに送信する。
ステップＳＴ１０９において、レスポンダーは、レジストリ４０から受信したアクセス制御規則を参照し、ステップＳＴ１０６において問い合わせを受信したＦＥＴＣＨ／ＷＲＩＴＥ／ＴＲＡＰ手順によるデータや制御結果を取得するための問合せ（要求）を送信したイニシエータがデータや制御結果に対するアクセスが許可されている場合、応答として当該問い合わせ（要求）に基づくデータや制御結果を当該イニシエータに送信する。
このように、リソースアクセス制御装置５０は、アクセス制御規則を記述して、記述したアクセス制御規則をレジストリ４０に記憶させる。なお、リソースアクセス制御装置５０は、レジストリ４０の機能を備え、リソースアクセス制御装置５０とレジストリ４０との機能を備えるようにしてもよい。
【００５６】
図５は、本発明の実施形態に係るリソースアクセス制御装置５０のハードウェア構成の一例を示すハードウェア構成図である。
リソースアクセス制御装置５０は、ＣＰＵ５０１と、記憶媒体５０２と、ドライブ部５０３と、入力部５０４と、出力部５０５と、ＲＯＭ５０６（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ：ロム）と、ＲＡＭ５０７（Ｒａｎｄｏｍ  Ａｃｃｃｅｓｓ  Ｍｅｍｏｒｙ：ラム）と、補助記憶部５０８と、通信部５０９と、を備える。
ＣＰＵ５０１と、ドライブ部５０３と、入力部５０４と、出力部５０５と、ＲＯＭ５０６と、ＲＡＭ５０７と、補助記憶部５０８と、通信部５０９とは、バスＢ（母線）を介して相互に接続される。
【００５７】
ＣＰＵ５０１は、補助記憶部５０８が記憶するプログラム、ＲＯＭ５０６およびＲＡＭ５０７が記憶する各種データを読み出して実行し、リソースアクセス制御装置５０を制御する。また、ＣＰＵ５０１は、ドライブ部５０３を介して記憶媒体５０２が記憶する各種データを読み出して実行し、リソースアクセス制御装置５０を制御する。記憶媒体５０２は、光磁気ディスク、フレキシブルディスク、フラッシュメモリなどの可搬記憶媒体であり、各種データを記憶する。ドライブ部５０３は、光ディスクドライブ、フレキシブルディスクドライブなどの記憶媒体５０２の読み出し装置である。入力部５０４は、マウス、キーボード、タッチパネルなどの入力装置である。出力部５０５は、表示部、スピーカなどの出力装置である。ＲＯＭ５０６、ＲＡＭ５０７は、各種データを一時的に記憶する。補助記憶部５０８は、ハードディスクドライブ、フラッシュメモリなどであり、上述したリソースアクセス制御装置５０の各機能部を動作させるためのプログラム、各種データを記憶する。通信部５０９は、通信インターフェースを有し、有線または無線によりネットワークＮＷに接続される。
【００５８】
このように、本実施形態によれば、データ構造は、通信システムの構成機器であるコンポーネントから取得されるデータであるポイントのポイント情報を記述する領域と、前記ポイントのポイント識別情報を記述する領域と、要求を送信するイニシエータのイニシエータ識別情報を記述する領域と、前記要求に対する応答をする側の装置であるレスポンダーの識別情報を記述する領域と、前記イニシエータがリソース情報管理装置へのアクセスを許可するか否かを表すアクセス可否情報を記述する領域と、を含む。
【００５９】
これにより、アクセス制御規則の記述量を削減することができ、当該記述を通信する通信量を削減することができる。また、１度の問合せで必要なアクセス制御規則を取得することができる。
さらに、本実施形態では、ＩＥＥＥ１８８８で規定されているレジストリとそのインターフェースを用いてアクセス制御規則を管理するため、ＩＥＥＥ１８８８で規定されているレジストリが持つインターフェースと動作の振る舞いをそのまま活用することができる。また、アクセス制御規則を取得するレスポンダー（アクセスされる側のコンポーネント）も新たなインターフェースを設計する必要がなく、必要なアクセス制御規則を指定して取得する場合でも、レジストリが持っている検索機能をそのまま活用することができる。
【００６０】
また、レスポンダーがアクセス制御規則を検索する際は、取得したいアクセス制御規則を「指定したポイント」や「指定したイニシエータ（アクセスする側のコンポーネント）」などの組み合わせで検索することが可能であるため、既存の方式（存在するイニシエータの数やポイントの数などを事前に問い合わせる必要があるため、結果として複数回の問い合わせが必要となる）と比べて、１回の問い合わせでアクセス制御規則を取得することができるため、問い合わせ途中に発生した更新によって整合性が保てなくなるといった事例も発生しない。また、本実施形態では、記述されるアクセス制御規則の電文形式は存在するイニシエータの数やポイントの数などといった情報をアクセス制御規則の中に記述する必要がなくなるため、アクセス制御規則の電文量自体を削減することができる。
【００６１】
なお、本発明の各実施形態のリソースアクセス制御装置５０の各処理を実行するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、当該記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより、リソースアクセス制御装置５０に係る上述した種々の処理を行ってもよい。
【００６２】
なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものであってもよい。また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、フラッシュメモリ等の書き込み可能な不揮発性メモリ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。
【００６３】
さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（例えばＤＲＡＭ（Ｄｙｎａｍｉｃ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ））のように、一定時間プログラムを保持しているものも含むものとする。また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。また、上記プログラムは、前述した機能の一部を実現するためのものであっても良い。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であっても良い。
【００６４】
以上、本発明の実施形態について図面を参照して詳述したが、具体的な構成はこの実施形態に限られるものではない。各実施形態における各構成およびそれらの組み合わせ等は一例であり、本発明の趣旨から逸脱しない範囲内で、構成の付加、省略、置換、およびその他の変更が可能である。また、本発明は実施形態によって限定されることはなく、特許請求の範囲によってのみ限定される。
【符号の説明】
【００６５】
１・・・通信システム、１１、１２・・・ゲートウェイ（ＧＷ）、２１、２２・・・ストレージ、３１、３２・・・アプリケーション、４０・・・レジストリ（リソース情報管理装置）、５０・・・リソースアクセス制御装置（ＲＡＭ）、５０１・・・ＣＰＵ、５０２・・・記憶媒体、５０３・・・ドライブ部、５０４・・・入力部、５０５・・・出力部、５０６・・・ＲＯＭ、５０７・・・ＲＡＭ、５０８・・・補助記憶部、５０９・・・通信部、６０、７０・・・ＡＣＭ（アクセス制御装置）、１１１、１２１、１２２・・・センサ、１１２・・・アクチュエータ
【図１】
2015099572.tif 000003
【図２】
2015099572.tif 000004
【図３】
2015099572.tif 000005
【図４】
2015099572.tif 000006
【図５】
2015099572.tif 000007