JP2008146517A - データ配布システムおよびインデクス保持装置 - Google Patents

Abstract

【課題】 ユーザ間でデータを交換するネットワークにおいて，データ取得者が，これから取得しようとしているデータが所望のデータであるかどうか，信憑性を事前に考慮することがまったくできない。したがって，データ取得者がそれと知らずに悪意あるデータを取得してしまう危険性が発生し，ネットワーク管理者はデータ取得者に安全を提供できない。
【解決手段】 ネットワーク管理者はデータ配布者に対し，あらかじめ割り当てた固有の配布者識別子をユーザに公開し，ユーザから悪意あるデータを配布したと通報を受けた配布者識別子を持つユーザのデータ配布を禁止することで，データ配布者の信頼性を確保する。また，データの拇印を用いて改ざんされたデータを検出し，これが再配布されることを阻止する。さらにデータを改ざんしたユーザを特定し，このユーザのネットワーク利用を禁止する。
【選択図】 図１

Description

本発明はユーザ間で相互にデータ転送を行う通信手法において，最初のデータ配布およびその後のデータ転送を管理する手法とその実現装置に関する。

１９９９年に米国で発表されたＮａｐｓｔｅｒにより，多数のユーザ間で相互にデータ転送を行う，ピアツーピア（以下Ｐ２Ｐと呼ぶ）ソフトウェアが爆発的に普及した。主な普及の要因として，他のユーザが保持しているデータを直接取得することが可能になった点を挙げることができる。このとき，自分の欲しいデータを誰が保持しているか，検索できることが非常に重要となる。すなわち，データが存在していたとしても，その所在を検索できない限りそのデータの取得はできず，結果として存在していないのと同じことになる。

Ｎａｐｓｔｅｒは中央サーバにおいてすべてのデータの所在情報を検索するため，このサーバに検索処理負荷が集中しシステム全体の性能を決定してしまうという弱点があった。また，中央サーバが故障してしまうとシステムが停止するという弱点もあった。この中央サーバが存在するＰ２ＰシステムはハイブリッドＰ２Ｐと呼ばれている。

これら弱点を解消するため，２０００年に米国でＧｎｕｔｅｌｌａ（非特許文献１ｈｔｔｐ：／／ｗｗｗ９．ｌｉｍｅｗｉｒｅ．ｃｏｍ／ｄｅｖｅｌｏｐｅｒ／ｇｎｕｔｅｌｌａ_ｐｒｏｔｏｃｏｌ_０．４．ｐｄｆ）が発表された。検索のための中央サーバを廃し，検索自身もユーザ間で相互にバケツリレーを行う方式を採用した。これによりＮａｐｓｔｅｒの弱点はなくなったが，検索のための通信量が爆発的に増大してしまった。また，バケツリレー方式の検索は時間がかかり，実際の検索には時間的制約があるため，データは存在するにもかかわらず検索の結果発見できない場合がある，という新たな弱点を持つことになった。このＧｎｕｔｅｌｌａはデータの所在を検索するための中央サーバが必要ないため，ピュアＰ２Ｐと区分される。

日本においてＰ２Ｐソフトウェアは２００２年に発表されたＷｉｎｎｙ（非特許文献２ Ｗｉｎｎｙの技術，ＩＳＢＮ４−７５６１−４５４８−５）によって広く一般に知られるようになった。ＷｉｎｎｙはピュアＰ２Ｐに区分されるが，データ転送経路の途中の装置において，本来必要でないにもかかわらず，転送中のデータをキャッシュする機能を持っている。これによりデータ転送速度の向上が見込める。

他方，通常のクライアントサーバシステムでの常識に反し，人気があって取得する人の多いデータほど取得速度が向上する，という特徴を持つハイブリッドＰ２ＰソフトのＢｉｔＴｏｒｒｅｎｔ（非特許文献３ ｈｔｔｐ：／／ｗｗｗ．ｂｉｔｔｏｒｒｅｎｔ．ｏｒｇ／ｐｒｏｔｏｃｏｌ．ｈｔｍｌ）が２００１年に米国で発表された。これはデータを小さなピースに分割してお互いに足りない部分を持ち寄る，という仕組みであるため，人気のあるデータほど自分の足りないピースを保持するユーザが多くなり，結果として取得速度が向上する。特に，映像データなどデータ量が多いものほど取得速度向上の恩恵が得られるため，最近ではテレビドラマ等映像データの配布手段として商用サービスへの適用がはじまっている。

ＢｉｔＴｏｒｒｅｎｔはハイブリッドＰ２Ｐであるが，Ｎａｐｓｔｅｒと異なりデータの所在検索機能を持たないことで中央サーバが持つ弱点を回避している。つまりユーザは別の方法でデータを検索する必要があるが，その分中央サーバの処理負荷を減らしている。また，中央サーバを複数持つことにより，ひとつの中央サーバが停止することでシステム全体が停止する，ということを防いでいる。以下これについて簡単に説明する。

ＢｉｔＴｏｒｒｅｎｔでは中央サーバをトラッカーと呼び，ここで各データの属性を保持し管理している。このトラッカーは，データを配布したいユーザが自由に設置できる。データの属性には，各ピースがデータ全体のどの部分にあたるか，各ピースのデータ量，各ピースの拇印，各ピースを保持する装置のＩＰアドレスの一覧，取得された回数等が含まれている。トラッカーは複数存在するが，あるデータに関する属性を保持するトラッカーは１つである。

データを取得するためにはどのトラッカーが所望のデータの属性を保持しているかを知る必要があるが，この情報を収めたファイルをトレントファイルと呼ぶ。すなわち，トレントファイルによりトラッカーのＩＰアドレスを知り，トラッカーにより所望のデータを保持する装置のＩＰアドレスを知ることができる。したがって，まずユーザがなすべきことは，所望のデータに関するトレントファイルを検索することである。

上記トレントファイルは通常ｗｅｂサイトで公開されている。したがって，キーワードさえあっていれば通常の検索でトレントファイルを発見できるので，特定のユーザ群にのみ公開したいデータを配布することは非常に困難である。また，ある特定のユーザ群以外に，データが存在すること自体を隠蔽することも非常に困難である。これに対し，特許文献１には，分散ハッシュという技術を用いたデータ検索を行なう場合に，ユーザ識別子を用いて検索する権限があるかどうか認証して解決する方法が開示されている。（特許文献１特開２００６−２３６３４９）
データを取得する手順は，まず検索サイト等を利用してトレントファイルを探し，次にトラッカーへ接続して前記データを保持する装置のＩＰアドレスを入手する。その後入手したＩＰアドレスの装置からデータを取得し，閲覧してデータの内容を確認する。

特開２００６−２３６３４９ ｈｔｔｐ：／／ｗｗｗ９．ｌｉｍｅｗｉｒｅ．ｃｏｍ／ｄｅｖｅｌｏｐｅｒ／ｇｎｕｔｅｌｌａ_ｐｒｏｔｏｃｏｌ_０．４．ｐｄｆ Ｗｉｎｎｙの技術，ＩＳＢＮ４−７５６１−４５４８−５ ｈｔｔｐ：／／ｗｗｗ．ｂｉｔｔｏｒｒｅｎｔ．ｏｒｇ／ｐｒｏｔｏｃｏｌ．ｈｔｍｌ

以下，改ざんされたデータ，コンピュータウィルス等のことを悪意あるデータ，データを改ざんするユーザ，コンピュータウィルス等を配布するユーザを悪意あるユーザと呼ぶ。

ＢｉｔＴｏｒｒｅｎｔをはじめとするＰ２Ｐソフトウェアによりユーザ間で自由にデータを交換し，ユーザの創作物を広く公開することができるようになった。しかしながら一方，ウィルス等被害を与えるデータも意図せず，しかも容易に取得できるようになった。例えば，ＢｉｔＴｏｒｒｅｎｔにおいてはトレントファイルの信憑性，すなわち本当に所望のデータを取得できるのかどうかは，実際にトレントファイルを使用してデータを取得し，閲覧してみるまで確認できない。よって，閲覧してみたらウィルスであったり，改ざんされており役に立たないデータであったり，ということが起こり得る。また，各トラッカーは各データに関して，送信元の装置のＩＰアドレス，取得した装置のＩＰアドレスを記録することができるが，最初に前記データを配布したユーザ名，前記データを取得したユーザ名を記録することはできない。

したがって映像データの販売といった商用サービスへの利用を考えたとき，データ流通の安全性や制御の観点から次に述べる課題が発生する。
一度配布されたデータに関して，後からその取得を禁止する制御をネットワーク管理者が行うことができない。したがって，データ取得者が，悪意あるデータを誤って取得してしまうことが起こり得る。また，ネットワーク管理者が悪意あるユーザを特定することができないため，悪意あるユーザをネットワークから排除することができない。したがって，さらなる悪意あるデータの配布を許してしまう危険性がある。

さらに，データ取得者が，これから取得しようとしているデータが所望のデータであるかどうか，信憑性を事前に考慮することがまったくできない。したがって，データ取得者がそれと知らずに悪意あるデータを取得してしまう危険性が発生し，ネットワーク管理者はデータ取得者に安全を提供できない。
また，データ配布者が特定のユーザ群にのみデータを配布すること，あるいは特定のユーザ群以外にはデータの存在自体を隠蔽することは非常に困難である。

本発明の目的は，これらの課題を解決し，ネットワーク管理者がユーザ間のデータ交換を制御して，データ配布者と取得者双方が安心して利用できるネットワークシステムを提供することである。

本発明によるデータ配布ネットワークのネットワーク管理者はデータ配布者に対し，固有の配布者識別子をあらかじめ割り当てる。また，データ配布装置において，配布するデータの属性をインデクス保持装置に配布者識別子を用いて登録する手段を備え，データ取得装置は，配布者識別子とデータ名を用いてデータの所在を検索し，データを取得する手段を備える。データ取得装置において，取得したデータが悪意あるデータであると判断した場合に，取得データの識別子をインデクス保持装置に通知する手段と，インデクス保持装置において，通知によって得られるデータの識別子を管理するデータブラックリストを保持する手段を備え，さらにインデクス保持装置において，前記データブラックリストに載っているデータへの検索に関してデータが存在しないと応答する手段を備える。

ユーザ間でデータを相互に交換するネットワークにおいて，配布された任意のデータに関し，配布ユーザ，取得ユーザ双方を特定することにより，ネットワーク管理者が特定データの転送禁止，特定ユーザに対してネットワーク利用停止等の措置をとることができる。これにより，ユーザに被害を与える悪意あるデータ，悪意あるユーザをネットワークから排除し，ユーザが安心して利用できるネットワークを提供できる。

以下図面に従い，本発明による実施形態の１つを説明する。まず説明に使用する記法について説明する。特に装置間処理シーケンスや装置内処理フローチャートの説明でメッセージの引数を記述する際は，例えば（ｖｉｄ，ｕｉｄ）のようにカッコ内にカンマで区切って必要とされる引数を記述する。

図１はネットワーク構成の全体図である。本発明によるデータ配布ネットワーク１２０は，データ取得装置１１０，データ配布装置１１１，インデクス保持ネットワーク１２１の３つより構成される。インデクス保持ネットワークは，複数のインデクス保持装置１１３より構成される。データ取得装置，データ配布装置，インデクス保持装置はネットワーク管理者の管理下にあるが，ネットワーク管理者が所有する装置はインデクス保持装置のみであり，他はユーザが所有する装置である。本ネットワーク１２０は大きくデータ配布，データ取得，データ属性の保持，の３つの機能，およびそれぞれに付随する機能を具備する。しかし，データ配布者が存在しているかどうかについての検索機能は具備しないため，データ取得の際には他の手段で所望のデータ配布者の存在情報を入手する必要がある。これは，例えばネットワーク管理者のｗｅｂサイトで公開するなどの手段が考えられる。

また，データ配布者はあらかじめネットワーク管理者に申請し，配布者識別子（以下ｖｉｄと呼ぶ）を割り当てられているものとする。同様に，本データ配布ネットワークを利用するすべてのユーザは，本データ配布ネットワーク管理者から固有のユーザ識別子（以下ｕｉｄと呼ぶ）をあらかじめ割り当てられているものとする。ｕｉｄは本データ配布ネットワークを利用する際に必要で，ログオン処理で使用される。なりすまし等他ユーザによる悪用を防ぐため，ｕｉｄは本人以外のユーザに非公開である。ｖｉｄは本データ配布ネットワークを利用してデータを配布する際に必要で，データ登録処理で使用される。よって，ｖｉｄは全ユーザに公開することが可能である。ｕｉｄはユーザと一対一対応であるが，ｖｉｄは一ユーザが複数保持でき，また，複数ユーザで一ｖｉｄを共有し，さらには複数ユーザで複数ｖｉｄを共有することができる。また，ｖｉｄには会社名，ブランド名，芸名等ユーザ自身が好みのものを指定できるが，ｕｉｄは本データ配布ネットワーク管理者が指定する。

ユーザ間でデータを交換する場合，データの身元，すなわち最初のデータ配布者を知ることは通常困難である。ｖｉｄはデータ取得者に対してデータの身元を明らかにするとともに，データ配布者に対してはそのデータが己の著作物であると明示する，という２つの意味を持つ。データ取得者はｖｉｄでデータの信頼性を判断することができ，データ配布者がｖｉｄを信頼してもらえるように，データ配布に注意を払うようになると期待できる。一度被害にあったｖｉｄと同一のｖｉｄをもつデータを取得しようとするユーザは少ない，と考えられるからである。

また，ｖｉｄを用いてデータ取得の利便性を向上させることもできる。例えば，同一ｖｉｄをもつ全データを一度に指定し，取得することができる。この際，各データのデータ名を知る必要がなく，すなわちデータ名で検索する手間が必要ない。例えばシリーズものＴＶ番組データを配布するに当たり，専用のｖｉｄを用意することで，いちいち各データ名を指定してデータを取得する必要がなくなる。さらに，ネットワークの安全性を向上させることもできる。例えば，あるｖｉｄを持つ複数のデータに改ざんが検出された際，このｖｉｄをもつデータを取得するユーザに対する監視を強化する等の行動が可能になる。

本データ配布ネットワークを利用するため，データ配布者およびデータ取得者は，まずネットワークへログオンする必要がある。このログオンする際のシーケンスが図２８，データを取得する際のシーケンスが図２，データを配布する際のシーケンスが図３である。以下説明の都合上，データ取得，データ配布，ログオンの順に説明する。また，装置間処理シーケンス，装置内部構成，装置内処理フローチャートの順に説明する。

図２において，データ取得装置１１０(以下Ｇと呼ぶ)はユーザからデータ取得要求(ｖｉｄ，ＮＡＭＥ)を受信する。ここでＮＡＭＥはデータ名である。まず，Ｇは前記データを保持する装置のＩＰアドレスを知るために，インデクス検索要求（ｖｉｄ，ＮＡＭＥ，ｕ１，ｇ１）２０１をインデクス保持装置１１３（以下Ｍ１とする）に送信する。ｕ１はＧのｕｉｄ、ｇ１はＧのＩＰアドレスである。ＧはＭ１のＩＰアドレスを知っている必要があるが，ここでは図５のようにあらかじめＧにいくつか設定されており，その中から適当にＭ１を選択したものとする。

インデクス検索要求２０１を受信したＭ１は，インデクス保持ネットワーク内を検索し，前記データを保持する装置のＩＰアドレス（以下ｔ１と呼ぶ）と前記データの拇印ｆを得る。このｖｉｄ，ＮＡＭＥで示されるデータを保持する可能性のある装置（以下Ｔと呼ぶ）としては，データ配布装置１１１（以下Ｄ１と呼ぶ）か，または別の異なるデータ取得装置（以下Ｄ２と呼ぶ）がある。ここで，Ｄ２は前記データをすでに取得しており，これを再配布できる状態にあるものとする。インデクス保持ネットワーク内検索の詳細はインデクス保持装置の処理フローチャート図２１と図２２で述べる。Ｍ１はｔ１，ｆをインデクス検索応答２０２でＧに返信する。

Ｍ１はＴ（ｔ１で指定する）に対して，データ転送要求（ｖｉｄ，ＮＡＭＥ，ｇ１）２０３を送信し，ＴはＮＡＭＥで示されるデータをＧに送信（メッセージ２０４）する。Ｔは，データ送信が終了すると，Ｍ１にデータ転送終了通知２０５を送信する。このメッセージによって，図１３に示されるインデクスが更新される。また，Ｇはｆを用いて取得したデータが改ざんされていないことを確認する。これについては図７で詳細を説明する。もし改ざんされていることを検出した場合，ＧはＭ１にデータ改ざん通知（ｖｉｄ，ＮＡＭＥ，ｔ１）２０６を行う。Ｍ１では受信したメッセージからｔ１を取り出し，後で説明するユーザ情報表（図１９）を参照してｔ１に対応するユーザ識別子ｕ２を検索し，ｕ２をユーザブラックリスト１５０３へ登録する。拇印ｆは取得したデータの改ざんを検出するために使用する重要なデータであるから，インデクス保持装置で管理する。またブラックリストにより，悪意あるユーザのサービス利用，また悪意あるデータの再配布を停止することができる。ブラックリストについては図１２で後述する。

これらＧでの処理の詳細は，図６，７で，Ｔでの処理は図１１で，Ｍ１での処理は図８，２０，２３，２４で述べる。
図３において，データ配布装置１１１（Ｄ１）はユーザからデータ配布要求（ｖｉｄ，ＮＡＭＥ）を受信する。Ｄ１はＭ１に対して，データ登録要求(ｖｉｄ，ＮＡＭＥ，ｕ３，ｄ１、ｆ)を送信する。ここでｆはＤ１において計算された拇印，ｕ３はデータ配布者のユーザ識別子，ｄ１はＤ１のＩＰアドレスである。Ｄ１もインデクス保持装置のＩＰアドレスを知っている必要があるが，ここでは図５のようにあらかじめＤ１にいくつか設定されており，その中から適当にインデクス保持装置Ｍ１を選択したものとする。Ｍ１はデータ登録要求を処理し，その結果をＤ１に通知する。このＤ１での処理の詳細は図１０で，Ｍ１での処理の詳細はインデクス保持装置の処理フローチャートの図２５，２６，２７で説明する。

図２８はＧとＤ１のデータ配布ネットワークへのログオン処理シーケンスである。シーケンスは両者とも同一なので，ここでは両者をまとめてＴ２と呼び，そのＩＰアドレスをｔ２，ユーザ識別子をｕ５とする。装置起動後，ログオン要求（ｕ５。ｔ２）２９０１をＭ１に送信する。ログオン応答２９０２にてログオンが許可されると，Ｔ２はデータ格納領域４１２または９１２に存在するすべてのデータに関して，保持データ情報登録（ｖｉｄ，ＮＡＭＥ，ｕ５，ｔ２）２９０３をＭ１に対して行う。Ｍ１では受信した保持データ情報を用いて，インデクス保持ネットワーク内インデクス登録を行う（２９０４と２９０５）。これによりインデクス保持ネットワークが保持する，図１３で示されるインデクスが更新される。

図４はデータ取得装置１１０（Ｇ）の構成図である。主記憶内にデータ配布ネットワークへのログオン機能４０１，インデクス検索要求機能４０２，データ取得機能４０３があり，それぞれ図２９，６，７のフローチャートで説明する。データ転送機能４０４はすでに取得済みでデータ格納領域４１２に存在するデータを，別のデータ取得装置からの要求に従って再配布する機能である。データ改ざん検出機能４０５はデータ取得機能４０３の一部分であり，取得したデータに関して，配布者が配布したデータと同一であるかどうか，確認する機能である。ハードディスク内にインデクス保持装置一覧４１１，データ格納領域４１２，メッセージバッファ４１３がある。ネットワークインタフェース４２１を介して他の装置と通信を行う。

図９はデータ配布装置１１１（Ｄ１）の内部構成図である。主記憶にデータ配布ネットワークへのログオン機能４０１，データ登録要求機能９０２，データ転送機能４０４がある。ハードディスク内に存在するものはＧと同一である。また，ログオン機能とデータ転送機能は，データ取得装置と同一である。データ登録要求機能９０２は図１０のフローチャートで説明する。ネットワークインタフェースの機能はＧと同一である。

図１２はインデクス保持装置１１３（Ｍ１）の内部構成図である。主記憶には検索応答機能１２０１，データ転送記録機能１２０２，データ登録応答機能１２０３，インデクス保持ネットワーク内インデクス検索機能１２０４，インデクス保持ネットワーク内インデクス登録機能１２０５，ログオン受付機能１２０６，インデクス公開機能１２０７がある。ハードディスクにはインデクス１２１１，インデクス保持装置ＩＰアドレス表１２１２，ユーザ情報表１２１３，ブラックリスト１２１５，拇印保持装置ＩＰアドレス表１２１６，拇印表１２１７，ユーザ統計表１２１８，メッセージバッファ４１３が存在する。ネットワークインタフェースの機能はＧと同一である。インデクス公開機能は，図１３のインデクスのうち，ｖｉｄとＮＡＭＥのペアを全データ取得者に公開する機能である。公開方法は，例えばｖｉｄごとにページを作成し，ＮＡＭＥの一覧を載せる等が考えられる。本機能は例えばａｐａｃｈｅ等ｗｅｂサーバが該当する。公開するｖｉｄとＮＡＭＥはすべてのインデクス保持装置から収集し，ある少数の特定のインデクス保持装置が公開することが考えられる。この場合，図５のように少数のインデクス保持装置のＩＰアドレスをあらかじめデータ取得装置に保持しておく。または，全インデクス保持装置で公開してもよい。この場合，データ取得装置は図５から適当にＩＰアドレスを選択すればよい。すべてのインデクス保持装置から配布者識別子とデータ名を収集するためには，図１４を参照し，ここにあるすべてのＩＰアドレスに対して配布者識別子とデータ名の通知を求めればよい。

図５はＧまたはＤ１が保持しているインデクス保持装置一覧４１１の具体例である。ここにはあらかじめいくつかのインデクス保持装置のＩＰアドレスを保持しておき，インデクス検索要求機能４０２等で使用する。例えば，優先順の順に接続を試み，成功したものと通信を行う方法がある。

図１３はＭ１が保持しているインデクス１２１１の具体例である。各インデクスエントリは各データの属性として，少なくとも検索キーとして配布者識別子（ｖｉｄ）とデータ名のハッシュ値（ｈ）を含み，値として前記データ名（ＮＡＭＥ），データ配布装置のＩＰアドレス，前記データの拇印（ｆ），前記データを取得したユーザのユーザ識別子のリスト，前記データを取得し現在も保持しているデータ取得装置のＩＰアドレスのリスト，前記データの総取得回数，を含む。検索応答処理１２０１時にこの表を参照してデータを保持している装置のＩＰアドレスを検索する。複数のＩＰアドレスがあるときは，そのうちどれかひとつを選択して応答することも，すべてのＩＰアドレスのリストを応答することもできる。また，ＩＰアドレスが存在しない場合にはデータ配布装置のＩＰアドレスを応答する。応答にはデータ名が含まれるので，検索要求側でデータ名が一致するか確認することもできる。拇印は検索要求者が該データを取得した際に，データの改ざんの有無を検出するために使用する。当該データを保持する装置のユーザが本データ配布ネットワークからログアウトした場合，そのＩＰアドレスは本表から削除される。該データを取得したユーザのユーザ識別子は，管理上の目的で，該データの転送経路を追跡したい場合等に使用する。ｖｉｄを検索キーとすることで，ファイル名がわからなくともデータ配布者がわかっているとき，データを取得することが可能となる。また，データ取得回数は統計情報としてデータ配布者などに公開することで，ユーザのデータ取得の傾向分析など，マーケティングが可能となる。

図１４はＭ１が保持しているインデクス保持装置ＩＰアドレス表１２１２の例である。それぞれのインデクス保持装置のＩＰアドレスと，そのインデクス保持装置が管轄するインデクス情報の範囲を示している。検索応答処理１２０１において，この表を参照して前記インデクスを保持している，インデクス保持装置のＩＰアドレスを検索する。

図１５はＭ１が保持しているブラックリスト１２１５の例である。ユーザブラックリストを参照し，インデクス保持装置１１３はログオン要求受付１２０６処理時に，ユーザのログオンを許可するか拒否するか判定する。これによりブラックリストに載っている悪意あるユーザを排除することができる。また，検索応答処理１２０１時にデータブラックリストに載っているデータについて，データが存在しないと応答する。これによりブラックリストに載っている，悪意あるデータなど再配布を禁止したいデータの取得を防ぐことができる。さらに，データ登録応答処理１２０３時に，配布者ブラックリストを参照して新規データ配布を許可するか拒否するか判定する。これは，ブラックリストに載っている悪意あるデータ配布ユーザによる，おそらくは悪意あるデータの配布を禁止するためである。これらブラックリストは最初空であり，本データ配布ネットワークを運用中に適宜追加される。また，いくつかの追加方法が図８に示される。ユーザブラックリストにユーザ識別子が追加された際には，同時に当該ユーザを強制的にログアウトさせ，本配布ネットワークから排除することも考えられる。

図１６，図１７はＭ１が保持している拇印保持装置ＩＰアドレス表１２１６の例，拇印表１２１７の例である。これは，新規に配布しようとするデータがすでに配布されているかどうか確認するために使用する。すなわち，Ｍ１において，データ登録応答処理１２０３時に使用される。図１７は，ある拇印をもつデータが存在しているかどうかを示す表であり，データ登録時に値が１とされる。あとで検索された時に，これが１であるデータはすでに存在すると判断する。実装によっては右欄がなく，左欄に拇印があることのみで該当データが存在するかどうか判断することもできる。図１６はある値の範囲の拇印にたいして，該当する図１７を保持するインデクス保持装置のＩＰアドレスを示す表である。拇印により，データがすでに登録されているかどうか判断することができ，例えば次のような効果がある。あるユーザが自分が過去に作成したデータの登録時に，すでに別人が登録していることに気がつくことができ，この別人に対して抗議を行なうことができる。

図１８はＭ１が保持するユーザ統計表１２１８の例である。これはデータ取得者が，どのデータを取得したか，その履歴を記録するものである。通常この表はデータ配布者にユーザ識別子を伏せて公開される。データ配布者はこの履歴を分析し，どのデータが人気があるか，等のマーケティングを行なうことができる。

図１９はＭ１が保持する，ユーザ情報表１２１３の例である。データ登録応答処理１２０３時に，データを配布しようとするユーザが，配布者識別子を事前に取得してその権利を持っているか，確認するために使用する。これは，ｕｉｄをキーとしてｖｉｄ，ＩＰアドレス，データ取得可能な配布者識別子リストの対応を示したものであり，ｕｉｄとｖｉｄは本データ配布ネットワークの管理者がユーザとのサービス契約時に設定するものである。ＩＰアドレスは，ログオン要求受付１２０６処理時に登録される。また，データ取得可能な配布者識別子には該ユーザがデータを取得する前に，データ配布者から直接，あるいはシステム管理者を介して間接にデータ取得の許可をとった際に，該データ配布者の配布者識別子が設定される。この許可は，例えばｗｅｂサイトでｖｉｄと配布データの一覧を公開するページに，データ取得のためのユーザ登録を行うページへの誘導を付け加える等により与えることができる。これにより，データ配布者がデータ取得者を制限したい場合にデータ取得許可を与えるユーザを選択することができる。さらに，データ取得許可を与えたユーザ以外には，該当データが存在する，という情報を隠蔽することもできる。これについては図２０で説明するが，ｖｉｄとデータ名をｗｅｂで公開せずに，データ取得許可を与えたユーザに個別に通知する必要がある。なお，データ取得者をまったく制限しない場合には，該当欄を空欄にしておく，あるいは“＊”等の特別な文字で代用することができる。

図６はＧのデクス検索要求機能，図７はＧのデータ取得機能のフローチャートである。
インデクス検索要求２０１においては，まずユーザからｖｉｄ，ＮＡＭＥを取得する（６０１）。図５の説明で述べたようにｍ１を選択し（６０２），ｖｉｄ，ＮＡＭＥを含んだインデクス検索要求メッセージをメッセージバッファ４１３に作成する（６０３）。これをＭ１へ送信し（６０４），その応答を受信するまで待つ（６０５）。Ｍ１から応答メッセージを受信したら，内容を確認し（６０６），ｔ１，ｆが存在した場合は，ｖｉｄおよびＮＡＭＥとあわせて，データ取得機能４０３に入力する（６０７）。応答メッセージにＩＰアドレスが含まれない場合は，ユーザに該当データが存在しないと通知する（６０８）。

データ取得機能４１３においては，インデクス検索要求機能４０２から（ｖｉｄ，ＮＡＭＥ，ｆ，ｔ１）を受信する（７０１）と，データを受信するのを待ち，データ格納領域へ保存する（７０２）。データ改ざん検出機能４０５により，改ざんの有無を確認（７０３）する。具体的には，受信したデータ全体から拇印ｆ2を計算する。このときに必要なハッシュ関数は本データ配布ネットワーク１２０全体で１つであり，あらかじめ設定されているものとする。ハッシュ関数の例としては，ＳＨＡ１（参考 ｆｔｐ：／／ｆｔｐ．ｒｆｃ−ｅｄｉｔｏｒ．ｏｒｇ／ｉｎ−ｎｏｔｅｓ／ｒｆｃ３１７４．ｔｘｔ）やＭＤ５（参考 ｆｔｐ：／／ｆｔｐ．ｒｆｃ−ｅｄｉｔｏｒ．ｏｒｇ／ｉｎ−ｎｏｔｅｓ／ｒｆｃ１３２１．ｔｘｔ）などがある。次にｆとｆ２を比較し，完全に一致する場合は改ざんがないと判定し，ユーザにデータ取得完了と通知する（７０４）。そうでない場合は改ざんがあったものと判定し，Ｍ１に対してデータ改ざん通知（ｖｉｄ，ＮＡＭＥ，ｔ１）を行う（７０５）。かつ，ユーザにデータ取得失敗を通知する（７０６）。

図１１はＴのデータ転送機能４０４のフローチャートである。データ転送要求２１３をＧから受信（１１０１）すると，メッセージバッファからＧのＩＰアドレスであるｇ１，ｖｉｄ，ＮＡＭＥを読み出す（１１０２）。次にデータ格納領域４１２からＮＡＭＥで指定されるデータを読み出しＧへ送信する（１１０３）。送信が終了すると，Ｍ１へデータ転送終了通知（ｖｉｄ，ＮＡＭＥ，ｄ１，ｇ１）２０５を行う（１１０４）。

図２０はＭ１における検索応答処理１２０１のフローチャートである。まずネットワークインタフェースでＧからのインデクス検索要求２０１を受信するとメッセージバッファ１２１９へ格納する（２１０１）。メッセージバッファから配布者識別子（ｖｉｄ），データ名（ＮＡＭＥ），検索を要求したユーザ識別子（ｕ１），該ユーザ端末のＩＰアドレス（ｇ１）を読み出しｕ１でユーザ情報表（図１９）を検索する（２１０２）。得られた取得可能配布者識別子の中にｖｉｄが存在しない場合，検索要求者に対して，検索不可と応答する（２１０７）。これにより，データ取得許可のないユーザはデータの取得が不可能になる。この場合，もしｖｉｄとＮＡＭＥが公開されているのならばデータ取得者は別途データ取得許可を得ようと試みることができる。しかし，ｖｉｄとＮＡＭＥを一般に公開しない場合には，たとえ該ユーザが意図的に検索したとしても，検索不可とすることで該当データが存在するかどうか，という情報を隠蔽することができる。

次にＮＡＭＥでブラックリスト１２１５を検索する（２１０３）。検索結果ヒットしなければ，ｖｉｄ，ＮＡＭＥでインデクス保持ネットワーク内インデクス検索を実行する（２１０４）。この検索の詳細は図２１，２２で説明する。検索結果がＯＫだった場合，ｔ１，ｆが得られる（２１０５）。次にメッセージバッファにｖｉｄ，ＮＡＭＥ，ｔ１，ｆを書き込み，インデクス検索応答２０２を作成する（２１０６）。手順２１０３でデータブラックリストにヒットした場合，および手順２１０４で検索失敗した場合は，配布者識別子がｖｉｄである配布者はＮＡＭＥで示されるデータを配布していない，という内容のインデクス検索応答を返す（２１０８）。これにより，データが実在するとしてもデータ所在情報を得ることができず，ユーザは該当データを取得できないことになる。特にブラックリストに載っているデータは悪意あるデータなので，このように取得できない方が望ましい。また，所在情報を削除しない理由は，管理上の目的で該データを保持するユーザ端末を追跡する場合があるからである。次にメッセージバッファの内容をネットワークインタフェースからＧに返信する（２１０９）。また，Ｔ１に対して，ｖｉｄとＮＡＭＥで示されるデータをＧへ送信するように指示するメッセージを作成し（２１１０），これを送信する（２１１１）。

図２１，２２はインデクス保持ネットワーク１２１におけるインデクス検索のフローチャートである。Ｍ１において，検索応答処理１２０１からｖｉｄ，ＮＡＭＥを受信する（２２０１）。ＮＡＭＥをあらかじめ決められたハッシュ関数に入力して，ハッシュ値（以下ｈと呼ぶ）を得る（２２０２）。次にｖｉｄ，ｈを用いてインデクス保持装置ＩＰアドレス表１２１２を検索し，ｖｉｄ，ｈで示されるデータのインデクスエントリを管理する，インデクス保持装置（以下Ｍ２と呼ぶ）のＩＰアドレス（以下ｍ２とする）を得る（２２０３）。このｍ２に対してインデクス検索要求（ｖｉｄ，ｈ）を送信する（２２０４）。Ｍ２から得られた応答であるｔ１，ｆを検索応答処理１２０１に返却する（２２０５）。

Ｍ２において，Ｍ１からインデクス検索要求（ｖｉｄ，ｈ）を受信すると（２３０１），ｖｉｄ，ｈでインデクス１２１１を検索する（２３０２）。検索がＯＫの場合，得られたｔ１，ｆをＭ１へ返却し（２３０３），ＮＧの場合はＮＧとＭ１へ返却する（２３０４）。

図８はＭ１におけるブラックリスト１２１５の作成フローチャートである。Ｇからデータ改ざん通知（ｖｉｄ，ＮＡＭＥ，ｔ１）２０６を受信（８０１）した場合，ｔ１でユーザ情報表（図１９）を検索しユーザ識別子ｕ２を得る。このｕ２をすべてのインデクス保持装置のユーザブラックリストへ登録する。このとき，ｕ２に対応するｖｉｄが存在した場合，すべてのインデクス保持装置の配布者ブラックリストにｖｉｄを登録する（８０４）。次にｖｉｄでインデクスを検索し，関連するすべてのデータ名を収集する（８０５）。そして，これらのデータ名をすべてのインデクス保持ノードのデータブラックリストに登録する。ユーザブラックリストへ登録することにより，データを改ざんしたユーザ（ユーザ識別子ｕ２）は次回ログオン時には本データ配布ネットワークから排除される。さらに配布者ブラックリストに登録することにより，即座にデータ配布を禁止することができる。そして，ユーザｕ２が過去にデータ配布者識別子ｖｉｄを使って配布したすべてのデータ名をデータブラックリストへ登録することにより，別ユーザがそれらのデータを取得することを禁止できる。したがって，データを改ざんする悪意を持つユーザを排除するだけでなく，悪意あるデータである可能性が高い，該ユーザが過去に配布したデータについても排除することができる。以上について概略を図に示したものが図３６である。ユーザＤが配布したデータｆｏｏをユーザＥが改ざんした場合，ユーザＤとＤが配布したデータｘｙｚはネットワークから排除されるが，ｆｏｏ自体は排除されない。

また，データ配布者からの転送禁止要求（ｖｉｄ，ＮＡＭＥ）があった場合（８１０），すべてのインデクス保持ノードのデータブラックリストにＮＡＭＥを登録する（８１１）。これにより，ＮＡＭＥに対するインデクス検索要求に対し，検索応答（図２３の２１０３）においてデータが存在しないと応答し該データの取得ができなくなるため，データ配布者からの転送禁止要求を満たすことができる。

さらに，ユーザが例えば，ＮＡＭＥ＝ｆｏｏ，ｖｉｄ＝ｖであるデータがコンピュータウィルスであると通報してきた場合（８２０），すべてのインデクス保持装置の配布者ブラックリストにｖを登録する（８２１）。次にインデクスをｖで検索し，関連するデータ名をすべて収集する（８２２）。これらのデータ名をすべてのインデクス保持装置のデータブラックリストへ登録する（８２３）。これにより，ｆｏｏというデータを配布したユーザのさらなるデータ配布を禁止し，また，すでに配布済みのデータについても，転送を禁止することができる。これについて概要を示した図が図３７である。ユーザＧがデータｆｏｏはコンピュータウィルスだと通報してきた場合，管理者はこれを確認した後，ｆｏｏの転送，および，ｆｏｏの配布者識別子“Ａ，Ｉｎｃ．”を使ったさらなるデータ配布を禁止する。かつ，“Ａ，Ｉｎｃ．”が過去に配布したデータｂａｒも転送禁止する。このようにコンピュータウィルス等悪意あるデータを配布されたとしても，被害の拡大を防ぐことができ，ユーザに安心感を与えることができる。

図２３，２４はインデクス保持ネットワークへのデータ転送記録機能のフローチャートである。Ｍ１においてネットワークインタフェース４２１でＴからのデータ転送終了通知（ｖｉｄ，ＮＡＭＥ，ｇ１）２０５を受信するとメッセージバッファに格納する（２４０１）。メッセージバッファからｖｉｄ，ＮＡＭＥを取り出し，あらかじめ決められたハッシュ関数にＮＡＭＥを代入してハッシュ値ｈを得る（２４０２）。次にインデクス保持装置ＩＰアドレス表により，（ｖｉｄ，ｈ）を管轄するインデクス保持装置のＩＰアドレスを検索する（２４０３）。ここではインデクス保持装置としてＭ２が選択され，そのＩＰアドレスはｍ２とする。着信先アドレスをｍ２としてデータ転送終了通知（ｖｉｄ，ＮＡＭＥ，ｈ，ｇ１）を送信する（２４０４）。

Ｍ２では，Ｍ１からデータ転送終了通知（ｖｉｄ，ＮＡＭＥ，ｈ，ｇ１）を受信し（２５０１），ｇ１でユーザ情報表（図１９）を検索し，ｕ１を得る。ｖｉｄ，ｈを用いてインデクス１２１１を更新する（２５０３）。ここでインデクスには，取得したユーザ識別子の欄にｕ１が，保持装置のＩＰアドレスの欄にｇ１が追記され，総取得回数が１増やされる。図１３の説明で述べたように，データ取得回数はマーケティングに利用できる。

図１０はＤ１のデータ登録要求機能９０２のフローチャートである。まずユーザからｖｉｄ，ＮＡＭＥを受信する（１００１）。このとき，ユーザが登録すべきデータをデータ格納領域４１２に設定する。次にあらかじめ設定されているハッシュ関数を用いて，データ全体から拇印ｆを計算する（１００２）。インデクス保持装置一覧４１１からインデクス保持装置をひとつ選択し（ここではＭ１を選択したとする）（１００３），Ｍ１のＩＰアドレス（ｍ１）を着信先，ｖｉｄ，ＮＡＭＥ，ｆ，データ配布者のユーザ識別子（ｕ３），データ配布装置のＩＰアドレス（ｄ１）を含んだデータ登録要求３０１をデータバッファに作成する（１００４）。これをＭ１へ送信し（１００５），Ｍ１からの応答を待つ。ネットワークインタフェース４２１でデータ登録応答３０２を受信したらこれをメッセージバッファに格納し（１００６），応答を調べる（１００７）。登録がＯＫだったらユーザにデータ配布が成功したと通知し（１００８），ＮＧだったらユーザへデータ配布失敗と通知する（１００９）。

図２５はＭ１のデータ登録応答機能のフローチャートである。まずＤ１からデータ登録要求３０１を受信しメッセージバッファに格納する（２６０１）。メッセージバッファからｖｉｄ，ＮＡＭＥ，ｆ，ｕ３，ｄ１を読み出す（２６０２）。次にｕ３を用いてユーザ情報表１２１３を検索，ｖｉｄが一致して前記ユーザがデータを配布する権利を保持しているか確認する（２６０３）。ＯＫの場合に，ｖｉｄでブラックリスト１２１５を検索して，ｖｉｄが配布者ブラックリストに載っていないことを確認する（２６０４）。手順２６０３でＮＧだった場合と手順２６０４でヒットした場合は，データ登録失敗とみなし図２６の手順２７０７へ進む。これによりブラックリストに載っている，悪意あるユーザが所持するデータなど再配布を禁止したいデータの取得を防ぐことができる。次にあらかじめ決められたハッシュ関数にＮＡＭＥを代入し，ｈを得る（２６０５）。このｈで拇印表１２１７を検索する（２６０６）。もしヒットした場合，前記データはすでに別人が登録している可能性があるため，登録保留としデータ配布者へ通知する（より具体的にはＧＵＩ上に警告として表示する）（２６０７）。図１６の説明で述べたように，もし自分が過去に作成したデータの場合には，この警告により自分のデータが別ユーザに登録されたと気づくことができ，該当ユーザに抗議すること等ができる。ヒットしない場合は，ｖｉｄ，ＮＡＭＥ，ｈ，ｆ，ｕ３，ｄ１をもってインデクスエントリを作成する（２６０８）。図１３でいうと，ｖｉｄは配布者識別子，ＮＡＭＥはデータ名，ｈは検索キー，ｕ３はユーザ識別子，ｄ１はＩＰアドレス，ｆは拇印にあたる。登録直後なので，データを取得したユーザのユーザ識別子，データを取得した装置のＩＰアドレスは空，総取得回数は０である。そして，このインデクスエントリを用いてインデクス保持ネットワーク内インデクス登録３０３を実行する（２６０９）。これについては図２６，２７で説明する。

図２６，２７はインデクス保持ネットワーク内インデクス登録のフローチャートである。Ｍ１において，データ登録応答機能１２０３よりインデクスエントリを受信する（２７０１）とｖｉｄ，ｈを用いてインデクス保持装置ＩＰアドレス表１２１２を参照してｖｉｄ，ｈを管轄するインデクス保持装置のＩＰアドレスを検索する（２７０２）。得られたＩＰアドレスがｍ１の場合，前記インデクスエントリをインデクス１２１１へ新規追加する（２７０３）。上記得られたＩＰアドレスがＭ２のＩＰアドレスであるｍ２の場合，ｍ２を着信先ＩＰアドレスとしてインデクスエントリを含むインデクス登録３０３をメッセージバッファに作成し（２７０４），ネットワークインタフェースから送信する（２７０５）。手順２７０７において，Ｍ２から応答メッセージ３０４を受信した（２７０６）場合は，内容をそのままにデータ登録応答３０２をメッセージバッファに作成する。また，手順２７０３を終了した場合は，その結果を内容としたデータ登録応答３０２をメッセージバッファに作成する。さらに，図２５の手順２６０３においてＮＧ，手順２６０４でヒットした場合はデータ登録を失敗としてデータ登録応答３０２をメッセージバッファに作成する。最後にこのメッセージをネットワークインタフェースからＤ１へ送信する（２７０８）。

Ｍ２においては，Ｍ１からインデクス登録を受信し，メッセージバッファへ格納する（２８０１）。メッセージバッファからインデクスエントリを取り出し（２８０２），インデクス１２１１へ追加する（２８０３）。着信先をｍ１としてインデクス登録応答３０４をメッセージバッファに作成し（２８０４），ネットワークインタフェースから送信する（２８０５）。

図２９はデータ取得装置１１０またはデータ配布装置１１１（以下Ｔ２と呼ぶ）に共通な，データ配布ネットワーク１２０へのログオン機能のフローチャートである。装置起動直後，インデクス保持装置一覧４１１からひとつインデクス保持装置を選択する（３００１）。ここではＭ１（ＩＰアドレスはｍ１）を選択したものとする。このＭ１に対してログオン要求（ｕ５）を送信する（３００２）。ここでｕ５はログオンしようとするデータ取得者またはデータ配布者のユーザ識別子である。Ｍ１からＯＫのログオン応答２９０２を受信したら，データ格納領域に存在するすべてのデータについて，保持データ情報（ｖｉｄ，ＮＡＭＥ，ｆ，ｕ５，ｔ２）を作成する（３００３）。ここでｔ２はＴ２のＩＰアドレスである。次にこれら保持データ情報をまとめて保持データ情報登録２９０３を作成し，Ｍ１に送信する（３００４）。

図３０はＭ１におけるログオン受付機能１２０６のフローチャートである。ログオン要求２９０１をＴ２から受信し（３１０１），ｕ５をとりだし（３１０２），ｕ５でブラックリスト１２１５を検索する（３１０３）。もしヒットしたら，ログオンを拒否するログオン応答２９０２を作成，ｔ２へ返信する（３１０７）。ヒットしない場合はログオンを許可するログオン応答２９０２を作成，ｔ２へ返信する（３１０４）。ブラックリストに載っている悪意あるユーザのログオンを拒否することで，さらなる被害を未然に防ぐことができる。Ｔ２から保持データ情報登録２９０３を受信する（３１０５）と，保持データ情報を用いて，インデクス保持ネットワーク内インデクス登録を実行する（３１０６）。この詳細は図２６，２７と同様である。これを保持データ情報の数だけ繰り返す。

以上説明してきた実施例では，データ取得者が，これから取得しようとしているデータが所望のデータであるかどうか，信憑性を事前に考慮することができる。したがって，データ取得者がそれと知らずに悪意あるデータを取得してしまう危険性がなく，ネットワーク管理者はデータ取得者に安全を提供できる。

本発明による第２の実施例は，図１２で示されるインデクス保持装置が持つログオン機能を別装置とするものである。ログオン受付機能１２０６，ユーザ情報表１２１３，ブラックリスト１２１５のうちユーザブラックリスト１５０３を図３２に示すユーザ管理装置３４０１に移設する。ネットワーク構成図を図３３で示す。データ取得装置１１０，データ配布装置１１１にはこのユーザ管理装置のＩＰアドレスをあらかじめ設定しておく。この場合，図２８のシーケンスは図３４となり，２９０１，２９０２メッセージはユーザ管理装置が処理する。図２９の３００１，３００２ステップではインデクス保持装置のかわりにユーザ管理装置を選択する。さらに図３０の３１０１，３１０２，３１０３，３１０４，３１０７のステップはユーザ管理装置で処理する。また，図２の２０６ステップでは，図３５で示すとおりデータ改ざん通知をユーザ管理装置へも行う。この実施例により，別のサービスと本データ配布ネットワーク利用サービスを連携させる場合等で，すでに存在するユーザ管理装置を利用することができるようになる。

図３１は，本発明による第３の実施例における，インデクス１２１１である。本実施例では，配布するデータを２つのピースに分割する。この時図３１にあるように，ピースごとに拇印，取得したユーザのユーザ識別子，データを取得した装置のＩＰアドレス，総取得回数を管理する。本実施例においては，ピースごとにデータ取得を実行する必要がある。すなわち，図２においてインデクス検索応答２０２には，２ピース分の取得先ＩＰアドレスが含まる。したがって，データ転送要求２０３も２つの異なる取得先へ送信し，データ転送２０４も２つの取得先から受信する。また，データ改ざん通知２０６，データ転送終了通知もそれぞれ２ピース分送信される。一方配布データの登録は，ピース単位でなくデータ単位であるので，図３におけるシーケンスに変更はない。ただし，図３１にあるインデクスの変更に従い，データ登録要求に含まれる拇印ｆは，ピース単位で計算し，ピースの数だけ存在する。データを２つのピースへ分割することによる変更は以上である。

また，以上の議論は分割するピース数が３以上に増えた場合も同様であり，データごとに分割数を変えることも可能である。本実施例のようにデータを複数のピースに分割することにより，同時に複数のピースを取得することができ，結果としてひとつのデータ取得にかかる時間を短縮することができる。

本発明によるネットワーク構成図。 データ取得シーケンス。 データ配布シーケンス。 データ取得装置構成図。 インデクス保持装置一覧の例。 インデクス検索要求フローチャート。 データ取得機能フローチャート。 ブラックリスト処理フローチャート。 データ配布装置構成図。 データ登録要求フローチャート。 データ転送フローチャート。 インデクス保持装置構成図。 インデクスの例。 インデクス保持装置ＩＰアドレス表の例。 ブラックリストの例。 拇印保持装置ＩＰアドレス表の例。 拇印表。 ユーザ統計表。 ユーザ情報表の例。 検索応答フローチャート。 インデクス保持ネットワーク内インデクス検索フローチャートその１。 インデクス保持ネットワーク内インデクス検索フローチャートその２。 データ転送記録機能フローチャートその１。 データ転送記録機能フローチャートその２。 データ登録応答フローチャート。 インデクス保持ネットワーク内インデクス登録フローチャートその１。 インデクス保持ネットワーク内インデクス登録フローチャートその２。 ログオンシーケンス。 データ配布ネットワークへのログオンフローチャート。 ログオン受付機能フローチャート。 データを２つのピースに分けたときのインデクスの例。 ユーザ管理装置構成図。 ユーザ管理装置を利用するときのネットワーク構成。 ユーザ管理装置を利用するときのログオン処理シーケンス。 ユーザ管理装置を利用するときのデータ取得シーケンス。 ユーザがデータを改ざんした場合の動作。 データ配布者が悪意あるデータを配布した場合の動作。

符号の説明

１１０ 本発明によるデータ取得装置
１１１ 本発明によるデータ配布装置
１２１ 本発明によるインデクス保持装置
１２１１ 各データの情報と所在を保持する表
１２１３ ｕｉｄをキーとしてｖｉｄ，ＩＰアドレスおよび該ユーザが取得可能な配布者識別子リストの対応関係を示す表
１２１５ インデクス保持装置が保持するブラックリスト
１２１７ 登録されて配布中であるデータの拇印を示す表
１２１８ ユーザのデータ取得回数などを示す表
１５０１ 配布者ブラックリストの例
１５０２ データブラックリストの例
１５０３ ユーザブラックリストの例。

Claims (20)

1. データを保持する少なくとも一つのデータ配布装置と少なくとも一つのデータ取得装置，および前記データの所在情報を保持する単一または複数のインデクス保持装置からなり，前記データ取得装置間，または前記データ取得装置と前記データ配布装置間で相互にデータを交換するデータ配布システムにおいて，
   前記データ配布装置は，あらかじめ割り当てられた固有の配布者識別子を含む，配布するデータの属性を前記インデクス保持装置に登録する手段を備え，
   前記データ取得装置は，前記配布者識別子と前記データのデータ名を用いて前記データの所在の検索を要求し，前記検索されたデータを取得する手段を備え，
   さらに，前記インデクス保持装置は，前記データ取得装置において，該取得したデータが悪意あるデータであると判断された場合に，該データを管理するデータブラックリストを保持する手段を備え，前記データブラックリストに載っているデータに対する検索に対して前記データが存在しないと応答することを特徴とするデータ配布システム。
2. 前記インデクス保持装置において，
   前記配布者識別子と前記データを配布する配布者のユーザ識別子との対応関係を保持する手段と，
   前記配布されるデータの属性を登録する際に前記データ配布装置から送信される前記配布者識別子と前記ユーザ識別子の対応が，前記対応関係と一致するか否かを照合する手段と，
   前記配布されたデータの所在情報を前記配布者識別子で管理する手段と，
   前記配布されたデータの所在を検索する際に，前記配布者識別子と前記データ名で検索する手段と、を備えることを特徴とする請求項１記載のデータ配布システム。
3. 前記データ取得装置は，
   前記データ登録の際に前記データ配布装置から通知され前記インデクス保持装置に保持される前記データの拇印を取得する手段と，
   前記取得したデータの拇印を作成する手段と，
   前記２種類の拇印を比較する手段とを備え，
   さらに前記２種類の拇印が異なっている場合に前記取得したデータを廃棄する手段と，
   前記データの配布者を示す配布者識別子，前記データ識別子及び取得元のユーザ識別子を前記インデクス保持装置に通知する手段を備えることを特徴とする請求項１記載のデータ配布システム。
4. 前記インデクス保持装置は、
   前記通知によって得られる前記配布者識別子を管理する，配布者ブラックリストを保持する手段を備え，前記配布者ブラックリストに登録されている前記配布者識別子に対応するユーザによる，前記インデクス保持装置へのデータの登録を拒否する手段を備えることを特徴とする請求項３記載のデータ配布システム。
5. 前記インデクス保持装置は、
   前記通知によって得られる前記ユーザ識別子を管理する，ユーザブラックリストを保持する手段と，前記ユーザブラックリストに登録されているユーザの該データ配布システムへのログオンを拒否する手段を備えることを特徴とする請求項３記載のデータ配布システム。
6. 前記データ配布装置および前記データ取得装置は保持しているデータを別のデータ取得装置に送信した場合に前記データの配布者識別子と前記データ名と送信相手の前記ユーザ識別子を前記インデクス保持装置に通知する手段を備え，
   前記インデクス保持装置は，前記通知された前記配布者識別子を単位として前記データ識別子と前記ユーザ識別子と，前記データの転送が行われた回数を記録し保持する手段を備えることを特徴とする請求項６記載のデータ配布システム。
7. 前記データ配布装置から通知された前記データ名についても前記データブラックリストに登録する手段を備えることを特徴とする請求項３記載のデータ配布システム。
8. 前記配布するデータを２以上のピースに分割し，前記配布するデータの属性を前記ピース毎に前記インデクス保持装置に登録し，前記データ取得装置は該ピースごとに前記データ取得することを特徴とする請求項1記載のデータ配布システム。
9. 前記データの属性は，少なくとも前記データ登録の際に前記データ配布装置から通知された拇印，該ピースを取得したユーザの前記ユーザ識別子および該ピースを取得した装置のＩＰアドレスを含むことを特徴とする請求項８記載のデータ配布システム。
10. 前記データの属性に該ピースの伝送が行われた回数を含むことを特徴とする請求項９に記載のデータ配布システム。
11. さらにユーザ管理装置を備え，
    前記通知を前記ユーザ管理装置にも通知し，前記ユーザ管理装置において，前記通知によって得られる前記ユーザ識別子を管理するユーザブラックリストを保持する手段と，前記ユーザブラックリストに載っているユーザの該データ配布システムへのログオンを拒否する手段を備えることを特徴とする請求項３記載のデータ配布システム。
12. データを保持する少なくとも一つのデータ配布装置および少なくとも一つのデータ取得装置と，前記データ取得装置間，または前記データ取得装置と前記データ配布装置間で相互にデータを交換するデータ配布ネットワークを介して接続される，前記データの所在情報を保持する単一または複数のインデクス保持装置であって，
    前記データ配布装置から通知された、前記データ配布装置にあらかじめ割り当てられた固有の配布者識別子を含む，配布するデータの属性を保持する手段と，
    前記データ取得装置から要求された前記配布者識別子と前記データ名を用いて前記データの所在の検索を要求し，前記検索されたデータの所在を前記データ取得装置に通知する手段とを備え，
    さらに，前記データ取得装置において該取得したデータが悪意あるデータであると判断された場合に該データを管理するデータブラックリストを保持する手段を備え，
    前記データブラックリストに登録されているデータに対する検索に対して前記データが存在しないと応答することを特徴とするインデクス保持装置。
13. 前記配布者識別子と前記データを配布する配布者のユーザ識別子との対応関係を保持する手段と，
    前記配布されるデータの属性を登録する際に前記データ配布装置から送信される前記配布者識別子と前記ユーザ識別子の対応が，前記対応関係と一致するかどうか照合する手段を備え，
    さらに，前記配布されたデータの所在情報を前記配布者識別子で管理する手段を備え，
    前記配布されたデータの所在を検索する際に，前記配布者識別子と前記データ名で検索する手段を備えることを特徴とする請求項１２記載のインデクス保持装置。
14. 前記データ登録の際に前記データ配布装置から通知された前記データの拇印を保持する手段と，
    前記データ取得装置からの検索要求に対し前記拇印を通知するする手段と，
    前記データ取得装置において，該拇印と取得したデータから作成された拇印とを比較し，前記２種類の拇印が異なっていると判断された場合に，前記データの配布者を示す配布者識別子，前記データ識別子と取得元の前記ユーザ識別子を保持する手段を備えることを特徴とする請求項１２記載のインデクス保持装置。
15. 前記通知によって得られる配布者識別子を管理する配布者ブラックリストを保持する手段と，
    前記配布者ブラックリストに載っている前記配布者識別子に対応するユーザによる，前記データの登録を拒否する手段を備えることを特徴とする請求項１４記載のインデクス保持装置。
16. 前記通知によって得られる前記ユーザ識別子を管理するユーザブラックリストを保持する手段と，
    前記ユーザブラックリストに登録されているユーザの該データ配布ネットワークへのログオンを拒否する手段を備えることを特徴とする請求項１４記載のインデクス保持装置。
17. 前記データ配布装置および前記データ取得装置において保持しているデータを別のデータ取得装置に送信した場合，前記データ配布装置および前記データ取得装置から通知された前記データの配布者識別子と前記データ名と送信相手の前記ユーザ識別子を，前記配布者識別子を単位として前記データ名と前記ユーザ識別子と，前記データの転送が行われた回数を記録し保持する手段を備えることを特徴とする請求項１２記載のインデクス保持装置。
18. 前記データ配布装置から通知された前記データ名についても前記データブラックリストに登録する手段を備えることを特徴とする請求項１２記載のインデクス保持装置。
19. データを保持する少なくとも一つのデータ配布装置、少なくとも一つのデータ取得装置，および前記データの所在情報を保持する単一または複数のインデクス保持装置を有し，前記データ取得装置間，または前記データ取得装置と前記データ配布装置間で相互に前記データを交換するデータ配布システムにおいて，
    前記データ配布装置は，あらかじめ割り当てられた固有の配布者識別子を含む，配布するデータの属性を前記インデクス保持装置に登録する手段を備え，
    前記データ取得装置は，前記配布者識別子と前記データのデータ名を用いて前記データの所在を検索し，前記検索された前記データを取得する手段を備え，
    前記インデクス保持装置は，
    前記データの取得が許可されたユーザの、各ユーザに割り当てられたユーザ識別子に対して前記配布者識別子を登録する配布者識別子リストを保持する手段と，
    該データに対する検索要求に対し，該検索要求メッセージに含まれる前記ユーザ識別子に対応する前記配布者識別子が，前記配布者識別子リストに存在するか否かを確認する手段を備え，
    前記配布者識別子リストに該検索要求メッセージに含まれる前記ユーザ識別子に対応する前記配布者識別子が存在しないと確認した場合に，前記検索を要求したユーザに検索不可能と応答することを特徴とするデータ配布システム。
20. データを保持する少なくとも一つのデータ配布装置および少なくとも一つのデータ取得装置と，前記データ取得装置間，または前記データ取得装置と前記データ配布装置間で相互にデータを交換するデータ配布ネットワークを介して接続される，前記データの所在情報を保持する単一または複数のインデクス保持装置であって，
    前記データ配布装置から通知された前記データ配布装置にあらかじめ割り当てられた固有の配布者識別子を含む，配布するデータの属性を保持する手段と，
    前記データ取得装置から要求された前記配布者識別子と前記データ名を用いて前記データの所在を検索し，前記検索されたデータの所在を前記データ取得装置に通知する手段と、
    さらに、前記データの取得が許可されたユーザの、各ユーザに割り当てられたユーザ識別子に対して前記配布者識別子を登録する配布者識別子リストを保持する手段と，
    該データに対する検索要求に対し，該検索要求メッセージに含まれる前記ユーザ識別子に対応する前記配布者識別子が，前記配布者識別子リストに存在するか否かを確認する手段を備え、
    前記配布者識別子リストに該検索要求メッセージに含まれる前記ユーザ識別子に対応する前記配布者識別子が存在しないと確認した場合に，前記検索を要求したユーザに検索不可能と応答することを特徴とするインデクス保持装置。

Images