JP2015172954A

JP2015172954A - プル・モード及びプッシュ・モードを組み合わせるシステム及び方法

Info

Publication number: JP2015172954A
Application number: JP2015098102A
Authority: JP
Inventors: ゴティエエリック; Eric Gautier; リュベルスウィレム; Lubbers Willem; ジェラールフランソワ; Gerard Francois
Original assignee: Thomson Licensing SAS
Current assignee: Thomson Licensing SAS
Priority date: 2007-01-12
Filing date: 2015-05-13
Publication date: 2015-10-01
Anticipated expiration: 2028-01-11
Also published as: CA2675057A1; US9100376B2; US20100011088A1; RU2009130739A; MX2009007438A; EP2103083A1; BRPI0806326A2; JP5785689B2; EP2103083B1; CN101584190A; CN101584190B; RU2454820C2; JP5951071B2; KR101606940B1; EP1944944A1; ZA200904569B; JP2010515988A; WO2008084096A1; KR20090101489A; CA2675057C

Abstract

【課題】本発明は、プッシュ・モード及びプル・モードの組合せを使用してコンテンツをダウンロードする方法に関する。【解決手段】第１の端末（１）と、少なくとも第２の端末（２）と、コンテンツ・サーバ（５，８）とを備える通信システム（１０）では、本発明は、第１の端末のレベルで、コンテンツ・サーバ若しくは少なくとも第２の端末からのプル・モードにおいて、又はコンテンツ・サーバからのプッシュ・モードにおいてコンテンツをダウンロードするステップと、コンテンツの連続するダウンロードのモード間でシームレスに切り換えるステップとを含む、コンテンツをダウンロードする方法に関する。【選択図】図１

Description

本発明は、一般に、コンテンツ・ダウンロードに関し、特に、プル手法及びプッシュ手法の組合せの使用に関する。

この部分は、本願明細書及び特許請求の範囲記載の本発明の種々の局面に関係し得る当該技術分野の種々の局面を本願明細書及び特許請求の範囲の読者に紹介することを意図している。本願明細書及び特許請求の範囲の記載は、本発明の種々の局面をより詳細に理解することを容易にするための背景情報を読者に与えるうえで有用であると思われる。よって、前述の記載はこれに照らして読まれるものとし、従来技術と認めたものとして読まれるものでない。

サーバと、複数の受信器との間のコンテンツの配信は、サーバと各受信器との間のポイント・ツー・ポイント接続、又はマルチポイント接続の設定を必要とする。ポイント・ツー・ポイント接続は、ユニキャスト手段においてコンテンツを各受信器に配信することを可能にし、ロバストな配信を提供する。これは、以降、プル・モードと呼ぶ。通常、クライアントはアクティブ・イニシエータである。しかし、受信器がかなりの数にのぼるので、接続全ての面倒な管理が必要になる。ネットワークを介したトラフィックを劇的に増加させることもできる。マルチキャスト配信は、よりロバストでない配信で、より少ないネットワーク負荷をもたらす。これは以下ではプッシュ・モードと呼ぶ。

サーバを管理するサービス・オペレータは、受信器の挙動を正確に予測することが可能でない。プッシュ・コンテンツ配信セッションでは、受信器は、受信器がプッシュ配信中にスイッチ・オフされること、受信器が、プッシュ配信が実行中にオンにされること、予約済帯域幅が全て、プッシュ配信に利用可能な訳でないこと、例えば、ＳＴＢユーザが、別の番組を記録している間に一番組を視聴すること、受信器は、プッシュ配信の際に記憶容量が不足していること、受信器はプッシュ配信の際にフルＣＰＵを使用していること、ネットワークはマルチキャスト・トラフィックを処理することが可能でないこと等の理由で、完全な、又は部分的なダウンロードから除外され得る。帯域幅を最適にするために、オペレータは、プッシュ・セッションの維持又は停止を選ばなければならないことがあり得る。プッシュ・セッションの停止は、オペレータがネットワークを大量のトラフィックから解放することを可能にし、欠落したコンテンツを有する受信器は回復モードを使用して取り出すことが可能である。回復手法は欧州特許出願第０６２９１４６４．３号明細書に規定されている。一方、プル・モードでは、オペレータは、コンテンツに対するピーク需要に直面しなければならないことがあり得る。その場合、プル・モ―ドの代わりにプッシュ・モードでこのコンテンツをマルチキャストすることにより、オペレータが展開遅延、及びネットワーク帯域幅の使用を最適にすることにおいてより効率的であり得る。

本発明は、プル・モードとプッシュ・モードとの間で効率的に切り換える方法に関する。

この目的で、本発明は、第１の端末、少なくとも第２の端末、及びコンテンツ・サーバを備える通信システムにおいてコンテンツをダウンロードする方法に関する。方法は、第１の端末のレベルで、コンテンツ・サーバ若しくは少なくとも第２の端末からプル・モードにおいて、又はコンテンツ・サーバからプッシュ・モードにおいてコンテンツをダウンロードする工程と、コンテンツを連続してダウンロードするためにモード間でシームレスに切り換える工程とを含む。

この意味合いでは、「シームレスに」は、何れの他の情報の要求を必要とすることもなく、一方モードから他方モードに端末が連続して切り換わることを意味している。

一実施例によれば、方法は、プッシュ・モードにおいてコンテンツをダウンロードする工程と、プッシュ・モードがコンテンツ・サーバにおいて停止した場合、プル・モードでコンテンツをダウンロードし続ける工程とを含む。

オペレータがプッシュ・セッションを停止すると、端末は、割り込みがあまり多くない状態でダウンロードし続ける。プル・ダウンロード・モードに切り換え、プル・ダウンロード・モードを管理するために十分な情報をプッシュ・セッション中に得ている。

別の実施例によれば、方法は、プル・モードにおいてコンテンツをダウンロードする工程と、プッシュ・モードがコンテンツ・サーバにおいて開始した場合、プッシュ・モードでコンテンツをダウンロードし続ける工程とを含む。

一実施例では、方法は、ＦＬＵＴＥプロトコルにより、セッション配信においてプッシュ・コンテンツを受信する工程と、セッション配信中に、ファイル配信テーブルＦＤＴにおいて情報を受信し、プル・モードに切り換えることが可能になる工程とを含む。

ＦＤＴは、プル・モードへのシームレスな切り換えに必要な更なる情報を含む。プッシュ・モードが停止すると、端末は、何れの別の情報も取り出さなくてよい。プル・モードに切り換えるためのＦＤＴを備えた適切な情報を既に受信している。

一実施例によれば、方法は、ＦＤＴインスタンスのインテグリティを検証する工程と、ＦＤＴインスタンスが首尾良く受信されているか否かをインデキシング・サーバに示し、ＦＤＴインスタンスに関連付けられたファイルが首尾良く受信されているか否かをインデキシング・サーバに示す工程とを含む。

一実施例によれば、方法は、損なわれたＦＤＴインスタンスを検出すると、ファイル配信の最後を待つ工程と、プル・モードにおいてＦＤＴインスタンス修復を行う工程とを含む。

一実施例によれば、方法は、損なわれたフルＦＤＴを検出すると、セッション配信の最後を待つ工程と、プル・モードにおいてフルＦＤＴの修復を行う工程とを含む。

一実施例によれば、方法は、ピアツーピア・プロトコルに応じてプル・コンテンツを受信する工程と、プッシュ・モードへの切り換えを可能にする情報を含むピアツーピア・メタ情報ファイルを受信する工程とを含む。

本発明は、プッシュ・モードにおいてコンテンツをダウンロードする手段と、プル・モードにおいてコンテンツをダウンロードする手段と、一方モードから他方モードにシームレスに切り換える手段とに関する。

本発明の別の目的は、プログラムがコンピュータ上で実行されると、本発明による方法の工程を実行するためのプログラム・コード命令を含むコンピュータ・プログラム・プロダクトである。「コンピュータ・プログラム・プロダクト」は、ディスケット（登録商標）やカセットなどの、プログラムを記憶空間が含むことを含むのみならず、電気信号又は光信号などの信号も含み得るコンピュータ・プログラム・サポートを意味している。

実施例に準拠したシステムを示すブロック図である。実施例による端末を表す図である。プル・モードを示すフローチャートである。プッシュ・モード及びプル・モードの組合せを示すフローチャートである。

本願開示の実施例の範囲と範囲が同等の特定の局面を以下に記載する。前述の局面は、本発明がとり得る特定の形態の簡単な要約を本明細書及び特許請求の範囲の読者に提供するためのみに提示しており、前述の局面は、本発明の範囲を限定することを意図するものでない。実際に、本発明は、以下に記載されていないことがあり得る種々の局面を包含し得る。

本発明は、添付図面を参照して、如何なる方法においても限定的でなく、以下の実施例及び実行例によってよりよく理解され、例証されるであろう。

図１及び図２では、図示されたブロックは、純粋に機能エンティティであり、これは、物理的に別個のエンティティに必ずしも対応しない。すなわち、ソフトウェアの形態で開発されるか、１つ又は複数の集積回路で実現することが可能である。

図１は、コンテンツを配信する実施例による通信システム１００のアーキテクチャを表す。端末１、２、３はクライアント・アプリケーションを有する。特に、これらは、セットトップボックス（ＳＴＢ）機能を有する。以下実施例では、端末はＳＴＢであるが、実施例は前述の端末に限定されるものでない。コンテンツ・サーバからデータをダウンロードするためのクライアント・アプリケーションを備える装置に適用可能である。

端末は、プッシュ・モードでコンテンツをダウンロードする手段、及びプル・モードでコンテンツをダウンロードする手段も備える。これは、以下に説明するプル機能及びプッシュ機能を行う。

システムは、プッシュ・コンテンツ・サーバ５及びプル・コンテンツ・サーバ８を含む。プル・コンテンツ・サーバは、プル・モードにおいてコンテンツを配信するよう適合される。これは、複数のクライアントとのポイント・ツー・ポイント接続を設定する手段を備える。プッシュ・コンテンツ・サーバは、プッシュ・モードにおいてコンテンツを配信するよう適合される。当然、前述のサーバは同じ装置に含まれ得る。

インデキシング・サーバ６の役割は、ピアＳＴＢを互いに関係付けて修復を完了するか、又はコンテンツを取り出す。インデキシング・サーバの役割は、ファイル又はファイルの一部を回復したいピアを、欠落している情報を供給することができるピアと関係付けることである。インデキシング・サーバは、何れのコンテンツ・ファイルも記憶せず、ファイルの場所についての情報を記憶するための集中化されたインデクスとしてふるまう。プル・プロトコルは、コンテンツのダウンロード・ステータスについて各ＳＴＢによって逐次通知される。上記実施例では、システムは一インデキシング・サーバのみを備える。ネットワークは、いくつかのインデキシング・サーバに、例えば、地域毎、又はコンテンツ・タイプ毎にアクセスを最適化させることが可能である。同じインデキシング・サーバが、プッシュ・モード環境において、かつ、プル・モード環境において使用される。

以下ＳＤ＆Ｓと表すサービス・ディスカバリ・サーバ７は、ＥＴＳＩＴＳ１０２０３４Ｖ１．２．１（２００６−０９）ＤｉｇｉｔａｌＶｉｄｅｏＢｒｏａｄｃａｓｔｉｎｇ（ＤＶＢ），ＴｒａｎｓｐｏｒｔｏｆＭＰＥＧ−２ＢａｓｅｄＤＶＢＳｅｒｖｉｃｅｓｏｖｅｒＩＰＢａｓｅｄＭｅｔｗｏｒｋｓ標準に示されたようなサービス・ディスカバリ及び選択手法を行うよう適合される。

上記実施例では、同じＳＤ＆Ｓサーバが、ＰＵＳＨモード環境、及びＰＵＬＬモード環境において使用される。

図２は、実施例による端末の構築ブロックを表す。端末は、記憶手段１．１と、通信手段１．２と、処理手段１．３と、内部バス１．４とを備える。記憶手段は、端末がプッシュ・モード又はプル・モードにおいてファイルをダウンロードすることを可能にするプログラムを記憶することが意図される。よって、端末は、プッシュ・ダウンロード手段１．６とプル・ダウンロード手段１．５とを備える。これは、一方モードから他方モードに切り換える手段１．７を備える。

次にプル手法を説明する。これは、Ｐ２Ｐと表すピアツーピア・ストラテジに基づく。

プル手法を実施するために、端末はまず、インデキシング・サーバ・アドレス・ディスカバリ段階を行う。ＳＴＢは、ダウンロードに利用可能なコンテンツのカタログをブラウジングすることにより、ダウンロードのためのコンテンツを見つける。カタログのアドレスは、ＥＴＳＩＴＳ１０２０３４Ｖ１．２．１（２００６−０９）及びＥＴＳＩＴＳ１０２５３９Ｖ１．１．１，ＤｉｇｉｔａｌＶｉｄｅｏＢｒｏａｄｃａｓｔｉｎｇ（ＤＶＢ）；ＣａｒｒｉａｇｅｏｆＢｒｏａｄｂａｎｄＣｏｎｔｅｎｔＧｕｉｄｅ（ＢＣＧ）ｉｎｆｏｒｍａｔｉｏｎｏｖｅｒＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ（ＩＰ）（ＤＶＢ−ＩＰの意味合いでコンテンツ・ガイドの伝送及びシグナリングを説明している）を使用して見つける。端末は、カタログにおけるインデキシング・サーバのアドレスを見つける。当然、インデキシング・サーバのアドレスは、ＤＶＢ―ＩＰ／ＳＤ＆Ｓシグナリングによって配信されるコンテンツ・ダウンロード提供レコードなどの他の手段によって見つけることが可能である。

大容量コンテンツをダウンロードする能力を向上させるために、コンテンツの各ファイルは、より小容量のブロックに分割される。ピアは次いで、コンテンツのブロックを受信し、検証し、次いで、コンテンツを完全に又は部分的に受信する前に前述のブロックを交換することができる。ハッシュ・コードは各ブロックにわたって算出される。表１に示すようなメタ情報はコンテンツ・サーバ内のファイルとして記憶される。メタ情報は、ピアツーピアにおけるファイル交換を行うために必要な情報全てを含む。ハッシング操作をコンテンツ・サーバによって行うことが可能である。

以下の表は、上記実施例によるコンテンツ・メタ情報を表す。ＴＳＩフィールド及びＴＯＩフィールドは、ＦＬＵＴＥプロトコルにおいて規定され、任意である。これらはここでは、プル・モードとプッシュ・モードとの間のシームレスなスイッチングをサポートするために使用される。Ｃｏｎｔｅｎｔ−Ｂｌｏｃｋ−Ｌｅｎｇｔｈフィールド、Ｃｏｎｔｅｎｔ−Ｂｌｏｃｋ−Ｄｉｇｅｓｔｓフィールド、Ｆｉｌｅ−Ｎａｍｅフィールド、Ｆｉｌｅ−Ｌｅｎｇｔｈフィールド、Ｆｉｌｅ−Ｄｉｇｅｓｔフィールド、Ｆｉｌｅ−Ｂｌｏｃｋ−Ｌｅｎｇｔｈフィールド、及びＦｉｌｅ−Ｂｌｏｃｋ−Ｄｉｇｅｓｔｓフィールドは、Ｐ２Ｐプロトコルに必要な最小のメタ情報である。

Ｍｅｔａ−ｌｎｆｏ−Ｄｉｇｅｓｔフィールドは、ＲＳＡシグネチャを送信して、メタ情報ファイルを認証することを可能にするために使用することが可能である。

ファイル・ダウンロードの方法はその場合、図３に表すように、以下の通りである。

工程Ｓ１。ＳＴＢ１は、選ばれたコンテンツに対する要求をインデキシング・サーバに送出する。

工程Ｓ２。インデキシング・サーバは、コンテンツのメタ情報を供給することができるピアＳＴＢ２のアドレスでＳＴＢに応答する。当然、インデキシング・サーバはいくつかのピアのアドレスを供給することができる。

ＳＴＢ１は、示されたピアとの接続を起動させる（工程Ｓ３）。これは、工程Ｓ４でメタ情報ファイルを取り出し、工程Ｓ５でこのインテグリティを検証し、工程Ｓ６でこのファイルを記憶し、メタ情報の受信をインデキシング・サーバに通知する。関連コンテンツが削除されるまで、ＳＴＢ１はこのファイルをメモリに保つ。

このメタ情報ファイルがあれば、ＳＴＢは、他のピアに、任意のバイト範囲のブロックを要求し、受信データのインテグリティを検証することが可能である。ＳＴＢは、メタ情報ファイルを受信した後、１つ若しくは複数のファイル、又は１つ若しくは複数のファイルのブロックをダウンロードすることが可能である。

ＳＴＢは、工程７で、インデキシング・サーバに一ブロックを要求する。当然、ＳＴＢは同時にいくつかのブロックを要求することができる。これはブロック番号及びファイル識別子（ファイル名であり得る）を送出する。ファイルＩＤは、いくつかのファイルが同時にダウンロードされる場合に必要である。

インデキシング・サーバは、工程８で、コンテンツのブロックを供給することができるピアのアドレスを戻す。

ＳＴＢは、示されたピアとの接続を起動させ（工程９）、コンテンツ・ブロックを取り出し（工程１０）、及びそのインテグリティを検証する（工程１１）。

ＳＴＢは、工程１２で、成功又は失敗の点でブロック・ダウンロードのステータスをインデキシング・サーバに示す。

クライアントは、完全なコンテンツがダウンロードされるまで、他のブロックに対する要求を、インデキシング・サーバに送出することができる。

ＳＴＢから受信する通知に表される情報を使用して、インデキシング・サーバは常にそのデータベースを更新する。何れの特定の時点でも、データ回復を必要とするＳＴＢを、欠落している情報を供給することができるピアＳＴＢと関係付けることができる。

ＴＳＩフィールド及びＴＯＩフィールドのおかげで、端末は、ファイルをダウンロードするためにプッシュ・モードにシームレスに切り換えることができる。

図３では、コンテンツのブロックを供給するピアは、コンテンツのメタ情報を供給するピアと同じである。当然、これは別のピアであり得る。

更に、インデキシング・サーバは、コンテンツのブロックを供給することができる２つ以上のピアのアドレスを返すことが可能である。ＳＴＢは次いで、場合によっては、２つ以上のピアに接続する。

インデキシング・サーバは、ピアＳＴＢの何れによっても、要求されたコンテンツ又はメタ情報を供給することが可能でない情報を有し得る。

その場合、コンテンツを直接配信することができるコンテンツ・サーバのアドレスを供給することが可能である。コンテンツに対する要求でのコンテンツ・サーバのフラッドを避けるために、インデキシング・サーバは、一ピアＳＴＢプールのみを処理し得る。その他のＳＴＢを保留にし、後に、コンテンツを首尾良くダウンロードしたピアＳＴＢプールのアドレスを示す。

あるいは、インデキシング・サーバは、別のインデキシング・サーバ又は「超」インデキシング・サーバに要求をアドレス指定することが可能である。要求された情報を見つけた場合、インデキシング・サーバは、そのデータベースに情報を記憶し、ＳＴＢに肯定的に応答する。

インデキシング・サーバは同じコンテンツに対していくつかのアドレスを供給し得る。コンテンツはいくつかのピアＳＴＢにわたって分散させることができる。すなわち、ピアＳＴＢの何れも、コンテンツ全部を有する訳でないが、コンテンツ合計を、ピアＳＴＢ上に常駐している部分コンテンツから構成することが可能である。インデキシング・サーバは、ダウンロード速度が低すぎるか、又はピアが利用可能でないことが証明された場合、別のピアからのコンテンツを取り出す機会をＳＴＢに与えるために要求コンテンツを全部又は部分的に供給することが可能な別のピアＳＴＢを示すことも可能である。

一方、インデキシング・サーバには、例えば、ピアからの首尾良く行われたダウンロードの数にわたる統計に基づいたインテリジェントなピア選択を可能にするアルゴリズムが供給され得る。

次に、プッシュ配信の方法を説明する。プッシュ配信は、ＲＦＣ３９２６に規定されたような、ＦＬＵＴＥと表す単方向伝送プロトコルによるファイル配信に基づく。プッシュ配信は、上記ピアツーピア手法を使用する回復機構を備える。

ＦＬＵＴＥプロトコルは、マルチキャスト・オブジェクトの伝送及び関連付けられた記述子表を規定する。これは、現在のセッションにおいて送信されなければならないファイルの情報を含む、ＦＤＴと表すファイル配信テーブルを規定する。ＦＬＵＴＥプロトコルは、コンテンツ・サーバからのＦＤＴをマルチキャスト・モードにおいて全てのＳＴＢに送信する。ＦＬＵＴＥは、いくつかの伝送モード（１つの完全なＦＤＴ及びそれに続く複数のファイル、又は一連のＦＤＴインスタンス（中間ＦＤＴ）及びそれに続く関連ファイルなど）を規定する。後者は、膨大な容量のビデオ・ファイルの伝送に特に適しており、セッションの最後に達する前に、オブジェクト又はファイルが正しく受信されたかを受信器が検証することができることを可能にする。前者の伝送モードは、小容量ファイルが伝送される環境において好都合である。フルＦＤＴは、同じセッションのＦＤＴインスタンス全てから構築される。

実施例では、ＦＬＵＴＥＦＤＴは、以下の表２に示すような、（ブロック長及びブロック・ハッシュを備える）特定のピアツーピア・メタ情報を有する。その場合、コンテンツ・ダウンロード中に、一方のプロトコルから他方のプロトコルに切り換えることが可能である。実際に、ＦＬＵＴＥマルチキャスト・プッシュ・セッションの最後に完全にコンテンツをダウンロードしなかった受信器は、ピアツーピア・プル・モードにシームレスに切り換え、コンテンツの欠落ブロックが厳密に分かることを可能にする、ＦＤＴにおける情報によって、欠落ブロックをダウンロードする。同様に、ピアツーピア・プル・モードにより、コンテンツをダウンロードし始めた受信器は、プッシュ・モードでファイルの欠落ブロックを回復するために必要な情報を受信器に与えるＦＤＴを使用してプッシュ・モードにシームレスに切り換えることが可能である。

以下の表は、実施例により、Ｐ２Ｐメタ情報を含むＦＬＵＴＥファイル配信表を表す。

Ｃｏｎｔｅｎｔ−Ｂｌｏｃｋ−Ｌｅｎｇｔｈフィールド、Ｃｏｎｔｅｎｔ−Ｂｌｏｃｋ−Ｄｉｇｅｓｔｓフィールド、Ｆｉｌｅ−Ｎａｍｅフィールド、Ｆｉｌｅ−Ｌｅｎｇｔｈフィールド、Ｆｉｌｅ−Ｄｉｇｅｓｔフィールド、Ｆｉｌｅ−Ｂｌｏｃｋ−Ｌｅｎｇｔｈフィールド、及びＦｉｌｅ−Ｂｌｏｃｋ−Ｄｉｇｅｓｔｓフィールドは、Ｐ２Ｐプロトコルに必要な最小のメタ情報である。ファイルは、いくつかのブロックに切断される。

Ｃｏｍｐｌｅｔｅ−ＦＤＴ−Ｄｉｇｅｓｔフィールドは、ＲＳＡシグネチャを送信して、フルＦＤＴを認証することを可能にするために使用することが可能である。

プッシュ手法でコンテンツをダウンロードするために、クライアントは、プッシュ・コンテンツ・ダウンロード・セッション・ディスカバリ段階を行う。クライアントＳＴＢはプッシュ・ダウンロード・オファーに加入する。加入の一部として、サービスがＤＶＢＩＰ／ＳＤ＆Ｓ手法を介して、ＳＤ＆Ｓサーバにより、サービスのシグナリングが伝送される配信アドレスを得る。ＳＴＢは次いで、専用マルチキャスト・アドレスにリッスンする。これは、ＤＶＢ−ＩＰコンテンツ・ダウンロード・オファー・レコードを見つける。

このコンテンツ・ダウンロード・オファー・レコードにおいて、コンテンツ・ダウンロード・セッションの開始及び終了日時、並びに、コンテンツが配信されるポート、マルチキャスト・アドレス、及び、依存するインデキシング・サーバのアドレスなどの他の情報を見つける。上記実施例によるＳＤ＆Ｓレコード・ファイルは以下の表３に示す。

ＡｎｎｏｕｎｃｅｍｅｎｔＤｉｇｅｓｔフィールドは、ＲＳＡシグネチャを送信して、通知を認証することを可能にするために使用することが可能である。

図４に示すように、ディスカバリ段階において獲得された情報を使用して、ＳＴＢは、プッシュ・セッション・コンテンツが配信されるマルチキャスト・アドレスにリッスンする（工程Ｓ’１）。

各ＦＤＴインスタンスは、それ自身のインテグリティ、及びそれと関連付けられたファイルのブロックのインテグリティを検証することを可能にするいくつかのハッシュ・コードを含む。この情報は、プル・モードについて説明したようなメタ情報ファイルに対応する。プル・モードの場合、ＳＴＢは、関連コンテンツを保持している限り、メタ情報ファイルを記憶する。ファイルを次いで、後に使用して、プル・モードでピアを処理することが可能である。

ＳＴＢは、ＦＬＵＴＥプロトコルの「Ｅｎｄ−Ｏｆ−Ｔｒａｎｓｍｉｓｓｉｏｎ−Ｆｉｌｅ」フラグにより、ファイル配信の終了の時点を検出する。その時点から、各ＳＴＢは、ＦＤＴインスタンスのインテグリティを検証することが可能である（工程Ｓ’２、Ｓ’３）。
この検証後、各ＳＴＢは、ＦＤＴインスタンスを受信したかを示すメッセージをインデキシング・サーバに送信する（工程Ｓ’４、Ｓ’５）。

ＦＤＴインスタンスのインテグリティ・チェックが首尾良く行われた場合、ＳＴＢはＦＤＴインスタンスに関連付けられたファイルのブロックのインテグリティを検証し（工程Ｓ’６、Ｓ’７）、関連ファイルについて通知をインデキシング・サーバに送出する。この通知は、正しく受信されたブロックについての情報、及びファイル識別子を含む。インデキシング・サーバはこの情報を記憶し、このデータベースを更新する。欠落しているファイル部分について、以下に説明するように、ＳＴＢはファイル回復を行う。

ＦＤＴインスタンスのインテグリティ・チェックが首尾良く行われなかった場合、損なわれたＦＤＴインスタンスは、関連付けられたファイルのブロックのインテグリティをＳＴＢが検証することを可能にしない。この情報がＦＤＴインスタンスに含まれているからである。ＳＴＢは、損なわれたＦＤＴに続くファイルを記憶し、ファイル配信の終了の検出を待って、以下に説明するようなＦＤＴインスタンス修復を開始させる。ブロックを含むＦＬＵＴＥパケットは、ファイル毎に一意の、ＴＯＩと呼ばれる識別子を含む。ＦＤＴはこの識別子も含む。これは、ブロックをファイルに関連付けることを可能にする。

セッションの最後のＦＤＴインスタンスは、セッションの一部であるＦＤＴインスタンス全ての合計にわたって算出されるハッシュ・コードも含む。これは、フルＦＤＴのインテグリティの検証、及びＦＤＴインスタンスが欠落しているかを知ることを可能にする。これは、ＦＤＴインスタンスが一ＦＬＵＴＥパケットによってのみ配信されるケースを検出するために使用することが可能であり、このパケットは廃棄される。

ＳＴＢは、ＦＬＵＴＥパケット・ヘッダ内に設けられた「セッション終了」フラグにより、又はセッション・シグナリング・レコードに含まれるセッション終了日時により、セッションが終了する時点を検出する。

したがって、各ＳＴＢは、受信ＦＤＴインスタンス全ての和であるフルＦＤＴのインテグリティを検証し、次いで、フルＦＤＴが損なわれているか、又は一部のＦＤＴインスタンスが欠落しているかを検証する。フルＦＤＴが損なわれていない場合、その受信状態に応じて、特定のファイルの回復処理を起動させることが必要になり得る。一方、フルＦＤＴが、損なわれていることが明らかになった場合、ＳＴＢは、フルＦＤＴに対する要求を示すメッセージをインデキシング・サーバに送出し、その後、損なわれたファイルについて回復処理が必要かを検証する。

欠落したか、又は損傷したプッシュ・コンテンツは、上述の通常プル・モード段階内で回復することが可能である。

フルＦＤＴに対するインテグリティ・チェック又はＦＤＴインスタンスに対するインテグリティ・チェックが首尾良く行われなかった場合（Ｓ‘１０）、ＳＴＢは、フルＦＤＴ（又はＦＤＴインスタンス。図４に示す）に対する要求を示すメッセージをインデキシング・サーバに送出する
インデキシング・サーバはＦＬＵＴＥの知識を何ら有していないはずなので、以下が、フルＦＤＴ（又はＦＤＴインスタンス）を取り出すことを可能にするうえであてはまる。

ＳＴＢは、フルＦＤＴ及びＦＤＴインスタンスをメモリに特定期間の間（特に、新たなセッションにおける新たなコンテンツのダウンロードまで）、保持する。ＳＴＢは、このフルＦＤＴ（又はＦＤＴインスタンス）の正しい受信をインデキシング・サーバに通知する。

損なわれたフルＦＤＴ（又は損なわれたＦＤＴインスタンス）を有するＳＴＢは、インデキシング・サーバに問い合わせることが可能である（工程Ｓ’１１）。インデキシング・サーバは、損なわれていないバージョンを送出することができるピアのアドレスを供給する（工程Ｓ’１２、Ｓ’１３）。

ＳＴＢは、そのハッシュ値で、損なわれていないフルＦＤＴ（又は損なわれていないＦＤＴインスタンス）を取り出すことが可能である（工程Ｓ’１４、Ｓ’１５、Ｓ’１６、Ｓ’１７）。これは、そのインテグリティを検証する。これは、フルＦＤＴを解析して、落としたプッシュ・セッションのファイルを識別するか、又は損なわれたＦＤＴインスタンスを修復する。次いで、関連付けられたファイルのインテグリティを検証する。ＳＴＢは、欠落しているファイルを検出した場合、その欠落しているファイルのファイル回復を開始する。ＳＴＢは、損なわれたファイルを検出した場合、ブロック回復を開始する。

ＳＴＢから受信する通知において与えられる情報を使用して、インデキシング・サーバは連続してそのデータベースを更新する。何れの特定の時点でも、データ回復を必要とするＳＴＢを、欠落している情報を供給することができるピアＳＴＢと関係付けることができる。

ＳＤ＆Ｓレコード内のセッション通知によって与えられるセッション持続時間のおかげで、ＳＴＢには、プッシュ・セッションを落としたか否かが分かる。プッシュ・セッションを落としたＳＴＢは、ファイル名「ＦＤＴ」のフルＦＤＴについてインデキシング・サーバに問い合わせ、欠落しているファイルのファイル回復を進める。

ファイル配信セッションが実行中に接続するＳＴＢは、ＦＬＵＴＥマルチキャスト・セッションから、コンテンツの一部を得ることがなおできる。ＦＬＵＴＥセッションにおいて落としたファイルを得るために、セッションの終了を待って、「フル」ＦＤＴ回復を行い、ピアから、欠落しているファイルを得る。

ビデオ・ファイル・ダウンロードの環境では、プッシュ手法及びプル手法の組合せは、拡張配信モデルをもたらす。配信ポリシーは以下の通りであり得る。比較的人気の高い映画はプッシュ・モードで提案することが可能であり、需要がより少ない他の映画はプル・モードで提案することが可能である。プッシュ・モード映画の組が新たなもので置換されると、旧い組が、プル・モードで利用可能な映画の組に加わる。

一方、インデキシング・サーバは、インデキシング・サーバが収集することができる需要に関する統計により、プル・モードからプッシュ・モードに、又はその逆に特定の映画の配信モードを切り換えることが興味深い旨をコンテンツ・サーバに示し得る。

監視エンティティ又は管理エンティティの場合、インデキシング・サーバは、ファイル回復活動についての統計を収集する可能性を提供する。この情報は、配信ストラテジを動的に監視するために又は適合させるためにオペレータによって使用される。後者は、ＦＥＣの付加、又はプッシュ配信の追加セッションの計画を含み得る。他の動作は、ダウンロード・ファイル配信に割り当てられた帯域幅を変更することを含み得る。

本明細書の、「ｏｎｅｅｍｂｏｄｉｍｅｎｔ」又は「ａｎｅｍｂｏｄｉｍｅｎｔ」への言及は、本願の実施例に関して説明した特定の構成、構造又は特性が本発明の少なくとも一実現形態に含まれ得ることを意味している。明細書中の種々の箇所に「ｉｎｏｎｅｅｍｂｏｄｉｍｅｎｔ」の句が存在していることは、同じ実施例を必ずしも全て参照しておらず、他の実施例と必ずしも相互排他的でない別個の、又は別の実施例でない。

特許請求の範囲記載の参照符号は、例証の目的に過ぎず、特許請求の範囲記載の範囲を限定する効果はないものとする。

Claims

第１の端末と、少なくとも第２の端末と、コンテンツ・サーバとを備える通信システムにおいてコンテンツを受信する方法であって、前記第１の端末のレベルで、
前記コンテンツ・サーバからプッシュ・モードにおいて、コンテンツ及びファイル配信テーブル（ＦＤＴ）を受信することにより、プル・モードへの切り換えを可能にするステップと、
前記プル・モードが利用可能な場合、インデキシング・サーバから受信された前記第２の端末のアドレス又は前記ＦＤＴにおいて受信された情報以外の更なる情報を要求することなく、前記プル・モードで前記コンテンツを前記コンテンツ・サーバ又は少なくとも前記第２の端末から受信し続けるステップとを含み、
前記ＦＤＴは、ＦＬＵＴＥプロトコルにおいて規定されるＴＳＩフィールドとＴＯＩフィールド、及びブロック長とブロック・ハッシュを備える特定のピアツーピア・メタ情報を含む、方法。
第１の端末と、少なくとも第２の端末と、コンテンツ・サーバとを備える通信システムにおいてコンテンツを受信するよう適合された端末であって、
プッシュ・モードでコンテンツをダウンロードする手段と、
プル・モードでコンテンツをダウンロードする手段と、
前記コンテンツ・サーバから前記プッシュ・モードにおいて、コンテンツ及びファイル配信テーブル（ＦＤＴ）を受信することにより、プル・モードへの切り換えを可能にし、前記プル・モードが利用可能な場合、インデキシング・サーバから受信された前記第２の端末のアドレス又は前記ＦＤＴにおいて受信された情報以外の更なる情報を要求することなく、前記コンテンツ・サーバ又は少なくとも第２の端末からプル・モードで前記コンテンツを受信し続ける手段とを含み、
前記ＦＤＴは、ＦＬＵＴＥプロトコルにおいて規定されるＴＳＩフィールドとＴＯＩフィールド、及びブロック長とブロック・ハッシュを備える特定のピアツーピア・メタ情報を含む、端末。