(57)【要約】      （修正有）【課題】管理サーバなどの外部システム側から収集するイベント情報のログの収集種別を、機器内で動作するモジュール毎に動作するイベント収集モジュールとは異なる単位で切り替えることが可能となるネットワーククライアント及びその制御方法を提供する。【解決手段】管理サーバ側で設定した収集種別と、クライアント内のイベント収集モジュールの対応テーブルと、管理サーバ側で設定した収集種別と、クライアント内のイベント種別の対応テーブルを持ち、管理サーバ側から要求された収集種別の単位でイベントログの出力を切り替える。【選択図】図７Ａ
2020086696.tif 000002
【特許請求の範囲】
【請求項１】
検出されたイベント情報のログを収集する複数の収集手段を有するネットワーククライアントであって、
収集種別と前記複数の収集手段の少なくともいずれかとの対応関係を示す第１テーブルを管理する設定手段を有し、
前記各収集手段は、収集種別とイベントの種別との対応関係を示す第２テーブルを管理し、
前記設定手段は、外部システムから、収集種別と取得トリガとが指定されたイベント収集要求を受信した場合に、前記第１テーブルを参照して、該イベント収集要求に含まれる収集種別に対応する１以上の収集手段を特定し、当該特定された１以上の収集手段に対して、収集種別と取得トリガとに基づくイベント情報の収集を指示し、
前記各収集手段は、前記第２テーブルを参照して、前記設定手段による指示に含まれる収集種別に対応するイベントの種別のイベント情報を、該指示に含まれ取得トリガに従い収集するための有効化処理を実行し、該有効化処理の実行結果を前記設定手段に通知し、
前記設定手段は、前記外部システムに対して、前記有効化処理に成功した収集種別の反映結果を送信し、
前記有効化処理が行われた後に、前記収集手段で収集されたイベント情報のログがネットワークを介して送信されることを特徴とするネットワーククライアント。
【請求項２】
前記有効化処理が行われた後に、各収集手段で収集されたイベント情報のログは、ネットワークを介して、前記外部システムとは異なるシステムに送信されることを特徴とする請求項１に記載のネットワーククライアント。
【請求項３】
前記設定手段は、前記各収集手段からの通知の基づいて、前記収集種別に対応するすべてのイベントの種別のイベント情報を収集するための前記有効化処理が実行されたことに基づいて、前記外部システムに対して、前記有効化処理に成功した収集種別の反映結果を送信することを特徴とする請求項１又は２に記載のネットワーククライアント。
【請求項４】
前記収集種別に対応するすべてのイベントの種別のイベント情報の収集を停止する前記有効化処理が実行されたことに基づいて、前記設定手段が、前記外部システムに対して、前記有効化処理に成功した収集種別の反映結果を送信することを特徴とする請求項１又は２に記載のネットワーククライアント。
【請求項５】
前記イベントの種別のイベント情報の収集を停止することができなかった場合は、前記外部システムは、イベント収集要求設定のリトライを実行する、又はネットワーククライアントからのイベント情報のログを受け付けないことを特徴とする請求項４に記載のネットワーククライアント。
【請求項６】
前記第２テーブルは、収集種別とイベントの種別とが、多対１対応であることを特徴とする請求項１〜５の何れか１項に記載のネットワーククライアント。
【請求項７】
１つのイベント種別に複数の収集種別が対応し、該イベント情報のログを取得する時間間隔が収集種別毎に設定されている場合は、各時間間隔の倍数ごとにイベント情報のログの収集を行うことを特徴とする請求項６に記載のネットワーククライアント。
【請求項８】
収集種別と前記複数の収集手段の少なくともいずれかとの対応関係を示す第１テーブルを管理する設定手段と、
検出されたイベント情報のログを収集し、収集種別とイベントの種別との対応関係を示す第２テーブルを管理する複数の収集手段と、
を有するネットワーククライアントの制御方法であって、
前記設定手段が、
外部システムから、収集種別と取得トリガとが指定されたイベント収集要求を受信した場合に、前記第１テーブルを参照して、該イベント収集要求に含まれる収集種別に対応する１以上の収集手段を特定する特定工程と、
当該特定された１以上の収集手段に対して、収集種別と取得トリガとに基づくイベント情報の収集を指示する指示工程と、
前記収集手段が、
前記第２テーブルを参照して、前記設定手段による指示に含まれる収集種別に対応するイベントの種別のイベント情報を、該指示に含まれ取得トリガに従い収集するための有効化処理を実行する実行工程と、
該有効化処理の実行結果を前記設定手段に通知する通知工程と、
前記設定手段が、
前記外部システムに対して、前記有効化処理に成功した収集種別の反映結果を送信する第１の送信工程とを有し、
さらに、前記有効化処理が行われた後に、前記収集手段で収集されたイベント情報のログをネットワークを介して送信する第２の送信工程を、
有することを特徴とするネットワーククライアントの制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーククライアント及びその制御方法に関する。
【背景技術】
【０００２】
近年、装置の状態を監視し、迅速な修理や適切な保守、故障等の予兆予測、装置搭載機能の改善等を行う必要性を増してきている。このために稼働している装置からインターネットを通じてログ管理サーバに各種ログを送信し、サーバ側でログを分析してフィードバックするシステムが知られている。こういったシステムでは、管理サーバは、収集したログを分析し、その結果をもとに保守を行ったり、顧客にフィードバッグをしたりする様々なサービスを提供する。
管理サーバにログを送信する装置は顧客の環境で動作しており、ログの種別によっては顧客の個人情報等も含まれる場合もあることから、どの種別のログを収集してもよいか、顧客に合意をしてもらう必要がある。この合意は顧客に提供するサービス毎に行う必要があるため、提供するサービスに応じて、装置で取得するログを切り替える必要がある。
特許文献1に記載のシステムでは、携帯端末においてアプリケーションで発生するエラー毎にログ取得を設定する技術が記載されている。
一方で、各ログの元となる情報は、ログの送信・フィードバックを行うシステムが導入される以前から装置に搭載されているレガシーシステムのモジュール毎に別々のインタフェースを介して別々の形式で出力されている。これらのレガシーモジュール毎に別々のイベント収集モジュールを用意し、ログを整形して出力している。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開2011-118610号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
装置内の既存モジュール毎に作成したイベント収集モジュールの単位でのログ出力の切り替えでは、管理サーバで新たに追加されるサービスに必要なログの単位での切り替えに対応することができない。そのため、管理サーバ側から、機器内で動作するモジュールとは異なる単位で、収集できるログを切り替えるシステムが必要である。
特許文献1では、アプリケーションで発生するエラー毎に取得するログを切り替えており、機器内で動作するモジュール単位での切り替えを行っており、この課題を解決することができない。
本発明は、管理サーバなどの外部システム側から収集するイベント情報のログの収集種別を、機器内で動作するモジュール毎に動作するイベント収集モジュールとは異なる単位で切り替えることが可能となることを目的とする。
【課題を解決するための手段】
【０００５】
本発明は、検出されたイベント情報のログを収集する複数の収集手段を有するネットワーククライアントであって、収集種別と前記複数の収集手段の少なくともいずれかとの対応関係を示す第１テーブルを管理する設定手段を有し、各収集手段は、収集種別とイベントの種別との対応関係を示す第２テーブルを管理し、前記設定手段は、外部システムから、収集種別と取得トリガとが指定されたイベント収集要求を受信した場合に、前記第１テーブルを参照して、該イベント収集要求に含まれる収集種別に対応する１以上の収集手段を特定し、当該特定された１以上の収集手段に対して、収集種別と取得トリガとに基づくイベント情報の収集を指示し、前記収集手段は、前記第２テーブルを参照して、前記設定手段による指示に含まれる収集種別に対応するイベントの種別のイベント情報を、該指示に含まれ取得トリガに従い収集するための有効化処理を実行し、該有効化処理の実行結果を前記設定手段に通知し、前記設定手段は、前記外部システムに対して、前記有効化処理に成功した収集種別の示す応答を送信し、前記有効化処理が行われた後に、前記収集手段で収集されたイベント情報のログがネットワークを介して送信されることを特徴とする。
【発明の効果】
【０００６】
本発明によれば、管理サーバなどの外部システム側から収集するイベント情報のログの収集種別を、機器内で動作するモジュール毎に動作するイベント収集モジュールとは異なる単位で切り替えることが可能となる。
【図面の簡単な説明】
【０００７】
【図１】システム全体を示すシステム構成図
【図２】管理サーバの構成を表すブロック図
【図３】ネットワーククライアントの全体構成を表すブロック図
【図４】情報処理コントローラユニットの構成を表すブロック図
【図５】ネットワーククライアントのソフトウェアブロック図
【図６】イベント発生の検出から管理サーバへの送付までのフローチャート
【図７Ａ】イベント収集設定処理のフローチャート
【図７Ｂ】イベント収集設定処理のフローチャート
【図７Ｃ】イベント収集設定処理のフローチャート
【図８】イベント収集要求設定ファイルの一例
【図９】イベント収集設定部の収集要求の反映結果の通知処理のフローチャート
【図１０】管理サーバのソフトウェアブロック図
【図１１Ａ】他の実施例におけるイベント収集要求受付時のフローチャート
【図１１Ｂ】他の実施例におけるイベント収集要求受付時のフローチャート
【図１２】他の実施例におけるイベント収集要求設定ファイルの一例
【発明を実施するための形態】
【０００８】
以下、本発明を実施するための形態について図面を用いて説明する。
【実施例１】
【０００９】
図１は、本発明におけるシステム全体を示すシステム構成図である。ネットワーク100には、本実施例で説明する外部システムである管理サーバ110、およびネットワーククライアント120、操作端末130が接続されている。
ネットワーククライアント120は機器内でのイベントを履歴イベントの形で管理サーバ110に対して通知する通信機能を具備している。また、管理サーバ110は複数のネットワーククライアント120から通知されたイベントを管理サーバ内のストレージに保存する機能性を具備している。ストレージに蓄積された情報は稼働監視情報の分析などに利用される。
本実施例では管理サーバ110についてはデータストレージと情報処理計算とネットワーク通信機能性を具備できるコンピュータなどの一般的な情報処理装置や、同等機能を持つクラウドサービスで実現する。
ネットワーククライアント120としては複数種類の機能、例えばコピーやFAX等を実現する複合機を例に説明する。それらの機能の実行した履歴に加え、省電力状態への遷移や復帰の履歴、またエラー発生など異常状態への遷移・復帰などの履歴などを管理サーバ110に通知する機能を具備している。
管理サーバ110はウェブアプリケーションを搭載し、ネットワーク100を介して操作端末130からウェブブラウザ等でアクセスすることで管理サーバ110の設定を変更したりすることができる。
【００１０】
図２は、本発明における管理サーバ110が一般的なコンピュータなどの情報処理装置で実現された場合の構成を表すブロック図である。コントローラユニット200、操作部209、表示部210を含んでいる。コントローラユニット200は、ＣＰＵ(Central Processing Unit)201を有する。ＣＰＵ201は、ＲＯＭ(Read Only Memory)202に格納されているブートプログラムによりＯＳ(Operating System)を起動する。
ＣＰＵ201は、このＯＳ上で、ＨDＤ(Hard Disk Drive)204に格納されているアプリケーションプログラムを実行し、これによって各種処理を実行する。このＣＰＵ201の作業領域としてはＲＡＭ(Random Access Memory)203が用いられる。
ＨＤＤ204は、上記アプリケーションプログラムと設定や履歴等のデータを格納する。
ＣＰＵ201には、システムバス208を介して、ＲＯＭ202およびＲＡＭ203とともに、操作部Ｉ/Ｆ205、表示部Ｉ/Ｆ206、Network 207が接続される。操作部Ｉ/Ｆ205は、マウス、キーボード等から成る操作部209とのインタフェースであり、操作部209によってユーザにより入力された情報をＣＰＵ201に送出する。表示部Ｉ/Ｆ206は、ディスプレイ等から成る表示部210に表示すべき画像データを表示部210に対して出力する。また、Network 207は、ネットワーク100に接続され、ネットワーク100を介してネットワーク100上の各装置との間で情報の入出力を行う。
【００１１】
図３は本発明におけるネットワーククライアント120の構成を表すブロック図である。ネットワーククライアント120は、情報処理コントローラユニット301、プリンタコントローラユニット302、スキャナコントローラユニット303、プリンタ304、スキャナ305、操作部306を含んでいる複合機である。情報処理コントローラユニット301は、ネットワーククライアント120の動作に係る情報処理制御を統括するコントローラであり、操作部306が接続される。情報処理コントローラユニット301には、さらに画像出力デバイスであるプリンタ304を制御するプリンタコントローラユニット302や画像入力デバイスであるスキャナ305を制御するスキャナコントローラユニット303が接続される。
【００１２】
図４は本発明におけるネットワーククライアント120の情報処理コントローラユニット301の構成を表すブロック図である。情報処理コントローラユニット301は、ＣＰＵ401を有し、ＣＰＵ401は、ＲＯＭ402に格納されているブートプログラムによりＯＳを起動する。
ＣＰＵ401は、このＯＳ上で、ＨＤＤ404に格納されているアプリケーションプログラムを実行し、これによって各種処理を実行する。このＣＰＵ401の作業領域としてはＲＡＭ403が用いられる。
ＲＡＭ403は、作業領域を提供するとともに、画像データを一時記憶するための画像メモリ領域を提供する。
ＨＤＤ404は、上記アプリケーションプログラムや画像データ、各種設定値や履歴を格納する。
ＣＰＵ401には、システムバス410を介して、ＲＯＭ402およびＲＡＭ403とともに、操作部Ｉ/Ｆ406、デバイスコントローラＩ/Ｆ408、Network 405、画像処理部407、および電源制御部409が接続される。
操作部Ｉ/Ｆ406は、タッチパネルを有する操作部306とのインタフェースであり、操作部306に表示すべき画像データを操作部306に対して出力する。また、操作部Ｉ/Ｆ406は、操作部306によってユーザにより入力された情報をＣＰＵ401に送出する。
デバイスコントローラＩ/Ｆ408には、スキャナコントローラユニット303およびプリンタコントローラユニット302が接続され、デバイスコントローラＩ/Ｆ408は、画像データの同期系/非同期系の変換を行う。
Network 405は、ネットワーク100に接続され、ネットワーク100を介してネットワーク100上の各装置との間で情報の入出力を行う。
画像処理部407では、プリンタ304への出力画像処理やスキャナ305からの入力画像処理、画像回転、画像圧縮、解像度変換、色空間変換、階調変換などの処理を行う。電源制御部409は機器全体の電源制御を行う、電源オンオフの制御の他通常通電状態以外の省電力状態への移行や、通常状態への復帰などを制御する。
【００１３】
図５は本発明におけるネットワーククライアント120のソフトウェアブロック図である。本明細書では、これらの各ソフトウェアがＲＡＭ403、ＨＤＤ404、ＲＯＭ402のいずれかの記憶手段に記憶され、ＣＰＵ401がソフトウェアを実行することにより、各機能が実現される。ネットワーククライアント120は複合機であり、スキャン、プリント、及びネットワークやメモリストレージを利用した各種機能性を実現するソフトウェアが動作する。
ユーザインターフェース501は操作部306に対してユーザが操作する画面を表示したり、ユーザが操作した際にその動きをソフトウェアに伝えたりする機能を持つ。
機能アプリケーション502はコピー、プリント、メール送信など機器内に複数あり、操作部306を経由したユーザの指示やNetwork 405経由のデータ受信などをトリガにして複合機のアプリケーション機能を動作させる。
ジョブ制御部503は機能アプリケーション502からの指示を受けてプリンタコントロールユニット302やスキャナコントロールユニット303を制御してスキャンやプリントを実行する。
電源制御部504は、装置内のソフトウェアの状態と連動して、電源管理部409を制御し通常通電状態と省電力状態の遷移を司る。
エラー制御部505は、主にジョブ制御部503やプリンタコントロールユニット302やスキャナコントローラユニット303などで発生した異常状態の通知を受け、システム全体を停止したり縮退動作を指示したりの制御を実施する。
履歴・設定保持部506は機器内における不揮発情報を管理する。複合機やジョブの制御に必要な設定を保持したり、ユーザの操作履歴やジョブ実行結果およびエラーの発生などをサマライズして保存したりする。またシステムの不具合発生時に解析デバッグ用途で残すログ情報もここに保存される。不揮発情報の実体はＨＤＤ404に保持される。
イベント回収部510は、ユーザ操作イベント収集モジュール511、ジョブイベント収集モジュール512、機器状態収集モジュール513の３つのイベント収集モジュールを備えている。また、それぞれのデータとしてイベント収集種別対応テーブル(521〜523)も備えている。
各イベント収集モジュール(511〜513)は、機器内各モジュール(501〜506)で状態遷移により発生する情報を管理サーバ110に送付するため、イベントの形で正規化しメッセージバッファ530に保存する機能性を持つ。メッセージバッファ530はＨＤＤ404上にあり正規化されたイベントは不揮発領域に保存される。ここでの正規化はJSONやXML，CSV，YAMLなどの汎用のフォーマットを使う。イベント名称、発生時刻、情報処理装置のシリアル番号などの基本情報に加えてイベントの種別によって、追加でさまざまな情報が付与される。これら付与情報はイベント回収部510が履歴・設定保持部506などの不揮発情報を参照したり、機器内各モジュール(501〜506)の状態などから動的に取得したりする。具体的な動作を以下で説明する。
【００１４】
ユーザ操作イベント収集モジュール511はユーザインターフェース501からユーザが行った操作の情報を取得する。
ジョブイベント収集モジュール512は、ジョブの実行状態が遷移したことをジョブ制御部503から受け取り、そのときの情報を機能アプリケーション502やジョブ制御部503から収集する。また、エラー制御部505から機器内で異常が発生したことの通知を受け、エラー発生要因等の情報を収集する。
機器状態収集モジュール513は、電源制御部504、履歴・設定保持部506から、機器の省電力状態が変化した際の情報や、履歴や設定の変更情報を収集する。
イベント送付部540はメッセージバッファ530への書き込みを検知するなどしてイベントが発行されたことを受け、メッセージバッファ530から情報を読み出してネットワーク通信部550を介して管理サーバ110に対してイベントを送付する。ネットワーク通信部550はNetwork 405を利用し通信する。
また、イベント収集設定部531はイベント収集設定送受信部541を介して受け取った収集設定の要求に応じて、イベント収集モジュール対応テーブル532から対応する各イベント収集モジュール(511〜513)を特定し収集設定を指示する。各イベント収集モジュール(511〜513)は各収集種別対応テーブル(521〜523)から収集指示を受けた収集種別に対応するイベント種別を取得する。そして、イベント情報のログを収集する設定を機器内各モジュール(501〜506)に対して有効化処理を実行するよう指示する。イベント収集設定部531は、設定した結果を、収集状態管理テーブル533に一時保存し、イベント収集設定送受信部541とネットワーク通信部550を介して管理サーバに通知する。この処理の詳細については、図７Ａ〜Ｃのフローチャートの説明を行う際に、具体的なテーブルの例を交えて説明する。
【００１５】
〔イベント送付処理〕
図６は本発明におけるネットワーククライアント120の機器内で各種イベントが生じた際の管理サーバ110へのイベント情報のログの送付処理の流れを示したフローチャートである。
エラー発生イベントを例にフローチャート600を説明する。フローチャート600はエラー発生イベントがイベント収集設定部531にてイベント発生時に即時収集するよう指定されていた場合にのみ実行される。
S601において、イベント回収部510がエラーの発生を検出する。
続いて、S602において、イベント回収部510は、現在時刻を取得する。
そしてS603において、イベント回収部510はイベント発行のサブルーチンに対してエラーイベントである旨と、取得した現在時刻を引数にして処理を実行することで管理サーバ110にイベントを送付する。
このサブルーチンについて次のフローチャート610で詳細に説明する。
S611において、イベント回収部510は受信したイベント種に応じてあらかじめ紐づけられた情報を機器内の各モジュールから収集する。例えばエラー発生のイベントであれば、エラーコードやエラーが起きた部品の名称、その時までの通紙したカウント値などが収集対象の情報になる。また、例えばコピージョブの完了イベントであれば、実行ユーザ名、カラーモノクロの区別、スキャン枚数、プリント枚数などが収集対象の情報になる。これら回収した情報に加えて、与えられた時刻情報を使ってJSONのような汎用フォーマットにして正規化する。
続いて、S612においてイベント回収部510は正規化されたイベント情報のログをメッセージバッファ530に保存する。この時点でサーバへの送付内容が確定される。
続くS613において、イベント送付部540は、メッセージバッファ530へのイベント情報のログの書き込みを非同期に検出し、メッセージバッファ530からイベント情報のログを読み出す。
S614のサブルーチンにおいて、イベント送付部530は、管理サーバ110への送信動作を行う。ここでは、サーバへの認証動作や通信エラー時のリトライ処理などを含めて送信完了までを実行する。送付された管理サーバ110は受信したイベント情報のログをストレージに保存する。
このようにしてネットワーククライアント120内で発生した各種イベント情報のログは管理サーバ110に送信され収集される。
【００１６】
〔イベント収集設定処理〕
図７Ａ〜Ｃは、本発明におけるネットワーククライアント120が、ネットワーク100を介して管理サーバ110からイベント収集要求を受け付け、イベント収集要求を反映するまでのイベント収集設定処理のフローチャートである。
＜収集種別設定の指示の読込処理＞
フローチャート700は、イベント収集設定部531が、収集種別設定の指示を保存したイベント収集設定ファイルの読込処理を示したフローチャートである。この処理は、ネットワーク通信部550からイベント収集設定送受信部541がイベント収集種別設定の指示を受け付け、イベント収集要求設定ファイルをＨＤＤ404に保存した際に行われる。また、ネットワーククライアント120が起動時に、既に受け取っていたイベント収集要求設定ファイルを読み込む際にも行われる。
S701において、イベント収集設定部531は、イベント収集設定送受信部541が受け取ったイベント収集要求設定ファイル801を読み込む。このイベント収集要求設定ファイル801は、図８で例示するように収集を行うイベントの種別を示す“収集種別”と、いつ収集を行うのかを示す“イベント取得トリガ”が記載されている。イベント収集要求設定ファイル801は、例えば、JSON，XML，CSV，YAMLのような汎用フォーマットで指定される。イベント収集設定部531は、設定ファイルから“収集種別”と“イベント取得トリガ”を読み込む。
【００１７】
【表１】
2020086696.tif 000003
【００１８】
S702では、続くS703〜S704において実行される、表１の例のようなイベント収集モジュール対応テーブル532から対応するイベント収集モジュールを確認する処理を、イベント収集モジュール毎に実行するループ処理を開始する。イベント収集モジュール対応テーブル532には、予めイベント収集モジュールと収集種別の対応関係が記録されている。
S703では、イベント収集モジュール対応テーブル532を参照して、要求された収集種別のうち該イベント収集モジュールに対応するものを選択する。
ここでは例として、図８のイベント収集要求設定ファイル801で指定をされた場合の機器状態収集モジュール513への設定について説明する。図８のイベント収集要求設定ファイル801では、収集種別は、“Basic”及び“Job”,“Diagnosis”が設定されている。そして、表１を参照すると、機器状態収集モジュール513に対応する収集種別は、上記3つの内、“Diagnosis”,“Basic”の２つが選択される。
S704では、S703で選択された”収集種別”及びその”イベント取得トリガ”を指定して、イベント収集モジュールにイベント収集の設定を行う。図８のイベント収集要求設定ファイル801の場合、機器状態収集モジュール513に対して“Diagnosis"を"即時"取得、"Basic"を"起動時"に取得するという指定で、イベント収集の設定を行うこととなる。この処理の詳細については710のフローチャートにて説明する。
＜イベント収集設定処理：S704＞
図７Ｂのフローチャート710は、図７ＡのS704の処理を示している。このフローチャート710は、各イベント収集モジュール(511〜513)がイベント収集設定部531から一つ以上の収集種別を指定して収集指示を行ったところから非同期に実行される。
【００１９】
【表２】
2020086696.tif 000004
【００２０】
S711では、各イベント収集モジュール(511〜513)は各イベント収集種別対応テーブル(521〜523)から対応する収集種別を確認し、収集種別毎にS712〜S715の処理を行う。イベント収集種別対応テーブル(521〜523)には、収集種別、イベント種別、イベント収集トリガの対応関係が記録されている。機器状態収集モジュール513の場合、表２の例のような機器状態収集種別対応テーブル523から収集種別として、“Basic"、“Diagnosis"、“Power"を読み込みそれぞれについてループを行う。
S712では、指示された収集種別に対応するイベント種別を確認し、処理をS713に進める。機器状態収集モジュール513が“Diagnosis"を“即時"取得の指定をされた場合、表２の例のような機器状態収集種別対応テーブル523から、“Diagnosis"に対応するのは“交換部品の交換完了"のイベントであることを確認する。また、機器状態収集モジュール513が“Basic"を“起動時"に取得の指定をされた場合であれば、“Basic"に対応するのが“基本構成情報"のイベントであることを確認する。
S713では、イベント収集設定部531から指定された収集種別が、当該イベント収集モジュールの収集種別対応テーブルの収集種別に、存在するかどうかを確認する。そして、存在する場合(S713でYes)はS714に、存在しない場合(S713でNo)はS718に処理を進める。機器状態収集モジュール513の場合、図８のイベント収集要求設定ファイル801で指定されている“Diagnosis"，“Basic"は存在するので、S715に、“Power"は存在しないので、S714に処理を進める。
S714では、”収集種別”が”イベント収集トリガ”に対応しているか否かを判定し、対応していれば処理をS715へ、対応していなければ次のループへ移行する。機器状態収集モジュール513の場合、“Diagnosis"に対応する“交換部品の交換完了"は、指定された“即時"イベント収集トリガに対応しているので、S715の処理を行う。
S715では、機器状態収集モジュール513は、“Diagnosis"に対応する“交換部品の交換完了"イベント発生時に即時取得するよう、履歴・設定保持部506に対して設定する有効化処理を行う。
このS715のイベント収集設定の有効化処理に関するサブルーチンの詳細についてはフローチャート730にて説明する。
S716ではイベント収集の設定の有効化処理が成功したかどうかを判断し、成功した場合(S716でYes)は、S717で動作しているイベント収集種別に関するリストである”設定した収集種別のリスト”に追加し、次のループを行う。失敗した場合(S716でNo)は、次のループを行う。
【００２１】
S718では、停止する収集種別に対応するイベント種別ごとに、S719にて収集するイベントの収集を停止する処理を機器内の各モジュール(501〜506)に対して行う。収集を停止するイベント種別についてS719の処理が終了し、S718のループ処理が全て終了したら、S720において、停止処理に成功していれば処理をS711からのループ処理の次のループに処理を進め、停止に失敗していればS717に処理を進める。S717では、動作しているイベント収集種別に関するリストである”設定した収集種別のリスト”に追加するため、停止処理に失敗したイベント種別の収集種別が登録されることになる。
図８のように“Power"が指定されていない収集要求だった場合、“電源OFF"、“電源ON"、“スリープ移行"、“スリープ復帰"について停止処理を行う。
S721では、設定した収集種別のリストを有効化処理の実行結果としてイベント収集設定部531に通知し処理を終了する。例では、機器状態収集モジュール513が“Diagnosis"を"即時"取得、"Basic"を"起動時"に取得するという設定に成功したことを設定した収集種別のリストとしてイベント収集設定部531に通知する。
【００２２】
＜イベント収集トリガ別イベント収集設定処理：S715＞
次に、イベント収集トリガ別イベント収集設定処理S715のサブルーチンについて、図７Ｃのフローチャート730を用いて説明する。
S731では、収集種別に対応する全ての“イベント種別”についてS732〜S736のループ処理を行う。
S732では、収集種別に対して設定要求の指定がされた“イベント収集トリガ”の種類を判定し、"即時"の場合はS733へ、“時間指定"の場合はS734へ、"起動時"の場合はS735に処理を進める。
・（即時）
S733では、機器内の各モジュール(501〜506)に、イベント発生時にイベント情報のログを取得し整形するためのコールバック関数を、イベントが発生するモジュールに対して登録し、S731の次のループ処理を進める。この処理を行うことで、イベントが発生した場合に、フローチャート600の処理が行われるようになる。
・（時間指定）
S734では、（機器内の各モジュール(501〜506)に、イベント情報のログを取得する時間間隔と、イベント情報のログを取得する関数を登録してタイマーを設定してS731の次のループに処理を進める。
・（起動時）
S735では、本フローチャートの処理の呼び出しがネットワーククライアント120の起動時の呼出しであるかを判定し、起動時であれば処理をS736へ、そうでなければS731の次のループに処理を進める。
S736では、指定された収集種別のイベント情報のログの収集を行い、S731の次のループに処理を進める。
【００２３】
＜収集要求の反映結果の通知処理＞
図９は、本発明におけるイベント収集設定部531がイベント収集設定送受信部541に収集要求の反映結果を通知する処理を示したフローチャートである。この処理は、管理サーバ110から受け付けたイベント収集要求設定の反映結果が、各イベント収集モジュール(511〜513)それぞれからイベント収集設定部531へ”設定した収集種別のリスト”としてS721で通知されてから、非同期で実行される。図７のフローチャートで図８のイベント収集要求設定ファイル801を受け取った場合の処理を例として以下に説明する。
【００２４】
【表３】
2020086696.tif 000005
【００２５】
以下では、まず機器状態収集モジュール513から、 “Diagnosis"を“即時"、“Basic"を“起動時"に設定した旨の通知を受け取り、図９のフローを一度実行する処理を説明する。そして、その後、ジョブイベント収集モジュール512から"“Job"を“即時"、“Diagnosis"を“即時"で受けとり再度図９のフローを実行する処理を説明する。なお、処理前は表３のように、収集状態管理テーブル533の現在の収集状態がすべて停止の状態とし、ここから表７まで収集状態管理テーブル533を更新していくものとする。
S901では、イベント収集設定部531は、各イベント収集モジュールからイベント収集要求の反映結果を”設定した収集種別のリスト”として受け取り、収集状態管理テーブル533に反映する。初めに、機器状態収集モジュール513から通知が来たとき、表３から表４のように更新される。
イベント収集モジュールが機器状態収集モジュール513で収集種別が“Diagnosis"は、現在の収集状態を“即時"とし、収集種別が“Basic"は、現在の収集状態を“起動時"となる。
【００２６】
【表４】
2020086696.tif 000006
【００２７】
S902では、収集状態管理テーブル533の収集種別毎に、S903〜S904の処理をループして実行する。
S903では、収集種別に対応するイベント収集モジュールの全ての収集状態が等しいかどうかを確認し、等しい場合（S903でYes）はS904に、異なる場合は次のループを実行する。“Basic"の場合、対応するイベント収集モジュールが一つなので、処理をS904に進める。
S904では、”管理サーバに通知する状態”を現在の収集状態に更新し、次のループに処理を進める。表４のように、“Basic"の管理サーバに通知する状態が“停止"となっている箇所を、“起動時"に更新する。
また、S903において"Diagnosis"に対しては、ジョブイベント収集モジュール512と機器状態収集モジュール513がそれぞれ“停止"と"即時"の収集状態になっているため、何もせずに次のループに進む。このように異なる収集状態となる場合は、次のような場合があり得る。ひとつは、表４のように、ジョブイベント収集モジュール512から通知が来ていない状態で機器状態収集モジュール513から先に通知が来て過渡状態となっている場合である。もう一つは、ジョブイベント収集モジュール512が"Diagnosis"の設定反映に失敗していた場合である。なお、反映が失敗している状態となるのは、イベント情報のログ収集元である履歴・設定保持部505が大量のイベント情報のログ収集処理を行っておりタイムアウトする場合がある。その外、履歴・設定保持部506が故障等で動作しておらず、イベント情報のログ収集のための手続きが行えない場合も考えられる。
【００２８】
S903で同じでないと判定した場合、収集状態管理テーブル533の”管理サーバに通知する状態”を変更せず、次のループに処理を進める。このように場合は、表５のように、”管理サーバに通知する状態”は"停止"のままとする。
なお、S903で同じでないと判定した場合に何もしないことで、過去にクラウドに通知した状態のまま再度通知し、取得可能なログは取得しつつ、設定を変更できなった旨をクラウドに通知することが可能である。片方のイベント収集モジュールは動作してしまっているが、管理サーバ110から動作してもいいという指示を受けているため、動作したままで問題はない。また逆に、複数のイベント収集モジュールが動作している状態から停止する場合は、同様にイベント情報のログの収集を停止できなかった旨を通知することが可能である。しかし、この場合は、片方のイベント収集モジュールは動作したままになってしまっている。そこで、管理サーバ110側はイベント収集要求設定のリトライを行うことや、該当のネットワーククライアント120からはイベントログの受信を受け付けないなどの対応を行う必要がある。
【００２９】
【表５】
2020086696.tif 000007
【００３０】
S905では、更新した収集状態管理テーブル533の”管理サーバに通知する状態”をJSONやXML、CSV、YAMLなどの汎用のフォーマットで反映結果ファイルとして書きこみ、処理を終了する。イベント収集設定送受信部541は反映結果ファイルへの書き込みイベントの通知を受け取ったときや、イベント収集要求設定ファイルを受信してから一定時間経過したときにその応答として反映結果ファイルを管理サーバ110に送信する。
次に、ジョブイベント収集モジュール512から“Job"を“即時"、“Diagnosis"を“即時"で受けとり図９のフローチャートを実行する場合、上記の例と同じようにS901で処理を行う。この結果として、表６のように収集状態管理テーブル533が更新される。
【００３１】
【表６】
2020086696.tif 000008
【００３２】
次に、S903では、"Diagnosis"に対して、ジョブイベント収集モジュール512と機器状態収集モジュール513がそれぞれ"即時"の収集状態になっているため、処理をS904に進める。
S904では、管理サーバに通知する状態を現在の収集状態に更新し、次のループに処理を進める。表４の"Diagnosis"を"即時"に更新する。この処理を続けた結果、収集状態管理テーブル533は表７のような状態になる。
【００３３】
【表７】
2020086696.tif 000009
【００３４】
図１０は、管理サーバ110のソフトウェア構成の一例を示すブロック図である。本発明は、ＲＡＭ203、ＨＤＤ204、ＲＯＭ202のいずれかの記憶手段に記憶されたソフトウェアをＣＰＵ201が実行することにより実現される。
デバイス通信部1001はNetwork 207を介して、ネットワーククライアント120との通信を行う。
データストア1002は、デバイス通信部1001を介してネットワーククライアント120から受信したイベント情報のログをＨＤＤ204に記憶したものである。
接続デバイス管理部1011は、デバイス通信部1001を介して、接続しているネットワーククライアント120の情報を管理する。ここで、管理する情報には、ネットワーククライアント120のＩＤ、現在収集しているイベント情報のログの収集種別、ネットワーククライアント120に提供しているクラウドサービス(1031〜1032)等が含まれる。接続デバイス管理部1011は、ネットワーククライアント120から通知された収集種別を管理することで、ネットワーククライアント120で異常等が発生していることを検出することができる。
イベント収集設定インタフェース部1021は、Network 207を介してWebページをユーザの操作端末130に提供し、ユーザからネットワーククライアント120への収集要求設定を受け付ける。イベント収集設定インタフェース部1021からイベント情報のログの収集要求設定を受け付けると、デバイス通信部1001を介して、ユーザが指定したネットワーククライアント120へ、イベント情報のログの収集要求設定を送信する。
【００３５】
機器状態監視サービス1031、および顧客価値向上支援サービス1032は、ネットワーククライアント120やユーザに提供されるクラウドサービスの一例である。これらのクラウドサービス(1031〜1032)はサービスを提供するうえで必要なイベント情報のログを、接続デバイス管理部1011とデバイス通信部1001を介してデータストア1002から取得する。機器状態監視サービス1031は、ネットワーククライアント120の消耗品の使用量の稼働状態を監視し、適切なタイミングで消耗品の発送を行うなどのサービスを提供する。顧客価値向上支援サービス1032は、ジョブの実行状況などを解析し、顧客の価値を向上できるような提案を行うなどのサービスを提供する。
これらのクラウドサービス(1031〜1032)は、サービスを提供するうえで必要なイベント情報のログの収集要求を、接続デバイス管理部1011とデバイス通信部1001を介してサービスを提供するネットワーククライアント120に対して行う。例えば、機器状態監視サービス1031の場合、“Basic"、“Job"、“Diagnosis"等、顧客価値向上支援サービス1032の場合、“Job"、“Power"等となる。
なお、本実施例では、図１０のようにネットワーククライアント120が、管理サーバ110にイベント情報のログを送信するとしたが、ネットワーク100上の異なるシステムにイベント情報のログを送信するようにしてもよい。
本実施例により、新たに顧客に提供するクラウドサービスに連動して、ネットワーククライアント120の各イベント収集モジュールの単位とは異なる収集種別の単位で、イベント情報のログの収集設定を切り替えることが可能となる。
【実施例２】
【００３６】
実施例１では、表２のように収集種別が指定するイベント種別が被らない区分の仕方の場合の処理について説明したが、収集種別の分け方の観点が複数ある場合、複数の収集種別が同一のイベント種別に対応するような多対１対応の場合が考えられる。実施例２では、表８のように、複数の収集種別が同一のイベント種別を指定する場合であっても、適切に各イベント収集モジュール(511〜513)と異なる単位でイベント情報のログの収集設定を切り替えられるようにする。
【００３７】
【表８】
2020086696.tif 000010
【００３８】
例として、機器状態収集モジュール513の機器状態収集種別対応テーブル523が表８のようなときに、図１２のように、“Basic"が“2時間おき"、“HighPriority"が“3時間おき"というような収集要求を受け取った場合を考える。この場合、“基本構成情報"のイベント種別に対してタイマーを別々に設定してしまうと、6時間おきのタイミングでは二つの収集種別に対して2回分ログが取得されてしまう。
【００３９】
図１１Ａは、本発明におけるネットワーククライアント120が、ネットワーク100を介して管理サーバ110からイベント収集要求を受け付けた際に収集要求を反映するまでのフローチャートである。実施例１で説明した図７Ｃのフローと異なる箇所についてのみ説明する。
S732で時間指定の場合に、S1101では、同じイベント種別に既にタイマーが設定されているかを判定し、設定されているならS1102に、設定されていないならS734に処理を進める。
S1102では、既に設定されているタイマーを解除し、一度イベントログの取得を行い、処理をS1103に進める。これは、すでに既存のタイマーを設定してから時間がたっている場合、タイマーを設定しなおしてしまうと、次のイベントログが取得されるタイミングが、始動する予定だった時間よりも大きく遅れてしまう可能性があるためである。
S1103では、既に設定されていた時間間隔と、新たに設定するタイマーの最大公約数の時間でタイマーを設定し、処理を終了する。図１２のように、“2時間おき"、“3時間おき"というような収集要求を受けた場合は1時間おきとなる。このとき、設定したタイマーに対して内部的にカウンタを用意し、0で初期化しておく。また、各時間間隔も保存をしておく。
【００４０】
図１１Ｂのフローチャート1121は、実施例２において、設定したタイマーが始動した場合のフローチャートである。
S1122では、S1103で設定した時間をカウンタに加算し、処理をS1123に進める。図１２の例の場合、1時間を加算する。
S1123では、始動したタイマーのカウンタが設定されている時間の倍数であるかを確認し、倍数であった場合には処理をS1124にてイベント情報のログの取得を行い、倍数でない場合は処理を終了する。図１２の例の場合、2時間、或いは3時間の倍数であるかを確認する。つまり、「2、3、4、6…」というように収集要求の来た時間間隔の倍数の時間に1回ずつ“基本構成情報"のイベント情報のログを重複しないよう取得することになる。
実施例２によれば、同一のイベント種別に対して複数の収集種別が複数の時間間隔の指定をされた場合でも、それぞれの収集種別の時間間隔について必要な回数だけのイベント情報のログを収集することができる。
【００４１】
(その他の実施例) 
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける1つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路(例えば、ASIC)によっても実現可能である。
【図１】
2020086696.tif 000011
【図２】
2020086696.tif 000012
【図３】
2020086696.tif 000013
【図４】
2020086696.tif 000014
【図５】
2020086696.tif 000015
【図６】
2020086696.tif 000016
【図７Ａ】
2020086696.tif 000017
【図７Ｂ】
2020086696.tif 000018
【図７Ｃ】
2020086696.tif 000019
【図８】
2020086696.tif 000020
【図９】
2020086696.tif 000021
【図１０】
2020086696.tif 000022
【図１１Ａ】
2020086696.tif 000023
【図１１Ｂ】
2020086696.tif 000024
【図１２】
2020086696.tif 000025