特許 6623797 通信システム、通信中継装置およびプログラム

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

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

(11)【特許番号】6623797

(24)【登録日】2019年12月6日

(45)【発行日】2019年12月25日

(54)【発明の名称】通信システム、通信中継装置およびプログラム

(51)【国際特許分類】

   H04L 12/66 20060101AFI20191216BHJP

   H04L 12/70 20130101ALI20191216BHJP

【ＦＩ】

   H04L12/66 A

   H04L12/70 A

【請求項の数】22

【全頁数】43

(21)【出願番号】特願2016-16135(P2016-16135)

(22)【出願日】2016年1月29日

(65)【公開番号】特開2017-135658(P2017-135658A)

(43)【公開日】2017年8月3日

【審査請求日】2018年9月14日

(73)【特許権者】

【識別番号】000001270

【氏名又は名称】コニカミノルタ株式会社

(74)【代理人】

【識別番号】100117673

【弁理士】

【氏名又は名称】中島 了

(72)【発明者】

【氏名】河野 高廣

【審査官】 羽岡 さやか

(56)【参考文献】

【文献】 特開２０１６−０１５５６１（ＪＰ，Ａ）

【文献】 特開２００３−１４３２１２（ＪＰ，Ａ）

【文献】 特開２０１４−０８２７３９（ＪＰ，Ａ）

【文献】 特表２０１１−５１７３５６（ＪＰ，Ａ）

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

Ｈ０４Ｌ １２／００−１２／９５５

Ｇ０６Ｆ ３／１２

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

【請求項1】

通信システムであって、
ファイアウォールの内側に設けられる少なくとも１つのデバイスと、
前記ファイアウォールの外側に設けられる少なくとも１つのクラウドサーバと、
前記少なくとも１つのデバイスと前記少なくとも１つのクラウドサーバで実行される少なくとも１つのアプリケーションとの間の通信を中継する通信中継装置と、
を備え、
前記通信中継装置は、
前記少なくとも１つのデバイスのいずれか或いは前記少なくとも１つのアプリケーションのいずれかからの通信依頼に基づく接続要求であって、前記通信中継装置と前記少なくとも１つのアプリケーションのうちの一のアプリケーションとの間での個別接続を確立すべき旨の接続要求を受信する通信制御手段と、
前記通信中継装置と前記少なくとも１つのアプリケーションとの間で確立される個別接続の接続数の上限値であってアプリケーションごとの上限値であるアプリケーション別上限値を、前記通信中継装置との間で個別接続を確立しているアプリケーションの個数の現在値に基づいて決定する決定手段と、
前記通信制御手段は、
前記通信中継装置と前記一のアプリケーションとの間で現在確立されている個別接続の合計接続数が前記一のアプリケーション向けの前記アプリケーション別上限値よりも小さいことを条件として、前記一のアプリケーションとの間での新たな個別接続を前記接続要求に応じて確立するとともに、
前記通信中継装置との間で現在確立されている個別接続の合計接続数が前記アプリケーション別上限値を超えているアプリケーションである高負荷アプリケーションが存在する場合、前記高負荷アプリケーションと前記通信中継装置との通信のリクエスト時間間隔を増大することを特徴とする通信システム。

【請求項2】

請求項１に記載の通信システムにおいて、
前記決定手段は、前記通信中継装置との個別接続を既に確立しているアプリケーション以外のアプリケーションとの間で更なる個別接続を確立すべき旨の接続要求が受信されると、前記アプリケーション別上限値を低減し、
前記通信制御手段は、前記アプリケーション別上限値の低減に応じて前記高負荷アプリケーションが発生する場合、前記高負荷アプリケーションと前記通信中継装置との通信のリクエスト時間間隔を増大することを特徴とする通信システム。

【請求項3】

請求項１または請求項２に記載の通信システムにおいて、
前記決定手段は、前記通信中継装置において前記少なくとも１つのアプリケーションとの間で確立可能な個別接続の最大数と、前記通信中継装置との個別接続が確立しているアプリケーションの個数の現在値とに基づいて、前記アプリケーション別上限値を決定することを特徴とする通信システム。

【請求項4】

請求項１または請求項２に記載の通信システムにおいて、
前記決定手段は、前記通信中継装置において前記少なくとも１つのアプリケーションとの間で確立可能な個別接続の最大数を、前記通信中継装置との個別接続が現在確立している複数のアプリケーションに対して均等に分配することによって、前記アプリケーション別上限値を決定することを特徴とする通信システム。

【請求項5】

請求項１または請求項２に記載の通信システムにおいて、
前記決定手段は、前記通信中継装置との間で個別接続を現在確立している複数のアプリケーションのそれぞれに関して、前記複数のアプリケーションと前記通信中継装置との接続履歴情報に基づいて、前記アプリケーション別上限値をアプリケーションごとに決定することを特徴とする通信システム。

【請求項6】

請求項５に記載の通信システムにおいて、
前記決定手段は、前記複数のアプリケーションと前記通信中継装置との過去の接続における通信負荷の多寡を示す指標値の比率に基づいて前記通信中継装置の最大接続数を前記複数のアプリケーションに分配することによって、前記アプリケーション別上限値をアプリケーションごとに決定することを特徴とする通信システム。

【請求項7】

請求項１から請求項６のいずれかに記載の通信システムにおいて、
前記通信制御手段は、前記接続要求が第１の種類の通信依頼と第２の種類の通信依頼とのうちのいずれの種類の通信依頼に基づくものであるかを判定し、
前記第１の種類の通信依頼は、前記少なくとも１つのアプリケーション側から前記少なくとも１つのデバイス側へ向かう向きに発せられる通信依頼であり、
前記第２の種類の通信依頼は、前記少なくとも１つのデバイス側から前記少なくとも１つのアプリケーション側へ向かう向きに発せられる通信依頼であり、
前記決定手段は、前記アプリケーション別上限値を前記第１の種類の通信依頼と前記第２の種類の通信依頼とに対して分配した種類別上限値をも決定し、
前記通信制御手段は、前記通信中継装置と前記一のアプリケーションとの間で現在確立されている個別接続の合計接続数のうち、前記接続要求の通信依頼種類と同じ種類である特定種類の通信依頼に基づく個別接続の個数が、前記一のアプリケーション向け且つ前記特定種類の通信依頼向けの前記種類別上限値よりも小さいことを条件として、前記一のアプリケーションとの間での新たな個別接続を前記接続要求に応じて確立することを特徴とする通信システム。

【請求項8】

請求項７に記載の通信システムにおいて、
前記通信制御手段は、前記通信中継装置との間で現在確立されている個別接続のうち所定種類の通信依頼に基づく個別接続の合計接続数が前記所定種類の通信依頼に対応する前記種類別上限値を超えているアプリケーションである種類別高負荷アプリケーションが存在する場合、前記種類別高負荷アプリケーションと前記通信中継装置との通信であって前記所定種類の通信依頼に対応する通信におけるリクエスト時間間隔を増大することを特徴とする通信システム。

【請求項9】

請求項７または請求項８に記載の通信システムにおいて、
前記決定手段は、前記第２の種類の通信依頼向けの前記種類別上限値を、前記第１の種類の通信依頼向けの前記種類別上限値よりも大きな値として決定することを特徴とする通信システム。

【請求項10】

請求項７から請求項９のいずれかに記載の通信システムにおいて、
前記通信制御手段は、前記接続要求が第１の種類の通信依頼と第２の種類の通信依頼とのうちのいずれの種類の通信依頼に基づくものであるかを、前記接続要求の通信プロトコルに基づいて判定することを特徴とする通信システム。

【請求項11】

請求項１から請求項１０のいずれかに記載の通信システムにおいて、
前記少なくとも１つのデバイスと前記少なくとも１つのアプリケーションとの間の通信であって前記通信中継装置を介した通信を管理する管理サーバ、
をさらに備え、
前記管理サーバは、
個別接続に関する前記通信中継装置内での現在の待機状況に関する情報である待機状況情報を取得する手段と、
前記少なくとも１つのアプリケーション側から前記少なくとも１つのデバイス側へ向かう向きに発せられる通信依頼である第１の種類の通信依頼を前記少なくとも１つのアプリケーションのいずれかから受信すると、前記待機状況情報に基づいて、前記第１の種類の通信依頼に基づく接続要求を直ちに前記通信中継装置に送信するか或るいは前記第１の種類の通信依頼に基づく接続要求の送信を暫時保留するかを決定する手段と、
を有することを特徴とする通信システム。

【請求項12】

ファイアウォールの内側に設けられる少なくとも１つのデバイスと前記ファイアウォールの外側に設けられる少なくとも１つのクラウドサーバで実行される少なくとも１つのアプリケーションとの間の通信を中継する通信中継装置であって、
前記少なくとも１つのデバイスのいずれか或いは前記少なくとも１つのアプリケーションのいずれかからの通信依頼に基づく接続要求であって、前記通信中継装置と前記少なくとも１つのアプリケーションのうちの一のアプリケーションとの間での個別接続を確立すべき旨の接続要求を受信する通信制御手段と、
前記通信中継装置と前記少なくとも１つのアプリケーションとの間で確立される個別接続の接続数の上限値であってアプリケーションごとの上限値であるアプリケーション別上限値を、前記通信中継装置との間で個別接続を確立しているアプリケーションの個数の現在値に基づいて決定する決定手段と、
を備え、
前記通信制御手段は、
前記通信中継装置と前記一のアプリケーションとの間で現在確立されている個別接続の合計接続数が前記一のアプリケーション向けの前記アプリケーション別上限値よりも小さいことを条件として、前記一のアプリケーションとの間での新たな個別接続を前記接続要求に応じて確立するとともに、
前記通信中継装置との間で現在確立されている個別接続の合計接続数が前記アプリケーション別上限値を超えているアプリケーションである高負荷アプリケーションが存在する場合、前記高負荷アプリケーションと前記通信中継装置との通信のリクエスト間隔を増大することを特徴とする通信中継装置。

【請求項13】

請求項１２に記載の通信中継装置において、
前記決定手段は、前記通信中継装置との個別接続を既に確立しているアプリケーション以外のアプリケーションとの間で更なる個別接続を確立すべき旨の接続要求が受信されると、前記アプリケーション別上限値を低減し、
前記通信制御手段は、前記アプリケーション別上限値の低減に応じて前記高負荷アプリケーションが発生する場合、前記高負荷アプリケーションと前記通信中継装置との通信のリクエスト時間間隔を増大することを特徴とする通信中継装置。

【請求項14】

請求項１２または請求項１３に記載の通信中継装置において、
前記決定手段は、前記通信中継装置において前記少なくとも１つのアプリケーションとの間で確立可能な個別接続の最大数と、前記通信中継装置との個別接続が確立しているアプリケーションの個数の現在値とに基づいて、前記アプリケーション別上限値を決定することを特徴とする通信中継装置。

【請求項15】

請求項１２または請求項１３に記載の通信中継装置において、
前記決定手段は、前記通信中継装置において前記少なくとも１つのアプリケーションとの間で確立可能な個別接続の最大数を、前記通信中継装置との個別接続が現在確立している複数のアプリケーションで分配することによって、前記アプリケーション別上限値を決定することを特徴とする通信中継装置。

【請求項16】

請求項１２または請求項１３に記載の通信中継装置において、
前記決定手段は、前記通信中継装置との間で個別接続を現在確立している複数のアプリケーションのそれぞれに関して、前記複数のアプリケーションと前記通信中継装置との接続履歴情報に基づいて、前記アプリケーション別上限値をアプリケーションごとに決定することを特徴とする通信中継装置。

【請求項17】

請求項１６に記載の通信中継装置において、
前記決定手段は、前記複数のアプリケーションと前記通信中継装置との過去の接続における通信負荷の多寡を示す指標値の比率に基づいて前記通信中継装置の最大接続数を前記複数のアプリケーションに分配することによって、前記アプリケーション別上限値をアプリケーションごとに決定することを特徴とする通信中継装置。

【請求項18】

請求項１２に記載の通信中継装置において、
前記通信制御手段は、前記接続要求が第１の種類の通信依頼と第２の種類の通信依頼とのうちのいずれの種類の通信依頼に基づくものであるかを判定し、
前記第１の種類の通信依頼は、前記少なくとも１つのアプリケーション側から前記少なくとも１つのデバイス側へ向かう向きに発せられる通信依頼であり、
前記第２の種類の通信依頼は、前記少なくとも１つのデバイス側から前記少なくとも１つのアプリケーション側へ向かう向きに発せられる通信依頼であり、
前記決定手段は、前記アプリケーション別上限値を前記第１の種類の通信依頼と前記第２の種類の通信依頼とに分配した種類別上限値をも決定し、
前記通信制御手段は、
前記通信中継装置と前記一のアプリケーションとの間で現在確立されている個別接続の合計接続数のうち、前記接続要求の通信依頼種類と同じ種類である特定種類の通信依頼に基づく個別接続の個数が、前記一のアプリケーション向け且つ前記特定種類の通信依頼向けの前記種類別上限値よりも小さいことを条件として、前記一のアプリケーションとの間での新たな個別接続を前記接続要求に応じて確立することを特徴とする通信中継装置。

【請求項19】

請求項１８に記載の通信中継装置において、
前記通信制御手段は、前記通信中継装置との間で現在確立されている個別接続のうち所定種類の通信依頼に基づく個別接続の合計接続数が前記所定種類の通信依頼に対応する前記種類別上限値を超えているアプリケーションである種類別高負荷アプリケーションが存在する場合、前記種類別高負荷アプリケーションと前記通信中継装置との通信接続であって前記所定種類の通信依頼に対応する通信接続におけるリクエスト時間間隔を増大することを特徴とする通信中継装置。

【請求項20】

請求項１８または請求項１９に記載の通信中継装置において、
前記決定手段は、前記第２の種類の通信依頼向けの前記種類別上限値を、前記第１の種類の通信依頼向けの前記種類別上限値よりも大きな値として決定することを特徴とする通信中継装置。

【請求項21】

請求項１８から請求項２０のいずれかに記載の通信中継装置において、
前記通信制御手段は、前記接続要求が第１の種類の通信依頼と第２の種類の通信依頼とのうちのいずれの種類の通信依頼に基づくものであるかを、前記接続要求の通信プロトコルに基づいて判定することを特徴とする通信中継装置。

【請求項22】

ファイアウォールの内側に設けられる少なくとも１つのデバイスと前記ファイアウォールの外側に設けられる少なくとも１つのクラウドサーバで実行される少なくとも１つのアプリケーションとの間の通信を中継する通信中継装置に内蔵されたコンピュータに、
ａ）前記少なくとも１つのデバイスのいずれか或いは前記少なくとも１つのアプリケーションのいずれかからの通信依頼に基づく接続要求であって、前記通信中継装置と前記少なくとも１つのアプリケーションのうちの一のアプリケーションとの間での個別接続を確立すべき旨の接続要求を受信するステップと、
ｂ）前記通信中継装置と前記少なくとも１つのアプリケーションとの間で確立される個別接続の接続数の上限値であってアプリケーションごとの上限値であるアプリケーション別上限値を、前記通信中継装置との間で個別接続を確立しているアプリケーションの個数の現在値に基づいて決定するステップと、
ｃ）前記通信中継装置と前記一のアプリケーションとの間で現在確立されている個別接続の合計接続数が前記一のアプリケーション向けの前記アプリケーション別上限値よりも小さいことを条件として、前記一のアプリケーションとの間での新たな個別接続を前記接続要求に応じて確立するステップと、
ｄ）前記通信中継装置との間で現在確立されている個別接続の合計接続数が前記アプリケーション別上限値を超えているアプリケーションである高負荷アプリケーションが存在する場合、前記高負荷アプリケーションと前記通信中継装置との通信のリクエスト間隔を増大するステップと、
を実行させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

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

【背景技術】

【0002】

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

【0003】

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

【0004】

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

【先行技術文献】

【特許文献】

【0005】

【特許文献1】特開２０１３−７３５７８号公報

【発明の概要】

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

【0006】

上記のような通信システムにおいては、複数のデバイス（ＭＦＰ等）とクラウドサーバにインストールされたアプリケーション（プログラム）との間においては、秘匿性を確保する等のため、個々に形成された通信接続である個別接続を用いた通信が行われる。当該個別接続としては、ＨＴＴＰ（詳細にはＨＴＴＰＳ）によるトンネル接続等が利用される。

【0007】

ところで、当該通信システムにおいて、処理要求のタイミングが重なった場合等において、短期的且つ急激な通信トラフィックの増加（すなわち突発的な負荷上昇）が発生し得る。

【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】

【図1】通信システムの概略構成を示す図である。

【図2】図１の一部を示す図である。

【図3】ＭＦＰ（デバイス）の構成を示す概略図である。

【図4】各要素の概略構成を示す図である。

【図5】トンネル通信を説明する概念図である。

【図6】トンネル通信を説明する概念図である。

【図7】「アプリトリガ通信依頼」に関する動作を示す図である。

【図8】「デバイストリガ通信依頼」に関する動作を示す図である。

【図9】管理サーバの動作を示すフローチャートである。

【図10】ゲートウエイの動作を示すフローチャートである。

【図11】ゲートウエイの動作を示すフローチャートである。

【図12】管理サーバ内に格納されている情報の一部（各ゲートウエイ３０の負荷状況に関する情報（待機状況情報））を示す図である。

【図13】上限値設定用テーブルを示す図である。

【図14】第２実施形態に係るゲートウエイの動作を示すフローチャートである。

【図15】上限値設定用テーブルを示す図である。

【図16】ゲートウエイと各アプリケーションとのトンネル接続の接続履歴を示す図である。

【図17】接続履歴に関する集計結果を示す図である。

【図18】「デバイストリガ通信依頼」に関する動作（変形例）を示す図である。

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

【0036】

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

【0037】

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

【0038】

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

【0039】

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

【0040】

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

【0041】

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

【0042】

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

【0043】

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

【0044】

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

【0045】

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

【0046】

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

【0047】

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

【0048】

この通信システム１においては、各デバイス１０（ＭＦＰ等）とクラウドサーバ７０にインストールされた各アプリケーション８０との間においては、秘匿性を確保する等のため、個々に形成された通信接続である個別接続を用いた通信が行われる。当該個別接続としては、ＨＴＴＰ（詳細にはＨＴＴＰＳ）によるトンネル接続等が利用される。

【0049】

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

【0050】

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

【0051】

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

【0052】

＜１−２．ＭＦＰの構成概要＞
次に、デバイス１０について説明する。

【0053】

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

【0054】

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

【0055】

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

【0056】

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

【0057】

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

【0058】

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

【0059】

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

【0060】

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

【0061】

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

【0062】

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

【0063】

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

【0064】

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

【0065】

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

【0066】

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

【0067】

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

【0068】

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

【0069】

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

【0070】

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

【0071】

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

【0072】

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

【0073】

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

【0074】

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

【0075】

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

【0076】

決定部４６は、ゲートウエイ３０と各アプリケーション８０との間で確立される個別接続の接続数の上限値であってアプリケーションごとの上限値（アプリケーション別上限値Ｍ（後述））を決定する処理部である。当該アプリケーション別上限値Ｍは、ゲートウエイ３０と各アプリケーション８０との間での個別接続の確立状況に基づいて決定される。

【0077】

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

【0078】

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

【0079】

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

【0080】

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

【0081】

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

【0082】

また、情報管理部６５は、複数のクラウドサーバ７０の情報、および複数のクラウドサーバ７０内の各アプリケーション８０の情報等をも管理する。これらの情報も、管理テーブル６９に格納される。また、情報管理部６５は、各ゲートウエイ３０と各クラウドサーバ７０との間に確立されているトンネル接続の接続数等をも管理テーブル６９等にて管理する。さらに、情報管理部６５は、各ゲートウエイ３０の現在の負荷状況（当該各ゲートウエイ３０における現在の接続待機状況（受信した通信依頼に基づく接続要求の待機状況）等）に関する情報（待機状況情報１１０（図１２）参照）をゲートウエイ３０から取得し、当該情報を管理する。

【0083】

アクセス制御部６７は、待機状況情報１１０（図１２）に基づいて、アプリケーション８０（クラウドサーバ７０）から受信した通信依頼に基づく接続要求等を制御する。たとえば、アクセス制御部６７は、アプリケーション８０（クラウドサーバ７０）から受信した通信依頼に基づく接続要求を、当該接続要求に対応するゲートウエイ３０に直ちに送信するか否かを決定する。

【0084】

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

【0085】

トンネル接続要求としては、たとえば、少なくとも１つのアプリケーション８０のいずれかからの通信依頼に基づく接続要求（管理サーバ５０を経由してゲートウエイ３０へと送信される接続要求等）が存在する。

【0086】

また、トンネル接続要求には、少なくとも１つのデバイス１０のいずれかからの通信依頼に基づく接続要求も存在する。この実施形態では、少なくとも１つのデバイス１０のいずれかからの通信依頼は、後述するように、デバイス１０からゲートウエイ３０に直接的に送信される。

【0087】

これらのトンネル接続要求は、ゲートウエイ３０と少なくとも１つのアプリケーション８０のうちの一のアプリケーションとの間での個別接続を確立すべき旨の接続要求、とも表現される。

【0088】

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

【0089】

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

【0090】

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

【0091】

＜アプリトリガ通信依頼に関する動作（「下向き」の動作）＞
図５および図６は、トンネル通信を説明する概念図である。

【0092】

この実施形態においては、図５および図６に示すような動作（「アプリトリガ通信依頼」に関する動作）において、トンネル通信が利用される。

【0093】

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

【0094】

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

【0095】

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

【0096】

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

【0097】

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

【0098】

管理サーバ５０は、クラウドサーバ７０（アプリケーション８０）からの通信依頼（「アプリトリガ通信依頼」）を受信するなどの動作を実行する（図９参照）。具体的には、管理サーバ５０は、アプリトリガ通信依頼を或るアプリケーション８０から受信すると、待機状況情報１１０（図１２）に基づいて以後の動作を決定する。詳細には、管理サーバ５０は、アプリトリガ通信依頼に基づく接続要求を直ちにゲートウエイ３０に送信する動作と当該接続要求の送信を暫時保留する動作とのいずれを採用するかを決定する（ステップＳ３２，Ｓ３３（図９））。なお、図９の動作については後に詳述する。

【0099】

前者を採用することが決定される場合、管理サーバ５０は、当該トンネル接続要求をゲートウエイ３０に送信する（Ｓ１３（図７））。詳細には、管理サーバ５０は、管理サーバ５０とゲートウエイ３０（３０ａ）との間の当該メッセージセッション（常時接続通信セッション）５１１を利用することにより、アクセス要求に基づくトンネル接続要求（たとえばＸＭＰＰによる接続要求）を当該ゲートウエイ３０ａに送信する。「トンネル接続要求」は、クラウドサーバ７０（アプリケーション８０）との間にトンネル接続を確立すべき旨をゲートウエイ３０に要求する指令である。換言すれば、当該トンネル接続要求は、トンネル接続を用いた通信をゲートウエイ３０に行わせる指令である。

【0100】

当該トンネル接続要求を受信したゲートウエイ３０ａは、図１０のような動作（後述）を実行する。

【0101】

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

【0102】

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

【0103】

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

【0104】

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

【0105】

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

【0106】

なお、アプリトリガ通信依頼は、「クラウドプリント」に関するもののみならず、各種の通信依頼が存在する。たとえば、「プルプリント」（詳細にはプリント対象データの送信動作）に関するもの、デバイス１０の装置状態を把握するための「ステータスポーリング」に関するもの、およびデバイス１０のカウンタ情報を取得するための「カウンタ情報収集サービス」に関するものなどが、アプリトリガ通信依頼として存在する。

【0107】

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

【0108】

具体的には、たとえば「クラウドスキャン」に関するユーザ操作がデバイス１０（たとえば１０ａ）にて行われ、デバイス１０は、クラウドサーバ７０（たとえば７０ｂ）で動作中のアプリケーション８０（たとえば８０ｂ）に対する通信依頼を、ゲートウエイ３０に送信する（Ｓ２１）。当該通信依頼は、ＨＴＴＰ（および／またはＦＴＰ）等の通信プロトコルを用いて、デバイス１０からゲートウエイ３０へと送信される。

【0109】

当該通信依頼は、デバイス１０からの通信依頼であってデバイス１０から（ゲートウエイ３０を介して）アプリケーション８０へ向かう向き（「上向き」）のデータ転送を伴う通信の依頼である。当該通信依頼は、デバイス１０から発せられるもの（デバイス側がトリガになるもの）であり、「デバイストリガ通信依頼」とも称される。ここでは、「デバイストリガ通信依頼」が受信されると、「トンネル接続要求」が受信された旨が判定されるものとする。換言すれば、「デバイストリガ通信依頼」が受信されると、「デバイストリガ通信依頼」に基づくトンネル接続要求もが受信されたものとみなされる。

【0110】

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

【0111】

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

【0112】

なお、デバイストリガ通信依頼は、「クラウドスキャン」に関するもののみならず、各種の通信依頼が存在する。

【0113】

＜１−５．トンネル接続要求に関する制御動作＞
＜管理サーバ５０の動作等＞
図９は、管理サーバ５０の動作を示すフローチャートである。図９を参照しつつ、管理サーバ５０の動作について説明する。

【0114】

管理サーバ５０は、まず、ステップＳ３１において、或るアプリケーション８０からの新規の通信依頼を受信する（図７のステップＳ１２も参照）。

【0115】

つぎに、ステップＳ３２において、管理サーバ５０は、管理テーブル６９を参照して、各ゲートウエイ３０の負荷状況（当該各ゲートウエイ３０における接続待機状況（受信した通信依頼に基づく接続要求の待機状況）等）を知得する。なお、管理テーブル６９には、各ゲートウエイ３０から随時送信されてくる各ゲートウエイ３０の負荷状況が随時格納（随時更新）される。

【0116】

そして、ステップＳ３２においては、ステップＳ３１で受信した新規の接続依頼に関するスケジューリング処理が実行される。具体的には、ステップＳ３１で受信した新規の接続依頼を当該新規接続依頼に対応するゲートウエイ３０に直ちに送信すべきか否か等が判定される。

【0117】

図１２は、管理テーブル６９内に格納されている情報の一部（各ゲートウエイ３０の負荷状況に関する情報（待機状況情報）１１０）を示す図である。図１２に示すように、待機状況情報１１０においては、複数のゲートウエイ３０ａ，３０ｂ，３０ｃ，...のそれぞれの負荷状況が格納されている。また、待機状況情報１１０においては、各ゲートウエイの負荷状況であってアプリケーションごとの負荷状況（ここでは「接続待ちの有無」）が格納されている。換言すれば、各ゲートウエイの負荷状況がアプリケーション別に示されている。

【0118】

図１２においては、ゲートウエイ３０ａとアプリケーション８０ａ（アプリケーションＡ１とも称する）とのトンネル接続は、「ビジー」であり、接続待ちが発生していること（「接続待ち有り」）が示されている。一方、ゲートウエイ３０ａとアプリケーション８０ｂ（アプリケーションＡ２とも称する）とのトンネル接続は、「ビジー」ではなく、接続待ちが発生していないこと（「接続待ち無し」）が示されている。また、ゲートウエイ３０ａとアプリケーション８０ｃ（アプリケーションＡ３とも称する）とのトンネル接続に関しても、「ビジー」ではなく、接続待ちが発生していないこと（「接続待ち無し」）が示されている。

【0119】

新規の接続依頼の送信先のゲートウエイ（対応ゲートウエイ）３０の負荷状況であって新規の接続依頼の送信元のアプリケーション８０との通信の負荷状況が「接続待ち有り」（ビジー）である場合には、管理サーバ５０は、ゲートウエイ３０による当該新規の接続処理が可能ではない旨を判定する。この場合、管理サーバ５０は、当該新規の接続依頼の対応ゲートウエイ３０への送信を保留する。そして、一定期間経過後にステップＳ３２に戻り、再び判定処理が実行される。

【0120】

たとえば、図１２の状況において、ゲートウエイ３０ａに対するアプリケーション８０ａ（アプリケーションＡ１）からの通信依頼が新規に受信される場合（接続待ち有りの場合）、管理サーバ５０は、ゲートウエイ３０ａによる新規の接続処理が可能ではない旨を判定する。そして、管理サーバ５０は、当該新規の接続依頼の対応ゲートウエイ３０ａへの送信を保留する。

【0121】

後述するように、トンネル接続要求への対応動作はゲートウエイ３０によって制御される。特に、特定のアプリケーションとの間の通信負荷が高い場合には、ゲートウエイ３０は当該特定のアプリケーションへのトンネル接続を実行しないことによって、当該特定のアプリケーションとの通信に起因する負荷増大の発生を緩和している。これに加えて、この実施形態では、管理サーバ５０側でも新規のトンネル接続要求の送出の有無が制御される。より詳細には、ゲートウエイ３０と特定アプリケーション８０との間のトンネル接続の接続待ちが発生している場合には、管理サーバ５０は、特定アプリケーション８０に関するトンネル接続要求をゲートウエイ３０に送信しない。これによれば、ゲートウエイ３０の負荷増大を予め回避することが可能である。

【0122】

一方、新規の接続依頼の送信先のゲートウエイ（対応ゲートウエイ）３０の負荷状況であって新規の接続依頼の送信元のアプリケーション８０との通信の負荷状況が「接続待ち無し」（非ビジー）である場合には、管理サーバ５０は、ゲートウエイ３０による新規の接続処理が可能である旨を判定し、ステップＳ３４に進む。ステップＳ３４（ステップＳ１３）においては、管理サーバ５０は、当該新規の接続依頼に対応するゲートウエイ３０（たとえばゲートウエイ３０ａ）へと、当該新規の接続依頼を直ちに送信する（図７のステップＳ１３も参照）。

【0123】

たとえば、図１２の状況において、ゲートウエイ３０ａに対するアプリケーション８０ｂ（アプリケーションＡ２）からの通信依頼が新規に受信される場合（接続待ち無しの場合）、管理サーバ５０は、ゲートウエイ３０ａによる新規の接続処理が可能である旨を判定する。そして、ステップＳ３４（ステップＳ１３（図７参照））において、常時接続のメッセージセッション（ＸＭＰＰ等）を用いて、新規の接続依頼が管理サーバ５０からゲートウエイ３０ａへと送信される。

【0124】

以上のようにして、「アプリトリガ通信依頼」に基づくトンネル接続要求がアプリケーション８０から管理サーバ５０を介してゲートウエイ３０へと送信される（ステップＳ１３（図７参照））。なお、「アプリトリガ通信依頼」に基づくトンネル接続要求は、ＸＭＰＰ等の通信プロトコルを用いて管理サーバ５０からゲートウエイ３０へと送信される。

【0125】

また、上述のように、「デバイストリガ通信依頼」に基づくトンネル接続要求が、デバイス１０からゲートウエイ３０へと直接送信される（ステップＳ２１（図８参照））。なお、「デバイストリガ通信依頼」に基づくトンネル接続要求は、ＨＴＴＰ等の通信プロトコルを用いてデバイス１０からゲートウエイ３０へと送信される。

【0126】

このように、各種の通信依頼等が、アプリケーション８０あるいはデバイス１０から、ゲートウエイ３０へ向けて随時送信される。そして、ゲートウエイ３０は、当該各種の通信依頼に基づくトンネル接続要求を受信する。

【0127】

ゲートウエイ３０は、当該トンネル接続要求を受け付ける（受信する）と、当該トンネル接続要求に基づく個別接続（トンネル接続）の接続動作を制御する（図１０および図１１参照）。図１０および図１１は、ゲートウエイ３０の動作を示すフローチャートである。以下、これらの図を参照しつつ、ゲートウエイ３０の動作について説明する。

【0128】

＜ゲートウエイ３０の動作＞
ゲートウエイ３０は、「アプリトリガ通信依頼」あるいは「デバイストリガ通信依頼」に基づくトンネル接続要求を受信する（ステップＳ５１）と、当該トンネル接続要求が接続確立済みのアプリケーション（サービス）に関するものであるか否かを判定する（ステップＳ５２）。たとえば、ゲートウエイ３０と２つのアプリケーション８０ａ，８０ｂのそれぞれとのトンネル接続要求が既に確立されている場合において、さらに別のアプリケーション８０ｃとのトンネル接続要求が受信されるときには、当該トンネル接続要求は接続確立済みのアプリケーション（８０ａ，８０ｂ）に関するものでない、と判定される。また、同様の場合において、同じアプリケーション８０ａとのトンネル接続要求が受信されるときには、当該トンネル接続要求は接続確立済みのアプリケーション（８０ａ）に関するものであると判定される。

【0129】

当該トンネル接続要求が接続確立済みのアプリケーション（サービス）に関するものであると判定される場合には、ステップＳ５３に進む。一方、当該トンネル接続要求が接続確立済みのアプリケーション以外のアプリケーション（端的に言えば「新たなアプリケーション」）に関するものであると判定される場合にはステップＳ５６に進む。

【0130】

ここで、ステップＳ５３，Ｓ５６での動作の説明に先立って、「アプリケーション別上限値Ｍ」（次述）について説明する。

【0131】

この実施形態では、ゲートウエイ３０（たとえば３０ａ）と１又は複数のアプリケーション８０との間で確立される個別接続の接続数の上限値であってアプリケーションごとの上限値Ｍ（「アプリケーション別上限値」とも称する）が用いられて、個別接続の接続動作が制御される。当該アプリケーション別上限値Ｍは、ゲートウエイ３０（３０ａ）と各アプリケーション８０との間での個別接続（トンネル接続）の確立状況に基づいて決定される。

【0132】

このアプリケーション別上限値Ｍは、ゲートウエイとの個別接続を確立しているアプリケーション（サービス）の個数に応じて変更される。より詳細には、アプリケーション別上限値Ｍは、ゲートウエイ３０の最大処理能力（ゲートウエイ３０において１又は複数のアプリケーションとの間で確立可能な個別接続の最大数Ｘ）と、ゲートウエイ３０との個別接続が確立しているアプリケーションの個数の現在値Ｎとに基づいて決定される。

【0133】

図１３は、上限値設定用テーブル２１０（２１０ａ）を示す図である。図１３においては、ゲートウエイ３０の最大処理能力（ゲートウエイ３０において１又は複数のアプリケーションとの間で確立可能な個別接続の最大数Ｘ）が「３０」である場合が例示されている。

【0134】

図１３の上限値設定用テーブル２１０（２１０ａ）は、接続確立済みのサービスの個数Ｎとアプリケーション別上限値Ｍとの関係を予め規定したデータテーブルである。図１３のような上限値設定用テーブル２１０（２１０ａ）が、ゲートウエイ３０の格納部内に予め格納されているものとする。図１３の左列は、接続確立済みのサービスの個数Ｎ（現在、ゲートウエイ３０との間でトンネル接続を確立しているアプリケーションの個数）を示している。また、右列は、アプリケーション別上限値Ｍを示している。

【0135】

ここでは、アプリケーション別上限値Ｍは、ゲートウエイ３０との個別接続が現在確立している複数のアプリケーションに対して、値Ｘ（ゲートウエイ３０における個別接続の最大数）を分配（詳細には、均等に分配）することによって決定される。

【0136】

より詳細には、アプリケーション別上限値Ｍは、値Ｘを個数Ｎで除した値（小数点以下切り捨て）として算出される（Ｍ＝Ｘ／Ｎ）。たとえば、個数Ｎが１の場合には、アプリケーション別上限値Ｍは「３０」（＝３０／１）であり、個数Ｎが２の場合には、アプリケーション別上限値Ｍは「１５」（＝３０／２）である。同様に、個数Ｎが３の場合には、アプリケーション別上限値Ｍは「１０」（＝３０／３）であり、個数Ｎが４の場合には、アプリケーション別上限値Ｍは「７」（≒３０／４）である。また、個数Ｎが１０の場合には、アプリケーション別上限値Ｍは「３」（＝３０／１０）であり、個数Ｎが１５の場合には、アプリケーション別上限値Ｍは「２」（＝３０／１５）である。さらに、個数Ｎが３０の場合には、アプリケーション別上限値Ｍは「１」（＝３０／３０）である。

【0137】

このように、接続確立済みのアプリケーションの個数Ｎが増大するにつれて、アプリケーション別上限値Ｍは小さくなる。換言すれば、個数Ｎの増大に伴って、１アプリケーションあたりのトンネル接続数の上限値Ｍが徐々に小さくなる。

【0138】

再び図１０を参照する。上述のように、新規のトンネル接続要求が接続確立済みのサービスに関するものであると判定される場合には、ステップＳ５２からステップＳ５３に進む。

【0139】

ステップＳ５３では、（現在の）アプリケーション別上限値Ｍが取得される。具体的には、上限値設定用テーブル２１０（２１０ａ）（図１３）に基づいて、当該アプリケーション別上限値Ｍが決定されて取得される。また、ステップＳ５３では、新規のトンネル接続要求（ステップＳ５１）の対応アプリケーション８０（たとえば８０ａ）に関する接続確立済み（既存）の個別接続（トンネル接続）の個数Ｑもが取得される。そして、ステップＳ５４において、両者Ｑ，Ｍの大小関係が判定される。

【0140】

新規接続要求の対応アプリケーション８０（８０ａ）に関する既存のトンネル接続の個数Ｑが（現在の）アプリケーション別上限値Ｍ以上である場合には、当該アプリケーション８０ａに関する負荷増大を回避すべき旨を判定し、ステップＳ５４からステップＳ５５に進む。ステップＳ５５において、ゲートウエイ３０は、当該対応アプリケーション８０（８０ａ）との間での新たな個別接続を未だ確立しないことを決定し、このトンネル接続要求を待ち行列に投入する。また、ゲートウエイ３０は、待ち行列の最新情報（ゲートウエイ３０の負荷状況）を管理サーバ５０に送信する。より詳細には、ゲートウエイ３０ａとアプリケーション８０ａとの間の個別接続に待ちが発生している旨が、ゲートウエイ３０から管理サーバ５０に送信される。管理サーバ５０は、ゲートウエイ３０から受信した当該最新情報に基づいて、当該ゲートウエイ３０（３０ａ）の負荷状況に関する待機状況情報１１０を更新する。

【0141】

たとえば、ゲートウエイ３０と２つのアプリケーション８０ａ，８０ｂのそれぞれとの間の個別のトンネル接続が確立されている場合には、アプリケーション別上限値Ｍは「１５」である。そして、新規接続要求の対応アプリケーション８０（８０ａ）に関する既存のトンネル接続の個数Ｑが既に「１５」であるときには、１６個目のトンネル接続に関する接続要求は、待ち行列に投入される。このように、特定のアプリケーション８０ａとの間の通信負荷が一定程度以上高いと判定される場合には、ゲートウエイ３０は当該特定のアプリケーションとのトンネル接続を実行しない。これによれば、当該特定のアプリケーション８０ａとの通信に起因する負荷増大の発生を緩和することが可能である。

【0142】

一方、新規接続要求の対応アプリケーション８０（８０ａ）に関する既存のトンネル接続の個数Ｑが現在のアプリケーション別上限値Ｍ未満である場合には、ステップＳ５４からステップＳ６１に進む。ステップＳ６１においては、ゲートウエイ３０は、当該対応アプリケーション８０（８０ａ）との間での新たな個別接続を確立すべき旨を決定する。そして、ゲートウエイ３０は、トンネル接続の確立要求をクラウドサーバ７０ａ（アプリケーション８０ａに対応するクラウドサーバ７０）に送信し、クラウドサーバ７０ａとのトンネル接続を確立する。

【0143】

たとえば、ゲートウエイ３０と２つのアプリケーション８０ａ，８０ｂのそれぞれとの間の個別のトンネル接続が確立されている場合には、アプリケーション別上限値Ｍは「１５」である。そして、新規接続要求の対応アプリケーション８０（８０ａ）に関する既存のトンネル接続の個数Ｑが「１５」未満の値（たとえば「１０」）であるときには、１１１個目のトンネル接続に関する確立要求がクラウドサーバ７０ａに送信される。これにより、クラウドサーバ７０ａ（アプリケーション８０ａ）とのトンネル接続が確立される。

【0144】

ステップＳ５４，Ｓ６１あるいはステップＳ５５の次は、ステップＳ６２（図１１）に進む。ステップＳ６２以降の処理については後述する。

【0145】

再び図１０を参照する。上述のように、ステップＳ５１で受信されたトンネル接続要求が「新たなアプリケーション」（接続確立済みのアプリケーション以外のアプリケーション）に関するものであると判定される場合には、ステップＳ５２からステップＳ５６に進む。

【0146】

ステップＳ５６においては、新たなアプリケーション（サービス）に関するトンネル接続要求が受信されたことに伴って、接続確立済みのアプリケーションの個数Ｎが１つインクリメントされるとともに、アプリケーション別上限値Ｍが更新される。たとえば、個数Ｎが「２」から「３」に増える場合には、アプリケーション別上限値Ｍが「１５」から「１０」に低減される（図１３参照）。なお、新たなアプリケーション（サービス）に関するトンネル接続要求に応じて実際に当該新たなアプリケーションとの間にトンネル接続が確立される時点（接続確立済みのアプリケーションが増加する時点）は、厳密には、後のステップＳ６１の時点（ステップＳ５６の直後の時点）である。ただし、この実施形態では、接続確立済みのアプリケーションがステップＳ５６にて既に増加したものとみなされて、（個数Ｎが１つインクリメントされ）アプリケーション別上限値ＭがステップＳ５６にて更新される。

【0147】

次のステップＳ５７においては、既存のトンネル接続の個数がアプリケーションごとに取得される。換言すれば、アプリケーションごとの既存のトンネル接続（個別接続）の個数Ｑ（アプリケーションごとの既存接続数（あるいは既存セッション数）とも称する）が取得される。

【0148】

そして、ステップＳ５８において、個数Ｍ，Ｑの両者の大小関係が既存アプリケーション（当該ゲートウエイ３０との間にトンネル接続が既に確立されているアプリケーション）ごとに判定される。換言すれば、各既存アプリケーション８０のそれぞれについて、アプリケーションごとの既存接続数Ｑとアプリケーション別上限値Ｍとが比較される。

【0149】

全てのアプリケーションに関して、既存接続数Ｑが更新後のアプリケーション別上限値Ｍ以下である場合には、ステップＳ５８からステップＳ６１に進む。ステップＳ６１においては、上述のような動作が実行される。具体的には、ゲートウエイ３０は、当該対応アプリケーション８０ａとの間での新たな個別接続を確立すべき旨を決定し、トンネル接続の確立要求をクラウドサーバ７０ａに送信し、クラウドサーバ７０ａとのトンネル接続を確立する。

【0150】

たとえば、ゲートウエイ３０（３０ａ）と２つのアプリケーション８０ａ，８０ｂのそれぞれとの間に個別のトンネル接続が確立されている場合において、別のアプリケーション８０ｃに関する新規のトンネル接続要求がステップＳ５１で受信された状況を想定する。また、ゲートウエイ３０とアプリケーション８０ａとの間の個別のトンネル接続の数は「８」であり、ゲートウエイ３０とアプリケーション８０ｂとの間の個別のトンネル接続の数は「７」であるものとする。

【0151】

この状況において、新たなアプリケーション８０ｃからの新規のトンネル接続要求が受信されると、個数Ｎが「２」から「３」に増大され且つアプリケーション別上限値Ｍが「１５」から「１０」へと変更（低減）される（ステップＳ５６）。この場合には、各アプリケーション８０ａ，８０ｂに関する既存の接続数Ｑ「８」，「７」は、更新後のアプリケーション別上限値Ｍ「１０」以下である。そのため、ステップＳ５８からステップＳ６１に進む。この場合、いずれのアプリケーションとの個別接続の個数も未だ上限値に到達しておらず、既存のトンネル接続はそのまま継続しつつアプリケーション８０ｃとのトンネル接続が確立される。

【0152】

一方、少なくとも１つのアプリケーションに関して、既存接続数Ｑが更新後のアプリケーション別上限値Ｍより大きい場合には、ステップＳ５８からステップＳ５９に進む。

【0153】

たとえば、ゲートウエイ３０（３０ａ）と２つのアプリケーション８０ａ，８０ｂのそれぞれとの間の個別のトンネル接続が確立されている場合に、別のアプリケーション８０ｃに関する新規のトンネル接続要求がステップＳ５１で受信された状況を想定する。また、ゲートウエイ３０とアプリケーション８０ａとの間の個別のトンネル接続の数は「１４」であり、ゲートウエイ３０とアプリケーション８０ｂとの間の個別のトンネル接続の数は「７」であるものとする。

【0154】

この状況において、新たなアプリケーション８０ｃからの新規のトンネル接続要求が受信されると、個数Ｎが「２」から「３」に増大され且つアプリケーション別上限値Ｍが「１５」から「１０」へと変更（低減）される。その結果、アプリケーション８０ｂに関する既存の接続数Ｑ「７」は更新後のアプリケーション別上限値Ｍ「１０」より小さい、と判定されるものの、アプリケーション８０ａに関する既存の接続数Ｑ「１４」は更新後のアプリケーション別上限値Ｍ「１０」より大きい、と判定される。そのため、ステップＳ５８からステップＳ５９に進む。なお、この場合には、後のステップＳ６１で（新たな）アプリケーション８０ｃとの新たなトンネル接続が確立されるものの、次のステップＳ５９にて既存のトンネル接続のうちの一のアプリケーション８０ａとのトンネル接続要求に関する負荷が低減される。

【0155】

ステップＳ５９においては、アプリケーション別上限値Ｍより大きな既存接続数Ｑを有するアプリケーション（「高負荷アプリケーション」とも称する）とゲートウエイ３０とのトンネル接続（ＨＴＴＰ通信）におけるＨＴＴＰリクエスト時間間隔が変更（詳細には増大）される。たとえば、直上の例においては、高負荷アプリケーション８０ａに関するトンネル接続のＨＴＴＰリクエスト時間間隔が、変更前の値（たとえばデフォルト値）よりも長い値（長い時間）に変更される。なお、他のアプリケーション８０ｂ，８０ｃに関するトンネル接続のＨＴＴＰリクエスト時間間隔は、変更されない（たとえばデフォルト値のままである）。

【0156】

ここで、ＨＴＴＰリクエスト時間間隔について説明する。ＨＴＴＰ通信では、送信対象データを所定データ量単位（たとえば６４ＫＢごと）に分割し、送信対象データを複数回に分けて通信する。この複数回の通信のそれぞれにおいて通信リクエストが送出される。ステップＳ５９においては、これら複数回の通信の相互間の時間間隔（ＨＴＴＰリクエスト時間間隔）を広げることによって、通信速度の低減（ひいては通信負荷の抑制）が企図される。これによって、ゲートウエイ３０における負荷が抑制される。

【0157】

より詳細には、ステップＳ５９において、ＨＴＴＰリクエスト時間間隔は、アプリケーション別上限値Ｍの変更前後比（後／前）の逆数倍（すなわち、（変更前の値Ｍ）／（変更後の値Ｍ））に増大されればよい。

【0158】

たとえば、アプリケーション別上限値Ｍが「３０」から「１５」に低減された場合には、ＨＴＴＰリクエスト時間間隔はデフォルト値の「２倍」（＝３０／１５）の値に増大されればよい。さらに、アプリケーション別上限値Ｍが「１５」から「１０」に低減された場合には、ＨＴＴＰリクエスト時間間隔はそれまでの値（デフォルト値の「２倍」）の１．５倍（＝１５／１０）の値（すなわち、デフォルト値の３倍）に増大されればよい。これによれば、既存の接続数Ｑ「１４」を有するアプリケーション８０ａとゲートウエイ３０ａとの間のトンネル接続は、更新前の上限値Ｍ「１５」までのトンネル接続時のＨＴＴＰリクエスト時間間隔よりも大きな時間間隔（たとえば、１．５倍）で実行される。したがって、或るアプリケーション８０ａに関する既存の接続数Ｑ「１４」が新たな上限値「１０」を超える場合においても、当該アプリケーション８０ａとゲートウエイ３０との通信負荷が抑制される。その結果、当該アプリケーション８０ａとゲートウエイ３０との通信が他のアプリケーション（８０ｂ，８０ｃ等）とゲートウエイ３０との通信に与える影響を抑制することが可能である。

【0159】

ステップＳ５８あるいはステップＳ５９の次は、ステップＳ６１に進む。ステップＳ６１では、アプリケーション８０ｃに関する新規のトンネル接続要求（ステップＳ５１）に対応して、ゲートウエイ３０とアプリケーション８０ｃとの間のトンネル接続が実際に確立される。そして、当該トンネル接続を利用して、ゲートウエイ３０とアプリケーション８０ｃとのＨＴＴＰ通信が実行される。

【0160】

その後、ステップＳ６２（図１１）に進む。既存のトンネル接続（ＨＴＴＰ接続）のいずれかが終了し当該トンネル接続（ＨＴＴＰ接続）の切断通知をゲートウエイ３０が受領した旨がステップＳ６２にて判定されると、ステップＳ６３に進む。ステップＳ６３では、待機中の接続要求が待ち行列に未だ存在しているか否かが判定される。待機中の接続要求（未処理の接続要求）が待ち行列に存在しない場合には、図１０および図１１の処理は終了する。一方、待機中の接続要求が待ち行列に存在している場合には、ステップＳ５３に戻り、その後、未処理の接続要求に関する処理（ステップＳ６１等）が続行される。

【0161】

以上のような態様によれば、ゲートウエイ３０は、アプリケーション８０ａとの間での新規のトンネル接続要求を受信する場合、或る条件の下、アプリケーション８０ａとの間での新たな個別接続を当該トンネル接続要求に応じて確立する（ステップＳ５４，Ｓ６１参照）。具体的には、当該アプリケーション８０ａと当該ゲートウエイ３０との間で現在確立されている個別接続の合計接続数Ｑがアプリケーション８０ａ向けのアプリケーション別上限値Ｍ未満であることを条件として、当該新たな個別接続を確立する。逆に言えば、当該トンネル接続要求が受信された場合であっても、アプリケーション８０ａに関する当該接続数Ｑがアプリケーション８０ａ向けのアプリケーション別上限値Ｍ以上である場合には、アプリケーション８０ａとの間での新たな個別接続は確立されない（ステップＳ５４，Ｓ５５参照）。したがって、特定のアプリケーション８０ａの利用集中が突発的に発生した場合であっても他のアプリケーション８０ｂ等の利用者に悪影響が及ぶことを回避ないし抑制することが可能である。

【0162】

また、ゲートウエイ３０との間で現在確立されている個別接続の合計接続数Ｑがアプリケーション別上限値Ｍを超えているアプリケーション（高負荷アプリケーション）（たとえば８０ａ）が存在する場合、当該高負荷アプリケーション８０ａとゲートウエイ３０との通信（トンネル接続）におけるリクエスト間隔が増大される。

【0163】

より詳細には、ゲートウエイ３０との個別接続を既に確立しているアプリケーション８０ａ，８０ｂ以外のアプリケーション８０ｃとの間で更なる個別接続を確立すべき旨の接続要求が受信されると、アプリケーション別上限値Ｍが低減される。そして、アプリケーション別上限値Ｍの低減に応じて高負荷アプリケーション（たとえば８０ａ）が発生する場合には、当該高負荷アプリケーション８０ａとゲートウエイ３０との通信のリクエスト間隔が増大される。

【0164】

これによれば、新たに高負荷アプリケーションになったアプリケーション８０ａとのトンネル接続の通信負荷が抑制されるので、特定のアプリケーション８０ａに関する利用が比較的多い場合であっても他のアプリケーション８０ｂ，８０ｃ等の利用者に悪影響が及ぶことを回避ないし抑制することが可能である。

【0165】

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

【0166】

上記第１実施形態においては、アプリケーションごとに既存の接続数（確立済みのトンネル接続数）とアプリケーション別上限値Ｍとが比較され、その比較結果に基づいてトンネル接続に関する動作が制御されている。しかしながら、本発明は、これに限定されない。

【0167】

たとえば、アプリケーションごと且つ通信依頼の方向（換言すれば、種類）（後述）ごとに、既存の接続数（確立済みのトンネル接続数）と方向別上限値（種類別上限値とも称する）Ｍ０（後述）とが比較され、その比較結果に基づいてトンネル接続に関する動作が制御されてもよい。これによれば、各個別接続（トンネル接続）が（「アプリケーション別」のみならず）「方向別」にも分離して制御される。したがって、或るアプリケーションとの個別接続のうち一方の方向（たとえば「下向き」）の個別接続の利用が比較的多いときであっても、他方の方向（たとえば「上向き」）の個別接続あるいは他のアプリケーションとの個別接続に悪影響が及ぶことを回避ないし抑制することが可能である。第２実施形態では、このような態様について説明する。

【0168】

この第２実施形態においても、上述のように、ゲートウエイ３０は、「アプリトリガ通信依頼」あるいは「デバイストリガ通信依頼」に基づくトンネル接続要求を受信する。換言すれば、「下向き」のデータ送信開始依頼と「上向き」のデータ送信開始依頼との少なくとも一方に基づくトンネル接続要求が受信される。

【0169】

また、方向別上限値（種類別上限値）Ｍ０は、アプリケーション別上限値Ｍを「アプリトリガ通信依頼」と「デバイストリガ通信依頼」との２種類の通信依頼（２方向の通信依頼）にそれぞれ分配した方向別（種類別）の上限値である。方向別上限値Ｍ０としては、下向きの通信依頼用の方向別上限値Ｍ０１と上向きの通信依頼用の方向別上限値Ｍ０２とが存在する。

【0170】

この第２実施形態では、ゲートウエイ３０は、次の条件が充足される場合に、或るアプリケーション８０（たとえば８０ａ）との間での新たな個別接続を接続要求に応じて確立する。当該条件は、合計接続数Ｑ０（次述）が当該アプリケーション８０ａ向け且つ特定方向（特定種類）の通信依頼向けの方向別上限値Ｍ０（Ｍ０１あるいはＭ０２）を超えていないこと、である。ここで、合計接続数Ｑ０は、新規依頼に対応するアプリケーション８０（たとえば８０ａ）との間で現在確立されている個別接続の合計接続数Ｑのうち、当該新規依頼に係る接続要求の通信依頼種類と同じ種類（特定種類）の通信依頼（当該接続要求の通信依頼方向と同じ方向（特定方向）の通信依頼）に基づく個別接続の個数（Ｑ０）である。たとえば、アプリケーション８０ａとゲートウエイ３０との間に「アプリトリガ通信依頼」に基づくトンネル接続が「６」個確立されており且つ「デバイストリガ通信依頼」に基づくトンネル接続が「４」個確立されている場合において、さらにアプリケーション８０ａから「アプリトリガ通信依頼」に基づく接続要求（新規依頼に係る接続要求）が受信されるとする。このときには、新規依頼に係る接続要求の通信依頼種類と同じ種類の通信依頼（「アプリトリガ通信依頼」）に基づく個別接続の個数「６」個が、合計接続数Ｑ０として算出される。

【0171】

また、「方向別高負荷アプリケーション」（次述）が存在する場合、ゲートウエイ３０は、当該方向別高負荷アプリケーションとゲートウエイとの通信のリクエスト時間間隔（詳細にはＨＴＴＰリクエスト時間間隔等）を増大する。ここで、「方向別高負荷アプリケーション」（種類別高負荷アプリケーションとも称する）は、当該ゲートウエイ３０との間で現在確立されている個別接続のうち、ステップＳ７１で受信された新規接続要求と同一方向（同一種類）の通信依頼に基づく個別接続の合計接続数が方向別上限値（種類別上限値）Ｍ０を超えているアプリケーションである。

【0172】

＜２−２．各アプリケーションにおける２種類の通信依頼＞
ここにおいて、１つのアプリケーション（サービス）においても、上述の２種類の通信依頼（詳細には、アプリトリガ通信依頼」および「デバイストリガ通信依頼」）が存在し得る。

【0173】

たとえば、プルプリントサービス等に関して、当該２種類の通信依頼が存在し得る。

【0174】

ここにおいて、プルプリントサービスにおいては、まず、印刷依頼元装置を用いてユーザによるプリント指示がなされた後、印刷依頼元装置からサーバ（ここではクラウドサーバ７０）に印刷データが転送され、当該印刷データがサーバ７０の格納部（プルプリント用格納領域）等に一旦蓄積される。

【0175】

その後、今度は印刷出力装置（ここではデバイス１０）の操作入力部等を用いたユーザ認証操作を経て、クラウドサーバ７０から印刷データが取得（プル）され印刷出力装置による印刷出力（プリント）が行われる。より詳細には、まず、デバイス１０でユーザ認証操作が行われた後、印刷対象文書（印刷候補）のリスト（プルプリント対象文書リスト）の送信要求がデバイス１０からクラウドサーバ７０に送信され、当該送信要求に応じて当該リストがクラウドサーバ７０からデバイス１０に送信される。そして、デバイス１０にて当該リストが表示され、当該リストから所望の印刷対象文書がユーザによって選択されると、当該印刷対象文書に関する印刷データがクラウドサーバ７０からデバイス１０へと送信され、当該印刷データに基づく印刷出力（プリント）がデバイス（印刷出力装置）１０によって行われる。

【0176】

このようなプルプリントサービスを提供するアプリケーション８０（たとえば８０ａ）に関しては、上述の２種類の通信依頼（詳細には、アプリトリガ通信依頼」および「デバイストリガ通信依頼」）の双方が存在し得る。具体的には、ログインユーザのプルプリント対象文書リスト（印刷出力候補の文書名情報）の送信要求をデバイス１０からクラウドサーバ７０（アプリケーション８０ａ）へ送信する通信は、「デバイストリガ通信依頼」に基づいて実行される。一方、印刷データをクラウドサーバ７０からデバイス１０へと送信する処理は、アプリケーション８０ａからデバイス１０へと向かう向きの「アプリトリガ通信依頼」に基づいて実行される。

【0177】

他のアプリケーションにおいても同様であり、各アプリケーション（サービス）において、上述の２種類の通信依頼（詳細には、アプリトリガ通信依頼」および「デバイストリガ通信依頼」）が存在し得る。

【0178】

＜２−３．方向別上限値（種類別上限値）Ｍ０＞
この第２実施形態では、方向別上限値（種類別上限値）Ｍ０が利用される。方向別上限値Ｍ０は、上述のアプリケーション別上限値Ｍを「アプリトリガ通信依頼」と「デバイストリガ通信依頼」との２種類の通信依頼に対してそれぞれ分配した方向別の上限値である。方向別上限値Ｍ０としては、下向きの通信依頼用の方向別上限値Ｍ０１と上向きの通信依頼用の方向別上限値Ｍ０２とが存在する。

【0179】

図１５は、第２実施形態に係る上限値設定用テーブル２１０（２１０ｂ）を示す図である。図１５においては、方向別上限値Ｍ０の一例が示されている。第２実施形態では、図１５のような上限値設定用テーブル２１０（２１０ｂ）が、ゲートウエイ３０の格納部内に予め格納されているものとする。

【0180】

図１５の最左列は、接続確立済みのサービスの個数Ｎ（現在、ゲートウエイ３０との間でトンネル接続を確立しているアプリケーションの個数）を示している。また、その右隣の列（図１５の最左列から２番目の列）は、アプリケーション別上限値Ｍを示している。図１３と比較すると判るように、図１５の最左列は図１３の左列と同じであり、図１５の最左列から２番目の列は図１３の右列と同じである。なお、図１５においても、ゲートウエイ３０の最大処理能力（ゲートウエイ３０において１又は複数のアプリケーションとの間で確立可能な個別接続の最大数Ｘ）が「３０」である場合が例示されている。

【0181】

図１５の右側２列に示されるように、アプリケーション別上限値Ｍは、「アプリトリガ通信依頼」に基づくトンネル接続要求の上限値（「下向き」通信の上限値とも称する）Ｍ０１と「デバイストリガ通信依頼」に基づくトンネル接続要求の上限値（「上向き」通信の上限値とも称する）Ｍ０２とに分配される。ここでは、接続アプリケーション（サービス）の個数Ｎに応じた各アプリケーション別上限値Ｍが、下向き通信の上限値Ｍ０１と上向き通信の上限値Ｍ０２とに対して、それぞれ、所定の割合（約１：２）で分配される。

【0182】

たとえば、個数Ｎが「１」の場合には、そのアプリケーション別上限値Ｍ「３０」が下向き通信の上限値Ｍ０１「１０」と上向き通信の上限値Ｍ０２「２０」とに分配される。

【0183】

同様に、個数Ｎが「２」の場合には、そのアプリケーション別上限値Ｍ「１５」が下向き通信の上限値Ｍ０１「５」と上向き通信の上限値Ｍ０２「１０」とに分配される。

【0184】

また、個数Ｎが「３」の場合には、そのアプリケーション別上限値Ｍ「１０」が下向き通信の上限値Ｍ０１「３」と上向き通信の上限値Ｍ０２「７」とに分配される。

【0185】

同様にして、その他の各個数Ｎに対応するアプリケーション別上限値Ｍも所定の割合（ここでは、約１：２）で２種類の上限値Ｍ０１，Ｍ０２に分配される。

【0186】

なお、個数Ｎが「３０」の場合には、そのアプリケーション別上限値Ｍ「１」であり、仮に完全に分配すると一方の方向の方向別上限値Ｍ０（たとえば、Ｍ０１）が「０」になってしまい、当該一方の方向のトンネル接続の確立に不都合が生じる。そこで、例外的に、下向き通信の上限値Ｍ０１と上向き通信の上限値Ｍ０２との双方を「１」に設定している。

【0187】

＜２−４．詳細動作＞
次に、第２実施形態に係るゲートウエイ３０の動作について図１４等を参照しながら、さらに詳細に説明する。

【0188】

図１４のステップＳ７１〜Ｓ７９においては、図１０のステップＳ５１〜Ｓ５９とそれぞれ同様の処理が行われる。ただし、上述のように、この第２実施形態に係るステップＳ７１〜Ｓ７９では、各トンネル接続要求が「アプリトリガ通信依頼」と「デバイストリガ通信依頼」とのいずれに基づくものであるか等を考慮して各動作が制御される点で第１実施形態に係るステップＳ５１〜Ｓ５９と相違する。

【0189】

ステップＳ７１において、ゲートウエイ３０は、「アプリトリガ通信依頼」あるいは「デバイストリガ通信依頼」に基づくトンネル接続要求を受信すると、当該トンネル接続要求が何れの方向に係るものかを判定する。すなわち、「アプリトリガ通信依頼」（下向きの通信依頼）に基づくトンネル接続要求と、「デバイストリガ通信依頼」（上向きの通信依頼）に基づくトンネル接続要求とのいずれが受信されたかが判定される。

【0190】

具体的には、当該トンネル接続要求の通信プロトコルに基づいて、いずれの方向（向き）の通信依頼に基づくトンネル接続要求が受信されたか判定される。より詳細には、ＸＭＰＰ等のプロトコル（常時接続のメッセージセッションのプロトコル）を用いて受信されたトンネル接続要求は、「アプリトリガ通信依頼」（下向きの通信依頼）に基づくトンネル接続要求であると判定される。一方、ＨＴＴＰ（および／またはＦＴＰ）等のプロトコル（非常時接続のメッセージセッションのプロトコル）を用いて受信されたトンネル接続要求は、「デバイストリガ通信依頼」（上向きの通信依頼）に基づくトンネル接続要求であると判定される。

【0191】

ステップＳ７２においては、当該トンネル接続要求が接続確立済みのサービス（アプリケーション）に関するものであるか否かが判定される。

【0192】

当該トンネル接続要求が接続確立済みのアプリケーション（サービス）に関するものであると判定される場合には、ステップＳ７３に進む。一方、当該トンネル接続要求が接続確立済みのアプリケーション以外のアプリケーション（端的に言えば「新たなアプリケーション」）に関するものであると判定される場合にはステップＳ７６に進む。

【0193】

ステップＳ７３では、現在の方向別限値Ｍ０が取得される。具体的には、上限値設定用テーブル２１０（２１０ｂ）（図１５）に基づいて、方向別上限値Ｍ０が決定されて取得される。たとえば、接続サービスの個数Ｎが「１」である場合には、アプリケーション別上限値Ｍが「３０」であり、下向きの方向別上限値Ｍ０１は「１０」であり、上向きの方向別上限値Ｍ０２は「２０」である。

【0194】

また、ステップＳ７３では、ゲートウエイ３０と新規のトンネル接続要求（ステップＳ７１）の対応アプリケーション８０（たとえば８０ａ）との間で現在確立されているトンネル接続要求（個別接続）のうち、ステップＳ７１で受信された通信依頼と同一種類（同一方向）の通信依頼に基づく個別接続の合計接続数Ｑ０もが取得される。

【0195】

そして、ステップＳ７４において、当該個数Ｍ０（Ｍ０１あるいはＭ０２）と個数Ｑ０との大小関係が判定される。

【0196】

合計接続数Ｑ０が方向別上限値Ｍ０（ステップＳ７１での接続要求に対応するアプリケーション向け且つ当該接続要求と同一種類の通信依頼に基づく接続要求向けの上限値）（たとえば、Ｍ０１）以上である場合には、ステップＳ７４からステップＳ７５に進む。ステップＳ７５において、ゲートウエイ３０は、当該対応アプリケーション８０（８０ａ）との間での新たな個別接続を未だ確立しないことを決定し、このトンネル接続要求を待ち行列に投入する。また、ゲートウエイ３０は、待ち行列の最新情報（ゲートウエイ３０の負荷状況）を管理サーバ５０に送信する。より詳細には、ゲートウエイ３０ａとアプリケーション８０ａとの間の個別接続に待ちが発生している旨が、ゲートウエイ３０から管理サーバ５０に送信される。管理サーバ５０は、ゲートウエイ３０から受信した当該最新情報に基づいて、当該ゲートウエイ３０（３０ａ）の負荷状況に関する待機状況情報１１０を更新する。

【0197】

たとえば、ゲートウエイ３０と２つのアプリケーション８０ａ，８０ｂのそれぞれとの間の個別のトンネル接続が確立されている場合には、アプリケーション別上限値Ｍは「１５」である。また、下向きの方向別上限値Ｍ０１は「１０」である。そして、新規接続要求が「下向き」の接続要求であり、且つ、当該新規接続要求の対応アプリケーション８０（８０ａ）に関する既存のトンネル接続の個数Ｑのうち「下向き」の合計接続数Ｑ０が既に「１０」に到達しているときには、１１個目の「下向き」の接続要求は、待ち行列に投入される。

【0198】

一方、合計接続数Ｑ０が当該方向別上限値Ｍ０（たとえば、Ｍ０１）未満である場合には、ステップＳ７４からステップＳ６１に進む。ステップＳ６１においては、ゲートウエイ３０は、当該対応アプリケーション８０（８０ａ）との間での新たな個別接続を確立すべき旨を決定する。そして、ゲートウエイ３０は、トンネル接続の確立要求をクラウドサーバ７０ａ（アプリケーション８０ａに対応するクラウドサーバ７０）に送信し、クラウドサーバ７０ａとのトンネル接続を確立する。

【0199】

たとえば、ゲートウエイ３０と２つのアプリケーション８０ａ，８０ｂのそれぞれとの間の個別のトンネル接続が確立されている場合には、アプリケーション別上限値Ｍは「１５」である。また、下向きの方向別上限値Ｍ０１は「１０」である。そして、新規接続要求が「下向き」の接続要求であり、且つ、新規接続要求の対応アプリケーション８０（８０ａ）に関する既存のトンネル接続の個数Ｑのうち「下向き」の合計接続数Ｑ０が「１０」未満の値（たとえば、「５」）であるときには、ステップＳ６１に進む。ステップＳ６１では、６個目の「下向き」の接続要求に対応して、当該６個目のトンネル接続に関する確立要求がクラウドサーバ７０ａに送信される。これにより、クラウドサーバ７０ａ（アプリケーション８０ａ）とのトンネル接続が確立される。

【0200】

このようにして、方向別の合計接続数Ｑ０が方向別上限値Ｍ０（ステップＳ７１での接続要求に対応するアプリケーション向け且つ当該接続要求と同一種類の通信依頼に基づく接続要求向けの上限値）（たとえば、Ｍ０１）よりも小さいことを条件として、当該アプリケーションとの間での新たな個別接続が接続要求に応じて確立される。

【0201】

ステップＳ７４，Ｓ６１あるいはステップＳ７５の次は、ステップＳ６２（図１１）に進む。

【0202】

再び図１４を参照する。上述のように、トンネル接続要求が接続確立済みのアプリケーション以外のアプリケーション（端的に言えば「新たなアプリケーション」）に関するものであると判定される場合には、ステップＳ７２からステップＳ７６に進む。

【0203】

ステップＳ７６においては、ステップＳ５６と同様に、接続確立済みのアプリケーションの個数Ｎが１つインクリメントされるとともに、アプリケーション別上限値Ｍが更新される。たとえば、個数Ｎが「２」から「３」に増える場合には、アプリケーション別上限値Ｍが「１５」から「１０」に低減される。また、これに伴って、下向きの方向別上限値Ｍ０（Ｍ０１）が「５」から「３」に低減され且つ上向きの方向別上限値Ｍ０（Ｍ０２）が「１０」から「７」に低減される。

【0204】

また、ステップＳ７７において、既存のトンネル接続の個数がアプリケーションごとに取得される。換言すれば、アプリケーションごとの既存のトンネル接続（個別接続）の個数Ｑ（アプリケーションごとの既存接続数Ｑとも称する）が取得される。特に、このステップＳ７７では、アプリケーションごと且つ方向別の既存接続数Ｑ０が取得される。具体的には、「下向き」の既存接続数Ｑ０１と「上向き」の既存接続数Ｑ０２とが、アプリケーションごとに取得される。

【0205】

そして、ステップＳ７８において、両者Ｍ０，Ｑ０の大小関係が既存アプリケーション（当該ゲートウエイ３０との間にトンネル接続が既に確立されているアプリケーション）ごとに且つ通信依頼の方向ごとに判定される。

【0206】

具体的には、各既存アプリケーション８０のそれぞれについて、アプリケーションごと且つ方向別の既存接続数Ｑ０と方向別上限値Ｍ０とが比較される。

【0207】

詳細には、まず、各既存アプリケーション８０のそれぞれについて、アプリケーションごと且つ「下向き」の既存接続数Ｑ０１と「下向き」向けの上限値Ｍ０１とが比較される。さらに、各既存アプリケーション８０のそれぞれについて、アプリケーションごと且つ「上向き」の既存接続数Ｑ０２と「上向き」向けの上限値Ｍ０２とが比較される。

【0208】

全てのアプリケーションについて（より詳細には「両方向」について）、アプリケーションごと且つ方向別の既存接続数Ｑ０が更新後の方向別上限値Ｍ０未満である場合には、ステップＳ７８からステップＳ６１に進む。ステップＳ６１においては、上述のような動作が実行される。具体的には、ゲートウエイ３０は、当該対応アプリケーション８０ａとの間での新たな個別接続を確立すべき旨を決定し、トンネル接続の確立要求をクラウドサーバ７０ａに送信し、クラウドサーバ７０ａとのトンネル接続を確立する。

【0209】

たとえば、ゲートウエイ３０（３０ａ）と２つのアプリケーション８０ａ，８０ｂのそれぞれとの間に個別のトンネル接続が確立されている場合において、別のアプリケーション８０ｃに関する新規のトンネル接続要求がステップＳ７１で受信された状況を想定する。また、ゲートウエイ３０とアプリケーション８０ａとの間の個別のトンネル接続のうち、「下向き」の接続数は「３」であり且つ「上向き」の接続数は「５」であるものとする。さらに、ゲートウエイ３０とアプリケーション８０ｂとの間の個別のトンネル接続のうち、「下向き」の接続数は「２」であり且つ「上向き」の接続数は「５」であるものとする。

【0210】

この状況において、新たなアプリケーション８０ｃからの新規のトンネル接続要求が受信されると、個数Ｎが「２」から「３」に増大され且つアプリケーション別上限値Ｍが「１５」から「１０」へと変更（低減）される（ステップＳ７６）。また、方向別上限値Ｍ０もそれぞれ変更される。具体的には、「下向き」向けの上限値Ｍ０１は「５」から「３」に低減され、「上向き」向けの上限値Ｍ０２は「１０」から「７」に低減される。

【0211】

この場合には、各アプリケーション８０ａ，８０ｂに関する「下向き」の方向別の各既存接続数Ｑ０１「３」，「２」は、いずれも、更新後の「下向き」向けの上限値Ｍ０１「３」以下である。また、各アプリケーション８０ａ，８０ｂに関する「上向き」の方向別の各既存接続数Ｑ０２「５」，「５」は、いずれも、更新後の「上向き」向けの上限値Ｍ０２「７」以下である。そのため、ステップＳ７８からステップＳ６１に進む。

【0212】

一方、少なくとも１つのアプリケーションについて（より詳細には少なくとも一方の「方向」について）、方向別の既存接続数Ｑ０が更新後の方向別上限値Ｍ０以上である場合には、ステップＳ７８からステップＳ７９に進む。

【0213】

たとえば、ゲートウエイ３０（３０ａ）と２つのアプリケーション８０ａ，８０ｂのそれぞれとの間に個別のトンネル接続が確立されている場合において、別のアプリケーション８０ｃに関する新規のトンネル接続要求がステップＳ７１で受信された状況を想定する。また、ゲートウエイ３０とアプリケーション８０ａとの間の個別のトンネル接続のうち、「下向き」の接続数Ｑ０１は「５」であり且つ「上向き」の接続数Ｑ０２は「７」であるものとする。さらに、ゲートウエイ３０とアプリケーション８０ｂとの間の個別のトンネル接続のうち、「下向き」の接続数Ｑ０１は「２」であり且つ「上向き」の接続数Ｑ０２は「５」であるものとする。

【0214】

この状況において、新たなアプリケーション８０ｃからの新規のトンネル接続要求が受信されると、個数Ｎが「２」から「３」に増大され且つアプリケーション別上限値Ｍが「１５」から「１０」へと変更（低減）される（ステップＳ７６）。また、方向別上限値Ｍ０もそれぞれ変更される。具体的には、「下向き」向けの上限値Ｍ０１は「５」から「３」に低減され、「上向き」向けの上限値Ｍ０２は「１０」から「７」に低減される。

【0215】

この場合、アプリケーション８０ａに関する「下向き」の（方向別の）各既存接続数Ｑ０１「５」は、更新後の「下向き」向けの上限値Ｍ０１「３」より大きい、と判定される。換言すれば、ゲートウエイ３０との間で現在確立されている個別接続のうち所定種類の通信依頼（たとえば、「下向き」の通信依頼）に基づく個別接続の合計接続数Ｑ０が当該所定種類の通信依頼に対応する方向別上限値Ｍ０を超えているアプリケーション（「方向別高負荷アプリケーション」）（たとえば、８０ａ）が存在する旨が判定される。なお、「方向別高負荷アプリケーション」は、「種類別高負荷アプリケーション」とも称される。

【0216】

このような判定の結果、ステップＳ７８からステップＳ７９に進む。

【0217】

ステップＳ７９においては、ゲートウエイ３０は、「方向別高負荷アプリケーション（８０ａ）」とゲートウエイ３０との通信接続であって所定種類の通信依頼に対応する通信接続におけるリクエスト時間間隔を増大する。たとえば、直上の例においては、高負荷アプリケーション８０ａに関する「下向き」のトンネル接続のＨＴＴＰリクエスト時間間隔が、変更前の値（たとえばデフォルト値）よりも長い値（長い時間）に変更される。当該ＨＴＴＰリクエスト時間間隔は、たとえば方向別上限値Ｍ０の変更前後比（後／前）の逆数倍（すなわち、（変更前の値Ｍ０）／（変更後の値Ｍ０））に増大されればよい。

【0218】

なお、アプリケーション８０ａに関する「上向き」の方向別の各既存接続数Ｑ０２「７」は、更新後の「上向き」向けの上限値Ｍ０２「５」以下である、と判定される。そのため、アプリケーション８０ａに関する「上向き」のトンネル接続のＨＴＴＰリクエスト時間間隔は、変更されない。また、アプリケーション８０ｂに関する「下向き」の方向別の各既存接続数Ｑ０１「２」は、更新後の「下向き」向けの上限値Ｍ０１「３」以下である、と判定されるとともに、アプリケーション８０ｂに関する「上向き」の方向別の各既存接続数Ｑ０２「５」は、更新後の「上向き」向けの上限値Ｍ０２「７」以下である、と判定される。そのため、アプリケーション８０ｂに関するトンネル接続のＨＴＴＰリクエスト時間間隔は、いずれの方向に関しても変更されない。さらに、他のアプリケーション８０ｃに関するトンネル接続のＨＴＴＰリクエスト時間間隔も変更されない。

【0219】

このようにして、所定方向に関して方向別上限値Ｍ０よりも大きな既存接続数Ｑ０を有する方向別高負荷アプリケーションが発生する場合、当該方向別高負荷アプリケーションとゲートウエイ３０との通信（トンネル接続）であって当該所定方向の通信依頼に対応する通信におけるリクエスト時間間隔が増大される。

【0220】

ステップＳ７８あるいはステップＳ７９の次は、ステップＳ６１に進む。ステップＳ６１では、アプリケーション８０ｃに関する新規のトンネル接続要求（ステップＳ７１）に対応して、ゲートウエイ３０とアプリケーション８０ｃとの間のトンネル接続が確立される。そして、当該トンネル接続を利用して、ゲートウエイ３０とアプリケーション８０ｃとのＨＴＴＰ通信が実行される。

【0221】

ステップＳ６２以降の処理は第１実施形態と同様である。

【0222】

以上のような態様においては、ゲートウエイ３０は、アプリケーション８０ａとの間での新規のトンネル接続要求を受信する場合、或る条件の下、アプリケーション８０ａとの間での新たな個別接続を当該トンネル接続要求に応じて確立する（ステップＳ７４，Ｓ６１参照）。具体的には、当該アプリケーション８０ａと当該ゲートウエイ３０との間で現在確立されている個別接続のうち、新規のトンネル接続要求の通信依頼種類と同じ種類である特定種類（特定方向）の通信依頼に基づくトンネル接続の合計接続数Ｑ０が、当該アプリケーション８０ａ向け且つ当該特定種類の通信依頼向けの方向別上限値（種類別上限値）Ｍ０よりも小さいことを条件として、当該新たな個別接続が確立される。逆に言えば、アプリケーション８０ａとの間のトンネル接続であって新規のトンネル接続要求と同じ種類（特定種類）の通信依頼に基づくトンネル接続の既存接続数Ｑ０が当該アプリケーション８０ａ向けの当該特定種類（特定方向）の方向別上限値Ｍ０以上である場合には、トンネル接続要求が受信されたときでも、アプリケーション８０ａとの間での新たなトンネル接続要求は確立されない（ステップＳ７４，Ｓ７５参照）。

【0223】

したがって、特定のアプリケーション８０ａの利用集中（特に、特定方向の通信依頼に関する利用集中）が突発的に発生した場合であっても他のアプリケーション８０ｂ等の利用者に悪影響が及ぶことを回避ないし抑制することが可能である。また、特定のアプリケーション８０ａとの特定方向のトンネル接続に関する利用集中が突発的に発生した場合であっても、当該特定方向以外の方向のトンネル接続（異なるトリガー種類のトンネル接続）に関する利用に悪影響が及ぶことを回避ないし抑制することが可能である。

【0224】

また、上述の「方向別高負荷アプリケーション」（たとえば８０ａ）が存在する場合、当該高負荷アプリケーション８０ａとゲートウエイ３０とのトンネル接続（通信）におけるリクエスト間隔が増大される。より詳細には、ゲートウエイ３０との個別接続を既に確立しているアプリケーション８０ａ，８０ｂとは別のアプリケーション８０ｃとの間で更なる個別接続を確立すべき旨の接続要求が受信されると、方向別上限値Ｍ０が低減される。そして、方向別上限値Ｍ０の低減に応じて、特定方向に関する方向別高負荷アプリケーション（たとえば８０ａ）が発生する場合、特定の通信接続におけるリクエスト時間間隔が増大される。ここで、当該特定の通信接続は、当該方向別高負荷アプリケーション８０ａとゲートウエイ３０との通信接続であって、当該特定方向の通信依頼に対応する通信接続である。

【0225】

これによれば、新たに方向別高負荷アプリケーションになったアプリケーション８０ａとのトンネル接続の当該特定方向の通信負荷が抑制される。したがって、特定のアプリケーション８０ａ（より詳細には、特定方向の通信依頼に基づくトンネル接続要求）に関する利用が比較的多い場合であっても他のアプリケーション８０ｂ，８０ｃ等の利用者に悪影響が及ぶことを回避ないし抑制することが可能である。また、特定のアプリケーション８０ａとの通信のうち所定方向以外の通信に影響が及ぶことを回避することが可能である。たとえば、ＨＴＴＰリクエスト間隔が「下向き」の通信のみに関して変更される場合には、「上向き」の通信（デバイストリガ通信）に影響が及ぶことを回避ないし抑制することが可能である。

【0226】

また、上記ステップＳ７６においては、図１５の上限値設定用テーブル２１０ｂに従って方向別上限値Ｍ０が決定される。具体的には、２方向（２種類）の通信依頼のうち、「上向き」の通信依頼（「デバイストリガ通信依頼」）向けの方向別上限値Ｍ０２が、「下向き」の通信依頼（「アプリトリガ通信依頼」）向けの方向別上限値Ｍ０１よりも大きな値として決定される。

【0227】

一般に、デバイストリガ通信依頼に基づくトンネル接続を用いた通信の方が、アプリトリガ通信依頼に基づくトンネル接続を用いた通信よりも、即時性を求められることが多い。たとえば、上述のプルプリント処理においては、ログインユーザのプルプリント対象文書リスト（印刷出力候補の文書名情報）の送信が、「デバイストリガ通信依頼」に基づくトンネル接続を用いて実行される。当該プルプリント対象文書リストに基づく画面表示は、特に即応性（ユーザ操作に対して素早く反応して表示されること）が求めれられることが多い。

【0228】

これに対して、上記実施形態においては、デバイストリガ通信依頼に基づくトンネル接続に関する方向別上限値Ｍ０２が、アプリトリガ通信依頼に基づくトンネル接続に関する方向別上限値Ｍ０１よりも大きな値に設定されている。そのため、デバイストリガ通信依頼に基づくトンネル接続の既存接続数Ｑ０は、デバイストリガ通信依頼に対応する更新後の方向別上限値Ｍ０２を超え難くなり、ステップＳ７８からステップＳ７９に進み難くなる。すなわち、デバイストリガ通信依頼（「上向き」の通信依頼）に基づくトンネル接続のＨＴＴＰリクエスト間隔が低減され難くなるので、上述の即時性（即応性）を比較的確保し易い。

【0229】

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

【0230】

たとえば、上記各実施形態においては、アプリケーション別上限値Ｍは各アプリケーションに対して同じ値であるが、これに限定されず、アプリケーション別上限値Ｍはアプリケーションごとに異なる値であってもよい。

【0231】

また、上記各実施形態においては、アプリケーション別上限値Ｍは、上限値設定用テーブル２１０に予め規定された値（固定値）に基づいて決定されているが、これに限定されず、アプリケーション別上限値Ｍは、他の情報（接続履歴等）に基づいて決定されるようにしてもよい。

【0232】

具体的には、ゲートウエイ３０と各アプリケーション８０との接続履歴に基づいて、アプリケーション別上限値Ｍが決定されてもよい。より具体的には、ゲートウエイ３０との間で個別接続を現在確立している複数のアプリケーション８０（たとえば、２つのアプリケーション８０ａ，８０ｂ）に関して、当該複数のアプリケーションとゲートウエイとの過去の接続情報（接続履歴）に基づいて、アプリケーション別上限値がアプリケーションごとに決定されてもよい。

【0233】

図１６は、ゲートウエイ３０と各アプリケーション８０とのトンネル接続の接続履歴（通信履歴）に関する情報（接続履歴情報）３１０を示す図である。

【0234】

図１６に示すように、ゲートウエイ３０におけるトンネル接続の接続履歴は、「通信先アプリケーション（サービス）」、「接続開始時刻」、「接続終了時刻」、「１接続におけるデータ通信量」等の各情報を含む。

【0235】

ゲートウエイ３０は、これらの接続履歴に関する情報（接続履歴情報）３１０をゲートウエイ３０の格納部に格納しておく。なお、当該接続履歴情報３１０は、随時更新される。

【0236】

ゲートウエイ３０は、上述のステップＳ５６（図１０参照）等でアプリケーション別上限値Ｍを決定する際に、アプリケーションごとの各種情報（「単位期間当たりの接続数」および「単位期間当たりのデータ通信量」等）を取得する（図１７参照）。なお、これらの情報（「単位期間当たりの接続数」および「単位期間当たりのデータ通信量」等）は、ゲートウエイ３０と各アプリケーション８０との過去の接続における通信負荷の多寡を示す指標値であるとも表現される。また、これらの情報は、当該接続履歴情報に基づく情報であり、当該接続履歴情報の集計結果として取得される。

【0237】

図１７は、接続履歴情報３１０を集計した集計結果３２０を示す図である。図１７においては、所定期間（単位期間）内（たとえば、１日）のトンネル接続の接続数がアプリケーションごとに集計されている。

【0238】

そして、ゲートウエイ３０は、たとえば「単位期間当たりの接続数」に基づいて、各アプリケーション別上限値Ｍをアプリケーションごとに決定する。

【0239】

２つのアプリケーションに関するトンネル接続が確立されている場合、上述の実施形態では２つのアプリケーションのそれぞれに対して常に同じ値「１５」がアプリケーション別上限値Ｍ（同じ値）として割り当てられる。これに対して、この変型例では、当該２つのアプリケーションのそれぞれに対して互いに異なる値がアプリケーション別上限値Ｍとして割り当てられ得る。特に、各アプリケーション向けの各アプリケーション別上限値Ｍは、当該各アプリケーションの接続履歴（過去の稼働状況）を反映して設定される。

【0240】

より詳細には、単位期間あたりの接続数が少ないアプリケーション（サービス）に対しては、比較的小さな値がアプリケーション別上限値Ｍとして割り当てられる。逆に、単位期間あたりの接続数が多いアプリケーション（サービス）に対しては、比較的大きな値がアプリケーション別上限値Ｍとして割り当てられる。換言すれば、各アプリケーションに関する過去の通信負荷を考慮して、アプリケーション別上限値Ｍがアプリケーションごとに決定される。

【0241】

たとえば、ゲートウエイ３０の能力に基づく上述の最大接続数Ｘ（たとえば、「３０」）が、当該２つのアプリケーションの「単位期間当たりの接続数」の比率に応じて当該２つのアプリケーションに分配されればよい。より詳細には、一方のアプリケーション８０ａの「単位期間当たりの接続数」が「１００」であり且つ他方のアプリケーション８０ｂの「単位期間当たりの接続数」が「２００」であるときには、アプリケーション８０ａのアプリケーション別上限値Ｍが「１０」に決定され且つアプリケーション８０ｂのアプリケーション別上限値Ｍが「２０」に決定されればよい。

【0242】

あるいは、最大数Ｘが各アプリケーションの「単位期間当たりのデータ通信量」の比率に応じて分配されて、各アプリケーション別上限値Ｍが決定されてもよい。たとえば、一方のアプリケーション８０ａの「データ通信量」が他方のアプリケーション８０ｂの「データ通信量」の２倍であるときには、アプリケーション８０ａのアプリケーション別上限値Ｍが「２０」に決定され且つアプリケーション８０ｂのアプリケーション別上限値Ｍが「１０」に決定されればよい。

【0243】

これによれば、各アプリケーションの実際の接続履歴に基づいて各アプリケーションの利用頻度等が取得され、当該利用頻度等に応じてアプリケーション別上限値Ｍが適切に設定される。したがって、ゲートウエイ３０のリソースが複数のアプリケーションの相互間で適切に分配される。より詳細には、実際の利用頻度が比較的低いアプリケーション（たとえば、カウンタ情報収集サービス、装置情報取得サービス（ステータスポーリングサービス）等）に対しては、比較的小さな値がアプリケーション別上限値Ｍとして割り当てられる。一方、実際の利用頻度が比較的高いアプリケーション（たとえば、クラウドプリントサービス等）に対しては、比較的大きな値がアプリケーション別上限値Ｍとして割り当てられるので、接続数がアプリケーション別上限値Ｍに到達し難くなる。

【0244】

なお、各アプリケーションの利用頻度は、顧客企業等によって異なることも多い。上記のような変形例によれば、各顧客企業における実際の利用頻度が反映されるので、非常に好適である。

【0245】

また、アプリケーション別上限値Ｍが２種類の種類別上限値Ｍ０１，Ｍ０２に分配される際にも、同様の思想が適用されてもよい。具体的には、接続履歴情報３１０に基づいて所定期間（単位期間）内のトンネル接続の接続数がアプリケーションごとに集計される（図１７参照）とともに、さらに各アプリケーションごとの「単位時間あたりの接続数」が方向別（種類別）に分離して集計されればよい。このような集計に基づいて、各アプリケーションに関する方向別の比率（「単位時間あたりの接続数」の方向別比率（種類別比率））が算出されればよい。たとえば、或るアプリケーションについて、「下向き」の通信依頼に基づくトンネル接続の「単位時間あたりの接続数」と「上向き」の通信依頼に基づくトンネル接続の「単位時間あたりの接続数」との比率が「２：３」であるときには、方向別上限値Ｍ０１，Ｍ０２の比率が「２：３」に決定されればよい。より詳細には、当該或るアプリケーション８０に対して「１５」のアプリケーション別上限値Ｍが割り当てられる場合には、方向別上限値Ｍ０１として「６」が決定され、方向別上限値Ｍ０２として「９」が決定されればよい。

【0246】

また、上記各実施形態においては、デバイス１０からの通信依頼（ひいてはデバイス１０からのトンネル接続要求）は、管理サーバ５０を経由せずに（謂わば直接的に）ゲートウエイ３０へと送信されている（図８参照）が、これに限定されない。たとえば、図１８に示すように、デバイス１０からのトンネル接続要求は、当該デバイス１０から管理サーバ５０を経由してゲートウエイ３０へと送信されるようにしてもよい。より詳細には、デバイス１０からの通信依頼（ステップＳ２１）がゲートウエイ３０を経由して管理サーバ５０に送信され（ステップＳ２２）、管理サーバ５０からゲートウエイ３０へとトンネル接続要求が送信される（ステップＳ２４）ようにしてもよい。そして、ゲートウエイ３０は、デバイス１０からの通信依頼と管理サーバ５０からの接続要求とに基づいて、トンネル接続の確立要求をアプリケーション８０に対して送信するようにしてもよい。

【0247】

また、上記各実施形態に係るシステム１においては、複数のデバイス１０が設けられているが、これに限定されず、単一のデバイス１０のみが設けられてもよい。

【0248】

また、上記各実施形態に係るシステム１においては、複数のクラウドサーバ７０が設けられているが、これに限定されず、単一のクラウドサーバ７０のみが設けられてもよい。

【符号の説明】

【0249】

１ 通信システム
１０ デバイス
３０ ゲートウエイ
５０ 管理サーバ
７０ クラウドサーバ
８０ アプリケーション
９０ クライアント
１０７ ＬＡＮ
Ｍ アプリケーション別上限値
Ｍ０，Ｍ０１，Ｍ０２ 方向別上限値（種類別上限値）

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】