JP2011159232A - 画像処理装置、消耗品発注方法、及び消耗品発注プログラム - Google Patents

Abstract

【課題】機種ごとに異なる消耗品の自動発注機能を高品質かつ短期間で実現可能な画像処理装置、消耗品発注方法、及び消耗品発注プログラムを提供する。
【解決手段】画像処理装置１００は、機器の消耗品を発注するサービスセンタ２００に所定のデータ伝送路を介して接続され、消耗品の状態をサービスセンタ２００に通知することで、消耗品の発注を要求する装置であって、自機種に対応する消耗品の定義情報２３Ｄに基づき、サービスセンタ２００に消耗品の状態通知を行う条件であるセンタ通知条件が設定された設定情報２７Ｄを生成する生成手段２１と、生成された設定情報２７Ｄに基づき、消耗品の状態がセンタ通知条件に該当する状態か否かを判定する判定手段２５と、判定結果に従って、該当した消耗品の状態情報を含む通知データをサービスセンタ２００に送信する送信手段２６と、を有することを特徴とする。
【選択図】図４

Description

本発明は、機器の消耗品を発注するサービスセンタにデータ伝送路を介して接続される１又は複数の画像処理装置に関し、特に、機種ごとに異なる消耗品の自動発注を行う技術に関するものである。

画像処理装置は、例えば、トナーカートリッジや感光体ユニットなどの複数の消耗品を搭載している。そのため、ユーザは、機器から通知される消耗品の状態情報（例えば「トナー残量値」など）に基づき、該当部品を交換しなければならない。

この点を考慮し、従来では、ユーザ側に設置された画像処理装置と、メーカ側に設置されたサービスセンタとが、インターネットなどの外部ネットワークにより接続され、画像処理装置内で検知した消耗品の状態情報をサービスセンタに送信することで、消耗品の自動発注が行えるシステムが既に知られている。

上記システムを保守・運用するためには、画像処理装置に複数の機種が存在し、消耗品がこれらの機種ごとで異なると言う点を考慮しなければならない。そのため、画像処理装置に対して、機種ごとに消耗品の状態情報をサービスセンタに通知する状態通知プログラムを用意（開発）する必要がある。しかし、これでは、機種に対応する消耗品の構成が変わったり、新たな機種が追加されたりした場合、状態通知プログラムを更新又は新規開発しなければならないため、保守・運用作業が繁雑なものとなる。

そこで、例えば、特許文献１には、画像処理装置において、トナーカートリッジが備える記憶装置内に記憶されたプログラムをカートリッジ交換時に本体へロードし、本体プログラムを更新する技術が開示されている。

しかしながら、従来の方法では、プログラムの導入・更新が容易に行えるものの、機種ごとに状態通知プログラムを用意しなければならないと言う根本的な問題が解決されていない。

複数のプログラムを開発し、保守・運用することは、メーカ側にとって煩雑な作業である。例えば、メーカ側で新たなプログラムを開発した場合、そのプログラムに対して多くの工程に従って動作テストを行い、ユーザに対して動作保証した上で、プログラムを提供している。そのため、機種に対応して複数のプログラムが存在すると、開発時間だけでなく、動作テストにかかる時間も増大する。また、複数のプログラムが存在すると、プログラム管理（例えば「リリースバージョン管理」など）やプログラミング作業が複雑になり、障害を引き起こす可能性がある。

このように、機種に対応して複数のプログラムが存在する場合には、消耗品の構成変化や新規機種の追加に対して、品質を確保しながら（障害発生を防止し）迅速な機能提供（開発・テスト期間の短縮）を実現することが困難になる。

本発明は上記従来技術の問題点を鑑み提案されたものであり、その目的とするところは、機種ごとに異なる消耗品の自動発注機能を高品質かつ短期間で実現できる画像処理装置、消耗品発注方法、及び消耗品発注プログラムを提供することにある。

上記目的を達成するため、本発明に係る画像処理装置は、機器の消耗品を発注するサービスセンタに所定のデータ伝送路を介して接続され、消耗品の状態を前記サービスセンタに通知することで、消耗品の発注を要求する画像処理装置であって、自機種に対応する消耗品の定義情報に基づき、前記サービスセンタに消耗品の状態通知を行う条件であるセンタ通知条件が設定された設定情報を生成する生成手段と、前記生成手段により生成された設定情報に基づき、消耗品の状態が前記センタ通知条件に該当する状態か否かを判定する判定手段と、前記判定手段による判定結果に従って、該当した消耗品の状態情報を含む通知データを前記サービスセンタに送信する送信手段と、を有している。

このように、本発明に係る画像処理装置は、自機種に対応する消耗品の定義情報（定義ファイル）に基づき、消耗品の状態情報をサービスセンタに通知する条件（センタ通知条件）が設定された設定情報（設定ファイル）を自動生成する。また、画像処理装置は、消耗品の状態変化イベントが発行されると、受け取った状態変化イベントと生成した設定情報とに基づき、消耗品の状態がセンタ通知条件に該当する状態か否かを判定する。画像処理装置は、センタ通知条件に該当する状態と判定した場合、定義情報に定義された通知内容に基づき、該当した消耗品の状態情報を含む通知データ（発注要求データ）を生成し、生成した通知データをサービスセンタに送信する。

これによって、本発明に係る画像処理装置では、機種ごとに異なる消耗品の状態通知を、機種に依存するプログラムにより実現するのではなく、機種共通のプログラムにより実現できる。その結果、メーカ側でプログラム開発や更新作業などを機種ごとに行う必要がなく、開発・保守・運用が簡便になり、機種ごとに異なる消耗品の自動発注機能をユーザに対して高品質かつ短期間で提供できる。

上記目的を達成するため、本発明に係る消耗品発注方法は、機器の消耗品を発注するサービスセンタに所定のデータ伝送路を介して接続され、消耗品の状態を前記サービスセンタに通知することで、消耗品の発注を要求する画像処理装置における消耗品発注方法であって、自機種に対応する消耗品の定義情報に基づき、前記サービスセンタに消耗品の状態通知を行う条件であるセンタ通知条件が設定された設定情報を生成する生成手順と、前記生成手順により生成された設定情報に基づき、消耗品の状態が前記センタ通知条件に該当する状態か否かを判定する判定手順と、前記判定手順による判定結果に従って、該当した消耗品の状態情報を含む通知データを前記サービスセンタに送信する送信手順と、を有している。

このように、本発明に係る消耗品発注方法は、自機種に対応する消耗品の定義情報（定義ファイル）から、消耗品の状態情報をサービスセンタに通知する条件（センタ通知条件）が設定された設定情報（設定ファイル）を自動生成し、消耗品の状態変化イベントが発行されると、受け取った状態変化イベントと生成した設定情報とに基づき、消耗品の状態がセンタ通知条件に該当する状態か否かを判定し、センタ通知条件に該当する状態と判定した場合、該当した消耗品の状態情報を含む通知データ（発注要求データ）をサービスセンタに送信すると言う動作を実現する。

これによって、本発明に係る消耗品発注方法では、機種ごとに異なる消耗品の状態通知を、機種に依存するプログラムにより実現するのではなく、機種共通のプログラムにより実現可能な環境を提供できる。

本発明によれば、機種ごとに異なる消耗品の状態通知を機種共通のプログラムにより実現することで、機種ごとに異なる消耗品の自動発注機能を高品質かつ短期間で実現可能な画像処理装置、消耗品発注方法、及び消耗品発注プログラムを提供することができる。

本発明の第１の実施形態に係る消耗品発注システムの構成例を示す図である。 本発明の第１の実施形態に係る画像処理装置のハードウェア構成例を示す図である。 本発明の第１の実施形態に係る画像処理装置のソフトウェア構成例を示す図である。 本発明の第１の実施形態に係る消耗品発注機能の構成例を示す図である。 本発明の第１の実施形態に係る消耗品に関する定義情報（定義ファイル）のデータ例を示す図である。 本発明の第１の実施形態に係るセンタ通知条件の設定情報（設定ファイル）のデータ例を示す図である。 本発明の第１の実施形態に係る設定ファイルを更新・生成する処理手順例を示すフローチャートである。 本発明の第１の実施形態に係る消耗品を発注する処理手順例を示すシーケンス図である。

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

［第１の実施形態］
＜システム構成＞
図１は、本実施形態に係る消耗品発注システム１の構成例を示す図である。
図１には、ユーザ側に構築されたネットワーク環境Ｃ１，Ｃ２（以下総称する場合には「ネットワーク環境Ｃ」と言う）と、メーカ側に設置されたサービスセンタ２００とが、インターネットなどの外部ネットワークＩで接続されるシステム１の構成例が示されている。

サービスセンタ２００は、サーバ機能を有し、ユーザ側に導入された画像処理装置の消耗品の自動発注を統括して行う情報処理装置である。サービスセンタ２００は、ユーザ側のネットワーク環境Ｃから通知された消耗品の状態情報に基づき、消耗品の発注を行う。つまり、サービスセンタ２００は、消耗品の状態通知を受信したことにより、発注要求を受け付ける。なお、図１には図示していないが、サービスセンタ２００やユーザ側のネットワーク環境Ｃは、ファイアウォールを介して外部ネットワークＩに接続されている。

また、図１には、１又は複数の画像処理装置１００_１及び仲介機器３００_１、また、１又は複数の画像処理装置１００_２及び仲介機器３００_２が、ＬＡＮ（Local Area Network）などの内部ネットワークＮで接続されるネットワーク環境Ｃ１，Ｃ２の構成例が示されている。

画像処理装置１００_１，１００_２（以下総称する場合には「画像処理装置１００」と言う）は、例えば、ＭＦＰ（Multifunction Peripheral）やＬＰ（Laser Printer）と言ったオフィス業務内の作業で利用される画像処理機能を有する機器である。画像処理装置１００は、本体内部で搭載する消耗品の状態変化イベントを受け取ると、消耗品の状態情報を仲介機器３００_１，３００_２（以下総称する場合には「仲介機器３００」と言う）に送信する。仲介機器３００は、画像処理装置１００からの送信情報を、外部ネットワークＩを介してサービスセンタ２００に転送する機器である。これにより、ユーザ側のネットワーク環境Ｃからは、導入された画像処理装置１００が搭載する消耗品の状態情報がサービスセンタ２００に通知される。

消耗品発注システム１は、上記システム構成により、ユーザ先に導入された画像処理装置１００の使用状況に応じて搭載する消耗品を自動発注するサービス（消耗品発注機能）を提供することができる。

なお、上記システム構成では、ユーザ側のネットワーク環境Ｃに仲介機器３００が導入されている構成例を示したが、この限りでない。例えば、画像処理装置１００がサービスセンタ２００に消耗品の状態情報を直接通知する構成であってもよい。

＜ハードウェア構成＞
次に、上記画像処理装置１００のハードウェア構成について説明する。
図２は、本実施形態に係る画像処理装置１００のハードウェア構成例を示す図である。なお、図２には、ＭＦＰ（複合機）の場合の構成例が示されている。
図２に示すように、画像処理装置１００は、主に、コントローラ１１０、操作パネル１２０、プロッタ１３０、及びスキャナ１４０などを備え、それぞれが相互にバスＢで接続されている。

操作パネル１２０は、表示部及び入力部を備えており、機器情報などの各種情報をユーザに提供したり、動作設定や動作指示などの各種ユーザ操作を受け付けたりする。プロッタ１３０は、画像形成部を備えており、用紙に出力画像を形成する。出力画像を形成する方式には、例えば、電子写真プロセスやインクジェット方式などがある。スキャナ１４０は、原稿を光学的に読み取り、読み取り画像を生成する。

コントローラ１１０は、ＣＰＵ（Central Processing Unit）１１１、記憶装置１１２、ネットワークＩ／Ｆ１１３、及び外部記憶Ｉ／Ｆ１１４などを備えており、それぞれが相互にバスＢで接続されている。

ＣＰＵ１１１は、プログラムを実行することで装置全体を制御する。また記憶装置１１２は、上記プログラムや各種データ（「画像データ」など）を格納し保持する。記憶装置１１２には、例えば、揮発性のメモリであるＲＡＭ（Random Access Memory）、不揮発性のメモリであるＲＯＭ（Read Only Memory）、及び大容量の記憶領域を備えたＨＤＤ（Hard Disk Drive）などがある。ＲＡＭは、ＣＰＵ１１１のワークエリア（プログラムやデータが一時的に読み出される記憶エリア）として機能する。ＲＯＭやＨＤＤは、プログラムや各種データの格納先として用いられる。これにより、画像処理装置１００では、ＣＰＵ１１１がＲＯＭに格納されたプログラムをＲＡＭ上に読み出し、プログラムを実行する。

ネットワークＩ／Ｆ１１３は、画像処理装置１００をネットワークなどの所定のデータ伝送路に接続するためのインタフェースである。外部記憶Ｉ／Ｆ１１４は、外部記憶装置にあたる記録媒体１１４ａを接続するためのインタフェースである。記録媒体１１４ａには、例えば、ＳＤメモリカード（SD Memory Card）やＵＳＢ（Universal Serial Bus）メモリなどがある。これにより、画像処理装置１００は、外部記憶Ｉ／Ｆ１１４を介して、記録媒体１１４ａに格納されたプログラムやデータを読み取る。

画像処理装置１００では、上記ハードウェア構成により、各種画像処理を行うサービス（画像処理機能）を提供することができる。

＜ソフトウェア構成＞
次に、上記画像処理装置１００のソフトウェア構成について説明する。
図３は、本実施形態に係る画像処理装置１００のソフトウェア構成例を示す図である。
図３に示すように、画像処理装置１００は、主に、プラットフォームＰＦ及びアプリケーションＡＰなどを有している。

プラットフォームＰＦは、装置全体を制御し、所定の情報処理サービスを提供する基本ソフトウェアである。例えば、Ｌｉｎｕｘ（登録商標：以下略）などの組み込みＯＳ（Operating System）などである。プラットフォームＰＦは、搭載機能を実現するためのアプリケーションＡＰと搭載するハードウェアＨＷとの間に位置し、アプリケーションＡＰからの動作要求に応じてハードウェアＨＷを制御する。また、プラットフォームＰＦは、要求に応じて動作するハードウェアＨＷの状態などをアプリケーションＡＰに通知する。そのため、プラットフォームＰＦは、アプリケーションＡＰとの情報伝達手段としてＡＰＩ（Application Program Interface）を有している。

アプリケーションＡＰは、画像処理装置１００が提供する各種機能を実現するプログラム群である。例えば、図３に示すアプリケーションＡＰは、後述する消耗品発注機能を実現するプログラムＰ１（設定ファイル生成プログラム），Ｐ２（機器管理プログラム）、及び画像処理機能（「印刷」や「画像読み取り」など）を実現するプログラムＰ３（画像処理プログラム）などを有している。

上述したように、これらのプログラムＰ１，Ｐ２，Ｐ３（以下総称する場合には「プログラムＰ」と言う）は、プラットフォームＰＦを介して、ハードウェアＨＷへの動作要求や動作状態の取得などを行い、提供機能を実現している。

具体的には、次の通りである。
例えば、機器管理プログラムＰ２は、設定ファイル生成プログラムＰ１により生成された設定ファイルのセンタ通知条件（消耗品の状態情報をサービスセンタに通知する条件）に基づき、該当した消耗品の状態情報を含む通知データ（発注要求データ）をサービスセンタ２００に送信する（仲介機器を介して送信する場合を含む）。このとき、機器管理プログラムＰ２は、プラットフォームＰＦが提供する通信用ＡＰＩを、通知データ（発注要求データ）を設定した上で呼びだすことで、ネットワークＩ／Ｆ１１３に対して情報送信を要求する。

また、例えば、印刷機能を実現する画像処理プログラムＰ３は、印刷データ（ＰＤＬ：Printer Description Languageデータ）をプリンタエンジンが処理可能なデータ（ビットマップデータ／ラスタデータ）に変換し、プロッタ１３０に転送する。このとき、画像処理プログラムＰ３は、プラットフォームＰＦが提供する通信用ＡＰＩを介して、ネットワークＩ／Ｆ１１３により受信した印刷データを受け取る。また、画像処理プログラムＰ３は、プラットフォームＰＦが提供する描画用ＡＰＩを、変換データを設定した上で呼びだすことで、プロッタ１３０に対して印刷を要求する。

画像処理装置１００では、上記ソフトウェア構成により、画像処理機能や消耗品発注機能などを実現することができる。

なお、上記プラットフォームＰＦ及び上記アプリケーションＡＰは、画像処理装置１００が備えるコントローラ１１０の記憶装置１１２に格納されており、電源投入後にワークメモリ（ＲＡＭ）上に読み出され、ＣＰＵ１１１で実行される。

＜消耗品発注機能＞
ここからは、本実施形態に係る消耗品発注機能について説明する。
本実施形態に係る画像処理装置１００では、まず、設定ファイル生成プログラムＰ１により、次の処理が行われる。設定ファイル生成プログラムＰ１は、自機種に対応する消耗品の定義情報（定義ファイル）に基づき、消耗品の状態情報をサービスセンタ２００に通知する条件（センタ通知条件）が設定された設定情報（設定ファイル）を自動生成する。また、画像処理装置１００は、機器管理プログラムＰ２により、次の処理が行われる。機器管理プログラムＰ２は、消耗品の状態変化イベントが発行されると、受け取った状態変化イベントと生成した設定情報とに基づき、消耗品の状態がセンタ通知条件に該当する状態か否かを判定する。機器管理プログラムＰ２は、センタ通知条件に該当する状態と判定した場合、定義情報に定義された通知内容に基づき、該当した消耗品の状態情報を含む通知データ（発注要求データ）を生成し、生成した通知データをサービスセンタ２００に送信する。画像処理装置１００は、このような消耗品発注機能を有している。

従来の場合には、画像処理装置１００の機種に対応して状態通知プログラムを複数用意し、消耗品発注システム１において、これらのプログラムＰを機種ごとに管理し、保守・運用しなければならなかった。そのため、従来の方法では、消耗品の構成変化や新規機種の追加に対して、品質を確保しながら（障害発生を防止し）迅速な機能提供（開発・テスト期間の短縮）を実現することが困難であった。

そこで、本実施形態に係る消耗品発注機能は、画像処理装置１００で行われる機種ごとに異なる消耗品の状態通知を、機種に依存するプログラムＰで実現するのではなく、機種共通のプログラムＰ（設定ファイル生成プログラム及び機器管理プログラム）で実現する。

これにより、本実施形態に係る消耗品発注システム１では、メーカ側でプログラム開発や更新作業などを機種ごとに行う必要がなく、開発・保守・運用が簡便になり、機種ごとに異なる消耗品の自動発注機能をユーザに対して高品質かつ短期間で提供できる。

以下に、上記消耗品発注機能の構成とその動作について説明する。
図４は、本実施形態に係る消耗品発注機能の構成例を示す図である。
図４に示すように、画像処理装置１００は、設定ファイル更新・生成部２１、更新・生成要否判定部２２、イベント受信部２４、通知要否判定部２５、及びセンタ通知部２６などを有している。また、サービスセンタ２００は、通知受信部３１、発注部３２、定義ファイル導入・更新部３３、及び定義ファイル編集部３５などを有している。これら各機能部について、画像処理装置１００、サービスセンタ２００の順に説明する。

《画像処理装置が有する各機能部》
設定ファイル更新・生成部２１及び更新・生成要否判定部２２は、設定ファイル生成プログラムＰ１が実行されることで機能する機能部である。

設定ファイル更新・生成部２１は、消耗品の状態情報をサービスセンタ２００に通知する条件（以下「センタ通知条件」と言う）が設定された設定情報（以下「設定ファイル」と言う）を自動更新・生成する機能部である。設定ファイル更新・生成部２１は、自機種に対応する消耗品の定義情報（以下「定義ファイル」と言う）に基づき、設定ファイルを更新・生成する。

例えば、上記定義ファイルは、図５に示すようなデータ構成で、記憶装置１１２の所定の記憶領域である消耗品定義情報（定義ファイル：以下略）保持部２３に格納され保持されている。

図５は、本実施形態に係る消耗品に関する定義情報（定義ファイル）２３Ｄのデータ例を示す図である。
図５に示すように、定義ファイル２３Ｄは、［消耗品識別］項目、［センタ通知条件］項目、及び［通知内容］項目などの各情報項目を有するデータ構成となっており、消耗品ごとに各項目が対応付けられている。

［消耗品識別］項目は、消耗品の識別子が定義される情報項目である。例えば、項目値には、"トナー"や"感光体ユニット"と言った消耗品名が定義されている。［センタ通知条件］項目は、各消耗品に対応するセンタ通知条件が定義される情報項目である。例えば、項目値には、残量が所定の閾値以下となった場合にトナーの状態情報を通知する条件や、累積回転数が所定の回転数以上となった場合に感光体ユニットの状態情報を通知するなどの通知条件が定義されている。［通知内容］項目は、センタ通知時の通知内容（発注要求データの構成）が定義される情報項目である。例えば、項目値には、画像処理装置１００に関する情報である機器情報、消耗品識別情報、及び消耗品状態情報などを含む通知内容が定義されている。

定義ファイル２３Ｄは、上記データ構成により、［消耗品識別］項目の項目値を参照することで、各消耗品に対応する［センタ通知条件］項目及び［通知内容］項目などの項目値を取得できる。

なお、定義ファイル２３Ｄは、外部ネットワークＩを介してサービスセンタ２００から画像処理装置１００に送信され、消耗品定義情報保持部２３に格納される。このとき、サービスセンタ２００からは、画像処理装置１００の機種に対応する定義ファイル２３Ｄが送信される。なお、定義ファイル２３Ｄは、画像処理装置１００が記録媒体１１４ａを読み取り、消耗品定義情報保持部２３に格納してもよい。

図４の説明に戻る。設定ファイル更新・生成部２１は、消耗品定義情報保持部２３にアクセスし、定義ファイル２３Ｄの［消耗品識別］項目及び［センタ通知条件］項目を読み取り、各項目値から設定ファイルを更新・生成する。

例えば、設定ファイル更新・生成部２１は、図６に示すようなデータ構成の設定ファイル２７Ｄを更新・生成する。更新・生成後の設定ファイル２７Ｄは、記憶装置１１２の所定の記憶領域であるセンタ通知条件設定情報（設定ファイル：以下略）保持部２７に格納され保持される。

図６は、本実施形態に係るセンタ通知条件の設定情報（設定ファイル）２７Ｄのデータ例を示す図である。
図６に示すように、設定ファイル２７Ｄは、［消耗品識別］項目及び［センタ通知条件］項目などを有するデータ構成となっており、消耗品ごとに各項目が対応付けられている。

［消耗品識別］項目は、消耗品の識別子を設定する情報項目である。例えば、項目値には、消耗品の種別を識別する型番などが設定される。［センタ通知条件］項目は、各消耗品に対応するセンタ通知条件を設定する情報項目である。例えば、項目値には、消耗品の状態値（「トナー残量値」や「累積回転数」など）及び条件判定用の閾値（「残量割合」や「回転数」など）を用いてセンタ通知条件を表した条件式（不等式）などが設定される。

設定ファイル２７Ｄは、上記データ構成により、［消耗品識別］項目の項目値を参照することで、各消耗品に対応する［センタ通知条件］項目の項目値を取得できる。

ここで、定義ファイル２３Ｄと設定ファイル２７Ｄとのデータの違いについて説明する。
上述したように両ファイル２３Ｄ，２７Ｄは、［消耗品識別］項目及び［センタ通知条件］項目を有するデータ構成であるが、各項目値の特性が異なる。

例えば、［センタ通知条件］項目の項目値について比較してみる。図５に示すように、定義ファイル２３Ｄの［センタ通知条件］項目には、「残量が１５％以下」、「残量が１０％以下」、「累積回転数が１００００回転以上」などのサービスセンタ２００の管理者により定義可能な項目値が示されている。一方、図６に示すように、設定ファイル２７Ｄの［センタ通知条件］項目には、「Ｘ_ｂｋ／１００ ＜ ０．１５」、「Ｘ_ｃｙ／１００ ＜ ０．１０」、「Ｘ ＞ １００００」などの画像処理装置１００で処理可能な項目値が示されている。

上記特性の違いからも分かるように、設定ファイル更新・生成部２１では、単に定義ファイル２３Ｄから該当項目の項目値を抽出し、設定ファイル２７Ｄを更新・生成しているのではない。設定ファイル更新・生成部２１では、サービスセンタ２００で取り扱われるデータを画像処理装置１００で処理可能なデータに変換している。これにより、サービスセンタ２００では、画像処理装置１００のデータ仕様を熟知した人（「開発者」など）でなくても、定義ファイル２３Ｄの編集などを容易に行うことができる環境（定義ファイルを簡便に取り扱える環境）を維持できる。つまり、サービスセンタ２００では、画像処理装置１００の機種に依存する消耗品ごとの各種情報を外部データ化（定義ファイルを作成）し易い環境を維持できる。また、画像処理装置１００においても、サービスセンタ２００のデータ仕様に対応するための設計変更などの煩雑な作業を行わなくてよい。

図４の説明に戻る。更新・生成要否判定部２２は、設定ファイル２７Ｄの更新要否又は生成要否の判定を行う機能部である。更新・生成要否判定部２２は、消耗品定義情報保持部２３にアクセスし、定義ファイル２３Ｄの有無及び状態変化を監視し判定を行う。

具体的には、次の通りである。
更新・生成要否判定部２２は、定義ファイル２３Ｄが消耗品定義情報保持部２３に新規導入（格納）された場合、設定ファイル２７Ｄを生成する必要があると判定する。例えば、格納先に対して行ったファイル名検索において、初めて定義ファイル２３Ｄを発見した場合に生成する必要があると判定する。

また、更新・生成要否判定部２２は、消耗品定義情報保持部２３で保持する定義ファイル２３Ｄが更新された場合、設定ファイル２３を更新する必要があると判定する。例えば、定義ファイル２３Ｄの名前に変更があった場合やアクセス履歴の書き込み日時に変更があった場合に更新する必要があると判定する。このようにして判定された結果は、更新・生成要否判定部２２から設定ファイル更新・生成部２１へと渡される。これにより、設定ファイル更新・生成部２１は、更新・生成要否判定部２２による判定結果に従って、設定ファイル２７Ｄの更新・生成を行う。

画像処理装置１００では、設定ファイル生成プログラムＰ１の上記機能部により、外部データとして提供された消耗品の定義ファイル２３Ｄに基づき、消耗品ごとのセンタ通知条件が機種に応じて自動設定される。これにより、機種に依存する消耗品ごとのセンタ通知条件などを、予め状態通知処理を行うプログラムＰに組み込まなくてもよく、機種間で機能実現プログラムＰを共通化できる。

次に、イベント受信部２４、通知要否判定部２５、及びセンタ通知部２６は、機器管理プログラムＰ２が実行されることで機能する機能部である。
イベント受信部２４は、消耗品の状態変化イベントを受信する機能部である。例えば、画像処理装置１００では、プラットフォームＰＦを介して、搭載センサにより検知された消耗品の状態値（「トナー残量値」や「累積回転数」など）を状態変化イベントとして取得できる。このようにして受信した状態変化イベントは、イベント受信部２４から通知要否判定部２５へと渡される。

通知要否判定部２５は、サービスセンタ２００に対して、消耗品の状態情報を含む通知データ（発注要求データ）を送信するか否かを判定する機能部である。通知要否判定部２５は、センタ通知条件設定情報保持部２７にアクセスし、設定ファイル２７Ｄに設定されたセンタ通知条件に従って判定を行う。

具体的には、次の通りである。
通知要否判定部２５は、状態変化イベントに含まれる消耗品の識別子（「型番」など）に基づき、設定ファイル２７Ｄを参照し、該当する消耗品の設定データを特定する。続いて、通知要否判定部２５は、特定した設定データの［センタ通知条件］項目の条件式に、状態変化イベントに含まれる消耗品の状態値を代入し、設定されたセンタ通知条件が満たされるか否かを確認する。つまり、通知要否判定部２５は、消耗品の状態がセンタ通知条件に該当する状態か否かを判定する。その結果、通知要否判定部２５は、消耗品の状態がセンタ通知条件に該当する状態であった場合に送信する必要があると判定する。

例えば、通知要否判定部２５は、イベント受信部２４でＢＫトナーの状態変化イベントを受信した場合、ＢＫトナーに対応付けて設定された条件式「Ｘ_ｂｋ／１００ ＜ ０．１５」に、状態変化イベントに含まれるＢＫトナー残量値をＸ_ｂｋを代入し、条件式が満たされるか否かを確認する。よって、通知要否判定部２５は、ＢＫトナー残量値が'１５'未満の場合、ＢＫトナーの状態情報を含む通知データ（発注要求データ）を送信する必要があると判定する。このようにして判定された結果は、通知要否判定部２５からセンタ通知部２６へと渡される。

センタ通知部２６は、消耗品の状態情報を含む通知データ（発注要求データ）をサービスセンタ２００に送信する機能部である。センタ通知部２６は、通知要否判定部２５による判定結果に従って、通知データ（発注要求データ）の送信を行う。

具体的には、次の通りである。
センタ通知部２６は、送信する必要があると判定された消耗品の識別子に基づき、定義ファイル２３Ｄを参照し、該当する消耗品の定義データを特定する。続いて、センタ通知部２６は、特定した定義データの［通知内容］項目の項目値に基づき、消耗品の状態情報を含む通知データ（発注要求データ）を生成する。その結果、センタ通知部２６は、生成した通知データ（発注要求データ）を、通知元（発注元）を特定する通知ＩＤデータなどとともにサービスセンタ２００へ送信する。つまり、センタ通知部２５は、消耗品の状態がセンタ通知条件に該当する状態と判定された場合、通知データ（発注要求データ）の送信を行う。

例えば、センタ通知部２５は、ＢＫトナーの状態がセンタ通知条件に該当する状態と判定された場合、ＢＫトナーに対応付けて定義された通知内容に基づき、機器情報［機番］、消耗品識別情報［ＢＫトナー］、及び消耗品状態情報［ＢＫトナー残量値］などを含む通知データ（発注要求データ）を生成し、サービスセンタ２００に送信する。ここで、画像処理装置１００を識別する機番を機器情報として含む通知データ（発注要求データ）について説明したが、この限りでない。通知データ（発注要求データ）には、消耗品の発注を要求した画像処理装置１００に関する機器情報が含まれていればよい。

画像処理装置１００では、機器管理プログラムＰ２の上記機能部により、消耗品の状態が、外部データとして提供された消耗品の定義ファイル２３Ｄから機種に応じて自動設定されたセンタ通知条件に該当する状態となった場合、サービスセンタ２００に対して、該当した消耗品の状態が通知される。つまり、画像処理装置１００では、設定ファイル生成プログラムＰ１により設定された制御値に基づき、機器管理プログラムＰ２により消耗品の状態が通知される。これにより、サービスセンタ２００へ消耗品の自動発注が行われる。

《サービスセンタが有する各機能部》
通知受信部３１は、画像処理装置１００から送信された消耗品の状態情報を含む通知データ（発注要求データ）を受信する機能部である。これにより、通知受信部３１は、画像処理装置１００からの発注要求を受け付ける。このようにして受信された通知データ（発注要求データ）は、通知受信部３１から発注部３２へと渡される。

発注部３２は、画像処理装置１００から受け取った発注要求に応じて、消耗品の発注を行う機能部である。発注部３２は、通知データ（発注要求データ）とともに受信した通知ＩＤデータから発注元（画像処理装置の導入先）を特定する。また、発注部３２は、通知データ（発注要求データ）に含まれる機器情報及び消耗品識別情報などから発注された消耗品を特定する。その結果、発注部３２は、発注された消耗品が発注元に配送されるように処理する。

定義ファイル導入・更新部３３は、画像処理装置１００への定義ファイル２３Ｄの導入や画像処理装置１００が保持する定義ファイル２３Ｄの更新を行う機能部である。例えば、定義ファイル導入・更新部３３は、管理者からファイル導入又はファイル更新の指示を受け付けると、機種別消耗品定義情報（定義ファイル群：以下略）保持部３４から、指定される画像処理装置１００の機種に応じた定義ファイル２３Ｄを取得する。定義ファイル導入・更新部３３は、取得した定義ファイル２３Ｄを画像処理装置１００に送信し、定義ファイル２３Ｄの導入・更新を行う。これにより、定義ファイル導入・更新部３３は、画像処理装置１００が保持する定義ファイル２３Ｄを管理する。なお、機種別消耗品定義情報保持部３４は、サービスセンタ２００が備える記憶装置（非図示：「ＨＤＤ」など）の所定の記憶領域であり、複数の定義ファイル２３Ｄが機種ごとに格納され、ＤＢ（Data Base）などで管理されている。

定義ファイル編集部３５は、定義ファイル２３Ｄの編集処理を行う機能部である。定義ファイル編集部３５は、所定のＧＵＩ（Graphical User Interface）を介して受け付けた編集要求に従って、定義ファイル２３Ｄの新規作成や項目値の変更などを行う。

サービスセンタ２００では、上記機能部により、画像処理装置１００からの発注要求に従って、消耗品の発注が行われる。また、サービスセンタ２００では、消耗品の定義ファイル２３Ｄが画像処理装置１００の機種ごとに管理される。

以上のように、本実施形態に係る消耗品発注機能は、上記各機能部が連係動作することにより実現される。

次に、消耗品発注機能の詳細な動作（機能部群の連係動作）について、処理手順を示すフローチャート及びシーケンス図を用いて説明する。消耗品発注機能は、画像処理装置１００又はサービスセンタ２００に搭載（インストール）されるプログラムＰ（消耗品発注機能を実現するソフトウェア部品）が、制御部（「ＣＰＵ」など）により、格納先（「ＲＯＭ」や「ＨＤＤ」など）からワークメモリ（「ＲＡＭ」など）上に読み出され、以下の処理が実行されることで実現される。

以下の説明では、画像処理装置１００における設定ファイル更新・生成処理、消耗品発注システム１における消耗品発注処理の順に処理手順を説明する。

《設定ファイル更新・生成処理》
図７は、本実施形態に係る設定ファイル２７Ｄを更新・生成する処理手順例を示すフローチャートである。
画像処理装置１００では、設定ファイル生成プログラムＰ１が起動されると、図７に示すような処理が実行される。

更新・生成要否判定部２２は、所定時間が経過したか否かを確認する（ステップＳ１０１）。更新・生成要否判定部２２は、所定時間の経過が確認されない間（ステップＳ１０１：ＮＯ）、次処理に移行しない。これは、設定ファイル更新・生成処理を定期的に行うための処理である。

更新・生成要否判定部２２は、所定時間の経過を確認すると（ステップＳ１０１：ＹＥＳ）、消耗品定義情報保持部２３にアクセスし、定義ファイル２３Ｄが存在するか否か（消耗品定義情報保持部に定義ファイルが格納されているか否か）を確認する（ステップＳ１０２）。

更新・生成要否判定部２２は、定義ファイル２３Ｄの存在を確認すると（ステップＳ１０２：ＹＥＳ）、定義ファイル２３Ｄが更新されているか否か、又は定義ファイル２３Ｄが新規導入されたか否かを確認する（ステップＳ１０３）。このとき、更新・生成要否判定部２２は、定義ファイル２３Ｄの更新を、ファイルの状態変化（「ファイル名の変更」や「書き込み日時の変更」など）を基に確認する。また、更新・生成要否判定部２２は、定義ファイル２３Ｄの新規導入を、格納先のファイル名検索結果を基に確認する。

更新・生成要否判定部２２は、定義ファイル２３Ｄの更新を確認すると（ステップＳ１０３：［更新を確認］）、設定ファイル２７Ｄを更新する必要があると判定し、判定結果を設定ファイル更新・生成部２１に渡す。これにより、更新・生成要否判定部２２は、設定ファイル更新・生成部２１に対して、設定ファイル２７Ｄの更新を指示する。

設定ファイル更新・生成部２１は、消耗品定義情報保持部２３にアクセスし、定義ファイル２３Ｄに定義された所定の項目値を参照する（ステップＳ１０４）。このとき、設定ファイル更新・生成部２１は、定義ファイル２３Ｄの［消耗品識別］項目及び［センタ通知条件］項目の項目値を参照する。

続いて、設定ファイル更新・生成部２１は、センタ通知条件設定情報保持部２７にアクセスし、定義ファイル２３Ｄの項目値に基づき、保持される設定ファイル２７Ｄを更新する（ステップＳ１０５）。このとき、設定ファイル更新・生成部２１は、定義ファイル２３Ｄの参照項目値に基づき、設定ファイル２７Ｄの該当項目値を書き換える。

設定ファイル更新後は、設定ファイル更新・生成部２１から更新・生成要否判定部２２に更新完了の旨が通知され、ステップＳ１０１の処理へ移行する。

一方、更新・生成要否判定部２２は、定義ファイル２３Ｄの新規導入を確認すると（ステップＳ１０３：［新規導入を確認］）、設定ファイル２７Ｄを生成する必要があると判定し、判定結果を設定ファイル更新・生成部２１に渡す。これにより、更新・生成要否判定部２２は、設定ファイル更新・生成部２１に対して、設定ファイル２７Ｄの更新を指示する。

設定ファイル更新・生成部２１は、消耗品定義情報保持部２３にアクセスし、定義ファイル２３Ｄに定義された所定の項目値を参照する（ステップＳ１０６）。

続いて、設定ファイル更新・生成部２１は、定義ファイル２３Ｄの項目値に基づき、設定ファイル２７Ｄを生成する（ステップＳ１０７）。このとき、設定ファイル更新・生成部２１は、定義ファイル２３Ｄの参照項目値を、設定ファイル２７Ｄのデータ形式に変換し、該当項目値を生成する。

設定ファイル生成後は、設定ファイル更新・生成部２１から更新・生成要否判定部２２に生成完了の旨が通知され、ステップＳ１０１の処理へ移行する。

また、更新・生成要否判定部２２は、定義ファイル２３Ｄの更新又は新規導入のどちらも確認されなかった場合（ステップＳ１０３：［どちらでもない］）、設定ファイル更新・生成部２１に対して動作指示することなく、ステップＳ１０１の処理へ移行する。

このように、画像処理装置１００では、上記処理（設定ファイル生成プログラムの処理）により、機器管理プログラムＰ２の制御値（設定ファイルの項目値）が、定義ファイル２３Ｄの新規導入時や導入後のデータ更新時などのタイミングで、最新の値へと変更される。

《消耗品発注処理》
図８は、本実施形態に係る消耗品を発注する処理手順例を示すシーケンス図である。
消耗品発注システム１では、画像処理装置１００で機器管理プログラムＰ２が起動されると（ステップＳ２０１）、ステップＳ２０２〜Ｓ２０６が実行される。なお、サービスセンタ２００及び仲介機器３００は、既に機能を実現するためのプログラムＰが起動されているものとする。

画像処理装置１００は、通知要否判定部２５により、センタ通知条件設定情報保持部２７にアクセスし、設定ファイル２７Ｄを読み込む（ステップＳ２０２）。

続いて、画像処理装置１００は、イベント受信部２４により、自機が搭載する消耗品の状態が変化した際に発行される状態変化イベントの受信を待ち受ける（ステップＳ２０３）。

画像処理装置１００は、状態変化イベントを受信すると（ステップＳ２０４）、受信イベントが通知要否判定部２５に渡される。これより、イベント受信部２４は、通知要否判定部２５に対して、イベントが発行された消耗品のセンタ通知要否判定を指示する。

画像処理装置１００は、通知要否判定部２５により、読み込んだ設定ファイル２７Ｄに設定されたセンタ通知条件に従って、消耗品の状態情報を含む通知データ（発注要求データ）を送信するか否かを判定する（ステップＳ２０５）。このとき、通知要否判定部２５は、状態変化イベントに含まれる消耗品の識別子を基に設定ファイル２７Ｄから設定データを特定する。通知要否判定部２５は、特定した設定データの［センタ通知条件］項目に設定された条件式に、状態変化イベントに含まれる消耗品の状態値を代入し、消耗品の状態がセンタ通知条件に該当する状態か否かを確認する。その結果、通知要否判定部２５は、消耗品の状態がセンタ通知条件に該当する状態であった場合に送信する必要があると判定し、判定結果をセンタ通知部２６に渡す。

画像処理装置１００は、消耗品の状態がセンタ通知条件に該当する状態であって場合、センタ通知部２６により、該当した消耗品の状態情報を含む通知データ（発注要求データ）を仲介機器３００に送信し、仲介機器３００に対してセンタ通知を要求する（ステップＳ２０６）。このとき、センタ通知部２６は、消耗品の識別子を基に定義ファイル２３Ｄから特定した定義データの［通知内容］項目の項目値から、消耗品の状態情報を含む通知データ（発注要求データ）を生成する。その結果、センタ通知部２６は、生成した通知データ（発注要求データ）を、通知元（発注元）を特定する通知ＩＤデータなどとともに仲介機器３００へ送信する。

仲介機器３００は、起動後のデータ受信待ち状態（ステップＳ３０１）で、画像処理装置１００から通知データ（発注要求データ）を受信すると、サービスセンタ２００に受信データを転送し、センタ通知要求を仲介する（ステップＳ３０２）。

サービスセンタ２００は、起動後のデータ受信待ち状態（ステップＳ４０１）で、仲介機器３００から転送データを受信すると、通知受信部３１が転送データを発注部３２に渡し、消耗品の発注を指示する。

その結果、サービスセンタ２００は、発注部３２により、転送データに基づき、消耗品を発注する（ステップＳ４０２）。

このように、画像処理装置１００では、上記ステップＳ２０１〜Ｓ２０６の処理（機器管理プログラムの処理）により、設定ファイル生成プログラムＰ１が機種に応じて設定した制御値に従って、消耗品の状態がサービスセンタ２００に通知され、自動発注される。

＜まとめ＞
以上のように、本実施形態に係る画像処理装置１００によれば、設定ファイル更新・生成部２１により、自機種に対応する消耗品の定義ファイル２３Ｄに基づき、消耗品ごとのセンタ通知条件が設定された設定ファイル２７Ｄを自動生成する。

また、画像処理装置１００は、イベント受信部２４が消耗品の状態変化イベントを受信すると、通知要否判定部２５により、状態変化イベントと設定ファイル２７Ｄとに基づき、消耗品の状態がセンタ通知条件に該当する状態か否かを判定する。画像処理装置１００は、通知要否判定部２５がセンタ通知条件に該当する状態と判定した場合、センタ通知部２６により、定義ファイル２３Ｄに定義された通知内容に基づき、該当した消耗品の状態情報を含む通知データ（発注要求データ）を生成し、生成した通知データをサービスセンタ２００に送信する。

これによって、本発明に係る画像処理装置１００では、機種ごとに異なる消耗品の状態通知を、機種に依存するプログラムＰにより実現するのではなく、機種共通のプログラムＰにより実現できる。その結果、メーカ側でプログラム開発や更新作業などを機種ごとに行う必要がなく、開発・保守・運用が簡便になり、機種ごとに異なる消耗品の自動発注機能をユーザに対して高品質かつ短期間で提供できる。

ここまで、上記実施形態の説明を行ってきたが、実施形態に係る画像処理装置１００が有する「消耗品発注機能」は、図を用いて説明を行った各処理手順を動作環境（プラットフォーム）にあったプログラミング言語でコード化したプログラムが、画像処理装置１００が備えるＣＰＵ１１１により実行されることで実現される。

上記プログラムは、コンピュータが読み取り可能な記録媒体１１４ａに格納することができる。記録媒体には、例えば、ＳＤメモリカード及びＵＳＢメモリなどがある。

よって、上記プログラムは、上記記録媒体に記憶させることで、記録媒体を読み取り可能な外部記憶Ｉ／Ｆ１１４などを介して画像処理装置１００にインストールすることができる。また、画像処理装置１００は、ネットワークＩ／Ｆ１１３を備えていることから、電気通信回線を用いて上記プログラムをダウンロードし、インストールすることもできる。

また、上記実施形態では、画像処理装置１００が設定ファイル生成プログラムＰ１及び機器管理プログラムＰ２を有する構成例について説明を行ったが、この限りでない。例えば、設定ファイル更新・生成処理及び消耗品の状態通知処理を１つのプログラムＰで実現する構成であってもよい。

また、上記実施形態では、画像処理装置１００が消耗品定義情報保持部２３で保持する定義ファイル２３Ｄを参照し、設定ファイル更新・生成部２１によって設定ファイル２７Ｄを更新・生成する構成例について説明を行ったが、この限りでない。例えば、画像処理装置１００は、サービスセンタ２００が機種別消耗品定義情報保持部３４で保持する定義ファイル２３Ｄを、ネットワークを介して参照し、設定ファイル更新・生成部２１によって設定ファイル２７Ｄを更新・生成する構成であってもよい。

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

１ 消耗品発注システム
２１ 設定ファイル更新・生成部
２２ 更新・生成要否判定部
２３ 消耗品定義情報（定義ファイル）保持部（Ｄ：定義ファイル）
２４ イベント受信部
２５ 通知要否判定部
２６ センタ通知部
２７ センタ通知条件設定情報（設定ファイル）保持部（Ｄ：設定ファイル）
３１ 通知受信部
３２ 発注部
３３ 定義ファイル導入・更新部
３４ 機種別消耗品定義情報（定義ファイル群）保持部
３５ 定義ファイル編集部
１００ 画像処理装置
１１０ コントローラ（制御基板）
１１１ ＣＰＵ（中央処理装置）
１１２ 記憶装置（ＲＡＭ，ＲＯＭ，ＨＤＤなど）
１１３ ネットワークＩ／Ｆ（ＮＩＣ：Network I/F Card）
１１４ 外部記憶Ｉ／Ｆ（ａ：記録媒体）
１２０ 操作パネル（入出力装置）
１３０ プロッタ（画像形成部）
１４０ スキャナ（原稿読み取り部）
２００ サービスセンタ（情報処理装置）
３００ 仲介機器（情報処理装置）
Ｎ 内部ネットワーク（ＬＡＮ）
Ｉ 外部ネットワーク（インターネット）
ＡＰ アプリケーション
Ｐ プログラム（１：設定ファイル生成プログラム，２：機器管理プログラム）

特開２００６−２９３２９６号公報

Claims (8)

1. 機器の消耗品を発注するサービスセンタに所定のデータ伝送路を介して接続され、消耗品の状態を前記サービスセンタに通知することで、消耗品の発注を要求する画像処理装置であって、
   自機種に対応する消耗品の定義情報に基づき、前記サービスセンタに消耗品の状態通知を行う条件であるセンタ通知条件が設定された設定情報を生成する生成手段と、
   前記生成手段により生成された設定情報に基づき、消耗品の状態が前記センタ通知条件に該当する状態か否かを判定する判定手段と、
   前記判定手段による判定結果に従って、該当した消耗品の状態情報を含む通知データを前記サービスセンタに送信する送信手段と、を有することを特徴とする画像処理装置。
2. 前記生成手段は、
   消耗品の識別子が設定される消耗品識別項目及び前記センタ通知条件が設定されるセンタ通知条件項目の項目値が、消耗品ごとに対応付けられた設定情報を生成することを特徴とする請求項１に記載の画像処理装置。
3. 前記判定手段は、
   当該画像処理装置から発行された消耗品の状態変化イベントに含まれる消耗品の識別子に基づき、前記設定情報から該当するセンタ通知条件を特定し、
   特定したセンタ通知条件と、前記状態変化イベントに含まれる消耗品の状態値とに基づき、消耗品の状態が、特定したセンタ通知条件に該当する状態か否かを判定することを特徴とする請求項２に記載の画像処理装置。
4. 前記送信手段は、
   前記判定手段により、消耗品の状態が前記センタ通知条件に該当する状態と判定された場合、
   前記定義情報に定義された通知内容項目の項目値に基づき、前記通知データを生成し、生成した通知データを前記サービスセンタに送信することを特徴とする請求項１ないし３のいずれか一項に記載の画像処理装置。
5. 当該画像処理装置は、
   前記設定情報を生成する必要があるか否かを判定する生成要否判定手段を有し、
   前記生成要否判定手段は、
   当該画像処理装置が備える記憶装置に前記定義情報が格納された場合に、前記設定情報を生成する必要があると判定し、
   前記生成手段は、
   前記生成要否判定手段による判定結果に従って、前記設定情報を生成することを特徴とする請求項１ないし４のいずれか一項に記載の画像処理装置。
6. 当該画像処理装置は、
   前記設定情報を更新する更新手段と、
   前記設定情報を更新する必要があるか否かを判定する更新要否判定手段と、を有し、
   前記更新要否判定手段は、
   当該画像処理装置が備える記憶装置に保持される前記定義情報が更新された場合に、前記設定情報を更新する必要があると判定し、
   前記更新手段は、
   前記更新要否判定手段による判定結果に従って、前記設定情報を更新することを特徴とする請求項１ないし５のいずれか一項に記載の画像処理装置。
7. 機器の消耗品を発注するサービスセンタに所定のデータ伝送路を介して接続され、消耗品の状態を前記サービスセンタに通知することで、消耗品の発注を要求する画像処理装置における消耗品発注方法であって、
   自機種に対応する消耗品の定義情報に基づき、前記サービスセンタに消耗品の状態通知を行う条件であるセンタ通知条件が設定された設定情報を生成する生成手順と、
   前記生成手順により生成された設定情報に基づき、消耗品の状態が前記センタ通知条件に該当する状態か否かを判定する判定手順と、
   前記判定手順による判定結果に従って、該当した消耗品の状態情報を含む通知データを前記サービスセンタに送信する送信手順と、を有することを特徴とする消耗品発注方法。
8. 機器の消耗品を発注するサービスセンタに所定のデータ伝送路を介して接続され、消耗品の状態を前記サービスセンタに通知することで、消耗品の発注を要求する画像処理装置における消耗品発注プログラムであって、
   コンピュータを、
   自機種に対応する消耗品の定義情報に基づき、前記サービスセンタに消耗品の状態通知を行う条件であるセンタ通知条件が設定された設定情報を生成する生成手段と、
   前記生成手段により生成された設定情報に基づき、消耗品の状態が前記センタ通知条件に該当する状態か否かを判定する判定手段と、
   前記判定手段による判定結果に従って、該当した消耗品の状態情報を含む通知データを前記サービスセンタに送信する送信手段として機能させる消耗品発注プログラム。

Images