(57)【要約】【課題】ネットワーク負荷を抑制した、複数のネットワークデバイスからのデータ送信の制御を実現するシステムを提供する。【解決手段】状態管理サーバ１０２は、複数のＭＦＰ１０１のそれぞれのデータ送信の送信ステータスを管理する。事前処理Ａｃｔｉｏｎ３４３は、ＭＦＰ１０１の送信ステータスを送信待ち状態に更新し、抽出処理Ａｃｔｉｏｎ３４４を起動する。抽出処理Ａｃｔｉｏｎ３４４は、送信ステータスが送信待ち状態であるＮ台以内のＭＦＰ１０１を選択し、選択されたＭＦＰ１０１の送信ステータスをデータ送信中に更新するように状態管理サーバ１０２に指示する。ＭＦＰ１０１からの送信完了を示す通知に応じて、状態管理サーバ１０２は、該ＭＦＰ１０１の送信ステータスを送信完了に更新し、抽出処理Ａｃｔｉｏｎ３４４を起動する。送信ステータスが送信待ち状態であるＭＦＰ１０１が無い場合、抽出処理Ａｃｔｉｏｎ３４４は、処理を終了する。【選択図】図３
2019091180.tif 000002
【特許請求の範囲】
【請求項１】
複数のネットワークデバイスのそれぞれのデータ送信の送信状態を管理する管理手段と、
前記複数のネットワークデバイスの送信状態を、送信待ちを示す第１状態に更新する第１更新手段と、
前記複数のネットワークデバイスの送信状態が前記第１状態に更新された際に、データ送信の対象となるネットワークデバイスを抽出するスクリプトを起動する第１起動手段と、
前記起動されたスクリプトに従う処理として、送信状態が前記第１状態であるＮ（Ｎは１以上の整数）台以内のネットワークデバイスを選択する選択手段と、
前記起動されたスクリプトに従う処理として、当該選択されたネットワークデバイスの送信状態を、送信中を示す第２状態に更新する第２更新手段と、
送信状態が前記第２状態であるネットワークデバイスからの送信完了を示す通知に応じて、該ネットワークデバイスの送信状態を、送信完了を示す第３状態に更新する第３更新手段と、
前記選択されたネットワークデバイスの送信状態が前記第３状態に更新された際に、前記スクリプトを起動する第２起動手段と、を有するシステムであって、
送信状態が前記第１状態であるネットワークデバイスが無い場合には、前記起動されたスクリプトに従う処理が終了する、ことを特徴とするシステム。
【請求項２】
前記管理手段は、各ネットワークデバイスの通知に従い、前記複数のネットワークデバイスの電源状態をさらに管理し、
前記選択手段は、送信状態が前記第１状態で、かつ、電源状態が電源オンであるネットワークデバイスを選択する、ことを特徴とする請求項１に記載のシステム。
【請求項３】
前記第２起動手段は、さらに、送信状態が前記第１状態であるネットワークデバイスの電源状態が電源オフから電源オンに変更された場合に、前記スクリプトを起動する、ことを特徴とする請求項１または２に記載のシステム。
【請求項４】
前記管理手段は、各ネットワークデバイスの前回のデータ送信を行った時間情報をさらに管理する、ことを特徴とする請求項１乃至３のいずれか一項に記載のシステム。
【請求項５】
前記選択手段により選択された送信状態が前記第１状態であるネットワークデバイスの前記時間情報のうち最も古い時間情報と、送信状態が前記第２状態であるネットワークデバイスの前記時間情報のうち最も新しい時間情報とを比較する比較手段を有し、
送信状態が前記第２状態であるネットワークデバイスの最も新しい時間情報よりも、送信状態が前記第１状態であるネットワークデバイスの最も古い時間情報の方が古い場合、前記第２更新手段は、送信状態が前記第１状態である該ネットワークデバイスの送信状態を前記第２状態に更新する、ことを特徴とする請求項４に記載のシステム。
【請求項６】
送信状態が前記第１状態であるネットワークデバイスの最も古い時間情報よりも、送信状態が前記第２状態であるネットワークデバイスの最も新しい時間情報の方が古い場合、前記第２更新手段は、送信状態が前記第２状態である該ネットワークデバイスの送信状態を前記第１状態に更新する、ことを特徴とする請求項５に記載のシステム。
【請求項７】
送信状態が第２状態に更新されたネットワークデバイスに対して、データ送信を指示する指示手段をさらに有する、ことを特徴とする請求項１乃至６のいずれか一項に記載のシステム。
【請求項８】
前記指示手段は、送信状態が第２状態から第１状態に更新されたネットワークデバイスに対して、データ送信の中止を指示する、ことを特徴とする請求項７に記載のシステム。
【請求項９】
前記第１起動手段は、前記複数のネットワークデバイスの送信状態が前記第１状態に更新された際に、前記スクリプトの起動を所定の回数繰り返す、ことを特徴とする請求項１乃至８のいずれか一項に記載のシステム。
【請求項１０】
複数のネットワークデバイスのそれぞれのデータ送信の送信状態を管理する工程と、
前記複数のネットワークデバイスの送信状態を、送信待ちを示す第１状態に更新する工程と、
前記複数のネットワークデバイスの送信状態が前記第１状態に更新された際に、データ送信の対象となるネットワークデバイスを抽出するスクリプトを起動する工程と、
前記起動されたスクリプトに従う処理として、送信状態が前記第１状態であるＮ（Ｎは１以上の整数）台以内のネットワークデバイスを選択する工程と、
前記起動されたスクリプトに従う処理として、当該選択されたネットワークデバイスの送信状態を、送信中を示す第２状態に更新する工程と、
送信状態が前記第２状態であるネットワークデバイスからの送信完了を示す通知に応じて、該ネットワークデバイスの送信状態を、送信完了を示す第３状態に更新する工程と、
前記選択されたネットワークデバイスの送信状態が前記第３状態に更新された際に、前記スクリプトを起動する工程と、を有するシステムの制御方法であって、
送信状態が前記第１状態であるネットワークデバイスが無い場合には、前記起動されたスクリプトに従う処理が終了する、ことを特徴とするシステムの制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、システムおよびその制御方法に関する。
【背景技術】
【０００２】
近年、インターネットに家電製品や自動車などのオブジェクトをクライアントとして接続する「Ｉｎｔｅｒｎｅｔ  ｏｆ  Ｔｈｉｎｇｓ」（ＩｏＴ）を実現するシステムがある。また、画像形成装置の多機能化が進み、Ｍｕｌｔｉ  Ｆｕｎｃｔｉｏｎ  Ｐｒｉｎｔｅｒ（ＭＦＰ）と呼ばれる複合機をＩｏＴシステムのクライアントとすることが可能になった。
【０００３】
ＩｏＴシステムでは、膨大な数のクライアントが接続されることを前提としている。ＩｏＴシステムは、クライアントからの膨大な量の情報を収集、分析することでクライアントおよびそれを利用するユーザに対して付加価値を提供する。例えば、複合機をクライアントとするＩｏＴシステムでは、複合機が有する各種センサデータをシステムに送信し、分析することで複合機の故障予測や消耗品配送予測を行うことが可能である。
【０００４】
このように、分析で利用されるセンサデータは、クライアントとなるデバイスにおいてアラート等のイベントが発生したタイミングだけでなく、平常稼動時において時系列データとして必要である。そのため、デバイスで継続的にセンサデータを計測・蓄積し、一定時間おきにまとめてシステムに送信する定期送信が実行される。このとき、定期送信のデータ量は膨大であり、各デバイスが一斉に送信を開始するとテナント側およびシステム側のネットワークトラフィックが逼迫してしまう。
【０００５】
そのため、テナント内で定期送信のタイミングが重複しないようにスケジュールの調整が必要となる。また、例えば、故障の兆候が現れた際には定期送信の間隔を短くするといった、収集されたデータの分析結果をユーザに素早く精度の高いフィードバックを行うためには、臨機応変にスケジュールを変更する対応も必要となる。このように、ＩｏＴシステムにおけるデバイスからのデータ送信では、細やかな制御が求められる。
【０００６】
特許文献１は、サーバが、該サーバに接続されたクライアントの数や該サーバの処理能力を反映した通信許容量を算出し、クライアントがサーバへ応答要求を送信する間隔を該通信許容量に基づいて決定するネットワークシステムを開示している。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２０１７−７３０６７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
特許文献１のネットワークシステムによれば、サーバ側の通信許容量から応答要求を送信する間隔が決定される。このため、クライアント側の負荷やクライアント側の分析ニーズを考慮して臨機応変にデータ送信のスケジュールを変更する等、データ送信の細やかな制御を行うことができない。細やかな制御を行うには、クライアントからサーバへの応答要求の回数を増やす必要があり、その場合はネットワーク負荷が高くなってしまう。
【０００９】
本発明は、ネットワーク負荷を抑制した、複数のネットワークデバイスからのデータ送信の制御を実現するシステムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
本発明の一実施形態のシステムは、複数のネットワークデバイスのそれぞれのデータ送信の送信状態を管理する管理手段と、前記複数のネットワークデバイスの送信状態を、送信待ちを示す第１状態に更新する第１更新手段と、前記複数のネットワークデバイスの送信状態が前記第１状態に更新された際に、データ送信の対象となるネットワークデバイスを抽出するスクリプトを起動する第１起動手段と、前記起動されたスクリプトに従う処理として、送信状態が前記第１状態であるＮ（Ｎは１以上の整数）台以内のネットワークデバイスを選択する選択手段と、前記起動されたスクリプトに従う処理として、当該選択されたネットワークデバイスの送信状態を、送信中を示す第２状態に更新する第２更新手段と、送信状態が前記第２状態であるネットワークデバイスからの送信完了を示す通知に応じて、該ネットワークデバイスの送信状態を、送信完了を示す第３状態に更新する第３更新手段と、前記選択されたネットワークデバイスの送信状態が前記第３状態に更新された際に、前記スクリプトを起動する第２起動手段と、を有するシステムであって、送信状態が前記第１状態であるネットワークデバイスが無い場合には、前記起動されたスクリプトに従う処理が終了する。
【発明の効果】
【００１１】
本発明のシステムによれば、ネットワーク負荷を抑制した、複数のネットワークデバイスからのデータ送信の制御を実現することが可能となる。
【図面の簡単な説明】
【００１２】
【図１】本発明の一実施形態に係るシステムの全体構成例を示す図である。
【図２】各装置の情報処理機能のハードウェア構成例を示す図である。
【図３】各装置のソフトウェア構成例を示す図である。
【図４】状態情報ファイルの一例を示す図である。
【図５】、ＭＦＰからファイル管理サーバへのデータ送信に係る処理を示す図である。
【図６】事前処理Ａｃｔｉｏｎが実行する処理を示す図である。
【図７】抽出処理Ａｃｔｉｏｎが実行する処理を示す図である。
【図８】状態情報ファイルの一例を示す図である。
【図９】第１実施形態における状態情報ファイルの一例を示す図である。
【図１０】第２実施形態にて抽出処理Ａｃｔｉｏｎが実行する処理を示す図である。
【図１１】第２実施形態における状態情報ファイルの一例を示す図である。
【図１２】第４実施形態にて事前処理Ａｃｔｉｏｎが実行する処理を示す図である。
【図１３】第４実施形態にて抽出処理Ａｃｔｉｏｎが実行する処理を示す図である。
【発明を実施するための形態】
【００１３】
以下、本発明を実施するための形態について図面などを参照して説明する。
【００１４】
［第１実施形態］
＜システムの全体構成＞
図１は、本発明の一実施形態に係るシステムの全体構成例を示す図である。
本実施形態に係るシステムは、ネットワーク１００を介して接続されるネットワークデバイス、状態管理サーバ１０２、スクリプト管理サーバ１０３、およびファイル管理サーバ１０４などから構成される。
【００１５】
なお、本実施形態では、ネットワークデイバスの一例としてＭＦＰ１０１を用いて説明するが、これに限られるものではない。ネットワークデバイスは、例えば、プリンタやスキャナ、ネットワーク中継機器（ルータ）やネットワークカメラ等の機器であってもよく、ネットワーク１００を介した通信機能を有する機器であればどのようなものでもよい。
【００１６】
なお、本実施形態に係る状態管理サーバ１０２およびスクリプト管理サーバ１０３は、それぞれ複数のサーバコンピュータから構築されてもよく、また、クラウドサービスによって提供されるリソースとしての仮想マシンやストレージを用いて構築されてもよい。仮想マシンとは、仮想化技術によって、データセンタ上のサーバコンピュータ（実コンピュータ）を物理的な構成にとらわれずに論理的な単位で分割し、分割したそれぞれで独立したオペレーティングシステムをもって動作する論理的なコンピュータである。
【００１７】
１台以上のサーバコンピュータ上で動作する１以上の仮想マシンを用いて、状態管理サーバ１０２およびスクリプト管理サーバ１０３が構築される。サーバコンピュータや作成する仮想マシンの数は限定しない。状態管理サーバ１０２およびスクリプト管理サーバ１０３が備える各ソフトウェアモジュールは、それぞれ別の仮想マシンで実行される場合もあれば、同一の仮想マシンで実行される場合もある。
【００１８】
ネットワーク１００は、各構成要素間で通信を行うための基盤であって、Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ（ＷＡＮ）、Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ（ＬＡＮ）またはその他のネットワークシステムであっても構わない。ＭＦＰ１０１は、本システムのクライアントとなるネットワークデバイスである。テナント１０５内の複数台のＭＦＰ１０１が、ネットワーク１００を介して状態管理サーバ１０２およびファイル管理サーバ１０４と相互に接続する。なお、ネットワーク１００に接続されるテナントの数や、該テナントに属するＭＦＰ１０１の台数は、図１に示した例に限定されるものではない。
【００１９】
状態管理サーバ１０２は、複数台のＭＦＰ１０１の状態を管理するＩｏＴ管理サーバとして機能する。ＭＦＰ１０１は、自身の状態に変化があった場合に、状態管理サーバ１０２にその旨を示す情報を送信する。また状態管理サーバ１０２は、スクリプト管理サーバ１０３からの指示をＭＦＰ１０１に送信する。状態管理サーバ１０２の代表的な例として、ＡＷＳ  ＩｏＴ等が挙げられるが、これに限定するものではない。
【００２０】
スクリプト管理サーバ１０３は、状態管理サーバ１０２の各種イベントをトリガーとして駆動するスクリプト（プログラムコード）の管理および実行を行う実行サービスとして機能する。スクリプト管理サーバ１０３の代表的な例として、ＡＷＳ  Ｌａｍｂｄａ等が挙げられるが、これに限定するものではない。ファイル管理サーバ１０４は、ＭＦＰ１０１から定期的に送信されるファイルの実体を受信し、保存するストレージサービスとして機能する。ファイル管理サーバ１０４は、ＭＦＰ１０１から送信される様々なフォーマットのファイルを保存する。
【００２１】
＜ハードウェア構成＞
図２は、ＭＦＰ１０１、状態管理サーバ１０２、スクリプト管理サーバ１０３、およびファイル管理サーバ１０４の情報処理機能のハードウェア構成例を示す図である。
なお、状態管理サーバ１０２またはスクリプト管理サーバ１０３が仮想マシンを用いて構築される場合、図２は、該仮想マシンを構築するデータセンタ上の実コンピュータのハードウェア構成をも示すものである。
【００２２】
ユーザインタフェース２０１は、ディスプレイ、キーボード、マウス、タッチパネルなどによる情報の入出力を行う。これらのハードウェアを備えないコンピュータは、リモートデスクトップやリモートシェルなどにより、他のコンピュータから接続・操作することも可能である。ネットワークインタフェース２０２は、ＬＡＮなどのネットワーク１００に接続して、他のコンピュータやネットワークデバイスとの通信を行う。
【００２３】
ＣＰＵ２０３は、ＲＯＭ２０４、ＲＡＭ２０５、記憶装置２０６などから読み込んだプログラムを実行する。ＲＯＭ２０４は、組込済みプログラムおよびデータが記録されている記憶素子である。ＲＡＭ２０５は、一時メモリ領域として機能する記憶素子である。記憶装置２０６は、ＨＤＤに代表されるような記憶装置である。上述した各ハードウェアは、入出力インタフェース２０７を介して接続されている。
【００２４】
＜ソフトウェア構成＞
図３は、本実施形態に係るシステムのソフトウェア構成およびネットワークを介した相互接続状況を示す図である。
図３に示す各ソフトウェアは、図２に示した記憶装置２０６に格納され、ＣＰＵ２０３によって実行される。
【００２５】
まず、ＭＦＰ１０１のソフトウェア構成について説明する。ＭＦＰ１０１は、クライアントアプリケーション３１０およびデータ管理アプリケーション３２０を備える。クライアントアプリケーション３１０は、ＭＦＰ１０１の状態情報を状態管理サーバ１０２に送信するとともに、状態管理サーバ１０２からの状態情報の更新指示を受信する。クライアントアプリケーション３１０は、通信部３１１、メッセージ生成部３１２、メッセージ解析部３１３、および状態管理部３１４から構成される。
【００２６】
通信部３１１は、ネットワークインタフェース２０２を介してネットワーク１００に接続される状態管理サーバ１０２と通信を行う。メッセージ生成部３１２は、状態管理部３１４から取得したＭＦＰ１０１の状態情報から自身の状態を通知するメッセージを生成する。生成されたメッセージは、通信部３１１を介して状態管理サーバ１０２に送信される。
【００２７】
メッセージ解析部３１３は、通信部３１１を介して状態管理サーバ１０２から受信した状態情報の更新を指示するメッセージ（状態更新指示）の解析を行い、状態管理部３１４に送信する。状態管理部３１４は、通信部３１１を介してＭＦＰ１０１の各種状態を示す情報や、各種設定値などの情報を受信する。また、状態管理部３１４は、メッセージ解析部３１３から受信した指示をデータ管理アプリケーション３２０に送信する。
【００２８】
データ管理アプリケーション３２０は、通信部３２１、データ管理部３２２、およびデータ保存部３２３から構成される。通信部３２１は、ネットワークインタフェース２０２を介してファイル管理サーバ１０４と通信を行う。データ管理部３２２は、ＭＦＰ１０１のセンサ情報や機器の構成情報などのデバイス情報を受信する。また、データ管理部３２２は、状態管理部３１４の指示に従い、データ保存部３２３からデバイス情報を取得し、通信部３２１を介してファイル管理サーバ１０４に送信する。データ保存部３２３は、データ管理部３２２からの指示に従って、ＭＦＰ１０１のデバイス情報を保存する。
【００２９】
次に、状態管理サーバ１０２のソフトウェア構成について説明する。状態管理サーバ１０２は、サーバアプリケーション３３０を備える。サーバアプリケーション３３０は、「出版−購読型モデル」における「Ｂｒｏｋｅｒ」としてＭＦＰ１０１とスクリプト管理サーバ１０３とのメッセージの送受信を管理する。
【００３０】
サーバアプリケーション３３０は、ＭＦＰ１０１の状態を管理し、ＭＦＰ１０１から状態更新を通知するメッセージを受信すると、連携するスクリプト管理サーバ１０３に該更新を通知する。また、サーバアプリケーション３３０は、スクリプト管理サーバ１０３からＭＦＰ１０１に対する状態更新指示を受信し、ＭＦＰ１０１に該指示を送信することでＭＦＰ１０１に状態情報の更新を指示する。
【００３１】
サーバアプリケーション３３０は、通信部３３１、テナント管理部３３２、テナント管理データベース３３３、クライアント管理部３３４、クライアントデータベース３３５、接続管理部３３６、接続管理データベース３３７、メッセージ生成部３３８、および通知制御部３３９から構成される。
【００３２】
通信部３３１は、ネットワークインタフェース２０２を介してネットワーク１００に接続されるＭＦＰ１０１およびスクリプト管理サーバ１０３と通信を行う。テナント管理部３３２は、テナント１０５とＭＦＰ１０１の関連情報を管理する。テナント１０５内に存在するＭＦＰ１０１は、テナント１０５と紐付けてテナント管理データベース３３３に保存される。テナント管理データベース３３３に保存され、テナント管理部３３２が管理するＭＦＰ１０１のテナント関連情報の一例を下表のテナント関連情報テーブルに示す。
【００３３】
【表１】
2019091180.tif 000003
【００３４】
テナント関連情報テーブルは、テナント名およびクライアント名から構成される。テナント名カラムには、テナント１０５の名称が保存される。クライアント名カラムには、テナント１０５と関連しているＭＦＰ１０１の名称が保存される。なお、本実施形態では、テナント関連情報は、テナント管理データベース３３３に保存されるが、これに限られるものではない。例えば、テナント関連情報は、図４に示す状態情報内で管理されてもよく、またアカウント管理を行う別サービス内で管理されてもよい。
【００３５】
クライアント管理部３３４は、状態管理サーバ１０２にネットワーク１００を介して接続されるＭＦＰ１０１の状態情報を管理する。ＭＦＰ１０１の状態情報は、クライアントデータベース３３５に保存される。クライアントデータベース３３５に保存され、クライアント管理部３３４が管理するＭＦＰの状態情報の一例を下表の状態情報テーブルに示す。
【００３６】
【表２】
2019091180.tif 000004
【００３７】
状態情報テーブルは、状態情報ＩＤ、状態情報名、および状態情報から構成される。状態情報ＩＤカラムには、サーバアプリケーション３３０に接続されるＭＦＰ１０１を一意に識別するための識別子が保存される。状態情報名カラムには、サーバアプリケーション３３０に接続されるＭＦＰ１０１の名称が保存される。状態情報カラムには、サーバアプリケーション３３０に接続されるＭＦＰ１０１の状態情報が保存される。以下、状態情報カラムに保存されるＭＦＰ１０１の状態情報について説明する。
【００３８】
図４は、本実施形態における状態管理サーバ１０２が管理するＭＦＰ１０１の状態情報の一例を示す図である。
状態情報ファイル４００は、ＭＦＰ１０１の状態情報を管理するファイルであり、状態管理サーバ１０２が管理するＭＦＰ１０１と対応付けて存在する。
【００３９】
状態情報ファイル４００は、状態情報部４０１、バージョン４０４、およびタイムスタンプ４０５から構成される。なお、本実施形態では、状態情報ファイル４００のフォーマットをＪａｖａＳｃｒｉｐｔ（登録商標）  Ｏｂｊｅｃｔ  Ｎｏｔａｔｉｏｎ形式（ＪＳＯＮ形式）で記載しているが、フォーマットはこれに限られるものではない。
【００４０】
状態情報部４０１は、ＭＦＰ１０１の現在の状態を示す状態部４０３とスクリプト管理サーバ１０３からの指示を受けて変化する状態を示す指示部４０２とから構成される。詳細には、指示部４０２は、スクリプト管理サーバ１０３からの指示内容であり、ＭＦＰ１０１の状態を更新するための指示を格納する。すなわち、ＭＦＰ１０１が該指示を受けて変化する状態を示す情報が格納される。なお、スクリプト管理サーバ１０３からの指示がない場合、指示部４０２には値が格納されず空となる。
【００４１】
また、状態部４０３には、ＭＦＰ１０１の現在の状態を示す情報が格納される。状態部４０３に格納される現在の状態を示す情報の一例として、図４では、送信ステータス４０６および電源ステータスを含む。送信ステータス４０６は、ＭＦＰ１０１のデータ送信の実行状況を示す情報を格納する。
【００４２】
本実施形態では、ＭＦＰ１０１がファイル管理サーバ１０４に対してデータ送信待ちの状態を示す情報を「ｗａｉｔｉｎｇ」とする。また、ＭＦＰ１０１がファイル管理サーバ１０４に対してデータを送信している状態を示す情報を「ｓｅｎｄｉｎｇ」とする。また、ＭＦＰ１０１がファイル管理サーバ１０４に対してデータの送信が完了した状態を示す情報を「ｃｏｍｐｌｅｔｅ」とする。図４に示す例では、送信ステータス４０６には送信が完了した状態であることを示す「ｃｏｍｐｌｅｔｅ」が格納されている。
【００４３】
電源ステータス４０７は、ＭＦＰ１０１の電源状態を示す情報を格納する。本実施形態では、ＭＦＰ１０１の電源がオンの状態を示す情報を「ｏｎ」とし、ＭＦＰ１０１の電源がオフの状態を示す情報を「ｏｆｆ」とする。図４に示す例では、電源ステータス４０７にはＭＦＰ１０１の電源がオンであることを示す「ｏｎ」が格納されている。
【００４４】
バージョン４０４には、状態情報ファイル４００のバージョンが格納される。バージョン４０４は、ＭＦＰ１０１およびスクリプト管理サーバ１０３によって状態情報ファイル４００が更新されるたびに変更される。タイムスタンプ４０５には、状態情報ファイル４００がＭＦＰ１０１およびスクリプト管理サーバ１０３によって更新された際にタイムスタンプ情報が格納される。
【００４５】
図３の説明に戻る。接続管理部３３６は、状態管理サーバ１０２にネットワーク１００を介して接続されるＭＦＰ１０１およびスクリプト管理サーバ１０３の接続情報を管理する。状態管理サーバ１０２に現在接続されているＭＦＰ１０１およびスクリプト管理サーバ１０３の接続情報は、接続管理データベース３３７に保存される。接続管理データベース３３７に保存され、接続管理部３３６が管理する接続情報の一例を下表の接続情報テーブルに示す。
【００４６】
【表３】
2019091180.tif 000005
【００４７】
接続情報テーブルは、接続ＩＤ、接続クライアント名、出版状態情報名、および購読状態情報名から構成される。接続ＩＤカラムには、状態管理サーバ１０２に現在接続されているＭＦＰ１０１、およびスクリプト管理サーバ１０３のスクリプトを一意に識別するための識別子が保存される。
【００４８】
接続クライアント名カラムには、状態管理サーバ１０２に現在接続されているＭＦＰ１０１およびスクリプト管理サーバ１０３のスクリプト名称が保存される。出版状態情報名カラムには、状態情報を更新可能なクライアント名が保存されている。購読状態情報名カラムには、状態情報を参照可能なクライアント名が格納されている。
【００４９】
接続管理データベース３３７に保存され、接続管理部３３６が管理するその他の情報の例として、ＭＦＰ１０１の状態情報に関する権限情報がある。詳細には、状態管理サーバ１０２に接続されるＭＦＰ１０１およびスクリプト管理サーバ１０３のスクリプトがアクセス可能な状態情報に対する実際のアクセス許可の内容（権限情報）である。権限情報の一例を下表の権限情報テーブルに示す。
【００５０】
【表４】
2019091180.tif 000006
【００５１】
権限情報テーブルは、接続クライアント名、状態情報ＩＤ、状態情報名、および権限から構成される。接続クライアント名カラムには、状態管理サーバ１０２が権限情報を管理するＭＦＰ１０１およびスクリプト管理サーバ１０３のスクリプトの名称が保存される。上記の権限情報テーブルの例では、接続クライアント名カラムの値が「ｍｆｐ１」および「ｍｆｐ２」のレコードがＭＦＰ１０１に関する権限情報を表す。
【００５２】
また、接続クライアント名カラムの値が「ｓｃｒｉｐｔ１」のレコードがスクリプト管理サーバ１０３の事前処理Ａｃｔｉｏｎ３４３の権限情報を表す。また、接続クライアント名カラムの値が「ｓｃｒｉｐｔ２」のレコードがスクリプト管理サーバ１０３の抽出処理Ａｃｔｉｏｎ３４４の権限情報を表す。
【００５３】
状態情報ＩＤカラムには、接続クライアント名カラムの値が示すＭＦＰ１０１またはスクリプト管理サーバ１０３のスクリプトがアクセス可能な状態情報を一意に識別するための識別子が保存される。なお、接続情報テーブルの状態情報ＩＤカラムの値に基づき、状態情報テーブル（表２）の状態情報ＩＤカラムにおいて同じ値を有する状態情報ファイルを特定することができる。
【００５４】
状態情報名カラムには、接続クライアント名カラムの値が示すＭＦＰ１０１またはスクリプト管理サーバ１０３のスクリプトがアクセス可能な状態情報がどのＭＦＰ１０１に対するものか、該ＭＦＰ１０１の名称が保存される。権限カラムには、状態情報ＩＤカラムの値から特定される状態情報テーブル（表２）の状態情報ファイルに対するアクセス権限に対応する値が保存される。
【００５５】
本実施形態では、権限カラムの値に「Ｐｕｂｌｉｓｈ」を含むレコードの場合、接続クライアント名カラムが示す接続クライアントが、状態情報ＩＤカラムが示す状態情報ファイルに対して更新権限を有することを表す。また、権限カラムの値に「Ｓｕｂｓｃｒｉｂｅ」を含むレコードの場合、接続クライアント名カラムが示す接続クライアントが、状態情報ＩＤカラムが示す状態情報ファイルに対して参照権限を有することを表す。
【００５６】
上記の権限情報テーブルの例では、接続クライアント名カラムの値がＭＦＰ１０１であることを示す「ｍｆｐ１」や「ｍｆｐ２」であるレコードから、ＭＦＰ１０１は、それぞれ自身の状態情報ファイルに対して更新権限および参照権限を有することがわかる。また、接続クライアント名カラムの値がスクリプト管理サーバ１０３の事前処理Ａｃｔｉｏｎであることを示す「ｓｃｒｉｐｔ１」であるレコードから、事前処理Ａｃｔｉｏｎは、以下の状態情報ファイルに対して更新権限および参照権限を有することがわかる。
【００５７】
すなわち、事前処理Ａｃｔｉｏｎは、「ｍｆｐ１」および「ｍｆｐ２」が示すＭＦＰ１０１の状態情報ファイルに対して更新権限および参照権限を有することがわかる。同様に、抽出処理Ａｃｔｉｏｎ３４４は、「ｍｆｐ１」および「ｍｆｐ２」が示すＭＦＰ１０１の状態情報ファイルに対して更新権限および参照権限を有することがわかる。
【００５８】
図３の説明に戻る。メッセージ生成部３３８は、スクリプト管理サーバ１０３から受信した指示に従い、ＭＦＰ１０１に対する状態情報の更新を指示するメッセージ（状態更新指示）を生成する。また、メッセージ生成部３３８は、通信部３３１を介して、生成した状態更新指示をＭＦＰ１０１に送信する。また、メッセージ生成部３３８は、通知制御部３３９の判定に従い、スクリプト管理サーバ１０３に対してスクリプトの駆動（起動）を指示するメッセージを生成し、通信部３３１を介して送信する。
【００５９】
通知制御部３３９は、メッセージ生成部３３８からスクリプト管理サーバ１０３へのスクリプト駆動の指示の送信を制御する。例えば、ＭＦＰ１０１から受信した状態情報ファイルの状態部４０３の送信ステータス４０６が「ｓｅｎｄｉｎｇ」から「ｃｏｍｐｌｅｔｅ」に更新された場合、通知制御部３３９は、スクリプト駆動の指示をスクリプト管理サーバ１０３へ送信すると判断する。
【００６０】
同様に、ＭＦＰ１０１から受信した状態情報ファイルの状態部４０３の送信ステータス４０６が「ｗａｉｔｉｎｇ」であり、かつ電源ステータス４０７が「ｏｆｆ」から「ｏｎ」に更新された場合、通知制御部３３９は、以下のように判断する。すなわち、通知制御部３３９は、スクリプト駆動の指示をスクリプト管理サーバ１０３へ送信すると判断する。また、通知制御部３３９は、上述した条件とは異なる場合、スクリプト駆動の指示をスクリプト管理サーバ１０３へ送信しないと判断する。
【００６１】
次に、スクリプト管理サーバ１０３のソフトウェア構成について説明する。スクリプト管理サーバ１０３は、スクリプト管理アプリケーション３４０を備える。スクリプト管理アプリケーション３４０は、各種イベントをトリガーとして駆動するスクリプト管理および実行を行う実行サービスとして機能する。通信部３４１、スクリプト管理データベース３４２、事前処理Ａｃｔｉｏｎ３４３、および抽出処理Ａｃｔｉｏｎ３４４から構成される。
【００６２】
通信部３４１は、ネットワークインタフェース２０２を介して状態管理サーバ１０２と通信を行う。スクリプト管理データベース３４２は、スクリプト管理アプリケーション３４０において管理するスクリプトを駆動する際のパラメータ等の管理情報を保存する。スクリプトの管理情報の一例を下表のスクリプト管理情報テーブルに示す。
【００６３】
【表５】
2019091180.tif 000007
【００６４】
スクリプト管理情報テーブルは、登録ＩＤ、スクリプト名、実行時間、およびパラメータから構成される。登録ＩＤカラムには、スクリプト管理アプリケーション３４０に登録されたスクリプトを一意に識別するための識別子が保存される。スクリプト名カラムには、実行時間カラムで指定された時刻に駆動されるスクリプト管理アプリケーション３４０のスクリプトの名称が保存される。本実施形態では、スクリプト名カラムの値が「ｓｃｒｉｐｔ１」のレコードは、事前処理Ａｃｔｉｏｎ３４３を表す。
【００６５】
実行時間カラムには、スクリプト管理アプリケーション３４０のスクリプトを駆動する時刻として登録されたスケジュールが保存される。パラメータカラムには、スケジュールの登録がなされたスクリプト管理アプリケーション３４０のスクリプトを駆動する際に渡すパラメータが保存される。本実施形態では、テナント１０５単位でＭＦＰ１０１への定期送信を行うようにスケジュール管理がなされている。このため、パラメータカラムには、管理対象とするテナント１０５の名称であるテナント名が保存される。
【００６６】
事前処理Ａｃｔｉｏｎ３４３は、状態管理サーバ１０２に対して状態情報の更新を指示するスクリプトである。事前処理Ａｃｔｉｏｎ３４３による処理の詳細は、図５および図６を用いて後述する。本実施形態では、事前処理Ａｃｔｉｏｎ３４３は、スクリプト管理データベース３４２に予め登録された管理情報に従い、該管理情報にてスケジュールされた時刻になると駆動される。
【００６７】
なお、上記のスクリプト管理情報テーブル（表５）の例に従うと、事前処理Ａｃｔｉｏｎ３４３は、毎日３時に駆動されるようにスケジュールされているが、これに限られるものではない。事前処理Ａｃｔｉｏｎ３４３は、所定の時刻に１回だけ駆動されてもよいし、任意の時間間隔で定期的に駆動されてもよい。
【００６８】
抽出処理Ａｃｔｉｏｎ３４４は、事前処理Ａｃｔｉｏｎ３４３と同様に、状態管理サーバ１０２に対して状態情報の更新を指示するスクリプトである。抽出処理Ａｃｔｉｏｎ３４４による処理の詳細は、図５および図７を用いて後述する。抽出処理Ａｃｔｉｏｎ３４４は、事前処理Ａｃｔｉｏｎ３４３および状態管理サーバ１０２の状態更新イベントを受けて駆動される。抽出処理Ａｃｔｉｏｎ３４４が駆動されるスケジュールについては、事前処理Ａｃｔｉｏｎ３４３と同様である。
【００６９】
なお、サーバアプリケーション３３０、事前処理Ａｃｔｉｏｎ３４３、抽出処理Ａｃｔｉｏｎ３４４は、それぞれ別の仮想マシンで実行される場合もあれば、１または２つの仮想マシンで実行される場合もある。具体的には、１つの仮想マシンでこれらのソフトウェアが実行される場合もあれば、それぞれのソフトウェアの組み合わせが１つの仮想マシンで実行される場合もある。すなわち、本システムを構成する各仮想マシンは、図３に示した状態管理サーバ１０２およびスクリプト管理サーバ１０３の各ソフトウェアの１つまたは２つ以上の機能を実現する。
【００７０】
次に、ファイル管理アプリケーション３５０のソフトウェア構成について説明する。ファイル管理アプリケーション３５０は、ＭＦＰ１０１から定期的に送信されるファイルの実体を受信し、保存するストレージサービスとして機能する。ファイル管理アプリケーション３５０は、通信部３５１、ファイル管理部３５２、およびファイル保存部３５３から構成される。通信部３５１は、ネットワークインタフェース２０２を介してＭＦＰ１０１と通信を行う。
【００７１】
ファイル管理部３５２は、通信部３５１を介してＭＦＰ１０１からのファイル保存や取得等の各種要求を受信する。ファイル保存部３５３は、ファイル管理部３５２の指示に従い、ＭＦＰ１０１から受信したファイルの実体を保存する。
【００７２】
＜処理シーケンス＞
図５は、本実施形態に係るシステムにおいて、複数のＭＦＰ１０１からファイル管理サーバ１０４へのデータ送信が行われる際の処理を説明するシーケンス図である。
予め設定された時刻になると、テナント１０５内の複数のＭＦＰ１０１から大容量データがファイル管理サーバ１０４に送信される。
【００７３】
このとき、ＭＦＰ１０１のデータ送信のタイミングが重なると、テナント１０５のネットワークトラフィックが逼迫してしまう。このため、本実施形態では、データ送信のタイミングが重ならないように、テナント１０５内のＭＦＰ１０１が順番にデータ送信を行うように制御される。なお、本実施形態では、１台ずつＭＦＰ１０１がデータ送信を行うように制御する場合について説明するが、これに限られるものではない。第４実施形態では、並列して複数台のＭＦＰ１０１がデータ送信を行うように制御する場合についても説明する。
【００７４】
ステップＳ５００において、スクリプト管理サーバ１０３のスクリプト管理アプリケーション３４０が所定の時刻になると事前処理Ａｃｔｉｏｎ３４３を駆動する。詳細には、スクリプト管理データベース３４２において予め登録された管理情報に従い、所定の時刻になると、事前処理Ａｃｔｉｏｎ３４３が駆動する。
【００７５】
以下、スクリプト管理情報テーブル（表５）の１レコード目に従いｓｃｒｉｐｔ１である事前処理Ａｃｔｉｏｎ３４３が駆動されるものとして説明する。このとき、事前処理Ａｃｔｉｏｎ３４３は、駆動する際のパラメータとして、テナント名を示す「ｔｅｎａｎｔ１」を受け取るものとする。
【００７６】
ステップＳ５０１において、事前処理Ａｃｔｉｏｎ３４３は、状態管理サーバ１０２が管理するテナント１０５内の全てのＭＦＰ１０１の状態情報ファイルについて、該状態情報ファイルの指示部の送信ステータスを「ｗａｉｔｉｎｇ」に更新する指示を行う。以下、ステップＳ５０１の処理の詳細について説明する。
【００７７】
図６は、事前処理Ａｃｔｉｏｎ３４３が実行するステップＳ５０１の処理を説明するためのフローチャートである。
ステップＳ６００において、事前処理Ａｃｔｉｏｎ３４３は、通信部３４１を介して、状態管理サーバ１０２のテナント管理部３３２に対してパラメータで指定されたテナント名に関連するクライアントのリストを要求する。
【００７８】
なお、上述したように、パラメータとして「ｔｅｎａｎｔ１」が指定されたものとして説明する。テナント管理部３３２は、テナント管理データベース３３３が管理するテナント関連情報テーブル（表１）のテナント名カラムの値が「ｔｅｎａｎｔ１」と一致するレコードのリストを取得し、通信部３３１を介して事前処理Ａｃｔｉｏｎ３４３に返却する。以下、取得したレコードに含まれるクライアント名の一覧をクライアントリストと呼ぶことにする。
【００７９】
ステップＳ６０１において、事前処理Ａｃｔｉｏｎ３４３は、通信部３４１を介して、状態管理サーバ１０２のクライアント管理部３３４に対して、取得したクライアントリストのクライアントの状態情報の更新を指示する。具体的には、事前処理Ａｃｔｉｏｎ３４３は、図４に示すような状態情報ファイル４１０をクライアント管理部３３４に送信することにより、クライアント管理部３３４に対してクライアントの状態情報の更新を指示する。
【００８０】
状態情報ファイル４１０の主な構成要素は、状態情報ファイル４００と同様のため、ここでは、状態情報ファイル４００との差異のみ説明する。状態情報ファイル４１０の指示部４１１には、送信ステータスを「ｗａｉｔｉｎｇ」とする指示が格納されている。これにより、クライアントであるＭＦＰ１０１によるデータの送信状態を送信待ちに更新できる。なお、状態情報ファイル４１０において、状態情報ファイル４００の状態部４０３に対応する部分には、情報は格納されず空である。
【００８１】
クライアント管理部３３４は、状態情報ファイル４１０を受信すると、該ファイルの内容に従い、クライアントデータベース３３５で管理するクライアントの状態情報を更新する。
【００８２】
図６の説明に戻る。ステップＳ６０２において、事前処理Ａｃｔｉｏｎ３４３は、ステップＳ６００にて取得したクライアントリストの全てのクライアントの状態情報の更新を指示したか判断する。全てのクライアントの状態情報の更新を指示した場合、図６の処理を終了し、全てのクライアントの状態情報の更新の指示が完了していない場合、処理はステップＳ６０１に戻り、完了するまでステップＳ６０２の処理が繰り返される。
【００８３】
図５の説明に戻る。ステップＳ５０２において、事前処理Ａｃｔｉｏｎ３４３は、抽出処理Ａｃｔｉｏｎ３４４を駆動する。また、事前処理Ａｃｔｉｏｎ３４３は、抽出処理Ａｃｔｉｏｎ３４４を駆動する際のパラメータとして、事前処理Ａｃｔｉｏｎ３４３が駆動された際に受け取ったテナント名を渡す。なお、上述したように、ここでは該パラメータとして「ｔｅｎａｎｔ１」が渡されたものとして説明する。
【００８４】
ステップＳ５１０において、抽出処理Ａｃｔｉｏｎ３４４は、状態管理サーバ１０２が管理するテナント１０５内のＭＦＰ１０１の中から、指示部の送信ステータスが「ｗａｉｔｉｎｇ」である、すなわちデータ送信待ちのＭＦＰ１０１を１つ選ぶ。そして、選んだＭＦＰ１０１の状態情報ファイルの指示部の送信ステータスを「ｓｅｎｄｉｎｇ」に更新する指示を行う。以下、ステップＳ５１０の処理の詳細について説明する。
【００８５】
図７は、抽出処理Ａｃｔｉｏｎ３４４が実行するステップＳ５１０の処理を説明するためのフローチャートである。
ステップＳ７００において、抽出処理Ａｃｔｉｏｎ３４４は、通信部３４１を介して、状態管理サーバ１０２のテナント管理部３３２に対してパラメータで指定されたテナント名に関連するクライアントのリストを要求する。
【００８６】
なお、上述したように、パラメータとして「ｔｅｎａｎｔ１」が指定されたものとして説明する。テナント管理部３３２は、テナント管理データベース３３３が管理するテナント管理情報テーブル（表１）のテナント名カラムの値が「ｔｅｎａｎｔ１」に一致するレコードのリスト（クライアントリスト）を取得する。そして、テナント管理部３３２は、取得したクライアントリストを通信部３３１を介して抽出処理Ａｃｔｉｏｎ３４４に返却する。
【００８７】
ステップＳ７０１において、抽出処理Ａｃｔｉｏｎ３４４は、通信部３４１を介して、状態管理サーバ１０２のクライアント管理部３３４に対して、取得したクライアントリストに含まれるクライアントの状態情報のリストを要求する。クライアント管理部３３４は、クライアントデータベース３３５が管理する状態情報テーブル（表２）の状態情報名カラムの値がクライアントリストに含まれるクライアントの名称と一致するレコードのリスト（状態情報リスト）を取得する。そして、クライアント管理部３３４は、取得した状態情報リストを、通信部３３１を介して抽出処理Ａｃｔｉｏｎ３４４に返却する。
【００８８】
ステップＳ７０２において、抽出処理Ａｃｔｉｏｎ３４４は、ステップＳ７０１で取得した状態情報リストに含まれる状態情報ファイルのうち、以下の条件を満たす状態情報ファイルを抽出する。抽出処理Ａｃｔｉｏｎ３４４は、状態情報ファイルの状態部４０３に格納された送信ステータス４０６が「ｗａｉｔｉｎｇ」であり、かつ電源ステータス４０７が「ｏｎ」である状態情報ファイルを抽出する。
【００８９】
なお、上述したように、抽出処理Ａｃｔｉｏｎ３４４の対象を抽出する際に、送信ステータス４０６および電源ステータス４０７を条件としたが、これに限られるものではない。電源ステータス４０７の値によらず、送信ステータス４０６が「ｗａｉｔｉｎｇ」の状態情報ファイルを抽出してもよい。
【００９０】
ステップＳ７０３において、抽出処理Ａｃｔｉｏｎ３４４は、ステップＳ７０２で取得した状態情報ファイルから１つを選択する。ステップＳ７０４において、抽出処理Ａｃｔｉｏｎ３４４は、ステップＳ７０３で１つの状態情報ファイルを選択できた場合、ステップＳ７０５の処理に進む。
【００９１】
ステップＳ７０３で１つの状態情報ファイルを選択できなかった場合、テナント１０５内に状態更新指示を送信可能なＭＦＰ１０１がなくなった、すなわちファイル管理サーバ１０４へのデータ送信が完了していないＭＦＰ１０１がないと判断する。そして、抽出処理Ａｃｔｉｏｎ３４４は、図９の処理を終了するとともに、図５の処理を終了する。
【００９２】
ステップＳ７０５において、抽出処理Ａｃｔｉｏｎ３４４は、ステップＳ７０３で取得した状態情報ファイルの指示部の送信ステータスを「ｓｅｎｄｉｎｇ」に更新させるため、以下を実行する。抽出処理Ａｃｔｉｏｎ３４４は、通信部３４１を介して、状態管理サーバ１０２のクライアント管理部３３４に対して、該クライアントの状態情報の更新を指示する。具体的には、抽出処理Ａｃｔｉｏｎ３４４は、図４に示すような状態情報ファイル４２０を送信することにより、クライアント管理部３３４に対してクライアントの状態情報の更新を指示する。
【００９３】
状態情報ファイル４２０の主な構成要素は、状態情報ファイル４００および４１０と同様のため、ここでは、状態情報ファイル４００および４１０との差異のみ説明する。状態情報ファイル４２０の指示部４２１には、データ送信を指示する情報として、送信ステータスに「ｓｅｎｄｉｎｇ」が格納されている。これにより、クライアントであるＭＦＰ１０１によるデータの送信状態を送信中に更新できる。
【００９４】
クライアント管理部３３４は、状態情報ファイル４２０を受信すると、該ファイルの内容に従い、クライアントデータベース３３５で管理するクライアントの状態情報を更新する。そして、抽出処理Ａｃｔｉｏｎ３４４は、図７の処理を終了する。
【００９５】
図５の説明に戻る。ステップＳ５１１において、状態管理サーバ１０２のサーバアプリケーション３３０は、ステップＳ５１０で状態情報ファイルの指示部の送信ステータスが「ｓｅｎｄｉｎｇ」に更新されたＭＦＰ１０１に対して、状態情報の更新を指示する。言い換えると、状態管理サーバ１０２は、ＭＦＰ１０１に対して、データ送信を指示する。具体的には、サーバアプリケーション３３０のメッセージ生成部３３８は、通信部３３１を介してＭＦＰ１０１に状態情報ファイル４２０を送信することにより、該ＭＦＰ１０１に対してデータ送信を指示する。
【００９６】
ステップＳ５１２において、ＭＦＰ１０１のメッセージ解析部３１３は、通信部３１１を介して状態管理サーバ１０２から状態情報ファイル４２０を受信する。そして、メッセージ解析部３１３は、受信した状態情報ファイル４２０の指示部４２１が示す状態更新指示を状態管理部３１４に送信する。状態管理部３１４は、状態情報ファイル４２０の指示部４２１に格納された送信ステータスが「ｓｅｎｄｉｎｇ」の場合、データ管理アプリケーション３２０のデータ管理部３２２に対してデータ送信を指示する。
【００９７】
ステップＳ５１３において、ＭＦＰ１０１は、ファイル管理サーバ１０４に対して自身の格納しているデバイス情報の送信を開始する。具体的には、データ管理アプリケーション３２０のデータ管理部３２２は、通信部３２１を介して、データ保存部３２３に格納されているデバイス情報をファイル管理アプリケーション３５０に対して送信を開始する。
【００９８】
ファイル管理アプリケーション３５０のファイル管理部３５２は、通信部３５１を介して、ＭＦＰ１０１からデバイス情報を受信する。ファイル管理部３５２は、受信したデバイス情報をファイル保存部３５３に格納する。なお、本発明では、ファイル保存部３５３がデバイス情報を管理する方法に関しては、特に限定しないものとする。
【００９９】
ステップＳ５１５において、データ管理アプリケーション３２０のデータ管理部３２２は、ステップＳ５１３で開始したデバイス情報の送信が完了すると、クライアントアプリケーション３１０の状態管理部３１４に対して、送信完了の通知を送信する。ステップＳ５１６において、状態管理部３１４は、データ管理部３２２から送信完了の通知を受信すると、状態管理サーバ１０２のサーバアプリケーション３３０に対して、ファイル管理サーバ１０４へのデータ送信が完了したことを通知する。
【０１００】
具体的には、状態管理部３１４は、図８に示すような状態情報ファイル８００を送信することにより、サーバアプリケーション３３０のクライアント管理部３３４に対してファイル管理サーバ１０４へのデータ送信が完了したことを通知する。状態情報ファイル８００は、状態管理部３１４がメッセージ生成部３１２に対して生成を指示し、メッセージ生成部３１２により生成される。
【０１０１】
図８は、ステップＳ５１６にて、ファイル管理サーバ１０４へのデータ送信が完了したことを通知するために送信される状態情報ファイルの一例である。
状態情報ファイル８００の主な構成要素は、状態情報ファイル４００等と同様のため、ここでは差異のみ説明する。状態情報ファイル８００の状態部には、ＭＦＰ１０１によるデータ送信が完了した状態であることを示す情報として、送信ステータス８０１に「ｃｏｍｐｌｅｔｅ」が格納されている。
【０１０２】
状態管理サーバ１０２のクライアント管理部３３４は、通信部３３１を介して、ＭＦＰ１０１から状態情報ファイル８００を受信する。クライアント管理部３３４は、クライアントデータベース３３５が管理する状態情報テーブル（表２）の該当するクライアントの状態情報ファイルを、受信した状態情報ファイル８００で更新する。
【０１０３】
図５の説明に戻る。ステップＳ５１７において、状態管理サーバ１０２の通知制御部３３９は、スクリプト管理サーバ１０３に対してスクリプト駆動を指示するか判断する。具体的には、ステップＳ５１６で状態情報ファイル８００を受信したことにより、クライアントデータベース３３５で管理する状態情報ファイルの状態部の送信ステータスが「ｓｅｎｄｉｎｇ」から「ｃｏｍｐｌｅｔｅ」に更新された。
【０１０４】
この送信ステータスの変更内容は、スクリプト管理サーバ１０３にスクリプト駆動を指示する条件と一致する。このため、通知制御部３３９は、スクリプト管理サーバ１０３に対してスクリプト駆動を指示すると判断して、処理はステップＳ５１８に進む。スクリプト駆動を指示する条件と一致しない場合、通知制御部３３９は、スクリプト管理サーバ１０３に対してスクリプト駆動を指示しないと判断して図５の処理を終了する。
【０１０５】
ステップＳ５１８において、状態管理サーバ１０２のメッセージ生成部３３８は、テナント管理部３３２に対してステップＳ５１６で受信した状態情報ファイル８００の送信元であるＭＦＰ１０１に関連するテナント名を要求する。テナント管理部３３２は、状態情報ファイル８００の送信元であるＭＦＰ１０１に関連するテナント名をテナント管理データベース３３３から取得し、メッセージ生成部３３８に返却する。
【０１０６】
なお、状態情報ファイル８００にテナント名が記載されていてもよい。その場合、メッセージ生成部３３８は、テナント管理部３３２を介してテナント名を取得することなく、状態情報ファイル８００からテナント名を取得してもよい。メッセージ生成部３３８は、通信部３３１を介して、スクリプト管理サーバ１０３に対しての抽出処理Ａｃｔｉｏｎ３４４の駆動を指示する。
【０１０７】
このとき、メッセージ生成部３３８は、抽出処理Ａｃｔｉｏｎ３４４を駆動する際のパラメータとして、取得したテナント名を渡す。抽出処理Ａｃｔｉｏｎ３４４は、通信部３４１を介して受信した駆動指示からパラメータとして指定されているテナント名を取得し、処理を開始する。抽出処理Ａｃｔｉｏｎ３４４が実行する処理は、ステップＳ５１０と同様のため、その説明を省略する。
【０１０８】
ここまでの説明により、テナント１０５内にファイル管理サーバ１０４へのデータ送信が完了していないＭＦＰ１０１がなくなるまで、１台ずつＭＦＰ１０１からのデータ送信が実行される。なお、上述した処理において、ステップＳ５１０、詳細には図７のステップＳ７０２で説明したように、抽出処理Ａｃｔｉｏｎ３４４は、ＭＦＰ１０１の電源がオフだった場合、データ送信が不可能であると判断し、状態更新指示の対象としない。
【０１０９】
そのため、しばらく電源がオフだったＭＦＰ１０１の電源がオンになったとしても、該ＭＦＰ１０１は、ステップＳ７０２において状態更新指示の対象から外れており、図５のステップＳ５１０〜ステップＳ５１８までのデータ送信リレーには含まれない。例えば、テナント１０５内のＭＦＰ１０１のデータ送信が開始してからや、全て完了した後等に、電源がオフだったＭＦＰ１０１の電源がオンになったとしても、データ送信リレーに含まれず、またはデータ送信リレーが完了してしまっている。
【０１１０】
このため、定期的なデータ送信のスケジュールに従って次にデータ送信リレーが開始されるまで該ＭＦＰ１０１のデータ送信が行われない。そこで、本実施形態では、ＭＦＰ１０１の電源がオンになったことをトリガーとして抽出処理Ａｃｔｉｏｎ３４４を駆動することにより、データ送信の待ち時間を軽減する。この処理は、図５に示すステップＳ５５０〜Ｓ５５３により実現する。以下、ステップＳ５５０〜Ｓ５５３の処理について説明する。
【０１１１】
ステップＳ５５０において、ＭＦＰ１０１の電源がオフからオンに変更される。ステップＳ５５１において、ＭＦＰ１０１の状態管理部３１４は、状態管理サーバ１０２に対して、ＭＦＰ１０１の電源ステータスが更新されたことを通知する。具体的には、状態管理部３１４は、図８に示すような状態情報ファイル８１０を送信することにより、状態管理サーバ１０２のクライアント管理部３３４に対してＭＦＰ１０１の電源ステータスが更新されたことを通知する。状態情報ファイル８１０は、状態管理部３１４がメッセージ生成部３１２に対して生成を指示し、メッセージ生成部３１２により生成される。
【０１１２】
図８は、ステップＳ５５１にてＭＦＰ１０１の電源ステータスが更新されたことを通知するために送信される状態情報ファイルの一例である。
状態情報ファイル８１０の主な構成要素は、状態情報ファイル４００等と同様のため、ここでは差異のみ説明する。
【０１１３】
状態情報ファイル８１０の状態部の送信ステータス８１１には、ＭＦＰ１０１がデータ送信待ちの状態であることを示す情報（「ｗａｉｔｉｎｇ」）が格納されている。なお、既にデータ送信が完了していた場合、送信ステータス８１１には「ｃｏｍｐｌｅｔｅ」が格納されている。また、状態部の電源ステータス８１２には、ＭＦＰ１０１の電源がオンの状態であることを示す「ｏｎ」が格納されている。
【０１１４】
状態管理サーバ１０２のクライアント管理部３３４は、通信部３３１を介して、ＭＦＰ１０１から状態情報ファイル８１０を受信する。クライアント管理部３３４は、クライアントデータベース３３５が管理する状態情報テーブル（表２）の該当するクライアントの状態情報ファイルを、受信した状態情報ファイル８１０で更新する。
【０１１５】
図５の説明に戻る。ステップＳ５５２において、状態管理サーバ１０２の通知制御部３３９は、スクリプト管理サーバ１０３に対してスクリプト駆動を指示するか判断する。具体的には、ステップＳ５５１で状態情報ファイル８１０を受信したことにより、クライアントデータベース３３５で管理する状態情報ファイルの状態部の送信ステータスが「ｗａｉｔｉｎｇ」であり、かつ電源ステータスが「ｏｆｆ」から「ｏｎ」に変更された。
【０１１６】
この送信ステータスの変更内容は、スクリプト管理サーバ１０３にスクリプト駆動を指示する条件と一致する。このため、通知制御部３３９は、スクリプト管理サーバ１０３に対してスクリプト駆動を指示すると判断して、処理はステップＳ５５３に進む。スクリプト駆動を指示する条件と一致しない場合、通知制御部３３９は、スクリプト管理サーバ１０３に対してスクリプト駆動を指示しないと判断して図５の処理を終了する。ステップＳ５５３の処理は、ステップＳ５１８と同様のため、その説明を省略する。
【０１１７】
なお、ステップＳ５５０〜Ｓ５５３では、ＭＦＰ１０１の電源ステータスが更新されたことを契機に抽出処理Ａｃｔｉｏｎ３４４を駆動する場合について説明したが、電源ステータスに限られるものではない。その他、ＭＦＰ１０１にて状態や設定値等が更新されたことにより、ステップＳ５５０〜Ｓ５５３と同様の処理を行い、抽出処理Ａｃｔｉｏｎ３４４が駆動されるようにしてもよい。
【０１１８】
以上のように、本実施形態によれば、ネットワーク負荷を抑制しつつ効果的に複数のネットワークデバイスからのデータ送信を制御することが可能となる。例えば、テナント内の複数のＭＦＰ１０１が大容量データを送信する場合、データ送信のスケジュール調整で発生する通信のネットワーク負荷を抑えながら、テナント側の負荷や分析ニーズを考慮した細やかな制御を行うことができる。
【０１１９】
［第２実施形態］
第１実施形態では、テナント１０５内のＭＦＰ１０１からデータ送信が行われる際に、ＭＦＰ１０１が順番に１台ずつデータ送信を行うように制御するシステムについて説明した。しかしながら、第１実施形態のシステムでは、以下のような場合、複数のＭＦＰ１０１からのデータ送信のタイミングが重なる可能性がある。
【０１２０】
例えば、ステップＳ５１０〜Ｓ５１８によりデータ送信を実行するＭＦＰ１０１と、ステップＳ５５０〜Ｓ５５３によりデータ送信を実行するＭＦＰ１０１とが、それぞれデータ送信を実行した場合などである。これは、データ送信待ちの状態のＭＦＰ１０１の電源がオンになることで、該ＭＦＰ１０１が属するテナント１０５内において他にデータ送信中のＭＦＰ１０１が存在するか否かに関わらず抽出処理Ａｃｔｉｏｎ３４４が駆動されるためである。
【０１２１】
このように、テナント１０５内においてデータ送信中のＭＦＰ１０１が存在し、新たに駆動された抽出処理Ａｃｔｉｏｎ３４４によって他のＭＦＰ１０１がデータ送信を開始する場合、１つのテナント１０５内でデータ送信のタイミングが重なり得る。データ送信が並行して実行されるＭＦＰ１０１の数が２つ程度であれば、ネットワークトラフィックへの影響は小さいと判断できる。しかし、多数のＭＦＰ１０１が一斉に電源オフから電源オンになる等、多数のＭＦＰ１０１によるデータ送信のタイミングが重なる場合、ネットワークトラフィックが逼迫する可能性がある。
【０１２２】
これに対して、本実施形態では、１つのテナント内におけるＭＦＰ１０１によるデータ送信に優先度をつけ、１つのテナント内において、１台ずつＭＦＰ１０１によるデータ送信が実行されるように制御する。データ送信の優先度は、各ＭＦＰ１０１の前回のデータ送信を行った時間情報に基づいて決定する。
【０１２３】
該時間情報が古い日時を示すＭＦＰ１０１のデータ送信を優先させ、該時間情報が新しい日時を示すＭＦＰ１０１のデータ送信をキャンセルする。これにより、１つのテナント内においてＭＦＰ１０１によるデータ送信が１台ずつ行われるように制御できる。以下、第１実施形態と同一構成のものには同一の符号を付し、第１実施形態との差異のみ説明する。
【０１２４】
図９は、ＭＦＰ１０１がファイル管理サーバ１０４へのデータ送信を完了したことを状態管理サーバ１０２に通知するために送信する状態情報ファイルの一例である。
状態情報ファイル９００の主な構成要素は、状態情報ファイル４００等と同様のため、ここでは差異のみ説明する。
【０１２５】
状態情報ファイル９００の状態部には、前回のデータ送信を行った時間情報９０１が含まれる。本実施形態では、時間情報９０１としてＭＦＰ１０１がファイル管理サーバ１０４に対するデータ送信を完了した直後の日時を格納するが、これに限られるものではない。例えば、データ送信を開始した日時であってもよい。
【０１２６】
図１０は、本実施形態において抽出処理Ａｃｔｉｏｎ３４４が実行する処理を説明するためのフローチャートである。
ステップＳ１０００〜Ｓ１００２の処理は、図７のステップＳ７００〜Ｓ７０２と同様のため、その説明を省略する。
【０１２７】
ステップＳ１００３において、抽出処理Ａｃｔｉｏｎ３４４は、ステップＳ１００２で取得した状態情報ファイルから、状態情報ファイルの状態部が含む時間情報、すなわち、前回のデータ送信を行った日時が最も古い状態情報ファイルを１つ選択する。ここで選択される状態情報ファイルは、テナント１０５内において、データ送信待ちの状態にあるＭＦＰ１０１のうち、前回のデータ送信を行った日時が最も古いＭＦＰ１０１に対応する状態情報ファイルである。
【０１２８】
ステップＳ１００４において、抽出処理Ａｃｔｉｏｎ３４４は、ステップＳ１００３にて状態情報ファイルが１つ選択できたか判断する。状態情報ファイルが１つ選択できた場合、処理はステップＳ１００５に進む。一方、状態情報ファイルが選択できなかった場合、テナント１０５内に状態更新指示を送信可能なＭＦＰ１０１がなくなった、すなわちファイル管理サーバ１０４へデータ送信が完了していないＭＦＰ１０１がないと判断する。そして、抽出処理Ａｃｔｉｏｎ３４４は、図１０の処理を終了するとともに、図５の処理を終了する。
【０１２９】
ステップＳ１００５において、抽出処理Ａｃｔｉｏｎ３４４は、ステップＳ１００１で取得した状態情報リストに含まれる情報ファイルのうち、以下の条件を満たす情報ファイルを抽出する。抽出処理Ａｃｔｉｏｎ３４４は、状態情報ファイルの状態部に格納された送信ステータスが「ｓｅｎｄｉｎｇ」であり、かつ電源ステータスが「ｏｎ」である状態情報ファイルを抽出する。ここで選択される状態情報ファイルは、テナント１０５内において、データ送信中の状態にあるＭＦＰ１０１のうち、前回のデータ送信を行った日時が最も古いＭＦＰ１０１に対応する状態情報ファイルである。
【０１３０】
ステップＳ１００６において、抽出処理Ａｃｔｉｏｎ３４４は、ステップＳ１００５で取得した状態情報ファイルから状態情報ファイルの状態部が含む時間情報、すなわち前回のデータ送信を行った日時が最も新しい状態情報ファイルを１つ選択する。なお、ここで選択する状態情報ファイルは、現在データ送信中であって、前回のデータ送信を行った日時が最も新しいＭＦＰ１０１に対応する。しかし、選択する状態情報ファイルは、これに限られるものではない。
【０１３１】
ここでの選択は、以下のステップＳ１００８において送信待ち状態のＭＦＰ１０１の状態情報ファイルとの比較対象を選択するものであり、現在データ送信中の状態情報ファイルから任意に選択してもよい。例えば、前回のデータ送信を行った日時が最も古いＭＦＰ１０１の状態情報ファイルを選択してもよい。ステップＳ１００７において、抽出処理Ａｃｔｉｏｎ３４４は、ステップＳ１００６にて状態情報ファイルが１つ選択できたか判断する。
【０１３２】
状態情報ファイルが選択できた場合、処理はステップＳ１００８に進み、状態情報ファイルが選択できなかった場合、テナント１０５内において、データ送信中のＭＦＰ１０１がないと判断し、処理はステップＳ１０１０に進む。ステップＳ１００８において、抽出処理Ａｃｔｉｏｎ３４４は、ステップＳ１００３で取得した状態情報ファイルの状態部が含む時間情報と、ステップＳ１００６で取得した状態情報ファイルの状態部が含む時間情報とを比較する。
【０１３３】
そして、抽出処理Ａｃｔｉｏｎ３４４は、ステップＳ１００３で取得した状態情報ファイルの状態部が含む時間情報が、ステップＳ１００６で取得した状態情報ファイルの状態部が含む時間情報より古いか判断する。すなわち、抽出処理Ａｃｔｉｏｎ３４４は、データ送信待ち状態のＭＦＰ１０１が前回データ送信を行った日時が、データ送信中のＭＦＰ１０１が前回データ送信を行った日時よりも古いか判断する。
【０１３４】
そして、抽出処理Ａｃｔｉｏｎ３４４は、データ送信待ち状態のＭＦＰ１０１が前回データ送信を行った日時が、データ送信中のＭＦＰ１０１が前回データ送信を行った日時よりも古い場合、データ送信待ちのＭＦＰ１０１のデータ送信を優先する。この場合、処理はステップＳ１００９に進む。
【０１３５】
一方、データ送信待ち状態のＭＦＰ１０１が前回データ送信を行った日時が、データ送信中のＭＦＰ１０１が前回データ送信を行った日時よりも新しい場合、以降の処理は行わず、図１０の処理を終了する。すなわち、現在データ送信中のＭＦＰ１０１の処理はキャンセルされず、続行される。
【０１３６】
ステップＳ１００９において、抽出処理Ａｃｔｉｏｎ３４４は、ステップＳ１００６で取得した状態情報ファイルの指示部の送信ステータスを、データ送信の中止を指示する「ｃａｎｃｅｌ」に更新させるため、以下を実行する。抽出処理Ａｃｔｉｏｎ３４４は、通信部３４１を介して、状態管理サーバ１０２のクライアント管理部３３４に対して、該クライアントの状態情報の更新を指示する。具体的には、抽出処理Ａｃｔｉｏｎ３４４は、図１１に示すような状態情報ファイル１１００を送信することにより、クライアント管理部３３４に対してクライアントの状態情報を指示する。
【０１３７】
図１１は、抽出処理Ａｃｔｉｏｎ３４４が、ＭＦＰ１０１のデータ送信を抽出させるために、状態管理サーバ１０２を介してＭＦＰ１０１に送信する状態情報ファイルの一例である。
状態情報ファイル１１００の主な構成要素は、状態情報ファイル４００等と同様のため、ここでは差異のみ説明する。
【０１３８】
状態情報ファイル１１００の指示部１１０１には、データ送信の中止を指示する情報として、送信ステータスに「ｃａｎｃｅｌ」が格納される。なお、本実施形態では、データ送信の中止を指示する際に送信ステータスに格納される情報を「ｃａｎｃｅｌ」としたが、これに限られるものではない。例えば、送信スタータスに「ｗａｉｔｉｎｇ」を格納することにより、データ送信の中止を指示する意味を持たせてもよい。この場合は、指示部１１０１の送信ステータスは「ｗａｉｔｉｎｇ」とすればよい。
【０１３９】
図１０の説明に戻る。クライアント管理部３３４は、状態情報ファイル１１００を受信すると、該ファイルの内容に従い、クライアントデータベース３３５で管理するクライアントの状態情報を更新する。そして、クライアント管理部３３４は、状態情報を更新したＭＦＰ１０１に対して、状態情報の更新を指示する。具体的には、クライアント管理部３３４は、通信部３３１を介して該ＭＦＰ１０１に状態情報ファイル１１００を送信することにより、該ＭＦＰ１０１に対してデータ送信の中止を指示する。
【０１４０】
ＭＦＰ１０１は、状態情報ファイル１１００を受信すると、ファイル管理サーバ１０４へのデータ送信を強制停止する。なお、次のデータ送信の指示があった場合には、最初からデータ送信をやり直すため、今回の送信処理の内容はリセットされる。また、ＭＦＰ１０１は、データ送信待ちの状態に戻るため、ＭＦＰ１０１の状態管理部３１４は、状態管理サーバ１０２のサーバアプリケーション３３０に対して、データ送信待ちの状態であることを通知する。
【０１４１】
具体的には、状態管理部３１４は、状態情報ファイルの状態部の送信ステータスを「ｗａｉｔｉｎｇ」とした状態情報ファイルをサーバアプリケーション３３０のクライアント管理部３３４に対して送信する。
【０１４２】
ステップＳ１０１０において、抽出処理Ａｃｔｉｏｎ３４４は、ステップＳ１００３で取得した状態情報ファイルの指示部の送信ステータスを「ｓｅｎｄｉｎｇ」に更新させるため、以下を実行する。抽出処理Ａｃｔｉｏｎ３４４は、通信部３４１を介して、状態管理サーバ１０２のクライアント管理部３３４に対して、該クライアントの状態情報の更新を指示する。具体的には、抽出処理Ａｃｔｉｏｎ３４４は、図４に示すような状態情報ファイル４２０を送信することにより、クライアント管理部３３４に対してクライアントの状態情報の更新を指示する。
【０１４３】
クライアント管理部３３４は、状態情報ファイル４２０を受信すると、該ファイルの内容に従い、クライアントデータベース３３５で管理するクライアントの状態情報を更新する。そして、抽出処理Ａｃｔｉｏｎ３４４は、図１０の処理を終了する。
【０１４４】
［第３実施形態］
第２実施形態では、１つのテナント内において、テナント１０５内のＭＦＰ１０１からデータ送信が行われる際に、データ送信のタイミングが重複しないように制御するシステムについて説明した。しかしながら、第２実施形態のシステムでは、特定の条件においてデータ送信のキャンセルが頻発し、テナント１０５内の全てのＭＦＰ１０１のデータ送信が完了するまで時間がかかる可能性がある。
【０１４５】
例えば、計画停電等により、テナント１０５内の複数のＭＦＰ１０１の電源がオフの状態にあり、かつ、事前処理Ａｃｔｉｏｎ３４３によりそれらのＭＦＰ１０１が送信待ちの状態である場合等が考えられる。このような場合に、テナント１０５内の停電が回復してフロア単位に複数のＭＦＰ１０１の電源がオンになると、電源がオンになったＭＦＰ１０１の数だけ抽出処理Ａｃｔｉｏｎ３４４が駆動されることになる。
【０１４６】
第２実施形態では、抽出処理Ａｃｔｉｏｎ３４４は、データ送信中のＭＦＰ１０１に対して、前回のデータ送信を行った日時が、送信待ちのＭＦＰ１０１のそれよりも古くなければデータ送信の中止を指示する。そのため、テナント１０５内のＭＦＰ１０１の電源がオンになる順序次第では、データ送信の指示と中止の指示が頻発し、テナント１０５内の全てのＭＦＰ１０１のデータ送信が完了するまでに時間がかかる可能性がある。
【０１４７】
これに対して、本実施形態では、前回のデータ送信を行った日時を比較してデータ送信の優先度を決定する際に、予め設定された許容値を加味することで、データ送信の中止を指示する頻度を抑制するように制御する。例えば、許容値を「２４時間」と設定する。
【０１４８】
この場合、データ送信中のＭＦＰ１０１よりも送信待ちのＭＦＰ１０１の方が前回のデータ送信を行った日時が古い場合であっても、その差が許容値の２４時間以上でなければ、現在データ送信中のＭＦＰ１０１の処理はキャンセルされない。そして、データ送信が続行される。以下、第１実施形態および第２実施形態と同一構成のものには同一の符号を付し、その説明を省略する。
【０１４９】
本実施形態と第２実施形態との差異は、図１０に示した抽出処理Ａｃｔｉｏｎが実行する処理において、ステップＳ１００８のみである。以下、本実施形態に係るステップＳ１００８の処理について説明する。
【０１５０】
ステップＳ１００８において、抽出処理Ａｃｔｉｏｎ３４４は、ステップＳ１００３で取得した状態情報ファイルの状態部が含む時間情報に予め設定された許容値を加える。そして、該許容値を加えた時間情報と、ステップＳ１００６で取得した状態情報ファイルの状態部が含む時間情報とを比較する。
【０１５１】
そして、抽出処理Ａｃｔｉｏｎ３４４は、許容値を加えた時間情報が、ステップＳ１００６で取得した状態情報ファイルの状態部が含む時間情報より古いか判断する。すなわち、抽出処理Ａｃｔｉｏｎ３４４は、データ送信待ち状態のＭＦＰ１０１が前回データ送信を行った日時が、データ送信中のＭＦＰ１０１が前回データ送信を行った日時よりも許容値を加味したとしても古いか判断する。
【０１５２】
そして、抽出処理Ａｃｔｉｏｎ３４４は、データ送信待ち状態のＭＦＰ１０１が前回データ送信を行った日時が、データ送信中のＭＦＰ１０１が前回データ送信を行った日時よりも許容値を加味したとしても古い場合、以下のように判断する。すなわち、抽出処理Ａｃｔｉｏｎ３４４は、データ送信待ちのＭＦＰ１０１のデータ送信を優先する。この場合、処理はステップＳ１００９に進む。
【０１５３】
一方、データ送信待ち状態のＭＦＰ１０１が前回データ送信を行った日時が、データ送信中のＭＦＰ１０１が前回データ送信を行った日時よりも許容値を加味したうえで新しい場合、以降の処理は行わず、図１０の処理を終了する。すなわち、現在データ送信中のＭＦＰ１０１の処理はキャンセルされず、続行される。なお、許容値の定義方法や管理方法については、特に限定しないものとする。許容値は、例えば、抽出処理Ａｃｔｉｏｎ３４４内で予め定義されていてもよく、また、設定ファイルやデータベース等で管理し、ユーザが独自に定義するようにしてもよい。
【０１５４】
［第４実施形態］
第１実施形態〜第３実施形態では、１つのテナント内において、ＭＦＰ１０１からデータ送信が行われる際にデータ送信のタイミングが重複しないように、１台ずつＭＦＰ１０１からデータ送信が実行されるように制御するシステムについて説明した。これにより、ビジネスタイムであってもネットワークトラフィックの負荷を抑えた状態でデータ送信を行える。
【０１５５】
これに対して、本実施形態では、応用例として１つのテナント１０５内においてＭＦＰ１０１からのデータ送信をＮ件ずつ並列して実行するように制御する。例えば、ビジネスタイム終了後の時間からテナントビルの各フロアの電気を消灯する時間までの間に、テナントビル内の全てのＭＦＰ１０１のデータ送信を完了させるように制御することが可能になる。
【０１５６】
これにより、ネットワークの帯域幅が非常に狭いテナントにおいて、定常業務の障害要因を排除するためにビジネスタイムを避けてデータ送信を行いたい場合等、ＭＦＰ１０１によるデータ送信を並行して行わせる。これによりデータ送信が完了するまでの時間を短縮することができる。
【０１５７】
図１２は、図５に示した処理シーケンスにおいて、事前処理Ａｃｔｉｏｎ３４３が実行する本実施形態に係るステップＳ５０２の処理を説明するためのフローチャートである。
第１実施形態では、ステップＳ５０２において、事前処理Ａｃｔｉｏｎ３４３は、抽出処理Ａｃｔｉｏｎ３４４を１つ駆動した。これに対して、本実施形態では、事前処理Ａｃｔｉｏｎ３４３は、予め設定された同時実行数分だけ抽出処理Ａｃｔｉｏｎ３４４を駆動する。
【０１５８】
なお、本実施形態では、事前処理Ａｃｔｉｏｎ３４３が抽出処理Ａｃｔｉｏｎ３４４を複数駆動する際には、スクリプト管理サーバ１０３の急激な負荷上昇を抑えるため、１つ駆動するごとに数秒ほど時間をずらして次を駆動するものとする。ただし、これに限られるものではなく、同時に駆動してもよい。
【０１５９】
ステップＳ１３００において、事前処理Ａｃｔｉｏｎ３４３は、抽出処理Ａｃｔｉｏｎを同時に実行可能な個数（同時実行可能数）Ｎの値を取得する。Ｎは１以上の整数である。同時実行可能数の定義方法や管理方法については、特に限定しないものとする。同時実行可能数は、例えば、事前処理Ａｃｔｉｏｎ３４３内で予め定義されていてもよく、また、設定ファイルやデータベース等で管理し、ユーザが独自に定義するようにしてもよい。
【０１６０】
ステップＳ１３０１において、事前処理Ａｃｔｉｏｎ３４３は、抽出処理Ａｃｔｉｏｎ３４４を駆動する。また、事前処理Ａｃｔｉｏｎ３４３は、抽出処理Ａｃｔｉｏｎ３４４を駆動する際のパラメータとして、事前処理Ａｃｔｉｏｎ３４３が駆動された際に受け取ったテナント名を渡す。
【０１６１】
ステップＳ１３０２において、事前処理Ａｃｔｉｏｎ３４３は、一定時間待機する。待機時間の定義方法や管理方法については、特に限定しないものとする。待機時間は、例えば、事前処理Ａｃｔｉｏｎ３４３内で予め定義されていてもよく、また、設定ファイルやデータベースで管理し、ユーザが独自に定義するようにしてもよい。
【０１６２】
ステップＳ１３０３において、事前処理Ａｃｔｉｏｎ３４３は、駆動した抽出処理Ａｃｔｉｏｎ３４４の個数が同時実行可能数Ｎの数より小さいか判断する。駆動した個数がＮより小さい場合、処理はステップＳ１３０１に戻り、駆動した個数がＮ以上の場合、図１２の処理を終了する。すなわち、抽出処理Ａｃｔｉｏｎ３４４が所定の回数繰り返して駆動され、並行してＭＦＰ１０１からデータ送信が実行されることになる。
【０１６３】
図１３は、本実施形態において抽出処理Ａｃｔｉｏｎが実行する処理を説明するためのフローチャートである。
ステップＳ１４００〜Ｓ１４０５の処理は、図１０のステップＳ１０００〜Ｓ１００５と同様のため、その説明を省略する。
【０１６４】
ステップＳ１４０６において、抽出処理Ａｃｔｉｏｎ３４４は、ステップＳ１４０５で抽出した状態情報ファイルの個数と同時実行可能数Ｎを比較する。そして、抽出処理Ａｃｔｉｏｎ３４４は、状態情報ファイルの個数が同時実行可能数Ｎを超えている場合、データ送信を実行しているＭＦＰ１０１の個数が同時実行可能数に達していると判断し、処理はステップＳ１４０７に進む。一方、状態情報ファイルの個数が同時実行可能数Ｎを超えていない場合、データ送信を実行しているＭＦＰ１０１の個数が同時実行可能数に達していないと判断し、処理はステップＳ１４１０に進む。
【０１６５】
ステップＳ１４０７において、抽出処理Ａｃｔｉｏｎ３４４は、ステップＳ１４０５で抽出した状態情報ファイルから、状態情報ファイルの状態部が含む時間情報、すなわち前回のデータ送信を行った日時が最も新しい状態情報を１つ選択する。ステップＳ１４０８〜Ｓ１４１０の処理は、図１０のステップＳ１００８〜Ｓ１０１０と同様のため、その説明を省略する。
【０１６６】
このように、本実施形態によれば、図１２および図１３に示した処理により、１つのテナント１０５内においてＭＦＰ１０１からのデータ送信を、予め決められたＮ台以内で並列して実行することができる。
【０１６７】
［その他の実施形態］
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【０１６８】
以上、本発明の好ましい実施形態について説明したが、本発明は、これらの実施形態に限定されず、その要旨の範囲内で種々の変形および変更が可能である。
【図１】
2019091180.tif 000008
【図２】
2019091180.tif 000009
【図３】
2019091180.tif 000010
【図４】
2019091180.tif 000011
【図５】
2019091180.tif 000012
【図６】
2019091180.tif 000013
【図７】
2019091180.tif 000014
【図８】
2019091180.tif 000015
【図９】
2019091180.tif 000016
【図１０】
2019091180.tif 000017
【図１１】
2019091180.tif 000018
【図１２】
2019091180.tif 000019
【図１３】
2019091180.tif 000020