JPH11149404A - ハイパーメディア蓄積管理方法 - Google Patents

Abstract

(57)【要約】 【課題】 ファイルの内容を変更せずに複写によるリン
ク破壊問題を防ぎ、リンクのバージョン不整合問題を防
ぎ、かつ元のＵＲＬを控えておく必要をなくす。 【解決手段】 プロキシサーバは、クライアントの要求
に対するサーバの応答を応答蓄積エリアに蓄積すると
き、要求の要求情報アドレスと応答の付加情報に含まれ
る最終更新時刻をパラメタとして結合したものを蓄積す
る応答のインデックスとして蓄積し、クライアントから
の要求内容に対して、前記応答蓄積エリアを検索し、検
索に成功したときその応答をクライアントに返送し、応
答をクライアントに返送出来ないときは、プロキシサー
バからのリダイレクションアドレスによる応答、あるい
はサーバに要求を通知し、サーバからの応答に基づくリ
ダイレクションアドレスによる応答を行うようにしてい
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ネットワークで接
続された複数の計算機によって情報を発信、および閲覧
するためのハイパーテキストに係り、特にWWW(World Wi
de Web)の文書の蓄積、共有に関する。

【０００２】

【従来の技術】従来、WWWと呼ばれるシステムにおい
て、ネットワークで接続されたクライアントとプロキシ
サーバとサーバが次のように動作する。クライアント
は、ネットワークに接続された任意の計算機上のファイ
ルのアドレスを示すＵＲＬ(Uniform Resource Locator)
が利用者によって指定されると、該クライアントは、そ
のＵＲＬを記述された要求を作成してプロキシサーバに
通知し、プロキシサーバから該要求に対する応答を取得
する。要求には、ヘッダーと呼ばれる付加情報が記述さ
れる。ＵＲＬにはファイルのアドレスに任意のパラメー
タを付加することができる。ＵＲＬに付加されたパラメ
タの解釈方法は、サーバごとに、あるいはプロキシサー
バごとに定義される。

【０００３】ヘッダーは、属性名と属性値の対を複数個
含むことができる。本発明の説明に必要とする要求に付
加されたヘッダーの属性名は"Referer"と"Pragma"であ
る。Refererは、参照元アドレスを示すものである。つ
まり、利用者がＵＲＬ-1を指定することにより、クライ
アントがそのＵＲＬ-1を指定した要求を作成してプロキ
シサーバに通知し、その結果取得した応答の中に別のＵ
ＲＬ-2が記述されている場合に、利用者がその別のＵＲ
Ｌ-2を指定することにより、クライアントがＵＲＬ-2を
指定した要求を作成するときに、ヘッダーのRefererの
属性値に参照元のＵＲＬ-1が設定される。プロキシサー
バに要求を通知する際に、後で説明するキャッシュ機能
を使用せずにサーバのファイルの内容を取り出して応答
とすることを指定したい場合に、要求のPragmaの属性値
に"no-cache"を指定する。つまり、Pragmaの属性値に"n
o-cache"があることは、最新情報取得指示を表す。クラ
イアントで最新情報取得指示を指定する操作をリロード
と呼ぶ。また、クライアントは、ＵＲＬ-Aを指定した要
求をプロキシサーバに通知し、その結果取得した応答の
ヘッダーに属性名が"Location"であるものが存在すると
き、Locationの属性値をＵＲＬ-Bと見なし、その応答を
取得後に、自動的にその応答の元となる要求のＵＲＬ-A
をLocationの属性値のＵＲＬ-Bに置き換えた要求を作成
してプロキシサーバにその要求を通知し、プロキシサー
バから該要求に対する応答を取得する。このように、取
得した応答のヘッダーに記述された別のＵＲＬ（上記の
場合、ＵＲＬ-B）を指定した要求を作成して通知し、応
答を取得することをリダイレクションと呼ぶ。

【０００４】プロキシサーバは、クライアントからの要
求を取得して、その要求をサーバに通知し、サーバから
の応答を取得して、その応答をクライアントに返送す
る。プロキシサーバがキャッシュ機能を持つ場合は、ク
ライアントからの要求に記述されているＵＲＬをインデ
ックスにして、サーバから取得した応答を蓄積し、クラ
イアントから同じＵＲＬを指定された要求を取得した際
に、最新情報取得指示がなければ、サーバに要求を通知
する代わりに、キャッシュに蓄積した応答を上記インデ
ックスにより検索して返送する。サーバは、プロキシサ
ーバからの要求を取得して、要求にあるＵＲＬが示すフ
ァイルを検索し、その検索したファイル内容を持つ応答
を作成してプロキシサーバに返送する。該応答はヘッダ
ーを持つ。サーバは、要求されたファイルの最終更新時
刻を、その旨を表すヘッダーの属性名"Last-Modified"
の属性値に設定する。

【０００５】このようにして、クライアント、プロキシ
サーバ、サーバがそれぞれ物理的にどこにあってもネッ
トワークに接続されていれば、サーバのファイルをＵＲ
Ｌによって指定することでクライアントがそのファイル
を参照することが可能である。上記の、クライアント、
プロキシサーバ、サーバの作用は、インタネットで検索
されるRFC(Request for Comments)1945、RFC2068に記述
されている内容の一部であり、本発明の説明に必要な部
分の要点を記述した。サーバのファイルは、サーバの管
理者の事情に従って作成され、更新され、あるいは削除
される。このサーバのファイルの作成、更新、削除に当
たっては多くの場合、クライアントの利用者の事情は考
慮されない。これは、クライアントはＵＲＬを指定すれ
ば、常に最新のファイル内容を参照できるという利点を
もたらす。しかし、クライアントの利用者は、最新の情
報でなく、そのファイルがサーバで更新されたり、削除
されたりしたあとでも、更新前、削除前の状態で参照し
たいことがあると考えた場合もある。この場合には、ダ
ウンロードなどによってファイルを手元の計算機に複写
することで保存する。サーバのファイルが更新されたり
削除されたりしたときは、複写したファイルを参照する
ことで対処する。

【０００６】

【発明が解決しようとする課題】更新前、削除前の状態
を参照したいときなどにおいて、サーバにあるファイル
をダウンロードなどによって手元の計算機に複写して保
存し、この複写したファイルを参照する場合には、その
複写のファイルのＵＲＬを指定して参照を行う。このと
き、本明細書では、解決すべき問題点として３個の問題
点を挙げる。

【０００７】第１の問題点は、ハイパーテキストの特徴
であるリンクが破壊される場合があるという問題点であ
る。この問題点を、本明細書では複写によるリンク破壊
と呼ぶことにする。この問題点を詳しく説明する。リン
クの記述方法には、相対リンクと絶対リンクがある。相
対リンクは、リンク先のファイルの所在を、リンク元の
ファイルの所在を基点として相対的に記述するものであ
り、同じフォルダ内に存在するファイルや同じ計算機内
に存在するファイルのような場合に使用され、リンクの
記述はリンク元のファイルからリンク先のファイルまで
の記述となる。リンクされたファイルを複写する際に、
複写の所在の相対的関係が、複写元の相対的関係と同じ
であるように複写されれば、相対リンクは破壊されな
い。しかし、複写が部分的に行われ、リンク先を複写し
てないような場合には、リンク先までのリンクは破壊さ
れる。絶対リンクは、リンク先のファイルの所在をその
リンクの記述だけで一意に決定できるように記述するも
のであり、リンク先のファイルの所在が別の計算機にあ
るような場合に使用され、リンクの記述は別の計算機の
ホスト名からリンク先のファイルまでの記述となる。こ
の場合、リンクされたファイルを複写しても、そのリン
クは複写の方を参照することなく、複写元の方を参照し
つづける。複写元が削除、変更されたときにも複写元の
方を参照し、複写を行った意図に反して複写の方を参照
しない。すなわち、複写されたファイルへのリンクは実
質上破壊されていることになる。このように破壊された
リンクを書き直して修復する方法が存在するが、複写を
追加する度に、既に複写済みのファイルの中のリンクが
破壊される可能性があり、そのリンクの検出にコストが
かかる。

【０００８】第２の問題点は、リンク先に複数のバージ
ョンが存在するときに、バージョンの整合性が取れない
場合があるという問題点が生じる。この問題点を本明細
書ではリンクのバージョン不整合問題と呼ぶことにす
る。リンク元のファイルが変更されずにリンク先のファ
イルが更新される場合で、その更新されるファイルを更
新の度に保存したい場合は、リンク先のファイルを異な
る場所に複写して保存する。このとき、リンク元のファ
イルからリンクをたどる際にリンク先のバージョンが複
数個存在することになるが、その選択の手段がなく、そ
のリンクは特定の一つのバージョン（通常、最新のバー
ジョン）を示す。そしてこのようなリンクが多数存在す
ると、リンク元のファイルのバージョンとリンク先のフ
ァイルのバージョンの組み合わせに、実際にはありえな
い組み合わせを作成する場合があり、バージョンの整合
性を保つことが困難になる。

【０００９】第３の問題点は、複写先のファイルのＵＲ
Ｌは、元のファイルのＵＲＬとの関連がないので、最新
のファイル内容を取得するためには、別途、元のＵＲＬ
を控えておかなくてはならないという問題点である。

【００１０】発明者は、過去に、上記の第１から第３の
問題点を解決する発明として特願平8-150696号を提案し
たが、これは、クライアントとプロキシサーバの両方を
変更する必要が有って、既に市場に浸透しているクライ
アントを変更することは市場に受けいられ難いという問
題点が有った。

【００１１】本発明の目的は、既に市場に浸透した従来
の技術に基づくクライアントおよびサーバを入れ替える
ことなく使用して、クライアントとサーバを仲介する本
発明によるハイパーメディア蓄積管理方法を実施したプ
ロキシサーバを導入するだけで、上記第１から第３の問
題点を同時に解決し、すなわち、ファイルの保存の際の
複写とＵＲＬの付け替えをプロキシサーバ上で行うこと
で、ファイルの内容を変更せずに複写によるリンク破壊
問題を防ぎ、また、保存したファイルの最終更新時刻、
消滅時刻を管理することとRefererによって参照関係を
把握することでリンクのバージョン不整合問題を防ぎ、
また、ファイルの保存の際にも元のＵＲＬとの関連を維
持することで、最新のファイル内容を取得するために別
途、元のＵＲＬを控えておく必要をなくす方法を提供す
ることにある。

【００１２】

【課題を解決するための手段】上記目的を達成するた
め、本発明は、クライアントとサーバのネットワークを
介した通信を仲介するプロキシサーバにおけるハイパー
メディア蓄積管理方法であり、プロキシサーバは、クラ
イアントの要求に対するサーバの応答を応答蓄積エリア
に蓄積するとき、前記要求に含まれる要求情報アドレス
として指定されているファイルアドレスに前記応答の付
加情報に含まれる最終更新時刻をパラメタとして結合し
たものを該蓄積する応答のインデックスとして蓄積し、
クライアントからの要求の要求情報アドレスに時刻を指
定するパラメタが付加されていない場合は、応答蓄積エ
リアのインデックスから該要求情報アドレスを含むアド
レスを検索し、検索成功のときは検索したインデックス
内の時刻をパラメタとして付加した前記要求情報アドレ
スをリダイレクションアドレスとする応答を作成してク
ライアントに返送し、検索不成功のときは前記要求情報
アドレスを持つ要求をサーバに通知し、その応答を前記
応答蓄積エリアに蓄積し、その応答の最終更新時刻に基
づいた時刻をパラメタとして付加した前記要求情報アド
レスをリダイレクションアドレスとする応答を作成して
クライアントに返送するようにしている。

【００１３】前記要求情報アドレスに時刻を指定するパ
ラメタが付加されている場合に、該要求情報アドレスと
時刻からなるインデックスを持つ応答を前記応答蓄積エ
リアから検索し、検索に成功したときその応答をクライ
アントに返送し、検索不成功のときは、前記要求情報ア
ドレスから時刻を指定するパラメタを削除した要求をサ
ーバに通知して応答をサーバから取得しその応答を前記
応答蓄積エリアに蓄積し、該応答の最終更新時刻と要求
の中の要求情報アドレスの時刻が一致するときは、その
応答をクライアントに返送し、一致しないときは、要求
に答えられない旨の応答を作成してクライアントに返送
するようにしている。

【００１４】前記サーバから取得した応答のファイルア
ドレスで前記応答蓄積エリアを検索し、該応答のファイ
ルアドレスと同一のファイルアドレスを含むインデック
スのうちで最終更新時刻が最新であるインデックスの応
答を求め、該求めた応答の消滅時刻として前記サーバか
ら取得した応答の最終更新時刻を記録するようにしてい
る。

【００１５】クライアントからの要求の要求情報アドレ
スと該要求に付加された参照元アドレスと該参照元アド
レスの付加情報に含まれる最終更新時刻を結合したイン
デックスと、前記要求の要求情報アドレスのファイルの
最終更新時刻とを登録した参照関係時刻対応蓄積エリア
を設け、クライアントからの要求の要求情報アドレスに
時刻を指定するパラメタが付加されていない場合のう
ち、要求の付加情報に参照元アドレスがあってその参照
元アドレスに時刻を指定するパラメタが付加されている
ときは、該要求の要求情報アドレスと参照元アドレスと
時刻の結合をインデックスとして前記参照関係時刻対応
蓄積エリアを検索し、前記要求の要求情報アドレスのフ
ァイルの最終更新時刻が検索されたとき、前記クライア
ントからの要求の要求情報アドレスと該検索した最終更
新時刻との結合をインデックスとして前記応答蓄積エリ
アを検索し、検索に成功したとき、該インデックスとし
て使用したクライアントからの要求の要求情報アドレス
と検索した最終更新時刻の組合せをリダイレクションア
ドレスとする応答を作成してクライアントに返送するよ
うにしている。

【００１６】前記検索に成功しないときは、参照元アド
レスをインデックスにして応答蓄積エリアに蓄積された
応答を検索してその最終更新時刻と消滅時刻を得て、そ
の最終更新時刻と消滅時刻が、参照関係にあるものとし
て矛盾しない最終更新時刻および消滅時刻を持つ応答
で、かつ、要求情報アドレスのファイルアドレスをイン
デックスに含む応答を一つ応答蓄積エリアから検索し、
インデックスとして使用したクライアントからの要求の
要求情報アドレスと検索した最終更新時刻の組合せをリ
ダイレクションアドレスとする応答を作成してクライア
ントに返送するようにしている。

【００１７】前記検索した応答の最終更新時刻を、要求
情報アドレスのファイルアドレスと参照元アドレスと該
参照元アドレスに付された最終更新時刻を結合したもの
をインデックスにして参照関係時刻対応蓄積エリアに蓄
積するようにしている。

【００１８】クライアントの要求の付加情報に最新情報
取得指示がある場合に、要求情報アドレスのファイルア
ドレスが同じである要求に対する前回のプロキシサーバ
の応答がリダイレクションアドレスを持つ応答でないと
き、または、そのような要求がこれまでにないとき、ま
たは、前記要求情報アドレスのファイルアドレスが同じ
である要求に対する前回のプロキシサーバの応答がリダ
イレクションアドレスを持つ応答であっても要求の要求
情報アドレスに時刻を指定するパラメタが付加されてい
ないときは、前記要求情報アドレスから時刻を指定する
パラメタを削除した要求をサーバに通知して、応答をサ
ーバから取得してその応答を前記応答蓄積エリアに蓄積
し、前記要求情報アドレスのファイルアドレスにその応
答の最終更新時刻に基づいた時刻を指定するパラメタを
付加したものをリダイレクションアドレスとする応答を
作成してクライアントに返送し、前記要求情報アドレス
のファイルアドレスが同じである要求に対する前回のプ
ロキシサーバの応答がリダイレクションアドレスを持つ
応答であり、かつ、要求情報アドレスに時刻を指定する
パラメタが付加されているものであるときは、要求情報
アドレスに基づいて前記応答蓄積エリアを検索するため
のインデックスを作成して、そのインデックスで該応答
蓄積エリアに蓄積された応答を検索し、その応答をクラ
イアントに返送するようにしている。

【００１９】前記要求情報アドレスに付加する時刻を指
定するパラメタが応答の最終更新時刻であるようにして
いる。

【００２０】

【発明の実施の形態】図１に、本発明によるハイパーメ
ディア蓄積管理方法を適用するためのプロキシサーバ10
03の利用形態と構成を表す。プロキシサーバ1003は、ネ
ットワーク1002を介してクライアント1001、および、サ
ーバ1008と接続して利用される。プロキシサーバ1003
は、通信仲介処理部1004と、これに接続したハイパーメ
ディア蓄積管理部1005と、ハイパーメディア蓄積管理部
1005に接続した応答蓄積エリア1006と、参照関係時刻対
応蓄積エリア1007から構成される。通信仲介処理部1004
は、従来の技術に従って、クライアント1001からの要求
をネットワーク1002を介して取得し、その要求に対する
応答をクライアント1001にネットワーク1002を介して返
送し、あるいは、サーバ1008にネットワーク1002を介し
て要求を通知して、その要求に対する応答をサーバ1008
からネットワーク1002を介して取得する。

【００２１】ハイパーメディア蓄積管理部1005について
は、まず、動作の概要を説明する。ハイパーメディア蓄
積管理部1005は、通信仲介処理部1004がサーバ1008から
応答を取得したときに、この応答の元となったクライア
ントの要求で指定されたＵＲＬのファイルアドレスにそ
の最終更新時刻をパラメータとして付加したＵＲＬを作
成し、その作成したＵＲＬをインデックスとしてその応
答を応答蓄積エリア1006に蓄積する。また、通信仲介処
理部1004がクライアント1001から取得した要求で指定さ
れたＵＲＬに最終更新時刻を表すパラメータがない場合
には、通信仲介処理部1004が、そのパラメータをつけた
ＵＲＬを作成して、この作成したＵＲＬを付与して、リ
ダイレクションを指示する応答をクライアントに返送す
ることによって、クライアントがリダイレクションを行
うようにし、クライアントからの要求にあるＵＲＬには
最終更新時刻を表すパラメータが付加されるようにす
る。また、通信仲介処理部1004は、クライアントから取
得した要求で指定されたＵＲＬに最終更新時刻を表すパ
ラメータがある場合には、そのＵＲＬをインデックスと
して応答蓄積エリア1006に蓄積した応答を検索し、その
応答をクライアント1001に返送する。

【００２２】また、リダイレクションを指示する応答を
クライアントに返送するために、最終更新時刻を表すパ
ラメータをつけたＵＲＬを作成するときに、要求のヘッ
ダーにあるRefererを利用してハイパーリンクによる参
照関係にあるデータの最終更新時刻、消滅時刻を把握し
て、応答蓄積エリア1006に蓄積した応答の中から適切な
最終更新時刻を選択してＵＲＬを作成し、また、ハイパ
ーリンクのリンク元の最終更新時刻とリンク先の最終更
新時刻の対応を参照関係時刻対応蓄積エリア1007に蓄積
する。なお、最終更新時刻は、ファイル内容が最後に更
新された時刻であり、消滅時刻は、ファイル内容が更新
されたとき、元のファイル内容はサーバからは消滅する
が、その消滅した時刻である。

【００２３】ハイパーメディア蓄積管理部1005の動作の
詳細の説明に先立って、応答蓄積エリア1006および参照
関係時刻対応蓄積エリア1007の蓄積形式を説明する。応
答蓄積エリア1006の蓄積形式を図２に示す。インデック
ス2001は、サーバからの応答2004（サーバからの応答さ
れたファイル内容を含む全ての応答内容）を蓄積すると
きにその識別のために使用する。応答2004のインデック
ス2001には、クライアントの指定したＵＲＬに最終更新
時刻を付加したものを使用する。これは、ファイルアド
レス2002と、ＵＲＬにパラメータとして付加されている
最終更新時刻2003から構成される。#2005は、蓄積した
応答の通し番号を表す。応答蓄積エリア1006には、ファ
イルアドレスが同じであるが最終更新時刻が異なる応答
も蓄積される。すなわち、応答蓄積エリア1006には、最
後に更新されたファイル内容だけでなく、更新前のいく
つかのファイル内容、換言すれば、複数バージョンのフ
ァイル内容を蓄積できる。しかし、サーバには最後に更
新された最も新しいファイル内容のみが蓄積される。

【００２４】参照関係時刻対応蓄積エリア1007の蓄積形
式を図３に示す。インデックス3001は、最終更新時刻30
07を蓄積するときに、その識別のために使用する。

【００２５】インデックス3001は、RefererのＵＲＬ300
2と要求のＵＲＬ3005を結合したものである。Refererの
ＵＲＬ3002（参照元）はファイルアドレス3003と、ＵＲ
Ｌにパラメータとして付加されている最終更新時刻3004
から構成される。要求のＵＲＬ3005は、ファイルアドレ
ス3006のみで構成される。最終更新時刻3007はファイル
アドレス3006のファイルに対する選択された最終更新時
刻である。#3008は、蓄積した最終更新時刻の通し番号
を表す。

【００２６】ハイパーメディア蓄積管理部1005の動作の
詳細を説明する。詳細な動作を表すフロー図を図４から
図１７に示す。

【００２７】図４のステップ4001において、通信仲介処
理部1004がクライアント1001からの要求を取得するのを
待つ。ステップ4002において、取得した要求の中のＵＲ
Ｌにパラメータとして最終更新時刻が付加されているか
どうかを調べ、判断ステップ4003で、ステップ4002の結
果にしたがって分岐する。ＵＲＬにパラメータとして最
終更新時刻が付加されている場合は、最終更新時刻付き
要求処理ステップ4004に進み、その後に処理を終了す
る。最終更新時刻付き要求処理ステップ4004の詳細は、
後で図５を使用して説明する。ステップ4002においてＵ
ＲＬに最終更新時刻が付加されてない場合は、判断ステ
ップ4003を経てステップ4005に進む。ステップ4005にお
いて、要求のヘッダーにRefererがあって、Refererの属
性値に示されたＵＲＬにパラメータとして最終更新時刻
が付加されているかどうかを調べる。付加されている場
合は、判断ステップ4006を経て参照元最終更新時刻付き
要求処理ステップ4007に進み、その後に処理を終了す
る。参照元最終更新時刻付き要求処理ステップ4007の詳
細は、後で図７を使用して説明する。ステップ4005で、
Refererの属性値のＵＲＬにパラメータとして最終更新
時刻が付加されていない場合は、判断ステップ4006を経
て最終更新時刻無し要求処理ステップ4008に進み、その
後に処理を終了する。最終更新時刻無し要求処理ステッ
プ4008の詳細は後で図１４を使用して説明する。

【００２８】次に、最終更新時刻付き要求処理4004の詳
細を図５により説明する。ステップ5001で、クライアン
トがＵＲＬを指定して行った要求におけるヘッダーにPr
agmaがあってその属性値がno-cacheであり、かつ、要求
情報アドレスのファイルアドレスが同じである要求に対
する前回のプロキシサーバの応答がリダイレクションア
ドレスを持つ応答でないかを調べる。すなわち、このク
ライアントの要求の前にプロキシサーバから送られた応
答が、上記クライアントの要求におけるＵＲＬと同じＵ
ＲＬを指定してなされた要求に対するリダイレクション
を指示するものではないかを調べる。この条件が成立す
る場合は、判断ステップ5002を経て、サーバへの要求通
知および応答取得処理ステップ5003に進み、要求をサー
バに通知し、その応答を取得し、蓄積する。サーバへの
要求通知および応答取得処理ステップ5003の詳細は、後
で図１６を使用して説明する。そして、次のステップ50
04で、クライアントにリダイレクションさせるために、
要求のＵＲＬのファイルアドレスに、取得した応答の最
終更新時刻をパラメータとして付加したＵＲＬをLocati
onの属性値のＵＲＬとする応答を作成してその応答を通
信仲介処理部1004を介してクライアント1001に返送し、
処理を終了する。

【００２９】ステップ5001における調査の条件が成立し
ない場合、すなわち、要求のヘッダーにPragmaの指定が
ないか、あっても属性値がno-cacheでない場合、およ
び、クライアントの要求の前にプロキシサーバから送ら
れた応答が、上記クライアントの要求におけるＵＲＬと
同じＵＲＬを指定してなされた要求に対するリダイレク
ションを指示するものである場合は、判断ステップ5002
を経てステップ5005に進む。ステップ5005で、要求の中
の最終更新時刻付きＵＲＬをインデックスとして応答蓄
積エリア1006に蓄積された応答を検索する。その検索が
成功した場合には判断ステップ5006を経てステップ5007
に進む。ステップ5007で、ステップ5005において検索し
た応答を、通信仲介処理部1004を通じてクライアント10
01に返送し、処理を終了する。

【００３０】ステップ5005における応答蓄積エリア1006
の検索が成功しない場合は判断ステップ5006を経て、図
６のサーバへの要求通知および応答取得処理ステップ60
01に進む。

【００３１】ステップ6001では、サーバ1008へ要求を通
知し、それに対する応答を取得する。サーバへの要求通
知および応答取得処理ステップ6001の詳細な説明は後で
図１６を使用して行う。ステップ6002で、サーバへの要
求通知および応答取得処理ステップ6001において取得し
た応答が、取得に失敗した旨の応答であるかどうかを調
べる。失敗した旨の応答である場合には、判断ステップ
6003を経て、ステップ6006で、その応答を通信仲介処理
部1004を通じてクライアント1001に返送し、処理を終了
する。ステップ6002における応答の調査の結果が、取得
失敗の応答でない場合は、判断ステップ6003を経て、ス
テップ6004に進む。ステップ6004で、要求の中のＵＲＬ
にあった最終更新時刻がサーバへの要求通知および応答
取得処理ステップ6001で取得した応答のヘッダーの中の
最終更新時刻と一致するかどうかを調べる。一致する場
合には、判断ステップ6005を経てステップ6006で、その
応答を通信仲介処理部1004を通じてクライアント1001に
返送し、処理を終了する。ステップ6004における最終更
新時刻の比較の結果が一致しない場合は、判断ステップ
6005を経て、ステップ6007で、要求された情報の取得に
失敗した旨を表す応答を作成して、その応答を通信仲介
処理部1004を通じてクライアント1001に返送し、処理を
終了する。

【００３２】次に、参照元最終更新時刻付き要求処理ス
テップ4007の詳細を図７により説明する。Refererの最
終更新時刻および消滅時刻の取得ステップ7001で、Refe
rerの最終更新時刻をTs(Ref)（RefはRefererを略記した
ものである）に設定し、Refererの消滅時刻をTe(Ref)に
設定する。Refererの最終更新時刻および消滅時刻の取
得ステップ7001の詳細は、後で図１０を使用して説明す
る。次の、ステップ7002で、クライアントの要求のヘッ
ダーにPragmaがあってその属性値がno-cacheであるかを
調べる。ステップ7002における調査の条件が成立しない
場合、すなわち、要求のヘッダーにPragmaの指定がない
か、あっても属性値がno-cacheでない場合は、判断ステ
ップ7003を経て、ステップ7004に進む。ステップ7004
で、要求のＵＲＬとRefererの最終更新時刻付きのＵＲ
Ｌを結合したものをインデックスにして、参照関係時刻
対応蓄積エリア1007に蓄積された最終更新時刻（図３の
3007）を検索する。この検索に成功した場合は、判断ス
テップ7005を経てステップ7006に進む。ステップ7006
で、ステップ7004において検索した最終更新時刻を要求
のＵＲＬにパラメータとして付加し、新たなＵＲＬを作
成して、この作成したＵＲＬをインデックスとして応答
蓄積エリア1006を検索する。検索に成功した場合は、判
断ステップ7007を経てステップ7008で、クライアント10
01にリダイレクションを行わせるために、ステップ7006
における検索のインデックスに使用したＵＲＬをヘッダ
ーのLocationの属性値とする応答を作成して、その応答
を通信仲介処理部1004を通じてクライアント1001に返送
し、処理を終了する。ステップ7004の検索に失敗した場
合は、判断ステップ7005を経て図８のステップ8001に進
み、ステップ7006における検索に失敗した場合は、判断
ステップ7007を経て図８のステップ8001に進む。また、
ステップ7002における調査で要求のヘッダーにPragmaの
指定があって、かつ、属性値がno-cacheである場合は、
判断ステップ7003を経て図９のステップ9001に進む。

【００３３】ステップ8001で、応答蓄積エリア1006に蓄
積された応答のインデックスで、要求のＵＲＬが示すフ
ァイルアドレスを含むインデックスを抽出し、この抽出
したインデックスの列挙をスタックにする。ステップ80
02で、インデックスの列挙のスタックが空かどうかを調
べる。空でない場合は判断ステップ8003を経て、ステッ
プ8004で、インデックスの列挙のスタックの頂上のイン
デックスを取り出し、そのインデックスで応答蓄積エリ
ア1006に蓄積された応答を検索して取得する。この検索
に失敗した場合は、判断ステップ8005を経てステップ80
02に戻る。成功した場合は、参照関係時刻対応の検査処
理ステップ8006で、Refererが示すファイルの存在時刻
と、要求のＵＲＬが示すファイルの存在時刻との整合性
の検査を行う。参照関係時刻対応の検査処理ステップ80
06の詳細は、後で図１１を使用して説明する。参照関係
時刻対応の検査処理ステップ8006における検査に合格し
ない場合は判断ステップ8007を経てステップ8002に戻
る。合格した場合は、参照関係時刻対応の記録処理ステ
ップ8008で、Refererが示すファイルアドレスと最終更
新時刻と、要求のＵＲＬが示すファイルと、要求のＵＲ
Ｌが示すファイルの最終更新時刻を参照関係時刻対応蓄
積エリア1007に記録する。参照関係時刻対応の記録処理
ステップ8008の詳細は、後で図１３を使用して説明す
る。次のステップ8009で、クライアント1001にリダイレ
クションさせるために、ステップ8004における応答蓄積
エリアの検索に使用したインデックスをLocationの属性
値のＵＲＬとする応答を作成して、クライアント1001に
返送し、処理を終了する。ステップ8002における調査に
おいてインデックスの列挙のスタックが空である場合
は、判断ステップ8003を経て、サーバへの要求通知およ
び応答取得処理ステップ9001に進む。

【００３４】ステップ9001ではサーバ1008へ要求を通知
し、それに対する応答を取得する。サーバへの要求通知
および応答取得処理ステップ9001の詳細は後で図１６を
使用して説明する。次のステップ9002で、サーバへの要
求通知および応答取得処理ステップ9001において取得し
た応答が、取得に失敗した旨の応答であるかを調べる。
失敗した旨の応答である場合は、判断ステップ9003を経
て、ステップ9004で、その取得した応答をクライアント
1001に返送して処理を終了する。ステップ9002における
調査において、取得した応答が取得に失敗した旨の応答
でない場合は、判断ステップ9003を経て参照関係時刻対
応の検査処理9005で、Refererが示すファイルの存在時
刻と要求のＵＲＬが示すファイルの存在時刻の整合性の
検査を行う。参照関係時刻対応の検査処理ステップ9005
の詳細は後で図１１を使用して説明する。参照関係時刻
対応の検査処理ステップ9005における検査に合格しない
場合は判断ステップ9006を経て、ステップ9007で、要求
された情報を返すことができない旨の応答を作成してク
ライアントに返送し、処理を終了する。参照関係時刻対
応の検査処理ステップ9005における検査に合格した場合
は、判断ステップ9006を経てステップ9008で、クライア
ント1001にリダイレクションさせるために、取得した応
答の最終更新時刻をパラメータとして要求のＵＲＬに付
加したＵＲＬをLocationの属性値とする応答を作成し
て、クライアント1001に返送し、処理を終了する。

【００３５】次に、Refererの最終更新時刻および消滅
時刻の取得ステップ7001の詳細を図１０で説明する。ス
テップ10001で、要求のヘッダにあるRefererのＵＲＬに
パラメタとして付加されいる最終更新時刻をTs(Ref)（R
efはRefererを略記したものである）とする。次のステ
ップ10002で、要求のRefererの最終更新時刻付きのＵＲ
Ｌをインデックスにして応答蓄積エリア1006に蓄積され
た応答を検索する。ステップ10002における検索に失敗
した場合は、判断ステップ10003を経て、ステップ10007
で、Te(Ref)の値を未定義（ファイルが未だ更新されて
いないことを示す）として、処理を終了する。ステップ
10002における検索に成功した場合は、ステップ10004
で、その応答のヘッダーに消滅時刻が有るかどうかを調
べる。消滅時刻がない場合は、判断ステップ10005を経
てステップ10007で、Te(Ref)の値を未定義として、処理
を終了する。ステップ10004における調査で消滅時刻が
あった場合は、判断ステップ10005を経てステップ10006
で、その消滅時刻をTe(Ref)の値として、処理を終了す
る。

【００３６】次に、図８における参照関係時刻対応の検
査処理ステップ8006および図９における参照関係時刻対
応の検査処理ステップ9005の詳細を図１１で説明する。
ステップ11001で、取得した応答のヘッダーに消滅時刻
が存在するかどうかを調べる。存在しない場合は、判断
ステップ11002を経てステップ11003で、Te(Req)（Reqは
Requestの略記）の値を未定義とする。ステップ11001に
おける調査でヘッダーに消滅時刻が存在する場合には、
判断ステップ11002を経てステップ11004で、その消滅時
刻をTe(Req)とする。次に、判断ステップ11005で、Ts(R
ef)の示す時刻がTe(Req)の示す時刻よりも過去か同時で
あるかどうかを判断し、そうでない場合はステップ1100
6で検査失敗として処理を終了する。判断ステップ11005
においてTs(Ref)の示す時刻がTe(Req)の示す時刻よりも
過去か同時である場合、および、ステップ11001におけ
る調査でヘッダーに消滅時刻が存在しないために判断ス
テップ11002を経てステップ11003に進んだ場合は、次
に、図１２のステップ12001で、取得した応答のヘッダ
ーにある最終更新時刻をTs(Req)とする。次のステップ1
2002で、Te(Ref)が未定義であるかどうかを調べる。未
定義である場合は、判断ステップ12003を経てステップ1
2005で検査合格として処理を終了する。ステップ12002
における調査でTe(Ref)が未定義でなかった場合は、次
の判定ステップ12004で、Ts(Req)の示す時刻がTe(Ref)
の示す時刻よりも過去か同時であるかどうかを判断し、
そうである場合は、ステップ12005で検査合格として処
理を終了する。判断ステップ12004においてTs(Req)の示
す時刻がTe(Ref)の示す時刻よりも過去か同時でない場
合は、ステップ12006で検査失敗として処理を終了す
る。

【００３７】次に、参照関係時刻対応の記録処理ステッ
プ8008の詳細を図１３で説明する。ステップ13001でTe
(Ref)が未定義でなく、かつ、Te(Req)が未定義でないか
どうかを調べる。条件が成立しない場合、すなわち、ど
ちらか一方または両方が未定義である場合は、判断ステ
ップ13002を経て処理を終了する。両方とも定義されて
いる場合は、判断ステップ13002を経て、ステップ13003
で、要求の、最終更新時刻のないファイルアドレスのみ
のＵＲＬと、Refererの、最終更新時刻付きのＵＲＬを
結合したものをインデックスにして、取得した応答の最
終更新時刻Ts(Req)を参照関係時刻対応蓄積エリア1007
に蓄積して処理を終了する。

【００３８】次に、最終更新時刻無し要求処理ステップ
4008の詳細を図１４で説明する。ステップ14001で、要
求のヘッダーにPragmaがあってその属性値がno-cacheで
あるかを調べる。ステップ14001における調査の条件が
成立しない場合、すなわち、要求のヘッダーにPragmaの
指定がないか、あっても属性値がno-cacheでない場合
は、判断ステップ14002を経て、ステップ14003で、応答
蓄積エリア1006に蓄積された応答のインデックスで、要
求の、最終更新時刻のないＵＲＬが示すファイルアドレ
スを含み、最終更新時刻が最新の時刻であるインデック
スを検索する。この検索に成功した場合は、判断ステッ
プ14004を経てステップ14005で、クライアント1001にリ
ダイレクションさせるために、検索したインデックスを
Locationの属性値とする応答を作成してクライアント10
01に返送し、処理を終了する。ステップ14003における
検索に失敗した場合は、サーバへの要求通知および応答
取得処理ステップ15001（図１５）に進む。また、ステ
ップ14001における調査で要求のヘッダーにPragmaの指
定があって、かつ、属性値がno-cacheである場合は、判
断ステップ14002を経てサーバへの要求通知および応答
取得処理ステップ15001に進む。

【００３９】サーバへの要求通知および応答取得処理ス
テップ15001で、サーバ1008へ要求を通知し、それに対
する応答を取得する。サーバへの要求通知および応答取
得処理ステップ15001の詳細は後で説明する。

【００４０】次のステップ15002で、取得した応答は、
取得に失敗した旨の応答であるかどうかを調べる。失敗
した旨の応答である場合は、判断ステップ15003を経
て、ステップ15004で、その取得した応答をクライアン
ト1001に返送して処理を終了する。ステップ15002にお
ける調査で、応答が取得に失敗した旨のものでない場合
は、判断ステップ15003を経て、ステップ15005で、クラ
イアント1001にリダイレクションさせるため、要求のＵ
ＲＬに取得した応答の最終更新時刻をパラメタとして付
加したＵＲＬをLocationの属性値とする応答を作成し
て、クライアントに返送し、処理を終了する。

【００４１】次に、図５におけるサーバへの要求通知お
よび応答取得処理ステップ5003、図６におけるサーバへ
の要求通知および応答取得処理ステップ6001、図９にお
けるサーバへの要求通知および応答取得処理ステップ90
01、図１５におけるサーバへの要求通知および応答取得
処理ステップ15001の詳細を図１６で説明する。ステッ
プ16001で、要求のＵＲＬに最終更新時刻がパラメータ
として付加されているならばそれを削除した要求を作成
する。ステップ16002で、要求をサーバ1008に通知して
サーバ1008からの応答を取得する。取得に成功しなかっ
た場合は、判断ステップ16003を経て、ステップ16004
で、取得に失敗した旨を表す応答を作成して処理を終了
する。ステップ16002における応答の取得に成功した場
合は、判断ステップ16003を経て、ステップ16005で、サ
ーバ1008に通知した要求の、最終更新時刻無しのＵＲＬ
に、サーバから取得した応答のヘッダーの中の最終更新
時刻をパラメータとして付加したＵＲＬをインデックス
として、応答を応答蓄積エリア1006に蓄積する。次に、
旧版消滅時刻の記録処理ステップ16006を経て処理を終
了する。

【００４２】旧版消滅時刻の記録処理ステップ16006の
詳細を図１７で説明する。ステップ17001で、応答蓄積
エリア1006に蓄積された応答のインデックスで、サーバ
1008に通知した要求の最終更新時刻のないＵＲＬにおけ
るファイルアドレスを含むインデックスのうち、最終更
新時刻が最新の時刻であるインデックスの応答を検索す
る。検索に失敗した場合は、判断ステップ17002を経て
処理を終了する。検索に成功した場合は、判断ステップ
17002を経て、ステップ17003で、サーバ1008から取得し
た応答のヘッダーの中の最終更新時刻を、応答蓄積エリ
ア1006から検索した応答のヘッダーに、消滅時刻として
追加し、処理を終了する。

【００４３】

【発明の効果】本発明により、既に市場に浸透した従来
の技術に基づくクライアントおよびサーバを入れ替える
ことなく使用しながらも次に述べる効果がある。複写に
よるリンク破壊問題に対しては、その問題を生じること
なく、保存済みのファイルであれば保存済みの内容を参
照し、保存していないファイルであればサーバに要求し
て取り出すことができという効果がある。また、リンク
のバージョン不整合問題に対しては、その問題を生じる
ことなく、保存したファイルの作成時刻、更新時刻を管
理してそれら時刻関係の矛盾のないファイルを参照する
ことができるという効果がある。また、ファイルの保存
の際にも元のＵＲＬとの関連を維持して最新のファイル
内容を取得するために別途、元のＵＲＬを控えておく必
要がなく、従来どおり「リロード」と呼ばれる操作を行
うだけで最新のファイルの内容を参照することができる
という効果がある。

【図面の簡単な説明】

【図１】図1は、本発明のハイパーメディアバージョン
蓄積管理方法を実現するプロキシサーバの構成と利用形
態を表す図である。

【図２】ハイパーメディアバージョン蓄積管理方法で使
用する応答蓄積エリアの蓄積形式を説明する図である。

【図３】ハイパーメディアバージョン蓄積管理方法で使
用する参照関係時刻対応蓄積エリアの蓄積形式を説明す
る図である。

【図４】ハイパーメディアバージョン蓄積管理方法を説
明するフロー図である。

【図５】最終更新時刻付き要求処理の詳細を説明するフ
ロー図である。

【図６】図５に続くフロー図である。

【図７】参照元最終更新時刻付き要求処理の詳細を説明
するフロー図である。

【図８】図７に続くフロー図である。

【図９】図８に続くフロー図である。

【図１０】Refererの最終更新時刻および消滅時刻の取
得処理の詳細を説明するフロー図である。

【図１１】参照関係時刻対応の検査処理の詳細を説明す
るフロー図である。

【図１２】図１１に続くフロー図である。

【図１３】参照関係時刻対応の記録処理の詳細を説明す
るフロー図である。

【図１４】最終更新時刻無し要求処理の詳細を説明する
フロー図である。

【図１５】図１４に続くフロー図である。

【図１６】サーバへの要求通知および応答取得処理の詳
細を説明するフロー図である。

【図１７】旧版消滅時刻の記録処理の詳細を説明するフ
ロー図である。

【符号の説明】

１００１ クライアント １００２ ネットワーク １００３ プロキシサーバ １００４ 通信仲介処理部 １００５ ハイパーメディア蓄積管理部 １００６ 応答蓄積エリア １００７ 参照関係時刻対応蓄積エリア １００８ サーバ

Claims (8)

【特許請求の範囲】
1. 【請求項１】 クライアントとサーバのネットワークを
   介した通信を仲介するプロキシサーバにおけるハイパー
   メディア蓄積管理方法であって、 プロキシサーバは、クライアントの要求に対するサーバ
   の応答を応答蓄積エリアに蓄積するとき、前記要求に含
   まれる要求情報アドレスとして指定されているファイル
   アドレスに前記応答の付加情報に含まれる最終更新時刻
   をパラメタとして結合したものを該蓄積する応答のイン
   デックスとして蓄積し、 クライアントからの要求の要求情報アドレスに時刻を指
   定するパラメタが付加されていない場合は、応答蓄積エ
   リアのインデックスから該要求情報アドレスを含むアド
   レスを検索し、検索成功のときは検索したインデックス
   内の時刻をパラメタとして付加した前記要求情報アドレ
   スをリダイレクションアドレスとする応答を作成してク
   ライアントに返送し、 検索不成功のときは前記要求情報アドレスを持つ要求を
   サーバに通知し、その応答を前記応答蓄積エリアに蓄積
   し、その応答の最終更新時刻に基づいた時刻をパラメタ
   として付加した前記要求情報アドレスをリダイレクショ
   ンアドレスとする応答を作成してクライアントに返送す
   ることを特徴とするハイパーメディア蓄積管理方法。
2. 【請求項２】 請求項１記載のハイパーメディア蓄積管
   理方法において、 前記要求情報アドレスに時刻を指定するパラメタが付加
   されている場合に、該要求情報アドレスと時刻からなる
   インデックスを持つ応答を前記応答蓄積エリアから検索
   し、検索に成功したときその応答をクライアントに返送
   し、 検索不成功のときは、前記要求情報アドレスから時刻を
   指定するパラメタを削除した要求をサーバに通知して応
   答をサーバから取得しその応答を前記応答蓄積エリアに
   蓄積し、該応答の最終更新時刻と要求の中の要求情報ア
   ドレスの時刻が一致するときは、その応答をクライアン
   トに返送し、一致しないときは、要求に答えられない旨
   の応答を作成してクライアントに返送することを特徴と
   するハイパーメディア蓄積管理方法。
3. 【請求項３】 請求項２記載のハイパーメディア蓄積管
   理方法において、 前記サーバから取得した応答のファイルアドレスで前記
   応答蓄積エリアを検索し、該応答のファイルアドレスと
   同一のファイルアドレスを含むインデックスのうちで最
   終更新時刻が最新であるインデックスの応答を求め、該
   求めた応答の消滅時刻として前記サーバから取得した応
   答の最終更新時刻を記録することを特徴とするハイパー
   メディア蓄積管理方法。
4. 【請求項４】 請求項１記載のハイパーメディア蓄積管
   理方法において、 クライアントからの要求の要求情報アドレスと該要求に
   付加された参照元アドレスと該参照元アドレスの付加情
   報に含まれる最終更新時刻を結合したインデックスと、
   前記要求の要求情報アドレスのファイルの最終更新時刻
   とを登録した参照関係時刻対応蓄積エリアを設け、 クライアントからの要求の要求情報アドレスに時刻を指
   定するパラメタが付加されていない場合のうち、要求の
   付加情報に参照元アドレスがあってその参照元アドレス
   に時刻を指定するパラメタが付加されているときは、 該要求の要求情報アドレスと参照元アドレスと時刻の結
   合をインデックスとして前記参照関係時刻対応蓄積エリ
   アを検索し、前記要求の要求情報アドレスのファイルの
   最終更新時刻が検索されたとき、前記クライアントから
   の要求の要求情報アドレスと該検索した最終更新時刻と
   の結合をインデックスとして前記応答蓄積エリアを検索
   し、検索に成功したとき、該インデックスとして使用し
   たクライアントからの要求の要求情報アドレスと検索し
   た最終更新時刻の組合せをリダイレクションアドレスと
   する応答を作成してクライアントに返送することを特徴
   とするハイパーメディア蓄積管理方法。
5. 【請求項５】 請求項４記載のハイパーメディア蓄積管
   理方法において、 前記検索に成功しないときは、参照元アドレスをインデ
   ックスにして応答蓄積エリアに蓄積された応答を検索し
   てその最終更新時刻と消滅時刻を得て、その最終更新時
   刻と消滅時刻が、参照関係にあるものとして矛盾しない
   最終更新時刻および消滅時刻を持つ応答で、かつ、要求
   情報アドレスのファイルアドレスをインデックスに含む
   応答を一つ応答蓄積エリアから検索し、インデックスと
   して使用したクライアントからの要求の要求情報アドレ
   スと検索した最終更新時刻の組合せをリダイレクション
   アドレスとする応答を作成してクライアントに返送する
   ことを特徴とするハイパーメディア蓄積管理方法。
6. 【請求項６】 請求項５記載のハイパーメディア蓄積管
   理方法において、 前記検索した応答の最終更新時刻を、要求情報アドレス
   のファイルアドレスと参照元アドレスと該参照元アドレ
   スに付された最終更新時刻を結合したものをインデック
   スにして参照関係時刻対応蓄積エリアに蓄積することを
   特徴とするハイパーメディア蓄積管理方法。
7. 【請求項７】 請求項１または請求項２または請求項４
   記載のハイパーメディア蓄積管理方法において、 クライアントの要求の付加情報に最新情報取得指示があ
   る場合に、 要求情報アドレスのファイルアドレスが同じである要求
   に対する前回のプロキシサーバの応答がリダイレクショ
   ンアドレスを持つ応答でないとき、または、そのような
   要求がこれまでにないとき、または、前記要求情報アド
   レスのファイルアドレスが同じである要求に対する前回
   のプロキシサーバの応答がリダイレクションアドレスを
   持つ応答であっても要求の要求情報アドレスに時刻を指
   定するパラメタが付加されていないときは、 前記要求情報アドレスから時刻を指定するパラメタを削
   除した要求をサーバに通知して、応答をサーバから取得
   してその応答を前記応答蓄積エリアに蓄積し、前記要求
   情報アドレスのファイルアドレスにその応答の最終更新
   時刻に基づいた時刻を指定するパラメタを付加したもの
   をリダイレクションアドレスとする応答を作成してクラ
   イアントに返送し、 前記要求情報アドレスのファイルアドレスが同じである
   要求に対する前回のプロキシサーバの応答がリダイレク
   ションアドレスを持つ応答であり、かつ、要求情報アド
   レスに時刻を指定するパラメタが付加されているもので
   あるときは、 要求情報アドレスに基づいて前記応答蓄積エリアを検索
   するためのインデックスを作成して、そのインデックス
   で該応答蓄積エリアに蓄積された応答を検索し、その応
   答をクライアントに返送することを特徴とするハイパー
   メディア蓄積管理方法。
8. 【請求項８】 請求項２記載のハイパーメディア蓄積管
   理方法において、前記要求情報アドレスに付加する時刻
   を指定するパラメタが応答の最終更新時刻であることを
   特徴とするハイパーメディア蓄積管理方法。