特許 7081313 中継サーバ

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2022-05-30

(45)【発行日】2022-06-07

(54)【発明の名称】中継サーバ

(51)【国際特許分類】

   G06F 11/30 20060101AFI20220531BHJP

   G06F 11/34 20060101ALI20220531BHJP

【ＦＩ】

G06F11/30 155

G06F11/34 176

G06F11/30 140A

【請求項の数】 12

(21)【出願番号】P 2018109235

(22)【出願日】2018-06-07

(65)【公開番号】P2019212149

(43)【公開日】2019-12-12

【審査請求日】2021-05-24

(73)【特許権者】

【識別番号】000005496

【氏名又は名称】富士フイルムビジネスイノベーション株式会社

(74)【代理人】

【識別番号】110000752

【氏名又は名称】特許業務法人朝日特許事務所

(72)【発明者】

【氏名】鈴木 善晴

【審査官】中村 信也

(56)【参考文献】

【文献】特開２００３－０５０７５２（ＪＰ，Ａ）

【文献】特開２００３－０８５０６０（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ １１／０７

Ｇ０６Ｆ １１／２８－１１／３６

(57)【特許請求の範囲】

【請求項1】

クライアント装置からの要求を受信する第１受信部と、
特定のサーバ装置が稼働しているか停止しているか監視する監視部と、
前記第１受信部が前記要求を受信した場合において前記サーバ装置が稼働しているときは、当該要求を当該サーバ装置に転送する転送部と、
前記第１受信部が前記要求を受信した場合において前記サーバ装置が停止しているときは、当該要求があった日時をデータベースに書き込む書き込み部と
を有する中継サーバ。

【請求項2】

前記書き込み部は、前記監視部における監視の結果を用いて、前記サーバ装置が停止していた時間帯を前記データベースに書き込む
請求項１に記載の中継サーバ。

【請求項3】

前記要求は、前記クライアント装置又は当該クライアント装置のユーザの識別情報を含み、
前記書き込み部は、前記要求と共に前記識別情報を前記データベースに書き込む
請求項１又は２に記載の中継サーバ。

【請求項4】

前記サーバ装置が停止しているときに前記要求を送信したことが前記データベースに記録されているクライアント装置又は当該クライアント装置のユーザに対し、特典を付与する付与部を有する
請求項３に記載の中継サーバ。

【請求項5】

前記付与部は、前記データベースに記録されている要求の属性に応じた重みを付けて、前記特典を付与する
請求項４に記載の中継サーバ。

【請求項6】

前記データベースが、アプリケーションプログラムの識別情報と、当該アプリケーションプログラムにおいて要求を再送信する機能の有無とを含み、
前記要求がアプリケーションプログラムの識別情報を含み、
前記書き込み部は、前記受信部が前記要求を受信した場合において当該要求を送信したアプリケーションプログラムが要求を再送信する機能を有することが前記データベースに記録されているときは、前記サーバ装置が停止していても、前記要求があった日時を前記データベースに書き込まない
請求項３乃至５のいずれか一項に記載の中継サーバ。

【請求項7】

前記サーバ装置が停止状態から稼働状態に変わったことの通知を受信する第２受信部
を有する請求項１乃至６のいずれか一項に記載の中継サーバ。

【請求項8】

前記サーバ装置が稼働しているか停止しているか監視をする頻度を変更する変更部
を有する請求項１乃至７のいずれか一項に記載の中継サーバ。

【請求項9】

前記変更部は、前記サーバ装置が停止しているときにあった前記要求の数又は頻度が基準より多い場合、前記監視の頻度を増加させる
請求項８に記載の中継サーバ。

【請求項10】

前記サーバ装置が停止する予定の時間帯を示す情報を取得する取得部を有し、
前記変更部は、前記情報により示される復旧時刻までの時間がしきい値を下回った場合、前記監視の頻度を増加させる
請求項８に記載の中継サーバ。

【請求項11】

前記監視部が行う前記サーバ装置の監視には、処理が軽い第１手法による監視と、当該第１手法より処理が重い第２手法による監視が含まれ、
前記変更部は、前記サーバ装置が稼働しているか停止しているか監視をする手法を変更する
請求項８乃至１０のいずれか一項に記載の中継サーバ。

【請求項12】

前記変更部は、監視の頻度を増加させるときは、監視の手法として前記第１手法を用いる
請求項１１に記載の中継サーバ。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、中継サーバに関する。

【背景技術】

【0002】

アプリケーションシステム１では、メンテナンスや不具合等によりサーバが停止する場合があり、サーバ側では、この停止時にアクセスしてきたクライアントを特定し、そのクライアントに対し、アクセスに応えられなかったことへの対応をする必要がある。特許文献１に開示の技術では、クライアント側で、通信に失敗した時刻をタイムスタンプとして保存し、次回の通信でそのタイムスタンプをサーバに送る。サーバ側は、停止期間を保持しておき、クライアント側から受信したタイムスタンプがこの停止期間内の時刻を示している場合に、そのタイムスタンプを送ってきたクライアントを、サーバ停止時にアクセスしてきたクライアントとして特定する。

【先行技術文献】

【特許文献】

【0003】

【文献】特許第５９８１６８３号

【発明の概要】

【発明が解決しようとする課題】

【0004】

本発明は、サーバに処理を要求するアプリケーションが動作するクライアント装置を含むシステムにおいて、サーバが停止している間にアプリケーションからアクセスがあったことを、アプリケーションの機能によらずに記録する技術を提供することを目的とする。

【課題を解決するための手段】

【0005】

請求項１に係る中継サーバは、クライアント装置からの要求を受信する第１受信部と、特定のサーバ装置が稼働しているか停止しているか監視する監視部と、前記第１受信部が前記要求を受信した場合において前記サーバ装置が稼働しているときは、当該要求を当該サーバ装置に転送する転送部と、前記第１受信部が前記要求を受信した場合において前記サーバ装置が停止しているときは、当該要求があった日時をデータベースに書き込む書き込み部とを有する。
請求項２に係る中継サーバは、請求項１に係る中継サーバにおいて、前記書き込み部は、前記監視部における監視の結果を用いて、前記サーバ装置が停止していた時間帯を前記データベースに書き込む。
請求項３に係る中継サーバは、請求項１又は２に係る中継サーバにおいて、前記要求は、前記クライアント装置又は当該クライアント装置のユーザの識別情報を含み、前記書き込み部は、前記要求と共に前記識別情報を前記データベースに書き込む。
請求項４に係る中継サーバは、請求項３に係る中継サーバにおいて、前記サーバ装置が停止しているときに前記要求を送信したことが前記データベースに記録されているクライアント装置又は当該クライアント装置のユーザに対し、特典を付与する付与部を有する。
請求項５に係る中継サーバは、請求項４に係る中継サーバにおいて、前記付与部は、前記データベースに記録されている要求の属性に応じた重みを付けて、前記特典を付与する。
請求項６に係る中継サーバは、請求項３乃至５のいずれか一項に係る中継サーバにおいて、前記データベースが、アプリケーションプログラムと、当該アプリケーションプログラムにおいて要求を再送信する機能の有無とを含み、前記要求がアプリケーションプログラムの識別情報を含み、前記書き込み部は、前記受信部が前記要求を受信した場合において当該要求を送信したアプリケーションプログラムが要求を再送信する機能を有すること
が前記データベースに記録されているときは、前記サーバ装置が停止していても、前記要求があった日時を前記データベースに書き込まない。
請求項７に係る中継サーバは、請求項１乃至６のいずれか一項に係る中継サーバにおいて、前記サーバ装置が停止状態から稼働状態に変わったことの通知を受信する第２受信部を有する。
請求項８に係る中継サーバは、請求項１乃至７のいずれか一項に係る中継サーバにおいて、前記サーバ装置が稼働しているか停止しているか監視をする頻度を変更する変更部を有する。
請求項９に係る中継サーバは、請求項８に係る中継サーバにおいて、前記変更部は、前記サーバ装置が停止しているときにあった前記要求の数又は頻度が基準より多い場合、前記監視の頻度を増加させる。
請求項１０に係る中継サーバは、請求項８に係る中継サーバにおいて、前記サーバ装置が停止する予定の時間帯を示す情報を取得する取得部を有し、前記変更部は、前記情報により示される復旧時刻までの時間がしきい値を下回った場合、前記監視の頻度を増加させる。
請求項１１に係る中継サーバは、請求項８乃至１１のいずれか一項に係る中継サーバにおいて、前記監視部が行う前記サーバ装置の監視には、処理が軽い第１手法による監視と、当該第１手法より処理が重い第２手法による監視が含まれ、前記変更部は、前記サーバ装置が稼働しているか停止しているか監視をする手法を変更する。
請求項１２に係る中継サーバは、請求項１１に係る中継サーバにおいて、前記変更部は、監視の頻度を増加させるときは、監視の手法として前記第１手法を用いる。

【発明の効果】

【0006】

請求項１に係る中継サーバによれば、クライアント装置からの要求を受信した場合においてサーバ装置が稼働しているときは、当該要求を当該サーバ装置に転送し、要求を受信した場合においてサーバ装置が停止しているときは、当該要求があった日時をデータベースに書き込むので、クライアント装置の機能によらず、サーバ装置停止時にアクセスを行ったクライアント装置を特定することができる。
請求項２に係る中継サーバによれば、サーバ装置が停止していた時間帯をデータベースに書き込むので、サーバ装置停止時にアクセスを行ったクライアント装置を容易に特定することができる。
請求項３に係る中継サーバによれば、前記要求は、クライアント装置又は当該クライアント装置のユーザの識別情報を含み、書き込み部は、前記要求と共に前記識別情報を前記データベースに書き込むので、サーバ装置停止時にアクセスを行ったクライアント装置を正確に特定することができる。
請求項４に係る中継サーバによれば、サーバ装置が停止しているときに前記要求を送信したクライアント装置又は当該クライアント装置のユーザに対し、特典を付与するので、クライアント装置のユーザからの信頼を高めることができる。
請求項５に係る中継サーバによれば、データベースに記録されている要求の属性に応じた重みを付けて、特典を付与するので、要求の属性に応じた適切な特典を付与することができる。
請求項６に係る中継サーバによれば、要求が受け付けられなかった場合に要求を再送信するアプリケーションプログラムからの要求が受信された場合には、サーバ装置が停止していても、要求があった日時をデータベースに書き込まない。従って、サーバ装置の停止により要求の機会を失ったクライアント装置のみに範囲を絞って、要求日時をデータベースに書き込むことができる。
請求項７に係る中継サーバによれば、サーバ装置が停止状態から稼働状態に変わったことの通知を受信するので、サーバ装置の復旧に迅速に対応することができる。
請求項８に係る中継サーバによれば、サーバ装置が稼働しているか停止しているか監視をする頻度を変更する変更部を有するので、サーバ装置に関する監視負担を適正に制御す
ることができる。
請求項９に係る中継サーバによれば、変更部は、サーバ装置が停止しているときにあった要求の数又は頻度が基準より多い場合、監視の頻度を増加させ、サーバ装置の停止期間の測定精度を高めるので、サーバ装置の停止期間に要求を送信したにも関わらず、その旨の特定がされないクライアント装置、あるいはサーバ装置の稼働期間に要求を送信したにも関わらず、停止期間に要求を送信した旨の特定がされるクライアント装置が発生する確率を低くすることができる。
請求項１０に係る中継サーバによれば、サーバ装置の復旧時刻までの時間がしきい値を下回った場合、前記監視の頻度を増加させるので、上記と同様、サーバ装置の停止期間に要求を送信したにも関わらず、その旨の特定がされないクライアント装置、あるいはサーバ装置の稼働期間に要求を送信したにも関わらず、停止期間に要求を送信した旨の特定がされるクライアント装置が発生する確率を低くすることができる。
請求項１１に係る中継サーバによれば、サーバ装置の監視を、処理が軽い第１手法による監視とするか、当該第１手法より処理が重い第２手法による監視とするかの切り換えを行うので、サーバ装置の監視負担を適正に制御することができる。
請求項１２に係る中継サーバによれば、監視の頻度を増加させるときは、監視の手法として前記第１手法を用いるので、サーバ装置の監視負担を適正に制御することができる。

【図面の簡単な説明】

【0007】

【図1】一実施形態に係るアプリケーションシステムの構成を例示するブロック図。

【図2】中継サーバの構成を例示するブロック図。

【図3】中継サーバにより実行される要求受信処理を例示するフローチャート。

【図4】シリアル番号－ユーザＩＤ対応テーブルを例示する図。

【図5】アクセス日時記録テーブルを例示する図。

【図6】中継サーバにより実行される監視処理を例示するフローチャート。

【図7】停止期間記録テーブルを例示する図。

【図8】第１の動作例を例示するシーケンス図。

【図9】第２の動作例を例示するシーケンス図。

【図10】第３の動作例を例示するシーケンス図。

【図11】停止期間一覧を例示する図。

【図12】アクセス失敗リクエスト一覧を例示する図。

【図13】停止中アクセス回数一覧を例示する図。

【図14】停止遭遇時間一覧を例示する図。

【発明を実施するための形態】

【0008】

１．構成
図１は、本発明の一実施形態に係るアプリケーションシステム１の構成を例示するブロック図である。図１に示すように、アプリケーションシステム１は、中継サーバ１００と、アプリケーションサーバ２００と、ＤＢ（データベース）３００と、クライアント装置４００とを有する。

【0009】

ＤＢ３００には、アプリケーションサーバ２００により実行される各種のアプリケーションプログラムの識別情報と、アプリケーションシステム１を管理、制御するための各種のデータが記憶される。アプリケーションサーバ２００は、クライアント装置４００からの要求に従ってＤＢ３００内のアプリケーションプログラムを実行し、クライアント装置４００にサービスを提供する。アプリケーションサーバ２００は、本実施形態において監視の対処となるサーバ装置の一例である。中継サーバ１００は、クライアント装置４００及びアプリケーションサーバ２００間の中継を行うとともに、アプリケーションサーバ２００の停止への対応を行うサーバである。さらに詳述すると、中継サーバ１００は、アプリケーションサーバ２００が稼働しているか停止しているか監視し、アプリケーションサ
ーバ２００の稼働期間内にクライアント装置４００からアプリケーションサーバ２００への要求を受信した場合には、当該要求をアプリケーションサーバ２００に転送し、アプリケーションサーバ２００の停止期間内にクライアント装置４００からアプリケーションサーバ２００への要求を受信した場合には、当該要求があった日時（タイムスタンプ）をＤＢ３００に書き込む。

【0010】

図２は、中継サーバ１００の構成例を示すブロック図である。この例において、中継サーバ１００は、プロセッサ１０１と、揮発性記憶部及び不揮発性記憶部からなる記憶部１０２と、ネットワークを介して通信を行う機能を備えた通信部１０３と、液晶ディスプレイ等からなる表示部１０４と、キーボードやマウス等の操作子からなる操作部１０５とを有するコンピュータ装置である。記憶部１０２の不揮発性記憶部にはプロセッサ１０１により実行される各種のプログラムが格納されている。アプリケーションサーバ２００も中継サーバ１００と同様な構成を有するコンピュータ装置。クライアント装置４００は、例えば汎用のコンピュータ装置であり、具体的には、パーソナルコンピュータ、タブレット端末、又はスマートフォンである。

【0011】

図１において、中継サーバ１００を示すブロック内には、第１受信部１１１及び第２受信部１１２を含む通信部１１０と、監視部１２０と、転送部１３０と、書き込み部１４０と、付与部１５０と、変更部１６０と、取得部１７０が示されている。これらは図２のプロセッサ１０１が記憶部１０２の不揮発性記憶部内のプログラムを実行することにより実現される機能である。

【0012】

第１受信部１１１は、クライアント装置４００からのアプリケーションサーバ２００への要求を受信する手段である。この要求は、クライアント装置４００又は当該クライアント装置４００のユーザの識別情報を含む。第２受信部１１２は、クライアント装置４００からの要求以外の各種の情報を受信する手段である。

【0013】

監視部１２０は、アプリケーションサーバ２００が稼働しているか停止しているか監視する手段である。転送部１３０は、第１受信部１１１が要求を受信した場合においてアプリケーションサーバ２００が稼働しているとき、当該要求をアプリケーションサーバ２００に転送する手段である。

【0014】

書き込み部１４０は、第１受信部１１１が要求を受信した場合においてアプリケーションサーバ２００が停止しているとき、当該要求があった日時と、当該要求の発生元を特定する識別情報をＤＢ３００に書き込む手段である。また、書き込み部１４０は、監視部１２０における監視の結果を用いて、アプリケーションサーバ２００が停止していた時間帯をＤＢ３００に書き込む。

【0015】

付与部１５０は、アプリケーションサーバ２００が停止しているときに要求を送信したことがＤＢ３００に記録されているクライアント装置４００又は当該クライアント装置４００のユーザに対し、特典を付与する手段である。ここで、付与部１５０は、ＤＢ３００に記録されている要求の属性に応じた重みを付けて、特典を付与する。

【0016】

変更部１６０は、監視部１２０による監視処理に関する制御を行う手段である。取得部１７０は、変更部１６０が行う制御に使用される制御情報を取得する手段である。

【0017】

２．動作
図３は、本実施形態において中継サーバ１００により実行される要求受信処理を示すフローチャートである。この要求受信処理は、第１受信部１１１がクライアント装置４００からの要求を受信することにより実行される。

【0018】

中継サーバ１００の第１受信部１１１は、クライアント装置４００からの要求を受信すると、サーバ停止フラグがＯＮか否かを判断する（ステップＳ１０１）。このサーバ停止フラグは、監視部１２０によって切り換えられるフラグであり、アプリケーションサーバ２００が停止しているときはＯＮ、稼働しているときはＯＦＦとなる。

【0019】

ステップＳ１０１の判断結果が「ＹＥＳ」、すなわち、アプリケーションサーバ２００が停止している場合、中継サーバ１００では、書き込み部１４０が、第１受信部１１１によって受信された要求のあった日時を要求の発生元を特定する識別情報とともにＤＢ３００に書き込む（ステップＳ１２２）。そして、中継サーバ１００の通信部１１０は、要求の発生元であるクライアント装置４００に対し、結果を返信、すなわち、要求が受け付けられなかった旨の情報を送信する（ステップＳ１３１）。これにより要求受信処理は終了となる。

【0020】

一方、ステップＳ１０１の判断結果が「ＮＯ」、すなわち、アプリケーションサーバ２００が稼働している場合、中継サーバ１００では、転送部１３０が、第１受信部１１１によって受信された要求をアプリケーションサーバ２００に転送する（ステップＳ１０２）。そして、中継サーバ１００では、第２受信部１１２が、要求に対する結果をアプリケーションサーバ２００から受信し（ステップＳ１０３）、結果の受信に成功したか否かを判定する（ステップＳ１１１）。

【0021】

ステップＳ１１１の判断結果が「ＹＥＳ」である場合、中継サーバ１００では、通信部１１０が、アプリケーションサーバ２００から返信された結果を要求の送信元であるクライアント装置４００に送信する（ステップＳ１３１）。これにより要求受信処理は終了となる。

【0022】

要求の転送に対して、アプリケーションサーバ２００から結果が正常に返信されなかった場合、あるいは要求の送信から所定時間が経過しても結果の返信がなくタイムアウトになった場合、ステップＳ１１１の判断結果は「ＮＯ」となり、中継サーバ１００では、監視部１２０がサーバ停止フラグをＯＮにする（ステップＳ１２１）。

【0023】

そして、中継サーバ１００では、書き込み部１４０が、第１受信部１１１によって受信された要求の送信元を特定する識別情報とともに要求のあった日時をＤＢ３００に書き込む（ステップＳ１２２）。そして、中継サーバ１００の通信部１１０は、要求の送信元であるクライアント装置４００に対し、要求が受け付けられなかった旨の情報を送信する（ステップＳ１３１）。これにより要求受信処理は終了となる。

【0024】

ステップＳ１２２の処理において、書き込み部１４０は、ＤＢ３００内のシリアル番号－ユーザＩＤ対応テーブルを参照し、ＤＢ３００内のアクセス日時記録テーブルへの書き込みを行う。

【0025】

図４は、ＤＢ３００内のシリアル番号－ユーザＩＤ対応テーブルを示す図である。また、図５は、ＤＢ３００内のアクセス日時記録テーブルを示す図である。

【0026】

本実施形態では、アプリケーションサーバ２００のサービスを受ける全ユーザについてシリアル番号が付与され、各ユーザのシリアル番号とユーザＩＤとを対応付けるシリアル番号－ユーザＩＤ対応テーブルがＤＢ３００内に格納される。ステップＳ１２２の処理において、書き込み部１４０は、シリアル番号－ユーザＩＤ対応テーブルを参照することにより、要求の送信元であるユーザのユーザＩＤからシリアル番号を求め、このシリアル番号を識別情報として要求のあった日時（図５ではアクセス日時）とともにアクセス日時記
録テーブルに書き込む。

【0027】

図６は、本実施形態において中継サーバ１００の監視部１２０により実行される監視処理を示すフローチャートである。まず、監視部１２０は、アプリケーションサーバ２００に対して、アプリケーションサーバ２００が停止中であるか稼働中であるかを確認するための死活確認要求を送信する（ステップＳ２０１）。そして、アプリケーションサーバ２００から死活確認要求に対する結果を受信し（ステップＳ２１１）、アプリケーションサーバ２００が稼働中か否かを判断する（ステップＳ２１２）。

【0028】

アプリケーションサーバ２００が稼働中であることを示す情報が受信された場合、ステップＳ２１２の判断結果は「ＹＥＳ」となり、監視部１２０はサーバ停止フラグをＯＦＦにする（ステップＳ２２１）。

【0029】

一方、アプリケーションサーバ２００が停止中であることを示す情報が受信された場合、あるいはアプリケーションサーバ２００が稼働中であることを示す情報が受信されることなく所定時間が経過してタイムアウトとなった場合、ステップＳ２１２の判断結果は「ＮＯ」となり、監視部１２０はサーバ停止フラグをＯＮにする（ステップＳ２２２）。

【0030】

ステップＳ２２１又はＳ２２２が終了すると、監視部１２０は任意の時間待機する（ステップＳ３３１）。そして、ステップＳ２０１に戻って処理を繰り返す。

【0031】

監視部１２０は、以上の監視処理を繰り返すことによりサーバ停止フラグがＯＦＦからＯＮに変化する停止開始日時と、サーバ停止フラグがＯＮからＯＦＦに変化する停止終了日時を求め、停止開始日時から停止終了日時までの停止期間を示す情報をＤＢ３００内の停止期間テーブルに書き込む。

【0032】

図７は、本実施形態における停止期間テーブルを示す図である。図７に示すように、停止期間テーブルは、アプリケーションサーバ２００の停止期間の各々について停止開始日時と停止終了日時の各情報を示している。

【0033】

図８は、本実施形態の第１の動作例を示すシーケンス図である。この動作例では、クライアント装置４００からの要求が中継サーバ１００によって受信されたとき（ステップＳ３０１）、サーバ停止フラグがＯＦＦであったため、要求が中継サーバ１００からアプリケーションサーバ２００に転送される（ステップＳ３０２）。そして、アプリケーションサーバ２００では要求に応じた処理が実行され、その結果が中継サーバ１００に返信される（ステップＳ３０３）。そして、この処理の結果は中継サーバ１００によってクライアント装置４００に転送される（ステップＳ３０４）。

【0034】

図９は、本実施形態の第２の動作例を示すシーケンス図である。この動作例では、クライアント装置４００からの要求が中継サーバ１００によって受信されたとき（ステップＳ３１１）、サーバ停止フラグがＯＮとなっている。このため、中継サーバ１００によって、ＤＢ３００に、要求のあった日時と要求の発生元の識別情報が書き込まれる（ステップＳ３１２）。そして、中継サーバ１００から要求の発生元であるクライアント装置４００に対し、アプリケーションサーバ２００が停止中のため要求が受け付けられなかった旨の結果が返信される（ステップＳ３１３）。

【0035】

図１０は、本実施形態の第３の動作例を示すシーケンス図である。この動作例では、クライアント装置４００からの要求が中継サーバ１００によって受信されたとき（ステップＳ３２１）、サーバ停止フラグがＯＦＦであったため、要求が中継サーバ１００からアプリケーションサーバ２００に転送される（ステップＳ３２２）。しかしながら、アプリケ
ーションサーバ２００が停止し、あるいは何等かの不具合が発生したため、アプリケーションサーバ２００から中継サーバ１００に結果が返信されない。このため、中継サーバ１００では、サーバ停止フラグがＯＮとされ（ステップＳ３２３）、ＤＢ３００に、要求のあった日時と要求の発生元の識別情報が書き込まれる（ステップＳ３２４）。そして、中継サーバ１００から要求の発生元であるクライアント装置４００に対し、アプリケーションサーバ２００が停止中のため要求が受け付けられなかった旨の結果が返信される（ステップＳ３２５）。

【0036】

次に中継サーバ１００の操作部１０５の操作により実行される各種の処理について説明する。

【0037】

図１１は、中継サーバ１００の表示部１０４に表示されるアプリケーションサーバ２００の停止期間一覧を示す図である。中継サーバ１００では、停止期間の一覧表示を指示する操作部１０５の操作が行われると、付与部１５０がＤＢ３００内の停止期間記録テーブル（図７参照）を参照し、この停止期間の一覧を表示部１０４に表示する。図１１に示すように、表示部１０４には、停止期間の開始日時、終了日時が表示されるとともに、当該停止期間に対応付けて「詳細を見る」の文字列を含むソフトボタン、「削除」の文字列を含むソフトボタンが表示される。

【0038】

ここで、「削除」の文字列を含むソフトボタンを指示する操作が行われると、付与部１５０は、当該ソフトボタンに対応した停止期間に関する情報を停止期間記録テーブルから削除する。一方、「詳細を見る」の文字列を含むソフトボタンを指示する操作が行われると、付与部１５０は、当該ソフトボタンに対応した停止期間に関する詳細な情報、具体的には当該停止期間内におけるアプリケーションサーバ２００への要求の発生状況を示す情報を表示部１０４に表示する。

【0039】

図１２は、本実施形態において表示部１０４に表示されるアクセス失敗リクエスト一覧を示す図である。これは、停止期間内におけるアプリケーションサーバ２００への要求の発生状況を示す情報の第１の例である。このアクセス失敗リクエスト一覧では、「詳細を見る」のソフトボタンにより指示された停止期間内における要求の発生日時と、その要求の発生元を特定するシリアル番号とユーザＩＤとを含む。これらの情報は、アクセス日時記録テーブル（図５参照）に記録された当該停止期間内のアクセス日時及びシリアル番号と、シリアル番号－ユーザＩＤ対応テーブル（図４参照）において当該シリアル番号に対応付けられたユーザＩＤとに基づいて生成される。

【0040】

アクセス失敗リクエスト一覧において、アクセス日時の左側にはチェックボックスが設けられている。また、アクセス失敗リクエスト一覧の下方には、「特典付与」の文字列を含むソフトボタンと、「お詫びのご連絡メール送信」の文字列を含むソフトボタンが表示されている。あるアクセス日時の左側のチェックボックスがチェックされ、「特典付与」の文字列を含むソフトボタンが指示されると、付与部１５０は、チェックボックスのチェックされたアクセス日時におけるアクセスを行ったユーザに対し、例えばライセンスを１つ付与する、といった特典を付与する。また、あるアクセス日時の左側のチェックボックスがチェックされ、「お詫びのご連絡メール送信」の文字列を含むソフトボタンが指示されると、付与部１５０は、チェックボックスのチェックされたアクセス日時におけるアクセスを行ったユーザに対し、お詫びのご連絡メールを送信する。

【0041】

図１３は、本実施形態において表示部１０４に表示される停止中アクセス回数一覧を示す図である。これは、停止期間内におけるアプリケーションサーバ２００への要求の発生状況を示す情報の第２の例である。この停止中アクセス回数一覧は、「詳細を見る」のソフトボタン（図１１参照）により指示された停止期間内に発生した要求をその要求の発生
元であるユーザ毎にまとめ、ユーザ毎に要求の発生回数をカウントしたものである。また、図１３に示す例では、各ユーザについての停止期間内の要求発生回数を回数の多い順に並び替えている。この停止中アクセス回数一覧を生成するに当たって参照する情報は、上述したアクセス失敗リクエスト一覧の場合と同様である。

【0042】

アクセス失敗リクエスト一覧の下方には、「重み付き特典付与」の文字列を含むソフトボタンと、「上位３３％ 中位３３％ 下位３４％」の文字列が表示されている。本実施形態では、「重み付き特典付与」のソフトボタンが指示されると、付与部１５０は、該当する停止期間内に要求を送信したユーザを、アクセス回数が上位３３％以内に該当するグループと、中位３３％以内に該当するグループと、下位３４％以内に該当するグループとに分け、グループ毎に異なる重み付けがされた特典を付与する。このように付与部１５０は、ＤＢ３００に記憶されたユーザの属性、具体的には停止期間内の要求発生回数に応じて重みを付けて特典を付与する。この場合、特典は、ライセンス数の増加の他、ライセンス期間の延長、サービスにおいて使用可能な容量増加、費用割引、クーポン配布等であってもよい。ユーザの属性に応じて特典に重みを付けるのは、ユーザに対し、被った不利益に応じた特典を与えるためでる。

【0043】

図１４は、本実施形態において表示部１０４に表示される停止遭遇時間一覧を示す図である。これは、停止期間内におけるアプリケーションサーバ２００への要求の発生状況を示す情報の第３の例である。この停止遭遇時間一覧は、「詳細を見る」のソフトボタン（図１１参照）により指示された停止期間内に発生した要求をその要求の発生元であるユーザ毎にまとめ、当該ユーザが最初にアクセスを行った停止中初回アクセス日時から最後にアクセスを行った停止中最終アクセス日時までの経過時間を停止遭遇時間として計測したものである。また、図１４に示す例では、各ユーザについての停止期間内の停止遭遇時間を時間の長い順に並び替えている。この停止遭遇時間一覧を生成するに当たって参照する情報は、上述したアクセス失敗リクエスト一覧の場合と同様である。

【0044】

停止遭遇時間一覧の下方には、上述したアクセス失敗リクエスト一覧（図１３参照）と同様、「重み付き特典付与」の文字列を含むソフトボタンと、「上位３３％ 中位３３％
下位３４％」の文字列が表示されている。これらの表示の意味するところは、上述したアクセス失敗リクエスト一覧と同様である。このように付与部１５０は、ＤＢ３００に記憶されたユーザの属性、具体的には停止期間内の停止遭遇時間に応じて重みを付けて特典を付与する。

【0045】

以上説明したように、本実施形態によれば、中継サーバ１００は、クライアント装置４００からの要求を受信した場合においてアプリケーションサーバ２００が稼働しているときは、当該要求をアプリケーションサーバ２００に転送し、要求を受信した場合においてアプリケーションサーバ２００が停止しているときは、当該要求があった日時をＤＢ３００に書き込むので、クライアント装置４００の機能によらず、アプリケーションサーバ２００停止時にアクセスを行ったクライアント装置４００を特定することができる。また、本実施形態によれば、中継サーバ１００、アプリケーションサーバ２００が停止していた時間帯をＤＢ３００に書き込むので、アプリケーションサーバ２００停止時にアクセスを行ったクライアント装置４００を容易に特定することができる。また、本実施形態によれば、クライアント装置４００からの要求は、ユーザの識別情報を含み、書き込み部１４０は、前記要求と共に前記識別情報を前記データベースに書き込むので、アプリケーションサーバ２００にアクセスを行ったクライアント装置４００を正確に特定することができる。また、本実施形態によれば、中継サーバ１００は、アプリケーションサーバ２００が停止しているときに要求を送信したクライアント装置４００又は当該クライアント装置のユーザに対し、特典を付与するので、クライアント装置４００のユーザからの信頼を高めることができる。また、本実施形態によれば、中継サーバ１００は、ＤＢ３００に記録され
ている要求の属性に応じた重みを付けて、特典を付与するので、要求の属性に応じた適切な特典を付与することができる。

【0046】

３．変形例
本発明は上述の実施形態に限定されるものではなく、種々の変形実施が可能である。以下、変形例を説明する。以下の変形例のうち２つ以上のものが組み合わせて用いられてもよい。

【0047】

（１）中継サーバ１００は、クライアント装置４００がアプリケーションサーバ２００に要求を送信するために実行するアプリケーションプログラムのバージョンに応じて対応を変えてもよい。この例において、ＤＢ３００は、アプリケーションサーバ２００に要求を送信するアプリケーションプログラムが要求を再送信する機能の有無を示す情報を、そのアプリケーションプログラムの識別情報と対応付けて格納する。これらの情報は、例えばアプリケーションプログラムの提供事業者によりあらかじめ提供される。また、クライアント装置４００は、上述した要求として、アプリケーションプログラムの識別情報を含む要求を送信する。中継サーバ１００の書き込み部１４０は、第１受信部１１１が要求を受信した場合において当該要求を送信したアプリケーションプログラムが要求を再送信する機能を有することがＤＢ３００に記録されているときは、アプリケーションサーバ２００が停止していても、要求があった日時をＤＢ３００に書き込まない。この態様によれば、要求の再送機能がなく、アプリケーションサーバ２００の停止により要求の機会を失ったクライアント装置４００のみに範囲を絞って、要求日時をＤＢ３００に書き込む。従って、ＤＢ３００を小さくすることができる。

【0048】

（２）アプリケーションサーバ２００が停止状態か稼働状態かを中継サーバ１００が確認する方法は実施形態において例示した方法に限定されない。例えば、中継サーバ１００からアプリケーションサーバ２００に対し問い合わせを送信することに代えて、又は加えて、アプリケーションサーバ２００が、停止状態から稼働状態に変わった場合にその旨の通知を中継サーバ１００に送信してもよい。中継サーバ１００の第２受信部１１２は、この通知を受信して、監視部１２０に引き渡し、監視部１２０がサーバ停止フラグをＯＦＦにする。この態様によれば、アプリケーションサーバ２００の復旧に迅速に対応することができる。

【0049】

（３）変更部１６０は、アプリケーションサーバ２００が稼働しているか停止しているか監視をする頻度を変更してもよい。具体的には、変更部１６０は、ＤＢ３００内のアクセス日時記録テーブル（図５参照）と停止期間記録テーブル（図７参照）を参照することにより、アプリケーションサーバ２００の停止期間内にあった要求の数又は頻度が基準より多いか否かを判断し、基準より多い場合に監視の頻度を増加させる。この態様によれば、アプリケーションサーバ２００に関する監視負担を適正に制御することができる。また、変更部１６０は、アプリケーションサーバ２００の停止期間内の要求の数又は頻度が基準より多い場合、監視の頻度を増加させ、停止期間の測定精度を高めるので、アプリケーションサーバ２００の停止期間に要求を送信したにも関わらず、その旨の特定がされないクライアント装置４００、あるいはアプリケーションサーバ２００の稼働期間に要求を送信したにも関わらず、停止期間に要求を送信した旨の特定がされるクライアント装置４００が発生する確率を低くすることができる。

【0050】

（４）監視部１２０は、処理が軽い第１手法による監視、及び第１手法より処理が重い第２手法による監視を含む複数の監視手法を実行可能であってもよい。この場合において、変更部１６０が、監視部１２０における監視手法を変更するようにしてもよい。具体的には、変更部１６０は、監視の頻度を増加させるときは、監視の手法として第１手法を用いる。処理が軽い第１手法としては、例えばアプリケーションサーバ２００とのコネクショ
ン確立が成功するかどうか確認する手法が考えられる。この処理に要する時間は例えば０．１秒程度である。第１手法より処理が重い第２手法としては、中継サーバ１００からアプリケーションサーバ２００にダミーの処理データを送信し、正しい結果が返ってくるかどうか確認する手法が考えられる。この処理に要する時間は例えば１０秒程度である。この態様によれば、アプリケーションサーバ２００についての監視負担を適正に制御することができる。

【0051】

（５）アプリケーションサーバ２００が停止する予定の時間帯があらかじめ分かっている場合、変更部１６０は、復旧予定時刻が近づいたらアプリケーションサーバ２００の監視の頻度を増加させてもよい。この場合、取得部１７０は、アプリケーションサーバ２００が停止する予定の時間帯を示す情報を取得する。変更部１６０は、この情報により示される復旧時刻までの時間がしきい値を下回った場合、アプリケーションサーバ２００の監視の頻度を増加させる。この態様によれば、アプリケーションサーバ２００の復旧時刻までの時間がしきい値を下回った場合、アプリケーションサーバ２００に関する監視の頻度を増加させるので、上記と同様、アプリケーションサーバ２００の停止期間に要求を送信したにも関わらず、その旨の特定がされないクライアント装置４００、あるいはアプリケーションサーバ２００の稼働期間に要求を送信したにも関わらず、停止期間に要求を送信した旨の特定がされるクライアント装置４００が発生する確率を低くすることができる。

【0052】

（６）アプリケーションシステム１における機能要素とハードウェア要素との対応関係は実施形態において例示したものに限定されない。例えば、複数のコンピュータ装置からなる装置群が全体として中継サーバ１００としての機能を有していてもよい。

【0053】

（７）実施形態において示したＵＩ画面、及び各種の情報はあくまで例示である。例えば、実施形態で示した画面のうち、一部のＵＩ要素は省略されてもよい。また、プロセッサ１０１等により実行されるプログラムは、ＣＤ－ＲＯＭ等の記録媒体に記録されて提供されてもよいし、ネットワーク上のサーバ装置に記憶された状態で提供されてもよい。

【符号の説明】

【0054】

１…アプリケーションシステム、１００…中継サーバ、２００…アプリケーションサーバ、３００…ＤＢ、４００…クライアント装置、１１０…通信部、１１１…第１受信部、１１２…第２受信部、１２０…監視部、１３０…転送部、１４０…書き込み部、１５０…付与部、１６０…変更部、１７０…取得部、１０１…プロセッサ、１０２…記憶部、１０３…通信部、１０４…表示部、１０５…操作部。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】