JP2007528140A - 配信ネットワークを介したマルチメディアコンテンツの配信方法 - Google Patents
配信ネットワークを介したマルチメディアコンテンツの配信方法 Download PDFInfo
- Publication number
- JP2007528140A JP2007528140A JP2006518388A JP2006518388A JP2007528140A JP 2007528140 A JP2007528140 A JP 2007528140A JP 2006518388 A JP2006518388 A JP 2006518388A JP 2006518388 A JP2006518388 A JP 2006518388A JP 2007528140 A JP2007528140 A JP 2007528140A
- Authority
- JP
- Japan
- Prior art keywords
- file
- client device
- content
- slices
- files
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Images
Landscapes
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Storage Device Security (AREA)
Abstract
本発明は、ネットワークを介して送信されるコンテンツを一組のスライスに分割し、当該スライス群から一組のファイルを生成することを提案する。スライス(またはファイル)は、係る解読鍵の取得前にクライアントがスライス(またはファイル)を利用できないようにダウンロード前に暗号化される。従って、本発明は、ダウンロードされたコンテンツ全体をプロテクトするよりも、スライスごとに(またはファイルごとに)ダウンロードされたコンテンツをプロテクトすることを可能にする。サーバとクライアントの間の送信(ダウンロードモードによる)は、すべてのファイアウォール及びNATにより受付けられているHTTPプロトコルにより規制される。この結果、送信されたコンテンツは、制限なくウェブにアクセスできる任意のクライアント装置にアクセス可能となる。効果的には、スライスは、互いに独立に復号可能である。
Description
本発明は、クライアント装置にマルチメディアコンテンツを送信する方法に関する。本発明はまた、当該送信方法を実現するよう具体的に構成されたクライアント装置、コンテンツサーバ及びシステムに関する。
本発明は、インターネットを介したクライアント装置への有料コンテンツの送信、特にライブコンテンツ(ライブイベント、ライブショー、放送テレビ番組など)の送信のための興味深いアプリケーションを有する。
欧州特許出願第1187423号は、音楽や映像など時間の経過と共に変換するコンテンツを有するオンデマンド情報を送信する方法について記載している。特に、それは1つのコンテンツを複数のファイルに分割し、第1ファイルから開始してコンテンツをファイル単位でダウンロードすることから構成されるいわゆるバッファリング配信方法について記載している。このバッファリング配信方法は、再生開始前の待機時間を短縮するという効果を提供するものとして説明されている(パーツNがダウンロードされている間に、パーツN−1を再生することが可能である)。
本発明の一課題は、そのような配信方法に対する改良を提案することである。
これは、請求項1乃至3記載のシステム、請求項4乃至7記載のコンテンツサーバ、請求項8及び9記載のクライアント装置、及び請求項10記載の方法により達成される。
本発明によるシステムは、
マルチメディアコンテンツを取得するソースと、
前記マルチメディアコンテンツを符号化するエンコーダと、
前記符号化されたマルチメディアコンテンツを少なくとも一組のスライスにスライスし、前記少なくとも一組のスライスから少なくとも一組のファイルを提供し、ファイルに含まれるスライスが、係る解読鍵なしには利用できないように暗号化アルゴリズムを実現するスライサと、
配信ネットワークと、
クライアント装置に前記配信ネットワークへのアクセスを提供するアクセスプロバイダと、
前記配信ネットワークにリンクされ、前記クライアント装置からのリクエストの受信に応答して、前記配信ネットワークを介し前記ファイルの少なくとも1つを前記クライアント装置にダウンロードするため、前記一組以上のファイルにアクセスするコンテンツサーバと、
前記配信ネットワークにリンクし、前記ダウンロードしたファイルに係る前記1以上の解読鍵を前記クライアント装置に提供するキーサーバと、
を有する。
マルチメディアコンテンツを取得するソースと、
前記マルチメディアコンテンツを符号化するエンコーダと、
前記符号化されたマルチメディアコンテンツを少なくとも一組のスライスにスライスし、前記少なくとも一組のスライスから少なくとも一組のファイルを提供し、ファイルに含まれるスライスが、係る解読鍵なしには利用できないように暗号化アルゴリズムを実現するスライサと、
配信ネットワークと、
クライアント装置に前記配信ネットワークへのアクセスを提供するアクセスプロバイダと、
前記配信ネットワークにリンクされ、前記クライアント装置からのリクエストの受信に応答して、前記配信ネットワークを介し前記ファイルの少なくとも1つを前記クライアント装置にダウンロードするため、前記一組以上のファイルにアクセスするコンテンツサーバと、
前記配信ネットワークにリンクし、前記ダウンロードしたファイルに係る前記1以上の解読鍵を前記クライアント装置に提供するキーサーバと、
を有する。
本発明によると、コンテンツは一組のスライスに分割され、各スライスに対して、ファイルが生成される。スライス(またはファイル)は、クライアント装置が係る解読鍵を取得する前にスライス(またはファイル)を利用できるようにダウンロード前に暗号化される。これにより、本発明は、ダウンロードされたコンテンツを全体的にプロテクトするのではなく、ダウンロードされたコンテンツをスライスごと(またはファイルごと)にプロテクトすることを可能にする。
これは以下の理由から効果的である。ダウンロードされたコンテンツが暗号化を介しプロテクトされると、ダウンロードの成功を確認し(これにより、クライアントが最終的に受け取っていないものに対して支払いをするリスクを解消し)、クライアントがコンテンツを視聴し、課金前に切断することを回避するため、ダウンロードの完了後に解読鍵が通常は提供される。当該スライス(またはファイル)を1つずつ(またはグループごとに)プロテクトすることは、クライアントが支払いを済ませたものを適切に受信し、支払いをしていないものを利用することができないことを保証しながら、すべてのファイルがダウンロードされる前にコンテンツの解読及び再生開始をするのを可能にする。
本発明によると、クライアントは、予めコンテンツ全体に対する支払いをする必要はない。再生の進捗に応じて、支払いが進捗する。クライアントは、コンテンツを再生開始し、所望する場合には、コンテンツ全体がダウンロードされる前に切断することができる。このような場合、クライアントは、最終的に受信したものに対する支払いのみを行うことになる。
本発明は、コンテンツプロバイダとクライアントの両方に利益を保護する。
本発明によると、ファイルベースのコンテンツが、ポイント・ツー・ポイント接続を介しコンテンツサーバからクライアント装置にダウンロードされる。IPネットワークを介し、ポイント・ツー・ポイント接続は通常はHTTPプロトコル(IETFのRFC2616に規定されるHyper Text Transfer Protocol)により規制される。HTTPプロトコルは、ワールドワイドウェブに基づくものであり、従って、すべてのファイアフォールとネットワークアドレストランスレータ(RTP/UDPトランスポートプロトコルのケースではない)により受付けられるという大きな効果を有する。このことは、送信されたコンテンツが制限なくワールドワイドウェブにアクセス可能な任意のクライアント装置にアクセス可能であるということを意味する。ダウンロード配信モードを利用する他の効果は、それを信頼性の高いものにするということである。
しかしながら、欧州特許出願第1187423号に記載されるタイプのダウンロード配信モードを利用することは、第1ファイルから始まりすべてのファイルを送信する必要があるという欠点を有する。このようなダウンロード配信モードによると、クライアントはランダムにコンテンツにアクセスすることはできない。ライブコンテンツ(すなわち、ライブイベント、ライブショー、放送テレビ番組などのリアルタイムに利用可能なコンテンツ)の送信は実現できない。
本発明の効果的な実施例では、互いに独立して復号できるようにスライスが生成される。このことは、クライアントがそれの始めからコンテンツを受信する必要がないことを意味する。それは、任意のスライスからコンテンツの受信を開始することができる。クライアントがライブコンテンツに対する最初のリクエストを送信すると、クライアントは前のファイルを受信するか(クライアントがやや古い情報を受信することを意味する)、または、次のファイルが準備できるまで待機する必要がある。
本発明によると、クライアント装置によるリクエストの受信により、1つのファイルのみしかダウンロードすることはできない。このことは、特定の用途に対しては、決勝戦の最中に結果のダイジェストをクライアントが取得することを可能にするという効果がある。
複数のファイルがダウンロードされるとき、これらのファイルはクライアント装置により1つずつフェッチ可能であるか、あるいは、最初のリクエストの受信によりコンテンツサーバによって1つずつ送信することも可能である。実際、すべてのクライアントブラウザが1つのリクエストに応答して複数のファイルの受信をサポートするということは保証されていない。従って、クライアント装置がファイルを1つずつフェッチすることが通常は望まれる(すなわち、ダウンロードされる各ファイルに対するフェッチリクエストの送信)。クライアント装置は、適切な時点にフェッチリクエストを自動的に送信するよう具体的に構成することが可能である。あるいは、コンテンツサーバは、クライアント装置にフェッチリクエストを繰り返し送信させる文書をクライアント装置に送信することができる。効果的には、当該文書は、クライアント装置が前のファイルの再生終了の所定時間前に、以降のフェッチリクエストを送信する命令を有する。このように、次のファイルが十分早くクライアント装置に到着し、クライアントが再生処理におけるギャップを受けないことが保証される。
図1は、本発明によるシステムの第1実施例の概略図である。図1のシステムは、マルチメディアコンテンツを取得するソース1と、受信したマルチメディアコンテンツを符号化するエンコーダ5と、符号化したマルチメディアコンテンツを一組のスライスにスライスし、各ファイルが前記符号化したマルチメディアコンテンツの一スライスを有する一組のファイルを提供し、ファイルに含まれる少なくとも当該スライスがそれに係る解読鍵なしには利用することができないように暗号化アルゴリズムを実現するスライサ6と、前記ファイルにアクセスするコンテンツサーバ8と、コンテンツサーバ8にリンクする配信ネットワーク10と、クライアント装置14に配信ネットワーク10とのアクセスを提供するアクセスプロバイダ12と、配信ネットワーク10とリンクし、クライアント装置14にダウンロードしたファイルに係る1以上の解読鍵を提供するキーサーバ15とを有する。
図1のシステムでは、ソース1、エンコーダ5及びスライサ6は、1つまたは複数の装置に物理的に配置されていてもよい。
図2は、本発明によるシステムの第2実施例の概略図である。図1を参照して上述された要素に加えて、図2のシステムは、ソース1により与えられるマルチメディアコンテンツを配信する配信システム16と、配信されたマルチメディアコンテンツを受信し、受信したマルチメディアコンテンツをスライサ6に転送する受信機17とを有する。
クライアント装置14は、アクセスプロバイダ12との送受信のための通信ユニット20と、符号化されたマルチメディアコンテンツを再生するプレーヤー22と、マルチメディアコンテンツを表示するディスプレイ24とを有する(図1に示されていない他の手段の中で)。クライアント装置14は、通信ユニット20が無線通信ユニットとなるモバイル装置(携帯電話など)、または通信ユニット20が有線通信ユニットとなる有線装置(PCなど)の何れであってもよい。配信ネットワーク10は、典型的にはインターネットネットワークである。
例えば、配信システム16は衛星配信ネットワークであり、受信機17は衛星受信機である。このことは限定的ではない。すなわち、他の任意の配信手段が、衛星配信手段の代わりに利用可能である。配信されるマルチメディアコンテンツは、受信機17を含むいくつかの受信機により受信可能であって、送信される任意のマルチメディアコンテンツであってもよい。配信マルチメディアコンテンツは、例えば、テレビ番組、予め記録されたイベント/番組、ライブイベントなどであってもよい。エンコーダ5は、受信したマルチメディアコンテンツを符号化するためのものである。エンコーダ5は、例えば、MPEG規格やH263に準拠する。
エンコーダ5とスライサ6は、単一の装置または2つの独立した装置により実現される。何れの場合でも、エンコーダ5からスライサ6に送信されるものは、符号化された映像ストリームである。効果的には、この符号化映像ストリームは、RTPプロトコルを利用することによりIPを介しエンコーダ5からスライサ6に送信される。これは限定的なものではない。例えば、MPEG−2 TSとして知られるMPEG−2規格のトランスポートレイヤもまた利用可能である。
実際、スライサ6により生成されたファイルは、コンテンツサーバ8がアクセスするストレージユニット26に格納される。ストレージユニット26は、スライサ6とコンテンツサーバ8により共有されている。ストレージユニット26は、コンテンツサーバ8の一部とすることも可能であり、あるいは遠隔配置することも可能である。
スライサ6は、以下の機能を有する。
a)それは、エンコーダ5により生成される符号化されたコンテンツを、各スライスが当該符号化マルチメディアコンテンツの所定時間からなる複数のスライスにスライスする。
b)それは、各スライスからファイルを生成する。
c)それは、ファイルに含まれる少なくとも当該スライスが、それに係る解読鍵なしには利用できないように暗号化アルゴリズムを実現する。これは、スライスまたはファイルを暗号化することにより実現可能である。ファイルの暗号化は簡単であるという効果を有する。スライスの暗号化はより複雑である。しかしながら、それは、第1ファイルを解読する必要なく、クライアント側でファイル構造(ヘッダなどに)に含まれるファイル情報へのアクセスを可能にする。例えば、スライサ6により用いられる暗号化アルゴリズムは、AES(Advanced Encryption Standard)である。暗号化は、暗号鍵を用いて実行される。係る解読鍵が、符号化されたエンティティ(スライスまたはファイル)の解読を実現するのに必要とされる。キーサーバ15は、暗号鍵をスライサ6に送り、解読鍵をクライアント装置14に送信するためのものである。
a)それは、エンコーダ5により生成される符号化されたコンテンツを、各スライスが当該符号化マルチメディアコンテンツの所定時間からなる複数のスライスにスライスする。
b)それは、各スライスからファイルを生成する。
c)それは、ファイルに含まれる少なくとも当該スライスが、それに係る解読鍵なしには利用できないように暗号化アルゴリズムを実現する。これは、スライスまたはファイルを暗号化することにより実現可能である。ファイルの暗号化は簡単であるという効果を有する。スライスの暗号化はより複雑である。しかしながら、それは、第1ファイルを解読する必要なく、クライアント側でファイル構造(ヘッダなどに)に含まれるファイル情報へのアクセスを可能にする。例えば、スライサ6により用いられる暗号化アルゴリズムは、AES(Advanced Encryption Standard)である。暗号化は、暗号鍵を用いて実行される。係る解読鍵が、符号化されたエンティティ(スライスまたはファイル)の解読を実現するのに必要とされる。キーサーバ15は、暗号鍵をスライサ6に送り、解読鍵をクライアント装置14に送信するためのものである。
スライサ6は、同一のマルチメディアコンテンツに対して複数のファイル群を生成することが可能である。例えば、スライサ6が複数のファイル群を生成するとき、スライス位置の各組がスライス位置のその他の組と比較して時間シフトされている複数のスライス位置の組が利用可能である。複数のファイル群を生成することは、クライアントがライブコンテンツに対するリクエストを送信するとき、クライアントが被る遅延を低減することを可能にするため効果的である。
図3は、スライス位置Tij(j=1,...,N−1)において符号化されたマルチメディアコンテンツをスライスすることによって、スライサ6により生成されるファイルFij(j=1,...,N)の組Siを表す。
効果的な実施例では、これらのスライスは、互いに独立に復号できるように生成される。実際、マルチメディアエンコーダにより生成される任意の符号化マルチメディアコンテンツは、いわゆるランダムアクセスポイント(RAP)から構成される。その他のものとは独立に復号可能なスライスを生成するため、スライサ6は、各スライスがランダムアクセスポイントから開始されるように符号化されたマルチメディアコンテンツをスライスする。例えば、エンコーダがMPEG−2またはMPEG−4規格に準拠しているとき、ランダムアクセスポイントは、MPEG符号化マルチメディアコンテンツのIフレームであり、スライス位置は、各スライスの第1フレームがIフレームとなるように選ばれる。
任意的には、スライスのサイズは調整可能である。それはすべてのスライスに対して同一であってもよいし、あるいは、スライスごとに可変とされてもよい(例えば、スライスのサイズは、時間の経過と共に大きくなるようにしてもよい)。最善の効率は、多くのファイルが転送されるほど、ファイルヘッダによるより大きなオーバーヘッドがもたらされるという理由から、比較的長いファイルにより得られる。
スライサ6により生成される各ファイルは、ストレージユニット26にファイルとして格納される。ストレージユニット26は、新たに生成されたファイルを格納するためのスペースが利用可能でことを保証するため、通常は「クリーン」にされる必要がある。ストレージユニットをクリーニングする方法は、通常はファイル名を再利用するというものである。他の方法は、各ファイルに対して異なるファイル名を使用し、通常は時間が経過したファイルを削除するというものである。
コンテンツサーバ8とキーサーバ15は、配信ネットワーク10を介しリンクする。クライアント装置14は、アクセスプロバイダ12を介し配信ネットワーク10にアクセスする。典型的には、クライアント装置14は、配信ネットワーク10を介し、クライアントサーバ8がダウンロードするため提供する1つの符号化マルチメディアコンテンツとの少なくとも1つのリンクを有するページをロードすることができる。ユーザが当該リンクをクリックすると、符号化マルチメディアコンテンツに向けられた最初のリクエストR0が、自動的にコンテンツサーバ8に送信される。コンテンツサーバ8が最初のリクエストR0を処理する方法は、複数存在する。
第1実施例では、コンテンツサーバ8は、クライアントレクエストに応答して、1つのファイルをダウンロードする。当該実現形態は、ライブイベントに関する情報を抽出するためクライアントに提供するアプリケーションなどの特定のアプリケーションに利用可能である。それはまた、クライアント装置14に最初のリクエストR0を繰り返し送信させるよう具体的に構成されたプレーヤー22により利用可能である。
第2実施例では、コンテンツサーバ8は、ファイルがサーバ側で準備できるとすぐに、1つずつダウンロードする。本実施例は、実現が容易であるという効果を有する。しかしながら、1つのリクエストに応答して、クライアントブラウザは複数のファイルの受信をサポートしていない可能性がある。
第3実施例では、コンテンツサーバ8は、最初のリクエストR0を受信すると、クライアント装置に文書を送信する。この文書は、クライアント装置14に符号化されたマルチメディアコンテンツを指定するフェッチしたリクエストを繰り返し送信させる。
例えば、コンテンツサーバ8により送信される文書は、自動リフレッシュコマンドを有するページであってもよい。このようなページの一例として、以下のものが与えられる。
あるいは、コンテンツサーバ8により送信される文書は、標準的な方法によりプレーヤー22により処理されるマルチメディアコンテンツの標準的記述であってもよい。このような記述は、例えば、SMIL記述であってもよい(SMILは、XMLベースの音声/映像シーン記述を規定するW3C規格である)。このようなSMIL記述の一例が、以下に与えられる。
効果的には、コンテンツサーバ8により送信されるSMIL文書は、ファイルが予めある時間だけ(すなわち、前のファイルの再生の終了前の時間)フェッチされる必要があることを示すコマンドを有する。このことは、クライアントにマルチメディアコンテンツのレンダリングにおいてギャップが生じないように、次のファイルが時間内にクライアント装置14に到達することを保証する。このようなコマンドを有するSMIL記述の一例が、以下に与えられる。
a)第1ソース(live2download1.mp4)の最初の25秒を再生する
b)第1ソースの最後の5秒を再生し、第2ソース(live2download2.mp4)の最初の5秒をパラレルにフェッチする
c)第2ソースの最初の25秒を再生する(最初の5秒は予めフェッチされているため、遅延なく実行可能である)
2つのソースを利用することが、実現形態のトリックである。コンテンツサーバ8は、第1及び第2ソースが同一の符号化マルチメディアコンテンツに対応することを認識するよう構成される必要がある。
ダウンロードされるコンテンツがライブコンテンツであるとき、サーバは、最初のリクエストR0の受信またはフェッチしたリクエストの受信に応答して、どのファイルをダウンロードするか選択する必要がある。コンテンツサーバ8は、準備のため直近のファイルまたは最初のファイルを選択することができる。直近のファイルを選択した結果、クライアントは古いデータを受信することになる。第1ファイルを準備するよう選択した結果、クライアントはレスポンス取得前に一定時間待機する必要がある。図2において、矢印Aは、コンテンツサーバ8による最初のリクエストR0の受信を示す。ダウンロードされたファイルがファイルFi1である場合、クライアントは遅延を受けないが、しかしながら、ai1だけ遅れてデータを受信するであろう。ダウンロードファイルがファイルFi2である場合、クライアントは古いデータを受信することはないが、bi2に等しい遅延を受けることになる。
ファイルのダウンロードが達成されると、クライアント装置14は、ファイルのコンテンツを再生できるようにするため、関連する解読鍵を取得する必要がある。この解読鍵を取得する2つの方法が、図4及び5を参照してそれぞれ説明される。
図4において、クライアント装置14は、ダウンロードが成功したことを示すアクノリッジメント30をコンテンツサーバ8に送信する。アクノリッジメント30を受信すると、コンテンツサーバ8は、通知32をキーサーバ15に送信する。通知32を受信すると、キーサーバ15は、適切な解読鍵を有するメッセージ34をクライアント装置14に送信する。
図5において、クライアント装置14は、ダウンロードが成功したことを示すアクノリッジメント40をコンテンツサーバ8に、リクエスト42をキーサーバ15に送信する。アクノリッジメント40を受信すると、コンテンツサーバ8は通知43をキーサーバ15に送信する。通知43とリクエスト42を受信すると、キーサーバ15は適切な解読鍵を有するメッセージ44をクライアント装置14に送信する。
配信ネットワーク10を介した送信は、HTTPプロトコルにより規制される。
本発明によるマルチメディアコンテンツMをクライアント装置14に送信する方法の第1実施例が、図6を参照して説明される。それは、マルチメディアコンテンツMから符号化されたマルチメディアコンテンツE(M)を生成するステップX1と、符号化されたマルチメディアコンテンツE(M)を一組のスライスSiにスライスするステップX2と、暗号化アルゴリズムXを適用することによりスライスSi(またはスライス群)を暗号鍵KXiにより暗号化し、これにより暗号化スライスX(Si、KXi)を提供するステップX3と、各ファイルFiが暗号化スライスX(Si、KXi)を有する一組のファイルFiを提供するステップX4と、クライアント装置14からマルチメディアコンテンツMに対する最初のリクエストR0の受信により、配信ネットワーク10を介しクライアント装置14にファイルFiの少なくとも1つをダウンロードするステップX5とを有する。
本発明によるマルチメディアコンテンツMをクライアント装置14に送信する方法の第2実施例が、図6を参照して説明される。それは、マルチメディアコンテンツMから符号化されたマルチメディアコンテンツE(M)を生成するステップX10と、符号化されたマルチメディアコンテンツE(M)を一組のスライスSiにスライスするステップX20と、各ファイルFiがスライスSiを有する一組のファイルFiを提供するステップX25と、暗号化アルゴリズムXを適用することによりファイルFi(またはファイル群)を暗号鍵KXiにより暗号化し、これにより暗号化ファイルX(Fi、KXi)を提供するステップX30と、クライアント装置14からマルチメディアコンテンツMに対する最初のリクエストR0の受信により、配信ネットワーク10を介しクライアント装置14にファイルX(Fi、KXi)の少なくとも1つをダウンロードするステップX50とを有する。
これらのステップは、1以上の装置に構成された特定のハードウェア及び/またはソフトウェアにより実現される。例えば、ステップX1とX10はエンコーダ5により実現され、ステップX2、X3、X4及びX20、X25、X30はスライサ6により実現され、ステップX5とX50はコンテンツサーバ8により実現される。
説明されたネットワーク、サーバ、システム、スライサ、クライアント装置及びダウンロード方法に関して、本発明の範囲から逸脱することなく変更または改良が提案されるかもしれない。従って本発明は、与えられた実施例に限定されるものではない。
HTTP以外のファイル転送プロトコルが、利用されてもよい(例えば、FTPなど)。
コンテンツサーバとキーサーバは、同一の物理的エンティティであってもよい。暗号化はスライスまたはファイルの何れかに適用されてもよい。暗号鍵及び対になる解読鍵は、用いられる暗号化アルゴリズムに応じて異なるまたは同一のものであってもよい。
明細書及び請求項における「有する」という動詞及びその派生語の使用は、明細書及び請求項に記載されている以外の要素またはステップの存在を排除するものではない。
要素またはステップを指定する冠詞「ある」の使用は、当該要素またはステップが複数存在することを排除するものではない。
Claims (10)
- マルチメディアコンテンツを取得するソースと、
前記マルチメディアコンテンツを符号化するエンコーダと、
前記符号化されたマルチメディアコンテンツを少なくとも一組のスライスにスライスし、前記少なくとも一組のスライスから少なくとも一組のファイルを提供し、ファイルに含まれるスライスが、係る解読鍵なしには利用できないように暗号化アルゴリズムを実現するスライサと、
配信ネットワークと、
クライアント装置に前記配信ネットワークへのアクセスを提供するアクセスプロバイダと、
前記配信ネットワークにリンクされ、前記クライアント装置からのリクエストの受信に応答して、前記配信ネットワークを介し前記ファイルの少なくとも1つを前記クライアント装置にダウンロードするため、前記一組以上のファイルにアクセスするコンテンツサーバと、
前記配信ネットワークにリンクし、前記ダウンロードしたファイルに係る前記1以上の解読鍵を前記クライアント装置に提供するキーサーバと、
を少なくとも有することを特徴とするシステム。 - 請求項1記載のシステムであって、
解読鍵は、該解読鍵に係る以上のファイルのダウンロードの成功に応答して、前記クライアント装置に提供されることを特徴とするシステム。 - 請求項1記載のシステムであって、
スライスは、互いに独立に復号可能となるよう生成されることを特徴とするシステム。 - 符号化されたマルチメディアコンテンツを少なくとも一組のスライスにスライスすることにより生成される少なくとも一組のファイルにアクセスし、ファイルに含まれるスライスが、係る解読鍵なしには利用できないように暗号化アルゴリズムを実現することによって、前記少なくとも一組のスライスから少なくとも一組のファイルを提供するコンテンツサーバであって、
当該コンテンツサーバは、クライアント装置からのリクエストの受信に応答して、前記ファイルの少なくとも1つを前記クライアント装置にダウンロードする手段を有することを特徴とするコンテンツサーバ。 - 請求項4記載のコンテンツサーバであって、
前記ファイルは、互いに独立に復号可能なスライスから得られることを特徴とするコンテンツサーバ。 - 請求項4記載のコンテンツサーバであって、さらに、
前記クライアント装置へのファイルのダウンロードの成功に応答して、キーサーバが前記クライアント装置に前記ファイルに係る解読鍵を提供するように、前記キーサーバに通知を送信する手段を有することを特徴とするコンテンツサーバ。 - 請求項4記載のコンテンツサーバであって、
前記ダウンロード手段は、
前記リクエストの受信に応答して、前記クライアント装置に前記符号化されたマルチメディアコンテンツを指定するフェッチしたリクエストを繰り返し送信させる文書を前記クライアント装置に送信する手段と、
前記クライアント装置からのフェッチしたリクエストの受信に応答して、前記1以上のファイルの中からどのファイルをダウンロードするか選択する手段と、
前記選択されたファイルをダウンロードする手段と、
を有することを特徴とするコンテンツサーバ。 - 符号化されたマルチメディアコンテンツを少なくとも一組のスライスにスライスし、ファイルに含まれるスライスが、係る解読鍵なしには利用できないように暗号化アルゴリズムを実現することにより生成される、各ファイルがスライスを有する少なくとも一組のファイルにアクセスし、前記符号化されたマルチメディアコンテンツの少なくとも一部をファイルごとにダウンロードするよう提供するコンテンツサーバに接続する手段と、
前記符号化されたマルチメディアコンテンツに対するリクエストを前記コンテンツサーバに繰り返し送信する手段と、
各リクエストに応答して、前記ファイルの1つを受信する手段と、
各ファイルに係る解読鍵を取得する手段と、
前記ファイルを解読及び再生する手段と、
を有することを特徴とするクライアント装置。 - 請求項8記載のクライアント装置であって、さらに、
現在のファイルの再生終了前に以降のリクエストを送信する手段を有することを特徴とするクライアント装置。 - 符号化されたマルチメディアコンテンツをクライアント装置に送信する方法であって、
マルチメディアコンテンツを符号化するステップと、
前記符号化されたマルチメディアコンテンツを少なくとも一組のスライスにスライスし、前記少なくとも一組のスライスから少なくとも一組のファイルを提供し、ファイルに含まれたスライスが係る解読鍵なしには利用できないように暗号化ステップを有するスライスするステップと、
前記クライアント装置からのリクエストの受信に応答して、前記配信ネットワークを介し前記ファイルの少なくとも1つを前記クライアント装置にダウンロードするステップと、
を有することを特徴とする方法。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP03292520 | 2003-10-10 | ||
PCT/IB2004/002140 WO2005004485A1 (en) | 2003-07-04 | 2004-06-23 | Method of broadcasting multimedia content via a distribution network |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2007528140A true JP2007528140A (ja) | 2007-10-04 |
Family
ID=38640116
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2006518388A Withdrawn JP2007528140A (ja) | 2003-10-10 | 2004-06-23 | 配信ネットワークを介したマルチメディアコンテンツの配信方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2007528140A (ja) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2011239472A (ja) * | 2011-08-15 | 2011-11-24 | Hitachi Ltd | コンテンツ再生装置およびコンテンツ再生方法 |
JP2012138083A (ja) * | 2008-12-31 | 2012-07-19 | Apple Inc | リアルタイム又はほぼリアルタイムのストリーミング |
JP2013500652A (ja) * | 2009-11-09 | 2013-01-07 | ▲ホア▼▲ウェイ▼技術有限公司 | Httpベースのストリーミングメディアサービスを実施するための方法、システムおよびネットワークデバイス |
JP2016523002A (ja) * | 2013-03-15 | 2016-08-04 | ビデリ、インコーポレイテッドVideri Inc. | デジタル・アートを表示、配信、鑑賞および制御し、画像形成するためのシステムおよび方法 |
CN117390684A (zh) * | 2023-12-06 | 2024-01-12 | 深圳市智能派科技有限公司 | 基于切片层级关联的数据加密处理方法及系统 |
-
2004
- 2004-06-23 JP JP2006518388A patent/JP2007528140A/ja not_active Withdrawn
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2012138083A (ja) * | 2008-12-31 | 2012-07-19 | Apple Inc | リアルタイム又はほぼリアルタイムのストリーミング |
JP2013500652A (ja) * | 2009-11-09 | 2013-01-07 | ▲ホア▼▲ウェイ▼技術有限公司 | Httpベースのストリーミングメディアサービスを実施するための方法、システムおよびネットワークデバイス |
US9338216B2 (en) | 2009-11-09 | 2016-05-10 | Snaptrack, Inc. | Method, system and network device for implementing HTTP-based streaming service |
JP2011239472A (ja) * | 2011-08-15 | 2011-11-24 | Hitachi Ltd | コンテンツ再生装置およびコンテンツ再生方法 |
JP2016523002A (ja) * | 2013-03-15 | 2016-08-04 | ビデリ、インコーポレイテッドVideri Inc. | デジタル・アートを表示、配信、鑑賞および制御し、画像形成するためのシステムおよび方法 |
CN117390684A (zh) * | 2023-12-06 | 2024-01-12 | 深圳市智能派科技有限公司 | 基于切片层级关联的数据加密处理方法及系统 |
CN117390684B (zh) * | 2023-12-06 | 2024-04-09 | 深圳市智能派科技有限公司 | 基于切片层级关联的数据加密处理方法及系统 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7912218B2 (en) | Method of broadcasting multimedia content via distribution network | |
US10698985B2 (en) | Extending data confidentiality into a player application | |
KR101445994B1 (ko) | 압축된 재생목록을 이용한 실시간 또는 준 실시간 스트리밍 | |
US9584556B2 (en) | Client proxy for adaptive bitrate selection in HTTP live streaming | |
US9203816B2 (en) | Controlling access to copies of media content by a client device | |
US9118630B2 (en) | Client proxy for key exchange in HTTP live streaming | |
US20130144714A1 (en) | Method, Apparatus and System for Supporting Advertisement Contents in HTTP Streaming Play Mode | |
US20090031424A1 (en) | Incomplete data in a distributed environment | |
US20090003592A1 (en) | Content delivery system, delivery server, terminal, and content delivery method | |
US20140068693A1 (en) | Method, system, or user device for adaptive bandwidth control of proxy multimedia server | |
US20080281803A1 (en) | Method of Transmitting Content With Adaptation of Encoding Characteristics | |
US8327406B2 (en) | Method and server for downloading a broadcasted multimedia content over a distribution network | |
EP3855751A1 (en) | Automated video content processing | |
EP2651123B1 (en) | Personal network video recording device and method for operation of a personal network video recording device. | |
JP2007528140A (ja) | 配信ネットワークを介したマルチメディアコンテンツの配信方法 | |
WO2019193991A1 (ja) | 配信装置、配信方法、およびプログラム | |
WO2017207861A1 (en) | An arrangement for media stream organization | |
KR101550661B1 (ko) | 모바일 스트리밍 시스템 및 모바일 단말 | |
CN114363721A (zh) | 基于hls的视频播放方法、装置、设备及存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A711 Effective date: 20080423 |
|
A761 | Written withdrawal of application |
Free format text: JAPANESE INTERMEDIATE CODE: A761 Effective date: 20090911 |