JP2007524294A - データ送信のためのネットワークアーキテクチャ - Google Patents

Abstract

【課題】低減帯域幅で作動する、クライアント側でマルチキャスト属性を伴ったコンテンツ配布ネットワークを提供する。
【解決手段】マルチメディアコンテンツのような要求されたコンテンツは、既存のユニキャスト通信リンク上での送信に適切なフォーマットで与えられ、ローカル配布のためのマルチキャストフォーマットに変換される。これにより、アプリケーションプロバイダは、コンテンツの単一ユニキャストストリームを、ローカルエリアネットワーク（ＬＡＮ）におけるクライアント側メディアサーバに送信することができ、マルチキャスト送信フォーマットを使用してＬＡＮ内において興味を示す複数のユーザに配布できる。ＬＡＮ内で専用のコンテンツストリームを使用して個々のユーザに供給するよりもむしろ、ＬＡＮに対して単一ユニキャスト送信を与えることにより、帯域幅要求の大幅な低減をもたらす。
【選択図】図１

Description

本発明は、データ送信ネットワークの改善に関し、特に、複数のネットワークユーザに情報を送信するために要求される総帯域幅を低減するネットワーク配置に関する。

多くの異なるタイプの情報が、コンピュータネットワーク上のあるポイントから別のポイントへ送信される。かかる情報は、テキスト、オーディオ、及び／又は、視覚情報（多くの場合、マルチメディアコンテンツと呼ばれる）といった、電子的情報の多様なフォーム又は組み合わせを含み、これらは、しばしば「コンテンツ」と呼ばれる。ネットワークを通るコンテンツ送信の一つの形態は、「ストリーミング」として知られる技術を介するものである。このストリーミング技術を使用して、遠隔コンピュータ端末側にいる者は、インターネット又は他のネットワーク越しに、コンテンツ要求側に後続して「ストリーム化される」コンテンツを要求することができる。例えば、ウィンドウズ・メディア・プレーヤー^TM又はリアルワン・プレーヤー^TMといった広く利用されているいくつかのメディアプレーヤーの１つを使って、ユーザは、ストリーム化されたコンテンツを自分のコンピュータ端末上で、迅速かつ容易に、鑑賞することができる。

ユーザが情報ソースから直接コンテンツストリームを要求すると、その要求に対する反応は、多くの場合、サーバ又はその要求側に直接コンテンツストリームを送信する他のリモートコンピュータによって処理される。一つのポイントから他のポイントへ、多かれ少なかれ直接的な形式で情報ストリームを送信するこの方法は、「ユニキャスト」送信と呼ばれ、ここでは、一つの専用データストリームが典型的には要求に基づいて送信される。サーバが要求に応答する他の方法は、ストリーム化されているその情報にユーザダウンストリームが関与するかどうかに関係なく、コミュニケーションネットワークの至る所に情報ストリームを送信することによるものである。ネットワーク上に情報を送信するこの方法は、しばしば「ブロードキャスト」送信と呼ばれる。

ユニキャスト及びブロードキャスト送信に対する代替的方法は、「マルチキャスティング」と呼ばれるものである。この方法を使用して、情報の単一ストリームはコンテンツサーバから送信され、すぐ後に、付加的な（追加の）同一のコンテンツストリームに「分割」されて、ユーザに与えられる。

マルチキャスティング、ユニキャスト、そして、ブロードキャスト送信は、特にネットワークサービスプロバイダに関連する帯域幅の問題点を含んでいる。

一般的に言えば、本発明は、マルチメディアコンテンツなどの要求されたコンテンツを既存のユニキャスト通信リンク上の送信に適したフォーマットで提供し、次いで、そのコンテンツをローカル配布のためのマルチキャストに変換するものである。これにより、アプリケーションプロバイダは、コンテンツの単一ユニキャストストリームを、例えば、ローカルエリアネットワーク（ＬＡＮ）上のクライアント側サーバに送信することができ、さらに、マルチキャスト送信フォーマットを使って、これをそのＬＡＮ内において興味をもった複数のユーザに配布することができる。専用のコンテンツストリームを使ってＬＡＮ内の個々のユーザに供給するよりは、ＬＡＮに対して単一ユニキャスト送信を提供することによって、帯域幅要求を大きく減少させることができる。

本発明の実施形態は、ネットワークサーバ又は他の遠隔コンピュータとの間の任務上重要な通信のためにアップストリーム末端回路における総帯域幅を最低限維持しながら、コンテンツ送信するために要求される帯域幅を減少させるネットワーク及び方法を提供するものである。この結果は、ポイント・ツー・ポイント送信経路における特定のマルチキャスト用ハードウェアに依存することなく達成されるものである。

開示したシステム内に配置された誤り検出ソフトウェアは、ネットワーク通信経路、その状態、サービスの一定の最低限品質を確保するために局所的にコンテンツを配布するクライアント側サーバの活動レベルをモニターする。もし、ネットワーク接続又はクライアント側サーバが過負荷であるか、或いは、正常に作動しない場合、この検出ソフトウェアがこの問題を認識し、例えば、クライアント側サーバにおける作業負荷を再分配するか、又は、代替的な、利用可能な、又は正常に機能する送信経路を通るように、送信されるコンテンツのルート変更を行なう、といった適切な修正行動をとる。

本発明の一実施形態による方法は、少なくとも１つの遠隔電子的コンテンツソースからの電子的コンテンツをユーザに提供する。この方法は、少なくとも１つのコンテンツソースから、例えば、ストリーミングメディアといったコンテンツのユニキャスト送信を提供し、複数のユーザに対してサービスする場所においてクライアント側サーバでこのコンテンツを受信し、このコンテンツがこの場所でサービスを受けるこれら複数のユーザの一つ以上に与えられるように、このクライアント側サーバにおける受信コンテンツを処理し、このコンテンツに対する要求を提示した複数のユーザの各々に対してこの受信及び処理されたコンテンツを配布することからなる。

本発明の実施形態において、この受信及び処理されたコンテンツは、このマルチキャストグループに対して予約することによってコンテンツに対する要求を提示した複数のユーザの個々を含む、マルチキャストグループに配布される。

クライアント側サーバは、好ましくは、複数のユーザに対するコンテンツ配布のためにモニターされる。このクライアント側サーバが複数のユーザの何れに対してもコンテンツを配布していない場合、少なくとも１つのコンテンツソースからこのクライアント側サーバへのコンテンツ送信は中止される。

本発明の実施形態においては、上記の場所でクライアント側サーバによるサービスを受けている複数ユーザの中の１つのユーザが、少なくとも１つのコンテンツソースによって現在送信されていないコンテンツをクライアント側サーバに対して要求することに応答して、別の付加的なコンテンツが、少なくとも１つのコンテンツソースからクライアント側サーバに送信される。この付加的なコンテンツは、他のユニキャスト送信で送信されることが好ましい。他のユーザが、少なくとも１つのコンテンツソースからの同一の付加的なユニキャスト送信を使ってこの付加的なコンテンツにアクセスできるように、この付加的なユニキャストは、別の付加的なマルチキャストグループに入れることができる。付加的なユニキャストは、このクライアント側サーバへの送信のために、マルチキャストフォーマットコンテンツをユニキャストフォーマットコンテンツに変換することにより与えられる。

ユーザは、このコンテンツの受信に加えて、１又はそれ以上のアプリケーションを実行している場合がある。本発明は、送信されたコンテンツをモニターし、ユーザにより受信されたコンテンツ以外に、複数ユーザの各々によって実行されている少なくとも１つの他のアプリケーションについてのサービスをするのに適切な総帯域幅を維持するために、送信されたコンテンツを制限する。

図１は、本発明の原理により構築されたコンテンツ配布ネットワーク１０のブロック図である。ここに示したように、ネットワーク１０は、インターネット２５を介してクライアント側サーバ３０に接続された電子的コンテンツソース２０を含む。図１ではサーバとして示したが、コンテンツソース２０は、遠隔コンピュータ、データベース、又は、電子的コンテンツを蓄積／検索可能な他のリポジトリなど、いずれの形式であってもよい。同様に、クライアント側サーバ３０は、適当なコンピュータ、ネットワーク、又は、要求、受信、及び／又は、ここで詳述するコンテンツストリームを操作可能な他の電子処理ユニットのいずれであってもよい。いくつかの実施形態においては、コンテンツソース２０及びクライアント側サーバ３０は、同様の、又は、互いに同一の構成をとることもできる（例えば、サーバ３０は、ソース２０の「ヘッドレス端末」版として構成することもできる）。クライアント側サーバ３０は、所有権を主張可能な、又は、コンテンツストリームを操作又は修正するための他の特別なソフトウェア及び／又はハードウェアを含むことができる。かかるソフトウェア及び／又はハードウェアは、サービス又はコンテンツプロバイダによって、制御又は構成することができる。

さらに、一般にはインターネット２５として表現されているが、この通信経路は、イントラネット、無線相互接続、ＬＡＮ、ＷＡＮのような、所望の、他のいずれの適当なネットワーク相互接続、又は、安全な組み込み相互接続などの他の相互接続でもよい。インターネット２５、コンテンツソース２０、そして、クライアント側サーバ３０は、限定ではなく説明目的としてのみ示したものである。加えて、本発明は、メディアコンテンツのストリーミング配布に非常に好適であるが、必要に応じて他の適当なコンテンツ配布手法も使用することができることが理解できるであろう。

一般に、本発明のネットワーク１０は次のように作動する。端末５０において、ユーザ（不図示）が、サーバ２０に蓄積された電子的コンテンツの一定断片を選択する。この要求は、通信経路１を通ってクライアント側サーバ３０に送られ、通信リンク２を介してコンテンツソース２０へ向かう。通信経路１及び２は、イーサネット（登録商標）リンクのような先行技術において知られた何れの適当なデータ通信経路でもよい。コンテンツソース２０は、その要求を処理し、要求されたコンテンツを局所的配布のためのクライアント側サーバ３０へ送信する。好ましくは、そのコンテンツは、標準的なユニキャスト形式で通信リンク３を通り、単一チャネル上のクライアント側サーバ３０に送信される。いったんコンテンツがサーバ３０によって受信されると、端末５０に直接転送されるというよりは、むしろ、要求側端末５０がその構成となっている、マルチキャストグループ４０（典型的には、サーバ３０上のソフトウェアにおいて実装された、仮想グループ又はエンティティである。）に転送される。端末５０での要求側は、その端末についてのローカルソフトウェアプロキシ８０から、そのコンテンツを受信する。ローカルプロキシ８０は、コンテンツが送信されたマルチキャストを受信し、マルチキャストデータパケットを操作することにより適切なユニキャストフォーマットに戻す変換を行い、このコンテンツ情報を適切な順序に（つまり、連続に）配置する。いくつかの例においては、補間方法又は他の既知のデータ修復技術によって、受信データにおけるいずれかの「隙間」や欠損データを埋め合わせるために付加的なパケットを「生成する」ことが含まれる。そして、このコンテンツは、ウィンドウズ・メディア・プレーヤー^TM、リアルワン・プレーヤー^TM、又は、他の何れかの適当なコンテンツ表示ソフトウェアといった、従来のメディアプレーヤー７０を使って、端末上に表示される。上述した欠損データパケットの生成は、このコンテンツストリームから欠損したデータパケットの回復を試みたときに、いくつかのコンテンツプレーヤーが「失速する」のを予防する傾向があり、これらプレーヤーは、いくつかのデータの「欠損」にも関わらず、コンテンツを継続して表示することができる。

コンテンツがユーザによる要求を受ける他の方法は、マルチキャストグループ４０への結合又は「予約」することによるものである。この場合、モニタープログラムは、予約側がマルチキャストグループに結合され、そのうえ関連するコンテンツを要求していることを通知する（このような関連コンテンツは、予め定義してもよく、ユーザ選択可能としてもよい）。この予約に応答して、モニタープログラムは、ソース２０（詳細は、図２に関連して以下に説明する）から選択されたコンテンツのユニキャスト送信を要求する擬似メディアプレーヤー（上記と同様のメディアプレーヤーである）を起動する。そして、このコンテンツは、その要求されたコンテンツの受信に興味を示すグループのメンバーに配布される。

いくつかの実施例において、コンテンツソース２０及びクライアント側サーバ３０は互いに通信することができるので、ソース２０は、特定のマルチキャストグループ４０に予約しているか、或いは、コンテンツを送信されたユニキャストを受信しているユーザの、同一性及び／又はその数を認識することができる。これは、あるコンテンツの人気評価、又は、規定以上又は異常な数のユーザが、あるコンテンツへの評価又は要求を行っているか否かの決定を含む、多くのネットワーク管理理由により行われるものである。サーバ２０は、この又は他の状態が検知された場合に、このコンテンツブロードキャストを中断又は修正するよう構成することができる。

図１には、ただ一つのマルチキャストグループ４０が示されているだけであるが、かかるグループは、特定の場所に複数存在し得ることがわかるであろう。特定のユーザが、一つのコンテンツストリームに関連するのみの多くのマルチキャストグループを予約しなくて済むように、かかるグループは、同様の、又は、関連するタイプのコンテンツを受信することができる。さらに、あるマルチキャストグループに関連するコンテンツは、ユーザによる選択が可能であり、これにより、特定の場所のユーザ又はネットワーク管理者は、あるコンテンツストリームを特定のマルチキャストグループに自由に結合又は分離して、関心のあるカスタマイズされたグループを生成できる。

マルチキャストグループ４０にコンテンツを投稿することの一つの利点は、要求側の場所にいる他のユーザが、ネットワーク２０越しに送信される他の専用のユニキャストストリームを起動することなく、常駐のコンテンツにもアクセスできるという点である。これは、クライアント側サーバ３０が、むしろ、入ってくるコンテンツストリームの複製が可能なマルチキャストハードウェアを含み、付加的なコンテンツストリームがユーザの場所での他の端末５０（不図示）に送信されることによるものである。このように、他のユーザがコンテンツストリームを要求すると、コンテンツソース２０に対する要求が生成される前に、その要求端末は、まず、通信リンク４を介してクライアント側サーバ３０にポーリング（又は、問い合わせ）を行って（しばしば、「ハートビート」と呼ばれる）、その要求コンテンツがサーバ３０によって既に受信されているかどうかを決定する。これが真ならば、新しい要求側は、ソース２０から新しいコンテンツストリームを呼び出すというよりは、単にそのマルチキャストグループに連結し、そこから要求されたコンテンツを受信する。この配置により、ネットワーク１０によって要求される総送信帯域幅は、重複するコンテンツストリームの除去により劇的に軽減される。また、このシステムはユニキャスト通信に適した既存のネットワーク上で実施することができ、特別な、高価なハードウェアに依存しないという理由によっても有益である。

ソース２０から受信したユニキャストコンテンツストリームから、本発明によるクライアント側サーバ３０によって与えられたマルチキャストフォーマットストリームを生成及び／又は変換するために、いくつかの方法が実行される。一実施形態において、ソース２０は、単に、到来と同時にサーバ３０によって処理されマルチキャスト配布に適合したフォームに変換される、ユニキャストフォーマットデータストリームを与える。これは、ここで述べる何れかの方法を使用して、或いは、他の何れかの先行技術を使用することによって実現することができる。代替的に、ソース２０は、ヘッダービットを付加又は除去することにより、さもなければ、サーバ３０に送信する前にユニキャストフォーマットにおいて出現するようコンテンツストリームを処理することにより、ユニキャストフォーマットに「配置される」マルチキャストフォーマットストリームを与える。サーバ３０に到来すると同時に、このヘッダファイル又は付加ビットは取り除かれて、さもなければ、処理されて、そのオリジナルのマルチキャストフォーマットにおけるデータストリームから分離する。

本発明の一実施の形態によれば、ユニキャストフォーマットでコンテンツを送信し、そして、マルチキャスト配布技術を使ってコンテンツを局所的に送付することにより、本システムは、大きな総帯域幅を使用することなくコンテンツを確実に供給することができる。ソース２０からサーバ３０へのコンテンツのユニキャスト送信は、この種の送信の使用において通常発生する欠損又は不正データのエラー検査及び再取り込みによって、データ送信のための確実な方法となっている。このように、サーバ３０でのコンテンツストリームにおけるデータ品質は、概して高い。サーバ３０から局所プロキシ３０への配布コンテンツに使用されるマルチキャスト配布技術は信頼性が低いが、補間法又は他の技術によって修正可能である。総合的な結論として、システムは、比較的小さな送信帯域幅を使用するのに対して、品質の高いコンテンツ配布を与える。さらに、ここで述べられたコンテンツ配布システムは、多くのコンテンツフォームを受け入れることができ、このシステムを使用してこれらを配布可能であることが理解できるであろう。もっとも、このコンテンツは、ここで述べたような、移動するデータストリームの「有効負荷」部分であり、そして、局所端末による後続使用のための局所プロキシ８０によって（可能なエラー訂正を伴って）再構成される。

図２に、図１に示したクライアント側サーバ３０の詳細図を示す。ここに示したように、サーバ３０は、マルチキャストモニタ３１、擬似メディアプレーヤー３２、ワーカースレッド３３、キュー３４、リスニングソケット３５、そして、高いレベルの構成上の観点からの見た場合のマルチキャストグループ４０を含んでいる。局所プロキシ８０は、通信リンク１を通るリスニングソケット３５と、通信リンク４を通るマルチキャストモニタとに結合されている。

クライアント側サーバ３０が稼動すると、その作動を管理するソフトウェアルーチンが初期化される。この初期化処理は、リスニングソケット３５（典型的には、入ってくるデータストリームをモニターする仮想的ソフトウェアエンティティ）を利用可能にし、これを誘導してコンテンツ要求に対する局所プロキシ８０をモニターし、ワーカースレッド３３による後続処理のために、かかる要求の何れかをキュー３４に置く（さらに、仮想マシン又はソフトウェアエンティティは、特に、コンテンツ要求を実行する義務がある）。かかる要求が受信されると、これらは、ワーカースレッド３３からリンク２を通ってコンテンツソース２０へ送信される。

ソース２０がこのコンテンツ要求に応答すると、この応答コンテンツは、（マルチキャストグループ４０を通って）局所プロキシ８０に転送され、この要求はキュー３４から削除される。この間、マルチキャストモニタ３１は、このグループに対して付加的なユーザが参加又は脱退しているかどうか（つまり、同一コンテンツが現在受信されているか、又は、もはやこのコンテンツには関心がないか）を決定するために、グループ４０をモニターする。他のユーザがこのグループに参加し、現在は受信されていないコンテンツを要求している場合には、マルチキャストモニタ３１は、擬似プレーヤー３２を制御してコンテンツソース２０からユニキャストコンテンツストリームを検索し、可能なフォーマット変換のために、そして、適切なユーザ端末５０への配布のために、データパケットをマルチキャストグループ４０へ転送する。モニタ３１が、そのユーザグループにおいて何も検知しない場合には、擬似プレーヤー３２を制御してコンテンツストリームを終了させる。

図１及び２に示したコンテンツ配布ネットワークの他の利点は、負荷調整及びフェイルオーバー問題にうまく対処する点である。一般に、従来のマルチキャスト又はユニキャストシステムがルータの故障や帯域幅制限問題に直面したとき、もはや二地点間の直接的な経路は存在しないので、ダウンストリームユーザは、しばしばデータストリームから「切り離されて」しまう。

しかしながら、ここで述べたシステム及び方法によれば、おそらくこの問題をはるかに軽減する、有効な付加的経路選択が利用可能になる。例えば、もし特定のユーザ位置が、複数のクライアント側サーバ３０を有していた場合、ユーザ端末５０及びマルチキャストグループ４０を、不調又は過負荷のサーバ３０から正常に作動するサーバに単に（ソフトウェアにおいて）再配置することにより、不調又は過負荷又は断線されたサーバ３０の作業負荷を吸収すべくこれらのサーバを利用することができる。これは、誤り検出ソフトウェアによって自動的に実行されるので、エンドユーザはサービスの中断（例えば、特定のサーバ３０における、ハードビート故障又は過剰能力の検出又は予測によるもの、及び、作業負荷の調整又はソース２０への再接続への迅速な切替え処理の実行によるもの）に気づくことはない。

さらに、ネットワーク１０は、ユニキャスト接続をサポートしているコンテンツソース２０への接続を単に要求するだけであるので、特別なマルチキャストハードウェアの必要性を強要されることなく、特定のクライアント側サーバ３０に対する複数のデータ経路を接続に使用することができ、それによって、たとえ通信の通常チャネルが中断されたとしても、許容可能な接続を得る可能性を向上させることができる。これにより、特定のユーザがコンテンツソース２０から完全に孤立する機会が大幅に減少する。

本発明による、潜在的なフェイルオーバー又は負荷調整問題を検知及び修正するための、システム１０の作動のモニターに含まれるいくつかの動作を図３のフローチャートに示す。ここに記載した機能は、クライアント側サーバ３０、コンテンツソース２０、インターネット２５上の多くのポイント、又はこれらの組み合わせに配置された、誤り検出ソフトウェアによって実行される。この誤り検出ソフトウェアは、ネットワークサービスプロバイダ、クライアント側のネットワーク管理者又はこれらの組み合わせによって与えられ、維持される。

作動において、この誤り検出ソフトウェアは、動作１００において、コンテンツが送信されているかどうかを決定するために、コンテンツソース２０、クライアント側サーバ３０、そして、この２者間のネットワーク接続（インターネット２５）をモニターする。もし、コンテンツが送信されているならば、誤り検出プログラムがネットワーク接続及びクライアント側サーバをモニターし、スループット、帯域幅容量、全体的な利用性といった、一定の予め定義された値を多くの作動パラメータと比較することによって、システムの全体的な「健全性」を決定する（動作１１０）。この比較の後、問題又は潜在的な問題が存在するかどうかが決定され、動作１３０及び１６０において適切な改善措置（又は、少なくともその試み）が実行される。

例えば、動作１２０において、誤り検出ソフトウェアは、コンテンツソース２０及びクライアント側サーバ３０の間のネットワーク接続が、不調又は中断の何れであるかを決定する。これが真ならば、動作１３０において、誤り検出ソフトウェアは、（サービス中断に対して）全体的な送信経路を別経路にするか、或いは、もし現在使用されている経路がサービスの最低品質を保証するよう制限された帯域幅であるならば、代替の経路を通って単にそのコンテンツの一部を別経路で送信する。この点で、この誤り検出ソフトウェアは、また、サービス・ミッション・クリティカル・アプリケーションに対して最小限の総アップストリーム帯域幅が利用可能となることを保証するネットワーク接続量もモニターすることができる。

動作１４０において、誤り検出ソフトウェアは、特定のサイトでのクライアント側サーバ３０が、不調、過負荷、又は、非作動の何れであるかを決定する。これが真ならば、動作１５０において、誤り検出ソフトウェアは、近くの又は結合された他のクライアント側サーバの可用性及び現在の作業負荷にアクセスし、これらのサーバが、不調又は非作動サーバの作業負担の調整、又は、完全交換の何れに使用可能かを決定する。もし、いくつかのサーバ３０が利用可能であると分かったならば、動作１７０において、誤り検出ソフトウェアは、特定のマルチキャストグループ又はユーザ端末５０をこれらのサーバに再割り当てすることができる。いったん、システムが作動許容状態に復帰すれば、誤り検出ソフトウェアは、モニター動作１１０に復帰する。

誤り検出及び処理モニターについてのいくつかの動作をこれまで述べてきたが、これらの動作は単なる例示であって、包括的なもの、又は、必ずしも示された順序で実行されることを意図するものではないということが理解できよう。

加えて、本発明について好適な実施例に関して記述及び説明してきたが、一方で、本発明の趣旨を逸脱しない範囲において、当業者にとって自明な多くの変形及び修正も可能であることは明らかであり、このように、本発明は、かかる変形及び修正が本発明の範囲内に含まれることが意図されているということだけでは、上述の方法又は構造の詳細通りに限定されるものではない。

本発明の原理による構築された通信ネットワークの一実施形態を示すブロック図。 図１に示したクライアント側メディアサーバの詳細ブロック図。 本発明の一実施形態による負荷調整及びサービス中断問題の検知及び修正に含まれる動作の一部を示すフローチャート。

符号の説明

１０ ネットワーク
２０ コンテンツソース
２５ インターネット
３０ クライアント側サーバ
３１ マルチキャストモニター
３２ 擬似プレーヤー
３３ ワークスレッド
３４ キュー
３５ リスニングソケット
３６ マルチキャストグループ
４０ マルチキャストグループ
５０ ターミナル
７０ メディアプレーヤー
８０ ローカルプロキシ

Claims (26)

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. 請求項２４に記載の方法において、クライアント側サーバの作業負荷のバランスを図るために、前記評価ステップにおいて、前記誤り検出ソフトウェアによって過負荷であるとみなされたクライアント側サーバの作業負荷の少なくとも一部を、利用可能とみなされたサーバに再配置することをさらに含む方法。

Images