(57)【特許請求の範囲】
【請求項１】
コンテンツの一部である複数のピースの送信を行う通信装置であって、
前記複数のピースを各々暗号鍵で暗号化することによって得られる複数の暗号化ピースを記憶する手段であって、前記複数のピースのうち少なくとも１つの第１ピースを複数の異なる暗号鍵で暗号化することによって得られる複数の暗号化ピースを記憶する第１記憶手段と、
前記第１記憶手段に記憶された前記暗号化ピースのそれぞれの送信回数を記憶する第２記憶手段と、
前記第１ピースが暗号化された前記複数の暗号化ピースのうち前記送信回数が０回である未送信暗号化ピースの個数に基づいて、前記第１ピースのうち少なくとも１つの第１ピースに対応する前記複数の暗号化ピースを優先ピースとして選定する選定手段と、
選定された優先ピースを特定する優先ピース情報を前記第２記憶手段に記憶させる記憶制御手段と、
暗号化ピースを要求するピース要求を他の通信装置から受信する要求受信手段と、
前記ピース要求が受信された場合、前記優先ピース情報によって前記優先ピースとして特定される前記複数の暗号化ピースを送信候補として決定する第１決定手段と、
送信候補として決定された前記複数の暗号化ピースのうち少なくとも１つの前記未送信暗号化ピースを送信対象として決定する第２決定手段と、
送信対象として決定された前記暗号化ピースを前記他の通信装置に送信する送信手段と、
前記送信手段によって送信された暗号化ピースに従い、前記第２記憶手段に記憶された前記暗号化ピースの送信回数を更新する第１更新手段と、
前記優先ピース情報によって優先ピースとして特定される複数の暗号化ピースのうち前記未送信暗号化ピースが存在しなくなった場合、前記優先ピース情報によって優先ピースが特定されない初期状態になるように、前記第２記憶手段に記憶された当該優先ピース情報を前記第２記憶手段において更新する第２更新手段とを備える
ことを特徴とする通信装置。
【請求項２】
前記選定手段は、前記未送信暗号化ピースの個数が同数である第１ピースが複数存在する場合、当該各第１ピースに対応して存在する前記複数の暗号化ピースの個数に基づいて、前記優先ピースを選定する
ことを特徴とする請求項１に記載の通信装置。
【請求項３】
前記第１ピースに対応する前記複数の暗号化ピースには、前記複数のピースの各々を区別するためのピースインデックスと、前記複数の異なる暗号鍵の各々を区別するためのバリエーションインデックスとが各々対応付けられており、
前記送信回数には、前記暗号化ピースに対応付けられた前記ピースインデックス及びバリエーションインデックスが対応付けられており、
前記選定手段は、前記少なくとも１つの第１ピースに対応する前記複数の暗号化ピースについて、各前記複数の暗号化ピースに対応する前記ピースインデックスに対応付けられた前記送信回数が０回である前記未送信暗号化ピースの個数に基づいて、少なくとも１つの前記ピースインデックスを優先ピースとして選定し、
前記記憶制御手段は、前記優先ピースとして選定された前記ピースインデックスを特定する情報を前記優先ピース情報として前記第２記憶手段に記憶させる
ことを特徴とする請求項１又は２に記載の通信装置。
【請求項４】
前記選定手段は、前記未送信暗号化ピースの個数が同数である前記ピースインデックスが複数存在する場合、当該各ピースインデックスの大小に基づいて、少なくとも１つの前記ピースインデックスを優先ピースとして選定する
ことを特徴とする請求項３に記載の通信装置。
【請求項５】
前記選定手段は、前記未送信暗号化ピースの個数が同数である第１ピースが複数存在する場合、他の通信装置が保持する暗号化ピースの個数に基づいて、前記優先ピースを選定する
ことを特徴とする請求項１乃至４のいずれか一項に記載の通信装置。
【請求項６】
前記要求受信手段は、要求する暗号化ピースに対応付けられている前記ピースインデックスと前記バリエーションインデックスとの組を指定する前記ピース要求を受信し、
前記第１決定手段は、前記ピース要求が受信された場合、前記ピース要求によって指定された前記ピースインデックスのうち、前記優先ピース情報によって特定される前記ピースインデックスと一致するピースインデックスのうち少なくとも１つを、送信候補とする暗号化ピースのピースインデックスとして決定し、
前記第２決定手段は、決定された前記ピースインデックス及び当該ピースインデックスとの組が前記ピース要求において指定された前記バリエーションインデックスが対応付けられている暗号化ピースについて、前記送信回数を参照して、前記未送信暗号化ピースのうち少なくとも１つを、送信対象の暗号化ピースとして決定する
ことを特徴とする請求項３に記載の通信装置。
【請求項７】
前記要求受信手段は、要求する暗号化ピースに対応付けられている前記ピースインデックスを指定する前記ピース要求を受信し、
前記第１決定手段は、前記ピース要求が受信された場合、前記ピース要求によって指定された前記ピースインデックスのうち、前記優先ピース情報によって特定される前記ピースインデックスと一致するピースインデックスのうち少なくとも１つを、送信候補とする暗号化ピースのピースインデックスとして決定し、
前記第２決定手段は、決定された前記ピースインデックスに対応付けられている前記複数の暗号化ピースのそれぞれについて、前記送信回数を参照して、前記未送信暗号化ピースのうち少なくとも１つを、送信対象の暗号化ピースとして決定する
ことを特徴とする請求項３に記載の通信装置。
【請求項８】
前記要求受信手段は、前記他の通信装置がデータの一部を取得済みである暗号化ピースに対応付けられている前記ピースインデックス及び前記バリエーションインデックスを指定すると共に、当該暗号化ピースの未取得のデータのデータ範囲を指定して、当該データを要求する一部データ要求を含む前記ピース要求を受信し、
前記第１決定手段は、前記ピース要求に前記一部データ要求が含まれる場合、前記一部データ要求によって指定された前記ピースインデックスのうち、前記優先ピース情報によって特定される前記ピースインデックスと一致するピースインデックスのうち少なくとも１つを、送信候補とする暗号化ピースのピースインデックスとして決定し、
前記第２決定手段は、決定された前記ピースインデックス及び当該ピースインデックスとの組が前記一部データ要求において指定された前記バリエーションインデックスが対応付けられている暗号化ピースについて、前記送信回数を参照して、前記未送信暗号化ピースのうち少なくとも１つを、送信対象の暗号化ピースとして決定し、
前記送信手段は、送信対象として決定された前記暗号化ピースについて、前記一部データ要求によって指定された前記データ範囲のデータを前記他の通信装置に送信する
ことを特徴とする請求項３に記載の通信装置。
【請求項９】
前記要求受信手段は、前記他の通信装置がデータの一部を取得済みである暗号化ピースに対応付けられている前記ピースインデックスを指定する一部データ要求を含む前記ピース要求を受信し、
前記第１決定手段は、前記ピース要求に前記一部データ要求が含まれる場合、前記一部データ要求によって指定された前記ピースインデックスのうち、前記優先ピース情報によって特定される前記ピースインデックスと一致するピースインデックスのうち少なくとも１つを、送信候補とする暗号化ピースのピースインデックスとして決定する第３決定手段と、決定された前記ピースインデックスを前記他の通信装置に通知する通知手段と、決定された前記ピースインデックスが対応付けられており且つデータの一部を取得済みである暗号化ピースに対応付けられているバリエーションデックスと、当該暗号化ピースの未取得のデータのデータ範囲とを前記他の通信装置から受信する範囲受信手段とを有し、
前記第２決定手段は、決定された前記ピースインデックス及び受信された前記バリエーションインデックスが対応付けられている暗号化ピースについて、前記送信回数を参照して、前記未送信暗号化ピースのうち少なくとも１つを、送信対象の暗号化ピースとして決定し、
前記送信手段は、送信対象として決定された前記暗号化ピースについて、受信された前記データ範囲のデータを前記他の通信装置に送信する
ことを特徴とする請求項３に記載の通信装置。
【請求項１０】
前記要求受信手段は、前記他の通信装置がデータの一部を取得済みである暗号化ピースに対応付けられている前記ピースインデックス及び前記バリエーションインデックスを指定すると共に、当該暗号化ピースの未取得のデータのデータ範囲を指定して、当該データを要求する一部データ要求と、前記他の通信装置がデータの全部を未取得である暗号化ピースに対応付けられている前記ピースインデックスを指定し、当該暗号化ピースを要求する未取得ピース要求とを含むピース要求を受信し、
前記第１決定手段は、前記ピース要求に前記一部データ要求及び前記未取得ピース要求が含まれる場合、前記一部データ要求によって指定された前記ピースインデックスのうち、前記優先ピース情報によって特定される前記ピースインデックスと一致するピースインデックスが存在する場合、当該ピースインデックスのうち少なくとも１つを、送信候補とする暗号化ピースのピースインデックスとして決定する第４決定手段と、前記一部データ要求によって指定された前記ピースインデックスのうち、前記優先ピース情報によって特定される前記ピースインデックスと一致するピースインデックスが存在しない場合、前記未取得ピース要求によって指定された前記ピースインデックスのうち、前記優先ピース情報によって特定される前記ピースインデックスと一致するピースインデックスのうち少なくとも１つを、送信候補とする暗号化ピースのピースインデックスとして決定する第５決定手段とを有し、
前記第２決定手段は、前記第４決定手段により前記ピースインデックスが決定された場合、当該ピースインデックス及び当該ピースインデックスとの組が前記一部データ要求において指定された前記バリエーションインデックスが対応付けられている暗号化ピースについて、前記送信回数を参照して、前記未送信暗号化ピースのうち少なくとも１つを、送信対象の暗号化ピースとして決定し、前記第５決定手段により前記ピースインデックスが決定された場合、当該ピースインデックスに対応付けられている前記複数の暗号化ピースのそれぞれについて、前記送信回数を参照して、前記未送信暗号化ピースのうち少なくとも１つを、送信対象の暗号化ピースとして決定する
ことを特徴とする請求項３に記載の通信装置。
【請求項１１】
前記優先ピースが選定されてから経過した時間に基づいて、前記優先ピースを更新するか否かを判断する第１判断手段を更に備え、
前記第１決定手段は、前記優先ピースを更新すると判断された場合、前記優先ピース情報によって特定される前記複数の暗号化ピース以外であり前記少なくとも第１ピースに対応する前記複数の暗号化ピースを、送信候補として決定する
ことを特徴とする請求項１乃至１０のいずれか一項に記載の通信装置。
【請求項１２】
接続されている他の通信装置の数を検出する検出手段と、
検出された前記他の通信装置の数が、前記優先ピースとして選定された前記複数の暗号化ピースの数より小さい場合に当該複数の暗号化ピースのうち前記未送信暗号化ピースの数と等しいか否かを判断する第２判断手段とを備え、
前記記憶制御手段は、前記第２判断手段の判断結果が肯定的である場合に、前記優先ピース情報によって特定される前記優先ピースを初期化時優先ピースとして特定する初期化時優先ピース情報を前記第２記憶手段に記憶させると共に、検出された前記他の通信装置の数を初期化時装置数として前記第２記憶手段に記憶させ、
前記第２更新手段は、前記第２判断手段の判断結果が肯定的である場合に、前記優先ピース情報を前記初期状態に更新し、
前記選定手段は、前記優先ピース情報が更新された後に検出された前記他の通信装置の数が前記初期化時装置数より大きい場合、前記初期化時優先ピース情報によって特定される前記初期化時優先ピースを前記優先ピースとして再選定し、前記優先ピース情報が更新された後に検出された前記他の通信装置の数が前記初期化時装置数以下である場合、前記初期化時優先ピース情報によって特定される前記優先ピース以外で少なくとも１つの前記第１ピースに対応する前記複数の暗号化ピースを、前記優先ピースとして新たに選定する
ことを特徴とする請求項１乃至１１のいずれか一項に記載の通信装置。
【請求項１３】
前記記憶制御手段は、前記第１ピースが暗号化された前記複数の暗号化ピースの全てを送信済であるか否かを示す送出済フラグを前記ピースインデックスに対応付けて前記第２記憶手段に記憶させ、
送信候補とする暗号化ピースの前記ピースインデックスが前記第１決定手段により決定されない場合に、前記送出済フラグを照会して、前記複数の暗号化ピースの全てを送信済であることを示す前記送出済フラグが対応付けられている前記ピースインデックスのうち少なくとも１つを、送信候補とする暗号化ピースのピースインデックスとして決定する送出済フラグ照会手段を更に備え、
前記第２決定手段は、送信候補とする暗号化ピースのピースインデックスが前記送出済フラグ照会手段により決定された場合、当該ピースインデックスが対応付けられている暗号化ピースのうち少なくとも１つを、送信対象の暗号化ピースとして決定する
ことを特徴とする請求項３に記載の通信装置。
【請求項１４】
前記送出済フラグ照会手段は、送信候補とする暗号化ピースの前記ピースインデックスが前記第１決定手段により決定されない場合に、前記送出済フラグを照会して、前記複数の暗号化ピースの全てを送信済であることを示す前記送出済フラグが対応付けられている前記ピースインデックスに対して優先順位を設定し、当該優先順位に応じて、送信候補とする暗号化ピースのピースインデックスを決定する
ことを特徴とする請求項１２に記載の通信装置。
【請求項１５】
前記記憶制御手段は、前記優先ピースとして選定された前記複数の暗号化ピースのうち前記未送信暗号化ピースが存在する場合に新たな前記優先ピースが選定される場合、新たに選定される前の前記優先ピースに対応する前記ピースインデックスに対して、前記未送信暗号化ピースの存在することを示す未送出フラグを対応付けて前記第２記憶手段に記憶させ、
前記第１決定手段は、前記優先ピース情報及び前記未送出フラグのうち少なくとも一方を用いて、送信候補とする暗号化ピースのピースインデックスを決定する
ことを特徴とする請求項３に記載の通信装置。
【請求項１６】
前記暗号化ピースを他の通信装置から受信するピース受信手段と、
受信された前記暗号化ピースを前記第１記憶手段に記憶させるピース記憶制御手段とを更に備る
ことを特徴とする請求項１乃至１５のいずれか一項に記載の通信装置。
【請求項１７】
前記ピース要求が他の通信装置から受信された場合、前記ピース受信手段を介して当該他の通信装置から少なくとも１つの暗号化ピースの少なくとも一部を受信しているか否かを判断する受信判断手段と、
前記受信判断手段の判断の結果に応じて、前記暗号化ピースを前記他の通信装置に送信するか否かを決定する送信決定手段とを備え、
前記第１決定手段は、前記暗号化ピースを前記他の通信装置に送信すると決定された場合に、前記優先ピース情報を参照して、前記優先ピースとして特定される前記複数の暗号化ピースを送信候補として決定する
ことを特徴とする請求項１６に記載の通信装置。
【請求項１８】
前記第１記憶手段は、コンテンツを構成する全ての複数のピースのそれぞれについて、少なくとも１つ以上の暗号鍵で暗号化された暗号化ピースを各々記憶する
ことを特徴とする請求項１乃至１７のいずれか一項に記載の通信装置。
【請求項１９】
前記他の通信装置がデータの一部を取得済みである継続暗号化ピースに対応付けられている前記ピースインデックス及びバリエーションインデックスと、前記一部のデータ量とを、当該他の通信装置を識別するための識別情報と対応付けてセッション情報として記憶する第３記憶手段と、
前記暗号化ピースに対応付けられている前記ピースインデックス及びバリエーションインデックスと、前記継続暗号化ピースについて前記一部を除いたデータのデータ開始位置と、前記一部を除いたデータのうち取得を要求するデータの第１取得希望データ量とを指定すると共に前記識別情報を含む前記ピース要求である継続ピース要求を前記要求受信手段が前記他の通信装置から受信した場合、前記セッション情報と、前記継続ピース要求との整合性を確認する確認手段と、
前記セッション情報を更新する第３更新手段とを更に備え、
前記送信手段は、前記確認手段の確認結果に応じて、前記継続暗号化ピースについて前記データ開始位置から前記第１取得希望データ量を有するデータを前記他の通信装置に送信し、
前記第３更新手段は、送信された前記データに基づいて、前記セッション情報を更新する
ことを特徴とする請求項３に記載の通信装置。
【請求項２０】
前記第３記憶手段は、前記他の通信装置がデータの全部を未取得である新規暗号化ピースを要求すると共に前記識別情報を含む前記ピース要求である新規ピース要求を受け入れるか否かを示す新規受入フラグを前記識別情報と対応付けて更に記憶し、
前記第３更新手段は、前記識別情報に対応する前記セッション情報の更新に伴い、前記継続暗号化ピースの前記一部のデータ量が当該継続暗号化ピースの全部のデータ量に達した場合、前記新規ピース要求を受け入れることを示すよう当該識別情報に対応する前記新規受入フラグを更新する
ことを特徴とする請求項１９に記載の通信装置。
【請求項２１】
前記要求受信手段は、前記新規暗号化ピースについて取得を要求する第２取得希望データ量を含む前記新規ピース要求を受信し、
前記第１決定手段は、前記新規ピース要求が受信された場合且つ当該新規ピース要求に含まれる前記識別情報に対応する前記受入フラグが前記新規ピース要求を受け入れることを示す場合、前記優先ピース情報によって前記優先ピースとして特定される前記複数の暗号化ピースを送信候補として決定し、
前記送信手段は、前記新規暗号化ピースについて前記第２取得希望データ量を有するデータを前記他の通信装置に送信する
ことを特徴とする請求項２０に記載の通信装置。
【請求項２２】
コンテンツの一部である複数のピースの送受信を行う第１通信装置及び第２通信装置がネットワークを介して接続され、
第１通信装置及び第２通信装置は各々、
前記複数のピースを各々暗号鍵で暗号化することによって得られる複数の暗号化ピースを記憶する手段であって、前記複数のピースのうち少なくとも１つの第１ピースを複数の異なる暗号鍵で暗号化することによって得られる複数の暗号化ピースを記憶する第１記憶手段と、
前記第１記憶手段に記憶された前記暗号化ピースのそれぞれの送信回数を記憶する第２記憶手段と、
前記第１ピースが暗号化された前記複数の暗号化ピースのうち前記送信回数が０回である未送信暗号化ピースの個数に基づいて、前記第１ピースのうち少なくとも１つの第１ピースに対応する前記複数の暗号化ピースを優先ピースとして選定する選定手段と、
選定された優先ピースを特定する優先ピース情報を前記第２記憶手段に記憶させる記憶制御手段と、
暗号化ピースを要求するピース要求を他の通信装置から受信する要求受信手段と、
前記ピース要求が受信された場合、前記優先ピース情報によって前記優先ピースとして特定される前記複数の暗号化ピースを送信候補として決定する第１決定手段と、
送信候補として決定された前記複数の暗号化ピースのうち少なくとも１つの前記未送信暗号化ピースを送信対象として決定する第２決定手段と、
送信対象として決定された前記暗号化ピースを前記他の通信装置に送信する送信手段と、
前記送信手段によって送信された暗号化ピースに従い、前記第２記憶手段に記憶された前記暗号化ピースの送信回数を更新する第１更新手段と、
前記優先ピース情報によって優先ピースとして特定される複数の暗号化ピースのうち前記未送信暗号化ピースが存在しなくなった場合、前記優先ピース情報によって優先ピースが特定されない初期状態になるよう当該優先ピース情報を前記第２記憶手段において更新する第２更新手段と、
前記暗号化ピースを他の通信装置から受信するピース受信手段と、
受信された前記暗号化ピースを前記第１記憶手段に記憶させるピース記憶制御手段とを備え、
前記第１通信装置の備える前記送信手段が、送信対象として決定された前記暗号化ピースを前記第２通信装置に送信し、
前記第２通信装置の備える前記ピース受信手段が、前記第１通信装置の備える前記送信手段から送信された前記暗号化ピースを受信する
ことを特徴とする通信システム。
【請求項２３】
前記第１通信装置は、
前記ピース要求が前記第２通信装置から受信された場合、前記ピース受信手段を介して当該第２通信装置から少なくとも１つの暗号化ピースを受信しているか否かを判断する受信判断手段と、
前記受信判断手段の判断の結果に応じて、前記暗号化ピースを前記第２通信装置に送信するか否かを決定する送信決定手段とを更に備え、
前記第１通信装置の備える前記第１決定手段は、前記暗号化ピースを前記第２通信装置に送信すると決定された場合に、前記優先ピース情報を参照して、前記優先ピースとして特定される前記複数の暗号化ピースを送信候補として決定する
ことを特徴とする請求項２２に記載の通信システム。
【請求項２４】
コンテンツの一部である複数のピースの送信を行う通信装置であって、前記複数のピースを各々暗号鍵で暗号化することによって得られる複数の暗号化ピースを記憶する手段であって、前記複数のピースのうち少なくとも１つの第１ピースを複数の異なる暗号鍵で暗号化することによって得られる複数の暗号化ピースを記憶する第１記憶手段と、前記第１記憶手段に記憶された前記暗号化ピースのそれぞれの送信回数を記憶する第２記憶手段とを備える通信装置において実現される送信方法であって、
前記第１ピースが暗号化された前記複数の暗号化ピースのうち前記送信回数が０回である未送信暗号化ピースの個数に基づいて、前記第１ピースのうち少なくとも１つの第１ピースに対応する前記複数の暗号化ピースを優先ピースとして選定する選定ステップと、
選定された優先ピースを特定する優先ピース情報を前記第２記憶手段に記憶させる記憶制御ステップと、
暗号化ピースを要求するピース要求を他の通信装置から受信する要求受信ステップと、
前記ピース要求が受信された場合、前記優先ピース情報によって前記優先ピースとして特定される前記複数の暗号化ピースを送信候補として決定する第１決定ステップと、
送信候補として決定された前記複数の暗号化ピースのうち少なくとも１つの前記未送信暗号化ピースを送信対象として決定する第２決定ステップと、
送信対象として決定された前記暗号化ピースを前記他の通信装置に送信する送信ステップと、
前記送信ステップで送信された暗号化ピースに従い、前記第２記憶手段に記憶された前記暗号化ピースの送信回数を更新する第１更新ステップと、
前記優先ピース情報によって優先ピースとして特定される複数の暗号化ピースのうち前記未送信暗号化ピースが存在しなくなった場合、前記優先ピース情報によって優先ピースが特定されない初期状態になるよう当該優先ピース情報を前記第２記憶手段において更新する第２更新ステップとを含む
ことを特徴とする送信方法。
【請求項２５】
コンテンツの一部である複数のピースの送信を行う通信装置であって、前記複数のピースを各々暗号鍵で暗号化することによって得られる複数の暗号化ピースを記憶する手段であって、前記複数のピースのうち少なくとも１つの第１ピースを複数の異なる暗号鍵で暗号化することによって得られる複数の暗号化ピースを記憶する第１記憶手段と、前記第１記憶手段に記憶された前記暗号化ピースのそれぞれの送信回数を記憶する第２記憶手段とを備える通信装置の有するコンピュータに実行させるための送信プログラムであって、
前記第１ピースが暗号化された前記複数の暗号化ピースのうち前記送信回数が０回である未送信暗号化ピースの個数に基づいて、前記第１ピースのうち少なくとも１つの第１ピースに対応する前記複数の暗号化ピースを優先ピースとして選定する選定ステップと、
選定された優先ピースを特定する優先ピース情報を前記第２記憶手段に記憶させる記憶制御ステップと、
暗号化ピースを要求するピース要求を他の通信装置から受信する要求受信ステップと、
前記ピース要求が受信された場合、前記優先ピース情報を参照して、前記優先ピースとして特定される前記複数の暗号化ピースを送信候補として決定する第１決定ステップと、
送信候補として決定された前記複数の暗号化ピースのうち少なくとも１つの前記未送信暗号化ピースを送信対象として決定する第２決定ステップと、
送信対象として決定された前記暗号化ピースを前記他の通信装置に送信する送信ステップと、
前記送信ステップで送信された暗号化ピースに従い、前記第２記憶手段に記憶された前記暗号化ピースの送信回数を更新する第１更新ステップと、
前記優先ピース情報によって優先ピースとして特定される複数の暗号化ピースのうち前記未送信暗号化ピースが存在しなくなった場合、前記優先ピース情報によって優先ピースが特定されない初期状態になるよう当該優先ピース情報を前記第２記憶手段において更新する第２更新ステップとを含む
ことを特徴とする送信プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、暗号鍵を用いて暗号化された暗号化コンテンツを、他の通信装置に送信する通信装置、システム、送信方法及びプログラムに関する。
【背景技術】
【０００２】
一般に、コンテンツを配信するシステムには、「単一サーバ型」と「分散サーバ型」とがある。単一サーバ型のシステムでは、例えば、１つのコンテンツサーバと、ライセンスサーバと、クライアントとがネットワークを介して接続され、コンテンツサーバからコンテンツが各クライアントに配信される。配信されるコンテンツは暗号化されており、この暗号化に係る鍵情報をライセンスサーバが有している。コンテンツサーバでは、コンテンツは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)仕様に従って暗号化したものもコンテンツである。ここでは、コンテンツ全体をＣと表すものとする。Ｃは平文であっても暗号化されていても構わない。図２は、コンテンツが複数のピースに分割された状態を模式的に示す図である。例えば、コンテンツＣは、ある１つのコンテンツをＮ（Ｎ＞１）個のピースＣ１〜ＣＮに分割される。各ピースＣ１，Ｃ２，・・・ＣＮのデータ長は全て同一であっても良いし、そうでなくても良い。これらのＮ個の各ピースＣ１〜ＣＮについては、各々異なる暗号鍵で暗号化される。このとき、Ｎ個のうちａ個のピースについては、同一のピースに対して、各々異なるｍ（ｍ＞１）個の暗号鍵で暗号化される。残りの（Ｎ-ａ）個のピースについては、同一のピースに対して１つの暗号鍵（第１暗号鍵）で暗号化される。即ち、ａ個の各ピースについては、同一のピースがｍ個の異なる暗号鍵で各々暗号化されてｍ個の異なるピース（暗号化ピース）が生成される。（Ｎ-ａ）個の各ピースについては、各々１つの暗号鍵で暗号化して、１つのピースに対して１つの暗号化ピースが生成される。図３は、各暗号化ピースを模式的に示す図である。このａ個の各ピースに各々対応して、ｍ個の暗号化ピースの中から各々１つ選択される暗号化ピースの組み合わせを異ならせることにより、Ｎ個の暗号化ピースから構成される暗号化コンテンツ全体を個別化することができる。
【００２２】
次に、リーチャ５０と、トラッカ５１と、シーダ５２と、鍵サーバ５３との各装置のハードウェア構成について説明する。各装置は各々、装置全体を制御するＣＰＵ（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）
【００２８】
尚、以降、各ピースＣ１〜ＣＮを区別するためのインデックスjについては、ピースインデックスと表記し、復号鍵の数に応じてバリエーションが生じるインデックスiについては、バリエーションインデックスと表記し、これらの組(i,j)を単にインデックスと表記する。また、ピースインデックスjに対応するピースについて、相異なる２つ以上の暗号鍵で各々暗号化された暗号化ピースが存在する場合これらの集合を暗号化ピース列jと適宜表記する。
【００２９】
初期シーダであるシーダ５２Ａは、コンテンツを構成する各ピースに各々対応する各暗号化ピースについて、同一のピースに対して複数の暗号鍵により各々暗号化されて生成された暗号化ピースの全てを記憶している。図４は、シーダ５２Ａが記憶している各暗号化ピースを例示する図である。同図においては、Ｎ個のうちa個（1<a<N）のピースについて、同一のピースに対して複数の異なる暗号鍵で各々暗号化されていることが示されている。同図においては、同一のピースの暗号化に用いられる暗号鍵の個数は、ピース毎に異なっている。ピースＣ１に対する暗号鍵の個数はｍ個であり、ピースＣ３に対する暗号鍵の個数は２個である。但し、本実施の形態においては、同一のピースの暗号化に用いられる暗号鍵の個数はピース毎に同じであっても良い。ピース処理装置では、このように、Ｎ個のうちa個（1<a<N）のピースについて、同一のピースに対して複数の異なる暗号鍵で各々暗号化することにより、例えば、重要度の高いほど暗号鍵の数を増やすようにすることができる。
【００３０】
尚、本実施の形態においては、これに限らず、例えば、図５に示されるように、「a=N」の場合、即ち、Ｎ個全てのピースについて、同一のピースに対してｍ個の異なる暗号鍵で各々暗号化されていても良い。このような構成によれば、暗号化ピースのシーケンスのバリエーションを多くすることができる。また、図６に示されるように、「a=1」の場合、即ち、Ｎ個のうち1個のピースのみ、ｍ個の異なる暗号鍵で暗号化されていても良い。このような構成によれば、配信効率を向上させることができる。
【００３１】
尚、初期シーダであるシーダ５２Ａ以外のシーダ５２Ｂ，５２Ｃは、暗号化ピース列jに属する暗号化ピースとして存在するものの全てを必ずしも保持しているとは限らない。シーダ５２Ｂ，５２Ｃが、ある時点で、暗号化ピース列jに属する暗号化ピースとして存在する一部の暗号化ピースしか保持していない場合、当該一部の暗号化ピースを処理対象として各種処理を行う。但し、ここでは、少なくとも１つの暗号化ピース列jについては、異なる２つ以上の暗号鍵で各々暗号化された暗号化ピースをシーダ５２は保持しているものとする。なお、シーダ５２Ａを含むシーダ５２（送信側）や、暗号化ピースを送信する送信側となった場合のリーチャ５０との間、即ち、送信側間では、少なくともピースインデックスは共有されているものとする。また、後述するように、暗号化ピースを受信する受信側からバリエーションインデックスの指定がなされる場合には、バリエーションインデックスも送信側間では共有されているものとする。これは、同一のTorrent Fileを共有するなどしていたりすれば実現可能である。このようなシーダ５２Ｂ，５２Ｃは、他のシータ５２やリーチャ５０から暗号化ピースを受信することにより、暗号化ピース列jに属する暗号化ピースとして存在するものの全てを保持可能である。
【００３２】
次に、シーダ５２のＣＰＵが記憶装置や外部記憶装置に記憶された各種プログラムを実行することにより実現される各種機能について説明する。図７は、シーダ５２の機能的構成を例示する図である。シーダ５２は、ピース情報送信部５２０と、ピース要求受信部５２１と、優先ピースインデックス選定部５２２と、ピースインデックス決定部５２３と、バリエーションインデックス決定部５２４と、送信状況テーブル更新部５２５と、ピース送信部５２６とを有する。また、シーダ５２は、図示しない送信状況テーブルを有する。送信状況テーブルとは、例えば外部記憶装置に記憶されるデータテーブルである。
【００３３】
ピース情報送信部５２０は、リーチャ５０からのアクセスにより、当該シーダ５２が記憶している暗号化ピースのピースインデックスを示すピース情報をリーチャ５０に送信する。図８は、ピース情報のデータ構成を例示する図である。同図においては、ピースインデックスのみが示されており、ピースＣ１９，Ｃ２９，Ｃ１００，Ｃ１０１に対応する暗号化ピースをシーダ５２が有することが示されている。このような構成によれば、シーダ５２は自身の保持する暗号化ピース（i，j）のバリエーションインデックスiをリーチャ５０に隠すことができる。このような構成においてもリーチャ５０は、Torrent Fileの情報や暗号化ピースの受信時にヘッダ情報として記載されたバリエーションインデックスの値iを参照することにより、自身が取得した暗号化ピースのシーケンスを判断することは可能である。しかし、シーダ５２は、ピースインデックスjのみならず、ピースインデックスjとバリエーションインデックスiとの組（i,j）を示すピース情報をリーチャ５０に送信するようにしても良い。
【００３４】
ピース要求受信部５２１は、上述のピース情報に基づいて暗号化ピースを要求するリーチャ５０からのピース要求を受信する。
【００３５】
送信状況テーブル更新部５２５は、シーダ５２が記憶している暗号化ピースのそれぞれについて、それが送信された後にその送信回数を計数し、送信回数を各暗号化ピースと対応付けて送信状況テーブルに記録する。図９は、送信状況テーブルのデータ構成を例示する図である。同図に示される送信状況テーブルにおいては、コンテンツを構成する全てのピースのピースインデックスと、当該ピースインデックスに対して存在する全てのバリエーションインデックスとが示されており、このうち、シーダ５２が記憶している暗号化ピースのインデックス(i,j)に対応して送信回数が各々記録される。また、送信状況テーブルにおいては、各ピースインデックスに対して、優先ピースインデックスフラグが対応付けられている。優先ピースインデックスフラグとは、以下に説明する優先ピースインデックス選定部５２２が優先ピースインデックスとして選定したピースインデックスを特定するものであり、優先ピース情報に相当する。優先ピースインデックスフラグには、初期値として‘０’が設定されている。これが‘１’に設定されたピースインデックスは、優先ピースインデックスとして選定されたことを示す。また、暗号化ピースが送信された後優先ピースインデックスの初期化条件が成立した場合に、送信状況テーブル更新部５２５が、全てのピースインデックスに対する優先ピースインデックスフラグの値を‘０’に設定することにより優先ピースインデックスを初期化する。即ち、優先ピースインデックスの初期化条件が成立した場合、送信状況テーブル更新部５２５は、優先ピースインデックスフラグによって優先ピースインデックスが特定されない初期状態にする。優先ピースインデックスの初期化条件とは、優先ピースインデックスとして選定されたピースインデックスに対応する暗号化ピース列に属する暗号化ピースのうち未だ送信していない、即ち、送信回数が０回である暗号化ピース（未送信暗号化ピース）が存在しなくなったことである。ここで、送信回数が０回であることはこれまでの送信履歴が０回ということではなく、前回の配信からある一定程度の時間が経過していたり、配信側のポリシーによって０回に設定されて配信が開始したりすることを意味している。例えばＰ２ＰネットワークＮＴで流通が確認されないなどの判断に基づいて設定すればよい。
【００３６】
優先ピースインデックス選定部５２２は、上述の送信状況テーブルを参照して、シーダ５２が記憶している暗号化ピースのうち未送信暗号化ピースの個数、即ち、送信回数が‘０’の暗号化ピースの個数を暗号化ピース列毎に計数し、未送信暗号化ピースの個数が最も多い暗号化ピース列のピースインデックスjを優先ピースインデックスとして選定する。即ち、優先ピースインデックスとして選定されたピースインデックスjの暗号化ピース列に含まれる複数の暗号化ピースが優先ピースとして選定される。優先ピースとは、ピースが異なる暗号鍵で暗号化された複数の暗号化ピースのうち、優先的に配信されるピースのことである。そして、優先ピースインデックス選定部５２２は、送信状況テーブルにおいて、優先ピースインデックスとして選定したピースインデックスに対応する優先ピースインデックスフラグを‘１’に設定する。尚、優先ピースインデックスの個数は、複数であっても良く、この場合、優先ピースインデックス選定部５２２は、未送信の暗号化ピースの個数が多い順に優先ピースインデックスを選定する。
【００３７】
ピースインデックス決定部５２３は、ピース要求受信部５２１がピース要求を受信した場合、送信状況テーブルの優先ピースインデックスフラグを参照して、優先ピースインデックスとして選定されたピースインデックスjが存在するか否かを判断し、当該判断結果が肯定的である場合に、送信候補とする暗号化ピースのピースインデックスjを決定する。バリエーションインデックス決定部５２４は、ピースインデックス決定部５２３が決定したピースインデックスjに対応する暗号化ピース列に属し自身が保持している暗号化ピースのバリエーションインデックスの中から、送信対象とする暗号化ピースのバリエーションインデックスiを決定する。この結果、ピースインデックスj及びバリエーションiとの組からなるインデックス(i,j)が決定され、当該インデックス(i,j)に対応する暗号化ピースが送信対象として決定されることになる。
【００３８】
ピース送信部５２６は、ピースインデックス決定部５２３が決定したピースインデックスjと、バリエーションインデックス決定部５２４が決定したバリエーションインデックスiとの組からなるインデックス(i,j)に対応する暗号化ピースをリーチャ５０に送信する。
【００３９】
＜リーチャ５０の構成＞
次に、上述したハードウェア構成において、リーチャ５０のＣＰＵが記憶装置や外部記憶装置に記憶された各種プログラムを実行することにより実現される各種機能について説明する。図１０は、リーチャ５０の機能的構成を例示する図である。リーチャ５０は、コンテンツ取得部５００と、鍵束要求部５０１と、鍵束取得部５０２と、コンテンツ復号部５０３とを有する。これら各部の実体は、ＣＰＵのプログラム実行時にＲＡＭなどの記憶装置上に生成されるものである。
【００４０】
コンテンツ取得部５００は、Ｐ２ＰネットワークＮＴを介して、暗号化コンテンツを構成する各暗号化ピースをシーダ５２の少なくとも１つから受信する。具体的には、コンテンツ取得部５００は、まず、販売サーバ５４から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に含まれるトラッカ情報に含まれるトラッカ接続先情報を用いてトラッカ５１にアクセスすると（ステップＳ２）、トラッカ５１はリーチャ５０に対して、ノード情報を送信する（ステップＳ３）。リーチャ５０は、ノード情報を受信すると（ステップＳ４）、ノード情報を用いて、例えばシーダ５２Ａ〜５２Ｃの少なくとも１つにアクセスする（ステップＳ５）。シーダ５２は、リーチャ５０からアクセスされると、図８に示したように、自身の保持する暗号化ピースのピースインデックスを示すピース情報をリーチャ５０へ送信する（ステップＳ６）。リーチャ５０は、ピース情報を受信すると（ステップＳ７）、取得したいピースのピースインデックスが少なくとも示されているピース情報を送信したシーダ５２にアクセスする(ステップＳ８)。そして当該シーダ５２に対して暗号化ピースを要求するピース要求をリーチャ５０は送信する。一方、シーダ５２は、優先ピースインデックス選定処理を行い、リーチャ５０からピース要求を受信した場合には、当該ピース要求に応じて、暗号化ピース送信処理を行う（ステップＳ９）。
【００５６】
ここで、シーダ５２が行う優先ピースインデックス選定処理及び暗号化ピース送信処理について図１５を用いて説明する。シーダ５２は、まず、優先ピースインデックス選定処理を行う（ステップＳ２０）。図１６は優先ピースインデックス選定処理の詳細な手順を示すフローチャートである。シーダ５２は、送信状況テーブルを参照して、優先ピースインデックスが初期状態であるか否か、即ち、優先ピースインデックスフラグ‘１’が設定されているものがないか否かを判断する（ステップＳ１００）。当該判断結果が否定的である場合、即ち、優先ピースインデックスが初期状態でない場合、シーダ５２は、既に設定されている優先ピースインデックスフラグを利用するので、優先ピースインデックス選定処理を終了する。当該判断結果が肯定的である場合、即ち、優先ピースインデックスが初期状態である場合、シーダ５２は、送信状況テーブルの各ピースインデックスjの暗号化ピース列jのそれぞれの送信回数を参照し（ステップＳ１０１）、暗号化ピース列毎に当該暗号化ピース列に属する暗号化ピースのうち未送信暗号化ピースの個数を計数する。そして、シーダ５２は、暗号化ピース列毎に計数した未送信暗号化ピースの個数が最も多いピースインデックスを検索する（ステップＳ１０２）。なお、この際に未送信暗号化ピースがある暗号化ピース列が存在しない場合には、現段階で自身が保持する全ての暗号化ピースをシーダ５２が送信していることを意味する。この場合、シーダ５２は、本方式によらずにピース要求に応じて暗号化ピースをリーチャ５０に提供したり、暗号化ピースの提供を止めたりしても良い。また、その後、何らかの経路で未送信の暗号化ピースが追加された場合には、シーダ５２は、その暗号化ピースのピースインデックスを優先ピースインデックスとして選定して暗号化ピースの提供を再開しても良い。
【００５７】
ステップＳ１０２の後、シーダ５２は、検索して得られたピースインデックスが唯一であるか否かを判断し（ステップＳ１０３）、当該判断結果が肯定的である場合、このピースインデックスを優先ピースインデックスとして選定する（ステップＳ１０５）。そして、シーダ５２は、送信状況テーブルにおいて、優先ピースインデックスとして選定したピースインデックスに対応する優先ピースインデックスフラグを‘１’に設定する。ステップＳ１０３の判断結果が否定的である場合、未送信暗号化ピースの個数が同数であるピースが複数存在するということであり、優先ピースインデックスの候補が複数存在するということである。この場合、シーダ５２は、それらのピースインデックスの中から一つのピースインデックスをランダムに選択し（ステップＳ１０４）、これを優先ピースインデックスとして選定する。そして、シーダ５２は、上述と同様にして送信状況テーブルにおける優先ピースインデックスフラグの値を設定する（ステップＳ１０５）。
【００５８】
図１５に戻り、その後、シーダ５２は、リーチャ５０からピース要求を受信すると（ステップＳ２１：ＹＥＳ）、暗号化ピース送信処理を行うことになる。暗号化ピース送信処理では、シーダ５２は、まず、ピースインデックス決定処理を行う（ステップＳ２２）。ここでは、シーダ５２は、優先ピースインデックス、即ち、送信状況テーブルにおいて優先ピースインデックスフラグが‘１’が設定されているピースインデックスを、リーチャ５０に送信する候補とする暗号化ピースのピースインデックスとして決定する。
【００５９】
そして、シーダ５２は、送信候補とする暗号化ピースのピースインデックスを決定できたか否かを判断して（ステップＳ２３）、当該判断結果が肯定的である場合、次いで、バリエーションインデックス決定処理を行う（ステップＳ２４）。ステップＳ２３の判断結果が否定的である場合には、シーダ５２は、暗号化ピースを送信しない旨を示す通知メッセージをリーチャ５０に送信して、新たなピース要求を待ち受ける。尚、ここで、シーダ５２はリーチャ５０に通知メッセージを送信しなくても良い。この場合、シーダ５２の処理負荷を軽減することができる。
【００６０】
図１７はバリエーションインデックス決定処理の手順を示すフローチャートである。シーダ５２は、まず、上述のピースインデックス決定処理で決定したピースインデックスを取得する（ステップＳ５００）。そして、シーダ５２は、そのピースインデックスをキーとして送信状況テーブルを参照して（ステップＳ５０１）、当該ピースインデックスの暗号化ピース列に未送信暗号化ピースが存在するか否かを判断する（ステップＳ５０２）。当該判断結果が否定的である場合には、シーダ５２は、バリエーションインデックスを決定せずに、バリエーションインデックス決定処理を終了する。尚、ステップＳ５０２の判断は、シーダ５２が暗号化ピース送信処理を多数のリーチャに対して並行して行う場合などにも未送信暗号化ピースが存在するか否かの判断を正確にするために行っている。しかし、この判断は、暗号化ピース送信処理を多数のリーチャに対して並行して行わない場合には省略しても良い。
【００６１】
さて、ステップＳ５０２の判断結果が肯定的である場合には、次いで、シーダ５２は、ステップＳ５００で取得したピースインデックスの暗号化ピース列における未送信暗号化ピースの個数を確認する（ステップＳ５０３）。この未送信暗号化ピースの個数が１つである場合、即ち、バリエーションインデックスが唯一に決定される場合、シーダ５２は、当該未送信暗号化ピースのバリエーションインデックスを、送信対象の暗号化ピースのバリエーションインデックスとして決定する（ステップＳ５０５）。そして、シーダ５２は、当該バリエーションインデックス決定処理を終了する。また、ステップＳ５０３で、未送信暗号化ピースの個数が複数ある場合、当該未送信暗号化ピースのバリエーションインデックスの中から１つのバリエーションインデックスをランダムに選択し（ステップＳ５０４）、当該バリエーションインデックスを、送信対象の暗号化ピースのバリエーションインデックスとして決定する（ステップＳ５０５）。そして、シーダ５２は、当該バリエーションインデックス決定処理を終了する。なお、バリエーションインデックスの候補が複数ある場合その中から１つのバリエーションインデックスを、シーダ５２は、ランダムに選択するのではなく、候補となるバリエーションインデックスに対応する暗号化ピースのＰ２ＰネットワークＮＴでの流通状況などに基づいて選択するようにしても良い。
【００６２】
図１５に戻り、シーダ５２は、ステップＳ２２で決定したピースインデックスjと、ステップＳ２４で決定したバリエーションインデックスiとの組からなるインデックス(i,j)に対応する暗号化ピースを外部記憶装置に実際に記憶しているか否かを判断する(ステップＳ２５)。そして、当該判断結果が肯定的である場合、シーダ５２は、当該暗号化ピースを外部記憶装置から読み出してこれをリーチャ５０に送信する（ステップＳ２６）。ステップＳ２５における判断結果が否定的である場合、シーダ５２は、暗号化ピースを送信しない旨を示す通知メッセージをリーチャ５０に送信して、新たなピース要求を待ち受ける。尚、ここで、シーダ５２はリーチャ５０に通知メッセージを送信しなくても良い。
【００６３】
また、ステップＳ２６の後、シーダ５２は、送信した暗号化ピースに応じて、送信状況テーブル更新処理を行う（ステップＳ２７）。図１８は送信状況テーブル更新処理の手順を示すフローチャートである。シーダ５２は、送信した暗号化ピースのピースインデックスj及びバリエーションインデックスiを取得して（ステップＳ８００）、送信状況テーブルにおいて、当該インデックス(i,j)に対応する送信回数を１つ増やす（ステップＳ８０１）。次いで、シーダ５２は、優先ピースインデックスの初期化条件が成立するか否かを判断する。具体的には、シーダ５２は、優先ピースインデックスに対応する未送信暗号化ピースが存在するか否か、即ち、優先ピースインデックスフラグが‘１’に設定されているピースインデックスの暗号化ピース列において送信回数が‘０’の暗号化ピースが存在するか否かを判断する（ステップＳ８０２）。当該判断結果が肯定的である場合、シーダ５２は、送信状況テーブル更新処理を終了する。ステップＳ８０２の判断結果が否定的である場合、即ち、優先ピースインデックスに対応する未送信暗号化ピースが存在しない場合、シーダ５２は、送信状況テーブルにおいて全てのピースインデックスに対応付けられてる優先ピースインデックスフラグの値を‘０’に設定することにより優先ピースインデックスを初期化する（ステップＳ８０３）。そして、シーダ５２は、送信状況テーブル更新処理を終了する。
【００６４】
一方、リーチャ５０は、シーダ５２から暗号化ピースを受信すると、コンテンツを構成する全てのピースＣ１〜ＣＮに各々対応する暗号化ピースが取得できていない場合には、次いで、他のシーダ５２（例えばシーダ５３Ｃ）にアクセスする。そして、当該他のシーダ５３Ｃからピース情報をリーチャ５０は取得する。そして、リーチャ５０は、上述と同様にして、ピース情報を用いて他のシーダ５２にアクセスして、当該暗号化ピースの取得を試みる。リーチャ５０は、このような処理を繰り返して、各暗号化ピースから構成される暗号化コンテンツ｛E( K( i1, 1 ) )[ C1 ], E( K( i2, 2 ) )[ C2 ], …, E( K( iN, N ))[ CN ]｝を得る。また、リーチャ５０は、特定のシーダ５２や他のリーチャ５０などの通信相手から暗号化ピースを受信できない場合には、他の通信相手に同じ暗号化ピースを要求したり、同じ通信相手に違う暗号化ピースを要求したりしてもよい。
【００６５】
リーチャ５０は、コンテンツを構成する各ピースに各々対応する暗号化ピースであって暗号化コンテンツを構成する全ての暗号化ピースを取得すると、各暗号化ピースを各々復号するための各復号鍵を含む鍵束を要求する要求メッセージを鍵サーバ５３に送信する（ステップＳ１０）。この要求メッセージには、各復号鍵に対応するシーケンスを示すインデックス情報｛( 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の生成者又は信頼できる第三者（例えば、コンテンツ製作者）がディジタル署名を付加しても良い。この場合、リーチャ５０は、受信した各暗号化ピースの完全性に加えて正当性も確認することができる。
【００７６】
このような構成においては、更に、シーダ５２は、ハッシュ値を含むピース情報をリーチャ５０に送信するようにしても良い。図２１は、ハッシュ値を含むインデックス情報を例示する図である。この場合も、リーチャ５０は、ハッシュ値を用いて、受信した各暗号化ピースの完全性を確認することができる。
【００７７】
また、ファイル情報は、全てのインデックス（上記の例では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 )をシーダ５２はリーチャ５０に送信しても良い。
【００８３】
＜変形例６＞
上述の実施の形態においては、リーチャ５０は、暗号化ピースをシーダ５２から受信するようにしたが、これに限らず、他のリーチャ５０から暗号化ピースを取得するようにしても良い。また、鍵サーバ５３や他のサーバが、暗号化ピースを送信する上述のシーダ５２と同様の機能を有するように構成し、これからリーチャ５０は暗号化ピースを取得するように構成しても良い。
【００８４】
＜変形例７＞
上述の実施の形態においては、各ピースＣ１〜ＣＮを区別するためのインデックスjをピースインデックスとして取り扱ったが、コンテンツを構成するピースの順序と暗号化ピースの順序とは必ずしも同じでなくても良い。この場合、暗号化ピースを、コンテンツを構成するピースの順序に並び替えた場合の順序をピースインデックスとして取り扱えば良い。
【００８５】
＜変形例８＞
上述の送信状況テーブルにおいては、優先ピースインデックスを指し示すものとして、優先インデックスフラグを用いたが、これに限らず、優先ピースインデックスとして選定したピースインデックスの値自体を送信状況テーブルに記録するようにしても良い。
【００８６】
＜変形例９＞
上述のステップＳ２０の優先ピースインデックス選定処理においては、優先ピースインデックスの候補となるピースインデックスが複数存在した場合は、シーダ５２は、その中から１つをランダムに選択するとした。しかし、これに限らず、例えば、複数の候補の各ピースインデックスに対応する各暗号化ピース列に属する暗号化ピースのバリエーションインデックスの最大値が大きい程優先順位が高くなるように設定し、優先順位が最も高いピースインデックスをシーダ５２は選択して、これを優先ピースインデックスとして選定するようにしても良い。このような構成によれば、同一のピースに対する暗号化ピースのバリエーションの数を重要度に応じて増やすという構成とした場合に、重要度が高い暗号化ピース程優先して送信することが可能となる。このため、鍵の漏洩による影響を限定することができる。
【００８７】
又は、複数の候補のピースインデックスの値が小さい程優先順位が高くなるように設定し、優先順位が最も高いピースインデックスを優先ピースインデックスとして選定するようにしても良い。このような構成によれば、シーダ５２は、コンテンツの先頭のピースから順にそれに対応する暗号化ピースを送信することが可能となる。例えば、ピースインデックスの順序が、コンテンツを構成するピースの順序（再生順序）と同じであるとし、受信側のリーチャ５０が暗号化ピースを先頭から順次復号して再生するという構成とした場合に、鍵の漏洩の影響を軽減しつつ、復号処理及び再生処理の遅延を防ぐことができる。また、ピースの順序と暗号化ピースの順序とが同じではなくその対応付けがランダムであるような場合には、暗号化ピースの順序としてのピースインデックスの値の大小ではなく、対応するピース自体の順序によって優先的にピースインデックスを優先ピースインデックスとして選定する構成としても良い。また、逆に、候補のピースインデックスの値が大きい程優先順位が高くなるように設定し、優先順位が最も高いピースインデックスを優先ピースインデックスとして選定するようにしても良い。このように、値の大きいピースインデックスを優先して送信することで、リーチャ５０が、暗号化ピースを取得して直ぐに暗号鍵の取得や再生を行うことを防ぐことができる。このため、Ｐ２ＰネットワークＮＴにおいて暗号化ピースの送受信が行われる時間を確保して、再生までにかかる時間を平滑化することもできる。
【００８８】
又は、シーダ５２自身が収集可能な周辺の暗号化ピースの分布状況に基づいて、複数の優先ピースインデックスの候補の中から１つを選択するようにしても良い。シーダ５２の周辺の暗号化ピースの分布状況は、例えば、Ｐ２ＰネットワークＮＴにおいてシーダ５２の周辺に存在するリーチャ５０から、リーチャ５０が既に取得した暗号化ピースのピースインデックスとバリエーションインデックスとを示すリストを取得してこれを分析することにより得るようにしても良い。また、シーダ５２の周辺の暗号化ピースの分布状況を既に取得可能なトラッカ５１から当該分布状況をシーダ５２は取得するようにしても良い。この場合、シーダ５２は、優先ピースインデックスの候補となるピースインデックスのうち、当該ピースインデックスに対応する暗号化ピース列に属する暗号化ピースの分布総数が最小のピースインデックスや、複数の暗号化ピースの送信回数の開きが大きく分布に偏りがあるピースインデックスを優先して、優先ピースインデックスとして選定する。このような構成によれば、暗号化ピースのその時点での分布状況に適したピースインデックスを優先ピースインデックスとして選定することができる。
【００８９】
＜変形例１０＞
上述の変形例９において、優先ピースインデックスの候補が複数存在した場合の優先ピースインデックス選定処理の各変形例について説明したが、各変形例において優先ピースインデックスを選定する各選定基準のそれぞれに重み付けをして、これらを組み合わせて利用しても良い。また、未送信暗号化ピースの個数が同数のときの選定基準としてではなく、優先ピースインデックスの選定において、未送信暗号化ピースの個数と組み合わせて利用しても良い。この場合は、他の選定基準（例えば、バリエーションインデックスの値の大きさ）によっては、未送信暗号化ピースの個数が最大ではないピースインデックスが、優先ピースインデックスとして選定される。このような構成によれば、より柔軟で状況に応じた優先ピースインデックスの選定が可能となる。
【００９０】
＜変形例１１＞
上述の実施の形態においては、シーダ５２は、ピース要求に対して一つの暗号化ピースを送信するとしたが、一度に複数の暗号化ピースを送信しても良い。即ち、シーダ５２は、優先ピースインデックスに対応する暗号化ピース列に属する暗号化ピースのうち未送信暗号化ピースが複数ある場合これを一度にリーチャ５０に送信するようにしても良い。但し、シーダ５２は、ピース要求に対して図１５のステップＳ２４〜ステップＳ２６を行った後にステップＳ２７の送信状況テーブル更新処理を行い、複数の暗号化ピースの送信途中で、優先ピースインデックスに対応する暗号化ピース列に属する暗号化ピースのうち未送信暗号化ピースがなくなった場合には、ステップＳ２０の優先ピースインデックス選定処理を行って優先ピースインデックスを更新して、新たな優先ピースインデックスに対応する暗号化ピース列に属する暗号化ピースのうち未送信暗号化ピースを送信しても良い。このように同一の暗号化ピース列から複数の暗号化ピースを送信する構成とすることで、シーダ５２は特定の暗号化ピース列の暗号化ピースを素早く送信済みとすることができる。特に、バリエーションインデックスの最大値の大きい暗号化ピースに関して効果が大きい。また、暗号化ピースを受信するリーチャ５０の帯域速度や他のリーチャ５０との接続数に応じて暗号化ピースを提供することで、鍵の漏洩の影響の限定を意図して暗号化ピースを提供することができる。例えば、帯域が大きいリーチャ５０には帯域が狭いリーチャ５０よりも複数の暗号化ピースを送信しておくことで、そのリーチャ５０が暗号化ピースを送信する側となった場合に単一の暗号化ピースを他のリーチャ５０に高速に送信して、他のリーチャ５０と共有してしまうことを避けることが可能である。
【００９１】
＜変形例１２＞
上述のステップＳ２７の送信状況テーブル更新処理において、優先ピースインデックスの初期化を、優先ピースインデックスに対応する暗号化ピース列に未送信暗号化ピースが存在しない場合に行うようにしたが、これに限らず、例えば、当該未送信暗号化ピースの個数がその暗号化ピース列のバリエーションインデックスに占める割合が閾値以下である場合に行うようにしても良い。また、優先ピースインデックスが設定されてから一定時間が経った場合に、優先ピースインデックスの初期化を行うようにしても良い。このような構成とすることで、リーチャ５０の総数よりもバリエーションインデックスの数が多い場面で、暗号化ピース列における暗号化ピースのバリエーションを提供しきることが難しい状況であっても、以下のような効果が得られる。例えば、優先ピースインデックスに対応する暗号化ピースを既に受信したリーチャ５０が他のピースインデックスの暗号化ピースを受信することを円滑に進めることができる。
【００９２】
また、優先ピースインデックスの初期化を行うか否かの判断は、判断時点で自身に接続しているリーチャ５０の数（リーチャ数という）とその時点での優先ピースインデックスに対応する暗号化ピースのバリエーションインデックスの個数（以降、対象バリエーション数という）との関係に応じて行うようにしても良い。この場合、シーダ５２は、自身に接続しているリーチャ５０の数（リーチャ数）を検出する手段を有しており、ステップＳ８０２において、その手段によって検出したリーチャ数と対象バリエーション数とを比較する。そして、リーチャ数が対象バリエーション数より小さい場合には、シーダ５２は、送信済である暗号化ピースのバリエーションインデックスの個数がリーチャ数と等しいか否かを判断する。そしてこれらの数が等しいことを初期化条件として、ステップＳ８０３と同様にして、シーダ５２は優先ピースインデックスの初期化を行う。そして、シーダ５２は、この段階のリーチャ数を初期化時リーチャ数として、またこの時点での優先ピースインデックスを初期化前優先ピースインデックスとして記憶しておく。そして、次に優先ピースインデックス選定処理を行うときには、シーダ５２は、その時点でのリーチャ数と初期化時リーチャ数とを比較する。このとき、リーチャ数の方が初期化時リーチャ数より大きい場合、シーダ５２は、初期化前優先ピースインデックスを優先ピースインデックスとして再設定する。リーチャ数が初期化時リーチャ数と等しいか又は初期化時リーチャ数より少ない場合には、シーダ５２は、初期化前優先ピースインデックスを優先ピースインデックスの候補から外して、優先ピースインデックス選定処理を行う。ここで、リーチャ数の増加があった場合には、シーダ５２は、初期化前優先ピースインデックスを優先ピースインデックスとして設定し得るが、そうではなく、初期化前優先ピースインデックスを優先ピースインデックスの候補の一つに加えるように構成しても良い。
【００９３】
なお、全てのバリエーションインデックスに対応する暗号化ピースを送信しきらないうちに優先ピースインデックスを更新し、結果的にそのピースインデックスの暗号化ピースの鍵の漏洩の影響を軽減するために、リーチャ数が対象バリエーション数を超えるまではシーダ５２は暗号化ピースの提供をどのリーチャ５０に対しても行わないように構成しても良い。またシーダ５２は、優先ピースインデックス選定処理において、その時点でのリーチャ数よりも未送信暗号化ピース数が少ないピースインデックスのみを、優先ピースインデックスを選定する処理の対象とするようにしても良い。また、シーダ５２は、優先ピースインデックス選定処理において優先ピースインデックスを更新する場合には、更新前のピースインデックスとその時点でのリーチャ数を記憶しておく。そして、シーダ５２は、次の優先ピースインデックス選定処理でリーチャ数に変化が生じている場合、更新前のピースインデックスを優先して優先ピースインデックスとして設定できるか否かを判断するようにしても良い。このように構成することで、全てのバリエーションインデックスに対応する暗号化ピースを送信しきっていないピースインデックスについて、その暗号化ピースが多くのリーチャ５０に共有される前に、他のピースインデックスに対応する暗号化ピースを送信することができるようになる。また、シーダ５２における暗号化ピースの配信効率と両立するために、未送信暗号化ピースの個数がその暗号化ピース列のバリエーションインデックスに占める割合が閾値以下である場合に優先ピースインデックスの初期化を行うという上述の変形例における構成と組み合わせても良い。このような構成とすることで、対象バリエーション数がリーチャ数よりも多く、リーチャ数が対象バリエーション数よりも増加しないような場合でも、暗号化ピースの配信が可能となる。
【００９４】
また、上述のステップＳ２７の送信状況テーブル更新処理において、ステップＳ８０２で、未送信暗号化ピースが存在する場合には、シーダ５２は、優先ピースインデックスを更新する更新イベントを発生させるタイマを上書き方式により設定し、このタイマによって更新イベントを割り込みさせるように構成しても良い。図２２は、本変形例にかかる送信状況テーブル更新処理の手順を示すフローチャートである。ステップＳ８００〜Ｓ８０３の処理は上述の第１の実施の形態と同様である。ここでは、ステップＳ８０２の判断結果が肯定的である場合に、ステップＳ８０４で、シーダ５２は、タイマによって更新イベントの割り込みを設定する。そして、更新イベントの割り込みが発生すると、ピースインデックス決定処理では、シーダ５２は、その時点で設定されている優先ピースインデックスを除外したピースインデックスを対象として処理を行う。このピースインデックス決定処理は、初期状態が否かを確認する点と、その前に設定されていたピースインデックスを処理の対象外とする点とを除いて、上述のステップＳ２０の処理と同様である。このような構成とすることで、リーチャ５０の総数よりも対象バリエーション数が多く、新たなリーチャ５０が暗号化ピースの受信を要求してこない状況であっても、優先ピースインデックスに対応する暗号化ピースを既に受信したリーチャ５０が他のピースインデックスの暗号化ピースの受信を円滑に進めることができるような配信形態とすることができる。
【００９５】
また、上記したように、シーダ５２が、設定した優先ピースインデックスに対応する暗号化ピース列に属する全てのバリエーションインデックスに対応する暗号化ピースを送信しきっていない事態が想定される場合、シーダ５２は、優先ピースインデックスを新たに選定する時に、選定する前に優先ピースインデックスとして設定されていたピースインデックスに対して未送出フラグを送信状況テーブルにおいて設定するようにしても良い。そして、シーダ５２は、ピースインデックス決定処理において、優先ピースインデックスフラグを用いて送信候補とする暗号化ピースのピースインデックスを決定する処理に加え、未送出フラグを用いて送信候補とする暗号化ピースのピースインデックスを決定する処理を適宜行うようにしても良い。即ち、シーダ５２は、優先ピースインデックスフラグが‘１’に設定されているピースインデックス及び未送出フラグの値が‘１’に設定されているピースインデックスのうち少なくとも一方を優先ピースインデックスとして選定するようにしても良い。このような構成とすることで、未だ送信されていない暗号化ピースのバリエーションを提供する機会を設けることができる。また、優先ピースインデックスフラグによるピースインデックス決定処理と未送出フラグによるピースインデックス決定処理との優先順位を入れ替えることで、暗号化ピースの放出効率と暗号化ピースの配信効率とのどちらを優先させるのかを切り替えることができる。また、未送出フラグにより、送信候補とする暗号化ピースのピースインデックスを決定する場合に適用する優先順位としては、例えば、キュー構造であったりスタック構造であったりしても良いし、まったくランダムであっても良い。
【００９６】
＜変形例１３＞
上述のステップＳ９でシーダ５２が受信するピース要求には、本実施の形態にかかる暗号化ピース処理を行う通信装置向けのピース要求と、リーチャ５０から要求に応じて無条件に暗号化ピースを提供する通信装置向けのピース要求との２つを含めておいて良い。Ｐ２ＰネットワークＮＴにおいて、リーチャ５０から要求に応じて無条件に暗号化ピースを提供する通信装置が存在する場合であっても、ピース要求を受信した通信装置は、ピース要求に応じて適宜処理を行うことができ、リーチャ５０に暗号化ピースを送信することができる。一方、リーチャ５０は、ピース要求を送信する相手が前者の通信装置であるか後者の通信装置であるかに応じてメッセージの切り替えを行う必要がない。このため、リーチャ５０が、前者の通信装置であるか後者の通信装置であるかをいちいち判断する必要がなく、リーチャ５０の処理負担を軽減することができる。
【００９７】
また、上述のステップＳ９でシーダ５２が受信するピース要求には、リーチャ５０が指定するピースインデックスj（指定ピースインデックスという）とバリエーションインデックスi（指定バリエーションインデックスという）との組(i,j)を示すリストが含まれていても良い。この場合、ステップＳ２２のピースインデックス決定処理では、シーダ５２は、優先ピースインデックスと指定ピースインデックスとをそれぞれ比較して一致した場合に、当該指定ピースインデックスを、送信候補とする暗号化ピースのピースインデックスとして決定する。そして、ステップＳ２４のバリエーションインデックス決定処理では、シーダ５２は、送信状況テーブルの送信回数を参照して、指定ピースインデクスに対応する暗号化ピース列に属する暗号化ピースのうち、指定バリエーションインデックスに対応する暗号化ピースが未送信暗号化ピースであるか否か、即ち、当該暗号化ピースの送信回数が‘０’か否かを判断する。そして、当該判断結果が肯定的である場合、シーダ５２は、当該指定バリエーションインデックス及び指定ピースインデックスに対応する暗号化ピースを外部記憶装置から読み出してこれをリーチャ５０に送信する。このような構成とすることで、リーチャ５０は自身が所望した暗号化ピースが存在する場合には、それを効率的に取得することができる。
【００９８】
又は、上述のステップＳ９でシーダ５２が受信するピース要求には、リーチャ５０が指定するピースインデックスj（指定ピースインデックス）を示すリストが含まれていても良い。この場合、ステップＳ２２のピースインデックス決定処理では、シーダ５２は、優先ピースインデックスと指定ピースインデックスとをそれぞれ比較して一致した場合に、当該指定ピースインデックスを、送信候補とする暗号化ピースのピースインデックスとして決定する。そして、ステップＳ２４のバリエーションインデックス決定処理では、シーダ５２は、送信状況テーブルにおいて、当該指定ピースインデックスに対応する暗号化ピース列に属する暗号化ピースのバリエーションインデックスに対応する送信回数を参照して、当該暗号化ピース列に属する暗号化ピースのうち未送信暗号化ピースが存在するかを判断する。そして、当該判断結果が肯定的である場合、シーダ５２は、当該未送信暗号化ピースのバリエーションインデックス及びピースインデックスに対応する暗号ピースを外部記憶装置から読み出してこれをリーチャ５０に送信する。このような構成とすることで、リーチャ５０は自身が所望したピースインデックスに対応する暗号化ピースを取得することができ、既に取得したピースインデックスに対応する暗号化ピースをシーダ５２から送信されることを防止することができる。
【００９９】
＜変形例１４＞
また、上述のステップＳ９でシーダ５２が受信するピース要求には、リーチャ５０が既にデータの一部を取得済みの暗号化ピース（一部取得済み暗号化ピースという）について未取得の部分のデータを要求する一部データ要求が含まれるようにしても良い。また、この一部データ要求と、データの全部を未取得の暗号化ピースを要求する未取得ピース要求とが区別されて各々含まれるようにしても良い。一部データ要求としては、一部取得済み暗号化ピースを指定する指定ピースインデックス及び指定バリエーションインデックスの組（i,j）と、未取得の部分のデータのデータ範囲を指定する情報とを示すリストであっても良い。未取得ピース要求としては、未取得の暗号化ピースを指定する指定ピースインデックス及び指定バリエーションインデックスの組（i,j）を示すリスト又は指定ピースインデックスのみを示すリストであっても良い。図２３は、本変形例にかかるピース要求のデータ構成を例示する図である。同図においては、一部データ要求として、例えば、(1,19)のインデックスに対応する暗号化ピースのデータのうち、100バイト目から400バイト目のデータが未取得のデータのデータ範囲として指定されていることが示されている。また、未取得ピース要求として、指定ピースインデックスのみを示すリストであることが示されている。
【０１００】
このような構成において、シーダ５２は、ステップＳ２２のピースインデックス決定処理では、優先ピースインデックスと、一部データ要求において示される指定ピースインデックスとを比較して、これらが一致した場合には、次のように処理をする。シーダ５２は、ステップＳ２４のバリエーションインデックス決定処理において、当該優先ピースインデクスに対応する暗号化ピース列に属する暗号化ピースのうち、指定バリエーションインデックスに対応する暗号化ピースが未送信暗号化ピースであるか否かを判断する。そして、当該判断結果が肯定的である場合、シーダ５２は、当該指定バリエーションインデックス及び指定ピースインデックスに対応する暗号化ピースのうち、指定されたデータ範囲のデータを外部記憶装置から読み出してこれをリーチャ５０に送信する。このような構成とすることで、シーダ５２はリーチャ５０の保持するバリエーションインデックスを別途問い合わせる必要がなくなり、シーダ５２とリーチャ５０の処理負荷を削減できる。
【０１０１】
また、一部データ要求に加え未取得ピース要求がピース要求に含まれる場合、シーダ５２は、優先ピースインデックスと、一部データ要求において示される指定ピースインデックスとを比較してこれが一致しない場合に、優先ピースインデックスと、未取得ピース要求において示される指定ピースインデックスとを比較する。これらが一致した場合には、シーダ５２は、ステップＳ２４のバリエーションインデックス決定処理において、当該優先ピースインデクスに対応する暗号化ピース列に属する暗号化ピースのうち、指定バリエーションインデックスに対応する暗号化ピースが未送信暗号化ピースであるか否かを判断する。そして、当該判断結果が肯定的である場合、シーダ５２は、当該指定バリエーションインデックス及び指定ピースインデックスに対応する暗号化ピースを外部記憶装置から読み出してこれをリーチャ５０に送信する。
【０１０２】
また、一部データ要求において指定された指定バリエーションインデックスに対応する暗号化ピースが未送信暗号化ピースではない場合であっても、リーチャ５０の一部取得済み暗号化ピースの完成を優先して、当該暗号化ピースを送信するようにしても良い。また、ピースインデックス決定処理において、優先ピースインデックスと一部データ要求において指定された指定ピースインデックスとを比較したときこれらが一致しない場合でも、指定ピースインデックスを、送信候補とする暗号化ピースのピースインデックスとして決定するようにしても良い。このような構成とすることで、リーチャ５０は一部取得済み暗号化ピースについて必要なデータを優先して受信することができることから、暗号化ピースをより早く完成させることができるようになる。このため、その暗号化ピースを他のリーチャ５０と共有できることから配信効率の向上が見こまれる。
【０１０３】
尚、一部データ要求は、一部取得済み暗号化ピースを指定する指定ピースインデックス及び指定バリエーションインデックスの組（i,j）ではなく、指定ピースインデックスのみと、未取得のデータのデータ範囲を指定する情報とを示すリストであるようにしても良い。この場合のピースインデックス決定処理は上述と同様である。バリエーションインデックス決定処理では、シーダ５２は、上述の実施の形態又は変形例に記載した少なくとも1つの方法又はその組み合わせによる方法で、送信対象の暗号化ピースのバリエーションインデックスを決定する。そして、ここでは、シーダ５２は、ピースインデックス決定処理で決定したピースインデックスが、一部データ要求において指定されているか又は未取得要求において指定されているかを判断する。当該判断の結果、送信候補となる暗号化ピースのピースインデックスが未取得要求において指定されている場合、シーダ５２は、当該ピースインデックス及び当該ピースインデックスに対応してバリエーションインデックス決定処理で決定したバリエーションインデックスに対応する暗号化ピースを外部記憶装置から読み出してこれをリーチャ５０に送信する。一方、送信候補となる暗号化ピースのピースインデックスが一部データ得要求において指定されている場合、シーダ５２は、一部取得済み暗号化ピースを指定する指定バリエーションインデックス及び未取得の部分のデータのデータ範囲を指定する情報を取得するための処理を行う。以下は当該処理の一例である。
【０１０４】
まず、シーダ５２は、送信候補の暗号化ピースのピースインデックスとして決定したピースインデックスをリーチャ５０に通知する。ここで、シーダ５２が、送信候補の暗号化ピースのピースインデックスを決定できなかった場合は、その旨を伝えるメッセージをリーチャ５０に送信しても良いししなくても良い。前者の場合リーチャ５０の処理効率が向上し得り、後者の場合シーダ５２の処理効率及び攻撃耐性が向上し得る。一方、リーチャ５０は、送信候補となる暗号化ピースのピースインデックスがシーダ５２から通知されると、それに応答して、当該ピースインデックスに対応する一部取得済み暗号化ピースのバリエーションインデックス（指定バリエーションインデックス）を指定する情報及び未取得の部分のデータのデータ範囲を指定する情報をシーダ５２へ送信する。シーダ５２は、当該情報を受信すると、バリエーションインデックス決定処理で決定したバリエーションインデックスと、指定バリエーションインデックスとを比較する。そして、これらが一致する場合は、シーダ５２は、決定したピースインデックス及び指定バリエーションインデックスに対応する暗号化ピースのうち指定されたデータ範囲のデータを外部記憶装置から読み出してこれをリーチャ５０に送信する。
【０１０５】
バリエーションインデックス決定処理で決定したバリエーションインデックスと、指定バリエーションインデックスとが一致しない場合には、シーダ５２は、送信可能な暗号化ピースが存在しない旨をリーチャ５０に通知しても良いし通知しなくても良い。この場合に期待される効果は上述の通りである。また、バリエーションインデックス決定処理で決定したバリエーションインデックスと、指定バリエーションインデックスとが一致した場合でも、指定されたデータ範囲によっては、シーダ５２は、暗号化ピースの提供を拒否しても良い。例えば、データ範囲として暗号化ピースの先頭のデータから途中のデータまでが指定されているような場合である。これは、通常の暗号化ピースのやりとりでは先頭周辺のデータが欠損することは想定されないため、リーチャ５０になんらかの攻撃意図があると判断することもできるからである。また、指定されたデータ範囲から想定される暗号化ピースの取得割合がある閾値を超えない場合なども、同様の理由により、暗号化ピースの提供を拒否する事例となりえる。
【０１０６】
このように、指定されたデータ範囲によっても暗号化ピースを送信するか否かを判断することによって、通常想定されない動作をするリーチャ５０による影響を排し、安全性を向上させることができる。即ち、以上のように、シーダ５２は、送信の要求された暗号化ピースが、リーチャ５０がデータの一部取得済みか又はデータの全部を未取得かで処理を分岐させることで、リーチャ５０がデータの全部を未取得である暗号化ピースを提供する場合の処理負荷を軽減することができる。それとともに、一部取得済み暗号化ピースを提供する場合においても、シーダ５２は、送信対象の暗号化ピースのバリエーションインデックスをリーチャ５０に明かすことなく、更に、暗号化ピースの取得にある程度の手間をリーチャ５０にかけさせることで、リーチャ５０が数多くの暗号化ピースを無差別に取得しようとする行為に一定の抑止力を与えることができる。尚、ここではシーダ５２はピースインデックスのみをリーチャ５０に通知するとしたが、その際に、バリエーションインデックス決定処理で決定したバリエーションインデックスも併せて送信しても良い。この場合、リーチャ５０は、当該暗号化ピースが自身の所望するものであるかどうかをより早く判断することができる。
【０１０７】
[第２の実施の形態]
次に、コンテンツ配信システムの第２の実施の形態について説明する。なお、上述の第１の実施の形態と共通する部分については、同一の符号を使用して説明したり、説明を省略したりする。
【０１０８】
（１）構成
＜シーダ５２の構成＞
本実施の形態にかかるコンテンツ配信システムにおいては、シーダ５２の機能的構成が上述の第１の実施の形態におけるものと異なる。本実施の形態におけるシーダ５２は、リーチャ５０からのピース要求に応じて暗号化ピースの送信を行うものの、自身が保持する暗号化ピースについて、未送信の暗号化ピースを全て送信することを優先して行いつつ、配信効率の向上のために、場合によっては、未送信暗号化ピースを含まない暗号化ピース列の中から送信対象の暗号化ピースを選択してこれをリーチャ５０に送信する。
【０１０９】
図２４は、本実施の形態にかかるシーダ５２の機能的構成を例示する図である。シーダ５２は、上述したピース情報送信部５２０と、ピース要求受信部５２１と、優先ピースインデックス選定部５２２と、ピースインデックス決定部５２３と、バリエーションインデックス決定部５２４と、送信状況テーブル更新部５２５と、ピース送信部５２６とに加え、送出済フラグ照会部５２７を有する。
【０１１０】
送信状況テーブル更新部５２５は、上述の第１の実施の形態と同様にして、送信状況テーブルにおいて、送信回数の記録と優先ピースインデックスの初期化とを行う。更に、本実施の形態においては、送信状況テーブル更新部５２５は、優先ピースインデックスの初期化の際に、送信状況テーブルにおいて送出済フラグの値を設定する。図２５は、本実施の形態にかかる送信状況テーブルのデータ構成を例示する図である。同図に示される送信状況テーブルにおいては、上述の第１の実施の形態と同様に、シーダ５２が記憶している暗号化ピースのインデックス(i,j)に対応して各送信回数が記録されると共に、各暗号化ピース列に対して優先ピースインデックスフラグが対応付けられており、更に、本実施の形態においては、各暗号化ピース列に対して送出済フラグが対応付けられている。送出済フラグとは、優先ピースインデックスとして選定されたことのあるピースインデックスに対応する暗号化ピース列に属する暗号化ピースの全てを送信済であるか否かを示すものであり、初期値として‘OFF’が設定されている。送信状況テーブル更新部５２５は、優先ピースインデックスの初期化の際に、初期化前の優先ピースインデックスに対応する各暗号化ピース列に対する送出済フラグの値を‘ON’に設定する。
【０１１１】
ピースインデックス決定部５２３は、ピース要求受信部５２１がピース要求を受信した場合、送信状況テーブルの優先ピースインデックスフラグを参照して、優先ピースインデックスとして選定されたピースインデックスが存在するか否かを判断し、当該判断結果が肯定的である場合は、上述の第１の実施の形態と同様である。当該判断結果が否定的である場合、ピースインデックス決定部５２３は、送出済フラグ照会部５２７を介して、送信状況テーブルにおいて送出済フラグが‘ON’に設定されているピースインデックスjが存在するか否かを判断する。そして、当該判断結果が肯定的である場合に、ピースインデックス決定部５２３は、送信候補とする暗号化ピースのピースインデックスjを決定する。
【０１１２】
送出済フラグ照会部５２７は、送信状況テーブルの送出済フラグを参照して、送出済フラグが‘ON’に設定されているピースインデックスjを照会する。
【０１１３】
ピース要求受信部５２１、優先ピースインデックス選定部５２２、バリエーションインデックス決定部５２４及びピース送信部５２６の各機能については上述の第１の実施の形態と略同様である。
【０１１４】
尚、リーチャ５０がシーダとして機能する場合の機能的構成についても、上述したシーダ５２の機能的構成と略同様であるため、その説明を省略する。
【０１１５】
（２）動作
次に、本実施の形態にかかるコンテンツ配信システムで行うコンテンツ配信処理の手順について説明する。尚、ここでも、リーチャ５０は、暗号化ピースを他のリーチャ５０からも受信可能であるが、説明の便宜上、暗号化ピースをシーダ５２Ａ〜５２Ｃからの少なくとも１つから受信するものとする。本実施の形態にかかるコンテンツ配信処理の手順自体は上述の図１４を用いて説明した通りである。本実施の形態においては図１４のステップＳ９における暗号化ピース送信処理の手順の詳細が上述の第１の形態におけるものと異なる。図２６は、本実施の形態にかかる優先ピースインデックス選定処理及び暗号化ピース送信処理の手順を示すフローチャートである。ステップＳ２０では、シーダ５２は、上述の第１の実施の形態と同様にして、優先ピースインデックス選定処理を行う。但し、ここでは、未送信暗号化ピースが存在しない状況であってもシーダ５２は優先ピースインデックスを選定しないまま暗号化ピース送信処理を継続して暗号化ピースの送信を行うことを想定している。ステップＳ２１〜Ｓ２２までの処理は上述の第１の実施の形態と同様である。
【０１１６】
ステップＳ３０では、送信候補とする暗号化ピースのピースインデックスが決定されているか否か、即ち、送信状況テーブルにおいて優先ピースインデックスフラグが‘１’が設定されているピースインデックスが存在しその中から１つのピースインデックスが決定されているか否かをシーダ５２は判断する。当該判断結果が肯定的である場合、上述の第１の実施の形態と同様にステップＳ２４に進む。ステップＳ２３の判断結果が否定的である場合は、ここでは、ステップＳ３１に進む。ステップＳ３１では、シーダ５２は、送出済フラグ照会処理を行う。
【０１１７】
図２７は、送出済フラグ照会処理の手順を示すフローチャートである。シーダ５２は、まず、送信状況テーブルにおいて送出済フラグが‘ON’に設定されているピースインデックスを照会する（ステップＳ６００）。そして、シーダ５２は、送出済フラグが‘ON’に設定されている該当のピースインデックスが存在するか否かを判断し（ステップＳ６０１）、当該判断結果が否定的である場合、送信候補とする暗号化ピースのピースインデックスを決定せずに、送出済フラグ照会処理を終了する。ステップＳ６０１の判断結果が肯定的である場合には、シーダ５２は、該当のピースインデックスが複数存在するか否かを判断する（ステップＳ６０２）。当該判断結果が否定的である場合、シーダ５２は、当該ピースインデックスを、送信候補とする暗号化ピースのピースインデックスとして決定する（ステップＳ６０４）。ステップＳ６０２の判断結果が肯定的である場合、複数存在する該当のピースインデックスの中から１つのピースインデックスをランダムに選択する（ステップＳ６０３）。そして、シーダ５２は、選択したピースインデックスを、送信候補とする暗号化ピースのピースインデックスとして決定して（ステップＳ６０４）、送出済フラグ照会処理を終了する。
【０１１８】
以上のようにして、シーダ５２は、各暗号化ピース列について送信状況テーブルにおいて記録されている送出済フラグを参照して、属する暗号化ピースの全てを送信済である暗号化ピース列に対応するピースインデックスの中から、送信候補とする暗号化ピースのピースインデックスを決定する。
【０１１９】
図２６に戻り、ステップＳ２３では、シーダ５２は、送信候補とする暗号化ピースのピースインデックスを決定できたか否かを判断して、当該判断結果が肯定的である場合、次いで、バリエーションインデックス決定処理を行う（ステップＳ２４）。ステップＳ２３の判断結果が否定的である場合には、シーダ５２は、暗号化ピースを送信しない旨を示す通知メッセージをリーチャ５０に送信して、新たなピース要求を待ち受ける。
【０１２０】
図２８は、本実施の形態にかかるバリエーションインデックス決定処理の手順を示すフローチャートである。ステップＳ５００の処理は上述の第１の実施の形態と同様である。ステップＳ５００の後ステップＳ５０７では、シーダ５２は、取得したピースインデックスをキーとして送信状況テーブルを参照して、当該ピースインデックスが優先ピースインデックスであるか否か、即ち、当該ピースインデックスに対する優先ピースインデックスフラグの値が‘１’に設定されているか否かを判断する。当該判断結果が肯定的な場合、当該ピースインデックスが、優先ピースインデックスとして、送信候補の暗号化ピースのピースインデックスに決定されたことを意味している。この場合、シーダ５２は、上述の第１の実施の形態と同様にしてステップＳ５０２〜Ｓ５０５の処理を行う。
【０１２１】
一方、ステップＳ５０７の判断結果が否定的である場合、当該ピースインデックスが、優先ピースインデックスとしてではなく、送出済フラグによって、送信候補の暗号化ピースのピースインデックスに決定されたことを意味している。この場合、シーダ５２は、送信状況テーブルに記録された送信回数に関らず、当該ピースインデックスに対応する暗号化ピース列に属する暗号化ピースのバリエーションインデックスの中から１つのバリエーションインデックスをランダムに選択する（ステップＳ５０８）。尚、シーダ５２は、当該１つのバリエーションインデックスを、ランダムに選択するのではなく、Ｐ２ＰネットワークＮＴでの暗号化ピースの流通状況などに基づいて選択するようにしても良い。そして、シーダ５２は、選択したバリエーションインデックスを、送信対象の暗号化ピースのバリエーションインデックスとして決定する(ステップＳ５０５)。
【０１２２】
図２６に戻ると、ステップＳ２５〜Ｓ２６の処理は上述の第１の実施の形態と同様である。ステップＳ２６の後ステップＳ２７では、シーダ５２は、送信した暗号化ピースに応じて、以下のようにして送信状況テーブル更新処理を行う。図２９は本実施の形態にかかる送信状況テーブル更新処理の手順を示すフローチャートである。ステップＳ８００〜Ｓ８０２までの処理は上述の第１の実施の形態と同様である。ステップＳ８０２の後ステップＳ８０５では、シーダ５２は、送信状況テーブルにおいて、優先ピースインデックスとして選定されているピースインデックスに対して、送出済フラグの値を‘ON’に設定する。その後、ステップＳ８０３では、シーダ５２は、上述の第１の実施の形態と同様にして、優先ピースインデックスを初期化する。このように送出済フラグの値を設定して優先ピースインデックスを初期化した後に、ステップＳ２０の優先ピースインデックス選定処理をシーダ５２が行った際、優先ピースインデックスを選定できない場合がある。この場合に、上述のステップＳ２３の判断結果が否定的となり、ステップＳ３０の送出済フラグ照会処理におけるステップＳ６０１の判断結果が肯定的となる。
【０１２３】
このようにしてシーダ５２は、属する暗号化ピースの全てを送信済である暗号化ピース列について、リーチャ５０の要求に応じて暗号化ピースを提供する。これにより、第１の実施の形態と同様にして鍵の漏洩による影響を軽減しつつも、暗号化ピースの配信効率を向上させることができる。
【０１２４】
以上、第２の実施の形態について説明したが、当該実施の形態に多様な変更または改良を加えることができる。
【０１２５】
（３）変形例
＜変形例１５＞
上述の実施の形態の構成と、上述の第１の形態の変形例１４で説明した一部取得済み暗号化ピースの送信を優先する構成とを併用しても良い。この場合、シーダ５２は、送出済フラグによる暗号化ピースの送信と、一部データ要求による暗号化ピースの送信とのどちらを優先して行っても良い。
【０１２６】
＜変形例１６＞
上述の実施の形態においては、ピース要求が、上述の第１の実施の形態の変形例１３で説明した指定ピースインデックスを含んでいても良い。この場合、シーダ５２は、送出済フラグ照会処理のステップＳ６００で、指定ピースインデックスのうち送信状況テーブルにおいて送出済フラグの値が‘ON’に設定されているピースインデックスを照会して、以降の処理を行えば良い。
【０１２７】
＜変形例１７＞
上述の実施の形態においては、シーダ５２は、送出済フラグ照会処理において、ステップＳ６０３では、該当のピースインデックスが複数存在する場合その中から１つのピースインデックスを、ランダムに選択するものとしたが、送出済フラグが設定された順番や、各ピースインデックスの暗号化ピースの送信回数や、上述の第１の実施の形態の変形例９，１４で記載した優先順位などの各選択基準に基づいて選択するようにしても良い。このようにして１つのピースインデックスを選択することで、特定のピースインデックスが他のピースインデックスより早く暗号化ピースを送信しきることを意図した変形例９，１４と同様の効果を得ることができる。また、上述の選択基準を組み合わせて利用しても良い。例えば、各ピースインデックスに対応する暗号化ピース列について、送信回数の最大値から最小値を引いた値を優先順位として設定して、送信された暗号化ピースの送信回数の偏りが大きい暗号化ピース列を選択することができる。更に、（最大値から最小値を引いた値）×（バリエーションインデックスの大きさ）の値を優先順位として設定して、送信された暗号化ピースの送信回数の偏りの大きさに加えて、その暗号化ピースの重要度も加味した上で、送信候補とする暗号化ピースのピースインデックスを決定することができる。
【０１２８】
また、このような優先順位を決定する処理は、上述の送信状況テーブル更新処理と併せて行って優先順位を送信状況テーブルに記録するようにしても良い。即ち、シーダ５２は、送出済フラグが‘ON’に設定される対象のピースインデックスに対して、優先順位を各々設定してその値を送信状況テーブルに記録するようにする。図３０は、本変形例にかかる送信状況テーブルを示す図である。同図においては、ピースインデックス‘０’に対して優先順位‘１’が記録されており、ピースインデックス‘ｎ−１’に対して優先順位‘２’が記録されていることが示されている。シーダ５２は送出済フラグ照会処理では送信状況テーブルに記録された優先順位を参照し、その参照結果に基づいてピースインデックス決定処理では、送信候補とする暗号化ピースのピースインデックスを決定するようにすれば良い。
【０１２９】
また、上述の送出済フラグ及び優先順位に加え、変形例１２にかかる未送出フラグを組み合わせて用いることにより、送信候補とする暗号化ピースのピースインデックスを決定するようにしても良い。このピースインデックスを決定する際に、送出済フラグ、優先順位及び未送出フラグのいずれを優先して用いるかは特に限定されない。
【０１３０】
＜変形例１８＞
上述の実施の形態においては、シーダ５２は、バリエーションインデックス決定処理において、バリエーションインデックスの候補が複数ある場合その中から１つのバリエーションインデックスを、ランダムに選択するのではなく、送信回数に基づいて選択するようにしても良い。例えば、送信候補とする暗号化ピースのピースインデックスに対して複数存在するバリエーションインデックスに各々対応する各暗号化ピースの送信回数が異なる場合、送信回数が同数になるように、バリエーションインデックスを選択しても良い。例えば、ピースインデックスjに対して、バリエーションインデックスi1,i2,i3(１≦i1,i2,i3≦ｍ)が候補として存在し、それぞれの暗号化ピース(i1,j)、暗号化ピース(i2,j)、および暗号化ピース（i3,j）の送信回数がそれぞれ‘１’,‘２’,‘３’であるものとする。この場合、シーダ５２は、バリエーションインデックスi1を選択する。また、暗号化ピース(i1,j)、暗号化ピース(i2,j)、および暗号化ピース（i3,j）の送信回数がそれぞれ‘２’,‘３’,‘２’である場合にはシーダ５２は、バリエーションインデックスi1又はi3のどちらかをランダムに選択するようにすれば良い。このような構成とすることで、それぞれの暗号化ピースをＰ２ＰネットワークＮＴ上に偏り無く配信することができる。この結果、暗号化ピースの偏りがある状況と比較して、ユーザが保持する暗号化ピースの偏りを少なくすることができ、鍵の漏洩時の影響を軽減することができる。
【０１３１】
[変形例]
なお、本発明は前記実施の形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、前記実施の形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施の形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施の形態にわたる構成要素を適宜組み合わせてもよい。また、以下に例示するような種々の変形が可能である。
【０１３２】
＜変形例１９＞
上述した各実施の形態においては、コンテンツの各ピースへの分割や、各ピースの暗号化は、トラッカ５１や、鍵サーバ５３や、コンテンツ製作者が用意したサーバのいずれが行っても良い。また、各暗号化ピースは、例えば、トラッカ５１、鍵サーバ５３又は信頼できる第三者（例えば、コンテンツ製作者が用意したサーバ）からシーダ５２Ａ（初期シーダ）へ与えられるものとする。
【０１３３】
また、上述した各実施の形態においては、復号鍵及び暗号鍵のうち少なくとも一方を鍵サーバ５３自体が発行して生成するようにしても良いし、トラッカ５１やコンテンツ製作者が用意したサーバが発行したり生成したりしたものを鍵サーバ５３が取得するようにしても良い。
【０１３４】
また、コンテンツＣを分割した全てのピースＣ１〜ＣＮが各々異なる暗号鍵で暗号化されているとしたが、これに限らず、一部のピースは同一の暗号鍵で暗号化されていても良い。
【０１３５】
＜変形例２０＞
上述した各実施の形態においては、トラッカ５１、シーダ５２及びリーチャ５０の数は、上述したものに限らない。
【０１３６】
また、Ｐ２ＰネットワークＮＴに販売サーバ５４が接続され、リーチャ５０は、販売サーバ５４からTorrent Fileを取得するようにした。しかし、販売サーバ５４はＰ２ＰネットワークＮＴに接続されていなくても良く、リーチャ５０は、例えばＣＤ−ＲＯＭなどの記録媒体に記録されたTorrent Fileを読み出すことにより、Torrent Fileを取得するようにしても良い。
【０１３７】
また、リーチャ５０は、鍵サーバ５３とネットワークを介して接続されるようにしたが、ネットワークを介さず専用線などを介して接続されるようにしてもよいし、プロキシサーバを介して接続されるようにしても良い。これにより管理能力を高めたり、プロキシサーバの後段にある鍵サーバ５３が直接攻撃されないようにしたりすることができる。
【０１３８】
＜変形例２１＞
上述した各実施の形態において、シーダ５２で実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成しても良い。また、当該各種プログラムを、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ、ＤＶＤ（Digital Versatile Disk）等のコンピュータで読み取り可能な記録媒体に記録して提供するように構成しても良い。この場合には、プログラムは、シーダ５２において上記記録媒体から読み出して実行することにより主記憶装置（例えばＲＡＭ）上にロードされ、上記機能的構成において説明した各部が主記憶装置上に生成される。リーチャ５０において実現される各種プログラムについても同様である。
【０１３９】
＜変形例２２＞
上述した第１の実施の形態においては、各暗号化ピースの送信回数と、優先ピースインデックスフラグとを１つの送信状況テーブルに記憶させこれを１つの外部記憶装置に記憶させるようにしたが、これらを別々のテーブルに記憶させるにしても良いし別々の記憶手段に記憶させるようにしても良い。第２の実施の形態における送出済フラグや、変形例１２にかかる未送出フラグや、変形例１７にかかる優先順位ついても同様である。更に、暗号化ピースを記憶する記憶装置と、送信状況テーブルを記憶する記憶装置とは同じであっても良いし、異なっていても良い。
【０１４０】
また、上述した各実施の形態においては、優先ピース情報として優先ピースインデックスフラグを用いたが、これに限らず、優先ピースを特定する情報であればどのようなものであっても良い。
【０１４１】
＜変形例２３＞
上述の各実施の形態においては、シーダ５２は、リーチャ５０と同様に、リーチャ５０や他のシーダ５２から暗号化ピースを受信する機能を備えていても良い。そして、シーダ５２は、ピース要求をリーチャ５０から受信した場合、当該リーチャ５０から少なくとも１つの暗号化ピースの少なくとも一部を受信しているか否かを判断し、当該判断結果に応じて、暗号化ピースの送信の可否を決定するようにしても良い。リーチャ５０から少なくとも１つの暗号化ピースの少なくとも一部を受信しているか否かは、例えば、シーダ５２がその時点で受信しているデータの受信量により判断することができる。そして、シーダ５２は、当該判断結果が肯定的である場合に、暗号化ピースを当該リーチャ５０に送信することを決定し、当該判断結果が否定的である場合には、暗号化ピースを当該リーチャ５０に送信しないことを決定する。そして、決定結果が前者である場合に、シーダ５２は、上述の各実施の形態と同様にして、暗号化ピースをリーチャ５０に送信する。このような構成は、暗号化ピースの送受信を互いに行い合うことにより各々暗号化ピースを取得する通信システムに用いて好適である。
【０１４２】
＜変形例２４＞
上述の各実施の形態においては、シーダ５２は、１つの暗号化ピースを複数回に分けてリーチャ５０に送信するように構成しても良い。この場合、シーダ５２は、当該暗号化ピースの送信に係るセッションを管理するためのセッション情報を記憶するセッション情報記憶テーブルを備える。セッション情報は、当該暗号化ピースの送信対象であるリーチャ５０を識別するためのリーチャ識別情報と対応付けられて記憶されるものであり、当該リーチャ５０がデータの一部を取得済みである暗号化ピース（継続暗号化ピース）のピースインデックス及びバリエーションインデックスと、送信済データ量と、新規セッション受入フラグとを含む。送信済データ量は、継続暗号化ピースについて当該リーチャ５０が既に取得した部分のデータ量を示す。尚、暗号化ピースが更に複数のサブピースに分割されている構成である場合、送信済データ量は、当該リーチャ５０が既に取得したサブピースに対して割り当てられたインデックスを示すものであっても良い。新規セッション受入フラグとは、シーダ５２が、当該暗号化ピースの送信対象であるリーチャ５０がデータの全部を未取得である暗号化ピース（新規暗号化ピース）を要求するピース要求（新規ピース要求）をどのように処理するかの判断基準となるものである。新規セッション受入フラグが‘ON’の場合には、リーチャ５０からの新規ピース要求を受け入れて、新規暗号化ピースを提供可能であることを示し、新規セッション受入フラグが ‘OFF’の場合には、当該新規暗号化ピースを提供不可能であることを示す。シーダ５２は起動時に新規セッション受入フラグを‘ON’に設定する。リーチャ識別情報は、例えば、リーチャ５０に対して割り当てられたＩＰアドレスや接続元ポート番号や、リーチャ５０を特定するＩＤ情報などである。以上のように、シーダ５２は、セッション情報において継続暗号化ピースに関する情報とリーチャ５０を識別するためのリーチャ識別情報とを対応付けて記憶する。このため、シーダ５２は同時に複数のリーチャ５０に暗号化ピースを送信する場合であってもセッションの識別が可能である。
【０１４３】
図３１は、本変形例に係るシーダ５２の機能的構成を例示する図である。シーダ５２は、上述の実施の形態で説明したピース情報送信部５２０と、ピース要求受信部５２１と、優先ピースインデックス選定部５２２と、ピースインデックス決定部５２３と、バリエーションインデックス決定部５２４と、送信状況テーブル更新部５２５と、ピース送信部５２６とに加え、セッション情報確認部５２８と、セッション情報更新部５２９とを更に有する。ピース要求受信部５２１は、ピース要求をリーチャ５０から受信する際に、リーチャ識別情報を取得する。尚、リーチャ５０から受信するピース要求が、継続暗号化ピースを要求する継続ピース要求である場合、そのデータ構成は例えば図３２に示されるものとなる。同図に示されるように、継続ピース要求は、新規ピース要求フラグと、送信要求対象の継続暗号化ピースのピースインデックス及びバリエーションインデックスと、データ開始位置と、取得希望データ長とを含む。新規ピース要求フラグは、ピース要求が新規ピース要求であるか否かを示すものである。新規ピース要求フラグが‘ON’である場合、ピース要求が新規ピース要求であることを示し、新規ピース要求フラグが‘OFF’である場合、ピース要求が継続ピース要求であることを示す。ここでは、新規ピース要求フラグが‘OFF’に設定される。データ開始位置は、継続暗号化ピースの未取得のデータの開始位置を示す。取得希望データ長とは、継続暗号化ピースの未取得のデータのうちリーチャ５０が取得を要求するデータのデータ長（データ量）を示すものであり、データ開始位置からのデータ長を示す。尚、ここでは、Torrent Fileに含まれるファイル情報においては、各暗号化ピースのデータ量が示されているものとする。リーチャ５０は、このデータ量に基づいて、上述のデータ開始位置を算出したり、未取得である部分全体のデータ長を算出してこれに基づいて上述の取得希望データ長を算出したりする。尚、データ量やデータ長の算出基準は特に限定されない。
【０１４４】
また、リーチャ５０から受信するピース要求が新規ピース要求である場合、そのデータ構成は例えば図３３に示されるものとなる。同図に示されるように、新規ピース要求は、新規ピース要求フラグと、取得を要求する取得希望データ長と、取得を要求するピースインデックスのリストとを含む。また、ここでは、新規ピース要求フラグは‘ON’に設定される。
【０１４５】
図３１の説明に戻る。セッション情報確認部５２８は、ピース要求受信部５２１が新規ピース要求をリーチャ５０から受信した場合、セッション情報記憶テーブルに記憶されているセッション情報において当該リーチャ５０のリーチャ識別情報に対応する新規セッション受入フラグを参照して、当該ピース要求を受け入れるか否かを判断する。そして、セッション情報確認部５２８は、当該新規ピース要求を受け入れた場合には、セッション情報更新部５２９を介して新規セッション受入フラグを’OFF’に設定する。また、セッション情報確認部５２８は、ピース要求受信部５２１が継続ピース要求をリーチャ５０から受信した場合に、セッション情報記憶テーブルにおいて当該リーチャ５０のリーチャ識別情報と対応付けられて記憶されているセッション情報に含まれるピースインデックス、バリエーションインデックス及び送信済みデータ量と、受信した継続ピース要求に含まれるピースインデックス、バリエーションインデックス及びデータ開始位置との間で整合がとれているかを確認して、当該継続ピース要求を受け入れるか否かを判断する。
【０１４６】
また、セッション情報確認部５２８は、ピース送信部５２６が新規暗号化ピースをリーチャ５０に送信する場合には、セッション情報記憶テーブルにおいて、セッション情報として当該リーチャ５０の識別情報と対応付けて当該暗号化ピースのピースインデックス及びバリエーションインデックスと送信済データ量とを記憶する。また、セッション情報更新部５２９は、ピース送信部５２６が継続暗号化ピースを送信する場合には、送信されたデータのデータ量を算出して、セッション情報記憶テーブルのセッション情報における送信済データ量を更新する。そして、セッション情報確認部５２８は、この送信済データ量が当該暗号化ピースの全部のデータ量に達した場合に、当該暗号化ピースの送信が完了したと判断する。この場合、セッション情報確認部５２８は、セッション情報更新部５２９を介して、セッション情報記憶テーブルに記憶されているセッション情報に含まれる新規セッション受入フラグを’ON’に設定する。
【０１４７】
セッション情報更新部５２９は、セッション情報確認部５２８の判断に応じて、新規セッション受入フラグを’ON’又は’OFF’に設定する。
【０１４８】
次に、本変形例にかかるシーダ５２が行う優先ピースインデックス選定処理及び暗号化ピース送信処理について図３４を用いて説明する。ステップＳ２０〜Ｓ２１の処理は上述の第１の実施の形態と同様である。シーダ５２はリーチャ５０からピース要求を受信した場合（ステップＳ２１：ＹＥＳ）、ここでは、以下のようにして暗号化ピース送信処理を行う。まず、ステップＳ４０では、シーダ５２は、リーチャ５０からのピース要求が新規ピース要求であるか否かを判断する。ピース要求が例えば図３２に例示されるデータ構成の継続ピース要求であり、新規ピース要求フラグが‘OFF’に設定されている場合、ステップＳ４０の判断結果は否定的となり、ステップＳ４５に進む。ステップＳ４５では、シーダ５２は、セッション情報記憶テーブルにおいて当該リーチャ５０のリーチャ識別情報と対応付けられて記憶されているセッション情報を参照し、受信した継続ピース要求に含まれるピースインデックス及びバリエーションインデックスと、セッション情報に含まれるピースインデックス及びバリエーションインデックスとが等しいことを確認する。その確認後、シーダ５２は、セッション情報に含まれる送信データ量と継続ピース要求に含まれる要求データ開始位置との間で整合がとれているかを確認する確認処理を行う（ステップＳ４６）。これらの間で整合がとれていない場合、確認処理は失敗であるとする。また、要求データ開始位置が「０」である場合も、確認処理は失敗であるとする。即ち、要求データ開始位置が「０」である継続ピース要求を排除することで、特定のピースインデックス及びバリエーションインデックスに対応する暗号化ピースをその先頭位置から集めようとするリーチャ５０の行為を排除できる。また、ここで排除する要求データ開始位置の閾値を「０」より大きくしても良く、この場合、上述のリーチャ５０の行為をより困難にすることができる。
【０１４９】
さて、上述の確認処理が成功した場合には（ステップＳ４６：ＹＥＳ）、シーダ５２は、当該リーチャ５０がデータの一部を取得済みである暗号化ピースの残り部分が要求されていると判断し、ステップＳ２６に進む。ステップＳ２６では、シーダ５２は、ステップＳ２１で受信したピース要求に含まれるピースインデックス、バリエーションインデックス、データ開始位置及び取得希望データ長に応じた暗号化ピースのデータを外部記憶装置から読み出してこれをリーチャ５０に送信する。尚、上述の確認処理が失敗した場合には（ステップＳ４６：ＮＯ）、シーダ５２は、ステップＳ２１で受信したピース要求を破棄して、ステップＳ２１に戻り、次のピース要求を待ち受ける。ここで、シーダ５２は、暗号化ピースの提供を行わないことをリーチャ５０に通知しても良いし、しなくても良い。
【０１５０】
ステップＳ２６の後、ステップＳ４２では、シーダ５２は、セッション情報記憶テーブルにおいて当該リーチャ５０のリーチャ識別情報と対応付けて記憶されたセッション情報において、ステップＳ２６で送信した暗号化ピースのピースインデックス、バリエーションインデックスに対応する送信済データ量を算出してこれを更新する。その後、シーダ５２は、ステップＳ２６において送信した暗号化ピースの送信が完了したか否かを判断する（ステップＳ４３）。シーダ５２は、ステップＳ２６で送信した暗号化ピースの送信済データ量が当該暗号化ピースの全部のデータ量に達した場合に、当該暗号化ピースの送信が完了したと判断する。この場合（ステップＳ４３：ＹＥＳ）、シーダ５２は、上述の実施の形態と同様にして、送信状況テーブル更新処理を行う。また、シーダ５２は、セッション情報記憶テーブルにおいて当該リーチャ５０のリーチャ識別情報と対応付けられて記憶されているセッション情報に含まれる新規セッション受入フラグを’ON’に設定する。そして、ステップＳ２１に戻り、シーダ５２は、次のピース要求を待ち受ける。
【０１５１】
一方、ステップＳ４０で、シーダ５２は、ピース要求が図３３に例示されるようなデータ構成の新規ピース要求であり、新規ピース要求が‘ON’に設定されている場合、ここでの判断結果は肯定的となり、ステップＳ４１に進む。ステップＳ４１では、シーダ５２は、セッション情報記憶テーブルにおいて当該リーチャ５０のリーチャ識別情報と対応付けられて記憶されているセッション情報に含まれる新規セッション受入フラグを参照して、当該ピース要求を受け入れるか否かを判断する。新規セッション受入フラグが‘ON’に設定されている場合、シーダ５２は、当該新規ピース要求を受け入れ、新規セッション受入フラグを’OFF’に設定して、ステップＳ２２に進む。以降ステップＳ２３〜Ｓ２６の処理は上述の実施の形態と同様である。ステップＳ２６では、シーダ５２は、ステップＳ２２で決定したピースインデックスjと、ステップＳ２４で決定したバリエーションインデックスiとの組からなるインデックス(i,j)に対応する暗号化ピースについて、ステップＳ２１で受信した新規ピース要求に含まれる取得希望データ量を有するデータを外部記憶装置から読み出してこれをリーチャ５０に送信する。その後、シーダ５２は、上述と同様にしてステップＳ４２以降の処理を行う。
【０１５２】
以上のような構成によれば、暗号化ピースのデータ量が多い場合であっても複数回に分けて効果的に暗号化ピースの送受信が可能となる。
【０１５３】
尚、上述においては、図３２〜３３に例示するような新規ピース要求フラグを用いて、受信されたピース要求が新規ピース要求であるか否かをシーダ５２は判断するようにした。しかし、これに限らず、シーダ５２は、例えば、図３３に示されるピース要求に含まれるバリエーションインデックスを参照して、この値が所定の特殊な値であるか否かを判断することにより、受信されたピース要求が新規ピース要求であるか否かを判断するようにしても良い。
【０１５４】
また、本変形例を実施する場合、ピース要求の受信処理と、暗号化ピースの送信処理とが別のスレッドとしてそれぞれ実行される場合がある。この場合、暗号化ピースの送信処理であるステップＳ２６の終了を待っていると、セッション情報を更新する処理であるステップＳ４２や、新規セッション受入れフラグを‘OFF’に設定する処理であるステップＳ４４や、送信状況テーブル更新処理であるステップＳ２７などの各処理の実施に時間を要し、その結果、リーチャからの適切な新規ピース要求を受け入れないなどの事態が生じる可能性がある。そのため、ステップＳ４３やステップＳ４２やステップＳ４４やステップＳ２７などの処理を、暗号化ピースの送信処理であるステップＳ２６の前に実施するようにしても良い。この場合、ステップＳ４３において、暗号化ピースの送信が完了したか否かの判断は、ピース要求に含まれるセッション情報を基にして行えば良い。
【図面の簡単な説明】
【０１５５】
【図１】第１の実施の形態にかかるコンテンツ配信システムの構成を示すブロック図である。
【図２】コンテンツが複数のピースに分割された状態を模式的に示す図である。
【図３】各暗号化ピースを模式的に示す図である。
【図４】シーダ５２Ａが記憶している各暗号化ピースを例示する図である。
【図５】シーダ５２Ａが記憶している各暗号化ピースを例示する図である。
【図６】シーダ５２Ａが記憶している各暗号化ピースを例示する図である。
【図７】シーダ５２の機能的構成を例示する図である。
【図８】ピース情報のデータ構成を例示する図である。
【図９】送信状況テーブルのデータ構成を例示する図である。
【図１０】リーチャ５０の機能的構成を例示する図である。
【図１１】Torrent Fileを例示する図である。
【図１２】鍵サーバ５３の機能的構成を例示する図である。
【図１３】ノード情報のデータ構成を例示する図である。
【図１４】コンテンツ配信処理の手順を示すフローチャートである。
【図１５】優先ピースインデックス選定処理及び暗号化ピース送信処理の手順を示すフローチャートである。
【図１６】優先ピースインデックス選定処理の詳細な手順を示すフローチャートである。
【図１７】バリエーションインデックス決定処理の手順を示すフローチャートである。
【図１８】送信状況テーブル更新処理の手順を示すフローチャートである。
【図１９】照合処理の手順を示すフローチャートである。
【図２０】同実施の形態の一変形例にかかるTorrent Fileのデータ構成を例示する図である。
【図２１】同実施の形態の一変形例にかかるハッシュ値を含むインデックス情報を例示する図である。
【図２２】同実施の形態の一変形例にかかる送信状況テーブル更新処理の手順を示すフローチャートである。
【図２３】同実施の形態の一変形例にかかるピース要求のデータ構成を例示する図である。
【図２４】第２の実施の形態にかかるシーダ５２の機能的構成を例示する図である。
【図２５】送信状況テーブルのデータ構成を例示する図である。
【図２６】優先ピースインデックス選定処理及び暗号化ピース送信処理の手順を示すフローチャートである。
【図２７】送出済フラグ照会処理の手順を示すフローチャートである。
【図２８】バリエーションインデックス決定処理の手順を示すフローチャートである。
【図２９】送信状況テーブル更新処理の手順を示すフローチャートである。
【図３０】同実施の形態の一変形例にかかる送信状況テーブルを示す図である。
【図３１】同実施の形態の一変形例にかかるシーダ５２の機能的構成を例示する図である。
【図３２】同変形例にかかる継続ピース要求のデータ構成を例示する図である。
【図３３】同変形例にかかる新規ピース要求のデータ構成を例示する図である。
【図３４】同変形例にかかる優先ピースインデックス選定処理及び暗号化ピース送信処理の手順を示すフローチャートである。
【符号の説明】
【０１５６】
５０，５０Ａ，５０Ｂ  リーチャ（通信装置）
５１  トラッカ（管理サーバ）
５２，５２Ａ，５２Ｂ，５２Ｃ  シーダ（通信装置）
５３  鍵サーバ
５４  販売サーバ
５００  コンテンツ取得部
５０１  鍵束要求部
５０２  鍵束取得部
５０３  コンテンツ復号部
５２０  ピース情報送信部
５２１  ピース要求受信部（受信手段）
５２２  優先ピースインデックス選定部（選定手段、記憶制御手段）
５２３  ピースインデックス決定部（第１決定手段）
５２４  バリエーションインデックス決定部（第２決定手段）
５２５  送信状況テーブル更新部（第１更新手段、第２更新手段、記憶制御手段）
５２６  ピース送信部（送信手段）
５２７  送出済フラグ照会部（照会手段）
５２８  セッション情報確認部（確認手段）
５２９  セッション情報更新部（第３更新手段）
５３０  制御部
５３１  パケット処理部
５３２  ネットワークインターフェース部
５３３  認証・鍵交換処理部
５３４  鍵記憶部
５３５  シーケンス情報照合部
５３６  シーケンス情報記憶部
５３７  鍵供給部
５３８  暗号処理部
ＮＴ  Ｐ２Ｐネットワーク
【図１】
0005208549.tif 000002
【図２】
0005208549.tif 000003
【図３】
0005208549.tif 000004
【図４】
0005208549.tif 000005
【図５】
0005208549.tif 000006
【図６】
0005208549.tif 000007
【図７】
0005208549.tif 000008
【図８】
0005208549.tif 000009
【図９】
0005208549.tif 000010
【図１０】
0005208549.tif 000011
【図１１】
0005208549.tif 000012
【図１２】
0005208549.tif 000013
【図１３】
0005208549.tif 000014
【図１４】
0005208549.tif 000015
【図１５】
0005208549.tif 000016
【図１６】
0005208549.tif 000017
【図１７】
0005208549.tif 000018
【図１８】
0005208549.tif 000019
【図１９】
0005208549.tif 000020
【図２０】
0005208549.tif 000021
【図２１】
0005208549.tif 000022
【図２２】
0005208549.tif 000023
【図２３】
0005208549.tif 000024
【図２４】
0005208549.tif 000025
【図２５】
0005208549.tif 000026
【図２６】
0005208549.tif 000027
【図２７】
0005208549.tif 000028
【図２８】
0005208549.tif 000029
【図２９】
0005208549.tif 000030
【図３０】
0005208549.tif 000031
【図３１】
0005208549.tif 000032
【図３２】
0005208549.tif 000033
【図３３】
0005208549.tif 000034
【図３４】
0005208549.tif 000035