(57)【要約】      （修正有）【課題】ウエブ資源を持続的に保存するための方法および装置。【解決手段】ウエブ資源を識別するＵＲＬが、タイムスタンプを含むように強化され、ウエブブラウザは、所望の日時の指定を容易にする機構を備えることも、手操作にて、タイムスタンプを、ブラウザの“ロケーション”ウインドウに指定されるように付加するようにすることもできる。パシステントウエブサーバは、タイムスタンプを含むＵＲＬを受信し、アーカイブから正しいウエブページを検索し、リクエストされたウエブページを修正することで、埋め込まれたハイパーリンクをリクエストされたウエブページと同一のタイムスタンプを含むように更新し、リクエストされたページをクライアントに送り返す。パシステントウエブサーバは、ウエブ資源の全てのバージョンを格納するためのパシステントアーカイブを備え、ウエブユーザはこれら全てのバージョンに持続的にアクセスすることが可能になる。【選択図】  図３
2005251190.tif 000002
【特許請求の範囲】
【請求項１】
複数のバージョンを有する電子ドキュメントを持続的に格納するための方法であって、
作成時刻のタイムスタンプによって特定されるバージョンの前記電子ドキュメントの１つを取得するステップ、及び
リクエストに応じて、リクエストされたタイムスタンプに基づいたタイムスタンプを含むように前記取得されたバージョンの電子ドキュメントにおける１以上の埋め込まれたハイパーリンクを更新するステップ
からなる方法。
【請求項２】
請求項１記載の方法において、該リクエストされたタイムスタンプとともにリンクされた電子ドキュメントが存在しない場合は、前記少なくとも１以上の更新済みの埋め込まれたハイパーリンクが、該リクエストされたタイムスタンプより前の最新のタイムスタンプを持つ該リンクされた電子ドキュメントのバージョンを指し示す方法。
【請求項３】
請求項１記載の方法において、前記取得されたバージョンの電子ドキュメントは前記リクエストされたタイムスタンプを用いて選択される方法。
【請求項４】
請求項１記載の方法において、前記含まれたタイムスタンプは前記取得されたバージョンの電子ドキュメントの前記作成時刻のタイムスタンプに基づく方法。
【請求項５】
請求項１記載の方法であって、さらに、前記更新済みのバージョンの電子ドキュメントをクライアントに送信するステップからなる方法。
【請求項６】
請求項１記載の方法であって、さらに、前記電子ドキュメントの前のバージョンが実質的に同一である場合、前記電子ドキュメントの前のバージョンへのポインタを格納するステップからなる方法。
【請求項７】
請求項１記載の方法において、前記電子ドキュメントを識別するアドレスが前記リクエストされたタイムスタンプを含む方法。
【請求項８】
請求項７記載の方法において、前記アドレスがＵＲＬである方法。
【請求項９】
請求項８記載の方法において、前記ＵＲＬが前記タイムスタンプを識別するための関連するリクエストヘッダを有する方法。
【請求項１０】
請求項１記載の方法において、前記取得するステップが、前記リクエストされたタイムスタンプを持つ前記電子ドキュメントのバージョンが存在しない場合、前記リクエストされたタイムスタンプの前の最新のタイムスタンプを持つ前記電子ドキュメントのバージョンを取得する方法。
【請求項１１】
請求項１記載の方法において、前記リクエストされたタイムスタンプがブラウザを用いて指定される方法。
【請求項１２】
請求項１記載の方法において、前記リクエストされたタイムスタンプが相対タイムスタンプである方法。
【請求項１３】
複数のバージョンを持つ電子ドキュメントを格納するためのシステムであって、
前記電子ドキュメントの前記複数のバージョンを電子ドキュメントのアーカイブ内に格納するためのメモリ、及び
前記メモリに結合されたプロセッサからなり、該プロセッサが、
作成時刻のタイムスタンプによって特定されるバージョンの前記電子ドキュメントの１つを取得し、
リクエストに応じて、リクエストされたタイムスタンプに基づいたタイムスタンプを含むように前記取得されたバージョンの電子ドキュメントにおける１以上の埋め込まれたハイパーリンクを更新する
ように構成されたシステム。
【請求項１４】
請求項１３記載のシステムにおいて、該リクエストされたタイムスタンプとともにリンクされた電子ドキュメントが存在しない場合は、前記少なくとも１以上の更新済みの埋め込まれたハイパーリンクが、該リクエストされたタイムスタンプより前の最新のタイムスタンプを持つ該リンクされた電子ドキュメントのバージョンを指し示すシステム。
【請求項１５】
請求項１３記載のシステムにおいて、前記取得されたバージョンの電子ドキュメントは前記リクエストされたタイムスタンプを用いて選択されるシステム。
【請求項１６】
請求項１３記載のシステムにおいて、前記含まれたタイムスタンプは前記取得されたバージョンの電子ドキュメントの前記作成時刻のタイムスタンプに基づくシステム。
【請求項１７】
請求項１３記載のシステムにおいて、前記プロセッサが、さらに、前記更新済みのバージョンの電子ドキュメントをクライアントに送信するように構成されたシステム。
【請求項１８】
請求項１３記載のシステムにおいて、前記プロセッサが、さらに、前記電子ドキュメントの前のバージョンが実質的に同一である場合、前記電子ドキュメントの前のバージョンへのポインタを格納するように構成されたシステム。
【請求項１９】
請求項１３記載のシステムにおいて、前記電子ドキュメントを識別するアドレスが前記リクエストされたタイムスタンプを含むシステム。
【請求項２０】
請求項１９記載のシステムにおいて、前記アドレスがＵＲＬであるシステム。
【請求項２１】
請求項２０記載のシステムにおいて、前記ＵＲＬが前記タイムスタンプを識別するための関連するリクエストヘッダを有するシステム。
【請求項２２】
請求項１３記載のシステムにおいて、前記リクエストされたタイムスタンプがブラウザを用いて指定されるシステム。
【請求項２３】
請求項１３記載のシステムにおいて、前記プロセッサが、さらに、前記リクエストされたタイムスタンプを持つ前記電子ドキュメントのバージョンが存在しない場合、前記リクエストされたタイムスタンプの前の最新のタイムスタンプを持つ前記電子ドキュメントのバージョンを取得するシステム。
【請求項２４】
請求項１３記載のシステムにおいて、前記リクエストされたタイムスタンプが相対タイムスタンプであるシステム。
【請求項２５】
電子ドキュメントにアクセスするための装置であって、
その上に実現されたコンピュータ読取可能なプログラムコード手段を持つコンピュータ読取可能媒体であって、該コンピュータ読取可能なプログラムコード手段がコンピュータに対して、
作成時刻のタイムスタンプによって特定されるバージョンの前記電子ドキュメントの１つを取得し、
リクエストに応じて、リクエストされたタイムスタンプに基づいたタイムスタンプを含むように前記取得されたバージョンの電子ドキュメントにおける１以上の埋め込まれたハイパーリンクを更新する
ように命令するコンピュータ読取可能媒体
からなることを特徴とする装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、本発明と同時に出願され、本発明の譲受人に譲渡された、以下の合衆国特許出願、つまり：“A Method And Apparatus For Persistent Access to Web Resources（ウエブ資源に持続的にアクセスするための方法および装置）”（Attorney Docket Number Ong 9）、“A Method And Apparatus For Persistent Access to Web Resources Using Relative Time-Stamps（ウエブ資源に相対タイムスタンプを用いて持続的にアクセスするための方法および装置）”（Attorney Docket Number Ong 10）、および“A Method And Apparatus For Resolving Domain Names of Persistent Web Resources（持続的ウエブ資源のドメイン名を解決するための方法および装置）”（Attorney Docket Number Ong 11）とも関連するために、これらについても参照されたい。
【背景技術】
【０００２】
本発明は、インターネット資源へのアクセス技法、より詳細には、インターネット資源へのパシステント（持続的）なアクセスを確保するための方法および装置に関する。
【０００３】
World Wide Web（“ウエブ（Web）”）は、莫大な量の情報を提出および配布するためのダイナミック（動的）な方法を提供する。ウエブ上の情報には、インターネットに接続されており、例えば、Netscape Communications Corporation of Mountain View,CA.から市販されるNetscape Navigator CommunicatorＴＭなどのブラウザを所有する人なら誰でもアクセスすることができる。ウエブは多数の媒体オプションをユーザに提供する。ウエブは、当初は、主としてパーソナルコンピュータを介してのアクセスに限られていたが、最近では、普遍的にますます多様なパーソナル電子デバイスから利用（アクセス）できるようになりつつある。加えて、ディスプレイ技術も絶えず進歩しており、ウエブは、終局的には、従来のペーパベースの媒体に完全に取って代ることも予測される。
【０００４】
ペーパベースの媒体は、通常は、関連するタイムスタンプを持ち、過去のある任意の時点において提出された情報を簡単に調べることができる。例えば、新聞の記事は、その新聞の特定の出版日を指定することができれば、信頼できるリファレンス（参照資料）として引用することができる。ただし、ウエブの内容（コンテント）は、ダイナミックな（動的な／可変的な）性格を持ち、このため、ウエブのドキュメントは、通常は、信頼できる参照源とはならない。つまり、現時点では、ウエブの内容は、将来の任意の時点で同一の形式にて存在し、これに、将来も引き続いて、同一の均一資源ロケーター（Uniform Resource Locator，“URL”）にて、持続的にアドレス（アクセス）できるという保証はない。つまり、幾つかのウエブサイトは、幾らかのアーカイブ（長期保存）ウエブドキュメントへのアクセスを提供するが、ただし、ユーザは、これら過去のウエブドキュメントに、たとえ可能であったとしても、一貫した予測可能なやり方でアクセスすることはできない。
【０００５】
非営利のコンピュータライブラリサービスおよびリサーチ機関であるオンラインコンピュータライブラリセンタ（Online Computer Library Center,Inc.，“OCLC”）は、一般インターネット資源に対するインターネットアドレスおよび別名を管理するためのＯＣＬＣ  ＰＵＲＬ（持続的均一資源ロケーター“Persistent Uniform Resource Locator”）と呼ばれるソフトウエアツールを提供する。技術均一資源ロケーター（Persistent Uniform Resource Locator，PURL）は、インターネット資源に、高信頼に、長期間に渡って、最小の保守にて、アクセスできることを保証するために、インターネット資源に対するフレキシブルなネーミング（名前の指定）および名前分析サービスを提供する。概略的には、ＯＣＬＣ  ＰＵＲＬは、ウエブ資源をどこに保存すべきかについての助言をインターネットユーザに与える。ただし、上述のように、インターネットは、絶えず、拡張および変化を続けている。そして、いったん、ＵＲＬが変更されると、そのＵＲＬを用いての以前の全ての参照（アクセス）は無効となり、ユーザは、もはや、そのインターネット資源にはアクセスできなくなる。しかも、これら変更の管理は、しばしば、非常に煩雑となる。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
均一資源ロケーター（ＵＳＲ）は、インターネット資源の位置（ロケーション）を直接にポイントするが、持続的均一資源ロケーター（ＵＳＲ）は、ＰＵＲＬを実際のＵＲＬに翻訳する中間のアドレス解決（翻訳）サービスをポイントする。いったん、ウエブ資源がＯＣＬＣに登録され、ＰＵＲＬを割り当てられると、そのウエブ資源はＰＵＲＬを介してアクセスすることが可能になる。ＰＵＲＬは、ある資源に、その資源の位置が変わった場合でも、パシステント（持続的）な名前を割り当てる。こうして、ウエブ資源および他の資源内で参照されるＰＵＲＬは、時間がたっても持続的に有効となり、ウエブ資源が移動される度にその参照を更新する必要はなくなる（ＰＵＲＬは持続的なものとなり、ウエブ資源が移動された場合でも、同一のＰＵＲＬを用いて同一のウエブ資源および他の資源の内容にアクセスすることが可能になる）。ただし、ＯＣＬＣによって維持されるＰＵＲＬ“転送（forwarding）”アドレスは、常に、更新された状態に維持することを必要とされる。換言すれば、現状では、ドキュメントを移動する度に、ＯＣＬＣに、そのドキュメントの新たなアドレスを通知することが要求される。
【課題を解決するための手段】
【０００７】
本発明は、一般的には、ウエブ資源へのパシステント（持続的）なアクセスを提供するための方法および装置に関する。本発明の一面によると、ウエブ資源を識別するための“ＵＲＬ”が、オプションとして、タイムスタンプを含むように強化される。このタイムスタンプは、“ＵＲＬ”内に、任意の適当な形式にて指定することができる。ウエブブラウザおよびウエブサーバが開示されるが、これらは、タイムスタンプパラメータを収容し、ユーザが、明確な標的（ターゲット）時間にて、任意のウエブアドレスを参照することを可能にする。こうして、本発明は、ウエブ（資源）を、ペーパベースの媒体と殆ど同様な、編成された、信頼できる参照源とすることを可能にする。
【０００８】
開示されるウエブブラウザは、オプションとして、所望の日時の指定を容易にする機構を備えることも、あるいは、ユーザが、手操作にて、タイムスタンプを、ＵＲＬに、ブラウザの“ロケーション（Location）”ウインドウに指定されるように付加するようにすることもできる。一つの実施例によると、パシステント（持続的）ウエブサーバは、（１）タイムスタンプを含むＵＲＬを受信し、（２）アーカイブからリクエストされたウエブページに対応するベースウエブページを検索し、（３）ベースウエブページを修正することで、埋め込まれたハイパーリンクをリクエストされたウエブページと同一のタイムスタンプを含むように更新し、（４）更新されたページをリクエストされたページとしてクライアントに送り返す。パシステント（持続的）ウエブサーバは、抽出されたＵＲＬを選択されたタイムスタンプフォーマットに従って翻訳する。加えて、パシステントウエブサーバは、ウエブ資源の全てのバージョンを格納するためのパシステント（持続的）アーカイブを備え、ウエブユーザはこれら全てのバージョンに持続的にアクセスすることが可能になる。本発明は、任意のウエブ資源へのタイムスタンプを持つ参照が所望の資料を参照することを保証する。こうして、ウエブ上で歴史的な（過去の）調査を行なっている人が、任意の時間期間に対する（任意の時間期間に対して有効な）任意の情報を検索できるようにする。
【発明を実施するための最良の形態】
【０００９】
図１は、インターネットあるいはWorld Wide Web（“ウエブ（Web）”）環境１３０を通じて一つあるいは複数のパシステント（持続的）ウエブサーバ１４０、１５０からの情報にアクセスする本発明によるウエブブラウザ１００を示す。本発明は、テキスト、オーディオ、ビデオ、アニメーションドキュメントなどを含むウエブ資源、すなわち電子ドキュメントへのパシステントなアクセスを提供する（過去のドキュメントにも持続的にアクセスできるようにする）。本発明の一つの実施例なおいては、ウエブ資源を識別する均一資源ロケーター（“ＵＳＲ”）が、タイムスタンプを含むように強化される。ウエブブラウザ１００およびパシステントウエブサーバ１４０、１５０は、追加のタイムスタンプパラメータを備え、こうして、ユーザは、特定の目標日付を持つ任意のウエブアドレスを参照することが可能となる（過去の任意の特定の日付のウエブ資源にアクセスすることが可能になる）。例えば、“http://cnn.com?time=2+2+1997”なるＵＲＬは、１９９７年２月２日付けのＣＮＮホームページのウエブ内容（コンテント）を指定する。このようにして、ウエブは、編成された、しかも、ペーパベースの媒体と同程度に信頼できる参照源となり得る。
【００１０】
一例としてのタイムスタンプのフォーマット
タイムスタンプは、（“ＵＲＬ”）内に任意の適当なフォーマットにて含めることができる（この方法は当業者においては明白であると思われる）。例えば、www.Lucent.comのウエブページの１９９８年２月２日の時点での内容を参照する（にアクセスする）ためには、ＵＲＬは、以下のように表される：
http://www.lucent.com?time=2+2+1998
もう一つのバリエーションとして、追加の時間粒度（より詳細な時間の指定）を、ＵＲＬ内に特定の日の時刻を含めることで、指定することもできる。例えば、www.Lucent.comのウエブページの１９９８年２月２日1:23.p.mの時点での内容にアクセスするためには、ＵＲＬは、以下のように表される：
http://www.lucent.com?time=13+23+2+2+1998
特に改めて指定されない限り、時間帯は、ユーザの省略時の時間帯であるものと想定される。上述の一例としてのタイムスタンプのフォーマットは、Commom Gateway Interface（CGI）による探索引数に従う。勿論、月、日、年（あるいは他の時間単位）は、任意の順番で表すことができる。ＵＲＬがタイムスタンプを持たない場合は、省略時の値は、最も最新のバージョンとなる。
【００１１】
加えて、相対タイムスタンプを用いることもできる。例えば、www.Lucent.comのウエブページの昨日の時点での内容にアクセスするためには、ＵＲＬは、以下のように表される：
http://www.lucent.com?time=yesterday
さらに、埋め込まれたハイパーリンクが相対タイムスタンプを含む場合は、その相対タイムスタンプは現在のウエブページに基づくこととなる。つまり、現在のウエブページが：
http://www.lucent.com?time=1998_1_10
なる形式のＵＲＬを持ち、さらに、このページが：
http://www.lucent.com?time=yesterday
なる形式の埋め込まれたハイパーリンクを持つ場合、ブラウザおよびサーバは、そのＵＲＬを：
http://www.lucent.com?time=1998_1_9
なる形式を持つものと解釈および翻訳することとなる。
【００１２】
他の相対タイムスタンプとして、現在のウエブページの時刻からの時間オフセットを含めることも、例えば、指定された時間期間を足したり、引いたりすることも考えられる。この方法では、例えば、“+10D”は、現時点で見られるウエブページの日付に１０日を加えた時刻（日付）を示すこととなる。
【００１３】
あるドキュメントより（現ドキュメントのタイムスタンプを起点として）前にあるいは後にアーカイブ（保存）されたバージョンを参照する（にアクセスする）ために、“next_archive”、あるいは“previous_archive”なるラベルを用いてＵＲＬを表すこともできる。この場合は、サーバは、アーカイブを通じて（内を）所望のドキュメ ントが見つかるまで探索することとなる。例えば、現在見ているドキュメントが：
http://www.lucent.com/doc.html?rtime=1997_5_12
なる形式のＵＲＬを持ち、同一のドキュメントの7/2/97、6/1/97、4/1/97および3/1/97なる年月日にアーカイブ（保存）された異なるバージョンが存在する場合は、現ドキュメント内に以下のリンクを用いることで、これら記録の一つを参照（一つにアクセス）することができる：
doc.html?rtime=next_archive
このような相対アーカイブタイムスタンプを用いると、同一ドキュメントの異なるバージョン間での移動がより効率的になる。
【００１４】
ここで、“リクエスト・ヘッダスキーム（request-header scheme）”と呼ばれるもう一つの実現においては、タイムスタンプは、ＨＴＴＰリクエストヘッダの一つとして、例えば：
Time-Stamp:June 9,1998
【００１５】
なる形式にて表される。
ここで、“専用文字スキーム（special character scheme）”と呼ばれるもう一つの実現においては、ＵＲＬ内に含まれるタイムスタンプを示すために、専用文字が以下のように用いられる：
http://www.cnnfn.com;time=2+2+1998&timezone=server
【００１６】
ウエブサーバ
ウエブブラウザ１００は、従来のブラウザ、例えば、Microsoft Internet ExplorerＴＭあるいはNetscape NavigatorＴＭとして実現し、これを本発明の特徴および機能を組み込むように修正することが考えられる。後に詳細に説明するように、ウエブブラウザ１００は、単に、ユーザが所望の日時を指定できるように、新たなオプション選択パネルを組み込むことのみを必要とされる。実際、従来のウエブブラウザ１００を利用し、ユーザが、手操作にて、タイムスタンプをURLに、ブラウザ１００の“Location”ウインドウに従って付加するようにすることもできる。
【００１７】
一つの実現においては、ユーザは、タイムスタンプをターンオンあるいはオフするオプションを有する。タイムスタンプが起動されている場合は、ブラウザ１００は、ＵＲＬに必要な変更を加えたうえで、ＵＲＬをウエブ１３０に送る。対応するウエブサーバ１４０、１５０がタイムスタンプを認識できるという保証はなく、このため、サーバ１４０、１５０によって送り返されるドキュメントに含まれる埋め込まれたハイパーリンクがタイムスタンプを含まないことも考えられる。このため、このような状況においては、ウエブブラウザ１００が、タイムスタンプオプションが起動されている場合は、ユーザがそのハイパーリンクをクリックした際に、埋め込まれているハイパーリンクと関連するＵＲＬを自動的に変換し、適当なタイムスタンプを付加するようにすることが考えられる。このため、ウエブブラウザ１００は、ＵＲＬを選択されたタイムスタンプフォーマットに従って変換できる必要がある。リクエスト・ヘッダスキームを用いる実現では、ブラウザ１００を、専用のリクエストヘッダ（例えば、“Time-Stamp:June9,1998”）を送信できるように修正する必要がある。加えて、ＨＴＭＬを、特定のタイムスタンプを持つ任意の埋め込まれたハイパーリンクに対して、新たなタイムスタンプタグを含むように修正する必要がある。例えば：
＜A HREF=“www.lucent.com">Lucent Web Site</A>
なる形式を持つハイパーリンに対しては、ＨＴＭＬを、１９９８年２月２日なるタイムスタンプを示すように、以下のように修正する必要がある：
＜A HREF=“www.lucent.com"><TIMESTAMP TIME="2+2+1998”
TIMEZONE=server><TIMESTAMP>Lucent Web Site</A>
【００１８】
パシステント（持続的）ウエブサーバ
パシステント（持続的）ウエブサーバ１４０、１５０は、従来のハードウエアおよびソフトウエアとして実現し、以下に説明する機能および動作を遂行するように修正することが考えられる。より具体的には、パシステントウエブサーバ１４０、１５０は、（１）タイムスタンプを含むURLを受信すること、（２）タイムスタンプを抽出すること、（３）アーカイブから正確なページを検索すること、（４）ベースウエブページを修正することで、埋め込まれたハイパーリンクをリクエストされたウエブページと同一のタイムスタンプを含むように更新すること、および（５）要求されたページをクライアントに送り返すことができる必要がある。さらに、パシステントウエブサーバ１４０、１５０は、抽出されたURLを、選択されたタイムスタンプフォーマットに従って分析できる必要がある。本発明の一つの実施例においては、リクエストされた時間に対応するウエブ資源のバージョンが存在しない場合は、そのウエブ資源が以前にアーカイブ（保存）されたバージョンから変更されてないものと想定され、リクエストされた時間より前の最も最近の時間を持つウエブ資源のバージョンが送り返される。
【００１９】
加えて、パシステントウエブサーバ１４０、１５０は、それらが扱ったウエブの過去の全ての情報を保存できる必要がある。このため、図１に示すように、各パシステントウエブサーバ、例えば、パシステントウエブサーバ１４０、１５０は、それぞれ、ウエブ資源の全てのバージョンを、それらがウエブユーザによって持続的に利用できるように、格納するためのパシステント（持続的）アーカイブ１４５、１５５を備える。これらパシステントアーカイブ１４５、１５５は、どのようなメモリデバイスを用いて実現することもできるが、ただし、好ましくは、ＣＤ−ＲＯＭ、ＣＲ−Ｒ、ＷＯＲＭ、ＤＶＤ−ＲＯＭなどの持続的な（消去不能な）メモリデバイスが用いられる。
【００２０】
パシステントウエブサーバ１４０、１５０にて日付を持つＵＲＬをサポートするためには、パシステントウエブサーバ１４０、１５０は、それらの全内容（コンテント）を、それらがいつでも取り出せるように、年代順に格納する必要がある。図２に示す一つの実現においては、パシステントアーカイブ１４５、１５５は、ウエブサイトの全内容を、永久メモリデバイスに、ある種の年代順ダイレクトリ構造に従って格納する。図２は、ウエブサイトの内容を年代順に配列するダイレクトリ構造２００を示す。このダイレクトリ構造２００内のおのおのの葉、例えば、葉２１０は、ある日付（ここでは、１９９８年６月２６日）を持つＵＲＬに対応する。例えば：
http://www.nytimes.com?time=24+2+1998
なる日付を持つURLは、概念的に：
http://www.nytimes.com/archive/1998/2/24/
と等しい。
【００２１】
勿論、ウエブサイトの全内容を格納することは、メモリの利用の観点からは効率が悪い。多くのウエブページは、あったとしても、毎日、少ししか変更されない。このため、単にアーカイブから冗長を除去することで、メモリ効率を大幅に向上させることができる。いったん冗長が除去されれば、正規のウエブサイトメモリに追加されるべきメモリ要件は、通常は、それほどは大きくはならない。
【００２２】
図３は、パシステントアーカイブ１４５、１５５の冗長を低減するためのアーカイブプロセス３００を示す。このアルゴリズムにおいて言及される全てのファイルあるいはサブダイレクトリは、図２の一例としてのダイレクトリ構造２００のアーカイブサブダイレクトリ２２０の下に来ることに注意する。図３に示すように、アーカイブプロセス３００は、最初に、ステップ３１０において、各サブダイレクトリ、例えば、サブダイレクトリＡに対して、それより以前に作成され、サブダイレクトリＡと同一の内容を持つサブダイレクトリＢが存在するか否かを決定するためのテストを遂行する。ステップ３１０において、それより以前に作成され、サブダイレクトリＡと同一の内容を持つサブダイレクトリＢは存在しないことが決定された場合は、サブダイレクトリレベルでは、パシステントアーカイブ１４５、１５５の冗長を低減することはできず、プログラム制御は、ステップ３３０に進む。
【００２３】
他方、ステップ３１０において、それより以前に作成され、サブダイレクトリＡと同一の内容を持つサブダイレクトリＢが存在することが決定された場合は、ステップ３２０において、サブダイレクトリＡが、サブダイレクトリＢをポイントする別名（代替入口点／代替名）となる。例えば、図４Ａに示すように、ウエブサイトの現在（今日）の内容が昨日の内容と同一である場合は、今日に対して昨日のサブダイレクトリをポイントする別名が生成され、同様に、図４Ｂに示すように、今月の内容が先月の内容と同一である場合は、今月に対して先月のサブダイレクトリをポイントする別名が生成される。
【００２４】
その後、ステップ３３０において、各ファイル、例えば、ファイルＡに対して、それより以前に作成され、ファイルＡと同一の内容を持つファイルＢが存在するか否か決定するためのテストが遂行される。ステップ３３０において、それより以前に作成され、ファイルＡと同一の内容を持つファイルＢは存在しないことが決定された場合は、ファイルのレベルでパシステントアーカイブ１４５、１５５の冗長を低減することはできない。このため、プログラム制御は、ステップ３５０において終結する。
【００２５】
他方、ステップ３３０において、それより以前に作成され、ファイルＡと同一の内容を持つファイルＢが存在することが決定された場合は、ステップ３４０において、ファイルＡがファイルＢをポイントする別名となる。その後、プログラム制御は、ステップ３５０において終結する。
【００２６】
アーカイブプロセス３００は、これが多数の（一致する）ファイルあるいはダイレクトリを探索する必要があるために、現実的でなくなることも考えられる。つまり、このプロセスの実行時間は、アーカイブ内のエンティティの数と共に指数関数的に増大することとなる。当業者においては明白なように、これに対する多くの次善の解決策が可能である。一つの極めて単純な解決策においては、単に、今日アーカイブしたいものが、最も最近に追加されたアーカイブ（例えば、昨日の内容）に対してチェックされる（と比較される）。殆どのウエブサイトは、以前にアーカイブされたものと僅かしか違わないために、このアプローチはかなり妥当なものとなる。このアプローチは、周知のファイルシステムの増分バックアップと類似する。
【００２７】
ウエブサーバがパシステント（持続的）ウエブサーバでない場合でも、その影響を最小限に押さえることが要求される。このために、一つの実現においては、リクエストがタイムスタンプを含むが、あるウエブサーバがそのタイムスタンプを認識できない場合、そのウエブサーバは、リクエストされたウエブ資源の最も最近のバージョンを送り返すようにされる。
【００２８】
パシステントアーカイブのメモリ要件を低減するためのもう一つの方法として、ウエブサーバを、正しいアーカイブされたデータを探索できるという観点で、よりスマートなものにすることが考えられる。例えば、あるウエブ資源のパシステントな（持続的な）記録は、そのウエブ資源の前に保存されているバージョンと幾らか異なるバージョンのみに制限することが考えられる。例えば、あるアーカイブがウエブ資源の次のような５つの異なるバージョン、つまり、6/4/1996、6/12/1996、3/23/1997、2/1/1998、2/3/1998を含み、リクエストされた日付がこれらアーカイブされているどのバージョンとも等しくない場合、ウエブサーバは、そのリクエストされた日付は、それより前の最も最近の日付を持つバージョンと同一であるものと想定することが考えられる。加えて、あるダイレクトリ内に専用のシンボルリンク（あるいは、MacOS上の別名、あるいは、MS Windows（登録商標）上のショートカット）を用いることで、現在のダイレクトリの下に見つけることができないファイルあるいはダイレクトリを探索すべき場所を表し、こうして、該当するダイレクトリの下には、変更された部分のみを格納することも考えられる。変更されてない全てのデータは、このような専用のリンクの連鎖を通じて参照することができる。
【００２９】
パシステント（持続的）ＤＮＳサーバ
パシステント（持続的）ドメイン名サーバ（domain name server、DNS）は、従来のハードウエアおよびソフトウエアとして実現し、以下に説明する機能および動作を遂行するように修正することが考えられる。従来のＤＮＳサーバは、任意のドメイン名参照を、それらがＤＮＳデータベース内に存在しない場合、拒否する。本発明による日付を持つＵＲＬの一つの長所は、これを（ＵＲＬを）、過去のウエブ資源を参照（にアクセス）するためにも用いることができることである。例えば、従来の方法では、会社Ａが会社Ｂに併合された場合、“www.A.com"を通じて参照（アクセス）される全てのウエブページはもはや無効となる。つまり、ユーザが会社Ａに関するドキュメントにアクセスすることを希望する場合、ユーザは、全ての参照を会社Ｂのウエブサイトのどこかに変更することが必要となる。
【００３０】
ただし、会社Ａの過去の情報は、ＤＮＳサーバが、会社Ａの名前での参照（アクセス）を拒否することなく、代わりに、会社Ａの過去の情報がどこに存在するかを知っているアーカイブサービス会社に相談（照会）するようにすれば、アクセスすることが可能となる。ＤＮＳサーバ自身も、名前をＩＰアドレスに解決（翻訳）するプロセスをより迅速にするための幾らかの過去のデータを格納する。図５Ａ〜図５Ｂは、ＤＮＳサーバデータベースに格納されるデータの一例を、それぞれ、会社ＡとＢが併合する前と後について示す。この方法では、図５Ｂに示すように、ユーザが併合の後に、www.A.comについて知りたいと希望した場合でも、ＤＮＳサーバは、ユーザのリクエストを会社Ｂと関連する新たなIPアドレスに再ダイレクトするための十分な情報を持つ。データベース内にリストされている日付は、対応するドメイン名が有効である期間を表す。図面の例では、“www.A.com. 2/2/1999"なる日付を持つドメイン名参照は無効であり、“www.A.com. 2/2/1992"なる日付の場合は有効であることが示される。
【００３１】
図６は、本発明によるＤＮＳサーバプロセス６００を示す。図６に示すように、ＤＮＳサーバプロセス６００は、最初に、ステップ６１０において、ドメイン名リクエストを受信する。次に、ステップ６２０において、ドメイン名リクエストが日付を持つか否かを決定するためのテストが遂行される。ステップ６２０において、ドメイン名リクエストが日付を持たないことが決定された場合は、ステップ６３０において、通常の名前探索結果が送り返される。
【００３２】
反対に、ステップ６２０において、ドメイン名リクエストが日付を持つことが決定された場合は、ＤＮＳサーバプロセス６００は、ステップ６４０において、ＤＮＳデータベースを、そのドメイン名を求めて、その日付の制約内で探索する。次に、ステップ６５０において、その日付を持つドメイン名が見つかったか否か決定するためのテストが遂行される。ステップ６５０において、目的の日付を持つドメイン名が見つからなかったことが決定された場合は、ＤＮＳサーバは、ステップ６６０において、さらなる探索のために、アーカイブサービス会社に相談し、その後、プログラム制御は、ステップ６７０に進む。
【００３３】
一方、ステップ６５０において、目的の日付を持つドメイン名が見つかったことが決定された場合は、ステップ６７０において、探索結果が送り返される。このとき、再リダイレクトの場合は、その指標も送り返される。その後、プログラム制御は終結する。
【００３４】
ドメイン名がＤＮＳサーバによって解決（翻訳）された後、ウエブブラウザ１００は、ＤＮＳサーバから送り返されたものに従ってリクエストをウエブサーバ１４０、１５０に送信する必要がある。例えば、ユーザからのリクエストが、“http://www.A.com?time=2+2+1992"なる形式のＵＲＬである場合、ブラウザ１００は、ＤＮＳサーバにドメイン名解決リクエストを“www.A.com 2/2/1992"なる形式で送信する。説明の例では、会社Ａは、現在は会社Ｂの一部であるために、（図５Ｂに示すように）結果として、“123.2.3.222redirect"が送り返される。こうして、ウエブブラウザ１００は、現在、サーバのIPアドレスを入手しており、それが、再ダイレクトアドレスであることも知っている。こうして、ウエブブラウザ１００は、結果として、会社Ｂのウエブサーバ１４０、１５０にリクエストを“http://123.2.3.222?http://www.A.com?time=2+2+1992"なる形式にて送信する。会社Ｂのウエブサーバ１４０、１５０は、正しい（該当する）情報を得るために、どのようにすれば、会社Ａのこの古いアドレスを適当な位置にマッピングすることができるか知っている。
【００３５】
この新たなDNSの一つの副次的な長所は、幾つかの名前は、それらが一旦過去のものとなったら、再使用できることである。例えば、会社Ａという名前を持つもう一つの会社が、所定の期間の後に、ＤＮＳデータベースを以下のエントリにて更新することで、www.A.comなるドメイン名を用いることが可能となる：
【表１】
2005251190.tif 000003
【００３６】
このようにして、ドメイン名を、無駄にすることなく、再利用することが可能となる。
【００３７】
ダイナミックなウエブ内容へのパシステントなアクセス
こうして、ウエブは、ダイナミックな（動的に変化する）内容（コンテント）で一杯となる。これら内容（コンテント）には、WebCamなどからのリアルタイムビデオや、WebCastイベントなどからのオーディオストリームや、Java（登録商標）、Javascript、あるいはActive-X起動のウエブページなどが考えられる。アプリケーションによっては、一連のダイナミックな内容を保存することは必要とされない、若しくは、要求されず、加えて、ウエブページの全ての広告部分は、保存することは必要とされない、若しくは、要求されない。
【００３８】
例えば、銀行や証券会社の取引データなどの年代順のデータでは、記録の一部分のみを、与えられたタイムスタンプの制約内で抽出することができる。例えば、ある日付における残高をチェックするためには、ブラウザ１００は、リクエストを以下のような形式にて送信する：
http://bank.com/?id=1234&time=2+3+1998
サーバ１４０、１５０は、単に、データを１９９８年３月２日まで検索あるいは再計算し、結果を送り返すことのみを必要とされる。このようなアプリケーション環境においては、全ての取引はもともとタイムスタンプを持つために、サービスにこの機能を追加することは極めて簡単である。
【００３９】
リアルタイムな内容（コンテント）に対しては、タイムスタンプを付加することの唯一の制約は、メモリ要件である。保存すべき情報の量に対して多くのメモリ空間が利用できる場合は、ウエブサイトの管理者は、全てのリアルタイム内容を保存することを選択し、メモリ空間が十分でない場合は、それらの幾らかを、例えば、１日分、１週間分、あるいは１年分のデータを保存することを選択することが考えられる。
【００４０】
ダイナミックに生成される宣伝に対しては、ウエブサイトの管理者は、（特別な理由により）古い広告を‘再提示（reshow）’することが適当であるか、あるいは、‘実際の（real）’アーカイブされているウエブ内容とは特に関係ない古い広告を新たな最新のコマーシャルと置換すべきか否かを決定することを要求される。
【００４１】
ウエブページ上でダイナミックに実行されるスクリプトについては、２つの可能な状況が考えられる。そのスクリプトが時間とともに変化しない場合は、そのスクリプトは安全に保存することができるが、そのスクリプトの挙動が時間とともに変化する場合、例えば、クロックやカレンダーディスプレイである場合は、そのスクリプトは、日付を持つＵＲＬを扱うように修正することを必要とされ、Java（登録商標）、JavascriptあるいはActive-X標準に適当な修正を施すことが必要となる。ＣＧＩアプリケーションによって動的に生成されるウエブページについても同様である。
【００４２】
以上、本発明について説明したが、説明の実施例およびバリエーションは単に本発明の原理を解説するためのものであり、当業者においては理解できるように、本発明の範囲および精神から逸脱することなく様々な修正が可能である。
【図面の簡単な説明】
【００４３】
【図１】本発明によるインターネット／World Wide Web（“ウエブ（Wed）”）環境を示す図である。
【図２】ウエブサイトの内容（コンテント）を年代順に配列するダイレクトリ構造を示す図である。
【図３】図１のパシステントアーカイブの冗長を低減するためにウエブサイト（サーバ）によって実現される一例としてのアーカイブプロセスの流れ図である。
【図４Ａ】図３のアーカイブプロセスによって遂行される以前にアーカイブされた内容と同一のウエブサイトの内容に別名を付ける様子を示す図である。
【図４Ｂ】図３のアーカイブプロセスによって遂行される以前にアーカイブされた内容と同一のウエブサイトの内容に別名を付ける様子を示す図である。
【図５Ａ】本発明によるＤＮＳサーバのデータベースのサンプルテーブルを示す図である。
【図５Ｂ】本発明によるＤＮＳサーバのデータベースのサンプルテーブルを示す図である。
【図６】タイムスタンプを持つＵＲＬに対応するＩＰアドレスを決定するためにＤＮＳサーバによって遂行される一例としてのＤＮＳサーバプロセスの流れ図である。
【符号の説明】
【００４４】
１００  ウエブブラウザ
１３０  インターネット／World Wide Web（“ウエブ（Web）”）環境
１４０、１５０  パシステントウエブサーバ
１４５、１５５  パシステントアーカイブ
２００  年代順ダイレクトリ構造
【図１】
2005251190.tif 000004
【図２】
2005251190.tif 000005
【図３】
2005251190.tif 000006
【図４Ａ】
2005251190.tif 000007
【図４Ｂ】
2005251190.tif 000008
【図５Ａ】
2005251190.tif 000009
【図５Ｂ】
2005251190.tif 000010
【図６】
2005251190.tif 000011