(57)【要約】  本発明は、ファイル記述テーブル（ＦＤＴ）を受信するステップと、再送されるフラグメント（シンボル）と称する、正しく受信されなかったかまたは受信されなかったオブジェクトの少なくとも一部の送信を要求するステップ（３１４、３１６）であって、上記の送信要求は、再送される上記のフラグメントが属するオブジェクトの識別子（ＵＲＩ）と再送される前記フラグメントの識別子（「シンボル」）とを備えるステップ、を備えるデータ受信に関する。正しく受信されなかったオブジェクト（例えば、ファイル）の修復を最適化するため、送信要求はさらにオブジェクトのバージョンの識別子（ＴＯＩ）を含む。
2009533918.tif 000002
【特許請求の範囲】
【請求項１】
ファイル記述テーブル（「ＦＤＴ」）を受信するステップと、
再送されるフラグメント（「シンボル」）と称する、正しく受信されなかったかまたは受信されなかったオブジェクトの少なくとも一部の送信を要求するステップであって、前記送信要求は、再送される前記フラグメントが属するオブジェクトの識別子（「ＵＲＩ」）と再送される前記フラグメントの識別子（「シンボル」）とを備えるステップ
を備え、
前記送信要求はさらに、前記オブジェクトのバージョンの識別子（「ＴＯＩ」）を含むこと
を特徴とするデータ受信方法。
【請求項２】
前記オブジェクトはオーディオおよび／またはビデオデータを備えることを特徴とする請求項１に記載の方法。
【請求項３】
前記送信要求を修復サーバに送信したことを特徴とする請求項１および２の任意に記載の方法。
【請求項４】
前記送信要求をＨＴＴＰプロトコルに従って送信したことを特徴とする請求項１から３の任意に記載の方法。
【請求項５】
前記ファイル記述テーブルを地上波デジタルネットワーク上で送信したことを特徴とする請求項１から４の任意に記載の方法。
【請求項６】
前記オブジェクトのバージョンの前記識別子が曖昧である場合に、エラーメッセージを受信するステップを備えることを特徴とする請求項１から５の任意に記載の方法。
【請求項７】
再送されるフラグメント（「シンボル」）と称する、正しく受信されなかったかまたは受信されなかったオブジェクトの少なくとも一部の送信を要求するステップであって、前記送信要求は、再送される前記フラグメントが属するオブジェクトの識別子（「ＵＲＩ」）と再送される前記フラグメントの識別子（「シンボル」）とを備えるステップ
を備え、
前記オブジェクトのバージョンの識別子（「ＴＯＩ」）と再送される前記フラグメントの少なくとも一部とを含むメッセージの送信ステップを備えること
を特徴とするデータ修復方法。
【請求項８】
ファイル記述テーブル（「ＦＤＴ」）を受信する手段と、
再送されるフラグメント（「シンボル」）と称する、正しく受信されなかったかまたは受信されなかったオブジェクトの少なくとも一部の送信を要求する手段であって、前記送信要求は、再送される前記フラグメントが属するオブジェクトの識別子（「ＵＲＩ」）と再送される前記フラグメントの識別子（「シンボル」）とを備える手段
を備え、
前記オブジェクトのバージョンの識別子（「ＴＯＩ」）を前記送信要求に挿入する手段を備えること
を特徴とするデータ受信端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、地上波デジタルテレビまたはデジタルビデオブロードキャスト（ＤＶＢ）の領域に関する。より正確には、本発明はＤＶＢサービス、例えば携帯端末に関連するＤＶＢ−Ｈ（「ＤＶＢ  ハンドヘルド」）の送信および受信に関する。
【背景技術】
【０００２】
ＤＶＢは特に、「非特許文献１」および「非特許文献２」で定義されている。ＤＶＢ−Ｈは特に、「非特許文献３」および「非特許文献４」で規定されている。
【０００３】
先行技術によると、ＤＶＢ−Ｈテレビサービス（例えば、ライブテレビまたはファイルサーバまたはＶＯＤ（ビデオオンデマンド）サーバ）をストリーミングモードまたはファイルモードでダウンロードすることができる。ＦＬＵＴＥ（「Ｆｉｌｅ  Ｄｅｌｉｖｅｒｙ  ｏｖｅｒ  Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ  Ｔｒａｎｓｐｏｒｔ」）として知られているプロトコルは、「非特許文献５」で説明されている。本プロトコルは、ファイルおよび他の離散オブジェクトをセッション内で配信するために使用される。本プロトコルは特に、ＤＶＢ−Ｈ上でのファイル送信に使用される。ＦＬＵＴＥセッションでは、複数の転送オブジェクトを送信することができる。これらの転送オブジェクトは例えば、ファイルまたは「ファイル配信テーブル」（ＦＤＴ）を表す。それぞれのオブジェクトはそのＵＲＩにより識別され、そのバージョンはそのＴＯＩ（「Ｔｒａｎｓｐｏｒｔ  Ｏｂｊｅｃｔ  Ｉｄｅｎｔｉｆｉｅｒ」）により符号無し整数の形で識別される。値“０”はＦＤＴ向けに予約されており、他の値を他のオブジェクトに対して使用することができる。ファイルをディスパッチする前に、これらのファイルの説明がＦＬＵＴＥプロトコルに従いＦＤＴで送信される。それぞれのファイルに対し、ＦＤＴはその名前（ＵＲＩ）をＴＯＩ値と関連付ける。記述テーブルはＦＤＴインスタンスの形で送信される。そのＦＤＴインスタンスはＸＭＬの構造である。それぞれのＦＤＴインスタンスは、例えば送信ファイルのサブセットに関する情報のような、カレントＦＤＴの全部または一部を転送する。それぞれのＦＤＴインスタンスはＦＤＴインスタンス識別子を転送する。ＦＤＴインスタンス識別子は符号無しの２０ビットの数値である。これらの識別子はインクリメンタルであり、従って最近のインスタンスを、同一セッションの古いインスタンスから区別するために使用することができる。ＦＤＴインスタンスは１つまたは複数のファイルに関連付けられ、「有効期限」属性を含む。「有効期限」属性はＦＤＴインスタンスの期限切れ時刻を定義する。ここで、用語「ファイル」は、ＦＤＴインスタンスを除いて、ＦＬＵＴＥプロトコルに従って転送される任意のオブジェクトに対応する。ＦＬＵＴＥ仕様によると、受信機は受信したＦＤＴインスタンスを使用して、そのＦＤＴインスタンスの期限切れ時刻の後に受信したパケットを解釈してはならない。
【０００４】
図１は、ＤＶＢ−ＣＢＭＳ（「Ｃｏｎｖｅｒｇｅｎｃｅ  ｏｆ  Ｂｒｏａｄｃａｓｔ  ａｎｄ  Ｍｏｂｉｌｅ  Ｓｅｒｖｉｃｅｓ」）のコンテクスト（またはＤＶＢ−Ｈ上でのＩＰ（「Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ」）データの転送において指定したＤＶＢ：「ＩＰ  Ｄａｔａｃａｓｔ  ｏｖｅｒ  ＤＶＢ−Ｈ  ｐｒｏｔｏｃｏｌ：ＣＤＰ（Ｃｏｎｔｅｎｔ  Ｄｅｌｉｖｅｒｙ  Ｐｒｏｔｏｃｏｌｓ）」）におけるファイル配布サービスブロードキャストを概略的に示す。ファイルサーバ１００は第１のＦＤＴ１１０を送信する。第１のＦＤＴ１１０は、ＤＶＢ−Ｈネットワーク上のＦＬＵＴＥ  ｏｖｅｒ  ＩＰプロトコルにより端末１０１に送信される。第１のＦＤＴ１１０はＵＲＩ（「Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ」）を備える。ＵＲＩにより、送信されるファイル（より一般的にはオブジェクト）を識別することができる。端末は第１のＦＤＴを受信して、この第１のＦＤＴに従ってブロードキャストされるファイルの記述を記録する。ファイルサーバ１００は次いでデータを、ファイルの一部に対応する１つまたは複数のシンボルの形で、後続フレーム１１１から１１３の形式でＤＶＢ−Ｈネットワークを介して端末１０１に送信する。
【０００５】
【非特許文献１】ＥＴＳＩ  ＥＮ  ３０１  １９２標準（タイトルは「デジタルビデオブロードキャスティング（ＤＶＢ）、データブロードキャストに関するＤＶＢ仕様」）
【非特許文献２】ＴＲ  １０１  １９０（タイトルは「デジタルビデオブロードキャスティング（ＤＶＢ）、ＤＶＢ地上波サービスに関する実装ガイドライン、送信機構」）
【非特許文献３】ＥＴＳＩ  ＥＮ  ３０２  ３０４（タイトルは「デジタルビデオブロードキャスティング（ＤＶＢ）、ハンドヘルド端末に対する送信システム（ＤＶＢ−Ｈ）」）
【非特許文献４】ＴＲ  １０２  ３７７（タイトルは「デジタルビデオブロードキャスティング（ＤＶＢ）、ＤＶＢ−Ｈ実装ガイドライン」）
【非特許文献５】ＲＦＣ  ３９２６、ＦＬＵＴＥ−Ｆｉｌｅ  Ｄｅｌｉｖｅｒｙ  ｏｖｅｒ  Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ  Ｔｒａｎｓｐｏｒｔ（ｂｙ  Ｔ．Ｐａｉｌａ，Ｍ．Ｌｕｂｙ，Ｒ．Ｌｅｈｔｏｎｅｎ，Ｖ．Ｒｏｃａ，Ｒ．Ｗａｌｓｈ）
【発明の開示】
【発明が解決しようとする課題】
【０００６】
例として、ファイルサーバ１００が、端末１０１がメッセージ１１４を（例えば、インターネットチャネルのアップリンクを介して）ファイルサーバ１００に送信するのと同じ時間間隔で、同じＵＲＩを有する第２のＦＤＴ１２０を端末１０１に送信すると仮定する。別のシナリオによると、第２のＦＤＴ１２０が端末により受信されないかまたは正確に受信されない場合にメッセージ１１４が送信される（この結果、システムが誤動作する恐れがある）。メッセージ１１４は２つのＦＤＴに対応するＵＲＩと、再送されるフラグメントの識別子とを含む。メッセージ１１４により、端末１０１は、ＤＶＢ−Ｈを介してファイルサーバ１００から受信されなかったかまたは正確に受信されなかった１つまたは複数のシンボル（またはフラグメント）を要求することができる。第２のＦＤＴ１２０を端末１０１により受信する必要はない。第１のＦＤＴに関するメッセージ１１４を受信すると、サーバ１００はシンボルを備えるフレーム１２１を転送する。そのシンボルは、要求されたシンボルと同じ識別子を有するが、第２のＦＤＴと対応し、第１のＦＤＴとは対応しない。この技術の欠点は従って、誤ったシンボルの送信が発生し、その結果、端末が誤動作する恐れがあることである。
【課題を解決するための手段】
【０００７】
本発明の目的は、先行技術のこれらの欠点を克服することである。
【０００８】
より詳細には、本発明の目的は、受信者により受信されなかったかまたは正確に受信されなかったオブジェクト（例えば、イメージまたはファイルオブジェクト）の修復を改善することである。
【０００９】
この目的を達成するため、本発明は、
ファイル記述テーブルを受信するステップと、
再送されるフラグメントとも称するが、受信されなかったかまたは正確に受信されなかったオブジェクト（例えば、イメージまたはデータファイルオブジェクト）の少なくとも一部の送信を要求するステップであって、その送信要求は、再送されるフラグメントが属するオブジェクトの識別子と再送されるフラグメント（複数）の識別子とを備えるステップ
を備えるデータ受信方法を提示する。
【００１０】
完全または部分的に受信されなかったかまたは正確に受信されなかったオブジェクトの修復を改善するため、本発明によると、送信要求はとりわけオブジェクトバージョンの識別子を備える。
【００１１】
特定の特性によるとオブジェクトはオーディオおよび／またはビデオデータを備える。
【００１２】
送信要求を修復サーバに送信するとなお良い。
【００１３】
有利な特性によると、送信要求をＨＴＴＰプロトコルに従って送信する。
【００１４】
特定の特性によると、ファイル記述テーブルを地上波デジタルネットワーク上で送信する。
【００１５】
有利な特性によると、本方法は、オブジェクトバージョンの識別子が使用できない場合にエラーメッセージを受信するステップを備える。
【００１６】
本発明はさらに、
受信されなかったかまたは正確に受信されなかったオブジェクトの少なくとも一部の送信要求を受信するステップであって、その送信要求は、再送されるフラグメントが属するオブジェクトの識別子と再送されるフラグメントの識別子とを備えるステップ
を備えるデータ修復方法にも関する。
【００１７】
本発明によると、本方法はオブジェクトバージョンの識別子と再送されるフラグメント（複数）の少なくとも一部とを備えるメッセージを送信するステップを備える。
【００１８】
本発明は、
ファイル記述テーブルを受信する手段
再送されるフラグメントとも称するが、受信されなかったかまたは正確に受信されなかったオブジェクトの少なくとも一部の送信を要求する手段であって、その送信要求は、再送されるフラグメント（複数）が属するオブジェクトの識別子と再送されるフラグメント（複数）の識別子とを備える手段
を備えるデータ受信端末にも関する。
【００１９】
本発明によると、端末は、オブジェクトバージョンの識別子を送信要求に挿入する手段を備える。
【００２０】
添付の図面を参照して以下の詳細な説明を読むと、本発明はより容易に理解され、他の特徴および利点は明らかになるであろう。
【発明を実施するための最良の形態】
【００２１】
図２は、ＤＶＢ−ＨおよびｘＤＳＬ（「ｘ−Ｄｉｇｉｔａｌ  Ｓｕｂｓｃｒｉｂｅｒ  Ｌｉｎｅ」）要素を組み合わせたインフラを用いた本発明の特定の実施形態を実装するネットワーク２のインフラの概略図を示す。このネットワークにより、特に、ＤＶＢ−ＣＢＭＳコンテクストにおいてファイルをファイルモードで送信することが可能となる。
【００２２】
ネットワーク２のインフラは特に、
サービスプロバイダに属し、そのサービスプロバイダの要素を相互接続するＩＰネットワークバックボーン２３、
ＡＤＳＬネットワークのＩＰネットワーク２３への接続を可能とするＩＰネットワークバックボーン２７、
データを受信機２９０から受信するビデオコーダ２９、
ファイルサーバ２５０と修復サーバ２５１とを備えるサーバ２５、
（ＤＶＢ−Ｈサービスプロバイダとの相互作用を可能とする、ｈｔｔｐ／ｈｔｍｌまたはｗａｐサーバである）ウェブポータル２８、
ＤＶＢ−Ｈネットワーク２２、
ＩＰネットワーク２３および２７の相互接続を可能とするＩＰルータ２６、
ブロードバンドネットワーク（例えば、ＡＴＭネットワーク）２１３、
ＤＳＬＡＭモジュール２１０、
アクセスポイント２１１、および
端末２０。携帯端末および、例えばＰＤＡまたは携帯電話であることが望ましい。
を備える。
【００２３】
サーバ２５は単一のブロック（同一マシン内で実装されているサーバ２５０および２５１）であるか、または別ブロック（例えば、分離されているサーバ２５０よび２５１）の形であることができる。本発明の変形例として、ファイルサーバを複数の修復サーバに関連付けることができ、および／または１つの修復サーバを複数のファイルサーバに関連付けることができる。本発明の変形例として、ファイルサーバ（複数）を１つまたは複数の修復サーバにローカルに、またはリモート接続（例えば、インターネット接続）を介して接続することができる。
【００２４】
ポータル２８ならびにサーバ２５０および２５１はネットワーク２３に接続される。ファイルサーバ２５０はＤＶＢ−Ｈサービスを、ＤＶＢ−Ｈネットワーク２２を介して端末２０に送信する。
【００２５】
ＤＶＢ−Ｈネットワーク２２は特に、
ＤＶＢ−ＨタイプのＩＰカプセル化モジュール２２０（ＩＰＥ）、
ＤＶＢ−Ｈネットワークコア２２１、および
送信機２２２
を備える。
【００２６】
ファイルサーバ２５０はネットワーク２２を介してオーディオ／ビデオファイルをＤＶＢ端末、特に端末２０に送信する。修復サーバはこれらのファイルも受信し、それらのファイルを所定時間、および／または特定のイベントが発生するまで、および／またはその記憶容量が使い切られるまで、記憶する。修復サーバは従って、端末により正しく受信されなかったファイルの全部または一部を、ＤＶＢネットワーク２２上および／またはネットワーク２１１を介して再送することができる。
【００２７】
１つの実装の変形によると、携帯電話ネットワークを介して端末と修復サーバ（および場合によってはファイルサーバ）の間のアップリンクを確立する。携帯電話ネットワークは例えば、ＧＧＳＮ携帯電話ネットワークゲートウェイ、ネットワークコアおよび基地局を備える。この場合、端末は携帯電話ネットワークとの通信を可能とする送信機／受信機を備える。携帯電話ネットワークは例えば、３Ｇ（即ち、第三世代）またはＧＳＭネットワークである。携帯電話ネットワークは、オーディオ／ビデオデータの転送を可能とするダウンリンク方向（ネットワークコアから端末への方向）の高速ネットワークであることが望ましい。
【００２８】
図５は端末２０を概略的に示す。
【００２９】
端末２０は、アドレスバスおよびデータバス５３により相互接続した形で、
マイクロプロセッサ５０（またはＣＰＵ）、
不揮発性ＲＯＭメモリ（「Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ」）５１、
ＲＡＭメモリ（「Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ」）５２、
インターネットデータ（例えば、ネットワーク２１１を介して送受信したデータ）の送受信を可能とするインターネットインタフェース５４、
ＤＶＢ−Ｈネットワーク上で受信した信号を受信する受信モジュール５５、および
受信したイメージを（例えば、表示または記録向けに）オーディオ／ビデオアプリケーションに送信するインタフェース５６
を備える。
【００３０】
さらに、図５に示す要素の各々は当業者にとり周知である。これらの一般的な要素はここでは説明しない。
【００３１】
本説明で用いる「レジスタ」という単語は、上述したメモリの各々における、低容量メモリゾーン（少数のバイナリデータ）だけでなく（プログラム全体あるいは受信したオーディオ／ビデオサービスを表すデータの全部または一部の記憶を可能とする）高容量メモリゾーンも指すことに留意されたい。
【００３２】
ＲＯＭメモリ５１は特に、
プログラム「ｐｒｏｇ」５１０
を備える。
【００３３】
上述の方法のステップを実装するアルゴリズムは、これらのステップを実装する端末２０に関連するＲＯＭメモリ５１に格納される。ブート時、マイクロプロセッサ５０はこれらのアルゴリズムの命令をロードおよび実行する。
【００３４】
ＲＡＭメモリ５２は特に、
レジスタ５２０内の、端末２０のブート時にロードされるマイクロプロセッサ５０のオペレーティングプログラム、
レジスタ５２１内の、受信したＦＤＴテーブルの内容、
レジスタ５２２内の、カレントＴＯＩフィールド、および
１つまたは複数の受信ファイルに対応するオーディオ／ビデオデータ
を備える。
【００３５】
図６は修復サーバ２５１を概略的に示す。
【００３６】
サーバ２５１は、アドレスバスおよびデータバス６３により相互接続した形で、
マイクロプロセッサ６０（またはＣＰＵ）、
不揮発性ＲＯＭメモリ６１、
ＲＡＭメモリ６２、および
インターネットデータ（例えば、端末２０に送信したデータおよび／またはサーバ２５０あるいは端末２０から受信したデータ）の送受信を可能とするインターネットインタフェース６４
を備える。
【００３７】
さらに、図６に示す要素の各々は当業者には周知である。これらの一般的な要素はここでは説明しない。
【００３８】
ＲＯＭメモリ６１は特に、
プログラム「ｐｒｏｇ」６１０
を備える。
【００３９】
上述の方法のステップを実装するアルゴリズムは、これらのステップを実装するサーバ２５１に関連付けたＲＯＭメモリ６１に格納される。ブート時、マイクロプロセッサ６０はこれらのアルゴリズムの命令をロードおよび実行する。
【００４０】
ＲＡＭメモリ６２は特に、
レジスタ６２０内の、サーバ２５１のブート時にロードされるマイクロプロセッサ６０のオペレーティングプログラム、
レジスタ６２１内の、受信したＦＤＴテーブルの内容、
レジスタ６２２内の、カレントＴＯＩフィールド、および
１つまたは複数の受信ファイルに対応するオーディオ／ビデオデータ
を備える。
【００４１】
図３は、本発明によるファイルモードでのファイルサービス送信を概略的に示す。ファイルサーバ２５０は第１のＦＤＴ３１０を送信する。第１のＦＤＴ３１０は、ＤＶＢ−Ｈネットワーク上のＦＬＵＴＥプロトコルを介して端末２０に送信される。第１のＦＤＴ３１０はＵＲＩ（例えば、名前）を備える。そのＵＲＩは、送信されるオブジェクト（例えば、ファイル、イメージまたはバイナリデータセット）の識別を可能とする。第１のＦＤＴ３１０はＴＯＩ（「Ｔｒａｎｓｐｏｒｔ  Ｏｂｊｅｃｔ  Ｉｄｅｎｔｉｆｉｅｒ」）も備える。ＴＯＩは、例えば、ＦＬＵＴＥプロトコルの仕様に従うＴＯＩであるか、または送信されるオブジェクトのバージョンの任意の他の識別子（例えば、デジタル）である。従ってＴＯＩにより、送信されるオブジェクトのバージョンを識別することができる。端末２０は第１のＦＤＴ３１０を受信し、送信されるオブジェクトの記述を、この第１のＦＤＴ、ＵＲＩおよびＴＯＩに従って記録する。ファイルサーバ２５０は次いでデータを、（第１のＦＤＴに対応する）オブジェクトの一部に対応する１つまたは複数のシンボル（またはフラグメント）の形で、後続フレーム３１１乃至３１３の形式でＤＶＢ−Ｈネットワークを介して端末２０に送信する。例として、第１のシナリオによると、端末２０がメッセージ３１４を修復サーバ２５１に（アップリンクチャネル、例えばインターネットチャネルを介して）送信するのと同じ時間間隔で、ファイルサーバ２５０が第２のＦＤＴ３２０を第１のＦＤＴと同じＵＲＩおよび別のＴＯＩ（送信オブジェクトのバージョン変化がある。これは、例えば、更新されたイメージを伴う。）で端末２０に送信することを仮定する。第２のシナリオによると、ファイルサーバ２５０は、端末２０により受信されなかった（または正確に受信されなかった）メッセージ３２０を送信する。メッセージ３１４は２つのＦＤＴに対応するＵＲＩ、再送されるフラグメント（複数）の識別子および第１のＦＤＴに対応するＴＯＩを含む。メッセージ３１４により、端末２０は、ＤＶＢ−Ｈを介して修復サーバ２５１から受信されなかったまたは正確に受信されなかった１つまたは複数のシンボル（またはフラグメント）を要求することができる。第２のＦＤＴ３２０を端末２０により受信する必要はない。第１のＦＤＴに関連するＴＯＩを含むメッセージ３１４を受信すると、カレントＴＯＩを検証した後に、サーバ２５１はエラーフレーム３１５を端末に転送する。エラーフレーム３５１は、要求されたフラグメント（複数）が、カレントＵＲＩに対応するオブジェクトの使用できないバージョンに属することを示す。次いで端末２０が、第２のＦＤＴ３２０に対応するＴＯＩを記録し、カレントＵＲＩ、再送されるフラグメント（複数）の識別子および第２のＦＤＴに対応するＴＯＩを含むメッセージ３１６を修復サーバ２５１に転送する、と仮定する。サーバ２５１は要求メッセージ３１６のＴＯＩがカレントＴＯＩであるかどうかをチェックし、要求されたフラグメント（複数）を含むｈｔｔｐメッセージ３１７（認証により保証されたバージョンの、ＲＦＣ２６１６またはＲＦＣ２８１８標準により定義された「ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒ���ｔｏｃｏｌ」）を端末２０に送信する。１つの変形例として、修復サーバ２５１は要求されたフラグメント（複数）を、新規ＦＬＵＴＥセッションまたは既存のＦＬＵＴＥセッション（ｈｔｔｐメッセージ３１７は送信されていない）において、ＤＶＢ−Ｈネットワークを介して端末２０に送信する。サーバ２５１のメモリのより経済的な使用を可能とする（それにより、既存のＦＬＵＴＥセッションではオーディオ／ビデオデータを記憶する必要がない）別の変形例として、修復サーバ２５１は、要求されたフラグメントをＤＶＢ−Ｈネットワークを介して送信するようファイルサーバ２５０に要求する。
【００４２】
図４は、本発明によるファイルモードでのファイルサービスブロードキャストの変形例を概略的に示す。本変形例によると、メッセージ３１０乃至３１３および３２０の送信は図３に関して説明したものと同様である。
【００４３】
例として、端末２０がメッセージ４００を修復サーバ２５１に（アップリンクチャネル、例えばインターネットチャネルを介して）送信するのと同じ時間間隔で、ファイルサーバ２５０が第２のＦＤＴ３２０を第１のＦＤＴと同じＵＲＩおよび別のＴＯＩで端末２０に送信することを仮定する。メッセージ４００は２つのＦＤＴに対応するＵＲＩ、再送されるフラグメント（複数）の識別子を含む。メッセージ４００により、端末２０は、ＤＶＢ−Ｈを介してファイルサーバ２５０から受信されなかったまたは正確に受信されなかった１つまたは複数のシンボル（またはフラグメント）を要求することができる。第２のＦＤＴ３２０を端末２０により受信する必要はない。メッセージ４００を受信すると、サーバ２５１は要求されたフラグメント（複数）、ＴＯＩおよびカレントＵＲＩを含むｈｔｔｐメッセージ４０１を転送する。端末２０は次いで、メッセージ４０１に含まれるＵＲＩおよびＴＯＩがメッセージ４００内で要求されたシンボルに対応するかどうかをチェックする。そうでなければ、端末はメッセージ４０１を無視する。そうであれば、メッセージ４０１内のＵＲＩおよびＴＯＩは要求されたフラグメント（複数）に対応し、メッセージ４０１のフラグメント（複数）を記録することができる。
【００４４】
図７は、端末２０により受信されサーバ２５０および２５１のうち１つにより送信されたオブジェクトを処理するアルゴリズムの形で実装した、オーディオ／ビデオデータの受信方法を示す。本アルゴリズムを端末２０内で実行する（例えば、ＣＰＵ５０により実行する。それにより、本アルゴリズムはプログラム５１０のタスクに対応する）。
【００４５】
本方法は初期化ステップ７０で開始する。ステップ７０において、別の変数およびパラメータを更新する。本ステップにおいて、端末２０はファイルサーバ２５０を識別する。ファイルサーバ２５０は、修復サーバのリストを端末２０に送信する。そのリストには、端末が例えば選択したサーバ２５１が含まれる。
【００４６】
次いで、ステップ７１において、端末２０は待機し、その後フレームまたはメッセージをＤＶＢ−Ｈネットワーク２２から受信する。
【００４７】
次いで、テスト７２において、端末２０は受信したフレームがＦＤＴを含むかどうかをチェックする。
【００４８】
そうである場合、ステップ７４において、端末２０は受信したフレームからＴＯＩを抽出し、レジスタ５２２に格納する。ステップ７４の後に、ステップ７１を再度繰り返す。
【００４９】
そうでない場合、ステップ７３において、端末２０は、正確に受信し格納されたＦＤＴ（受信データの完全性は、例えば、誤り訂正コードを用いてチェックすることができる）に対応するオブジェクトのフラグメントを格納する。
【００５０】
次いで、テスト７５において、端末２０は、最後に格納されたＦＤＴに対応するオブジェクトの全てのフラグメントを正確に受信したかどうかをチェックする。即ち、或る特定のフラグメントが受信されなかったかまたは正しく受信されなかった恐れがある。テスト７５を、送信オブジェクトの受信終了を検知したとき、またはＦＤＴ内で指定したタイムアウトの後に実行することが望ましい。
【００５１】
オブジェクトのフラグメントが正確に受信されなかった場合、ステップ７６において、（セーフティマージンの役割を果たす所定時間（「バックオフ時間」）の可能な一時停止の後に）、端末２０は前述のメッセージ３１４または４００に対応する要求を修復サーバ２５１に送信する。
【００５２】
次いで、ステップ７７において、端末２０は、ステップ７６からの要求に応じて修復サーバ２５１から（または１つの変形によるとファイルサーバ２５０から）メッセージを受信する。これは、特に、メッセージ３１５、３１７または４０１を伴う可能性がある。
【００５３】
次いで、テスト７８において、端末２０は受信したメッセージが受信したシンボルを含むかどうかをチェックする。図４に示す変形例によると、端末２０はさらに、メッセージ４０１内に存在するＴＯＩが実際に、レジスタ５２２に格納したカレントＴＯＩに対応するメッセージであるかどうかをチェックする。そのカレントＴＯＩは、ステップ７６で送信した要求に対応する。
【００５４】
そうである場合、受信したシンボルは有効であり、ステップ７９において端末が記録する。
【００５５】
そうでない場合、エラーメッセージが受信されるかまたは受信したシンボルがカレントＴＯＩに関連付けられずに、あるいはステップ７９の後、ステップ７１を再度繰り返す。
【００５６】
図８は、アルゴリズムの形で実装したデータ受信方法を示す。そのデータは、修復サーバ２５１により受信され、ファイルサーバ２５０により送信される。本アルゴリズムを修復サーバ２５１内で実行する（例えば、ＣＰＵ６０により実行する。これにより、本アルゴリズムはプログラム６１０のタスクに対応する）。
【００５７】
上記の方法は初期化ステップ８０で開始する。ステップ８０において、別の変数およびパラメータを更新する。
【００５８】
次いで、ステップ８１において、サーバ２５１は待機し、その後サーバ２５０からデータを受信する。
【００５９】
次いで、テスト８２において、サーバ２５１はそのデータがＦＤＴを含むかどうかをチェックする。
【００６０】
そうであれば、ステップ８３において、サーバ２５１はレジスタ６２２内の受信したＦＤＴに関連付けたＴＯＩ、およびＵＲＩを記録する。
【００６１】
そうでなければ、ステップ８４において、サーバ２５１はデータをレジスタ６２３に格納する。
【００６２】
ステップ８３および８４の後に、ステップ８１を再度繰り返す。
【００６３】
本発明の１つの実施形態では、フラグメントを、それを要求した端末に送信するようサーバ２５１がサーバ２５０に要求することによって、ステップ８４を省略または減らすことができる。
【００６４】
図９は、アルゴリズムの形で修復サーバ２５１により実行した修復要求を修復または処理する方法を示す（その修復要求は例えばＣＰＵ６０により実行される。それにより上記アルゴリズムはプログラム６１０のタスクに対応する）。上記アルゴリズムは図３に示すデータ交換に対応する。
【００６５】
上記の方法は初期化ステップ９０で開始する。ステップ９０において、別の変数およびパラメータを更新する。
【００６６】
次いで、ステップ９１において、サーバ２５１は待機し、その後ｈｔｔｐメッセージ（例えば、メッセージ３１４または３１６）を端末２０から受信する。
【００６７】
次いで、テスト９２において、サーバ２５１は受信したｈｔｔｐメッセージが、ファイルサーバ２５０を介して前に送信した１つまたは複数のオブジェクトフラグメントの（要求タイプ３１０である）送信要求に対応するかどうかをチェックする。
【００６８】
次いで、テスト９３において、サーバ２５１は受信した要求に挿入されたＴＯＩを抽出し、このＴＯＩが（レジスタ６２２に格納された）カレントＴＯＩに対応するかどうかをチェックする。
【００６９】
そうならば、サーバ２５１はステップ９４において要求フラグメント（複数）を送信する（メッセージ３１７）。１つの変形例によると、サーバ２５１はファイルサーバ２５３に、要求フラグメント（複数）を端末に再送することまたはＤＶＢ−Ｈネットワーク上で送信することを要求する。
【００７０】
そうでなければ、サーバ２５１はステップ９５においてエラーメッセージ（メッセージタイプ３１５）を送信する。従って、要求フラグメントが使用できない場合、端末側での実装が簡潔になり、データが端末２０に不必要に再送されることはない。
【００７１】
ステップ９４または９５の後にステップ９１を再度繰り返す。
【００７２】
図１０は、アルゴリズムの形で修復サーバ２５１により実行した修復要求を修復または処理する方法を示す（その修復要求は例えばＣＰＵ６０により実行される。それにより上記アルゴリズムはプログラム６１０のタスクに対応する）。上記アルゴリズムは図４に示すデータ交換に対応する。
【００７３】
上記の方法は初期化ステップ９０で開始する。ステップ９０において、別の変数およびパラメータを更新する。
【００７４】
次いで、ステップ９１において、サーバ２５１は待機し、その後ｈｔｔｐメッセージ（例えば、メッセージ４００）を端末２０から受信する。
【００７５】
次いで、テスト９２において、サーバ２５１は受信したｈｔｔｐメッセージが、ファイルサーバ２５０を介して前に送信した１つまたは複数のオブジェクトフラグメントの（要求タイプ３１０である）送信要求に対応するかどうかをチェックする。
【００７６】
次いで、テスト９６において、サーバ２５１はメッセージ（タイプ４０１）内の受信した要求に存在する送信フラグメントのＵＲＩと識別子とに対応するフラグメント（複数）を送信する。上記メッセージには、レジスタ６２２に格納したＴＯＩも含まれる。従って、ＴＯＩの検証を端末２０により実行しなければならず、それによりサーバ２５１における実行が簡単になる。次いでステップ９１を再度繰り返す。
【００７７】
本発明は勿論、上述の実施形態には限定されない。
【００７８】
特に、本発明はＤＶＢ−Ｈネットワークにおける実装に限定されず、バージョンが変化しうるオブジェクト（例えば、任意の種類のイメージ、サウンドおよび／またはデータファイル）を、１つまたは複数のフラグメントの形で端末に任意に送信することにも関する。
【００７９】
本発明は、雑音が多いチャネルまたは高速に変化するチャネル（例えば、ワイヤレス通信）上のフラグメント送信に特に良く適している。
【００８０】
さらに、アップリンク（即ち、端末から）はインターネットまたはモバイルタイプである必要はなく、任意の種類（例えば、回線交換ネットワーク、専用ネットワーク、等）であることができる。
【００８１】
さらに、オブジェクトサーバを端末に接続するネットワークアーキテクチャは、本発明によると、１つまたは複数の端末へのオブジェクトの送信を可能とする任意の所与のタイプであることができる。
【００８２】
さらに、オブジェクトはオーディオ／ビデオファイルタイプである必要はなく、本発明によると、任意のタイプ（例えば、ファイルに挿入されないサウンドまたはイメージ、非オーディオおよび非ビデオ、等）であることができる。
【００８３】
本発明によると、オブジェクトバージョンの識別子はＤＶＢ標準で定義される識別子である必要はなく、任意のタイプの識別子（例えば、所定の数字）であることができる。
【図面の簡単な説明】
【００８４】
【図１】先行技術による、サーバと端末間の通信の通信プロトコルを示す図である。
【図２】本発明を実装するＤＶＢ−Ｈネットワークの高度な概略図である。
【図３】本発明の２つの実施形態による、図２に示すネットワークにおけるサーバと端末間の通信の通信プロトコルを示す図である。
【図４】本発明の２つの実施形態による、図２に示すネットワークにおけるサーバと端末間の通信の通信プロトコルを示す図である。
【図５】図２に示すネットワークにおける端末を示す図である。
【図６】図２に示すネットワーク内で実装される修復サーバを示す図である。
【図７】図５に示す端末内で実装されるアルゴリズムを示す図である。
【図８】図６に示す修復サーバ内で実装されるアルゴリズムを示す図である。
【図９】図６に示す修復サーバ内で実装されるアルゴリズムを示す図である。
【図１０】図６に示す修復サーバ内で実装されるアルゴリズムを示す図である。
【図１】
2009533918.tif 000003
【図２】
2009533918.tif 000004
【図３】
2009533918.tif 000005
【図４】
2009533918.tif 000006
【図５】
2009533918.tif 000007
【図６】
2009533918.tif 000008
【図７】
2009533918.tif 000009
【図８】
2009533918.tif 000010
【図９】
2009533918.tif 000011
【図１０】
2009533918.tif 000012
【国際調査報告】
2009533918.tif 000013
2009533918.tif 000014