(57)【特許請求の範囲】
【請求項１】
ピアツーピア（以下、Ｐ２Ｐ）ネットワークに接続され、このＰ２Ｐネットワークを構成する他の複数のＰ２Ｐ端末との間で、カラオケ端末で実行されるコンテンツに関するキャッシュファイルを相互に授受すると共に、ローカルネットワークに接続され、このローカルネットワークを構成する複数のカラオケ端末に対して、自らが保有する前記キャッシュファイル又は前記Ｐ２Ｐネットワークにおいて他のＰ２Ｐ端末から取得した前記キャッシュファイルを配信するＰ２Ｐ端末であって、
前記Ｐ２Ｐネットワークにおいて他のＰ２Ｐ端末へ送信するキャッシュファイルを格納するためのキャッシュ手段と、
前記キャッシュ手段に現に格納されているキャッシュファイルの一覧であるキャッシュファイルリストを記憶するリスト記憶手段と、
前記キャッシュ手段の不具合を検知する検知手段と、
前記検知手段により前記キャッシュ手段の不具合を検知した場合、前記ローカルネットワークを構成する複数の前記カラオケ端末の中からマウント対象となるカラオケ端末を選定するマウント先選定手段と、
前記マウント先選定手段により選定したマウント対象のカラオケ端末が備える記憶手段の特定領域を、自Ｐ２Ｐ端末の前記キャッシュ手段として代用可能な状態にマウントするマウント手段と、
前記検知手段により前記キャッシュ手段の不具合が検知された場合、前記リスト記憶手段におけるキャッシュファイルリストに記されたキャッシュファイルを保有する前記カラオケ端末及び前記他のＰ２Ｐ端末を特定して、その中から最もファイルの取得速度が速い端末を取得先端末として選定し、その選定した取得先端末から前記キャッシュファイルリストに記載のキャッシュファイルを取得して前記マウント手段によりマウントした特定領域に記録するキャッシュ復元手段とを備え、
そして、前記キャッシュ復元手段によりキャッシュファイルが復元された前記特定領域を、前記キャッシュ手段として代用すること
を特徴とするＰ２Ｐ端末。
【請求項２】
請求項１に記載のＰ２Ｐ端末において、
前記マウント先選定手段は、前記ローカルネットワークを構成する複数のカラオケ端末について、それぞれの記憶手段の空き容量を比較し、前記記憶手段の空き容量が大きい前記カラオケ端末を優先して前記マウント対象に選定すること
を特徴とするＰ２Ｐ端末。
【請求項３】
請求項１又は請求項２に記載のＰ２Ｐ端末において、
前記マウント先選定手段は、前記ローカルネットワークを構成する複数のカラオケ端末について、キャッシュファイルの復元処理の速さに関する所定の指標を比較し、キャッシュファイルの復元処理の速い前記カラオケ端末を優先して前記マウント対象に選定すること
を特徴とするＰ２Ｐ端末。
【請求項４】
請求項１ないし請求項３の何れか１項に記載のＰ２Ｐ端末において、
前記キャッシュ復元手段は、前記ローカルネットワークを構成するカラオケ端末からキャッシュファイルの配信要求を受けている場合、その配信要求に該当のキャッシュファイルを保有する前記取得先端末を選定し、その選定した取得先端末から当該配信要求に該当のキャッシュファイルを優先して取得すること
を特徴とするＰ２Ｐ端末。
【請求項５】
請求項１ないし請求項４の何れか１項に記載のＰ２Ｐ端末において、
前記キャッシュ復元手段は、前記取得先端末を選定する事前に、前記ローカルネットワークを構成する複数のカラオケ端末におけるキャッシュファイルの保有状況を取得し、その取得した保有状況に基づいて前記取得先端末を選定すること
を特徴とするＰ２Ｐ端末。
【請求項６】
ピアツーピア（以下、Ｐ２Ｐ）ネットワークを構成し、カラオケ端末で実行されるコンテンツに関するキャッシュファイルを相互に授受する複数のＰ２Ｐ端末と、
前記複数のＰ２Ｐ端末の各々が１つ又は複数単位で接続された複数のローカルネットワークを構成する複数のカラオケ端末とを有し、
前記Ｐ２Ｐ端末の各々は、自Ｐ２Ｐ端末が接続する前記ローカルネットワークを構成する複数の前記カラオケ端末に対して、自らが保有する前記キャッシュファイル又は前記Ｐ２Ｐネットワークにおいて他のＰ２Ｐ端末から取得した前記キャッシュファイルを配信するコンテンツ配信システムであって、
前記Ｐ２Ｐ端末の各々は、
前記Ｐ２Ｐネットワークにおいて他のＰ２Ｐ端末へ送信するキャッシュファイルを格納するためのキャッシュ手段と、
前記キャッシュ手段に現に格納されているキャッシュファイルの一覧であるキャッシュファイルリストを記憶するリスト記憶手段と、
前記キャッシュ手段の不具合を検知する検知手段と、
前記検知手段により前記キャッシュ手段の不具合を検知した場合、自Ｐ２Ｐ端末が接続しているローカルネットワークを構成する複数の前記カラオケ端末の中からマウント対象となるカラオケ端末を選定するマウント先選定手段と、
前記マウント先選定手段により選定したマウント対象のカラオケ端末が備える記憶手段の特定領域を、自Ｐ２Ｐ端末の前記キャッシュ手段として代用可能な状態にマウントするマウント手段と、
前記検知手段により前記キャッシュ手段の不具合が検知された場合、前記リスト記憶手段におけるキャッシュファイルリストに記されたキャッシュファイルを保有する前記カラオケ端末及び前記他のＰ２Ｐ端末を特定して、その中から最もファイルの取得速度が速い端末を取得先端末として選定し、その選定した取得先端末から前記キャッシュファイルリストに記載のキャッシュファイルを取得して前記マウント手段によりマウントした特定領域に記録するキャッシュ復元手段とを備え、
そして、前記キャッシュ復元手段によりキャッシュファイルが復元された前記特定領域を、前記キャッシュ手段として代用すること
を特徴とするコンテンツ配信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを介して相互に接続された複数の端末装置間でピアツーピア（Peer to Peer（Ｐ２Ｐ））型のコンテンツ配信を行う技術に関する。
【背景技術】
【０００２】
近年、ネットワークを介して相互に接続された複数の端末同士でデータを共有するＰ２Ｐ方式のコンテンツ配信システムが実用化している（例えば、特許文献１参照）。このようなＰ２Ｐ方式のコンテンツ配信システムによれば、コンテンツを配給するセンタサーバの負荷を軽減し、システムの運用・保守にかかるコストを低減できるとされている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００６−１９７４００号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ところで、カラオケサービスを提供するカラオケ端末は、利用客からのサービス要求に応じて楽曲データの再生や、歌詞字幕の表示及び色変わり、背景動画の表示等の処理を行っている。また、通信カラオケにおいては、そうしたカラオケサービスの提供の他に、最新楽曲やオンデマンドによるコンテンツのダウンロードも並行して行わなければならない。
【０００５】
こうしたカラオケ端末にＰ２Ｐ方式のコンテンツ配信機能を搭載する問題として、ＣＰＵの処理負荷の増大による処理の遅延が挙げられる。それは、Ｐ２Ｐ方式のコンテンツ配信においては、クライアントサーバ方式と異なり、１つの端末がコンテンツの受信（ダウンロード）だけでなく他の端末へのコンテンツ送信(アップロード)も同時に行わなければならないからである。かといって、各端末がカラオケサービスの提供を優先したがためにアップロードを停止してしまえば、他の端末はコンテンツを取得することができなくなり、Ｐ２Ｐ方式のコンテンツ配信システムとしては破綻してしまうだろうし、利用者に迅速なオンデマンドサービスを提供できなくなってしまう。
【０００６】
こうしたカラオケサービス特有の問題を回避するため、カラオケサービスを提供するカラオケ端末とは別に、Ｐ２Ｐネットワークに接続してコンテンツ交換（コンテンツを他の端末にアップロードしたり、他の端末からダウンロード）するためのデータを記憶する補助記憶手段（以下、キャッシュ領域）を備えたＰ２Ｐ端末を設け、これらをローカルネットワーク（例えば、カラオケ店舗内に敷設されたＬＡＮ）によって相互に接続する構成が考案されている。このように構成されたシステムでは、カラオケ端末はローカルネットワークを介してＰ２Ｐ端末対して必要なコンテンツを要求し、Ｐ２Ｐ端末はＰ２Ｐネットワークを介して取得した要求コンテンツをキャッシュ領域に一時記憶してカラオケ端末に配信したり、Ｐ２Ｐネットワーク側の他のＰ２Ｐ端末との間で、キャッシュ領域を介してコンテンツを共有するようになっている。このようにして、Ｐ２Ｐネットワーク間でのコンテンツの送受信に係る処理をＰ２Ｐ端末に代表して負担させることで、カラオケ端末の処理負荷が軽減し、カラオケサービスを安定して提供することができる。
【０００７】
しかしながら、このようなＰ２Ｐ端末を用いたコンテンツ配信システムにおいて問題となるのが、Ｐ２Ｐ端末内でコンテンツのキャッシュ領域が何らかの不具合により使用不可能になる場合である。各Ｐ２Ｐ端末で持ち合っているコンテンツの保存場所であるキャッシュ領域が使用不能となれば、そのキャッシュ領域に格納されていたコンテンツのデータは失われ、他のＰ２Ｐ端末に対するアップロードが不可能となる。そうした端末が増えれば、コンテンツの配信に遅延を招くおそれがあり、そのような事態が更に悪化し、Ｐ２Ｐ端末間でのコンテンツの送受信に支障を来すことになれば、カラオケサービスにとって致命的である。
【０００８】
特にカラオケサービスでは、大量のコンテンツ提供が必要となる為、比較的安価で大容量の記憶媒体であるハードディスクドライブ（ＨＤＤ）がＰ２Ｐ端末のキャッシュ領域としてよく使用されるが、機械的な駆動機構が多用されるＨＤＤは過熱や衝撃に弱く、故障してしまうことも少なくない。
【０００９】
本発明は、このような問題を解決するためになされたものであり、Ｐ２Ｐ方式のコンテンツ配信システムを構成するＰ２Ｐ端末のキャッシュ領域に不具合が生じた場合に、速やかにキャッシュ領域を復元してコンテンツの送信機能を回復できるようにするための技術を提供することを目的とする。
【課題を解決するための手段】
【００１０】
上記目的を達成するためになされた請求項１に記載のＰ２Ｐ端末は、Ｐ２Ｐネットワークに接続され、このＰ２Ｐネットワークを構成する他の複数のＰ２Ｐ端末との間で、カラオケ端末で実行されるコンテンツに関するキャッシュファイルを相互に授受する。それと共に、ローカルネットワークに接続され、このローカルネットワークを構成する複数のカラオケ端末に対して、自らが保有する前記キャッシュファイル又は前記Ｐ２Ｐネットワークにおいて他のＰ２Ｐ端末から取得した前記キャッシュファイルを配信する。
【００１１】
加えて、本発明のＰ２Ｐ端末は、キャッシュ手段、リスト記憶手段、検知手段、マウント先選定手段、マウント手段、キャッシュ復元手段を備える。キャッシュ手段は、Ｐ２Ｐネットワークにおいて他のＰ２Ｐ端末へ送信するキャッシュファイルを格納するためのものである。リスト記憶手段は、キャッシュ手段に現に格納されているキャッシュファイルの一覧であるキャッシュファイルリストを記憶するものである。検知手段は、キャッシュ手段の不具合を検知するためのものである。
【００１２】
マウント先選定手段は、検知手段によりキャッシュ手段の不具合を検知した場合、ローカルネットワークを構成する複数のカラオケ端末の中からマウント対象となるカラオケ端末を選定する。マウント手段は、マウント先選定手段により選定したマウント対象のカラオケ端末が備える記憶手段の特定領域を、自Ｐ２Ｐ端末のキャッシュ手段として代用可能な状態にマウントする。ここでいうマウントとは、Ｐ２Ｐ端末がカラオケ端末が備える記憶手段を自身のファイルシステムとして認識し、操作可能にするための手続きを指す。
【００１３】
キャッシュ復元手段は、検知手段によりキャッシュ手段の不具合が検知された場合、まず、リスト記憶手段におけるキャッシュファイルリストに記されたキャッシュファイルを保有するカラオケ端末及び他のＰ２Ｐ端末を特定する。そして、その中から最もファイルの取得速度が速い端末を取得先端末として選定し、その選定した取得先端末からキャッシュファイルリストに記載のキャッシュファイルを取得してマウント手段によりマウントした特定領域に記録する。そして、Ｐ２Ｐ端末は、キャッシュ復元手段によりキャッシュファイルが復元された特定領域を、キャッシュ手段として代用する。
【００１４】
このように構成されたＰ２Ｐ端末によれば、万一、ＨＤＤが故障するなどしてキャッシュ手段が使用不能になった場合でも、ローカルネットワークを介して接続しているカラオケ端末の記憶手段をキャッシュ手段として代用でき、キャッシュファイルのアップロードを継続できる。さらに、キャッシュファイルリストに基づいて、破損前のキャッシュファイルをキャッシュ手段の代用としてマウントされた記憶領域に復元できる。これにより、Ｐ２Ｐネットワークを構成する端末間において共有の管理情報を変更することなく、破損前と同等のキャッシュファイルを他のＰ２Ｐ端末へアップロード可能である。
【００１５】
また、復元するキャッシュファイルの取得先を、ローカルネットワーク経由でカラオケ端末から取得するか、あるいはＰ２Ｐネットワーク経由で他のＰ２Ｐ端末から取得するか、そのときの取得速度（例えば、通信速度）が最も早い端末から選定することで、速やかにキャッシュファイルを復元し、キャッシュファイルのアップロード機能を迅速に回復できる。
【００１６】
つぎに、請求項２に記載のＰ２Ｐ端末は次のような特徴を有する。すなわち、マウント先選定手段は、ローカルネットワークを構成する複数のカラオケ端末について、それぞれの記憶手段の空き容量を比較し、記憶手段の空き容量が大きいカラオケ端末を優先してマウント対象に選定する。このように構成することで、複数のカラオケ端末の中から記憶容量に余裕のあるカラオケ端末を優先的にマウント対象に選定することができ、マウント対象のカラオケ端末が持つ記憶資源に対してなるべく負担がかからないようにできる。
【００１７】
つぎに、請求項３に記載のＰ２Ｐ端末は次のような特徴を有する。すなわち、マウント先選定手段は、ローカルネットワークを構成する複数のカラオケ端末について、キャッシュファイルの復元処理の速さに関する所定の指標を比較し、キャッシュファイルの復元処理の速いカラオケ端末を優先してマウント対象に選定する。なお、ここでいうキャッシュファイルの復元処理の速さに関する所定の指標とは、例えば、キャッシュファイルの転送時における通信速度や、カラオケ端末が持つＣＰＵの使用率等が挙げられる。具体的には、通信速度が速ければファイルの転送速度が向上し、キャッシュファイルの復元処理を速やかに完了できる。また、カラオケ端末のＣＰＵの使用率が低ければ、キャッシュファイルの復元処理のためにＣＰＵを占有できる時間を多く確保できるので、キャッシュファイルの復元処理を速やかに完了できる。
【００１８】
このように構成することで、複数のカラオケ端末の中から情報処理能力に余裕のあるカラオケ端末を優先的にマウント対象に選定することができ、キャッシュファイルの復元を迅速に完了できるようにすると共に、マウント対象のカラオケ端末が持つ情報処理能力に対してなるべく負担がかからないようにできる。
【００１９】
ところで、オンデマンドによるコンテンツのダウンロードサービスを提供するカラオケ端末においては、利用客からのリクエストに応じて不定期にコンテンツの配信要求がなされる。このとき、ダウンロード要求先のＰ２Ｐ端末がキャッシュ手段の不具合によりキャッシュファイルを復元中であったとしても、カラオケ端末からの配信要求に係るコンテンツのキャッシュファイルの配信に遅延が生じないようにすることが肝要である。
【００２０】
そこで、請求項４に記載のように構成するとよい。すなわち、キャッシュ復元手段は、ローカルネットワークを構成するカラオケ端末からキャッシュファイルの配信要求を受けている場合、その配信要求に該当のキャッシュファイルを保有する取得先端末を選定し、その選定した取得先端末から当該配信要求に該当のキャッシュファイルを優先して取得する。このように構成することで、破損前の保有状況を記したキャッシュファイルリストの内容に関わらず、カラオケ端末からの配信要求に対応するキャッシュファイルを優先的に取得できる。これにより、キャッシュファイルを復元中であったとしても、カラオケ端末からの配信要求に係るキャッシュファイルの取得に遅延が生じないようにできる。
【００２１】
ところで、復元するキャッシュファイルの取得先を選定する場合には、必要なキャッシュファイルを保有している端末を特定する必要がある。Ｐ２Ｐネットワーク内から必要なキャッシュファイルを保有する端末を探す場合、Ｐ２Ｐネットワーク内でキャッシュファイルの保有状況を示すインデックス情報を共有する周知の仕組みにより、必要なキャッシュファイルを保有する端末を確実に特定できる。
【００２２】
一方、ローカルネットワーク内から必要なキャッシュファイルを保有する端末を探す場合、あるタイミングで各カラオケ端末へ問合せることにより、その時点での保有状況を把握できる。しかしながら、カラオケ端末では、コンテンツを保有するための記憶資源に限りがあるため、製作時期が古いコンテンツや再生リクエストの少ないコンテンツ等に関するキャッシュファイルをカラオケ端末独自の判断により削除する場合がある。そのため、ローカルネットワーク内においてキャッシュファイルの保有状況はその時々で変化している。このような事情により、Ｐ２Ｐ端末側で過去に把握したローカルネットワーク内のキャッシュファイルの保有状況と、実際の保有状況とが必ずしも一致するとは限らない。
【００２３】
このような問題を解決するために、請求項５に記載のように構成するとよい。すなわち、キャッシュ復元手段は、取得先端末を選定する事前に、ローカルネットワークを構成する複数のカラオケ端末におけるキャッシュファイルの保有状況を取得し、その取得した保有状況に基づいて取得先端末を選定する。このように構成することで、復元するキャッシュファイルの取得先を選定する直前においてローカルネットワーク内におけるキャッシュファイルの最新の保有状況を把握でき、必要なキャッシュファイルを保有するカラオケ端末を確実に特定できる。
【００２４】
つぎに、請求項６に記載の発明は、Ｐ２Ｐネットワークを構成し、カラオケ端末で実行されるコンテンツに関するキャッシュファイルを相互に授受する複数のＰ２Ｐ端末と、複数のＰ２Ｐ端末の各々が１つ又は複数単位で接続された複数のローカルネットワークを構成する複数のカラオケ端末とを有するコンテンツ配信システムに関するものである。そして、このコンテンツ配信システムを構成するＰ２Ｐ端末は、請求項１に記載のＰ２Ｐ端末と同様の構成を有する。
【００２５】
このように構成されたコンテンツ配信システムによれば、請求項１に記載のＰ２Ｐ端末に関して上述した効果を得られると共に、Ｐ２Ｐ端末のＨＤＤの破損といった不具合に対して耐久性のあるコンテンツ配信システムを実現できる。
【図面の簡単な説明】
【００２６】
【図１】実施形態のコンテンツ配信システム１の概略構成を示すブロック図である。
【図２】Ｐ２Ｐ端末３、カラオケ端末４の概略構成を示すブロック図である。
【図３】キャッシュファイルの保有状況を示すリストの一例を示す説明図である。
【図４】キャッシュ領域監視処理のフローチャートである。
【図５】マウント処理、マウント対象選定処理のフローチャートである。
【図６】キャッシュファイル復元処理のフローチャートである。
【図７】ＬＡＮ内保有状況確認処理、取得先選定処理のフローチャートである。
【図８】保有端末応答処理のフローチャートである。
【図９】カラオケ端末４が実施する処理のフローチャートである。
【発明を実施するための形態】
【００２７】
以下、本発明の一実施形態を図面に基づいて説明する。
［コンテンツ配信システム１の構成の説明］
図１に示すように、コンテンツ配信システム１は、利用客にカラオケサービスを提供する複数のカラオケ店舗Ａ，Ｂ，Ｃにそれぞれ敷設された店舗内ネットワークが、広域ネットワークであるＰ２Ｐネットワーク２００を介して相互に接続されることによって形成されている。各カラオケ店舗の店舗内ネットワークは、少なくとも１台のＰ２Ｐ端末３と、通常は複数台のカラオケ端末４とが店舗内に敷設されたＬＡＮ１００を介して相互に接続されている。また、各カラオケ店舗のＰ２Ｐ端末３は、Ｐ２Ｐネットワーク２００を介して相互に接続されている。なお、図１においては、説明の便宜上、３つのカラオケ店舗Ａ，Ｂ，ＣがＰ２Ｐネットワーク２００に接続されている構成を示すが、更に多くのカラオケ店舗が接続されていてもよい。また、各カラオケ店舗において、１台のＰ２Ｐ端末３と、３台のカラオケ端末４とが設置されている構成を示すが、１つの店舗に複数台のＰ２Ｐ端末３が配置されていてもよいし、更に多くのカラオケ端末４が配置されていてもよい。
【００２８】
このコンテンツ配信システム１は、各Ｐ２Ｐ端末３間でカラオケサービスのコンテンツに関するキャッシュファイルを互いに送受信するＰ２Ｐ方式のネットワークシステムと、Ｐ２Ｐ端末３が保有するキャッシュファイルを店舗内のＬＡＮ１００を介してカラオケ端末４へ配信するサーバクライアント型のネットワークシステムとが複合したものである。
【００２９】
Ｐ２Ｐ端末３は、自端末の記憶装置であるハードディスクドライブ（以下、ＨＤＤ）３４に予め確保したキャッシュ領域にコンテンツのキャッシュファイルを保存しておき、他のＰ２Ｐ端末３との間でキャッシュファイルをアップロードしたりダウンロードすることでコンテンツを共有している。それと共に、自Ｐ２Ｐ端末３が属するＬＡＮ１００において隷下にあるカラオケ端末４からキャッシュファイルの配信要求があった場合、他のＰ２Ｐ端末からダウンロードしてキャッシュ領域に保存した要求ファイルを、要求元のカラオケ端末４に対して配信する。また、各Ｐ２Ｐ端末３には、識別情報として広域ネットワークに接続するための固有のグローバルＩＰアドレスが割当てられている。なお、Ｐ２Ｐ端末３で共有するキャッシュファイルは、コンテンツの元データを暗号化したり分割化して機密性を向上させたものであってもよいし、元データのままでもよい。
【００３０】
Ｐ２Ｐ端末３は、ＨＤＤ３４が故障してキャッシュ領域が使用不能になった場合に、隷下のカラオケ端末４のＨＤＤ４４に自端末が利用可能なキャッシュ領域を確保すると共に、故障前にキャッシュ領域に保有していたキャッシュファイルを新たに確保したキャッシュ領域に復元する機能を有する。これらの処理の詳細な内容については後述する。
【００３１】
一方、カラオケ端末４は、Ｐ２Ｐ端末３から取得したキャッシュファイルをＨＤＤ４４に保有しており、このキャッシュファイルに基づいてカラオケコンテンツの再生処理をする情報処理装置である。また、各カラオケ端末４には、識別情報として自装置が属するＬＡＮ１００の範囲内で固有のローカル（又はプライベート）ＩＰアドレスが割当てられている。このカラオケ端末４は、実行するコンテンツのファイルを自ら保有するためのＨＤＤ４４を備えているが、このＨＤＤ４４の記憶容量はコンテンツ配信システム１において流通する全てのコンテンツを保有するには小さいものである。そのため、個々のカラオケ端末４は一部のコンテンツしか保有していない。そのため、カラオケ端末４は、利用者からのリクエストに基づき、自端末が属するＬＡＮ１００内のＰ２Ｐ端末３に対してオンデマンドの配信要求を行い、リクエストされたコンテンツのキャッシュファイルをＰ２Ｐ端末３からダウンロードする。
【００３２】
図２（ａ）は、Ｐ２Ｐ端末３の概略構成を示すブロック図である。Ｐ２Ｐ端末３は、ハードウェア構成としてＣＰＵ３１、ＲＡＭ３２、ＲＯＭ３３、ＨＤＤ３４、Ｐ２Ｐネットワーク通信部３５、ＬＡＮ通信部３６等を備える。
【００３３】
ＣＰＵ３１は、ＲＡＭ３２やＲＯＭ３３に記憶されたプログラムやデータに従って、Ｐ２Ｐ端末３の各部に対する制御及び各種演算を実行する装置で、後述するキャッシュ領域監視処理、保有端末応答処理は、このＣＰＵ３１によって実行される。ＲＡＭ３２はＣＰＵ３１から直接アクセスされるメインメモリとして利用される記憶装置である。後述する保有キャッシュファイルリストやキャッシュファイルの保有端末一覧、ＬＡＮ内のキャッシュファイル保有状況等もここに記憶される。ＲＯＭ３３は、不揮発性の記憶装置であり、ＢＩＯＳや読み出し専用のデータ等を記憶している。ＨＤＤ３４は、プログラムや他のＰ２Ｐ端末３から取得したキャッシュファイル等を保存しておくための記憶装置である。このＨＤＤ３４には、他のＰ２Ｐ端末３との間で送受信するキャッシュファイルを保管しておくためのキャッシュ領域が設けられている。
【００３４】
Ｐ２Ｐネットワーク通信部３５は、Ｐ２Ｐ端末３をＰ２Ｐネットワーク２００に接続して他のＰ２Ｐ端末３との間で通信を行うための通信インタフェースである。ＬＡＮ通信部３６は、Ｐ２Ｐ端末３をＬＡＮ１００に接続して、同一店舗内のＬＡＮ１００に接続された各カラオケ端末４との間で通信を行うための通信インタフェースである。
【００３５】
一方、図２（ｂ）は、カラオケ端末４の概略構成を示すブロック図である。カラオケ端末４は、ハードウェア構成としてＣＰＵ４１、ＲＡＭ４２、ＲＯＭ４３、ＨＤＤ４４、操作部４５、再生部４６、入力部４７、ＬＡＮ通信部４８等を備える。
【００３６】
ＣＰＵ４１は、ＲＡＭ４２やＲＯＭ４３に記憶されたプログラムやデータに従ってカラオケ端末４各部に対する制御及び各種演算を行う装置で、後述するＨＤＤ情報送信処理、マウント要求応答処理、保有状況応答処理は、このＣＰＵ４１によって実行される。ＲＡＭ４２は、ＣＰＵ４１から直接アクセスされるメインメモリとして利用される記憶装置である。ＲＯＭ４３は、不揮発性の記憶装置でありＢＩＯＳや読み出し専用のデータ等を記憶している。ＨＤＤ４４は、カラオケ用の楽曲や映像等のコンテンツやプログラム等の各種データを保存しておくための装置である。操作部４５は、ユーザからの各種指示を入力するための入力装置であり、複数のキースイッチ等によって構成される。
【００３７】
再生部４６は、演奏データに基づく演奏再生をおこなうＭＩＤＩ音源、ＭＩＤＩ音源から再生されたオーディオ信号及び入力部４７から入力された音声信号をスピーカへ出力する音声制御部、画像データに基づく映像の再生を制御する映像再生部、映像を表示するためのモニタ等を備える。入力部４７は、マイクロフォンによって歌唱者の歌唱音声を音声信号に変換し、再生部４６へ入力するためのものである。ＬＡＮ通信部４８は、カラオケ端末４をＬＡＮ１００に接続して、同一店舗内のＬＡＮ１００に接続されたＰ２Ｐ端末３や他のカラオケ端末４との間で通信を行うための通信インタフェースである。
【００３８】
［各種リストの説明］
図３（ａ）は、各Ｐ２Ｐ端末３が記憶管理している保有キャッシュファイルリストの一例である。この保有キャッシュファイルリストは、自Ｐ２Ｐ端末３がキャッシュ領域に現に保有しているキャッシュファイルの一覧であり、Ｐ２Ｐ端末３のＲＡＭ３２に記憶されている。
【００３９】
図３（ａ）に示すとおり、Ｐ２Ｐ端末３の保有キャッシュファイルリストには、自己のグローバルＩＰアドレスに対応付けて、現在保有しているキャッシュファイルの一覧が記述されている。キャッシュファイルの一覧には、ファイルを取得（ダウンロード）した時期（例えば年月日）や、取得先のＰ２Ｐ端末３のグローバルＩＰアドレスがファイル名ごとに記述されている。この保有キャッシュファイルリストは、他のＰ２Ｐ端末３からキャッシュファイルを新たに取得したときには、ＣＰＵ３１によってそのキャッシュファイルのレコードが追加されるようになっている。また、保有しているキャッシュファイルをキャッシュ領域から消去したときには、ＣＰＵ３１によってその消去したキャッシュファイルのレコードが削除されるようになっている。
【００４０】
図３（ｂ）は、各Ｐ２Ｐ端末３が記憶管理しているキャッシュファイルの保有端末一覧の一例である。この保有端末一覧は、どのキャッシュファイルをどのＰ２Ｐ端末３が保有しているのかを示す一覧であり、Ｐ２Ｐ端末３のＲＡＭ３２に記憶されている。
【００４１】
図３（ｂ）に示すとおり、キャッシュファイルの保有端末一覧には、自己のグローバルＩＰアドレスに対応付けて、キャッシュファイル名ごとにそのキャッシュファイルを保有しているＰ２Ｐ端末３のグローバルＩＰアドレスの一覧が記述されている。この保有端末一覧は、ＣＰＵ３１による情報収集や、Ｐ２Ｐ端末３同士の情報交換等により取得した保有状況に基づいて更新される。なお、この保有端末一覧では、１台のＰ２Ｐ端末３において全てのキャッシュファイルの保有状況が網羅されているわけではなく、複数のＰ２Ｐ端末３の間で分担して全ての保有状況を網羅するようになっている。よって、自己が記憶している保有端末一覧に網羅されていないキャッシュファイルの保有端末を特定する場合、Ｐ２Ｐネットワーク２００を介して他のＰ２Ｐ端末３に問合せることで特定可能である。
【００４２】
図３（ｃ）は、各カラオケ端末４が記憶管理している保有キャッシュファイルリストの一例である。この保有キャッシュファイルリストは、自カラオケ端末４がＨＤＤ４４に保有しているキャッシュファイルの一覧であり、カラオケ端末４のＲＡＭ４２やＨＤＤ４４等に記憶されている。
【００４３】
図３（ｃ）に示すとおり、カラオケ端末４の保有キャッシュファイルリストには、自己のローカルＩＰアドレスに対応付けて、現在保有しているキャッシュファイルの一覧が記述されている。キャッシュファイルの一覧には、ファイルを取得した時期（例えば年月日）や、取得先のＰ２Ｐ端末３のグローバルＩＰアドレスがファイル名ごとに記述されている。この保有キャッシュファイルリストは、同一店舗内のＰ２Ｐ端末３からキャッシュファイルを取得したときには、ＣＰＵ４１によってその取得したキャッシュファイルのレコードが追加されるようになっている。また、保有しているキャッシュファイルをＨＤＤ４４から消去したときには、ＣＰＵ４１によってその消去したキャッシュファイルのレコードが削除されるようになっている。
【００４４】
なお、各カラオケ店舗のＰ２Ｐ端末３は、同一店舗内のＬＡＮ１００に接続している全てのカラオケ端末４の保有キャッシュファイルリストをＲＡＭ３２に記憶している。ただし、カラオケ端末４では、製作時期が古いコンテンツや再生リクエストの少ないコンテンツ等に関するキャッシュファイルをカラオケ端末４独自の判断により削除する場合がある。そのため、Ｐ２Ｐ端末３側で過去に把握したカラオケ端末４のキャッシュファイルの保有状況と、実際の保有状況とが必ずしも一致するとは限らない。
【００４５】
［１．Ｐ２Ｐ端末３が実行する処理の説明］
（１−１．キャッシュ領域監視処理）
Ｐ２Ｐ端末３のＣＰＵ３１が実行するキャッシュ領域監視処理の手順について図４のフローチャートを参照しながら説明する。この処理は、Ｐ２Ｐ端末３の稼働中において所定時間ごとに繰返し実行される処理である。
【００４６】
Ｐ２Ｐ端末３のＣＰＵ３１は、まず、ＨＤＤ３４のキャッシュ領域に対するリード・ライトを試みることで、キャッシュ領域を検査する（Ｓ１００）。検査の結果、キャッシュ領域の破損を検知したか否かを判定する（Ｓ１０１）。
【００４７】
Ｓ１０１で、キャッシュ領域に破損がない、すなわちキャッシュ領域に対するアクセスが正常に機能すると判定した場合（Ｓ１０１：ＮＯ）、本処理を終了する。一方、キャッシュ領域に破損がある、すなわちキャッシュ領域に対するアクセスが正常に機能しないと判定した場合（Ｓ１０１：ＹＥＳ）、Ｓ１０２においてマウント処理を実行する。Ｓ１０２のマウント処理では、ＬＡＮ１００に接続している隷下のカラオケ端末４の中からマウント対象となる端末を選定し、このマウント対象のカラオケ端末４が備えるＨＤＤ４４の特定領域を、自Ｐ２Ｐ端末３のキャッシュ領域として代用可能な状態にマウントする（詳細な手順については後述する）。
【００４８】
つぎに、Ｓ１０３においてキャッシュファイル復元処理を実行する。このキャッシュファイル復元処理では、Ｓ１０２においてマウントした代用のキャッシュ領域に、破損したキャッシュ領域に従前まで記憶されていたキャッシュファイルを復元する（詳細な手順については後述する）。
【００４９】
（１−２．マウント処理）
上述のキャッシュ領域監視処理（図４参照）のＳ１０２でＣＰＵ３１が実行するマウント処理の手順について図５（ａ）のフローチャートを参照しながら説明する。
【００５０】
まず、Ｓ２００では、ＬＡＮ１００内にブロードキャストでＨＤＤ情報送信要求を発信する。このＨＤＤ情報送信要求は、各カラオケ端末４に対して、代用のキャッシュ領域として提供可能なＨＤＤ４４の空き容量を示すＨＤＤ情報の送信を要求するメッセージである。つぎに、Ｓ２０１では、各カラオケ端末４から通知されたＨＤＤ情報に基づき、マウント対象選定処理を実行する。このマウント対象選定処理では、ＬＡＮ１００に接続している複数のカラオケ端末４の中から、代用のキャッシュ領域をマウントする対象となる端末を選択する（詳細な手順については後述する）。
【００５１】
つぎに、Ｓ２０２では、Ｓ２０１で選定したマウント対象のカラオケ端末４が備えるＨＤＤ４４の特定領域を、自身のファイルシステムにおいて利用可能なキャッシュ領域としてマウントする。ここでいうマウントとは、Ｐ２Ｐ端末３がカラオケ端末４のＨＤＤ４４の特定領域を自身のファイルシステムとして認識し、操作可能にするための手続きを指す。本実施形態では、ＮＦＳ（Network File System）に実装されている周知のマウント機能を用いる。具体的には、Ｐ２Ｐ端末３側から、マウント対象のカラオケ端末４に対してキャッシュ領域のマウント要求を通知する。これに対し、マウント対象のカラオケ端末４は、キャッシュ領域として提供するＨＤＤの特定領域（マウント領域）を要求元のＰ２Ｐ端末３へ通知し、マウントを受付ける。この一連の手続きにより、代用のキャッシュ領域のマウントが成立する。
【００５２】
（１−３．マウント対象選定処理、第１実施形態）
上述のマウント処理（図５（ａ）参照）のＳ２０１でＣＰＵ３１が実行するマウント対象選定処理の第１実施形態の手順について図５（ｂ）のフローチャートを参照しながら説明する。
【００５３】
まず、Ｓ３００では、各カラオケ端末４から、ＨＤＤ情報を受信する。このＨＤＤ情報には、送信元のカラオケ端末４の識別情報（ローカルＩＰアドレス）及び、代用のキャッシュ領域として提供可能なＨＤＤ４４の空き容量を示す情報が含まれる。つぎに、Ｓ３０２では、受信したＨＤＤ情報に基づいて各カラオケ端末４のＨＤＤ４４の空き容量を比較し、空き容量が最大のカラオケ端末４をマウント対象に選定する。
【００５４】
（１−４．マウント対象選定処理、第２実施形態）
上述のマウント処理（図５（ａ）参照）のＳ２０１でＣＰＵ３１が実行するマウント対象選定処理の第２実施形態の手順について図５（ｃ）のフローチャートを参照しながら説明する。
【００５５】
まず、Ｓ３０１では、ＬＡＮ１００に接続している各カラオケ端末４との間の通信速度をそれぞれ測定する。測定方法の一例としては、各カラオケ端末４に対してｐｉｎｇコマンドを送信し、各カラオケ端末４から返信されるまでの所要時間を測定して、この通信時間とｐｉｎｇコマンドのデータサイズとから、各カラオケ端末４の通信速度を算出する。
【００５６】
つぎに、Ｓ３０３では、Ｓ３０１での測定結果に基づいて各カラオケ端末４の通信速度を比較し、通信速度が最大のカラオケ端末４をマウント対象に選定する。
（１−５．キャッシュファイル復元処理）
上述のキャッシュ領域監視処理（図４参照）のＳ１０３でＣＰＵ３１が実行するキャッシュファイル復元処理の手順について図６のフローチャートを参照しながら説明する。
【００５７】
まず、Ｓ４００では、ＲＡＭ３２に記憶している自己の保有キャッシュファイルリスト（図３（ａ）参照）に記述されている全てのキャッシュファイルについて、マウント領域（代用のキャッシュ領域）への復元が完了したか否かを判定する。全てのキャッシュファイルの復元が完了していない場合（Ｓ４００：ＮＯ）、Ｓ４０１でＬＡＮ内保有状況確認処理を実行する。このＬＡＮ内保有状況確認処理では、ＬＡＮ１００に接続している全てのカラオケ端末４におけるキャッシュファイルの保有状況を確認し、ＲＡＭ３２に記憶している各カラオケ端末４の保有キャッシュファイルリスト（図３（ｃ）参照）を更新する（詳細な手順については後述する）。
【００５８】
つぎに、Ｓ４０２では、現時点でカラオケ端末４から特定のキャッシュファイルに対するダウンロード要求があるか否かを判定する。カラオケ端末４からのダウンロード要求がある場合（Ｓ４０２：ＹＥＳ）、要求されているキャッシュファイルを次の取得対象のキャッシュファイルに選定する（Ｓ４０３）。一方、カラオケ端末４からのダウンロード要求がない場合（Ｓ４０２：ＮＯ）、自己の保有キャッシュファイルリストを参照し、復元が未完了のキャッシュファイルのうちの１つを、次の取得対象のキャッシュファイルに選定する（Ｓ４０４）。
【００５９】
つぎに、Ｓ４０５では、ＲＡＭ３２に記憶しているキャッシュファイルの保有端末一覧（図３（ｂ）参照）、及び、各カラオケ端末４の保有キャッシュファイルリスト（図３（ｃ）参照）を参照し、取得対象のキャッシュファイルを保有している端末が既知であるか否かを判定する。取得対象のキャッシュファイルを保有している端末が既知である場合（Ｓ４０５：ＹＥＳ）、Ｓ４０８の処理へ進み、取得対象のキャッシュファイルを保有している端末が不明、すなわち、参照したリストに取得対象のキャッシュファイルの保有先が記述されていない場合（Ｓ４０５：ＮＯ）、Ｓ４０６の処理へ進む。
【００６０】
取得対象のキャッシュファイルを保有している端末が不明である場合に進むＳ４０６では、他のＰ２Ｐ端末３に対して、取得対象のキャッシュファイルを保有している端末を問合せる。そして、この問合せの結果得られた情報に基づいて、取得対象のキャッシュファイルを保有しているＰ２Ｐ端末３の情報をＲＡＭ３２の保有端末一覧に追加更新し（Ｓ４０７）、Ｓ４０８の処理へ進む。
【００６１】
Ｓ４０８では、取得先選定処理を実行する。この取得先選定処理では、取得対象のキャッシュファイルを保有しているＰ２Ｐ端末３及びカラオケ端末４の中から、当該キャッシュファイルの取得先となる端末を選定し、この取得先の端末から取得対象のキャッシュファイルをダウンロードする（詳細な手順については後述する）。
【００６２】
Ｓ４０８の処理を実行後、Ｓ４００の処理へ戻る。以降、Ｓ４００〜Ｓ４０８の処理を繰返すことで、自己の保有キャッシュファイルリストに記録されているキャッシュファイルを順次マウント領域（代用のキャッシュ領域）へ復元する。そして、Ｓ４００において全てのキャッシュファイルの復元が完了したと判定した場合（Ｓ４００：ＹＥＳ）、本処理を終了する。以降、自Ｐ２Ｐ端末３のＨＤＤ３４が復旧されるまで、カラオケ端末４のＨＤＤ４４に復元されたキャッシュ領域を代用して、他のＰ２Ｐ端末４との間でキャッシュファイルの送受信を継続する。
【００６３】
（１−６．ＬＡＮ内保有状況確認処理）
上述のキャッシュファイル復元処理（図６参照）のＳ４０１でＣＰＵ３１が実行するＬＡＮ内保有状況確認処理の手順について図７（ａ）のフローチャートを参照しながら説明する。
【００６４】
まず、Ｓ５００では、ＬＡＮ１００内にブロードキャストで保有キャッシュファイルリストの送信要求を発信する。保有キャッシュファイルリストの送信要求は、各カラオケ端末４に対して、各自の保有キャッシュファイルリスト（図３（ｃ）参照）の送信を要求するメッセージである。つぎに、Ｓ５０１では、ＲＡＭ３２に既存の各カラオケ端末４の保有キャッシュファイルリストと、Ｓ５００の送信要求に応じて各カラオケ端末４から送信されてきた最新の保有キャッシュファイルリストとで、記録内容に差分があるか否かを判定する。既存の保有キャッシュファイルリストと、最新の保有キャッシュファイルリストとで差分がある場合（Ｓ５０１：ＹＥＳ）、ＲＡＭ３２に既存のカラオケ端末４の保有キャッシュファイルリストを最新の内容に更新する（Ｓ５０２）。一方、既存の保有キャッシュファイルリストと、最新の保有キャッシュファイルリストとで記憶内容が同一である場合（Ｓ５０１：ＮＯ）、本処理を終了する。
【００６５】
（１−７．取得先選定処理）
上述のキャッシュファイル復元処理（図６参照）のＳ４０８でＣＰＵ３１が実行する取得先選定処理の手順について図７（ｂ）のフローチャートを参照しながら説明する。
【００６６】
まず、Ｓ６００では、取得対象のキャッシュファイルを保有しているＰ２Ｐ端末３及びカラオケ端末４（以下、保有端末）が複数存在するか否かを判定する。保有端末が複数存在する場合（Ｓ６００：ＹＥＳ）、各保有端末との間のデータ転送レートをそれぞれ測定し、全保有端末の中からデータ転送レートが最大のＰ２Ｐ端末３又はカラオケ端末４の何れか１つを、取得先の端末に選定する（Ｓ６０１）。一方、保有端末が唯一である場合（Ｓ６００：ＮＯ）、その唯一の保有端末であるＰ２Ｐ端末３又はカラオケ端末４を取得先の端末に選定する（Ｓ６０２）。
【００６７】
つぎに、Ｓ６０３では、Ｓ６０１又はＳ６０２で選定した取得先の端末から取得対象のキャッシュファイルをダウンロードし、そのダウンロードしたキャッシュファイルをマウント対象のカラオケ端末４に設けられたマウント領域（代用のキャッシュ領域）に保存する。
【００６８】
（１−８．保有端末応答処理）
Ｐ２Ｐ端末３のＣＰＵ３１が実行する保有端末応答処理の手順について図８のフローチャートを参照しながら説明する。この処理は、Ｐ２Ｐ端末３の稼働中において所定時間ごとに繰返し実行される処理である。
【００６９】
Ｐ２Ｐ端末３のＣＰＵ３１は、まず、他のＰ２Ｐ端末３からキャッシュファイルの保有端末の問合せを受信したか否かを判定する（Ｓ７００）。この問合せは、上述のキャッシュファイル復元処理（図６参照）のＳ４０６において送信されるものである。保有端末の問合せを受信した場合（Ｓ７００：ＹＥＳ）、ＲＡＭ３２に記憶している自己の保有キャッシュファイルリストを要求元のＰ２Ｐ端末３に対して送信し（Ｓ７０１）、本処理を終了する。一方、保有端末の問合せを受信していない場合（Ｓ７００：ＮＯ）、そのまま本処理を終了する。
【００７０】
［２．カラオケ端末４が実行する処理の説明］
（２−１．ＨＤＤ情報送信処理）
カラオケ端末４のＣＰＵ４１が実行するＨＤＤ情報送信処理の手順について図９（ａ）のフローチャートを参照しながら説明する。この処理は、カラオケ端末４の稼働中において所定時間ごとに繰返し実行される処理である。
【００７１】
カラオケ端末４のＣＰＵ４１は、まず、Ｐ２Ｐ端末３からＨＤＤ情報送信要求を受信したか否かを判定する（Ｓ８００）。このＨＤＤ情報送信要求は、上述のマウント処理（図５（ａ）参照）のＳ２００において送信されるものである。ＨＤＤ情報送信要求を受信した場合（Ｓ８００：ＹＥＳ）、ＨＤＤ４４の利用状況から代用のキャッシュ領域として提供可能なＨＤＤ４４の空き容量を算出し、この空き容量と自カラオケ端末４のローカルＩＰアドレスとを含むＨＤＤ情報を要求元のＰ２Ｐ端末３に対して送信し（Ｓ８０１）、本処理を終了する。一方、ＨＤＤ情報送信要求を受信していない場合（Ｓ８００：ＮＯ）、そのまま本処理を終了する。
【００７２】
（２−２．マウント要求応答処理）
カラオケ端末４のＣＰＵ４１が実行するマウント要求応答処理の手順について図９（ｂ）のフローチャートを参照しながら説明する。この処理は、カラオケ端末４の稼働中において所定時間ごとに繰返し実行される処理である。
【００７３】
カラオケ端末４のＣＰＵ４１は、まず、Ｐ２Ｐ端末３からマウント要求を受信したか否かを判定する（Ｓ９００）。このマウント要求は、上述のマウント処理（図５（ａ）参照）のＳ２０２において送信されるものである。マウント要求を受信した場合（Ｓ９００：ＹＥＳ）、マウントを受付ける領域を示すマウントポイントを要求元のＰ２Ｐ端末３に対して通知し（マウント応答、Ｓ９０１）、Ｐ２Ｐ端末３からのマウントを許可する（マウント受付、Ｓ９０２）。一方、マウント要求を受信していない場合（Ｓ９００：ＮＯ）、そのまま本処理を終了する。
【００７４】
（２−３．保有状況応答処理）
カラオケ端末４のＣＰＵ４１が実行する保有状況応答処理の手順について図９（ｃ）のフローチャートを参照しながら説明する。この処理は、カラオケ端末４の稼働中において所定時間ごとに繰返し実行される処理である。
【００７５】
カラオケ端末４のＣＰＵ４１は、まず、Ｐ２Ｐ端末３からカラオケ端末４の保有キャッシュファイルリストの送信要求を受信したか否かを判定する（Ｓ１０００）。この送信要求は、上述のキャッシュファイル復元処理（図６参照）のＳ４０１において送信されるものである。保有キャッシュファイルリストの送信要求を受信した場合（Ｓ１０００：ＹＥＳ）、ＲＡＭ４２又はＨＤＤ４４に記憶している自己の保有キャッシュファイルリストを要求元のＰ２Ｐ端末３に対して送信し（Ｓ１００１）、本処理を終了する。一方、保有キャッシュファイルリストの送信要求を受信していない場合（Ｓ１０００：ＮＯ）、そのまま本処理を終了する。
【００７６】
［特許請求の範囲に記載の構成との対応］
実施形態のコンテンツ配信システム１の構成と、特許請求の範囲に記載の構成との対応は次のとおりである。所定のプログラムに沿って各種演算処理を行うＰ２Ｐ端末３のＣＰＵ３１が、特許請求の範囲における検知手段、マウント先選定手段、マウント手段、キャッシュ復元手段に相当する。また、Ｐ２Ｐ端末３のＨＤＤ３４がキャッシュ手段に相当する。また、Ｐ２Ｐ端末３のＲＡＭ３２がリスト記憶手段に相当する。
【００７７】
［効果］
上記実施形態のコンテンツ配信システム１によれば、次のような効果を奏する。
（１）Ｐ２Ｐ端末３のＨＤＤ３４が故障するなどしてキャッシュ領域が使用不能になった場合でも、ＬＡＮ１００を介して接続しているカラオケ端末４のＨＤＤ４４をキャッシュ領域として代用でき、他のＰ２Ｐ端末３に対するキャッシュファイルのアップロードを継続できる。さらに、ＲＡＭ３２に記憶している保有キャッシュファイルリストに基づいて、破損前のキャッシュファイルをキャッシュ領域の代用としてマウントされた記憶領域に復元できる。これにより、Ｐ２Ｐネットワークを構成する端末間において共有の管理情報を変更することなく、破損前と同等のキャッシュファイルを他のＰ２Ｐ端末３へアップロード可能である。また、復元するキャッシュファイルの取得先として、データ転送レート（通信速度）が最大の端末を選定することで、速やかにキャッシュファイルを復元し、キャッシュファイルのアップロード機能を迅速に回復できる。
【００７８】
（２）マウント対象選定処理（第１実施形態）では、ＨＤＤ４４の空き容量が最大のカラオケ端末４をマウント対象として選定することで、マウント対象のカラオケ端末４が持つ記憶資源に対してなるべく負担がかからないようにできる。
【００７９】
（３）マウント対象選定処理（第２実施形態）では、Ｐ２Ｐ端末３との通信速度が最大のカラオケ端末４をマウント対象として選定することで、キャッシュファイルの復元を迅速に完了できるようにすると共に、マウント対象のカラオケ端末４が持つ情報処理能力に対してなるべく負担がかからないようにできる。
【００８０】
（４）Ｐ２Ｐ端末３がキャッシュファイルを復元する最中において、カラオケ端末４からキャッシュファイルのダウンロード要求を受けた場合、保有キャッシュファイルリストの内容に関わらず、カラオケ端末４からのダウンロード要求に対応するキャッシュファイルを優先的に取得できる。これにより、キャッシュファイルを復元中であったとしても、カラオケ端末４からのダウンロード要求に係るキャッシュファイルの取得に遅延が生じないようにできる。
【００８１】
（５）復元するキャッシュファイルの取得先を選定する直前のタイミングで、各カラオケ端末４からキャッシュファイルの保有状況を取得することで、ＬＡＮ１００内におけるキャッシュファイルの最新の保有状況を把握でき、必要なキャッシュファイルを保有するカラオケ端末４を確実に特定できる。
【００８２】
［変形例］
以上、本発明の実施形態について説明したが、本発明は上記の実施形態に何ら限定されるものではなく様々な態様にて実施することが可能である。
【００８３】
例えば、上述のマウント対象選定処理の第２実施形態（図５（ｃ）参照）においては、Ｐ２Ｐ端末３との通信速度が最大のカラオケ端末４をマウント対象に選定する構成となっていた。これに対し、通信速度に基づいてマウント対象を選定する代わりに、各カラオケ端末４のＣＰＵ４１の使用率を取得し、それに基づいてＣＰＵ４１の使用率が低いカラオケ端末４をマウント対象に選定するように構成してもよい。カラオケ端末４のＣＰＵ４１の使用率が低ければ、キャッシュファイルの復元処理のためにＣＰＵ４１を占有できる時間を多く確保できるので、キャッシュファイルの復元処理を速やかに完了できる。また、処理能力に余裕のあるカラオケ端末４がマウント対象に選定されることになるため、カラオケ端末４が本来実行すべきカラオケサービスの実施に支障を及ぼすおそれがない。
【００８４】
あるいは、上述のマウント対象選定処理の第１実施形態（図５（ｂ）参照）と、第２実施形態の要件を併せ持つように構成してもよい。すなわち、複数のカラオケ端末４の間でＨＤＤ４４の空き容量及び通信速度をそれぞれ比較し、その中からＨＤＤ４４の空き容量が大きく、かつ、通信速度が速いカラオケ端末４を優先的にマウント対象に選定するように構成することが考えられる。
【符号の説明】
【００８５】
１…コンテンツ配信システム、３…Ｐ２Ｐ端末、３１…ＣＰＵ、３２…ＲＡＭ、３３…ＲＯＭ、３４…ＨＤＤ、３５…Ｐ２Ｐネットワーク通信部、３６…ＬＡＮ通信部、４…カラオケ端末、４１…ＣＰＵ、４２…ＲＡＭ、４３…ＲＯＭ、４４…ＨＤＤ、４５…操作部、４６…再生部、４７…入力部、４８…ＬＡＮ通信部、１００…ＬＡＮ、２００…Ｐ２Ｐネットワーク。
【図１】
0005168333.tif 000002
【図２】
0005168333.tif 000003
【図３】
0005168333.tif 000004
【図４】
0005168333.tif 000005
【図５】
0005168333.tif 000006
【図６】
0005168333.tif 000007
【図７】
0005168333.tif 000008
【図８】
0005168333.tif 000009
【図９】
0005168333.tif 000010