JP2009539304A - マルチキャスト配信 - Google Patents

Abstract

通信ネットワーク（３０５）において、ファイルのマルチキャストの配信を制御するための方法およびノードであって、このマルチキャスト配信は、通信ネットワークにおいて、要求されたユニキャストファイル配信の量を削減するように構成されている。ＩＰＴＶ終端機能（ＩＴＦ；３１０ａ、ｂ、ｃ）のブラウザが、ファイルを必要としており、ファイル配信に対するユニキャスト要求がＡｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ Ｐｌａｔｆｏｒｍ（ＡＳＰ；３００）へ送信される前に、ＩＦＴのキャッシュ（３１６）にファイルコンテンツの問い合わせを行う。キャッシュ内に記憶されているファイルは、ここで提案されるマルチキャストメカニズムを介して、前もってＩＦＴへ配信されている。ファイルコンテンツがキャッシュに記憶されていない場合、ユニキャスト要求がＡＳＰへ送信される。また、各ユニキャスト要求は、マルチキャストコントローラ（ＭＣＣ；３２０）にも転送され、ここで、マルチキャストコントローラは、要求されたファイルが、マルチキャストチャネル上で複数の別のＩＦＴにも送信されるべきか判定する。マルチキャストチャネルを聴取している各ＩＦＴでは、受信されたコンテンツがフィルタリングメカニズムに従って、選択的に処理され、また、受信されたファイルは、例えば、後の検索に備えてキャッシュに記憶されてもよい。
【選択図】 なし

Description

本願は、２００６年６月２日に出願された米国仮特許出願６０／８０３７２９からの優先権を主張し、その教示内容全体は参照により本願に組み込まれる。

本発明は、一般に、ファイルコンテンツをマルチキャストチャネルで配信するための効率的な配信メカニズムを提供し、かつ、受信側でコンテンツの柔軟な受信および処理を提供する方法および装置に関するものである。

ＩＰＴＶは、ブロードキャストされるＴＶサービスをＩＰネットワーク上で配信するための新たな技術である。現在有力なＩＰＴＶサービスはＢｒｏａｄｃａｓｔＴＶであり、この場合、通常の非ＩＰＴＶチャネルおよびそれほど浸透していない他のチャネルは、スーパーヘッドエンド（super head-end：専用電波中継局）から、典型的にはセット・トップ・ボックス（ＳＴＢ）を有する複数のエンドユーザまで、ブロードバンドネットワークを介して送信される。

従来のブロードキャストＴＶシステム、例えば、Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ−Ｔｅｒｒｅｓｔｒｉａｌ（ＤＶＢ−Ｔ：デジタルビデオブロードキャスティング−テレストリアル）およびＤｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ−Ｓａｔｅｌｌｉｔｅ（ＤＶＢ−Ｓ：デジタルブロードキャスティング−サテライト）では、ブロードキャストチャネルはアプリケーションレイヤ情報の送受信専用とされている。アプリケーションレイヤ情報は、電子番組表（ＥＰＧ：Ｅｌｅｃｔｒｏｎｉｃ Ｐｒｏｇｒａｍ Ｇｕｉｄｅ）を含んでもよく、この電子番組表とは画面に表示されるテレビ番組の放送予定案内であり、これを使って視聴者は、例えば、リモートコントロール、キーボード、または電話のキーパッドを用いて、時刻、題名、ジャンル等によって、コンテンツをナビゲートし、選択し、発見することができる。ＥＰＧ情報は、典型的には、マークアップ言語、例えば、ＸＭＬである。ＳＴＢ上で動作するアプリケーションは、この情報を処理して、それをＳＴＢに接続されているＴＶ画面上に描画してもよい。

例えば、ＳＴＢ／ＴＶのようなＩＰＴＶ用の受信機、ここからはＩＰＴＶ Ｔｅｒｍｉｎａｔｉｎｇ ｆｕｎｃｔｉｏｎ（ＩＴＦ：ＩＰＴＶ終端機能）と呼ぶことにするが、そのようなＩＰＴＶ用の受信機とネットワークの間の通信に適したものとして、一般に４つの通信手段がある。図１ａ−１ｄは、これらの４つの異なるコンテンツの送信方法を示している。

図１ａは、クライアント専用ストリーミングを介する送信を示している。クライアント専用ストリーミングは、指定のエンドユーザにリアルタイムでオーディオおよびビデオの少なくとも一方を配信するために適している通信手段である。クライアント専用ストリーミングは、制御プロトコルであるＲｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ（ＲＳＴＰ：リアルタイム・ストリーミング・プロトコル）および転送プロトコルであるＲｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ（ＲＴＰ：リアルタイム・トランスポート・プロトコル）に基づいて提供されてもよく、通常はオンデマンドで使用される。図１ａでは、３つのＩＰＴＶ終端機能（ＩＴＦ）１０１−１０３がＡｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒ Ｐｌａｔｆｏｒｍ（ＡＳＰ：アプリケーション・サーバ・プラットフォーム）１００に接続されていて、ＩＰＴＶサービスをＩＴＦに提供する。各ＩＴＦは、共通ＡＳＰ１００から別のストリーム化コンテンツをオンデマンドで配信するように要求してもよい。ＩＴＦ１ １０１は、クライアント専用ストリーミングを介して要求されたストリーム化コンテンツ１０４をＡＳＰ１００から受信し、一方、ＩＴＦ２ １０２は、ストリーム化コンテンツ１０５を受信し、そして、ＩＴＦ３ １０３は、データコンテンツの第３のストリーム１０６を受信する。図１ａに示される各ストリームは、別個の独立したストリーミングセッションを介して配信される。

クライアント専用プルは、ユーザの介入に何ら依存することなく、クライアントが自動的にデータを要求できるようにする機能に基づくもう１つの通信手段である。即ち、データは、所定の仕様に従って配信される。図１ｂに示されるこの通信手段によって、ＩＴＦは、ユーザの介入に何ら頼る依存することなく、自動的にコンテンツを要求することができる。即ち、コンテンツは、各ＩＴＦについて一意である場合がある、所定の仕様に従って配信される。図では、ＩＴＦ１ １０１、ＩＴＦ２ １０２およびＩＴＦ３ １０３は、それぞれのコンテンツ１０４、１０５および１０６を、相互に独立して受信する。

図１ｃに示されるクライアント専用プッシュは、さらに別の通信代替手段である。クライアント専用プッシュによって、要求されたデータを、サーバに記憶されている所定のルールやプリファレンスに従って、サーバから自動的に受信することが可能になる。しかしまがら、この通信代替手段は、ＡＳＰのサーバに依存しており、そのサーバが単独でデータコンテンツを様々なＩＴＦにプッシュすることができ、この場合、どのコンテンツを配信するか、さらに各コンテンツをいつ配信するかについては、各ＩＴＦについて前もって作成される仕様に依存する。

いかなるブロードバンドシステムであろうと、往々にして同一の情報を多数のＩＴＦに送信する必要が生じる。この情報を各ＩＴＦに個別に送信することは可能ではあるが、いくつかの理由で望ましくない。第１に、送信対象の情報は、サイズが非常に大きい可能性があり、使用されるアクセスネットワークの帯域幅リソースをかなり必要とする可能性がある。第２に、ホームネットワーク環境内でトラフィックの優先順位付けがない場合、この情報が他のリアルタイムトラフィックと干渉する可能性がある。最後に、すべてのＩＴＦを宛先とする制御トラフィックが集中することで、コアネットワークに潜在的な輻輳を引き起こし、収益を創出するトラフィックに影響を及ぼす可能性がある。

上記の３つの通信手段にはいずれも、上述の欠点がある。従って、別の通信手段が必要とされている。

通常の専用プッシュは、同一データコンテンツを複数のＩＴＦ１０１−１０３に配信する通信手段である。図１ｄでは、上述のアーキテクチャを使用して、一般的な専用プッシュのデータ配信の例を示している。一般的なプッシュは、応答時間とネットワーク負荷の削減のために不可欠なメカニズムであり、これは、ＡＳＰ１００と、接続されているＩＴＦ１０１−１０３との間でデータコンテンツを配信するためのＭｕｌｔｉ−ｃａｓｔ Ｄａｔａ Ｃｈａｎｎｅｌ（ＭＤＣ：マルチキャスト・データ・チャネル）に依存する。ＭＤＣは、例えば、ＥＰＧウェブページ、メタデータファイル、対話トリガ・ファイル、ファームウェア・アップグレード、アラートメッセージの配信等、様々なタイプの情報転送に適している。

図１ｄでは、３つのＩＴＦはいずれも、同一データコンテンツ１０４をＭＤＣを介して同時に受信する。

しかしながら、オペレータ事業者の観点からは、上述の従来型のＩＰＴＶ ＥＰＧには重大な欠点がいくつかあり、一般的なプッシュと共に使用する場合にも、様々なＳＴＢ製造業者が様々なユーザインタフェースを提供するという点で、それがいえる。これによってオペレータ事業者は、自身のＩＰＴＶサービスをエンドユーザに対してブランド化することが一層難しくなる。また、これによって、新しいユーザインタフェースおよびサービスを導入することも、一層難しくなる。加えて、新規のアプリケーションをパーソナライズする可能性は非常に制限される。

上述のような様々な欠点があるため、一部の新しいＩＰＴＶシステムは、オペレータのブランドによる、パーソナライズされたウェブタイプのインタフェースを取得するために、ウェブブラウザ技術、例えば、ＨＴＭＬ、ｊａｖａｓｃｒｉｐｔまたはスケーラブル・ベクトル・グラフィクス（ＳＶＧ）が使用される、シンクライアントという概念を検討中である。

それでもやはり、ブラウザタイプのインタフェースの重大な欠点は、それが、クライアントサーバ技術に固有の欠点を示してしまうことであり、すなわち、多くのユーザがＥＰＧを同時に閲覧すると、サーバおよび中間ネットワーク上に著しい負荷をもたらしかねないことである。

本発明の目的は、上述の諸問題に取り組むことである。詳細には、本発明の目的は、多数の加入者に効率的にＩＰＴＶコンテンツの送信を提供するメカニズムを見い出すことである。また、例えば、ＩＴＦのような受信機内でファイルのコンテンツを選択的に受信して処理する一層柔軟なメカニズムを取得することも望ましい。

これらのおよびその他の目的は、以下に添付する独立請求項に従う方法と、受信機とマルチキャストコントローラとを提供することによって達成することができる。

一態様に従えば、本発明は、マルチキャストチャネルを聴取している複数の受信機に対するファイル配信の方法を含んでいる。この方法は、１つ以上のＡｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒ Ｐｌａｔｆｏｒｍ（ＡＳＰ：アプリケーション・サーバ・プラットフォーム）からのファイル配信に対する要求を、Ｍｕｌｔｉ−Ｃａｓｔ Ｃｏｎｔｒｏｌｌｅｒ（ＭＣＣ：マルチキャストコントローラ）で受信してキューに入れることを含んでいる。ここで、各要求は、その要求および関連するファイルコンテンツをどのように処理するかについての条件を指定する少なくとも１つの属性を含んでいる。この方法は、マルチキャストチャネル上でファイルコンテンツがＭＣＣから受信機へ配信されることが判定されている時点で、各ＡＳＰからファイルコンテンツを検索して取得することをさらに含んでいる。次いで、各ファイル配信は、少なくとも１つの属性に基づいてスケジュール設定される。ファイル記述情報は、１つ以上のファイルエントリにフォーマットされて送信される。ここで、その各々は、ファイルコンテンツに関連付けられている。次いで、ファイルコンテンツは、１つ以上のファイルインスタンスにフォーマットされて配信される。

要求を受信してキューに入れる前に、要求されたファイルコンテンツは、それぞれのＡＳＰからユニキャストを介して要求元の受信機に配信されている。

別の態様に従えば、本発明は、また、通信ネットワーク内で、マルチキャストチャネルを聴取している受信機でファイルコンテンツを選択的に受信するための方法も含んでいる。この方法は、１つ以上のファイルエントリをマルチキャストチャネル上で受信することを含んでいる。ここで、各ファイルエントリは、１つ以上の属性と、それぞれのファイルエントリを１つ以上のファイルインスタンスに結び付ける１つの識別子とを備えていて、各ファイルインスタンスは、ファイルコンテンツおよび同一の識別子を備える。各ファイルエントリの１つ以上の属性と、１つ以上の選択基準とを照合して、受信機に対する受信要件を指定することによって、受信機に関心のあるファイルインスタンスが識別される。次いで、ファイルコンテンツが１つ以上のファイルインスタンスで受信される。ここで、受信機に関心のあるファイルインスタンスが、ファイルインスタンスに関連する１つ以上の属性に従って処理され、一方、残りのファイルインスタンスは廃棄される。

選択基準は、受信機が位置する地理的地域を示す「地域」、受信機の製造業者を示す「ブランド」、受信機のファームウェアを示す「バージョン」、現在の受信機ユーザの関心分野を示す「関心」、現在の受信機ユーザの最低格付けレベルを示す「格付け」、現在の受信機ユーザの最小年齢を示す「年齢」、あるいは、受信機上で現在視聴されているＴＶチャネルを示す「チャネル」のうち、少なくとも１つを備えてもよい。

この方法は、要求されているファイルコンテンツのためのキャッシュの問い合わせをさらに含んでも良い。ここで、キャッシュに記憶されているファイルコンテンツは、マルチキャスト配信を介してすでに受信機に配信されており、そして、ファイルコンテンツがキャッシュに記憶されている場合には、ファイルコンテンツはキャッシュから検索して取得される。しかしながら、ファイルコンテンツがキャッシュに記憶されていない場合には、ファイルコンテンツは、ユニキャスト配信を介してＡＳＰから検索して取得される。

要求されたファイルコンテンツが、キャッシュに記憶されていない場合、ユニキャスト配信を開始することに加えて、ユニキャスト配信に対する要求がＡＳＰからＭＣＣへと転送される。ＭＣＣでは、要求されたファイルコンテンツもマルチキャストチャネル上で配信されるべきかが判定される。

判定するステップにおいて、例えば、経験されているファイル要求パターンおよび記憶されているファイル配信パターンの統計値の少なくとも一方等の基準が、考慮されてもよい。

各ファイルエントリは、典型的には、それぞれの要求から検索して取得された１つ以上の属性と、ファイルエントリをそれぞれの１つ以上のファイルインスタンスに結び付ける一意の識別子とを備えており、一方、関連付けられた１つ以上のファイルインスタンスは、ファイルコンテンツと、同一の識別子とを備える。

識別するステップの結果として、関心のあるファイルインスタンスの識別子と、関連する属性とを備える、選択リストが更新されても良い。この場合、選択リストは、ファイルインスタンスをフィルタリングする場合と、受信した関心のあるファイルインスタンスを処理する場合とに使用される。

上述の態様のうちのいずれかに従って使用されることになる属性は、例えば、一意のＵＲＬ識別を指定する「コンテンツ位置」、使用される情報フォーマットを指定する「コンテンツタイプ」、ファイルインスタンス間の優先順位を指定する「優先度」、ファイルインスタンスを処理する必要があることを指定する「基準」、その時間の前にファイルインスタンスがＭＤＣ上で送信されなければならない時間を指定する「ステイル時間」、ファイルインスタンスがいつ無効になるかを指定する「有効時間」、あるいはどのようにファイルインスタンスが処理されるべきかを指定する「タイプ」のうち、１つ以上であってもよい。

「タイプ」という属性は、例えば、ファイルインスタンスがＩＴＦキャッシュに記憶されるべきことを示す「キャッシュ」、ファイルインスタンスのコンテンツがＩＴＦの画面上に表示されるべきことを示す「表示」、ファイルインスタンスのコンテンツがファームウェアのアップグレードのために使用されるべきことを示す「アップグレード」、ファイルインスタンスが双方向セッションで使用されるべきことを示す「双方向性メッセージ」、受信機が別のＭＤＣチャネルに接続すべきであることを示す「チャネルに接続」、あるいは、受信機が現在のＭＤＣから離脱するべきであることを示す「チャネルを離脱」のうち、１つ以上であってもよい。

一実施形態では、関心のあるファイルインスタンスのコンテンツが、そのコンテンツは受信機のキャッシュに入れられるべきであることを示す属性に関連付けられてもよい。そのような状況では、コンテンツは、別の関連属性として指定される期間の間、キャッシュに記憶される。

上記のマルチキャストチャネルは、Ｍｕｌｔｉ−ｃａｓｔ Ｄａｔａ Ｃｈａｎｎｅｌ（ＭＤＣ：マルチキャスト・データ・チャネル）であってもよく、受信機は、ＩＰＴＶ Ｔｅｒｍｉｎａｔｉｎｇ ｆｕｎｃｔｉｏｎ（ＩＴＦ：ＩＰＴＶ終端機能）であってもよい。

また、上述のいくつかの実施形態に従って使用される各受信機は、１つ以上の所定の選択基準のリストを備えてもよい。この場合、各選択基準は、受信機用のファイルコンテンツ受信のルールを指定している。

別の態様に従えば、本発明は、マルチキャストチャネル上で配信されるファイルコンテンツを選択的に受信するための受信機に関するものである。この受信機は、マルチキャストチャネルに接続する手段と、少なくとも１つのファイルインスタンスで関連するファイルコンテンツを受信する前に、少なくとも１つのファイルエントリをマルチキャストチャネル上で受信する手段とを備える。この受信機は、受信したファイルエントリをフィルタリングすることによって受信機に関連すると考えられるファイルインスタンスを識別する手段をさらに備える。

ファイルインスタンスを識別する手段は、関連するファイルコンテンツを搬送する各ファイルインスタンスを、関連付けられたファイルエントリから検索して取得された少なくとも１つの属性に基づいて処理するようにさらに構成されてもよい。

加えて、受信機は、要求されているファイルコンテンツに対してキャッシュに問い合わせする手段を備えても良い。その場合、キャッシュに記憶されているファイルコンテンツは、マルチキャスト配信を介して受信機へ配信されている。また、この手段は、ファイルコンテンツがキャッシュに記憶されている場合には、キャッシュからファイルコンテンツを検索して取得し、ファイルコンテンツがキャッシュに記憶されていない場合には、ユニキャスト配信を介して、ＡＳＰからファイルコンテンツを検索して取得するように構成されてもよい。

一態様では、この識別する手段は、各ファイルエントリの１つ以上の属性と識別子とを識別し、そして、同一の識別子を介してファイルエントリに結び付けられているファイルコンテンツを備える、１つ以上のファイルインスタンスの各々を識別するように構成されてもよい。

さらに別の態様では、この識別する手段は、各ファイルエントリの１つ以上の属性と、受信機に対する受信要件を指定する１つ以上の選択基準とを照合することによって、受信したファイルエントリをフィルタリングするように構成されてもよい。

別の態様では、ファイルインスタンスを識別する手段は、関心のあるファイルインスタンスの識別子および関連する属性を備える、選択リストを更新するようにさらに構成されてもよい。

受信する手段は、関心のあるファイルインスタンスを受け入れて残りのファイルインスタンスを廃棄するために、選択リストを使用するように構成されてもよく、一方、ファイルインスタンスを識別する手段は、関連する１つ以上の属性に従って関心のあるファイルインスタンスを処理するように構成されてもよい。

別の態様では、受信機は、関連するファイルコンテンツを、これが属性と共に示される場合には、キャッシュに挿入する手段を備えてもよく、あるいは、既存のファイルコンテンツをそのファイルコンテンツの新しいバージョンと置換する手段を備えてもよい。

受信機は、ＩＴＦであってもよいが、セット・トップ・ボックス／ＴＶと、携帯電話と、パーソナルコンピュータ（ＰＣ）とのうちのいずれかであってもよい。

さらに別の態様に従えば、本発明は、ＭＣＣに関わっており、このＭＣＣは、そのＭＣＣによって管理されるマルチキャストチャネルを聴取する複数の受信機に対するマルチキャスト配信を管理する。ＭＣＣは、少なくとも１つのＳＰＰからファイル配信要求を受信する手段と、それらをキューに入れる手段を備える。その場合、各要求は、要求および関連するファイルコンテンツをどのように処理するかについての条件を各々が指定する、１つ以上の属性を備えている。また、ＭＣＣは、ファイルコンテンツがマルチキャストチャネル上でＭＣＣから受信機へ配信されるべきかどうか判定する手段も備える。このＭＣＣは、マルチキャストチャネル上で配信されるべきファイルコンテンツを検索する手段と、関連する要求の１つ以上の属性に基づいて各ファイル配信をスケジュール設定する手段もさらに備える。また、ＭＣＣは、ファイルコンテンツを１つ以上のファイルインスタンスにフォーマットして配信する前に、そのファイルコンテンツに関連するファイル記述情報を１つ以上のファイルエントリにフォーマットして配信する手段も備える。

このフォーマットして配信する手段は、１つ以上の属性と、ファイルエントリを関連するファイルコンテンツを搬送するファイルインスタンスに結び付ける一意の識別子とを備える各ファイルエントリをフォーマットして、関連するファイルコンテンツと同一の識別子とを備えるファイルインスタンスをフォーマットするように、構成されてもよい。

さらに別の態様では、判定する手段は、例えば、ＭＤＣであってもよいマルチキャストチャネル上でファイルコンテンツがＭＣＣから受信機へ配信されるべきかを判定する場合、経験したファイル要求パターンおよび記憶されたファイル配信パターンの統計値の少なくとも１つを考慮するように構成されている。

本発明の更なる特徴とその利点について、以下の詳細説明で説明する。

次に本発明について、添付の図面を参照しながら詳細に記述しよう。

簡単に言うと、本発明は、アプリケーションおよびメディアデータの配信のために使用されるマルチキャストチャネルが、柔軟性のあるユーザインタフェースと、ＩＰＴＶサービス用の効率的な配信メカニズムとを取得するために、クライアントブラウザの概念と組み合わせられるソリューションを提供する。

データコンテンツ、特に、ＩＰＴＶ関連のデータコンテンツの配信用の改良されたメカニズムを提供して、ＩＰＴＶ Ｔｅｒｍｉｎａｔｉｎｇ ｆｕｎｃｔｉｏｎｓ（ＩＴＦ：ＩＰＴＶ終端機能）と呼ばれるいくつかの受信機に対してＩＰＴＶサービスを提供するために、ネットワークの送信側に一層の柔軟性を提供すること、および、受信側に実装されることになる選択的受信メカニズムを提供することに着目して、例えば、ＭＤＣのような、マルチキャストチャネルを介する送信に基づく既知の技術をさらに発展させることを提案する。

ＦＬＵＴＥと呼ばれるＭｕｌｔｉ−Ｃａｓｔ Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ Ｐｒｏｔｏｃｏｌ（マルチキャストファイル配信プロトコル）は、マルチキャスト単方向チャネルを介してファイルを配信するためのデファクトスタンダードのプロトコルである。まだ、公式標準ではないとはいえ、例えば、ＯＭＡ ＢＣａｓｔ、３ＧＰＰのような各種のコンテクストにおいて、そして、マルチメディアファイルのマルチキャスト配信用に選択されるプロトコルとして、すでに採用されている。ＦＬＵＴＥは、大規模なスケーラブルマルチキャスト分配用に設計されている基本プロトコルである、Ａｓｙｎｃｈｒｏｎｏｕｓ Ｌａｙｅｒｅｄ Ｃｏｄｉｎｇ（ＡＬＣ：非同期階層符号化）、バージョン１において構築されている。

ＡＬＣは、任意のバイナリオブジェクトの転送を定義するものであり、通常は、転送されたデータオブジェクトをオブジェクトと呼ぶのに対して、ＦＬＵＴＥは、データオブジェクトをファイルと呼ぶ。このため、用語「オブジェクト」と用語「ファイル」は、本明細書を通して相互に交換して使用する。また、用語「オブジェクト」は、オブジェクト指向のコンテクストにおいて通常はそうとされる場合のオブジェクトではなく、このコンテクストで使用される場合には、転送されるデータ項目を示すことに注意されたい。

しかしながら、ファイル配信アプリケーションにとって、オブジェクトの転送だけでは十分ではない。オブジェクトが実際に何を表しているのか、終端システムが知る必要がある。ＦＬＵＴＥは、受信機が、受信したオブジェクトにこれらのパラメータを割り当てることが可能になる方法で、ファイルのプロパティをＡＬＣのコンセプトにシグナリングしてマッピングするためのメカニズムを規定する。このためＦＬＵＴＥは、転送の詳細と時間的制約を含めてファイル配信セッションをＡＬＣの上に構築して、ＡＬＣの専用の転送アプリケーションを定義する。また、ＡＬＣセッションの転送パラメータの帯域内信号だけでなく、配信されるファイルのプロパティの帯域内信号も提供する。加えて、ＦＬＵＴＥは、セッション内の複数のファイルの多重化に関連する詳細も指定する。

ＦＬＵＴＥは、実際のファイルコンテンツとは分離されているファイル記述情報の配信も提供する。ここで、ファイル記述情報は、通常、ＦＩＬＥ Ｄｅｌｉｖｅｒｙ Ｔａｂｌｅ（ＦＤＴ：ファイル配信テーブル）として配信される。ＦＤＴは、１つ以上のファイルのファイル記述情報を備えており、単一のオブジェクト（ＦＤＴインスタンス）として配信される、あるいは複数のＦＤＴインスタンス上に拡散されてもよい。従って、ファイル記述子インスタンスの連続ストリームとして送信されてもよい。そのような従来技術のＦＬＵＴＥ Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ Ｓｔｒｕｃｔｕｒｅ（ＦＬＵＴＥファイル配信構造）の一例について、図２を参照しながら説明する。

図２は、２つのＦＤＴインスタンス２００および２０１の典型的なコンテンツを示し、その各々はＦＤＴインスタンスアイデンティティ（ＦＤＴ＿ＩｎｓｔａｎｃｅＩＤ）でタグ付けされている。ＦＤＴインスタンスは、１つ以上のファイルエントリを備えることができ、各ファイルエントリ（Ｆｉｌｅ ｅｎｔｒｙ）は、関連するファイルコンテンツ（Ｆｉｌｅ Ｃｏｎｔｅｎｔ）についての情報と、ファイルエントリをそれぞれのファイルコンテンツに結び付ける（リンクする）識別子とを備える。図において、ＦＤＴインスタンスＩＤ ２３でタグ付けされている第１のＦＤＴインスタンス２００は、３つのファイルエントリ２０２−２０４を含み、一方、それに続くＦＤＴ ＩＤ２４でタグ付けされている第２のＦＤＴインスタンス２０１は、単一のファイルエントリ２０５だけを含んでいる。各ファイルエントリ２０２−２０５は、ファイルコンテンツ、すなわち、マルチキャストチャネルを介して複数のＩＴＦに配信されることになるユーザ情報、を搬送するファイルインスタンス（ファイルオブジェクト）２０６−２０９に関連付けられている。各ファイルエントリ２０２−２０５は、１つ以上の属性を含み、それらは関連するファイルコンテンツに関連し、そして関連するファイルコンテンツについての固有の情報を示している。この情報は、各ファイルインスタンスが適宜に処理されることができるように、受信メカニズムに関連してもよい。ＦＬＵＴＥ用に定義されている属性の完全なリストは、ＲＦＣ３９２６「ＦＬＵＴＥ−Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ」に記載されている。図中に示されるファイルエントリは、２つの属性「Ｃｏｎｔｅｎｔ＿Ｔｙｐｅ（コンテンツタイプ）」および「Ｃｏｎｔｅｎｔ＿Ｌｏｃａｔｉｏｎ（コンテンツ位置）」（Ｌｏｃ）を備える。Ｃｏｎｔｅｎｔ＿Ｔｙｐｅ（コンテンツタイプ）は、関連するファイルコンテンツについて定義されるＭＩＭＥ（Ｍｕｌｔｉｐｕｒｐｏｓｅ Ｉｎｔｅｒｎｅｔ Ｍａｉｌ Ｅｘｔｅｎｓｉｏｎｓ）タイプを示す属性である。図に示されるように、Ｃｏｎｔｅｎｔ＿Ｔｙｐｅを使用して、例えば、ＨＴＭＬテキスト（ｔｅｘｔ／ｈｔｍｌ）、ｊｐｅｇ画像（ｐｉｃｔ／ｊｐｅｇ）またはｘｍｌアプリケーション（ａｐｐｌ／ｘｍｌ）の形式でファイルコンテンツの配信を示すために使用することができる。ＦＤＴには必須であるＣｏｎｔｅｎｔ＿Ｌｏｃａｔｉｏｎ（コンテンツ位置）は、ファイルを一意に識別するＵＲＬ記述子であり、例えば、「ｈｔｔｐ：ｔｅｓｔ．ｃｏｍ／ｆｉｌｅ．ｈｔｍｌ」のようなＨＴＴＰアドレスを含んでもよい。加えて、各ファイルエントリは、Ｔａｒｇｅｔ Ｏｂｊｅｃｔ Ｉｄｅｎｔｉｆｉｅｒ（ＴＯＩ：ターゲットオブジェクト識別子）を含んでおり、これはＦＤＴのファイルエントリと実際のファイルコンテンツの間の結び付き（リンク）を示す一意のＡＬＣレベル識別子である。すなわち、ＴＯＩが２に設定されているＦＤＴ２０２は、同じく２に設定されているＴＯＩでタグ付けされているファイルインスタンス２０６で搬送されるファイルコンテンツのためのファイル記述子である。ファイル記述インスタンスと受信機内のファイルインスタンスとを区別することができるようにするために、各ファイル記述インスタンス（ＦＤＴインスタンス）には、０に等しいＴＯＩが与えられ、一方、ファイルエントリおよびそれに結び付けられたファイルインスタンスには、０以外の数である一意のＴＯＩが与えられる。

上述のＦＬＵＴＥ ＦＤＴを拡張することによって、そして、マルチキャストチャネルの送信端で実装されてもよい改良された配信メカニズムと共に属性を用いることによって、マルチキャスト配信のためのより効率的なメカニズムが要求される。

ＭＤＣを聴取する各ＩＴＦでは、ここで提案するフィルタリングメカニズムが、配信されるファイルコンテンツの選択的受信と処理とを提供することになる。

図３ａでは、ここで提案される拡張されたＦＬＵＴＥ／ＦＤＴで使用することができる、複数の属性を示している。属性のリストを拡張する主な目的は、改良された配信メカニズムを送信側エンティティで可能にするパラメータを提供することと、受信ＩＴＦ側で所望のファイルコンテンツをフィルタリングするために使用されることになる選択式メカニズムを提供することである。図３ａに示される属性のリストは、いかなる制限もなく示されており、ここで提案される配信メカニズムおよび選択式メカニズムは、他の属性と共に動作するように構成され、その一部はオペレータ専用であってもよいことが理解されるべきである。配信メカニズムは、Ｍｕｌｔｉ−Ｃａｓｔ Ｃｏｎｔｒｏｌｌｅｒ（ＭＣＣ：マルチキャストコントローラ）と呼ばれるエンティティによって管理されることになるが、それについては図４および図５を参照して以下で詳細に説明する。一方、選択式メカニズムは、ＭＤＣ Ｔｅｒｍｉｎａｌ Ｆｕｎｃｔｉｏｎ（ＭＤＣ ＴＦ：ＭＤＣ端末機能）によって管理されることになる。ＭＤＣ ＴＦについては、図６を参照して詳細に説明する。

「コンテンツ位置（Ｃｏｎｔｅｎｔ−Ｌｏｃａｔｉｏｎ）」および「コンテンツタイプ（Ｃｏｎｔｅｎｔ−Ｔｙｐｅ）」という２つの属性は、ＦＬＵＴＥの既存の属性を表している。「優先度（Ｐｒｉｏｒｉｔｙ）」は、送信段階と受信段階の両方に関連することがある属性である。この属性は、輻輳しているまたは輻輳しそうなＭＤＣ上で配信されようとしているオブジェクト間の優先順位を決定する場合に、スケジュール設定（スケジューリング）に使用されてもよい。ＩＦＴでは、この属性は、ＩＴＦ内で輻輳の問題が発生しようとしている場合にファイルコンテンツの処理方法に優先順位を付けるために使用されてもよい。「基準（Ｃｒｉｔｅｒｉａ）」は、特定の基準に照合する受信オブジェクトが処理される必要があるか否かを表す、ＩＴＦにとって関心対象となり得る属性である。

「ステイル時間（Ｓｔａｌｅ ｔｉｍｅ（延滞時間））」という属性は、ＩＦＴに関連する場合があり、ＭＣＣがあるオブジェクトの送信を遅らせて、よりタイム・クリティカル（時間に厳格）な他の配信を優先させることを可能にする。従って、ステイル時間は、ＭＣＣがＭＤＣを一層効率よく使用することを可能にする。

「有効時間（Ｖａｌｉｄｉｔｙ ｔｉｍｅ）」は、ここで提案される別の属性であり、ＭＣＣとＩＴＦの両方に関連する場合がある。「有効時間」は、オブジェクトのコンテンツがどのくらい長く有効であるかを示し、従って、ＩＦＴに配信されて記憶された後にはどのくらい長くオブジェクトのコンテンツがアクセス可能かを示すものである。

「タイプ（Ｔｙｐｅ）」という属性は、各ＩＴＦがメッセージをどのように処理すべきかを示している。何ら限定されることなく、可能なタイプの定義のリストが図３ｂに示される。

「キャッシュ（Ｃａｃｈｅ）」タイプを有するオブジェクトは、そのオブジェクトが各ＩＴＦのキャッシュに記憶されるべきことを示している。キャッシュは、ＩＦＴを閲覧する場合に要求される、またはＩＦＴのアプリケーションから要求される、コンテンツを記憶して提供するための記憶手段である。例えば、その人気度が理由で、近い将来要求される可能性が高いファイルコンテンツは、要求された場合に早く検索して取得できるように、あらかじめ配信されてキャッシュ内に記憶されてもよい。従って、キャッシュ内にすでに記憶されているコンテンツを閲覧する場合、アプリケーションサーバからのユニキャスト配信は回避される。このファイルコンテンツが、マルチキャストチャネル上で複数の受信機に配信され、そして、それが実際に必要とされる前に各受信機のキャッシュに記憶されるという事実は、帯域幅の節約になる。もう１つの利点は、ユーザがファイルコンテンツにより早くアクセスできることになることである。キャッシュの機能については、図４を参照して以下でさらに説明する。

「表示（Ｄｉｓｐｌａｙ）」というもう１つのタイプは、受信したオブジェクトの各コンテンツがＩＴＦの画面上に表示されるべきであることを示すために使用されてもよい。「アップグレード（Ｕｐｇｒａｄｅ）」タイプは別のタイプであり、これは、各オブジェクトのコンテンツがファームウェアのアップグレードのために使用されるべきであることをＩＴＦに示すために使用されてもよい。「双方向性メッセージ（Ｉｎｔｅｒａｃｔｉｖｉｔｙ ｍｅｓｓａｇｅ）」はさらに別の属性であり、これは、メッセージが双方向セッションで使用されるべきであることを示すために使用されてもよく、一方、「チャネルに接続（Ｊｏｉｎ ｃｈａｎｎｅｌ）」および「チャネルを離脱（Ｌｅａｖｅ ｃｈａｎｎｅｌ）」という２つのタイプは、ＩＴＦが別のＭＤＣに接続すべきである、または現在のＭＤＣを離脱すべきであることをそれぞれＩＴＦに示すものである。

ここで図４を参照して、一実施形態に従う、拡張ＭＤＣ／ＦＬＵＴＥ概念に基づくＩＰＴＶアーキテクチャの概要と新しい基準のメカニズムについて説明する。図は、３つのＩＰＴＶ Ａｐｐｌｉｃａｔｉｏｎ Ｐｌａｔｆｏｒｍ（ＡＳＰ：アプリケーションプラットホーム）３００ａ−ｃを備える通信ネットワーク３０５を示しており、その各々が、ＩＰＴＶサービスに関連するファイルコンテンツを、３つのＩＴＦ３１０ａ−ｃのうち１つ以上に提供するように構成されている。ここで、ＩＴＦ３１０ａ−ｃは、ＩＰＴＶサービスを受信するように構成されている、例えば、ＳＴＢ／ＴＶ、ＰＣまたは携帯電話のうちのいずれであってもよい。明確にするために、図では、ＩＴＦおよびＡＳＰは３つのエンティティに限られているが、更なるＩＴＳおよびＡＳＰを備えるアーキテクチャに容易に拡張することができる。また、通信ネットワーク３０５には、Ｍｕｌｔｉ−Ｃａｓｔ Ｃｏｎｔｒｏｌｌｅｒ（ＭＣＣ：マルチキャストコントローラ）３２０が導入されており、これは、ＭＤＣを聴取しているＩＴＦに対するファイルコンテンツのマルチキャスト配信を制御するように構成されている。

各ＡＳＰ３００ａ−ｃは、ＩＴＦ３１０ａ−ｃのいずれかを使用して、特定のＩＰＴＶサービスを、加入エンドユーザに提供するようにそれぞれが構成されている、１つ以上のアプリケーション（ＡＳＰ ＡＰ１、ＡＳＰ ＡＰ２）を備えることができる。一部のアプリケーション（ＡＳＰ ＡＰ１）は、例えば、閲覧のようなユーザとの対話に応じて、またはＩＴＦのアプリケーションによって開始される自動要求に応じて、サービスを提供するように構成されてもよい。通常は、ファイルに対する要求が各ＡＳＰへ送信され、そこから、要求されたファイルコンテンツがユニキャストを介してＩＴＦへ配信される。また、上述の実施形態に従えば、ファイルのユニキャスト配信をトリガすることに加えて、ファイル配信に対する要求も、１つ以上のＡＳＰからＭＣＣへ送信される。ＭＣＣでは、ファイルも配信されるべきかどうかを判定するために、例えば、経験したファイル要求パターンまたは記憶されたファイル配信パターンの統計値を考慮した上で、受信した要求が評価され、マルチキャストチャネルを聴取しているＩＦＴ内に記憶される。ＩＦＴへ一旦配信されると、何らかの信号（シグナリング）で通信ネットワーク３０５に負荷をかけることなく、要求時にこのファイルコンテンツをＩＦＴによって直ちに検索して取得することができる。

他のアプリケーション（ＡＳＰ ＡＰ２）３０１ｂは、内部からまたは外部から開始される何らかの他のトリガに基づいて、直接のマルチキャストファイル配信に対する要求を実行するように構成されてもよい。ユーザとの対話をまったく必要としないサービスには、例えば、緊急時にＩＴＦのグループへ配信されることになる緊急情報の配信が含まれる。

ここで、本明細書で示されるＩＴＦは、必要な対話機能を備えることも想定されていることが理解されるべきである。この必要な対話機能には、例えば、検索して取得されたコンテンツをエンドユーザに提示するために必要なディスプレイや、ユーザ専用のオプションを挿入するために構成されるだけでなく双方向ＩＰＴＶサービスに関連するユーザとの対話を実行するためにも構成されているユーザインタフェースなどが含まれる。しかしながら、このタイプの機能は、市場でよく知られており、各種の代替物として提供されているので、本明細書の範囲外である。

ＩＦＴの観点からは、ユーザに関心のあるファイルコンテンツは、通常、それぞれのＡＳＰ３００ａ−ｃからユーザとの対話によって要求される。ここで、それぞれのＩＴＦ３１０ａ−ｃのブラウザ３１１で閲覧するエンドユーザは、ＡＳＰにアクセスして、要求されているファイルをＨＴＴＰプロキシ３１２経由でユニキャスト配信を通じて検索して取得することができる。選択的には、ＩＴＦのアプリケーション（ＩＦＴ ＡＰ２）３１３ｂは、ＨＴＴＰプロキシ３１２をトリガして、必要なファイルに対する要求を自動的に行ってもよい。しかしながら、ここで提示される実施形態に従えば、要求されるファイルは、当初、それぞれのＩＴＦのキャッシュ３１６の中を探索される。キャッシュ３１６は、探索に先立ってＭＣＣからＭＤＣを介して検索して取得されるファイルコンテンツを含んでいる。その場合、それぞれのファイルコンテンツは、それが有効であると設定されている限り、キャッシュ３１６の中に維持される。ファイルの有効性は、コンテンツに関連して記憶される、特定の有効性の属性で定義されてもよい。要求されているファイルコンテンツがキャッシュ３１６の中で検出される場合、遅滞なく、かつ、通信ネットワーク３０５上でのファイル配信に対する何らかの要求を開始することなく、それを検索して取得することができる。しかしながら、ファイルがキャッシュ内に存在しない場合には、ユニキャストのファイル配信に対する要求が開始され、かつそれぞれのＡＳＰおよびアプリケーションへ転送されることが必要である。その要求がＡＳＰ３００ａ−ｃの１つへ配信される前に、それぞれがファイル固有の要件を定義する１つ以上の属性が、その要求に付加される。

ＭＤＣ配信メカニズムの改良をもたらすことを目的として、ＭＤＣ３１２の送信側での制御機能が必要となるであろう。このため、Ｍｕｌｔｉ−Ｃａｓｔ Ｃｏｎｔｒｏｌｌｅｒ（ＭＣＣ）３２０と呼ばれる一般的な制御機能が導入される。また、上述のように、ＡＳＰに転送されるユニキャスト要求はそれぞれ、ＭＣＣ３２０へ転送されることになり、その場合、その要求は、他の要求と共に評価され、そして、利用可能な情報に基づいて、ファイルコンテンツもＭＤＣ３１２を介して配信されるべきかどうかの判定が行われる。図８を参照して、以下で、そのようなプロセスの一例について説明する。

ＭＣＣ３２０は、ＭＤＣ３１２に接続してそれを聴取しているすべてのＩＴＦ３１０ａ−ｃに対してＡＳＰ３００ａ−ｃからＭＤＣ３１２上で提供されるファイルコンテンツのマルチキャスト配信に責任を持っている。図ではＭＤＣ３１２が１つしか示されていないが、ＭＣＣは、複数のＭＤＣを介するファイル配信を制御することができる。ＩＦＴは、通常、典型的にはＩｎｔｅｒｎｅｔ Ｇｒｏｕｐ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ（ＩＧＭＰ：インターネットグループ管理プロトコル）を使用することによって、起動時にＭＤＣに接続し、ＩＦＴの電源が切れるまでまたはＭＤＣを変更する指示がなされるまで、そのＭＤＣを聴取し続ける。また、ＭＣＣ３２０は、ＩＴＦ３１０ａ−ｃとＡＳＰ３００ａ−ｃの間の中間ユニットとして動作する１つ以上のＭＤＣプロキシ（不図示）に接続されてもよい。

ＭＤＣ Ｉｎｓｅｒｔ Ｆｕｎｃｔｉｏｎ（ＭＤＣ ＩＦ：ＭＤＣ挿入機能）３２１は、図５を参照して以下で詳細に説明するが、ＡＳＰ３００ａ、ｂ、ｃから検索して取得されるファイルコンテンツのマルチキャストファイル配信を制御するように構成される。ファイルをＭＤＣ３１２を介して配信すべきであるという結論に達すると、実際のファイルコンテンツがそれぞれのＡＳＰから検索して取得される。次いで、ファイルコンテンツ配信がスケジュール設定され、ＩＴＦ３１０ａ−ｃにプッシュされる。各ＭＤＣ３１２に対する効率的な配信管理は、スケジュール設定（スケジューリング）のスキームに依存することになり、また、そのスキームは、コンテンツ固有の基準を考慮に入れるでことになる。ここで提案される拡張ＦＤＴは、フィルタリングのプロセスと共に使用され、スケジュール設定を一層柔軟なものにすることになり、その場合、要求の中で受信される１つ以上の属性と、オプションで、例えば、ＭＣＣデータベース（ＭＣＣ ＤＢ）３２２に記憶されているＴＶ番組の人気度統計値のような追加情報とが、判定処理中に考慮することもできる。また、典型的には、ＭＣＣ ＤＢ３２２は、定期的にＭＤＣ上で繰り返されることになるファイルインスタンスの各種のカルーセル（carousels）を維持する。

ＭＤＣ３１２を介してＩＴＦ３１０ａに一旦配信されると、ファイルコンテンツは、導入されるＭＤＣ Ｔｅｒｍｉｎａｌ Ｆｕｎｃｔｉｏｎ（ＭＤＣ ＴＦ：ＭＤＣ端末機能）３１４によって処理されることになる。ここで、提案されるフィルタリングのプロセスは、ＭＤＣ ＴＦ３１４に位置するロジックによって、またはＩＴＦ ３１０ａ−ｃのアプリケーション（ＩＦＴ ＡＰ１）３１３ａによって、制御されてもよい。フィルタリングのプロセスによって、エンドユーザは、自身が関心のある受信したファイルコンテンツと、無関係のコンテンツとを区別することができる。フィルタリングの後、識別されたファイルコンテンツは、ファイルコンテンツに関連する１つ以上の属性に従って処理される。ファイルコンテンツは、例えば、ＭＤＣ ＴＦ３１４からＣａｃｈｅ Ｉｎｓｅｒｔ Ｆｕｎｃｔｉｏｎ（Ｃａｃｈｅ ＩＦ：キャッシュ挿入機能）３１５によって検索して取得され、各属性によって指示される場合にはキャッシュ３１６へ挿入されてもよい。各ファイルコンテンツは、通常、それが有効である限りキャッシュの中に残存する。有効時間は有効性属性によって設定されてもよいが、それが切れたら、ファイルコンテンツは、キャッシュ３１６から廃棄される。しかしながら、対応するファイルが既にキャッシュの中に存在する場合には、このファイルは廃棄されて、新たな更新されたファイルと置換される。

上述の実施形態に従うマルチキャスト配信の評価およびスケジュール設定に使用されることになるＭＤＣ ＩＦ３２１を備える、典型的なＭＣＣ３２０について、図５を参照しながら、以下で詳細に説明する。

ＭＣＣ３２０は、ＡＳＰ３００ａ−ｃのアプリケーションに対して適用される、１つ以上のアプリケーション・プログラム・インタフェース（ＡＰＩ）３３０を備えており、これは、最初にＡＳＰ３００ａ、ｂ、ｃに向けられる要求の受信を可能にするだけでなく、各ファイルコンテンツのマルチキャストファイル配信の決定がＭＣＣ３２０によって一旦行われると、ファイルコンテンツ自体の受信をも可能にする。ＡＰＩ３３０によって受信されるファイル配信に対する要求は、ＭＤＣ Ｆｏｒｍａｔｔｉｎｇ ａｎｄ Ｓｃｈｅｄｕｌｉｎｇ Ｆｕｎｃｔｉｏｎ（ＭＤＣ ＦＳＦ：ＭＤＣフォーマッティングおよびスケジューリング機能）３３１へ転送され、そこで、要求は、他のキューに入っている要求と共に、キュー３３３に入れられる。そのキューの処理に続いて、ＭＤＣ ＦＳＦ３３１が、ＭＣＣ ＤＢ３２２の中に記憶されてそこから検索して取得される統計値を使用して、ファイルがＭＤＣを介して配信されるべきかどうか判定してもよい。これが判定されると、典型的には、クライアント専用プルを実行することによって、ファイルコンテンツがそれぞれのＡＳＰから検索して取得され、そして、その要求で検索して取得される１つ以上の属性に基づいてファイル配信がスケジュール設定される。

スケジュール設定は、単独でもしくは組み合わせて起動されることになる１つ以上のフィルタリング機能に基づいていてもよい。第１のレベルは、ＭＤＣが所定の帯域幅制限に達している場合に起動されてもよいが、そのレベルでは、ＭＤＣ ＦＳＦ３３１は、要求されたファイル配信を実行する順序に優先順位を付けるために、例えば、優先度のような属性を検討してもよい。第２のレベルは、ＭＤＣ上の輻輳のリスクが低い場合に検討されるが、このレベルでは、他の属性、例えば、ステイル時間および有効時間の少なくとも一方が検討されて、他の要求の対応する属性と比較されてもよい。

属性に加えて、スケジュール設定の際にＭＣＣ ＤＢ３２２から検索して取得される情報を使用することもでき、例えば、最も要求頻度の高いファイルコンテンツが最高の優先度を与えられてもよい。

スケジュール設定に続いて、ＩＦＴの受信機のための指示を含む、ファイルコンテンツおよびファイル記述情報が、ＦＬＵＴＥプロトコルに従ってＭＤＣ ＦＳＦ３２１の中でフォーマットされる。

図２を参照して上述したように、１つ以上のファイル記述インスタンスは、ＦＤＴインスタンスとして組み立てられ、その各々が１つ以上のファイルエントリを搬送する。ＦＤＴインスタンスは、ＭＤＣ Ｔｒａｎｓｍｉｔｔｅｒ（ＭＤＣトランスミッタ）３３４を介して、専用のＭＤＣ上でＩＴＦ３１０ａ−ｃにプッシュされる。ＦＤＴインスタンスがＩＦＴへ一旦配信されると、ファイルコンテンツを搬送する１つ以上のＡＬＣパケットが、関連する識別子（ＴＯＩ）と共に組み立てられる。次いで、ＡＬＣパケットも、ＭＤＣトランスミッタ３３４を介してＩＴＳ３１０ａ−ｃにプッシュされる。

受信側の各ＩＦＴでは、ファイルコンテンツに関連する属性と選択基準とを使用して、各受信機について設定されている特定のプロファイルを定義して、関心のあるファイルコンテンツを識別し、無関係のコンテンツと区別することができる。ここで、上述の実施形態に従って、そのような識別とフィルタリングとを制御するように構成される、ＩＴＦ３１０の例示するＭＤＣ ＴＦ３１４について、図６を参照して詳細に説明する。

ＭＤＣを介してＭＤＣ ＴＦ３１４に到達するファイルエントリは、ＭＤＣ受信機３４０によって受信され、ＩＴＦロジック３４１によって処理される。ＩＴＦロジック３４１は、識別メカニズムを備えており、これは、ファイルエントリに続いて配信されることになるファイルコンテンツがＩＴＦにとって関心があるかどうかを判定するために使用される。ファイルインスタンスの属性を、ＩＦＴロジック３４１またはＩＦＴ ＡＰ１ ３１３から検索して取得される所定の選択基準３４３と比較した後、ＩＴＦロジックは、選択リスト３４２を作成する。この選択リスト３４２は、ＩＴＦにとって関心があると判定されたファイルインスタンスにリンクしている１つ以上の識別子（ＴＯＩ）と、関連する属性とを示すものである。選択リスト３４２の中に存在する識別子を備えるすべてのファイルインスタンスが、ＩＦＴロジック３４１によって検討され、それぞれの１つ以上の属性に従って処理される。しかしながら、選択リスト３４２の中に存在しない識別子を有するファイルインスタンスは、ＩＦＴロジック３４１によって廃棄される。別の実施形態では、無関係なファイルコンテンツは、ＭＤＣ受信機３４０の中で既に廃棄されてもよい。

図７は、選択基準の一部の例を示しており、それらはＩＴＦの受信要件を指定するために、すなわち、受信をパーソナライズするために使用されてもよい。

「地域（Ｒｅｇｉｏｎ）」という選択基準は、それぞれのＩＦＴが位置する地理的地域を定義する。選択基準「地域」を使用する場合、例えば、「ｓｅ．ｓｔｏｃｋｈｏｌｍ．ｎｏｒｒｍａｌｍ」で定義されるゾーン内に位置するＩＴＦは、「ｓｅ」、「ｓｅ．ｓｔｏｃｋｈｏｌｍ」、「ｓｅ．ｓｔｏｃｋｈｏｌｍ．ｎｏｒｒｍａｌｍ」という地域でタグ付けされるすべての着信ファイルインスタンスを受け入れることになる。

「ブランド（Ｂｒａｎｄ）」という選択基準は、ＩＴＦの製造業者を示している。この基準は、その特定のブランド向けのコンテンツだけが受け入れられるべきであることを示すことができる。

「バージョン（Ｖｅｒｓｉｏｎ）」は、もう１つの選択基準であり、どのファームウェアバージョンが使用されていることを示すために使用され、このバージョンと共に使用されるように構成されていない何らかのコンテンツをＩＴＦがフィルタで除外するのを可能にすることができる。

「関心（Ｉｎｔｅｒｅｓｔ）」は、ＩＦＴをパーソナライズするために使用されることになり、従って、ここで提案されるＭＤＣメカニズムを介して、どのカテゴリのコンテンツを受信するかを選択的に選べるようになる、多様な選択オプションをエンドユーザに提供することができる。

「格付（Ｒａｔｉｎｇ）」は、現在のＩＴＦユーザの最低格付け（レイティング）レベルを示すために使用することができる。

「年齢（Ａｇｅ）」は、現在のＩＴＦユーザの最小年齢を示すことができ、「チャネル（Ｃｈａｎｎｅｌ）」は、現在ＩＴＦ上で視聴されているＴＶチャネルを示す選択基準である。

ここで、ここで提案される選択基準のリストは、例として主な用途を説明しているにすぎないことが理解されるべきである。従って、図７のリストは、エンドユーザだけでなく製造業者およびサービスプロバイダの少なくとも一方の観点から、関心のある、かつ優先させる側面を表すために適している追加の選択基準で拡張することができる。

また、ＩＴＦロジック３４１は、タイプ属性に従って関心のあるファイルインスタンスを処理するように構成されている。キャッシュでマークされているファイルインスタンスは、例えば、上述のように、キャッシュ３１５に転送されてそこに記憶されることになる。しかしながら、キャッシュが一杯であるまたは所定の閾値に達している場合、どのファイルインスタンスを優先させるかを判定するために、優先度属性を使用しても良い。

図８は、上述の実施形態に従うファイル配信メカニズムを示す信号図である。図８では、上述の実施形態に従って、ＡＳＰ３００へ配信されるファイルに対する要求がどのようにしてＭＣＣ３２０へ転送されるか、および、要求されるファイルコンテンツをＭＤＣを介してＩＦＴのグループへも送信するという判定が、どのようにしてＭＣＣで行われるかを示している。ここで、図８のシグナリング図は、１つの要求の到着だけを示しているが、マルチキャストファイル配信に対する決定は、同一のファイルに対する複数の要求がＭＣＣ３２０の決定ロジックに何らかの種類のパターンを示す場合に限って行われることになることが理解されるべきである。

図８の第１のステップ８：１（ＲｅｑＮｅｗＦｉｌｅ［ａｔｔｒｉｂｕｔｅｓ］）において、ファイル配信に対する複数の要求のうちの１つが、最初はＩＦＴからＡＳＰ３００へ転送され、更に、ＡＳＰ３００からＭＣＣ３２０へ転送される。ＩＴＦでは、当初、各要求には、それぞれの要求されたファイルに対する一定の要件を示す属性が提供されている。次のステップ８：２では、要求は、同一のＡＳＰまたは別のＡＳＰから受信した他の要求と共に、キュー（ＥｎｑｕｅｕｅＦｉｌｅ）に入れられる。次のステップ８：３で、要求をキューに入れることが、ＡＳＰ３００（ＣｏｎｆｉｒｍＳｅｎｄＮｅｗＦｉｌｅ）に対して確認される。別のステップ８：４では、決定ロジックが、ファイルコンテンツがＭＣＣ３２０によってマルチキャスト配信を介して配信されるべきかどうかを判定する。あるファイルに対してのマルチキャスト配信が決定される場合、そのファイルコンテンツはステップ８：５およびステップ８：６（ＨＴＴＰ：ＵＲＬ）においてＡＳＰ３００からプルされる（ＨＴＴＰ：ＧｅｔＵＲＬ）。次に、マルチキャストファイル配信のスケジュール設定がなされ、それによって、例えば、ＭＤＣ上の輻輳を回避するために、および配信に効率よく優先順位をつけるためにの、少なくとも一方のために、異なる基準が使用されてもよい。図８：７に示されるスケジュール設定は、典型的には、各要求と共に配信される属性に依存するが、配信されることになるファイルコンテンツに対する追加の統計値にも依存してよい。検索して取得されたファイルコンテンツは、この時、ＭＤＣを聴取しているすべてのＩＴＦに対して配信するためにＭＣＣ３２０で利用可能である。ステップ８：８では、送信されることになるファイルコンテンツに関連する１つ以上のＦＤＴインスタンスが、組み立てられてそれぞれのマルチキャストチャネルを聴取しているＩＴＦにプッシュされる（ＦＬＵＴＥ：ＳｅｎｄＦＤＴ［ａｔｔｒｉｂｕｔｅｓ］）。ＩＴＦ３１０で一旦受信されると、ＦＤＴインスタンスの１つ以上の属性が使用されて、１つ以上の属性をＩＦＴ３１０の選択基準と照合することによって、ＩＦＴ３１０に関して考慮されるファイルコンテンツがフィルタリングされる（ＰｒｏｃｅｓｓＳｅｌｅｃｔｉｏｎＣｒｉｔｅｒｉａ）。これは別のステップ８：９で実行される。照合の結果として、ＩＦＴ３１０に関連すると考えられているファイルインスタンスを、受信機に無関係であると分ったファイルインスタンスと区別することができる。次のステップ８：１０では、以前にプッシュされたＤＦＴインスタンスに関連するファイルインスタンスが、専用ＭＤＣを介してＩＴＦへプッシュされる（ＦＬＵＴＥ：ＳｅｎｄＦｉｌｅ［ＴＯＩ，ｆｉｌｅ ｃｏｎｔｅｎｔ］）。この時、フィルタリング手順の結果に依存して、関連するファイルコンテンツが、それに応じて処理されることができる。図では、このステップは、ステップ８：１１で示されている（ＨａｎｄｌｅＦｉｌｅ）。

本発明は、具体的に例示する実施形態を参照して説明しているが、この記載は一般に本発明の概念を示すことだけを意図しており、本発明の範囲を限定すると解釈されるべきではなく、本発明の範囲は、添付の請求項によって定義される。

従来技術に従って、クライアント専用ストリーミングに基づいて、ネットワークからＩＰＴＶ受信機へのファイル配信を提供する一方法の略図である。 ファイル配信用にクライアント専用プルが使用される場合に、従来技術に従ってファイル配信を提供する第２の方法を示すもう１つの略図である。 従来技術に従って、クライアント専用プッシュを使用する第３のファイル配信手段を示す更にもう１つの略図である。 従来技術に従う、一般的な専用プッシュに基づくファイル配信の第４の代替の方法を提示するもう１つの略図である。 従来技術に従う、例示のＦＬＵＴＥ Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ Ｓｔｒｕｃｔｕｒｅの図である。 一実施形態に従う、複数の例示する属性の機能を説明し、かつ一方法において使用される場合に、その属性がどのノードに関連するかを説明する表を示す図である。 一実施形態に従う、一方法において使用される場合に、一部の例示するタイプの属性がどのように定義される場合があるかを説明するもう１つの表を示す図である。 一実施形態に従う、マルチキャスト配信に関わるネットワークおよびＩＰＴＶ Ｔｅｒｍｉｎａｔｉｎｇ Ｆｕｎｃｔｉｏｎ（ＩＴＦ）のアーキテクチャを示す図である。 一実施形態に従う、Ｍｕｌｔｉ−Ｃａｓｔ Ｃｏｎｔｒｏｌｌｅｒ（ＭＣＣ）がマルチキャストチャネル配信を制御するＭＣＣのアーキテクチャを示す図である。 一実施形態に従う、ＩＦＴで受信されるファイルオブジェクトを受信して処理する、ＩＴＦのＭｕｌｔｉ−Ｃａｓｔ Ｄａｔａ Ｃｈａｎｎｅｌ Ｔｅｒｍｉｎａｌ Ｆｕｎｃｔｉｏｎ（ＭＤＣ ＴＦ）のアーキテクチャを示す図である。 上述の一実施形態に従う、一部の例示する選択基準を示し、かつ一方法において使用される場合に、これらがどのように定義され得るかを示す、もう１つの表を示す図である。 一実施形態に従う、マルチキャストファイル配信の手順を示す信号図である。

Claims (29)

1. 通信ネットワーク（３０５）において、マルチキャストチャネル（３１２）を聴取している複数の受信機（３１０ａ、ｂ、ｃ）に対してファイルを配信するための方法であって、
   少なくとも１つのアプリケーション・サーバ・プラットフォーム（ＡＳＰ；３００ａ、ｂ、ｃ）からのファイル配信に対する要求群として、それぞれが該要求およびそれに関連するファイルコンテンツをどのように処理するかについての条件を指定する少なくとも１つの属性を含んでいる要求群を、マルチキャストコントローラ（ＭＣＣ；３２０）で受信して（８：１）、キューに入れる（８：２）ステップと、
   マルチキャストチャネル上でファイルコンテンツが前記マルチキャストコントローラから前記複数の受信機へ配信されることが判定されている（８：４）時点で、各アプリケーション・サーバ・プラットフォームからファイルコンテンツを取得する（８：５、８：６）ステップと、
   各ファイル配信が、前記少なくとも１つの属性に基づいてスケジュール設定する（８：７）ステップと、
   前記ファイルコンテンツを少なくとも１つのファイルインスタンスにフォーマットして配信する（８：１０）前に、ファイル記述情報を、該ファイルコンテンツに関連付けられている少なくとも１つのファイルエントリにフォーマットして配信する（８：８）ステップと
   を備えることを特徴とする方法。
2. 要求を受信してキューに入れる前に、要求されているファイルコンテンツは、各アプリケーション・サーバ・プラットフォームからユニキャストを介して要求元の受信機に配信されている
   ことを特徴とする請求項１に記載の方法。
3. 通信ネットワーク（３０５）において、マルチキャストチャネル（３１２）を聴取している受信機（３１０ａ、ｂ、ｃ）でファイルコンテンツを選択的に受信するための方法であって、
   少なくとも１つのファイルエントリとして、それぞれが、少なくとも１つの属性と、それぞれのファイルエントリを少なくとも１つのファイルインスタンスに結び付ける識別子とを備えるファイルエントリをマルチキャストチャネル上で受信する（８：８）ステップと、
   各ファイルエントリの少なくとも１の属性と、前記受信機に対する受信要件を指定する少なくとも１つの選択基準とを照合することによって、前記受信機に関心のあるファイルインスタンスを識別する（８：９）ステップと、
   前記マルチキャストチャネルにおいて、少なくとも１つのファイルインスタンスにおけるファイルコンテンツを受信する（８：１０）ステップと、
   前記ファイルインスタンスに関連する前記少なくとも１つの属性に従って、前記受信機に関心のあるファイルインスタンスを処理する（８：１１）ステップとを備え、
   前記少なくとも１つのファイルインスタンスは、ファイルコンテンツおよび前記識別子と同一の識別子を備える
   ことを特徴とする方法。
4. 前記選択基準は、
   前記受信機が位置する地理的地域を示す地域、
   前記受信機の製造業者を示すブランド、
   前記受信機のファームウェアを示すバージョン、
   前記受信機の現在のユーザの関心分野を示す関心、
   前記受信機の現在のユーザの最低格付レベルを示す格付、
   前記受信機の現在のユーザの最小年齢を示す年齢、
   前記受信機上で現在視聴されているＴＶチャネルを示すチャネル
   のうち、少なくとも１つを含む
   ことを特徴とする請求項３に記載の方法。
5. マルチキャスト配信を介して前記受信機に配信されている、キャッシュ（３１６）に記憶されている要求されたファイルコンテンツに対する問い合わせを前記キャッシュに行うステップと、
   前記ファイルコンテンツが前記キャッシュに記憶されている場合は、前記ファイルコンテンツを前記キャッシュから取得するステップと、
   前記ファイルコンテンツが前記キャッシュに記憶されていない場合は、ユニキャスト配信を介して、アプリケーション・サーバ・プラットフォーム（ＡＳＰ；３００ａ、ｂ、ｃ）から前記ファイルコンテンツを取得するステップと
   を備えることを特徴とする請求項３または４に記載の方法。
6. 前記要求されたファイルコンテンツが、前記キャッシュに記憶されていない場合、該要求されたファイルコンテンツも前記マルチキャストチャネル上で配信されるべきかどうかを判定するためのユニキャスト配信を開始することに加えて、前記ユニキャスト配信に対する要求が前記アプリケーション・サーバ・プラットフォームからマルチキャストコントローラ（ＭＣＣ；３２０）へと転送される
   ことを特徴とする請求項５に記載の方法。
7. 前記判定においては、
   経験されたファイル要求パターンと、
   記憶されたファイル配信パターンの統計値と
   の一方あるいは両方の基準が考慮される
   ことを特徴とする請求項１、２及び６のいずれか１項に記載の方法。
8. 各ファイルエントリは、それぞれの要求から取得される前記少なくとも１つの属性と、前記ファイルエントリをそれぞれ少なくとも１つのファイルインスタンスに結び付ける一意の識別子とを備えており、
   前記ファイルエントリに関連付けられているファイルインスタンスは、ファイルコンテンツと、前記識別子と同一の識別子とを備えている
   ことを特徴とする請求項１乃至７のいずれか１項に記載の方法。
9. 前記識別するステップは、識別の結果として、関心のあるファイルインスタンスの前記識別子と、それに関連する属性とを備える選択リストの更新を行ない、
   前記選択リストは、ファイルインスタンスをフィルタリングする場合と、受信した関心のあるファイルインスタンスを処理する場合とで使用される
   ことを特徴とする請求項３乃至８のいずれか１項に記載の方法。
10. 前記属性は、
    一意のＵＲＬ識別を指定するコンテンツ位置、
    使用される情報フォーマットを指定するコンテンツタイプ、
    ファイルインスタンス間の優先順位を指定する優先度
    ファイルインスタンスを処理する必要があることを指定する基準、
    指定の時間であって、その時間より前に、ファイルインスタンスがマルチキャスト・データ・チャネル上で送信されなければならない時間を指定するステイル時間、
    ファイルインスタンスがいつ無効になるかを指定する有効時間、
    ファイルインスタンスがどのように処理されるべきかを指定するタイプ
    のうち、少なくとも１つを含む
    ことを特徴とする請求項１乃至９のいずれか１項に記載の方法。
11. 前記タイプは、
    ファイルインスタンスがＩＴＦのキャッシュに記憶されるべきことを示すキャッシュ、
    ファイルインスタンスのコンテンツがＩＴＦの画面上に表示されるべきことを示す表示
    ファイルインスタンスのコンテンツがファームウェアのアップグレードのために使用されるべきことを示すアップグレード、
    ファイルインスタンスが双方向セッションで使用されるべきことを示す双方向性メッセージ、
    受信機が別のマルチキャスト・データ・チャネルに接続すべきであることを示す、チャネルの接続、
    受信機が現在のマルチキャスト・データ・チャネルから離脱するべきであることを示す、チャネルの離脱
    のうち、少なくとも１つを含む
    ことを特徴とする請求項１０に記載の方法。
12. 前記関心のあるファイルインスタンスのコンテンツは、そのコンテンツが前記受信機のキャッシュに入れられるべきであることを示す属性に関連付けられていて、
    前記属性は、前記コンテンツが、別に関連付けられている属性で指定される期間の間、前記キャッシュに入れられていることを示す
    ことを特徴とする請求項３乃至１１のいずれか１項に記載の方法。
13. 前記マルチキャストチャネルは、マルチキャスト・データ・チャネル（ＭＤＣ）である
    ことを特徴とする請求項１乃至１２のいずれか１項に記載の方法。
14. 前記受信機は、ＩＰＴＶ終端機能（ＩＴＦ）である
    ことを特徴とする請求項１乃至１３のいずれか１項に記載の方法。
15. 各受信機は、１つ以上の所定の選択基準のリストを備え、各選択基準は、受信機用のファイルコンテンツの受信のルールを指定する
    ことを特徴とする請求項１乃至１４のいずれか１項に記載の方法。
16. マルチキャストチャネル（３１２）上で配信されるファイルコンテンツを選択的に受信するための受信機（３１０ａ、ｂ、ｃ）であって、
    前記マルチキャストチャネルに接続する手段と、
    少なくとも１つのファイルインスタンスで関連するファイルコンテンツを受信する前に、少なくとも１つのファイルエントリを前記マルチキャストチャネル上で受信する手段（３４０）と
    受信したファイルエントリをフィルタリングすることによって、前記受信機に関連すると考えられるファイルインスタンスを識別する手段（３４１）と
    を備えることを特徴とする受信機。
17. 前記識別する手段は、更に、関連するファイルコンテンツを搬送する各ファイルインスタンスを、関連付けられたファイルエントリから取得される少なくとも１つの属性に基づいて処理するように構成されている
    ことを特徴とする請求項１６に記載の受信機。
18. 要求されたファイルコンテンツについてキャッシュ（３１６）に問い合わせする手段（３１１）を更に備え、
    前記キャッシュに記憶されているファイルコンテンツは、マルチキャスト配信を介して当該受信機へ配信されたものであり、
    前記問い合わせする手段は、前記ファイルコンテンツがキャッシュに記憶されている場合には、該キャッシュから前記ファイルコンテンツを取得し、前記ファイルコンテンツがキャッシュに記憶されていない場合には、ユニキャスト配信を介して、アプリケーションサーバプラットホーム（ＡＳＰ；３００ａ、ｂ、ｃ）から該ファイルコンテンツを取得するように構成されている
    ことを特徴とする請求項１７に記載の受信機。
19. 前記識別する手段は、受信された各ファイルエントリの少なくとも１つの属性と識別子とを識別し、前記識別子と同一の識別子を介して前記ファイルエントリに結び付けられるファイルコンテンツを備える少なくとも１つのファイルインスタンスの各々を識別するように構成されている
    ことを特徴とする請求項１６乃至１８のいずれか１項に記載の受信機。
20. 前記識別する手段は、各ファイルエントリの少なくとも１つの属性と、当該受信機に対する受信要件を指定する少なくとも１つの選択基準（３４３）とを照合することによって、受信したファイルエントリをフィルタリングするように構成されている
    ことを特徴とする請求項１６乃至１９のいずれか１項に記載の受信機。
21. 前記識別する手段は、更に、関心のあるファイルインスタンスの識別子および関連する属性を備える選択リスト（３４２）を更新するように構成されている
    ことを特徴とする請求項１６乃至２０のいずれか１項に記載の受信機。
22. 前記受信する手段は、関心のあるファイルインスタンスを受け入れて、残りのファイルインスタンスを廃棄するために、前記選択リストを使用するように構成されていて、
    前記識別する手段は、関連する少なくとも１つの属性に従って、関心のあるファイルインスタンスを処理するために、前記選択リストを使用するように構成されている
    ことを特徴とする請求項２１に記載の受信機。
23. 前記受信機は、更に、
    関連するファイルコンテンツであって、それを示す属性と共に関連付けられている関連するファイルコンテンツをキャッシュに挿入する、あるいは既存のファイルコンテンツを前記ファイルコンテンツの新しいバージョンと置換する手段（３１５）を備える
    ことを特徴とする請求項１６乃至２２のいずれか１項に記載の受信機。
24. 前記受信機は、ＩＰＴＶ終端機能（ＩＴＦ）である
    ことを特徴とする請求項１６乃至２３のいずれか１項に記載の受信機。
25. 前記ＩＰＴＶ終端機能（ＩＴＦ）は、セット・トップ・ボックス／ＴＶ、携帯電話、パーソナルコンピュータ（ＰＣ）のうちのいずれかである
    ことを特徴とする請求項１６乃至２４のいずれか１項に吉舎の受信機。
26. マルチキャストコントローラ（ＭＣＣ；３２０）であって、当該マルチキャストコントローラによって管理されるマルチキャストチャネル（３１２）を聴取する複数の受信機（３１０ａ、ｂ、ｃ）に対するマルチキャスト配信を管理するマルチキャストコントローラであって、
    少なくとも１つのサービスププロバイダプラットホーム（ＳＰＰ；３００ａ、ｂ、ｃ）からファイル配信に対する要求群として、それぞれが該要求およびそれに関連するファイルコンテンツをどのように処理するかについての条件を指定する少なくとも１つの属性を含んでいる要求群を、受信し（８：１）、それらをキューに入れる（８：２）手段と、
    ファイルコンテンツがマルチキャストチャネル上で当該マルチキャストコントローラから前記複数の受信機へ配信されるべきか判定する（８：４）手段と、
    前記マルチキャストチャネル上で配信されるべきファイルコンテンツを取得（８：５、８：６）する手段と、
    関連する要求の少なくとも１つの属性に基づいて、各ファイル配信をスケジュール設定する手段（３３１）と、
    前記ファイルコンテンツを少なくとも１つのファイルインスタンスにフォーマットして配信する（８：１０）前に、ファイル記述情報を前記ファイルコンテンツに関連する少なくとも１つのファイルエントリにフォーマットして配信する（８：８）手段（３３１、３３４）と
    を備えることを特徴とするマルチキャストコントローラ。
27. 前記フォーマットして配信する手段は、少なくとも１つの属性と、ファイルエントリをファイルインスタンスが搬送する関連するファイルコンテンツに結び付ける一意の識別子とを備えるように各ファイルエントリをフォーマットして、関連するファイルコンテンツと前記識別子と同一の識別子とを備えるように前記ファイルインスタンスをフォーマットするように構成されている
    ことを特徴とする請求項２６に記載のマルチキャストコントローラ。
28. 前記判定する手段は、
    経験されたファイル要求パターンと、
    記憶されたファイル配信パターンの統計値と
    の一方あるいは両方の基準が考慮される
    ことを特徴とする請求項２６または２７に記載のマルチキャストコントローラ。
29. 前記マルチキャストチャネルは、マルチキャスト・データ・チャネル（ＭＤＣ）である
    ことを特徴とする請求項２６乃至２８のいずれか１項に記載のマルチキャストコントローラ。

Images