画像処理装置
【課題】リソース状態の通知を効果的に行なう画像処理装置を提供すること。
【解決手段】画像処理装置１００は、装置のリソース状態を監視して、前記リソース状態がサービスを要求する状態となったことを示す装置状態監視部２１０と、サービス要求を送付する複数の宛先アドレスについての宛先情報を記憶する宛先情報記憶部２３０と、現在時情報を管理し、前記サービスを要求する状態となった時刻を不具合発生時刻とする現在時情報管理部２２０と、装置状態監視部２１０の指令に応答し、宛先情報記憶部２３０が管理する宛先情報を、現在時情報管理部２２０が設定した不具合発生時刻を検索キーとして検索し、宛先アドレスを決定する宛先決定部２４０と、宛先決定部２４０によって決定された宛先アドレスに、サービス要求を通知するメッセージを送信するメッセージ送信部２５０とを含んでいる。
【解決手段】画像処理装置１００は、装置のリソース状態を監視して、前記リソース状態がサービスを要求する状態となったことを示す装置状態監視部２１０と、サービス要求を送付する複数の宛先アドレスについての宛先情報を記憶する宛先情報記憶部２３０と、現在時情報を管理し、前記サービスを要求する状態となった時刻を不具合発生時刻とする現在時情報管理部２２０と、装置状態監視部２１０の指令に応答し、宛先情報記憶部２３０が管理する宛先情報を、現在時情報管理部２２０が設定した不具合発生時刻を検索キーとして検索し、宛先アドレスを決定する宛先決定部２４０と、宛先決定部２４０によって決定された宛先アドレスに、サービス要求を通知するメッセージを送信するメッセージ送信部２５０とを含んでいる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク接続可能な画像処理装置のリソース管理に関する。
【背景技術】
【０００２】
従来、ネットワーク接続可能な複合機（ＭＦＰ）などにおいて、紙やトナー等の消耗品の状態や、装置の異常な状態を検知して、予め設定された特定のユーザに電子メールを使用してメッセージを通知する機能を有するものが知られている。
【０００３】
例えば、特開２００４−２４２０３８号公報には、紙、トナーの残量、感光体などのサプライ品の状態や、装置の機械的若しくはソフト的な異常の発生を監視していて、リソース状態が予め設定した条件を満足したら、外部装置に対して、電子メールによって装置のリソース状態を通知する画像入出力装置が開示されている。
【０００４】
しかしながら、当該公報記載の画像入出力装置では、予め設定されたひとつの宛先にしかメッセージを送信できないため、当該メッセージを受信するユーザが不在の場合などは、電子メールによって通知されるべき、装置のリソース状態に対する処置が迅速には行われないという不都合があった。
【特許文献１】特開２００４−２４２０３８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
本発明の目的は、画像処理装置のリソース状態の通知を、より効果的にサービス要求の通知に変換し、消耗品のサプライやメンテナンス・サービスを行うことを可能とする、画像処理装置を提供することにある。
【課題を解決するための手段】
【０００６】
本発明では、消耗品状態やデバイス状態などの装置のリソース状態を検出し、検出されたリソース状態がサービスを必要とする場合、画像処理装置の不具合が検出された時刻を使用してサービス要求通知を送信する宛先アドレスを、日付、時刻、曜日などの通知条件を検索し、変更できるように構成する。宛先アドレスは、例えば、長期休暇中や、週末、夜間時など、適切な時間情報と対応させて登録しておくことができる。
【０００７】
宛先アドレスは、電子メール・アドレスまたはＵＲＩ(Uniform Resource Identifier)とすることができる。本発明では、リソース状態の監視により不具合が発生した場合、不具合が発生した時刻を不具合発生時刻として登録し、不具合発生時刻を使用して、登録された時間情報についての範囲情報を照会して、宛先アドレスが決定される。したがって、画像処理装置に不具合が発生した時刻で、最適で最も信頼性の高い通知先に、サービス要求通知が送付できる。本発明では、画像処理装置のリソース状態を監視することにより、サービスが必要であることを通知して不具合発生時刻が取得され、取得された不具合発生時刻から最小限のタイムラグで最適なサービス要求通知の宛先アドレスが決定される。
【０００８】
このため、本発明では、リソース状態通知を最小のタイムラグでサービス要求通知に変換し、メッセージを適切な宛先アドレス宛て送信でき、サービス要求を通知するメッセージを使用して装置のリソース状態に対する処置（例えば、消耗品の補充）を行うことができる。
【０００９】
サービス要求通知の伝送方式としては、ＳＭＴＰプロトコルを使用する電子メールまたは、Ａｐａｃｈｅ、ＩＩＳ(Internet Information Service)などのサーバ・プログラムを使用したＨＴＴＰを使用するファイル伝送を使用することができる。
【００１０】
すなわち、本発明によれば、
装置のリソース状態を監視して、前記リソース状態がサービスを要求する状態となったことを示す装置状態監視部と、
サービス要求を送付する複数の宛先アドレスについての宛先情報を記憶する宛先情報記憶部と、
現在時情報を管理し、前記サービスを要求する状態となった時刻を不具合発生時刻とする現在時情報管理部と、
前記装置状態監視部の指令に応答し、前記宛先情報記憶部が管理する宛先情報を、前記現在時情報管理部が設定した不具合発生時刻を検索キーとして検索し、前記宛先アドレスを決定する宛先決定部と、
前記宛先決定部によって決定された前記宛先アドレスに、サービス要求を通知するメッセージを送信するメッセージ送信部と
を含む、画像処理装置が提供される。
【００１１】
本発明の前記宛先情報記憶部は、時間情報と前記宛先アドレスとを対応付けて管理することができる。本発明では、前記宛先情報記憶部は、リソース状態、前記時間情報、および前記宛先アドレスを対応付けて管理することができる。本発明では、前記時間情報は、日付、曜日および時刻の少なくとも１つについての設定開始値および設定終了値として管理されても良い。
【発明を実施するための最良の形態】
【００１２】
以下、本発明を図面に示した実施形態をもって説明するが、本発明は後述する実施形態に限定されるわけではない。
【００１３】
図１は、画像処理装置のハードウェア構成の実施形態を示す。図１に示す画像処理装置１００は、ＣＰＵ（Central Processing Unit）１１０と、ＲＯＭ（Read Only Memory）１２１と、ＲＡＭ（Random
Access Memory）１２２と、ＮＶＲＡＭ（Non Volatile RAM）１２３とを備えている。ＣＰＵ１１０、ＲＯＭ１２１およびＲＡＭ１２２は、画像処理装置１００の起動時初期設定を可能とし、アプリケーション・ソフトウェアをＲＡＭ１２２に読込み、アプリケーションの実行による、ＳＭＴＰプロトコルを使用する電子メールによるメッセージ伝送を可能としている。ＮＶＲＡＭ１２３は、ＣＰＵ１１０によってアクセスされる読み書き可能な不揮発性のメモリであり、画像処理装置１００が電源を落とした状態においても記憶させておきたいデータを格納する。
【００１４】
また、本実施形態では、画像処理装置１００は、操作パネル１３１と、操作パネル制御部１３２と、スキャン／プリントエンジン１４１と、エンジン制御部１４２とを備えている。操作パネル１３１は、ユーザからの入力を受付け、パネル制御部１３２に伝え、画像処理装置１００に対して各種処理を指令する。さらに、画像処理装置１００は、ハードディスク装置１５１と、ハードディスク制御部１５２とを備えており、画像処理装置１００が取得したイメージデータや宛先アドレス、その他の情報を記憶し、画像処理装置１００からの要求に応答して情報を読み出して画像処理装置１００に渡している。スキャン／プリントエンジン１４１は、イメージデータの入出力ユニットとして、紙原稿の読み取りや転写紙への印刷を行うものである。エンジン制御部１４２は、ＣＰＵ１１０からの指令に応じて、スキャン／プリントエンジン１４１の制御を行なう。
【００１５】
さらに、本実施形態では、画像処理装置１００は、ＰＳＵ（Power Supply Unit）１６１と、電源制御部１６２と、通信制御部１７１と、モデム１７２と、外部インタフェース（Ｉ／Ｆ）部１８０とを備えている。ＰＳＵ１６１、電源制御部１６２は、画像処理装置１００への電力供給を制御して、例えば通常モードから省エネモードなどへの状態遷移を管理している。また、通信制御部１７１およびモデム１７２（ＩＳＤＮ回線などの場合には、ＤＳＵ／ＴＡ）は、画像処理装置１００のファクシミリ送信やＰＰＰなどの接続プロトコルを使用する、ＳＭＴＰプロトコルによる電子メールの送信を可能としている。また、通信制御部１７１は、ネットワーク・インタフェース・カード（ＮＩＣ）などを含んで構成されていて、ＰＰＰｏＥなどの接続プロトコルを使用して、イーサネット（登録商標）などによるローカルエリア・ネットワークまたはインターネットなどの公衆ネットワークへの接続を可能としている。
【００１６】
外部Ｉ／Ｆ部１８０は、セントロニクス等のパラレルインタフェースや、ＲＳ−２３２Ｃ、ＵＳＢなどのシリアルインタフェースを介して、外部の機器との通信を可能としている。なお、上述した各機能モジュールは、それぞれ、データバス１９０を介して相互接続されていて、各種データの送受信を実行している。
【００１７】
図２は、画像処理装置１００の機能構成を示す。図２に示す実施形態では、画像処理装置１００は、装置状態監視部２１０と、カレンダー／クロック管理部２２０とを含んでいる。装置状態監視部２１０は、装置内のデバイス状態や、用紙やトナーなどのリソース状態の監視を行うものである。装置状態監視部２１０は、リソース状態対応テーブルを管理しており、デバイス状態や消耗品の消費状態についての情報を定期的に収集する。収集された画像処理装置１００のリソース状態を、リソース状態管理テーブルのエントリ項目と照合する。
【００１８】
リソース状態管理テーブルは、本実施形態では、リソース状態通知がどのような不具合に対応するのかを対応づけて管理するデータ構造であり、装置状態監視部２１０は、リソース状態の取得内容に対応する不具合を、「トナー無し（各色ごと）」、「用紙無し」、または「・・・処理部応答無し」などのテキスト・コードなどを対応させて管理している。
【００１９】
装置状態監視部２１０は、照合の結果、画像処理装置１００が管理者またはメンテナンス・セクションに通知が必要な設定状態（例えば、消耗品が設定量以下）になっていると判断した場合、その時刻を決定するため、カレンダー／クロック管理部２２０に通知する。また、他の実施形態では、当該通知は、そのために設定される共用変数値を経由して行われても良い。この場合、装置状態監視部２１０は、リソース状態がサービス要求通知を発行する状態であることを示す共用変数値を、サービス要求通知を発行させる肯定的な値に設定する。同時に本実施形態では、装置状態監視部２１０は、リソース状態に対応するテキスト・ストリングを共用変数、例えば、message_contentに登録し、後述するメッセージ送信部２５０が読出し可能とする。
【００２０】
カレンダー／クロック管理部２２０は、現在の日付、曜日、時刻など、カレンダー情報を管理する。カレンダー／クロック管理部２２０は、宛先決定部２４０からの要求に応じて、リソース状態通知を受け取った時刻として与えられる不具合発生時刻を宛先決定部２４０に渡す。なお、カレンダー／クロック管理部２２０は、Ｃ、Ｃ＋＋、ＪＡＶＡ（登録商標）などの標準ライブラリ関数を使用して構成することができる。
【００２１】
例えば、本実施形態では、カレンダー／クロック管理部２２０は、リソース状態通信号の受領を待機しており、装置状態監視部２１０からのリソース状態通知を通信パケットなどとして明示的に受付けるか、またはリソース状態通知を受付けたことを示す変数値がサービス要求通知を発行することを肯定的に示す値を格納すると判断した場合、その時点での現在時刻を不具合発生時刻として、グローバル変数として設定されるc_timeなどに取得し、取得した不具合発生時刻を以後の処理において他の処理モジュールに利用させる構成とすることができる。
【００２２】
この場合、c_timeは、asctime()関数（Ｃ＋＋の実施形態で）などを用いてコーディングすることにより、月、日、時刻、年の出力形式で出力させることができる。なお、本発明では、使用する処理プログラムに応じて、同様の機能を与えるいかなるカレンダー関数を使用することができる。
【００２３】
さらに、本実施形態の画像処理装置１００は、宛先情報記憶部２３０と、宛先決定部２４０と、メッセージ送信部２５０とを含んで構成されている。宛先情報記憶部２３０は、メッセージによって画像処理装置１００のサービス要求を通知する宛先アドレスについての情報を記憶・管理しており、宛先アドレスの追加、変更に対応して追加修正が行われる。より具体的には、宛先情報記憶部２３０は、宛先情報として、不具合発生を通知するメッセージの宛先となる複数の宛先アドレスと、各宛先アドレスを選択するための通知先条件として使用される設定範囲（例えば、時間帯、曜日範囲、日付範囲など）とを対応付けて記憶する。宛先情報記憶部２３０が記憶する宛先情報の具体例については後述する。
【００２４】
宛先決定部２４０は、装置状態監視部２１０から管理者などに通知すべき不具合状態が発生することに対応して発行されるリソース状態通知または共用変数値の更新に応答して、カレンダー／クロック管理部２２０が登録した不具合発生時刻を検索キーとして、宛先情報記憶部２３０から取得される宛先情報を検索する。宛先決定部２４０は、検索によりサービス要求を送付しなければならない宛先アドレスを決定し、決定された宛先アドレスをメッセージ送信部２５０に渡す。具体的な宛先決定方法については後述する。
【００２５】
メッセージ送信部２５０は、特定の実施形態では、メーラ・アプリケーションを含んで構成されており、宛先決定部２４０から通知される電子メールの宛先アドレスを、サービス要求を行うためのメッセージ・ファイルの宛先アドレスに記述する。さらに、不具合に対応するメッセージを適切なメモリ・アドレスから取得して、メッセージ本文を記述する箇所に記述し、画像処理装置１００を固有に識別させる送信元アドレスまたはメッセージを追加して、メッセージ・ファイルを作成し、電子メール送信を行っている。
【００２６】
また、他の実施形態では、メッセージ送信部２５０は、ＡｐａｃｈｅやＩＩＳといったプログラムを含んで構成することもでき、ＨＴＴＰ、ＦＴＰなどのファイル転送プロトコルを使用してメッセージをサーバにアップロードする。本実施形態の場合、宛先決定部２４０は、時間情報を参照して、休暇中ではないサービス・セクションや部門を指定するＵＲＩを決定する。
【００２７】
本実施形態の画像処理装置１００は、装置状態監視部２１０により、リソース状態を監視し、リソース状態に不具合が発生した時刻を不具合発生時刻として使用して、登録された宛先アドレスを検索し、決定する処理を実行する。図３は、宛先情報記憶部２３０が管理する宛先情報テーブル３００の実施形態を示す。宛先情報テーブル３００は、宛先情報が格納されるテーブルであり、宛先情報テーブル３００に格納される情報は、予め管理者やサービスマンなどによって設定することができる。
【００２８】
図３に示す実施形態では、宛先情報テーブル３００は、宛先アドレスを検索する場合の時間情報を宛先アドレスの区分ごとに対応付けて管理している。宛先情報テーブル３００は、宛先区分識別値を「Ｎｏ．」としてエントリするフィールド３００ａと、設定範囲を、「設定時刻」として登録するフィールド３００ｂと、電子メールの宛先アドレスを。「宛先」としてエントリするフィールド３００ｃとを対応付けて管理している。図３に示した実施形態では、宛先情報テーブル３００は、１日のうちの時刻（時間帯）に対応して異なる宛先アドレスが設定されている。
【００２９】
図３の実施形態では、「０９：００」〜「１７：００」の時間帯に対し、宛先アドレスとして、会社で使用する宛先アドレス「taro_company@aaa.bb.jp」が、宛先区分識別値＝Ｎｏ．１として設定されている。さらに、「１７：０１」〜「１８：５９」の時間帯および「０７：０１」〜「０８：５９」の時間帯に対しては、宛先区分識別値＝Ｎｏ．２、４で携帯端末で使用する宛先アドレス「taro_mobile@ccc.dd.jp」が設定され、「１９：００」〜「０７：００」の時間帯に対しては、宛先区分識別値＝Ｎｏ．３として自宅で使用する宛先アドレス「taro_home@eee.ff.jp」が設定されている。
【００３０】
宛先決定部２４０は、装置状態監視部２１０からリソース状態について通知を受けると、カレンダー／クロック管理部２２０から取得される不具合発生時刻（現在の時刻情報）を、宛先情報テーブル３００の設定範囲と照合する。当該照合で、不具合発生時刻が「０９：００」〜「１７：００」の間の時刻を示していると判断した場合（例えば、不具合発生時刻が「１０：００」の場合）、不具合発生の通知を行う宛先として、「taro_company@aaa.bb.jp」を選択する。また、不具合発生時刻が「１７：０１」〜「１８：５９」の間または「０７：０１」〜「０８：５９」の間の時刻を示している場合（例えば、不具合発生時刻が「１８：００」の場合）は、「taro_mobile@ccc.dd.jp」を選択する。さらに、不具合発生時刻が「１９：００」〜「０７：００」の間の時刻を示している場合（例えば、不具合発生時刻が「２０：００」の場合）は、宛先アドレスとして「taro_home@eee.ff.jp」を選択する。
【００３１】
図４は、宛先情報記憶部２３０によって保持される他の実施形態の宛先情報テーブル４００を示す。図４に示した宛先情報テーブル４００は、時間情報を１週間のうちの曜日に応じて、異なる宛先を設定することができる。図４に示す宛先情報テーブル４００は、設定された時間情報を曜日識別値（Ｎｏ．）としてエントリするフィールド４００ａと、設定範囲を「設定曜日」としてエントリするフィールド４００ｂと、宛先アドレスを「宛先」としてエントリするフィールド４００ｃとを対応付け、レコードとして管理している。本発明のさらに他の実施形態では、国民の休日とされている特定日付を別にエントリするレコードを設けて、さらに詳細に管理しても良い。
【００３２】
図４に示した例では、曜日識別値＝Ｎｏ．１の「月曜日（Mon.）」〜「金曜日(Fri.)」の期間に対して、会社で使用する電子メールの宛先アドレス「taro_company@aaa.bb.jp」が設定されている。また、曜日識別値＝Ｎｏ．２の「土曜日（Sat.）」〜「日曜日(Sun.)」の期間に対して、自宅で使用する宛先アドレス「taro_home@eee.ff.jp」が設定されている。
【００３３】
図４の実施形態では、宛先決定部２４０は、カレンダー／クロック管理部２２０から取得される不具合発生時刻（現在の曜日情報）が、「月曜日（Mon.）」〜「金曜日(Fri.)」のいずれかの曜日を示している場合（例えば、「火曜日（Tue.）」の場合）、サービス要求通知を行う宛先として、「taro_company@aaa.bb.jp」を選択し、「土曜日（Sat.）」〜「日曜日(Sun.)」のいずれかの曜日を示している場合（例えば、「日曜日（Sun.）」の場合）は、「taro_home@eee.ff.jp」を選択する。
【００３４】
図５は、宛先情報記憶部２３０によって保持される宛先情報テーブルの更に他の実施形態を示す。図５に示す実施形態では、宛先情報テーブル５００は、日付識別値を「Ｎｏ．」としてエントリするフィールド５００ａと、時間範囲として使用され、設定範囲を「設定日付」としてエントリするフィールド５００ｂと、宛先アドレスを「宛先」としてエントリするフィールド５００ｃとを、レコードとして形成し、対応付けて管理している。図４に示した実施形態の宛先情報テーブル５００では、１年のうちの日付に応じて、異なる宛先を設定することができる。
【００３５】
図５に示した例では、日付識別値＝Ｎｏ．１で「８／１２」〜「８／２０」の期間に対して、携帯端末で使用する宛先アドレス「taro_mobile@ccc.dd.jp」が設定され、それ以外の期間に対して、日付識別値＝Ｎｏ．２で会社で使用する宛先アドレス「taro_company@aaa.bb.jp」が設定がされている。
【００３６】
図４に示した実施形態では、宛先決定部２４０は、カレンダー／クロック管理部２２０から取得される不具合発生時刻（現在の日付情報）が、「８／１２」〜「８／２０」の間の日付を示している場合（例えば、「８／１３」の場合）、サービス要求通知を行う宛先として、「taro_mobile@ccc.dd.jp」を選択し、「８／１２」〜「８／２０」の間にない日付を示している場合（例えば、「９／１２」の場合）は、「taro_company@aaa.bb.jp」を選択する。
【００３７】
なお、図３および図４に示した例においても、図５の場合と同様に、「上記以外」という設定をすることで、明示的に設定された範囲以外の全ての範囲をカバーさせることができる。なお、宛先アドレスとしてＵＲＩを使用する場合、宛先情報テーブルを構成する宛先フィールドに、ＵＲＩを記述しておくことで、ＨＴＴＰやＦＴＰなどのファイル転送プロトコルを使用して、期間情報により宛先を選択することが可能となる。
【００３８】
また、上記各テーブル３００〜５００の設定を行う際に、管理者などによって設定される内容のチェックを行うようにしてもよい。設定内容のチェックは、例えば、各設定項目に指定された時間範囲に重複が生じていないか、または設定された時間範囲に不足が生じていないかをチェックして、重複や不足が生じている場合は、設定された時間範囲を、設定しなければならない時間範囲のリストと照合して、重複設定または欠落設定が識別された段階で、ビープ音を発生させることで誤設定を管理者や、サービスマンなどに警告して、再設定を行わせるようにしてもよい。
【００３９】
また、他の実施形態では設定時には設定内容のチェックは行わず、上記テーブル３００〜５００を参照して宛先を決定する際に、設定された時間範囲の重複による条件の競合などが発生した時点で、予め定められたルールにしたがって競合などを解消させるようにしてもよい。例えば、条件の競合が生じた場合は、時間、曜日または日付の順に不具合発生時刻の対応する値を比較してゆき、最初に設定範囲に一致した範囲で宛先アドレスを選択することができる。
【００４０】
また、宛先情報記憶部２３０は、上記テーブル３００〜５００のいずれかひとつを保持するようにしてもよいし、そのうちの２つ、またはすべてを保持するようにしてもよい。宛先情報記憶部２３０が複数のテーブルを保持する場合は、各テーブルに設定された条件が競合したときに、どのテーブルの設定を優先させるかを予め（例えば、フラグ設定によって）設定できるようにする。
【００４１】
上述したテーブル３００〜５００の実施形態では、時間、曜日、日付などの時間情報と、宛先とを対応付けて管理する。さらに他の実施形態では、後述するように、装置のリソース状態と、時間情報と、宛先アドレスとを対応付けて管理することもできる。また、本発明のさらに別の実施形態では、設定時刻、設定曜日、設定日付などをエントリするフィールドを、「通知条件」として構成し、設定時刻、設定曜日、設定日付などについての範囲情報を任意に含ませた宛先情報テーブルとして構成することができる。
【００４２】
図６は、宛先情報記憶部２３０によって保持される宛先情報テーブルのさらに他の実施形態を示す。図６に示す実施形態では、宛先情報テーブル６００は、宛先区分識別値を「Ｎｏ．」としてエントリするフィールド６００ａと、通知すべき不具合状態を、「装置状態」としてエントリするフィールド６００ｂと、設定範囲を「設定時刻」としてエントリするフィールド６００ｃと、電子メールの宛先アドレスを、「宛先」としてエントリするフィールド６００ｄを対応付けて管理している。図６に示す宛先情報テーブル６００は、通知すべき装置の状態および１日のうちの時刻に応じて、異なる宛先を設定することができる。
【００４３】
なお、図６に示したデータ構造を使用する場合、装置状態監視部２１０は、リソース状態対応テーブルを別に管理する必要はなく、装置状態監視部２１０は、リソース状態に不具合が発生したことを示す通知を発行するか、または不具合を発生したことを示す共用変数の値を更新する処理を実行する。
【００４４】
図６に示した実施形態の場合、装置状態監視部２１０のメッセージ取得処理は、宛先決定部２４０が実装し、メッセージ送信部２５０のメッセージ取得を可能とする構成とされる。
【００４５】
図６に示した例では、リソース状態「用紙無し」および時間帯「０９：００」〜「１７：００」の組み合わせに対して、宛先区分識別値＝Ｎｏ．１で会社で使用する電子メールの宛先アドレス「taro_company@aaa.bb.jp」が設定され、リソース状態「用紙無し」および時間帯「１７：０１」〜「１８：５９」の組み合わせであって、リソース状態「用紙無し」および時間帯「０７：０１」〜「０８：５９」の組み合わせに対して、宛先区分識別値＝Ｎｏ．２、４で携帯端末で使用する宛先アドレス「taro_mobile@ccc.dd.jp」が設定されている。さらに、リソース状態「用紙無し」および時間帯「１９：００」〜「０７：００」の組み合わせに対して、宛先区分識別値＝Ｎｏ．３で、自宅で使用する宛先アドレス「taro_home@eee.ff.jp」が設定がされる構成とされている。
【００４６】
また、リソース状態「故障」および時間帯「０９：００」〜「１７：００」の組み合わせに対して、宛先区分識別値＝Ｎｏ．５でカスタマーサービスの通常の宛先アドレス「customer_service@ddd.ee.jp」が選択され、リソース状態「故障」および時間帯「１７：０１」〜「０８：５９」の組み合わせに対して、宛先区分識別値＝Ｎｏ．６で、カスタマーサービスの緊急用の宛先アドレス「emergency_service@
ddd.ee.jp」が選択される。
【００４７】
また、リソース状態「トナー無し」および時間帯「０９：００」〜「１７：００」の組み合わせに対して、宛先区分識別値＝Ｎｏ．７のレコードにエントリされた、カスタマーサービスの通常の宛先アドレス「customer_service@ddd.ee.jp」が設定され、リソース状態「トナー無し」および時間帯「１７：０１」〜「０８：５９」の組み合わせに対して、宛先区分識別値＝Ｎｏ．８のレコードにエントリされた、カスタマーサービスの緊急用の宛先アドレス「emergency_service@
ddd.ee.jp」が設定がされている。
【００４８】
図６に示した実施形態の場合、宛先決定部２４０は、装置状態監視部２１０から通知されるリソース状態が「用紙無し」であって、カレンダー／クロック管理部２２０から取得される不具合発生時刻（現在の時刻情報）が、「０９：００」〜「１７：００」の間の時刻である場合（例えば、「１０：００」の場合）、サービス要求通知を行う宛先として、「taro_company@aaa.bb.jp」を選択し、「１７：０１」〜「１８：５９」の間または「０７：０１」〜「０８：５９」の間の時刻である場合（例えば、「１８：００」の場合）は、「taro_mobile@ccc.dd.jp」を選択し、「１９：００」〜「０７：００」の間の時刻である場合（例えば、「２０：００」の場合）は、「taro_home@eee.ff.jp」を選択する。
【００４９】
また、装置状態監視部２１０から通知されるリソース状態が「故障」であって、カレンダー／クロック管理部２２０から取得される不具合発生時刻（現在の時刻情報）が、「０９：００」〜「１７：００」の間の時刻である場合（例えば、「１３：００」の場合）、サービス要求通知を行う宛先として、「customer_service@ddd.ee.jp」を選択し、「１７：０１」〜「０８：５９」の間の時刻である場合（例えば、「１８：００」の場合）は、「emergency_service@
ddd.ee.jp」を選択する。また、装置状態監視部２１０から通知されるリソース状態が「トナー無し」であって、カレンダー／クロック管理部２２０から取得される不具合発生時刻（現在の時刻情報）が、「０９：００」〜「１７：００」の間の時刻である場合（例えば、「１６：００」の場合）、サービス要求通知を行う宛先として、「customer_service@ddd.ee.jp」を選択し、「１７：０１」〜「０８：５９」の間の時刻である場合（例えば、「２３：００」の場合）は、「emergency_service@
ddd.ee.jp」を選択する。
【００５０】
図６に示した実施形態を採用する場合、宛先決定部２４０は、装置状態フィールド６００ｂにエントリされたコードや識別値を取得し、メッセージ・リストなどを検索して対応するテキスト・ストリングを選択し、共用変数message_contentに記述する。その後、メッセージ送信部２５０は、message_contentに記述された値を読出し、電子メールを送信するメーラのメッセージ記述箇所に追加し、宛先アドレスを、送信先アドレスを記述する部分に記述する。さらに、メッセージ送信部２５０は、送信元アドレスまたはメッセージ記述箇所中に画像処理装置１００を固有に識別することが可能な装置識別値を記述して、メッセージ・ファイルを作成する。
【００５１】
また、他の実施形態では、フィールド６００ｂに直接「用紙無し」、「故障」、「トナー（Ｂｋ）無し」などのテキスト・コートをエントリさせておくことができる。当該実施形態では、宛先決定部２４０は、取得したテキスト・ストリングを共用変数message_contentに登録するか、または通信パケットを作成し、メッセージ送信部２５０に通知しても良い。
【００５２】
上述した処理を終了した後、メッセージ送信部２５０は、モデムまたはＤＳＵ／ＴＡなどを起動し、ＰＰＰプロトコルを使用してアクセス・ポイントへの接続を確立し、ＳＭＴＰプロトコルを使用して、作成したメッセージ・ファイルを電子メールとして宛先アドレスに宛て送信する。なお、画像処理装置１００の実施形態で、ＰＰＰｏＥなどのプロトコルによりインターネットなどに常時接続されている場合には、メッセージ送信部２５０は、メッセージを作成後、直ちに宛先アドレスに宛て送信することができる。
【００５３】
また、他の実施形態では、取得したメッセージをＨＴＭＬ、ＸＭＬなどの構造化文書に記述し、決定された宛先アドレスにより指定されるサービスを提供することができる最適なサービス・サイトのサーバにメッセージをアップロードしても良い。
【００５４】
なお、図６では、「リソース状態」と「時刻」（時間帯）の組み合わせに対して、電子メールの宛先が設定される宛先情報テーブルの例を示したが、本実施形態では、リソース状態情報を、他の時間情報、すなわち、曜日情報や日付情報と組み合わせ、設定時刻、設定曜日、設定日付などをエントリするフィールドを、「通知条件」として構成させ、設定時刻、設定曜日、設定日付などについての範囲情報を任意に含ませた宛先情報テーブルとして構成することができる。
【００５５】
次に、図７に示すフローチャートを使用して、本実施形態の画像処理装置１００が実行する処理について説明する。処理は、ステップＳ７００から開始し、ステップＳ７０１で、画像処理装置１００は、画像処理装置１００内の各種リソース状態（消耗品状態やデバイス状態）についての情報を、定期的なポーリング処理または画像処理装置１００が実装するリソース状態検出部からの通知を受け付けるなどの処理を実行して収集する。
【００５６】
画像処理装置１００は、リソース状態を示す情報を、リソース状態管理テーブルまたはリソース状態を「装置状態」としてエントリした宛先情報テーブルのフィールドを検索して取得する。リソース状態管理テーブルまたは宛先情報テーブルは、ＮＶＲＡＭ１２３またはハードディスク装置１５１の特定のメモリ・アドレスにマッピングされた記憶領域に格納することができる。
【００５７】
ステップＳ７０２で、画像処理装置１００は、収集された情報を使用して、現在の画像処理装置１００のリソース状態が、不具合発生を通知をすべきか否かを判定する。サービス要求通知を送信すべきリソース状態としては、例えば、消耗品の残量が設定量以下（例えば、トナー残量が１０％以下）になっている状態や、デバイスがポーリング処理に対して応答を返さないことにより、故障と判断された状態などを挙げることができる。
【００５８】
ステップＳ７０２における判定の結果、リソース状態通知を通知しない場合（Ｎｏ）は、画像処理装置１００は、処理をステップＳ７０１に戻し、継続してリソース状態の監視を実行する。一方、ステップＳ７０２における判定の結果、リソース状態を通知をすると判断された場合（Ｙｅｓ）、処理をステップＳ７０３に分岐させる。
【００５９】
画像処理装置１００は、ステップＳ７０３で、カレンダー／クロック管理部２２０が、装置状態監視装置２１０からのリソース状態通知を受領して登録した不具合発生時刻を、例えばc_timeを読出して取得する。c_timeに登録される不具合発生時刻は、例えば、リソース状態通知を受付けた時刻、現在の曜日、日付などを含んでいる。
【００６０】
次に、画像処理装置１００は、ステップＳ７０４で、宛先情報記憶部２３０が管理する宛先情報テーブル３００〜６００を参照し、設定範囲をエントリするフィールドを検索する。なお、宛先情報テーブルのデータ構造についても、ＮＶＲＡＭ１２３またはハードディスク装置１５１の特定のメモリ・アドレスにマッピングされた記憶領域に格納され、宛先決定部２４０が参照することで取得することができる。
【００６１】
次に、画像処理装置１００は、ステップＳ７０５で、カレンダー／クロック管理部２２０から取得された不具合発生時刻を検索キーとした設定範囲をエントリするフィールドの検索からStart_data≦c_time≦End_dataとなる設定範囲が登録されたレコードを決定し、その宛先区分識別値を取得する。さらに、取得された宛先区分識別値のレコードの宛先アドレスを登録するフィールドのアドレスを読込み、登録されたデータを宛先アドレスとして取得し、バッファ・メモリなどに格納する。
【００６２】
なおStart_dataは、宛先情報テーブルに登録された宛先区分識別値により固有に指定されるレコードの、設定範囲にエントリされる設定開始値であり、End_dataは、設定終了値を意味し、c_timeと比較可能なエンコーディングで登録される値を意味している。
【００６３】
さらに画像処理装置１００は、ステップＳ７０６で、取得した宛先アドレスおよびメッセージを電子メール送信用のテンプレートなどとして作成されたファイルの宛先アドレス、メッセージを取得してテキスト・ストリングとして記述する。また、画像処理装置１００は、画像処理装置１００を固有に識別させることが可能な値を、送信元アドレスまたはメッセージ本文に記述してメッセージ・ファイルを作成する。メッセージ・ファイルが作成されると、メッセージ送信部２５０は、モデムまたはＤＳＵ／ＴＡ１７２または通信制御部１７１に対して指令して、ＰＯＰサーバとの間の接続を確立させる。その後、画像処理装置１００は、送信バッファに登録したメッセージ・ファイルを電子メールまたは構造化文書として公衆電話回線、ＩＳＤＮ、またはイーサネット（登録商標）を介してゲートウェイ・サーバまたは、インターネットを介してウェブ・サーバやＦＴＰサーバに送信し、処理をステップＳ７０７で終了させる。
【００６４】
以上のような処理を行うことにより、リソース状態がメンテナンスや消耗品補充などのサービスを必要とするようになったタイミング（時刻／曜日／日付）に応じ、適切な宛先にサービス要求を通知することが可能となる。
【００６５】
以上説明したように、本実施形態の画像処理装置１００は、リソース状態通知を行うことが必要になったタイミング（時刻、曜日、日付）や、通知すべきリソース状態を取得し、最適な宛先アドレスを決定し、リソース状態に対応したサービスを要求するメッセージとして送信する。このため、画像処理装置１００において発生したリソース状態（例えば、用紙切れ、トナー切れ、装置故障）に対する処置（例えば、用紙の補充、トナーカートリッジの交換、メンテナンス）の要求を最小のタイムラグで通知する機能が達成され、この結果、メンテナンス処理を最低限のタイムラグをもって迅速に行うことが可能となる。
【００６６】
上述した実施形態の各機能は、アセンブリ言語、Ｃ、Ｖｉｓｕａｌ Ｃ、Ｃ＋＋、Ｖｉｓｕａｌ Ｃ＋＋、Ｊａｖａ（登録商標）、Ｊａｖａ（登録商標）Ｂｅａｎｓ、Ｊａｖａ（登録商標）Ａｐｐｌｅｔ、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ、Ｐｅｒｌ、Ｒｕｂｙなど、レガシーブログラミング言語やオブジェクト指向プログラミング言語などで記述された装置実行可能なプログラムにより実現でき、装置可読な記録媒体に格納して頒布することができる。
【００６７】
これまで本発明を図面に示した実施形態をもって説明してきたが、本発明は図面に示した実施の形態に限定されるものではなく、他の実施形態、追加、変更、削除など、当業者が想到することができる範囲内で変更することができ、いずれの態様においても本発明の作用・効果を奏する限り、本発明の範囲に含まれるものである。
【図面の簡単な説明】
【００６８】
【図１】画像処理装置のハードウェア構成の実施形態を示した図。
【図２】画像処理装置の機能構成の実施形態を示した図。
【図３】宛先情報記憶部が管理する宛先情報テーブルの実施形態を示す図。
【図４】宛先情報記憶部が管理する宛先情報テーブルの実施形態を示す図。
【図５】宛先情報記憶部が管理する宛先情報テーブルの実施形態を示す図。
【図６】宛先情報記憶部が管理する宛先情報テーブルの実施形態を示す図。
【図７】画像処理装置の処理の実施形態のフローチャート。
【符号の説明】
【００６９】
１００…画像処理装置、１１０…ＣＰＵ、１２１…ＲＯＭ、１２２…ＲＡＭ、１２３…ＮＶＲＡＭ、１３１…操作パネル、１３２…操作パネル制御部、１４１…スキャン／プリントエンジン、１４２…エンジン制御部、１５１…ハードディスク装置、１５２…ハードディスク制御部、１６１…ＰＳＵ、１６２…電源制御部、１７１…通信制御部、１７２…モデム、１８０…外部インタフェース部、１９０…データバス、２１０…装置状態監視部、２２０…カレンダー／クロック管理部、２３０…宛先情報記憶部、２４０…宛先決定部、２５０…メッセージ送信部
【技術分野】
【０００１】
本発明は、ネットワーク接続可能な画像処理装置のリソース管理に関する。
【背景技術】
【０００２】
従来、ネットワーク接続可能な複合機（ＭＦＰ）などにおいて、紙やトナー等の消耗品の状態や、装置の異常な状態を検知して、予め設定された特定のユーザに電子メールを使用してメッセージを通知する機能を有するものが知られている。
【０００３】
例えば、特開２００４−２４２０３８号公報には、紙、トナーの残量、感光体などのサプライ品の状態や、装置の機械的若しくはソフト的な異常の発生を監視していて、リソース状態が予め設定した条件を満足したら、外部装置に対して、電子メールによって装置のリソース状態を通知する画像入出力装置が開示されている。
【０００４】
しかしながら、当該公報記載の画像入出力装置では、予め設定されたひとつの宛先にしかメッセージを送信できないため、当該メッセージを受信するユーザが不在の場合などは、電子メールによって通知されるべき、装置のリソース状態に対する処置が迅速には行われないという不都合があった。
【特許文献１】特開２００４−２４２０３８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
本発明の目的は、画像処理装置のリソース状態の通知を、より効果的にサービス要求の通知に変換し、消耗品のサプライやメンテナンス・サービスを行うことを可能とする、画像処理装置を提供することにある。
【課題を解決するための手段】
【０００６】
本発明では、消耗品状態やデバイス状態などの装置のリソース状態を検出し、検出されたリソース状態がサービスを必要とする場合、画像処理装置の不具合が検出された時刻を使用してサービス要求通知を送信する宛先アドレスを、日付、時刻、曜日などの通知条件を検索し、変更できるように構成する。宛先アドレスは、例えば、長期休暇中や、週末、夜間時など、適切な時間情報と対応させて登録しておくことができる。
【０００７】
宛先アドレスは、電子メール・アドレスまたはＵＲＩ(Uniform Resource Identifier)とすることができる。本発明では、リソース状態の監視により不具合が発生した場合、不具合が発生した時刻を不具合発生時刻として登録し、不具合発生時刻を使用して、登録された時間情報についての範囲情報を照会して、宛先アドレスが決定される。したがって、画像処理装置に不具合が発生した時刻で、最適で最も信頼性の高い通知先に、サービス要求通知が送付できる。本発明では、画像処理装置のリソース状態を監視することにより、サービスが必要であることを通知して不具合発生時刻が取得され、取得された不具合発生時刻から最小限のタイムラグで最適なサービス要求通知の宛先アドレスが決定される。
【０００８】
このため、本発明では、リソース状態通知を最小のタイムラグでサービス要求通知に変換し、メッセージを適切な宛先アドレス宛て送信でき、サービス要求を通知するメッセージを使用して装置のリソース状態に対する処置（例えば、消耗品の補充）を行うことができる。
【０００９】
サービス要求通知の伝送方式としては、ＳＭＴＰプロトコルを使用する電子メールまたは、Ａｐａｃｈｅ、ＩＩＳ(Internet Information Service)などのサーバ・プログラムを使用したＨＴＴＰを使用するファイル伝送を使用することができる。
【００１０】
すなわち、本発明によれば、
装置のリソース状態を監視して、前記リソース状態がサービスを要求する状態となったことを示す装置状態監視部と、
サービス要求を送付する複数の宛先アドレスについての宛先情報を記憶する宛先情報記憶部と、
現在時情報を管理し、前記サービスを要求する状態となった時刻を不具合発生時刻とする現在時情報管理部と、
前記装置状態監視部の指令に応答し、前記宛先情報記憶部が管理する宛先情報を、前記現在時情報管理部が設定した不具合発生時刻を検索キーとして検索し、前記宛先アドレスを決定する宛先決定部と、
前記宛先決定部によって決定された前記宛先アドレスに、サービス要求を通知するメッセージを送信するメッセージ送信部と
を含む、画像処理装置が提供される。
【００１１】
本発明の前記宛先情報記憶部は、時間情報と前記宛先アドレスとを対応付けて管理することができる。本発明では、前記宛先情報記憶部は、リソース状態、前記時間情報、および前記宛先アドレスを対応付けて管理することができる。本発明では、前記時間情報は、日付、曜日および時刻の少なくとも１つについての設定開始値および設定終了値として管理されても良い。
【発明を実施するための最良の形態】
【００１２】
以下、本発明を図面に示した実施形態をもって説明するが、本発明は後述する実施形態に限定されるわけではない。
【００１３】
図１は、画像処理装置のハードウェア構成の実施形態を示す。図１に示す画像処理装置１００は、ＣＰＵ（Central Processing Unit）１１０と、ＲＯＭ（Read Only Memory）１２１と、ＲＡＭ（Random
Access Memory）１２２と、ＮＶＲＡＭ（Non Volatile RAM）１２３とを備えている。ＣＰＵ１１０、ＲＯＭ１２１およびＲＡＭ１２２は、画像処理装置１００の起動時初期設定を可能とし、アプリケーション・ソフトウェアをＲＡＭ１２２に読込み、アプリケーションの実行による、ＳＭＴＰプロトコルを使用する電子メールによるメッセージ伝送を可能としている。ＮＶＲＡＭ１２３は、ＣＰＵ１１０によってアクセスされる読み書き可能な不揮発性のメモリであり、画像処理装置１００が電源を落とした状態においても記憶させておきたいデータを格納する。
【００１４】
また、本実施形態では、画像処理装置１００は、操作パネル１３１と、操作パネル制御部１３２と、スキャン／プリントエンジン１４１と、エンジン制御部１４２とを備えている。操作パネル１３１は、ユーザからの入力を受付け、パネル制御部１３２に伝え、画像処理装置１００に対して各種処理を指令する。さらに、画像処理装置１００は、ハードディスク装置１５１と、ハードディスク制御部１５２とを備えており、画像処理装置１００が取得したイメージデータや宛先アドレス、その他の情報を記憶し、画像処理装置１００からの要求に応答して情報を読み出して画像処理装置１００に渡している。スキャン／プリントエンジン１４１は、イメージデータの入出力ユニットとして、紙原稿の読み取りや転写紙への印刷を行うものである。エンジン制御部１４２は、ＣＰＵ１１０からの指令に応じて、スキャン／プリントエンジン１４１の制御を行なう。
【００１５】
さらに、本実施形態では、画像処理装置１００は、ＰＳＵ（Power Supply Unit）１６１と、電源制御部１６２と、通信制御部１７１と、モデム１７２と、外部インタフェース（Ｉ／Ｆ）部１８０とを備えている。ＰＳＵ１６１、電源制御部１６２は、画像処理装置１００への電力供給を制御して、例えば通常モードから省エネモードなどへの状態遷移を管理している。また、通信制御部１７１およびモデム１７２（ＩＳＤＮ回線などの場合には、ＤＳＵ／ＴＡ）は、画像処理装置１００のファクシミリ送信やＰＰＰなどの接続プロトコルを使用する、ＳＭＴＰプロトコルによる電子メールの送信を可能としている。また、通信制御部１７１は、ネットワーク・インタフェース・カード（ＮＩＣ）などを含んで構成されていて、ＰＰＰｏＥなどの接続プロトコルを使用して、イーサネット（登録商標）などによるローカルエリア・ネットワークまたはインターネットなどの公衆ネットワークへの接続を可能としている。
【００１６】
外部Ｉ／Ｆ部１８０は、セントロニクス等のパラレルインタフェースや、ＲＳ−２３２Ｃ、ＵＳＢなどのシリアルインタフェースを介して、外部の機器との通信を可能としている。なお、上述した各機能モジュールは、それぞれ、データバス１９０を介して相互接続されていて、各種データの送受信を実行している。
【００１７】
図２は、画像処理装置１００の機能構成を示す。図２に示す実施形態では、画像処理装置１００は、装置状態監視部２１０と、カレンダー／クロック管理部２２０とを含んでいる。装置状態監視部２１０は、装置内のデバイス状態や、用紙やトナーなどのリソース状態の監視を行うものである。装置状態監視部２１０は、リソース状態対応テーブルを管理しており、デバイス状態や消耗品の消費状態についての情報を定期的に収集する。収集された画像処理装置１００のリソース状態を、リソース状態管理テーブルのエントリ項目と照合する。
【００１８】
リソース状態管理テーブルは、本実施形態では、リソース状態通知がどのような不具合に対応するのかを対応づけて管理するデータ構造であり、装置状態監視部２１０は、リソース状態の取得内容に対応する不具合を、「トナー無し（各色ごと）」、「用紙無し」、または「・・・処理部応答無し」などのテキスト・コードなどを対応させて管理している。
【００１９】
装置状態監視部２１０は、照合の結果、画像処理装置１００が管理者またはメンテナンス・セクションに通知が必要な設定状態（例えば、消耗品が設定量以下）になっていると判断した場合、その時刻を決定するため、カレンダー／クロック管理部２２０に通知する。また、他の実施形態では、当該通知は、そのために設定される共用変数値を経由して行われても良い。この場合、装置状態監視部２１０は、リソース状態がサービス要求通知を発行する状態であることを示す共用変数値を、サービス要求通知を発行させる肯定的な値に設定する。同時に本実施形態では、装置状態監視部２１０は、リソース状態に対応するテキスト・ストリングを共用変数、例えば、message_contentに登録し、後述するメッセージ送信部２５０が読出し可能とする。
【００２０】
カレンダー／クロック管理部２２０は、現在の日付、曜日、時刻など、カレンダー情報を管理する。カレンダー／クロック管理部２２０は、宛先決定部２４０からの要求に応じて、リソース状態通知を受け取った時刻として与えられる不具合発生時刻を宛先決定部２４０に渡す。なお、カレンダー／クロック管理部２２０は、Ｃ、Ｃ＋＋、ＪＡＶＡ（登録商標）などの標準ライブラリ関数を使用して構成することができる。
【００２１】
例えば、本実施形態では、カレンダー／クロック管理部２２０は、リソース状態通信号の受領を待機しており、装置状態監視部２１０からのリソース状態通知を通信パケットなどとして明示的に受付けるか、またはリソース状態通知を受付けたことを示す変数値がサービス要求通知を発行することを肯定的に示す値を格納すると判断した場合、その時点での現在時刻を不具合発生時刻として、グローバル変数として設定されるc_timeなどに取得し、取得した不具合発生時刻を以後の処理において他の処理モジュールに利用させる構成とすることができる。
【００２２】
この場合、c_timeは、asctime()関数（Ｃ＋＋の実施形態で）などを用いてコーディングすることにより、月、日、時刻、年の出力形式で出力させることができる。なお、本発明では、使用する処理プログラムに応じて、同様の機能を与えるいかなるカレンダー関数を使用することができる。
【００２３】
さらに、本実施形態の画像処理装置１００は、宛先情報記憶部２３０と、宛先決定部２４０と、メッセージ送信部２５０とを含んで構成されている。宛先情報記憶部２３０は、メッセージによって画像処理装置１００のサービス要求を通知する宛先アドレスについての情報を記憶・管理しており、宛先アドレスの追加、変更に対応して追加修正が行われる。より具体的には、宛先情報記憶部２３０は、宛先情報として、不具合発生を通知するメッセージの宛先となる複数の宛先アドレスと、各宛先アドレスを選択するための通知先条件として使用される設定範囲（例えば、時間帯、曜日範囲、日付範囲など）とを対応付けて記憶する。宛先情報記憶部２３０が記憶する宛先情報の具体例については後述する。
【００２４】
宛先決定部２４０は、装置状態監視部２１０から管理者などに通知すべき不具合状態が発生することに対応して発行されるリソース状態通知または共用変数値の更新に応答して、カレンダー／クロック管理部２２０が登録した不具合発生時刻を検索キーとして、宛先情報記憶部２３０から取得される宛先情報を検索する。宛先決定部２４０は、検索によりサービス要求を送付しなければならない宛先アドレスを決定し、決定された宛先アドレスをメッセージ送信部２５０に渡す。具体的な宛先決定方法については後述する。
【００２５】
メッセージ送信部２５０は、特定の実施形態では、メーラ・アプリケーションを含んで構成されており、宛先決定部２４０から通知される電子メールの宛先アドレスを、サービス要求を行うためのメッセージ・ファイルの宛先アドレスに記述する。さらに、不具合に対応するメッセージを適切なメモリ・アドレスから取得して、メッセージ本文を記述する箇所に記述し、画像処理装置１００を固有に識別させる送信元アドレスまたはメッセージを追加して、メッセージ・ファイルを作成し、電子メール送信を行っている。
【００２６】
また、他の実施形態では、メッセージ送信部２５０は、ＡｐａｃｈｅやＩＩＳといったプログラムを含んで構成することもでき、ＨＴＴＰ、ＦＴＰなどのファイル転送プロトコルを使用してメッセージをサーバにアップロードする。本実施形態の場合、宛先決定部２４０は、時間情報を参照して、休暇中ではないサービス・セクションや部門を指定するＵＲＩを決定する。
【００２７】
本実施形態の画像処理装置１００は、装置状態監視部２１０により、リソース状態を監視し、リソース状態に不具合が発生した時刻を不具合発生時刻として使用して、登録された宛先アドレスを検索し、決定する処理を実行する。図３は、宛先情報記憶部２３０が管理する宛先情報テーブル３００の実施形態を示す。宛先情報テーブル３００は、宛先情報が格納されるテーブルであり、宛先情報テーブル３００に格納される情報は、予め管理者やサービスマンなどによって設定することができる。
【００２８】
図３に示す実施形態では、宛先情報テーブル３００は、宛先アドレスを検索する場合の時間情報を宛先アドレスの区分ごとに対応付けて管理している。宛先情報テーブル３００は、宛先区分識別値を「Ｎｏ．」としてエントリするフィールド３００ａと、設定範囲を、「設定時刻」として登録するフィールド３００ｂと、電子メールの宛先アドレスを。「宛先」としてエントリするフィールド３００ｃとを対応付けて管理している。図３に示した実施形態では、宛先情報テーブル３００は、１日のうちの時刻（時間帯）に対応して異なる宛先アドレスが設定されている。
【００２９】
図３の実施形態では、「０９：００」〜「１７：００」の時間帯に対し、宛先アドレスとして、会社で使用する宛先アドレス「taro_company@aaa.bb.jp」が、宛先区分識別値＝Ｎｏ．１として設定されている。さらに、「１７：０１」〜「１８：５９」の時間帯および「０７：０１」〜「０８：５９」の時間帯に対しては、宛先区分識別値＝Ｎｏ．２、４で携帯端末で使用する宛先アドレス「taro_mobile@ccc.dd.jp」が設定され、「１９：００」〜「０７：００」の時間帯に対しては、宛先区分識別値＝Ｎｏ．３として自宅で使用する宛先アドレス「taro_home@eee.ff.jp」が設定されている。
【００３０】
宛先決定部２４０は、装置状態監視部２１０からリソース状態について通知を受けると、カレンダー／クロック管理部２２０から取得される不具合発生時刻（現在の時刻情報）を、宛先情報テーブル３００の設定範囲と照合する。当該照合で、不具合発生時刻が「０９：００」〜「１７：００」の間の時刻を示していると判断した場合（例えば、不具合発生時刻が「１０：００」の場合）、不具合発生の通知を行う宛先として、「taro_company@aaa.bb.jp」を選択する。また、不具合発生時刻が「１７：０１」〜「１８：５９」の間または「０７：０１」〜「０８：５９」の間の時刻を示している場合（例えば、不具合発生時刻が「１８：００」の場合）は、「taro_mobile@ccc.dd.jp」を選択する。さらに、不具合発生時刻が「１９：００」〜「０７：００」の間の時刻を示している場合（例えば、不具合発生時刻が「２０：００」の場合）は、宛先アドレスとして「taro_home@eee.ff.jp」を選択する。
【００３１】
図４は、宛先情報記憶部２３０によって保持される他の実施形態の宛先情報テーブル４００を示す。図４に示した宛先情報テーブル４００は、時間情報を１週間のうちの曜日に応じて、異なる宛先を設定することができる。図４に示す宛先情報テーブル４００は、設定された時間情報を曜日識別値（Ｎｏ．）としてエントリするフィールド４００ａと、設定範囲を「設定曜日」としてエントリするフィールド４００ｂと、宛先アドレスを「宛先」としてエントリするフィールド４００ｃとを対応付け、レコードとして管理している。本発明のさらに他の実施形態では、国民の休日とされている特定日付を別にエントリするレコードを設けて、さらに詳細に管理しても良い。
【００３２】
図４に示した例では、曜日識別値＝Ｎｏ．１の「月曜日（Mon.）」〜「金曜日(Fri.)」の期間に対して、会社で使用する電子メールの宛先アドレス「taro_company@aaa.bb.jp」が設定されている。また、曜日識別値＝Ｎｏ．２の「土曜日（Sat.）」〜「日曜日(Sun.)」の期間に対して、自宅で使用する宛先アドレス「taro_home@eee.ff.jp」が設定されている。
【００３３】
図４の実施形態では、宛先決定部２４０は、カレンダー／クロック管理部２２０から取得される不具合発生時刻（現在の曜日情報）が、「月曜日（Mon.）」〜「金曜日(Fri.)」のいずれかの曜日を示している場合（例えば、「火曜日（Tue.）」の場合）、サービス要求通知を行う宛先として、「taro_company@aaa.bb.jp」を選択し、「土曜日（Sat.）」〜「日曜日(Sun.)」のいずれかの曜日を示している場合（例えば、「日曜日（Sun.）」の場合）は、「taro_home@eee.ff.jp」を選択する。
【００３４】
図５は、宛先情報記憶部２３０によって保持される宛先情報テーブルの更に他の実施形態を示す。図５に示す実施形態では、宛先情報テーブル５００は、日付識別値を「Ｎｏ．」としてエントリするフィールド５００ａと、時間範囲として使用され、設定範囲を「設定日付」としてエントリするフィールド５００ｂと、宛先アドレスを「宛先」としてエントリするフィールド５００ｃとを、レコードとして形成し、対応付けて管理している。図４に示した実施形態の宛先情報テーブル５００では、１年のうちの日付に応じて、異なる宛先を設定することができる。
【００３５】
図５に示した例では、日付識別値＝Ｎｏ．１で「８／１２」〜「８／２０」の期間に対して、携帯端末で使用する宛先アドレス「taro_mobile@ccc.dd.jp」が設定され、それ以外の期間に対して、日付識別値＝Ｎｏ．２で会社で使用する宛先アドレス「taro_company@aaa.bb.jp」が設定がされている。
【００３６】
図４に示した実施形態では、宛先決定部２４０は、カレンダー／クロック管理部２２０から取得される不具合発生時刻（現在の日付情報）が、「８／１２」〜「８／２０」の間の日付を示している場合（例えば、「８／１３」の場合）、サービス要求通知を行う宛先として、「taro_mobile@ccc.dd.jp」を選択し、「８／１２」〜「８／２０」の間にない日付を示している場合（例えば、「９／１２」の場合）は、「taro_company@aaa.bb.jp」を選択する。
【００３７】
なお、図３および図４に示した例においても、図５の場合と同様に、「上記以外」という設定をすることで、明示的に設定された範囲以外の全ての範囲をカバーさせることができる。なお、宛先アドレスとしてＵＲＩを使用する場合、宛先情報テーブルを構成する宛先フィールドに、ＵＲＩを記述しておくことで、ＨＴＴＰやＦＴＰなどのファイル転送プロトコルを使用して、期間情報により宛先を選択することが可能となる。
【００３８】
また、上記各テーブル３００〜５００の設定を行う際に、管理者などによって設定される内容のチェックを行うようにしてもよい。設定内容のチェックは、例えば、各設定項目に指定された時間範囲に重複が生じていないか、または設定された時間範囲に不足が生じていないかをチェックして、重複や不足が生じている場合は、設定された時間範囲を、設定しなければならない時間範囲のリストと照合して、重複設定または欠落設定が識別された段階で、ビープ音を発生させることで誤設定を管理者や、サービスマンなどに警告して、再設定を行わせるようにしてもよい。
【００３９】
また、他の実施形態では設定時には設定内容のチェックは行わず、上記テーブル３００〜５００を参照して宛先を決定する際に、設定された時間範囲の重複による条件の競合などが発生した時点で、予め定められたルールにしたがって競合などを解消させるようにしてもよい。例えば、条件の競合が生じた場合は、時間、曜日または日付の順に不具合発生時刻の対応する値を比較してゆき、最初に設定範囲に一致した範囲で宛先アドレスを選択することができる。
【００４０】
また、宛先情報記憶部２３０は、上記テーブル３００〜５００のいずれかひとつを保持するようにしてもよいし、そのうちの２つ、またはすべてを保持するようにしてもよい。宛先情報記憶部２３０が複数のテーブルを保持する場合は、各テーブルに設定された条件が競合したときに、どのテーブルの設定を優先させるかを予め（例えば、フラグ設定によって）設定できるようにする。
【００４１】
上述したテーブル３００〜５００の実施形態では、時間、曜日、日付などの時間情報と、宛先とを対応付けて管理する。さらに他の実施形態では、後述するように、装置のリソース状態と、時間情報と、宛先アドレスとを対応付けて管理することもできる。また、本発明のさらに別の実施形態では、設定時刻、設定曜日、設定日付などをエントリするフィールドを、「通知条件」として構成し、設定時刻、設定曜日、設定日付などについての範囲情報を任意に含ませた宛先情報テーブルとして構成することができる。
【００４２】
図６は、宛先情報記憶部２３０によって保持される宛先情報テーブルのさらに他の実施形態を示す。図６に示す実施形態では、宛先情報テーブル６００は、宛先区分識別値を「Ｎｏ．」としてエントリするフィールド６００ａと、通知すべき不具合状態を、「装置状態」としてエントリするフィールド６００ｂと、設定範囲を「設定時刻」としてエントリするフィールド６００ｃと、電子メールの宛先アドレスを、「宛先」としてエントリするフィールド６００ｄを対応付けて管理している。図６に示す宛先情報テーブル６００は、通知すべき装置の状態および１日のうちの時刻に応じて、異なる宛先を設定することができる。
【００４３】
なお、図６に示したデータ構造を使用する場合、装置状態監視部２１０は、リソース状態対応テーブルを別に管理する必要はなく、装置状態監視部２１０は、リソース状態に不具合が発生したことを示す通知を発行するか、または不具合を発生したことを示す共用変数の値を更新する処理を実行する。
【００４４】
図６に示した実施形態の場合、装置状態監視部２１０のメッセージ取得処理は、宛先決定部２４０が実装し、メッセージ送信部２５０のメッセージ取得を可能とする構成とされる。
【００４５】
図６に示した例では、リソース状態「用紙無し」および時間帯「０９：００」〜「１７：００」の組み合わせに対して、宛先区分識別値＝Ｎｏ．１で会社で使用する電子メールの宛先アドレス「taro_company@aaa.bb.jp」が設定され、リソース状態「用紙無し」および時間帯「１７：０１」〜「１８：５９」の組み合わせであって、リソース状態「用紙無し」および時間帯「０７：０１」〜「０８：５９」の組み合わせに対して、宛先区分識別値＝Ｎｏ．２、４で携帯端末で使用する宛先アドレス「taro_mobile@ccc.dd.jp」が設定されている。さらに、リソース状態「用紙無し」および時間帯「１９：００」〜「０７：００」の組み合わせに対して、宛先区分識別値＝Ｎｏ．３で、自宅で使用する宛先アドレス「taro_home@eee.ff.jp」が設定がされる構成とされている。
【００４６】
また、リソース状態「故障」および時間帯「０９：００」〜「１７：００」の組み合わせに対して、宛先区分識別値＝Ｎｏ．５でカスタマーサービスの通常の宛先アドレス「customer_service@ddd.ee.jp」が選択され、リソース状態「故障」および時間帯「１７：０１」〜「０８：５９」の組み合わせに対して、宛先区分識別値＝Ｎｏ．６で、カスタマーサービスの緊急用の宛先アドレス「emergency_service@
ddd.ee.jp」が選択される。
【００４７】
また、リソース状態「トナー無し」および時間帯「０９：００」〜「１７：００」の組み合わせに対して、宛先区分識別値＝Ｎｏ．７のレコードにエントリされた、カスタマーサービスの通常の宛先アドレス「customer_service@ddd.ee.jp」が設定され、リソース状態「トナー無し」および時間帯「１７：０１」〜「０８：５９」の組み合わせに対して、宛先区分識別値＝Ｎｏ．８のレコードにエントリされた、カスタマーサービスの緊急用の宛先アドレス「emergency_service@
ddd.ee.jp」が設定がされている。
【００４８】
図６に示した実施形態の場合、宛先決定部２４０は、装置状態監視部２１０から通知されるリソース状態が「用紙無し」であって、カレンダー／クロック管理部２２０から取得される不具合発生時刻（現在の時刻情報）が、「０９：００」〜「１７：００」の間の時刻である場合（例えば、「１０：００」の場合）、サービス要求通知を行う宛先として、「taro_company@aaa.bb.jp」を選択し、「１７：０１」〜「１８：５９」の間または「０７：０１」〜「０８：５９」の間の時刻である場合（例えば、「１８：００」の場合）は、「taro_mobile@ccc.dd.jp」を選択し、「１９：００」〜「０７：００」の間の時刻である場合（例えば、「２０：００」の場合）は、「taro_home@eee.ff.jp」を選択する。
【００４９】
また、装置状態監視部２１０から通知されるリソース状態が「故障」であって、カレンダー／クロック管理部２２０から取得される不具合発生時刻（現在の時刻情報）が、「０９：００」〜「１７：００」の間の時刻である場合（例えば、「１３：００」の場合）、サービス要求通知を行う宛先として、「customer_service@ddd.ee.jp」を選択し、「１７：０１」〜「０８：５９」の間の時刻である場合（例えば、「１８：００」の場合）は、「emergency_service@
ddd.ee.jp」を選択する。また、装置状態監視部２１０から通知されるリソース状態が「トナー無し」であって、カレンダー／クロック管理部２２０から取得される不具合発生時刻（現在の時刻情報）が、「０９：００」〜「１７：００」の間の時刻である場合（例えば、「１６：００」の場合）、サービス要求通知を行う宛先として、「customer_service@ddd.ee.jp」を選択し、「１７：０１」〜「０８：５９」の間の時刻である場合（例えば、「２３：００」の場合）は、「emergency_service@
ddd.ee.jp」を選択する。
【００５０】
図６に示した実施形態を採用する場合、宛先決定部２４０は、装置状態フィールド６００ｂにエントリされたコードや識別値を取得し、メッセージ・リストなどを検索して対応するテキスト・ストリングを選択し、共用変数message_contentに記述する。その後、メッセージ送信部２５０は、message_contentに記述された値を読出し、電子メールを送信するメーラのメッセージ記述箇所に追加し、宛先アドレスを、送信先アドレスを記述する部分に記述する。さらに、メッセージ送信部２５０は、送信元アドレスまたはメッセージ記述箇所中に画像処理装置１００を固有に識別することが可能な装置識別値を記述して、メッセージ・ファイルを作成する。
【００５１】
また、他の実施形態では、フィールド６００ｂに直接「用紙無し」、「故障」、「トナー（Ｂｋ）無し」などのテキスト・コートをエントリさせておくことができる。当該実施形態では、宛先決定部２４０は、取得したテキスト・ストリングを共用変数message_contentに登録するか、または通信パケットを作成し、メッセージ送信部２５０に通知しても良い。
【００５２】
上述した処理を終了した後、メッセージ送信部２５０は、モデムまたはＤＳＵ／ＴＡなどを起動し、ＰＰＰプロトコルを使用してアクセス・ポイントへの接続を確立し、ＳＭＴＰプロトコルを使用して、作成したメッセージ・ファイルを電子メールとして宛先アドレスに宛て送信する。なお、画像処理装置１００の実施形態で、ＰＰＰｏＥなどのプロトコルによりインターネットなどに常時接続されている場合には、メッセージ送信部２５０は、メッセージを作成後、直ちに宛先アドレスに宛て送信することができる。
【００５３】
また、他の実施形態では、取得したメッセージをＨＴＭＬ、ＸＭＬなどの構造化文書に記述し、決定された宛先アドレスにより指定されるサービスを提供することができる最適なサービス・サイトのサーバにメッセージをアップロードしても良い。
【００５４】
なお、図６では、「リソース状態」と「時刻」（時間帯）の組み合わせに対して、電子メールの宛先が設定される宛先情報テーブルの例を示したが、本実施形態では、リソース状態情報を、他の時間情報、すなわち、曜日情報や日付情報と組み合わせ、設定時刻、設定曜日、設定日付などをエントリするフィールドを、「通知条件」として構成させ、設定時刻、設定曜日、設定日付などについての範囲情報を任意に含ませた宛先情報テーブルとして構成することができる。
【００５５】
次に、図７に示すフローチャートを使用して、本実施形態の画像処理装置１００が実行する処理について説明する。処理は、ステップＳ７００から開始し、ステップＳ７０１で、画像処理装置１００は、画像処理装置１００内の各種リソース状態（消耗品状態やデバイス状態）についての情報を、定期的なポーリング処理または画像処理装置１００が実装するリソース状態検出部からの通知を受け付けるなどの処理を実行して収集する。
【００５６】
画像処理装置１００は、リソース状態を示す情報を、リソース状態管理テーブルまたはリソース状態を「装置状態」としてエントリした宛先情報テーブルのフィールドを検索して取得する。リソース状態管理テーブルまたは宛先情報テーブルは、ＮＶＲＡＭ１２３またはハードディスク装置１５１の特定のメモリ・アドレスにマッピングされた記憶領域に格納することができる。
【００５７】
ステップＳ７０２で、画像処理装置１００は、収集された情報を使用して、現在の画像処理装置１００のリソース状態が、不具合発生を通知をすべきか否かを判定する。サービス要求通知を送信すべきリソース状態としては、例えば、消耗品の残量が設定量以下（例えば、トナー残量が１０％以下）になっている状態や、デバイスがポーリング処理に対して応答を返さないことにより、故障と判断された状態などを挙げることができる。
【００５８】
ステップＳ７０２における判定の結果、リソース状態通知を通知しない場合（Ｎｏ）は、画像処理装置１００は、処理をステップＳ７０１に戻し、継続してリソース状態の監視を実行する。一方、ステップＳ７０２における判定の結果、リソース状態を通知をすると判断された場合（Ｙｅｓ）、処理をステップＳ７０３に分岐させる。
【００５９】
画像処理装置１００は、ステップＳ７０３で、カレンダー／クロック管理部２２０が、装置状態監視装置２１０からのリソース状態通知を受領して登録した不具合発生時刻を、例えばc_timeを読出して取得する。c_timeに登録される不具合発生時刻は、例えば、リソース状態通知を受付けた時刻、現在の曜日、日付などを含んでいる。
【００６０】
次に、画像処理装置１００は、ステップＳ７０４で、宛先情報記憶部２３０が管理する宛先情報テーブル３００〜６００を参照し、設定範囲をエントリするフィールドを検索する。なお、宛先情報テーブルのデータ構造についても、ＮＶＲＡＭ１２３またはハードディスク装置１５１の特定のメモリ・アドレスにマッピングされた記憶領域に格納され、宛先決定部２４０が参照することで取得することができる。
【００６１】
次に、画像処理装置１００は、ステップＳ７０５で、カレンダー／クロック管理部２２０から取得された不具合発生時刻を検索キーとした設定範囲をエントリするフィールドの検索からStart_data≦c_time≦End_dataとなる設定範囲が登録されたレコードを決定し、その宛先区分識別値を取得する。さらに、取得された宛先区分識別値のレコードの宛先アドレスを登録するフィールドのアドレスを読込み、登録されたデータを宛先アドレスとして取得し、バッファ・メモリなどに格納する。
【００６２】
なおStart_dataは、宛先情報テーブルに登録された宛先区分識別値により固有に指定されるレコードの、設定範囲にエントリされる設定開始値であり、End_dataは、設定終了値を意味し、c_timeと比較可能なエンコーディングで登録される値を意味している。
【００６３】
さらに画像処理装置１００は、ステップＳ７０６で、取得した宛先アドレスおよびメッセージを電子メール送信用のテンプレートなどとして作成されたファイルの宛先アドレス、メッセージを取得してテキスト・ストリングとして記述する。また、画像処理装置１００は、画像処理装置１００を固有に識別させることが可能な値を、送信元アドレスまたはメッセージ本文に記述してメッセージ・ファイルを作成する。メッセージ・ファイルが作成されると、メッセージ送信部２５０は、モデムまたはＤＳＵ／ＴＡ１７２または通信制御部１７１に対して指令して、ＰＯＰサーバとの間の接続を確立させる。その後、画像処理装置１００は、送信バッファに登録したメッセージ・ファイルを電子メールまたは構造化文書として公衆電話回線、ＩＳＤＮ、またはイーサネット（登録商標）を介してゲートウェイ・サーバまたは、インターネットを介してウェブ・サーバやＦＴＰサーバに送信し、処理をステップＳ７０７で終了させる。
【００６４】
以上のような処理を行うことにより、リソース状態がメンテナンスや消耗品補充などのサービスを必要とするようになったタイミング（時刻／曜日／日付）に応じ、適切な宛先にサービス要求を通知することが可能となる。
【００６５】
以上説明したように、本実施形態の画像処理装置１００は、リソース状態通知を行うことが必要になったタイミング（時刻、曜日、日付）や、通知すべきリソース状態を取得し、最適な宛先アドレスを決定し、リソース状態に対応したサービスを要求するメッセージとして送信する。このため、画像処理装置１００において発生したリソース状態（例えば、用紙切れ、トナー切れ、装置故障）に対する処置（例えば、用紙の補充、トナーカートリッジの交換、メンテナンス）の要求を最小のタイムラグで通知する機能が達成され、この結果、メンテナンス処理を最低限のタイムラグをもって迅速に行うことが可能となる。
【００６６】
上述した実施形態の各機能は、アセンブリ言語、Ｃ、Ｖｉｓｕａｌ Ｃ、Ｃ＋＋、Ｖｉｓｕａｌ Ｃ＋＋、Ｊａｖａ（登録商標）、Ｊａｖａ（登録商標）Ｂｅａｎｓ、Ｊａｖａ（登録商標）Ａｐｐｌｅｔ、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ、Ｐｅｒｌ、Ｒｕｂｙなど、レガシーブログラミング言語やオブジェクト指向プログラミング言語などで記述された装置実行可能なプログラムにより実現でき、装置可読な記録媒体に格納して頒布することができる。
【００６７】
これまで本発明を図面に示した実施形態をもって説明してきたが、本発明は図面に示した実施の形態に限定されるものではなく、他の実施形態、追加、変更、削除など、当業者が想到することができる範囲内で変更することができ、いずれの態様においても本発明の作用・効果を奏する限り、本発明の範囲に含まれるものである。
【図面の簡単な説明】
【００６８】
【図１】画像処理装置のハードウェア構成の実施形態を示した図。
【図２】画像処理装置の機能構成の実施形態を示した図。
【図３】宛先情報記憶部が管理する宛先情報テーブルの実施形態を示す図。
【図４】宛先情報記憶部が管理する宛先情報テーブルの実施形態を示す図。
【図５】宛先情報記憶部が管理する宛先情報テーブルの実施形態を示す図。
【図６】宛先情報記憶部が管理する宛先情報テーブルの実施形態を示す図。
【図７】画像処理装置の処理の実施形態のフローチャート。
【符号の説明】
【００６９】
１００…画像処理装置、１１０…ＣＰＵ、１２１…ＲＯＭ、１２２…ＲＡＭ、１２３…ＮＶＲＡＭ、１３１…操作パネル、１３２…操作パネル制御部、１４１…スキャン／プリントエンジン、１４２…エンジン制御部、１５１…ハードディスク装置、１５２…ハードディスク制御部、１６１…ＰＳＵ、１６２…電源制御部、１７１…通信制御部、１７２…モデム、１８０…外部インタフェース部、１９０…データバス、２１０…装置状態監視部、２２０…カレンダー／クロック管理部、２３０…宛先情報記憶部、２４０…宛先決定部、２５０…メッセージ送信部
【特許請求の範囲】
【請求項１】
装置のリソース状態を監視して、前記リソース状態がサービスを要求する状態となったことを示す装置状態監視部と、
サービス要求を送付する複数の宛先アドレスについての宛先情報を記憶する宛先情報記憶部と、
現在時情報を管理し、前記サービスを要求する状態となった時刻を不具合発生時刻とする現在時情報管理部と、
前記装置状態監視部の指令に応答し、前記宛先情報記憶部が管理する宛先情報を、前記現在時情報管理部が設定した不具合発生時刻を検索キーとして検索し、前記宛先アドレスを決定する宛先決定部と、
前記宛先決定部によって決定された前記宛先アドレスに、サービス要求を通知するメッセージを送信するメッセージ送信部と
を含む、画像処理装置。
【請求項２】
前記宛先情報記憶部は、時間情報と前記宛先アドレスとを対応付けて管理する、請求項１に記載の画像処理装置。
【請求項３】
前記宛先情報記憶部は、リソース状態、前記時間情報、および前記宛先アドレスを対応付けて管理する、請求項１に記載の画像処理装置。
【請求項４】
前記時間情報は、日付、曜日および時刻の少なくとも１つについての設定開始値および設定終了値として管理される、請求項２または３に記載の画像処理装置。
【請求項１】
装置のリソース状態を監視して、前記リソース状態がサービスを要求する状態となったことを示す装置状態監視部と、
サービス要求を送付する複数の宛先アドレスについての宛先情報を記憶する宛先情報記憶部と、
現在時情報を管理し、前記サービスを要求する状態となった時刻を不具合発生時刻とする現在時情報管理部と、
前記装置状態監視部の指令に応答し、前記宛先情報記憶部が管理する宛先情報を、前記現在時情報管理部が設定した不具合発生時刻を検索キーとして検索し、前記宛先アドレスを決定する宛先決定部と、
前記宛先決定部によって決定された前記宛先アドレスに、サービス要求を通知するメッセージを送信するメッセージ送信部と
を含む、画像処理装置。
【請求項２】
前記宛先情報記憶部は、時間情報と前記宛先アドレスとを対応付けて管理する、請求項１に記載の画像処理装置。
【請求項３】
前記宛先情報記憶部は、リソース状態、前記時間情報、および前記宛先アドレスを対応付けて管理する、請求項１に記載の画像処理装置。
【請求項４】
前記時間情報は、日付、曜日および時刻の少なくとも１つについての設定開始値および設定終了値として管理される、請求項２または３に記載の画像処理装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公開番号】特開２００８−１０４０５２（Ｐ２００８−１０４０５２Ａ）
【公開日】平成２０年５月１日（２００８．５．１）
【国際特許分類】
【出願番号】特願２００６−２８６０２３（Ｐ２００６−２８６０２３）
【出願日】平成１８年１０月２０日（２００６．１０．２０）
【出願人】（０００００６７４７）株式会社リコー (37,907)
【Ｆターム（参考）】
【公開日】平成２０年５月１日（２００８．５．１）
【国際特許分類】
【出願日】平成１８年１０月２０日（２００６．１０．２０）
【出願人】（０００００６７４７）株式会社リコー (37,907)
【Ｆターム（参考）】
[ Back to top ]