JP2002506543A - 分散型コンピュータネットワーク上のデータ配信のサーバ側最適化のためのシステムおよび方法 - Google Patents

Abstract

(57)【要約】 分散型サイトでのビデオデータの最適化されている記憶保持および検索のためのシステムおよび方法は、そのそれぞれがシステムにより管理されている一定のデータのコピーを維持する、ネットワーク全体での“スマートミラー”サイトの配備を要求する。ユーザアドレスは、利用可能な配信サイトのそれぞれに関するネットワークパフォーマンスの分析に基づいて、特定の配信サイトに割り当てられる。汎用化されているネットワークパフォーマンスデータは、追加配信サイトの選択を容易にするため、および従来のネットワークに比較して改善されたパフォーマンスの保存を確実にするために、収集、記憶される。

Description

【発明の詳細な説明】 分散型コンピュータネットワーク上のデータ配信のサーバ側最適化のためのシス テムおよび方法 本発明は、分散型データの記憶保持および検索のためのシステムおよび方法に 関し、さらに詳細には、それによりユーザが、動的でかつ分散されている多目的 ネットワーク用のネットワークパフォーマンスの情報を取得することができる、 システムおよび方法に関する。ここで、この情報は、コンピュータデータ、具体 的には、マルチメディア・コンテンツを受信するための最適な配信サイトまたは サーバを識別し、および、選択するために、使用されるものとなる。このような 配信サイトおよびサーバは、ネットワーク容量を増加し、サーバ負荷を分散し、 および、サーバとユーザの間の伝達遅延を削減するように、選択される。 発明の背景 インターネットは、世界中に広がっていて接続されているコンピュータの開放 的なネットワークである。メッセージは、宛先アドレスを指定するとともに、一 連の“ホップ”（“hops”）を介してコンピュータからコンピュータへメッセー ジを渡すことによって、インターネット上の任意のコンピュータから他の任意の コンピュータに送信することができる。インターネット上の各コンピュータ、各 ルータ、または、各“ノード”（“node”）には、ユニークなインターネットア ドレスがある。中間のコンピュータまたはルータが通過中のメッセージを受信す ると、コンピュータは、そのメッセージの意図されている宛先をチェックすると ともに、それに応じてそのメッセージを次々と回送する。 インターネットは、規模と高度化という両方の点で、急激な速度で発達してい る。過去においては、インターネットの大部分のユーザは、学術、研究もしくは 機関のユーザであった。インターネットは、その頃は、おもに、電子メールおよ びネットワークニュースを送信および受信するためと、コンピュータ・ファイル の転送を可能にするためとに使用されていた。しかし、数年前にワールドワイド ウェブ（“ウェブ”または“ＷＷＷ”としても知られている）が導入されて以来 、インターネットは、一般的に関心をよせられる、つまり画像や記事等の表現の 、他の種類のデータの量を増大させることを、ホストし始めた。 ウェブのプロトコルおよび言語は、インターネットの広々とした区域（expans es）をナビゲーションするグラフィックの手段を確立する。多くの場合、おもに テキストとグラフィックの資材から成り立っている“ウェブページ”は、インタ ーネット中にある“ウエブサーバ”として知られている多数のコンピュータに蓄 積されている。“ブラウザ”として知られているソフトウェアプログラムは、希 望されるウェブページの場所（すなわち、インターネットアドレス）を指定する ことにより、インターネットを経由してウェブページにアクセスしかつウェブペ ージを見るために使用することができる。ウェブページにアクセスすると、その 情報は、それが世界中のどこに位置していようとも、遠隔のコンピュータ（サー バまたは配信サイト）からインターネットを経由してユーザへと送信される。 最近では、ウェブは、音声データおよびビデオデータのようなきわめて高度化 されている種類のマルチメディアコンテンツとコンピュータソフトウェアとをホ ストし始めた。第１世代のウェブコンテンツ、つまりテキストおよび静上画像に 比較して、音声クリップ、ビデオクリップおよびソフトウェアプログラムは、き わめて高い記憶領域と帯域幅の要求をもっている。 現在、インターネットのマルチノードリンク上で大きな音声／ビデオファイル の高速持続伝送を提供することは、不可能ではないにしても、困難である。デー タは多くの場合遠くから転送されるため、多くの要因によって伝送の一部もしく はすべての遅延または損失さえ生じ得る。ユーザが小さいグラフィックファイル またはテキストファイルを受信する上でマイナーな遅延を体験するかどうかは、 概して重大ではない。しかし、ビデオのようなリアルタイムデータがデータの転 送および表示に非常に特殊かつ厳密なタイミング要件を有することは、認識され ている。 残念なことに、従来のインターネットに類似するデータネットワークの現在の 設計は、遅延および大きなデータ伝達速度の変動が通常のデータ（例えば、テキ ストおよび静止画像）の場合に許容できるという原則に基づいている。その結果 、世界中の場所からのテキスト情報およびグラフィック情報へのアクセスを可能 にする高い価格のために、このような伝送の欠陥は許容できると考えられ、イン ターネットの基本容量は、データ伝送コストを削減するためにいくぶん“加入超 過”（“oversubscribed”）になっている。言い換えると、ネットワークデータ 伝送の適時性（timeliness）は、長距離通信接続であることの総費用を相対的に 無意味にするために、かなり妥協されてきていた。 音声−ビデオデータをインターネットのようなメッセージ指向型ネットワーク 経由で無事に転送するためには、数人を超える任意のユーザにとって、ネットワ ークリソースが伝送の適時性を促進する形式で寄託される必要がある。寄託され ているネットワークリソースを使用するシステムは、それがデータパケット単位 によるデータパケットでのネットワークリソースの共有に参加することができな いため、通常、インターネットのような共有ネットワークの既存の価格形成方式 を利用することはできない。ビデオデータは、より低い優先順位のデータを除外 して伝送されなければならない。したがって、特に、接続が“長距離”のとき、 あるいは、延長された時間の間接続が続行されるときには、伝送コストが多大に なる。 上述した適時性対コストの折り合いの別の結果は、見た目には無差別のネット ワークの構造設計になっている。遅延およびスループット（throughput）の変動 は、従来、低コストを好んで大目に見られてきたため、インターネット・インフ ラストラクチャのコンフィギュレーションもコストの考慮によって決定されてき ていた。このため、ネットワークの相互間接続の効率は、めったに考慮されるこ とはなかった。リアルタイムデータの急激な発展がこの要求を変えつつある。 インターネット上での時間に敏感なデータの不十分なデータ転送パフォーマン スは、典型的には以下の４つの要因によって引き起こされることが認識されてい る。すなわち、パケットの損失、過剰なサーバの活用、ネットワーク・インフラ ストラクチャの相対的に低い容量、および、ネットワークハードウェアにおける 固有の遅延である。特に、パケットの損失は、不十分なインフラストラクチャお よびルーティングにおける堅固さの欠如によって引き起こされる。固有の遅延は 、とりわけ、インターネット上での多数ノード経路における隣接ノード間のフロ ー制御の欠如によって引き起こされると考えられている。 より小さいテキストファイルとグラフィックファイルとは異なり、相対的に大 きなビデオファイルは、数分間（またはそれ以上）の“ストリーム”（“stream ing”）、すなわち、絶えず続くデータフローを要することがある。その結果、 通常のネットワークパフォーマンスの問題は悪化する。ネットワーク帯域幅、す なわち、ある特定のネットワークのデータ搬送容量が制限される。このため、パ ケット損失および遅延が増加する。長い配信時間は、長期間大量のサーバ容量を 消費し、他のユーザが使用できるリソースを減少させる。したがって、ネットワ ーク・インフラストラクチャがますます輻輳するようになるので、パケット損失 と遅延は増加し続け、伝送時間は上昇し、および、サーバ負荷はさらに増大する 。 このパターンは、ビデオクリップのような大きいデータファイルの伝送の試行 によって左右され得るネットワークパフォーマンスの“連続的下降”（“downwa rd spiral”）を例示するものである。ネットワークトラフィックがネットワー ク帯域幅によって課されれている制限の範囲内に留まる限り、ネットワークパフ ォーマンスは許容可能なままになる。しかし、ピークネットワーク負荷が容量を 越えると常に、前述の連続的下降が始まり、不十分なネットワークパフォーマン スの期間を引き延ばす。 上述したように、ブラウザプログラムは、希望されているウェブページの場所 （つまり、インターネットアドレス）を指定することによって、あるいは、より 一般的には、ウェブページに“ホットリンクする”（“hotlinking”）ことによ って、インターネットを経由してウェブページにアクセスし、かつ、これを見る のに使用することができる。一般のブラウザは、Ｌｙｎｘ、ＮＣＳＡ、Mosaic、 Netscape Navigator、および、Microsoft Internet Explorerである。希望され ているウェブページは、構文“http://internet.address/directory/filename.h tml”を使用してファイルの正確な場所を示す全域資源位置指示子（“ＵＲＬ” （uniform resource locator））によつて指定される。 ウェブページは、通常、レイアウトとコンテンツという点で、“ＨＴＭＬ”（ HyperText Markup Language）として知られている言語によって記述されている 。インターネットにリンクされている特定のコンピュータは、いずれも、１つま た は２つ以上のウェブページ、すなわち、ＨＴＭＬフォーマットで書かれたコンピ ュータファイルを、ユーザによるアクセスのために記憶蓄積することができる。 あるＨＴＭＬウェブページから別のＨＴＭＬウェブページへのホットリンクは 、以下のように達成される。ユーザは、まず、多くの場合ユーザのＩＳＰ（Inte rnet Service Provider）に位置しているコンピュータ上の、既知のアドレスを 有しているウェブページにアクセスする。ＩＳＰは、ユーザにインターネット接 続性を提供している組織である。そのウェブページは、ＨＴＭＬフォーマットで 指定されているテキストのデータと視覚的なデータとに加えて、多くの場合、“ リンク”、つまりインターネット全体を通じた他のコンピュータ上の、他のウェ ブページのインターネットアドレスを指す（ＵＲＬの形をした）はめ込まれた情 報を含むことができる。それから、ユーザは、リンクを選択することによって（ 多くの場合、マウスで指し示してクリックすることによって）、他のウェブペー ジにアクセスすることができ、それらは、次々と一層のデータおよび／または追 加リンクを含み得るものとなっている。 NetscapeのＥＭＢＥＤタグのようなＨＴＭＬへの多様な拡張は、ウェブページ の中にはめ込まれる他のデータの参照を可能にする。テキストおよび創像以外の データを処理することができないブラウザもある。その一方で、多様な方法でデ ータを処理することができるブラウザもある。例えば、ＮＣＳＡのMosaicは、デ ータがユーザのコンピュータにダウンロードされるのを可能にし、かつ、その後 にデータを見てまたは操作するための外部プログラムを任意で呼び出すことによ って、既知ではない種類のデータに対する参照を取り扱う。Netscape Navigator およびMicrosoft Internet Explorerの最近のリリースにより、概念はさらに一 歩進んだ。すなわち、データがリモートウェブページから受信されると、そのデ ータを処理するためにブラウザ拡張、つまり“プラグ−イン”（“plug-in”） を、自動的に呼び出すことができる。Ｊａｖａ言語（または類似した言語）で記 述されているネットワークプログラム“アプレット”（“applets”）のような 他の手段は、ブラウザ環境またはネットワークの機能性を拡張するために使用す ることができる。 デジタルのマルチメディアデータは、きわめて高い記憶領域および帯域幅の要 求を有し得る。特に、ビデオファイルは、約１０メガバイトから１０ギガバイト と非常に大きくなる可能性がある。ユーザの端末で、それが録画された速度に近 づく速度でビデオファイルを再生するためには、ファイルは高速、不変の速度で 配信されなければならない。低速過ぎると、画像は、もとの録画されたものより ゆっくりとプレイバックされる。速度が一様ではない場合には、ビデオは、昔の 映画のようにびくびく動く（jerky）ように見える。 上述したネットワーク設計の折り合いは、通常、インターネットを経由する音 声データおよびビデオデータの伝送に悪影響を及ぼす。ウェブを“サーフ”（“ surf”）するためにブラウザを使用しているユーザは、テキストおよび静止画像 を検索している間のマイナーな遅延および伝送速度の変動に気がつかない可能性 があるが、このような欠陥は、リアルタイムの音声情報およびビデオ情報がアク セスされると明白になり、かつ、顕著になる。 これらの問題を解決する試みにおいて、インターネットコンテンツプロバイダ は、“ミラーサイト”（“mirror sites”）として知られている多様なサーバま たは配信サイト上で、インターネット中の人気のあるコンテンツを拡布すること がある。各ミラーサイトは、元のサイトの情報と本質的に同一である情報を含ん でいる。例えば、人気のあるウェブサイトがニューヨークに位置する場合、ミラ ーサイトは、ロスアンジェルス、ロンドンおよび東京に位置していてもよい。し たがって、ヨーロッパのユーザが元のニューヨークのサイトにアクセスするのが 困難な場合、そのユーザは、地理的に最も近いミラーサイト、つまりロンドンに ホットリンクすることができる。 しかしながら、ミラーサイトにはいくつかの不利な点がある。例えば、ミラー サイトは、地理的には幅広く分散していてもよいが、実際の使用量、ネットワー クトラフィック等という点ではネットワーク上で効率的に分散されていないこと がある。したがって、ニューヨークとロスアンジェルスのミラーサイトは、両方 とも、同じ国内インターネットサービスプロバイダのネットワークに接続され、 それらのサイトの一方にアクセスする上での困難さが他方にも影響を及ぼす可能 性があることを、意味することがある。 さらに、ミラーサイトは、各サーバに対する負荷を削減するために最適に配置 されていないことがある。ミラーサイトがどこに設置されるべきかに関して“知 識に基づいた推測”（“educated guess”）がなされるかもしれないが、実際の 使用量パターンは異なる可能性がある。さらに、パフォーマンスの改善の保証は ない。ミラーサイトの帯域幅は、元のサイトの帯域幅より低く、あるいは、それ が他の理由から過剰負荷の状態になっていることがある。 さらに、ミラーサイトは、多くの場合、自発的な基準によってホストされてい る。あるウェブサイトがきわめて人気かあり、かつ、主題がその加入者にとって 関心がある可能性があるとサービスプロバイダが判断すると、そのサービスプロ バイダは、元のウェブサイトのミラーサイトをホストすることに同意する可能性 がある。人々がミラーサイトに引かれ、かつ、そこでホストされている他のコン テンツにもホットリンクする可能性があるため、このような調整は、ミラーサイ トのホストにとって魅力的なものとなる。他方、このような自発的な提携は、典 型的には信頼性がなく、かつ、任意の時点で断ち切られる可能性がある。 本来、ミラーサイトは、データにとって、使用できることもあれば、使用でき ないこともあり、かつ、ユーザの利便性を改善することもあるが、ネットワーク の帯域幅または効率には取り組まない、二次的なソースを提供する。ミラーサイ トは、ネットワークのパフォーマンス特性も考慮に入れず、インターネット上の 方式のような既存の低コストの価格形成方式を依然として活用する一方で効率的 にビデオデータを伝送するために使用し得る利用可能な帯域幅も識別しない。 現在では、配信サイトのための最適な場所の選択に関するガイダンスがまった くなく、どのミラーサイトに接続するのかをユーザが判断できるようにする、最 適なパフォーマンスを保証するであろう方法も知られていない。実際、従来のミ ラーサイトの使用は自発的である。典型的には、ユーザは、元のサイト（もしく は、既知のミラーサイト）にアクセスしようと試み、１回または２回以上の試行 の後にパフォーマンスが不十分であると判明する場合にだけ、別のミラーサイト への切り替えをすることになる。このアプローチは、ネットワークリソースの非 効率的な活用である。明らかに、ミラーサイトは、過剰負荷になっているウェブ サイトの問題にとっての最適な解決策ではない。とりわけ、この主要な理由とは 、ネットワークパフォーマンスを考慮できていない点にある。 ネットワーク分析、特に、インターネット上での特定の経路およびリンクのパ フォーマンスは周知であり、かつ、開発されている。例えば、“ｐｉｎｇ”プロ グラムは、インターネットに接続されているコンピュータに対し、遠隔のホスト がアクセス可能であるかどうかを判断できるようにする。しかし、このｐｉｎｇ プログラムは、ＩＣＭＰプロトコルとして知られている低優先順位ネットワーク プロトコルを使用しており、かつ、そのために有意義なパフォーマンスの分析情 報を提供しない。“ｔｒａｃｅｒｏｕｔｅ”プログラムは、コンピュータから速 隔のホストへのメッセージの伝送を追跡し、各リンクに沿った遅延を追跡調査し 、および、該メッセージによって取られる経路を決定する。このｔｒａｃｅｒｏ ｕｔｅアプリケーションは、データの流れをマッピングするのに使用できる。た だし、それには、有意義なパフォーマンスの分析情報を提供する能力が欠けてい る。Ｔｒａｃｅｒｏｕｔｅは、ある方向で伝搬するメッセージに関するルート情 報を提供するだけであり、かつ、時間的にある一瞬に関してだけ提供する。 さらに、テストを実行中の単一のコンピュータに続く経路とそれから続く経路 の接続性特性だけは、典型的に決定される。テストの範囲を拡大することば可能 であるが、インターネットは非常に大規模であるため、論理学的には実行不可能 である。 “ｐｉｎｇ”プログラムおよび“ｔｒａｃｅｒｏｕｔｅ”プログラムのような 従来のネットワーク分析技術は、ネットワーク接続性という観点を提供するが、 プロバイダとインターネットを経由するミラーサイトからどのようなパフォーマ ンスを期待できるかについての理解はほとんど提供しない。したがって、配信サ イトまたはミラーサイトがどこに位置すべきなのか、あるいは、パフォーマンス を最適化するためにはどのミラーサイトを使用すべきなのかに関しては、「推測 」だけを行うことができるに過ぎない。 したがって、総合的なネットワークパフォーマンスを判断する方法に対するニ ーズが存在する。コンテンツプロバイダが最適なネットワークの位置にデータ配 信またはミラーサイトを動的に配置することができるようにし、かつ、ユーザが データを受信すべき最適なミラーサイトを選択するのを許容する、その方法を適 用するシステムにとってはさらに別のニーズが存在する。 発明の要約 本発明は、インターネット中に位置しているサイトへのウェブコンテンツの最 適化された分散のためのシステムおよび方法を目的としている。ここで、“スマ ートミラー化”（“Smart Mirroring”)と呼ばれているインテリジェント・ミラ ー化方式は、ミラーサイトに対するニーズおよびその分散を判断するとともに、 一定のウェブコンテンツに対するユーザの要求を最適なミラーサイトに向けるた めに使用される。 多くの“スマート”（“Smart”）な配信サイトまたはミラーサイトは、人気 のあるウェブコンテンツをインターネットの多様な部分に分散するために使用さ れる。多数のユーザによって実行されているテストに基づいたネットワーク分析 の包括的な方式が、サイトに好ましい位置（locations）を対話的に決定し、か つ、各個別のユーザによって使用される最適なサイトを決定するために、使用さ れる。 したがって、各個別のユーザが改善されたパフォーマンスを提供するスマート ミラーまたは配信サイトヘルーティングされるため、総合的なネットワークの輻 幀は削減される。大部分のケースでは、データがその上を移動しなければならな いネットワーク接続の数を減少させ、それによりパケット損失および遅延を削減 するために、改良されたサーバがユーザに電子的に近くに配置される。 さらに、ネットワーク分析の結果により、メッセージのトラフィックを、すで に過剰負荷になっているそれらの配信サイトおよびネットワーク領域から遠ざけ 、かつ、十分に利用されていないサーバおよびネットワークに向けてルーティン グすることができるようにする。このため、各ユーザによって理解されるように スループット（throughput）における改善がなされ、かつ、それによって該シス テムを使用しているコンテンツプロバイダにより提供されているコンテンツの魅 力が増すことになる。コンテンツプロバイダは、パフォーマンスにおける顕著な 低下を被ることなく、インターネットを経由してより多数のユーザに到達するこ とができる。 本発明によるシステムは、元のウェブサイトおよび少なくとも１つの追加配信 （またはミラー）サイトで始まる。このシステムの使用を希望している各ユーザ には、好ましい実施の形態においては、コンフィギュレーション・ユーティリテ ィおよびクライアント・プログラムを含むソフトウェアが与えられることになる 。そのコンフィギュレーション・ユーティリティは、まず、どの配信サイトがそ の特定のユーザにとって改善されたパフォーマンスを提供するのかを判断するた めに使用される。 本発明の一実施形態においては、コンフィギュレーション・ユーティリティは 、最初に、サービスプロバイダから“配信サイトファイル”（“delivery site file”）をダウンロードする。この配信サイトファイルには、利用可能な配信サ イトのリストおよび実行されるネットワークテストのリストが含まれている。テ ストの種類および実行されるテストの頻度は、ネットワークをテストしているユ ーザの数およびネットワーク上での概算流出もしくは配信システム容量に応じる ように、該配信サイトファイルにおいて指定することとしてもよい。 コンフィギュレーション・ユーティリティは、該配信サイトファイルにおいて 指定されているテストのサブセットを実行することになる。テストの結果は、ど の配信サイトがユーザにとって改善されたパフォーマンスを生み出すのかを示す とともに、テストを実行しているユーザの観点からの多様な汎用化されたネット ワークの性能に関する情報をも含んでいる。ネットワークのテスト結果および選 ばれた配信サイトの識別情報は、（１つの可能なコンフィギュレーションにおい てはｅメールによって）サービスプロバイダのデータベースの中に取り込むため に配信サービスプロバイダへ送り返されることになる。 その後、コンフィギュレーション・ユーティリティによって選ばれた配信サイ トは、配信システムのサービスプロバイダが管理しているすべてのコンテンツの 検索のために、そのユーザによって使用される。その結果、ユーザがウェブコン テンツをブラウザして、そして、サービスプロバイダの配信システムによって管 理されている特定のアイテム、例えばビデオクリップを見つけると、クライアン ト・ソフトウェアは、自動的に、指定されている“スマートミラー”配信サイト からそれを検索する。サイトの優先およびデフォルトのサイトは、要求に応じて 定期的に、指定されたときに、または、ネットワークの負荷およびトラフィック における変化に応答して、アップデートすることができる。 さらに、本発明のコンフィギュレーション・ユーティリティは、多様なネット ワークテストを実行し、かつ、サービスプロバイダにそのテストの結果を提供し ているため、システムおよびネットワークのパフォーマンスに関する貴重なデー タを入手することができる。このようなデータは、どの“スマートミラー”配信 サイトが効果的に実行していてどの“スマートミラー”配信サイトが効果的に実 行していないのか、どのスマートミラー配信サイトが過剰負荷になっているのか 、および、インターネットのどの部分がさらに多くの配信サイトまたは容量の追 加から利益を得る可能性かあるのか、に関する情報を提供する。このようなデー タは、また、エンド−ツー−エンド（end-to-end）のパフォーマンスの測定、処 理量の特徴化、ルートの安定性および動作不能状態の測定基準のような高度なネ ットワーク分析の実行をも可能にする。 本発明の実施の形態においては、ミラーサービスプロバイダは、インターネッ トＩＰアドレスを“電子的に近い”（“electronically close”）配信サイトに 相関付けるルックアップテーブルを運営するために、エンドユーザによって提供 されているネットワークパフォーマンスのデータを使用する。ユーザがウェブペ ージをブラウジングしつつ、例えば、サービスプロバイダの配信システムによっ て管理されている広告の見出しまたはビデオクリップなどのファイルを要求する と、サービスプロバイダは、そのユーザのＩＰアドレスをそのルックアップテー ブルにマッピングし、かつ、どの配信サイトがそのユーザにとって“電子的に近 い”のかを判断することができる。サービスプロバイダは、その後、ユーザのコ ンフィギュレーション・ユーティリティまたはクライアント・プログラムに対し 、単一の配信サイトアドレスまたはこれらのサーバへの配信サイトアドレスのリ ストを提供することができる。後者の場合、ユーザ端末は、最終的な配信サイト 選択を行うルータとして動作する。 一般的には、ある特定のユーザにとって改善された配信サイトは、一群のユー ザによって以前に実行されたネットワークのテストから収集されたネットワーク パフォーマンスの総合データを分析することにより、事前に予測することができ る。したがって、配信サイトの選択は、ユーザがミラーサービスプロバイダの配 信システムによって管理されているファイルを要求するたびに、実行中（on-the -fly）に起こる可能性がある。ユーザの観点からは、配信サイトの選択は、ウェ ブページからファイルを選択することとユーザの端末へ配信されたファイルを所 有することとの間にまったく遅延がないものと見えるように、自動的にかつ透明 的（transparently）に行われる。サーピスプロバイダによって維持されている ルックアップリストは絶えずアップデートされてネットワークパフォーマンスに おける変化を反映し、サービスプロバイダがネットワークトラフィックの負荷配 分を効率的に行うことを可能にする。 このようにして、工学技術的な観点から、ミラーサービスプロバイダは、改善 されたパフォーマンスが提供されていることを保証し続けることができる。マー ケティングの観点からは、コンテンツプロバイダに対し、パフォーマンスの改善 のためにスマートミラーまたは配信サイトをどこに配置するべきなのか、および 、どのＩＳＰが改善された配信を実現するのか、を告げることができる。 図面の簡単な説明 図１は、多種多様なユーザおよび多種多様なコンテンツプロバイダを含む本発 明によるシステムの例示的なネットワークトポロジのブロックダイヤグラムであ る。 図２は、本発明によるシステムにおいて使用されるコンフィギュレーション・ ユーティリティの動作を説明するフローチャートである。 図３は、本発明によるシステムにおいて使用されるクライアント・プログラム の動作を説明するフローチャートである。 図４は、サイト選択が本発明の実施の形態においてどのように実行されるのか を示すフローチャートである。 発明の詳細な説明 本発明は、詳説されている例示的な実施の形態に関して以下に説明される。本 発明が多岐に渡る種々の形式で実現できることは明白であり、そのいくつかは、 開示されている実施の形態の形式とはきわめて異なるものであってもよい。従っ て、ここに開示されている特定の構造上および機能上の詳細は、単に代表的なも のにすぎず、かつ、本発明の範囲を制限しない。 最初に図１を参照すると、インターネット１０が“クラウド”（“cloud”） として描かれている。このインターネット１０は、一般的な広域通信ネットワー クを表すことを意図したものである。インターネットは、多数のコンピュータの 相互接続されたネットワークとして知られている。互いに“地理的に”（“geog raphically”）近いインターネット接続されたコンピュータかインターネット上 で互いに“電子的に”（“electronically”）近いこともあり得るが、このよう なことは通常のケースではない。しかし、インターネットに接続されているある コンピュータが、インターネットに接続されている任意の他のコンピュータと通 信することはできる。つまり、メッセージは、直接的に互いに接続されているコ ンピュータ間で、リンクのシーケンスまたは“ホップ”（“hops”）を含む経路 上をほぼ確実に移動することになる。 第１ユーザ端末１２も図１に描かれている。第１ユーザ端末１２は、典型的に はただのコンピュータ、ルータ、または、インターネット１０に接続されている 端末サーバであるインターネットサービスプロバイダ（ＩＳＰ（Internet servi ce provider））１４に接続されている。ＩＳＰ１４は、第２ユーザ端末１６の ような追加のユーザ端末をホストすることができる。第２ＩＳＰ１８のような他 のＩＳＰもまた、インターネット１０に接続されている。第３ユーザ端末２０は 、第２ＩＳＰ１８に接続されて図示されている。３つのユーザ端末しか示されて いないが、本発明の並行ユーザの数は後述の実用可能な詳細を条件として無制限 であることを注記する。 この技術分野で公知であるように、コンテンツプロバイダもまたインターネッ ト１０に接続されている。第１コンテンツプロバイダ２２は、ある一定の種類の コンテンツ、例えばスポーツのスコアとハイライトを提供するものでもよい。第 ２のコンテンツプロバイダ２４は、他の種類のコンテンツ、例えばビジネスニュ ースを提供するものでもよい。 従来、（第１ユーザ端末１２を使用しているユーザのような）ユーザが第１コ ンテンツプロバイダ２２によって提供されているコンテンツにアクセスすること を希望すると、端末１２は、第１コンテンツプロバイダ２２を直接問い合わせる ことになる。要求メッセージは、端末１２からインターネット１０を経由してコ ンテンツプロバイダ２２へと伝搬することになる。コンテンツプロバイダ２２は 、インターネット１０を経由して端末１２へ希望されているデータを送り返すこ とになる。 図１では、いくつかの配信または“ミラー”（“mirror”）サイトが、インタ ーネット１０に接続されて示されている。第１配信サイト２６は、第１ユーザ端 末１２からの少数の“ホップ”を配置されてもよい。第２配信サイト２８は、第 １ユーザ端末１２からさらに遠く離れて配置されていてもよいが、第３ユーザ端 末２０の近くに位置していてもよい。第３配信サイト３０は、第２配信サイト２ ８が第３ユーザ端末２０に近いのと同程度に第３ユーザ端末２０の近くにあって もよい。前記したように、“地理的に”互いに近いユーザおよびプロバイダもし くは配信サイトは、インターネット上で“電子的に”互いに近くないことがある 。ユーザとプロバイダまたは配信サイトとの間の“電子的な”（“electronic” ）距離を減なくすることによって、その上をデータが移動しなければならないネ ットワーク接続およびルータの数は、減少させることができる。 上述したように、スマートミラー化システムは、上記ネットワークの問題の発 生率を減少させることによって、ネットワークパフォーマンスを改善する役割を 果す。いくつかのケースでは、本発明のネットワークのテスト手順は、さらに長 い経路の方がより短い経路より優れたスループット（throughput）を提供するこ とがあることを示すが、パケット損失および遅延の問題は、一般的には、データ がその上を移動しなければならないネットワーク接続の数を削減することによっ て軽減される。ネットワークのケーブルにおいては、パケット損失はほとんど発 生せず、かつ、本来遅延はまったく生じない。したがって、典型的には、それは 過剰負荷になっているネットワークの記憶装置とルーティング装置とによって引 き起こされている。本発明のスマートミラーサイトは、各ユーザに電子的に近く に位置しているため、パケット損失および遅延は削減される。過剰なサーバ活用 の問題は、多種多様な配信サイトが典型的には単一サーバによって処理されてい たであろう負荷を共用するので、削減される。別々の場所にあるパラレルの配信 サイトから検索されるデータが通常同じネットワークリンク上を移動する必要が ないため、ネットワーク・インフラストラクチャの相対的に低い容量は、より問 題になりにくい。 この発明を説明するため、配信サイトは、配信のためにソフトウェアコードの ようなデータまたはその他のファイルを記憶することもできるネットワーク上の “ノード”（“node”）であるものとする。この用語は、また、ミラーサイト、 コンテンツプロバイダおよびビデオストリームもしくはウェブサイトの一斉送信 （broadcast）用サーバを含む、データ配信に対応することができるサイトを含 み得る。 システムでは、ミラーサービスプロバイダ（ＭＳＰ（mirror service provide r））３２が、インターネット１０に接続されている。配信サイト２６、２８お よび３０の分散と、ユーザ端末１２、１６および２０からの元のサイトおよび配 信サイトへの要求の割当とで、管理機能を実行するＭＳＰ３２は、インターネッ ト１０上でデータを送信しかつ受信することができるデータベースを含む。 この管理機能は、ユーザ端末１２上の記憶媒体（つまり、ランダムアクセスメ モリ）内で実行されるコンフィギュレーション・ユーティリティ３４およびクラ イアント・プログラム３６の使用によって容易にされる。コンフィギュレーショ ン・ユーティリティ３４およびクライアント・プログラム３６は、第１ユーザ端 末１２だけの一部として図１に示されているが、端末１６および２０のようなこ のシステムに加入している任意のユーザ端末がこのようなソフトウェアを使用す ることになると認識すべきであることを注記する。このシステムに加入すること を希望するユーザは、コンフィギュレーション・ユーティリティ３４およびクラ イアント・プログラム３６を含むソフトウェアを、ＭＳＰ３２から直接的に、あ るいは、従来の小売経路、もしくは（コンピュータのブラウザもしくはオペレー ティングシステムの一部であるような）他の経路を通して入手することができる 。この本発明が説明されている実施の形態においてコンフィギュレーション・ユ ーティリティ３４によって実行される機能は、ブラウザまたはその他のネットワ ークアプリケーションのような一般的なインターネットアプリケーションソフト ウェアの中に統合することができることを注記する。スタンド−アロン・プログ ラムは必要ではない。 好ましい実施の形態においては、コンフィギュレーション・ユーティリティ３ ４は、ユーザ端末１２がシステムへのアクセスを得る前に、コマンドによってか 、または、自動的かによって、ユーザにより実行されなければならない。コンフ ィギュレーション・ユーティリティ３４の動作は、図２に詳細に示されている。 コンフィギュレーション・ユーティリティ３４は、最初にユーザ端末１２上で 実行されるとき、ＭＳＰ３２（図１）から配信サイトファイルを検索する（ステ ップ４０）。ユーザがすでに配信サイトファイルを持っており（例えば、それが コンフィギュレーション・ユーティリティ３４を使って受け取られ）、かつ、そ の配信サイトファイルが十分に新しい場合、配信サイトファイルは、ユーザ端末 １２のローカルハードディスクから検索することができる。この配信サイトファ イルには、（配信サイト２６、２８および３０のような）すべての利用可能な配 信サイトのリストと、ユーザ端末１２で実行されるネットワークのテストのリス トとが含まれている。本発明のコンテキストでは、２つほど少ない配信サイト、 あるいは、ユーザの数がそれを正当化する場合には数千ほど多い配信サイトがあ り得る。原則的にはサイト数は無制限であり、それぞれの利用可能な配信サイト が配信サイトファイルに表されている。 配信サイトファイルは、ＭＳＰのコンピュータシステム内からデータベースに よって作成される。データベースのアプリケーションは、ユーザについての情報 を使用し、実行すべき最適なテストを動的に決定する。その結果、配信サイトフ ァイルは、存在するあらゆる配信サイトに対するエントリを含む必要はない。つ まり、そのリストは、適切または実行可能と考えられるサイトだけを含むように 調整することができる。 当初、配信システムのユーザ用のテスト・コンフィギュレーションにおける実 行時間の変動の規模は低い。つまり、ユーザの第１グループは、すべて本質的に は同じテストを実行する。しかしながら、配信サービスが発達するにつれて、各 ユーザのテストの激しさは、ネットワーク全体でテストする規模の増加を埋め合 わせるために削減される。テストの範囲およびテストされる配信サイトの数は、 両方とも、ネットワークテストの総計負荷をさらに削減するために狭めることが できる。 ある実施の形態においては、配信サイトファイルは、一般的に以下のようなフ ォーマットを有するものとなる。 １．ファイル改訂番号およびメッセージ。ファイルは、コンフィギュレーショ ン・ユーティリティ３４の新しいバージョンが利用できるかどうかを判断するた めに、このフィールドを有する。配信サイトファイルの改訂番号がコンフィギュ レーション・ユーティリティのためのバージョン番号より高い場合、コンフィギ ュレーションは許容されていない。代わりに、ユーザは、コンフィギュレーショ ン・ユーティリティ３４のさらに新しいバージョンを取得するようにプロンプト を出されることになる。ここに説明されているようなファイル改訂の検証は、も っともアップ−トウ−デートな配信サイト選択アルゴリズムがコンフィギュレー ション・ユーティリティ３４によって生成されているテストデータに適用される ことを保証する。 ２．利用可能なスマートミラー配信サイトのリスト。それぞれの利用可能な配 信サイトに関し、以下の情報が提供される。 ａ．ホスト名。“www.server.com”という公知のインターネットフォーマッ トによる。 ｂ．ＩＰアドレス。公知のフォーマットでの数値のインターネットアドレス 。このアドレスは、現在では、w.x.y.zという形の３２ビットの数値であり、こ の場合、ｗ、ｘ、ｙおよびｚは、それぞれ０から２５５の範囲内にある。 ｃ．代替名。“第１ミラーサイト”のような非公式の名称。 ｄ．実行されるテストのリスト。それぞれのテストに対し、以下の情報が提 供される。 ｉ．テストＩＤ。各種テストは、コンフィギュレーション・ユーティリテ ィ３４に既知であるユニークな識別子を有している。 ｉｉ．重み付けファクタ。各テストは、指定されたパーセンテージ分だけ 、重み付けされることになる。 ｉｉｉ．頻度。各テストは必ずしも毎回実行される必要はない。このフィ ールドは、どの程度頻繁にある特定のテストが実行されるのかを求める確率を指 定する。 ｉｖ．追加情報（オプション）。ある一定のテストに対し、追加情報が必 要とされることとしてもよい。 ｅ．サイト優先レベル。各サイトには、例えば１と１００の間の重み付け、 つまり優先レベルを与えることができる。後述するように、ＭＳＰのデータベー ス内の総計データは、単一ユーザの瞬間的なエンド−ツー−エンドのテストだけ では可能ではないネットワーク使用の分析を実行するために使用される。ここで 規定されている重み付けファクタは、サービスプロバイダのデータベースから受 け取られるテスト結果をを取り入れるために使用される。いったん所定の最大使 用レベルに到達すると、この重み付けファクタは、また、新規ユーザの配信サイ トへの割当を制限するためにも使用される。 ｆ．テストサイトのフラグ。このフラグがイネーブルされると、前記テスト が実行されるが、サイトは、たとえそれが最良のパフォーマンスを生じさせると しても、配信サイトとして割り当てられないことになる。 ｇ．コンテンツプロバイダのグループ。各サイトは、１つまたは２つ以上の コンテンツプロバイダグループに属し、それによって一定のコンテンツだけをミ ラー化することができる。ユーザがある特定の配信サイトによってホストされて いるデータの種類に関心がない場合には、それがテストされる必要はない。 コンフィギュレーション・ユーティリティ３４は、その後、例えば、ユーザの 氏名、ｅメールのアドレス、パスワード、モデム速度、および、アクセス制御に 関係する情報（例えば、該ユーザが多様な属性のどのレベルを見ることができる のか）などのコンフィギュレーション・プロセスにおいて必要とされる情報の多 様な項目に関して、ユーザに問い合わせる（ステップ４２）。アクセス制御メカ ニズムは、以下により詳細に説明することにする。本発明の一実施形態において は、ユーザから受け取られる情報は、暗号化され、かつユーザ端末１２上のコン フィギュレーション・ファイル内に記憶されている。 それから、コンフィギュレーション・ユーティリティ３４は、ユーザ端末１２ が、インターネットに接続しているかどうか判断する（ステップ４２）。接続し ていない場合、それは接続を始動し（ステップ４４）、または、ユーザにそれを 行うようにプロンプトを出す。 それから、一連のネットワークテストが実行される（ステップ４６）。配信サ イトファイルに一覧表記されている利用可能なサイトごとに、１回または２回以 上のテストを実行することができる。ファイル内のすべてのサイトがテストされ る必要はない。 以下のテストの種類は、現在、有効なデータを提供すると考えられている。 １．Ｐｉｎｇ。遠隔のサーバが到達可能であるのかどうか、および、到達可能 である場合、低優先順位のメッセージがユーザ端末１２からその遠隔のサーバへ の往復を移動するのにどの程度の時間を要するのか、に関する情報を提供する。 ｐｉｎｇは、サイトが追加評価に使用できるのかどうかを決める上で有効な簡易 テストである。ｐｉｎｇアプリケーションによって戻される過剰時間は、効果的 な情報の配信には“低速”すぎる配信システムを排除するために使用することが できる。このテストは、テストされている配信サイトの数を削減するために端末 によって使用される。 ２．Ｔｒａｃｅｒｏｕｔｅ。途中でどのシステムが使用されるのかと各ホップ にどのくらいの時間を要するのかとを含む、ユーザ端末１２から遠隔のサーバま でにメッセージがどのルートを取るのかに関する情報を、提供する。Ｔｒａｃｅ ｒｏｕｔｅは、情報伝達の経路を文書化するために、コンフィギュレーション・ プログラム３４によって使用される。結果が異なるいくつかのトレースが、ある 特定のユーザから特殊なサーバまでのルートの安定性が許容できないことを示す 場合がある。サービスプロバイダのシステムデータベースからの、特定のルート に関して以前に総計されたデータもまた、特殊なユーザ向けの特定の配信サイト を選択するための決定に影響を及ぼすことがある。ルートの安定性は、主要な考 慮事項である。 ３．逆Ｔｒａｃｅｒｏｕｔｅ。途中でどのシステムが使用されるのかと各ホッ プにどのくらい時間を要するのかとを含む、遠隔のサーバからユーザ端末までに メッセージがどのルートを取るのかに関する情報を提供する。逆Ｔｒａｃｅｒｏ ｕｔｅは、情報受取りの経路を文書化するために、コンフィギュレーション・プ ログラムによって使用される。結果が異なるいくつかのトレースが、ある特定の サーバから特殊なユーザまでのルートの安定性が許容できないことを示す場合が ある。サービスプロバイダのシステムデータベースから特定のルートに関して以 前に総計されたデータもまた、特殊なユーザ向けの特定の配信サイトを選択する ための決定に影響を及ぼすことがある。再び、ルートの安定性は主要な考慮事項 である。 ４．動的Ｔｒａｃｅｒｏｕｔｅ。ｔｒａｃｅｒｏｕｔｅまたは逆ｔｒａｃｅｒ ｏｕｔｅに同様であるが、インターネット上の任意の指定されたコンピュータの 対の間。動的Ｔｒａｃｅｒｏｕｔｅは、情報伝達の経路を文書化するためにコン フィギュレーション・プログラムによって使用される。結果が異なるいくつかの トレースが、２つのネットワークの位置間のルートの安定性が許容できないこと を示すことがある。サービスプロバイダのシステムデータベースから、特定のル ートに関して以前に総計されたデータもまた、特殊なユーザ向けの特定の配信サ イトを選択するための決定に影響を及ぼすことがある。上述のように、ルートの 安定性は、主要な考慮事項である。 ５．ネームサーバ解像度遅延（Name Server Resolution Delay）。数値インタ ーネットアドレスが未指定である場合、ネームサーバのルックアップが実行され 、どの数値アドレスが希望されているホスト名に相当するのかを判断する。この プロセスは、かなりの量の時間を要する場合がある。 ６．スループット（Throughput）。サンプルファイルは、遠隔のサーバからダ ウンロードされるか、または、部分的にダウンロードされ、毎秒バイト単位で実 際のスループットを求める。 ７．スループット変動（Throughput variation）。サンプルファイルは、遠隔 のサーバからダウンロードされるか、または、部分的にダウンロードされ、スル ープットが相対的に不変であるのか、または、浮動しているのかを判断する。 ８．誤り率。サンプルファイルは、遠隔のサーバからダウンロードされるか、 または、部分的にダウンロードされ、伝送が伝送誤差を受けるかどうかを判断す る。この情報は、ユーザに戻されるエラーメッセージパケットの数を数えること によって得られ、それによってユーザからサーバへの誤り率を習得し、および、 転送されたバイト数の分数として受信されたバイト数を追跡調査し、それによっ てサーバからユーザへの誤り率を習得する。 ９．パケット断片化（PacketFragmentation）。サンプルファイルは、遠隔の サーバからダウンロードされるか、または、部分的にダウンロードされ、伝送が 、断片化または故障しているパケットの受信にさらされるかどうかを判断する。 １０．容量問い合わせ（Capacity Query）。遠隔のサーバがこのように作動さ れている場合、コンフィギュレーション・ユーティリティ３４は、その伝送容量 およびその平均負荷を求めるためにサーバに問い合わせる。この情報は、ほぼす べてのインターネットサーバによってサポートされている簡易ネットワーク管理 プロトコル（“ＳＮＭＰ”（Simple Network Management Protocol））を介して 収集される。 １１．巨視的ネットワーク分析（Macroscopic Network Analysis）。ＭＳＰデ ータベースによって蓄積されているデータは、ネットワーク動作の大局的なビュ ーを提供する。この情報により、スマートミラーシステムのユーザは、利用可能 な配信サイトのパフォーマンスの履歴的な表示を見ることができる。該蓄積デー タは、すでにパフォーマンスの衰えを経験している領域での使用の重視をやめる 一方で、ネットワークの高容量領域での使用を重視する目的でネットワークパフ ォーマンスを分析するために、配信システムのデータベースにより操作される。 前記テストのそれぞれがどのように実行されるのかに関する情報は、ネットワ ーク分析の技術分野では周知である。例えば、Bob QuinnおよびDave Shuteのウ ィンドウズ・ソケット・ネットワーク・プログラミング （Windows Sockets Netw ork Programming）（アディソン−ウェズレイ（Addison-Wesley）、１９９６年 ）を参照のこと。本発明の一実施形態においては、テストは、サーバが到達可能 であるかどうかを検証するための“ｐｉｎｇ”テスト、一連の小さい（例えば、 ２０Ｋ）ダウンロード、一連の大きい（例えば、２００Ｋ）ダウンロード、およ び、配信経路を文書化するための“ｔｒａｃｅｒｏｕｔｅ”テストと“逆ｔｒａ ｃｅｒｏｕｔｅ”テストを実行することによって達成される。 ｔｒａｃｅｒｏｕｔｅ情報は、テストデータをそのデータベースにおける情報 に相関付けるためにＭＳＰ３２によって使用される。そのようにして、特に不良 なネットワークリンクおよびサーバが識別できる。このような情報は、前述した 配信サイトファイルに提供される。ある特定のリンクまたはサーバが信頼できな いことが分かっている場合、他のユーザから得られた情報に基づいて、個々のユ ーザは、たとえ単一のテストが良好な結果を出したとしても、それから離れてル ーティングされるものとすることができる。 短いダウンロードは、サーバ容量を求めるために使用される。ネームサーバ解 像度遅延は、データ送信を開始するために要する時間と同様に、、このようなテ ストによって決定することができる。もっと後の結果は、サーバ負荷、容量およ びパフォーマンスに強く関係している。 長いダウンロードによって、コンフィギュレーション・ユーティリティ３４は 、パケット損失、ネットワーク輻輳およびサーバ活用がどのようにファイル配信 に影響を与えるのかを判断できることになる。単一ユーザからのテストの結果に 基づき、前記ファクタのどれがパフォーマンスの低下を引き起こしているのかを 判断するのは理想的ではない。ただし、ＭＳＰ３２によって維持されているデー タベースに記憶されているような総計中のこのような結果が、根本的な原因を示 す。 テスト結果のいくつかが、それ以外のテスト結果とともに使用されてもよいこ とに注意する必要がある。例えば、容量問い合わせを通して決定される配信サイ トに対する負荷は、サーバの負荷特性を仮定すると、平均予想ダウンロード時間 を引き出すために、スループットテストの結果によって分割される。 すべての指定されたテストが実行された後、結果が収集され、かつ、処理され る（ステップ４８）。一定のテストが無事に実行できなかったと考えることは可 能である。このようなケースでは、結果は、適切な最悪ケースの値（例えば、ゼ ロ・スループットまたはきわめて大きい遅延）を示すはずである。 コンフィギュレーション・ユーティリティ３４が実行されるたびに、可能なす べてのテストが実行されるわけではないことに注意することが重要である。多数 のユーザがシステムを使用しているとき、テスト手順だけによっても、サーバと ネットワーク容量の多大な流出が生じ、前述したネットワークパフォーマンスの 連続的下降を増大することになる。 上述したように、テストの頻度数は、テストを実行しているユーザの数を動的 に制御する目的で、配信サイトファイル内に記憶される。コンフィギュレーショ ン・ユーティリティ３４によって実行されるテストは、どの配信サイトがある特 定のユーザへのデータの配信にもっともよく適しているのかを決定する上で統計 的な信頼を達成するために実行される。統計的な信頼は、ユーザの小さいサンプ ルを十分によく試験し、かつ、そのデータを配信サイトの選択肢に影響を及ぼす ために使用することによってか、あるいは、多数のユーザにいくつかの利用可能 なサイトをそれぞれ“軽く”（“lightly”）テストさせ、そのデータを総計の 中で使用することによって、得られる。 したがって、システムが最初に使用されるとき、相対的に小さい数のユーザが システムに“登録”される（enrolled）。ＭＳＰ３２によって維持されている配 信サイトファイルは、それらの条件を反映し、かつ、各ユーザに、相対的に激し く（コンフィギュレーション・ユーティリティ３４を通して）ネットワークをテ ストすることを要求する。ユーザ数が増加するに従い、配信サイトファイルは、 各ユーザによって実行されるテストを軽減するために修正される。非常に多数の ユーザがシステムを使用する時までは、コンフィギュレーション・ユーティリテ ィ３４は、大部分は（上述したように、“ｐｉｎｇ”型（“ping”-type）のテ ストによって）配信サイトの到達性に関し試験するとともに、おもに他のユーザ によって提供されかつＭＳＰ３２によって維持されているデータベースに記憶さ れているテストデータを信頼する。ただし、多くのユーザがシステムをテストし ている時でも、少数のユーザ（例えば、５０００分の１）がテストの包括的なセ ットを実行するために選択されてよい。 好ましくは、テストは、総サーバ負荷の約５%を超えて寄与してはならない。 この目標に到達するための1つの方法が、多数のサーバを軽く（lightly）テスト し、適切なパフォーマンスを有する配信サイトのグループを生じさせることであ る。すると、この配信サイトのグループは、データを検索するためのローテーシ ョンで使用することができる。グループ内の配信サイトのそれぞれのためのマル チメディア・クリップの実際のダウンロード時間に関する情報は、後述するよう に蓄積され、その後、配信サイトパフォーマンスに関する追加情報は、追加の即 座テストを必要としなくても、透明的（transparently）にＭＳＰ３２へ供給す るこ とができる。 これにより、収集されたテスト結果およびＭＳＰ３２によって配信サイトファ イルの中に提供された情報に基づき、コンフィギュレーション・ユーティリティ ３４は、どの配信サイトまたは配!信サイトのグループがユーザ端末１２にとっ て最良であるのかを決定する（ステップ５０）。この決定は、実行される多用な 試験を重み付けし、かつ、サイトごとにスコアを比較することによって、数値的 に下すことができる。 好ましい本実施形態においては、配信サイトおよびユーザの数が比較的に少数 である低トラフィック（low-traffic）環境で使用するために、コンフィギュレ ーション・ユーティリティ３４は、おもに、利用可能な配信サイトごとのｐｉｎ ｇテストおよびスループットテストに頼る。初期のｐｉｎｇテストは、配信サイ トが到達可能であるかどうかを判断するために実行される。短いダウンロードお よび長いダウンロードが、スループットテストで実行され、配信サイトからの最 大スループットおよび最小スループットを求め、および、スループット変動がビ デオデータの伝送に対処できるほど十分に小さいかどうかを判断する。したがっ て、それらのテストにはすべて高い重みが与えられている。ｔｒａｃｅｒｏｕｔ ｅのような他のテストを実行することができ、かつ、その結果は、配信サイトの 選択で役割を果さないでＭＳＰ３２に報告することができる（このような他のテ ストには、例えば、ゼロまたはほぼゼロの重みを与えることができる）。システ ムのサイズが大きくなるとともに、追加の配信サイトおよびユーザが登録される に従って、変化を遂げるネットワーク状態を反映するために、サイトの選択方式 を、配信サイトファイルのコンテンツを変更することによって変えることができ る。 本発明の一実施形態においては、ユーザの位置とテストされている各サイトの （地理的および電子的の両方の）位置がユーザ端末１２に接続されているモニタ 上に表示できるように、所有権のグラフィックインタフェースが提供され、サイ ト間の相対的な距離の視覚的な表示を可能にする。一実施形態においては、その ディスプレイは、その上でユーザ端末１２と配信サイトが関連する地理的な地域 のマップ上に重畳されている“ブリップ”（“blips”）として表示される“レ ー ダー・スクリーン”（“radar screen”）の形で示されている。ユーザに、アプ リケーションを使用し、かつ、さらにネットワーク全体のデータを提供するよう に促すために、ユーザインタフェースは、ユーザが追加のパフォーマンステスト 用の“暫定”（“ad-hoc”）テストサイトを入力できるようにする。このケース では、コンフィギュレーション・ユーティリティは、デフォルトのウェブページ ファイル（例えば“index.html”）またはユーザによって要求されている特殊な ファイルのどちらかをテストすることになる。ユーザによって選択されているサ イトからの分析結果は、その他のサイトからの結果との妥当な比較を行うことが できるように調整される。 コンテンツプロバイダの複数のグループに対応するために、配信サイトの多種 多様なセットを本発明によって維持できることに注意する必要がある。各コンテ ンツプロバイダは、一定のサイトだけでミラー化されることとしてもよい。した がって、配信サイトのユニークなセットを有するコンテンツプロバイダごとに、 一次配信ファイルがコンフィギュレーション・ユーティリティ３４によって選択 される。これを達成するために、前記テストを一度実行することができ、その後 、一実施形態においては、数値重みを配信サイトのそれぞれの適切なセットに適 用することができる。コンテンツプロバイダのグループごとに１つ、複数のスマ ートミラーサイトが選択される。コンテンツプロバイダのグループは、配信サイ トファイルにおいて指定される。それぞれの考えられる配信サイトは、１つまた は２つ以上のコンテンツプロバイダグループに属しているとして識別される。コ ンテンツプロバイダグループが使用されるとき、２つのグループしかないことが ある。最大数は、本来、無制限である。 配信サイトの優先順位が付けられている格付けもまた作成しかつ維持すること ができることに注意する必要がある。これが実行される場合、１次スマートミラ ーサイトが応答できないと、システムは次に高い順位が付けられているスマート ミラーサイトに後退することを許容される。 スマートミラーサイトが選択された後、一定のデータが、ｅメールまたはその 他のインターネット電子プロトコルを介してＭＳＰ３２に送信されることになる （ステップ５２）。ユーザに照会することによって受け取られる情報、選択され たスマートミラーサイトの識別情報、および、各テストが実行された時刻と日付 を含む、すべての未処理テストデータと結果が（ある実施の形態では暗号化され ている）テキストファイルにコンパイルされる。ＭＳＰ３２によって受信される と、データは、システムを管理しかつ分析する上で使用するためのデータベース に記憶される。 最終的に、コンフィギュレーション・ユーティリティ３４は、配信サイトの各 セットごとのために選択されたスマートミラーサイトの識別情報または（暗号化 されている）コンフィギュレーション・ファイルに従って優先順位が付けられて いるリストを保存する（ステップ５４）。コンフィギュレーション・ユーティリ ティは、また、テストされた各配信サイトごとの相対的なパフォーマンスに関す る情報も保存することとしてもよい。クライアント・プログラム３６は、適切な スマートミラーサイトからデータファイル（ビデオクリップまたはその他のコン テンツ）をダウンロードするために暗号化されているコンフィギュレーション・ ファイルを使用する。 システムの運用では、ＭＳＰ３２が一定の機能を実行することに注意する必要 がある。ＭＳＰ３２は、配信サイトのリストを維持し、必要に応じてサイトを追 加し、かつ、削除する。ＭＳＰ３２は、また、コンフィギュレーション・ユーテ ィリティ３４を実行しているユーザから、ｅメールまたは他の手段によって受け 取られる情報を格納するネットワークパフォーマンスに関するデータベースも維 持する。大量のデータが多数のユーザから受け取られるので、データベースは、 インターネットのパフォーマンスとその他の特性、および、その部分に関する貴 重な情報を提供することができる。このような情報を運営するためには、多様な データ処理技術が知られている。 本発明で使用される配信サイトの位置は、究極的には、マーケティングの考慮 事項およびコスト／利益の分析を含む数多くのファクタによって決定される。し かしながら、ＭＳＰのデータベースに記憶されているデータは、インターネット またはそれ以外のネットワーク上の与えられた位置に配信サイトを配置する有用 性を確認することができる。一実施形態においては、サーバは、各主線（major backbone）（単一の企業によって維持されているインターネットの部分）の上に 、および、地域ベル電話会社（“ＲＢＯＣｓ”（Regional Bell Operating Comp anies））によって運用されている主要回線のような多数のユーザにサービスを 提供している他のインターネット回線上に、配置される。多数のユーザにサービ スを提供し、または、激しいビデオ配信トラフィックを有する一定のネットワー クでは、サーバは、各ユーザが高速サーバにアクセスすることを確実にするため に、ネットワークのための主要な接続点（“ＰＯＰｓ”（Points of Presence） ）に配置することができる。 いったんコンフィギュレーション・ユーティリティ３４が実行されると、ユー ザは、システムを使用し、データファイル、具体的にはビデオクリップ、音声ク リップ、ソフトウェアプログラムおよびその他のコンテンツの受信をイネーブル し、かつ、容易にすることができる。 時間が経過するとともに、ユーザのインターネットの領域の使用パターンが変 化するにつれて、ユーザは、自分のユーザ端末１２に対応しているスマートミラ ーサイトのパフォーマンスに満足できなくなる可能性がある。それが起こると、 ユーザはコンフィギュレーション・ユーティリティ３４を自由に再実行する。そ のときまでに、追加配信サイトがサービスとして稼動されているか、あるいは、 別の先に存在していたサイトが以前に割り当てられたサイトより良好に実行動作 をする可能性がある。さらに、選択されたスマートミラーサイトが十分に実行さ れていない（例えば、それが１０回の試行の内３回失敗した）とプレーヤー・プ ログラム３６が判断すると、プレーヤー・プログラム３６は、ユーザにコンフィ ギュレーション・ユーティリティ３４を再実行するようにプロンプトを出すこと ができる。本発明の他の実施の形態では、テストおよびミラーの割当てが、スマ ートミラーサービス上でのファイルに対する各要求で、または、各別の要求、３ 回目の要求、１０回目の要求もしくは１００回目の要求のたびのように、なんら かの間欠時間で、自動的に実行される。 本発明の一実施形態では、スマートミラーシステムは、ウェブページ上で参照 されているビデオクリップまたは音声クリップ（“クリップ”（“clip”））を そこからダウンロードする配信サイトの位置を突き止めるために使用される。こ の実施の形態においては、クライアント・プログラムは、“プレーヤー・プログ ラム”と呼ばれるか、“プレーヤー・プログラム”と見なすことができる。プレ ーヤー・プログラムは、クライアン・プログラム３６の機能を実行することに加 え、ビデオデータの検索およびプ1ノーバックも可能にする。通常、ブラウザ・ プログラム３８は、ウェブコンテンツを表示するためにユーザ端末１２上で実行 される。典型的に使用されているブラウザ・プログラムは、ＮＣＳＡ Mosaic、N etscape NavigatorおよびMicrosoft Internet Explorerを含む。ブラウザ・プロ グラム３８によって、ユーザは、インターネット上の多様なウェブサイトの間で ホットリンクをすることができる。 ＥＭＢＥＤタグは、ＨＴＭＬ文書内で使用され、どのウェブページがシステム によって管理されているコンテンツを含んでいるのかを示す。ブラウザ・プログ ラム３８がＥＭＢＥＤタグを含むウェブページを受け取ると、そのタグで参照さ れているファイルのダウンロードが始まるとともに、そのファイルタイプが分析 される。ファイルがＭＰＥＧなどのプレーヤー・プログラムによって処理されて いるタイプである場合、ブラウザ・プログラム３８は、プレーヤー・プログラム ３６を開始する。それから、そのタグのコンテンツはブラウザ・プログラム３８ によってプレーヤー・プログラム３６に渡される。 プレーヤー・プログラム３６（図１）は、ＭＳＰ３２によって容易にされてい るスマートミラー化サービスを提供する。プレーヤー・プログラム３６の動作は 、図３に詳細に示されている。 プレーヤー・プログラムは、最初に、ＥＭＢＥＤタグを分析し、「ＳＭ」（ス マートミラー）パラメータがあるかどうかを判断する（ステップ６０）。このよ うなパラメータの存在は、埋め込まｈているクリップがスマートミラー化のため にイネーブルされていることを示す。「ＳＭ」パラメータに関連しているデータ は、希望されているクリップの発信元である特定のコンテンツプロバイダを指定 するとともに、その特定のコンテンツプロバイダが使用するミラーサーバのグル ープも同様に指定する。 ＥＭＢＥＤタグがシステムによって処理されているビデオクリップまたはその 他のコンテンツを参照しているとプレーヤー・プログラム３６が判断する場合（ ステップ６２）、コンテンツプロバイダ２２からの埋め込まれているクリップの 転送は停止される。それから、プレーヤー・プログラム３６は、存在する場合に は、ＥＭＢＥＤステートメントからアクセス制御またはレーティング情報を抽出 する（ステップ６４）。このレーティング情報は、ユーザ端末１２に格納されて いるコンフィギュレーション・ファイルに記憶されている基準レベルに対して比 較される（ステップ６６）。レーティング情報がクリップに関し存在しない場合 、コンフィギュレーション・ファイルは、以下に規定するように、レートが定め られていないクリップが再生されてよいかどうかを判断するために問い合わせを される（ステップ６８）。前記情報に基づき、プレーヤー・プログラム３６は、 希望されているクリップの表示を許可するか、または、拒絶することになる。 プレーバックが許可されると、プレーヤー・プログラム３６が、ユーザ端末１ ２に属しているローカルコンピュータ上で参照されているクリップを発見しよう とする（ステップ７０）。それがそこに存在する場合、それは再ダウンロードさ れず、（ディスクからまたはＲＡＭから）コンピュータ上で直接再生することが できる（ステップ７２）。ただし、コーカルコンピュータでのクリップの作成の 時刻および日付は、まず、ネットワークで利用可能なクリップの時刻および日付 に付き合わせて検証され、記憶されているクリップが最も最近のバージョンであ るかどうかを判断する（ステップ７４）。それが最も最近のバージョンではない 場合、記憶されているクリップは破棄され（ステップ７６）、かつ、ダウンロー ドが以下のように進む。 クリップがローカルコンピュータ上に存在しない場合、プレーヤーは、以下の 形式による新たなＵＲＬを作成する（ステップ７８）。すなわち、コンフィギュ レーション・ファイルに記憶されている選択されたスマートミラーサイトのＩＰ アドレスと、ミラーファイルへのパス名（例えば、“/pub/mirror/”）と、ＥＭ ＢＥＤステートメントにおける「ＳＭ」のパラメータから取得されるコンテンツ プロバイダの名称と、ＥＭＢＥＤステートメントから取得されるファイル名とを 、“http://”にプラスする。その構築されたＵＲＬは、コンフィギュレーショ ン・ユーティリティ３４によって選択される適切なスマートミラーサイトから、 選択されるクリップを検索するために使用される（ステップ８０）。１つより多 いセットの配信サイトが異なるコンテンツプロバイダに存在する場合、「ＳＭ」 パ ラメータは、さらにプレーヤー・プログラム３６によって使用され、構築された ＵＲＬでコンフィギュレーション・ファイルにおけるどのスマートミラーサイト が使用されるのかを決定する（ステップ８２）。本発明の一実施形態では、サイ ト選択が少なくとも部分的にリダイレクトサーバ（redirection server）によっ て実行される。この実施の形態は、図４を参照して後に詳述する。 構築されたＵＲＬに対応するクリップがスマートミラーサイトで見つからない 場合、または、アクセスできない場合には、ダウンロードは、その後、コンフィ ギュレーション・ファイル内の次に高い順位のスマートミラーサイト、あるいは 、リダイレクトサーバによって選択された次に高い順位の配信サイト（図４を参 照のこと）から進む(ステップ８４)。すべての配信サイトが失敗すると、ダウン ロードは、ＥＭＢＥＤステートメントによって直接的に指定されているように、 元のコンテンツプロバイダのサイトから進む。 プレーバックが禁じられると、プレーヤーはクリップが転送されるのを防止す るとともに（ステップ８８）、ユーザに対してダウンロードが許可されないこと を忠告するビットマップを表示する（ステップ９０）。 ＥＭＢＥＤタグがシステムによって処理されていないビデオクリップまたはそ れ以外のコンテンツを参照しているとプレーヤー・プログラム３６が判断すると 、そのプレーヤーは、コンフィギュレーション・ファイル内に設定されているア クセス制御レベルが、ユーザに対し、これらのクリップまたは“レートが定めら れていない”（“unrated”）と見なされている他のファイルを再生することを 許すかどうかをチェックすることになる（ステップ９２）。許すのであれば、そ のクリップは、従来の手段によってその元のコンテンツプロバイダ２２から転送 され（ステップ９４）、プレーヤー・プログラム３６がダウンロードされたファ イルを表示する（ステップ９６）。許されない場合は、プレーヤーは、クリップ が転送されるのを防止するとともに（ステップ９８）、ユーザに対し、ダウンロ ードが許可されていないことを忠告するメッセージを表示する（ステップ１００ ）。 ダウンロード時、希望されているクリップを表すデータファイルは、ユーザ端 末１２に属しているローカルコンピュータ上の指定されているデータ領域内、通 常はハードディスク上に記憶される（ステップ１０２）。一実施形態においては 、このデータ領域は、プレーヤー・プログラム３６によって最低使用頻度（leas t-recently-used）を基準として管理することができる。すなわち、データ領域 内に新規クリップ用に場所がない場合、最低使用頻度の（または表示されていな い）１つまたは複数のクリップを場所を作るために破棄することができる（ステ ップ１０４）。 本発明の一実施形態においては、クライアント・プログラム３６が、ダウンロ ードが成功したかどうかを反映するために、ＭＳＰ３２にメッセージを送信する ことができるものとなっている（ステップ１０６）。このメッセージには、ユー ザ端末１２のインターネットアドレス、選択されたサーバセットの識別情報、ダ ウンロードを達成するために使用されているサイトのインターネットアドレス、 失敗したすべてのサイトのインターネットアドレス、ダウンロードされたファイ ルの名前、および。ファイルをダウンロードするための時間が含まれている。こ の情報は、また、ファイルのダウンロードを追跡調査するため、および、リアル タイムで任意のスマートミラーサイトに問題があるかどうかを判断するために、 ＭＳＰ３２によって使用することもできる。 代わりに、クライアント・プログラム３６は、ファイル転送パフォーマンスの 小さいローカルデータベースを維持することができる。それから、各ダウンロー ドが時間を合わせられることになる。具体的には、サーバが要求されたファイル を送信し始めるのに要する時間、データ転送速度の安定性、および、転送の誤り 率に関して情報を集めることができる。なんらかの間隔（例えば、毎週、または ダウンロード１００回につき1度）で、前述したユーザとサーバの情報と同様に 、蓄積されたファイル転送パフォーマンスの情報を含むメッセージが（自動的に または要求時に）ＭＳＰ３２に送信され（ステップ１０６）、ＭＳＰのデータベ ースをアップデートする。この追加情報によって、いかなる追加のテスト間接費 をも生じさせることなく、ネットワークパフォーマンスに関するＭＳＰの“知識 ”（“knowledge”）が増加する。 このデータは、配信サイトプロバイダから購入されているサービスの質を評価 する目的で、および、システムのコストをサポートするためにコンテンツプロバ イダにサービスの質を文書化する目的で、配信サイトのパフォーマンスを把握す る上で特に貴重である。しかし、同じ情報の多くは、コンフィギュレーション・ ユーティリティ３４を実行している新規ユーザを通して入手することができるこ とが認識される。 本発明の一実施形態においてはＭＳＰ３２のデータベースから引き出される情 報は、そのユーザと潜在的な配信サイトのリストの間のネットワークを試験する ために、実際にコンフィギュレーション・ユーティリティを実行する必要なしに 与えられたユーザのための配信サイトの改善を予測するのに使用することができ る。さらに具体的には、ＭＳＰ３２データベースに含まれている総計ネットワー クパフォーマンスデータは、与えられたインターネットＩＰアドレスと異なる配 信サイトの数との間のパフォーマンスの差異という点で分析される。この分析に 基づき、ユーザのＩＰアドレスと、さらに優れたデータ配信パフォーマンスを提 供する配信サイトとの間の相関関係を引き出すことができる。この相関付けられ ているデータは、配信サイト選択の過程でＭＳＰ３２が活用することができるル ックアップテーブルを作成するために使用される。 実際には、リダイレクトサーバがＭＳＰネットワーク内に含まれる。一実施形 態においては、リダイレクトサーバの機能が、ＭＳＰ３２サーバ内で実現され、 かつ、ＭＳＰ３２サーバによって実行される。代替の実施形態においては、複数 のリダイレクトサーバがネットワーク全体の様々な位置で利用されることとして もよい。 動作中、リダイレクトサーバは、ユーザがＭＳＰ配信システムによって管理さ れているファイルを要求するときに、ユーザのＩＰアドレスを取得することにな る。前述したように、ＥＭＢＥＤステートメントを通してリダイレクトサーバに 対する要求がなされる。ＥＭＢＥＤステートメントは、単一のリダイレクトサー バ（例えば、ＭＳＰ３２）を識別して特殊なサーバＩＰアドレスを明示的に参照 することができ、あるいは、シーケンスもしくはランダムな順序でアクセスを試 みることができる複数のリダイレクトサーバを指定している（例えば、Ｊａｖａ ＳｃｒｉｐｔまたはＪａｖａプログラミング言語の）スクリプトもしくは実行可 能なプログラムコードを含むことができる。それから、ＨＴＴＰ（HyperText Tr ansport Protocol）要求が典型的には要求者のアドレスに関する情報を含むので 、ユーザのＩＰアドレスは従来の手段を介してサーバによって決定される。それ から、リタイレクトサーバが、ユーザのＩＰアドレスをルックアップテーブル内 に位置している最適な配信サイトにマッピングし、かつ、配信サイトアドレスを ユーザに転送する。それから、ユーザのクライアント・プログラム３６またはリ ダイレクトサーバは、ファイルが最適な配信サイトから配信されるように、ファ イル要求の宛先変更をする。 ルックアップテーブルを設計する上で重要なファクタは、インターネット上の 多数のアドレスに由来する。インターネットに接続されているあらゆるコンピュ ータには、アドレスが割り当てられている。従来のインターネットアドレス指定 方式では、アドレスは、規約により４バイトの値から構成され、各バイトを１０ 進数（０−２５５）に変換し、かつ、バイトをピリオドで区切ることによって表 記される。例えば、“www.intervu.net”サーバのアドレスは、192.215.147.185 である。このアドレス方式を使用する場合、インターネット上には４０億を超え る使用可能なアドレスがあることになる。この技術分野の現行の状態を考慮する ならば、４０億のアドレスを含むルックアップテーブルは、大規模過ぎてここに 説明されている実施の形態では使用できないため、テーブルを圧縮するための方 法が探求された。 最適な配信サイトの選択は、多くの場合、ユーザのＩＰアドレスの第１番目の バイトに相関付けることができることが判明している。この相関関係は、コンフ ィギュレーション・ユーティリティ３４を実行した後に、同じ第１バイトのアド レスを有している統計的に意味のある数のユーザが、同じ配信サイトまたは配信 サイトの小さいグループからの別のサイトを選択するようなものとなっている。 これらの配信サイトが、相関付けられていない配信サイトに比較して、同じ第１ バイトアドレスを有する大部分のユーザにとって改善されたパフォーマンスを提 供することが認められる。相関関係は、本発明の一実施形態において、０−２５ ５に番号付けされた第１バイトのＩＰアドレスのリストと、各アドレスに対して 対応しているＩＰアドレスを有するユーザに改善されたパフォーマンスを提供す る配信サイトのリストとを含む、圧縮されたルックアップテーブルが形成される に充分な、重要なものである。このようにして、１つまたは２つ以上の配信サイ トが、アドレスリストの各エントリにマッピングされる。 一定の状況では、ルックアップテーブルにおける第１バイトＩＰアドレスのい くつかは、対応するサーバにマッピングされないことがあることに注意する必要 がある。これは、例えば、ほとんどのユーザがテーブル中のある特定のエントリ に対応しているＩＰアドレスを持っておらず、かつ、それらの内の十分な数が統 計的に重要または信頼できる結果を生じさせるためにコンフィギュレーション・ ユーティリティ３４を実行しなかったときのケースが当てはまる。このケースで は、１つまたは２つ以上のデフォルトサーバを、特殊なサーバがルックアップテ ーブルにおいて識別されていないときに、使用するためのデータベースにおいて 指定することができる。 好ましい実施の形態においては、ルックアップリストは、単一リダイレクトサ ーバ、例えばＭＳＰ３２に記憶される。ただし、ルックアップリストおよび関連 するプログラミングは、また、ウェブページのサーバ、コンテンツプロバイダ２ ２サーバ、または、前記の組み合わせにおいて記憶することもできる。 リダイレクトサーバは、以下のように、また図４に説明されるように、配信サ イトを選択するためにアクセスされる（ステップ８２、図３）。ユーザは、その ファイルのＥＭＢＥＤステートメントを有しているリンクをクリックすることに よって、ユーザ端末ブラウザを介して、ウェブページ上で参照されているファイ ルを要求する。そのファイル要求がＭＳＰの配信システムによって管理されてい るファイルに対してである場合、そのファイル要求は、従来のＨＴＭＬファイル 要求意味論、つまりサーバ「ＧＥＴ」を使用して、リダイレクトサーバ（例えば 、ＭＳＰ３２）に転送される（ステップ１２０）。 リダイレクトサーバは、到来する要求を調べ、かつ、ウェブサーバによって供 給されている“ＲＥＭＯＴＥ＿Ｈ０ＳＴ”変数を使用してユーザのネットワーク アドレス（ＩＰアドレス）を判断する（ステップ１２２）。図４に説明されてい る本発明の実施形態は、ユーザ端末１２上にインストールされている（クライア ント・プログラム３６のような）特殊目的クライアント・プログラムがなくても 達成することができることに注意する必要がある。クライアント・プログラム３ ６がまったくインストールされておらず（ステップ１２４）、かつ、ユーザが、 スクリプトまたはダウンロードされたプログラムによって問い合わされるときに 、クライアント・プログラムのインストールを希望しない（ステップ１２６）場 合は、サイト選択は完全にリダイレクトサーバによって実行される。 それから、リダイレクトサーバは、ユーザのＩＰアドレスを分析するとともに 、ルックアップテーブルの潜在的な配信サイトのリストを調べ、１つまたは複数 のどの配信サイトがユーザのＩＰアドレスと相関付けられているのかを判断する （ステップ１２８）。それから、リダイレクトサーバは、１つ以上のアドレスが ユーザのルックアップテーブルのエントリに一致する場合、配信サイトアドレス を選択する（ステップ１３０）。単一の配信サイトアドレスが見つかったときは 、ＨＴＴＰリダイレクト応答が、選択された配信サイトからファイルを配信する ために使用される（ステップ１３２）。ＨＴＴＰ仕様に従って、あるサーバから 要求されているファイルは、ユーザまたはクライアント・プログラムのいかなる 介入をも要せずに、そのサーバによって別の位置に宛先変更することができる。 これでサイト選択は完了する（ステップ１３４）。トランザクションを完了する ためには、クライアント・プログラムが選択された配信サイトからファイルのコ ピーを要求し、かつ、配信サイトサーバが該ファイルを検索するとともにそれを ユーザに配信する。 ユーザがクライアント・プログラム３６のインストールを希望する（ステップ １２６）場合には、そのプログラムは従来の手段によってダウンロードされ、か つ、インストールされることになる（ステップ１３６）。クライアント・プログ ラム３６がすでにインストールされていた場合（ステップ１２４）、あるいは、 インストールがちょうど完了したところである場合、ファイル要求は違うように 進み、サーバ側とクライアント側両方の処理を活用し、考えられる最も効率的な 方法でファイルを検索することができる。 第１に、リダイレクトサーバは、ユーザのＩＰアドレスを分析し、かつ、ルッ クアップテーブルの潜在的な配信サイトのリストを調べ、１つまたは複数のどの 配信サイトがユーザのＩＰアドレスと関連付けられているのかを判断する（ステ ップ１３８）。ルックアップテーブルを格納しているリダイレクトサーバが、配 信サイトのサブリストを含む小さいファイルを作成し（ステップ１４０）、かつ 、これをユーザ端末１２に送信し（ステップ１４２）、および、最終的な配信サ イトの選択を行うために、クライアント・プログラム３６に依存すること（ステ ップ１４４）が考えられる場合もある。これが発生するいくつかの理由がある。 第１に、前述したように、総計ネットワークパフォーマンスデータの分析は、 （単一の配信サイトとは対照的に）多くの配信サイトが同じ第１バイトアドレス の範囲を有する一定のユーザに対して改善されたパフォーマンスを提供すること を示すことがある。例えば、これは、全員が単一の第1バイトアドレス内で同じ 第1バイトアドレスまたはアドレスの範囲を有する数多くのユーザは、コンフィ ギュレーション・ユーティリティを実行後に異なる配信サイトを選択した場合に 発生する。この場合では、クライアント・プログラム３６は、リダイレクトサー バによってダウンロードされているサブリストを取得し、かつ、それをコンフィ ギュレーション・ユーティリティの実行によって以前に選択された（図３、ステ ップ５４を参照）ミラーサイトの保存されているリストと比較することができる 。一致が見つかると、クライアント・プログラムは、ファイル要求を一致してい る配信サイトに宛先変更する（ステップ１４６）。これらの配信サイトの１つま たは２つ以上が、特にコンフィギュレーション・ユーティリティが最近実行され ていない場合に、以前にコンフィギュレーション・ユーティリティによって選択 された任意の配信サイト上で改善されたパフォーマンスを提供することがあるた め、クライアントには、また、クライアント・プログラムによってなされた選択 を無視するとともに、ルックアップリストに含まれている配信サイトの中から最 良の推量の選択を行うというオプションもあることになる。 第２に、ＭＳＰによって管理されている配信サイトおよびＩＰアドレスの数が 、ルックアップテーブルが大きくなりすぎて実践的でありえない点まで増加した 場合、つまりリダイレクトサーバが以前のファイル要求の代わりにルックアップ テーブルを捜索することでビジー状態になるために新しいファイル要求に応答す ることに遅れる場合にもまた、状況が発生する可能性がある。これが当てはまる 場合には、ルックアップテーブルを捜索するというタスクは、リダイレクトサー バとクライアント・プログラム３６との間で分けられる。このようにして、ユー ザ端末１２は、処理のいくらかを実行することと、最終的な配信サイトの選択を 行うことによってルータとしての役割も果すこととを要求される。 これを達成するため、リダイレクトサーバは、ルックアップテーブルを与えら れた範囲のアドレスを含むより小さいサブリストに細分化する。このようにして 、リダイレクトサーバがファイルに対する要求を受け取ると、サーバはユーザの ＩＰアドレスを、対応するアドレス範囲を含むサブリストにマッピングし（ステ ップ１３８）、その後、該サブリストを含む小さいファイルを作成し（ステップ １４０）、かつ、ユーザにダウンロードする（ステップ１４２）。それから、ク ライアント・プログラム３６はルータとしての役割を果たし、ユーザのＩＰアド レスをサブリスト上の適切な相関付けられている配信サイトアドレスにマッピン グするか、あるいは、サブリスト上の配信サイトと前述したようにネットワーク パフォーマンステストを以前に実行した後にコンフィギュレーション・ユーティ リティ３４によって保存された優先順位が付けられているサイトのリスト上の配 信サイトとの一致を探すことによって、サブリストのルックアップテーブルにお ける配信サイトの中から配信サイトを選択する（ステップ１４４）。クライアン ト・プログラムがいったん配信サイトを選択すると、そのクライアント・プログ ラムは、選択された配信サイトへファイル要求を宛先変更する（ステップ１４６ ）。リダイレクトサーバとユーザ端末１２の間で作業を分割することによって、 ファイル要求をより迅速に処理することができ、それによってユーザがファイル を要求する時刻とファイルがユーザ端末１２によって受け取られる時刻との間の 遅延を減少させる。 ＭＳＰ３２のリダイレクトルックアップテーブルは、ネットワークパフォーマ ンスの変化に応じて頻繁にアップデートされるが、ユーザに渡されているサブリ ストは、少なくとも数日間は満足の行くものであることが予想される。したがっ て、クライアント・プログラム３６は、新しいサブリストを取得する前の数日間 、該リストを再利用することができる。この機能は、例えば、ファイル要求ステ ートメントをホストするウェブページに埋め込まれているスクリプトによって実 現することができる。そのスクリプトは、ユーザ端末１２に記憶されているサブ リストにおいて符号化されている満期日に関してクライアント・プログラム３６ に問い合わせることができる。満期日およびサブリストのタイプは、リダイレク トサーバに戻すことができ、かつ、必要ならばサーバが新しいサブリストを回送 することになる。 ある特定のユーザがＭＳＰ配信システムによって管理されているファイルを要 求することとしてもよく、システムがそのユーザに関する知識を持っていない（ つまり、ユーザのＩＰアドレスとルックアップテーブル中の配信サイトの間で一 致がまったく見つからない）ことが可能である。この場合、リダイレクトサーバ は、リダイレクトサーバに格納されているデフォルトリストからそのユーザ向け の配信サイトを選択することになる（ステップ１３０および１４４）。ユーザが この配信サイトから要求されているファイルをダウンロードすると、そのユーザ は、埋め込まれているスクリプトまたはプログラムにより、コンテンツ配信を改 善する目的でＭＳＰ３２からコンフィギュレーション・ユーティリティファイル を取得するようにプロンプトを出されてもよく、あるいは、コンテンツ配信の改 善のための近似（approximation）である（例えば、類似しているが同一ではな い第１バイトＩＰアドレスの）サーバを一時的に割り当てられることになる。ユ ーザがコンフィギュレーション・ユーティリティを取得し、かつ、実行すると、 ユーザ端末１２は、前述したように、ＭＳＰ３２に多様なネットワーク試験の結 果を提供し始め、この情報は、究極的にはネットワークパフォーマンスデータの ＭＳＰデータベースの一部となる。このようにして、その新しいユーザからの次 のファイル要求時には、リダイレクトサーバは、追加ネットワークパフォーマン スデータの分析に基づき、該ユーザのＩＰアドレスをさらに適切なサーバにマッ ヒングすることになる。 ルックアップテーブルを変更することによって、リダイレクトサーバは、また 、ファイル要求に関して負荷の配分と管理も実行することができる。ＭＳＰ３２ （またはＭＳＰ３２を制御している個人）が、ネットワークのセクションがある 時間の間ダウンするだろうと事前に判断する場合、あるいは、一定の配信サイト がある時間の間シャットダウンされなければならない場合、リダイレクトサーバ がユーザの注意を代替の配信サイトに向けるように、ルックアップテーブルを修 正することができる。したがって、同じファイルに対する２つの連続する（back -to-back）要求時には、ユーザは２つの異なる配信サイトに向けられてよいこと とするのも可能である。 ルックアップテーブルのサブリストを含むファイルが、コンフィギュレーショ ン・ユーティリティ３４によってネットワークテストを実行するために使用され る配信サイトファイルとして機能することができることが理解される必要がある 。そのサブリストは、以前にネットワークテストを実施したことのある他のユー ザのグループから引き出される総計ネットワークパフォーマンスデータにより、 パフォーマンス改善があるかどうかすでに審査された配信サイトを表す。この配 信サイトのサブリストは、リストに対してコンフィギュレーション・ユーティリ ティ３４を実行し、かつ、過去の配信サイトファイルから保持されているネット ワークテストのシーケンスを実行することによって、さらに切り詰める、または 、優先順位を付けることができる。いったんサブリストに優先順位が付けられる と、コンフィギュレーション・ユーティリティ３４は、前述したように（暗号化 されている）コンフィギュレーション・ファイルに従って、リストを保存する。 以下の例示的な説明において、スマートミラーシステムは、ウェブページの広 告の見出しに参照されているビデオクリップのダウンロード元の、改善されてい る配信サイトの位置を突きとめるためにルックアップテーブルを活用する。広告 のような相対的に人気のないコンテンツを取り扱うときには、潜在的な顧客が興 味を失わないように、意図されている顧客に広告の内容を可能な限り迅速に配信 することが重要である。ウェブページの広告見出しの内容に関しては、同じこと が当てはまる。つまり、事前に相当量のソフトウェアをダウンロードする必要な しに、顧客にビデオを可能な限り迅速に配信することができることが望ましい。 したがって、高価なサービスとして本発明を活用することの代替策として、サー ビスプロバイダは、インターネットを経由してウェブページに広告見出しを拡布 することができる。各見出しはビデオクリップを参照し、それらクリップのすべ てがその目的のために確立されているコンテンツプロバイダのサーバで格納され ることになる。 この例では、クライアント・プログラム３６は、“プレーヤー・プログラム” と呼ばれるとともに、それは、前述したように、ビデオデータを検索し、かつ、 プレーバックする追加機能性を有している。（Netscape NavigatorまたはMicros oft Internet Explorerのような）ブラウザ３８は、ユーザ端末１２でウェブコ ンテンツを表示するため、および、ユーザ端末１２とインターネット１０上のそ の他のコンピュータとの間で通信するために、使用される。 クライアントがウェブページに表示されている広告見出しを選択すると、その 見出し中に符号化されているＥＭＢＥＤタグがブラウザによって調べられる。ブ ラウザが、ＥＭＢＥＤタグによって参照されているファイルのダウンロードを開 始し、かつ、ファイルのタイプが分析される。ファイルがＭＰＥＧなどのプレー ヤー・プログラムによって処理されているタイプであれば、ブラウザはタグをプ レーヤー・プログラムに渡すことによってプレーヤー・プログラムを始動する。 プレーヤー・プログラムは、ビデオクリップのファイル名がないかＥＭＢＥＤタ グを調べ、かつ、ユーザ端末に属しているローカルコンピュータ上でそのクリッ プを見つけようとする。そのクリップがそこに存在する場合、それは再ダウンロ ードされず、（ディスクからまたはＲＡＭから）コンピュータ上で直接再生する ことができる。そのビデオクリップがローカルコンピュータ上にない場合は、プ レーヤー・プログラムはＥＭＢＥＤタグを分析し、「ＳＭ」（スマートミラー） パラメータがあるかどうか判断する。このようなパラメータの存在は、埋め込ま れているクリップがスマートミラー化のためにイネーブルにされていることを示 す。ＳＭパラメータは、さらに、特定のコンテンツプロバイダが使用するミラー サーバのグループと同様に、リダイレクトサーバのアドレスと、上述したように 希望されているクリップの発信元である特定のコンテンツプロバイダとを指定す る。 プレーヤー・プログラムがリダイレクトサーバを指定しているパラメータを認 識すると、プレーヤー・プログラムはブラウザを呼び出し、参照されている広告 見出しファイルを従来のＨＴＭＬファイル要求技術によってリダイレクトサーバ から要求する。リダイレクトサーバは到来する要求を調べ、かつ、クライアント のＩＰアドレスを判断する。リダイレクトサーバは、クライアントのＩＰアドレ スをルックアップテーブルにマッピングするとともに、配信サイトアドレスまた はサブリストを検索する。配信サイトアドレス（または配信サイトとＩＰアドレ スのサブリスト）は、リダイレクトサーバによってプレーヤー・プログラムに戻 される。サブリストが戻されると、前述したように、プレーヤー・プログラムは 、一覧表示されているサイトの中からただ一つの配信サイトを選択する。ただ一 つの配信サイトがいったん決定されると、プレーヤー・プログラムは、“http:/ /”に、選択された配信サイトのＩＰアドレスと、ファイルをミラー化するため のパス名（例えば、“/pub/mirror/”）と、ＥＭＢＥＤステートメントにおける 「ＳＭ」パラメータから取得されるコンテンツプロバイダの名前と、ＥＭＢＥＤ ステートメントから取得されるファイル名とを、足し合わせた形式の新規なＵＲ Ｌを作成する。構築されたＵＲＬは、ルックアップテーブルから選択された配信 ファイルから、選択したクリップを検索するために使用される。 ＥＭＢＥＤタグの中のＳＭパラメータがリダイレクトサーバを指定していない 場合、あるいは、リダイレクトサーバが利用できず、かつ、応答を返さない場合 、プレーヤー・プログラムは、コンフィギュレーション・ユーティリティファイ ルに記憶されているスマートミラーサイトの優先順位がつけられているリストか ら任意のＩＰアドレスを選択するとともに、ＵＲＬにおけるこのアドレスを置換 することになる。プレーヤー・プログラムが、スマートミラーサイトの優先順位 が付けられているリストの存在を検出しない場合（例えば、ユーザがコンフィギ ュレーション・ユーティリティ３４を絶対にダウンロードしなかった場合）は、 プレーヤー・プログラムは、ＥＭＢＥＤステートメントによって直接指定される ように、元のコンテンツプロバイダのサーバのアドレスを使用してビデオを要求 することになる。 広告コンテンツの配信に目標が明示的に定められていない用途では、ダウンロ ード情報をＭＳＰに提供することによって、高価な加入を基本としたサービスと しての本発明の使用が容易になる。成功したダウンロードはデータベースにおい て追跡調査されるので、各ユーザが請求金額を追跡調査するための関連「アカウ ント」を持つことができる。ユーザは、ファイル単位、メガバイト単位、月単位 、あるいは、それ以外の既知の手段によって、スマートミラーシステムの使用に 関して料金請求され得る。一実施形態においては、ファイルに関連しているＥＭ ＢＥＤタグが料金請求書作成発行の情報、つまりファイルの「価格」を含む。本 発明のダウンロードパフォーマンスの追跡調査によって、ダウンロードが過度に 困難であるか、あるいは低速であると判明すると、割引または信用貸し（ｃｒｅ ｄｉｔｓ）を発行することができる。 スマートミラー配信サイト上で記憶されているファイルが、本発明の認可され ているユーザ（例えば、支払い済みアカウントを有するそれらのユーザ）だけに よって使用されることを保証するために、配信サイトで記憶されているファイル は、任意に暗号化形式を取ることができ、かつ、前述したダウンロードステップ は、暗号解読ステップを含むこととすることができる。このような暗号化および 暗号解読は、周知の手段によって達成することができる。 上述したように、本発明によって管理されているクリップは、それと関連して いるコンテンツのレーティング情報を有するものとすることができる。これは、 クリップに対応するＥＭＢＥＤステートメントにおける「ＰＧ」パラメータを提 供することによって達成される。一実施形態においては、４つの特徴が指定され ている。つまり、裸体（nudity）、性別（sexuality）、不敬（profanity）およ び暴力（violence）である。したがって、ＰＧパラメータは、４桁の引数によっ て指定することができる。各特徴は１対３という尺度で指定されている。１はフ ィルタ機能なし（つまり、すべてのコンテンツが許容できる）に対応し、２は多 少のフィルタ機能（例えば、基本的に放送テレビで許されているレベルに等しい ）に対応し、３は最も広範囲なフィルタ機能（例えば、子供用）に対応する。あ るファイルのためにＥＭＢＥＤステートメントに含まれているレーティングのレ ベルは、前記認可プロセスにおいてユーザ端末１２に格納されたコンフィギュレ ーション・ファイルに含まれているレーティング・フィルタ・レベルと比較され 、認可されているファイルだけが転送される。 上述した観点からすると、本発明の実施の形態が、与えられたユーザとコンテ ンツプロバイダまたは配信サイトとの間のネットワークのためのパフォーマンス データの取得および分析を可能にする多くの異なるアプリケーションにおいて利 用されてよいことが理解される。したがって、説明されている実施の形態は、イ ンターネットというコンテキストの範囲で、インターネット型のアドレス指定方 式を使用して動作しているシステムを示しているが、このようなシステムが、法 人組織の“イントラネット”を含むが、それに限定されないその他のネットワー ク環境において有効であることは明白であることが認識される。 さらに、例示的な実施の形態は、おもに、ビデオ配信システムで使用するため に説明されているが、本発明によるシステムが、それ以外の多様な種類のコンピ ュータデータ（例えば、アプリケーションプログラム、データベースファイル、 およびその他のビジネス情報、バーチャル・リアリティ・ファイル、マクロメデ ィア・ショックウェーブ・ファイル（Macromedia Shockwave files）のようなマ ルチメディア、並びに、本などの大型テキストファイル）を分散するために、同 様に使用できることが認識される必要がある。このような他の種類のデータは、 上に詳細に説明したように異なるコンテンツプロバイダグループにおいて本発明 によって管理することができる。（プレーヤー・プログラム３６よりはむしろ） 別の種類のプログラムが、他の種類のデータを表示または使用するために、ユー ザ端末１２で典型的に呼び出されることになる。 また、ユーザ端末１２で実行されているものと記述された一定の機能性（特に 、コンフィギュレーション・ユーティリティ３４またはクライアント／プレーヤ ー・プログラム３６によって実行される一定の機能）は、スタンドアロン・プロ グラムとして、ブラウザプログラム内で実行するための“プラグ−イン”（“pl ug-in”）もしくは“ヘルパー・アプリケーション”（“helper application” ）として、または、ブラウザ環境内で実行するために配信サイトからダウンロー ドされるＪａｖａアプレットとして、実現できることも注意する必要がある。Mi crosoft Windowsオペレーティングシステムを実行することができるユーザ端末 にとっては、Microsoft ActiveXとして知られている環境もまた有効である。 一定の例示的な構成および動作が説明されてきたが、本発明は、そのように限 定されず、かつ、その範囲は、以下に述べられている請求の範囲に従って決定さ れるべきである。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ， ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，ＫＥ，Ｌ Ｓ，ＭＷ，ＳＤ，ＳＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ， ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，Ｅ Ｅ，ＥＳ，ＦＩ，ＧＢ，ＧＥ，ＧＷ，ＨＵ，ＩＤ，ＩＬ ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ， ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，Ｍ Ｋ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ， ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＳ，ＵＺ，ＶＮ，Ｙ Ｕ，ＺＷ (72)発明者 ロバート・エヌ・マドライ アメリカ合衆国・カリフォルニア・ 92008・カールスバッド・ポイント・レイ ズ・コート・4350

Claims (1)

1. 【特許請求の範囲】 １．ファイルを受け取るために、分散型コンピュータネットワーク上に配置さ れている配信サイトを選択するためのシステムであって、 通信ネットワークと、 前記ネットワークに接続されている少なくとも１つのコンテンツプロバイダで あって、少なくとも１つのファイルを記憶するコンテンツプロバイダと、 前記ネットワークに接続されている少なくとも２つの配信サイトであって、そ れそれコンテンツプロバイダと同じファイルを記憶する配信サイトと、 前記ネットワークに接続されているリダイレクトサーバと、 前記ネットワークに接続されているユーザ端末と、 前記ネットワークを試験し、かつ、前記ネットワークに接続されている全ての 配信サイトから１つの好ましい配信サイトを選択するためのネットワーク試験装 置と、 前記リダイレクトサーバによって指定されている前記好ましい配信サイトから 前記ユーザ端末へファイルをダウンロードするためのダウンロード装置と、 を備えるシステム。 ２．前記ネットワーク試験装置が前記ユーザ端末に接続されている第１の記憶 媒体を有し、 前記第１の記憶媒体は、前記ネットワークを試験し、かつ、前記ネットワーク に接続されているすべての配信サイトから１つの好ましい配信サイトを選択する ための、第１のソフトウェアプログラムを実現する、請求項１に記載のシステム 。 ３．前記ダウンロード装置が前記ユーザ端末に接続されている第２の記憶媒体 を有し、 前記第２の記憶媒体は、前記好ましい配信サイトから前記ユーザ端末へファイ ルをダウンロードすることができる、第２のソフトウェアプログラムを実現する 、請求項２に記載のシステム。 ４．前記リダイレクトサーバがデータベースを有する、請求項３に記載のシス テム。 ５．前記第１のソフトウェアプログラムが前記データベースによって作成され る配信サイトのリストを使用する、請求項４に記載のシステム。 ６．前記第１のソフトウェアプログラムが、配信サイトの前記リストから前記 好ましい配信サイトを選択するためのネットワーク分析手順からの結果を使用す る、請求項５に記載のシステム。 ７．前記第１のソフトウェアプログラムが、好ましい配信サイトの優先順位が 付けられたリストを作成するためのネットワーク分析手順からの結果を使用する 、請求項５に記載のシステム。 ８．前記ネットワーク分析手順が前記ユーザ端末において少なくとも部分的に 実行される、請求項６に記載のシステム。 ９．前記ネットワーク分析手順が複数のネットワーク試験を含む、請求項８に 記載のシステム。 １０．前記ネットワーク試験が前記データベース内に維持されている試験のリ ストから選択される、請求項９に記載のシステム。 １１．前記ネットワーク試験からの結果が前記データベースに提供される、請 求項９に記載のシステム。 １２．前記第１のソフトウェアプログラムが前記ユーザ端末と関連して前記ネ ットワーク試験を実行する、請求項９に記載のシステム。 １３．前記結果が前記データベースに記憶される、請求項１１に記載のシステ ム。 １４．前記データベースが、前記ユーザ端末のためのアドレスを少なくとも１ つの配信サイトにマッピングする、請求項１３に記載のシステム。 １５．前記第２のソフトウェアプログラムが前記ユーザ端末と関連してダウン ロードを実行する、請求項１４に記載のシステム。 １６．前記第２のソフトウェアプログラムが前記データベースによって指定さ れるサーバからダウンロードを実行する、請求項１５に記載のシステム。 １７．前記第１のソフトウェアプログラムが任意の時点で実行可能な請求項１ ２に記載のシステム。 １８．前記第１のソフトウェアプログラムが、任意のファイルがダウンロード される前に、自動的に実行される、請求項１７に記載のシステム。 １９．前記ファイルがビデオクリップを含む請求項１に記載のシステム。 ２０．前記第２のソフトウェアプログラムが、優先順位が付けられているリス トを使用する、請求項７に記載のシステム。 ２１．前記第２のソフトウェアプログラムが前記データベースにアクセスする 、請求項２０に記載のシステム。 ２２．前記第２のソフトウェアプログラムが、まず、優先順位が付けられてい るリストにおいて指定されている第１の配信サイトを使用することを試行する、 請求項２１に記載のシステム。 ２３．前記第１の配信ファイルが故障すると、前記第２のソフトウェアプログ ラムが、優先順位が付けられているリストにおいて指定されている連続する配信 サイトを使用することを試行する、請求項２２に記載のシステム。 ２４．優先順位が付けられているリストにおけるすべての配信サイトが故障す ると、前記第２のソフトウェアプログラムが前記コンテンツプロバイダから直接 ダウンロードすることを試行する、請求項２３に記載のシステム。 ２５．前記ファイルがそれに関連している特徴の情報を有する、請求項１に記 載のシステム。 ２６．前記特徴の情報が前記ファイルに対応する「ＥＭＢＥＤ」ステートメン ト内に記憶される、請求項２５に記載のシステム。 ２７．ネットワーク上の複数の配信サイトから好ましい配信サイトのセットを 決定するための方法であって、 配信サイトのリストを取得するステップと、 少なくとも１つのネットワーク試験を実行するステップと、 前記ネットワーク試験からの結果を処理するステップと、 前記試験の結果に従って、ＩＰアドレスに前記配信サイトをマッピングするス テップと、 を含む方法。 ２８．前記実行するステップが前記リスト中の前記配信サイトのいくつかを試 験することを含む、請求項２７に記載の方法。 ２９．前記実行するステップは、 前記リストから配信サイトのサブセットを選択することと、 前記サブセットにおけるそれぞれの配信サイトに対し、少なくとも１回の試験 を実行することと を含む、請求項２８に記載の方法。 ３０．前記試験が複数の試験から選択される、請求項２９に記載の方法。 ３１．前記複数の試験が前記ネットワークに接続されているデータベースにお いて指定される、請求項３０に記載の方法。 ３２．前記試験が、前記データベースにおいて指定されている頻度に基づき、 ランダムな選択によって複数から選択される、請求項３１に記載の方法。 ３３．前記ネットワークに接続されているデータベースに前記結果を送信する ステップをさらに含む、請求項２７に記載の方法。 ３４．前記処理するステップが、前記結果を重み付けすることを含む、請求項 ２７に記載の方法。 ３５．前記マッピングするステップが、複数のアドレス範囲のそれぞれに対し 、好ましい順序で配信サイトのセットを記憶することを含む、請求項２７に記載 の方法。 ３６．各アドレス範囲が、同じ第１バイトを有するすべてのＩＰアドレスに対 応する、請求項３５に記載の方法。 ３７．前記好ましい順序が前記試験の結果によって決定される、請求項３６に 記載の方法。 ３８．配信サイトの前記リストがデータベースから得られる、請求項２７に記 載の方法。 ３９．配信サイトからユーザ端末へファイルをダウンロードするための方法で あって、 希望されているファイルを識別するステップと、 前記希望されているファイルが、１つまたは２つ以上の配信サイト上でミラー 化されているかどうかを判断するステップと、 前記希望されているファイルがミラー化されている場合、好ましい配信サイト をＩＰアドレスにマッピングされている配信サイトのリストにおいて見つけるス テップと、 前記好ましい配信サイトから前記希望されているファイルをダウンロードする ステップと、 を含む方法。 ４０．前記判断するステップが、リダイレクトサーバに問い合わせ、かつ、応 答を受け取るサブステップを含む、請求項３９に記載の方法。 ４１．前記問い合わせるステップがスクリプトによって実行される、請求項４ ０に記載の方法。 ４２．前記スクリプトがウェブページ内に埋め込まれている、請求項４１に記 載の方法。 ４３．前記問い合わせるステップが、前記ユーザ端末にダウンロードされてい るプログラムによって実行される、請求項４０に記載の方法。 ４４．検索するステップおよびダウンロードするステップが、前記ダウンロー ドするステップが成功するまで繰り返される、請求項４０に記載の方法。 ４５．繰り返される検索およびダウンロードのステップが成功しない場合に、 コンテンツプロバイダのサイトから前記希望されているファイルをダウンロード するステップをさらに含む、請求項４４に記載の方法。 ４６．前記見つけるステップは、 前記ユーザ端末のためのアドレスを決定するサブステップと、 前記アドレスを、データベース内のアドレスのリストと比較するサブステップ と、 前記データベースに十分なデータが含まれている場合、前記アドレスに対応す る前記好ましい配信サイトの位置を突きとめるサブステップと、 前記データベースに十分なデータが含まれていない場合、デフォルトの配信サ イトの位置を突きとめるサブステップと を含む、請求項４０に記載の方法。 ４７．前記比較するステップが、前記データベースをホストするコンピュータ において実行される、請求項４６に記載の方法。 ４８．前記位置を突きとめる両ステップが、前記データベースをホストするコ ンピュータにおいて実行される、請求項４７に記載の方法。 ４９．第１の前記位置を突きとめるステップは、 アドレスのサブリストを隔離するサブステップと、 前記サブリスト内で前記好ましい配信サイトを選択するサブステップと を含む、請求項４６に記載の方法。 ５０．前記選択するステップが前記ユーザ端末において実行される、請求項４ ９に記載の方法。