(57)【要約】【課題】コンテンツ配信システムにおいて配信される暗号化されたコンテンツが不正に復号されることをより効果的に抑制可能な配信技術を提供する。【解決手段】リーチャ５０Ａは、バージョン情報を含むTorrent Fileを販売サーバ５４から受信し、当該Torrent Fileに基づいて、トラッカ５１にアクセスしてノード情報を取得し、ノード情報に基づいて、シーダ５２Ａ〜５２Ｃやリーチャ５０Ｂの少なくとも１つにアクセスして各暗号化ピースを受信して、各ピースに各々対応する全ての暗号化ピースを取得する。そして、リーチャ５０Ａは、各暗号化ピースを各々復号するための各復号鍵を含む鍵束を要求すると共に、各暗号化ピースの取得に用いたTorrent Fileのバージョン情報を含む要求メッセージを鍵サーバ５３に送信し、鍵サーバ５３の判断結果に応じて当該鍵束を受信する。【選択図】        図１
2010021888.tif 000002
【特許請求の範囲】
【請求項１】
コンテンツの一部である複数のピースを受信する通信装置であって、
複数の第１暗号化ピースは、前記複数のピースを第１暗号鍵で暗号化することによって生成されるものであって、
第２暗号化ピースは、前記複数のピースのうち１つ以上のピースを第２暗号鍵で暗号化することによって生成されるものであって、
同一のピースを暗号化するための前記第１暗号鍵と前記第２暗号鍵とは異なっていて、
前記第１暗号化ピース及び前記第２暗号化ピースの全部又は一部を示すファイル情報と、当該ファイル情報の有効性の有無を判断可能な版管理情報とを取得する情報取得手段と、
他の通信装置から、前記ファイル情報を用いて、前記第１暗号化ピース又は前記第２暗号化ピースをピース毎に受信するコンテンツ受信手段と、
前記コンテンツ受信手段がピース毎に受信した前記第１暗号化ピース又は前記第２暗号化ピースを復号するための各復号鍵を要求する要求メッセージと当該各対応暗号化ピースの取得に用いた前記ファイル情報の前記版管理情報とを鍵サーバへ送信する送信手段と、
前記要求メッセージに従った前記鍵サーバから前記各復号鍵を受信する鍵受信手段とを備える
ことを特徴とする通信装置。
【請求項２】
前記情報取得手段は、所定又は任意のタイミングで更新される前記ファイル情報と、前記版管理情報とを取得する
ことを特徴とする請求項１に記載の通信装置。
【請求項３】
前記コンテンツ受信手段は、
前記他の通信装置が保持する前記第１暗号化ピース又は前記第２暗号化ピースの取得に用いられた前記ファイル情報の前記版管理情報を取得する第３取得手段と、
前記情報取得手段が取得した前記版管理情報と前記第３取得手段が取得した前記版管理情報とを用いて、前記他の通信装置から前記第１暗号化ピース又は前記第２暗号化ピースを取得するか否かを判断する判断手段と、
前記判断手段の判断結果に応じて、前記他の通信装置に対して前記第１暗号化ピース又は前記第２暗号化ピースを要求する要求手段とを有する
ことを特徴とする請求項１又は２に記載の通信装置。
【請求項４】
前記情報取得手段は、前記ファイル情報と、有効性を有する前記ファイル情報の前記版管理情報を示す有効性情報及び有効性を有する前記ファイル情報の前記版管理情報の範囲を特定する有効性情報のうち少なくとも一方とを取得し、
前記判断手段は、前記情報取得手段が取得した前記版管理情報及び前記有効性情報と前記第３取得手段が取得した前記版管理情報とを用いて、前記他の通信装置から前記第１暗号化ピース又は前記第２暗号化ピースを取得するか否かを判断する
ことを特徴とする請求項１乃至３のいずれか一項に記載の通信装置。
【請求項５】
前記情報取得手段は、前記ファイル情報と、前記版管理情報と、前記ファイル情報の有効期限を示す有効性情報とを取得し、当該有効性情報によって示される有効期限に基づいて、更新された前記ファイル情報を少なくとも取得する
ことを特徴とする請求項１乃至４のいずれか一項に記載の通信装置。
【請求項６】
前記通信装置は、少なくとも１つ以上のグループに属するようにグループ分けされており、
前記ファイル情報によって示される前記第１暗号化ピース及び前記第２暗号化ピースの全部又は一部は前記グループ毎に異なり、
前記情報取得手段は、前記通信装置の属する前記グループに対応する前記ファイル情報と、当該ファイル情報の有効性の有無を判断可能な版管理情報とを取得する
ことを特徴とする請求項１乃至５のいずれか一項に記載の通信装置。
【請求項７】
前記コンテンツ受信手段は、
前記第１暗号化ピース又は前記第２暗号化ピースを記憶する他の通信装置にアクセスするためのノード情報を管理サーバから受信する第１受信手段と、
受信された前記ノード情報を用いて、前記他の通信装置にアクセスして、前記第１暗号化ピース又は前記第２暗号化ピースを受信する第２受信手段とを有する
ことを特徴とする請求項１乃至６のいずれか一項に記載の通信装置。
【請求項８】
前記送信手段は、前記要求メッセージに前記版管理情報を含めて、前記鍵サーバに送信する
ことを特徴とする請求項１乃至７のいずれか一項に記載の通信装置。
【請求項９】
受信された前記各復号鍵を用いて、各前記対応暗号化ピースを各々復号する復号手段を更に備える
ことを特徴とする請求項１乃至８のいずれか一項に記載の通信装置。
【請求項１０】
コンテンツの一部である複数のピースを受信する通信装置であって、
複数の第１暗号化ピースは、前記複数のピースを第１暗号鍵で暗号化することによって生成されるものであって、
第２暗号化ピースは、前記複数のピースのうち１つ以上のピースを第２暗号鍵で暗号化することによって生成されるものであって、
同一のピースを暗号化するための前記第１暗号鍵と前記第２暗号鍵とは異なっていて、
他の通信装置から、前記第１暗号化ピース又は前記第２暗号化ピースをピース毎に受信するコンテンツ受信手段と、
前記コンテンツ受信手段がピース毎に受信した前記第１暗号化ピース又は前記第２暗号化ピースを復号するための各復号鍵を要求する要求メッセージを、当該各復号鍵を記憶する鍵サーバに送信する鍵要求送信手段と、
前記要求メッセージによって要求された各復号鍵によって復号されるピース毎の前記第１暗号化ピース又は前記第２暗号化ピースを保持していることを証明するための保持証明情報を要求する情報要求メッセージを前記鍵サーバから受信する要求受信手段と、
前記情報要求メッセージに従って前記保持証明情報を前記鍵サーバに送信する情報送信手段と、
前記保持証明情報及び前記情報要求メッセージに基づいて前記鍵サーバから前記各復号鍵のうち全部又は一部を受信する鍵受信手段とを備える
ことを特徴とする通信装置。
【請求項１１】
前記要求受信手段は、前記要求メッセージによって要求した各復号鍵によって復号されるピース毎の前記第１暗号化ピース又は前記第２暗号化ピースのうち少なくとも２つ以上のピースに各々対応する前記第１暗号化ピース又は前記第２暗号化ピースを用いて所定の演算により計算される演算値である前記保持証明情報を要求する情報要求メッセージを前記鍵サーバから受信し、
前記情報送信手段は、
前記演算値要求メッセージに従って前記少なくとも２つ以上のピースに各々対応する前記第１暗号化ピース又は前記第２暗号化ピースを用いて所定の演算により演算値を計算する計算手段と、
計算された前記演算値を前記鍵サーバに送信する演算値送信手段と有する
ことを特徴とする請求項１０に記載の通信装置。
【請求項１２】
前記要求受信手段は、前記要求メッセージによって要求された各復号鍵によって復号されるピース毎の前記第１暗号化ピース又は前記第２暗号化ピースのうち少なくとも２つ以上のピースに各々対応する前記第１暗号化ピース又は前記第２暗号化ピースを連結したデータの全部又は一部である前記保持証明情報を要求する演算値要求メッセージを前記鍵サーバから受信し、
前記情報送信手段は、前記情報要求メッセージに従って前記少なくとも２つ以上のピースに各々対応する前記第１暗号化ピース又は前記第２暗号化ピースを連結することによりデータを生成する連結手段と、
前記データの全部又は一部を前記鍵サーバに送信するデータ送信手段とを有する
ことを特徴とする請求項１０に記載の通信装置。
【請求項１３】
コンテンツの一部である複数のピースを受信する通信装置と通信する鍵サーバであって、
複数の第１暗号化ピースは、前記複数のピースを第１暗号鍵で暗号化することによって生成されるものであって、
第２暗号化ピースは、前記複数のピースのうち１つ以上のピースを第２暗号鍵で暗号化することによって生成されるものであって、
同一のピースを暗号化するための前記第１暗号鍵と前記第２暗号鍵とは異なっていて、
前記通信装置は、他の通信装置から、前記第１暗号化ピース又は前記第２暗号化ピースをピース毎に受信するものであって、
前記通信装置から、ピース毎の前記第１暗号化ピース又は前記第２暗号化ピースを復号するための各復号鍵を要求する要求メッセージと前記第１暗号化ピース又は前記第２暗号化ピースの取得に用いられた前記ファイル情報の有効性の有無を判断可能な版管理情報とを受信する要求受信手段と、
前記各復号鍵を記憶する第１記憶手段と、
有効性を有する前記ファイル情報の前記版管理情報を特定するための有効性情報を記憶する第２記憶手段と、
受信された前記版管理情報と、前記有効性情報とを用いて、前記要求メッセージによって要求された前記各復号鍵が有効であるか否かを判断する判断手段と、
前記判断手段の判断結果が肯定的である場合、前記要求メッセージによって要求された前記各復号鍵の組み合わせに基づいて、当該各復号鍵を送信するか否かを決定する決定手段と、
前記決定手段の決定結果が肯定的である場合、前記要求メッセージによって要求された前記組み合わせにおける前記各復号鍵を前記第１記憶手段から各々読み出してこれらを前記通信装置に送信する鍵送信手段とを備える
ことを特徴とする鍵サーバ。
【請求項１４】
前記第２記憶手段は、有効性を有する前記ファイル情報の版を示す情報である前記版管理情報を示す前記有効性情報を記憶する
ことを特徴とする請求項１３に記載の鍵サーバ。
【請求項１５】
前記第２記憶手段は、有効性を有する前記ファイル情報が生成された時刻を示す情報である前記版管理情報を示す前記有効性情報を記憶する
ことを特徴とする請求項１３に記載の鍵サーバ。
【請求項１６】
前記第２記憶手段は、有効性を有する前記ファイル情報によって示される前記第１暗号化ピース又は前記第２暗号化ピースの全部又は一部を用いて所定の演算により計算される演算値である前記版管理情報を示す前記有効性情報を記憶する
ことを特徴とする請求項１３に記載の鍵サーバ。
【請求項１７】
コンテンツの一部である複数のピースを受信する通信装置と通信する鍵サーバであって、
複数の第１暗号化ピースは、前記複数のピースを第１暗号鍵で暗号化することによって生成されるものであって、
第２暗号化ピースは、前記複数のピースのうち１つ以上のピースを第２暗号鍵で暗号化することによって生成されるものであって、
同一のピースを暗号化するための前記第１暗号鍵と前記第２暗号鍵とは異なっていて、
前記通信装置は、他の通信装置から、前記第１暗号化ピース又は前記第２暗号化ピースをピース毎に受信するものであって、
前記通信装置から、ピース毎の前記第１暗号化ピース又は前記第２暗号化ピースを復号するための各復号鍵を要求する要求メッセージを受信する要求受信手段と、
前記各復号鍵を記憶する第１記憶手段と、
前記要求メッセージによって要求された前記各復号鍵によって復号されるピース毎の前記第１暗号化ピース又は前記第２暗号化ピースを前記通信装置が保持しているか否かを判断するための保持判断情報を記憶する第２記憶手段と、
前記要求メッセージによって要求された各復号鍵によって復号されるピース毎の前記第１暗号化ピース又は前記第２暗号化ピースを保持していることを証明するための保持証明情報を要求する情報要求メッセージを前記通信装置に送信する要求送信手段と、
前記保持証明情報を前記通信装置から受信する情報受信手段と、
受信された前記保持証明情報と、記憶された前記保持判断情報とを用いて、前記要求メッセージによって要求された前記各復号鍵によって復号されるピース毎の前記第１暗号化ピース又は前記第２暗号化ピースを前記通信装置が保持しているか否かを判断する保持証明判断手段と、
前記判断手段の判断結果が肯定的である場合、前記要求メッセージによって要求された前記各復号鍵の組み合わせに基づいて、当該各復号鍵を送信するか否かを決定する決定手段と、
前記決定手段の決定結果が肯定的である場合、前記要求メッセージによって要求された前記組み合わせにおける前記各復号鍵を前記第１記憶手段から各々読み出してこれらを前記通信装置に送信する鍵送信手段とを備える
ことを特徴とする鍵サーバ。
【請求項１８】
前記要求送信手段は、
前記要求メッセージによって要求された各復号鍵によって復号されるピース毎の前記第１暗号化ピース又は前記第２暗号化ピースのうち少なくとも２つ以上のピースに各々対応する前記第１暗号化ピース又は前記第２暗号化ピースを選択する選択手段と、
前記少なくとも２つ以上の対応暗号化ピースを用いて所定の演算により計算される演算値である前記保持証明情報を要求する情報要求メッセージを前記通信装置に送信する第１送信手段とを有し、
前記情報受信手段は、前記情報要求メッセージに従って前記少なくとも２つ以上のピースに各々対応する前記第１暗号化ピース又は前記第２暗号化ピースを用いて所定の演算により計算された演算値である前記保持証明情報を前記通信装置から受信する
ことを特徴とする請求項１７に記載の鍵サーバ。
【請求項１９】
前記第２記憶手段は、前記第１暗号化ピース及び前記第２暗号化ピースの全部又は一部を記憶し、
前記要求送信手段は、前記要求メッセージによって要求された各復号鍵によって復号されるピース毎の前記第１暗号化ピース又は前記第２暗号化ピースのうち少なくとも２つ以上のピースに各々対応する前記第１暗号化ピース又は前記第２暗号化ピースを連結したデータの全部又は一部である前記保持証明情報を要求する情報要求メッセージを前記通信装置に送信し、
前記情報受信手段は、前記情報要求メッセージに従って前記少なくとも２つ以上のピースに各々対応する前記第１暗号化ピース又は前記第２暗号化ピースが連結されたデータの全部又は一部である前記保持証明情報を前記通信装置から受信し、
前記保持証明判断手段は、受信された前記データと、前記第２記憶手段に記憶された前記第１暗号化ピース及び前記第２暗号化ピースの全部又は一部のうち、前記少なくとも２つ以上のピースに各々対応する前記第１暗号化ピース又は前記第２暗号化ピースを連結したデータとを用いて、前記要求メッセージによって要求された前記各復号鍵によって復号される前記対応暗号化ピースを前記通信装置が保持しているか否かを判断する
ことを特徴とする請求項１７に記載の鍵サーバ。
【請求項２０】
前記各ピースに対応して既に送信した前記各復号鍵の組み合わせを示すシーケンス情報を記憶する第２記憶手段を備え、
前記決定手段は、前記各復号鍵が全て有効であると判断された場合、前記要求メッセージによって要求された前記各復号鍵の組み合わせを示すシーケンス情報が、前記第２記憶手段に記憶されているか否かを判断することにより、当該各復号鍵を送信するか否かを決定する
ことを特徴とする請求項１７乃至１９のいずれか一項に記載の鍵サーバ。
【請求項２１】
コンテンツの一部である複数のピースを受信する通信装置と通信する管理サーバであって、
複数の第１暗号化ピースは、前記複数のピースを第１暗号鍵で暗号化することによって生成されるものであって、
第２暗号化ピースは、前記複数のピースのうち１つ以上のピースを第２暗号鍵で暗号化することによって生成されるものであって、
同一のピースを暗号化するための前記第１暗号鍵と前記第２暗号鍵とは異なっていて、
ファイル情報は、前記第１暗号化ピース及び前記第２暗号化ピースの全部又は一部を示し且つ当該ファイル情報の有効性の有無を判断可能な版管理情報が対応付けられるものであり、
前記通信装置は、他の通信装置から、前記ファイル情報を用いて、前記第１暗号化ピース又は前記第２暗号化ピースをピース毎に受信するものであって、
前記他の通信装置にアクセスするための接続先情報を記憶する第１記憶手段と、
前記通信装置が、前記ファイル情報と対応付けられ且つ当該管理サーバへアクセスするための第１アクセス情報を用いて当該管理サーバにアクセスした場合、前記他の通信装置にアクセスするための前記接続先情報を送信する情報送信手段とを備える
ことを特徴とする管理サーバ。
【請求項２２】
前記通信装置が有する前記ファイル情報の前記版管理情報を取得する情報取得手段を更に備え、
前記情報送信手段は、
前記版管理情報を用いて、前記通信装置及び前記他の通信装置のうち少なくとも一方をグループ分けする分類手段と、
前記通信装置と同じグループに属する前記他の通信装置にアクセスするための前記接続先情報を送信する送信手段とを有する
ことを特徴とする請求項２１に記載の管理サーバ。
【請求項２３】
前記情報送信手段は、
前記通信装置及び前記他の通信装置のうち少なくとも一方が、少なくとも１つ以上のグループに属し且つグループ毎に前記ファイル情報によって示される前記第１暗号化ピース及び前記第２暗号化ピースの全部又は一部が異なるようにグループ分けする分類手段と、
前記通信装置と同一のグループに属する前記他の通信装置にアクセスするための接続先情報を前記第１記憶手段から読み出してこれを送信する送信手段とを有する
ことを特徴とする請求項２１に記載の管理サーバ。
【請求項２４】
前記ファイル情報が更新され且つ当該ファイル情報に対応付けられる前記第１アクセス情報が変更された場合、前記接続先情報の送信の停止を要求する停止要求メッセージを外部装置から受信する受信手段を備え、
前記情報送信手段は、前記停止要求メッセージが受信された場合、当該管理サーバにアクセスした前記通信装置に対して前記接続先情報を送信しない
ことを特徴とする請求項２１乃至２３のいずれか一項に記載の管理サーバ。
【請求項２５】
前記ファイル情報が更新され且つ当該ファイル情報に対応付けられる前記第１アクセス情報が変更された場合、前記接続先情報の送信の停止を要求する停止要求メッセージと、前記接続先情報を送信しない対象となる前記通信装置を識別するための通信装置識別情報を対応付けて示すリスト情報とを外部装置から受信する受信手段と、
当該管理サーバにアクセスした前記通信装置から当該通信装置を識別するための前記通信装置識別情報を取得する取得手段とを備え、
前記情報送信手段は、前記停止要求メッセージ及び前記リスト情報が受信された場合、当該管理サーバにアクセスした前記通信装置のうち前記リスト情報に前記通信装置識別情報が示されている通信装置に対して前記接続先情報を送信しない
ことを特徴とする請求項２１乃至２３のいずれか一項に記載の管理サーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、暗号鍵を用いて暗号化された暗号化コンテンツを、他の通信装置から受信する通信装置、暗号化コンテンツを復号するための復号鍵を送信する鍵サーバ、通信装置が他の通信装置へアクセスするための情報を記憶する通信装置、鍵サーバ及び管理サーバに関する。
【背景技術】
【０００２】
一般に、コンテンツを配信するシステムには、「単一サーバ型」と「分散サーバ型」とがある。単一サーバ型のシステムでは、例えば、１つのコンテンツサーバと、ライセンスサーバと、クライアントとがネットワークを介して接続され、コンテンツサーバからコンテンツが各クライアントに配信される。配信されるコンテンツは暗号化されており、この暗号化に係る鍵情報をライセンスサーバが有している。コンテンツサーバでは、コンテンツは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を受信し、当該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」の場合、即ち、Ｎ個のうち１個のピースのみ、ｍ個の異なる暗号鍵で暗号化されていても良い。このような構成によれば、配信効率を向上させることができる。
【００３３】
このような構成において、シーダ５２は、リーチャ５０からのアクセスにより、当該シーダ５２が記憶している暗号化ピースのシーケンスを示すピース情報をリーチャ５０に送信する。図７は、ピース情報のデータ構成を例示する図である。同図においては、ピースＣ１に対応する暗号化ピースについては、復号鍵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 ]を復号して、ピースＣＮを得て、他のピースについても同様にして得ることにより、各ピースＣ１〜ＣＮから構成されるコンテンツＣを得る。
【００６０】
尚、リーチャ５０は、ステップＳ１５で鍵束を受信することなく、図１３のステップＳ１４３で鍵サーバ５３から送信されたエラーメッセージを受信した場合、ステップＳ１０で取得した各ピースを復号することができず、従って、コンテンツを利用できない。この場合、ステップＳ５に戻り、リーチャ５０は、ステップＳ１０で取得したシーケンスとは異なるシーケンスで各暗号化ピースを取得した後に、ステップＳ１０以降の処理を再度行う。
【００６１】
以上のように、Ｐ２Ｐネットワークを介して、同一のコンテンツを複数のリーチャ５０に配信する場合、暗号化ピースのシーケンスを用いて、鍵サーバ５３が鍵束の送信の可否を決定する。ここで、鍵サーバ５３が、既に使用されたシーケンスの再使用を回避することにより、コンテンツをリーチャ５０毎に個別化することができる。従って、例えば、１つの鍵束が漏洩したとしても、この鍵束に対応する暗号化コンテンツのみしか復号することができないので、コンテンツの不正使用を抑制することができる。また、予め定められたシーケンスではなく、リーチャ５０が任意に取得した暗号化ピースにより定まるシーケンスを用いることにより、Ｐ２Ｐネットワークの環境に応じたフレキシブルなコンテンツ配信を実現することができる。
【００６２】
＜本実施の形態にかかるコンテンツ配信システムの構成＞
次に、上述したコンテンツ配信システムの基本的な構成に加えた本実施の形態に特有の構成について説明する。本構成においては、暗号化ピース及び復号鍵K( i, j )を時間の経過とともに更新する。ここでは、便宜上、暗号鍵と復号鍵とが同一である場合について説明する。尚、上述した通り、暗号鍵と復号鍵とが異なっていても良いが、その場合、暗号鍵と復号鍵とをそれぞれ更新する。例えば、上述のピース処理装置は、図５に例示されるような暗号化ピースを生成するとする。ピース処理装置は、このような暗号化ピースを生成した後ある一定時間Vが経過すると、新たな復号鍵を各々生成して鍵束K’( i, j )（i=1,…,m, j=1,…,N）を生成し、当該新たな復号鍵（暗号鍵）を用いて暗号化して合計mN個の暗号化ピースE( K’( i, j ) )[ Cj ]をそれぞれ生成し、それらを初期シーダ５２Ａへ渡す。また、ピース処理装置は、新たに生成した合計mN個の暗号化ピースE( K’( i, j ) )[ Cj ]を示すファイル情報を含む新たなTorrent Fileを生成し、それを販売サーバ５４及び初期シーダ５２Ａへ渡す。ピース処理装置が鍵サーバ５３でない場合にはピース処理装置は鍵サーバ５３にも新たなTorrent Fileを渡す。更に、ピース処理装置は、暗号化ピースの更新を行った旨をトラッカ５１に通知する。
【００６３】
ここで、ピース処理装置が生成するTorrent Fileの構成について説明する。図１４は、Torrent Fileを例示する図である。本構成におけるTorrent Fileは、図９に例示したTorrent Fileの構成に加え、バージョン情報を有する。バージョン情報とは、Torrent Fileを更新する毎に更新される版を示す情報であり、Torrent Fileの有効性の有無を判断可能な版管理情報である。ピース処理装置は、暗号化ピース及び復号鍵を更新する度にバージョン情報の値を更新して、更新した暗号化ピースを示すファイル情報と共に、値を更新したバージョン情報を有するTorrent Fileを生成し、それを販売サーバ５４及び初期シーダ５２Ａへ渡す。尚、Torrent Fileが有効性を有する、即ち、Torrent Fileが有効であるとは、そのファイル情報によって示される暗号化ピースが有効であり、当該暗号化ピースを復号するための復号鍵が有効であるということである。有効な復号鍵とは、例えば暴露等されたことにより無効化されてるものではなく、鍵サーバ５３がリーチャ５０から要求された場合に送信可能なものである。従って、Torrent Fileの有効性の有無が判断されることにより、そのファイル情報によって示される暗号化ピースの有効性の有無及び当該暗号化ピースを復号するための復号鍵が有効性の有無が判断される。尚、ここでは、ピース処理装置が値を更新した最新のバージョン情報を有するTorrent Fileのみが有効であるとして処理を行うものとする。
【００６４】
次に、このような構成において、上述のリーチャ５０の基本的な機能に加わる更なる機能について説明する。リーチャ５０の鍵束要求部５０１は、コンテンツ取得部５００が取得したTorrent Fileであって暗号化ピースの取得に用いたTorrent Fileに含まれるバージョン情報を取得し、これをインデックス情報と共に上述の要求メッセージに含ませて鍵サーバ５３に送信する。
【００６５】
次に、上述の鍵サーバ５３の基本的な機能に加わる更なる機能について説明する。図１５は、本構成における鍵サーバ５３の機能的構成を例示する図である。本構成においては、鍵サーバ５３は、有効性判断部５３９と、Torrent File有効性情報記憶部５４０とを更に有する。Torrent File有効性情報記憶部５４０は、有効なTorrent Fileのバージョン情報を特定するための有効性情報を記憶している。ここでは、有効性情報は、最新のバージョン情報を示す情報である。尚、ピース処理装置が鍵サーバ５３である場合には、当該鍵サーバ５３がバージョン情報を生成して有効性情報をTorrent File有効性情報記憶部５４０に記憶する。ピース処理装置が鍵サーバ５３でない場合には、鍵サーバ５３は有効性情報をピース処理装置から取得してこれをTorrent File有効性情報記憶部５４０に記憶する。有効性判断部５３９は、認証・鍵交換処理部５３３が受信した要求メッセージに含まれるバージョン情報と、Torrent File有効性情報記憶部５４０に記憶されている有効性情報とを照合することにより、リーチャ５０から要求されている鍵束の有効性の有無を判断する。シーケンス情報照合部５３５は、有効性判断部５３９の判断結果に応じて、上述と同様にしてインデックス情報とシーケンス情報との照合を行う。
【００６６】
（２）動作
次に、本実施の形態にかかるコンテンツ配信システムで行うコンテンツ配信処理の手順について図１２を用いて説明する。ステップＳ１では、リーチャ５０は、上述と同様にして、販売サーバ５４にアクセスして、Torrent Fileを取得する。尚、リーチャ５０は、ステップＳ１を行う度に最新のTorrent Fileを取得することになる。ステップＳ２〜Ｓ９は上述の基本構成における処理と同様である。ステップＳ１０では、リーチャ５０は、ステップＳ１で取得し暗号化ピースの取得に用いたTorrent Fileに含まれるバージョン情報を含む要求メッセージを鍵サーバ５３に送信する。例えば、各暗号化ピースに対応するTorrent Fileのバージョン情報が同一である場合、リーチャ５０は、以下のようにバージョン情報とインデックス情報との組み合わせにより表される要求メッセージを鍵サーバ５３に送信する。
{Version, ( i1, 1 ), ( i2, 2 ), …, ( iN, N) }
（ただし、1≦i1, …, iN≦m）
Versionは、Torrent Fileのバージョン情報を表す。
【００６７】
尚、リーチャ５０はステップＳ１の処理を複数回行って複数の異なるTorrent Fileを販売サーバ５４から取得しており、複数のTorrent Fileを用いて各暗号化ピースを取得する場合もある。この場合、リーチャ５０は、例えば以下のように、各暗号化ピースに対応するTorrent Fileのバージョン情報と当該バージョン情報に対応する各インデックス情報との組み合わせを要求メッセージに含ませてこれを鍵サーバ５３に送信する。
{ ( i1, 1, Version_1 ), ( i2, 2, Version_2 ), …, ( iN, N, Version_N) }
Version_i（1≦i≦N）は、各暗号化ピースに対応するTorrent Fileのバージョン情報を表す。尚、各Version_iは各々異なるものであっても良いし、少なくとも２つが同じであっても良い。
【００６８】
次いで、ステップＳ１１〜Ｓ１３は上述の基本構成における処理と同様である。ステップＳ１４では、鍵サーバ５３は、以下の照合処理を行う。図１６は、本実施の形態に係る照合処理の手順を示すフローチャートである。鍵サーバ５３の有効性判断部５３９は、要求メッセージに含まれるバージョン情報と、Torrent File有効性情報記憶部５４０に記憶されている有効性情報とを照合する（ステップＳ１４０Ｇ）。そして、有効性判断部５３９は、これらが一致するか否かを判断することにより、当該要求メッセージにより要求されている鍵束が有効か否かを判断する（ステップＳ１４０Ｈ）。即ち、ここでは、最新のバージョン情報を含むTorrent Fileに含まれるファイル情報によって示される暗号化ピースを復号するための復号鍵のみが有効であると判断される。尚、要求メッセージに複数のバージョン情報が含まれる場合、有効性判断部５３９は、各バージョン情報についてステップＳ１４０Ｈの判断を行う。全てのバージョン情報についての判断結果が肯定的である場合、要求されている鍵束に含まれる復号鍵は全て有効であり、当該鍵束は有効であると判断する。次いで、シーケンス情報照合部５３５が、上述と同様にしてステップＳ１４０以降の処理を行う。少なくとも１つのバージョン情報に対するステップＳ１４０Ｈの判断結果が否定的である場合、有効性判断部５３９は、当該バージョン情報に対応するインデックス情報によって特定される復号鍵は無効であると判断し、当該復号鍵を含む鍵束は無効であると判断する。この場合、シーケンス情報照合部５３５が、上述と同様にしてステップＳ１４４の処理を行う。
【００６９】
以上のように、暗号化ピース及び鍵束を逐次更新していけば、全ての暗号化ピース及び鍵束を集め、それら全てを何らかの方法で暴露し、他のユーザにコンテンツを不正使用させるという不正行為を抑制することができる。なぜなら、そのような不正行為を行おうとする者が全ての暗号化ピースを取得する前に、所望の暗号化ピースをネットワーク上において見付け難くなるからである。つまり、各シーダ５２には一定時間毎に新たな暗号化ピースが保持される又は新たな暗号化ピースに置き換わりうるので、時間的に古い鍵束に対応する暗号化ピースを取得しようとしても、見つけ出せない恐れがあるからである。このため、このような不正行為による被害としてコンテンツの不正使用をより効果的に抑制することができる。
【００７０】
（３）変形例
＜変形例１＿１＞
上述の第１の実施の形態においては、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を用いてハッシュ演算により計算されるハッシュ値を示す情報を記憶する。そして、鍵サーバ５３は、上述の第１の実施の形態と同様にして、有効性情報を用いて、リーチャ５０から送信された要求メッセージにより要求されている鍵束が有効か否かを判断する。
【００７６】
＜変形例１＿３＞
上述した第１の実施の形態においては、リーチャ５０は、要求メッセージにTorrent Fileがバージョン情報を含ませるようにしたが、バージョン情報ではなく、Torrent Fileに含まれるファイル情報によって示される暗号化ピースのハッシュ値を要求メッセージに含ませて送信するようにしても良い。この場合、当該ハッシュ値が、Torrent Fileの有効性を判断可能な版管理情報となる。この場合、リーチャ５０が取得するTorrent Fileには、バージョン情報が含まれていなくても良い。また、この場合、例えば、変形例１＿１で説明したように、Torrent Fileのファイル情報が各暗号化ピースのハッシュ情報を含むとする。このようなTorrent Fileのファイル情報をリーチャ５０は参照して、その復号鍵を要求する各暗号化ピースのハッシュ値を要求メッセージに含ませて鍵サーバ５３に送信する。又は、Torrent Fileのファイル情報が各暗号化ピースのハッシュ情報を含むのではなく、リーチャ５０自体が、取得した暗号化ピースのハッシュ値を算出しこれを要求メッセージに含ませて送信する。
【００７７】
一方、いずれの場合も、鍵サーバ５３のTorrent File有効性情報記憶部５４０は、有効なTorrent Fileに含まれるファイル情報によって示される各暗号化ピースのハッシュ値を予め記憶している。そして、有効性判断部５３９は、要求メッセージに含まれるハッシュ値と、Torrent File有効性情報記憶部５４０に記憶されているハッシュ値とを照合し、要求メッセージに含まれる全てのハッシュ値について一致するものがある場合、有効性判断部５３９は、要求された鍵束は有効であると判断する。一方、要求メッセージに含まれる各ハッシュ値のうちTorrent File有効性情報記憶部５４０に一致するものがないものがある場合、有効性判断部５３９は、要求された鍵束は無効であると判断する。この場合、鍵サーバ５３は、要求した鍵束が無効である旨のメッセージをリーチャ５０に送信するように構成しても良い。また、鍵サーバ５３は、例えば、一致するものがTorrent File有効性情報記憶部５４０に記憶されていないハッシュ値に対応するインデックス情報をリーチャ５０に送信することにより、無効な復号鍵により復号される暗号化ピースをリーチャ５０に通知するようにしても良い。
【００７８】
＜変形例１＿４＞
上述した第１の実施の形態においては、Torrent Fileは、バージョン情報に加え、有効なTorrent Fileのバージョン情報を特定するための有効性情報を含むようにしても良い。図１９は、本変形例にかかるTorrent Fileを例示する図である。有効性情報は、例えば、有効なTorrent Fileのバージョン情報を示す情報である。例えば、あるコンテンツについてTorrent Fileのバージョン情報が「１」から順に「５」まで更新されているとする。このうち、有効なTorrent Fileのバージョン情報が「３」、「４」、「５」であるとき、有効性情報は、有効なTorrent Fileのバージョン情報として、「３」、「４」、「５」を示すようにしても良い。又は、有効性情報は、有効なTorrent Fileのバージョン情報の範囲を特定する情報であっても良い。この場合、有効なTorrent Fileのバージョン情報の範囲が「３」以上であるとして、有効性情報は、「３」のみを示すようにしても良い。また、有効でない復号鍵により復号される暗号化ピースを示すファイル情報を含むTorrent Fileのバージョン情報のリスト又は範囲を示すように、有効性情報を構成しても良い。この場合、有効性情報によって示されるバージョン情報のリスト又は範囲以外のTorrent Fileが有効であると特定することができる。
【００７９】
尚、どの時点のTorrent Fileを有効とするかは特に限定されない。また、暗号化ピース及び復号鍵を更新する度に、どの時点のTorrent Fileを有効とするかを変更しても良い。
【００８０】
このような構成において、鍵サーバ５３の有効性情報記憶部５４０には、上述の有効性情報の代わりに、その時点において有効なTorrent Fileを特定する有効性情報が記憶される。尚、ピース処理装置が鍵サーバ５３である場合には、当該鍵サーバ５３が有効性情報を生成して有効性情報をTorrent File有効性情報記憶部５４０に都度記憶する。ピース処理装置が鍵サーバ５３でない場合には、鍵サーバ５３は有効性情報をピース処理装置から都度取得してこれをTorrent File有効性情報記憶部５４０に記憶する。
【００８１】
鍵サーバ５３は、上述のステップＳ１４０Ｇでは、有効性情報との照合を行うのではなく、要求メッセージに含まれるバージョン情報が、Torrent File有効性情報記憶部５４０に記憶されている有効性情報によって示されるバージョン情報のリスト又は範囲に含まれるか否かを判断する。これにより、鍵サーバ５３は、要求メッセージによって要求されている鍵束の有効性の有無を判断する。そして、当該判断結果が肯定的である場合、ステップＳ１４０に進み、当該判断結果が否定的である場合、ステップＳ１４４に進む。
【００８２】
尚、Torrent Fileに含まれる有効性情報は、上述のものに限らず、当該Torrent Fileの有効期限を示す情報であっても良い。当該Torrent Fileの有効期限とは、即ち、当該Torrent Fileに含まれるファイル情報によって示される暗号化ピースを復号するための復号鍵をリーチャ５０が鍵サーバ５３対して要求可能である期限である。この場合、リーチャ５０は、有効性情報を参照することにより、取得したTorrent Fileがその時点において有効であるか否かを知ることができる。そして、例えば、リーチャ５０は、鍵サーバ５３に要求メッセージを送信する際に、各暗号化ピースの取得に用いたTorrent Fileに含まれる有効期限情報によって示される有効期限内であるか否かを判断し、当該判断結果が肯定的である場合に、当該Torrent Fileに含まれるバージョン情報を要求メッセージに含ませて鍵サーバ５３に送信する。
【００８３】
また、リーチャ５０は、取得したTorrent Fileに含まれる有効性情報を参照して、当該Torrent File自体の有効性の有無を判断し、当該判断結果に応じて、更新されているTorrent Fileを取得するようにしても良い。例えば、当該Torrent Fileが有効でないと判断した場合や、当該Torrent Fileの有効期限が間近に迫っており有効期限までの時間が所定時間以内であると判断した場合、リーチャ５０は、当該Torrent Fileを取得した販売サーバ５４や当該販売サーバ５４とは異なる販売サーバ５４から、更新されているTorrent Fileを取得し直しても良い。また、リーチャ５０は、ある時点において取得したTorrent Fileを用いて暗号化ピースの取得を始め、リーチャ５０にとって未知のインデックスに対応する暗号化ピースをシーダ５２が保持している場合、シーダ５２から当該未知のインデックスに対応する暗号化ピースを受信し、その受信後に、更新されているTorrent Fileを取得して受信した各暗号化ピースの完全性や正当性を確認してもよい。
【００８４】
一方、鍵サーバ５３のTorrent File有効性情報記憶部５４０は、各Torrent Fileのバージョン情報と当該バージョン情報の有効性情報とを対応付けて記憶する。そして、有効性判断部５３９は、リーチャ５０から受信した要求メッセージに含まれるバージョン情報について、Torrent File有効性情報記憶部５４０に記憶されているバージョン情報に対応付けられている有効性情報を参照して、有効期限内であるか否かを判断する。要求メッセージによって要求されている復号鍵毎にバージョン情報が異なる場合には、有効性判断部５３９はこの判断を復号鍵毎に行う。そして、全ての復号鍵について当該判断結果が肯定的である場合に、有効性判断部５３９は、要求メッセージによって要求されている鍵束は有効であると判断する。
【００８５】
以上のような構成によっても、コンテンツの不正使用をより効果的に抑制することができる。
【００８６】
＜変形例１＿５＞
上述の第１の実施の形態においては、ピース処理装置が値を更新した最新のバージョン情報を有するTorrent Fileのみが有効であるとしたが、これに限らず、最新より以前にピース処理装置が値を更新したバージョン情報有するTorrent Fileを有効であるようにしても良い。また、有効なTorrent Fileのバージョン情報の範囲を適宜変更するようにしても良い。
【００８７】
尚、上述の第１の実施の形態においては、一定時間毎に暗号化ピース及び復号鍵を更新するようにしたが、これに限らず、例えば、鍵束の漏洩が起こった際には直ちに暗号化ピース及び復号鍵を更新するようにしても良い。
【００８８】
また、上述のステップＳ１４０Ｈでは、少なくとも１つのバージョン情報に対する判断結果が否定的である場合、鍵サーバ５３は、例えば、当該バージョン情報に対応するインデックス情報をリーチャ５０に送信することにより、無効である復号鍵がいずれであるのかをリーチャ５０に通知するようにしても良い。
【００８９】
また、ステップＳ１０では、リーチャ５０は、バージョン情報を要求メッセージに含ませて鍵サーバ５３に送信するようにしたが、これに限らず、受理メッセージを受信した後やその他のタイミングで、バージョン情報を鍵サーバ５３へ送信しても良い。上述の変形例１＿２におけるハッシュ値や変形例１＿４における有効性情報についても同様である。
【００９０】
＜変形例１＿６＞
上述した第１の実施の形態においては、リーチャ５０がシーダ５２から暗号化ピースを取得する際に、Torrent Fileに含まれるバージョン情報を用いて、当該シーダ５２が保持する暗号化ピースの有効性の有無を判断するようにしても良い。この場合、シーダ５２はピース情報をリーチャ５０へ送信するとき、シーダ５２が保持する各暗号化ピースについて対応するTorrent Fileのバージョン情報もリーチャ５０へ送信する。ここでは、シーダ５２は、上述の第１の実施の形態においてリーチャ５０が鍵サーバ５３にバージョン情報を送信する場合と同様に、バージョン情報とインデックス情報との組み合わせによりピース情報及びバージョン情報を送信するようにしても良い。
【００９１】
そして、リーチャ５０は、シーダ５２から取得したバージョン情報を用いて、当該シーダ５２が保持する暗号化ピースの有効性の有無を判断する。図２０は、本変形例におけるリーチャ５０の機能的構成を例示する図である。本変形例においては、リーチャ５０のコンテンツ取得部５００は、有効性判断部５００ａを有する。有効性判断部５００ａは、シーダ５２からピース情報及びバージョン情報を受信すると、当該バージョン情報と、当該バージョン情報と、トラッカ５１から取得したTorrent Fileに含まれているバージョン情報とを照合し、この照合結果に応じて、シーダ５２が保持する暗号化ピースの有効性の有無を判断する。そして、コンテンツ取得部５００は、有効性判断部５００ａの判断結果に応じて、当該シーダ５２から暗号化ピースを取得する。
【００９２】
次に、本変形例にかかるコンテンツ配信システムで行うコンテンツ配信処理の手順について図２１を用いて説明する。ステップＳ１〜Ｓ５は上述の第１の実施の形態と同様である。ステップＳ５０では、シーダ５２は、自身が保持する各暗号化ピースについてピース情報及び各ピースの取得に用いられたTorrent Fileのバージョン情報をリーチャ５０へ送信する。ステップＳ５１では、リーチャ５０は、ピース情報及びバージョン情報をシーダ５２から受信する。次いで、リーチャ５０は、ステップＳ５０で受信したバージョン情報と、ステップＳ１でトラッカ５１から取得し暗号化ピースの取得に用いるTorrent Fileに含まれているバージョン情報とを照合し（ステップＳ５２）、これらが一致するか否かを判断することにより、シーダ５２が保持する暗号化ピースの有効性の有無を判断する（ステップＳ５３）。尚、リーチャ５０は、ステップＳ１の処理を複数回行って複数の異なるTorrent Fileをトラッカ５１から取得しており、複数のTorrent Fileを用いて暗号化ピースを取得する場合がある。この場合、リーチャ５０は、ステップＳ５０で受信したバージョン情報と、当該複数のTorrent Fileに各々含まれるバージョン情報と各々照合する。また、シーダ５２から取得したバージョン情報についても、各暗号化ピースに対応するバージョン情報が異なる場合がある。この場合、リーチャ５０は、各暗号化ピースについて各々バージョン情報を照合する。そして、各暗号化ピースについてステップＳ５２で取得した各バージョン情報と、リーチャ５０が暗号化の取得に用いるTorrent Fileに含まれるバージョン情報とが一致する場合、リーチャ５０は、シーダ５２が保持する暗号化ピースが有効であると判断し、上述の第１の実施の形態と同様にして、ステップＳ８以降の処理を行う。尚、ステップＳ１４では、鍵サーバ５３は、図１６に示したＳ１４０Ｇ，Ｓ１４０Ｈの処理を行わずにＳ１４０以降の処理を行えば良い。一方、ステップＳ５２で前者のバージョン情報と後者のバージョン情報とが一致しないものがある場合、リーチャ５０は、シーダ５２が保持する暗号化ピースが有効でないと判断し、当該シーダ５２からは暗号化ピースを取得しない。尚、この場合、リーチャ５０は、ステップＳ１又はステップＳ５に戻って処理をやり直しても良い。
【００９３】
以上のように、リーチャ５０自身が、Torrent Fileに含まれるバージョン情報を用いて、有効であると判断される暗号化ピースのみを取得する。これにより、暗号化ピースを復号するための復号鍵が例え暴露されたとしても、当該暗号化ピースの取得が回避され得る。従って、不正行為による被害としてコンテンツの不正使用をより効果的に抑制することができる。
【００９４】
尚、シーダ５２が保持する各暗号化ピースに対応するTorrent Fileのバージョン情報が全て同一である場合、シーダ５２はピース情報の送信とは異なるタイミングでバージョン情報をリーチャ５０に送信しても良い。例えば、リーチャ５０との接続のネゴシエーションを行うタイミングなどである。また、シーダ５２がバージョン情報を取得する他の方法として、例えば、シーダ５２がTorrent Fileを用いてハッシュ演算により計算されるハッシュ値を送信し、リーチャ５０がハッシュ値を受信するとこれと同一のハッシュ値が計算されるTorrent Fileを検索し、見付かったTorrent Fileに含まれるバージョン情報を取得するという方法などがある。
【００９５】
＜変形例１＿７＞
上述の第１の実施の形態においては、ノード情報は、各ノードのＩＰアドレス及びポート番号を示すものとしたが、これに限らず、ＩＰアドレスのみを示すようにしても良いし、各ノードのＭＡＣアドレスを示すようにしても良いし、コンテンツ配信サービスの加入時に割り当てられる加入者ＩＤを示すようにしても良いし、ノードのＵＲＬを含むようにしても良いし、ノードのＩＰアドレスとポート番号との組に加えてノードのＵＲＬが含まれていても良い。この場合、各ノードはノード識別情報として、当該ノードのＩＰアドレス、ＭＡＣアドレス、加入者ＩＤ及びＵＲＬのうち少なくとも１つ以上をトラッカ５１に送信すれば良い。
【００９６】
また、上述の第１の実施の形態においては、トラッカ５１がノード情報を生成する際に、各ノードは、ノード識別情報をトラッカ５１に送信するようにした。しかし、これに限らず、ノード識別情報に加えて、Torrent File識別情報をトラッカ５１に送信しても良い。Torrent File識別情報とは、Torrent Fileを一意に識別可能な情報であり、例えば、Torrent Fileの一部又は全部のハッシュ値であっても良いし、Torrent Fileのファイル名であっても良い。また、そのＩＤを示すフィールドを含むようにTorrent Fileを構成し、そのＩＤの値をTorrent File識別情報として取り扱うようにしても良い。この場合、トラッカ５１は、Torrent File識別情報毎にノード情報を生成しても良い。この場合、リーチャ５０からアクセスされたトラッカ５１は、リーチャ５０が送信するTorrent File識別情報に対応するノード情報をリーチャ５０へ送信する。
【００９７】
また、トラッカ５１は、ノード識別情報を基にノードをグループ分けし、グループ毎にノード情報を生成しても良い。この場合、リーチャ５０からアクセスされたトラッカ５１は、当該リーチャ５０のノード識別情報が属するグループに対応するノード情報をリーチャ５０へ送信する。ここで、トラッカ５１は、リーチャ５０が複数のグループに属するようにグループ分けしても良く、この場合、トラッカ５１は、リーチャ５０のノード識別情報が属する全部または一部のグループにそれぞれ対応するノード情報をリーチャ５０へ送信する。
【００９８】
また、トラッカ５１は、ノード情報を生成する際に、Torrent Fileに含まれるバージョン情報を用いてノードをグループ分けしても良い。例えば、トラッカ５１は、各々保持するTorrent Fileに含まれるバージョン情報が同一である各ノードの接続先が、同一のノード情報に示されるようにノード情報を生成する。又は、トラッカ５１は、同一に限らず、所定範囲にあるバージョン（例えば、バージョン１とバージョン２のみ、など）を示すバージョン情報を含むTorrent Fileを保持するノード各ノードの接続先が、同一のノード情報に示されるようにノード情報を生成しても良い。リーチャ５０はトラッカ５１にアクセスしてノード情報を取得する際、Torrent Fileのバージョン情報をトラッカ５１に送信する。トラッカ５１は、リーチャ５０から送信されたバージョン情報に対応するノード情報をリーチャ５０へ送信する。このような構成によれば、ノード情報に接続先が示される全てのノードは、同一又は所定範囲にあるバージョンを示すバージョン情報を含むTorrent Fileを用いて、暗号化ピースの送受信を行うことになる。この場合、そのTorrent Fileが有効である限り、接続相手のノードが有効な暗号化ピースを保持していることになる。言い換えると、接続相手のノードから無効な暗号化ピースをダウンロードしてしまうケースがないことになる。このため、暗号化ピースのより効率的な配信が可能となる。尚、トラッカ５１は、バージョン情報に限らず、変形例１＿２で説明した様々な版管理情報や、変形例１＿６で説明したTorrent File識別情報を用いてノードをグループ分けしても良い。
【００９９】
＜変形例１＿８＞
上述した第１の実施の形態においては、販売サーバ５４がリーチャ５０に送信するTorrent Fileを、リーチャ５０のグループ毎に異ならせても良い。即ち、各々異なる暗号化ピースを示すファイル情報を含むTorrent Fileを、グループ毎に異ならせてリーチャ５０に送信する。その結果、Ｐ２ＰネットワークＮＴにおいて配信される暗号化ピースがグループ毎に異なるようにする。例えば、あるグループに属するリーチャ５０については、暗号化ピースとして{ E( K( i, 1 ) )[ C1 ], E( K( i, 2 ) )[ C2 ], …, E( K( i, N ))[ CN ]} （ただし、1≦i≦2）があることを示すファイル情報を含むTorrent Fileを送信し、他のグループに属するリーチャ５０については、暗号化ピースとして{ E( K( i, 1 ) )[ C1 ], E( K( i, 2))[ C2 ], …, E( K( i, N))[ CN ]}（ただし、3≦i≦5）があることを示すファイル情報を含むTorrent Fileを送信する。
【０１００】
グループ分けは、販売サーバ５４がどの地域向けにコンテンツの配信サービスを行っているかを基準として行っても良い。例えば、日本のユーザ向けの配信サービスを扱う販売サーバ５４がリーチャ５０へ渡すTorrent Fileと、米国のユーザ向けの配信サービスを扱う販売サーバ５４がリーチャ５０へ渡すTorrent Fileとを異ならせるようにしても良い。
【０１０１】
この場合、変形例１＿７で説明したように、トラッカ５１によるノード情報のグループ分けに応じて、Torrent Fileのグループ分けを行うようにしても良い。例えば、トラッカ５１は、ノードが少なくとも１つ以上のグループに属し且つTorrent Fileがグループ毎に異なるように各ノードをグループ分けし、各ノードに対して当該ノードと同じグループに属する他のノードを含むノード情報を送信するようにすれば良い。また、この場合、ノード情報におけるグループと、Torrent Fileにおけるグループとは一対一対応するようにしても良いし、複数対一対応するようにしても良い。
【０１０２】
以上のように、リーチャ５０をグループ分けしてTorrent Fileを送信することにより、リーチャ５０が属するグループとは異なるグループにおいて配信される暗号化ピースを復号するための鍵束が暴露されても、当該リーチャ５０は、Torrent Fileを用いて自身が取得した暗号化ピースを当該鍵束を用いて復号することができない。このため、鍵束を暴露するという不正行為がより起こりにくくなり、また、不正行為が起こった場合の影響範囲をより限定することができる。
【０１０３】
＜変形例１＿９＞
上述した第１の実施の形態においては、Torrent Fileの更新が行われたとき、当該Torrent Fileに含まれるトラッカ接続先情報が変更された場合、更新前のTorrent Fileであって無効化されるTorrent Fileに含まれるトラッカ接続先情報によって接続可能なトラッカ５１の機能を停止させるようにしても良い。即ち、当該トラッカ５１は、アクセスしてきたリーチャ５０へノード情報を送信する自身の機能を停止させる。この場合、例えば、外部装置からトラッカ５１に対して上述の機能の停止を要求する停止要求メッセージを送信する。外部装置とは、例えば、販売サーバ５４、シーダ５２、リーチャ５０、コンテンツプロバイダ、ピース処理装置などである。トラッカ５１は当該停止要求メッセージを受信すると、無効化されるTorrent Fileに含まれるトラッカ接続先情報によってリーチャ５０がアクセスしてきたとしても、ノード情報を送信しない。
【０１０４】
又は、無効化されるTorrent Fileに含まれるトラッカ接続先情報によってアクセスしてきたリーチャ５０全てではなく一部のリーチャ５０のみにトラッカ５１はノード情報を送信しないようにしても良い。例えば、トラッカ５１は、Torrent Fileの更新が行われたとき、当該Torrent Fileに含まれるトラッカ接続先情報が変更された場合、停止要求メッセージに加え、ノード情報を送信しない対象となるリーチャ５０を識別するためのリーチャ識別情報を示すリストを外部装置から取得する。リーチャ識別情報としては、例えば、リーチャ５０のＩＰアドレスやポート番号や、リーチャ５０のＭＡＣアドレスや上述の加入者ＩＤなどやこれらの組み合わせなどがある。そして、トラッカ５１は、アクセスしてきたリーチャ５０からリーチャ識別情報を取得し、当該リーチャ識別情報がリストに存在するか否かを判断し、当該判断結果が肯定的である場合には、当該リーチャ５０にはノード情報を送信しないようにする。
【０１０５】
これらの構成によれば、無効化されるTorrent Fileによる暗号化ピースの取得をより効果的に抑制することができる。結果的に、コンテンツの不正使用をより効果的に抑制することができる。
【０１０６】
また、Torrent Fileの更新が行われたとき、更新前のTorrent Fileであって無効化されるTorrent Fileに含まれるトラッカ接続先情報によって接続可能なトラッカ５１は、アクセスしてきたリーチャ５０に対して、更新されたTorrent Fileを取得することを促す促進メッセージを送信しても良い。リーチャ５０は、当該促進メッセージに従って、更新されたTorrent Fileを販売サーバ５４から取得すれば良い。これにより、リーチャ５０は、更新されたTorrent Fileを用いて暗号化ピースを取得することになるため、より新しい暗号化ピースの取得をリーチャ５０に促すことができる。
【０１０７】
[第２の実施の形態]
次に、コンテンツ配信システムの第２の実施の形態について説明する。なお、上述の第１の実施の形態と共通する部分については、同一の符号を使用して説明したり、説明を省略したりする。
【０１０８】
（１）構成
本実施の形態における構成について、上述の第１の実施の形態において説明したコンテンツ配信システムの基本構成との差異を主に説明する。従って、本実施の形態においては、第１の実施の形態に特有の機能の実現のために用いられるバージョン情報は、Torrent Fileには含まれていなくても良い。従って、鍵サーバ５３は、有効性判断部５３９とTorrent File有効性情報記憶部５４０とを有さなくても良い。本実施の形態において鍵サーバ５３は、リーチャ５０から要求された鍵束に含まれる各復号鍵によって復号される各暗号化ピースをリーチャ５０が実際に保持しているか否かを確認する。
【０１０９】
＜リーチャ５０の構成＞
本実施の形態においては、リーチャ５０は、各暗号化ピースを復号するための各復号鍵を含む鍵束を要求する要求メッセージを鍵サーバ５３に送信した後、鍵サーバ５３からの要求に応じて、各暗号化ピースのうち少なくとも２つ以上の暗号化ピースを用いてハッシュ演算により計算されるハッシュ値を鍵サーバ５３に送信する。図２２は、本実施の形態にかかるリーチャ５０の機能的構成を例示する図である。本実施の形態においては、リーチャ５０は、コンテンツ取得部５００と、鍵束要求部５０１と、鍵束取得部５０２と、コンテンツ復号部５０３に加え、保持証明部５０６を有する。
【０１１０】
保持証明部５０６は、鍵束要求部５０１が鍵サーバ５３に送信した要求メッセージによって要求された鍵束に含まれる復号鍵によって復号される各暗号化ピースを実際に保持していることを証明するための保持証明情報を鍵サーバ５３に送信する。具体的には、保持証明部５０６は、要求メッセージによって要求された鍵束に含まれる復号鍵によって復号される各暗号化ピースのうち、少なくとも２つ以上の暗号化ピースのハッシュ値を保持証明情報として要求する情報要求メッセージを鍵サーバ５３から受信する。そして、保持証明部５０６は、当該情報要求メッセージに従って、該当の暗号化ピースを外部記憶装置から読み出し、これらを連結したデータを用いてハッシュ演算によりハッシュ値を計算する。そして、保持証明部５０６は、計算したハッシュ値を鍵サーバ５３に送信する。
【０１１１】
＜鍵サーバ５３の構成＞
図２３は、本実施の形態にかかる鍵サーバ５３の機能的構成を例示する図である。鍵サーバ５３は、制御部５３０と、パケット処理部５３１と、ネットワークインターフェース部５３２と、認証・鍵交換処理部５３３と、鍵記憶部５３４と、シーケンス情報記憶部５３６と、シーケンス情報照合部５３５と、鍵供給部５３７とに加え、保持証明判断部５４１と保持判断情報記憶部５４２とを有する。保持判断情報記憶部５４２は、認証・鍵交換処理部５３３がリーチャ５０から受信した要求メッセージによって要求された鍵束に含まれる復号鍵によって復号される各暗号化ピースをリーチャ５０が実際に保持しているか否かを判断するための保持判断情報を記憶している。具体的には、保持判断情報記憶部５４２は、保持判断情報として、初期シーダ５２Ａと同じく全ての暗号化ピースをインデックスと対応付けて記憶している。
【０１１２】
保持証明判断部５４１は、認証・鍵交換処理部５３３がリーチャ５０から受信した要求メッセージによって要求された鍵束に含まれる復号鍵によって復号される各暗号化ピースをリーチャ５０が実際に保持しているか否かを、保持判断情報記憶部５４２に記憶された保持判断情報を用いて判断する。具体的には、保持証明判断部５４１は、当該要求メッセージに含まれるインデックス情報を用いて、ハッシュ値を要求する対象の複数の暗号化ピースを選択する。そして、保持証明判断部５４１は、選択した暗号化ピースのハッシュ値を要求する情報要求メッセージをリーチャ５０に送信する。例えば、インデックス情報によって示されるシーケンスが｛( i1, 1 ), ( i2, 2 ), …, ( iN, N)｝である場合、保持証明判断部５４１は、このシーケンスに含まれる各インデックスを２つ以上任意に選択する。そして、保持証明判断部５４１は、選択したインデックスを示すと共に当該インデックスに対応する暗号化ピースのハッシュ値を要求する情報要求メッセージをリーチャ５０に送信する。また、保持証明判断部５４１は、選択した暗号化ピースについて、保持判断情報記憶部５４２から読み出し、これらを用いてハッシュ演算によりハッシュ値を計算する。そして、当該ハッシュ要求メッセージに従ってハッシュ値がリーチャ５０から送信されると、これを保持証明判断部５４１は受信し、これと算出したハッシュ値とを照合する。そして、保持証明判断部５４１は、照合結果に応じて、当該リーチャ５０から受信した要求メッセージによって要求された鍵束に含まれる復号鍵によって復号される各暗号化ピースをリーチャ５０が実際に保持しているか否かを判断する。シーケンス情報照合部５３５は、保持証明判断部５４１の判断結果に応じて、シーケンス情報の照合を行う。
【０１１３】
（２）動作
次に、本実施の形態にかかるコンテンツ配信システムで行うコンテンツ配信処理の手順について図１２を用いて説明する。ステップＳ１〜Ｓ１３は上述の基本構成における処理と同様である。ステップＳ１４では、鍵サーバ５３は、以下の照合処理を行う。図２４は、本実施の形態にかかる照合処理の手順を示すフローチャートである。例えば、ステップＳ１１で鍵サーバ５３が受信した要求メッセージに含まれるインデックス情報が以下に示されるものとする。
{ ( i1, 1 ), ( i2, 2 ), …, ( iN, N) }
（ただし、1≦i1, …, iN≦m）
【０１１４】
鍵サーバ５３の保持証明判断部５４１は、このインデックス情報によって示されるシーケンスに含まれる各インデックスを２つ以上任意に選択する。そして、保持証明判断部５４１は、選択したインデックスを示すと共に当該インデックスに対応する暗号化ピースのハッシュ値を要求する情報要求メッセージをリーチャ５０に送信する（ステップＳ１５０）。例えば、( i2, 2 )と( i4, 4 )により特定される２つの暗号化ピースのハッシュ値を要求する情報要求メッセージがリーチャ５０に送信される。
【０１１５】
一方、リーチャ５０は、情報要求メッセージを受信すると、該当の暗号化ピースを外部記憶装置から読み出し、これらを連結したデータを用いてハッシュ演算によりハッシュ値を計算して（ステップＳ１５１）、これを鍵サーバ５３に送信する（ステップＳ１５２）。例えば、リーチャ５０は、( i2, 2 )と( i4, 4 )により特定される２つの暗号化ピースを連結して、連結したデータを用いてハッシュ演算によりハッシュ値
hash(E( K(i2 , 2 ) ) [ C2 ] || E( K(i4 , 4 ) ) [ C4 ])
を計算する。尚、||はデータ連結を表す。
【０１１６】
鍵サーバ５３は、選択した暗号化ピースについて、保持判断情報記憶部５４２から読み出し、これらを用いてハッシュ演算によりハッシュ値を計算する。そして、鍵サーバ５３は、リーチャ５０から送信されたハッシュ値を受信すると（ステップＳ１５３）、これと、算出したハッシュ値とを照合する（ステップＳ１５４）。そして、これらが一致する場合（ステップＳ１５５：ＹＥＳ）、鍵サーバ５３は、ステップＳ１１で受信した要求メッセージによって要求された鍵束に含まれる復号鍵によって復号される各暗号化ピースをリーチャ５０が実際に保持していると判断し、ステップＳ１４１以降の処理を行う。一方、ステップＳ１５５で前者のハッシュ値と後者のハッシュ値とが一致しない場合（ステップＳ１５５：ＮＯ）、鍵サーバ５３は、ステップＳ１１で受信した要求メッセージによって要求された鍵束に含まれる復号鍵によって復号される各暗号化ピースをリーチャ５０が実際に保持していないと判断し、ステップＳ１４４に進む。即ち、この場合、鍵サーバ５３は、ステップＳ１１で受信した要求メッセージに従わずに、鍵束をリーチャ５０に送信しない。
【０１１７】
以上のようにして、鍵サーバ５３は、リーチャ５０が要求している鍵束を送信する前に、当該鍵束に含まれる復号鍵によって復号される暗号化ピースを実際に保持しているか否かを確認する。そして、鍵サーバ５３は、当該暗号化ピースを実際に保持していないことを確認した場合には、当該鍵束をリーチャ５０に送信しない。これにより、例えば、リーチャ５０が鍵束を漏洩させることを目的として、暗号化ピースをダウンロードせずに鍵サーバ５３に鍵束を要求するという不正行為を排除することができる。
【０１１８】
（３）変形例
＜変形例２＿１＞
上述の第２の実施の形態においては、保持判断情報記憶部５４２は、保持判断情報として、全ての暗号化ピースを記憶するようにしたが、この場合大きな記憶容量を必要とするため、一部の暗号化ピースのみを記憶するようにしても良い。保持判断情報記憶部５４２は、例えば、ピースＣ１〜Ｃ３について各々m個の暗号化ピースとして、E( K( 1, 1 ))[C1]〜E( K( m, 1 ))[C1], E( K( 1, 2 ))[C2]〜 E( K( m, 2 ))[C2], E( K( 1, 3 ))[C3]〜E( K( m, 3 ))[C3]の3m個の暗号化ピースのみを記憶する。そして、保持証明判断部５４１は、保持判断情報記憶部５４２に記憶された暗号化ピースの範囲内で、要求メッセージに含まれるインデックス情報によって示されるシーケンスに含まれるインデックスのうち、( i1, 1 ), ( i2, 2 ),( i3, 3 )の中から２つ以上を選択して、当該インデックスに対応する暗号化ピースのハッシュ値をリーチャ５０に要求すれば良い。このような構成によれば、保持判断情報記憶部５４２において必要とする記憶容量を小さくすることができる。
【０１１９】
尚、ステップＳ１５０では、保持証明判断部５４１は、保持判断情報記憶部５４２に記憶されていない暗号化ピースを選択しても良い。この場合、保持判断情報記憶部５４２は、当該暗号化ピースをシーダ５２や他のリーチャ５０などの他の通信装置から取得すれば良い。
【０１２０】
尚、保持判断情報記憶部５４２は、保持判断情報として、暗号化ピース自体を記憶するのではなく、暗号化ピースのハッシュ値を記憶していても良い。この場合、保持判断情報記憶部５４２は、全ての暗号化ピースのうち少なくとも２つ以上の暗号化ピースの組み合わせ全てについてハッシュ値を記憶しても良いし、リーチャ５０へ要求する又は要求する可能性のあるハッシュ値のみを記憶しても良い。この場合、保持証明判断部５４１は、ステップＳ１５４では、ステップＳ１５３でリーチャ５０から受信したハッシュ値と、保持判断情報記憶部５４２に記憶されステップＳ１５４で選択した２つの暗号化ピースにより計算されるハッシュ値とを照合すれば良い。
【０１２１】
また、この場合、ステップＳ１５０では、保持証明判断部５４１は、保持判断情報記憶部５４２に記憶されていないハッシュ値が計算される暗号化ピースを選択しても良い。この場合、保持判断情報記憶部５４２は、当該ハッシュ値自体や当該ハッシュ値の計算の基になる暗号化ピースをシーダ５２や他のリーチャ５０などの他の通信装置から取得すれば良い。
【０１２２】
＜変形例２＿２＞
上述の第２の実施の形態においては、リーチャ５０は、鍵サーバ５３の要求に応じて、ハッシュ値を計算してこれを保持証明情報として鍵サーバ５３に送信した。しかし、これに限らず、リーチャ５０は、保持証明情報として、２つ以上の暗号化ピースを連結したデータの全部又は一部を鍵サーバ５３に送信するようにしても良い。この場合、鍵サーバ５３の保持証明判断部５４１は、ステップＳ１５０では、要求メッセージに含まれるインデックス情報を用いて、２つ以上の暗号化ピースを選択した後、選択した暗号化ピースのインデックスを示すと共に当該暗号化ピースを連結したデータを要求する情報要求メッセージをリーチャ５０に送信する。ここで、例えば、インデックス(i2 , 2 )に対応する暗号化ピースとインデックス(i4 , 4 )に対応する暗号化ピースとを連結したデータが要求されるとする。この場合、リーチャ５０は、情報要求メッセージを受信すると、ステップＳ１５１では、インデックス(i2 , 2 )に対応する暗号化ピースとインデックス(i4 , 4 )に対応する暗号化ピースとを連結して、データE( K(i2 , 2 ) ) [ C2 ] || E( K(i4 , 4 ) ) [ C4 ]）を生成し、ステップＳ１５２では、当該データを鍵サーバ５３へ送信する。また、鍵サーバ５３の保持証明判断部５４１は、保持判断情報記憶部５４２に記憶されステップＳ１５０で選択された暗号化ピースを連結したデータを生成する。そして、保持証明判断部５４１は、ステップＳ１５３で、当該データを受信すると、ステップＳ１５４では、当該データと、自身が生成したデータとを照合し、これらが一致する場合にステップＳ１４０以降の処理を行えば良い。
【０１２３】
＜変形例２＿３＞
上述の第２の実施の形態においては、鍵サーバ５３がステップＳ１５０で選択する暗号化ピースの数は、２以上の固定値であっても良いし、２以上で適宜変更される可変値であっても良い。
【０１２４】
[変形例]
なお、本発明は前記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、前記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。また、以下に例示するような種々の変形が可能である。
【０１２５】
＜変形例３＿１＞
上述した各実施の形態においては、鍵サーバ５３と、リーチャ５０とは、相互認証の後、通信対象のデータを暗号化するようにしても良い。図２５は、このような構成の鍵サーバの構成を例示する図である。鍵サーバ５３´は、上述の制御部５３０と、パケット処理部５３１と、ネットワークインターフェース部５３２と、認証・鍵交換処理部５３３と、鍵記憶部５３４と、シーケンス情報記憶部５３６と、シーケンス情報照合部５３５と、鍵供給部５３７とに加え、暗号処理部５３８を有する。認証・鍵交換処理部５３３は、リーチャ５０と、通信対象のデータを暗号化するための暗号鍵の交換を行う。暗号処理部５３８は、認証・鍵交換処理部５３３が交換した暗号鍵を用いて通信対象のデータを暗号化してこれをネットワークインターフェース部５３２を介してリーチャ５０に送信する。
【０１２６】
また、上述した各実施の形態においては、復号鍵及び暗号鍵のうち少なくとも一方を鍵サーバ５３自体が発行して生成するようにしても良いし、トラッカ５１やコンテンツ製作者が用意したサーバが発行したり生成したりしたものを鍵サーバ５３が取得するようにしても良い。
【０１２７】
また、コンテンツＣを分割した全てのピースＣ１〜ＣＮが各々異なる暗号鍵で暗号化されているとしたが、これに限らず、一部のピースは同一の暗号鍵で暗号化されていても良い。
【０１２８】
上述した各実施の形態においては、トラッカ５１、シーダ５２及びリーチャ５０の数は、上述したものに限らない。
【０１２９】
また、Ｐ２ＰネットワークＮＴに販売サーバ５４が接続され、リーチャ５０は、販売サーバ５４から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 )｝がシーケンス情報記憶部５３６に未だ記憶されていない場合、鍵サーバ５３は上記に例示した置き換えを行ってもよいし、行わなくてもよい。
【０１３７】
＜変形例３＿３＞
上述の各実施の形態においては、照合処理では、シーケンス情報照合部５３５は、リーチャ５０から要求されている鍵束が１回でも過去にリーチャ５０のいずれかに送信していれば、当該鍵束を送信しないようにした。しかし、これに限らず、同一の鍵束を、２回以上の所定の回数まで送信可能にしても良い。この場合、鍵サーバ５３の認証・鍵交換処理部５３３は、リーチャ５０との間で行う相互認証において、リーチャ５０を識別するためのリーチャ識別情報をリーチャ５０から取得する。シーケンス情報照合部５３５は、鍵束のシーケンスを示すシーケンス情報と、リーチャ識別情報と、当該リーチャ識別情報によって識別されるリーチャ５０が当該鍵束の送信を要求した使用回数とを対応付けてシーケンス情報記憶部５３６に記憶させる。図２６は、本変形例に係る照合処理の手順を示すフローチャートである。尚、同図においては、ステップＳ１４０以前に行う処理については図示を省略している。ステップＳ１４０〜Ｓ１４１は第１の実施の形態と同様である。ステップＳ１４１の判定結果が肯定的である場合、即ち、リーチャ５０から要求されている鍵束のシーケンスと同一のシーケンスを示すシーケンス情報がシーケンス情報記憶部５３６に既に記憶されている場合、当該シーケンス情報と、当該リーチャ５０のリーチャ識別情報と対応付けられてシーケンス情報記憶部５３６に記憶されている使用回数を参照して、当該使用回数が所定回数以下であるか否かを判断する（ステップＳ１４０Ａ）。当該判断結果が肯定的である場合、シーケンス情報照合部５３５は、当該シーケンス情報と、当該リーチャ識別情報と対応付けられてシーケンス情報記憶部５３６に記憶されている使用回数を１つインクリメントすることにより、当該使用回数を更新して（ステップＳ１４０Ｂ）、上述と同様のステップＳ１４３の処理を行う。また、ステップＳ１４１の判断結果が否定的である場合、シーケンス情報照合部５３５は、上述と同様にステップＳ１４２以降の処理を行う。尚、ステップＳ１４０Ａの判断結果が否定的である場合は、シーケンス情報照合部５３５は、上述のステップＳ１４４と同様の処理を行う。
【０１３８】
このような構成によれば、暗号化ピースにおける同一のシーケンスの使用を１回のみならず複数回許可することになり、より柔軟なコンテンツ配信を実現することができる。
【０１３９】
＜変形例３＿４＞
上述した各実施の形態においては、シーダ５２がリーチャ５０に送信するピース情報は、図７に示されるように、当該シーダ５２が記憶している暗号化ピースのシーケンスを示すものであった。しかし、ピース情報は、シーダ５２が記憶している暗号化ピースの各インデックス(i, j)のうち、各ピースＣ１〜ＣＮを区別するためのインデックスjのみを示すものであっても良い。図２７〜２９は、本変形例にかかるピース情報を例示する図である。この場合、Torrent Fileに含まれるファイル情報は、例えば、上述の変形例１＿１で説明したように、各暗号化ピースを用いてハッシュ演算により計算されるハッシュ値{ hash( E( K( i, j ) )[ Cj ] ) }（ただし、1≦i≦m、1≦j≦N）を含んでいるものとする（図１７参照）。尚、以降、各ピースＣ１〜ＣＮを区別するためのインデックス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を特定する。ステップＳ１０以降は上述の第１の実施の形態又は第２の実施の形態と同様である。
【０１４３】
以上のようにして、リーチャ５０が暗号化ピースを受信する前に、シーダ５２が記憶している暗号化ピースのバリエーションインデックスiを特定できないようにした場合、コンテンツの不正使用をより一層効果的に抑制することができる。リーチャ５０が、例えばその復号鍵が漏洩したあるインデックス(i, j)に対応する暗号化ピースを取得しようとすることを抑制することができるからである。
【０１４４】
＜変形例３＿５＞
上述の変形例３＿４においては、シーダ５２は、リーチャ５０へ暗号化ピースを送信する場合、ピース情報とは別に、当該暗号化ピースのバリエーションインデックスを示すバリエーションインデックス情報をリーチャ５０へ送信するようにしても良い。この場合、リーチャ５０は、上述のように、暗号化ピースのハッシュ値を計算する必要はない。このため、Torrent Fileに含まれるファイル情報は、各暗号化ピースのハッシュ値を含んでいなくても良い。図３１は、本変形例にかかるコンテンツ配信処理の手順を示すフローチャートである。ステップＳ１〜Ｓ８は上述の変形例３＿４と同様である。ステップＳ４００３では、シーダ５２は、リーチャ５０へ送信する対象の暗号化ピースのバリエーションインデックスを示すバリエーションインデックス情報をリーチャ５０へ送信し、ステップＳ４００４で、リーチャ５０は当該バリエーションインデックス情報を受信する。ステップＳ９〜Ｓ１６は、上述の第１の実施の形態又は第２の実施の形態と同様である。尚、ステップＳ４００３〜Ｓ４００４は、ステップＳ９の後であっても構わない。
【０１４５】
このような構成によれば、リーチャ５０における暗号化ピースのバリエーションインデックスの特定を容易にしつつ、例えばその復号鍵が漏洩したあるインデックス(i, j)に対応する暗号化ピースを取得しようとすることを抑制することができる。
【０１４６】
＜変形例３＿６＞
上述した各実施の形態においては、リーチャ５０は、１つの暗号化ピースを複数回に分けてシーダ５２から受信するように構成しても良い。この場合、リーチャ５０は、暗号化ピースについて、暗号化ピースの一部である部分データ（サブピースという）をシーダ５２に要求するピース要求（一部データ要求という）を送信する。尚、各サブピースのデータ長は、一定の長さであっても良いし、可変長でも良い。また、暗号化ピースが何個のサブピースで構成されるかについては限定されず、一定の個数にしても良いし、可変にしても良い。また、各サブピースのデータ長や、１つの暗号化ピースを構成する全部のサブピースの個数は、コンテンツ配信システムに初期値として予め設定されるようにしても良いし、Torrent Fileにおいて予め示されるようにしても良い。尚、ここでは、Torrent Fileに含まれるファイル情報は、各暗号化ピースのデータ長を含むものとし、ハッシュ値を含んでいなくても良い。
【０１４７】
図３２は、本変形例にかかるリーチャ５０の機能的構成を例示する図である。リーチャ５０は、上述したコンテンツ取得部５００と、鍵束要求部５０１と、鍵束取得部５０２と、コンテンツ復号部５０３とに加え、サブピース完成判定部５０４と、セッション情報管理部５０５とを有する。尚、リーチャ５０は、暗号化ピースについてそのデータの全部を要求することも、サブピースを要求することもいずれも可能であるとする。前者については、上述の各実施の形態と略同様であるので、ここでは、後者について主に説明する。
【０１４８】
本変形例にかかるコンテンツ取得部５００は、ピース要求をシーダ５２に送信する際に、取得対象の暗号化ピースについて、データの一部を取得済みであるか否かを判断し、データの一部を取得済みであると判断した場合、一部データ要求を生成してこれをシーダ５２に送信する。一部データ要求は、例えば、取得対象である一部取得済み暗号化ピースを指定する指定ピースインデックス及び指定バリエーションインデックスの組（i,j）と、当該一部取得済み暗号化ピースの一部のデータであるサブピースを指定するサブピース指定情報とを示す。サブピース指定情報は、当該一部取得済み暗号化ピースの一部のデータ（サブピース）のデータ範囲を指定するものである。データ範囲は、例えば、当該サブピースの開始位置としてバイト数等で表されるオフセット値、当該サブピースの終了位置としてバイト数等で表されるオフセット値、当該サブピースのデータ長などやそれらの組み合わせなどを用いて指定される。図３３は、本変形例にかかるピース要求のデータ構成を例示する図である。同図においては、一部データ要求として、指定ピースインデックス及び指定バリエーションインデックスの組と、サブピース指定情報として、サブピースの開始位置及びデータ長とが示されている。この一部データ要求は、インデックス(3,4)に対応する暗号化ピースE( K( 3, 4 ) )[C4]のデータのうち、先頭位置（0バイト目）から54677バイト目を開始位置とし、当該開始位置から54676バイトを有するデータ範囲のデータが取得対象のサブピースとして指定されていることが示されている。
【０１４９】
尚、コンテンツ取得部５００は、ピース要求をシーダ５２に送信する際に、取得対象の暗号化ピースについて、データの全部を未取得であると判断した場合、上述の各実施の形態で説明したようなピース要求を生成してこれをシーダ５２に送信する。
【０１５０】
サブピース完成判定部５０４は、コンテンツ取得部５００が暗号化ピース又はサブピースを受信した場合、当該暗号化ピース又は当該サブピースを一部とする暗号化ピースについて、その全部のデータを取得済みであるか否かを判定する完成判定処理を行う。この完成判定処理は、例えば、そのデータ長や、暗号化ピースにおけるデータの先頭位置や終了位置からデータ長を計算すること等により行う。ここでは、サブピース完成判定部５０４は、後述するセッション情報において示される取得済み量と、Torrent Fileに含まれるデータ長とを参照して、完成判定処理を行う。そして、サブピース完成判定部５０４は、判定対象の暗号化ピースについて、その全部のデータを取得済みであると判定した場合、当該暗号化ピースが複数のサブピースから構成されている場合には、当該暗号化ピースを構成する全てのサブピースを統合して、暗号化ピースを完成させる完成処理を行う。
【０１５１】
また、サブピース完成判定部５０４は、判定対象の暗号化ピースについて、その全部のデータを取得済みでないと判定した場合、後述のセッション情報を参照して、当該暗号化ピースを構成するサブピースを送信したシーダ５２にアクセスして、当該暗号化ピースを構成するサブピースのうち未だ取得していないサブピース（未取得サブピースという）を要求する一部データ要求を、コンテンツ取得部５００を介してシーダ５２に送信する。このようにして、サブピース完成判定部５０４は、コンテンツ取得部５００を介して未取得サブピースの取得を試みる。例えば、サブピース完成判定部５０４は、当該暗号化ピースを構成するサブピース全て取得するまで、未取得サブピースをシーダ５２から取得する処理を繰り返し行う。
【０１５２】
セッション情報管理部５０５は、サブピースの送信元であるシーダ５２に対して未取得サブピースを再度要求するために用いるセッション情報を生成してこれを記憶する。セッション情報は、例えば、シーダ特定情報と、取得済み量とを示す。シーダ特定情報とは、サブピースの送信元であるシーダ５２を特定する情報である。シーダ特定情報としては、例えば、シーダ５２のＩＰアドレスやポート番号や、シーダ５２のＭＡＣアドレスや上述の加入者ＩＤなどやこれらの組み合わせなどがある。取得済み量とは、暗号化ピースのうち取得済みのデータの数量を示す。取得済み量としては、例えば、暗号化ピースにおけるデータの先頭位置や取得済みのデータの終了位置から計算されるデータ長や、暗号化ピースを構成するサブピースのうち取得済みのサブピースのデータ長の合計や、当該取得済みのサブピースの個数などがある。
【０１５３】
一方、シーダ５２は、一部データ要求において要求されたサブピースを外部記憶装置から読み出してこれをリーチャ５０に送信する。図３３に示された一部データ要求を受信した場合は、シーダ５２は、当該一部データ要求において示される指定ピースインデックス及び指定ピースインデックスに対応する暗号化ピースのうち、指定されたデータ範囲のデータを送信する。
【０１５４】
図３４は、本変形例にかかるコンテンツ配信システムで行うコンテンツ配信処理の手順を示すフローチャートである。ステップＳ１〜Ｓ４の処理は、上述の各実施の形態と同様である。ステップＳ３００では、リーチャ５０は、暗号化ピースのダウンロード処理を行う。一方、シーダ５２は、ステップＳ３０１で、暗号化ピースのアップロード処理を行う。図３５は、ダウンロード処理及びアップロード処理の詳細な手順を示すフローチャートである。ステップＳ５〜Ｓ７の処理は、上述の各実施の形態と同様である。ステップＳ３１０では、リーチャ５０は、ピース要求をシーダ５２に送信する際に、取得対象の暗号化ピースについて、データの一部を取得済みであるか否かを判断する。データの一部を取得済みであると判断した場合（ステップＳ３１０：ＹＥＳ）、リーチャ５０は、セッション情報のシーダ特定情報を参照して（ステップＳ３１３）、取得対象の暗号化ピースを構成するサブピースの送信元であるシーダ５２を特定し、図３２に示されるような一部データ要求をピース要求として生成して（ステップＳ３１４）、これを当該シーダ５２に送信する（ステップＳ３１２）。尚、取得対象の暗号化ピースについて、データの全部を未取得であると判断した場合（ステップＳ３１０：ＮＯ）、リーチャ５０は、上述の各実施形態で説明したピース要求を生成して（ステップＳ３１１）、これをシーダ５２に送信する（ステップＳ３１２）。
【０１５５】
一方、シーダ５２は、ステップＳ３１２で送信されたピース要求を受信すると、当該ピース要求に応じた暗号化ピース又はサブピースを外部記憶装置から読み出してこれをリーチャ５０に送信する（ステップＳ３１５）。リーチャ５０は、暗号化ピース又はサブピースを受信すると（ステップＳ３１６）、セッション情報において取得済み量を更新する（ステップＳ３１７）。次いで、リーチャ５０は、ピース要求が完了したか否かを判定する（ステップＳ３１８）。ここでは、リーチャ５０は、ステップＳ３１２でサブピースを受信した場合には、当該サブピースから構成される暗号化ピースについて、セッション情報に示される取得済み量と、Torrent Fileに含まれるデータ長とを比較し、これらが一致する場合には、当該暗号化ピースについて、その全部のデータを取得済みであると判定し、ピース要求が完了したと判定する（ステップＳ３１８：ＹＥＳ）。そして、リーチャ５０は、当該暗号化ピースを構成する全てのサブピースを統合して、暗号化ピースを完成させる完成処理を行う。次いで、リーチャ５０は、他のシーダ５２にアクセスして、他の暗号化ピースを受信するか否かを判断し（ステップＳ３１９）、当該判断結果が肯定的である場合には、ステップＳ５に戻り、他のシーダ５２にアクセスする。ステップＳ３１９の判断結果が否定的である場合には、処理を終了する。
【０１５６】
一方、ステップＳ３１８で、セッション情報に示される取得済み量と、Torrent Fileに含まれるデータ長とが一致する場合には、リーチャ５０は、当該暗号化ピースについて、その全部のデータを取得済みでないと判定し、ピース要求が完了していないと判定する。この場合、リーチャ５０は、ステップＳ５に戻り、セッション情報を参照して、当該暗号化ピースを構成するサブピースを送信したシーダ５２に再度アクセスする。そして、以降の処理では、リーチャ５０は、当該暗号化ピースを構成するサブピースのうち未取得サブピースを要求する一部データ要求を生成してこれをシーダ５２に送信し、当該暗号化ピースを構成するサブピース全て取得するまで、未取得サブピースをシーダ５２から取得する処理を繰り返し行う。
【０１５７】
尚、リーチャ５０がステップＳ３１１の後、ステップＳ３１６で暗号化ピースを受信する場合、何らかの原因で暗号化ピースのデータのうち全部を受信し切れない場合がある。この場合も、ステップＳ３１５でサブピースを受信した場合と同様に、ステップＳ３１８では、リーチャ５０は、セッション情報に示される取得済み量と、Torrent Fileに含まれるデータ長とを比較することにより、ピース要求が完了したか否かを判定する。そして、ピース要求が完了していないと判定した場合、リーチャ５０は、ステップＳ５に戻り、セッション情報を参照して、当該暗号化ピースを送信したシーダ５２に再度アクセスする。そして、以降の処理では、リーチャ５０は、当該暗号化ピースのうち未取得のデータ（未取得サブピースと同様に扱う）を要求する一部データ要求を生成してこれをシーダ５２に送信する。以降は上述と同様である。一方、ステップＳ３１８で、リーチャ５０は、一度の受信でピース要求が完了したと判定した場合、上述したステップＳ３１９の処理を行う。
【０１５８】
そして、図３４に戻り、リーチャ５０は、コンテンツを構成する各ピースに各々対応する暗号化ピースであって暗号化コンテンツを構成する全ての暗号化ピースについて、全てのデータを取得すると、上述の第１の実施の形態又は第２の実施の形態と同様にして、ステップＳ１０以降の処理を行う。
【０１５９】
以上のように、リーチャ５０が暗号化ピースを複数回に分けて各々サブピースとして取得する場合であっても、暗号化ピースの取得と同様にTorrent Fileを用いるため、当該Torrent Fileに含まれるバージョン情報を鍵サーバ５３が照合し照合結果に応じて鍵束を送信することにより、コンテンツの不正使用をより効果的に抑制することができる。
【０１６０】
尚、一部データ要求は、一部取得済み暗号化ピースを指定する指定ピースインデックス及び指定バリエーションインデックスの組（i,j）ではなく、指定ピースインデックスjを少なくとも示すようにしても良い。この場合、シーダ５２は、一部データ要求を受信すると、当該一部取得済み暗号化ピースを指定する指定バリエーションインデックスと、サブピースを指定する情報とをリーチャ５０に問い合わせることにより、これらの情報を取得して、送信対象のサブピースを特定して当該サブピースをリーチャ５０に送信するようにしても良い。このような構成によれば、シーダ５２に対する攻撃耐性が向上し得る。
【０１６１】
＜変形例３＿７＞
上述の第１の実施の形態又は第２の実施の形態の一部及び全部や各変形例を組み合わせても良い。
【０１６２】
＜変形例３＿８＞
上述した各実施の形態において、リーチャ５０で実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成しても良い。また、当該各種プログラムを、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ、ＤＶＤ（Digital Versatile Disk）等のコンピュータで読み取り可能な記録媒体に記録して提供するように構成しても良い。この場合には、プログラムは、リーチャ５０において上記記録媒体から読み出して実行することにより主記憶装置（例えばＲＡＭ）上にロードされ、上記機能的構成において説明した各部が主記憶装置上に生成される。シーダ５２において実現される各種プログラム、鍵サーバ５３において実現される各種プログラム、トラッカ５１において実現される各種プログラムについても同様である。
【０１６３】
[他の態様の発明１]
前記情報取得手段は、前記ファイル情報と、当該ファイル情報が更新される度に更新される版を示す情報である前記版管理情報と取得する
ことを特徴とする請求項２に記載の通信装置。
[他の態様の発明２]
前記情報取得手段は、前記ファイル情報と、当該ファイ情報が生成された時刻を示す情報である前記版管理情報と取得する
ことを特徴とする請求項２に記載の通信装置。
[他の態様の発明３]
前記情報取得手段は、前記ファイル情報と、当該ファイル情報によって示される前記第１暗号化ピース及び前記第２暗号化ピースの全部又は一部を用いて所定の演算により計算される演算値である前記版管理情報と取得する
ことを特徴とする請求項２に記載の通信装置。
[他の態様の発明４]
前記情報取得手段は、
最新の前記ファイル情報を保持する販売サーバから前記ファイル情報を受信することにより取得する第１取得手段と、
前記ファイル情報によって示される前記第１暗号化ピース及び前記第２暗号化ピースの全部又は一部を用いて所定の演算により演算値を計算することにより、当該演算値である前記版管理情報を取得する第２取得手段とを有する
ことを特徴とする他の態様の発明３に記載の通信装置。
[他の態様の発明５]
前記情報取得手段は、前記管理サーバへアクセスするための第１アクセス情報と、前記ファイル情報と、前記版管理情報とを取得し、
前記第１受信手段は、取得された前記第１アクセス情報を用いて、前記管理サーバにアクセスして、前記ノード情報を受信し、
前記第２受信手段は、受信された前記ノード情報を用いて、前記他の通信装置にアクセスして、前記ファイル情報を用いて、前記第１暗号化ピース又は前記第２暗号化ピースを受信する
ことを特徴とする請求項７に記載の通信装置。
[他の態様の発明６]
更新された前記ファイル情報の取得を促す取得促進メッセージを前記管理サーバから受信する促進受信手段を更に備え、
前記情報取得手段は、前記取得促進メッセージに従い、更新された前記ファイル情報を少なくとも取得する
ことを特徴とする請求項７に記載の通信装置。
[他の態様の発明７]
前記第２記憶手段は、有効性を有する少なくとも１つ以上の前記ファイル情報の前記版管理情報を示す有効性情報及び有効性を有する前記ファイル情報の前記版管理情報の範囲を特定する有効性情報のうち少なくとも一方を記憶する
ことを特徴とする請求項１４に記載の鍵サーバ。
[他の態様の発明８]
前記第２記憶手段は、少なくとも１つ以上の前記ファイル情報の前記版管理情報と、前記ファイル情報の有効期限を示す有効性情報とを対応付けて記憶し、
前記判断手段は、受信された前記版管理情報について、当該版管理情報と対応付けられて前記第２記憶手段に記憶されている前記有効性情報を参照して、有効期限内であるか否かを判断することにより、前記要求メッセージによって要求された前記各復号鍵が有効であるか否かを判断する
ことを特徴とする請求項１３に記載の鍵サーバ。
[他の態様の発明９]
前記要求受信手段は、前記要求メッセージ及び各前記対応暗号化ピースのそれぞれについて前記版管理情報を受信し、
前記判断手段は、ピース毎の前記第１暗号化ピース又は前記第２暗号化ピースのそれぞれについて、前記版管理情報と、前記有効性情報とを照合することにより、前記要求メッセージによって要求された前記各復号鍵が有効であるか否かを各々判断し、
前記決定手段は、前記各復号鍵が全て有効であると判断された場合、前記要求メッセージによって要求された前記各復号鍵の組み合わせに基づいて、当該各復号鍵を送信するか否かを決定する
ことを特徴とする請求項１３に記載の鍵サーバ。
[他の態様の発明１０]
前記第２記憶手段は、ピース毎の前記第１暗号化ピース又は前記第２暗号化ピースのうち少なくとも２つ以上のピースに各々対応する前記第１暗号化ピース又は前記第２暗号化ピースを用いて所定の演算により計算される演算値である前記保持証明情報を記憶し、
前記保持証明判断手段は、受信された前記演算値と、記憶された前記演算値とを用いて、前記要求メッセージによって要求された前記各復号鍵によって復号されるピース毎の前記第１暗号化ピース又は前記第２暗号化ピースを前記通信装置が保持しているか否かを判断する
ことを特徴とする請求項１８に記載の鍵サーバ。
[他の態様の発明１１]
前記第２記憶手段は、前記第１暗号化ピース及び前記第２暗号化ピースの全部又は一部を記憶し、
前記保持証明判断手段は、
前記第２記憶手段に記憶された前記第１暗号化ピース及び前記第２暗号化ピースの全部又は一部のうち、前記少なくとも２つ以上のピースに各々対応する前記第１暗号化ピース又は前記第２暗号化ピースを用いて所定の演算により演算値を計算する計算手段と、
受信された前記演算値と、記憶された前記演算値とを用いて、前記要求メッセージによって要求された前記各復号鍵によって復号されるピース毎の前記第１暗号化ピース又は前記第２暗号化ピースを前記通信装置が保持しているか否かを判断する判断手段とを有する
ことを特徴とする請求項１８に記載の鍵サーバ。
[他の態様の発明１２]
前記情報取得手段は、前記ファイル情報が更新される度に更新される版を示す情報である前記版管理情報を取得し、
前記分類手段は、前記版管理情報によって示されるものが同一又は所定範囲にある前記ファイル情報を有するものが同一のグループに属するように、前記通信装置及び前記他の通信装置のうち少なくとも一方をグループ分けする
ことを特徴とする請求項２２に記載の管理サーバ。
[他の態様の発明１３]
前記情報取得手段は、前記ファイ情報が生成された時刻を示す情報である前記版管理情報を取得し、
前記分類手段は、前記版管理情報によって示されるものが同一又は所定範囲にある前記ファイル情報を有するものが同一のグループに属するように、前記通信装置及び前記他の通信装置のうち少なくとも一方をグループ分けする
ことを特徴とする請求項２２に記載の管理サーバ。
[他の態様の発明１４]
前記情報取得手段は、前記ファイル情報によって示される前記第１暗号化ピース及び前記第２暗号化ピースの全部又は一部を用いて所定の演算により計算される演算値である前記版管理情報を取得し、
前記分類手段は、前記版管理情報によって示されるものが同一又は所定範囲にある前記ファイル情報を有するものが同一のグループに属するように、前記通信装置及び前記他の通信装置のうち少なくとも一方をグループ分けする
ことを特徴とする請求項２２に記載の管理サーバ。
[他の態様の発明１５]
前記ファイル情報が更新され且つ当該ファイル情報に対応付けられる前記第１アクセス情報が変更された場合、前記接続先情報の送信の停止を要求する停止要求メッセージを外部装置から受信する受信手段を備え、
前記情報送信手段は、前記停止要求メッセージが受信された場合、当該管理サーバにアクセスした前記通信装置に対して、前記接続先情報を送信せずに、更新された前記ファイル情報の取得を促す取得促進メッセージを送信する
ことを特徴とする請求項２１に記載の管理サーバ。
【図面の簡単な説明】
【０１６４】
【図１】第１の実施の形態にかかるコンテンツ配信システムの基本的構成を示すブロック図である。
【図２】コンテンツが複数のピースに分割された状態を模式的に示す図である。
【図３】各暗号化ピースを模式的に示す図である。
【図４】シーダ５２Ａが記憶している各暗号化ピースを例示する図である。
【図５】シーダ５２Ａが記憶している各暗号化ピースを例示する図である。
【図６】シーダ５２Ａが記憶している各暗号化ピースを例示する図である。
【図７】ピース情報のデータ構成を例示する図である。
【図８】リーチャ５０の基本的な機能的構成を例示する図である。
【図９】基本的なTorrent Fileを例示する図である。
【図１０】鍵サーバ５３の基本的な機能的構成を例示する図である。
【図１１】ノード情報のデータ構成を例示する図である。
【図１２】コンテンツ配信処理の基本的な手順を示すフローチャートである。
【図１３】照合処理の基本的な手順を示すフローチャートである。
【図１４】同実施形態にかかるTorrent Fileのデータ構成を例示する図である。
【図１５】本構成における鍵サーバ５３の機能的構成を例示する図である。
【図１６】同実施の形態にかかる照合処理の手順を示すフローチャートである。
【図１７】同実施の形態の一変形例にかかるTorrent Fileのデータ構成を例示する図である。
【図１８】同実施の形態の一変形例にかかるハッシュ値を含むインデックス情報を例示する図である。
【図１９】同実施の形態の一変形例にかかるTorrent Fileを例示する図である。
【図２０】同実施の形態の一変形例にかかるリーチャ５０の機能的構成を例示する図である。
【図２１】同実施の形態の一変形例にかかるコンテンツ配信システムで行うコンテンツ配信処理の手順示すフローチャートである。
【図２２】第２の実施の形態にかかるリーチャ５０の機能的構成を例示する図である。
【図２３】同実施の形態にかかる鍵サーバ５３の機能的構成を例示する図である。
【図２４】同実施の形態にかかる照合処理の手順を示すフローチャートである。
【図２５】一変形例にかかる鍵サーバの構成を例示する図である。
【図２６】一変形例にかかる照合処理の手順を示すフローチャートである。
【図２７】一変形例にかかるピース情報を例示する図である。
【図２８】同変形例にかかるピース情報を例示する図である。
【図２９】同変形例にかかるピース情報を例示する図である。
【図３０】同変形例にかかるコンテンツ配信システムで行うコンテンツ配信処理の手順を示す図である。
【図３１】一変形例にかかるコンテンツ配信システムで行うコンテンツ配信処理の手順を示す図である。
【図３２】一変形例にかかるリーチャ５０の機能的構成を例示する図である。
【図３３】同変形例にかかるピース要求のデータ構成を例示する図である。
【図３４】同変形例にかかるコンテンツ配信システムで行うコンテンツ配信処理の手順を示すフローチャートである。
【図３５】同変形例にかかるダウンロード処理及びアップロード処理の詳細な手順を示すフローチャートである。
【符号の説明】
【０１６５】
５０，５０Ａ，５０Ｂ  リーチャ（通信装置）
５１  トラッカ（管理サーバ）
５２，５２Ａ，５２Ｂ，５２Ｃ  シーダ（通信装置）
５３  鍵サーバ
５４  販売サーバ
５００  コンテンツ取得部（コンテンツ受信手段）
５００ａ  有効性判断部
５０１  鍵束要求部（送信手段）
５０２  鍵束取得部（鍵受信手段）
５０３  コンテンツ復号部（復号手段）
５０４  サブピース完成判定部
５０５  セッション情報管理部
５０６  保持証明部
５３０  制御部
５３１  パケット処理部
５３２  ネットワークインターフェース部（受信手段、送信手段）
５３３  認証・鍵交換処理部
５３４  鍵記憶部（第１記憶手段）
５３５  シーケンス情報照合部（決定手段）
５３６  シーケンス情報記憶部（第２記憶手段）
５３７  鍵供給部（送信手段）
５３８  暗号処理部
５３９  有効性判断部
５４０  Torrent File有効性情報記憶部
５４１  保持証明判断部
５４２  保持判断情報記憶部
ＮＴ  Ｐ２Ｐネットワーク
【図１】
2010021888.tif 000003
【図２】
2010021888.tif 000004
【図３】
2010021888.tif 000005
【図４】
2010021888.tif 000006
【図５】
2010021888.tif 000007
【図６】
2010021888.tif 000008
【図７】
2010021888.tif 000009
【図８】
2010021888.tif 000010
【図９】
2010021888.tif 000011
【図１０】
2010021888.tif 000012
【図１１】
2010021888.tif 000013
【図１２】
2010021888.tif 000014
【図１３】
2010021888.tif 000015
【図１４】
2010021888.tif 000016
【図１５】
2010021888.tif 000017
【図１６】
2010021888.tif 000018
【図１７】
2010021888.tif 000019
【図１８】
2010021888.tif 000020
【図１９】
2010021888.tif 000021
【図２０】
2010021888.tif 000022
【図２１】
2010021888.tif 000023
【図２２】
2010021888.tif 000024
【図２３】
2010021888.tif 000025
【図２４】
2010021888.tif 000026
【図２５】
2010021888.tif 000027
【図２６】
2010021888.tif 000028
【図２７】
2010021888.tif 000029
【図２８】
2010021888.tif 000030
【図２９】
2010021888.tif 000031
【図３０】
2010021888.tif 000032
【図３１】
2010021888.tif 000033
【図３２】
2010021888.tif 000034
【図３３】
2010021888.tif 000035
【図３４】
2010021888.tif 000036
【図３５】
2010021888.tif 000037