JP7379041B2 - ネットワークデバイス、ネットワークデバイスの制御方法及びプログラム - Google Patents

Description

本発明は、ネットワークデバイス、ネットワークデバイスの制御方法及びプログラムに関する。

デバイスの状態に応じて、迅速な保守、故障や寿命の予兆予測、搭載機能の改善等を行うために、デバイスから送信された各種イベントログをサーバやクラウド上の各種サービスで取得して保存するシステムが知られている。サーバでは、蓄積されたイベントログとサーバ上のアプリケーションを利用し、デバイスの各種状態変化を分析したり、発生した事象に応じて迅速に消耗品の交換やメンテナンス作業の手配の通知をしたりなどの対応を行う。サーバにおいて迅速な処理を行うために、デバイスで発生した事象をサーバ側のアプリケーションが取り扱いやすい形式のイベントログにしてデバイスから送付する必要がある。

一方で、イベントログをサーバ側のアプリケーションが取り扱いやすい形式にすると、情報量が多くなりすぎて、デバイスの処理負荷やネットワークの通信負荷を増やしてしまう恐れがある。そのため、不必要な情報を送らない等により情報量を抑制して、デバイス側の処理負荷の低減をする必要がある。特許文献１は、装置内で発生した複数のエラーを１つの通知情報にまとめるエラー出力プログラムを開示している。

特開２０１２－０６４０４５号公報

しかしながら、特許文献１のプログラムでは、デバイスでのエラーを都度送付せずにまとめることで通信頻度やデータ量を抑制することはできるが、出力先での情報の取り扱いやすさを下げることになってしまう。そのため、サーバでの情報の取り扱いやすさを考慮しつつ、デバイスの処理負荷を下げることが求められる。

本発明は、デバイス内で検知したイベントをサーバ上のサービスで利用しやすい形式で送信しつつ、デバイスの処理負荷を低減することを目的とする。

上記課題を解決するために、本発明のネットワークデバイスは、イベントを検知する検知部を備えるネットワークデバイスであって、通知設定を管理する管理手段と、前記検知部で検知されたイベントが、前記通知設定に基づいて通知対象として決定された場合に、前記イベントに対応するメッセージを作成する第１の作成手段と、前記検知部で検知されたイベントに紐づく通知情報がある場合に、該通知情報の各内容について、前記通知設定に従い、通知対象か否かを判定する判定手段と、通知対象として決定された内容のそれぞれについて、メッセージを作成し、作成したメッセージに前記内容もしくは前記イベントに紐づく属性情報を付与する第２の作成手段と、作成されたメッセージを管理サーバに送信する送信手段と、を備える。前記属性情報は、イベントを一意に特定する情報を含み、
前記通知設定に従い前記検知されたイベントに紐づく通知情報に対応する複数の内容が前記通知対象として判定された場合、各内容のために作成される複数のメッセージのそれぞれには、前記属性情報の一部として、該イベントを一意に識別できる情報が付与される。

本発明によれば、デバイス内で検知したイベントをサーバ上のサービスで利用しやすい形式で送信しつつ、デバイスの処理負荷を低減することができる。

管理システム全体の構成を示す図である。 管理サーバの構成を説明する図である。 デバイスの構成を説明する図である。 デバイスの制御部の構成を説明する図である。 デバイス１２０のソフトウェアの構成を説明する図である。 イベントの送付処理を示すフローチャートである。 イベントの通知設定の設定処理を示すフローチャートである。 従属イベントがある場合のイベントの送付処理を示すフローチャートである。

図１は、本実施形態における管理システム全体の構成を示す図である。管理システムは、管理サーバ１１０を備え、ネットワーク１００を介して管理サーバ１１０に接続されているデバイス１２０（デバイス１２０ａおよびデバイス１２０ｂ）を管理する。ネットワーク１００は、例えば、インターネット等のＬＡＮ、ＷＡＮ、電話回線、専用デジタル回線、ケーブルテレビ回線、データ放送用無線回線等のいずれか、またはこれらの組み合わせにより実現される、いわゆる通信ネットワークである。

デバイス１２０は、機器内での事象を履歴イベントの形で管理サーバ１１０に対して通知する通信機能を備えたネットワークデバイスである。本実施形態では、デバイス１２０の一例として、例えばコピーやＦＡＸ等の複数種類の機能を実現する複合機を例に説明する。デバイス１２０は、管理サーバ１１０に対し、複合機としての機能を実行した履歴に加え、省電力状態への遷移や復帰の履歴、またエラー発生など異常状態への遷移・復帰などの履歴を管理サーバ１１０に通知する。なお、本実施形態では、デバイス１２０の一例として複合機について説明を行うが、これに限られるものではない。デバイス１２０は、エラー等のデバイス内のイベントを検知して、検知した情報を管理サーバ１１０に送信できる機能を有するものであればよい。

管理サーバ１１０は、デバイス１２０から通知されたイベントの情報を管理サーバ内のストレージに保存する。また管理サーバ１１０は、ストレージに蓄積された情報を利用して、デバイス１２０の稼働状況の分析などに利用される。なお、管理サーバ１１０は、サーバ装置の他、サーバ装置を含むデータセンターにより提供されたリソースを利用した仮想マシン（クラウドサービス）により実現されてもよいし、アプリケーションにより実現されてもよい。

図２は、管理サーバ１１０の構成を説明する図である。管理サーバ１１０は、例えば情報処理装置により実現され、制御部２００、操作部２０９、表示部２１０を備える。制御部２００は、ＣＰＵ２０１を備え、管理サーバ１１０全体を統括制御する。また、制御部２００は、ＲＯＭ２０２、ＲＡＭ２０３、ＨＤＤ２０４、操作部Ｉ／Ｆ２０５、表示部Ｉ／Ｆ２０６、通信Ｉ／Ｆ２０７を備える。これらは、システムバス２０８により互いに接続されている。

ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２０１は、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）２０２に格納されているブートプログラムによりＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）を起動する。また、ＣＰＵ２０１は、ＯＳ上で、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）２０４に格納されているアプリケーションプログラムを実行し、各種処理を実行する。ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２０３は、ＣＰＵ２０１の一時的な作業領域として利用される。ＨＤＤ２０４は、アプリケーションプログラム、アプリケーションの設定、デバイス１２０から受信した履歴等のデータを格納する。

操作部２０９は、ポインティングデバイス（例えば、マウス、タッチパッド、タッチパネル、トラックボールなど）、キーボード等を有し、ユーザからの操作を受け付ける。操作部Ｉ／Ｆ２０５は、操作部２０９とのインタフェースであり、操作部２０９によってユーザにより入力された情報をＣＰＵ２０１に送出する。表示部２１０は、ディスプレイを備え、ユーザに対して各種情報を表示する。表示部Ｉ／Ｆ２０６は、表示部２１０に表示すべきデータを表示部２１０に対して出力する。通信Ｉ／Ｆ２０７は、ネットワーク１００に接続され、ネットワーク１００を介してデバイス１２０との間で情報の入出力を行う。

図３は、デバイス１２０の構成を説明する図である。本実施形態におけるデバイス１２０は複合機であり、制御部３０１、プリンタ制御部３０２、スキャナ制御部３０３、プリンタ３０４、スキャナ３０５、操作部３０６を備える。制御部３０１は、デバイス１２０全体を統括制御する。制御部３０１は、操作部３０６、プリンタ制御部３０２、スキャナ制御部３０５に接続されている。制御部３０１の詳細については、図４を用いて後述する。

プリンタ部３０４は、受信した印刷ジョブに応じた画像を形成して用紙に出力したり、スキャナにセットされた原稿画像を光学的に読み取り用紙に出力したりする画像出力デバイスである。プリンタ部３０４は、プリンタ制御部３０２に接続され、プリンタ制御部３０２により制御される。スキャナ部３０５は、スキャナにセットされた原稿画像を光学的に読み取り、画像データを生成する画像入力デバイスである。スキャナ部３０５は、スキャナ制御部３０３に接続され、スキャナ制御部３０３により制御される。

操作部３０６は、ＬＣＤ（液晶表示装置）等の表示デバイスを有し、デバイス１２０に関する操作内容や各種設定等の情報を表示する。操作部３０６の表示デバイスは、タッチパネルとして操作が可能となっており、ユーザによる操作を受け付ける。また、操作部３０６はさらにユーザによる操作を受け付けるボタンボードを有していてもよい。

図４は、デバイス１２０の制御部３０１の構成を説明する図である。制御部３０１は、ＣＰＵ４０１を備え、デバイス１２０全体を統括制御する。また、制御部３０１は、ＲＯＭ４０２、ＲＡＭ４０３、ＨＤＤ４０４、通信Ｉ／Ｆ４０５、操作部Ｉ／Ｆ２０６、画像処理部４０７、プリンタＩ／Ｆ４０８、電源管理部４０９を備える。これらは、システムバス４１０を介して互いに接続されている。

ＣＰＵ４０１は、ＲＯＭ４０２に格納されているブートプログラムによりＯＳを起動する。また、ＣＰＵ２０１は、ＯＳ上で、ＨＤＤ４０４に格納されているアプリケーションプログラムを実行し、各種処理を実行する。ＲＡＭ４０３は、ＣＰＵ４０１の一時的な作業領域として利用され、さらに、画像データを一時記憶するための画像メモリ領域としても利用される。ＨＤＤ４０４は、アプリケーションプログラム、画像データ、各種設定値、デバイス１２０内の履歴等のデータを格納する。

操作部Ｉ／Ｆ４０６は、操作部３０６とのインタフェースであり、操作部３０６に表示すべき画像データを操作部３０６に対して出力する。また、操作部Ｉ／Ｆ４０６は、操作部３０６によってユーザにより入力された情報をＣＰＵ４０１に送出する。プリンタＩ／Ｆ４０８には、プリンタ制御部３０２およびスキャナ制御部３０３が接続され、画像データの同期系／非同期系の変換を行う。

通信Ｉ／Ｆ４０５は、ネットワーク１００に接続され、ネットワーク１００を介して管理サーバ１１０との間で情報の入出力を行う。画像処理部４０７は、プリンタ３０４への出力画像処理や、スキャナ３０５からの入力画像に対しての画像回転、画像圧縮、解像度変換、色空間変換、階調変換などの処理を行う。電源制御部４０９は、デバイス１２０全体の電源制御を行う。例えば、電源制御部４０９は、電源オンオフの制御の他、通常通電状態以外の省電力状態への移行や、通常状態への復帰などを制御する。

図５は、デバイス１２０のソフトウェアの構成を説明する図である。各部の機能は、ＲＡＭ４０３、ＨＤＤ４０４、ＲＯＭ４０２のいずれかの記憶手段に記憶されたプログラム等がＣＰＵ４０１により実行されることにより実現される。本実施形態においてデバイス１２０は複合機であり、デバイス１２０では、スキャン、プリントの他、ネットワークやメモリストレージを利用した各種機能性を実現するソフトウェアが動作する。

デバイス１２０は、ユーザインターフェース５０１、機能アプリケーション５０２、ジョブ制御部５０３、電源制御部５０４、エラー制御部５０５、履歴・設定保持部５０６、イベント回収部５１０を備える。また、デバイス１２０はさらに、メッセージバッファ５２０、イベント送付部５３０、ネットワーク通信部５３１、通知設定取得部５３１、通知設定取得部５３２、通知設定保持部５２１を備える。

ユーザインターフェース５０１は、操作部３０６に対してユーザが操作する画面を表示し、ユーザから受け付けた操作をＣＰＵ４０１に伝達するユーザインターフェース機能を提供する。機能アプリケーション５０２は、コピー、プリント、メール送信などの複合機の各種機能を提供するアプリケーションであり、デバイス１２０は複数のアプリケーションを有している。機能アプリケーション５０２は、操作部３０６を経由したユーザの指示や通信Ｉ／Ｆ４０５経由のデータ受信などをトリガーにして、複合機のアプリケーション機能を動作させる。

ジョブ制御部は、機能アプリケーション５０２からの指示を受けてプリンタ３０２やスキャナ３０３を制御し、スキャンやプリントを実行させる。電源制御部５０４は、デバイス１２０内のソフトウェアの状態と連動して電源管理部４０９を制御し、通常通電状態と省電力状態の遷移を制御する。

エラー制御部５０５は、ジョブ制御部５０３、プリンタ制御部３０２、スキャナ制御部３０３などデバイス１２０内で発生した異常状態の通知を受け、デバイス１２０全体や一部を停止する、縮退動作を指示するなどの制御を行う。

履歴・設定保持部５０６は、デバイス１２０内における情報を管理する。例えば、履歴・設定保持部５０６は、デバイス１２０やジョブの制御に必要な設定を保持する。また、履歴・設定保持部５０６は、ユーザの操作履歴、ジョブの実行結果、エラーの履歴、システムの不具合発生時に解析デバッグ用途で残すログ情報等を保持する。履歴・設定保持部５０６が保持するデータは、ハードとしてはＨＤＤ４０４に保存される。

イベント回収部５１０は、デバイス１２０内の各モジュール（ユーザインターフェース５０１～履歴・設定保持部５０６）の状態遷移を監視し、イベントを検知する。そして、イベント回収部５１０は、後述する通知設定に従って、検知したイベントが通知対象か否か判定する。その後、イベント回収部５１０は、デバイス１２０内の状態遷移を管理サーバ１１０に送付するため、通知対象のイベントを正規化し、メッセージバッファ５２０に保存する。正規化には、例えば、ＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ(登録商標) Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）などの汎用のフォーマットを使う。

イベント回収部５１０は、正規化の際に、イベント名称、発生時刻、情報処理装置のシリアル番号などの基本情報に加えて、イベントの種別によって追加でさまざまな属性情報が付与されたメッセージを生成する。属性情報は、イベント回収部５１０が、履歴・設定保持部５０６などの不揮発情報を参照したり、各モジュールの状態などから動的に取得したりすることで付与される。イベント回収部５１０によって正規化されたイベントは、メッセージとしてメッセージバッファ５２０に保存される。メッセージバッファ５２０は、ＨＤＤ４０４内にある不揮発領域にある。

イベント送付部５３０は、ネットワーク通信部５３１を介して管理サーバ１１０に対してデバイス１２０で発生したイベントを通知する。イベント送付部５３０は、例えば、メッセージバッファ５２０へのメッセージの書き込みを検知することでイベントが発行されたことを検知する。そして、イベント送付部５３０は、メッセージバッファ５２０からメッセージを読み出して、管理サーバ１１０に対して１以上のメッセージを送付することでイベントを通知する。ネットワーク通信部５３１は、Ｎｅｔｗｏｒｋ４０５を利用して管理サーバ１１０と通信する。

通知設定取得部５３２は、ネットワーク通信部５３１を介して管理サーバ１１０からイベントの通知設定を取得し、通知設定保持部５２１に保存する。通知設定取得部５３２および通知設定保持部５２１は、イベントの通知設定の管理手段として機能する。通知設定保持部５２１は、イベントの通知設定をＨＤＤ４０４上にファイルの形式で保存する。通知設定保持部５２１に保存されるイベントの通知設定は、デバイス１２０内で発生しイベント化することのできる事象のうちどのイベントをサーバ１１０に通知するかを示した内容である。イベント回収部５１０は、通知設定保持部５２１に保存されたイベントの通知設定に従い、検知したイベントの内、サーバ１１０に通知すべきと指定されたイベントのみを正規化してメッセージバッファ５２０に保存するよう動作する。

次に、通知設定保持部５２１に保存されるイベントの通知設定について説明する。表１は、通知設定とイベントの関係を表している。

表１の「Ｅｖｅｎｔ」は、複合機であるデバイス１２０上で発生するイベントの例であり、デバイス１２０内で起きた状態の遷移に対して名称を付けて正規化した単位である。つまりＥｖｅｎｔは、イベント回収部５３０がメッセージバッファ５２０に対して書き込む単位であり、管理サーバ１１０に送られる単位である。表１の「説明」は、各イベントの説明である。例えば、「ＪｏｂＳｔａｒｔｅｄ」はコピーやプリントなどのジョブが実行開始したことを意味するイベントであり、「ＥｒｒｏｒＯｃｃｕｒｒｅｄ」はデバイス１２０内で何らかの異常状態が発生したことを意味するイベントである。

表１のＣｏｌｌｅｃｔｉｏｎは、複数のイベントを動作の意味のまとまりでグループにした単位である。通知設定保持部５２１は、管理サーバ１１０へイベントを通知するか否かの通知設定がＣｏｌｌｅｃｔｉｏｎの単位でなされたＣｏｌｌｅｃｔｉｏｎファイルを保持している。例えば、ＡｌａｒｍのＣｏｌｌｅｃｔｉｏｎが通知対象として指定されると、イベントのＥｒｒｏｒＯｃｃｕｒｒｅｄとＡｌａｒｍＯｃｃｕｒｒｅｄが管理サーバ１１０に送付される通知対象になる。ＣｏｕｎｔｅｒのＣｏｌｌｅｃｉｔｏｎが指定されると、イベントのＣｏｕｎｔｅｒＳｎａｐｓｈｏｔｔｅｄとＰａｒｔｓＣｏｕｎｔｅｒＳｎａｐｓｈｏｔｔｅｄが管理サーバ１１０への通知対象になる。ＣｏｕｎｔｅｒＳｎａｐｓｈｏｔｔｅｄは課金用のカウンタ情報取得のイベント、ＰａｒｔｓＣｏｕｎｔｅｒＳｎａｐｓｈｏｔｔｅｄは部品の摩耗度のカウンタの情報取得のイベントである。なお、スナップショットイベントは、状態遷移をトリガーとするのではなくデバイス１２０の起動やタイマ等で定期的に送付されるイベントである。

図６は、デバイス１２０内で各種事象が起きた際の、管理サーバ１１０へのイベントの送付処理を示すフローチャートである。図６の各処理は、ＲＡＭ４０３、ＨＤＤ４０４、ＲＯＭ４０２のいずれかの記憶手段に記憶されたプログラムに基づいて、ＣＰＵ４０１により実行される。

以下では、デバイス１２０内で発生した事象としてエラー発生イベントを例に説明する。図６（Ａ）は、エラー発生イベントの管理サーバ１１０への送付処理を示すフローチャートである。ステップＳ６０１において、イベント回収部５１０は、デバイス１２０内でのイベントの発生を検知する。即ち、イベント回収部５１０は、イベントの検知部としても機能する。本実施形態においては、イベント回収部５１０はエラーの発生を検知し、ステップＳ６０２に進む。ステップＳ６０２において、イベント回収部５１０は、イベント発生時刻として現在時刻を取得しステップＳ６０３に進む。

ステップＳ６０３において、イベント回収部５１０は、ステップＳ６０１において検知したイベントが管理サーバ１１０への通知対象イベントであるか否かを、通知設定保持部５２１に保存された通知設定に従い判定する。具体的には、イベント回収部５１０は、通知設定保持部５２１に保存された通知設定の中で、エラーのイベントに対応したＣｏｌｌｅｃｔｉｏｎであるＡｌａｒｍが通知対象として設定されているか否かを判定する。イベント回収部５１０は、イベントが通知対象である場合、即ちＡｌａｒｍが通知対象として設定されている場合は、ステップＳ６０４に進む。一方、イベントが通知対象でない場合は、本処理を終了する。

ステップＳ６０４において、イベント回収部５１０は、イベント発行処理を行う。イベント回収部５１０は、イベント発行処理においてステップＳ６０１において検知したイベントと、ステップＳ６０４において取得した現在時刻を引数にしてイベント発行処理を実行することで管理サーバ１１０にイベントを送付する。本実施形態では、イベント回収部５１０は、エラー発生のイベントと現在時刻に基づいてイベント発行処理を実行する。イベント発行処理の詳細については、図６（Ｂ）を用いてその詳細を説明する。

図６（Ｂ）は、イベント発行処理を示すフローチャートである。
ステップＳ６１１において、イベント回収部５１０は、イベントの正規化処理を行い、管理サーバ１１０に送付するメッセージを生成する。具体的には、イベント回収部５１０は、まず検知したイベント内容に応じて、当該イベント種に予め紐づけられた属性情報をデバイス１２０内の各モジュールから収集する。属性情報は、管理サーバ１１０においてイベントの情報を利用する各種サービスでの利用が想定される情報であり、イベントごとに異なっている。例えば、エラー発生のイベントであれば、エラーコードやエラーが起きた部品の名称、エラー発生までに通紙したカウント値などが収集対象の属性情報となる。また例えば、コピージョブの完了イベントであれば、実行ユーザ名、カラーモノクロの区別、スキャン枚数、プリント枚数などが収集対象の属性情報となる。イベント回収部５１０は、イベントに応じて収集した属性情報とステップＳ６０２で取得した時刻情報に基づいて、正規化を行い、イベントに属性情報と時刻情報を付与したメッセージを作成する。正規化は、例えばＪＳＯＮのような汎用フォーマットで実行する。

ステップＳ６１２において、イベント回収部５１０は、ステップＳ６１２で生成されたメッセージをメッセージバッファ５２０に保存する。メッセージバッファ５２０に保存されるメッセージ（即ち、正規化されたイベント）は、管理サーバ１１０への通知対象と判定されたイベントのみであるため、この時点で管理サーバ１１０への送付内容が確定される。

ステップＳ６１３において、イベント送付部５３０は、ステップＳ６１２におけるメッセージバッファ５２０へのメッセージの書き込みを非同期に検知し、メッセージバッファ５２０からメッセージを読み出す。ステップＳ６１４において、イベント送付部５３０は、ステップＳ６１３で読み出したメッセージを管理サーバ１１０へ通知する。ステップＳ６１４の通知処理では、管理サーバ１１０への認証動作や通信エラー時のリトライ処理などを含めて送信完了までを実行する。デバイス１２０からメッセージを受信した管理サーバ１１０は、受信したイベントをストレージに保存する。以上説明したように、デバイス１２０内で発生した各種事象のうち通知対象となっているイベントは、管理サーバ１１０に送信され収集される。

図７は、イベントの通知設定の設定処理を示すフローチャートである。管理サーバ１１０における各処理は、ＲＡＭ２０３、ＨＤＤ２０４、ＲＯＭ２０２のいずれかの記憶手段に記憶されたプログラムに基づいて、ＣＰＵ４０１により実行される。デバイス１２０における各処理は、ＲＡＭ４０３、ＨＤＤ４０４、ＲＯＭ４０２のいずれかの記憶手段に記憶されたプログラムに基づいて、ＣＰＵ４０１により実行される。

本処理では、管理サーバ１１０と管理対象のデバイス１２０を接続し、デバイス１２０の通知設定保持部５２１にイベントの通知設定を設定する。デバイス１２０の通知設定保持部５２１が保持するＣｏｌｌｅｃｔｉｏｎファイルを更新することで、イベントの通知設定を更新することができる。Ｃｏｌｌｅｃｔｉｏｎファイルには、Ｃｏｌｌｅｃｔｉｏｎの単位で管理サーバ１１０へ通知を行うか否かの通知設定が記載されている。

図６のイベントの送信処理により管理サーバ１１０上に集まるデータは、管理サーバ１１０上に構築される各種のサービスやアプリケーションに利用される。サービスは、デバイス１２０毎に契約することになり、契約したサービスに応じてデバイス１２０から送信される必要のあるデータが異なる。そのため、サービスに応じてＣｏｌｌｅｃｔｉｏｎに記載する内容が異なる。例えば、ダッシュボードなどで運用中状況などのマクロな稼働状況の監視を行いたい場合は、表１のＣｏｕｎｔｅｒおよびＡｌａｒｍのＣｏｌｌｅｃｔｉｏｎを通知対象として設定する。また、消耗品の自動配送サービスであればＩｍｆｏｒｍａｔｉｏｎを、稼働監視・メンテナンスサービスであればＤｉａｇｎｏｓｉｓを通知対象として設定する。

図７のフローチャート７００は管理サーバ１１０のアプリケーションのデバイス１２０との接続フロー、その時のデバイス１２０のイベント送付部５３０の動作フローがフローチャート７５０である。

ステップＳ７０１において、管理サーバ１１０のアプリケーションは、これから接続されるクライアント装置の情報をデバイスシリアル番号や顧客情報などと共に登録する。ステップＳ７０２において、管理サーバ１１０のアプリケーションは、クライアントの契約内容に基づいて利用登録するサービスを決定する。ステップＳ７０３において、管理サーバ１１０のアプリケーションは、ステップＳ７０２において登録したサービスに応じて、デバイス１２０に設定するＣｏｌｌｅｃｔｉｏｎの内容を決定する。

クライアント装置であるデバイス１２０では、ステップＳ７５１において、ネットワーク通信部５３１が管理サーバ１１０への初期接続処理を行う。具体的には、ネットワーク通信部５３１は、ネットワーク設定を実施し、管理サーバ１１０のアドレスを入力するなどの手順でネットワーク１００を介した通信を実施し、管理サーバ１１０上のアプリケーションと通信を実施する。

デバイス１２０からの接続処理（ステップＳ７５１）を受けて、管理サーバ１１０では、ステップＳ７０４において、デバイス１２０の接続を確認する。接続が確立されると、以降はクライアントであるデバイス１２０と管理サーバ１１０間でデータのやり取りを実施する。

ステップＳ７０５において、管理サーバ１１０のアプリケーションは、ステップＳ７０３で決定したＣｏｌｌｅｃｔｉｏｎをデバイス１２０に送付する。ステップＳ７５２において、デバイス１２０の通知設定取得部５３２は、管理サーバ１１０から送付されたＣｏｌｌｅｃｔｉｏｎを受信する。

ステップＳ７５３において、デバイス１２０の通知設定取得部５３２は、受信したＣｏｌｌｅｃｔｉｏｎが既に保持しているＣｏｌｌｅｃｔｉｏｎから変更があるか否か判定する。即ち、管理サーバ１１０へ送付するイベントの通知設定に変更があるか否か判定する。Ｃｏｌｌｅｃｔｉｏｎに変更がある場合はステップＳ７５４に進む。一方、Ｃｏｌｌｅｃｔｉｏｎに変更がない場合は、ステップＳ７５５に進む。

ステップＳ７５４において、デバイス１２０の通知設定取得部５３２は、通知設定保持部５２１に保存されているＣｏｌｌｅｃｔｉｏｎファイルの内容を、ステップＳ７５２で受信した内容に基づいて書き換える。以降、ステップＳ７５５で一定時間待機した後、再度ステップＳ７５２に戻り、最新のＣｏｌｌｅｃｔｉｏｎを入手して必要があれば通知設定保持部５２１に反映させるという動作を継続する。

管理サーバ１１０側では、ステップＳ７０６で、顧客の契約内容が変更になるなどして登録サービスの内容に変更があったか否か判定する。登録サービスの内容に変更があった場合はステップＳ７０７に進む。一方、登録サービスの内容に変更がなかった場合は、ステップＳ７０６の処理を定期的に繰り返す。ステップＳ７０７において、管理サーバ１１０は、変更があった登録サービスの内容に応じて、該サービスに対応するようＣｏｌｌｅｃｔｉｏｎを変更する。その後、ステップＳ７０５ってデバイス１２０と通信し、最新のＣｏｌｌｅｃｔｉｏｎをデバイス１２０に反映させる処理を行う。

以上説明したように、本実施形態では顧客の契約するサービス内容に応じてデバイス１２０が管理するイベントの通知設定を変更する。通知設定が反映された以降は、デバイス１２０内で図６のフローが動作するたびに、管理サーバ１１０に対してデバイス１２０内の発生事象（状態変化）を通知設定に応じて通知するようになる。

次に、表２を用いてイベント回収部５１０が１つの発生事象（主イベントともいう）に対する従属イベントをメッセージバッファ５２０に書き込む処理について説明する。表２は、発生事象と従属イベントの関係を説明する表である。従属イベントは、イベント回収部５１０が検知する発生事象である主イベントに紐づく通知情報である。従属イベントは、主イベントと共に管理サーバ１１０に送信されることもあれば、従属イベントのみで管理サーバ１１０に送信されることもある。

図５で説明した通り、デバイス１２０内の状態遷移をイベント回収部５１０が検知し、必要な情報を回収してメッセージバッファ５２０にイベントの形で書き込む。イベント回収部５１０が検知した状態遷移があらかじめイベント回収部５１０内に定義された特定の状態遷移の場合には、表２にしたがって主イベントと同じ時刻情報でメッセージバッファ５２０に複数の従属イベントを書き込む。

例えば、複合機であるデバイス１２０では、トナーがあらかじめ設定された残量を下回ったタイミングで履歴設定保持部５０６が寿命到達に対応するアラームコードの記録を通知する状態になる。この際、イベント回収部５１０はアラームの発生を通知するＡｌａｒｍＯｃｃｕｒｅｄイベントを検知し、メッセージバッファ５２０に書き込む。さらに、イベント回収部５１０は表２にしたがって同じ時刻情報で、トナーの寿命が閾値到達したことを通知するＬｉｆｅＰｒｅｄｉｃｔｉｏｎＴｈｒｅｄｈｏｌｄＲｅａｃｈｅｄイベントについても書き込む。ＬｉｆｅＰｒｅｄｉｃｔｉｏｎＴｈｒｅｄｈｏｌｄＲｅａｃｈｅｄイベントは、ＡｌａｒｍＯｃｃｕｒｅｄイベントに付随する従属イベントである。これにより、デバイス１２０内でアラームが発生した状況とその詳細としてトナー残量が閾値到達した状況とを別のイベントとして管理サーバ１１０に通知することができる。

また、ユーザやサービスマンが複合機であるデバイス１２０のトナーボトル交換作業を完了すると、履歴設定保持部５０６が部品の交換完了に対応するアラームコードの記録を通知する状態になる。この際、イベント回収部５１０はアラームの発生を通知するＡｌａｒｍＯｃｃｕｒｅｄイベントを検知し、メッセージバッファ５２０に書き込む。さらに、イベント回収部５１０は表２にしたがって同じ時刻情報で、ＬｉｆｅＰｒｅｄｉｃｔｉｏｎＩｎｉｔｉａｌｉｚｅｄイベントなど４つの従属イベントについても書き込む。なお、ＬｉｆｅＰｒｅｄｉｃｔｉｏｎＩｎｉｔｉａｌｉｚｅｄは、寿命情報の初期化通知であり、ＬｉｆｅＰｒｅｄｉｃｔｉｏｎＤｉｓｃｏｎｔｉｎｕｅｄは、交換されたトナーボトルの最終寿命情報の通知である。また、ＴｏｎｎｅｒＢｏｔｔｌｅＩｎｓｔａｌｌｅｄは、新しいトナーボトルの検知イベントであり、ＴｏｎｎｅｒＢｏｔｔｌｅＲｅｍｏｖｅｄは、古いトナーボトルが外されたことを検知イベントである。

このように１つの発生事象に紐づく複数の通知情報をそれぞれ意味の異なる別のイベントとして定義した上で、それぞれに異なる属性を付与して通知することで、管理サーバ１１０において情報の検索や利用が容易になる。

図８は、１つの発生事象（主イベント）に対して従属イベントがある場合のイベントの送付処理を示すフローチャートである。図８の各処理は、ＲＡＭ４０３、ＨＤＤ４０４、ＲＯＭ４０２のいずれかの記憶手段に記憶され、ＣＰＵ４０１により実行される。

ステップＳ８０１で、イベント回収部５１０はデバイス１２０の状態遷移（イベントの発生）を検知する。以下では一例として、イベント回収部５１０がトナーボトルの交換完了のアラーム（ＡｌａｒｍＯｃｃｕｒｅｄイベント）を検知した場合について説明する。ステップＳ８０２で、イベント回収部５１０は現在の時刻情報を取得する。以下では、イベント回収部５１０が検知したイベントを主イベントとも言う。

ステップＳ８０３で、イベント回収部５１０は、ステップＳ８０１において検知したイベント（主イベント）が管理サーバ１１０への通知対象イベントであるか否かを、通知設定保持部５２１に保存された通知設定に従い判定する。具体的には、イベント回収部５１０は、通知設定保持部５２１に保存された通知設定の中で、ＡｌａｒｍＯｃｃｕｒｅｄイベントに対応したＣｏｌｌｅｃｔｉｏｎであるＡｌａｒｍが通知対象として設定されているか否かを判定する。イベント回収部５１０は、イベントが通知対象である場合、即ちＡｌａｒｍが通知対象として設定されている場合は、ステップＳ８０４に進む。一方、イベントが通知対象でない場合は、イベントは発行せずステップＳ８０５に進む。

ステップＳ８０４で、イベント回収部５１０は、イベント発行のサブルーチン（図６（Ｂ））を呼び出し、アラーム発生イベントを管理サーバ１１０に送出してステップＳ８０５へ進む。

ステップＳ８０５で、イベント回収部５１０は、ステップＳ８０１において検知したイベント（ＡｌａｒｍＯｃｃｕｒｅｄイベント）に付随して通知すべき従属イベントがあるか否か判定する。具体的には、イベント回収部５１０が表２のような論理をプログラムとして実現したり、テーブルとして定義して読み込んだりするなどの形で実現する。従属イベントがある場合は、ステップＳ８０６に進む。一方、従属イベントがない場合は、処理を終了する。

ステップＳ８０６で、イベント回収部５１０はＮ＝１とする。Ｎは、イベントの送付処理を実行する従属イベントの数である。複数の従属イベントがある場合は、従属イベントとして送付すべきイベントの数だけステップＳ８０７からステップＳ８１１を繰り返し、１つ１つの従属イベントについて管理サーバ１１０に通知を行うか否か判定する。ステップＳ８０６とステップＳ８１０は繰り返しの為の手続きである。

ステップＳ８０７で、イベント回収部５１０は、従属イベントの内、通知対象か否か判定する対象となる従属イベントを決定する。ステップＳ８０８で、イベント回収部５１０は、ステップＳ８０７において対象イベントとして決定した従属イベントが管理サーバ１１０への通知対象イベントであるか否かを、通知設定保持部５２１に保存された通知設定に従い判定する。具体的には、イベント回収部５１０は、通知設定保持部５２１に保存された通知設定の中で、従属イベントに対応したＣｏｌｌｅｃｔｉｏｎが通知対象として設定されているか否かを判定する。イベント回収部５１０は、従属イベントが通知対象である場合は、ステップＳ８０９に進む。一方、従属イベントが通知対象でない場合は、イベントは発行せずステップＳ８１０に進む。

ステップＳ８０９で、イベント回収部５１０は、イベント発行のサブルーチン（図６（Ｂ））を呼び出し、１以上の従属イベントを管理サーバ１１０に送出してステップＳ８１０へ進む。従属イベントが呼び出すイベント発行のサブルーチン（図６（Ｂ））において主イベントが発行済みの場合には、主イベントに付与されている一意のＩＤなど主イベントを識別できる識別情報をステップＳ６１１の属性情報の１つとして従属イベントに付与する。これにより関連するイベントであることを管理サーバ１１０側で追跡することが可能になる。

なお、主イベントは通知せず従属イベントのみ通知する場合（ステップＳ８０３がＮｏかつステップＳ８０８がＹｅｓの場合）がある。例えば、トナーボトルを交換した場合に、アラームの発生を知らせるＡｌａｒｍＯｃｃｕｒｅｄイベントは通知せず、トナーボトルの交換という具体的なイベントを表す従属イベントのみ通知する場合である。なお、トナーボトルの交換を表す具体的なイベントとしては、ＴｏｎｎｅｒＢｏｔｔｌｅＩｎｓｔａｌｌｅｄ（新しいトナーボトルの検知イベント）等のイベントがある。通知設定において、ＣｏｌｌｅｃｔｉｏｎのＡｌａｒｍが通知対象外でＩｎｆｏｒｍａｔｉｏｎが通知対象になっている場合には、ＡｌａｒｍＯｃｃｕｒｅｄイベントは通知せず、ＴｏｎｎｅｒＢｏｔｔｌｅＩｎｓｔａｌｌｅｄイベントは通知することとなる。主イベントを通知せず従属イベントのみ通知することで、管理サーバ１１０が必要としている情報のみを通知することが可能となる。従属イベントのみ通知する場合は、管理サーバ１１０側で主イベントと従属イベントを紐づけて管理する必要がないため、従属イベントの属性情報に主イベントの識別情報を付与する必要はない。

ステップＳ８１０で、イベント回収部５１０は、Ｎに１を加算する。ステップＳ８１１で、イベント回収部５１０は、全ての従属イベントについて通知対象か否かの判定が終了したかを判定する。具体的には、Ｎが全ての従属イベントの数より大きい場合は、全ての従属イベントについて判定が終了したと判定する。全ての従属イベントについて判定が終了している場合は、本処理を終了する。一方、全ての従属イベントについて判定が終了していない場合は、ステップＳ８０７に戻る。

以上のように、本実施形態によれば、管理サーバ１１０上の各種サービスが解釈や分析がしやすい詳細化された情報をデバイス１２０から管理サーバ１１０へ送付できる。また、必要な情報のみを選択して送付するため、通信するデータ量とデバイス１２０および管理サーバ１１０の処理負荷を軽減することができる。

（その他の実施例）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

以上、本発明の好ましい実施形態について説明したが、本発明は、これらの実施形態に限定されず、その要旨の範囲内で種々の変形および変更が可能である。

Claims (7)

1. イベントを検知する検知部を備えるネットワークデバイスであって、
   通知設定を管理する管理手段と、
   前記検知部で検知されたイベントが、前記通知設定に基づいて通知対象として決定された場合に、前記イベントに対応するメッセージを作成する第１の作成手段と、
   前記検知部で検知されたイベントに紐づく通知情報がある場合に、該通知情報の各内容について、前記通知設定に従い、通知対象か否かを判定する判定手段と、
   通知対象として決定された内容のそれぞれについてメッセージを作成し、作成したメッセージに前記内容もしくは前記イベントに紐づく属性情報を付与する第２の作成手段と、
   作成されたメッセージを管理サーバに送信する送信手段と、を備え、
   前記属性情報は、イベントを一意に特定する情報を含み、
   前記通知設定に従い前記検知されたイベントに紐づく通知情報に対応する複数の内容が前記通知対象として判定された場合、各内容のために作成される複数のメッセージのそれぞれには、前記属性情報の一部として、該イベントを一意に識別できる情報が付与されることを特徴とするネットワークデバイス。
2. 前記判定手段が前記イベントが通知対象でないと判定した場合、前記第１の作成手段は前記イベントについてメッセージの作成を行わないことを特徴とする請求項１に記載のネットワークデバイス。
3. 前記管理手段は、前記管理サーバで利用されるサービスの変更に応じて前記通知設定を更新することを特徴とする請求項１または２に記載のネットワークデバイス。
4. 前記管理手段は、前記通知設定において、１つ以上の前記イベントまたは前記通知情報の内容のグループごとに通知対象か否かを管理することを特徴とする請求項１乃至３のいずれか１項に記載のネットワークデバイス。
5. 前記管理手段は、前記管理サーバで利用されるサービスの変更に伴い通知対象となる前記グループに変更があった場合に、前記通知設定を更新することを特徴とする請求項４に記載のネットワークデバイス。
6. イベントを検知する検知部を備えるネットワークデバイスの制御方法であって、
   通知設定を管理する管理工程と、
   前記検知部で検知されたイベントが、前記通知設定に基づいて通知対象として決定された場合に、前記イベントに対応するメッセージを作成する工程と、
   前記検知部で検知されたイベントに紐づく通知情報がある場合に、該通知情報の各内容について、前記通知設定に従い、通知対象か否かを判定する判定工程と、
   通知対象として決定された内容のそれぞれについてメッセージを作成し、作成したメッセージに前記内容もしくは前記イベントに紐づく属性情報を付与する工程と、
   作成されたメッセージを管理サーバに送信する送信工程と、を有し、
   前記属性情報は、イベントを一意に特定する情報を含み、
   前記通知設定に従い前記検知されたイベントに紐づく通知情報に対応する複数の内容が前記通知対象として判定された場合、各内容のために作成される複数のメッセージのそれぞれには、前記属性情報の一部として、該イベントを一意に識別できる情報が付与されることを特徴とする制御方法。
7. 請求項１乃至５のいずれか１項に記載のネットワークデバイスの各手段としてコンピュータを機能させるためのプログラム。

Images