(57)【要約】【課題】柔軟性・拡張性の優れた情報共有システムを構築すること。【解決手段】インデックスサーバと複数のノードとがネットワークを介して相互に接続され、前記インデックスサーバには、ノードが提供するコンテンツの属性データがそのコンテンツを共有するグループ毎に任意に定義されて格納されていることを特徴とするもの。【選択図】                    図１
2004265273.tif 000002
【特許請求の範囲】
【請求項１】
インデックスサーバと複数のノードとがネットワークを介して相互に接続され、
前記インデックスサーバには、ノードが提供するコンテンツの属性データがそのコンテンツを共有するグループ毎に任意に定義されて格納されていることを特徴とする情報共有システム。
【請求項２】
各ノードは、提供するコンテンツの属性データを各グループ毎の定義に基づきインデックスサーバに書き込むことを特徴とする請求項１記載の情報共有システム。
【請求項３】
各ノードは、インデックスサーバに格納されている属性データを検索し、その検索結果に基づき所定のノードから所望のコンテンツを取り込むことを特徴とする請求項１または請求項２記載の情報共有システム。
【請求項４】
各ノードが提供するコンテンツは、静的なデータであることを特徴とする請求項１から請求項３のいずれかに記載の情報共有システム。
【請求項５】
各ノードが提供する静的なデータにより、データベースシステムを構成することを特徴とする請求項４に記載の情報共有システム。
【請求項６】
各ノードが提供するコンテンツは、アプリケーションの処理に基づく動的なデータであることを特徴とする請求項１から請求項３のいずれかに記載の情報共有システム。
【請求項７】
各ノードが提供する動的なデータにより、サービスシステムを構成することを特徴とする請求項６に記載の情報共有システム。
【請求項８】
インデックスサーバに格納されるコンテンツの属性に対して少なくとも有効期限と接続セッションのいずれかのライフサイクルを設定することを特徴とする請求項１に記載の情報共有システム。
【請求項９】
インデックスサーバにノード間のメッセージ仲介機能を設けることを特徴とする請求項１に記載の情報共有システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、情報共有システムに関するものであり、詳しくは、自由度が高く柔軟性に富む情報共有システムの改善に関する。
【０００２】
【従来の技術】
図６は、従来の情報共有システム例を示すブロック図である。図６において、ノードＮＤ１〜ＮＤ４は互いに情報（コンテンツ）を共有する情報共有グループＧＰを形成するものであり、ネットワークＮＷを介してデータベースサーバＤＢＳＶＲに接続されている。
【０００３】
ノードＮＤ１〜ＮＤ４はコンテンツをデータベースサーバＤＢＳＶＲにアップロードするとともに、データベースサーバＤＢＳＶＲにアップロードされたこれらコンテンツを検索して条件に適合したコンテンツをダウンロードする。
【０００４】
データベースサーバＤＢＳＶＲは、ノードＮＤ１〜ＮＤ４間で共有されるコンテンツを分析し、その情報を格納するデータベース構造を決定する。ここで、データベース構造とは、コンテンツが持つ属性データとコンテンツそのものを格納する構造をいう。
【０００５】
このような概念に基づく情報共有システムとしては、例えば特許文献１のような測定データ管理システムがある。
【０００６】
【特許文献１】
特開２００２−８１７９
【０００７】
特許文献１には、データセンターと複数の測定器やユーザー端末をネットワークで相互に接続し、ユーザーが必要とするときに、必要なデータ形式で解析加工された所望の測定データが得られるようにした測定データ管理システムの構成が開示されている。
【０００８】
【発明が解決しようとする課題】
しかし、図６に示す従来の情報共有システムや特許文献１に開示されている測定データ管理システムは、アップロードされる情報の構造が固定的であるため、以下の問題が生じる。
１）情報共有グループで任意に新種のコンテンツを共有できない
２）情報共有グループで既存コンテンツの属性を新たに追加・変更できない
３）新たなコンテンツを共有する共有グループを任意に追加できない
【０００９】
従来のシステムでこれらの要求に対応するためには、追加・変更要求に応じて随時データベースの構造を変更しなければならないが、データベース構造を変更するためにはエンジニアリングコストが大きくなるという問題点がある。
【００１０】
また、従来のシステム構成では、各ノードＮＤ１〜ＮＤ４によるコンテンツ登録のためのアップロード、検索や情報取得のためのダウンロードの負荷はデータベースサーバＤＢＳＶＲに集中するため、システムのボトルネックが生じるという問題もある。
【００１１】
また、従来のシステム構成では、そのシステムが破壊されると重要なデータが消失してしまい、システムが麻痺することになる。そこで、データのバックアップに莫大な費用をかけて多重化が行われている。
【００１２】
また、共有されるコンテンツが以下のような性質を持つとき、従来技術による方法は非効率でもある。
・音楽、ストリーム、設計図面など巨大容量のもの
・情報の複製が許されるもの
・センサが取得する温度、湿度などの時系列データ
・ＷＷＷ等による情報提供等の状態に依存せずにノードが提供するサービス
【００１３】
なお、音楽コンテンツの共有に特化したＮａｐｓｔｅｒ（商標）などのシステムが公表されているが、以下のような制限がある。
・音楽コンテンツ以外の属性をノードが自由に定めることができない
・ノードが定義した属性に基づくコンテンツ検索ができない
・独立した目的を持った複数の情報共有グループが共存できない
【００１４】
本発明は、これらの問題点に着目したものであり、柔軟性・拡張性の優れた情報共有システムを構築することを目的とする。
【００１５】
【課題を解決するための手段】
上記の目的を達成する請求項１に記載の発明は、
インデックスサーバと複数のノードとがネットワークを介して相互に接続され、
前記インデックスサーバには、ノードが提供するコンテンツの属性データがそのコンテンツを共有するグループ毎に任意に定義されて格納されていることを特徴とする情報共有システムである。
【００１６】
請求項２の発明は、請求項１記載の情報共有システムにおいて、
提供するコンテンツの属性データを各グループ毎の定義に基づきインデックスサーバに書き込むことを特徴とする。
【００１７】
請求項３の発明は、請求項１または請求項２記載の情報共有システムにおいて、
各ノードは、インデックスサーバに格納されている属性データを検索し、その検索結果に基づき所定のノードから所望のコンテンツを取り込むことを特徴とする。
【００１８】
請求項４の発明は、請求項１から請求項３のいずれかに記載の情報共有システムにおいて、
各ノードが提供するコンテンツは、静的なデータであることを特徴とする。
【００１９】
請求項５の発明は、請求項４に記載の情報共有システムにおいて、
各ノードが提供する静的なデータにより、データベースシステムを構成することを特徴とする。
【００２０】
請求項６の発明は、１から請求項３のいずれかに記載の情報共有システムにおいて、
各ノードが提供するコンテンツは、アプリケーションの処理に基づく動的なデータであることを特徴とする。
【００２１】
請求項７の発明は、請求項６に記載の情報共有システムにおいて、
各ノードが提供する動的なデータにより、サービスシステムを構成することを特徴とする。
【００２２】
これらの構成において、各ノードは自由にコンテンツの属性を定義してインデックスサーバに書き込むとともに、属性に基づきコンテンツを検索する。コンテンツの取得やサービスの交換にあたっては、該当するコンテンツを有する他のノードやサービスを行うノードに直接アクセスする。
一方、インデックスサーバは、コンテンツの属性に基づいて独立した複数の情報共有グループを任意に形成する。
【００２３】
これらにより、従来のシステムのようなデータベースサーバへの負荷集中を回避でき、複数の情報共有グループは互いに副作用を与えることなくシステムとして動作するので、高度の柔軟性および拡張性が得られる。
【００２４】
そして、インデックスサーバが故障しても重要なデータはすべて各ノードに格納されているので、再起動したインデックスサーバに各ノードから再登録することにより、問題なくシステムを復旧できる。これにより、データバックアップのためのコストを従来に比べて大幅に削減できる。
【００２５】
請求項８の発明は、請求項１に記載の情報共有システムにおいて、
インデックスサーバに格納されるコンテンツの属性に対して少なくとも有効期限と接続セッションのいずれかのライフサイクルを設定することを特徴とする。
【００２６】
これにより、インデックスサーバに格納される不要な属性データを適切に削除できる。
【００２７】
請求項９の発明は、請求項１に記載の情報共有システムにおいて、
インデックスサーバにノード間のメッセージ仲介機能を設けることを特徴とする。
【００２８】
これにより、直接アクセスできないノード間でのメッセージの授受が可能になる。
【００２９】
【発明の実施の形態】
図１は本発明の実施態様の一例を示す情報共有システムのブロック図である。図１において、ノードＮＤ１〜ＮＤ１１はネットワークＮＷを介してインデックスサーバＩＤＸＳＶＲに接続されている。これらノードＮＤ１〜ＮＤ１１は適宜相互に情報（コンテンツ）を共有する情報共有グループを形成する。図１では、ノードＮＤ１〜ＮＤ４で形成されるグループＧＰＡと、ノードＮＤ４〜ＮＤ７で形成されるグループＧＰＢと、ノードＮＤ８〜ＮＤ１１で形成されるグループＧＰＣを形成する例を示している。
【００３０】
これらノードＮＤ１〜ＮＤ１１は、それぞれが格納しているコンテンツの属性を、「スコープ：属性名＝属性値」という形式で記述してインデックスサーバＩＤＸＳＶＲのインデックスデータファイルＩＤＸＦＬに登録する。ここで、スコープとは属性名の有効範囲を規定するものである。
【００３１】
このようなスコープとしては、情報共有グループ毎で異なったものを定めることができる。そして、コンテンツの属性名を定義するのにあたり、各情報共有グループは互いに他のグループとの衝突を気にすることなく、各グループ内で任意に定義することができる。すなわち、同じスコープに対して複数の「属性名＝属性値」の組み合わせが存在してもよいし、同一のコンテンツに対して複数のスコープを定めてもよい。
【００３２】
図２は図１のノードＮＤ４におけるある音楽ファイルについての属性定義例である。この例に示す音楽ファイルは、「ＧｒｏｕｐＡ．ｃｏｎｔｅｎｔ」と「ＧｒｏｕｐＢ．ｃｏｎｔｅｎｔ」と「Ｓｅｒｖｉｃｅ．ｍｕｓｉｃ」の３つのスコープとして定義されていて、各スコープにおける「属性名＝属性値」は、それぞれ以下のように定義されている。
ＧｒｏｕｐＡ．ｃｏｎｔｅｎｔ：ＩＤ＝３９８２
ＧｒｏｕｐＡ．ｃｏｎｔｅｎｔ：種類＝音楽
ＧｒｏｕｐＡ．ｃｏｎｔｅｎｔ：曲名＝“Ｙｏｕ  ａｒｅ  ｅｖｅｒｙｔｈｉｎｇ”
ＧｒｏｕｐＡ．ｃｏｎｔｅｎｔ：場所＝ｈｔｔｐ：／／１０．２３．２４．３２：８０００／ｇｅｔｍｕｓｉｃ＆ｉｄ＝３９８２
ＧｒｏｕｐＢ．ｃｏｎｔｅｎｔ：ＩＤ＝３９８２
ＧｒｏｕｐＢ．ｃｏｎｔｅｎｔ：形式＝ｍｐ３ファイル
ＧｒｏｕｐＢ．ｃｏｎｔｅｎｔ：ＩＰアドレス＝１０．２３．２４．３２
ＧｒｏｕｐＢ．ｃｏｎｔｅｎｔ：場所＝／ｕｓｒ／ｃｏｎｔｅｎｔｓ／３９８２．ｍｐ３
Ｓｅｒｖｉｃｅ．ｍｕｓｉｃ：ＩＤ＝ａｂｃｄｘｙｚ３
Ｓｅｒｖｉｃｅ．ｍｕｓｉｃ：種類＝音楽サーバ
Ｓｅｒｖｉｃｅ．ｍｕｓｉｃ：サービス．音楽サーバＵＲＩ＝
ｈｔｔｐ：／／１０．２３．２４．３２：８０００／ｇｅｔｍｕｓｉｃ
Ｓｅｒｖｉｃｅ．ｍｕｓｉｃ：サービス．ファイルサーバＵＲＩ＝
ｆｔｐ：／／１０．２３．２４．３２：２５／ｐｕｂｌｉｃ／
【００３３】
このように定義されたノードＮＤ４の音楽ファイルは、「ＧｒｏｕｐＡ．ｃｏｎｔｅｎｔ」のスコープでは「曲名」などの音楽の文脈に基づいて検索され、「ＧｒｏｕｐＢ．ｃｏｎｔｅｎｔ」のスコープではファイル形式などファイルとしての文脈に基づいて検索される。すなわち、それぞれ情報共有グループＡとＢでコンテンツに対する検索の文脈が異なる。さらに、「Ｓｅｒｖｉｃｅ．ｍｕｓｉｃ」のスコープでは、音楽サーバやファイルサーバなどのサービスの文脈に基づいて検索される。
【００３４】
本発明に基づくシステムでは、「属性名」のようなコンテンツのメタ属性にその有効範囲を規定するスコープを導入して任意の属性名を各ノードが自由にインデックスサーバＩＤＸＳＶＲに登録するようにし、それらの属性に基づく検索を可能にしている。
【００３５】
ノードからの要求に対する具体的な処理の流れを説明する。
１）インデックスサーバＩＤＸＳＶＲは、各ノードから登録された属性のインデックスを作成してインデックスデータファイルＩＤＸＦＬに格納し、これに基づくコンテンツの検索を可能とする
２）ノードＮＤ１は、「Ｓｅｒｖｉｃｅ」のスコープでインデックスサーバＩＤＸＳＶＲのインデックスデータファイルＩＤＸＦＬに登録されている音楽サーバとなるノードを検索する。
３）ノードＮＤ１は、検索により見つけたノードＮＤ４に対してサービスをリクエストする。
【００３６】
１）ノードＮＤ５は、インデックスサーバＩＤＸＳＶＲのインデックスデータファイルＩＤＸＦＬから「ＧｒｏｕｐＢ．ｃｏｎｔｅｎｔ」のスコープで任意のｍｐ３ファイル（ファイル形式＝ｍｐ３となるファイル）の一覧を取得する
２）ノードＮＤ５は、取得した一覧ファイルに基づき、希望するコンテンツのファイルをネットワークＮＷを経由してノードＮＤ４から取得する。
【００３７】
次にインデックスサーバＩＤＸＳＶＲの動作について説明する。
図３はインデックスサーバＩＤＸＳＶＲ内のデータ構造説明図である。インデックスサーバＩＤＸＳＶＲは、コンテンツデータファイルＣＴＳＦＬに格納されるコンテンツデータＣＴＳとインデックスデータファイルＩＤＸＦＬに格納されるインデックスデータＩＤＸという二つのデータ構造を持っている。
【００３８】
コンテンツデータＣＴＳは、コンテンツＩＤを格納する可変長テーブルであるコンテンツＩＤ表と、各コンテンツＩＤ表の値にリンクされた可変属性リストとで構成されている。可変属性リストは、対応するコンテンツＩＤが持つ属性のリストである。
【００３９】
インデックスデータＩＤＸは、属性のスコープと属性名の連結値をキーとする可変表である属性表と、そこから連結された対応する属性が持つ値の一覧表である値表と、各値表の値から連結された特定の属性名と属性値を持つ可変コンテンツＩＤリストとで構成されている。
【００４０】
インデックスサーバＩＤＸＳＶＲへの新規コンテンツの追加について、コンテンツデータＣＴＳに対する操作とインデックスデータＩＤＸに対する操作について説明する。
【００４１】
＜コンテンツデータＣＴＳに対する操作＞
１）コンテンツＩＤ表に追加されたコンテンツのＩＤ（ＩＤ＿Ｎｅｗと以下記述）を挿入する。
２）コンテンツの各属性をそのコンテンツＩＤの可変属性リストに追加する。
【００４２】
＜インデックスデータＩＤＸに対する操作＞
以下挿入されるコンテンツの各属性に対して繰り返す。
１）スコープと属性名の連結値（Ｘ）が属性表に存在するか確認する。
２）Ｘが存在するときは、対応する値の値表に属性値（Ｙ）が存在するか確認する。
３）Ｙが存在しない場合は新たにＹを値表に挿入し、その可変コンテンツＩＤリストにＩＤ＿Ｎｅｗを追加する。
４）Ｙが存在する場合はＩＤ＿Ｎｅｗをその可変コンテンツＩＤリストに追加する。
５）Ｘが存在しないときはＸを属性表に挿入し、その値表を作成してＹを挿入し、その可変コンテンツＩＤリストを作成してこれにＩＤ＿Ｎｅｗを追加する。
【００４３】
インデックスサーバＩＤＸＳＶＲからのコンテンツの削除について、コンテンツデータＣＴＳに対する操作とインデックスデータＩＤＸに対する操作について説明する。
【００４４】
＜コンテンツデータＣＴＳに対する操作＞
コンテンツＩＤ表から削除されるコンテンツのＩＤ（ＩＤ＿ｄｅｌと記述）とすべてのその可変属性リストを削除する。
【００４５】
＜インデックスデータＩＤＸに対する操作＞
以下削除されるコンテンツの各属性に対して繰り返す
１）スコープと属性名の連結値（Ｘ）を属性表から検索する。
２）その値に対応する値表から挿入される属性値（Ｙ）を検索する。
３）それに関連される可変コンテンツＩＤリストからＩＤ＿ｄｅｌを検索し、その値を削除する。
４）ＩＤ＿ｄｅｌの削除の結果、対応する可変コンテンツＩＤリストの長さが０になった場合、値表から属性値（Ｙ）を削除する。
５）属性値Ｙの削除の結果値表の大きさが０になった場合、対応する属性表の連結値（Ｘ）を削除する。
【００４６】
続いてコンテンツの検索について説明する。
＜インデックスデータＩＤＸに対する検索＞
スコープ＝ｓｃｏｐｅＸ、属性名＝ｔｙｐｅＸ、属性値＝ｖａｌｕｅＸを持つコンテンツを検索するとする。
１）ＳｃｏｐｅＸ：ｔｙｐｅＸの値を属性表から検索する。存在しない場合は、該当するコンテンツは存在しない。
２）ＳｃｏｐｅＸ：ｔｙｐｅＸとなる値が存在する場合には、対応する値表からｖａｌｕｅＸを検索する。存在しない場合は、該当するコンテンツは存在しない。存在する場合は、該当する値の可変コンテンツＩＤリストの各値が該当するコンテンツＩＤである。
同様に、属性名、属性値に対して比較演算による検索も可能である。（例．  属性値がＸＸＸ“で始まる”、“を含む”、”で終わる”等）
【００４７】
＜コンテンツデータＣＴＳに対する検索＞
インデックスデータに対する検索から得られた各コンテンツＩＤについて、コンテンツＩＤ表の値と対応する可変属性リストを検索することにより、対応するコンテンツのすべての属性を取得できる。
【００４８】
以上のように構成によれば、インデックスサーバＩＤＸＳＶＲは属性の登録と検索の機能しか持たないため、従来のシステムのようなサーバ負荷の一極集中が生じることはなく、負荷分散が図れる。
【００４９】
そして、音楽共有などの特定のアプリケーションに依存しない汎用的なハイブリッドピアツーピア型の情報共有システムが実現できる。
【００５０】
さらに、互いに独立した複数の情報共有グループを任意に形成できる。ここで独立したとは、
１）互いに異なる属性の語彙を有すること
２）それぞれの情報共有グループ間で相互干渉による副作用なしにシステムを利用できることを意味する。
これにより、同じコンテンツ実体に対して複数のスコープで属性を定義することができ、それぞれの文脈で検索、アクセスが可能となる。
【００５１】
ところで、ノードがコンテンツの属性をインデックスサーバＩＤＸＳＶＲのインデックスデータファイルＩＤＸＦＬに登録したままダウンしてネットワークＮＷから切り離されると、登録された属性は永遠にゴミとしてインデックスサーバＩＤＸＳＶＲに残ってしまうことになる。このような不都合を解決するためには、不必要な属性を適切に削除し、ゴミとなる属性をインデックスサーバＩＤＸＳＶＲのインデックスデータファイルＩＤＸＦＬに残さないようにすればよい。
【００５２】
このような対策としては、インデックスサーバＩＤＸＳＶＲに格納するコンテンツの属性に対して例えば有効期限と接続セッションの２種類のライフサイクルを導入する。具体的には例えば図４に示すように、インデックスサーバＩＤＸＳＶＲに登録有効期限ファイルＲＶＤＦＬと接続セッション制御部ＣＳＣＴＬを設ける。
【００５３】
有効期限ライフサイクルでは、登録有効期限ファイルＲＶＤＦＬにインデックスサーバＩＤＸＳＶＲに登録する属性に有効期限を設定して、これを越えた属性についてはインデックスサーバＩＤＸＳＶＲが自動的に削除する。
【００５４】
接続セッションライフサイクルでは、インデックスサーバＩＤＸＳＶＲの接続セッション制御部ＣＳＣＴＬは、ノードがインデックスサーバＩＤＸＳＶＲにネットワーク接続されている（接続セッションが存在する）間だけそれに関する属性を保持し、接続が切れるとそのノードに関するすべての属性を削除する。
【００５５】
これらにより、コンテンツの属性をインデックスサーバＩＤＸＳＶＲのインデックスデータファイルＩＤＸＦＬに登録したままノードがダウンしてネットワークＮＷから切り離されても不必要な属性データは適切に削除されるので、ゴミとして残ることはない。
【００５６】
他の問題として、あるノードが検索の結果に基づいて別ノードのコンテンツの取得あるいはサービス要求をするのにあたり、直接それらのノードにアクセスできない場合がある。
例えばアクセスされるノードはサーバにはなれない。
また、各ノードが存在するネットワークにファイアウォールが導入されていたり各ノードにプライベートアドレスが割り当てられていると、ノード間の接続性がなくなってしまう。
【００５７】
このような問題は、図５に示すように、インデックスサーバＩＤＸＳＶＲにメッセージ転送制御部ＭＳＧＣＴＬを設け、インデックスサーバＩＤＸＳＶＲに接続されたノード間でインデックスサーバＩＤＸＳＶＲを経由してメッセージをやりとりするインデックスサーバＩＤＸＳＶＲによるノード間のメッセージ仲介機能を設けることで解決できる。
【００５８】
図５の動作例を説明する。
１）ノードＮＤ１は、ノード検索機能によりノードＮＤ３を検索する。
２）ノードＮＤ１は、インデックスサーバＩＤＸＳＶＲのメッセージ転送制御部ＭＳＧＣＴＬに対して、メッセージをノードＮＤ３に転送する要求を出す。
３）メッセージ転送制御部ＭＳＧＣＴＬはノードＮＤ３がインデックスサーバＩＤＸＳＶＲに接続されている場合、メッセージをノードＮＤ３に転送する。
４）ノードＮＤ３はメッセージを受信する
【００５９】
【発明の効果】
以上説明したように、本発明によれば、柔軟性・拡張性の優れた情報共有システムを構築することができ、測定データ管理をはじめとする各種のデータ収集システムや、情報ファイル交換サービスシステムなどに好適である。
【図面の簡単な説明】
【図１】本発明の実施態様の一例を示す情報共有システムのブロック図である。
【図２】図１のノードＮＤ４における音楽ファイルについての属性定義例である。
【図３】インデックスサーバＩＤＸＳＶＲ内のデータ構造説明図である。
【図４】本発明の他の実施態様例を示す情報共有システムのブロック図である。
【図５】本発明の他の実施態様例を示す情報共有システムのブロック図である。
【図６】従来の情報共有システム例を示すブロック図である。
【符号の説明】
ＮＤ  ノード
ＩＤＸＳＶＲ  インデックスサーバ
ＮＷ  ネットワーク
ＩＤＸＦＬ  インデックスデータファイル
ＣＴＳＦＬ  コンテンツデータファイル
ＲＶＤＦＬ  登録有効期限ファイル
ＣＳＣＴＬ  接続セッション制御部
ＭＳＧＣＴＬ  メッセージ転送制御部
【図１】
2004265273.tif 000003
【図２】
2004265273.tif 000004
【図３】
2004265273.tif 000005
【図４】
2004265273.tif 000006
【図５】
2004265273.tif 000007
【図６】
2004265273.tif 000008