JP2002540491A - ウェブサーバコンテンツ複製 - Google Patents

Abstract

(57)【要約】 本発明は、複数のウェブサーバの管理、システムオペレータがコンテンツをウェブサービスシステム内の各サーバに配信することを可能にするウェブサーバシステムおよび方法、ならびにキャッシュサーバのようなコンピュータにコンテンツの変更を知らせることに関する。１つの実施形態において、コンピュータに変更したファイルを知らせる方法は、ソースファイルセット内の変更点を識別する工程、修正リスト内の識別した変更点を格納する工程、および修正リストをコンピュータに送信する工程を含む。

Description

【発明の詳細な説明】

【０００１】 （関連出願の相互参照） 本願は、１９９８年５月２９日に出願された米国特許出願第０９／０８６，８
２１号の一部継続出願であり、本願は、１９９８年５月２９日に出願された米国
特許出願第０９／０８６，８３６号の一部継続出願であり、本願は、１９９８年
５月２９日に出願された米国特許出願第０９／０８６，８７４号の一部継続出願
であり、本願は、１９９８年５月２９日に出願された米国特許出願第０９／０８
７，２６３号の一部継続出願であり、１９９９年１月２８日に出願された米国仮
特許出願第６０／１１７，６７４号、１９９９年８月１９日に出願された米国特
許出願第０９／３７６，０１７号、１９９９年８月１９日に出願された米国特許
出願第０９／３７７，６１１号の優先権を主張する。

【０００２】 （技術分野） 本発明は、複数のウェブサーバの管理、より具体的には、システムオペレータ
がウェブサービスシステム内の各ウェブサーバにコンテンツを配信することを可
能にする。ウェブサービスシステムに関する。

【０００３】 （背景情報） コンピュータネットワーク環境において、ウェブサーバは、ユーザのウェブペ
ージリクエストに応答するように用いられ、ユーザのウェブページリクエストは
、コンピュータネットワークにわたって送信される。コンテンツリクエストとも
呼ばれるウェブページリクエストは、典型的には、ユーザのコンピュータで実行
するブラウザによって行われる。ウェブサーバは、ウェブページリクエストに対
し、１つ以上のコンピュータネットワークアドレス／ポートエンドポイント端点
を監視し、リクエスタにウェブページを送信することによりウェブページリクエ
ストに、応答する。ウェブサーバは、特殊用途のデバイスであってもよいし、汎
用コンピュータで実行するソフトウェアプログラムによって実現されてもよい。
ウェブサーバのサービス容量は、所与の時間間隔で受信され得、応答され得るウ
ェブページリクエストの数を制限する。

【０００４】 ウェブサービスシステムは、１つのウェブサーバまたは１つより多いウェブサ
ーバを含み得る。概して、ウェブサービスシステムが、１つより多いウェブサー
バを含む場合、ウェブサービスシステムは、複数のウェブサーバの各々がウェブ
ページリクエストに応答するように設計される。典型的には、ユーザのウェブペ
ージリクエストは、ウェブサーバのうちの１つに振り向けられ、そのウェブサー
バはそのウェブページリクエストに応答する。また、典型的には、多数のウェブ
ページリクエストを受信するように設計されるウェブサービスシステムが、多く
のウェブサーバを含む。

【０００５】 概して、複数のウェブサーバを有するシステムにおいて、単数または複数のシ
ステムオペレータは、様々なサーバによって提供されるコンテンツを管理する。
システムオペレータは、システムのコンテンツを調整し、例えば、様々なウェブ
サーバのコンテンツがユニフォームであることを確認し、もしくは１つのウェブ
サーバから得られる一部のコンテンツおよび他のウェブサーバから得られる他の
コンテンツを有することを時に望み得る。これは、特にコンテンツの更新がユー
ザに対し明白であるべき場合、達成するのが困難であり、ユーザは、一連の関連
するウェブページを含むシステムとのインタラクションの最中である可能性があ
る。

【０００６】 また、コンテンツの管理は、キャッシュサーバにとって問題である。キャッシ
ュサーバは、連続的なユニフォームのリクエストを満たすのに用いる、ブラウザ
からウェブサーバに伝えられるリクエストの結果を、「キャッシュする」、つま
り一時的に格納する。キャッシュサーバ設計および操作における課題は、格納さ
れた（キャッシュされた）コンテンツが元のサーバのコンテンツと一致しなくな
るか、すなわち、キャッシュされたコンテンツがいつ無効になるかを判定するこ
とである。ハイパーテキスト転送プロトコル（「ｈｔｔｐ」）は、キャッシュサ
ーバがコンテンツのコピーを保たなければならない持続時間を特定する、一部の
コンテンツの元のサーバ用の仕組みを含む。しかし、一部のコンテンツについて
は、コンテンツがどれぐらいの間、有効性を維持するかを、元のサーバが前もっ
て正確に判定することが不可能であり、元のサーバによって特定された終了時間
よりも早くにコンテンツが予期せず更新される場合があり得る。

【０００７】 （発明の要旨） １つまたは多くのウェブサーバを有するウェブサービスシステムにおいて、１
つ以上のウェブサーバ上のコンテンツを管理および配信するシステムおよび方法
が、システムオペレータにとって有用である。例えば、コンテンツ更新は、しば
しば、素早く行われることが所望される。スケジューリングおよび自動化は、効
率的かつ一貫した様態で、サーバ上のコンテンツを更新するために用いられ得る
。また、可能な限り素早く、コンテンツの更新の失敗を識別し、機能しなくなっ
たサーバを休止させ、サーバを修理し、ウェブサービスシステムにおいてサーバ
を動作状態に戻すことは、有用である。更新を行うと同時に、トランザクション
の分断を最小化しながら、ウェブサイト利用可能性を最大化することが所望され
る。変更は、例えば、ウェブサーバプロセス（単数または複数）が終了するまで
ロードされない（および／または更新されない）共有のライブラリを用いてコン
テンツが供給される場合、サーバが再開することを必要とし得る。

【０００８】 本発明によるウェブサービスシステムは、システムにおける１つ以上のウェブ
サーバの変更されたコンテンツを、正確に、かつ、効率的に更新する。その結果
ウェブサーバ間の変更は首尾一貫し、変更は過剰なネットワーク帯域幅を要求し
ない。これは、ウェブサーバとのトランザクションに関係するブラウザにコンテ
ンツの変化が顕著でなく、達成され、コンテンツのバージョンは、より古いコン
テンツを用いて開始されるトランザクションの一貫性のため、および更新に問題
がある場合に古いコンテンツにウェブサーバが戻ることを可能にするため、保存
される。また、本発明のウェブサービスシステムは、コンテンツの変更点を探知
し得、適切なときにキャッシュされたコンテンツが無効になったことをキャッシ
ュサーバに知らせ得る。

【０００９】 概して、１つの局面において、本発明は、変更されたファイルをコンピュータ
に知らせるシステムおよび方法に関する。ソースファイルセット内の変更点は、
識別される。識別された変更点は、変更されたファイルを特定する、ユニフォー
ムリソースロケータを含む修正リストに格納される。修正リストは、コンピュー
タに送信される。１つの実施形態において、修正リストは、ウェブキャッシュサ
ーバに送信される。１つの実施形態において、ファイルのセットを検査し、ファ
イルのセットを以前に記録されたセットと比較することによって、変更点が識別
される。他の実施形態において、ファイル属性を以前に記録されたセットのファ
イル属性と比較することによって、ファイルのセットが以前に記録されたセット
と比較される。他の実施形態において、ファイル属性は、ファイルサイズ、ファ
イルの許可、ファイルの所有権、修正時刻、およびハッシュファイルのセットか
ら選択される少なくとも１つの属性を含む。他の実施形態において、ファイルの
セットを検査し、ファイルのセットを以前に記録されたセットと比較することに
よって、変更点が識別される。他の実施形態において、ファイル動作を行うよう
にデバイスドライバをインストールすること、および、デバイスドライバによっ
て、ソースファイルセットの変更点を記録することによって、変更点が識別され
る。他の実施形態において、ソースファイルセットの変更点を記述するマニフェ
スト（ｍａｎｉｆｅｓｔ）を受信することによって、変更点が識別される。他の
実施形態において、方法は、識別する工程の前に、スクリプトを呼び出す工程を
包含する。他の実施形態において、方法は、送信する工程の前に、スクリプトを
呼び出す工程を包含する。他の実施形態において、方法は、送信する工程の後に
、スクリプトを呼び出す工程を包含する。他の実施形態において、方法は、送信
する工程が首尾よく完了したかどうかを判定する工程を包含し、呼び出す工程が
、判定する工程の後に発生する。

【００１０】 概して、他の局面において、本発明は、ソースファイルセット内の変更点を、
宛先ファイルシステムで複製し、変更点をコンピュータに知らせるシステムおよ
び方法に関する。ソースファイルセット内の変更点は識別される。変更点は、第
１の修正リストに格納される。修正リストは、宛先ファイルシステムへのアクセ
スを有するエージェントに送信される。変更点は、変更されたファイルを特定す
るユニフォームリソースロケータを含む、第２の修正リストに格納される。修正
リストは、コンピュータに送信される。１つの実施形態において、修正リストは
、ウェブキャッシュサーバに送信される。他の実施形態において、第１の修正リ
ストは、第２の修正リストに変換される。

【００１１】 概して、他の局面において、本発明は、ソースファイルセット内の変更点を、
宛先ファイルシステム上で複製し、変更点をコンピュータに知らせるシステムお
よび方法に関する。ソースファイルセット内の変更点は識別される。変更点は、
変更されたファイルを特定するユニフォームリソースロケータを含む、第２の修
正リストに格納される。修正リストは、宛先ファイルシステムへのアクセス権を
有するエージェントに送信される。修正リストは、コンピュータに送信される。

【００１２】 概して、他の局面において、本発明は、ウェブサービスシステムに関する。シ
ステムは、ウェブサービスシステムを管理するマネージャを含む。また、システ
ムは、ウェブページリクエストを受信するウェブサーバ、およびマネージャと通
信するエージェントを備えるホストを含む。また、システムは、ウェブキャッシ
ュと、ホストにコンテンツ変更点を提供するコンテンツディストリビュータとを
含む。１つの実施形態において、コンテンツディストリビュータは、コンテンツ
の変更点をウェブキャッシュに知らせる。他の実施形態において、システムは、
ウェブページリクエストを向けるトラフィックマネージャを含む。他の実施形態
において、コンテンツディストリビュータは、ソースファイルセット内の変更点
を識別する識別モジュールと、識別された変更点を格納する修正リストと、修正
リストを宛先ファイルシステムへのアクセスを有するエージェントに送信するト
ランスミッタとを含む。他の実施形態において、システムは、変更されたファイ
ルをエージェントに送信するトランスミッタを含む。他の実施形態において、エ
ージェントは、宛先ファイルシステム上の変更されたファイルをインストールす
る、インストーラを含む。

【００１３】 概して、他の局面において、本発明は、コンテンツディストリビュータに関す
る。コンテンツディストリビュータは、ソースファイルセット内の変更点を識別
する識別モジュールを含む。また、コンテンツディストリビュータは、識別され
た変更点を格納する修正リストを含む。また、コンテンツディストリビュータは
、修正リストを宛先ファイルシステムへのアクセス権を有するエージェントに送
信するトランスミッタを含む。１つの実施形態において、コンテンツディストリ
ビュータは、変更されたファイルをエージェントに送信するトランスミッタを含
む。他の実施形態において、コンテンツディストリビュータは、変更されたファ
イルをウェブキャッシュサーバに送信するトランスミッタを含む。

【００１４】 本発明の上記および他の目的、局面、特徴、および利点は、以下の説明からよ
り明らかになる。

【００１５】 図面において、ユニフォームの参照符号は、概して、異なる図を通じて同じ部
分を指す。また、図面は、必ずしも縮尺される必要はなく、概して、本発明の原
理を示すことに重点が置かれている。

【００１６】 （説明） ウェブページを供給するシステムは、複数のウェブサーバを有し、複数のウェ
ブサーバの動作を調整する機能およびツールをシステムオペレータに提供する。
システムは、１つのウェブサーバのみを有してもよいが、典型的には、１つより
多いウェブサーバを含む。システムは、概して、クライアントコンピュータ上の
ウェブブラウザから発生するウェブページリクエストを、利用可能なウェブサー
バに向けることによって、トラフィックを管理する。このようにして、システム
は、複数のサーバ間のウェブページリクエストサービス負荷の均衡を取る。シス
テムは、ウェブページリクエスト、およびこれらのウェブページリクエストに対
するウェブサーバ応答についてのデータを収集し得、データの報告と、自動およ
び手動解析ツールとを提供する。システムは、特定のイベントを監視し得、この
ようなイベントの発生時には自動的に動作し得る。イベントは、今にも起こりそ
うなシステム問題を示す予測または閾値を含む。システムは、自動エラー復旧を
提供し、構成要素の欠陥またはネットワーク環境問題のようなイベントから回復
するために取られ得る可能な動作を通じてシステムオペレータをガイドする、危
機管理能力を含み得る。システムは、システムオペレーションについての現在の
情報を、システムオペレータに示し得る。システムは、バージョン管理およびデ
ータのアップデートでコンテンツの複製を管理し得る。これらの機能性の一部ま
たは全てが、特定の実施形態において提供され得る。

【００１７】 図１を参照すると、ウェブサービスシステム９０の実施形態が、ブラウザ１か
らのウェブページリクエストを受信する。このコンテキストにおいて、ウェブペ
ージは、ウェブページリクエストに応答して、コンピュータネットワーク２上で
利用可能にされ得る電子コンテンツである。リクエストは、典型的には、ウェブ
ブラウザ１から発生される。ウェブページの一例として、表示、実行、再生、処
理、ストリーミング、および／または格納され得、他のウェブページへのリンク
、またはポインタを含み得る、コンピュータ実行可能または解釈可能な情報、グ
ラフィックス、音、テキスト、および／または映像を含むデータファイルがある
。リクエストは、通信ネットワーク２を介して通信され得る。１つの実施形態に
おいて、通信ネットワーク２はイントラネットである。他の実施形態において、
通信ネットワーク２は、インターネットとして公知のグローバル通信ネットワー
ク２である。ブラウザ１は、ユーザによって操作されて、ウェブページリクエス
トを作成し得る。また、ブラウザ１は、コンピュータまたはコンピュータプログ
ラムによって操作されて、コンピュータプログラミングに基づいて自動的にリク
エストを作成し得る。ウェブページリクエストは、ハイパーテキスト転送プロト
コル（「ｈｔｔｐ」）フォーマットを用いて作成されてもよいし、リクエスト能
力を提供する他のプロトコルを用いて作成されてもよい。

【００１８】 図２を参照すると、様々な構成要素１００〜１２６を含むウェブサービスシス
テム９０の実施形態が示される。構成要素は、１つ以上のコンピュータネットワ
ークを介して通信する。構成要素の物理的な位置は、様々な構成要素間の通信リ
ンクが十分なデータ通信能力を有する限り、システムの性能またはパフォーマン
スに影響を与えない。ウェブサービスシステム９０は、種々の設計のファイアウ
ォールを通って機能し得、遠隔的に設定および管理され得る。

【００１９】 ウェブサービスシステム９０は、１つ以上のホスト１００を管理する。例とし
て、１つのホスト１００が示されている。ウェブサービスシステム９０の実施形
態は、任意の数のホスト１００を有し得る。各ホスト１００は、市販されており
、ＵＮＩＸ（登録商標）またはＷｉｎｄｏｗｓ（登録商標） ＮＴのようなマル
チスレッドのオペレーティングシステムを用いることができるコンピュータシス
テムであり得る。各ホスト１００は、例えば、インターネットまたはイントラネ
ット、あるいは任意の他のネットワークのような、少なくとも１つのコンピュー
タネットワークへのネットワーク接続を有し得る。このことによって、ホスト１
００が、ウェブページデータリクエストに応答して、ウェブページデータを提供
することが可能になる。各ホスト１００は、少なくとも１つのウェブサーバ１０
２を含む。

【００２０】 ウェブサーバ１０２は、コンピュータネットワークを介して受信したウェブペ
ージリクエストに応答して、ウェブページを提供する任意のウェブサーバであり
得る。このようなウェブサーバの２つの例は、Ｍｏｕｎｔａｉｎ Ｖｉｅｗ，Ｃ
ａｌｉｆｏｒｎｉａのＮｅｔｓｃａｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｃｏ
ｒｐｏｒａｔｉｏｎから市販されているＮＥＴＳＣＡＰＥ ＥＮＴＥＲＰＲＩＳ
Ｅ ＳＥＲＶＥＲと、Ｒｅｄｍｏｎｄ，ＷａｓｈｉｎｇｔｏｎのＭｉｃｒｏｓｏ
ｆｔ Ｃｏｒｐｏｒａｔｉｏｎから市販されているＭＩＣＲＯＳＯＦＴ ＩＮＴ
ＥＲＮＥＴ ＩＮＦＯＲＭＡＴＩＯＮ ＳＥＲＶＩＣＥＳ ＳＥＲＶＥＲとがあ
る。ウェブサーバ１０２は、ブラウザおよび／またはウェブページのリクエスタ
とも呼ばれるウェブクライアントから、ウェブページリクエストを受信すること
ができる。また、ブラウザからのウェブページリクエストは、コンテンツリクエ
ストと呼ばれるか、またはウェブサーバの視点から、「ヒットする」とも呼ばれ
る。しばしば、ウェブページリクエストは、いくつかのリクエストおよび応答に
関わる、ウェブサーバ１０２との通信のシリーズの一部である。セッションと呼
ばれる、このようなシリーズは、ウェブサーバとの、広げられたインタラクショ
ンである。より短いインタラクション、例えば、商品の購入は、トランザクショ
ンと呼ばれる。セッションは、いくつかのトランザクションを含み得る。ユーザ
は、ウェブサーバ１０２の初期リクエストを作成することで、ウェブサーバ１０
２とやりとりし、そのやりとりの結果ウェブサーバ１０２にウェブページを応答
として送信する。ウェブページは情報を含み得、ウェブサーバ１０２またはおそ
らく他のウェブサーバから作成し得る他のリクエストへのポインタも含み得る。
リクエストは、データベースから検索されなければならない情報を求める場合も
あれば、データベースに格納される情報を含む場合もある。リクエストは、ウェ
ブサーバ１０２による処理、または他のコンピュータシステムとのインタラクシ
ョンを必要とする場合もある。高性能なウェブサーバとブラウザとは、様々な方
法でインタラクトし得る。

【００２１】 関連するトピックについてのウェブページのセットとして、または、特定のソ
ース、必ずではないが、通常は同じウェブサーバ１０２から、ユーザに提示され
る、関連するウェブページの集合は、アプリケーションと呼ばれる。アプリケー
ションの一例として、会社についての情報を提供するページのセットがある。ア
プリケーションの他の例として、ユーザが自身の貯蓄銀行と取り引きすることを
可能にするページのシリーズがある。ウェブページの２つのセットは、１つのア
プリケーションとして考えられてもよいし、２つの別個のアプリケーションとし
て考えられてもよい。例えば、ウェブページのセットは、銀行についての情報を
提供し得、ウェブページのカスタマーサービスセットは、銀行との事務処理を可
能にし得る。ウェブページのセットが、１つのアプリケーションとして考えられ
るか、またはいくつかのアプリケーションとして考えられるかは、アプリケーシ
ョン設計者によって決定される。ウェブサービスシステム９０は、１つ以上のア
プリケーションをユーザに送る能力を有する。ウェブサービスシステム９０は、
ウェブサーバ１０２の一部のサブセットが、１つのアプリケーションのみの役に
立つように設定され得る。１つの実施形態においては、ウェブサーバ１０２の一
部のサブセットが、利用可能なアプリケーションのサブセットの役に立ち、他の
ウェブサーバ１０２は、他のアプリケーションの役に立つ。他の実施形態におい
ては、全てのウェブサーバ１０２が、全ての利用可能なアプリケーションの役に
立つ。

【００２２】 ユーザのウェブブラウザからのウェブページリクエストに応答してユーザに提
示されるウェブページは、ホスト１００、または、ウェブサーバ１０２にアクセ
ス可能なファイルシステムに格納され得る。一部または全てのウェブページコン
テンツは、ウェブサーバ１０２に利用可能なデータを処理することによって、ウ
ェブサーバ１０２によって生成され得る。例えば、トピックについてのドキュメ
ントであるウェブページについて、ウェブページが、作成（設計）され、ウェブ
サーバ１０２ファイルシステムに格納され得る。ウェブページリクエストに応答
して、このようなウェブページは、ファイルシステムに格納されるのと同時に、
ユーザに送信され得る。しかし、銀行取引システムにおいては、ユーザの銀行口
座についての情報が、データベースに格納される可能性が高い。ウェブサーバ１
０２は、ユーザがページをリクエストするたびに、ユーザの口座情報を含むウェ
ブページを生成し得る。しばしば、ウェブページは、部分的にはファイルシステ
ムに格納され、部分的には、リクエストされるとき、ウェブサーバ１０２によっ
て生成される。

【００２３】 ユーザのウェブサーバ１０２とのセッションの「状態」とも呼ばれるステータ
ス情報を格納するため、様々な技術が用いられる。ユーザは、自身とウェブサー
バ１０２とのインタラクションの間に、作成するウェブサーバ１０２へのリクエ
スト、およびこれらのリクエストに対する応答として受信したウェブページを通
じて、状態を発展させ得る。一例として、ユーザの状態は、ユーザを識別する情
報を含み得る。他の例として、状態は、ユーザが既にリクエストしたウェブペー
ジ、またはユーザがシステムとのインタラクションにおいて選択したオプション
を特定する情報を含み得る。他の例として、状態は、商品販売アプリケーション
からユーザが購入することを選択したアイテムを含み得る。概して、セッション
の状態についての一部の情報またはセッションの状態を識別する情報は、例えば
、以下で説明するクッキーとして、クライアントウェブブラウザに格納され、一
部の情報は、ウェブサーバ１０２に格納され得る。

【００２４】 ホスト１００は、ホスト容量、性能、およびコストについての考慮に依存して
、任意の数の、その上で実行されるウェブサーバ１０２を有し得る。１つの実施
形態において、ホスト１００は、１つのウェブサーバ１０２を含む。他の実施形
態において、ホストは、１つより多いウェブサーバ１０２を含む。ホスト１００
上の１つのウェブサーバ１０２は、簡略化された例示的な例であり、ウェブサー
バ１０２の取り得る数を限定するものではない。各ウェブサーバ１０２は、エン
ドポイントとも呼ばれる、少なくとも１つのネットワークアドレスおよびポート
を監視する。特定のアドレスおよびポートが、バーチャルな通信のエンドポイン
トであるので、エンドポイントと呼ばれ、ネットワーク接続は、１つのアドレス
／ポートエンドポイントと他のアドレス／ポートエンドポイントとの間で作成さ
れる。ウェブサーバ１０２は、そのエンドポイントのうちの１つに向けられたリ
クエストを受信し、ウェブページの形式のデータでこれらのリクエストに応答す
る。

【００２５】 複数のネットワークアドレス／ポートエンドポイントでリクエストを受け取る
ウェブサーバ１０２は、実際には１つのウェブサーバ１０２として実行されるに
も関わらず、複数の異なるウェブサーバ１０２であるかのように、動作し得る。
このようなウェブサーバは、複数エンドポイントウェブサーバと呼ばれる。説明
のため、複数のエンドポイントウェブサーバは、実際に、各ウェブサーバ１０２
がネットワークアドレス／ポートエンドポイントでリクエストを受信する、複数
のウェブサーバ１０２であるかのように、説明され得る。１つの実施形態におい
て、このような複数エンドポイントウェブサーバは、複数のエンドポイント全て
とのインターフェースである、ウェブサーバインターフェース１０４を１つ有す
る。

【００２６】 各ウェブサーバ１０２は、ウェブサーバインターフェース１０４と関連付けら
れ得る。ウェブサーバインターフェース１０４は、ウェブサーバ１０２とウェブ
サービスシステム９０の他の構成要素との間のインターフェースとして役に立つ
、プラグイン、フィルタ、または、ウェブサーバ１０２と関連付けられた他のソ
フトウェアであり得る。このコンテキストにおいて、タームウェブサーバインタ
ーフェースは、ホスト１００に存在し得るネットワークインターフェースとは異
なる。例えば、ウェブサーバ１０２は、ウェブサーバインターフェース１０４を
有する。各ウェブサーバインターフェースは、各ホスト１００上のエージェント
１０６と通信し得る。

【００２７】 ホスト１００は、エージェント１０６を含む。エージェント１０６は、ホスト
１００とインターフェースをとるウェブサービスシステム９０を提供する。エー
ジェント１０６は、ウェブサーバインターフェース１０４をウェブサービスシス
テム９０とリンクする。また、エージェント１０６は、ホスト１００をウェブサ
ービスシステム９０とリンクする。複数のウェブサーバを有するホストにおいて
、１つより多いエージェントを有することが可能であるとしても、一般的には、
ホスト１００上で実行しているエージェント１０６は１つしかない。各エージェ
ント１０６は、システム構成要素についての情報を含むデータベース１０８への
アクセスを有する。

【００２８】 ホスト１００上のエージェント１０６は、ウェブサービスシステムマネージャ
１１０と通信する。マネージャ１１０は、ホスト１００およびウェブサーバ１０
２のステータスについての情報を、エージェント１０６から受信する。マネージ
ャ１１０は、コマンドをエージェント１０６に送信して、ウェブサーバ１０２を
開始、終了、または一時停止させて、ウェブサーバ１０２の負荷を管理するよう
に、ホスト１００を設定し得る。マネージャ１１０は、システム活動およびイベ
ントのロギングにおいて用いられるロギングデータベース１１４へのアクセスを
有する。また、マネージャ１１０は、システムの様々な構成要素についての情報
を格納するために用いられる、管理されているオブジェクトデータベース１１２
へのアクセスを有する。また、マネージャ１１０は、１つ以上のコンソール１１
６Ａ〜１１６Ｘ、全体的に１１６と呼ばれるコンソールと通信する。コンソール
１１６は、システムオペレータにユーザインターフェースを提供する。システム
オペレータは、システムのステータスを監視し、コンソールを通じてシステムを
設定し得る。マネージャ１１０は、ウェブサーバ１０２の１つまたはトラフィッ
クマネージャ１２０、あるいは、十分な容量の他のコンピュータのような、ウェ
ブサービスシステム９０の他の構成要素と同じホスト１００上で実行し得る。

【００２９】 マネージャ１１０は、インターセプタとも呼ばれるトラフィックマネージャ１
２０と通信する。トラフィックマネージャ１２０は、ウェブページリクエストを
ウェブサーバに向ける。本発明は、トラフィックマネージャ１２０の任意の特定
のタイプによって限定されず、ウェブページリクエストをウェブサーバ１０２に
向ける、任意の種類のトラフィックマネージャ１２０と共に動作するように意図
される。

【００３０】 １つの実施形態において、トラフィックマネージャ１２０は、マネージャ１１
０から情報およびコマンドを受信する。また、トラフィックマネージャ１２０は
、制御プログラム１２２から情報およびコマンドを受信する。トラフィックマネ
ージャ制御プログラムは、トラフィックマネージャ１２０と同じコンピュータシ
ステム上にあってもよく、あるいは、他のシステム上で実行してもよい。トラフ
ィックマネージャ１２０は、ウェブページリクエストを受信し、ウェブサーバの
うちの１つにリクエストを問い合わせる。ウェブサービスシステム９０の管理能
力のうちの一部は、ウェブサーバ１０２によって作成されるウェブページリクエ
ストと、得られるウェブサーバ１０２およびホスト１００上の負荷とを監視する
ことによって達成される。ウェブページリクエストは、ウェブサーバ１０２間の
負荷の均衡を取るように、向けられ得る。１つの実施形態において、トラフィッ
クマネージャ１２０は、ユーザが最初に接触する点である。トラフィックマネー
ジャ１２０は、ユーザからウェブページリクエストを受信し、ユーザのウェブブ
ラウザをそのリクエストに関して適切なウェブサーバ１０２に「問い合わせる」
。ユーザのウェブブラウザは、適切なウェブサーバ１０２上のウェブページへの
照会を用い、ウェブページリクエストに応答することで、問い合わせられる。こ
の照会能力は、ハイパーテキスト転送プロトコルに組込まれる能力で達成され得
るが、他の方法でも達成され得る。ユーザは、ウェブブラウザが、適切なウェブ
サーバ１０２に問い合わせられたことを認識してもよいし、しなくてもよい。ユ
ーザは、そのウェブサーバ１０２上のアプリケーションにアクセスし、そのウェ
ブサーバ１０２からのウェブページリクエストへの応答を受信し得る。１つの実
施形態において、ウェブサーバ１０２に負荷が掛けられ過ぎた場合、そのウェブ
サーバ１０２は、マネージャ１１０の指示の下で、ユーザをトラフィックマネー
ジャ１２０に差し戻すか、またはアプリケーションを送る能力を有する他のウェ
ブサーバ１０２に問い合わせ得る。

【００３１】 トラフィックマネージャ１２０は、ユーザからのリクエストを受信し、ユーザ
のリクエストをウェブサーバ１０２に向け直す。１つの実施形態において、トラ
フィックマネージャ１２０が、他のトラフィックマネージャ１２０または単一の
エンドポイントのように、全てのユーザを１つのウェブサーバ１０２に向けるよ
うに用いられる。このようにして、トラフィックマネージャ１２０は、分路とし
て機能を果たす。すなわち、トラフィックマネージャ１２０は、ホストの１つ以
上のウェブサーバに向けられた全てのリクエストを、他のウェブサーバ１０２に
向ける。他の実施形態において、トラフィックマネージャ１２０は、マネージャ
１１０から、ステータス情報を受信し、その情報を用いてユーザを向け直す。ス
テータス情報は、サーバ利用可能性および負荷、管理者の変化、ならびにアプリ
ケーションまたはウェブサーバ１０２の開始および終了アクションを含む。トラ
フィックマネージャ１２０は、速度およびセキュリティのために設計される。ト
ラフィックマネージャ１２０は、システムの正面入り口であり、その性能は、全
体ウェブサービスシステム９０の知覚された性能に影響する。トラフィックマネ
ージャ１２０を、ネットワークトポロジーの意味において、可能な限りバックボ
ーンの近傍に配置することが有用であり得る。従って、必然的に、トラフィック
マネージャ１２０は、ウェブサービスシステム９０の最も露出される構成要素で
ある。

【００３２】 １つの実施形態において、トラフィックマネージャ１２０は、ハードウェアに
おいて実現される。他の実施形態において、トラフィックマネージャ１２０は、
ホストコンピュータ上で実行されるソフトウェアプログラムである。ソフトウェ
ア実施形態の１つにおいて、トラフィックマネージャ１２０は、マルチスレッド
のオペレーティングシステムを実行する能力を有するサーバクラスコンピュータ
で実行されるスタンドアロンのプログラムである。ＵＮＩＸ（登録商標）の下で
、トラフィックマネージャ１２０は、例えば、デーモンとして実行し得る。Ｗｉ
ｎｄｏｗｓ（登録商標）ＮＴの下で、トラフィックマネージャ１２０は、サービ
スとして実行し得る。

【００３３】 他の実施形態において、トラフィックマネージャ１２０は、１つのエンドポイ
ントに向けられたリクエストをウェブサーバ１０２に属するエンドポイントに向
けるインターネットプロトコルブリッジまたはルーターである。このようにして
、トラフィックマネージャ１２０は、ウェブページリクエストを、１つ以上のウ
ェブサーバ１０２に向ける。このようなトラフィックマネージャの一例として、
Ｓａｎ Ｊｏｓｅ， ＣａｌｉｆｏｒｎｉａのＣｉｓｃｏ Ｓｙｓｔｅｍｓ，
Ｉｎｃ．製のＬＯＣＡＬＤＩＲＥＣＴＯＲがある。さらに別の実施形態において
、トラフィックマネージャ１２０は、Ｗｅｓｔｆｏｒｄ， Ｍａｓｓａｃｈｕｓ
ｅｔｔｓのＡｒｒｏｗｐｏｉｎｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ， Ｉｎｃ．
製のＣＯＮＴＥＮＴ ＳＭＡＲＴ ＷＥＢ ＳＷＩＴＣＨのようなウェブスイッ
チである。トラフィックマネージャ１２０は、各ウェブページリクエストを受信
し、リクエストに基づいて、リクエストをウェブサーバに向ける。

【００３４】 また、ウェブサービスシステム９０は、コンテンツディストリビュータ１２５
とも呼ばれるバージョンコントローラを含む。コンテンツディストリビュータ１
２５は、ウェブサービスシステム９０内の様々なウェブサーバ１０２上のコンテ
ンツの更新を含むバージョンおよびコンテンツ複製を管理する。コンテンツディ
ストリビュータ１２５のシステムオペレータインターフェースは、コンテンツコ
ントロール１２６によって提供される。１つの実施形態において、コンテンツデ
ィストリビュータ１２５およびコンテンツコントロール１２６は、それぞれ、ホ
スト１００上で動作するスタンドアロンのプロセスである。他の実施形態におい
て、コンテンツディストリビュータ１２５およびコンテンツコントロール１２６
は、マネージャ１１０と同じホストで動作する。他の実施形態において、コンテ
ンツディストリビュータ１２５およびコンテンツコントロール１２６は、他のホ
スト上で動作する。コンテンツディストリビュータ１２５とコンテンツコントロ
ール１２６とは、同じホスト上で動作してもよいし、異なるホスト上で動作して
もよい。他の実施形態において、コンテンツディストリビュータ１２５は、マネ
ージャ１１０、またはシステム９０の他の構成要素の機能に組み込まれ得る。

【００３５】 コンテンツディストリビュータ１２５は、情報をエージェント１０６に送信し
、エージェント１０６を通じてウェブサーバインターフェース１０４に送信する
。送信された情報は、ソースファイルと呼ばれ、概して、階層ディレクトリ構造
に編成される、コンテンツディレクトリおよびファイルのセットの変更点を記述
する。これらのソースファイルは、ウェブサーバ用のコンテンツの「マスター」
コピーである。ディレクトリおよびファイルは、共に、概して、ソースファイル
またはソースファイルセットと呼ばれる。ソースファイルセットは、ステージン
グサーバとも呼ばれるソースホストに格納され得る。ステージングサーバは、典
型的には、コンテンツディストリビュータ１２５が実行しているホストであるが
、必ずしもそうでなくてもよい。説明を簡略にするため、以下の説明において、
コンテンツディレクトリおよびファイルは、ソースファイルであっても、ホスト
１００上であっても、概して、単にファイルと呼ばれる。ソースファイルセット
は、ディレクトリおよびファイルの両方を含み得、また、ファイルの変更点は、
ディレクトリの追加、削除、および変更を含み得る。

【００３６】 図３を参照すると、ある程度の期間にわたって、ソースファイルセットに対し
て変更が行われる（工程１８０）。行われる変更には、新しいファイルの作成、
古いファイルの削除、現存するファイルを新しいコンテンツで置換（すなわち、
ファイル内容の変更）、ならびに、許可制限および所有権のようなファイル属性
を変更することが含まれる。また、ファイルの変更について説明する場合でも、
ディレクトリの変更も含まれるように意図される。変更は、アプリケーションプ
ログラムおよびオペレーティングシステムユーティリティを含む、当該技術にお
いて公知である、このような編集技術およびツールを用いて、ファイルを編集す
ることによって行われる。変更は、テストされ、発展および承認プロセスにおい
て承認され得る。実際には、特定の時間では、ファイルの変更点がない場合があ
り、システムは、これを識別し得る。このような場合、変更点がないことが識別
された後、次の起こり得る変化が識別されるまで、さらなる処理が行われない。

【００３７】 コンテンツディストリビュータは、ファイルの変更点を識別する（工程１８１
）。ファイルの変更は、多数の方法で識別され得る。１つの実施形態において、
コンテンツ設計者は、変更点のリストである、マニフェストを提供する。設計者
は、例えば、コンテンツコントロールユーザインターフェース１２６を用いて、
または、マニフェストをコンテンツディストリビュータ１２５に通信することに
よって、変更点を把握し、コンテンツディストリビュータへの変更を手動で識別
する。他の実施形態において、設計するためにコンテンツ設計者によって用いら
れるソフトウェアおよびシステムは、変更点をたどり、コンテンツディストリビ
ュータ１２５に通信される変更点のマニフェストを提供する。

【００３８】 他の実施形態において、コンテンツディストリビュータ１２５は、オペレーテ
ィングシステムファイルサービスと一体化し、ソースファイルセットへの変更点
を監視する。このような実施形態の１つにおいて、オペレーティングシステムに
よって呼び出される、ソフトウェアデバイスドライバ「モニタ」がインストール
されて、ファイルオペレーションが行われる。デバイスモニタは、オペレーティ
ングシステムと実際のデバイスドライバ（すなわち、ハードディスクドライバソ
フトウェア）との間でデータを通過させるパススルー（ｐａｓｓ ｔｈｒｏｕｇ
ｈ）デバイスドライバとして機能を果たす。ディスクドライバを通じてディスク
Ｉ／Ｏコマンドを通過させることに加えて、デバイスモニタは、それらのＩ／Ｏ
コマンドを観察し、ソースファイルセットの変更点を記録する。１つの実施形態
において、デバイスモニタは、コンテンツディストリビュータ１２５と一体化さ
れる。他の実施形態において、デバイスモニタは、コンテンツディストリビュー
タ１２５に通信されたマニフェストを生成する。

【００３９】 さらに別の実施形態において、コンテンツディストリビュータ１２５は、現在
のソースファイルセットと以前のソースファイルセットとの比較を行って、ソー
スファイルセットの変更点を判定する。コンテンツディストリビュータは、比較
のため、最後に更新されたときに存在したファイルのリストを維持する。このリ
ストには、ファイル名と、ファイルサイズ、ファイルが最後に変更された日付／
時間、コンテンツのハッシュコード、許可および／またはアクセスコントロール
制限、ユーザ／グループ所有権のような、他のファイル特性とが含まれる。１つ
の実施形態において、ファイルのリストは、以前のソースファイルセットにおけ
る全てのファイルの完全なコピーを含むが、大きなファイルシステムについては
、この実施形態は非効率的である。より効率的な実施形態において、以下で説明
するように、以前のファイルのリストおよび特定のファイル属性のみが必要とさ
れる。変更点を識別する工程（工程１８１）、変更点を送信する工程（工程１８
２）、および変更点をインストール工程（工程１８３）は、更新と呼ばれること
もある。

【００４０】 図４を参照すると、１つの実施形態において、ソースファイルと以前のソース
ファイルセットとの比較は、ソースファイルセット内のファイル（およびディレ
クトリ）の解析によって行われる。ソースファイルセット内の各ファイルについ
て（工程１９０）、コンテンツディストリビュータは、ソースファイルセット内
のファイルを、１つの実施形態において、上述したリストの形態である、以前の
ソースファイルセットを記述する情報と比較する。各ファイルについて、コンテ
ンツディストリビュータは、ファイルが以前のソースファイルセットリスト内に
あるかどうか判定する（工程１９１）。以前のソースファイルセットリスト内に
ない場合、ファイルは新たなファイルとしてリストに挙げられ（工程１９２）、
このファイルがソースファイルセットに追加されたことが示され、ファイルでハ
ッシュが計算される（工程１９３）。ファイルがリストに挙げられる場合、ファ
イルリスト項目がマークされて（工程１９４）、ファイルが依然ファイルセット
に含まれていることを示す。これは、後に、以前のリストのファイルがなくなっ
ている、すなわち、削除されたものがあるかどうか判定するために用いられる。

【００４１】 ファイルのサイズは、リスト内の情報と比較される（工程１９５）。ファイル
サイズが異なる場合、このファイルは修正されたと考えられ、このようにリスト
に挙げられる（工程１９６）。ファイルの新たなハッシュが、計算され、リスト
に格納される（工程１９３）。サイズが同じである場合、日付／時間が比較され
る（工程１９７）。日付／時間が異なる場合、ファイルのハッシュは、計算され
、以前のリストに含まれるハッシュと比較される（工程１９８）。このコンテキ
ストにおいて、ハッシュは、ファイルのコンテンツについて行われ、ファイルコ
ンテンツに関連する単一の数が得られる計算である。このようなハッシュは、メ
ッセージ完全性コードとも呼ばれる。ハッシュコードの例として、チェックサム
および周期的冗長コードがある。ファイルのハッシュが異なる場合、このファイ
ルは、修正されたとしてリストに挙げられ（工程１９６）、新たなハッシュがリ
ストに格納される（工程１９３）。そうでない場合、ファイル属性（オーナー、
グループなど）が変更された場合（工程１９９）、ファイルは、修正された属性
を有するものとしてリストに挙げられる（工程２００）。

【００４２】 １つの実施形態において、ファイルコンテンツが変更されていない場合、シス
テムはまた、ファイル属性が変化していないかどうかを判定する（工程１９９）
。他の実施形態において、属性情報は、コンテンツ更新の一部として送信される
。これらの工程が、ソースファイルセット内の全てのファイルについて完了した
場合、工程１９４からのマーキングは、以前にリストに挙げられたファイルがな
くなっている、すなわち、ファイルセットから削除されたものがあるかどうかが
調べられる（工程２００）。マークされていないファイルは、削除されたとして
リストに挙げられる（工程２０２）。

【００４３】 ソースファイルセットの変更点は、マニフェストとも呼ばれる変更点リスト内
にあることが、コンテンツディストリビュータ１２５に知らせられる（ｉｄｅｎ
ｔｉｆｙ）。１つの実勢形態において、追加、削除、コンテンツ修正、および／
または属性修正のような、ファイルの変更点を示す項目を含む。例えば、追加ス
テートメント「ＡＤＤ ｓｏｕｒｃｅ／ｄｉｒ／ｄｉｒ／ｆｉｌｅ １」は、フ
ァイル１が追加されたことを示し、ステートメント「ＣＨＭＯＳ ｓｏｕｒｃｅ
／ｆｉｌｅ ２」は、「ｆｉｌｅ２」に関連する許可が変更されたことを示す。
例えば、他のステートメントには、ファイルの除去を示す「ＤＥＬＥＴＥ」、お
よびコンテンツの変更を示す「ＭＯＤＩＦＹ」が含まれる。また、さらなる属性
の違いは、ＣＨＭＯＤステートメントを用いるか、または、所有権変更について
のＣＨＯＷＮ、またはグループ関連の変更についてのＣＨＧＲＰのような、自身
の特有ステートメントを有する。

【００４４】 図５を参照すると、１つの実施形態において、マニフェストエントリー３００
は、少なくとも８つの情報要素３０１〜３０８を含む。１つの実施形態において
、各エントリーは、テキストフォーマットで格納されるので、情報は、シンプル
テキストエディタでシステムオペレータによって読み出され得るか、他のソフト
ウェアによって翻訳され得る。他の実施形態において、各エントリーは、テキス
トフォーマットと同様に、同じ情報を含むが、よりコンパクトな２進数形式で格
納される。２進数形式は、変換ツールで、テキストフォーマットに変換され得る
。また、テキストフォーマットは、２進数形式に変換され得る。

【００４５】 １つの実施形態において、マニフェストエントリー３００は、ファイルタイプ
フィールド３０１を含む。可能なファイルタイプは、ディレクトリ、ファイル、
記号リンク、ハードリンク、または、ディレクトリ内の最後のファイルの後に来
るエンドオブディレクトリマーカーである。テキストフォーマットの実施形態に
おいて、各ファイルは、ディレクトリの「ＤＩＲ」、エンドオブディレクトリマ
ーカーの「ＥＮＤ」、通常ファイルの「ＮＲＭ」、記号リンクの「ＬＮＫ」、お
よびハードリンクの「ＨＬＫ」のような３文字コードで記述される。２進数形式
の実施形態において、各選択肢は、整数コードによって表される。例えば、１つ
の実施形態において、ディレクトリは、数字１で表され、ファイルは２で表され
、以下同様に続く。

【００４６】 また、マニフェストエントリー３００は、取得されるアクションフィールド３
０２を含む。テキストフォーマットの実施形態において、取得されるアクション
は、追加されるファイルの「ＡＤＤ」、変更されたコンテンツの「ＣＨＧ」、変
更されたオーナー、グループ、または許可の「ＣＨＰ」、削除されたファイルの
「ＤＥＬ」のような３文字コードである。３文字コード「ＮＯＣ」は、ファイル
が変更されてないことを記述するために用いられる。２進数形式の実施形態にお
いて、各選択肢は、整数コードによって表される。例えば、１つの実施形態にお
いて、追加されたファイルは、数字１で表され、変更されたコンテンツは、２で
表され、以下同様に続く。

【００４７】 また、マニフェストエントリー３００は、ファイルアクセス許可、およびファ
イルについての他の情報を記述する、許可フィールド３０３を含む。テキストフ
ォーマットの実施形態において、ＵＮＩＸ（登録商標）形式で、４つの３項目バ
イナリ入力（すなわち、ｒｗｘｒｗｘｒｗｘ）として、許可は格納される。ここ
で、第１の３項目バイナリ入力は、実行可能プログラムがユーザとして実行され
るかどうかを記述し、続く３つの入力は、それぞれ、オーナー、グループ、およ
びパブリックの読み出し、書き込みおよび実行許可を示す。バイナリ実施形態に
おいて、許可情報は、許可を表す４桁の８進数である、バイナリ整数として格納
される。

【００４８】 また、マニフェストエントリー３００は、ファイルのサイズを記述するファイ
ルサイズフィールド３０４を含む。テキストフォーマットの実施形態において、
ファイルサイズは、ＡＳＣＩＩ文字で書かれる。２進数形式の実施形態において
、ファイルサイズは、整数として格納される。

【００４９】 また、マニフェストエントリー３００は、日付／時刻スタンプ３０５を含む。
テキストフォーマットの実施形態において、日付および時刻は、ＡＳＣＩＩ文字
で書かれる。２進数形式の実施形態において、日付／時刻は、１９７０年１月１
日深夜からの秒数を表す整数として格納される。

【００５０】 また、マニフェストエントリー３００は、所有権情報３０６を含む。この情報
は、２つの部分、ファイルオーナーのユーザ識別子、およびグループオーナーの
グループ識別子を含む。テキストフォーマット実施形態において、オーナーおよ
びグループ識別子は、ＡＳＣＩＩストリングとして格納される。２進数形式の実
施形態において、オーナーおよびグループ識別子は、整数として、それぞれ格納
される。

【００５１】 また、マニフェストエントリー３００は、チェックサム３０７またはハッシュ
結果を含む。テキストフォーマットの実施形態において、これは、ＡＳＣＩＩス
トリングとして格納される。また、マニフェストエントリーは、ファイルの相対
パス名３０８を含む。テキストおよび２進数形式の両方の実施形態において、相
対パス名３０８は、ＡＳＣＩＩストリングとして格納される。

【００５２】 図６を参照すると、変更点の例示的なリストに、追加されたファイルａａａ（
ディレクトリである）、ディレクトリａａａのファイルａｇｅｎｔ．ｒｅｇ、ｑ
ｕｅｓｔｄ．ｒｅｇ、およびｓｑｌｓｅｒｖｅｒ．ｒｅｇ、ならびに、同様にデ
ィレクトリであるファイルｂｂｂおよびｃｃｃが示されている。ディレクトリｄ
ｄｄと、ディレクトリｄｄｄ内のファイルａｂｃおよびｅｆｇは、変更されてい
ない。また、ディレクトリｅｆｇも変更されていない。ディレクトリｍｍｍ、ｘ
ｘｘ、およびｙｙｙは削除され、ファイルａｇｅｎｔ．ｒｅｇ、ｑｕｅｓｔｄ．
ｒｅｇ、およびｓｑｌｓｅｒｖｅｒ．ｒｅｇはディレクトリｘｘｘから削除され
ている。

【００５３】 図７を参照すると、図５のフォーマットのマニフェストのテキストフォーマッ
トの実施形態の一例は、図６でリストに挙げられた変更点を反映させている。第
１の入力、ＥＮＴＲＹ１において、ディレクトリａａａは、ファイル名３０８に
おいてリストに挙げられている。ファイルａａａは、タイプ３０１「ＤＩＲ」と
してリストに挙げられる。このファイルのアクション３０２は、「ＡＤＤ」であ
り、ファイルが追加されたことを示す。許可３０３は、ＵＮＩＸ（登録商標）形
式でリストに挙げられ、ファイルがディレクトリであること、オーナーが許可を
読み出し、書き込み、実行することを示す。ファイルサイズ３０４は、０として
リストに挙げられる。ファイルの日付／時刻スタンプ３０５は、５月２７日１７
：１２としてリストに挙げられる。ユーザおよびグループ識別子３０６は、両方
とも、識別子０としてリストに挙げられる。ファイル３０７のチェックサムは、
０である。

【００５４】 第２の入力、ＥＮＴＲＹ２において、ファイル名３０８においてリストに挙げ
られるファイルは、ａｇｅｎｔ．ｒｅｇである。このファイルは、ａｇｅｎｔ．
ｒｅｇである（Ｔｈｉｓ ｆｉｌｅ， ａｇｅｎｔ．ｒｅｇ．）。ＥＮＴＲＹ２
が、ａａａディレクトリ入力（ＥＮＴＲＹ１）および終了ステートメント（ＥＮ
ＴＲＹ５）の間にあるので、このファイルは、ディレクトリａａａの中にある。
ファイルａｇｅｎｔ．ｒｅｇは、通常のタイプ３０１であり、アクション要素３
０２において示すように、新たなファイルとして追加される。許可３０３は、オ
ーナーが許可を読み出し、書き込んだことを示す。ファイルサイズ３０４は、５
６９バイトである。ファイルの日付３０５は、１９９８年５月１１日である。ユ
ーザおよびグループ識別子３０６は、両方とも０である。チェックサム３０７は
、３５６４８８６２２０である。

【００５５】 第５の入力、ＥＮＴＲＹ５は、ディレクトリａａａのリスト項目の最後を示す
、タイプ３０１終了マーカーである。第６の入力、ＥＮＴＲＹ６について、ディ
レクトリｂｂｂは、ａａａ終了マーカーの後にリストに挙げられているので、ａ
ａａのサブディレクトリではない。

【００５６】 再度、図３を参照すると、１つの実施形態において、コンテンツディストリビ
ュータは、例えば、図４の方法を用いて変更点を判定することによって、マニフ
ェストを作成する。他の実施形態において、マニフェストは、コンテンツディス
トリビュータに通信される。１つの実施形態において、マニフェストは、マニフ
ェストを特定の位置（すなわち、ディレクトリおよびファイル名）に格納するこ
とによって通信され、コンテンツディストリビュータは、それを見出すように設
定される。他の実施形態において、マニフェストは、ネットワークを介してコン
テンツディストリビュータ１２５にはっきりと送信することによって、コンテン
ツディストリビュータに通信される。

【００５７】 変更点が識別された後（工程１８１）、例えば、図３の実施形態を用いて、変
更点が、エージェントに送信される（工程１８２）。しばしば、変更点は、ホス
トファイルシステムの特定のディレクトリにマッピングされる。１つの実施形態
において、ソースファイルセットは、表１の実施例に示すように、様々なホスト
のファイルシステムにマッピングされる。

【００５８】

【表１】 表１から明らかであるように、システム管理者は、ソースファイルセット内のフ
ァイルを、ステージングサーバファイルシステムから、様々なウェブサーバのフ
ァイルシステムにマッピングし得る。ＵＲＬではなく、実際のファイルシステム
識別子を用いることによって、ユニフォームリソースロケータ（「ＵＲＬ」）で
識別可能でない、共有のライブラリおよび他のファイルのマッピングが可能にな
る。例えば、ＣＧＩスクリプトは、ウェブサーバからウェブページリクエストを
介して、このようなファイルが、概して利用可能でないのでＵＲＬが用いられる
場合、マッピングされず、ＵＲＬを有さない。ファイルシステム識別子の代わり
に、ＵＲＬを用いることが可能なので、修正され得るファイルのタイプの制限に
おけるトレードオフ以外において、マッピングは必要ない。ＵＲＬが用いられる
場合、ウェブサーバからウェブページリクエストを介してアクセス可能なファイ
ルのみがアクセス可能である。

【００５９】 １つの実施形態において、ソースファイルセットディレクトリ階層内のファイ
ルは、単一のアーカイブファイルに結合され、そのアーカイブファイルは、圧縮
される。設定可能な値より大きい任意のファイルは、ネットワークを介するホス
トシステムまでの通信をより効率的にし、ネットワークへの影響を低減するよう
に、より小さいブロックに分割される。ファイルをより小さいブロックに分割す
ることによって、タイムアウトの場合における再送信の量が最小化される。この
ような設定可能な値の例は、１メガバイトである。

【００６０】 変更されたファイルのファイルサイズを含む変更点リスト（マニフェスト）は
、コンテンツを受け取るべき各エージェントに送信される。エージェントは、変
更リストにおけるファイルサイズおよびエージェントが認識している、行わなけ
ればならない計算に基づいて、更新のために十分なディスクの空き容量があるか
どうかを判定する。例えば、エージェントは、ファイルシステム内に、コンテン
ツ更新の圧縮されたコピー、および圧縮されてないデータのコピーを２つ、すな
わち、一時コピーおよび格納されるべきコピーを格納する、十分な場所があるか
どうかを判定し得る。このようにして、エージェントは、ホストが新たなコンテ
ンツによって負荷を掛けられ過ぎるようになる前に、転送を中止することができ
る。

【００６１】 所定の数のサーバが、更新されたコンテンツを受信することに同意する場合、
データは、コンテンツディストリビュータからエージェントに送信される。多く
のエージェントが、コンテンツを受信することができない場合、コンテンツディ
ストリビュータは、ジョブを中止し得る。転送を行うために必要なエージェント
の率は、設定可能である。例えば、システムオペレータは、５０％のエージェン
トが変更を受け入れることが可能になるまで転送が行われてはならないことを決
定し得る。このようにして、更新されたコンテンツを有するサーバの数が少なす
ぎることが防がれる。

【００６２】 １つの実施形態において、転送は、ファイル転送プロトコル（「ＦＴＰ」）の
ような標準ＴＣＰ／ＩＰ転送を用いて行われる。他の実施形態において、転送は
、信頼できるマルチキャストプロトコルを用いて行われる。送信失敗がある場合
、データのブロックが再送信される。転送が繰り返し失敗する場合、転送は中止
され、システムオペレータへの警告を含む様々なアクションが取られ得る。また
、コンテンツディストリビュータは、予測されない環境に起因して、転送におい
て成功するエージェントが予期されていた数より少ない場合、変更点のインスト
ールを中止し得る。例えば、多くのエージェントが、ネットワーク接続性を失う
場合、新たなコンテンツの役に立つように利用可能なエージェントの数が不十分
であることが起こり得る。

【００６３】 再度図１を参照すると、特定のエージェント１０６について更新が失敗する場
合、ウェブサービスシステム９０は、システムの影響された部分を「避けて通る
（ｒｏｕｔｅ ａｒｏｕｎｄ）」ように試みる。コンテンツディストリビュータ
がマネージャとは別である実施形態において、コンテンツディストリビュータ１
２５は、エージェント１０６が失敗したことをマネージャ１１０に知らせる。マ
ネージャ１１０は、トラフィックマネージャ１２０と通信し、トラフィックマネ
ージャは、そのエージェント１０６と通信するウェブサーバ１０２にウェブペー
ジリクエストを向けない。また、マネージャ１１０は、ウェブサーバ１０２から
他のサーバにトラフィックを向け得る。

【００６４】 １つの実施形態において、コンテンツディストリビュータ１２５は、失敗した
宛先エージェントを目標とする、「追い上げ（ｃａｔｃｈ−ｕｐ）」更新パッケ
ージを作成する。追い上げ更新パッケージは、エージェントに達する必要がある
が、達していない変更点を含む。初期的に、これは、第１の更新から、送信にお
いて失敗する、変更点のリストである。この追い上げ更新パッケージは、連続的
な更新が同じエージェントに達することを失敗する場合でも、増大し得る。更新
パッケージが失敗する場合、以前に伝送が失敗した変更点についての新たな更新
から依存し得るので、エージェントは、「追い上げ」更新が完了するまで他の更
新を受信しない。

【００６５】 再度図３を参照すると、変更点がエージェント１８２に送信された後、変更点
がインストールされる（工程１８３）。エージェント１０６およびウェブサーバ
インターフェース１０４は、協力して、コンテンツをインストールする。新たな
コンテンツが受信される場合、エージェントは、更新パッケージを、再度組み立
て、その後、解凍し、データを一時データ格納に位置付ける。その後、エージェ
ントは、コンテンツディストリビュータからの信号を待って、サーバコンテンツ
ディレクトリへのファイルのコピーを開始する。信号が受信される場合、サーバ
コンテンツディレクトリで変更が行われる。また、削除するようにリストに挙げ
られた任意のファイルが、このとき除去さえる。更新が成功する場合、エージェ
ントは、ファイルの更新において成功したことをコンテンツディストリビュータ
に知らせる。１つの実施形態において、コピーは、単純な上書きによって達成さ
れる。他の実施形態において、古いファイルは、まず、再命名され、かつ／また
は、代替的なディレクトリに格納される。これによって、変化が素早く入れ替え
られるが、より多くのデータ格納を必要とするというトレードオフがある。何ら
かの理由でコピーが失敗する場合、エージェントは、コンテンツディストリビュ
ータに問題を警告する。エージェントまたはコンテンツディストリビュータのい
ずれかは、マネージャにも警告し、マネージャは、トラフィックマネージャに、
失敗したエージェントを避けるように指令し得る。１つの実施形態において、エ
ージェントは、ウェブサーバのコンテンツ状態を示すバージョン識別子を維持す
る。１つの実施形態において、バージョン識別子は、整数値である。

【００６６】 １つの実施形態において、ウェブサーバは、更新プロセスの間、一時停止また
は停止する。ウェブサーバコンテンツディレクトリにファイルがコピーされる場
合、ウェブサーバは、リクエスタが首尾一貫していないコンテンツを受信するこ
とを避けるために、ウェブページリクエストの処理を止められる。ウェブサーバ
は、コンテンツ更新プロセスの間にユーザを向け直すように調節される。これは
、トラフィックマネージャがリクエストをそのウェブサーバに転送しないように
命令するマネージャによって、達成される。同時に、そのウェブサーバ１０２に
達するリクエストは、ウェブサーバインターフェース１０４によって、そのウェ
ブサーバ１０２から、トラフィックマネージャ１２０または他のウェブサーバ１
０２に転送され得る。トランザクションの最中のユーザは、転送される前にトラ
ンザクションを完了するため、所定の長さの時間を与えられ得る。ウェブサーバ
が、リクエスタを除く場合、更新が起こる。アプリケーションバイナリファイル
が、変更されない場合、ウェブサーバは、リクエスタを除き得、リクエスタは、
コンテンツ転送が完了した後、サーバに向けられ得る。しかしながら、アプリケ
ーションバイナリファイルが修正された場合、ウェブサーバは再開される必要が
あり得る。

【００６７】 いくつかの場合において、コンテンツを更新するために、ウェブサーバをディ
セーブルすることが可能でないこともある。一時的なブラウザの再方向付けのプ
ロセスは、非常に時間が掛かり得、その場合、ファイルの転送およびウェブサー
バの更新に必要な時間と共に、容認できないほど長い。サーバの利用可能性を最
大限にするため、コンテンツは、ウェブサーバがリクエストに応答し続ける間、
更新され得る。これは、変更されるファイルのコピーを作成し、これらのファイ
ルのコピーをウェブサーバにアクセス可能な場所に入れることによって、達成さ
れる。エージェントは、ウェブサーバインターフェースに、変更されているファ
イルについての全てのリクエストを遮らせる。変更していないファイルについて
のリクエストは、通常のコンテンツ領域に向けられ得る。変更しているファイル
についてのリクエストは、代わりに、安定コピー（ｓｔａｂｌｅ ｃｏｐｙ）に
向けられ得、新たなファイルが、通常の領域にインストールされる。エージェン
トがファイルの修正を完了した後、ウェブサーバインターフェースは、通常領域
を再度用いるように信号送信され得る。古いコンテンツから新たなコンテンツへ
の転換の時に、関連するウェブページのシリーズに関わるトランザクションに関
わるユーザは、転換の後しばらく、トランザクションが完了するまで、「古い」
コンテンツにアクセスし続ける必要を有し得る。例えば、第１の価格で購入する
最中のユーザは、更新された異なる価格を用いるウェブページとのトランザクシ
ョンを完了すべきではない。

【００６８】 １つの実施形態において、トランザクションの完全性を確実にするため、転換
のたびに、バージョン識別子が割り当てられる。１つの実施形態において、チェ
ックポイント識別子とも呼ばれるバージョン識別子は、コンテンツ更新ごとに増
分されることによって変更される整数である。ウェブサーバインターフェースは
、ブラウザによって予期されるバージョンに基づいて、ウェブページリクエスト
を遮り、そのバージョンのコンテンツを提供する。このことを行うために、ウェ
ブサーバは、ブラウザによって所望されるバージョンを知る必要がある。１つの
実施形態において、この情報は、ＵＲＬに含まれる。しかし、これは、ＵＲＬお
よびより複雑なファイル構造の作成という不利な点を有する。また、バージョン
変更点は、ユーザにとって、あまり意識されない。

【００６９】 １つの実施形態において、ウェブサーバは、サーバによってブラウザに供給さ
れるページのその後−現在（ｔｈｅｎ−ｃｕｒｒｅｎｔ）バージョンを特定する
バージョン識別子を含むブラウザに、クッキーを発行する。クッキーは、ウェブ
サーバがブラウザに送信するので、ウェブサーバがそのブラウザについて何かを
「記憶する（ｒｅｍｅｍｂｅｒ）」ことができる特別なテキストファイルである
。ウェブのハイパーテキスト転送プロトコル（ＨＴＴＰ）を用いることによって
、ウェブページのリクエストの各々は、全ての他のリクエストから独立する。こ
のため、クッキーのようなメカニズムなしには、ウェブサーバは、以前にブラウ
ザに送信したページがどれかということも知らないか、または、ブラウザの以前
の訪問について何も知らない。クッキーは、サーバがブラウザについての自身の
情報をブラウザ自身のコンピュータに格納し、ユーザがウェブページリクエスト
を行う場合、その情報にアクセスすることを可能にするメカニズムである。クッ
キーには、有効な持続期間が提供され得る、すなわち、ある程度の時間の後、ブ
ラウザによって廃棄される。

【００７０】 １つの実施形態において、このようなクッキーの一例が、コード、「Ｓｅｔ−
Ｃｏｏｋｉｅ：ＡｔｒｅｖｅＢＣＤ＝３７；ｅｘｐｉｒｅｓ＝Ｔｈｕｒｓｄａｙ
，２０−Ｊａｎｕａｒｙ−１９９９ １２：３２：３４ ＧＭＴ；ｐａｔｈ＝／
」として実現される。このコードは、ウェブサーバからブラウザに送信される。
ブラウザは、同じドメインにおいてウェブサーバと通信する場合、１９９９年１
月２０日の１２：３２：３４ ＧＭＴまで、任意のパスへの全てのリクエストに
ついて「Ｃｏｏｋｉｅ：ＡｔｒｅｖｅＢＣＤ＝３７」という行を含む。プロトコ
ルの「Ｓｅｔ−Ｃｏｏｋｉｅ」および「Ｃｏｏｋｉｅ」部分は、ＨＴＴＰ規格に
よるヘッダである。「ＡｔｒｅｖｅＢＣＤ」は、クッキーの名前である。Ａｔｒ
ｅｖｅＢＣＤはデフォルトなので、任意の他の名前が用いられ得る。「３７」は
、サーバが、終了時まで、現在、および将来（ウェブサーバインターフェースの
せいで）において提供し続けるチェックポイントである、クッキーの値である。
コード「終了」は、終了時を設定する。この例において、終了時は、１９９９年
１月２０日である。「Ｐａｔｈ」コードは、どのページがクッキーを与えるかを
制限するために用いられ得るが、「／」は、全てのファイルを含むことを示す。

【００７１】 ウェブサーバがブラウザに発行するクッキーは、ウェブサーバから、ブラウザ
がコンテンツをリクエストすることを効率的に可能にし、そのコンテンツについ
てのバージョン識別子を示す。従って、ブラウザが特定のＵＲＬを特定する特定
のクッキーで、６つのリクエストを作成する場合、これらの６つのリクエストは
、エージェントがその間に新たなバージョンのコンテンツをウェブサーバ１０２
に配信した場合にさえ、自己矛盾がない。

【００７２】 １つの実施形態において、より早いコンテンツは、そのコンテンツを特定する
全てのクッキーが廃棄されるまで、廃棄されない。コンテンツは、１つのバージ
ョンから次のバージョンへの変更点を含む「バックアップ」領域に格納される。
例えば、バージョン２からバージョン３への移行において変更するファイルは、
バージョン２−３バックアップ領域に格納される。ウェブサーバインターフェー
スは、バージョン２からバージョン３への移行で変更されたバージョン２のウェ
ブページリクエストを、適切なバックアップ領域における適切なコンテンツに向
ける。

【００７３】 図８を参照すると、簡略化された例において、ウェブサーバは、３４の現在の
バージョン識別子を有するコンテンツを有する。クッキーが依然有効である以前
のバージョンは、バージョン３３および３２である。現在のバージョン、バージ
ョン３４は、バージョン３４において修正されたファイルＡおよびＢ、バージョ
ン２８において修正されたファイルＣ、バージョン２５において修正されたファ
イルＤを含む。ファイルＡは、図に示す全てのバージョン（バージョン３２、バ
ージョン３３、およびバージョン３４を含む）において修正された。ファイルＢ
は、バージョン３０、バージョン３２、上述したように、バージョン３４におい
て修正された。従って、バージョン３１からバージョン３２への変更は、ファイ
ルＡおよびＢの変更点、バージョン１で作成されたファイルＥの削除を含む。従
って、バージョン３１からバージョン３２への移行において変更されたファイル
を含む３１−３２バックアップ領域には、ファイルＡのバージョン３１、ファイ
ルＢのバージョン３０、ファイルＥのバージョン１が格納されている。バージョ
ン３２からバージョン３３への変更には、ファイルＡの修正が含まれるので、３
２−３３バックアップ領域には、ファイルＡのバージョン３２が格納されている
。バージョン３３からバージョン３４への変更には、ファイルＡおよびＢの修正
、およびファイルＦ（バージョン１０で追加）の削除が含まれるので、３３−３
４バックアップ領域において、ファイルＡのバージョン３３、ファイルＢのバー
ジョン３２、ファイルＦのバージョン１０が格納される。

【００７４】 例えば、現在のバージョン以外のコンテンツバージョンを示すクッキーを提示
することによって、ウェブサーバがコンテンツをリクエストする場合であって、
古いチェックポイントと現在のチェックポイントとの間でファイルが変更される
場合、ウェブサーバインターフェースは、ウェブサーバに現在のバージョン領域
以外の領域からコンテンツを取らせ得る。１つの実施形態において、ウェブサー
バインターフェースは、変更点リストを再び見て、リクエストされたファイルが
変更されたかどうか判定し、変更されている場合、どのバックアップ領域に位置
するかを判定する。例えば、現在のバージョンがバージョン３４である、図８の
例をまた参照すると、ウェブサーバがファイルＡのリクエストを受信し、クッキ
ーはブラウザがバージョン３２を探していることを示す場合、ウェブサーバイン
ターフェースは、バージョン３３の一部として、ファイルＡが修正されたことが
わかる。従って、ファイルＡのバージョン３２は、３２−３３バックアップ領域
に位置する。ウェブサーバが、同じブラウザから（同じバージョン３２クッキー
で）ファイルＢのリクエストを受信する場合、ウェブサーバインターフェースは
、バージョン３４でファイルＢが修正され、ファイルＢのバージョン３２が３３
−３４バックアップ領域に格納されたと判定する。ウェブサーバがファイルＤの
リクエストを受信する場合、ウェブサーバインターフェースは、ファイルがバー
ジョン３２から修正されておらず、そのファイルが現在のバージョン領域から入
手され得ることを判定する。

【００７５】 １つの実施形態において、コンテンツディストリビュータは、特定の時間また
は時間間隔に対するソースファイルセット変更点のスケジューリングされた更新
に備える。コンテンツディストリビュータは、システムオペレータの手動コマン
ドでも、更新し得る。１つの実施形態において、更新は、ファイルがどこからコ
ピーされる必要があるか（すなわち、ソースファイルセット）、どこにコピーさ
れる必要があるか（すなわち、ファイルサーバのファイルシステム）を示すコン
テンツマッピング、更新がいつ起こるかを示す開始／日付時間または時間間隔、
（上述したように）変更されたファイルのみが更新される必要があるか、または
全てのファイルがコピーされる必要があるかどうか、失敗の場合に取られる必要
があるアクション、コンテンツの更新においてサーバが再開される必要があるか
どうか、コンテンツの更新の間にサーバが一時停止または停止する必要があるか
どうか、更新が（システムオペレータがスケジューリングされた更新をディセー
ブルすることを可能にするように）イネーブルまたはディセーブルされるかどう
か、ならびに、サーバが変更を行うように命令される前に更新を許容する必要が
あるサーバの率によって、特定される。１つの実施形態において、更新は、ジョ
ブと呼ばれる。

【００７６】 例えば、１０分ごとに実行して、変更したファイルを更新し、任意の問題をシ
ステムオペレータに知らせる更新を特定することが可能である。また、月に１度
、更新を特定することも可能である。１つの実施形態において、システムは、フ
ァイルをコピーする間はサーバをオフにし、全ての変更されたファイルを更新し
、コンテンツが更新された場合、サーバを再開する。

【００７７】 図９を参照すると、いくつかのウェブサービスシステム９０は、関連付けられ
た１つ以上のキャッシュサーバ２００を有する。キャッシュサーバ２００は、リ
クエスタ２０１（例えば、ブラウザ）とウェブサービスシステム９０の間に位置
するウェブサーバのタイプである。キャッシュサーバ２００は、初期的には、い
ずれのコンテンツも有さない。それよりは、リクエスタ２０１からの命令でウェ
ブページをリクエストし、ウェブページをそのキャッシュに格納する。市販され
ているキャッシュサーバの一例として、Ｓａｎｔａ Ｃｌａｒａ， Ｃａｌｉｆ
ｏｒｎｉａのＮｅｔｗｏｒｋ Ａｐｐｌｉｃａｎｃｅ，Ｉｎｃ．製のＮＥＴＣＡ
ＣＨＥ製品がある。キャッシュサーバ２００は、ブラウザ２０１から、ウェブサ
ービスシステム９０に位置するコンテンツのウェブページリクエストを受信する
。リクエストおよび自身の設定に基づいて、キャッシュサーバ２００は、ウェブ
ページを有する元のウェブサーバ（ウェブサービスシステム９０）から、ウェブ
ページをリクエストする。キャッシュサーバ２００は、元のウェブサーバ９０か
ら、ウェブページを受信し、ブラウザ２０１にウェブページを送信する。また、
キャッシュサーバ２００は、所定の期間、そのウェブページを格納する。ページ
が格納される期間は、コンテンツプロバイダ（元のウェブサービスシステム９０
）によって、例えば、ＨＴＴＰプロトコルに従って文書の送達の終了期間を特定
することによって、またはキャッシュサーバ２００システム管理者のいずれかに
よって、決定される期間である。第２のリクエストが、同じリクエスタ２０１、
または異なるリクエスタから、終了期間の前にキャッシュサーバ２００に到達す
る場合、キャッシュサーバは、元のサーバからコンテンツをリクエストすること
なしに、リクエストに応答して、ウェブページを再送信し得る。従って、リクエ
ストは、第２のリクエストで、元のサーバまたはネットワークにさらなる要求を
出すことなく、履行される。

【００７８】 上述したように、ウェブサービスシステム９０上でファイルが変更する場合、
キャッシュサーバ２００上にキャッシュされたファイルは、終了し得ない。その
場合、キャッシュサーバ２００は、ウェブサービスシステム９０から利用可能な
更新されたバージョンよりも、よりカールした（ｃａｒｌｉｅｒ）ウェブページ
のバージョンを提供する。従って、上述したような変更点リストを用いて、ファ
イルが変更したことをキャッシュサーバ２００に知らせることが有利である。

【００７９】 図１０を参照すると、キャッシュサーバでファイルの変更点が調整されたシス
テムにおいて、変更が行われ（工程１８０）、変更点が識別され（工程１８１）
、変更点がウェブサーバに送信され（工程１８２）、変更点がインストールされ
る（工程１８３）。また、キャッシュサーバは、変更が知らせられる（工程１８
４）。キャッシュサーバに知らせる、さらなる工程（工程１８４）は、キャッシ
ュサーバが、もはや用いられないウェブページを破棄する（すなわち、除く）こ
とを可能にする。１つのキャッシュサーバ、または多くのキャッシュサーバがあ
り得、様々な通信技術を用いて知らせられ得る。例えば、１つの実施形態におい
て、放送メッセージが用いられる。他の実施形態において、各キャッシュサーバ
に別個のメッセージが送信される。さらに別の実施形態において、ファイルが、
１つ以上のキャッシュサーバとって利用可能なディレクトリに格納される。

【００８０】 図１１を参照すると、図６の方法の実施形態は、変更を行う工程（工程１８０
）、変更点を識別する工程（工程１８１）、キャッシュに知らせる工程（工程１
８４）を含み得る。１つの実施形態において、知らせること（工程１８４）は、
変更点リストをユニフォームリソースロケータ（「ＵＲＬ」）に変換して、コン
テンツを識別する工程（工程１８６）を含む。ブラウザは、ＵＲＬを用いて、コ
ンテンツを識別する。上述したように、１つの実施形態において、変更点リスト
は、ウェブサーバにとってより簡便で、殆どのファイルシステムにおける全ての
ファイルを示すことを可能にするので、ホストファイルシステムにおけるディレ
クトリおよびファイルに関して記述される。キャッシュサーバに変更点を提供す
る場合、ＵＲＬを含むフォーマットで、ファイル（およびディレクトリ）が挙げ
られる変更点リストを変換することは有用である。ソースディレクトリは、可能
なＵＲＬの特定のプレフィックスに対応することがあり得る。例えば、コンテン
ツディレクトリおよびファイル「Ｃ：＼ＷＥＢＳＰＥＣＴＩＶＥ＼ＨＯＭＥ＼Ａ
ＢＯＵＴ＿ＨＴＭＬ」は、ＵＲＬ「ｈｔｔｐ：／／ｗｗｗ．ｗｅｂｓｐｅｃｔｉ
ｖｅ．ｃｏｍ／ｈｏｍｅ／ａｂｏｕｔ＿ｈｔｍｌ」に対応し得る。これは、プレ
フィックスが修正された（この場合、Ｃ：＼ＷＥＢＳＰＥＣＴＩＶＥは、ｈｔｔ
ｐ：／／ｗｗｗ＿ｗｅｂｓｐｅｃｔｉｖｅ．ｃｏｍで置き換えられる）ことを含
意し、ディレクトリを分割するもの、この場合では、バックスラッシュ「＼」は
、ＵＲＬ標準フォーワードスラッシュ「／」で置き換えられている。さらに、Ｕ
ＲＬにおいて許容されない文字、例えばスペースが、特定化されたルールに従っ
て符号化される。このような文字の置き換えの一例が、Ｔ．Ｂｅｒｎｅｒｓ−Ｌ
ｅｅらによる、「Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ」という
題のＩＥＴＦ Ｎｅｔｗｏｒｋ Ｗｏｒｋｉｎｇ Ｇｒｏｕｐ ＲＦＣ−１７８
３文書において記載される。例えば、スペースは、「％２０」で符号化され得、
この翻訳は、ＵＲＬプレフィックスに連結される。

【００８１】 リスト項目が、ＵＲＬフォーマットに変換された後、変更されたＵＲＬのリス
トは、キャッシュサーバに送信される（工程１８７）。キャッシュサーバは、こ
のリストを用いて、古いコンテンツを破棄し得る。図７に示すように、通知を行
うためにコンテンツ伝送を行う必要はない。例えば、１つしかウェブサーバがな
いが、キャッシュが多い場合、図７のシステムは、１つ以上のキャッシュサーバ
に変更を知らせるように機能を果たす。図７に示すように、変更が行われ（工程
１８０）、変更点が識別され（工程１８１）、変更点のリストは、ＵＲＬに変換
される（工程１８６）。これらの変更点は、キャッシュサーバに送信される（工
程１８７）。他の実施形態において、ＵＲＬへの変換（工程１８６）は、変更が
行われる工程（工程１８０）と、変更点を識別する工程（工程１８１）との間に
行われる。

【００８２】 図１２を参照すると、１つの実施形態において、図３および図１０の方法は、
ユーザ設定可能スクリプトを実行する工程をさらに含む。変更が行われた（工程
１８０）後、ユーザ設定可能スクリプトが実行される（工程２８０）。変更点を
識別した後（工程１８１）、ユーザ設定可能スクリプトが実行される（工程２８
１）。スクリプトは、変更点の送信（工程１８２）と同時に実行される。変更点
が送信された後（工程１８２）、ユーザ設定可能スクリプトは再度実行される（
工程２８２）。ユーザ設定可能スクリプトは、カスタマーの実現に特有のコンテ
ンツ配信タスクを達成するために、用いられ得る。ユーザ設定可能スクリプトは
、オペレーティングシステム機能の適切な呼び出しを通じて実行される。

【００８３】 図１３を参照すると、１つの実施形態において、コールアウトスクリプトに情
報が提供される。１つの実施形態において、情報は、標準入力のスクリプトに提
供される。他の実施形態において、情報は、ファイル内に提供される。スクリプ
トは、十分な（ゼロ）ステータスコード、または、１つの実施形態において動作
を中止する非ゼロエラーコードのいずれかである。

【００８４】 １つの実施形態において、情報４００は、テキストフォーマットで提供され、
ＢＥＧＩＮＰＡＲＡＭＳステートメント４０１で開始し、ＥＮＤＰＡＲＡＭＳス
テートメント４２０で終了する。情報４００は、互換性のために用いられる、情
報ブロックのバージョン数４０２を含む。情報４００は、この例においてＥＸＡ
ＭＰＬＥＪＯＢである、ジョブ名４０３を含む。

【００８５】 情報４００は、ＢＥＧＩＮ、ＩＮ ＰＲＯＧＲＥＳＳ、およびＥＮＤのうちの
１つであり得るジョブ４０４の状態を含む。ＢＥＧＩＮ値は、変更点を識別する
（すなわち、図１１の工程２８０）前にスクリプトが呼び出されることを示す。
ＩＮ ＰＲＯＧＲＥＳＳ値は、変更点を識別した後、変更点が送信される前（ま
たは、ちょうど送信されるとき）にスクリプトが呼び出されることを示す（すな
わち、図１１の工程２８１）。ＥＮＤ値は、送信が完了したことを示す（すなわ
ち、図１１の工程２８２）。情報４００は、この場合はＡＬＬＩＭＡＧＥＳであ
る、マッピング４０５の名前を含む。情報４００は、この例において、／ＴＭＰ
／ＳＴＡＧＩＮＧ／２３４２３．ＴＸＴ．であるマニフェストファイル４０６の
パス名を含む。この例において、マニフェストは、テキストファイルであり、上
述したテキストフォーマットの実施形態であることを含意する。１つの実施形態
において、マニフェストは、スクリプトが呼び出される前にテキストファイルに
変換されるように、２進数形式の実施形態に格納される。

【００８６】 情報４００は、ソースファイルセットディレクトリ４０６、および、より早い
（変更の前の）バージョンを指示し得るか、自動的に回帰される任意のコンテン
ツを保持し得る、回帰ディレクトリディレクトリ４０８を含む。宛先４０９のア
レイが示される。各アレイの要素は、ファイルの宛先についての情報を含む。こ
の例において、２つの宛先ホスト、ＯＯＬＯＮＧおよびＤＡＲＪＥＥＬＩＮＧが
ある。アレイの第１の要素は、ＢＥＧＩＮＥＬＥＭＥＮＴステートメント４１０
で開始し、ＥＮＤＥＬＥＭＥＮＴステートメント４１４で終了する。アレイ要素
は、この場合においてはＯＯＬＯＮＧである、宛先ホストの名前４１１を含む。
アレイ要素は、この例においては／ＨＯＭＥ／ＨＴＴＰＤ−ＯＯＬＯＮＧ／ＤＯ
Ｃ／ＩＭＡＧＥＳである、宛先ホストの宛先ディレクトリ４１２を含む。アレイ
要素は、この例においてはＮＯＲＭＡＬである、転送４１３の状態を含む。アレ
イの第２の要素は、ＢＥＧＩＮＥＬＥＭＥＮＴステートメント４１５で開始し、
ＥＮＤＥＬＥＭＥＮＴステートメント４１９で終了する。第２のアレイ要素は、
この場合においてはＤＡＲＪＥＥＬＩＮＧである、宛先ホストの名前４１６を含
む。アレイ要素は、この例においては／ＨＯＭＥ／ＨＴＴＰＤ−ＤＡＲＪＥＥＬ
ＩＮＧ／ＤＯＣ／ＩＭＡＧＥＳである、宛先ホストの宛先ディレクトリ４１７を
含む。第２のアレイ要素は、この例においてはＮＯＲＭＡＬである、転送４１８
の状態を含む。従って、ユーザスクリプトに提供される情報は、同じスクリプト
が、ジョブの実行の間に、異なる場合に呼び出されることを可能にし、スクリプ
トは、提供されるパラメータに依存して、異なるアクションを取り得る。

【００８７】 本明細書の記載の変形例、改変例、および他の実現例は、請求された本発明の
精神および範囲から逸脱することなく、当業者によって想起され得る。従って、
本発明は、前述の例示的な記載によって規定されるものではなく、特許請求の範
囲の精神および範囲によって規定される。

【図面の簡単な説明】

【図１】 図１は、本発明による、ウェブサービスシステムの実施形態のブロック図であ
る。

【図２】 図２は、ウェブサービスシステムの実施形態のより詳細なブロック図である。

【図３】 図３は、図１のコンテンツディストリビュータの実施形態の動作のフローチャ
ートである。

【図４】 図４は、現在のソースファイルセットと前のファイルセットとの比較のフロー
チャートである。

【図５】 図５は、マニフェストエントリーの実施形態の図である。

【図６】 図６は、変更されたファイルの一例の図である。

【図７】 図７は、図６の変更されたファイルを示すマニフェストの例示的な実施形態の
図である。

【図８】 図８は、古いバージョンのメンテナンスの実施形態の一例の図である。

【図９】 図９は、キャッシュサーバと通信するウェブサービスシステムの実施形態のブ
ロック図である。

【図１０】 図１０は、コンテンツを配信する方法の実施形態のフローチャートである。

【図１１】 図１１は、コンテンツディストリビュータの他の実施形態の動作のフローチャ
ートである。

【図１２】 図１２は、コンテンツディストリビュータの他の実施形態の動作のフローチャ
ートである。

【図１３】 図１３は、図１２の実施形態のスクリプトに提供される情報の一例の図である
。

───────────────────────────────────────────────────── フロントページの続き (31)優先権主張番号 ０９／３７７，６１１ (32)優先日 平成11年８月19日(1999．8．19) (33)優先権主張国 米国（ＵＳ） (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＳＤ，ＳＬ，ＳＺ，ＴＺ，ＵＧ，ＺＷ )，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ， ＴＪ，ＴＭ)，ＡＥ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ， ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，Ｃ Ｒ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＤＭ，ＥＥ，ＥＳ，ＦＩ ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ， ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，Ｋ Ｚ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＡ ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ， ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，Ｓ Ｋ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＴＺ，ＵＡ，ＵＧ ，ＵＺ，ＶＮ，ＹＵ，ＺＡ，ＺＷ (72)発明者 シャー， スワップニル アメリカ合衆国 マサチューセッツ 01742， コンコード， サッドバリー ロード 467 (72)発明者 ウェン， ケイス アメリカ合衆国 カリフォルニア 94114， サン フランシスコ， ヒル ストリー ト 541， アパートメント ビー (72)発明者 マテオス， アーサー アメリカ合衆国 マサチューセッツ 02174， アーリントン， ブロードウェ イ 261 (72)発明者 ララ， マルコ アメリカ合衆国 マサチューセッツ 01983， トップスフィールド， ワイル デス ロード 21 (72)発明者 デベッテンコート， ジェイソン アメリカ合衆国 マサチューセッツ 01701， フラミンガム， エッジエル ロード 835 Ｆターム(参考） 5B075 KK07 KK13 KK33 KK40 ND20 ND23 ND36 PQ02 PQ46 UU40 5B082 GB02 HA02 HA03 5B085 AA08 BG04 BG07

Claims (20)

【特許請求の範囲】
1. 【請求項１】 変更されたファイルをコンピュータに知らせる方法であって
   、 （ａ）ソースファイルセット内の変更点を識別する工程と、 （ｂ）該変更されたファイルを特定する、ユニフォームリソースロケータを含
   む修正リストに識別された変更点を格納する工程と、 （ｃ）該修正リストをコンピュータに送信する工程と を包含する、方法。
2. 【請求項２】 前記工程（ｃ）が、前記修正リストをウェブキャッシュサー
   バに送信する工程を包含する、請求項１に記載の方法。
3. 【請求項３】 前記識別する工程が、 ファイルのセットを検査する工程と、 ファイルのセットを以前に記録されたセットと比較する工程と を包含する、請求項１に記載の方法。
4. 【請求項４】 前記比較する工程が、ファイル属性を前記以前に記録された
   セットのファイル属性と比較する工程を包含する、請求項３に記載の方法。
5. 【請求項５】 前記ファイル属性が、ファイルサイズ、ファイル許可、ファ
   イル所有権、修正時刻、およびファイルのハッシュのセットから選択される少な
   くとも１つの属性を含む、請求項４に記載の方法。
6. 【請求項６】 前記識別する工程が、 ファイル動作を行うようにデバイスドライバをインストールする工程と、 該デバイスドライバによって、前記ソースファイルセットの変更点を記録する
   工程と を包含する、請求項１に記載の方法。
7. 【請求項７】 前記識別する工程が、 前記ソースファイルセットの変更点を記述するマニフェストを受信する工程と
   、 を包含する、請求項１に記載の方法。
8. 【請求項８】 前記識別する工程の前に、スクリプトを呼び出す工程をさら
   に包含する、請求項１に記載の方法。
9. 【請求項９】 前記送信する工程の前に、スクリプトを呼び出す工程をさら
   に包含する、請求項１に記載の方法。
10. 【請求項１０】 前記送信する工程の後に、スクリプトを呼び出す工程をさ
    らに包含する、請求項１に記載の方法。
11. 【請求項１１】 前記送信する工程が首尾よく完了したかどうかを判定する
    工程をさらに包含し、前記呼び出す工程が、該判定する工程の後に発生する、請
    求項１０に記載の方法。
12. 【請求項１２】 ソースファイルセット内の変更点を、宛先ファイルシステ
    ムで複製し、該変更点をコンピュータに知らせる方法であって、 （ａ）ソースファイルセット内の変更点を識別する工程と、 （ｂ）第１の修正リストに該変更点を格納する工程と、 （ｃ）該第１の修正リストを、宛先ファイルシステムへのアクセスを有するエ
    ージェントに送信する工程と、 （ｄ）変更されたファイルを特定するユニフォームリソースロケータを含む、
    第２の修正リストに変更点を格納する工程と、 （ｅ）該第２の修正リストをコンピュータに送信する工程と を包含する、方法。
13. 【請求項１３】 前記コンピュータは、ウェブキャッシュサーバである、請
    求項１２に記載の方法。
14. 【請求項１４】 前記工程（ｄ）の前に、前記第１の修正リストを前記第２
    の修正リストに変換する工程をさらに包含する、請求項１２に記載の方法。
15. 【請求項１５】 ソースファイルセット内の変更点を、宛先ファイルシステ
    ムで複製し、該変更点をコンピュータに知らせる方法であって、 （ａ）ソースファイルセット内の変更点を識別する工程と、 （ｂ）変更されたファイルを特定するユニフォームリソースロケータを含む修
    正リストに該変更点を格納する工程と、 （ｃ）該修正リストを、宛先ファイルシステムへのアクセスを有するエージェ
    ントに送信する工程と、 （ｄ）該修正リストをコンピュータに送信する工程と を包含する、方法。
16. 【請求項１６】 ウェブサービスシステムを管理するマネージャと、 ウェブページリクエストを受信するウェブサーバ、および該マネージャと通信
    するエージェントを備えるホストと、 ウェブキャッシュと、 該ホストにコンテンツ変更点を提供するコンテンツディストリビュータと を備える、ウェブサービスシステム。
17. 【請求項１７】 ウェブページリクエストを前記ウェブサーバに向けるトラ
    フィックマネージャをさらに備える、請求項１６に記載のシステム。
18. 【請求項１８】 前記コンテンツディストリビュータが、 （ａ）ソースファイルセット内の変更点を識別する、識別モジュールと、 （ｂ）識別された変更点を格納する、修正リストと、 （ｃ）該修正リストを宛先ファイルシステムへのアクセスを有するエージェン
    トに送信する、トランスミッタと を備える、請求項１６に記載のシステム。
19. 【請求項１９】 前記変更されたファイルを前記エージェントに送信するト
    ランスミッタを備える、請求項１８に記載のシステム。
20. 【請求項２０】 （ａ）ソースファイルセット内の変更点を識別する、識別
    モジュールと、 （ｂ）識別された変更点を格納する、修正リストと、 （ｃ）該修正リストを宛先ファイルシステムへのアクセスを有するエージェン
    トに送信する、トランスミッタと、 （ｄ）変更されたファイルをウェブキャッシュサーバに送信する、トランスミ
    ッタと を備える、コンテンツディストリビュータ。