(57)【要約】【課題】通信の集中による遠隔管理システム側の応答性の低下を防止できるシステムの提供。【解決手段】データ処理サーバーは、ストレージに格納されている画像形成装置の運用情報の最終更新日時をチェックする最終更新日時チェック部と、運用情報の欠損をチェックするデータ欠損チェック部と、再取得する運用情報のデータ長を計算する再取得データ長計算部と、画像形成装置から運用情報を再取得する時刻を決定する再取得開始時刻決定部と、再取得要求をキューに入れてリモート保守サーバーへ送信する再取得要求送信部とを備え、リモート保守サーバーは、画像形成装置から運用情報を収集し、収集した運用情報をストレージに格納する運用情報収集部と、キューから再取得要求を取り出す再取得要求受信部と、再取得要求を再取得コマンドに変換する再取得要求変換部と、再取得コマンドを再取得を要求する画像形成装置へ送信する再取得コマンド送信部とを備える。【選択図】図４
2019204410.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク接続された、データ処理サーバーと、リモートメンテナンスサーバーと、ストレージと、接続サーバーとを含んだ遠隔管理システムであって、
前記データ処理サーバーは、
前記ストレージに格納されている画像形成装置の運用情報の最終更新日時をチェックする最終更新日時チェック部と、
前記運用情報の欠損をチェックするデータ欠損チェック部と、
再取得する前記運用情報のデータ長を計算する再取得データ長計算部と、
前記画像形成装置から前記運用情報を再取得する時刻を決定する再取得開始時刻決定部と、
データ長および再取得開始時刻が決定した再取得要求をキューに入れて前記リモートメンテナンスサーバーへ送信する再取得要求送信部と
を備え、
前記リモートメンテナンスサーバーは、
前記画像形成装置から前記運用情報を収集し、収集した前記運用情報を前記ストレージに格納する運用情報収集部と、
前記キューから前記再取得要求を取り出して受信する再取得要求受信部と、
前記再取得要求を前記画像形成装置が理解できる形の再取得コマンドに変換する再取得要求変換部と、
変換された前記再取得コマンドを前記接続サーバー経由で、前記運用情報の再取得を要求する画像形成装置へ送信する再取得コマンド送信部と
を備えた
遠隔管理システム。
【請求項２】
請求項１に記載の遠隔管理システムであって、
前記再取得開始時刻決定部は、
前記画像形成装置から前記運用情報を再取得する時刻を、前記遠隔管理システムの負荷が軽い時刻に決定する
遠隔管理システム。
【請求項３】
請求項１または２に記載の遠隔管理システムであって、
前記再取得データ長計算部は、
再取得する運用情報のデータ長が長すぎる場合は分割する
遠隔管理システム。
【請求項４】
ネットワーク接続された、データ処理サーバーと、リモートメンテナンスサーバーと、ストレージと、接続サーバーとを含んだ遠隔管理システムにおける情報処理方法であって、
前記リモートメンテナンスサーバーの運用情報収集部が、画像形成装置から運用情報を収集し、収集した前記運用情報を前記ストレージに格納し、
前記データ処理サーバーの最終更新日時チェック部が、前記ストレージに格納されている前記画像形成装置の前記運用情報の最終更新日時をチェックし、
前記最終更新日時が第１のしきい値以上前である場合、前記データ処理サーバーのデータ欠損チェック部が、前記運用情報の欠損をチェックし、
前記運用情報が欠損している場合、前記データ処理サーバーの再取得データ長計算部が、再取得する前記運用情報のデータ長を計算し、
前記データ処理サーバーの再取得開始時刻決定部が、前記画像形成装置から前記運用情報を再取得する時刻を決定し、
前記データ処理サーバーの再取得要求送信部が、データ長および再取得開始時刻が決定した再取得要求をキューに入れて前記リモートメンテナンスサーバーへ送信し、
前記リモートメンテナンスサーバーの再取得要求受信部が、前記キューから前記再取得要求を取り出して受信し、
前記リモートメンテナンスサーバーの再取得要求変換部が、前記再取得要求を前記画像形成装置が理解できる形の再取得コマンドに変換し、
前記リモートメンテナンスサーバーの再取得コマンド送信部が、変換された前記再取得コマンドを前記接続サーバー経由で、前記運用情報の再取得を要求する画像形成装置へ送信する
情報処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、数多くの画像形成装置（ＭＦＰ、Multifunction Peripheral）を管理する遠隔管理システムおよび情報処理方法に関する。
【背景技術】
【０００２】
数百台から数十万台の規模で画像形成装置を遠隔で管理するシステムでは、通信エラーや画像形成装置の電源断、また予期せぬ障害のために、トナー消費量や印刷枚数などの管理対象のデータが送信されないことがある。それに対して、データを再送信しようとしても、画像形成装置側の都合だけで任意のタイミングでデータを再送した場合は、通信回線に輻輳を発生させたり、遠隔管理システムの容量を超えた通信が発生し、逆に通信障害を発生させたりすることがある。
【０００３】
画像形成装置の遠隔管理システムにおいて、画像形成装置から送信されるデータの再送には、例えば、特許文献１、特許文献２、特許文献３において提案されているような、通信プロトコルのレベルにおいて誤り訂正符号などを付与し、データの破損時には当該データの再送処理を行う方式が提案されている。
【０００４】
この方式は、通信中のデータについて、通信プロトコルのレベルでエラーを検出する方式であるため、遠隔管理システムと画像形成装置との間のネットワーク接続が確立され、少なくとも通信可能な状態である必要がある。従って、一時的な通信経路上の不具合に対するデータ復旧のみが実現され、長期間画像形成装置との通信が切断されるレベルのエラーからの回復を想定していない。
【０００５】
これに対して、特許文献４の技術では、画像形成装置側から遠隔管理システムに対して、送信すべきであったエラー情報やカウンター情報を再送する仕組みが提案されている。しかし、ここで提案されている仕組みは、画像形成装置内のタイマーによって起動される。言い換えると、画像形成装置を起点としたエラー復旧処理であるということができる。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００２−２７１８７５号公報
【特許文献２】特開２００２−４１３７４号公報
【特許文献３】特開２００２−３３３９９６号公報
【特許文献４】特開２０１１−１５０５８７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
特許文献４が提案するエラー回復方法は、大量の画像形成装置のリトライ処理を実施する際に、遠隔管理システムの運用に重大な影響を与える可能性がある。何故なら、画像形成装置で自立して再試行されるデータの送信は、それぞれの送信タイミングを分散させることができず、従って、通信の集中による遠隔管理システム側の応答性の低下や、長期間通信が切断された場合には試行間隔が長くなることによって、データ復旧までに時間を要するという欠点がある。
【０００８】
以上のような事情に鑑み、本発明の目的は、画像形成装置を管理する遠隔管理システム側が保有するデータを基に、再送信すべき時刻を指定することで、通信の集中による遠隔管理システム側の応答性の低下を防止できる遠隔管理システムおよび情報処理方法を提供することにある。
【課題を解決するための手段】
【０００９】
上記目的を達成するため、本発明の一形態に係る遠隔管理システムは、ネットワーク接続された、データ処理サーバーと、リモートメンテナンスサーバーと、ストレージと、接続サーバーとを含んだ遠隔管理システムであって、前記データ処理サーバーは、前記ストレージに格納されている画像形成装置の運用情報の最終更新日時をチェックする最終更新日時チェック部と、前記運用情報の欠損をチェックするデータ欠損チェック部と、再取得する前記運用情報のデータ長を計算する再取得データ長計算部と、前記画像形成装置から前記運用情報を再取得する時刻を決定する再取得開始時刻決定部と、データ長および再取得開始時刻が決定した再取得要求をキューに入れて前記リモートメンテナンスサーバーへ送信する再取得要求送信部とを備え、前記リモートメンテナンスサーバーは、前記画像形成装置から前記運用情報を収集し、収集した前記運用情報を前記ストレージに格納する運用情報収集部と、前記キューから前記再取得要求を取り出して受信する再取得要求受信部と、前記再取得要求を前記画像形成装置が理解できる形の再取得コマンドに変換する再取得要求変換部と、変換された前記再取得コマンドを前記接続サーバー経由で、前記運用情報の再取得を要求する画像形成装置へ送信する再取得コマンド送信部とを備える。
【００１０】
そのため、画像形成装置を管理する遠隔管理システム側が保有するデータを基に、再送信すべき時刻を指定することで、通信の集中による遠隔管理システム側の応答性の低下を防止できる。
【００１１】
上記目的を達成するため、本発明の一形態に係る遠隔管理システムでは、前記再取得開始時刻決定部は、前記画像形成装置から前記運用情報を再取得する時刻を、前記遠隔管理システムの負荷が軽い時刻に決定する構成でもよい。
【００１２】
本構成により、遠隔管理システム側の応答性の低下を防止できる。
【００１３】
上記目的を達成するため、本発明の一形態に係る遠隔管理システムでは、前記再取得データ長計算部は、再取得する運用情報のデータ長が長すぎる場合は分割する構成でもよい。
【００１４】
本構成により、遠隔管理システム側の応答性の低下を防止できる。
【００１５】
上記目的を達成するため、本発明の一形態に係る情報処理方法は、ネットワーク接続された、データ処理サーバーと、リモートメンテナンスサーバーと、ストレージと、接続サーバーとを含んだ遠隔管理システムにおける情報処理方法であって、前記リモートメンテナンスサーバーの運用情報収集部が、画像形成装置から運用情報を収集し、収集した前記運用情報を前記ストレージに格納し、前記データ処理サーバーの最終更新日時チェック部が、前記ストレージに格納されている前記画像形成装置の前記運用情報の最終更新日時をチェックし、前記最終更新日時が第１のしきい値以上前である場合、前記データ処理サーバーのデータ欠損チェック部が、前記運用情報の欠損をチェックし、前記運用情報が欠損している場合、前記データ処理サーバーの再取得データ長計算部が、再取得する前記運用情報のデータ長を計算し、前記データ処理サーバーの再取得開始時刻決定部が、前記画像形成装置から前記運用情報を再取得する時刻を決定し、前記データ処理サーバーの再取得要求送信部が、データ長および再取得開始時刻が決定した再取得要求をキューに入れて前記リモートメンテナンスサーバーへ送信し、前記リモートメンテナンスサーバーの再取得要求受信部が、前記キューから前記再取得要求を取り出して受信し、前記リモートメンテナンスサーバーの再取得要求変換部が、前記再取得要求を前記画像形成装置が理解できる形の再取得コマンドに変換し、前記リモートメンテナンスサーバーの再取得コマンド送信部が、変換された前記再取得コマンドを前記接続サーバー経由で、前記運用情報の再取得を要求する画像形成装置へ送信する。
【発明の効果】
【００１６】
以上のように、本発明によれば、画像形成装置を管理する遠隔管理システム側が保有するデータを基に、再送信すべき時刻を指定することで、通信の集中による遠隔管理システム側の応答性の低下を防止できる。
【図面の簡単な説明】
【００１７】
【図１】本発明の一実施形態に係る遠隔管理システム１００の全体構成図である。
【図２】データ処理サーバー１０が一般的なコンピューターにより構成される場合の構成図である。
【図３】リモートメンテナンスサーバー３０が一般的なコンピューターにより構成される場合の構成図である。
【図４】遠隔管理システム１００のデータ処理サーバー１０における再取得要求送信までの処理の流れを説明するためのフローチャートである。
【発明を実施するための形態】
【００１８】
以下、図面を参照しながら、本発明の実施形態を説明する。
【００１９】
［全体構成］
最初に、本発明の一実施形態に係る遠隔管理システム１００の全体構成について説明する。図１は、本発明の一実施形態に係る遠隔管理システム１００の全体構成図である。
【００２０】
遠隔管理システム１００は、ネットワーク接続された、負荷分散装置５０と、リモートメンテナンスサーバー３０（３０は、３０Ａと３０Ｂの総称。以下同じ）と、データ処理サーバー１０と、スケジュールサーバー４０と、ＤＢ（データベース）８０と、ストレージ６０と、接続サーバー７０を含んで構成される。
【００２１】
インターネット側から見たエンドポイントは、リモートメンテナンスサーバー３０Ａおよび３０Ｂに画像形成装置２０からのアクセスを分散させる負荷分散装置５０と、接続サーバー７０Ａと、接続サーバー７０Ｂと、接続サーバー７０Ｃとである。
【００２２】
負荷分散装置５０は、画像形成装置２０からのアクセスを、リモートメンテナンスサーバー３０Ａおよび３０Ｂに分散させる。
【００２３】
リモートメンテナンスサーバー３０は、管理下にある画像形成装置２０をリモートでメンテナンスする。例えば、日々の運用情報（トナー消費量、印刷枚数など）を1日1回収集してＤＢ８０およびストレージ６０に格納したり、画像形成装置２０のファームウェアのアップデートを行ったりする。
【００２４】
ＤＢ８０は、直近の運用情報を格納する。
【００２５】
ストレージ６０は、日ごと画像形成装置２０ごとの運用情報を全て保管する。
【００２６】
接続サーバー７０は、遠隔管理システム１００の管理下にある画像形成装置２０へ管理コマンドを送るため、画像形成装置２０との間で管理接続を行うサーバーである。管理接続は、画像形成装置２０の電源が切られるまで継続される。
【００２７】
ネットワークに接続された画像形成装置２０は、まず負荷分散装置５０経由でリモートメンテナンスサーバー３０に接続し、どの接続サーバー７０と管理接続を確立すべきかの応答を得る。その後、リモートメンテナンスサーバー３０との接続を切り、指定された接続サーバー７０に接続し、管理接続を確立する。
【００２８】
ストレージ６０に保存される運用情報の欠損は、スケジュールサーバー４０によって定期的に起動されるデータ処理サーバー１０によりチェックされる。運用情報に欠損がある場合は、データ処理サーバー１０が再取得する運用情報のデータ長や再取得開始時刻を計算した上で再取得要求をキューに入れてリモートメンテナンスサーバー３０に送信する。
【００２９】
リモートメンテナンスサーバー３０は、再取得要求をキューから取り出して受信し、画像形成装置２０が理解する再取得コマンド形式に変換した上で、接続サーバー７０経由で画像形成装置２０に送信する。
【００３０】
以上、遠隔管理システム１００の全体構成について説明した。なお、上記の説明に対応する図では、例えば接続サーバー７０は３台となっているが、これはあくまで例示であり、実際には何台あっても構わない。
【００３１】
［データ処理サーバーの構成］
次に、データ処理サーバー１０の構成について説明する。データ処理サーバー１０は、専用のハードウェアやソフトウェアにより構成されていてもよいし、一般的なコンピューターにより構成されてもよい。データ処理サーバー１０が一般的なコンピューターにより構成される場合の構成図を図２に示す。
【００３２】
同図に示すように、データ処理サーバー１０は、ＣＰＵ（Central Processing Unit）１１、ＲＯＭ（Read Only Memory）１２、ＲＡＭ（Random Access Memory）１３、操作入力部１４、通信部１５、表示部１６、および記憶部１７を有し、これら各ブロックがバス１８を介して接続されている。
【００３３】
ＲＯＭ１２は、各種の処理を実行するためのファームウェア等の複数のプログラムやデータを記憶する。ＲＡＭ１３は、ＣＰＵ１１の作業用領域として用いられ、ＯＳ（Operating System）、実行中の各種アプリケーション、処理中の各種データを一時的に保持する。
【００３４】
記憶部１７は、例えばＨＤＤ（Hard Disk Drive）や、フラッシュメモリー、その他の不揮発性メモリーである。記憶部１７には、ＯＳや各種アプリケーション、各種データが記憶される。
【００３５】
通信部１５は、ネットワーク上の機器等と情報のやりとりを行う為のネットワークと結ばれている。
【００３６】
ＣＰＵ１１は、ＲＯＭ１２や記憶部１７に格納された複数のプログラムのうち、操作入力部１４から与えられる命令に対応するプログラムをＲＡＭ１３に展開し、この展開されたプログラムにしたがって、表示部１６及び記憶部１７を適宜制御する。
【００３７】
操作入力部１４は、例えばマウス等のポインティングデバイス、キーボード、タッチパネル、その他の操作装置である。
【００３８】
表示部１６は、例えば液晶ディスプレイ、ＥＬ（Electro-Luminescence）ディスプレイ、プラズマディスプレイ等である。
【００３９】
次に、ＣＰＵ１１においてプログラムが実行されることにより実現される機能ブロックについて説明する。
【００４０】
データ処理サーバー１０のＣＰＵ１１において実現される機能ブロックは、最終更新日時チェック部１１ａ、データ欠損チェック部１１ｂ、再取得データ長計算部１１ｃ、再取得開始時刻決定部１１ｄ、および再取得要求送信部１１ｅである。
【００４１】
最終更新日時チェック部１１ａは、ストレージ６０に格納されている各画像形成装置２０の運用情報の最終更新日時をチェックする。最終更新日時が１日以上前である場合は、通信エラーなどにより最新の運用情報が送られてきていない可能性があるため、次にデータ欠損チェックを行う。
【００４２】
データ欠損チェック部１１ｂは、ストレージ６０に格納されている各画像形成装置２０の運用情報の欠損を、通信エラーなどをチェックした上で、チェックする。運用情報は、１日１件が格納されているので、運用情報が無い日があれば、その日の運用情報が欠損していることが分かる。また、運用情報が画像形成装置２０から送られてくる際には、チェックサムが付加されるので、チェックサムを検証することにより、格納されている運用情報が適切なものであるか欠損を生じているものであるかをチェックすることが出来る。
【００４３】
再取得データ長計算部１１ｃは、再取得する運用情報のデータ長を計算する。運用情報の再取得は、日単位で行われる。一日分の運用情報のデータ長は決まっているので、欠損が２日分あれば、データ長は２倍になり、欠損が３日分あれば、データ長は３倍になる。再取得するデータを遠隔管理システム１００への影響が少なくなるように小さくする場合は、例えば欠損が２日分ある場合、再取得する運用情報を１日分ずつ小分けに分割して取得する。すなわち、再取得する運用情報のデータ長が長すぎる場合は分割する。
【００４４】
再取得開始時刻決定部１１ｄは、画像形成装置２０から運用情報を再取得する時刻を、遠隔管理システム１００の負荷が軽い時刻に決定する。
【００４５】
再取得要求送信部１１ｅは、データ長および再取得開始時刻が決定した再取得要求をキューに入れてリモートメンテナンスサーバー３０へ送信する。
【００４６】
以上、データ処理サーバー１０の構成について説明した。
【００４７】
［リモートメンテナンスサーバーの構成］
次に、リモートメンテナンスサーバー３０の構成について説明する。リモートメンテナンスサーバー３０は、専用のハードウェアやソフトウェアにより構成されていてもよいし、一般的なコンピューターにより構成されてもよい。リモートメンテナンスサーバー３０が一般的なコンピューターにより構成される場合の構成図を図３に示す。
【００４８】
同図に示すように、リモートメンテナンスサーバー３０は、ＣＰＵ３１、ＲＯＭ３２、ＲＡＭ３３、操作入力部３４、通信部３５、表示部３６、および記憶部３７を有し、これら各ブロックがバス３８を介して接続されている。
【００４９】
ＲＯＭ３２は、各種の処理を実行するためのファームウェア等の複数のプログラムやデータを記憶する。ＲＡＭ３３は、ＣＰＵ３１の作業用領域として用いられ、ＯＳ、実行中の各種アプリケーション、処理中の各種データを一時的に保持する。
【００５０】
記憶部３７は、例えばＨＤＤ（Hard Disk Drive）や、フラッシュメモリー、その他の不揮発性メモリーである。記憶部３７には、ＯＳや各種アプリケーション、各種データが記憶される。
【００５１】
通信部３５は、ネットワーク上の機器等と情報のやりとりを行う為のネットワークと結ばれている。
【００５２】
ＣＰＵ３１は、ＲＯＭ３２や記憶部３７に格納された複数のプログラムのうち、操作入力部３４から与えられる命令に対応するプログラムをＲＡＭ３３に展開し、この展開されたプログラムにしたがって、表示部３６及び記憶部３７を適宜制御する。
【００５３】
操作入力部３４は、例えばマウス等のポインティングデバイス、キーボード、タッチパネル、その他の操作装置である。
【００５４】
表示部３６は、例えば液晶ディスプレイ、ＥＬディスプレイ、プラズマディスプレイ等である。
【００５５】
次に、ＣＰＵ３１においてプログラムが実行されることにより実現される機能ブロックについて説明する。
【００５６】
リモートメンテナンスサーバー３０のＣＰＵ３１において実現される機能ブロックは、運用情報収集部３１ａ、再取得要求受信部３１ｂ、再取得要求変換部３１ｃ、および再取得コマンド送信部３１ｄである。
【００５７】
運用情報収集部３１ａは、負荷分散装置５０経由で、画像形成装置２０から運用情報を収集し、収集した運用情報をＤＢ８０およびストレージ６０に格納する。
【００５８】
再取得要求受信部３１ｂは、キューから再取得要求を取り出して受信する。
【００５９】
再取得要求変換部３１ｃは、キューから取り出され受信された再取得要求を画像形成装置２０が理解できる形の再取得コマンドに変換する。
【００６０】
再取得コマンド送信部３１ｄは、変換された再取得コマンドを接続サーバー７０経由で、運用情報の再取得を要求する画像形成装置２０へ送信する。
【００６１】
以上、リモートメンテナンスサーバー３０の構成について説明した。
【００６２】
［処理の流れ］
次に、遠隔管理システム１００のデータ処理サーバー１０における再取得要求送信までの処理の流れを説明する。図４は、遠隔管理システム１００のデータ処理サーバー１０における再取得要求送信までの処理の流れを説明するためのフローチャートである。
【００６３】
まずスケジュールサーバー４０により起動されたデータ処理サーバー１０の最終更新日時チェック部１１ａが、ストレージ６０に保存している画像形成装置２０ごとの運用情報の最終更新日時をチェックする（ステップＳ１）。
【００６４】
次に、最終更新日時チェック部１１ａが、運用情報の最終更新日時が１日（第１のしきい値）以上前であるか否かを判断する（ステップＳ２）。
【００６５】
最終更新日時が１日以上前ではない場合（ステップＳ２のＮ）、処理を終了する。
【００６６】
最終更新日時が１日以上前である場合（ステップＳ２のＹ）、次に、データ欠損チェック部１１ｂが、ストレージ６０に保存されている運用情報の欠損をチェックする（ステップＳ３）。
【００６７】
次に、データ欠損チェック部１１ｂが、運用情報に欠損があるか否かを判断する（ステップＳ４）。
【００６８】
欠損が無い場合（ステップＳ４のＮ）、処理を終了する。
【００６９】
欠損がある場合（ステップＳ４のＹ）、次に、再取得データ長計算部１１ｃが、再取得する運用情報のデータ長を計算する（ステップＳ５）。なお、この計算を行う際には、再取得する運用情報を分割して取得することも検討する。
【００７０】
次に、再取得開始時刻決定部１１ｄが、再取得する運用情報の送信を開始する時刻を、遠隔管理システム１００の負荷が少ない時刻に設定する（ステップＳ６）。
【００７１】
次に、再取得要求送信部１１ｅが、欠損している運用情報の再取得要求をキューの形でリモートメンテナンスサーバー３０に送信し、処理を終了する（ステップＳ７）。
【００７２】
以上、遠隔管理システム１００のデータ処理サーバー１０における再取得要求送信までの処理の流れを説明した。
【００７３】
［補足事項］
その他、本発明は、上述の実施形態にのみ限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変更を加え得ることは勿論である。
【符号の説明】
【００７４】
１０  …  データ処理サーバー
１１  …  ＣＰＵ
１１ａ…  最終更新日時チェック部
１１ｂ…  データ欠損チェック部
１１ｃ…  再取得データ長計算部
１１ｄ…  再取得開始時刻決定部
１１ｅ…  再取得要求送信部
１２  …  ＲＯＭ
１３  …  ＲＡＭ
１４  …  操作入力部
１５  …  通信部
１６  …  表示部
１７  …  記憶部
１８  …  バス
２０  …  画像形成装置
３０  …  リモートメンテナンスサーバー
３１  …  ＣＰＵ
３１ａ…  運用情報収集部
３１ｂ…  再取得要求受信部
３１ｃ…  再取得要求変換部
３１ｄ…  再取得コマンド送信部
３２  …  ＲＯＭ
３３  …  ＲＡＭ
３４  …  操作入力部
３５  …  通信部
３６  …  表示部
３７  …  記憶部
３８  …  バス
４０  …  スケジュールサーバー
５０  …  負荷分散装置
６０  …  ストレージ
７０  …  接続サーバー
８０  …  ＤＢ
１００  …  遠隔管理システム
【図１】
2019204410.tif 000003
【図２】
2019204410.tif 000004
【図３】
2019204410.tif 000005
【図４】
2019204410.tif 000006