JP5536129B2 - ルータ及びウェブサイトへの再接続方法 - Google Patents

Description

本発明は、ウェブサイトへの再接続を自動的に行うルータ及びウェブサイトへの再接続方法に関する。

一般に、複数のウェブページ（Web page）を一纏めにして公開するウェブサイト（Web site）には、端末に組み込まれたウェブブラウザ（Web browser）を使用してアクセスするようになっている。ウェブブラウザを使用してウェブサイトにアクセスする場合、通信ネットワーク或いはウェブサーバ（Web server）が障害状態にあると、その時点ではウェブサイトに接続することが出来ず、ウェブページの閲覧は出来ない。従って、当該ウェブサイトにアクセスしたいユーザは、ウェブブラウザを使用し、時間をおいてウェブサイトへの再接続を試みることが必要となる。そして、この再接続の操作は、障害状態がいつ復旧するか不明であるため、当該ウェブサイトに接続できるまで行う必要がある。そのため、ユーザにとって非常に煩雑な作業となってしまう、という問題がある。

このような問題を解消するために、サーバ等の障害の復旧をクライアント（ユーザが使用する端末）に通知する装置を提案しているものがある（例えば、特許文献１参照。）。

上述した特許文献１「サーバ障害復旧通知方法及び装置」には以下の記載がなされている。

すなわち、サーバ障害復旧通知装置のサーバ障害検出部が、障害のためサーバにアクセスを試みてアクセスできなかったクライアントを検出する。そして、サーバ復旧検出部が障害復旧を検出し、サーバ復旧通知部が、アクセスできなかったクライアントに障害復旧を通知する。また、サーバ障害復旧通知装置をルータに実装し、サーバ障害検出部は、ルータのＩＣＭＰ（Internet Control Message Protocol：インターネット制御通知プロトコル）の宛先到達不能メッセージに基づき、アクセスできなかったクライアントを検出する。又は、クライアントからサーバ宛のＩＰパケットに対する応答ＩＰパケットが無いとき、サーバが障害発生中であると判定することで、アクセスできなかったクライアントを検出する。

このことにより、サーバ等の障害の復旧をクライアントに通知することができるようになる、としている。

特開２００３−０５０７５２号公報（第３〜１９頁、図１〜３７）

上述した特許文献１に記載の手法においては、サーバ障害復旧通知装置をルータに実装するようにしている。そして、サーバ障害復旧通知装置のサーバ復旧検出部は、ＳＮＭＰ（Simple Network Management Protocol：簡易ネットワーク管理プロトコル）マネージャ機能を有している。このＳＮＭＰマネージャ機能が、ＳＮＭＰエージェント機能を有するサーバからのトラップメッセージを、障害が復旧したことを示す信号として受信するようになっている。しかし、通常、ＳＮＭＰマネージャを利用するのはネットワーク管理者のみである。従って、特許文献１に記載の手法は、ネットワーク管理者しか利用できない、という課題を有している。

本発明は上述した課題を解決するためになされたものである。従って、本発明の目的は、
ネットワーク管理者でなくとも、ウェブサーバなどの障害の復旧を自動的に検知し、ウェブサイトに再接続することを可能とする、ルータ及びウェブサイトへの再接続方法、を提供することにある。

本発明のルータは、端末と接続するＬＡＮインタフェースと、ウェブサイトを形成するウェブサーバと接続するＷＡＮインタフェースと、制御手段を備えている。そして、制御手段は、端末からウェブサイト宛の第１のＨＴＴＰリクエストを受信した場合に前記第１のＨＴＴＰリクエストを前記ウェブサイトへ転送する。そして、前記転送の結果受信したＨＴＴＰレスポンスがエラーの発生を示すレスポンスであった場合、或いは、所定の待ち時間内に前記転送の結果としてのＨＴＴＰレスポンスを受信できない場合、以下を行う。すなわち、前記端末と前記ウェブサイトに関する情報をアクセス先情報として記憶する。次に、前記アクセス先情報に基づく第２のＨＴＴＰリクエストを生成し所定の時間間隔で、かつ、所定の回数だけ前記ウェブサイトへ送信する。ここで、前記ウェブサイトから前記第２のＨＴＴＰリクエストが成功した旨のＨＴＴＰレスポンスを受信した際、前記ウェブサイトの前記エラーが解消した旨を前記端末に通知する、ようになっている。

本発明のウェブサイトへの再接続方法は、端末からウェブサイト宛の第１のＨＴＴＰリクエストを受信した場合に前記第１のＨＴＴＰリクエストをウェブサイトへ転送する。そして、前記転送の結果受信したＨＴＴＰレスポンスがエラーの発生を示すレスポンスであった場合、或いは、所定の待ち時間内に前記転送の結果としてのＨＴＴＰレスポンスを受信できない場合、以下を行う。すなわち、前記端末と前記ウェブサイトに関する情報をアクセス先情報として記憶する。次に、前記アクセス先情報に基づく第２のＨＴＴＰリクエストを生成し所定の時間間隔で、かつ、所定の回数だけ前記ウェブサイトへ送信する。送信の結果、前記ウェブサイトから前記第２のＨＴＴＰリクエストが成功した旨のＨＴＴＰレスポンスを受信した際、前記ウェブサイトの前記エラーが解消した旨を前記端末に通知する。

本発明によれば、ネットワーク管理者でなくとも、ウェブサーバなどの障害の復旧を自動的に検知し、ウェブサイトに再接続することが可能となる。

本発明のルータの概略構成を示すブロック図である。 本発明のルータの第１の実施形態を示すブロック図である。 ルータの記憶部が記憶する情報の一例を示す図である。 ＨＴＴＰレスポンスのステータスコードの一例を示す図である。 第１の実施形態の概略動作を示すシーケンスチャートである。 第１の実施形態の詳細動作を説明する第１のフローチャートである。 第１の実施形態の詳細動作を説明する第２のフローチャートである。 第１の実施形態の詳細動作を説明する第３のフローチャートである。 アクセス先情報の変更される様子を示す図である。 ルータが生成する通知画面の一例を示す図である。 第２の実施形態の設定情報を示す図である。 第２の実施形態の概略動作を示す第１のシーケンスチャートである。 第２の実施形態において記憶部が記憶する情報の一例を示す図である。 第２の実施形態の概略動作を示す第２のシーケンスチャートである。 本発明のルータの第３の実施形態を示すブロック図である。 第３の実施形態の概略動作を示すシーケンスチャートである。

次に、本発明の実施形態について図面を参照して説明する。
[第１の実施形態]
図１は、本発明のルータの概略構成を示すブロック図である。

図１に示すルータ（router）１００は、ＬＡＮ（Local Area Network：ラン）インタフェース１０、ＷＡＮ（Wide Area Network：ワン）インタフェース２０、制御部９０を備えている。ルータ１００は、通信速度が比較的低速なナローバンド（narrow band）で通信ネットワークに接続するルータでもよいし、広帯域のブロードバンド（broadband）で通信ネットワークに接続するブロードバンドルータであってもよい。

ＬＡＮインタフェース１０は、ＬＡＮ４００を介して端末２００と接続するインタフェースである。ＬＡＮインタフェース１０は、ＬＡＮ４００からパケット（packet）を受信すると制御部９０に送信し、制御部９０からパケットを受信するとＬＡＮ４００に送信する。

ＷＡＮインタフェース２０は、ＷＡＮ６００を介してウェブサーバ３００と接続するインタフェースである。ＷＡＮインタフェース２０は、ＷＡＮ６００からパケットを受信すると制御部９０に送信し、制御部９０からパケットを受信するとＷＡＮ６００に送信する。

制御部９０は、ルータ１００全体の動作制御を行う。制御部９０の詳細については、図２を参照して後述する。

図１に示すＬＡＮ４００は、ルータ１００と端末２００を通信接続するネットワークである。ＬＡＮ４００は、有線ＬＡＮであってもよいし、無線ＬＡＮであってもよい。

図１に示す端末２００は、パーソナルコンピュータ等の端末装置であり、ウェブサーバ３００にアクセスする機能が組み込まれている。

図１に示すＷＡＮ６００は、公衆回線、専用回線などにより構築される広域ネットワークであり、ルータ１００とウェブサーバ３００を通信接続する。なお、ＷＡＮ６００とルータ１００の接続は、有線接続であってもよいし、無線接続であってもよい。

図１に示すウェブサーバ３００は、ウェブサイト３１０を形成するサーバである。

次に、図１に示すルータの概略動作について説明する。

前提として、端末２００とウェブサーバ３００の通信プロトコルとしては、ＨＴＴＰ（ハイパーテキスト転送プロトコル）が使用される。ＨＴＴＰについては後述する。

そして、端末２００からウェブサーバ３００に対して要求を行う場合は、ＨＴＴＰリクエストを送信する。ＨＴＴＰリクエストを受信したウェブサーバ３００は、ＨＴＴＰレスポンスを端末２００に対して返送する。ここで、ＨＴＴＰレスポンスには、ＨＴＴＰリクエストが成功したか、或いは、ＨＴＴＰリクエスが失敗したかのステータスコードが付されている。

また、図１に示すルータは、前記したＨＴＴＰリクエスト、或いは、ＨＴＴＰレスポンスを監視している。

そして、本実施形態のルータ１００は、端末（２００）と接続するＬＡＮインタフェース（１０）と、ウェブサイト（３１０）を形成するウェブサーバ（３００）と接続するＷＡＮインタフェース（２０）と、を備えている。また、ルータ１００は、制御手段（制御部９０）を備えている。

そして、制御手段は、端末からウェブサイト宛の第１のＨＴＴＰリクエストを受信した場合に前記第１のＨＴＴＰリクエストを前記ウェブサイトへ転送する。そして、前記転送の結果受信したＨＴＴＰレスポンスがエラーの発生を示すレスポンスであった場合、或いは、所定の待ち時間内に前記転送の結果としてのＨＴＴＰレスポンスを受信できない場合、以下を行う。すなわち、前記端末と前記ウェブサイトに関する情報をアクセス先情報として記憶する。次に、前記アクセス先情報に基づく第２のＨＴＴＰリクエストを生成し所定の時間間隔で、かつ、所定の回数だけ前記ウェブサイトへ送信する。ここで、前記ウェブサイトから前記第２のＨＴＴＰリクエストが成功した旨のＨＴＴＰレスポンスを受信した際、前記ウェブサイトの前記エラーが解消した旨を前記端末に通知する、ようになっている。

従って、本実施形態によれば、ネットワーク管理者でなくとも、ウェブサーバなどの障害の復旧を自動的に検知し、ウェブサイトに再接続することが可能となる。

次に、図２を参照して、図１に示したルータ１００の詳細構成について説明する。

図２は、本発明のルータの第１の実施形態を示すブロック図である。

図２に示すルータ１００は、ＬＡＮインタフェース１０、ＷＡＮインタフェース２０、ルーティング部３０、ルータ装置機能部４０、記憶部５０を備えている。ここで、ルーティング部３０、ルータ装置機能部４０、記憶部５０は図１に示したルータ１００の制御部９０の詳細構成である。

ＬＡＮインタフェース１０とＷＡＮインタフェース２０は、図１に示したものと同一であるため、その説明を省略する。

ルーティング部３０は、ＬＡＮインタフェース１０から受信したパケットをＷＡＮインタフェース２０に送信し、ＷＡＮインタフェース２０から受信したパケットをＬＡＮインタフェース１０に送信する。ルーティング部３０は、特定の条件下においてはルータ装置機能部４０にパケットを送信し、ルータ装置機能部４０から送信されたパケットを受信し、ＬＡＮインタフェース１０或いはＷＡＮインタフェース２０に送信する。

ルータ装置機能部４０は、ルーティング部３０から受信したパケットに対して特定の処理を行い、ルーティング部３０に送信する。ルータ装置機能部４０は、特定の条件下においてはパケットを生成してルーティング部３０に送信する。ルータ装置機能部４０は、必要な情報を記憶部５０に記憶させ、或いは、必要な情報を記憶部５０から読み出して使用する。

記憶部５０は、ルータ装置機能部４０が必要とする情報を記憶する。記憶部５０が記憶する情報の具体例については、図３を参照して後述する。

図２に示すＬＡＮ４００は、ルータ１００と端末２００を通信接続するネットワークである。

図２に示す端末２００は、パーソナルコンピュータ等の端末装置であり、ウェブブラウザ２１０が組み込まれている。本実施形態においては、複数の端末２００（端末２００−１、・・・、端末２００−ｎ）がＬＡＮ４００に接続されている。端末２００は、ウェブブラウザ２１０を用い、ルータ１００を介してウェブサーバ３００にアクセスする。そして、ウェブサーバ３００からウェブページが返送された場合は、当該ウェブページを図示しない表示装置に表示する。

図２に示すインターネット５００は、コンピュータネットワーク、電話交換網、移動体通信網、企業内イントラネット（Intranet）などが相互に接続された通信網であり、ルータ１００とウェブサーバ３００を通信接続する。なお、インターネット５００は、図１に示したＷＡＮ６００である。

図２に示すウェブサーバ３００は、ウェブサイト３１０を形成するサーバである。本実施形態においては、複数のウェブサーバ３００（ウェブサーバ３００−１、・・・、ウェブサーバ３００−ｍ）がインターネット５００に接続されている。

次に、図３を参照して、ルータ１００の記憶部５０が記憶する情報について説明する。

図３は、ルータの記憶部が記憶する情報の一例を示す図である。

図３において、記憶部５０には、設定情報５１、アクセス先情報５２が記憶されるようになっている。

設定情報５１は、端末２００からウェブサイト３１０にアクセスし、通信ネットワーク（インターネット５００）、或いは、ウェブサーバ３００、の障害等によりアクセスできなかった場合、当該ウェブサイト３１０に再接続する際の条件を設定する。すなわち、設定情報５１には、再接続する間隔（５１−１行、５１−１１列）及び再接続する回数（５１−１行、５１−１２列）が設定される。一例として、再接続する間隔が「１０分」（５１−２行、５１−１１列）、再接続する回数が「６回」（５１−２行、５１−１２列）と設定されている。

アクセス先情報５２は、端末２００からのウェブサイト３１０へのアクセスができなかった場合、アクセスしようとした端末２００やアクセス先ウェブサイト３１０の情報などを記憶する。すなわち、アクセス先情報５２は、アクセス先情報５２のＮｏ．（５２−１行、５２−１１列）、端末のＩＰ（Internet Protocol：アイピー）アドレス（５２−１行、５２−１２列）を記憶する。また、アクセス先ウェブサイト３１０のＵＲＬ（Uniform Resource Locator：ユーアールエル）すなわちアクセス先ＵＲＬ（５２−１行、５２−１３列）も記憶する。さらに、残り再接続回数（５２−１行、５２−１４列）、アクセス可否（５２−１行、５２−１５列）も記憶する。一例として、Ｎｏ．が「１」（５２−２行、５２−１１列）の行には、端末のＩＰアドレスが「１９２．１６８．０．１」（５２−２行、５２−１２列）、アクセス先ＵＲＬが「ｈｔｔｐ：／／□□□／△△△／」（５２−２行、５２−１３列）が記憶されている。また当該行の続きとして、残り再接続回数が「６回」（５２−２行、５２−１４列）、アクセス可否が「×」（５２−２行、５２−１５列）が記憶されている。ここで、アクセス可否が「×」は、アクセスできない、ことを示し、アクセスできる、の場合は「○」が記憶されるようになっている。

次に、図４以降を参照して、本実施形態の動作について説明する。

ここで先ず、本実施形態の、端末２００とウェブサーバ３００間の通信を行うために用いられる通信プロトコル、すなわち、ＨＴＴＰ（Hypertext Transfer Protocol：ハイパーテキスト転送プロトコル）の概略につき説明を行うものとする。

周知のように、ＨＴＴＰは、ファイルを提供するサーバ（本実施形態のウェブサーバ３００に相当）と、ファイルを要求するクライアント（本実施形態の端末２００に相当）の間でファイル転送を行う手順を定めたものである。

ＨＴＴＰには、クライアントからサーバに要求を出すためのＨＴＴＰリクエストと、サーバからクライアントに応答するためのＨＴＴＰレスポンスとがある。

ＨＴＴＰリクエストの一例として、ＧＥＴリクエストやＰＯＳＴリクエストを挙げることができる。ＧＥＴリクエストは、クライアントがファイルを貰うためのリクエストであり、ＰＯＳＴリクエストは、クライアントからファイルを送ってサーバ内のウェブページに書き込むためのリクエストである。

また、ＨＴＴＰレスポンスは、ＨＴＴＰリクエストに応じたＨＴＭＬ（Hyper Text Markup Language：エイチティエムエル）ファイルなどを応答データとして返すものである。ＨＴＴＰレスポンスには、応答データに加えて、ＨＴＴＰリクエストに対するサーバの処理結果を表す３桁の番号としてのステータスコードが付加されている。

ここで、図４を参照して、ＨＴＴＰレスポンスのステータスコードについて説明する。

図４は、ＨＴＴＰレスポンスのステータスコードの一例を示す図である。

図４において、例えば（３）の行に示すように、２００番台のステータスコードの行には、メッセージが「Ｓｕｃｃｅｓｓ」であり、その解説として「成功」と記載されている。これは、サーバがＨＴＴＰリクエストを処理できたことを伝える「成功」を意味している。また、（７）の行に示すように、４００番台のステータスコードの行には、メッセージが「Ｃｌｉｅｎｔ Ｅｒｒｏｒ」であり、その解説として「クライアントエラー」と記載されている。これは、ＨＴＴＰリクエストに問題があり、サーバが処理できなかったことを伝える「クライアントエラー」を意味している。同様に、（１０）の行に示す５００番台は、サーバ側に問題があって処理できなかったことを伝える「サーバエラー」を意味するようになっている。

具体的には、図４の（４）行に示す「２００」のステータスコードは、ＨＴＴＰリクエストが「成功」したことを意味している。また、（８）行に示す「４０４」のステータスコードは、クライアントエラーであり、その詳細は、「要求されたリソースが見つからなかった」を意味している。さらに、（９）行に示す「４０８」のステータスコードは、クライアントエラーであり、その詳細は、「クライアントは、サーバの待ち時間内にＨＴＴＰリクエストを発行しなかった」を意味するものである。

またさらに、図４の（１１）行に示す「５００」のステータスコードは、サーバエラーであり、その詳細は、「予期せぬエラーが原因でＨＴＴＰリクエストを実行できなかった」を意味している。また、（１２）行に示す「５０３」のステータスコードは、サーバエラーであり、その詳細は、「過負荷やメンテナンスのため、一時的にＨＴＴＰリクエストを実行できない」を意味するものである。

次に、図５を参照して、本実施形態の概略動作について説明する。

図５は、第１の実施形態の概略動作を示すシーケンスチャートである。なお、図５においては、一例として、端末２００−１がウェブサーバ３００−１のウェブサイト３１０−１へアクセスする場合について説明するものとする。

図５において、端末２００−１は、ウェブサーバ３００−１のウェブサイト３１０−１にアクセスするために、ＨＴＴＰリクエストを送出する（図５のステップＳ１１）。すると、ルータ１００は、当該ＨＴＴＰリクエストをウェブサーバ３００−１に転送する（ステップＳ１２）。

ＨＴＴＰリクエストを受信したウェブサーバ３００−１は、ＨＴＴＰレスポンスを返送する。このときのＨＴＴＰレスポンスが、ＨＴＴＰエラーレスポンスであり、そのステータスコードが「５０３」であったものとする（ステップＳ１３）。なお、以降の説明において、ＨＴＴＰレスポンスの記載を、以下のようにするものとする。すなわち、「成功」を意味する場合は、「ＨＴＴＰ成功レスポンス（“２００”）」の様に記載し、ステータスコードは「“”」で囲み括弧内に記述するものとする。また、クライアントエラーの内のステータスコードが“４０４”や“４０８”のもの、或いは、サーバエラーの内のステータスコードが“５００”や“５０３”のものである場合は、「ＨＴＴＰエラーレスポンス（“５０３”）」の様に記載する。そして、ステータスコードは「“”」で囲み括弧内に記述するものとする。

サーバエラーを意味するＨＴＴＰエラーレスポンス（“５０３”）を受信したルータ１００は、当該ＨＴＴＰリクエストを送出した端末２００−１やアクセス先ウェブサイト３１０−１の情報などを、アクセス先情報５２としてルータ１００の記憶部５０に記憶する（ステップＳ１４）。そして、ルータ１００は、当該ＨＴＴＰエラーレスポンス（“５０３”）を端末２００−１に転送する（ステップＳ１５）。

次に、アクセス先情報５２を記憶したルータ１００は、記憶部５０に記憶したアクセス先情報５２に基づいて、ＨＴＴＰリクエストを生成する（ステップＳ１６）。ここで生成するＨＴＴＰリクエストは、ステップＳ１１で端末２００−１が送出したＨＴＴＰリクエストを代替するものである。そして、ルータ１００は、生成したＨＴＴＰリクエストをウェブサーバ３００−１に送信する（ステップＳ１７）。ここで送信するＨＴＴＰリクエストは、「サーバエラー」の状態であったウェブサーバ３００−１が復旧したかを確認する為に送信するものであり、端末２００−１から新たに送出されるＨＴＴＰリクエストを転送するものではない。この時点で、端末２００−１のユーザは、ウェブサーバ３００−１が「サーバエラー」の状態であることを知っているため、他の作業を行っていてもよい。

ＨＴＴＰリクエストを受信したウェブサーバ３００−１は、ＨＴＴＰレスポンスを返送する。このときのＨＴＴＰレスポンスが、ステップＳ１３と同一のＨＴＴＰエラーレスポンス（“５０３”）であったものとする（ステップＳ１８）。

ＨＴＴＰエラーレスポンス（“５０３”）を再度受信したルータ１００は、ステップＳ１６と同様に、再度、ＨＴＴＰリクエストを生成し（ステップＳ１９）、生成したＨＴＴＰリクエストをウェブサーバ３００−１に送信する（ステップＳ２０）。

ステップＳ２０のＨＴＴＰリクエストを受信したウェブサーバ３００−１は、ＨＴＴＰレスポンスを返送する。このときのＨＴＴＰレスポンスは、ＨＴＴＰ成功レスポンス（“２００”）であったものとする（ステップＳ２１）。このＨＴＴＰ成功レスポンス（“２００”）は、サーバエラーの状態だったウェブサーバ３００−１が復旧したことを意味するものである。

ＨＴＴＰ成功レスポンス（“２００”）を受信したルータ１００は、ステップＳ１６或いはステップＳ１９で行っていた動作、すなわち、アクセス先情報５２に基づいてＨＴＴＰリクエストを生成する動作、を終了する。そして、端末２００−１からの次のＨＴＴＰリクエストを受信するのを待つ状態となる（ステップＳ２２）。

端末２００−１では、ウェブサイト３１０−１へのアクセスは中断しており、代わりに、ウェブサイト３１０−２へのアクセスを行おうとしたものとする。そして、端末２００−１からは、ウェブサイト３１０−２へアクセスするためのＨＴＴＰリクエスト（ウェブサイト３１０−２宛）を送出する（図５のステップＳ３１）。

ＨＴＴＰリクエスト（ウェブサイト３１０−２宛）を受信したルータ１００は、ステップＳ１１で受信したウェブサイト３１０−１宛のＨＴＴＰリクエストとは異なるウェブサイト３１０−２へのアクセスであることを検知する。そこで、ルータ１００は、端末２００−１に対する通知画面を生成する（ステップＳ３２）。ここで生成する通知画面は、以前アクセスしようとしたが出来なかったウェブサイト３１０−１が復旧している旨を通知する画面である。そして、生成した通知画面を、ＨＴＴＰ成功レスポンスとして端末２００−１に送信する（ステップＳ３３）。

通知画面を受信した端末２００−１で、ウェブサイト３１０−２ではなくウェブサイト３１０−１へアクセスする旨を入力し（ステップＳ３４）、次に、端末２００−１はＨＴＴＰリクエストを送出する（ステップＳ３５）。ステップＳ３５のＨＴＴＰリクエストは、以前アクセスしようとして出来なかったウェブサイト３１０−１へアクセスするためのＨＴＴＰリクエストである。

ウェブサイト３１０−１へアクセスするためのＨＴＴＰリクエストを受信したルータ１００は、当該ＨＴＴＰリクエストをウェブサーバ３００−１へ転送する（ステップＳ３６）。

当該ＨＴＴＰリクエストを受信したウェブサーバ３００−１は、ＨＴＴＰレスポンスを返送する。ここで、ウェブサーバ３００−１はサーバエラーの状態からは復旧しているため、ＨＴＴＰ成功レスポンス（“２００”）を送信する（ステップＳ３７）。

ＨＴＴＰ成功レスポンス（“２００”）を受信したルータ１００は、これを端末２００−１へ転送する（ステップＳ３８）。

端末２００−１は、ウェブサーバ３００−１からのＨＴＴＰ成功レスポンス（“２００”）を受信したことにより、中断していたウェブサイト３１０−１への再接続がなされたことを認識する。そして、以降、端末２００−１からウェブサイト３１０−１へのアクセスが再開されることとなる。

以上、本実施形態の概略動作について説明した。

次に、図６〜図１０を参照して、本実施形態の詳細動作について説明する。なお、詳細動作の説明においては、端末２００−１からルータ１００を介して、ウェブサイト３１０−１へアクセスするものとする。そして、端末２００−１のＩＰアドレスを「１９２．１６８．０．１」であるものとし、ウェブサイト３１０−１のＵＲＬを「ｈｔｔｐ：／／□□□／△△△／」であるものとする。また、ウェブサイト３１０−２のＵＲＬは「ｈｔｔｐ：／／○○○／◇◇◇／」であるものとする。また、詳細動作の実行は、ルータ１００の制御部９０が行うものであるが、説明の容易化のため、ルータ１００が行うものとして以下の記述を行う。

図６は、第１の実施形態の詳細動作を説明する第１のフローチャートである。

図６において、ルータ１００は、端末２００−１から送出されるＨＴＴＰリクエストを受信したかの判定を行っている（ステップＳ１０１）。ＨＴＴＰリクエストを受信しない場合（ステップＳ１０１でＮｏ）、ステップＳ１０１の判定を繰り返し行う。

ＨＴＴＰリクエストを受信した場合（ステップＳ１０１でＹｅｓ）、ルータ１００は、受信したＨＴＴＰリクエストを宛先であるところのウェブサーバ３００−１へ転送する（ステップＳ１０２）。

次に、ルータ１００は、ＨＴＴＰリクエストを転送した時点から、ウェブサーバ３００−１からのＨＴＴＰレスポンスを待ち受ける所定の時間が経過したかの判定を行う（ステップＳ１０３）。所定の時間が経過している場合（ステップＳ１０３でＹｅｓ）、ＨＴＴＰレスポンスを所定の時間内に受信できなかった為、ステップＳ１０６の動作に進む。なお、ここでは、ＨＴＴＰレスポンスを受信していないため、ステップＳ１０６の次のステップＳ１０７の動作は実行されない。

所定の時間が経過していない場合（ステップＳ１０３でＮｏ）、ルータ１００は、ウェブサーバ３００−１からＨＴＴＰレスポンスを受信したかの判定を行う（ステップＳ１０４）。ＨＴＴＰレスポンスを受信していない場合（ステップＳ１０４でＮｏ）、ルータ１００は、ステップＳ１０３の判定動作に戻る。

ＨＴＴＰレスポンスを受信した場合（ステップＳ１０４でＹｅｓ）、ルータ１００は、受信したＨＴＴＰレスポンスがＨＴＴＰエラーレスポンスであるかの判定を行う（ステップＳ１０５）。ＨＴＴＰエラーレスポンスでない場合（ステップＳ１０５でＮｏ）、ＨＴＴＰレスポンスはＨＴＴＰ成功レスポンスである為、ルータ１００はステップＳ１０７の動作に進む。

ＨＴＴＰエラーレスポンスである場合（ステップＳ１０５でＹｅｓ）、ルータ１００は、ステップＳ１０１で受信したＨＴＴＰリクエストを送出した端末２００−１やアクセス先ウェブサイト３１０−１の情報などを、アクセス先情報５２として記憶部５０に記憶する（ステップＳ１０６）。ここで記憶するアクセス先情報５２について、図９を参照して説明する。

図９は、アクセス先情報の変更される様子を示す図である。

図９の（１）に示すアクセス先情報５２は、ステップＳ１０６で記憶するアクセス先情報５２である。すなわち、アクセス先情報５２の「端末のＩＰアドレス」の欄には、ＨＴＴＰリクエストを送出した端末２００−１のＩＰアドレス（１９２．１６８．０．１）が記載される。また、「アクセス先ＵＲＬ」の欄には、アクセス先ウェブサイト３１０−１のＵＲＬ（ｈｔｔｐ：／／□□□／△△△／）が記載される。さらに、「残り再接続回数」の欄には、記憶部５０内に記憶されている設定情報５１の中の、「再接続する回数」の欄に記載されている回数（６回）が記載される。またさらに、「アクセス可否」の欄には、アクセスできなかったことを示す「×」が記載される。

なお、図９の（２）或いは（３）として示すアクセス先情報５２は、図９の（１）で示したアクセス先情報５２が、ルータ１００の今後の動作に応じて変更される様子を示すものである。従って、これらのアクセス先情報５２については、ルータ１００の今後の動作を説明する際に適宜参照して説明を行うものとする。

図６に戻り、ステップＳ１０６の後、ルータ１００は、ウェブサーバ３００−１から受信したＨＴＴＰレスポンスを、端末２００−１へ転送する（ステップＳ１０７）。そして、ルータ１００の動作は、図７で説明する次のステップに進む。

次に、図７を参照し、本実施形態の動作の続きについて説明する。

図７は、第１の実施形態の詳細動作を説明する第２のフローチャートである。

図６のステップＳ１０７の後、ルータ１００は、記憶部５０内に記憶されたアクセス先情報５２の中の「アクセス先ＵＲＬ」に対し、定期的にアクセスを行うようになる。

すなわち、ルータ１００は、アクセス先情報５２の中の「残り接続回数」に記載されている回数が、「０」より大きいか判定する（ステップＳ１１１）。ステップＳ１０７の直後にステップＳ１１１の判定を行った場合、アクセス先情報５２の「残り接続回数」は、図９の（１）で説明したように「６回」となっている。従って、残り接続回数＞０であり、ステップＳ１１１の判定はＹｅｓとなる。

残り接続回数が「０」より大きい場合（ステップＳ１１１でＹｅｓ）、ルータ１００は、記憶部５０内の設定情報５１の「再接続する間隔」に記載されている時間（本実施形態では「１０分」）が経過したかを判定する（ステップＳ１１２）。「再接続する間隔」が経過していない場合（ステップＳ１１２でＮｏ）、ステップＳ１１２の判定動作を繰り返す。

「再接続する間隔」が経過した場合（ステップＳ１１２でＹｅｓ）、ルータ１００は、記憶部５０に記憶されたアクセス先情報５２に基づき、ＨＴＴＰリクエストを生成する（ステップＳ１１３）。そして、ルータ１００は、生成したＨＴＴＰリクエストを、アクセス先情報５２の中の「アクセス先ＵＲＬ」の欄に記載されているＵＲＬに送信する。このとき同時に、アクセス先情報５２の中の「残り接続回数」の欄に記載されている回数から「１」を減算する（ステップＳ１１４）。この時のアクセス先情報５２の様子を図９（２）として示す。すなわち、図９（２）のアクセス先情報５２の「残り接続回数」の欄は「５回」となっており、図９（１）の「残り接続回数」の「６回」から「１」が減算されている。

次に、ルータ１００は、ウェブサイト３１０−１からＨＴＴＰ成功レスポンスを受信したかの判定を行う（ステップＳ１１５）。ＨＴＴＰ成功レスポンスを受信していない場合（ステップＳ１１５でＮｏ）、ステップＳ１１１に戻る。

ＨＴＴＰ成功レスポンスを受信した場合（ステップＳ１１５でＹｅｓ）、ルータ１００は、アクセス先情報５２の「アクセス可否」の欄の記載を、アクセス可能、を示す「○」に書き替える（ステップＳ１１６）。この時のアクセス先情報５２の様子を図９（３）として示す。すなわち、図９（３）のアクセス先情報５２の「アクセス可否」の欄は「○」となっており、図９（１）の「アクセス可否」の「×」が、「○」に書き替えられている。

そしてルータ１００は端末２００−１からの次のＨＴＴＰリクエストを受信するのを待つ状態となり、ルータ１００の動作は、図８で説明する次のステップに進む。

ステップＳ１１１の判定の説明に戻り、残り接続回数が「０」より大きくない場合（ステップＳ１１１でＮｏ）、ルータ１００は、記憶部５０に記憶したアクセス先情報５２を消去する（ステップＳ１１７）。そしてルータ１００は端末２００−１からの次のＨＴＴＰリクエストの受信を待つ状態となり、ルータ１００の動作は、図８で説明する次のステップに進む。

次に、図８を参照し、本実施形態の動作の続きについて説明する。

図８は、第１の実施形態の詳細動作を説明する第３のフローチャートである。

図７のステップＳ１１６或いはステップＳ１１７の後、ルータ１００は端末２００−１からの次のＨＴＴＰリクエストの受信を待つ状態となっている。そして、ルータ１００は、ＨＴＴＰリクエストを受信したかの判定を行う（ステップＳ１２１）。ＨＴＴＰリクエストを受信していない場合（ステップＳ１２１でＮｏ）、ステップＳ１２１の判定動作を繰り返す。

ＨＴＴＰリクエストを受信した場合（ステップＳ１２１でＹｅｓ）、ルータ１００は、当該ＨＴＴＰリクエストに関し、以下の確認を行う。すなわち、先ず、記憶部５０内にアクセス先情報５２が記憶されているかを判定する（ステップＳ１２２）。アクセス先情報５２が記憶されていない場合（ステップＳ１２２でＮｏ）、ルータ１００の動作はステップＳ１２８へ進む。

アクセス先情報５２が記憶されている場合（ステップＳ１２２でＹｅｓ）、ルータ１００は、当該ＨＴＴＰリクエストがアクセスしようとしているＵＲＬは、アクセス先情報５２の「アクセス先ＵＲＬ」の欄に記載されているＵＲＬと一致するかを判定する（ステップＳ１２３）。例として、当該ＨＴＴＰリクエストが、ウェブサイト３１０−２へのアクセスを行うものであったとする。ウェブサイト３１０−２のＵＲＬは「ｈｔｔｐ：／／○○○／◇◇◇／」であるため、記憶部５０のアクセス情報５２のアクセス先ＵＲＬ（ｈｔｔｐ：／／□□□／△△△／）とは異なっている。従ってこの例では、ステップＳ１２３の判定は「Ｎｏ」となる。

当該ＨＴＴＰリクエストのＵＲＬが、アクセス先情報５２に記載されているＵＲＬと一致しない場合（ステップＳ１２３でＮｏ）、ルータ１００の動作はステップＳ１２８へ進む。

当該ＨＴＴＰリクエストのＵＲＬが、アクセス先情報５２に記載されているＵＲＬと一致した場合（ステップＳ１２３でＹｅｓ）、ルータ１００は、アクセス先情報５２の「アクセス可否」の欄にはアクセス可能を示す「○」が記載されているか判定する（ステップＳ１２４）。「アクセス可否」の欄がアクセス可能となっていない場合（ステップＳ１２４でＮｏ）、ルータ１００の動作はステップＳ１２８へ進む。

「アクセス可否」の欄がアクセス可能となっている場合（ステップＳ１２４でＹｅｓ）、ルータ１００は、端末２００−１に対する通知画面を生成する（ステップＳ１２５）。ここで生成する通知画面は、以前アクセスしようとしたが出来なかったウェブサーバ３００−１のウェブサイト３１０−１が復旧している旨を通知するものである。加えて、この通知画面では、今アクセスしようとしているウェブサイト３１０−２と以前のウェブサイト３１０−１の何れにアクセスするかの問い合わせも含んでいる。ここで、図１０を参照して、ルータ１００が生成する通知画面について説明を行っておく。

図１０は、ルータが生成する通知画面の一例を示す図である。

図１０の（１）部分は、今アクセスしようとしているウェブサイト３１０−２に関する表示である。（１）の中段に、ウェブサイト３１０−２のＵＲＬが記載されており、このＵＲＬをクリックすれば、当該ＵＲＬへの接続を行う旨を表示している。

また、図１０の（２）部分は、以前アクセスしようとしたが出来なかったウェブサイト３１０−１に関する表示である。（２）の上段に、ウェブサイト３１０−１が復旧した旨を表示している。そして、（２）の下段に記載されているＵＲＬをクリックして選択すれば、当該ＵＲＬへの接続を行う旨を表示している。

図８に戻り、ステップＳ１２５で通知画面を生成した後、ルータ１００は、通知画面を、ステップＳ１２１で受信した当該ＨＴＴＰリクエストに対するＨＴＴＰ成功レスポンスとして、端末２００−１に返送する（ステップＳ１２６）。

そして、ルータ１００は、ＨＴＴＰリクエストを受信したかについて判定を行う（ステップＳ１２７）。ここで受信するＨＴＴＰリクエストは、ステップＳ１２６で端末２００−１に返送した通知画面において、ウェブサイト３１０−２とウェブサイト３１０−１の何れかのＵＲＬが選択された場合に、受信するものである。ＨＴＴＰリクエストを受信しない場合（ステップＳ１２７でＮｏ）、ステップＳ１２７の判定動作を繰り返す。

ＨＴＴＰリクエストを受信した場合（ステップＳ１２７でＹｅｓ）、ルータ１００は、ＨＴＴＰリクエストを宛先であるところのウェブサーバ３００へ転送する（ステップＳ１２８）。

次に、ウェブサーバ３００のウェブサイト３１０からＨＴＴＰレスポンスを受信する（ステップＳ１２９）。すると、ルータ１００は、受信したＨＴＴＰレスポンスがＨＴＴＰ成功レスポンスであるかの判定を行う（ステップＳ１３０）。

受信したＨＴＴＰレスポンスがＨＴＴＰ成功レスポンスでない場合（ステップＳ１３０でＮｏ）、ルータ１００の動作はステップＳ１０５に戻る。

受信したＨＴＴＰレスポンスがＨＴＴＰ成功レスポンスである場合（ステップＳ１３０でＹｅｓ）、ルータ１００は、これを端末２００へ転送する（ステップＳ１３１）。そして、ルータ１００は、本実施形態における動作を終了する。

以上、本発明の第１の実施形態の動作について説明した。

なお、上述した本実施形態において、以下のような変更を行ってもよい。

すなわち、先ず、記憶部５０に記憶するアクセス先情報５２の「端末のＩＰアドレス」に代えて、「端末のＭＡＣ（Media Access Control：マック）アドレス」を用いるようにしてもよい。

また、ＨＴＴＰレスポンスの内、ステータスコードが“２００”のものを、ＨＴＴＰ成功レスポンスであるとしていた。これに加えて、ステータスコードが“４０１”のものを、ＨＴＴＰ成功レスポンスであるとしてもよい。ステータスコード“４０１”は、「認証が拒否された」旨を意味するレスポンスである。さらに、ウェブサイト３１０にアクセスできない、と判定するのは、ＨＴＴＰレスポンスのステータスコードが“４０４”や“４０８”のもの、或いは、“５００”や“５０３”のものを受信した場合であるとしている。これに加えて、ＨＴＴＰリクエストに対するレスポンスが所定の時間以内に帰らない場合も、ウェブサイト３１０にアクセスできない、と判定するようにしてもよい。

以上説明したように、本実施形態のルータ１００は、端末（２００）と接続するＬＡＮインタフェース（１０）と、ウェブサイト（３１０）を形成するウェブサーバ（３００）と接続するＷＡＮインタフェース（２０）と、を備えている。また、ルータ１００は、制御手段（制御部９０）を備えている。

そして、制御手段は、端末からウェブサイト宛の第１のＨＴＴＰリクエストを受信した場合に前記第１のＨＴＴＰリクエストを前記ウェブサイトへ転送する。そして、前記転送の結果受信したＨＴＴＰレスポンスがエラーの発生を示すレスポンスであった場合、或いは、所定の待ち時間内に前記転送の結果としてのＨＴＴＰレスポンスを受信できない場合、以下を行う。すなわち、前記端末と前記ウェブサイトに関する情報をアクセス先情報として記憶する。次に、前記アクセス先情報に基づく第２のＨＴＴＰリクエストを生成し所定の時間間隔で、かつ、所定の回数だけ前記ウェブサイトへ送信する。ここで、前記ウェブサイトから前記第２のＨＴＴＰリクエストが成功した旨のＨＴＴＰレスポンスを受信した際、前記ウェブサイトの前記エラーが解消した旨を前記端末に通知する、ようになっている。

従って、本実施形態によれば、ネットワーク管理者でなくとも、ウェブサーバなどの障害の復旧を自動的に検知し、ウェブサイトに再接続することが可能となる。

また、前記制御手段は、前記端末からエラーが解消した前記ウェブサイト宛の第３のＨＴＴＰリクエストを受信した場合に前記第３のＨＴＴＰリクエストを前記ウェブサイトへ転送する、ようになっている。

従って、本実施形態によれば、端末のユーザは、障害等の影響でアクセスできなくなっているウェブサーバの復旧確認のための操作を行う必要がない。
[第２の実施形態]
次に、図１１〜図１４を参照して、本発明の第２の実施形態について説明する。

本発明の第２の実施形態は、ルータ１００によってウェブサイト３１０へ再接続を行わせるか否かについて、端末２００毎に設定できるようにしたものである。そして、ルータ１００の構成は、図２に示したものと同一であるが、記憶部５０に記憶させる設定情報５１が、第１の実施形態とは異なるものである。

図１１は、第２の実施形態の設定情報を示す図である。

図１１において、記憶部５０に記憶される設定情報５１３は、端末２００からウェブサイト３１０にアクセスしようとしたが、アクセスできなかった場合、当該ウェブサイト３１０に再接続する際の条件を設定する。

すなわち、設定情報５１３には、設定情報５１３のＮｏ．（５１３−１行、５１３−１１列）、ウェブサイト３１０への再接続を行わせる端末のＩＰアドレス（５１３−１行、５１３−１２列）が設定される。また、再接続する間隔（５１３−１行、５１３−１３列）及び再接続する回数（５１３−１行、５１３−１４列）が設定される。一例として、Ｎｏ．が「１」（５１３−２行、５１３−１１列）の行には、端末のＩＰアドレスが「１９２．１６８．０．１０」（５１３−２行、５１３−１２列）が設定されている。また当該行の続きとして、再接続する間隔が「２０分」（５１３−２行、５１３−１３列）、再接続する回数が「９回」（５１３−２行、５１３−１４列）と設定されている。

つまり、設定情報５１３内に、端末のＩＰアドレスが設定されている端末２００だけが、ウェブサイト３１０へのアクセスが出来なかった場合に、ルータ１００による再接続を行わせることとなる。設定情報５１３内に端末のＩＰアドレスが設定されていない端末２００は、ウェブサイト３１０へのアクセスが出来なかった場合、ルータ１００による再接続動作は行われない。図１１に示した例においては、端末のＩＰアドレスとして「１９２．１６８．０．１０」を有する端末２００の場合だけ、ルータ１００による再接続動作が行われることとなる。

次に、図１２を参照して、本実施形態の動作例について説明する。

図１２は、第２の実施形態の概略動作を示す第１のシーケンスチャートである。なお、図１２においては、一例として、端末２００−１及び端末２００−２がウェブサーバ３００−１のウェブサイト３１０−１へアクセスする場合について説明する。ここで、端末２００−１のＩＰアドレスは「１９２．１６８．０．１」であるものとし、設定情報５１３内に当該ＩＰアドレスは設定されていないものとする。また、端末２００−２のＩＰアドレスは「１９２．１６８．０．１０」であるものとし、図１１に示したように、設定情報５１３内に当該ＩＰアドレスが設定されているものとする。

図１２において、端末２００−１は、ウェブサーバ３００−１のウェブサイト３１０−１にアクセスするために、ＨＴＴＰリクエストを送出する（図１２のステップＳ２１）。すると、ルータ１００は、当該ＨＴＴＰリクエストをウェブサーバ３００−１に転送する（ステップＳ２２）。

ＨＴＴＰリクエストを受信したウェブサーバ３００−１は、ＨＴＴＰレスポンスを返送する。このときのＨＴＴＰレスポンスが、ＨＴＴＰエラーレスポンスであったものとする（ステップＳ２３）。

ＨＴＴＰエラーレスポンスを受信したルータ１００は、当該ＨＴＴＰリクエストを送出した端末２００−１のＩＰアドレスが、設定情報５１３内に設定されているかを確認する。上述したように、端末２００−１のＩＰアドレスは、設定情報５１３内に設定されていない。従って、ルータ１００は、受信したＨＴＴＰエラーレスポンスをそのまま、端末２００−１に転送する（ステップＳ２４、ステップＳ２５）。

次に、端末２００−２は、ウェブサーバ３００−１のウェブサイト３１０−１にアクセスするために、ＨＴＴＰリクエストを送出する（ステップＳ３１）。すると、ルータ１００は、当該ＨＴＴＰリクエストをウェブサーバ３００−１に転送する（ステップＳ３２）。

ＨＴＴＰリクエストを受信したウェブサーバ３００−１は、ＨＴＴＰレスポンスを返送する。このときのＨＴＴＰレスポンスが、ＨＴＴＰエラーレスポンスであったものとする（ステップＳ３３）。

ＨＴＴＰエラーレスポンスを受信したルータ１００は、当該ＨＴＴＰリクエストを送出した端末２００−２のＩＰアドレスが、設定情報５１３内に設定されているかを確認する。上述したように、端末２００−２のＩＰアドレスは、設定情報５１３内に設定されている。従って、ルータ１００は、当該ＨＴＴＰリクエストを送出した端末２００−２やアクセス先ウェブサイト３１０−１の情報などを、アクセス先情報５２としてルータ１００の記憶部５０に記憶する（ステップＳ３４）。そして、ルータ１００は、当該ＨＴＴＰエラーレスポンスを端末２００−２に転送する（ステップＳ３５）。

ステップＳ３５の後、ルータ１００は、第１の実施形態で説明したと同様の動作を行うようになり、端末２００−２がウェブサイト３１０−１に再接続できるよう動作する。

次に、本実施形態の第２の動作例について説明する。

本実施形態の第２の動作例は、２台の端末２００が、２つのウェブサイト３１０にアクセスする場合の動作を例示するものである。

前提として、２台の端末２００は、端末２００−１（ＩＰアドレス＝「１９２．１６８．０．１」）と端末２００−２（ＩＰアドレス＝「１９２．１６８．０．１０」）であるものとする。また、２つのウェブサイト３１０は、ウェブサイト３１０−１（ＵＲＬ＝「ｈｔｔｐ：／／□□□／△△△／」）とウェブサイト３１０−２（ＵＲＬ＝「ｈｔｔｐ：／／○○○／◇◇◇／」）であるものとする。

そして、２台の端末２００は共に、記憶部５０の設定情報５１３内に、端末のＩＰアドレスが設定されている。また、２台の端末２００がアクセスしようとしているアクセス先ＵＲＬは、記憶部５０のアクセス先情報５２内に記憶されている。

図１３は、第２の実施形態において記憶部が記憶する情報の一例を示す図である。

図１３において、設定情報５１３には、端末２００−１に関する設定情報（５１３−２行）と端末２００−２に関する設定情報（５１３−３行）が設定されている。

また、アクセス先情報５２には、端末２００−１がアクセスしようとしているアクセス先ＵＲＬなどが記憶され（５２−２行）、また、端末２００−２がアクセスしようとしているアクセス先ＵＲＬなどが記憶されている（５２−３行）。そして、アクセス先情報５２のアクセス可否の欄には「○」が記載されている（５２−２行、５２−３行）。これは、両端末２００がそれぞれアクセスしようとして出来なかったウェブサイト３１０が、今は復旧した状態に戻っている、ということを意味している。

以上の前提をもとに、本実施形態の第２の動作例について説明する。

図１４は、第２の実施形態の概略動作を示す第２のシーケンスチャートである。

図１４において、端末２００−１は、ウェブサーバ３００−１のウェブサイト３１０−１にアクセスするために、ＨＴＴＰリクエスト（ウェブサイト３１０−１宛）を送出する（図１４のステップＳ４１）。すると、ルータ１００は、当該ＨＴＴＰリクエストを送出した端末２００−１が、以前アクセスしたアクセス先ＵＲＬを確認する。図１３（５２−２行）に示したように、端末２００−１が以前アクセスしたアクセス先ＵＲＬはウェブサイト３１０−１（ＵＲＬ＝「ｈｔｔｐ：／／□□□／△△△／」）である。すなわち、以前アクセスしたアクセス先と、今回アクセスしたアクセス先は同一である。従って、ルータ１００は、第１の実施形態で説明した通知画面は生成せず、当該ＨＴＴＰリクエストをウェブサーバ３００−１に転送する（ステップＳ４２）。第１の実施形態で説明したように、通知画面を生成する場合とは、以前アクセスしようとして出来なかったアクセス先とは異なるアクセス先に接続しようとした場合である。

ＨＴＴＰリクエストを受信したウェブサーバ３００−１は、ＨＴＴＰレスポンスを返送する。このときのＨＴＴＰレスポンスが、ＨＴＴＰ成功レスポンスであったものとする（ステップＳ４３）。

ＨＴＴＰ成功レスポンスを受信したルータ１００は、受信したＨＴＴＰ成功レスポンスをそのまま端末２００−１に転送する（ステップＳ４４）。

次に、端末２００−１は、ステップＳ４１でアクセスしたウェブサイト３１０−１とは別の、ウェブサーバ３００−２のウェブサイト３１０−２にアクセスするために、ＨＴＴＰリクエスト（ウェブサイト３１０−２宛）を送出する（ステップＳ５１）。

すると、ルータ１００は、当該ＨＴＴＰリクエストを送出した端末２００−１が、以前アクセスしたアクセス先ＵＲＬを確認する。図１３（５２−２行）に示したように、端末２００−１が以前アクセスしたアクセス先ＵＲＬはウェブサイト３１０−１（ＵＲＬ＝「ｈｔｔｐ：／／□□□／△△△／」）である。すなわち、以前アクセスしたアクセス先と、今回アクセスしたアクセス先は異なっている。従って、ルータ１００は、通知画面を生成する（ステップＳ５２）。そして、ルータ１００は、生成した通知画面を、ステップＳ４５で受信したＨＴＴＰリクエストに対するＨＴＴＰ成功レスポンスとして、端末２００−１に返送する（ステップＳ５３）。

端末２００−１と同様に、端末２００−２は、ウェブサーバ３００−２のウェブサイト３１０−２にアクセスするために、ＨＴＴＰリクエスト（ウェブサイト３１０−２宛）を送出する（図１４のステップＳ６１）。すると、ルータ１００は、当該ＨＴＴＰリクエストを送出した端末２００−２が、以前アクセスしたアクセス先ＵＲＬを確認する。図１３（５２−３行）に示したように、端末２００−２が以前アクセスしたアクセス先ＵＲＬはウェブサイト３１０−２（ＵＲＬ＝「ｈｔｔｐ：／／○○○／◇◇◇／」）である。すなわち、以前アクセスしたアクセス先と、今回アクセスしたアクセス先は同一である。従って、ルータ１００は、通知画面は生成せず、当該ＨＴＴＰリクエストをウェブサーバ３００−２に転送する（ステップＳ６２）。

ＨＴＴＰリクエストを受信したウェブサーバ３００−２は、ＨＴＴＰレスポンスを返送する。このときのＨＴＴＰレスポンスが、ＨＴＴＰ成功レスポンスであったものとする（ステップＳ６３）。

ＨＴＴＰ成功レスポンスを受信したルータ１００は、受信したＨＴＴＰ成功レスポンスをそのまま端末２００−２に転送する（ステップＳ６４）。

次に、端末２００−２は、ステップＳ６１でアクセスしたウェブサイト３１０−２とは別の、ウェブサーバ３００−１のウェブサイト３１０−１にアクセスするために、ＨＴＴＰリクエスト（ウェブサイト３１０−１宛）を送出する（ステップＳ７１）。

すると、ルータ１００は、当該ＨＴＴＰリクエストを送出した端末２００−２が、以前アクセスしたアクセス先ＵＲＬを確認する。図１３（５２−３行）に示したように、端末２００−２が以前アクセスしたアクセス先ＵＲＬはウェブサイト３１０−２（ＵＲＬ＝「ｈｔｔｐ：／／○○○／◇◇◇／」）である。すなわち、以前アクセスしたアクセス先と、今回アクセスしたアクセス先は異なっている。従って、ルータ１００は、通知画面を生成する（ステップＳ７２）。そして、ルータ１００は、生成した通知画面を、ステップＳ５５で受信したＨＴＴＰリクエストに対するＨＴＴＰ成功レスポンスとして、端末２００−２に返送する（ステップＳ７３）。

以上、本発明の第２の実施形態の動作について説明した。

前述したように、本発明の第２の実施形態は、ルータ１００によってウェブサイト３１０へ再接続を行わせるか否かについて、端末２００毎に設定できるようにした点でのみ、第１の実施形態と異なるものである。従って、以下においては、第２の実施形態に特有の箇所に関してのみ説明するものとする。

以上説明したように、第２の実施形態の制御手段（制御部９０）は、以下のように動作する。制御手段は、前記第１のＨＴＴＰリクエストを前記ウェブサイトへ転送し、前記転送の結果受信したＨＴＴＰレスポンスがエラーの発生を示すレスポンスであった場合、或いは、所定の待ち時間内に前記転送の結果としてのＨＴＴＰレスポンスを受信できない場合、以下を行う。すなわち、前記端末が設定情報内に設定されている場合にのみ、前記端末と前記ウェブサイトに関する情報をアクセス先情報として記憶する、ようになっている。

従って、本実施形態によれば、ルータによってウェブサイトへ再接続を行わせるか否かについて、端末毎に設定できるようなる。
[第３の実施形態]
次に、図１５、図１６を参照して、本発明の第３の実施形態について説明する。

図１５は、本発明のルータの第３の実施形態を示すブロック図である。本発明の第３の実施形態は、図２に示した第１の実施形態のルータ１００内に、ＵＳＢ（Universal Serial Bus：ユーエスビー）インタフェースを追加した点でのみ異なるものである。従って、図１５において、第１の実施形態で示した図２の構成要素に対応するものは同一の参照数字または符号を付し、その説明を極力省略するものとする。

図１５において、ルータ１００−３は、ＬＡＮインタフェース１０、ＷＡＮインタフェース２０、ルーティング部３０、ルータ装置機能部４０、記憶部５０、ＵＳＢインタフェース６０、ＵＳＢマスストレージデバイス７０を備えている。ここで、ルーティング部３０、ルータ装置機能部４０、記憶部５０、ＵＳＢインタフェース６０は、図１に示したルータ１００の制御部９０の詳細構成である。

ＬＡＮインタフェース１０、ＷＡＮインタフェース２０、ルーティング部３０、ルータ装置機能部４０、記憶部５０は、図２に示した第１の実施形態と同一であるため、その説明を省略する。

ＵＳＢインタフェース６０は、ＵＳＢ規格に則ったＵＳＢマスストレージデバイス７０と接続するインタフェースである。

ＵＳＢマスストレージデバイス７０は、ＵＳＢ規格に則った大容量の記憶装置である。

図１５に示すＬＡＮ４００、端末２００、インターネット５００、ウェブサーバ３００は、図２に示した第１の実施形態と同一であるため、その説明を省略する。

次に、本実施形態の動作について説明する。

本実施形態のルータ１００−３は、ウェブサイト３１０のエラー状態が復旧して当該ウェブサイト３１０へのアクセスが可能になったと判断した場合に、以下の動作を行うものである。すなわち、ルータ１００−３は、当該ウェブサイト３１０が提供するウェブページなどのコンテンツ情報を取得し、これを、ＵＳＢインタフェース６０を介してＵＳＢマスストレージデバイス７０にキャッシュ（履歴フォルダ等）として保存しておく。そして、当該ウェブサイト３１０に再度アクセスできなくなった場合に、保存したキャッシュを端末２００に表示させるものである。

以下、図１６のシーケンスチャートを参照して、本実施形態の動作の具体例を説明する。

図１６は、第３の実施形態の概略動作を示すシーケンスチャートである。

図１６において、ステップＳ１１からステップＳ２１までの動作は、図５に示した動作と同一である。従って、図１６において、図５に示した動作と同一のものは、同一の参照数字または符号を付しその説明を省略するものとする。

図１６のステップＳ２１において、ルータ１００−３は、ウェブサーバ３００−１からＨＴＴＰ成功レスポンス（“２００”）を受信したので、当該ウェブサーバ３００−１へのアクセスが可能になったと判断する。そして、その時点で、ウェブサーバ３００−１のウェブサイト３１０−１からコンテンツ情報を取得し、ＵＳＢマスストレージデバイス７０にキャッシュとして保存しておく（ステップＳ２１−１）。

次に、ＨＴＴＰ成功レスポンス（“２００”）を受信したルータ１００−３は、ステップＳ１６或いはステップＳ１９で行っていた動作、すなわち、アクセス先情報５２に基づいてＨＴＴＰリクエストを生成する動作、を終了する。そして、端末２００−１からの次のＨＴＴＰリクエストを受信するのを待つ状態となる（ステップＳ２２）。

次に、端末２００−１は、ウェブサイト３１０−１へアクセスするためのＨＴＴＰリクエストを送信する（ステップＳ８１）。すると、ルータ１００−３は、当該ＨＴＴＰリクエストを、ウェブサーバ３００−１に対して転送する（ステップＳ８２）。

ここで、ウェブサーバ３００−１は、ＨＴＴＰエラーレスポンス（“５０３”）を返送したものとする（ステップＳ８３）。

次に、ルータ１００−３は、ウェブサーバ３００−１からＨＴＴＰエラーレスポンス（“５０３”）を受信したので、当該ウェブサイト３１０−１にはアクセスできなくなったと判断する。そして、その時点で、ＵＳＢマスストレージデバイス７０に保存しておいたコンテンツ情報を、端末２００−１に送信する。また、端末２００−１やアクセス先ウェブサイト３１０−１の情報などを、アクセス先情報として記憶する（ステップＳ８４）。

ルータ１００−３からは、端末２００−１に対し、コンテンツ情報が送信される（ステップＳ８５）。

以上、本実施形態の動作について説明した。

前述したように、本発明の第３の実施形態は、図２に示した第１の実施形態のルータ１００内に、ＵＳＢインタフェース６０を追加した点でのみ異なるものである。従って、以下においては、第３の実施形態に特有の箇所に関してのみ説明するものとする。

以上説明したように、第３の実施形態の制御手段（制御部９０−３）は、前記ウェブサイトから前記第２のＨＴＴＰリクエストが成功した旨のＨＴＴＰレスポンスを受信した際、前記ウェブサイトからコンテンツ情報を取得し、キャッシュとして保存する、ようになっている。

従って、本実施形態によれば、ウェブサイトに再度のエラーが発生した場合に備えて、コンテンツ情報を予め保存しておくことが可能となる。

また、前記制御手段は、前記ウェブサイトに再度前記エラーが発生した際、前記コンテンツ情報を前記端末へ送信して表示させる、ようになっている。

従って、本実施形態によれば、ウェブサイトに再度のエラーが発生した場合であっても、エラーが発生する前のコンテンツ情報を端末に表示させることが可能となる。

１０ ＬＡＮインタフェース
２０ ＷＡＮインタフェース
３０ ルーティング部
４０ ルータ装置機能部
５０ 記憶部
５１ 設定情報
５１３ 設定情報
５２ アクセス先情報
６０ ＵＳＢインタフェース
７０ ＵＳＢマスストレージデバイス
９０ 制御部
１００ ルータ
２００ 端末
２１０ ウェブブラウザ
３００ ウェブサーバ
３１０ ウェブサイト
４００ ＬＡＮ
５００ インターネット
６００ ＷＡＮ

Claims (10)

1. 端末と接続するＬＡＮインタフェースと、
   ウェブサイトを形成するウェブサーバと接続するＷＡＮインタフェースと、
   端末からウェブサイト宛の第１のＨＴＴＰリクエストを受信した場合に前記第１のＨＴＴＰリクエストを前記ウェブサイトへ転送し、前記転送の結果受信したＨＴＴＰレスポンスがエラーの発生を示すレスポンスであった場合、或いは、所定の待ち時間内に前記転送の結果としてのＨＴＴＰレスポンスを受信できない場合、前記端末と前記ウェブサイトに関する情報をアクセス先情報として記憶し、前記アクセス先情報に基づく第２のＨＴＴＰリクエストを生成し所定の時間間隔で、かつ、所定の回数だけ前記ウェブサイトへ送信し、前記ウェブサイトから前記第２のＨＴＴＰリクエストが成功した旨のＨＴＴＰレスポンスを受信した際、前記ウェブサイトの前記エラーが解消した旨を前記端末に通知する制御手段と、
   を備えていることを特徴とするルータ。
2. 前記制御手段は、前記端末からエラーが解消した前記ウェブサイト宛の第３のＨＴＴＰリクエストを受信した場合に前記第３のＨＴＴＰリクエストを前記ウェブサイトへ転送する、
   ことを特徴とする請求項１に記載のルータ。
3. 前記制御手段は、前記第１のＨＴＴＰリクエストを前記ウェブサイトへ転送し、前記転送の結果受信したＨＴＴＰレスポンスがエラーの発生を示すレスポンスであった場合、或いは、所定の待ち時間内に前記転送の結果としてのＨＴＴＰレスポンスを受信できない場合、前記端末が設定情報内に設定されている場合にのみ、前記端末と前記ウェブサイトに関する情報をアクセス先情報として記憶する、
   ことを特徴とする請求項１或いは請求項２の何れかに記載のルータ。
4. 前記制御手段は、前記ウェブサイトから前記第２のＨＴＴＰリクエストが成功した旨のＨＴＴＰレスポンスを受信した際、前記ウェブサイトからコンテンツ情報を取得し、キャッシュとして保存する、
   ことを特徴とする請求項１から請求項３の何れかに記載のルータ。
5. 前記制御手段は、前記ウェブサイトに再度前記エラーが発生した際、前記コンテンツ情報を前記端末へ送信して表示させる、
   ことを特徴とする請求項４に記載のルータ。
6. 端末からウェブサイト宛の第１のＨＴＴＰリクエストを受信した場合に前記第１のＨＴＴＰリクエストをウェブサイトへ転送し、
   前記転送の結果受信したＨＴＴＰレスポンスがエラーの発生を示すレスポンスであった場合、或いは、所定の待ち時間内に前記転送の結果としてのＨＴＴＰレスポンスを受信できない場合、前記端末と前記ウェブサイトに関する情報をアクセス先情報として記憶し、
   前記アクセス先情報に基づく第２のＨＴＴＰリクエストを生成し所定の時間間隔で、かつ、所定の回数だけ前記ウェブサイトへ送信し、
   前記ウェブサイトから前記第２のＨＴＴＰリクエストが成功した旨のＨＴＴＰレスポンスを受信した際、前記ウェブサイトの前記エラーが解消した旨を前記端末に通知する、
   ことを特徴とするウェブサイトへの再接続方法。
7. 前記端末からエラーが解消した前記ウェブサイト宛の第３のＨＴＴＰリクエストを受信した場合に前記第３のＨＴＴＰリクエストを前記ウェブサイトへ転送する、
   ことを特徴とする請求項６に記載のウェブサイトへの再接続方法。
8. 前記第１のＨＴＴＰリクエストを前記ウェブサイトへ転送し、前記転送の結果受信したＨＴＴＰレスポンスがエラーの発生を示すレスポンスであった場合、或いは、所定の待ち時間内に前記転送の結果としてのＨＴＴＰレスポンスを受信できない場合、前記端末が設定情報内に設定されている場合にのみ、前記端末と前記ウェブサイトに関する情報をアクセス先情報として記憶する、
   ことを特徴とする請求項６或いは請求項７の何れかに記載のウェブサイトへの再接続方法。
9. 前記ウェブサイトから前記第２のＨＴＴＰリクエストが成功した旨のＨＴＴＰレスポンスを受信した際、前記ウェブサイトからコンテンツ情報を取得し、キャッシュとして保存する、
   ことを特徴とする請求項６から請求項８の何れかに記載のウェブサイトへの再接続方法。
10. 前記ウェブサイトに再度前記エラーが発生した際、前記コンテンツ情報を前記端末へ送信して表示させる、
    ことを特徴とする請求項９に記載のウェブサイトへの再接続方法。

Images