JP2019028811A - 通信システム、利用者端末通信プログラム、Ｗｅｂサーバ通信プログラム、利用者端末およびＷｅｂサーバ - Google Patents

Abstract

【課題】通信システムにおける障害の発生元の特定を容易にすることができる通信システムを提供すること。【解決手段】プロキシを介して、利用者端末に導入されたブラウザとＷｅｂサーバとの間でＨＴＴＰ通信を行う通信システムにおいて、プロキシは、ブラウザから送信されたＨＴＴＰリクエストをＷｅｂサーバへ送信し、Ｗｅｂサーバへ送信するＨＴＴＰリクエストの情報を保存する。Ｗｅｂサーバは、受信したＨＴＴＰリクエストの内容が正常であるか否かを判定し、ブラウザへＨＴＴＰリクエストに対するレスポンスを送信する。Ｗｅｂサーバは、ＨＴＴＰリクエストの内容が異常であると判定された場合、特定のページへのリダイレクトを指示するレスポンスをブラウザに送信し、プロキシは、前回のＨＴＴＰリクエストの情報を特定のページに対するＨＴＴＰリクエストに付加してＷｅｂサーバへ送信する。【選択図】図１７

Description

本発明は、通信システム、利用者端末通信プログラム、Ｗｅｂサーバ通信プログラム、利用者端末およびＷｅｂサーバに関する。

従来、利用者端末に導入されたブラウザとＷｅｂサーバとの間で通信を行う通信システムが存在する。

利用者端末とＷｅｂサーバとの間において、第三者による悪意の改ざんがなされたり、ルータ等の機器の設定による通信経路に問題があると、本来利用者端末からＷｅｂサーバへ送られるべきデータの内容が棄損する場合がある。この場合、Ｗｅｂサーバは必要なデータが受信できず正常な処理を行うことができない。

そこで、ネットワークに接続されている機器同士で送受信するデータの漏洩や改ざんを防止する技術が開示されている（例えば、特許文献１参照）。

特開２００５−０２０１０５号公報

しかしながら、従来技術では、第三者による改ざんを防止する効果は見込めるものの、データの内容が棄損する障害が発生した場合に、ルータ等の機器の設定の問題なのか、通信システム上の問題なのか、障害の発生元を容易に特定することができなかった。

１つの側面として、本発明は、通信システムにおける障害の発生元の特定を容易にすることを目的とする。

本発明は、上記課題を解決するため、下記のような構成を採用した。
即ち、本発明の一態様によれば、本発明の通信システムは、プロキシを介して、利用者端末に導入されたブラウザとＷｅｂサーバとの間でＨＴＴＰ通信を行う通信システムにおいて、前記プロキシは、前記利用者端末のブラウザから送信されたＨＴＴＰリクエストを前記Ｗｅｂサーバへ送信するリクエスト中継部と、前記Ｗｅｂサーバへ送信するＨＴＴＰリクエストの情報を保存するリクエスト情報処理部と、を備え、前記Ｗｅｂサーバは、受信した前記ＨＴＴＰリクエストの内容が正常であるか否かを判定するリクエスト処理部と、前記利用者端末のブラウザへ前記ＨＴＴＰリクエストに対するレスポンスを送信するレスポンス送信部と、を備え、前記レスポンス送信部は、前記リクエスト処理部により前記ＨＴＴＰリクエストの内容が異常であると判定された場合、特定のページへのリダイレクトを指示するレスポンスを前記利用者端末のブラウザに送信し、前記リクエスト情報処理部は、前記利用者端末のブラウザから前記Ｗｅｂサーバへ送信されるＨＴＴＰリクエストが、前記レスポンスに対応する前記特定のページに対するＨＴＴＰリクエストである場合、前記リクエスト情報処理部が保存した前記ＨＴＴＰリクエストのうち、前回のＨＴＴＰリクエストの情報を前記特定のページに対するＨＴＴＰリクエストに付加し、前記リクエスト中継部は、前回のＨＴＴＰリクエストの情報を付加した前記ＨＴＴＰリクエストを前記Ｗｅｂサーバへ送信することを特徴とする。

本発明によれば、通信システムにおける障害の発生元の特定を容易にすることができる。

本発明の実施形態に係る利用者端末およびＷｅｂサーバを含む通信システムの一例を示す図である。 利用者端末のハードウェアブロック図の例である。 Ｗｅｂサーバのハードウェアブロック図の例である。 実施の形態に係る通信システムを実現するための利用者端末とＷｅｂサーバの機能ブロック図である。 ブラウザに表示される書類の入力画面の一例を示す図である。 利用者端末からＷｅｂサーバへ送信されるＨＴＴＰリクエストの構造の一例を示す図である。 リクエスト情報処理部がキャプチャしたＨＴＴＰリクエストの構造の一例を示す図である。 前回のＨＴＴＰリクエストの情報をＨＴＴＰリクエストヘッダ行に付加した状態を示すＨＴＴＰリクエストの情報を説明する図である。 記録部の書類情報テーブルに格納されている情報の一例を示す図である。 ＨＴＴＰリクエストの内容は正常であると判定された場合にＷｅｂサーバからブラウザへ送信されるＨＴＴＰレスポンスの構造の一例を示す図である。 Ｗｅｂサーバで受信したＨＴＴＰリクエストに異常がある場合の構造の一例を示す図である。 エラー情報テーブルの一例を示す図である。 ＨＴＴＰリクエストの内容は異常であると判定された場合にＷｅｂサーバから利用者端末へ送信されるＨＴＴＰレスポンスの構造の一例を示す図である。 リクエスト受信部が受信したエラーページへのリクエストＵＲＬが含まれるＨＴＴＰリクエストの構造を説明する図である。 回線業者情報テーブルの一例を示す図である。 実施形態に係る通信システムにおける通常時の通信処理の手順の一例を示すシーケンスチャートである。 実施形態に係る通信システムにおける異常時の通信処理の手順の一例を示すシーケンスチャートである。

以下、図面に従って本発明の実施形態を説明する。
図１は、本発明の実施形態に係る利用者端末およびＷｅｂサーバを含む通信システムの一例を示す図である。通信システム１は、利用者端末１０と、Ｗｅｂサーバ２０と、を含む。利用者端末１０と、Ｗｅｂサーバ２０と、の間は、ルータ３０ａと、収容局４０ａと、収容局４０ｂと、ルータ３０ｂと、を介して接続されている。一例として、通信システム１は、取引所と上場会社との間の書類授受を電子化した証券取引所向けのシステムとして使用される。収容局４０ａ、収容局４０ｂ間は、専用回線業者が提供する専用回線により接続される。

本実施形態においては、利用者端末１０に導入されたローカルプロキシ（local proxy）１１を介して利用者端末１０とＷｅｂサーバ２０との間で専用回線によるＨＴＴＰ通信が行われる例について説明する。利用者端末１０、Ｗｅｂサーバ２０間の接続は、ユーザＩＤとパスワードによるログイン認証が使用されている。ログイン認証後は、ＨＴＴＰリクエストヘッダ行にパラメタ（例えば、user-account）が設定される。パラメタ（user-account）のパラメタ値はログイン中のユーザＩＤが設定される。ＨＴＴＰリクエストヘッダの詳細については後述する。尚、本実施形態においては、利用者端末１０は、Ｗｅｂサーバ２０以外のサーバともインターネット回線等を通じて接続されている。

利用者端末１０は、既存のＰＣ（personal computer）により構成され、ローカルプロキシ１１と、ウェブブラウザ（web browser）（以下、「ブラウザ」と称する）１２と、が導入されている。

利用者端末１０のブラウザ１２は、利用者の操作に応じて、ローカルプロキシ１１を介してＷｅｂサーバ２０に対し、ＨＴＴＰ（Hyper Text Transfer Protocol）リクエストを送信する。

ローカルプロキシ１１は、利用者端末１０のブラウザ１２からＷｅｂサーバ２０へ送信されるＨＴＴＰリクエストを中継し、ルータ３０ａと、収容局４０ａ、４０ｂ間の専用回線と、ルータ３０ｂと、を介してＷｅｂサーバ２０へＨＴＴＰリクエストを送信する。

また、ローカルプロキシ１１は、ＨＴＴＰリクエストを中継する際に、ＨＴＴＰリクエストの内容をキャプチャし、記録部１３に記録する。ローカルプロキシ１１がＨＴＴＰリクエストの内容をキャプチャして記録する詳細については、後述する。

Ｗｅｂサーバ２０は、既存のサーバ装置により構成され、利用者端末１０のブラウザ１２から送信されたＨＴＴＰリクエストをルータ３０ｂを介して受信する。

Ｗｅｂサーバ２０は、ＨＴＴＰリクエストの内容を解析し、ＷｅｂサーバのアプリケーションによりＨＴＴＰリクエストに対するＨＴＴＰレスポンスを作成する。

そして、Ｗｅｂサーバ２０は、作成したＨＴＴＰレスポンスをルータ３０ｂと、収容局４０ｂ、４０ａ間の専用回線と、ルータ３０ａと、を介して利用者端末１０のブラウザ１２へ送信する。Ｗｅｂサーバ２０がＨＴＴＰレスポンスをブラウザ１２へ送信する詳細については、後述する。

ローカルプロキシ１１は、ブラウザ１２へ送信されたＨＴＴＰリクエストに対するＨＴＴＰレスポンスを受信し、ブラウザ１２へ送信する。

以下、ルータ３０ａと、収容局４０a、４０b間の専用回線と、ルータ３０ｂと、の間のＨＴＴＰ通信については、特に必要な場合を除き説明を省略する。

次に、実施の形態に係る利用者端末１０を実現するためのハードウェア構成の一例について図２を用いて説明する。図２は、利用者端末１０のハードウェアブロック図の例である。

例えば、利用者端末１０は、ＣＰＵ（Central Processing Unit）１０１と、ＲＡＭ（Random access memory）１０２と、通信インタフェース（Ｉ／Ｆ）１０３と、入出力インタフェース（Ｉ／Ｆ）１０４と、記録部１３と、を有する。ＣＰＵ１０１と、ＲＡＭ１０２と、通信インタフェース（Ｉ／Ｆ）１０３と、入出力インタフェース（Ｉ／Ｆ）１０４と、記録部１３と、は、例えば、バス１０５を介して互いに接続されている。

ＣＰＵ１０１は、バス１０５を介して、記録部１３などに格納される利用者端末１０の各種処理を行うためのプログラムを読み込み、読み込んだプログラムをＲＡＭ１０２に一時的に格納し、そのプログラムにしたがって各種処理を行うものである。

記録部１３には、ＨＴＴＰリクエストをキャプチャした時のＨＴＴＰリクエストの内容、利用者端末１０のローカルプロキシ１１およびブラウザ１２の各種処理を行うためのアプリケーションプログラムや、利用者端末通信プログラム、利用者端末１０の処理に必要なデータなどが格納される。

ＲＡＭ１０２は、揮発性メモリであって、ＣＰＵ１０１に実行させるためのＯＳ（Operating System）やアプリケーションプログラムが一時的に格納される。また、ＲＡＭ１０２には、ＣＰＵ１０１による処理に必要な各種データが格納される。

通信インタフェース（Ｉ／Ｆ）１０３は、Ｗｅｂサーバ２０との間でＨＴＴＰ通信を行うものである。

入出力インタフェース（Ｉ／Ｆ）１０４は、キーボード、マウス、タッチパネルディスプレイ等とデータの送受信を行うものである。バス１０５は、各装置間の制御信号、データ信号などの授受を媒介する経路である。

次に、実施の形態に係るＷｅｂサーバ２０を実現するためのハードウェア構成の一例について図３を用いて説明する。図３は、Ｗｅｂサーバ２０のハードウェアブロック図の例である。

例えば、Ｗｅｂサーバ２０は、ＣＰＵ２０１と、ＲＡＭ２０２と、通信インタフェース（Ｉ／Ｆ）２０３と、記録部２０４と、を有する。ＣＰＵ２０１と、ＲＡＭ２０２と、通信インタフェース（Ｉ／Ｆ）２０３と、記録部２０４と、は、例えば、バス２０５を介して互いに接続されている。

ＣＰＵ２０１は、バス２０５を介して、記録部２０４などに格納されるＷｅｂサーバ２０の各種処理を行うためのプログラムを読み込み、読み込んだプログラムをＲＡＭ２０２に一時的に格納し、そのプログラムにしたがって各種処理を行うものである。

記録部２０４には、Ｗｅｂサーバ２０の各種処理を行うためのＷｅｂアプリケーションを含む各種アプリケーションプログラム、Ｗｅｂサーバ通信プログラム、ドライバ、およびＷｅｂサーバ２０の処理に必要なデータなどが格納される。

ＲＡＭ２０２は、揮発性メモリであって、ＣＰＵ２０１に実行させるためのＯＳやアプリケーションプログラムが一時的に格納される。また、ＲＡＭ２０２には、ＣＰＵ２０１による処理に必要な各種データが格納される。

通信インタフェース（Ｉ／Ｆ）２０３は、利用者端末１０との間でＨＴＴＰ通信を行うものである。

次に、実施の形態に係る通信システム１を実現するための利用者端末１０とＷｅｂサーバ２０の機能ブロック図の例について説明する。図４は、実施の形態に係る通信システム１を実現するための利用者端末１０とＷｅｂサーバ２０の機能ブロック図である。

利用者端末１０には、ローカルプロキシ１１と、ブラウザ１２と、が導入されている。ローカルプロキシ１１には、記録部１３が接続される。記録部１３は、情報保存領域５０１と、Ｗｅｂ情報格納領域５０２を有する。情報保存領域５０１は、ブラウザ１２から送信されるＨＴＴＰリクエストの情報を保存可能な領域である。Ｗｅｂ情報格納領域５０２は、Ｗｅｂサーバ２０の情報を保存可能な領域である。

利用者端末１０は、ローカルプロキシ１１を介して、Ｗｅｂサーバ２０との間でＨＴＴＰ通信を行う。

利用者端末１０のブラウザ１２には、通信システム１上で授受される書類の入力画面が表示される。図５は、ブラウザ１２に表示される書類の入力画面１０００の一例を示す図である。

ブラウザ１２は、利用者端末１０の入出力インタフェース（Ｉ／Ｆ）１０４を介して、入力画面１０００に表示されている各入力項目に対する利用者からのデータ入力を受け付ける。そして、ブラウザ１２は、提出ボタン１００１に対する押下（クリック）操作を受け付けると、ローカルプロキシ１１を介してＷｅｂサーバ２０にＨＴＴＰリクエストを送信する。そして、Ｗｅｂサーバ２０からＨＴＴＰリクエストに対応するＨＴＴＰレスポンスが戻ってくると、ブラウザ１２は、レスポンス結果のＷｅｂページを表示する。

図６は、利用者端末１０（ブラウザ１２）からＷｅｂサーバ２０へ送信されるＨＴＴＰリクエストの構造の一例を示す図である。図６の例では、図５の入力画面１０００の各入力項目にデータが入力され、ＰＯＳＴ通信によりブラウザ１２から送信されたＨＴＴＰリクエストの構造を示している。

ＨＴＴＰリクエストは、ＨＴＴＰリクエスト行と、ＨＴＴＰリクエストヘッダ行と、ＨＴＴＰリクエストボディ行と、を含む情報により構成されている。ＨＴＴＰリクエスト行には、ＰＯＳＴやＧＥＴなどのメソッドの情報、ＵＲＬ（Uniform Resource Locator）などのパスの情報、が含まれる。ＨＴＴＰリクエストヘッダ行には、ユーザＩＤに対応するパラメタ（例えば、user-account）と、このパラメタに対応するパラメタ値としてログイン中のユーザＩＤ（例えば、ZZZZZ）の情報が含まれる。また、ＨＴＴＰリクエスト行には、その他利用環境に応じた任意の情報が含まれる。ＨＴＴＰリクエストボディ行には、ＰＯＳＴ通信が行われる場合に受け渡すパラメタと、このパラメタに対応するパラメタ値の情報が含まれる。

例えば、ＨＴＴＰリクエストボディ行には、ブラウザ１２の入力画面１０００に表示されている各入力項目に対応するパラメタと、このパラメタに対応するパラメタ値の情報が含まれる。具体的には、ＨＴＴＰリクエストボディ行には、会社名に対応するパラメタ（例えば、company）と、このパラメタに対応するパラメタ値（例えば、A株式会社）の情報が含まれる。

次に、ローカルプロキシ１１について説明する。ローカルプロキシ１１は、利用者端末１０上で動作するツールである。ローカルプロキシ１１の起動時に、任意のポートを監視対象の監視ポートとして予め設定する。ローカルプロキシ１１は、設定された監視ポートにてＨＴＴＰリクエストとＨＴＴＰレスポンスの情報を解析する。

ローカルプロキシ１１で設定した監視ポートをブラウザ１２のプロキシポートに予め指定することで、ブラウザ１２から送信されたＨＴＴＰリクエストがローカルプロキシ１１に対し提供される。

ローカルプロキシ１１は、リクエスト情報処理部３０１と、リクエスト中継部３０２と、レスポンス中継部３０３と、を備える。

リクエスト情報処理部３０１は、ブラウザ１２からＷｅｂサーバ２０へ送信されたＨＴＴＰリクエストをキャプチャする。

図７は、リクエスト情報処理部３０１がキャプチャしたＨＴＴＰリクエストの構造の一例を示す図である。リクエスト情報処理部３０１がキャプチャしたＨＴＴＰリクエストの構造は、ブラウザ１２がＷｅｂサーバ２０へ送信した図６のＨＴＴＰリクエストと同一となるため説明を省略する。

リクエスト情報処理部３０１は、キャプチャしたＨＴＴＰリクエストのＵＲＬが、Ｗｅｂサーバ２０のドメインであるか否かを判定する。この処理では、リクエスト情報処理部３０１は、キャプチャしたＨＴＴＰリクエストのＨＴＴＰリクエスト行に含まれるＵＲＬを判定対象とする。例えば、リクエスト情報処理部３０１は、ＨＴＴＰリクエスト行にＷｅｂサーバ２０のドメイン “www.xxx”が含まれているか否かを判定する。Ｗｅｂサーバ２０のドメイン “www.xxx”の情報は、予め記録部１３のＷｅｂ情報格納領域５０２に格納されている。

本実施形態においては、利用者端末１０は、”www.xxx”以外のドメインをもつＷｅｂサーバ２０以外のドメインをもつサーバとも接続されている。したがって、本実施形態においては、通信システムにおける障害の発生元の特定を、”www.xxx”のドメインをもつＷｅｂサーバ２０との通信に特定して行う目的で、ドメインの判定が行われる。

キャプチャしたＨＴＴＰリクエストのＵＲＬがＷｅｂサーバ２０のドメインでない場合は、リクエスト情報処理部３０１は、キャプチャしたＨＴＴＰリクエストをリクエスト中継部３０２へ送る。そして、リクエスト中継部３０２は、キャプチャしたＨＴＴＰリクエストのＵＲＬにＨＴＴＰリクエストを送信する。

キャプチャしたＨＴＴＰリクエストのＵＲＬがＷｅｂサーバ２０のドメインである場合には、リクエスト情報処理部３０１は、キャプチャしたＨＴＴＰリクエストが特定のエラーページへのリクエストであるか否かを判定する。特定のエラーページのＵＲＬの一例として、“www.xxx/error.html”などが使用される。

特定のエラーページへのリクエストを受け付ける場合とは、Ｗｅｂサーバ２０から送信された特定のエラーページへのリダイレクトを指示するＨＴＴＰレスポンスに対し、ブラウザ１２が特定のエラーページとして“www.xxx/error.html”へのＨＴＴＰリクエスト作成し、このＨＴＴＰリクエストをＷｅｂサーバ２０へ送信する場合である。特定のエラーページとは、利用者端末１０からＷｅｂサーバ２０へ送信したＨＴＴＰリクエストのデータの内容に棄損が発生していることを示すページである。特定のエラーページへのリダイレクトを指示するＨＴＴＰレスポンスについては後述する。 特定のエラーページへのリクエストでない場合には、リクエスト情報処理部３０１は、キャプチャしたＨＴＴＰリクエストの情報を文字列に変換する。具体的には、リクエスト情報処理部３０１は、キャプチャしたＨＴＴＰリクエストのＨＴＴＰリクエスト行、ＨＴＴＰリクエストヘッダ行、ＨＴＴＰリクエストボディ行の情報を文字列に変換して直列化する。そして、リクエスト情報処理部３０１は、直列化した文字列の情報を情報保存領域５０１に保存する。

具体的には、リクエスト情報処理部３０１は、キャプチャしたＨＴＴＰリクエストの情報を「パラメタ＝パラメタ値」として１つの項目のフォーマットへ編集して文字列の情報に変換する。フォーマットへの編集において、項目間は、カンマ区切りとする。リクエスト情報処理部３０１は、変換した文字列の情報を情報保存領域５０１へ保存する。具体的には、リクエスト情報処理部３０１がＨＴＴＰリクエストをキャプチャした場合、リクエスト情報処理部３０１は、キャプチャしたＨＴＴＰリクエストの情報を文字列に変換し直列化する。

図７のＨＴＴＰリクエストの情報を文字列に変換して直列化すると「URL="POST https://www.xxx/regist/ent",user-account=ZZZZZ, … , company=A株式会社 , … , registrationdate=20170630」のようになる。

リクエスト情報処理部３０１は、文字列に変換して直列化したＨＴＴＰリクエストの情報を情報保存領域５０１に保存する。

すでに同じＨＴＴＰリクエストに対応する文字列の情報が情報保存領域５０１に保存されている場合には、リクエスト情報処理部３０１は、保存されている文字列の情報を上書きして保存する。文字列の情報が上書きされることにより、情報保存領域５０１に保存されている同じＨＴＴＰリクエストの情報は、１世代のみ保存されることとなり、常に最新の状態を保つことができる。

リクエスト情報処理部３０１は、文字列の情報を保存後、キャプチャしたＨＴＴＰリクエストをリクエスト中継部３０２へ送る。そして、リクエスト中継部３０２は、Ｗｅｂサーバ２０にＨＴＴＰリクエストを送信する。

特定のエラーページへのリクエストである場合には、リクエスト情報処理部３０１は、前回のＨＴＴＰリクエストの情報をエラーページへのＨＴＴＰリクエストのＨＴＴＰリクエストヘッダ行へ付加する。前回のＨＴＴＰリクエストとは、同一セッション上の同一ＵＲＬに対するＨＴＴＰリクエストである。同一セッション上のＨＴＴＰリクエストであるか否かの判断は、ブラウザ１２のｃｏｏｋｉｅ等に基づき判断される。同一ＵＲＬに対するＨＴＴＰリクエストであるか否かの判断は、ＨＴＴＰリクエストのＨＴＴＰリクエスト行に含まれるＵＲＬ等に基づき判断される。

前回のＨＴＴＰリクエストの情報とは、今回キャプチャしたＨＴＴＰリクエストに含まれるＵＲＬと同一のＵＲＬを含む、前回キャプチャしたＨＴＴＰリクエストの情報である。前回キャプチャしたＨＴＴＰリクエストの情報は、情報保存領域５０１に保存されている文字列の情報に基づき参照される。

リクエスト情報処理部３０１は、前回のＨＴＴＰリクエストの情報を情報保存領域５０１に保存されている文字列の情報から抽出する。

リクエスト情報処理部３０１は、今回のＨＴＴＰリクエストのＨＴＴＰリクエストヘッダ行にパラメタ（ヘッダ属性）（例えば、LatestRequestInfo）を設定する。そして、リクエスト情報処理部３０１は、ＨＴＴＰリクエストヘッダ行のパラメタ（ヘッダ属性）（LatestRequestInfo）に対応するパラメタ値に、抽出した文字列の情報を前回のＨＴＴＰリクエストの情報として付加する。これにより、前回のＨＴＴＰリクエストの情報を今回のＨＴＴＰリクエストのＨＴＴＰリクエスト行のヘッダ属性として付加することができる。

図８は、前回のＨＴＴＰリクエストの情報をＨＴＴＰリクエストヘッダ行に付加した状態を示すＨＴＴＰリクエストの情報を説明する図である。図８に示すように、ＨＴＴＰリクエストのヘッダ行に、前回のＨＴＴＰリクエストの情報としてヘッダ属性（LatestRequestInfo）が付加されている。ＨＴＴＰリクエストヘッダ行には、その他利用環境に応じた任意の情報が含まれる。ＨＴＴＰリクエスト行には、エラーページへのリクエストＵＲＬ、すなわち、エラーページへのリダイレクト先のＵＲＬの情報が含まれる。更に、エラーページへのリクエストＵＲＬには、棄損が発生したデータを含むＨＴＴＰリクエストを受信した日時や契機となったＵＲＬ等を検索するキーとなるエラーＩＤ（例えば、x1000013090）が付与されている。

エラーＩＤは、Ｗｅｂサーバ２０で受信したＨＴＴＰリクエストが異常であると判定された場合、リクエスト処理部４０２により、重複のない一意のエラーＩＤが付与される情報である。また、リクエスト処理部４０２は、エラーＩＤと、その異常があると判定された発生日時の情報等をエラー情報テーブル７００に格納する。エラーＩＤについては、後述する。

リクエスト情報処理部３０１は、前回のＨＴＴＰリクエストの情報を付加したＨＴＴＰリクエストをリクエスト中継部３０２へ送る。そして、リクエスト中継部３０２は、前回のＨＴＴＰリクエストの情報を付加したＨＴＴＰリクエストをＷｅｂサーバ２０に送信する。レスポンス中継部３０３は、Ｗｅｂサーバ２０からＨＴＴＰレスポンスが戻ってきた場合、ＨＴＴＰレスポンスをブラウザ１２へ送信する。

次に、図４に戻り、Ｗｅｂサーバ２０について説明する。Ｗｅｂサーバ２０は、リクエスト受信部４０１と、リクエスト処理部４０２と、レスポンス送信部４０３と、を備える。記録部２０４は、書類情報テーブル６００と、エラー情報テーブル７００と、回線業者情報テーブル８００と、リクエスト情報格納領域９００を備える。

リクエスト受信部４０１は、ローカルプロキシ１１を介してブラウザ１２から送信されたＨＴＴＰリクエストを受信する。リクエスト受信部４０１は、受信したＨＴＴＰリクエストのうち、ＨＴＴＰリクエストボディ行の設定内容を記録部２０４のリクエスト情報格納領域９００に格納する。

図９は、記録部２０４の書類情報テーブル６００に格納されている情報の一例を示す図である。

書類情報テーブル６００には、各項目に対応して、必須項目の欄が設定されている。
リクエスト処理部４０２は、ＨＴＴＰリクエストボディ行に、書類情報テーブル６００の各項目のうち、必須項目のすべての項目が存在するか否かを判定する。

ＨＴＴＰリクエストボディ行に、書類情報テーブル６００の各項目のうち、必須項目のすべての項目が存在する場合には、リクエスト処理部４０２は、Ｗｅｂサーバ２０で受信したＨＴＴＰリクエストの内容は正常であると判定する。この場合、レスポンス送信部４０３は、ＨＴＴＰリクエストが正常に行われたことを示す登録完了画面を表示するＨＴＴＰレスポンスをブラウザ１２へ送信する。この場合は、通信経路上で情報の棄損は行われておらず、通信システム１および専用回線のいずれにおいても問題はないということを把握できる。

図１０は、ＨＴＴＰリクエストの内容は正常であると判定された場合にＷｅｂサーバ２０から利用者端末１０へ送信されるＨＴＴＰレスポンスの構造の一例を示す図である。ＨＴＴＰレスポンスは、ステータス行と、ＨＴＴＰレスポンスヘッダ行と、ＨＴＴＰレスポンスボディ行と、を含む情報により構成され、リクエスト処理部４０２が作成する。ステータス行には、ＨＴＴＰのバージョン（例えば、ＨＴＴＰ／１．１）やＨＴＴＰリクエストが正常であることを示すステータス番号（例えば、２００）、ＨＴＴＰリクエストが正常であることを示す補足メッセージの情報（例えば、ＯＫ）等が含まれる。ＨＴＴＰレスポンスヘッダ行には、利用環境に応じた任意の情報が含まれる。ＨＴＴＰレスポンスボディ行には、登録完了画面のＵＲＬの情報が含まれる。

リクエスト処理部４０２は、利用者端末１０で使用されているブラウザ１２に対応するＨＴＴＰのバージョンをＨＴＴＰのバージョンに設定する。

また、ＨＴＴＰリクエストが正常である場合には、リクエスト処理部４０２は、ステータス番号にＨＴＴＰリクエストが正常であることを示す２００を設定し、メッセージの情報に、ＨＴＴＰリクエストが正常であることを示すＯＫの情報を設定する。

次に、ＨＴＴＰリクエストが異常である場合について説明する。
ＨＴＴＰリクエストボディ行に、書類情報テーブル６００の各項目のうち、必須項目が抜けている場合には、リクエスト処理部４０２は、Ｗｅｂサーバ２０で受信したＨＴＴＰリクエストの内容は異常であると判定する。

図１１は、Ｗｅｂサーバ２０で受信したＨＴＴＰリクエストに異常がある場合の構造の一例を示す図である。

図１１のＨＴＴＰリクエストの構造は、ブラウザ１２がＷｅｂサーバ２０へ送信した図６のＨＴＴＰリクエストと基本的には同一である。但し、図１１のＨＴＴＰリクエストのＨＴＴＰリクエストボディ行には、図９の書類情報テーブル６００において必須項目に設定されている「代表者の氏名」の情報が棄損している点でブラウザ１２が送信したＨＴＴＰリクエストと相違する。

例えば、図９の書類情報テーブル６００によると「代表者の氏名」の項目が必須項目となっている。図１１に示すように、送信されたＨＴＴＰリクエストのＨＴＴＰリクエストボディ行に必須項目である「代表者の氏名」の情報がない場合には、リクエスト処理部４０２は、Ｗｅｂサーバ２０で受信したＨＴＴＰリクエストの内容は異常であると判定する。この場合、リクエスト処理部４０２は、異常であると判定されたＨＴＴＰリクエストの情報をエラー情報テーブル７００に格納する。エラー情報テーブル７００は、エラー情報インデックステーブル７０１と、エラー情報詳細テーブル７０２と、を備える。より具体的には、リクエスト処理部４０２は、Ｗｅｂサーバ２０で受信したＨＴＴＰリクエストの内容が異常であると判定した場合に、そのＨＴＴＰリクエストの情報の内容をエラー情報インデックステーブル７０１と、エラー情報詳細テーブル７０２と、に格納する。

図１２は、ＨＴＴＰリクエストが異常であると判定された場合にリクエスト処理部４０２により格納されるエラー情報テーブル７００に格納されるＨＴＴＰリクエストの情報の内容の一例を示す図である。図１２（Ａ）は、エラー情報インデックステーブル７０１に格納される具体的な情報の一例を示す図である。エラー情報インデックステーブルには、エラーＩＤと、ユーザＩＤと、発生日時と、が設定される。リクエスト処理部４０２は、エラーＩＤとして、エラー情報テーブル７００内において、重複のない一意なＩＤ（例えば、x1000013090）を付与する。リクエスト処理部４０２は、エラー情報インデックステーブル７０１に、エラーＩＤに対応して、ユーザＩＤ（例えば、zzzzz）、発生日時（例えば、2017/6/10 17:21:11.123）の情報を格納する。発生日時の情報には、異常な内容を含むＨＴＴＰリクエストを受信してエラーが発生した日時が格納される。

図１２（Ｂ）は、エラー情報詳細テーブル７０２に格納される具体的な情報の一例を示す図である。エラー情報詳細テーブル７０２には、エラーＩＤと、属性と、属性値と、が設定されている。リクエスト処理部４０２は、エラー情報詳細テーブル７０２に、エラーＩＤ（例えば、x1000013090）に対応して、属性の情報、属性値の情報を格納する。 属性の情報には、ブラウザ１２から送信されたＨＴＴＰリクエストに含まれるパラメタが格納され、属性値の情報には、パラメタに対応するパラメタ値が格納される。例えば、ＨＴＴＰリクエストにＨＴＴＰリクエスト行が含まれている場合には、属性の欄の項目名をＵＲＬとし、属性値に当該ＨＴＴＰリクエスト行に含まれる情報（例えば、POST”会社情報登録リクエストURL”）を格納する。同様に、ＨＴＴＰリクエストヘッダ行にuser-accountの情報が格納されている場合には、属性の項目名をuser-accountとし、属性値に当該user-accountのID（例えば、ZZZZZ）を格納する。同様に、ＨＴＴＰリクエストボディ行に、登録日（registrationdate）の情報が格納されている場合には、属性の項目名をregistrationdateとし、属性値に当該registrationdateの日付（例えば、20170630）を格納する。すなわち、エラーＩＤに基づき、エラー情報インデックステーブル７０１およびエラー情報詳細テーブル７０２を参照することにより、異常な内容を含むＨＴＴＰリクエストを受信した日時や契機となったＵＲＬ等を検索することができる。

また、リクエスト処理部４０２が、Ｗｅｂサーバ２０で受信したＨＴＴＰリクエストの内容が異常であると判定した場合には、レスポンス送信部４０３は、エラーページへのリダイレクト指示のＨＴＴＰレスポンスをブラウザ１２へ送信する。

そして、エラーページへのリダイレクト指示のＨＴＴＰレスポンスを受信すると、ブラウザ１２は、特定のエラーページとして“www.xxx/error.html”へのＨＴＴＰリクエスト作成し、このＨＴＴＰリクエストをＷｅｂサーバ２０へ送信する。図１３は、ＨＴＴＰリクエストの内容は異常であると判定された場合にＷｅｂサーバ２０から利用者端末１０（ブラウザ１２）へ送信されるＨＴＴＰレスポンスの構造の一例を示す図である。ＨＴＴＰレスポンスは、ステータス行と、ＨＴＴＰレスポンスヘッダ行と、を含む情報により構成され、リクエスト処理部４０２が作成する。ステータス行には、ＨＴＴＰのバージョン（例えば、ＨＴＴＰ／１．１）や、リダイレクトを示すステータス番号（例えば、３０２）、ＨＴＴＰリクエストが異常であることを示す補足メッセージの情報（例えば、Ｆｏｕｎｄ）等が含まれる。ＨＴＴＰレスポンスヘッダ行には、特定のページのうち、エラーページであることを表示する特定のエラーページへのリダイレクト先のＵＲＬの情報（例えば、https://www.xxx/error.html）、リダイレクト先のＵＲＬの情報に付与されているパラメータであるエラーＩＤ（例えば、［errorid］の値［x1000013090］）や、その他利用環境に応じた任意の情報が含まれる。

リクエスト処理部４０２は、利用者端末１０で使用されているブラウザ１２に対応するＨＴＴＰのバージョンをＨＴＴＰのバージョンに設定する。

また、ＨＴＴＰリクエストが異常である場合には、リクエスト処理部４０２は、ステータス番号にリダイレクトを示す番号３００を設定し、メッセージの情報に、ＨＴＴＰリクエストが異常であることを示すＦｏｕｎｄの情報を設定する。

また、リクエスト処理部４０２は、受信したＨＴＴＰリクエストにエラーページへのリクエストＵＲＬ（例えば、www.xxx/error.html）が含まれているか否かを判定する。エラーページへのリクエストＵＲＬが含まれているか否かの判定は、ＨＴＴＰリクエストのＨＴＴＰリクエスト行にエラーページへのリクエストＵＲＬが含まれているか否かに基づいて行われる。

図１４は、リクエスト受信部４０１が受信したエラーページへのリクエストＵＲＬが含まれるＨＴＴＰリクエストの構造を説明する図である。リクエスト受信部４０１が受信したエラーページへのリクエストＵＲＬが含まれるＨＴＴＰリクエストの構造は、ブラウザ１２がＷｅｂサーバ２０へ送信した図８のＨＴＴＰリクエストと同一となるため説明を省略する。

ＨＴＴＰリクエストにエラーページへのリクエストＵＲＬが含まれている場合には、リクエスト処理部４０２は、エラーページへのリクエストＵＲＬに付与されているエラーＩＤを取得する。図１４の例では、リクエスト処理部４０２は、リクエストＵＲＬ（例えば、https://www.xxx/error.html）に付与されているパラメータであるエラーＩＤ（例えば、［errorid］の値［x1000013090］）を取得する。

ここで、リクエスト処理部４０２は、ブラウザ１２から送信されたＨＴＴＰリクエストに、書類情報テーブル６００の各項目のうち、必須項目が抜けている場合には、Ｗｅｂサーバ２０で受信したＨＴＴＰリクエストの内容は異常であるという点までは特定できる。

但し、この時点では、利用者端末１０と、Ｗｅｂサーバ２０と、の間に介在する専用回線などの通信経路上に不具合があるのか、利用者端末１０やＷｅｂサーバ２０通信システム１の設定に不具合があるのかまでは特定できない。

そこで、リクエスト処理部４０２は、エラー情報テーブル７００に格納されたＨＴＴＰリクエストの情報と、エラーページへのリクエストＵＲＬが含まれるＨＴＴＰリクエストの情報と、が一致するかを判断する。具体的には、リクエスト処理部４０２は、取得したエラーＩＤ（例えば、x1000013090）に基づいて、図１２（Ａ）のエラー情報詳細テーブル７０２内を検索し、異常な内容を含むＨＴＴＰリクエストを受信した日時や契機となったＵＲＬの情報を取得する。

また、リクエスト処理部４０２は、エラーページへのリクエストＵＲＬが含まれるＨＴＴＰリクエストのＨＴＴＰリクエストヘッダ行のパラメタ（例えば、LatestRequestInfo）に対応するパラメタ値の情報を取得する。パラメタ（LatestRequestInfo）に対応するパラメタ値には、前回のＨＴＴＰリクエストの情報が付加されている。

リクエスト処理部４０２は、エラーＩＤをキーとしてエラー情報詳細テーブル７０２内から取得した情報と、エラーページへのリクエストＵＲＬが含まれるＨＴＴＰリクエストヘッダ行のパラメタ値の情報と、が一致するかを判断する。

エラー情報詳細テーブル７０２内から取得した情報と、ＨＴＴＰリクエストヘッダ行のパラメタ値の情報と、が一致しない場合は、リクエスト処理部４０２は、通信経路上において情報の棄損が発生したと判定する。すなわち、利用者端末１０と、Ｗｅｂサーバ２０と、の間に介在するルータ３０ａ、３０ｂや収容局４０ａ、４０ｂ間の専用回線などの通信経路上に不具合があると判定する。

この場合、リクエスト処理部４０２は、回線業者情報テーブル８００に基づいて、専用回線の業者宛に不具合がある旨のメッセージを送信する。

図１５は、回線業者情報テーブル８００の一例を示す図である。回線業者情報テーブル８００は、ユーザＩＤに対応する専用回線業者の情報が設定されている。本実施形態においては、Ｗｅｂサーバ２０は、利用者端末１０以外の端末に接続されており、また、利用者端末１０を複数のユーザＩＤでログインする場合も考えられる。そのため、回線業者情報テーブル８００には、ユーザＩＤ（例えば、zzzzz）に対応づけて、専用回線業者名（例えば、AAAAA）と、サポートメールアドレス（例えば、info@AAAAA.xx.yy）と、サポート電話番号（xx-xxxx-xxxx）と、を含む複数の項目の情報が予め設定されている。

リクエスト処理部４０２は、ＨＴＴＰリクエストヘッダ行のパラメタ（例えば、user-account）のパラメタ値から、ユーザＩＤを取得する。リクエスト処理部４０２は、取得したユーザＩＤに基づいて、図１５の回線業者情報テーブル８００を参照して、対象となるユーザＩＤが契約している専用回線業者名（例えば、AAAAA）と、サポートメールアドレス（例えば、info@AAAAA.xx.yy）を取得する。

リクエスト処理部４０２は、取得したサポートメールアドレス宛に、エラーがある旨のメッセージを送信する。具体的には、リクエスト処理部４０２は、メッセージの本文に、取得したユーザＩＤを入力するとともに、当該ユーザＩＤが契約している回線に障害の疑いがあり、調査を依頼する旨を入力したメッセージを作成する。リクエスト処理部４０２は、作成したメッセージを専用回線業者宛に送信する。

エラー情報詳細テーブル７０２内から取得した情報と、ＨＴＴＰリクエストヘッダ行のパラメタ値の情報と、が一致する場合は、リクエスト処理部４０２は、通信経路上において情報の棄損は行われなかったと判定する。すなわち、収容局４０ａ、４０ｂ間の専用回線などの通信経路上の不具合ではない可能性が高いと判定される。すなわち、この場合は、利用者端末１０やＷｅｂサーバ２０を含む通信システム１の設定に不具合が発生していることがわかる。この場合、リクエスト処理部４０２は、通信システム１のシステムエンジニア宛に通信システム１に障害が発生している旨のメッセージを送信する。メッセージを見たエンジニアは、即座に通信システム１に対する対応を行うことができる。
一方、エラー情報詳細テーブル７０２内から取得した情報と、ＨＴＴＰリクエストヘッダ行のパラメタ値の情報と、が一致しない場合は、リクエスト処理部４０２は、通信経路上において情報の棄損が行われたと判定する。すなわち、収容局４０ａ、４０ｂ間の専用回線などの通信経路上の不具合の可能性が高いと判定される。この場合、リクエスト処理部４０２は、通信システム１のシステムエンジニア宛に通信経路上の不具合（回線障害）が発生している旨のメッセージを送信してもよい。

また、更に、リクエスト処理部４０２は、回線障害のエラーページへのリダイレクトＵＲＬを含むＨＴＴＰレスポンスを作成する。そして、レスポンス送信部４０３は、作成したＨＴＴＰレスポンスをブラウザ１２へ送信する。ブラウザ１２は、回線障害のエラーページを表示する。ブラウザ１２を通じてエラーページを見た利用者は、回線障害のエラーが発生していることを認識することができる。

次に、図１６を参照して、通信システム１におけるローカルプロキシ１１を介して接続されるブラウザ１２と、Ｗｅｂサーバ２０と、の間においてエラーが発生していない通常時の通信処理の手順について説明する。図１６は、実施形態に係る通信システム１における通常時の通信処理の手順の一例を示すシーケンスチャートである。通信システム１における通常時の通信処理は、利用者端末通信プログラムおよびＷｅｂサーバ通信プログラムにより実行される。

ブラウザ１２は、入力画面１０００に表示されている各入力項目に対する利用者からのデータ入力を受け付けると、ローカルプロキシ１１を介してＷｅｂサーバ２０にＨＴＴＰリクエストを送信する（ステップＳ１０１）。

ローカルプロキシ１１のリクエスト情報処理部３０１は、ブラウザ１２からＷｅｂサーバ２０へ送信されたＨＴＴＰリクエストをキャプチャする。そして、リクエスト情報処理部３０１は、キャプチャしたＨＴＴＰリクエストの情報を直列化した文字列の情報に変換して情報保存領域５０１に保存する（ステップＳ１０２）。リクエスト中継部３０２は、キャプチャしたＨＴＴＰリクエストをＷｅｂサーバ２０へ送信する（ステップＳ１０３）。

Ｗｅｂサーバ２０のリクエスト受信部４０１は、ブラウザ１２から送信されたＨＴＴＰリクエストを受信する。そして、リクエスト処理部４０２は、受信したＨＴＴＰリクエストの情報を書類情報テーブル６００に格納する（ステップＳ１０４）。

リクエスト処理部４０２は、ＨＴＴＰリクエストボディ行に、書類情報テーブル６００の各項目のうち、必須項目が抜けているか否かを判定する。必須項目が抜けていない場合には、リクエスト処理部４０２は、Ｗｅｂサーバ２０で受信したＨＴＴＰリクエストの内容は正常であると判定する。受信したＨＴＴＰリクエストの内容は正常である場合には、レスポンス送信部４０３は、ＨＴＴＰリクエストが正常に行われたことを示す登録完了画面を表示するＨＴＴＰレスポンスをブラウザ１２へ送信する（ステップＳ１０５）。

ローカルプロキシ１１のレスポンス中継部３０３は、Ｗｅｂサーバ２０から送信されたＨＴＴＰレスポンスを中継して、ブラウザ１２へ送信する（ステップＳ１０６）。ローカルプロキシ１１を介してＷｅｂサーバ２０からＨＴＴＰレスポンスが戻ってくると、ブラウザ１２は、レスポンス結果の登録完了画面のＷｅｂページを表示する（ステップＳ１０７）。

次に、図１７を参照して、通信システム１におけるローカルプロキシ１１を介して接続されるブラウザ１２と、Ｗｅｂサーバ２０と、の間においてエラーが発生している異常時の通信処理の手順について説明する。図１７は、実施形態に係る通信システム１における異常時の通信処理の手順の一例を示すシーケンスチャートである。通信システム１における異常時の通信処理は、利用者端末通信プログラムおよびＷｅｂサーバ通信プログラムにより実行される。

ブラウザ１２は、入力画面１０００に表示されている各入力項目に対する利用者からのデータ入力を受け付けると、ローカルプロキシ１１を介してＷｅｂサーバ２０にＨＴＴＰリクエストを送信する（ステップＳ２０１）。

ローカルプロキシ１１のリクエスト情報処理部３０１は、ブラウザ１２からＷｅｂサーバ２０へ送信されたＨＴＴＰリクエストをキャプチャする。そして、リクエスト情報処理部３０１は、キャプチャしたＨＴＴＰリクエストの情報を直列化した文字列の情報に変換して情報保存領域５０１に保存する（ステップＳ２０２）。リクエスト中継部３０２は、キャプチャしたＨＴＴＰリクエストをＷｅｂサーバ２０へ送信する（ステップＳ２０３）。

Ｗｅｂサーバ２０のリクエスト受信部４０１は、ブラウザ１２から送信されたＨＴＴＰリクエストを受信する。そして、リクエスト処理部４０２は、受信したＨＴＴＰリクエストの情報を書類情報テーブル６００に格納する（ステップＳ２０４）。

リクエスト処理部４０２は、ＨＴＴＰリクエストボディ行に、書類情報テーブル６００の各項目のうち、必須項目が抜けているか否かを判定する。必須項目が抜けている場合には、リクエスト処理部４０２は、Ｗｅｂサーバ２０で受信したＨＴＴＰリクエストの内容は異常であると判定する（ステップＳ２０５）。

リクエスト処理部４０２は、異常であると判定されたＨＴＴＰリクエストの情報をエラー情報テーブル７００に格納する（ステップＳ２０６）。この処理では、リクエスト処理部４０２は、Ｗｅｂサーバ２０で受信したＨＴＴＰリクエストの内容が異常であると判定された場合に、そのＨＴＴＰリクエストの情報の内容をエラー情報インデックステーブル７０１と、エラー情報詳細テーブル７０２と、に格納する。

受信したＨＴＴＰリクエストが異常である場合には、レスポンス送信部４０３は、エラーページへのリダイレクト指示のＨＴＴＰレスポンスをブラウザ１２へ送信する（ステップＳ２０７）。

ローカルプロキシ１１のレスポンス中継部３０３は、Ｗｅｂサーバ２０から送信されたＨＴＴＰレスポンスを中継して、ブラウザ１２へ送信する（ステップＳ２０８）。

エラーページへのリダイレクト指示のＨＴＴＰレスポンスが戻ってくると、ブラウザ１２は、特定のエラーページとして“www.xxx/error.html”へのＨＴＴＰリクエスト作成し、このＨＴＴＰリクエストをWebサーバ２０へ送信する（ステップＳ２０９）。

ローカルプロキシ１１のリクエスト情報処理部３０１は、前回のＨＴＴＰリクエストの情報を情報保存領域５０１に保存されている文字列の情報から抽出する。そして、リクエスト情報処理部３０１は、抽出した文字列の情報を今回のＨＴＴＰリクエストのＨＴＴＰリクエストヘッダ行へ付加して送信する（ステップＳ２１０）。

リクエスト処理部４０２は、エラー情報詳細テーブル７０２内から取得した情報と、ＨＴＴＰリクエストヘッダ行のパラメタ値の情報と、が一致するかを判断する。リクエスト処理部４０２は、エラー情報詳細テーブル７０２内から取得した情報と、ＨＴＴＰリクエストヘッダ行のパラメタ値の情報と、が一致しない場合には、通信経路上において情報の棄損が発生したと判定する（ステップＳ２１１）。リクエスト処理部４０２は、専用回線の業者宛に回線にエラーがある旨のメッセージを送信したり、通信システム１のシステムエンジニア宛に通信経路上の不具合（回線障害）が発生している旨のメッセージを送信してもよい。また、リクエスト処理部４０２は、エラー情報詳細テーブル７０２内から取得した情報と、ＨＴＴＰリクエストヘッダ行のパラメタ値の情報と、が一致する場合には、通信システム１に不具合が発生していると判定する。

リクエスト処理部４０２は、回線障害のエラーページへのリダイレクトＵＲＬを含むＨＴＴＰレスポンスを作成する。そして、レスポンス送信部４０３は、エラーページへのＨＴＴＰレスポンスをブラウザ１２へ送信する（ステップＳ２１２）。

ローカルプロキシ１１のレスポンス中継部３０３は、Ｗｅｂサーバ２０から送信されたＨＴＴＰレスポンスを中継して、ブラウザ１２へ送信する（ステップＳ２１３）。ブラウザ１２は、回線障害のエラーページを表示する（ステップＳ２１４）。

以上のことから、収容局４０ａ、４０ｂ間の専用回線などに問題があり、通信経路上において情報の棄損が発生したのか、または、利用者端末１０やＷｅｂサーバ２０の通信システム１上の問題なのか判断することができる。これにより、通信システムにおける障害の発生元の特定を容易に行うことができる。

以上、本発明の実施の形態を、図面を参照しながら説明してきたが、本発明が適用される画像表示装置は、前述の実施の形態に限定されない。

上記実施形態においては、利用者端末１０と、Ｗｅｂサーバ２０と、は専用回線を通じて接続しているがこの限りではない。例えば、インターネット回線を通じて接続することもできる。

上記実施形態においては、通信システム１は、ルータ３０ａ、３０ｂを採用しているがこれに限られるものではなく、例えば、ルータ３０ａ、３０ｂの代わりにスイッチを使用することもできる。

尚、本発明は上述した実施形態そのままに限定されるものではなく、実施段階でのその要旨を逸脱しない範囲で構成要素を変形して具体化することができる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成することができる。例えば、実施形態に示される全構成要素を適宜組み合わせても良い。更に、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。このような、発明の趣旨を逸脱しない範囲内において種々の変形や応用が可能であることはもちろんである。

１ 通信システム
１０ 利用者端末
１１ ローカルプロキシ
１２ ブラウザ
１３ 記録部
２０ Ｗｅｂサーバ
３０ａ、３０ｂ ルータ
４０ｂ、４０ａ 収容局
１０１ ＣＰＵ
１０２ ＲＡＭ
１０３ 通信インタフェース（Ｉ／Ｆ）
１０４ 入出力インタフェース（Ｉ／Ｆ）
１０５ バス
２０１ ＣＰＵ
２０２ ＲＡＭ
２０３ 通信インタフェース（Ｉ／Ｆ）
２０４ 記録部
２０５ バス
３０１ リクエスト情報処理部
３０２ リクエスト中継部
３０３ レスポンス中継部
４０１ リクエスト受信部
４０２ リクエスト処理部
４０３ レスポンス送信部
５０１ 情報保存領域
５０２ Ｗｅｂ情報格納領域
６００ 書類情報テーブル
７００ エラー情報テーブル
７０１ エラー情報インデックステーブル
７０２ エラー情報詳細テーブル
８００ 回線業者情報テーブル
９００ リクエスト情報格納領域
１０００ 入力画面
１００１ 提出ボタン

Claims (10)

1. プロキシを介して、利用者端末に導入されたブラウザとＷｅｂサーバとの間でＨＴＴＰ通信を行う通信システムにおいて、
   前記プロキシは、
   前記利用者端末のブラウザから送信されたＨＴＴＰリクエストを前記Ｗｅｂサーバへ送信するリクエスト中継部と、
   前記Ｗｅｂサーバへ送信するＨＴＴＰリクエストの情報を保存するリクエスト情報処理部と、
   を備え、
   前記Ｗｅｂサーバは、
   受信した前記ＨＴＴＰリクエストの内容が正常であるか否かを判定するリクエスト処理部と、
   前記利用者端末のブラウザへ前記ＨＴＴＰリクエストに対するレスポンスを送信するレスポンス送信部と、
   を備え、
   前記レスポンス送信部は、前記リクエスト処理部により前記ＨＴＴＰリクエストの内容が異常であると判定された場合、特定のページへのリダイレクトを指示するレスポンスを前記利用者端末のブラウザに送信し、
   前記リクエスト情報処理部は、前記利用者端末のブラウザから前記Ｗｅｂサーバへ送信されるＨＴＴＰリクエストが、前記レスポンスに対応する前記特定のページに対するＨＴＴＰリクエストである場合、前記リクエスト情報処理部が保存した前記ＨＴＴＰリクエストのうち、前回のＨＴＴＰリクエストの情報を前記特定のページに対するＨＴＴＰリクエストに付加し、
   前記リクエスト中継部は、前回のＨＴＴＰリクエストの情報を付加した前記ＨＴＴＰリクエストを前記Ｗｅｂサーバへ送信する
   ことを特徴とする通信システム。
2. 前記リクエスト処理部は、異常であると判定されたＨＴＴＰリクエストの情報を格納し、前記格納された前記ＨＴＴＰリクエストの情報と、前記特定のページへのリクエストＵＲＬが含まれるＨＴＴＰリクエストの情報と、を比較する。
   ことを特徴とする請求項１に記載の通信システム。
3. 前記リクエスト処理部は、エラー情報テーブル内から取得した情報と、前記ＨＴＴＰリクエストのＨＴＴＰリクエストヘッダ行のパラメタ値の情報と、が一致するかを判断し、前記エラー情報テーブル内から取得した情報と、前記ＨＴＴＰリクエストのＨＴＴＰリクエストヘッダ行のパラメタ値の情報と、が一致しない場合には、通信経路上において情報の棄損が発生したと判定する
   ことを特徴とする請求項１または請求項２に記載の通信システム。
4. 書類情報テーブルは、複数の項目が格納され、
   前記リクエスト処理部は、受信した前記ＨＴＴＰリクエストに、前記書類情報テーブルに格納された各項目のうち、必須項目のすべての項目が存在するか否かに応じて、前記ＨＴＴＰリクエストの内容が正常であるか否かの判定を行う
   ことを特徴とする請求項１または請求項２に記載の通信システム。
5. 前記前回のＨＴＴＰリクエストは、同一セッション上のＨＴＴＰリクエストである
   ことを特徴とする請求項１乃至４のうち何れか１項に記載の通信システム。
6. 前記特定のページは、利用者にエラーであることを示すエラーページである
   ことを特徴とする請求項１乃至５のうち何れか１項に記載の通信システム。
7. 通信システム上で、Ｗｅｂサーバと、ＨＴＴＰ通信を行う利用者端末のコンピュータを、
   利用者端末に導入されたブラウザから送信されたＨＴＴＰリクエストを前記Ｗｅｂサーバへ送信するリクエスト中継手段、
   前記Ｗｅｂサーバへ送信するＨＴＴＰリクエストの情報を保存するリクエスト情報処理手段、
   として機能させ、
   前記リクエスト情報処理手段は、前記ブラウザから前記Ｗｅｂサーバへ送信されるＨＴＴＰリクエストが、前記Ｗｅｂサーバが受信したＨＴＴＰリクエストが異常である場合に送信されるＨＴＴＰレスポンスに対応する特定のページに対するＨＴＴＰリクエストである場合、前記保存した前記ＨＴＴＰリクエストのうち、前回のＨＴＴＰリクエストの情報を前記特定のページに対するＨＴＴＰリクエストに付加し、
   前記リクエスト中継手段は、前回のＨＴＴＰリクエストの情報を付加した前記ＨＴＴＰリクエストを前記Ｗｅｂサーバへ送信する
   ことを特徴とする利用者端末通信プログラム。
8. 通信システム上で、利用者端末に導入されたプロキシを介して、ＨＴＴＰ通信を行うＷｅｂサーバのコンピュータを、
   前記利用者端末に導入されたブラウザから送信されたＨＴＴＰリクエストを受信した内容が正常であるか否かを判定するエラー処理手段、
   前記利用者端末のブラウザへ前記ＨＴＴＰリクエストに対するレスポンスを送信するレスポンス送信手段、
   として機能させ、
   前記レスポンス送信手段は、前記ＨＴＴＰリクエストの内容が異常であると判定された場合、特定のページへのリダイレクトを指示するレスポンスを前記利用者端末のブラウザに送信し、
   前記エラー処理手段は、前記利用者端末に導入されたプロキシから、前記レスポンスに対応する前記特定のページに対するＨＴＴＰリクエストに前回のＨＴＴＰリクエストの情報を付加したＨＴＴＰリクエストを受信した場合には、異常であると判定されたＨＴＴＰリクエストの情報が格納されたエラー情報テーブルに格納されたＨＴＴＰリクエストの情報と、前記特定のページに対するＨＴＴＰリクエストの情報と、を比較する
   ことを特徴とするＷｅｂサーバ通信プログラム。
9. 通信システム上で、Ｗｅｂサーバと、ＨＴＴＰ通信を行う利用者端末であって、
   前記Ｗｅｂサーバと通信を行うブラウザと、
   前記ブラウザとＷｅｂサーバとの間でＨＴＴＰ通信を中継するプロキシと、
   を備え、
   前記プロキシは、
   前記ブラウザから送信されたＨＴＴＰリクエストを前記Ｗｅｂサーバへ送信するリクエスト中継部と、
   前記Ｗｅｂサーバへ送信するＨＴＴＰリクエストの情報を保存するリクエスト情報処理部と、
   を備え、
   前記リクエスト情報処理部は、前記ブラウザから前記Ｗｅｂサーバへ送信されるＨＴＴＰリクエストが、前記Ｗｅｂサーバが受信したＨＴＴＰリクエストが異常である場合に送信されるＨＴＴＰレスポンスに対応する特定のページに対するＨＴＴＰリクエストである場合、前記リクエスト情報処理部が保存した前記ＨＴＴＰリクエストのうち、前回のＨＴＴＰリクエストの情報を前記特定のページに対するＨＴＴＰリクエストに付加し、
   前記リクエスト中継部は、前回のＨＴＴＰリクエストの情報を付加した前記ＨＴＴＰリクエストを前記Ｗｅｂサーバへ送信する
   ことを特徴とする利用者端末。
10. 通信システム上で、利用者端末に導入されたプロキシを介して、ＨＴＴＰ通信を行うＷｅｂサーバであって、
    前記利用者端末に導入されたブラウザから送信されたＨＴＴＰリクエストを受信した内容が正常であるか否かを判定するリクエスト処理部と、
    前記利用者端末のブラウザへ前記ＨＴＴＰリクエストに対するレスポンスを送信するレスポンス送信部と、
    を備え、
    前記レスポンス送信部は、前記リクエスト処理部により前記ＨＴＴＰリクエストの内容が異常であると判定された場合、特定のページへのリダイレクトを指示するレスポンスを前記利用者端末のブラウザに送信し、
    前記リクエスト処理部は、前記利用者端末に導入されたプロキシから、前記レスポンスに対応する前記特定のページに対するＨＴＴＰリクエストに前回のＨＴＴＰリクエストの情報を付加したＨＴＴＰリクエストを受信した場合には、異常であると判定されたＨＴＴＰリクエストの情報が格納されたエラー情報テーブルに格納されたＨＴＴＰリクエストの情報と、前記特定のページに対するＨＴＴＰリクエストの情報と、を比較する
    ことを特徴とするＷｅｂサーバ。

Images