JP3593303B2

JP3593303B2 - クライアント・マシンにおいてドキュメントをアクセスするための方法

Info

Publication number: JP3593303B2
Application number: JP2000180511A
Authority: JP
Inventors: ジェフリー・アレン・ジョーンズ; マイケル・ウェイン・ブラウン
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1999-06-17
Filing date: 2000-06-15
Publication date: 2004-11-24
Anticipated expiration: 2020-06-15
Also published as: GB2356269B; GB2356269A; CN1273916C; JP2001034526A; GB0014624D0; TW473660B; CN1278627A; US6381618B1

Description

【０００１】
【発明の属する技術分野】
本発明は、概してコンピュータ・ソフトウェアに関し、より詳しくは分散型コンピューティング環境におけるドキュメントのコピー管理に関する。
【０００２】
【従来の技術】
インターネットは、情報ならびに娯楽の両面においてともにそのソースとして文化的に定着した。多くのビジネスは、市場努力の一環としてインターネット・サイトを開設し、消費者に当該ビジネスが提供する製品ないしはサービスを知らせ、あるいはその他の情報を提供しブランドを浸透させようとしている。連邦、州、および地方自治体の部局もまた、その多くが情報提供目的でインターネット・サイトを採り入れており、特に実質的に社会のあらゆる部分と対話しなければならない国税局等の部局および国務長官においてはそれが顕著である。公開記録については、情報提供のためのガイドやサーチ可能なデータベースをオンラインで提供する方が運用コストが削減できることがある。
【０００３】
【発明が解決しようとする課題】
現在、コンテンツのプロバイダや制作者（著作者）によって、ウェブ上での資源（ドキュメント、ロゴ、データ、グラフィック等）の配付のために試みられている方法は、それが個人であるか会社であるかによらず、一般に次の２つの方法のいずれかである：すなわち、サーバを準備し、資源はすべてそこからロードしなければならないとする方法、または資源のコピーを許し、リモート・サイトにおいてそれを繰り返し再現できるとする方法である。その一例がウェブ上のバナー広告である。問題はいずれの方法にもある。前者の方法を採用した場合、制作者のサーバは、発生が予想される膨大なヒットに追随し得るべく非常に広い帯域幅を有していなければならない。この帯域幅が充分であることはまれであり、そのため広告のロードが遅くなり、延いてはそれが、広告がなければ「速い」はずのページのロードさえも遅くすることになる。この方法はまた、サーバの故障が地球規模の影響を招くというリスクも抱えている。
【０００４】
２番目の方法においては、広告主がコントロールをほぼ完全に放棄した形となる。実際上、インターネット全体にわたるドキュメント／画像／ロゴの同期は不可能である。広告主が持ち得る唯一の手段は、アップデートを提供し、時機を失することなくそれがリモート・サイトにおいて更新されることを祈るだけである。さらに、それぞれのサイトは、（まったく同一の）コピーを個別に持たなければならず、おそらくはそれが異なる名前で識別され、かつ間違いなくそれが互いに異なる固有のサイト／パス／ファイル名によって識別されることから、いたるところに見受けられるコカコーラ（Ｃｏｃａ−Ｃｏｌａ）のロゴのように、すでに他のサイトからロードした多くのコピーをユーザが所持している場合であっても、そのドキュメント／画像をユーザの元に再送信しなければならない。このように、名前が異なるとき、または名前が同じでもサイトが異なるとき、ブラウザは異なるドキュメント／画像／ロゴと見なしてしまう。
【０００５】
そこで、ドキュメント配付のための改善された方法および装置があると都合がよい。
【０００６】
【課題を解決するための手段】
本発明は、分散型コンピューティング環境において第１のドキュメントのコピーを同期させる方法を提供する。この第１のドキュメント用の優先リポジトリに対するパスおよび、第１のドキュメント用のマスタ・リポジトリに対するパスが、第２のドキュメントに埋め込まれる。まず第１のドキュメントのコピーを優先リポジトリから取り出す。続いてマスタ・リポジトリを調べ、取り出したこのコピーが、第１のドキュメントのもっとも新しいバージョンのコピーであるか否かを判断する。取り出したコピーが第１のドキュメントのもっとも新しいバージョンであると判断されると、取り出したそのコピーを使用して第２のコピーをフォーマットする。
【０００７】
新規性があると考えられる本発明の特徴は、特許請求の範囲に述べたとおりである。しかしながら、本発明そのもの、その好ましい実施態様を始めそのさらなる目的ならびに利点に対するより良い理解に資するため、以下、添付図面を参照して実施例を詳細に説明する。
【０００８】
【発明の実施の形態】
ここで図面、特に本発明を実施し得る分散型データ処理システムの概要を示した図１を参照する。
【０００９】
分散型データ処理システム１００は、本発明を実施し得るコンピュータのネットワークである。この分散型データ処理システム１００は、分散型データ処理システム１００内で接続される各種デバイスおよびコンピュータ間の通信リンクを提供するために使用されるメディアであるネットワーク１０２を備える。ネットワーク１０２は、有線もしくは光ファイバ・ケーブル等を用いる恒久的な接続、または電話接続を通じた一時的な接続を含むものとすることができる。
【００１０】
この例に示したネットワーク１０２には、サーバ１０４が記憶ユニット１０６とともに接続されている。それに加えてこのネットワーク１０２には、クライアント１０８、１１０および１１２が接続されている。クライアント１０８、１１０および１１２は、たとえばパーソナル・コンピュータもしくはネットワーク・コンピュータとすることができる。ただし本明細書においては、ネットワークに接続された別のコンピュータからプログラム、データまたはその他のアプリケーションを受信する、ネットワークに接続された任意のコンピュータをネットワーク・コンピュータとする。図示の例におけるサーバ１０４は、ブート・ファイル、オペレーティング・システム・イメージおよびアプリケーション等のデータをクライアント１０８〜１１２に供給する。サーバ１０４は、複数のクライアントまたは他のサーバに配付予定のファイル（グラフィック・ファイル、ドキュメント、バナー、広告等）のためのリポジトリとしても機能し得る。クライアント１０８、１１０および１１２は、サーバ１０４に対するクライアントである。分散型データ処理システム１００は、図示を省略したが、このほかにもサーバ、クライアントおよびその他のデバイスを含むこともある。分散型データ処理システム１００は、プリンタ１１４、１１６および１１８も備えている。あるクライアント、たとえばクライアント１１０は、プリンタ１１４に直接プリントすることができる。クライアント１０８およびクライアント１１２等のクライアントには、プリンタが直接アタッチされていない。これらのクライアントは、サーバ１０４にアタッチされるプリンタ１１６またはドキュメントをプリントするためのコンピュータを接続しておく必要のないネットワーク・プリンタ１１８にプリントすることができる。クライアント１１０も、プリンタのタイプおよびドキュメントの要件に応じてプリンタ１１６またはプリンタ１１８にプリントすることができる。
【００１１】
図示の例においては、分散型データ処理システム１００がインターネットであり、ネットワーク１０２は互いの通信を可能にするＴＣＰ／ＩＰプロトコル・スイートを使用するネットワークおよびゲートウェイの地球規模の集合を表す。しかしながら本発明がインターネットに限定されることはなく、その他のネットワーク、たとえばこれに限定する意図はまったくないが、ローカル・エリア・ネットワーク（「ＬＡＮ」）およびワイド・エリア・ネットワーク（「ＷＡＮ」）を含めたネットワークにおいて使用されることもある。インターネットの心臓部には、主要ノードすなわち、データならびにメッセージのルーティングを行う無数の商業関連、政府関連、教育関連その他のコンピュータ・システムからなるホスト・コンピュータの間をつなぐ高速データ通信ラインのバックボーンが横たわる。当然のことながら、たとえばイントラネットまたはローカル・エリア・ネットワーク等の種々のタイプのネットワークとして、分散型データ処理システム１００を具体化してもよい。
【００１２】
図１は、例示を意図したものであり本発明のプロセスに関する構造的な限定を意図したものではない。
【００１３】
図２を参照すると、本発明に従って図１におけるサーバ１０４等のサーバとして具体化され得るデータ処理システムのブロック図が図示されている。データ処理システム２００は、システム・バス２０６に接続された複数のプロセッサ２０２および２０４を備える対称マルチプロセッサ（ＳＭＰ）システムである。これに代えてシングル・プロセッサ・システムを使用してもよい。また、このシステム・バス２０６に接続されているメモリ・コントローラ／キャッシュ２０８は、ローカル・メモリ２０９に対するインターフェースを提供する。さらにＩ／Ｏバス・ブリッジ２１０がシステム・バス２０６に接続され、それによりＩ／Ｏバス２１２に対するインターフェースが提供される。メモリ・コントローラ／キャッシュ２０８およびＩ／Ｏバス・ブリッジ２１０は、ここに図示したように統合されていることもある。
【００１４】
Ｉ／Ｏバス２１２に接続されたＰＣＩバス・ブリッジ２１４は、ＰＣＩローカル・バス２１６に対するインターフェースを提供する。このＰＣＩバス２１６には複数のモデム２１８〜２２０が接続されることがある。一般的なＰＣＩバス実装は、４つのＰＣＩ拡張スロットまたはアドイン・コネクタをサポートする。図１に示したネットワーク・コンピュータ１０８〜１１２に対する通信リンクは、アドイン・ボードを通じてＰＣＩローカル・バス２１６に接続されたモデム２１８およびネットワーク・アダプタ２２０を介して提供される。
【００１５】
上記のほかにも追加のＰＣＩバス２２６および２２８用のインターフェースを提供するＰＣＩバス・ブリッジ２２２および２２４が備わり、これを介して追加のモデムまたはネットワーク・アダプタをサポートすることができる。このようにしてサーバ２００においては、複数のネットワーク・コンピュータに対する接続が可能になる。また図示のように、Ｉ／Ｏバス２１２には、メモリ・マップド・グラフィック・アダプタ２３０およびハードディスク２３２が直接もしくは間接的に接続されることもある。
【００１６】
当業者にとっては明らかであろうが、図２に示したハードウェアには多くの変形が考えられる。たとえば、図示のハードウェアに加えて、またはそれに代えて光ディスク・ドライブ等の他の周辺デバイスを使用してもよい。すなわち、ここに示した例が本発明に関する構造的な制限を暗示することはない。
【００１７】
図２に示したデータ処理システムは、たとえばＡＩＸオペレーティング・システムを実行するＩＢＭＲＩＳＣ／Ｓｙｓｔｅｍ６０００とすることができる。
【００１８】
ここで、本発明を実施することができるデータ処理システムのブロック図を示した図３を参照する。データ処理システム３００は、クライアント・コンピュータの一例である。データ処理システム３００は、ネットスケープ・ナビゲータまたはマイクロソフト・インターネット・エクスプローラといったウェブ・ブラウザ・ソフトウェアを実行することもできる。このデータ処理システム３００は、ＰＣＩローカル・バス・アーキテクチャを採用している。ここに図示した例においてはＰＣＩバスが使用されているが、マイクロチャネルあるいはＩＳＡ等のこれとは異なるバス・アーキテクチャを使用してもよい。ＰＣＩローカル・バス３０６には、ＰＣＩブリッジ３０８を介してプロセッサ３０２およびメイン・メモリ３０４が接続されている。このＰＣＩブリッジ３０８には、プロセッサ３０２用のメモリ・コントローラおよびキャッシュ・メモリが統合されていてもよい。ＰＣＩローカル・バス３０６に対する追加の接続は、直接コンポーネント接続により、あるいはアドイン・ボードを介して得られる。図示した例においては、直接コンポーネント接続によりローカル・エリア・ネットワーク（ＬＡＮ）アダプタ３１０、ＳＣＳＩホスト・バス・アダプタ３１２、および拡張バス・インターフェース３１４がＰＣＩローカル・バス３０６に接続されている。これに対して、オーディオ・アダプタ３１６、グラフィック・アダプタ３１８、およびオーディオ／ビデオ・アダプタ（Ａ／Ｖ）３１９は、拡張スロットに挿入されたアドイン・ボードによってＰＣＩローカル・バス３０６に接続されている。拡張バス・インターフェース３１４は、キーボードおよびマウス・アダプタ３２０、モデム３２２、および増設メモリ３２４のための接続を提供する。図示の例において、ＳＣＳＩホスト・バス・アダプタ３１２はハードディスク・ドライブ３２６、テープ・ドライブ３２８、ＣＤ−ＲＯＭドライブ３３０およびディジタル・ビデオ・ディスク読み出し専用メモリ・ドライブ（ＤＶＤ−ＲＯＭ）３３２のための接続を提供する。一般的なＰＣＩローカル・バス実装は、３ないしは４のＰＣＩ拡張スロットまたはアドイン・コネクタをサポートする。
【００１９】
プロセッサ３０２上で実行されるオペレーティング・システムは、図３に示したデータ処理システム３００内の各種コンポーネントを調整し、制御するために使用される。このオペレーティング・システムは、本出願人から提供されているＯＳ／２等の市販オペレーティング・システムとすることができる。Ｊａｖａ等のオブジェクト指向プログラミング・システムをこのオペレーティング・システムと関連させて実行し、データ処理システム３００上で実行するＪａｖａプログラムからオペレーティング・システムへの呼び出しを提供するようにしてもよい。オペレーティング・システム、オブジェクト指向オペレーティング・システム、およびアプリケーションまたはプログラム用の命令は、一般に、ハード・ディスク・ドライブ３２６等の記憶デバイスに格納されており、プロセッサ３０２による実行時にメイン・メモリ３０４にロードされる。
【００２０】
当業者にとっては明らかであろうが、図３に示したハードウェアは、実装に応じて多様な形をとり得る。たとえば、図３に示したハードウェアに加えて、またはそれに代えて光ディスク・ドライブ等の他の周辺デバイスを使用してもよい。すなわち、ここに示した例が本発明に関する構造的な制限を暗示することはない。たとえば、本発明のプロセスをマルチプロセッサ・データ処理システムに適用することもできる。
【００２１】
本発明の好ましい実施例を図４に示す。ローカル・サーバ４１０上にあるウェブ・サイトは、ターゲット・ドキュメント仕様（ＨＴＭＬリンク等）を擁しており、そこには複数の名前およびターゲット・ドキュメントを見つけ出すことができる可能性のある場所が含まれている。ターゲット・ドキュメントとしては、たとえばグラフィック・ファイル、ドキュメント、バナー、広告等が考えられる。パス名の１つは「優先」ロケーション４１０を参照し、１つないしは複数のパス名は「フォールバック（代替）」ロケーション４２０を参照し、名前の１つは「マスタ」ロケーション４３０を参照する。ネットスケープ・ナビゲータまたはマイクロソフト・インターネット・エクスプローラ等のウェブ・ブラウザは、ネットワーク１０２を経由して優先ロケーション４１０からターゲット・ドキュメントをユーザ４５０にロードする。この「優先」ロケーション４１０は、通常ローカル・サイトであり、一般に当該ブラウザにとってもっとも高速にロードできるターゲット・ドキュメントのコピーとなる。ブラウザは、アイドル期間中にロード済みのバージョンと「マスタ」サイト４３０上のバージョンを照合し、必要に応じてドキュメントを更新する。ターゲット・ドキュメントを「優先」ロケーション４１０から入手できない場合に、ウェブ・ブラウザは「フォールバック」ロケーション４２０をチェックし、この「フォールバック」ロケーション４２０からターゲット・ドキュメントのロードを試みる。「優先」ロケーション４１０ならびに「フォールバック」ロケーション４２０のいずれにもアクセスできなければ、ウェブ・ブラウザは「マスタ」ロケーション４３０からターゲット・ドキュメントをロードする。
【００２２】
現在のシステムにおいては、ＨＴＭＬが、たとえば次に示すような形になる。
＜ＩＭＧＳＲＣ＝”ｉｍａｇｅｓ／ｃｏｋｅｌｏｇｏ．ｇｉｆ” ＷＩＤＴＨ＝１２９ＨＥＩＧＨＴ＝１２８＞
【００２３】
しかしながら、本発明を使用するとＨＴＭＬが次に示すような形になる。
＜ＩＭＧＳＲＣ＝”ｉｍａｇｅｓ／ｃｏｋｅｌｏｇｏ．ｇｉｆ” ＷＩＤＴＨ＝１２８ＨＥＩＧＨＴ＝１２８ＡＬＴＳＲＣ＝” ｈｔｔｐ：／／ｗｗｗ．ｌｏｇｏｓｅｒｖｅｒ．ｃｏｍ／ｃｏｋｅ／ｌｏｇｏｓ／ｃｏｋｅ．ｇｉｆ” ＡＬＳＴＳＲＣ＝ＨＴＴＰ：／／ｗｗｗ．ｆａｌｌｂａｃｋ．ｃｏｍ／ｉｍａｇｅｓ／ｇｉｆ／ｃｏｋｅ／ｌｏｇｏ．ｇｉｆＭＡＳＴＥＲＳＲＣ＝ｈｔｔｐ：／／ｗｗｗ．ｃｏｃａｃｏｌａ．ｃｏｍ／ｌｏｇｏｓ／ｃｏｋｅ．ｇｉｆ＞
【００２４】
このように、「優先」ロケーションは、相対リンク「ｉｍａｇｅｓ／ｃｏｋｅｌｏｇｏ．ｇｉｆ」を経由してこのＨＴＭＬがダウンロードされるサイト上にある。このリンクに障害が生じている場合（または、可能性としてはローカル・サーバのパフォーマンスが低いことから）、示された名前を使用して「ｌｏｇｏｓｅｒｖｅｒ．ｃｏｍ」および「ｆａｌｌｂａｃｋ．ｃｏｍ」が試みられる。これらのリンクもまた成功しなければ、「ｃｏｃａｃｏｌａ．ｃｏｍ」からの「マスタ」コピーの取り出しが試みられることになる。ここで、これらのＨＴＭＬ行が、一般にブラウザが探索する第１のドキュメントに埋め込まれたタグであることを理解する必要がある。
【００２５】
オリジナルのＨＴＭＬドキュメントが完全にロードされた後、マスタ・サーバに対して、表示中のドキュメント／画像／ロゴが最新のものであるかを確認する問い合わせがなされる。しかしながら、マスタ・サーバおよびフォールバック・サーバが使用できない場合は、比較は行われない。変形例においては、マスタ・サーバおよびフォールバック・サーバが使用できない場合に、ウェブ・ブラウザが現在のドキュメントとマスタ・ドキュメントの比較のため、定期的にこれらへのアクセスを試みる。
【００２６】
１つの選択肢としては、優先リポジトリのコピーが作成から所定時間経過している場合、たとえばそのコピーが作成後少なくとも１日を経過している場合に限り、フォールバック・リポジトリおよびマスタ・リポジトリをチェックする。これにより、マスタ・サーバおよびフォールバック・サーバの不必要なアクセスが回避される。
【００２７】
本発明の変形実施例を図５に示す。この実施例においては、各ローカル・サーバ５７０、５７２、５７４、５７６、５７８、および５８０が、図４に示した実施例における場合と同じ「フォールバック」サーバ（１ないしは複数）４２０のシステムを経由して「マスタ」サーバに戻るのではなく、マスタ・ドキュメントのコピーが作成されて「発行」サーバ５６０、５６２、および５６４にストアされ、これらの「発行」サーバ５６０、５６２、および５６４が、ローカル・サーバ５７０、５７２、５７４、５７６、５７８、および５８０ならびにフォールバック・サーバ（図示せず）の離散的なグループのための「マスタ」サーバ４３０として機能する。これらの「発行」サーバ５６０、５６２、および５６４は、ネットワーク１０２を介して「マスタ」サーバ４３０に接続される。各ローカル・サーバ５７０、５７２、５７４、５７６、５７８は、ネットワーク１０２を介して対応する「発行」サーバ５６０、５６２、および５６４に接続される。同様にユーザ５４０、５４２、および５４４は、ネットワーク１０２を経由して対応するローカル・サーバ５７０、５７２、５７４、５７６、５７８に接続される。当業者であれば明らかになろうが、本発明の範囲ならびに真意から逸脱することなく、発行サーバおよびローカル・サーバの数をこれより多く、あるいはこれより少なくし、またユーザ数をこれより多く、あるいはこれより少なくすることは可能である。つまり、図５に示したシステムは、単に例示を意図したものであり、本発明を限定する意図はまったくない。
【００２８】
ユーザ５４０用のウェブ・ブラウザは、ウェブ・ページが見つかったローカル・サーバ５７２からターゲット・ドキュメントの獲得を試みる。このウェブ・ブラウザがローカル・サーバ５７２に対して、もしくはそのいずれのフォールバック・サーバ（図示せず）に対してもアクセスし得ないとき、ユーザ５４０用のウェブ・ブラウザは「発行」サーバ５６０からターゲット・ドキュメントをロードする。ユーザ５４２用のウェブ・ブラウザは、ローカル・サーバ５７４経由でターゲット・ドキュメントのロードを試みるが、この試み、およびすべての「フォールバック」サーバに対する試みに失敗すると、発行サーバ５６２を介してそれをロードする。同様に、ユーザ５４４用のウェブ・ブラウザは、ローカル・サーバ５７８経由でターゲット・ドキュメントのロードを試みるが、この試み、およびすべての「フォールバック」サーバに対する試みに失敗すると、「発行」サーバ５６４を介してそれをロードする。
【００２９】
マスタ・サーバ４３０は、マスタ・ターゲット・ドキュメントの修正が行われると、ネットワーク１０２を通じて発行サーバ５６０、５６２、および５６４に向けて更新をプッシュする。続いて「発行」サーバ５６０、５６２、および５６４は、この更新を「フォールバック」サーバにプッシュし、さらにそこからローカル・サーバ５７０、５７２、５７４、５７６、５７８に向けてこの更新がプッシュされる。このようにしてターゲット・ドキュメントの制作者または所有者は、ターゲット・ドキュメントに対する参照を含むウェブ・ページのロード時間を遅らせることなく、使用されるターゲット・ドキュメントが正しい最新のコピーであることを保証できる。
【００３０】
本発明の好ましい実施例のフローチャートを図６に示す。ネットスケープ・ナビゲータ等のウェブ・ブラウザ・プログラムを実行しているユーザは、ウェブ・ページの表示に含められるターゲット・ドキュメントに対する複数のパスが収められたウェブ・ページにアクセスする（ステップ６１０）。ウェブ・ブラウザは、ターゲット・ドキュメントに対するすべてのパス名と、以前にキャッシュしたドキュメントのパス名を照合する（ステップ６１５）。パス名の１つが以前にキャッシュしたドキュメントのそれと一致した場合は、以前にキャッシュしたバージョンがウェブ・ページのロードに使用される（ステップ６１７）。以前にこのターゲット・ドキュメントがキャッシュされていない場合は、ウェブ・ブラウザから優先ロケーションに対して問い合わせが行なわれ、当該ロケーションからのターゲット・ドキュメントのロードが可能であるか否かが判断される（ステップ６２０）。優先ロケーションからターゲット・ドキュメントを獲得できるときは、優先ロケーションからのターゲット・ドキュメントを使用してウェブ・ページが生成される（ステップ６２５）。
【００３１】
優先ロケーションからターゲット・ドキュメントが獲得できない場合は、ウェブ・ブラウザから最初のフォールバック・ロケーションに対して問い合わせが行なわれ、そこからのターゲット・ドキュメントの入手可能性が判断される（ステップ６３０）。入手可能であれば、そのフォールバック・ロケーションからロードしたターゲット・ドキュメントを使用してウェブ・ページが生成される（ステップ６３５）。フォールバック・ロケーションから入手できないとき、ウェブ・ブラウザは別のフォールバック・ロケーションがリストされていないか判断する（ステップ６３７）。
【００３２】
別のフォールバック・ロケーションが存在する場合は（ステップ６３７）、ウェブ・ブラウザから次のフォールバック・ロケーションに対して問い合わせが行なわれてターゲット・ドキュメントの入手可能性が判断され（ステップ６３０）、前述と同じプロセスが繰り返される。別のフォールバック・ロケーションが存在しなければ（ステップ６３７）、マスタ・ロケーションからロードしたターゲット・ドキュメントを使用してウェブ・ページが生成される（ステップ６４０）。
【００３３】
キャッシュ・バージョン（ステップ６１７）、優先ロケーション（ステップ６２５）およびフォールバック・ロケーション（ステップ６３５）のいずれかからロードしたターゲット・ドキュメントを使用してウェブ・ページを生成した場合、ウェブ・ブラウザは、ロードしたターゲット・ドキュメントのコピーと、マスタ・ロケーションに存在するターゲット・ドキュメントのバージョンを照合する。これらが一致しないとき、マスタ・ロケーションにあるターゲット・ドキュメントとまったく同一となるようにロードしたドキュメントを必要に応じて更新する（ステップ６７０）。特定ロケーションからターゲット・ドキュメントが入手できない条件の一例として、そのロケーション用のサーバがオフラインとなっている場合が挙げられる。
【００３４】
次に、図７に示したフローチャートを参照して画像またはドキュメントがすでにキャッシュ済みであるか否かを判断する方法について詳細に説明する。ウェブ・ページがロードされると、そのウェブ・ページとともにロードされたすべてのドキュメントに対するすべての参照名がキャッシュされる（ステップ７１０）。これらの名前は、優先ソース名、代替ソース名（１ないしは複数）、およびマスタ・ソース名を含む。新しいウェブ・ページがロードされると（ステップ７２０）ブラウザは、新しいウェブ・ページに含められた各ドキュメントに関する優先ソース名、代替ソース名（１ないしは複数）、およびマスタ・ソース名を決定する（ステップ７３０）。続いてブラウザは、キャッシュ内でそのドキュメントに関連するすべての参照名を探し（ステップ７４０）、参照名の１つがキャッシュ内に存在するか否かを判断する（ステップ７５０）。ドキュメントに関係付けられた参照名の１つが、以前にキャッシュしたドキュメントに関係付けられた有効な名前に一致すると、そのキャッシュ・ドキュメントがロードされる（ステップ７６０）。そのドキュメントに関係付けられたいずれの参照名もキャッシュ済みの参照名と一致しないと、ブラウザは、そのウェブ・ページによって提供されるロケーションの１つからドキュメントをロードすることを試みる（ステップ７７０）。ドキュメントをロードした後は、そのウェブ・ページによって提供される各参照名とともにキャッシュ内にそれをストアする（ステップ７８０）。このドキュメントがキャッシュ内に残存している限り、その後そのドキュメントを参照するときは必ずキャッシュからそれがロードされる。加えて、同じドキュメントのコピーが複数キャッシュされることはない。つまり、１つのドキュメントについて１つのコピーだけがキャッシュされる。しかしながらこのコピーには、そのドキュメントに関連するすべての参照名がアタッチされることになる。
【００３５】
複数のロケーションの１つから画像をロードする場合に適したローディング・アルゴリズム８００を図８に示す。セクション８１０は、ブラウザに対して優先ロケーション「ＳＲＣ」から画像のロードを試みるように指示する。ブラウザが優先ロケーションから画像をロードすることができないとき、セクション８２０において最初のフォールバック・サイト「ＡＬＴＳＲＣ」からその画像のロードを試みるように指示される。さらにセクション８２０においては、画像のロードが成功しなければそれが成功するまで、あるいは最後のフォールバック・サイトに到達するまで、順次、次のフォールバック・サイト「ＡＬＴＳＲＣ」からその画像のロードを試みるように指示される。ブラウザがすべてのフォールバック・サイトについて画像のロードを試みても画像がロードされなかった場合、セクション８３０においてブラウザはマスタ・ロケーション「ＭＡＳＴＥＲＳＲＣ」からその画像のロードを試みるように指示される。それでもなおブラウザが画像をロードできないときは、セクション８４０において、その画像が配置される予定だった表示エリア内に「切断されたリンク」の画像を表示するようにブラウザに指示が与えられる。
【００３６】
図９にチェック・アルゴリズム９００を示す。画像がロードされた後、アイドル期間を使用してブラウザは、ロードした画像がその画像のもっとも新しいバージョンであることを確認するためのチェックを行う。セクション９１０においては、ロードした画像に関するデータ、すなわち参照ドキュメントのＵＲＬ、画像のローカル「ＳＲＣ」名、画像の「ＭＡＳＴＥＲＳＲＣ」名、日付／時刻スタンプ、画像ファイルのサイズ、およびチェックサムを含めたデータを集める。セクション９２０においては、ブラウザに対して、マスタ・ソースがあるサーバ「ＭＡＳＴＥＲＳＲＣ」に問い合わせを行なって、ロードした画像が期限切れであるか、あるいはそれがもっとも新しいバージョンの画像であるかを判断することを指示する。その画像が期限切れである場合は、セクション９３０においてブラウザに、その画像のマスター・コピーを保持しているサーバ「ＭＡＳＴＥＲＳＲＣ」から画像をロードさせる。さらにセクション９３０においては、ブラウザに、キャッシュ内の古い画像と新しい画像の置換を指示し、その画像を表示している場所をすべて無効にすべく指示する。
【００３７】
本発明の応用を理解する上で図１０および図１１を参照すると役に立つ。まず図１０においては、ウェブ・ブラウザ１０２０を使用しているユーザが、ウェブからウェブ・ページ１０３０をロードする。ウェブ・ページ１０３０には、ウェブ・ページ１０３０上に表示するロゴ１０１０にアクセスするために使用される優先名、代替名、マスタ名が含まれている。ウェブ・ブラウザ１０２０は、優先ローカル・サーバからロゴ１０１０をロードし（通常この方法がもっとも高速になる）、そのロゴ１０１０をウェブ・ページ１０３０上に表示する。アイドル期間中にブラウザ１０２０は、ロゴ１０１０のマスタ・ソース・ロケーションに対して問い合わせを行い、最新のコピーがロードされたか否かを判断する。この例においては、最新バージョンがロードされなかったとする。ロードしたロゴ１０１０が期限切れであることをマスタ・ソースから知らされると、ウェブ・ブラウザ１０２０は更新後のロゴ１１１０をマスタ・ソースからロードし、図１１に示すようにそれをユーザに向けて表示する。これに対し、ロードしたロゴ１０１０がロゴ１０１０の最新のコピーであった場合は、ユーザに向けて表示される画像は変更されない。このように本発明によれば、分散されたドキュメントのオーナは、これらのドキュメントを含むウェブ・ページのロード時間を遅らせることなく、ドキュメントのコンテンツに関するコントロールを保持することができる。
【００３８】
つまり本発明の１つの利点は、ウェブ・サイトがサード・パーティのファイル（ロゴ、ドキュメント、バナー、広告等）の高速なローカル・コピーを持ち得る一方、ほぼリアルタイムで制作者がそのファイルをコントロールできることである。さらに本発明によれば、ブラウザが共通のドキュメント／画像のアイデンティティをそれらの共通の「マスタ」名および「代替」名によって識別することが可能になり、ページのロード時間を短縮し、それによりページ上に広告を掲示することを好ましくないとする意見も抑えることができる。
【００３９】
図８および図９に示した疑似コードには、本発明の理解を明確にするため線形アルゴリズムを使用している。しかしながらここでは、実用上の理由から、実際に使用されるアルゴリズムが、おそらくはイベント駆動型のアルゴリズムになると考えられる点に注意する必要がある。また、図８および図９においては「画像（ｉｍａｇｅ）」が使用されているが、任意のドキュメント・タイプの使用が可能であり、関連するハイパーテキスト・マークアップ言語（「ＨＴＭＬ」）タグについても「ＳＲＣ」またはＳＲＣに類似したコンポーネントと関係を有する任意のタグとすることができる点にも注意が必要である。さらにまた、ここでは本発明を唯一のマスタ・ロケーションに対する参照によって説明したが、制作者がそれぞれのマスタ・ロケーションにあるドキュメントのコンテンツに関して直接のコントロールを有する限り、複数のマスタ・ロケーションを伴う状況にも等しく適用可能である点に注意されたい。以上に加えて、マスタ・ソース・ロケーションは、ウェブ・サーバとすることもできる。
【００４０】
ここでは、ＨＴＭＬとの関連から本発明を説明してきたが、それ以外のマークアップ言語、たとえば拡張マークアップ言語が使用できることも重要なポイントであり、当業者であればそれが明らかであろう。また、本発明が、ワールド・ワイド・ウェブ（単に「ウェブ」とも呼ばれる）、インターネット、イントラネット、ローカル・エリア・ネットワーク、およびワイド・エリア・ネットワーク上にあるドキュメントに対して適用され、また優先ソース、フォールバック・ソース、およびマスタ・ソースが、ロケーション・タイプの各種組み合わせを含めてこれらのネットワーク上に置かれることがある点を理解する必要がある。さらに、ドキュメントがウェブ・ページとなることもあるが、それが必須でないことに注意が必要である。さらにまた、クライアントがマスタ・ソースにアクセスできない場合、画像がフォールバック・ソースの１つから更新できることに注意を要する。さらにまた、画像の更新に関して主に説明してきたが、これは単なる例として与えられたものにすぎず、画像は任意のタイプのドキュメントに置き換えることが可能であり、それにおいてドキュメントは、たとえば、画像、テキスト、サウンド、あるいはこれらの組み合わせを含むものとしてよい。
【００４１】
ここでは、本発明を完全に機能するデータ処理システムに関連づけて説明してきたが、当業者であれば明らかであろうが、本発明のプロセスが、命令を収めたコンピュータ可読メディアの形式および各種の形式で配付できること、また本発明が、配付を行うために実際に使用される信号担持メディアのタイプと無関係に等しく適用されることへの注意も重要である。コンピュータ可読メディアの例としては、フロッピーディスク、ハードディスク・ドライブ、ＲＡＭ、およびＣＤ−ＲＯＭ等の記録可能なタイプのメディア、およびディジタルおよびアナログ通信リンク等の伝達タイプのメディアが挙げられる。
【００４２】
以上行ってきた本発明の説明は、例示および説明を目的としたものであり、網羅的であることを意図したものでもなければ、開示した形でそれを限定することを意図したものでもない。当業者にとっては、多くの修正ならびに変形が明らかであろう。実施例は、本発明の原理、実際的な応用をもっともよく説明するため、また当業者が本発明を理解し予定された特定の使用に適した各種の修正を伴う各種の具体化を行うことができるように選択され、述べられたものである。
【図面の簡単な説明】
【図１】本発明を実施し得る分散型データ処理システムの概要図を示す。
【図２】本発明に従ったデータ処理システム（サーバ）のブロック図を示す。
【図３】データ処理システム（クライアント）のブロック図を示す。
【図４】本発明の好ましい実施例を示す。
【図５】本発明の変形実施例を示す。
【図６】本発明の好ましい実施例のフローチャートを示す。
【図７】本発明のキャッシング・メカニズムのフローチャートを示す。
【図８】本発明のドキュメント・ロード機能を実行する疑似コードを一例で示す。
【図９】本発明のドキュメント・チェック機能を実行する疑似コードを一例で示す。
【図１０】ウェブ・ブラウザのスクリーン画像を示す。
【図１１】ウェブ・ブラウザのスクリーン画像を示す。

Claims

クライアント・マシンにおいてドキュメントをアクセスするための方法であって、
検索すべきドキュメントの優先ソースおよびマスタ・ソースの識別を含むターゲット・ドキュメント仕様を受け取るステップと、
前記優先ソースから前記ドキュメントを取り出すステップと、
前記マスタ・ソースに問い合わせて、取り出したドキュメントが最新のドキュメントであるか否かを判断するステップと、
前記取り出したドキュメントが最新のドキュメントであるとの判断が得られない場合、前記マスタ・ソースにある最新のドキュメントを使用して当該クライアント・マシン上の前記取り出したドキュメントを更新するステップと、
を含む方法。
前記ターゲット・ドキュメント仕様は、前記優先ソースおよび前記マスタ・ソースの識別の他に、１以上の代替ソースの識別を含む、請求項１に記載の方法。
前記クライアント・マシンはキャッシュを含み、前記取り出したドキュメントが前記優先ソース、前記マスタ・ソース及び前記代替ソースの識別とともに前記キャッシュに記憶される、請求項２に記載の方法。
前記優先ソースから前記ドキュメントを取り出す前に、前記キャッシュに記憶されているソース識別のいずれかが前記ターゲット・ドキュメント仕様に含まれる優先ソース、代替ソースおよびマスタ・ソースの識別のいずれかに一致するか否かを判断するステップと、
一致が見つかると、前記優先ソースの代わりに前記キャッシュから前記ドキュメントを取り出すステップと、
をさらに含む、請求項３に記載の方法。
一致が得られない場合、前記優先ソースから前記ドキュメントを取り出すことが可能であればそれを行うステップと、
前記優先ソースから前記ドキュメントを取り出すことができないとき、前記１以上の代替ソースの１つから前記ドキュメントを取り出すことが可能であればそれを行うステップと、
前記優先ソースおよび前記代替ソースから前記ドキュメントを取り出すことができないとき、前記マスタ・ソースから前記ドキュメントを取り出すステップと、
をさらに含む、請求項４に記載の方法。
請求項１乃至請求項５のいずれかに記載の方法を実行するためのプログラムを記憶したプログラム記憶媒体。