(57)【要約】  本発明は、サーバからクライアント端末へのマルチメディア・コンテンツの送信に適用される。前記マルチメディア・コンテンツは、１つ又は複数の組のファイルとして前記サーバから入手可能である。初期リクエストを前記クライアントから受信すると、前記サーバは、文書を前記クライアントへ送信して戻し、前記文書は、前記クライアントに、フェッチリクエストを繰り返し送信するようにさせる。フェッチリクエストを受信すると、前記サーバは、ダウンロードするべきファイルを選択する。
2007528044.tif 000002
【特許請求の範囲】
【請求項１】
符号化されたマルチメディア・コンテンツを、互いに独立して復号化され得るスライスを形成する少なくとも１つの組のスライス位置においてスライスし、各スライスをファイルに封入し、これにより少なくとも１つの組のファイルを生成することによって生成される少なくとも１つの組のファイルへのアクセスを有するサーバであって、前記サーバが、
−マルチメディア・コンテンツへ向けられた初期リクエストをクライアント装置から受信する手段と、
−前記初期リクエストを受信すると文書を前記クライアント装置へ送信する手段であって、前記文書が、前記クライアント装置に、前記マルチメディア・コンテンツを指定するフェッチリクエストを繰り返し送信するようにさせる手段と、
−前記クライアント装置から前記フェッチリクエストを受信すると、前記組のファイルの中から少なくとも１つのファイルを選択する手段と、
−前記選択されたファイルを前記クライアント装置へダウンロードする手段と
を有するサーバ。
【請求項２】
前記文書が、前記マルチメディア・コンテンツを指定し前記クライアント装置に特有のリソース識別子を含み、前記クライアント装置に、前記リソース識別子を含むフェッチリクエストを繰り返し送信するようにさせ、前記サーバが、
−第１フェッチリクエストを受信すると有効にされ、前記ファイルの組の中からダウンロードされるべき第１ファイルを選択し、かつ前記リソース識別子を前記選択されたファイルの指示と共に記録に残す手段と、
−後続のフェッチリクエストを受信して有効にされ、次にダウンロードされるべきファイルを選択するために前記記録を確認し、かつ前記記録を更新する手段と
を有する、請求項１に記載のサーバ。
【請求項３】
前記文書が、前記クライアント装置が、該以前のフェッチリクエストに応答してダウンロードされた前記ファイルの再生の終わりの前に後続のフェッチリクエストを送信する命令を有する、請求項１又は２の何れか一項に記載のサーバ。
【請求項４】
ダウンロードすべきファイルを前記フェッチリクエストに含まれるジャンプ指示に基づいて選択する手段を有する、請求項２に記載のサーバ。
【請求項５】
符号化されたマルチメディア・コンテンツをクライアント装置へダウンロードする方法であって、前記方法が、
−マルチメディア・コンテンツを符号化するステップと、
−前記符号化されたマルチメディア・コンテンツを、互いに独立して復号化され得る少なくとも１つの組のスライスを形成する少なくとも１つの組のスライス位置においてスライスするステップと、
−各スライスをファイルに封入すると共にこれにより少なくとも１つの組のファイルを生成するステップと、
−初期リクエストをクライアント装置から受信するステップであって、前記初期リクエストが、前記マルチメディア・コンテンツに向けられているステップと、
−前記初期リクエストを受信すると文書を前記クライアント装置へ送信するステップであって、前記文書が、前記クライアント装置に、前記マルチメディア・コンテンツを指定するフェッチリクエストを繰り返し送信するようにさせるステップと、
−前記クライアント装置から前記フェッチリクエストを受信すると、前記組のファイルから少なくとも１つのファイルを選択するステップと、
−前記選択されたファイルを前記クライアント装置へダウンロードするステップと
を有する方法。
【請求項６】
前記文書が、前記マルチメディア・コンテンツを指定し前記クライアント装置に特有のリソース識別子を含むと共に、前記クライアント装置に、前記リソース識別子を含むフェッチリクエストを繰り返し送信するようにさせ、また当該方法が、更に、
−第１フェッチリクエストを受信すると、前記組のファイルの中からダウンロードされるべき第１ファイルを選択し、前記リソース識別子を前記選択されたファイルの指示と共に記録に残すステップと、
−後続のフェッチリクエストを受信すると、次にダウンロードされるべきファイルを選択するために前記記録を確認し、かつ前記記録を更新するステップと
を有する、請求項５に記載の方法。
【請求項７】
前記文書が、前記クライアント装置が、該以前のフェッチリクエストに応答してダウンロードされた前記ファイルの再生の終わりの前に後続のフェッチリクエストを送信する命令を有する、請求項５又は６の何れか一項に記載の方法。
【請求項８】
ダウンロードすべきファイルを選択する前記ステップが、前記受信されるフェッチリクエストに含まれるジャンプ指示を考慮に入れる、請求項６に記載の方法。
【請求項９】
ネットワークシステムであって、少なくとも、
−マルチメディア・コンテンツを取得する供給源と、
−前記マルチメディア・コンテンツを符号化する符号化器と、
−前記符号化されたマルチメディア・コンテンツを、互いに独立して復号化され得る少なくとも１つの組のスライスを形成する少なくとも１つの組のスライス位置でスライスすると共に、各スライスをファイルに封入し、これにより少なくとも１つの組のファイルを生成するスライサと、
−配信ネットワークと、
−クライアント装置に前記配信ネットワークへのアクセスを提供するアクセス・プロバイダと、
−請求項１ないし４の何れか一項に記載のサーバと
を有するネットワークシステム。
【請求項１０】
計算機プログラムであって、前記プログラムが処理器によって実行される場合に、請求項５ないし８の何れか一項に記載の方法を実行する命令を有する計算機プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチメディア・コンテンツをクライアント装置へダウンロードする方法に関する。
【０００２】
また本発明は、処理器によって実行される場合に斯様な方法を実施する命令を含む計算機プログラムにも関する。
【０００３】
また本発明は、マルチメディア・コンテンツをクライアント装置へダウンロードするように特別に設計されたサーバ及びネットワークシステムにも関する。
【０００４】
本発明は、インターネットを介してクライアント装置へのマルチメディア・コンテンツ（生放送イベント又はテレビ番組放送のような生放送コンテンツを含む）の送信に関する興味深い応用例を有する。また本発明は、インターネットを介したある携帯装置から１つ又は複数の同等の装置（peer  device）へのビデオの送信にも適用される。
【背景技術】
【０００５】
国際特許出願第WO02/49343号は、音声またはビデオ資料であって、前記資料の連続的で時間的な部分を表すファイルの一組として遠隔地サーバにおいて記憶される音声またはビデオ資料を端末へ送信する方法を開示する。
【０００６】
開示される方法において、端末は、該端末がどのファイルを受信することを望んでいるかを決定することと共に各ファイルを１つずつ要求することに関して責任を負う。
【０００７】
この解決法は、２つの主な欠点を有しており、１つ目として、端末は、提案された配信方法を実施するのに特別に設計されなければならず、２つ目として、サーバは、どのファイルがダウンロードされるかに関しての如何なる制御も有さない。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
本発明の目的の１つは、上述の問題を有さない代わりの配信方法を提案することである。
【課題を解決するための手段】
【０００９】
このことは、請求項１〜４に記載のサーバ、請求項５〜８に記載のダウンロード方法、請求項９に記載のネットワークシステム及び請求項１０に記載の計算機プログラムを用いて実現される。
【００１０】
本発明に従うと、サーバは、クライアント装置からマルチメディア・コンテンツへ指示された初期リクエストを受信すると、前記クライアント装置へ文書を送り返す。この文書は、前記クライアント装置にフェッチリクエストを繰り返し送信するようにさせる。サーバは、前記フェッチリクエストを受信すると、どのファイルがダウンロードされるべきかを選択する。
【００１１】
本発明に従うフェッチリクエストは、ダウンロードされるべきいずれの特定のファイルも示さない。これらは、次のファイルに関する単なるリクエストである。
【００１２】
ダウンロードされるべき各ファイルに関するフェッチリクエストをクライアント装置に送信させることの１つの有利な点は、斯様な動作方法が全てのクライアントブラウザによってサポートされていることである（あるブラウザは、単一のリクエストに応答していくつかのファイルを受信することをサポートしないこともあり、したがって、サーバに、クライアント装置による単一のリクエストを受信した時にファイルを１つずつ送信させないことが好ましい）。
【００１３】
本発明を用いると、クライアント装置は、サーバから受信された文書によりフェッチリクエストを送信するようにさせられる。これが意味するのは、クライアント装置は、フェッチリクエストを送信するのに特別に設計される必要がないということである。如何なる標準クライアント装置も、本発明を実施することが可能である。
【００１４】
本発明は、互いに相違するスライス部分を具える、同一のマルチメディア・コンテンツに関する１つ又は複数の組を発生すること（ファイルが、各々の組において別々の時間部分において開始している）を提案する。クライアントが生放送コンテンツを指示する初期リクエストを送信する場合、該クライアントは、以前のファイルを受信する（該クライアントは、期限切れの情報を受信し得ることを意味する）か又は、次のファイルが用意できる状態になるのを待つ必要がある。両方の場合において、いくつかのファイルの組を用いることにより、使用者にとっての不便さを減らすことが可能になる。組の数は、クライアントによって遭遇される不便さとファイルを記憶するのに必要とされる記憶ユニットスペースとの間における折衷物である。
【００１５】
ファイルを基にしたコンテンツは、サーバからクライアント装置へポイント・ツー・ポイント接続を介して送信される。ＩＰネットワークにおいて、ポイント・ツー・ポイント接続は、ＨＴＴＰプロトコル(ＩＥＴＦのＲＦＣ２６１６において定義されるHyper  Text  Transfer  Protocol)によって通常規定される。ＨＴＴＰは、処理状態を把握しないプロトコル(stateless  protocol)であるので、同一のクライアント装置によって発行されるＨＴＴＰリクエストは、通常、独立して夫々区別して処理される。
【００１６】
請求項２及び６の実施例は、サーバが各々のクライアントを追跡するのを可能にする。サーバは、どのファイルが各々のクライアントに次に送信されるべきかを把握しているので、いくつかのファイルの組が利用可能である場合でも、コンテンツの滑らかな再生が実現され得る。
【００１７】
請求項４及び８に記載の実施例は、クライアント装置が如何なるフェッチリクエストにおいても、一連のファイルにおけるジャンプをリクエストするのを可能にするという有利な点を有する。
【００１８】
本発明のこれら及び他の態様は、添付図面を参照にして更に説明される。
【発明を実施するための最良の形態】
【００１９】
図１は、本発明に従うネットワークシステムの概略的表現である。図１のネットワークシステムは、
−マルチメディア・コンテンツを取得する供給源１と、
−前記マルチメディア・コンテンツを放送する放送局２と、
−放送されたマルチメディア・コンテンツを受信する受信器３と、
−受信されたマルチメディア・コンテンツを符号化する符号化器５及び、符号化されたマルチメディア・コンテンツを、互いに独立して復号化され得る少なくとも１つのスライスの組を形成する少なくとも１つのスライス位置の組においてスライスすると共に各スライスをファイルに封入し、これにより少なくとも１つのファイルの組を生成するスライサ６を有する符号化システム４と、
−前記ファイルへのアクセスを有するサーバ８と、
−配信ネットワーク１０であって、サーバ８がリンクされている配信ネットワーク１０と、
−クライアント装置１４に配信ネットワーク１０へのアクセス提供するアクセス・プロバイダ１２と
を有する。
【００２０】
クライアント装置１４は、（図１に示されない他の手段の中でもとりわけ）アクセス・プロバイダ１２への送信及び／又はからの受信をする通信ユニット１５と、符号化マルチメディア・コンテンツを再生するプレーヤ１６と、マルチメディア・コンテンツを表示するディスプレイ１７を有する。クライアント装置１４は、（携帯電話であるような）携帯装置であってもよく、この場合通信ユニット１５は無線通信ユニットであり、又はクライアント装置１４は、（ＰＣのような）有線で繋がった装置であってもよく、この場合通信ユニット１５は、有線通信ユニットである。配信ネットワーク１０は、一般的には、インターネット・ネットワークである。
【００２１】
例えば、放送局２は、衛星放送ネットワークであり、そして受信器３は、衛星受信器である。このことは、制限的ではなく、他の如何なる放送手段も、衛星放送手段の代わりに用いられ得る。放送されるマルチメディア・コンテンツは、送信されると共に受信器３を含む複数の受信器によって受信され得る如何なるマルチメディア・コンテンツであってもよい。例えば、放送されるマルチメディア・コンテンツは、テレビ番組、事前録画されたイベント／番組又は生放送イベント等であってもよい。
【００２２】
符号化器５は、受信されたマルチメディア・コンテンツを符号化する責任を担う。例えば、符号化器５は、ＭＰＥＧ標準のうちの１つに、すなわちＨ２６３に準拠する。
【００２３】
符号化器５及びスライサ６は、単一の装置又は２つの個別の装置の何れかで実施される。両方の場合において、符号化器５からスライサ６へ送られるのは、符号化されたビデオストリームである。有利には、この符号化されたビデオストリームは、符号化器５からスライサ６へＲＴＰプロトコルを用いることによってＩＰを介して送られる。このことは、制限的ではない。例証として、ＭＰＥＧ−２  ＴＳとして知られるＭＰＥＧ２標準のトランスポート層も同様に用いられ得る。
【００２４】
実際面として、スライサ６によって生成されるファイルは、サーバ８がアクセスを有する記憶ユニット２０に記憶される。記憶ユニット２０は、スライサ６及びサーバ８によって共有される。記憶ユニット２０は、サーバ機器の一部であってもよく、又は遠隔地に位置されていてもよい。
【００２５】
スライサ６の機能は、符号化器５によって生成される符号化コンテンツを複数のスライスにスライスすることであり、各スライスは、符号化されたマルチメディア・コンテンツの所与の時間量を有し、他のスライスとは独立して復号化され得る。実際面として、マルチメディア符号化器によって生成される如何なる符号化マルチメディア・コンテンツも、いわゆるランダム・アクセス・ポイント（ＲＡＰ）を有する。互いに独立して復号化され得るスライスを生成するために、スライサ６は、符号化マルチメディア・コンテンツを、各スライスが、ランダム・アクセス・ポイントを用いて開始するように、スライスする。符号化器が、例えば、ＭＰＥＧ−２又はＭＰＥＧ−４に準拠する場合、ランダム・アクセス・ポイントは、ＭＰＥＧ符号化マルチメディア・コンテンツのＩフレームであり、スライス位置は、各スライスの第１フレームがＩフレームであるように選択される。
【００２６】
スライスは、他とは独立して復号化され得るので、クライアントは、コンテンツをその開始から受信する必要はない。クライアントは、コンテンツを何れのスライスから受信するのを開始することも可能である。したがって、本発明は、サーバ側においてリアルタイムで利用可能にされるコンテンツであるような、生放送コンテンツ（例えば、選手権若しくはショーのような生のイベント、又は放送された番組等）の送信に適用可能である。
【００２７】
有利には、スライスのサイズは、調節可能である。スライスのサイズは、同一であってもよく、又は互いに変化してもよい（例えば、スライスのサイズは、時間に沿って増加する等）。最適効率は、比較的長くあるファイルで得られるが、その理由は、より多くのファイルがトランスポートされると、ファイルヘッダが原因であるより多くのオーバヘッドが発生するからである。
【００２８】
スライス６によって生成される各スライスは、記憶ユニット２０においてファイルとして記憶される。記憶ユニット２０は、新たに生成されたファイルを記憶する利用可能な空きが存在することを確実にするために、定期的に「一掃される(clean)」必要がある。記憶ユニットを一掃する方法の１つは、定期的にファイル名を再利用することである。代わりの方法は、各ファイルに関して別々のファイル名を用い、そして定期的に経年したファイルを削除することである。
【００２９】
本発明に従うスライサ６は、同一のマルチメディア・コンテンツに関して１つのファイルの組又は複数のファイルの組の何れかを生成する。スライサ６が、複数のファイルの組を生成する場合、複数のスライス位置の組が用いられ、各々のスライス位置の組は、他のスライス位置の組と比べて時間的にずらされる。図２は、スライス６によって生成される複数のファイルの組S1,S2,…,SNの例示である。各々のファイルの組Siは、Ｋ個のファイルFi,j(i=1,…,N;j=1,…,K)を有する。１つの組のスライス位置{Ti,1,…,Ti,K}は、各々のファイルの組Siに関連付けられる。図２に示されるように、スライス位置Ti+1,jは、スライス位置Ti,jと比較して時間的にずらされる（軸ｔは、時間軸である）。言い換えれば、ファイルFi+1,j及びFi,jは、重なり合っている（これらは、同一の符号化データを有する）。図３において、ファイルFi+1,j及びFi,jの間における重なり合いは、矢印Oi+1によって示される。
【００３０】
以下の説明において明らかであるように、複数のファイルの組を生成することは、このことが、クライアントが生放送コンテンツに関するリクエストを送信する場合にクライアントが遭遇する遅延を低減することを可能にするので、有利なことである。
【００３１】
サーバ８は、配信ネットワーク１０にリンクされる。クライアント装置１４は、アクセス・プロバイダ１２を介して配信ネットワーク１０へのアクセスを有する。通常、クライアント装置１４は、配信ネットワーク１０を介して、サーバ８がダウンロードするように提供するマルチメディア・コンテンツへの少なくとも１つのリンクを含むページをロードすることが可能である。使用者が前記リンクをクリックする場合、前記マルチメディア・コンテンツへ指示される初期リクエストR0が、サーバ８へ自動的に送信される。サーバ８が初期リクエストR0を処理するための可能な方法はいくつかある。
【００３２】
本発明の第１実施例において、サーバ８は、処理リクエストR0を受信すると、クライアント１４へ文書を送信する。この文書は、クライアント装置１４に、マルチメディア・コンテンツを指定するフェッチリクエストを繰り返し送信させるようにする。
【００３３】
例証として、サーバ８によって送信される文書は、自動リフレッシュ命令を有するページであり得る。斯様なページの例は、以下のように与えられる。
<html>
<head>
<META  meta  http-equiv="Refresh"  content="134"  ;  url='http://www.yoursite.com/live2download.html'"
</head>
<embed  src="live2download.mp4"  width="240"  height="240">
</embed>
</html>
【００３４】
斯様なページは、クライアントブラウザにファイル「live2download.mp4」を134秒毎（この例におけるファイルの持続時間）に再ロードするようにさせる。
【００３５】
代わりに、サーバ８によって送信される文書は、マルチメディア・コンテンツの標準的な記述であってもよく、前記標準的な記述は、標準的な方法でプレーヤ１６によって処理されることを意図される。例えば、斯様な記述は、ＳＭＩＬ記述であってもよい。（ＳＭＩＬは、ＸＭＬベースの音声／ビデオシーン記述を定義するＷ３Ｃ標準である）斯様なＳＭＩＬ記述の一例は、以下に与えられる。
<smil>
<head>
<layout>
<root-layout  width="240"  height="240"  background-color="white"/>
<region  regionName="im"  left="0"  top="0"  width="240"  height="240"/>
</layout>
</head>
<body>
<seq  repeatCount  =  "indefinite"  >
<video  id="vid"  src="live2download.mp4"  region="im"  />
</seq>
</body>
</smil>
【００３６】
このＳＭＩＬ文書の効果は、プレーヤ１６にファイル「live2download.mp4」を繰り返し再生させることである。結果として、クライアント装置は、ファイル「live2download.mp4」に向けられたフェッチリクエストを繰り返し送信し得る。
【００３７】
有利には、サーバ８によって送信されるＳＭＩＬ文書は、ファイルが（以前のファイルの再生の終わりのある程度前である）ある程度事前にフェッチされる必要があることを示す命令を有する。このことは、クライアントがマルチメディア・コンテンツの再生において欠落を経験しないように、次のファイルがクライアント装置１４に時間通りに到着することを確実にする。斯様な命令を有するＳＭＩＬ記述の例は、以下に与えられる。
<smil>
<head>
<layout>
<root-layout  width="240"  height="240"  background-color="white"/>
<region  regionName="im"  left="0"  top="0"  width="240"  height="240"/>
</layout>
</head>
<body>
<seq  repeatCount  =  "indefinite"  >
<video  id="vid"  src="live2download1.mp4"  region="im"  clipBegin  =  "0s"  dur  =  "25s"  />
<par>
<prefetch  src="live2download2.mp4"  mediaTime  ="5s"  />
<video  id="vid"  src="live2download1.mp4"  region="im"  clipBegin  =  "25s"  />
</par>
<video  id="vid"  src="live2download2.mp4"  region="im"  clipBegin  =  "0s"  dur  =  "25s"  />
<par>
<prefetch  src="live2download1.mp4"  mediaTime  ="5s"  />
<video  id="vid"  src="live2download2.mp4"  region="im"  clipBegin  =  "25s"  />
</par>
</seq>
</body>
</smil>
【００３８】
この文書は、３０秒のコンテンツを含むスライスに関して記されている。この文書は、プレーヤに、以下の動作を順次的に実行するようにさせる。
a)第１供給源(live2download1.mp4)の最初の２５秒を再生する。
b)最初の供給源の最後の５秒を再生し、並行して第２供給源(live2download2.mp4)の最初の５秒をフェッチする。
c)第２供給源の最初の２５秒を再生する（このことは、最初の５秒が事前フェッチされているので遅延なしに行われる）。
２つの異なる供給源を用いることは、実行のトリックである。サーバ８は、第１及び第２供給源が、同一の符号化マルチメディア・コンテンツに対応することを認識するように設計されなければならない。
【００３９】
サーバは、フェッチリクエストを受信すると、ダウンロードされるべきファイルを選択する必要がある。サーバ８は、最も新しいファイル又は準備が出来る１番目のファイルの何れかを選択し得る。最も新しいファイルを選択することの結果は、クライアントが期限切れのデータを受信し得るということになる。準備が出来る第１番目のファイルを選択することの結果は、クライアントが応答を得る前に特定の時間だけ待機する必要があり得るということになる。両方の場合において、クライアントにとっての不便さは、複数のファイルの組が用いられる場合、低減される。このことは、図４に示される。
【００４０】
図４において、３つのファイルの組S1、S2及びS3が示される。矢印Ａは、サーバ８によるリクエストの受信を示す。
【００４１】
スライサ６によって生成されるべき唯一の組が第１組S1である場合、サーバ８は、ファイルF1,1(最も新しいファイル)又はF1,2(準備出来る次のファイル)の何れかをダウンロードし得る。サーバ８がファイルF1,1をダウンロードする場合、クライアントによって受信されるデータは、a1,1に等しい時間だけ遅れる。サーバがファイルF1,2をダウンロードする場合、クライアントは、データを受信する前にb1,2に等しい遅延を経験する。
【００４２】
３つの組S1、S2及びS3がスライサ６によって生成される場合、サーバ８は、ファイルF2,1(最も新しいファイル)又はF3,2(準備出来る次のファイル)の何れかをダウンロードし得る。サーバ８がファイルF2,1をダウンロードする場合、クライアントによって受信されるデータは、a2,1に等しい時間だけ遅れる。サーバがファイルF3,2をダウンロードする場合、クライアントは、データを受信する前にb3,2に等しい遅延を経験する。a1,1>a2,1及びb1,2>b3,2であることが理解され得る。
【００４３】
配信ネットワーク１０を介しての伝送は、ＨＴＴＰプロトコルによって規定される。ＨＴＴＰは、処理状態を把握しないプロトコルであるので、同一のクライアント装置によって発行されるＨＴＴＰリクエストは、通常互いに独立して処理される。結果として、コンテンツの再生はいくつかのファイルの組が利用可能である場合滑らかに得られないというリスクが存在する（コンテンツのある部分は数回受信され得、又はコンテンツのある部分は行方不明であることもある）。この問題を解決する本発明の第２の実施例が、以下に説明される。
【００４４】
本発明の第２の実施例において、初期リクエストR0に応答してサーバ８によって送信される文書は、クライアントによって求められた符号化マルチメディア・コンテンツを指定するリソース識別子を有する。このリソース識別子は、クライアント装置１４に特有である。サーバ８によって送信される文書は、クライアント装置１４がこのリソース識別子を含むフェッチリクエストを繰り返し送信するようにさせる。第１フェッチリクエストを受信すると、サーバ８は、上述のようにダウンロードされるべきファイルを選択する（最も新しいファイル又は次に準備出来るファイルの何れかを選択する）。サーバ８は、選択されたファイルをダウンロードし、どのファイルがダウンロードされたか(代わりには、どのファイルが次にダウンロードされるか)に関して追跡を行う。サーバ８は、同一のリソース識別子を含む後続のフェッチリクエストを受信すると、次にダウンロードすべきファイルを選択するために記録を確認し、選択されたファイルをダウンロードして、前記記録を更新する。
【００４５】
斯様にして、各々のクライアント装置１４は、完全なかつ正常な順序の一連のファイルを受信する（全ての受信されたファイルは、同一のファイルの組に属する連続的ファイルである）。
【００４６】
例証として、サーバ８によって送信される文書に含まれるリソース識別子は、IETFのRFC1510に定義される「nonce」であり得る（nonceは、１度のみ用いられる数字である）。斯様なリソース識別子を含むＳＭＩＬ文書の一例は、以下に与えられる。
<smil>
<head>
<layout>
<root-layout  width="240"  height="240"  background-color="white"/>
<region  regionName="im"  left="0"  top="0"  width="240"  height="240"/>
</layout>
</head>
<body>
<seq  repeatCount  =  "indefinite"  >
<video  id="vid"  src="cnn142299293873635534291919.mp4"  region="im"  />
</seq>
</body>
</smil>
【００４７】
ここにおいて、リソース識別子は、cnn142299293873635534291919である。クライアント装置１４は、ファイルcnn142299293873635534291919.mp4に関するフェッチリクエストを繰り返し送信する。サーバ８は、リソース識別子cnn142299293873635534291919に関してどのファイルがダウンロードされたか（又はダウンロードされるべきか）を追跡する。
【００４８】
本発明の第３実施例において、クライアント装置によって送信されるフェッチリクエストは、ジャンプ指示（後方／前方命令）を含み得る。例えば、斯様な後方／前方命令は、スライドバーにおけるカーソルを動かすことによってクライアントによって入力される。そしてカーソルの位置又は変位の指示は、フェッチリクエストにおいて含まれる。この指示は、ダウンロードするファイルを決定するのにリソース識別子を用いて一緒にサーバによって用いられる。
【００４９】
上記で説明されてきたステップは、図５において要約される。図５に従うと、本発明に従うマルチメディア・コンテンツMをダウンロードする方法は、
−符号化マルチメディア・コンテンツE(M)を作成するステップＸ１と、
−前記符号化マルチメディア・コンテンツE(M)を、互いに独立して復号化され得る少なくとも１つのスライスの組を形成する少なくとも１つのスライス位置の組においてスライスすると共に、各スライスをファイルFi,jに封入し、これにより少なくとも１つのファイルの組S1,S2,…,SNを生成するステップＸ２と、
−前記初期リクエストR0を受信すると前記クライアント装置へ文書ＤＯＣを送信するステップＸ３であって、前記文書が、前記クライアント装置に前記マルチメディア・コンテンツを指定するフェッチリクエストRt(t=0,…,P、ここでPは整数)を繰り返し送信させるステップＸ３と、
−前記クライアント装置から前記フェッチリクエストを受信すると前記ファイルの組の中から少なくとも１つのファイルFi,jを選択すると共に、前記選択されたファイルを前記クライアント装置へダウンロードするステップと
を有する。
【００５０】
これらのステップは、１つ又は複数の装置に含まれる特有のハードウェア及び／又はソフトウェアを用いて実行される。図１において例えば、ステップＸ１は、符号化器５によって実行され、ステップＸ２は、スライサ６によって実行され、ステップＸ３及びＸ４は、サーバ８によって実行される。
【００５１】
本発明に従うネットワークシステムの２つの他の例が、図６及び図７を参照にして以下に説明される。
【００５２】
図６のネットワークシステムは、第１クライアント装置５０、配信ネットワーク５２、第２クライアント装置５４並びに第１及び第２クライアント装置５０及び５４に配信ネットワーク５２へのアクセスを提供する少なくとも１つのアクセス・プロバイダ５６を有する。
【００５３】
第２クライアント装置５４は、図１を参照にして説明されるクライアント装置に類似する。通常、配信ネットワーク５２は、インターネット・ネットワークである。
【００５４】
第１クライアント装置５０は、
−マルチメディア・コンテンツを取得する供給源６０と、
−取得したマルチメディア・コンテンツを符号化する符号化器６２と、
−符号化マルチメディア・コンテンツを、互いに独立して復号化され得る少なくとも１つのスライスの組を形成する少なくとも１つのスライス位置の組においてスライスすると共に、各スライスをファイルに封入し、これにより少なくとも１つのファイルの組を生成するスライサ６４と、
−前記ファイルへのアクセスを有するサーバ６６と、
−前記アクセス・プロバイダ５６への送信／からの受信をする通信ユニット６８と
を有する。
【００５５】
通常、第１クライアント装置は、携帯電話であり、このことは、通信ユニット６８が無線通信ユニットであることを意味する。
【００５６】
供給源６０、符号化器６２、スライサ６４及びサーバ６６の機能性は、図１〜４を参照にして上述される供給源１、符号化器５、スライサ６及びサーバ８の機能性と同一である。
【００５７】
図７は、サーバ６６が第１クライアント装置５０に位置される代わりに配信ネットワーク５２において位置される代わりの解決法の概略表現を与える。この実施例において、第１クライアント装置５０は、スライサ６４によって生成されるファイルをサーバ６６にアップロードし、サーバ６６は、ファイルの少なくとも１つを第２クライアント装置５４へ交代にダウンロードする。
【００５８】
通常、第１クライアント５０は、符号化されたマルチメディア・コンテンツ(例えば、第１クライアント装置５０によって保存されたビデオ)へのリンクを、第２クライアント装置５４へ例えばＳＭＳ(Short  Message  Service)を介して送信する。第２クライアントがＳＭＳに含まれるリンクをクリックすると、符号化されたマルチメディア・コンテンツへ向けられた初期リクエストが第１クライアント装置に送信される。第１クライアント装置５０は、この初期リクエストを受信すると、図１〜４を参照にして上述されるように動作する。
【００５９】
修正態様又は改善態様は、本発明の請求の範囲から逸脱することなく、上記のネットワークシステム、サーバ、システム、スライサ、クライアント装置及びダウンロード方法に関して提案され得る。したがって、本発明は、与えられる例に制限されない。
【００６０】
具体的に、Koninklijke  Philips  Electronics  N.V.によって2003年5月７日に出願された、欧州特許出願第03290453.4号において開示される「先行的ダウンロード(progressive  downloading)」概念は、本発明と組み合わせられ得る。スライサ６によって生成されるファイルが先行的にダウンロードされる場合、プレーヤ１６は、ファイルの再生を開始するために、ファイルが完全にダウンロードされるまで待つ必要がない。
【００６１】
明細書及び請求の範囲における「有する（comprising）」なる動詞の使用は、明細書及び請求項に記載される以外の要素又はステップの存在を排除しない。単数形の構成要素は、複数個の斯様な構成要素の存在を排除しない。
【図面の簡単な説明】
【００６２】
【図１】図１は、本発明に従うネットワークシステムの第１例の概略表現である。
【図２】図２は、本発明に従うスライサによって生成される複数のファイルの組の概略表現である。
【図３】図３は、２つの重なり合うファイルの概略表現である。
【図４】図４は、これらのファイルの組の概略表現である。
【図５】図５は、生放送マルチメディア・コンテンツをダウンロードする、本発明に従う方法のブロック図である。
【図６】図６は、本発明に従うネットワークシステムの他の例の概略的表現である。
【図７】図７は、本発明に従うネットワークシステムの更に他の例の概略的表現である。
【図１】
2007528044.tif 000003
【図２】
2007528044.tif 000004
【図３】
2007528044.tif 000005
【図４】
2007528044.tif 000006
【図５】
2007528044.tif 000007
【図６】
2007528044.tif 000008
【図７】
2007528044.tif 000009
【国際調査報告】
2007528044.tif 000010
2007528044.tif 000011