JP6311666B2 - 通信システム、管理サーバおよびプログラム - Google Patents

Description

本発明は、ファイアウォールの外側のクラウドサーバとファイアウォールの内側のデバイスとの間の通信を行う通信システム、およびそれに関連する技術に関する。

ＬＡＮ外部のサーバ（クラウドサーバ等）とＬＡＮ内部のデバイス（画像形成装置等）との連携を図る技術が存在する。

たとえば、クラウド上のサーバ（クラウドサーバ）に格納された電子文書をローカル側（ＬＡＮ内部）の画像形成装置を用いて印刷出力する技術が存在する（特許文献１参照）。

特許文献１には、画像形成装置（デバイス）とゲートウエイとクラウドサーバとを備える文書出力システム（通信システム）が示されている。このシステムにおいては、クラウドサーバに格納された電子文書がゲートウエイ等を介して画像形成装置に送信され、画像形成装置１０において当該電子文書の印刷出力が行われる。なお、ゲートウエイおよび画像形成装置（デバイス）はＬＡＮの内部に設けられており、クラウドサーバはＬＡＮの外部に設けられている。

ところで、上述のようなシステムにおいては、通常、ＬＡＮの内部の画像形成装置（デバイス）とＬＡＮの外部のクラウドサーバとの間にはファイアウォールが設けられる。

ＬＡＮ内部の画像形成装置からＬＡＮ外部のクラウドサーバへのアクセスは、ファイアウォールを通過し、当該アクセスは許可される。

しかしながら、逆向きのアクセス、すなわち、ＬＡＮ外部のクラウドサーバからＬＡＮ内部の画像形成装置への直接的なアクセスは、ファイアウォールによってブロックされる。すなわち、クラウドサーバから直接、画像形成装置に対するアクセスを行うことはできない。

これに対して、ＬＡＮ外部の管理サーバとＬＡＮ内部のゲートウエイ（通信中継装置）との間に（ファイアフォールの例外として）メッセージセッション（通信セッション）を確立しておき、ＬＡＮ外部のクラウドサーバから、当該管理サーバおよび当該ゲートウエイを経由して、ＬＡＮ内部の画像形成装置にアクセスする技術が考えられる。

図２６および図２７は、そのような技術を示す図である。ゲートウエイ３０（３０ａ）は、その起動時等において、予め指定された管理サーバ５０との間にメッセージセッション５１１を確立しておく（図２６の太線参照）。その後、クラウドサーバ７０から（管理サーバ５０を介した）特定のデバイス１０ａへのアクセス要求発生時においては、管理サーバ５０と或るゲートウエイ３０（３０ａ）との間の当該メッセージセッション５１１を利用することにより管理サーバ５０から当該ゲートウエイ３０ａにトンネル接続要求が送信される。当該トンネル接続要求は、トンネル接続（ゲートウエイ３０とクラウドサーバ７０との間でのトンネル接続）を確立すべき旨を当該ゲートウエイ３０に要求する指令である。換言すれば、当該トンネル接続要求は、トンネル接続を用いた通信をゲートウエイ３０に行わせる指令である。当該トンネル接続要求に基づき、ゲートウエイ３０ａはクラウドサーバ７０との間にトンネル通信を確立する（図２７参照）。そして、当該トンネル通信を用いてクラウドサーバ７０から（ゲートウエイ３０経由で）デバイス（画像形成装置）１０ａへのアクセスが行われる。このような技術については、後に詳述する。

なお、特許文献２には、同様の技術が示されている。

このような技術においては、管理サーバ５０によってゲートウエイの管理が行われる。

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

上記特許文献２の技術とは逆向きのアクセス、すなわち、ＬＡＮ外部のクラウドサーバからＬＡＮ内部の画像形成装置へのアクセスは、ファイアウォールを通過することを必ずしも要しない。ただし、セキュリティ上の問題（後述）等によって、ＬＡＮ外部のクラウドサーバからＬＡＮ内部の画像形成装置へのアクセスにおいても、管理サーバ５０を介した通信が行われることが好ましい。

さらに、仮に、管理サーバ５０を介さずにファイアウォールの内部のデバイスからファイアウォールの外部のサーバへの通信が行われる場合には、複数の通信が無秩序に行われるなど、システム統制上の問題も存在する。

このような問題を解消するためには、ファイアウォールの外側のクラウドサーバとファイアウォールの内側のデバイスとの間の通信は、管理サーバ５０を介して行われることが好ましい。

たとえば、管理サーバ５０は、各クラウドサーバからの通信依頼および各デバイスからの通信依頼を受け付け、その受付順序に従って、各通信依頼に基づく処理（ゲートウエイに対するトンネル接続要求等）を行うことが考えられる。

しかしながら、各通信依頼に基づく処理が当該各通信依頼の受付順序のみに従って行われる場合には、各通信依頼に基づく処理が非効率的な実行順序で実行されることも多い。

そこで、この発明は、複数の通信依頼に基づく処理を効率的に実行することが可能な通信システムおよびそれに関連する技術を提供することを課題とする。

上記課題を解決すべく、請求項１の発明は、通信システムであって、ファイアウォールの内側に設けられる少なくとも１つのデバイスと、前記ファイアウォールの外側に設けられる少なくとも１つのクラウドサーバと、前記少なくとも１つのデバイスと前記少なくとも１つのクラウドサーバで実行される少なくとも１つのアプリケーションとの間の通信を中継する少なくとも１つのゲートウエイと、前記少なくとも１つのデバイスと前記少なくとも１つのアプリケーションとの間の通信であって前記少なくとも１つのゲートウエイを介した通信を管理する管理サーバと、を備え、前記管理サーバは、前記少なくとも１つのデバイスのいずれかからの通信依頼であって前記少なくとも１つのデバイス側から前記少なくとも１つのアプリケーション側へ向かう向きのデータ転送を伴う通信の依頼である第１の通信依頼と、前記少なくとも１つのアプリケーションのいずれかからの通信依頼であって前記少なくとも１つのアプリケーション側から前記少なくとも１つのデバイス側へ向かう向きのデータ転送を伴う通信の依頼である第２の通信依頼とを含む複数の通信依頼を受信する受信手段と、前記複数の通信依頼に基づく複数のトンネル接続要求の実行順序を制御するトンネル接続要求制御手段と、を有し、各トンネル接続要求は、前記少なくとも１つのゲートウエイのいずれかと前記少なくとも１つのアプリケーションのいずれかとの間でのトンネル接続を用いた通信を行うべき旨を前記少なくとも１つのゲートウエイのいずれかに対して要求する指令であり、前記トンネル接続要求制御手段は、前記第１の通信依頼に基づくトンネル接続要求である第１のトンネル接続要求を、前記第２の通信依頼に基づくトンネル接続要求である第２のトンネル接続要求よりも優先して実行することを特徴とする。

請求項２の発明は、請求項１の発明に係る通信システムにおいて、前記トンネル接続要求制御手段は、利用ユーザによる指示に応じたユーザ指示処理の実行のための第３の通信依頼に基づくトンネル接続要求である第３のトンネル接続要求と、前記利用ユーザによる指示を前提としない管理処理の実行のための第４の通信依頼に基づくトンネル接続要求である第４のトンネル接続要求とのうち、前記第３のトンネル接続要求を前記第４のトンネル接続要求よりも優先して実行することを特徴とする。

請求項３の発明は、請求項２の発明に係る通信システムにおいて、前記トンネル接続要求制御手段は、（１）前記第１のトンネル接続要求であって前記第３のトンネル接続要求でもあるトンネル接続要求と、（２）前記第１のトンネル接続要求であって前記第４のトンネル接続要求でもあるトンネル接続要求と、（３）前記第２のトンネル接続要求であって前記第３のトンネル接続要求でもあるトンネル接続要求と、（４）前記第２のトンネル接続要求であって前記第４のトンネル接続要求でもあるトンネル接続要求と、を前記１）〜４）の順序で優先順位付けして実行することを特徴とする。

請求項４の発明は、請求項１ないし請求項３のいずれかの発明に係る通信システムにおいて、前記通信システムには複数のデバイスが設けられ、前記トンネル接続要求制御手段は、前記複数のデバイスのうち第１の閾値よりも大きな数のトンネル接続を未だ確立していない第１のデバイスに関するトンネル接続要求を、前記複数のデバイスのうち前記第１の閾値よりも大きな数のトンネル接続を既に確立している第２のデバイスに関するトンネル接続要求よりも、優先して実行することを特徴とする。

請求項５の発明は、請求項１ないし請求項４のいずれかの発明に係る通信システムにおいて、前記通信システムには複数のゲートウエイが設けられ、前記トンネル接続要求制御手段は、前記複数のゲートウエイのうち第２の閾値よりも大きな数のトンネル接続を未だ確立していない第１のゲートウエイに関するトンネル接続要求を、前記複数のゲートウエイのうち前記第２の閾値よりも大きな数のトンネル接続を既に確立している第２のゲートウエイに関するトンネル接続要求よりも、優先して実行することを特徴とする。

請求項６の発明は、請求項１ないし請求項５のいずれかの発明に係る通信システムにおいて、前記通信システムには複数のアプリケーションが設けられ、前記トンネル接続要求制御手段は、前記複数のアプリケーションのうち第３の閾値よりも大きな数のトンネル接続を未だ確立していない第１のアプリケーションに関するトンネル接続要求を、前記複数のアプリケーションのうち前記第３の閾値よりも大きな数のトンネル接続を既に確立している第２のアプリケーションに関するトンネル接続要求よりも、優先して実行することを特徴とする。

請求項７の発明は、請求項１ないし請求項６のいずれかの発明に係る通信システムにおいて、前記トンネル接続要求制御手段は、前記受信手段によって受信された前記複数の通信依頼に対応する複数のトンネル接続要求に対して各評価値をそれぞれ算出し、前記各評価値に基づいて前記複数のトンネル接続要求の優先順位を決定することを特徴とする。

請求項８の発明は、請求項２または請求項３の発明に係る通信システムにおいて、前記第３の通信依頼および前記第４の通信依頼は、それぞれ、前記少なくとも１つのデバイスのいずれかと前記少なくとも１つのアプリケーションのいずれかとの間でのデータ通信を伴う通信の依頼であり、前記トンネル接続要求制御手段は、前記受信手段によって受信された通信依頼に基づくトンネル接続要求が前記第３のトンネル接続要求であるか前記第４のトンネル接続要求であるかを、各通信依頼に応じて実際のデータ通信にて用いられる通信プロトコルに基づいて判定することを特徴とする。

請求項９の発明は、請求項８の発明に係る通信システムにおいて、前記トンネル接続要求制御手段は、前記各通信依頼と当該各通信依頼に応じた前記データ通信にて利用される通信プロトコルとの対応関係を示すデータテーブルに基づいて、前記各通信依頼に応じて実際のデータ通信にて用いられる通信プロトコルを判定することを特徴とする。

請求項１０の発明は、請求項２または請求項３の発明に係る通信システムにおいて、前記トンネル接続要求制御手段は、前記受信手段によって受信された通信依頼に基づくトンネル接続要求が前記第３のトンネル接続要求であるか前記第４のトンネル接続要求であるかを、前記通信依頼の依頼元ユーザが利用ユーザであるか管理ユーザであるかに応じて判定することを特徴とする。

請求項１１の発明は、ファイアウォールの内側に設けられる少なくとも１つのデバイスと前記ファイアウォールの外側に設けられる少なくとも１つのクラウドサーバで実行される少なくとも１つのアプリケーションとの間の通信であって少なくとも１つのゲートウエイによって中継される通信を管理する管理サーバであって、前記少なくとも１つのデバイスのいずれかからの通信依頼であって前記少なくとも１つのデバイス側から前記少なくとも１つのアプリケーション側へ向かう向きのデータ転送を伴う通信の依頼である第１の通信依頼と、前記少なくとも１つのアプリケーションのいずれかからの通信依頼であって前記少なくとも１つのアプリケーション側から前記少なくとも１つのデバイス側へ向かう向きのデータ転送を伴う通信の依頼である第２の通信依頼とを含む複数の通信依頼を受信する受信手段と、前記複数の通信依頼に基づく複数のトンネル接続要求の実行順序を制御するトンネル接続要求制御手段と、を備え、各トンネル接続要求は、前記少なくとも１つのゲートウエイのいずれかと前記少なくとも１つのアプリケーションのいずれかとの間でのトンネル接続を用いた通信を行うべき旨を前記少なくとも１つのゲートウエイのいずれかに対して要求する指令であり、前記トンネル接続要求制御手段は、前記第１の通信依頼に基づくトンネル接続要求である第１のトンネル接続要求を、前記第２の通信依頼に基づくトンネル接続要求である第２のトンネル接続要求よりも優先して実行することを特徴とする。

請求項１２の発明は、請求項１１の発明に係る管理サーバにおいて、前記トンネル接続要求制御手段は、利用ユーザによる指示に応じたユーザ指示処理の実行のための第３の通信依頼に基づくトンネル接続要求である第３のトンネル接続要求と、前記利用ユーザによる指示を前提としない管理処理の実行のための第４の通信依頼に基づくトンネル接続要求である第４のトンネル接続要求とのうち、前記第３のトンネル接続要求を前記第４のトンネル接続要求よりも優先して実行することを特徴とする。

請求項１３の発明は、請求項１２の発明に係る管理サーバにおいて、前記トンネル接続要求制御手段は、（１）前記第１のトンネル接続要求であって前記第３のトンネル接続要求でもあるトンネル接続要求と、（２）前記第１のトンネル接続要求であって前記第４のトンネル接続要求でもあるトンネル接続要求と、（３）前記第２のトンネル接続要求であって前記第３のトンネル接続要求でもあるトンネル接続要求と、（４）前記第２のトンネル接続要求であって前記第４のトンネル接続要求でもあるトンネル接続要求と、を前記（１）〜（４）の順序で優先順位付けして実行することを特徴とする。

請求項１４の発明は、請求項１１ないし請求項１３のいずれかの発明に係る管理サーバにおいて、前記トンネル接続要求制御手段は、前記ファイアウォールの内側に設けられる複数のデバイスのうち第１の閾値よりも大きな数のトンネル接続を未だ確立していない第１のデバイスに関するトンネル接続要求を、前記複数のデバイスのうち前記第１の閾値よりも大きな数のトンネル接続を既に確立している第２のデバイスに関するトンネル接続要求よりも、優先して実行することを特徴とする。

請求項１５の発明は、請求項１１ないし請求項１４のいずれかの発明に係る管理サーバにおいて、前記トンネル接続要求制御手段は、前記少なくとも１つのデバイスと前記少なくとも１つのアプリケーションとの間の通信を中継する複数のゲートウエイのうち第２の閾値よりも大きな数のトンネル接続を未だ確立していない第１のゲートウエイに関するトンネル接続要求を、前記複数のゲートウエイのうち前記第２の閾値よりも大きな数のトンネル接続を既に確立している第２のゲートウエイに関するトンネル接続要求よりも、優先して実行することを特徴とする。

請求項１６の発明は、請求項１１ないし請求項１５のいずれかの発明に係る管理サーバにおいて、前記トンネル接続要求制御手段は、前記ファイアウォールの外側に設けられる複数のアプリケーションのうち第３の閾値よりも大きな数のトンネル接続を未だ確立していない第１のアプリケーションに関するトンネル接続要求を、前記複数のアプリケーションのうち前記第３の閾値よりも大きな数のトンネル接続を既に確立している第２のアプリケーションに関するトンネル接続要求よりも、優先して実行することを特徴とする。

請求項１７の発明は、請求項１１ないし請求項１６のいずれかの発明に係る管理サーバにおいて、前記トンネル接続要求制御手段は、前記受信手段によって受信された前記複数の通信依頼に対応する前記複数のトンネル接続要求に対して各評価値をそれぞれ算出し、前記各評価値に基づいて前記複数のトンネル接続要求の優先順位を決定することを特徴とする。

請求項１８の発明は、請求項１２または請求項１３の発明に係る管理サーバにおいて、前記第３の通信依頼および前記第４の通信依頼は、それぞれ、前記少なくとも１つのデバイスのいずれかと前記少なくとも１つのアプリケーションのいずれかとの間でのデータ通信を伴う通信の依頼であり、前記トンネル接続要求制御手段は、前記受信手段によって受信された通信依頼に基づくトンネル接続要求が前記第３のトンネル接続要求であるか前記第４のトンネル接続要求であるかを、各通信依頼に応じて実際のデータ通信にて用いられる通信プロトコルに基づいて判定することを特徴とする。

請求項１９の発明は、請求項１８の発明に係る管理サーバにおいて、前記トンネル接続要求制御手段は、前記各通信依頼と前記各通信依頼に応じた前記データ通信にて利用される通信プロトコルとの対応関係を示すデータテーブルに基づいて、前記各通信依頼に応じて実際のデータ通信にて用いられる通信プロトコルを判定することを特徴とする。

請求項２０の発明は、請求項１２または請求項１３の発明に係る管理サーバにおいて、前記トンネル接続要求制御手段は、前記受信手段によって受信された通信依頼に基づくトンネル接続要求が前記第３のトンネル接続要求であるか前記第４のトンネル接続要求であるかを、前記通信依頼の依頼元ユーザが利用ユーザであるか管理ユーザであるかに応じて判定することを特徴とする。

請求項２１の発明は、ファイアウォールの内側に設けられる少なくとも１つのデバイスと前記ファイアウォールの外側に設けられる少なくとも１つのクラウドサーバで実行される少なくとも１つのアプリケーションとの間の通信であって少なくとも１つのゲートウエイによって中継される通信を管理する管理サーバに内蔵されたコンピュータに、ａ）前記少なくとも１つのデバイスのいずれかからの通信依頼であって前記少なくとも１つのデバイス側から前記少なくとも１つのアプリケーション側へ向かう向きのデータ転送を伴う通信の依頼である第１の通信依頼と、前記少なくとも１つのアプリケーションのいずれかからの通信依頼であって前記少なくとも１つのアプリケーション側から前記少なくとも１つのデバイス側へ向かう向きのデータ転送を伴う通信の依頼である第２の通信依頼とを含む複数の通信依頼を受信するステップと、ｂ）前記複数の通信依頼に基づく複数のトンネル接続要求の実行順序を制御するステップと、を実行させるためのプログラムであって、各トンネル接続要求は、前記少なくとも１つのゲートウエイのいずれかと前記少なくとも１つのアプリケーションのいずれかとの間でのトンネル接続を用いた通信を行うべき旨を前記少なくとも１つのゲートウエイのいずれかに対して要求する指令であり、前記ステップｂ）においては、前記第１の通信依頼に基づくトンネル接続要求である第１のトンネル接続要求が、前記第２の通信依頼に基づくトンネル接続要求である第２のトンネル接続要求よりも優先して実行されることを特徴とする。

請求項１ないし請求項２１に記載の発明によれば、複数の通信依頼に基づくトンネル接続要求を効率的に実行することが可能である。

第１実施形態に係る通信システムの概略構成を示す図である。 図１の一部を示す図である。 ＭＦＰの構成を示す概略図である。 各装置の概略構成を示す図である。 アプリトリガ通信依頼に関する動作を示す図である。 デバイストリガ通信依頼に関する動作を示す図である。 トンネル接続要求の分類を示す図である。 分類に応じた付与ポイントを示す図である。 各トンネル接続要求に対する評価値（優先値）の付与例を示す図である。 管理サーバの動作を示すフローチャートである。 図１０の一部動作の詳細を示すフローチャートである。 管理サーバの待ち行列内の様子を示す概念図である。 管理サーバの待ち行列内の様子を示す概念図である。 管理サーバの待ち行列内の様子を示す概念図である。 管理サーバの待ち行列内の様子を示す概念図である。 第２実施形態におけるトンネル接続要求の分類を示す図である。 分類に応じた付与ポイントを示す図である。 各トンネル接続要求に対する評価値（優先値）の付与例を示す図である。 各トンネル接続要求に対する評価値（優先値）の付与例を示す図である。 管理サーバの一部の動作を示すフローチャートである。 管理サーバの待ち行列内の様子を示す概念図である。 管理サーバの待ち行列内の様子を示す概念図である。 管理サーバの待ち行列内の様子を示す概念図である。 管理サーバの待ち行列内の様子を示す概念図である。 管理サーバの待ち行列内の様子を示す概念図である。 通信システムにおける動作を示す概念図である。 通信システムにおける動作を示す概念図である。

以下、本発明の実施形態を図面に基づいて説明する。

＜１．第１実施形態＞
＜１−１．システム構成概要＞
図１および図２は、本発明の実施形態に係る通信システム１の概略構成を示す図である。なお、図２は、図１の一部を示す図である。

図１等に示すように、通信システム１は、複数のデバイス１０（１０ａ，１０ｂ，１０ｃ，...）と、複数のゲートウエイ３０（３０ａ，３０ｂ）と、管理サーバコンピュータ（以下、単に管理サーバとも称する）５０とを備える。通信システム１は、複数のクラウドサーバコンピュータ（以下、単にクラウドサーバとも称する）７０と、複数のクライアントコンピュータ（以下、単にクライアントとも称する）９０とをさらに備える。

各要素１０，３０，５０，７０，９０は、ネットワーク１０８（図２参照）を介して互いに接続されており、ネットワーク通信を実行することが可能である。なお、ネットワーク１０８は、ＬＡＮ（ローカルエリアネットワーク）１０７およびインターネットなどによって構成される。ネットワーク１０８への接続形態は、有線接続であってもよく或いは無線接続であってもよい。

各ゲートウエイ３０および当該各ゲートウエイ３０に対応する１または２以上のデバイス１０が、企業内等に構築された各ＬＡＮ１０７の内部（換言すれば、ファイアウォールの内側）に設けられている。各ゲートウエイ３０には、同じＬＡＮ１０７内に設けられたデバイス１０が接続されている。より詳細には、たとえば、図１に示すように、或る企業のＬＡＮ１０７ａ内に１台のゲートウエイ３０ａと３台のデバイス１０（１０ａ，１０ｂ，１０ｃ）が設けられ、別の企業のＬＡＮ１０７ｂ内に１台のゲートウエイ３０ｂと２台のデバイス１０（１０ｄ，１０ｅ）が設けられる。なお、各ＬＡＮ１０７内には、単一のゲートウエイ３０が設けられてもよく、２以上のゲートウエイ３０が設けられてもよい。

一方、管理サーバ５０、クラウドサーバ７０およびクライアント９０は、ＬＡＮ１０７の外部（換言すれば、ファイアウォールの外側）に設けられている。なお、クライアント９０は、ＬＡＮ１０７の内部に設けられていてもよい。

また、ここでは、デバイス１０として、マルチ・ファンクション・ペリフェラル（Multi-Functional Peripheral）（ＭＦＰとも略称する）を例示する。ＭＦＰは、画像形成装置あるいは通信装置などとも称される。

一方、ゲートウエイ３０、管理サーバ５０、クラウドサーバ７０およびクライアント９０は、サーバ用コンピュータあるいはパーソナルコンピュータ等を用いて構築される。

この通信システム１においては、クラウドサーバ７０（詳細には、クラウドサーバ７０に実装されるアプリケーションソフトウエアプログラム（以下、単にアプリケーションとも称する）８０）からの通信依頼に基づく処理が実行される。アプリケーション８０からの当該通信依頼は、アプリケーション８０から発せられるもの（アプリケーション側がトリガになるもの）であり、「アプリトリガ通信依頼」とも称される。「アプリトリガ通信依頼」においては、図１の上側（クラウドサーバ７０側）から下側（デバイス１０側）に向かう向き（「下向き」とも表現される）のデータ転送を伴う処理が行われる。たとえば、クライアント９０からクラウドサーバ７０へと送出された印刷指令が、管理サーバ５０およびゲートウエイ３０を経由してデバイス１０へと送信され、デバイス（ＭＦＰ）１０において印刷出力が行われる。このような印刷出力は、クラウドサーバを経由した処理であることから、「クラウドプリント」などとも称される。「クラウドプリント」における通信依頼は、「アプリトリガ通信依頼」の一例である。

また、この通信システム１においては、逆に、デバイス１０からの通信依頼（ゲートウエイ経由）に基づく処理も実行される。デバイス１０からの当該通信依頼は、デバイス１０から発せられるもの（デバイス側がトリガになるもの）であり、「デバイストリガ通信依頼」とも称される。「デバイストリガ通信依頼」においては、上述の「下向き」の処理とは逆向きの処理、すなわち図１の下側（デバイス１０側）から上側（クラウドサーバ７０側）に向かう向き（「上向き」とも表現される）のデータ転送を伴う処理が行われる。たとえば、デバイス１０で生成されたスキャン画像が、管理サーバ５０の管理下において、デバイス１０からゲートウエイ３０を経由してクラウドサーバ７０へと送信され、クラウドサーバ７０において格納される。このようなスキャン処理は、クラウドサーバへの格納処理を伴うことから、「クラウドスキャン」などとも称される。「クラウドスキャン」における通信依頼は、「デバイストリガ通信依頼」の一例である。

各クラウドサーバ７０には、それぞれ、１または複数のアプリケーション８０がインストールされている。各アプリケーション８０は、サース（SaaS：Software as a Service）形式で提供される。換言すれば、各アプリケーション８０の機能は、サービスとして提供される。たとえば、クラウドプリント用のアプリケーション８０ａがクラウドサーバ７０ａにインストールされ、クラウドプリントサービスがアプリケーション８０ａおよびデバイス１０等を用いて提供される。また、クラウドスキャン用のアプリケーション８０ｂがクラウドサーバ７０ｂにインストールされ、クラウドスキャンサービスがアプリケーション８０ｂおよびデバイス１０等を用いて提供される。

また、各ゲートウエイ３０は、当該各ゲートウエイ３０に対応するデバイス１０と複数のクラウドサーバ７０（詳細には、アプリケーション８０）との通信を中継する機能を有している。各ゲートウエイ３０は、通信中継装置とも称される。

管理サーバ５０は、複数のデバイス１０と複数のクラウドサーバ７０（詳細には、アプリケーション８０）との間の通信、特に各ゲートウエイ３０を介した通信（トンネル接続通信）等を管理する装置である。

管理サーバ５０は、複数のデバイス１０のうちの特定のデバイス１０に対するアクセス要求（通信依頼）をクラウドサーバ７０から受け付けるとともに、当該アクセス要求に応じて、複数のゲートウエイ３０のうち特定のデバイス１０に対応するゲートウエイ３０に対して、クラウドサーバ７０とのトンネル接続要求を送信する。また、管理サーバ５０は、複数のクラウドサーバ７０のうちの特定のクラウドサーバ７０（アプリケーション８０）に対するアクセス要求（通信依頼）をデバイス１０から受け付けるとともに、当該アクセス要求に応じて、複数のゲートウエイ３０のうちの或るゲートウエイ３０に対して、クラウドサーバ７０とのトンネル接続要求を送信する。

ここで、各トンネル接続要求は、複数のゲートウエイ３０のいずれかと複数のクラウドサーバ７０（複数のアプリケーション８０）のいずれかとの間でのトンネル接続を用いた通信を行うべき旨を、複数の１つのゲートウエイ３０のいずれかに対して要求する指令である。

また、後に詳述するように、管理サーバ５０は、デバイス１０あるいはクラウドサーバ７０（アプリケーション８０）からの複数の通信依頼を受け付け（受信し）、当該複数の通信依頼に基づく複数のトンネル接続要求の処理順序を制御する。

管理サーバ５０は、各通信依頼を受け付けると、当該各通信依頼に対応する各トンネル接続要求を待ち行列に投入する。ただし、各トンネル接続要求が待ち行列に投入される際には、各トンネル接続要求の優先度合いを示す指標値（優先値）Ｖが各トンネル接続要求に割り当てられる。そして、各トンネル接続要求は、当該待ち行列内において、当該各トンネル接続要求の指標値Ｖに従った位置（順序（ひいては待ち時間の大小）が互いに相違する位置）に配置される。待ち行列内にて指標値Ｖに応じた位置に配置され格納された各トンネル接続要求は、自らの実行順序の到来を待機する。そして、自らの実行順序が到来したトンネル接続要求が実行される。このように、管理サーバ５０は、複数のトンネル接続要求を、その優先度合いに応じた順序で実行する。なお、優先処理の詳細等については後述する。

＜１−２．ＭＦＰの構成概要＞
上述のように、この実施形態では、デバイス１０として、マルチ・ファンクション・ペリフェラル（Multi-Functional Peripheral）（ＭＦＰとも略称する）を例示する。

図３は、ＭＦＰの構成を示す概略図である。ＭＦＰは、スキャナ機能、プリンタ機能、コピー機能およびデータ通信機能などを備える装置（複合機とも称する）である。

ＭＦＰは、印刷出力処理（プリント処理）および画像読取処理（スキャン処理）等を行うことが可能な画像形成装置である。

図３に示すように、ＭＦＰは、画像読取部２、印刷出力部３、通信部４、格納部５、入出力部６およびコントローラ９等を備えており、これらの各部を複合的に動作させることによって、各種の機能を実現する。

画像読取部２は、ＭＦＰの所定の位置に載置された原稿を光学的に読み取って、当該原稿の画像データ（原稿画像とも称する）を生成する処理部である。

印刷出力部３は、対象画像に関する画像データに基づいて紙などの各種の媒体に画像を印刷出力する出力部である。

通信部４は、公衆回線等を介したファクシミリ通信を行うことが可能な処理部である。さらに、通信部４は、ネットワーク１０８を介したネットワーク通信が可能である。このネットワーク通信では、ＵＤＰ（User Datagram Protocol）、ＴＣＰ（Transmission Control Protocol）、ＩＰ（Internet Protocol）、ＳＮＭＰ（Simple Network Management Protocol）およびＦＴＰ（File Transfer Protocol）等の各種の通信プロトコルが利用され、当該ネットワーク通信を利用することによって、ＭＦＰは、所望の相手先（ゲートウエイ３０、管理サーバ５０およびクラウドサーバ７０等）との間で各種のデータを授受することが可能である。

たとえば、ＭＦＰの通信部４は、ゲートウエイ３０とクラウドサーバ７０との間に確立されたトンネル接続（後述）を利用して、当該ゲートウエイ３０を経由してクラウドサーバ７０と通信すること（クラウドサーバ７０へデータを送信すること、および／またはクラウドサーバ７０からのデータを受信すること）が可能である。なお、通信部４は、他の装置に対してデータ等を送信する送信部と、他の装置からデータ等を受信する受信部とを有する。

格納部５は、ハードディスクドライブ（ＨＤＤ）および不揮発性メモリ等の格納装置で構成される。

入出力部６は、ＭＦＰに対する入力を受け付ける操作入力部６ａと、各種情報の表示出力を行う表示部６ｂとを備えている。なお、入出力部６は、操作部とも称される。

コントローラ９は、ＭＦＰを統括的に制御する制御部であり、ＣＰＵと、各種の半導体メモリ（ＲＡＭおよびＲＯＭ等）とを備えて構成される。

コントローラ９は、ＣＰＵにおいて、ＲＯＭ（例えば、ＥＥＰＲＯＭ等）内に格納されている所定のソフトウエアプログラム（単にプログラムとも称する）を実行することによって、各種の処理部（画像形成動作等を制御する動作制御部１６等）を実現する。なお、当該プログラムは、たとえば各種の可搬性の記録媒体（ＵＳＢメモリ等）に記録され、当該記録媒体を介してＭＦＰにインストールされればよい。あるいは当該プログラムは、ネットワーク等を介してダウンロードされてＭＦＰにインストールされるようにしてもよい。

＜１−３．各要素の構成概要＞
図４は、各要素３０，５０，７０等の概略構成を示す図である。図４を参照して、これらの各要素について説明する。なお、この実施形態では、ゲートウエイ３０、管理サーバ５０、クラウドサーバ７０およびクライアント９０は、サーバ用コンピュータあるいはパーソナルコンピュータ等を用いて構築される。

＜クラウドサーバ７０＞
クラウドサーバ７０は、通信制御部８１を備える。通信制御部８１は、管理サーバ５０との通信を実行する。また、通信制御部８１は、各ゲートウエイ３０との通信をトンネル通信（後述）を用いて実行する。

また、上述のように、各クラウドサーバ７０には、それぞれ、１または複数のアプリケーション８０がインストールされている。各アプリケーション８０は、通信制御部８１等を介して、他の装置５０，３０，１０（詳細にはそれぞれのアプリケーション）等と通信する。

＜ゲートウエイ３０＞
ゲートウエイ３０は、その配下に存在するデバイス１０と複数のクラウドサーバ７０（アプリケーション８０）との通信を中継する。

各ゲートウエイ３０は、それぞれ、通信制御部４１などの各種の処理部を備える。当該各種の処理部は、ゲートウエイ３０（ＭＦＰ）のコントローラ９において、所定のプログラムを実行することによって実現される。

通信制御部４１は、他の装置との通信を制御する処理部である。通信制御部４１は、メッセージセッション通信制御部４２とトンネル通信制御部４３とＬＡＮ内通信制御部４４とを有する。

ＬＡＮ内通信制御部４４は、ＬＡＮ内の各種装置との通信を実行する処理部である。

一方、メッセージセッション通信制御部４２とトンネル通信制御部４３とは、それぞれ、ＬＡＮ外の各種装置との通信を実行する処理部である。

メッセージセッション通信制御部４２は、管理サーバ５０との通信をメッセージセッションを用いて実行する処理部である。メッセージセッション通信制御部４２は、管理サーバ５０との間にメッセージセッション（たとえば、ＸＭＰＰ（eXtensible Messaging and Presence Protocol）等を利用するメッセージセッション）を確立して、管理サーバ５０との通信を実行する。メッセージセッション通信制御部４２は、対管理サーバ通信部（あるいは管理サーバ通信部）とも称される。

トンネル通信制御部４３は、クラウドサーバ７０との通信をトンネル通信を用いて実行する処理部である。トンネル通信制御部４３は、クラウドサーバ７０との間にトンネル接続（たとえば、ＨＴＴＰＳ（Hypertext Transfer Protocol Secure）等を利用する通信セッション）を確立して、クラウドサーバ７０と特定のデバイス１０との通信を中継する。トンネル通信制御部４３は、対クラウドサーバ通信部（あるいはクラウドサーバ通信部）とも称される。

後述するように、トンネル接続等を利用することによって、ＬＡＮ１０７の外部の装置（クラウドサーバ７０）からＬＡＮ１０７の内部の装置（ゲートウエイ３０およびデバイス１０）に対してデータを送信すること（およびその逆向きのデータ送信）が可能である。

＜管理サーバ５０＞
管理サーバ５０は、デバイス１０、ゲートウエイ３０およびクラウドサーバ７０（アプリケーション８０を含む）を管理するサーバである。

管理サーバ５０は、通信制御部６１、情報管理部６５およびアクセス制御部６７などの各種の処理部を備える。

これら各種の処理部は、管理サーバ５０のＣＰＵにおいて、格納部（ＨＤＤ等）に格納されている所定のソフトウエアプログラム（単にプログラムとも称する）を実行することによって実現される。なお、当該プログラムは、たとえば各種の可搬性の記録媒体（ＤＶＤ−ＲＯＭ等）に記録され、当該記録媒体を介して管理サーバ５０にインストールされればよい。あるいは当該プログラムは、ネットワーク１０８等を介してダウンロードされて管理サーバ５０にインストールされるようにしてもよい。

通信制御部６１は、通信部５４（通信用ハードウエア）と協働して、各種の通信動作を制御する。たとえば、通信制御部６１は、クラウドサーバ７０との通信を実行し、クラウドサーバ７０からのアクセス要求を受信する。また、通信制御部６１は、各ゲートウエイ３０との通信をメッセージセッション等を用いて実行する。なお、通信部５４は、他の装置に対してデータ等を送信する送信部と、他の装置からデータ等を受信する受信部とを有する。当該受信部は、複数の通信依頼（後述）を受信し、当該送信部は、当該複数の通信依頼に基づくトンネル接続要求をゲートウエイ３０に送信する。

情報管理部６５は、管理サーバ５０による管理対象の複数のゲートウエイ３０の情報（管理ゲートウエイ情報）、および当該複数のゲートウエイ３０からそれぞれ受信した管理デバイス情報（各ゲートウエイ３０による管理対象のデバイス１０の情報）等を管理する処理部である。これらの情報（管理ゲートウエイ情報および管理デバイス情報）は、管理サーバ５０の格納部（ＨＤＤ（ハードディスクドライブ）等）５５内に格納された管理テーブル６９に記述されている。管理テーブル６９においては、管理ゲートウエイ情報（各ゲートウエイ３０の識別情報（たとえばＩＰアドレス）等）、および各ゲートウエイ３０と各ゲートウエイ３０の配下のデバイス（管理対象デバイス）との関係を示す管理デバイス情報等が記述されている。

また、情報管理部６５は、複数のクラウドサーバ７０の情報、および複数のクラウドサーバ７０内の各アプリケーション８０の情報等をも管理する。これらの情報も、管理テーブル６９に格納される。また、情報管理部６５は、各ゲートウエイ３０と各クラウドサーバ７０との間に確立されているトンネル接続の接続数等をも管理テーブル６９等にて管理する。

アクセス制御部６７は、クラウドサーバ７０から受信したアクセス要求（通信依頼）の内容、およびデバイス１０からゲートウエイ３０を経由して受信したアクセス要求（通信依頼）の内容を解析する。具体的には、当該通信依頼の依頼元（デバイス１０／アプリケーション８０（クラウドサーバ７０））、および依頼処理種類（ユーザ指示処理／管理処理）（後述）等が解析結果として得られる。また、各アクセス制御部６７は、これらの解析結果に基づいて、複数の通信依頼の各優先度合いに基づき、当該複数の通信依頼および当該複数の通信依頼に関する複数のトンネル接続要求の実行順序を制御する。なお、アクセス制御部６７は、トンネル接続要求を制御する処理部であることから、トンネル接続要求制御部などとも表現される。

通信制御部６１および通信部５４等は、ゲートウエイ３０（通信中継装置）に対して、「トンネル接続要求」（当該ゲートウエイ３０と指定したクラウドサーバ７０との間でトンネル接続を確立すべき旨の要求）を送信する。

なお、管理サーバ５０のアクセス制御部６７から当該トンネル接続要求を受信したゲートウエイ３０（通信中継装置）は、当該トンネル接続要求に応じてトンネル接続をクラウドサーバ７０との間に確立する。そして、当該ゲートウエイ３０は、当該トンネル接続を利用して、クラウドサーバ７０と接続先デバイス１０との間の通信を中継する。

＜１−４．通信依頼に基づく動作＞
この通信システム１においては、デバイス１０とクラウドサーバ７０（アプリケーション８０）との間でのファイアウォールを越える通信が、ゲートウエイ３０と管理サーバ５０とを利用して行われる。具体的には、次の２種類の動作、すなわち「アプリトリガ通信依頼」に関する動作および「デバイストリガ通信依頼」に関する動作（後述）が実行される。

以下では、まず「アプリトリガ通信依頼」に関する動作について説明する。

＜アプリトリガ通信依頼に関する動作（「下向き」の動作）＞
この実施形態においても、図２６および図２７に示すような上述の動作（「アプリトリガ通信依頼」に関する動作）が行われる。具体的には、ＬＡＮ外部の管理サーバ５０とＬＡＮ内部のゲートウエイ３０（３０ａ）との間に（ファイアフォールの例外としての）メッセージセッション５１１（図２６参照）を確立しておき、さらに当該メッセージセッション５１１を利用して管理サーバ５０からゲートウエイ３０へトンネル接続要求（デバイス１０ａ向けのアクセス要求）が送信される。また、当該トンネル接続要求に応じて、ゲートウエイ３０とクラウドサーバ７０との間にトンネル接続が形成される（図２７参照）。そして、当該トンネル接続を利用して、ＬＡＮ外部のクラウドサーバ７０から、ゲートウエイ３０を経由して、ＬＡＮ内部のデバイス１０にアクセスすることが行われ得る。たとえば、クラウドサーバ７０ａを利用した「クラウドプリント」がデバイス１０ａ（画像形成装置）にて行われ得る。

以下では、まず、このような動作について主に図５を参照しながら説明する。なお、図５は、「アプリトリガ通信依頼」に関する動作を示す図である。

上述（図２６参照）のように、まず、ゲートウエイ３０ａは、その起動時等において、予め指定された管理サーバ５０との間に通信セッション（詳細には、メッセージセッション）５１１を予め確立しておく。具体的には、ゲートウエイ３０ａは、予め指定された管理サーバ５０に対してメッセージセッションの確立要求を送信する。これに応じて、管理サーバ５０が当該確立要求を承認することによって、ゲートウエイ３０ａと管理サーバ５０との間にメッセージセッション５１１が確立される（図２６参照）。換言すれば、ＬＡＮ１０７の内部のゲートウエイ３０からＬＡＮ１０７の外部の管理サーバ５０へのアクセスに応じて、メッセージセッションが確立される。なお、このようなメッセージセッション（通信セッション）としては、たとえば、「XMPP:eXtensible Messaging and Presence Protocol」）などの通信プロトコルを用いたものが例示される。

また、ゲートウエイ３０ａは、ゲートウエイ３０ａの管理下のデバイス（管理対象デバイス）の情報等を管理サーバ５０へ送信しておく。また、管理サーバ５０は、各ゲートウエイ３０による管理対象デバイス１０の情報（各デバイスリストに記述された情報）を含む登録情報を、管理サーバ５０の格納部５５内の管理テーブル６９（図４）に格納する。

その後、「クラウドプリント」に関するユーザ操作がクライアント９０にて行われ、クラウドサーバ７０ａ（アプリケーション８０ａ）がユーザ操作に基づく指示をクライアント９０から受け付ける（Ｓ１１（図５））。当該指示に応答して、クラウドサーバ７０ａ（アプリケーション８０ａ）は、特定のデバイス１０ａ向けの通信依頼（アクセス要求）を管理サーバ５０に送信する（Ｓ１２）。

管理サーバ５０は、クラウドサーバ７０（アプリケーション８０）からの通信依頼（「アプリトリガ通信依頼」）を受信すると、デバイス１０に対するアクセス権限を依頼元のクラウドサーバ７０（アプリケーション８０）が有している旨を確認する。たとえば、管理サーバ５０は、予め生成され格納部５５に格納されたアクセス権限情報（デバイス１０ａに対するアクセス権限を有するアプリケーション８０がリストアップされた情報）等に基づいて、当該アクセス権限の有無を判定する。

依頼元アプリケーション８０が当該アクセス権限を有している旨が判定されると、その後、管理サーバ５０は、当該アプリトリガ通信依頼に基づくトンネル接続要求を、トンネル接続要求に関する待ち行列に投入する。

その後、待ち行列内で待機していたトンネル接続要求の実行順序が到来すると、管理サーバ５０は、当該トンネル接続要求をゲートウエイ３０に向けて送信する（Ｓ１３（図５））。詳細には、管理サーバ５０は、管理サーバ５０とゲートウエイ３０（３０ａ）との間の当該メッセージセッション（常時接続通信セッション）５１１を利用することにより、アクセス要求に基づくトンネル接続要求を当該ゲートウエイ３０ａに送信する。「トンネル接続要求」は、クラウドサーバ７０（アプリケーション８０）との間にトンネル接続を確立すべき旨をゲートウエイ３０に要求する指令である。換言すれば、当該トンネル接続要求は、トンネル接続を用いた通信をゲートウエイ３０に行わせる指令である。

当該トンネル接続要求を受信したゲートウエイ３０ａは、当該トンネル接続要求に応答して、トンネル接続（トンネル通信）をクラウドサーバ７０ａ（アプリケーション８０ａ）との間に形成する（Ｓ１４（図５））（図２７も参照）。なお、図２７においては、砂地ハッチング付きの細長い矩形によって「トンネル通信」が模式的に示されている。

詳細には、ゲートウエイ３０ａは、当該トンネル接続要求に応答して、ＨＴＴＰ（Hypertext Transfer Protocol）セッション（より詳細には、ＨＴＴＰＳ（Hypertext Transfer Protocol Secure）セッション）の確立要求をクラウドサーバ７０ａに対して送信する。このようなＨＴＴＰ（ＨＴＴＰＳ）セッションの確立要求は、（ゲートウエイ３０による）トンネル接続の確立要求とも称される。なお、ゲートウエイ３０による「トンネル接続の確立要求」と管理サーバ５０による「トンネル接続要求」とは互いに異なるものである。ゲートウエイ３０による「トンネル接続の確立要求」は、管理サーバ５０による「トンネル接続要求」に応答して、ゲートウエイ３０からクラウドサーバ７０に向けて実際のトンネル接続確立のために発せられる要求（指令）である。

そして、ゲートウエイ３０による「トンネル接続の確立要求」をクラウドサーバ７０ａが承認することによって、当該ゲートウエイ３０ａとクラウドサーバ７０ａとの間に当該ＨＴＴＰセッションによるトンネル接続（トンネル通信）が確立される。換言すれば、ＬＡＮ１０７の内部のゲートウエイ３０からＬＡＮ１０７の外部のクラウドサーバ７０へのアクセスに応じて、トンネル接続が確立される。

トンネル接続が確立されると、ゲートウエイ３０ａは、当該トンネル接続を用いてクラウドサーバ７０ａとデバイス１０ａとの間の通信（主に「下向き」のデータ通信）を中継する（Ｓ１５，Ｓ１６）。より詳細には、ＨＴＴＰ（ＨＴＴＰＳ）セッションによるトンネル通信を用いることによって、クラウドサーバ７０は、ゲートウエイ３０を経由してデバイス１０（たとえば１０ｄ）へと各種のデータを送信することが可能である。

このようにして、クラウドサーバ７０から（ゲートウエイ３０経由での）デバイス（画像形成装置）１０へのアクセスがトンネル通信を用いて行われる。

以上のように、管理サーバ５０は、アプリケーション８０（８０ａ）からの通信依頼であってアプリケーション８０（８０ａ）から（ゲートウエイ３０を介して）デバイス１０（１０ａ）へ向かう向き（「下向き」）のデータ転送を伴う通信の依頼（「アプリトリガ通信依頼」とも称する）を受信する。そして、管理サーバ５０は、当該アプリトリガ通信依頼に基づくトンネル接続要求をその待ち行列に投入し、待ち行列内で待機していたトンネル接続要求の実行順序が到来すると、当該トンネル接続要求をゲートウエイ３０に向けて送信する。その後、ゲートウエイ３０は、当該トンネル接続要求に応じて、トンネル接続をクラウドサーバ７０ａ（アプリケーション８０ａ）との間に形成し、当該トンネル接続を用いてクラウドサーバ７０ａとデバイス１０ａとの間の通信（主に「下向き」のデータ通信）を中継する。

＜デバイストリガ通信依頼に関する動作（「上向き」の動作）＞
この通信システム１においては、上述の「アプリトリガ通信依頼」に基づく動作（「下向き」の動作）とは謂わば「逆向き」の動作（「デバイストリガ通信依頼」（後述）に関する動作）も行われる。以下、図６を参照しながら当該動作について説明する。なお、デバイストリガ通信依頼を伴う処理として、ここでは「クラウドスキャン」を例示する。

具体的には、まず、上記と同様に、ゲートウエイ３０ａは、その起動時等において、予め指定された管理サーバ５０との間に通信セッション（メッセージセッション）５１１を予め確立しておく。

その後、たとえば「クラウドスキャン」に関するユーザ操作がデバイス１０（たとえば１０ａ）にて行われ、デバイス１０は、クラウドサーバ７０（たとえば７０ｂ）で動作中のアプリケーション８０（たとえば８０ｂ）に対する通信依頼を、ゲートウエイ３０を介して、管理サーバ５０に送信する（Ｓ２１，Ｓ２２）。当該通信依頼は、デバイス１０からの通信依頼（ゲートウエイ経由）であってデバイス１０から（ゲートウエイ３０を介して）アプリケーション８０へ向かう向き（「上向き」）のデータ転送を伴う通信の依頼である。当該通信依頼は、デバイス１０から発せられるもの（デバイス側がトリガになるもの）であり、「デバイストリガ通信依頼」とも称される。

管理サーバ５０は、ゲートウエイ３０を経由した通信依頼（「デバイストリガ通信依頼」）を受信すると、クラウドサーバ７０（アプリケーション８０）に対するアクセス権限を依頼元のデバイス１０（１０ａ）が有している旨を確認する。たとえば、管理サーバ５０は、依頼元デバイス１０のアクセス権限の有無を通信先のアプリケーション８０ｂに問い合わせ（Ｓ２３）、その問い合わせ結果に基づいて当該アクセス権限の有無を判定するようにすればよい。あるいは、管理サーバ５０は、アプリケーション８０ｂから予め受信しておいたアクセス権限情報（アプリケーション８０ｂに対するアクセス権限を有するデバイス１０がリストアップされた情報）に基づいて、（この時点ではアプリケーション８０ｂと通信せずに）、当該アクセス権限の有無を判定するようにしてもよい。

依頼元デバイス１０が当該アクセス権限を有している旨が判定（確認）されると、その後、上記と同様の動作が行われる。

具体的には、管理サーバ５０は、当該デバイストリガ通信依頼に基づくトンネル接続要求を、当該トンネル接続要求に関する待ち行列に投入する。なお、デバイストリガ通信依頼に基づくトンネル接続要求とアプリトリガ通信依頼に基づくトンネル接続要求とは、同じ待ち行列に投入される。

その後、待ち行列内で待機していたトンネル接続要求の実行順序が到来すると、管理サーバ５０は、当該トンネル接続要求をゲートウエイ３０に向けて送信する（Ｓ２４）。ゲートウエイ３０は、当該トンネル接続要求に応じて、トンネル接続をクラウドサーバ７０ｂ（アプリケーション８０ｂ）との間に形成（確立）する（Ｓ２５）。そして、ゲートウエイ３０は、当該トンネル接続を用いてデバイス１０ａとクラウドサーバ７０ｂとの間の通信（主に「上向き」のデータ通信（スキャン画像のアップロード処理等））を中継する（Ｓ２６）。

このようにして、デバイストリガ通信依頼を伴う処理が実行される。

なお、このようなデバイストリガ通信依頼においては、セキュリティ向上のため、次のような処理が行われることが好ましい。具体的には、管理サーバ５０は、デバイストリガ通信依頼の依頼元デバイス１０がアクセス権限を有している旨を確認した後、管理サーバ５０は、クラウドサーバ７０からワンタイムパスワードを受領する（Ｓ２３）。そして、管理サーバ５０は、当該ワンタイムパスワードを利用してクラウドサーバ７０にアクセスしてトンネル接続を形成する（Ｓ２５）。このような処理によれば、クラウドサーバ７０等のセキュリティを向上させることが可能である。

＜１−５．複数のトンネル接続要求に関する制御動作の概要＞
上述のように、各種の通信依頼が、アプリケーション８０から管理サーバ５０へ（ステップＳ１２参照）、あるいは、デバイス１０から（ゲートウエイ３０を経由して）管理サーバ５０へと（ステップＳ２１，Ｓ２２参照）随時送信される。詳細には、「アプリトリガ通信依頼」がアプリケーション８０から管理サーバ５０へと随時送信され、「デバイストリガ通信依頼」がデバイス１０から（ゲートウエイ３０を経由して）管理サーバ５０へと随時送信される。

ところで、これらの複数の通信依頼を処理する手法としては、管理サーバ５０において当該複数の通信依頼（および当該複数の通信依頼に基づく複数のトンネル接続要求）をその受付順（受信順）に従って順次に処理していくことが考えられる。より詳細には、管理サーバ５０は、当該複数の通信依頼（および当該複数のトンネル接続要求等）を受付順に従って順次に待ち行列に投入し、待ち行列内で待機している当該複数の通信依頼（および当該複数のトンネル接続要求等）を当該受付順に従って処理すればよい。

しかしながら、各通信依頼および当該各通信依頼に基づくトンネル接続要求が当該各通信依頼の受付順序のみに従って行われることは、必ずしも効率的ではない。

たとえば、管理サーバ５０が複数の「クラウドプリント」を受け付け且つその後に「クラウドスキャン」を受け付けた場合を想定する。「クラウドスキャン」は、ＬＡＮ内のデバイス（ＭＦＰ）１０を利用した処理であり、クラウドスキャンの利用ユーザは、当該デバイス１０の近くに存在し、素早いレスポンスを期待している。一方、「クラウドプリント」は、主にＬＡＮの外（外出先等）に居る利用ユーザから依頼され且つＬＡＮ内のデバイス１０で印刷出力される処理である。クラウドプリントの利用ユーザは、当該デバイス１０に近くに居らず、素早いレスポンスを求めていない（外出から戻ったときに印刷出力されていれば十分である等）ことが多い。

このような状況において、複数のクラウドプリントに関するトンネル接続要求等が優先されると、当該クラウドスキャンに関するトンネル接続要求は、当該複数のクラウドプリントに関するトンネル接続要求が行われるまで実行されない。その結果、クラウドスキャンの利用ユーザは、素早いレスポンスを求めているにもかかわらず、比較的長い期間に亘って待機することを余儀なくされる。

各通信依頼に基づくトンネル接続要求が当該各通信依頼の受付順序のみに従って行われる場合には、このような問題等が生じる。

そこで、この実施形態においては、管理サーバ５０は、図７〜図１１等に示すように、種々の要素を考慮して実行順序を決定する動作等を実行する。この結果、たとえば、「クラウドスキャン」に関するトンネル接続要求が、「クラウドプリント」に関するトンネル接続要求よりも優先して実行される（図９等参照）。なお、図７は、トンネル接続要求の分類（後述）を示す図であり、図８は当該分類に応じた付与ポイントを示す図であり、図９は、各トンネル接続要求に対する評価値の付与例を示す図である。また、図１０および図１１は、本実施形態に係る管理サーバ５０の動作を示すフローチャートである。

まず、図１０を参照して、管理サーバ５０の動作の概要について説明する。

図１０に示すように、ステップＳ５１にて管理サーバ５０が当該各通信依頼を受信すると、管理サーバ５０は、ステップＳ５２にて、各通信依頼（および当該各通信依頼に基づく各トンネル接続要求）に対してそれぞれ優先度合いを決定する。詳細には、管理サーバ５０は、複数の通信依頼（および複数のトンネル接続要求）に対する各評価値（優先度合いに関する評価値（指標値Ｖ））をそれぞれ算出し、当該各評価値に基づいて当該複数のトンネル接続要求の優先順位を決定する。

このような優先度合いが決定された上で、各通信依頼（および当該各トンネル接続要求）が待ち行列に投入される（ステップＳ５３）。

その後、管理サーバ５０は、その実行順序が到来したトンネル接続要求を順次に実行する。換言すれば、管理サーバ５０は、複数のトンネル接続要求を、その優先度合いに応じた順序で実行する。これによれば、各通信依頼および当該各通信依頼に基づくトンネル接続要求を効率的に実行することが可能である。

＜１−６．トンネル接続要求の優先順位決定動作＞
次に、優先順位決定処理（ステップＳ５２）の詳細について説明する。ただし、図１１（ステップＳ５２の詳細フローチャート）を参照する前に、優先順位決定処理の概略について図７〜図９を参照しながら説明する。

＜依頼処理の分類１：デバイストリガ／アプリトリガ＞
この実施形態においては、複数の通信依頼（アクセス要求）が、その依頼元（「デバイス」／「アプリケーション」）に応じて分類される（デバイストリガ通信依頼／アプリトリガ通信依頼）。換言すれば、複数の通信依頼に基づく複数のトンネル接続要求が、「デバイストリガ通信依頼」に基づくトンネル接続要求と「アプリトリガ通信依頼」に基づくトンネル接続要求とに分類される。

＜依頼処理の分類２：ユーザ指示処理（非理処理）／管理処理＞
また、複数の通信依頼（アクセス要求）は、その処理種類（「ユーザ指示処理」／「管理処理」）に応じても分類される。換言すれば、複数の通信依頼に基づく複数のトンネル接続要求は、「ユーザ指示処理」のための通信依頼に基づくトンネル接続要求と「管理処理」のための通信依頼に基づくトンネル接続要求とにも分類される。

ここにおいて、「ユーザ指示処理の実行のための通信依頼」は、明示のユーザ指示（利用ユーザ（一般ユーザないし非管理ユーザとも称される）からの手動指示）に基づく処理（ユーザ指示処理）を実行するための通信依頼である。

一方、「管理処理の実行のための通信依頼」は、管理処理（利用ユーザによる明示の指示（手動指示）に基づくのではなく装置により自動的に開始される管理用の処理）を実行するための通信依頼である。なお、「ユーザ指示処理」は、利用ユーザによる指示を前提とする処理であるのに対して、「管理処理」は、利用ユーザによる指示を前提としない処理である、とも表現される。このように、「ユーザ指示処理」と「管理処理」とは概念的に対峙するものであり、「ユーザ指示処理」は、「非管理処理」であるとも表現される。また、「管理処理」は、ユーザ指示処理とは異なり、利用ユーザからは見えない状態で（バックグラウンドで）実行される処理であることから、「バックグラウンド処理」とも称される。

たとえば、上述の「クラウドスキャン」は、デバイス１０のユーザによる明示のスキャン指示に基づくスキャン処理（スキャンジョブ）である。当該クラウドスキャンを実行するための通信依頼は、「ユーザ指示処理の実行のための通信依頼」であるとも表現される。同様に、上述の「クラウドプリント」は、アプリケーション８０のユーザによる明示のプリント指示に基づくプリント処理（プリントジョブ）である。クラウドプリントを実行するための通信依頼も、「ユーザ指示処理の実行のための通信依頼」であるとも表現される。

一方、「結果通知」は、デバイス１０による処理の処理結果をアプリケーション８０に自動的に通知する処理（処理結果自動通知処理）である。当該結果通知を実行するための通信依頼は、「管理処理の実行のための通信依頼」であるとも表現される。同様に、「装置情報取得」は、アプリケーション８０による情報取得処理（ＭＦＰ１０および／またはゲートウエイ３０の情報をアプリケーション８０が自動的に取得する処理）である。当該「装置情報取得」を実行するための依頼処理も、「管理処理の実行のための通信依頼」であるとも表現される。

なお、「結果通知」処理は、その依頼元がデバイス１０であることから、「デバイストリガ通信依頼」処理にも分類される。また、「装置情報取得」処理は、その依頼元がアプリケーション８０であることから、「アプリトリガ通信依頼」処理にも分類される。

＜依頼処理の複合的分類＞
複数の通信依頼（アクセス要求）は、上述の２つの分類基準、すなわち、（１）「デバイストリガ通信依頼」であるか否かに関する基準、（２）「ユーザ指示処理（非管理処理）」であるか否かに関する基準、を用いて大きく４つに分類される。同様に、複数の通信依頼に基づく複数のトンネル接続要求も、当該２つの分類基準を用いて大きく４つに分類される。以下では、複数のトンネル接続要求の分類について主に説明するが、複数の通信依頼も同様に分類される。

図７は、このような分類を示す図である。図７においては、複数の通信依頼に基づく複数のトンネル接続要求が複数の種類に分類されている。当該複数の種類は、次の４つ、すなわち、
・Ｃ１１：「デバイストリガ通信依頼」且つ「ユーザ指示処理のための通信依頼」に基づくトンネル接続要求と、
・Ｃ１２：「デバイストリガ通信依頼」且つ「管理処理のための通信依頼」に基づくトンネル接続要求と、
・Ｃ２１：「アプリトリガ通信依頼」且つ「ユーザ指示処理のための通信依頼」に基づくトンネル接続要求と、
・Ｃ２２：「アプリトリガ通信依頼」且つ「管理処理のための通信依頼」に基づくトンネル接続要求と、
を含む。

管理サーバ５０は、各通信依頼を受信すると、当該各通信依頼に含まれるデータ等に基づき当該各通信依頼の処理内容を解析し、当該各通信依頼に対応する処理の種類等を知得する。たとえば、管理サーバ５０は、処理種類を示す番号（「クラウドスキャン」＝「００１」、「クラウドプリント」＝「００２」、「装置状態取得」＝「００３」、「結果通知」＝「００４」等）を当該データから知得する。また、管理サーバ５０は、当該データから知得した処理種類と管理サーバ５０内のデータテーブル（各処理種類と上述の４つの分類Ｃ１１，Ｃ１２，Ｃ２１，Ｃ２２）との対応関係を示すデータテーブル）とに基づいて、各処理種類のトンネル接続要求が４つの分類のいずれに該当するかを決定する。換言すれば、当該処理種類と当該データテーブルとに基づいて、各トンネル接続要求が、「デバイストリガ通信依頼」に基づくトンネル接続要求であるか「アプリトリガ通信依頼」に基づくトンネル接続要求であるかが決定される。また、当該処理種類と当該データテーブルとに基づいて、各トンネル接続要求が、「ユーザ指示処理」に基づくトンネル接続要求であるか「管理処理」に基づくトンネル接続要求であるかも決定される。

そして、４種類の分類Ｃ１１，Ｃ１２，Ｃ２１，Ｃ２２のうち、分類Ｃ１１に属するトンネル接続要求に対して最も高い優先度合い（指標値Ｖ）が付与され、分類Ｃ１２に属するトンネル接続要求に対して２番目に高い優先度合いが付与される。また、分類Ｃ２１に属するトンネル接続要求に対して３番目に高い優先度合いが付与され、分類Ｃ２２に属するトンネル接続要求に対して４番目に高い優先度合いが付与される。

より具体的には、図８および図９に示すようなポイントが付与される。「デバイストリガ通信依頼」に基づくトンネル接続要求に対しては、「＋１００」ポイントが付与され、「アプリトリガ通信依頼」に基づくトンネル接続要求に対しては、「＋０」ポイントが付与される。また、「ユーザ指示処理のための通信依頼」に基づくトンネル接続要求に対しては、「＋１０」ポイントが付与され、「管理処理のための通信依頼」に基づくトンネル接続要求に対しては、「＋０」ポイントが付与される。

図１１には、このようなポイント（評価値）付与動作が示されている。図１１のステップＳ６１において、トンネル接続要求がデバイストリガ通信依頼に基づくものであるか否かが判定される。トンネル接続要求がデバイストリガ通信依頼に基づくものである旨が判定される場合には、「＋１００」ポイントが付与される（ステップＳ６２）。一方、トンネル接続要求がアプリトリガ通信依頼に基づくものである旨が判定される場合には、ポイントは加算されない。なお、このようなポイント分配処理（加算処理）によれば、デバイストリガ通信依頼に基づくトンネル接続要求がアプリトリガ通信依頼に基づくトンネル接続要求よりも優先して実行される。

また、ステップＳ６３においては、トンネル接続要求がユーザ指示処理に基づくものであるか否かが判定される。トンネル接続要求がユーザ指示処理に基づくものである旨が判定される場合には、「＋１０」ポイントが付与される（ステップＳ６４）。一方、トンネル接続要求が管理処理に基づくものである旨が判定される場合には、ポイントは加算されない。なお、このようなポイント分配処理（加算処理）によれば、ユーザ指示処理に基づくトンネル接続要求が管理処理に基づくトンネル接続要求よりも優先して実行される。

ここにおいて、「デバイストリガ通信依頼」に基づくトンネル接続要求に対する重み付け（加算値「＋１００」）は、「ユーザ指示処理」に基づくトンネル接続要求に対する重み付け（加算値「＋１０」）よりも大きい。これにより、上述の２つの分類基準、すなわち、（１）「デバイストリガ通信依頼」であるか否かに関する基準、（２）「ユーザ指示処理（非管理処理）」であるか否かに関する基準、のうち、前者の基準（１）が後者の基準（２）よりも重視される（図７も参照）。

この結果、図９に示すような合計ポイント（指標値Ｖ）が付与される。分類Ｃ１１に属するトンネル接続要求（換言すれば、デバイストリガ通信依頼に基づき且つユーザ指示処理にも基づくトンネル接続要求）（たとえば、クラウドスキャンに関するトンネル接続要求）には合計１１０（＝１００＋１０）ポイントが付与される（Ｖ＝１１０）（ステップＳ６２，Ｓ６４参照）。分類Ｃ１２に属するトンネル接続要求（換言すれば、デバイストリガ通信依頼に基づき且つ管理処理にも基づくトンネル接続要求）（たとえば、結果通知に関するトンネル接続）には合計１００（＝１００＋０）ポイントが付与される（Ｖ＝１００）（ステップＳ６２参照）。また、分類Ｃ２１に属するトンネル接続要求（換言すれば、アプリトリガ通信依頼に基づき且つユーザ指示処理にも基づくトンネル接続要求）には合計１０（＝０＋１０）ポイントが付与される（Ｖ＝１０）（ステップＳ６４参照）。そして、分類Ｃ２２に属するトンネル接続要求（換言すれば、アプリトリガ通信依頼に基づき且つ管理処理にも基づくトンネル接続要求）には、合計０（＝０＋０）ポイントが付与される（Ｖ＝０）。

このように、４種類に分類されるトンネル接続要求Ｃ１１，Ｃ１２，Ｃ２１，Ｃ２２がこの順序で高い順に並ぶように、複数のトンネル接続要求に対して優先度合い（指標値Ｖ）が付与される。

そして、管理サーバ５０は、このような指標値Ｖに基づいて、複数のトンネル接続要求の優先順位を決定する。具体的には、管理サーバ５０は、４種類のトンネル接続要求Ｃ１１，Ｃ１２，Ｃ２１，Ｃ２２をこの順序で優先順位付けして実行する。

なお、２つ以上のトンネル接続要求の指標値Ｖが全く同一である場合には、当該２つ以上のトンネル接続要求は、その受付順序に従って処理される。

＜１−７．優先順位決定処理等の一例＞
図１２〜図１５は、管理サーバ５０の待ち行列内の様子を示す概念図である。これらの図を参照しながら、優先順位決定処理の一例について説明する。

図１２の状態ＳＴ１においては、クラウドスキャン３０１に対応するトンネル接続要求２０１（Ｃ１１）と装置状態取得処理Ｃ２２（３０２）に対応するトンネル接続要求２０２とが既に待ち行列に投入されている。

ここで、クラウドスキャン３０１は、デバイス１０ａからゲートウエイ３０ａを経由してアプリケーション８０ｂに向かう通信を依頼する処理である。また、装置状態取得処理３０２は、アプリケーション８０ｃからゲートウエイ３０ａを経由してデバイス１０ａに向かう通信を依頼する処理である。また、クラウドスキャン３０１に関するトンネル接続要求２０１には「＋１１０」の指標値Ｖが付与されており、装置状態取得処理３０２に関するトンネル接続要求２０２には「＋０」の指標値Ｖが付与されている。

図１２に示すように、この状態ＳＴ１においては、クラウドプリント３０３に関する通信依頼がさらに受信される。なお、クラウドプリント３０３は、アプリケーション８０ａからゲートウエイ３０ａを経由してデバイス１０ａに向かう通信を依頼する処理である。

当該通信依頼が受信されると、管理サーバ５０は、クラウドプリント３０３に対応するトンネル接続要求２０３（Ｃ２１）の指標値Ｖを「＋１０」に設定する。そして、管理サーバ５０は、指標値Ｖの降順になるように、待ち行列においてクラウドプリント３０３に関するトンネル接続要求２０３を、クラウドスキャン３０１に関するトンネル接続要求２０１の次順位（且つ装置状態取得処理３０２に関するトンネル接続要求２０２の前順位）の位置に配置する（図１３も参照）。

次に、図１３（状態ＳＴ２）に示すように、クラウドスキャン３０４に対応する通信依頼が受信されると、管理サーバ５０は、当該通信依頼に対応するトンネル接続要求２０４（Ｃ１１）の指標値Ｖを「＋１１０」に設定する。ここで、クラウドスキャン３０４は、デバイス１０ａからゲートウエイ３０ａを経由してアプリケーション８０ｂに向かう通信を依頼する処理である。そして、管理サーバ５０は、指標値Ｖの降順になるように、待ち行列においてクラウドスキャン３０４に関するトンネル接続要求２０４をクラウドスキャン３０１に関するトンネル接続要求２０１の次順位（且つクラウドプリント３０３に関するトンネル接続要求２０３の前順位）の位置に配置する（図１４も参照）。

次に、図１４（状態ＳＴ３）に示すように、結果通知処理３０５に対応する通信依頼が受信されると、管理サーバ５０は、当該通信依頼に対応するトンネル接続要求２０５（Ｃ１２）の指標値Ｖを「＋１００」に設定する。ここで、結果通知処理３０５は、デバイス１０ａからゲートウエイ３０ａを経由してアプリケーション８０ｄに向かう通信を依頼する処理である。そして、管理サーバ５０は、指標値Ｖの降順になるように、待ち行列において結果通知処理３０５に関するトンネル接続要求２０５をクラウドスキャン３０４に関するトンネル接続要求２０４の次順位（且つクラウドプリント３０３に関するトンネル接続要求２０３の前順位）の位置に配置する（図１５も参照）。

以上のようにして、複数の通信依頼および当該複数の通信依頼に基づく複数のトンネル接続要求の実行順序が決定される。そして、上述のように、当該実行順序に基づいて、複数の通信依頼および当該複数の通信依頼に基づく複数のトンネル接続要求が実行される。

詳細には、上述のように、２つの分類基準、すなわち、（１）「デバイストリガ通信依頼」であるか否かに関する基準、（２）「ユーザ指示処理（非管理処理）」であるか否かに関する基準、のうち、前者の基準（１）が後者の基準（２）よりも重視される。

より具体的には、まず、前者の基準（１）が優先的に（比較的大きな重み付けで）適用され、「デバイストリガ通信依頼」に基づくトンネル接続要求Ｃ１（Ｃ１１，Ｃ１２）が、「アプリトリガ通信依頼」に基づくトンネル接続要求Ｃ２（Ｃ２１，Ｃ２２）よりも優先して実行される。

また、後者の基準（２）が次順位で（比較的小さな重み付けで）適用され、「非管理処理」に基づくトンネル接続要求と「管理処理」に基づくトンネル接続要求とのうち、「非管理処理」に基づくトンネル接続要求が、「管理処理」に基づくトンネル接続要求よりも優先して実行される。より詳細には、同じ「デバイストリガ通信依頼」に基づくトンネル接続要求Ｃ１（図７参照）の相互間において、「ユーザ指示処理（非管理処理）」に基づくトンネル接続要求Ｃ１１が、「管理処理」に基づくトンネル接続要求Ｃ１２よりも優先して実行される。同様に、同じ「アプリトリガ通信依頼」に基づくトンネル接続要求Ｃ２の相互間において、「ユーザ指示処理（非管理処理）」に基づくトンネル接続要求Ｃ２１が、「管理処理」に基づくトンネル接続要求Ｃ２２よりも優先して実行される。

このように、複数のトンネル接続要求のうち、トンネル接続要求Ｃ１１，Ｃ１２，Ｃ２１，Ｃ２２とがこの順序で優先順位付けされて実行される。

＜１−８．実施形態の効果等＞
以上のような動作によれば、複数のトンネル接続要求のうち、デバイストリガ通信依頼に基づくトンネル接続要求がアプリトリガ通信依頼に基づくトンネル接続要求よりも優先して実行される。これによれば、複数のトンネル接続要求が好適な順序で実行され得る。

ここにおいて、アプリケーションでの処理が蓄積された（アプリケーションでの処理負荷が集中した）場合、アプリケーション側のハードウエア変更等（クラウドサーバ７０のハードウエア追加等）によってアプリケーション側の処理能力を向上させることは比較的容易である。一方、デバイスでの処理が蓄積された場合、デバイス側のハードウエア変更および追加等によってデバイスの処理能力を向上させることは比較的困難である。特に、デバイスの処理が待ち行列内の比較的後ろ側にて集中すると、比較的遅い時点から処理が開始されるとともに処理期間の遅延等が発生し、処理の終了時点（終期）が大きく遅延する事態になる可能性が高い。これに対して、デバイスの処理を比較的早い時点から開始することによれば、このような事態の発生を回避あるいは抑制することが可能である。

また、デバイス側から発せられる処理（デバイストリガ依頼処理）は、デバイスのハードウエアと特に密接に関連する処理（デバイスでの処理との関連性が比較的高い処理）であることが多い。上述のようにデバイスのハードウエア能力の拡大の余地が少ないこと等を考慮すると、「デバイストリガ依頼処理」を「アプリトリガ依頼処理」よりも優先することが好ましい。

また、「デバイストリガ通信依頼」に関する処理は、「アプリトリガ通信依頼」に関する処理と比べて、比較的高い即時性を要求されることが多い。たとえば、「クラウドスキャン」（デバイストリガ通信依頼処理（且つユーザ指示処理））は、「クラウドプリント」（アプリトリガ通信依頼処理（且つユーザ指示処理））よりも早期に実行されることが望まれることが多い。「クラウドスキャン」（デバイストリガ通信依頼処理）は、ＬＡＮの内側に存在する人（デバイス１０の近くに居る人）からの指示に基づく処理である。一方、「クラウドプリント」（アプリトリガ通信依頼に対応する処理）は、多くの場合、ＬＡＮの外側に存在する人（デバイスから遠く離れた人）からの指示に基づく処理である。デバイスの近くに居る人は、デバイスへの接近を伴う動作（デバイスのスキャナを用いたスキャン動作等）を比較的早い時期に行うことを希望することが多い。このように、一般に「クラウドスキャン」は「クラウドプリント」よりも高い即時性要求を有している。そして、「クラウドスキャン」が「クラウドプリント」よりも優先的に（先に）実行されることによれば、このような要求を充足させることが可能である。

また、「結果通知」処理（デバイストリガ通信依頼処理（且つ管理処理））と「装置状態取得」処理（アプリトリガ通信依頼処理（且つ管理処理））とを比較すると、「結果通知」処理は、「装置状態取得」処理よりも、比較的高い即時性を要求されることが多い。「結果通知」処理（デバイストリガ通信依頼に対応する処理）は、ＬＡＮの内側のデバイス１０における各種処理の処理結果を通知する処理であり、その即時性要求が比較的高い処理である。換言すれば、「装置状態取得」処理の即時性要求は、「結果通知」処理の即時性要求よりも低い。このような事情を考慮すると、「結果通知」処理（「デバイストリガ依頼処理」）を「装置状態取得」処理（「アプリトリガ依頼処理」）よりも優先することが好ましい。

上記実施形態においては、上記のような事情を踏まえ、デバイストリガ通信依頼に基づくトンネル接続要求がアプリトリガ通信依頼に基づくトンネル接続要求よりも優先して実行される。これによれば、安定したシステム運用を効率的に実現することが可能である。

また、上記実施形態においては、「ユーザ指示処理」に基づくトンネル接続要求が、「管理処理」に基づくトンネル接続要求よりも優先して実行される。利用ユーザによる指示操作に基づくユーザ指示処理（非管理処理）は、処理を実行したい利用ユーザが現に存在している（現に所望の操作を行っている）という特質を有していることに基づき即時性要求が高いと判断され、優先的に実行される。これによれば、当該特質を有するユーザ指示処理に基づくトンネル接続要求が、適切に優先的に実行され得る。

＜２．第２実施形態＞
＜２−１．概要＞
第２実施形態は、第１実施形態の変型例である。以下では、第１実施形態との相違点を中心に説明する。

上記第１実施形態においては、管理サーバ５０は、アプリケーション８０あるいはデバイス１０から受信した複数の通信依頼に基づく複数のトンネル接続要求の実行順序を、当該複数の通信依頼の依頼内容の分類結果のみに基づいて決定している。

一方、第２実施形態においては、当該複数のトンネル接続要求の実行順序が、当該複数の通信依頼の依頼内容の分類結果のみならず、当該複数の通信依頼の受信時点での各装置等（デバイス１０、ゲートウエイ３０およびクラウドサーバ７０（アプリケーション８０））の負荷の推定結果にも基づいて決定される態様を例示する。

具体的には、上述の４つのカテゴリー（Ｃ１１，Ｃ１２，Ｃ２１，Ｃ２２）のうちの同じカテゴリーに分類された２以上のトンネル接続要求の優先順位が、当該２以上のトンネル接続要求のそれぞれに関連する装置等の負荷に応じて決定される（図１６参照）。なお、図１６は、第２実施形態における分類（トンネル接続要求の分類）を示す図である。

換言すれば、この第２実施形態においては、上述の２つの分類基準（１）（２）に加えて、（３）当該複数の通信依頼の受信時点での各装置等が所定程度以上の高負荷状態を有するか否かに関する基準が用いられる。また、当該分類基準（３）は、上述の２つの分類基準（１）（２）よりも低い重み付けで考慮される。

また、この第２実施形態においては、管理サーバ５０は、各通信依頼に関連する各装置等の負荷を、当該装置等に関するトンネル接続の接続状況（トンネル接続の現在の接続数等）に基づいて推定する。なお、上述のように、当該トンネル接続の接続状況（接続数等）は、管理サーバ５０（情報管理部６５および管理テーブル６９等）にて管理されている。

＜２−２．デバイス１０の負荷＞
たとえば、ゲートウエイ３０とクラウドサーバ７０（アプリケーション８０）との間に既に確立されているトンネル接続であって特定のデバイス１０に関連するトンネル接続の接続数が閾値ＴＨ１（「２本」）よりも大きい場合には、管理サーバ５０は、当該特定のデバイス１０の負荷が所定程度よりも大きい（端的に言えば「ビジー状態」である）と判定する。一方、当該特定のデバイス１０に関連するトンネル接続の接続数が閾値ＴＨ１よりも小さい場合には、管理サーバ５０は、当該特定のデバイス１０の負荷が所定程度よりも小さい（端的に言えば「非ビジー状態」である）と判定する。なお、等号成立時は、ビジー状態であると判定されてもよく、逆に非ビジー状態であると判定されてもよい。

そして、管理サーバ５０は、非ビジー状態であると判定されたデバイス１０に関するトンネル接続要求（ビジーデバイスに関するトンネル接続要求）を、ビジー状態であると判定されたデバイス１０に関するトンネル接続要求（非ビジーデバイスに関するトンネル接続要求）よりも優先して実行する。

より詳細には、管理サーバ５０は、或るトンネル接続要求を受信した際に、当該トンネル接続要求に関与するデバイス１０に関してその時点で既に確立されている（別の）トンネル接続の接続数に基づき、当該デバイス１０が「ビジー状態」であるか否かを判定する。

図１７に示すように、当該デバイスが「ビジー状態」である場合には、受信した当該トンネル接続要求に対してマイナスポイント（「−１」ポイント）が付与される。一方、当該デバイスが「非ビジー状態」である場合には、受信した当該トンネル接続要求に対してゼロポイント（「０」ポイント）が付与される。そして、第１実施形態と同様のポイント付与結果に対して、さらにこれらのマイナスポイント等が加算される（結果的に低減等される）ことによって、各トンネル接続要求に対する評価値（指標値Ｖ）が算出され、当該評価値に基づいて優先順位が決定される。

これによれば、同じカテゴリー（Ｃ１１，Ｃ１２，Ｃ２１，Ｃ２２のいずれか）に分類された２以上のトンネル接続要求のうち、「非ビジー状態」のデバイス１０に関するトンネル接続要求が、「ビジー状態」のデバイス１０に関するトンネル接続要求よりも優先して実行される。すなわち、比較的空いているデバイス１０に関するトンネル接続要求が比較的優先して実行されるので、ビジー状態のデバイス１０に関するトンネル接続が実行されることに伴う待ち時間の発生および／または処理時間の長大化を回避あるいは抑制することができる。したがって、システム全体としての動作を効率化することが可能である。

＜２−３．ゲートウエイ３０の負荷＞
同様に、たとえば、ゲートウエイ３０とクラウドサーバ７０（アプリケーション８０）との間に既に確立されているトンネル接続であって特定のゲートウエイ３０に関連するトンネル接続の接続数が閾値ＴＨ２（「４本」）よりも大きい場合には、管理サーバ５０は、当該特定のゲートウエイ３０の負荷が所定程度よりも大きい（端的に言えば「ビジー状態」である）と判定する。一方、当該特定のゲートウエイ３０に関連するトンネル接続の接続数が閾値ＴＨ２よりも小さい場合には、管理サーバ５０は、当該特定のゲートウエイ３０の負荷が所定程度よりも小さい（端的に言えば「非ビジー状態」である）と判定する。なお、等号成立時は、ビジー状態であると判定されてもよく、逆に非ビジー状態であると判定されてもよい。

そして、管理サーバ５０は、非ビジー状態であると判定されたゲートウエイ３０に関するトンネル接続要求（ビジーゲートウエイに関するトンネル接続要求）を、ビジー状態であると判定されたゲートウエイ３０に関するトンネル接続要求（非ビジーゲートウエイに関するトンネル接続要求）よりも優先して実行する。

より詳細には、管理サーバ５０は、或るトンネル接続要求を受信した際に、当該トンネル接続要求に関与するゲートウエイ３０に関してその時点で既に確立されている（別の）トンネル接続の接続数に基づき、当該ゲートウエイ３０が「ビジー状態」であるか否かを判定する。

図１７に示すように、当該ゲートウエイ３０が「ビジー状態」である場合には、受信した当該トンネル接続要求に対してマイナスポイント（「−１」ポイント）が付与される。一方、当該ゲートウエイ３０が「非ビジー状態」である場合には、受信した当該トンネル接続要求に対してゼロポイント（「０」ポイント）が付与される。そして、第１実施形態と同様のポイント付与結果に対して、さらにこれらのマイナスポイント等が加算されることによって、各トンネル接続要求に対する評価値（指標値Ｖ）が算出され、当該評価値に基づいて優先順位が決定される。

これによれば、同じカテゴリー（Ｃ１１，Ｃ１２，Ｃ２１，Ｃ２２のいずれか）に分類された２以上のトンネル接続要求のうち、「非ビジー状態」のゲートウエイ３０に関するトンネル接続要求が、「ビジー状態」のゲートウエイ３０に関するトンネル接続要求よりも優先して実行される。すなわち、比較的空いているゲートウエイ３０に関するトンネル接続要求が比較的優先して実行されるので、ビジー状態のゲートウエイ３０に関するトンネル接続が実行されることに伴う待ち時間の発生および／または処理時間の長大化を回避あるいは抑制することができる。したがって、システム全体としての動作を効率化することが可能である。

＜２−４．アプリケーション８０の負荷＞
同様に、たとえば、ゲートウエイ３０とクラウドサーバ７０（アプリケーション８０）との間に既に確立されているトンネル接続であって、特定のアプリケーション８０に関連するトンネル接続の接続数が閾値ＴＨ３（「１０本」）よりも大きい場合には、管理サーバ５０は、当該特定のアプリケーション８０の負荷が所定程度よりも大きい（端的に言えば「ビジー状態」である）と判定する。一方、当該特定のアプリケーション８０に関連するトンネル接続の接続数が閾値ＴＨ３よりも小さい場合には、管理サーバ５０は、当該特定のアプリケーション８０の負荷が所定程度よりも小さい（端的に言えば「非ビジー状態」である）と判定する。なお、等号成立時は、ビジー状態であると判定されてもよく、逆に非ビジー状態であると判定されてもよい。

そして、管理サーバ５０は、非ビジー状態であると判定されたアプリケーション８０に関するトンネル接続要求（ビジーゲートウエイに関するトンネル接続要求）を、ビジー状態であると判定されたアプリケーション８０に関するトンネル接続要求（非ビジーゲートウエイに関するトンネル接続要求）よりも優先して実行する。

より詳細には、管理サーバ５０は、或るトンネル接続要求を受信した際に、当該トンネル接続要求に関与するアプリケーション８０に関してその時点で既に確立されている（別の）トンネル接続の接続数に基づき、当該アプリケーション８０が「ビジー状態」であるか否かを判定する。

図１７に示すように、当該アプリケーション８０が「ビジー状態」である場合には、受信した当該トンネル接続要求に対してマイナスポイント（「−１」ポイント）が付与される。一方、当該アプリケーション８０が「非ビジー状態」である場合には、当該受信したトンネル接続要求に対してゼロポイント（「０」ポイント）が付与される。そして、第１実施形態と同様のポイント付与結果に対して、さらにこれらのマイナスポイント等が加算されることによって、各トンネル接続要求に対する評価値（指標値Ｖ）が算出され、当該評価値に基づいて優先順位が決定される。

これによれば、同じカテゴリー（Ｃ１１，Ｃ１２，Ｃ２１，Ｃ２２のいずれか）に分類された２以上のトンネル接続要求のうち、「非ビジー状態」のアプリケーション８０に関するトンネル接続要求が、「ビジー状態」のアプリケーション８０に関するトンネル接続要求よりも優先して実行される。すなわち、比較的空いているアプリケーション８０に関するトンネル接続要求が比較的優先して実行されるので、ビジー状態のアプリケーション８０に関するトンネル接続が実行されることに伴う待ち時間の発生および／または処理時間の長大化を回避あるいは抑制することができる。したがって、システム全体としての動作を効率化することが可能である。

＜２−５．トンネル接続要求の優先順位決定動作等＞
第２実施形態においても、第１実施形態と同様の動作が行われる。ただし、図２０の動作が図１１の動作に代えて実行される。図２０は、トンネル接続要求の優先順位決定動作を示すフローチャートである。

図２０に示すように、ステップＳ６１〜Ｓ６４は、第１実施形態と同様である。

その後、受信したトンネル接続要求に関連するデバイス１０が「ビジー状態」である場合には、当該トンネル接続要求に対してマイナスポイント（「−１」ポイント）が付与される（ステップＳ７１，Ｓ７２）。一方、当該デバイス１０が「非ビジー状態」である場合には、当該トンネル接続要求に対してポイントが付与されない（「０」ポイントが付与される）。

また、受信したトンネル接続要求に関連するゲートウエイ３０が「ビジー状態」である場合には、当該トンネル接続要求に対してマイナスポイント（「−１」ポイント）が付与される（ステップＳ７３，Ｓ７４）。一方、当該ゲートウエイ３０が「非ビジー状態」である場合には、当該トンネル接続要求に対してポイントが付与されない（「０」ポイントが付与される）。

さらに、受信したトンネル接続要求に関連するアプリケーション８０が「ビジー状態」である場合には、当該トンネル接続要求に対してマイナスポイント（「−１」ポイント）が付与される（ステップＳ７５，Ｓ７６）。一方、当該アプリケーション８０が「非ビジー状態」である場合には、当該トンネル接続要求に対してポイントが付与されない（「０」ポイントが付与される）。

なお、ステップＳ７１〜７６にて付与されるポイントは、負荷調整ポイントとも称される。第２実施形態においては、ステップＳ６１〜Ｓ６４で算出されたポイントに対して、ステップＳ７１〜７６にて算出された当該負荷調整ポイントが加算されることによって指標値Ｖが算出される。そして、当該指標値Ｖに基づいて各トンネル接続要求の処理順序が決定される。また、２つ以上のトンネル接続要求の指標値Ｖ（ステップＳ７１〜Ｓ７６での負荷調整ポイント加算（減算）後のポイント）が全く同一である場合には、当該２つ以上のトンネル接続要求は、その受付順序に従って処理される。

＜２−６．優先順位決定処理の一例＞
＜状態ＳＴ３まで＞
図２１〜図２５は、管理サーバ５０の待ち行列内の様子を示す概念図である。これらの図を参照しながら、優先順位決定処理の一例について説明する。

第２実施形態においても、状態ＳＴ１〜ＳＴ３では、第１実施形態（図１２〜図１４参照）と同様の処理が実行される。なお、図２１においては、状態ＳＴ３に関する処理結果（図１５参照）に対して、新たなクラウドスキャン３０６に関するトンネル接続要求２０６が受信された状況が示されている。

ただし、この第２実施形態においては、各装置等（デバイス１０、ゲートウエイ３０、クラウドサーバ７０（アプリケーション８０））の負荷を考慮したマイナスポイントも付与される。ここでは、複数のデバイス１０のうちデバイス１０ａのみがビジーであり、複数のゲートウエイ３０のうちゲートウエイ３０ａのみがビジーであり、複数のアプリケーション８０のうちアプリケーション８０ｂのみがビジーである場合を想定する。

この場合、クラウドスキャン３０１（図２１の最上欄参照）に関するトンネル接続要求２０１には、デバイス１０ａがビジー状態であることに基づく「−１」ポイントと、ゲートウエイ３０ａがビジー状態であることに基づく「−１」ポイントと、アプリケーション８０ｂがビジー状態であることに基づく「−１」ポイントとの合計値「−３」ポイントが付与される（図２１の右から２列目（負荷調整ポイント欄）参照）。

そして、その他のポイント「１１０」に負荷調整ポイント「−３」を加算することによって、クラウドスキャン３０１に関するトンネル接続要求２０１の評価値（指標値Ｖ）は、合計「１０７」ポイントに設定される（図２１の最右列（合計値欄）、および図１８の上から２段目参照）。

同様に、クラウドスキャン３０４に関するトンネル接続要求２０４の指標値Ｖも、合計「１０７」ポイントに設定される。

また、結果通知処理３０５に関するトンネル接続要求２０５には、デバイス１０ａがビジー状態であることに基づく「−１」ポイントと、ゲートウエイ３０ａがビジー状態であることに基づく「−１」ポイントとの合計値（負荷調整ポイント）「−２」ポイントが付与される。その他のポイント「１００」に負荷調整ポイント「−２」を加算することによって、結果通知処理３０５に関するトンネル接続要求２０５の指標値Ｖは、合計「９８」ポイントに設定される（図２１の最右列、および図１９の上から２段目参照）。

同様に、クラウドプリント３０３に関するトンネル接続要求２０３の指標値Ｖは、合計「８」ポイントに設定され（図１８の最下段も参照）、装置状態取得処理３０２に関するトンネル接続要求２０２の指標値Ｖは、合計「−２」ポイントに設定される（図１９の最下段参照）。

なお、これらの各指標値は、各通信依頼の受信時に設定される。具体的には、クラウドスキャン３０１、装置状態取得処理３０２、クラウドプリント３０３、クラウドスキャン３０４、結果通知処理３０５の各処理に関する指標値Ｖは、当該各処理に関する通信依頼の受信時に（この順序で）設定される。そして、待ち行列内において、各通信依頼に基づくトンネル接続要求が、図２１に示すような優先順位で配列される。なお、図２１等においては、複数のトンネル接続要求が、その優先順位の高いものから順に、上から下に向けて配置されている。

＜状態ＳＴ４＞
次に、図２１（状態ＳＴ４）に示すように、新たな通信依頼、具体的にはクラウドスキャン３０６に対応する通信依頼が受信されると、管理サーバ５０は、当該通信依頼に対応するトンネル接続要求２０６（Ｃ１１）の指標値Ｖを「＋１０８」に設定する。ここで、クラウドスキャン３０６は、デバイス１０ｂ（１０ａではない）からゲートウエイ３０ａを経由してアプリケーション８０ｂに向かう通信を依頼する処理であり、負荷調整ポイントは「−２」である。そして、管理サーバ５０は、指標値Ｖの降順になるように、待ち行列においてクラウドスキャン３０６に関するトンネル接続要求２０６をクラウドスキャン３０１に関するトンネル接続要求２０１よりも前の順位の位置（先頭位置）に配置する（図２２も参照）。

これによれば、同一のカテゴリー（Ｃ１１）に分類される２つのクラウドスキャン３０１，３０６の相互間においては、負荷調整ポイントの大小によってその優先順位が決定される。具体的には、同一のゲートウエイ３０ａを経由して同一のアプリケーション８０ｂに向かうデータ送信を伴う２つの通信依頼に基づく２つのトンネル接続要求２０１，２０６の優先順位は、その互いに異なる依頼元デバイス１０ａ，１０ｂの負荷状況に応じて決定される。そして、決定された優先順位に従って当該２つのトンネル接続要求が実行される。詳細には、「非ビジー状態」のデバイス１０ｂに関するトンネル接続要求２０６が、「ビジー状態」のデバイス１０ａに関するトンネル接続要求２０１よりも優先して実行される。換言すれば、管理サーバ５０は、複数のデバイスのうち閾値ＴＨ１よりも大きな数のトンネル接続が未だ確立されていないデバイス１０ｂに関するトンネル接続要求を、当該複数のデバイスのうち閾値ＴＨ１よりも大きな数のトンネル接続が既に確立されているデバイス１０ａに関するトンネル接続要求よりも、優先して実行する。すなわち、比較的空いているデバイス１０ｂに関するトンネル接続要求２０６が比較的優先して実行される。したがって、ビジー状態のデバイス１０ａに関するトンネル接続要求２０１が実行されることに伴う待ち時間の発生および／または処理時間の長大化を回避あるいは抑制することができる。ひいては、システム全体としての動作を効率化することが可能である。

＜状態ＳＴ５＞
つぎに、図２２（状態ＳＴ５）に示すように、クラウドプリント３０７に対応する通信依頼が受信されると、管理サーバ５０は、当該通信依頼に対応するトンネル接続要求２０７（Ｃ２１）の指標値Ｖを「＋９」に設定する。ここで、クラウドプリント３０７は、アプリケーション８０ａからゲートウエイ３０ａを経由してデバイス１０ｂ（１０ａではない）に向かう通信を依頼する処理であり、負荷調整ポイントは「−１」である。そして、管理サーバ５０は、待ち行列においてクラウドプリント３０７に関するトンネル接続要求２０７を「結果通知処理３０５に関するトンネル接続要求２０５の次順位且つクラウドプリント３０３に関するトンネル接続要求２０３の前順位」の位置に配置する（図２３も参照）。

これによれば、同一のカテゴリー（Ｃ２１）に分類される２つのクラウドプリント３０３，３０７の相互間においては、負荷調整ポイントの大小によってその優先順位が決定される。具体的には、同一アプリケーション８０ａから同一のゲートウエイ３０を経由して受信される２つの通信依頼に基づく２つのトンネル接続要求２０３，２０７の優先順位は、その互いに異なる関与デバイス１０ａ，１０ｂの負荷状況に応じて決定される。そして、決定された優先順位に従って当該２つのトンネル接続要求が実行される。詳細には、「非ビジー状態」のデバイス１０ｂに関するトンネル接続要求２０７が、「ビジー状態」のデバイス１０ａに関するトンネル接続要求２０３よりも優先して実行される。すなわち、比較的空いているデバイス１０ｂに関するトンネル接続要求２０７が比較的優先して実行されるので、ビジー状態のデバイス１０ａに関するトンネル接続要求２０３が実行されることに伴う待ち時間の発生および／または処理時間の長大化を回避あるいは抑制することができる。したがって、システム全体としての動作を効率化することが可能である。

＜状態ＳＴ６＞
次に、図２３（状態ＳＴ６）に示すように、クラウドプリント３０８に対応する通信依頼が受信されると、管理サーバ５０は、当該通信依頼に対応するトンネル接続要求２０８（Ｃ２１）の指標値Ｖを「＋１０」に設定する。ここで、クラウドプリント３０８は、アプリケーション８０ａからゲートウエイ３０ｂ（ゲートウエイ３０ａではない）を経由してデバイス１０ｅ（１０ａではない）に向かう通信を依頼する処理であり、負荷調整ポイントは「０」である。そして、管理サーバ５０は、待ち行列においてクラウドプリント３０８に関するトンネル接続要求２０８を「結果通知処理３０５に関するトンネル接続要求２０５の次順位且つクラウドプリント３０７に関するトンネル接続要求２０７の前順位」の位置に配置する（図２４も参照）。

これによれば、同一のカテゴリー（Ｃ２１）に分類される２つのクラウドプリント３０７，３０８の相互間においては、負荷調整ポイントの大小によってその優先順位が決定される。具体的には、同一アプリケーション８０ａから受信される２つの通信依頼に基づく２つのトンネル接続要求２０７，２０８の優先順位は、その互いに異なる関与ゲートウエイ３０ｂ，３０ａの負荷状況とその互いに異なる関与デバイス１０ｅ，１０ｂの負荷状況とに応じて決定される。ここでは、関与デバイス１０ｅ，１０ｂの負荷状況は互いに同等（いずれも「低負荷」）であり、関与ゲートウエイ３０ｂ，３０ａの負荷状況が互いに異なっている。したがって、２つのトンネル接続要求２０７，２０８の優先順位は、関与ゲートウエイ３０ｂ，３０ａの負荷状況に応じて実質的に決定される。そして、決定された優先順位に従って当該２つのトンネル接続要求が実行される。詳細には、「非ビジー状態」のゲートウエイ３０ｂに関するトンネル接続要求２０８が、「ビジー状態」のゲートウエイ３０ａに関するトンネル接続要求２０７よりも優先して実行される。換言すれば、管理サーバ５０は、複数のゲートウエイ３０のうち閾値ＴＨ２よりも大きな数のトンネル接続を未だ確立していないゲートウエイ３０ｂに関するトンネル接続要求を、当該複数のゲートウエイ３０のうちの閾値ＴＨ２よりも大きな数のトンネル接続を既に確立しているゲートウエイ３０ａに関するトンネル接続要求よりも、優先して実行する。すなわち、比較的空いているゲートウエイ３０ｂに関するトンネル接続要求２０８が比較的優先して実行される。したがって、ビジー状態のゲートウエイ３０ａに関するトンネル接続要求２０７が実行されることに伴う待ち時間の発生および／または処理時間の長大化を回避あるいは抑制することができる。ひいては、システム全体としての動作を効率化することが可能である。

＜状態ＳＴ７＞
次に、図２４（状態ＳＴ７）に示すように、クラウドスキャン３０９に対応する通信依頼が受信されると、管理サーバ５０は、当該通信依頼に対応するトンネル接続要求２０９（Ｃ１１）の指標値Ｖを「＋１０８」に設定する。ここで、クラウドスキャン３０９は、デバイス１０ａからゲートウエイ３０ａを経由してアプリケーション８０ｅ（８０ｂではない）に向かう通信を依頼する処理であり、負荷調整ポイントは「−２」である。そして、管理サーバ５０は、待ち行列においてクラウドスキャン３０９に関するトンネル接続要求２０９をクラウドスキャン３０６に関するトンネル接続要求２０６の次順位（且つクラウドスキャン３０１に関するトンネル接続要求２０１の前順位）の位置に配置する（図２４も参照）。

これによれば、同一のカテゴリー（Ｃ１１）に分類される２つのクラウドスキャン３０１，３０９の相互間においては、負荷調整ポイントの大小によってその優先順位が決定される。具体的には、同一のデバイス１０ａから同一のゲートウエイ３０ａを経由して異なるアプリケーション８０ａ，８０ｂに向かうデータ送信を伴う２つの通信依頼に基づく２つのトンネル接続要求２０１，２０９の優先順位は、その互いに異なる送信先アプリケーション８０ｂ，８０ｅの負荷状況に応じて決定される。そして、決定された優先順位に従って当該２つのトンネル接続要求が実行される。詳細には、「非ビジー状態」のアプリケーション８０ｅに関するトンネル接続要求２０９が、「ビジー状態」のアプリケーション８０ｂに関するトンネル接続要求２０１よりも優先して実行される。換言すれば、管理サーバ５０は、複数のアプリケーション８０のうち閾値ＴＨ３よりも大きな数のトンネル接続を未だ確立していないアプリケーション８０ｅに関するトンネル接続要求を、複数のアプリケーション８０のうち閾値ＴＨ２よりも大きな数のトンネル接続を既に確立しているアプリケーション８０ｂに関するトンネル接続要求よりも、優先して実行する。すなわち、比較的空いているアプリケーション８０ｅに関するトンネル接続要求２０９が比較的優先して実行される。したがって、ビジー状態のアプリケーション８０ｂに関するトンネル接続要求２０１が実行されることに伴う待ち時間の発生および／または処理時間の長大化を回避あるいは抑制することができる。ひいては、システム全体としての動作を効率化することが可能である。

＜３．変形例等＞
以上、この発明の実施の形態について説明したが、この発明は上記説明した内容のものに限定されるものではない。

たとえば、上記各実施形態においては、トンネル接続要求がユーザ指示処理に基づくものであるか管理処理に基づくものであるかが、依頼処理の処理種類（当該処理種類を表すデータ等）に基づいて決定されているが、これに限定されない。

具体的には、管理サーバ５０は、トンネル接続要求がユーザ指示処理に基づくものであるか管理処理に基づくものであるかを、各通信依頼に係るデータ転送にて利用される通信プロトコルに基づいて判定するようにしてもよい。たとえば、通信依頼後の実際のデータ通信が、通信速度（リアルタイム性）を優先しデータの完全性を保証しない通信プロトコル（たとえばＵＤＰ（User Datagram Protocol））を用いるものである場合には、当該通信依頼に対応するトンネル接続要求は管理処理に基づくトンネル接続要求である、と判定されるようにしてもよい。逆に、通信依頼後の実際のデータ通信が、データの完全性を重視する通信プロトコル（たとえばＴＣＰ（Transmission Control Protocol））を用いるデータ通信を伴うものである場合には、当該通信依頼に対応するトンネル接続要求は非管理処理に基づくトンネル接続要求であると判定するようにしてもよい。なお、管理サーバ５０は、各通信依頼と当該各通信依頼に応じた実際のデータ通信にて利用される通信プロトコルとの対応関係を示すデータテーブルを格納部５５に予め格納しておく。そして、管理サーバ５０は、当該データテーブル等に基づいて、各通信依頼に応じた通信プロトコル（各通信依頼に応じて実際のデータ通信にて用いられる通信プロトコル（ＵＤＰ／ＴＣＰ等））を判定（取得）すればよい。

あるいは、管理サーバ５０は、通信依頼の依頼元のユーザ種類に応じて、当該通信依頼に対応するトンネル接続要求がユーザ指示処理に基づくものであるか管理処理に基づくものであるかを判定するようにしてもよい。詳細には、依頼元ユーザが管理者（管理ユーザ）である場合には、当該通信依頼に対応するトンネル接続要求が管理処理に基づくトンネル接続要求である旨が決定されればよい。逆に、依頼元ユーザが利用者（利用ユーザ）（非管理者）である場合には、当該通信依頼に対応するトンネル接続要求がユーザ指示処理に基づくトンネル接続要求である旨が決定されればよい。

さらには、当該通信依頼が定期的に（一定周期で）発生しているものである場合、当該通信依頼に対応するトンネル接続要求は管理処理に基づくトンネル接続要求であると判定されるようにしてもよい。たとえば、毎日同時刻に通算で所定回数以上繰り返して受信される同種の通信依頼は、「管理処理」に関するものであると判定されるようにしてもよい。

また、上記各実施形態においては、複数の通信依頼（および当該複数の通信依頼に基づく複数のトンネル接続要求）が２つの分類基準を用いて大きく４つに分類されている（図７等参照）が、これに限定されない。たとえば、２つの分類基準のうちの一方（具体的には、「デバイストリガ通信依頼」であるか否かに関する基準）のみを用いて、複数の通信依頼（および当該複数の通信依頼に基づく複数のトンネル接続要求）が大きく２つにのみ分類されるようにしてもよい。

また、上記各実施形態においては、各クラウドサーバ７０に１つのアプリケーション８０が設けられているが、これに限定されず、単一のクラウドサーバ７０内に複数のアプリケーション８０が設けられてもよい。

また、上記各実施形態においては、１つのアプリケーション８０が単一の機能を有しているが、これに限定されず、１つのアプリケーション８０が複数の機能（たとえば、クラウドスキャン機能およびクラウドプリント機能）を有していてもよい。換言すれば、各アプリケーション８０は複数の種類の処理を実行するものであってもよい。

また、上記各実施形態の通信システム１においては、複数のデバイス１０と複数のゲートウエイ３０と複数のクラウドサーバ７０（アプリケーション８０）とが設けられているが、これに限定されない。具体的には、各装置等１０，３０，７０（８０）のうちの少なくとも１つが単一であってもよい。たとえば、通信システム１において、複数のデバイス１０と単一のゲートウエイ３０と複数のアプリケーション８０とが設けられてもよい。あるいは、単一のデバイス１０と単一のゲートウエイ３０と複数のアプリケーション８０とが設けられてもよい。あるいは、単一のデバイス１０と単一のゲートウエイ３０と単一のアプリケーション８０とが設けられてもよい。

１ 通信システム
１０ デバイス（ＭＦＰ）
３０ ゲートウエイ
５０ 管理サーバ
７０ クラウドサーバ
８０ アプリケーション
９０ クライアント
Ｖ 指標値

Claims (21)

1. 通信システムであって、
   ファイアウォールの内側に設けられる少なくとも１つのデバイスと、
   前記ファイアウォールの外側に設けられる少なくとも１つのクラウドサーバと、
   前記少なくとも１つのデバイスと前記少なくとも１つのクラウドサーバで実行される少なくとも１つのアプリケーションとの間の通信を中継する少なくとも１つのゲートウエイと、
   前記少なくとも１つのデバイスと前記少なくとも１つのアプリケーションとの間の通信であって前記少なくとも１つのゲートウエイを介した通信を管理する管理サーバと、
   を備え、
   前記管理サーバは、
   前記少なくとも１つのデバイスのいずれかからの通信依頼であって前記少なくとも１つのデバイス側から前記少なくとも１つのアプリケーション側へ向かう向きのデータ転送を伴う通信の依頼である第１の通信依頼と、前記少なくとも１つのアプリケーションのいずれかからの通信依頼であって前記少なくとも１つのアプリケーション側から前記少なくとも１つのデバイス側へ向かう向きのデータ転送を伴う通信の依頼である第２の通信依頼とを含む複数の通信依頼を受信する受信手段と、
   前記複数の通信依頼に基づく複数のトンネル接続要求の実行順序を制御するトンネル接続要求制御手段と、
   を有し、
   各トンネル接続要求は、前記少なくとも１つのゲートウエイのいずれかと前記少なくとも１つのアプリケーションのいずれかとの間でのトンネル接続を用いた通信を行うべき旨を前記少なくとも１つのゲートウエイのいずれかに対して要求する指令であり、
   前記トンネル接続要求制御手段は、前記第１の通信依頼に基づくトンネル接続要求である第１のトンネル接続要求を、前記第２の通信依頼に基づくトンネル接続要求である第２のトンネル接続要求よりも優先して実行することを特徴とする通信システム。
2. 請求項１に記載の通信システムにおいて、
   前記トンネル接続要求制御手段は、利用ユーザによる指示に応じたユーザ指示処理の実行のための第３の通信依頼に基づくトンネル接続要求である第３のトンネル接続要求と、前記利用ユーザによる指示を前提としない管理処理の実行のための第４の通信依頼に基づくトンネル接続要求である第４のトンネル接続要求とのうち、前記第３のトンネル接続要求を前記第４のトンネル接続要求よりも優先して実行することを特徴とする通信システム。
3. 請求項２に記載の通信システムにおいて、
   前記トンネル接続要求制御手段は、
   （１）前記第１のトンネル接続要求であって前記第３のトンネル接続要求でもあるトンネル接続要求と、
   （２）前記第１のトンネル接続要求であって前記第４のトンネル接続要求でもあるトンネル接続要求と、
   （３）前記第２のトンネル接続要求であって前記第３のトンネル接続要求でもあるトンネル接続要求と、
   （４）前記第２のトンネル接続要求であって前記第４のトンネル接続要求でもあるトンネル接続要求と、
   を前記（１）〜（４）の順序で優先順位付けして実行することを特徴とする通信システム。
4. 請求項１ないし請求項３のいずれかに記載の通信システムにおいて、
   前記通信システムには複数のデバイスが設けられ、
   前記トンネル接続要求制御手段は、前記複数のデバイスのうち第１の閾値よりも大きな数のトンネル接続を未だ確立していない第１のデバイスに関するトンネル接続要求を、前記複数のデバイスのうち前記第１の閾値よりも大きな数のトンネル接続を既に確立している第２のデバイスに関するトンネル接続要求よりも、優先して実行することを特徴とする通信システム。
5. 請求項１ないし請求項４のいずれかに記載の通信システムにおいて、
   前記通信システムには複数のゲートウエイが設けられ、
   前記トンネル接続要求制御手段は、前記複数のゲートウエイのうち第２の閾値よりも大きな数のトンネル接続を未だ確立していない第１のゲートウエイに関するトンネル接続要求を、前記複数のゲートウエイのうち前記第２の閾値よりも大きな数のトンネル接続を既に確立している第２のゲートウエイに関するトンネル接続要求よりも、優先して実行することを特徴とする通信システム。
6. 請求項１ないし請求項５のいずれかに記載の通信システムにおいて、
   前記通信システムには複数のアプリケーションが設けられ、
   前記トンネル接続要求制御手段は、前記複数のアプリケーションのうち第３の閾値よりも大きな数のトンネル接続を未だ確立していない第１のアプリケーションに関するトンネル接続要求を、前記複数のアプリケーションのうち前記第３の閾値よりも大きな数のトンネル接続を既に確立している第２のアプリケーションに関するトンネル接続要求よりも、優先して実行することを特徴とする通信システム。
7. 請求項１ないし請求項６のいずれかに記載の通信システムにおいて、
   前記トンネル接続要求制御手段は、前記受信手段によって受信された前記複数の通信依頼に対応する複数のトンネル接続要求に対して各評価値をそれぞれ算出し、前記各評価値に基づいて前記複数のトンネル接続要求の優先順位を決定することを特徴とする通信システム。
8. 請求項２または請求項３に記載の通信システムにおいて、
   前記第３の通信依頼および前記第４の通信依頼は、それぞれ、前記少なくとも１つのデバイスのいずれかと前記少なくとも１つのアプリケーションのいずれかとの間でのデータ通信を伴う通信の依頼であり、
   前記トンネル接続要求制御手段は、前記受信手段によって受信された通信依頼に基づくトンネル接続要求が前記第３のトンネル接続要求であるか前記第４のトンネル接続要求であるかを、各通信依頼に応じて実際のデータ通信にて用いられる通信プロトコルに基づいて判定することを特徴とする通信システム。
9. 請求項８に記載の通信システムにおいて、
   前記トンネル接続要求制御手段は、前記各通信依頼と当該各通信依頼に応じた前記データ通信にて利用される通信プロトコルとの対応関係を示すデータテーブルに基づいて、前記各通信依頼に応じて実際のデータ通信にて用いられる通信プロトコルを判定することを特徴とする通信システム。
10. 請求項２または請求項３に記載の通信システムにおいて、
    前記トンネル接続要求制御手段は、前記受信手段によって受信された通信依頼に基づくトンネル接続要求が前記第３のトンネル接続要求であるか前記第４のトンネル接続要求であるかを、前記通信依頼の依頼元ユーザが利用ユーザであるか管理ユーザであるかに応じて判定することを特徴とする通信システム。
11. ファイアウォールの内側に設けられる少なくとも１つのデバイスと前記ファイアウォールの外側に設けられる少なくとも１つのクラウドサーバで実行される少なくとも１つのアプリケーションとの間の通信であって少なくとも１つのゲートウエイによって中継される通信を管理する管理サーバであって、
    前記少なくとも１つのデバイスのいずれかからの通信依頼であって前記少なくとも１つのデバイス側から前記少なくとも１つのアプリケーション側へ向かう向きのデータ転送を伴う通信の依頼である第１の通信依頼と、前記少なくとも１つのアプリケーションのいずれかからの通信依頼であって前記少なくとも１つのアプリケーション側から前記少なくとも１つのデバイス側へ向かう向きのデータ転送を伴う通信の依頼である第２の通信依頼とを含む複数の通信依頼を受信する受信手段と、
    前記複数の通信依頼に基づく複数のトンネル接続要求の実行順序を制御するトンネル接続要求制御手段と、
    を備え、
    各トンネル接続要求は、前記少なくとも１つのゲートウエイのいずれかと前記少なくとも１つのアプリケーションのいずれかとの間でのトンネル接続を用いた通信を行うべき旨を前記少なくとも１つのゲートウエイのいずれかに対して要求する指令であり、
    前記トンネル接続要求制御手段は、前記第１の通信依頼に基づくトンネル接続要求である第１のトンネル接続要求を、前記第２の通信依頼に基づくトンネル接続要求である第２のトンネル接続要求よりも優先して実行することを特徴とする管理サーバ。
12. 請求項１１に記載の管理サーバにおいて、
    前記トンネル接続要求制御手段は、利用ユーザによる指示に応じたユーザ指示処理の実行のための第３の通信依頼に基づくトンネル接続要求である第３のトンネル接続要求と、前記利用ユーザによる指示を前提としない管理処理の実行のための第４の通信依頼に基づくトンネル接続要求である第４のトンネル接続要求とのうち、前記第３のトンネル接続要求を前記第４のトンネル接続要求よりも優先して実行することを特徴とする管理サーバ。
13. 請求項１２に記載の管理サーバにおいて、
    前記トンネル接続要求制御手段は、
    （１）前記第１のトンネル接続要求であって前記第３のトンネル接続要求でもあるトンネル接続要求と、
    （２）前記第１のトンネル接続要求であって前記第４のトンネル接続要求でもあるトンネル接続要求と、
    （３）前記第２のトンネル接続要求であって前記第３のトンネル接続要求でもあるトンネル接続要求と、
    （４）前記第２のトンネル接続要求であって前記第４のトンネル接続要求でもあるトンネル接続要求と、
    を前記（１）〜（４）の順序で優先順位付けして実行することを特徴とする管理サーバ。
14. 請求項１１ないし請求項１３のいずれかに記載の管理サーバにおいて、
    前記トンネル接続要求制御手段は、前記ファイアウォールの内側に設けられる複数のデバイスのうち第１の閾値よりも大きな数のトンネル接続を未だ確立していない第１のデバイスに関するトンネル接続要求を、前記複数のデバイスのうち前記第１の閾値よりも大きな数のトンネル接続を既に確立している第２のデバイスに関するトンネル接続要求よりも、優先して実行することを特徴とする管理サーバ。
15. 請求項１１ないし請求項１４のいずれかに記載の管理サーバにおいて、
    前記トンネル接続要求制御手段は、前記少なくとも１つのデバイスと前記少なくとも１つのアプリケーションとの間の通信を中継する複数のゲートウエイのうち第２の閾値よりも大きな数のトンネル接続を未だ確立していない第１のゲートウエイに関するトンネル接続要求を、前記複数のゲートウエイのうち前記第２の閾値よりも大きな数のトンネル接続を既に確立している第２のゲートウエイに関するトンネル接続要求よりも、優先して実行することを特徴とする管理サーバ。
16. 請求項１１ないし請求項１５のいずれかに記載の管理サーバにおいて、
    前記トンネル接続要求制御手段は、前記ファイアウォールの外側に設けられる複数のアプリケーションのうち第３の閾値よりも大きな数のトンネル接続を未だ確立していない第１のアプリケーションに関するトンネル接続要求を、前記複数のアプリケーションのうち前記第３の閾値よりも大きな数のトンネル接続を既に確立している第２のアプリケーションに関するトンネル接続要求よりも、優先して実行することを特徴とする管理サーバ。
17. 請求項１１ないし請求項１６のいずれかに記載の管理サーバにおいて、
    前記トンネル接続要求制御手段は、前記受信手段によって受信された前記複数の通信依頼に対応する前記複数のトンネル接続要求に対して各評価値をそれぞれ算出し、前記各評価値に基づいて前記複数のトンネル接続要求の優先順位を決定することを特徴とする管理サーバ。
18. 請求項１２または請求項１３に記載の管理サーバにおいて、
    前記第３の通信依頼および前記第４の通信依頼は、それぞれ、前記少なくとも１つのデバイスのいずれかと前記少なくとも１つのアプリケーションのいずれかとの間でのデータ通信を伴う通信の依頼であり、
    前記トンネル接続要求制御手段は、前記受信手段によって受信された通信依頼に基づくトンネル接続要求が前記第３のトンネル接続要求であるか前記第４のトンネル接続要求であるかを、各通信依頼に応じて実際のデータ通信にて用いられる通信プロトコルに基づいて判定することを特徴とする管理サーバ。
19. 請求項１８に記載の管理サーバにおいて、
    前記トンネル接続要求制御手段は、前記各通信依頼と前記各通信依頼に応じた前記データ通信にて利用される通信プロトコルとの対応関係を示すデータテーブルに基づいて、前記各通信依頼に応じて実際のデータ通信にて用いられる通信プロトコルを判定することを特徴とする管理サーバ。
20. 請求項１２または請求項１３に記載の管理サーバにおいて、
    前記トンネル接続要求制御手段は、前記受信手段によって受信された通信依頼に基づくトンネル接続要求が前記第３のトンネル接続要求であるか前記第４のトンネル接続要求であるかを、前記通信依頼の依頼元ユーザが利用ユーザであるか管理ユーザであるかに応じて判定することを特徴とする管理サーバ。
21. ファイアウォールの内側に設けられる少なくとも１つのデバイスと前記ファイアウォールの外側に設けられる少なくとも１つのクラウドサーバで実行される少なくとも１つのアプリケーションとの間の通信であって少なくとも１つのゲートウエイによって中継される通信を管理する管理サーバに内蔵されたコンピュータに、
    ａ）前記少なくとも１つのデバイスのいずれかからの通信依頼であって前記少なくとも１つのデバイス側から前記少なくとも１つのアプリケーション側へ向かう向きのデータ転送を伴う通信の依頼である第１の通信依頼と、前記少なくとも１つのアプリケーションのいずれかからの通信依頼であって前記少なくとも１つのアプリケーション側から前記少なくとも１つのデバイス側へ向かう向きのデータ転送を伴う通信の依頼である第２の通信依頼とを含む複数の通信依頼を受信するステップと、
    ｂ）前記複数の通信依頼に基づく複数のトンネル接続要求の実行順序を制御するステップと、
    を実行させるためのプログラムであって、
    各トンネル接続要求は、前記少なくとも１つのゲートウエイのいずれかと前記少なくとも１つのアプリケーションのいずれかとの間でのトンネル接続を用いた通信を行うべき旨を前記少なくとも１つのゲートウエイのいずれかに対して要求する指令であり、
    前記ステップｂ）においては、前記第１の通信依頼に基づくトンネル接続要求である第１のトンネル接続要求が、前記第２の通信依頼に基づくトンネル接続要求である第２のトンネル接続要求よりも優先して実行されることを特徴とするプログラム。