JP3934174B2

JP3934174B2 - 中継サーバ

Info

Publication number: JP3934174B2
Application number: JP10965396A
Authority: JP
Inventors: 典生田川
Original assignee: Brother Industries Ltd; Xing Inc
Current assignee: Brother Industries Ltd; Xing Inc
Priority date: 1996-04-30
Filing date: 1996-04-30
Publication date: 2007-06-20
Anticipated expiration: 2016-04-30
Also published as: US5991773A; JPH09297703A

Description

【０００１】
【発明の属する技術分野】
本発明は、データベース技術に関連し、特に、複数の情報提供手段がネットワークで接続されて分散型データベースを構成するシステムに対し、その情報提供手段内のデータを検索あるいは取得するための情報端末装置に関する。
【０００２】
【従来の技術】
従来、インターネットを用いた複数の情報提供手段（サーバ）による分散型データベースサービスのシステムが考えられている。インターネットにおけるＷＷＷ（World Wide Web）と呼ばれるデータベースの仕組みでは、分散した多くのサーバにデータが個別に用意されており、情報端末装置側となるユーザは、データが必要になる度に各サーバにデータを取りに行くこととなる。
【０００３】
このＷＷＷにおいては、ハイパーリンクと呼ばれる仕組みでばらばらのサーバをつなぎあわせ、分散型データベースを実現している。ハイパーリンクとは、あるデータベースのデータの一部として、他のデータを指すＵＲＬ（Uniform Resource Locator）と呼ばれるインデックスを用意し、ユーザ側でこのインデックスをたどって他のサーバに半ば自動的にデータを取りに行く仕組みである。
【０００４】
このＵＲＬは、基本的には名前による参照であり、ＵＲＬ自体にはハイパーリンクによって指定されるデータの実質的な内容に関する情報は何もない。従って、ハイパーリンクがあっても、その先の実体が必ずしも存在することを保証しているわけではない。
【０００５】
また、インターネット上の分散システムの特徴として、各サーバの管理は別々の管理主体が行っているため、一貫した管理がなされていない。つまり、一般的に、リンクを張る側の管理主体とデータを用意する側の管理主体は異なる。このような形態のデータベースサービスでは、あるハイパーリンクが用意されていても、必ずしも対応する特定のデータが常にあるわけではない。
【０００６】
そのため、データサービスを行うための各サーバは一貫した管理がなされておらず、そのためデータベースサービスの利用者は、利用時点においてサービスされているデータのみしか検索あるいは取得できなかった。つまり、過去に検索・取得が可能であったデータが、ある時点で変更される場合もある。その場合、利用者は、過去のデータを検索・取得したいと思っても過去のデータにアクセスすることはできず、現時点のデータしかアクセスできないこととなる。
【０００７】
【発明が解決しようとする課題】
このように過去のデータをアクセスする必要にせまられた時点で、データを取り出すことができないので、利用者は、必要になりそうなデータをそのデータにアクセスが可能なうちに自分のローカルなディスクにセーブしておくといったことが考えられる。
【０００８】
しかしながら、全ての利用者が全てのデータを保存しておくことは現実的には因難であり、また、そのデータ保存のためには大量の記憶容量を必要とする。さらには、数多くのデータを保存した場合、利用者にとってどれが必要なデータであるかを管理するために多大な労力を必要とする。
【０００９】
本発明は、上述した問題点を解決するためになされたものであり、ネットワーク上の情報提供手段から得た情報を、記憶手段に記憶しておき、利用者からの指定に従って、過去のデータを検索・取得可能とすることを目的としている。
【００１０】
【課題を解決するための手段及び発明の効果】
この目的を達成するためになされた本発明の中継サーバは、図１に例示するように、複数の情報提供手段がネットワークで接続されて分散型データベースを構成するシステムに対し、前記情報提供手段内のデータを検索あるいは取得するための情報端末装置において、ネットワーク介して情報提供手段から得られた情報を記憶し、この記憶している情報を端末装置へ送信する中継サーバであって、ネットワークを介して通信するための通信手段と、該通信手段を介して情報提供手段から得られた情報を、時間の推移に従った管理を行うための履歴管理手段と、履歴管理手段から受け取った情報を記憶しておく記憶手段とを備える。
このうち、履歴管理手段は、受信手段と、存在判断手段と、第１記憶手段と、更新判断手段と、第２記録手段と、送信手段とを備える。
受信手段は、通信手段を介して端末装置からＵＲＬ（ uniform resource locator ）を受信する。
存在判断手段は、受信手段によって受信されたＵＲＬに、情報のバージョンを指定するためのバージョン指定情報が付加されていない場合、このＵＲＬに対応する情報が記憶手段に存在するか否かを判断する。
第１記録手段は、存在判断手段によって記憶手段に情報が存在しないと判断された場合、当該ＵＲＬに対応する情報を通信手段を介して情報提供手段から取得し、この取得した情報をこの情報のバージョンを示す情報と共に記憶手段に記録する。
更新判断手段は、存在判断手段によって記憶手段に情報が存在すると判断された場合、当該情報が更新されているか否かを判断する。
第２記録手段は、更新判断手段によって、情報が更新されていると判断した場合、当該ＵＲＬに対応する情報を通信手段を介して情報提供手段から新たに取得し、この取得した情報をこの情報のバージョンを示す情報と共に記憶手段に記録する。
送信手段は手段は、受信手段によって受信されたＵＲＬに、情報のバージョンを指定するためのバージョン指定情報が付加されている場合、このバージョン指定情報で指定されたバージョンに対応する情報を記憶手段から読み出し、これを通信手段を介して端末装置へ送信する。
【００１１】
本中継サーバによれば、分散型データベースを構成する複数の情報提供手段に対し、通信手段によりネットワークを介してアクセスすることができ、情報提供手段内のデータを検索あるいは取得することができる。ここで、履歴管理手段は、通信手段を介して情報提供手段から得られた情報を、時間の推移に従った管理を行うことができる。
【００１２】
そして、端末装置によって、履歴管理手段に対してバージョン指定情報を指定することで、利用者は、容易に過去の情報を見ることができる。
次に、請求項２に記載の中継サーバは、以下のような特徴を有する。履歴管理手段が備える送信手段は、受信手段によって受信されたＵＲＬに追加されているバージョン指定情報に、直近のバージョンを示すフラグ情報が付加されている場合、当該バージョン指定情報で指定されたバージョンに対応する情報が記憶手段に存在すれば、この情報を記憶手段から読み出してこれを端末装置へ送信する。一方、当該バージョン指定情報で指定されたバージョンに対応する情報が記憶手段に存在しなければ、記憶手段に記憶された情報の中から指定されたバージョンに最も近いバージョンに対応する情報を読み出してこれを端末装置へ送信する
【００１３】
次に、請求項３に記載の中継サーバは、以下のような特徴を有する。履歴管理手段が備える送信手段は、受信手段によって受信されたＵＲＬに追加されているバージョン指定情報に、或るバージョンに対する相対的なバージョンを指定するための符号及び値を含む相対指定情報が付加されている場合、この相対指定情報で指定されたバージョンに対応する情報を記憶手段から読み出し、これを通信手段を介して端末装置へ送信する。
【００１４】
【発明の実施の形態】
以下、本発明の実施の形態について図面を参照して説明する。本実施形態の履歴管理機能付き情報端末装置は、図２に示されるネットワーク・システムにおいて実施される。このネットワークは、ローカルなネットワーク（ＬＡＮ）１１を、インターネットに代表される広域ネットワーク（ＷＡＮ）１４に接続することにより構成されている。
【００１５】
前記ＬＡＮ１１上には、ユーザが利用する複数の端末１３に加えて、中継サーバ１２が用意されている。本実施形態では任意の一つの端末１３と中継サーバ１２とで「履歴管理機能付き情報端末装置」が構成されることとなる。また、ＷＡＮ１４上には、情報提供手段に相当するサーバＡ（１５）、サーバＢ（１６）、サーバＣ（１７）の３つのサーバをはじめとして、分散型データベースを構成している数多くのＷＷＷサーバがある。
【００１６】
ここでネットワークのハードウェアについて説明しておく。ＬＡＮ１１側は、イーサネットに代表される高速なネットワークを用い、ＷＡＮ１４側は、電話回線を用いた遠距離の、つまり比較的低速の通信回線によるネットワークを用いることが一般的である。
【００１７】
また、中継サーバ１２及び各端末１３としては、多種多様な機器が用いられるが、本実施形態においては、図３に示す周知のコンピュータが用いられているとする。簡単に説明すれば、中継サーバ１２は図３（ａ）に示すように、通信手段としてのネットワークインターフェース２１と、制御手段としてのＣＰＵ２２と、記憶手段としてのメモリ２３と記憶手段としてのディスク２４とを備えている。一方、端末１３は図３（ｂ）に示すように、通信手段としてのネットワークインターフェース３１と、制御手段としてのＣＰＵ３２と、記憶手段としてのメモリ３３と、表示手段としての表示装置３５と、入力手段としてのキーボード３６及びマウス３７とを備えている。
【００１８】
まず、本実施形態の前提として、このネットワークにおけるＷＷＷシステムの動作のあらましを、以下に説明する。このネットワークでは、通信プロトコルとしてＴＣＰ／ＩＰ（Transmission control protocol／internet protocol）を用いる。このＴＣＰ／ＩＰでは、ネットワーク上の任意の装置間で通信を行うことができる。従って、端末１３は、インターネット上のサーバＡ（１５）、サーバＢ（１６）、サーバＣ（１７）と直接通信を行うことができる。
【００１９】
また、ＷＷＷシステムにおいては、データの通信は主にｈｔｔｐプロトコルにより行われる。実際には他のプロトコルも用いられるが、本実施形態ではｈｔｔｐプロトコルのみを用いるものとする。このプロトコルは、上記のＴＣＰ／ＩＰプロトコルの上位プロトコルとして動作する。このプロトコルは比較的単純なプロトコルで、クライアント（端末）からのコマンドに対しサーバが返すことをするという形式で一回に一つのデータを転送する。
【００２０】
たとえば、端末１３がサーバＡ（１５）に対して、「ＧＥＴ／ｉｎｄｅｘ．ｈｔｍｌ」というコマンドを送る。このコマンドは、サーバＡ（１５）中の「ｉｎｄｅｘ．ｈｔｍｌ」というファイルを端末１３側に転送させるためのコマンドである。サーバＡ（１５）は、このコマンドを受け取ると対応するファイル（ｉｎｄｅｘ．ｈｔｍｌ）を端末１３に送信する。
【００２１】
この、ｈｔｔｐプロトコルにより、データの転送方法が定められるが、データの内容は、ｈｔｍｌ（hyper text markup language）によって記述される。このｈｔｍｌによって、どのようにページが記述されるかを図４に示す。ｈｔｍｌでは、内容となる文章とコマンドを、一つのファイル中に、テキストの形で記述する。図４において、「＜」と、「＞」でくくられた部分がコマンドである。
【００２２】
図４に示すｈｔｍｌが端末１３の表示装置３５（図３（ｂ）参照）にて表示されると図５に示すようになる。図５は全て表示装置３５の画面上の表示である。まず、マウス３７（図３（ｂ）参照）によりクリックすることで次の動作を指示するためのボタンとして、ｏｐｅｎボタン５１、ｇｏボタン５２、ｖｉｅｗボタン５３、ｅｘｉｔボタン５４及びヒストリ・ボタン５５，５６がある。このヒストリ・ボタン５５，５６は、過去のデータを取り出す際のヒストリをたどるため用いられる。図５中で左側にあるボタン５５をクリックすると一つ前のバージョンを表示させることができ、右側のボタン５６をクリックすると一つ後の新しいバージョンを表示させることができる。
【００２３】
一方、図５中の右側には表示を上下にスクロールさせるためのスクロール・バー５７があり、中央部には実際のデータが表示されるメイン・ウィンドウ５８が位置している。ここで、図４中において「＜Ｈ１＞」と「＜／Ｈ１＞」でくくられた部分（「サンプル」）はヘッダを表しているので、表示される文字のサイズが大きくなっている。また、＜ＩＭＧＳＲＣ＝"ｓｔａｒ．ｇｉｆ"＞の部分は図５中のメイン・ウィンドウ５８中の星形図形５９に対応する。この部分はｓｔａｒ．ｇｉｆという名前のイメージファイルを表示することを指示しているので、上記ｈｔｔｐプロトコルを用いて図形の実体が入っているファイルを別途転送し、ウィンドウに張り付ける。
【００２４】
そして、「＜ＡＨＲＥＦ＝"ｈｔｔｐ：／／ｗｗｗ．ａｂｃ．ｎｅｔ／ｉｎｄｅｘ．ｈｔｍｌ"＞ハイパーリンク＜／Ａ＞」の部分が、ＷＷＷシステムにおいて特徴的なハイパーリンクを記述している部分である。＜Ａ……＞と＜／Ａ＞間のテキストが表示されている部分をマウス３７によりクリックすると、「ＨＲＥＦ＝……」で指定されたデータを読み込むことができる。これによって、利用者から見た場合、あるサーバから他のサーバにあたかも移動したかのように感じられる操作性をもたらしている。
【００２５】
この「ＨＲＥＦ＝……」で指定されるリンクはＵＲＬと呼ばれる形式で記述される。ＵＲＬは、図６に示すように、プロトコル名６１、ホスト名６２、パス名（ファイル名）６３により構成されている。プロトコル名はｈｔｔｐであり、ホスト名はＴＣＰ／ＩＰネットワークにおいてサーバを特定するための名前であり、パス名はそのサーバにおけるファイルを特定するための名前である。
【００２６】
このように、ＷＷＷシステムでは、基本的に、サーバ側は端末１３側から指定されたデータを送るのみであり、画面の表示やリンクの処理などはほとんど端末１３側で行われる。この端末１３側から見た処理の概要を図７のフローチャートに示す。
【００２７】
なお、この図７の処理は、ヒストリ・ボタン５５，５６（図５参照）を備えない従来のものにおいても実行されていた内容であり、後述する図１５のフローチャートの処理が、本案の特徴でもあるこのヒストリ・ボタン５５，５６を使用する場合の内容である。但し、従来の場合と本案との比較のためにも、ここでは、図７を用いて従来も実現されていた一般的な基本処理を説明することとする。
【００２８】
端末１３側では、最初のＵＲＬは、ユーザによりキーボード３６から入力される（ステップ７１。以下、ステップをＳと記す）。次に、このＵＲＬにより指定されるデータをサーバ１５からｈｔｔｐプロトコルにより読み込む（Ｓ７２）。読み込んだデータを解析し（Ｓ７３）、ウィンドウ上に表示する（Ｓ７４）。この時、イメージデータなどの別途転送が必要なデータがある場合は、そのデータを転送し、ウィンドウ上に表示する。この処理をｈｔｍｌ中の全てのデータについて行う（Ｓ７５）。
【００２９】
１ページ分の全てのデータが転送されると、マウス３７の入力待ちになる（Ｓ７６）。マウス３７がクリックされると、その位置を取り出し（Ｓ７７）、その位置がハイパーリンクであれば（Ｓ７８：ＹＥＳ）、その部分に対応するＵＲＬを取り出し（Ｓ７９）、その後Ｓ７２へ戻って、サーバ１５にデータを取りに行く処理から繰り返す。
【００３０】
一方、マウス３７のクリック位置がハイパーリンク上でなかった場合は（Ｓ７８：ＮＯ）、その位置に応じた処理を行い（Ｓ８０）、その後Ｓ７６へ戻る。このように、端末１３とサーバ１５間の通信によりＷＷＷシステムが機能するわけであるが、端末１３とサーバ１５が直接通信するのではなく、それらの間に中継サーバ１２を介して通信を行うことも一般的である。
【００３１】
中継サーバ１２を用いる目的は、主として、データをキャッシュし、見かけ上の転送速度を高めることである。つまり、一般的にＬＡＮ１１はＷＡＮ１４に比べて高速であるので、一度読み込んだデータをＬＡＮ１１上の中継サーバ１２にキャッシュし、次回のアクセスがあった場合は、ＷＡＮ１４上のサーバ１５から転送するのではなく、中継サーバ１２から転送することで、体感的なアクセス速度を高めることができる。
【００３２】
さて、本実施形態における特徴は、中継サーバ１２にデータのヒストリ管理機構を導入して、過去のデータを効率良く検索することである。ここで、本実施形態における中継サーバ１２について、図８に示す機能ブロック図を参照して説明する。
【００３３】
後述するバージョン付きＵＲＬを処理するＵＲＬ処理機能８３と、キャッシュデータを管理するキャッシュ管理機能８４と、実際にデータを保存するためのファイルシステム機能８５と、ネットワークと接続するためのインターフェース機能８１，８２と、時間を管理するためのタイマ機能８６を備える。ＬＡＮ側のネットワークインターフェース機能８２は端末１３に対してサーバとしての動作を行い、ＷＡＮ側のネットワークインターフェース機能８１はＷＡＮ１４上のサーバ１５，１６，１７に対するクライアントとして動作する。
【００３４】
なお、この図８は中継サーバ１２の機能を抽象的に示したものであり、図３（ａ）に示した構成要素によってこれらの機能が実現されることとなる。したがって、例えば図８におけるＷＡＮ側のネットワークインターフェース機能８１及びＬＡＮ側のネットワークインターフェース機能８２は、実際には図３（ａ）に示す１つのネットワークインターフェース２１がその機能を持つこととなる。
【００３５】
一方、端末１３もヒストリ機能に対応するための機能を備えている。本実施形態における端末１３について図９に示す機能ブロック図を参照して説明する。従来のクライアント機能を発揮するためにも必要であったネットワークインターフェース機能９１と、ｈｔｍｌ処理機能９６と、表示機能９９と、リンク情報選択機能９７と、ＵＲＬ生成機能９２と、キー入力機能９３と、マウス入力機能９８とに加えて、本発明の特徴的な構成に関連するヒストリ機能として、バージョン付ＵＲＬ及びヒストリ付データを処理するためのファイル管理機能９４とバージョン管理機能９５とを備えている。なお、図５の画面に示したヒストリ・ボタン５５，５６も当然、本発明の特徴的な構成に関連するヒストリ機能を実現するためのものである。
【００３６】
さて、本実施形態においては、ヒストリ機能の実現のために、通常のＵＲＬ及びデータに若干の拡張を行ったデータを採用している。そのデータの構成を以下で説明する。バージョン付きＵＲＬは、通常のＵＲＬにバージョンを指定するためのデータを付加したものである。これは、図１０に示すように、バージョン付きであることを示すフラグ１０１と、バージョンを表す数値１０３と、近いバージョンを指定するフラグ１０４と、相対的なバージョンを指定するための符号及び数値１０５とを、従来までの通常のＵＲＬ１０６に追加することで構成される。
【００３７】
本実施形態ではバージョンを表す数値として日付を用いた。実用的には、より細かく秒単位でのバージョン管理が必要であるが、ここでは、表記を簡単にするため日付のみを用いることとする。また、近いバージョンを指定するフラグ１０４とは、指定されたバージョンに一致するバージョンがない場合、それにもっとも近いバージョンでかまわないことを示すためのものである。今後、このフラグを「Ａフラグ」と略称する。
【００３８】
さらに、バージョンの相対指定のために、或るバージョンのいくつ前あるいはいくつ後といった指定を、「＋」及び「−」の符号と数値とを用いることにより指定できる。図１０に示す例では、矢印（１）で示したＵＲＬ（図１０中で上側）が１９９５年９月２０日のバージョンであり、矢印（２）で示すＵＲＬ（図１０中で下側）が１９９５年９月２０日にもっとも近いバージョンから一つ新しいバージョンを示している。
【００３９】
次に、中継サーバ１２にキャッシュされるデータの構造を以下に説明する。キャッシュされるデータは、図１１（ａ）に示すように、ＵＲＬに対して一意のファイル名を持つファイルとして保存される。ファイル名は、プロトコル、ホスト名、パス名（一番最後の部分は除く）をファイルシステム中のディレクトリ１１１に対応させる。
【００４０】
そして、パス名の一番最後の名前をファイル名とする。これだけでは、同一ファイルのバージョンによる区別ができないので、ファイル名の後にバージョン番号を付加する。また、最新のファイルがどれかを示すためのインデックス・ファイル１１２も用意する。このインデックス・ファイル１１２は、ファイル名の後のバージョン番号として「０００」を付加したファイル名を用いる。このファイル中には図１１（ｂ）に示すように、最新バージョンのバージョン番号１１４が記録されている。
【００４１】
また、各キャッシュ・ファイル１１３には、通常のデータの他、図１１（ｃ）に示すように、キャッシュ・ファイルの総数１１５と、過去のバージョン番号１１６とが記録されている。ただし、キャッシュ・ファイルの総数は、そのファイルを作った時点の数であるので、古いバージョンのファイルでは、ファイルの総数を示すわけではない。
【００４２】
次に、以上の要素を用いて、実際にデータを読む手順及びヒストリ機能の動作を具体的に説明する。ここでは図１２に示す状況を考える。つまり、最初はサーバＡ（１５）中のａ．ｈｔｍｌファイル１２１からサーバＢ（１６）のｂ．ｈｔｍｌファイル１２２に対してリンクが張られていた。そして、その後に「（１）サーバＢ（１６）のｂ．ｈｔｍｌファイル１２２の内容が変更」され、さらにその後のある時点で「（２）サーバＡ（１５）上のａ．ｈｔｍｌファイル１２１が変更され、それまで、サーバＢ（１６）のｂ．ｈｔｍｌを指していたリンクが、サーバＣ（１７）のｃ．ｈｔｍｌファイル１２３を指すようになった」場合である。
【００４３】
まず、最初にサーバＡ（１５）のａ．ｈｔｍｌファイル１２１を読み、そこからリンクをたどって、サーバＢ（１６）のｂ．ｈｔｍｌファイル１２２やサーバＣ（１７）のｃ．ｈｔｍｌファイル１２３を読む場合の動作を説明する。最初に利用者は、サーバＡ（１５）のａ．ｈｔｍｌファイル１２１を読む。このとき端末１３側では従来通りの動作（図７）を行う。また、このとき中継サーバ１２ではデータをキャッシュする。この手順を図１３のフローチャートを参照して説明する。
【００４４】
中継サーバ１２では、端末１３から送られて来たＵＲＬを受信する（Ｓ１３０１）と、そのＵＲＬがバージョン付きかどうかを調べる（Ｓ１３０２）。このＵＲＬがバージョン付きでなく通常のＵＲＬである場合は（Ｓ１３０２：ＮＯ）、そのＵＲＬに合致するキャッシュを検索する（Ｓ１３０３）。最初に指定されたデータを読む時にはキャッシュにデータはないので（Ｓ１３０４：ＮＯ）、サーバＡ（１５）からａ．ｈｔｍｌファイル１２１を読み込む（Ｓ１３０７）。読み込んだデータはキャッシュに書き込まれ（Ｓ１３０９）、その後、端末１３に送信される（Ｓ１３１０）。
【００４５】
ここで、上記Ｓ１３０９でのキャッシュへの書き込み手順を図１４のフローチャートを参照して説明する。まず、最初のステップＳ１４０１では、バージョン番号を生成する。本実施形態では、バージョン番号として日付を用いているので、タイマ機能８６（図８参照）により日付を取り出すことでバージョン番号が得られる。
【００４６】
次に、ＵＲＬからディレクトリ名とファイル名を取り出す（Ｓ１４０２）。この場合は、「ｈｔｔｐ／Ａ」というディレクトリと「ａ．ｈｔｍｌ」というファイル名になる。そして、このディレクトリ中でインデックス・ファイルを検索する（Ｓ１４０３）。最初のアクセス時には、当然インデックス・ファイルはないので（Ｓ１４０４：ＮＯ）、ディレクトリに新たにインデックス・ファイルを作成する（Ｓ１４０７）。そして、さらに新規のデータ・キャッシュ・ファイル１２６（図１２（ｂ）参照）を作成し（Ｓ１４０８）、そのデータ・キャッシュ・ファイル１２６には、バージョン情報を追加して（Ｓ１４０９）、内容を書き込む（Ｓ１４１０）。
【００４７】
その後のアクセス時には、すでに古いバージョンのファイルが存在している場合もある。その場合には（Ｓ１４０４：ＹＥＳ）、Ｓ１４０５で作成した新規ファイルに一つ前のバージョンのファイルのヘッダをコピーし（Ｓ１４０６）、それから新バージョンを追加する（Ｓ１４０９）。つまり、各キャッシュ・ファイルは、そのファイル以前のバージョンの情報を全て持つことになる。
【００４８】
さて、このようにして、図１２（ａ）に示すサーバＡ（１５）からａ．ｈｔｍｌファイル１２１を中継した後、ユーザがａ．ｈｔｍｌファイル１２１に記述されているリンクをマウス３７でクリックしてサーバＢ（１６）のｂ．ｈｔｍｌファイル１２２を要求したとする。この場合も同様の手順でサーバＢ（１６）からｂ．ｈｔｍｌファイル１２２が転送され、中継サーバ１２にキャッシュされる。
【００４９】
この後しばらく時間がたち、サーバＢのファイルｂ．ｈｔｍｌが変更されたとする。そして、再びユーザが同様の手順でサーバＡ（１５）、サーバＢ（１６）にアクセスした場合の動作を以下に説明する。この場合には、図１３に示すように、キャッシュの検索（Ｓ１３０３）時、データが有ることが判るので（Ｓ１３０４：ＹＥＳ）、そのデータが更新されているかどうかを調べる（１３０５）。これは、サーバＡ（１５）に対して、ａ．ｈｔｍｌファイル１２１が更新されているどうかを問い合わせることによって行われる。
【００５０】
この時点では、サーバＡ（１５）のデータは更新されていないので、キャッシュから図１２８（ｂ）に示すデータ１２６を読み出して（Ｓ１３０８）、それを端末１３に送信する（Ｓ１３１０）。続いて、ユーザが前回同様に、ａ．ｈｔｍｌファイル１２１からのリンクをたどってサーバＢ（１６）のデータを要求した場合には、同様の手順でサーバＢ（１６）からｂ．ｈｔｍｌファイル１２２を受信する。このときにはデータが更新されているので（Ｓ１３０６：ＹＥＳ）、サーバＢ（１６）から新たにデータを受信し（Ｓ１３０７）、キャッシュした上で（Ｓ１３０９）、端末１３にデータを送信する（Ｓ１３１０）。
【００５１】
さて、ここまでの処理は、従来のキャッシュ機能付きの中継サーバにおいてもすでに実現されていることである。それに対して、この状態からヒストリをたどることにより過去のデータが取り出せることが本発明の特徴である。そこで、ヒストリをたどることにより過去のデータを取り出す場合の処理を説明する。
【００５２】
本実施形態における端末１３の画面表示は図５に示すようになっている。上述したように、ヒストリ・ボタン５５，５６は過去のデータを取り出す際のヒストリをたどるため用いられ、図５中で左側にあるボタン５５をクリックすると一つ前のバージョンを表示させることができ、右側のボタン５６をクリックすると一つ後の新らしいバージョンを表示させることができる。
【００５３】
このときの端末１３および中継サーバ１２の動作を、上述したサーバＢ（１６）のｂ．ｈｔｍｌファイル１２２（図１２（ａ）参照）を例に取って説明する。図１５に示すフローチャートは、図７に示した従来の処理にヒストリ機能に係る処理を追加したものであり、Ｓ１５０１〜Ｓ１５０３の処理は、図７のＳ７１〜Ｓ７３の処理と同じ内容の処理を行う。その後、端末１３は、ｂ．ｈｔｍｌファイル１２２を表示している状態にあり、これは図１５のＳ１５０６に示すマウス入力待ち状態である。
【００５４】
次に、ユーザがヒストリ・ボタン５５，５６を押すと、マウス３７のクリック位置がマウス入力機能９８（図９参照）を介して入力される。次にその位置を調べると（Ｓ１５０７）、ヒストリ・ボタン５５，５６上であることが判るので（Ｓ１５０８：ＹＥＳ）、バージョン指定のＵＲＬを生成する（Ｓ１５１０）。
【００５５】
このＵＲＬは、通常のデータｂ．ｈｔｍｌにバージョン番号を追加することにより生成される。前に説明したように、データには、それまでのバージョン情報が入っているので、一つ前の場合には、データ中のバージョン情報から対応するものを取り出して使えば良い。つまり、「＠＠＠＊９５０９１０＊ｈｔｔｐ：／／Ｂ／ｂ．ｈｔｍｌ」となる。また、一つ後の場合は、現時点で表示してあるバージョン番号に、「＋１」を指定すれば良い。この場合、「＠＠＠＊９５１０１０＊＋１＊ｈｔｔｐ：／／Ｂ／ｂ．ｈｔｍｌ」となる。次に端末１３は、このＵＲＬを中継サーバ１２に送信し、対応するバージョンのデータを受信する。中継サーバ１２での処理は、図１３に示すように、ＵＲＬを受信するとバージョン付きかどうかを調べた後（Ｓ１３０２）、バージョン付きであるのでＳ１３１１へ移行してキャッシュを検索する。
【００５６】
このＳ１３１１でのキャッシュ検索処理について図１６のフローチャートを参照して説明する。例えば、ＵＲＬが「＠＠＠＊９５０９１０＊ｈｔｔｐ：／／Ｂ／ｂ．ｈｔｍｌ」の場合は、ＵＲＬからディレクトリ名とファイル名を取り出した後（Ｓ１６０１）、インデックス・ファイルを検索し（Ｓ１６０２）、最新のキャッシュ・ファイルからバージョン情報を取り出す（Ｓ１６０４）。続くＳ１６０５では指定バージョンがあるかどうか判断する。この場合、バージョン情報中にはバージョン９５０９１０のものが存在しているので（Ｓ１６０５：ＹＥＳ）、Ｓ１６０９に移行する。
【００５７】
Ｓ１６０９では＋−指定があるかどうかを判断する。この場合のＵＲＬには＋−指定はないので（Ｓ１６０９：ＮＯ）、キャッシュにあることが確定して本キャッシュ検索処理を終了する。従って、この場合は図１３の処理に戻った場合、Ｓ１３１２にて肯定判断となるため、中継サーバ１２は、該当するキャッシュデータをファイルシステムから読み出し（Ｓ１３０８）、端末１３側に送信する（Ｓ１３１０）。
【００５８】
一方、図１６の処理において、ＵＲＬが「＠＠＠＊９５１０１０＊＋１＊ｈｔｔｐ：／／Ｂ／ｂ．ｈｔｍｌ」の場合には、同様に９５１０１０のバージョンが存在するため（Ｓ１６０５：ＹＥＳ）、Ｓ１６０９へ移行する。しかしこの場合は＋１指定があるので（Ｓ１６０９：ＹＥＳ）、このバージョンより一つ新しいバージョンを探す（Ｓ１６１０）。しかし、キャッシュ中には該当するデータはないので（Ｓ１６１１：ＮＯ）、キャッシュにないことが確定して本キャッシュ検索処理を終了する。
【００５９】
従って図１３のＳ１３１２にて否定判断となるため、この場合の中継サーバ１２は、該当するバージョンのファイルは無いというエラー情報を端末１３に送信する（Ｓ１３１３）。そして、中継サーバ１２からデータを受信した端末１３は、正しいデータであればそのデータを表示装置３５（図３（ｂ）参照）に表示し、エラーであればその旨をユーザに知らせる。
【００６０】
この様に、ユーザは、ヒストリ・ボタン５５，５６をマウス３７でクリックするだけで容易にファイルのヒストリをたどり、任意のバージョンのファイルを見ることができる。さて、このようにバージョン指定を行って過去のデータにアクセスする場合には、リンクの取り扱いも通常の場合とは異なってくる。つまり、過去のデータ中にあるリンクはその過去の時点のものであるので、現時点においては必ずしも存在するものではない。
【００６１】
この場合の例として、図１２（ａ）中に（２）で示すようにサーバＡ（１５）中のａ．ｈｔｍｌファイル１２１が変更され、サーバＢ（１６）のｂ．ｈｔｍｌファイル１２２を指していたものがサーバＣ（１７）のｃ．ｈｔｍｌファイル１２３を指すようになった場合を考える。
【００６２】
まず、端末１３からは、サーバＡ（１５）のａ．ｈｔｍｌファイル１２１を読み出す要求が来る。この場合ａ．ｈｔｍｌファイル１２１は変更されているので、中継サーバ１２はこれまでに説明した手順でサーバＡ（１５）からａ．ｈｔｍｌファイル１２１を受信してキャッシュし、端末１３に送信する。
【００６３】
端末１３は、受信したデータを表示する。そしてユーザがハイパーリンクをクリックすると、今度はサーバＣ（１７）のｃ．ｈｔｍｌファイル１２３を要求し、同様の手順によって処理が行われる。この後、ユーザは表示装置３８における画面表示をａ．ｈｔｍｌファイル１２１に対応したものに戻した後、ヒストリ・ボタン５５，５６を押して、一つ前のバージョンを要求したとする。既に説明した手順に従って一つ前のバージョンのａ．ｈｔｍｌファイル１２１が転送され、表示される。
【００６４】
ここで、リンクをクリックすると、今度はサーバＢ（１６）のｂ．ｈｔｍｌファイル１２２が要求される。このとき端末１３側は、ＵＲＬ作成時にａ．ｈｔｍｌファイル１２１のバージョンに、近いバージョンを指定するＡフラグ１０４（図１０参照）を付加したＵＲＬを作成する。つまり、「＠＠＠＊９５０９１０＊Ａ＊ｈｔｔｐ：／／Ｂ／ｂ．ｈｔｍｌ」を中継サーバ１２に要求する。ここで、Ａフラグ１０４を使用するのは、ａ．ｈｔｍｌファイル１２１のバージョンと、ｂ．ｈｔｍｌファイル１２２のバージョンが完全に一致することはないので、Ａフラグ１０４を付けないと対応するバージョンのファイルが検索できないためである。
【００６５】
中継サーバ１２は、Ａフラグ１０４を持つＵＲＬを受信した場合でも同様にキャッシュの検索を行う。これは、図１６のＳ１６０１〜Ｓ１０６４の処理に示すように、ファイル名とディレクトリ名からインデックス・ファイルを検索し、最新のファイルからバージョン番号を取り出すところまではＡフラグ１０４が無い場合と同じであることからも判る。
【００６６】
そしてＡフラグ１０４が付いていると（Ｓ１６０７：ＹＥＳ）、指定のバージョンのファイルが無い場合でも（Ｓ１６０５：ＮＯ）、近いバージョンを取り出す（Ｓ１６０８）。近いバージョンとは、各キャッシュ・ファイルのバージョン番号と指定されたバージョン番号の差が最も小さくなるバージョン番号を持つキャッシュ・ファイルである。
【００６７】
こうして、ａ．ｈｔｍｌファイル１２１の古いバージョンに最も近いバージョンのｂ．ｈｔｍｌファイル１２２がキャッシュ中から取り出され、端末１３に送られる。ファイルの更新が頻繁な場合には、こうして取り出したファイルが必ずしも、以前にａ．ｈｔｍｌファイル１２１からリンクをたどって取り出したものとは一致しない場合もあるが、その場合でも、ユーザがヒストリ・ボタン５５，５６を使っていくつか前の、あるいはいくつか後のバージョンを取り出すことにより、容易に目指すバージョンのデータを取り出すことができる。
【００６８】
以上、本発明はこのような実施例に何等限定されるものではなく、本発明の主旨を逸脱しない範囲において種々なる形態で実施し得る。例えば、上記実施形態では、図２に示す中継サーバ１２と任意の一つの端末１３とで「履歴管理機能付き情報端末装置」が構成されることになるが、両機能を兼ね備えた端末装置として最初から構成してもよい。但し、上記実施形態のようにすれば、１台の中継サーバ１２における履歴管理機能や記憶機能を、複数台の端末１３が共用できるため、記憶容量の節約等の点で有利ではある。
【００６９】
また、上記実施形態においては、マウス３７によってヒストリ・ボタン５５，５６をクリックすることによりバージョンの指定を行っていたが、キーボード３６（図３（ｂ）参照）を用いて、明示的にバージョン付きのＵＲＬを入力してもバージョンの指定が行える。また、キャッシュ・ファイル中には過去のバージョン情報が入っているので、これを表示装置３５にメニュー形式で表示し、ユーザに選択させることも可能である。
【００７０】
また、このキャッシュ・ファイルの内容は、同一のＵＲＬに対しては変更があった場合でも一部分のみの変更である場合が多い、従って、キャッシュする際、ファイル全体をキャッシュするのではなく、過去のファイルとの差分をとり、その差分のみをキャッシュすることで、図３（ａ）に示すディスク２４の記憶容量を少なくすることも可能である。
【図面の簡単な説明】
【図１】本発明の構成を例示する説明図である。
【図２】実施形態の履歴管理機能付き情報端末装置が適用されるネットワークのブロック図である。
【図３】実施形態において使用される機器のハードウェアのブロック図である。
【図４】ｈｔｍｌファイルのサンプルを示す説明図である。
【図５】表示のサンプルを示す説明図である。
【図６】ＵＲＬを示す説明図である。
【図７】従来の端末における処理手順を示すフローチャートである。
【図８】中継サーバの機能ブロック図である。
【図９】端末装置の機能ブロック図である。
【図１０】バージョン付きＵＲＬの説明図である。
【図１１】キャッシュデータの構造を示す説明図である。
【図１２】時間の経過に対する中継サーバ上のデータの変化を示す説明図である。
【図１３】中継サーバの動作を示すフローチャートである。
【図１４】キャッシュへの書き込み手順を示すフローチャートである。
【図１５】実施形態における端末の処理手順を示すフローチャートである。
【図１６】キャッシュの検索手順を示すフローチャートである。
【符号の説明】
１１…ＬＡＮ
１２…中継サーバ
１３…端末
１４…ＷＡＮ
１５，１６，１７…サーバ
２１…ネットワークインターフェース
２３…メモリ
２４…ディスク
３１…ネットワークインターフェース
３３…メモリ
３５…表示装置
３６…キーボード
３７…マウス
３８…表示装置
５５，５６…ヒストリ・ボタン
８３…ＵＲＬ処理機能
８４…キャッシュ管理機能
８５…ファイルシステム機能
９４…ファイル管理機能
９５…バージョン管理機能
９６…ｈｔｍｌ処理機能
９７…リンク情報選択機能

Claims

複数の情報提供手段がネットワークで接続されて分散型データベースを構成するシステムに対し、前記情報提供手段内のデータを検索あるいは取得するための情報端末装置において、前記ネットワーク介して前記情報提供手段から得られた情報を記憶し、この記憶している情報を端末装置へ送信する中継サーバであって、
ネットワークを介して通信を行うための通信手段と、
該通信手段を介して前記情報提供手段から得られた情報を、時間の推移に従った管理を行うための履歴管理手段と、
前記履歴管理手段から受け取った情報を記憶しておく記憶手段とを備え、
前記履歴管理手段は、
前記通信手段を介して前記端末装置からＵＲＬ（ uniform resource locator ）を受信する受信手段と、
前記受信手段によって受信されたＵＲＬに、情報のバージョンを指定するためのバージョン指定情報が付加されていない場合、このＵＲＬに対応する情報が前記記憶手段に存在するか否かを判断する存在判断手段と、
前記存在判断手段によって前記記憶手段に情報が存在しないと判断された場合、当該ＵＲＬに対応する情報を前記通信手段を介して前記情報提供手段から取得し、この取得した情報をこの情報のバージョンを示す情報と共に前記記憶手段に記録する第１記録手段と、
前記存在判断手段によって前記記憶手段に情報が存在すると判断された場合、当該情報が更新されているか否かを判断する更新判断手段と、
前記更新判断手段によって、情報が更新されていると判断した場合、当該ＵＲＬに対応する情報を前記通信手段を介して前記情報提供手段から新たに取得し、この取得した情報をこの情報のバージョンを示す情報と共に前記記憶手段に記録する第２記録手段と、
前記受信手段によって受信されたＵＲＬに、情報のバージョンを指定するためのバージョン指定情報が付加されている場合、このバージョン指定情報で指定されたバージョンに対応する情報を前記記憶手段から読み出し、これを前記通信手段を介して前記端末装置へ送信する送信手段とを備えたこと
を特徴とする中継サーバ。
請求項１に記載の中継サーバにおいて、
前記履歴管理手段が備える送信手段は、
前記受信手段によって受信されたＵＲＬに追加されている前記バージョン指定情報に、直近のバージョンを示すフラグ情報が付加されている場合、当該バージョン指定情報で指定されたバージョンに対応する情報が前記記憶手段に存在すれば、この情報を前記記憶手段から読み出してこれを前記端末装置へ送信し、当該バージョン指定情報で指定されたバージョンに対応する情報が前記記憶手段に存在しなければ、前記記憶手段に記憶された情報の中から指定されたバージョンに最も近いバージョンに対応する情報を読み出し、これを前記端末装置へ送信すること
を特徴とする中継サーバ。
請求項１又は請求項２に記載の中継サーバにおいて、
前記履歴管理手段が備える送信手段は、
前記受信手段によって受信されたＵＲＬに追加されている前記バージョン指定情報に、或るバージョンに対する相対的なバージョンを指定するための符号及び値を含む相対指定情報が付加されている場合、この相対指定情報で指定されたバージョンに対応する情報を前記記憶手段から読み出し、これを前記通信手段を介して前記端末装置へ送信すること
を特徴とする中継サーバ。