(57)【要約】【課題】動画圧縮ファイルを不正に視聴できないようにし、かつ、動画圧縮ファイルを視聴可能に修復するための修復データのデータ量を小さく抑えることができるコンテンツ配信システムを提供する。【解決手段】コンテンツ配信システムのサーバは、動画圧縮ファイルであるＭＰＥＧファイル内の各Ｉピクチャを正常に再生できない欠陥Ｉピクチャにし（図中（１））、欠陥Ｉピクチャを元のＩピクチャに戻すための修復データを作成する（図中（２））。欠陥Ｉピクチャにより、ＭＰＥＧファイル内のＢピクチャ、Ｐピクチャも正常に再生できないため、ＭＰＥＧファイルは視聴不能となる。クライアントは、欠陥Ｉピクチャを含むＭＰＥＧファイルを再生するとき、サーバから修復データを取得し（図中（３））、欠陥Ｉピクチャを元のＩピクチャに修復してＭＰＥＧファイルを再生する。【選択図】図２
2007116445.tif 000002
【特許請求の範囲】
【請求項１】
クライアントと、前記クライアントに接続されるサーバとを備えたコンテンツ配信システムであって、
前記サーバは、
配列された複数の画像を含み、前記複数の画像は、単独で復号される複数の基本画像と、前記基本画像を利用して復号される複数の差分画像とで構成される動画圧縮ファイルを記憶するためのサーバ記憶手段と、
前記基本画像を、正常な再生が不可能な欠陥基本画像にする正常再生不能化手段と、
前記欠陥基本画像を元の基本画像に修復するための修復データを前記欠陥基本画像ごとに作成する修復データ作成手段と、
前記欠陥基本画像を含む動画圧縮ファイルを送信する動画圧縮ファイル送信手段と、
前記修復データを送信する修復データ送信手段とを備え、
前記クライアントは、
前記送信された動画圧縮ファイルを記憶するためのクライアント記憶手段と、
前記動画圧縮ファイル内の画像を配列順に復号する復号手段と、
前記復号された画像を再生する再生手段と、
前記送信された修復データを格納するためのメモリ手段と、
前記動画圧縮ファイルを復号するとき、前記動画圧縮ファイル内の欠陥基本画像に対応する修復データを取得して前記メモリ手段に格納する修復データ取得手段と、
前記欠陥基本画像を復号する前に、前記格納された修復データを使用して前記欠陥基本画像を元の基本画像に修復する修復手段と、
修復後、使用済みの修復データを前記メモリ手段から消去する消去手段とを備えることを特徴とするコンテンツ配信システム。
【請求項２】
請求項１に記載のコンテンツ配信システムであって、
前記修復データ作成手段はさらに、前記動画圧縮ファイル内における欠陥基本画像の配列位置と、前記欠陥基本画像に対応する修復データに関する情報とを含む修復テーブルを作成し、
前記クライアントはさらに、
前記修復テーブルを取得する手段と、
前記修復データ取得手段が所定数の修復データを取得後、前記修復テーブルに基づいて、前記取得された所定数の修復データのうち最後に使用される修復データに対応する欠陥基本画像の次に復号される欠陥基本画像に対応する修復データを先頭修復データに特定する先頭特定手段とを備え、
前記修復データ取得手段は、前記所定数の修復データのうち未使用の修復データの数が所定数未満になったとき、前記特定された先頭修復データから、対応する欠陥基本画像が復号される順に前記所定数の修復データを新たに取得することを特徴とするコンテンツ配信システム。
【請求項３】
請求項２に記載のコンテンツ配信システムであって、
前記メモリ手段は、複数のメモリ領域を含み、
前記消去手段は、前記メモリ手段に格納された前記所定数の修復データのうち、使用済みの修復データが格納されたメモリ領域を解放し、
前記修復データ取得手段は、前記新たに取得された修復データを前記解放されたメモリ領域に格納することを特徴とするコンテンツ配信システム。
【請求項４】
請求項１〜請求項３のいずれか１項に記載のコンテンツ配信システムであって、
前記基本画像は行列状に配置される複数のマクロブロックを含み、
前記正常再生不能化手段は、前記基本画像内の複数のマクロブロックの配置を変更して欠陥基本画像とし、
前記修復データ作成手段は、前記変更されたマクロブロックの元の配置に関する情報を前記修復データに含め、
前記修復手段は、前記修復データに基づいて前記欠陥基本画像内のマクロブロックを元の配置に戻すことを特徴とするコンテンツ配信システム。
【請求項５】
請求項１〜請求項４のいずれか１項に記載のコンテンツ配信システムであって、
前記正常再生不能化手段は、前記基本画像のうちの一部のデータを削除し、
前記修復データ作成手段は、前記削除されたデータ及び前記基本画像内における前記削除されたデータの配置に関する情報を前記修復データに含め、
前記修復手段は、前記修復データに基づいて前記欠陥基本画像に前記削除されたデータを戻すことを特徴とするコンテンツ配信システム。
【請求項６】
請求項５に記載のコンテンツ配信システムであって、
前記動画圧縮ファイルはＭＰＥＧファイルであり、前記基本画像はＩピクチャであり、前記差分画像はＢピクチャ及びＰピクチャであり、
前記削除されたデータは前記Ｉピクチャのピクチャヘッダであることを特徴とするコンテンツ配信システム。
【請求項７】
請求項２に記載のコンテンツ配信システムであって、
前記クライアントはさらに、
再生種類を含む再生指示を受ける再生指示受信手段と、
前記受けた再生指示の再生種類に基づいて、修復データの取得条件を決定する条件決定手段とを備え、
前記修復データ取得手段は、前記取得条件に基づいて前記所定数の修復データを取得することを特徴とするコンテンツ配信システム。
【請求項８】
配列された複数の画像を含み、前記複数の画像は単独で復号される複数の基本画像と前記基本画像を利用して復号される差分画像とで構成される動画圧縮ファイルを蓄積したサーバに接続可能なクライアントであって、
前記サーバから送信された動画圧縮ファイルであって、正常な再生が不可能な欠陥基本画像を含む動画圧縮ファイルを記憶するためのクライアント記憶手段と、
前記動画圧縮ファイル内の画像を配列順に復号する復号手段と、
前記復号された画像を再生する再生手段と、
前記欠陥基本画像を元の基本画像に修復するための修復データを格納するためのメモリ手段と、
前記動画圧縮ファイルを復号するとき、前記動画圧縮ファイル内の欠陥基本画像に対応する修復データを前記サーバから取得して前記メモリ手段に格納する修復データ取得手段と、
前記欠陥基本画像を復号する前に、前記格納された修復データを使用して前記欠陥基本画像を元の基本画像に修復する修復手段と、
修復後、使用済みの修復データを前記メモリ手段から消去する消去手段とを備えることを特徴とするクライアント。
【請求項９】
請求項８に記載のクライアントであって、
前記サーバはさらに、前記動画圧縮ファイル内における欠陥基本画像の配列位置と、前記欠陥基本画像に対応する修復データを特定するための情報とを含む修復テーブルを有し、
前記クライアントはさらに、
前記修復テーブルを取得する手段と、
前記修復データ取得手段が所定数の修復データを取得後、前記修復テーブルに基づいて、前記取得された所定数の修復データのうち最後に使用される修復データに対応する欠陥基本画像の次に復号される欠陥基本画像に対応する修復データを先頭修復データに特定する先頭特定手段とを備え、
前記修復データ取得手段は、前記所定数の修復データのうち未使用の修復データの数が所定数未満になったとき、前記特定された先頭修復データから、対応する欠陥基本画像が復号される順に前記所定数の修復データを新たに取得することを特徴とするクライアント。
【請求項１０】
請求項９に記載のクライアントであって、
前記メモリ手段は、複数のメモリ領域を含み、
前記消去手段は、前記メモリ手段に格納された前記所定数の修復データのうち、使用済みの修復データが格納されたメモリ領域を解放し、
前記修復データ取得手段は、前記新たに取得された修復データを前記解放されたメモリ領域に格納することを特徴とするクライアント。
【請求項１１】
動画圧縮ファイルを再生するクライアントに接続可能なサーバであって、
配列された複数の画像を含み、前記複数の画像は、単独で復号される複数の基本画像と、前記基本画像を利用して復号される複数の差分画像とで構成される動画圧縮ファイルを記憶するためのサーバ記憶手段と、
前記基本画像を、正常な再生が不可能な欠陥基本画像にする正常再生不能化手段と、
前記欠陥基本画像を元の基本画像に修復するための修復データを前記欠陥基本画像ごとに作成する修復データ作成手段と、
前記欠陥基本画像を含む動画圧縮ファイルを送信する動画圧縮ファイル送信手段と、
前記クライアントからの要求に応じて前記欠陥基本画像に対応した修復データを送信する修復データ送信手段とを備えることを特徴とするサーバ。
【請求項１２】
クライアントと、前記クライアントに接続されるサーバとを備えたコンテンツ配信システムによるコンテンツ配信方法であって、
配列された複数の画像を含み、前記複数の画像は、単独で復号される複数の基本画像と、前記基本画像を利用して復号される複数の差分画像とで構成される動画圧縮ファイルを前記サーバに記憶するステップと、
前記基本画像を正常な再生が不可能な欠陥基本画像にするステップと、
前記欠陥基本画像を元の基本画像に修復するための修復データを前記欠陥基本画像ごとに作成するステップと、
前記欠陥基本画像を含む動画圧縮ファイルを前記サーバから前記クライアントへ送信するステップと、
前記修復データを前記サーバから前記クライアントへ送信するステップと、
前記送信された動画圧縮ファイルを前記クライアントに記憶するステップと、
前記クライアントにおいて、前記動画圧縮ファイル内の画像を配列順に復号するステップと、
前記クライアントにおいて、前記復号された画像を再生するステップと、
前記送信された修復データを前記クライアントに格納するステップと、
前記動画圧縮ファイルを復号するとき、前記欠陥基本画像に対応する修復データを取得して前記クライアントに格納するステップと、
前記欠陥基本画像を復号する前に、前記格納された修復データを使用して前記欠陥基本画像を元の基本画像に修復するステップと、
修復後、使用済みの修復データを前記クライントから消去するステップとを備えることを特徴とするコンテンツ配信方法。
【請求項１３】
請求項８〜請求項１０のいずれか１項に記載の手段をクライアントコンピュータに実現させるためのクライアントプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンテンツ配信システムに関し、さらに詳しくは、動画圧縮ファイルを蓄積するサーバと、サーバから動画圧縮ファイルをダウンロードして再生するクライアントとを備えたコンテンツ配信システムに関する。
【背景技術】
【０００２】
インターネット等のネットワークを介してサーバからクライアントへ動画を配信する方法として、ストリーム配信とダウンロード配信とがある。ストリーム配信はコンテンツの不正コピーを防止できる点で有効であるが、ネットワークの状態によっては高いビットレートの動画を配信できず、コンテンツの再生が途切れてしまう場合がある。
【０００３】
一方、ダウンロード配信は、クライアントのハードディスクドライブに動画ファイルをいったん格納した後、ハードディスクドライブから動画ファイルを読み出して再生するため、ネットワークの状態に関係なく、高画質の動画を再生できる。しかしながら、ダウンロード配信ではハードディスクに動画ファイルを格納するため、動画ファイルを不正コピーし、不正に視聴することができる。そのため、ダウンロード配信では、不正コピーの防止対策が問題となる。
【０００４】
特開２００４−２２７５３６号公報では、コンテンツを基本部と残存部とに分割し、一方をＣＤ−ＲＯＭ等の記憶媒体に記憶してユーザに配布し、他方をインターネット等の伝送経路を通じてそのユーザが利用するクライアントに配信し、クライアントで分割されたコンテンツを合成して再生する方法が開示されている。しかしながら、特開２００４−２２７５３６号公報では、コンテンツの具体的な配信方法及び合成方法が示されていない。仮に、コンテンツの他方をダウンロードするのであれば、記憶媒体に記憶された一方のコンテンツとともにクライアントのハードディスクに記憶することができるため、容易に不正コピーできてしまう。また、２つに分割されたコンテンツはいずれか一方でも再生可能であるため、分割されたコンテンツの一方でも不正コピーすれば、部分的にコンテンツを視聴できる。
【０００５】
特開２００４−７０５７３号公報に開示されたデジタルコンテンツ不正コピー防止システムでは、クライアントは、データの一部が欠落したコンテンツデータ（穴あきコンテンツデータ）をダウンロードする。クライアントが穴あきコンテンツデータを再生するとき、サーバは、穴を補充する補正データをストリーム配信する。これにより、クライアントは穴あきコンテンツデータの穴を補正データで修復して再生でき、かつ、ハードディスクに保存された穴あきコンテンツデータでは、コンテンツを完全に再生できないため、不正コピーを防止できるとしている。
【０００６】
しかしながら、穴あきコンテンツデータだけでも視聴可能であるため、穴あきコンテンツデータを不正コピーすれば、不完全なコンテンツではあるものの不正に視聴することが可能となる。したがって、不正コピーに対する抑止力は低い。
【０００７】
さらに、穴あき部分は補正データにより修復されるが、補正データがいかなるデータであるか不明である。仮に、補正データが画像データの一部であれば、補正データのデータ量が大きくなる。補正データのデータ量が大きければ、ストリーム配信された補正データが再生に間に合わない場合が生じる。補正データ量を小さくすれば、この問題は解決するが、補正データ量が小さければ、コンテンツデータの「穴」も小さくなるため、不正コピーに対する抑止力がさらに低下する。
【０００８】
また、クライアントは穴あきコンテンツデータを再生するとき、穴あき部分を再生するごとに補正データを要求する。要するに、クライアントは、コンテンツデータの「穴」の個数と同じ回数分サーバにアクセスして補正データを取得する。そのため、サーバの負担が増大する。
【特許文献１】特開２００４−２２７５３６号公報
【特許文献２】特開２００４−７０５７３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
本発明の目的は、動画圧縮ファイルを不正に視聴できないようにし、かつ、動画圧縮ファイルを視聴可能に修復するための修復データのデータ量を小さく抑えることができるコンテンツ配信システムを提供することである。
【００１０】
本発明の他の目的は、動画ファイルの再生中におけるクライアントからサーバへのアクセス数を低減できるコンテンツ配信システムを提供することである。
【課題を解決するための手段及び発明の効果】
【００１１】
本発明によるコンテンツ配信システムは、クライアントと、クライアントに接続されるサーバとを備える。
【００１２】
サーバは、サーバ記憶手段と、正常再生不能化手段と、修復データ作成手段と、動画圧縮ファイル送信手段と、修復データ送信手段とを備える。サーバ記憶手段は、動画圧縮ファイルを記憶する。動画圧縮ファイルは、配列された複数の画像を含み、複数の画像は、単独で復号される複数の基本画像と、基本画像を利用して復号される複数の差分画像とで構成される。正常再生不能化手段は、基本画像を正常な再生が不可能な欠陥基本画像にする。ここで、正常な再生が不可能な状態とは、基本画像を正常に復号できない状態や、復号できても、スクランブル等の暗号が掛けられていることにより正常に再生できない状態をいう。修復データ作成手段は、欠陥基本画像を元の基本画像に修復するための修復データを欠陥基本画像ごとに作成する。動画圧縮ファイル送信手段は、欠陥基本画像を含む動画圧縮ファイルを送信する。修復データ送信手段は、修復データを送信する。
【００１３】
クライアントは、クライアント記憶手段と、復号手段と、再生手段と、メモリ手段と、修復データ取得手段と、修復手段と、消去手段とを備える。クライアント記憶手段は、送信された動画圧縮ファイルを記憶する。復号手段は、動画圧縮ファイル内の画像を配列順に復号する。再生手段は、復号された画像を再生する。ここで、再生手段は、復号手段が復号した順に復号された画像を再生してもよいし、復号された順に再生せず、復号された画像を配列し直して、再生してもよい。メモリ手段は、送信された修復データを格納する。修復データ取得手段は、動画圧縮ファイルを復号するとき、動画圧縮ファイル内の欠陥基本画像に対応する修復データを取得してメモリ手段に格納する。修復手段は、欠陥基本画像を復号する前に、格納された修復データを使用して欠陥基本画像を元の基本画像に修復する。消去手段は、修復後、使用済みの修復データをメモリ手段から消去する。
【００１４】
本発明によるコンテンツ配信システムは、動画圧縮ファイル内の複数の画像のうち、基本画像のみを正常に再生できないようにする。基本画像が正常に再生できなければ、差分画像も正常に再生できない。なぜなら、差分画像は基本画像を利用して復号されるため、利用される基本画像が正常に再生できなければ、差分画像も正常に再生できないからである。したがって、基本画像のみを正常に再生できないようにするだけで、全ての画像を正常に再生できなくでき、動画圧縮ファイルを視聴不能にすることができる。
【００１５】
また、基本画像のみを改変して欠陥基本画像とするため、動画圧縮ファイルを正常に再生するための修復データのデータ量を抑えることができる。
【００１６】
また、修復に使用された修復データは消去されるため、修復データが不正コピーに利用されるのを防止できる。
【００１７】
好ましくは、修復データ作成手段はさらに、動画圧縮ファイル内における欠陥基本画像の配列位置と、欠陥基本画像に対応する修復データに関する情報とを含む修復テーブルを作成する。クライアントはさらに、修復テーブルを取得する手段と、先頭特定手段とを備える。先頭特定手段は、修復データ取得手段が所定数の修復データを取得後、修復テーブルに基づいて、取得された所定数の修復データのうち最後に使用される修復データに対応する欠陥基本画像の次に復号される欠陥基本画像に対応する修復データを先頭修復データに特定する。修復データ取得手段は、所定数の修復データのうち未使用の修復データの数が所定数未満になったとき、特定された先頭修復データから、対応する欠陥基本画像が復号される順に所定数の修復データを新たに取得する。
【００１８】
動画圧縮ファイル内の欠陥基本画像に対応する修復データを、対応する欠陥基本画像を復号するごとに要求する場合、サーバとの間のトラフィックが混雑する。一方、動画圧縮ファイル内の欠陥基本画像に対応する修復データの全てを一度に要求する場合、データ量が大きくなるため、たとえば、ハードディスクドライブといった記憶容量の大きい不揮発性の記憶装置に記憶させなければならない場合がある。修復データを不揮発性の記憶装置に格納すれば、不正コピーに利用することが可能となるため好ましくない。
【００１９】
本発明では、所定数の修復データ（修復データ群）を随時取得し、未使用の修復データの数が所定数未満になったとき、次の修復データ群を新たに取得する。このため、修復データを１つずつ取得する場合よりも、クライアントからサーバへのアクセス数を低減でき、クライアントとサーバとの間のトラフィックを緩和できる。さらに、全ての修復データを一度に取得する場合よりも取得するデータ量を少なくできるため、不揮発性の記憶手段に修復データを格納する必要がなくなり、修復データが不正コピーに利用されるのを防止できる。
【００２０】
好ましくは、メモリ手段は、複数のメモリ領域を含む。消去手段は、メモリ手段に格納された所定数の修復データのうち使用済みの修復データが格納されたメモリ領域を解放する。修復データ取得手段は、新たに取得された修復データを解放されたメモリ領域に格納する。
【００２１】
この場合、新たに取得された修復データ群は、メモリ手段のうち使用済みの修復データが格納されたメモリ領域に上書きされ、使用済みの修復データは消去される。そのため、使用済みの修復データが不正コピーに利用されるのを防止できる。
【００２２】
好ましくは、基本画像は行列状に配置される複数のマクロブロックを含む。正常再生不能化手段は、基本画像内の複数のマクロブロックの配置を変更して欠陥基本画像とする。修復データ作成手段は、変更されたマクロブロックの元の配置に関する情報を修復データに含める。修復手段は、修復データに基づいて欠陥基本画像内のマクロブロックを元の配置に戻す。
【００２３】
この場合、基本画像内のマクロブロックの配置を変更するのみで正常に再生できなくする。また、画像データを削除するのではなく、画像データの配置を変更するだけなので、欠陥基本画像のデータ量自体は正常な基本画像とほぼ同じである。修復データはマクロブロックの配置に関する情報であるため、画像データ等を削除して正常に再生できなくする場合よりも、修復データのデータ量を小さく抑えることができる。
【００２４】
好ましくは、正常再生不能化手段は、基本画像のうちの一部のデータを削除する。修復データ作成手段は、削除されたデータ及び基本画像内における削除されたデータの配置に関する情報を修復データに含める。修復手段は、修復データに基づいて欠陥基本画像に削除されたデータを元の位置に配置する。
【００２５】
この場合、基本画像内の一部のデータを削除するだけで、基本画像を正常に再生できなくするだけでなく、差分画像も正常に再生できなくする。また、修復データとして削除された一部のデータを含めれば、基本画像を正常に修復できるため、修復データのデータ量を抑えることができる。
【００２６】
好ましくは、動画圧縮ファイルはＭＰＥＧファイルであり、基本画像はＩピクチャであり、差分画像はＢピクチャ及びＰピクチャである。削除されたデータはＩピクチャのピクチャヘッダである。
【００２７】
この場合、Ｉピクチャのピクチャヘッダを削除して欠陥Ｉピクチャを作成すれば、Ｉピクチャを復号することはできなくなり、Ｂピクチャ、Ｐピクチャも復号できなくなる。また、Ｉピクチャのピクチャヘッダが修復データとなるため、修復データのデータ量を抑えることができる。
【００２８】
好ましくは、クライアントはさらに、再生指示受信手段と、条件決定手段とを備える。再生指示受信手段は、再生種類を含む再生指示を受ける。条件決定手段は、受けた再生指示の再生種類に基づいて、修復データの取得条件を決定する。修復データ取得手段は、取得条件に基づいて所定数の修復データを取得する。ここで、再生の種類とは、正常再生、早送り再生、早戻し再生等であり、早送り再生や早戻し再生の場合、２倍速、３倍速といった再生速度に関する情報を含んでもよい。
【００２９】
この場合、クライアントは再生種類に応じて修復データを取得できる。
【００３０】
本発明によるクライアントは、上記コンテンツ配信システムに使用されるクライアントであり、本発明によるサーバは、上記コンテンツ配信システムに使用されるサーバである。本発明によるクライアントプログラムは上記クライアントに実現させるためのプログラムである。
【００３１】
また、本発明によるコンテンツ配信方法は、上記コンテンツ配信システムの動作方法である。
【発明を実施するための最良の形態】
【００３２】
以下、図面を参照し、本発明の実施の形態を詳しく説明する。図中同一又は相当部分には同一符号を付してその説明は繰り返さない。
【００３３】
［全体構成］
図１を参照して、コンテンツ配信システムは、動画圧縮ファイルである複数のＭＰＥＧファイルを蓄積するサーバ（コンピュータ）１と、クライアント（コンピュータ）２とを備える。これらはインターネット３で相互に接続されるが、ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）、その他のコンピュータネットワーク経由で相互に接続されてもよい。図１では、１つのクライアント２がサーバ１に接続されているが、複数のクライアント２がサーバ１に接続されてもよい。
【００３４】
ＭＰＥＧファイルは、図２に示すように連続して配列される複数のＧＯＰ（Group Of Pictures）で構成される。各ＧＯＰは複数の画像フレーム（以下、単に画像ともいう）を含む。具体的には、各ＧＯＰは、単独で復号可能な基本画像であるＩピクチャ（フレーム）を１つ含む。また、各ＧＯＰは、単独で復号できず、復号するためにＩピクチャを利用する差分画像である複数のＢピクチャ及びＰピクチャ（フレーム）を含む。なお、図２では、各ＧＯＰが複数の画像フレームで構成されるとしたが、各ＧＯＰが複数の画像フィールドで構成されてもよい。
【００３５】
クライアント２は、サーバ１から所望のＭＰＥＧファイルをダウンロードする。ダウンロードされたＭＰＥＧファイルは、正常に再生できないように処理されている。ここで、正常に再生できないとは、ＭＰＥＧファイルを復号できなかったり、復号できても、画像がスクランブル等により暗号化されていて正常に視聴できないことをいう。以下、正常に再生できないように処理されたＭＰＥＧファイルを欠陥ＭＰＥＧファイルという。欠陥ＭＰＥＧファイルを再生するとき、クライアント２はサーバ１から欠陥ＭＰＥＧファイルを正常に復号するための修復データを取得し、修復データを用いて欠陥ＭＰＥＧファイルを正常に復号し、再生する。
【００３６】
［サーバの構成］
再び図１を参照して、サーバ１は、ハードディスクドライブ（以下、ＨＤＤという）１０と、ＣＰＵ１３と、メモリ１４とを含む。これらは図示しないバスで相互に接続される。
【００３７】
ＨＤＤ１０には、複数のＭＰＥＧファイルが登録された動画データベース１１と、サーバ１の動作を制御するためのサーバアプリケーション（プログラム）１２とが記憶される。
【００３８】
サーバアプリケーション１２は、動画データベース１１に登録されたＭＰＥＧファイルを欠陥ＭＰＥＧファイルにする。サーバアプリケーション１２はまた、欠陥ＭＰＥＧファイルを元の正常なＭＰＥＧファイルに修復するための修復データと、修復データに関する情報をリスト化した修復テーブルとを作成し、クライアント２からの要求に応じて修復データをストリーム配信する。
【００３９】
サーバアプリケーション１２は、メモリ１４にロードされ、ＣＰＵ１３により実行されることで、上記動作を実現する。
【００４０】
［クライアント］
クライアント２は、ハードディスクドライブ（ＨＤＤ）２０と、ＣＰＵ２３と、メモリ２４とを含む。これらは図示しないバスで相互に接続される。
【００４１】
ＨＤＤ２０は、サーバ１からダウンロードした欠陥ＭＰＥＧファイルが登録される動画データベース２１と、要求アプリケーション（プログラム）２２と、復号アプリケーション（プログラム）２５と、再生アプリケーション（プログラム）２６とを保存する。
【００４２】
要求アプリケーション２２は、欠陥ＭＰＥＧファイルを再生するときに、複数の修復データ（以下、修復データ群という）をサーバ１に要求し、取得する。復号アプリケーション２５は、取得された修復データ群を用いて、欠陥ＭＰＥＧファイル内のピクチャ（フレーム）を配列順に順次復号する。再生アプリケーション２６は復号されたピクチャを再生する。
【００４３】
要求アプリケーション２２、復号アプリケーション２５及び再生アプリケーション２６は、メモリ２４にロードされ、ＣＰＵ２３により実行されることで、上記動作を実現する。
【００４４】
［動作概要］
［ＭＰＥＧファイルの正常再生不能化］
サーバ１は、欠陥ＭＰＥＧファイルを作成する。このとき、サーバ１は、図２に示すようにＭＰＥＧファイル内の複数の画像のうち、Ｉピクチャのみを正常に再生できないように処理する（正常再生不能化処理：図２中（１））。Ｉピクチャ以外のＢ、Ｐピクチャに対しては正常再生不能化処理を実行しない。Ｂ、ＰピクチャはＩピクチャに基づいて復号されるため、Ｉピクチャが正常に再生できなければ、Ｂ、Ｐピクチャも正常に再生できない。以下、正常再生不能化処理を実行されたＩピクチャを欠陥Ｉピクチャという。欠陥ＭＰＥＧファイルは、要するに、欠陥Ｉピクチャを含むＭＰＥＧファイルである。
【００４５】
Ｉピクチャを再生できないように処理する方法としては、Ｉピクチャのみをスクランブル処理する。また、Ｉピクチャのピクチャヘッダを特定し、特定されたピクチャヘッダをランダムデータと置換する。要するに、ピクチャヘッダを削除する。ピクチャヘッダを削除することによりＩピクチャは復号できなくなり、かつ、仮にピクチャヘッダを修復して復号しても、スクランブル処理によりＩピクチャは正常に視聴できない。
【００４６】
サーバ１は欠陥Ｉピクチャを作成したとき、修復データを欠陥Ｉピクチャごとに作成する（図２中（２））。サーバ１は各修復データに修復データＩＤを付してＨＤＤ１０に格納する。修復データは、Ｉピクチャのピクチャヘッダデータと、スクランブルを解除するためのデスクランブルテーブルとを含む。
【００４７】
以上のとおり、サーバ１は、ＭＰＥＧファイルのうち、Ｉピクチャに対してのみ正常再生不能化処理を行うことで、全てのピクチャを正常に再生できなくする。さらに、正常再生不能化処理はＩピクチャに対してのみ実行されるため、修復データのデータ量を少なく抑えることができる。
【００４８】
［クライアントでのＭＥＰＧファイル再生処理］
クライアント２はサーバ１から欠陥ＭＰＥＧファイルをダウンロードし、その欠陥ＭＰＥＧファイルを再生する。このとき、クライアント２は欠陥ＭＰＥＧファイル内に連続して配列された複数のピクチャ（Ｉ、Ｂ、Ｐ）を配列順に順次復号するが、欠陥Ｉピクチャを復号するために対応する修復データをサーバ１から取得する。
【００４９】
このとき、クライアント２は、各欠陥Ｉピクチャを復号するごとに対応する修復データを取得したり、修復データの全てを一度に取得したりしない。図２（３）に示すように、クライアント２は、連続して配列された複数の修復データ（ＩＤ＝０〜２９９）をいくつかに区切り（図２では３つに区切り）、区切られた修復データ群（ＩＤ＝０〜９９、１００〜１９９、２００〜２９９）を順次取得する。
【００５０】
図２（３）では、クライアント２は初めに修復データＩＤ＝０〜９９の修復データ群をサーバ１から取得してメモリ２４に格納し、格納された修復データ群を用いて欠陥Ｉピクチャを順次復号しながら再生する。格納された修復データ群のうち、修復に使用された修復データ（以下、使用済み修復データという）の数が増え、修復に未だ使用されていない修復データ（以下、未使用修復データという）の数が所定数未満となったとき、クライアント２は次の修復データ群（ＩＤ＝１００〜１９９）をサーバ１から取得してメモリ２４に格納し、格納された修復データ群を用いて欠陥Ｉピクチャを復号する。新たな修復データ群をメモリ２４に格納するとき、クライアント２は使用済み修復データを消去する。
【００５１】
クライアント２が修復データを１つずつ要求すれば、クライアント２からサーバ１へのアクセス回数が増加し、クライアント２とサーバ１との間のトラフィックが混雑する。一方、クライアント２が修復データの全てを一度に要求して取得すれば、取得した修復データの全てをメモリ２４に格納できず、取得した修復データをＨＤＤ２０に格納しなければならない場合が生じる。修復データをＨＤＤ２０に格納する場合、修復データが不正コピーに利用される可能性が生じる。本実施の形態では、クライアント２は、修復データ群を随時取得するため、サーバ１との間のトラフィックを緩和できる。また、取得した修復データ群をメモリ２４に格納し、使用済み修復データを消去することにより、修復データが不正コピーに利用されるのを防止できる。
【００５２】
［全体動作］
図３を参照して、サーバ１はまず、ＨＤＤ２０に蓄積された各ＭＰＥＧファイルに対して正常再生不能化処理を実行し、欠陥ＭＰＥＧファイルを作成する（Ｓ１００）。このとき、サーバ１は複数の修復データと、修復データに関する情報をリスト化した修復テーブルとを作成する。
【００５３】
クライアント２は、所望の欠陥ＭＰＥＧファイルを要求し、サーバ１から欠陥ＭＰＥＧファイル及び修復テーブルを取得する（図３中（１））。
【００５４】
続いて、クライアント２は、欠陥ＭＰＥＧファイルを通常再生する（図３中（２））。このとき、クライアント２は、修復データ群を要求する（修復データ要求処理：Ｓ２００）。クライアント２はまず、取得する修復データの先頭を示す先頭修復データＩＤ＝０とする。クライアント２はさらに、再生種類（ここでは通常再生）に基づいて取得条件を決定し、その取得条件に基づく修復データ群を要求する。図３では、取得条件は、カウント数＝１００、検索方向＝前方、スキップ数＝０となっている。この場合、クライアント２は、先頭修復データＩＤ＝０から数えて１００個（カウント数＝１００）の修復データを再生方向（検索方向＝前方）にスキップせずに（スキップ数＝０）送信するよう要求する。クライアント２は修復テーブルに基づいて修復データを要求する。
【００５５】
サーバ１はクライアント２からの要求を受け、修復データＩＤ＝０〜９９の修復データ群を配信する（修復データ送信処理：Ｓ４００）。
【００５６】
クライアント２は修復データ群をメモリ２４に格納し、修復データＩＤ＝０〜９９の修復データに対応する欠陥Ｉピクチャを含むＧＯＰを順次復号し、再生する（復号処理：Ｓ３００）。
【００５７】
クライアント２は、メモリ２４に格納された未使用修復データ数が所定数未満になったとき、先頭修復データＩＤ＝１００とし、修復データＩＤ＝１００以降の修復データ群の配信をサーバ１に要求する（修復データ要求処理：Ｓ２００）。
【００５８】
サーバ１は修復データＩＤ＝１００〜１９９の修復データ群を配信する。クライアント２は、配信された新たな修復データ群を、メモリ２４のうち使用済み修復データが格納されているメモリ領域に格納する。この動作により、クライアント２は使用済み修復データを消去する。したがって、使用済み修復データはクライアント２に記憶されず、不正コピーに利用できない。
【００５９】
以上の動作を繰り返し、クライアント２は通常再生を継続する。
【００６０】
なお、クライアント２は早送り再生や早戻し再生といったトリック再生もできる。クライアント２が早送り再生を実行する場合（図３中（３））、クライアント２は、ＭＰＥＧファイル内のＩピクチャのみを再生する。クライアント２はさらに、再生速度（２倍速、３倍速等）に応じてＩピクチャをｎ個置きに（ｎは自然数）再生する。早送り再生時にＩピクチャを１つ置きに再生する場合、クライアント２は、次に再生する予定のＧＯＰ内の欠陥Ｉピクチャに対応する先頭修復データＩＤを決定し（図３では修復データＩＤ＝２００）、さらに、取得条件として、カウント数＝１００、検索方向＝前方、スキップ数＝１とする。要するに、クライアント２は先頭修復データＩＤ＝２００から数えて１００個（カウント数＝１００）の修復データを再生方向（検索方向＝前方）に、１つおきにスキップしながら（スキップ数＝１）送信するよう要求する。
【００６１】
サーバ１はクライアント２からの要求を受け、修復データＩＤ＝２００〜３９８のうち偶数番号の修復データ群（総計１００個）を配信する。クライアント２は修復データ群を取得し、Ｉピクチャを１つ置きにスキップして再生する。
【００６２】
早送り再生と同様に、クライアント２は早戻し再生もできる（図３中（４））。早戻し再生では、クライアント２はＩピクチャを通常再生方向と逆の方向に再生する。つまり、取得条件中の検索方向は「後方」（通常再生方向と逆の方向）になる。早戻し再生時にＩピクチャを１つ置きに再生する場合、クライアント２は、次に再生する予定のＧＯＰ内の欠陥Ｉピクチャに対応する修復データＩＤ（図３ではＩＤ＝５００）から数えて１００個（カウント数＝１００）の修復データを通常再生方向と逆の方向（検索方向＝後方）に、１つ置きにスキップして（スキップ数＝１）送信するよう指示する。
【００６３】
クライアント２から要求を受けたサーバ１は、先頭修復データＩＤ＝５００からスキップ数分デクリメントした修復データＩＤを有する修復データを収集し、ＩＤ＝５００〜３０２の偶数番号に対応する修復データ群を配信する。
【００６４】
以上の動作により、クライアント２は早戻し再生に対応した修復データ群を取得し、早戻し再生することができる。
【００６５】
以下、図３中に示した正常再生不能化処理（Ｓ１００）、修復データ要求処理（Ｓ２００）、復号処理（Ｓ３００）及び修復データ送信処理（Ｓ４００）の詳細を説明する。
【００６６】
［正常再生不能化処理］
サーバ１内のサーバアプリケーション１２は、動画データベース１１内の各ＭＰＥＧファイルに対して正常再生不能化処理（Ｓ１００）を実行し、欠陥ＭＰＥＧファイルを作成する。
【００６７】
図４を参照して、サーバアプリケーション１２はまず、ＭＰＥＧファイル内のＧＯＰをＭＰＥＧファイルの先頭から検索する（Ｓ１０１）。このとき、サーバアプリケーション１２は、ＭＰＥＧファイル内のＧＯＰヘッダを検索することによりＧＯＰを検索できる。ＧＯＰを検索したとき（Ｓ１０２でＹＥＳ）、サーバアプリケーション１２はさらに、検索したＧＯＰ内のＩピクチャを検索する（Ｓ１０３）。Ｉピクチャを検索したとき、サーバアプリケーション１２は、Ｉピクチャのピクチャヘッダを特定する。
【００６８】
サーバアプリケーション１２は、特定されたピクチャヘッダを読み出し、メモリ１４にいったん格納する（Ｓ１０４）。続いて、ＭＰＥＧファイル内の特定されたピクチャヘッダをランダムデータに置換する（Ｓ１０５）。要するに、ピクチャヘッダを削除する。これによりＩピクチャは復号不能となる。
【００６９】
サーバアプリケーション１２はさらに、Ｉピクチャに対してスクランブル処理を実行する（Ｓ１０６及びＳ１０７）。ＭＰＥＧファイル内の各画像は行列状に配置される複数のマクロブロックで構成される。サーバアプリケーション１２はスクランブル処理を実行してＩピクチャ内のマクロブロックの配置を変更する。サーバアプリケーション１２はまず、各マクロブロックの配置変更後の位置を示すスクランブルテーブルを作成する（Ｓ１０６）。サーバアプリケーション１２はさらに、配置変更されたマクロブロックの位置を元に戻すためのデスクランブルテーブルを作成する。デスクランブルテーブルは、スクランブルテーブルに基づいて作成される。スクランブルテーブル及びデスクランブルテーブルを作成後、サーバアプリケーション１２は、スクランブルテーブルに基づいて、Ｉピクチャのマクロブロックの配置を変更する（Ｓ１０７）。以上の動作によりＩピクチャは欠陥Ｉピクチャになる。欠陥Ｉピクチャを作成後、サーバアプリケーション１２はＭＰＥＧファイルを更新する（Ｓ１０８）。これにより、ＭＰＥＧファイル内のＩピクチャをステップＳ１０５〜Ｓ１０７により作成された欠陥Ｉピクチャに置き換え、欠陥ＭＰＥＧファイルにする。
【００７０】
続いて、サーバアプリケーション１２は、作成された欠陥Ｉピクチャを元の正常なＩピクチャに修復するための修復データを作成する（Ｓ１０９）。図５に修復データのデータ構造を示す。修復データは、ステップＳ１０４で読み出されたピクチャヘッダ（以下、置換データともいう）と、ステップＳ１０７で作成したデスクランブルテーブルとを含む。修復データはさらに、修復データを特定するための修復データＩＤと、対応する欠陥Ｉピクチャのタイムスタンプと、欠陥Ｉピクチャ内のランダムデータの位置（つまり、正常なＩピクチャにおけるピクチャヘッダの位置）を示すオフセットと、修復データ内の置換データ（ピクチャヘッダ）の位置情報と、置換データのデータサイズとを含む。
【００７１】
サーバアプリケーション１２はさらに、図６に示す修復テーブルを作成する（Ｓ１１０）。修復テーブルは、複数の修復レコードを含む。各修復レコードには、欠陥ＭＰＥＧファイル内の各欠陥Ｉピクチャの配列位置に関する情報と、各欠陥に対応する修復データに関する情報とが登録される。具体的には、修復レコードには、修復データＩＤと、欠陥Ｉピクチャのタイムスタンプと、欠陥Ｉピクチャ内のランダムデータの位置を示すオフセットと、欠陥Ｉピクチャのサイズと、対応する修復データのサイズとを含む。修復レコード内の修復データＩＤ、タイムスタンプ及びオフセットは、対応する修復データ内の修復データＩＤ、タイムスタンプ及びオフセットと同じである。
【００７２】
修復テーブルに修復レコードを登録後、サーバアプリケーション１２はステップＳ１０２に戻る。要するに、ＭＰＥＧファイル内の全てのＩピクチャを欠陥Ｉピクチャにする。全てのＩピクチャを欠陥Ｉピクチャにしたとき、サーバアプリケーション１２はステップＳ１０２で次のＧＯＰがないと判断し（Ｓ１０２でＮＯ）、動作を終了する。
【００７３】
以上の動作により、サーバアプリケーション１２は、欠陥ＭＰＥＧファイルと、修復データ及び修復テーブルとを作成する。
【００７４】
なお、上述の正常再生不能化処理では、ＭＰＥＧファイル内の全てのＩピクチャを欠陥Ｉピクチャとしたが、全てのＩピクチャを欠陥Ｉピクチャにしなくてもよい。たとえば、１つおきにＩピクチャを欠陥Ｉピクチャにしてもよい。
【００７５】
［修復データ要求処理］
続いて、図３中の修復データ要求処理（Ｓ２００）について説明する。図７を参照して、クライアント２内の要求アプリケーション２２は、ユーザ操作によりＭＰＥＧファイルの再生指示が入力されたか否かを監視する（Ｓ２０１）。クライアント２は、マウスやキーボード等の図示しない入力装置を備え、クライアント２のユーザは入力装置を用いて再生指示を入力する。
【００７６】
再生指示が入力されたとき（Ｓ２０１でＹＥＳ）、要求アプリケーション２２は図８に示す修復データ要求コマンドを作成し送信する（Ｓ２０２〜Ｓ２０５）。修復データ要求コマンドは、取得する修復データ群のうち先頭の修復データのＩＤである先頭修復データＩＤと、取得条件であるカウント数、検索方向及びスキップ数とを含む。カウント数は取得する修復データ数を示す。
【００７７】
要求アプリケーション２２はまず、修復データ要求コマンドに含める先頭修復データＩＤ＝０とする（Ｓ２０２）。続いて、ユーザ操作により指示された再生の種類（通常再生、早送り再生、早戻し再生等）及び再生速度（２倍速、３倍速等）を特定する（Ｓ２０３）。以降、通常再生が指示されたと仮定する。
【００７８】
要求アプリケーション２２は、ステップＳ２０３で特定された再生種類及び再生速度に基づいて、取得条件を決定する（Ｓ２０４）。具体的には、検索方向＝前方（再生方向）、スキップ数＝０とし、要求する修復データ数を示すカウント数を所定の数（たとえば１００）に決定する（Ｓ２０４）。以上の動作により、図８に示す修復データ要求コマンドが作成される。要求アプリケーション２２は、作成された修復データ要求コマンドをサーバ１に送信する（Ｓ２０５）。
【００７９】
サーバ１は修復データ要求コマンドを受信し、後述する修復データ送信処理により、先頭修復データＩＤの修復データから要求された数（ここでは１００個）の修復データ群を送信する（図３中のＳ４００）。要求アプリケーション２２は、サーバ１から送信された修復データ群を取得し（Ｓ２０６）、メモリ２４に格納する（Ｓ２０７）。このとき、格納された各修復データ（未使用修復データ）には、未使用であることを示す未使用フラグが立てられる。
【００８０】
クライアント２は後述する復号処理（図３中のＳ３００）で、欠陥ＭＰＥＧファイル内の欠陥Ｉピクチャを対応する修復データを用いて正常なＩピクチャに順次修復し、復号する。欠陥Ｉピクチャを順次修復することにより、欠陥ＭＰＥＧファイルは正常に再生される。使用された修復データ（使用済み修復データ）には、未使用フラグに代えて、使用済みを示す使用済みフラグが立てられる。
【００８１】
再生中、要求アプリケーション２２は、メモリ２４内の未使用修復データの数を監視する（Ｓ２０８）。未使用修復データの数が所定数以上であるとき（Ｓ２０８でＮＯ）、ユーザ操作による再生終了指示、又は再生変更指示がなければ（ステップＳ２１１及びＳ２１２でＮＯ）、ステップＳ２０８に戻って監視を継続する。
【００８２】
一方、未使用修復データ数が所定数未満となったとき（Ｓ２０８でＹＥＳ）、要求アプリケーション２２は、新たな修復データ群を取得する準備をする。
【００８３】
要求アプリケーション２２はまず、メモリ２４のうち使用済み修復データが格納されているメモリ領域を解放する（Ｓ２０９）。
【００８４】
続いて、次にサーバ１に要求する修復データ群の先頭修復データＩＤを特定する（Ｓ２１０）。要求アプリケーション２２は、既にメモリ２４に格納された複数の修復データのうち、ステップＳ２０４で決定された検索方向で末尾に相当する修復データＩＤを特定する。次に、末尾の修復データＩＤに対応する欠陥Ｉピクチャの次に復号される予定の欠陥Ｉピクチャを特定する。特定された欠陥Ｉピクチャに対応する修復データＩＤを先頭修復データＩＤとする。
【００８５】
たとえば、通常再生の場合であって、メモリ２４に修復データＩＤ＝０〜９９の修復データが登録されているとき、検索方向（再生方向）で末尾に相当する修復データＩＤ＝９９を特定し、その修復データに対応する欠陥Ｉピクチャの次に復号される予定の欠陥Ｉピクチャに対応する修復データＩＤ＝１００を先頭修復データＩＤに特定する。
【００８６】
要求アプリケーション２２は、ステップＳ２１０で特定された先頭修復データＩＤ（＝１００）と、ステップＳ２０４で既に決定された取得条件（カウント数、検索方向、スキップ数）とを含む修復データ要求コマンドを作成し、サーバ１に送信する（Ｓ２０５）。サーバ１は修復データ要求コマンドを受信し、修復データＩＤ＝１００〜１９９の修復データ群をクライアント２に送信する。
【００８７】
要求アプリケーション２２は、修復データＩＤ＝１００〜１９９の修復データ群を取得し（Ｓ２０６）、メモリ２４に格納する（Ｓ２０７）。このとき、要求アプリケーション２２は、取得した修復データ群を、メモリ２４のうちステップＳ２０９で解放されたメモリ領域に優先的に格納する。この動作により、要求アプリケーション２２は、使用済み修復データをメモリ２４から消去する。このように要求アプリケーション２２は使用済み修復データを順次消去するため、使用済み修復データが不正コピーに使用されるのを防止できる。
【００８８】
以上の動作を繰り返し、要求アプリケーション２２は、使用済み修復データを順次消去し、新たな修復データ群を随時取得する。要求アプリケーション２２が修復データを１つずつ要求する場合、サーバ１との間のトラフィックが混雑する。一方、欠陥ＭＰＥＧファイル用の修復データの全てを一度に取得する場合、取得した修復データの全てをメモリ２４に格納できず、取得した修復データをＨＤＤ２０に格納しなければならない場合が生じる。修復データをＨＤＤ２０に格納する場合、修復データを不正コピーに利用される可能性が生じる。本実施の形態では、要求アプリケーション２２は、複数の修復データの束（修復データ群）を随時取得するため、サーバ１との間のトラフィックを緩和できる。また、取得した修復データ群をメモリ２４に格納し、使用済み修復データを随時消去することにより、修復データが不正コピーに利用されるのを防止できる。
【００８９】
なお、ユーザ操作により、再生終了指示がクライアント２に入力されたとき、要求アプリケーション２２は再生終了指示を受けたと判断する（Ｓ２１１でＹＥＳ）。この場合、要求アプリケーション２２は、メモリ２４のうち、修復データ（未使用及び使用済みを含む）が格納されたメモリ領域を全て解放し、終了する（Ｓ２１８）。修復データが格納されたメモリ領域は解放されているため、新たなデータが上書きされ、修復データは消去される。したがって、修復データが不正コピーに使用されるのを防止できる。
【００９０】
なお、ステップＳ２０１でユーザ操作により早送り再生が指示されたと判断した場合、ステップＳ２０４で検索方向は「前方」に決定され、スキップ数は再生速度に応じて設定される。また、ステップＳ２０１で早戻し再生が指示されたと判断した場合、ステップＳ２０４で検索方向は「後方」に決定され、スキップ数は再生速度に応じて設定される。
【００９１】
［再生変更時の修復データ要求処理］
ＭＰＥＧファイルを再生中に再生の種類を変更したとき、たとえば通常再生を早戻し再生（２倍速）に変更したとき、図７中のステップＳ２１２で、要求アプリケーション２２は再生が変更されたと判断する（Ｓ２１２でＹＥＳ）。この場合、要求アプリケーションは変更された再生の種類を「早戻し再生」、再生速度を「２倍速」と特定する（Ｓ２１３）。
【００９２】
続いて、要求アプリケーション２２は、再生種類、再生速度に対応した修復データを取得するための修復データ要求コマンドを作成する（Ｓ２１４〜Ｓ２１６）。要求アプリケーション２２はまず、ステップＳ２１３で特定した再生種類及び再生速度に基づいて、取得条件を決定する。具体的には、スキップ数＝１００、検索方向＝後方（再生方向と逆の方向）、スキップ数＝１（２倍速に対応）と決定する（Ｓ２１４）。スキップ数は、再生速度に応じて設定される。
【００９３】
続いて、修復データ要求コマンドに含める先頭修復データＩＤを特定する（Ｓ２１５及びＳ２１６）。具体的には、後述する復号処理により直近に復号された画像（Ｉ、Ｂ、Ｐピクチャ）のオフセットを特定し（Ｓ２１５）、特定されたオフセットからステップＳ２１４で決定された検索方向に向かって最も近いオフセットを有する修復データＩＤを修復テーブルに基づいて特定する。特定された修復データＩＤを先頭修復データＩＤとする（Ｓ２１６）。
【００９４】
以上の動作により、修復データ要求コマンドが作成される。修復データ要求コマンドを作成後、要求アプリケーション２２は、メモリ２４のうち、修復データが既に登録されたメモリ領域を全て解放する（Ｓ２１７）。再生種類が変更されたため、既に取得した修復データを全て消去するためである。
【００９５】
メモリ領域を解放した後、要求アプリケーション２２はステップＳ２０５に戻り、新たな修復データ群を取得する。
【００９６】
以上の動作により、再生実行中に再生種類を変更しても、変更された再生種類に対応して修復データ要求コマンドを作成し、修復データ群を取得できる。また、既に修復データが格納されたメモリ領域を解放することにより、再生変更前に取得した修復データを消去できる。
【００９７】
［復号処理］
図９を参照して、復号アプリケーション２５は、ユーザの操作により再生開始指示を受けたとき（Ｓ３０１でＹＥＳ）、再生の種類及び再生速度を特定する（Ｓ３０２）。以下、通常再生の指示を受けたと仮定して説明する。
【００９８】
復号アプリケーションは欠陥ＭＰＥＧファイル内の連続して配列されたピクチャ（フレーム）のうち、先頭のピクチャを特定する（Ｓ３０３）。続いて、特定されたピクチャがＩピクチャであるか否かを判断する（Ｓ３０４）。Ｉピクチャである場合（Ｓ３０４でＹＥＳ）、そのＩピクチャは欠陥Ｉピクチャであるため、修復データを用いて正常なＩピクチャに修復する（Ｓ３０５及びＳ３０６）。
【００９９】
復号アプリケーション２５はまず、特定されたＩピクチャに対応する修復データを特定する（Ｓ３０５）。具体的には、復号アプリケーション２５は修復テーブルを参照し、特定されたＩピクチャのオフセットを含む修復レコードに登録された修復データＩＤを特定する。
【０１００】
続いて、復号アプリケーション２５は、特定された修復データＩＤの修復データをメモリ２４から読み出し、欠陥Ｉピクチャを修復する（Ｓ３０６）。復号アプリケーション２５はまず、修復テーブル内のオフセット（ピクチャヘッダ位置）に基づいて、欠陥Ｉピクチャ内のランダムデータを修復データ内のピクチャヘッダに置き換える。続いて、修復データ内のデスクランブルテーブルに基づいて、欠陥Ｉピクチャ内のマクロブロックをスクランブル処理前の元の配置に戻す。以上の動作により、復号アプリケーション２５は欠陥Ｉピクチャを正常なＩピクチャに修復する。
【０１０１】
修復後、復号アプリケーション２５は、修復に使用した修復データに使用済みフラグを立てる（Ｓ３０７）。これにより、修復データ要求処理において、要求アプリケーション２２は、使用済み修復データを格納したメモリ領域を解放できる。復号アプリケーション２５は修復されたＩピクチャを復号し（Ｓ３０８）、復号されたＩピクチャをメモリ２４に格納する（Ｓ３０９）。
【０１０２】
再生終了指示を受けていない場合（Ｓ３１０でＮＯ）、復号アプリケーション２５は、欠陥ＭＰＥＧファイルのうち、次に復号すべきピクチャが存在するか否かを判断する（Ｓ３１１）。次に復号すべきピクチャは再生種類及び再生速度に応じて決定される。通常再生の場合、ＭＥＰＧファイル内のピクチャの配列順に復号するため、復号アプリケーション２５は、次に配列されたピクチャが存在するか否か判断する（Ｓ３１１）。
【０１０３】
次に配列されたピクチャが存在する場合（Ｓ３１１でＹＥＳ）、そのピクチャを特定する（Ｓ３１２）。復号アプリケーション２５は、特定されたピクチャに対してステップＳ３０４以降の動作を実行する。特定されたピクチャがＢピクチャ又はＰピクチャである場合（Ｓ３０４でＮＯ）、これらのピクチャは正常であるため、そのまま復号する（Ｓ３０８）。
【０１０４】
以上の動作を繰り返し、配列された複数のピクチャを順次復号する。再生アプリケーション２６は、復号されてメモリ２４に格納されたピクチャを再生する。
【０１０５】
以上、復号処理では、欠陥Ｉピクチャを修復し、修復したＩピクチャを復号する。そのため、クライアント２は、欠陥ＭＰＥＧファイルを正常に再生できる。さらに、使用済み修復データに対しては使用済みフラグを立てるため、修復データ要求処理において使用済み修復データが格納されたメモリ領域を解放し、新たな修復データを上書きできる。そのため、使用済み修復データを消去することができ、修復データを利用した不正コピーを防止できる。
【０１０６】
上述の説明では、全てのＩピクチャを欠陥Ｉピクチャとしたが、複数のＩピクチャのうちのいくつかを欠陥Ｉピクチャとしてもよい。この場合ステップＳ３０４でＩピクチャと特定し、さらにそのＩピクチャが欠陥Ｉピクチャであるか否かを修復テーブルに基づいて判断する。具体的には、ステップＳ３０４で特定されたＩピクチャのオフセットが修復テーブルに登録された修復レコード内のオフセットと一致するか否か判断する。一致すれば、そのＩピクチャは欠陥Ｉピクチャであるため、修復する（Ｓ３０５及びＳ３０６）。
【０１０７】
なお、ステップＳ３０２で特定された再生種類が「早送り再生」の場合、復号アプリケーションは複数のピクチャのうちＩピクチャのみを復号する。したがって、ステップＳ３１１で復号アプリケーション２５は次に配列されたＩピクチャが存在するか否かを判断し、存在する場合、ステップＳ３１２でそのＩピクチャを特定する。なお、「早送り再生」の「再生速度」に応じて、Ｉピクチャをスキップすることもある。たとえば、修復データ要求処理における修復データ要求コマンド内のスキップ数が「１」である場合、復号アプリケーションはＩピクチャを１つ置きに順次復号する。ステップＳ３０２で特定された再生種類が「早戻し再生」の場合も同様である。
【０１０８】
［修復データ送信処理］
続いて、図３中の修復データ送信処理（Ｓ４００）について説明する。図１０を参照して、サーバアプリケーション１２は、修復データ要求コマンドの受信を監視する（Ｓ４０１）。
【０１０９】
修復データ要求コマンドを受信したとき（Ｓ４０１でＹＥＳ）、サーバアプリケーション１２はクライアント２に送信する修復データの修復データＩＤを特定する（Ｓ４０２）。サーバアプリケーションはまず、クライアント２に送信する修復データとして、修復データ要求コマンド内の先頭修復データＩＤを特定する。続いて、修復テーブルに基づいて、コマンド内の検索方向及びスキップ数に応じた次の修復データＩＤを特定する。たとえば、図８に示す修復データ要求コマンドの場合、先頭修復データＩＤ＝０、検索方向＝前方、スキップ数＝０であるため、次の修復データＩＤを「１」と特定する。サーバアプリケーション１２は特定された修復データＩＤの数がカウント数と同じ数になるまで修復データＩＤを特定する。
【０１１０】
修復データＩＤの特定を完了した後、サーバアプリケーションは特定された修復データＩＤに対応した修復データを収集し（Ｓ４０３）、収集された修復データ群をクライアント２に送信する（Ｓ４０４）。
【０１１１】
以上のとおり、サーバアプリケーション１２は、修復データ要求コマンドの内容に応じて、修復テーブルを参照して送信すべき修復データを収集する。
【０１１２】
以上、本実施の形態では、クライアント２に送信すべき修復データＩＤの特定をサーバ１で実行したが（図１０中のステップＳ４０２）、クライアント２で修復データＩＤを特定してもよい。この場合、クライアント２から送信される修復データ要求コマンドは、取得すべき複数の修復データの修復データＩＤを含むが、カウント数、検索方向、スキップ数等の情報を含める必要はない。
【０１１３】
また、上述の実施の形態では、Ｉピクチャのマクロブロックをスクランブル処理したが、スクランブル処理に代えて、各マクロブロックの輝度や色差データを変更することにより正常に再生できなくしてもよい。
【０１１４】
本実施の形態では、Ｉピクチャに対してのみ正常再生不能化処理を実行したが、複数のＢ、Ｐピクチャのうちのいくつかに対して正常再生不能化処理を実行してもよい。
【０１１５】
本実施の形態では、修復データ内にデスクランブルテーブルを含めたが、クライアント２が予め複数のデスクランブルテーブルを有してもよい。この場合、各デスクランブルテーブルはデスクランブルＩＤを有する。正常再生不能化処理において、サーバアプリケーション１２は、クライアント２が有する複数のデスクランブルテーブルに対応する複数のスクランブルテーブルのうちのいずれかで各Ｉピクチャをスクランブル処理し、処理に使用したスクランブルテーブルに対応するデスクランブルテーブルのデスクランブルＩＤを修復データに含める。復号アプリケーション２５は、修復データ内のデスクランブルＩＤによりデスクランブルテーブルを特定し、特定されたデスクランブルテーブルを用いて欠陥Ｉピクチャのスクランブルを解除する。この場合、修復データに含まれるデータ量をさらに少なくすることができる。
【０１１６】
本実施の形態におけるＭＰＥＧファイルは、ＭＰＥＧ１、ＭＰＥＧ２、ＭＰＥＧ４、ＭＰＥＧ７といったＭＰＥＧ形式のファイルである。動画圧縮ファイルのうち、単独で復号可能な基本画像と、単独で復号できず基本画像を利用して復号される差分画像とで構成されるものであれば本発明を適用できる。
【０１１７】
以上、本発明の実施の形態を説明したが、上述した実施の形態は本発明を実施するための例示に過ぎない。よって、本発明は上述した実施の形態に限定されることなく、その趣旨を逸脱しない範囲内で上述した実施の形態を適宜変形して実施することが可能である。
【図面の簡単な説明】
【０１１８】
【図１】本発明の実施の形態によるコンテンツ配信システムの構成を示す機能ブロック図である。
【図２】図１に示すコンテンツ配信システムの概要を示す図である。
【図３】図１中のコンテンツ配信システムの動作を示すシーケンス図である。
【図４】図３中の正常再生不能化処理の詳細を示すフロー図である。
【図５】図４中のステップＳ１０９で作成される修復データのデータ構造を示す図である。
【図６】図４中のステップＳ１１０で作成される修復テーブルのデータ構造を示す図である。
【図７】図３中の修復データ要求処理の詳細を示すフロー図である。
【図８】図７中のＳ２０５で送信される修復データ要求コマンドに含まれる情報を示す図である。
【図９】図３中の復号処理の詳細を示すフロー図である。
【図１０】図３中の修復データ送信処理の詳細を示すフロー図である。
【符号の説明】
【０１１９】
１  サーバ
２  クライアント
３  インターネット
１１，２１  動画データベース
１２  サーバアプリケーション
２２  要求アプリケーション
２４  メモリ
２５  復号アプリケーション
２６  再生アプリケーション
【図１】
2007116445.tif 000003
【図２】
2007116445.tif 000004
【図３】
2007116445.tif 000005
【図４】
2007116445.tif 000006
【図５】
2007116445.tif 000007
【図６】
2007116445.tif 000008
【図７】
2007116445.tif 000009
【図８】
2007116445.tif 000010
【図９】
2007116445.tif 000011
【図１０】
2007116445.tif 000012