JP2007502560A - データプロバイダを選択するためのシステム及び方法 - Google Patents

Abstract

クライアント識別データとともにクライアント（１０）からデータに対する要求を受け取るステップと、前記クライアント（１０）にデータを提供できる複数のデータプロバイダ（３０）を識別するステップと、前記クライアント識別データを前記データプロバイダに提供するステップと、前記データプロバイダに対し、信号が前記クライアントに送信される、及び前記クライアントから受信されるための経過時間の値と、データ転送のためのそれらの残りの容量を示す値を確立するために試験を実行し、これらの値をシステム（２０）が使用できるようにするように指示するステップとを実行することによって、複数のデータプロバイダ（３０）から好ましいデータプロバイダが選択されるシステム（２０）及び方法。その結果、１つ以上の好ましいデータプロバイダ（３０）が、前記データプロバイダからの前記経過時間信号及び残りの容量信号に基づいて選択することが可能となる。
【選択図】 図１

Description

本発明は、データを転送するための適切な通信チャネルを、データの転送の前、あるいはデータの転送中に識別することに関する。本発明の実施形態は、ユーザが例えばビデオストリーミングを手段として、あるいはｘＤＳＬ、無線ＬＡＮ、携帯電話等の種々の手段のどれかでのマルチメディアコンテンツのダウンロードの前、又はダウンロード中にビデオデータなどのデータを受信することを希望する状況で適用可能である。

インターネットなどのようなネットワークの多くの使用方法の内、最近とみに人気を獲得してきた１つのカテゴリの使用分野としてビデオデータ又は音声データあるいは他の媒体コンテンツなどのようなデータの交換のためのネットワーク使用がある。インターネット上では複数のタイプのマルチメディアコンテンツ（例えば、ビデオ、音声）が大量に使用できるようになっている。このマルチメディアコンテンツは広帯域又は狭帯域のどちらかで種々のＩＰネットワーク上でストリーミングできる。さらに一般的には、データの分散は、データストリーミング、あるいはより一般的な形態のダウンロードを手段として達成されてよい。このような分散はピアツーピア(peer-to-peer)コンテキストで、又は商業的なマルチメディア提供サーバで実行されてよく、ｘＤＳＬ、無線ＬＡＮ、ケーブル、携帯電話（ＧＰＲＳ又は３Ｇ）等のような種々の手段を使用して実行されてよい。ｘＤＳＬには、ＡＤＳＬ（「非対称」）、ＨＤＳＬ（「高ビットレート」）、及びＲＡＤＳＬ（「速度適応」）などの多くの異なるＤＳＬ（「デジタル加入者回線」）の種類があることに注意しなければならない。デジタル加入者回線技術は、通常の電話回線上で家庭に又は小企業に高帯域幅の情報をもたらすための周知の技術である。

残念なことに、インターネットからデータを受信することが、パケット損失、パケット遅延、ジッタ、サーバがダウンしているなどの要因、及びビデオストリーミングなどのタイムクリティカルな応用例に大きな影響を及ぼす他の要因のために問題となることがある。多くの場合、ユーザはサーバに接続しようとし、サーバがダウンしている、又はひどくビジーであるかのどちらかであり、したがってビデオコンテンツを拒絶することに気付く。ユーザがなんとかサーバに接続し、ビデオコンテンツが最終的にストリーミングされても、前述されるパケット遅延などの要因のために品質が非常に悪い場合がある。これらの要因はすべて、特にストリーミングされた音声データ又はビデオデータをインターネット上で受信することに関して、エンドユーザの経験に大きく影響を及ぼし、したがってこの種のアプリケーションの処理（ｔａｋｅ−ｕｐ）を遅らせてきた。

大きなファイル又は他のアイテムのダウンロード、あるいはおそらくある特定の１つ以上のファイルに関するストリーミングされたデータの受信を希望する個人ユーザにとって、必要とされるデータを提供できる可能性がある営利的なサーバ又はピアなどの多数の異なるデータプロバイダがある可能性がある。ユーザをネットワークに接続してよい種々の手段、データの出元となる場合がある種々のデータプロバイダ、及び他の要因の理由で、個人ユーザが、ビデオサーバなどの使用可能なデータプロバイダの「プール」から、どのデータプロバイダが、ビデオコンテンツ又は他のこのようなデータを確実な接続で供給できるのかが分からないという問題に遭遇することがある。低い信頼性は、そのすべてが高品質のダウンロード又はデータストリーミングを達成する確率を引き下げるパケット損失、ジッタ、パケット遅延、及び他の要因により引き起こされる可能性がある。

その問題を解決することがどれほど重要であるのかに関する考えを示すために、以下にいくつかの「周知の」アプリケーションを挙げる。

１）「ナップスター（登録商標）（Ｎａｐｓｔｅｒ）」（最近閉鎖された音楽ファイル共用ウェブサイト）及びカザー「（Ｋａｚａａ）」（ｗｗｗ．ｋａｚａａ．ｃｏｍ）のようなピアツーピアアプリケーション
２）多くのビデオサーバがネットワークのどこかにセットアップされるビデオストリーミングコンテンツプロバイダ
本発明が特に適用可能であるビデオサーバに関連して、この問題に対する従来の手法は、どのサーバが最も信頼できる接続を提供するのかに関する事前の知識を持たずにデフォルトのビデオサーバを選ぶことであり、それはエンドユーザがネットワークのどこに位置しているのかに左右されるが、何らかの点でより高速又はより優れている可能性のあるサーバを選ぶためのいくかの手法はすでに存在している。

（従来の技術）
いくつかの関連する論文のまとめを以下に示す。

「ピアツーピアファイル共用システムの測定研究」、著者、Ｓａｒｏｉｕ Ｓ、Ｇｕｍｍａｄｉ ＰＫ、Ｇｒｉｂｂｌｅ ＳＤ（米国、ワシントン州シアトル）、ワシントン大学コンピュータサイエンス及びエンジニアリング学部、マルチメディアコンピューティング及びネットワーキング２００２、２００２年１月２３日から２４日、ＳＰＩＥ−国際光工学学会の議事録−国際光工学学会、第４６７３巻、１５６−７０ページ
要約：グヌーテラ（Ｇｎｕｔｅｌｌａ）及びナップスター（Ｎａｐｓｔｅｒ）などのピアツーピアマルチメディアファイル共用アプリケーションの人気に伴い、ピアツーピアアーキテクチャに関する研究活動が最近相次いで行われている。この論文は前記２つの人気があるピアツーピアファイル共用システム、つまりナップスターとグヌーテラの詳細な測定研究を含み、特に、これらの２つのシステムに関与するエンドユーザホストの数を特徴付けようとしている。この特徴付けは、これらのホストとインターネット全体の間のボトルネック帯域幅、パケットをこれらホストに送信するためのＩＰ待ち時間、ホストがどの程度頻繁にシステムに接続、切断されるのか、ホストがどのくらいの数のファイルを共用し、ダウンロードするのか、ホスト間の協力の程度、及びこれらの特性の間のいくつかの相関関係を含む。

「ピアツーピアネットワークにおけるマルチメディアオブジェクトの処理：著者：Ｋａｌｏｇｅｒａｋｉ Ｖ．（ＨＰラボ、米国カリフォルニア州パロアルト、Ｄｅｌｉｓ Ａ，Ｇｕｎｏｐｕｌｏｓ Ｄ、２００２年ＣＣＧＲＩＤ議事録、クラスタコンピューティング及びグリッドに関する第２回ＩＥＥＥ／ＡＣＭ国際シンポジウム、２００２年５月２１日から２４日、ＩＥＥＥコンピュータ学会、４３８−９ページ
要約：本論文は、ピアツーピア（Ｐ２Ｐ）ネットワーク上でのビデオサービスの提供がどのようにしてビデオサービスの送達のために今日使用されているおもに独自仕様のアーキテクチャに、実行できる代替策を提供できるだけではなく、それが、信頼できるスケラブルな方法で実行できるのかを説明しようとしている。リソースの特別のＰ２Ｐネットワークの手法を足場に、映画の及び／又はビデオクリップ記憶及び検索をサポートできる新しいアーキテクチャが提案されている。提案されている構成は、使用可能なサーバ間の完全接続性だけではなく、ネットワークに対する高性能リンクの可用性、ノードにそれ自体の近傍にあるコンテンツを「認識」させるピア内での独占的且つ部分的な索引付けの使用、オブジェクトの複製及び人気のあるアイテムのキャッシュも利用する。アーキテクチャは、マルチメディアオブジェクトの検索に効率的な索引付け機構を使用することを主張し、サーバの故障を考慮に入れ継続的な動作を保証し、ユーザの混乱を最小限に留めて、提供されたサービス及び／又はネットワークリソースの進展だけではなく新しいサーバのトランスペアレントな装着（ｐｏｐｕｌａｔｉｏｎ）も可能にする。このようなＰ２Ｐインフラストラクチャを実現するための１つの重要な条件は、コアピア（又はサーバ）が膨大なマルチメディアデータを効果的に、処理、送達できる低待ち時間且つ高帯域幅のネットワークを介してリンクされると考えられているという点である。エンドユーザがオブジェクトサーバに対する十分な接続を有する必要があることも見込まれている。

「ピアツーピアストリーミングメディア送達」：著者：Ｓｔｏｌａｒｚ Ｄ、議事録、第１回ピアツーピアコンピューティングに関する国際会議、２００１年８月２７日から２９日、ＩＥＥＥコンピュータ学会、４８から５２ページ
要約：それに関してどのような定義がなされたのかに関係なく、ピアツーピアは物事を行う新しい方法を求める効果的なときの声であると言われている。ストリーミングメディア送達は特にピアツーピアアーキテクチャ手法の影響を受けやすい。ピアツーピアシステムは帯域幅コストを削減し、インターネット上のオンデマンドコンテンツ及びストリーミングコンテンツのスケラビリティを高めることが示されている。類似した技法は、ネットワーク層マルチキャスティングの効率的なサブネット放送機能のアプリケーション層の実現である「仮想マルチキャスト」を作成するために使用できる。

「ピアツーピアメディアストリーミングに関して」：著者：Ｄｏｎｇｙａｎ Ｘｕ、Ｈｅｆｅｅｄａ Ｍ、Ｈａｍｂｒｕｓｃｈ Ｓ、Ｂｈａｒｇａｖａ Ｂ（米国インディアナ州ウェストラファイエット、パデュー大学コンピュータサイエンス学部）、議事録、分散コンピューティングシステムに関する第２２回国際会議、２００２年７月２日から５日、ＩＥＥＥコンピュータ学会３６３−７１ページ
要約：
本論文では、ピエアツーピアメディアストリーミングシステムは、以下の特性に関して研究されている。（１）そのストリーミング容量は動的に増加する。（２）ピアはサーバのような動作を示さない。（３）ピアはその帯域幅貢献において異質である。及び（４）各ストリーミングセッションは複数の供給側ピアを含む可能性がある。これらの特性に基づき、２つの問題が調査される。つまり（１）１回のストリーミングセッションで複数の供給側ピアにどのようにしてメディアデータを割り当てるのか、及び（２）システムの総合的なストリーミング能力をどのようにして迅速に増幅するかである。第１の問題に提案された解決策とは、結果として生じるストリーミングセッションにおいて最小のバッファ遅延を生じさせる最適メディアデータ割り当てアルゴリズムＯＴＳ_ｐ２ｐである。第２の問題に対する解決策は分散分化型許可制御プロトコルＤＡＣ_ｐ２ｐである。異なるアウトバウンド帯域幅で要求側ピア間を区別することにより、ＤＡＣ_ｐ２ｐは高速システム容量拡大を達成すると言われ、許可率、待機時間、及びバッファ遅延においてすべての要求側ピアのベネフィットとなり、ピアがそれらの真に使用可能なアウトバウンド帯域幅を提供するためのインセンティブを付与する。

ここで背景の特許参考文献を参照すると、データ送達のサーバ側最適化のためのシステムは、米国第６，１１２，２３９号（Ｋｅｎｎｅｒら）に開示されている。類似したシステムは米国第６，５０２，１２５号及び米国第２００３／０１４５００７号（ともにやはりＫｅｎｎｅｒら）に開示されている。これらのシステムでは、ユーザは最適化を実行するためにユーザ自身のマシンで実行しなければならないソフトウェアを与えられる。同様に、米国第６，４７７，５２２号（Ｙｏｕｎｇ）では、アプレットがファイルに対する要求をインターセプトし、ファイルを提供するために最善のサーバを決定するインターネットからのファイルのダウンロードを最適化するためのシステムが開示されている。やはり、ソフトウェアがユーザのマシンにインストールされ、ユーザのマシンから実行されることが必要である。

インターネットを介して接続されるユーザ間でのデジタル電子ゲームプレイの分野に関して、米国第６，３０４，９０２号（Ｂｌａｃｋら）は、複数のゲームをプレイするユーザと任意の必要な１台以上のサーバの間のデータ通信リンクの品質がこのようなゲームプレイに十分であることを確実にするための方法を開示している。ゲームプレイは、通常、複数のプレーヤと、複数の考えられるサーバから選択されてよい１台の共通サーバの間での２方向の情報の交換を必要とする。１台のサーバは仲介役の役を務め、複数の考えられるサーバから数台のサーバを選択し、これらから要求されたゲームのためのサーバとして１台を選択する。このようなゲームプレイシステムの性質のため、目的は複数のユーザが同じサーバに同時に接続できるようにすることであり、したがってサーバは、同時にあるいは次々とサーバに接続を試みることがある複数のユーザによるその使用を容易にするように選ばれることに留意されたい。

前記とは対照的に、本発明の実施形態は、マルチメディアコンテンツのダウンロード又はそのユーザによって要求される他のこのようなデータ交換に適切であるだけではなく、それがまた多数の他のユーザにデータを提供するための低速化又は過負荷に最も被りそうにないサーバに対する接続がその個人ユーザによって確立できるように、個人ユーザにとって「最も速い」、「最も近い」、又はそうでなければ最も適切なサーバ、又は最速で最善あるいは最も信頼できる接続を特定することを目的とする。本発明の好ましい実施形態によれば、この特定プロセスは、ユーザが自身のマシンに特殊なソフトウェアをインストールする、あるいは実行する必要なく実施することが可能である。

本発明によれば、複数のデータプロバイダから好ましいデータプロバイダを選択するためのシステムが提供され、前記システムは、
クライアントからデータに対する要求を受け取るための手段と、
前記クライアントからクライアント識別データを受け取るための手段と、
前記クライアントにデータを提供することができる複数のデータプロバイダを特定するための手段と、
前記データプロバイダに前記クライアント識別データを提供するための手段と、
前記データプロバイダに対し、
（ｉ）前記クライアントに試験信号を送信するステップと、
（ｉｉ）前記クライアントから帰還信号を受信するステップと、
（ｉｉｉ）試験信号の送信と帰還信号の受信の間の経過時間の値を取得するステップと、
（ｉｖ）システムが経過時間を示す信号を入手できるようにするステップと、
（ｖ）システムがそれらの残り容量を示す信号を入手できるようにするステップと、
を実行するように指示するための手段と、
前記データプロバイダから経過時間信号及び残り容量信号を受信するための手段と、
前記信号に基づいて好ましいデータプロバイダを選択するための手段と、
前記クライアントに前記好ましいデータプロバイダのアイデンティティに関する情報を提供するための手段と、
を含む。

本発明によれば、複数のデータプロバイダから好ましいデータプロバイダを選択するための方法も提供され、前記方法は、
クライアントからデータに対する要求を受け取るステップと、
前記クライアントからクライアント識別データを受信するステップと、
前記クライアントにデータを提供することができる複数のデータプロバイダを特定するステップと、
前記データプロバイダに前記クライアント識別データを提供するステップと、
前記データプロバイダに対し、
（ｉ）前記クライアントに試験信号を送信するステップと、
（ｉｉ）前記クライアントから帰還信号を受信するステップと、
（ｉｉｉ）試験信号の送信と帰還信号の受信の間の経過時間の値を取得するステップと、
（ｉｖ）システムが前記経過時間を示す信号を入手できるようにするステップと、
（ｖ）システムがそれらの残り容量を示す信号を入手できるようにするステップと、
を実行するように指示するステップと、
前記データプロバイダから経過時間信号及び残り容量信号を受信するステップと、
前記信号に基づいて好ましいデータプロバイダを選択するステップと、
前記クライアントに前記好ましいデータプロバイダのアイデンティティに関する情報を提供するステップと、
を含む。

本発明の実施形態によるシステム及び方法を使用することによって、ユーザがビデオコンテンツ又は他のデータへのアクセスの試行を望むときに、エンドユーザに完全に不可視とすることが可能となり、ユーザのマシン上での特殊なソフトウェアのインストール又は実行を必要としない小さい試験プロセスを実行し、このようにして、多くの使用可能なビデオサーバ又は他のデータプロバイダから前記特定のユーザにとって最も信頼性があり、最速で、最も輻輳していない、あるいはそれ以外の場合は最も適切なプロバイダを決定することによって前記に概略された問題を解決することが可能である。このようにして、ユーザは最も「信頼できる」プロバイダに接続することにより最良のデータダウンロード又はデータストリームの受信が可能となり、このようにしてマルチメディアアプリケーション及び他のこのようなアプリケーションに関するユーザの経験を改善することができる。

好ましい実施形態によれば、システムは、特定のビデオファイルなどの特定のアイテムに対する要求をユーザから受け取るように構成されてよい。それは、次に、事前に選択さるか、あるいはシステムに対する加入者であってもよく、おそらくはデータプロバイダのグループの、あるいはインターネット全体又は他のこのようなネットワークの、要求される特定のアイテムを提供できるデータプロバイダを特定するためにサーチを実行できる。このようなサーチに続き、システムは、これらの潜在的なデータプロバイダだけから選択を行うために選択プロセスを実行できる。代わりに、ユーザは「好ましい」データプロバイダが選択されるためにある特定のアイテムを指定することを求められる必要はない。しかしながら、このようなケースでは、ユーザは自身が、ユーザが要求することを希望する特定のアイテムを含むこともあれば、含まないこともある、いったん選択されたならば、好ましいデータプロバイダが提供できるアイテムの「カタログ」に限定されているのに気付く可能性がある。

本発明の好ましい実施形態によるシステムでは、前記データプロバイダに指示するための手段は、集中型サーバなどの、クライアントから遠隔の手段である。用語「遠隔の」は、指示手段とクライアントが地理的に離れていることを暗示する必要はなく、クライアントと指示手段のそれぞれの機能がクライアントマシン上の１つの共通した処理手段によって実行されないことを暗示するにすぎない。クライアントとサーバのそれぞれの物理的な場所に関係なく、クライアント以外の何かが「指示すること」を実行し、したがってソフトウェアがクライアントマシンにダウンロードされる必要がないことが明らかとなるであろう。

本発明の実施形態によるシステムは、所定の閾値を超えた残りの容量を有するデータプロバイダだけから好ましいデータプロバイダを選択し、事実上、その残りの容量がその所定の閾値以下であるあらゆるデータプロバイダを不適格とするように構成されてもよい。代わりに、決定が特定の閾値によって制約されるのではなく、２種類の信号（つまり経過時間及び残り容量）により表されるそれぞれの要因の間の最善のバランスを取得するために最終的な選択が行われてもよい。

好ましい実施形態によれば、データプロバイダが提供するように指示される可能性のある残りの容量を示す信号は、その残りの帯域幅を示す信号であってよい。

好ましい実施形態によるシステムでは、好ましいデータプロバイダのアイデンティティに関する情報を提供するために、システムはウェブサイト上で情報を提供するように構成されてもよく、それは選択プロセスが実行され、新しい「好ましい」データプロバイダが確立されるたびに更新されてもよい。情報は、好ましいデータプロバイダのユニフォームリソースロケータ（ＵＲＬ）の形で提供されてよい。しかしながら、情報はユーザへのｅメール又は必要な情報を含む他のこのようなメッセージの送信などの他の方法で提供されてよい。

本発明の実施形態によるシステムは、複数の「好ましい」データプロバイダを選択できる。このケースでは、それらは、おそらく、それらがそれぞれの試験で発揮した性能の順（つまり、最高、２番目に最高等）に基づいて順位付けを示すリストの形式でユーザに複数の好ましいデータプロバイダに関する情報を提供でき、あるいは代わりに所定の品質閾値を超えた性能を発揮したものがユーザに特定されてもよい。

本発明の好ましい実施形態の説明において、以下に示す技術、つまりＲＭＩ、ＪＡＶＡ（登録商標）、サーブレット（Servlets）、ＨＴＭＬを説明する。これらの技術についての情報は公に入手できるが、ここでは専門用語、及びそれに関連付けられる略語及び頭字語に関する不明瞭さの可能性を回避する目的で概要を示す。

ＲＭＩ（「リモートメソッド呼び出し(Invocation)」）は、Ｊａｖａ開発キット（ＪＤＫ）１．１で提供される、たとえそれらがネットワークによって分離されていたとしても異なるＪａｖａ仮想マシン（ＪＶＭ）の間のメッセージングを可能にする、新しいアプリケーションプログラミングインタフェース（ＡＰＩ）である。

「ＪＡＶＡ」はインターネットの分散環境で使用するために明示的に設計されたプログラミング言語である。それは、単一のコンピュータ上で実行可能であり、あるいはネットワーク内のサーバとクライアントの間で分散されてよい完全なアプリケーションを作成するために使用できる。それは、ウェブページの一部として使用するための小さいアプリケーションモジュール、または「アプレット」を構築するために使用できる。アプレットは、ウェブページユーザがページと対話できるようにする。

「サーブレット」は、サーバ上で実行する小さいプログラムと定義できる。前記用語は、通常、ウェブサーバ環境の中で実行するＪａｖａアプレットを指す。これは、ウェブブラウザ環境の中で実行するＪａｖａアプレットに類似している。

ＨＴＭＬ（「ハイパーテキスト・マークアップ言語」）は、ワールドワイドウェブのブラウザページでの表示を目的としたファイルに挿入される記号又は符号の集合である。「マークアップ」は、ウェブページのワード及び画像をユーザのためにどのように表示するのかをウェブブラウザに教える。

本発明の更なる特徴及び利点は、一例としてのみ、及び類似した参照番号が類似したパーツを指す添付図面を参照することにより提示されるその実施形態の以下の説明から明らかになるであろう。

本発明の実施形態によるシステムを含むネットワークが図１に示されている。この図は、好ましい、または「最高の」ビデオサーバを決定するプロセスで発生する可能性があるネットワークの構成要素の間の対話を明らかにする。この一部が、ビデオストリーミングのために使用される典型的なアーキテクチャ（クライアント、ウェブサーバ、ビデオサーバ）であるが、それはある特定のエンドユーザのためのビデオストリーミングにどの「ビデオサーバ」が最も適しているのかを決定するために試験を実行できるようにするＪＡＶＡ ＲＭＩ実行も含む。前記プロセスは詳細に後述される。図中のステップは、イベントの好ましい順序を示す。システムの構成要素は以下のように要約できる。

クライアント：「クライアント」１０は、一般的には、ウェブブラウザ及び「ビデオプレーヤ」を実行する「エンドユーザの」パーソナルコンピュータ（ＰＣ）又は類似したプラグイン又はアプリケーションを指す。しかしながら、クライアントが、インターネットと対話するためにＷＡＰ（ワイヤレスアプリケーションプロトコル）又は類似するウェブブラウジングプロトコルを使用する３Ｇ（「第三世代」）携帯電話などのデバイスである場合があることに留意する。

集中型サーバ：「集中型」サーバ２０は、一般的には、ウェブサーバソフトウェアを実行するウェブサーバ２２を含むＰＣなどのようなコンピュータ端末を指す。集中型サーバ２０は、このようにして、ユーザがそこから例えばビデオクリップの選択を行うことができるウェブページの形でユーザに情報を提供又は提示でき、前記ウェブページはビデオストリーミングサーバサイトへのリンクを含む。集中型サーバは、ダイナミックウェブページを作成し、ＲＭＩサーバと通信し、最終的には、複数の「ビデオストリーミングサーバ」のどれかにインストールされる「ＲＭＩサーバ」と通信するためにＪＡＶＡ ＲＭＩクライアントを動作することに関与する「サーブレット」（ＪＡＶＡ）ソフトウェア２４又は「ＡＳＰ」（マイクロソフト（登録商標））ソフトウェアを実行できる。

集中型サーバ２０は、このようにしてユーザにダイナミックウェブページを最初に提示できる。集中型サーバが、それが「最高の」（つまり、最も速い、最も近い、あるいはそれ以外の場合最も適切な）１以上のサーバを見つけることを目的とする任意の「サーチ」モードで動作する前に、それは１以上の「デフォルト」サーバへのリンクを含んでもよい。任意の時点で、ユーザは１つのコンテンツを選択でき、あるいは１つのコンテンツに対する要求を送信できる−これがサーチが完了する前に発生する場合には、デフォルトのストリーミングサーバがコンテンツを送達するために選ばれる、あるいは１つ以上のデフォルトサーバへのリンクが提供されてもよい。

ビデオストリーミングサーバ：それぞれが圧縮されている、又は圧縮されていない「ビデオコンテンツ」、集中型サーバ２０において「ＲＭＩクライアント」２６と通信する「ＲＭＩサーバ」３６、及びクライアント１０などのエンドユーザに「ビデオストリーミングコンテンツ」を供給できる適切なソフトウェアなどの記憶されている「マルチメディアコンテンツ」３５を含む、又は「マルチメディアコンテンツ」３５にアクセスする、複数の「マルチメディアサーバ」又は「ビデオストリーミングサーバ」３０が示されている（この例では「Ｃ１」、「Ｃ２」、及び「Ｃｎ」として特定されるこのような３つのサーバが示されている）。それらは、また後述されるような「ピング試験」を実行するため、及び詳細に後述されるような「往復応答時間」のための値を設定し、この値は平均値であってもよく、これを集中型サーバに提供するための手段も備える。

これらの構成要素のすべては、後述されるように、ビデオストリーミングコンテンツをエンドユーザに送達するために対話してもよい。

「最高の」（又は少なくとも「好ましい」）サーバを決定するプロセスが後述される。「最高の」が主観的な用語である一方、データ転送において非常に重要である２つの要因は速度と信頼性であることが理解されるであろう。これらの要因のどちらかに関するいかなる改善もダウンロードの全体的な品質の改善と見なすことができる。このプロセスでは、以下に挙げる２つの主要な観点がある。

（ａ）「待ち時間」試験及び
（ｂ）「残りの帯域幅」試験
これらの試験は、どちらかの順で次々に、あるいは同時に実行できる。それらは以下の段落に説明される。

ａ）待ち時間試験
ステップ１（図１に示される）：「クライアント」又は「ユーザ」１０は、マルチメディアサーバのための全体的な「サーチ」プロセスの調整に責任を有する「集中型」サーバ２０を介して「マルチメディアサーバ」への接続の要求を提出する。この集中型サーバ２０は、「クライアント」又は「ユーザ」マシン１０のＩＰアドレスを検索できる「サーブレット（Ｓｅｒｖｌｅｔ）」２４を、それがこのＩＰアドレスを例えば「ＪＡＶＡ ＲＭＩ」技術を使用して多くのマルチメディアサーバ３０に伝搬できるように含む。ユーザは特定のデータ、又は、例えば特定のビデオファイルなどのような特定のアイテムに対する要求を行うことができ、その場合集中型サーバは、そのデータ、アイテム又はファイルを提供することができると判明しているサーバから「最高の」のサーバを決定するプロセスを続行する前に、それらを提供できるビデオサーバのサーチを実行できる。代わりに、ユーザの要求は一般的にデータに対してであってもよく、その場合、集中型サーバはサーバの集合、所定のサーバ、あるいは別の代替となるサーバから「最高の」サーバを決定するプロセスを実行でき、その場合にはユーザは、例えばそのサーバがいったんユーザに入手可能なアイテムの「ライブラリ」を提供したら、好ましいサーバのアイデンティティがいったん確立されたら、好ましいサーバからどの１つ以上のアイテムを受け取るのかを選択できる。

ステップ２（図１に示される）：前記に言及されたように、「クライアント」又は「ユーザ」マシン１０から検索されるＩＰアドレスは、集中型サーバ２０の「ＲＭＩクライアント」２６からマルチメディアサーバ３０の「ＲＭＩサーバ」３６に伝搬される。

ステップ３（図１に示される）：「ビデオストリーミングサーバ」３０に位置する各「ＲＭＩサーバ」３６はそのＩＰアドレスを検索し、それぞれのサーバはそのＩＰアドレスを使用して「ユーザ」マシン１０を「ピングする（ＰＩＮＧ−ｉｎｇ）」ことによって試験信号を送信する。「ピング」とは、インターネットコントロールメッセージプロトコル（ＩＣＭＰ）パケットを「ビデオストリーミングサーバ」マシンから「クライアント」マシンに送信するプロセスを動作するために使用されてよいアプリケーションソフトウェア「パケットインターネットゴーファー(Gophers)」を指し、このようにしてパケットがその「ビデオストリーミングサーバ」マシン３０から「クライアント」マシン１０に移動し、ビデオストリーミングサーバに戻るのに要する時間を測定できる。一般的には、（複数が送信される場合に）無事に受信され、戻されるパケットが多く、パケットがある特定の「ビデオストリーミングサーバ」マシンからクライアントマシンまで移動し、戻ってくるのに要する時間（通常はミリ秒単位で測定される）が少ないほど、その「ビデオストリーミングサーバ」に接続される場合にエンドユーザが取得するであろうビデオストリーミング性能はよくなる。この時点で、数パケットの「ピング」プロセスの後に「要求タイムアウト応答」メッセージが受信される場合、パケットが「不成功」と見なされる場合があることが言及されなければならない。この場合、パケットは「失われた」と見なされ、デフォルト値（通常１０００ｍｓ）が与えられ、このようにして最後に計算される「平均値」に影響を及ぼす。

前記のように「ピング」試験を活用することは、特にそれがユーザマシン上で特別なソフトウェアをインストールすることを必要としないため特に有利である一方、待ち時間を測定するための代替策が存在する。これらの代替策は、「トレースルート（Ｔｒａｃｅｒｏｕｔｅ）」などの既知のネットワークツール、及びＵＤＰ（「ユーザデータグラムプロトコル」）などのＩＣＭＰ以外のプロトコルに適切な「ピング」同等物を含む。

ステップ４（図１に示される）：各マシンで「ピングする（Ｐｉｎｇｉｎｇ）」プロセスが完了した後、平均値が計算され、この値は再びＲＭＩを使用して「集中型」サーバに返される。このようにして表１に示されるような「平均」応答値時間を有する「表」が「ＲＭＩクライアント」で形成される。これらのすべての値から、最小の値（つまり、この場合にはサーバＣ１）が好ましい、又は最も適切な「ビデオストリーミングサーバ」（又は「最高の」サーバ）として選ばれてもよい。

表１：これは、ＲＭＩ技術を用いてすべての「ビデオストリーミングサーバ」から取り出される平均値を示す。「ＲＭＩクライアント」は最小値（つまりサーバＣ１）を選んでよい。

ステップ５（図１に示される）：次に「サーブレット（Ｓｅｒｖｌｅｔ）」は、最小の「平均応答時間」の「ビデオストリーミングサーバ」のＩＰアドレスを「ＲＭＩクライアント」から取り出す。前記の例では、これがＩＰアドレス「１３２．１４６．１０７．６１」を有する「Ｃ１」である。それは、その新しいＩＰアドレスでビデオリンクを含むウェブページを更新できる。このようにして、「集中型」サーバはＪＡＶＡ「サーブレット」技術を介して「マルチメディア」サーバにクライアントをリダイレクトする。

以上で待ち時間試験は終わりである。前記に述べられたような全体的なプロセスがエンドユーザにとっては不可視であり、完了するには２〜３秒しか要さない可能性があり、この試験だけに基づいて選択することによって、ユーザがビデオストリーミングコンテンツを取得可能なサーバが、「好ましい」「ビデオストリーミングサーバ」から選択されてよい。

前記プロセスは、例えば「ビデオサーバ」管理者によって設定される特定の期間の後に繰り返すことができ、毎回ウェブページは、新しい好ましい「ビデオストリーミングサーバ」ＩＰアドレスで動的にリフレッシュすることができる。

ｂ）残りの帯域幅試験
前述されたようなシステムは「待ち時間試験」だけの結果に基づいて好ましいサーバを設定できるが、本発明の実施形態によるシステムは「残り帯域幅試験」と呼ばれる追加試験を実行することもできる。これにより、サーバを、相当数の他のユーザによって使用されているため、あるいはその帯域幅の高い割合がすでに他のタスクに割り当てられているため、それが現在「輻輳している」場合には好ましいサーバとして選ばれることから「不適格とする」ことを可能にする。図２は特定の期間での「サーバ」内の残りの「アップリンク」容量の計算を図解する。

ステップ３ａ（図１に図示されていない）：必ずしもでなくても好ましくは、「待ち時間試験」のステップ３と同時に、マルチメディアサーバ３０のそれぞれの「ＲＭＩサーバ」３６は、「ビデオストリーミングソフトウェア」からそのマルチメディアサーバにすでに接続されている他のユーザの数のための値Ｕ、及びそれぞれのものごとに要求されるクリップの「ビットレート」Ｂを得ることが可能である。図２を参照して、既存のユーザのビットレートは同じである必要はないが、Ｕ人の既存のユーザのそれぞれのビットレートが、簡単にするために毎秒２２０キロビットであるとして示されている。このような情報は、「マイクロソフト」の「ウィンドウズ（登録商標）メディアＳＤＫ」のような「プラグイン」ライブラリを、あるいは他社の類似したツール（ＲｅａｌＶｉｄｅｏ、ＱｕｉｃｋＴｉｍｅ他）を使用してプログラムで取り出すことができるであろう。

以下の式から、「ＲＭＩサーバ」からの要求時に消費される総帯域幅が与えられるであろう。

式中、
Ｎ_{ｔｏｔａｌ}は「ＲＭＩサーバ」からの要求が発生した時点で要求された「ビデオストリーム」によって消費される総帯域幅である。

Ｂ_ｉは、ｉ番目のユーザのために要求された「ビデオクリップ」の符号化「ビットレート」である。

Ｕは、「ビデオストリーミングサーバ」に接続された「ユーザ」の数である。

同時に、「ＲＭＩサーバ」は、ネットワーク接続により制限される「ビデオストリーミングサーバ」の最大使用可能「アップストリーム」帯域幅を確立してよい。これは、「管理者」が全体的なソフトウェアをインストールするときに管理者によって手動で設定できるか、あるいはそれは最大「アップリンク」接続帯域幅を決定するマシンで局所的に実行しているプロセスから自動的に取り出すことができるであろう。

このようにして、Ｘ_ｍａｘは、最大入手可能「アップストリーム」帯域幅である。

最後に、以下の式により使用可能な「アップリンク」帯域幅の「パーセンテージ」が得られる。

式中、Ａは残りの「アップストリーム」帯域幅のパーセンテージである。

このようにして、例えば１０％から２０％の「閾値」を設定でき、その結果Ａが閾値を下回ると、この「ビデオストリーミングサーバ」がほぼ輻輳していると仮定することができ、したがってそれは最終的な「最高のビデオストリーミングサーバ」決定（ステップ４）に含まれない。

以下に、前記の数式を説明するために例が示されている。

例えば、「ビデオストリーミングサーバ」に符号化された２つのクリップがある状況を取り上げてみよう。第１のファイルは「ｖｉｄｅｏｆｉｌｅ１」と呼ばれ、２２０ｋｂｐｓという符号化ビットレートを有する。第２は「ｖｉｄｅｏｆｉｌｅ２」と呼ばれ、１４０ｋｂｐｓという符号化ビットレートを有する。他の１０人の「ユーザ」は、すでに「ビデオストリーミングサーバ」に接続されており、その内の７人は「ｖｉｄｅｏｆｉｌｅ１」を、その内の３人は「ｖｉｄｅｏｆｉｌｅ２」を見ている。最大使用可能帯域幅は、Ｘ＝１０Ｍｂｐｓ＝１００００Ｋｂｐｓである。閾値を２０％と設定する。

式（Ｆ．１）から、以下が得られる。

ユーザ数：Ｕ＝１０
「ｖｉｄｅｏｆｉｌｅ１」を見ている７人のユーザ：Ｂ１＝２２０、Ｂ２＝２２０、Ｂ３＝２２０、Ｂ４＝２２０、Ｂ５＝２２０、Ｂ６＝２２０、Ｂ７＝２２０
「ｖｉｄｅｏｆｉｌｅ２」を見ている３人のユーザ：Ｂ８＝１４０、Ｂ９＝１４０、Ｂ１０＝１４０
したがって、総消費帯域幅は、以下のようになる。
Ｎ＝Ｂ１＋Ｂ２＋Ｂ３＋Ｂ４＋Ｂ５＋Ｂ６＋Ｂ７＋Ｂ８＋Ｂ９＋Ｂ１０
＝２２０＋２２０＋２２０＋２２０＋２２０＋２２０＋２２０＋１４０＋１４０＋１４０＝１９６０
Ｎ_{ＴＯＴＡＬ}＝１９６０ｋｂｐｓ
前記に述べられたように、最大使用可能帯域幅Ｘ＝１００００ｋｂｐｓである。

式（Ｆ．２）から、以下が得られる。

したがってＡ＝８０．４％
結論：残りの使用可能な「アップリンク」帯域幅は、２０％という閾値を超える８０．４％である。したがって、このサーバはさらに多くの「ビデオストリーム」に対する要求を受け入れることができ、ステップ３からのその「使用可能応答時間」は、最終的な「最高のビデオストリーミングサーバ」決定に含まれる。

以下のような「残りの容量」を計算する代替の方法が存在することに注意する必要がある。プログラムは、サーバ又はある期間に渡って送信されるパケット（ＴＣＰ／ＵＤＰ）を測定することができる他のこのようなデータプロバイダで連続して実行することにより「平均アップリンク容量」を測定できる。このようなプログラムは広く入手可能であり、データプロバイダへの及びデータプロバイダからのトラフィックの推定値を与えるであろう。このようなプロセスは前述されたプロセスよりさらに複雑な場合があるが、瞬間的な平均残り帯域幅のより正確な測定値を提供することができ、あらゆる「マルチメディアパケット」だけではなく、他のトラフィック（ＴＣＰ受領確認メッセージ、オーバヘッドパケット、他のネットワークアプリケーションからのトラフィック等）も測定できる。前記に詳細に説明されたものは「帯域幅測定」が必要とされるときにだけ起動する必要があるが、このような方法は一般的には「データプロバイダ」上で持続的に実行するであろう。

ステップ４ａ（図１に図示されていない）：いったん前記値が設定されると、使用可能な「アップリンク」帯域幅のパーセンテージは、各ビデオストリーミングサーバ３０によって集中型サーバ２０のＲＭＩクライアント２６に返されてよい。いったん「ピング（Ｐｉｎｇｉｎｇ）」プロセス（「待ち時間試験」のステップ３）が各マシンに関して完了されると、平均応答時間値及びパーセンテージ値を有する表が「ＲＭＩクライアント」に形成されてよい（以下の表２を参照すること）。任意のビデオストリーミングサーバの使用可能な「アップリンク」帯域幅のパーセンテージが所定の「閾値」を下回る場合、そのサーバはその応答時間値に関係なく不適格と見なされてよい。不適格とされていないものから、最小の平均応答時間を有するもの（つまりこの例では「Ｃ１」）が、最も適した（又は「最高の」）ビデオストリーミングサーバとして選ばれてよい。

表２：これは、使用可能なアップリンク帯域幅値のパーセンテージとともに、ＲＭＩ技術ですべての「ビデオストリーミングサーバ」から取り出された「平均応答時間」値を示している。「ＲＭＩクライアント」は２０％という所定の閾値以下のパーセンテージ値を有するために不適格とされない最小応答時間値を有するサーバを選んでよい。ｎ番目のサーバ（Ｃｎ）は「輻輳している」と考えられるため、その「平均応答時間」値は、非常に低いけれども最終的な決定から拒絶されることに留意されたい。

ステップ５（図１に図示される）：「サーブレット」は「ＲＭＩクライアント」から好ましいビデオストリーミングサーバのＩＰアドレスを取り出し、それはその新しいＩＰアドレスとのビデオリンクを含むウェブページを更新する。このようにして、「集中型」サーバは、ＪＡＶＡ「サーブレット」技術を介してその「マルチメディア」サーバにクライアントをリダイレクトしてよい。

以上で試験の終わりであり、これによりユーザは「最高の」ビデオストリーミングサーバからビデオストリームコンテンツを受信できるであろう。

プロセスは、「ビデオサーバ」管理者によって設定される固定期間について繰り返すことができ、毎回、ウェブページは新しい「ビデオストリーミングサーバＩＰアドレス」で動的にリフレッシュできる。

特殊ケースの検討：
以下に簡略に、前記プロセスを崩壊させる可能性があるいくつかの特定の状況をレビューする。

ＲＭＩサーバが「ダウン」している：この場合、ＲＭＩクライアントがある特定のビデオストリーミングサーバのＲＭＩサーバとの通信を確立できない可能性がある。したがって、この「サーバ」が現在動作していないと仮定されてよい。したがって、この「サーバ」は、どの「ビデオストリーミングサーバ」が「最高」であるのかの決定で考慮されない。

ユーザ／クライアントがファイアウォールの後ろにある：この特別なケースでは、クライアントのマシンがすべての「ピング」パケットをブロックし、その結果すべてのサーバは「要求タイムアウト応答」を受信する場合がある。この場合、エンドユーザはデフォルトの「ビデオストリーミングサーバ」を提供され、このイベントについて（つまり、ユーザがファイアウォールの後ろにあって、ＩＣＭＰパケットのブロックを非活性化するべきである旨）知らされてよい。代わりに、このケースに対処するために他のプロセスが自動的に開始されてよい。

「ビデオストリーミングサーバ」が「ダウン」している：この場合、ＲＭＩサーバはビデオストリーミングソフトウェアが実行しているかどうかをチェックし、その「ビデオストリーミングサーバ」が接続を受け入れる準備が完了している場合、あるいは完了しているとき「ＲＭＩクライアント」に知らせてよい。代わりに、ステップ４では、この「サーバ」はどの「ビデオストリーミングサーバ」が「最高」であるのかを確立するプロセスから除外されてよい。

本発明の一実施形態によるシステムを含むネットワークの構成要素パーツを示す図である。 「データプロバイダ」の残りの「アップリンク」容量の計算を示す図である。

Claims (18)

1. 複数のデータプロバイダから好ましいデータプロバイダを選択するためのシステムであって、
   クライアントからデータに対する要求を受け取るための手段と、
   前記クライアントからクライアント識別データを受け取るための手段と、
   前記クライアントにデータを提供できる複数のデータプロバイダを特定するための手段と、
   前記クライアント識別データを前記データプロバイダに提供する手段と、
   前記データプロバイダに対し、
   （ｉ）前記クライアントに試験信号を送信するステップと、
   （ｉｉ）前記クライアントから帰還信号を受信するステップと、
   （ｉｉｉ）前記試験信号の送信と前記帰還信号の受信の間の経過時間の値を取得するステップと、
   （ｉｖ）前記システムが経過時間を示す信号を使用できるようにするステップと、
   （ｖ）前記システムがその残り容量を示す信号を入手できるようにするステップと、
   を実行するように指示するための手段と、
   前記データプロバイダから経過時間信号と残り容量信号を受信するための手段と、
   前記信号に基づいて好ましいデータプロバイダを選択するための手段と、
   前記好ましいデータプロバイダのアイデンティティに関する情報を前記クライアントに提供するための手段と、
   を含む、システム。
2. 前記データに対する要求を受信するための手段は、１つ以上の特定のアイテムに対する要求を受信するための手段を含む、請求項１に記載のシステム。
3. 前記データプロバイダを特定するための手段は、要求される前記特定の１以上のアイテムを提供することができるデータプロバイダをサーチするための手段を含む、請求項２に記載のシステム。
4. 前記選択する手段は、所定の閾値を超える残り容量を有するデータプロバイダから好ましいデータプロバイダを選択するように構成される、請求項１乃至請求項３のいずれか１項に記載のシステム。
5. 前記データプロバイダに対し指示するための手段は、前記データプロバイダに、それらの残り帯域幅を示す信号を前記システムが入手できるようにするよう指示するための手段を含む、請求項１乃至請求項４のいずれか１項に記載のシステム。
6. 前記データプロバイダに指示するための手段は、クライアントから遠隔の手段である、請求項１乃至請求項５のいずれか１項に記載のシステム。
7. 前記好ましいデータプロバイダのアイデンティティに関する情報を提供するための手段は、前記情報をウェブサイトで提供するように構成される、請求項１乃至請求項６のいずれか１項に記載のシステム。
8. 前記好ましいデータプロバイダのアイデンティティに関する情報を提供するための手段は、前記好ましいデータプロバイダのユニフォームリソースロケータ（ＵＲＬ）を提供するように構成される、請求項１乃至請求項７のいずれか１項に記載のシステム。
9. 所定の基準に従って複数の好ましいデータプロバイダを選択できる手段と、それぞれの好ましいデータプロバイダのアイデンティティに関する情報を前記クライアントに提供するための手段とを含む、請求項１乃至請求項８のいずれか１項に記載のシステム。
10. 複数のデータプロバイダから好ましいデータプロバイダを選択するための方法であって、
    クライアントからデータに対する要求を受け取るステップと、
    前記クライアントからクライアント識別データを受信するステップと、
    前記クライアントにデータを提供できる複数のデータプロバイダを特定するステップと、
    前記データプロバイダに前記クライアント識別データを提供するステップと、
    前記データプロバイダに対し、
    （ｉ）前記クライアントに試験信号を送信するステップと、
    （ｉｉ）前記クライアントから帰還信号を受信するステップと、
    （ｉｉｉ）前記試験信号の送信と前記帰還信号の受信の間の経過時間の値を取得するステップと、
    （ｉｖ）前記システムが前記経過時間を示す信号を入手できるようにするステップと、
    （ｖ）前記システムがその残り容量を示す信号を入手できるようにするステップと、
    を実行するように指示するステップと、
    前記データプロバイダから経過時間信号及び残り容量信号を受信するステップと、
    前記信号に基づき好ましいデータプロバイダを選択するステップと、
    前記クライアントに前記好ましいデータプロバイダのアイデンティティに関する情報を提供するステップと、
    を含む、方法。
11. データに対する要求を受け取る前記ステップは、１つ以上の特定のアイテムに対する要求を受け取ることを含む、請求項１０に記載の方法。
12. データプロバイダを特定する前記ステップは、要求される前記特定の１つ以上のアイテムを提供できるデータプロバイダをサーチすることを含む、請求項１１に記載の方法。
13. 好ましいデータプロバイダを選択する前記ステップは、所定の閾値を超える残り容量を有するデータプロバイダから選択することを含む、請求項１０乃至請求項１２のいずれか１項に記載の方法。
14. 前記データプロバイダに対し指示する前記ステップは、前記データプロバイダに前記システムがその残り帯域幅を示す信号を入手できるように指示することを含む、請求項１０乃至請求項１３のいずれか１項に記載の方法。
15. 前記データプロバイダに指示する前記ステップは、前記クライアントから遠隔の手段により実行される、請求項１０乃至請求項１４のいずれか１項に記載の方法。
16. 前記好ましいデータプロバイダの前記アイデンティティに関する情報を提供する前記ステップは、ウェブサイトで前記情報を提供することを含む、請求項１０乃至請求項１５のいずれか１項に記載の方法。
17. 前記好ましいデータプロバイダの前記アイデンティティに関する情報を提供する前記ステップは、前記好ましいデータプロバイダのユニフォームリソースロケータ（ＵＲＬ）を提供することを含む、請求項１０乃至請求項１６のいずれか１項に記載の方法。
18. 複数の好ましいデータプロバイダが所定の基準に従って選択されてよく、それぞれの好適データプロバイダの前記アイデンティティに関する情報が前記クライアントに提供されてよい、請求項１０乃至請求項１７のいずれか１項に記載の方法。

Images