(57)【要約】【課題】リクエストを適切な順序で送信可能にすること。【解決手段】記憶部１ａは、複数のリクエスト間の関連性に関する情報およびリクエストの送信に関する優先度を該リクエストに対応付けて記憶する。処理部１ｂは、処理の実行に関する第１のリクエストを受信すると、記憶部１ａを参照して、第１のリクエストに関連する第２のリクエストと、第２のリクエストに対応する第１の優先度とを特定する。処理部１ｂは、第１のリクエストに応じた処理を実行する情報処理装置２に、第１の優先度よりも高い第２の優先度で第２のリクエストを送信する。【選択図】図１
2019040344.tif 000002
【特許請求の範囲】
【請求項１】
処理の実行に関する第１のリクエストを受信すると、複数のリクエスト間の関連性に関する情報およびリクエストの送信に関する優先度を該リクエストに対応付けて記憶する記憶部を参照して、前記第１のリクエストに関連する第２のリクエストと、前記第２のリクエストに対応する第１の優先度とを特定し、
受信したリクエストに応じた処理を実行する情報処理装置に、前記第１の優先度よりも高い第２の優先度で前記第２のリクエストを送信する、
処理をコンピュータに実行させることを特徴とする送信制御プログラム。
【請求項２】
前記第１の優先度は、前記第１のリクエストに対応する第３の優先度よりも低い優先度であり、
前記第２の優先度は、前記第３の優先度よりも高い優先度である、
ことを特徴とする請求項１記載の送信制御プログラム。
【請求項３】
前記第３の優先度よりも高い優先度である第３のリクエストと前記第２のリクエストとを含む第４のリクエストを生成し、前記第３の優先度よりも高い優先度で前記第４のリクエストを前記情報処理装置に送信する、ことを特徴とする請求項２記載の送信制御プログラム。
【請求項４】
前記第１のリクエストを受信すると、前記情報処理装置に対する応答待ちリクエスト数が上限値を超過するか否かを判定し、超過する場合に、前記第１のリクエストを前記記憶部に保存し、前記第１のリクエストに関連する前記第２のリクエストを特定し、優先度に応じて前記第１のリクエストおよび前記第２のリクエストの送信順序を決定する、ことを特徴とする請求項１乃至３の何れか１項に記載の送信制御プログラム。
【請求項５】
前記第２のリクエストの送信元が前記第１のリクエストの送信元と同じであるか否かを判定し、同じである場合に、前記第２のリクエストの優先度を前記第１の優先度から前記第２の優先度に変更する、ことを特徴とする請求項２乃至４の何れか１項に記載の送信制御プログラム。
【請求項６】
前記第２のリクエストは、前記情報処理装置に所定の情報を提供するためのリクエストであり、
前記第１のリクエストは、前記情報処理装置に提供された前記所定の情報を取得するためのリクエストである、
ことを特徴とする請求項１乃至５の何れか１項に記載の送信制御プログラム。
【請求項７】
前記第１のリクエストは、前記第１のリクエストの送信元の装置に対するユーザの操作に応じて送信されたリクエストであり、
前記第２のリクエストは、前記送信元の装置によりユーザの操作に依らずに送信されたリクエストである、
ことを特徴とする請求項１乃至６の何れか１項に記載の送信制御プログラム。
【請求項８】
前記記憶部に記憶された前記第１のリクエストに対応する優先度で、前記第１のリクエストを送信する、ことを特徴とする請求項１乃至７の何れか１項に記載の送信制御プログラム。
【請求項９】
複数のリクエスト間の関連性に関する情報およびリクエストの送信に関する優先度を該リクエストに対応付けて記憶する記憶部と、
処理の実行に関する第１のリクエストを受信すると、前記記憶部を参照して、前記第１のリクエストに関連する第２のリクエストと、前記第２のリクエストに対応する第１の優先度とを特定し、受信したリクエストに応じた処理を実行する情報処理装置に、前記第１の優先度よりも高い第２の優先度で前記第２のリクエストを送信する処理部と、
を有することを特徴とする送信制御装置。
【請求項１０】
コンピュータが、
処理の実行に関する第１のリクエストを受信すると、複数のリクエスト間の関連性に関する情報およびリクエストの送信に関する優先度を該リクエストに対応付けて記憶する記憶部を参照して、前記第１のリクエストに関連する第２のリクエストと、前記第２のリクエストに対応する第１の優先度とを特定し、
受信したリクエストに応じた処理を実行する情報処理装置に、前記第１の優先度よりも高い第２の優先度で前記第２のリクエストを送信する、
ことを特徴とする送信制御方法。
【請求項１１】
送信に関する優先度が対応付けられたリクエストを情報処理装置に送信する送信制御プログラムにおいて、
処理の実行に関する特定のリクエストを受信すると、複数のリクエスト間の関連性に関する情報を記憶する記憶部を参照して、受信した前記リクエストに関連する他のリクエストを特定し、
特定した前記他のリクエストを前記情報処理装置に送信する優先度を、前記他のリクエストに対応付けられた優先度よりも高める制御を実行する、
処理をコンピュータに実行させることを特徴とする送信制御プログラム。
【請求項１２】
送信に関する優先度が対応付けられたリクエストを情報処理装置に送信する送信制御装置において、
複数のリクエスト間の関連性に関する情報を記憶する記憶部と、
処理の実行に関する特定のリクエストを受信すると、前記記憶部を参照して、受信した前記リクエストに関連する他のリクエストを特定し、特定した前記他のリクエストを前記情報処理装置に送信する優先度を、前記他のリクエストに対応付けられた優先度よりも高める制御を実行する処理部と、
を有することを特徴とする送信制御装置。
【請求項１３】
送信に関する優先度が対応付けられたリクエストを情報処理装置に送信する送信制御方法において、コンピュータが、
処理の実行に関する特定のリクエストを受信すると、複数のリクエスト間の関連性に関する情報を記憶する記憶部を参照して、受信した前記リクエストに関連する他のリクエストを特定し、
特定した前記他のリクエストを前記情報処理装置に送信する優先度を、前記他のリクエストに対応付けられた優先度よりも高める制御を実行する、
ことを特徴とする送信制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は送信制御プログラム、送信制御装置および送信制御方法に関する。
【背景技術】
【０００２】
現在、複数の情報処理装置がネットワークを介して通信する情報処理システムが利用されている。例えば、クライアントサーバシステムでは、サービスを提供する装置（サーバと呼ばれる）と、サービスを利用する装置（クライアントと呼ばれる）とがネットワークを介して通信する。クライアントは、サーバに対するリクエストを送信する。サーバは、リクエストを受信し、リクエストに応じたレスポンスをクライアントに送信する。
【０００３】
ここで、クライアントとサーバとの間に、クライアントのリクエストを受信してサーバへのアクセスを代行する制御装置を設け、制御装置の機能によりサーバに送信するリクエストの数を制限することがある。
【０００４】
例えば、クライアントからリクエストを受信し、受信したリクエストを蓄積してサーバに送信する負荷制御装置の提案がある。負荷制御装置は、サーバからの応答待ちリクエスト数が閾値に達しているならば、受信したリクエストをバッファに一時蓄積し、応答待ちリクエスト数が閾値を下回るまでバッファからのリクエストの送信を待ち合わせることで、応答待ちリクエスト数を制限する。この提案では、バッファ中のリクエストの実行順序に関し、リクエストの重要度や要求品質に応じて優先制御を行うことも考えられている。具体的には、負荷制御装置は、クラス別にリクエストをキューに格納し、各キュー間のリクエスト取り出し順序を、所定のスケジューリングアルゴリズム（Priority Queuing、Waited Fair QueuingまたはWaited Round Robin）を利用して決める。
【０００５】
なお、モバイルデバイス上にローカルプロキシを設けて、モバイルネットワークトラフィックを調整するシステムの提案もある。ローカルプロキシは、第１のアプリケーションによって開始された第１のデータ転送要求の転送を、第２のアプリケーションによって開始された第２のデータ転送要求がモバイルデバイス上で検出されるまで、遅延させる。そして、ローカルプロキシは、第１，第２の転送要求を単一の転送作動で転送する。
【０００６】
また、複数のサービス提供部を備えるサーバ装置に、外部装置と複数のサービス提供部との間の通信を仲介する仲介機能部の機能を付加する提案もある。この提案では、仲介機能部により、外部装置とサーバ装置との間で、複数のサービス提供部の動作に係るＳＯＡＰ（Simple Object Access Protocol）リクエストおよびＳＯＡＰレスポンスを複数一括して送受信する。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】国際公開第２００７／１２５９４２号
【特許文献２】特表２０１３−５４１２３８号公報
【特許文献３】特開２００５−３２２２２２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
上記のように、クライアントとサーバとの間に設けられた制御装置により、サーバに送信するリクエストの数を制限することがある。このとき、制御装置により、リクエストに関して予め定められた優先度を基に、蓄積した複数のリクエストをサーバへ送信する順序を決定することが考えられる。しかし、予め定められた優先度が常に適切とは限らない。
【０００９】
例えば、第１のリクエストに対するサーバのレスポンスの内容が、第２のリクエストに応じたサーバの処理結果の影響を受けることもある。この場合、第２のリクエストの優先度が比較的低いと、制御装置が第１，第２のリクエストを含む複数のリクエストを同時に受信したときに、第２のリクエストのサーバへの送信が遅延することがある。第２のリクエストのサーバへの送信が遅延すると、サーバは、第１のリクエストに対する応答に、第２のリクエストによる処理結果を反映できない可能性がある。したがって、クライアントは、第１のリクエストに対して、第２のリクエストによる処理結果が反映された最新の状態の応答を得られないことがあるという問題がある。
【００１０】
１つの側面では、本発明は、リクエストを適切な順序で送信可能にすることを目的とする。
【課題を解決するための手段】
【００１１】
１つの態様では、送信制御プログラムが提供される。送信制御プログラムは、処理の実行に関する第１のリクエストを受信すると、複数のリクエスト間の関連性に関する情報およびリクエストの送信に関する優先度を該リクエストに対応付けて記憶する記憶部を参照して、第１のリクエストに関連する第２のリクエストと、第２のリクエストに対応する第１の優先度とを特定し、受信したリクエストに応じた処理を実行する情報処理装置に、第１の優先度よりも高い第２の優先度で第２のリクエストを送信する、処理をコンピュータに実行させる。
【００１２】
また、１つの態様では、送信に関する優先度が対応付けられたリクエストを情報処理装置に送信する送信制御プログラムが提供される。送信制御プログラムは、処理の実行に関する特定のリクエストを受信すると、複数のリクエスト間の関連性に関する情報を記憶する記憶部を参照して、受信したリクエストに関連する他のリクエストを特定し、特定した他のリクエストを情報処理装置に送信する優先度を、他のリクエストに対応付けられた優先度よりも高める制御を実行する、処理をコンピュータに実行させる。
【発明の効果】
【００１３】
１つの側面では、リクエストを適切な順序で送信できる。
【図面の簡単な説明】
【００１４】
【図１】第１の実施の形態の送信制御装置を示す図である。
【図２】第２の実施の形態の情報処理システムを示す図である。
【図３】リバースプロキシサーバのハードウェア例を示す図である。
【図４】リバースプロキシサーバの機能例を示す図である。
【図５】リクエスト関連テーブルの例を示す図である。
【図６】優先度テーブルの例を示す図である。
【図７】リバースプロキシサーバの処理例を示すフローチャートである。
【図８】優先度制御の例を示すフローチャートである。
【図９】リクエストの優先度の変更例を示す図である。
【図１０】リクエストの送信例（その１）を示す図である。
【図１１】リクエストの送信例（その２）を示す図である。
【図１２】リクエスト送信の比較例を示す図である。
【図１３】第３の実施の形態のマルチパートのリクエストの例を示す図である。
【図１４】リクエスト送信元管理テーブルの例を示す図である。
【図１５】リバースプロキシサーバの処理例を示すフローチャートである。
【図１６】通信例（その１）を示す図である。
【図１７】通信例（その２）を示す図である。
【発明を実施するための形態】
【００１５】
以下、本実施の形態について図面を参照して説明する。
［第１の実施の形態］
図１は、第１の実施の形態の送信制御装置を示す図である。送信制御装置１は、ネットワーク（図示を省略している）に接続されており、ネットワークを介して、情報処理装置２および端末装置３，４と通信する。送信制御装置１は、端末装置３，４により送信されたリクエストを受信する。送信制御装置１は、受信したリクエストを一時的に記憶し、情報処理装置２に送信する。送信制御装置１は、リクエストに対するレスポンスを情報処理装置２から受信し、リクエストの送信元の端末装置３，４に送信する。
【００１６】
ここで、端末装置３，４は、あるユーザにより利用されている。送信制御装置１は、情報処理装置２に対する同時接続数の上限値Ｎ（Ｎは１以上の整数）をユーザ毎に管理する。同時接続数は、応答待ちリクエストの数に相当する。応答待ちリクエストは、情報処理装置２に送信したリクエストのうち、情報処理装置２からのレスポンスを未受信であるリクエストである。
【００１７】
送信制御装置１は、端末装置３，４による情報処理装置２に対する同時接続数Ｍ（Ｍは０以上の整数）が上限値Ｎに達していない場合、端末装置３，４からリクエストを受信すると、当該リクエストを情報処理装置２に直ちに送信する。一方、送信制御装置１は、同時接続数Ｍが上限値Ｎに達した場合、端末装置３，４からリクエストを受信すると、同時接続数Ｍが上限値Ｎを下回るまで当該リクエストを一時的に記憶する。そして、送信制御装置１は、同時接続数Ｍが上限値Ｎを下回ると、一時的に記憶した複数のリクエストを、各リクエストに対する優先度に応じた順番で、情報処理装置２に送信する。
【００１８】
送信制御装置１は、各リクエストに対する優先度を制御する機能を提供する。送信制御装置１は、記憶部１ａおよび処理部１ｂを有する。
記憶部１ａは、ＲＡＭ（Random Access Memory）などの揮発性記憶装置でもよいし、ＨＤＤ（Hard Disk Drive）やフラッシュメモリなどの不揮発性記憶装置でもよい。処理部１ｂは、ＣＰＵ（Central Processing Unit）、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）などを含み得る。処理部１ｂはプログラムを実行するプロセッサでもよい。「プロセッサ」は、複数のプロセッサの集合（マルチプロセッサ）も含み得る。
【００１９】
記憶部１ａは、リクエストのバッファとして用いられる。また、記憶部１ａは、リクエスト関連情報５および優先度情報６を記憶する。
リクエスト関連情報５は、複数のリクエスト間の関連性に関する情報である。２つのリクエストの関連性は、一方のリクエストに対する情報処理装置２の処理結果が、他方のリクエストに対する情報処理装置２の応答に影響を及ぼすという関係を示す。
【００２０】
例えば、リクエスト関連情報５には、関連のある２つのリクエストの種別の組を示す情報が登録される。より具体的には、リクエスト関連情報５には、種別“ｔｙｐｅ１”および種別“ｔｙｐｅ２”というレコードが登録されている。このレコードは、リクエストの種別が“ｔｙｐｅ１”および“ｔｙｐｅ２”である２つのリクエストは、関連があることを示す。このうち、前者の種別“ｔｙｐｅ１”は、下記の優先度制御の契機となる予め特定された種別である。
【００２１】
リクエストの種別とは、例えば、リクエストに応じた処理の内容や当該処理で扱われるデータの種類などに応じて分類される。一例では、リクエストは、ＨＴＴＰ（HyperText Transfer Protocol）によるリクエスト（ＨＴＴＰリクエスト）である。この場合、種別は、例えば、ＨＴＴＰリクエストメッセージのヘッダにおけるリクエスト行のパス名によって分類されてもよい。あるいは、種別は、当該ヘッダにおけるＨｏｓｔ名あるいはＨｏｓｔ名とパス名との組合せによって分類されてもよい。
【００２２】
優先度情報６は、優先度をリクエストに対応付けて記録した情報である。例えば、優先度情報６には、リクエストの種別に対して、優先度が登録される。より具体的には、種別“ｔｙｐｅ３”のリクエストの優先度は“１”である。種別“ｔｙｐｅ１”の優先度は“２”である。種別“ｔｙｐｅ４”の優先度は“３”である。種別“ｔｙｐｅ２”の優先度は“４”である。本例では、優先度の数値が小さいほど、優先される度合が高く、優先度の数値が大きいほど、優先される度合が低いものとする。すなわち、優先度情報６の例によれば、種別“ｔｙｐｅ３”のリクエストの優先度が最も高い。２番目に、種別“ｔｙｐｅ１”のリクエストの優先度が高い。３番目に、種別“ｔｙｐｅ４”のリクエストの優先度が高い。そして、種別“ｔｙｐｅ２”のリクエストの優先度が最も低い。
【００２３】
ここで、予め優先度が定められた、関連性のある２つのリクエストとしては、種々の例が考えられる。例えば、優先度が高い方のリクエストが端末装置３を利用するユーザによるログの取得要求を示す種別であり、優先度が低い方のリクエストが端末装置３から情報処理装置２へのログの定期的な自動送信を示す種別である場合が考えられる。あるいは、優先度が高い方のリクエストが端末装置３を利用するユーザによるジョブの実行完了の確認要求を示す種別であり、優先度が低い方のリクエストが端末装置３から情報処理装置２へのジョブの実行完了報告を示す種別である場合が考えられる。ただし、関連性のある２つのリクエストの例はこれらに限られるものではない。
【００２４】
処理部１ｂは、情報処理装置２における処理の実行に関する第１のリクエストを受信すると、記憶部１ａを参照して、第１のリクエストに関連する第２のリクエストを特定する。例えば、処理部１ｂは、情報処理装置２に対する同時接続数が上限値Ｎに達している状態で、リクエストＲ１，Ｒ２を端末装置３から受信し、リクエストＲ３，Ｒ４を端末装置４から受信する。処理部１ｂは、リクエストＲ１，Ｒ２，Ｒ３，Ｒ４を記憶部１ａに格納する（バッファリング）。
【００２５】
ここで、リクエストＲ１の種別は“ｔｙｐｅ１”である。したがって、リクエストＲ１（第１のリクエスト）は、特定の種別に対応する特定のリクエストである。リクエストＲ２の種別は“ｔｙｐｅ２”である。リクエストＲ３の種別は“ｔｙｐｅ３”である。リクエストＲ４の種別は“ｔｙｐｅ４”である。
【００２６】
例えば、処理部１ｂは、記憶部１ａに記憶されたリクエスト関連情報５を参照して、リクエストＲ１（第１のリクエスト）に関連するリクエストＲ２（第２のリクエスト）を特定する。
【００２７】
処理部１ｂは、記憶部１ａに記憶された優先度情報６を参照して、第２のリクエストに対応する第１の優先度を特定する。例えば、処理部１ｂは、優先度情報６を参照して、種別“ｔｙｐｅ２”であるリクエストＲ２（第２のリクエスト）に対応する第１の優先度“４”を特定する。
【００２８】
そして、処理部１ｂは、第１の優先度よりも高い第２の優先度で第２のリクエストを情報処理装置２に送信する。例えば、処理部１ｂは、第１の優先度“４”よりも高い第２の優先度でリクエストＲ２を情報処理装置２に送信する。これにより、優先度情報６に設定された優先度で送信するよりも早く、リクエストＲ２が情報処理装置２に送信される可能性を高められる。なお、処理部１ｂにより変更された優先度は、優先度情報６に反映されるものではなく、今回限りの一時的なものである。
【００２９】
処理部１ｂは、リクエストＲ１の優先度“２”よりも高い優先度“１”を、第２の優先度としてもよい。このとき、例えば、端末装置３，４による同時接続数の上限値Ｎ＝２とすると、処理部１ｂは、リクエストＲ１，Ｒ２，Ｒ３，Ｒ４を次の順番で情報処理装置２に送信する。
【００３０】
まず、処理部１ｂは、優先度が“１”であるリクエストＲ３と変更後の優先度が“１”であるリクエストＲ２とを、順次、情報処理装置２に送信する（ステップＳ１）。
次に、処理部１ｂは、優先度が“２”であるリクエストＲ１と優先度が“３”であるリクエストＲ４とを、順次、情報処理装置２に送信する（ステップＳ２）。すなわち、処理部１ｂは、記憶部１ａに記憶されたリクエストＲ１に対応する優先度でリクエストＲ１を送信する。こうして、処理部１ｂは、リクエストＲ１よりも早くリクエストＲ２を情報処理装置２に送信することができる。
【００３１】
このように、処理部１ｂは、処理の実行に関する特定のリクエストを受信すると、記憶部１ａを参照して、受信したリクエストに関連する他のリクエストを特定する。そして、処理部１ｂは、特定した他のリクエストを情報処理装置２に送信する優先度を、他のリクエストに対応付けられた優先度よりも高める制御を実行する。
【００３２】
ここで、リクエストＲ１に対する情報処理装置２の応答が、リクエストＲ２の処理結果の影響を受けることがある。この場合、処理部１ｂは、リクエストＲ１，Ｒ２を受信してバッファリングしているときに、優先度情報６に登録された優先度に従い、リクエストＲ１，Ｒ２の順番で、情報処理装置２に送信することも考えられる。しかし、リクエストＲ１の方がリクエストＲ２よりも先に情報処理装置２に送信されると、リクエストＲ１に対する情報処理装置２の応答に、送信制御装置１に到着済のリクエストＲ２に対する情報処理装置２の処理結果が反映されないことになる。すなわち、情報処理装置２からの端末装置３に対する応答は最新の情報ではないことになる。この場合、端末装置３は、最新の情報を得るために、情報処理装置２に対するリクエストを再送することになる。
【００３３】
そこで、送信制御装置１は、リクエストＲ１，Ｒ２を受信してバッファリングしている場合に、リクエストＲ２を特定し、リクエストＲ２の優先度を優先度情報６に設定された優先度よりも高める制御を行う。これにより、予め設定された優先度に従うよりも、リクエストＲ２が情報処理装置２に送信されるタイミングを早められる。
【００３４】
前述のように、処理部１ｂは、リクエストＲ２の優先度をリクエストＲ１の優先度より高めてもよい。このようにすると、リクエストＲ２が情報処理装置２に送信されるタイミングを一層早めることができる。特に、リクエストＲ２がリクエストＲ１よりも先に情報処理装置２に送信される可能性を高められる。
【００３５】
リクエストＲ２が情報処理装置２に送信されるタイミングを早めることで、リクエストＲ１に対する情報処理装置２の応答に、リクエストＲ２に対する情報処理装置２の処理結果が反映される可能性も高まる。したがって、端末装置３がリクエストＲ１に対して最新の状態の応答を得られる可能性が高まる。
【００３６】
こうして、送信制御装置１は、適切な順番でリクエストを情報処理装置２に送信することで、端末装置３に対して期待される応答（例えば、最新の情報）を提供することができる。また、端末装置３により余計なリクエストが再送されることを抑え、ネットワークの負荷を抑えられる。
【００３７】
以下では、より具体的な情報処理システムを例示して、送信制御装置１の機能を更に詳細に説明する。
［第２の実施の形態］
図２は、第２の実施の形態の情報処理システムを示す図である。第２の実施の形態の情報処理システムは、リバースプロキシサーバ１００、Ｗｅｂサーバ２００およびクライアント３００，４００を有する。リバースプロキシサーバ１００、Ｗｅｂサーバ２００およびクライアント３００，４００は、ネットワーク１０に接続されている。ネットワーク１０は、ＬＡＮ（Local Area Network）やインターネットを含んでもよい。
【００３８】
リバースプロキシサーバ１００は、リバースプロキシ機能を提供するサーバコンピュータである。リバースプロキシサーバ１００は、クライアント３００，４００からＷｅｂサーバ２００へのリクエストの送信を仲介する。また、リバースプロキシサーバ１００は、Ｗｅｂサーバ２００からクライアント３００，４００へのレスポンスの送信を仲介する。
【００３９】
ここで、リクエストおよびレスポンスは、ＨＴＴＰのメッセージである。リバースプロキシサーバ１００は、クライアント３００，４００からリクエストを受信し、Ｗｅｂサーバ２００に対する同時接続数の上限に達しないように、Ｗｅｂサーバ２００へのリクエストの送信を制御する。同時接続数の制限により、リバースプロキシサーバ１００は、Ｗｅｂサーバ２００の負荷を削減し得る。
【００４０】
なお、リバースプロキシサーバ１００は、第１の実施の形態の送信制御装置１の一例である。また、リバースプロキシサーバ１００は、ＳＳＬ（Secure Sockets Layer）アクセラレータなどのアプライアンスに組み込まれてもよい。
【００４１】
Ｗｅｂサーバ２００は、Ｗｅｂサーバ機能を提供するサーバコンピュータである。Ｗｅｂサーバ２００は、リバースプロキシサーバ１００からリクエストを受信し、リクエストに応じた処理を実行する。Ｗｅｂサーバ２００は、実行結果を示すレスポンスをリバースプロキシサーバ１００に送信する。Ｗｅｂサーバ２００は、第１の実施の形態の情報処理装置２の一例である。
【００４２】
クライアント３００，４００は、ユーザによって利用されるクライアントコンピュータである。クライアント３００，４００は、Ｗｅｂブラウザとして機能し、リバースプロキシサーバ１００にリクエストを送信する。リクエストは、リバースプロキシサーバ１００によるＡＰＩ（Application Programming Interface）の実行要求であり、「ＡＰＩ実行リクエスト」と呼ばれてもよい。また、クライアント３００，４００は、リバースプロキシサーバ１００から、リクエストに応じたレスポンスを受信する。クライアント３００，４００は、第１の実施の形態の端末装置３，４の一例である。
【００４３】
ここで、クライアント３００，４００により送信されるリクエストには、ユーザ操作リクエストおよび自動実行リクエストの２種類が含まれる。ユーザ操作リクエストは、クライアント３００，４００に対するユーザの操作に応じて送信されるリクエストである。例えば、ユーザ操作リクエストには、ユーザの操作入力に応じたログの取得要求や、ジョブの実行完了の確認要求などがある。
【００４４】
自動実行リクエストは、クライアント３００，４００により実行される所定のソフトウェアによって自動的に（すなわち、ユーザの操作に依らずに）送信されるリクエストである。例えば、自動実行リクエストには、Ｗｅｂサーバ２００との疎通確認やセッション維持を行うためのリクエストが考えられる。また、自動実行リクエストには、クライアント３００，４００のログをＷｅｂサーバ２００に提供するためのリクエストやクライアント３００，４００によるジョブの実行完了を通知するためのリクエストなどが考えられる。
【００４５】
クライアント３００，４００を利用するユーザには、Ｗｅｂサーバ２００に対する同時接続数の上限が予め定められている。例えば、同時接続数の上限は、リバースプロキシサーバ１００およびＷｅｂサーバ２００を提供する事業者と、クライアント３００，４００を利用するユーザ（テナント）との間の契約によって定められてもよい。または、リバースプロキシサーバ１００およびＷｅｂサーバ２００を提供する組織と、クライアント３００，４００を利用するユーザが属する組織とが同一であれば、当該組織のポリシーによって、ユーザ（例えば、部門）毎の同時接続数の上限が定められてもよい。
【００４６】
図３は、リバースプロキシサーバのハードウェア例を示す図である。リバースプロキシサーバ１００は、プロセッサ１０１、ＲＡＭ１０２、ＨＤＤ１０３、画像信号処理部１０４、入力信号処理部１０５、媒体リーダ１０６およびＮＩＣ（Network Interface Card）１０７を有する。各ハードウェアはリバースプロキシサーバ１００のバスに接続されている。Ｗｅｂサーバ２００やクライアント３００，４００もリバースプロキシサーバ１００と同様のハードウェアを用いて実現できる。
【００４７】
プロセッサ１０１は、リバースプロキシサーバ１００の情報処理を制御するハードウェアである。プロセッサ１０１は、マルチプロセッサであってもよい。プロセッサ１０１は、例えばＣＰＵ、ＤＳＰ、ＡＳＩＣまたはＦＰＧＡなどである。プロセッサ１０１は、ＣＰＵ、ＤＳＰ、ＡＳＩＣ、ＦＰＧＡなどのうちの２以上の要素の組み合わせであってもよい。
【００４８】
ＲＡＭ１０２は、リバースプロキシサーバ１００の主記憶装置である。ＲＡＭ１０２は、プロセッサ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部を一時的に記憶する。また、ＲＡＭ１０２は、プロセッサ１０１による処理に用いる各種データを記憶する。
【００４９】
ＨＤＤ１０３は、リバースプロキシサーバ１００の補助記憶装置である。ＨＤＤ１０３は、内蔵した磁気ディスクに対して、磁気的にデータの書き込みおよび読み出しを行う。ＨＤＤ１０３は、ＯＳのプログラム、アプリケーションプログラム、および各種データを記憶する。リバースプロキシサーバ１００は、フラッシュメモリやＳＳＤ（Solid State Drive）などの他の種類の補助記憶装置を備えてもよく、複数の補助記憶装置を備えてもよい。
【００５０】
画像信号処理部１０４は、プロセッサ１０１からの命令に従って、リバースプロキシサーバ１００に接続されたディスプレイ１１に画像を出力する。ディスプレイ１１として、ＣＲＴ（Cathode Ray Tube）ディスプレイや液晶ディスプレイなどを用いることができる。
【００５１】
入力信号処理部１０５は、リバースプロキシサーバ１００に接続された入力デバイス１２から入力信号を取得し、プロセッサ１０１に出力する。入力デバイス１２として、例えば、マウスやタッチパネルなどのポインティングデバイス、キーボードなどを用いることができる。
【００５２】
媒体リーダ１０６は、記録媒体１３に記録されたプログラムやデータを読み取る装置である。記録媒体１３として、例えば、フレキシブルディスク（ＦＤ：Flexible Disk）やＨＤＤなどの磁気ディスク、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）などの光ディスク、光磁気ディスク（ＭＯ：Magneto-Optical disk）を使用できる。また、記録媒体１３として、例えば、フラッシュメモリカードなどの不揮発性の半導体メモリを使用することもできる。媒体リーダ１０６は、例えば、プロセッサ１０１からの命令に従って、記録媒体１３から読み取ったプログラムやデータをＲＡＭ１０２またはＨＤＤ１０３に格納する。
【００５３】
ＮＩＣ１０７は、ネットワーク１０を介して他の装置と通信を行う。ＮＩＣ１０７は、有線通信インタフェースでもよいし、無線通信インタフェースでもよい。
図４は、リバースプロキシサーバの機能例を示す図である。リバースプロキシサーバ１００は、記憶部１１０、通信処理部１２０および優先度制御部１３０を有する。記憶部１１０は、ＲＡＭ１０２や記憶部１１０の記憶領域により実現される。通信処理部１２０および優先度制御部１３０は、プロセッサ１０１により実現される。例えば、プロセッサ１０１は、ＲＡＭ１０２に記憶されたプログラムを実行することで、通信処理部１２０および優先度制御部１３０の機能を発揮する。ただし、通信処理部１２０および優先度制御部１３０は、ＦＰＧＡやＡＳＩＣなどのハードワイヤードロジックにより実現されてもよい。
【００５４】
記憶部１１０は、クライアント３００，４００から受信したリクエストのキャッシュとして用いられる。記憶部１１０は、リクエスト関連テーブルを記憶する。リクエスト関連テーブルは、複数のリクエストの間の関連を示す情報である。また、記憶部１１０は、優先度テーブルを記憶する。優先度テーブルは、リクエスト毎の優先度を示す情報である。
【００５５】
通信処理部１２０は、クライアント３００，４００により送信されたリクエストを受信し、受信したリクエストをＷｅｂサーバ２００に転送する。また、通信処理部１２０は、リクエストに応じてＷｅｂサーバ２００により送信されたレスポンスを受信し、受信したレスポンスをクライアント３００，４００に転送する。
【００５６】
通信処理部１２０は、クライアント３００，４００に対して定められた同時接続数の上限に達しないように、Ｗｅｂサーバ２００に対して送信するリクエストの数を制限する。同時接続数は、例えば、Ｗｅｂサーバ２００に送信したリクエストのうち、Ｗｅｂサーバ２００からのレスポンスを未受信であるリクエストの数である。通信処理部１２０は、同時接続数の上限を超えた数のリクエストを受信すると、受信したリクエストを記憶部１１０に格納する（バッファリング）。
【００５７】
通信処理部１２０は、優先度テーブルおよび優先度制御部１３０により決定された優先度に応じた順序で、バッファリングされたリクエストをＷｅｂサーバ２００に送信する。
優先度制御部１３０は、記憶部１１０に格納されたリクエストに対する優先度の制御を行う。優先度制御部１３０は、記憶部１１０に格納された複数のリクエストの中から、リクエスト関連テーブルに基づいて関連性のあるリクエストを特定し、特定したリクエストの優先度を変更する。優先度制御部１３０は、変更後の優先度を通信処理部１２０に通知する。なお、優先度制御部１３０による優先度の変更は、今回限りの一時的な設定変更であり、記憶部１１０に記憶された優先度テーブルの設定内容が変更されるわけではない。
【００５８】
図５は、リクエスト関連テーブルの例を示す図である。リクエスト関連テーブル１１１は、記憶部１１０に予め格納されている。リクエスト関連テーブル１１１は、ユーザ操作リクエストおよび自動実行リクエストの項目を含む。
【００５９】
ユーザ操作リクエストの項目には、ユーザ操作リクエストの種別を示すＵＲＬ（Uniform Resource Locator）が登録される。ユーザ操作リクエストは、優先度制御部１３０による優先度制御の契機となる特定のリクエストとして、リクエスト関連テーブル１１１に設定される。ＵＲＬは、ホスト名とパス名との組合せを含む。自動実行リクエストの項目には、自動実行リクエストの種別を示すＵＲＬが登録される。
【００６０】
ここで、ＵＲＬは、Ｗｅｂサーバ２００により提供されるサービスあるいはコンテンツに対応する識別情報であり、クライアント３００，４００により指定されるＵＲＬである。ただし、クライアント３００，４００によって指定されるＵＲＬは、リバースプロキシサーバ１００へリクエストを送信するためのＵＲＬとなっている。リバースプロキシサーバ１００は、クライアント３００，４００から受信したリクエストに含まれるＵＲＬを、Ｗｅｂサーバ２００における該当のサービスまたはコンテンツに対応するＵＲＬに変換して、当該リクエストをＷｅｂサーバ２００に転送する。
【００６１】
例えば、リクエスト関連テーブル１１１には、ユーザ操作リクエストが“ｈｔｔｐｓ：／／ｘｘｘ”、自動実行リクエストが“ｈｔｔｐｓ：／／ａａａ”というレコードが登録されている。このレコードは、ユーザ操作リクエスト“ｈｔｔｐｓ：／／ｘｘｘ”と自動実行リクエスト“ｈｔｔｐｓ：／／ａａａ”とが関連していることを示す。
【００６２】
ここで、自動実行リクエスト“ｈｔｔｐｓ：／／ａａａ”は、例えば、Ｗｅｂサーバ２００にログなどの所定の情報を提供するためのリクエストである。また、ユーザ操作リクエストは、例えば、Ｗｅｂサーバ２００に提供された当該ログなどの所定の情報を取得するためのリクエストである。
【００６３】
図６は、優先度テーブルの例を示す図である。優先度テーブル１１２は、記憶部１１０に予め格納されている。優先度テーブル１１２は、優先度およびリクエストの項目を含む。
【００６４】
優先度の項目には、優先度を示す数値が登録される。優先度を示す数値が小さいほど、優先される度合が高いものとする。リクエストの項目には、リクエストの種別を示すＵＲＬが登録される。
【００６５】
例えば、優先度テーブル１１２には、優先度が“１”、リクエストが“ｈｔｔｐｓ：／／１１１”という情報が登録されている。これは、リクエスト“ｈｔｔｐｓ：／／１１１”の優先度が“１”であることを示す。
【００６６】
ここで、優先度“１”は、最高の優先度である。優先度“１”に対応付けられるリクエストは、主に、Ｗｅｂサーバ２００に対して重要性の高いメッセージ（例えば、クライアントにおける障害発生時のエラーなど）を通知するための自動実行リクエストである。
【００６７】
優先度“２”は、中間の優先度である。優先度“２”に対応付けられるリクエストは、主に、ユーザ操作リクエストである。
優先度“３”は、最低の優先度である。優先度“３”に対応付けられるリクエストは、主に、Ｗｅｂサーバ２００に対して重要性の低いメッセージ（例えば、クライアントにおいて取得されたログなど）を通知するための自動実行リクエストである。
【００６８】
次に、リバースプロキシサーバ１００による処理手順を説明する。
図７は、リバースプロキシサーバの処理例を示すフローチャートである。以下、図７に示す処理をステップ番号に沿って説明する。例えば、リバースプロキシサーバ１００は、下記の手順を所定の周期（例えば、１００ミリ秒や１秒など）で実行する。
【００６９】
（Ｓ１１）通信処理部１２０は、クライアント３００，４００から受信したリクエストを記憶部１１０に蓄積し、蓄積したリクエストの数が、同時接続数の上限値Ｎよりも大きいか否かを判定する。蓄積したリクエストの数が上限値Ｎよりも大きい場合、通信処理部１２０は、ステップＳ１３に処理を進める。蓄積したリクエストの数が上限値Ｎ以下の場合、通信処理部１２０は、ステップＳ１２に処理を進める。
【００７０】
（Ｓ１２）通信処理部１２０は、全てのリクエストをＷｅｂサーバ２００に送信する。そして、通信処理部１２０は、処理を終了する。
（Ｓ１３）通信処理部１２０は、記憶部１１０に蓄積されたリクエストのうち、ユーザ操作リクエストの数が同時接続数の上限値Ｎ以下であるか否かを判定する。ユーザ操作リクエストの数が上限値Ｎ以下である場合、通信処理部１２０は、ステップＳ１５に処理を進める。ユーザ操作リクエストの数が上限値Ｎよりも大きい場合、通信処理部１２０は、ステップＳ１４に処理を進める。ここで、通信処理部１２０は、記憶部１１０に蓄積されたリクエストのヘッダに含まれるパス名などから、ユーザ操作リクエストや自動実行リクエストを分類することができる。
【００７１】
（Ｓ１４）通信処理部１２０は、上限値Ｎを超過した分のユーザ操作リクエストの受け付けを拒否する（蓄積されるユーザ操作リクエストの数の上限も上限値Ｎとなる）。例えば、通信処理部１２０は、上限値Ｎを超過してユーザ操作リクエストが送信されたことを、当該ユーザ操作リクエストの送信元のクライアント３００またはクライアント４００に通知し、超過した分のユーザ操作リクエストを破棄する。そして、通信処理部１２０は、ステップＳ１５に処理を進める。
【００７２】
（Ｓ１５）優先度制御部１３０は、蓄積したリクエストに対する優先度制御を行う。優先度制御の処理の詳細は後述される。
（Ｓ１６）通信処理部１２０は、記憶部１１０に記憶された優先度テーブル１１２および優先度制御部１３０により変更された優先度に応じた順序で、記憶部１１０に蓄積されたリクエストをＷｅｂサーバ２００に送信する。そして、通信処理部１２０は、処理を終了する。
【００７３】
このように、通信処理部１２０は、ユーザ操作リクエスト（第１のリクエスト）を受信すると、Ｗｅｂサーバからの応答待ちリクエスト数が上限値を超過するか否かを判定する。当該リクエスト数が上限数を超過する場合に、通信処理部１２０は、ユーザ操作リクエストを記憶部１１０に保存する。そして、通信処理部１２０は、記憶部１１０に保存されたリクエストから、ユーザ操作リクエストに関連する自動実行リクエスト（第２のリクエスト）を特定し、優先度に応じてユーザ操作リクエストおよび自動実行リクエストの送信順序を決定する。
【００７４】
なお、ステップＳ１３，Ｓ１４のように、ユーザ操作リクエスト数が同時接続数の上限値Ｎを超過しない限り、ユーザ操作リクエストの受け付けを許容することで、自動実行リクエストによりユーザ操作リクエストの送信が妨げられることを防げる。すなわち、ユーザ操作によるＡＰＩ実行リクエスト数だけに着目すると同時接続数の制限値を超過していない状況では、ユーザ操作に関係なく自動送信されるＡＰＩ実行リクエスト数が多くても、ユーザ操作によるＡＰＩ実行リクエストの送信を妨げずに済む。
【００７５】
図８は、優先度制御の例を示すフローチャートである。以下、図８に示す処理をステップ番号に沿って説明する。以下に示す手順は、図７のステップＳ１５に相当する。
（Ｓ２１）優先度制御部１３０は、記憶部１１０に記憶されたリクエスト関連テーブル１１１を参照する。
【００７６】
（Ｓ２２）優先度制御部１３０は、記憶部１１０に蓄積されたリクエストを参照して、リクエスト関連テーブル１１１に登録されているユーザ操作リクエストを受信したか否かを判定する。リクエスト関連テーブル１１１に登録されているユーザ操作リクエストを受信した場合、優先度制御部１３０は、ステップＳ２３に処理を進める。リクエスト関連テーブル１１１に登録されているユーザ操作リクエストを受信していない場合、優先度制御部１３０は、処理を終了する。
【００７７】
（Ｓ２３）優先度制御部１３０は、ユーザ操作リクエストと該当のユーザ操作リクエストに関連する自動実行リクエストとを同一クライアントから受信した否かを判定する。両方のリクエストを同一クライアントから受信した場合、優先度制御部１３０は、ステップＳ２４に処理を進める。ユーザ操作リクエストと当該ユーザ操作リクエストに関連する自動実行リクエストとを異なるクライアントから受信した場合、優先度制御部１３０は、処理を終了する。
【００７８】
（Ｓ２４）優先度制御部１３０は、該当の自動実行リクエストの優先度をユーザ操作リクエストよりも高くする。
こうして、リバースプロキシサーバ１００は、ユーザ操作リクエストに関連する自動実行リクエストの優先度を当該ユーザ操作リクエストの優先度よりも高くする。これにより、リバースプロキシサーバ１００は、自動実行リクエストを、当該自動実行リクエストに関連するユーザ操作リクエストよりも早くＷｅｂサーバ２００に送信することができる。
【００７９】
なお、ステップＳ２３のように、優先度制御部１３０は、自動実行リクエストの送信元が関連するユーザ操作リクエストの送信元と同じであるか否かを判定する。そして、優先度制御部１３０は、両送信元が同じである場合に、当該自動実行リクエストの優先度を既定の優先度よりも高い優先度に変更する。これにより、適切なリクエストに絞って、優先度の変更を行える。
【００８０】
図９は、リクエストの優先度の変更例を示す図である。リバースプロキシサーバ１００がクライアント３００，４００からリクエスト群１１３を受信し、記憶部１１０に蓄積している場合を考える。ここで、図中、“ｃｌｉｅｎｔＡ”は、クライアント３００の識別情報である。“ｃｌｉｅｎｔＢ”は、クライアント４００の識別情報である。
【００８１】
例えば、リクエスト群１１３は、クライアント３００により送信されたリクエスト“ｈｔｔｐｓ：／／ａａａ”を含む。優先度テーブル１１２に登録されているリクエスト“ｈｔｔｐｓ：／／ａａａ”の優先度は“３”である。
【００８２】
また、リクエスト群１１３は、クライアント３００により送信されたリクエスト“ｈｔｔｐｓ：／／ｘｘｘ”を含む。優先度テーブル１１２に登録されているリクエスト“ｈｔｔｐｓ：／／ｘｘｘ”の優先度は“２”である。
【００８３】
また、リクエスト群１１３は、クライアント４００により送信されたリクエスト“ｈｔｔｐｓ：／／ｂｂｂ”を含む。優先度テーブル１１２に登録されているリクエスト“ｈｔｔｐｓ：／／ｂｂｂ”の優先度は“３”である。
【００８４】
更に、リクエスト群１１３は、クライアント４００により送信されたリクエスト“ｈｔｔｐｓ：／／１１１”を含む。優先度テーブル１１２に登録されているリクエスト“ｈｔｔｐｓ：／／１１１”の優先度は“１”である。
【００８５】
優先度制御部１３０は、リクエスト関連テーブル１１１を参照して、リクエスト群１１３の中から相互に関連するリクエストの組を特定する。リクエスト関連テーブル１１１の例では、ユーザ操作リクエスト“ｈｔｔｐｓ：／／ｘｘｘ”と、自動実行リクエスト“ｈｔｔｐｓ：／／ａａａ”との組が登録されている。また、ユーザ操作リクエスト“ｈｔｔｐｓ：／／ｘｘｘ”および自動実行リクエスト“ｈｔｔｐｓ：／／ａａａ”は、同一のクライアント（クライアント３００）により送信されたリクエストである。このため、優先度制御部１３０は、リクエスト群１１３において、自動実行リクエスト“ｈｔｔｐｓ：／／ａａａ”の優先度を、ユーザ操作リクエスト“ｈｔｔｐｓ：／／ｘｘｘ”の優先度“２”よりも高くする。具体的には、優先度制御部１３０は、リクエスト群１１３における自動実行リクエスト“ｈｔｔｐｓ”：／／ａａａ”の優先度を“１”に変更する。リクエスト群１１４は、自動実行リクエスト“ｈｔｔｐｓ：／／ａａａ”の優先度を“１”に変更した結果を示している。通信処理部１２０は、変更後の優先度に応じた順序で、リクエスト群１１４に属する各リクエストをＷｅｂサーバ２００に送信する。
【００８６】
図１０は、リクエストの送信例（その１）を示す図である。クライアント３００，４００の両方による同時接続数の上限値Ｎが“２”である場合を考える。なお、図中、クライアント３００，４００からリバースプロキシサーバ１００へのリクエストと、リバースプロキシサーバ１００からＷｅｂサーバ２００へのリクエストとの対応が分かり易いように、便宜的に、両リクエストを共通の表記（“ｈｔｔｐｓ：／／ａａａ”など）としている（他の図でも同様に表記することがある）。ただし、前述のように、リバースプロキシサーバ１００は、クライアント３００，４００から受信したリクエストのＵＲＬのドメインを、バックエンドのＷｅｂサーバ２００のドメインまたはＩＰ（Internet Protocol）アドレスに変換して転送する。
【００８７】
あるタイミングで、リバースプロキシサーバ１００は、クライアント３００からリクエスト“ｈｔｔｐｓ：／／ａａａ”、“ｈｔｔｐｓ：／／ｘｘｘ”を受信し、クライアント４００からリクエスト“ｈｔｔｐｓ：／／ｂｂｂ”、“ｈｔｔｐｓ：／／１１１”を受信する（ステップＳＴ１１）。ステップＳＴ１１の段階では、クライアント３００，４００の両方による同時接続数が上限値Ｎに達しているとする。また、ステップＳＴ１１で受信したユーザ操作リクエストの数は“２”であり、同時接続数の上限値Ｎ以下である。
【００８８】
この場合、リバースプロキシサーバ１００は、リクエスト“ｈｔｔｐｓ：／／ａａａ”、“ｈｔｔｐｓ：／／ｘｘｘ”、“ｈｔｔｐｓ：／／ｂｂｂ”、“ｈｔｔｐｓ：／／１１１”を記憶部１１０に格納する。そして、図９で例示したように、リバースプロキシサーバ１００は、クライアント３００から送信されたリクエスト“ｈｔｔｐｓ：／／ａａａ”、“ｈｔｔｐｓ：／／ｘｘｘ”の関連を検出する。このため、リバースプロキシサーバ１００は、リクエスト“ｈｔｔｐｓ：／／ａａａ”の優先度をリクエスト“ｈｔｔｐｓ：／／ｘｘｘ”の優先度よりも上げる。
【００８９】
その後、リバースプロキシサーバ１００は、クライアント３００，４００による同時接続数に空きができたことを検出する。すると、リバースプロキシサーバ１００は、記憶部１１０に格納した各リクエストの送信順序を決定する。このとき、リバースプロキシサーバ１００は、リクエスト“ｈｔｔｐｓ：／／ｘｘｘ”、“ｈｔｔｐｓ：／／ｂｂｂ”、“ｈｔｔｐｓ：／／１１１”については優先度テーブル１１２の優先度を用い、“ｈｔｔｐｓ：／／ａａａ”については変更後の優先度を用いる。
【００９０】
具体的には、リクエスト“ｈｔｔｐｓ：／／ｘｘｘ”の優先度は“２”である。リクエスト“ｈｔｔｐｓ：／／ｂｂｂ”の優先度は“３”である。リクエスト“ｈｔｔｐｓ：／／１１１”の優先度は“１”である。リクエスト“ｈｔｔｐｓ：／／ａａａ”の変更後の優先度は“１”である。このため、リバースプロキシサーバ１００は、まずは、リクエスト“ｈｔｔｐｓ：／／ａａａ”、“ｈｔｔｐｓ：／／１１１”を、順番に、Ｗｅｂサーバ２００に送信する（ステップＳＴ１２）。その後、リバースプロキシサーバ１００は、リクエスト“ｈｔｔｐｓ：／／ｘｘｘ”、“ｈｔｔｐｓ：／／ｂｂｂ”を、順番に、Ｗｅｂサーバ２００に送信する（ステップＳＴ１３）。
【００９１】
こうして、リバースプロキシサーバ１００は、あるタイミングにおいて、互いに関連性のあるユーザ操作リクエストと自動実行リクエストとを受信した場合に、自動実行リクエストの優先度をユーザ操作リクエストの優先度よりも上げる。これにより、リバースプロキシサーバ１００は、ユーザ操作リクエストよりも先に、自動実行リクエストをＷｅｂサーバ２００に送信することができる。
【００９２】
図１１は、リクエストの送信例（その２）を示す図である。図１１でも、クライアント３００，４００の両方による同時接続数の上限値Ｎが“２”である場合を考える。図１１では、図１０におけるリクエストを更に具体的に示している。
【００９３】
ログ更新要求は、リクエスト“ｈｔｔｐｓ：／／ａａａ”に対応する自動実行リクエストである。ログ更新要求は、Ｗｅｂサーバ２００に対して、クライアント３００のログを提供するためのリクエストである。例えば、Ｗｅｂサーバ２００は、クライアント３００により提供されたログを保持し、ログ取得要求に応じて、保持したログをクライアントに提供する。ログ更新要求に対して予め設定された優先度は“３”である。
【００９４】
ログ取得要求は、リクエスト“ｈｔｔｐｓ：／／ｘｘｘ”に対応するユーザ操作リクエストである。ログ取得要求は、Ｗｅｂサーバ２００に対してクライアント３００に関するログの提供を要求するためのリクエストである。ログ取得要求に対して予め設定された優先度は“２”である。
【００９５】
所定処理要求は、リクエスト“ｈｔｔｐｓ：／／１１１”に対応する自動実行リクエストである。所定処理要求は、Ｗｅｂサーバ２００に対して所定の処理の実行を要求するためのリクエストである。所定処理要求に対して予め設定された優先度は“１”である。
【００９６】
あるタイミングにおいて、リバースプロキシサーバ１００は、ログ更新要求およびログ取得要求をクライアント３００から受信し、所定処理要求をクライアント４００から受信する（ステップＳＴ２１）。なお、ステップＳＴ２１の段階では、クライアント３００，４００の両方による同時接続数が上限値Ｎに達しているとする。また、ステップＳＴ２１で受信したユーザ操作リクエストの数は“２”であり、同時接続数の上限値Ｎ以下である。
【００９７】
この場合、リバースプロキシサーバ１００は、ログ更新要求、ログ取得要求および所定処理要求を記憶部１１０に格納する。そして、図９で例示したように、リクエスト関連テーブル１１１に基づいて、ログ更新要求およびログ取得要求の関連を検出し、ログ更新要求の優先度をログ取得要求の優先度よりも上げる。
【００９８】
その後、リバースプロキシサーバ１００は、クライアント３００，４００による同時接続数に空きができたことを検出する。すると、リバースプロキシサーバ１００は、ログ取得要求および所定処理要求については、優先度テーブル１１２に設定された優先度に従い、ログ更新要求については、変更後の優先度に従って、ログ更新要求、ログ取得要求および所定処理要求の送信順序を決定する。具体的には、ログ取得要求の優先度は“２”である。所定処理要求の優先度は“１”である。ログ更新要求の変更後の優先度は“１”である。このため、リバースプロキシサーバ１００は、まずは、所定処理要求およびログ更新要求を、順番に、Ｗｅｂサーバ２００に送信する（ステップＳＴ２２）。その後、リバースプロキシサーバ１００は、ログ取得要求をＷｅｂサーバ２００に送信する（ステップＳＴ２３）。
【００９９】
こうして、リバースプロキシサーバ１００は、ログ取得要求よりも前に、ログ更新要求をＷｅｂサーバ２００に送信することができる。
図１２は、リクエスト送信の比較例を示す図である。図１２では、図１１の例において、優先度テーブル１１２の優先度を変更せずに、リクエストの送信順序を決定する例を示す。ここで、図１２の説明では、リバースプロキシサーバ１００に代えて、リバースプロキシサーバ９００を用いる。また、以下に示すログ更新要求に対して予め設定された優先度は“３”である。ログ取得要求に対して予め設定された優先度は“２”である。所定処理要求に対して予め設定された優先度は“１”である。
【０１００】
あるタイミングにおいて、リバースプロキシサーバ９００は、ログ更新要求およびログ取得要求をクライアント３００から受信し、所定処理要求をクライアント４００から受信する（ステップＳＴ３１）。なお、ステップＳＴ３１の段階では、クライアント３００，４００の両方による同時接続数が上限値Ｎに達しているとする。また、ステップＳＴ３１で受信したユーザ操作リクエストの数は“２”であり、同時接続数の上限値Ｎ以下である。
【０１０１】
その後、リバースプロキシサーバ９００は、クライアント３００，４００による同時接続数に空きができたことを検出する。すると、リバースプロキシサーバ９００は、ログ更新要求、ログ取得要求および所定処理要求に対して予め定められた優先度に従って、ログ更新要求、ログ取得要求および所定処理要求の送信順序を決定する。具体的には、ログ更新要求の優先度は“３”である。ログ取得要求の優先度は“２”である。所定処理要求の優先度は“１”である。このため、リバースプロキシサーバ９００は、まずは、所定処理要求およびログ取得要求を、順番に、Ｗｅｂサーバ２００に送信する（ステップＳＴ３２）。その後、リバースプロキシサーバ９００は、ログ更新要求をＷｅｂサーバ２００に送信する（ステップＳＴ３３）。
【０１０２】
この場合、ログ更新要求は、ログ取得要求より後に、Ｗｅｂサーバ２００に送信されることになる。すると、Ｗｅｂサーバ２００によるログ取得要求に対するレスポンス（Ｗｅｂサーバ２００により保持されるクライアント３００のログを含む）には、ステップＳＴ３３のログ更新要求によるログ更新の結果が反映されないことになる。すなわち、ログ取得要求に対して、最新のログを取得することが期待されるが、クライアント３００は最新のログを取得できないことになり、期待される動作になっていない。しかも、クライアント３００は、最新のログを取得しようとすると、Ｗｅｂサーバ２００にログ取得要求を再送することになる。
【０１０３】
そこで、リバースプロキシサーバ１００は、図１１で例示したように、リクエストの優先度を変更することで、ログ取得要求よりも先に、ログ更新要求をＷｅｂサーバ２００に送信する。これにより、リバースプロキシサーバ１００は、ログ取得要求およびログ更新要求を適切な順序で送信することができる。すなわち、Ｗｅｂサーバ２００によるログ取得要求へのレスポンスに、ログ更新要求によるログ更新の結果が反映される。このため、クライアント３００は、ログ取得要求に対して、最新のログを取得可能になる。
【０１０４】
こうして、Ｗｅｂサーバ２００に対して期待される動作を実現できる可能性が高まる。すなわち、通常時は優先度の低いＡＰＩ実行リクエストでも、あるユーザ操作が行われたときは当該ＡＰＩ実行リクエストを先に実行しないと期待する結果が返ってこない場合は、当該ＡＰＩ実行リクエストの優先度を上げることで、期待しない結果が返ることを防げる。
【０１０５】
また、クライアント３００により、Ｗｅｂサーバ２００へログ取得要求を再送せずに済む。クライアント３００によるリクエストの再送を抑えることで、リバースプロキシサーバ１００、Ｗｅｂサーバ２００およびクライアント３００やネットワークの負荷を軽減できる利点もある。
【０１０６】
［第３の実施の形態］
次に、第３の実施の形態を説明する。前述の第２の実施の形態と相違する事項を主に説明し、共通する事項の説明を省略する。
【０１０７】
リバースプロキシサーバ１００は、クライアント３００，４００から受信した複数のリクエストを１つのリクエストにまとめて、Ｗｅｂサーバ２００に送信してもよい。このようにすると、Ｗｅｂサーバ２００に対する同時接続数を減らすことができる。
【０１０８】
図１３は、第３の実施の形態のマルチパートのリクエストの例を示す図である。例えば、リバースプロキシサーバ１００は、リクエストＲｅｑ１，Ｒｅｑ２を、マルチパートのリクエスト５００にまとめる。ここで、一例として、リクエストＲｅｑ１は、リクエスト“ｈｔｔｐｓ：／／ａａａ”に相当する自動実行リクエストである。また、リクエストＲｅｑ２は、リクエスト“ｈｔｔｐｓ：／／１１１”に相当する自動実行リクエストである。
【０１０９】
１つの方法として、例えば、リクエスト５００のヘッダ部５０１に、複数のリクエストをひとまとめにしたことを示す識別情報を設定し、リクエスト５００のボディ部５０２に、リクエストＲｅｑ１，Ｒｅｑ２の内容を挿入することが考えられる。識別情報としては、例えば、ヘッダ部５０１のＣｏｎｔｅｎｔ−Ｔｙｐｅヘッダにおける“ｍｕｌｔｉｐａｒｔ”が考えられる。このように、リバースプロキシサーバ１００は、複数のリクエストからマルチパートの１つのリクエストを作成して、Ｗｅｂサーバ２００に送信する。マルチパートのリクエストの作成方法には、特開２００５−３２２２２２号公報も参考にすることができる。
【０１１０】
Ｗｅｂサーバ２００は、マルチパートのリクエスト５００を検出すると、ボディ部５０２におけるリクエストＲｅｑ１，Ｒｅｑ２を分離して処理する。そして、Ｗｅｂサーバ２００は、リクエストＲｅｑ１，Ｒｅｑ２に対する処理結果をひとまとめにしたマルチパートのレスポンスを生成し、リバースプロキシサーバ１００に送信する。
【０１１１】
リバースプロキシサーバ１００は、Ｗｅｂサーバ２００から受信したマルチパートのレスポンスからリクエストＲｅｑ１，Ｒｅｑ２に対応する２つのレスポンスを抽出し、クライアント３００，４００に送信する。リバースプロキシサーバ１００は、抽出したレスポンスを、リクエスト送信元のクライアントに適切に送信可能にするため、リクエスト送信元管理テーブルを保持する。
【０１１２】
図１４は、リクエスト送信元管理テーブルの例を示す図である。リクエスト送信元管理テーブル１１５は、記憶部１１０に格納される。リクエスト送信元管理テーブル１１５は、まとめられたリクエストの組毎に、通信処理部１２０により作成される。リクエスト送信元管理テーブル１１５は、リクエストおよび送信元の項目を含む。
【０１１３】
リクエストの項目には、リクエストの種別を示すＵＲＬが登録される。送信元の項目には、クライアントの識別情報が登録される。クライアントの識別情報は、ＩＰアドレスなどのアドレス情報でもよい。
【０１１４】
例えば、リクエスト送信元管理テーブル１１５には、リクエストが“ｈｔｔｐｓ：／／ａａａ”、送信元が“ｃｌｉｅｎｔＡ”というレコードが登録される。このレコードは、マルチパートのリクエスト要素のうち、ＵＲＬ“ｈｔｔｐｓ：／／ａａａ”のリクエストの送信元が“ｃｌｉｅｎｔＡ”で示されるクライアント３００であることを示す。
【０１１５】
次に、第３の実施の形態におけるリバースプロキシサーバ１００の処理手順を説明する。
図１５は、リバースプロキシサーバの処理例を示すフローチャートである。以下、図１５に示す処理をステップ番号に沿って説明する。
【０１１６】
（Ｓ３１）通信処理部１２０は、クライアント３００，４００から受信したリクエストを記憶部１１０に蓄積し、蓄積したリクエストの数が、同時接続数の上限値Ｎよりも大きいか否かを判定する。蓄積したリクエストの数が上限値Ｎよりも大きい場合、通信処理部１２０は、ステップＳ３３に処理を進める。蓄積したリクエストの数が上限値Ｎ以下の場合、通信処理部１２０は、ステップＳ３２に処理を進める。
【０１１７】
（Ｓ３２）通信処理部１２０は、全てのリクエストをＷｅｂサーバ２００に送信する。そして、通信処理部１２０は、処理を終了する。
（Ｓ３３）通信処理部１２０は、記憶部１１０に蓄積されたリクエストのうち、ユーザ操作リクエストの数が同時接続数の上限値Ｎ以下であるか否かを判定する。ユーザ操作リクエストの数が上限値Ｎ以下である場合、通信処理部１２０は、ステップＳ３５に処理を進める。ユーザ操作リクエストの数が上限値Ｎよりも大きい場合、通信処理部１２０は、ステップＳ３４に処理を進める。
【０１１８】
（Ｓ３４）通信処理部１２０は、上限値Ｎを超過した分のユーザ操作リクエストの受け付けを拒否する（蓄積されるユーザ操作リクエストの数の上限も上限値Ｎとなる）。例えば、通信処理部１２０は、上限値Ｎを超過してユーザ操作リクエストが送信されたことを、当該ユーザ操作リクエストの送信元のクライアント３００またはクライアント４００に通知し、超過した分のユーザ操作リクエストを破棄する。そして、通信処理部１２０は、ステップＳ３５に処理を進める。
【０１１９】
（Ｓ３５）優先度制御部１３０は、蓄積したリクエストに対する優先度制御を行う。優先度制御の処理手順は、図８で例示した手順と同様である。
（Ｓ３６）通信処理部１２０は、ユーザ操作リクエストよりも高優先度の自動実行リクエストが複数あるか否かを判定する。ユーザ操作リクエストよりも高優先度の自動実行リクエストが複数ある場合、通信処理部１２０は、ステップＳ３７に処理を進める。ユーザ操作リクエストよりも高優先度の自動実行リクエストが複数ない（すなわち、１つの）場合、通信処理部１２０は、ステップＳ３９に処理を進める。
【０１２０】
（Ｓ３７）通信処理部１２０は、ユーザ操作リクエストよりも高優先度の複数の自動実行リクエストを含む１つのリクエスト（マルチパートのリクエスト）を生成する。このとき、通信処理部１２０は、まとめたリクエストの組に対して、リクエスト送信元管理テーブル１１５を生成し、記憶部１１０に格納する。
【０１２１】
（Ｓ３８）通信処理部１２０は、生成したリクエストをＷｅｂサーバ２００に送信する。そして、通信処理部１２０は、ステップＳ４０に処理を進める。
（Ｓ３９）通信処理部１２０は、ユーザ操作リクエストよりも高優先度の自動実行リクエストをＷｅｂサーバ２００に送信する。そして、通信処理部１２０は、ステップＳ４０に処理を進める。
【０１２２】
（Ｓ４０）通信処理部１２０は、ユーザ操作リクエストをＷｅｂサーバ２００に送信する。
（Ｓ４１）通信処理部１２０は、ユーザ操作リクエストよりも低優先度の自動実行リクエストをＷｅｂサーバ２００に送信する。
【０１２３】
このように、通信処理部１２０は、ユーザ操作リクエストの優先度（第３の優先度）よりも高い優先度である自動実行リクエスト（第３のリクエスト）と当該ユーザ操作リクエストに関連する自動実行リクエスト（第２のリクエスト）とを含むマルチパートのリクエスト（第４のリクエスト）を生成する。そして、通信処理部１２０は、ユーザ操作リクエストの優先度（第３の優先度）よりも高い優先度で、生成したマルチパートのリクエストをＷｅｂサーバ２００に送信する。
【０１２４】
図１６は、通信例（その１）を示す図である。図１６（Ａ）は、リバースプロキシサーバ１００によるＷｅｂサーバ２００へのリクエストの送信例を示す。クライアント３００，４００の両方による同時接続数の上限値Ｎが“２”である場合を考える。
【０１２５】
あるタイミングでリバースプロキシサーバ１００は、クライアント３００からリクエスト“ｈｔｔｐｓ：／／ａａａ”、“ｈｔｔｐｓ：／／ｘｘｘ”を受信し、クライアント４００からリクエスト“ｈｔｔｐｓ：／／ｂｂｂ”、“ｈｔｔｐｓ：／／１１１”を受信する（ステップＳＴ４１）。ステップＳＴ４１の段階では、クライアント３００，４００の両方による同時接続数が上限値Ｎに達しているとする。また、ステップＳＴ４１で受信したユーザ操作リクエストの数は“２”であり、同時接続数の上限値Ｎ以下である。
【０１２６】
この場合、リバースプロキシサーバ１００は、受信した４つのリクエストを記憶部１１０に格納する。そして、図９で例示したように、リクエスト“ｈｔｔｐｓ：／／ａａａ”、“ｈｔｔｐｓ：／／ｘｘｘ”の関連を検出し、リクエスト“ｈｔｔｐｓ：／／ａａａ”の優先度をリクエスト“ｈｔｔｐｓ：／／ｘｘｘ”の優先度よりも上げる。
【０１２７】
すると、ユーザ操作リクエスト“ｈｔｔｐｓ：／／ｘｘｘ”よりも優先度の高い２つの自動実行リクエスト“ｈｔｔｐｓ：／／ａａａ”、“ｈｔｔｐｓ：／／１１１”が存在することになる。このため、リバースプロキシサーバ１００は、これら２つの自動実行リクエスト“ｈｔｔｐｓ：／／ａａａ”、“ｈｔｔｐｓ：／／１１１”を１つにまとめたマルチパートのリクエストを生成する。そして、クライアント３００，４００による同時接続数に空きができると、生成したマルチパートのリクエスト、および、ユーザ操作リクエスト“ｈｔｔｐｓ：／／ｘｘｘ”を、順番に、Ｗｅｂサーバ２００に送信する（ステップＳＴ４２）。このとき、リバースプロキシサーバ１００は、ひとまとめにしたリクエスト“ｈｔｔｐｓ：／／ａａａ”、“ｈｔｔｐｓ：／／１１１”の組に対して、リクエスト送信元管理テーブル１１５を生成し、記憶部１１０に格納する。その後、リバースプロキシサーバ１００は、自動実行リクエスト“ｈｔｔｐｓ：／／ｂｂｂ”を、Ｗｅｂサーバ２００に送信する（ステップＳＴ４３）。
【０１２８】
図１６（Ｂ）は、リバースプロキシサーバ１００によるレスポンスの送信例（特に、マルチパートのリクエストに対するレスポンスの送信例）を示す。リバースプロキシサーバ１００は、マルチパートのリクエストに対するマルチパートのレスポンスをＷｅｂサーバ２００から受信する（ステップＳＴ４４）。すると、リバースプロキシサーバ１００は、当該レスポンスからリクエスト“ｈｔｔｐｓ：／／ａａａ”および“ｈｔｔｐｓ：／／１１１”それぞれに対応する２つのレスポンスを抽出する。そして、リバースプロキシサーバ１００は、記憶部１１０に記憶されたリクエスト送信元管理テーブル１１５を参照して、抽出したレスポンスに対するリクエスト送信元を特定する。リバースプロキシサーバ１００は、特定したリクエスト送信元のクライアントに当該レスポンスを、送信する（ステップＳＴ４５）。具体的には、リバースプロキシサーバ１００は、“ｈｔｔｐｓ：／／ａａａ”に対応するレスポンスをクライアント３００に送信する。また、リバースプロキシサーバ１００は、“ｈｔｔｐｓ：／／１１１”に対応するレスポンスをクライアント４００に送信する。
【０１２９】
このように、リバースプロキシサーバ１００は、ユーザ操作リクエストよりも優先度の高い２つの自動実行リクエストをまとめることで、ユーザ操作リクエストの送信タイミングを早めることもできる。
【０１３０】
図１７は、通信例（その２）を示す図である。第３の実施の形態では、リクエスト送信元管理テーブル１１５によりひとまとめにしたリクエストの送信元を管理する例を示したが、リバースプロキシサーバ１００は、他の方法によりリクエストの送信元を管理してもよい。例えば、リバースプロキシサーバ１００は、ひとまとめにしたリクエストに対して、クライアント３００，４００それぞれの識別情報を付加してもよい。この場合、Ｗｅｂサーバ２００は、レスポンス内に、同識別情報を付加し、クライアント３００向けのレスポンス部分であるか、クライアント４００向けのレスポンス部分であるかを識別可能にする。
【０１３１】
すなわち、あるタイミングでリバースプロキシサーバ１００は、クライアント３００からリクエスト“ｈｔｔｐｓ：／／ａａａ”、“ｈｔｔｐｓ：／／ｘｘｘ”を受信し、クライアント４００からリクエスト“ｈｔｔｐｓ：／／ｂｂｂ”、“ｈｔｔｐｓ：／／１１１”を受信する（ステップＳＴ５１）。ステップＳＴ５１の段階では、クライアント３００，４００の両方による同時接続数が上限値Ｎに達しているとする。また、ステップＳＴ５１で受信したユーザ操作リクエストの数は“２”であり、同時接続数の上限値Ｎ以下である。
【０１３２】
この場合、リバースプロキシサーバ１００は、受信した４つのリクエストを記憶部１１０に格納する。そして、図９で例示したように、リクエスト“ｈｔｔｐｓ：／／ａａａ”、“ｈｔｔｐｓ：／／ｘｘｘ”の関連を検出し、リクエスト“ｈｔｔｐｓ：／／ａａａ”の優先度をリクエスト“ｈｔｔｐｓ：／／ｘｘｘ”の優先度よりも上げる。
【０１３３】
すると、ユーザ操作リクエスト“ｈｔｔｐｓ：／／ｘｘｘ”よりも優先度の高い２つの自動実行リクエスト“ｈｔｔｐｓ：／／ａａａ”、“ｈｔｔｐｓ：／／１１１”が存在することになる。このため、リバースプロキシサーバ１００は、これら２つの自動実行リクエスト“ｈｔｔｐｓ：／／ａａａ”、“ｈｔｔｐｓ：／／１１１”を１つにまとめたマルチパートのリクエストを生成する。このとき、リバースプロキシサーバ１００は、マルチパートのリクエストのうち、リクエスト“ｈｔｔｐｓ：／／ａａａ”の部分にクライアント３００の識別情報“ｃｌｉｅｎｔＡ”を付加する。また、リバースプロキシサーバ１００は、マルチパートのリクエストのうち、リクエスト“ｈｔｔｐｓ：／／１１１”の部分にクライアント４００の識別情報“ｃｌｉｅｎｔＢ”を付加する。そして、クライアント３００，４００による同時接続数に空きができると、生成したリクエスト、および、ユーザ操作リクエスト“ｈｔｔｐｓ：／／ｘｘｘ”を、順番に、Ｗｅｂサーバ２００に送信する（ステップＳＴ５２）。その後、リバースプロキシサーバ１００は、自動実行リクエスト“ｈｔｔｐｓ：／／ｂｂｂ”を、Ｗｅｂサーバ２００に送信する（ステップＳＴ５３）。
【０１３４】
図１７（Ｂ）は、リバースプロキシサーバ１００によるレスポンスの送信例（特に、マルチパートのリクエストに対するレスポンスの送信例）を示す。リバースプロキシサーバ１００は、マルチパートのリクエストに対するマルチパートのレスポンスをＷｅｂサーバ２００から受信する（ステップＳＴ５４）。すると、リバースプロキシサーバ１００は、当該レスポンスからリクエスト“ｈｔｔｐｓ：／／ａａａ”および“ｈｔｔｐｓ：／／１１１”それぞれに対応する２つのレスポンスを抽出する。このとき、リバースプロキシサーバ１００は、各レスポンス部分に付加されたクライアントの識別情報を参照して、各レスポンスの送信先を特定し、特定した送信先にレスポンスを送信する（ステップＳＴ５５）。具体的には、リバースプロキシサーバ１００は、“ｈｔｔｐｓ：／／ａａａ”に対応するレスポンスをクライアント３００に送信する。また、リバースプロキシサーバ１００は、“ｈｔｔｐｓ：／／１１１”に対応するレスポンスをクライアント４００に送信する。
【０１３５】
このように、リバースプロキシサーバ１００は、図１７で例示した方法によって、ユーザ操作リクエストよりも優先度の高い２つの自動実行リクエストをまとめてもよい。この場合も、図１６と同様に、ユーザ操作リクエストの送信タイミングを早めることができる。ここで、第３の実施の形態の例では、２つの自動実行リクエストを１つのリクエストにまとめる例を示したが、リバースプロキシサーバ１００は、３以上の自動実行リクエストを１つのリクエストにまとめてもよい。
【０１３６】
なお、第１の実施の形態の情報処理は、処理部１ｂにプログラムを実行させることで実現できる。また、第２の実施の形態の情報処理は、プロセッサ１０１にプログラムを実行させることで実現できる。プログラムは、コンピュータ読み取り可能な記録媒体１３に記録できる。
【０１３７】
例えば、プログラムを記録した記録媒体１３を配布することで、プログラムを流通させることができる。また、プログラムを他のコンピュータに格納しておき、ネットワーク経由でプログラムを配布してもよい。コンピュータは、例えば、記録媒体１３に記録されたプログラムまたは他のコンピュータから受信したプログラムを、ＲＡＭ１０２やＨＤＤ１０３などの記憶装置に格納し（インストールし）、当該記憶装置からプログラムを読み込んで実行してもよい。
【符号の説明】
【０１３８】
１  送信制御装置
１ａ  記憶部
１ｂ  処理部
２  情報処理装置
３，４  端末装置
５  リクエスト関連情報
６  優先度情報
【図１】
2019040344.tif 000003
【図２】
2019040344.tif 000004
【図３】
2019040344.tif 000005
【図４】
2019040344.tif 000006
【図５】
2019040344.tif 000007
【図６】
2019040344.tif 000008
【図７】
2019040344.tif 000009
【図８】
2019040344.tif 000010
【図９】
2019040344.tif 000011
【図１０】
2019040344.tif 000012
【図１１】
2019040344.tif 000013
【図１２】
2019040344.tif 000014
【図１３】
2019040344.tif 000015
【図１４】
2019040344.tif 000016
【図１５】
2019040344.tif 000017
【図１６】
2019040344.tif 000018
【図１７】
2019040344.tif 000019