JP2019186658A - 通信システム、プラットフォームサーバおよびプログラム - Google Patents

Abstract

【課題】運用コストを低減することが可能な通信システムおよびそれに関連する技術を提供する。【解決手段】通信システムにおいて、複数のデバイス１０と複数のゲートウエイ３０とがファイアウォールの内側に設けられ、クラウドサーバ９０とプラットフォームサーバ８０と複数の種類のサーバ５０，６０とがファイアウォールの外側に設けられる。プラットフォームサーバ８０は、クラウドサーバ９０からアクセス要求を受け付けると、当該アクセス要求の通信態様情報に基づき、複数の種類の通信ルート（たとえば、時間課金サーバ５０を経由する第１ルート、およびデータ量課金サーバ６０を経由する第２ルート）の中から選択されたメッセージ送信用通信ルート（ファイアウォール通過用通信ルート）を介して、当該アクセス要求にて指定された通信対象デバイスに対応するゲートウエイに対してメッセージ（トンネル接続要求）を送信する。【選択図】図１１

Description

本発明は、ＬＡＮ外部の装置とＬＡＮ内部の装置との間の通信を行う通信システム、およびそれに関連する技術に関する。

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

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

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

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

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

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

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

図３４および図３５は、そのような技術を示す図である。各ゲートウエイ３０（３０ｘ等）は、その起動時等において、予め指定されたＸＭＰＰサーバ５０ｘ（メッセージ伝達サーバあるいは接続要求伝達サーバとも称する）との間にメッセージセッション（５１１）を確立しておく（図３４の太線参照）。その後、クラウドサーバ９０から特定のデバイス１０ｘへのアクセス要求発生時においては、図３５に示すような動作が実行される。具体的には、まず、プラットフォームサーバ８０がクラウドサーバ９０からのアクセス要求を受信し、プラットフォームサーバ８０は、ＸＭＰＰサーバ５０ｘを介してゲートウエイ３０ｘに対してトンネル接続要求を送信する。詳細には、ＸＭＰＰサーバ５０ｘと或るゲートウエイ３０（たとえば３０ｘ）との間の当該メッセージセッション（たとえば５１１）を利用することにより、ＸＭＰＰサーバ５０ｘから当該ゲートウエイ３０ｘにトンネル接続要求（メッセージ）が送信される。当該ゲートウエイ３０ｘは、当該トンネル接続要求を受信すると、当該トンネル接続要求に基づきクラウドサーバ９０との間にトンネル通信（図３５の砂地ハッチング領域（細長矩形部分）参照）を確立する。そして、当該トンネル通信（トンネル接続）を用いてクラウドサーバ９０から（ゲートウエイ３０ｘ経由で）デバイス（画像形成装置）１０ｘへのアクセスが行われる。

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

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

ところで、上記の技術においては、ゲートウエイ３０とＸＭＰＰサーバ５０ｘとの間にメッセージセッション（通信セッション）が予め確立されるようにするため、ＸＭＰＰサーバ５０ｘが常時稼働される。そのような常時稼働状況を実現するため、たとえば、当該ＸＭＰＰサーバ５０ｘは、固定的に運用される（たとえば、購入されて或いは定額課金体系（月額固定料金あるいは年額固定料金等）で貸与されて運用される）。

しかしながら、ＸＭＰＰサーバ５０ｘを常時稼働しようとすると、ＸＭＰＰサーバ５０ｘの運用コストが嵩む、という問題が存在する。特に、ＸＭＰＰサーバ５０ｘの台数が多くなると、ＸＭＰＰサーバ５０ｘの運用コストは非常に大きくなる。

そこで、本発明は、運用コストを低減することが可能な通信システムおよびそれに関連する技術を提供することを課題とする。

上記課題を解決すべく、請求項１の発明は、通信システムであって、ファイアウォールの内側に設けられる複数のデバイスと、前記ファイアウォールの内側に設けられ、前記複数のデバイスと前記ファイアウォールの外側に設けられた少なくとも１つのクラウドサーバとの通信を中継する少なくとも１つのゲートウエイと、前記ファイアウォールの外側に設けられ、前記複数のデバイスのうちの少なくとも１つの通信対象デバイスに対する少なくとも１つのアクセス要求を前記少なくとも１つのクラウドサーバから受け付けるとともに、複数の種類の通信ルートの中から選択されたメッセージ送信用通信ルートを介して、前記少なくとも１つのアクセス要求にて指定された前記少なくとも１つの通信対象デバイスに対応するゲートウエイに対してメッセージを送信するプラットフォームサーバと、を備え、前記複数の種類の通信ルートのそれぞれは、互いに異なる非定額課金体系で運用され且つ前記ファイアウォールの外側に設けられる複数の種類のサーバであってその課金金額の大小関係が通信態様に応じて変更され得る複数の種類のサーバのいずれかを経由して、前記ファイアウォールを通過するルートであり、前記プラットフォームサーバは、前記少なくとも１つのアクセス要求の通信態様情報に基づき、前記少なくとも１つの通信対象デバイスに関する前記メッセージ送信用通信ルートを前記複数の種類の通信ルートの中から選択することを特徴とする。

請求項２の発明は、請求項１の発明に係る通信システムにおいて、前記複数の種類の通信ルートは、前記複数の種類のサーバのうちの第１の種類のサーバを経由して前記ファイアウォールを通過する第１ルートと、前記複数の種類のサーバのうちの第２の種類のサーバを経由して前記ファイアウォールを通過する第２ルートとを有することを特徴とする。

請求項３の発明は、請求項２の発明に係る通信システムにおいて、前記第１の種類のサーバは、利用時間に応じて課金される時間課金サーバであり、前記第２の種類のサーバは、通信データ量に応じて課金されるデータ量課金サーバであることを特徴とする。

請求項４の発明は、請求項３の発明に係る通信システムにおいて、前記プラットフォームサーバは、前記第１ルートが選択される場合、前記第１の種類のサーバの起動依頼を所定の起動用サーバに対して送出して前記第１の種類のサーバを起動させ且つ起動後の前記第１の種類のサーバを経由して前記メッセージを前記少なくとも１つの通信対象ゲートウエイに対して送信する処理を開始することを特徴とする。

請求項５の発明は、請求項１から請求項４のいずれかの発明に係る通信システムにおいて、前記プラットフォームサーバは、一のアクセス要求の受信に応答して、前記一のアクセス要求にて通信対象として指定された前記少なくとも１つの通信対象デバイスに関する前記メッセージ送信用通信ルートの選択処理を実行するとともに、選択された前記メッセージ送信用通信ルートを介して前記メッセージを送信する処理を開始することを特徴とする。

請求項６の発明は、請求項１から請求項４のいずれかの発明に係る通信システムにおいて、前記プラットフォームサーバは、一のアクセス要求の受信時点から所定期間が経過した後において、前記所定期間内に更に受け付けられた別のアクセス要求をも含む複数のアクセス要求にて通信対象として指定された複数の通信対象デバイスに関する前記メッセージ送信用通信ルートを前記複数のアクセス要求の通信態様情報に基づき選択し、選択された前記メッセージ送信用通信ルートを介して前記メッセージを前記複数の通信対象デバイスに対応する各通信対象ゲートウエイに対して送信する処理を開始することを特徴とする。

請求項７の発明は、請求項６の発明に係る通信システムにおいて、前記所定期間は、前記一のアクセス要求の種類に応じた長さに変更されることを特徴とする。

請求項８の発明は、請求項６の発明に係る通信システムにおいて、前記所定期間は、前記一のアクセス要求の種類の緊急度合いが高い程、短い時間に変更されることを特徴とする。

請求項９の発明は、請求項１から請求項４のいずれかの発明に係る通信システムにおいて、前記プラットフォームサーバは、所定数のアクセス要求が受信された時点で、前記所定数のアクセス要求にて通信対象として指定されている複数の通信対象デバイスに関する前記メッセージ送信用通信ルートを前記所定数のアクセス要求の通信態様情報に基づき選択し、選択された前記メッセージ送信用通信ルートを介して前記メッセージを前記複数の通信対象デバイスに対応する各通信対象ゲートウエイに対して送信する処理を開始することを特徴とする。

請求項１０の発明は、請求項１から請求項４のいずれかの発明に係る通信システムにおいて、前記プラットフォームサーバは、所定数以上の通信対象デバイスに対する少なくとも１つのアクセス要求が受信された時点で、前記少なくとも１つのアクセス要求にて通信対象として指定されている複数の通信対象デバイスに関する前記メッセージ送信用通信ルートを前記少なくとも１つのアクセス要求の通信態様情報に基づき選択し、選択された前記メッセージ送信用通信ルートを介して前記メッセージを前記複数の通信対象デバイスに対応する各通信対象ゲートウエイに対して送信する処理を開始することを特徴とする。

請求項１１の発明は、請求項１から請求項４のいずれかの発明に係る通信システムにおいて、前記プラットフォームサーバは、一のアクセス要求である第１のアクセス要求に応じて前記メッセージの送信処理が開始された後に前記第１のアクセス要求とは別のアクセス要求である第２のアクセス要求がさらに受け付けられた際には、前記第１のアクセス要求にて指定された複数の通信対象デバイスのうち前記第１のアクセス要求に応じた前記メッセージの送信処理が未完了の通信対象デバイスである未完了デバイスと前記第２のアクセス要求における通信対象デバイスとに関する前記メッセージ送信用通信ルートを、前記第１のアクセス要求の通信態様情報と前記第２のアクセス要求の通信態様情報とに基づき、前記複数の種類の通信ルートの中から選択し、選択された前記メッセージ送信用通信ルートを介して、前記未完了デバイスと前記第２のアクセス要求における通信対象デバイスとにそれぞれ対応する通信対象ゲートウエイに対して前記メッセージを送信する送信処理を開始することを特徴とする。

請求項１２の発明は、請求項２から請求項４のいずれかの発明に係る通信システムにおいて、前記複数のデバイスは、前記メッセージを前記ファイアウォールを通過させて送信するためのサーバであるメッセージ伝達サーバとして前記複数の種類のサーバを選択的に利用可能な第１タイプデバイスと、その運用費用が固定的に発生するサーバである固定運用サーバのみを前記メッセージ伝達サーバとして利用可能な第２タイプデバイスとを含み、前記プラットフォームサーバは、前記少なくとも１つのアクセス要求にて指定された通信対象デバイスから前記第２タイプデバイスを除外した残余のデバイスに基づいて、前記メッセージ送信用通信ルートを選択することを特徴とする。

請求項１３の発明は、請求項１２の発明に係る通信システムにおいて、前記固定運用サーバは、常時稼働しており、且つ、前記第２タイプデバイスに対応するゲートウエイからの通信を常に許可し、前記第１ルートが前記メッセージ送信用通信ルートとして選択されていない場合、前記第１の種類のサーバは稼働しておらず、前記第１の種類のサーバが稼働状態を有する場合、前記第１の種類のサーバは前記第１タイプデバイスに対応するゲートウエイからの通信を許可し、前記第１ルートが前記メッセージ送信用通信ルートとして選択された場合、前記第１タイプデバイスに対応する前記第１の種類のサーバが起動し、前記第１タイプデバイスに対応するゲートウエイと前記第１の種類のサーバとの間にメッセージセッションが確立され、当該メッセージセッションが前記メッセージの通信用ルートとして確保されることを特徴とする。

請求項１４の発明は、請求項１２の発明に係る通信システムにおいて、所定プロトコルによるメッセージセッションを各ゲートウエイとの間で確立して前記メッセージを伝達することが可能な複数のメッセージ伝達サーバの相互間における負荷分散処理を実行する負荷分散サーバ、をさらに備え、前記第１の種類のサーバは、前記所定プロトコルによる前記メッセージセッションを前記第１タイプデバイスに対応するゲートウエイとの間に確立することが可能であり、前記負荷分散サーバは、複数のゲートウエイのそれぞれからの通信の許否を規定したＩＰフィルタを有し、前記ＩＰフィルタは、前記第２タイプデバイスに対応するゲートウエイからの通信を常に許可し、前記メッセージ送信用通信ルートとして前記第１ルートが選択されていない場合、前記第１タイプデバイスに対応するゲートウエイからの通信を許可せず、前記プラットフォームサーバは、前記メッセージ送信用通信ルートとして前記第１ルートが選択される場合、前記少なくとも１つのアクセス要求にて通信対象として指定された前記第１タイプデバイスに対応するゲートウエイである対応ゲートウエイとの通信に用いる前記メッセージ伝達サーバを増設するとともに、前記負荷分散サーバの前記ＩＰフィルタにおいて前記対応ゲートウエイのＩＰアドレスを通信許可対象アドレスとして追加登録し、前記負荷分散サーバは、前記対応ゲートウエイからの前記所定プロトコルによる前記メッセージセッションの確立要求が前記ＩＰフィルタを通過して受信されると、前記複数のメッセージ伝達サーバの中から、前記対応ゲートウエイに割り当てるべきサーバである対応サーバを決定し、前記対応サーバと前記対応ゲートウエイとの間に前記所定プロトコルによる前記メッセージセッションが確立され、前記プラットフォームサーバは、前記負荷分散サーバに前記メッセージを送信することによって、前記メッセージセッションを介して前記メッセージを前記対応ゲートウエイに対して送信することを特徴とする。

請求項１５の発明は、請求項１から請求項１３のいずれかの発明に係る通信システムにおいて、前記プラットフォームサーバは、前記少なくとも１つの通信対象デバイスの全てに関して、同じ種類の通信ルートを前記メッセージ送信用通信ルートとして選択することを特徴とする。

請求項１６の発明は、請求項２から請求項４のいずれかの発明に係る通信システムにおいて、前記プラットフォームサーバは、各通信対象デバイスと前記各通信対象デバイスに予め対応付けられた前記第１の種類のサーバである対応サーバとの対応関係に基づき、前記少なくとも１つのアクセス要求にて通信対象として指定された複数の通信対象デバイスを前記対応サーバを基準にして複数のグループに分類し、前記少なくとも１つのアクセス要求の通信態様情報に基づき前記複数の種類の通信ルートの中から前記メッセージ送信用通信ルートを選択する選択処理を、グループごとに実行することを特徴とする。

請求項１７の発明は、請求項１の発明に係る通信システムにおいて、前記プラットフォームサーバは、各アクセス要求の送信元のクラウドサーバである送信元クラウドサーバとの間でトンネル接続を確立すべき旨のトンネル接続要求を、前記メッセージとして送信し、前記メッセージ送信用通信ルートは、トンネル接続要求用通信ルートであり、前記トンネル接続要求は、非定額課金体系で運用されるメッセージ伝達サーバと前記少なくとも１つの通信対象デバイスに対応する少なくとも１つの通信対象ゲートウエイとの間で確立されたメッセージセッションを介して、前記少なくとも１つの通信対象ゲートウエイに対して送信され、前記トンネル接続要求を受信した通信対象ゲートウエイは、当該トンネル接続要求に基づき、前記通信対象ゲートウエイと前記送信元クラウドサーバとの間でトンネル接続を確立し、前記送信元クラウドサーバと前記通信対象ゲートウエイに対応するデバイスとの通信を中継し、前記プラットフォームサーバは、前記少なくとも１つのアクセス要求の通信態様情報に基づき、前記複数の種類のサーバの中から前記メッセージ伝達サーバを決定することを特徴とする。

請求項１８の発明は、ファイアウォールの内側に設けられる複数のデバイスに対する少なくとも１つのアクセス要求を受け付けることが可能であり且つ前記ファイアウォールの外側に設けられるコンピュータに、ａ）前記少なくとも１つのアクセス要求を、前記ファイアウォールの外側に設けられる少なくとも１つのクラウドサーバから受け付けるステップと、ｂ）前記少なくとも１つのアクセス要求に応じて、複数の種類の通信ルートの中から選択されたメッセージ送信用通信ルートを介して、前記少なくとも１つのアクセス要求にて指定された前記少なくとも１つの通信対象デバイスに対応するゲートウエイに対してメッセージを送信する処理を開始するステップと、を実行させるプログラムであって、前記複数の種類の通信ルートのそれぞれは、互いに異なる非定額課金体系で運用され且つ前記ファイアウォールの外側に設けられる複数の種類のサーバであってその課金金額の大小関係が通信態様に応じて変更され得る複数の種類のサーバのいずれかを経由して前記ファイアウォールを通過するルートであり、前記ステップｂ）は、ｂ−１）前記少なくとも１つのアクセス要求に応じて、前記少なくとも１つのアクセス要求の通信態様情報に基づき、前記少なくとも１つの通信対象デバイスに関する前記メッセージ送信用通信ルートを前記複数の種類の通信ルートの中から選択するステップと、ｂ−２）前記複数の種類の通信ルートの中から選択された前記メッセージ送信用通信ルートを介して、前記少なくとも１つの通信対象デバイスに対応する少なくとも１つの通信対象ゲートウエイに対して前記メッセージを送信する処理を開始するステップと、を有することを特徴とする。

請求項１９の発明は、請求項１８の発明に係るプログラムにおいて、前記複数の種類の通信ルートは、前記複数の種類のサーバのうちの第１の種類のサーバを経由して前記ファイアウォールを通過する第１ルートと、前記複数の種類のサーバのうちの第２の種類のサーバを経由して前記ファイアウォールを通過する第２ルートとを有することを特徴とする。

請求項２０の発明は、請求項１９の発明に係るプログラムにおいて、前記第１の種類のサーバは、利用時間に応じて課金される時間課金サーバであり、前記第２の種類のサーバは、通信データ量に応じて課金されるデータ量課金サーバであることを特徴とする。

請求項２１の発明は、請求項２０の発明に係るプログラムにおいて、前記ステップｂ−２）は、ｂ−２−１）前記ステップｂ−１）にて前記第１ルートが選択される場合、前記第１の種類のサーバの起動依頼を所定の起動用サーバに対して送出して、前記第１の種類のサーバを起動させるステップと、ｂ−２−２）前記ｂ−２−１）の後、起動した前記第１の種類のサーバを経由して前記メッセージを前記少なくとも１つの通信対象ゲートウエイに対して送信する処理を開始するステップと、を有することを特徴とする。

請求項２２の発明は、請求項１８から請求項２１のいずれかの発明に係るプログラムにおいて、前記ステップｂ−１）においては、一のアクセス要求の受信に応答して、前記一のアクセス要求にて通信対象として指定された前記少なくとも１つの通信対象デバイスに関する前記メッセージ送信用通信ルートの選択処理が実行され、前記ステップｂ−２）においては、前記ステップｂ−１）にて選択された前記メッセージ送信用通信ルートを介して前記メッセージを送信する処理が開始されることを特徴とする。

請求項２３の発明は、請求項１８から請求項２１のいずれかの発明に係るプログラムにおいて、前記ステップｂ−１）においては、一のアクセス要求の受信時点から所定期間が経過した後において、前記所定期間内に更に受け付けられた別のアクセス要求をも含む複数のアクセス要求にて通信対象として指定されている複数の通信対象デバイスに関する前記メッセージ送信用通信ルートが前記複数のアクセス要求の通信態様情報に基づき選択され、前記ステップｂ−２）においては、前記ステップｂ−１）にて選択された前記メッセージ送信用通信ルートを介して、前記複数の通信対象デバイスに対応する各通信対象ゲートウエイに対して前記メッセージを送信する処理を開始することを特徴とする。

請求項２４の発明は、請求項２３の発明に係るプログラムにおいて、前記所定期間は、前記一のアクセス要求の種類に応じた長さに変更されることを特徴とする。

請求項２５の発明は、請求項２３の発明に係るプログラムにおいて、前記所定期間は、前記一のアクセス要求の種類の緊急度合いが高い程、短い時間に変更されることを特徴とする。

請求項２６の発明は、請求項１８から請求項２１のいずれかの発明に係るプログラムにおいて、前記ステップｂ−１）においては、所定数のアクセス要求が受信された時点で、前記所定数のアクセス要求にて通信対象として指定されている複数の通信対象デバイスに関する前記メッセージ送信用通信ルートが前記所定数のアクセス要求の通信態様情報に基づき選択され、前記ステップｂ−２）においては、前記ステップｂ−１）にて選択された前記メッセージ送信用通信ルートを介して、前記複数の通信対象デバイスに対応する各通信対象ゲートウエイに対して前記メッセージを送信する処理が開始されることを特徴とする。

請求項２７の発明は、請求項１８から請求項２１のいずれかの発明に係るプログラムにおいて、前記ステップｂ−１）においては、所定数以上の通信対象デバイスに対する少なくとも１つのアクセス要求が受信された時点で、前記少なくとも１つのアクセス要求にて通信対象として指定されている複数の通信対象デバイスに関する前記メッセージ送信用通信ルートが前少なくとも１つのアクセス要求の通信態様情報に基づき選択され、前記ステップｂ−２）においては、前記ステップｂ−１）にて選択された前記メッセージ送信用通信ルートを介して、前記複数の通信対象デバイスに対応する各通信対象ゲートウエイに対して前記メッセージを送信する処理が開始されることを特徴とする。

請求項２８の発明は、請求項１８または請求項２１の発明に係るプログラムにおいて、ｃ）一のアクセス要求である第１のアクセス要求に応じて前記メッセージの送信処理が開始された後に、前記第１のアクセス要求とは別のアクセス要求である第２のアクセス要求をさらに受け付けるステップと、ｄ）前記第２のアクセス要求が受け付けられた際において、前記第１のアクセス要求にて指定された複数の通信対象デバイスのうち前記第１のアクセス要求に応じた前記メッセージの送信処理が未完了の通信対象デバイスである未完了デバイスと前記第２のアクセス要求における通信対象デバイスとに関する前記メッセージ送信用通信ルートを、前記第１のアクセス要求の通信態様情報と前記第２のアクセス要求の通信態様情報とに基づき、前記複数の種類の通信ルートの中から選択するステップと、ｅ）前記複数の種類の通信ルートの中から前記ステップｄ）にて選択された前記メッセージ送信用通信ルートを介して、前記未完了デバイスと前記第２のアクセス要求における通信対象デバイスとにそれぞれ対応する通信対象ゲートウエイに対して前記メッセージを送信する送信処理を開始するステップと、を前記コンピュータにさらに実行させることを特徴とする。

請求項２９の発明は、請求項１９から請求項２１のいずれかの発明に係るプログラムにおいて、前記複数のデバイスは、前記メッセージを前記ファイアウォールを通過させて送信するためのサーバであるメッセージ伝達サーバとして前記複数の種類のサーバを選択的に利用可能な第１タイプデバイスと、その運用費用が固定的に発生するサーバである固定運用サーバのみを前記メッセージ伝達サーバとして利用可能な第２タイプデバイスとを含み、前記ステップｂ−１）においては、前記少なくとも１つのアクセス要求にて指定された通信対象デバイスから前記第２タイプデバイスを除外した残余のデバイスに基づいて、前記メッセージ送信用通信ルートが選択されることを特徴とする。

請求項３０の発明は、請求項２９の発明に係るプログラムにおいて、前記固定運用サーバは、常時稼働しており、且つ、前記第２タイプデバイスに対応するゲートウエイからの通信を常に許可し、前記第１ルートが前記メッセージ送信用通信ルートとして選択されていない場合、前記第１の種類のサーバは稼働しておらず、前記第１の種類のサーバが稼働状態を有する場合、前記第１の種類のサーバは前記第１タイプデバイスに対応するゲートウエイからの通信を許可し、前記ステップｂ−２）は、ｂ−２−１）前記第１ルートが前記メッセージ送信用通信ルートとして前記ステップｂ−１）にて選択された場合、前記第１タイプデバイスに対応する前記第１の種類のサーバを起動させるステップと、ｂ−２−２）前記第１の種類のサーバの起動に応じて、前記第１タイプデバイスに対応するゲートウエイと前記第１の種類のサーバとの間にメッセージセッションが確立されると、確立された当該メッセージセッションを前記メッセージ送信用通信ルートの一部として利用して、前記メッセージを前記少なくとも１つの通信対象ゲートウエイに対して送信するステップと、を有することを特徴とする。

請求項３１の発明は、請求項２９の発明に係るプログラムにおいて、前記第１の種類のサーバは、所定プロトコルによるメッセージセッションを前記第１タイプデバイスに対応するゲートウエイとの間に確立することが可能であり、各ゲートウエイは、負荷分散サーバに対して前記所定プロトコルによる前記メッセージセッションの確立要求を送信し、前記所定プロトコルによる前記メッセージセッションを前記各ゲートウエイとの間で確立して前記メッセージを伝達することが可能な複数のメッセージ伝達サーバの相互間における負荷分散処理を実行する前記負荷分散サーバは、複数のゲートウエイのそれぞれからの通信の許否を規定したＩＰフィルタを有し、前記ＩＰフィルタは、前記第２タイプデバイスに対応するゲートウエイからの通信を常に許可し、前記メッセージ送信用通信ルートとして前記第１ルートが選択されていない場合、前記第１タイプデバイスに対応するゲートウエイからの通信を許可せず、前記ステップｂ−２）は、ｂ−２−１）前記第１ルートが前記メッセージ送信用通信ルートとして前記ステップｂ−１）にて選択された場合、前記少なくとも１つのアクセス要求にて通信対象として指定された前記第１タイプデバイスに対応するゲートウエイである対応ゲートウエイとの通信に用いるメッセージ伝達サーバを増設するステップと、ｂ−２−２）前記第１ルートが前記メッセージ送信用通信ルートとして前記ステップｂ−１）にて選択された場合、前記負荷分散サーバの前記ＩＰフィルタにおいて前記対応ゲートウエイのＩＰアドレスを通信許可対象アドレスとして追加登録するステップと、ｂ−２−３）前記対応ゲートウエイからの前記所定プロトコルによる前記メッセージセッションの確立要求が前記ＩＰフィルタを通過して受信されることに応じて、前記ステップｂ−２−１）にて増設された前記第１の種類のサーバであって前記負荷分散サーバによる割り当て処理によって割り当てられた前記第１の種類のサーバと前記対応ゲートウエイとの間に前記メッセージセッションが確立された後、前記負荷分散サーバに前記メッセージを送信することによって、前記メッセージセッションを介して前記メッセージを前記対応ゲートウエイに対して送信するステップと、を有することを特徴とする。

請求項３２の発明は、請求項１８から請求項３１のいずれかの発明に係るプログラムにおいて、前記ステップｂ−１）において、前記少なくとも１つの通信対象デバイスの全てに関して、同じ種類の通信ルートが前記メッセージ送信用通信ルートとして選択されることを特徴とする。

請求項３３の発明は、請求項１９から請求項２１のいずれかの発明に係るプログラムにおいて、前記ステップｂ−１）は、ｂ−１−１）各通信対象デバイスと前記各通信対象デバイスに予め対応付けられた前記第１の種類のサーバである対応サーバとの対応関係に基づき、前記少なくとも１つのアクセス要求にて通信対象として指定された複数の通信対象デバイスを、前記対応サーバを基準にして複数のグループに分類するステップと、ｂ−１−２）前記少なくとも１つのアクセス要求の通信態様情報に基づき前記複数の種類の通信ルートの中から前記メッセージ送信用通信ルートを選択する選択処理を、グループごとに実行するステップと、を有することを特徴とする。

請求項３４の発明は、請求項１８の発明に係るプログラムにおいて、前記ステップｂ−２）において、各アクセス要求の送信元のクラウドサーバである送信元クラウドサーバとの間でトンネル接続を確立すべき旨のトンネル接続要求が、前記メッセージとして送信され、前記メッセージ送信用通信ルートは、トンネル接続要求用通信ルートであり、前記トンネル接続要求は、非定額課金体系で運用されるメッセージ伝達サーバと前記少なくとも１つの通信対象デバイスに対応する少なくとも１つの通信対象ゲートウエイとの間で確立されたメッセージセッションを介して、前記少なくとも１つの通信対象ゲートウエイに対して送信され、前記ステップｂ−１）において、前記少なくとも１つのアクセス要求の通信態様情報に基づき、前記複数の種類のサーバの中から前記メッセージ伝達サーバが決定されることを特徴とする。

請求項３５の発明は、ファイアウォールの内側に設けられる複数のデバイスに対する少なくとも１つのアクセス要求を受け付けることが可能であり且つ前記ファイアウォールの外側に設けられるプラットフォームサーバであって、前記少なくとも１つのアクセス要求を、前記ファイアウォールの外側に設けられる少なくとも１つのクラウドサーバから受け付ける受信手段と、前記少なくとも１つのアクセス要求に応じて、複数の種類の通信ルートの中から選択されたメッセージ送信用通信ルートを介して、前記少なくとも１つのアクセス要求にて指定された前記少なくとも１つの通信対象デバイスに対応するゲートウエイに対してメッセージを送信する処理を開始する送信手段と、を備え、前記複数の種類の通信ルートのそれぞれは、互いに異なる非定額課金体系で運用され且つ前記ファイアウォールの外側に設けられる複数の種類のサーバであってその課金金額の大小関係が通信態様に応じて変更され得る複数の種類のサーバのいずれかを経由して前記ファイアウォールを通過するルートであり、前記プラットフォームサーバは、前記少なくとも１つのアクセス要求に応じて、前記少なくとも１つのアクセス要求の通信態様情報に基づき、前記少なくとも１つの通信対象デバイスに関する前記メッセージ送信用通信ルートを前記複数の種類の通信ルートの中から選択する選択手段、をさらに備え、前記送信手段は、前記複数の種類の通信ルートの中から選択された前記メッセージ送信用通信ルートを介して、前記少なくとも１つの通信対象デバイスに対応する少なくとも１つの通信対象ゲートウエイに対して前記メッセージを送信する処理を開始することを特徴とする。

請求項１から請求項３５に記載の発明によれば、非定額課金体系で運用される複数の種類のサーバのいずれかを経由する通信ルートを介してメッセージが送信されるので、当該メッセージをファイアウォール越しに伝達するためのメッセージ伝達サーバが常に固定的な運用費用を発生させる場合に比べて、運用コストを低減することが可能である。特に、互いに異なる種類の非定額課金体系で運用される複数の種類のサーバであってその相互間における課金金額の大小関係が通信態様に応じて変更され得る複数の種類のサーバのいずれかを経由する複数の種類の通信ルートの中から、アクセス要求の通信態様情報に基づいてメッセージ送信用通信ルートが選択されるので、運用コストを一層抑制することが可能である。

通信システムの概略構成を示す図である。 ＭＦＰの構成を示す概略図である。 ゲートウエイおよびプラットフォームサーバ等の概略構成を示す図である。 通信システムの初期状態を示す図である。 第１実施形態のプラットフォームサーバの動作を示すフローチャートである。 デバイスリストを示す図である。 各通信対象デバイスに関するトンネル接続要求がデータ量課金サーバを経由して各対応ゲートウエイに送信される様子を示す図である。 非稼働状態を有していた時間課金サーバが起動される様子を示す図である。 所定時間間隔でゲートウエイから送信されていたＸＭＰＰ接続要求が、起動後の時間課金サーバにて受信される様子を示す図である。 各ゲートウエイと時間課金サーバとの間でＸＭＰＰ接続が確立された様子を示す図である。 各通信対象デバイスに関するトンネル接続要求が時間課金サーバを経由して（ＸＭＰＰ接続を介して）各対応ゲートウエイに送信される様子を示す図である。 ２種類の非定額課金体系の料金のグラフを示す図である。 第２実施形態に係る動作を示すフローチャートである。 第２実施形態の変形例に関する動作を示すフローチャートである。 アクセス要求種類と待機期間との関係を規定したデータテーブルを示す図である。 第３実施形態に係る動作を示すフローチャートである。 第３実施形態の変形例に関する動作を示すフローチャートである。 第４実施形態に係る動作を示すフローチャートである。 複数の時間課金サーバが設けられた通信システムを示す図である。 第５実施形態に係る動作を示すフローチャートである。 第５実施形態に係る通信システムの概略構成を示す図である。 第２ルート（データ量課金サーバ経由ルート）等でトンネル接続要求が送信される様子を示す図である。 第１ルート（時間課金サーバ経由ルート）が選択された際の動作を示す図である。 第１ルート等を経由してトンネル接続要求が送信される様子を示す図である。 デバイスリストを示す図である。 第６実施形態に係る動作を示すフローチャートである。 第６実施形態に係る通信システムの概略構成を示す図である。 第２ルート等でトンネル接続要求が送信される様子を示す図である。 第１ルートが選択された際の動作を示す図である。 第１ルートが選択された際の動作を示す図である。 第１ルートが選択された際の動作を示す図である。 第７実施形態に係る動作を示すフローチャートである。 デバイスリスト等を示す図である。 比較例に係る通信システムを示す図である。 比較例に係る通信システムを示す図である。

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

＜１．第１実施形態＞
＜１−１．システム構成概要＞
図１は、本発明の実施形態に係る通信システム１の概略構成を示す図である。図１にも示すように、通信システム１は、少なくとも１つ（ここでは複数）のデバイス１０（１０ａ，１０ｂ，１０ｃ，...）と、少なくとも１つ（ここでは複数）のゲートウエイ３０（３０ａ，３０ｂ）と、少なくとも１つ（ここでは単一）のクラウドサーバコンピュータ（以下、単にクラウドサーバとも称する）９０と、少なくとも１つ（ここでは単一）のクライアントコンピュータ（以下、単にクライアントとも称する）１００と、管理用サーバ群２００とを備える。

管理用サーバ群２００は、管理用プラットフォームサーバ（以下、単にプラットフォームサーバとも称する）８０と、複数の接続要求伝達サーバ（５０，６０）と、サービス起動用サーバ４０とを備える。

また、ここでは、接続要求伝達サーバ（メッセージ伝達サーバとも称する）として、少なくとも１つ（ここでは複数）の時間課金サーバ５０と、少なくとも１つ（ここでは単一）のデータ量課金サーバ（ＭＱＴＴサーバとも称する）６０とが設けられる。なお、ここでは、時間課金サーバ５０は、ＸＭＰＰ（Extensible Messaging and Presence Protocol）のプロトコルを利用してメッセージを送信することからＸＭＰＰサーバとも称され、データ量課金サーバ６０は、ＭＱＴＴ（Message Queue Telemetry Transport）のプロトコルを利用してメッセージを送信することからＭＱＴＴサーバとも称される。なお、時間課金サーバ５０およびデータ量課金サーバ６０は、それぞれ、他のプロトコルを利用してメッセージを送信してもよい。また、後述するように、サービス起動用サーバ４０は、プラットフォームサーバ８０からの起動依頼に応じて非稼働状態（非起動状態）の時間課金サーバ５０（より詳細にはＸＭＰＰサービス）を起動させる処理等を実行するサーバ（起動用サーバ）である。

各要素１０，３０，４０，５０，６０，８０，９０，１００，２００は、ネットワーク１０８を介して互いに接続されており、ネットワーク通信を実行することが可能である。ただし、後述するように、ファイアウォールによって一部の通信は遮断される。なお、ネットワーク１０８は、ＬＡＮ（ローカルエリアネットワーク）、ＷＡＮ（ワイドエリアネットワーク）、インターネットなどによって構成される。また、ネットワーク１０８への接続形態は、有線接続であってもよく或いは無線接続であってもよい。

複数のデバイス１０および複数のゲートウエイ３０は、企業内等に構築された或るＬＡＮ１０７の内部（換言すれば、ファイアウォールの内側）に設けられている。一方、管理用サーバ群２００、クラウドサーバ９０およびクライアント１００は、ＬＡＮ１０７の外部（換言すれば、ファイアウォールの外側）に設けられている。なお、クライアント１００は、ＬＡＮ１０７の内部（ファイアウォールの内側）に設けられていてもよい。

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

また、ゲートウエイ３０は、ここではデバイス１０としてのＭＦＰとは別のＭＦＰに構築される。具体的には、ハードウエアとしてのＭＦＰ内に組み込まれたソフトウエア（プログラム）を実行することにより、ゲートウエイ３０が実現される。

一方、各種サーバ４０，５０，６０，８０，９０およびクライアント１００は、それぞれ、ブレードコンピュータ或いは所謂パーソナルコンピュータ等を用いて構築される。

この通信システム１においては、たとえば、クライアント１００からクラウドサーバ９０へと送出された印刷指令が、クラウドサーバ９０とゲートウエイ３０との間に確立されたトンネル接続を利用して、クラウドサーバ９０からゲートウエイ３０を経由してデバイス１０へと送信され、デバイス（ＭＦＰ）１０において印刷出力が行われる。あるいは、クライアント１００からクラウドサーバ９０へと送出されたファームウエアのアップデートデータが、クラウドサーバ９０とゲートウエイ３０との間に確立されたトンネル接続を利用して、クラウドサーバ９０からゲートウエイ３０を経由してデバイス１０へと送信され、デバイス（ＭＦＰ）１０においてファームウエアのアップデート処理が行われる。

複数のゲートウエイ３０は、複数のデバイス１０とクラウドサーバ９０との通信を中継する機能を有しており、各ゲートウエイ３０は、通信中継装置とも称される。

管理用サーバ群２００は、クラウドサーバ９０と複数のゲートウエイ３０との通信等を管理する装置群である。管理用サーバ群２００は、複数のデバイス１０のうちの１又は複数の特定のデバイス（通信対象デバイス）に対するアクセス要求をクラウドサーバ９０から受け付けるとともに、当該アクセス要求に応じて、複数のゲートウエイ３０のいずれか（具体的には、当該通信対象デバイスに対応づけられているゲートウエイ）に対してクラウドサーバ９０とのトンネル接続要求を送信する。

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

ＭＦＰは、印刷出力処理（プリント処理）および画像読取処理（スキャン処理）等を行うことが可能な画像形成装置である。この実施形態では、ＬＡＮ１０７内に複数のＭＦＰが設けられている。また、当該複数のＭＦＰのうちの一部のＭＦＰは、ゲートウエイ３０としても動作する。

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

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

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

通信部４は、公衆回線等を介したファクシミリ通信を行うことが可能な処理部である。さらに、通信部４は、ネットワーク１０８を介したネットワーク通信が可能である。このネットワーク通信では、ＴＣＰ／ＩＰ（Transmission Control Protocol / Internet Protocol）およびＦＴＰ（File Transfer Protocol）等の各種のプロトコルが利用され、当該ネットワーク通信を利用することによって、ＭＦＰは、所望の相手先（サーバ５０，６０，９０等）との間で各種のデータを授受することが可能である。

詳細には、ゲートウエイ３０として動作するＭＦＰの通信部４は、ゲートウエイ３０と接続要求伝達サーバ（５０あるいは６０）との間に確立されたメッセージセッション（後述）を利用して、当該接続要求伝達サーバと通信すること（特に接続要求伝達サーバからのデータ（トンネル接続要求等）を受信すること）ができる。また、デバイス１０として動作するＭＦＰの通信部４は、ゲートウエイ３０とクラウドサーバ９０との間に確立されたトンネル接続（後述）を利用して、当該ゲートウエイ３０を経由してクラウドサーバ９０と通信すること（特にクラウドサーバ９０からのデータを受信すること）もできる。なお、通信部４は、他の装置に対してデータ等を送信する送信部と、他の装置からデータ等を受信する受信部とを有する。

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

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

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

コントローラ９は、ＣＰＵにおいて、ＲＯＭ（例えば、ＥＥＰＲＯＭ（登録商標）等）内に格納されている所定のソフトウエアプログラム（単にプログラムとも称する）を実行することによって、各種の処理部（画像形成動作等を制御する動作制御部１６、および後述するゲートウエイ処理部１８等）を実現する。

たとえば、ゲートウエイ３０として動作するＭＦＰのコントローラ９は、ゲートウエイ処理部１８（通信制御部３１（図３参照）等を含む）を実現する。また、デバイス１０のみとして動作するＭＦＰのコントローラ９も同様の処理部を有していても良いが、ゲートウエイ３０として機能するための処理部を有していなくてもよい。なお、当該プログラムは、たとえば各種の可搬性の記録媒体（ＵＳＢメモリ等）に記録され、当該記録媒体を介してＭＦＰにインストールされればよい。あるいは当該プログラムは、ネットワーク１０８等を介してダウンロードされてＭＦＰにインストールされるようにしてもよい。

＜１−３．各要素の構成概要＞
図３は、各要素３０，８０，９０等の概略構成を示す図である。図３を参照して、これらの各要素について説明する。

＜クラウドサーバ９０＞
クラウドサーバ９０は、少なくとも１つの通信対象デバイスに対するアクセス要求をプラットフォームサーバ８０に送信するサーバである。

クラウドサーバ９０は、通信制御部８１を備える。通信制御部８１は、プラットフォームサーバ８０およびゲートウエイ３０との通信を実行する。特に、ファイアウォール外部に配置されたクラウドサーバ９０の通信制御部８１は、ファイアウォール内部に配置された各ゲートウエイ３０との通信をトンネル通信（後述）を用いて実行する。

＜プラットフォームサーバ８０＞
プラットフォームサーバ８０は、管理用サーバ群２００を構成する一のサーバであり、管理用サーバなどとも称される。プラットフォームサーバ８０は、クラウドサーバ９０からのアクセス要求を受け付けることが可能なサーバである。

プラットフォームサーバ８０は、通信制御部８１、デバイス情報管理部８２、解析部８３および選択部８４などの各種の処理部を備える。

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

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

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

解析部８３は、クラウドサーバ９０から受信したアクセス要求の内容を解析するとともに、各通信対象デバイス（当該アクセス要求において接続先（通信対象）として指定されたデバイス）１０に対応する通信対象ゲートウエイを決定する処理部である。解析部８３は、接続先デバイス１０に対する通信を中継することが可能なゲートウエイ３０を、管理テーブル８６に基づき決定する処理部である。解析部８３は、利用すべきゲートウエイ３０（通信中継装置）を決定する中継装置決定部とも表現される。

選択部８４は、クラウドサーバ９０からのアクセス要求に応じて、複数の種類の通信ルートの中から、各通信対象デバイス（接続先デバイスとも称する）１０に関する接続要求用通信ルート（後述）を、アクセス要求の通信態様情報に基づき選択（決定）する処理部である。

また、通信制御部８１および通信部８７等は、クラウドサーバ９０（アクセス要求の送信元のクラウドサーバ（送信元クラウドサーバとも称する））との間でトンネル接続を確立すべき旨のトンネル接続要求を送信する。当該トンネル接続要求は、選択部８４によって複数の種類の通信ルートの中から選択（決定）されたトンネル接続要求用通信ルート（単に接続要求用通信ルートとも称する）を介して、解析部（中継装置決定部）８３によって決定されたゲートウエイ３０（通信中継装置）に対して送信される。なお、「接続要求用通信ルート」は、「メッセージ送信用通信ルート」あるいは「ファイアウォール通過用通信ルート」などとも称される。

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

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

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

ＬＡＮ内通信制御部３４は、ＬＡＮ内の各種装置（デバイス１０等）との通信を実行する処理部である。

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

メッセージセッション通信制御部３２は、接続要求伝達サーバ（５０あるいは６０）との通信をメッセージセッション（ＸＭＰＰ接続あるいはＭＱＴＴ接続等）を用いて実行する処理部である。メッセージセッション通信制御部３２は、接続要求伝達サーバ（５０あるいは６０）との間にメッセージセッションを確立して、当該接続要求伝達サーバとの通信を実行する。

トンネル通信制御部３３は、クラウドサーバ９０との通信をトンネル通信（後述）を用いて実行する処理部である。トンネル通信制御部３３は、クラウドサーバ９０との間にトンネル通信を確立して、クラウドサーバ９０と特定のデバイス１０との通信を中継する。トンネル通信制御部３３は、対クラウドサーバ通信部（あるいはクラウドサーバ通信部）とも称される。

後述するように、メッセージセッションを利用することによって、ファイアウォールＦＷ（図４等参照）の外部の装置（接続要求伝達サーバ（５０あるいは６０））からファイアウォールＦＷの内部の装置（ゲートウエイ３０）に対して、データ（メッセージ等）を送信することが可能である。また、トンネル接続を利用することによって、ファイアウォールＦＷの外部の装置（クラウドサーバ９０）からファイアウォールＦＷの内部の装置（ゲートウエイ３０およびデバイス１０）に対して、データ（ファームウエアアップデートデータ等）を送信することが可能である。

＜１−４．比較例に係る動作＞
ここで、比較例に係る動作について、図３４および図３５を参照しつつ説明する。この比較例に係る動作においては、ファイアウォール外部の管理用サーバ群２００（特にＸＭＰＰサーバ５０ｘ）とファイアウォール内部のゲートウエイ３０との間に（ファイアフォールの例外としての）メッセージセッション（ＸＭＰＰ接続）を確立しておき、ファイアウォール外部のクラウドサーバ９０から、当該管理用サーバ群２００および当該ゲートウエイ３０を経由して、ファイアウォール内部のデバイス１０にアクセスすることが行われ得る。管理用サーバ群２００は、プラットフォームサーバ８０およびＸＭＰＰサーバ（ここでは、固定運用サーバ（その運用費用が固定的に発生するサーバ））５０ｘを有する。

上述（図３４参照）のように、ゲートウエイ３０は、その起動時等において、予め指定されたＸＭＰＰサーバ（固定運用サーバ）５０ｘとの間に通信セッション（詳細には、メッセージセッション）（５１１）を予め確立しておく。その後、クラウドサーバ９０から特定のデバイス１０へのアクセス要求発生時において、ＸＭＰＰサーバ５０ｘとゲートウエイ３０（３０ｘ）との間の当該メッセージセッション（常時接続通信セッション）（５１１）を利用することにより、プラットフォームサーバ８０からＸＭＰＰサーバ５０ｘを経由して当該ゲートウエイ３０ｘにトンネル接続要求が送信される。当該ゲートウエイ３０ｘは、当該トンネル接続要求に基づき、クラウドサーバ９０との間にトンネル通信を確立する（図３５参照）。そして、当該トンネル通信を用いてクラウドサーバ９０から（ゲートウエイ３０経由での）デバイス（画像形成装置）１０へのアクセスが行われる。

より詳細には、まず、各ゲートウエイ３０は、それぞれの起動時等において、予め指定されたＸＭＰＰサーバ５０ｘに対してメッセージセッションの接続要求（確立要求）を送信する。これに応じて、ＸＭＰＰサーバ５０ｘが当該確立要求を承認することによって、各ゲートウエイ３０とＸＭＰＰサーバ５０ｘとの間にメッセージセッション（５１１）がそれぞれ確立される（図３４参照）。換言すれば、ファイアウォール内部のゲートウエイ３０からファイアウォール外部のＸＭＰＰサーバ５０ｘへのアクセスに応じて、メッセージセッションが確立される。当該メッセージセッション（通信セッション）としては、「XMPP:eXtensible Messaging and Presence Protocol」）のプロトコルを用いたものが例示される。また、各ゲートウエイ３０は、各ゲートウエイ３０の管理下のデバイス（管理対象デバイス）の情報等をプラットフォームサーバ８０へ送信しておく。また、プラットフォームサーバ８０は、各ゲートウエイ３０による管理対象デバイスの情報を含む登録情報（管理テーブル８６）を、プラットフォームサーバ８０の格納部８５（図３）に格納する。

そして、ＸＭＰＰサーバ５０ｘとゲートウエイ３０との間の当該メッセージセッションを利用して、クラウドサーバ９０から、デバイス（画像形成装置）１０へのアクセスが行われ得る。

詳細には、クラウドサーバ９０が特定のデバイス１０ｘに対するアクセス（通信）を行いたい場合には、まず特定のデバイス１０ｘ向けのアクセス要求がクラウドサーバ９０からプラットフォームサーバ８０に送信される。

プラットフォームサーバ８０は、特定のデバイス１０に対応するゲートウエイ３０（特定のデバイス１０ｘをその配下に有する特定のゲートウエイ３０ｘ等）を管理情報（管理テーブル８６）に基づいて特定する。換言すれば、アクセスすべきゲートウエイ３０が管理テーブル８６に基づいて特定される。なお、これに限定されず、たとえば、アクセスすべきゲートウエイ３０は、アクセスすべき特定のデバイス１０等とともにユーザ等によって予め指定されていてもよい。そして、アクセスすべきゲートウエイ３０は、当該指定に基づいて特定されるようにしてもよい。

また、プラットフォームサーバ８０は、特定されたゲートウエイ３０に対して、ＸＭＰＰサーバ５０ｘを経由してトンネル接続要求を送信する。

たとえば、まず、特定のデバイス１０ｘに対するアクセス要求がクラウドサーバ９０からプラットフォームサーバ８０に送信された場合において、プラットフォームサーバ８０は、特定のデバイス１０ｘに対応するゲートウエイ（３０ｘ）を管理情報（管理テーブル８６）に基づいて特定する。

つぎに、ＸＭＰＰサーバ５０ｘと（特定のデバイス１０ｘに対応する）特定のゲートウエイ３０ｘとの間にメッセージセッション５１１が確立されているときには、プラットフォームサーバ８０は、当該特定されたゲートウエイ３０ｘに対してトンネル接続要求を当該メッセージセッション５１１を介して送信する。「トンネル接続要求」は、クラウドサーバ９０との間にトンネル接続（トンネル通信接続）を確立すべき旨の接続要求（確立要求）である。このように、ＸＭＰＰサーバ５０ｘと特定のゲートウエイ３０ｘとの間にメッセージセッション５１１が確立されているときには、当該トンネル接続要求は、ＸＭＰＰサーバ５０ｘとゲートウエイ３０ｘとの間の当該メッセージセッション５１１を利用して送信される。

トンネル接続要求を受信したゲートウエイ３０は、当該トンネル接続要求に応答して、ＨＴＴＰ（Hypertext Transfer Protocol）セッション（より詳細には、ＨＴＴＰＳ（Hypertext Transfer Protocol Secure）セッション）の確立要求をクラウドサーバ９０に対して送信する。そして、クラウドサーバ９０が当該確立要求を承認することによって、当該ゲートウエイ３０とクラウドサーバ９０との間に当該ＨＴＴＰセッションによるトンネル接続（トンネル通信）が確立される。換言すれば、ファイアウォール内部のゲートウエイ３０からファイアウォール外部のクラウドサーバ９０へのアクセスに応じて、トンネル接続（トンネル通信）が確立される。そして、このＨＴＴＰセッションによるトンネル通信を用いて、クラウドサーバ９０は、ゲートウエイ３０を経由してデバイス１０（たとえば１０ｄ）へと各種のデータを送信することが可能である。このようなＨＴＴＰ（ＨＴＴＰＳ）セッションの確立要求は、トンネル接続の確立要求とも称される。なお、図３５においては、砂地ハッチング付きの細長い矩形によって「トンネル通信」が模式的に示されている。

＜１−５．第１実施形態に係る動作＞
上記比較例に係る動作においては、ゲートウエイ３０とＸＭＰＰサーバ５０ｘとの間にメッセージセッション（通信セッション）が予め確立されるようにするため、たとえばＸＭＰＰサーバ５０ｘが常時稼働される。また、ＸＭＰＰサーバ５０ｘの常時稼働を実現するため、たとえば当該ＸＭＰＰサーバ５０ｘは固定的に運用される（具体的には、購入されて或いは定額課金体系で貸与されて運用される）。なお、当該ＸＭＰＰサーバ５０ｘは、その運用費用が固定的に発生するサーバであることから、固定運用サーバとも称される。

しかしながら、ＸＭＰＰサーバ５０ｘを常時稼働しようとすると、ＸＭＰＰサーバ５０ｘの運用コストが嵩む、という問題が存在する。特に、ＸＭＰＰサーバ５０ｘの台数が多くなると、ＸＭＰＰサーバ５０ｘの運用コストは非常に大きくなる。

ここにおいて、ＸＭＰＰサーバ５０ｘ（詳細には、固定運用サーバ）の稼働期間の全体の中には、データ（トンネル接続要求等）の送受信が実際には行われていない期間が存在する。特に、トンネル接続要求の送受信の頻度は比較的低く、当該固定運用サーバの全稼働期間に対して実際の送受信が行われている期間の割合（端的に言えば、固定運用サーバの稼働率）は比較的低い。端的に言えば、トンネル接続要求の実行指示を待機している期間（アイドル期間）が長く、固定運用サーバの利用効率は低い。

そこで、この実施形態では、管理用サーバ群２００におけるトンネル接続要求の通信用のサーバ（「接続要求伝達サーバ」（メッセージ伝達サーバ））として、上述のような固定運用サーバ（その運用費用が固定的に発生するサーバ）（ＸＭＰＰサーバ５０ｘ）の代わりに、その運用費用が変動し得るサーバ（変動運用サーバあるいは非固定運用サーバとも称する）（詳細には、「非定額課金体系」で貸与されて運用されるサーバ）が利用される。これによれば、運用コストを低減することが可能である。ここで、「非定額課金体系」は、定額課金以外の課金体系であり、使用量（使用データ量あるいは使用時間等）に応じた従量課金体系を含む。

また、「非定額課金体系」で運用されるサーバ（非定額課金サーバとも称する）として、複数の種類（ここでは２種類）の非定額課金サーバが選択的に利用される。具体的には、「時間課金サーバ」５０（利用時間に応じて課金されるサーバ（時間課金制が適用されるサーバ））と「データ量課金サーバ」６０（通信データ量に応じて課金されるサーバ（データ量課金制が適用されるサーバ））との２種類の従量制課金サーバが選択的に利用される。より詳細には、クラウドサーバ９０からのアクセス要求の通信態様情報（当該アクセス要求にて指定された通信対象デバイスの数など）に基づいて、時間課金サーバ（時間課金制サーバとも称する）５０とデータ量課金サーバ（データ量課金制サーバとも称する）６０との中から、一の種類の非定額課金サーバが選択される。これによれば、２種類のサーバのうち、アクセス要求の内容に応じたサーバ（より安価なサーバ）を利用することが可能である。

これら複数の種類のサーバ５０，６０は、互いに異なる種類の非定額課金体系（従量課金制（変動課金制））で運用される複数の種類のサーバである。また、当該複数の種類のサーバ５０，６０の課金金額の相互間の大小関係は、通信（トンネル接続要求等）の通信態様（通信頻度あるいは通信密度等）に応じて変更（逆転）され得る。たとえば、メッセージ（トンネル接続要求）が非常に低頻度でのみ送信される場合（少数のメッセージが散発的に送信される場合等）には、データ量課金サーバ６０の課金金額の方が時間課金サーバ５０の課金金額よりも安い。逆に、メッセージが非常に高頻度で送信される場合（非常に多数のメッセージが集中して送信される場合等）には、時間課金サーバ５０の課金金額の方がデータ量課金サーバ６０よりも安い。

ここで、１台のデータ量課金サーバ６０の料金は、次のように算出される。たとえば、１メッセージ（最小送信データ単位）（５ＫＢ（キロバイト））あたり「０．０００００１ＵＳＤ」の金額が課金され、１つのトンネル接続要求が１メッセージ（５ＫＢ）以内である場合を想定する。この場合、トンネル接続要求の数に「０．０００００１ＵＳＤ」を乗じた額がデータ量課金サーバの料金として算出される。仮に、アクセス要求に通信対象デバイスとして１００万個のデバイスが指定されているときには、１００万個のトンネル接続要求の送信が要求されるので、「１」ＵＳＤ（＝１００万×「０．０００００１」ＵＳＤ）がデータ量課金サーバの料金として算出される。また、アクセス要求に通信対象デバイスとして１個のデバイスのみが指定されているときには、１個のトンネル接続要求の送信が要求されるので、「０．０００００１」ＵＳＤ（＝１×「０．０００００１」ＵＳＤ）がデータ量課金サーバの料金として算出される。なお、データ量課金サーバ６０は、（メッセージ送信の有無にかかわらず）常時起動されているものの、データ量課金サーバ６０の起動期間（およびデータ送信の「時間」）に依拠した課金はなされない。データ量課金サーバ６０の利用に対しては、送信データのデータ量に応じてのみ課金される。

一方、１台の時間課金サーバ５０の料金は、次のように算出される。たとえば、或るレベルの処理能力を有する時間課金サーバに関して、１時間あたり「０．１３３（ＵＳＤ）」（１秒あたり「０．００００３６９４（ＵＳＤ）」）の金額が課金され、当該サーバは１秒あたり１００個のメッセージ（１００個のトンネル接続要求）を処理可能である場合を想定する。仮に、アクセス要求に通信対象デバイスとして１００万個のデバイスが指定されているときには、１００万個のデバイスに関する１００万個のトンネル接続要求の送信に１万秒（約３時間）の稼働時間を要する（１００万（個）／１００（個／秒）＝１万秒＝２．７７７８時間）ので、「０．３６９４」ＵＳＤ（＝１００００００×０．００００３６９４＝２．７７７８×０．１３３ＵＳＤ）が時間課金サーバの料金として算出される。また、１個のデバイスに関する１個のトンネル接続要求の送信に１秒以下（１／１００秒）の稼働時間を要するので、最小課金単位の１秒に１秒単価（１秒あたり「０．００００３６９４（ＵＳＤ）」）を乗じた金額「０．００００３６９４（ＵＳＤ）」が時間課金サーバの料金として算出される。

したがって、アクセス要求に通信対象デバイスとして１個のデバイスのみが指定されているとき（換言すれば、通信頻度が所定程度よりも低いとき）には、データ量課金サーバ６０の料金（「０．０００００１」ＵＳＤ）の方が時間課金サーバ５０の料金（「０．００００３６９４」ＵＳＤ」）よりも低額である（安い）。

一方、アクセス要求に通信対象デバイスとして１００万個のデバイスが指定されているとき（換言すれば、通信頻度が所定程度よりも高いとき）には、逆に、時間課金サーバ５０の料金（「０．３９９」ＵＳＤ）の方がデータ量課金サーバ６０の料金（「１」ＵＳＤ）よりも低額である（安い）。

図１２は、このような２種類の非定額課金体系の料金のグラフを示す図である。曲線Ｌ１１は、時間課金サーバ５０の料金を示しており、曲線Ｌ２０は、データ量課金サーバ６０の料金を示している。両曲線Ｌ１１，Ｌ２０を比較すると判るように、アクセス要求にて指定される通信対象デバイスの数Ｎ（換言すれば、トンネル接続要求の数）が所定数ＴＨ１（ＴＨ１１）より小さいときには、データ量課金サーバ６０の料金（Ｌ２０参照）が時間課金サーバ５０の料金（Ｌ１１参照）よりも安い。一方、当該通信対象デバイスの数Ｎが所定数ＴＨ１（ＴＨ１１）より大きいときには、時間課金サーバ５０の料金（Ｌ１１参照）がデータ量課金サーバ６０の料金（Ｌ２０参照）よりも安い。

その後、トンネル接続要求を伝達する通信ルートとして複数の種類（ここでは２種類）の通信ルートの中から選択された「接続要求用通信ルート」（メッセージ送信用通信ルート）を介して、少なくとも１つの通信対象デバイスに対応する少なくとも１つの通信対象ゲートウエイに対して送信処理が開始される。ここで、接続要求用通信ルートは、ファイアウォールを越えて（通過させて）トンネル接続要求をゲートウエイに送信する通信ルート（ファイアウォール通過用通信ルートとも称する）である。各接続要求用通信ルートは、上述の複数の種類のサーバ（５０，６０等）のいずれかを経由してファイアウォールを通過するルートであり、且つ、当該複数の種類のサーバのうちの互いに異なる種類のサーバを経由するルートである。たとえば、接続要求用通信ルートとしては、複数の種類のサーバのうちの「時間課金サーバ５０」を経由してプラットフォームサーバ８０側からファイアウォールを通過する第１ルートと、当該複数の種類のサーバのうちの「データ量課金サーバ６０」を経由してプラットフォームサーバ８０側からファイアウォールを通過するファイアウォールを通過）する第２ルートとが存在する。

なお、上述の料金算出例では、時間課金サーバ５０の料金の算出にて、当該時間課金サーバ５０の起動に要する時間（所要起動時間）を考慮していないが、当該所要起動時間を考慮してもよい。当該所要起動時間を考慮すると、所定数（閾値）ＴＨ１は、値ＴＨ１１よりも大きな値ＴＨ１２（あるいはＴＨ１３）等に遷移する。曲線Ｌ１２，Ｌ１３は、その所要起動時間をも考慮した時間課金サーバ５０の料金を示している。曲線Ｌ１２は、比較的小さな所要起動時間に対応する時間課金サーバ５０の料金を示しており、曲線Ｌ１３は、比較的大きな所要起動時間に対応する時間課金サーバ６０の料金を示している。

また、ここでは、「時間課金サーバ」として１台の接続要求伝達サーバが選択される態様を主に例示しているが、これに限定されない。たとえば、「時間課金サーバ」として複数の接続要求伝達サーバ（図１９では複数の時間課金サーバ５０）が選択されるようにしてもよい。図１９には、通信システムにおいて複数の時間課金サーバが設けられ、複数の時間課金サーバが複数の接続要求伝達サーバとして選択され得る状態が示されている。

具体的には、アクセス要求にて指定された少なくとも１つの通信対象デバイスに関するトンネル接続要求を伝達すべき接続要求伝達サーバが全て時間課金サーバ５０（複数の時間課金サーバ）で構成される場合の合計料金と、当該接続要求伝達サーバが全てデータ量課金サーバ６０で構成される場合の合計料金とが比較される。そして、両合計料金のうち、より低額の料金（最も安価な料金）に対応する種類の接続要求伝達サーバ（たとえば、「時間課金サーバ」（詳細には複数の時間課金サーバ５０））が選択されればよい。

この実施形態では、時間課金サーバ５０として、ＸＭＰＰプロトコルを利用してトンネル接続要求を（より詳細には、ファイアウォールを通過させて）ゲートウエイに対して送信することが可能なサーバ（ＸＭＰＰサーバとも称する）を例示する。時間課金サーバ５０は、送信すべきデータが存在しない場合には、起動されていない状態（非起動状態あるいは非稼働状態とも称する）を有する。その後、プラットフォームサーバ８０が接続要求用通信ルートとして第１ルート（時間課金サーバ５０を経由するルート）を選択した場合には、プラットフォームサーバ８０は、非稼働状態（非起動状態）の時間課金サーバ５０を起動させる。ここでは、プラットフォームサーバ８０が時間課金サーバ５０の起動依頼をサービス起動用サーバ４０に対して送信し、当該起動依頼を受信したサービス起動用サーバ４０が時間課金サーバ５０を起動する。なお、これに限定されず、プラットフォームサーバ８０が時間課金サーバ５０を直接的に起動するようにしてもよい。

なお、ＸＭＰＰ接続の確立に際しては、（第６実施形態で示すようなロードバランサ（負荷分散サーバ）７０（後述）が存在しない場合には、）次のような動作が行われる。まず、ゲートウエイ３０は、時間課金サーバ５０とのＸＭＰＰ接続（メッセージセッション）が未だ確立されていない状態（未接続状態）において、当該ゲートウエイ３０に対応する時間課金サーバ５０に対して、ＸＭＰＰ接続要求を所定時間間隔（たとえば１分間隔）で送信する。時間課金サーバ５０が非稼働状態を有する場合、当該時間課金サーバ５０は当該ＸＭＰＰ接続要求を受信できないので、ゲートウエイ３０と当該時間課金サーバ５０との間の接続は確立されない。一方、時間課金サーバ５０が稼働状態を有する場合、当該時間課金サーバ５０は当該ＸＭＰＰ接続要求を受信し、ゲートウエイ３０と当該時間課金サーバ５０との間でＸＭＰＰ接続が確立される。

また、データ量課金サーバ６０として、ＭＱＴＴプロトコルを利用してトンネル接続要求をファイアウォールを通過してゲートウエイに対して送信することが可能なサーバ（ＭＱＴＴサーバとも称する）を例示する。データ量課金サーバ６０は、送信すべきデータが存在しない場合でも起動されている状態（起動状態あるいは稼働状態とも称する）を有する。この稼働状態においては、ＭＱＴＴプロトコルによるメッセージセッション（常時接続）がデータ量課金サーバ６０と各ゲートウエイ３０との間に確立されている。ただし、このメッセージセッションが確立されただけでは、実質的なデータ送信は未だ行われておらず、実質的な課金は行われない。また、当該メッセージセッションを利用して、トンネル接続要求がデータ量課金サーバ６０を経由してゲートウエイ３０へと送信される際に、当該トンネル接続要求のデータ量に応じた料金が課される。

なお、ここでは、時間課金サーバ５０とデータ量課金サーバ６０とにおいて、互いに異なるプロトコルを用いてトンネル接続要求が送信される。具体的には、時間課金サーバ５０ではＸＭＰＰプロトコルが用いられ、データ量課金サーバ６０ではＭＱＴＴプロトコルが用いられる。ただし、これに限定されず、時間課金サーバ５０とデータ量課金サーバ６０とにおいて同じプロトコルを用いて（たとえば、両サーバ５０，６０ともにＸＭＰＰプロトコルを用いて）トンネル接続要求が送信されてもよい。

＜１−６．詳細動作＞
図４は、通信システム１の初期状態を示す図である。また、図５は、第１実施形態のプラットフォームサーバ８０の動作を示すフローチャートである。これらの図等を参照しながら、第１実施形態の動作について更に詳細に説明する。

図４は、或る時点ｔ０における通信システム１の状態（初期状態あるいはアクセス要求受信前の状態とも称する）を示している。時点ｔ０においては、時間課金サーバ５０は非稼働状態を有しており、時間課金サーバ５０に関する料金は発生していない。また、データ量課金サーバ６０は稼働状態を有するものの、データ量課金サーバ６０に関する料金も発生していない。

第１実施形態では、各デバイス１０には、それぞれ、対応するゲートウエイ３０が予め定められているとともに、各ゲートウエイ３０にも、それぞれ、対応する時間課金サーバ５０が予め定められている。したがって、各デバイス１０には、それぞれ、対応する時間課金サーバ５０が予め定められている。プラットフォームサーバ８０は、このような対応関係の情報を予め格納しているものとする。

各ゲートウエイ３０は、対応する時間課金サーバ５０の情報（時間課金サーバ５０のＩＰアドレス等）を格納しており、当該対応する時間課金サーバ５０にアクセスすることが可能である。具体的には、ゲートウエイ３０は、時間課金サーバ５０との接続が未だ確立されていない状態（未接続状態）においては、当該ゲートウエイ３０に対応する時間課金サーバ５０に対して、接続要求を所定時間間隔（たとえば１分間隔）で送信している。ただし、時間課金サーバ５０が非稼働状態を有する場合、当該時間課金サーバ５０は当該接続要求を受信できないので、ゲートウエイ３０と当該時間課金サーバ５０との間の接続は確立されない。

このような通常状態（図４）において、プラットフォームサーバ８０は、アクセス要求を或るクラウドサーバ９０から受信する（ステップＳ１１（図５））。アクセス要求には、依頼元のクラウドサーバ９０の情報、およびデバイスリスト３００（図６参照）が含まれている。図６に示されるように、デバイスリスト３００には、通信対象として指定されるデバイス（通信対象デバイス）のデバイスＩＤ、アクセス要求の種類（「セキュリティ脆弱性対策のファームウエア更新指示」、「（非セキュリティ対策の）ファームウエア更新指示」、「ログアップロード指示」、...）等が記述されている。当該アクセス要求に含まれるデバイスＩＤの数を計数することによって、通信対象デバイスの数が算出され得る。このように、アクセス要求には、通信態様情報（当該アクセス要求にて通信対象として指定された通信対象デバイスの数など）が含まれている。

クラウドサーバ９０からのアクセス要求を受信したプラットフォームサーバ８０は、当該アクセス要求に応じて、複数の種類の通信ルートの中から選択される接続要求用通信ルートを介して、トンネル接続要求を各通信対象ゲートウエイに対して送信する処理（送信処理）を開始する。第１実施形態では、送信ルートの選択処理（ステップＳ２３（図５）等）および送信処理（ステップＳ２４，Ｓ２８）等が、一のアクセス要求の受信に応答して直ちに開始される。

具体的には、クラウドサーバ９０からのアクセス要求を受信したプラットフォームサーバ８０は、当該アクセス要求の通信態様情報（当該アクセス要求にて指定された通信対象デバイスの数など）に基づいて、時間課金サーバ５０とデータ量課金サーバ６０との中から、一の種類の非定額課金サーバ（従量制課金サーバ）を選択する処理等を実行する。

より詳細には、まず、プラットフォームサーバ８０は、時間課金サーバ５０の利用料金を算出する（ステップＳ２１）とともに、データ量課金サーバ６０の利用料金を算出する（ステップＳ２２）。詳細には、ステップＳ２１では、当該アクセス要求にて指定された通信対象デバイスに関するトンネル接続要求を時間課金サーバ５０経由の第１ルートで送信する場合の料金が算出される。ステップＳ２２では、当該アクセス要求にて指定された通信対象デバイスに関するトンネル接続要求をデータ量課金サーバ６０経由の第２ルートで送信する場合の料金が算出される。その後、ステップＳ２３では、両料金が比較され、比較結果に基づく選択処理（通信ルート選択処理）および分岐処理が実行される。なお、通信ルート選択処理は、アクセス要求の通信態様情報に基づき、通信対象デバイスに関する接続要求用通信ルート（詳細には、当該通信対象デバイスに対応するゲートウエイとの接続要求用通信ルート）を複数の種類の通信ルートの中から選択する処理である。その後、プラットフォームサーバ８０は、トンネル接続要求を、複数の種類の通信ルートの中から選択された接続要求用通信ルートを介して、各通信対象デバイスに対応する各通信対象ゲートウエイに対して送信する。

たとえば、データ量課金サーバ６０の料金が時間課金サーバ５０の料金よりも安い場合には、データ量課金サーバ６０が接続要求伝達サーバとして選択（決定）される。換言すれば、複数の種類の通信ルートの中から、第２ルートが接続要求用通信ルートとして選択（決定）される。そして、ステップＳ２４にて、プラットフォームサーバ８０は、トンネル接続要求をデータ量課金サーバ６０を経由して、各通信対象デバイス１０に対応する各ゲートウエイ（対応ゲートウエイ）３０に送信する（図７参照）。図７では、各通信対象デバイス１０に関するトンネル接続要求がデータ量課金サーバ６０を経由して各対応ゲートウエイ３０に送信される様子が示されている。

一方、時間課金サーバ５０の料金がデータ量課金サーバ６０の料金よりも安い場合には、時間課金サーバ５０が接続要求伝達サーバとして選択（決定）される。換言すれば、複数の種類の通信ルートの中から、第１ルートが接続要求用通信ルートとして選択（決定）される。そして、ステップＳ２６（図５）に進む。ステップＳ２６では、プラットフォームサーバ８０は、各対応ゲートウエイに対応する時間課金サーバ５０を起動すべき旨の起動依頼を、サービス起動用サーバ４０に対して送出する（図８も参照）。サービス起動用サーバ４０は、当該起動依頼に基づいて１又は複数の時間課金サーバ５０（図８では１つの時間課金サーバ５０）に対して、起動指令を送信し、当該１又は複数の時間課金サーバ５０を起動する。当該起動指令に応じて当該１又は複数の時間課金サーバ５０が稼働状態に遷移する（図８参照）。

上述のように、各ゲートウエイ３０は、時間課金サーバ５０との接続が未だ確立されていない状態（未接続状態）においては、当該ゲートウエイ３０に対応する時間課金サーバ５０に対して、接続要求を所定時間間隔（たとえば１分間隔）で送信している（図９参照）。時間課金サーバ５０が稼働状態を有する場合、当該時間課金サーバ５０は当該接続要求を受信し、各ゲートウエイ３０と当該時間課金サーバ５０との間で各ＸＭＰＰ接続が確立される（図１０参照）。また、各時間課金サーバ５０は、当該ＸＭＰＰ接続が確立された旨をプラットフォームサーバ８０に送信する。

そして、プラットフォームサーバ８０は、当該ＸＭＰＰ接続を利用してトンネル接続要求を各時間課金サーバ５０を経由して各ゲートウエイ３０に送信する処理を開始する（ステップＳ２８）。換言すれば、プラットフォームサーバ８０は、各ゲートウエイ３０と、起動した時間課金サーバ５０との間の第１ルートを経由して、トンネル接続要求を各通信対象ゲートウエイに送信する処理（図１１参照）を開始する。図１１では、各通信対象デバイス１０に関するトンネル接続要求が時間課金サーバ５０を経由して各対応ゲートウエイ３０に送信される様子が示されている。

その後、各ゲートウエイ（通信対象ゲートウエイとも称する）は、時間課金サーバ５０あるいはデータ量課金サーバ６０を経由してトンネル接続要求を受信すると、当該トンネル接続要求に基づきクラウドサーバ９０との間でトンネル接続を確立する。

そして、各通信対象ゲートウエイ３０は、確立された当該トンネル接続を利用して、アクセス要求の送信元のクラウドサーバ９０と当該各通信対象ゲートウエイに対応する各デバイスとの通信を中継する。

以上のような動作によれば、プラットフォームサーバ８０は、クラウドサーバ９０からのアクセス要求にて指定された各通信対象デバイスに関するトンネル接続要求（メッセージ）を、非定額課金体系で運用されるサーバと各通信対象デバイスに対応する各通信対象ゲートウエイとの間で確立されたメッセージセッションを介して、各通信対象ゲートウエイ３０に送信する。端的に言えば、トンネル接続要求は、非定額課金体系で運用されるサーバを接続要求伝達サーバ（メッセージ伝達サーバ）として利用して各通信対象ゲートウエイ３０に送信される。したがって、固定運用サーバ（購入されて運用されるサーバ或いは定額課金体系（固定課金制）で貸与されて運用されるサーバ等）を利用してトンネル接続要求が各通信対象ゲートウエイ３０に送信される場合（換言すれば、メッセージをファイアウォール越しに伝達するためのメッセージ伝達サーバが常に固定的な運用費用を発生させる場合）に比べて、通信システム１の運用コスト（特に接続要求伝達サーバの運用コスト）を低減することが可能である。

また、プラットフォームサーバ８０は、互いに異なる種類の非定額課金体系で運用される複数の種類のサーバであってその相互間における課金金額の大小関係が通信態様（メッセージ数等）に応じて変更され得る複数の種類のサーバ５０，６０の中から、アクセス要求の通信態様情報に基づき、接続要求伝達サーバを決定する。換言すれば、プラットフォームサーバ８０は、クラウドサーバ９０からのアクセス要求にて指定された通信対象デバイスに関する接続要求用通信ルート（メッセージ送信用通信ルート）を、複数の種類の通信ルートの中から、アクセス要求の通信態様情報に基づき選択する。詳細には、複数の種類のサーバ５０，６０のうちの時間課金サーバ５０を経由する第１ルートと、当該複数の種類のサーバのうちのデータ量課金サーバ６０のサーバを経由する第２ルートとの中から、その利用料金が最も安価なルートが選択される。端的に言えば、アクセス要求にて指定された通信対象デバイスの数に基づき、２種類のサーバのうち、より安価なサーバが選択される。したがって、通信システム１の運用コストを更に抑制することが可能である。

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

上記第１実施形態では、プラットフォームサーバ８０は、一のアクセス要求の受信に応答して通信ルート選択処理（ステップＳ２１〜Ｓ２３）（図４）を直ちに実行するとともに、選択された接続要求用通信ルートを介してトンネル接続要求を送信する処理（ステップＳ２４，Ｓ２８）を直ちに開始しているが、これに限定されない。

たとえば、プラットフォームサーバ８０は、一のアクセス要求の受信時点から所定期間Ｔ２（たとえば１２時間）が経過するまで待った後に、当該所定期間内に更に受け付けられた別のアクセス要求をも含む複数のアクセス要求に含まれる複数の通信対象デバイスに関する通信ルート選択処理等を実行するようにしてもよい。詳細には、当該複数のアクセス要求にて通信対象として指定された複数の通信対象デバイスに関する接続要求用通信ルートが、当該複数のアクセス要求の通信態様情報に基づき選択されてもよい。そして、選択された接続要求用通信ルートを介して、当該複数の通信対象デバイスに対応する各通信対象ゲートウエイに対してトンネル接続要求を送信する処理が開始されるようにしてもよい。これによれば、より多数の通信対象デバイスに関するトンネル接続要求を伝達するための接続要求伝達サーバを、より適切に決定することが可能である。特に、より多数のトンネル接続要求を纏めて送信することによって、利用料金を抑制することが可能になる。換言すれば、通信システム１の運用コストをさらに抑制することが可能である。

第２実施形態では、このような改変例について説明する。

図１３は、第２実施形態に係るプラットフォームサーバ８０の動作を示すフローチャートである。

図５（第１実施形態に係る動作を示すフローチャート）と比較すると判るように、図１３においては、ステップＳ１２，Ｓ１４，Ｓ１５が追加されている。

プラットフォームサーバ８０は、クラウドサーバ９０からの一のアクセス要求をステップＳ１１にて受信（時刻ｔ１）した後、ステップＳ１２，Ｓ１４の待機ループにて所定期間Ｔ２（たとえば１２時間）が経過するまで待機する。また、この待機期間Ｔ２において更に別のアクセス要求が受信されると、ステップＳ１４からステップＳ１５に進む。ステップＳ１５では、追加受信されたアクセス要求にて通信対象として指定されたデバイスを通信対象デバイスに追加する処理が実行される。

その後、一のアクセス要求の受信時点ｔ１から所定期間Ｔ２が経過すると、ステップＳ２１以降に進む。ステップＳ２１〜Ｓ２３では、追加されたデバイスを含む通信対象デバイスに関する接続要求用通信ルートの選択処理が実行される。

その後、第１実施形態と同様に、ステップＳ２４の処理、あるいはステップＳ２６，Ｓ２８の処理が、ステップＳ２３での選択結果に応じて実行される。

このような動作によれば、より多数の通信対象デバイスに関するトンネル接続要求を伝達するための接続要求伝達サーバを、より適切に決定することが可能である。具体的には、複数のアクセス要求に関する処理を纏めて実行することによって通信頻度を高めることが可能である。比較的多数のトンネル接続要求を纏めて（集中的に）送信することによれば、同じ数のトンネル接続要求を散発的に送信する場合に比べて、通信システム１の運用コストをさらに抑制することが可能である。例えば、短時間の間に、少数の通信対象デバイスを指定するアクセス要求を複数受信した場合、仮に個々のアクセス要求について上記両料金を算出すると第２ルート（データ量課金サーバ経由を経由するルート）の方が低額と判断される状況であったとしても、当該複数のアクセス要求をまとめて上記両料金を算出すると通信対象デバイスの総数（当該複数のアクセス要求をまとめることによって増大したデバイス総数）によっては第１ルート（時間課金サーバを経由するルート）の方が低額になることがある。本実施形態では、所定時間Ｔ２の期間に受信したアクセス要求をまとめることにより、上記のような場合に、低額な第１ルートが選択されるようになる。

＜第２実施形態の変形例＞
上記第２実施形態では、所定期間Ｔ２として、全てのアクセス要求に対して同じ値が設定されているが、これに限定されない。アクセス要求の種類に応じた所定期間Ｔ２が、アクセス要求ごとに設定されてもよい。たとえば、所定期間Ｔ２は、アクセス要求の種類の緊急度合いに応じた長さに変更（設定）されてもよい。

図１４は、このような変形例に関する動作を示すフローチャートである。図１３と比較すると判るように、ステップＳ１２ｂにおいて、緊急度合いに応じた長さを有する期間が所定期間Ｔ２として設定され且つ当該所定期間Ｔ２の経過の有無が判定されている。

図１５は、アクセス要求の種類と所定期間（待機期間）Ｔ２との関係を予め規定したデータテーブル３２０を示す図である。当該データテーブル３２０は、プラットフォームサーバ８０内に格納される。

受信されたアクセス要求の種類と当該データテーブル３２０とに基づいて、各アクセス要求向けの待機期間Ｔ２が決定される。

たとえば、アクセス種類「セキュリティ脆弱性対策のファームウエア更新指示」のアクセス要求は、比較的高い緊急度を有すると判断され、その待機期間Ｔ２は「１０分」（比較的短い期間）に設定される。逆に、アクセス種類「ログアップロード指示」（デバイス１０内のログデータをクラウドサーバ９０にアップロードすべき旨の指示）のアクセス要求は、比較的低い緊急度を有すると判断され、その待機期間Ｔ２は「２４時間」（比較的長い期間）に設定される。このように、各アクセス要求の緊急度に応じて、待機期間Ｔ２の長さが決定される。詳細には、各アクセス要求に関する待機期間Ｔ２は、当該アクセス要求の緊急度合いが高い程、短い時間に変更される。

そして、当該待機期間Ｔ２の経過の有無がステップＳ１２ｂにて判定される。待機期間Ｔ２が経過した旨が判定されると、ステップＳ２１以降に進み、第２実施形態と同様の動作が実行されればよい。

なお、ステップＳ１２ｂ，Ｓ１４の待機ループで別のアクセス要求が追加受信された場合には、追加受信された当該アクセス要求についての所定期間Ｔ２の経過の有無もがステップＳ１２ｂにて判定されることが好ましい。そして、いずれかのアクセス要求の受信時点からそのアクセス要求に対応する待機期間Ｔ２が経過した時点で、ステップＳ２１以降に進むようにすればよい。

また、ここでは、最も短い待機期間Ｔ２は「１０分」に設定されているが、これに限定されず、最も短い待機期間Ｔ２は「０分」（換言すれば、「即時実行すべき旨」）に設定されてもよい。

また、第２実施形態およびその変形例では、プラットフォームサーバ８０は、単一のクラウドサーバ９０からのアクセス要求を受信しているが、これに限定されず、プラットフォームサーバ８０は、複数のクラウドサーバ９０からのアクセス要求を受信してもよい。そして、当該複数のクラウドサーバ９０からの複数のアクセス要求にて指定された複数の通信対象デバイスに関する接続要求用通信ルートが、当該複数のアクセス要求の通信態様情報に基づき選択されるようにしてもよい。

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

この第３実施形態では、プラットフォームサーバ８０は、一のアクセス要求を含む所定数Ｍ１（たとえば１０個）のアクセス要求が受信された時点で、当該所定数Ｍ１のアクセス要求に含まれる複数の通信対象デバイスに関する接続要求用通信ルートを、所定数Ｍ１のアクセス要求の通信態様情報に基づき選択する。詳細には、当該所定数Ｍ１のアクセス要求にて通信対象として指定された複数の通信対象デバイスに関する接続要求用通信ルートが、当該所定数Ｍ１のアクセス要求の通信態様情報に基づき選択される。そして、選択された接続要求用通信ルートを介して、当該複数の通信対象デバイスに対応する各通信対象ゲートウエイに対してトンネル接続要求を送信する処理が開始される。これによれば、より多数の通信対象デバイスに関するトンネル接続要求を伝達するための接続要求伝達サーバを、より適切に決定することが可能である。特に、より多数のトンネル接続要求を纏めて送信することによって、利用料金を抑制することが可能になる。換言すれば、通信システム１の運用コストをさらに抑制することが可能である。

第３実施形態では、このような改変例について説明する。

図１６は、第３実施形態に係るプラットフォームサーバ８０の動作を示すフローチャートである。

図１６においては、図５（第１実施形態に係る動作を示すフローチャート）と比較すると判るように、ステップＳ１３，Ｓ１４，Ｓ１５が追加されている。

プラットフォームサーバ８０は、クラウドサーバ９０からの一のアクセス要求をステップＳ１１にて受信した後、ステップＳ１３，Ｓ１４の待機ループにて、アクセス要求の受信数が所定数Ｍ１（たとえば１０個）に到達するまで待機する。また、この待機期間において更に別のアクセス要求が受信されると、ステップＳ１４からステップＳ１５に進む。ステップＳ１５では、追加受信されたアクセス要求にて通信対象として指定されたデバイスを通信対象デバイスに追加する処理が実行される。

その後、所定数Ｍ１のアクセス要求の受信数が所定値Ｍに到達すると、ステップＳ２１以降に進む。ステップＳ２１〜Ｓ２３では、追加されたデバイスを含む通信対象デバイスに関する接続要求用通信ルートの選択処理が実行される。

その後、第１実施形態と同様に、ステップＳ２４の処理、あるいはステップＳ２６，Ｓ２８の処理が、ステップＳ２３での選択結果に応じて実行される。

このような動作によれば、複数のアクセス要求に関する処理を纏めて実行することによって、第２実施形態と同様の効果を得ることが可能である。

＜第３実施形態の変形例＞
上記第３実施形態では、所定数Ｍ１のアクセス要求数に関して、接続要求用通信ルートの選択処理が纏めて実行されているが、これに限定されない。少なくとも１つのアクセス要求にて通信対象として指定された所定数Ｍ２（たとえば１０００個）の通信対象デバイスに関して、接続要求用通信ルートの選択処理が纏めて実行されてもよい。

具体的には、プラットフォームサーバ８０は、所定数以上の通信対象デバイスに対する少なくとも１つのアクセス要求が受信された時点で、当該少なくとも１つのアクセス要求にて通信対象として指定されている複数の通信対象デバイスに関する接続要求用通信ルートの選択処理を実行してもよい。換言すれば、受信された１又は複数のアクセス要求にて通信対象として指定されている複数の通信対象デバイスの合計数（指定デバイス総数）が所定数Ｍ２以上であるときに、当該複数の通信対象デバイスに関する接続要求用通信ルートの選択処理が実行されてもよい。

＜第３実施形態の他の変形例＞
また、第３実施形態の態様は、第２実施形態の態様と組み合わせて実行されてもよい。具体的には、図１７に示されるように、待機期間Ｔ２の経過時点とアクセス要求数の所定数Ｍ１への到達時点とのうちの早い方の時点で、それまでに受信されたアクセス要求にて通信対象として指定されている複数の通信対象デバイスに関する接続要求用通信ルートの選択処理が実行されてもよい。図１７では、ステップＳ１２ｂ，Ｓ１３，Ｓ１４の待機ループが示されている。図１７に示されるように、ステップＳ１２ｂにて所定期間Ｔ２の経過が判定されるか或いはステップＳ１３にてアクセス要求数が所定値Ｍ１に到達した時点で、接続要求用通信ルートの選択処理等が実行されてもよい。なお、ステップＳ１３においては、アクセス要求の受信数が所定数Ｍ１に到達したか否かが判定されてもよく、および／または、指定デバイス総数が所定数Ｍ２に到達したか否かが判定されてもよい。

＜４．第４実施形態＞
第４実施形態は、第１実施形態〜第３実施形態等の変形例である。以下では、第１実施形態との相違点を中心に説明する。

上記各実施形態では、プラットフォームサーバ８０は、少なくとも１つのアクセス要求の受信に応じて通信ルート選択処理（ステップＳ２１〜Ｓ２３）を実行するとともに、選択された接続要求用通信ルートを介してトンネル接続要求を送信する処理（ステップＳ２４，Ｓ２８）を開始している。

その後、当該少なくとも１つのアクセス要求（第１のアクセス要求とも称する）に関する全てのトンネル接続要求の送信処理が完了するまでに新たなアクセス要求（第２のアクセス要求とも称する）が更に受信される場合には、当該新たなアクセス要求の受信時点で送信未完了のトンネル接続要求に対応する通信対象デバイスをも考慮して、通信ルート選択処理が再び実行されてもよい。具体的には、第１のアクセス要求における少なくとも１つの通信対象デバイスのうち「未完了デバイス」と第２のアクセス要求における通信対象デバイスとに関する接続要求用通信ルートが、第１のアクセス要求の通信態様情報と第２のアクセス要求の通信態様情報とに基づき、複数の種類の通信ルートの中から選択されてもよい。ここで、「未完了デバイス」は、第１のアクセス要求にて通信対象として指定されていた通信対象デバイスのうち、当該第１のアクセス要求に応じたトンネル接続要求の送信処理が未完了の通信対象デバイスである。

第４実施形態では、このような態様について図１８を参照しながら説明する。図１８は、第４実施形態に係るプラットフォームサーバ８０の動作を示すフローチャートである。

第１のアクセス要求（少なくとも１つのアクセス要求）に関する通信ルート選択処理が実行され（ステップＳ２１〜Ｓ２３）、トンネル接続要求が開始（ステップＳ２４，Ｓ２８）されると、新たなアクセス要求の待機処理（ステップＳ３１，Ｓ３２）が実行される。

ステップＳ３１，Ｓ３２の待機ループにおける待機中において、第１のアクセス要求にて指定された全ての通信対象デバイスに関するトンネル接続要求の送信が完了した旨がステップＳ３２で判定されると、図１８の処理は修了する。

一方、ステップＳ３１，Ｓ３２の待機ループにおける待機中において、第１のアクセス要求にて指定された全ての通信対象デバイスに関するトンネル接続要求の送信が完了するまでに、新たなアクセス要求がプラットフォームサーバ８０にて受信された際には、ステップＳ３１からステップＳ３３に進む。ステップＳ３３では、通信ルートの再決定処理を実行する旨を決定し、ステップＳ２１に戻る。

ステップＳ２１に戻った後の再決定処理（Ｓ２１〜Ｓ２３）（再選択処理とも称する）では、第１のアクセス要求にて指定されていた全ての通信対象デバイスのうち「未完了デバイス」（残余の通信対象デバイスと称する）と第２のアクセス要求にて指定されている全ての通信対象デバイスとに関する接続要求用通信ルートが、第１のアクセス要求の通信態様情報と第２のアクセス要求の通信態様情報とに基づき、複数の種類の通信ルートの中から選択される。

その後のステップＳ２４あるいはステップＳ２８では、複数の種類の通信ルートの中から再決定処理にて選択された接続要求用通信ルートを介して、未完了デバイスと第２のアクセス要求における通信対象デバイスとにそれぞれ対応する通信対象ゲートウエイに対してトンネル接続要求を送信する送信処理が開始される。

上記再決定処理においては、たとえば、第１のアクセス要求にて通信対象として指定されていた１０００台の通信対象デバイスのうち８５０台が未完了デバイスであるときには、第２のアクセス要求にて指定されている３台の通信対象デバイと合わせて、８５３台の通信対象デバイスが存在する旨が判定される。そして、当該８５３台の通信対象デバイスに関するトンネル接続要求を送信するための最適な通信ルートが選択される。

より詳細には、「１０００台」の通信対象デバイスに関する接続要求用通信ルートとして、時間課金サーバ５０を経由する第１ルートが選択されていた場合、再決定処理において、「８５３台」の通信対象デバイスに関する接続要求用通信ルートとして、当該時間課金サーバ５０を経由する第１ルートが引き続き選択される。これによれば、より多数の通信対象デバイスを纏めて処理することによって、運用コストをさらに低減することが可能である。

＜５．第５実施形態＞
上記各実施形態では、通信システム１は、トンネル接続要求の通信用のサーバ（接続要求伝達サーバ）として上述の複数の種類のサーバを選択的に利用可能なデバイス（換言すれば、上述の複数の通信ルートを選択的に利用可能なデバイス）のみが、アクセス要求にて通信対象デバイスとして指定される態様が例示されている。ただし、これに限定されず、比較例に係る固定運用サーバ（５０ｘ等）のみをトンネル接続要求の通信用のサーバとして利用可能なデバイスもが、アクセス要求にて通信対象デバイスとして指定されてもよい。

第５実施形態では、デバイス１０として２つのタイプのデバイスが存在する。具体的には、「第１タイプデバイス」（接続要求伝達サーバ（トンネル接続要求の通信用のサーバ）として上述の複数の種類の非定額課金サーバ（５０，６０）を選択的に利用可能なデバイス）と、「第２タイプデバイス」（固定運用サーバ（５０ｘ等）のみを接続要求伝達サーバとして利用可能なデバイス）とが存在する。第２タイプデバイスは、比較例に係るデバイスに相当し「旧型デバイス」とも称される。一方、第１タイプデバイスは、上記各実施形態に係る思想を適用することが可能な新しいタイプのデバイスであり、「新型デバイス」とも称される。

図２０は、第５実施形態に係るプラットフォームサーバ８０の動作を示すフローチャートである。また、図２１は、第５実施形態に係る通信システム１の概略構成を示す図である。

図２１に示されるように、第５実施形態に係る通信システム１では、第１実施形態等と同様にデータ量課金サーバ６０および時間課金サーバ５０が設けられる。さらに、旧型デバイスに関する接続要求伝達サーバとして利用される固定運用サーバ１５０（ＸＭＰＰサーバ５０ｘ，５０ｙ等）も設けられる。

ここでは、時間課金サーバ５０および固定運用サーバ１５０は、いずれもＸＭＰＰサーバである。ただし、時間課金サーバ５０は時間課金制のサーバであり、通常時（非使用時）には、非稼働状態（非起動状態）を有している（図２１参照）。図２１では、時間課金サーバ５０を示す矩形が破線で表現されることによって、時間課金サーバ５０が非稼働状態を有していることが示されている。詳細には、第１ルートが接続要求用通信ルートとして選択されていない場合、時間課金サーバ５０は稼働していない。これに対して、第１ルートが接続要求用通信ルートとして選択された場合、時間課金サーバ５０は起動される。時間課金サーバ５０の起動後（起動完了後）において時間課金サーバ５０が稼働状態を有する場合、時間課金サーバ５０は新型デバイス（１０ａ，１０ｂ，１０ｃ等）に対応するゲートウエイ（新型対応ゲートウエイとも称する）（３０ａ，３０ｂ等）からの通信を許可する。一方、固定運用サーバ１５０は、常時、稼働状態を有している。固定運用サーバ１５０は、旧型デバイス（１０ｘ，１０ｙ等）に対応するゲートウエイ（旧型対応ゲートウエイとも称する）（３０ｘ，３０ｙ等）からの通信（ＸＭＰＰ接続要求を含む）を常に許可する。

旧型デバイス（１０ｘ，１０ｙ等）に関連（対応）付けられた各ゲートウエイ３０（３０ｘ，３０ｙ等）は、対応する固定運用サーバ１５０（ＸＭＰＰサーバ５０ｘ，５０ｙ等）との間に、ＸＭＰＰ接続を常時形成している。詳細には、まず各ゲートウエイ３０（３０ｘ，３０ｙ等）が、その起動時等において、対応する固定運用サーバ１５０との間にＸＭＰＰ接続を形成すべくＸＭＰＰ接続要求（「メッセージセッションの確立要求」とも称される）を当該固定運用サーバ１５０に送信する。当該固定運用サーバ１５０は常時稼働状態を有するので、固定運用サーバ１５０とゲートウエイ３０との間におけるＸＭＰＰ接続（メッセージセッション）が確立される（図２１）。プラットフォームサーバ８０は、固定運用サーバ１５０を経由して、旧型デバイスに関連付けられたゲートウエイ３０（３０ｘ，３０ｙ等）に対してＸＭＰＰプロトコルによるトンネル接続要求を送信することが可能である。

一方、新型デバイス（１０ａ，１０ｂ，１０ｃ等）に関連（対応）付けられた各ゲートウエイ３０（３０ａ，３０ｂ等）は、普段は（初期状態等においては）、対応する時間課金サーバ５０との間にＸＭＰＰ接続を形成していない。詳細には、各ゲートウエイ３０（３０ａ，３０ｂ等）が、対応する時間課金サーバ５０との間にＸＭＰＰ接続を形成すべくＸＭＰＰ接続要求を所定時間間隔で当該時間課金サーバ５０に送信しても、当該時間課金サーバ５０は稼働状態を有していないので、時間課金サーバ５０とゲートウエイ３０との間におけるＸＭＰＰ接続は確立されない（図２１）。

その後、後述するように、時間課金サーバ５０が新型デバイスに関する接続要求伝達サーバとして選択（決定）された場合、プラットフォームサーバ８０およびサービス起動用サーバ４０により時間課金サーバ５０が起動される。時間課金サーバ５０が起動され稼働状態に遷移する（図２３参照）と、新型デバイス１０と当該新型デバイス１０に対応する時間課金サーバ５０との間に常時接続（ＸＭＰＰ接続）が確立され、当該常時接続（メッセージセッション）がトンネル接続要求の通信用ルート（ファイアウォール通過用通信ルート）の一部として確保される。プラットフォームサーバ８０は、起動した時間課金サーバ５０を経由して（換言すれば、ＸＭＰＰ接続を利用して）、新型デバイスに関連付けられたゲートウエイ３０に対してＸＭＰＰプロトコルによるトンネル接続要求を送信（図２４参照）することが可能である。

なお、データ量課金サーバ６０は、上述のように常時稼働状態を有しており、プラットフォームサーバ８０は、データ量課金サーバ６０を経由して、新型デバイスに関連付けられたゲートウエイ３０に対してＭＱＴＴプロトコルによるトンネル接続要求を送信することも可能である。

次に図２０を参照しながら、第５実施形態の動作について説明する。

第５実施形態のステップＳ１１（Ｓ１１ｂ）においては、上記第１実施形態等と同様にしてアクセス要求（デバイスリスト３００を含む）が受信される。ただし、第５実施形態においては、図２５に示されるように、各デバイスのタイプ（旧型／新型）の情報もがデバイスリスト３００にて規定されているものとする。当該情報を利用することによって、各デバイスが新型デバイスであるか旧型デバイスであるかが容易に判別される。なお、これに限定されず、各デバイスのタイプ（旧型／新型）の情報は、プラットフォームサーバ８０内に予め格納されていてもよい。

ステップＳ１１ｂにおいて、プラットフォームサーバ８０は、アクセス要求のデバイスリスト３００（図２５参照）にて通信対象として指定された複数の通信対象デバイスの中から、新型デバイスを抽出する。換言すれば、アクセス要求のデバイスリスト３００（図２５参照）にて通信対象として指定された複数の通信対象デバイスに旧型デバイスが含まれている場合、ステップＳ２１，Ｓ２２，Ｓ２３の処理における対象デバイスから、当該旧型デバイスが除外される。具体的には、新型デバイスと旧型デバイスとのうち新型デバイスのみを対象として（旧型デバイスを除外して）、通信対象デバイス数等が算出される。

たとえば、アクセス要求のデバイスリスト３００にて、１００個の旧型デバイスおよび７００個の新型デバイス（合計８００個のデバイス）が通信対象デバイスとして指定されている場合、新型デバイスの数「７００」個（合計デバイス数「８００」個から旧型デバイスの数「１００」個を差し引いた数に相当する個数）が、ステップＳ２１，Ｓ２２，Ｓ２３で利用されるデバイス（料金算定対象デバイスとも称する）の数として算出される。

そして、ステップＳ２１，Ｓ２２，Ｓ２３では、新型デバイスの数（たとえば、「７００」個）に応じた接続要求用通信ルートが選択される。

その後、第１実施形態と同様に、ステップＳ２４の処理、あるいはステップＳ２６，Ｓ２８の処理が、ステップＳ２３での選択結果に応じて実行される。

たとえば、データ量課金サーバ６０が新型デバイスに関する接続要求伝達サーバとして選択（決定）された場合、図２２に示されるように、プラットフォームサーバ８０は、データ量課金サーバ６０を経由して、新型デバイスに関連付けられたゲートウエイ３０（３０ａ，３０ｂ等）に対してＭＱＴＴプロトコルによるトンネル接続要求を送信する（ステップＳ２４）。なお、上述のように、データ量課金サーバ６０は、（時間課金サーバ５０とは異なり、）常時稼働状態を有している。

一方、時間課金サーバ５０が新型デバイスに関する接続要求伝達サーバとして選択（決定）された場合、まず図２３にも示されるように、プラットフォームサーバ８０は、（未だ起動されていなかった）時間課金サーバ５０を起動する（ステップＳ２６）。具体的には、プラットフォームサーバ８０は、時間課金サーバ５０の起動依頼をサービス起動用サーバ４０に対して送信し、当該起動依頼を受信したサービス起動用サーバ４０が時間課金サーバ５０を起動する。その後、起動した時間課金サーバ５０がゲートウエイ３０からのＸＭＰＰ接続要求を受信することによって、時間課金サーバ５０とゲートウエイ３０との間にメッセージセション（ＸＭＰＰ接続）が確立される。詳細には、ゲートウエイ３０は、時間課金サーバ５０に対して所定時間間隔でＸＭＰＰ接続要求を送信しており、当該ＸＭＰＰ接続要求が、起動後の時間課金サーバ５０によって受信されることによって、当該メッセージセション（ＸＭＰＰ接続）が確立される。時間課金サーバ５０の起動に応じて当該メッセージセッションが確立されると、プラットフォームサーバ８０は、当該メッセージセッションを利用して、新型デバイスに関連付けられたゲートウエイ３０（３０ａ，３０ｂ等）に対してＸＭＰＰプロトコルによるトンネル接続要求を送信する（ステップＳ２８）（図２４も参照）。

なお、図２０のフローチャートには示されていないが、各旧型デバイスに関しては、各旧型デバイス（１０ｘ，１０ｙ等）に対応する各ゲートウエイ（３０ｘ，３０ｙ等）と当該各ゲートウエイに対応する固定運用サーバ１５０との間に確立されているメッセージセッション（ＸＭＰＰ接続）を介して、トンネル接続要求がプラットフォームサーバ８０から当該各ゲートウエイへと送信される。詳細には、データ量課金サーバ６０が新型デバイスに関する接続要求伝達サーバとして選択（決定）された場合（図２２参照）と、時間課金サーバ５０が新型デバイスに関する接続要求伝達サーバとして選択（決定）された場合（図２４参照）とのいずれにおいても、旧型デバイスに関しては固定運用サーバ１５０が接続要求伝達サーバとして利用される。

以上のような動作によれば、新型デバイスと旧型デバイスとが混在する通信システム１において、各タイプのデバイスに関するトンネル接続要求を伝達するための接続要求伝達サーバを、より適切に決定することが可能である。

なお、第５実施形態に係る思想を第２〜第４実施形態等にそれぞれ適用してもよい。その場合、ステップＳ１１（図１３〜図１８等）およびステップＳ３１（図１８等）において、ステップＳ１１ｂ（図２０）と同様の動作（新型デバイスの抽出処理（換言すれば、旧型デバイスの除外処理））が行われればよい。そして、待機期間Ｔ２の長さ（第２実施形態等参照）および／またはデバイス数が所定数に到達したこと（第３実施形態等参照）等が、除外後のデバイス（新型デバイスのみ）に基づいて判定されればよい。

次述する第６実施形態に関しても同様であり、第６実施形態に係る思想を第２〜第４実施形態等にそれぞれ適用してもよい。

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

図２６は、第６実施形態に係るプラットフォームサーバ８０の動作を示すフローチャートである。また、図２７は、第６実施形態に係る通信システム１の概略構成を示す図である。

第６実施形態に係る通信システム１においても、新型デバイス（１０ａ，１０ｂ，１０ｃ等）と旧型デバイス（１０ｘ，１０ｙ等）とが混在している。ただし、第６実施形態においては、図２７に示されるように、管理用サーバ群２００は、ＸＭＰＰサーバに関する負荷分散サーバ７０をも備えている。負荷分散サーバ（ロードバランササーバあるいは単にロードバランサとも称する）７０は、複数の接続要求伝達サーバ（詳細には、複数のＸＭＰＰサーバ）の相互間における負荷分散処理を実行する装置である。なお、当該ロードバランサ（負荷分散サーバ）７０による負荷分散処理の対象装置（接続要求伝達サーバ）は、所定プロトコル（ここではＸＭＰＰ）によるメッセージセッションを各ゲートウエイとの間で確立してトンネル接続要求を伝達することが可能な装置である。

たとえば、ロードバランサ７０は、複数の固定運用サーバ１５０が稼働している状況において、各旧型対応ゲートウエイ（３０ｘ，３０ｙ等）と接続すべきＸＭＰＰサーバ（接続要求伝達サーバ）を、複数の固定運用サーバ１５０の中から割り当てる処理を実行する。また、ロードバランサ７０は、複数の時間課金サーバ５０が稼働している状況において、各新型対応ゲートウエイ（３０ａ，３０ｂ等）と接続すべきＸＭＰＰサーバを、複数の時間課金サーバ５０の中から割り当てる処理をも実行する。さらに、ロードバランサ７０は、１以上の固定運用サーバ１５０と１以上の時間課金サーバ５０とを含む複数のＸＭＰＰサーバが稼働している状況において、各新型対応ゲートウエイ（あるいは旧型対応ゲートウエイ）と接続すべきＸＭＰＰサーバを、複数のＸＭＰＰサーバの中から割り当てる処理をも実行する。

プラットフォームサーバ８０は、ＸＭＰＰサーバ（固定運用サーバ１５０および／または時間課金サーバ５０）に対する送信処理（トンネル接続要求の送信処理等）を、ロードバランサ７０を介して行う。また、各ゲートウエイ３０も、当該ＸＭＰＰサーバに対する送信処理（ＸＭＰＰ接続要求の送信処理等）を、ロードバランサ７０を介して行う。特に、ゲートウエイ３０からＸＭＰＰサーバに対する通信は、ロードバランサ７０のＩＰフィルタ（次述）によって制限される。

ロードバランサ７０には、複数のゲートウエイのそれぞれからの通信の許否を規定したＩＰフィルタ（パケットフィルタ）３５０（図２７参照）が設けられている。ＩＰフィルタ３５０には、初期状態において、旧型デバイスに対応するゲートウエイ（旧型対応ゲートウエイ）が「通信許可装置」として登録されており且つ新型デバイスに対応するゲートウエイ（新型対応ゲートウエイ）が「通信不許可装置」として登録されている。詳細には、旧型対応ゲートウエイのＩＰアドレスが「通信許可装置」のＩＰアドレスとして登録されており、新型対応ゲートウエイのＩＰアドレスが「通信不許可装置」のＩＰアドレスとして登録されている。このようなＩＰフィルタ３５０によるフィルタリング機能によって、初期状態（図２７参照）においては旧型対応ゲートウエイからの通信は許可され且つ新型対応ゲートウエイからの通信は許可されない。

この実施形態では、各ゲートウエイ３０は、ロードバランサ７０に対して、ＸＭＰＰサーバ（固定運用サーバ１５０あるいは時間課金サーバ５０）とのＸＭＰＰ接続の確立要求（ＸＭＰＰ接続要求）を（所定時間間隔で）送信する。ただし、上述のＩＰフィルタ３５０によるフィルタリング機能によって、初期状態においては旧型対応ゲートウエイからの通信は許可され且つ新型対応ゲートウエイからの通信は許可されない。特に、接続要求用通信ルートとして第１ルートが選択されていない場合、新型対応ゲートウエイ３０（３０ａ，３０ｂ等）からロードバランサ７０への通信は、許可されない。また、後述するように、接続要求用通信ルートとして第１ルートが選択されると、ＩＰフィルタ３５０が書き換えられ、新型対応ゲートウエイ３０（３０ａ，３０ｂ等）からロードバランサ７０への通信が許可される。なお、旧型デバイスに対応するゲートウエイ（旧型対応ゲートウエイ）からの通信は常に許可される。

旧型対応ゲートウエイからの通信は（常に）許可されるので、旧型対応ゲートウエイ３０（３０ｘ，３０ｙ等）からのＸＭＰＰ接続要求がロードバランサ７０によって（常に）受信される。そして、ロードバランサ７０は、当該ＸＭＰＰ接続要求に応じた割り当て先のＸＭＰＰサーバ（固定運用サーバ１５０等）を（負荷分散を図りつつ）決定し、当該ＸＭＰＰ接続要求を割り当て先のＸＭＰＰサーバに振り分ける。これに応じて、旧型対応ゲートウエイ３０と割り当て先のＸＭＰＰサーバとの間でＸＭＰＰ接続が確立される。このようにして、旧型対応ゲートウエイ３０は、ロードバランサ７０の管理下のいずれかのＸＭＰＰサーバとの間でメッセージセッションを確立することができる。なお、ロードバランサ７０は、旧型対応ゲートウエイ３０と当該旧型対応ゲートウエイ３０に対して割り当てたＸＭＰＰサーバとの対応関係を記憶しておく。

その後、プラットフォームサーバ８０がロードバランサ７０に対して旧型デバイスに関するトンネル接続要求を送信すると、当該トンネル接続要求は、或るメッセージセッションを経由して、当該旧型デバイスに対応するゲートウエイ（旧型対応ゲートウエイ）３０に伝達される。この際、ロードバランサ７０は、記憶されていた対応関係（旧型対応ゲートウエイ３０とその割り当て先のＸＭＰＰサーバとの対応関係）に基づいて、トンネル接続要求を、旧型対応ゲートウエイ（旧型デバイスに対応するゲートウエイ）に対する割り当て先のＸＭＰＰサーバに振り分ける。これによって、当該トンネル接続要求は、旧型対応ゲートウエイと当該割り当て先のＸＭＰＰサーバとの間に形成されたメッセージセッションを経由して、旧型対応ゲートウエイに送信される。

一方、新型対応ゲートウエイ（３０ａ，３０ｂ等）からのＸＭＰＰ接続要求が、初期状態においてロードバランサ７０に対して送信される場合、当該ＸＭＰＰ接続要求は、ロードバランサ７０のＩＰフィルタ３５０でブロックされる。したがって、新型対応ゲートウエイ３０は、ロードバランサ７０の管理下のいずれのＸＭＰＰサーバ（時間課金サーバ５０を含む）との間でもメッセージセッションを確立することができない。その結果、この初期状態においては、新型デバイスに関するトンネル接続要求は、データ量課金サーバ６０と新型デバイスに対応するゲートウエイ（新型対応ゲートウエイ）３０との間のメッセージセッションを介してのみ送信され得る。すなわち、複数の種類の通信ルートのうち、（第１ルートは選択され得ず）第２ルートのみが選択され得る。なお、後述するように、ＩＰフィルタ３５０の内容が変更されれば、新型対応ゲートウエイ３０もロードバランサ７０の管理下のいずれかのＸＭＰＰサーバとの間でメッセージセッションを確立することが可能になる。

次に図２６を参照しながら、第６実施形態の動作について説明する。図２６においては、ステップＳ２６ｂ，Ｓ２７の動作が図２０（第５実施形態）と相違する。

ステップＳ２１〜Ｓ２３において新型デバイスに関する接続要求伝達サーバとして時間課金サーバ５０が選択された場合、ステップＳ２３からステップＳ２６（Ｓ２６ｂ）に進む。ここでは、新型デバイスに関する接続要求伝達サーバとして２台のＸＭＰＰサーバを使用すること（換言すれば、増設すべきＸＭＰＰサーバの台数）がステップＳ２１〜Ｓ２３にて併せて決定されているものとする。たとえば、６００個の新型デバイスに関するメッセージを送信すべき場合において、全てのメッセージを３秒以内に処理できることが更なる条件として設定されているときには、１台あたり１００メッセージ／秒の能力を有するＸＭＰＰサーバを２台設けることが決定される。

ステップＳ２６ｂでは、プラットフォームサーバ８０は、アクセス要求にて通信対象として指定された新型デバイスに対応するゲートウエイ（対応ゲートウエイとも称する）との通信に用いる接続要求伝達サーバをサービス起動用サーバ４０を介して増設する。具体的には、プラットフォームサーバ８０は、時間課金サーバ５０の増設依頼をサービス起動用サーバ４０に送信する（図２９も参照）。詳細には、時間課金サーバ５０を起動すべき旨と、起動すべき時間課金サーバ５０の台数（料金算出の際に併せて決定された増設台数）とが、サービス起動用サーバ４０に伝達される。サービス起動用サーバ４０は、当該増設依頼に基づいて時間課金サーバ５０を起動する（図２９も参照）。起動された時間課金サーバ５０は、ロードバランサ７０による割り当て処理（負荷分散処理）の対象装置になる。

さらにステップＳ２７において、プラットフォームサーバ８０は、ロードバランサ７０のＩＰフィルタ３５０において対応ゲートウエイのＩＰアドレスを通信許可対象アドレスとして追加登録する処理を実行する。この追加登録処理は、サービス起動用サーバ４０を介して実行される。

具体的には、プラットフォームサーバ８０は、ロードバランサ７０内のＩＰフィルタ３５０の変更依頼（追加対象のＩＰアドレス等を含む）をサービス起動用サーバ４０に送信する（図２９も参照）。サービス起動用サーバ４０は、当該変更依頼に応じてロードバランサ７０に変更指令を送出し、ロードバランサ７０内のＩＰフィルタ３５０の内容を変更する。具体的には、通信対象デバイスでもある新型デバイスに対応するゲートウエイのＩＰアドレスを、ＩＰフィルタ３５０を通過させるアドレス（「通信許可装置」のＩＰアドレス）として追加登録する。換言すれば、デバイスリスト３００内の新型デバイスに対応するゲートウエイが、通信不許可装置から通信許可装置に変更される。

この登録変更（ＩＰフィルタ更新）に応じて、複数のゲートウエイ３０のうち、当該新型デバイス（１０ａ，１０ｂ，１０ｃ等）に対応するゲートウエイ３０（新型対応ゲートウエイ３０ａ，３０ｂ等）から送信されてくるＸＭＰＰ接続要求がＩＰフィルタ３５０を通過することが可能になるので、ロードバランサ７０は、当該ＸＭＰＰ接続要求を受信することが可能になる（図３０参照）。ロードバランサ７０は、当該ＸＭＰＰ接続要求を受信すると、当該ＸＭＰＰ接続要求に応じた割り当て先のＸＭＰＰサーバ（新型対応ゲートウエイに割り当てるべきＸＭＰＰサーバ）（時間課金サーバ５０等）を決定する。そして、ロードバランサ７０は、当該ＸＭＰＰ接続要求を割り当て先のＸＭＰＰサーバに振り分ける。これに応じて、新型対応ゲートウエイ３０と割り当て先のＸＭＰＰサーバ（対応サーバ）との間でＸＭＰＰ接続が確立される（図３０参照）。

このようにして、新型対応ゲートウエイ３０は、ロードバランサ７０の管理下のいずれかのＸＭＰＰサーバ（図３０では２台の時間課金サーバ５０）との間でメッセージセッション（ＸＭＰＰ接続）を確立する。なお、ロードバランサ７０は、新型対応ゲートウエイ３０と当該新型対応ゲートウエイ３０に対して割り当てたＸＭＰＰサーバとの対応関係を記憶しておく。なお、図３０では、第５実施形態と同様の対応関係が示されているが、実際には、第５実施形態とは異なる種々の対応関係が構築され得る。

その後、ステップＳ２８において、プラットフォームサーバ８０は、ロードバランサ７０に対して新型デバイスに関するトンネル接続要求を送信する処理（詳細には、新型デバイスに対応するゲートウエイに対して、トンネル接続要求を送信する処理）を開始する。当該トンネル接続要求は、新型対応ゲートウエイ３０とロードバランサ７０の管理下のいずれかのＸＭＰＰサーバ（図３０および図３１では２台の時間課金サーバ５０）との間で確立されているメッセージセッションを介して、当該新型デバイスに対応するゲートウエイ（新型対応ゲートウエイ）３０に送信（伝達）される。この際、ロードバランサ７０は、記憶されていた対応関係（新型対応ゲートウエイ３０とその割り当て先のＸＭＰＰサーバとの対応関係）に基づいて、各トンネル接続要求を、各新型対応ゲートウエイに対する割り当て先のＸＭＰＰサーバに振り分ける。これによって、各トンネル接続要求は、各新型対応ゲートウエイとその割り当て先のＸＭＰＰサーバとの間に形成されたメッセージセッション（ＸＭＰＰ接続）を経由して、各新型対応ゲートウエイに送信される。換言すれば、当該メッセージセッションがファイアウォール通過用通信ルートの一部として利用されて、トンネル接続要求が送信される。

なお、ステップＳ２１〜Ｓ２３において新型デバイスに関する接続要求伝達サーバとしてデータ量課金サーバ６０が選択された場合には、第５実施形態等と同様に、ステップＳ２４に進む。ステップＳ２４では、データ量課金サーバ６０を経由して（ＭＱＴＴ接続を利用して）各トンネル接続要求を各ゲートウエイ３０に送信する処理が開始される（図２８参照）。当該トンネル接続要求に基づき、各ゲートウエイ（通信対象ゲートウエイ）は、クラウドサーバ９０との間でトンネル接続を確立する。

また、図２６のフローチャートには示されていないが、各旧型デバイスに関しては、次のような処理が行われる。具体的には、各旧型デバイスに対応する各ゲートウエイと当該各ゲートウエイに対応するＸＭＰＰサーバ（固定運用サーバ１５０等）との間に確立されているメッセージセッション（ＸＭＰＰ接続）を介して、プラットフォームサーバ８０から当該各ゲートウエイへとトンネル接続要求が送信される。より詳細には、プラットフォームサーバ８０が一のデバイスに対応するゲートウエイ（対応ゲートウエイ）３０へのメッセージ（トンネル接続要求）の送信依頼をロードバランサ７０に送信すると、ロードバランサ７０が、当該対応ゲートウエイ３０に対応するＸＭＰＰサーバ５０を特定し、特定されたＸＭＰＰサーバ５０を当該送信依頼に対して割り当てる。そして、割り当てられた当該ＸＭＰＰサーバ５０と当該対応ゲートウエイとの間に予め確立されているメッセージセッション（ＸＭＰＰ接続）を介して、当該メッセージ（トンネル接続要求）が対応ゲートウエイ３０へと送信される。このように、旧型デバイスに関しては固定運用サーバ１５０が接続要求伝達サーバとして利用される。このような動作は、データ量課金サーバ６０が新型デバイスに関する接続要求伝達サーバとして選択（決定）された場合（図２８参照）と、時間課金サーバ５０が新型デバイスに関する接続要求伝達サーバとして選択（決定）された場合（図３１参照）とのいずれにおいても、同様に行われる。

＜７．第７実施形態＞
上記各実施形態においては、１又は複数のアクセス要求にて指定された複数の通信対象デバイスの全てに関して、同じ種類の通信ルートがファイアウォール通過用通信ルート（接続要求用通信ルート）として選択されているが、これに限定されない。

たとえば、複数の通信対象デバイスの一部に関しては第１ルートがファイアウォール通過用通信ルートとして選択され、複数の通信対象デバイスの他の一部に関しては第２ルートがファイアウォール通過用通信ルートとして選択されてもよい。端的に言えば、第１ルートと第２ルートとが併用されてもよい。第７実施形態では、このような態様について説明する。

第７実施形態は、第５実施形態の変形例である。ただし、これに限定されず、第７実施形態に係る思想は、第１〜第４実施形態等に適用されてもよい。

第７実施形態では、図３３に示すようなデバイスリスト３００を含むアクセス要求が取得されるものとする。このデバイスリスト３００においては、各デバイス１０に対応するＸＭＰＰサーバアドレスもが規定されている。ただし、これに限定されず、上記第１実施形態等と同様に、プラットフォームサーバ８０内の格納部に、このような対応関係（デバイスとＸＭＰＰサーバアドレスとの対応関係）の情報が予め格納されており、当該格納部から当該情報が取得されてもよい。

図３２は、第７実施形態に係る動作を示すフローチャートである。

まず、ステップＳ１１ｂにおいて、図３３に示すようなデバイスリスト３００が取得される。デバイスリスト３００に含まれる複数のデバイス（通信対象デバイス）は、新型デバイスと旧型デバイスとに大きく分類される。ここでは、合計１００３台の全通信対象デバイスのうち、１００２台のデバイス（デバイスＩＤ：「DEVICE_0001」〜「DEVICE_1000」、「DEVICE_1001」、「DEVICE_1002」）が新型デバイスであり、１台のデバイス（デバイスＩＤ：「DEVICE_1003」）が旧型デバイスである。

なお、旧型デバイスは、上述のように、比較例に係る固定運用サーバ（５０ｘ等）のみを接続要求伝達サーバ（トンネル接続要求の通信用のサーバ）として利用可能なデバイスである。図３３においては、１台の旧型デバイス（デバイスＩＤ：「DEVICE_1003」）に対応する固定運用サーバ１５０のアドレス（「Address_X」）が記述されている。各旧型デバイスに関しては、第５実施形態と同様、各旧型デバイスに対応する固定運用サーバ１５０を経由して、トンネル接続要求が送信される。

ステップＳ１１ｂにおいては、さらに、取得されたデバイスリスト３００にて通信対象として指定された複数のデバイスのうち、旧型デバイスが除外され、新型デバイスのみが以後の処理対象として決定される。なお、新型デバイスは、上述のように、接続要求伝達サーバとして上述の２種類のサーバ（時間課金サーバ５０およびデータ量課金サーバ６０）を選択的に利用可能なデバイス（換言すれば、上述の複数の通信ルートを選択的に利用可能なデバイス）である。

ステップＳ１１ｂの後のステップＳ１９においては、デバイスリスト３００から抽出された複数の新型デバイスが、対応する時間課金サーバ５０（「対応サーバ」とも称する）を基準にして、更に複数（ここでは３つ）のグループに分類される。「対応サーバ」は、各通信対象デバイスと当該各通信対象デバイスに予め対応付けられた第１の種類のサーバである、とも表現される。

第１のグループは、アドレス「Address_A」を有する時間課金サーバ５０に対応するグループである。換言すれば、第１のグループは、アドレス「Address_A」の時間課金サーバ５０を接続要求伝達サーバ（メッセージ伝達サーバ）として利用することが予め規定されたデバイス群を有する。第１のグループは、１０００台のデバイス（デバイスＩＤ「DEVICE_0001」〜「DEVICE_1000」）で構成される。また、第２のグループは、アドレス「Address_B」を有する時間課金サーバ５０に対応するグループであり、デバイスＩＤ「DEVICE_1001」の１台のデバイスで構成される。また、第３のグループは、アドレス「Address_C」を有する時間課金サーバ５０に対応するグループであり、デバイスＩＤ「DEVICE_1002」の１台のデバイスで構成される。

このようにして、各通信対象デバイスと各対応サーバとの対応関係に基づき、複数の通信対象デバイス（新型デバイス）が、対応サーバを基準にして複数のグループに分類される。

このような分類処理が実行された後、接続要求用通信ルートの選択処理が、グループごとに実行される。換言すれば、接続要求伝達サーバ（トンネル接続要求の通信用のサーバ）を２種類のサーバ（時間課金サーバ５０およびデータ量課金サーバ６０）の中から選択する選択処理が、グループ単位で実行される。

具体的には、まず、ステップＳ２０において、第ｉのグループ（ただし、ｉ＝１，２，...）（初期値「１」）が着目対象に設定される。そして、着目されたグループ（着目グループ）に関して、ステップＳ２１〜Ｓ２８の処理が実行される。ステップＳ２１〜Ｓ２８の処理は、全てのグループに関する処理が終了した旨がステップＳ２９で判定されるまで繰り返される。全てのグループに関する処理が終了した旨がステップＳ２９で判定されると、図３２の処理は終了する。

このような処理によって、図３３にも示されるように、第１のグループの新型デバイス（１０００台の新型デバイス（「DEVICE_0001」〜「DEVICE_1000」））に関しては、時間課金サーバ５０（換言すれば、第１ルート）が選択される。一方、第２のグループの新型デバイス（「DEVICE_1001」）に関しては、データ量課金サーバ６０（換言すれば、第２ルート）が選択される。また、第３のグループの新型デバイス（「DEVICE_1002」）に関しても、データ量課金サーバ６０（換言すれば、第２ルート）が選択される。

これによれば、複数の通信対象デバイスの全てに関して、同じ種類の通信ルート（たとえば、第１ルート）を接続要求用通信ルートとして選択する場合に比べて、運用コストを一層低減することが可能である。

詳細には、仮に、複数の通信対象デバイスの全て（換言すれば、３つのグループの全て）に関して、いずれも第１ルートが接続要求用通信ルートとして選択される場合を、「比較対象」として想定する。この比較対象では、第２のグループについて「Address_B」の時間課金サーバ５０を少なくとも１秒稼働し、且つ、第３のグループについて「Address_C」の時間課金サーバ５０を少なくとも１秒稼働することを要する。これらの時間課金サーバ５０の稼働に要する料金は、データ量課金サーバ６０にて２つのメッセージを送信する料金よりも高い。逆に言えば、上述のように第２のグループと第３のグループとに関しては、１台のデバイス向けの各メッセージ（合計２個のメッセージ）をデータ量課金サーバ６０を用いて送信する方が、２台の時間課金サーバ５０を１秒ずつ稼働させるために要する料金よりも安い。したがって、運用コストを一層低減することが可能である。

たとえば、上記と同様の条件で料金が計算される場合、第２および第３グループに関する時間課金サーバ５０を１秒ずつ稼働させるための課金料金（比較対象）は、「０．００００７３８８」ＵＳＤ（＝２×１（秒）×０．００００３６９４（秒／ＵＳＤ））である。一方、第２および第３グループに関するデータ量課金サーバ６０の課金料金（第７実施形態）は、「０．０００００２」ＵＳＤ（＝２（メッセージ）×０．０００００１（ＵＳＤ／メッセージ）であり、上記比較対象に関する金額（「０．００００７３８８」ＵＳＤ）よりも低額である。なお、第１グループに関する時間課金サーバ５０の課金料金は、「０．０００３６９４」ＵＳＤ（＝１０００／１００×０．００００３６９４）であり、比較対象と第７実施形態とで共通である。

このように、第７実施形態によれば、運用コストを一層低減することが可能である。特に、比較対象において所定数ＴＨ１（図１２参照）よりも少ないメッセージの送信のために起動される時間課金サーバ５０（「Address_B」，「Address_C」等の時間課金サーバ５０）の台数（上記比較対象では２台）が増大するにつれて、運用コストの低減の度合いは大きくなる。換言すれば、所定数ＴＨ１（図１２参照）よりも少ない台数のデバイスが割り当てられたグループの数が増大するにつれて、運用コストの低減の度合いは大きくなる。

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

たとえば、上記各実施形態においては、ゲートウエイ３０がＭＦＰを用いて構築される態様が例示されているが、これに限定されず、ゲートウエイ３０は他の装置（単機能プリンタあるいはパーソナルコンピュータ等）を用いて構築されてもよい。

また、上記各実施形態においては、デバイス１０としてＭＦＰが例示されているが、これに限定されず、デバイス１０はその他の装置（単機能プリンタあるいはパーソナルコンピュータ等）であってもよい。

また、上記実施形態においては、複数の種類のサーバとして、時間課金サーバ５０とデータ量課金サーバ６０との２種類のサーバを例示したが、これに限定されず、当該複数の種類のサーバは、他の種類のサーバであってもよい。また、複数の種類のサーバは、３種類以上のサーバであってもよい。

１ 通信システム
１０ デバイス
３０ ゲートウエイ
４０ サービス起動用サーバ
５０ 時間課金サーバ
６０ データ量課金サーバ
７０ ロードバランサ
８０ プラットフォームサーバ
９０ クラウドサーバ
１００ クライアント
１５０ 固定運用サーバ
２００ 管理用サーバ群
３００ デバイスリスト
３２０ データテーブル
３５０ ＩＰフィルタ
５１１ メッセージセッション
ＦＷ ファイアウォール

Claims (35)

1. 通信システムであって、
   ファイアウォールの内側に設けられる複数のデバイスと、
   前記ファイアウォールの内側に設けられ、前記複数のデバイスと前記ファイアウォールの外側に設けられた少なくとも１つのクラウドサーバとの通信を中継する少なくとも１つのゲートウエイと、
   前記ファイアウォールの外側に設けられ、前記複数のデバイスのうちの少なくとも１つの通信対象デバイスに対する少なくとも１つのアクセス要求を前記少なくとも１つのクラウドサーバから受け付けるとともに、複数の種類の通信ルートの中から選択されたメッセージ送信用通信ルートを介して、前記少なくとも１つのアクセス要求にて指定された前記少なくとも１つの通信対象デバイスに対応するゲートウエイに対してメッセージを送信するプラットフォームサーバと、
   を備え、
   前記複数の種類の通信ルートのそれぞれは、互いに異なる非定額課金体系で運用され且つ前記ファイアウォールの外側に設けられる複数の種類のサーバであってその課金金額の大小関係が通信態様に応じて変更され得る複数の種類のサーバのいずれかを経由して、前記ファイアウォールを通過するルートであり、
   前記プラットフォームサーバは、前記少なくとも１つのアクセス要求の通信態様情報に基づき、前記少なくとも１つの通信対象デバイスに関する前記メッセージ送信用通信ルートを前記複数の種類の通信ルートの中から選択することを特徴とする通信システム。
2. 請求項１に記載の通信システムにおいて、
   前記複数の種類の通信ルートは、前記複数の種類のサーバのうちの第１の種類のサーバを経由して前記ファイアウォールを通過する第１ルートと、前記複数の種類のサーバのうちの第２の種類のサーバを経由して前記ファイアウォールを通過する第２ルートとを有することを特徴とする通信システム。
3. 請求項２に記載の通信システムにおいて、
   前記第１の種類のサーバは、利用時間に応じて課金される時間課金サーバであり、
   前記第２の種類のサーバは、通信データ量に応じて課金されるデータ量課金サーバであることを特徴とする通信システム。
4. 請求項３に記載の通信システムにおいて、
   前記プラットフォームサーバは、前記第１ルートが選択される場合、前記第１の種類のサーバの起動依頼を所定の起動用サーバに対して送出して前記第１の種類のサーバを起動させ且つ起動後の前記第１の種類のサーバを経由して前記メッセージを前記少なくとも１つの通信対象ゲートウエイに対して送信する処理を開始することを特徴とする通信システム。
5. 請求項１から請求項４のいずれかに記載の通信システムにおいて、
   前記プラットフォームサーバは、一のアクセス要求の受信に応答して、前記一のアクセス要求にて通信対象として指定された前記少なくとも１つの通信対象デバイスに関する前記メッセージ送信用通信ルートの選択処理を実行するとともに、選択された前記メッセージ送信用通信ルートを介して前記メッセージを送信する処理を開始することを特徴とする通信システム。
6. 請求項１から請求項４のいずれかに記載の通信システムにおいて、
   前記プラットフォームサーバは、一のアクセス要求の受信時点から所定期間が経過した後において、前記所定期間内に更に受け付けられた別のアクセス要求をも含む複数のアクセス要求にて通信対象として指定された複数の通信対象デバイスに関する前記メッセージ送信用通信ルートを前記複数のアクセス要求の通信態様情報に基づき選択し、選択された前記メッセージ送信用通信ルートを介して前記メッセージを前記複数の通信対象デバイスに対応する各通信対象ゲートウエイに対して送信する処理を開始することを特徴とする通信システム。
7. 請求項６に記載の通信システムにおいて、
   前記所定期間は、前記一のアクセス要求の種類に応じた長さに変更されることを特徴とする通信システム。
8. 請求項６に記載の通信システムにおいて、
   前記所定期間は、前記一のアクセス要求の種類の緊急度合いが高い程、短い時間に変更されることを特徴とする通信システム。
9. 請求項１から請求項４のいずれかに記載の通信システムにおいて、
   前記プラットフォームサーバは、所定数のアクセス要求が受信された時点で、前記所定数のアクセス要求にて通信対象として指定されている複数の通信対象デバイスに関する前記メッセージ送信用通信ルートを前記所定数のアクセス要求の通信態様情報に基づき選択し、選択された前記メッセージ送信用通信ルートを介して前記メッセージを前記複数の通信対象デバイスに対応する各通信対象ゲートウエイに対して送信する処理を開始することを特徴とする通信システム。
10. 請求項１から請求項４のいずれかに記載の通信システムにおいて、
    前記プラットフォームサーバは、所定数以上の通信対象デバイスに対する少なくとも１つのアクセス要求が受信された時点で、前記少なくとも１つのアクセス要求にて通信対象として指定されている複数の通信対象デバイスに関する前記メッセージ送信用通信ルートを前記少なくとも１つのアクセス要求の通信態様情報に基づき選択し、選択された前記メッセージ送信用通信ルートを介して前記メッセージを前記複数の通信対象デバイスに対応する各通信対象ゲートウエイに対して送信する処理を開始することを特徴とする通信システム。
11. 請求項１から請求項４のいずれかに記載の通信システムにおいて、
    前記プラットフォームサーバは、
    一のアクセス要求である第１のアクセス要求に応じて前記メッセージの送信処理が開始された後に前記第１のアクセス要求とは別のアクセス要求である第２のアクセス要求がさらに受け付けられた際には、前記第１のアクセス要求にて指定された複数の通信対象デバイスのうち前記第１のアクセス要求に応じた前記メッセージの送信処理が未完了の通信対象デバイスである未完了デバイスと前記第２のアクセス要求における通信対象デバイスとに関する前記メッセージ送信用通信ルートを、前記第１のアクセス要求の通信態様情報と前記第２のアクセス要求の通信態様情報とに基づき、前記複数の種類の通信ルートの中から選択し、
    選択された前記メッセージ送信用通信ルートを介して、前記未完了デバイスと前記第２のアクセス要求における通信対象デバイスとにそれぞれ対応する通信対象ゲートウエイに対して前記メッセージを送信する送信処理を開始することを特徴とする通信システム。
12. 請求項２から請求項４のいずれかに記載の通信システムにおいて、
    前記複数のデバイスは、前記メッセージを前記ファイアウォールを通過させて送信するためのサーバであるメッセージ伝達サーバとして前記複数の種類のサーバを選択的に利用可能な第１タイプデバイスと、その運用費用が固定的に発生するサーバである固定運用サーバのみを前記メッセージ伝達サーバとして利用可能な第２タイプデバイスとを含み、
    前記プラットフォームサーバは、前記少なくとも１つのアクセス要求にて指定された通信対象デバイスから前記第２タイプデバイスを除外した残余のデバイスに基づいて、前記メッセージ送信用通信ルートを選択することを特徴とする通信システム。
13. 請求項１２に記載の通信システムにおいて、
    前記固定運用サーバは、常時稼働しており、且つ、前記第２タイプデバイスに対応するゲートウエイからの通信を常に許可し、
    前記第１ルートが前記メッセージ送信用通信ルートとして選択されていない場合、前記第１の種類のサーバは稼働しておらず、
    前記第１の種類のサーバが稼働状態を有する場合、前記第１の種類のサーバは前記第１タイプデバイスに対応するゲートウエイからの通信を許可し、
    前記第１ルートが前記メッセージ送信用通信ルートとして選択された場合、前記第１タイプデバイスに対応する前記第１の種類のサーバが起動し、前記第１タイプデバイスに対応するゲートウエイと前記第１の種類のサーバとの間にメッセージセッションが確立され、当該メッセージセッションが前記メッセージの通信用ルートとして確保されることを特徴とする通信システム。
14. 請求項１２に記載の通信システムにおいて、
    所定プロトコルによるメッセージセッションを各ゲートウエイとの間で確立して前記メッセージを伝達することが可能な複数のメッセージ伝達サーバの相互間における負荷分散処理を実行する負荷分散サーバ、
    をさらに備え、
    前記第１の種類のサーバは、前記所定プロトコルによる前記メッセージセッションを前記第１タイプデバイスに対応するゲートウエイとの間に確立することが可能であり、
    前記負荷分散サーバは、複数のゲートウエイのそれぞれからの通信の許否を規定したＩＰフィルタを有し、
    前記ＩＰフィルタは、
    前記第２タイプデバイスに対応するゲートウエイからの通信を常に許可し、
    前記メッセージ送信用通信ルートとして前記第１ルートが選択されていない場合、前記第１タイプデバイスに対応するゲートウエイからの通信を許可せず、
    前記プラットフォームサーバは、
    前記メッセージ送信用通信ルートとして前記第１ルートが選択される場合、前記少なくとも１つのアクセス要求にて通信対象として指定された前記第１タイプデバイスに対応するゲートウエイである対応ゲートウエイとの通信に用いる前記メッセージ伝達サーバを増設するとともに、前記負荷分散サーバの前記ＩＰフィルタにおいて前記対応ゲートウエイのＩＰアドレスを通信許可対象アドレスとして追加登録し、
    前記負荷分散サーバは、前記対応ゲートウエイからの前記所定プロトコルによる前記メッセージセッションの確立要求が前記ＩＰフィルタを通過して受信されると、前記複数のメッセージ伝達サーバの中から、前記対応ゲートウエイに割り当てるべきサーバである対応サーバを決定し、
    前記対応サーバと前記対応ゲートウエイとの間に前記所定プロトコルによる前記メッセージセッションが確立され、
    前記プラットフォームサーバは、前記負荷分散サーバに前記メッセージを送信することによって、前記メッセージセッションを介して前記メッセージを前記対応ゲートウエイに対して送信することを特徴とする通信システム。
15. 請求項１から請求項１３のいずれかに記載の通信システムにおいて、
    前記プラットフォームサーバは、前記少なくとも１つの通信対象デバイスの全てに関して、同じ種類の通信ルートを前記メッセージ送信用通信ルートとして選択することを特徴とする通信システム。
16. 請求項２から請求項４のいずれかに記載の通信システムにおいて、
    前記プラットフォームサーバは、
    各通信対象デバイスと前記各通信対象デバイスに予め対応付けられた前記第１の種類のサーバである対応サーバとの対応関係に基づき、前記少なくとも１つのアクセス要求にて通信対象として指定された複数の通信対象デバイスを前記対応サーバを基準にして複数のグループに分類し、
    前記少なくとも１つのアクセス要求の通信態様情報に基づき前記複数の種類の通信ルートの中から前記メッセージ送信用通信ルートを選択する選択処理を、グループごとに実行することを特徴とする通信システム。
17. 請求項１に記載の通信システムにおいて、
    前記プラットフォームサーバは、各アクセス要求の送信元のクラウドサーバである送信元クラウドサーバとの間でトンネル接続を確立すべき旨のトンネル接続要求を、前記メッセージとして送信し、
    前記メッセージ送信用通信ルートは、トンネル接続要求用通信ルートであり、
    前記トンネル接続要求は、非定額課金体系で運用されるメッセージ伝達サーバと前記少なくとも１つの通信対象デバイスに対応する少なくとも１つの通信対象ゲートウエイとの間で確立されたメッセージセッションを介して、前記少なくとも１つの通信対象ゲートウエイに対して送信され、
    前記トンネル接続要求を受信した通信対象ゲートウエイは、当該トンネル接続要求に基づき、前記通信対象ゲートウエイと前記送信元クラウドサーバとの間でトンネル接続を確立し、前記送信元クラウドサーバと前記通信対象ゲートウエイに対応するデバイスとの通信を中継し、
    前記プラットフォームサーバは、前記少なくとも１つのアクセス要求の通信態様情報に基づき、前記複数の種類のサーバの中から前記メッセージ伝達サーバを決定することを特徴とする通信システム。
18. ファイアウォールの内側に設けられる複数のデバイスに対する少なくとも１つのアクセス要求を受け付けることが可能であり且つ前記ファイアウォールの外側に設けられるコンピュータに、
    ａ）前記少なくとも１つのアクセス要求を、前記ファイアウォールの外側に設けられる少なくとも１つのクラウドサーバから受け付けるステップと、
    ｂ）前記少なくとも１つのアクセス要求に応じて、複数の種類の通信ルートの中から選択されたメッセージ送信用通信ルートを介して、前記少なくとも１つのアクセス要求にて指定された前記少なくとも１つの通信対象デバイスに対応するゲートウエイに対してメッセージを送信する処理を開始するステップと、
    を実行させるプログラムであって、
    前記複数の種類の通信ルートのそれぞれは、互いに異なる非定額課金体系で運用され且つ前記ファイアウォールの外側に設けられる複数の種類のサーバであってその課金金額の大小関係が通信態様に応じて変更され得る複数の種類のサーバのいずれかを経由して前記ファイアウォールを通過するルートであり、
    前記ステップｂ）は、
    ｂ−１）前記少なくとも１つのアクセス要求に応じて、前記少なくとも１つのアクセス要求の通信態様情報に基づき、前記少なくとも１つの通信対象デバイスに関する前記メッセージ送信用通信ルートを前記複数の種類の通信ルートの中から選択するステップと、
    ｂ−２）前記複数の種類の通信ルートの中から選択された前記メッセージ送信用通信ルートを介して、前記少なくとも１つの通信対象デバイスに対応する少なくとも１つの通信対象ゲートウエイに対して前記メッセージを送信する処理を開始するステップと、
    を有することを特徴とするプログラム。
19. 請求項１８に記載のプログラムにおいて、
    前記複数の種類の通信ルートは、前記複数の種類のサーバのうちの第１の種類のサーバを経由して前記ファイアウォールを通過する第１ルートと、前記複数の種類のサーバのうちの第２の種類のサーバを経由して前記ファイアウォールを通過する第２ルートとを有することを特徴とするプログラム。
20. 請求項１９に記載のプログラムにおいて、
    前記第１の種類のサーバは、利用時間に応じて課金される時間課金サーバであり、
    前記第２の種類のサーバは、通信データ量に応じて課金されるデータ量課金サーバであることを特徴とするプログラム。
21. 請求項２０に記載のプログラムにおいて、
    前記ステップｂ−２）は、
    ｂ−２−１）前記ステップｂ−１）にて前記第１ルートが選択される場合、前記第１の種類のサーバの起動依頼を所定の起動用サーバに対して送出して、前記第１の種類のサーバを起動させるステップと、
    ｂ−２−２）前記ｂ−２−１）の後、起動した前記第１の種類のサーバを経由して前記メッセージを前記少なくとも１つの通信対象ゲートウエイに対して送信する処理を開始するステップと、
    を有することを特徴とするプログラム。
22. 請求項１８から請求項２１のいずれかに記載のプログラムにおいて、
    前記ステップｂ−１）においては、一のアクセス要求の受信に応答して、前記一のアクセス要求にて通信対象として指定された前記少なくとも１つの通信対象デバイスに関する前記メッセージ送信用通信ルートの選択処理が実行され、
    前記ステップｂ−２）においては、前記ステップｂ−１）にて選択された前記メッセージ送信用通信ルートを介して前記メッセージを送信する処理が開始されることを特徴とするプログラム。
23. 請求項１８から請求項２１のいずれかに記載のプログラムにおいて、
    前記ステップｂ−１）においては、一のアクセス要求の受信時点から所定期間が経過した後において、前記所定期間内に更に受け付けられた別のアクセス要求をも含む複数のアクセス要求にて通信対象として指定されている複数の通信対象デバイスに関する前記メッセージ送信用通信ルートが前記複数のアクセス要求の通信態様情報に基づき選択され、
    前記ステップｂ−２）においては、前記ステップｂ−１）にて選択された前記メッセージ送信用通信ルートを介して、前記複数の通信対象デバイスに対応する各通信対象ゲートウエイに対して前記メッセージを送信する処理を開始することを特徴とするプログラム。
24. 請求項２３に記載のプログラムにおいて、
    前記所定期間は、前記一のアクセス要求の種類に応じた長さに変更されることを特徴とするプログラム。
25. 請求項２３に記載のプログラムにおいて、
    前記所定期間は、前記一のアクセス要求の種類の緊急度合いが高い程、短い時間に変更されることを特徴とするプログラム。
26. 請求項１８から請求項２１のいずれかに記載のプログラムにおいて、
    前記ステップｂ−１）においては、所定数のアクセス要求が受信された時点で、前記所定数のアクセス要求にて通信対象として指定されている複数の通信対象デバイスに関する前記メッセージ送信用通信ルートが前記所定数のアクセス要求の通信態様情報に基づき選択され、
    前記ステップｂ−２）においては、前記ステップｂ−１）にて選択された前記メッセージ送信用通信ルートを介して、前記複数の通信対象デバイスに対応する各通信対象ゲートウエイに対して前記メッセージを送信する処理が開始されることを特徴とするプログラム。
27. 請求項１８から請求項２１のいずれかに記載のプログラムにおいて、
    前記ステップｂ−１）においては、所定数以上の通信対象デバイスに対する少なくとも１つのアクセス要求が受信された時点で、前記少なくとも１つのアクセス要求にて通信対象として指定されている複数の通信対象デバイスに関する前記メッセージ送信用通信ルートが前少なくとも１つのアクセス要求の通信態様情報に基づき選択され、
    前記ステップｂ−２）においては、前記ステップｂ−１）にて選択された前記メッセージ送信用通信ルートを介して、前記複数の通信対象デバイスに対応する各通信対象ゲートウエイに対して前記メッセージを送信する処理が開始されることを特徴とするプログラム。
28. 請求項１８または請求項２１に記載のプログラムにおいて、
    ｃ）一のアクセス要求である第１のアクセス要求に応じて前記メッセージの送信処理が開始された後に、前記第１のアクセス要求とは別のアクセス要求である第２のアクセス要求をさらに受け付けるステップと、
    ｄ）前記第２のアクセス要求が受け付けられた際において、前記第１のアクセス要求にて指定された複数の通信対象デバイスのうち前記第１のアクセス要求に応じた前記メッセージの送信処理が未完了の通信対象デバイスである未完了デバイスと前記第２のアクセス要求における通信対象デバイスとに関する前記メッセージ送信用通信ルートを、前記第１のアクセス要求の通信態様情報と前記第２のアクセス要求の通信態様情報とに基づき、前記複数の種類の通信ルートの中から選択するステップと、
    ｅ）前記複数の種類の通信ルートの中から前記ステップｄ）にて選択された前記メッセージ送信用通信ルートを介して、前記未完了デバイスと前記第２のアクセス要求における通信対象デバイスとにそれぞれ対応する通信対象ゲートウエイに対して前記メッセージを送信する送信処理を開始するステップと、
    を前記コンピュータにさらに実行させることを特徴とするプログラム。
29. 請求項１９から請求項２１のいずれかに記載のプログラムにおいて、
    前記複数のデバイスは、前記メッセージを前記ファイアウォールを通過させて送信するためのサーバであるメッセージ伝達サーバとして前記複数の種類のサーバを選択的に利用可能な第１タイプデバイスと、その運用費用が固定的に発生するサーバである固定運用サーバのみを前記メッセージ伝達サーバとして利用可能な第２タイプデバイスとを含み、
    前記ステップｂ−１）においては、前記少なくとも１つのアクセス要求にて指定された通信対象デバイスから前記第２タイプデバイスを除外した残余のデバイスに基づいて、前記メッセージ送信用通信ルートが選択されることを特徴とするプログラム。
30. 請求項２９に記載のプログラムにおいて、
    前記固定運用サーバは、常時稼働しており、且つ、前記第２タイプデバイスに対応するゲートウエイからの通信を常に許可し、
    前記第１ルートが前記メッセージ送信用通信ルートとして選択されていない場合、前記第１の種類のサーバは稼働しておらず、
    前記第１の種類のサーバが稼働状態を有する場合、前記第１の種類のサーバは前記第１タイプデバイスに対応するゲートウエイからの通信を許可し、
    前記ステップｂ−２）は、
    ｂ−２−１）前記第１ルートが前記メッセージ送信用通信ルートとして前記ステップｂ−１）にて選択された場合、前記第１タイプデバイスに対応する前記第１の種類のサーバを起動させるステップと、
    ｂ−２−２）前記第１の種類のサーバの起動に応じて、前記第１タイプデバイスに対応するゲートウエイと前記第１の種類のサーバとの間にメッセージセッションが確立されると、確立された当該メッセージセッションを前記メッセージ送信用通信ルートの一部として利用して、前記メッセージを前記少なくとも１つの通信対象ゲートウエイに対して送信するステップと、
    を有することを特徴とするプログラム。
31. 請求項２９に記載のプログラムにおいて、
    前記第１の種類のサーバは、所定プロトコルによるメッセージセッションを前記第１タイプデバイスに対応するゲートウエイとの間に確立することが可能であり、
    各ゲートウエイは、負荷分散サーバに対して前記所定プロトコルによる前記メッセージセッションの確立要求を送信し、
    前記所定プロトコルによる前記メッセージセッションを前記各ゲートウエイとの間で確立して前記メッセージを伝達することが可能な複数のメッセージ伝達サーバの相互間における負荷分散処理を実行する前記負荷分散サーバは、複数のゲートウエイのそれぞれからの通信の許否を規定したＩＰフィルタを有し、
    前記ＩＰフィルタは、
    前記第２タイプデバイスに対応するゲートウエイからの通信を常に許可し、
    前記メッセージ送信用通信ルートとして前記第１ルートが選択されていない場合、前記第１タイプデバイスに対応するゲートウエイからの通信を許可せず、
    前記ステップｂ−２）は、
    ｂ−２−１）前記第１ルートが前記メッセージ送信用通信ルートとして前記ステップｂ−１）にて選択された場合、前記少なくとも１つのアクセス要求にて通信対象として指定された前記第１タイプデバイスに対応するゲートウエイである対応ゲートウエイとの通信に用いるメッセージ伝達サーバを増設するステップと、
    ｂ−２−２）前記第１ルートが前記メッセージ送信用通信ルートとして前記ステップｂ−１）にて選択された場合、前記負荷分散サーバの前記ＩＰフィルタにおいて前記対応ゲートウエイのＩＰアドレスを通信許可対象アドレスとして追加登録するステップと、
    ｂ−２−３）前記対応ゲートウエイからの前記所定プロトコルによる前記メッセージセッションの確立要求が前記ＩＰフィルタを通過して受信されることに応じて、前記ステップｂ−２−１）にて増設された前記第１の種類のサーバであって前記負荷分散サーバによる割り当て処理によって割り当てられた前記第１の種類のサーバと前記対応ゲートウエイとの間に前記メッセージセッションが確立された後、前記負荷分散サーバに前記メッセージを送信することによって、前記メッセージセッションを介して前記メッセージを前記対応ゲートウエイに対して送信するステップと、
    を有することを特徴とするプログラム。
32. 請求項１８から請求項３１のいずれかに記載のプログラムにおいて、
    前記ステップｂ−１）において、前記少なくとも１つの通信対象デバイスの全てに関して、同じ種類の通信ルートが前記メッセージ送信用通信ルートとして選択されることを特徴とするプログラム。
33. 請求項１９から請求項２１のいずれかに記載のプログラムにおいて、
    前記ステップｂ−１）は、
    ｂ−１−１）各通信対象デバイスと前記各通信対象デバイスに予め対応付けられた前記第１の種類のサーバである対応サーバとの対応関係に基づき、前記少なくとも１つのアクセス要求にて通信対象として指定された複数の通信対象デバイスを、前記対応サーバを基準にして複数のグループに分類するステップと、
    ｂ−１−２）前記少なくとも１つのアクセス要求の通信態様情報に基づき前記複数の種類の通信ルートの中から前記メッセージ送信用通信ルートを選択する選択処理を、グループごとに実行するステップと、
    を有することを特徴とするプログラム。
34. 請求項１８に記載のプログラムにおいて、
    前記ステップｂ−２）において、各アクセス要求の送信元のクラウドサーバである送信元クラウドサーバとの間でトンネル接続を確立すべき旨のトンネル接続要求が、前記メッセージとして送信され、
    前記メッセージ送信用通信ルートは、トンネル接続要求用通信ルートであり、
    前記トンネル接続要求は、非定額課金体系で運用されるメッセージ伝達サーバと前記少なくとも１つの通信対象デバイスに対応する少なくとも１つの通信対象ゲートウエイとの間で確立されたメッセージセッションを介して、前記少なくとも１つの通信対象ゲートウエイに対して送信され、
    前記ステップｂ−１）において、前記少なくとも１つのアクセス要求の通信態様情報に基づき、前記複数の種類のサーバの中から前記メッセージ伝達サーバが決定されることを特徴とするプログラム。
35. ファイアウォールの内側に設けられる複数のデバイスに対する少なくとも１つのアクセス要求を受け付けることが可能であり且つ前記ファイアウォールの外側に設けられるプラットフォームサーバであって、
    前記少なくとも１つのアクセス要求を、前記ファイアウォールの外側に設けられる少なくとも１つのクラウドサーバから受け付ける受信手段と、
    前記少なくとも１つのアクセス要求に応じて、複数の種類の通信ルートの中から選択されたメッセージ送信用通信ルートを介して、前記少なくとも１つのアクセス要求にて指定された前記少なくとも１つの通信対象デバイスに対応するゲートウエイに対してメッセージを送信する処理を開始する送信手段と、
    を備え、
    前記複数の種類の通信ルートのそれぞれは、互いに異なる非定額課金体系で運用され且つ前記ファイアウォールの外側に設けられる複数の種類のサーバであってその課金金額の大小関係が通信態様に応じて変更され得る複数の種類のサーバのいずれかを経由して前記ファイアウォールを通過するルートであり、
    前記プラットフォームサーバは、
    前記少なくとも１つのアクセス要求に応じて、前記少なくとも１つのアクセス要求の通信態様情報に基づき、前記少なくとも１つの通信対象デバイスに関する前記メッセージ送信用通信ルートを前記複数の種類の通信ルートの中から選択する選択手段、
    をさらに備え、
    前記送信手段は、前記複数の種類の通信ルートの中から選択された前記メッセージ送信用通信ルートを介して、前記少なくとも１つの通信対象デバイスに対応する少なくとも１つの通信対象ゲートウエイに対して前記メッセージを送信する処理を開始することを特徴とするプラットフォームサーバ。

Images