JP5567906B2 - 画面の再現を支援する装置及び方法 - Google Patents

Description

本発明は、画面の再現を支援する装置及び方法に関する。特に、本発明は、クライアントにサーバから送信されたデータに基づいて表示された画面の再現を支援する装置及び方法に関する。

クライアントサーバ方式のウェブアプリケーションシステムにおいて、端末にユーザが入力した情報とウェブシステムが端末に表示した画面とを、ネットワークモニタが取得するネットワークトレースから再現する技術がある。この技術では、アプリケーション開発が行われているシステムにおいて、ネットワークトレースを連続的にキャプチャし、実行されたテスト内容、実行結果の記録、エラーの際に表示された画面の確認等を行っている。

ここで、同様の画面再現に関する技術は、公報記載の技術としても知られている（例えば、特許文献１、２参照）。
特許文献１の技術では、サーバからクライアントに送信されたデータであってユーザによる操作を受け付ける第１画面をクライアントに表示させるためのデータである第１データと、クライアントからサーバに送信されたデータであってクライアントに表示された第１画面で受け付けられた操作を示すデータである第２データとを取得し、第１データ及び第２データに基づいて、第２データに基づく情報である操作情報を第１画面に付加してなる第２画面を表示させるための第３データを生成している。

特許文献２の技術では、ネットワーク上のパケットを傍受し、傍受したパケットから通信内容を再構築し、通信内容に対応付けて通信元アドレス、通信先アドレス及び日時を格納し、検索条件に応じて通信内容を検索し、検索した通信内容が入力値を含むかを判定し、通信元アドレス、通信先アドレス又は日時に基づいて入力画面を含む通信内容を取得し、入力値を入力画面に埋め込むことによって表示画面を作成し表示している。

特開２００７−２８０３５７号公報 特開２００８−１０８０４７号公報

ところで、ＨＴＴＰ（HyperText Transfer Protocol）では、データの転送量を削減するために、キャッシュの仕組みが定義されており、端末のブラウザや通信経路上のプロキシにキャッシュが実装されている。従って、ウェブアプリケーションシステムでは、画面の部品がブラウザやプロキシにキャッシュされることがあるため、画面再現に必要な部品が、画面再現のためのネットワークトレースに全て含まれているとは限らない。このため、ネットワークトレースから完全な画面が再現できないことがある。

一例を挙げる。ブラウザは、ＨＴＭＬ（HyperText Markup Language）ファイルに埋め込むファイルをリクエストする際、該当のファイルを既にキャッシュに持っていれば、リクエストにLast-Modifiedの日時を付加してサーバに送る。すると、サーバは、その日時を確認し、キャッシュしてあるファイルが有効かどうかを判断する。
即ち、Last-Modifiedの日時がサーバ側のファイルの情報と一致すれば、サーバは、ファイルの本体は送付せずに、キャッシュにあるファイルが有効であることを示すステータスコード「３０４（Not Modified）」を送る。そして、ブラウザは、キャッシュしてあるファイルを、画面を描画するためにＨＴＭＬファイルに埋め込むファイルとして使用する。この場合、レスポンスは、ステータスコードは含むものの、リクエストしたファイルは含まないので、ファイルはネットワークトレースに残らない。従って、埋め込まれたファイルをネットワークトレースから抽出できないため、画面の再現が不十分になる。

かかる問題に対して、特許文献１、２の技術は、何ら解決手段を提供するものでない。
特許文献１は、画面再現のためのネットワークトレースに含まれる画面部品の処理しか開示しておらず、画面部品がネットワークトレースに含まれてない場合の問題は扱っていない。
特許文献２では、キャッシュされた画面の問題にも触れている。しかしながら、データ入力を伴う画面のみを対象に同じＵＲＬへのアクセスを遡って検索し、その画面が同じ入力を求めているかどうかによって同一性を確認する、という手法を採用している。この確認方法から、特許文献２では、Fromタグを含むＨＴＭＬファイルがキャッシュされている場合のみを処理を対象としていることが分かる。従って、入力画面の本体（ＨＴＭＬファイル）だけでなく、ＨＴＭＬファイルに埋め込まれる画像ファイル、スタイルシート等もキャッシュされ得るウェブシステムにおいて、特許文献２は、上記問題に対する解決手段を提供しない。また、特許文献２では、過去のネットワークトレースを遡って検索するため、画面再現の際の応答時間が長くなるという問題もある。

本発明の目的は、クライアントにサーバから送信されたデータに基づいて表示された画面を完全に再現できる可能性を、実用性の低下を抑えつつ高めることにある。

かかる目的のもと、本発明は、クライアントにサーバから送信されたデータに基づいて表示された画面の再現を支援する装置であって、クライアントに画面が表示された複数の時点で画面を表示するためにサーバから送信されたデータのうち、画面を表示するために用いられるファイルを伴うデータから、ファイルを抽出する抽出部と、抽出部により抽出されたファイルを記憶する記憶部と、複数の時点のうちの特定の時点でクライアントに表示された画面の再現の要求を受け付ける受付部と、特定の時点で画面を表示するためにサーバから送信されたデータがファイルを含まない場合に、記憶部に記憶されたファイルを、受付部にて受け付けた画面の再現の要求に応じて出力する出力部とを含む、装置を提供する。

ここで、出力部は、特定の時点で画面を表示するためにサーバから送信されたデータが、キャッシュされているファイルが有効であることを示すデータである場合に、記憶部に記憶されたファイルを、受付部にて受け付けた画面の再現の要求に応じて出力する、ものであってよい。
加えて、出力部は、記憶部に記憶されたファイルに設定されたファイルの有効性に関する情報に基づいて、ファイルの有効性が特定の時点で失われていないと判断できる場合に、ファイルを、受付部にて受け付けた画面の再現の要求に応じて出力する、ものであってよい。

また、この装置において、ファイルは、画面の部品を表示するために用いられ、受付部は、特定の時点でクライアントに表示された部品の再現の要求を受け付け、出力部は、特定の時点で部品の表示を要求するデータがサーバへ送信されていない場合に、記憶部に記憶されたファイルを、受付部にて受け付けた部品の再現の要求に応じて出力する、ものであってよい。
加えて、出力部は、記憶部に記憶されたファイルに設定されたファイルの有効性に関する情報に基づいて、ファイルの有効性が、画面の部品以外の部分の表示を要求するデータがサーバへ送信された時点で失われていないと判断できる場合に、ファイルを、受付部にて受け付けた部品の再現の要求に応じて出力する、ものであってよい。

更に、抽出部は、ファイルのタイプが予め定められたタイプである場合に、ファイルを伴うデータから、ファイルを抽出する、ものであってよい。
更にまた、抽出部は、ファイルを伴うデータが、ファイルがキャッシュされ得ることを示す情報として予め定められた情報を含む場合に、データからファイルを抽出する、ものであってよい。

また、本発明は、クライアントにサーバから送信されたデータに基づいて表示された画面の再現を支援する装置であって、クライアントに画面が表示された複数の時点で画面を表示するためにサーバから送信されたデータであって、画面を表示するために用いられるファイルを伴うデータを含むネットワーク上のトレースデータを蓄積する蓄積部と、蓄積部にトレースデータが蓄積される際に、ファイル及びファイルを伴うデータの少なくとも何れか一方が、ファイルがキャッシュされ得ると判断するための条件として予め定められた条件を満たしていれば、トレースデータに含まれるファイルを伴うデータから、ファイルを抽出する抽出部と、抽出部により抽出されたファイルを記憶する記憶部と、複数の時点のうちの特定の時点でクライアントに表示された画面の再現の要求を受け付ける受付部と、蓄積部に蓄積されたトレースデータに含まれるデータのうち、特定の時点で画面を表示するためにサーバから送信されたデータが、ファイルを含まず、キャッシュされているファイルが有効であることを示す場合に、記憶部に記憶されたファイルに設定されたファイルの有効性に関する情報に基づいて、ファイルの有効性が特定の時点で失われていないと判断できれば、ファイルを、受付部にて受け付けた画面の再現の要求に応じて出力する出力部とを含む、装置も提供する。

また、本発明は、クライアントにサーバから送信されたデータに基づいて表示された画面の再現を支援する装置であって、クライアントに画面が表示された複数の時点で画面を表示するためにサーバから送信されたデータであって、画面を表示するために用いられるファイルを伴うデータを含むネットワーク上のトレースデータを蓄積する蓄積部と、蓄積部に蓄積されたトレースデータから読み出されたファイル及びファイルを伴うデータの少なくとも何れか一方が、ファイルがキャッシュされ得ると判断するための条件として予め定められた条件を満たしていれば、トレースデータに含まれるファイルを伴うデータから、ファイルを抽出する抽出部と、抽出部により抽出されたファイルを記憶する記憶部と、複数の時点のうちの特定の時点でクライアントに表示された画面の再現の要求を受け付ける受付部と、蓄積部に蓄積されたトレースデータに含まれるデータのうち、特定の時点で画面を表示するためにサーバから送信されたデータが、ファイルを含まず、キャッシュされているファイルが有効であることを示す場合に、記憶部に記憶されたファイルに設定されたファイルの有効性に関する情報に基づいて、ファイルの有効性が特定の時点で失われていないと判断できれば、ファイルを、受付部にて受け付けた画面の再現の要求に応じて出力する出力部とを含む、装置も提供する。

更に、本発明は、クライアントにサーバから送信されたデータに基づいて表示された画面の再現を支援する方法であって、クライアントに画面が表示された複数の時点で画面を表示するためにサーバから送信されたデータのうち、画面を表示するために用いられるファイルを伴うデータから、ファイルを抽出するステップと、抽出されたファイルを記憶部に記憶するステップと、複数の時点のうちの特定の時点でクライアントに表示された画面の再現の要求を受け付けるステップと、特定の時点で画面を表示するためにサーバから送信されたデータがファイルを含まない場合に、記憶部に記憶されたファイルを、受け付けた画面の再現の要求に応じて出力するステップとを含む、方法も提供する。

更にまた、本発明は、クライアントにサーバから送信されたデータに基づいて表示された画面の再現を支援する装置としてコンピュータを機能させるプログラムであって、コンピュータを、クライアントに画面が表示された複数の時点で画面を表示するためにサーバから送信されたデータのうち、画面を表示するために用いられるファイルを伴うデータから、ファイルを抽出する抽出部と、抽出部により抽出されたファイルを記憶する記憶部と、複数の時点のうちの特定の時点でクライアントに表示された画面の再現の要求を受け付ける受付部と、特定の時点で画面を表示するためにサーバから送信されたデータがファイルを含まない場合に、記憶部に記憶されたファイルを、受付部にて受け付けた画面の再現の要求に応じて出力する出力部として機能させる、プログラムも提供する。

本発明によれば、クライアントにサーバから送信されたデータに基づいて表示された画面を完全に再現できる可能性を、実用性の低下を抑えつつ高めることができる。

本発明の第１の実施の形態が適用されるコンピュータシステムの構成例を示したブロック図である。 本発明の第１の実施の形態における画面再現装置のキャッシャブルファイル記憶時の動作例を示したフローチャートである。 本発明の第１、第２の実施の形態における画面再現装置の画面再現時の動作例を示したフローチャートである。 本発明の第１、第２の実施の形態における画面再現装置の画面再現時の動作例を示したフローチャートである。 本発明の第２の実施の形態が適用されるコンピュータシステムの構成例を示したブロック図である。 本発明の第２の実施の形態における画面再現装置のキャッシャブルファイル記憶時の動作例を示したフローチャートである。 キャッシャブルファイル判定処理（簡易版ロジック）の動作例を示したフローチャートである。 キャッシャブルファイル選択処理（簡易版ロジック）の動作例を示したフローチャートである。 キャッシャブルファイル判定処理（厳密版ロジック）の動作例を示したフローチャートである。 キャッシャブルファイル判定処理（厳密版ロジック）の結果としてキャッシャブルファイルと共に記憶される付加情報の一例を示した図である。 キャッシャブルファイル判定処理（厳密版ロジック）の結果として記憶された付加情報との比較の対象であるトレースの一例を示した図である。 キャッシャブルファイル選択処理（厳密版ロジック）の動作例を示したフローチャートである。 キャッシャブルファイル選択処理（厳密版ロジック）の動作例を示したフローチャートである。 本発明の実施の形態を適用可能なコンピュータのハードウェア構成を示した図である。

まず、本発明の実施の形態の概要を説明する。
ＨＴＴＰでは、キャッシュの仕組みとして、検証モデルと期限モデルとが定義されている。検証モデルの場合、クライアントはキャッシュされているファイルが有効かサーバに問い合わせ、サーバは、ファイルが有効であれば、有効であることを示すレスポンスを返すだけで、レスポンス対象のファイル（以下、「レスポンスファイル」という）を送らない。また、期限モデルでは、キャッシュされているファイルに有効期限が設定されているので、クライアントは、サーバに問い合わせることなく、ファイルが有効かを判断する。従って、この何れのモデルにおいても、キャッシュされたファイルが有効な場合は、ネットワークトレース（以下、単に「トレース」という）にレスポンスファイルが含まれないこととなる。問題は、レスポンスファイルなしでは、画面イメージをトレースから完全には再現できない、ということである。

ここで、ブラウザやプロキシにキャッシュされているレスポンスファイルも、元をただせば同じサーバから送出されたファイルである。トレースを連続的に取得している限り、トレースを遡って検索すればレスポンスファイルは見つかるはずである。
しかしながら、長時間に亘って取得したトレースをすべて保管し、必要に応じてその中を検索するという方法は、保管容量が膨らむこと、検索時間が長くなり画面再現のレスポンス時間が長くなること等のデメリットがあるので、よい解決法とは言えない。

そこで、本実施の形態では、次のように問題を解決した。
即ち、トレースからキャッシャブルファイルを抽出し、保管しておく。その後、あるユーザがある時間に表示した画面を再現する際に、画面再現に必要なキャッシャブルファイルがその時間のトレースに含まれていなければ、保管しておいたキャッシャブルファイルから適切なものを取り出し、それを利用する。ここで、キャッシャブルファイルとは、予め定めた基準によって、キャッシュされるであろうと判断されるレスポンスファイルのことである。例えば、キャッシュされるファイルをサーバが送出する際、そのファイルを送出するためのＨＴＴＰパケットのヘッダには、そのファイルがキャッシュされてもよいことを示す情報が含まれるので、このような情報が含まれることを上記基準として採用すればよい。また、キャッシャブルファイルを保管する際には、ＨＴＴＰパケットのヘッダ内の関連する情報もあわせて保管し、キャッシャブルファイルを適切に選択するために利用する。

以下、添付図面を参照して、本発明の実施の形態について詳細に説明する。
［第１の実施の形態］
図１は、第１の実施の形態が適用されるコンピュータシステムの構成を示したブロック図である。
図示するように、コンピュータシステムは、ウェブシステム１０と、クライアント２０と、クライアント３０と、画面再現装置４０とが、インターネット等のネットワーク８０に接続されることにより構成されている。特に、クライアント２０は、代理サーバであるプロキシ７０を経由してネットワーク８０に接続されているものとする。

ウェブシステム１０は、クライアントにインストールされたブラウザからの要求に応じてサービスを提供するサーバ上のシステムであり、本実施の形態ではモニタ対象となるシステムである。
クライアント２０，３０は、ユーザが使用する端末装置である。このうち、クライアント２０は、一般ユーザがウェブシステム１０を利用する際に使用する端末装置である。図では、１つのクライアント２０しか示していないが、複数のクライアント２０が接続されていてもよく、その場合、クライアント２０というときはそのうちの１つを指すものとする。また、本明細書において、単に「ユーザ」というときは、クライアント２０を使用する一般ユーザのことを指すものとする。一方、クライアント３０は、クライアント２０に表示された画面を再現するために特定ユーザが使用する端末装置である。

画面再現装置４０は、あるユーザがある時間にクライアント２０に表示した画面をクライアント３０で再現するための処理を行う装置である。この第１の実施の形態では、トレースをキャプチャしながらトレースからキャッシャブルファイルを抽出して保管し、あるユーザがある時間に表示した画面の部品がトレースに存在しない場合に、保管したキャッシャブルファイルを利用して画面を再現する。尚、以下では、クライアント３０からの画面の再現の要求に応じて、画面を再現しクライアント３０に出力するものとして説明するが、自身のユーザインターフェイスからの画面の再現の要求に応じて、画面を再現し自身が表示するようにしてもよい。

ここで、画面再現装置４０の機能構成について詳細に説明する。
図示するように、画面再現装置４０は、キャプチャ部４１と、キャッシャブルファイル判定部４２と、トレース分類部４３と、トレース記憶部４４と、レスポンスファイル抽出部４６と、レスポンスファイル送出部４７と、キャッシャブルファイル管理部４８と、キャッシャブルファイル記憶部４９とを備える。このうち、キャプチャ部４１、キャッシャブルファイル判定部４２、トレース分類部４３、レスポンスファイル抽出部４６、レスポンスファイル送出部４７、キャッシャブルファイル管理部４８は、ＣＰＵ９０ａ（図１４参照）がプログラムを磁気ディスク装置９０ｇ（図１４参照）からメインメモリ９０ｃ（図１４参照）に読み込んで実行することにより、実現される。また、トレース記憶部４４、キャッシャブルファイル記憶部４９は、例えば磁気ディスク装置９０ｇ（図１４参照）によって実現される。

キャプチャ部４１は、ネットワーク８０上のトラフィックのトレースを取得する。尚、トレースは、図中斜線で示したミラーポート又はＴＡＰ接続により取得する。
キャッシャブルファイル判定部４２は、キャプチャ部４１が取得したトレース内のＨＴＴＰレスポンスパケット（以下、「レスポンスパケット」という）を解析し、このレスポンスパケットに含まれるレスポンスファイルがキャッシャブルかどうかを判定する。そして、キャッシャブルと判定すれば、レスポンスパケットからレスポンスヘッダとレスポンスファイルとを抽出してキャッシャブルファイル管理部４８に送る。尚、本明細書では、レスポンスパケットのメッセージヘッダを「レスポンスヘッダ」と称し、これには、ＨＴＴＰで定義された一般ヘッダやエンティティヘッダも含まれる。本実施の形態では、ファイルの一例として、レスポンスファイルを用いており、ファイルを抽出する抽出部の一例として、キャッシャブルファイル判定部４２を設けている。

トレース分類部４３は、キャプチャ部４１が取得したネットワーク８０上のトレースをクライアント２０ごとに分類し、複数のトレースファイルを作成する。ここで、トレースファイルの作成は、キャプチャ部４１によるトレースのキャプチャ中に連続的に行ってもよいし、再現対象の画面が表示されたクライアント２０を選択してプル形式で行ってもよい。
トレース記憶部４４は、トレース分類部４３が作成した複数のトレースファイルを記憶する。本実施の形態では、トレースデータを蓄積する蓄積部の一例として、トレース記憶部４４を設けている。

レスポンスファイル抽出部４６は、トレース記憶部４４に記憶されたトレースファイルからＨＴＴＰリクエストパケット（以下、「リクエストパケット」という）とレスポンスパケットとを抽出し保持しておく。そして、レスポンスパケットから、クライアント２０のブラウザに送られたレスポンスファイルを抽出する。また、クライアント２０でユーザが表示した画面を例えばリクエストパケットにより特定してユーザに提示する処理も行う。

レスポンスファイル送出部４７は、クライアント３０から要求されたレスポンスファイルがレスポンスファイル抽出部４６によって抽出されている場合には、その抽出されたレスポンスファイルをクライアント３０に送出する。また、クライアント３０から要求されたレスポンスファイルがレスポンスファイル抽出部４６によって抽出されておらず、レスポンスファイル抽出部４６が保持するレスポンスパケット内のステータスコードが「３０４（Not Modified）」である場合には、キャッシャブルファイル管理部４８を通して、キャッシャブルファイル記憶部４９から適切なキャッシャブルファイルを選択し、これをレスポンスファイルとしてクライアント３０に送出する。その際、レスポンスファイル送出部４７は、レスポンスファイルにおいてウェブシステム１０内のＵＲＬ（Uniform Resource Locator）を参照している部分を、画面再現装置４０を参照するように書き換える書き換え処理も行う。尚、クライアント３０のブラウザでファイルが不用意にキャッシュされることを防止するため、レスポンスファイル送出部４７が送出するレスポンスパケットにおいて、レスポンスヘッダには、念のため「Cache-Control:no-cache」を含めておくとよい。本実施の形態では、画面の再現の要求を受け付ける受付部の一例として、レスポンスファイル送出部４７を設けている。

キャッシャブルファイル管理部４８は、キャッシャブルファイル判定部４２から受け取ったレスポンスファイルの本体を、同じくキャッシャブルファイル判定部４２から受け取ったレスポンスヘッダ内の付加情報と共にキャッシャブルファイル記憶部４９に記憶する。また、レスポンスファイル送出部４７からの要求に応じて、レスポンスファイルとして送出すべきキャッシャブルファイルをキャッシャブルファイル記憶部４９から選択する。本実施の形態では、ファイルを出力する出力部の一例として、キャッシャブルファイル管理部４８を設けている。
キャッシャブルファイル記憶部４９は、キャッシャブルファイルを付加情報と共に記憶する。本実施の形態では、ファイルを記憶する記憶部の一例として、キャッシャブルファイル記憶部４９を設けている。

次に、第１の実施の形態における画面再現装置４０の動作について詳細に説明する。
図２は、画面再現装置４０がキャッシャブルファイルを保存するときの動作例を示したフローチャートである。尚、一般ユーザがクライアント２０のブラウザからネットワーク８０を介してウェブシステム１０に接続し、ウェブシステム１０を使用している状態で、このフローチャートの動作は開始するものとする。

画面再現装置４０では、図２に示すように、まず、キャプチャ部４１が、ネットワーク８０上のトラフィックのトレースを取得する（ステップ４０１）。この場合、トレースは、ネットワーク８０上のスイッチのミラーポートを使用したり、ネットワーク８０にＴＡＰを挿入したりすることによって、取得すればよい。

次に、キャッシャブルファイル判定部４２は、トレース内のレスポンスパケットを解析し、レスポンスパケットに含まれるレスポンスファイルがキャッシャブルかどうかを判定するキャッシャブルファイル判定処理を行う（ステップ４０２）。尚、このキャッシャブルファイル判定処理では、レスポンスファイルがキャッシュされ得ると判断するための条件として予め定められた条件を満たしているかどうかを判定するが、その詳細については後述する。

そして、キャッシャブルファイル判定部４２は、キャッシャブルファイル判定処理の結果がキャッシャブルであることを示しているかどうかを判定する（ステップ４０３）。
その結果、キャッシャブルファイル判定処理の結果がキャッシャブルであることを示していない場合、キャッシャブルファイル判定部４２は、そのまま制御をトレース分類部４３に渡す。この場合、トレースには複数のクライアント２０のトラフィックが混ざっているので、トレース分類部４３は、クライアント２０ごとに分類したトレースファイルを作成する（ステップ４０４）。そして、クライアント２０ごとに分類したトレースファイルをトレース記憶部４４に保存する（ステップ４０５）。

一方、キャッシャブルファイル判定処理の結果がキャッシャブルであることを示している場合、キャッシャブルファイル判定部４２は、トレース内のレスポンスパケットからレスポンスファイルとレスポンスヘッダとを抽出し、キャッシャブルファイル管理部４８を通して、レスポンスファイル本体とレスポンスヘッダ内の付加情報とをキャッシャブルファイル記憶部４９に記憶する（ステップ４０６）。具体的には、キャッシャブルファイル判定部４２が、抽出したレスポンスファイルとレスポンスヘッダとをキャッシャブルファイル管理部４８に送る。そして、キャッシャブルファイル管理部４８が、レスポンスヘッダから必要な付加情報を取り出し、キャッシャブルファイル本体と付加情報とをキャッシャブルファイル記憶部４９に記憶する。或いは、キャッシャブルファイル判定部４２が、トレース内のレスポンスパケットから、レスポンスファイルと、レスポンスヘッダ内の必要な付加情報とを抽出し、これらをキャッシャブルファイル管理部４８に送り、キャッシャブルファイル管理部４８が、これらの情報をキャッシャブルファイル記憶部４９に記憶するようにしてもよい。

その後、キャッシャブルファイル判定部４２は、制御をトレース分類部４３に渡す。この場合、トレースには複数のクライアント２０のトラフィックが混ざっているので、トレース分類部４３は、クライアント２０ごとに分類したトレースファイルを作成する（ステップ４０４）。そして、クライアント２０ごとに分類したトレースファイルをトレース記憶部４４に保存する（ステップ４０５）。

図３，４は、画面再現装置４０が画面を再生するときの動作例を示したフローチャートである。尚、クライアント２０で表示された画面を再現したい特定ユーザが、クライアント３０のブラウザから画面再現装置４０にアクセスすることにより、このフローチャートの動作は開始するものとする。

画面再現装置４０では、図３に示すように、まず、レスポンスファイル抽出部４６が、画面再現に用いるトレースファイルをトレース記憶部４４から選択する（ステップ４１１）。具体的には、あるユーザがある時間に表示した画面を再現したい旨の情報をクライアント３０から受け付け、そのユーザがその時間に使用していたクライアント２０のトレースファイルのその時間の部分をトレース記憶部４４から読み出す。本実施の形態では、ユーザのウェブシステム１０に対するログインからログアウトまでを単位としてトレースを管理しているので、あるクライアント２０のトレースファイルのある時間の部分には、１人のユーザの操作に関するトレースのみが含まれることになる。

次に、レスポンスファイル抽出部４６は、選択したトレースファイルから、クライアント２０のブラウザに送信されたレスポンスファイルを抽出する（ステップ４１２）。この場合、例えば、トレースファイルからリクエストパケットとレスポンスパケットとを抽出して保持しておき、このうちレスポンスパケットからレスポンスファイルを抽出すればよい。尚、ここでいうレスポンスファイルには、画面に対応するＨＴＭＬファイルと、このＨＴＭＬファイルにエンベッドされるエンベッドファイルとが含まれる。

ところで、上述したように、トレースファイルには、クライアント２０におけるユーザの一連の操作による複数の画面が含まれている。そこで、レスポンスファイル抽出部４６は、これら複数の画面のうちのどの画面を再現するのかを選択させる画面選択用画面を生成し、この画面選択用画面をクライアント３０のブラウザに送出する（ステップ４１３）。
これにより、クライアント３０のブラウザには、画面選択用画面が表示される。ここで、画面選択用画面には、例えば、ユーザが一連の操作によって表示した画面に対応するＨＴＭＬファイルのリストが含まれている。従って、画面を再現したい特定ユーザは、そのリストに含まれるＨＴＭＬファイルの中から、再現したい画面に対応するＨＴＭＬファイルを選択することになる。

すると、クライアント３０のブラウザは、選択されたＨＴＭＬファイルのリクエストを画面再現装置４０に送信する。
これにより、画面再現装置４０では、レスポンスファイル送出部４７が、ＨＴＭＬファイルのリクエストを受信する（ステップ４１４）。

そして、レスポンスファイル送出部４７は、レスポンスファイル抽出部４６が抽出したレスポンスファイルの中から、このリクエストの対象であるＨＴＭＬファイルを検索し（ステップ４１５）、検索が成功したかどうかを判定する（ステップ４１６）。
その結果、検索が成功した場合、即ち、レスポンスファイル抽出部４６が抽出したレスポンスファイルの中に目的のＨＴＭＬファイルがあった場合、レスポンスファイル送出部４７は、そのＨＴＭＬファイルを選択する（ステップ４１７）。そして、ＨＴＭＬファイルの書き換え処理を行う（ステップ４１８）。ここで、書き換え処理とは、ＨＴＭＬファイル内でＵＲＬを参照している部分を検索し、参照先がウェブシステム１０であれば、画面再現装置４０を参照するように書き換える処理である。その後、レスポンスファイル送出部４７は、書き換え処理後のＨＴＭＬファイルをクライアント３０に送出する（ステップ４１９）。

一方、検索が成功しなかった場合、即ち、レスポンスファイル抽出部４６が抽出したレスポンスファイルの中に目的のＨＴＭＬファイルがなかった場合、レスポンスファイル送出部４７は、レスポンスファイル抽出部４６が保持しているリクエストパケットのうち目的のＨＴＭＬファイルを要求するリクエストパケットに対応するレスポンスパケットが、ステータスコード「３０４（Not Modified）」を含むかどうかを判定する（ステップ４２１）。

ここで、ステータスコード「３０４（Not Modified）」を含むと判定した場合、レスポンスファイル送出部４７は、制御をキャッシャブルファイル管理部４８に渡す。そして、キャッシャブルファイル管理部４８が、キャッシャブルファイル記憶部４９に記憶されたキャッシャブルファイルの中から適切なキャッシャブルファイルを選択するキャッシャブルファイル選択処理を行う（ステップ４２２）。尚、このキャッシャブルファイル選択処理では、キャッシャブルファイルが画面の再現に用いるのに適切であると判断するための条件として予め定められた条件を満たしているかどうかを判定するが、その詳細については後述する。

そして、レスポンスファイル送出部４７は、キャッシャブルファイル管理部４８から適切なキャッシャブルファイルがあった旨の情報が返されたかどうかを判定する（ステップ４２３）。
ここで、適切なキャッシャブルファイルがあった旨の情報が返されたと判定した場合、レスポンスファイル送出部４７は、キャッシャブルファイル管理部４８が適切と判定したキャッシャブルファイルであるＨＴＭＬファイルを選択する（ステップ４２４）。そして、ＨＴＭＬファイルの書き換え処理を行う（ステップ４１８）。ここで、書き換え処理とは、ＨＴＭＬファイル内でＵＲＬを参照している部分を検索し、参照先がウェブシステム１０であれば、画面再現装置４０を参照するように書き換える処理である。その後、レスポンスファイル送出部４７は、書き換え処理後のＨＴＭＬファイルをクライアント３０に送出する（ステップ４１９）。

このようにして送られてきたＨＴＭＬファイルはクライアント３０のブラウザに表示される。すると、クライアント３０のブラウザは、そのＨＴＭＬファイル内に埋め込まれたＵＲＬ参照に基づいて、エンベッドファイルのリクエストを画面再現装置４０に送信する。
これにより、画面再現装置４０では、図４に示すように、レスポンスファイル送出部４７が、エンベッドファイルのリクエストを受信する（ステップ４３４）。

そして、レスポンスファイル送出部４７は、レスポンスファイル抽出部４６が抽出したレスポンスファイルの中から、このリクエストの対象であるエンベッドファイルを検索し（ステップ４３５）、検索が成功したかどうかを判定する（ステップ４３６）。
その結果、検索が成功した場合、即ち、レスポンスファイル抽出部４６が抽出したレスポンスファイルの中に目的のエンベッドファイルがあった場合、レスポンスファイル送出部４７は、そのエンベッドファイルを選択する（ステップ４３７）。そして、エンベッドファイルをクライアント３０に送出する（ステップ４３９）。

一方、検索が成功しなかった場合、即ち、レスポンスファイル抽出部４６が抽出したレスポンスファイルの中に目的のエンベッドファイルがなかった場合、レスポンスファイル送出部４７は、レスポンスファイル抽出部４６が保持しているリクエストパケットの中に、目的のエンベッドファイルを要求するリクエストパケットがあるかどうかを判定する（ステップ４４０）。期限モデルの場合、リクエストパケット自体がトレースに存在しないことがあるので、このような判断を行っている。そして、目的のエンベッドファイルを要求するリクエストパケットがないと判定すれば、そのままステップ４４２へ進む。また、目的のエンベッドファイルを要求するリクエストパケットがあると判定すれば、そのリクエストパケットに対応するレスポンスパケットが、ステータスコード「３０４（Not Modified）」を含むかどうかを判定する（ステップ４４１）。

ここで、ステータスコード「３０４（Not Modified）」を含むと判定した場合、又は、ステップ４４０でリクエストパケットがないと判定した場合、レスポンスファイル送出部４７は、制御をキャッシャブルファイル管理部４８に渡す。そして、キャッシャブルファイル管理部４８が、キャッシャブルファイル記憶部４９に記憶されたキャッシャブルファイルの中から適切なキャッシャブルファイルを選択するキャッシャブルファイル選択処理を行う（ステップ４４２）。尚、このキャッシャブルファイル選択処理では、キャッシャブルファイルが画面の再現に用いるのに適切であると判断するための条件として予め定められた条件を満たしているかどうかを判定するが、その詳細については後述する。

そして、レスポンスファイル送出部４７は、キャッシャブルファイル管理部４８から適切なキャッシャブルファイルがあった旨の情報が返されたかどうかを判定する（ステップ４４３）。
ここで、適切なキャッシャブルファイルがあった旨の情報が返されたと判定した場合、レスポンスファイル送出部４７は、キャッシャブルファイル管理部４８が適切と判定したキャッシャブルファイルであるエンベッドファイルを選択する（ステップ４４４）。そして、エンベッドファイルをクライアント３０に送出する（ステップ４３９）。
これにより、エンベッドファイルがクライアント３０のブラウザで受信される。そして、ブラウザの機能によりエンベッドファイルがＨＴＭＬファイルに埋め込まれると、クライアント２０に表示されたのと同じ画面が表示され、一画面分の画面再現が完了する。

尚、ステップ４２１又はステップ４４１でステータスコード「３０４（Not Modified）」を含まないと判定された場合としては、例えば、ウェブシステム１０でエラーが発生したこと等により、「２００（OK）」でも「３０４（Not Modified）」でもないステータスコードがトレースに記録されたような場合が考えられる。このような場合、レスポンスファイル送出部４７は、トレースに記録されたのと同じステータスコードをセットしたレスポンスパケット（ＨＴＭＬファイルなし）を、クライアント３０のブラウザに送出し（ステップ４４５）、処理を終了する。
ＨＴＭＬファイルなしの異常ステータスコードがどのように表示されるかはブラウザによるが、クライアント２０のブラウザでユーザが見た画面と同じ意味を持つ画面がクライアント３０に表示されることになる。

或いは、ステップ４２１又はステップ４４１でステータスコード「３０４（Not Modified）」を含まないと判定される場合としては、例えば、ウェブシステム１０は正常に動作しているものの、画面再現装置４０のエラーによるパケットロス等で正しくファイルを取り出せないような場合も考えられる。具体的には、ステータスコード「２００（OK）」なのにレスポンスファイルがない、もしくは更に悪く、リクエストパケットに対応するレスポンスパケットがない、といった場合である。このような場合、レスポンスファイル送出部４７は、「再現を要求された画面はトレースのエラーにより再現不能」といったエラー画面をクライアント３０のブラウザに送出するとよい。

また、ステップ４２３又はステップ４４３で適切なキャッシャブルファイルがあった旨の情報が返されなかったと判定された場合、レスポンスファイル送出部４７は、ステータスコード「４０４（Not Found）」を含むレスポンスパケットをクライアント３０に送出し（ステップ４４６）、処理を終了する。
これにより、クライアント３０のブラウザには、キャッシャブルファイルが見つからなかった部分が空白となった画面が表示される。厳密には画面再現が正常に表示できたとは言えないかもしれないが、たとえ不完全だとしてもどのような画面だったかを確認したいときには有効である。

或いは、ステップ４２３又はステップ４４３で適切なキャッシャブルファイルがあった旨の情報が返されなかったと判定された場合、レスポンスファイル送出部４７は、「画面再現に必要なファイルが足りないために正常な画面再現が行えない」といったエラー画面をクライアント３０のブラウザに送出してもよい。これは、画面が再現できなかったことを厳密に確認したいときに有効となる。

［第２の実施の形態］
図５は、第２の実施の形態が適用されるコンピュータシステムの構成を示したブロック図である。
図示するように、コンピュータシステムは、ウェブシステム１０と、クライアント２０と、クライアント３０と、画面再現装置４０とが、インターネット等のネットワーク８０に接続されることにより構成されている。特に、クライアント２０は、代理サーバであるプロキシ７０を経由してネットワーク８０に接続されているものとする。

ウェブシステム１０、クライアント２０，３０については、第１の実施の形態で述べたのと同様であるので、ここでの説明は省略する。

画面再現装置４０は、あるユーザがある時間にクライアント２０に表示した画面をクライアント３０で再現するための処理を行う装置である。この第２の実施の形態では、キャプチャして記憶されたトレースから適切なタイミングでキャッシャブルファイルを抽出して保管し、あるユーザがある時間に表示した画面の部品がトレースに存在しない場合に、保管したキャッシャブルファイルを利用して画面を再現する。尚、以下では、クライアント３０からの画面の再現の要求に応じて、画面を再現しクライアント３０に出力するものとして説明するが、自身のユーザインターフェイスからの画面の再現の要求に応じて、画面を再現し自身が表示するようにしてもよい。

ここで、画面再現装置４０の機能構成について詳細に説明する。
図示するように、画面再現装置４０は、キャプチャ部４１と、キャッシャブルファイル判定部４２と、トレース分類部４３と、トレース記憶部４４と、トレース管理部４５と、レスポンスファイル抽出部４６と、レスポンスファイル送出部４７と、キャッシャブルファイル管理部４８と、キャッシャブルファイル記憶部４９とを備える。このうち、キャプチャ部４１、キャッシャブルファイル判定部４２、トレース分類部４３、トレース管理部４５、レスポンスファイル抽出部４６、レスポンスファイル送出部４７、キャッシャブルファイル管理部４８は、ＣＰＵ９０ａ（図１４参照）がプログラムを磁気ディスク装置９０ｇ（図１４参照）からメインメモリ９０ｃ（図１４参照）に読み込んで実行することにより、実現される。また、トレース記憶部４４、キャッシャブルファイル記憶部４９は、例えば磁気ディスク装置９０ｇ（図１４参照）によって実現される。

キャプチャ部４１は、ネットワーク８０上のトラフィックのトレースを取得する。尚、トレースは、図中斜線で示したミラーポート又はＴＡＰ接続により取得する。
トレース分類部４３は、キャプチャ部４１が取得したネットワーク８０上のトレースをクライアント２０ごとに分類し、複数のトレースファイルを作成する。ここで、トレースファイルの作成は、キャプチャ部４１によるトレースのキャプチャ中に連続的に行ってもよいし、再現対象の画面が表示されたクライアント２０を選択してプル形式で行ってもよい。
トレース記憶部４４は、トレース分類部４３が作成した複数のトレースファイルを記憶する。本実施の形態では、トレースデータを蓄積する蓄積部の一例として、トレース記憶部４４を設けている。

トレース管理部４５は、トレース記憶部４４に記憶されたトレースファイルのどの部分までキャッシャブルファイル判定部４２による判定処理が行われているかを管理する。そして、キャッシャブルファイル判定部４２による判定処理が行われていないトレースを適切なタイミングで読み出す。
キャッシャブルファイル判定部４２は、トレース管理部４５が読み出したトレース内のレスポンスパケットを解析し、このレスポンスパケットに含まれるレスポンスファイルがキャッシャブルかどうかを判定する。そして、キャッシャブルと判定すれば、レスポンスパケットからレスポンスヘッダとレスポンスファイルとを抽出してキャッシャブルファイル管理部４８に送る。本実施の形態では、ファイルの一例として、レスポンスファイルを用いており、ファイルを抽出する抽出部の一例として、キャッシャブルファイル判定部４２を設けている。

レスポンスファイル抽出部４６、レスポンスファイル送出部４７、キャッシャブルファイル管理部４８、キャッシャブルファイル記憶部４９については、第１の実施の形態で述べたのと同様であるので、ここでの説明は省略する。

次に、第２の実施の形態における画面再現装置４０の動作について詳細に説明する。
まず、一般ユーザがクライアント２０のブラウザからネットワーク８０を介してウェブシステム１０に接続し、ウェブシステム１０を使用しているものとする。この状態で、キャプチャ部４１が、ネットワーク８０上のトラフィックのトレースを取得する。この場合、トレースは、ネットワーク８０上のスイッチのミラーポートを使用したり、ネットワーク８０にＴＡＰを挿入したりすることによって、取得すればよい。トレースには複数のクライアント２０のトラフィックが混ざっているので、トレース分類部４３は、クライアント２０ごとに分類したトレースファイルを作成する。そして、クライアント２０ごとに分類したトレースファイルをトレース記憶部４４に保存する。

その後、画面再現装置４０は、適切なタイミングで、バッチ処理によりキャッシャブルファイルを保存する。尚、適切なタイミングの例としては、処理対象のトレースがそれほど多くなければ、画面再現装置４０の使用開始時が挙げられる。即ち、画面再現装置４０のユーザが画面再現装置４０の使用開始時等に手動でバッチ処理を起動するとよい。或いは、画面再現装置４０が連続的に稼働しておりトレースが多くなるのであれば、毎晩一定時刻というタイミングも考えられる。この場合は、毎晩一定時刻に画面再現装置４０を自動起動してバッチ処理を行い、当日のトレースから画面再生する際に当日分のトレースについてのバッチ処理を追加で行えばよい。

図６は、画面再現装置４０がキャッシャブルファイルを保存するときの動作例を示したフローチャートである。尚、上記バッチ処理が起動されることにより、このフローチャートの動作は開始するものとする。

画面再現装置４０では、図６に示すように、まず、トレース管理部４５が、トレース記憶部４４から、キャッシャブルファイル判定部４２による判定処理を行っていないトレースを順次読み出す（ステップ４５１）。

次に、キャッシャブルファイル判定部４２は、トレース内のレスポンスパケットを解析し、レスポンスパケットに含まれるレスポンスファイルがキャッシャブルかどうかを判定するキャッシャブルファイル判定処理を行う（ステップ４５２）。尚、このキャッシャブルファイル判定処理では、レスポンスファイルがキャッシュされ得ると判断するための条件として予め定められた条件を満たしているかどうかを判定するが、その詳細については後述する。

そして、キャッシャブルファイル判定部４２は、キャッシャブルファイル判定処理の結果がキャッシャブルであることを示しているかどうかを判定する（ステップ４５３）。
その結果、キャッシャブルファイル判定処理の結果がキャッシャブルであることを示していない場合、キャッシャブルファイル判定部４２は、そのまま制御をトレース管理部４５に戻す。すると、トレース管理部４５は、次回のバッチ処理で継続して処理できるように、キャッシャブルファイル判定部４２により判定処理済のトレースの部分が分かるようにする（ステップ４５４）。例えば、どの時刻のトレースまで処理が終わったかを記録すればよい。

一方、キャッシャブルファイル判定処理の結果がキャッシャブルであることを示している場合、キャッシャブルファイル判定部４２は、トレース内のレスポンスパケットからレスポンスファイルとレスポンスヘッダとを抽出し、キャッシャブルファイル管理部４８を通して、レスポンスファイル本体とレスポンスヘッダ内の付加情報とをキャッシャブルファイル記憶部４９に記憶する（ステップ４５６）。具体的には、キャッシャブルファイル判定部４２が、抽出したレスポンスファイルとレスポンスヘッダとをキャッシャブルファイル管理部４８に送る。そして、キャッシャブルファイル管理部４８が、レスポンスヘッダから必要な付加情報を取り出し、キャッシャブルファイル本体と付加情報とをキャッシャブルファイル記憶部４９に記憶する。或いは、キャッシャブルファイル判定部４２が、トレース内のレスポンスパケットから、レスポンスファイルと、レスポンスヘッダ内の必要な付加情報とを抽出し、これらをキャッシャブルファイル管理部４８に送り、キャッシャブルファイル管理部４８が、これらの情報をキャッシャブルファイル記憶部４９に記憶するようにしてもよい。

その後、キャッシャブルファイル判定部４２は、制御をトレース管理部４５に戻す。すると、トレース管理部４５は、次回のバッチ処理で継続して処理できるように、キャッシャブルファイル判定部４２により判定処理済のトレースの部分が分かるようにする（ステップ４５４）。例えば、どの時刻のトレースまで処理が終わったかを記録すればよい。

尚、画面再現装置４０が画面を再生するときの動作は、図３，４のフローチャートに示したものと同様であるので、説明を省略する。

［キャッシャブルファイル判定処理及びキャッシャブルファイル選択処理］
次に、図２のステップ４０２と図６のステップ４５２におけるキャッシャブルファイル判定処理、及び、図３のステップ４２２と図４のステップ４４２におけるキャッシャブルファイル選択処理について、詳細に説明する。

ここで、キャッシャブルファイル判定処理及びキャッシャブルファイル選択処理には、簡易版ロジックと厳密版ロジックとがある。
ウェブシステム１０によっては、キャッシャブルファイルが、追加や削除はされることがあっても更新されることはなく、かつ、全てのユーザにより共通に使用されることが保証されている場合がある。即ち、キャッシャブルファイルのバージョンコントロールが不要であり、同一のＵＲＩ（Uniform Resource Identifier）で示されるキャッシャブルファイルが１個又は０個である場合である。このような場合は、簡易版ロジックで十分である。
一方で、キャッシャブルファイルが、追加や削除だけでなく更新されることがあったり、ユーザごとにその内容が異なったりする場合がある。即ち、時間によって複数のバージョンのキャッシャブルファイルが存在する場合、又は、同一のＵＲＩで示されるキャッシャブルファイルがユーザによって異なる場合である。このような場合は、厳密版ロジックを用いる必要がある。

（簡易版ロジック）
第一に、キャッシャブルファイル判定処理の簡易版ロジックについて説明する。
図７は、この場合のキャッシャブルファイル判定処理の動作例を示したフローチャートである。
図７に示すように、まず、キャッシャブルファイル判定部４２は、レスポンスファイルのファイルタイプを検査する（ステップ５０１）。
そして、レスポンスファイルのファイルタイプが特定のファイルタイプと一致するかどうかを判定する（ステップ５０２）。キャッシュされ得るレスポンスファイルのファイルタイプは、スタイルシート（CSS）や画像ファイル（png, gif）であるので、特定のファイルタイプとしては、これらのファイルタイプを採用すればよい。

その結果、レスポンスファイルのファイルタイプが特定のファイルタイプと一致すると判定されれば、キャッシャブルファイル判定部４２は、レスポンスファイルをキャッシャブルファイルであると判定する（ステップ５０３）。
一方、レスポンスファイルのファイルタイプが特定のファイルタイプと一致しないと判定されれば、キャッシャブルファイル判定部４２は、レスポンスファイルをキャッシャブルファイルでないと判定する（ステップ５０４）。

ところで、この簡易版ロジックでは、ファイルタイプのみに基づいてキャッシャブルファイルであるかどうかを判定しているので、キャッシャブルでないファイルを誤ってキャッシャブルと判定し記憶してしまうことがあるかもしれない。
しかしながら、このようなことが起こったとしても、問題は生じない。キャッシャブルでないファイルは、画面再現のためのトレースに必ず含まれているはずなので、キャッシャブルと誤判定されて記憶されたファイルが使われることはないからである。従って、ウェブシステム１０でキャッシャブルとして扱われる可能性のあるファイルのファイルタイプは全て特定のファイルタイプとして判定対象とすればよい。

尚、この簡易版ロジックにおいて、キャッシャブルファイル判定部４２は、既にキャッシャブルファイルとして記憶されているファイルのＵＲＬ及びファイル名と同じＵＲＬ及びファイル名を持つファイルがトレースから見つかった場合、この見つかったファイルを重複して記憶する必要はない。
また、画面再現装置４０からウェブシステム１０上のファイルにアクセスできる場合には、ウェブシステム１０上のスタティックファイルとみなせるファイルタイプのファイルを直接キャッシャブルファイル記憶部４９にコピーしたり、ウェブシステム１０上のファイルにリクエストに応じて直接アクセスしたりすることにより、このキャッシャブルファイル判定処理は更に容易に実装することができる。

さて、上記キャッシャブルファイル判定処理でキャッシャブルであると判定されたレスポンスファイルはキャッシャブルファイル記憶部４９に保存される。簡易版ロジックにおいて、このとき最低限記憶すべきデータは、ＵＲＩ（ホスト名、パス、ファイル名）及びレスポンスファイル本体である。また、必須ではないが、レスポンスヘッダのContent-Typeフィールドの値を記憶してもよい。レスポンスヘッダのその他のフィールドについてはオプショナルである。

第二に、キャッシャブルファイル選択処理の簡易版ロジックについて説明する。
図８は、この場合のキャッシャブルファイル選択処理の動作例を示したフローチャートである。
図８に示すように、まず、キャッシャブルファイル管理部４８は、キャッシャブルファイル記憶部４９からキャッシャブルファイルを１つ読み出す（ステップ５１１）。
そして、キャッシャブルファイルに付加されているＵＲＩが、トレース内のリクエストパケットにおけるＵＲＩ（ホスト名、パス、ファイル名）と一致するかどうかを判定する（ステップ５１２）。

その結果、これらのＵＲＩが一致すると判定されれば、キャッシャブルファイル管理部４８は、ステップ５１１で読み出したキャッシャブルファイルを、選択すべきキャッシャブルファイルであると判定する（ステップ５１３）。
一方、これらのＵＲＩが一致しないと判定されれば、キャッシャブルファイル管理部４８は、キャッシャブルファイル記憶部４９に記憶された全てのキャッシャブルファイルについての処理が終了したかどうかを判定する（ステップ５１４）。そして、全てのキャッシャブルファイルについての処理が終了していないと判定されれば、ステップ５１１へ戻って、次のキャッシャブルファイルについて同様の処理を行う。また、全てのキャッシャブルファイルについての処理が終了したと判定されれば、キャッシャブルファイル管理部４８は、選択すべきキャッシャブルファイルが存在しないと判定する（ステップ５１５）。

（厳密版ロジック）
第一に、キャッシャブルファイル判定処理の厳密版ロジックについて説明する。
図９は、この場合のキャッシャブルファイル判定処理の動作例を示したフローチャートである。
図９に示すように、まず、キャッシャブルファイル判定部４２は、レスポンスファイルがキャッシャブルファイルでない場合の条件を、レスポンスヘッダのフィールドが満たすかどうかを検査する（ステップ５５１）。ここで、レスポンスファイルがキャッシャブルファイルでない場合の条件とは、レスポンスヘッダにCache-Controlフィールドがあり、その値がno-cache又はno-storeであるという条件、レスポンスヘッダにPragmaフィールドがあり、その値がno-cacheであるという条件、レスポンスヘッダにVaryフィールドがあり、その値が*であるという条件である。即ち、このステップでは、これらの何れかの条件が満たされるかどうかを検査する。

そして、この検査結果が条件を満たすことを示しているかどうかを判定する（ステップ５５２）。
その結果、条件を満たすことを示していると判定されれば、キャッシャブルファイル判定部４２は、レスポンスファイルをキャッシャブルファイルでないと判定する（ステップ５５６）。

一方、ステップ５５２で条件を満たすことを示していると判定されなければ、キャッシャブルファイル判定部４２は、レスポンスファイルがキャッシャブルファイルである場合の条件を、レスポンスヘッダのフィールドが満たすかどうかを検査する（ステップ５５３）。ここで、レスポンスファイルがキャッシャブルファイルである場合の条件とは、レスポンスヘッダにCache-Controlフィールドがあり、その値がpublic、private、max-age=#seconds、must-revalidate、s-maxageの何れかであるという条件、レスポンスヘッダにExpiresフィールドがあるという条件、レスポンスヘッダにETagフィールド又はLast-Modifiedフィールドがあるという条件、レスポンスヘッダにVaryフィールドがあり、その値が別のフィールド名であるという条件である。即ち、このステップでは、これらの何れかの条件が満たされるかどうかを検査する。

そして、この検査結果が条件を満たすことを示しているかどうかを判定する（ステップ５５４）。
その結果、条件を満たすことを示していると判定されれば、キャッシャブルファイル判定部４２は、レスポンスファイルをキャッシャブルファイルであると判定する（ステップ５５５）。
一方、条件を満たすことを示していると判定されなければ、即ち、レスポンスファイルがキャッシャブルファイルでない場合の条件、レスポンスファイルがキャッシャブルファイルである場合の条件の何れも満たされていないと判定されれば、キャッシャブルファイル判定部４２は、レスポンスファイルをキャッシャブルファイルでないと判定する（ステップ５５６）。

尚、この厳密版ロジックにおいて、キャッシャブルファイル判定部４２は、既にキャッシャブルファイルとして記憶されているファイルのＵＲＬ及びファイル名と同じＵＲＬ及びファイル名を持つファイルがトレースから見つかった場合、上記で検査したフィールドの値が異なれば、この見つかったファイルを別のキャッシャブルファイルとして記憶し、上記で検査したフィールドの値が同じであれば、この見つかったファイルを重複して記憶しないようにすればよい。

さて、上記キャッシャブルファイル判定処理でキャッシャブルであると判定されたレスポンスファイルはキャッシャブルファイル記憶部４９に保存される。
図１０は、レスポンスファイル本体に加えて、キャッシャブルファイル記憶部４９に記憶される付加情報の一例を示した図である。
図示するように、付加情報には、ＵＲＩ、TimeStamp、Cache-Control、Pragma、Expires、ETag、Last-Modified、Vary、ユーザＩＤが含まれる。

ＵＲＩは、リクエストヘッダのHostフィールドのホスト名及びポート名と、リクエスト行のパス及びファイル名とを含む。尚、本明細書では、リクエストパケットのメッセージヘッダを「リクエストヘッダ」とするが、これには、ＨＴＴＰで定義された一般ヘッダやエンティティヘッダも含まれる。
TimeStampは、画面再現装置４０がレスポンスファイルを取得した日時であり、レスポンスヘッダのDateフィールドの値がセットされる。
Cache-Controlは、レスポンスヘッダのCache-Controlフィールドの値であり、Pragmaは、レスポンスヘッダのPragmaフィールドの値であり、Expiresは、レスポンスヘッダのExpiresフィールドの値であり、ETagは、レスポンスヘッダのETagフィールドの値であり、Last-Modifiedは、レスポンスヘッダのLast-Modifiedフィールドの値である。
Varyは、レスポンスヘッダのVaryフィールドの値であるフィールド名及びそのフィールド名のフィールドの値である。図中、「Ｆｎ＝Ｖｎ」の「Ｆｎ」がフィールド名を、「Ｖｎ」がそのフィールド名のフィールドの値を示している（ｎ＝１，２，３，４，…）。
ユーザＩＤは、cache-controlフィールドの値がprivateである場合のみ有効であり、ユーザがクライアント３０でログイン時に入力されたユーザＩＤがセットされる。
また、必須ではないが、レスポンスヘッダのContent-Typeフィールドの値を記憶してもよい。レスポンスヘッダのその他のフィールドについてはオプショナルである。

次に、このキャッシャブルファイルの付加情報と比較する対象であるトレースファイルについても説明しておく。
図１１は、トレースファイルの内容の一例を示した図である。
（ａ）は、検証モデルが使用された場合のトレースの内容を示す。１行目に示すように、トレースには、開始行と、メッセージヘッダと、メッセージボディとが含まれる。そして、２行目はＨＴＭＬファイルに対するリクエストパケットであり、３行目はそのリクエストパケットに対応するレスポンスパケットである。ここで、３行目の開始行では、ステータスコード「３０４」が返されているので、ウェブシステム１０からＨＴＭＬファイル本体は送られていないことが分かる。また、５行目はエンベッドファイルに対するリクエストパケットであり、６行目はそのリクエストパケットに対応するレスポンスパケットである。ここで、６行目の開始行では、ステータスコード「３０４」が返されているので、ウェブシステム１０からエンベッドファイル本体は送られていないことが分かる。

（ｂ）は、期限モデルが使用された場合のトレースの内容を示す。１行目に示すように、トレースには、開始行と、メッセージヘッダと、メッセージボディとが含まれる。そして、２行目はＨＴＭＬファイルに対するリクエストパケットであり、３行目はそのリクエストパケットに対応するレスポンスパケットである。ここで、３行目の開始行では、ステータスコード「３０４」が返されているので、ウェブシステム１０からＨＴＭＬファイル本体は送られていないことが分かる。また、（ｂ）では、（ａ）と異なり、エンベッドファイルに対するリクエストパケットが記録されていないので、ウェブシステム１０に対してリクエストパケットが送られておらず、ウェブシステム１０からエンベッドファイル本体が送られてもいないことが分かる。

尚、図において、メッセージヘッダについては、キャッシャブルファイル選択処理で使用するフィールドを主に示し、その他のフィールドについては記載を省略している。
また、図示していないが、トレースファイルには、あるユーザの一連の操作に関するトレースに対して、ユーザＩＤが関連付けて記録されているものとする。

第二に、キャッシャブルファイル選択処理の厳密版ロジックについて説明する。
図１２，１３は、この場合のキャッシャブルファイル選択処理の動作例を示したフローチャートである。
図１２に示すように、まず、キャッシャブルファイル管理部４８は、キャッシャブルファイル記憶部４９からキャッシャブルファイルを１つ読み出す（ステップ５６１）。
そして、キャッシャブルファイルに付加されているＵＲＩが、トレース内のリクエストパケットにおけるＵＲＩ（ホスト名、パス、ファイル名）と一致するかどうかを判定する（ステップ５６２）。

その結果、これらのＵＲＩが一致すると判定されれば、キャッシャブルファイル管理部４８は、キャッシャブルファイル記憶部４９に記憶された付加情報内の値とトレース内のリクエストヘッダのフィールドの値とで以下の比較を行う。
即ち、まず、キャッシャブルファイル管理部４８は、Cache-Controlが付加情報にある場合に、その値が条件を満たすかどうかを検査する（ステップ５６３）。ここで、条件とは、その値がpublicであるという条件、その値がprivateであり、付加情報内のユーザＩＤとトレース内のユーザＩＤとが一致するという条件、その値がs-maxage=#secondsであり、付加情報内のTimeStampからトレース内のリクエストヘッダのDateフィールドで示される日時までの時間が#seconds以内であるという条件、その値がmax-age=#secondsであり、付加情報内のTimeStampからトレース内のリクエストヘッダのDateフィールドで示される日時までの時間が#seconds以内であるという条件、その値がmust-revalidateであるという条件である。即ち、このステップでは、これらの何れかの条件が満たされるかどうかを検査する。ここで、s-maxage及びmax-ageの値は、ファイルに設定されたファイルの有効性に関する情報の一例である。尚、Cache-Controlが付加情報にない場合は、条件が満たされている旨を検査結果にセットする。

そして、この検査結果が条件を満たすことを示しているかどうかを判定する（ステップ５６４）。
その結果、条件を満たすことを示していると判定されれば、キャッシャブルファイル管理部４８は、ETagが付加情報にある場合に、その値が条件を満たすかどうかを検査する（ステップ５６５）。ここで、条件とは、その値がトレース内のリクエストヘッダのIf-None-Matchフィールドで示されるETagの値と一致するという条件である。即ち、このステップでは、この条件が満たされるかどうかを検査する。尚、ETagが付加情報にない場合は、条件が満たされている旨を検査結果にセットする。

そして、この検査結果が条件を満たすことを示しているかどうかを判定する（ステップ５６６）。
その結果、条件を満たすことを示していると判定されれば、キャッシャブルファイル管理部４８は、Last-Modifiedが付加情報にある場合に、その値が条件を満たすかどうかを検査する（ステップ５６７）。ここで、条件とは、その値がトレース内のリクエストヘッダのLast-Modifiedフィールドの値と一致するという条件である。即ち、このステップでは、この条件が満たされるかどうかを検査する。尚、Last-Modifiedが付加情報にない場合は、条件が満たされている旨を検査結果にセットする。

そして、この検査結果が条件を満たすことを示しているかどうかを判定する（ステップ５６８）。
その結果、条件を満たすことを示していると判定されれば、図１３に示すように、キャッシャブルファイル管理部４８は、If-Modified-Sinceがトレース内のリクエストヘッダにある場合に、その値が条件を満たすかどうかを検査する（ステップ５８１）。ここで、条件とは、その値が付加情報内のLast-Modifiedで示される日時と等しいか又はその日時よりも古いという条件である。即ち、このステップでは、この条件が満たされるかどうかを検査する。尚、If-Modified-Sinceがトレース内のリクエストヘッダにない場合は、条件が満たされている旨を検査結果にセットする。

そして、この検査結果が条件を満たすことを示しているかどうかを判定する（ステップ５８２）。
その結果、条件を満たすことを示していると判定されれば、キャッシャブルファイル管理部４８は、Expiresが付加情報にある場合に、その値が条件を満たすかどうかを検査する（ステップ５８３）。ここで、条件とは、その値がトレース内のリクエストヘッダのDateフィールドで示される日時よりも新しいという条件である。即ち、このステップでは、この条件が満たされるかどうかを検査する。ここで、Expiresの値は、ファイルに設定されたファイルの有効性に関する情報の一例である。尚、Expiresが付加情報にない場合は、条件が満たされている旨を検査結果にセットする。

ところで、Expiresが付加情報にある場合は、期限モデルによるキャッシュ制御が行われており、トレース内にエンベッドファイルに対するリクエストパケットが存在しないことがある。そうなると、上記Dateフィールドとして、エンベッドファイルに対するリクエストパケットのDateフィールドを用いることはできない。そこで、代用として、エンベッドファイルがエンベッドされるＨＴＭＬファイルに対するリクエストパケットのDateフィールドを用いることとする。図１１（ｂ）を例にとれば、４行目以降にエンベッドファイルに対するリクエストパケットがないので、２行目のＨＴＭＬファイルに対するリクエストパケットのDateフィールドを用いる。厳密には、ＨＴＭＬファイルに対するリクエストパケットのDateフィールドの日時は、エンベッドファイルを要求した日時よりも若干早くなるが、期限モデルによるキャッシュ制御は本来厳密性を要求しない場合に行われるものなので、問題はないと考えられる。
尚、上記では、エンベッドファイルがエンベッドされるＨＴＭＬファイルに対するリクエストパケットのDateフィールドを用いることとしたが、対象の画面の再現に用いられる如何なるファイルに対するリクエストパケットのDateフィールドを用いてもよい。

そして、キャッシャブルファイル管理部４８は、ステップ５８３の検査結果が条件を満たすことを示しているかどうかを判定する（ステップ５８４）。
その結果、条件を満たすことを示していると判定されれば、キャッシャブルファイル管理部４８は、Varyが付加情報にある場合に、その値が条件を満たすかどうかを検査する（ステップ５８５）。ここで、条件とは、Varyで示されるフィールドの値がトレース内のリクエストヘッダのそのフィールドの値と一致するという条件である。即ち、このステップでは、この条件が満たされるかどうかを検査する。尚、Varyが付加情報にない場合は、条件が満たされている旨を検査結果にセットする。

そして、この検査結果が条件を満たすことを示しているかどうかを判定する（ステップ５８６）。
その結果、条件を満たすことを示していると判定されれば、キャッシャブルファイル管理部４８は、ステップ５６１で読み出したキャッシャブルファイルを、選択すべきキャッシャブルファイルであると判定する（ステップ５８７）。
一方、図１２のステップ５６２でＵＲＩが一致しないと判定された場合、図１２のステップ５６４で条件を満たさないと判定された場合、図１２のステップ５６６で条件を満たさないと判定された場合、図１２のステップ５６８で条件を満たさないと判定された場合、図１３のステップ５８２で条件を満たさないと判定された場合、図１３のステップ５８４で条件を満たさないと判定された場合、図１３のステップ５８６で条件を満たさないと判定された場合、キャッシャブルファイル管理部４８は、キャッシャブルファイル記憶部４９に記憶された全てのキャッシャブルファイルについての処理が終了したかどうかを判定する（ステップ５８８）。そして、全てのキャッシャブルファイルについての処理が終了していないと判定されれば、図１２のステップ５６１へ戻って、次のキャッシャブルファイルについて同様の処理を行う。また、全てのキャッシャブルファイルについての処理が終了したと判定されれば、キャッシャブルファイル管理部４８は、選択すべきキャッシャブルファイルが存在しないと判定する（ステップ５８９）。

以上、本発明の実施の形態について説明した。
このように、本実施の形態では、トレースからキャッシャブルファイルを抽出して保管し、その後、あるユーザがある時間に表示した画面を再現する際に、保管しておいたキャッシャブルファイルを利用するようにした。これにより、キャッシャブルファイルを保管するための記憶容量、画面再現時のキャッシャブルファイルの検索時間の双方を、実用的なものとすることが可能となった。

最後に、本実施の形態を適用するのに好適なコンピュータのハードウェア構成について説明する。図１４は、このようなコンピュータのハードウェア構成の一例を示した図である。図示するように、コンピュータは、演算手段であるＣＰＵ（Central Processing Unit）９０ａと、Ｍ／Ｂ（マザーボード）チップセット９０ｂを介してＣＰＵ９０ａに接続されたメインメモリ９０ｃと、同じくＭ／Ｂチップセット９０ｂを介してＣＰＵ９０ａに接続された表示機構９０ｄとを備える。また、Ｍ／Ｂチップセット９０ｂには、ブリッジ回路９０ｅを介して、ネットワークインターフェイス９０ｆと、磁気ディスク装置（ＨＤＤ）９０ｇと、音声機構９０ｈと、キーボード／マウス９０ｉと、フレキシブルディスクドライブ９０ｊとが接続されている。

尚、図１４において、各構成要素は、バスを介して接続される。例えば、ＣＰＵ９０ａとＭ／Ｂチップセット９０ｂの間や、Ｍ／Ｂチップセット９０ｂとメインメモリ９０ｃの間は、ＣＰＵバスを介して接続される。また、Ｍ／Ｂチップセット９０ｂと表示機構９０ｄとの間は、ＡＧＰ（Accelerated Graphics Port）を介して接続されてもよいが、表示機構９０ｄがＰＣＩ Ｅｘｐｒｅｓｓ対応のビデオカードを含む場合、Ｍ／Ｂチップセット９０ｂとこのビデオカードの間は、ＰＣＩ Ｅｘｐｒｅｓｓ（ＰＣＩｅ）バスを介して接続される。また、ブリッジ回路９０ｅと接続する場合、ネットワークインターフェイス９０ｆについては、例えば、ＰＣＩ Ｅｘｐｒｅｓｓを用いることができる。また、磁気ディスク装置９０ｇについては、例えば、シリアルＡＴＡ（AT Attachment）、パラレル転送のＡＴＡ、ＰＣＩ（Peripheral Components Interconnect）を用いることができる。更に、キーボード／マウス９０ｉ、及び、フレキシブルディスクドライブ９０ｊについては、ＵＳＢ（Universal Serial Bus）を用いることができる。

ここで、本発明は、全てハードウェアで実現してもよいし、全てソフトウェアで実現してもよい。また、ハードウェア及びソフトウェアの両方により実現することも可能である。また、本発明は、コンピュータ、データ処理システム、コンピュータプログラムとして実現することができる。このコンピュータプログラムは、コンピュータにより読取り可能な媒体に記憶され、提供され得る。ここで、媒体としては、電子的、磁気的、光学的、電磁的、赤外線又は半導体システム（装置又は機器）、或いは、伝搬媒体が考えられる。また、コンピュータにより読取り可能な媒体としては、半導体、ソリッドステート記憶装置、磁気テープ、取り外し可能なコンピュータディスケット、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、リジッド磁気ディスク、及び光ディスクが例示される。現時点における光ディスクの例には、コンパクトディスク−リードオンリーメモリ（ＣＤ−ＲＯＭ）、コンパクトディスク−リード／ライト（ＣＤ−Ｒ／Ｗ）及びＤＶＤが含まれる。

以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態には限定されない。本発明の精神及び範囲から逸脱することなく様々に変更したり代替態様を採用したりすることが可能なことは、当業者に明らかである。

１０…ウェブシステム、２０，３０…クライアント、４０…画面再現装置、４１…キャプチャ部、４２…キャッシャブルファイル判定部、４３…トレース分類部、４４…トレース記憶部、４５…トレース管理部、４６…レスポンスファイル抽出部、４７…レスポンスファイル送出部、４８…キャッシャブルファイル管理部、４９…キャッシャブルファイル記憶部

Claims (11)

1. クライアントにサーバから送信されたデータに基づいて表示された画面の再現を支援する装置であって、
   前記クライアントに前記画面が表示された複数の時点で当該画面を表示するために前記サーバから送信されたデータのうち、当該画面を表示するために用いられるファイルを伴うデータから、当該ファイルを抽出する抽出部と、
   前記抽出部により抽出された前記ファイルを記憶する記憶部と、
   前記複数の時点のうちの特定の時点で前記クライアントに表示された前記画面の再現の要求を受け付ける受付部と、
   前記特定の時点で前記画面を表示するために前記サーバから送信されたデータが前記ファイルを含まない場合に、前記記憶部に記憶された前記ファイルを、前記受付部にて受け付けた前記画面の再現の要求に応じて出力する出力部と
   を含む、装置。
2. 前記出力部は、前記特定の時点で前記画面を表示するために前記サーバから送信されたデータが、キャッシュされている前記ファイルが有効であることを示すデータである場合に、前記記憶部に記憶された前記ファイルを、前記受付部にて受け付けた前記画面の再現の要求に応じて出力する、請求項１の装置。
3. 前記出力部は、前記記憶部に記憶された前記ファイルに設定された当該ファイルの有効性に関する情報に基づいて、当該ファイルの有効性が前記特定の時点で失われていないと判断できる場合に、当該ファイルを、前記受付部にて受け付けた前記画面の再現の要求に応じて出力する、請求項２の装置。
4. 前記ファイルは、前記画面の部品を表示するために用いられ、
   前記受付部は、前記特定の時点で前記クライアントに表示された前記部品の再現の要求を受け付け、
   前記出力部は、前記特定の時点で前記部品の表示を要求するデータが前記サーバへ送信されていない場合に、前記記憶部に記憶された前記ファイルを、前記受付部にて受け付けた前記部品の再現の要求に応じて出力する、請求項１乃至３の何れかの装置。
5. 前記出力部は、前記記憶部に記憶された前記ファイルに設定された当該ファイルの有効性に関する情報に基づいて、当該ファイルの有効性が、前記画面の前記部品以外の部分の表示を要求するデータが前記サーバへ送信された時点で失われていないと判断できる場合に、当該ファイルを、前記受付部にて受け付けた前記部品の再現の要求に応じて出力する、請求項４の装置。
6. 前記抽出部は、前記ファイルのタイプが予め定められたタイプである場合に、当該ファイルを伴うデータから、当該ファイルを抽出する、請求項１乃至５の何れかの装置。
7. 前記抽出部は、前記ファイルを伴うデータが、当該ファイルがキャッシュされ得ることを示す情報として予め定められた情報を含む場合に、当該データから当該ファイルを抽出する、請求項１乃至５の何れかの装置。
8. クライアントにサーバから送信されたデータに基づいて表示された画面の再現を支援する装置であって、
   前記クライアントに前記画面が表示された複数の時点で当該画面を表示するために前記サーバから送信されたデータであって、当該画面を表示するために用いられるファイルを伴うデータを含むネットワーク上のトレースデータを蓄積する蓄積部と、
   前記蓄積部に前記トレースデータが蓄積される際に、前記ファイル及び前記ファイルを伴うデータの少なくとも何れか一方が、当該ファイルがキャッシュされ得ると判断するための条件として予め定められた条件を満たしていれば、当該トレースデータに含まれる当該ファイルを伴うデータから、当該ファイルを抽出する抽出部と、
   前記抽出部により抽出された前記ファイルを記憶する記憶部と、
   前記複数の時点のうちの特定の時点で前記クライアントに表示された前記画面の再現の要求を受け付ける受付部と、
   前記蓄積部に蓄積された前記トレースデータに含まれるデータのうち、前記特定の時点で前記画面を表示するために前記サーバから送信されたデータが、前記ファイルを含まず、キャッシュされている前記ファイルが有効であることを示す場合に、前記記憶部に記憶された前記ファイルに設定された当該ファイルの有効性に関する情報に基づいて、当該ファイルの有効性が前記特定の時点で失われていないと判断できれば、当該ファイルを、前記受付部にて受け付けた前記画面の再現の要求に応じて出力する出力部と
   を含む、装置。
9. クライアントにサーバから送信されたデータに基づいて表示された画面の再現を支援する装置であって、
   前記クライアントに前記画面が表示された複数の時点で当該画面を表示するために前記サーバから送信されたデータであって、当該画面を表示するために用いられるファイルを伴うデータを含むネットワーク上のトレースデータを蓄積する蓄積部と、
   前記蓄積部に蓄積された前記トレースデータから読み出された前記ファイル及び前記ファイルを伴うデータの少なくとも何れか一方が、当該ファイルがキャッシュされ得ると判断するための条件として予め定められた条件を満たしていれば、当該トレースデータに含まれる当該ファイルを伴うデータから、当該ファイルを抽出する抽出部と、
   前記抽出部により抽出された前記ファイルを記憶する記憶部と、
   前記複数の時点のうちの特定の時点で前記クライアントに表示された前記画面の再現の要求を受け付ける受付部と、
   前記蓄積部に蓄積された前記トレースデータに含まれるデータのうち、前記特定の時点で前記画面を表示するために前記サーバから送信されたデータが、前記ファイルを含まず、キャッシュされている前記ファイルが有効であることを示す場合に、前記記憶部に記憶された前記ファイルに設定された当該ファイルの有効性に関する情報に基づいて、当該ファイルの有効性が前記特定の時点で失われていないと判断できれば、当該ファイルを、前記受付部にて受け付けた前記画面の再現の要求に応じて出力する出力部と
   を含む、装置。
10. クライアントにサーバから送信されたデータに基づいて表示された画面の再現を支援する方法であって、
    前記クライアントに前記画面が表示された複数の時点で当該画面を表示するために前記サーバから送信されたデータのうち、当該画面を表示するために用いられるファイルを伴うデータから、当該ファイルを抽出するステップと、
    抽出された前記ファイルを記憶部に記憶するステップと、
    前記複数の時点のうちの特定の時点で前記クライアントに表示された前記画面の再現の要求を受け付けるステップと、
    前記特定の時点で前記画面を表示するために前記サーバから送信されたデータが前記ファイルを含まない場合に、前記記憶部に記憶された前記ファイルを、受け付けた前記画面の再現の要求に応じて出力するステップと
    を含む、方法。
11. クライアントにサーバから送信されたデータに基づいて表示された画面の再現を支援する装置としてコンピュータを機能させるプログラムであって、
    前記コンピュータを、
    前記クライアントに前記画面が表示された複数の時点で当該画面を表示するために前記サーバから送信されたデータのうち、当該画面を表示するために用いられるファイルを伴うデータから、当該ファイルを抽出する抽出部と、
    前記抽出部により抽出された前記ファイルを記憶する記憶部と、
    前記複数の時点のうちの特定の時点で前記クライアントに表示された前記画面の再現の要求を受け付ける受付部と、
    前記特定の時点で前記画面を表示するために前記サーバから送信されたデータが前記ファイルを含まない場合に、前記記憶部に記憶された前記ファイルを、前記受付部にて受け付けた前記画面の再現の要求に応じて出力する出力部と
    して機能させる、プログラム。

Images