(57)【要約】      （修正有）【課題】装置の消費電力の増大を抑えつつ、装置の内部で収集されるデータをその特性に応じて適切に外部システムに送信し、装置の各種保守作業や改善、その他処理を適切に行うことを可能にすること。【解決手段】装置の稼働情報である第１のデータ、プロセッサ、メモリ、ストレージを含む複数のハードウェアの利用状況に関する第２のデータを収集するクライアント機では、装置の内部で収集されるデータを外部システムに送信するタイミングにクライアント機が省電力状態だった場合には、省電力状態から復帰させることによる第１のデータの送信を制限せず且つ第２のデータの送信を制限し、前記タイミングにクライアント機が省電力状態でなかった場合には、第１のデータの送信及び第２のデータの送信を制限しないように制御する（Ｓ８０４〜Ｓ８０６）。【選択図】図８
2020156007.tif 000002
【特許請求の範囲】
【請求項１】
プロセッサ、メモリ、ストレージを含む複数のハードウェアを備える画像処理装置であって、
前記画像処理装置の内部で収集されるデータを外部システムに送信するタイミングを管理する管理手段と、
前記画像処理装置の内部で収集されるデータを前記外部システムに送信する送信手段と、
前記画像処理装置の稼働情報である第１のデータを収集する第１収集手段と、
前記複数のハードウェアの利用状況に関する第２のデータを収集する第２収集手段と、を有し、
前記タイミングに前記画像処理装置の状態が省電力状態だった場合には、前記省電力状態から復帰させることによる前記送信手段による前記第１のデータの送信は制限されず且つ前記第２のデータの送信は制限され、
前記タイミングに前記画像処理装置の状態が省電力状態でなかった場合には、前記送信手段による前記第１のデータの送信及び第２のデータの送信は制限されないことを特徴とする画像処理装置。
【請求項２】
前記管理手段は、前記画像処理装置の状態が省電力状態であった場合にも通知される第１のタイマーにより前記第１のデータの送信タイミングを管理し、前記画像処理装置の状態が省電力状態であった場合には通知されない第２のタイマーにより前記第２のデータの送信タイミングを管理することを特徴とする請求項１に記載の画像処理装置。
【請求項３】
前記第１収集手段及び前記第２収集手段は、前記タイミングに予め紐づけられたデータを収集することを特徴とする請求項１又は２に記載の画像処理装置。
【請求項４】
前記画像処理装置が省電力状態の間に前記第２のデータの送信タイミングとなった場合、該省電力状態から復帰した場合に前記第２のデータの少なくとも一部のデータが前記送信手段により前記外部システムへ送信されることを特徴とする請求項１〜４のいずれか１項に記載の画像処理装置。
【請求項５】
前記第２のデータの少なくとも一部のデータは、前記ストレージの寿命に関するデータであることを特徴とする請求項４に記載の画像処理装置。
【請求項６】
前記ストレージの寿命に関するデータは、ストレージの書き込み量もしくは回数であることを特徴とする請求項５に記載の画像処理装置。
【請求項７】
前記画像処理装置が省電力状態から復帰した要因が前記第１のデータの送信タイミングによる場合には、前記送信手段により前記第２のデータが送信されないことを特徴とする請求項４〜６のいずれか１項に記載の画像処理装置。
【請求項８】
プロセッサ、メモリ、ストレージを含む複数のハードウェアを備える画像処理装置で、前記画像処理装置の内部で収集されるデータを外部システムに送信するタイミングを管理する管理手段と、前記画像処理装置の内部で収集されるデータを前記外部システムに送信する送信手段と、前記画像処理装置の稼働情報である第１のデータを収集する第１収集手段と、前記複数のハードウェアの利用状況に関する第２のデータを収集する第２収集手段と、を有する画像処理装置の制御方法であって、
前記タイミングに前記画像処理装置の状態が省電力状態だった場合には、前記省電力状態から復帰させることによる前記送信手段による前記第１のデータの送信を制限せず且つ前記第２のデータの送信を制限し、
前記タイミングに前記画像処理装置の状態が省電力状態でなかった場合には、前記送信手段による前記第１のデータの送信及び第２のデータの送信を制限しないことを特徴とする画像処理装置の制御方法。
【請求項９】
コンピュータを、請求項１〜７のいずれか１項に記載の手段として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、装置の内部で収集されるデータを外部システムに送信する画像処理装置、画像処理装置の制御方法、及びプログラムに関する。
【背景技術】
【０００２】
迅速な保守、予兆予測・装置搭載機能の改善を行うことを目的として、稼働している装置からインターネットを通じてイベントログ管理サーバに各種イベントログを送信するシステムが知られている。例えば、ＭＦＰ（Multifunction Peripheral）やプリンタなどの画像処理装置には画像処理装置には、稼働情報（カウンタ、エラー、ジョブログなど）を、スケジュールや発生タイミングなどの条件で外部システムに送信するものがある。
【０００３】
なお、装置が省電力状態の場合には、装置がイベントログ管理サーバにデータを送信しないように制御する技術が知られている。特許文献１では、データの送信停止時間帯を指定し、送信停止時間帯の終了時刻に省電力状態から復帰させることが開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１４−０５０９７６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかし、従来のように、装置が省電力状態であった場合にデータを送信しない制御とすると、消費電力は抑えることができるが、省電力状態のため送信を見送られたデータが長期間入手できず、各種保守作業や改善、その他処理の妨げとなる可能性が生じる。例えば、装置の使用量をもとにユーザに対して課金を行うような装置においては、省電力状態でも復帰した上で定期的にイベントログを送信することが必要である。このように、装置は定期的に送信するイベントログの種別に応じて適切に制御を行う必要が生じるが、従来の技術では、このような制御を適切に行うことができなかった。
【０００６】
本発明は、上記の問題点を解決するためになされたものである。本発明の目的は、消費電力の増大を抑えつつ、装置の内部で収集されるデータをその特性に応じて適切に外部システムに送信でき、各種保守作業や改善、その他処理を適切に行うことが可能となる仕組みを提供することである。
【課題を解決するための手段】
【０００７】
本発明は、プロセッサ、メモリ、ストレージを含む複数のハードウェアを備える画像処理装置であって、前記画像処理装置の内部で収集されるデータを外部システムに送信するタイミングを管理する管理手段と、前記画像処理装置の内部で収集されるデータを前記外部システムに送信する送信手段と、前記画像処理装置の稼働情報である第１のデータを収集する第１収集手段と、前記複数のハードウェアの利用状況に関する第２のデータを収集する第２収集手段と、を有し、前記タイミングに前記画像処理装置の状態が省電力状態だった場合には、前記省電力状態から復帰させることによる前記送信手段による前記第１のデータの送信は制限されず且つ前記第２のデータの送信は制限され、前記タイミングに前記画像処理装置の状態が省電力状態でなかった場合には、前記送信手段による前記第１のデータの送信及び第２のデータの送信は制限されないことを特徴とする。
【発明の効果】
【０００８】
本発明によれば、消費電力の増大を抑えつつ、装置の内部で収集されるデータをその特性に応じて適切に外部システムに送信できる。よって、装置の各種保守作業や改善、その他処理を適切に行うことが可能となる。
【図面の簡単な説明】
【０００９】
【図１】本実施形態を示すシステム全体の構成の一例を示す図。
【図２】管理サーバのハードウェア構成の一例を示すブロック図。
【図３】クライアント機のハードウェア構成の一例を示すブロック図。
【図４】クライアント機の情報処理コントローラユニットのハードウェア構成の一例を示すブロック図。
【図５】クライアント機のソフトウェア構成の一例を示すソフトウェアブロック図。
【図６】メッセージバッファに保存される正規化されたイベント情報の一例を示す図。
【図７】メッセージバッファに保存される正規化されたイベント情報の他の例を示す図。
【図８】イベント回収部の初期化時に行われる処理の流れの一例を示すフローチャート。
【図９】定期収集イベントの収集時に行われる処理の流れの一例を示すフローチャート。
【図１０】第１実施形態におけるクライアント機が省電力状態から復帰したことに対応してイベント回収部が行う処理の一例を示すフローチャート。
【図１１】第２実施形態におけるクライアント機が省電力状態から復帰したことに対応してイベント回収部が行う処理の一例を示すフローチャート。
【図１２】第３実施形態において省電力状態から復帰した際に収集される正規化されたイベント情報の一例を示す図。
【発明を実施するための形態】
【００１０】
以下、本発明を実施するための形態について図面を用いて説明する。
〔第１実施形態〕
図１は、本発明の一実施形態を示すシステム全体の構成の一例を示す図である。
図１に示すように、ネットワーク１００には、管理サーバ１１０及び複数のクライアント機１２０（１２０ａ、・・・、１２０ｂ）が接続されている。
【００１１】
クライアント機１２０は、機器内での事象を履歴イベントの形で管理サーバ１１０に対して通知する通信機能を具備している。また、管理サーバ１１０は、複数のクライアント機１２０から通知されたイベントを管理サーバ１１０内のストレージに保存する機能を具備している。該ストレージに蓄積された情報は、稼働監視情報の分析などに利用される。
【００１２】
本実施形態では、管理サーバ１１０を、データストレージと情報処理計算とネットワーク通信機能性を具備できるコンピュータなどの一般的な情報処理装置や、同等機能を持つクラウドサービスで実現する。
【００１３】
また、クライアント機１２０としては、複数種類の機能、例えばコピーやプリンタやファクシミリ等を実現する複合機等の画像処理装置を例に説明する。クライアント機１２０は、それらの機能の実行をした履歴に加え、省電力状態への遷移や復帰の履歴、またエラー発生など異常状態への遷移・復帰などの履歴などを、管理サーバ１１０に通知する機能を具備している。
【００１４】
図２は、管理サーバ１１０が一般的なコンピュータなどの情報処理装置で実現された場合の構成の一例を示すブロック図である。
管理サーバ１１０は、コントローラユニット２００、操作部２０９、表示部２１０を含んでいる。
コントローラユニット２００は、ＣＰＵ（Central Processing Unit）２０１を有する。
【００１５】
ＣＰＵ２０１は、ＲＯＭ（Read Only Memory）２０２に保存されているブートプログラムによりＯＳ（Operating System）を起動する。ＣＰＵ２０１は、このＯＳ上で、ＨＤＤ（Hard Disk Drive）２０４に保存されているアプリケーションプログラムを実行し、これによって各種処理を実行する。このＣＰＵ２０１の作業領域としてはＲＡＭ（Random Access Memory）２０２が用いられる。ＨＤＤ２０４は、上記アプリケーションプログラムと設定や履歴等のデータを保存する。なお、ＨＤＤ２０４の代わりに又は併用してＳＳＤ（Solid State Drive）等の他の記憶装置を備える構成でもよい。
【００１６】
ＣＰＵ２０１には、システムバス２０８を介して、ＲＯＭ２０２およびＲＡＭ２０３とともに、操作部Ｉ／Ｆ２０５、表示部Ｉ／Ｆ２０６、Ｎｅｔｗｏｒｋ２０７が接続される。
操作部Ｉ／Ｆ２０５は、マウス、キーボード等から成る操作部２０９とのインタフェースであり、操作部２０９によってユーザにより入力された情報をＣＰＵ２０１に送出する。
表示部Ｉ／Ｆ２０６は、ディスプレイ等から成る表示部２１０に表示すべき画像データを表示部２１０に対して出力する。
Ｎｅｔｗｏｒｋ２０７は、ネットワーク１００に接続され、ネットワーク１００を介してネットワーク１００上の各装置との間で情報の入出力を行う。
【００１７】
図３は、クライアント機１２０のハードウェア構成の一例を示すブロック図である。
クライアント機１２０は、情報処理コントローラユニット３０１、プリンタコントローラユニット３０２、スキャナコントローラユニット３０３、プリンタ３０４、スキャナ３０５、操作部３０６を含んでいる複合機である。
【００１８】
情報処理コントローラユニット３０１は、クライアント機１２０の動作に係る情報処理制御を統括するコントローラであり、操作部３０６が接続される。さらに、情報処理コントローラユニット３０１には、画像出力デバイスであるプリンタ３０４を制御するプリンタコントローラユニット３０２や画像入力デバイスであるスキャナ３０５を制御するスキャナコントローラユニット３０３が接続される。
【００１９】
図４は、情報処理コントローラユニット３０１のハードウェア構成の一例を示すブロック図である。
図４に示すように、情報処理コントローラユニット３０１は、ＣＰＵ４０１を有する。
ＣＰＵ４０１は、ＲＯＭ４０２に保存されているブートプログラムによりＯＳを起動するプロセッサである。ＣＰＵ４０１は、このＯＳ上で、ＨＤＤ４０４に保存されているアプリケーションプログラムを実行し、これによって各種処理を実行する。このＣＰＵ４０１の作業領域としてはＲＡＭ４０３が用いられる。ＲＡＭ４０３はメモリであり、作業領域を提供するとともに、画像データを一時記憶するための画像メモリ領域を提供する。ＨＤＤ４０４は、上記アプリケーションプログラムや画像データ、各種設定値や履歴を保存するストレージである。なお、ＨＤＤ４０４の代わりに又は併用してＳＳＤ等の他の記憶装置を備える構成でもよい。
【００２０】
ＣＰＵ４０１には、システムバス４１０を介して、ＲＯＭ４０２およびＲＡＭ４０３とともに、操作部Ｉ／Ｆ４０６、デバイスコントローラＩ／Ｆ４０８、Ｎｅｔｗｏｒｋ４０５、画像処理部４０７、および電源管理部４０９が接続される。
【００２１】
操作部Ｉ／Ｆ４０６は、タッチパネルを有する操作部３０６とのインタフェースであり、操作部３０６に表示すべき画像データを操作部３０６に対して出力する。また、操作部Ｉ／Ｆ４０６は、操作部３０６によってユーザにより入力された情報をＣＰＵ４０１に送出する。
【００２２】
デバイスコントローラＩ／Ｆ４０８には、スキャナコントローラユニット３０３およびプリンタコントローラユニット３０２が接続される。デバイスコントローラＩ／Ｆ４０８は、画像データの同期系／非同期系の変換を行う。
【００２３】
Ｎｅｔｗｏｒｋ４０５は、ネットワーク１００に接続され、ネットワーク１００を介してネットワーク１００上の各装置との間で情報の入出力を行う。
画像処理部４０７では、プリンタ３０４への出力画像処理やスキャナ３０５からの入力画像処理、画像回転、画像圧縮、解像度変換、色空間変換、階調変換などの処理を行う。
電源管理部４０９は、機器全体の電源制御を行う。例えば、電源管理部４０９は、電源オン／オフの制御の他、通常通電状態ではない省電力状態（通常通電状態よりも消費電力が小さい）への移行や、通常通電状態への復帰などを制御する。
【００２４】
図５は、クライアント機１２０のソフトウェア構成の一例を示すソフトウェアブロック図である。
図５に示すソフトウェア構成は、ＲＡＭ４０３、ＨＤＤ４０４、ＲＯＭ４０２のいずれかの記憶部に記憶されたプログラムをＣＰＵ４０１が実行することにより実現される。クライアント機１２０が複合機等の画像処理装置の場合、スキャン、プリント、およびネットワークやメモリ、ストレージを利用した各種機能性を実現するソフトウェアが動作する。
【００２５】
ユーザインターフェース５０１は、操作部３０６に対してユーザが操作する画面を表示したり、ユーザが操作した際にその動きをソフトウェアに伝えたりする機能を持つ。
機能アプリケーション５０２は機器内に複数設けられており、例えば、コピー、プリント、メール送信などのアプリケーション機能ごとに設けられている。各機能アプリケーション５０２は、操作部３０６を経由したユーザの指示やＮｅｔｗｏｒｋ４０５経由のデータ受信などをトリガーにして、複合機のアプリケーション機能を動作させる。
【００２６】
ジョブ制御部５０３は、機能アプリケーション５０２からの指示を受けてプリンタコントローラユニット３０２やスキャナコントローラユニット３０３を制御して、スキャンやプリントなどを実行する。
電源制御部５０４は、装置内のソフトウェアの状態と連動して電源管理部４０９を制御し、通常通電状態と省電力状態の遷移を司る。また、電源制御部５０４は、所定の時刻にクライアント機１２０内の任意のソフトウェアに対してタイマー通知を行うタイマー機能を有する。クライアント機１２０内のソフトウェアは、予め電源制御部５０４にタイマー通知を受信したい時刻を登録することにより、所定の時刻に必要な処理を行うことが可能である。なお、電源制御部５０４は、通常通電状態である場合にのみタイマー通知を行える通常タイマー機能と、省電力状態である場合でも通常通電状態に移行した上でタイマー通知を行える省電力復帰タイマー機能の二種類のタイマー機能を有する。
【００２７】
エラー制御部５０５は、主にジョブ制御部５０３やプリンタコントローラユニット３０２やスキャナコントローラユニット３０３などで発生した異常状態の通知を受け、システム全体を停止したり縮退動作を指示したりの制御を実施する。
【００２８】
履歴・設定保持部５０６は、機器内における不揮発情報を管理する。履歴・設定保持部５０６は、複合機やジョブの制御に必要な設定を保持したり、ユーザの操作履歴やジョブ実行結果およびエラーの発生などをサマライズして保存したりする。また、履歴・設定保持部５０６は、システムの不具合発生時に解析デバッグ用途で残すログ情報も保持する。なお、不揮発情報の実体は、ＨＤＤ４０４に保持される。
【００２９】
情報処理コントローラ状態管理部５０７は、情報処理コントローラユニット３０１に含まれるＣＰＵ４０１、ＲＡＭ４０３などの各要素の状態を管理する。具体的には、情報処理コントローラ状態管理部５０７は、ＣＰＵ４０１、ＲＡＭ４０３、ＨＤＤ４０４の使用量もしくは使用率や、ＨＤＤ４０４に対する通算の書き込み量などのデータを、他のソフトウェアからの取得要求に対応して返却する。
【００３０】
機器使用量管理部５０８は、ユーザによるクライアント機１２０の使用量に関する情報を保持する機能を持つ。上記使用量に関する情報としては、具体的には、プリントジョブ等を通じてクライアント機１２０が排紙した用紙の枚数や、印刷時に消費した材料の量が考えられる。しかし、上記使用量に関する情報は、これらに限らずクライアント機１２０の使用量を把握するために必要な情報であれば内容は問わない。本実施形態においては、機器使用量管理部５０８は、ジョブ制御部５０３をはじめとした各種ソフトウェアから伝達されたこれらの内容を永続化するものとする。これらの情報を用いることにより、例えば、ユーザによるクライアント機１２０の使用量に応じた課金を行うことが可能となる。
【００３１】
イベント回収部５１０は、機器内の各モジュール（５０１〜５０８）で発生したデータを監視し、それを管理サーバ１１０に送付するため、イベントの形で正規化しメッセージバッファ５２０に保存する機能性を持つ。
【００３２】
メッセージバッファ５２０は、ＨＤＤ４０４上に実現される不揮発性記憶領域であり、正規化されたイベント等を保存する。本実施形態においては、イベントの正規化方式としてＪＳＯＮ（JavaScript(登録商標) Object Notation）フォーマットを使うものとするが、これに限定されるものではない。イベント情報には、イベント名称、発生時刻、などの基本情報に加えてイベントの種別によって、追加でさまざまな情報が付与される。これら付与情報は、イベント回収部５１０が情報処理コントローラ状態管理部５０７・機器使用量管理部５０８などから取得する。具体的なイベント情報の例については後述する。
【００３３】
イベント送付部５３０は、メッセージバッファ５２０への書き込みを検知するなどしてイベントが発行されたことを受け、メッセージバッファ５２０から情報を読み出して、ネットワーク通信部５３１を介して管理サーバ１１０に対してイベントを送付する。
ネットワーク通信部５３１は、Ｎｅｔｗｏｒｋ４０５を利用し通信する。
【００３４】
次に、本実施形態で使用する定期収集データの管理テーブルに関して説明する。
表１に、定期収集データの管理テーブルを例示する。
本実施形態では、この定期収集データの管理テーブルに相当するデータをＨＤＤ２０４に保持するものとするが、例えば管理サーバ１１０から同等のデータを受信し、このデータを基に処理を行ってもよい。
【００３５】
【表１】
2020156007.tif 000003
【００３６】
表１のように、定期収集データの管理テーブルには、定期的に収集すべきイベントの各々の内容について、「収集間隔」や、「省電力状態でも収集するイベントか？」の情報が関連付けられている。「収集間隔」は、定期収集を行う際の時間間隔を示す。「省電力状態でも収集するイベントか？」の情報は、定期収集すべき時刻に達したときに省電力状態であった場合にもデータ収集を行うかどうかを指定する情報を示す。
【００３７】
図６は、メッセージバッファ５２０に保存される正規化されたイベント情報の一例を示す図である。特に図６にはクライアント機１２０の稼働情報の一例を示す。
【００３８】
上述したように、本実施形態においては、イベント情報をＪＳＯＮ形式で表現する。イベント情報は、イベント種別（event_type属性）、イベント発生日時（occur_datetime属性）が付与され、必要に応じて発生したイベントの具体的な内容（attributes属性）が含まれる構成である。また、イベント情報に、イベントに関連する付加情報（additional_info属性）を付与することも可能である。
【００３９】
図６の例は、課金に関する機器の使用量スナップショット情報が収集されたことを示すイベント情報であり、そのことを“device_charge_counts_snapshotted”属性により示している。このイベント情報には、モノクロ・カラーで印刷された用紙枚数（“mono_output_papers”、“color_output_papers”属性）や、合計の排紙枚数（“total_output_papers”属性）が付加情報として記録されている。
【００４０】
なお、表１に示した管理テーブルによれば、図６のデータは１６時間に１回データ収集が行われる。また、図６のデータは、データ収集時刻を行うべき時刻にクライアント機１２０が省電力状態であったとしても、省電力状態から復帰して収集を行うイベントに対応する。
【００４１】
図７は、メッセージバッファ５２０に保存される正規化されたイベント情報の他の例を示す図である。特に図７にはクライアント機１２０のプロセッサ、メモリ、ストレージを含む複数のハードウェアの利用状況に関する情報の一例を示す。
【００４２】
図７の例は、情報処理コントローラユニット３０１の使用量スナップショット情報の収集に関するイベント情報であり、そのことを“info_controller_usage_snapshotted”属性により示している。このイベント情報には、ＣＰＵ４０１、ＲＡＭ４０３、ＨＤＤ４０４の使用量に関するデータ（“average_usage_rate”属性、“peek_usage_rate”属性）がそれぞれ付加情報として“CPU_usage”属性、“RAM_usage”属性、“HDD_usage”属性に記録されている。加えて、ＨＤＤ４０４に関しては、データへのアクセスに伴い消耗が進むため、“HDD_usage”属性にはＨＤＤ４０４の寿命に関するデータとして、想定される寿命を１００％とした場合の現在の寿命（“device_life_rate”属性）が記載されている。図７の例では、ＨＤＤ４０４は、想定寿命の８％の消耗率である。なお、“HDD_usage”属性に記載されるＨＤＤ４０４の寿命に関するデータは、ＨＤＤ４０４の書き込み量もしくは回数のデータであってもよい。また、ストレージがＨＤＤではなくＳＳＤの場合、ストレージの寿命に関するデータは、ＳＳＤの書き換え回数のデータであってもよい。
【００４３】
なお、表１に示した管理テーブルによれば、図７のデータは２４時間に１回データ収集が行われる。また、図７のデータは、データ収集時刻を行うべき時刻にクライアント機１２０が省電力状態であった場合には、その時点では収集を行わないイベントに対応する。
【００４４】
図８は、本実施形態におけるイベント回収部５１０の初期化時に行われる処理の流れの一例を示すフローチャートである。本フローチャートに相当する処理は、クライアント機１２０の起動時に、ＲＡＭ２０３に展開されたプログラムをＣＰＵ２０１が読み取り実行することにより実現される。
【００４５】
本フローチャートに対応する処理が開始されると、イベント回収部５１０は、最初に現在時刻を取得する（Ｓ８０１）。
次に、イベント回収部５１０は、収集すべき定期収集データの数だけ以降の処理（Ｓ８０３〜Ｓ８０７）を繰り返すように制御する（Ｓ８０２）。具体的には、表１の各行に記載された各定期収集イベントを、順次、処理対象のイベントとして、以下のＳ８０３〜Ｓ８０７に示す処理を行う。
【００４６】
まず、イベント回収部５１０は、処理対象となる定期収集イベントを次回収集する時刻を決定する（Ｓ８０３）。具体的には、上記Ｓ８０１で取得した現在時刻に、表１で示した管理テーブル内の収集間隔を加算する。例えば、現在時刻が「１５時２１分」で、収集間隔が「１６時間」であれば、次回収集する時刻は「０７時２１分」となる。
【００４７】
続いて、イベント回収部５１０は、処理対象となる定期収集イベントが、省電力状態でも収集するイベントであるかどうかを判断する（Ｓ８０４）。具体的には、表１で示した管理テーブル内の３列目の項目が「Ｙｅｓ」であるか「Ｎｏ」であるかを確認する。
【００４８】
イベント回収部５１０は、処理対象となる定期収集イベントがクライアント機１２０が省電力状態でも収集するイベント（表１の３列目の項目が「Ｙｅｓ」）であると判定した場合（Ｓ８０４でＹｅｓの場合）、Ｓ８０６に処理を進める。
Ｓ８０６において、イベント回収部５１０は、電源制御部５０４の省電力復帰タイマーを利用し、上記Ｓ８０３で決定した次回収集時刻を登録し、Ｓ８０７に処理を進める。
【００４９】
一方、イベント回収部５１０は、処理対象となる定期収集イベントがクライアント機１２０が省電力状態でも収集するイベントでない（表１の３列目の項目が「Ｎｏ」）と判定した場合（Ｓ８０４でＮｏの場合）、Ｓ８０５に処理を進める。すなわちクライアント機１２０が省電力状態である場合にはその時点では収集しないイベントであった場合、Ｓ８０５に処理を進める。
Ｓ８０５において、イベント回収部５１０は、電源制御部５０４の通常タイマーを利用し、上記Ｓ８０３で決定した次回収集時刻を登録し、Ｓ８０７に処理を進める。
【００５０】
Ｓ８０５，Ｓ８０６のいずれかでタイマーの登録を行った後、イベント回収部５１０は、Ｓ８０７の処理を実行する。Ｓ８０７において、イベント回収部５１０は、自身が管理するＲＡＭ４０３の領域に、現在の処理対象の定期収集イベントの種別と、上記Ｓ８０３で決定した次回収集時刻を関連付けて保持し、Ｓ８０２に処理を戻し、処理対象を次の定期収集イベントに移す。
【００５１】
以上のように、クライアント機１２０では、省電力状態でも収集する定期収集イベントのデータの送信タイミングについては省電力復帰タイマーにより管理するよう制御する。また、省電力状態では収集しない定期収集イベントのデータの送信タイミングについては通常タイマーにより管理するよう制御する。これにより、定期収集イベントごとに、クライアント機器１０２の内部でデータを収集して外部システムである管理サーバ１１０に送信するタイミングを適切に管理することが可能となる。
【００５２】
図９は、本実施形態における定期収集イベントの収集時に行われる処理の流れの一例を示すフローチャートである。本フローチャートに相当する処理は、クライアント機１２０の起動時に、ＲＡＭ２０３に展開されたプログラムをＣＰＵ２０１が読み取り実行することにより実現される。
【００５３】
まず図９（ａ）のフローチャートから説明する。
最初に、イベント回収部５１０は、予め登録されたタイマーが発火した旨（予め登録されたタイマー日時となった旨）の通知を電源制御部５０４から受信すると（Ｓ９０１）、Ｓ９０２に処理を進める。なお、このタイマーは、図８のフローチャートにおいて、イベント回収部５１０がＳ８０５もしくはＳ８０６で登録したタイマーに対応する。
【００５４】
Ｓ９０２において、イベント回収部５１０は、最初に現在時刻を取得する。さらに、Ｓ９０３において、イベント回収部５１０は、上記Ｓ９０２で取得した現在時刻をもとに、収集すべき定期取得イベントの内容を決定する。具体的には、イベント回収部５１０は、図８のＳ８０７で自身が管理するＲＡＭ４０３の領域に予め保持しておいた次回収集時刻及び定期収集イベントの種別と、上記Ｓ９０２で取得した現在時刻を照合し、表１に記載のどの定期収集イベントを収集すべきかを決定する。
【００５５】
続いて、イベント回収部５１０は、上記Ｓ９０３で決定した定期取得イベントの種別と、現在時刻をもとに、一連のイベント送信の処理を行う（Ｓ９０４）。Ｓ９０４の処理の詳細は図９（ｂ）を用いて後述する。
【００５６】
上記Ｓ９０４の処理が完了すると、イベント回収部５１０は、収集したイベントの種別と送信完了時刻（処理対象となっている定期収集イベントの最終送信時刻）とを関連付けてＲＡＭ４０３の所定の領域に保持する（Ｓ９０５）。
【００５７】
最後に、イベント回収部５１０は、上記Ｓ９０４で送信したイベントの次回取得を行うために、次回収集時刻とともに適切なタイマーを登録する（Ｓ９０６）。この処理は、図８のＳ８０３〜Ｓ８０７の処理と同様であるので説明を省略する。
【００５８】
続いて、図９（ｂ）を用いて、図９（ａ）のＳ９０４の処理の詳細について説明する。
イベント回収部５１０は、受信したイベント内容に応じて予め紐づけられた情報を機器内の各モジュールから情報を収集する（Ｓ９１１）。例えば、図６に示した課金に関する機器の使用量スナップショット情報のイベントであれば、イベント回収部５１０は、各種排紙枚数を機器使用量管理部５０８から収集する。また、例えば図７に示した情報処理コントローラの使用量スナップショット情報であれば、イベント回収部５１０は、ＣＰＵ４０１、ＲＡＭ４０３、ＨＤＤ４０４の使用率等の情報を情報処理コントローラ状態管理部５０７から収集する。これらに加えて、イベント回収部５１０は、与えられた時刻情報を使って前述のＪＳＯＮのような汎用フォーマットにして正規化する。
【００５９】
その後、イベント回収部５１０は、正規化されたイベント情報をメッセージバッファ５２０に保存する（Ｓ９１２）。この時点で管理サーバ１１０への送付内容が確定される。
【００６０】
上記Ｓ９１２の書き込みを非同期に検知したイベント送付部５３０は、メッセージバッファ５２０からイベント情報を読み出し（Ｓ９１３）、管理サーバ１１０への送信動作を行う（Ｓ９１４）。ここでは、管理サーバ１１０への認証動作や通信エラー時のリトライ処理などを含めて送信完了までを実行する。イベント情報を送信された管理サーバ１１０は、受信したイベント情報をストレージに保存する。
【００６１】
以上のように、クライアント機１２０内で発生した各種事象は、適切なタイミングで、管理サーバ１１０に送信され収集される。
【００６２】
図１０は、第１実施形態におけるクライアント機１２０が省電力状態から復帰したことに対応してイベント回収部５１０が行う処理の一例を示すフローチャートである。本フローチャートに相当する処理は、ＲＡＭ２０３に展開されたプログラムをＣＰＵ２０１が読み取り実行することにより実現される。
【００６３】
まず、イベント回収部５１０は、最初に現在時刻を取得する（Ｓ１００１）。
次に、イベント回収部５１０は、収集すべき定期収集データの数だけ以降の処理（Ｓ１００３〜Ｓ１００８）を繰り返すように制御する（Ｓ１００２）。具体的には、表１に記載された各定期収集イベントを、順次処理対象のイベントとして、以下Ｓ１００３〜Ｓ１００８の処理を行う。
【００６４】
まず、イベント回収部５１０は、処理対象となる定期収集イベントが、省電力状態でも収集するイベントであるかどうかを判断する（Ｓ１００３）。具体的には、表１で示した管理テーブル内の３列目の項目が「Ｙｅｓ」であるか「Ｎｏ」であるかを確認する。
【００６５】
イベント回収部５１０は、処理対象となる定期収集イベントがクライアント機１２０が省電力状態でも収集するイベント（表１の３列目の項目が「Ｙｅｓ」）であると判定した場合（Ｓ１００３でＹｅｓの場合）、Ｓ１００２に処理を戻し、処理対象を次の定期収集イベントに移すよう制御する。
【００６６】
一方、イベント回収部５１０は、処理対象となる定期収集イベントがクライアント機１２０が省電力状態でも収集するイベントでない（表１の３列目の項目が「Ｎｏ」）と判定した場合（Ｓ１００３でＮｏの場合）、Ｓ１１０４に処理を進める。すなわちクライアント機１２０が省電力状態である場合にはその時点では収集しないイベントであった場合、Ｓ１１０４に処理を進める。
Ｓ１００４において、イベント回収部５１０は、図９のＳ９０５で保持した処理対象の定期収集イベントの最終送信時刻と送信間隔を取得する。
【００６７】
続いて、イベント回収部５１０は、上記Ｓ１００４で取得した最終送信時刻と送信間隔を加算した時刻、すなわち次回の定期収集時刻が上記Ｓ１００１で取得した現在時刻を超過しているかどうかを判定する（Ｓ１００５）。
そして、まだ次回の定期収集時刻が現在時刻を超過していないと判定した場合（Ｓ１００５でＮｏの場合）、イベント回収部５１０は、Ｓ１００２に処理を戻し、処理対象を次の定期収集イベントに移す。
【００６８】
一方、すでに次回の定期収集時刻が現在時刻を超過していると判定した場合（Ｓ１００５でＹｅｓの場合）、イベント回収部５１０は、Ｓ１００６に処理を進める。
Ｓ１００６において、イベント回収部５１０は、図９（ａ）のＳ９０４（すなわち図９（ｂ））と同様にイベント送信処理を行う。
さらに、イベント回収部５１０は、最終送信時刻を更新する（Ｓ１００７）。
さらに、イベント回収部５１０は、次回の定期収集のためのタイマーを登録し（Ｓ１００８）、Ｓ１００２に処理を戻し、処理対象を次の定期収集イベントに移す。なお、上記Ｓ１００８では、電源制御部５０４の通常タイマーを利用するものとする。
【００６９】
以上のように、クライアント機１２０は、管理サーバ１１０に送出するイベントの種別によっては、クライアント機１２０が省電力状態である場合にはイベントの送出を行わず、省電力状態でない状態である場合にイベント送出を行う構成を有する。これにより、管理サーバ１１０等の外部システムに各種イベントを送出するクライアント機１２０等の画像処理装置において、消費電力の増大を抑止したり、有効性の低い情報の送出を防いだりすることができる。よって、定期的に取得するイベントログについて、イベントログの特性に応じて適切なデータ収集を行うことが可能となる。
したがって、課金関連データ等の情報に関しては省電力状態から復帰してデータ収集を行うとともに、機器の稼働時に取得することが望ましいデータは省電力状態から復帰せずに、省電力状態からの復帰時等、別のタイミングでデータ収集が行える。そのため、機器の省電力性能の向上や、有効性が低いデータが管理サーバに送信されることを抑制できる利点がある。
【００７０】
〔第２実施形態〕
上記第１実施形態では、収集する定期収集イベントの種別に応じて、省電力状態から復帰してデータ収集を行うかどうかを切り替え可能な構成について説明した。加えて、省電力状態から復帰しない定期収集イベントに関しては、省電力状態からの復帰時等にデータ収集を行うことにより、機器の省電力性能の向上や、有効性が低いデータが管理サーバに送信されることを抑制できる利点があることを説明した。ところで、上記第１実施形態では、課金関連データ等の重要情報に関しては省電力状態から復帰してデータ収集を行うことを示した。この状況においても、省電力状態から復帰しているため、図１０に示す定期イベントの収集処理が行われる。しかし、この状況では、ユーザから印刷指示等何らかの動作指示を受け取って動作しているわけではないため、この時点で機器の稼働状況を収集する有効性が低い可能性も考えられる。以下、このような場合に対応するための実施形態について説明する。
【００７１】
以下、図１１を用いて、第２実施形態における省電力状態から復帰した際の処理について説明する。
図１１は、第２実施形態におけるクライアント機１２０が省電力状態から復帰したことに対応してイベント回収部５１０が行う処理の一例を示すフローチャートである。本フローチャートに相当する処理は、ＲＡＭ２０３に展開されたプログラムをＣＰＵ２０１が読み取り実行することにより実現される。
なお、図１１は第１実施形態における図１０に相当するものである。
【００７２】
まず、イベント回収部５１０は、省電力状態から復帰したことを検知すると、最初に何の要因で省電力状態から復帰したかを確認する（Ｓ１１０１）。具体的には、電源制御部５０４に省電力状態から復帰した要因を問い合わせる。
【００７３】
そして、印刷指示等のユーザからの何らかの指示（ユーザ指示）に基づいて省電力状態から復帰したと判定した場合（Ｓ１１０１で「ユーザ指示」の場合）、イベント回収部５１０は、Ｓ１１０２〜Ｓ１１０９の処理を行う。なお、Ｓ１１０２〜Ｓ１１０９の処理は、図１０のＳ１００１〜Ｓ１００８の処理と同様の処理であり、必要に応じて省電力状態中に収集するはずだった定期取得イベントの収集を行う。
【００７４】
一方、定期収集イベントの収集のために省電力状態から復帰したと判定した場合（Ｓ１１０１で「定期収集イベントの収集のため」の場合）、イベント回収部５１０は、本フローチャートの処理を終了する。
【００７５】
以上のように、省電力状態から復帰した際に、定期収集イベントの収集のために省電力状態から復帰した場合のように、データ収集を行っても有効でない状況であると判断した場合には、機器の稼働状況を収集せずにしないでおくように構成する。これにより、有効性が低いデータが管理サーバ１１０に送信されることを抑制することができる。
【００７６】
〔第３実施形態〕
上記第１実施形態、第２実施形態では、情報処理コントローラユニット３０１の使用量スナップショット情報等、省電力状態から復帰しない定期収集イベントに関して、省電力状態からの復帰時のタイミングでデータ収集要否判断を行うことにより、適切にデータ収集が行えることを示した。
ところで、情報処理コントローラユニット３０１の使用量スナップショット情報のような単一のイベントの中に、重要度の異なるデータが混在する場合がある。このような場合には、収集するタイミングに依存して収集するデータの内容を切り替えることが有効である場合が考えられる。本実施形態ではこのような場合の処理について説明する。
【００７７】
上述した情報処理コントローラユニット３０１の使用量スナップショット情報のように、定期的に送信するデータの中には、省電力状態からの復帰直後などのように、装置が通常稼働している状態ではない状態で送信しても、あまり意味を成さないデータが含まれている場合がある。
例えば、情報処理コントローラユニット３０１の使用量スナップショット情報の場合、ＣＰＵ利用率やメモリ使用量は、機器の状態に大きく影響を受ける。また、省電力復帰時には、通常状態では行われない様々な特殊処理が行われる。このため、省電力復帰直後のＣＰＵ利用率やメモリ使用量のデータを、管理サーバ１１０に送信しても、あまり意味を成さないと考えられる。一方、ストレージに関しては不揮発デバイスであり、省電力復帰処理からも大きな影響を受けない。このため、省電力復帰時に、ストレージの使用量を管理サーバ１１０に送信することには一定の意義があると考えられる。
【００７８】
そこで、例えば、通常通電状態で、情報処理コントローラの使用量スナップショット情報の定期収集タイミングとなった場合、ＣＰＵ利用率やメモリ使用量及びストレージの使用量に関するデータを送信する。一方、省電力状態で、情報処理コントローラの使用量スナップショット情報の定期収集タイミングとなった場合、その後に省電力状態から復帰した際、ストレージの使用量に関する情報のみを送信するように構成する。以下、詳細に説明する。
【００７９】
図１２は、第３実施形態において省電力状態から復帰した際に収集する（図１０のＳ１００６もしくは図１１のＳ１１０７で収集する）イベント情報の一例を示す図である。
本イベント情報は、図７と同様に、情報処理コントローラユニット３０１の使用量スナップショット情報の収集に関するイベント情報であり、そのことを“info_controller_usage_snapshotted”属性により示している。なお、以下の点が図７と異なる。
【００８０】
図７に示したイベントの一例では、ＣＰＵ４０１、ＲＡＭ４０３、ＨＤＤ４０４の使用量に関するデータが含まれていたが、ここではＨＤＤ４０４の使用量（“HDD_usage”属性）のみが付加情報として記載されている。さらに、ＨＤＤ４０４の使用量の情報についても、ＨＤＤ４０４の寿命に関する情報（“device_life_rate”属性）のみが記載された形になっている。
【００８１】
これは、ＨＤＤ４０４の寿命に関する情報が、機器を使用する上で情報な重要な情報であるからである。例えば、“device_life_rate”属性が「１００」である場合、ＨＤＤ４０４の製造時に想定された想定寿命に達したということを表す。このため、交換を行わずに使用を続けると寿命により使用不能となる可能性がある。また、一般的にＨＤＤ４０４の寿命は少なくとも年単位で設定されていることが多く、数時間から数日程度取得タイミングが変化しても本データの有効性は変化しないことが想定される。このため、ＨＤＤ４０４の寿命に関する情報の定期収集イベントを、省電力状態から復帰しない定期収集イベントとしても問題はない。しかし、ＨＤＤ４０４の寿命に関する情報は重要な情報であるから、省電力状態から復帰した際には送信する。
【００８２】
本実施形態では、例えば、通常通電状態で、情報処理コントローラの使用量スナップショット情報の定期収集タイミングとなった場合、図７のように、ＣＰＵ４０１、ＲＡＭ４０３、ＨＤＤ４０４の使用量に関するデータを付加情報として収集・送信する。一方、省電力状態で、情報処理コントローラの使用量スナップショット情報の定期収集タイミングとなった場合、その後に省電力状態から復帰した際、図１２のように、ＨＤＤ４０４の使用量の情報であってＨＤＤ４０４の寿命に関する情報（“device_life_rate”属性）のみを付加情報として収集・送信する。
【００８３】
なお、図１２に示すイベント情報では、省電力状態からの復帰時に一部の情報のみを取得したことを判別可能とするために、本情報が省電力状態からの復帰時に取得したことを示す情報（“snapshotted_on_wake_up”属性）を付与している。このように構成することにより、管理サーバ１１０においても、“snapshotted_on_wake_up”属性の有無のみを確認することで、どのような内容の情報が含まれているかを容易に確認することが可能となる。
【００８４】
以上のように、本実施形態によれば、収集タイミングに応じて送信するデータの内容を適切に切り替えることで、有効性が低いデータが管理サーバ１１０に送信されることを抑制することができる。
【００８５】
以上、各実施形態では、外部システム（管理サーバ１１０）に送出するイベントの種別によっては、画像処理装置（クライアント機１２０）が省電力状態の場合にはイベントの送出を制限し、省電力状態でない場合にはイベント送出を行う構成を有する。この構成により、外部システムに各種イベントを送出する画像処理装置にて、定期的に収集・送信するイベントログの特性に応じて適切なデータを収集・送信することができ、消費電力の増大を抑止したり、有効性の低い情報の送出を抑えたりすることができる。
したがって、消費電力の増大を抑えつつ、装置の内部で収集されるデータをその特性に応じて適切に外部システムに送信でき、各種保守作業や改善、その他処理を適切に行うことが可能となる。よって、画像処理装置を適切に管理することが可能となる。
【００８６】
なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能である。具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
また、上記各実施形態を組み合わせた構成も全て本発明に含まれるものである。
【００８７】
（その他の実施形態）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。
本発明は上記実施形態に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施形態の有機的な組合せを含む）が可能であり、それらを本発明の範囲から除外するものではない。即ち、上述した各実施形態及びその変形例を組み合わせた構成も全て本発明に含まれるものである。
【図１】
2020156007.tif 000004
【図２】
2020156007.tif 000005
【図３】
2020156007.tif 000006
【図４】
2020156007.tif 000007
【図５】
2020156007.tif 000008
【図６】
2020156007.tif 000009
【図７】
2020156007.tif 000010
【図８】
2020156007.tif 000011
【図９】
2020156007.tif 000012
【図１０】
2020156007.tif 000013
【図１１】
2020156007.tif 000014
【図１２】
2020156007.tif 000015