配信ネットワークを介したマルチメディアコンテンツの配信方法
本発明は、ネットワークを介して送信されるコンテンツを一組のスライスに分割し、当該スライス群から一組のファイルを生成することを提案する。スライス（またはファイル）は、係る解読鍵の取得前にクライアントがスライス（またはファイル）を利用できないようにダウンロード前に暗号化される。従って、本発明は、ダウンロードされたコンテンツ全体をプロテクトするよりも、スライスごとに（またはファイルごとに）ダウンロードされたコンテンツをプロテクトすることを可能にする。サーバとクライアントの間の送信（ダウンロードモードによる）は、すべてのファイアウォール及びＮＡＴにより受付けられているＨＴＴＰプロトコルにより規制される。この結果、送信されたコンテンツは、制限なくウェブにアクセスできる任意のクライアント装置にアクセス可能となる。効果的には、スライスは、互いに独立に復号可能である。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クライアント装置にマルチメディアコンテンツを送信する方法に関する。本発明はまた、当該送信方法を実現するよう具体的に構成されたクライアント装置、コンテンツサーバ及びシステムに関する。
【０００２】
本発明は、インターネットを介したクライアント装置への有料コンテンツの送信、特にライブコンテンツ（ライブイベント、ライブショー、放送テレビ番組など）の送信のための興味深いアプリケーションを有する。
【背景技術】
【０００３】
欧州特許出願第１１８７４２３号は、音楽や映像など時間の経過と共に変換するコンテンツを有するオンデマンド情報を送信する方法について記載している。特に、それは１つのコンテンツを複数のファイルに分割し、第１ファイルから開始してコンテンツをファイル単位でダウンロードすることから構成されるいわゆるバッファリング配信方法について記載している。このバッファリング配信方法は、再生開始前の待機時間を短縮するという効果を提供するものとして説明されている（パーツＮがダウンロードされている間に、パーツＮ−１を再生することが可能である）。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
本発明の一課題は、そのような配信方法に対する改良を提案することである。
【課題を解決するための手段】
【０００５】
これは、請求項１乃至３記載のシステム、請求項４乃至７記載のコンテンツサーバ、請求項８及び９記載のクライアント装置、及び請求項１０記載の方法により達成される。
【０００６】
本発明によるシステムは、
マルチメディアコンテンツを取得するソースと、
前記マルチメディアコンテンツを符号化するエンコーダと、
前記符号化されたマルチメディアコンテンツを少なくとも一組のスライスにスライスし、前記少なくとも一組のスライスから少なくとも一組のファイルを提供し、ファイルに含まれるスライスが、係る解読鍵なしには利用できないように暗号化アルゴリズムを実現するスライサと、
配信ネットワークと、
クライアント装置に前記配信ネットワークへのアクセスを提供するアクセスプロバイダと、
前記配信ネットワークにリンクされ、前記クライアント装置からのリクエストの受信に応答して、前記配信ネットワークを介し前記ファイルの少なくとも１つを前記クライアント装置にダウンロードするため、前記一組以上のファイルにアクセスするコンテンツサーバと、
前記配信ネットワークにリンクし、前記ダウンロードしたファイルに係る前記１以上の解読鍵を前記クライアント装置に提供するキーサーバと、
を有する。
【発明の効果】
【０００７】
本発明によると、コンテンツは一組のスライスに分割され、各スライスに対して、ファイルが生成される。スライス（またはファイル）は、クライアント装置が係る解読鍵を取得する前にスライス（またはファイル）を利用できるようにダウンロード前に暗号化される。これにより、本発明は、ダウンロードされたコンテンツを全体的にプロテクトするのではなく、ダウンロードされたコンテンツをスライスごと（またはファイルごと）にプロテクトすることを可能にする。
【０００８】
これは以下の理由から効果的である。ダウンロードされたコンテンツが暗号化を介しプロテクトされると、ダウンロードの成功を確認し（これにより、クライアントが最終的に受け取っていないものに対して支払いをするリスクを解消し）、クライアントがコンテンツを視聴し、課金前に切断することを回避するため、ダウンロードの完了後に解読鍵が通常は提供される。当該スライス（またはファイル）を１つずつ（またはグループごとに）プロテクトすることは、クライアントが支払いを済ませたものを適切に受信し、支払いをしていないものを利用することができないことを保証しながら、すべてのファイルがダウンロードされる前にコンテンツの解読及び再生開始をするのを可能にする。
【０００９】
本発明によると、クライアントは、予めコンテンツ全体に対する支払いをする必要はない。再生の進捗に応じて、支払いが進捗する。クライアントは、コンテンツを再生開始し、所望する場合には、コンテンツ全体がダウンロードされる前に切断することができる。このような場合、クライアントは、最終的に受信したものに対する支払いのみを行うことになる。
【００１０】
本発明は、コンテンツプロバイダとクライアントの両方に利益を保護する。
【００１１】
本発明によると、ファイルベースのコンテンツが、ポイント・ツー・ポイント接続を介しコンテンツサーバからクライアント装置にダウンロードされる。ＩＰネットワークを介し、ポイント・ツー・ポイント接続は通常はＨＴＴＰプロトコル（ＩＥＴＦのＲＦＣ２６１６に規定されるＨｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）により規制される。ＨＴＴＰプロトコルは、ワールドワイドウェブに基づくものであり、従って、すべてのファイアフォールとネットワークアドレストランスレータ（ＲＴＰ／ＵＤＰトランスポートプロトコルのケースではない）により受付けられるという大きな効果を有する。このことは、送信されたコンテンツが制限なくワールドワイドウェブにアクセス可能な任意のクライアント装置にアクセス可能であるということを意味する。ダウンロード配信モードを利用する他の効果は、それを信頼性の高いものにするということである。
【００１２】
しかしながら、欧州特許出願第１１８７４２３号に記載されるタイプのダウンロード配信モードを利用することは、第１ファイルから始まりすべてのファイルを送信する必要があるという欠点を有する。このようなダウンロード配信モードによると、クライアントはランダムにコンテンツにアクセスすることはできない。ライブコンテンツ（すなわち、ライブイベント、ライブショー、放送テレビ番組などのリアルタイムに利用可能なコンテンツ）の送信は実現できない。
【００１３】
本発明の効果的な実施例では、互いに独立して復号できるようにスライスが生成される。このことは、クライアントがそれの始めからコンテンツを受信する必要がないことを意味する。それは、任意のスライスからコンテンツの受信を開始することができる。クライアントがライブコンテンツに対する最初のリクエストを送信すると、クライアントは前のファイルを受信するか（クライアントがやや古い情報を受信することを意味する）、または、次のファイルが準備できるまで待機する必要がある。
【００１４】
本発明によると、クライアント装置によるリクエストの受信により、１つのファイルのみしかダウンロードすることはできない。このことは、特定の用途に対しては、決勝戦の最中に結果のダイジェストをクライアントが取得することを可能にするという効果がある。
【００１５】
複数のファイルがダウンロードされるとき、これらのファイルはクライアント装置により１つずつフェッチ可能であるか、あるいは、最初のリクエストの受信によりコンテンツサーバによって１つずつ送信することも可能である。実際、すべてのクライアントブラウザが１つのリクエストに応答して複数のファイルの受信をサポートするということは保証されていない。従って、クライアント装置がファイルを１つずつフェッチすることが通常は望まれる（すなわち、ダウンロードされる各ファイルに対するフェッチリクエストの送信）。クライアント装置は、適切な時点にフェッチリクエストを自動的に送信するよう具体的に構成することが可能である。あるいは、コンテンツサーバは、クライアント装置にフェッチリクエストを繰り返し送信させる文書をクライアント装置に送信することができる。効果的には、当該文書は、クライアント装置が前のファイルの再生終了の所定時間前に、以降のフェッチリクエストを送信する命令を有する。このように、次のファイルが十分早くクライアント装置に到着し、クライアントが再生処理におけるギャップを受けないことが保証される。
【発明を実施するための最良の形態】
【００１６】
図１は、本発明によるシステムの第１実施例の概略図である。図１のシステムは、マルチメディアコンテンツを取得するソース１と、受信したマルチメディアコンテンツを符号化するエンコーダ５と、符号化したマルチメディアコンテンツを一組のスライスにスライスし、各ファイルが前記符号化したマルチメディアコンテンツの一スライスを有する一組のファイルを提供し、ファイルに含まれる少なくとも当該スライスがそれに係る解読鍵なしには利用することができないように暗号化アルゴリズムを実現するスライサ６と、前記ファイルにアクセスするコンテンツサーバ８と、コンテンツサーバ８にリンクする配信ネットワーク１０と、クライアント装置１４に配信ネットワーク１０とのアクセスを提供するアクセスプロバイダ１２と、配信ネットワーク１０とリンクし、クライアント装置１４にダウンロードしたファイルに係る１以上の解読鍵を提供するキーサーバ１５とを有する。
【００１７】
図１のシステムでは、ソース１、エンコーダ５及びスライサ６は、１つまたは複数の装置に物理的に配置されていてもよい。
【００１８】
図２は、本発明によるシステムの第２実施例の概略図である。図１を参照して上述された要素に加えて、図２のシステムは、ソース１により与えられるマルチメディアコンテンツを配信する配信システム１６と、配信されたマルチメディアコンテンツを受信し、受信したマルチメディアコンテンツをスライサ６に転送する受信機１７とを有する。
【００１９】
クライアント装置１４は、アクセスプロバイダ１２との送受信のための通信ユニット２０と、符号化されたマルチメディアコンテンツを再生するプレーヤー２２と、マルチメディアコンテンツを表示するディスプレイ２４とを有する（図１に示されていない他の手段の中で）。クライアント装置１４は、通信ユニット２０が無線通信ユニットとなるモバイル装置（携帯電話など）、または通信ユニット２０が有線通信ユニットとなる有線装置（ＰＣなど）の何れであってもよい。配信ネットワーク１０は、典型的にはインターネットネットワークである。
【００２０】
例えば、配信システム１６は衛星配信ネットワークであり、受信機１７は衛星受信機である。このことは限定的ではない。すなわち、他の任意の配信手段が、衛星配信手段の代わりに利用可能である。配信されるマルチメディアコンテンツは、受信機１７を含むいくつかの受信機により受信可能であって、送信される任意のマルチメディアコンテンツであってもよい。配信マルチメディアコンテンツは、例えば、テレビ番組、予め記録されたイベント／番組、ライブイベントなどであってもよい。エンコーダ５は、受信したマルチメディアコンテンツを符号化するためのものである。エンコーダ５は、例えば、ＭＰＥＧ規格やＨ２６３に準拠する。
【００２１】
エンコーダ５とスライサ６は、単一の装置または２つの独立した装置により実現される。何れの場合でも、エンコーダ５からスライサ６に送信されるものは、符号化された映像ストリームである。効果的には、この符号化映像ストリームは、ＲＴＰプロトコルを利用することによりＩＰを介しエンコーダ５からスライサ６に送信される。これは限定的なものではない。例えば、ＭＰＥＧ−２ ＴＳとして知られるＭＰＥＧ−２規格のトランスポートレイヤもまた利用可能である。
【００２２】
実際、スライサ６により生成されたファイルは、コンテンツサーバ８がアクセスするストレージユニット２６に格納される。ストレージユニット２６は、スライサ６とコンテンツサーバ８により共有されている。ストレージユニット２６は、コンテンツサーバ８の一部とすることも可能であり、あるいは遠隔配置することも可能である。
【００２３】
スライサ６は、以下の機能を有する。
ａ）それは、エンコーダ５により生成される符号化されたコンテンツを、各スライスが当該符号化マルチメディアコンテンツの所定時間からなる複数のスライスにスライスする。
ｂ）それは、各スライスからファイルを生成する。
ｃ）それは、ファイルに含まれる少なくとも当該スライスが、それに係る解読鍵なしには利用できないように暗号化アルゴリズムを実現する。これは、スライスまたはファイルを暗号化することにより実現可能である。ファイルの暗号化は簡単であるという効果を有する。スライスの暗号化はより複雑である。しかしながら、それは、第１ファイルを解読する必要なく、クライアント側でファイル構造（ヘッダなどに）に含まれるファイル情報へのアクセスを可能にする。例えば、スライサ６により用いられる暗号化アルゴリズムは、ＡＥＳ（Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）である。暗号化は、暗号鍵を用いて実行される。係る解読鍵が、符号化されたエンティティ（スライスまたはファイル）の解読を実現するのに必要とされる。キーサーバ１５は、暗号鍵をスライサ６に送り、解読鍵をクライアント装置１４に送信するためのものである。
【００２４】
スライサ６は、同一のマルチメディアコンテンツに対して複数のファイル群を生成することが可能である。例えば、スライサ６が複数のファイル群を生成するとき、スライス位置の各組がスライス位置のその他の組と比較して時間シフトされている複数のスライス位置の組が利用可能である。複数のファイル群を生成することは、クライアントがライブコンテンツに対するリクエストを送信するとき、クライアントが被る遅延を低減することを可能にするため効果的である。
【００２５】
図３は、スライス位置Ｔｉｊ（ｊ＝１，．．．，Ｎ−１）において符号化されたマルチメディアコンテンツをスライスすることによって、スライサ６により生成されるファイルＦｉｊ（ｊ＝１，．．．，Ｎ）の組Ｓｉを表す。
【００２６】
効果的な実施例では、これらのスライスは、互いに独立に復号できるように生成される。実際、マルチメディアエンコーダにより生成される任意の符号化マルチメディアコンテンツは、いわゆるランダムアクセスポイント（ＲＡＰ）から構成される。その他のものとは独立に復号可能なスライスを生成するため、スライサ６は、各スライスがランダムアクセスポイントから開始されるように符号化されたマルチメディアコンテンツをスライスする。例えば、エンコーダがＭＰＥＧ−２またはＭＰＥＧ−４規格に準拠しているとき、ランダムアクセスポイントは、ＭＰＥＧ符号化マルチメディアコンテンツのＩフレームであり、スライス位置は、各スライスの第１フレームがＩフレームとなるように選ばれる。
【００２７】
任意的には、スライスのサイズは調整可能である。それはすべてのスライスに対して同一であってもよいし、あるいは、スライスごとに可変とされてもよい（例えば、スライスのサイズは、時間の経過と共に大きくなるようにしてもよい）。最善の効率は、多くのファイルが転送されるほど、ファイルヘッダによるより大きなオーバーヘッドがもたらされるという理由から、比較的長いファイルにより得られる。
【００２８】
スライサ６により生成される各ファイルは、ストレージユニット２６にファイルとして格納される。ストレージユニット２６は、新たに生成されたファイルを格納するためのスペースが利用可能でことを保証するため、通常は「クリーン」にされる必要がある。ストレージユニットをクリーニングする方法は、通常はファイル名を再利用するというものである。他の方法は、各ファイルに対して異なるファイル名を使用し、通常は時間が経過したファイルを削除するというものである。
【００２９】
コンテンツサーバ８とキーサーバ１５は、配信ネットワーク１０を介しリンクする。クライアント装置１４は、アクセスプロバイダ１２を介し配信ネットワーク１０にアクセスする。典型的には、クライアント装置１４は、配信ネットワーク１０を介し、クライアントサーバ８がダウンロードするため提供する１つの符号化マルチメディアコンテンツとの少なくとも１つのリンクを有するページをロードすることができる。ユーザが当該リンクをクリックすると、符号化マルチメディアコンテンツに向けられた最初のリクエストＲ０が、自動的にコンテンツサーバ８に送信される。コンテンツサーバ８が最初のリクエストＲ０を処理する方法は、複数存在する。
【００３０】
第１実施例では、コンテンツサーバ８は、クライアントレクエストに応答して、１つのファイルをダウンロードする。当該実現形態は、ライブイベントに関する情報を抽出するためクライアントに提供するアプリケーションなどの特定のアプリケーションに利用可能である。それはまた、クライアント装置１４に最初のリクエストＲ０を繰り返し送信させるよう具体的に構成されたプレーヤー２２により利用可能である。
【００３１】
第２実施例では、コンテンツサーバ８は、ファイルがサーバ側で準備できるとすぐに、１つずつダウンロードする。本実施例は、実現が容易であるという効果を有する。しかしながら、１つのリクエストに応答して、クライアントブラウザは複数のファイルの受信をサポートしていない可能性がある。
【００３２】
第３実施例では、コンテンツサーバ８は、最初のリクエストＲ０を受信すると、クライアント装置に文書を送信する。この文書は、クライアント装置１４に符号化されたマルチメディアコンテンツを指定するフェッチしたリクエストを繰り返し送信させる。
【００３３】
例えば、コンテンツサーバ８により送信される文書は、自動リフレッシュコマンドを有するページであってもよい。このようなページの一例として、以下のものが与えられる。
【００３４】
【表１】
このようなページは、クライアントブラウザに１３４秒（本実施例のファイルの所要時間）ごとに「ｌｉｖｅ２ｄｏｗｎｌｏａｄ．ｍｐ４」ファイルをリロードさせる。
【００３５】
あるいは、コンテンツサーバ８により送信される文書は、標準的な方法によりプレーヤー２２により処理されるマルチメディアコンテンツの標準的記述であってもよい。このような記述は、例えば、ＳＭＩＬ記述であってもよい（ＳＭＩＬは、ＸＭＬベースの音声／映像シーン記述を規定するＷ３Ｃ規格である）。このようなＳＭＩＬ記述の一例が、以下に与えられる。
【００３６】
【表２】
このＳＭＩＬ文書の効果は、プレーヤー１７に「ｌｉｖｅ２ｄｏｗｎｌｏａｄ．ｍｐ４」ファイルを繰り返し再生させることである。この結果、クライアント装置は、「ｌｉｖｅ２ｄｏｗｎｌｏａｄ．ｍｐ４」ファイルに対するフェッチしたリクエストを繰り返し送信する。
【００３７】
効果的には、コンテンツサーバ８により送信されるＳＭＩＬ文書は、ファイルが予めある時間だけ（すなわち、前のファイルの再生の終了前の時間）フェッチされる必要があることを示すコマンドを有する。このことは、クライアントにマルチメディアコンテンツのレンダリングにおいてギャップが生じないように、次のファイルが時間内にクライアント装置１４に到達することを保証する。このようなコマンドを有するＳＭＩＬ記述の一例が、以下に与えられる。
【００３８】
【表３】
当該記述は、３０秒のコンテンツを含むスライスに対して書かれている。それは、プレーヤー１７に以下の処理を逐次的に実行させる。すなわち、
ａ）第１ソース（ｌｉｖｅ２ｄｏｗｎｌｏａｄ１．ｍｐ４）の最初の２５秒を再生する
ｂ）第１ソースの最後の５秒を再生し、第２ソース（ｌｉｖｅ２ｄｏｗｎｌｏａｄ２．ｍｐ４）の最初の５秒をパラレルにフェッチする
ｃ）第２ソースの最初の２５秒を再生する（最初の５秒は予めフェッチされているため、遅延なく実行可能である）
２つのソースを利用することが、実現形態のトリックである。コンテンツサーバ８は、第１及び第２ソースが同一の符号化マルチメディアコンテンツに対応することを認識するよう構成される必要がある。
【００３９】
ダウンロードされるコンテンツがライブコンテンツであるとき、サーバは、最初のリクエストＲ０の受信またはフェッチしたリクエストの受信に応答して、どのファイルをダウンロードするか選択する必要がある。コンテンツサーバ８は、準備のため直近のファイルまたは最初のファイルを選択することができる。直近のファイルを選択した結果、クライアントは古いデータを受信することになる。第１ファイルを準備するよう選択した結果、クライアントはレスポンス取得前に一定時間待機する必要がある。図２において、矢印Ａは、コンテンツサーバ８による最初のリクエストＲ０の受信を示す。ダウンロードされたファイルがファイルＦｉ１である場合、クライアントは遅延を受けないが、しかしながら、ａｉ１だけ遅れてデータを受信するであろう。ダウンロードファイルがファイルＦｉ２である場合、クライアントは古いデータを受信することはないが、ｂｉ２に等しい遅延を受けることになる。
【００４０】
ファイルのダウンロードが達成されると、クライアント装置１４は、ファイルのコンテンツを再生できるようにするため、関連する解読鍵を取得する必要がある。この解読鍵を取得する２つの方法が、図４及び５を参照してそれぞれ説明される。
【００４１】
図４において、クライアント装置１４は、ダウンロードが成功したことを示すアクノリッジメント３０をコンテンツサーバ８に送信する。アクノリッジメント３０を受信すると、コンテンツサーバ８は、通知３２をキーサーバ１５に送信する。通知３２を受信すると、キーサーバ１５は、適切な解読鍵を有するメッセージ３４をクライアント装置１４に送信する。
【００４２】
図５において、クライアント装置１４は、ダウンロードが成功したことを示すアクノリッジメント４０をコンテンツサーバ８に、リクエスト４２をキーサーバ１５に送信する。アクノリッジメント４０を受信すると、コンテンツサーバ８は通知４３をキーサーバ１５に送信する。通知４３とリクエスト４２を受信すると、キーサーバ１５は適切な解読鍵を有するメッセージ４４をクライアント装置１４に送信する。
【００４３】
配信ネットワーク１０を介した送信は、ＨＴＴＰプロトコルにより規制される。
【００４４】
本発明によるマルチメディアコンテンツＭをクライアント装置１４に送信する方法の第１実施例が、図６を参照して説明される。それは、マルチメディアコンテンツＭから符号化されたマルチメディアコンテンツＥ（Ｍ）を生成するステップＸ１と、符号化されたマルチメディアコンテンツＥ（Ｍ）を一組のスライスＳｉにスライスするステップＸ２と、暗号化アルゴリズムＸを適用することによりスライスＳｉ（またはスライス群）を暗号鍵ＫＸｉにより暗号化し、これにより暗号化スライスＸ（Ｓｉ、ＫＸｉ）を提供するステップＸ３と、各ファイルＦｉが暗号化スライスＸ（Ｓｉ、ＫＸｉ）を有する一組のファイルＦｉを提供するステップＸ４と、クライアント装置１４からマルチメディアコンテンツＭに対する最初のリクエストＲ０の受信により、配信ネットワーク１０を介しクライアント装置１４にファイルＦｉの少なくとも１つをダウンロードするステップＸ５とを有する。
【００４５】
本発明によるマルチメディアコンテンツＭをクライアント装置１４に送信する方法の第２実施例が、図６を参照して説明される。それは、マルチメディアコンテンツＭから符号化されたマルチメディアコンテンツＥ（Ｍ）を生成するステップＸ１０と、符号化されたマルチメディアコンテンツＥ（Ｍ）を一組のスライスＳｉにスライスするステップＸ２０と、各ファイルＦｉがスライスＳｉを有する一組のファイルＦｉを提供するステップＸ２５と、暗号化アルゴリズムＸを適用することによりファイルＦｉ（またはファイル群）を暗号鍵ＫＸｉにより暗号化し、これにより暗号化ファイルＸ（Ｆｉ、ＫＸｉ）を提供するステップＸ３０と、クライアント装置１４からマルチメディアコンテンツＭに対する最初のリクエストＲ０の受信により、配信ネットワーク１０を介しクライアント装置１４にファイルＸ（Ｆｉ、ＫＸｉ）の少なくとも１つをダウンロードするステップＸ５０とを有する。
【００４６】
これらのステップは、１以上の装置に構成された特定のハードウェア及び／またはソフトウェアにより実現される。例えば、ステップＸ１とＸ１０はエンコーダ５により実現され、ステップＸ２、Ｘ３、Ｘ４及びＸ２０、Ｘ２５、Ｘ３０はスライサ６により実現され、ステップＸ５とＸ５０はコンテンツサーバ８により実現される。
【００４７】
説明されたネットワーク、サーバ、システム、スライサ、クライアント装置及びダウンロード方法に関して、本発明の範囲から逸脱することなく変更または改良が提案されるかもしれない。従って本発明は、与えられた実施例に限定されるものではない。
【００４８】
ＨＴＴＰ以外のファイル転送プロトコルが、利用されてもよい（例えば、ＦＴＰなど）。
【００４９】
コンテンツサーバとキーサーバは、同一の物理的エンティティであってもよい。暗号化はスライスまたはファイルの何れかに適用されてもよい。暗号鍵及び対になる解読鍵は、用いられる暗号化アルゴリズムに応じて異なるまたは同一のものであってもよい。
【００５０】
明細書及び請求項における「有する」という動詞及びその派生語の使用は、明細書及び請求項に記載されている以外の要素またはステップの存在を排除するものではない。
【００５１】
要素またはステップを指定する冠詞「ある」の使用は、当該要素またはステップが複数存在することを排除するものではない。
【図面の簡単な説明】
【００５２】
【図１】図１は、本発明によるシステムの第１実施例の概略図である。
【図２】図２は、本発明によるシステムの第２実施例の概略図である。
【図３】図３は、本発明によるスライサにより生成されるファイル群の概略図である。
【図４】図４は、クライアント装置が特定ファイルに係る解読鍵を取得するのに実現されるプロトコルの第１実施例である。
【図５】図５は、クライアント装置が特定ファイルに係る解読鍵を取得するのに実現されるプロトコルの第２実施例である。
【図６】図６は、本発明によるライブマルチメディアコンテンツをダウンロードするための方法の第１実施例のブロック図である。
【図７】図７は、本発明によるライブマルチメディアコンテンツをダウンロードするための方法の第２実施例のブロック図である。
【技術分野】
【０００１】
本発明は、クライアント装置にマルチメディアコンテンツを送信する方法に関する。本発明はまた、当該送信方法を実現するよう具体的に構成されたクライアント装置、コンテンツサーバ及びシステムに関する。
【０００２】
本発明は、インターネットを介したクライアント装置への有料コンテンツの送信、特にライブコンテンツ（ライブイベント、ライブショー、放送テレビ番組など）の送信のための興味深いアプリケーションを有する。
【背景技術】
【０００３】
欧州特許出願第１１８７４２３号は、音楽や映像など時間の経過と共に変換するコンテンツを有するオンデマンド情報を送信する方法について記載している。特に、それは１つのコンテンツを複数のファイルに分割し、第１ファイルから開始してコンテンツをファイル単位でダウンロードすることから構成されるいわゆるバッファリング配信方法について記載している。このバッファリング配信方法は、再生開始前の待機時間を短縮するという効果を提供するものとして説明されている（パーツＮがダウンロードされている間に、パーツＮ−１を再生することが可能である）。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
本発明の一課題は、そのような配信方法に対する改良を提案することである。
【課題を解決するための手段】
【０００５】
これは、請求項１乃至３記載のシステム、請求項４乃至７記載のコンテンツサーバ、請求項８及び９記載のクライアント装置、及び請求項１０記載の方法により達成される。
【０００６】
本発明によるシステムは、
マルチメディアコンテンツを取得するソースと、
前記マルチメディアコンテンツを符号化するエンコーダと、
前記符号化されたマルチメディアコンテンツを少なくとも一組のスライスにスライスし、前記少なくとも一組のスライスから少なくとも一組のファイルを提供し、ファイルに含まれるスライスが、係る解読鍵なしには利用できないように暗号化アルゴリズムを実現するスライサと、
配信ネットワークと、
クライアント装置に前記配信ネットワークへのアクセスを提供するアクセスプロバイダと、
前記配信ネットワークにリンクされ、前記クライアント装置からのリクエストの受信に応答して、前記配信ネットワークを介し前記ファイルの少なくとも１つを前記クライアント装置にダウンロードするため、前記一組以上のファイルにアクセスするコンテンツサーバと、
前記配信ネットワークにリンクし、前記ダウンロードしたファイルに係る前記１以上の解読鍵を前記クライアント装置に提供するキーサーバと、
を有する。
【発明の効果】
【０００７】
本発明によると、コンテンツは一組のスライスに分割され、各スライスに対して、ファイルが生成される。スライス（またはファイル）は、クライアント装置が係る解読鍵を取得する前にスライス（またはファイル）を利用できるようにダウンロード前に暗号化される。これにより、本発明は、ダウンロードされたコンテンツを全体的にプロテクトするのではなく、ダウンロードされたコンテンツをスライスごと（またはファイルごと）にプロテクトすることを可能にする。
【０００８】
これは以下の理由から効果的である。ダウンロードされたコンテンツが暗号化を介しプロテクトされると、ダウンロードの成功を確認し（これにより、クライアントが最終的に受け取っていないものに対して支払いをするリスクを解消し）、クライアントがコンテンツを視聴し、課金前に切断することを回避するため、ダウンロードの完了後に解読鍵が通常は提供される。当該スライス（またはファイル）を１つずつ（またはグループごとに）プロテクトすることは、クライアントが支払いを済ませたものを適切に受信し、支払いをしていないものを利用することができないことを保証しながら、すべてのファイルがダウンロードされる前にコンテンツの解読及び再生開始をするのを可能にする。
【０００９】
本発明によると、クライアントは、予めコンテンツ全体に対する支払いをする必要はない。再生の進捗に応じて、支払いが進捗する。クライアントは、コンテンツを再生開始し、所望する場合には、コンテンツ全体がダウンロードされる前に切断することができる。このような場合、クライアントは、最終的に受信したものに対する支払いのみを行うことになる。
【００１０】
本発明は、コンテンツプロバイダとクライアントの両方に利益を保護する。
【００１１】
本発明によると、ファイルベースのコンテンツが、ポイント・ツー・ポイント接続を介しコンテンツサーバからクライアント装置にダウンロードされる。ＩＰネットワークを介し、ポイント・ツー・ポイント接続は通常はＨＴＴＰプロトコル（ＩＥＴＦのＲＦＣ２６１６に規定されるＨｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）により規制される。ＨＴＴＰプロトコルは、ワールドワイドウェブに基づくものであり、従って、すべてのファイアフォールとネットワークアドレストランスレータ（ＲＴＰ／ＵＤＰトランスポートプロトコルのケースではない）により受付けられるという大きな効果を有する。このことは、送信されたコンテンツが制限なくワールドワイドウェブにアクセス可能な任意のクライアント装置にアクセス可能であるということを意味する。ダウンロード配信モードを利用する他の効果は、それを信頼性の高いものにするということである。
【００１２】
しかしながら、欧州特許出願第１１８７４２３号に記載されるタイプのダウンロード配信モードを利用することは、第１ファイルから始まりすべてのファイルを送信する必要があるという欠点を有する。このようなダウンロード配信モードによると、クライアントはランダムにコンテンツにアクセスすることはできない。ライブコンテンツ（すなわち、ライブイベント、ライブショー、放送テレビ番組などのリアルタイムに利用可能なコンテンツ）の送信は実現できない。
【００１３】
本発明の効果的な実施例では、互いに独立して復号できるようにスライスが生成される。このことは、クライアントがそれの始めからコンテンツを受信する必要がないことを意味する。それは、任意のスライスからコンテンツの受信を開始することができる。クライアントがライブコンテンツに対する最初のリクエストを送信すると、クライアントは前のファイルを受信するか（クライアントがやや古い情報を受信することを意味する）、または、次のファイルが準備できるまで待機する必要がある。
【００１４】
本発明によると、クライアント装置によるリクエストの受信により、１つのファイルのみしかダウンロードすることはできない。このことは、特定の用途に対しては、決勝戦の最中に結果のダイジェストをクライアントが取得することを可能にするという効果がある。
【００１５】
複数のファイルがダウンロードされるとき、これらのファイルはクライアント装置により１つずつフェッチ可能であるか、あるいは、最初のリクエストの受信によりコンテンツサーバによって１つずつ送信することも可能である。実際、すべてのクライアントブラウザが１つのリクエストに応答して複数のファイルの受信をサポートするということは保証されていない。従って、クライアント装置がファイルを１つずつフェッチすることが通常は望まれる（すなわち、ダウンロードされる各ファイルに対するフェッチリクエストの送信）。クライアント装置は、適切な時点にフェッチリクエストを自動的に送信するよう具体的に構成することが可能である。あるいは、コンテンツサーバは、クライアント装置にフェッチリクエストを繰り返し送信させる文書をクライアント装置に送信することができる。効果的には、当該文書は、クライアント装置が前のファイルの再生終了の所定時間前に、以降のフェッチリクエストを送信する命令を有する。このように、次のファイルが十分早くクライアント装置に到着し、クライアントが再生処理におけるギャップを受けないことが保証される。
【発明を実施するための最良の形態】
【００１６】
図１は、本発明によるシステムの第１実施例の概略図である。図１のシステムは、マルチメディアコンテンツを取得するソース１と、受信したマルチメディアコンテンツを符号化するエンコーダ５と、符号化したマルチメディアコンテンツを一組のスライスにスライスし、各ファイルが前記符号化したマルチメディアコンテンツの一スライスを有する一組のファイルを提供し、ファイルに含まれる少なくとも当該スライスがそれに係る解読鍵なしには利用することができないように暗号化アルゴリズムを実現するスライサ６と、前記ファイルにアクセスするコンテンツサーバ８と、コンテンツサーバ８にリンクする配信ネットワーク１０と、クライアント装置１４に配信ネットワーク１０とのアクセスを提供するアクセスプロバイダ１２と、配信ネットワーク１０とリンクし、クライアント装置１４にダウンロードしたファイルに係る１以上の解読鍵を提供するキーサーバ１５とを有する。
【００１７】
図１のシステムでは、ソース１、エンコーダ５及びスライサ６は、１つまたは複数の装置に物理的に配置されていてもよい。
【００１８】
図２は、本発明によるシステムの第２実施例の概略図である。図１を参照して上述された要素に加えて、図２のシステムは、ソース１により与えられるマルチメディアコンテンツを配信する配信システム１６と、配信されたマルチメディアコンテンツを受信し、受信したマルチメディアコンテンツをスライサ６に転送する受信機１７とを有する。
【００１９】
クライアント装置１４は、アクセスプロバイダ１２との送受信のための通信ユニット２０と、符号化されたマルチメディアコンテンツを再生するプレーヤー２２と、マルチメディアコンテンツを表示するディスプレイ２４とを有する（図１に示されていない他の手段の中で）。クライアント装置１４は、通信ユニット２０が無線通信ユニットとなるモバイル装置（携帯電話など）、または通信ユニット２０が有線通信ユニットとなる有線装置（ＰＣなど）の何れであってもよい。配信ネットワーク１０は、典型的にはインターネットネットワークである。
【００２０】
例えば、配信システム１６は衛星配信ネットワークであり、受信機１７は衛星受信機である。このことは限定的ではない。すなわち、他の任意の配信手段が、衛星配信手段の代わりに利用可能である。配信されるマルチメディアコンテンツは、受信機１７を含むいくつかの受信機により受信可能であって、送信される任意のマルチメディアコンテンツであってもよい。配信マルチメディアコンテンツは、例えば、テレビ番組、予め記録されたイベント／番組、ライブイベントなどであってもよい。エンコーダ５は、受信したマルチメディアコンテンツを符号化するためのものである。エンコーダ５は、例えば、ＭＰＥＧ規格やＨ２６３に準拠する。
【００２１】
エンコーダ５とスライサ６は、単一の装置または２つの独立した装置により実現される。何れの場合でも、エンコーダ５からスライサ６に送信されるものは、符号化された映像ストリームである。効果的には、この符号化映像ストリームは、ＲＴＰプロトコルを利用することによりＩＰを介しエンコーダ５からスライサ６に送信される。これは限定的なものではない。例えば、ＭＰＥＧ−２ ＴＳとして知られるＭＰＥＧ−２規格のトランスポートレイヤもまた利用可能である。
【００２２】
実際、スライサ６により生成されたファイルは、コンテンツサーバ８がアクセスするストレージユニット２６に格納される。ストレージユニット２６は、スライサ６とコンテンツサーバ８により共有されている。ストレージユニット２６は、コンテンツサーバ８の一部とすることも可能であり、あるいは遠隔配置することも可能である。
【００２３】
スライサ６は、以下の機能を有する。
ａ）それは、エンコーダ５により生成される符号化されたコンテンツを、各スライスが当該符号化マルチメディアコンテンツの所定時間からなる複数のスライスにスライスする。
ｂ）それは、各スライスからファイルを生成する。
ｃ）それは、ファイルに含まれる少なくとも当該スライスが、それに係る解読鍵なしには利用できないように暗号化アルゴリズムを実現する。これは、スライスまたはファイルを暗号化することにより実現可能である。ファイルの暗号化は簡単であるという効果を有する。スライスの暗号化はより複雑である。しかしながら、それは、第１ファイルを解読する必要なく、クライアント側でファイル構造（ヘッダなどに）に含まれるファイル情報へのアクセスを可能にする。例えば、スライサ６により用いられる暗号化アルゴリズムは、ＡＥＳ（Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）である。暗号化は、暗号鍵を用いて実行される。係る解読鍵が、符号化されたエンティティ（スライスまたはファイル）の解読を実現するのに必要とされる。キーサーバ１５は、暗号鍵をスライサ６に送り、解読鍵をクライアント装置１４に送信するためのものである。
【００２４】
スライサ６は、同一のマルチメディアコンテンツに対して複数のファイル群を生成することが可能である。例えば、スライサ６が複数のファイル群を生成するとき、スライス位置の各組がスライス位置のその他の組と比較して時間シフトされている複数のスライス位置の組が利用可能である。複数のファイル群を生成することは、クライアントがライブコンテンツに対するリクエストを送信するとき、クライアントが被る遅延を低減することを可能にするため効果的である。
【００２５】
図３は、スライス位置Ｔｉｊ（ｊ＝１，．．．，Ｎ−１）において符号化されたマルチメディアコンテンツをスライスすることによって、スライサ６により生成されるファイルＦｉｊ（ｊ＝１，．．．，Ｎ）の組Ｓｉを表す。
【００２６】
効果的な実施例では、これらのスライスは、互いに独立に復号できるように生成される。実際、マルチメディアエンコーダにより生成される任意の符号化マルチメディアコンテンツは、いわゆるランダムアクセスポイント（ＲＡＰ）から構成される。その他のものとは独立に復号可能なスライスを生成するため、スライサ６は、各スライスがランダムアクセスポイントから開始されるように符号化されたマルチメディアコンテンツをスライスする。例えば、エンコーダがＭＰＥＧ−２またはＭＰＥＧ−４規格に準拠しているとき、ランダムアクセスポイントは、ＭＰＥＧ符号化マルチメディアコンテンツのＩフレームであり、スライス位置は、各スライスの第１フレームがＩフレームとなるように選ばれる。
【００２７】
任意的には、スライスのサイズは調整可能である。それはすべてのスライスに対して同一であってもよいし、あるいは、スライスごとに可変とされてもよい（例えば、スライスのサイズは、時間の経過と共に大きくなるようにしてもよい）。最善の効率は、多くのファイルが転送されるほど、ファイルヘッダによるより大きなオーバーヘッドがもたらされるという理由から、比較的長いファイルにより得られる。
【００２８】
スライサ６により生成される各ファイルは、ストレージユニット２６にファイルとして格納される。ストレージユニット２６は、新たに生成されたファイルを格納するためのスペースが利用可能でことを保証するため、通常は「クリーン」にされる必要がある。ストレージユニットをクリーニングする方法は、通常はファイル名を再利用するというものである。他の方法は、各ファイルに対して異なるファイル名を使用し、通常は時間が経過したファイルを削除するというものである。
【００２９】
コンテンツサーバ８とキーサーバ１５は、配信ネットワーク１０を介しリンクする。クライアント装置１４は、アクセスプロバイダ１２を介し配信ネットワーク１０にアクセスする。典型的には、クライアント装置１４は、配信ネットワーク１０を介し、クライアントサーバ８がダウンロードするため提供する１つの符号化マルチメディアコンテンツとの少なくとも１つのリンクを有するページをロードすることができる。ユーザが当該リンクをクリックすると、符号化マルチメディアコンテンツに向けられた最初のリクエストＲ０が、自動的にコンテンツサーバ８に送信される。コンテンツサーバ８が最初のリクエストＲ０を処理する方法は、複数存在する。
【００３０】
第１実施例では、コンテンツサーバ８は、クライアントレクエストに応答して、１つのファイルをダウンロードする。当該実現形態は、ライブイベントに関する情報を抽出するためクライアントに提供するアプリケーションなどの特定のアプリケーションに利用可能である。それはまた、クライアント装置１４に最初のリクエストＲ０を繰り返し送信させるよう具体的に構成されたプレーヤー２２により利用可能である。
【００３１】
第２実施例では、コンテンツサーバ８は、ファイルがサーバ側で準備できるとすぐに、１つずつダウンロードする。本実施例は、実現が容易であるという効果を有する。しかしながら、１つのリクエストに応答して、クライアントブラウザは複数のファイルの受信をサポートしていない可能性がある。
【００３２】
第３実施例では、コンテンツサーバ８は、最初のリクエストＲ０を受信すると、クライアント装置に文書を送信する。この文書は、クライアント装置１４に符号化されたマルチメディアコンテンツを指定するフェッチしたリクエストを繰り返し送信させる。
【００３３】
例えば、コンテンツサーバ８により送信される文書は、自動リフレッシュコマンドを有するページであってもよい。このようなページの一例として、以下のものが与えられる。
【００３４】
【表１】
このようなページは、クライアントブラウザに１３４秒（本実施例のファイルの所要時間）ごとに「ｌｉｖｅ２ｄｏｗｎｌｏａｄ．ｍｐ４」ファイルをリロードさせる。
【００３５】
あるいは、コンテンツサーバ８により送信される文書は、標準的な方法によりプレーヤー２２により処理されるマルチメディアコンテンツの標準的記述であってもよい。このような記述は、例えば、ＳＭＩＬ記述であってもよい（ＳＭＩＬは、ＸＭＬベースの音声／映像シーン記述を規定するＷ３Ｃ規格である）。このようなＳＭＩＬ記述の一例が、以下に与えられる。
【００３６】
【表２】
このＳＭＩＬ文書の効果は、プレーヤー１７に「ｌｉｖｅ２ｄｏｗｎｌｏａｄ．ｍｐ４」ファイルを繰り返し再生させることである。この結果、クライアント装置は、「ｌｉｖｅ２ｄｏｗｎｌｏａｄ．ｍｐ４」ファイルに対するフェッチしたリクエストを繰り返し送信する。
【００３７】
効果的には、コンテンツサーバ８により送信されるＳＭＩＬ文書は、ファイルが予めある時間だけ（すなわち、前のファイルの再生の終了前の時間）フェッチされる必要があることを示すコマンドを有する。このことは、クライアントにマルチメディアコンテンツのレンダリングにおいてギャップが生じないように、次のファイルが時間内にクライアント装置１４に到達することを保証する。このようなコマンドを有するＳＭＩＬ記述の一例が、以下に与えられる。
【００３８】
【表３】
当該記述は、３０秒のコンテンツを含むスライスに対して書かれている。それは、プレーヤー１７に以下の処理を逐次的に実行させる。すなわち、
ａ）第１ソース（ｌｉｖｅ２ｄｏｗｎｌｏａｄ１．ｍｐ４）の最初の２５秒を再生する
ｂ）第１ソースの最後の５秒を再生し、第２ソース（ｌｉｖｅ２ｄｏｗｎｌｏａｄ２．ｍｐ４）の最初の５秒をパラレルにフェッチする
ｃ）第２ソースの最初の２５秒を再生する（最初の５秒は予めフェッチされているため、遅延なく実行可能である）
２つのソースを利用することが、実現形態のトリックである。コンテンツサーバ８は、第１及び第２ソースが同一の符号化マルチメディアコンテンツに対応することを認識するよう構成される必要がある。
【００３９】
ダウンロードされるコンテンツがライブコンテンツであるとき、サーバは、最初のリクエストＲ０の受信またはフェッチしたリクエストの受信に応答して、どのファイルをダウンロードするか選択する必要がある。コンテンツサーバ８は、準備のため直近のファイルまたは最初のファイルを選択することができる。直近のファイルを選択した結果、クライアントは古いデータを受信することになる。第１ファイルを準備するよう選択した結果、クライアントはレスポンス取得前に一定時間待機する必要がある。図２において、矢印Ａは、コンテンツサーバ８による最初のリクエストＲ０の受信を示す。ダウンロードされたファイルがファイルＦｉ１である場合、クライアントは遅延を受けないが、しかしながら、ａｉ１だけ遅れてデータを受信するであろう。ダウンロードファイルがファイルＦｉ２である場合、クライアントは古いデータを受信することはないが、ｂｉ２に等しい遅延を受けることになる。
【００４０】
ファイルのダウンロードが達成されると、クライアント装置１４は、ファイルのコンテンツを再生できるようにするため、関連する解読鍵を取得する必要がある。この解読鍵を取得する２つの方法が、図４及び５を参照してそれぞれ説明される。
【００４１】
図４において、クライアント装置１４は、ダウンロードが成功したことを示すアクノリッジメント３０をコンテンツサーバ８に送信する。アクノリッジメント３０を受信すると、コンテンツサーバ８は、通知３２をキーサーバ１５に送信する。通知３２を受信すると、キーサーバ１５は、適切な解読鍵を有するメッセージ３４をクライアント装置１４に送信する。
【００４２】
図５において、クライアント装置１４は、ダウンロードが成功したことを示すアクノリッジメント４０をコンテンツサーバ８に、リクエスト４２をキーサーバ１５に送信する。アクノリッジメント４０を受信すると、コンテンツサーバ８は通知４３をキーサーバ１５に送信する。通知４３とリクエスト４２を受信すると、キーサーバ１５は適切な解読鍵を有するメッセージ４４をクライアント装置１４に送信する。
【００４３】
配信ネットワーク１０を介した送信は、ＨＴＴＰプロトコルにより規制される。
【００４４】
本発明によるマルチメディアコンテンツＭをクライアント装置１４に送信する方法の第１実施例が、図６を参照して説明される。それは、マルチメディアコンテンツＭから符号化されたマルチメディアコンテンツＥ（Ｍ）を生成するステップＸ１と、符号化されたマルチメディアコンテンツＥ（Ｍ）を一組のスライスＳｉにスライスするステップＸ２と、暗号化アルゴリズムＸを適用することによりスライスＳｉ（またはスライス群）を暗号鍵ＫＸｉにより暗号化し、これにより暗号化スライスＸ（Ｓｉ、ＫＸｉ）を提供するステップＸ３と、各ファイルＦｉが暗号化スライスＸ（Ｓｉ、ＫＸｉ）を有する一組のファイルＦｉを提供するステップＸ４と、クライアント装置１４からマルチメディアコンテンツＭに対する最初のリクエストＲ０の受信により、配信ネットワーク１０を介しクライアント装置１４にファイルＦｉの少なくとも１つをダウンロードするステップＸ５とを有する。
【００４５】
本発明によるマルチメディアコンテンツＭをクライアント装置１４に送信する方法の第２実施例が、図６を参照して説明される。それは、マルチメディアコンテンツＭから符号化されたマルチメディアコンテンツＥ（Ｍ）を生成するステップＸ１０と、符号化されたマルチメディアコンテンツＥ（Ｍ）を一組のスライスＳｉにスライスするステップＸ２０と、各ファイルＦｉがスライスＳｉを有する一組のファイルＦｉを提供するステップＸ２５と、暗号化アルゴリズムＸを適用することによりファイルＦｉ（またはファイル群）を暗号鍵ＫＸｉにより暗号化し、これにより暗号化ファイルＸ（Ｆｉ、ＫＸｉ）を提供するステップＸ３０と、クライアント装置１４からマルチメディアコンテンツＭに対する最初のリクエストＲ０の受信により、配信ネットワーク１０を介しクライアント装置１４にファイルＸ（Ｆｉ、ＫＸｉ）の少なくとも１つをダウンロードするステップＸ５０とを有する。
【００４６】
これらのステップは、１以上の装置に構成された特定のハードウェア及び／またはソフトウェアにより実現される。例えば、ステップＸ１とＸ１０はエンコーダ５により実現され、ステップＸ２、Ｘ３、Ｘ４及びＸ２０、Ｘ２５、Ｘ３０はスライサ６により実現され、ステップＸ５とＸ５０はコンテンツサーバ８により実現される。
【００４７】
説明されたネットワーク、サーバ、システム、スライサ、クライアント装置及びダウンロード方法に関して、本発明の範囲から逸脱することなく変更または改良が提案されるかもしれない。従って本発明は、与えられた実施例に限定されるものではない。
【００４８】
ＨＴＴＰ以外のファイル転送プロトコルが、利用されてもよい（例えば、ＦＴＰなど）。
【００４９】
コンテンツサーバとキーサーバは、同一の物理的エンティティであってもよい。暗号化はスライスまたはファイルの何れかに適用されてもよい。暗号鍵及び対になる解読鍵は、用いられる暗号化アルゴリズムに応じて異なるまたは同一のものであってもよい。
【００５０】
明細書及び請求項における「有する」という動詞及びその派生語の使用は、明細書及び請求項に記載されている以外の要素またはステップの存在を排除するものではない。
【００５１】
要素またはステップを指定する冠詞「ある」の使用は、当該要素またはステップが複数存在することを排除するものではない。
【図面の簡単な説明】
【００５２】
【図１】図１は、本発明によるシステムの第１実施例の概略図である。
【図２】図２は、本発明によるシステムの第２実施例の概略図である。
【図３】図３は、本発明によるスライサにより生成されるファイル群の概略図である。
【図４】図４は、クライアント装置が特定ファイルに係る解読鍵を取得するのに実現されるプロトコルの第１実施例である。
【図５】図５は、クライアント装置が特定ファイルに係る解読鍵を取得するのに実現されるプロトコルの第２実施例である。
【図６】図６は、本発明によるライブマルチメディアコンテンツをダウンロードするための方法の第１実施例のブロック図である。
【図７】図７は、本発明によるライブマルチメディアコンテンツをダウンロードするための方法の第２実施例のブロック図である。
【特許請求の範囲】
【請求項１】
マルチメディアコンテンツを取得するソースと、
前記マルチメディアコンテンツを符号化するエンコーダと、
前記符号化されたマルチメディアコンテンツを少なくとも一組のスライスにスライスし、前記少なくとも一組のスライスから少なくとも一組のファイルを提供し、ファイルに含まれるスライスが、係る解読鍵なしには利用できないように暗号化アルゴリズムを実現するスライサと、
配信ネットワークと、
クライアント装置に前記配信ネットワークへのアクセスを提供するアクセスプロバイダと、
前記配信ネットワークにリンクされ、前記クライアント装置からのリクエストの受信に応答して、前記配信ネットワークを介し前記ファイルの少なくとも１つを前記クライアント装置にダウンロードするため、前記一組以上のファイルにアクセスするコンテンツサーバと、
前記配信ネットワークにリンクし、前記ダウンロードしたファイルに係る前記１以上の解読鍵を前記クライアント装置に提供するキーサーバと、
を少なくとも有することを特徴とするシステム。
【請求項２】
請求項１記載のシステムであって、
解読鍵は、該解読鍵に係る以上のファイルのダウンロードの成功に応答して、前記クライアント装置に提供されることを特徴とするシステム。
【請求項３】
請求項１記載のシステムであって、
スライスは、互いに独立に復号可能となるよう生成されることを特徴とするシステム。
【請求項４】
符号化されたマルチメディアコンテンツを少なくとも一組のスライスにスライスすることにより生成される少なくとも一組のファイルにアクセスし、ファイルに含まれるスライスが、係る解読鍵なしには利用できないように暗号化アルゴリズムを実現することによって、前記少なくとも一組のスライスから少なくとも一組のファイルを提供するコンテンツサーバであって、
当該コンテンツサーバは、クライアント装置からのリクエストの受信に応答して、前記ファイルの少なくとも１つを前記クライアント装置にダウンロードする手段を有することを特徴とするコンテンツサーバ。
【請求項５】
請求項４記載のコンテンツサーバであって、
前記ファイルは、互いに独立に復号可能なスライスから得られることを特徴とするコンテンツサーバ。
【請求項６】
請求項４記載のコンテンツサーバであって、さらに、
前記クライアント装置へのファイルのダウンロードの成功に応答して、キーサーバが前記クライアント装置に前記ファイルに係る解読鍵を提供するように、前記キーサーバに通知を送信する手段を有することを特徴とするコンテンツサーバ。
【請求項７】
請求項４記載のコンテンツサーバであって、
前記ダウンロード手段は、
前記リクエストの受信に応答して、前記クライアント装置に前記符号化されたマルチメディアコンテンツを指定するフェッチしたリクエストを繰り返し送信させる文書を前記クライアント装置に送信する手段と、
前記クライアント装置からのフェッチしたリクエストの受信に応答して、前記１以上のファイルの中からどのファイルをダウンロードするか選択する手段と、
前記選択されたファイルをダウンロードする手段と、
を有することを特徴とするコンテンツサーバ。
【請求項８】
符号化されたマルチメディアコンテンツを少なくとも一組のスライスにスライスし、ファイルに含まれるスライスが、係る解読鍵なしには利用できないように暗号化アルゴリズムを実現することにより生成される、各ファイルがスライスを有する少なくとも一組のファイルにアクセスし、前記符号化されたマルチメディアコンテンツの少なくとも一部をファイルごとにダウンロードするよう提供するコンテンツサーバに接続する手段と、
前記符号化されたマルチメディアコンテンツに対するリクエストを前記コンテンツサーバに繰り返し送信する手段と、
各リクエストに応答して、前記ファイルの１つを受信する手段と、
各ファイルに係る解読鍵を取得する手段と、
前記ファイルを解読及び再生する手段と、
を有することを特徴とするクライアント装置。
【請求項９】
請求項８記載のクライアント装置であって、さらに、
現在のファイルの再生終了前に以降のリクエストを送信する手段を有することを特徴とするクライアント装置。
【請求項１０】
符号化されたマルチメディアコンテンツをクライアント装置に送信する方法であって、
マルチメディアコンテンツを符号化するステップと、
前記符号化されたマルチメディアコンテンツを少なくとも一組のスライスにスライスし、前記少なくとも一組のスライスから少なくとも一組のファイルを提供し、ファイルに含まれたスライスが係る解読鍵なしには利用できないように暗号化ステップを有するスライスするステップと、
前記クライアント装置からのリクエストの受信に応答して、前記配信ネットワークを介し前記ファイルの少なくとも１つを前記クライアント装置にダウンロードするステップと、
を有することを特徴とする方法。
【請求項１】
マルチメディアコンテンツを取得するソースと、
前記マルチメディアコンテンツを符号化するエンコーダと、
前記符号化されたマルチメディアコンテンツを少なくとも一組のスライスにスライスし、前記少なくとも一組のスライスから少なくとも一組のファイルを提供し、ファイルに含まれるスライスが、係る解読鍵なしには利用できないように暗号化アルゴリズムを実現するスライサと、
配信ネットワークと、
クライアント装置に前記配信ネットワークへのアクセスを提供するアクセスプロバイダと、
前記配信ネットワークにリンクされ、前記クライアント装置からのリクエストの受信に応答して、前記配信ネットワークを介し前記ファイルの少なくとも１つを前記クライアント装置にダウンロードするため、前記一組以上のファイルにアクセスするコンテンツサーバと、
前記配信ネットワークにリンクし、前記ダウンロードしたファイルに係る前記１以上の解読鍵を前記クライアント装置に提供するキーサーバと、
を少なくとも有することを特徴とするシステム。
【請求項２】
請求項１記載のシステムであって、
解読鍵は、該解読鍵に係る以上のファイルのダウンロードの成功に応答して、前記クライアント装置に提供されることを特徴とするシステム。
【請求項３】
請求項１記載のシステムであって、
スライスは、互いに独立に復号可能となるよう生成されることを特徴とするシステム。
【請求項４】
符号化されたマルチメディアコンテンツを少なくとも一組のスライスにスライスすることにより生成される少なくとも一組のファイルにアクセスし、ファイルに含まれるスライスが、係る解読鍵なしには利用できないように暗号化アルゴリズムを実現することによって、前記少なくとも一組のスライスから少なくとも一組のファイルを提供するコンテンツサーバであって、
当該コンテンツサーバは、クライアント装置からのリクエストの受信に応答して、前記ファイルの少なくとも１つを前記クライアント装置にダウンロードする手段を有することを特徴とするコンテンツサーバ。
【請求項５】
請求項４記載のコンテンツサーバであって、
前記ファイルは、互いに独立に復号可能なスライスから得られることを特徴とするコンテンツサーバ。
【請求項６】
請求項４記載のコンテンツサーバであって、さらに、
前記クライアント装置へのファイルのダウンロードの成功に応答して、キーサーバが前記クライアント装置に前記ファイルに係る解読鍵を提供するように、前記キーサーバに通知を送信する手段を有することを特徴とするコンテンツサーバ。
【請求項７】
請求項４記載のコンテンツサーバであって、
前記ダウンロード手段は、
前記リクエストの受信に応答して、前記クライアント装置に前記符号化されたマルチメディアコンテンツを指定するフェッチしたリクエストを繰り返し送信させる文書を前記クライアント装置に送信する手段と、
前記クライアント装置からのフェッチしたリクエストの受信に応答して、前記１以上のファイルの中からどのファイルをダウンロードするか選択する手段と、
前記選択されたファイルをダウンロードする手段と、
を有することを特徴とするコンテンツサーバ。
【請求項８】
符号化されたマルチメディアコンテンツを少なくとも一組のスライスにスライスし、ファイルに含まれるスライスが、係る解読鍵なしには利用できないように暗号化アルゴリズムを実現することにより生成される、各ファイルがスライスを有する少なくとも一組のファイルにアクセスし、前記符号化されたマルチメディアコンテンツの少なくとも一部をファイルごとにダウンロードするよう提供するコンテンツサーバに接続する手段と、
前記符号化されたマルチメディアコンテンツに対するリクエストを前記コンテンツサーバに繰り返し送信する手段と、
各リクエストに応答して、前記ファイルの１つを受信する手段と、
各ファイルに係る解読鍵を取得する手段と、
前記ファイルを解読及び再生する手段と、
を有することを特徴とするクライアント装置。
【請求項９】
請求項８記載のクライアント装置であって、さらに、
現在のファイルの再生終了前に以降のリクエストを送信する手段を有することを特徴とするクライアント装置。
【請求項１０】
符号化されたマルチメディアコンテンツをクライアント装置に送信する方法であって、
マルチメディアコンテンツを符号化するステップと、
前記符号化されたマルチメディアコンテンツを少なくとも一組のスライスにスライスし、前記少なくとも一組のスライスから少なくとも一組のファイルを提供し、ファイルに含まれたスライスが係る解読鍵なしには利用できないように暗号化ステップを有するスライスするステップと、
前記クライアント装置からのリクエストの受信に応答して、前記配信ネットワークを介し前記ファイルの少なくとも１つを前記クライアント装置にダウンロードするステップと、
を有することを特徴とする方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公表番号】特表２００７−５２８１４０（Ｐ２００７−５２８１４０Ａ）
【公表日】平成１９年１０月４日（２００７．１０．４）
【国際特許分類】
【出願番号】特願２００６−５１８３８８（Ｐ２００６−５１８３８８）
【出願日】平成１６年６月２３日（２００４．６．２３）
【国際出願番号】ＰＣＴ／ＩＢ２００４／００２１４０
【国際公開番号】ＷＯ２００５／００４４８５
【国際公開日】平成１７年１月１３日（２００５．１．１３）
【出願人】（５９００００２４８）コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ (12,071)
【Ｆターム（参考）】
【公表日】平成１９年１０月４日（２００７．１０．４）
【国際特許分類】
【出願日】平成１６年６月２３日（２００４．６．２３）
【国際出願番号】ＰＣＴ／ＩＢ２００４／００２１４０
【国際公開番号】ＷＯ２００５／００４４８５
【国際公開日】平成１７年１月１３日（２００５．１．１３）
【出願人】（５９００００２４８）コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ (12,071)
【Ｆターム（参考）】
[ Back to top ]