JP6298302B2 - ネットワークデバイス及びデータの特定方法 - Google Patents

Description

本発明は、例えばネットワークを介して接続されたデバイスから故障分析、故障予測を行うために必要なデータを収集するためのネットワークデバイス及びデータの特定方法に関する。特に、通信、蓄積するデータ容量を節約して、効率的に故障予測を行うためのデータを収集するためのネットワークデバイス及びデータの特定方法に関するものである。

従来、インターネット上に管理システムを設置し、ネットワークを介して顧客先のデバイスを管理するメンテナンスシステムが知られている。この従来のメンテナンスシステムでは、例えば、管理システムがデバイス監視装置から送信されるデバイスステータス、故障や紙詰まりなどのイベントデータ、プリント枚数等の情報を収集して、デバイスの管理を行っていた。また、近年ではデバイス監視装置からより詳細なデバイスの状態データを収集することで、故障やジャムなどのイベントの発生の原因分析や予測が行われている。具体的な原因分析としては、データ分析者が表計算ソフトやBI(Business Intelligence)ツールを駆使して、デバイスの状態データと故障やジャムなどのイベントの発生との因果関係を可視化する。また、予測としては、回帰分析を用いる方法が一般的である。データ分析者は、管理システムが収集したデバイスステータス、イベントデータと、デバイスの状態データをもとに故障分析、故障予測の回帰モデルを作成する。故障分析、故障予測のモデルは、サービスマンのメンテナンス計画への活用、デバイスの所有者であるユーザに対する警告の提示などの用途に利用される。

一方、高精度の分析、予測を行うためには、単純なデバイスの状態データだけでなく、様々な付加情報を元に分析モデルを作成することが必要である。特許文献１では、デバイスの状態データに加えて、デバイスの使用状況データを合わせてモデルを作成することで、デバイスが故障するまでの猶予期間の予測精度の向上を実現している。

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

しかしながら、特許文献１では、デバイスの状態データと使用状況データとを合わせた分析モデルだけでしか高精度の予測を行うことができない。そのため、例えばデバイスのパーツ情報や、デバイスの連続電源投入時間などと密接な関連をもつ分析モデルを新たに生成することはできず、汎用性が高いとは言えない。また、汎用性を高くするためにデバイスからの状態データの収集をより高密度、かつ多種類にするとしても、この場合は管理システムに大量の状態データを蓄積する必要があり、サーバの運用コストが増加するという課題がある。

本発明は、前記従来の問題点に鑑み、分析者が必要とするデバイスの状態データを、高汎用性、かつ効率的に収集することを実現するネットワークデバイス及びデータ収集方法及びデータ収集システムを提供する。

上述した課題を解決するために、本発明は以下の構成を有する。

ネットワークデバイスから収集した教師データの分析を行うシステムと通信するネットワークデバイスであって、
前記ネットワークデバイスで検出されたデータの中から、前記システムに対して送信すべきデータを特定するための過去の複数タイミングを計算するために利用される、複数の異なるロジックをデータベースで管理する管理手段と、
前記システムから、前記ネットワークデバイスで生じたイベントを特定するイベント情報と、前記ロジックを特定するロジック情報とを含む条件データを取得する取得手段と、
前記ネットワークデバイスでイベントの発生が検出された場合、当該イベントに対応するイベント情報が含まれる条件データのロジック情報に基づき、前記データベースからロジックを特定する第１特定手段と、
前記特定されたロジックに従い、前記ネットワークデバイスで検出されたデータの中から、前記システムに対して送信するデータを特定する第２特定手段と、
前記特定されたデータを前記教師データとして前記システムに対して送信する送信手段と
を有する。

本発明により、故障分析、故障予測モデルを生成するためのデバイスの状態データを高い汎用性を保ちながら効率的に収集することができる。

本実施形態の複写機、被管理装置及び管理システム106とのインターネットを介した接続関係を示す図である。 本実施形態のデバイス監視モジュールと管理システム106とユーザとの間の通信シーケンス例を表した図である。 本実施形態の管理システム106のハードウェア構成例を示すブロック図である。 本実施形態の管理システム106のアプリケーションプログラムの機能ブロック図である。 本実施形態の管理システム106の記憶構成例を示す図である。 本実施形態の管理システム106の記憶構成例を示す図である。 本実施形態の管理システム106から被管理装置へ送信される情報例を表した図である。 本実施形態のユーザが管理システム106を介して被管理装置へ入力したリクエストの例を表した図である。 本実施形態の管理システム106が保管する被管理デバイスの機種依存デバイスマスタを表した図である。 本実施形態の条件データの構成図を示す図である。 本実施形態の計算ロジックの処理フローを示す図である。 本実施形態の管理システム106が保管する被管理デバイスの監視対象デバイスマスタを表した図である。 本実施形態の管理システム106がデバイスに送信データスケジュール設定を返信する際の全体の流れを表すフローチャートである。 本実施形態の管理システム106がデバイスからスケジュールリクエストを受信した際の流れを表すフローチャートである。 本実施形態の管理システム106が未登録のデバイスから通信リクエストを受信した際の流れを表すフローチャートである。 本実施形態の管理システム106がデバイスからデバイス監視を受信した際の流れを表すフローチャートである。 本実施形態のデバイスのハードウェア構成例を示すブロック図である。 本実施形態のデバイスの記憶構成例を示す図である。 本実施形態のデバイスから管理システム106にセンサーデータをアップロードするシーケンス図である。 本実施形態のセンサーデータの構成図を示す図である。 本実施形態の管理システム106が分析ユーザに提供するウェブ画面を示す図である。

以下、本発明を実施するための形態について図面を用いて説明する。なお、この後の説明において、設定した条件に従ってデバイスから現在の状態を通知する通信をスケジュール系通信という。これはデバイスの最新の状態を管理システムが監視するための通信である。それに対して、主として図10、図11、図18乃至図20を参照して説明する分析データの取得は、設定した条件に該当するイベントが生じた場合に、そのイベントから遡った過去の時点におけるデバイスの状態を取得するというもので、スケジュール系通信とは独立して実行可能である。分析データの取得により、ある時点におけるデバイスの状態とその後に発生したイベントとの因果関係を特定することで、例えばエラーの発生を予告することができる。

＜本実施形態のデバイス管理システムの構成例＞
図1において、イントラネット108は顧客のイントラネット環境を示している。イントラネット108には、インターネットからの、あるいはインターネットへのアクセスを制限する接続ポイントであるファイアウォール105が設置されている。また、外部へのHTTPやHTTPS通信を1台のマシンがコントロールできるようにプロクシサーバ104が設置されている。

ネットワークデバイス101や102は、顧客のネットワークに設置されたMFP(Multi Function Printer)やSFP(Single Function Printer)などのプリント・複写などの機能をもつ機器（ここではデバイスと呼ぶ。）である。各デバイスには、デバイス監視モジュールが組み込まれており、このモジュールがデバイスのステータスを監視し、外部の管理システム106と通信を行う。また、デバイス監視モジュールは、デバイス監視を行うソフトウェアプログラムなので、デバイスに組み込む形態でも、PCや専用のハードに組み込まれる形態で存在してもかまわない。パーソナルコンピュータ103は、一般のユーザが業務等で使用するパーソナルコンピュータ（PC）を表している。インターネット110は、イントラネット108に類似した別顧客のネットワークが無数に接続されている。なお、本実施形態では、「デバイス監視モジュール」とは、デバイスの状態を監視して管理システム106に伝達するためのプログラムの総称であり、たとえば図18に記載したイベント情報送信プログラム1807等の各処理プログラム1806を含む。なおデバイス監視モジュールは、所与のスケジュールに従ってデバイス状態を管理システム106に通知するモジュールを指し、本願発明に係る条件に従ってデバイス状態のスナップショットを通知するためのプログラムとは別のものであるとする。デバイス監視モジュールはデバイスにインストールされたものにかぎらず、監視対象のデバイスと同一のネットワーク（具体的には同一のLAN）108に接続されたコンピュータにインストールしたプログラムによって実現されてもよい。この場合には、デバイスによって捉えられたイベント情報は、いったん対象デバイスと同一のネットワーク108上のコンピュータに送信され、そのコンピュータで実行されているデバイス監視モジュールにより管理システム106に送信される。

管理システム106は、管理サーバ111と分析サーバ112とを含む。管理システム106は、インターネット110上に設置され各顧客のネットワークに設置されているデバイス監視モジュールと通信を行う事によって、デバイスの情報を収集し、管理している。管理サーバ111の収集するデバイスの情報は、デバイスの種動作モード設定や、カウンタ値、稼動ログ、各パーツの使用度合いを表すカウンタ値などの稼動情報、ハード障害やジャム等の障害情報を含む。また、管理サーバ111は、各デバイスに対して設定情報の更新やリブートなどのコマンド指示を行う。この際の通信手段としては、HTTPやHTTPSなどのプロトコルを介したSOAPを利用した通信などがある。また、分析サーバ112が収集するデバイスの情報は、デバイス内のセンサーデータのスナップショット情報を含む。以下、デバイス内のセンサーデータのスナップショット情報のことを単にセンサーデータと呼ぶ。分析サーバ112は、デバイスに対して、デバイス内のセンサーデータの中で、分析に必要となるセンサーデータの条件と、条件に適合するセンサーデータを特定するための計算ロジックを提供する。

管理システム106は、冗長性や性能向上のために複数台のサーバ（本実施形態で例示するように、管理サーバ111、分析サーバ112など）から構成されることが好ましい。しかしながら、それらのサーバが提供する機能を1台のサーバで実現することも可能である。また、通信手段に関しては、管理システム106とデバイスとの間で通信ができればいいので、HTTPやHTTPSに限定するものではない。例えば、図１の例では、デバイス監視モジュールは監視対象であるデバイスの情報を取得し、HTTPSを利用してプロクシサーバとファイアウォールを介して、管理システム106にデータを送信している。管理システム106は、デバイス監視モジュール及びデバイスを制御するために、デバイス監視モジュールに対してコマンドを発行する。

また、管理サーバ111は、管理システムのユーザが使用するクライアントコンピュータ107に対して、管理システム106で管理されるデバイスの情報を表示させる機能を提供する。例えば、パーツの寿命情報や、トナーの残量などを表示することで、メンテナンスの要否をクライアントコンピュータ107の画面で確認することができる。

さらに、分析サーバ112は、分析サーバ112で管理されるデータ（これを教師データと呼ぶ。）を分析する分析ユーザのクライアントコンピュータ113に対してデータを提供する。このとき、例えば分析ユーザはクライアントコンピュータ113に表計算ソフトやBI(Business Intelligence)ツールをインストールし、分析サーバ112が管理するデータから故障分析や、故障予測などのデータ分析を行うことができる。また、例えば分析サーバ112が提供する図21に示すようなウェブ画面で、分析に必要なデータの条件を分析サーバ112にユーザが入力し、それを分析サーバー112から監視対象のネットワークデバイスに与え、その条件に合致するデータをデバイスから取得することもできる。図2とうを参照して説明する条件データは、このようにして入力されたものである。

管理システム106内の管理サーバ111および分析サーバ112は同一のサーバ内で稼働させることもできる。そのため、本実施形態においては、管理サーバ111と分析サーバ112とを含めたシステムを管理システム106として記述する。

＜本実施形態の管理システム106の構成例＞
図3は、図1における管理システム106のハードウェア構成例を示すブロック図である。管理システム106は汎用のコンピュータ等で構成されてよい。管理システム106は、全体を制御するためのCPU302と、システム起動に必要なブートプログラムを記憶するための読み出し専用メモリであるROM303と、CPU302でプログラムを実行する際に必要とされる作業メモリであるRAM304とを含む。又、管理システム106は、ネットワーク上で通信を行うためのネットワーク（Network）I/F305と、表示デバイス309にデバイス監視モジュールとの通信内容等を表示するための表示制御部306とを含む。更に、管理システム106を管理するオペレータからの入力を入力信号に変換する入力デバイス310や311、入力信号を受け付ける入力制御部307を含む。さらに、CPU302で実行するプログラムやデバイス監視モジュールから送られた各デバイスの稼働情報、センサーデータなどを格納する磁気ディスク等の記憶装置308を含む。

管理システム106は、デバイス監視モジュールからの定期的な稼働情報通知や不定期的な異常状態の通知、コマンドリクエスト、センサーデータをNetwork I/F305を介して常時受け付けている。また、ユーザからデバイスへの設定変更や動作要求などのコマンド入力は、入力制御部307を介して常時受け付けている。定期的に通知される稼働情報には、各種カウンタ値や稼働ログなどが含まれており、管理システム106は稼動情報を基にデバイスを所有している顧客に対して毎月請求する定期メンテナンス料を算出する。又、デバイスに使用されているパーツが推奨寿命に対してどのくらい消耗しているのかをレポートの形で出力する。管理システム106はこの稼働情報を記憶装置308に逐次格納する。一方、オペレータは格納された稼働情報を適宜参照して顧客への請求額を決定する。また、管理システム106はデバイスから送付されるセンサーデータを記憶装置308に逐次格納している。センサーデータの分析を行うオペレータは、このセンサーデータを適宜参照してデバイス内で発生した各種イベントの発生原因の調査や、予測モデルの生成を行う。

不定期的に通知されるデバイスの異常状態を表す情報には、稼働情報に加えて、発生したハード障害やジャムなどのエラー／アラーム情報が含まれている。管理システム106はこの情報を受け取ると、情報の緊急度に基づいて処理を決定する。受け取った情報が、デバイスの故障など、デバイスが異常状態を表すものであり、すぐに復旧させる必要のある障害情報だった場合には、その対象のデバイスを管理しているオペレータに電子メールを送信する。さらに記憶装置308に逐次格納すると共にディスプレイ309上に表示することで、デバイスが異常状態に陥っている旨をオペレータに通知する。一方、受け取った情報がジャムやアラームのように緊急度が低い場合には、記憶装置208に逐次格納し、電子メールの送信が必要かどうか、ディスプレイ309に表示させる必要があるかどうかそのときの障害に応じて処理を行う。オペレータは、ディスプレイ309上の表示内容からデバイスの状態を判断し、必要に応じて障害復旧作業をサービスマンに指示をする。緊急度は例えば予めイベントごとに定めておいてもよいし、或いはイベントに応じて処理を決めておいてもよい。後者の場合には、予め決められた処理に緊急度に応じた処理を組み込んでおくことができる。

デバイス監視モジュールからのコマンドリクエストは、任意のタイミングで常時受け付ける。管理システム106はコマンドリクエストを受ける都度、管理システム106内の記憶装置308を確認し、デバイス監視モジュールへの送信すべきコマンドが設定されていたら、デバイス監視モジュールへコマンドを送信する。

＜本実施形態の管理システム106のソフトウエア構成例＞
図4は、管理システム106における、１以上のアプリケーションプログラムで提供される機能モジュールを説明するための図である。具体的には、管理サーバ１１１と分析サーバ１１２とのそれぞれの機能を実現する２つのアプリケーションプログラムにより、管理システム１０６におけるすべての機能モジュールを提供してもよい。なお以下の説明では、アプリケーションプログラムの実行により実現される機能モジュールあるいはそのためのプログラム部分を「部」と称している。

アプリケーションプログラムは、ユーザからマスタデータの入力を受け付けるマスタデータ入力部403を有する。マスタデータには、2種類のマスタデータが存在する。そのひとつは、デバイスの製品名や、製品スペックなど基本的な機種の情報、エラー、アラームなど、デバイス機種に依存するコード情報を意味する機種依存デバイスマスタデータである。さらに、機種依存デバイスマスタデータは、分析のために必要となるセンサーデータをデバイが決定するための条件データを含んでいる。もうひとつは、監視対象となるデバイスのデバイスIDや設置場所である顧客の情報など、監視対象としての個別情報を意味する監視対象デバイスマスタデータである。

また、アプリケーションプログラムは、入力の行われたマスタデータを、マスタデータ記憶部401へ保管処理するマスタデータ入出力部402を有する。また、アプリケーションプログラムは、デバイス監視モジュールとの通信を行う通信I/F部404を有する。また、アプリケーションプログラムは、デバイス監視モジュールから受信したデータからデバイスIDや通信コマンド、センサーデータをデータとして取り出す通信コマンド解釈部407を有する。また、通信コマンド解釈部407はデバイス監視モジュールへ送信するデータを通信用フォーマットへ成型する機能を有する。また、デバイス監視モジュールに新規の送信設定を送信する必要があるとき、または、送信スケジュールを要求されたときに、対象のデバイス監視モジュールに適切な送信設定を発行する通信設定発行部405を有する。この通信設定発行部405はマスタデータ入出力部402から、機種依存デバイスマスタ情報と監視対象デバイスマスタ情報を呼び出し、デバイス監視モジュールにとって適切な送信設定を発行する。

さらに、アプリケーションプログラムは、通常監視状態にデバイス監視モジュールから受信するデバイスステータスデータを通信コマンド解釈部407から受け取るデバイスデータ取得部408を有する。また、アプリケーションプログラムは、デバイスデータ取得部408で取得したデバイスステータス情報を格納するための取得データ記憶部410を有し、取得データ入出力部409は取得データ記憶部410への入出力処理を管理する。また、アプリケーションプログラムはユーザへデバイスから取得したステータスデータを表示するための取得データ表示部406を有する。

さらに、アプリケーションプログラムは、通常監視状態にデバイス監視モジュールから受信するセンサーデータを通信コマンド解釈部407から受け取るセンサーデータ取得部411を有する。また、アプリケーションプログラムはセンサーデータ取得部411で取得したセンサーデータを格納するためのセンサーデータ記憶部412を有し、センサーデータ出力部413はセンサーデータ記憶部412からの出力処理を管理する。また、ユーザが分析のためにセンサーデータを取得するためのセンサーデータ取得部414を有する。センサーデータ取得部414は、例えば、図21に示すようなウェブ画面で、分析に必要なデータを分析サーバ112から取得することができる。なお、センサーデータ取得部414はウェブ画面である必要はなく、例えばSQLステートメントによりセンサーデータを特定して取得させるなど、ユーザの指示に基づいてセンサーデータを返却できればよい。

なお、管理サーバと分析サーバとのそれぞれの機能を実現する２つのアプリケーションプログラムにより、図４で示す機能モジュールが提供されることを想定する。その場合には、例えば、管理サーバ111の機能を実現するアプリケーションプログラムにより４０１〜４１０として説明した機能モジュールが提供されることが想定される。

＜管理システム106の記憶部構成例＞
図5は、図3のROM303又は記憶装置308に不揮発的に記憶されるプログラム及びデータのメモリ空間を示す図である。尚、図5には、本実施形態に関連深いプログラム及びデータのみを示し、他は省略している。

システムプログラム501はOS等の装置の基礎的な制御を行う。デバイス管理プログラム502は管理システム106のデバイス管理全体を制御するプログラムである。かかるデバイス管理プログラム502の本実施形態に関連する部分は、以下に図13，図14，図15, 図16、図19を参照して説明される。ユーザインタフェース・プログラム503はユーザからのマスタデータ入力、またはユーザへのデバイス状態の表示出力などを制御するプログラムである。ユーザインタフェース・プログラム503は、ユーザから入力されたマスタデータを所定のデータベースへ保管する。ユーザ／管理デバイス／認証プログラム504はマスタデータを入力するユーザ、またはデバイスステータスデータを送信するデバイス監視モジュールを認証するためのプログラムである。

メッセージ送受信プログラム505は、デバイス監視モジュールとの間でInternet110を介してコマンドを含むメッセージ送受信を制御する。受信コマンド解析プログラム506は、デバイス監視モジュールから受信したメッセージに含まれるコマンドを解析して、それに対応する処理の実行を指示する。各処理プログラム507は、受信コマンド解析プログラム506の解析結果に対応して実行される。例えば、コマンドリクエストと解析すればコマンド送信プログラム508を実行する。コマンド送信プログラム508は、図2のS223、S224で示すように、デバイスで実行すべきコマンドが設定されていた場合に、デバイス監視モジュールへコマンドを送信するプログラムである。また、受信コマンド解析プログラム506による受信コマンドの解析の結果、スケジュール設定リクエストであればスケジュール設定送信プログラム509を実行する。スケジュール設定送信プログラム509は、図2のS210、S211で示すように、通信スケジュールの設定情報を送信するプログラムである。また、デバイスのステータス受信と解析すればステータス受信プログラム510を実行する。ステータス受信プログラム510は、図2のS216で示すデバイスからのステータスデータ送信を受信するプログラムである。また、受信コマンド解析プログラム506による受信コマンドの解析の結果、条件データリクエストだと判断すれば、条件送信プログラム525を実行する。条件送信プログラム525は、図2のS214、S215のように、条件データをデバイスに送信するプログラムである。また、受信コマンド解析プログラム506による受信コマンドの解析の結果、センサーデータ受信だと判断すれば、センサーデータ受信プログラム526を実行する。センサーデータ受信プログラム526は、図19のS1911のデバイスからのセンサーデータ送信を受信するプログラムである。ここには、本実施形態に関連する受信コマンドを示したが、これに限定されない。

機種依存デバイスマスタDB511は、管理システム106のデータベースで保管する機種依存デバイスマスタDBを表すデータベース空間である。機種依存デバイスマスタDB511には、本実施形態ではデバイスの製品名称やスペックをあらわす基本情報512、機種別のエラー情報をあらわす機種依存エラー情報513、機種別のアラーム情報をあらわす機種依存アラーム情報514、その他、機種依存ジャム情報515、機種依存パーツ情報516、機種依存条件データ523、機種依存計算ロジック524などが含まれる。

監視対象デバイスマスタDB517は、管理システム106のデータベースで保管する監視対象デバイスマスタDBを表すデータベース空間である。監視対象デバイスマスタDB517には、本実施形態では監視対象デバイスの識別子となるデバイスID518や、監視対象となるデバイスの機種情報519、その他、データベースに登録を行ったが、監視を無効にしておくことのできる監視対象有効ステータス520、監視対象の送信設定を保存しておく送信設定情報521などが含まれる。さらに、デバイス内のセンサーの瞬時値を記録したセンサーデータ522が含まれる。

＜RAM304のメモリ空間構成例＞
図6は、図3のRAM304に一時記憶されるメモリ空間を示す図である。尚、図6にも、本実施形態に関連深いプログラム及びデータのみを示し、他は省略している。デバイスID601は、デバイス監視モジュールから送信されたデバイスIDである。通信入力メソッド602は、デバイス監視モジュールが送信してくる通信の入力メソッドを表している。通信の入力データ603は、デバイス監視モジュールが送信してくる通信の入力データを表している。例えば、メソッドとして、カウンタ種の入力を意味し、入力データ部には、実際のカウンタ番号とカウンタ値が格納される。機種依存デバイスマスタによる送信スケジュール設定情報604には、対象デバイスに関連付けられた機種依存デバイスマスタの送信スケジュール設定情報が出力される。監視対象デバイスマスタ情報による送信スケジュール設定605には、対象デバイスに関連付けられた監視対象デバイスマスタの送信スケジュール設定情報が出力される。アプリケーションプログラムは、デバイス監視モジュールからスケジュール設定リクエストのメソッドを受信すると機種依存デバイスマスタによる送信スケジュール設定情報604、および監視対象デバイスマスタによる送信スケジュール設定情報605を参照し、対象のデバイス監視モジュールに適切な送信スケジュール設定を決定する。ここで決定した送信スケジュール設定は、606に出力される。
プログラムロード領域607は、図3に示したプログラムをCPU302が実行するためロードする記憶領域である。

＜本実施形態の通信シーケンスの概略＞
図2は、本実施形態に係るデバイス監視モジュールと管理システム106とサーバ管理者間の通信シーケンス例の一部を表した図である。尚、図2では、サーバ管理者から管理システム106に対して、デバイスの「新機種情報登録」ステップS201や、デバイスの「機種属性情報登録」ステップS202、デバイスの「追加条件データ登録」ステップS220の指示を行う例を示すが、これは通信シーケンスの概略の説明であって、実際にはこれに限定されない。また、図1について説明したように、以下の説明におけるデバイス監視モジュールとは、イベント監視プログラム1822および各処理プログラム1806を含むプログラム群に相当する。また、実施形態の初めに説明したスケジュール系通信は、図2におけるステップS208〜S211及びステップS216〜S218に相当する。分析データの取得に係る工程は、ステップS212〜S215及びステップS219〜S227に相当する。ステップS201〜S207はデバイスを管理システムの管理下に置くための工程である。ステップS201/S202は、サーバ管理者による管理システム106に対しての、デバイス新機種情報登録を表している。ステップS201では、デバイスの機種名や、製品スペック、製品カテゴリなど、市場に投入された新機種の基本的情報を登録している。ステップS202では、新規管理対象である機種のエラーコード情報、パーツコード情報を登録している。さらに、ステップS202では、機種依存の条件データを登録する。条件データとは、デバイス内のセンサーにより検知された値を記録したセンサーデータを、デバイスから管理システム106に対して送る条件を示すデータである。センサーの数は多く、また、各センサーにより検知した値は例えば所定の頻度で取得されるため、デバイス内のすべてのセンサーにより検知された値をそのまま管理システム106に対して送信すると、データ容量が膨大になってしまう。そのため、条件データによりフィルタリングが行われる。なお、ある機種のデバイスをメンテナンスするには、エラーコード情報、パーツ情報、アラーム情報、ジャム情報、条件データなど複数の属性情報が必要になる。以後この属性情報のことを、機種依存デバイスマスタデータと呼ぶ。図2のシーケンス図では、エラー情報と、パーツ情報、条件データがステップS202で登録されたことを表しており、この登録シーケンスが行われる事で、新規機種のデバイスが管理システム106で利用可能となることを意味している。ステップS203では、顧客先でデバイス管理を開始するための設定作業を表している。

ステップS204で、顧客先に設置しているデバイス監視モジュールから、管理システム106に対して通信可能か確認を行う通信テストを行う。この通信テストを受信した管理システム106は通信データの内容から、デバイス監視モジュールのID番号をベースに認証を行う。管理システム106は、認証が成功だった場合に、監視対象であるデバイスIDの確認を行う。監視対象としてのデバイスの情報（デバイスIDを含む）はすでに登録済みのものとし、管理システム106に登録されているデバイスIDと、通信テストで受信したデバイスIDをマッチさせることにより、管理システム106はデバイスの詳細情報を認識する。すなわち、ここでいうデバイスIDの確認とは、デバイス監視モジュールから受信したデバイスIDで監視対象デバイスマスタDB517を検索し、該当するデバイス機種情報等の詳細情報を読み出してRAM304へロードすることである。ここで、ステップS205のように、HTTPのレスポンスとして、通信テストが問題なく完了したことをデバイス監視モジュールに通知するデータを送信する。この通信テスト完了情報が、ステップS207で表されている。S209、S213、S217、S222、S226も同様に、応答メッセージをHTTPレスポンスで返すことを示している。また図２におけるデバイス監視モジュールからの送信先は管理システム106に限られることから、以下の説明ではデバイス監視モジュールからの送信先は省略する。

通信テストが問題なく完了すると、ステップS208にてデバイス監視モジュールは、スケジュール情報リクエストを送信する。スケジュール情報リクエストS208は、デバイス監視モジュールが、どのようなスケジュールにしたがってデータを送信するかを管理システム106に通知し、また、どのイベントデータを管理システム106が必要とするかを管理システム106に問い合わせるメッセージである。ステップS210にて、管理システム106は、スケジュール情報リクエストS208の送信元のデバイス（以下、対象デバイスと呼ぶ）のデバイスIDから機種情報を特定して、リクエストを受けたデバイスの機種と、機種依存デバイスマスタデータとを比較し、管理システム106で管理可能であるかを判定する。本例では、エラー情報とパーツ情報とが機種依存デバイスマスタDB518に登録されているものとする。したがってエラー情報とパーツ情報とを管理あるいは処理する事ができるが、その他の情報を受信してもそれを取り扱えずに読み捨ててしまうことになる。よって、管理システム106は、基本データとしての課金カウンタ情報と、属性情報としてのエラー情報とパーツ情報とを送信するように、対象デバイスのデバイス管理モジュールに設定情報を送信する。

ステップS211は、ステップS208に対するHTTPレスポンスS209として、デバイス監視モジュールに上述した設定情報を送信している事を表わしている。ステップS212で、デバイス監視モジュールは、条件データリクエストを送信する。これは、デバイス内の各種センサーの検知した値を記録したセンサーデータを管理システム106に対して送信する条件を問い合わせることを表わしている。ステップS214にて、管理システム106は、対象のデバイスIDから機種情報を特定して、条件データを特定する。ステップS215において、管理システム106は条件データをステップS212に対するHTTPレスポンスS213として返却する。ステップS216,S217,S218は、デバイス監視モジュールが通常の管理状態に入り、通常の通信を行っていることを意味している。この通信は、ステップS211によって指定された設定情報に従って情報を送信している。例えば、監視対象のデバイスにエラーが発生し、デバイス監視モジュールがエラーを検知した場合には、即時に管理システム106へエラー情報を送信する。

ステップS219では、イベント監視部1822が通常の監視状態に入り、通常の通信を行っていることを意味している。イベント監視部1822は、イベントの発生時に、条件データに応じて、その時点から遡った過去のデバイス状態のスナップショットを管理システムに対して送信する。すなわちステップS219は、説明の便宜として図2のように表現されているが、条件データがデバイスにいったん設定されると、他のステップとは非同期に実行される。この通信についての詳細は、図19で後述する。

ステップS220では、サーバ管理者による管理システム106に対しての、追加の条件データ登録を表している。ステップS201で機種情報を登録したときには、収集する必要がないと判断されていたセンサーデータが、後から分析のために必要になり収集対象となったとする。その場合ステップS220にて、サーバ管理者は追加条件データを登録する。例えば、ある機種のデバイスで一定の印刷枚数を超過するとジャムが多発するようになり、その原因分析が必要になったなどの場合である。条件データの追加登録により、管理システム106は、対象機種のデバイスに対して送信すべき条件データが増える事になる。条件の追加前に設置を行った対象デバイスは、追加した条件に適合するセンサーデータを管理システム106に送信しない。ここで、管理システム106は、通常送信のひとつであるコマンド取得通信がデバイス監視モジュールから送信されてくるのを待つ。

ステップS221では、デバイス監視モジュールが設定にしたがって、管理システム106に対して、コマンド取得通信を行っていることを表している。ステップS223で、管理システム106は、S221でコマンド取得通信を行ったデバイス監視モジュールの認証を行い、またデバイスIDを特定する。さらに、対象のデバイスIDの条件情報の変更の有無を判定する。変更があった場合はS224で条件データリクエストを行うようにデバイス監視モジュールに対して応答を行う。ステップS224の応答はステップS221に対するHTTPレスポンスS222として返される。

ステップS225は、デバイス監視モジュールが管理システム106に対して条件データリクエストを行うことを表わしている。リクエストを受けた管理システム106は、対象のデバイスIDから機種情報を特定して、リクエストを受けたデバイスの機種をもとに、条件データを特定する。ステップS227において、管理システム106は条件データを返却する。応答S227はステップS225に対するHTTPレスポンスS226として返される。

ステップS228において、デバイスは受信した条件データと、条件データDB1829とを比較し、追加条件があれば条件データDB1829に条件データを追加する。なお、ステップS228で追加された条件に適合するセンサーデータは、一定周期で実行されるS219のイベント監視部1822による処理により、管理システム106にアップロードされる。S219の処理については、図19で詳述する。

なお、ステップS220以降のシーケンスは、追加の条件設定を行わない限り行う必要はない。また追加の条件設定が行われた場合には、ステップS228の後に、ステップS215〜S219が実行される。

以上の処理およびメッセージシーケンスにより、監視対象のデバイスごとに、設定したスケジュールに従って、管理システムは監視対象のデバイスからデバイス状態を収集できる。加えて、条件データをデバイスに対して設定することで、デバイスにイベントが生じた場合に、管理システムは、条件データに応じた過去のデバイス状態を収集できる。

＜管理システム106からの通信データの構成例＞
図7は、管理システム106からデバイス監視モジュールへ送信されるスケジュール設定情報を模式的に表した図である。図7で、レスポンス701は、管理システム106が受信したスケジュール情報リクエストに対応したレスポンスである。レスポンス701はスケジュール情報リクエストに対するレスポンスであることを示すコマンドである。レスポンス701は、図2のスケジュール情報リクエストS208に対する応答である「設定情報の送信」S211で送信される情報に相当する。

スケジュール設定情報702はスケジュール設定情報のヘッダ情報を示し、各データタイプに関する送信Off/On設定や、スケジュール通信の間隔等の情報を含む。すなわち、スケジュール設定情報702が、図2で説明した、デバイス監視モジュールに対して送信され設定されるスケジュールデータに相当する。スケジュールデータは、論理和によって結合される複数のトリガを含むことができる。すなわち複数のトリガのうちいずれかに該当すればトリガ条件に該当するものと判定される。複数のトリガ条件のそれぞれは、そのトリガ条件のタイプ（トリガタイプ）を含む。本例ではトリガタイプにはイベントタイプとスケジュールタイプとを含む。イベントタイプはイベントの発生がデバイス状態データの送信のトリガとなる（ただしトリガ条件が満たされなければ送信はされない）。スケジュールタイプは予め定められた時刻や間隔に達したことがトリガとなる。またトリガタイプがイベントタイプであれば、そのトリガ条件は、送信対象が何であるかを示すコードを含む。この送信対象のコードにより、例えばエラー、アラーム、ジャムといったイベントの区分および区分ごとの種類が示される。また、設定された送信対象のコードに該当するイベントが生じたときに、デバイス状態データ、例えば発生したイベントを管理システム106に送信するか否かを示す送信設定をトリガ条件に含む。送信設定がONであれば、設定されたトリガ条件を満たすデバイス状態データを管理システム106に送信し、OFFであれば設定されたトリガ条件を満たすデバイス状態データを管理システム106に送信しない。また、トリガタイプがスケジュールタイプの場合には、送信対象のデバイス状態データを示す情報と、送信するか否かを示す送信設定と、送信するスケジュールとを含む。スケジュールには、送信開始に日時と送信間隔を含む。

さて図7の具体例を説明する。タイプ703は、トリガタイプがイベントタイプであることを示す情報が出力されている。コード704には、そのイベントはあるエラーであることを示しているエラーコードが記録されている。また、送信設定705には送信設定としてONの値が出力さている。すなわち、条件703,704,705では、監視対象であるデバイスに、設定されたエラーコードのエラーが発生した場合には、イベントベースで即時、すなわちイベント発生の都度、管理システム106に送信を行うということをデバイス監視モジュールに対して指示している。条件706,707,708では、監視対象であるデバイスに、設定されたコードのアラームが発生した場合でも、情報を管理システム106に送信しないということを指示している。条件709,710,711では、監視対象であるデバイスに設定されたコードのジャムが発生した場合には、イベントベースで即時管理システム106に送信を行うということを指示している。また、条件712,713,714では、監視対象であるデバイスに設定されたパーツの寿命等を示すイベントが発生した場合には、そのイベントをイベントベースで即時管理システム106に送信を行うということを指示している。

またタイプ715には、スケジュールタイプの情報送信設定を示す情報が出力されており、データタイプ716にて、送信対象のデバイス状態データは、印刷カウントデータであることを示している。また、送信設定717には、送信設定としてONの値が出力され、送信開始日時718には、スケジュール送信を行う上で、基準となる送信開始日時が出力される。送信間隔719には、スケジュール送信を行う際の通信と通信の間隔時間を出力している。条件715,716,717,718,719では、トリガタイプがスケジュールタイプであること、送信対象のデータが監視対象であるデバイスの印刷カウンタデータであること、指定された送信開始日を初回として、指定の送信間隔で送信対象のデバイス状態データの送信を行うという事を指示している。条件720,721,722,723,724では、監視対象であるデバイスの設定情報を、指定の送信開始日を初回として、指定の送信間隔で送信するという事を指示している。条件725,726,727,728,729では、デバイス監視モジュール自身が、監視サーバに対して、コマンドリクエスト問い合わせを行うように指示している。このときの送信開始日時と送信間隔とを、その他の通信と同様に指定している。

図8で、レスポンス801は、管理システム106が受信したコマンドリクエストに対応したレスポンスである。コマンド情報801としてはコマンドリクエストに対するレスポンスであることを示すコマンドが出力される。レスポンス801は、図2のステップS224で送信されるレスポンスに相当する。通信結果802はコマンドリクエストを受信成功したか、失敗したかを示すコードを出力する。処理完了日時803には、処理を完了した日時を出力し、詳細説明804には、受信失敗時の例えば理由等の詳細説明を出力する。コマンド805には、コマンド情報が入る。これは、対象となる被管理装置に指示するべきコマンドがある場合に出力される。

＜管理システム106の機種依存デバイスマスタデータDBの構成例＞
図9は、管理システム106内部のデータベースの一部を模式的に表した図である。図4のブロック図では、マスタデータ記憶部401に相当する。マスタ情報901は、機種依存デバイスマスタデータの一部を表しており、ProductAという製品に関する機種情報が格納されている。スペック情報902には、製品の仕様に関する情報、例えば、デバイスのクラス情報や、1分間に何枚のプリントができるのか、カラー機なのか、白黒機なのか、といった製品の基本仕様情報が保管される。トナー情報903には、対象デバイスで使用できるトナーの情報が保管される。カラー機であった場合には、項目904,905,906,907に、各色のトナー製品情報が保管される。ここには、製品名の情報だけでなく、推奨寿命枚数などのトナー属性情報も一緒に保管される。
エラーコード情報908には、ProductA製品に実装されているエラーコードに関する情報が保管されている。項目909、910では具体的な各エラーコードと、そのエラーコードの説明・対応方法などが関連付けられている。アラームコード情報911には、ProductA製品に実装されているアラームコードに関する情報が保管されている。項目912,913では、具体的な各アラームコードと、そのアラームコードの説明・対応方法などが関連付けられている。ジャムコード情報914には、ProductA製品に実装されているジャムコードに関する情報が保管されている。項目915、916では、具体的な各ジャムコードと、そのジャムコードの説明・製品のどの場所でジャムが発生しているのかなどの情報が関連付けられている。パーツコード情報917、918、919では、具体的な各パーツコードとそのパーツコードの説明・パーツ製品名・推奨寿命などの情報が関連付けられている。また、最終更新日時920には機種依存マスタが更新された日時が保管される。データ作成日時921には、機種依存マスタが最初に作成された日時が保管される。条件データ922には、条件データが格納されている。条件データとは、監視対象デバイスがアップロードすべきセンサーデータの条件を表わすデータである。条件データは機種ごとに別々のデータとなり、別々に管理される。たとえば、ある機種Aにおいて高頻度で故障が発生している場合、重点的にある機種Aのセンサーデータを集めることで故障分析を高精度で行うことができる。また、ある機種Bに関しては、ジャムが高頻度で発生するため、ジャムイベントに関してのみ重点的にセンサーデータを集めるといったことが可能である。条件データには、図10に示すように、エラー、アラート、ジャムなどのデバイス内のイベントを一意に識別するイベントID1001と、アップロードすべきセンサーデータを特定するための目的日時を算出するロジックを一意に識別する計算ロジックID1002と、計算ロジックの入力となる絶対値1003とを含む。絶対値1003は、物理時間（例えば秒単位）や印刷枚数やドラムの回転数等を単位として、現在時刻から計算ロジックに従って遡るための定数である。条件データに関しては、図19の説明とともに後で詳述する。計算ロジック923には、時間を遡るための計算ロジックが格納される。計算ロジックに関しては、図11で詳述する。そして、遡った時刻に取得され保存されているデバイス状態のスナップショットが、管理システム106に送信される。

＜監視対象デバイスマスタデータDBの構成例＞
図12は、管理システム106内部のデータベースの一部を模式的に表した図である。図4のブロック図では、401のマスタデータ記憶部に相当する。マスタ情報1201は監視対象デバイスマスタデータの一部を表しており、監視対象デバイスAというデバイスに関するデバイス情報が格納されている。デバイスID1202には、監視対象デバイスAのデバイスIDが保管されている。デバイス監視モジュールが送信してくるデバイスの情報と、このデバイスID1202とを利用して、受信したデバイスの情報がどのデバイスの情報なのかを管理システム106は一意に判断する事ができる。製品情報1203には、監視対象デバイスAの製品情報が格納される。この製品情報1203は、図9の機種依存デバイスマスタDBと関連付けられ、監視対象のデバイスのエラー情報やアラーム情報、その他の属性情報が、この製品情報を通じて利用可能となる。フラグ1204は、監視対象として、有効にするか、無効にするかを設定する事のできるフラグを意味している。例えば、一時的にデバイス管理システム106で監視対象からはずしたい場合などに、このフラグをOFFにすることで監視対象から外れる事になる。ファームウェア情報1205は、監視対象デバイスには、どのバージョンのファームウェアが実装されているかを格納する場所である。

顧客先情報1206には、監視対象デバイスの顧客先情報を保管する。顧客名1207、担当者名1208、設置場所1209のそれぞれに、顧客名、担当者名、設置場所を保管することによって、デバイスに緊急のエラーが発生した場合でも、すぐに、対象のデバイスがどの顧客の所有物なのかをシステムユーザに通知する事ができる。

ネットワーク情報1210には、監視対象デバイスのネットワーク情報を保管する。デバイス名1211、IP Address1212、MAC Address1213には、それぞれ監視対象デバイスのデバイス名やIP Address、MAC Addressなど保存する。管理者情報1214は、監視対象デバイスの顧客先管理担当者の情報を保管する。管理担当者名1215、メールアドレス1216には、顧客先でデバイスそのものの調子を管理している管理者の名前とメールアドレスを保管する。また、消耗品担当者名1217、メールアドレス1218には、顧客先で、デバイスのトナーなどの消耗品を管理している管理者の名前とメールアドレスを保管する。

フラグ1219には、機種依存デバイスマスタと監視対象デバイスマスタをあわせて、スケジュール通信を変更するべき情報が更新されたかどうかを示すフラグ情報が保管される。例えば、監視対象有効フラグ1204が、「有効」から「無効」に変更された場合には、デバイス監視モジュールから、デバイスに関するデータは送信する必要がなくなる。これを受けてアプリケーションプログラムは、全てのデバイス情報の送信設定をOFFに変更する。しかし、また監視対象フラグが「無効」から「有効」へと変わる事があるかもしれないので、コマンドリクエストのスケジュール通信のみは、スケジュールしておく必要がある。

このようにデバイスのステータス情報が変化すると、管理システム106で必要な情報も変化する。これによって、デバイス監視モジュールへスケジュール変更の依頼を行うが、依頼の必要になった時に、この設定値変更フラグをつけておく。また、日時1220には監視対象デバイスマスタが更新された日時が保管される。1121には、監視対象デバイスマスタが作成された日時が保管される。

＜本実施形態の管理システム106の動作例＞
上記構成に基づいて、本実施形態の管理システム106の動作例を説明する。尚、以下の動作例では、処理を単純化するためにデバイス監視モジュールは同じデバイス内の監視モジュールで管理されているものとして説明する。しかし、実際には、デバイス監視モジュールが複数のデバイスを管理しており、その場合には特定のデバイスに対しては独立の処理となるが、そのための処理手順は明らかである。

本動作例では、デバイス監視モジュールから何らかの通信があった場合に管理システム106が通信メソッドを認識し、デバイス監視モジュールからの送信すべき情報が管理システム106にとって必要十分な情報となるように送信設定を指示する例を示す。

図13は、管理システム106が、通常のデバイス監視モードにあるときに、デバイスから通信リクエストを受けた場合の振る舞いを表すフローチャートである。または、管理システム106の管理者から機種依存デバイスマスタデータの更新を受けたときに振る舞いを表すフローチャートである。または、ユーザによる監視対象デバイスの登録のリクエストを受けたときの振る舞いに関する処理を表すフローチャートである。

このフローチャートで表す動作例は、管理システム106内のデータベースの設定値によって、デバイス監視モジュールに適切な通信設定を管理システム106が自動的に決定し、設定情報を送信することを特徴とする。すなわち、サーバ管理者によって、データベースのデータに更新が行われようと、ユーザによってデバイス情報に更新が行われようと、常に管理システム106は、通信によるデバイス監視モジュールからの通信と、データベースのステータスを認識する。これは、ユーザが意識しなくても必要十分な管理が行われるように通信情報がコントロールされることを意味する。また、ここでの動作例では、デバイス監視モジュールはデバイスに内蔵されているものとして、管理システム106はデバイスと通信を行うものとする。

ステップS1301では、管理システム106の内部処理であるループの開始を表している。これによって、管理システム106はデバイスの監視モードに入る。なおステップS1301とステップS1312はループの始端と終端とをそれぞれ表しており、図13の処理は、いったん開始されたなら中断されるまで繰り返される。ステップS1302にて、管理システム106が、Network I/Fを通じてデバイスから通信を受信した場合には、ステップS1305へ進み、通信相手であるデバイスは、管理システム106内に登録しているデバイスIDと一致するかの判定を行う。ステップ1302にて、管理システム106がデバイスから通信を受信しなかった場合に、ステップS1303へ進み、管理者から機種依存デバイスマスタに更新があるか判定を行う。管理システム106はステップS1303で、管理者による機種依存マスタの更新、または登録があるかを判定するが、ここで機種依存マスタに更新があった場合に、ステップS1306へ進み、機種依存マスタ関係のあるデバイスを監視対象デバイスマスタから抽出する。機種依存マスタに更新がある場合には、関連するデバイスは通信内容に影響を受けるため、対象となるデバイスの設定変更フラグをセットする。例えば、ある機種のアラーム情報が追加された場合には、今後管理システム106で対象機種のアラーム情報をコントロールする事ができるようになるので、デバイスからアラーム情報を送信するようにデバイスの通信設定を更新する必要がある。ここでは、管理システム106からデバイスに対して、通信設定を更新できないので、デバイスから通信されるのを待つ。この変更をデータベース内に保管しておくために、ステップS1306では、次回の通信があったときには、通信設定を更新するリクエストをすることを指示するために、設定変更フラグをセットしておく。この処理が終わると、ステップS1312へ進み、ループの最初のステップであるS1301へ戻る。ステップS1303にて、管理者による機種依存マスタの更新がなかった場合に、ステップS1304へ進み、ユーザによる監視対象デバイスマスタの更新があるか確認する。管理システム106は、ステップS1304にて、ユーザによる監視対象デバイスマスタの更新があるか判定し、更新があった場合には、ステップS1307に進み、データベースへの更新が通信設定の更新を必要とする更新であった場合に、更新対象デバイスの設定変更フラグをセットし、対象デバイスからの通信に備える。また、ステップS1304にて、ユーザからの更新がなかった場合には、ステップS1312へ進み、監視モードのループへ戻る。ステップS1307にて、設定変更フラグをセットした後に、ステップS1312へ進み、監視モードのループへ戻る。

ステップS1305にて、通信リクエストを送信してきたデバイスのIDが、管理システム106の管理する監視対象デバイスマスタDBに登録されているか判定する。ここで、登録されていなかった場合には、ステップS1311へ進み、未登録デバイス用の通信処理を行う。デバイスの管理とは、通常、管理システム106に監視対象デバイスを登録してから、顧客にデバイスを設置し、管理システム106へ通信を行う。しかし、必ずしもそのように運用が行えるものではなく、デバイスの登録を行う前に、デバイスからの通信が先に行われてしまう事がある。このようなケースでは、顧客側で設定処理を終わらせてしまって、登録が行われた段階で管理を始めればいい。実際の管理システム106の処理としては、ステップS1311にて記述する処理を行う。また、未登録デバイス通信処理は、図15で説明を行う。

ステップS1305にて、通信リクエストを行ってきたデバイスのデバイスIDが監視対象デバイスマスタに登録してあった場合にはステップS1308へ進み、管理システム106は、通信メソッドを特定して、通信テストのリクエストか否かを判定する。ステップS1308で、行われた通信が通信テストメソッドであった場合には、ステップS1310へ進み、getConfiguratioの通信処理を行う。このgetConfigurationメソッドは、図2のステップS208に相当する。また、ステップS1308にて、通信メソッドが、通信テストでないと確認できた場合には、ステップS1309へ進みスケジュール系通信処理を行う。これら、getConfiguration通信処理は図14に示すフローチャートで説明する。また、スケジュール系通信処理に関しては、図16に示すフローチャートで説明を行う。

図14は、図13のステップS1310のgetConfiguration通信処理の詳細処理を表す。getConfiguration通信処理が開始されると、ステップS1401にて、監視対象デバイスマスタのステータスが有効か無効かを判定する。対象デバイスのステータスが無効であった場合には、ステップS1402へ進み、全通信機能のうち、コマンドリクエストの問い合わせのみ設定し、通信のレスポンスとして送信設定情報を対象デバイスへ送信する。このようにすることで、現在管理対象でないデバイスからの通信を最小限に抑えることができる。また、コマンドリクエスト問い合わせを設定した理由として、将来、監視有効無効フラグが有効になった場合に、再度、対象デバイスの送信設定を変更し、必要なデータを送信するようにコントロールを行う必要があるからである。また、ステップS1402にて、設定を完了したら、ここでのgetConfiguration通信処理を終了する。ステップS1401にて、該当デバイスが有効の状態であった場合に、ステップS1403へ進み、対象デバイスの機種情報から、機種依存デバイスマスタを参照する。ステップS1404へ進み、機種依存デバイスマスタで全ての属性情報が登録済みであり、コントロールできる事が確認できた場合、次にステップS1405へ進む。機種依存デバイスマスタの情報がすべて用意されていなかった場合には、ステップS1406へ進む。ステップS1405では、通信を行ってきたデバイスに対し、管理システム106が管理を行う事のできる全ての機能を有効にする通信設定を行い、通信のレスポンスとして、対象のデバイスに送信設定情報を送信する。ステップS1406では機種依存デバイスマスタに登録してある属性情報をベースにコントロールのできる通信種類を決定し、通信リクエストを行ったデバイスに対してレスポンスとして送信設定情報を送信する。それぞれのステップでデバイスに送信設定を返す事でgetConfigurationの通信処理を終了する。

図15は、図13のステップS1311の未登録デバイス通信処理の詳細処理を表す。未登録デバイス通信処理が開始されると、ステップS1501にて通信のメソッドが、通信テストを意味するものなのか、それ以外のものなのかの判定を行う。もし、通信のタイプが通信テストであった場合には、ステップS1503へ進み、全通信機能のうち、コマンドリクエストの問い合わせ通信のみを有効にして、送信設定を決定し、通信のレスポンスに決定した送信設定を送信する。続けて、デバイスに対して送信指示を完了する。また、ステップS1501にて、通信テストでないとわかったとき、ステップS1502へ進む。ステップS1502では、通信のタイプがコマンドリクエストか、それ以外かを判定する。ここで通信のタイプがコマンドリクエストであった場合には、ステップS1504に進み、その通信に関しては何も処理を行わず、デバイスに対して、正常に通信が完了したことを伝える情報を送信する。また、ステップS1502にて通信のタイプがコマンドリクエストではないとわかったときには、ステップS1505へ進み、システムとデバイス間で障害が発生している可能性があるので、この事象をシステム管理者へ伝える通知を行う。

図16は、図13のステップS1309のスケジュール系通信処理の詳細処理を表す。スケジュール系通信処理が開始されると、ステップS1601にて、通信の種類がコマンドリクエストなのか、それ以外なのかを判定する。この判定処理によって、通信の種類がコマンドリクエストだった場合には、ステップS1602へ進む。またそれ以外の通信処理だった場合には、ステップS1603に進む。ステップS1602では、監視対象デバイスマスタの有効無効状態を判定し、有効状態がセットされていた場合には、ステップS1604へ進む。ステップS1604では、監視対象デバイスマスタの設定値更新フラグを参照する。ここで更新フラグがセットされていた場合には、ステップS1605へ進み、通信対象デバイスに対してgetConfigurationメソッドをリクエストする。その後、ステップS1608でgetConfigurationの通信リクエストを受信したら、ステップS1310のgetConfiguration通信処理を行う。この処理が完了したら、ステップS1609にて、監視対象デバイスマスタにて、対象デバイスの設定値更新フラグをクリアする。

ステップS1604にて、監視対象デバイスマスタの設定値更新フラグがセットされていなかった場合には、ステップS1606に進み、通信データを正しく受信し、正常に処理が終了した事を伝える処理を行う。ステップS1601にて、通信の種類がコマンドリクエストでなかった場合には、ステップS1603へ進み監視対象デバイスが有効であるか無効であるかを判定する。該当デバイスが有効の状態であった場合には、ステップS1606へ進み、データを正しく受信し、正常処理を行ったことを返信する。また、ステップS1603にてデバイスが無効状態であった場合には、ステップS1607へ進み、受信データをすべて破棄し、通信が正常に終了した事をデバイスに返信する。

ステップS1602にて、該当のデバイスが無効状態であった場合には、全通信機能のうち、コマンドリクエストのみを有効にセットし、レスポンスに送信設定を送信する。

上記の動作を行う事により、常に管理システム106は管理対象のデバイスからデバイスを管理するうえで必要十分な情報を受信することができ、ネットワーク帯域・ハードウェアリソースを無駄に使用することなく効率のよいデバイス監視を行う事ができる。

＜デバイスのハードウェア構成例＞
図17は、デバイス内の制御部のブロック図である。ここではデバイス内でデバイス監視モジュールが処理を行う例を表している。デバイス監視モジュールはデバイス内の制御部内で処理され、デバイスの個別情報の管理や、デバイスのステータス情報を管理システム106に送信するなどの処理を行う。デバイスの制御部では、主として、プリントやスキャンなどプログラムの制御処理を行い、そのほかに、デバイス監視モジュールなどの各アプリケーションが制御されている。制御部の各構成要素は、システムバス1716及び画像バス1717に接続されている。

ROM1704にはデバイスの制御プログラム及び、デバイス監視プログラムが格納されており、CPU1707で実行される。 RAM1705は、プログラムを実行するためのワークメモリエリアであり、デバイス監視プログラムが監視を行ううえで必要なデバイスのステータス情報や、画像データを一時記憶するための画像メモリでもある。記憶装置1706は不揮発性の記憶装置であり、デバイスの再起動後も保持しておく必要のある各種動作モード設定や、カウンタ値、稼働ログなどが記憶される。Network I/F1702はLANと接続するためのインタフェース部であり、LANを介して管理システム106と通信を行う。回線I/F部1703は、ISDNや公衆電話網に接続され、ROM1704内の通信制御プログラムにより制御され、ISDN I/Fやモデム、NCU（Network Control Unit）を介して遠隔の端末とデータの送受信を行う。ファクシミリの送受信もこの回線I/F部1730を使用して行う。操作部1701には表示手段やキー入力手段が内蔵されており、これらはCPU1707にて制御される。操作者は、キー入力手段を通してスキャナ読み取りやプリント出力に関する各種設定指示や、作動／停止指示を行う。

以上のデバイスがシステムバス1716上に配置される。IO制御部1708は、システムバス1716と画像データを高速で転送する画像バス1717とを接続するためのバスブリッジである。 画像バス1717は、PCIバスまたはIEEE1394で構成される。画像バス1717上には以下のデバイスが配置される。 デジタルI/F部1711は、デバイスのリーダー部1715やプリンタ部1714と制御部とを接続し、画像データの同期系／非同期系の変換を行う。また、リーダー部1715やプリンタ部1714内の各所に配置した前述の各種センサーが検出した情報は、このデジタルI/F部1711、及びIO制御部1708を介してシステムバス1716へ流れる。画像処理部1709は、入力及び出力画像データに対し補正／加工／編集を行う。画像回転部1710は画像データの回転を行う。画像圧縮伸長部1712は、多値画像データはJPEG、2値画像データはJBIG/MMR/MR/MHの圧縮伸張処理を行う。画像密度変換部1713は、出力用画像データに対して解像度変換等を行う。

CPU1707で実行される制御プログラムにより、CPU1707は記憶装置1706内のカウンタ値や稼働ログなどの稼動情報や障害情報を読み出してデバイスのステータス情報として監視サーバへ、Network I/F1702を介して送信する。

＜デバイスの記憶部構成例＞
図18は、図17のROM1704又は記憶装置1706に不揮発的に記憶されるプログラム及びメモリ空間を示す図である。尚、図18には、本実施形態に関連深いプログラム及びデータのみを示し、他は省略している。

システムプログラム1801はOS等の装置の基本的な制御を行うプログラムである。デバイス管理プログラム1802はデバイスの管理を制御するプログラムである。メッセージ送受信プログラム1803は管理システム106から設定指示等を受信する、または、デバイスのステータス情報やコマンドリクエストを管理システム106へ送信するための送受信を制御するプログラムを表している。

受信コマンド解析プログラム1804は管理システム106から受信した通信に含まれているコマンドを解析し、何を行うかを決定するプログラムを表している。受信コマンド解析プログラム1804にて受信したコマンドが、スケジュール情報の設定であった場合に、スケジュール解析プログラム1805を利用して、どの種類のデータをどのスケジュールで管理システム106に送信するのか、またはしないのかを決定する。

処理プログラム1806は、スケジュール解析プログラム1805の解析結果に対応して実行される各処理プログラム1807-1810,1824の総称である。例えば、イベント情報送信処理プログラム1807はデバイスでイベントが発生した場合には、イベントデータをどのタイミングで管理システム106に送信すればいいのか、解析結果を確認し、その解析結果に応じてイベント情報送信処理を実行する。また、スケジュール送信プログラム1808はスケジュールデータを送信する。カウンタ情報送信処理プログラム1809はカウンタ情報を送信する。スケジュール設定変更処理プログラム1810はスケジュール設定を変更する。条件データ変更処理プログラム1824はセンサーデータを管理システム106に送信する条件となる条件データを変更するためのプログラムである。

デバイスID1811はデバイスを管理システム106内で識別できるデバイスIDを表している。また、記憶装置内には、デバイスの状態が保管してあるデバイス状態DB1812が管理されている。デバイス状態DB1812には、デバイスのファームウェアやデバイスのタイプなど、デバイスの基本情報1813や、今までに発生したエラー1814・アラーム1815・ジャム1816などのイベント情報、パーツの消耗度1817などが保管されている。また、カウンタデータDB1818は、デバイスのカウンタデータのデータベースを現しており、これは、課金カウンタ1819や機能カウンタ1820が管理されている。

イベント監視プログラム1822は、デバイスにおいて一定周期で実行されるプログラムである。イベント監視プログラム1822は、管理システム106にアップロードすべきセンサーデータが存在しないかを、デバイス状態DB1814を監視し、後述の条件データDB1829と計算ロジックDB1830で管理される情報を用いて監視する。アップロード部1823は、イベント監視プログラム1822が特定したアップロードすべきセンサーデータを管理システム106にアップロードする。

センサーデータDB1825は、各種センサーデータの瞬時値をスナップショットとして保持するデータ格納領域である。センサーデータDB1825で管理されるセンサーデータについては、図20で詳述する。本実施例においては、センサーデータDB1825には、温度センサー情報1826、振動センサー情報1827、圧力センサー情報1828が格納されている。なお、本実施形態においてはセンサー情報の種類については限定しない。

条件データDB1829はアップロードすべきセンサーデータを特定するための条件データを格納した条件データのデータベースである。条件データDB1829に関しては、この後に図10を参照して詳述する。条件データDB1829には、図2のステップS215及びステップS227で管理システム106から受信した条件データを特定できるように、条件データが格納される。たとえば受信した条件データそのものを格納してもよい。

計算ロジックDB1830は計算ロジックを格納したデータベースである。計算ロジックについては、この後に図11を参照して詳述する。"absolute_time"ロジック1831、"print_count"ロジック1832、"revolution_count"ロジック1833は、それぞれ独自の計算ロジックにより日時すなわち時間情報の計算を行う。計算ロジックDB1830には、予め計算ロジックを実現するプログラム等が格納されている。また管理システム106から更新することもできる。

プログラムロード領域1834は、図17に示したプログラムをCPU1707が実行するためロードする記憶領域である。

なお、図18等に示したプログラムを実行することで実現される機能モジュールを、本実施形態では「プログラム名」＋「部」で示すことがある。例えばイベント監視プログラム1822をCPU1707で実行することで実現される機能モジュールはイベント監視部である。このイベント監視部はイベント監視プログラム1822と同じ参照番号を付してイベント監視部1822と称する。

＜本実施形態のデバイスの動作例＞
図19は、本実施形態に係る監視対象のネットワークデバイスと管理システム106間の通信シーケンス例の一部を表している。より具体的には、デバイスに電源が投入され、デバイスのイベント監視部1822が管理システム106に対してアップロードすべきセンサーデータが存在しないか監視するフローである。
ステップS1901で、デバイスのイベント監視部1822は、アップロード対象となるセンサーデータの監視を開始する。イベント監視部1822は、デバイス状態DB1812を参照し、新たなイベントが発生していた場合に、そのイベントに関連する条件データを条件データDB1829から参照することでアップロード対象となるセンサーデータを特定する。デバイス状態DB1812は、イベントの発生に応じて、たとえば当該イベントの管理システムへの通知とともに更新される。したがってイベント監視部1822は、イベントの発生そのものを監視しているのではなく、デバイス状態DB1812におけるイベント情報の更新を監視する。しかしながら、イベントの発生をリアルタイムで監視するように構成してもよい。
ステップS1902で、デバイスのイベント監視部1822は、デバイス状態DB1812からイベント情報を受け取る。
ステップS1903、S1904で、デバイスのイベント監視部1822は、条件データDB1829からS1902で受け取ったイベント情報をもとに条件データを受け取る。このとき、条件データは、発生したイベントIDをもとに特定され、取得される。ひとつのイベントIDに対して、複数の条件データが対応する場合は、対応するすべての条件データを取得する。例えば図10に示す条件データでは、JAM-CODE-001なるイベントIDに対して３つの条件データが関連付けられている。この場合にはこれら３つの条件データすべてが取得される。
ステップS1905で、デバイスのイベント監視部1822はS1904で取得した条件データをもとに計算ロジックを特定する。条件データには計算ロジックIDが含まれており、それが特定された計算ロジックを示す。
ステップS1906、S1907で、デバイスのイベント監視部1822はステップS1905で特定した計算ロジックを、計算ロジックDB1830から取得する。計算ロジックは条件データに対応する計算ロジックIDをもとに取得する。条件データが複数の場合は、対応する計算ロジックをすべて取得する。計算ロジックの詳細な処理の説明は図11を用いて後述する。なお計算ロジックがたとえばプログラムであれば、取得された計算ロジックは実行可能な形式でRAMにロードされる。
ステップS1908で、デバイスのイベント監視部1822はステップS1907で取得した条件データ、計算ロジックを用いてアップロード対象となるセンサーデータを特定するための目的日時を算出する。条件データが複数の場合は、複数の目的日時を算出する。なおここでいうセンサーデータはリアルタイムのデータではなく、過去に取得され、取得された日時に関連づけて保存されたスナップショットである。
ステップS1909で、デバイスのイベント監視部1822は、ステップS1908で特定した目的日時をもとに、センサーデータを特定する。センサーデータは一定期間ごとにスナップショットとしてデバイス状態DB1812に保存されており、ステップS1908で特定した目的日時に最も近いセンサーデータを特定する。また、本実施形態において、センサーデータはデバイス状態DB1812にすべて一つのテーブルとして保存されている構成となっているが、センサーデータを格納する領域はデバイス状態DB1812内で分散していても構わない。その場合は、分散しているセンサーデータを収集して、アップロード対象として特定する。
ステップS1911で、デバイスのイベント監視部1822は、ステップS1910で特定したセンサーデータを管理システム106にアップロードする。
ステップS1912で、デバイスのイベント監視部1822は、管理システム106からセンサーデータのアップロードが完了した旨の通知を受ける。
なお、デバイスのイベント監視部1822は、ステップS1901からステップS1912の処理を一定周期で繰り返す。

図10は、条件データDB1829が管理する条件データ1000の一例を示している。これは機種依存デバイスマスタDBに格納した条件データ922の少なくとも一部であり、同じ構造を有する。イベントID1001とは、エラー、アラート、ジャムなどのデバイス内のイベントを一意に識別するIDである。計算ロジックID1002とは、アップロードすべきセンサーデータを特定するための目的日時を算出するロジックを一意に識別するIDである。絶対値1003は、計算ロジックの入力となる値である。たとえば、イベントIDが"JAM-CODE-001"、計算ロジックIDが"absolute_time"の条件データに関しては、"JAM-CODE-001"が発生する、600,1200,1800,3600,86400秒前のセンサーデータを、"absolute_time"計算ロジックによりそれぞれ特定する条件であることを表わしている。

図20は、センサーデータDB1825が管理するセンサーデータ2000の一例を示している。スナップショット日時2001とは、センサーデータの瞬時値を取得した日時を表わしている。データ2002-2009は各センサーによるセンサーデータである。T_SENSOR_01、T_SENSOR_02、T_SENSOR_03は温度センサー情報1826を示している。V_SENSOR_01、V_SENSOR_02は、振動センサー情報1827を示している。P_SENSOR_01、P_SENSOR_02は圧力センサー情報1828を示している。図20は、デバイス内に8個のセンサーが設置されている例であるが、実際にはより多くのセンサーをデバイス内に設置することで、デバイスの状態をより精密に監視することができる。また、より多くの種類のセンサーを設定し、センサーデータDB1825で管理することも可能である。

図11は、アップロードすべきセンサーデータを特定するために必要な、目的日時を算出する計算ロジックの一例を示している。これは機種依存デバイスマスタDBに格納した計算ロジック923の少なくとも一部である。本計算ロジックは、イベント監視部1822が実行する関数、ライブラリ、実行モジュールである。本計算ロジックはデバイスの出荷時にあらかじめ登録されるとともに、ファームウェアアップデートなどのタイミングで随時追加が可能である。本計算ロジックが算出する目的日時は、アップロードすべきセンサーデータを特定するために使用される。各計算ロジックは、イベントが発生した時刻である"基準日時"と、"絶対値"を受け取ることで、"目的日時"を返却する。本実施例においては、上記の値を以下のように定義する。
T = "基準日時"
P = "目的日時"
A = "絶対値"。

図11(a)は、計算ロジックIDが"absolute_time"の場合の計算ロジックである。ステップS2201で、下記の計算式でPを算出する。
P = T - A
ステップS2202で、ステップS2201で算出したP(目的日時)を返却する。以上のように、ロジックIDが"absolute_time"の場合は、単純に時間を遡る計算ロジックである。例えば図10のイベントJAM-CODE-0001が発生した場合、計算ロジック"absolute_time"を用いて目的日時Pが算出される。この場合Aは600,1200,1800,3600,86400が与えられているので、この単位が秒であるとすれば、目的日時は、イベント発生日時の、10分前、20分前、30分前、1時間前、24時間前となる。したがって、その日時のスナップショットが管理システム106に送信される。

図11(b)は、ロジックIDが" print_count"の場合の計算ロジックである。ロジックIDが" print_count"の場合は、Tから、A枚前の印刷を実行した日時がPとなる。ステップS2211でデバイスカウンタデータDB1819を参照してイベント発生時の課金カウンタを取得する。ここで、イベント発生時の課金カウンタ数、すなわち合計の印刷枚数を取得することができる。特定した印刷枚数をtotal_pとする。ステップS2212で、デバイスカウンタデータDB1819を参照して目的課金カウンタ情報を検索する。ここで、目的課金カウンタ情報とは、total_p - A枚の印刷を実行した際の課金カウンタ情報である。課金カウンタ情報は時刻と関連付けて保存されている。ステップS2213で、S2212で特定した目的課金カウンタ情報の発生日時をPとして返却する。以上のように、ロジックIDが"print_count"の場合は、印刷回数にもとづいてセンサーデータを特定する。例えば図10のイベントJAM-CODE-0001が発生した場合、計算ロジック"print_coun"も用いて目的日時Pが算出される。この場合Aは100,200,500,1000,5000,10000が与えられているので、目的日時は、イベント発生日時から、それぞれの枚数を印刷する前の時点の日時となる。その日時のスナップショットが管理システム106に送信される。ただし、同一のイベントに係る他の計算ロジックと同じ日時が得られた場合には、その日時は目的日時から省いてもよい。

図11(c)は、ロジックIDが"revolution_count"の場合の計算ロジックである。ロジックIDが"revolution_count"の場合は、イベントが発生した時点から、ドラムロールの回転数がA回転前の日時が目的日時となる。ドラムロールとは、例えば電子写真方式のデバイスにおける感光体あるいは感光体ドラムであり、使用量に応じて消耗する。
ステップS2221でドラムロールの円周を取得する。これは、デバイス基本情報1815からパーツ情報を参照することで取得することができる。ここでドラムロールの円周をCとする。
ステップS2222で、１ページ印刷時の回転数を取得する。１ページ印刷するためには、１ページの長辺の長さをYとすると、Y/C回転が必要となる。
ステップS2223で、デバイスカウンタデータDB1819を参照してイベント発生時の課金カウンタを取得する。イベント発生時の課金カウンタ数、すなわち合計の印刷枚数を取得することができる。ここで特定した印刷枚数をtotal_pとする。すなわち感光体ドラムの回転数を用紙枚数に換算する。
ステップS2224で、デバイスカウンタデータDB1819を参照して目的課金カウンタ情報を検索する。ここで、目的課金カウンタ情報とは、A＝ (total_p - p) × Y / Cを満たすp枚目の印刷を実行したときの課金カウンタ情報である。
ステップS2225で、S2224で特定した目的課金カウンタ情報の発生日時をPとして返却する。なお、本実施形態ではドラム回転数がデバイス内に保存されていない場合の計算ロジックを示しているが、ドラム回転数が日時と関連付けて保存されているデバイスに関しては、単純にドラム回転数がAである日時をPとして返却すればよい。
例えば図10のイベントJAM-CODE-0001が発生した場合、計算ロジック"revolution_count"も用いて目的日時Pが算出される。この場合Aは100,200,500,1000が与えられているので、目的日時は、イベント発生日時から、感光体ドラムがそれぞれの回数だけ回転する以前の時点の日時となる。その日時のスナップショットが管理システム106に送信される。

本実施形態では、計算ロジックとして3例を挙げた。これら3例によれば、経過時間とイベント、印刷枚数とイベント、ドラム回転数とイベント、という3とおりの因果関係を分析することができる。しかし、計算ロジックはこれに限定されるものではない。例えば、あるイベントが生じた際に、他の特定のイベントがそれ以前に発生した回数を絶対値Aとして、その特定のイベントがA回前に発生した日時を目的日時とすることもできよう。これによりイベント間の因果関係を分析することができる。

以上のように、図10で示す条件データと、図11で説明した計算ロジックを組み合わせることで柔軟な条件でセンサーデータを管理システム106にアップロードさせることができる。管理システム106では、デバイスからアップロードされたセンサーデータとイベントとの関係を、例えば回帰分析によって特定することができる。その因果関係に基づいて、管理システム106では、発生するであろうイベントを、スケジュール系通信処理により得られたデバイス状態に基づいて予測することができる。なおこのデバイスから収集されるセンサーデータを教師データあるいはデバイスデータと呼ぶこともある。

以上のように、本実施形態においては、分析者が必要とするデバイスの状態データを、高い汎用性を保ちつつ、効率的に収集することを実現することができる。

［その他の実施例］
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウエア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

Claims (8)

1. ネットワークデバイスから収集した教師データの分析を行うシステムと通信するネットワークデバイスであって、
   前記ネットワークデバイスで検出されたデータの中から、前記システムに対して送信すべきデータを特定するための過去の複数タイミングを計算するために利用される、複数の異なるロジックをデータベースで管理する管理手段と、
   前記システムから、前記ネットワークデバイスで生じたイベントを特定するイベント情報と、前記ロジックを特定するロジック情報とを含む条件データを取得する取得手段と、
   前記ネットワークデバイスでイベントの発生が検出された場合、当該イベントに対応するイベント情報が含まれる条件データのロジック情報に基づき、前記データベースからロジックを特定する第１特定手段と、
   前記特定されたロジックに従い、前記ネットワークデバイスで検出されたデータの中から、前記システムに対して送信するデータを特定する第２特定手段と、
   前記特定されたデータを前記教師データとして前記システムに対して送信する送信手段と
   を有することを特徴とするネットワークデバイス。
2. 前記第２特定手段は、前記ロジックにより特定された時間情報と対応するデータを前記システムに対して送信すべき教師データとして特定することを特徴とする請求項１に記載のネットワークデバイス。
3. 前記ネットワークデバイスで検出されたデータは、前記ネットワークデバイスの複数のセンサーにより検出されたデータであり、該データは時間情報と対応したスナップショットとして前記ネットワークデバイスの記憶手段に記憶されることを特徴とする請求項１又は２に記載のネットワークデバイス。
4. 前記条件データは、所定のスケジュールに従う前記ネットワークデバイスからの要求に応じて、前記システムから取得されることを特徴とする請求項１乃至３のいずれか一項に記載のネットワークデバイス。
5. 前記条件データは、前記ネットワークデバイスで生じたイベントを特定する情報と、前記ロジックを特定する情報に加えて、遡る時間を示す情報とを含み、
   前記第２特定手段は、前記発生したイベントに対応するイベント情報が含まれる条件データのロジック情報に基づき、当該条件データで特定される時間を遡って時間情報を特定し、特定した時間情報に対応したデータを特定することを特徴とする請求項１乃至４のいずれか一項に記載のネットワークデバイス。
6. 前記ネットワークデバイスの複数のセンサーにより検出されたデータをスナップショットとして格納する手段を更に有することを特徴とする請求項１乃至５のいずれか一項に記載のネットワークデバイス。
7. ネットワークデバイスから収集した教師データの分析を行うシステムと通信するネットワークデバイスにおけるデータの特定方法であって、
   前記ネットワークデバイスで検出されたデータの中から、前記システムに対して送信すべきデータを特定するための過去の複数タイミングを計算するために利用される、複数の異なるロジックをデータベースで管理する管理工程と、
   前記システムから、前記ネットワークデバイスで生じたイベントを特定するイベント情報と、前記ロジックを特定するロジック情報とを含む条件データを取得する取得工程と、
   前記ネットワークデバイスでイベントの発生が検出された場合、当該イベントに対応するイベント情報が含まれる条件データのロジック情報に基づき、前記データベースからロジックを特定する第１特定工程と、
   前記特定されたロジックに従い、前記ネットワークデバイスで検出されたデータの中から、前記システムに対して送信するデータを特定する第２特定工程と、
   前記特定されたデータを前記教師データとして前記システムに対して送信する送信工程と
   を有することを特徴とするデータの特定方法。
8. 請求項１乃至６のいずれか一項に記載のネットワークデバイスとしてコンピュータを機能させるためのプログラム。

Images