【課題】コンテンツ配信システムにおいて配信される暗号化されたコンテンツが不正に復号されることを抑制可能な配信技術を提供する。
【解決手段】リーチャ５０Ａは、販売サーバ５４からTorrent Fileを受信し、当該Torrent Fileに基づいて、トラッカ５１にアクセスしてノード情報を取得し、ノード情報に基づいて、シーダ５２Ａ〜５２Ｃやリーチャ５０Ｂの少なくとも１つにアクセスして各暗号化ピースを受信して、各ピースに各々対応する全ての暗号化ピースを取得し、各暗号化ピースを各々復号するための各復号鍵を含む鍵束を鍵サーバ５３から受信する。

【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、暗号鍵を用いて暗号化された暗号化コンテンツを、他の通信装置から受信する通信装置、暗号化コンテンツを復号するための復号鍵を送信する鍵サーバ、通信装置が他の通信装置へアクセスするための情報を記憶する管理サーバ、通信サーバ、通信方法及びプログラムに関する。
【背景技術】
【０００２】
一般に、コンテンツを配信するシステムには、「単一サーバ型」と「分散サーバ型」とがある。単一サーバ型のシステムでは、例えば、１つのコンテンツサーバと、ライセンスサーバと、クライアントとがネットワークを介して接続され、コンテンツサーバからコンテンツが各クライアントに配信される。配信されるコンテンツは暗号化されており、この暗号化に係る鍵情報をライセンスサーバが有している。コンテンツサーバでは、コンテンツはE( KT )[ C ]として保持される。ただし、KTはタイトル鍵と呼ばれる鍵であり、Cは平文のコンテンツである。E( KT )[ C ]はCがKTで暗号化されていることを示す。鍵情報にはKTが含まれている。クライアントＢは、鍵情報をライセンスサーバから取得し、当該鍵情報を、当該クライアント（クライアントＢとする）固有の鍵KBを用いて暗号化し、これをコンテンツサーバから受信したコンテンツE( KT )[ C ]と関連づけて保持する。そして、クライアントＢは、鍵KBを用いて鍵情報を復号して、タイトル鍵KTを取り出し、当該タイトル鍵KTを用いてE( KT )[ C ]を復号することにより、コンテンツを利用することができる。
【０００３】
このような構成において、クライアントＢは、コンテンツサーバからコンテンツE( KT )[ C ]をダウンロードする際、認証及び鍵交換を互いに行う。この結果、クライアントＢは、一時鍵KtmpBを共有する。コンテンツサーバは、一時鍵KtmpBを用いてコンテンツE( KT )[ C ]を暗号化し、コンテンツE( KtmpB )[ E( KT )[ C ]]をクライアントＢに送信する。クライアントＢは、上述の認証及び鍵交換によってコンテンツサーバと共有している一時鍵KtmpBを用いてコンテンツE( KtmpB )[ E( KT )[ C ]]を復号して、E( KT )[ C ]を取り出す。このような構成においては、ネットワークの経路上で、暗号化されたコンテンツE( KtmpB )[ E( KT )[ C ] ]が不正に読み取られたとしても、不正に読み取られたものは一時鍵KtmpBがなければ復号することができない。即ち、クライアント毎に異なる一時鍵を用いてコンテンツを暗号化することにより、同一のコンテンツをクライアント毎に個別化し、これにより、コンテンツの不正使用を抑制することができる。例えば、クライアントＡに対する一時鍵KtmpAとクライアントＢに対する一時鍵KtmpBとを異ならせることにより、クライアントＡに配信されるコンテンツE( KtmpA )[ E( KT )[ C ] ]と、クライアントＢに配信されるコンテンツE( KtmpB )[ E( KT )[ C ] ]とは異なる個別のデータとなる。このように同一のコンテンツを暗号鍵の相違により個別化することにより、コンテンツの不正使用を抑制することができる。
【０００４】
しかし、単一サーバ型のシステムでは、クライアントとコンテンツサーバとの１対１での通信となるため、多くのクライアントがコンテンツサーバからコンテンツの配信を受けようとすると、配信効率が悪くなるという問題がある。
【０００５】
一方、分散サーバ型のシステムには、例えば、Ｐ２ＰによるBitTorrentというコンテンツ配信システムがある（例えば、非特許文献１参照）。このようなシステムにおいては、コンテンツ毎に異なるトラッカと、シーダと、リーチャとがＰ２Ｐで各々接続される。また、配信されるコンテンツは、複数のピースに分割されている。シーダは、コンテンツの配信（アップロード）を目的として、コンテンツを構成するピースを配信するノードである。リーチャは、コンテンツの受信（ダウンロード）を目的として、コンテンツを構成する各ピースの受信とコンテンツを構成するピースの配信とを行うノードである。即ち、リーチャはコンテンツを構成するピースをある程度取得するとシーダになる場合がある。このように、シーダには、コンテンツを構成する全部のピース又は一部のピースを受信したリーチャがシーダへ変化したものと、システム側で（予め又は配信の途中に）用意される（最初からシーダである）ものとがある。後者を初期シーダと呼ぶ。初期シーダは、あるひとつのコンテンツを構成し得る全てのピース又は一部のピースを保持している。以降、特に断りのない限り、シーダとはシーダ又は初期シーダを意味するものとし、ノードとはリーチャ、シーダ、又は初期シーダを意味するものとする。トラッカは、各ノードに関するノード情報を保持しており、リーチャからアクセスがあった場合、ノード情報をリーチャに提供する。
【０００６】
このような構成において、あるリーチャがコンテンツの配信を受ける場合、まず、Torrent Fileと呼ばれる情報を取得する。Torrent Fileは、例えば、コンテンツプロバイダ又はユーザにコンテンツを販売するサービスを運用するサーバ（販売サーバと呼ぶ））から、他ノード又は販売サーバへ与えられ、さらに他ノード又は販売サーバからリーチャへ与えられる。この他に、例えばＣＤ−ＲＯＭなどの記録媒体に記録されたTorrent Fileをオフラインでリーチャへ配布される場合もある。Torrent Fileには、コンテンツに関するトラッカ情報と、当該コンテンツのファイル情報とが格納されている。トラッカ情報はトラッカの接続先を含んでいる。ファイル情報は、例えば、コンテンツを構成する各ピースのハッシュ情報を含んでいる。ハッシュ情報は、ピースの完全性を確認するために用いられる。即ち、ハッシュ情報は、リーチャがダウンロードしたピースのハッシュを計算し、当該ピースのハッシュ値と照合して、受信したピースが改竄されていないことを確認するのに用いられる。
【０００７】
リーチャは、このようなTorrent Fileを取得すると、トラッカ情報に基づいてトラッカに接続する。トラッカは、リーチャに上述のノード情報を送信する。ノード情報は単数または複数のノードの接続先のリストを含んでいる。リーチャはノード情報に基づいて、複数のノードに接続する。各ノードが配信するピースは、ノード毎に異なっている場合が多い。リーチャは、複数のノードから異なるピースを受信することができるので、コンテンツの高速な受信が可能である。
【０００８】
このように、Ｐ２Ｐによるコンテンツ配信システムでは、コンテンツは複数のノードに分散して保持されている。従って、このようなシステムにおいては、コンテンツの配信を受けるノードが多くても、Ｐ２Ｐにより複数の他のノードからコンテンツの配信を受けることができるため、単一サーバ型のシステムに比べて配信効率が良い。
【０００９】
また、特許文献１には、コンテンツを複数のピースに分割し、それら複数のピースのそれぞれについて、複数の暗号鍵を用いて暗号化して複数の暗号化ピースを生成するコンテンツ配信方法が開示されている。
【００１０】
【非特許文献１】Bittorrent Protocol Specification v1.0
【特許文献１】特許第３９１７３９５号公報
【発明の開示】
【発明が解決しようとする課題】
【００１１】
しかし、非特許文献１に記載されているような複数のノードからコンテンツを配信し得るコンテンツ配信システムにおいても、コンテンツの不正使用を抑制するためには、配信するコンテンツを暗号化によって保護することが望ましい。しかし、このようなコンテンツ配信システムでは、単一サーバ型のシステムとは異なり、各リーチャがシーダから受信する同一のコンテンツは、暗号化された状態であっても同一でなければならず、リーチャ毎に個別に暗号化したコンテンツを配信することは難しかった。このため、暗号化されたコンテンツを復号するための鍵が１つ曝露されてしまうと、ネットワーク上に多数存在するコンテンツが全て復号可能になってしまうという恐れがあった。
【００１２】
また、特許文献１に記載のコンテンツ配信方法では、コンテンツの配信を受ける各ユーザが全ての暗号化ピースを取得する必要がある。このため、このコンテンツ配信方法をＰ２Ｐによるコンテンツ配信システムへそのまま応用した場合、配信効率が悪くなる恐れがある。更に、暗号化されたコンテンツを復号するための鍵が複数であっても、それらが曝露されてしまった場合、復号鍵を正規に取得することなしにコンテンツが復号可能になってしまうという恐れがある。
【００１３】
本発明は、上記に鑑みてなされたものであって、コンテンツ配信システムにおいて配信される暗号化されたコンテンツが不正に復号されることを抑制可能な通信装置、鍵サーバ、管理サーバ、通信サーバ、通信方法及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１４】
上述した課題を解決し、目的を達成するために、本発明は、コンテンツの一部である複数のピースを受信する通信装置であって、複数の第１暗号化ピースは、前記複数のピースを第１暗号鍵で暗号化することによって生成されるものであって、第２暗号化ピースは、前記複数のピースのうち１つ以上のピースを第２暗号鍵で暗号化することによって生成されるものであって、同一のピースを暗号化するための前記第１暗号鍵と前記第２暗号鍵とは異なっていて、他の通信装置から、前記第１暗号化ピース又は前記第２暗号化ピースをピース毎に受信するコンテンツ受信手段と、前記コンテンツ受信手段がピース毎に受信した前記第１暗号化ピース又は前記第２暗号化ピースを復号するための各復号鍵を要求する要求メッセージを、当該各復号鍵を記憶する鍵サーバに送信する鍵要求送信手段と、前記要求メッセージに従った前記鍵サーバから前記各復号鍵を受信する鍵受信手段とを備えることを特徴とする。
【００１５】
また、本発明は、コンテンツの一部である複数のピースを送信する通信装置であって、
複数の第１暗号化ピースは、前記複数のピースを第１暗号鍵で暗号化することによって生成されるものであって、第２暗号化ピースは、前記複数のピースのうち１つ以上のピースを第２暗号鍵で暗号化することによって生成されるものであって、同一のピースを暗号化するための前記第１暗号鍵と前記第２暗号鍵とは異なっていて、前記第１暗号化ピース又は前記第２暗号化ピースをピース毎に記憶する記憶手段と、前記第１暗号化ピース又は前記第２暗号化ピースのデータのうち一部又は全部を要求するピース要求を他の通信装置から受信する要求受信手段と、前記ピース要求によって要求された前記第１暗号化ピース又は前記第２暗号化ピースのデータのうち一部又は全部を前記他の通信装置に送信する送信手段とを備えることを特徴とする。
【００１６】
また、本発明は、コンテンツの一部である複数のピースを受信する通信装置と通信する鍵サーバであって、複数の第１暗号化ピースは、前記複数のピースを第１暗号鍵で暗号化することによって生成されるものであって、第２暗号化ピースは、前記複数のピースのうち１つ以上のピースを第２暗号鍵で暗号化することによって生成されるものであって、
同一のピースを暗号化するための前記第１暗号鍵と前記第２暗号鍵とは異なっていて、
前記通信装置は、他の通信装置から、前記第１暗号化ピース又は前記第２暗号化ピースをピース毎に受信するものであって、前記通信装置から、ピース毎の前記第１暗号化ピース又は前記第２暗号化ピースを復号するための各復号鍵を要求する要求メッセージを受信する受信手段と、前記各復号鍵を記憶する第１記憶手段と、前記要求メッセージによって要求された前記各復号鍵の組み合わせに基づいて、当該各復号鍵を送信するか否かを決定する決定手段と、前記決定手段の決定結果が肯定的である場合、前記要求メッセージによって要求された前記組み合わせにおける前記各復号鍵を前記第１記憶手段から各々読み出してこれらを前記通信装置に送信する鍵送信手段とを備えることを特徴とする。
【００１７】
また、本発明は、コンテンツの一部である複数のピースを受信する通信装置と通信する管理サーバであって、複数の第１暗号化ピースは、前記複数のピースを第１暗号鍵で暗号化することによって生成されるものであって、第２暗号化ピースは、前記複数のピースのうち１つ以上のピースを第２暗号鍵で暗号化することによって生成されるものであって、同一のピースを暗号化するための前記第１暗号鍵と前記第２暗号鍵とは異なっていて、前記通信装置は、他の通信装置から、前記第１暗号化ピース又は前記第２暗号化ピースをピース毎に受信するものであって、前記他の通信装置にアクセスするための接続先情報を記憶する第１記憶手段と、前記複数のピースのうち少なくとも１つのピースについて、当該少なくとも１つのピースが暗号化された前記第１暗号化ピース又は前記第２暗号化ピースを決定する決定手段と、前記通信装置に対して、前記他の通信装置にアクセスするための接続先情報を前記第１記憶手段から読み出してこれと、決定された前記第１暗号化ピース又は前記第２暗号化ピースを指定するシーダ情報とを送信する送信手段とを備えることを特徴とする。
【００１８】
また、本発明は、コンテンツの一部である複数のピースを受信する通信装置と通信する通信サーバであって、複数の第１暗号化ピースは、前記複数のピースを第１暗号鍵で暗号化することによって生成されるものであって、第２暗号化ピースは、前記複数のピースのうち１つ以上のピースを第２暗号鍵で暗号化することによって生成されるものであって、
第３暗号化ピースは、前記複数のピースのうち１つ以上のピースを第３暗号鍵で暗号化することによって生成されるものであって、同一のピースを暗号化するための前記第１暗号鍵と前記第２暗号鍵と前記第３暗号鍵とは異なっていて、前記通信装置は、他の通信装置から、前記第１暗号化ピース又は前記第２暗号化ピースをピース毎に受信するものであって、前記第３暗号化ピースを記憶する第１記憶手段と、前記第３暗号化ピースを前記通信装置に送信した場合に当該通信装置を識別するための識別情報を記憶する第２記憶手段と、前記第３暗号化ピースを要求すると共に前記通信装置を識別するための識別情報を含む特別ピース要求を前記通信装置から受信する第１受信手段と、前記特別ピース要求に含まれる前記識別情報が前記第２記憶手段に記憶されていない場合、前記第１記憶手段から前記第３暗号化ピースを読み出して前記通信装置に送信する第１送信手段とを備えることを特徴とする。
【発明の効果】
【００１９】
本発明によれば、コンテンツ配信システムにおいて配信される暗号化されたコンテンツを受信装置毎に個別化することができるため、配信される暗号化されたコンテンツが不正に復号されることを抑制することができる。
【発明を実施するための最良の形態】
【００２０】
以下に添付図面を参照して、この発明にかかる通信装置、鍵サーバ、管理サーバ、通信サーバ、通信方法及びプログラムの最良な実施の形態を詳細に説明する。
【００２１】
[第１の実施の形態]
（１）構成
＜コンテンツ配信システムの構成＞
図１は、本実施の形態にかかるコンテンツ配信システムの構成を示すブロック図である。本実施の形態にかかるコンテンツ配信システムにおいては、リーチャ５０Ａ〜５０Ｂと、トラッカ５１と、シーダ５２Ａ〜５２Ｃと、販売サーバ５４とが各々Ｐ２ＰネットワークＮＴを介して接続されている。リーチャ５０Ａ〜５０Ｂと、鍵サーバ５３とは各々、図示しないインターネットなどのネットワークを介して接続される。ここでノードとは、リーチャ５０Ａ〜５０Ｂと、シーダ５２Ａ〜５２Ｃとである。シーダ５２Ａ〜５２Ｃは、複数のピースに分割されたコンテンツについて、各ピースが各々異なる暗号鍵で暗号化された各暗号化ピースを保持している。尚、以降、このような暗号化ピースから構成されるコンテンツを暗号化コンテンツという。このような暗号化コンテンツの詳細については後述する。シーダ５２Ａ〜５２Ｃのうち、シーダ５２Ａは、上述した初期シーダとして機能する。シーダ５２Ａは、一つのコンテンツを構成する各ピースについて、同一のピースに対して複数の暗号鍵を用いて各々暗号化されて生成された暗号化ピースの全てを保持している。トラッカ５１は、各ノードにアクセスするためのノード情報を保持している。尚、各ノードには各々、ノード識別情報が付与されているものとする。ノード識別情報とは、各ノードを一意に識別可能な識別情報であり、例えば、各ノードのＩＰアドレスである。鍵サーバ５３は、各暗号化ピースを復号するための復号鍵を保持している。販売サーバ５４は、Torrent Fileを保持している。
【００２２】
リーチャ５０Ａは、販売サーバ５４からTorrent Fileを受信し、当該Torrent Fileに基づいて、トラッカ５１にアクセスしてノード情報を取得し、ノード情報に基づいて、シーダ５２Ａ〜５２Ｃやリーチャ５０Ｂの少なくとも１つにアクセスして各暗号化ピースを受信して、各ピースに各々対応する全ての暗号化ピースを取得し、各暗号化ピースを各々復号するための各復号鍵を含む鍵束を鍵サーバ５３から受信する。リーチャ５０Ｂについても同様である。尚、以降、リーチャ５０Ａ〜５０Ｂを各々区別する必要がない場合、単にリーチャ５０と記載する。シーダ５２Ａ〜５２Ｃを各々区別する必要がない場合も、単にシーダ５２と記載する。
【００２３】
ここで、コンテンツの構成について説明する。コンテンツとは、種々のデジタルデータ、例えばMPEG2やMPEG4等の動画データや音声データの他、テキストデータや静止画データ等を指し、また、これらのデジタルデータが暗号化されているものもコンテンツと呼ぶ。例えば、HD DVD Prepared Video ContentをAACS(Advanced Access Content System)仕様に従って暗号化したものもコンテンツである。ここでは、コンテンツ全体をＣと表すものとする。Ｃは平文であっても暗号化されていても構わない。図２は、コンテンツが複数のピースに分割された状態を模式的に示す図である。例えば、コンテンツＣは、ある１つのコンテンツをＮ（N＞１）個のピースＣ１〜ＣＮに分割される。各ピースＣ１，Ｃ２，・・・ＣＮのデータ長は全て同一であっても良いし、そうでなくても良い。これらのＮ個の各ピースＣ１〜ＣＮについては、各々異なる暗号鍵で暗号化される。このとき、Ｎ個のうちａ個のピースについては、同一のピースに対して、各々異なるｍ個の暗号鍵（第１暗号鍵及び第２暗号鍵）で暗号化される。残りの（Ｎ-ａ）個のピースについては、同一のピースに対して１つの暗号鍵（第１暗号鍵）で暗号化される。即ち、ａ個の各ピースについては、同一のピースがｍ個の異なる暗号鍵で各々暗号化されてｍ個の異なるピース（暗号化ピース）が生成される。（Ｎ-ａ）個の各ピースについては、各々１つの暗号鍵で暗号化して、１つのピースに対して１つの暗号化ピースが生成される。図３は、各暗号化ピースを模式的に示す図である。このａ個の各ピースに各々対応して、ｍ個の暗号化ピースの中から各々１つ選択される暗号化ピースの組み合わせを異ならせることにより、Ｎ個の暗号化ピースから構成される暗号化コンテンツ全体を個別化することができる。
【００２４】
次に、リーチャ５０と、トラッカ５１と、シーダ５２と、鍵サーバ５３との各装置のハードウェア構成について説明する。各装置は各々、装置全体を制御するＣＰＵ（Central Processing Unit）等の制御装置と、各種データや各種プログラムを記憶するＲＯＭ（Read Only Memory）やＲＡＭ（Random Access Memory）等の記憶装置と、各種データや各種プログラムを記憶するＨＤＤ（Hard Disk Drive）やＣＤ（Compact Disk）ドライブ装置等の外部記憶装置と、これらを接続するバスとを備えており、通常のコンピュータを利用したハードウェア構成となっている。また、各装置には各々、情報を表示する表示装置と、ユーザの指示入力を受け付けるキーボードやマウス等の入力装置と、外部装置の通信を制御する通信Ｉ／Ｆ（interface）とが有線又は無線により接続される。
【００２５】
＜シーダ５２の構成＞
次に、上述したハードウェア構成において、シーダ５２のＣＰＵが記憶装置や外部記憶装置に記憶された各種プログラムを実行することにより実現される各種機能について説明する。シーダ５２は、コンテンツＣを構成する複数のピースＣ１〜ＣＮが各々暗号化された各暗号化ピースを、各ピースＣ１〜ＣＮを各々復号するための各復号鍵のインデックス（添え字）と対応付けて記憶している。尚、各復号鍵は、各暗号鍵と同一であっても良いし、各暗号鍵と異なるものであっても良い。いずれにしろ、各ピースＣ１〜ＣＮは各々暗号鍵で暗号化されているため、これらの各暗号化ピースを復号するための復号鍵のそれぞれについて、各復号鍵のインデックスを用いて、各暗号化ピースを特定することができる。このような各暗号化ピースは例えば外部記憶装置に記憶される。
【００２６】
以下簡単のため、暗号鍵と復号鍵が同一の場合で説明する。復号鍵のインデックスを、( i, j )で表し、復号鍵を、K ( i, j )で表すとすると、各暗号化ピースは、例えば、以下のように表される。
E( K( i, j) )[ Cj ]
（ただし、i, jは整数、1≦i≦m、1≦j≦N（m＞1）、相異なるインデックス( i, j)、( i’, j’) (( i, j)≠( i’, j’))についてK( i, j)= K( i’, j’)であってもよい。）
【００２７】
このような各暗号化ピースから構成される暗号化コンテンツは、例えば、以下のように表される。
{ E( K( i1, 1 ) )[ C1 ], E( K( i2, 2 ) )[ C2 ], …, E( K( iN, N ))[ CN ]}
（ただし、1≦i1, …, iN≦m）
【００２８】
このような暗号化コンテンツにおける各暗号化ピースのシーケンスは、各暗号化ピースのインデックスの組み合わせにより表され、例えば以下のように表される。ここでは、各ピースＣ１〜ＣＮに各々対応するインデックスが左から順に配列されて表されている。
{ ( i1, 1 ), ( i2, 2 ), …, ( iN, N) }
（ただし、1≦i1, …, iN≦m）
【００２９】
従って、シーダ５２が各暗号化ピースとインデックスとを対応付けて記憶するものは、例えば、以下のように表される。
{ ( E( K( i1, 1) )[ C1 ], ( i1, 1 ) ), ( E( K( i2, 2) )[ C2 ], ( i2, 2 ) ), …,( E( K( iN, N) )[ CN ], ( iN, N ) ) }
（ただし、1≦i1, …, iN≦m）
【００３０】
更に、初期シーダであるシーダ５２Ａは、コンテンツを構成する各ピースに各々対応する各暗号化ピースについて、同一のピースに対して複数の暗号鍵により各々暗号化されて生成された暗号化ピースの全てを記憶している。図４は、シーダ５２Ａが記憶している各暗号化ピースを例示する図である。同図においては、Ｎ個のうちa個（1<a<N）のピースについて、同一のピースに対して複数の異なる暗号鍵で各々暗号化されていることが示されている。同図においては、同一のピースの暗号化に用いられる暗号鍵の個数は、ピース毎に異なっている。ピースＣ１に対する暗号鍵の個数はｍ個であり、ピースＣ３に対する暗号鍵の個数は２個である。但し、本実施の形態においては、同一のピースの暗号化に用いられる暗号鍵の個数はピース毎に同じであっても良い。ピース処理装置では、このように、Ｎ個のうちa個（1<a<N）のピースについて、同一のピースに対して複数の異なる暗号鍵で各々暗号化することにより、例えば、重要度の高いほど暗号鍵の数を増やすようにすることができる。
【００３１】
尚、本実施の形態においては、これに限らず、例えば、図５に示されるように、「a=N」の場合、即ち、Ｎ個全てのピースについて、同一のピースに対してｍ個の異なる暗号鍵で各々暗号化されていても良い。このような構成によれば、暗号化ピースのシーケンスのバリエーションを多くすることができる。また、図６に示されるように、「a=1」の場合、即ち、Ｎ個のうち1個のピースのみ、ｍ個の異なる暗号鍵で暗号化されていても良い。このような構成によれば、配信効率を向上させることができる。
【００３２】
このような構成において、シーダ５２は、リーチャ５０からのアクセスにより、当該シーダ５２が記憶している暗号化ピースのシーケンスを示すピース情報をリーチャ５０に送信する。図７は、ピース情報のデータ構成を例示する図である。同図においては、ピースＣ１に対応する暗号化ピースについては、復号鍵K(1, 1 )により復号されることが示され、ピースＣ２に対応する暗号化ピースについては、復号鍵K(3, 2 ) により復号されることが示されている。即ち、ピース情報によって、各暗号化ピースと各暗号化ピースの復号化のための復号鍵の対応関係とが示される。シーダ５２は、当該ピース情報に基づいて暗号化ピースを要求するピース要求をリーチャ５０から受信すると、要求された暗号化ピースを保持しているか否かを判断し、当該判断結果が肯定的である場合に、当該暗号化ピースをリーチャ５０に送信する。
【００３３】
＜リーチャ５０の構成＞
次に、上述したハードウェア構成において、リーチャ５０のＣＰＵが記憶装置や外部記憶装置に記憶された各種プログラムを実行することにより実現される各種機能について説明する。図８は、リーチャ５０の機能的構成を例示する図である。リーチャ５０は、コンテンツ取得部５００と、鍵束要求部５０１と、鍵束取得部５０２と、コンテンツ復号部５０３とを有する。これら各部の実体は、ＣＰＵのプログラム実行時にＲＡＭなどの記憶装置上に生成されるものである。
【００３４】
コンテンツ取得部５００は、Ｐ２ＰネットワークＮＴを介して、暗号化コンテンツを構成する各暗号化ピースをシーダ５２の少なくとも１つから受信する。具体的には、コンテンツ取得部５００は、まず、販売サーバ５４からTorrent Fileを受信する。Torrent Fileは、トラッカ５１に接続するためのトラッカ接続先情報を含むトラッカ情報と、暗号化コンテンツを構成する各暗号化ピースとしてどのようなものがあるかを示すファイル情報とを含んでいる。図９は、Torrent Fileを例示する図である。同図においては、ファイル情報として、各暗号化ピースを特定するための情報として、各暗号化ピースに対応するインデックスが各々示されている。トラッカ接続先情報は、例えば、トラッカ５１のＩＰアドレスや、ＵＲＬなどである。
【００３５】
コンテンツ取得部５００は、Torrent Fileに基づいて、Ｐ２ＰネットワークＮＴを介してトラッカ５１にアクセスして、Ｐ２ＰネットワークＮＴに接続されているノード（シーダ５２、他のリーチャ５０）にアクセスするためのノード情報を当該トラッカ５１から受信する。ノード情報の詳細については後述する。そして、コンテンツ取得部５００は、ノード情報に基づいて、ノードの少なくとも１つにアクセスして、当該ノードが記憶している自身の保持する暗号化ピースのシーケンスを示すピース情報を取得する。そして、コンテンツ取得部５００は、ピース情報に基づいて、暗号化コンテンツを構成する各暗号化ピースを要求するピース要求をノードの少なくとも１つに送信し、当該ピース要求に応じて送信される暗号化ピースを受信することにより、暗号化コンテンツを構成する全ての暗号化ピース（ピースシーケンス）を取得する。例えば、図３に示した各暗号化ピースのうち、網掛けされた全ての暗号化ピースをピースシーケンスとしてコンテンツ取得部５００は取得する。
【００３６】
鍵束要求部５０１は、ピースシーケンスを復号するための鍵束を要求する要求メッセージを鍵サーバ５３へ送信する。鍵束とは、ピースシーケンスの各暗号化ピースを各々復号するための各復号鍵を、各暗号化ピースのシーケンスに合わせて含むものである。尚、鍵束及び復号鍵の詳細については後述する。要求メッセージは、この鍵束に含ませる各復号鍵のシーケンスを指定する情報として、ピースシーケンスにおける各暗号化ピースのインデックスの組み合わせ（シーケンス）を示すインデックス情報を含む。このようなシーケンスは、例えば、以下のように表される。
{ ( i1, 1 ), ( i2, 2 ), …, ( iN, N) }
（ただし、1≦i1, …, iN≦m）
【００３７】
鍵束取得部５０２は、要求メッセージに応じて鍵サーバ５３から送信された鍵束を受信する。コンテンツ復号部５０３は、コンテンツ取得部５００が取得した各暗号化ピースを、鍵束取得部５０２が取得した鍵束に含まれ且つ各暗号化ピースに各々対応する復号鍵を用いて各々復号して、復号した各ピースから構成されるコンテンツを取得する。
【００３８】
尚、リーチャ５０は、上述したように、シーダとして機能する場合もあるが、その機能的構成については、シーダ５２の構成において説明したため、ここでは、その説明を省略する。
【００３９】
＜鍵サーバ５３の構成＞
次に、鍵サーバ５３のＣＰＵが記憶装置や外部記憶装置に記憶された各種プログラムを実行することにより実現される各種機能について説明する。図１０は、鍵サーバ５３の機能的構成を例示する図である。鍵サーバ５３は、制御部５３０と、パケット処理部５３１と、ネットワークインターフェース部５３２と、認証・鍵交換処理部５３３と、鍵記憶部５３４と、シーケンス情報記憶部５３６と、シーケンス情報照合部５３５と、鍵供給部５３７とを有する。制御部５３０と、シーケンス情報照合部５３５と、ネットワークインターフェース部５３２と、パケット処理部５３１と、認証・鍵交換処理部５３３と、鍵供給部５３７との実体は、ＣＰＵのプログラム実行時にＲＡＭなどの記憶装置上に生成されるものである。鍵記憶部５３４は、例えば、外部記憶装置に記憶されるものである。
【００４０】
制御部５３０は、鍵サーバ５３全体を制御し、シーケンス情報照合部５３５から鍵供給部５３７への指示を仲介したりする。パケット処理部５３１は、リーチャ５０などの外部装置に送信する各種データをパケット化してネットワークインターフェース部５３２に受け渡したり、ネットワークインターフェース部５３２から受け渡されたパケットを基にデータを取得したりする。ネットワークインターフェース部５３２は、外部装置との通信を制御し、パケット処理部５３１から受け渡されたパケット化されたデータを送信したり、外部装置から受信したパケットをパケット処理部５３１に受け渡したりする。
【００４１】
認証・鍵交換処理部５３３は、ネットワークインターフェース部５３２を介して、リーチャ５０から要求メッセージを受信し、当該リーチャ５０と相互認証を行い、認証後、要求を受理する旨の受理メッセージをリーチャ５０に送信する。
【００４２】
鍵記憶部５３４は、例えば、ＨＤＤなどの外部記憶装置において構成され、各暗号化ピースを各々復号するための各復号鍵を各々記憶する。各復号鍵は、上述したように、例えばK ( i, j )として表される。
【００４３】
シーケンス情報記憶部５３６は、例えばＨＤＤなどの外部記憶装置において構成され、リーチャ５０に過去に送信した全ての鍵束に各々対応するシーケンスを示すシーケンス情報を記憶する。鍵束に各々対応するシーケンスは、上述したインデックス情報に示されるシーケンスと同様に、例えば以下のように表される。
{ ( i1, 1 ), ( i2, 2 ), …, ( iN, N) }
（ただし、1≦i1, …, iN≦m）
【００４４】
シーケンス情報照合部５３５は、シーケンス情報記憶部５３６に記憶されたシーケンス情報と、リーチャ５０から受信したインデックス情報とを照合することにより、インデックス情報によって示されるシーケンスに対応する鍵束を送信するか否かを決定する。具体的には、シーケンス情報照合部５３５は、インデックス情報に示されるシーケンスと同一のシーケンスを示すシーケンス情報がシーケンス情報記憶部５３６に記憶されていない場合、インデックス情報によって示されるシーケンスに対応する鍵束を送信することを決定する。鍵束は、例えば、以下のように表される。ここでは、各ピースＣ１〜ＣＮに各々対応する復号鍵が左から順に配列されて表されている。
｛K( i1, 1 ), K( i2, 2 ), …, K( iN, N )｝
（ただし、1≦i1, …, iN≦m）
【００４５】
そして、シーケンス情報照合部５３５は、鍵束を送信することを決定した場合、制御部５３０を介して、当該鍵束を当該リーチャ５０へ送信するよう鍵供給部５３７に指示する。また、シーケンス情報照合部５３５は、鍵束を送信しないことを決定した場合、制御部５３０を介して、当該鍵束の当該リーチャ５０への送信禁止を鍵供給部５３７に指示する。
【００４６】
鍵供給部５３７は、制御部５３０を介してシーケンス情報照合部５３５から鍵束の送信を指示されると、当該鍵束のシーケンスに応じた復号鍵を鍵記憶部５３４から各々読み出し、読み出した各復号鍵を含む鍵束を、ネットワークインターフェース部５３２を介してリーチャ５０に送信する。
【００４７】
＜トラッカ５１の構成＞
次に、トラッカ５１の構成について説明する。トラッカ５１は、リーチャ５０からアクセスされると、Ｐ２ＰネットワークＮＴに接続されているノードにアクセスするためのノード情報を当該リーチャ５０に対して送信する。ノード情報は、各ノードのＩＰアドレスとポート番号との組を含んでいる。図１１は、ノード情報のデータ構成を例示する図である。同図においては、ノードＡ〜Ｂは各々、リーチャ５０Ａ〜５０Ｂ、シーダ５２Ａ〜５２Ｃのいずれかであり、当該各ノードのＩＰアドレスとポート番号との組が示されている。
【００４８】
ここで、トラッカ５１がノード情報をどのように生成するかについて説明する。あるノードが、トラッカ５１に接続するためのトラッカ接続先情報を含むTorrent Fileを保持しており、また、暗号化ピースを保持しているとする。ノードは、Torrent Fileに含まれるトラッカ接続先情報を参照して、トラッカ５１にアクセスして、当該ノードを識別するためのＩＰアドレスとポート番号とをトラッカ５１に送信する。トラッカ５１は、受信したピース情報とＩＰアドレスとポート番号とを用いてノード情報を生成する。
【００４９】
（２）動作
次に、本実施の形態にかかるコンテンツ配信システムで行うコンテンツ配信処理の手順について図１２を用いて説明する。尚、リーチャ５０は、暗号化ピースを他のリーチャ５０からも受信可能であるが、ここでは、説明の便宜上、暗号化ピースをシーダ５２Ａ〜５２Ｃからの少なくとも１つから受信するものとする。
【００５０】
リーチャ５０は、まず、販売サーバ５４にアクセスして、Torrent Fileを取得する（ステップＳ１）。そして、リーチャ５０は、Torrent Fileに含まれるトラッカ情報に含まれるトラッカ接続先情報を用いてトラッカ５１にアクセスすると（ステップＳ２）、トラッカ５１はリーチャ５０に対して、ノード情報を送信する（ステップＳ３）。リーチャ５０は、ノード情報を受信すると（ステップＳ４）、ノード情報を用いて、例えばシーダ５２Ａ〜５２Ｃの少なくとも１つにアクセスする（ステップＳ５）。シーダ５２は、リーチャ５０からアクセスされると、自身の保持する暗号化ピースのシーケンスを示すピース情報をリーチャ５０へ送信する（ステップＳ６）。
【００５１】
リーチャ５０は、ピース情報を受信すると（ステップＳ７）、当該ピース情報を用いて、少なくとも１つのシーダ５２にアクセスする(ステップＳ８)。そして当該シーダ５２に対して、各ピースＣ１〜ＣＮに各々対応して複数存在しえる暗号化ピースのうち少なくとも１つを要求するピース要求をリーチャ５０は送信して、各暗号化ピースを受信する。シーダ５２は、リーチャ５０からのピース要求に応じて、自身の保持する暗号化ピースをリーチャ５０に送信する（ステップＳ９）。具体的には、リーチャ５０は、例えば、シーダ５２Ｂにアクセスして受信したピース情報を用いて、ピースＣ１が暗号化された暗号化ピースE( K( i1, 1 ) )[ C1 ]（i1は1≦i1≦mの整数）のうち例えば「i1=1」の暗号化ピースをシーダ５２Ｂが保持しているか否かを判断し、当該判断結果が肯定的である場合、当該シーダ５２Ｂにアクセスして、当該暗号化ピースE( K( 1, 1 ) )[ C1 ]をシーダ５２Ｂから受信することによりこれを取得する。尚、シーダ５２Ｂが当該暗号化ピースE( K( 1, 1 ) )[ C1 ]を実際には保持していなかった場合、リーチャ５０は、次いで、他のシーダ５２（例えばシーダ５２Ｃ）にアクセスして、当該他のシーダ５２Ｃからピース情報を取得する。そして、リーチャ５０は、上述と同様にして、ピース情報を用いて、当該暗号化ピースをシーダ５２Ｃが保持しているか否かを判断して、当該判断結果が肯定的である場合、シーダ５２にアクセスして、当該暗号化ピースの取得を試みる。リーチャ５０は、このような処理を繰り返して、各暗号化ピースから構成される暗号化コンテンツ｛E( K( i1, 1 ) )[ C1 ], E( K( i2, 2 ) )[ C2 ], …, E( K( iN, N ))[ CN ]｝を得る。
【００５２】
なお、リーチャ５０が、ピースＣｊ（1≦j≦N）に対応して複数存在しえる暗号化ピースのうちいずれの暗号化ピースを取得対象とするか、即ち、E( K( i1, j ) )[ Cj ]（i1は1≦i1≦mの整数）につきi1を「１」から「ｍ」のうちいずれの値にするかについては、任意である。従って、リーチャ５０が、各ピースＣ１〜ＣＮに対応して各々取得した暗号化ピースにシーケンス｛( i1, 1 ), ( i2, 2 ), …,(iN, N )｝は、任意のものとなる。
【００５３】
リーチャ５０は、コンテンツを構成する各ピースに各々対応する暗号化ピースであって暗号化コンテンツを構成する全ての暗号化ピースを取得すると、各暗号化ピースを各々復号するための各復号鍵を含む鍵束を要求する要求メッセージを鍵サーバ５３に送信する（ステップＳ１０）。この要求メッセージには、各復号鍵に対応するシーケンスを示すインデックス情報｛( i1, 1 ),…, ( iN, N)｝が含まれる。
【００５４】
鍵サーバ５３の認証・鍵交換処理部５３３は、ネットワークインターフェース部５３２を介して、当該要求メッセージを受信すると（ステップＳ１１）、当該リーチャ５０と相互認証を行い、認証成功の場合、要求を受理する旨の受理メッセージをリーチャ５０に送信する（ステップＳ１２）。リーチャ５０は、鍵サーバ５３から受理メッセージを受信すると（ステップＳ１３）、鍵サーバ５３からの鍵束の送信を待機する。
【００５５】
一方、鍵サーバ５３のシーケンス情報照合部５３５は、ステップＳ１１で受信された要求メッセージに含まれるインデックス情報を用いて、照合処理を行う（ステップＳ１４）。図１３は、照合処理の手順を示すフローチャートである。照合処理では、シーケンス情報照合部５３５は、ステップＳ１１で受信された要求メッセージに含まれるインデックス情報と、シーケンス情報記憶部５３６に記憶されているシーケンス情報とを照合し（ステップＳ１４０）、インデックス情報に示されるシーケンスと同一のシーケンスを示すシーケンス情報がシーケンス情報記憶部５３６に記憶されている否かを判断する（ステップＳ１４１）。即ち、リーチャ５０から要求されている鍵束が過去にリーチャ５０のいずれかに送信されたか否かが判断される。
【００５６】
当該判断結果が否定的である場合（ステップＳ１４１：ＮＯ）、シーケンス情報照合部５３５は、インデックス情報に示されるシーケンスに対応する鍵束｛K( i1, 1 ), K( i2, 2 ), …, K( iN, N )｝を送信することを決定する。そして、シーケンス情報照合部５３５は、制御部５３０を介して、当該鍵束を当該リーチャ５０へ送信するよう鍵供給部５３７に指示する。また、シーケンス情報照合部５３５は、当該シーケンスを示すシーケンス情報をシーケンス情報記憶部５３６に記憶させる（ステップＳ１４２）。鍵供給部５３７は、制御部５３０を介してシーケンス情報照合部５３５から送信を指示された鍵束を、鍵記憶部５３４から読み出しこれをネットワークインターフェース部５３２を介してリーチャ５０に送信する（ステップＳ１４３）。尚、ステップＳ１４１の判断結果が肯定的である場合、シーケンス情報照合部５３５は、当該鍵束を送信しないことを決定し、制御部５３０を介して、当該鍵束の当該リーチャ５０への送信禁止を鍵供給部５３７に指示する（ステップＳ１４４）。
【００５７】
図１２に戻り、リーチャ５０は、鍵束K( i1, 1 ), K( i2, 2 ), …, K( iN, N )を鍵サーバ５３から受信した場合（ステップＳ１５：ＹＥＳ）、鍵束に含まれる各復号鍵を用いて、各暗号化ピースE( K( i1, 1 ) )[ C1 ], E( K( i2, 2 ) )[ C2 ], …, E( K( iN, N )[ CN ]をそれぞれ復号し、復号した各ピースＣ１〜ＣＮを得て、これらから構成されるコンテンツＣを得る（ステップＳ１６）。即ち、リーチャ５０は、復号鍵K( i1, 1 )を用いてE( K( i1, 1 ) )[ C1 ]を復号して、ピースＣ１を得て、復号鍵K( i2, 2 )を用いてE( K( i2, 2 ) )[ C2 ]を復号して、ピースＣ２を得て、復号鍵K( iN, N )を用いてE( K( iN, N ))[ CN ]を復号して、ピースＣＮを得て、他のピースについても同様にして得ることにより、各ピースＣ１〜ＣＮから構成されるコンテンツＣを得る。
【００５８】
尚、リーチャ５０は、ステップＳ１５で鍵束を受信することなく、図１３のステップＳ１４３で鍵サーバ５３から送信されたエラーメッセージを受信した場合、ステップＳ１０で取得した各ピースを復号することができず、従って、コンテンツを利用できない。この場合、ステップＳ５に戻り、リーチャ５０は、ステップＳ１０で取得したシーケンスとは異なるシーケンスで各暗号化ピースを取得した後に、ステップＳ１０以降の処理を再度行う。
【００５９】
以上のように、Ｐ２Ｐネットワークを介して、同一のコンテンツを複数のリーチャ５０に配信する場合、暗号化ピースのシーケンスを用いて、鍵サーバ５３が鍵束の送信の可否を決定する。ここで、鍵サーバ５３が、既に使用されたシーケンスの再使用を回避することにより、コンテンツをリーチャ５０毎に個別化することができる。従って、例えば、１つの鍵束が漏洩したとしても、この鍵束に対応する暗号化コンテンツのみしか復号することができないので、コンテンツの不正使用を抑制することができる。また、予め定められたシーケンスではなく、リーチャ５０が任意に取得した暗号化ピースにより定まるシーケンスを用いることにより、Ｐ２Ｐネットワークの環境に応じたフレキシブルなコンテンツ配信を実現することができる。
【００６０】
（３）変形例
＜変形例１＿１＞
上述の第１の実施の形態においては、Torrent Fileは上述のものに限らず、例えば、ファイル情報は、各暗号化ピースを用いてハッシュ演算により計算されるハッシュ値を含んでいても良い。各暗号化ピースのハッシュ値とは、例えば以下のように表される。
{ hash( E( K( i, j ) )[ Cj ] ) }
（ただし、1≦i≦m、1≦j≦N）
【００６１】
図１４は、このようなTorrent Fileのデータ構成を例示する図である。同図においては、暗号化ピースのハッシュ値とインデックスとの対応関係が示される。リーチャ５０は、これらm×n個のハッシュ値を用いて、受信した各暗号化ピースの完全性を確認することができる。更に、このようなTorrent Fileに対し、Torrent Fileの生成者又は信頼できる第三者（例えば、コンテンツ製作者）がディジタル署名を付加しても良い。この場合、リーチャ５０は、受信した各暗号化ピースの完全性に加えて正当性も確認することができる。
【００６２】
また、このようなTorrent Fileを参照することで、暗号化ピースのハッシュ値からインデックスを特定することが可能であり、この結果、当該暗号化ピースを復号するための復号鍵を特定することも可能になる。
【００６３】
このような構成においては、更に、シーダ５２は、ハッシュ値を含むピース情報をリーチャ５０に送信するようにしても良い。図１５は、ハッシュ値を含むインデックス情報を例示する図である。この場合も、リーチャ５０は、ハッシュ値を用いて、受信した各暗号化ピースの完全性を確認することができる。
【００６４】
また、ファイル情報は、全てのインデックス（上記の例では1≦i≦m、1≦j≦Nの全ての( i, j )）についてのものである必要はなく、その一部についてのものであってもよい。
【００６５】
また、Torrent Fileにそのバージョン番号や有効期限情報を含めてもよい。この場合、リーチャ５０は、取得したTorrent Fileがその時点において有効であるか否かを知ることができる。例えば、ある時点において取得したTorrent Fileが有効でない場合、リーチャ５０はより新しいTorrent Fileを取得してもよいし、前記ある時点において取得したTorrent Fileを用いて暗号化ピースの取得を始め、シーダ５２が（リーチャ５０にとって）未知のインデックスに対応する暗号化ピースを保持している場合、シーダ５２から前記未知のインデックスに対応する暗号化ピースを受信し、その受信後により新しいTorrent Fileを取得して受信した各暗号化ピースの完全性や正当性を確認してもよい。
【００６６】
＜変形例１＿２＞
上述の第１の実施の形態においては、リーチャ５０は、ステップＳ１０で、インデックス情報を要求メッセージに含ませて鍵サーバ５３に送信したが、これに限らず、受理メッセージを受信した後にインデックス情報を鍵サーバ５３へ送信してもよい。
【００６７】
＜変形例１＿３＞
上述のステップＳ６では、シーダ５２は、リーチャ５０からのアクセスにより、自身の保持するピースのシーケンスを示すピース情報を送信したが、リーチャ５０からのアクセスを待たずに、ピース情報を当該リーチャ５０へ送信するようにしても良い。
【００６８】
＜変形例１＿４＞
上述のステップＳ９では、シーダ５２は、暗号化ピースをリーチャ５０に送信したが、これに加えて、対応するインデックスを送信しても良い。例えば、送信する暗号化ピースがE( K( 1, 1 ) )[ C1 ]である場合、これに加えて、対応するインデックス( 1, 1 )をシーダ５２はリーチャ５０に送信しても良い。
【００６９】
＜変形例１＿５＞
上述の第１の実施の形態においては、リーチャ５０は、暗号化ピースをシーダ５２から受信するようにしたが、これに限らず、他のリーチャ５０から暗号化ピースを取得するようにしても良い。
【００７０】
また、リーチャ５０は、各ピースＣ１〜ＣＮに各々対応する暗号化ピースにつき、同一のピースに対応する異なる暗号化ピースを複数取得しておくようにしても良い。例えば、ピースＣ１に対して、暗号化ピースE( K( i1, 1 ) )[ C1 ]及びE( K( i1’, 1 ) )[ C1 ]（但し、i1≠i1’， 1≦i1≦m，1≦i1’≦m）をリーチャ５０は取得しておいても良い。このような構成によれば、リーチャ５０が鍵束を鍵サーバ５３に要求する際に、仮にインデックス( i1, 1 )を含むシーケンスが既に使用されている場合当該シーケンスに対応する鍵束を取得することはできないが、インデックス( i1’, 1 ) を含むシーケンスが使用可能である場合には、シーダ５２へ再びアクセスすることなく当該シーケンスに対応する鍵束を鍵サーバ５３から取得することができる。このように、暗号化ピースを予め余分に取得しておくことにより、シーケンスの候補を予め複数用意することができるため、リーチャ５０がシーダ５２に再度アクセスする煩雑さを回避することができる。
【００７１】
＜変形例１＿６＞
上述の第１の実施の形態においては、リーチャ５０から要求されている鍵束に対応するシーケンスがシーケンス情報記憶部５３６に既に記憶されている場合、ステップＳ１４４では、鍵サーバ５３のシーケンス情報照合部５３５は、制御部５３０を介して、当該鍵束の当該リーチャ５０への送信禁止を鍵供給部５３７に指示するようにしたが、これに限らず、以下のようにすることもできる。例えば、リーチャ５０が暗号化コンテンツE( K( i1, 1 ) )[ C1 ], E( K( i2, 2 ) )[ C2 ], …, E( K( iN, N ))[ CN ]を取得し、これに対応する鍵束を鍵サーバ５３へ要求したとする。鍵サーバ５３は、リーチャ５０から要求された鍵束に対応するシーケンス｛( i1, 1 ), ( i2, 2 ), …, ( iN, N )｝がシーケンス情報記憶部５３６に既に記憶されている場合、シーケンス情報記憶部５３６に記憶されていない他のシーケンス｛( i1’, 1 ), ( i2, 2 ), …, ( iN, N )｝を生成して、リーチャ５０が置き換えるべき暗号化ピースE( K( i1’, 1 ) )[ C1 ]とそのインデックスに関する情報（この例では( i1’, 1 )）をリーチャ５０へ送信する。加えて、鍵サーバ５３は他のシーケンス｛( i1’, 1 ), ( i2, 2 ), …, ( iN, N )｝に各々対応する各復号鍵を含む鍵束をリーチャ５０へ送信する。このようにすれば、リーチャ５０は、鍵サーバ５３のシーケンス情報照合部５３５が行う照合処理において鍵束の送信が許可されるシーケンスに対応する暗号化ピースを取得するために、リーチャ５０がトラッカ５１へ再度アクセスする煩雑さを避けることができる。尚、鍵サーバ５３は、リーチャ５０に送信可能な暗号化ピースを予め保持しておく必要があるが、その暗号化ピースは１つでも複数でも良く、その暗号化ピースが複数の場合、リーチャ５０が置き換えるべき暗号化ピースとして複数の暗号化ピース（とそれらのインデックスに関する情報）をリーチャ５０へ送信してもよい。なお、リーチャ５０から要求された鍵束に対応するシーケンス｛( i1, 1 ), ( i2, 2 ), …, ( iN, N )｝がシーケンス情報記憶部５３６に未だ記憶されていない場合、鍵サーバ５３は上記に例示した置き換えを行ってもよいし、行わなくてもよい。
【００７２】
＜変形例１＿７＞
上述の第１の実施の形態においては、照合処理では、シーケンス情報照合部５３５は、リーチャ５０から要求されている鍵束が１回でも過去にリーチャ５０のいずれかに送信していれば、当該鍵束を送信しないようにした。しかし、これに限らず、同一の鍵束を、２回以上の所定の回数まで送信可能にしても良い。この場合、鍵サーバ５３の認証・鍵交換処理部５３３は、リーチャ５０との間で行う相互認証において、リーチャ５０を識別するためのリーチャ識別情報をリーチャ５０から取得する。リーチャ識別情報としては、例えば、リーチャ５０のＩＰアドレスやポート番号や、リーチャ５０のＭＡＣアドレスや上述の加入者ＩＤなどやこれらの組み合わせなどがある。シーケンス情報照合部５３５は、鍵束のシーケンスを示すシーケンス情報と、リーチャ識別情報と、当該リーチャ識別情報によって識別されるリーチャ５０が当該鍵束の送信を要求した使用回数とを対応付けてシーケンス情報記憶部５３６に記憶させる。図１６は、本変形例に係る照合処理の手順を示すフローチャートである。ステップＳ１４０〜Ｓ１４１は第１の実施の形態と同様である。ステップＳ１４１の判定結果が肯定的である場合、即ち、リーチャ５０から要求されている鍵束のシーケンスと同一のシーケンスを示すシーケンス情報がシーケンス情報記憶部５３６に既に記憶されている場合、当該シーケンス情報と、当該リーチャ５０のリーチャ識別情報と対応付けられてシーケンス情報記憶部５３６に記憶されている使用回数を参照して、当該使用回数が所定回数以下であるか否かを判断する（ステップＳ１４０Ａ）。当該判断結果が肯定的である場合、シーケンス情報照合部５３５は、当該シーケンス情報と、当該リーチャ識別情報と対応付けられてシーケンス情報記憶部５３６に記憶されている使用回数を１つインクリメントすることにより、当該使用回数を更新して（ステップＳ１４０Ｂ）、上述と同様のステップＳ１４３の処理を行う。また、ステップＳ１４１の判断結果が否定的である場合、シーケンス情報照合部５３５は、上述と同様にステップＳ１４２以降の処理を行う。尚、ステップＳ１４０Ａの判断結果が否定的である場合は、シーケンス情報照合部５３５は、上述のステップＳ１４４と同様の処理を行う。
【００７３】
このような構成によれば、暗号化ピースにおける同一のシーケンスの使用を１回のみならず複数回許可することになり、より柔軟なコンテンツ配信を実現することができる。
【００７４】
＜変形例１＿８＞
上述の第１の実施の形態においては、ノード情報は、各ノードのＩＰアドレス及びポート番号を示すものとしたが、これに限らず、各ノードのＭＡＣアドレスを示すようにしても良いし、コンテンツ配信サービスの加入時に割り当てられる加入者ＩＤを示すようにしても良い。この場合、各ノードはノード識別情報として、当該ノードのＩＰアドレス、ＭＡＣアドレス、加入者ＩＤ及びＵＲＬのうち少なくとも１つ以上をトラッカ５１に送信すれば良い。
【００７５】
また、上述の第１の実施の形態においては、トラッカ５１がノード情報を生成する際に、各ノードは、受信したピース情報とＩＰアドレス及びポート番号とをトラッカ５１に送信するようにした。しかし、これに限らず、ピース情報とＩＰアドレス及びポート番号とに加えて、Torrent File識別情報をトラッカ５１に送信しても良い。Torrent File識別情報とは、例えば、Torrent Fileの一部又は全部のハッシュ値であっても良いし、Torrent Fileのファイル名であっても良いし、Torrent FileにそのＩＤを示すフィールドがある場合、そのＩＤの値であっても良い。この場合、トラッカ５１は、受信したピース情報とＩＰアドレス及びポート番号とに加えTorrent File識別情報を受信すると、Torrent File識別情報毎にノード情報を生成するようにしても良い。即ち、トラッカ５１は、アクセスしてきたノードが送信したTorrent File識別情報に対応するノード情報を生成してこれを当該ノードへ送信するようにしても良い。
【００７６】
また、トラッカ５１は、ＩＰアドレス及びポート番号を基にノードをグループ分けし、グループ毎にノード情報を生成しても良い。即ち、トラッカ５１は、アクセスしてきたノードが送信したＩＰアドレス及びポート番号の属するグループに対応するノード情報を生成してこれを当該ノードへ送信する。ここで、トラッカ５１は、各ノードが複数のグループに属するようにグループ分けしても良い。この場合、トラッカ５１は、アクセスしてきたノードが送信したＩＰアドレス及びポート番号が属する全部または一部のグループにそれぞれ対応するノード情報を生成してこれを当該ノードへ送信する。
【００７７】
＜変形例１＿９＞
上述の第１の実施の形態においては、ステップＳ９で、リーチャ５０は、暗号化ピースの取得に成功した場合、その旨を、当該暗号化ピースを送信したシーダ５２に通知するようにしても良い。暗号化ピースの取得が成功したか否かは、例えば、以下のように判断するようにしても良い。シーダ５２が、そのデータの末尾に末尾であることを示す印をつけて暗号化ピースを送り、リーチャ５０は、このような暗号化ピースを受信する際に当該印を検出することにより、当該暗号化ピースについてデータの全部を取得できたと判断するようにしても良い。
【００７８】
又は、Torrent Fileに含まれるファイル情報が、上述の変形例１＿１で説明したように、各暗号化ピースを用いてハッシュ演算により計算されるハッシュ値を含む場合、リーチャ５０は、シーダ５２から受信した暗号化ピースのハッシュ値を計算しこれと、Torrent Fileにおける当該暗号化ピースのハッシュ値とを比較して、これらが一致する場合に、当該暗号化ピースの取得に成功したと判断するようにしても良い。また、リーチャ５０は、暗号化ピースの取得に成功した旨を示す通知メッセージをシーダ５２に送信する際に、当該暗号化ピースのハッシュ値やTorrent Fileにある暗号化ピースのインデックスや取得に成功した時刻や当該リーチャ５０のノード情報を当該通知メッセージに含めても良い。
【００７９】
＜変形例１＿１０＞
上述の第１の実施の形態においては、リーチャ５０が、シーダ５２に対して一度に要求できる暗号化ピースの数に上限を設けても良い。この場合、シーダ５２は、上限を超える数の暗号化ピースを要求するピース要求を受信した場合、シーダ５２はその要求を拒否しても良い。又は、シーダ５２はその要求を拒否せずに、その上限以下の数の暗号化ピースを、当該ピース要求を送信したリーチャ５０に送信して、それらのうち少なくとも一つの暗号化ピースの送信が終わるのを確認してから、ピース要求により要求され未だ送信していない残りの暗号化ピースのうち少なくとも一つであって且つ設定された上限の数以下の数の暗号化ピースを当該リーチャ５０に送信するようにしても良い。
【００８０】
＜変形例１＿１１＞
上述の第１の実施の形態においては、シーダ５２は、リーチャ５０から送信されたピース要求によって要求された暗号化ピースを、保持していないなどの理由で当該リーチャ５０に送信できない場合、その旨のメッセージをリーチャ５０に送信しても良い。
【００８１】
[第２の実施の形態]
次に、コンテンツ配信システムの第２の実施の形態について説明する。なお、上述の第１の実施の形態と共通する部分については、同一の符号を使用して説明したり、説明を省略したりする。
【００８２】
（１）構成
本実施の形態にかかるコンテンツ配信システムの構成は、上述の第１の実施の形態にかかるコンテンツ配信システムの構成とは以下の点で異なる。本実施の形態においては、各ピースＣ１〜ＣＮに対応する各暗号化ピースのうち全部又は一部のシーケンスについてトラッカ５１が決定する。
【００８３】
図１７は、本実施の形態にかかるトラッカ５１の機能的構成を示すブロック図である。トラッカ５１は、インデックス生成部５１０と、シーダ情報生成部５１１と、シーダデータベース５１２と、インデックスデータベース５１３とを有する。
【００８４】
シーダデータベース５１２は、各ピースＣ１〜ＣＮについて、各暗号化ピースを復号するための各復号鍵のインデックスと、当該インデックスに対応する暗号化ピースを保持するノードにアクセスするためのシーダ接続先情報とを対応付けて記憶している。シーダ接続先情報とは、ここでは、ＵＲＬとする。図１８は、シーダデータベース５１２のデータ構成を例示する図である。同図においては、左から順に各ピースＣ１〜ＣＮに対応する情報が示されており、例えば、ピースＣ１に対応しインデックス( 1, 1 )に対応する暗号化ピースは、ＵＲＬが「http://www11...」であるノード及びＵＲＬが「http://www12...」であるノードが保持していることが示され、ピースＣ２に対応しインデックス( 2, 2 )に対応する暗号化ピースは、ＵＲＬが「http://www23...」であるノードが保持していることが示されている。尚、各ピースＣ１〜ＣＮのインデックスに対応付けられるノードは全て同じであっても良いし、各々異なるノードであっても良い。
【００８５】
尚、トラッカ５１は、以下のようにシーダ接続先情報を生成して各インデックスと対応付けてシーダデータベース５１２に記憶する。上述の第１の実施の形態で説明したように、トラッカ５１は、各ノードからノード識別情報を取得するが、本実施の形態においては、これに加え、当該ノードが保持する暗号化ピースのピース情報も取得する。そして、トラッカ５１は、上述の第１の実施の形態で説明したノード情報と同様に、ノード識別情報に基づいてシーダ接続先情報を生成し、これと、ピース情報によって示されるシーケンスに含まれる各インデックスとを対応付けてシーダデータベース５１２に記憶させる。
【００８６】
インデックス生成部５１０は、リーチャ５０からアクセスされると、まず、Torrent File識別情報をリーチャ５０から取得する。そして、インデックス生成部５１０は、Torrent File識別情報に基づいて、各暗号化ピースの選択できるインデックスの範囲を定めた上で、各ピースに各々対応する各暗号化ピースの各インデックスを決定し、各インデックスの組み合わせ（シーケンス）を生成する。そして、インデックス生成部５１０は、生成したシーケンスがインデックスデータベース５１３に既に記憶されているか否かを問い合わせて、当該問い合わせ結果に応じて、当該シーケンスの使用可否を判断する。インデックス生成部５１０が使用可能であると判断したシーケンスを示すシーケンス情報はインデックスデータベース５１３において記憶される。
【００８７】
シーダ情報生成部５１１は、インデックス生成部５１０が使用可能であると判断したシーケンスを用いて、シーダデータベース５１２を参照して、シーケンスに対応する各暗号化ピースを保持するノードを暗号化ピース毎に各々特定する。尚、シーダ情報生成部５１１は、ここで特定するノードは、対象の暗号化ピースを保持するノードが複数存在する場合、その中から任意に選択したものであっても良い。そして、シーダ情報生成部５１１は、暗号化ピース毎に特定されたノードを示すシーダ情報を生成してこれをリーチャ５０に送信する。シーダ情報とは、インデックス生成部５１０が使用可能であると判断したシーケンスの各インデックスを示すインデックス情報と、当該各インデックスに対応する暗号化ピースを保持するノードにアクセスするための接続先情報とを含む。
【００８８】
図１９は、シーダ情報を例示する図である。同図においては、全部の暗号化ピースのシーケンスをトラッカ５１が決定する例を示している。同図には、左から順にピースＣ１〜Ｃ３に対応する情報が示されており、接続先情報として、各ノードのＵＲＬが示されている。また、ピースＣ１〜ＣＮに対して決定されたシーケンスは、｛(3,1),(5,2),…,(1,N)｝であることが示され、インデックス(3,1)に対応する暗号化ピースを、ＵＲＬが「http://www10...」であるノードが保持することが示され、インデックス(5,2)に対応する暗号化ピースを、ＵＲＬが「http://www20...」であるノードが保持することが示され、インデックス(1, N)に対応する暗号化ピースを、ＵＲＬが「http://wwwN0...」であるノードが保持することが示されている。尚、各暗号化ピースを保持するノードは同一のノードであっても良い。
【００８９】
インデックスデータベース５１３は、インデックス生成部５１０が生成したインデックスのシーケンスを示すシーケンス情報を記憶する。あるシーケンス情報がインデックスデータベース５１３に記憶されているということは、当該シーケンス情報によって示されるシーケンスは既に使用されたことになる。また、インデックスデータベース５１３は、外部又は内部にコントローラを有し、インデックス生成部５１０からの問合せに応じて、シーケンス情報を検索して、検索結果に応じて、問合せ結果をインデックス生成部５１０に返したり、シーケンス情報を記憶したりする。
【００９０】
（２）動作
次に、本実施の形態にかかるコンテンツ配信システムで行うコンテンツ配信処理の手順について図２０を用いて説明する。尚、ここでも、説明の便宜上、リーチャ５０は、各暗号化ピースをシーダ５２Ａ〜５２Ｃからの少なくとも１つから受信するものとする。
【００９１】
ステップＳ１〜Ｓ２は上述の第１の実施の形態と同様である。トラッカ５１は、リーチャ５０からアクセスされると、Torrent File識別情報をリーチャ５０から取得し、Torrent File識別情報に基づいて、インデックス生成処理を行う（ステップＳ２０）。以下では、各暗号化ピースの全部のシーケンスをトラッカ５１が決定する場合について説明する。図２１はインデックス生成処理の手順を示すフローチャートである。インデックス生成処理では、インデックス生成部５１０が、例えば、各インデックス( i1, 1 ), ( i2, 2 ),…,( i3, N )において、「1≦i1, i2, …, i3≦m」なる「i1」, 「i2」, …,「 N」の値をそれぞれ任意に決定して、各インデックスのシーケンス｛( i1, 1 ), ( i2, 2 ), …,( i3, N )｝を生成する（ステップＳ２００）。次いで、インデックス生成部５１０は、当該シーケンス｛( i1, 1 ), ( i2, 2 ), …,( i3, N )｝を示すシーケンス情報が既に記憶されているか否かをインデックスデータベース５１３に問い合わせる。インデックスデータベース５１３は、自身が記憶しているシーケンス情報を検索して、問合せされたシーケンスと同一のシーケンスを示すシーケンス情報が既に記憶されている場合（ステップＳ２０１：ＹＥＳ）、問合せされたシーケンスは既に使用されたことになる。この場合、インデックスデータベース５１３は、「１」をインデックス生成部５１０に返す。インデックス生成部５１０は、インデックスデータベース５１３から「１」を受け取ると、新たなシーケンスを生成して、当該シーケンスを示すシーケンス情報が既に記憶されているか否かをインデックスデータベース５１３に再度問い合わせる。
【００９２】
尚、ステップＳ２０１で、問合せされたシーケンスと同一のシーケンスを示すシーケンス情報が記憶されていない場合（ステップＳ２０１：ＮＯ）、インデックスデータベース５１３は、問合せされたシーケンスを示すシーケンス情報を記憶すると共に、「０」をインデックス生成部５１０に返す（ステップＳ２０２）。インデックス生成部５１０がインデックスデータベース５１３から「０」を受け取ると、次いで、シーダ情報生成部５１１が、シーケンスシーダデータベース５１２を参照して、当該シーケンスに対応する各暗号化ピースを保持するシーダ５２を暗号化ピース毎に各々特定する。そして、シーダ情報生成部５１１は、暗号化ピース毎に特定されたシーダを示すシーダ情報を生成してこれをリーチャ５０に送信する（ステップＳ２０３）。シーダ情報には、上述のインデックス情報及び接続先情報が含まれている。
【００９３】
図２０に戻り、リーチャ５０は、シーダ情報をトラッカ５１から受信すると（ステップＳ２１）、当該シーダ情報に含まれる接続先情報を用いてシーダ５２にアクセスして（ステップＳ２２）、シーダ情報に含まれるインデックス情報によって示されるシーケンスに対応する各暗号化ピースを取得する。ステップＳ１０〜Ｓ１３は上述の第１の実施の形態と同様である。ステップＳ２３では、鍵サーバ５３は、上述の照合処理を行わず、要求メッセージに応じた鍵束をリーチャ５０に送信する。ステップＳ１５以降は上述の第１の実施の形態と同様である。
【００９４】
このような構成によれば、トラッカ５１は、暗号化コンテンツを構成する暗号化ピースのシーケンスについて、既に使用されたシーケンスを回避したシーケンスをリーチャ５０に提供することができる。例えば、トラッカ５１が、あるリーチャ５０に対して、図１９に示されるシーダ情報を送信したとする。同図に示されるシーダ情報によって示されるシーケンスは、{( 3, 1 ),( 5, 2 ),…,( 1, N)}である。これに対し、その後、他のリーチャ５０がトラッカ５１にアクセスしたとき、例えば図２２に示されるシーダ情報を送信する。同図に示されるシーダ情報によって示されるシーケンスは、{( 4, 1 ),( 5, 2 ), …,(2, N)}であり、図１９に示したものとは異なる。従って、暗号化コンテンツを構成する暗号化ピースのシーケンスをトラッカ５１がリーチャ５０毎に異ならせることができる。
【００９５】
このように、トラッカ５１がシーケンスを決定することで、同一のシーケンスに対応するコンテンツの不正使用を抑制することができる。例えば、各暗号化ピースを復号するための復号鍵が全て漏洩した場合、漏洩元を特定することが可能である。
【００９６】
即ち、トラッカ５１は、既に使用されたシーケンスを回避するためのみではなく、鍵束を漏洩させる不正行為に対して、鍵束の漏洩元を特定するために、各ノードにシーケンスを割り当てることもできる。後者の目的を達成する手段として、以下の参考文献１において示されているTA Codeを用いることができる。例えば、あるノードに割り当てられたTA Codeの符号語をw=( i1 i2 … iN’ )（i1, i2, … ,iN’はそれぞれ、符号語を構成するシンボルである）とすると、当該ノードには暗号化ピースE( K( i1, 1 ) )[ C1 ], E( K( i2, 2 ) )[ C2 ], …, E( K( iN’, N’ ))[ CN’ ]を保持させる。
（参考文献１）J. Staddon, D.R. Stinson, and R. Wei, “Combinatorial properties of frameproof and traceability codes,” IEEE Transactions on Information Theory 47(3): pp.1042-1049 (2001).
【００９７】
鍵束が漏洩した場合には、当該鍵束に対応するシーケンス（対応する符号語）を調べることにより、トラッカ５１が当該シーケンスを割り当てたノードを特定することができる。このため、結果的に、コンテンツの不正使用を抑制することが可能になる。
【００９８】
＜変形例２＿１＞
上述の第２の実施の形態においては、接続先情報は、上述のものに限らず、シーダのＵＲＬの代わりに、シーダのＩＰアドレスとポート番号とを含むようにしても良いし、シーダのＵＲＬに加えて、シーダのＩＰアドレスとポート番号との組が含まれていても良い。
【００９９】
また、上述の第２の実施の形態においては、シーダ情報は、各暗号化ピースの各インデックスと各暗号化ピースのハッシュ値とを含んでも良い。図２３は、本変形例にかかるシーダ情報を例示する図である。同図においては、接続先情報として、各「ノードのＩＰアドレスとポート番号との組が示されている。また、hash(E( K(i1 , 1 ))[ C1 ] ), hash(E( K(i2 , 2 ) ) [ C2 ] ), hash(E( K(i3 , 3 )) [ C3 ])により、各暗号化ピースのインデックスとハッシュ値とが表される。
【０１００】
また、上述の第２の実施の形態においては、第１の実施形態の変形例で説明したように、Torrent Fileに暗号化ピースのハッシュ情報が含まれている場合、トラッカ５１は、Torrent File識別情報をリーチャ５０から取得しなくても良い。
【０１０１】
また、上述の第２の実施の形態においては、トラッカ５１が生成するシーダ情報は、ノードにアクセスするための接続先情報を含むようにしたが、これを含まないようにしても良い。図２４は、本変形例にかかるシーダ情報を例示する図である。同図においては、暗号化ピースに対応する各インデックスのみが示されている。このような構成において、リーチャ５０は、第１の実施の形態で説明したノード情報をトラッカ５１から取得し、取得したノード情報に基づいて、各暗号化ピースを取得するようにすれば良い。また、この場合も、シーダ情報としてハッシュ値を含んでも良い。図２５は、ハッシュ値を含み、接続先情報を含まないシーダ情報を例示する図である。
【０１０２】
また、トラッカ５１は、シーダデータベース５１２において、接続先情報を各暗号化ピースを復号するための各復号鍵のインデックスと対応付けて記憶していたが、これに限らず、接続先情報自体を記憶しなくても良い。この場合のリーチャ５０の動作は、上述と同様である。
【０１０３】
＜変形例２＿２＞
上述の第２の実施の形態においては、インデックス生成処理では、１回でも既に使用されたシーケンスを再度使用しないようにしたが、２回以上の所定の回数まで使用可能にしても良い。この場合、トラッカ５１の認証・鍵交換処理部５３３は、リーチャ５０との間で行う相互認証において、リーチャ５０を識別するためのリーチャ識別情報をリーチャ５０から取得する。シーケンス情報照合部５３５は、シーケンス情報と、リーチャ識別情報と、当該リーチャ識別情報によって識別されるリーチャ５０に対して生成したシーケンスを示すシーケンス情報を送信した使用回数とを対応付けてシーダデータベース５１２に記憶させる。図２６は、本変形例に係るインデックス生成処理の手順を示すフローチャートである。尚、トラッカ５１は、図２０に示したステップＳ２でリーチャ５０からアクセスされたときにリーチャ識別情報をリーチャ５０から取得しているものとする。ステップＳ２００〜Ｓ２０１は上述と同様である。ステップＳ２０１の判定結果が肯定的である場合、即ち、ステップＳ２００で生成されたインデックスのシーケンスを示すシーケンス情報がインデックスデータベース５１３に既に記憶されている場合、当該シーケンス情報と、取得されたリーチャ識別情報とに対応付けられて記憶されている使用回数を参照して、当該使用回数が所定回数以下であるか否かを判断する（ステップＳ２００Ａ）。当該判断結果が肯定的である場合、インデックスデータベース５１３は、「０」をインデックス生成部５１０に返すと共に、当該シーケンス情報と、当該リーチャ識別情報と対応付けて使用回数を１つインクリメントすることにより、当該使用回数を更新する（ステップＳ２００Ｂ）。尚、ステップＳ２０１の判断結果が否定的である場合は、上述と同様にステップＳ２０２以降の処理を行う。ステップＳ２００Ａの判断結果が否定的である場合は、ステップＳ２００に戻って、各インデックスのシーケンスを新たに生成する。
【０１０４】
このような構成によれば、暗号化ピースの同一のシーケンスの使用を１回のみならず複数回許可することになり、より柔軟なコンテンツ配信を実現することができる。
【０１０５】
＜変形例２＿３＞
上述においては、トラッカ５１が、インデックス生成部５１０が生成したシーケンスが既に使用されたか否かをトラッカ５１自体が判断するようにしたが、この判断をトラッカ５１が行わないようにしても良い。この場合、上述の第１の実施の形態と同様にして、鍵サーバ５３は、ステップＳ１２の後、ステップＳ１４の照合処理を行うことにより、同一のシーケンスが再度使用されることを回避することができる。
【０１０６】
例えば、この場合、リーチャ５０は、トラッカ５１がそのシーケンスを決定する暗号化ピースにつき、同一のピースに対応する異なる暗号化ピースを複数取得しておくようにしても良い。例えば、ピースＣ１に対して、暗号化ピースE( K( i1, 1 ) )[ C1 ]及びE( K( i1’, 1 ) )[ C1 ]（但し、i1≠i1’， 1≦i1≦m，1≦i1’≦m）をリーチャ５０は取得しておいても良い。このような構成によれば、リーチャ５０が鍵束を鍵サーバ５３に要求する際に、仮にインデックス( i1, 1 )を含むシーケンスが既に使用されている場合当該シーケンスに対応する鍵束を取得することはできないが、インデックス( i1’,1 ) を含むシーケンスが使用可能である場合には、トラッカ５１へ再びアクセスすることなく当該シーケンスに対応する鍵束を鍵サーバ５３から取得することができる。このように、暗号化ピースを予め余分に取得しておくことにより、シーケンスの候補を予め複数用意することができるため、リーチャ５０が再度トラッカ５１へアクセスする煩雑さを回避することができる。
【０１０７】
また、トラッカ５１は、コンテンツを構成する全ての各ピースＣ１〜ＣＮに対応する暗号化ピースのシーケンスを決定するようにしたが、これに限らず、一部の暗号化ピースのシーケンスのみを決定するように構成しても良い。このような構成においては、トラッカ５１がシーケンスを決定しない残りの暗号化ピースについては、上述の第１の実施の形態と同様に、リーチャ５０が他のノードから任意に取得すれば良く、そのシーケンスについて、鍵サーバ５３が上述の照合処理を行うようにすれば良い。
【０１０８】
この場合、鍵サーバ５３は、照合処理では、トラッカ５１が決定した一部の暗号化ピースのシーケンスを除いたシーケンスについてのみ照合を行うようにしても良い。この場合、シーケンス情報記憶部５３６は、トラッカ５１が決定する一部のシーケンス以外のシーケンスを示すシーケンス情報を記憶する。各ピースＣ１〜ＣＮのうちいずれに対応する暗号化ピースのシーケンスについてトラッカ５１が決定するのかは、例えばTorrent Fileにおいて予め定められているものとする。鍵サーバ５３のシーケンス情報照合部５３５は、照合処理においては、トラッカ５１が決定した一部のシーケンスを除いて、要求メッセージに含まれるインデックス情報と、シーケンス情報記憶部５３６に記憶されたシーケンス情報とを照合する。
【０１０９】
このような構成によれば、シーケンス情報記憶部５３６に記憶される情報量を低減させることができる。また、照合処理に用いる情報量を低減することができるため、鍵サーバ５３の処理負担を軽減することができる。
【０１１０】
＜変形例２＿４＞
上述の第２の実施の形態においては、インデックスデータベース５１３はトラッカ５１が有する構成としたが、これに限らず、トラッカ５１に接続されるデータベースサーバが有するように構成しても良い。このような構成において、トラッカ５１のインデックス生成部５１０は、データベースサーバを介してインデックスデータベース５１３に記憶されているシーケンスを参照する。
【０１１１】
[第３の実施の形態]
次に、コンテンツ配信システムの第３の実施の形態について説明する。なお、上述の第１の実施の形態又は第２の実施の形態と共通する部分については、同一の符号を使用して説明したり、説明を省略したりする。
【０１１２】
（１）構成
本実施の形態にかかるコンテンツ配信システムの構成は、上述の第１の実施の形態又は第２の実施の形態にかかるコンテンツ配信システムの構成とは以下の点で異なる。本実施の形態にかかるコンテンツ配信システムにおいては、特定の暗号化ピース（たとえば、ピースＣ１に対応する暗号化ピースとする）を鍵サーバ５３からリーチャ５０へ配信する例について説明する。ここでは、例えば、図６に示されるように暗号化ピースが生成されるものとする。また、本実施の形態にかかるTorrent Fileに含まれるファイル情報は、ピースＣ１に対応する暗号化ピースにどのようなものがあるかを示す情報を含まない。
【０１１３】
このような構成において、リーチャ５０は、鍵束を要求する要求メッセージを鍵サーバ５３に送信する際に、当該リーチャ５０を識別するためのリーチャ識別情報を要求メッセージに含ませて送信する。また、要求メッセージは、インデックス情報を含まなくても良いし、特定の暗号化ピースを除いた全てのピース（例えば、特定の暗号化ピースがピースＣ１に対応する暗号化ピースである場合はＣ２〜ＣＮ）の各インデックスのシーケンスを示すようにしても良い。
【０１１４】
また、鍵サーバ５３の鍵記憶部５３４は、各復号鍵に加え、ピースＣ１に対応する暗号化ピースを記憶する。シーケンス情報記憶部５３６は、シーケンス情報に対応して過去に鍵サーバ５３から鍵束を送信したリーチャ５０のリーチャ識別情報を記憶する。シーケンス情報照合部５３５は、リーチャ５０から送信されたリーチャ識別情報がシーケンス情報記憶部５３６に記憶されているか否かを判断し、当該判断結果に応じて、鍵束及び特定の暗号化ピースの送信の可否を決定する。鍵供給部５３７は、シーケンス情報照合部５３５の決定結果に応じて、鍵束及び暗号化ピースをリーチャ５０に送信する。
【０１１５】
（２）動作
次に、本実施の形態にかかるコンテンツ配信システムで行うコンテンツ配信処理の手順について図１２を用いて説明する。ステップＳ１〜Ｓ１３は上述の第１の実施の形態と同様である。但し、ステップＳ１でリーチャ５０が取得したTorrent Fileに、ピースＣ１に対応する暗号化ピースに関する情報が含まれないため、リーチャ５０は、各ピースＣ２〜ＣＮに各々対応する暗号化ピースを取得している。ステップＳ１０では、鍵束を要求する要求メッセージに、当該リーチャ５０を識別するためのリーチャ識別情報を含ませて鍵サーバ５３に送信する。そして、ステップＳ１４では、鍵サーバ５３は、以下の照合処理を行う。
【０１１６】
図２７は、本実施の形態にかかる照合処理の手順を示すフローチャートである。鍵サーバ５３のシーケンス情報照合部５３５は、要求メッセージに含まれるリーチャ識別情報と、シーケンス情報記憶部５３６に記憶されているリーチャ識別情報とを照合し（ステップＳ１４０Ｄ）、同一のリーチャ識別情報がシーケンス情報記憶部５３６に既に記憶されているか否かを判断する（ステップＳ１４０Ｅ）。当該判断結果が否定的である場合、シーケンス情報照合部５３５は、当該リーチャ識別情報に対応する鍵束｛K( i1, 1 ), K(1, 2 ), …, K( 1, N )｝と、ピースＣ１に対応する暗号化ピースE( K( i1, 1 ) )[ C1 ]とを送信することを決定する。そして、シーケンス情報照合部５３５は、制御部５３０を介して、当該鍵束及び暗号化ピースを当該リーチャ５０へ送信するよう鍵供給部５３７に指示する。また、シーケンス情報照合部５３５は、当該リーチャ識別情報をシーケンス情報記憶部５３６に記憶させる。鍵供給部５３７は、制御部５３０を介してシーケンス情報照合部５３５から送信を指示された鍵束及び暗号化ピースを、鍵記憶部５３４から読み出しこれらをネットワークインターフェース部５３２を介してリーチャ５０に送信する（ステップＳ１４０Ｆ）。尚、ステップＳ１４０Ｅの判断結果が肯定的である場合、即ち、リーチャ５０に対して過去に鍵サーバ５３から鍵束を送信している場合、シーケンス情報照合部５３５は、当該鍵束及び暗号化ピースを送信しないことを決定し、制御部５３０を介して、当該鍵束の当該リーチャ５０への送信禁止を鍵供給部５３７に指示する（ステップＳ１４４）。ステップＳ１５以降は上述の第１の実施の形態と同様である。
【０１１７】
以上のようにして、特定の暗号化ピースを鍵サーバ５３から配信することにより、リーチャ５０にトラッカ５１に再度アクセスさせることなく、各リーチャ５０がそれぞれ異なるシーケンスで各暗号化ピースを取得することを可能とする。従って、リーチャ５０がトラッカ５１へ再度アクセスする煩雑さを避けることができる。
【０１１８】
＜変形例３＿１＞
上述のステップＳ１４０Ｆにおいて、上述の変形例１＿７で例示した暗号化ピースの置き換えを行ってもよい。例えば、リーチャ５０が暗号化コンテンツE( K( i2, 2 ) )[ C2 ], E( K( i3, 3 ) )[ C3 ], …, E( K( iN, N ))[ CN ]を取得し、これに対応する鍵束を鍵サーバ５３へ要求したとする。鍵サーバ５３は、リーチャ５０から要求された鍵束に対応するシーケンス｛( i2, 2 ), ( i3, 3 ), …, ( iN, N )｝がシーケンス情報記憶部５３６に既に記憶されている場合（シーケンス情報照合部５３５での判定結果が否定的な場合）、シーケンス情報記憶部５３６に記憶されていない他のシーケンス｛( i2’, 2 ), ( i3, 3 ), …, ( iN, N )｝を生成して、リーチャ５０が置き換えるべき暗号化ピースE( K( i2’, 2 ) )[ C2 ]とそのインデックスに関する情報（この例では( i2’, 2 )）をリーチャ５０へ送信する。加えて、鍵サーバ５３はシーケンス｛( i1, 1 ), ( i2’, 2 ), …, ( iN, N )｝に各々対応する各復号鍵を含む鍵束とピースＣ１に対応する暗号化ピースE( K( i1, 1 ) )[ C1 ]とをリーチャ５０へ送信する。なお、リーチャ５０から要求された鍵束に対応するシーケンス｛( i2, 2 ), ( i3, 3 ), …, ( iN, N )｝がシーケンス情報記憶部５３６に未だ記憶されていない場合（シーケンス情報照合部５３５での判定結果が肯定的な場合）、鍵サーバ５３は上記に例示した置き換えを行ってもよいし、行わなくてもよい。
【０１１９】
＜変形例３＿２＞
上述の第３の実施の形態においては、特定の暗号化ピースは、ピースＣ１に対応する暗号化ピースに限らず、その数も１つに限らない。例えば、第２の実施の形態で例示した参考文献１におけるTA Codeを用いて定められる暗号化ピースを特定の暗号化ピースとしてもよい。例えば、あるノードに割り当てられたTA Codeの符号語をw=( i1 i2 … iN’ )とすると、当該ノードには暗号化ピースE( K( i1, 1 ) )[ C1 ], E( K( i2, 2 ) )[ C2 ], …, E( K( iN’, N’ ))[ CN’ ]を特定の暗号化ピースとして、鍵サーバ５３からリーチャ５０へ送信してもよい。
【０１２０】
また、特定の暗号化ピースをリーチャ５０に配信するのは、鍵サーバ５３に限らず、トラッカ５１、販売サーバ５４又は信頼できる第３者のサーバであっても良い。この場合、鍵サーバ５３は、ステップＳ１４０Ｆでは、鍵束のみリーチャ５０に送信すれば良い。
【０１２１】
＜変形例３＿３＞
上述の第３の実施の形態においては、暗号化ピース及びリーチャ識別情報を各々記憶するものは、鍵記憶部５３４及びシーケンス情報記憶部５３６に限らない。例えば、鍵サーバ５３は別途異なる記憶部を各々備え、各記憶部に暗号化ピース及びリーチャ識別情報を記憶させるようにしても良い。
【０１２２】
＜変形例３＿４＞
上述の第３の実施の形態においては、特定の暗号化ピースを鍵サーバ５３からリーチャ５０に送信するように構成したが、これに限らず、鍵サーバ５３が特定の暗号化ピースのインデックス（上述の例ではピースＣ１に対応するインデックスi1の値：(i1,1)）を指定し、そのインデックスに対応する暗号化ピースE( K( i1, 1 ) )[ C1 ]を他ノード、販売サーバ５４又は別途用意した専用サーバからリーチャ５０に送信するようにしても良い。また、鍵サーバ５３がインデックスを指定するのではなく、他ノード、販売サーバ５４又は別途用意した専用サーバが特定の暗号化ピースのインデックスを指定し、専用サーバからそのインデックスに対応する暗号化ピースをリーチャ５０に送信するようにしても良い。
【０１２３】
[第４の実施の形態]
次に、コンテンツ配信システムの第４の実施の形態について説明する。なお、上述の第１の実施の形態乃至第３の実施の形態と共通する部分については、同一の符号を使用して説明したり、説明を省略したりする。
【０１２４】
（１）構成
本実施の形態においては、Torrent Fileに含まれるファイル情報が、上述の変形例１＿１で説明したように、各暗号化ピースを用いてハッシュ演算により計算されるハッシュ値{ hash( E( K( i, j ) )[ Cj ] ) }（ただし、1≦i≦m、1≦j≦N）を含んでいるものとする（図１４参照）。上述の各実施の形態においては、シーダ５２がリーチャ５０に送信するピース情報は、図７に示されるように、当該シーダ５２が記憶している暗号化ピースのシーケンスを示すものであった。本実施の形態においては、ピース情報は、図２９に示されるように、シーダ５２が記憶している暗号化ピースの各インデックス(i, j)のうち、各ピースＣ１〜ＣＮを区別するためのインデックスjのみを示すものとする。
【０１２５】
尚、以降、各ピースＣ１〜ＣＮを区別するためのインデックスjについては、ピースインデックスと表記し、復号鍵の数に応じてバリエーションが生じるインデックスiについては、バリエーションインデックスと表記し、これらの組(i,j)を単にインデックスと表記する。また、ピースインデックスjに対応するピースについて、相異なる２つ以上の暗号鍵で各々暗号化された暗号化ピースが存在する場合これらの集合を暗号化ピース列jと適宜表記する。
【０１２６】
このような構成において、リーチャ５０のコンテンツ取得部５００は、上述のようなピース情報に基づいて、暗号化ピースをシーダ５２から取得すると、当該暗号化ピースについて、バリエーションインデックスjを特定する処理を行う。具体的には、コンテンツ取得部５００は、当該暗号化ピースを用いてハッシュ演算によりハッシュ値を計算し、Torrent Fileに含まれるファイル情報を参照して、当該ハッシュ値に対応するインデックス(i, j)のうち、当該暗号化ピースのピースインデックスjに対応するバリエーションインデックスiを特定する。
【０１２７】
（２）動作
次に、本実施の形態にかかるコンテンツ配信システムで行うコンテンツ配信処理の手順について図３０を用いて説明する。ステップＳ１〜Ｓ５は、上述の第１の実施の形態と同様である。ステップＳ６では、シーダ５２は、リーチャ５０からアクセスされると、図２９に示したように、自身の保持する暗号化ピースのピースインデックスを示すピース情報をリーチャ５０へ送信し、ステップＳ７では、リーチャ５０は、当該ピース情報を受信する。ステップＳ８では、リーチャ５０は、当該ピース情報を用いて、少なくとも１つのシーダ５２にアクセスして、各ピースＣ１〜ＣＮに各々対応して複数存在しえる暗号化ピースのうち少なくとも１つを要求するピース要求を当該シーダ５２に送信して、各暗号化ピースを受信する。シーダ５２は、リーチャ５０からのピース要求に応じて、自身の保持する暗号化ピースをリーチャ５０に送信する（ステップＳ９）。ここでは、リーチャ５０がシーダ５２Ｂにアクセスして受信したピース情報に示されるインデックスには、バリエーションインデックスが含まれていない。このため、リーチャ５０は、シーダ５２Ｂにアクセスして受信したピース情報を用いて、例えば、ピースＣ１について暗号化された暗号化ピースE( K( i1, 1 ) )[ C1 ]（i1は1≦i1≦mの整数）のうちいずれかの暗号化ピースをシーダ５２Ｂが保持しているか否かを判断し、当該判断結果が肯定的である場合、当該シーダ５２Ｂにアクセスして、ピースＣ１について暗号化された暗号化ピースのうちいずれかの暗号化ピースをシーダ５２Ｂから受信することによりこれを取得する。尚、シーダ５２ＢがピースＣ１について暗号化された暗号化ピースを実際には１つも保持していなかった場合、リーチャ５０は、次いで、他のシーダ５２（例えばシーダ５２Ｃ）にアクセスして、当該他のシーダ５２Ｃからピース情報を取得する。そして、リーチャ５０は、上述と同様にして、ピース情報を用いて、当該暗号化ピースをシーダ５２Ｃが保持しているか否かを判断して、当該判断結果が肯定的である場合、シーダ５２にアクセスして、当該暗号化ピースの取得を試みる。
【０１２８】
次いで、ステップＳ４００１では、リーチャ５０は、受信した暗号化ピースのハッシュ値を計算する。その後、ステップＳ４００２では、リーチャ５０は、図１４に示したTorrent Fileを参照して、当該ハッシュ値に対応するインデックス(i, j)のうち、当該暗号化ピースのピースインデックスjに対応するバリエーションインデックスiを特定する。ステップＳ１０は上述の第１の実施の形態と同様である。ここでリーチャ５０が鍵サーバ５３に送信する要求メッセージには、上述の第１の実施の形態と同様に、各復号鍵に対応するシーケンスを示すインデックス情報｛( i1, 1 ),…, ( iN, N)｝が含まれる。この各復号鍵に対応する各インデックス( i1, 1 ),…, ( iN, N)における各バリエーションインデックスi1,…iNは、ステップＳ４００１毎に各々特定されたものとなる。以降、ステップＳ１１〜Ｓ１６も上述の第１の実施の形態と同様である。
【０１２９】
以上のようにして、リーチャ５０が暗号化ピースを受信する前に、シーダ５２が記憶している暗号化ピースのバリエーションインデックスiを特定できないようにする。このような構成によれば、リーチャ５０が、例えばその復号鍵が漏洩したあるインデックス(i, j)に対応する暗号化ピースを取得しようとすることを抑制することができる。また、取得された暗号化ピースについては、そのバリエーションインデックスをハッシュ値及びTorrent Fileにより特定可能にしたため、リーチャ５０は、取得した各暗号化ピースの復号鍵を含む鍵束を上述の第１の実施の形態と同様にして鍵サーバ５３から取得することができる。
【０１３０】
（３）変形例
＜変形例４＿１＞
上述第４の実施の形態においては、ピース情報に示されるインデックスは、図２９に示されるものに限らず、例えば図３１に示されるように、バリエーションインデックスｊを含んでいても良い。この場合、バリエーションインデックスjには、値自体が特定されないもの（ここでは‘X’である）をセットすれば良い。また、ピース情報に示されるインデックスは、図３２に示されるように、バリエーションインデックスｊを含むものと含まないものとが混在するようにしても良い。
【０１３１】
＜変形例４＿２＞
上述第４の実施の形態においては、シーダ５２は、リーチャ５０へ暗号化ピースを送信する場合、ピース情報とは別に、当該暗号化ピースのバリエーションインデックスを示すバリエーションインデックス情報をリーチャ５０へ送信するようにしても良い。この場合、リーチャ５０は、上述のように、暗号化ピースのハッシュ値を計算する必要はない。このため、Torrent Fileに含まれるファイル情報は、各暗号化ピースのハッシュ値を含んでいなくても良い。図３３は、本変形例にかかるコンテンツ配信処理の手順を示すフローチャートである。ステップＳ１〜Ｓ８は上述の第１の実施の形態と同様である。ステップＳ４００３では、シーダ５２は、リーチャ５０へ送信する対象の暗号化ピースのバリエーションインデックスを示すバリエーションインデックス情報をリーチャ５０へ送信し、ステップＳ４００４で、リーチャ５０は当該バリエーションインデックス情報を受信する。以降、ステップＳ９〜Ｓ１６は、上述の第１の実施の形態と同様である。尚、ステップＳ４００３〜Ｓ４００４は、ステップＳ９の後であっても構わない。
【０１３２】
このような構成によれば、リーチャ５０における暗号化ピースのバリエーションインデックスの特定を容易にしつつ、例えばその復号鍵が漏洩したあるインデックス(i, j)に対応する暗号化ピースを取得しようとすることを抑制することができる。
【０１３３】
＜変形例４＿３＞
上述第４の実施の形態においては、シーダ５２は、リーチャ５０へ暗号化ピースを送信する場合、当該暗号化ピースのハッシュ値をリーチャ５０へ送信するようにしても良い。この場合も、リーチャ５０は、上述のように、暗号化ピースのハッシュ値を計算する必要はない。Torrent Fileに含まれるファイル情報は、上述の第４の実施の形態と同様に、各暗号化ピースのハッシュ値を含んでいる。図３４は、本変形例にかかるコンテンツ配信処理の手順を示すフローチャートである。ステップＳ１〜Ｓ８は上述の第１の実施の形態と同様である。ステップＳ４００５では、シーダ５２は、リーチャ５０へ送信する対象の暗号化ピースのハッシュ値をリーチャ５０へ送信し、ステップＳ４００６で、リーチャ５０は当該ハッシュ値を受信する。以降、ステップＳ９，Ｓ４００２，Ｓ１０〜Ｓ１６は、上述の第４の実施の形態と同様である。尚、ステップＳ４００５〜Ｓ４００６は、ステップＳ９の後であっても構わない。
【０１３４】
このような構成によれば、暗号化ピースのバリエーションインデックスをリーチャ５０に直接伝えることなく且つハッシュ値を伝えることで、リーチャ５０に処理負担を掛けることなく、暗号化ピースのバリエーションインデックスを特定させることができる。
【０１３５】
尚、シーダ５２が暗号化ピースのハッシュ値をリーチャ５０へ送信する場合、暗号化ピースのバリエーションインデックスの特定を、リーチャ５０が行うのではなく、鍵サーバ５３が行うようにしても良い。即ち、上述のステップＳ４００２に相当する処理を、鍵サーバ５３が行うようにする。図３５は、本変形例にかかるコンテンツ配信処理の手順を示すフローチャートである。ステップＳ１〜Ｓ８は上述の第１の実施の形態と同様である。そして、上述のステップＳ４００５〜Ｓ４００６の後、ステップＳ１０では、リーチャ５０は、各暗号化ピースを各々復号するための各復号鍵を含む鍵束を要求する要求メッセージとして、ハッシュ値を含む要求メッセージを鍵サーバ５３に送信する。ピースCjが暗号化された暗号化ピースのハッシュ値をHjとすると、要求メッセージは、インデックス情報として例えば{ ( 1, 1 ), (( X, 2 ), H2), …, ((N), HN) }を含む。このインデックス情報に含まれるインデックス( 1, 1 )では、ピースＣ１についてバリエーションインデックス‘１’が特定されていることが示され、インデックス（( X, 2 ), H2)では、ピースＣ２についてバリエーションインデックスが特定されておらずハッシュ値H2が示されており、インデックス((N), HN)では、ピースＣＮについてバリエーションインデックスが特定されておらずハッシュ値HNが示されている。
【０１３６】
次いで、ステップＳ１１では、鍵サーバ５３は、このようなハッシュ値を含む要求メッセージを受信した場合、ステップＳ１２の後、次いで、ステップＳ４００７で、ハッシュ値が示されるインデックスについて、図１４に示されるTorrent Fileを参照して、ステップＳ４００２と同様にして、当該暗号化ピースのバリエーションインデックスを特定する。
【０１３７】
このような構成によれば、リーチャ５０自身が暗号化ピースのバリエーションインデックスを特定しなくても、当該暗号化ピースを復号するための復号鍵を取得可能になる。
【０１３８】
＜変形例４＿４＞
上述の第４の実施の形態においては、リーチャ５０が暗号化ピースのハッシュ値を計算した後、当該暗号化ピースのバリエーションインデックスを特定する処理を行ったが、これに限らず、この処理を鍵サーバ５３が行うようにしても良い。この場合、鍵サーバ５３は、図１４に示されるTorrent Fileを予め取得しておく。図３６は、本変形例にかかるコンテンツ配信処理の手順を示すフローチャートである。ステップＳ１〜Ｓ８は上述の第１の実施の形態と同様である。ステップＳ４００１は上述の第４の実施の形態と同様である。ステップＳ９〜Ｓ１２は上述の第１の実施の形態と同様である。ステップＳ４００７以降は上述の変形例４＿３と同様である。
【０１３９】
このような構成によっても、リーチャ５０自身が暗号化ピースのバリエーションインデックスを特定しなくても、当該暗号化ピースを復号するための復号鍵を取得可能になる。
【０１４０】
[第５の実施の形態]
次に、コンテンツ配信システムの第５の実施の形態について説明する。なお、上述の第１の実施の形態乃至第４の実施の形態と共通する部分については、同一の符号を使用して説明したり、説明を省略したりする。
【０１４１】
（１）構成
本実施の形態においては、リーチャ５０が、１つの暗号化ピースを複数回に分けてシーダ５２に要求する場合について説明する。この場合、リーチャ５０は、暗号化ピースについて、その一部である部分データ（サブピースという）をシーダ５２に要求するピース要求（一部データ要求という）を送信する。尚、各サブピースのデータ長は、一定の長さであっても良いし、可変長でも良い。また、暗号化ピースが何個のサブピースで構成されるかについては限定されず、一定の個数にしても良いし、可変にしても良い。また、各サブピースのデータ長や、１つの暗号化ピースを構成する全部のサブピースの個数は、コンテンツ配信システムに初期値として予め設定されるようにしても良いし、Torrent Fileにおいて予め示されるようにしても良い。尚、ここでは、Torrent Fileに含まれるファイル情報は、各暗号化ピースのデータ長を含むものとし、ハッシュ値を含んでいなくても良い。
【０１４２】
＜リーチャ５０の構成＞
図３７は、本実施の形態にかかるリーチャ５０の機能的構成を例示する図である。リーチャ５０は、上述したコンテンツ取得部５００と、鍵束要求部５０１と、鍵束取得部５０２と、コンテンツ復号部５０３とに加え、サブピース完成判定部５０４と、セッション情報管理部５０５とを有する。尚、リーチャ５０は、暗号化ピースについてそのデータの全部を要求することも、サブピースを要求することもいずれも可能であるとする。前者については、上述の第１の実施の形態と略同様であるので、ここでは、後者について主に説明する。
【０１４３】
本実施の形態にかかるコンテンツ取得部５００は、ピース要求をシーダ５２に送信する際に、取得対象の暗号化ピースについて、データの一部を取得済みであるか否かを判断し、データの一部を取得済みであると判断した場合、一部データ要求を生成してこれをシーダ５２に送信する。一部データ要求は、例えば、取得対象である一部取得済み暗号化ピースを指定する指定ピースインデックス及び指定バリエーションインデックスの組（i,j）と、当該一部取得済み暗号化ピースの一部のデータであるサブピースを指定するサブピース指定情報とを示す。サブピース指定情報は、当該一部取得済み暗号化ピースの一部のデータ（サブピース）のデータ範囲を指定するものである。データ範囲は、例えば、当該サブピースの開始位置としてバイト数等で表されるオフセット値、当該サブピースの終了位置としてバイト数等で表されるオフセット値、当該サブピースのデータ長などやそれらの組み合わせなどを用いて指定される。図３８は、本実施の形態にかかるピース要求のデータ構成を例示する図である。同図においては、一部データ要求として、指定ピースインデックス及び指定バリエーションインデックスの組と、サブピース指定情報として、サブピースの開始位置及びデータ長とが示されている。この一部データ要求は、インデックス(3,4)に対応する暗号化ピースE( K( 3, 4 ) )[C4]のデータのうち、先頭位置（0バイト目）から54677バイト目を開始位置とし、当該開始位置から54676バイトを有するデータ範囲のデータが取得対象のサブピースとして指定されていることが示されている。
【０１４４】
尚、コンテンツ取得部５００は、ピース要求をシーダ５２に送信する際に、取得対象の暗号化ピースについて、データの全部を未取得であると判断した場合、上述の第１の実施形態で説明したようなピース要求を生成してこれをシーダ５２に送信する。
【０１４５】
サブピース完成判定部５０４は、コンテンツ取得部５００が暗号化ピース又はサブピースを受信した場合、当該暗号化ピース又は当該サブピースを一部とする暗号化ピースについて、その全部のデータを取得済みであるか否かを判定する完成判定処理を行う。この完成判定処理は、例えば、そのデータ長や、暗号化ピースにおけるデータの先頭位置や終了位置からデータ長を計算すること等により行う。ここでは、サブピース完成判定部５０４は、後述するセッション情報において示される取得済み量と、Torrent Fileに含まれるデータ長とを参照して、完成判定処理を行う。そして、サブピース完成判定部５０４は、判定対象の暗号化ピースについて、その全部のデータを取得済みであると判定した場合、当該暗号化ピースが複数のサブピースから構成されている場合には、当該暗号化ピースを構成する全てのサブピースを統合して、暗号化ピースを完成させる完成処理を行う。
【０１４６】
また、サブピース完成判定部５０４は、判定対象の暗号化ピースについて、その全部のデータを取得済みでないと判定した場合、後述のセッション情報を参照して、当該暗号化ピースを構成するサブピースを送信したシーダ５２にアクセスして、当該暗号化ピースを構成するサブピースのうち未だ取得していないサブピース（未取得サブピースという）を要求する一部データ要求を、コンテンツ取得部５００を介してシーダ５２に送信する。このようにして、サブピース完成判定部５０４は、コンテンツ取得部５００を介して未取得サブピースの取得を試みる。例えば、サブピース完成判定部５０４は、当該暗号化ピースを構成するサブピース全て取得するまで、未取得サブピースをシーダ５２から取得する処理を繰り返し行う。
【０１４７】
セッション情報管理部５０５は、サブピースの送信元であるシーダ５２に対して未取得サブピースを再度要求するために用いるセッション情報を生成してこれを記憶する。セッション情報は、例えば、シーダ特定情報と、取得済み量とを示す。シーダ特定情報とは、サブピースの送信元であるシーダ５２を特定する情報である。シーダ特定情報としては、例えば、シーダ５２のＩＰアドレスやポート番号や、シーダ５２のＭＡＣアドレスや上述の加入者ＩＤなどやこれらの組み合わせなどがある。取得済み量とは、暗号化ピースのうち取得済みのデータの数量を示す。取得済み量としては、例えば、暗号化ピースにおけるデータの先頭位置や取得済みのデータの終了位置から計算されるデータ長や、暗号化ピースを構成するサブピースのうち取得済みのサブピースのデータ長の合計や、当該取得済みのサブピースの個数などがある。
【０１４８】
＜シーダ５２の構成＞
シーダ５２は、一部データ要求において要求されたサブピースを外部記憶装置から読み出してこれをリーチャ５０に送信する。図３８に示された一部データ要求を受信した場合は、シーダ５２は、当該一部データ要求において示される指定ピースインデックス及び指定ピースインデックスに対応する暗号化ピースのうち、指定されたデータ範囲のデータを送信する。
【０１４９】
（２）動作
本実施の形態にかかるコンテンツ配信システムで行うコンテンツ配信処理の手順について図３９を用いて説明する。ステップＳ１〜Ｓ４の処理は、上述の第１の実施の形態と同様である。ステップＳ３００では、リーチャ５０は、暗号化ピースのダウンロード処理を行う。一方、シーダ５２は、ステップＳ３０１で、暗号化ピースのアップロード処理を行う。図４０は、ダウンロード処理及びアップロード処理の詳細な手順を示すフローチャートである。ステップＳ５〜Ｓ７の処理は、上述の第１の実施の形態と同様である。ステップＳ３１０では、リーチャ５０は、ピース要求をシーダ５２に送信する際に、取得対象の暗号化ピースについて、データの一部を取得済みであるか否かを判断する。データの一部を取得済みであると判断した場合（ステップＳ３１０：ＹＥＳ）、リーチャ５０は、セッション情報のシーダ特定情報を参照して（ステップＳ３１３）、取得対象の暗号化ピースを構成するサブピースの送信元であるシーダ５２を特定し、図３８に示されるような一部データ要求をピース要求として生成して（ステップＳ３１４）、これを当該シーダ５２に送信する（ステップＳ３１２）。尚、取得対象の暗号化ピースについて、データの全部を未取得であると判断した場合（ステップＳ３１０：ＮＯ）、リーチャ５０は、上述の第１の実施形態で説明したピース要求を生成して（ステップＳ３１１）、これをシーダ５２に送信する（ステップＳ３１２）。
【０１５０】
一方、シーダ５２は、ステップＳ３１２で送信されたピース要求を受信すると、当該ピース要求に応じた暗号化ピース又はサブピースを外部記憶装置から読み出してこれをリーチャ５０に送信する（ステップＳ３１５）。リーチャ５０は、暗号化ピース又はサブピースを受信すると（ステップＳ３１６）、セッション情報において取得済み量を更新する（ステップＳ３１７）。次いで、リーチャ５０は、ピース要求が完了したか否かを判定する（ステップＳ３１８）。ここでは、リーチャ５０は、ステップＳ３１２でサブピースを受信した場合には、当該サブピースから構成される暗号化ピースについて、セッション情報に示される取得済み量と、Torrent Fileに含まれるデータ長とを比較し、これらが一致する場合には、当該暗号化ピースについて、その全部のデータを取得済みであると判定し、ピース要求が完了したと判定する（ステップＳ３１８：ＹＥＳ）。そして、リーチャ５０は、当該暗号化ピースを構成する全てのサブピースを統合して、暗号化ピースを完成させる完成処理を行う。次いで、リーチャ５０は、他のシーダ５２にアクセスして、他の暗号化ピースを受信するか否かを判断し（ステップＳ３１９）、当該判断結果が肯定的である場合には、ステップＳ５に戻り、他のシーダ５２にアクセスする。ステップＳ３１９の判断結果が否定的である場合には、処理を終了する。
【０１５１】
一方、ステップＳ３１８で、セッション情報に示される取得済み量と、Torrent Fileに含まれるデータ長とが一致する場合には、リーチャ５０は、当該暗号化ピースについて、その全部のデータを取得済みでないと判定し、ピース要求が完了していないと判定する。この場合、リーチャ５０は、ステップＳ５に戻り、セッション情報を参照して、当該暗号化ピースを構成するサブピースを送信したシーダ５２に再度アクセスする。そして、以降の処理では、リーチャ５０は、当該暗号化ピースを構成するサブピースのうち未取得サブピースを要求する一部データ要求を生成してこれをシーダ５２に送信し、当該暗号化ピースを構成するサブピース全て取得するまで、未取得サブピースをシーダ５２から取得する処理を繰り返し行う。
【０１５２】
尚、リーチャ５０がステップＳ３１１の後、ステップＳ３１６で暗号化ピースを受信する場合、何らかの原因で暗号化ピースのデータのうち全部を受信し切れない場合がある。この場合も、ステップＳ３１５でサブピースを受信した場合と同様に、ステップＳ３１８では、リーチャ５０は、セッション情報に示される取得済み量と、Torrent Fileに含まれるデータ長とを比較することにより、ピース要求が完了したか否かと判定する。そして、ピース要求が完了していないと判定した場合、リーチャ５０は、ステップＳ５に戻り、セッション情報を参照して、当該暗号化ピースを送信したシーダ５２に再度アクセスする。そして、以降の処理では、リーチャ５０は、当該暗号化ピースのうち未取得のデータ（未取得サブピースと同様に扱う）を要求する一部データ要求を生成してこれをシーダ５２に送信する。以降は上述と同様である。一方、ステップＳ３１８で、リーチャ５０は、一度の受信でピース要求が完了したと判定した場合、上述したステップＳ３１９の処理を行う。
【０１５３】
そして、図３９に戻り、リーチャ５０は、コンテンツを構成する各ピースに各々対応する暗号化ピースであって暗号化コンテンツを構成する全ての暗号化ピースについて、全てのデータを取得すると、上述の第１の実施の形態と同様にして、ステップＳ１０以降の処理を行う。
【０１５４】
以上のような構成によれば、リーチャ５０は自身が一部取得済みの暗号化ピースについて必要なデータを取得することができることから、暗号化ピースをより早く完成させることができるようになり、その暗号化ピースを他のリーチャと共有できることから配信効率の向上が期待される。
【０１５５】
（３）変形例
＜変形例５＿１＞
上述の第５の実施の形態においては、シーダ５２は、サブピースを送信する際に、一部データ要求によって要求されたサブピースのデータの全部ではなく更に一部のデータのみを送信するようにしても良い。また、シーダ５２は、リーチャ５０に送信するサブピースと共に、当該サブピースを特定する情報を送信しても良い。サブピースを特定する情報は、上述したサブピースを指定する情報と同様の情報であっても良い。また，複数のサブピースを一度に送信する場合、これらが、１つの暗号化ピースにおいて連続するサブピースであっても、各サブピースのそれぞれについて、サブピースを特定する情報を共に送信するようにしても良いし、送信するサブピースの個数を共に送信するようにしても良い。
【０１５６】
また、シーダ５２は、ピース要求によって暗号化ピースについてそのデータの全部が要求された場合、当該暗号化ピースと共に、サブピースではなく当該暗号化ピースのデータの全部を含むことを示す情報を共に送信するようにしても良い。
【０１５７】
また、シーダ５２は、同じリーチャ５０から暗号化ピースやサブピースを要求するピース要求（新ピース要求という）を受信した際、それより以前に受信したピース要求（前ピース要求という）によって要求された暗号化ピースやサブピースについて送信が完了していないデータ量に応じて、新ピース要求による要求を拒否したり、新ピース要求による要求を保留したりしても良い。具体的には、例えば、シーダ５２は、前ピース要求によって要求されていてその送信がまだ完了しておらず送信途中である暗号化ピースやサブピースの数や送信が完了されていない前ピース要求の数などを計数し、当該数がある閾値以上であった場合には、新ピース要求による要求を拒否する。又は、シーダ５２は、送信途中のものの送信を終えて処理中である前ピース要求に応じて既に送信した暗号化ピースやサブピースの数が閾値未満になるまで新ピース要求による要求を保留する。
【０１５８】
また、リーチャ５０は、暗号化ピースやサブピースを取得する毎に取得した旨のメッセージをシーダ５２へ送信しても良い。また、このメッセージにその暗号化ピースやサブピースを識別する情報として指定ピースインデックス及び指定バリエーションインデックスの組（i,j）と、サブピースを指定する情報やハッシュ値などを含めても良い。また、取得したサブピースから暗号化ピースを完成できたときに完成できた旨のメッセージをシーダ５２へ送信しても良い。このメッセージにその暗号化ピースを識別する情報として指定ピースインデックス及び指定バリエーションインデックスの組（i,j）やハッシュ値などを含めても良い。
【０１５９】
＜変形例５＿２＞
上述の第５の実施の形態においては、一部データ要求が、更に、一部データ要求であることを示すフラグ情報を含むようにしても良い。また、１つの一部データ要求において、複数のサブピースを要求するようにしても良い。この場合、一部データ要求において、複数のサブピースのそれぞれについて、指定ピースインデックス及び指定バリエーションインデックスの組（i,j）と、サブピースを指定する情報とを示すようにしても良い。また、１つの一部データ要求で要求される複数のサブピースは、１つの暗号化ピースにおいて連続するサブピースであっても良いし、１つの暗号化ピースにおいて連続しないサブピースであっても良いし、各々異なるピースが復号される各暗号化ピースの一部であるサブピースであっても良い。一方、シーダ５２は、一部データ要求によって要求される複数のサブピースのうち少なくとも１つをリーチャ５０に送信するようにしても良い。
【０１６０】
また、一部データ要求は、一部取得済み暗号化ピースを指定する指定ピースインデックス及び指定バリエーションインデックスの組（i,j）ではなく、指定ピースインデックスjを少なくとも示すようにしても良い。この場合、シーダ５２は、一部データ要求を受信すると、当該一部取得済み暗号化ピースを指定する指定バリエーションインデックスと、サブピースを指定する情報とをリーチャ５０に問い合わせることにより、これらの情報を取得して、送信対象のサブピースを特定して当該サブピースをリーチャ５０に送信するようにしても良い。このような構成によれば、シーダ５２に対する攻撃耐性が向上し得る。
【０１６１】
また、一部データ要求は、一部取得済み暗号化ピースを用いてハッシュ演算によって計算されたハッシュ値を示し、取得対象の一部取得済み暗号化ピースを当該ハッシュ値により指定するようにしても良い。この場合、シーダ５２は、各暗号化ピースのハッシュ値を含むファイル情報を含むTorrent Fileを予め取得しておく。そして、シーダ５２は、Torrent Fileを参照して、一部データ要求によって示されたハッシュ値により指定された一部取得済み暗号化ピースを特定することができる。
【０１６２】
＜変形例５＿３＞
上述の第５の実施の形態においては、暗号化ピースを所定の個数のサブピースに分割可能に予め構成し、各サブピースに対してデータ番号（サブピースインデックスという）を予め割り当てるようにしても良い。この場合、一部データ要求に含まれるサブピース指定情報として、サブピースインデックスを用いても良い。この場合、Torrent Fileのファイル情報は、暗号化ピースを構成する全てのサブピースの個数を示すようにする。そして、リーチャ５０のサブピース完成判定部５０４は、ある暗号化ピースについてリーチャ５０取得したサブピースの個数と、当該暗号化ピースについてTorrent Fileのファイル情報に示されるサブピースの個数とを用いて完成判定処理を行うようにしても良い。
【０１６３】
＜変形例５＿４＞
上述の第５の実施の形態においては、各サブピースを用いて計算されるハッシュ値がTorrent Fileに含まれるようにしても良い。
【０１６４】
また、Torrent Fileに含まれるファイル情報が、各暗号化ピースを用いてハッシュ演算により計算されるハッシュ値を含む場合、リーチャ５０のサブピース完成判定部５０４は、以下のようにして、完成判定処理を行うようにしても良い。サブピース完成判定部５０４は、判定対象の暗号化ピースについて、サブピースを統合したもののハッシュ値を計算しこれと、Torrent Fileに含まれる、当該暗号化ピースのハッシュ値とが一致する場合に、当該暗号化ピースについて、その全部のデータを取得済みであると判定する。
【０１６５】
＜変形例５＿５＞
上述の第５の実施の形態においては、リーチャ５０のコンテンツ取得部５００は、シーダ５２においてリーチャ５０を識別できるようにするために、一部データ要求をシーダ５２位送信する際に、リーチャ５０を識別するためのリーチャ識別情報をシーダ５２に送信するようにしても良い。
【０１６６】
＜変形例５＿６＞
上述の第５の実施の形態においては、ステップＳ３１８の判定結果が否定的である場合、リーチャ５０は、サブピースの送信元であるシーダ５２に対して未取得サブピースを要求する一部データ要求を送信するのではなく、当該暗号化ピースを保持する他のシーダ５２に対して当該一部データ要求を送信するようにしても良い。
【０１６７】
また、リーチャ５０は、暗号化ピースを構成するサブピースの送信元であるシーダ５２から、当該暗号化ピースを構成する未取得サブピースを受信できなかった場合に、一定時間経過後に当該シーダに対して当該一部データ要求を送信するようにしても良いし、又は、他のシーダ５２に対して当該一部データ要求を送信するようにしても良いし、当該一部データ要求とは異なるピース要求を当該シーダ５２や他のシーダ５２に送信するようにしても良い。
【０１６８】
即ち、上述においては、リーチャ５０は、判定対象の暗号化ピースについて、その全部のデータを取得済みでないと判定した場合、当該暗号化ピースを構成するサブピース全て取得するまで、当該暗号化ピースを構成するサブピースのうち未取得サブピースをシーダ５２から取得する処理を繰り返し行うようにしたが、このような処理を行わないようにしても良い。
【０１６９】
また、リーチャ５０は、判定対象の暗号化ピースについて、その全部のデータを取得済みでないと判定した場合、未取得サブピースを取得することをせず、当該暗号化ピースについて取得済みのサブピースを破棄し、当該暗号化ピースから復号されるピースについては、暗号化ピースの取得をやり直すようにしても良い。
【０１７０】
＜変形例５＿７＞
上述のステップＳ３１３では、シーダ５２は、リーチャ５０から送信されたピース要求が不正であるか否かを判定し、判定結果に応じて、暗号化ピースやサブピースの送信を拒否するようにしても良い。図４１は、本変形例にかかるシーダ５２の機能的構成を例示する図である。シーダ５２は、コンテンツ送信部５２６と、不正要求判定部５２７と、セッション情報管理部５２８とを有する。コンテンツ送信部５２６は、リーチャ５０からのアクセスにより、ピース情報をリーチャ５０に送信したり、リーチャ５０からのピース要求を受信したり、当該ピース要求及び不正要求判定部５２７の判定結果に応じて、暗号化ピース又はサブピースをリーチャ５０に送信したりする。
【０１７１】
セッション情報管理部５２８は、暗号化ピース又はサブピースの送信に係るセッションを管理するためのセッション情報を記憶する。セッション情報は、暗号化ピース又はサブピースの送信対象であるリーチャ５０を識別するためのリーチャ識別情報と対応付けられて記憶されるものであり、暗号化ピース又はサブピースを構成する暗号化ピースのピースインデックス及びバリエーションインデックスと、送信済データ量とを含む。リーチャ識別情報は、コンテンツ送信部５２６がリーチャ５０からピース要求を受信する際に共に受信する。取得済み量とは、暗号化ピースのうち取得済みのデータの数量を示す。取得済み量としては、例えば、暗号化ピースにおけるデータの先頭位置や取得済みのデータの終了位置から計算されるデータ長や、暗号化ピースを構成するサブピースのうち取得済みのサブピースのデータ長の合計や、当該取得済みのサブピースの個数などがある。
【０１７２】
不正要求判定部５２７は、コンテンツ送信部５２６がリーチャ５０から受信したピース要求が、不正であるか否かを判定する。ここでは、ピース要求のうち一部データ要求に示されるサブピース指定情報として、データの開始位置及びデータ長を用いる。そして、例えば、所定の条件を満たした場合のみ指定しても良い開始位置（判定位置という）を所定値として予め決めておく。所定の条件とは、例えば、同じリーチャ５０が同じピースを暗号化したものである暗号化ピースを一定数以上収集しようと試みていないことが確認されることや、同じ暗号化ピースを一定数以上収集しようと試みていないことが確認されること、もしくはその両方が確認されることである。このような所定の条件を満たすか否かは、上述したセッション情報を参照して判定することができる。同じリーチャ５０か否かは、リーチャ５０から受信したリーチャ識別情報と、セッション情報によって示されるリーチャ識別情報とが同じであるか否かにより判定する。同じピースを暗号化したものである暗号化ピースであるか否かは、リーチャ５０から受信したピース要求によって指定されるピースインデックスと、セッション情報によって示されるピースインデックスとが同じであるか否かにより判定する。
【０１７３】
不正要求判定部５２７は、このような所定の条件が満たされている場合、コンテンツ送信部５２６がリーチャ５０から受信したピース要求が、不正でないと判定する。一方、このような所定の条件が満たされていない場合、コンテンツ送信部５２６がリーチャ５０からピース要求として受信した一部データ要求によって示される開始位置が、判定位置と同じか否かを判定することにより、不正であるか否かを判定する。例えば、暗号化ピースのデータの先頭位置（例えば、‘０’とする）を判定位置とする。この場合、一部データ要求によって示される開始位置が、先頭位置、即ち、‘０’か否かが判定されることになる。この判定結果が肯定的となる場合、リーチャ５０が、上述の第１の実施形態で説明したように、データの全部を未取得である場合に送信するピース要求ではなく、一部データ要求によって、暗号化ピースのデータの先頭位置からデータを要求しているということである。このような行為は、不正であると判定される。
【０１７４】
以上のような構成において、コンテンツ送信部５２６は、ピース要求が不正でないと不正要求判定部５２７が判定した場合、ピース要求に応じた暗号化ピース又はサブピースの送信を拒否して、これをリーチャ５０に送信しない。この場合、コンテンツ送信部５２６は、暗号化ピース又はサブピースの送信を拒否する旨のメッセージをリーチャ５０に送信しても良いし、送信しなくても良い。また、コンテンツ送信部５２６は、ピース要求が不正でないと不正要求判定部５２７が判定した場合、ピース要求に応じた暗号化ピース又はサブピースをリーチャ５０に送信する。
【０１７５】
一方、リーチャ５０は、ピース要求をシーダ５２に送信する毎に、当該リーチャ５０のリーチャ識別情報を当該シーダ５２に送信する。尚、送信したピース要求が不正であるとシーダ５２に判定されたり、何らかの障害があったりした場合、リーチャ５０は、シーダ５２から暗号化ピース又はサブピースを受信できない。このとき、リーチャ５０は、図４０のステップＳ３１５よりも前のいずれかのステップに戻って処理をやり直しても良い。リーチャ５０は、例えば、当該暗号化ピースの取得を試みて失敗した回数が予め定められた回数を超えた場合、又は当該暗号化ピースを取得する処理を開始してからの経過時間が予め定められた時間を超えた場合、当該シーダ５２より当該暗号化ピースを受信することができないと判断しても良い。また、不正な要求と判断された、もしくは何らかの障害があった旨の拒否メッセージをシーダ５２がリーチャ５０へ送信しても良い。リーチャ５０は、そのような拒否メッセージを受信した場合、当該シーダ５２より当該暗号化ピースを受信することができないと判断しても良い。リーチャ５０は、当該シーダ５２より当該暗号化ピースを受信することができないと判断した場合、他のシーダ５２へ接続し、当該暗号化ピースの取得を試みる。
【０１７６】
また、シーダ５２は、拒否メッセージをリーチャ５０に送信せずにリーチャ５０からのピース要求を保留しても良い。この場合、シーダ５２は、ある時間経過後に拒否メッセージをリーチャ５０に送信しても良いし、リーチャ５０との接続を強制的に切断しても良い。
【０１７７】
尚、不正要求判定部５２７が、リーチャ５０に攻撃の意図が推測されるようなピース要求を不正であると判定できれば、上述の例に限らない。また、判定位置も上述のものに限らない。また、ピース要求が不正であるか否かは、開始位置が判定位置と同じであるか否かではなく、例えば、前者が後者よりも先か後かにより判定しても良い。
【０１７８】
尚、変形例５＿３で説明したようなサブピースインデックスを用いる場合、判定位置の代わりに、判定インデックスとして、サブピースインデックスの値を用いても良い。例えば、暗号化ピースを構成する１番先頭のサブピースのサブピースインデックスの値を判定インデックス（所定値）として設定しても良い。尚、判定位置や判定インデックスは、所定値ではなく、可変であっても良い。
【０１７９】
[第６の実施の形態]
次に、コンテンツ配信システムの第６の実施の形態について説明する。なお、上述の第１の実施の形態乃至第５の実施の形態と共通する部分については、同一の符号を使用して説明したり、説明を省略したりする。
【０１８０】
（１）構成
図４２は、本実施の形態にかかるコンテンツ配信システムの構成を示す図である。本実施の形態にかかるコンテンツ配信システムの構成は、上述の第１の実施の形態乃至第５の実施の形態にかかるコンテンツ配信システムの構成とは以下の点で異なる。本実施の形態にかかるコンテンツ配信システムにおいては、リーチャ５０と、鍵サーバ５３とに接続されるResidualサーバ５５を更に備える。Residualサーバ５５は、リーチャ５０と対応付けて送信する暗号化ピースとして別途用意されている暗号化ピース（非流通暗号化ピースという）を記憶している。非流通暗号化ピースは、コンテンツを構成する各ピースＣ１〜ＣＮのうち、上述したピースＣ１〜ＣＬ(1<L≦N)が各々暗号化されたものである。但し、非流通暗号化ピースは、各ピースＣ１〜ＣＬについて、各々暗号化されて初期シーダ５２Ａに少なくとも記憶されておりＰ２ＰネットワークネットワークＮＴを介して送受信される暗号化ピース（流通暗号化ピースという）とは各々異なる暗号鍵で暗号化された暗号化ピースである。図４３は、流通暗号化ピースと、非流通暗号化ピースとを例示する図である。同図において、「1≦i≦m, 1≦j≦N」なるi,jに対する暗号化ピースE(K(i,j))[Cj]が流通暗号化ピースであり、「m+1≦i≦m´, 1≦j≦L 」なるi, jに対する暗号化ピースE(K(i,j))[Cj]が非流通暗号化ピースである。尚、流通暗号化ピースの数及び非流通暗号化ピースの数は同図に示されるものに限らない。また、本実施の形態にかかるTorrent Fileに含まれるファイル情報は、流通暗号化ピースにどのようなものがあるかを示す情報は含むが、非流通暗号化ピースにどのようなものがあるかを示す情報は含まない。
【０１８１】
＜リーチャ５０の構成＞
このような構成において、リーチャ５０は、非流通暗号化ピースを要求するピース要求（特別ピース要求という）をResidualサーバ５５に送信する。このとき、リーチャ５０は、当該リーチャ５０を識別するためのリーチャ識別情報をピース要求に含ませて送信する。尚、ここでリーチャ５０が要求する非流通暗号化ピースのピースインデックスjについては、リーチャ５０毎に初期値として予め設定されているものとする。その初期値は1≦j≦L なる j の中からランダムに選ばれたものであっても良い。このピースインデックスjの初期値は、リーチャ５０のプログラムにおいて予め設定されるようにしても良いし、他のノードからリーチャ５０に対して通知されるようにしても良いし、当該リーチャ５０が予め決定するようにしても良い。また、リーチャ５０は、Residualサーバ５５から非流通暗号化ピースE( K( i,ｊ))[ Cｊ]を受信すると、当該非流通暗号化ピースを復号するための復号鍵を要求する要求メッセージをResidualサーバ５５に送信する。
【０１８２】
＜Residual サーバ５５の構成＞
Residualサーバ５５のハードウェア構成は、上述の第１の実施の形態において説明したリーチャ５０等の各装置のハードウェア構成と略同様である。このようなハードウェア構成において、Residualサーバ５５のＣＰＵが記憶装置や外部記憶装置に記憶された各種プログラムを実行することにより実現される各種機能について説明する。図４４は、Residualサーバ５５の機能的構成を例示する図である。Residualサーバ５５は、制御部５５０と、パケット処理部５５１と、ネットワークインターフェース部５５２と、認証交換処理部５５３と、非流通暗号化ピース記憶部５５４と、リーチャ識別情報記憶部５５６と、リーチャ識別情報照合部５５５と、非流通暗号化ピース供給部５５７と、鍵記憶部５５８と、鍵供給部５５９とを有する。
【０１８３】
制御部５５０は、鍵サーバ５３全体を制御し、リーチャ識別情報照合部５５５から鍵供給部５５９への指示を仲介したりする。パケット処理部５５１は、リーチャ５０などの外部装置に送信する各種データをパケット化してネットワークインターフェース部５５２に受け渡したり、ネットワークインターフェース部５５２から受け渡されたパケットを基にデータを取得したりする。ネットワークインターフェース部５５２は、外部装置との通信を制御し、パケット処理部５５１から受け渡されたパケット化されたデータを送信したり、外部装置から受信したパケットをパケット処理部５５１に受け渡したりする。
【０１８４】
非流通暗号化ピース記憶部５５４は、非流通暗号化ピースを記憶する。リーチャ識別情報記憶部５５６は、Residualサーバ５５が非流通暗号化ピースを過去に送信したリーチャ５０のリーチャ識別情報を記憶する。リーチャ識別情報照合部５５５は、リーチャ５０から送信されたリーチャ識別情報がリーチャ識別情報記憶部５５６に記憶されているか否かを判断し、当該判断結果に応じて、非流通暗号化ピースの送信の可否を決定する。非流通暗号化ピース供給部５５７は、リーチャ識別情報照合部５５５の決定結果に応じて、制御部５５０を介して、送信対象の非流通暗号化ピースの送信が指示されると、当該非流通暗号化ピースを非流通暗号化ピース記憶部５５４を読み出しこれをリーチャ５０に送信する。
【０１８５】
認証交換処理部５５３は、ネットワークインターフェース部５５２を介して、リーチャ５０から特別ピース要求を受信し、当該リーチャ５０と相互認証を行い、認証後、要求を受理する旨の受理メッセージをリーチャ５０に送信する。鍵記憶部５５８は、例えば、ＨＤＤなどの外部記憶装置において構成され、各非流通暗号化ピースを各々復号するための各復号鍵を各々記憶する。各復号鍵は、上述したように、例えばK ( i, j )（但し、m+1≦i≦m´, 1≦j≦L）として表される。鍵供給部５５９は、非流通暗号化ピースを復号するための復号鍵を要求する要求メッセージを受信し、当該要求メッセージに応じて、当該復号鍵を鍵記憶部５５８から読み出しこれを、ネットワークインターフェース部５５２を介してリーチャ５０に送信する。
【０１８６】
（２）動作
次に、本実施の形態にかかるコンテンツ配信システムで行うコンテンツ配信処理の手順について図４５を用いて説明する。ステップＳ１〜Ｓ７は上述の第１の実施の形態と同様であるため、その図示を省略している。ステップＳ８〜Ｓ９についても上述の第１の実施の形態と同様である。ステップＳ９の後、リーチャ５０は、シーダ５２から流通暗号化ピースを受信すると、次いで、ステップＳ９６０では、次に取得するのは非流通暗号化ピースであるか否かを判断する。各ピースＣ１〜ＣＮのうち、非流通暗号化ピースに対して予め設定されているピースインデックスj以外のピースについて流通暗号化ピースを取得している場合、当該判断結果が肯定的となる。この場合、リーチャ５０は、ステップＳ９６１では、当該リーチャ５０を識別するためのリーチャ識別情報を含み、非流通暗号化ピースを要求する特別ピース要求をResidualサーバ５５に送信する。一方、ステップＳ９６０の判断結果が否定的となる場合、ステップＳ８に戻り、リーチャ５０は、シーダ５２にアクセスして、以降、各ピースＣ１〜ＣＮのうち、未だ取得していないピースが暗号化された流通暗号化ピースの取得を試みる。
【０１８７】
一方、Residualサーバ５５は、特別ピース要求を受信すると（ステップＳ９６２）、当該リーチャ５０と相互認証を行い、認証後、要求を受理する旨の受理メッセージをリーチャ５０に送信する（ステップＳ９６３）。リーチャ５０は、Residualサーバ５５から受理メッセージを受信すると（ステップＳ９６４）、Residualサーバ５５からの非流通暗号化ピースの送信を待機する。ステップＳ９６５では、Residualサーバ５５は、特別ピース要求について、以下の照合処理を行う。
【０１８８】
図４６は、本実施の形態にかかるResidualサーバ５５が行う照合処理の手順を示すフローチャートである。Residualサーバ５５のリーチャ識別情報照合部５５５は、ピース要求に含まれるリーチャ識別情報と、リーチャ識別情報記憶部５５６に記憶されているリーチャ識別情報とを照合し（ステップＳ９６５１）、同一のリーチャ識別情報がリーチャ識別情報記憶部５５６に既に記憶されているか否かを判断する（ステップＳ９６５２）。同一のリーチャ識別情報がリーチャ識別情報記憶部５５６に記憶されていないと判断した場合、リーチャ識別情報照合部５５５は、予め設定されているピースインデックスjに対応する非流通暗号化ピースE( K(i,ｊ))[Cｊ]を送信することを決定する。そして、リーチャ識別情報照合部５５５は、制御部５５０を介して、当該非流通暗号化ピースを当該リーチャ５０へ送信するよう非流通暗号化ピース供給部５５７に指示する。また、リーチャ識別情報照合部５５５は、当該リーチャ識別情報をリーチャ識別情報記憶部５５６に記憶させる。非流通暗号化ピース供給部５５７は、制御部５５０を介してリーチャ識別情報照合部５５５から送信を指示された非流通暗号化ピースを非流通暗号化ピース記憶部５５４から読み出し、これをネットワークインターフェース部５５２を介してリーチャ５０に送信する（ステップＳ９６５３）。尚、当該リーチャ５０に対して予め設定されているピースインデックスjに対応する非流通暗号化ピースE( K(i,ｊ))[Cｊ]が複数ある場合、即ち、これのバリエーションインデックスiが「２」以上存在する場合、Residualサーバ５５は、バリエーションインデックスiとして任意の値を選択して、送信対象の非流通暗号化ピースを決定する。
【０１８９】
一方、ステップＳ９６５２で、同一のリーチャ識別情報がリーチャ識別情報記憶部５５６に記憶されていると判断した場合、即ち、リーチャ５０に対して過去にResidualサーバ５５から非流通暗号化ピースを送信している場合、リーチャ識別情報照合部５５５は、当該非流通暗号化ピースを送信しないことを決定し、制御部５５０を介して、当該非流通暗号化ピースの当該リーチャ５０への送信禁止を非流通暗号化ピース供給部５５７に指示する（ステップＳ９６５４）。
【０１９０】
ここでは、ステップＳ９６５３で、非流通暗号化ピースが送信されたものとする。図４５に戻り、この場合、リーチャ５０は、非流通暗号化ピースを受信すると（ステップＳ９６６）、当該非流通暗号化ピースを復号するための復号鍵を要求する要求メッセージをResidualサーバ５５に送信する（ステップＳ９６７）。Residualサーバ５５は、当該要求メッセージを受信すると、当該要求メッセージに応じて、当該復号鍵を外部記憶装置から読み出しこれを当該リーチャ５０に送信する（ステップＳ９６８）。リーチャ５０は、Residualサーバ５５から復号鍵を受信する（ステップＳ９６９）。その後の処理の手順は図示を省略しているが、図１２に示したステップＳ１０で、リーチャ５０が取得した各流通暗号化ピースを復号するための各復号鍵を含む鍵束を要求する要求メッセージを鍵サーバ５３に送信する。以降、上述の第１の実施の形態と同様に、図１２に示したステップＳ１１〜Ｓ１６の処理がコンテンツ配信システムにおいて行われる。
【０１９１】
このような構成によれば、各ピースＣ１〜ＣＮのうち、どのピースが非流通暗号化ピースから復号されるかが秘匿され得る。このため、例えば、非流通暗号化ピースを復号したピースと、他の各ピースについて暗号化された各流通暗号化ピースの復号鍵とを暴露して、コンテンツを不正に利用可能にする攻撃を抑制することができる。
【０１９２】
＜変形例６＿１＞
上述の第６の実施の形態においては、リーチャ５０が特別ピース要求によって要求する非流通暗号化ピースE(K(i,j))[Cj] (m+1≦i≦m´, 1≦j≦L)のピースインデックスjは、予め設定されているものとしたが、予め設定されていなくても良い。その場合、特別ピース要求は、取得対象の非流通暗号化ピースのピースインデックスを指定する情報を含んでも良いし、既に取得している流通暗号化ピースの各インデックスのシーケンスを示すシーケンス情報を含むようにしても良い。
【０１９３】
尚、シーケンス情報を特別ピース要求に含ませる場合、Residualサーバ５５は、当該特別ピース要求に含まれるリーチャ識別情報とシーケンス情報との組をリーチャ識別情報記憶部５５６に記憶し、ステップＳ９６５では、リーチャ識別情報とシーケンス情報との組を用いて照合するようにしても良い。
【０１９４】
また、リーチャ５０に送信する非流通暗号化ピースのピースインデックスjを決定する主体は、Residualサーバ５５であっても良いし、鍵サーバ５３であっても良いし、シーダ５２であっても良いし、他の通信装置であっても良い。
【０１９５】
また、リーチャ５０に送信する非流通暗号化ピースのピースインデックスjは、任意の値であっても良いし、Residualサーバ５５において特別ピース要求を受信した順にインクリメントされる値であっても良い。また、コンテンツに対してコンテンツインデックスが割り当てられている場合にはコンテンツインデックスやノード情報やリーチャ識別情報などのいくつかを用いてハッシュ関数などで計算される値であっても良い。リーチャ５０に送信する非流通暗号化ピースのピースインデックスjを決定する主体は、このような情報をリーチャ５０から予め取得して、当該ピースインデックスjを決定すれば良い。
【０１９６】
また、リーチャ５０に送信する非流通暗号化ピースを何れにするのかを決定するタイミングは、特別ピース要求がリーチャ５０からResidualサーバ５５に送信された後であっても良い。
【０１９７】
また、リーチャ５０特別ピース要求によって要求する非流通暗号化ピースは、複数であっても良い。また、取得可能な非流通暗号化ピースの個数が、リーチャ５０毎に異なっていても良い。
【０１９８】
また、リーチャ５０が取得する非流通暗号化ピースのピースインデックスjは、リーチャ毎５０に異なるように設定されるようにしても良い。即ち、Residualサーバ５５は、復号されるピースがリーチャ毎５０に各々異なるように、非流通暗号化ピースをリーチャ５０に送信する。
【０１９９】
更に、リーチャ５０が取得する非流通暗号化ピースのピースインデックスj及びバリエーションインデックスiは、リーチャ毎５０に異なるように設定されるようにしても良い。即ち、Residualサーバ５５は、リーチャ毎５０に各々異なるように、非流通暗号化ピースがをリーチャ５０に送信する。
【０２００】
＜変形例６＿２＞
上述の第６の実施の形態においては、Residualサーバ５５がリーチャ５０に送信する非流通暗号化ピースE(K(i,j))[Cj] (m+1≦i≦m´, 1≦j≦L)のバリエーションインデックスiは、任意に決定するものとした。しかし、当該バリエーションインデックスiの値は、固定値であっても良いし、Residualサーバ５５において特別ピース要求を受信した順にインクリメントされる値であっても良い。また、コンテンツに対してコンテンツインデックスが割り当てられている場合にはコンテンツインデックスやノード情報やリーチャ識別情報などのいくつかを用いてハッシュ関数などで計算される値であっても良い。また、当該非流通暗号化ピースのバリエーションインデックスiの値は、当該非流通暗号化ピースのピースインデックスjの値が決定される前又は後のいずれに決定されても良い。また、非流通暗号化ピースを配られたリーチャ５０の数の分布の分散が小さくなるように、各リーチャ５０に対して送信する非流通暗号化ピースについてのバリエーションインデックスiを決定するようにしても良い。
【０２０１】
＜変形例６＿３＞
上述の第６の実施の形態においては、ステップＳ１でリーチャ５０が取得したTorrent Fileに含まれるファイル情報には、非流通暗号化ピースにどのようなものがあるかを示す情報が含まれないため、リーチャ５０は、各ピースＣ１〜ＣＮのそれぞれについて流通暗号化ピースを取得する場合がある。この場合、リーチャ５０は、流通暗号化ピースをシーダ５２に要求する際に、非流通暗号化ピースのピースインデックスjとして予め設定されているもの以外に対応する暗号化ピースを要求するようにしても良いし、当該ピースインデックスjに対応する暗号化ピースをシーダ５２から受信した場合は受信後にこれを削除するようにしても良い。
【０２０２】
また、図４５のステップＳ９でシーダ５２がリーチャ５０へ暗号化ピースを送信する際、各リーチャ５０に対して送信される非流通暗号化ピースのピースインデックスとして予め設定されているものに対応するピースについて、これが暗号化された流通暗号化ピースを当該リーチャ５０に送信しないようにしても良い。
【０２０３】
＜変形例６＿４＞
上述の第６の実施の形態においては、リーチャ５０が非流通暗号化ピースをResidualサーバ５５に要求するタイミングは、各ピースＣ１〜ＣＮのうち、非流通暗号化ピースに対して予め設定されているピースインデックスj以外のピースについて流通暗号化ピースを取得した後であるとした。しかし、これに限らず、各Ｃ１〜ＣＮのそれぞれについて流通暗号化ピースを取得する前であっても良いし、流通暗号化ピースの取得の途中やその取得と並行するタイミングであっても良い。
【０２０４】
また、リーチャ５０が非流通暗号化ピースを復号するための復号鍵をResidualサーバ５５に要求するタイミングは、リーチャ５０が取得した各流通暗号化ピースを復号するための各復号鍵を含む鍵束を要求する要求メッセージを鍵サーバ５３に送信した後であっても良いし、これと並行するタイミングであっても良い。
【０２０５】
＜変形例６＿５＞
上述の第６の実施の形態においては、リーチャ５０が非流通暗号化ピースを復号するための復号鍵を要求する要求メッセージには、どの非流通暗号化ピースに対する復号鍵かを特定するための情報として、非流通暗号化ピースのピースインデックス及びバリエーションインデックスや、非流通暗号化ピースの部分データやその部分データハッシュ値、非流通暗号化ピースのハッシュ値及びリーチャ５０の識別情報のうち少なくとも１つを含ませてResidualサーバ５５に送信しても良い。Residualサーバ５５は、このような情報を用いて特定される非流通暗号化ピースを復号するための復号鍵を非流通暗号化ピース記憶部５５４から読み出しこれをリーチャ５０に送信すれば良い。
【０２０６】
＜変形例６＿６＞
上述の第６の実施の形態においては、非流通暗号化ピースを復号するための復号鍵をResidualサーバ５５が送信するようにした。しかし、各非流通暗号化ピースを復号するための各復号鍵を鍵サーバ５３が記憶し、リーチャ５０は、流通暗号化ピースについての鍵束を要求する要求メッセージにおいて、自身が取得した非流通暗号化ピースを復号するための復号鍵を要求するようにしても良い。鍵サーバ５３は、当該要求メッセージに応じて、上述の第１の実施の形態で説明した照合処理の後、各復号鍵をリーチャ５０に送信するようにすれば良い。また、鍵サーバ５３ではなく、他の通信装置が各非流通暗号化ピースを復号するための各復号鍵を鍵サーバ５３が記憶し、リーチャ５０からの要求に応じて当該復号鍵をリーチャ５０に送信するようにしても良い。
【０２０７】
＜変形例６＿７＞
上述の第６の実施の形態においては、非流通暗号化ピースを復号するための復号鍵は、Residualサーバ５５の鍵記憶部５５８に記憶されているとしたが、Residualサーバ５５がこれを備えず、非流通暗号化ピース記憶部５５４で非流通暗号化ピースと共に記憶するようにしても良い。また、ステップＳ９６５３では、Residualサーバ５５の非流通暗号化ピース供給部５５７は、制御部５５０を介してリーチャ識別情報照合部５５５から送信を指示された非流通暗号化ピースを非流通暗号化ピース記憶部５５４から読み出すと共に、当該非流通暗号化ピースを復号するための復号鍵を読み出し、これらをネットワークインターフェース部５５２を介してリーチャ５０に送信しても良い。
【０２０８】
＜変形例６＿８＞
上述の第６の実施の形態においては、Residualサーバ５５は、流通暗号化ピースを更に記憶していても良く、リーチャ５０は、非流通暗号化ピースのみならず流通暗号化ピースを当該Residualサーバ５５に要求するようにしても良い。この場合、Residualサーバ５５は、ステップＳ９６５２で、同一のリーチャ識別情報がリーチャ識別情報記憶部５５６に記憶されていないと判断した場合、リーチャ５０に要求された非流通暗号化ピース又は流通暗号化ピースのうち少なくとも一方を当該リーチャ５０に送信すれば良い。
【０２０９】
[変形例]
なお、本発明は前記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、前記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。また、以下に例示するような種々の変形が可能である。
【０２１０】
＜変形例７＿１＞
上述した各実施の形態においては、鍵サーバ５３と、リーチャ５０とは、相互認証の後、通信対象のデータを暗号化するようにしても良い。図２８は、このような構成の鍵サーバの構成を例示する図である。鍵サーバ５３´は、上述の制御部５３０と、パケット処理部５３１と、ネットワークインターフェース部５３２と、認証・鍵交換処理部５３３と、鍵記憶部５３４と、シーケンス情報記憶部５３６と、シーケンス情報照合部５３５と、鍵供給部５３７とに加え、暗号処理部５３８を有する。認証・鍵交換処理部５３３は、リーチャ５０と、通信対象のデータを暗号化するための暗号鍵の交換を行う。暗号処理部５３８は、認証・鍵交換処理部５３３が交換した暗号鍵を用いて通信対象のデータを暗号化してこれをネットワークインターフェース部５３２を介してリーチャ５０に送信する。
【０２１１】
＜変形例７＿２＞
上述した各実施の形態においては、コンテンツの各ピースへの分割や、各ピースの暗号化は、トラッカ５１や、鍵サーバ５３や、コンテンツ製作者が用意したサーバのいずれが行っても良い。また、各暗号化ピースは、例えば、トラッカ５１、鍵サーバ５３又は信頼できる第三者（例えば、コンテンツ製作者が用意したサーバ）からシーダ５２Ａ（初期シーダ）へ与えられるものとする。
【０２１２】
また、上述した各実施の形態においては、復号鍵及び暗号鍵のうち少なくとも一方を鍵サーバ５３自体が発行して生成するようにしても良いし、トラッカ５１やコンテンツ製作者が用意したサーバが発行したり生成したりしたものを鍵サーバ５３が取得するようにしても良い。
【０２１３】
また、コンテンツＣを分割した全てのピースＣ１〜ＣＮが各々異なる暗号鍵で暗号化されているとしたが、これに限らず、一部のピースは同一の暗号鍵で暗号化されていても良い。
【０２１４】
＜変形例７＿３＞
上述した各実施の形態においては、トラッカ５１、シーダ５２及びリーチャ５０の数は、上述したものに限らない。
【０２１５】
また、Ｐ２ＰネットワークＮＴに販売サーバ５４が接続され、リーチャ５０は、販売サーバ５４からTorrent Fileを取得するようにした。しかし、販売サーバ５４はＰ２ＰネットワークＮＴに接続されていなくても良く、リーチャ５０は、例えばＣＤ−ＲＯＭなどの記録媒体に記録されたTorrent Fileを読み出すことにより、Torrent Fileを取得するようにしても良い。
【０２１６】
また、リーチャ５０は、鍵サーバ５３とネットワークを介して接続されるようにしたが、ネットワークを介さず専用線などを介して接続されるようにしてもよいし、プロキシサーバを介して接続されるようにしても良い。これにより管理能力を高めたり、プロキシサーバの後段にある鍵サーバが直接攻撃されないようにしたりすることができる。
【０２１７】
＜変形例７＿４＞
上述の第１の実施の形態乃至第６の実施の形態の一部及び全部を組み合わせても良い。尚、第２の実施の形態及び第３の実施の形態とを組み合わせた場合、Torrent Fileと同様に、シーダ情報も、鍵サーバ５３が保持する特定の暗号化ピースに関する情報を含まないようにすれば良い。
【０２１８】
＜変形例７＿５＞
上述した各実施の形態において、リーチャ５０で実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成しても良い。また、当該各種プログラムを、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ、ＤＶＤ（Digital Versatile Disk）等のコンピュータで読み取り可能な記録媒体に記録して提供するように構成しても良い。この場合には、プログラムは、リーチャ５０において上記記録媒体から読み出して実行することにより主記憶装置（例えばＲＡＭ）上にロードされ、上記機能的構成において説明した各部が主記憶装置上に生成される。シーダ５２において実現される各種プログラム、鍵サーバ５３において実現される各種プログラム、トラッカ５１において実現される各種プログラム及びResidualサーバ５５において実現される各種プログラムについても同様である。
【０２１９】
[他の態様の発明１]
前記取得手段は、前記管理サーバへアクセスするための第１アクセス情報を更に取得し、
前記第１受信手段は、取得された前記第１アクセス情報を用いて、前記管理サーバにアクセスして、前記ノード情報を受信する
ことを特徴とする請求項３に記載の通信装置。
[他の態様の発明２]
前記第２受信手段は、
受信された前記ノード情報を用いて、前記他の通信装置にアクセスして、当該他の通信装置が記憶している前記第１暗号化ピースと当該第１暗号化ピースを復号するための復号鍵との対応関係又は前記第２暗号化ピースと当該第２暗号化ピースを復号するための復号鍵との対応関係を示すピース情報を当該他の通信装置から受信する第３受信手段と、
受信された前記ピース情報を用いて、前記ファイル情報に基づいて、前記第１暗号化ピース又は前記第２暗号化ピースを前記他の通信装置から受信する第４受信手段とを有する
ことを特徴とする請求項３又は４に記載の通信装置。
[他の態様の発明３]
前記第１受信手段は、複数の他の通信装置にアクセスするためのノード情報を前記管理サーバから受信し、
前記第３受信手段は、前記第４受信手段が、前記ピース情報を用いて、前記第１暗号化ピース又は前記第２暗号化ピースを前記他の通信装置から受信できなかった場合、前記ノード情報を用いて、その他の通信装置にアクセスして、当該その他の通信装置から前記ピース情報を受信し、
前記第４受信手段は、前記その他の通信装置から受信された前記ピース情報を用いて、前記ファイル情報に基づいて、前記第１暗号化ピース又は前記第２暗号化ピースを前記その他の通信装置から受信する
ことを特徴とする他の態様の発明２に記載の通信装置。
[他の態様の発明４]
前記コンテンツ受信手段は、
受信された前記シーダ情報によって指定された前記第１暗号化ピース又は前記第２暗号化ピースに暗号化された前記ピース以外の他のピースが暗号化された前記第１暗号化ピース又は前記第２暗号化ピースのうち任意のいずれか一方を前記他の通信装置から受信する第７受信手段を有する
ことを特徴とする請求項７に記載の通信装置。
[他の態様の発明５]
前記第２暗号化ピースは、複数であり、前記複数のピースの全てを各々第２暗号鍵で暗号化することによって各々生成されるものであって、
前記コンテンツ受信手段は、前記第１暗号化ピース又は前記第２暗号化ピースをピース毎に前記他の通信装置から受信する
ことを特徴とする請求項１に記載の通信装置。
[他の態様の発明６]
前記第２暗号化ピースは、前記複数のピースのうち１つのピースを第２暗号鍵で暗号化することによって生成されるものであって、
前記コンテンツ受信手段は、前記第１暗号化ピース又は前記第２暗号化ピースをピース毎に前記他の通信装置から受信する
ことを特徴とする請求項１に記載の通信装置。
[他の態様の発明７]
前記取得手段は、複数のピースのそれぞれについて、前記第１暗号化ピースを用いて所定の演算により計算された演算値と当該第１暗号化ピースを復号するための復号鍵との対応関係又は前記第２暗号化ピースを用いて所定の演算により計算された演算値と当該第２暗号化ピースを復号するための復号鍵との対応関係を示すファイル情報を取得し、
前記第３受信手段は、前記他の通信装置にアクセスして、当該他の通信装置に記憶されている前記第１暗号化ピース又は前記第２暗号化ピースに対する前記ピースを特定するピース情報を当該他の通信装置から受信し、
前記第４受信手段は、受信された前記ピース情報を用いて、前記第１暗号化ピース又は前記第２暗号化ピースを受信し、
前記コンテンツ受信手段は、受信された前記第１暗号化ピース又は前記第２暗号化ピースを用いて前記所定の演算により演算値を計算する計算手段を更に有し、
前記鍵要求送信手段は、前記ファイル情報において前記演算値との対応関係が示される前記復号鍵を要求する要求メッセージを前記鍵サーバに送信する
ことを特徴とする請求項５に記載の通信装置。
[他の態様の発明８]
前記取得手段は、複数のピースのそれぞれについて、前記第１暗号化ピースを用いて所定の演算により計算された演算値と当該第１暗号化ピースを復号するための復号鍵との対応関係又は前記第２暗号化ピースを用いて所定の演算により計算された演算値と当該第２暗号化ピースを復号するための復号鍵との対応関係を示すファイル情報を取得し、
前記第３受信手段は、前記他の通信装置にアクセスして、当該他の通信装置に記憶されている前記第１暗号化ピース又は前記第２暗号化ピースに対する前記ピースを特定するピース情報を当該他の通信装置から受信し、
前記第４受信手段は、受信された前記ピース情報を用いて、前記ファイル情報に基づいて、前記第１暗号化ピース又は前記第２暗号化ピースを前記他の通信装置から受信し、
前記コンテンツ受信手段は、前記第１暗号化ピース又は前記第２暗号化ピースを用いて前記所定の演算により計算された演算値を前記他の通信装置から受信する演算値受信手段を更に有し、
前記鍵要求送信手段は、前記ファイル情報において前記演算値との対応関係が示される前記復号鍵を要求する要求メッセージを前記鍵サーバに送信する
ことを特徴とする請求項５に記載の通信装置。
[他の態様の発明９]
前記第３受信手段は、前記他の通信装置にアクセスして、当該他の通信装置に記憶されている前記第１暗号化ピース又は前記第２暗号化ピースに対する前記ピースを特定するピース情報を当該他の通信装置から受信し、
前記第４受信手段は、受信された前記ピース情報を用いて、前記ファイル情報に基づいて、前記第１暗号化ピース又は前記第２暗号化ピースを前記他の通信装置から受信し、
前記コンテンツ受信手段は、前記第１暗号化ピース又は前記第２暗号化ピースを用いて前記所定の演算により計算された演算値を前記他の通信装置から受信する演算値受信手段を更に有し、
前記鍵要求送信手段は、前記演算値によって特定される前記復号鍵を要求する要求メッセージを前記鍵サーバに送信する
ことを特徴とする請求項５記載の通信装置。
[他の態様の発明１０]
前記一部データ要求において指定された前記データ範囲に基づいて、当該一部データ要求が不正であるか否かを判定する判定手段を更に備え、
前記ピース送信手段は、前記一部データ要求が不正であると判定された場合、前記一部ピース要求において指定された前記データ範囲のデータを前記他の通信装置に送信しない
ことを特徴とする請求項１２に記載の通信装置。
[他の態様の発明１１]
前記ピース要求送信手段は、当該通信装置に対して予め割り当てられたピースが暗号化された前記第３暗号化ピースを要求すると共に、前記識別情報を含む特別ピース要求を通信サーバに送信する
ことを特徴とする請求項１３に記載の通信装置。
[他の態様の発明１２]
前記コンテンツ受信手段は、前記複数のピースのうち、当該通信装置に対して予め割り当てられたピース以外のピースについて前記第１暗号化ピース又は前記第２暗号化ピースを前記他の通信装置から受信する
ことを特徴とする他の態様の発明１０に記載の通信装置。
[他の態様の発明１３]
前記ピース要求送信手段は、前記第１暗号化ピース、前記第２暗号化ピース又は前記第３暗号化ピースを要求すると共に、前記識別情報を含む特別ピース要求を前記通信サーバに送信し、
前記コンテンツ受信手段は、前記特別ピース要求に従い前記通信サーバが送信した前記第１暗号化ピース、前記第２暗号化ピース又は前記第３暗号化ピースを前記他の通信装置から受信する
ことを特徴とする請求項１３に記載の通信装置。
[他の態様の発明１４]
受信された前記第３暗号化ピースを復号するための復号鍵を要求する特別要求メッセージを前記通信サーバに送信する特別鍵要求送信手段と、
前記特別要求メッセージによって要求された前記復号鍵を前記通信サーバから受信する特別鍵受信手段とを更に備える
ことを特徴とする請求項１３に記載の通信装置。
[他の態様の発明１５]
前記一部データ要求において指定された前記データ範囲に基づいて、当該一部データ要求が不正であるか否かを判定する判定手段を更に備え、
前記送信手段は、前記一部データ要求が不正であると判定された場合、前記一部データ要求において指定された前記データ範囲のデータを前記他の通信装置に送信しない
ことを特徴とする請求項１５に記載の通信装置。
[他の態様の発明１６]
前記一部データ要求は、前記データ範囲として、前記第１暗号化ピース又は前記第２暗号化ピースにおける前記データの開始位置、終了位置及び開始位置からのデータ長少なくとも１つを指定する
ことを特徴とする請求項１５に記載の通信装置。
[他の態様の発明１７]
前記第１暗号化ピース又は前記第２暗号化ピースは、所定の個数のデータに分割可能に予め構成され、各データにデータ番号が予め割り当てられており、
前記一部データ要求は、前記データ範囲として、前記データに割り当てられたデータ番号を指定する
ことを特徴とする請求項１５に記載の通信装置。
[他の態様の発明１８]
前記判定手段は、前記一部データ要求において指定された前記データ範囲が、所定値であるか否かを判定することにより、当該一部データ要求が不正であるか否かを判定する
ことを特徴とする請求項１５に記載の通信装置。
[他の態様の発明１９]
前記第１暗号化ピース又は前記第２暗号化ピースには、前記複数のピースの各々を区別するためのピースインデックスと、前記ピースに対する前記第１暗号化ピース又は前記第２暗号化ピースの各々を区別するためのバリエーションインデックスとが各々対応付けられており、
前記要求受信手段は、そのデータのうち一部を要求する前記第１暗号化ピース又は前記第２暗号化ピースを、前記ピースインデックス及び前記バリエーションインデックスにより指定する前記一部データ要求を受信する
ことを特徴とする請求項１５に記載の通信装置。
[他の態様の発明２０]
前記要求受信手段は、そのデータのうち一部を要求する前記第１暗号化ピース又は前記第２暗号化ピースを、当該第１暗号化ピース又は前記第２暗号化ピースを用いて所定の演算により計算された演算値により指定する前記一部データ要求を受信する
ことを特徴とする請求項１５に記載の通信装置。
[他の態様の発明２１]
前記第１のピース要求によって要求された前記データを送信しない場合、その旨を示す拒否メッセージを前記他の通信装置に送信する拒否送信手段を更に備える
ことを特徴とする請求項１６に記載の通信装置。
[他の態様の発明２２]
前記送信手段は、第１のピース要求が受信された場合且つ当該第１のピース要求が受信される以前に受信された第２のピース要求によって要求された前記データのうち一部又は全部の送信が完了しておらず、送信が完了していないデータの量が閾値以上である場合、前記第１のピース要求によって要求された前記データの送信を保留し、前記第２のピース要求に応じて送信が完了していないデータの全部又は一部を送信後、送信が完了していないデータの量が閾値未満になった場合、前記第１のピース要求によって要求された前記データの全部又は一部を送信する
ことを特徴とする請求項１４に記載の通信装置。
[他の態様の発明２３]
前記第２記憶手段は、前記組み合わせを示すシーケンス情報と、前記通信装置を識別する第１識別情報と、前記組み合わせにおける各前記復号鍵を前記通信装置に送信した回数とを対応付けて記憶し、
前記受信手段は、前記要求メッセージによって要求される前記各復号鍵について、前記インデックス情報と、前記通信装置を識別する第１識別情報とを前記通信装置から受信し、
前記決定手段は、前記インデックス情報によって示される前記各復号鍵の組み合わせと同じ組み合わせを示すシーケンス情報が前記第２記憶手段に記憶されている場合且つ当該シーケンス情報と前記第１識別情報とに対応して前記第２記憶手段に記憶されている前記回数が所定の回数以下である場合、当該各復号鍵を送信することを決定する
ことを特徴とする請求項１９に記載の鍵サーバ。
[他の態様の発明２４]
前記複数のピースのうち特定のピースが暗号化された特定暗号化ピースを記憶する第３記憶手段を更に備え、
前記鍵送信手段は、前記決定手段の決定結果が肯定的である場合、前記特定暗号化ピースを前記第３記憶手段から読み出してこれを前記通信装置に送信する
ことを特徴とする請求項２０に記載の鍵サーバ。
[他の態様の発明２５]
前記鍵送信手段は、前記決定手段の決定結果が肯定的である場合、前記要求メッセージによって要求された、ピース毎の前記第１暗号化ピース又は前記第２暗号化ピースを各々復号するための前記各復号鍵と、前記コンテンツの一部であって前記複数のピースとは異なるピースである特定ピースが暗号化され且つ前記他の通信装置及び前記通信装置に対応付けられた特定暗号化ピースのうち、前記通信装置に対応付けられた特定暗号化ピースを復号化するための前記復号鍵とを前記第１記憶手段から各々読み出してこれらを前記通信装置に送信する
ことを特徴とする他の態様の発明２４に記載の鍵サーバ。
他の態様の発明２６]
前記決定手段の決定結果が否定的である場合、前記第２記憶手段に記憶された前記シーケンス情報とは異なる、前記各復号鍵の組み合わせを特定する置換特定手段を更に備え、
前記鍵送信手段は、前記決定手段の決定結果が否定的である場合、特定された前記組み合わせを示す置換インデックス情報を送信する
ことを特徴とする請求項１７に記載の鍵サーバ。
[他の態様の発明２７]
前記複数のピースのそれぞれについて、前記第１暗号化ピースを用いて所定の演算により計算された演算値と当該第１暗号化ピースを復号するための復号鍵との対応関係又は前記第２暗号化ピースを用いて所定の演算により計算された演算値と当該第２暗号化ピースを復号するための復号鍵との対応関係を示すファイル情報を取得する取得手段を更に備え、
前記受信手段は、前記第１暗号化ピース又は前記第２暗号化ピースを用いて前記所定の演算により計算された演算値を含む前記要求メッセージを前記通信装置から受信し、
前記決定手段は、
前記要求メッセージに含まれる前記演算値との対応関係が前記ファイル情報において示される前記復号鍵を特定する特定手段と、
特定された前記復号鍵を含む前記各復号鍵の組み合わせに基づいて、当該各復号鍵を送信するか否かを決定する第１決定手段とを有する
ことを特徴とする請求項１７に記載の鍵サーバ。
[他の態様の発明２８]
前記第３暗号化ピースを復号するための復号鍵を記憶する第３記憶手段と、
前記復号鍵を要求する要求メッセージを前記通信装置から受信する第２受信手段と、
前記要求メッセージによって要求された前記復号鍵を前記通信装置に送信する第２送信手段とを更に備える
ことを特徴とする請求項２６に記載の通信サーバ。
[他の態様の発明２９]
コンテンツの一部である複数のピースを受信する通信装置と、少なくとも１つの他の通信装置と、当該他の通信装置にアクセスするためのノード情報を記憶する管理サーバと、鍵サーバとが通信するコンテンツ配信システムであって、
複数の第１暗号化ピースは、前記複数のピースを第１暗号鍵で暗号化することによって生成されるものであって、
第２暗号化ピースは、前記複数のピースのうち１つ以上のピースを第２暗号鍵で暗号化することによって生成されるものであって、
同一のピースを暗号化するための前記第１暗号鍵と前記第２暗号鍵とは異なっていて、
前記通信装置が、
前記アクセス情報を前記管理サーバから受信するアクセス情報受信手段と、
受信された前記ノード情報を用いて前記少なくとも１つの他の通信装置にアクセスして、前記第１暗号化ピース又は前記第２暗号化ピースをピース毎に他の通信装置から受信するコンテンツ受信手段と、
前記コンテンツ受信手段がピース毎に受信した前記第１暗号化ピース又は前記第２暗号化ピースを各々復号するための各復号鍵を要求する要求メッセージを、当該復号鍵を記憶する鍵サーバに送信する第１送信手段と、
前記要求メッセージに従い前記鍵サーバから、前記各復号鍵を受信する鍵受信手段とを備え、
前記鍵サーバが、
前記要求メッセージを前記通信装置から受信する受信手段と、
各前記復号鍵を記憶する第１記憶手段と、
前記要求メッセージによって要求された前記各復号鍵の組み合わせに基づいて、当該各復号鍵を送信するか否かを決定する決定手段と、
前記決定手段の決定結果が肯定的である場合、前記要求メッセージによって要求された前記各復号鍵を前記第１記憶手段から各々読み出してこれらを前記通信装置に送信する鍵送信手段とを備える
ことを特徴とするコンテンツ配信システム。
[他の態様の発明３０]
コンテンツ受信手段と、送信手段と、鍵受信手段とを備え、コンテンツの一部である複数のピースを受信する通信装置において実現される通信方法であって、
複数の第１暗号化ピースは、前記複数のピースを第１暗号鍵で暗号化することによって生成されるものであって、
第２暗号化ピースは、前記複数のピースのうち１つ以上のピースを第２暗号鍵で暗号化することによって生成されるものであって、
同一のピースを暗号化するための前記第１暗号鍵と前記第２暗号鍵とは異なっていて、
前記コンテンツ受信手段が、他の通信装置から、前記第１暗号化ピース又は前記第２暗号化ピースを、ピース毎に受信するコンテンツ受信ステップと、
前記送信手段が、各前記対応暗号化ピースを復号するための各復号鍵を要求する要求メッセージを、当該各復号鍵を記憶する鍵サーバに送信する送信ステップと、
前記鍵受信手段が、前記要求メッセージに従った前記鍵サーバから前記各復号鍵を受信する鍵受信ステップとを含む
ことを特徴とする通信方法。
[他の態様の発明３１]
受信手段と、決定手段と、鍵送信手段と、前記各復号鍵を記憶する記憶手段とを備え、コンテンツの一部である複数のピースを受信する通信装置と通信する鍵サーバにおいて実現される通信方法であって、
複数の第１暗号化ピースは、前記複数のピースを第１暗号鍵で暗号化することによって生成されるものであって、
第２暗号化ピースは、前記複数のピースのうち１つ以上のピースを第２暗号鍵で暗号化することによって生成されるものであって、
同一のピースを暗号化するための前記第１暗号鍵と前記第２暗号鍵とは異なっていて、
前記通信装置は、他の通信装置から、前記第１暗号化ピース又は前記第２暗号化ピースを、ピース毎に受信するものであって、
前記受信手段が、前記通信装置から、ピース毎の前記第１暗号化ピース又は前記第２暗号化ピースを復号するための各復号鍵を要求する要求メッセージを受信する受信ステップと、
前記決定手段が、前記要求メッセージによって要求された前記各復号鍵の組み合わせに基づいて、当該各復号鍵を送信するか否かを決定する決定ステップと、
前記鍵送信手段が、前記決定手段の決定結果が肯定的である場合、前記要求メッセージによって要求された前記組み合わせにおける前記各復号鍵を前記記憶手段から各々読み出してこれらを前記通信装置に送信する鍵送信ステップとを含む
ことを特徴とする通信方法。
[他の態様の発明３２]
決定手段と、送信手段と、記憶手段とを備え、コンテンツの一部である複数のピースを受信する通信装置と通信する管理サーバにおいて実現される通信方法であって、
複数の第１暗号化ピースは、前記複数のピースを第１暗号鍵で暗号化することによって生成されるものであって、
第２暗号化ピースは、前記複数のピースのうち１つ以上のピースを第２暗号鍵で暗号化することによって生成されるものであって、
同一のピースを暗号化するための前記第１暗号鍵と前記第２暗号鍵とは異なっていて、
前記通信装置は、他の通信装置から、前記第１暗号化ピース又は前記第２暗号化ピースを、ピース毎に受信するものであって、
前記記憶手段には、前記他の通信装置にアクセスするための接続先情報が記憶され、
前記決定手段が、各前記ピースのうち少なくとも１つのピースについて、当該少なくとも１つのピースが暗号化された前記第１暗号化ピース又は前記第２暗号化ピースを決定する決定ステップと、
前記送信手段が、前記通信装置に対して、前記他の通信装置にアクセスするための接続先情報を前記記憶手段から読み出してこれと、決定された前記第１暗号化ピース又は前記第２暗号化ピースを指定するシーダ情報とを送信する送信ステップとを含む
ことを特徴とする通信方法。
[他の態様の発明３３]
第１記憶手段と、第２記憶手段と、第１受信手段と、第１送信手段とを備え、コンテンツの一部である複数のピースを受信する通信装置と通信する通信サーバで実現される通信方法であって、
複数の第１暗号化ピースは、前記複数のピースを第１暗号鍵で暗号化することによって生成されるものであって、
第２暗号化ピースは、前記複数のピースのうち１つ以上のピースを第２暗号鍵で暗号化することによって生成されるものであって、
第３暗号化ピースは、前記複数のピースのうち１つ以上のピースを第３暗号鍵で暗号化することによって生成されるものであって、
同一のピースを暗号化するための前記第１暗号鍵と前記第２暗号鍵と前記第３暗号鍵とは異なっていて、
前記通信装置は、他の通信装置から、前記第１暗号化ピース又は前記第２暗号化ピースを、ピース毎に受信するものであって、
前記第１記憶手段には、前記第３暗号化ピースが記憶され、
前記第２記憶手段には、前記第３暗号化ピースを前記通信装置に送信した場合に当該通信装置を識別するための識別情報が記憶され、
前記第１受信手段が、前記第３暗号化ピースを要求すると共に前記通信装置を識別するための識別情報を含む特別ピース要求を前記通信装置から受信する第１受信ステップと、
前記第１送信手段が、前記特別ピース要求に含まれる前記識別情報が前記第２記憶手段に記憶されていない場合、前記第１記憶手段から前記第３暗号化ピースを読み出して前記通信装置に送信する第１送信ステップとを含む
ことを特徴とする通信方法。
【図面の簡単な説明】
【０２２０】
【図１】第１の実施の形態にかかるコンテンツ配信システムの構成を示すブロック図である。
【図２】コンテンツが複数のピースに分割された状態を模式的に示す図である。
【図３】各暗号化ピースを模式的に示す図である。
【図４】シーダ５２Ａが記憶している各暗号化ピースを例示する図である。
【図５】シーダ５２Ａが記憶している各暗号化ピースを例示する図である。
【図６】シーダ５２Ａが記憶している各暗号化ピースを例示する図である。
【図７】ピース情報のデータ構成を例示する図である。
【図８】リーチャ５０の機能的構成を例示する図である。
【図９】Torrent Fileを例示する図である。
【図１０】鍵サーバ５３の機能的構成を例示する図である。
【図１１】ノード情報のデータ構成を例示する図である。
【図１２】コンテンツ配信処理の手順を示すフローチャートである。
【図１３】照合処理の手順を示すフローチャートである。
【図１４】同実施形態の一変形例にかかるTorrent Fileのデータ構成を例示する図である。
【図１５】同実施形態の一変形例にかかるハッシュ値を含むインデックス情報を例示する図である。
【図１６】同実施形態の一変形例にかかる照合処理の手順を示すフローチャートである。
【図１７】第２の実施の形態にかかるトラッカ５１の機能的構成を示すブロック図である。
【図１８】シーダデータベース５１２のデータ構成を例示する図である。
【図１９】シーダ情報を例示する図である。
【図２０】コンテンツ配信処理を示すフローチャートである。
【図２１】インデックス生成処理の手順を示すフローチャートである。
【図２２】シーダ情報を例示する図である。
【図２３】同実施形態の一変形例にかかるシーダ情報を例示する図である。
【図２４】同実施形態の一変形例にかかるシーダ情報を例示する図である。
【図２５】同実施形態の一変形例にかかるハッシュ値を含み、接続先情報を含まないシーダ情報を例示する図である。
【図２６】同実施形態の一変形例にかかるインデックス生成処理の手順を示すフローチャートである。
【図２７】第３の実施の形態にかかる照合処理の手順を示すフローチャートである。
【図２８】一変形例にかかる鍵サーバの構成を例示する図である。
【図２９】第４の実施の形態にかかるピース情報のデータ構成を例示する図である。
【図３０】同実施の形態にかかるコンテンツ配信処理の手順を示すフローチャートである。
【図３１】一変形例にかかるピース情報のデータ構成を例示する図である。
【図３２】一変形例にかかるピース情報のデータ構成を例示する図である。
【図３３】一変形例にかかるコンテンツ配信処理の手順を示すフローチャートである。
【図３４】一変形例にかかるコンテンツ配信処理の手順を示すフローチャートである。
【図３５】一変形例にかかるコンテンツ配信処理の手順を示すフローチャートである。
【図３６】一変形例にかかるコンテンツ配信処理の手順を示すフローチャートである。
【図３７】第５の実施の形態にかかるリーチャ５０の機能的構成を例示する図である。
【図３８】同実施の形態にかかるピース要求のデータ構成を例示する図である。
【図３９】同実施の形態にかかるコンテンツ配信処理の手順を示すフローチャートである。
【図４０】同実施の形態にかかるダウンロード処理及びアップロード処理の詳細な手順を示すフローチャートである。
【図４１】一変形例にかかるシーダ５２の機能的構成を例示する図である。
【図４２】第６の実施の形態にかかるコンテンツ配信システムの構成を示す図である。
【図４３】同実施の形態にかかる流通暗号化ピースと、非流通暗号化ピースとを例示する図である。
【図４４】同実施の形態にかかるResidualサーバ５５の機能的構成を例示する図である。
【図４５】同実施の形態にかかるコンテンツ配信処理の手順を示すフローチャートである。
【図４６】同実施の形態にかかるResidualサーバ５５が行う照合処理の手順を示すフローチャートである。
【符号の説明】
【０２２１】
５０，５０Ａ，５０Ｂ リーチャ（通信装置）
５１ トラッカ（管理サーバ）
５２，５２Ａ，５２Ｂ，５２Ｃ シーダ（通信装置）
５３ 鍵サーバ
５４ 販売サーバ
５００ コンテンツ取得部（コンテンツ受信手段）
５０１ 鍵束要求部（送信手段）
５０２ 鍵束取得部（鍵受信手段）
５０３ コンテンツ復号部（復号手段）
５０４ サブピース完成判定部
５０５ セッション情報管理部
５１０ インデックス生成部（決定手段）
５１１ シーダ情報生成部（生成手段、送信手段）
５１２ シーダデータベース（第１記憶手段）
５１３ インデックスデータベース（第２記憶手段）
５２６ コンテンツ送信部
５２７ 不正要求判定部
５２８ セッション情報管理部
５３０ 制御部
５３１ パケット処理部
５３２ ネットワークインターフェース部（受信手段、送信手段）
５３３ 認証・鍵交換処理部
５３４ 鍵記憶部（第１記憶手段）
５３５ シーケンス情報照合部（決定手段）
５３６ シーケンス情報記憶部（第２記憶手段）
５３７ 鍵供給部（送信手段）
５３８ 暗号処理部
５５０ 制御部
５５１ パケット処理部
５５２ ネットワークインターフェース部
５５３ 認証交換処理部
５５４ 非流通暗号化ピース記憶部
５５５ リーチャ識別情報照合部
５５６ リーチャ識別情報記憶部
５５７ 非流通暗号化ピース供給部
５５８ 鍵記憶部
５５９ 鍵供給部
ＮＴ Ｐ２Ｐネットワーク

【特許請求の範囲】
【請求項１】
コンテンツの一部である複数のピースを受信する通信装置であって、
複数の第１暗号化ピースは、前記複数のピースを第１暗号鍵で暗号化することによって生成されるものであって、
第２暗号化ピースは、前記複数のピースのうち１つ以上のピースを第２暗号鍵で暗号化することによって生成されるものであって、
同一のピースを暗号化するための前記第１暗号鍵と前記第２暗号鍵とは異なっていて、
他の通信装置から、前記第１暗号化ピース又は前記第２暗号化ピースをピース毎に受信するコンテンツ受信手段と、
前記コンテンツ受信手段がピース毎に受信した前記第１暗号化ピース又は前記第２暗号化ピースを復号するための各復号鍵を要求する要求メッセージを、当該各復号鍵を記憶する鍵サーバに送信する鍵要求送信手段と、
前記要求メッセージに従った前記鍵サーバから前記各復号鍵を受信する鍵受信手段とを備える
ことを特徴とする通信装置。
【請求項２】
前記複数のピースのそれぞれについて、前記ピースが暗号化された前記第１暗号化ピース又は前記第２暗号化ピースのうち全部又は一部を示すファイル情報を取得する取得手段を更に備え、
前記コンテンツ受信手段は、前記ファイル情報に基づいて、前記第１暗号化ピース又は前記第２暗号化ピースを前記他の通信装置から受信する
ことを特徴とする請求項１に記載の通信装置。
【請求項３】
前記コンテンツ受信手段は、
前記第１暗号化ピース又は前記第２暗号化ピースのうち少なくとも一方を記憶する他の通信装置にアクセスするためのノード情報を管理サーバから受信する第１受信手段と、
受信された前記ノード情報を用いて、前記他の通信装置にアクセスして、前記ファイル情報に基づいて、前記第１暗号化ピース又は前記第２暗号化ピースを前記他の通信装置から受信する第２受信手段とを有する
ことを特徴とする請求項２に記載の通信装置。
【請求項４】
前記第２受信手段は、前記ファイル情報によって示される前記第１暗号化ピース又は前記第２暗号化ピースの全ての中から、前記複数のピースのうち少なくとも１つのピースについて、前記第１暗号化ピース又は前記第２暗号化ピースを受信する
ことを特徴とする請求項３に記載の通信装置。
【請求項５】
前記コンテンツ受信手段は、
前記他の通信装置が記憶している前記第１暗号化ピースと当該第１暗号化ピースを復号するための復号鍵との対応関係又は前記第２暗号化ピースと当該第２暗号化ピースを復号するための復号鍵との対応関係を示すピース情報を当該他の通信装置から受信する第３受信手段と、
受信された前記ピース情報を用いて、前記ファイル情報に基づいて、前記第１暗号化ピース又は前記第２暗号化ピースを前記他の通信装置から受信する第４受信手段とを有する
ことを特徴とする請求項２乃至４のいずれか一項に記載の通信装置。
【請求項６】
前記鍵要求送信手段は、前記要求メッセージによって要求する、前記各ピースに各々対応する各前記復号鍵の組み合わせを示すインデックス情報を前記鍵サーバに送信し、
前記鍵受信手段は、前記要求メッセージに従った前記鍵サーバから前記各復号鍵を当該鍵サーバから受信する
ことを特徴とする請求項１乃至５のいずれか一項に記載の通信装置。
【請求項７】
前記コンテンツ受信手段は、
前記複数のピースのうち少なくとも１つのピースが暗号化された前記第１暗号化ピース又は前記第２暗号化ピースを指定するシーダ情報を管理サーバから受信する第５受信手段と、
受信された前記シーダ情報によって指定された前記第１暗号化ピース又は前記第２暗号化ピースを記憶する他の通信装置にアクセスして、当該第１暗号化ピース又は前記第２暗号化ピースを受信する第６受信手段とを有する
ことを特徴とする請求項１乃至６のいずれか一項に記載の通信装置。
【請求項８】
前記コンテンツ受信手段は、前記コンテンツの一部であって前記複数のピースとは異なる特定ピースが暗号化された特定暗号化ピースを前記鍵サーバ、前記管理サーバ及び他のサーバのうち少なくとも１つから受信し、
前記鍵要求送信手段は、前記特定暗号化ピースを復号するための復号鍵を要求する要求メッセージを前記鍵サーバに送信し、
前記鍵受信手段は、前記要求メッセージに従った前記鍵サーバから、前記特定暗号化ピースを復号化するための復号鍵を受信する
ことを特徴とする請求項１乃至７のいずれか一項に記載の通信装置。
【請求項９】
特定暗号化ピースは、前記コンテンツの一部であって前記複数のピースとは異なるピースである特定ピースが暗号化され且つ他の通信装置及び当該通信装置に対応付けられたものであって、
前記コンテンツ受信手段は、当該通信装置に対応付けられた特定暗号化ピースを、当該特定暗号化ピースを記憶する他の通信装置、前記鍵サーバ、前記管理サーバ及び他のサーバのうち少なくとも１つから受信し、
前記鍵要求送信手段は、前記特定暗号化ピースとを復号するための復号鍵を要求する要求メッセージを、当該復号鍵を記憶する鍵サーバに送信し、
前記鍵受信手段は、前記要求メッセージに従った前記鍵サーバから前記特定暗号化ピースを復号化するための各復号鍵のうち全部又は一部を受信する
ことを特徴とする請求項１乃至８のいずれか一項に記載の通信装置。
【請求項１０】
受信された前記各復号鍵を用いて、前記第１暗号化ピース又は前記第２暗号化ピースをピース毎に各々復号する復号手段を更に備える
ことを特徴とする請求項１乃至９のいずれか一項に記載の通信装置。
【請求項１１】
前記第１暗号化ピース又は前記第２暗号化ピースを復号するための復号鍵には、前記複数のピースの各々を区別するためのピースインデックスと、前記ピースに対する前記第１暗号化ピース又は前記第２暗号化ピースの各々を区別するためのバリエーションインデックスとが各々対応付けられており、
前記取得手段は、複数のピースのそれぞれについて、前記ピースインデックス及びバリエーションインデックスを示すファイル情報を取得し、
前記第３受信手段は、前記他の通信装置にアクセスして、当該他の通信装置に記憶されている前記第１暗号化ピース又は前記第２暗号化ピースに対するピースを区別するためのピースインデックスを示すピース情報を当該他の通信装置から受信し、
前記第４受信手段は、受信された前記ピース情報を用いて、前記ファイル情報に基づいて、前記第１暗号化ピース又は前記第２暗号化ピースを前記他の通信装置から受信し、
前記コンテンツ受信手段は、前記第１暗号化ピース又は前記第２暗号化ピースの前記ピースインデックスに対応する前記バリエーションインデックスを示すバリエーションインデックス情報を前記他の通信装置から受信するバリエーション受信手段とを更に有し、
前記鍵要求送信手段は、前記ピースインデックス及び前記バリエーションインデックスによって特定される前記復号鍵を要求する要求メッセージを前記鍵サーバに送信する
ことを特徴とする請求項５に記載の通信装置。
【請求項１２】
前記第１暗号化ピース又は前記第２暗号化ピースをピース毎に記憶する記憶手段と、
前記第１暗号化ピース又は前記第２暗号化ピースのデータのうち一部又は全部を要求するピース要求を他の通信装置から受信する要求受信手段と、
前記ピース要求によって要求された前記第１暗号化ピース又は前記第２暗号化ピースのデータのうち一部又は全部を前記他の通信装置に送信するピース送信手段とを更に備え、
前記要求受信手段は、前記第１暗号化ピース又は前記第２暗号化ピースのデータのうち一部を要求するピース要求として、当該前記第１暗号化ピース又は前記第２暗号化ピースのデータのうち一部のデータ範囲を指定する一部データ要求を受信し、
前記ピース送信手段は、前記一部データ要求によって指定された前記データ範囲のデータを前記他の通信装置に送信する
ことを特徴とする請求項１乃至１１のいずれか一項に記載の通信装置。
【請求項１３】
第３暗号化ピースは、前記複数のピースのうち１つ以上のピースを第３暗号鍵で暗号化することによって生成されるものであって、
同一のピースを暗号化するための前記第１暗号鍵と前記第２暗号鍵と前記第３暗号鍵とは異なっていて、
前記第３暗号化ピースを要求すると共に、当該通信装置を識別するための識別情報を含む特別ピース要求を通信サーバに送信するピース要求送信手段を更に備え、
前記コンテンツ受信手段は、前記特別ピース要求に従い前記通信サーバが送信した前記第３暗号化ピースを受信する
ことを特徴とする請求項１乃至１２のいずれか一項に記載の通信装置。
【請求項１４】
コンテンツの一部である複数のピースを送信する通信装置であって、
複数の第１暗号化ピースは、前記複数のピースを第１暗号鍵で暗号化することによって生成されるものであって、
第２暗号化ピースは、前記複数のピースのうち１つ以上のピースを第２暗号鍵で暗号化することによって生成されるものであって、
同一のピースを暗号化するための前記第１暗号鍵と前記第２暗号鍵とは異なっていて、
前記第１暗号化ピース又は前記第２暗号化ピースをピース毎に記憶する記憶手段と、
前記第１暗号化ピース又は前記第２暗号化ピースのデータのうち一部又は全部を要求するピース要求を他の通信装置から受信する要求受信手段と、
前記ピース要求によって要求された前記第１暗号化ピース又は前記第２暗号化ピースのデータのうち一部又は全部を前記他の通信装置に送信する送信手段とを備える
ことを特徴とする通信装置。
【請求項１５】
前記要求受信手段は、前記第１暗号化ピース又は前記第２暗号化ピースのデータのうち一部を要求するピース要求として、前記第１暗号化ピース又は前記第２暗号化ピースのデータのうち一部のデータ範囲を指定する一部データ要求を受信し、
前記送信手段は、前記一部データ要求によって指定された前記データ範囲のデータを前記他の通信装置に送信する
ことを特徴とする請求項１４に記載の通信装置。
【請求項１６】
前記送信手段は、第１のピース要求が受信された場合且つ当該第１のピース要求が受信される以前に受信された第２のピース要求によって要求された前記データのうち一部又は全部の送信が完了しておらず、送信が完了していないデータの量が閾値以上である場合、前記第１のピース要求によって要求された前記データを送信しない
ことを特徴とする請求項１４又は１５に記載の通信装置。
【請求項１７】
コンテンツの一部である複数のピースを受信する通信装置と通信する鍵サーバであって、
複数の第１暗号化ピースは、前記複数のピースを第１暗号鍵で暗号化することによって生成されるものであって、
第２暗号化ピースは、前記複数のピースのうち１つ以上のピースを第２暗号鍵で暗号化することによって生成されるものであって、
同一のピースを暗号化するための前記第１暗号鍵と前記第２暗号鍵とは異なっていて、
前記通信装置は、他の通信装置から、前記第１暗号化ピース又は前記第２暗号化ピースをピース毎に受信するものであって、
前記通信装置から、ピース毎の前記第１暗号化ピース又は前記第２暗号化ピースを復号するための各復号鍵を要求する要求メッセージを受信する受信手段と、
前記各復号鍵を記憶する第１記憶手段と、
前記要求メッセージによって要求された前記各復号鍵の組み合わせに基づいて、当該各復号鍵を送信するか否かを決定する決定手段と、
前記決定手段の決定結果が肯定的である場合、前記要求メッセージによって要求された前記組み合わせにおける前記各復号鍵を前記第１記憶手段から各々読み出してこれらを前記通信装置に送信する鍵送信手段とを備える
ことを特徴とする鍵サーバ。
【請求項１８】
前記各ピースに対応して既に送信した前記各復号鍵の組み合わせを示すシーケンス情報を記憶する第２記憶手段を備え、
前記決定手段は、前記要求メッセージによって要求された前記各復号鍵の組み合わせを示すシーケンス情報が、前記第２記憶手段に記憶されているか否かを判断することにより、当該各復号鍵を送信するか否かを決定する
ことを特徴とする請求項１７に記載の鍵サーバ。
【請求項１９】
前記受信手段は、要求メッセージによって要求される前記各復号鍵の組み合わせを示すインデックス情報を前記通信装置から受信し、
前記決定手段は、前記インデックス情報によって示される前記各復号鍵の組み合わせに基づいて、当該各復号鍵を送信するか否かを決定する
ことを特徴とする請求項１７又は１８に記載の鍵サーバ。
【請求項２０】
前記鍵送信手段は、前記決定手段の決定結果が肯定的である場合、前記要求メッセージによって要求された、ピース毎の前記第１暗号化ピース又は前記第２暗号化ピースを各々復号するための前記各復号鍵と、前記コンテンツの一部であって前記複数のピースとは異なる特定ピースが暗号化された特定暗号化ピースを復号化するための前記復号鍵とを前記第１記憶手段から各々読み出してこれらを前記通信装置に送信する
ことを特徴とする請求項１７乃至１９のいずれか一項に記載の鍵サーバ。
【請求項２１】
コンテンツの一部である複数のピースを受信する通信装置と通信する管理サーバであって、
複数の第１暗号化ピースは、前記複数のピースを第１暗号鍵で暗号化することによって生成されるものであって、
第２暗号化ピースは、前記複数のピースのうち１つ以上のピースを第２暗号鍵で暗号化することによって生成されるものであって、
同一のピースを暗号化するための前記第１暗号鍵と前記第２暗号鍵とは異なっていて、
前記通信装置は、他の通信装置から、前記第１暗号化ピース又は前記第２暗号化ピースをピース毎に受信するものであって、
前記他の通信装置にアクセスするための接続先情報を記憶する第１記憶手段と、
前記複数のピースのうち少なくとも１つのピースについて、当該少なくとも１つのピースが暗号化された前記第１暗号化ピース又は前記第２暗号化ピースを決定する決定手段と、
前記通信装置に対して、前記他の通信装置にアクセスするための接続先情報を前記第１記憶手段から読み出してこれと、決定された前記第１暗号化ピース又は前記第２暗号化ピースを指定するシーダ情報とを送信する送信手段と
を備えることを特徴とする管理サーバ。
【請求項２２】
前記送信手段は、決定された前記第１暗号化ピースと当該第１暗号化ピースを復号するための復号鍵との対応関係を示すインデックス情報又は前記第２暗号化ピースと当該第２暗号化ピースを復号するための復号鍵との対応関係を示すインデックス情報を含む前記シーダ情報を前記通信装置に送信する
ことを特徴とする請求項２１に記載の管理サーバ。
【請求項２３】
前記第１暗号化ピースと当該第１暗号化ピースを復号するための復号鍵との対応関係又は前記第２暗号化ピースと当該第２暗号化ピースを復号するための復号鍵との対応関係に対して、それを示す前記シーダ情報が前記通信装置に送信されたか否かを記憶する第２記憶手段を備え、
前記決定手段は、前記ピースに対応する前記第１暗号化ピース又は前記第２暗号化ピースのうち、前記復号鍵との対応関係においてそれを示す前記シーダ情報が前記通信装置に送信されたことが前記第２記憶手段に記憶されていない前記第１暗号化ピース又は前記第２暗号化ピースを決定する
ことを特徴とする請求項２１又は２２に記載の管理サーバ。
【請求項２４】
前記コンテンツの一部であって前記複数のピースとは異なるピースである特定ピースが暗号化された特定暗号化ピースを、前記他の通信装置及び前記通信装置のうち少なくとも一方に一意に割り当てる割当手段を更に備える
ことを特徴とする請求項２１乃至２３のいずれか一項に記載の管理サーバ。
【請求項２５】
前記第１記憶手段は、各前記ピースに各々対応する前記第１暗号化ピース又は前記第２暗号化ピースについて、前記第１暗号化ピースと当該第１暗号化ピースを復号するための復号鍵との対応関係と当該第１暗号化ピースを記憶する他の通信装置の前記接続先情報とを対応付けて記憶し又は前記第２暗号化ピースと当該第２暗号化ピースを復号するための復号鍵との対応関係と当該第２暗号化ピースを記憶する他の通信装置の前記接続先情報とを対応付けて記憶し、
前記決定手段は、前記少なくとも１つのピースが暗号化された前記第１暗号化ピース又は前記第２暗号化ピースを決定すると共に、決定された前記第１暗号化ピース又は前記第２暗号化ピースに対応して前記第１記憶手段に記憶された前記接続先情報を参照して、決定した前記第１暗号化ピース又は前記第２暗号化ピースを記憶する他の通信装置を特定し、
前記送信手段は、特定された前記他の通信装置の前記接続先情報を前記シーダ情報に含めて前記通信装置に送信する
ことを特徴とする請求項２１乃至２４のいずれか一項に記載の管理サーバ。
【請求項２６】
コンテンツの一部である複数のピースを受信する通信装置と通信する通信サーバであって、
複数の第１暗号化ピースは、前記複数のピースを第１暗号鍵で暗号化することによって生成されるものであって、
第２暗号化ピースは、前記複数のピースのうち１つ以上のピースを第２暗号鍵で暗号化することによって生成されるものであって、
第３暗号化ピースは、前記複数のピースのうち１つ以上のピースを第３暗号鍵で暗号化することによって生成されるものであって、
同一のピースを暗号化するための前記第１暗号鍵と前記第２暗号鍵と前記第３暗号鍵とは異なっていて、
前記通信装置は、他の通信装置から、前記第１暗号化ピース又は前記第２暗号化ピースをピース毎に受信するものであって、
前記第３暗号化ピースを記憶する第１記憶手段と、
前記第３暗号化ピースを前記通信装置に送信した場合に当該通信装置を識別するための識別情報を記憶する第２記憶手段と、
前記第３暗号化ピースを要求すると共に前記通信装置を識別するための識別情報を含む特別ピース要求を前記通信装置から受信する第１受信手段と、
前記特別ピース要求に含まれる前記識別情報が前記第２記憶手段に記憶されていない場合、前記第１記憶手段から前記第３暗号化ピースを読み出して前記通信装置に送信する第１送信手段とを備える
ことを特徴とする通信サーバ。
【請求項２７】
前記第１送信手段は、前記特別ピース要求に含まれる前記識別情報が前記第２記憶手段に記憶されていない場合、復号される前記ピースが通信装置毎に異なるように、前記第３暗号化ピースを前記第１記憶手段から読み出して前記通信装置に送信する
ことを特徴とする請求項２６に記載の通信サーバ。
【請求項２８】
前記第１記憶手段は、前記第１暗号化ピース及び前記第２暗号化ピースのうち少なくとも一つを更に記憶しており、
前記第１受信手段は、前記第１暗号化ピース、前記第２暗号化ピース及び前記第３暗号化ピースを要求すると共に前記通信装置を識別するための識別情報を含むピース要求を前記通信装置から受信し、
前記第１送信手段は、前記特別ピース要求に含まれる前記識別情報が前記第２記憶手段に記憶されていない場合、前記特別ピース要求によって要求された前記第１暗号化ピース、前記第２暗号化ピース及び前記第３暗号化ピースを前記第１記憶手段から読み出して前記通信装置に送信する
ことを特徴とする請求項２６又は２７に記載の通信サーバ。
【請求項２９】
コンテンツの一部である複数のピースを受信する通信装置の有するコンピュータに実行させるためのプログラムであって、
複数の第１暗号化ピースは、前記複数のピースを第１暗号鍵で暗号化することによって生成されるものであって、
第２暗号化ピースは、前記複数のピースのうち１つ以上のピースを第２暗号鍵で暗号化することによって生成されるものであって、
同一のピースを暗号化するための前記第１暗号鍵と前記第２暗号鍵とは異なっていて、
他の通信装置から、前記第１暗号化ピース又は前記第２暗号化ピースをピース毎に受信するコンテンツ受信ステップと、
前記コンテンツ受信ステップでピース毎に受信した前記第１暗号化ピース又は前記第２暗号化ピースを復号するための各復号鍵を要求する要求メッセージを、当該各復号鍵を記憶する鍵サーバに送信する送信ステップと、
前記要求メッセージに従った前記鍵サーバから前記各復号鍵を当該鍵サーバから受信する鍵受信ステップとを含む
ことを特徴とするプログラム。

【図１】

【図２】

【図３】

【図４】

【図５】

【図６】

【図７】

【図８】

【図９】

【図１０】

【図１１】

【図１２】

【図１３】

【図１４】

【図１５】

【図１６】

【図１７】

【図１８】

【図１９】

【図２０】

【図２１】

【図２２】

【図２３】

【図２４】

【図２５】

【図２６】

【図２７】

【図２８】

【図２９】

【図３０】

【図３１】

【図３２】

【図３３】

【図３４】

【図３５】

【図３６】

【図３７】

【図３８】

【図３９】

【図４０】

【図４１】

【図４２】

【図４３】

【図４４】

【図４５】

【図４６】

【公開番号】特開２００９−１５３０９１（Ｐ２００９−１５３０９１Ａ）
【公開日】平成２１年７月９日（２００９．７．９）
【国際特許分類】
【出願番号】特願２００８−１８１８８４（Ｐ２００８−１８１８８４）
【出願日】平成２０年７月１１日（２００８．７．１１）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】