(57)【要約】本発明は、サーバーからクライアント装置にマルチメディアコンテンツをクライアントデバイスの要求に際して送信する方法を提案する。本方法は、ネットワーク送信レートおよび／または単数または複数のクライアント好み設定に基づいて、マルチメディアコンテンツをエンコードするために使われるエンコーダの特性を適応させることを可能にする。本発明の方法は、コンテンツをさまざまなエンコーダ特性を用いてエンコードしてそれによりいくつかのエンコードされたマルチメディアコンテンツを提供し、エンコードされたマルチメディアコンテンツをスライスしてそれにより複数のファイルベースのコンテンツを提供し、コンテンツを１ファイルずつダウンロードし、一つのエンコードされたマルチメディアコンテンツから別のものに切り換えることによってエンコード特性を変更し、それによりネットワーク送信レートおよび／またはクライアント好み設定に適応することを含む。
2007520109.tif 000002
【特許請求の範囲】
【請求項１】
サーバーからクライアント装置に配送ネットワークを通じてマルチメディアコンテンツを前記クライアントデバイスの要求に際して送信する方法であって、
当該方法は少なくとも一セットのファイルからなるグループを複数使用し、各グループは一つのエンコードされたマルチメディアコンテンツに関連付けられており、エンコードされたマルチメディアコンテンツは前記マルチメディアコンテンツをさまざまなエンコーダ特性を用いてエンコードすることによって得られるものであり、前記グループは前記エンコードされたマルチメディアコンテンツを互いに独立にデコードできる諸スライスを形成する少なくとも一セットのスライス位置においてスライスすることにより得られるものであり、各ファイルはエンコードされたマルチメディアコンテンツの一つのスライスを含んでおり、
当該方法は：
・前記複数のグループからグループを選択するステップと、
・スライスを選択するステップと、
・前記サーバーから前記クライアント装置に、前記選択されたスライスを含み、前記選択されたグループに属するファイルをダウンロードするステップ、
とを有しており、前記諸ステップが少なくとも一回実行されることを特徴とする方法。
【請求項２】
配送ネットワークの現在の送信レートの推定を計算するステップをさらに有しており、前記グループ選択ステップが前記推定を考慮に入れることを特徴とする、請求項１記載の方法。
【請求項３】
前記エンコーダ特性に関するクライアント好み設定を前記クライアント装置から前記サーバーに送信するステップをさらに有し、前記グループ選択ステップが前記クライアント好み設定を考慮に入れることを特徴とする、請求項１または２記載の方法。
【請求項４】
・マルチメディアコンテンツをエンコードしてそれにより複数のエンコードされたマルチメディアコンテンツを生成するための、さまざまなエンコーダ特性をもつ複数のエンコーダと、
・前記エンコードされたマルチメディアコンテンツを、互いに独立にデコードできる諸スライスを形成するスライス位置の少なくとも一つのセットにおいてスライスするための、そしてエンコードされたマルチメディアコンテンツの各スライスをファイルに納め、それにより少なくとも一セットのファイルからなるグループを複数個、各グループが一つのエンコードされたマルチメディアコンテンツに関連付けられるように生成するための複数のスライサー、
とを有することを特徴とするエンコード・システム。
【請求項５】
少なくとも一セットのファイルからなるグループ複数個へのアクセスを有するサーバーであって、各グループは一つのエンコードされたマルチメディアコンテンツに関連付けられており、エンコードされたマルチメディアコンテンツはマルチメディアコンテンツをさまざまなエンコーダ特性を用いてエンコードすることによって得られるものであり、前記グループは前記エンコードされたマルチメディアコンテンツを互いに独立にデコードできる諸スライスを形成する少なくとも一セットのスライス位置においてスライスすることにより得られるものであり、各ファイルはエンコードされたマルチメディアコンテンツの一つのスライスを含んでおり、当該サーバーは：
・スライスを選択する手段と、
・前記選択されたスライスを含み、ある選択されたグループに属するファイルをダウンロードさせる手段、
とを有しており、前記諸手段が前記クライアント装置から前記マルチメディアコンテンツに向けられた要求の受信に際して少なくとも一回作動されることを特徴とするサーバー。
【請求項６】
配送ネットワークの現在の送信レートに関する情報を前記クライアント装置から受信する手段と、前記情報に基づいて前記グループを選択するためのグループ選択手段とをさらに有することを特徴とする、請求項５記載のサーバー。
【請求項７】
クライアント好み設定データを受信するための手段と、前記クライアント好み設定データに基づいて前記グループを選択するためのグループ選択手段をさらに有することを特徴とする、請求項５記載のサーバー。
【請求項８】
・配送ネットワークを通じてサーバーに接続する手段と、
・複数のグループから少なくとも一セットのファイルのグループを選択する手段であって、各グループは一つのエンコードされたマルチメディアコンテンツに関連付けられており、エンコードされたマルチメディアコンテンツはマルチメディアコンテンツをさまざまなエンコーダ特性を用いてエンコードすることによって得られるものであり、前記グループは前記エンコードされたマルチメディアコンテンツを互いに独立にデコードできる諸スライスを形成する少なくとも一セットのスライス位置においてスライスすることにより得られるものであり、各ファイルはエンコードされたマルチメディアコンテンツの一つのスライスを含んでいるような手段と、
・前記マルチメディアコンテンツに向けられ、前記選択されたグループの指標を含む少なくとも一つの要求を前記サーバーに送る手段、
とを有することを特徴とするクライアント装置。
【請求項９】
前記配送ネットワークの現在の送信レートの推定を計算する手段をさらに有しており、前記グループ選択手段が前記推定を考慮に入れることを特徴とする、請求項８記載のクライアント装置。
【請求項１０】
クライアント好み設定を得るための手段をさらに有しており、前記グループ選択手段が前記クライアント好み設定を考慮に入れることを特徴とする、請求項８または９記載のクライアント装置。
【請求項１１】
・さまざまなエンコーダ特性をもつ複数のエンコーダであって、マルチメディアコンテンツをエンコードし、それにより複数のエンコードされたマルチメディアコンテンツを生成するエンコーダと、
・前記エンコードされたマルチメディアコンテンツを互いに独立にデコードできる諸スライスを形成するスライス位置の少なくとも一つのセットにおいてスライスするための、そしてエンコードされたマルチメディアコンテンツの各スライスをファイルに納め、それにより少なくとも一セットのファイルからなる複数のグループを各グループが一つのエンコードされたマルチメディアコンテンツに関連付けられるように生成するための複数のスライサーと、
・配送ネットワークと、
・前記配送ネットワークを通じてサーバーに接続する手段および前記マルチメディアコンテンツに向けられた少なくとも一つの要求を前記サーバーに送る手段をもつクライアント装置と、
・前記複数のグループへのアクセスを有し：
ａ）スライスを選択する手段、および
ｂ）前記選択されたスライスを含み、ある選択されたグループに属するファイルをダウンロードさせる手段、を有するサーバー、
とを有しており、前記手段が前記クライアント装置から前記マルチメディアコンテンツに向けられた要求が受信されると少なくとも一回作動されることを特徴とする、ネットワークシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバーからクライアント装置への配送ネットワークを通じたマルチメディアコンテンツの送信方法に関する。本発明はまた、サーバー、クライアント装置、マルチメディアコンテンツをエンコードするためのエンコーダを有するエンコード・システム、ならびにエンコーダ・システム、サーバー、配送ネットワークおよびクライアント装置を有するネットワークシステムにも関する。
【０００２】
本発明は、一般にウェブを通じたマルチメディアコンテンツ送信の分野において適用可能である。
【背景技術】
【０００３】
コーニンクレッカ・フィリップス・エレクトロニクス・N・Vによって出願された国際特許出願WO03/098935は、オーディオ／ビデオ・ストリーミング・アプリケーションにおいてクライアント装置に供給されるストリームの品質を適応させる方法を記載している。その目的は、ストリームの品質を適応させることによって、該ストリームの送信に必要とされる帯域幅が利用可能な帯域幅に合うようにすることである。これを達成するための一つの解決策は、さまざまなエンコード・ビットレートに対応する複数の事前エンコードされたストリームの間で切り換えを行うことである。
【０００４】
この解決策の一つの問題は、変更されるエンコーダ・パラメータがエンコード・ビットレートだけであることである。その理由は、画像サイズのようなその他のエンコーダ・パラメータがストリーミング・セッションの間、変更できないということである（その他のエンコーダ・パラメータが変更されたらクライアント側のデコーダがストリームをデコードできなくなる）。その他のエンコーダ・パラメータを適応させることができないことの帰結は、エンコード・ビットレートの変化の範囲が限られるということである（ビットレートをある限界値よりさらに下げることは、画像サイズの縮小などといったその他のエンコーダ・パラメータを適応させることなしにはできない）。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
クライアント装置にマルチメディアコンテンツを送信するための、上述した欠点のない解決策を提案することが本発明の目的の一つである。
【課題を解決するための手段】
【０００６】
本発明に基づく、マルチメディアコンテンツをクライアント装置に送信するための方法は、請求項において定義されている。本発明に基づく、マルチメディアコンテンツをエンコードするための方法も請求項において定義されている。本発明に基づく、マルチメディアコンテンツをクライアント装置に送信するためのサーバーも請求項において定義されている。本発明に基づくクライアント装置も請求項において定義されており、本発明に基づくネットワークシステムも請求項において定義されている。
【０００７】
本発明によれば、マルチメディアコンテンツはさまざまなエンコーダ特性を使ってエンコードされ、それにより複数のエンコードされたマルチメディアコンテンツが生成される。エンコードされたマルチメディアコンテンツは、互いに独立にデコードできる諸スライスを形成するスライス位置の少なくとも一つのセットにおいてスライスすることによって、ファイルベースのコンテンツに変換される。エンコードされたマルチメディアコンテンツの各スライスは一つのファイル内に納められ、それにより少なくとも一セットのファイルからなるグループが複数生成される。各グループが異なるエンコーダ特性に関連付けられる。
【０００８】
クライアント装置によるマルチメディアコンテンツの要求に際して、サーバーは前記マルチメディアコンテンツを１ファイルずつダウンロードさせる。ダウンロードされるべきファイルの選択は、スライスの選択およびグループの選択を含む。送信されるデータの特性の修正は、第一のエンコーダ特性に関連付けられた一つのグループから、第二のエンコーダ特性に関連付けられた別のグループに切り換えることによって達成される。
【０００９】
マルチメディアコンテンツの送信はファイルのダウンロードに基づいているので、エンコーダ特性はエンコード・ビットレート以外のエンコーダ・パラメータにも関わりうる。たとえばエンコード・ビットレートに加えて画像サイズである。もう一つの例では、異なるエンコード・フォーマットを使ったエンコーダが使用されて、それにより一つのグループから別のグループへの切り換えがエンコード・フォーマットの変更をも許容するようになる（たとえば、たいていのコーデック・フォーマットは好ましい動作ビットレートを有するので、より遅いビットレートの第一のエンコード・フォーマットとより高いビットレートを有する第二のエンコード・フォーマットとを使用することがより有益でありうる）。
【００１０】
どのグループに属するファイルがダウンロードされるかはサーバーが選択することも、クライアント装置が選択することもできる。それは配送ネットワークの現在の送信レートの推定および／またはエンコーダ特性に関するクライアントの好み設定に基づく。たとえば、クライアントが自分が受信したいビットレートおよび／または画像サイズを選んでもよい（たとえば、コスト上の理由から低画質を好み、よって小さい画像サイズおよび／または低いビットレートを選ぶこともありうる）。クライアントはまた、送信の間にクライアントの好み設定を変更してもよい（たとえば、データの一部を受信したのち、コンテンツは非常に興味深いものであり、より高品質で入手したいと判断することがありうる）。
【００１１】
本発明では、スライスは互いに独立してデコードできる。これは、クライアントがマルチメディアコンテンツを最初から受信する必要はないということを意味している。どのスライスから開始してもいい。したがって、本発明は、ライブコンテンツ（つまり、ライブイベント、放送番組などといったサーバー側でリアルタイムに利用可能なコンテンツ）を含むいかなる型のコンテンツの送信にも適用可能である。
【００１２】
マルチメディアコンテンツがライブコンテンツであるとき、クライアントが最初のファイルを受信するまでに経験する遅延を減らすために、いくつかのスライス位置セットが有利に使用される。複数のスライス位置セットが使用されるときには、エンコードされる各マルチメディアコンテンツに対してファイルの複数のセットからなるグループが利用可能である。
【００１３】
本発明では、少なくとも一つのファイルのシーケンスがクライアント装置による要求に際してダウンロードされる。ファイルは１回のクライアント要求の受信で一つずつ送られることもできるし、あるいはクライアント装置が一つずつ取得することもできる。実際上は、すべてのクライアントブラウザーが１回の要求への応答で複数のファイルを受信することをサポートしているかどうかは定かではない。したがって、通例はクライアント装置がファイルを一つずつ取得する（すなわち、ダウンロードされるべきファイルごとに取得要求を送る）ほうが好ましい。クライアント装置は、自動的に取得要求を送るよう設計できる。有利には、クライアント装置が取得要求を自動的に送るよう設計されていないときは、そのクライアント装置からの最初の要求の受信に際して、サーバーが、そのクライアント装置に取得要求を反復的に送るようにさせる文書を送る。
【発明の効果】
【００１４】
ファイルのダウンロードは通例HTTPプロトコルを使うことによってIPネットワーク上で実装されることを注意しておく（HTTPはHyper  Text  Transfer  Protocol［ハイパーテキスト転送プロトコル］の略で、IETFのRFC2616で定義されている）。HTTPプロトコルはウェブの基礎であり、よってあらゆるファイアウォールによって受け入れられる。ストリーミング・アプリケーションにおいて一般に使われるUDPプロトコルについてはそうではない（UDPはUser  Datagram  Protocol［ユーザー・データグラム・プロトコル］の略で、IETFのRFC768において定義されている）。結果として、本発明において提案される解決策は、いかなるクライアント装置でも、配送ネットワークに接続するのに通るファイアウォールの特性に関わりなく要求したコンテンツを受信できるという、従来技術に対する大きな利点を有している。
【００１５】
これらのことを含む本発明のさまざまな側面について、以下で図面を参照しつつさらに述べる。
【発明を実施するための最良の形態】
【００１６】
図１は、本発明に基づくネットワークシステムの概略図である。図１のネットワークシステムは：
・マルチメディアコンテンツを取得するためのソース１と、
・前記マルチメディアコンテンツを放送するための放送者２と、
・放送されたマルチメディアコンテンツを受信するための受信機３と、
・受信されたマルチメディアコンテンツをエンコードし、少なくとも一セットのファイルからなる諸グループを生成するためのエンコード・システム４と、
・前記ファイルのグループへのアクセスを有するサーバー８と、
・前記サーバー８がリンクされている配送ネットワーク１０と、
・配送ネットワーク１０へのアクセスをクライアント装置１４に提供するためのアクセス・プロバイダー１２、
とを有する。
【００１７】
サーバー８は通信ユニット８ａおよび処理ユニット８ｂを有し、該処理ユニットはデータメモリ、プログラムメモリおよび前記プログラムメモリ内に保存された命令を実行するためのプロセッサを有している。
【００１８】
クライアント装置１４は、アクセス・プロバイダー１２との間の送受信のための通信ユニット１５、エンコードされたマルチメディアコンテンツを再生するためのプレーヤー１６、マルチメディアコンテンツを表示するためのディスプレイ１７ならびにプログラムメモリ、データメモリおよび前記プログラムメモリ内に保存されている命令を実行するためのプロセッサを有する処理ユニット１８を有する。クライアント装置１４は、前記通信ユニット１５が無線通信ユニットである移動体装置（携帯電話のような）であってもよいし、あるいは前記通信ユニット１５が有線通信ユニットである有線装置（パソコンのような）であってもよい。配送ネットワーク１０は典型的にはインターネットのネットワークである。
【００１９】
たとえば、放送者２は衛星放送ネットワークであり、受信機３は衛星受信機である。これは制約ではない：衛星放送手段の代わりに他のいかなる放送手段を使用してもよい。放送マルチメディアコンテンツは、送信され、受信機３を含むいくつかの受信機によって受信されることのできるいかなるマルチメディアコンテンツであってもよい。たとえば、放送マルチメディアコンテンツはテレビ番組、事前に録画されたイベント／番組、ライブイベントなどでありうる。
【００２０】
エンコード・システムは：
ａ）受信されたマルチメディアコンテンツをエンコードしてそれにより複数のエンコードされたマルチメディアコンテンツEC_1からEC_Nを生成するための、さまざまな特性を有するN個のエンコーダ５_1から５_Nと、
ｂ）前記エンコードされたマルチメディアコンテンツを、互いに独立にデコードできる諸スライスを形成するスライス位置の少なくとも一つのセットにおいてスライスするための、そしてエンコードされたマルチメディアコンテンツの各スライスをファイルに納め、それにより少なくとも一セットのファイルからなるN個のグループG_1からG_Nを各グループが一つのエンコードされたマルチメディアコンテンツに関連付けられるように生成するためのN個のスライサー６_1から６_N、
とを有する。
【００２１】
たとえば、エンコーダ５_1から５_NはMPEG規格またはH263規格のうちの一つに準拠する。
【００２２】
エンコーダ５_1から５_Nとスライサー６_1から６_Nは、単一の装置中に実装されても別個の装置に実装されてもよい。いずれの場合でも、エンコーダ５_iからスライサー６_iに送信されるのは、エンコードされたストリームである（iは1とNとの間の整数）。有利には、エンコードされたストリームはエンコーダ５_iからスライサー６_iにIPを通じて、RTPプロトコルを使うことによって送信される（RTPはReal-time  Transport  Protocol［リアルタイム転送プロトコル］の略で、IETFのRFC1889で定義されている）。これは制約ではない。たとえば、MPEG-2  TSとして知られるMPEG-2規格のトランスポート層を使ってもよい。
【００２３】
スライサー６_1から６_Nの機能は、エンコーダ５_1から５_Nによって生成されたエンコードされたマルチメディアコンテンツを、少なくとも一セットのスライス位置でスライスすることである。スライス位置は、それぞれがエンコードされたマルチメディアコンテンツの所与の長さの時間を含み、互いに独立にデコードできるような諸スライスを定義するものである。実際上は、マルチメディア・エンコーダによって生成されたいかなるエンコードされたマルチメディアコンテンツも、いわゆるランダムアクセス点（RAP:  Random  Access  Points）を含んでいる。互いに独立してデコードできるスライスを生成するためには、スライス位置は、各スライスがランダムアクセス点で始まるように選ばれる。たとえば、エンコーダがMPEG-2またはMPEG-4規格に準拠している場合は、ランダムアクセス点はMPEGエンコードされたマルチメディアコンテンツのIフレームであり、スライス位置は各スライスの最初のフレームがIフレームとなるよう選ばれる。
【００２４】
有利には、スライスのサイズは調整可能である。スライスのサイズはすべてのスライスについて同一でもよいし、あるいはスライスごとに変わってもよい（たとえば、スライスのサイズが時間とともに増大してもよい）。最良の効率が得られるのは比較的長いファイルについてである。というのも、転送されるべきファイルが多いほどファイルヘッダに起因するオーバーヘッドが大きくなるからである。
【００２５】
図２は、エンコードされたマルチメディアコンテンツEC_1からEC_Nをスライスするために使用されるスライス方式の概略図である。図２に表されているスライス方式はPセットのスライス位置ST1,  ...,  STPを含んでいる。スライス位置の各セットSTmはQ−1個のスライス位置Tm,1,  ...,  Tm,Q-1を含んでいる。各セットのスライス位置は他のセットのスライス位置に比較して時間的にずれている（t軸が時間軸である）。このスライス方式では、スライス位置STmの各セットについてQ個のスライスLm,1,...,Lm,Qが形成される。以下の記述から明らかになるように、スライス位置のセットを複数使うことは、ライブ・マルチメディアコンテンツを送信するときに有利である。というのも、ライブコンテンツについての要求を送るときにクライアントが経験する遅延を減らすことを許容するからである。
【００２６】
スライサー６_1から６_Nは各エンコードされたマルチメディアコンテンツを少なくとも一セットのスライス位置でスライスすることによって、少なくとも一セットのファイルからなるグループを複数生成する。図３は、図２に記載されたスライス方式を使うことによってエンコードされたマルチメディアコンテンツEC_iから生成されたファイルのグループG_iの概略図である。図３に示されるように、グループG_iはPセットのファイルS1_i,  S2_i  ,...,  SP_iを含んでいる。それぞれのファイルのセットSm_i（m＝1,  ...,  P）はQ個のファイルFm,k_i（m＝1,  ...,  P;  k＝1,  ...,  Q）を有する。スライス位置STmのセットはファイルのセットSm_iにそれぞれ対応する。ファイルFm+1,k_iおよびFm,k_iは重なっている（エンコードされたデータが同一である）。図４では、Fm+1,k_iおよびFm,k_iの間の重なりが矢印Om+1によって示されている。
【００２７】
スライサー６_1から６_Nによって生成された各ファイルは、サーバー８がアクセスを有する記憶ユニット２０に保存される。記憶ユニット２０はスライサー６_1から６_Nおよびサーバー８によって共有されている。記憶ユニット２０はサーバー設備の一部であってもよいし、あるいはリモート位置にあってもよい。記憶ユニット２０は新たに生成されたファイルを保存するための余地が利用できるよう規則的に「クリーニング」されなければならない。記憶ユニットをクリーニングする一つの方法は、ファイル名を規則的に再利用することである。代替的な方法は、各ファイルについて異なるファイル名を使い、規則的に古くなったファイルを削除することである。
【００２８】
サーバー８は配送ネットワーク１０にリンクされている。クライアント装置１４はアクセス・プロバイダー１２を通じて配送ネットワーク１０にアクセスを有する。典型的には、クライアント装置１４は配送ネットワーク１０からページをロードできる。該ページは、サーバー８が送信のために提供するマルチメディアコンテンツへの少なくとも一つのリンクを含んでいる。ユーザーが前記リンクをクリックすると、前記マルチメディアコンテンツに向けられた初期要求（request）R0が自動的にサーバー８に送られる。サーバー８が初期要求R0を処理するにはいくつかの可能な方法がある。
【００２９】
第一の実施形態では、サーバー８はクライアント要求に応答して単一のファイルをダウンロードする。この実装は、たとえばクライアントにライブイベントに関する情報を拾い上げることを提供するアプリケーションなどの特定のアプリケーションのために使用されることができる。クライアント装置１４に初期要求R0を反復的に送るようにさせるよう明示的に設計されたプレーヤー１６とともに使用されることもできる。
【００３０】
第二の実施形態では、サーバー８は、サーバー側で用意ができ次第、ファイルを一つずつダウンロードさせる。この実施形態は実装が容易であるという利点がある。しかし、ある種のクライアントブラウザーは１回の要求に応答して複数のファイルを受信することをサポートしていない危険性がある。
【００３１】
第三の実施形態では（通例これが好ましい）、サーバー８は初期要求R0の受信に際してクライアント装置１４に文書を送る。この文書は、クライアント装置１４にマルチメディアコンテンツを指定する取得要求を反復的に送るようにさせる。
【００３２】
例として、サーバー８によって送られる文書は、自動更新コマンドを含むページでありうる。そのようなページの例を次に挙げる。
【００３３】
【表１】
2007520109.tif 000003
このようなページはクライアントブラウザーに134秒ごとにファイルlive2download.mp4を再ロードするようにさせる（134秒というのはこの例でのファイルの継続時間である）。
【００３４】
あるいはまた、サーバー８によって送られる文書は、プレーヤー１６によって標準的な仕方で処理されることが意図された、マルチメディアコンテンツの標準的な記述であってもよい。たとえば、そのような記述はSMIL記述であってもよい（SMILはXMLベースのオーディオ／ビデオシーン記述を定義するW3C規格である）。そのようなSMIL記述の例を次に挙げる。
【００３５】
【表２】
2007520109.tif 000004
このSMIL文書の効果は、プレーヤー１６がファイルlive2download.mp4を反復的に再生するようにすることである。結果として、クライアント装置は反復的にファイルlive2download.mp4に向けられた取得要求を送ることになる。
【００３６】
有利には、サーバー８によって送られるSMIL文書は、少し早めに（すなわち、直前のファイルの再生の終わりより少し前に）ファイルを取得する必要があることを示すコマンドを含む。これにより、次のファイルがクライアント装置１４に時間内に届くことが保証され、クライアントがマルチメディアコンテンツの表現における空隙を経験することがなくなる。そのようなコマンドを有するSMIL記述の例を次に挙げる。
【００３７】
【表３】
2007520109.tif 000005
この文書は、30sのコンテンツを含むスライスについて書かれている。これはプレーヤーが次の動作を順に実行するようにする：
ａ）第一のソース（live2download1.mp4）の最初の25sを再生する、
ｂ）第一のソースの最後の5sを再生し、並行して第二のソース（live2download2.mp4）の最初の5sを取得する、
ｃ）第二のソースの最初の25sを再生する（最初の5sがあらかじめ取得されているので遅延なくできる）。
二つの異なるソースを使うのは実装上の技巧である。サーバー８は第一および第二のソースが同じマルチメディアコンテンツに対応していることを認識するよう設計されなければならない。
【００３８】
上記の３つの実施形態では、サーバーは初期要求R0の受信に際して、あるいは取得要求の受信に際して、どのファイルがダウンロードされるべきかを決定する必要がある。本発明によれば、ダウンロードされるべきファイルは、スライスを選択することによって、およびファイルのグループを選択することによって決定される（スライスLm,kおよびグループG_iの選択がファイルFm,k_iのダウンロードにつながる）。
【００３９】
有利には、グループの選択は、配送ネットワーク１０の現在の送信レートおよび／またはエンコーダ特性に関するクライアントの好み設定を考慮に入れて行われる（前記クライアントの好み設定は時間によって変わりうる）。第一のエンコーダ特性に関連付けられた一つのグループから第二のエンコーダ特性に関連付けられた別のグループへの切り換えは、クライアント装置から受信される、配送ネットワーク１０の現在の送信レートおよび／またはクライアントの好み設定への適応を許容する。
【００４０】
第一の実施例では、前記グループの選択は、サーバー側で、クライアント装置によって送信される情報に基づいて行われる。送信される情報は、配送ネットワーク１０の現在の送信レートか、あるいはサーバー８が配送ネットワーク１０の現在の送信レートを計算するために使用するトラフィック情報である。代替的または追加的に、送信される情報は、所望のビットレートおよび／または画像サイズおよび／またはコーデックといったクライアントの好み設定を含んでいてもよい。
【００４１】
第二の実施例では、前記グループの選択はクライアント装置１４によって行われ、選択されたグループの指標がサーバー８に送られる。
【００４２】
クライアント装置１４からサーバー８に送信される情報および／または指標はたとえば単数または複数の初期要求および／または取得要求中で送信される。あるいはまた、クライアント装置１４とサーバー８との間に確立される別個の制御チャネルで送信される。あるいはまた、選択されたグループは、送信されるべきマルチメディアコンテンツを指定するときに特定の命名規約を使ってサーバー８に示されることもできる（この場合、送信されるべきマルチメディアコンテンツの名前がどのグループが使われるべきかを示す）。
【００４３】
たとえば、転送プロトコルがHTTPであるとき、上述の情報および／または指標を送信するために使われるべきものとして特定のパラメータをインターネット番号割当機関（IANA:  Internet  Assigned  Numbers  Authority）に登録することが可能である。
【００４４】
スライスの選択はサーバー８によって、送信されるマルチメディアコンテンツの連続性を保証するよう（つまり、直前の選択されたスライスがLx,k（x∈｛1,  ...,  P｝）であれば、次に選択されるスライスはLy,k+1（y∈｛1,  ...,  P｝）になる）行われる。スライス位置のセットがいくつか使用されている場合（P＞1）、ライブコンテンツに向けられる初期要求の受信に際して、サーバー８は、該初期要求の到着時刻と比較して、最も最近のスライスか最も近い未来のスライスを選択できる。最も最近のスライスを選択することの帰結は、クライアントは古くなったデータを受信するということである。最も近い未来のスライスを選択することの帰結は、クライアントは応答を得るまで一定の時間待たなければならないということである。いずれの場合にも、クライアントにとっての不都合は複数のファイルセットが使用される場合には軽減される。このことが図５で図解されている。
【００４５】
図５は、３つのファイルセットS1_i,  S2_i,  S3_iからなるグループG_iを示している。矢印Aはサーバー８による要求の受信を示している。スライサー６_iによって生成されるセットが第一のセットS1_iだけである場合には、サーバー８はファイルF1,1_i（最も最近のファイル）またはファイルF1,2_i（最も近い未来のファイル）をダウンロードさせる。サーバー８がファイルF1,1_iをダウンロードさせる場合、クライアントが受信するデータはa1,1に等しい時間だけ遅れることになる。サーバーがファイルF1,2_iをダウンロードさせる場合、クライアントはデータを受信するまでにb1,2に等しい遅延を経験することになる。
【００４６】
スライサー６によって生成されるセットがS1_i,  S2_i,  S3_iの３つである場合には、サーバー８はファイルF2,1_i（最も最近のファイル）またはファイルF3,2_i（最も近い未来のファイル）をダウンロードさせる。サーバー８がファイルF2,1_iをダウンロードさせる場合、クライアントが受信するデータはa2,1に等しい時間だけ遅れることになる。サーバーがファイルF3,2_iをダウンロードさせる場合、クライアントはデータを受信するまでにb3,2に等しい遅延を経験することになる。a1,1＞a2,1およびb1,2＞b3,2であることが見て取れる。
【００４７】
HTTPは無状態プロトコルであり、よって同じクライアント装置によって発されるHTTP要求でも通常は互いに独立に処理される。結果として、配送ネットワーク１０を通じた送信がHTTPプロトコルによって支配されているときは、コンテンツの再生がスムーズに達成できない危険性がある（コンテンツの一部が何度か受信されたり、コンテンツの一部が欠けたりすることがありうる）。この問題を解決する第四の実施形態についてこれから述べる。
【００４８】
この第四の実施形態では、初期要求R0に応答してサーバー８によって送られる文書は、クライアントによって求められたマルチメディアコンテンツを指定するリソース識別子を含んでいる。このリソース識別子はクライアント装置１４に固有のものである。サーバー８によって送られる文書はクライアント装置１４がこのリソース識別子を含んだ取得要求を反復的に送るようにさせる。最初の取得要求の受信に際して、サーバー８は上記のようにしてダウンロードされるべきファイルを決定する（サーバーによるスライス選択およびサーバーまたはクライアント装置によるグループ選択）。サーバー８はそのファイルをダウンロードさせ、ダウンロードされたスライスの記録をとる。同じリソース識別子を含むその後の取得要求を受信した際には、サーバー８はその記録を調べて使用されるべき次のスライスを選択し、適切なファイルをダウンロードさせ、記録を更新する。
【００４９】
このようにして、各クライアント装置１４は完全でありかつ正しい順序のファイルのシーケンスを受信することになる（受信されるファイルはすべて同じファイルセットに属する連続したファイルである）。
【００５０】
例として、サーバー８によって送られる文書中に含まれるリソース識別子は、IETFのRFC1510で定義される「ノンス」であってもよい（ノンスとは一度した使われない数である）。そのようなリソース識別子を含むSMIL文書の例を次に挙げる。
【００５１】
【表４】
2007520109.tif 000006
ここで、リソース識別子はcnn142299293873635534291919である。クライアント装置１４はファイルcnn142299293873635534291919.mp4に対する取得要求を反復的に送る。サーバー８リソース識別子cnn142299293873635534291919についてどのファイルがダウンロードされたか（またはダウンロードされるべきか）を常時追跡する。
【００５２】
以上で議論してきたステップは図６にまとめられている。図６に示されるように、マルチメディアコンテンツを送信するための本発明に基づく方法は：
・複数のグループ（i＝1,  ...,  N）からグループG_iを選択するステップX1と、
・スライスSm,k（m＝1,  ...,  Pおよびk＝1,  ...,  Q）を選択するステップX2と、
・前記サーバーから前記クライアント装置に、選択されたスライスを含み、選択されたグループに属するファイルFm,k_iをダウンロードするステップ、
とを有する。
【００５３】
矢印Wは、ファイルのあるシーケンスの送信のためにステップX1からX3が何度か実行されることを示している。
【００５４】
ステップX1はクライアント装置１４またはサーバー８によって実行される。ステップX2およびX3はサーバー８によって実行される。
【００５５】
これらのステップは、サーバー８および／またはクライアント装置１４に含まれる特定のハードウェアおよび／またはソフトウェアによって実装される。
【実施例】
【００５６】
本発明に基づくネットワークシステムのもう二つの例について図７および図８を参照しつつ述べる。
【００５７】
図７のネットワークシステムは第一のクライアント装置５０、配送ネットワーク５２、第二のクライアント装置５４ならびに第一および第二のクライアント装置５０および５４に配送ネットワーク５２へのアクセスを提供するための少なくとも一つのアクセス・プロバイダー５６を有している。
【００５８】
第二のクライアント装置５４は図１を参照しつつ述べたクライアント装置１４と同様である。典型的には配送ネットワーク５２はインターネットのネットワークである。
【００５９】
第一のクライアント装置５０は：
・マルチメディアコンテンツを取得するためのソース６０と、
・取得されたマルチメディアコンテンツをさまざまなエンコーダ特性を用いてエンコードするための、そしてエンコードされたマルチメディアコンテンツをスライスするためのエンコード・システム６２と、
・エンコード・システム６２によって生成されたファイルへのアクセスを有するサーバー６６と、
・アクセス・プロバイダー５６との間の送受信のための通信ユニット６８、
とを有する。
【００６０】
典型的には、第一のクライアント装置は携帯電話である。これは、通信ユニット６８は無線通信ユニットであることを意味する。
【００６１】
ソース６０、エンコード・システム６２およびサーバー６６の機能は、図１から図６を参照しつつ述べたソース１、エンコード・システム４およびサーバー８の機能と同一である。
【００６２】
図８は、代替的な解決策の概略図である。ここではサーバー６６は第一のクライアント装置５０内に位置する代わりに配送ネットワーク５２内に位置している。この実施形態では、第一のクライアント装置５０はエンコード・システム６２によって生成されたファイルをサーバー６６にアップロードし、サーバー６６は今度はその単数または複数のファイルを第二のクライアント装置５４にダウンロードさせる。
【００６３】
典型的には、第一のクライアント５０はあるマルチメディアコンテンツ（たとえば第一のクライアント装置５０によって取り込まれているビデオ）に対するリンクを第二のクライアント装置５４に、たとえばSMS（Short  Message  Service［ショート・メッセージ・サービス］）を使って送る。第二のクライアントがSMSに含まれるそのリンクをクリックすると、前記マルチメディアコンテンツに向けられた初期要求が第一のクライアント装置５０に送られる。この初期要求の受信に際して、第一のクライアント装置５０は図１から図５を参照しつつ先に述べたようにして動作する。
【００６４】
記載されたネットワークシステム、サーバー、エンコード・システム、クライアント装置および送信方法に関し、本発明の範囲から外れることなく修正または改良が提案されることもありうる。よって、本発明はここに記載した例に限定されるものではない。
【００６５】
特に、コーニンクレッカ・フィリップス・エレクトロニクス・N・Vによって2003年5月7日に出願された欧州特許出願第03290453.4号において開示されている「漸進ダウンロード（progressive  downloading）」の概念が本発明と組み合わせることができる。スライサー６_iによって生成されたファイルが漸進的にダウンロードされるとき、プレーヤー１６はそのファイルが完全にダウンロードされるまでそのファイルの再生開始を待つ必要はない。
【００６６】
明細書および請求項における動詞「有する」およびその活用形の使用は、当該明細書および請求項において述べられているもの以外の要素の存在を排除するものではない。要素を指示する単数形の表現はそのような要素の複数の存在を排除するものではない。
【図面の簡単な説明】
【００６７】
【図１】本発明に基づくネットワークシステムの第一の例の概略図である。
【図２】本発明に基づくエンコードされたマルチメディアコンテンツをスライスするために使われるスライス方式の概略図である。
【図３】図２に描かれたスライス方式を使って生成される複数のファイルセットからなるグループの概略図である。
【図４】二つの重なり合うファイルの概略図である。
【図５】３セットのファイルからなるグループの概略図である。
【図６】本発明に基づく、マルチメディアコンテンツを送信する方法のブロック図である。
【図７】本発明に基づくネットワークシステムの別の例の概略図である。
【図８】本発明に基づくネットワークシステムの別の例の概略図である。
【図１】
2007520109.tif 000007
【図２】
2007520109.tif 000008
【図３】
2007520109.tif 000009
【図４】
2007520109.tif 000010
【図５】
2007520109.tif 000011
【図６】
2007520109.tif 000012
【図７】
2007520109.tif 000013
【図８】
2007520109.tif 000014
【国際調査報告】
2007520109.tif 000015
2007520109.tif 000016