プル・モード及びプッシュ・モードを組み合わせるシステム及び方法
本発明は、プッシュ・モード及びプル・モードの組合せを使用してコンテンツをダウンロードする方法に関する。第１の端末（１）と、少なくとも第２の端末（２）と、コンテンツ・サーバ（５，８）とを備える通信システム（１０）では、本発明は、第１の端末のレベルで、コンテンツ・サーバ若しくは少なくとも第２の端末からのプル・モードにおいて、又はコンテンツ・サーバからのプッシュ・モードにおいてコンテンツをダウンロードする工程と、コンテンツの連続するダウンロードのモード間でシームレスに切り換える工程とを含む、コンテンツをダウンロードする方法に関する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、コンテンツ・ダウンロードに関し、特に、プル手法及びプッシュ手法の組合せの使用に関する。
【背景技術】
【０００２】
この部分は、本願明細書及び特許請求の範囲記載の本発明の種々の局面に関係し得る当該技術分野の種々の局面を本願明細書及び特許請求の範囲の読者に紹介することを意図している。本願明細書及び特許請求の範囲の記載は、本発明の種々の局面をより詳細に理解することを容易にするための背景情報を読者に与えるうえで有用であると思われる。よって、前述の記載はこれに照らして読まれるものとし、従来技術と認めたものとして読まれるものでない。
【０００３】
サーバと、複数の受信器との間のコンテンツの配信は、サーバと各受信器との間のポイント・ツー・ポイント接続、又はマルチポイント接続の設定を必要とする。ポイント・ツー・ポイント接続は、ユニキャスト手段においてコンテンツを各受信器に配信することを可能にし、ロバストな配信を提供する。これは、以降、プル・モードと呼ぶ。通常、クライアントはアクティブ・イニシエータである。しかし、受信器がかなりの数にのぼるので、接続全ての面倒な管理が必要になる。ネットワークを介したトラフィックを劇的に増加させることもできる。マルチキャスト配信は、よりロバストでない配信で、より少ないネットワーク負荷をもたらす。これは以下ではプッシュ・モードと呼ぶ。
【０００４】
サーバを管理するサービス・オペレータは、受信器の挙動を正確に予測することが可能でない。プッシュ・コンテンツ配信セッションでは、受信器は、受信器がプッシュ配信中にスイッチ・オフされること、受信器が、プッシュ配信が実行中にオンにされること、予約済帯域幅が全て、プッシュ配信に利用可能な訳でないこと、例えば、ＳＴＢユーザが、別の番組を記録している間に一番組を視聴すること、受信器は、プッシュ配信の際に記憶容量が不足していること、受信器はプッシュ配信の際にフルＣＰＵを使用していること、ネットワークはマルチキャスト・トラフィックを処理することが可能でないこと等の理由で、完全な、又は部分的なダウンロードから除外され得る。帯域幅を最適にするために、オペレータは、プッシュ・セッションの維持又は停止を選ばなければならないことがあり得る。プッシュ・セッションの停止は、オペレータがネットワークを大量のトラフックから解放することを可能にし、欠落したコンテンツを有する受信器は回復モードを使用して取り出すことが可能である。回復手法は欧州特許出願第０６２９１４６４．３号明細書に規定されている。一方、プル・モードでは、オペレータは、コンテンツに対するピーク需要に直面しなければならないことがあり得る。その場合、プル・モ―ドの代わりにプッシュ・モードでこのコンテンツをマルチキャストすることにより、オペレータが展開遅延、及びネットワーク帯域幅の使用を最適にすることにおいてより効率的であり得る。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明は、プル・モードとプッシュ・モードとの間で効率的に切り換える方法に関する。
【課題を解決するための手段】
【０００６】
この目的で、本発明は、第１の端末、少なくとも第２の端末、及びコンテンツ・サーバを備える通信システムにおいてコンテンツをダウンロードする方法に関する。方法は、第１の端末のレベルで、コンテンツ・サーバ若しくは少なくとも第２の端末からプル・モードにおいて、又はコンテンツ・サーバからプッシュ・モードにおいてコンテンツをダウンロードする工程と、コンテンツを連続してダウンロードするためにモード間でシームレスに切り換える工程とを含む。
【０００７】
この意味合いでは、「シームレスに」は、何れの他の情報の要求を必要とすることもなく、一方モードから他方モードに端末が連続して切り換わることを意味している。
【０００８】
一実施例によれば、方法は、プッシュ・モードにおいてコンテンツをダウンロードする工程と、プッシュ・モードがコンテンツ・サーバにおいて停止した場合、プル・モードでコンテンツをダウンロードし続ける工程とを含む。
【０００９】
オペレータがプッシュ・セッションを停止すると、端末は、割り込みがあまり多くない状態でダウンロードし続ける。プル・ダウンロード・モードに切り換え、プル・ダウンロード・モードを管理するために十分な情報をプッシュ・セッション中に得ている。
【００１０】
別の実施例によれば、方法は、プル・モードにおいてコンテンツをダウンロードする工程と、プッシュ・モードがコンテンツ・サーバにおいて開始した場合、プッシュ・モードでコンテンツをダウンロードし続ける工程とを含む。
【００１１】
一実施例では、方法は、ＦＬＵＴＥプロトコルにより、セッション配信においてプッシュ・コンテンツを受信する工程と、セッション配信中に、ファイル配信テーブルＦＤＴにおいて情報を受信し、プル・モードに切り換えることが可能になる工程とを含む。
【００１２】
ＦＤＴは、プル・モードへのシームレスな切り換えに必要な更なる情報を含む。プッシュ・モードが停止すると、端末は、何れの別の情報も取り出さなくてよい。プル・モードに切り換えるためのＦＤＴを備えた適切な情報を既に受信している。
【００１３】
一実施例によれば、方法は、ＦＤＴインスタンスのインテグリティを検証する工程と、ＦＤＴインスタンスが首尾良く受信されているか否かをインデキシング・サーバに示し、ＦＤＴインスタンスに関連付けられたファイルが首尾良く受信されているか否かをインデキシング・サーバに示す工程とを含む。
【００１４】
一実施例によれば、方法は、損なわれたＦＤＴインスタンスを検出すると、ファイル配信の最後を待つ工程と、プル・モードにおいてＦＤＴインスタンス修復を行う工程とを含む。
【００１５】
一実施例によれば、方法は、損なわれたフルＦＤＴを検出すると、セッション配信の最後を待つ工程と、プル・モードにおいてフルＦＤＴの修復を行う工程とを含む。
【００１６】
一実施例によれば、方法は、ピアツーピア・プロトコルに応じてプル・コンテンツを受信する工程と、プッシュ・モードへの切り換えを可能にする情報を含むピアツーピア・メタ情報ファイルを受信する工程とを含む。
【００１７】
本発明は、プッシュ・モードにおいてコンテンツをダウンロードする手段と、プル・モードにおいてコンテンツをダウンロードする手段と、一方モードから他方モードにシームレスに切り換える手段とに関する。
【００１８】
本発明の別の目的は、プログラムがコンピュータ上で実行されると、本発明による方法の工程を実行するためのプログラム・コード命令を含むコンピュータ・プログラム・プロダクトである。「コンピュータ・プログラム・プロダクト」は、ディスケット（登録商標）やカセットなどの、プログラムを記憶空間が含むことを含むのみならず、電気信号又は光信号などの信号も含み得るコンピュータ・プログラム・サポートを意味している。
【図面の簡単な説明】
【００１９】
【図１】実施例に準拠したシステムを示すブロック図である。
【図２】実施例による端末を表す図である。
【図３】プル・モードを示すフローチャートである。
【図４】プッシュ・モード及びプル・モードの組合せを示すフローチャートである。
【発明を実施するための形態】
【００２０】
本願開示の実施例の範囲と範囲が同等の特定の局面を以下に記載する。前述の局面は、本発明がとり得る特定の形態の簡単な要約を本明細書及び特許請求の範囲の読者に提供するためのみに提示しており、前述の局面は、本発明の範囲を限定することを意図するものでない。実際に、本発明は、以下に記載されていないことがあり得る種々の局面を包含し得る。
【００２１】
本発明は、添付図面を参照して、如何なる方法においても限定的でなく、以下の実施例及び実行例によってよりよく理解され、例証されるであろう。
【実施例】
【００２２】
図１及び図２では、図示されたブロックは、純粋に機能エンティティであり、これは、物理的に別個のエンティティに必ずしも対応しない。すなわち、ソフトウェアの形態で開発されるか、１つ又は複数の集積回路で実現することが可能である。
【００２３】
図１は、コンテンツを配信する実施例による通信システム１００のアーキテクチャを表す。端末１、２、３はクライアント・アプリケーションを有する。特に、これらは、セットトップボックス（ＳＴＢ）機能を有する。以下実施例では、端末はＳＴＢであるが、実施例は前述の端末に限定されるものでない。コンテンツ・サーバからデータをダウンロードするためのクライアント・アプリケーションを備える装置に適用可能である。
【００２４】
端末は、プッシュ・モードでコンテンツをダウンロードする手段、及びプル・モードでコンテンツをダウンロードする手段も備える。これは、以下に説明するプル機能及びプッシュ機能を行う。
【００２５】
システムは、プッシュ・コンテンツ・サーバ５及びプル・コンテンツ・サーバ８を含む。プル・コンテンツ・サーバは、プル・モードにおいてコンテンツを配信するよう適合される。これは、複数のクライアントとのポイント・ツー・ポイント接続を設定する手段を備える。プッシュ・コンテンツ・サーバは、プッシュ・モードにおいてコンテンツを配信するよう適合される。当然、前述のサーバは同じ装置に含まれ得る。
【００２６】
インデキシング・サーバ６の役割は、ピアＳＴＢを互いに関係付けて修復を完了するか、又はコンテンツを取り出す。インデキシング・サーバの役割は、ファイル又はファイルの一部を回復したいピアを、欠落している情報を供給することができるピアと関係付けることである。インデキシング・サーバは、何れのコンテンツ・ファイルも記憶せず、ファイルの場所についての情報を記憶するための集中化されたインデクスとしてふるまう。プル・プロトコルは、コンテンツのダウンロード・ステータスについて各ＳＴＢによって逐次通知される。上記実施例では、システムは一インデキシング・サーバのみを備える。ネットワークは、いくつかのインデキシング・サーバに、例えば、地域毎、又はコンテンツ・タイプ毎にアクセスを最適化させることが可能である。同じインデキシング・サーバが、プッシュ・モード環境において、かつ、プル・モード環境において使用される。
【００２７】
以下ＳＤ＆Ｓと表すサービス・ディスカバリ・サーバ７は、ＥＴＳＩ ＴＳ１０２ ０３４ Ｖ１．２．１ （２００６−０９） Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ （ＤＶＢ）， Ｔｒａｎｓｐｏｒｔ ｏｆ ＭＰＥＧ−２ Ｂａｓｅｄ ＤＶＢ Ｓｅｒｖｉｃｅｓ ｏｖｅｒ ＩＰ Ｂａｓｅｄ Ｍｅｔｗｏｒｋｓ標準に示されたようなサービス・ディスカバリ及び選択手法を行うよう適合される。
【００２８】
上記実施例では、同じＳＤ＆Ｓサーバが、ＰＵＳＨモード環境、及びＰＵＬＬモード環境において使用される。
【００２９】
図２は、実施例による端末の構築ブロックを表す。端末は、記憶手段１．１と、通信手段１．２と、処理手段１．３と、内部バス１．４とを備える。記憶手段は、端末がプッシュ・モード又はプル・モードにおいてファイルをダウンロードすることを可能にするプログラムを記憶することが意図される。よって、端末は、プッシュ・ダウンロード手段１．６とプル・ダウンロード手段１．５とを備える。これは、一方モードから他方モードに切り換える手段１．７を備える。
【００３０】
次にプル手法を説明する。これは、Ｐ２Ｐと表すピアツーピア・ストラテジに基づく。
【００３１】
プル手法を実施するために、端末はまず、インデキシング・サーバ・アドレス・ディスカバリ段階を行う。ＳＴＢは、ダウンロードに利用可能なコンテンツのカタログをブラウジングすることにより、ダウンロードのためのコンテンツを見つける。カタログのアドレスは、ＥＴＳＩ ＴＳ１０２ ０３４ Ｖ１．２．１ （２００６−０９）及びＥＴＳＩ ＴＳ１０２ ５３９ Ｖ１．１．１， Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ （ＤＶＢ）； Ｃａｒｒｉａｇｅ ｏｆ Ｂｒｏａｄｂａｎｄ Ｃｏｎｔｅｎｔ Ｇｕｉｄｅ （ＢＣＧ） ｉｎｆｏｒｍａｔｉｏｎ ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ （ＩＰ）（ＤＶＢ−ＩＰの意味合いでコンテンツ・ガイドの伝送及びシグナリングを説明している）を使用して見つける。端末は、カタログにおけるインデキシング・サーバのアドレスを見つける。当然、インデキシング・サーバのアドレスは、ＤＶＢ―ＩＰ／ＳＤ＆Ｓシグナリングによって配信されるコンテンツ・ダウンロード提供レコードなどの他の手段によって見つけることが可能である。
【００３２】
大容量コンテンツをダウンロードする能力を向上させるために、コンテンツの各ファイルは、より小容量のブロックに分割される。ピアは次いで、コンテンツのブロックを受信し、検証し、次いで、コンテンツを完全に又は部分的に受信する前に前述のブロックを交換することができる。ハッシュ・コードは各ブロックにわたって算出される。表１に示すようなメタ情報はコンテンツ・サーバ内のファイルとして記憶される。メタ情報は、ピアツーピアにおけるファイル交換を行うために必要な情報全てを含む。ハッシング操作をコンテンツ・サーバによって行うことが可能である。
【００３３】
以下の表は、上記実施例によるコンテンツ・メタ情報を表す。ＴＳＩフィールド及びＴＯＩフィールドは、ＦＬＵＴＥプロトコルにおいて規定され、任意である。これらはここでは、プル・モードとプッシュ・モードとの間のシームレスなスイッチングをサポートするために使用される。Ｃｏｎｔｅｎｔ−Ｂｌｏｃｋ−Ｌｅｎｇｔｈフィールド、Ｃｏｎｔｅｎｔ−Ｂｌｏｃｋ−Ｄｉｇｅｓｔｓフィールド、Ｆｉｌｅ−Ｎａｍｅフィールド、Ｆｉｌｅ−Ｌｅｎｇｔｈフィールド、Ｆｉｌｅ−Ｄｉｇｅｓｔフィールド、Ｆｉｌｅ−Ｂｌｏｃｋ−Ｌｅｎｇｔｈフィールド、及びＦｉｌｅ−Ｂｌｏｃｋ−Ｄｉｇｅｓｔｓフィールドは、Ｐ２Ｐプロトコルに必要な最小のメタ情報である。
【００３４】
【表１】
Ｍｅｔａ−ｌｎｆｏ−Ｄｉｇｅｓｔフィールドは、ＲＳＡシグネチャを送信して、メタ情報ファイルを認証することを可能にするために使用することが可能である。
【００３５】
ファイル・ダウンロードの方法はその場合、図３に表すように、以下の通りである。
【００３６】
工程Ｓ１。ＳＴＢ１は、選ばれたコンテンツに対する要求をインデキシング・サーバに送出する。
【００３７】
工程Ｓ２。インデキシング・サーバは、コンテンツのメタ情報を供給することができるピアＳＴＢ２のアドレスでＳＴＢに応答する。当然、インデキシング・サーバはいくつかのピアのアドレスを供給することができる。
【００３８】
ＳＴＢ１は、示されたピアとの接続を起動させる（工程Ｓ３）。これは、工程Ｓ４でメタ情報ファイルを取り出し、工程Ｓ５でこのインテグリティを検証し、工程Ｓ６でこのファイルを記憶し、メタ情報の受信をインデキシング・サーバに通知する。関連コンテンツが削除されるまで、ＳＴＢ１はこのファイルをメモリに保つ。
【００３９】
このメタ情報ファイルがあれば、ＳＴＢは、他のピアに、任意のバイト範囲のブロックを要求し、受信データのインテグリティを検証することが可能である。ＳＴＢは、メタ情報ファイルを受信した後、１つ若しくは複数のファイル、又は１つ若しくは複数のファイルのブロックをダウンロードすることが可能である。
【００４０】
ＳＴＢは、工程７で、インデキシング・サーバに一ブロックを要求する。当然、ＳＴＢは同時にいくつかのブロックを要求することができる。これはブロック番号及びファイル識別子（ファイル名であり得る）を送出する。ファイルＩＤは、いくつかのファイルが同時にダウンロードされる場合に必要である。
【００４１】
インデキシング・サーバは、工程８で、コンテンツのブロックを供給することができるピアのアドレスを戻す。
【００４２】
ＳＴＢは、示されたピアとの接続を起動させ（工程９）、コンテンツ・ブロックを取り出し（工程１０）、及びそのインテグリティを検証する（工程１１）。
【００４３】
ＳＴＢは、工程１２で、成功又は失敗の点でブロック・ダウンロードのステータスをインデキシング・サーバに示す。
【００４４】
クライアントは、完全なコンテンツがダウンロードされるまで、他のブロックに対する要求を、インデキシング・サーバに送出することができる。
【００４５】
ＳＴＢから受信する通知に表される情報を使用して、インデキシング・サーバは常にそのデータベースを更新する。何れの特定の時点でも、データ回復を必要とするＳＴＢを、欠落している情報を供給することができるピアＳＴＢと関係付けることができる。
【００４６】
ＴＳＩフィールド及びＴＯＩフィールドのおかげで、端末は、ファイルをダウンロードするためにプッシュ・モードにシームレスに切り換えることができる。
【００４７】
図３では、コンテンツのブロックを供給するピアは、コンテンツのメタ情報を供給するピアと同じである。当然、これは別のピアであり得る。
【００４８】
更に、インデキシング・サーバは、コンテンツのブロックを供給することができる２つ以上のピアのアドレスを返すことが可能である。ＳＴＢは次いで、場合によっては、２つ以上のピアに接続する。
【００４９】
インデキシング・サーバは、ピアＳＴＢの何れによっても、要求されたコンテンツ又はメタ情報を供給することが可能でない情報を有し得る。
【００５０】
その場合、コンテンツを直接配信することができるコンテンツ・サーバのアドレスを供給することが可能である。コンテンツに対する要求でのコンテンツ・サーバのフラッドを避けるために、インデキシング・サーバは、一ピアＳＴＢプールのみを処理し得る。その他のＳＴＢを保留にし、後に、コンテンツを首尾良くダウンロードしたピアＳＴＢプールのアドレスを示す。
【００５１】
あるいは、インデキシング・サーバは、別のインデキシング・サーバ又は「超」インデキシング・サーバに要求をアドレス指定することが可能である。要求された情報を見つけた場合、インデキシング・サーバは、そのデータベースに情報を記憶し、ＳＴＢに肯定的に応答する。
【００５２】
インデキシング・サーバは同じコンテンツに対していくつかのアドレスを供給し得る。コンテンツはいくつかのピアＳＴＢにわたって分散させることができる。すなわち、ピアＳＴＢの何れも、コンテンツ全部を有する訳でないが、コンテンツ合計を、ピアＳＴＢ上に常駐している部分コンテンツから構成することが可能である。インデキシング・サーバは、ダウンロード速度が低すぎるか、又はピアが利用可能でないことが証明された場合、別のピアからのコンテンツを取り出す機会をＳＴＢに与えるために要求コンテンツを全部又は部分的に供給することが可能な別のピアＳＴＢを示すことも可能である。
【００５３】
一方、インデキシング・サーバには、例えば、ピアからの首尾良く行われたダウンロードの数にわたる統計に基づいたインテリジェントなピア選択を可能にするアルゴリズムが供給され得る。
【００５４】
次に、プッシュ配信の方法を説明する。プッシュ配信は、ＲＦＣ３９２６に規定されたような、ＦＬＵＴＥと表す単方向伝送プロトコルによるファイル配信に基づく。プッシュ配信は、上記ピアツーピア手法を使用する回復機構を備える。
【００５５】
ＦＬＵＴＥプロトコルは、マルチキャスト・オブジェクトの伝送及び関連付けられた記述子表を規定する。これは、現在のセッションにおいて送信されなければならないファイルの情報を含む、ＦＤＴと表すファイル配信テーブルを規定する。ＦＬＵＴＥプロトコルは、コンテンツ・サーバからのＦＤＴをマルチキャスト・モードにおいて全てのＳＴＢに送信する。ＦＬＵＴＥは、いくつかの伝送モード（１つの完全なＦＤＴ及びそれに続く複数のファイル、又は一連のＦＤＴインスタンス（中間ＦＤＴ）及びそれに続く関連ファイルなど）を規定する。後者は、膨大な容量のビデオ・ファイルの伝送に特に適しており、セッションの最後に達する前に、オブジェクト又はファイルが正しく受信されたかを受信器が検証することができることを可能にする。前者の伝送モードは、小容量ファイルが伝送される環境において好都合である。フルＦＤＴは、同じセッションのＦＤＴインスタンス全てから構築される。
【００５６】
実施例では、ＦＬＵＴＥ ＦＤＴは、以下の表２に示すような、（ブロック長及びブロック・ハッシュを備える）特定のピアツーピア・メタ情報を有する。その場合、コンテンツ・ダウンロード中に、一方のプロトコルから他方のプロトコルに切り換えることが可能である。実際に、ＦＬＵＴＥマルチキャスト・プッシュ・セッションの最後に完全にコンテンツをダウンロードしなかった受信器は、ピアツーピア・プル・モードにシームレスに切り換え、コンテンツの欠落ブロックが厳密に分かることを可能にする、ＦＤＴにおける情報によって、欠落ブロックをダウンロードする。同様に、ピアツーピア・プル・モードにより、コンテンツをダウンロードし始めた受信器は、プッシュ・モードでファイルの欠落ブロックを回復するために必要な情報を受信器に与えるＦＤＴを使用してプッシュ・モードにシームレスに切り換えることが可能である。
【００５７】
以下の表は、実施例により、Ｐ２Ｐメタ情報を含むＦＬＵＴＥファイル配信表を表す。
【００５８】
【表２】
Ｃｏｎｔｅｎｔ−Ｂｌｏｃｋ−Ｌｅｎｇｔｈフィールド、Ｃｏｎｔｅｎｔ−Ｂｌｏｃｋ−Ｄｉｇｅｓｔｓフィールド、Ｆｉｌｅ−Ｎａｍｅフィールド、Ｆｉｌｅ−Ｌｅｎｇｔｈフィールド、Ｆｉｌｅ−Ｄｉｇｅｓｔフィールド、Ｆｉｌｅ−Ｂｌｏｃｋ−Ｌｅｎｇｔｈフィールド、及びＦｉｌｅ−Ｂｌｏｃｋ−Ｄｉｇｅｓｔｓフィールドは、Ｐ２Ｐプロトコルに必要な最小のメタ情報である。ファイルは、いくつかのブロックに切断される。
【００５９】
Ｃｏｍｐｌｅｔｅ−ＦＤＴ−Ｄｉｇｅｓｔフィールドは、ＲＳＡシグネチャを送信して、フルＦＤＴを認証することを可能にするために使用することが可能である。
【００６０】
プッシュ手法でコンテンツをダウンロードするために、クライアントは、プッシュ・コンテンツ・ダウンロード・セッション・ディスカバリ段階を行う。クライアントＳＴＢはプッシュ・ダウンロード・オファーに加入する。加入の一部として、サービスがＤＶＢＩＰ／ＳＤ＆Ｓ手法を介して、ＳＤ＆Ｓサーバにより、サービスのシグナリングが伝送される配信アドレスを得る。ＳＴＢは次いで、専用マルチキャスト・アドレスにリッスンする。これは、ＤＶＢ−ＩＰコンテンツ・ダウンロード・オファー・レコードを見つける。
【００６１】
このコンテンツ・ダウンロード・オファー・レコードにおいて、コンテンツ・ダウンロード・セッションの開始及び終了日時、並びに、コンテンツが配信されるポート、マルチキャスト・アドレス、及び、依存するインデキシング・サーバのアドレスなどの他の情報を見つける。上記実施例によるＳＤ＆Ｓレコード・ファイルは以下の表３に示す。
【００６２】
【表３】
ＡｎｎｏｕｎｃｅｍｅｎｔＤｉｇｅｓｔフィールドは、ＲＳＡシグネチャを送信して、通知を認証することを可能にするために使用することが可能である。
【００６３】
図４に示すように、ディスカバリ段階において獲得された情報を使用して、ＳＴＢは、プッシュ・セッション・コンテンツが配信されるマルチキャスト・アドレスにリッスンする（工程Ｓ’１）。
【００６４】
各ＦＤＴインスタンスは、それ自身のインテグリティ、及びそれと関連付けられたファイルのブロックのインテグリティを検証することを可能にするいくつかのハッシュ・コードを含む。この情報は、プル・モードについて説明したようなメタ情報ファイルに対応する。プル・モードの場合、ＳＴＢは、関連コンテンツを保持している限り、メタ情報ファイルを記憶する。ファイルを次いで、後に使用して、プル・モードでピアを処理することが可能である。
【００６５】
ＳＴＢは、ＦＬＵＴＥプロトコルの「Ｅｎｄ−Ｏｆ−Ｔｒａｎｓｍｉｓｓｉｏｎ−Ｆｉｌｅ」フラグにより、ファイル配信の終了の時点を検出する。その時点から、各ＳＴＢは、ＦＤＴインスタンスのインテグリティを検証することが可能である（工程Ｓ’２、Ｓ’３）。
この検証後、各ＳＴＢは、ＦＤＴインスタンスを受信したかを示すメッセージをインデキシング・サーバに送信する（工程Ｓ’４、Ｓ’５）。
【００６６】
ＦＤＴインスタンスのインテグリティ・チェックが首尾良く行われた場合、ＳＴＢはＦＤＴインスタンスに関連付けられたファイルのブロックのインテグリティを検証し（工程Ｓ’６、Ｓ’７）、関連ファイルについて通知をインデキシング・サーバに送出する。この通知は、正しく受信されたブロックについての情報、及びファイル識別子を含む。インデキシング・サーバはこの情報を記憶し、このデータベースを更新する。欠落しているファイル部分について、以下に説明するように、ＳＴＢはファイル回復を行う。
【００６７】
ＦＤＴインスタンスのインテグリティ・チェックが首尾良く行われなかった場合、損なわれたＦＤＴインスタンスは、関連付けられたファイルのブロックのインテグリティをＳＴＢが検証することを可能にしない。この情報がＦＤＴインスタンスに含まれているからである。ＳＴＢは、損なわれたＦＤＴに続くファイルを記憶し、ファイル配信の終了の検出を待って、以下に説明するようなＦＤＴインスタンス修復を開始させる。ブロックを含むＦＬＵＴＥパケットは、ファイル毎に一意の、ＴＯＩと呼ばれる識別子を含む。ＦＤＴはこの識別子も含む。これは、ブロックをファイルに関連付けることを可能にする。
【００６８】
セッションの最後のＦＤＴインスタンスは、セッションの一部であるＦＤＴインスタンス全ての合計にわたって算出されるハッシュ・コードも含む。これは、フルＦＤＴのインテグリティの検証、及びＦＤＴインスタンスが欠落しているかを知ることを可能にする。これは、ＦＤＴインスタンスが一ＦＬＵＴＥパケットによってのみ配信されるケースを検出するために使用することが可能であり、このパケットは廃棄される。
【００６９】
ＳＴＢは、ＦＬＵＴＥパケット・ヘッダ内に設けられた「セッション終了」フラグにより、又はセッション・シグナリング・レコードに含まれるセッション終了日時により、セッションが終了する時点を検出する。
【００７０】
したがって、各ＳＴＢは、受信ＦＤＴインスタンス全ての和であるフルＦＤＴのインテグリティを検証し、次いで、フルＦＤＴが損なわれているか、又は一部のＦＤＴインスタンスが欠落しているかを検証する。フルＦＤＴが損なわれていない場合、その受信状態に応じて、特定のファイルの回復処理を起動させることが必要になり得る。一方、フルＦＤＴが、損なわれていることが明らかになった場合、ＳＴＢは、フルＦＤＴに対する要求を示すメッセージをインデキシング・サーバに送出し、その後、損なわれたファイルについて回復処理が必要かを検証する。
【００７１】
欠落したか、又は損傷したプッシュ・コンテンツは、上述の通常プル・モード段階内で回復することが可能である。
【００７２】
フルＦＤＴに対するインテグリティ・チェック又はＦＤＴインスタンスに対するインテグリティ・チェックが首尾良く行われなかった場合（Ｓ‘１０）、ＳＴＢは、フルＦＤＴ（又はＦＤＴインスタンス。図４に示す）に対する要求を示すメッセージをインデキシング・サーバに送出する
インデキシング・サーバはＦＬＵＴＥの知識を何ら有していないはずなので、以下が、フルＦＤＴ（又はＦＤＴインスタンス）を取り出すことを可能にするうえであてはまる。
【００７３】
ＳＴＢは、フルＦＤＴ及びＦＤＴインスタンスをメモリに特定期間の間（特に、新たなセッションにおける新たなコンテンツのダウンロードまで）、保持する。ＳＴＢは、このフルＦＤＴ（又はＦＤＴインスタンス）の正しい受信をインデキシング・サーバに通知する。
【００７４】
損なわれたフルＦＤＴ（又は損なわれたＦＤＴインスタンス）を有するＳＴＢは、インデキシング・サーバに問い合わせることが可能である（工程Ｓ’１１）。インデキシング・サーバは、損なわれていないバージョンを送出することができるピアのアドレスを供給する（工程Ｓ’１２、Ｓ’１３）。
【００７５】
ＳＴＢは、そのハッシュ値で、損なわれていないフルＦＤＴ（又は損なわれていないＦＤＴインスタンス）を取り出すことが可能である（工程Ｓ’１４、Ｓ’１５、Ｓ’１６、Ｓ’１７）。これは、そのインテグリティを検証する。これは、フルＦＤＴを解析して、落としたプッシュ・セッションのファイルを識別するか、又は損なわれたＦＤＴインスタンスを修復する。次いで、関連付けられたファイルのインテグリティを検証する。ＳＴＢは、欠落しているファイルを検出した場合、その欠落しているファイルのファイル回復を開始する。ＳＴＢは、損なわれたファイルを検出した場合、ブロック回復を開始する。
【００７６】
ＳＴＢから受信する通知において与えられる情報を使用して、インデキシング・サーバは連続してそのデータベースを更新する。何れの特定の時点でも、データ回復を必要とするＳＴＢを、欠落している情報を供給することができるピアＳＴＢと関係付けることができる。
【００７７】
ＳＤ＆Ｓレコード内のセッション通知によって与えられるセッション持続時間のおかげで、ＳＴＢには、プッシュ・セッションを落としたか否かが分かる。プッシュ・セッションを落としたＳＴＢは、ファイル名「ＦＤＴ」のフルＦＤＴについてインデキシング・サーバに問い合わせ、欠落しているファイルのファイル回復を進める。
【００７８】
ファイル配信セッションが実行中に接続するＳＴＢは、ＦＬＵＴＥマルチキャスト・セッションから、コンテンツの一部を得ることがなおできる。ＦＬＵＴＥセッションにおいて落としたファイルを得るために、セッションの終了を待って、「フル」ＦＤＴ回復を行い、ピアから、欠落しているファイルを得る。
【００７９】
ビデオ・ファイル・ダウンロードの環境では、プッシュ手法及びプル手法の組合せは、拡張配信モデルをもたらす。配信ポリシーは以下の通りであり得る。比較的人気の高い映画はプッシュ・モードで提案することが可能であり、需要がより少ない他の映画はプル・モードで提案することが可能である。プッシュ・モード映画の組が新たなもので置換されると、旧い組が、プル・モードで利用可能な映画の組に加わる。
【００８０】
一方、インデキシング・サーバは、インデキシング・サーバが収集することができる需要に関する統計により、プル・モードからプッシュ・モードに、又はその逆に特定の映画の配信モードを切り換えることが興味深い旨をコンテンツ・サーバに示し得る。
【００８１】
監視エンティティ又は管理エンティティの場合、インデキシング・サーバは、ファイル回復活動についての統計を収集する可能性を提供する。この情報は、配信ストラテジを動的に監視するために又は適合させるためにオペレータによって使用される。後者は、ＦＥＣの付加、又はプッシュ配信の追加セッションの計画を含み得る。他の動作は、ダウンロード・ファイル配信に割り当てられた帯域幅を変更することを含み得る。
【００８２】
本明細書の、「ｏｎｅ ｅｍｂｏｄｉｍｅｎｔ」又は「ａｎ ｅｍｂｏｄｉｍｅｎｔ」への言及は、本願の実施例に関して説明した特定の構成、構造又は特性が本発明の少なくとも一実現形態に含まれ得ることを意味している。明細書中の種々の箇所に「ｉｎ ｏｎｅ ｅｍｂｏｄｉｍｅｎｔ」の句が存在していることは、同じ実施例を必ずしも全て参照しておらず、他の実施例と必ずしも相互排他的でない別個の、又は別の実施例でない。
【００８３】
特許請求の範囲記載の参照符号は、例証の目的に過ぎず、特許請求の範囲記載の範囲を限定する効果はないものとする。
【技術分野】
【０００１】
本発明は、一般に、コンテンツ・ダウンロードに関し、特に、プル手法及びプッシュ手法の組合せの使用に関する。
【背景技術】
【０００２】
この部分は、本願明細書及び特許請求の範囲記載の本発明の種々の局面に関係し得る当該技術分野の種々の局面を本願明細書及び特許請求の範囲の読者に紹介することを意図している。本願明細書及び特許請求の範囲の記載は、本発明の種々の局面をより詳細に理解することを容易にするための背景情報を読者に与えるうえで有用であると思われる。よって、前述の記載はこれに照らして読まれるものとし、従来技術と認めたものとして読まれるものでない。
【０００３】
サーバと、複数の受信器との間のコンテンツの配信は、サーバと各受信器との間のポイント・ツー・ポイント接続、又はマルチポイント接続の設定を必要とする。ポイント・ツー・ポイント接続は、ユニキャスト手段においてコンテンツを各受信器に配信することを可能にし、ロバストな配信を提供する。これは、以降、プル・モードと呼ぶ。通常、クライアントはアクティブ・イニシエータである。しかし、受信器がかなりの数にのぼるので、接続全ての面倒な管理が必要になる。ネットワークを介したトラフィックを劇的に増加させることもできる。マルチキャスト配信は、よりロバストでない配信で、より少ないネットワーク負荷をもたらす。これは以下ではプッシュ・モードと呼ぶ。
【０００４】
サーバを管理するサービス・オペレータは、受信器の挙動を正確に予測することが可能でない。プッシュ・コンテンツ配信セッションでは、受信器は、受信器がプッシュ配信中にスイッチ・オフされること、受信器が、プッシュ配信が実行中にオンにされること、予約済帯域幅が全て、プッシュ配信に利用可能な訳でないこと、例えば、ＳＴＢユーザが、別の番組を記録している間に一番組を視聴すること、受信器は、プッシュ配信の際に記憶容量が不足していること、受信器はプッシュ配信の際にフルＣＰＵを使用していること、ネットワークはマルチキャスト・トラフィックを処理することが可能でないこと等の理由で、完全な、又は部分的なダウンロードから除外され得る。帯域幅を最適にするために、オペレータは、プッシュ・セッションの維持又は停止を選ばなければならないことがあり得る。プッシュ・セッションの停止は、オペレータがネットワークを大量のトラフックから解放することを可能にし、欠落したコンテンツを有する受信器は回復モードを使用して取り出すことが可能である。回復手法は欧州特許出願第０６２９１４６４．３号明細書に規定されている。一方、プル・モードでは、オペレータは、コンテンツに対するピーク需要に直面しなければならないことがあり得る。その場合、プル・モ―ドの代わりにプッシュ・モードでこのコンテンツをマルチキャストすることにより、オペレータが展開遅延、及びネットワーク帯域幅の使用を最適にすることにおいてより効率的であり得る。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明は、プル・モードとプッシュ・モードとの間で効率的に切り換える方法に関する。
【課題を解決するための手段】
【０００６】
この目的で、本発明は、第１の端末、少なくとも第２の端末、及びコンテンツ・サーバを備える通信システムにおいてコンテンツをダウンロードする方法に関する。方法は、第１の端末のレベルで、コンテンツ・サーバ若しくは少なくとも第２の端末からプル・モードにおいて、又はコンテンツ・サーバからプッシュ・モードにおいてコンテンツをダウンロードする工程と、コンテンツを連続してダウンロードするためにモード間でシームレスに切り換える工程とを含む。
【０００７】
この意味合いでは、「シームレスに」は、何れの他の情報の要求を必要とすることもなく、一方モードから他方モードに端末が連続して切り換わることを意味している。
【０００８】
一実施例によれば、方法は、プッシュ・モードにおいてコンテンツをダウンロードする工程と、プッシュ・モードがコンテンツ・サーバにおいて停止した場合、プル・モードでコンテンツをダウンロードし続ける工程とを含む。
【０００９】
オペレータがプッシュ・セッションを停止すると、端末は、割り込みがあまり多くない状態でダウンロードし続ける。プル・ダウンロード・モードに切り換え、プル・ダウンロード・モードを管理するために十分な情報をプッシュ・セッション中に得ている。
【００１０】
別の実施例によれば、方法は、プル・モードにおいてコンテンツをダウンロードする工程と、プッシュ・モードがコンテンツ・サーバにおいて開始した場合、プッシュ・モードでコンテンツをダウンロードし続ける工程とを含む。
【００１１】
一実施例では、方法は、ＦＬＵＴＥプロトコルにより、セッション配信においてプッシュ・コンテンツを受信する工程と、セッション配信中に、ファイル配信テーブルＦＤＴにおいて情報を受信し、プル・モードに切り換えることが可能になる工程とを含む。
【００１２】
ＦＤＴは、プル・モードへのシームレスな切り換えに必要な更なる情報を含む。プッシュ・モードが停止すると、端末は、何れの別の情報も取り出さなくてよい。プル・モードに切り換えるためのＦＤＴを備えた適切な情報を既に受信している。
【００１３】
一実施例によれば、方法は、ＦＤＴインスタンスのインテグリティを検証する工程と、ＦＤＴインスタンスが首尾良く受信されているか否かをインデキシング・サーバに示し、ＦＤＴインスタンスに関連付けられたファイルが首尾良く受信されているか否かをインデキシング・サーバに示す工程とを含む。
【００１４】
一実施例によれば、方法は、損なわれたＦＤＴインスタンスを検出すると、ファイル配信の最後を待つ工程と、プル・モードにおいてＦＤＴインスタンス修復を行う工程とを含む。
【００１５】
一実施例によれば、方法は、損なわれたフルＦＤＴを検出すると、セッション配信の最後を待つ工程と、プル・モードにおいてフルＦＤＴの修復を行う工程とを含む。
【００１６】
一実施例によれば、方法は、ピアツーピア・プロトコルに応じてプル・コンテンツを受信する工程と、プッシュ・モードへの切り換えを可能にする情報を含むピアツーピア・メタ情報ファイルを受信する工程とを含む。
【００１７】
本発明は、プッシュ・モードにおいてコンテンツをダウンロードする手段と、プル・モードにおいてコンテンツをダウンロードする手段と、一方モードから他方モードにシームレスに切り換える手段とに関する。
【００１８】
本発明の別の目的は、プログラムがコンピュータ上で実行されると、本発明による方法の工程を実行するためのプログラム・コード命令を含むコンピュータ・プログラム・プロダクトである。「コンピュータ・プログラム・プロダクト」は、ディスケット（登録商標）やカセットなどの、プログラムを記憶空間が含むことを含むのみならず、電気信号又は光信号などの信号も含み得るコンピュータ・プログラム・サポートを意味している。
【図面の簡単な説明】
【００１９】
【図１】実施例に準拠したシステムを示すブロック図である。
【図２】実施例による端末を表す図である。
【図３】プル・モードを示すフローチャートである。
【図４】プッシュ・モード及びプル・モードの組合せを示すフローチャートである。
【発明を実施するための形態】
【００２０】
本願開示の実施例の範囲と範囲が同等の特定の局面を以下に記載する。前述の局面は、本発明がとり得る特定の形態の簡単な要約を本明細書及び特許請求の範囲の読者に提供するためのみに提示しており、前述の局面は、本発明の範囲を限定することを意図するものでない。実際に、本発明は、以下に記載されていないことがあり得る種々の局面を包含し得る。
【００２１】
本発明は、添付図面を参照して、如何なる方法においても限定的でなく、以下の実施例及び実行例によってよりよく理解され、例証されるであろう。
【実施例】
【００２２】
図１及び図２では、図示されたブロックは、純粋に機能エンティティであり、これは、物理的に別個のエンティティに必ずしも対応しない。すなわち、ソフトウェアの形態で開発されるか、１つ又は複数の集積回路で実現することが可能である。
【００２３】
図１は、コンテンツを配信する実施例による通信システム１００のアーキテクチャを表す。端末１、２、３はクライアント・アプリケーションを有する。特に、これらは、セットトップボックス（ＳＴＢ）機能を有する。以下実施例では、端末はＳＴＢであるが、実施例は前述の端末に限定されるものでない。コンテンツ・サーバからデータをダウンロードするためのクライアント・アプリケーションを備える装置に適用可能である。
【００２４】
端末は、プッシュ・モードでコンテンツをダウンロードする手段、及びプル・モードでコンテンツをダウンロードする手段も備える。これは、以下に説明するプル機能及びプッシュ機能を行う。
【００２５】
システムは、プッシュ・コンテンツ・サーバ５及びプル・コンテンツ・サーバ８を含む。プル・コンテンツ・サーバは、プル・モードにおいてコンテンツを配信するよう適合される。これは、複数のクライアントとのポイント・ツー・ポイント接続を設定する手段を備える。プッシュ・コンテンツ・サーバは、プッシュ・モードにおいてコンテンツを配信するよう適合される。当然、前述のサーバは同じ装置に含まれ得る。
【００２６】
インデキシング・サーバ６の役割は、ピアＳＴＢを互いに関係付けて修復を完了するか、又はコンテンツを取り出す。インデキシング・サーバの役割は、ファイル又はファイルの一部を回復したいピアを、欠落している情報を供給することができるピアと関係付けることである。インデキシング・サーバは、何れのコンテンツ・ファイルも記憶せず、ファイルの場所についての情報を記憶するための集中化されたインデクスとしてふるまう。プル・プロトコルは、コンテンツのダウンロード・ステータスについて各ＳＴＢによって逐次通知される。上記実施例では、システムは一インデキシング・サーバのみを備える。ネットワークは、いくつかのインデキシング・サーバに、例えば、地域毎、又はコンテンツ・タイプ毎にアクセスを最適化させることが可能である。同じインデキシング・サーバが、プッシュ・モード環境において、かつ、プル・モード環境において使用される。
【００２７】
以下ＳＤ＆Ｓと表すサービス・ディスカバリ・サーバ７は、ＥＴＳＩ ＴＳ１０２ ０３４ Ｖ１．２．１ （２００６−０９） Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ （ＤＶＢ）， Ｔｒａｎｓｐｏｒｔ ｏｆ ＭＰＥＧ−２ Ｂａｓｅｄ ＤＶＢ Ｓｅｒｖｉｃｅｓ ｏｖｅｒ ＩＰ Ｂａｓｅｄ Ｍｅｔｗｏｒｋｓ標準に示されたようなサービス・ディスカバリ及び選択手法を行うよう適合される。
【００２８】
上記実施例では、同じＳＤ＆Ｓサーバが、ＰＵＳＨモード環境、及びＰＵＬＬモード環境において使用される。
【００２９】
図２は、実施例による端末の構築ブロックを表す。端末は、記憶手段１．１と、通信手段１．２と、処理手段１．３と、内部バス１．４とを備える。記憶手段は、端末がプッシュ・モード又はプル・モードにおいてファイルをダウンロードすることを可能にするプログラムを記憶することが意図される。よって、端末は、プッシュ・ダウンロード手段１．６とプル・ダウンロード手段１．５とを備える。これは、一方モードから他方モードに切り換える手段１．７を備える。
【００３０】
次にプル手法を説明する。これは、Ｐ２Ｐと表すピアツーピア・ストラテジに基づく。
【００３１】
プル手法を実施するために、端末はまず、インデキシング・サーバ・アドレス・ディスカバリ段階を行う。ＳＴＢは、ダウンロードに利用可能なコンテンツのカタログをブラウジングすることにより、ダウンロードのためのコンテンツを見つける。カタログのアドレスは、ＥＴＳＩ ＴＳ１０２ ０３４ Ｖ１．２．１ （２００６−０９）及びＥＴＳＩ ＴＳ１０２ ５３９ Ｖ１．１．１， Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ （ＤＶＢ）； Ｃａｒｒｉａｇｅ ｏｆ Ｂｒｏａｄｂａｎｄ Ｃｏｎｔｅｎｔ Ｇｕｉｄｅ （ＢＣＧ） ｉｎｆｏｒｍａｔｉｏｎ ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ （ＩＰ）（ＤＶＢ−ＩＰの意味合いでコンテンツ・ガイドの伝送及びシグナリングを説明している）を使用して見つける。端末は、カタログにおけるインデキシング・サーバのアドレスを見つける。当然、インデキシング・サーバのアドレスは、ＤＶＢ―ＩＰ／ＳＤ＆Ｓシグナリングによって配信されるコンテンツ・ダウンロード提供レコードなどの他の手段によって見つけることが可能である。
【００３２】
大容量コンテンツをダウンロードする能力を向上させるために、コンテンツの各ファイルは、より小容量のブロックに分割される。ピアは次いで、コンテンツのブロックを受信し、検証し、次いで、コンテンツを完全に又は部分的に受信する前に前述のブロックを交換することができる。ハッシュ・コードは各ブロックにわたって算出される。表１に示すようなメタ情報はコンテンツ・サーバ内のファイルとして記憶される。メタ情報は、ピアツーピアにおけるファイル交換を行うために必要な情報全てを含む。ハッシング操作をコンテンツ・サーバによって行うことが可能である。
【００３３】
以下の表は、上記実施例によるコンテンツ・メタ情報を表す。ＴＳＩフィールド及びＴＯＩフィールドは、ＦＬＵＴＥプロトコルにおいて規定され、任意である。これらはここでは、プル・モードとプッシュ・モードとの間のシームレスなスイッチングをサポートするために使用される。Ｃｏｎｔｅｎｔ−Ｂｌｏｃｋ−Ｌｅｎｇｔｈフィールド、Ｃｏｎｔｅｎｔ−Ｂｌｏｃｋ−Ｄｉｇｅｓｔｓフィールド、Ｆｉｌｅ−Ｎａｍｅフィールド、Ｆｉｌｅ−Ｌｅｎｇｔｈフィールド、Ｆｉｌｅ−Ｄｉｇｅｓｔフィールド、Ｆｉｌｅ−Ｂｌｏｃｋ−Ｌｅｎｇｔｈフィールド、及びＦｉｌｅ−Ｂｌｏｃｋ−Ｄｉｇｅｓｔｓフィールドは、Ｐ２Ｐプロトコルに必要な最小のメタ情報である。
【００３４】
【表１】
Ｍｅｔａ−ｌｎｆｏ−Ｄｉｇｅｓｔフィールドは、ＲＳＡシグネチャを送信して、メタ情報ファイルを認証することを可能にするために使用することが可能である。
【００３５】
ファイル・ダウンロードの方法はその場合、図３に表すように、以下の通りである。
【００３６】
工程Ｓ１。ＳＴＢ１は、選ばれたコンテンツに対する要求をインデキシング・サーバに送出する。
【００３７】
工程Ｓ２。インデキシング・サーバは、コンテンツのメタ情報を供給することができるピアＳＴＢ２のアドレスでＳＴＢに応答する。当然、インデキシング・サーバはいくつかのピアのアドレスを供給することができる。
【００３８】
ＳＴＢ１は、示されたピアとの接続を起動させる（工程Ｓ３）。これは、工程Ｓ４でメタ情報ファイルを取り出し、工程Ｓ５でこのインテグリティを検証し、工程Ｓ６でこのファイルを記憶し、メタ情報の受信をインデキシング・サーバに通知する。関連コンテンツが削除されるまで、ＳＴＢ１はこのファイルをメモリに保つ。
【００３９】
このメタ情報ファイルがあれば、ＳＴＢは、他のピアに、任意のバイト範囲のブロックを要求し、受信データのインテグリティを検証することが可能である。ＳＴＢは、メタ情報ファイルを受信した後、１つ若しくは複数のファイル、又は１つ若しくは複数のファイルのブロックをダウンロードすることが可能である。
【００４０】
ＳＴＢは、工程７で、インデキシング・サーバに一ブロックを要求する。当然、ＳＴＢは同時にいくつかのブロックを要求することができる。これはブロック番号及びファイル識別子（ファイル名であり得る）を送出する。ファイルＩＤは、いくつかのファイルが同時にダウンロードされる場合に必要である。
【００４１】
インデキシング・サーバは、工程８で、コンテンツのブロックを供給することができるピアのアドレスを戻す。
【００４２】
ＳＴＢは、示されたピアとの接続を起動させ（工程９）、コンテンツ・ブロックを取り出し（工程１０）、及びそのインテグリティを検証する（工程１１）。
【００４３】
ＳＴＢは、工程１２で、成功又は失敗の点でブロック・ダウンロードのステータスをインデキシング・サーバに示す。
【００４４】
クライアントは、完全なコンテンツがダウンロードされるまで、他のブロックに対する要求を、インデキシング・サーバに送出することができる。
【００４５】
ＳＴＢから受信する通知に表される情報を使用して、インデキシング・サーバは常にそのデータベースを更新する。何れの特定の時点でも、データ回復を必要とするＳＴＢを、欠落している情報を供給することができるピアＳＴＢと関係付けることができる。
【００４６】
ＴＳＩフィールド及びＴＯＩフィールドのおかげで、端末は、ファイルをダウンロードするためにプッシュ・モードにシームレスに切り換えることができる。
【００４７】
図３では、コンテンツのブロックを供給するピアは、コンテンツのメタ情報を供給するピアと同じである。当然、これは別のピアであり得る。
【００４８】
更に、インデキシング・サーバは、コンテンツのブロックを供給することができる２つ以上のピアのアドレスを返すことが可能である。ＳＴＢは次いで、場合によっては、２つ以上のピアに接続する。
【００４９】
インデキシング・サーバは、ピアＳＴＢの何れによっても、要求されたコンテンツ又はメタ情報を供給することが可能でない情報を有し得る。
【００５０】
その場合、コンテンツを直接配信することができるコンテンツ・サーバのアドレスを供給することが可能である。コンテンツに対する要求でのコンテンツ・サーバのフラッドを避けるために、インデキシング・サーバは、一ピアＳＴＢプールのみを処理し得る。その他のＳＴＢを保留にし、後に、コンテンツを首尾良くダウンロードしたピアＳＴＢプールのアドレスを示す。
【００５１】
あるいは、インデキシング・サーバは、別のインデキシング・サーバ又は「超」インデキシング・サーバに要求をアドレス指定することが可能である。要求された情報を見つけた場合、インデキシング・サーバは、そのデータベースに情報を記憶し、ＳＴＢに肯定的に応答する。
【００５２】
インデキシング・サーバは同じコンテンツに対していくつかのアドレスを供給し得る。コンテンツはいくつかのピアＳＴＢにわたって分散させることができる。すなわち、ピアＳＴＢの何れも、コンテンツ全部を有する訳でないが、コンテンツ合計を、ピアＳＴＢ上に常駐している部分コンテンツから構成することが可能である。インデキシング・サーバは、ダウンロード速度が低すぎるか、又はピアが利用可能でないことが証明された場合、別のピアからのコンテンツを取り出す機会をＳＴＢに与えるために要求コンテンツを全部又は部分的に供給することが可能な別のピアＳＴＢを示すことも可能である。
【００５３】
一方、インデキシング・サーバには、例えば、ピアからの首尾良く行われたダウンロードの数にわたる統計に基づいたインテリジェントなピア選択を可能にするアルゴリズムが供給され得る。
【００５４】
次に、プッシュ配信の方法を説明する。プッシュ配信は、ＲＦＣ３９２６に規定されたような、ＦＬＵＴＥと表す単方向伝送プロトコルによるファイル配信に基づく。プッシュ配信は、上記ピアツーピア手法を使用する回復機構を備える。
【００５５】
ＦＬＵＴＥプロトコルは、マルチキャスト・オブジェクトの伝送及び関連付けられた記述子表を規定する。これは、現在のセッションにおいて送信されなければならないファイルの情報を含む、ＦＤＴと表すファイル配信テーブルを規定する。ＦＬＵＴＥプロトコルは、コンテンツ・サーバからのＦＤＴをマルチキャスト・モードにおいて全てのＳＴＢに送信する。ＦＬＵＴＥは、いくつかの伝送モード（１つの完全なＦＤＴ及びそれに続く複数のファイル、又は一連のＦＤＴインスタンス（中間ＦＤＴ）及びそれに続く関連ファイルなど）を規定する。後者は、膨大な容量のビデオ・ファイルの伝送に特に適しており、セッションの最後に達する前に、オブジェクト又はファイルが正しく受信されたかを受信器が検証することができることを可能にする。前者の伝送モードは、小容量ファイルが伝送される環境において好都合である。フルＦＤＴは、同じセッションのＦＤＴインスタンス全てから構築される。
【００５６】
実施例では、ＦＬＵＴＥ ＦＤＴは、以下の表２に示すような、（ブロック長及びブロック・ハッシュを備える）特定のピアツーピア・メタ情報を有する。その場合、コンテンツ・ダウンロード中に、一方のプロトコルから他方のプロトコルに切り換えることが可能である。実際に、ＦＬＵＴＥマルチキャスト・プッシュ・セッションの最後に完全にコンテンツをダウンロードしなかった受信器は、ピアツーピア・プル・モードにシームレスに切り換え、コンテンツの欠落ブロックが厳密に分かることを可能にする、ＦＤＴにおける情報によって、欠落ブロックをダウンロードする。同様に、ピアツーピア・プル・モードにより、コンテンツをダウンロードし始めた受信器は、プッシュ・モードでファイルの欠落ブロックを回復するために必要な情報を受信器に与えるＦＤＴを使用してプッシュ・モードにシームレスに切り換えることが可能である。
【００５７】
以下の表は、実施例により、Ｐ２Ｐメタ情報を含むＦＬＵＴＥファイル配信表を表す。
【００５８】
【表２】
Ｃｏｎｔｅｎｔ−Ｂｌｏｃｋ−Ｌｅｎｇｔｈフィールド、Ｃｏｎｔｅｎｔ−Ｂｌｏｃｋ−Ｄｉｇｅｓｔｓフィールド、Ｆｉｌｅ−Ｎａｍｅフィールド、Ｆｉｌｅ−Ｌｅｎｇｔｈフィールド、Ｆｉｌｅ−Ｄｉｇｅｓｔフィールド、Ｆｉｌｅ−Ｂｌｏｃｋ−Ｌｅｎｇｔｈフィールド、及びＦｉｌｅ−Ｂｌｏｃｋ−Ｄｉｇｅｓｔｓフィールドは、Ｐ２Ｐプロトコルに必要な最小のメタ情報である。ファイルは、いくつかのブロックに切断される。
【００５９】
Ｃｏｍｐｌｅｔｅ−ＦＤＴ−Ｄｉｇｅｓｔフィールドは、ＲＳＡシグネチャを送信して、フルＦＤＴを認証することを可能にするために使用することが可能である。
【００６０】
プッシュ手法でコンテンツをダウンロードするために、クライアントは、プッシュ・コンテンツ・ダウンロード・セッション・ディスカバリ段階を行う。クライアントＳＴＢはプッシュ・ダウンロード・オファーに加入する。加入の一部として、サービスがＤＶＢＩＰ／ＳＤ＆Ｓ手法を介して、ＳＤ＆Ｓサーバにより、サービスのシグナリングが伝送される配信アドレスを得る。ＳＴＢは次いで、専用マルチキャスト・アドレスにリッスンする。これは、ＤＶＢ−ＩＰコンテンツ・ダウンロード・オファー・レコードを見つける。
【００６１】
このコンテンツ・ダウンロード・オファー・レコードにおいて、コンテンツ・ダウンロード・セッションの開始及び終了日時、並びに、コンテンツが配信されるポート、マルチキャスト・アドレス、及び、依存するインデキシング・サーバのアドレスなどの他の情報を見つける。上記実施例によるＳＤ＆Ｓレコード・ファイルは以下の表３に示す。
【００６２】
【表３】
ＡｎｎｏｕｎｃｅｍｅｎｔＤｉｇｅｓｔフィールドは、ＲＳＡシグネチャを送信して、通知を認証することを可能にするために使用することが可能である。
【００６３】
図４に示すように、ディスカバリ段階において獲得された情報を使用して、ＳＴＢは、プッシュ・セッション・コンテンツが配信されるマルチキャスト・アドレスにリッスンする（工程Ｓ’１）。
【００６４】
各ＦＤＴインスタンスは、それ自身のインテグリティ、及びそれと関連付けられたファイルのブロックのインテグリティを検証することを可能にするいくつかのハッシュ・コードを含む。この情報は、プル・モードについて説明したようなメタ情報ファイルに対応する。プル・モードの場合、ＳＴＢは、関連コンテンツを保持している限り、メタ情報ファイルを記憶する。ファイルを次いで、後に使用して、プル・モードでピアを処理することが可能である。
【００６５】
ＳＴＢは、ＦＬＵＴＥプロトコルの「Ｅｎｄ−Ｏｆ−Ｔｒａｎｓｍｉｓｓｉｏｎ−Ｆｉｌｅ」フラグにより、ファイル配信の終了の時点を検出する。その時点から、各ＳＴＢは、ＦＤＴインスタンスのインテグリティを検証することが可能である（工程Ｓ’２、Ｓ’３）。
この検証後、各ＳＴＢは、ＦＤＴインスタンスを受信したかを示すメッセージをインデキシング・サーバに送信する（工程Ｓ’４、Ｓ’５）。
【００６６】
ＦＤＴインスタンスのインテグリティ・チェックが首尾良く行われた場合、ＳＴＢはＦＤＴインスタンスに関連付けられたファイルのブロックのインテグリティを検証し（工程Ｓ’６、Ｓ’７）、関連ファイルについて通知をインデキシング・サーバに送出する。この通知は、正しく受信されたブロックについての情報、及びファイル識別子を含む。インデキシング・サーバはこの情報を記憶し、このデータベースを更新する。欠落しているファイル部分について、以下に説明するように、ＳＴＢはファイル回復を行う。
【００６７】
ＦＤＴインスタンスのインテグリティ・チェックが首尾良く行われなかった場合、損なわれたＦＤＴインスタンスは、関連付けられたファイルのブロックのインテグリティをＳＴＢが検証することを可能にしない。この情報がＦＤＴインスタンスに含まれているからである。ＳＴＢは、損なわれたＦＤＴに続くファイルを記憶し、ファイル配信の終了の検出を待って、以下に説明するようなＦＤＴインスタンス修復を開始させる。ブロックを含むＦＬＵＴＥパケットは、ファイル毎に一意の、ＴＯＩと呼ばれる識別子を含む。ＦＤＴはこの識別子も含む。これは、ブロックをファイルに関連付けることを可能にする。
【００６８】
セッションの最後のＦＤＴインスタンスは、セッションの一部であるＦＤＴインスタンス全ての合計にわたって算出されるハッシュ・コードも含む。これは、フルＦＤＴのインテグリティの検証、及びＦＤＴインスタンスが欠落しているかを知ることを可能にする。これは、ＦＤＴインスタンスが一ＦＬＵＴＥパケットによってのみ配信されるケースを検出するために使用することが可能であり、このパケットは廃棄される。
【００６９】
ＳＴＢは、ＦＬＵＴＥパケット・ヘッダ内に設けられた「セッション終了」フラグにより、又はセッション・シグナリング・レコードに含まれるセッション終了日時により、セッションが終了する時点を検出する。
【００７０】
したがって、各ＳＴＢは、受信ＦＤＴインスタンス全ての和であるフルＦＤＴのインテグリティを検証し、次いで、フルＦＤＴが損なわれているか、又は一部のＦＤＴインスタンスが欠落しているかを検証する。フルＦＤＴが損なわれていない場合、その受信状態に応じて、特定のファイルの回復処理を起動させることが必要になり得る。一方、フルＦＤＴが、損なわれていることが明らかになった場合、ＳＴＢは、フルＦＤＴに対する要求を示すメッセージをインデキシング・サーバに送出し、その後、損なわれたファイルについて回復処理が必要かを検証する。
【００７１】
欠落したか、又は損傷したプッシュ・コンテンツは、上述の通常プル・モード段階内で回復することが可能である。
【００７２】
フルＦＤＴに対するインテグリティ・チェック又はＦＤＴインスタンスに対するインテグリティ・チェックが首尾良く行われなかった場合（Ｓ‘１０）、ＳＴＢは、フルＦＤＴ（又はＦＤＴインスタンス。図４に示す）に対する要求を示すメッセージをインデキシング・サーバに送出する
インデキシング・サーバはＦＬＵＴＥの知識を何ら有していないはずなので、以下が、フルＦＤＴ（又はＦＤＴインスタンス）を取り出すことを可能にするうえであてはまる。
【００７３】
ＳＴＢは、フルＦＤＴ及びＦＤＴインスタンスをメモリに特定期間の間（特に、新たなセッションにおける新たなコンテンツのダウンロードまで）、保持する。ＳＴＢは、このフルＦＤＴ（又はＦＤＴインスタンス）の正しい受信をインデキシング・サーバに通知する。
【００７４】
損なわれたフルＦＤＴ（又は損なわれたＦＤＴインスタンス）を有するＳＴＢは、インデキシング・サーバに問い合わせることが可能である（工程Ｓ’１１）。インデキシング・サーバは、損なわれていないバージョンを送出することができるピアのアドレスを供給する（工程Ｓ’１２、Ｓ’１３）。
【００７５】
ＳＴＢは、そのハッシュ値で、損なわれていないフルＦＤＴ（又は損なわれていないＦＤＴインスタンス）を取り出すことが可能である（工程Ｓ’１４、Ｓ’１５、Ｓ’１６、Ｓ’１７）。これは、そのインテグリティを検証する。これは、フルＦＤＴを解析して、落としたプッシュ・セッションのファイルを識別するか、又は損なわれたＦＤＴインスタンスを修復する。次いで、関連付けられたファイルのインテグリティを検証する。ＳＴＢは、欠落しているファイルを検出した場合、その欠落しているファイルのファイル回復を開始する。ＳＴＢは、損なわれたファイルを検出した場合、ブロック回復を開始する。
【００７６】
ＳＴＢから受信する通知において与えられる情報を使用して、インデキシング・サーバは連続してそのデータベースを更新する。何れの特定の時点でも、データ回復を必要とするＳＴＢを、欠落している情報を供給することができるピアＳＴＢと関係付けることができる。
【００７７】
ＳＤ＆Ｓレコード内のセッション通知によって与えられるセッション持続時間のおかげで、ＳＴＢには、プッシュ・セッションを落としたか否かが分かる。プッシュ・セッションを落としたＳＴＢは、ファイル名「ＦＤＴ」のフルＦＤＴについてインデキシング・サーバに問い合わせ、欠落しているファイルのファイル回復を進める。
【００７８】
ファイル配信セッションが実行中に接続するＳＴＢは、ＦＬＵＴＥマルチキャスト・セッションから、コンテンツの一部を得ることがなおできる。ＦＬＵＴＥセッションにおいて落としたファイルを得るために、セッションの終了を待って、「フル」ＦＤＴ回復を行い、ピアから、欠落しているファイルを得る。
【００７９】
ビデオ・ファイル・ダウンロードの環境では、プッシュ手法及びプル手法の組合せは、拡張配信モデルをもたらす。配信ポリシーは以下の通りであり得る。比較的人気の高い映画はプッシュ・モードで提案することが可能であり、需要がより少ない他の映画はプル・モードで提案することが可能である。プッシュ・モード映画の組が新たなもので置換されると、旧い組が、プル・モードで利用可能な映画の組に加わる。
【００８０】
一方、インデキシング・サーバは、インデキシング・サーバが収集することができる需要に関する統計により、プル・モードからプッシュ・モードに、又はその逆に特定の映画の配信モードを切り換えることが興味深い旨をコンテンツ・サーバに示し得る。
【００８１】
監視エンティティ又は管理エンティティの場合、インデキシング・サーバは、ファイル回復活動についての統計を収集する可能性を提供する。この情報は、配信ストラテジを動的に監視するために又は適合させるためにオペレータによって使用される。後者は、ＦＥＣの付加、又はプッシュ配信の追加セッションの計画を含み得る。他の動作は、ダウンロード・ファイル配信に割り当てられた帯域幅を変更することを含み得る。
【００８２】
本明細書の、「ｏｎｅ ｅｍｂｏｄｉｍｅｎｔ」又は「ａｎ ｅｍｂｏｄｉｍｅｎｔ」への言及は、本願の実施例に関して説明した特定の構成、構造又は特性が本発明の少なくとも一実現形態に含まれ得ることを意味している。明細書中の種々の箇所に「ｉｎ ｏｎｅ ｅｍｂｏｄｉｍｅｎｔ」の句が存在していることは、同じ実施例を必ずしも全て参照しておらず、他の実施例と必ずしも相互排他的でない別個の、又は別の実施例でない。
【００８３】
特許請求の範囲記載の参照符号は、例証の目的に過ぎず、特許請求の範囲記載の範囲を限定する効果はないものとする。
【特許請求の範囲】
【請求項１】
第１の端末と、少なくとも第２の端末と、コンテンツ・サーバとを備える通信システムにおいてコンテンツをダウンロードする方法であって、前記第１の端末のレベルで、
前記コンテンツ・サーバ若しくは少なくとも前記第２の端末からプル・モードにおいて、又は前記コンテンツ・サーバからプッシュ・モードにおいてコンテンツをダウンロードする工程と、
前記コンテンツの連続したダウンロードのためにモード間でシームレスに切り換える工程とを含む方法。
【請求項２】
請求項１記載の方法であって、
コンテンツをプッシュ・モードにおいてダウンロードする工程と、
前記プッシュ・モードが前記コンテンツ・サーバにおいて停止すると前記コンテンツをプル・モードにおいて連続してダウンロードする工程とを含む方法。
【請求項３】
請求項１記載の方法であって、
コンテンツをプル・モードにおいてダウンロードする工程と、
前記プッシュ・モードが前記コンテンツ・サーバにおいて開始すると前記コンテンツをプッシュ・モードにおいて連続してダウンロードする工程とを含む方法。
【請求項４】
請求項２記載の方法であって、
ＦＬＵＴＥプロトコルにより、セッション配信においてプッシュ・コンテンツを受信する工程と、
前記セッション配信中に、ファイル配信テーブルＦＤＴにおいて情報を受信し、プル・モードに切り換えることが可能になる工程とを含む方法。
【請求項５】
請求項４記載の方法であって、
ＦＤＴインスタンスのインテグリティを検証する工程と、
前記ＦＤＴインスタンスが首尾良く受信されているか否かをインデキシング・サーバに示す工程と、
前記ＦＤＴインスタンスに関連付けられたファイルが首尾良く受信されているか否かを前記インデキシング・サーバに示す工程とを含む方法。
【請求項６】
請求項５記載の方法であって、損なわれたＦＤＴインスタンスを検出すると、
前記ファイル配信の終了を待つ工程と、
プル・モードにおいてＦＤＴインスタンス修復を行う工程とを含む方法。
【請求項７】
請求項５記載の方法であって、損なわれたフルＦＤＴを検出すると、
前記セッション配信の終了を待つ工程と、
プル・モードにおいてフルＦＤＴ修復を行う工程とを含む方法。
【請求項８】
請求項３記載の方法であって、
ピアツーピア・プロトコルにより、プル・コンテンツを受信する工程と、
プッシュ・モードへの切り換えを可能にする情報を有するピアツーピア・メタ情報ファイルを受信する工程とを含む方法。
【請求項９】
端末であって、
コンテンツをプッシュ・モードにおいてダウンロードする手段と、
コンテンツをプル・モードにおいてダウンロードする手段と、
一方モードから他方モードにシームレスに切り換える手段とを備える端末。
【請求項１】
第１の端末と、少なくとも第２の端末と、コンテンツ・サーバとを備える通信システムにおいてコンテンツをダウンロードする方法であって、前記第１の端末のレベルで、
前記コンテンツ・サーバ若しくは少なくとも前記第２の端末からプル・モードにおいて、又は前記コンテンツ・サーバからプッシュ・モードにおいてコンテンツをダウンロードする工程と、
前記コンテンツの連続したダウンロードのためにモード間でシームレスに切り換える工程とを含む方法。
【請求項２】
請求項１記載の方法であって、
コンテンツをプッシュ・モードにおいてダウンロードする工程と、
前記プッシュ・モードが前記コンテンツ・サーバにおいて停止すると前記コンテンツをプル・モードにおいて連続してダウンロードする工程とを含む方法。
【請求項３】
請求項１記載の方法であって、
コンテンツをプル・モードにおいてダウンロードする工程と、
前記プッシュ・モードが前記コンテンツ・サーバにおいて開始すると前記コンテンツをプッシュ・モードにおいて連続してダウンロードする工程とを含む方法。
【請求項４】
請求項２記載の方法であって、
ＦＬＵＴＥプロトコルにより、セッション配信においてプッシュ・コンテンツを受信する工程と、
前記セッション配信中に、ファイル配信テーブルＦＤＴにおいて情報を受信し、プル・モードに切り換えることが可能になる工程とを含む方法。
【請求項５】
請求項４記載の方法であって、
ＦＤＴインスタンスのインテグリティを検証する工程と、
前記ＦＤＴインスタンスが首尾良く受信されているか否かをインデキシング・サーバに示す工程と、
前記ＦＤＴインスタンスに関連付けられたファイルが首尾良く受信されているか否かを前記インデキシング・サーバに示す工程とを含む方法。
【請求項６】
請求項５記載の方法であって、損なわれたＦＤＴインスタンスを検出すると、
前記ファイル配信の終了を待つ工程と、
プル・モードにおいてＦＤＴインスタンス修復を行う工程とを含む方法。
【請求項７】
請求項５記載の方法であって、損なわれたフルＦＤＴを検出すると、
前記セッション配信の終了を待つ工程と、
プル・モードにおいてフルＦＤＴ修復を行う工程とを含む方法。
【請求項８】
請求項３記載の方法であって、
ピアツーピア・プロトコルにより、プル・コンテンツを受信する工程と、
プッシュ・モードへの切り換えを可能にする情報を有するピアツーピア・メタ情報ファイルを受信する工程とを含む方法。
【請求項９】
端末であって、
コンテンツをプッシュ・モードにおいてダウンロードする手段と、
コンテンツをプル・モードにおいてダウンロードする手段と、
一方モードから他方モードにシームレスに切り換える手段とを備える端末。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公表番号】特表２０１０−５１５９８８（Ｐ２０１０−５１５９８８Ａ）
【公表日】平成２２年５月１３日（２０１０．５．１３）
【国際特許分類】
【出願番号】特願２００９−５４５１８７（Ｐ２００９−５４５１８７）
【出願日】平成２０年１月１１日（２００８．１．１１）
【国際出願番号】ＰＣＴ／ＥＰ２００８／０５０２９１
【国際公開番号】ＷＯ２００８／０８４０９６
【国際公開日】平成２０年７月１７日（２００８．７．１７）
【出願人】（５０１２６３８１０）トムソン ライセンシング (2,848)
【氏名又は名称原語表記】Ｔｈｏｍｓｏｎ Ｌｉｃｅｎｓｉｎｇ
【住所又は居所原語表記】１−５， ｒｕｅ Ｊｅａｎｎｅ ｄ’Ａｒｃ， ９２１３０ ＩＳＳＹ ＬＥＳ ＭＯＵＬＩＮＥＡＵＸ， Ｆｒａｎｃｅ
【Ｆターム（参考）】
【公表日】平成２２年５月１３日（２０１０．５．１３）
【国際特許分類】
【出願日】平成２０年１月１１日（２００８．１．１１）
【国際出願番号】ＰＣＴ／ＥＰ２００８／０５０２９１
【国際公開番号】ＷＯ２００８／０８４０９６
【国際公開日】平成２０年７月１７日（２００８．７．１７）
【出願人】（５０１２６３８１０）トムソン ライセンシング (2,848)
【氏名又は名称原語表記】Ｔｈｏｍｓｏｎ Ｌｉｃｅｎｓｉｎｇ
【住所又は居所原語表記】１−５， ｒｕｅ Ｊｅａｎｎｅ ｄ’Ａｒｃ， ９２１３０ ＩＳＳＹ ＬＥＳ ＭＯＵＬＩＮＥＡＵＸ， Ｆｒａｎｃｅ
【Ｆターム（参考）】
[ Back to top ]