JP2011527479A - プロキシ機能 - Google Patents

Abstract

本発明は、ＩＰＴＶサービスプロバイダのドメイン２、２Ｂの外側にある外部ドメイン３、３ＢからのコンテンツにＩＰＴＶセットトップボックス４、４Ｂがアクセスするための方法および装置に関するものであり、その方法は、必要なコンテンツを外部ドメインから検索するステップと、必要なコンテンツをＩＰＴＶセットトップボックスを介してアクセス可能な形式に変換するステップとによって特徴付けられる。

Description

本発明は、ＩＰＴＶサービスプロバイダのドメインの外側にある外部ドメインからのコンテンツにアクセスするための、ＩＰＴＶセットトップボックスのための方法および装置に関する。

ＩＰＴＶの展開はすでに行われており、高速アクセス技術の導入が続くのにつれて拡大し続けるであろう。一方、例えばＪｏｏｓｔやＢＢＣのｉＰｌａｙｅｒのようなコンテンツアグリゲータが、合法的なオンラインコンテンツ発信元としての地位を固めつつある。

ブロードバンドの普及によって帯域幅の拡大がもたらされたことや、高度な端末能力と、コンテンツ作成および公開ツールとが利用できるようになったことによって、例えばＹｏｕＴｕｂｅやＰｏｄｃａｓｔｉｎｇ等のユーザが作成したコンテンツのインターネット上での利用可能性が著しく増大した。また、例えばＪｏｏｓｔやＢＢＣ ｉＰｌａｙｅｒ等のコンテンツアグリゲータが、合法的なオンラインコンテンツ発信元としての地位を固めつつある。

ピア・ツー・ピアの技術は、ユーザの作成したコンテンツを配信するために実行可能な技術であり、かつ、コンテンツアグリゲータに最適な技術であることが実証されている。例えば、ｉＰｌａｙｅｒは、ＩＭＰ Ｐ２Ｐクライアントを利用する。多くの場合、単純にピア・ツー・ピアと呼ばれ、短縮してＰ２Ｐと呼ばれることもあるが、ピア・ツー・ピアのアーキテクチャは、各ワークステーションが同等の能力と責任とを有するネットワークの一種である。これは、一部のコンピュータが他のコンピュータへのサーバ専用であるクライアント／サーバのアーキテクチャとは異なる。Ｐ２Ｐネットワークは、ネットワーク内で接続されたピア間に演算力を分散し、そして、まとめられた資源、例えばネットワークの利用可能な帯域幅を、効率的なコンテンツ配信のために利用する。Ｐ２Ｐという用語は、例えばソフトウェアの更新ファイルやメディアファイルのような材料をダウンロードする目的で共通のＰ２Ｐクライアントを利用して情報やファイルを交換するために１人のユーザが別のユーザと結合することを記述する用語として用いられる場合が多い。しかし、これはＰ２Ｐネットワーキングの１つのタイプに過ぎない。一般に、Ｐ２Ｐネットワークはファイルを共有するのに用いられるが、Ｐ２Ｐネットワークがグリッドコンピューティングやインスタント・メッセージを意味することもある。Ｐ２Ｐクライアントが例えばＰＣへとダウンロードされてインストールされ、かつ、インターネットに接続されると、ユーティリティを立ち上げて中央指標付与（インデックス）サーバに接続することが可能である。この中央サーバは、サーバに現時点でオンライン接続しているすべてのユーザに指標を付与する。このサーバは、ダウンロード用のファイルはホストしない。Ｐ２Ｐクライアントは、ユーザが特定のファイルを検索できるようなエリアを有するであろう。ユーティリティは、ユーザが探しているファイルに接続している他ユーザを見つけるため、指標付与サーバにクエリを行う。一致するものが見つかると、中央サーバは、要求されたファイルをどこで見つけるかをクライアントに通知するであろう。次いで、ユーザは、検索クエリから結果を選択することができ、そして、ユーザのユーティリティは、自分が要求したファイルをホストしているピアとの接続を確立しようと試みるであろう。接続が成功すると、ユーザは、ファイルのダウンロードを開始するであろう。Ｐ２Ｐクライアントの第２のモデルは、同様に機能するけれども、中央指標付与サーバなしでそれを行う。このシナリオでは、Ｐ２Ｐソフトウェアは、同じプログラムを用いている他のインターネットユーザを単純に探し出し、彼らに自分のオンラインでの存在を通知することによって、そのソフトウェアをインストールして使用するユーザが増加するにつれて、コンピュータの大規模ネットワークを構築する。

ＩＰＴＶ仕様（例えばＯｐｅｎＩＰＴＶ Ｆｏｒｕｍ）は、多様なマルチメディアおよびインタラクティブサービスを小売ベースの消費者装置に供給するためのアーキテクチャを定義する。主なサービスとして、Ｂｒｏａｄｃａｓｔ Ｃｏｎｔｅｎｔサービス（ａｋａ ｃｏｎｖｅｎｔｉｏｎａｌ ＴＶ）とＯｎ Ｄｅｍａｎｄコンテンツサービス（ａｋａ Ｖｉｄｅｏ ｏｎ Ｄｅｍａｎｄ）との２つが挙げられる。一般に用いられるプロトコルには、ＶｏＤのためのＲＴＳＰと、ライブストリーミングのためのＲＴＰ／ＩＧＭＰとが含まれる。今日、大半のＩＰＴＶオペレータは、補助金付きで顧客に提供されたセットトップボックス（ＳＴＢ）に動画コンテンツを配信することに依存している。通常、これはサービス契約と抱き合わせになっている。目的は、大量の顧客に到達できるようにすることであり（例えばＴｅｌｉａ ＩＰＴＶは２００７年の第１四半期時点で３７９０００を超える加入契約を有している）、従って、消費者にはＳＴＢが大量展開されている。そのため、すでに展開済のＳＴＢを使用し続けることは、オペレータ各社にとっては極めて重要であり、なぜなら、これらのデバイスを変更するための費用は、大量展開を考慮に入れると非常に高いものになりうるからである。

すでに述べたとおり、Ｐ２Ｐ技術は、ファイル共有、動画ストリーミング、動画およびコンテンツのダウンロード用として広く用いられている。Ｐ２Ｐ技術は、ユーザの作成したコンテンツを配信するために実行可能な技術であり、かつ、多くのインターネットコンテンツアグリゲータに最適な技術であることが実証されている。しかし、現行のＩＰＴＶ ＳＴＢ展開は、この新たな配信方法を利用することができない。ＩＰＴＶ ＳＴＢの能力には限界があり、言い換えれば、実行環境能力に限度があり、すなわち、例えばＰ２Ｐクライアントのような新しいアプリケーションを低コストで追加することができない。また、ＳＴＢは、記憶能力あるいは処理力に限度があるかまたは欠けていることがある。ＩＰＴＶ ＳＴＢにとって、大量のインターネットベースのコンテンツは、現在のところアクセス不可能である。一部のサービスプロバイダ（例えばＴｅｌｉａのＩＰＴＶサービス）では、ＩＰＴＶ ＳＴＢを用いたウェブ閲覧が可能であるが、フォーマットに互換性がないため、かつ、コンテンツのダウンロードを行うための正しいクライアントアプリケーションがＳＴＢには単純に欠けているため、これでは、ユーザは、純粋なインターネットベースのコンテンツにアクセスできない。

本発明は、ＩＰＴＶサービスプロバイダのドメインの外側にあるコンテンツにアクセスするためのセットトップボックスの能力の限界によって生じる諸問題に関する。

これらの問題およびその他の問題が、本発明によって、ＩＰＴＶサービスプロバイダのコンテンツドメインの外側にあるコンテンツにアクセスするための、ＩＰＴＶセットトップボックスのための方法および装置によって解決される。本発明は、ＩＰＴＶセットトップボックスによってアクセスされることができ、かつ、ＩＰＴＶサービスプロバイダのコンテンツドメインの外側にあるコンテンツにアクセスすることができるネットワークノードを定める。特に、本願は、Ｐ２ＰコンテンツドメインおよびＩＰＴＶ ＳＴＢを介してアクセス可能になるウェブコンテンツドメインの中で利用可能なコンテンツのためのやり方を定めるが、それに限定されない。

詳細には、本方法には、必要なコンテンツを外部ドメインから検索するステップと、必要なコンテンツをＩＰＴＶセットトップボックスを介してアクセス可能な形式に変換するステップとが含まれる。プロキシ機能が、これによってもたらされ、そのプロキシ機能は、ＩＰＴＶサービスプロバイダのコンテンツドメインの外部のコンテンツを取り出し、コンテンツを変換して、定められた変換プロトコルと、例えばマルチキャスト−ＩＧＭＰおよびユニキャスト−ＲＴＳＰと、ＳＴＢによってサポートされるメディア形式とを用いてＩＰＴＶ ＳＴＢ動画コンテンツを送信することができる。

本発明の目的は、現在展開されているＩＰＴＶ ＳＴＢが、サービスプロバイダの提供品に加えて新興のメディアコンテンツ配信ネットワークからのコンテンツにアクセスする能力をそれによって有効にされるようなＩＰＴＶ取り込みシステムを定義することである。この目的およびその他の目的は、方法、装置、ノード、システム、およびプログラムによって達成される。

本発明の一部の利点は、サービスプロバイダが、よりよいサービスを提供でき、エンドユーザが、より広範な種類のコンテンツを既存のＳＴＢを用いて楽しめることである。これによって既存のＳＴＢの寿命が延び、それによって新しい高性能の代替ＳＴＢへの投資コストを先送りするか、場合によっては不要にすることもありうる。

次に、本発明について、添付の図面に関連させて好適実施形態を使って詳細に記述しよう。

オペレータネットワークだけでなくインターネットネットワークにもアクセスできるＰ２Ｐプロキシのようなネットワークノードを備えたシステムの概略ブロック図を開示する図である。 Ｐ２Ｐプロキシの概略ブロック図をより詳細に開示する図である。 必要なコンテンツをＳＴＢがインターネットドメインから取り出すための方法を示す信号シーケンス図を開示する図である。 オペレータネットワークだけでなくインターネットネットワーク内のさまざまなＭＣＤＮにもアクセスできるＭＣＤＮプロキシのようなネットワークノードを備えたシステムの概略ブロック図を開示する図である。 ＭＣＤＮプロキシの概略ブロック図を開示する図である。 本発明の方法の一部の不可欠なステップを図解するフローチャートである。

図１は、本発明の第１の実施形態に従って、オペレータのブロードバンドネットワーク２とインターネットネットワーク３とを備えたコンテンツ配信システムを開示する。オペレータネットワーク２は、ＩＰＴＶがそれを経由してＳＴＢへ配信される「保証された」部分と、対象トラヒックを通常搬送するＱｏＳがないベストエフォート部分との２つの論理部分から成る。オペレータの管理ドメイン内にＩＰＴＶ セットトップボックス４があることを示す。この例では、ＩＰＴＶ ＳＴＢについて一組の仮定が行われる。

−記憶装置がない：現在、ＩＰＴＶサービスプロバイダは、助成料金でＳＴＢをユーザに提供している。オペレータがこれらのデバイスに課す主な要件の１つは、それらができるだけ安いということであり、従って、低コストを維持するため通常これらのデバイスには記憶装置がない。

−Ｐ２Ｐアプリケーションまたは追加のビデオプレーヤがない：コストの問題に起因して、デバイス内のソフトウェアは、通常は最小である。また、ソフトウェアは通常はＳＴＢ用に特注される。Ｐ２Ｐアプリケーションとビデオプレーヤとに共通する特徴は、それらの機能が絶え間なく変わることである。その結果、これは、これを可能にするＳＴＢ内のアプリケーションが時代遅れである場合、Ｐ２Ｐまたはウェブコンテンツにアクセスすることが極めて難しくなることを意味する。

−旧式のＳＴＢについての仮定は、ユニキャストおよびマルチキャストプロトコルのサポートである。ユニキャスト：ＲＴＳＰおよびＨＴＴＰ。マルチキャスト：ＩＧＭＰおよび任意でＦＬＵＴＥ。

インターネットネットワークは、多数の組のサーバを備える。図１では、第１のＰＣ Ｐ２Ｐクライアント５、バッファ７に接続している第２のＰＣ Ｐ２Ｐクライアント６、そして、その中に例えば動画コンテンツが取り込まれうるＬｉｖｅ Ｃｏｎｔｅｎｔ Ｉｎｇｅｓｔｉｏｎ Ｐｏｉｎｔ８とを示す。サーバ５、６および８は、この例では、相互にＰ２Ｐ関係にあり、それは、それらがＰ２Ｐのやり方でコンテンツを交換することを意味する。図２に、１つのネットワークノードを開示する。ネットワークノードは、この例では、インターネットネットワーク側にもオペレータネットワーク側にもアクセスできるＰ２Ｐプロキシ１である。本発明によるプロキシ機能は、トランスポートプロトコル（例えばマルチキャスト−ＩＧＭＰおよびユニキャスト−ＲＴＳＰ）とＳＴＢによってサポートされるメディア形式とを用いて、（Ｐ２Ｐからの）インターネットドメインから取り出した動画コンテンツを変換して送信することができる。これについては、以下の各実施形態の中でさらに説明しよう。

図２は、ピア・ツー・ピアＰ２Ｐプロキシ１をより詳細に開示する。プロキシは、オープンなインターネットネットワーク、この例ではインターネットのＰ２Ｐネットワーク部分へのインタフェースを有する。プロキシ１は、オペレータネットワークへのインタフェース、すなわちＳＴＢ４へのインタフェースも有する。プロキシ１は、サービスオペレータによって維持管理されるサーバである。プロキシ１は、Ｐ２Ｐモジュール１０を備える。基本的に、すべてのモジュールは既存のネットワークに対応するであろうから、このモジュールは多数あるであろう。これについては、後で第２の実施形態を使う説明の中で例示しよう。Ｐ２Ｐモジュールは、複数の動画待ち行列１１、すなわち、ランタイムの間にＰ２Ｐモジュールのメモリの中に作成されたデータ構造のインスタンスと、プロキシテーブル１２とを備える。Ｐ２Ｐネットワークから取り出されたコンテンツのセグメントは、動画待ち行列１１に置かれるであろうし、プロキシテーブル１２は、維持管理されるネットワーク上で端末まで、すなわちセットトップボックスまでコンテンツを配信するためにどの配信詳細情報（マルチキャストかユニキャストか）が適用されるかを判定するのに用いられるであろう。Ｐ２Ｐモジュールは、Ｐ２Ｐを通してマルチキャストプロトコルとユニキャストプロトコルとの間の翻訳を行うことができるストリーミングモジュール１３に接続している。ストリーミングモジュールは、インタワーキングモジュール１４を備える。インタワーキングモジュールは、取り出し要求（フェッチリクエスト）をＳＴＢのユーザから受信するであろう（これについては、図３と共にさらに記述しよう）。取り出し要求は、インタワーキングモジュールの中でＰ２Ｐ要求にマッピングされるであろう。次いでインタワーキングモジュールは、Ｐ２Ｐネットワークに対して要求を実行する。ストリーミングモジュールは、さらに、受信したコンテンツのトランスコーディングを行い、セットトップボックス４による消費に適した形式にコンテンツを変更することができる、トランスコーダ１５を備える。ストリーミングモジュール１３は、２つのキャスティングモジュール、すなわちユニキャストモジュール１６とマルチキャストモジュール１７とを有する。セットトップボックスがコンテンツについてどのように要求したかによって、それがＲＴＳＰ要求である場合、ストリーミングモジュールは、コンテンツをＳＴＢにユニキャストするであろうし、ＳＴＢがマルチキャストのためのＩＧＭＰ加入を行う場合、ストリーミングモジュールは、コンテンツをセットトップボックスにマルチキャストするであろう。さらにプロキシ１は、この例では、Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｅｎｔ Ｇｕｉｄｅ ＥＣＧ Ｐｏｒｔａｌ １８を備える。Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｅｎｔ Ｇｕｉｄｅ ＥＣＧは、ユーザが従来型および新型のＰ２Ｐコンテンツを閲覧してそれらにアクセスできるようにするため、ＳＴＢが使うものである。従ってＥＣＧは、既存のＳＴＢの能力を活用する必要があるだろう。ＥＣＧは、例えばＹｏｕＴｕｂｅ、Ｊｏｏｓｔ、ｉＰｌａｙｅｒのようなメディアコンテンツ配信ネットワーク上で現在利用可能なものに基づいた動的コンテンツを含む。ＥＣＧを生成するには、静的またはオンデマンドという２つの方法を用いることができる。静的に生成されたＥＣＧは、コンテンツサイトを事前にゆっくり進み、そして、各サイトで利用可能なコンテンツに指標を付与するであろう。これは、ＥＣＧを更新し続けるために周期的に行われてもよい。オンデマンドの方法は、ユーザがアクセスすることを望む度にコンテンツのリスティングにアクセスするために、例えばＷｅｂ ｓｅｒｖｉｃｅｓのような、コンテンツサイトに対して標準化されたインタフェースを利用してもよい。これは、ＥＣＧコンテンツが常に最新であることを保証する。どちらの方法も、Ｍｅｄｉａ Ｃｏｎｔｅｎｔ Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｎｅｔｗｏｒｋｓ（メデイアコンテンツ配信ネットワーク：ＭＣＤＮ）にクエリを行うためにＥＣＧサーバが使用できるかまたはＭＣＤＮがＥＣＧサーバに更新をプッシュできるようにするため、所定のインタフェースを利用するであろう。これらのインタフェースの詳細は、本特許の範囲外であるが、例えばＷｅｂ Ｓｅｒｖｉｃｅｓのような標準化されたインタフェースを利用できるであろう。ＳＴＢ４は、ＳＴＢ Ｖｉｄｅｏ Ｄｅｃｏｄｅｒ ＳＴＢ ＶＤ ４Ｘ、ＥＣＧポータルから情報を受信することができるＳＴＢ Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｅｎｔ Ｇｕｉｄｅ ＳＴＢ ＥＣＧ ４Ｙ、そして、ユーザの要求がそこからインタワーキングモジュールへ送信されるＳＴＢ Ｍｉｄｄｌｅｗａｒｅ ＳＴＢ ＭＷを備える。

要約すれば、Ｐ２Ｐプロキシ１は、Ｐ２Ｐネットワークへ向かっている外部の組および内部の組という一組のインタフェースと、それらのインタフェースの間のトランスコーディングの機能とを有する。外部の組のインタフェースは、オペレータが接続を望む多様なコンテンツ配信ネットワークのソフトウェアクライアントを構成する。例えば、クライアントには、ＢｉｔｔｏｒｅｎｔＤＮＡクライアント、Ｎａｓｐｅｒクライアント、およびその他のＰ２Ｐアプリケーションクライアントが含まれうるであろう。内部インタフェースは、マルチキャスト用のＩＧＭＰ上のＲＴＰとユニキャスト用のＲＴＳＰとを含めて従来型の方法を用いたコンテンツ配信を可能にするモジュールを構成する。トランスコーダ１５の中のトランスコーディング機能は、外部インタフェースで受信されたコンテンツが内部インタフェース上で送出されることを可能にする。機能は、どのようにして特定のＰ２Ｐアプリケーションからのコンテンツが最初に所与のメディア形式にトランスコードされ、次いで標準のトランスポートプロトコルを介してＳＴＢに配信されるかについて記述する一組の規則で成り立つ。従って、プロキシは、一組のメディアデコーダおよびエンコーダで成り立つ。Ｐ２Ｐプロキシは、ビットレート、解像度、およびコーデックのようなパラメータを考慮に入れながらメディアトランスコーディングを行う。

図３は必要なコンテンツをＳＴＢがインターネットドメインから取り出すための方法を表す信号シーケンス図を開示する。図３に開示するエンティティは、すべて、図１および図２の説明と一緒に説明したものである。Ｍｅｄｉａ Ｃｏｎｔｅｎｔ Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｎｅｔｗｏｒｋ ＭＣＤＮは、図２のＰ２Ｐネットワークに対応する。次に、本発明の第１の実施形態による方法について、図３と共により詳細に記述しよう。図３は、図２と共に読んでいただきたい。方法は、以下のステップを含む。

−ユーザが、セットトップボックス４の電源を入れる２１。

−ＳＴＢ４の中のＥＣＧクライアント４Ｙが、Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｅｎｔ Ｇｕｉｄｅ ＥＣＧポータル１８のコンテンツを取り出す動作２２を行う。取り出し要求は、これによってＳＴＢからＰ２Ｐプロキシ１へ送信される。任意で、ユーザのＩＤが含まれる。

−本願で前述したようにＥＣＧポータルの中で電子コンテンツガイドが生成される２３。任意で、カスタマイズするためユーザのＩＤが用いられてもよい。

−ＥＣＧデータがＰ２Ｐプロキシ１からＳＴＢ４へ配信される２４。ＥＣＧデータは利用可能な資産のリストを含む。

−ユーザが、利用可能な資産のリストからコンテンツを選択する２５。あるいは、前述した検索手順（取り出し手順）が、ここで行われてもよい。

−前のステップにおけるユーザ選択の結果、マルチキャストまたはユニキャストの取り出し要求コマンドが行われるであろう（例えばマルチキャスト用にはＩＧＭＰ加入、ユニキャスト用にはＲＴＳＰ ＰｌａｙまたはＨＴＴＰ ＧＥＴ）。所定の組のコンテンツを選択するのではなくてユーザが検索を行った場合には、このステップは、要求された動画資産の発見が成功した後に限って行われるであろう。このステップの重要性は、それが、現在のＳＴＢに現時点で実装されている既存のコンテンツ検索方法を利用するということである。ユニキャストの取り出し要求は、この例では、ＳＴＢ４の中のミドルウェアＭＷ ４Ｚから、ストリーミングモジュールの中のユニキャスト／マルチキャスト１６／１７へ送信される２６。取り出し要求は、所望のキャスティング方法についての情報以外に、例えばビットレート、符合化等の所望のメディア形式のような情報のような、追加のメタデータを備える。

−必要なコンテンツを取り出す要求２７が、ユニキャスト／マルチキャストモジュール１６／１７からインタワーキングモジュール１４へ送信される。これによって、内部メッセージがユニキャスト／マルチキャストモジュール１６／１７からインタワーキングモジュール１４へ送信される。これが、コンテンツを求める要求とＭｅｄｉａ Ｃｏｎｔｅｎｔ Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｎｅｔｗｏｒｋ ＭＣＤＮ固有の方法との間を翻訳するようにインタワーキングモジュールに信号で伝える。それは、ＳＴＢが要求を行ったことと、インタワーキングモジュールがその要求をＰ２Ｐモジュールへ送信されることになるＰ２Ｐ要求（すなわち、図３に示すメッセージ２９）へ翻訳すべきであることとをインタワーキングモジュールに信号で伝える、トリガメッセージである。

−インタワーキングモジュール１４の中にセッションＩＤが生成され、本セッションが識別される２８。セッションＩＤは、ユーザからの要求がＭＣＤＮからのコンテンツの実際の取り出しと同時にもたらされうるように、Ｍｅｄｉａ Ｃｏｎｔｅｎｔ Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｎｅｔｗｏｒｋ ＭＣＤＮから後で取り出されるであろうデータを識別するのに用いられる。インタワーキングモジュール１４は、受信したコンテンツ、例えば動画が、ＳＴＢにユニキャストとして送信されるのかマルチキャストとして送信されるのかを判定するために、セッション状態情報を維持する。

−インタワーキングモジュールが、セッションＩＤとコンテンツ名と追加のメタデータ、例えばビットレート、符合化等を含むメッセージを、処理の目的でＰ２Ｐモジュールへ送信する２９。追加のメタデータは、この例では、取り出し要求（フェッチリクエスト）の中で受信されるが、場合によっては、変形として、それをＰ２Ｐプロキシの中に事前に記憶することがありうるであろう。

−Ｐ２Ｐモジュールは、インタワーキングモジュール１４からのメッセージの中のデータを用いて３０、動画待ち行列１１の中のデータ待ち行列、および、セッションＩＤと、データ待ち行列へのポインタと、追加情報、すなわち、ステップ９で受信されたかまたは、コンテンツ取り出しプロセスを管理するときに使用されてもよいメタデータとを含むプロキシテーブル１２の中のエントリをインスタンス化する。

交渉３１が、Ｐ２Ｐモジュール１０とＭＣＤＮとの間で行われ、結果として、コンテンツがＭＣＤＮからダウンロードされて、動画待ち行列１１に置かれる。コンテンツをダウンロードするのに用いられる方法によって、例えば複数の発信元からか単一の発信元からかによって、データ待ち行列にどのようにデータが投入されるかが判定される。データは、ユーザへの配信が行われる前に、例えばコンテンツ全体が受信されるまで、待ち行列に入れられてもよいだろうし、あるいは、データは、ダウンロードする間にユーザに配信されてもよいであろう。

−コンテンツがダウンロードされたことがインタワーキングモジュール１４に通知される３２。この通知は、セッションＩＤに加えられる。このステップには２つの選択肢がある。どちらの選択肢を用いるかの選択は、Ｐ２Ｐプロキシの中のポリシーによって決定されてもよい。Ｐ２Ｐモジュールが、コンテンツのダウンロードが完了した時に通知を送信するか、または、コンテンツの個々のセグメントがダウンロードされた時に通知するか、いずれか一方である。コンテンツは、エンドユーザに対してストリームされるであろうから、第２の選択肢が用いられる場合には、シーケンシャルなセグメントについて通知が行われるであろうと仮定される。

−インタワーキング機能が、コンテンツがトランスコードされる必要があるかどうか、すなわち、動画信号を、異なるビットレート、フレームレート、フレームサイズ、または圧縮標準のような、異なる形式を持つ別の信号に変換する必要があるかどうか、そして、顧客に対するストリームはユニキャストであろうかまたはマルチキャストであろうかを、セッションＩＤを用いて判定する３３。この例では、ストリームはユニキャストであろう。

−トランスコーディングの詳細情報が、トランスコードされることになるコンテンツに対する動画待ち行列１１へのポインタと一緒にトランスコーダ１５へ送信される３４。

−命令が、インタワーキングモジュール１４からＰ２Ｐモジュールへと送信され３５、残りの動画シーケンスをトランスコーダ１５に直接送信するようにＰ２Ｐモジュールに要求する。

−トランスコーダ１５は、動画待ち行列１１の中のＰ２Ｐモジュールデータ待ち行列から、トランスコードされることになるコンテンツを入手するであろう３６。次いで、このデータは、その元の形式からＳＴＢおよび発信要求にとって適切な形式へとトランスコードされる。例外：場合によっては、コンテンツはすでに、正確な形式になっていることがあり、その場合、トランスコーダは、コンテンツを取り出すだけであって、コンテンツを操作はしないであろう。

−コンテンツが、ユニキャスト／マルチキャストモジュール１６／１７へ送信される３７。

−ユニキャスト／マルチキャストモジュールが、コンテンツをＳＴＢデコーダへストリームするであろう３８。この例では、コンテンツはユニキャストされるであろう。

−コンテンツは、ＳＴＢによって復号され、表示される３９。

留意すべきだが、上記に示すシグナリングは一例であって、変形がありうる。

図４は、本発明の第２の実施形態において、オペレータのブロードバンドネットワーク２Ｂとインターネットネットワーク３Ｂとを備えたコンテンツ配信システムを開示する。オペレータの管理ドメイン内にモバイルＩＰＴＶのセットトップボックス４Ｂがあることを示す。インターネットネットワークは、この例では、Ｊｏｏｓｔ ５Ｂ、ＹｏｕＴｕｂｅ ６Ｂ、ＢｉｔＴｏｒｒｅｎｔ ７Ｂのような多様なＭｅｄｉａ Ｃｏｎｔｅｎｔ Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｎｅｔｗｏｒｋ ＭＣＤＮを備えているが、それらに限定されない。図４に、１つのネットワークノードを開示する。ネットワークノードは、インターネットネットワーク側とオペレータネットワーク側の両方にアクセスすることができるＭＣＤＮプロキシ１Ｂである。本発明によるプロキシ機能は、この例ではＪｏｏｓｔドメイン、ＹｏｕＴｕｂｅドメイン、およびＢｉｔＴｏｒｒｅｎｔドメインから取り出された動画コンテンツを変換して送信することができる。Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｅｎｔ Ｇｕｉｄｅ ＥＣＧポータル１８Ｂは、この実施形態では、ＭＣＤＮプロキシの外側に位置する。ＥＣＧは、ユーザが従来のコンテンツおよび新しいコンテンツ（この例ではＪｏｏｓｔコンテンツ、ＹｏｕＴｕｂｅコンテンツ、ＢｉｔＴｏｒｒｅｎｔコンテンツ）を閲覧してそれらにアクセスできるようにするために旧式のＳＴＢが使用するものである。従って、ＥＣＧは、既存のＳＴＢの能力を活用しなければならないであろう。上述のように、ＥＣＧを生成するのに静的またはオンデマンドという２つの方法を用いることができる。どちらの方法も、ＭＣＤＮにクエリを行うためかまたはＭＣＤＮがＥＣＧサーバに更新をプッシュするためかいずれかのためにＥＣＧサーバが使用できる、所定のインタフェースを利用するであろう。

図５は、ＭＣＤＮプロキシ１Ｂを概略的に開示する。プロキシは、オープンなインターネットネットワーク、この例ではインターネットのＪｏｏｓｔ部分、ＹｏｕＴｕｂｅ部分、ＢｉｔＴｏｒｒｅｎｔ部分へのインタフェースを有する。また、プロキシ１Ｂは、適切なトランスポートプロトコル、例えばマルチキャストまたはユニキャストを用いてコンテンツをＳＴＢ ４Ｂに配信することができるストリーミングサーバへのインタフェースを有する。ＥＣＧポータル１８Ｂは、ＭＣＤＮプロキシとＳＴＢ ４Ｂとの間に位置する。

プロキシ１Ｂは、ＭＣＤＮモジュール１０Ｂを備える。実際、図５から分るように、この例のＭＣＤＮモジュールは、３つの異なるモジュール、すなわち、ＪｏｏｓｔモジュールとＹｏｕＴｕｂｅモジュールとＢｉｔＴｏｒｒｅｎｔモジュールとを備える。どのモジュールも、既存のネットワークのうちの１つに対応する。各ＭＣＤＮモジュールの機能は、すでに図２で説明したＰ２Ｐモジュールに対応する。各ＭＣＤＮモジュールは、インタワーキングモジュール１４Ｂに接続しており、それが次に、トランスコーダ １５Ｂに接続する。インタワーキングモジュールとトランスコーダとはいずれも、図２ですでに説明した対応するエンティティと同じ機能を有する。ＭＣＤＮプロキシは、トランスコーダを介してストリーミングサーバ１７Ｂに接続しており、それが次に、ＳＴＢ ４Ｂに接続する。第１の実施形態の場合と同様、インタワーキングモジュールは、取り出し要求をＳＴＢ ４Ｂのユーザから受信するであろう。取り出し要求は、インタワーキングモジュールにおいて、Ｊｏｏｓｔ要求かＹｏｕＴｕｂｅ要求かまたはＢｉｔＴｏｒｒｅｎｔ要求にマップされるであろう。次いでインタワーキングモジュールは、問題のネットワークに対して要求を行う。トランスコーダ１５Ｂは、外部インタフェース上で受信したコンテンツが、内部インタフェース上で送出されるのを可能にする。トランスコーディング機能は、特定のアプリケーションＪｏｏｓｔ、ＹｏｕＴｕｂｅ、ＢｉｔＴｏｒｒｅｎｔからのコンテンツがどのようにして最初に所与のメディア形式にトランスコードされ、次いで標準のトランスポートプロトコルを介してＳＴＢに配信されるかについて記述する一組の規則から成る。ストリーミングサーバ１７Ｂは、１つまたは２つのモジュール、すなわちユニキャストモジュールおよび／またはマルチキャストモジュールを備えてもよい。セットトップボックスがどのようにしてコンテンツを要求したかによって、それがＲＴＳＰ要求であった場合、ストリーミングサーバは、コンテンツをＳＴＢにユニキャストするであろうし、また、ＳＴＢがマルチキャスト用のＩＧＭＰ加入を行う場合、ストリーミングサーバは、コンテンツをセットトップボックスにマルチキャストするであろう。ＥＣＧポータルは、ＳＴＢ ４ｂとＭＣＤＮプロキシとに接続している。ＥＣＧとプロキシとの間にはある関係がなければならない。ＥＣＧは、各コンテンツ項目へのリンクを維持する。ＳＴＢからＥＣＧへのコンテンツ要求の後、リンク仕様が、要求の一部として（例えばＲＴＳＰ ＰＬＡＹコマンドの中で）ＳＴＢからＭＣＤＮプロキシへ転送される。あるいは、ＥＣＧが、ＭＣＤＮプロキシへのコンテンツへのリンクを指定してもよい。

必要なコンテンツをインターネットドメインから取り出すためにＳＴＢ ４Ｂによって用いられる信号シーケンスの基本的な一例は、以下のようであってもよい。

−利用可能なコンテンツをＳＴＢがＥＣＧから受信した後、ユーザが、ダウンロードされることになる所望のコンテンツを選択する。この例では、ＭＣＤＮ Ｊｏｏｓｔからのコンテンツが選択される。

−取り出し要求が、ＳＴＢ ４ＢからＭＣＤＮプロキシ１Ｂの中のインタワーキングモジュール１４Ｂへ送信される。

−本セッションを識別するため、セッションＩＤがインタワーキングモジュール１４Ｂの中で生成される。

−インタワーキングモジュール１４Ｂが、セッションＩＤとコンテンツ名と追加のメタデータとを含むメッセージをＭＣＤＮ Ｊｏｏｓｔモジュール１０Ｂへ処理の目的で送信する。

−データ待ち行列およびプロキシテーブルの中のエントリが、ＭＣＤＮ Ｊｏｏｓｔモジュール１０Ｂの中でインスタンス化される。

−コンテンツがＭＣＤＮ Ｊｏｏｓｔネットワークからダウンロードされて、ＭＣＤＮ Ｊｏｏｓｔモジュール１０Ｂの中に置かれる。

−コンテンツがダウンロードされることが、インタワーキングモジュール１４Ｂに通知される。

−トランスコーディングの詳細情報が、トランスコードされることになるコンテンツに対するポインタと一緒にインタワーキングモジュール１４Ｂからトランスコーダ１５Ｂへ送信される。

−命令がインタワーキングモジュール１４からＭＣＤＮ Ｊｏｏｓｔモジュール１０Ｂへと送信され、動画シーケンスをトランスコーダ１５Ｂに直接送信するようにモジュールに要求する。

−トランスコーダ１５Ｂに受信されたデータが、その元の形式からＳＴＢ４Ｂおよび発信要求にとって適切な形式へとトランスコードされる。

−コンテンツがストリーミングサーバ１７Ｂへ送信される。

−ストリーミングサーバが、コンテンツをＳＴＢ ４Ｂへストリームし、コンテンツは表示されるであろう。

図６は、本発明の方法のうちの一部の必須のステップを図解するフローチャートを開示する。本フローチャートは、前に示した図と一緒に参照していただきたい。フローチャートには、以下のステップが含まれる。

−外部ドメインからコンテンツを取り出すための要求が、セットトップボックスからネットワークノードに受信される。このステップを図ではブロック１０１で示す。

−必要なコンテンツが、外部ドメインからネットワークノードへ取り出される。このステップを図ではブロック１０２で示す。

−必要なコンテンツが、ネットワークノード内で、セットトップボックスを介してアクセス可能な形式に変換される。このステップを図ではブロック１０３で示す。

−変換されたコンテンツは、ネットワークノードからセットトップボックスへ配信される。このステップを図ではブロック１０４で示す。

本発明を実施するのに用いられうるノードとシステムとを、図１、２、４、および５に示す。列挙した項目を、図では個別の要素として示す。しかし、本発明の実際の実装では、それらは他の電子デバイス、例えばデジタルコンピュータ（プロセッサ）の分離不可能なコンポーネントであってもよい。従って、上記の動作は、プログラム記憶媒体に実装されうるソフトウェア（プログラム）として実装されてもよい。プログラム記憶媒体は、搬送波、コンピュータディスク（磁気または光学（例えばＣＤまたはＤＶＤまたはそれらの両方）、不揮発性メモリ、テープ、システムメモリ、およびコンピュータハードドライブのうちの１つ以上の中に実施されたデータ信号を含む。

本発明は、上記および図に示した実施形態に限定されるのではなく、添付の請求項の範囲内で修正することができる。本発明のシステムおよび方法は、例えば、第三世代パートナシッププロジェクト（３ＧＰＰ）とＥｕｒｏｐｅａｎ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｔａｎｄａｒｄｓ Ｉｎｓｔｉｔｕｔｅ（ＥＴＳＩ）とＡｍｅｒｉｃａｎ Ｎａｔｉｏｎａｌ Ｓｔａｎｄａｒｄｓ Ｉｎｓｔｉｔｕｔｅ（ＡＮＳＩ）とその他の標準の通信ネットワークアーキテクチャとのうちのいずれかに実装されてもよい。他の例としては、ｔｈｅ Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｅｌｅｃｔｒｉｃａｌ ａｎｄ Ｅｌｅｃｔｒｏｎｉｃｓ Ｅｎｇｉｎｅｅｒｓ（ＩＥＥＥ）またはＴｈｅ Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ（ＩＥＴＦ）またはＴｈｅ Ｂｒｏａｄｂａｎｄ Ｆｏｒｕｍがある。

限定の目的ではなく説明の目的で、本記述は、本発明を理解してもらうために特定の詳細、例えば特定のコンポーネント、電子回路機構、技術等を記述する。しかし、当業者には明白であろうが、本発明は、これらの特定の詳細から逸脱した他の実施形態でも実施されうる。他の例では、周知の方法、デバイス、および技術等の詳細記述は、不要な詳細で記述をあいまいにしないため、省略する。個々の機能ブロックを１つ以上の図面の中に示す。当業者であれば、諸機能が、個別部品または多機能ハードウェアを用いて実装されうることを理解するであろう。処理機能は、プログラム式マイクロプロセッサまたは汎用コンピュータを用いて実装されてもよい。本発明は、上記の、かつ、図示した実施形態に限定されるのではなく、添付の請求項の範囲内で修正されうる。

本発明は、もちろん、上記の、かつ、図示した実施形態に限定されるのではなく、添付の請求項の範囲内で修正されうる。

Claims (22)

1. ＩＰＴＶサービスプロバイダのドメイン（２，２Ｂ）の外部に位置する外部ドメイン（３，３Ｂ）からのコンテンツにＩＰＴＶセットトップボックス（４，４Ｂ）がアクセスするための方法であって、
   必要なコンテンツを前記外部ドメインから取り出すステップと、
   前記必要なコンテンツを、前記ＩＰＴＶセットトップボックスを介してアクセス可能な形式へ変換するステップと
   を含むことを特徴とする方法。
2. 前記ＩＰＴＶセットトップボックス（４，４Ｂ）からネットワークノード（１，１Ｂ）への要求であって、前記外部ドメイン（３，３Ｂ）からコンテンツを取り出す前記要求を受信するステップと、
   前記外部ドメイン（３，３Ｂ）から前記ネットワークノード（１，１Ｂ）へ前記必要なコンテンツを取り出すステップと、
   前記ネットワークノード（１，１Ｂ）において、前記外部ドメインからの前記必要なコンテンツを前記ＩＰＴＶセットトップボックスを介してアクセス可能な形式へ変換するステップと、
   前記ネットワークノード（１，１Ｂ）から前記ＩＰＴＶセットトップボックス（４，４Ｂ）へ、前記変換したコンテンツを配信するステップと
   を含むことを特徴とする請求項１に記載の方法。
3. 前記ＩＰＴＶセットトップボックス（４，４Ｂ）からネットワークノード（１，１Ｂ）への取り出し要求であって、必要なコンテンツの詳細情報と、特定した配信詳細情報とを含む前記取り出し要求を受信するステップと、
   前記外部ドメイン（３，３Ｂ）のメデイアコンテンツ配信ネットワーク（ＭＣＤＮ）から必要なコンテンツを前記ネットワークノード（１，１Ｂ）へダウンロードするステップと、
   前記ネットワークノード（１，１Ｂ）において必要とされる前記配信詳細情報を適用するステップと
   をさらに含むことを特徴とする請求項２に記載の方法。
4. 前記取り出し要求は、前記ネットワークノード（１，１Ｂ）において、前記メデイアコンテンツ配信ネットワーク（ＭＣＤＮ）に適した形式に変換されることを特徴とする請求項３に記載の方法。
5. 前記必要とされる配信詳細情報は、マルチキャスト又はユニキャストを含むトランスコーディング仕様を含むことを特徴とする請求項３又は４に記載の方法。
6. 前記必要とされる配信詳細情報は、ビットレート、解像度、又はコーデックを含む、前記ＩＰＴＶセットトップボックスに適した、必要なコンテンツの形式を含むことを特徴とする請求項３乃至５の何れか１項に記載の方法。
7. 必要とされる配信詳細情報の少なくとも一部は、前記ネットワークノード（１，１Ｂ）において予め格納されていることを特徴とする請求項６に記載の方法。
8. 前記ネットワークノード（１）において、前記メデイアコンテンツ配信ネットワーク（ＭＣＤＮ）からのコンテンツに対して、内部シグナリング要求に起因したセッションを識別するセッションＩＤを生成するステップをさらに含むことを特徴とする請求項３乃至７の何れか１項に記載の方法。
9. 前記セッションＩＤは、前記配信詳細情報及びコンテンツの形式とともに前記セッションを集約するために前記ネットワークノード（１，１Ｂ）において使用されることを特徴とする請求項８に記載の方法。
10. 前記ネットワークノード（１，１Ｂ）において、前記セッションＩＤと開始データ待ち行列へのポインタとを含む、テーブル（１２）内のエントリをインスタンス化するステップをさらに含むことを特徴とする請求項８又は９に記載の方法。
11. ＩＰＴＶサービスプロバイダのドメイン（２，２Ｂ）の外部に位置する外部ドメイン（３，３Ｂ）からのコンテンツにアクセスするＩＰＴＶセットトップボックス（４，４Ｂ）に適した装置であって、
    必要なコンテンツを前記外部ドメインから取り出し、前記必要なコンテンツを、前記ＩＰＴＶセットトップボックスを介してアクセス可能な形式へ変換するネットワークノード（１，１Ｂ）を備えることを特徴とする装置。
12. 前記ＩＰＴＶセットトップボックス（４，４Ｂ）からネットワークノード（１，１Ｂ）への要求であって、前記外部ドメイン（３，３Ｂ）からコンテンツを取り出す前記要求を受信する手段と、
    前記外部ドメイン（３，３Ｂ）から前記ネットワークノード（１，１Ｂ）へ前記必要なコンテンツを取り出す手段と、
    前記ネットワークノード（１，１Ｂ）において、前記外部ドメインからの前記必要なコンテンツを前記ＩＰＴＶセットトップボックスを介してアクセス可能な形式へ変換する手段と、
    前記ネットワークノード（１，１Ｂ）から前記ＩＰＴＶセットトップボックス（４，４Ｂ）へ、前記変換したコンテンツを配信する手段と
    を備えることを特徴とする請求項１１に記載の装置。
13. 前記ＩＰＴＶセットトップボックス（４，４Ｂ）からネットワークノード（１，１Ｂ）への取り出し要求であって、必要なコンテンツの詳細情報と、特定した配信詳細情報とを含む前記取り出し要求を受信する手段と、
    前記外部ドメイン（３，３Ｂ）のメデイアコンテンツ配信ネットワーク（ＭＣＤＮ）から必要なコンテンツを前記ネットワークノード（１，１Ｂ）へダウンロードする手段と、
    前記ネットワークノード（１，１Ｂ）において必要とされる前記配信詳細情報を適用する手段と
    をさらに備えることを特徴とする請求項１２に記載の装置。
14. 前記取り出し要求は、前記ネットワークノード（１，１Ｂ）において、前記メデイアコンテンツ配信ネットワーク（ＭＣＤＮ）に適した形式に変換されることを特徴とする請求項１３に記載の装置。
15. 前記必要とされる配信詳細情報は、マルチキャスト又はユニキャストを含むトランスコーディング仕様を含むことを特徴とする請求項１３又は１４に記載の装置。
16. 前記必要とされる配信詳細情報は、ビットレート、解像度、又はコーデックを含む、前記ＩＰＴＶセットトップボックスに適した、必要なコンテンツの形式を含むことを特徴とする請求項１３乃至１５の何れか１項に記載の装置。
17. 必要とされる配信詳細情報の少なくとも一部は、前記ネットワークノード（１，１Ｂ）において予め格納されていることを特徴とする請求項１６に記載の装置。
18. 前記ネットワークノード（１）において、前記メデイアコンテンツ配信ネットワーク（ＭＣＤＮ）からのコンテンツに対して、内部シグナリング要求に起因したセッションを識別するセッションＩＤを生成する手段をさらに備えることを特徴とする請求項１３乃至１７の何れか１項に記載の装置。
19. 前記セッションＩＤは、前記配信詳細情報及びコンテンツの形式とともにセッションを前記集約するために前記ネットワークノード（１，１Ｂ）において使用されることを特徴とする請求項１８に記載の装置。
20. 前記ネットワークノード（１，１Ｂ）において、前記セッションＩＤと開始データ待ち行列へのポインタとを含む、テーブル（１２）内のエントリをインスタンス化する手段をさらに備えることを特徴とする請求項１８又は１９に記載の装置。
21. ＩＰＴＶサービスプロバイダのドメイン（２，２Ｂ）の外部に位置する外部ドメイン（３，３Ｂ）からのコンテンツにアクセスするＩＰＴＶセットトップボックス（４，４Ｂ）に適したネットワークノード（１，１Ｂ）であって、
    前記外部ドメイン（３，３Ｂ）からコンテンツを取り出す前記要求を受信する手段と、
    前記外部ドメイン（３，３Ｂ）から、前記必要なコンテンツを取り出す手段と、
    前記外部ドメインからの前記必要なコンテンツを前記ＩＰＴＶセットトップボックスを介してアクセス可能な形式へ変換する手段と、
    前記ネットワークノード（１，１Ｂ）から、前記変換したコンテンツを配信する手段と
    を備えることを特徴とするネットワークノード。
22. 請求項１乃至１０の何れか１項に記載の方法における各ステップをコンピュータに実行させるためのプログラム。

Images