JP2010147810A - 画像処理装置、電源制御方法、電源制御プログラム、及びそのプログラムを記録した記録媒体 - Google Patents

Abstract

【課題】使用不可能な状態における無駄な消費電力を削減することができる画像処理装置、電源制御方法、電源制御プログラム、及びそのプログラムを記録した記録媒体を提供する。
【解決手段】画像処理装置１００は、当該画像処理装置１００において発生した障害に応じて、電源制御を実行するか否かを判断する実行判断手段２２と、実行判断手段２２による判断結果に基づき、電源装置をオフする電源制御実行手段２３と、を有することを特徴とする。
【選択図】図２

Description

本発明は、画像処理装置に関し、特に、電源制御を行う技術に関するものである。

近年、省エネルギー化（グリーン化とも言う）をより進める傾向が顕著になってきている。その背景には、ＣＯ２の削減など環境対策やエネルギーコスト削減などが、企業内で積極的に取り組まれるようになったことが挙げられる。

そのため、画像処理装置は、例えばエネルギースター（Energy Star）などの消費電力基準を満たすように設計され、さらに、電力消費量を低減するために、例えば特許文献１に開示されるような電源制御機能を有している。

特許文献１には、設置環境の照明光量の変化に基づいて省エネモードへの移行を制御する画像処理装置が開示されている。
特開２００４−１７０４５７号公報

しかしながら、従来の電源制御では、自機の状態に応じて電源制御が行われていない。

上記特許文献１に開示される画像処理装置では、自機内部で発生したエラーにより画像処理機能を動作させることができない状態（使用不可能な状態）であっても、その間、電源をオフするなどの電源制御が行われていない。その結果、原状回復までに無駄な電力が消費されることになる。

本発明は上記従来技術の問題点を鑑み提案されたものであり、その目的とするところは、使用不可能な状態における無駄な消費電力を削減することができる画像処理装置、電源制御方法、電源制御プログラム、及びそのプログラムを記録した記録媒体を提供することにある。

上記目的を達成するため、本発明にあっては、当該画像処理装置において発生した障害に応じて、電源制御を実行するか否かを判断する実行判断手段と、前記実行判断手段による判断結果に基づき、電源装置をオフする電源制御実行手段と、を有することを要旨としている。

また、上記目的を達成するため、本発明に係る画像処理装置は、当該画像処理装置において発生したイベントに関する情報を取得する取得手段を有し、前記実行判断手段が、前記取得手段により取得した前記イベントに関する情報に基づき、前記発生した障害を特定し、電源制御を実行するか否かを判断する。

また、上記目的を達成するため、本発明に係る画像処理装置は、前記実行判断手段が、前記イベントに関する情報に含まれるエラー又は警告状態を表すエラーコードと、回復不可能なエラーコードとが、一致するか否かを判定し、判定結果が一致した場合に、前記発生した障害が回復不可能な障害であると特定する。

また、上記目的を達成するため、本発明に係る画像処理装置は、前記実行判断手段が、前記発生した障害が回復不可能な障害であると特定した場合に、前記電源装置をオフする電源制御を実行すると判断する。

このような構成によって、本発明に係る画像処理装置は、当該画像処理装置において発生したイベントから特定した障害に応じて電源制御を実行するか否かを判断し、その判断結果に基づいて、電源制御の実行（電源オフ）を指示する。

これによって、本発明に係る画像処理装置は、使用不可能な状態における無駄な消費電力を削減し、当該画像処理装置全体の電力消費量を低減することができる。

また、上記目的を達成するため、本発明に係る画像処理装置は、当該画像処理装置の状態を通知する複数の通知手段と、当該画像処理装置において発生したイベントに応じて、選択決定した通知手段により前記状態を通知するように制御する状態通知制御手段と、を有することを特徴とする。

また、上記目的を達成するため、本発明に係る画像処理装置は、前記状態通知制御手段が、さらに、前記取得手段により取得した前記イベントに関する情報に基づき、前記複数の通知手段から前記状態を通知するときに用いる通知手段を選択決定する選択決定手段を有することを特徴とする。

また、上記目的を達成するため、本発明に係る画像処理装置は、前記状態通知制御手段が、前記通知手段の識別子と、状態通知の緊急度を段階的に表す緊急レベルが割り当てられたイベントの等級値とが対応付けて設定されている制御情報を、所定の記憶領域に保持する保持手段を有し、前記選択決定手段は、前記イベントに関する情報に含まれるイベントの等級値に基づき、前記保持手段が保持する制御情報を参照し、前記等級値に割り当てられた緊急レベルを特定し、特定した緊急レベルに対応する通知手段を選択決定する。

また、上記目的を達成するため、本発明に係る画像処理装置は、前記状態通知制御手段が、前記通知手段の使用可否を判定する使用可否判定手段を有し、前記選択決定手段は、前記使用可否判定手段により使用可能と判定された通知手段を、前記状態を通知する通知手段として選択決定する。

また、上記目的を達成するため、本発明に係る画像処理装置は、前記保持手段が、状態通知の緊急度が高い緊急レベルが割り当てられたイベントの等級に、通信時のデータ量が少ない通知手段が対応付けて設定されている制御情報を保持している。

また、上記目的を達成するため、本発明に係る画像処理装置は、前記電源制御手段が、前記取得手段により取得した前記イベントに関する情報と、予め設定しておいた回復不可能なエラーに該当するイベント種とに基づき、前記電源をオフするか否かを判定する電源制御実行判定手段を有することを特徴とする。

上記目的を達成するため、本発明に係る電源制御方法は、画像処理装置における電源制御方法であって、前記画像処理装置において発生した障害に応じて、電源制御を実行するか否かを判断する実行判断手順と、前記実行判断手順による判断結果に基づき、電源装置をオフする電源制御実行手順と、を有することを特徴とする。

このような手順によって、本発明に係る電源制御方法は、当該画像処理装置において発生したイベントから特定した障害に応じて電源制御を実行するか否かを判断し、その判断結果に基づいて、電源制御の実行（電源オフ）を指示すると言う動作を実現する。

これによって、本発明に係る電源制御方法は、当該画像処理装置において発生したイベントから特定した障害に応じた電源制御が可能な環境を提供できる。

本発明によれば、発生した障害に応じて電源制御を行うことにより、使用不可能な状態における無駄な消費電力を削減可能な画像処理装置、電源制御方法、電源制御プログラム、及びそのプログラムを記録した記録媒体を提供することができる。

以下、本発明の好適な実施の形態（以下、「実施形態」という。）について、図面を用いて詳細に説明する。

［第１の実施形態］
＜ハードウェア構成＞
まず、本実施形態に係る画像処理装置１００のハードウェア構成について説明する。図１は、本実施形態に係る画像処理装置１００のハードウェア構成例を示す図である。

図１に示すように、画像処理装置１００は、操作パネル１１、外部記憶Ｉ／Ｆ１２、コントローラ１３、データ通信Ｉ／Ｆ１４、ＨＤＤ（Hard Disk Drive）１１０、スキャナ１５、及びプロッタ１６を有し、それぞれがバスで相互に接続されている。

操作パネル１１は、入力装置１０１と表示装置１０２とを有しており、入力装置１０１は、ハードウェアキーなどで構成され、当該画像処理装置１００に各操作信号を入力するのに用いられる。また、表示装置１０２は、ディスプレイなどで構成され、例えば動作条件などの画像処理動作に関する各種情報を表示する。

データ通信Ｉ／Ｆ１４は、インタフェース装置１０９を有しており、当該画像処理装置１００を、有線及び／又は無線回線などデータ通信網に接続するインタフェースである。

ＨＤＤ１１０は、当該画像処理装置１００で取り扱われる画像データなどの各種データを格納する。また、ＨＤＤ１１０は、これらの各種データを、所定のファイルシステムやＤＢ（Data Base）により管理する。

外部記憶Ｉ／Ｆ１２は、例えばＳＤメモリカード（SD Memory Card）やＵＳＢメモリ（Universal Serial Bus Memory）を含むフラッシュメモリなどの記録媒体１０４を、当該画像処理装置１００に接続するためのインタフェースである。この外部記憶Ｉ／Ｆ１２によって、当該画像処理装置１００と記録媒体１０４との間でデータのやり取りが行える。例えば、記録媒体１０４は、アプリケーションプログラムなどをインストールするときに利用する。

コントローラ１３は、ＲＯＭ（Read Only Memory）１０５、ＲＡＭ（Random Access Memory）１０６、ＮＶ−ＲＡＭ（Non Volatile RAM）１０７、及びＣＰＵ（Central Processing Unit）１０８を有している。

ＲＯＭ１０５は、当該画像処理装置１００全体を制御する基本ソフトウェアやアプリケーションソフトウェアなどの各種プログラム及びデータを格納する。また、ＲＡＭ１０６は、ＲＯＭ１０５やＨＤＤ１１０から読み出されたプログラムやデータを一時保持する。ＮＶ−ＲＡＭ１０７は、画像形成動作を制御するための初期設定値などのデータを格納する。さらにＣＰＵ１０８は、ＲＡＭ１０６上に読み出されたプログラムを実行する。コントローラ１３は、上記構成により、ＲＯＭ１０５からＲＡＭ１０６上に読み出された基本ソフトウェアプログラムをＣＰＵ１０８により実行し、当該画像処理装置１００全体を制御する。

スキャナ１５は、画像読取装置１１１を有し、読み取り面上の原稿を光学的に読み取り画像データを生成する。プロッタ１６は、タンデム方式の印刷装置１１２を有し、例えば電子写真方式によって、コントローラ１３から転送されたビットマップイメージを用紙に印刷する。なお、画像形成方式については、電子写真方式に限らない。

また、ファクシミリ（非図示）は、上記プロッタ１６及び上記データ通信Ｉ／Ｆ１４により実現される。ファクシミリは、データ通信Ｉ／Ｆ１４によりファックスデータを受信し、プロッタ１６により受信データを印刷する。

電源装置（非図示）は、上記ハードウェアに対して所定の電力を供給する装置である。なお、電源装置は、当該画像処理装置１００に備えられていてもよいし、当該画像処理装置１００に外部から電力供給を行う構成であってもよい。

このように、本実施形態に係る画像処理装置１００では、コントローラ１３のＲＡＭ１０６に読み出された所定のプログラムがＣＰＵ１０８で実行され、当該装置が備える各インタフェースから入力されたデータに対して要求された画像処理を行う。

なお、上記ハードウェア構成は、本実施形態に係る画像処理装置１００が複合機（ＭＦＰ：Multifunction Peripheral）である場合の例である。本実施形態に係る画像処理装置１００は、複合機以外にも、プリンタ、ファクシミリ、スキャナと言った装置も含まれる。ただし、以降の説明では、便宜上、複合機を例に挙げる。

＜電源制御機能＞
ここからは、本実施形態に係る画像処理装置１００が有する電源制御機能について詳しく説明する。

本実施形態に係る画像処理装置１００では、当該画像処理装置１００において発生したイベントから特定した障害に応じて、電源制御を実行するか否かを判断し、判断結果に基づき、電源制御の実行（電源のオフ）を指示する。このような電源制御機能を有している。

画像処理装置１００の状態には、発生した障害により、画像処理機能が使用不可能な場合がある。このような場合、画像処理装置１００には、障害対応され使用可能な状態に復帰するまで（原状回復するまで）、電力を必要としない。

そこで、本実施形態に係る画像処理装置１００では、当該画像処理装置１００で発生した障害に応じて電源制御を行い、原状回復までの消費電力を削減する。

これによって、画像処理装置１００全体の電力消費量を低減ことができる。

では、上記電源制御機能の構成とその動作について説明する。

《機能構成》
図２は、本実施形態に係る画像処理装置が有する機能の構成例を示す図である。図２に示すように、画像処理装置１００では、イベント情報取得部２１、電源制御実行判断部２２、及び電源制御実行部２３を含む電源制御部２０を有している。

このように、本実施形態に係る電源制御機能は、上記各機能部が連係動作することにより実現される。

（イベント情報の取得）
イベント情報取得部２１は、当該画像処理装置１００において発生する各種イベントに関する情報（以下、「イベント情報」と言う。）４１を取得する機能部である。イベント情報取得部２１は、ＳＮＭＰ（Simple Network Management Protocol）を用いて、当該画像処理装置１００が備える各種ハードウェアに対してポーリング処理を行い、イベント情報４１を取得する。具体的には、ＳＮＭＰのコマンドを用いてハードウェアが有するprtAlertTable情報を取得することにより、エラー又は警告状態などのイベントが発生していないかを調べる。

図３は、本実施形態に係るソフトウェア構成例を示す図である。画像処理装置１００では、例えば図３に示すようなソフトウェア構成により、電源制御部２０を実装できる。

電源制御部２０を実現するプログラム（ソフトウェア部品）は、Ｊａｖａ（登録商標）アプリケーションプログラムである。

上記プログラムは、Ｊａｖａ（登録商標）アプリケーションの開発をする際に必要となる、ライブラリ、各種サンプル、ツール、ドキュメントなどで構成されたソフトウェア開発者向けのキットであるＳＤＫＪ（Software Development Kit for Java）６２上に実装される。また、ＳＤＫＪ６２は、Ｊａｖａ（登録商標）バイトコードをプラットフォームＰＦのネイティブコード（実行可能なコード）に変換して実行するソフトウェアであるＪａｖａ（登録商標）ＶＭ（Java Virtual Machine）６１上に実装されている。また、Ｊａｖａ（登録商標）ＶＭ（Java Virtual Machine）６１は、画像処理装置１００が搭載するプラットフォームＰＦ上に実装される。

なお、上記プラットフォームＰＦは、コントロールサービス（ＣＳ：Control Service）、システムリソースマネージャ（ＳＲＭ：System Resource Manager）、及びＯＳ（Operating System）などを含む。コントロールサービスは、アプリケーションからの処理要求を解釈してハードウェア資源の獲得要求（例えば「メモリの確保」など）を発生させる。システムリソースマネージャは、１つ又は複数のハードウェア資源の管理を行い、コントロールサービスからの獲得要求を調停する。

また、ソフトウェア構成は、上記構成に限らず、ＳＤＫＪ６２を含まない構成であってもよい。ただし、以降の説明では、便宜上、電源制御部２０を実現するプログラムがＳＤＫＪ６２上に実装される構成を例に挙げる。

画像処理装置１００では、上記ソフトウェア構成により、電源制御部２０を実現するプログラムが、当該画像処理装置１００が備える各種ハードウェア７１と、ＳＮＭＰを用いたデータ処理を行うことができる。つまり、電源制御部２０がＳＮＭＰマネージャ機能を有し、一方、ハードウェア７１がＳＮＭＰエージェント機能を有する。

イベント情報取得部２１は、上記ＳＮＭＰマネージャ・エージェント機能により、当該画像処理装置１００が備えるハードウェア７１において発生したエラー又は警告情報を含む各種イベント情報４１を取得する。

エージェントは、当該画像処理装置１００の状態を外部に知らせるために公開する情報を保持している。この情報のことを、ＭＩＢ（Management Information Base）と言う。ＭＩＢは木構造のデータ構造をしており、全てのノードが一意に番号付けされている。このノードの識別子のことを、オブジェクト識別子（OBJECT IDENTIFIER）と言う。

このＭＩＢの構造は、管理情報構造（ＳＭＩ：Structure of Management Information）と言い、ＲＦＣ１１５５ Structure and Identification of Management Information for TCP/IP-based Internetsで規定されている。

前述したエラー又は警告状態は、ハードウェア７１においてそれぞれ固有のコードが割り当てられている。さらに、ハードウェア７１が有するＭＩＢのあるオブジェクトは、ハードウェア７１でエラー又は警告状態が発生すると、それに割り当てられたコードの値、又はその重要度を表す値を持つようになっている。

例えば、Ｐｒｉｎｔｅｒ ＭＩＢ（ＲＣＦ １７５９）で定義されているprtAlertTable情報は、各エントリが１つのエラー又は警告状態に対応しており、それぞれ「prtAlertSeverityLevel」、「prtAlertLocation」などのオブジェクトのインスタンスを持つよう定義されている。複数のエラー又は警告状態が発生している場合は、prtAlertTable情報は複数のエントリを持つ。

当該画像処理装置１００が備えるプロッタ１６のエージェントは、prtAlertTable情報をサポートしており、prtAlertLocationには、各エラー又は警告状態に対応するコードが設定されている。また、prtAlertSeverityLevelは、プリンタアラート（イベント）ごとの等級を表す値であり、Ｐｒｉｎｔｅｒ ＭＩＢでは、エラー「critical（３）」、警告「warning（４）」、及びその他「other（１）」が設定されている。

例えば、プロッタ１６で実際にエラー又は警告状態が発生すると、エージェントが、prtAlertTable情報にエントリを追加し、追加したエントリ中の「prtAlertSeverityLevel」、「prtAlertLocation」などの各インスタンスに状態に応じた値を持たせる。

よって、イベント情報取得部２１は、エラー又は警告状態を含む各種イベント情報４１として、上記prtAlertTable情報に定義される値（設定値）を取得する。

イベント情報取得部２１によるprtAlertTable情報の取得方法についての詳細は、以下の通りである。

ＳＮＭＰには、以下に挙げるコマンドがある。

"GetRequest"及び"GetNextRequest"は、マネージャがエージェントのＭＩＢオブジェクトの値を取得するために、エージェントに対して送出するコマンドである。このコマンドを受け取ったエージェントは、マネージャにレスポンスすることによりＭＩＢオブジェクトの値を知らせる。

"SetRequest"は、マネージャがエージェントのＭＩＢオブジェクトの値を設定するために、エージェントに対して送出するコマンドである。このコマンドを受け取ったエージェントは、設定結果をマネージャに通知するために、マネージャにレスポンスする。

"Trap"は、エージェントが、当該画像処理装置１００の状態変化をマネージャに対して通知するために、エージェントがマネージャに対して送出するコマンドである。特に、原状回復が不可能なエラーの場合には、エージェントが"Trap"によりマネージャへ通知する。

このように、イベント情報取得部２１は、"GetRequest"や"GetNextRequest"などのＧｅｔコマンドを用いて、エージェントにprtAlertTable情報の設定値を問い合わせ、レスポンスを受信する。これにより、イベント情報取得部２１は、各種イベント情報４１としてprtAlertTable情報を取得することができる。

なお、上記イベント情報４１の取得については、Ｇｅｔコマンドを用いた情報取得（例えば「ポーリング処理による取得」など）以外に、"Trap"によるエージェントからの通知を受信することで取得する方法であってもよい。

（電源制御の実行判断）
電源制御実行判断部２２は、発生したイベントから特定した障害に応じて当該画像処理装置１００の電源をオフするか否かを判断する機能部である。電源制御実行判断部２２は、まず、取得したイベント情報４１に基づき、障害を特定する。その結果、障害が、回復不可能な障害（例えば「サービス担当者でなければ原状回復させることが困難なエラー」など）と特定された場合に、当該画像処理装置１００の電源をオフすると判断する。

上述したように、イベント情報取得部２１により取得したprtAlertTable情報のprtAlertLocationの値には、エラー又は警告状態に対応するコードが設定されている。よって、電源制御実行判断部２２は、予め設定しておいた回復不可能な障害とみなすエラーコード（判定基準値）と、上記取得したコード（設定値）とが一致するか否かを判定する。その判定結果に基づき、障害を特定する。

例えば、本実施形態では、「トナーエンド（Empty：XXX Toner）」、「廃トナー満杯（Full：Waste Toner）」、及び「サービスコール（Call Service Center）」などのエラーに対応するコードを、上記回復不可能な障害とみなす判定基準値としている。

一方、電源制御実行判断部２２は、特定された障害が、回復不可能以外の障害の場合（判定基準値と異なるコードであった場合）には、当該画像処理装置１００の電源をオフしなくてもよいと判断する。

電源制御実行判断部２２は、上記判断結果に基づき、当該画像処理装置１００の電源をオフすると判断した場合に、後述する電源制御実行２３へ実行要求を行う。

（電源制御）
電源制御実行部２３は、実行要求に応じて当該画像処理装置１００の電源をオフする機能部である。電源制御実行部２３は、電源制御実行判断部２２からの電源制御実行要求（電源オフの要求）を受け付けると、要求に従って、当該画像処理装置１００が備える電源装置（非図示）に対して電源のオフを指示する。

上述したように、電源制御部２０を実現するプログラムは、エージェントに対し、"SetRequest"などのＳＮＭＰのＳｅｔコマンドを用いて、新たなＭＩＢオブジェクト値の設定を指示することができる。

よって、電源制御実行部２３では、上記設定方法により、当該画像処理装置１００が備える電源装置（非図示）に対して電源をオフする制御値（新たなＭＩＢオブジェクト値）を設定し、電源制御の実行を指示する。

このように、画像処理装置１００では、電源制御実行判断部２２により、イベントから特定した障害に応じて電源制御を実行するか否かを判断し、電源制御実行部２３が、電源制御実行判断部２２による判断結果に基づき電源制御の実行（電源のオフ）を指示する。これにより、原状回復までの消費電力を削減できる。

《機能動作》
ここからは、上記に説明を行った各機能部による動作について説明する。電源制御機能は、画像処理装置１００に搭載（インストール）される電源制御プログラム（ソフトウェア部品）が、ＣＰＵ１０８により格納先（例えば「ＲＯＭ１０５」など）からＲＡＭ１０６に読み出され、以下の処理が実行されることで実現される。

図４は、本実施形態に係る電源を制御する処理手順例を示すフローチャートである。

図４に示すように、画像処理装置１００は、イベント情報取得部２１により、当該画像処理装置１００において発生したエラー又は警告状態を含むイベント情報４１を取得する（ステップＳ１０１）。なお、イベント情報取得部２１は、イベントハンドラとして動作しており、イベント情報４１が受信可能な状態となっている。

イベント情報取得部２１は、イベント情報４１を取得すると（ステップＳ１０１：ＹＥＳ）、取得したイベント情報４１を電源制御実行判断部２２へ渡す。

画像処理装置１００は、電源制御実行判断部２２が、イベント情報４１に基づき、発生した障害を特定し、電源をオフするか否かを判断する（ステップＳ１０２）。このとき、電源制御実行判断部２２は、回復不可能な障害とみなす判定基準値と、イベント情報４１として取得したprtAlertTable情報のprtAlertLocationの値とが一致するか否かを判定し、発生した障害を特定する。

ステップＳ１０２において、電源をオフすると判断した場合には（ステップＳ１０２：ＹＥＳ）、電源制御実行判断部２２が、電源制御実行部２３に対して電源をオフする実行要求を行う。

画像処理装置１００は、電源制御実行部２３が、電源をオフする指示を受け付けると、まず、未処理のジョブ実行要求を一時保持しているキューを参照し、処理完了していないジョブが存在するか否かを確認する（ステップＳ１０３）。

ステップ１０３において、処理完了していないジョブ（未処理のジョブ）が存在していることが確認されると（ステップＳ１０３：ＹＥＳ）、電源制御実行部２３は、発生した障害により実行要求されたジョブが処理不可能か否かを判定する（ステップＳ１０４）。

ステップＳ１０４において、処理不可能と判定された場合には（ステップＳ１０４：ＹＥＳ）、電源制御実行部２３が、ジョブキャンセルを要求する（ステップＳ１０５）。

一方、ステップＳ１０４において、処理可能と判定された場合には（ステップＳ１０４：ＮＯ）、電源制御実行部２３は、ジョブの処理が完了するまで待つ。

電源制御実行部２３は、このようにして、キューに保持されている全てのジョブの処理が完了又はキャンセルされるまで、電源制御の実行を待つ。

また、ステップＳ１０３において、全てのジョブについて処理が完了又はキャンセルされたことが確認されると（ステップＳ１０３：ＮＯ）、電源制御実行部２３は、当該画像処理装置１００が備える電源装置（非図示）に対して電源をオフする制御値を設定し、電源制御の実行を指示する（ステップＳ１０６）。

＜まとめ＞
以上のように、本実施形態に係る画像処理装置１００は、発生した障害に応じて電源制御を行う。

これにより、画像処理装置１００は、使用不可能な状態における無駄な消費電力を削減し、当該画像処理装置１００全体の電力消費量を低減することができる。

［第２の実施形態］
第１の実施形態では、画像処理装置が使用不可能な状態となった場合に、電源がオフされる。このような電源制御を行う場合、機器管理者やサービス担当者へ、電源装置（非図示）の状態情報（以下、「電源状態」と言う。）を含む機器状態を通知し、迅速な障害対応を促す必要がある。

そこで、本実施形態では、障害に応じて電源制御を行い、さらに、電源制御と連係して機器状態を通知する機能を有する画像処理装置について説明する。なお、本実施形態では、第１の実施形態と同じ事項について同一の符号を付し、その説明は便宜省略する。

＜状態通知機能＞
本実施形態に係る画像処理装置１００が有する状態通知機能について詳しく説明する。

本実施形態に係る画像処理装置１００では、複数の通知手段の中から、当該画像処理装置１００において発生したイベントに応じて、通知する際に用いる通知手段を選択決定する。また、選択決定された通知手段により、電源状態を含む機器状態を通知する。このような状態通知機能を有している。

電源をオフする場合には、オフする前に、電源状態を含む機器状態を通知する必要がある。

そこで、本実施形態に係る画像処理装置１００では、電源制御部２０から電源をオフする旨を受け取り、さらに通知が完了した旨を電源制御部２０へ応答する。つまり、電源制御部２０は、状態通知機能からの通知完了応答を受け付けるまで、電源をオフしないように制御される。

また、画像処理装置１００の状態通知には、保守・運用上、緊急度の低いジョブレポートやアクセスレポートなどの履歴情報から当該画像処理装置１００において発生した緊急度の高いエラー情報などが含まれる。

そこで、本実施形態に係る画像処理装置１００では、発生したイベントの緊急度に応じて通知手段を変更するように制御する。

これによって、機器管理者やサービス担当者などが、電源制御後の保守・運用を迅速に行えるように支援することができる。

では、上記状態通知機能の構成とその動作について説明する。

《機能構成》
図５は、本実施形態に係る状態通知機能の構成例を示す図である。図５に示すように、画像処理装置１００では、電源制御機能を実現する電源制御部２０と、状態通知機能を実現する通知制御部３０との２つの機能部を有している。

通知制御部３０は、通知手段選択部３１、通知部３２、及び制御情報保持部３３を有している。

このように、本実施形態に係る状態通知機能は、上記各機能部が連係動作することにより実現される。

（通知手段の選択）
通知手段選択部３１は、発生したイベントに応じて１つ又は複数の通知手段を選択決定する機能部である。このとき、通知手段選択部３１は、図６に示すような制御情報保持部３３が保持する制御情報５１を参照し、当該画像処理装置１００で発生したイベントの緊急度に応じて、状態通知の際に用いる通知手段を選択決定する。なお、制御情報保持部３３は、上記制御情報５１が保持された記憶装置（例えば「ＨＤＤ」など）の所定の記憶領域である。

図６は、本実施形態に係る状態通知の制御情報５１のデータ例を示す図である。図６に示すように、制御情報５１は、「使用通知手段」、「使用可否設定」、及び「通知判定基準設定」の各項目を含み、それぞれが対応付けられている。

「使用通知手段」は、当該画像処理装置１００が備えるデータ通信Ｉ／Ｆ１４を介して外部装置（例えば「ユーザ端末」など）へ状態を通知する際に使用する通知手段の識別情報を設定する項目である。「使用可否設定」は、通知手段の使用可否を設定する項目である。「通知判定基準設定」は、発生したイベントに対する状態通知の緊急度を判定するための基準を設定する項目である。

上記「通知判定基準設定」の項目には、イベントの等級（Severity Level）と、状態通知の緊急度を表すレベル（以下「緊急レベル」と言う）とを対応付けて設定することができる。本実施形態では、イベントの等級が４つあることから、最大４段階の緊急レベルを対応付けて設定することができる。

例えば、図６に示す制御情報５１では、等級［１］に係るイベントに最も低い緊急レベル"報告（Ｒｅｐｏｒｔ）"が割り当てられ、等級［４］、等級［３］の順に、高い緊急レベルへと段階的に割り当てられている。また、"Trap"により受信したイベントの等級には、最も高い緊急レベル"回復不可能なエラー（Ｕｎｒｅｃｏｖｅｒａｂｌｅ）"が割り当てられている（緊急レベルの高低については、図中の矢印を参照のこと）。

また、上記「通知判定基準設定」を含む各項目は、管理者を含むユーザが、当該画像処理装置１００が備える操作パネル１１や所定のツール（ブラウザなど）や所定のコマンドを用いて設定・変更を行うことができる。なお、上記「使用可否設定」の項目については、当該画像処理装置１００が備えるデータ通信Ｉ／Ｆ１４の動作状態やデータ伝送路の通信状態に応じて動的に変更・更新させることもできる。

本実施形態では、上記設定・変更方法により、制御情報５１に、予め、発生イベントに対応する緊急レベルと、緊急レベルに適した通知手段とを対応付けて設定しておく。

図７は、本実施形態に係る画像処理装置１００の動作環境例を示す図である。

図７に示すように、本実施形態に係る画像処理装置１００の動作環境には、２通りの環境が主な例として挙げられる。まず図７（Ａ）に示すような、１台又は複数のクライアントＰＣ（Personal Computer）２００（以下、単に「ＰＣ」と言う。）と、ネットワークなどの所定のデータ伝送路で相互に接続される動作環境である。

このような動作環境の場合、例えば画像処理装置１００は、接続された複数のＰＣ２００ｎに対してブロードキャスト（不特定多数へのメッセージ送信）やマルチキャスト（指定した複数の通知先へのメッセージ送信）により状態通知を行う。

次に、図７（Ｂ）に示すような、機器の状態を監視する状態監視装置３００と、ネットワークなどの所定のデータ伝送路で相互に接続される動作環境である。

このような動作環境の場合、例えば画像処理装置１００は、接続された状態監視装置３００に対してユニキャスト（指定した通知先へのメッセージ送信）により状態通知を行う。これにより、ＰＣ２００において状態監視装置３００へ状態情報の取得を要求すれば、画像処理装置１００の状態を知ることができる。

なお、上記動作環境は、状態情報の通知又は状態情報取得先の装置としてＰＣ２００や状態監視装置３００の一例を挙げたが、この限りでない。例えば、各種サーバやモバイル端末（例えば「ＰＤＡ（Personal Digital Assistant）」や「携帯電話」など）を含む任意の情報処理装置であってもよい。

（Ａ）に示す動作環境は、通知先が多いことから、画像処理装置１００の状態をユーザが迅速に知ることができるが、通知時の総データ量が多くなり通信負荷がかかる。また（Ｂ）に示す動作環境は、通知先が限定されていることから、通信負荷を軽減できるが、ユーザが機器状態を迅速に知ることができない。

このようなことから、緊急度の高い通知内容については、状態通知の迅速性を優先し、データ量が限定された送信メッセージを用いてブロードキャストやマルチキャストにより状態通知を行うのが望ましい。一方、緊急度の低い通知内容については、通知時のデータ量を優先し、ユニキャストにより通知先を限定し、詳細な状態通知を行うのが望ましい。

よって、制御情報５１の設定では、上記点を考慮して通知手段を設定しておく。

これにより、通知手段選択部３１は、イベント情報取得部２１により取得されたイベント情報４１に基づき、上記制御情報５１から緊急レベルを特定し、特定した緊急レベルに対応する最適な通知手段を選択決定することができる。具体的には、イベント情報４１として取得したprtAlertTable情報のprtAlertSeverityLevelの値に基づき、制御情報５１の「通知判定基準設定」に定義された緊急レベルを特定する。続いて、特定した緊急レベルに対応付けられた通知手段を、状態通知の際に用いる通知手段として選択決定する。

例えば、prtAlertSeverityLevelの値が［４］の場合に、図６に示す制御情報５１を参照すると、２段階目の緊急レベル"警告（Ｗａｒｎｉｎｇ）"が設定されている「通知判定基準設定」の項目が特定される。続いて、特定された「通知判定基準設定」に対応付けられた「使用可否設定」及び「使用通知手段」の各項目を参照し、使用可能なＥｍａｉｌ（電子メール）が通知手段として選択決定される。

また、prtAlertSeverityLevelの値が［３］の場合に、図６に示す制御情報５１を参照すると、３段階目の緊急レベル"エラー（Ｃｒｉｔｉｃａｌ）"が設定されている「通知判定基準設定」の項目が特定される。続いて、特定された「通知判定基準設定」に対応付けられた「使用可否設定」及び「使用通知手段」の各項目を参照し、ＳＭＳ（Short Message Service）及びＮｅｔｓｅｎｄの２つの通知手段のうち、使用可能なＳＭＳが通知手段として選択決定される。このように、「使用可否設定」の項目に"使用不可能（Ｄｉｓａｂｌｅ）"が設定されている通知手段は、選択対象から外される。

また、通知手段選択部３１は、上記選択決定の際、発生したイベントの緊急レベルに対応する全ての通知手段が使用不可能で選択決定できなかった場合に、次に緊急度の高いレベル（次の段階にあたる緊急レベル）に対応付けられた使用可能な通知手段を選択決定する。なお、最も高い緊急レベルに対応する全ての通知手段が使用不可能な場合には、次に緊急度の低いレベルに対応付けられた使用可能な通知手段を選択決定する。

また、通知手段選択部３１は、制御情報５１において、「通知判定基準設定」に複数の通知手段が対応付けて設定され、かつ、各通知手段の使用が可能であった場合には、最大、設定された数の通知手段を、状態通知の際に用いる通知手段として選択決定する。つまり、制御情報５１の設定によっては、複数の通知手段を選択決定することになる。

このように、画像処理装置１００では、通知手段選択部３１が、通知内容の緊急度と通知時の通信負荷軽減とを考慮し設定された制御情報５１を参照し、複数の通知手段の中から、緊急レベルに適した使用可能な通知手段を選択決定することができる。

なお、上記制御情報５１は、次に示す方法によって、「使用通知手段」の設定内容を動的に変更してもよい。

（制御情報における通知手段に関する設定の動的な変更）
画像処理装置１００は、当該画像処理装置１００が備えるデータ通信Ｉ／Ｆ１４やネットワーク制御機器などのデータ通信に係るトラフィック情報を、ＳＮＭＰのコマンドを用いて取得することができる。

そこで、画像処理装置１００は、トラフィック情報を取得し、取得した情報に基づいて、現在の通信負荷を判断し、制御情報５１の設定内容を変更する。

例えば、通信に負荷がかかっていると判断した場合には、制御情報５１に設定される「使用通知手段」の項目を、通信時のデータ量が少ない通知手段に変更する。具体的には、ＥｍａｉｌからＳＭＳに変更するなどである。

このように、画像処理装置１００では、現在の通信状況に応じて適切な通知手段を選択決定することもできる。

（状態通知）
通知部３２は、当該画像処理装置１００の状態を外部装置（例えばＰＣ２００や状態監視装置３００など）へ通知する機能部である。つまり、通知手段選択部３１による選択対象である通知手段にあたる。

本実施形態では、複数の通知部３２ｎを有している。具体的には、図５に示すように、Ｅｍａｉｌ（電子メール）により状態を通知する通知部Ａ３２ａ、ＳＭＳ（ショートメッセージサービス）により状態を通知する通知部Ｂ３２ｂ、及びＷｅｂＳｅｒｖｉｃｅ（ウェブサービス）に利用して状態を通知する通知部Ｃ３２ｃなどである。

ＥｍａｉｌやＷｅｂＳｅｒｖｉｃｅは、ＳＭＳに比べて通知時のデータ量を多く扱えることから、上述したようにユニキャストにより通知先を限定した場合（通知先を指定した場合）に用いるのが適した通知手段である。一方、ＳＭＳは、通知時のデータ量が限定されていることから、ブロードキャストやマルチキャストにより複数の通知先（不特定多数の通知先を含む）へ通知する場合に用いるのが適した通知手段である。すなわち、表示画面の大きさに制限はあるものの携帯性の高いモバイル端末（例えば「ＰＤＡ」や「携帯電話」など）に対してのメッセージ送信に適している。

なお、他の通知手段として、緊急度の低い通知内容の場合には、画像形成機能が使用可能であれば、プリンタやファクシミリなどによるレポート印刷などが一例として挙げられる。また、緊急度の高い通知内容の場合には、ＩＭ（インスタントメッセージ：Instant Message）によるメッセージ送信などが一例として挙げられる。

通知部３２は、通知手段選択部３１からの選択決定時の通知要求を受け付けると、例えば図８に示すような通知情報Ｍを通知する。

図８は、本実施形態に係る通知情報Ｍの一例を示す図である。図８に示すように、通知部３２は、機器の識別情報、機器で発生した障害情報、及び電源状態に関する情報を含む送信データを生成し、所定の通知先情報を基にデータを送信する。なお、上記通知先情報は、例えばＩＰアドレスやメールアドレスなどである。

また、通知部３２は、電源状態の通知指示として、電源制御部２０からの実行判断結果を、通知手段選択部３１から受け取ると、その判断結果に基づき、電源状態を含む送信データを生成する。

これにより、通知情報Ｍを受け取った機器管理者やサービス担当者に、電源状態を含む機器状態を確認させることができ、使用可能状態への迅速な対応を促すことができる。

通知部３２は、上記通知情報Ｍを通知すると、その通知結果を要求元の通知手段選択部３１へと応答する。

《機能動作》
ここからは、上記に説明を行った各機能部による動作について説明する。状態通知機能は、画像処理装置１００に搭載（インストール）される状態通知プログラム（ソフトウェア部品）が、ＣＰＵ１０８により格納先（例えば「ＲＯＭ１０５」など）からＲＡＭ１０６に読み出され、以下の処理が実行されることで実現される。

（状態通知）
図９は、本実施形態に係る状態通知を制御する処理手順例を示すフローチャートである。

図９に示すように、画像処理装置１００は、まず、通知手段選択部３１により、イベント情報取得部２１から取得したイベント情報４１を受け取る（ステップＳ２０１：ＹＥＳ）。続いて、通知手段選択部３１が、受け取ったイベント情報４１に含まれるイベントの等級に基づいて、制御情報保持部３５が保持する制御情報５１を参照する（ステップＳ２０２）。具体的には、イベント情報４１として取得したprtAlertTable情報のprtAlertSeverityLevelの値に基づき、制御情報５１の「通知判定基準設定」の項目を参照する。

通知手段選択部３１は、制御情報５１に設定された「通知判定基準設定」の項目から、イベントの等級に割り当てられた緊急レベルを特定し、特定した緊急レベルに対応する「使用通知手段」の項目に設定された通知手段（通知部３２）を選択決定する（ステップＳ２０３）。具体的には、prtAlertSeverityLevelの値が設定された「通知判定基準設定」の項目を特定し、特定した「通知判定基準設定」の項目に対応付けられた「使用通知手段」の制御値に基づき、該当する通知手段を選択決定する。

続いて、通知手段選択部３１は、特定した「通知判定基準設定」の項目に対応付けられた「使用可否設定」の制御値に基づき、選択決定した通知手段が、使用不可能か否かを判断する（ステップＳ２０４）。

また、ステップＳ２０４において、選択決定した通知手段を使用不可能と判断した場合には（ステップＳ２０４：ＹＥＳ）、通知手段選択部３１が、予め設定しておいたイベントの通知に関する緊急レベルの段階（緊急度）に従って、次の緊急レベル（次の段階）にあたる通知手段を選択決定する（ステップＳ２０５）。

一方、ステップＳ２０４において、使用可能と判断された場合には（ステップＳ２０４：ＮＯ）、通知手段選択部３１が、選択決定した通知手段に対応する通知部３２に、電源制御部２０から受け付けた電源制御の実行判断結果を渡し、電源状態を含む機器状態の通知を指示する（ステップＳ２０６）。

続いて、通信手段選択部３１は、電源制御部２０から受け付けた電源制御の実行判断結果に基づき、電源をオフする制御を行おうとしているか否かを判断する（ステップＳ２０７）。

ステップＳ２０７において、電源をオフする制御を行おうとしていると判断した場合には（ステップＳ２０７：ＹＥＳ）、通信手段選択部３１が電源制御部２０へ、電源制御通知部３２からの応答結果から、状態通知が完了した旨を通知する（ステップＳ２０８）。

（電源制御）
図１０は、本実施形態に係る電源を制御する処理手順例を示すフローチャートである。

図１０に示すように、本実施形態に係る電源制御処理は、図４を用いて説明した第１の実施形態に係る電源制御処理と処理手順の一部が異なる。具体的には、図１０に示すステップＳ３０３、Ｓ３０７、及びＳ３０９の各処理手順である。

以下に、異なる処理手順についてのみ説明する。

画像処理装置１００は、電源制御実行判断部２２が、イベント情報４１に基づき、発生した障害を特定し、電源をオフするか否かを判断する（ステップＳ３０２）。

ステップＳ３０２において、電源をオフすると判断した場合には（ステップＳ３０２：ＹＥＳ）、電源制御実行判断部２２が、電源制御実行部２３に対して電源をオフする実行要求を行う。さらに電源制御実行判断部２２が、上記実行判断結果（電源オフする）を通知制御部３０に渡し、電源状態を含む機器状態の通知を指示する（ステップＳ３０３）。

一方、ステップＳ３０２において、電源をオフしないと判断した場合には（ステップＳ３０２：ＮＯ）、電源制御実行判断部２２が、電源制御の実行判断結果（電源オフしない）を通知制御部３０に渡し、電源状態を含む機器状態の通知を指示する（ステップＳ３０９）。

また、画像処理装置１００は、ステップＳ３０４において、全てのジョブについて処理が完了又はキャンセルされたことが確認されると（ステップＳ３０４：ＮＯ）、電源制御実行部２３は、通知制御部３０からの通知完了の応答通知を受け付けたか否かを判定し（ステップＳ３０７）、応答通知を受け付けるまで待つ（ステップＳ３０７：ＮＯ）。

ステップＳ３０７において、応答通知を受け付けると（ステップＳ３０７：ＹＥＳ）、電源制御実行部２３は、当該画像処理装置１００が備える電源装置（非図示）に対して電源をオフする制御値を設定し、電源制御の実行を指示する（ステップＳ３０８）。

＜まとめ＞
以上のように、本実施形態に係る画像処理装置１００は、第１の実施形態と同様の効果を奏する。さらに、電源制御後の効率的な保守・運用を支援することができる。

ここまで、上記各実施形態の説明を行ってきたが、各実施形態に係る画像処理装置１００が有する「状態通知機能」又は「電源制御機能」は、図を用いて説明を行った各処理手順を、動作環境（プラットフォーム）にあったプログラミング言語でコード化し、プログラムをＣＰＵ１０８により実行することで実現される。よって、上記プログラムは、コンピュータが読み取り可能な記録媒体１０４に記憶させることができる。

また、上記プログラムは、フロッピー（登録商標）ディスク、ＣＤ（Compact Disk）、ＤＶＤ（Digital Versatile Disk）、ＳＤメモリカード、ＵＳＢメモリなどの記録媒体１０４に記憶させることによって、これらの記録媒体１０４を読み取り可能なドライブ装置（非図示）や外部記憶Ｉ／Ｆ１２を介して画像処理装置１００にインストールすることができる。また、画像処理装置１００は、データ通信Ｉ／Ｆ１４を備えていることから、電気通信回線を介してインストールすることもできる。

また、上記第２の実施形態では、制御情報５１を、画像処理装置１００が備える記憶装置（例えば「ＨＤＤ１１０」など）に保持する構成（制御情報保持部３３を有する構成）について説明を行ったが、この限りでない。例えば、ＳＤメモリカードやＵＳＢメモリなどが保持する制御情報５１を、外部記憶Ｉ／Ｆ１２を介して読み取り、通知手段を選択決定する際に用いることもできる。さらに、画像処理装置１００が備えるデータ通信Ｉ／Ｆ１４を介して、当該画像処理装置１００と所定のデータ伝送路により接続される外部装置が保持する制御情報５１を、通知手段の選択決定に用いることもできる。

また、制御情報５１を、外部ファイルとして保持する構成について説明を行ったが、この限りでない。例えば、通知手段選択部３１の機能を実現するモジュール（ソフトウェア部品）が有する構成であってもよい。この場合、各制御設定の切り換えは、上記モジュールを切り換えて行う。

最後に、上記各実施形態に挙げた形状や構成に、その他の要素との組み合わせなど、ここで示した要件に、本発明が限定されるものではない。これらの点に関しては、本発明の主旨をそこなわない範囲で変更することが可能であり、その応用形態に応じて適切に定めることができる。

本発明の第１の実施形態に係る画像処理装置のハードウェア構成例を示す図である。 本発明の第１の実施形態に係る画像処理装置が有する機能の構成例を示す図である。 本発明の第１の実施形態に係るソフトウェア構成例を示す図である。 本発明の第１の実施形態に係る電源を制御する処理手順例を示すフローチャートである。 本発明の第２の実施形態に係る画像処理装置が有する機能の構成例を示す図である。 本発明の第２の実施形態に係る状態通知の制御情報のデータ例を示す図である。 本発明の第２の実施形態に係る画像処理装置の動作環境例を示す図である。 本発明の第２の実施形態に係る通知情報の一例を示す図である。 本発明の第２の実施形態に係る状態通知を制御する処理手順例を示すフローチャートである。 本発明の第２の実施形態に係る電源を制御する処理手順例を示すフローチャートである。

符号の説明

２０ 電源制御部
２１ イベント情報取得部
２２ 電源制御実行判断部
２３ 電源制御実行部
３０ 通知制御部
３１ 通知手段選択部
３２ 通知部（ａ：Ｅｍａｉｌ，ｂ：ＳＭＳ，ｃ：ＷｅｂＳｅｒｖｉｃｅ）
３３ 制御情報保持部
４１ イベント情報
５１ 制御情報
６１ ソフトウェア（ＪａｖａＶＭ）
６２ ソフトウェア（ＳＤＫＪ）
７１ ハードウェア
１００ 画像処理装置
１１ 操作パネル
１０１ 入力装置
１０２ 表示装置
１２ 外部記憶Ｉ／Ｆ
１０４ 記録媒体
１３ コントローラ
１０５ ＲＯＭ（不揮発性の半導体メモリ）
１０６ ＲＡＭ（揮発性の半導体メモリ）
１０７ ＮＶ−ＲＡＭ（不揮発性の半導体メモリ）
１０８ ＣＰＵ（中央処理装置）
１４ データ通信Ｉ／Ｆ
１０９ インタフェース装置
１１０ ＨＤＤ（不揮発性の記憶装置）
１５ スキャナ
１１１ 画像読取装置（スキャナ装置）
１６ プロッタ
１１２ 印刷装置（プロッタ装置）
２００ クライアントＰＣ（情報処理装置）
３００ 状態監視装置（情報処理装置）
ＰＦ プラットフォーム

Claims (13)

1. 当該画像処理装置において発生した障害に応じて、電源制御を実行するか否かを判断する実行判断手段と、
   前記実行判断手段による判断結果に基づき、電源装置をオフする電源制御実行手段と、を有することを特徴とする画像処理装置。
2. 当該画像処理装置が、
   当該画像処理装置において発生したイベントに関する情報を取得する取得手段を有し、
   前記実行判断手段は、
   前記取得手段により取得した前記イベントに関する情報に基づき、前記発生した障害を特定し、電源制御を実行するか否かを判断することを特徴とする請求項１に記載の画像処理装置。
3. 前記実行判断手段は、
   前記イベントに関する情報に含まれるエラー又は警告状態を表すエラーコードと、回復不可能なエラーコードとが、一致するか否かを判定し、
   判定結果が一致した場合に、前記発生した障害が回復不可能な障害であると特定することを特徴とする請求項２に記載の画像処理装置。
4. 前記実行判断手段は、
   前記発生した障害が回復不可能な障害であると特定した場合に、
   前記電源装置をオフする電源制御を実行すると判断することを特徴とする請求項３に記載の画像処理装置。
5. 当該画像処理装置が、
   当該画像処理装置の状態を通知する複数の通知手段と、
   当該画像処理装置において発生したイベントに応じて選択決定した通知手段により前記状態を通知するように制御する状態通知制御手段と、を有することを特徴とする請求項１ないし４のいずれか一項に記載の画像処理装置。
6. 前記状態通知制御手段は、
   さらに、前記取得手段により取得した前記イベントに関する情報に基づき、前記複数の通知手段から前記状態を通知するときに用いる通知手段を選択決定する選択決定手段を有することを特徴とする請求項５に記載の画像処理装置。
7. 前記状態通知制御手段は、
   前記通知手段の識別子と、状態通知の緊急度を段階的に表す緊急レベルが割り当てられたイベントの等級値とが対応付けて設定されている制御情報を、所定の記憶領域に保持する保持手段を有し、
   前記選択決定手段は、
   前記イベントに関する情報に含まれるイベントの等級値に基づき、前記保持手段が保持する制御情報を参照し、前記等級値に割り当てられた緊急レベルを特定し、特定した緊急レベルに対応する通知手段を選択決定することを特徴とする請求項５又は６に記載の画像処理装置。
8. 前記状態通知制御手段は、
   前記通知手段の使用可否を判定する使用可否判定手段を有し、
   前記選択決定手段は、
   前記使用可否判定手段により使用可能と判定された通知手段を、前記状態を通知する通知手段として選択決定することを特徴とする請求項５ないし７のいずれか一項に記載の画像処理装置。
9. 前記保持手段は、
   状態通知の緊急度が高い緊急レベルが割り当てられたイベントの等級に、通信時のデータ量が少ない通知手段が対応付けて設定されている制御情報を保持していることを特徴とする請求項５ないし８のいずれか一項に記載の画像処理装置。
10. 前記電源制御手段は、
    前記取得手段により取得した前記イベントに関する情報と、予め設定しておいた回復不可能なエラーに該当するイベント種とに基づき、前記電源をオフするか否かを判定する電源制御実行判定手段を有することを特徴とする請求項５ないし９のいずれか一項に記載の画像処理装置。
11. 画像処理装置における電源制御方法であって、
    前記画像処理装置において発生した障害に応じて、電源制御を実行するか否かを判断する実行判断手順と、
    前記実行判断手順による判断結果に基づき、電源装置をオフする電源制御実行手順と、を有することを特徴とする電源制御方法。
12. 画像処理装置における電源制御プログラムであって、
    コンピュータを、
    前記画像処理装置において発生した障害に応じて、電源制御を実行するか否かを判断する実行判断手段と、
    前記実行判断手段による判断結果に基づき、電源装置をオフする電源制御実行手段として機能させる電源制御プログラム。
13. 請求項１２に記載のプログラムを記録した、コンピュータが読み取り可能な記録媒体。

Images