(57)【特許請求の範囲】
【請求項１】
１つ以上のキャッシュ文書を記憶したローカル・キャッシュを含むプロキシ・サーバを１つ以上と、監視される１つ以上のユニフォーム・リソース・ロケータ（ＵＲＬ）パターンを記憶した追跡リスト、および該追跡リストにおける位置の各々に対する現在のヒット回数を記憶してあるデータベースを含むヒット蓄積サーバとを備えるプロキシであって、クライアントおよびリモート・サーバに結合されている前記プロキシにおいて、前記プロキシに記憶された文書に対する要求を追跡する方法であって、
前記プロキシ・サーバが、文書に対するクライアント要求を受信するステップと、
前記文書が前記プロキシ・サーバのローカル・キャッシュから入手可能な場合、前記プロキシが、前記文書に対するヒット情報を記録するステップであって、前記プロキシ・サーバが前記ヒット蓄積サーバに対して、前記クライアント要求が前記ローカル・キャッシュから提供されたことを通知し、前記文書が前記ＵＲＬパターンの１つに対応する場合、前記ヒット蓄積サーバが、前記ヒット情報と前記文書のＵＲＬとを前記データベースのレコードに記憶する、前記プロキシが記録するステップと、
前記プロキシが、前記文書の前記ヒット情報をリモート・サイト運営管理者に提供するステップと、
を含み、
前記プロキシ・サーバが、前記ヒット蓄積サーバに対して通知することは、
前記ヒット蓄積サーバが、前記１つ以上のプロキシ・サーバにアクセス可能である共通記憶装置を監視すること、および
前記プロキシ・サーバが、該プロキシ・サーバのローカル・キャッシュによって前記クライアント要求を処理した場合、前記プロキシ・サーバが、前記クライアントが要求した文書に対するＵＲＬを含むエントリを前記共通記憶装置に記憶すること、
を含み、
前記監視される１つ以上のＵＲＬパターンが、文書のヒットを追跡すべきリモート・サイト上の１つ以上のディレクトリを表しており、前記方法は更に、
前記ヒット蓄積サーバが、前記エントリを検出するステップと、
前記ヒット蓄積サーバが、前記エントリ内のＵＲＬを、前記監視される１つ以上のＵＲＬパターンと比較して、前記ヒットを記録すべきか否かを決定するステップと、
を含み、
前記監視される１つ以上のＵＲＬパターンの各々には、０個以上の文字に一致するワイルドカードを含めることができること
を特徴とする方法。
【請求項２】
前記ヒット情報が、特定の文書に対するクライアント要求に、前記文書キャッシュから処理された回数を表わすカウントを含む、請求項１に記載の方法。
【請求項３】
前記ヒット情報が、前記カウントが対応する時間期間を識別するタイムスタンプを含む、請求項１又は２に記載の方法。
【請求項４】
前記リモート・サイト運営管理者が前記プロキシからの前記ヒット情報を要求し、それによって、前記ヒット情報をリモート・サイト運営管理者に提供するステップを開始する、請求項１〜３のいずれか一つに記載の方法。
【請求項５】
前記リモート・サイト運営管理者に提供される前記ヒット情報が、ハイパーテキスト・マークアップ言語（ＨＴＭＬ）報告の形態である、請求項１〜４のいずれか一つに記載の方法。
【請求項６】
前記プロキシが、前記ヒット情報をリモート・サイト運営管理者に提供するステップに先立って、前記リモート・サイト運営管理者の要求を認証する、請求項１〜５のいずれか一つに記載の方法。
【請求項７】
前記ヒット情報をリモート・サイト運営管理者へ提供する前記ステップが、前記プロキシが未要請情報を当該プロキシから前記リモート・サイト運営管理者に送信するステップを更に含む、請求項１〜６のいずれか一つに記載の方法。
【発明の詳細な説明】
発明の分野
本発明は、一般的に、クライアント−サーバ・コンピュータ・ネットワーク構築の分野に関する。更に特定すれば、本発明は、ウェブ・サイトのミラーリング（mirroring）、ミラー保護された（mirrored）サイトの運営管理者に対するヒットの通知、およびユニフォーム・リソース・ロケータ（ＵＲＬ）に基づくミラーリング・サーバ間におけるウェブ・コンテンツの割り当てに関するものである。
発明の背景
ワールド・ワイド・ウェブ（ウェブ）文書は、共通してＨＴＭＬ（ハイパーテキスト・マークアップ言語）で書かれている。ＨＴＭＬ文書は、典型的に、ウェブ・サーバ上に常駐し、ウェブ・クライアントによって要求される。例えば、インターネット上の通信トラフィック過剰、またはリモート・サイトの鈍い応答により、ウェブのブラウジング最中にしばしば遅延を生ずる場合がある。１つ以上のサーバを用意しリモート・サーバ（remote server）にミラーリング・ウェブ・サイトを配するのは、ウェブのブラウジングに伴う遅延を少なくする１つの手段である。これらミラーリング・サーバは、典型的に、総称して「プロキシ」と呼ばれたり、あるいは個々に「プロキシ・サーバ」と呼ばれており、頻繁にアクセスされるウェブ・サイトをローカル・キャッシュ内に記憶しておくことによって、アクセスが多い文書が繰り返し引き出されることをなくそうとするものである。したがって、ある特定のウェブ・ページに対する要求がクライアントから受信された場合、この特定のクライアントに関連するプロキシ・サーバは、ウェブ・ページが常駐するリモート・サイトではなく、最初にプロキシ・サーバ自体のキャッシュを見て、要求に応じようとする。要求された文書が自サーバ内で発見された場合、その要求はプロキシ・サーバによって処理することができ、その文書に対してリモート・サーバに次の要求を出すのを回避することができる。したがって、要求された文書の有効なコピーがプロキシ・サーバのローカル・キャッシュ内にない場合にのみ、リモート・サーバにアクセスすればよい。このようにして、インターネット上の通信トラフィック過剰やリモート・サーバの鈍い応答に直面するのを減らすことができる。
このミラーリング手法は、エンド・ユーザには有効であるが、リモート・サイト運営管理者がヒットを追跡するのが困難になる。ヒットとは、ウェブ・ページに対する要求であり、典型的に、ユーザがウェブ・ページに対するハイパーテキスト・リンクを選択することによって開始される。先に論じたミラーリング手法は、リモート・サーバが所与のウェブ・ページに対する全要求回数を追跡する機能を損なわせることになる。何故なら、先に論じたように、要求の内のいくつかはプロキシ・サーバによって横取りされ、処理されるからである。例えば、あるページの相対的な人気を追っていくため、または当該ページ上に広告を掲載している広告主にフィードバックを提供するために、所与のウェブ・ページまたはページ群に対して精度の高い要求のカウントを有するのは望ましいことである。したがって、プロキシによるユーザ・ヒットを追跡する機構、およびミラー保護されたサイトに通知することによって、リモート・サイト運営管理者がヒット総数（即ち、プロキシのローカル・キャッシュによって処理される要求およびリモート・サーバによって処理される要求）を精度高く追跡できるようにする機構が必要とされている。
現在のミラーリング手法に伴う別の問題として、プロキシのキャッシュ空間の割り当てが効率的でないことがあげられる。現在、各クライアントは、１つ以上のプロキシ・サーバに割り当てられている。したがって、アクティブな各クライアントが最後に要求した文書は、対応するプロキシ・サーバのキャッシュ内にある。異なるプロキシ・サーバに割り当てられた１つ以上のクライアントが同じ文書を最近要求したと仮定すると、数箇所のプロキシ・サーバに同じ文書がキャッシュされている可能性があり、頻繁に要求される文書のためのキャッシュ記憶空間が狭くなってしまう。更に、１つ以上のある文書に非常に人気があると、各プロキシ・サーバにキャッシュされている可能性もある。情報の冗長性はフォールト・トレランスには有用であるが、冗長性は組織化した方が好ましいであろう。以上の説明から、プロキシ内のキャッシュ空間割り当てを一層効率化する手段が必要とされている。即ち、ウェブのコンテンツの相互に排他的な部分を特定のプロキシ・サーバに対して割り当てることができれば望ましい。
発明の概要
ミラー保護されたサイトの運営管理者に、プロキシの文書キャッシュからヒット数を提供し、プロキシにおいて文書要求をディスパッチ（dispatch）し、プロキシ内の文書キャッシュ空間を一層効率的に割り当てる方法および装置について説明されている。プロキシは、最後に要求された文書を記憶する文書キャッシュを含む。プロキシは、クライアントおよびリモート・サーバに結合されている。プロキシは、プロキシの文書キャッシュが処理したクライアントからの要求に関する情報を維持する。この情報は、プロキシによってリモート・サイト運営管理者に提供される。このように、リモート・サイト運営管理者は、一層精度高く全てのヒット（即ち、プロキシの文書キャッシュが処理した要求およびリモート・サーバ自体が処理した要求の和）を追跡することができる。
本発明の別の態様によれば、プロキシは、クライアントの要求に対してディスパッチ方式を実施し、その結果、プロキシの文書キャッシュ空間割り当ての効率向上を図る。プロキシは、クライアントから文書要求を受信する。ユニフォーム・リソース・ロケータ（ＵＲＬ）が、文書要求に含まれている。プロキシは、このＵＲＬに基づいて、複数のプロキシ・サーバの１つに要求を送る。
本発明の別の態様によれば、プロキシは、ＵＲＬ上でハッシュ機能を実行し、ＵＲＬを複数のプロキシ・サーバの１つに正確にマッピングする。このようにして、好都合なことに、ウェブのコンテンツの相互に排他的な部分を、特定のプロキシ・サーバに割り当てることができる。
【図面の簡単な説明】
添付図面において、本発明を限定としてではなく、一例として示す。図面では、同様の参照番号は同様のエレメントを指すものとする。
図１は、ネットワークにおいてプロキシ・サーバに接続されているいくつかのクライアントを示すブロック図である。
図２は、本発明の一実施形態によるクライアントを示す図である。
図３は、本発明の一実施形態によるサーバのブロック図である。
図４は、本発明の一実施形態によるプロキシの構成要素の相互作用を示すデータ・フロー図である。
図５Ａは、本発明の一実施形態によるサイト追跡リストの一例の図である。
図５Ｂは、本発明の一実施形態による毎サイト・ヒット・データベースの一例の図である。
図６は、リモート・サーバのディレクトリ構造の一例の論理図である。
図７は、本発明の一実施形態による、ヒット蓄積を行う方法を示すフロー図である。
図８は、本発明の一実施形態によるヒット報告方法を示すフロー図である。
図９は、本発明の別の実施形態による、プロキシの構成要素の相互作用を示すデータ・フロー図である。
図１０は、本発明の一実施形態による文書の記憶を分離する要求をディスパッチする方法を示すフロー図である。
詳細な説明
クライアント−サーバ・コンピュータ・ネットワークにおいて、ミラー保護されたサイトの運営管理者に、プロキシの文書キャッシュからヒット数を提供し、一層効率化を図った文書キャッシュ方式を維持する方法および装置について説明する。以下の記載では、説明の目的上、本発明の完全な理解を得るために具体的な詳細を数多く明記する。しかしながら、本発明は、これら具体的な詳細以外でも実施可能であることは、当業者には明白であろう。更に、その他の場合、公知の構造およびデバイスはブロック図で示す。
本発明は種々のステップを含み、それについて以下に説明する。そのステップは、機械実行可能な命令に具体化することができ、その命令によりプログラムした汎用プロセッサまたは特殊目的プロセッサに、そのステップを実行させることができる。あるいは、本発明のステップは、当該ステップを実行するハードワイヤド・ロジックを内蔵した特定のハードウエア構成部品、またはプログラムしたコンピュータ構成部品とカスタム・ハードウエア構成部品との組み合わせによって実行することも可能である。
本発明の実施形態は、ＨＴＭＬ文書に関して説明するが、ここに記載する方法および装置は、テキスト・ファイル、画像（例えば、ＪＰＥＧおよびＧＩＦ）、オーディオ・ファイル（例えば、.WAV、.AU、および.AIFF）、ビデオ・ファイル（例えば、.MOV、および.AVI）等の他の形式の文書、およびウェブ上で一般に見られるその他の文書型にも同様に適用可能である。
システムの概要
本発明は、WebTVTMとして知られているシステムに含ませ、ユーザにインターネットへのアクセスを提供することができる。WebTVTMクライアントのユーザは、通常、直接発信電話（direct-dial telephone）（「完全に旧式の電話サービス」を表わすＰＯＴＳ）、ＩＳＤＮ（統合サービス・ディジタル・ネットワーク）、またはその他の同様の接続を通じてWebTVTMにアクセスし、ウェブをブラウズし、電子メール（イーメール）の送受信を行い、その他の種々のWebTVTMのネットワーク・サービスを使用する。WebTVTMネットワーク・サービスは、WebTVTMサーバが、WebTVTMクライアント内部に常駐するソフトウエアと共に、WebTVTMサーバ内部に常駐するソフトウエアを用いることによって提供される。
図１は、一実施形態によるWebTVTMネットワークの基本構成を示す。多数のWebTVTMクライアント１が、直接発信双方向データ接続２９を通じて、モデム・プール（modem pool）２に結合されている。直接発信双方向データ接続２９は、電話（ＰＯＴＳ、即ち、「完全に旧式の電話サービス」）、ＩＳＤＮ（統合サービス・ディジタル・ネットワーク）、またはその他の同様の形式の接続のいずれかとすることができる。モデム・プール２は、典型的に、当業界では従来から知られているようなルータを介して、インターネットのような従来からのネットワーク・インフラストラクチャを通じて多数のリモート・サーバ４に結合されている。また、WebTVTMシステムはWebTVTMサーバ５も含み、これは特に特にWebTVTMクライアント１を支援する。WebTVTMクライアント１は、各々、直接に又はモデム・プール２およびインターネット３を経由して、WebTVTMサーバ５へ接続されている。モデム・プール２は、今日インターネットや私的なネットワークへのアクセスを得るために世界中で見られるような、従来からのモデム・プールであることを注記しておく。
この記載では、説明を容易にするために、WebTVTMサーバ５は総じてあたかも単一のデバイスであるかのように論じ、WebTVTMサーバが提供する機能は、全体的にかかる単一のデバイスによって実行されるものとして論ずることにする点に注意されたい。しかしながら、WebTVTMサーバ５は、実際には、分散アーキテクチャ状に接続された多数の物理的および論理的デバイスから成る場合もあり、WebTVTMサービスによって提供される、以下で論ずる種々の機能は、実際には、多数のWebTVTMサーバ装置間で分配され得る。
クライアント・システムの一例
図２は、WebTVTMクライアント１を示す。WebTVTMクライアント１は、電子ユニット１０（以降「WebTVTMボックス１０」と呼ぶ）、通常のテレビジョン受像機１２、およびリモート・コントローラ１１を含む。本発明の代替実施形態では、WebTVTMボックス１０は、一体化ユニットとして、テレビジョン受像機１２に内蔵される。WebTVTMボックス１０は、ユーザにグラフィカル・ユーザ・インターフェースを与えるためのハードウエアおよびソフトウエアを含み、これによって、ユーザはWebTVTMネットワーク・サービスにアクセスし、ウェブをブラウズし、イーメールを送ることができ、それ以外にもインターネットにアクセスすることができる。
WebTVTMクライアント１は、表示装置として、テレビジョン受像機１２を用いる。WebTVTMボックス１０は、ビデオ・リンク６によって、テレビジョン受像機１２に結合されている。ビデオ・リンク６は、ＲＦ（無線周波数）、Ｓ−ビデオ、複合ビデオ、またはその他の同等のビデオ・リンクである。好適な実施形態では、クライアント１は、標準的なモデムおよびＩＳＤＮモデムを含むので、WebTVTMボックス１０とサーバ５との間の通信リンク２９は、電話（ＰＯＴＳ）接続２９ａまたはＩＳＤＮ接続２９ｂのいずれでも可能である。WebTVTMボックス１０は、電源線７から電力を受ける。
リモート・コントローラ１１は、ユーザがウェブをブラウズしたり、イーメールを送ったり、その他のインターネット関連機能を実行する際に、WebTVクライアント１を制御するために操作される。WebTVTMボックス１０は、赤外線（Ｉ−Ｒ）通信リンクを通じて、リモート・コントローラ１１からのコマンドを受信する。代替実施形態では、リモート・コントローラ１１とWebTVTMボックス１０との間のリンクは、ＲＦまたはいずれかの同等の送信モードでもよい。
サーバ・システムの一例
一般に、WebTVTMサーバ５は、概略的に図３に示すアーキテクチャを有する１つ以上のコンピュータ・システムを含む。図示のアーキテクチャは一例に過ぎず、本発明をこの特定のアーキテクチャに限定する訳ではないことを注記しておく。図示のアーキテクチャは、中央演算装置（ＣＰＵ）５０、ランダム・アクセス・メモリ（ＲＡＭ）５１、リード・オンリ・メモリ（ＲＯＭ）５２、大容量記憶装置５３、モデム５４，ネットワーク・インターフェース・カード（ＮＩＣ）５５、およびその他の様々な入出力（Ｉ／Ｏ）デバイス５６を含む。大容量記憶装置５３は、磁気、光学、またはその他の同様の記憶媒体を含む。Ｉ／Ｏデバイス５６は、表示モニタ、キーボード、カーソル制御デバイス等のいずれかまたは全てを含むことができる。モデム５４は、インターネットを通じてリモート・サーバ４へおよびリモート・サーバ４からのデータ授受を行うために用いられる。
先に注記したように、WebTVTMサーバ５は、実際には、分散アーキテクチャ状に接続された多数の物理デバイスおよび論理デバイスから成る場合もある。したがって、WebTVTMサービスの一部である他のデバイスとのデータ通信を行うため、ＮＩＣ５５が用いられる。また、モデム５４は、WebTVTMサービスの一部であり且つ図示のデバイスに地理的に接近して配置されていないその他のデバイスと通信するためにも使用可能である。
プロキシの一例
図４は、本発明の一実施形態によるWebTVTMプロキシ４００のキャッシュおよびヒット蓄積の特徴的構成を示す。この実施形態では、WebTVTMクライアント１に、ウェブおよびその他のWebTVTMサービスに対するアクセスを与える際、１箇所以上のWebTVTMサーバ５がプロキシ４００として動作する。更に具体的には、WebTVTMサーバ５は、「キャッシュ・プロキシ」（caching proxy）として機能する。この例では、プロキシ４００は、プロキシ・サーバ４０５およびヒット蓄積サーバ４１５を含む。プロキシ・サーバのローカル文書キャッシュ４６５による処理を受けたクライアント要求は、ヒット蓄積サーバ４１５に伝達される。以下で説明するが、ヒット蓄積サーバ４１５は、リモート・サイト運営管理者４８０のようなリモート・サイト運営管理者にヒット追跡情報を提供するように、データを維持し編成する。リモート・サイト運営管理者４８０は、リモート・サイトに対する統計データを集計することを許可された人、リモート・サイトのサイト、リモート・サイト自体、あるいはリモート・サイトに対する統計データを受信するように構成された自動化コンピュータ・システムまたはその他のデバイスを管理し維持することを許可された人のようなエンティティを含むことができる。
この実施形態では、プロキシ・サーバ４０５は、プロキシ要求プロセッサ４１０、文書キャッシュ４６５、文書データベース４６１、およびトランスコーダ（transcoder）４６６を含む。プロキシ要求プロセッサ４１０は、WebTVTMクライアント１からの要求を受信し、WebTVTMクライアント１に応答を送る。プロキシ要求プロセッサ４１０は、文書データベース４６１、文書キャッシュ４６５を維持し、更に、いつトランスコードを実行するのかについての決定を行う。文書キャッシュ４６５は、画像、テキスト・ファイル、オーディオ・ファイル、ビデオ・ファイル、およびWebTVTMクライアント１またはプロキシ・サーバ４０５のいずれかが頻繁に用いるその他の情報の一時的記憶に用いられる。
文書要求をクライアントから受信した場合、プロキシ要求プロセッサ４１０は、文書キャッシュ４６５の検索を実行することにより、文書キャッシュ４６５がその要求を処理するか否かについて判定を行う。文書が内部で見つかった場合、その文書を文書キャッシュ４６５から引き出し、応答と共にクライアントに転送することができる。しかしながら、要求された文書が見つからない場合、プロキシ要求プロセッサ４１０は、適切なサイトから文書を要求し、受信時にプロキシ要求プロセッサ４１０は、その文書を応答と共にクライアントに提供する。更に、プロキシ要求プロセッサ４１０は、今後の要求を予測し、その文書を文書キャッシュ４６５に記憶しておく。
プロキシ・サーバ４０５によってリモート・サーバ４から文書が引き出された場合、例えば、この文書に関する詳細な情報を、文書データベース４６１に記憶することができる。記憶した情報は、後にプロキシ・サーバ４０５により用いられ、当該文書に対する今後の要求に応答し、その文書の処理やダウンロードを高速化することができる。加えて、文書データベース４６１に記憶されている情報を利用することによって、トランスコード機能（transcoding function）およびWebTVTMサービスのその他の様々な機能も簡便化することができる。例えば、文書データベース４６１は、WebTVTMクライアント１がアクセスしたウェブ・ページについて、何らかの履歴および診断情報を含むことができる。
文書トランスコーダ４６６は、リモート・サーバ４から引き出したウェブ文書のコードを自動的に書き直すために用いられ、その目的は、（１）文書中のバグを訂正すること、（２）文書をクライアント１で表示する場合に発生する望ましくない影響を訂正すること、（３）サーバ５からクライアント１への文書送信の効率を向上させること、（４）クライアント１内部におけるハードウエアの伸長技術を一致させること、（５）テレビジョン受像機１２上に適合するように画像のサイズを変えること、（６）文書を他のフォーマットに変換し、互換性を備えること、（７）インライン画像（テキスト内に表示する画像）を有するウェブ・ページを表示する際にクライアント１に生ずる待ち時間を短縮すること、および（８）文書を変形し、より小さなメモリ空間に納まるようにすること等である。
一実施形態では、ヒット蓄積サーバ４１５は、パイパーテキスト・トランスポート・プロトコル（ＨＴＴＰ）インターフェースを備えるウェブ・サーバとして機能することでき、これによってリモート・サイト運営管理者は、ウェブ・ブラウザを用いて、それらのサイトに対する蓄積ヒットにアクセスすることができる。ヒット蓄積サーバ４１５は、ヒット・ログ４２０、ヒット蓄積プロセッサ４３０、サイト追跡リスト４２５、ヒット報告プロセッサ４５０、および毎サイト・ヒット（per site hit）・データベース４４０を含むことができる。所与のプロキシ・サーバからヒット蓄積サーバ４１５にヒットを伝達する方法の１つは、ヒット・ログ４２０のような共通の記憶装置を経由することである。ヒットを伝達するこの方法およびその他の方法については、以下で説明する。ヒット蓄積サーバ４１５にヒットをどのように伝達するかには無関係に、ヒット蓄積プロセッサ４３０のようなプロセスは、監視すべき位置のリストにヒットを突き合わせるために望ましいものである。かかる位置リストは、例えば、サイト追跡リスト４２５内に記憶され得る。この文脈においては、位置とは文書の位置のことを言う。位置は、ＵＲＬ、ディレクトリ経路、または特定の文書を一意に識別するためのその他の機構によって表わすことができる。ヒット蓄積プロセッサ４３０によって妥当性検査を受けたヒットは、毎サイト・ヒット・データベース４４０に記録される。したがって、毎サイト・ヒット・データベース４４０は、サイト追跡リスト４２５内に掲示されている各位置について、現在のヒット・カウントを有する。この実施形態では、ヒット報告プロセッサ４５０が、リモート・サイト運営管理者４８０のような、リモート・サイト運営管理者からヒット報告の要求を受信することができる。ヒット報告は、毎サイト・ヒット・データベース４４０から抽出され、例えば、ＨＴＭＬ報告内において要求元に送信され得る。
この実施形態では、プロキシ・サーバ４０５およびヒット蓄積サーバ４１５を別個のサーバとして示したが、双方の機能性を１つのWebTVTMサーバ５に結合することも可能である。加えて、プロキシ４００は、１つ以上のプロキシ・サーバ４０５を含むように拡張することも可能である。１つ以上のプロキシ・サーバ４０５を含むようにプロキシ４００を拡張した場合、ヒット蓄積サーバ４１５を１つだけ用いれば済む。
代替実施形態では、プロキシ・サーバ４０５がヒットを蓄積サーバ４１５に伝達する際、イベントを送ることができる永続的接続のようなネットワーク接続を経由してもよい。また、メッセージの受け渡しを用いることによって、プロキシ・サーバ４０５がデータグラムのようなメッセージをヒット蓄積サーバ４１５に送り、それに文書キャッシュ・ヒットを通知するようにしてもよい。サーバ間の情報伝達の手段には、他にも多くのものが可能であることは認められよう。
サイト追跡リストの一例
図５Ａは、本発明の一実施形態によるサイト追跡リストの一例を示す。この図は、３つのリモート・サイト（１）http://www.companyA.com/、（２）http://www.companyB.com/、および（３）http://www.companyC.com/についてのサイト追跡リスト・レコード５０５を含むサイト追跡リスト４３５を示す。この実施形態では、各サイト追跡リスト・レコード５０５は、１つ以上のＵＲＬパターン５１０のリストを含むことができる。
ＵＲＬパターン５１０のリストは、追跡すべきＵＲＬの先頭部分（例えば、プレフィックス）を識別するストリングのリストであり得る。この例では、プロキシ４０００は、ＵＲＬによって識別された文書についてのヒットを、サイト追跡リスト・レコード５０５の１つに指定されているＵＲＬパターン５１０のいずれかに一致するプレフィックスを用いて追跡する。次に、一致したＵＲＬパターンを収容するサイト追跡リスト・レコード５０５に対応する毎サイト・ヒット・データベース４４０内のレコードにヒットを記録（log）することができる。
このＵＲＬパターンの形態は、同じ文字が続く先頭部分で始まるウェブ・ページの特定の集合に対するヒットを追跡するのに有用である。例えば、会社Ａのウェブ・ページに対するＵＲＬは、全て、「http://www.company_A.com/」で始まる可能性がある。これに加えて、会社Ａが生産する製品に関連するウェブ・ページは、全て、「http://www.company_A.com/product/」という文字列で始まる可能性がある。更に、特定の製品に関連する複数のページは、全て、ＵＲＬのプレフィックス「http://www.company_A.com/product/<product_name>/」で始まるかも知れない。ここで、<product_name>は特定の製品を識別する。したがって、会社ＡのGizmo製品ラインに関連するページに対するヒットを追跡するためには、「http://www.company_A.com/product/Gizmo/」いうＵＲＬパターンを用い得る。同様に、会社Ａの製品全てに対するヒットを追跡するためには、「http://www.company_A.corn/product/」というＵＲＬパターンを使用し得る。
ＵＲＬパターンは、プレフィックスに限定される訳ではなく、ワイルド・カードまたはその他の特殊文字を含むパターンや、標準的な規則的表現形態のパターンのように、他の形態のＵＲＬパターンも使用可能である。
毎サイト・ヒット・データベースの一例
図５Ｂは、本発明の一実施形態による毎サイト・ヒット・データベースの一例を示す。図５Ａのサイト追跡リスト４２５において与えられる情報に基づいて、毎サイト・ヒット・データベース４４０として、毎サイト・ヒット・データベースの一例を表現することができる。この例では、毎サイト・ヒット・データベース４４０は、会社Ａ、会社Ｂおよび会社Ｃのリモート・サイトに対応する３つのサイト・ヒット・レコード５１５を含む。
この実施形態では、各サイト・ヒット・レコード５１５は、タイムスタンプ５２５を含む。タイムスタンプ５２５は、ヒットを蓄積してからの時間を示すことができる。したがって、この例では、１９９７年１月１６日１０時０１分５８秒以来、監視対象のＵＲＬには６回のヒットがあった。タイムスタンプ５２５は、最後のヒット報告を作成して以来経過した時間のように、別の方法で蓄積期間を表わしてもよいことを当業者は認めよう。
また、サイト・ヒット・レコード５１５は、リモート・サイト名５３０も含む。リモート・サイト名５３０は、前から後ろに向かって、会社Ａ、会社Ｂおよび会社Ｃに対応する。更に、サイト・ヒット・レコード５１５は、ヒット・リスト５２０も含む。この実施形態では、ヒット・リスト５２０は、タイムスタンプ５２５が示す時刻以降に、要求され、続いてプロキシのローカル・キャッシュ（例えば、文書キャッシュ４６５）から供給された文書のＵＲＬを含む。会社Ａに対するサイト・ヒット・レコード５１５によれば、adl.htmlウェブ・ページは、プロキシのローカル・キャッシュから３回要求され、供給された。同様に、sales.htmlおよびQ1.htmlウェブ・ページがプロキシのキャッシュからそれぞれ１回および２回提供された。特定のサイト・ヒット・レコード５１５における蓄積ヒット情報に基づいて、対応するリモート・サイト運営管理者に詳細なヒット報告を提供することができる。ヒット蓄積については、以下で更に論じる。
図６は、リモート・サーバ４上に存在可能なディレクトリ構造６００の一例の論理図である。このディレクトリ構造６００の一例は、ヒット数を追跡する柔軟な方法の必要性を示す。ウェブ・ページは、図示のディレクトリのいずれかまたは全てに内在する可能性がある。この例では、サイト追跡リスト・レコード５０５内部のＵＲＬパターンは、図示の階層で、特定のディレクトリまたは複数のディレクトリを識別することができる。
会社Ａに対するリモート・サイト運営管理者は、広告サブディレクトリ６０５およびイベント・サブディレクトリ６１０内のヒット数を知りたい場合がある。その理由は、これらのディレクトリのウェブ・ページ上に広告バナー（advertising banner）が示されており、広告主は、どれくらい多くのウェブ閲覧者がその広告を見ているのかについてフィードバックを欲しがる場合があるからである。あるいは、会社自体に、ある地域においてそのウェブ・サイトの統計を分析する業務上の理由がある可能性もある。それには無関係に、会社のサーバ上のルート・ディレクトリ６１５に対する全ヒットを単に追跡するだけでは不十分であることは明白である。
例えば、リモート・サイト運営管理者が関心のないディレクトリについて、ヒットを追跡することもあろう。所望の柔軟性に対処するために、ＵＲＬパターンのリストが用いられる。会社Ａが前述のサブディレクトリを追跡するために、次のＵＲＬパターン、即ち、「http://www.companyA.com/products/Events」および「http://www.companyA.com/products/Ads/」が記憶され得る。各サイト追跡リスト・レコード５０５内のＵＲＬパターン５１０のリストによって、リモート・サイトは、例えば、ユーザのヒットを追跡したい特定のディレクトリを数え上げることができる。
ワイルド・カードにＵＲＬパターンの形態を与えることの利点は、ディレクトリ構造６００を参照することによって明白となる。「＊」記号をワイルド・カードとする。即ち、これは０個以上の文字に一致する。会社Ａは新聞発表のあるサブディレクトリを２つ有しているので、双方におけるヒットを追跡する便利な方法は、ＵＲＬパターン「http://www.companyA.com/*press_releases/」を用いることである。ワイルド・カードを用いないと、同等のＵＲＬパターンは「http://www.companyA.com/press_releases/」および「http://www.companyA.com/products/press_releases/」になる。このように、ワイルド・カードおよび規則的な表現によって、ＵＲＬパターンの指定に効率および利便性が追加されることが認められよう。
ヒットの蓄積
図７は、本発明の一実施形態によるヒット蓄積を実行する方法を示すフロー図である。この実施形態では、各々のサイト・ヒット・レコード５１５は、リモート・サイト（例えば、名称５３０）の指示とヒット蓄積を開始する時刻を表わすタイムスタンプ５２５とを有する初期状態において開始する。初期状態では、ヒット蓄積サーバ４１５は、プロキシのローカル・キャッシュがクライアントの要求を処理したという指示を待つ（ステップ７１０）。例えば、ヒット蓄積プロセッサ４３０は、新たな入力がヒット・ログ４２０に対して行われたことを判定する。
プロキシ４００がキャッシュされた応答を処理したという指示を受信すると、ヒット蓄積サーバ４１５は、プロキシのローカル・キャッシュから引き出された文書のＵＲＬが、ヒットを追跡する対象であるか否かについて判定を行う。先に論じたように、全てのヒットを追跡する訳ではない。この実施形態では、先に論じたサイト追跡リスト４２５のような追跡リスト内に既に登録されているＵＲＬに一致する文書についてのみ、ヒットを追跡する。したがって、ヒット蓄積プロセッサ４３０は、引き出した文書のＵＲＬを、各サイト追跡リストのレコード５０５のＵＲＬパターン５１０と比較し、毎サイト・ヒットデータベース４４０にそのヒットを記録するか否かについて判定を行う（ステップ７２０）。引き出した文書に一致するＵＲＬパターン５１０がない場合、そのヒットを無視する。それ以外の場合、引き出した文書がＵＲＬパターン５１０のいずれかに一致するならば、毎サイト・ヒット・データベース４４０内の適切なサイト・ヒット・レコード５１５を更新する（ステップ７３０）。
サイト・ヒット・レコード５１５の更新については、図５Ｂに関して簡単に説明することができる。この実施形態では、適切なサイト・ヒット・レコード５１５は、引き出した文書のＵＲＬに一致するエントリについて検索される。引き出した文書のＵＲＬが、サイト・ヒット・レコード５１５に対するヒット・リスト５２０内に未だ存在しない場合、そのＵＲＬを追加し、そのカウントを１にセットする。これが当該文書の最初のヒットだからである。しかしながら、引き出した文書のＵＲＬが既にヒット・リスト５２０にある場合（少なくとも１回過去にヒットがあったことを意味する）には、対応するカウントを増加させるだけである。このように、プロキシのローカル・キャッシュから引き出した各文書が追跡対象のＵＲＬパターンに一致する場合、その文書はヒット・リスト５２０内にエントリを有しており、対応するカウントがキャッシュ・ヒット数を示す。
ヒット報告
次に図８を参照し、本発明の一実施形態によるヒット報告方法を示す。本発明のこの実施形態では、ヒット蓄積サーバ４１５は、その別の責務に加えて、ＨＴＴＰインターフェースを備えるウェブ・サーバとしても機能し、このインターフェースによって、リモート・サイト運営管理者は、それらの各追跡対象のサイトに対して蓄積されているヒットにアクセスすることが可能となる。ヒット報告プロセッサ４５０は、リモート・サイト運営管理者からの要求を受信するまで待つ（ステップ８１０）。ヒット蓄積サーバ４１５上のＨＴＴＰアドレスを用いて、情報の要求元を識別することができるようにするのが好ましい。例えば、会社Ａのヒット報告は、”http://www.webtv.net/hits/company_a」のヒット蓄積サーバ４１５上においてアクセスすることができる。
ヒット報告に対するアクセスを制限するために、セキュア・ソケット・レイヤ（ＳＳＬ：Secure Sockets Layer）のような安全通信技術またはその他の使用可能な安全通信プロトコルを用い、ネットワーク全体で暗号化通信を行うことによって、ヒット情報を秘密に保持することができる。加えて、特定のリモート・サーバのみ又は個々のサーバが情報にアクセスできることを確認するために、報告要求の認証を行うことができる（ステップ８２０）。
一旦リモート・サイト運営管理者からの要求を受信し、随意に認証したなら、特定のサイト・ヒット・レコード５１５に対するヒット・リスト５２０のような、蓄積されたヒット・データから報告を作成することができる（ステップ８３０）。この実施形態では、報告は、ＵＲＬのリスト、および最後の報告以来のそれらの対応するカウントを含み得る。ウェブを通じた便利なアクセスのためには、報告はＨＴＭＬフォーマットでフォーマットされ得る。また、リモート・サイト運営管理者の便宜のためには、蓄積の開始点を識別するタイムスタンプを報告に含めてもよい。ＵＲＬの特定性（specificity）レベルを文書レベルにすることによって、リモート・サイト運営管理者が、個々の文書に対するヒット数を判定できるようにすることができる。しかしながら、これは、例えば、補足的にディレクトリによってヒットを要約する場合にも役立つであろう。ヒット報告のフォーマットおよび配列には、他にも多数の方法が可能であることが認められよう。
報告をフォーマットし終えた後、この報告を含む応答をリモート・サイト運営管理者に送信する（ステップ８４０）。
この実施形態では、図７のヒット蓄積を再開する前に、サイト・ヒット・レコード５１５に蓄積したデータをクリアし（ステップ８５０）、更にタイプスタンプ５２５もリセットし、現時点を反映させる。プロキシから報告を引き出すためのこれまでのステップは、精度の高い総ヒット・カウントを必要とするときはいつでも、リモート・サイト運営管理者の都合で、周期的に繰り返すことができる。
代替実施形態では、ヒットの報告は、多数の他の方法でリモート・サイトに提供することも可能である。ヒットの報告は、リモート・サイト運営管理者からの要求によって開始される必要はない。例えば、プロキシが、イーメールを通じて、要請なくヒットの報告を周期的に送ったり、プロキシが、リモート・サイト運営管理者が指定したデバイスに、周期的にヒットの更新をダウンロードしたり、あるいはヒット報告をデータグラムの形態でリモート・サイト運営管理者に送信することも可能である。いずれにしても、本発明の譲受人は様々な報告機構が可能であることを認めている。
プロキシ内におけるキャッシュ空間の割り当て
図９は、本発明の別の実施形態によるプロキシの構成要素間の相互作用を示すデータ・フロー図である。この実施形態では、プロキシ９００は、ディスパッチャ９１０とヒット蓄積サーバ４１５とに通信状態に結合されている複数のプロキシ・サーバ４０５を含む。関連するクライアントの要求に基づいて、所与のプロキシ・サーバにキャッシュされているコンテンツを判定できるようにする代わりに、ディスパッチャ９１０が実行するハッシュ・アルゴリズムによって、ウェブのコンテンツをプロキシ・サーバ４０５間に分配することができる。ハッシュ・アルゴリズムは、所与のＵＲＬを複数のプロキシ・サーバ４０５の内の１つのみにマッピングすることが好ましい。これを達成可能にするために、Message Digest 5（ＭＤ５）ハッシュ・アルゴリズムのような、セキュア・ハッシュ・アルゴリズムの出力の一部を用いる。ハッシュ・アルゴリズムは、プロキシ９００内のプロキシ・サーバ４０５の各々に、ある範囲のＵＲＬを指定する機構であると考えることができる。
この実施形態では、ディスパッチャ９１０は、ＵＲＬを含む文書要求を、WebTVTMクライアント１のようなクライアントから受信する。要求の中のＵＲＬに基づいて、ディスパッチャは、文書がキャッシュされているはずのプロキシ・サーバ４０５を判定し、クライアントの要求をこのプロキシ・サーバ４０５へ送る。クライアントが要求する文書がプロキシ・サーバのローカル文書キャッシュ４６５内で見つからない場合、プロキシ・サーバは、適切なサーバ（例えば、リモート・サーバ）から文書を要求し、当該サーバから受信したなら、その文書をキャッシュする。
冗長性が望ましい場合、ＵＲＬのハッシュ結果を用いて、単一のプロキシ・サーバ４０５の代わりに、２つ以上のプロキシ・サーバのクラスタを識別することができる。このように、人気のある文書を支援するために必要な負荷を、１群のプロキシ・サーバに分散することができる。
代替実施形態では、非集中ディスパッチ方式（decentralized dispatching scheme）を実施することができる。例えば、プロキシ・サーバ４０５は、相互接続されたリング形態を形成するように配列することができ、ディスパッチャ９１０の機能性は、各プロキシ・サーバ４０５内に組み込むことができる。この実施形態では、クライアントの文書要求は、最初に、リング内のプロキシ・サーバ４０５の１つによって処理することができる。要求された文書が最初のプロキシ・サーバのローカル・キャッシュ内で見つからない場合、最初のプロキシ・サーバは、先に論じたハッシュ方式に基づいて、その要求を適切なプロキシ・サーバに送ることができる。
図１０は、本発明の一実施形態による、文書の記憶を分離する要求をディスパッチする方法を示すフロー図である。これまで集中化および非集中化要求ディスパッチ機構について論じたが、以下に述べる方法は通常双方に適用可能である。この実施形態では、最初に、クライアントからの文書要求を受信する（ステップ１０１０）。
ディスパッチャ９１０のような集中ディスパッチャが要求を受信した場合、ＵＲＬに基づいて、更に、ハッシュ・アルゴリズムの出力に基づいて、適切なプロキシ・サーバを判定する（ステップ１０２０）。
しかしながら、非集中ディスパッチ環境では、クライアントの要求を受信した最初のプロキシ・サーバは、それが適切なプロキシ・サーバであると仮定し、最初にそのローカル文書キャッシュ４６５をチェックする。文書がない場合、プロキシ・サーバは、ＵＲＬに対してハッシュ・アルゴリズムを実行し、残りのプロキシ・サーバの内のどれがその要求に適しているかについて判定を行う（ステップ１０２０）。
クライアントの要求に適切なプロキシ・サーバを判定した後、要求をそのプロキシ・サーバへ送る（ステップ１０３０）。プロキシ・サーバ４０５は、そのローカル文書キャッシュ４６５によって要求を処理しようとする。キャッシュ・ヒットが生じた場合、文書はプロキシ・サーバのローカル文書キャッシュ４６５から直ちに入手可能である。しかしながら、キャッシュ・ミスが発生した場合、プロキシ・サーバ４０５は、適切なサーバから文書を引き出し、コピーを自サーバ内に記憶する。いずれにせよ、集中または非集中ディスパッチ機構は、最終的にサーバからの応答（例えば、クライアントが要求した文書）を受信する（ステップ１０４０）。最後に、典型的にＨＴＭＬ文書の形態で応答をクライアントに送出する（ステップ１０５０）。この文書キャッシュ方法は、文書のＵＲＬに基づいて、ウェブのコンテンツを分離する。各ＵＲＬは１つのプロキシ・サーバ４０５のみにマッピングするので、この手法は、不要な冗長性を回避することによって、プロキシのキャッシュ空間を一層効率的に割り当てる。
以上の明細書においては、本発明をその具体的な実施形態を参照しながら説明した。しかしながら、本発明のより広い精神および範囲から逸脱することなく、種々の修正や変更が可能であることは明白である。したがって、本明細書および図面は、限定的な意味ではなく、例示として見なすべきである。
【図１】
0004364947.tif 000002
【図２】
0004364947.tif 000003
【図３】
0004364947.tif 000004
【図４】
0004364947.tif 000005
【図５Ａ】
0004364947.tif 000006
【図５Ｂ】
0004364947.tif 000007
【図６】
0004364947.tif 000008
【図７】
0004364947.tif 000009
【図８】
0004364947.tif 000010
【図９】
0004364947.tif 000011
【図１０】
0004364947.tif 000012